en hoe ze te slechten

9

White paper

barrières voor de agile IT organisatie

en hoe ze te slechten

Your business technologists. Powering progress

Inleiding

Waarom is het voor IT organisaties zo moeilijk om snelle antwoorden te geven op vragen die vanuit de eindgebruiker gezien tamelijk eenvoudig zouden moeten zijn? En waarom heeft iedereen in een dergelijke organisatie het idee dat hij of zij verzuipt in het werk, terwijl de klanten zich afvragen of er eigenlijk wel wat gebeurt? Waarom kan een kleine internet-startup met vijf mensen sneller een nieuwe campagnesite lanceren dan dat het de IT organisatie van een grote onderneming lukt om een eerste meeting te organiseren waarin over het idee voor een nieuwe campagnesite wordt nagedacht? Waarom zijn veel IT organisaties niet wendbaar, niet Agile? Waarom kunnen ze niet meebewegen met de veranderende werelden om zich heen?

Contents

Makkelijke vragen, moeilijke antwoorden 3 De negen grootste bergen werk

4

Phanta Rei, Alles Stroomt

8

Een Agile aanpak om te komen tot een Agile IT organisatie

9

Aan de slag: Wat nu te doen

13

Tot slot

14

Onder de noemer Agilization bundelt Atos Consulting haar deskundigheid op het gebied van het wendbaar maken van organisaties. Daarbij vullen disciplines als Change Management, IT Strategy, Process Management, Lean, Architectuur, Project Management en HR Management elkaar aan zodanig dat daadwerkelijk succes wordt behaald door de multidisciplinaire aanpak. 2

Negen barrières voor de Agile IT organization

Makkelijke vragen, moeilijke antwoorden Uit onze ervaring blijkt dat dit geen eenvoudig te beantwoorden vragen zijn, maar dat er wel een gemeenschappelijke oorzaak is met een duidelijke remedie. Die oorzaak is namelijk verstopping, congestie. En zo voortvarend als we in Nederland de afgelopen jaren bezig zijn geweest met het wegwerken van congestie in het verkeer (daarmee de Agility of beter gezegd de Mobiliteit van Nederland groter makend), zo afwachtend zijn we geweest in de sluipende congestie die in elke IT organisatie op de loer ligt. Daarbij dient aangetekend te worden dat die verstopping zowel een oorzaak is als een symptoom van een gebrek aan wendbaarheid in een IT organisatie. Want een organisatie die niet wendbaar is zal op allerlei plaatsen een ophoping van onderhanden werk te zien geven, terwijl datzelfde onderhanden werk voorkomt dat er flexibel kan worden ingespeeld op veranderingen.

De verstopte organisatie In vroeger tijden was het makkelijk om een stroperige en verstopte organisatie te herkennen. Dat was namelijk te zien aan de vele stapels documenten die je overal zag liggen. Kasten vol. Bureaus vol. Sommige mensen moesten zich achter hun bureau uitrekken om over de stapel achterstallig werk heen kijkend nog een stukje van de buitenwereld te kunnen zien. Gelukkig is dat tegenwoordig anders. De werk¬plekken van tegenwoordig zien er fris uit. De flex-plek¬bureaus zijn keurig leeg volgens het gevoerde clean-desk beleid, prachtige 18 inch schermen staan gereed, toetsenbord en dockingstation in de aanslag. Je zou je haast in de clean rooms van een chip¬fabrikant wanen.


Hoe anders is het als je dieper kijkt. De hele afdeling zit verstopt met achterstallig werk. Niet in de vorm van papieren dossiers, maar vermomd als mails in een overvolle mailbox (“your mailbox is over its 500 MB size limit”). Op actielijsten staan acties maanden te rijpen. Sommige change requests gaan binnenkort hun tweede verjaardag vieren. Agenda’s zijn zo overvol dat er geen tijd is om even de vorige vergadering te verwerken en in acties om te zetten. In de projectenportefeuille zitten projecten waarvan iedereen weet dat ze allang gestopt hadden moeten worden maar waar nu al zoveel in is geïnvesteerd dat we ze toch maar doorzetten. Op de prachtige Sharepoint team site staan tienduizenden documenten waar nog eens de bezem doorheen moet worden gehaald.

Overal sleepankers Geen wonder dat elke flexibiliteit en innoverend vermogen uit een dergelijke organisatie is verdwenen. Als mensen al wat tijd overhebben dan gebruiken ze die om “hun mail bij te werken”, waarbij ze in een uur tijd een stuk of 20 mailtjes uit hun eigen mailbox wegwerken en daar 40 mailtjes in andermans mailbox tegenover stellen. De organisatie zit vol met sleepankers, alsmaar doorzeurende dossiers. Dan is het te verwachten dat een nieuwe, spontane, frisse vraag van de business wordt beantwoord met “ja, daar hebben we echt geen tijd voor….” Een dergelijke organisatie kan moeilijk de omschakeling maken naar nieuwe producten en processen. Als je een fabriek hebt die vol ligt met onderdelen voor en halffabricaten van zwart-wit televisies, dan kun je de omschakeling naar kleurentelevisies maar moeilijk maken.

