De eerste golf van business process reengineering mislukte om een eerlijke reden: de technologie van die tijd kon niet leveren wat de theorie beloofde. In 1993 kon een bedrijf een proces opnieuw tekenen op een whiteboard, maar de onderliggende systemen waren star, batchgebonden en moeilijk te integreren, waardoor het herontwerp ofwel vastliep bij de grens van de mainframe ofwel ontaardde in een bezuinigingsoefening verpakt in de taal van transformatie. Het idee was gezond en het instrumentarium niet, en de twee werden samen herinnerd.

Die beperking is grotendeels verdwenen. Application programming interfaces zijn nu een standaardverwachting in plaats van een maatwerkproject. Event streaming, cloud dataplatforms en orchestration engines maken het haalbaar om een proces samen te stellen dat over meerdere systems of record loopt zonder data handmatig tussen die systemen te verplaatsen. Wat ooit een heroïsche integratie was, is nu gewone engineering. Het gevolg is dat de vraag naar reengineering, lang uitgesteld omdat het te duur was om te beantwoorden, weer hanteerbaar is geworden, en in de meeste organisaties terugkeert onder andere namen: order-to-cash-herontwerp, klant-onboarding, leveringsveerkracht, versnelling van de financiële afsluiting.

De verleiding om de vraag naar reengineering uit te stellen is begrijpelijk en niet langer veilig. Jarenlang was de rationele koers om te wachten, omdat de integratiekosten van elk serieus herontwerp niet opwogen tegen de baten, en bedrijven verzamelden noodoplossingen in de vaste verwachting dat die bij de volgende systeemupgrade zouden worden opgelost. Dat gebeurde zelden. Elke upgrade behield de oude procesvorm, omdat het migreren van de vorm goedkoper was dan die in twijfel trekken, en het toevallige ontwerp verhardde tot schijnbare permanentie. Wat is veranderd, is dat concurrenten die de vraag wél stellen nu naar het antwoord kunnen handelen, en een proces dat twee keer zo lang duurt of twee keer zoveel kost, wordt niet langer verhuld doordat iedereen even traag is.

Er is een tweede reden waarom de vraag er nu toe doet. Drie decennia van adoptie van bedrijfssoftware hebben de meeste grote bedrijven achtergelaten met een CRM die de klant modelleert, een ERP die de transactie en financiën modelleert, en een supply chain-suite die materiaal en capaciteit modelleert, elk geconfigureerd door een andere functie op een ander moment volgens een andere logica. De processen die daadwerkelijk waarde creëren, een order aannemen en uitvoeren, een klant werven en bedienen, aanbod plannen tegen echte vraag, lopen dwars door alle drie heen. De organisatie is ingedeeld naar functie; het werk is ingedeeld naar stroom; en de kloof tussen die twee is waar kosten, vertraging en fouten zich verzamelen. Reengineering is de discipline om die kloof doelbewust te dichten in plaats van hem te camoufleren met spreadsheets en goodwill.

Het fundamentele inzicht van reengineering, en nog altijd het inzicht dat het meeste werk verzet, is dat een onderneming waarheidsgetrouwer wordt beschreven door haar processen dan door haar organisatieschema. Een functiegericht bedrijf optimaliseert elke afdeling tegen haar eigen doelen: sales maximaliseert boekingen, operations minimaliseert de kostprijs per eenheid, finance beschermt het werkkapitaal. Elk is lokaal rationeel en de som is vaak globaal slecht, omdat de overdrachten tussen functies, waar de klant daadwerkelijk wacht, van niemand zijn. Een procesgericht bedrijf keert dit om. Het benoemt de end-to-end stromen die ertoe doen, geeft elk een eigenaar met werkelijke autoriteit over functionele grenzen heen, en meet de stroom als geheel: doorlooptijd, first-pass yield, cost to serve, cash conversion.

