De verkeerde volgorde: eerst de organisatie, dan het systeem

Het gebeurt vaak. Een afdeling loopt vast: dossiers zijn onvolledig, doorlooptijden lopen op, medewerkers werken met eigen lijstjes. Iemand ziet op een beurs of bij een collega-organisatie een systeem dat precies dit probleem lijkt op te lossen. Een jaar later is het systeem ingevoerd. En nog een jaar later blijkt dat de problemen grotendeels zijn gebleven, alleen nu in een nieuw systeem.

Het is een open deur dat je eerst het probleem moet begrijpen voordat je een oplossing kiest. Toch gebeurt het anders, keer op keer. In dit artikel beschrijf ik waarom die verkeerde volgorde zo hardnekkig is, wat onderzoek erover zegt en welke volgorde wel werkt.

Waarom organisaties bij de oplossing beginnen

Een systeem is tastbaar. Het heeft een naam, een prijs en een leverancier die een demonstratie geeft. Een procesprobleem is dat niet. Het zit verspreid over afdelingen, gewoonten en afspraken die niemand heeft opgeschreven. Het is begrijpelijk dat bestuurders liever kiezen voor iets wat zij kunnen kopen dan voor iets wat zij moeten uitzoeken.

Daar komt bij dat ict-projecten vaak worden aangevlogen vanuit de techniek. De vraag wordt belegd bij de afdeling ICT, die logischerwijs denkt in systemen en koppelingen. De vragen die eraan voorafgaan, over doelen, processen en verantwoordelijkheden, horen eigenlijk bij de lijnorganisatie. Die schuift ze door omdat het een ict-project lijkt.

Wat onderzoek zegt

Hammer (1990) schreef al in 1990 dat organisaties hun processen niet moeten automatiseren, maar opnieuw moeten ontwerpen. Wie een slecht proces automatiseert, maakt het sneller, maar niet beter. De wachttijden, de dubbele controles en de onnodige overdrachten blijven bestaan, alleen nu vastgelegd in software.

Davenport (1998) liet zien dat standaardpakketten hun eigen logica meebrengen over hoe een organisatie werkt. Dat is niet per se slecht. Maar het betekent dat de keuze voor een pakket ook een keuze is voor een manier van werken. Organisaties die dat niet beseffen, merken pas tijdens de invoering dat het systeem niet past bij hoe zij willen werken. Dan volgen dure aanpassingen, of een organisatie die zich ongemerkt naar het systeem voegt.

Markus en Tanis (2000) volgden de invoering van bedrijfssystemen van begin tot eind. Zij zagen dat veel problemen die tijdens of na de invoering zichtbaar worden, hun oorsprong hebben in de allereerste fase: de fase waarin het besluit wordt genomen, de businesscase wordt gemaakt en het pakket wordt gekozen. Beslissingen die daar te snel worden genomen, werken het hele traject door.

Robey, Ross en Boudreau (2002) onderzochten hoe organisaties leren een groot systeem in te voeren. Zij vonden dat de invoering vraagt om kennis van zowel het systeem als de eigen processen, en dat organisaties die die kennis vooraf opbouwen de invoering beter doorkomen.

De juiste volgorde in vijf stappen

1. Begin bij doelen en context

Wat wil de organisatie bereiken, en wat staat dat nu in de weg? Welke wettelijke eisen, ketenpartners en ontwikkelingen spelen een rol? Ross, Weill en Robertson (2006) raden aan eerst te bepalen hoe de organisatie wil werken: in welke mate processen gestandaardiseerd moeten zijn en in welke mate gegevens gedeeld moeten worden. Die keuze bepaalt welke systemen passen, niet andersom.

2. Breng processen en informatie in kaart

Beschrijf hoe het werk nu verloopt, waar het schuurt en hoe het beter kan. Welke informatie ontstaat waar, wie gebruikt haar en wie is eigenaar? Dat hoeft geen dik document te worden. Een overzicht van de belangrijkste processen, de knelpunten en de gewenste situatie is vaak genoeg. Het belangrijkste is dat de mensen die het werk doen erbij betrokken zijn. Zij weten waar het werkelijk misgaat.

3. Vertaal naar eisen en architectuurprincipes

Vertaal de gewenste situatie naar eisen aan de ondersteuning. Welke functies zijn nodig? Welke gegevens moeten worden uitgewisseld, en met wie? Welke eisen gelden voor beveiliging, privacy en archivering? Leg daarnaast de principes vast waaraan elke oplossing moet voldoen, zoals eenmalige vastlegging van gegevens en aansluiting op bestaande voorzieningen. Zo wordt de keuze voor een systeem toetsbaar.

