Den första vågen av business process reengineering misslyckades av ett ärligt skäl: dåtidens teknik kunde inte leverera det som teorin lovade. År 1993 kunde ett företag rita om en process på en whiteboard, men systemen därunder var stelbenta, batchbundna och svåra att integrera, så omkonstruktionen antingen körde fast vid stordatorns gräns eller urartade till en kostnadsbesparingsövning klädd i transformationens språk. Idén var sund och verktygen var det inte, och de två minns man tillsammans.

Den begränsningen har i stort sett upplösts. Programmeringsgränssnitt (API) är numera en standardförväntan snarare än ett skräddarsytt projekt. Event streaming, molnbaserade dataplattformar och orkestreringsmotorer gör det genomförbart att sätta samman en process som löper över flera transaktionssystem utan att data bärs för hand mellan dem. Det som en gång var en heroisk integration är nu vardaglig ingenjörskonst. Följden är att frågan om reengineering, länge uppskjuten eftersom den var för dyr att besvara, åter har blivit hanterbar, och den återvänder i de flesta organisationer under andra namn: omkonstruktion av order-till-betalning, kundintroduktion, leveransmotståndskraft, snabbare ekonomisk periodavslutning.

Frestelsen att skjuta upp frågan om reengineering är begriplig och inte längre riskfri. Under många år var det rationella att avvakta, eftersom integrationskostnaden för varje seriös omkonstruktion övervägde nyttan, och företag samlade på sig kringgående lösningar i den trygga förväntan att dessa skulle lösas vid nästa systemuppgradering. Så blev det sällan. Varje uppgradering bevarade den gamla processformen eftersom det var billigare att migrera formen än att ifrågasätta den, och den tillfälliga utformningen stelnade till en skenbar beständighet. Det som har förändrats är att konkurrenter som väl ställer frågan nu kan agera på svaret, och en process som tar dubbelt så lång tid eller kostar dubbelt så mycket döljs inte längre av att alla andra är lika långsamma.

Det finns ett andra skäl till att frågan är angelägen nu. Tre decennier av införande av företagsprogramvara har lämnat de flesta stora företag med ett CRM som modellerar kunden, ett ERP som modellerar transaktionen och ekonomin, och en försörjningskedjelösning som modellerar material och kapacitet, var och en konfigurerad av en olika funktion vid en olika tidpunkt enligt en olika logik. De processer som faktiskt skapar värde, att ta emot en order och verkställa den, att förvärva en kund och betjäna denna, att planera försörjning mot verklig efterfrågan, löper rakt igenom alla tre. Organisationen är ordnad efter funktion; arbetet är ordnat efter flöde; och glappet mellan de två är där kostnad, fördröjning och fel samlas. Reengineering är disciplinen att medvetet sluta det glappet snarare än att överskyla det med kalkylblad och god vilja.

Reengineeringens grundläggande insikt, och alltjämt den som uträttar mest, är att ett företag beskrivs mer sanningsenligt av sina processer än av sitt organisationsschema. Ett funktionscentrerat företag optimerar varje avdelning mot dess egna mål: försäljningen maximerar orderingång, verksamheten minimerar styckkostnad, ekonomin skyddar rörelsekapitalet. Var för sig är detta lokalt rationellt och summan är ofta globalt dålig, eftersom överlämningarna mellan funktioner, där kunden faktiskt väntar, tillhör ingen. Ett processcentrerat företag vänder på detta. Det namnger de flöden från början till slut som betyder något, ger vart och ett en ägare med verklig befogenhet över funktionsgränserna, och mäter flödet som helhet: förfluten tid, andel rätt från början, kostnad att betjäna, kassaomvandling.

Härav följer en svår förhandsfråga, som vi insisterar på att besvara innan någon omkonstruktion inleds: reengineera eller förbättra stegvis? De två är inte utbytbara, och att förväxla dem är dyrt åt båda hållen. Stegvis förbättring är rätt val när en process är grundläggande sund och blott inkrusterad av slöseri; här återbetalar sig verktygen inom lean och ständig förbättring snabbt och tryggt. Reengineering är motiverad endast när processen förkroppsligar antaganden som inte längre håller, när stegföljden existerar på grund av en begränsning som sedan dess har försvunnit, eller när det önskade utfallet är onåbart hur mycket man än trimmar den befintliga utformningen. Testet vi tillämpar är trubbigt. Om du inte hade kunnat komma fram till denna process genom att utforma för dagens utfall från ett blankt blad, är den en kandidat för omkonstruktion. Om du hade kunnat det, är den en kandidat för förbättring.

