Lean IT gaat verder dan Agile

In de jaren ’80 van de vorige eeuw is binnen de IT, als tegenreactie op de watervalaanpak, nagedacht over methoden om het ontwikkelen van software te versnellen. Kort gezegd is de Agile-aanpak erop gericht om met een klein, multidisciplinair team, doelgericht, meetbaar en efficiënt te werken, waarbij de werkzaamheden worden ingedeeld in kleine behapbare delen (sprints). Er worden steeds korte ‘sprints’ getrokken, waarbinnen een aantal deelresultaten wordt opgeleverd. Deze (deel)resultaten worden gedeeld met de klant. Alles is gericht op produceren, en dat is ook direct waar een team op wordt afgerekend. Deelresultaten krijgen een waarde, gebaseerd op de complexiteit ervan. Een goede inschatting maken van de werkelijke complexiteit is overigens essentieel voor het slagen van een Agile-traject.

Letterlijk betekent Agile behendig, lenig, wendbaar of flexibel. Agile is eigenlijk meer een ‘paraplu’-term dan één methode of een soort framework. Ondanks dat Agile binnen de IT min of meer is ontstaan als tegenreactie op de watervalaanpak, wil dit nog niet zeggen dat ieder project per definitie in aanmerking komt om Agile aangepakt te worden. Voor eenvoudige projecten (waarbij zowel de requirements akkoord en de technologieën zeker zijn), is de voorspelbaarheid van het resultaat hoog, een voorspellende aanpak (waterval) werkt hier prima. Voor ingewikkelde en complexe(re) projecten (en voor veel IT-projecten geldt dit), is de voorspelbaarheid laag en waar een voorspellende aanpak niet of minder goed werkt, geniet een adaptieve benadering de voorkeur. Dit is waar Agile goed werkt (het gebied complex).

Ideale Agile-gebied (het gebied complex)

Het verschil tussen de Agile-aanpak en Lean IT lijkt klein. Toch zijn er wel verschillen. Lean IT, in z’n algemeenheid, gaat verder dan Agile. Lean IT biedt een breder perspectief om de Agile-aanpakken juist in staat te stellen om tot bloei te komen. De reden is dat Lean IT meer naar het geheel kijkt door de ogen van de klant (‘naar buiten’ gericht) en niet naar de individuele onderdelen door de ogen van de ontwerper of de ontwikkelaar (‘naar binnen’ gericht). Bovendien legt Lean IT, meer nog dan Agile, de nadruk op het minimaliseren van verspillingen door niet te veel te kijken naar welke hulpmiddelen en technieken daarvoor gebruikt worden. Bij degenen die Agile toepassen gaat het hierbij nog wel eens fout. Dit is niet specifiek een Agile-probleem, maar meer een algemeen probleem.

Zowel Agile en Lean IT zijn gericht op het verbeteren van de efficiëntie van een proces en een betere afstemming met de klant. Maar de aanpak, de toepassingswijze, de hulpmiddelen en technieken zijn soms verschillend:

  • Agile wordt gebruikt voor het verhogen van de snelheid van levering van informatiesystemen.
  • Lean IT wordt gebruikt voor het minimaliseren van verspilling.

Beide hanteren het principe van continue verbetering, het leveren van waarde aan de demandorganisatie en hebben zelfmanagement (empowerment) als belangrijk aandachtspunt.

Er zijn dus overeenkomsten tussen Agile en Lean IT. Zo is er zowel binnen Lean IT als Agile niets belangrijker dan het eindresultaat, oftewel het resultaat dat waarde creëert voor de demandorganisatie; een IT-service die ondersteunend is. Ook het stevig verankeren van continu verbetering is een belangrijk element.

De navolgende tabel geeft een verschillenoverzicht tussen Agile en Lean IT.

Lean IT versus Agile

Tenslotte is een Agile-werkstroom grofweg in te delen in drie fasen en kan prima worden ondersteund met hulpmiddelen en technieken vanuit Lean IT.

Agile-werkstroom in relatie tot Lean IT hulpmiddelen en -technieken

Lean IT en Agile vertonen veel raakvlakken. De ideeën zijn sterk vergelijkbaar en op z’n minst aanvullend. De gebruikte hulpmiddelen en technieken verschillen soms wel maar zijn zeker complementair. In de praktijk blijkt dat de Lean-vocabulaire (het begrippenkader) over het algemeen dichter bij de belevingswereld staat van het senior management. Een belangrijk punt van aandacht is dat het gebruik van Agile, zonder gebruik te maken van de Lean IT-filosofie, vanuit de demandorganisatie wordt beleefd als het zoveelste speeltje van IT.