4. Kies pas dan de middelen

Nu pas is het moment om naar oplossingen te kijken. Soms blijkt een bestaand systeem met een betere inrichting voldoende. Soms is een standaardpakket de beste keuze, en is het verstandig het proces op het pakket aan te passen in plaats van andersom. Dat laatste kan heel goed werken, als de organisatie die keuze bewust maakt en de gevolgen voor de werkwijze in beeld heeft. Het verschil met de verkeerde volgorde is dat de organisatie nu weet wat zij kiest.

5. Voer in als verandering, niet als techniek

Een systeem invoeren is een verandering in hoe mensen werken. Behandel het ook zo: met een opdrachtgever uit de lijn, met aandacht voor draagvlak en met een overgangsfase waarin mensen de nieuwe werkwijze eigen kunnen maken. De technische ingebruikname is een mijlpaal, niet het einde. Hoe u dat organiseert, beschreef ik in Programmamanagement: integreren en veranderen tegelijk en Draagvlak creëren in projecten.

Wat ik in de praktijk zie

Wie ziet hoe een applicatielandschap in de loop der jaren uitgroeit tot honderden of zelfs duizenden applicaties, ziet vaak dezelfde oorzaak: voor elke nieuwe vraag is een nieuw pakket gekocht, zonder samenhangend beeld van processen en informatie. Het terugbrengen van zo’n landschap lukt alleen door de volgorde om te draaien: eerst de processen en de architectuur, dan pas de keuze welke applicaties blijven.

Een goede volgorde kost aan de voorkant tijd. Dat voelt als vertraging, zeker als er een leverancier klaarstaat. Maar zoals ik schreef in Haastige spoed is zelden goed: die tijd verdient zich vrijwel altijd terug. En de opdrachtgever die daarvoor ruimte maakt, bepaalt voor een groot deel of het resultaat ook echt iets oplevert. Meer daarover leest u in Opdrachtgeverschap: wie is nu eigenaar van wat?

Checklist: begint uw traject aan de goede kant?

Stap	Toetsvraag
Doelen	Is beschreven welk probleem wordt opgelost en wat er daarna anders moet zijn?
Processen	Zijn de betrokken processen in kaart gebracht, samen met de mensen die het werk doen?
Informatie	Is duidelijk welke informatie ontstaat, wie haar gebruikt en wie eigenaar is?
Eisen en principes	Zijn functionele eisen en architectuurprincipes vastgelegd voordat naar oplossingen is gekeken?
Bewuste keuze	Is bewust gekozen tussen aanpassen van het systeem en aanpassen van het proces?
Verandering	Is de invoering belegd bij een opdrachtgever uit de lijn, met aandacht voor de nieuwe werkwijze?

Veelgestelde vragen

Moet je het proces altijd eerst verbeteren voordat je een systeem kiest?

Niet altijd volledig, maar u moet het proces wel begrijpen. Soms is het verstandig het proces juist op een standaardpakket aan te passen. Dat werkt goed als u vooraf weet hoe het proces nu werkt, wat er beter moet en welke gevolgen de keuze voor het pakket heeft.

Waarom mislukken zoveel ict-implementaties?

Onderzoek laat zien dat veel problemen hun oorsprong hebben in de beginfase: het besluit en de keuze voor een oplossing worden genomen voordat doelen, processen en eisen helder zijn. Daarnaast wordt de invoering vaak als technisch project behandeld, terwijl het vooral een verandering in werkwijze is.

Wie moet het voortouw nemen bij de keuze voor een nieuw systeem?

De lijnorganisatie die het proces uitvoert, met ondersteuning van architectuur en ICT. De afdeling ICT kan goed beoordelen welke oplossingen technisch passen, maar de vragen over doelen en werkwijze horen bij de eigenaar van het proces.

Bronnen

• Davenport, T. H. (1998). Putting the enterprise into the enterprise system. Harvard Business Review, 76(4), 121–131.
• Hammer, M. (1990). Reengineering work: Don’t automate, obliterate. Harvard Business Review, 68(4), 104–112.
• Markus, M. L., & Tanis, C. (2000). The enterprise system experience: From adoption to success. In R. W. Zmud (Red.), Framing the domains of IT management: Projecting the future through the past (pp. 173–207). Pinnaflex Educational Resources.
• Robey, D., Ross, J. W., & Boudreau, M.-C. (2002). Learning to implement enterprise systems: An exploratory study of the dialectics of change. Journal of Management Information Systems, 19(1), 17–46.
• Ross, J. W., Weill, P., & Robertson, D. C. (2006). Enterprise architecture as strategy: Creating a foundation for business execution. Harvard Business School Press.