vrijdag 5 april 2013

TOC 3.0?


De Theory of Constraints (TOC) bestaat al heel wat jaren. Sindsdien is TOC wat verder ontwikkelt.  Sommigen zouden zeggen dat het veel heeft gegroeid.

Misschien, maar naar mijn bescheiden mening is TOC toe om wakker geschut te worden. Voortzetting van het huidige pad is een pad in de vergetelheid. En dat, dat zou geweldige jammer zijn.


Een aantal wake-up statements
Hoewel verre van beperkt tot TOC, is er deze 'nare' vraag die blijft opduiken: "hoe kunnen we onze klanten / anderen overtuigen om gebruik te maken van ...". Natuurlijk is het met de beste intenties. Overigens we kennen allemaal wel het gezegde met over 'beste intenties'...  Maar alsjeblieft, hoe kun je zo'n plank voor je hoofd hebben? Eerlijk gezegd, deze had ik een hele poos. Maar wie kan echt geloven dat ze HET antwoord kunnen hebben voor wie dan ook?

Jarenlang beweren mensen, natuurlijk de TOC-minded, dat TOC de beste probleemoplossende benadering die er te krijgen is. Dat er geen betere manier is om een analyse te doen. Volgens mij kunnen ze niet meer verkeerd zitten. En wel omdat: TOC is GEEN probleemoplossende benadering, TOC is GEEN analyse. Niet omdat ik het zeg, maar omdat TOC dit zelf zegt.

TOC, de Theory of Constraints, beweert dat het zijn kracht ontleent door te denken in constraints. Nou, misschien is de waarheid een beetje anders. De kracht is voornamelijk afgeleid uit beperken-tot-constraints denken. Dit is eigenlijk zeer krachtig voor focus, maar in geen geval een rechtvaardiging om te spreken van de Theory of Constraints.

Het is niet verkeerd om trots te zijn op TOC, dat is niet het probleem!


Hoe TOC begon
Maar laat eerst een paar decennia terug gaan. Een tijd vlak voordat TOC het leven zag, een wereld die lijkt op die van vandaag en toch heel anders was. Een tijd die voornamelijk dreef op productie, een tijd waarin de capaciteit werd gezien als oneindig, een tijd waar de arbeidskosten zeer laag waren, een tijd van grote volumes en incidentele productwijzigingen. Een tijd waar de dingen behoorlijk voorspelbaar waren. Het was een tijd waarin het rationele denken ontstond ​​en uitgroeide tot systeemdenken.

Maar de wereld werd minder voorspelbaar. Natuurlijk, zoals nu met Big Data, werd er flink ingezet op computers die in staat zijn om veel gegevens te processen. De ERP-systemen kwamen, maar velen konden de verwachting niet waar maken. Niet omdat ze erg duur waren, niet omdat het nodig is een enorme hoeveelheid inspanning te blijven leveren om de systemen te voeden met informatie. Nee, het is mislukt vooral vanwege een reden: de ERP-systemen veronderstelde oneindige capaciteit.

Hoewel ik de weg die TOC nam zal volgen, kunnen we niet echt negeren wat Deming gedaan en bereikt heeft. De meeste die van Deming gehoord hebben, associëren hem met Kwaliteit. Geen twijfel over, hij is een knooppunt in de geschiedenis met betrekking tot kwaliteit. Maar Deming gaat eigenlijk veel meer over het bouwen van een duurzame toekomst. Ja, toen was kwaliteit belangrijk om vooruit te komen, maar hij waarschuwde al: "Ze waren de beste in hun sector, maakten ze de beste producten, waar zijn ze [carburateur producenten] nu?" Kostenreductie is belangrijk, maar je bestaat niet om de kosten te verlagen. Verbetering van de kwaliteit is belangrijk, maar je bestaat niet om de kwaliteit te verbeteren.

Eli Goldratt pikte hiervan een paar dingen op. Zijn 'ijverige' kruistocht tegen de efficiency mentaliteit. Niet omdat hij tegen kostenreductie was, maar omdat hij voor Throughput verhoging stond. Ook slaagde Eli Goldratt erin om te komen met een algoritme dat eindige capaciteit verondersteld. Een doorbraak. En de fundamenten voor TOC werden gelegd.

TOC houdt zich niet bezig met problemen. Het enige wat relevant is, is hoe hoe de doelstelling kan worden bereikt. Dit is vastgelegd in de Focusing Steps: Stap 0 = bepaal het doel. 'Problemen' die geen invloed hebben op het bereiken van het doel worden 'genegeerd'.

In een tijd waar analyse hoog in het vaandel stond, begon TOC met synthese: uitzoeken hoe de dingen met elkaar samenhangen en verbonden zijn, het 'toetsen' van onze kennis hierover.

De tijd veranderde

En nu? Vandaag de dag is een zeer dominante factor de dienstverlenende sector (Ik beschouw s/w ontwikkeling ook als een dienst). Productie bestaat natuurlijk ​​nog steeds, maar een paar veranderingen hebben plaatsgevonden. Tegenwoordig is voor de meeste bedrijven de grootste uitdaging de flexibiliteit. De deterministische modellen en denken die zo mooi werkte in het verleden zijn ingehaald door de realiteit.

Helaas te veel van de modellen en denken lijken door te glijden in de dienstverlening. Een industrie die maar al te bereid om hen te omhelzen: 6 Sigma, geoptimaliseerde batch grootte, kanban, enz. Al deze concepten vereisen een hoge volume / geen verandering en voldoende / overcapaciteit en voorspelbaarheid. Geen van deze eisen komen zelfs maar in de buurt bij waar de service-industrie voor staat: laag volume / veel wijzingen, tekort aan capaciteit. Vandaag de dag is het toverwoord flexibiliteit belangrijker dan ooit tevoren.