In dit artikel schetsen we een oplossing. Die oplossing is niet het ei van Columbus, maar heeft zich bewezen als een methode die daadwerkelijk tot verbetering leidt. Dat geldt voor de nogal extreem neergezette organisatie die hiervoor is geschetst, maar ook voor organisaties waar het minder erg gesteld is, maar waar de verstopping en de overload op de loer liggen als sluimerende spierverslappende middelen. De oplossing vindt zijn oorsprong in de industriële sector, waar al decennia lang gewerkt is aan het minimaliseren van de doorlooptijd en het verlagen van de werkvoorraden. Om een en ander tastbaar te maken hebben we hieronder een “gemiddelde” IT organisatie weergegeven, om zodoende een indruk te geven van de omvang van de werkvoorraad, in productietermen het Onderhanden Werk of OHW. Deze IT organisatie bestaat uit 200 fte, heeft een budget van circa 50 miljoen euro, en bevat de hele range, van Business Information Managers tot Technisch Beheerders.

Agilization: Als je een fabriek hebt die vol ligt met onderdelen voor en halffabricaten van zwart-wit televisies, dan kun je de omschakeling naar kleurentelevisies maar moeilijk maken.

3

De negen grootste bergen werk

Waar ligt dan de werkvoorraad binnen een IT organisatie? De negen grootste stapels bespreken we hieronder. Als gezegd vormen deze stapels zowel een symptoom als een oorzaak van een gebrek aan wendbaarheid. Het zijn daadwerkelijk barrières voor de Agile IT organisatie.

Berg 1: “You’ve got mail” Met stip op nummer 1: de Inbox van de medewerkers in de organisatie, daarbij opgeteld de functionele mailboxen die gedeeld worden door meer mensen op een afdeling. Een medewerker krijgt gemiddeld 99 e-mails per dag. Deze razendsnel groeiende Inbox – inclusief de talloze sub-mapjes die medewerkers aanmaken om nog enigszins overzicht te houden – bevat voor een typische medewerker op enig moment gemiddeld 250 items “waar ze nog iets mee moeten.” Je kunt de gemiddelde professionele organisatie dan ook het beste vergelijken met een voetbalteam, waarbij elk van de elf spelers een grote zak met “nog af te handelen post” met zich mee moet sjouwen tijdens de wedstrijd. Wat denk je dat er met de wendbaarheid en het creatief vermogen van een dergelijk elftal zou gebeuren. Zelfs Messi zou “eerst zijn mail even doen” alvorens te gaan denken aan scoren. In onze ”gemiddelde” IT organisatie hangen dus 50.000 e-mails te wachten. Die vragen bewust of onbewust om aandacht. En hoe langer ze blijven liggen, hoe moeilijker het wordt om ze nog adequaat te verwerken.

Figuur 1: Negen bergen die innovatie en agilization in de weg staan

1

3 5 I N N O V A T I E Klanten E-mails Projecten in de 2 4 wacht Change requests

Sollicitanten

Contract details

9

Facturen

Niet gestelde vragen

8 Het archief

AG I L I Z AT I O N Berg 2: Change Requests Elke IT beheersorganisatie kent ze: changes die eindeloze discussie opleveren. De business weet niet wat ze wil, spreekt met vele monden, en veranderen ook nog eens steeds van mening. De IT organisatie vindt ze ook niet makkelijk en zou er eigenlijk even goed voor willen gaan zitten, maar kan de tijd en het geduld daarvoor niet opbrengen. En dus blijven ze eeuwig staan, tot frustratie van iedereen en alles. Gek genoeg is het beheer van al die changes in onze ervaring al een hele opgave. Omdat changes nogal wat documenten zoals impactanalyses met zich mee kunnen dragen bestaat het gevaar dat ze niet strak gedefinieerd zijn of worden. Er ontstaan problemen met versiebeheer, het eenduidige beeld op de changes vertroebelt, de verwachtingen lopen uiteen: “ja, maar ik bedoelde juist dat dat er niet bij hoorde”.

Je kunt de gemiddelde professionele organisatie dan ook het beste vergelijken met een voetbalteam, waarbij elk van de elf spelers een grote zak met “nog af te handelen post” met zich mee moet sjouwen tijdens de wedstrijd.

4

6

7

Berg 3: De projectenportefeuille De gemiddelde IT organisatie heeft meer dan 100 projecten lopen, gelijktijdig. Dat betekent dat die projecten elkaar in de weg zitten, al is het maar voor wat betreft de resources en daarmee de doorlooptijd. Een eenvoudig voorbeeld illustreert dat. Stel een organisatie heeft drie projecten A,B en C. Die vergen alle drie 2 manmaanden werk. We hebben twee man tot onze beschikking. Als we ze alle drie gelijktijdig uitvoeren (eerst een stukje A, dan een stukje B, dan een stukje C, en dan weer een stukje A), dan zijn alle drie de projecten na drie maanden gereed. Maar doen we ze achter elkaar, dan is project A al na een maand gereed, project B al na twee maanden en project C duurt nog steeds even lang, 3 maanden. Ofwel: minder projecten tegelijkertijd doen versnelt de oplevering van een aantal projecten zonder dat dat ten koste gaat van andere projecten! En dan hebben we het “omsteleffect” en de onderlinge afhankelijkheid tussen projecten nog niet eens meegerekend.