Lean Management als een blijvende waarde (strategie als leidende of lijdende factor)

Lean management wordt voor veel organisaties steeds belangrijker. De reden is dat het werken aan (bedrijfs)processen in veel organisaties centraal is komen te staan. Dat wil niet zeggen dat processen de meest belangrijke factor is, maar onvoldoende grip op de processen hebben is funest in willekeurig wat aan een klant wordt geleverd.
Er geldt een belangrijk voorwaarde. Voor wie doen we het allemaal en wat wordt hiertoe als belangrijk geacht? Het antwoord is simpel: de klant en hetgeen de klant belangrijk vindt; de toegevoegde waarde!

Lean management gaat over het op een slimme manier gebruik maken van menselijke kwaliteiten en capaciteiten en het optimaliseren van processen zodat zoveel mogelijk waarde wordt gecreëerd aan de klant. Een organisatie wordt hiermee efficiënter; de mate waarin iets veel en snel resultaat heeft. Belangrijk hierbij is dat de processen zijn afgestemd op de wensen van de klant en er (aantoonbare) toegevoegde waarde wordt gecreëerd voor deze klant. Het tweede belang is dat de verspillingen in het proces wordt geminimaliseerd en er flow (doorstroming) wordt gecreëerd waarmee het ritme van het proces door (en voor) de klant wordt gestuurd.

De vijf stappen van Lean Thinking

De context

Een veelgehoorde vraag is: “als het proces optimaal is ingericht (er is sprake van een waardestroom met voldoende doorstroming), zijn we dan klaar?”. Het antwoord is eigenlijk net zo evident als de reden waarom we processen optimaliseren; nee dus! Een proces is nooit optimaal ingericht en nee, we zijn nooit klaar. De vraag die er namelijk aan vooraf is gegaan is namelijk net zo evident: “Zijn we er klaar voor?”. Het vraagt in beide gevallen een duidelijk inzicht in de situatie. Waarom überhaupt een proces optimaliseren? Indien deze vraag legitiem is (een gedefinieerd klantwaarde geeft reden tot een verbeteringsinitiatief) dan is inzicht in de huidige stand van zaken elementair om vast te stellen hoe van A (de huidige situatie) naar B (de toekomstige situatie) wordt gekomen. Op weg naar het bereiken van B (de stip op de horizon) dienen we telkens vast te stellen of we nog op de goede weg zijn, anders zullen we situatie B nooit halen……… als we deze situatie überhaupt ooit al gaan halen! Continue verbetering is dan ook het credo!

Het gaat erom het proces te perfectioneren (een stadium dat overigens nooit echt wordt bereikt).

De beperkingen

Binnen veel organisaties beperkt het toepassen van Lean management zich tot het operationele niveau. Hier is in basis niets mis mee. Per slot is de werkvloer (Gemba; de ‘echte plaats’) ook de plaats waar het werk daadwerkelijk wordt uitgevoerd en waar de waarde wordt gecreëerd, of minstens zichtbaar wordt. De omslag voor veel organisaties zit in het (h)erkennen van de aspecten teamwork en ondersteuning. De mate van verantwoordelijkheid en betrokkenheid ten opzichte van de Gemba leidt namelijk tot veel betere resultaten. De ondersteuning bestaat uit een proces waarbij accurate informatie over kosten, risico en baten van ieder voorgesteld initiatief beschikbaar is of wordt gemaakt, ter ondersteuning van de besluitvorming en de besturing. Dit is en blijft namelijk de kern van ieder organisatie. De wijze waarop dit wordt ingericht, inclusief de mate van sturing en beheersing, is vervolgens een keuze.

De Gemba-aanpak

De voorwaarden

Er gelden een aantal belangrijke voorwaarden. Deze bevinden zich op het richtinggevende niveau (de top van de organisatie) via het inrichtingsniveau (het midden van de organisatie) en de leidinggevenden richting de werkvloer. Dit kan als een proces op zich worden beschouwd. Om een indruk te geven dient iedere organisatie zich serieus een aantal vragen te stellen:

  • Strategie: wat is de waardepropositie, welke fundamentele principes worden gehanteerd, wat zijn kernwaarden, welke beleidskaders gelden, …..
  • Besturing: welke beperkingen zijn er (vanuit bijvoorbeeld governance optiek), welke structuur wordt er gehanteerd, wat is de rol van proceseigenaren, ……
  • Leiderschap: welk type managers zijn er versus het type manager dat nodig is, welke stijl wordt gehanteerd, ……
  • Teams: is er sprake van voldoende zelflerend vermogen en autonomie, wordt visueel management gehanteerd, zijn de benodigde vaardigheden aanwezig, is zelfsturing wel/niet mogelijk, ………

