De door businessdesigner dr. Eliyahu M. Goldratt al jaren uitgedragen 'Theory of Constraints', kortweg TOC, wordt in allerlei bedrijfstakken toegepast. Van logistiek, gezondheidszorg tot in het onderwijs. TOC wordt langzaam aan ook toegepast in softwaredevelopment. Het toepassen van de TOC-methode in een softwareproject brengt allerlei positieve invloeden met zich mee. In deze opiniebijdrage wil ik me daarbij beperken tot het proces waarin het ontwerp van de software ontstaat.
Een software-ontwikkeltraject wordt, indien het enige omvang heeft en überhaupt een kans van slagen wil maken, in projectvorm ontwikkeld. Welke methodiek er ook gebruikt wordt, Extreme Programming (XP), RUP, (D)SDM of Prince2, altijd heb je te maken met een fase waarin de software wordt beschreven die gemaakt dient te worden. Deze beschrijving vindt in de praktijk in allerlei vormen plaats: user stories, use cases, scherm mock-ups of bijna werkende prototypes. Voor het gemak noem ik het resultaat hier het functioneel ontwerp. Op welke wijze je het functionele ontwerp ook maakt, TOC helpt gegarandeerd de juiste oplossing te beschrijven en er tevens voor te zorgen dat deze oplossing gedragen wordt door de juiste mensen.
TOC-denkproces
Het ‘TOC-denkproces', de methodiek van dr. Eliyahu M. Goldratt, biedt een gestructureerde werkwijze om dilemma's te achterhalen en tot doorbraakoplossingen te komen. De methodiek is een holistische benadering en onderscheidt zich daarmee van een aantal andere analysetechnieken. Daarbij worden zoveel mogelijk logische verbanden (oorzaak-gevolg) in kaart gebracht. Dat is ook bruikbaar bij het ontwerpen van software. Wanneer men de functionele analyse baseert op dit denkproces, start je niet met de oplossing, zoals vaak gebeurt, maar met het doel. De kernvraag is: wat wil de organisatie bereiken en wat staat er in de weg om dat doel te bereiken?
Wat lost nieuwe software nu eigenlijk voor probleem op? Aanname hierbij is dat softwareprojecten altijd een bijdrage leveren aan het businessdoel, in de vorm van omzetvergroting, kostenverlaging of bijvoorbeeld voldoen aan veranderende wet- en regelgeving (en zo de continuïteit van de organisatie te waarborgen). Bij het vaststellen van het doel waarshuwt Dr. Goldratt ons voor lokale doelen, 'local optima' noemt hij dat. Lokale doelen dragen niet significant bij om de organisatie als geheel grote sprongen vooruit te laten maken. Bovendien wordt een lokale oplossing ook altijd maar gedragen door ‘lokale' medewerkers en niet de gehele organisatie, terwijl het slagen van het project veel van een organisatie vraagt en commitment (lees: het projectdoel accepteren) van alle mensen die bij dit project betrokken zijn, essentieel is. Zonder dat is het project gedoemd te mislukken. In de praktijk zie je vaak dat de manager van die ene afdeling veel prioriteit geeft aan het project, maar zodra er anderen van buiten die afdeling nodig zijn in het project, het project ineens vertraging oploopt. Heel simpel, doordat het project voor die mensen geen prioriteit heeft.
Dus wat leert het TOC-denkproces ons, na de kernvraag 'wat wil de organisatie bereiken en wat staat er in de weg om dat doel te bereiken?'. Eigenlijk zijn het vier hele gewone vragen, maar de juiste oplossing zit hem niet in ingewikkelde methodieken. Juist in de eenvoud zit de kracht.
1. Wie willen de verandering?
2. Wat veranderen?
3. Waarheen veranderen?
4. Hoe veranderen?
Wie veranderen?
De TOC-toepassing voor functionele analyse begint met de vraag 'Wie veranderen?'. Daarbij worden alle betrokkenen in kaart gebracht. Belangrijke personen hierin: degene die 's nachts wakker ligt van het probleem en degene die over de financiële middelen beschikt om iets aan het probleem te laten doen. Wij noemen deze personen probleemeigenaar respectievelijk opdrachtgever.
Naast deze personen zijn er vaak meer personen betrokken in het project. Dat zijn personen die invloed kunnen uitoefenen op het probleemgebied. Meestal komt dat erop neer dat er afdelingshoofden en hoofdgebruikers worden ingeschakeld. Soms is het niet mogelijk om alle doelgroepen ook werkelijk te betrekken, bijvoorbeeld in geval van een internetwinkel. Een goede aanpak is om deze doelgroepen via een 'persona'-aanpak te betrekken in het project. Vanuit de TOC-analyse-aanpak geef ik dan mee om van elke persona ook te beschrijven welke invloed het probleem op hen heeft. Cruciaal is dat alle betrokken personen het eens zijn over het probleem.
Wat veranderen?
Dat brengt ons automatisch bij de volgende stap" 'Wat veranderen?'. Daar zit de crux in een TOC-analyse: alle betrokkenen zitten op één lijn over het probleem en vinden dat dat probleem opgelost moet worden. De TOC-aanpak houdt ook in dat we ons focussen. Door met elkaar duidelijk vast te leggen wat het probleem is dat opgelost moet worden en door daarop te focussen, is het doel van het project klip en klaar.
Als er voortschrijdend inzicht ontstaat (en dat gebeurt altijd!), is eenduidig vast te stellen of dat noodzakelijk is om het probleem op te lossen. Indien dat niet het geval is, hoort dat nieuwe inzicht niet tot de scope van het project. Het kan heel goed opgeschreven worden voor een latere release-kalender. Maar trap niet in de verleiding van 'nu we toch ermee bezig zijn, neem dit dan meteen mee'. Een scopewijziging kost tijd en energie. Het gevolg van een scopewijziging is meestal dat het probleem later wordt opgelost, daarmee wordt ook het doel later bereikt. Meestal draagt het 'even meenemen' minder bij dan dat het later bereiken van het doel verlies oplevert.
Waarheen veranderen?
Eindelijk zijn we dan aanbeland bij de stap 'Waarheen veranderen?'. Er zijn heel veel mensen die deze stap als eerste nemen. Ze hebben al een oplossing in het hoofd zitten en die is leuk, spannend, uitdagend, etc. Daar willen ze direct mee aan de slag. Echter, doordat de oplossing niet getoetst is aan het achterliggende probleem, wordt het slagen van het project al in gevaar gebracht. Het doel is niet duidelijk voor alle betrokkenen, er is geen ‘norm' om met scopewijzigingen om te gaan, de deadline is niet hard neergezet, etc.
De wijze waarop beschreven wordt waarheen veranderd wordt, maakt niet uit. Maar het moet er zijn. Je kunt dat doen met de analyse-aanpak die je gewend bent, mits je maar zorgt dat de betrokkenen zich focussen op het oplossen van het probleem. Dat levert precies de juiste oplossing op. Niet teveel functionaliteit, niet te weinig functionaliteit. In sommige aanpakken wordt er aan het eind van de analyse functionaliteit conform Moscow verdeelt van 'Must have' tot 'Will have but not right now'.
Dit is een vreemde stap in de TOC-aanpak. Waarom eerst iets uitwerken om dan later aan te geven dat het niet nodig is? Ook wordt dit soort verdelingen gebruikt om te bepalen wat er wel en wat er niet in het budget past. Maar ook dat is een vreemd uitgangspunt. Beter zou zijn: met welk budget lossen we het probleem op en wat is de waarde van die oplossing voor de organisatie? Door vanuit het doel van de organisatie te denken en door het eens te zijn over het probleem dat de organisatie in de weg staat om dat doel te bereiken, garandeert de TOC-aanpak dat de oplossing gedragen wordt door alle betrokkenen en dat daar altijd budget voor te verkrijgen is.
Hoe veranderen?
De laatste stap is 'Hoe veranderen?'. De planning van het veranderen, het project, laten we over aan projectmanagers. Maar de functioneel ontwerper is nog niet klaar als het functioneel ontwerp gemaakt is. We hebben dan pas beschreven waarheen we willen veranderen, maar onderweg kan er nog wel het één en ander gebeuren. De organisatie gaat het er niet om dat de oplossing van het probleem beschreven is, maar dat het probleem werkelijk opgelost is. Onderweg zullen er onvoorziene obstakels opduiken die de oplossing in de weg staan. Daarvoor zal binnen de kaders van het probleem een injectie op de oplossing gedaan moeten worden. De TOC-aanpak garandeert niet dat er geen voortschrijdend inzicht zal ontstaan, maar garandeert wel dat deze de tijdige oplossing van het probleem niet in de weg zullen staan.
Persoonlijk heb ik uitstekende ervaringen met het toepassen van de TOC-aanpak tijdens de functionele analyse. Door te focussen op het op te lossen probleem, ben ik gericht met de oplossing bezig. Ik ben benieuwd of er meer mensen zijn die TOC toepassen in deze fase van een project en wat hun ervaringen daarmee zijn.
Alexander Vermeulen
Informatie & systeem analist
Garansys