Hieruit volgt een harde voorafgaande vraag, die wij erop staan te beantwoorden voordat enig herontwerp begint: reengineeren, of stapsgewijs verbeteren? De twee zijn niet uitwisselbaar, en ze verwarren is in beide richtingen kostbaar. Stapsgewijze verbetering is de juiste keuze wanneer een proces fundamenteel gezond is en slechts is bedekt met verspilling; hier betalen de instrumenten van lean en continue verbetering zich snel en veilig terug. Reengineering is alleen gerechtvaardigd wanneer het proces aannames belichaamt die niet langer gelden, wanneer de volgorde van stappen bestaat vanwege een beperking die inmiddels is verdwenen, of wanneer de gewenste uitkomst met geen enkele mate van verfijning van het bestaande ontwerp bereikbaar is. De toets die wij hanteren is bot. Als u niet bij dit proces had kunnen uitkomen door te ontwerpen voor de uitkomst van vandaag vanaf een leeg vel, dan is het een kandidaat voor herontwerp. Als u dat wel had gekund, dan is het een kandidaat voor verbetering.

Het derde principe is dat een proces dat CRM, SCM en ERP overspant niet in één daarvan alleen kan worden herontworpen. De customer master, de product master, de prijslogica en de orderstatus zijn gedeelde feiten die, redundant en vaak inconsistent, in alle drie de systemen leven. Een echt herontwerp moet beslissen waar elk feit wordt vastgelegd, hoe het zich voortplant, en welk systeem wordt vertrouwd wanneer ze het oneens zijn. Daarom behandelen wij data en integratie niet als een stroomafwaartse implementatiezorg maar als de substantie van het ontwerp zelf. Het procesmodel en het datamodel zijn twee weergaven van hetzelfde ding, en een reengineering-inspanning die prachtige procesdiagrammen oplevert en het eigenaarschap van data onopgelost laat, heeft in werkelijkheid niets gereengineerd.

Een vierde principe schraagt de andere drie: een proces, een systeem en een organisatie zijn geen drie dingen die op elkaar moeten worden afgestemd maar één ding gezien vanuit drie invalshoeken. Wanneer ze worden behandeld als afzonderlijke werkstromen met afzonderlijke governance, optimaliseert elk voor zijn eigen voltooiing, en ontmoeten ze elkaar bij livegang in wederzijdse tegenspraak. Het systeem dwingt een stroom af waarvoor de organisatie niet is bemenst, op data waarvan het proces aannam dat die schoon was. Ze als één beslissing ontwerpen is intellectueel veeleisender en in de praktijk veel goedkoper, omdat de tegenstrijdigheden op papier worden gevonden in plaats van in productie.

Het vakgebied is in beweging, en niet altijd in de richting die de leveranciers adverteren. Enkele patronen zijn het waard om helder te benoemen, omdat ze veranderen hoe een herontwerp moet worden aangepakt.

Componeerbaarheid boven de monoliet. De aanname dat één ERP-suite het grootste deel van het proces zou moeten bezitten, maakt plaats voor een architectuur van gespecialiseerde systemen die door integratie worden verbonden. De laag voor klantinteractie, de planning engine, de financiële kern en de fulfilmentsystemen zijn steeds vaker afzonderlijk, gekozen op hun eigen merites en samengesteld tot een stroom. Dit is bevrijdend voor procesontwerp, omdat u niet langer gebonden bent aan de opvatting van één leverancier over hoe order-to-cash zou moeten werken, maar het verplaatst de moeilijkheid naar de integratie- en governancelaag, die nu de samenhang draagt die de monoliet vroeger bood.

Process mining als bewijs. Gedurende het grootste deel van haar geschiedenis begon reengineering met workshops waarin mensen beschreven hoe zij dachten dat het proces werkte, wat betrouwbaar een fictie was. Process mining reconstrueert het werkelijke proces uit de event logs die de systemen al uitzenden, en toont elke variant, herstellus en omweg zoals die zich werkelijk voordoet. Wij beschouwen het beginnen van een herontwerp zonder dit bewijs inmiddels als bijna nalatig. Het vervangt opinie door een gemeten baseline en levert later het instrument dat u vertelt of het herontwerp zich in productie gedraagt zoals bedoeld.