De conclusie

Een Lean-strategie is gericht op een langetermijnvisie en kenmerkt zich door leidinggeven op de werkvloer, wat vaak de sleutel is tot het structureel verbeteren van prestaties.

True North

Strategie-invoering stimuleert een holistische (alomvattende) focus over alle dimensies van de organisatie; dit is het principe van systeemdenken. Het fungeert als een kompas om de dagelijks activiteiten af te stemmen op de strategie. Vanuit een organisch perspectief (iets dat op natuurlijke wijze, van binnenuit ontstaat) fungeert strategie-invoering als het gedistribueerde zenuwcentrum, door het continu scannen van de omgeving op uitzonderingen, problemen, bedreigingen en kansen.

True North wordt gezien als de stip op de horizon. Dit is voor alle medewerkers bekend, betekenisvol en gedragen. Belangrijk is om True North duidelijk en concreet weer te geven zodat medewerkers en klanten weten wat de focus en het onderscheidingsvermogen is.

True North is gericht op de echt belangrijke zaken, en deze worden gemeten!

De opmaat naar Agile Service Management

Binnen veel organisaties is er een strijd gaande tussen het loslaten van de ITIL-kaders en het adopteren van de Agile-kaders. Voornamelijk het gebruik van Scrum (als ‘lichtgewicht’ Agile-aanpak) en DevOps (het behendiger leveren van IT-services; continue levering) viert hoogtij. Het is bijna zover dat wanneer je als organisatie niet Agile werkt je eigenlijk als mateloos ouderwets wordt beschouwd. ITIL is zó 2015, 2014, 2013 …. dat kan écht niet meer!

ITIL (anno nu) is als IT Service Management (ITSM) best-practice gericht op de levenscyclus van een IT-service. Op basis van strategische kaders (de nut en noodzaak om een IT-service te ontwikkelen of significant aan te passen) wordt via de fase ontwerp en de fase transitie een nieuwe of gewijzigde IT-service overgedragen naar een operationele omgeving (de fase productie). In feite ligt de kracht van ITIL in de fase continue serviceverbetering, oftewel op basis van de prestaties vanuit de operationele omgeving verbeteren van willekeurig wat wordt vastgesteld als noodzakelijke verbetering.

Praktijkconstatering 1: In veel organisaties krijgt de ontwerpfase onvoldoende aandacht en wordt er te snel een transitie uitgevoerd; we willen ‘direct’ (of in ieder geval zo snel mogelijk) van situatie A naar situatie B.

Een ontwerp richt zich op ‘het identificeren van de eisen en het vervolgens kiezen van een oplossing die in staat is om aan de eisen te voldoen’. Deze oplossing wordt vervolgens via transitie gerealiseerd (bouwen, testen en inzetten). Vanzelfsprekend is er afstemming respectievelijk samenwerking tussen degenen die zich met het ontwerp bezighouden en degenen die zich met de transitie bezighouden. Sterker nog, tijdens zowel ontwerp alsook transitie worden degenen die zich met de productie van de IT-service bezighouden (permanent) betrokken.  Dit is een van de kernitems binnen DevOps; development en operations voegen gezamenlijk waarde toe en zijn gezamenlijk verantwoordelijk.

Agile in relatie tot IT Service Management (ITSM) hanteert als best practice de navolgende uitgangspunten:

  • Klanttevredenheid boven SLA-compliance;
  • Attitude & samenwerking boven certificering;
  • Sturen op resultaat boven sturen op uitvoering;
  • Adaptiviteit boven procedures.

Agile Service ManagementAgile Service Management (Agile SM) zorgt ervoor dat de ITSM-processen de Agile-waarden weerspiegelen. De ITSM-processen zijn met “net genoeg” controle en structuur ontworpen om de IT-services effectief en efficiënt te leveren ter ondersteuning van de bedrijfsresultaten, op het moment en op een wijze waarop ze nodig zijn.