De menselijke factor is steeds dominanter geworden. De tijd van de rationaliteit is niet verdwenen, maar is beperkter. Een van de dingen die lijkt in dit gat te kunnen vullen, is het Cynefin framework.

Cynefin framework

Ik denk niet dat het Cynefin framework het antwoord zelf zal worden. Wel dat het instaat is om een aantal van onze grote uitdagingen op te lossen op meta-niveau. Er is heel veel te zeggen over de Cynefin framework en niemand beter dan Dave Snowden. Als je het Cynefin framework bestudeert, neem dan in gedachten:

  • GEEN VAN DE DOMEINEN IS BETER OF SLECHTER DAN DE ANDERE (met uitzondering van disorder misschien).
  • Typeer geen organisatie of zelfs organisatieonderdeel, het is gaat over een situatie. Het is goed mogelijk dat tegelijkertijd verschillende delen van een situatie zich in verschillende domeinen bevinden.



Ik zal het Cynefin framework vanuit een speciale hoek belichten: constraints.

Binnen het Cynefin framework hebben constraints een ander gevoel dan binnen TOC. TOC gaat uit dat een constraint een factor is die beperkend of blokkerend is om een ​​doel te bereiken. Als iets niet beperkt of blokkerend werkt in het bereiken van een doel dan is het geen constraint.

Er is een ander ding dat ik even moet toelichten voordat ik inga op constraints. Binnen het Complexe en Chaotische Domein kun je niet denken in termen van doelstellingen bereiken. Het is 'opkomend', dingen gebeuren zoals ze gebeuren. Nu, als je reactie is iets dergelijks van mij of Bill, dat is prima. De valorisatie vindt plaats in de Gecompliceerde domein. Dave Snowden heeft IMHO een liefdesrelatie met het Complexe en Chaotische Domein, maar op geen enkele manier ontkent hij het ​​belang van het Gecompliceerde Domein of het Simpele domein ... hij heeft alleen een allergie wanneer dingen beperkt worden.

Als een situatie zich in het Complexe Domein bevindt en valorisatie is nodig is, dan moeten er acties ondernomen worden om het geheel te verplaatsen naar het Gecompliceerde Domein. Een beetje abstract misschien, zie het als een uitdaging om het Cynefin framework in te duiken.

Cynefin framework & Constraints


Er zijn verschillende manieren om te kijken naar het Cynefin framework. Ik ga nu vooral gebruik maken van Daves ideeën met betrekking tot constraints. Constraints in het Cynefin framework zijn dingen die gedrag en denken beïnvloeden. Hoe sterker de beperkingen, hoe voorspelbaarder de uitkomst. De losser de beperkingen, hoe meer interactiviteit er plaats vindt en hoe minder voorspelbaar de uitkomst is.

Als de constraints erg strak zijn, dan is Oorzaak = Gevolg, Simpele Domein. Een goede manier om dit te testen, is dat iedereen de oplossing volgt die is voorgeschreven, zonder zelfs af te vragen of het misschien ter discussie moet worden gesteld (bijv. loon-rolling). Best Practice.

Als de constraints redelijk strak zijn, betekent dat het resultaat nog steeds voorspelbaar is. Dan is Oorzaak -> Gevolg, Complicted Domein. Het domein waar we de grote projecten doen, het geld verdienen, waar het grootste deel van de core business zit. Een goede test: meerdere oplossingen zijn mogelijk, maar het advies van de experts(s) wordt gevolgd. Good Practises.

Echter, wanneer constraints los zitten. Dan is er een interactie tussen Oorzaak -> Gevolg -> Oorzaak en de iteratie betekent dat de dingen niet meer voorspelbaar. In het beste geval enkele gissingen over de richting. Een goede test: meerdere oplossingen zijn mogelijk, maar het advies van de expert(s) wordt niet gevolgd. Het voelt als een patstelling, geen afstemming, etc. Echter, dit is ook het domein waar meerdere oplossingen kunnen en moeten worden onderzocht, waarbij out-of-the-box denken kan plaatsvinden, innovatie.

Het Chaotische Domein. Hier hebben we geen benul van Oorzaak?? Gevolg??. Meestal een situatie waarbij tijd een belangrijke factor speelt. Snel grip krijgen op is de sleutel. Dave Snowden en anderen hebben zelfs een aantal 'workshops' bedacht die dit deel weten te benutten. Die workshops hebben maar één doel voor ogen: het verstoren van de denkprocessen en wat mensen denken. We kennen allemaal het gezegde, van de beker volle beker.

Het heeft mij de nodige tijd en inspanning gekost en misschien zie ik het verkeerd, maar in dit alles zie ik grote mogelijkheden voor TOC 3.0. Er is zoveel meer te doen met constraints dan alleen maar het vinden van de 'meest beperkende' en deze te 'exploiteren'. Constraints Management kan een geheel nieuwe betekenis krijgen. Sommige dingen moeten waarschijnlijk veranderen, ook afhankelijk van welk domein het wordt toegepast. Maar het meeste dat moet veranderen is hoe TOC-minded mensen naar TOC kijken:

  • TOC is een middel, geen doel
  • TOC is een op het doel-bereiken gerichte methodologie
  • TOC houdt zich primair bezig met de synthese = relatie tussen dingen, en of die nuttig of niet nuttig zijn
  • Constraints is niet beperkt tot dat wat limiteert of blokkeert en iets wat geïdentificeerd en benut moet worden. Constraints zijn dingen die kunnen worden aangetrokken of gerelaxed kunnen wordne om dingen mogelijk te maken die anders onmogelijk zijn.





Geen opmerkingen:

Een reactie posten