“Tijd is geld”. De business vraagt niet voor niets om projecten en changes. Die leveren naar hun mening geld op in de vorm van kostenbesparingen of extra winst. En hoe langer het duurt voor die projecten of changes zijn uitgevoerd, hoe langer het duurt voor de business dat geld kan binnenhalen. “More is less” en dat geldt in projectportfoliomanagement als geen ander. Projecten die geen waarde toevoegen moeten natuurlijk acuut gestopt worden, voor dat soort folkloristische activiteiten is in deze tijd echt geen plaats meer. Kosten die al gemaakt zijn – in boekhoudkundige termen “sunk costs” horen geen rol te spelen bij de beslissing om wel of niet door te gaan met een project, hoe tegennatuurlijk dat ook moge lijken.


En verder moet er gepland worden met zo min mogelijk projecten tegelijkertijd. Het boek “The Critical Chain” van Goldratt geeft een schat aan tips. Met als belangrijkste: “tijd is geld”. De business vraagt niet voor niets om projecten en changes. Die leveren naar hun mening geld op in de vorm van kostenbesparingen of extra winst. En hoe langer het duurt voor die projecten of changes zijn uitgevoerd, hoe langer het duurt voor de business dat geld kan binnenhalen. Deze “opportunity costs” worden vaak niet inde beschouwing meegenomen, wat natuurlijk verkeerd is.

Berg 4: Sollicitanten in procedure Dit is een verrassende berg die we toch zeer regelmatig tegenkomen in IT organisaties: de lijst van sollicitanten in procedure waar het maanden lijkt te duren voor een vacature daadwerkelijk is ingevuld, ondanks de economische crisis. Daarbij rekenen we ook de lijsten met door leveranciers aangedragen kandidaten voor tijdelijke posities, waarvan iedereen weet dat ze na twee weken normaal gesproken geen kandidaat meer zijn omdat ze elders zijn ingezet. Het lijkt er op dat IT organisaties vaak niet doordrongen zijn van het feit dat het tijdig invullen van open posities een key element is voor een soepel draaiende organisatie. Als een afdeling van tien mensen een half jaar zonder feitelijke leiding zit – die wordt er dan tijdelijk even door een ander “bijgedaan”- dat heeft dat nog maanden daarna consequenties voor het vermogen om adequaat zaken op te pakken. Als die ene vacature voor een specialist op het gebied van middleware maar niet ingevuld blijft worden, dan brengt dat alle projecten in gevaar. Linksom of rechtsom, er blijft werk liggen, en dat gaat ook nog eens ten koste van het innoverend vermogen.

Het is daarom verbazingwekkend dat er in de gemiddelde IT organisatie niet meer aandacht aan wordt besteed. Termen als succession planning zouden gemeengoed moeten zijn. De aansluiting met HR en Inkoop zou zo moeten zijn dat er soepel geschakeld wordt als er een positie open staat. En de feitelijke verwerking van sollicitanten moet als een flow, met een minimum aan werkvoorraad.

Het is verbazingwekkend dat er in de gemiddelde IT organisatie niet meer aandacht wordt besteed aan het snel en adequaat invullen van permanente en tijdelijke vacatures.

5

Berg 5: Klanten die wachten op antwoord

Berg 6: Voortslepende contractbesprekingen

Berg 7: Rondgepompte facturen

Dit is de berg waar call centres zo goed op sturen: op de rij met klanten in de wacht. Op grote elektronische borden aan de wand wordt heel direct aangegeven hoe lang de wachtrij is, en hoe lang de wachttijd. De manager van een dergelijk call centre zal er alles aan doen om zo’n rij zo klein mogelijk te houden, in de wetenschap dat de klanttevredenheid letterlijk met de minuut daalt.

Deze zesde berg is feitelijk de tegenhanger van de vijfde. Waar berg 5 zich bevindt aan de klantenkant, kunnen we berg 6 vinden aan de leverancierskant.

Veel IT organisatie s dragen een administratieve last met zich mee die uitermate verlammend werkt. Die verlamming is extra sterk als het om geld gaat: facturen die rondgepompt worden totdat iemand bereid is de kosten op zich te nemen, kostenallocaties die maar niet gebeuren, budgetoverschrijdingen die niemand op zijn nek wil nemen. Voorbeelden hiervan zijn de kosten voor een tijdschrift waarvan het abonnement te laat is opgezegd: wie gaat dat betalen? Extremer is het voorbeeld van een net gereorganiseerde multinational die over de hele wereld facturen heeft liggen van IT service leveranciers die diensten hebben geleverd aan entiteiten die vanwege de reorganisatie niet meer bestaan.

Helaas gaat die heldere weergave alleen op voor de klanten van de IT organisatie die de helpdesk bellen. Daar gelden dezelfde principes als voor elk call centre, en is daarom vaak al het onderwerp geweest van een optimalisatieslag. Maar het merendeel van de klanten van een IT organisatie is niet zo zichtbaar als een rij mensen aan de telefoon. Zij hebben een vraag gesteld, een idee geopperd, een klacht ingediende, soms bij de helpdesk, soms bij hun business partner, soms naar een willekeurige IT medewerker. En ze verwachten antwoord. Ze willen geïnformeerd worden over wat er gebeurt, of er voortgang is, wat het gaat kosten, en vooral: wanneer het klaar is, zie het stukje over “tijd is geld” dat hiervoor weergegeven is en waar we zo nog op terug zullen komen.

