Slagvaardig en efficiënt

Slagvaardig en efficiënt zijn modewoorden waarbij men het liefst ziet dat alles en iedereen moet voldoen aan beide. Is dat wel reëel? Ik denk dat een keuze moet worden gemaakt welke het meest belangrijk is. Als je naar de maatschappij, technologie en omgeving kijkt, zie je dat alles steeds sneller verandert. Mee veranderen moet, anders ben je gedoemd. Welke keuze maak je dan in de eerste instantie: efficiënt of slagvaardig? Of maakt efficiënt je juist slagvaardig?

Definities

Efficiënt: het bereiken van zoveel mogelijk, met zo weinig mogelijk middelen.

Slagvaardig: actief en snel reageren op veranderende omstandigheden.

Effectief: doeltreffend in één keer.

Systeem: een iets dat op een samenhangende manier is opgezet of georganiseerd.

Legacy: systemen die zijn gebaseerd op verouderde omstandigheden.

Concurrenten; slagvaardig en efficiënt

Slagvaardig en efficiënt willen zijn, zijn geen tegenstellingen ‘pur sang’, maar wel concurrenten. Organisaties moeten kiezen welke twee zij het belangrijkste vinden. Die keuze helpt bij de besluitvorming en geeft je kaders.

Wanneer een organisatie slagvaardig als prio 1 heeft, heeft dit implicaties bij vernieuwingen. Voorbeeld: Er is een nieuw of vernieuwd product nodig. Hoe ga je dat implementeren? Efficiënt betekent dat je er heel goed over na moet denken hoe je dit met zo min mogelijk effort kunt doen. Effectief betekent dat het in één keer goed moet. Slagvaardig is hoe je dit snel in één keer goed kunt. Heel goed nadenken over hoe je het gaat doen kost tijd en is dus niet slagvaardig. Slagvaardiger is het in één keer neerzetten en later verder verbeteren. Vooralsnog is het streven naar in één keer goed en is efficiënt het secundaire doel; dit lijkt wel Agile.

Voor en nadelen bij efficiëntie: Een efficiënt ingericht proces is meestal maar gericht op één omstandigheid. Vaak is er zo getuned aan het proces dat er geen ‘vet meer op de botten zit’. Efficiëntie wordt mede bereikt om zoveel mogelijk met generieke (technische) systemen te werken. Je hoeft dan dat systeem maar een keer in te realiseren.  Als de focus is ‘houdt generiek’, en dus efficiënt, betekent dit meestal dat je aan flexibiliteit inboet en je inschikt op wat het generieke systeem je oplegt. Bij generieke systemen legt het systeem op hoe je proces loopt in plaats dat het proces het systeem bepaalt; eigenlijk is dat een randvoorwaarde. Het voordeel is dat je zo min mogelijk middelen hoeft in te zetten. Nadeel kan zijn dat bij een diversiteit aan producten het een complex karwij kan zijn om deze allemaal onder te brengen in een generiek systeem. Maatwerk bovenop het generieke systeem is dan nodig. De complexiteit neemt dan weer exponentieel toe. Immers, alle producten raken verweven binnen het generieke geheel.

Wat bepaalt dan de diversiteit van producten en het gedrag van een systeem? Voorbeeld:

Je doelgroep bestaat uit jongeren van 14 tot 21 jaar en je product is een abonnement op iets dat jaarlijks wordt gefactureerd. Je inningsstraat zal veel minder gericht zijn op het sturen van fysieke facturen, maar meer gericht op het aanbieden van elektronisch betalen (iDeal, PayPal, etc.). Bij producten gericht op een doelgroep van 55+ en ouder zal het product een andere uitstraling hebben maar ook de wijze hoe je de doelgroep benadert.

We hebben nu slagvaardig, effectief en flexibel. Hoe staat dat in relatie tot Agile?

Agile

Agile ontwikkelen is een product- of systeem ontwikkelingsmethode waarbij in korte cycli concrete werkend versies worden opgeleverd. Agile, of te wel, wendbaar is een kameraad van slagvaardig. Bij Agile ontwikkelen staan zelfsturende multidisciplinaire teams centraal. De filosofie is: ‘begin, doe en verbeter’. Fouten mogen gemaakt worden in het ontwikkelproces; het is experimenteer en verbeter. Ontwerp en documentatie hebben minder prioriteit. Hierdoor is men veel eerder geneigd creatieve ideeën uit te proberen. De afspraak is in korte tijd iets werkbaars op te leveren; het moet bruikbaar zijn. De ontwikkeltijd  kan variëren tussen twee en vier weken. Dit sluit heel nauw aan bij het slagvaardig willen en kunnen zijn. Het hoeft niet gelijk perfect maar het moet wel werken. Na elke ontwikkelcyclus (sprint) besluit je om door te gaan met perfectie of aanvullende functionaliteit. Niet perfect wil niet zeggen ‘ vol met fouten’, maar het werkt, beperkt en misschien niet zo mooi.

Voorbeeld:

Banken boden hun online dienstverlening stap voor stap aan. Eerst kon je alleen inloggen en je saldo checken, daarna werd de beveiliging opgevoerd, betalingen ingericht, et cetera. Nu is de totale dienstverlening gedigitaliseerd.

Deze stap-voor-stap-filosofie is wel heel anders dan we gewend zijn om veranderingen door te voeren, maar deze wijze van het benaderen van veranderingen lijkt de juiste om slagvaardig te kunnen zijn.

De erfenis

Ok, slagvaardig wordt dus steeds belangrijker. Echter, we nemen wel veel mee uit het verleden toen veranderingen nog niet zo snel gingen. De focus was destijds meer gericht op het steeds efficiënter doen. Lean processen en schaalvergroting waren dé woorden waar het om ging; meer doen met zo min mogelijke kosten. Met groter worden ook de bijkomstige eigenschappen: bureaucratie, veel management, procedures, etc. Voor elke verandering moest een procedure worden doorlopen om in controle te willen blijven.

Voorbeeld: RFC, business case, projectbrief, project plan, ontwerp, technisch ontwerp, realisatie, test en acceptatie. Als er vragen ontstonden in de realisatiefase moest er helemaal terug worden gegaan naar de business case of de ontwerpers (als die in deze fase nog beschikbaar waren). Dit lijkt snelle besluitvorming aardig in de weg te staan.

Agile ontwikkelen lijkt het antwoord op de snelle veranderende omgeving.  De belangrijkste voorwaarde is voor Agile ontwikkelen is vertrouwen, maar met vertrouwen hebben de meeste organisaties nog veel moeite. Ook dat nemen we als erfenis mee; gebrek aan vertrouwen.

Daarnaast hebben organisaties te kampen met systemen die door bezuinigingen en andere prioriteiten (korte termijn denken) slecht onderhouden zijn. Hoe ouder de systemen des te langer duurt het om wijzigingen door te voeren. Hoe gaat men dan om met deze erfenissen?  Legacy systemen kun je stabiliseren en inkapselen, accepteer ze! Vervolgens plan je een nieuwe lijn.

De nieuwe lijn

Wat is een betere tactiek? Een groot leger met een generaal en alle resources (mens, voertuig, wapens) indirect onder één aansturing? Of kleine wendbare eenheden? Het antwoord ligt eraan in welke omstandigheden de strijd zich afspeelt. Als dagelijks de omstandigheden wijzigen (elke dag een andere vijand of ander landschap/klimaat), is het makkelijker kleine eenheden van ander materiaal te voorzien dan een heel leger, dan wel het aanpassen van de tactiek.

Deze analogie zou je kunnen gebruiken als je het vraagstuk hebt waarbij je op zich zelf staande producten hebt met daarbij ook nog eens een andere doelgroep (vijand). Een specifieke productielijn is sneller aan te passen dan een generieke. Denk daarbij bijvoorbeeld dat je bij een generiek klantenbestand ook rekening dient te houden met andere klantgroepen die in het systeem zitten maar niet de doelgroep die de wijziging betreft. Immers, voor een specifiek iets wil je het liefst geen generiek systeem aanpassen met alle test issues van overige producten hier omheen.

Wanneer men besluit de gehele organisatie volgens slagvaardige principes in te richten is er een vraagstuk wat te doen met de oude systemen.

De oude systemen (legacy) werken nog steeds en dan letterlijk genomen, ze werken. De focus moet zijn: hoe zijn we het meest slagvaardig? Met daarbij de vraagstukken:

1. Gaan we voor generieke processen en een totaal integraal systeem?
2. Gaan we voor toegesneden subsystemen (diversificatie)? En wat te doen met legacy?

Voor keuze 1 of 2 speelt de aard van producten een grote rol. Wijken de producten qua soort en de totstandkoming niet veel van elkaar af en is de doelgroep niet teveel afwijkend, dan kies je voor generiek.

Legacy systemen kun je snel uitfaseren of inkapselen. Inkapselen kies je als migratie (uit de oude en naar de nieuwe systemen) te risicovol is, en dat is het vaak.

Hoe ziet dat inkapselen er dan uit?

1. Zorg dat de documentatie van het systeem actueel is. Zorg dat het systeem in een geïsoleerde omgeving kan blijven performen (oud Operating systeem). Ontkoppel het systeem van directe benadering van buiten af vanwege veiligheids-overwegingen
2. Ontwikkel de nieuwe straat volgens Agile; d.i. snel iets werkend opleveren, niet perfect, wel foutloos. Work-arrounds ontstaan door de imperfectie. Dat is acceptabel voor de korte termijn. Werk vervolgens de work-arrounds af via business cases toe naar een totaal systeem.

We vertrokken vanuit de vermeende concurrentie van efficiëntie en slagvaardig. Vervolgens namen we de route Agile en de omgang met Legacy. Belangrijk is dat we moeten accepteren dat veranderingen steeds sneller gaan, ons er op moeten aanpassen en accepteren dat we te maken hebben met Legacy (systemen, processen en organisatie).