Cloud ERP en de tweelaagse realiteit. De overgang naar cloud ERP wordt vaak verkocht als een kans om terug te keren naar standaardprocessen en jaren van maatwerk los te laten, en voor werkelijk generiek werk is dat gezond advies. Maar dezelfde overgang verhardt vaak tot een tweelaags landschap, een gestandaardiseerde kern omringd door de gespecialiseerde systemen die het werkelijke onderscheidend vermogen van een bedrijf dragen. De ontwerpvraag is daarom niet of er maatwerk moet komen maar waar onderscheidend vermogen legitiem thuishoort, waarbij de kern dicht bij de standaard wordt gehouden terwijl de rand mag afwijken, en de twee doelbewust worden geïntegreerd in plaats van bij toeval.

Automatisering die verschuift van taak naar proces. De eerste generatie automatisering, robotic process automation in het bijzonder, bootste vooral een mens na die door schermen klikte, wat het bestaande proces bestendigde in plaats van het te herontwerpen. Het nuttiger patroon nu is om de herontworpen stroom te automatiseren op het niveau van het proces, met behulp van orchestration en native integratie, en automatisering op schermniveau te reserveren voor de echte randen waar geen interface bestaat. Een slecht proces automatiseren laat u het alleen sneller uitvoeren.

Een gereengineerd proces is slechts zo goed als de architectuur die het draagt. Verschillende ontwerpprincipes onderscheiden herontwerpen die standhouden van herontwerpen die stilletjes terugvallen.

Eén bron van waarheid per feit, niet per systeem. De neiging om één systeem tot master van alles te bestempelen is even onjuist als helemaal geen master hebben. De discipline is fijner: benoem voor elke betekenisvolle entiteit en attribuut precies één systeem dat het vastlegt, en laat de andere zich abonneren. Het CRM mag de klantrelatie bezitten terwijl het ERP de juridische rekening en kredietpositie bezit; wat telt is dat het eigenaarschap expliciet, overeengekomen en afgedwongen is, zodat reconciliatie ophoudt een maandelijks ritueel te zijn.

Integratie als een contract, niet een verbinding. Point-to-point interfaces die in haast zijn gebouwd worden het meest broze deel van het systeemlandschap, omdat elk aannames codeert die niemand heeft opgeschreven. Wij ontwerpen integratie als geversioneerde contracten met gedefinieerde events, payloads en semantiek, gemedieerd door een laag die verandering aan weerszijden kan opvangen. Het doel is dat een systeem achter zijn contract kan worden vervangen zonder dat elke buur het hoeft te weten.

Ontwerp het proces zodat het waarneembaar is. Een proces dat niet in vlucht kan worden gemeten kan niet worden beheerd, en de meeste kunnen dat niet. Wij bouwen de herontworpen stroom zo dat zijn status, zijn timings en zijn uitzonderingen door constructie als events worden uitgezonden, en dezelfde process mining voeden die de baseline vaststelde. Waarneembaarheid is geen instrumentatie die achteraf wordt toegevoegd; het is een eigenschap die wordt ingeontworpen, en het is wat het proces in staat stelt te blijven verbeteren nadat het project eindigt.

Ontwerp voor omkeerbaarheid. Een herontwerp dat alleen vooruit kan is een herontwerp waartegen weerstand zal ontstaan, omdat de kosten van ongelijk hebben catastrofaal zijn. Wij bouwen de migratie zo dat elke stap kan worden gepauzeerd, parallel aan de bestaande situatie kan draaien, en kan worden teruggedraaid als het bewijs dat vereist. Dit is geen schroom; het is wat durf betaalbaar maakt. Wanneer een verandering goedkoop kan worden teruggedraaid, zal een organisatie veranderingen aandurven die ze onder een alles-of-niets-overstap nooit zou riskeren, en het zijn juist die pogingen die zich samenvoegen tot werkelijke transformatie.