Waar bestaat deze berg dan wel uit? Op zijn slechtst bestaat ze uit alsmaar voortdurende discussies over service level agreements, klachten over dienstverlening, onduidelijkheden over wat nu wel of niet tot de gemaakte afspraken behoort, escalaties omdat zaken niet naar wens worden uitgevoerd. Op zijn best bestaat deze stapel uit een berg potentie aan de kant van de leverancier die niet wordt benut. Met andere woorden: er wordt onvoldoende gebruik gemaakt van het innoverend vermogen dat leveranciers met zich mee kunnen dragen. De gedachte van een partnership – de term die bij het aangaan van een nieuw contract vaak gebezigd wordt – is nooit gematerialiseerd. We zullen straks zien dat het adequaat aanhaken van leveranciers en andere business partners een van de belangrijkste drivers is om een organisatie wendbaar te maken.

Een organisatie deed een keer een klein onderzoek op hun kennismanagementsysteem, en daar bleek een bepaald contract in 3500voud op te staan. Het aantal documenten op die systemen is enorm, en veel daarvan hebben de status: “we kijken er maar niet naar, maar we durven ze ook niet weg te gooien.”

6

Berg 8: Het elektronisch archief Een organisatie deed een keer een klein onderzoek op hun kennismanagementsysteem, en daar bleek een bepaald contract in 3500-voud op te staan. Het aantal documenten op die systemen is enorm, en veel daarvan hebben de status: “we kijken er maar niet naar, maar we durven ze ook niet weg te gooien.” Maar als iemand dé versie van het betreffende contract zou willen ophalen, dan zal hij of zijn extra werk moeten verrichten om uit te vinden welk van de 3500 versies nu de juiste is. Waar vroeger een archivaris een dagtaak had aan het fatsoenlijk ordenen van het archief, en de archetypische bibliothecaresse als een bok op de haverkist waakte over het op orde zijn van de bibliotheek, is het in de moderne kennismanagementsysteem bijna een anarchie. Nu kun je met de moderne zoekmiddelen ook in een anarchie prima je weg vinden, maar met name het versiebeheer los je daar niet mee op. Om een voorbeeld dicht bij huis te geven: het kennismanagementsysteem van Atos bevat meer dan 100.000 Powerpoint presentaties.


Nu is Atos medio 2011 van huisstijl veranderd, en je hebt die 100.000 presentaties dus eigenlijk nodig in de nieuwe huisstijl. Je moet niet denken aan de effort daarvoor nodig. Een ander voorbeeld: even verderop staat een veelgebruikt Atos model, het zogenaamde “klaverblad”. Die staat wel 10.000 keer in het systeem, maar waar is nu dé versie?

Berg 9: De berg niet gestelde vragen We kennen een organisatie waar de lijnmanagers aan het einde van de werkweek de geschreven uren moeten goedkeuren van de medewerkers die aan en rapporteren. Dat gaat via een self-service portal en dat gaat op een wereldwijde schaal, elke vrijdag weer. Nu is dat portaal zo ingericht dat de uren en de medewerkers niet op 1 scherm passen. Ofwel, je moet even naar rechts scrollen om die uren te kunnen zien, maar dan kun je de naam van de medewerker niet zien. Met andere woorden: zo’n 2000 managers over de hele wereld zitten vrijdag allemaal een stuk of 100 keer de “schuif wat naar rechts en daarna weer naar links” handeling uit te voeren. En denk je dat een van die managers ooit de helpdesk heeft gebeld om te vragen of dat niet anders kon? Ja, inderdaad, een heeft dat gedaan en het was een fluitje van een cent om het aan te passen. Maar voor die andere 1999 gold dat ze het minder de moeite vonden om heen en weer te scrollen dan om de helpdesk te bellen en een oplossing te vragen. Dat tekent de situatie van veel helpdesks, “ze helpen je toch niet”. En dat kan variëren van kleine ergernissen (na 10 minuten doet de muis van mijn laptop het steeds niet meer, maar dat los ik door hem even in een andere USB poort te steken) tot grote vormen van burgerlijke ongehoorzaamheid: we brengen die site zelf wel in de lucht, mijn buurman thuis doet in die dingen en dan is het in een week gepiept.


Waar vroeger een archivaris een dagtaak had aan het fatsoenlijk ordenen van het archief, en de archetypische bibliothecaresse als een bok op de haverkist waakte over het op orde zijn van de bibliotheek, is het in het moderne kennismanagementsysteem bijna een anarchie.

7

Phanta Rhei, Alles Stroomt

Tijd is Geld We hebben het eerder aangegeven: dé leidraad voor de Agile IT organisatie moet zijn: Tijd is Geld! Klanten vragen niet zomaar om projecten of changes. Ze doen dat omdat ze met het resultaat daarvan geld willen en kunnen verdienen. Elke dag vertraging kost hun dus feitelijk geld. De IT Organisatie moet er helemaal op ingericht zijn om zo snel mogelijk resultaat op te leveren. Het klinkt gek maar de kosten van de IT Organisatie zelf zijn daar minder van belang. De negen bergen die hiervoor zijn beschreven zijn symptomen van een organisatie die het principe “tijd is geld” niet huldigt. Al het onderhanden werk kost – direct of indirect – geld. Wachttijd is dode tijd; alles wat niet beweegt is een last die gefinancierd moet worden. Om het helemaal dramatisch te maken: diezelfde stapels die het gevolg zijn van het niet-Agile zijn van de IT organisatie zijn zelf ook een oorzaak van de inflexibiliteit. Dat is de wet van behoud van ellende: probleem A leidt tot probleem B welke weer bijdraagt aan probleem A en zo voort. Het goede nieuws is dat het andersom ook werkt: als je probleem A deels oplost, dan los je ook probleem B deels op, waardoor op zijn beurt probleem A weer verder wordt opgelost. Dat vliegwiel willen we op gang brengen, en hoe dat moet wordt hieronder beschreven.

