De Lean-filosofie: het is niets nieuws onder de zon. Toch blijft de door Toyota ontwikkelde methode in de huidige fluctuerende economie een relevant onderwerp voor veel bedrijven. Nu managers in verschillende sectoren al hun heil hebben gezocht in Lean, begint de filosofie ook bij it-managers te leven.
Er duiken steeds vaker trainingen, papers en congressen over Lean-IT op. Dat Lean IT als ‘lastig’ wordt ervaren, is wellicht de reden dat het nu trending topic is. In de praktijk stuiten organisaties op flink wat weerstand. Waar lopen zij tegenaan?
Een veelgehoord argument: ‘Lean komt van Toyota en it maakt geen auto’s!’ Het kost de meeste it’ers moeite om de Lean-filosofie te vertalen naar een it-organisatie. Belangrijkste reden: procesgericht en klantgericht denken zit niet standaard in de genen van een it’er. Bij het toepassen van Lean in een it-omgeving ligt daar een grote uitdaging: het creëren van een klantgerichte houding en begrijpen wat de business wil bereiken in termen van verbeteringen of waarde creatie. Om it’ers op weg te helpen worden Lean-consultants ingezet, maar door het gebrek aan it-kennis en ervaring lopen zij vaak tegen een muur aan. Als je niet weet wat de it-processen zijn, hoe ze op elkaar inhaken in combinatie met een omgeving waar toch vooral aandacht is voor de it-techniek, is het logisch dat weerstand ontstaat bij het ‘strak in de leer’ implementeren van kpi-dashboards, kaizens en dergelijke.
Tot slot een niet onbelangrijk aspect: een Lean-programma levert niet zo snel de betere performance die op korte termijn noodzakelijk wordt geacht door de business. En dat wringt! Een Lean-programma is geen quick win oplossing voor het verhogen van de kwaliteit, een snellere levering en lagere kosten. Als gevolg van die druk schiet it terug in de bekende ‘brandblushouding’ die vanwege de korte termijn resultaten nog gewaardeerd wordt ook. De sleutel tot succes zit hem dan ook in de veranderaanpak die je hanteert. In mijn optiek kan een Lean-implementatie dan ook alleen succesvol zijn als nagedacht wordt over hoe de cultuurverandering in beweging gezet wordt. Daarvoor zijn drie factoren cruciaal:
Factor 1: Urgency of change
Lean-programma’s (operational excellence, customer excellence, house in order) worden vaak gestart met als einddoel een continue verbeter cultuur. Wat mij betreft een slechte reden voor een Lean-traject, want er is geen mens die gaat veranderen om het veranderen. Daarnaast is Lean slechts een middel om iets wat hoge urgentie heeft, te bereiken. Kortom: you need an urgency of change!
De wensen en verwachtingen van de eindklant, de markt en technologie veranderen continu en in een steeds hoger tempo. Als organisatie moet je in staat om zijn om snel en accuraat met die externe veranderingen om te gaan, om te voorkomen dat je op lange termijn geen bestaansrecht meer hebt. Het goed begrijpen van de klantwens en flexibel inspelen op de verschillende marktontwikkelingen kan worden gerealiseerd met een continue verbetercultuur.
Factor 2: Hot spots
Na de urgency of change voor de lange termijn, is het handig om de eerste stap te zetten op een plek in de organisatie waar een probleem ook echt wordt ervaren. Echter wel alleen in combinatie met de daadwerkelijke wil te investeren in een structurele oplossing. Uitdaging is dus het vinden van de zogenaamde ‘hot spots’, omdat dit de kans op een eerste succes aanzienlijk vergroot. Hierdoor dient een volgende ‘hot spot’ zich automatisch aan. De motivatie om continu te willen verbeteren, ontstaat hierdoor van binnenuit de organisatie in plaats van bovenaf en opgelegd. Het mes snijdt dan aan twee kanten: zelf willen onderzoeken en oplossen betekent automatisch ook verantwoordelijk voelen voor de implementatie en borging van de oplossing.
Factor 3: Guiding coalition
Tot slot moet de ‘urgency of change’ continu uitgedragen worden door een ‘guiding coalition’. Dit is een groep koplopers die bestaat uit management, medewerkers en IT-consultants met verandermanagement expertise. Zij nemen medewerkers mee in de verandering en houden vast aan het doel, ook bij beren onderweg. Zij herhalen de boodschap, stimuleren en creëren ruimte voor initiatieven en bieden kennis en hulp bij het toepassen. Houdt deze guiding coalition het niet langer vol dan een half jaar (ook bij tegenvallende resultaten of niet voldoen aan (te) hoge verwachtingen), dan ontstaat er geen grote groep volgers. Er is dan geen sprake van een cultuurverandering, maar van een projectgroep die probeert iets te verbeteren.
Lean-implementaties worden nog veel te vaak als een project aangevlogen met een kop en staart, een projectmanager als verantwoordelijke en door te sturen op het boeken van resultaten op korte termijn. Wil Lean daadwerkelijk in de genen van een organisatie komen, dan zal ten eerste een veranderaanpak gehanteerd moeten worden waarbij bovenstaande factoren centraal staan. Het management stelt de lange termijn visie op en geeft kaders mee, waarna bottom-up up de verbetermogelijkheden aangedragen en uitgevoerd worden. ‘Bezint eer ge begint’, want een Lean-traject vraagt om aandacht, geduld en vasthoudendheid over een termijn van misschien wel enkele jaren. Als dat besef ontbreekt, zullen medewerkers de bevestiging krijgen dat de Lean-implementatie iets is ‘dat wel weer overwaait’.
Dank voor jullie reacties allemaal!
@Bas: Zonder een samenvatting van het artikel te gaan geven – dubbel werk is namelijk ook niet echt Lean 😉 – is mijn kernboodschap als volgt: Meerdere wegen leiden naar Rome, zo zijn er ook meerdere wegen die leiden naar een effectievere en efficiëntere IT-organisatie. Als men besluit daarvoor Lean te omarmen, kan men niet verwachten op korte termijn op plaats van bestemming te zijn. De route bevat meerdere obstakels en om enigszins voorbereid op pad te gaan, deel ik graag mijn ervaringen. Verder is het vooral een reis die je moet ondergaan waarbij je continu reflecteert of de gevolgde koers nog leidt tot de beoogde eindbestemming.
@Nico: De term ‘Lean-IT’ doemt steeds vaker op in de media en lijkt daarmee iets nieuws te zijn of zoals jij aangeeft ‘een vervorming van Lean’. Als je echter nader onderzoek doet naar Lean-IT publicaties, zie je dat het simpelweg gaat om het toepassen van de basis principes Lean in IT omgevingen. Insteek van dit artikel is niet Lean verder te vervormen tot Lean-IT, maar toe te lichten dat het gebruik de principes van de Lean-filosofie in IT niet zo maar gedaan is.
@Felix: Veel van de basisprincipes van Agile werken komen overeen met de Lean-filosofie. De retrospective is een voorbeeld van kort-cyclisch evalueren op procesniveau: wat ging er goed en wat kan er beter tijdens een sprint? Feit is echter dat ook Agile-implementaties in veel organisaties moeizaam gaan. Ja, het iteratief ontwikkelen en elke paar weken nieuwe functionaliteit opleveren is vaak wel op korte termijn te realiseren. De werkelijke Agile mindset verandering kost echter meerdere jaren.
@Ewout: In tegenstelling tot veel productiebedrijven die vaak al tientallen jaren hun sporen hebben verdiend, zijn IT-organisaties relatief jonge organisaties. IT is ook ‘klein’ begonnen, maar juist door de internettijdperk zijn de mogelijkheden enorm toegenomen en daarmee de grootte en complexiteit van IT-organisaties ook. Vanuit dat perspectief is het eigenlijk dus ook logisch dat op een aantal gebieden IT ‘achter’ loopt. Maar waarom zou je niet gebruik maken van een bewezen methodiek in plaats van zelf het wiel opnieuw uit te gaan vinden?
@Chantal
Dank voor je reactie hoewel je erg richting de klassieke vorm van het von Neumann denken met normatief-reëducatieve kader van moderne datasynthese middels idee van het All People Seems To Need Data Processing gaat. Voor velen zal dit een stukje onnavolgbare proza zijn waarmee ik aandacht wil vragen voor het niet Turing-oplosbare probleem van de semantiek waarbij jij ook opmerkelijk makkelijk de fout bij een ander neer lijkt te leggen door te stellen dat de IT ‘achter’ loopt. Want het kort-cyclische verander de wereld, begin bij een ander van katholieke machtsdenken met de afschrijving zorgt tenslotte voor een hierarchische inertie van de koning is dood, lang leve de koning. Of het nu om koffie of computers gaat maakt dus niet zoveel uit;-)
@Ewout:
Ook Eric Ries refereert aan diezelfde klassieke OODA loop van Boyd.
Hij gebruikt het als onderbouwing voor een LEAN-based aanpak bij startups die daarmee sneller rendabel zouden kunnen zijn. In zijn boek heeft ie het overigens over Build-Measure-Learn.
Zijn aanpak gaat uit van de kleinst mogelijke functie/product/dienst dat enig rendement op zou kunnen brengen (even los van de vorm van dat rendement).
Om van daaruit over te gaan op het plannen van de Build-Measure-Learn activiteiten. Dus uitgaande van het kleinst mogelijke “Learn” resultaat gaat ie terug redeneren naar “wat-moet-ik-in-stelling-brengen-om-dat-te-halen”. Met als uitgangspunt minimale risico’s en de kortst mogelijke doorlooptijd.
Alles bij elkaar lijkt me dat nauwelijks vernieuwend omdat iedereen die zich bezighoud met een of andere vorm van proces/project/programma management, sinds jaar en dag hetzelfde doet: terugbrengen naar kleine, hapklare brokken om die vervolgens met minimale risico’s zo snel mogelijk uit te (laten) voeren.
Maar als je dat anders ziet, dan laat ik me graag bijpraten!
🙂
@Will
In het kader van Build-Measure-Learn wijs ik op de ingesleten rivierbedding van de problematiek terugbrengen tot kleine hapklare brokken, het oude idee van factorisatie blijkt namelijk steeds vaker te knellen met de schaalbaarheid van de governance. Mijn verwijziging naar de ‘situational awareness’ binnen de OODA-loop betreffende semantische informatie van de koffiemachine versus het cijferfetisjisme van excemption management met Excel on steroïds middels het All People Seems To Need Data Processing gaat om het vervangingsdenken van de koopman.
Succes heeft vele vaders maar mislukking blijft nog vaak een wees als we kijken naar de ‘fouttolerantie’ binnen het verwachtingsmanagement. Nu je weer een stapje verder bent op het schaakbord de volgende zoekstring: OODA & ToC. In het kader van Build-Measure-Learn principe gaat mijn referentie naar von Neumann om het korte termijn geheugen, ‘contextual awareness’ van patronen herkennen in een organisatie om zodoende de operationele performance te verbeteren gaat alleen om marges. De kwalitatieve discussie over prijs (red ops) in plaats van waarde (blue ops) is namelijk als besparen op de postzegel.
Maar Ewout, ook van Neumann en zijn manier van denken/werken is van het pre-internet tijdperk (i.e. medio 20-ste eeuw).
Dus samengevat, in een eerdere reactie diskwalificeer je de aanpak in het artikel als niet relevant omdat het 20 jaar te laat zou zijn. Maar in latere, twee opeenvolgende reacties kom je voor een deel met alternatieven die afkomstig zijn uit het begin van de vorige eeuw!
Waarbij ik me dan afvraag wat het punt is dat je wil maken?
Immers – als een bepaalde aanpak ook in het huidige, internet tijdperk werkt, dan lijkt me de leeftijd van die aanpak nauwelijks relevant – toch?
Iets wat je tot nu toe in minstens twee reacties bevestigd hebt. Misschien niet bewust of zo niet bedoeld – maar het staat er wel.
@Will
Resumerend wek je de indruk dat je een contextuele discrepantie probeert te bewijzen tussen appels en peren, in het kader van waardeketens ben ik inderdaad van mening dat Build-Measure-Learn cyclus niet werkt als we overwegen dat serieële denken door Internet is verworden tot een parallele ‘interconnected’ matrix van afhankelijkheden. Pak me op de semantiek maar ik geloof dat ik in eerste reactie al iets zei over idee en tijd, informatiesystemen stoppen niet bij de perimeter van het netwerk als we de juiste definitie van Enterprise gebruiken.
Ewout – ik probeer niks te bewijzen.
Ik heb in de vorm van een paar reacties getracht te begrijpen wat je bedoelde – meer niet.
@will
C’est le ton qui fait la musique.
Als je de moeite had genomen om te kijken welke twee kleuren er op het schaakbord staan dan had je vervanging en vernieuwing niet door elkaar heen gegooid, de Raines’s Rules van 20 jaar geleden hebben de ‘lenigheid’ aangaande het Business-IT alignment probleem namelijk nogal verkleind doordat BUILD is vervangen door een BUY. In dat kader heb ik de indruk dat Six Sigma ook zo’n beetje door EA is vervangen omdat juist de MEASURE in de (out)loop zo lastig is geworden waardoor eerder sprake is van MEAN-IT. Je moet het zien om het te begrijpen zullen we maar zeggen, ik heb al wat gezegd en geschreven over het economische onbehagen dat ontstaat als de kernbelangen verkwanseld zijn.
Oja, mijn stijlfiguren vragen wel wat klassieke literatuur kennis want zoals ik al stelde zit er weinig verschil tussen computers en koffie als we kijken naar het idee van factorijen om zodoende de business te schalen. De essentie van LEAN gaat om feedback, denk dat daar al een probleem ligt in de top-down benaderingen als we kijken naar de reality-tree van de zogenaamde ‘customer-driven’ benadering welke in 9 van de 10 gevallen als een discussie met de kalkoen over het kerstdiner is.
@Ewout, prachtig onderscheid die je in voorgaande reacties maakt:
“situational awareness” versus “contextual awareness”.
Het zal je niet verbazen dat mijn voorkeur beslist uitgaat naar het eerste.
Maar het levert interessante discussies op zoals hier:
http://www.researchgate.net/post/To_what_extent_we_can_differentiate_between_context-awareness_and_situation-awareness .
Een beschrijving die jou waarschijnlijk meer aanspreekt dan mij is:
https://en.wikipedia.org/wiki/Situation_awareness
gezien het feit dat onder het kopje History de door jou voorgestelde OODA-loop wordt genoemd.
Dat de beschrijving op deze wiki-pagina mij minder aanspreekt kan ik terugvoeren op één zin:
“SA can be described in terms of a holistic framework of SA Systems, States, and Processes.”
(en deze discussie hebben we al eens gehad :-).
Overigens was ik eind jaren 80 erg geinteresseerd in een beslissingsmodel dat wel enige verwantschap lijkt te hebben met de observe-orient-decide-act loop van Boyd en dat is het intelligence-design-choice model van Simon. Dit model werd door Bemelmans vermeld in zijn bekende Bestuurlijke informatiesystemen en automatisering (3de druk, 1987); om precies te zijn op blz. 2.
Onlangs kwam ik het concept context-aware al tegen in dit boeiende achtergrond-artikel van Sander Hulsman: https://www.computable.nl/artikel/magazine/5418365/5215853/computing-everywhere-wat-is-het.html ; met name de zin: “‘Context-aware’ is het sleutelwoord als het op computing everywhere aankomt”.
Tegenover context wilde ik mijn favoriete begrip ruimte zetten.
Maar jij komt met een veel beter sleutelwoord: situatie.
Besef van ruimte (veraf: de wereld, dichtbij: de woning) is één ding;
besef van de situatie waarin je verkeert is nog weer een ander verhaal
(en is overigens pas mogelijk op grond van het eerste!).