Uitgaande van hetgeen binnen Agile Service Management wordt gesteld ‘net genoeg controle en structuur’ kan het dus zijn dat op basis van een analyse binnen de CSI-fase wordt vastgesteld dat de controle en/of de structuur ‘net niet genoeg’ is! Het gebeurt namelijk maar al te vaak dat, ten aanzien van bijvoorbeeld het uitgangspunt ‘adaptiviteit boven procedures’ dit wordt opgevat als ‘we hoeven dus geen procedures (wie doet wat, wanneer en waarmee) meer op te stellen’. Dit gebeurde al met het basis Agile-uitgangspunt ‘werkende software boven allesomvattende documentatie’ en de opvatting ‘we hoeven dus geen documentatie meer op te leveren’! Gevolg is dat na de oplevering van een nieuwe of gewijzigde IT-service er vaak veel onduidelijkheden zijn binnen de operationele omgeving. Dit nog los van de herstelwerkzaamheden om ervoor te zorgen dat de controle en/of structuur wordt bijgesteld of om te zorgen dat de IT-service überhaupt goed functioneert.

Praktijkconstatering 2: In veel organisaties krijgt bij de Agile-aanpak (en in het bijzonder het gebruik van Scrum) sprint-Ø onvoldoende aandacht en ontstaat het inzicht tijdens de vervolg-/uitvoerings-sprints.

De voorbereidende sprint-Ø is erop gericht dat wordt nagedacht over de omgevingen, het team, de hulpmiddelen, de standaarden, de implementatie in de organisatie et cetera. Er moet dus flink wat worden gedaan om dit fundament op orde te hebben. Maar dit is toch eigenlijk vergelijkbaar met de fase ontwerp binnen ITIL? Hierbinnen wordt (naast hetgeen benoemd als onderdeel van sprint-Ø) de aandacht gelegd op onderwerpen zoals technologie- en management-architecturen, de benodigde beheerprocessen, de meetmethodieken en metrieken en de informatievoorziening richting de operationele omgeving.

Het ontwikkelen (en ook het verbeteren) volgens de Agile-aanpak richt zich erop om met een klein, multidisciplinair team, doelgericht, meetbaar en efficiënt te werken, waarbij de werkzaamheden worden ingedeeld in kleine behapbare delen (sprints). Dit is een vergelijkbare aanpak zoals dat binnen ITIL voorkomt in de vorm van een release unit en/of een release package.

Agile Service Management definieert naast de product backlog een proces backlog. Deze combinatie is vergelijkbaar met het CSI-register zoals binnen ITIL gedefinieerd. Er worden drie basistypen sprints onderkend: een strategische sprint, een procesactiviteit sprint en een CSI sprint en vanzelfsprekend kunnen hier combinaties in worden gemaakt.

Agile development

Bij CSI (continual service improvement) staat de drive om processen effectiever en efficiënter in te regelen centraal, door bijvoorbeeld het meten en het evalueren van de bevindingen van een IT-service. Door CSI toe te passen wordt inzichtelijk wat het effect is van een IT-service en hoe deze IT-service wordt ervaren door de klant/gebruiker. Het is belangrijk dat er, nadat een IT-service is geoperationaliseerd, er voortdurende verbeterslagen worden uitgevoerd. Kijkend naar de kerndoelstelling van CSI ligt hier de essentie van het hebben van een vliegwiel voor verbeteringen (het vullen van een Backlog met verbeterinitiatieven op ofwel het product of op een proces). Dit is een Kaizen-systeem, daar waar verbeteringen in het ene (deel)proces consequenties heeft voor de gehele waardestroom en bijdraagt aan het creëren van waarde voor de klant/gebruiker.

Praktijkconstatering 3: In veel organisaties wordt CSI nog te weinig toegepast en is er onvoldoende aandacht voor continue verbetering en het meten en evalueren van de bevindingen van een IT-service.

Continue serviceverbetering dient te beschikken over de mogelijkheden om een positieve invloed te hebben op alle niveaus van het management om ervoor te zorgen dat het verbeteren de nodige steun ontvangt en voldoende middelen beschikbaar heeft om oplossingen te implementeren. CSI in ITIL gaat overigens pas echt leven als het wordt ondersteund door een bedrijfsbrede filosofie, zoals Lean IT. Bestaande verbeterinitiatieven worden dan gestroomlijnd zodat er in de organisatie een doorstroming wordt bereikt of wordt behouden.

Samenhang

IT-service ontwikkelwerkzaamheden zijn zonder problemen op een iteratieve en incrementele wijze (volgens een agile-aanpak) uit te voeren. Sterker nog, dit wordt onderbouwd door een zeer interessante beschrijving in het ITIL-boek Service Design (TSO, ISBN 9780113313174), paragraaf 3.1 Service Design Basics op pagina 35.