8

Dezelfde stapels die het gevolg zijn van het niet-Agile zijn van de IT organisatie zijn zelf ook een oorzaak van de inflexibiliteit. Dat is de wet van behoud van ellende: probleem A leidt tot probleem B welke weer bijdraagt aan probleem A en zo voort. Het goede nieuws is dat het andersom ook werkt: als je probleem A deels oplost, dan los je ook probleem B deels op, waardoor op zijn beurt probleem A weer verder wordt opgelost.


Een Agile Aanpak om te komen tot een Agile IT Organisatie Stap 1: Maak de bergen inzichtelijk In deze stap worden de bergen met onderhanden werk inzichtelijk gemaakt. Hoe hoog zijn ze? Wat zijn feitelijke doorlooptijden? Wat zijn interessante cases? Plastisch gezegd: we maken een foto van het berglandschap. Kijk in hoeverre je zelf afwijkt van de gemiddelde IT organisatie die hierboven staat beschreven. Kijk eens naar de Inbox van de collega’s. Tel het aantal documenten in het kennismanagement systeem. Kijk hoeveel uren in de agenda aan kop-staart overleggen worden besteed. We hebben voorbeelden die meteen tot de verbeelding spreken. “Elke E-mail in deze organisatie wordt aan gemiddeld 2,8 mensen verzonden, waarvan 1,3 in de cc.”, “Document X staat 3500 keer op Sharepoint.”, “De langstlopende sollicitant is al zeven maanden in procedure.”, “We krijgen nu voor de vierde keer dezelfde factuur voor een tijdschriftabonnement over ons bureau”. Het in kaart brengen van de hoogtes en de aard van de negen verschillende bergen is al een heel nuttige oefening op zich, omdat IT organisaties vaak geen integraal beeld hebben van dit berglandschap. “Dat kan niet waar zijn” is vaak een eerste reactie. Het adagium “meten is weten” of de Engelse variant “What gets measured gets done.”is vaak maar al te waar. De resultaten van deze eerste stap worden vastgelegd een Powerpoint presentatie, met precies één slide per berg. Daarnaast wordt een overkoepelende slide gemaakt, die voor elke berg de twee belangrijkste indicators geeft (doorgaans de gemiddelde berghoogte en de gemiddelde doorlooptijd van stenen in de gletsjers om het maar eens zo te zeggen). Die laatste slide moet ruimte openlaten om de ambities voor de Agile IT Organisatie neer te zetten, zie stap 2.


Het adagium “meten is weten” of de Engelse variant “What gets measured gets done” is vaak maar al te waar.

Stap 3: De eerste verbetering doorvoeren

Stap 2: Ambities Bepalen en Selectie

Elk verbetertraject heeft feitelijk twee componenten. Eenvoudig gezegd: component 1 betreft het dweilen van de keuken, en component 2 betreft bij voorbeeld het repareren van de kraan. De vergelijking met het loodgieterswerk gaat bij IT organisaties in die zin mank dat we tegelijkertijd gaan dweilen en de kraan gaan repareren. Voor dat dweilen gebruiken we een prachtige Rotterdamse handen-uit-de-mouwen term: Opzoomeren. We hebben één stapel gekozen, en die gaan we nu eerst met zijn allen wegwerken.

Op basis van stap 1 zijn de eerste doelstellingen doorgaans snel af te leiden. “Een change request mag nooit ouder zijn dan 1 maand”, “De hoeveelheid mail gaan we halveren”, “sollicitanten zitten hooguit 2 maanden in procedure”, “alle facturen gaan hooguit door één hand.” Nu is de verleiding wellicht groot om een allesomvattend programma te starten om al die ambities waar te maken. Maar dat betekent weer een extra project, weer extra belasting, en weer meer achterstand. In plaats van een stap vooruit, gaan we een stap achteruit. Onze methode gaat daarom uit van wat in IT termen vaak “bootstrappen” wordt genoemd. We beginnen een klein verbeterprojectje, en de tijd die we daarmee sparen gebruiken we om een wat groter project aan te pakken, en zo voort. Welke project doen we als eerste? Dat vergt een afweging van de waarde van het besparingspotentieel en de moeite die het gaat kosten om er wat aan te gaan doen. De waarde wordt vanzelf hoger als er een directe relatie is met een klant, maar deze klantwaarde kan ook indirect zijn. De moeite die het kost om te verbeteren is nooit helemaal precies in te schatten maar dat hoeft ook niet, het is geen wetenschappelijke exercitie.