Den tredje principen är att en process som spänner över CRM, SCM och ERP inte kan omkonstrueras i enbart ett av dem. Kundregistret, produktregistret, prislogiken och ordertillståndet är delade fakta som lever, redundant och ofta inkonsekvent, i alla tre systemen. En genuin omkonstruktion måste avgöra var varje faktum författas, hur det sprids, och vilket system som är att lita på när de är oense. Detta är skälet till att vi behandlar data och integration inte som en efterföljande implementeringsfråga utan som själva substansen i utformningen. Processmodellen och datamodellen är två vyer av samma sak, och en reengineeringinsats som producerar vackra processdiagram och lämnar dataägandet olöst har i själva verket inte reengineerat någonting.

En fjärde princip underbygger de andra tre: en process, ett system och en organisation är inte tre saker att samordna utan en sak sedd ur tre vinklar. När de behandlas som separata arbetsströmmar med separat styrning optimerar var och en för sitt eget färdigställande, och de möts vid driftsättning i ömsesidig motsägelse. Systemet framtvingar ett flöde som organisationen inte är bemannad att köra mot data som processen antog var ren. Att utforma dem som ett enda beslut är intellektuellt mer krävande och långt billigare i praktiken, eftersom motsägelserna hittas på papper snarare än i produktion.

Området rör på sig, och inte alltid i den riktning som leverantörerna annonserar. Några mönster är värda att namnge rakt på sak eftersom de förändrar hur en omkonstruktion bör angripas.

Sammansättbarhet framför monoliten. Antagandet att en enda ERP-svit bör äga större delen av processen viker undan för en arkitektur av specialiserade system förenade genom integration. Kundengagemangslagret, planeringsmotorn, den ekonomiska kärnan och verkställandesystemen är alltmer åtskilda, valda utifrån sina förtjänster och sammansatta till ett flöde. Detta är befriande för processutformningen, eftersom du inte längre är bunden vid en leverantörs uppfattning om hur order-till-betalning bör fungera, men det flyttar svårigheten in i integrations- och styrningslagret, som nu bär den sammanhållning som monoliten brukade tillhandahålla.

Process mining som bevis. Under större delen av sin historia inleddes reengineering med workshoppar där människor beskrev hur de trodde att processen fungerade, vilket tillförlitligt var en fiktion. Process mining rekonstruerar den faktiska processen ur de händelseloggar som systemen redan avger, och visar varje variant, omarbetningsslinga och genväg så som den verkligen inträffar. Vi betraktar numera det att inleda en omkonstruktion utan detta bevis som nära på försumligt. Det ersätter åsikt med en uppmätt utgångspunkt och tillhandahåller senare det instrument som talar om huruvida omkonstruktionen beter sig som avsett i produktion.

Molnbaserat ERP och tvånivåverkligheten. Övergången till molnbaserat ERP säljs ofta in som en chans att återgå till standardprocesser och överge år av anpassningar, och för genuint vanligt arbete är det ett sunt råd. Men samma övergång stelnar ofta till ett landskap i två nivåer, en standardiserad kärna omgiven av de specialiserade system som bär ett företags verkliga särart. Utformningsfrågan är därför inte huruvida man ska anpassa utan var särarten legitimt hör hemma, att hålla kärnan nära standard samtidigt som ytterkanten tillåts skilja sig, och att integrera de två medvetet snarare än av en slump.

Automatisering som flyttar från uppgift till process. Den första generationens automatisering, i synnerhet robotic process automation, härmade mestadels en människa som klickar sig igenom skärmbilder, vilket befäste den befintliga processen snarare än att omkonstruera den. Det nyttigare mönstret nu är att automatisera det omkonstruerade flödet på processnivå, med hjälp av orkestrering och inbyggd integration, och att reservera automatisering på skärmnivå för de genuina ytterkanter där inget gränssnitt finns. Att automatisera en dålig process låter dig bara utföra den snabbare.

En omkonstruerad process är aldrig bättre än den arkitektur som bär den. Flera utformningsprinciper skiljer omkonstruktioner som håller från dem som i tysthet återgår.

En enda sanningskälla per faktum, inte per system. Instinkten att utropa ett system till mästare över allt är lika felaktig som att inte ha någon mästare alls. Disciplinen är finare: för varje betydande entitet och attribut, namnge exakt ett system som författar det, och låt de övriga prenumerera. CRM kan äga kundrelationen medan ERP äger det juridiska kontot och kreditpositionen; det som betyder något är att ägandet är uttryckligt, överenskommet och framtvingat, så att avstämning upphör att vara en månatlig ritual.