Wanneer services of processen niet worden ontworpen, dan zullen ze zich organisch ontwikkelen. Als ze zich ontwikkelen zonder de juiste controles dan is de tendens gewoonlijk om op de omgevingscondities te reageren die zich voordoen, in plaats van de visie en de bedrijfsbehoeften werkelijk te begrijpen.

Ontwerpen om te voldoen aan de verwachte omgeving is veel effectiever en efficiënter, maar vaak onmogelijk – vandaar de noodzaak om een iteratieve en incrementele benadering van service ontwerp te overwegen. Een iteratieve en incrementele benadering is van essentieel belang om ervoor te zorgen dat de IT-services die naar de productieomgeving worden overgezet, zich voortdurend zullen aanpassen in lijn met de veranderende bedrijfsbehoeften.

IT-services ontwikkelen zich in de loop van de tijd. Tijdens de ontwerp-fase/sprint-0 wordt bepaald wat er in de eerste release van de IT-service (vanuit strategisch perspectief) opgeleverd dient te worden. Vervolgens worden tijdens de geplande vervolgreleases (hierbinnen worden de sprints uitgevoerd) nieuwe IT-service functionaliteiten toegevoegd alsook verbeteringen aangebracht op basis van de bevindingen vanuit de fase productie. Van daaruit wordt middels de vervolgreleases (op basis van het uitvoeren van sprints) naar ‘perfectie’ toegewerkt; een combinatie van nieuwe en vernieuw(en)de functionaliteiten en verbeteringen.

Voor het plannen van de diverse werkzaamheden (zowel ontwerp, ontwikkel en operationele werkzaamheden) is Kanban (het visualiseren en reguleren van de workflow) uitstekend geschikt.

Agile Service Management overview

Conclusie

Het is een utopie te denken dat een IT-service ‘in een keer goed’ is. Het ontwerpen en ontwikkelen van een IT-service zal zich dan ook altijd in een groeipad afspelen. Het incrementeel en iteratief ontwikkelen is dan ook een logisch gevolg. Afhankelijk van de noodzaak zal, door een klein, multidisciplinair team, in de vervolgreleases, op basis van het uitvoeren van sprints (strategische, procesactiviteit en/of CSI) telkens naar een nieuwe situatie toe worden gewerkt, in goed overleg met de klant/gebruikers.

Het zit niet in de raamwerken, de best-practices en/of de hulpmiddelen maar in de wijze waarop wijzelf als mensen er mee omgaan; de mindset (de manier van denken) en de cultuur.

Het gaat om gezond verstand en slimmer werk…… ‘het zit tussen uw eigen oren’!

Dit alles vraagt, ook binnen snel veranderende omstandigheden, nog steeds een serieuze afweging en overweging welke (combinatie van) aanpak het beste past, binnen de beschikbare mogelijkheden en middelen, rekening houdend met de huidige (organisatie)situatie.

Ik wens u veel Agile, Scrum, Kanban, DevOps, Lean IT en ITIL wijsheid……. En ik hoop in een goede combinatie en verstandhouding; ‘het een laat namelijk het ander niet onverlet’!

Er is altijd wel iets te verbeteren!

Veel organisaties zijn druk met allerlei projectgerichte aanpakken ter ondersteuning van veranderingen en ontwikkelingen in de organisatie. PRINCE2, Scrum, AgilePM, DevOps vliegen als warme broodjes over de ‘(veranderings)toonbank’. Iteratief en incrementeel werken lijkt vandaag de dag meer een vanzelfsprekendheid dan een expliciete keuze. Op zich niets mis mee, mits het ook daadwerkelijk een bewuste keuze is.

Wat we bijna zouden vergeten is dat veel van de werkzaamheden die we als project (of projectmatig) uitvoeren, meer met (proces)verbetering te maken hebben dan met veranderen. Veranderen ligt veel meer in lijn met innovatie (vernieuwing) terwijl verbeteren (door te leren) uitgaat van een bestaande, operationele situatie.

Veranderen versus verbeteren

