Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Lean-IT: beren op de weg naar hot spot

 

Expert

Chantal Boesveld
Lean Six Sigma Concultant, QNH Consulting. Expert van voor het topic .

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’.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5412105). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

Chantal,
Lean in IT wordt aardig beschreven in: "The Phoenix Project". Voor sommigen een aha van "Het Doel/The Goal". De kern blijft No Waste, iets wat je op je eigen tekst wellicht kunt toepassen. Wat zou je boodschap als je tachtig woorden hebt i.p.v. achthonderd?

In het artikel staat: "de door Toyota ontwikkelde methode".

In de jaren 80 van de vorige eeuw zagen Amerikanen dat Japanners alles sneller, goedkoper en vooral beter deden. Hierdoor ontstond belangstelling voor het Toyota Production System, wat dus geen methode is zoals het artikel voorstelt.
Toyota bood het TPS aan elke belangstellende aan en bood ook hulp aan. Toyota besefte hierbij dat de meeste belangstellenden - en concurrenten zoals Ford, GM en Chrysler - er toch niets meekonden omdat hun cultuur haaks stond op de cultuur die TPS nodig had om positief te kunnen bijdragen. Zoals Deming het uitte: "it would be a mistake to export American management to friendly nations".

De Amerikaanse, weinig effectieve versie van het TPS (lange termijn systeem) is Lean (korte termijn methode). En door Lean nog verder te vervormen in Lean-IT wordt het er niet beter op.

Laatste tijd lezen we steeds meer over cultuurveranderingen die nodig zouden zijn.
Of het nou gaat om Agile, business of klantgerichtheid. Dit artikel pleit voor het toevoegen van Lean aan dit rijtje.
Urgency of change maar natuurlijk wel meetbaar snel en goedkoop.
Bij Lean gaat het om al het onnodige weglaten. Dat doet de 'guiding coalition' door de Lean boodschappen te herhalen :-)
Dat gaat jaren duren, aldus de Lean expert. Kun je nagaan ..

Ik gok dat de business dan al Agile wendbaar met een nieuwe trend aan de slag is.
Het zal wel weer overwaaien.

het overbodige weglaten ... geldt dat alleen voor proces-stappen, of ook voor managers die zich overal mee bemoeien maar niets toevoegen ?

@ Pa Va Ke

Lean gaat niet alleen over processen, maar ook over mensen. Dus ja, ook mensen kunnen als 'waste' naar voren komen in een analyse. Bij de nodige reorganisaties wordt Lean als een uitstekende tool toegepast. ;)

Auteur praktiseert duidelijk wat zij predikt,
Maar geeft volgens mij heel goed aan waarom deze "afslank filosofie" door het bedrijfsleven niet wordt omarmd!

Met de zinsnede "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"

De lange termijn vraagt om enorm krachtige en duidelijke visie en overtuigingskracht. Een uiterst zeldzame bedrijfs- en overheidsfilosofie die je in Nederland nog maar weinig tegen komt tegenwoordig!

Denk dat Nico aardig de spijker op z'n kop slaat, vraag is - zoals Edward Douwes Dekker al stelde - of je jezelf kunt voeden met de spijs die een ander al gegeten heeft. De auteur heeft gelijk maar is dus 20 jaar te laat. Iemand die in haar profiel zet dat ze een grote interesse heeft in het doorgronden van patronen zou eigenlijk niet meer met pre-internet denken van de jaren 80 moeten komen maar zou OODA-loop moeten omarmen. Uiteindelijk klinkt verhaal als schaken met maar één kleur op het bord, redelijk eenzijdig dus.

Lean gaat inderdaad veel meer cultuurverandering als de veelgenoemde kreten als kostenreductie en continue veranderen. In productiebedrijven, zorg sectoren en andere organisaties waar ik mag binnenkijken zijn de laatst genoemde vaak de driver van het lean programma. Dat is jammer.
IT sector zal met name een cultuurslag moeten gaan maken en meer in dienst van organisaties gaan werken. Te vaak is IT leidend bij inrichten en ondersteunen van bedrijfsprocessen.
In 2006 is dit ook de reden geweest waarom wij vanuit de lean gedachte een IT product hebben ontwikkeld. Of beter gezegd laten ontwikkelen. We zien dat deze aanpak veel beter aansluit met de flexibele organisaties van vandaag. Als je wat meer wilt weten over de principes die wij hebben toegepast verwijs ik je naar onze blogs op www.leanforms.com
Op het komende business software event zullen wij ook een lezing verzorgen over LEAN ICT management. Inhoud gaat niet over bits en bytes of scrum maar over de organisatie (en mens) als leidende factor bij ontwikkeling en toepassing van ICT.

@Ewout:
Voor zover ik kan nagaan stamt ook de OODA loop uit het pre-internet tijdperk. Als ik via Google op zoek ga naar de geschiedenis, dan kom ik terecht bij ene John Boyd die dit concept begin jaren 60 liet opnemen in de inmiddels bekende Top Gun training. Destijds gestart als tegenmaatregel op de hoge verliezen in de gevechten tussen de Amerikaanse F86 en de Russische Mig-15 tijdens de oorlog met Korea in de jaren 50.

Dus hoewel het principe achter de OODA loop – het verkorten van de reactietijden – inderdaad goed bruikbaar is bij security vraagstukken ben je hier eigenlijk dik 50 jaar te laat mee… ;-)

Punt wat ik hiermee wil maken is dat iets en/of iemand die in het pre-internet tjdperk zijn sporen verdiend heeft niet per definitie “obsolete” hoeft te zijn in het (post?) internet tijdperk…

:-)

@Will
Je lijkt in dit geval een klassieke fout te maken, je zoekt maar met de helft van de stukken. Combineer in je zoekstring eens LEAN & OODA om een idee te krijgen van de achterliggende strategie van Eric Ries.

Factor 1: Big Urgent Market Problem (BUMP)
Factor 2: Red versus blue ocean curve (The Cost of Change)
Factor 3: Rapid Iterative Problem Solving (RIPS)

Het idee dat sommigen over LEAN hebben past niet altijd - zie Mintzberg - bij de Turing paradox van de menselijke maat omdat de normatief-reëducatieve veranderstrategie van Protestantse kerk en de machtsstrategie van de boekhouders in de Katholiek kerk nog weleens willen wringen met de Enterprise lifecycle.

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: http://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!).

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×