Ontwerp voor de uitzondering, niet voor het gelukspad. De meeste herontwerpen worden getekend voor de transactie die zich netjes gedraagt, en het grootste deel van de kosten zit in de transacties die dat niet doen: de deellevering, de betwiste factuur, de klant die twee keer bestaat onder licht verschillende namen. Een proces dat zijn uitzonderingen naar een spreadsheet en een bereidwillig individu leidt, is niet ontworpen; het is half ontworpen en voor de rest overgelaten aan menselijke goodwill. Wij modelleren de uitzonderingspaden expliciet, beslissen welke vaak genoeg voorkomen om een eersteklas route door het systeem te verdienen en welke werkelijk zeldzaam genoeg zijn om aan doordacht handmatig werk over te laten, en wij maken dat onderscheid een doelbewuste keuze in plaats van een toevalligheid van wat de software nu eenmaal ondersteunde. De ware maat van een herontwerp is hoe het zich gedraagt op zijn slechtste dinsdag, niet op zijn beste.

De manieren waarop deze programma's mislukken zijn consistent genoeg om te catalogiseren, en de meeste zijn falen van oordeel in plaats van technologie.

Big-bang ERP-vervanging. De duurste enkelvoudige fout is om het ERP te vervangen en de processen te reengineeren in één gelijktijdige overstap over de hele onderneming. De theorie is dat een schone breuk de kosten van het draaien van twee werelden vermijdt; de praktijk is dat risico zich opstapelt, omdat elk probleem tegelijk opduikt zonder mogelijkheid om de oorzaak te isoleren, en de onderneming het vermogen verliest om terug te vallen. Wij geven de voorkeur aan een herontwerp dat per proces en per domein wordt geleverd, waarbij de nieuwe stroom op een begrensde reikwijdte wordt bewezen voordat hij wordt verbreed. Een gefaseerde migratie is trager en veel waarschijnlijker om aan te komen.

De bestaande rommel automatiseren. Een programma dat het huidige proces in kaart brengt, het getrouw automatiseert en het resultaat transformatie noemt, heeft veel uitgegeven om sneller in de verkeerde richting te bewegen. Automatisering moet volgen op herontwerp, nooit ervoor in de plaats komen.

Het diagram reengineeren, niet de organisatie. Een herontwerp dat het systeem en het proces verandert maar de prikkels, rollen en rapportagelijnen onaangeroerd laat, zal stilletjes worden teruggedraaid door de mensen die het hindert. Als het proces nu functie-overstijgend is maar de bonussen functioneel blijven, winnen de functionele doelen. Proceseigenaarschap zonder autoriteit is decoratie.

Uitgestelde dataschuld. Teams stellen het werk aan master data en kwaliteit routinematig uit als onglamoureus, met de bedoeling het later aan te pakken. Later ontmoet het herontworpen proces, dat schone en consistente data aannam, het echte ding en loopt vast. Datakwaliteit is geen opschoontaak naast het project; het is een voorwaarde voor het überhaupt werken van het proces. Consultant-geleid ontwerp zonder operators in de ruimte versterkt dit: een herontwerp dat volledig door specialisten wordt getekend zal de impliciete kennis missen van de mensen die het werk uitvoeren, de reden waarom een stap die overbodig lijkt in werkelijkheid dragend is, de uitzondering die wekelijks optreedt en nooit is gedocumenteerd. Wanneer die operators het nieuwe proces voor het eerst tegenkomen bij de training, ontdekken ze de gaten, en hun vertrouwen, eenmaal verloren, is kostbaar om te herstellen.

Reikwijdte per systeem in plaats van per uitkomst. Programma's die worden opgezet als een ERP-project of een CRM-project erven de grenzen van de software in plaats van de grenzen van het werk, en de systeemoverstijgende stromen, die nu juist zijn waar de waarde zit, vallen in de gaten tussen de werkstromen. Het charter moet een uitkomst en een stroom benoemen, en de systemen daarbinnen laten vallen.

Wij beginnen bij de stroom en de uitkomst, niet bij het systeem. Voordat wij enige verandering voorstellen, stellen wij vast wat het end-to-end proces geacht wordt te bereiken in termen die de onderneming zal herkennen, doorlooptijd, cost to serve, cash conversion, klantinspanning, en wij meten de huidige toestand daartegen af met de event-data die de systemen al bevatten in plaats van het verhaal dat mensen in workshops vertellen. Die gemeten baseline beslecht het eerste dispuut, of het proces reengineering dan wel verbetering verdient, op bewijs in plaats van enthousiasme.