Continu veranderen is iets anders dan continu verbeteren. (Continu) veranderen (ervoor zorgen dat iets niet hetzelfde blijft) veroorzaakt in de meeste organisaties (per definitie) voor de nodige onrust. Wanneer continu verbeteren leidt tot (of wordt ervaren als) ‘continu’ veranderen, dan is het dubbel op! Dit betekent dat er duidelijke doelstellingen nodig zijn op basis van heldere, eenvoudige en begrijpelijk gestelde doelen om succesvol en blijvend te verbeteren. Belangrijk hierbij is dat verbetering afkomstig dient te zijn vanaf de werkvloer (op basis van het bestaande) en verandering eigenlijk iets is om strategische doelen te behalen (gericht op de toekomst).

…… herstellen!

Naast veranderen en verbeteren is er een derde ‘variant’ en dat betreft ‘brandjes blussen’ (trouble shooting). Vaak wordt dit gezien als dé aanpak voor (operationele) problemen. De aanpak is er echter op gericht om vanuit klantnoodzaak naar een bekende, vertrouwde status terug te keren; het oplossen van ‘problemen’ die leiden tot underperformance. Het uiteindelijke resultaat is echter zelden vooruitgang maar eigenlijk altijd herstel.

Veel problemen (en afwijkingen) zijn het gevolg van discrepanties in de huidige werkwijze ten opzichte van hetgeen is bedoeld. In veel gevallen is er, na de herstelactie, geen vervolg, oftewel een onderzoek naar de grondoorzaak waarom de situatie (het probleem) überhaupt is ontstaan. Dit zijn dé uitgelezen situaties voor een continue verbeteraanpak. Voorwaarde is wel een parallelle (verbeter-)cultuur, waarbij iedereen streeft naar perfectie door continue verbetering.

Verbetertheorieën en -modellen

In de literatuur zijn veel verbetertheorieën en -modellen te vinden. De focus daarbij ligt op het verbeteren en het optimaliseren op basis van kwaliteit en klantwaardering. Hiermee wordt verzekerd dat men zich focust op het continu verbeteren van de mogelijkheid om (klant)waarde te leveren.

Een veel gehanteerd verbeterprogramma betreft Lean Six Sigma. De praktijk leert echter dat voor veel organisaties Six Sigma een (behoorlijke) brug te ver is. Het ‘gescheiden’ gebruik, of alleen Lean, levert in de praktijk dan ook vaak betere resultaten op.

Lean Six Sigma
Weghalen van verspilling uit de keten. Minimaliseren van variatie.
Focus op doorstroming. Focus op problemen.
Resultaat is het reduceren van doorstromingstijd. Resultaat is uniforme procesoutput.

In feite zijn het beiden verbeterprogramma’s met als centraal thema continous inprovement (continue verbetering) & problem solving (het oplossen van problemen). Er is een scala aan hulpmiddelen en technieken die ter ondersteuning, in combinatie wordt gebruikt.

Six Sigma leent zich vooral voor het oplossen van complexe (kwaliteits)vraagstukken, waarbij de oorzaak van het probleem niet direct voor de hand ligt. Centraal staat de kwaliteitsverbetering van de resultaten van bedrijfskundige processen door de oorzaken van defecten en fouten te ontdekken en te verwijderen. Hierdoor kan de variatie in de processen worden gereduceerd.

Lean Management (dus niet Lean Manufacturing/Production) zorgt ervoor dat verbeteringen in de processen binnen een organisatie in een beheersbaar, gesynchroniseerd tempo verlopen en is gericht op het leveren van klantwaarde. Hierbij wordt gebruikgemaakt van diverse hulpmiddelen en technieken om het doel, het leveren van waarde aan de klant, aan te laten sluiten op de processen en de mensen.

Lean IT is een voorbeeld van een verdere doorontwikkeling van Lean Management; een verlenging van de principes van Lean, toegepast op een IT-omgeving. Lean IT gaat vooral over servicegerichtheid en het creëren van klantwaarde waarbij twee kernwaarden gelden: vertrouwen en samenwerking.

Naast de twee hierboven vermelde verbeterprogramma’s (Lean & Six Sigma) kennen we ook de verbeterprogramma’s Kaizen en Theory of constraints.

Kaizen Theory of Constraints
Verbeteren in kleine stappen. Maximaliseren van de output.
Focus op continu verbeteren. Focus op systeem beperkingen.
Resultaat is verbeterde stabiliteit. Resultaat is snelle(re) doorvoer (throughput).

Kaizen A