Belangrijk is dat er draagvlak gecreëerd wordt binnen de hele IT organisatie en haar klanten en partners. “We gaan Agile worden.” is de boodschap die we vaak helpen uitdragen. “We gaan focussen op het wegwerken en voorkomen van stapels onderhanden werk. Stilstand is Achteruitgang. Tijd is Geld.” Daarbij geven we concrete doelen voor de specifieke organisatie. De mooiste: vanaf tijdstip X zijn we een zeroemail bedrijf.

Welke project doen we als eerste? Dat vergt een afweging van de waarde van het besparingspotentieel en de moeite die het gaat kosten om er wat aan te gaan doen.

9

Stap 3A: Opzoomeren Opzoomeren is een term die zijn oorsprong vond in de Opzoomerstraat in de Rotterdamse wijk Het Nieuwe Westen in de deelgemeente Delfshaven. De straat is vernoemd naar de jurist en filosoof C.W. Opzoomer. De bewoners van de straat vonden in 1989 dat hun woongebied een flinke opknapbeurt kon gebruiken. Er werd met name aandacht besteed aan de veiligheid, de gezelligheid en de schoonheid van de straat. Dankzij de media, met name RTV Rijnmond en de medewerking van de gemeente Rotterdam, groeide het project snel uit tot geheel Rotterdam. Het begrip werd “opzoomeren” genoemd en deze term belandde in het woordenboek. Het opzoomeren kenmerkt zich door eigen initiatieven van bewoners in hun straat. Deze doe het zelf activiteiten zijn vooral gericht op ontmoeting en kennismaking en worden vaak gekoppeld aan praktische initiatieven gericht op bijvoorbeeld schoon of kinderen. Voorbeelden van straatactiviteiten zijn: straatdiners, spelletjesdagen, klusdagen, schoonmaakacties en straatfeesten.

Doel is dat de berg die we hadden gekozen als target voor het eerste verbeterproject daadwerkelijk is verdwenen. De ervaring leert dat deze manier van achterstanden wegwerken een schat aan informatie oplevert voor de feitelijke organisatieverbetering die we in stap 3B willen doorvoeren. Figuur 2: Het klaverbladmodel: op 4 assen dien je te verbeteren

Management & organisatie

Opzoomeren is nu precies wat we willen doen in de organisatie: het wegwerken van alle oude rommel, om zodoende de voorjaarszon weer te kunnen zien. “Zolderopruiming” is de term die we ook weleens gebruiken. Opzoomeren vraagt om een centrale groep met mandaat om te kunnen besluiten. Deze oude factuur van 124 euro? Gewoon betalen en verder sluiten. Die sollicitant van 7 maanden geleden die steeds met nieuwe vragen en wensen komt? Afbellen! Die change waar steeds maar geen ei over gelegd kan worden? Weigeren. Die wekelijkse meeting van twee uur? Halveren. Doel is dat de berg die we hadden gekozen als target voor het eerste verbeterproject daadwerkelijk is verdwenen. De ervaring leert dat deze manier van achterstanden wegwerken een schat aan informatie oplevert voor de feitelijke organisatieverbetering die we in stap 3B willen doorvoeren.

10

Processen

Prestaties

Infrastructuur

Mensen & cultuur


Stap 3B: Voer verbeteringen door

Figuur 3: Het Lean Huis Het dak: De doelstelling van verbetering

Volgens het klaverbladmodel dient er bij organisatieverandering evenwichtig aandacht te zijn voor vier assen. Dat betekent dat een eerste project verbeteringen op elk van de vier assen moet laten zien: Processen, Mensen & Cultuur, Management & Organisatie en Infrastructuur. Het aantal mogelijkheden voor verbetering is welhaast eindeloos. Hieronder staan een aantal voorbeelden van feitelijk uitgevoerde verbeterprojecten.

Implementeer een modern E-mail beleid

De kop is minder breed dan de activiteit zelf zou moeten inhouden. Deftiger gezegd: zorg ervoor dat mensen op een effectievere en efficiëntere manier samenwerken. Er zijn zelfs organisaties die als credo hebben een zero email-bedrijf te worden, omdat er veel betere manieren van samenwerken bestaan. Leg een e-mail policy vast, die banden legt aan het forwarden en cc-en van mailtjes. Zorg dat iedereen bereikbaar is via de telefoon en een berichtenservice. Zorg voor voldoende fysieke overlegcapaciteit en een gedegen alternatief voor documentenuitwisseling.

Pak de processen Lean aan

Dit is een brede oplossingsrichting die toegepast kan worden op alle processen binnen de IT organisatie . Dat geldt voor “echte” IT processen zoals die bijvoorbeeld door ITIL, BiSL en ASL zijn gedefinieerd. Maar ook voor meer secundaire processen zoals HR, Finance en Project Portfolio Management. Gebruik zoveel mogelijk standaarden. Die standaarden bevatten namelijk een zodanig rijke set aan best practices dat er eigenlijk geen reden is om ze niet te gebruiken. Elk van deze standaarden kent zijn sub-processen die stuk voor stuk aangepakt kunnen worden volgens de Lean methode, zie het plaatje van het Lean huis.


Kwaliteit

De linker pijler: Optimaal ontwerp

Levertijd

Kosten

Just in time

Jidoka

Value stream mapping

Het Lean Management ‘Huis’

Poka Yoka

De rechter pijler: Operationeel management; de implementatie

Flow en pull 5S Muda

Heijunka Visueel management en Kaizen Stabiliteit