Integration som ett kontrakt, inte en anslutning. Punkt-till-punkt-gränssnitt byggda i hast blir den sköraste delen av systemlandskapet, eftersom vart och ett kodar in antaganden som ingen skrev ner. Vi utformar integration som versionshanterade kontrakt med definierade events, nyttolaster och semantik, förmedlade genom ett lager som kan absorbera förändring på endera sidan. Målet är att ett system ska kunna ersättas bakom sitt kontrakt utan att varje granne behöver veta om det.

Utforma processen för att vara observerbar. En process som inte kan mätas medan den pågår kan inte styras, och de flesta kan inte det. Vi bygger det omkonstruerade flödet så att dess tillstånd, dess tidsförlopp och dess undantag avges som events per konstruktion, och matar samma process mining som fastställde utgångspunkten. Observerbarhet är inte instrumentering tillagd i efterhand; det är en egenskap inbyggd från start, och det är det som gör att processen kan fortsätta förbättras efter att projektet avslutats.

Utforma för reversibilitet. En omkonstruktion som bara kan gå framåt är en omkonstruktion som kommer att mötas av motstånd, eftersom kostnaden för att ha fel är katastrofal. Vi bygger migreringen så att varje steg kan pausas, köras parallellt med det befintliga och rullas tillbaka om bevisen så kräver. Detta är inte försiktighet; det är det som gör djärvhet överkomlig. När en förändring kan reverseras billigt kommer en organisation att försöka sig på förändringar som den aldrig skulle riskera under en allt-eller-inget-omställning, och det är just dessa försök som ackumuleras till verklig transformation.

Utforma för undantaget, inte för lyckoscenariot. De flesta omkonstruktioner ritas för transaktionen som beter sig, och största delen av kostnaden ligger i dem som inte gör det: den partiella leveransen, den bestridda fakturan, kunden som existerar två gånger under något olika namn. En process som dirigerar sina undantag till ett kalkylblad och en villig individ har inte utformats; den har halvt utformats och lämnats åt mänsklig god vilja för resten. Vi modellerar undantagsvägarna uttryckligen, avgör vilka som är tillräckligt vanliga för att förtjäna en förstklassig väg genom systemet och vilka som är genuint sällsynta nog att överlämnas till genomtänkt manuellt arbete, och vi gör den distinktionen till ett medvetet val snarare än en slump av vad programvaran råkade stödja. Det verkliga måttet på en omkonstruktion är hur den beter sig på sin värsta tisdag, inte på sin bästa.

De sätt på vilka dessa program misslyckas är tillräckligt konsekventa för att katalogiseras, och de flesta är omdömesbrister snarare än teknikbrister.

Big-bang-utbyte av ERP. Det dyraste enskilda misstaget är att byta ut ERP och omkonstruera processerna i en enda samtidig omställning över hela företaget. Teorin är att en ren brytning undviker kostnaden för att köra två världar; praktiken är att risken ackumuleras, eftersom varje problem yttrar sig på en gång utan något sätt att isolera orsaken, och företaget förlorar förmågan att falla tillbaka. Vi föredrar omkonstruktion levererad per process och per domän, med det nya flödet bevisat på en avgränsad omfattning innan det breddas. En stegvis migrering är långsammare och långt mer sannolik att komma fram.

Att automatisera den befintliga röran. Ett program som kartlägger den nuvarande processen, automatiserar den troget och kallar resultatet transformation har lagt mycket stora summor på att röra sig snabbare i fel riktning. Automatisering bör följa på omkonstruktion, aldrig ersätta den.

Att reengineera diagrammet, inte organisationen. En omkonstruktion som förändrar systemet och processen men lämnar incitament, roller och rapporteringsvägar orörda kommer i tysthet att återföras av de människor den besvärar. Om processen nu är tvärfunktionell men bonusarna förblir funktionella, vinner de funktionella målen. Processägande utan befogenhet är dekoration.

Uppskjuten dataskuld. Team skjuter rutinmässigt upp arbetet med stamdata och kvalitet som oglamoröst, med avsikten att ta itu med det senare. Senare möter den omkonstruerade processen, som antog ren och konsekvent data, den verkliga varan och kör fast. Datakvalitet är inte en upprensningsuppgift vid sidan av projektet; det är en förutsättning för att processen över huvud taget ska fungera. Konsultledd utformning utan operatörer i rummet förvärrar detta: en omkonstruktion helt uppritad av specialister kommer att missa den tysta kunskapen hos de människor som sköter arbetet, skälet till att ett steg som ser överflödigt ut i själva verket är bärande, undantaget som inträffar varje vecka och som aldrig dokumenterades. När dessa operatörer först stöter på den nya processen vid utbildningen upptäcker de dess luckor, och deras förtroende, väl förlorat, är dyrt att återvinna.