Kaizen heeft specifiek betrekking op de continue verbeteractiviteiten (kleine, incrementele en frequente verbeteringen); ‘change for the good’ respectievelijk Kai = veranderen, Zen = naar het goede. Uitgangspunt bij Kaizen is dat veel kleine verbeteringen op lange termijn tot een grote verbetering leiden. Kaikaku (systeem Kaizen) is de radicale variant. Radicale verbeteringen (soms een ‘verandering’) die snel zorgen voor grote verbeteringen. Kaikaku wordt soms ook wel ‘break-through Kaizen’ genoemd die wordt geïnitieerd vanuit het senior management, terwijl Kaizen zich afspeelt op het niveau van de teamleden (de medewerker) en op z’n hoogst op het niveau van het middenkader.

Kaizen versus KaikakuImprovement

Theory of constraints heeft specifiek betrekking op het verbeteren van de doorlooptijd, door de bottlenecks of beperkingen op te heffen. Binnen de theorie is de stelling dat er in elk proces knelpunten zijn, knooppunten van deelprocessen die gepasseerd dienen te worden alvorens de volgende deelprocessen in gang gezet worden. Hierdoor ontstaat er een plafond voor de capaciteit. Een bottleneck (knelpunt) is een proces dan wel processtap die voor het hele voortbrengingsproces de beperkende factor is. De bottleneck blijkt vaak met eenvoudige middelen op te lossen. De theorie wordt wel gezien als dé aanpak waarbij de mens centraal staat! Het kernpunt is, dat je goed kijkt welke bottlenecks verhinderen dat er optimaal wordt geproduceerd. Bij procesmanagement (maar ook projectmanagement) is dat vaak de inzet van de medewerker en de optimale inzet van deze (schaarse) medewerker.

Waarom processen verbeteren?

Processen maken of breken elke organisatie. Geen proces? Geen organisatie. Geen slim proces? Ontevreden klanten en vaak een verliesgevende business.

Omdat processen belangrijk zijn, is het raadzaam te kijken naar wat er verbeterd kan worden, zeker wanneer:

  • er meer handelingen buiten het proces om worden afgehandeld dan binnen het proces;
  • de processen te lange doorlooptijden kennen en de klant dit niet langer accepteert;
  • er veel verspilling is van capaciteiten, lange wachttijden of te hoge werkvoorraden.

Een proces is niets anders dan een geoperationaliseerde werkwijze: een serie activiteiten die meestal door meerdere mensen achtereenvolgens worden uitgevoerd en mensen blijken nog steeds de grootste bottleneck!

Als je niet tevreden bent over hoe een proces loopt, dan moet je iets aan het proces veranderen.

De Lean IT organisatie (volgens Gartner)

‘De organisatie bereikt weinig met Lean IT wanneer medewerkers niet energiek zijn en veranderingen niet goed aankunnen!’

Lean DruppelEr ontstaat meer en meer een organisatie vanuit het perspectief dat er meer middelen op het middenniveau (tactisch/inrichten) dan op het laagste niveau (operationeel/verrichten) ontstaan. Het laagste niveau bevat middelen van ofwel technologische diensten of andere dienstverleners. De ‘lichtere’ technologieën zoals Cloud en SaaS vragen een centralisatie van IT verantwoordelijkheid op het creëren van productiviteit en capaciteiten ter ondersteuning van de strategie met als uitdaging een concentratie van interne resources op het realiseren van toegevoegde waarde in een multi-sourced omgeving.

Het voorgaande kan als ‘lean’ worden aangeduid vanuit het perspectief dat de ICT-organisatie zich concentreert op de essentiële rol die nodig is om waarde te leveren aan de organisatie. De groepen die het beste in staat zijn om de activiteiten (de processtappen) uit te voeren ten aanzien van de specifiek te leveren diensten, zonder dat sprake is van doublures of verspilling, spelen hierbij een belangrijke rol.

Eea is het beste als volgt te onderscheiden:

Gartner - Lean

  • Een CIO en technologisch leiderschapsgroep die verantwoordelijk is voor de strategie, de uitvoering, de architectuur, het risicomanagement en het beheer van het beleid.
  • Een expertisecentrum gericht op business-processen en de centrale rol van IT in procesverbetering, inclusief aandacht voor implementatieaspecten vanuit Six Sigma en lean thinking (A).
  • Een expertisecentrum met verregaande analytische vaardigheden en hulpmiddelen ter ondersteuning van het vergroten van de strategische en operationele waarde van informatie (B).
  • Een agile ontwikkelgroep gericht op nieuwe toepassingen in antwoord op specifieke business eisen en behoeften, waar niet gemakkelijk aan kan worden voldaan door outsourced partijen (C).
  • Een gericht en professioneel service- & vendor management ter ondersteuning van complexe multi-sourced partnerrelaties.