Robuustheid - 1:3 & 3:1

Het fundament: De basis voor verbetering

Het plaatje van het Lean huis geeft een aardig inzicht in de doelstellingen van Lean. Het dak – wat willen we bereiken – wordt geschraagd door de twee pilaren: doorlooptijd en efficiency. Simpel gezegd is het minimaliseren van de doorlooptijd je doel bij het ontwerpen van de processen, en is het minimaliseren van de kosten je doel bij de feitelijke uitvoering van de processen.

Er zijn zelfs organisaties die als credo hebben een zero emailbedrijf te worden, omdat er veel betere manieren van samenwerken bestaan.

“Just-in-time” vormt de top van de linkerpilaar en dat is de logistieke zegswijze voor “geen voorraden”, “geen stapels”, het verdwijnen van de bergen die we hiervoor hebben besproken. “Value Stream Mapping” geeft aan dat inzichtelijk gemaakt moet worden waar we feitelijk waarde leveren aan de klant. “Flow & Pull” zorgen ervoor dat niets in de organisatie stilstaat en dat de beweging geïnitieerd wordt door de klantvraag. “Heijunka” betekent dat er ontworpen moet worden op een goede verdeling van de werklast. “Jidoka” betekent het automatisch inbouwen van kwaliteit. Veel stapels die we zijn tegengekomen zijn het gevolg van kwaliteitsfouten. “Zaken moet in één keer goed gaan.” Daar helpt ook “Poka Yoke” bij: het wordt simpelweg onmogelijk gemaakt om fouten te maken. En dat alles moet worden uitgevoerd zonder overbodige handelingen, ofwel “muda”. Als dan organisatorisch wordt gekozen voor het 1:3 & 3:1 principe (1 werknemer beheerst 3 taken en, 3 werknemers beheersen 1 taak) dan heeft de organisatie een waarborg ingebakken die voorkomt dat uitval van 1 medewerker acuut tot nieuwe verstopping leidt.

11

De kern van het komen tot een Agile IT organisatie zit in het ver-Lean-en van de bedrijfsprocessen. In de praktijk betekent het komen tot een Agile organisatie het achtereenvolgens uitvoeren van kleinere Lean-projecten, als een doorlopend verbeterproces, ofwel “Kaizen”. De kern van het komen tot een Agile IT Organisatie zit in het ver-Lean-en van de bedrijfsprocessen. In de praktijk betekent het komen tot een Agile Organisatie het achtereenvolgens uitvoeren van kleinere Lean-projecten, als een doorlopend verbeterproces, ofwel “Kaizen”. Die projecten zorgen voor het gewenste bootstrapeffect dat we hiervoor besproken hebben.

12

Rationaliseer het Applicatielandschap

Nu is er ook een grens aan de wendbaarheid die je met de bedrijfsprocessen kunt bereiken. Op enig moment is het niet meer de organisatie die de bottleneck vormt bij het nog verder wendbaar maken van de IT organisatie, maar de onderliggende infrastructuur. Anders gezegd: het applicatielandschap of de technische infrastructuur gaan als het goed is op enig moment de blokkerende factor zijn. Dat is een goed teken, want dat betekent dat de eerste grote barrières – de mensen, de processen, de cultuur – geen barrières meer vormen. Een behoorlijk deel van de inflexibiliteit van de gemiddelde IT Organisatie zit in de complexiteit van de applicaties. Aan de bergen werk die we hebben onderscheiden vanuit organisatorisch oogpunt kunnen we nog bergen toevoegen vanuit een meer technisch perspectief: bergen met moeilijk onderhoudbare interfaces, bergen met verouderde applicaties, bergen met aan elkaar geknoopte databases. Die vragen er op enig moment ook om om aangepakt te worden in een Agile verbeteringstraject.

Maak de infrastructuur flexibel

Een ontwikkeling die typisch sterk gedreven wordt door leveranciers is die van het denken in “the cloud”. Deze “Cloud” heeft een aantal kenmerken waarvan vanuit Agility perspectief het “on-demand”kunnen opschakelen van bij

voorbeeld database capaciteit, de belangrijkste is. Plotseling is beschikbare capaciteit in het rekencentrum geen issue meer bij het snel live trekken van een website. Plotseling is het te kort aan gekwalificeerde beheerders geen issue meer, omdat je de boel als een service afneemt. Dit biedt grote mogelijkheden voor IT organisaties om naar haar klanten toe de wendbaarheid op technisch niveau aanzienlijk te verhogen.

Voer Agile projectmanagement in

Last but not least. De term “Agile” is sterk verbonden met een nieuwe manier van software ontwikkeling, die wel Agile Project Management of Scrum wordt genoemd. En ere wie ere toekomt: het is de beroepsgroep van softwareontwikkelaars die deze manier van kijken naar de wereld hebben geïntroduceerd. Belangrijk is dat Agile veel breder is, zoals we hopelijk duidelijk hebben weten te maken. En ook Agile Project Management is breder dan Scrum ofwel breder dan softwareontwikkeling. Als in de Analyse blijkt dat de projectportfolio een barrière vorm om Agile te worden, dan is het zeer aan te raden te onderzoeken of een Agile Project Management niet te overwegen is voor de betreffende organisatie. Er wordt dan veel korter op de bal gespeeld, er wordt permanent gevraagd of het project nog wel een goede business case heeft, en de eerste resultaten komen vele malen sneller.

