Een paar jaar geleden besluit een industrieel bedrijf zijn ERP te moderniseren. Een project van 18 maanden, een budget met zeven cijfers, een bekende integrator. Het IT-team documenteert het bestaande systeem, maakt een lijst van functies, migreert module voor module. Op tijd opgeleverd. Gebruikers ontevreden. Processen even zwaar — op een nieuw platform.
Dit was geen IT-falen. Het was een methodefalen.
Het symptoom — en hoe u het herkent
“Dat kunnen we niet doen. Het systeem ondersteunt het niet.”
Als u deze zin in uw organisatie heeft gehoord, kent u het onderliggende probleem. Uw bedrijfsprocessen hebben zich geleidelijk aangepast aan uw IT-beperkingen. Niet andersom. Wat een hulpmiddel had moeten zijn, is de referentie geworden: het systeem bepaalt hoe u werkt, niet uw bedrijf dat bepaalt wat het systeem moet doen.
Het meest onthullende teken zit in de taal.
Ik werkte met een adviesbureau waar iedereen het had over “urenregistratie” — één concept in hun systeem. Toen we er tijdens een domeinmodelleringsoefening op doorgingen, ontdekten we dat het minstens drie afzonderlijke bedrijfsbehoeften omvatte.
HR keek naar die uren voor salarisadministratie en talentmanagement. De projectmanager keek ernaar om de contractrentabiliteit bij te houden. De resourcedirecteur keek ernaar om onderbelaste consultants te identificeren en teams te herbalanceren — overbelaste medewerkers ontlasten, beschikbare medewerkers inzetten.
Drie toepassingen. Drie granulariteiten. Drie verschillende tijdlijnen. Maar omdat het systeem slechts één concept kende, had niemand ooit deze kunstmatige eenheid in twijfel getrokken. We ontdekten, aan het einde van de oefening, dat HR en de resourcedirecteur niet dezelfde gegevens nodig hadden. Het systeem had hen in de illusie gehouden dat ze over hetzelfde spraken.
Wanneer uw team het vocabulaire van uw systeem gebruikt om uw bedrijfsrealiteit te beschrijven, is de besmetting volledig.
De klassieke fout bij moderniseringsprojecten
Wanneer een bedrijf besluit te moderniseren, is de eerste vraag bijna altijd dezelfde: “Wat hebben we?”
Het IT-team wordt erbij geroepen, het bestaande systeem wordt geauditeerd, functies worden opgesomd, stromen worden in kaart gebracht. Dan wordt aan de integrators gevraagd: “Hoe migreren we dit?”
Het resultaat is voorspelbaar: een nieuw systeem dat de organisatie van het oude reproduceert. Nieuwe stack, dezelfde beperkingen. Nieuw contract, dezelfde frustratie. Het budget is besteed, het project is opgeleverd — maar het onderliggende probleem is nooit aangepakt.
Beginnen vanuit wat bestaat om de toekomst te definiëren, garandeert dat de toekomst op het heden lijkt.
Probleemruimte en oplossingsruimte — het onderscheid dat alles verandert
Er zijn twee fundamenteel verschillende vragen in een moderniseringsproject.
De eerste: wat heeft uw bedrijf werkelijk nodig om te doen? Wat zijn uw echte bedrijfsregels — die voortkomen uit uw regelgevende beperkingen, uw waardeketen, uw klanten? Onafhankelijk van hoe uw huidige systeem werkt.
Dit wordt de probleemruimte genoemd: de realiteit van uw bedrijfsdomein, bevrijd van technische beperkingen. “Urenregistratie” bestaat niet in de probleemruimte. Er is salarisadministratie, contractaansturing en resourcetoewijzing — drie afzonderlijke concepten met hun eigen regels, hun eigen stakeholders, hun eigen gegevensbehoeften.
De tweede: hoe zal technologie die realiteit dienen? Met welke systemen, integraties, budget- en haalbaarheidsrestricties? Dit is de oplossingsruimte: de doelarchitectuur, met realistische afwegingen.
De volgorde is niet onderhandelbaar. Probleemruimte eerst. Oplossingsruimte daarna. Het omgekeerde produceert systemen die verwarring bestendigen in plaats van oplossen.
Waarom de volgorde bijna altijd omgekeerd is
IT-teams beginnen vanuit wat ze kennen. Dat is menselijk. Het bestaande documenteren is tastbaar, geruststellend, factureerbaar. Modelleren wat het bedrijf zou moeten doen — onafhankelijk van wat het vandaag doet — is ongemakkelijk en wordt vaak als theoretisch beschouwd.
Leveranciers en integrators worden niet gestimuleerd om deze vraag te stellen. Ze zijn ingehuurd om een systeem op te leveren, niet om vereisten te betwisten. Hoe complexer het bestaande systeem, hoe duurder de migratie.
En het bedrijf zelf heeft moeite om zijn behoeften te formuleren buiten zijn huidige beperkingen. Wanneer u een operationeel directeur vraagt “hoe zou uw proces er idealiter uitzien?”, begint het antwoord bijna altijd met “nou, wat we momenteel doen is…”. Het bedrijfsdomein is nooit geformaliseerd. Het leeft in gewoonten, in omwegen, in interne trainingen. En in het vocabulaire van het systeem.
Wat dit in de praktijk verandert
Ik werkte aan een moderniseringsproject waarbij we drie maanden besteedden aan het modelleren van het bedrijfsdomein voordat we iets in het bestaande systeem aanraakten. Drie maanden die bij elke stuurgroep bijna uit het plan werden geschrapt. “We verliezen tijd.”
Wat we ontdekten: een aanzienlijk deel van de “beperkingen” die het IT-team als vaststaande feiten beschouwde, waren in werkelijkheid bedrijfsregels die nooit waren geformaliseerd — soms tegengesproken door wat de operationele teams daadwerkelijk deden. Hele use cases onzichtbaar in het huidige systeem, niet omdat ze niet bestonden, maar omdat ze zo lang waren omzeild dat ze onzichtbaar waren geworden.
Het uiteindelijke migratieplan was radicaal anders dan wat we hadden geproduceerd als we vanuit het bestaande systeem waren begonnen. Minder modules om te migreren. Meer waarde in de eerste twaalf maanden. Minder technische schuld vanaf dag één.
Het domein modelleren zonder legacy-beperkingen is geen fout. Het is de voorwaarde om te weten welke beperkingen er echt toe doen.
Dus, concreet
Voordat u aan uw volgende moderniseringsproject begint, één vraag aan uw team of leverancier: “Waar begint u — met wat we hebben, of met wat we moeten doen?”
Als het antwoord begint met de audit van het bestaande systeem, is het risico aanwezig.
Een project dat begint vanuit het bedrijfsdomein kost meer tijd aan het begin. Het levert minder verwarring op de lange termijn, minder herschrijvingen zes maanden na de livegang, en een resultaat dat uw bedrijf dient — niet uw IT-systeem van 2014.
Dat is het eerste wat ik doe in elk Architectuur Assessment: het domein modelleren voordat ik iets voorstel.
Als u CTO bent in plaats van CEO en u beheert deze discipline onder leveringsdruk, dit artikel behandelt de specifieke valkuil voor teams in uitvoering →