Lean IT is een innovatieve methode om de productiviteit en de capaciteiten voortdurend te verbeteren. Dit geldt ook voor de kenniswerker binnen de IT organisatie. In de IT dienstverlening wordt deze kenniswerker gevraagd om in minder tijd met een oplossing te komen. Processtappen die dan ook geen toegevoegde waarde hebben en dus nutteloos zijn, dienen uit het proces geëlimineerd te worden. Er wordt gestreefd naar perfectie: excelleren in continu verbeteren.
Er wordt vaak onevenredig veel gevraagd van de medewerker, maar ook van de manager. Medewerkers dienen evenwel  gestimuleerd te worden om zich in te zetten voor systematische oplossing en innovatie. De managers coachen hen daarbij, in een organisatiecultuur die gericht is op procesverbetering op dagelijkse basis.
De kunst zit in het voorkomen van een ‘energielek’. Energie is de basisvoorwaarde om productief te zijn en om goed om te gaan met de eisen van de klanten. De menselijke energie is een essentiële resource binnen de organisatie. Helemaal wanneer het gaat om een kennis- en service-intensieve organisatie.

Lean IT is véél meer dan een nieuw speeltje binnen IT

In de afgelopen periode hebben veel vragen mij bereikt over Lean IT. De strekking hiervan is eigenlijk steeds dezelfde: oh, dat klinkt weer als de zoveelste IT-ontwikkeling!

Niets is minder waar: met het begrip IT, in relatie tot Lean IT, wordt zowel het IV-domein als het IT-domein bedoeld, oftewel hetgeen specifiek is gericht op bedrijfsinformatie alsook hetgeen is gericht op de ondersteunende technologie.

Voor veel mensen heeft het begrip IT betekenis in enge zin. Veelal wordt IT alleen in een technologisch perspectief beschouwd. Deze engere betekenis is gericht op het informatiesysteem of specifieke onderdelen daarbinnen, in de zin van technische infrastructuur of applicatie(onderdelen).

Eigenlijk hebben we het over Lean Management toegepast in een IT-omgeving.

Lean IT is in het bijzonder bedoeld voor organisaties die zich bezighouden met het managen van bedrijfsinformatie (information management) en het managen van ondersteunende technologie (information technology). Binnen dit totale werkveld van besturing en beheersing wordt een aantal kaders gebruikt. Het totaal betreft alle activiteiten die nodig zijn voor adequate informatievoorziening, ter ondersteuning van de bedrijfsvoering van een organisatie. Hieronder vallen twee domeinen:

  • Het IV-domein (informatievoorziening in casu de informatisering). Binnen het IV-domein gaat het specifiek om informatie als ondersteunend middel voor het bedrijfsdomein. Hier wordt de vraag naar informatievoorziening vertaald in een vraag naar IT.
  • Het IT-domein (informatietechnologie in casu de automatisering) ter ondersteuning van de bedrijfsvoering van een organisatie. Binnen het IT-domein gaat het specifiek om de ontwikkeling en exploitatie van de IT.

Lean IT is véél meer dan een nieuw speeltje binnen IT.

De basis voor optimalisatie (continue verbetering), bezien vanuit de optiek van Lean IT, is een solide en stabiele IT-omgeving.

De IT-omgeving is ondersteunend voor het leveren van de benodigde IT-services, volgens bepaalde criteria zoals: consequente beschikbaarheid, veiligheid, betrouwbaarheid en capaciteit, de juistekwaliteit tegen de juiste kosten. Een solide en stabiele IT-omgeving omvat alles van deinformatietechnologie en het managen van de bedrijfsinformatie, inclusief de betrokken mensen, processen en documentatie. Dit vormt dan ook het totale gespecialiseerde vermogen voor het leveren van de benodigde informatievoorziening en geeft daarmee het kader voor het ontwikkelen en managen van de supply organisatie.

Lean IT gaat niet zozeer over de technische IT-processen, maar vooral ook over het verbinden van mensen, gebruikmakend van een kader van principes en ondersteunende instrumenten (hulpmiddelen en technieken), om de supply organisatie te integreren en op lijn te brengen (alignment) met de demand organisatie. Het doel van Lean IT is om kwalitatieve informatievoorziening en effectieve informatiesystemen te bieden waarmee toegevoegde waarde wordt gecreëerd vanuit het perspectief van de demand organisatie. Hiermee wordt de continue verbetering en innovatie van bedrijfsprocessen mogelijk gemaakt en ondersteund.