Er zijn inmiddels aardig wat hectare bossen geveld en ook vele GB aan opslag gevuld met het beschrijven van wat genoemd wordt het 'Toyota Production System' (TPS), beter bekend als 'The Toyota Way'. Dit is een systeem gebaseerd op veertien principes om verspillingen te elimineren. Hierdoor gaat de kwaliteit omhoog en gaan de kosten omlaag, wat leidt tot een verbetering van het resultaat. Iets voor in de ict? Onze expert van het topic ICT-branche aan het woord.
Leendert Hinds, directeur, Hints Company
Het is natuurlijk duidelijk dat het implementeren van principes, zoals denk op de lange termijn, zorg dat je geen overschotten produceert, stop om problemen direct op te lossen met de betrokkenen, etc., in de ict niet gemakkelijk is. Dit vanwege het feit dat in de praktijk in de ict-branche vaak naar oplossingen wordt gezocht en gevonden die tegengesteld aan de principes zijn. Natuurlijk worden er goede beslissingen genomen en worden projecten succesvol afgesloten. Sommige bedrijven investeren wel in mensen, hanteren een 'open deur'-beleid, evalueren voortdurend het productieproces, laten medewerkers meedenken in het verbeterproces, etc. Ondanks alle inspanningen is het nog niet 'The Toyota Way'. Dit kan ook niet, aangezien een cultuur onmogelijk in enkele tientallen jaren gevormd kan worden.
Edwin van Asch, solution architect, Systemation
De vergelijking tussen 'The Toyota Way' en de ict gaat niet altijd op. Toyota maakt standaardproducten: auto's. De meeste ict-projecten leveren een eenmalige maatwerkproduct en dat is wat anders dan een serieproduct. Een aantal principes zijn uiteraard wel bruikbaar. Een groot probleem zit in 'Use only reliable, thoroughly tested technology'. Als er iets is waartegen de ict-branche vaak zondigt, dan is het dit. Een complex ict-product bestaat uit zoveel onderdelen die op hun beurt niet allemaal 'reliable, thoroughly tested' zijn en daarom is het eindproduct dat vaak ook niet. Een deel van de oplossing: een gedegen testaanpak gebaseerd op geautomatiseerd regressietesten.
Gert Jan Timmerman, manager Kenniscentrum, Info Support
Naar mijn mening wordt er in de ict-branche met name gezondigd bij het principe 'Standardized tasks and processes are the foundation for continuous improvement and employee empowerment'. Er zijn veel organisaties die geen gestandaardiseerde werkwijze hanteren, waardoor men telkens opnieuw het wiel probeert uit te vinden en (dezelfde) fouten keer op keer gemaakt worden. Om ict-projecten beheersbaar te houden op aspecten als doorlooptijd, kosten en kwaliteit, is een standaardwerkwijze absoluut noodzakelijk. Dat is namelijk de enige manier om opgedane ervaringen (lessons learned) op een structurele manier te borgen.
Deze gestandaardiseerde werkwijze heeft niet alleen betrekking op projectmanagement, maar ook op andere disciplines, zoals architectuur, requirements management, analyse, design, bouw en testen. Pas wanneer een organisatie op al deze terreinen standaarden en richtlijnen heeft geformuleerd die ook gebruikt (en afgedwongen) worden, ontstaat de mogelijkheid voor continue verbetering, een essentieel onderdeel van 'The Toyota Way'.
Jos Struik, directeur, Dataccent
De problemen in de ict-markt hebben vooral te maken met de dynamiek van de snelle veranderingen in de ict en het gebruik ervan in de praktijk. Daardoor ontstaat vooral focus op de lopende projecten en problemen. Als daarnaast de verantwoordelijk ict-manager een soort van meewerkend voorman is, dan verlies je al snel die lange termijn uit het oog. In grote organisaties kun je dat oplossen door een scheiding tussen beleid en uitvoering, door bijvoorbeeld op organisatieniveau een cio of informatiemanager aan te stellen die zich niet zo zeer met de dagelijkse sores bemoeit. Voor kleinere organisaties is die scheiding moeilijker te maken, maar zou bijvoorbeeld de algemeen of financieel verantwoordelijk manager die langetermijnrol op zich kunnen nemen.
Erik Smits, managing consultant, DIKW Consulting
Het grote verschil tussen de ict-branche en de automotive-branche is de consensus die bestaat over het eindproduct en de verwachting die betrokkenen hebben. Een auto biedt de mogelijkheid tot mobiliteit. Dat is zowel in het productieproces als bij het zoeken naar de juiste aanschaf duidelijk. Voor een ict-product of -dienst is het lang niet altijd duidelijk welke functie dit heeft en welke toegevoegde waarde wordt geboden aan de bedrijfsvoering. De effectieve en efficiënte inzet van ict staat of valt bij overeenstemming over de toegevoegde waarde bij alle betrokkenen. Start dus niet met een project of schaf geen ict-producten aan als dit vooraf niet 100 prpcent duidelijk is.
Harold van Heeringen, consultant metrieken, Sogeti Nederland
De vergelijking tussen de fabrieksmatige realisatie van auto's en software gaat op een aantal punten zeker wel op. Ook binnen de grote softwarehuizen wordt 'fabrieksmatig' ontwikkeld. Een aantal zaken zouden 'The Toyota Way' kunnen worden ingericht, alleen heeft de ict-sector een aantal specifieke 'problemen' waardoor niet alle principes opgaan, zoals de klant bepaalt wie de productie mag doen en de verschillende leveranciers die per project tegen elkaar opbieden. Dat veel softwareprojecten falen (dus veel verspilling opleveren) ligt aan twee belangrijke zaken:
1. Veel (maatwerk) systemen zijn slecht gedocumenteerd. 'The Toyota Way' zou ook in de automobielindustrie slecht werken, als niet het product tot op de punt nauwkeurig zou zijn gespecificeerd. In de ict wordt vaak te weinig tijd besteed aan requirements analyse en wordt meestal te snel gestart met de realisatie. Dit leidt tot onnodige verandering tijdens het project en soms zelfs tot ontevreden gebruikers na oplevering. Dit is een typisch voorbeeld van onnodige 'waste'.
2. Men baseert een projectbegroting vaak alleen op input van experts. Dit leidt tot onrealistische begrotingen en het project zal vrijwel zeker falen (qua kosten, doorlooptijd en/of kwaliteit). Ook dit is een duidelijk voorbeeld van onnodige 'waste'. De onderhoudbaarheid van de code (langetermijnvisie) neemt in dit soort projecten enorm af. Veel beter is het om naast de expertbegroting een top-down begroting te maken op basis van omvang en ervaringscijfers.
John Roos, project-/programmamanager, JHERoos Projectmanagementadvies
De principes lijken op de key performance-indicatoren die horen bij het beoordelen van de volwassenheid van een organisatie. Een volwassen organisatie faciliteert project- en programmaorganisaties. Daar is onderzoek naar gedaan (Pricewaterhouse Coopers, april 2008). Het is aantoonbaar dat (ict-)projecten in een volwassen organisatie beter presteren.
Helaas blijkt ook uit het onderzoek dat de vierhonderd onderzochte bedrijven gemiddeld op het volwassenheidsniveau 1 zaten en dus niet gestandaardiseerd werken. Dit verklaart mogelijk de hoge percentages van mislukte projecten. Mijn mening en stelling is dat bij een volwassenheidsniveau van organisaties op niveau 3 en 4 het mislukken van het project tot meer dan 50 procent gereduceerd kan worden en de voorspelbaarheid van het projectsucces wordt vergroot. Deze voorspelbaarheid of volwassenheidsmeting zou een vast onderdeel moeten worden als toetscriteria bij de business case, die overigens maakbaar is.
Op dit moment merk ik een zeer ernstige ontwikkeling, dat het beter doen van projecten/programma's nog verder van ons ideaal brengt. De kwaliteit wordt van een project/programma niet door de opdrachtgever bepaald maar door inkoop. Deze kijkt niet naar kwaliteit maar naar de prijs. De opdrachtgever heeft geen invloed en wordt nu geconfronteerd met beperkte budgetinstructies, met als gevolg dat de A-project- en programmamanagers vervangen worden door een B-categorie of PM-studenten na een cursus projectmanagement. Het lijkt dat goedkoop nog meer duurkoop wordt.
Experts gezocht
Computable is bezig om al zijn 25 topics te voorzien van een expertpanel. Voor de komende tijd zijn wij op zoek naar experts op de volgende vakgebieden:
Besturingssystemen: besturingssystemen@computable.nl
Beleid: beleid@computable.nl
Maatschappij: maatschappij@computable.nl
eHRM: ehrm@computable.nl
Internet: internet@computable.nl
Ben jij expert op een van bovengenoemde vakgebieden, stuur dan een e-mail met je gegevens (naam, functie, bedrijf, werkzaamheden) naar het bijbehorende e-mailadres.
Een mooie verzameling meningen over de mate van volwassenheid van de ict-branche. De mening dat je voorzichtig moet zijn om software development te vergelijken met massa productie deel ik zonder meer. Echter gaat “De Toyota way” niet alleen over massa productie, maar ook over New Product Development; waarom kan Toyota nieuwe modellen sneller ontwikkelen en in de markt zetten dan concurrenten. Overigens sluit dit niet uit dat met name alle herhaalbare stappen in een development proces zoveel mogelijk gestandaardiseerd (en wat mij betreft ook geautomatiseerd) moeten worden -> hier zijn dan wel weer de massa productie principes van toepassing.
De kop van dit artikel sluit echter niet aan bij de strekking van (de meeste) gegeven meningen en zet een toon die maakt dat je de meningen al met een bepaalde vooringenomenheid leest (afhankelijk aan welke kant je van het Lean / Agile spectrum zit). Juist in deze voor ICT moeilijkere tijden is menig bedrijf klaar om ‘iets anders’ te doen. Dat ‘iets anders’ kan heel goed de Toyota way principes omarmen.
TPS wordt helaas in de ICT-branche maar al te vaak
gebruikt als 1 op 1 voorbeeld uit de auto industrie!.
Je krijgt dan maar al te vaak onnodige stressvolle situaties waar de ICT werknemer elke 5 minuten, wordt gemonitoord,in een daarvoor speciaal ingerichte tijds applicatie, zo kan een verblijf op het Toilet bijvoorbeeld al voor verbetering vatbaar zijn.Dit zou dan rapportages moeten waarbij het management dan een goed beeld zou krijgen van de effectiviteit van de werknemer. In Japan is dit wellict aan de Orde, Maar hier in Europa hebben wij dit Echt niet nodig, voor mij geen Toyota als nieuwe auto !.
Het mooie aan TPS is juist dat het helemaal niet interessant is of er auto?s geproduceerd worden of software. Het is geen ‘best practise’. Het gaat om de principes en deze zijn allemaal universeel geldig, ook binnen de ICT.
Juist omdat TPS geen voorschrijvende methode is is het van belang om de principes in essentie te begrijpen en toe te passen. Hier zit ook meteen het grootste gevaar. Bij verkeerd gebruik richt je meer schade aan dan dat je goed doet.
Als je begint met het timen van het toiletbezoek, zoals hierboven wordt beschreven, kun je beter maar stoppen met TPS. Er zit honderden malen meer ‘waste’ in de bestaande processen en werkwijzen. Ook suboptimalisatie is naar mijn mening een groot gevaar. We optimaliseren nog steeds ‘eilandjes’ zoals ontwerp, bouw en test.
Als ik naar de meningen van de experts kijk zie ik dat vaak de fout wordt gemaakt om TPS te mappen op de huidige werkwijze. “TPS is in de ICT lastig toe te passen want…” Dat is nu juist het punt! Er is niet mis met TPS, er is blijkbaar iets mis met de huidige werkwijze!
Het is dan ook niet zo dat de ICT niet klaar is voor TPS. De wil om te veranderen is er niet. Alles staat of valt met de wil om te veranderen.
Ik vraag me al geruime tijd af waarom deze wil ontbreekt. Mijn voorlopige conclusie: We zijn vergeten dat alles dient te draaien om de waarde die we leveren aan de klant. Dit is overigens wat mij betreft met stip TPS principe nummer 1. Als iets geen directe waarde levert voor de klant is het in potentie ‘waste’. En dat is best bitter als je, zoals ik, een software tester bent. Denk daar maar eens over na 😉
‘The Toyota Way’? Dat heette vroeger Lean en als je daar op Googlet kom je een zooi ellende tegen. Op zich zitten er goede dingen tussen, maar pas heel goed op. Het is een systeem voor massa productie en dat is toch wat anders dan ICT
http://nl.wikipedia.org/wiki/Lean_manufacturing
Er is een groot verschil tussen het beheersen van een lopend productieproces en het proces voor productontwikkeling. De meeste mensen verwarren productontwikkeling met productie. Dat is ook zichtbaar in de reacties van de experts en bovenstaande reacties.
Toyota heeft dit echter heel goed begrepen en maakt dan ook onderscheid tussen deze processen. Echter, de onderliggende principes zijn dezelfde!
Uit eigen ervaring als projectmanager kan ik aangeven dat die principes wel degelijk erg goed kunnen werken. Ik heb een aantal volgens het boekje opgezette, maar slecht functionerende projecten mogen overnemen, en daar de Toyota principes met groot succes toegepast.
Juist het Toyota systeem benadrukt de individuele kennis en kunde van mensen in het team en faciliteert de samenwerking hierbinnen. Juist het Toyota systeem houdt rekening met onvoorspelbare zaken op een effectieve manier. Dit zijn zaken die een grote rol spelen in softwareontwikkeling. Het is een kennisintensief proces met een grote mate van onvoorspelbaarheid (het laatste gemeten aan de daadwerkelijke klantbehoefte, niet aan de opgestelde requirements).
Er is overigens er veel informatie te vinden over softwareontwikkeling volgens Lean principes (meestal Agile genoemd). Het is dan ook helemaal niet iets nieuws. Het probleem is eerder dat het erg moeilijk is om de filosofie te begrijpen en goed toe te passen. Bij mij was dat zeker zo.
Wat mij uit alle reacties niet duidelijk wordt, is welke maatregelen we in de ICT zouden moeten nemen om WEL deze principes te kunnen toepassen…
TPS is volgens mij een ontwikkeling geweest van Toyota in Amerika (Kentucky) en niet Japan. Waar er naar verbeteringen topdown en buttom-up gekeken wordt. Kaizen en JIT zijn een aantal zaken waar TPS zijn oorsprong in vindt. Continue verbeteren en just in time zou goed mogelijk zijn in de ICT. Misschien is TPS als geheel niet altijd en overal toe te passen maar delen van TPS zijn zeer zeker binnen de ICT te gebruiken.
Implementatie van LEAN (=TPS) binnen de ICT-branche is kansloos zonder een echte ?sense of urgency? en een meer realistisch zelfbeeld.
Toyota nodigt jaarlijks tientallen vrienden en vijanden uit om deze kennis te laten maken met hun LEAN-productiesysteem. Zij zijn niet bang voor het snel kopi?ren van hun proces omdat dit slecht de resultante is van de LEAN filosofie die diep in de genen zit van het bedrijf zelf.
De heer Leenderts raakt dit onderwerp voorzichtig aan door te spreken over een cultuurverandering (houding en gedrag) die moet worden ingezet om werkelijk te kunnen aan spreken over LEAN-implementaties binnen de branche.
Blijft de vraag staan hoe je nu deze verandering tot stand moet brengen. Belangrijk is het dat er binnen het verandergebied een bewustwording ontstaat dat er iets moet veranderen. Dat het blijven volgen van de huidige koers ernstige gevolgen zal hebben. Zonder deze ?sense of urgency? is er geen energie die de verandering moet voeden.
Blijkbaar komt de ICT-branche nog altijd weg bij de klant met te dure of te laat opgeleverde projecten waarbij de deliverables van een twijfelachtige kwaliteit zijn. Nee, ik kan niet zeggen dat er een gevoel heerst in de branche dat het echt anders moet.
Daarnaast moeten we ook eens kijken naar de doorsnee ICT-er binnen deze branche. Is het niet zo dat we juist in deze branche wars zijn van standaard oplossingen, processen en technologie?n. Het liefst zien we elk project weer als een volledig nieuw uitdaging zonder terug te kijken naar wat we in vorige projecten hebben gedaan of geleerd.
Welke architect wil niet werken met ?on the edge??technologie en vraagt zich daarbij misschien minder af of de klant daar wel bij gebaat is. Werken met ?proven technology? is saai en daar kun je op een verjaardag niet mee aankomen.
De kern hierbij is dat we liever drie oplossingen voor ??n probleem bedenken dan ??n oplossing voor drie problemen.
Mijn stelling is dat zonder een duidelijke ?sense of urgency? en een realistisch zelfbeeld binnen de branche kunnen alle vormen van schrijven hierover als ?waste? kunnen worden beschouwd.
Hierboven al door Martin genoemd, maar zeker het herhalen waard: we kunnen als IT beter kijken naar “The Toyota Product Development System” dan naar “Toyota Production System”.
Voordat een Toyota in productie gaat, wordt het eerst volledig ontworpen, gebouwd en meerdere malen getest. Visual, in de vorm van mockups, in een cad/cam omgeving, volledig gespecificeerd, om alle krachten door te rekenen, in als prototypes.
Voordat het eerst exemplaar van de productie lijn komt, zijn er al verschijnene gebouwd en getest.
In de IT gaat dit compleet anders, de zogenaamde Technische Ontwerp documenten beschrijven vaak slechts in hoofdlijnen hoe iets gaat werken. Echt getest zijn ze nooit. Je kunt dus absoluut niet verwachten dat de IT op een productielijn gaat lijken.
We zijn met product development bezig, niet met productie. Een cd-tje branden van een software product dat af is, dat is productie.
Ik denk dat we over een jaar of 10 klaar zijn om op grotere schaal te begrijpen wat Toyota doet.
TPS is het resultaat van het toepassen van hun management principes. Die worden gehanteerd in alles wat ze doen. Dit heeft geleid tot wat nu TPS wordt genoemd. Maar dat is niet wat men bij Toyota predikt “Leer TPS”, men predikt “Leer de filosofie begrijpen en leer hoe je dat in jouw situatie, binnen jouw organisatie kan toepassen”.
Als je verder kijkt, je in deze materie verdiept, dan zal je zien (hoop ik) dat deze principes toepasbaar zijn op elk niveau, binnen elke bedrijfstak.
Als we deze stap hebben gemaakt, het begrijpen van de filosofie welke de “Toyota way” is, pas dan zullen we verder komen in de toepassing ervan op werkelijk alle bedrijvigheden.