De term “Agile” is sterk verbonden met een nieuwe manier van softwareontwikkeling, die wel Agile Project Management of Scrum wordt genoemd. En ere wie ere toekomt: het is de beroepsgroep van softwareontwikkelaars die deze manier van kijken naar de wereld hebben geïntroduceerd. Belangrijk is dat Agile veel breder is.


Aan de slag: Wat nu te doen?

Agile werken betekent kleine stappen nemen die op zichzelf al resultaat brengen.

Figuur 4: De weg naar Agilization

Lanceer een klein project team – in Agile termen een Scrum Team – dat de opdracht krijgt in korte tijd een foto te maken van de stapels in de organisatie. Dit team dient daarbij fysiek te gaan kijken bij diverse stakeholders – medewerkers, klanten van de IT organisatie, leveranciers, HR, etc. De foto moet levendig worden gebracht en waar mogelijk worden voorzien van benchmark gegevens: “bij ons duurt het vier weken voordat we een reactie geven op een door HR aangedragen sollicitant en daarin zijn we van het hele concern de hekkensluiter.” Plan nu al een meeting waarin de resultaten van het scrum team worden besproken. In een typisch geval neemt die meeting twee uur in beslag en is het hele management team van de IT organisatie aanwezig. Zet het scrum team aan het werk en laat ze vooral hun werk doen. In de geplande terugkoppelmeeting wordt de foto van het berglandschap van de IT organisatie besproken. Gezamenlijk wordt nu voor alle geconstateerde bergen een ambitie vastgesteld, en wordt besproken wat de prioritering is van de verschillende ambities. Uiteindelijk moeten er 1 of 2 ambities worden gekozen die als eerste worden behaald. Lanceer voor elk van de gekozen ambities een Scrum Team dat gaat werken aan enerzijds het Opzoomeren, en anderzijds het implementeren van de beoogde veranderingen. Doe dat aan de hand van het plaatje van het Lean verbeterhuis. Die laatste stappen worden steeds herhaald, met korte verbetercycli van hooguit enkele weken, zie nevenstaande figuur.


3 weken

Om nu concreet aan de slag te gaan met het slechten van barrières die Agilization in de weg staan moet er het volgende gebeuren: 2A Bepalen ambities

1 Maak stapels inzichtelijk

2B Selecteer verbeterproject

3 Verbeterproject

3A Opzoomeren

3B Uitvoeren verbeterproject

3 weken

Plan nu al een meeting waarin de resultaten van het scrum team worden besproken. In een typisch geval neemt die meeting twee uur in beslag en is het hele management team van de IT organisatie aanwezig.

13

Tot slot

Het spreekwoord “Soms is de reis belangrijker dan de bestemming” gaat zeker op voor de reis naar een Agile IT organisatie. Er is namelijk geen absolute maatstaf voor Agilization. Hooguit kun je zeggen dat de ene organisatie meer wendbaar is dan de andere. Het wegwerken van al die stapels, en het zodanig ontwerpen van processen dat die stapels niet meer terugkomen, geeft een enorme stimulans aan een IT organisatie. De luiken gaan open, er stroomt zonlicht naar binnen, het is een soort van voorjaar. En dat is wat je wilt bereiken als CIO: een soepel draaiende organisatie, die verandering niet als een bedreiging ziet maar als een uitdaging.

Meer informatie Voor meer informatie kunt u contact opnemen met Robert-Jan Streng. Hij leidt het Agile Trending Topics initiatief bij Atos Consulting.

14



15

Over Atos Consulting Atos Consulting is een toonaangevende, internationale business- en IT-consultancy organisatie met wereldwijd meer dan 2.500 gedreven professionals. Atos Consulting is de partner voor klanten die zoeken naar effectieve oplossingen op het gebied van rendement, organisatie, processen en control. Zij biedt diepgaande kennis van branchespecifieke, primaire processen én van ondersteunende processen, zoals Finance, HRM en IT. Indien nodig biedt Atos Consulting ook interim management of neemt zij processen over. Daarbij neemt Atos Consulting een onafhankelijke positie in, adviseert zij deskundig en werkt nauw samen - voor en mét klanten. Atos Consulting is een zelfstandig onderdeel van Atos, een internationale IT-dienstverlener met een jaaromzet van 8,5 miljard euro. Het bedrijf biedt werk aan 74.000 collega’s in 48 landen. Atos focust op het aanbieden van zakelijke technologie die klanten vooruit helpt en in staat stelt hun onderneming van de toekomst te creëren. Atos is de wereldwijde IT-partner voor de Olympische Spelen en Paralympische Spelen en staat genoteerd aan de Paris Eurolist Market. Atos opereert onder de namen Atos, Atos Consulting & Technology Services, Atos Worldline en Atos Worldgrid.

Meer informatie: Atos Consulting Papendorpseweg 93 3528 BJ Utrecht +31 (0) 88 265 8888 [email protected]

atosconsulting.nl

Atos, the Atos logo, Atos Consulting, Atos Worldline, Atos Sphere, Atos Cloud, Atos Healthcare (in the UK) and Atos Worldgrid are registered trademarks of Atos SA.. November 2012 © 2012 Atos.

en hoe ze te slechten

Recommend Documents