Waar herontwerp gerechtvaardigd is, ontwerpen wij het proces, het datamodel en de integratie samen, en behandelen wij ze als drie weergaven van één beslissing in plaats van drie opeenvolgende projecten. Wij lossen het eigenaarschap van elk gedeeld feit over CRM, SCM en ERP expliciet op, definiëren de integratie als geversioneerde contracten, en maken de orchestration van de stroom een inspecteerbaar artefact in plaats van logica verspreid door de configuratie. Het herontworpen proces is gebouwd om zijn eigen status uit te zenden, zodat het in productie kan worden gemeten tegen dezelfde baseline die het rechtvaardigde.

Wij leveren per domein en per stroom, nooit per big-bang-overstap. Een begrensd deel van het herontworpen proces wordt in productie bewezen, op echte transacties, voordat het wordt verbreed, zodat het risico geïsoleerd blijft en de onderneming het vermogen behoudt om terug te vallen. Gedurende het geheel behandelen wij de organisatorische verandering, het eigenaarschap, de prikkels, de rollen, als onderdeel van de engineering in plaats van als een bijzaak, omdat een proces waarvoor de organisatie niet is ingericht om het uit te voeren niet zal overleven. Ons doel is een herontwerp dat blijft verbeteren nadat wij vertrekken, omdat de instrumenten om het te beheren vanaf het begin zijn ingebouwd.

Wij zijn openhartig over tempo. Een herontwerp dat drie systems of record overspant kan niet eerlijk in een kwartaal worden voltooid, en elk voorstel dat dat belooft verkoopt een overstap in plaats van een herontwerp. Wij ordenen het werk zo dat elk domein op zichzelf een meetbare verbetering oplevert, wat het vertrouwen en de aandacht verdient die nodig zijn voor het volgende, in plaats van de onderneming te vragen haar adem in te houden gedurende een meerjarig programma voor één verre beloning. Die ordening disciplineert ook het ontwerp zelf: een stroom die verplicht is zijn waarde op een begrensd deel te bewijzen kan zich niet verschuilen achter de belofte dat aan het eind alles zal samenvallen. Als een deel de uitkomst die het geacht werd te verbeteren niet verbetert, ontdekken wij dat veel liever op één domein dan op alle drie tegelijk.

Wat ons werk in procesreengineering onderscheidt, is dat wij weigeren om CRM, supply chain en ERP te behandelen als afzonderlijke territoria met afzonderlijke herontwerpen. Wij houden de end-to-end stroom, de data die er doorheen loopt en de organisatie die haar bedient in één blikveld, en wij lossen de moeilijke vragen van eigenaarschap en integratie op als ontwerpbeslissingen in plaats van ze uit te stellen tot de implementatie. Dat is een moeilijker gesprek om te beginnen en een veel duurzamer resultaat om af te ronden.

Er is ook een praktisch uitvloeisel dat verandert wat het werk mag aannemen. Wanneer een opdracht een capaciteit vereist die nog niet bestaat, hoeft die niet te wachten op een inkoopcyclus of de roadmap van een leverancier. Het Nashua 360 Enterprise Platform is gebouwd om vrijwel elke functie in hoog tempo te accommoderen, via extreme vibe coding: wat nodig is wordt in gewone taal beschreven en snel gegenereerd, maar altijd binnen vaste architectuurprincipes en onder strikte kwaliteitsborging, zodat snelheid nooit ten koste gaat van samenhang, beveiliging of controle. Het effect is strategisch in plaats van louter handig. Het verschuift de make-or-buy-grens, houdt optionaliteit goedkoop, en laat de architectuur de strategie volgen in plaats van de strategie te laten buigen naar wat er nu eenmaal op de plank lag.

De beloning voor deze discipline is een reeks kernprocessen die doen wat de onderneming werkelijk nodig heeft, afgemeten aan uitkomsten waar zij om geeft, gedragen door een architectuur die kan veranderen zonder te breken, en uitgevoerd door een organisatie die is ingericht om ze uit te voeren. Dat is wat reengineering altijd geacht werd te leveren, en met het instrumentarium van vandaag kan het dat eindelijk.