Omfattning efter system snarare än efter utfall. Program som stadgas som ett ERP-projekt eller ett CRM-projekt ärver programvarans gränser snarare än arbetets gränser, och de systemövergripande flödena, som är just där värdet ligger, faller ned i glappen mellan strömmarna. Stadgan bör namnge ett utfall och ett flöde, och låta systemen falla inom det.

Vi utgår från flödet och utfallet, inte från systemet. Innan vi föreslår någon förändring fastställer vi vad processen från början till slut är avsedd att uppnå i termer som företaget känner igen, förfluten tid, kostnad att betjäna, kassaomvandling, kundansträngning, och vi mäter det nuvarande tillståndet mot detta med hjälp av de händelsedata som systemen redan innehåller snarare än den berättelse människor återger i workshoppar. Den uppmätta utgångspunkten avgör den första tvisten, huruvida processen förtjänar reengineering eller förbättring, på bevis snarare än på entusiasm.

Där omkonstruktion är motiverad utformar vi processen, datamodellen och integrationen tillsammans, och behandlar dem som tre vyer av ett enda beslut snarare än tre sekventiella projekt. Vi löser ägandet av varje delat faktum över CRM, SCM och ERP uttryckligen, definierar integrationen som versionshanterade kontrakt, och gör orkestreringen av flödet till en granskningsbar artefakt snarare än logik utspridd genom konfigurationen. Den omkonstruerade processen byggs för att avge sitt eget tillstånd, så att den kan mätas i produktion mot samma utgångspunkt som motiverade den.

Vi levererar per domän och per flöde, aldrig genom en big-bang-omställning. En avgränsad skiva av den omkonstruerade processen bevisas i produktion, på verkliga transaktioner, innan den breddas, så att risken hålls isolerad och företaget behåller förmågan att falla tillbaka. Genomgående behandlar vi den organisatoriska förändringen, ägandet, incitamenten, rollerna, som en del av ingenjörsarbetet snarare än som en eftertanke, eftersom en process som organisationen inte är ordnad att köra inte kommer att överleva. Vårt mål är en omkonstruktion som fortsätter förbättras efter att vi lämnat, eftersom instrumenten för att styra den byggdes in redan från start.

Vi är uppriktiga om takten. En omkonstruktion som spänner över tre transaktionssystem kan ärligt talat inte färdigställas på ett kvartal, och varje förslag som lovar det säljer en omställning snarare än en omkonstruktion. Vi sekvenserar arbetet så att varje domän ger en mätbar förbättring på egen hand, vilket förtjänar det förtroende och den uppmärksamhet som behövs för nästa, snarare än att be företaget hålla andan genom ett flerårigt program för en enda avlägsen belöning. Den sekvenseringen disciplinerar också själva utformningen: ett flöde som är förpliktigat att bevisa sitt värde på en avgränsad skiva kan inte gömma sig bakom löftet att allt kommer att hänga ihop till slut. Om en skiva misslyckas med att förbättra det utfall den stadgades att förbättra, upptäcker vi det långt hellre på en domän än på alla tre samtidigt.

Det som utmärker vårt arbete inom process reengineering är att vi vägrar behandla CRM, försörjningskedja och ERP som separata territorier med separata omkonstruktioner. Vi håller flödet från början till slut, de data som löper genom det och den organisation som driver det i en enda vy, och vi löser de svåra frågorna om ägande och integration som utformningsbeslut snarare än att skjuta upp dem till implementeringen. Det är ett svårare samtal att inleda och ett långt mer varaktigt resultat att slutföra.

Det finns också en praktisk följd som förändrar vad arbetet tillåts anta. När ett uppdrag kräver en förmåga som ännu inte existerar behöver det inte invänta en inköpscykel eller en leverantörs färdplan. enterprise platform är byggd för att kunna rymma nästan vilken funktion som helst i högt tempo, genom agentic engineering: det som behövs beskrivs i klarspråk och genereras snabbt, men alltid inom fasta arkitekturprinciper och under sträng kvalitetssäkring, så att snabbhet aldrig sker på bekostnad av sammanhållning, säkerhet eller kontroll. Effekten är strategisk snarare än enbart bekväm. Den flyttar gränsen mellan att bygga och köpa, håller valfriheten billig, och låter arkitekturen följa strategin snarare än att strategin böjer sig efter vad som råkade finnas på hyllan.

Belöningen för denna disciplin är en uppsättning kärnprocesser som gör det företaget faktiskt behöver, mätt mot utfall det bryr sig om, buren av en arkitektur som kan förändras utan att gå sönder, och driven av en organisation ordnad att driva dem. Det är vad reengineering alltid var avsett att leverera, och med dagens verktyg kan den äntligen göra det.