Den første bølge af business process reengineering slog fejl af en ærlig grund: datidens teknologi kunne ikke levere det, teorien lovede. I 1993 kunne en virksomhed gentegne en proces på en whiteboardtavle, men systemerne nedenunder var stive, batchbundne og vanskelige at integrere, så nytænkningen enten gik i stå ved mainframens grænse eller degenererede til en spareøvelse iklædt transformationens sprog. Idéen var solid, og værktøjerne var det ikke, og de to blev husket sammen.

Den begrænsning er stort set opløst. Application programming interfaces er nu en standardforventning snarere end et skræddersyet projekt. Event streaming, cloud-dataplatforme og orkestreringsmotorer gør det muligt at sammensætte en proces, der kører på tværs af flere registreringssystemer uden at bære data mellem dem i hånden. Hvad der engang var en heroisk integration, er nu ganske almindelig ingeniørkunst. Konsekvensen er, at spørgsmålet om reengineering, som længe blev udskudt, fordi det var for dyrt at besvare, igen er blevet håndterbart, og det vender tilbage i de fleste organisationer under andre navne: nytænkning af order-to-cash, kundeonboarding, forsyningsrobusthed, acceleration af finansafslutningen.

Fristelsen til at udskyde spørgsmålet om reengineering er forståelig og ikke længere sikker. I årevis var den rationelle kurs at vente, fordi integrationsomkostningen ved enhver seriøs nytænkning oversteg gevinsten, og virksomheder ophobede omgåelsesløsninger i den trygge forventning om, at de ville blive løst ved næste systemopgradering. Det blev de sjældent. Hver opgradering bevarede den gamle procesform, fordi det var billigere at migrere formen end at sætte spørgsmålstegn ved den, og det tilfældige design hærdede til tilsyneladende permanens. Det, der har ændret sig, er, at konkurrenter, som faktisk stiller spørgsmålet, nu kan handle på svaret, og en proces, der tager dobbelt så lang tid eller koster dobbelt så meget, skjules ikke længere af, at alle andre er lige så langsomme.

Der er endnu en grund til, at spørgsmålet betyder noget nu. Tre årtiers indførelse af enterprise-software har efterladt de fleste store virksomheder med et CRM, der modellerer kunden, et ERP, der modellerer transaktionen og økonomien, og en forsyningskædesuite, der modellerer materiale og kapacitet, hver konfigureret af en forskellig funktion på et forskelligt tidspunkt efter en forskellig logik. De processer, der faktisk skaber værdi, at modtage en ordre og opfylde den, at erhverve en kunde og betjene ham, at planlægge forsyning ud fra reel efterspørgsel, løber lige tværs igennem alle tre. Organisationen er indrettet efter funktion; arbejdet er indrettet efter flow; og kløften mellem de to er der, hvor omkostning, forsinkelse og fejl samler sig. Reengineering er disciplinen i at lukke den kløft bevidst frem for at dække over den med regneark og velvilje.

Den grundlæggende indsigt i reengineering, og stadig den, der udretter mest, er, at en virksomhed beskrives mere sandfærdigt ved sine processer end ved sit organisationsdiagram. En funktionscentreret virksomhed optimerer hver afdeling mod dens egne mål: salg maksimerer ordrer, drift minimerer enhedsomkostning, økonomi beskytter arbejdskapitalen. Hver er lokalt rationel, og summen er ofte samlet set dårlig, fordi overleveringerne mellem funktioner, dér hvor kunden faktisk venter, tilhører ingen. En procescentreret virksomhed vender dette på hovedet. Den navngiver de gennemgående flows, der betyder noget, giver hvert af dem en ejer med reel autoritet på tværs af funktionsgrænser og måler flowet som helhed: gennemløbstid, first-pass yield, cost to serve, kontantomsætning.

Heraf følger et hårdt indledende spørgsmål, som vi insisterer på at besvare, før nogen nytænkning begynder: reengineere eller forbedre trinvist? De to er ikke ombyttelige, og at forveksle dem er dyrt i begge retninger. Trinvis forbedring er det rette valg, når en proces er grundlæggende sund og blot er tilgroet med spild; her betaler værktøjerne fra lean og løbende forbedring sig hurtigt og sikkert tilbage. Reengineering er kun berettiget, når processen indeholder antagelser, der ikke længere holder, når rækkefølgen af trin eksisterer på grund af en begrænsning, der siden er forsvundet, eller når det ønskede resultat er uopnåeligt uanset hvor meget man justerer det eksisterende design. Testen, vi anvender, er kontant. Hvis du ikke kunne være nået frem til denne proces ved at designe efter dagens resultat fra et blankt stykke papir, er den kandidat til nytænkning. Hvis du kunne, er den kandidat til forbedring.

Det tredje princip er, at en proces, der spænder over CRM, SCM og ERP, ikke kan nytænkes i ét af dem alene. Kundestamdata, produktstamdata, prislogik og ordrestatus er delte fakta, der lever, redundant og ofte inkonsistent, i alle tre systemer. En ægte nytænkning må afgøre, hvor hvert faktum forfattes, hvordan det udbredes, og hvilket system der har forrang, når de er uenige. Derfor behandler vi ikke data og integration som en efterfølgende implementeringsbekymring, men som selve substansen i designet. Procesmodellen og datamodellen er to syn på det samme, og et reengineering-forløb, der frembringer smukke procesdiagrammer og efterlader dataejerskabet uafklaret, har i virkeligheden ikke reengineeret noget som helst.

Et fjerde princip understøtter de øvrige tre: en proces, et system og en organisation er ikke tre ting, der skal bringes på linje, men én ting set fra tre vinkler. Når de behandles som separate arbejdsspor med separat styring, optimerer hvert af dem mod sin egen færdiggørelse, og de mødes ved idriftsættelsen i indbyrdes modstrid. Systemet håndhæver et flow, som organisationen ikke er bemandet til at køre, på data, som processen antog var rene. At designe dem som én beslutning er mere krævende intellektuelt og langt billigere i praksis, fordi modsætningerne findes på papiret frem for i produktion.

Feltet bevæger sig, og ikke altid i den retning, leverandørerne reklamerer med. Nogle få mønstre er værd at benævne ligeud, fordi de ændrer, hvordan en nytænkning bør gribes an.

Komponerbarhed frem for monolitten. Antagelsen om, at én ERP-suite bør eje det meste af processen, viger for en arkitektur af specialiserede systemer, der forbindes med integration. Kundeengagementslaget, planlægningsmotoren, den finansielle kerne og opfyldelsessystemerne er i stigende grad adskilte, valgt efter deres egne fortjenester og sammensat til et flow. Dette er frigørende for procesdesign, fordi man ikke længere er bundet til én leverandørs mening om, hvordan order-to-cash bør fungere, men det flytter vanskeligheden ind i integrations- og styringslaget, som nu bærer den sammenhæng, monolitten plejede at levere.

Process mining som evidens. I det meste af sin historie begyndte reengineering med workshops, hvor folk beskrev, hvordan de troede processen fungerede, hvilket pålideligt var en fiktion. Process mining rekonstruerer den faktiske proces ud fra de event-logs, systemerne allerede udsender, og viser hver variant, omarbejdningssløjfe og omgåelse, som den reelt forekommer. Vi betragter det nu som tæt på uansvarligt at påbegynde en nytænkning uden denne evidens. Den erstatter holdning med et målt udgangspunkt og leverer senere det instrument, der fortæller dig, om nytænkningen opfører sig som tilsigtet i produktion.

Cloud-ERP og totrinsrealiteten. Overgangen til cloud-ERP sælges ofte som en chance for at vende tilbage til standardprocesser og opgive årevis af tilpasninger, og for reelt almindeligt arbejde er det et fornuftigt råd. Men samme skridt hærder ofte til et totrinslandskab, en standardiseret kerne omgivet af de specialiserede systemer, der bærer en virksomheds egentlige særpræg. Designspørgsmålet er derfor ikke, om man skal tilpasse, men hvor særpræget legitimt hører hjemme, ved at holde kernen tæt på standard og samtidig lade kanten afvige og integrere de to bevidst frem for tilfældigt.

Automatisering flytter sig fra opgave til proces. Den første generation af automatisering, robotic process automation i særdeleshed, efterlignede for det meste et menneske, der klikkede sig gennem skærmbilleder, hvilket cementerede den eksisterende proces frem for at nytænke den. Det mere nyttige mønster nu er at automatisere det nytænkte flow på procesniveau ved hjælp af orkestrering og native integration og at reservere skærmniveau-automatisering til de ægte yderkanter, hvor der ikke findes noget interface. At automatisere en dårlig proces lader dig blot udføre den hurtigere.

En nytænkt proces er kun så god som den arkitektur, der bærer den. Flere designprincipper adskiller nytænkninger, der holder, fra dem, der stille falder tilbage.

Én kilde til sandhed pr. faktum, ikke pr. system. Instinktet til at udnævne ét system som master over alt er lige så forkert som slet ikke at have nogen master. Disciplinen er finere: for hver væsentlig entitet og attribut skal man navngive præcis ét system, der forfatter den, og lade de øvrige abonnere. CRM'et kan eje kunderelationen, mens ERP'et ejer den juridiske konto og kreditpositionen; det afgørende er, at ejerskabet er eksplicit, aftalt og håndhævet, så afstemning ophører med at være et månedligt ritual.

Integration som en kontrakt, ikke en forbindelse. Punkt-til-punkt-interfaces bygget i hast bliver den mest skrøbelige del af systemlandskabet, fordi hvert af dem indkoder antagelser, som ingen har skrevet ned. Vi designer integration som versionerede kontrakter med definerede events, payloads og semantik, formidlet gennem et lag, der kan optage forandring på begge sider. Målet er, at et system kan udskiftes bag sin kontrakt, uden at hver nabo behøver at vide det.

Design processen til at kunne observeres. En proces, der ikke kan måles undervejs, kan ikke styres, og det kan de fleste ikke. Vi bygger det nytænkte flow, så dets tilstand, dets tidsforløb og dets undtagelser udsendes som events by construction og fodrer den samme process mining, der etablerede udgangspunktet. Observerbarhed er ikke instrumentering tilføjet bagefter; det er en egenskab designet ind, og det er, hvad der lader processen fortsætte med at forbedres, efter projektet slutter.

Design for reversibilitet. En nytænkning, der kun kan gå fremad, er en nytænkning, der vil blive modarbejdet, fordi omkostningen ved at tage fejl er katastrofal. Vi bygger migreringen, så hvert trin kan sættes på pause, køres parallelt med det bestående og rulles tilbage, hvis evidensen kræver det. Dette er ikke forsigtighed; det er, hvad der gør dristighed overkommelig. Når en ændring kan tilbagerulles billigt, vil en organisation forsøge ændringer, den aldrig ville risikere under en alt-eller-intet-overgang, og det er netop disse forsøg, der lægger sig sammen til ægte transformation.

Design for undtagelsen, ikke for den ideelle vej. De fleste nytænkninger tegnes for den transaktion, der opfører sig, og det meste af omkostningen ligger i dem, der ikke gør: dellevering, den bestridte faktura, kunden der findes to gange under lidt forskellige navne. En proces, der leder sine undtagelser hen til et regneark og en villig person, er ikke blevet designet; den er blevet halvt designet og overladt til menneskelig velvilje for resten. Vi modellerer undtagelsesvejene eksplicit, afgør hvilke der er almindelige nok til at fortjene en førsteklasses vej gennem systemet, og hvilke der er reelt sjældne nok til at overlade til gennemtænkt manuelt arbejde, og vi gør den skelnen til et bevidst valg frem for et tilfælde af, hvad softwaren nu engang understøttede. Det sande mål for en nytænkning er, hvordan den opfører sig på sin værste tirsdag, ikke sin bedste.

De måder, disse programmer slår fejl på, er konsistente nok til at kunne katalogiseres, og de fleste er fejl i dømmekraft snarere end i teknologi.

Big bang-udskiftning af ERP. Den dyreste enkeltfejl er at udskifte ERP'et og reengineere processerne i én samtidig overgang på tværs af hele virksomheden. Teorien er, at et rent brud undgår omkostningen ved at drive to verdener; praksis er, at risikoen lægger sig sammen, fordi hvert problem dukker op på én gang uden nogen måde at isolere årsagen, og virksomheden mister evnen til at falde tilbage. Vi foretrækker nytænkning leveret proces for proces og domæne for domæne, med det nye flow bevist på et afgrænset omfang, før det udvides. En trinvis migrering er langsommere og langt mere tilbøjelig til at nå frem.

At automatisere det eksisterende rod. Et program, der kortlægger den nuværende proces, automatiserer den trofast og kalder resultatet transformation, har brugt store beløb på at bevæge sig hurtigere i den forkerte retning. Automatisering bør følge nytænkning, aldrig træde i stedet for den.

At reengineere diagrammet, ikke organisationen. En nytænkning, der ændrer systemet og processen, men lader incitamenter, roller og rapporteringslinjer være urørte, vil stille blive rullet tilbage af de mennesker, den er til besvær for. Hvis processen nu er tværfunktionel, men bonusserne forbliver funktionelle, vinder de funktionelle mål. Procesejerskab uden autoritet er udsmykning.

Udskudt datagæld. Teams udskyder rutinemæssigt arbejdet med stamdata og kvalitet som ustyrligt uglamourøst med den hensigt at tage sig af det senere. Senere møder den nytænkte proces, der antog rene og konsistente data, den virkelige vare og går i stå. Datakvalitet er ikke en oprydningsopgave ved siden af projektet; det er en forudsætning for, at processen overhovedet virker. Konsulentledet design uden operatører i rummet forværrer dette: en nytænkning, der udelukkende tegnes af specialister, vil overse den tavse viden hos de mennesker, der udfører arbejdet, årsagen til at et trin, der ser overflødigt ud, i virkeligheden er bærende, undtagelsen der forekommer ugentligt og aldrig blev dokumenteret. Når disse operatører første gang møder den nye proces ved oplæring, opdager de dens huller, og deres tillid, når først den er mistet, er dyr at genvinde.

Afgrænsning efter system frem for efter resultat. Programmer, der får mandat som et ERP-projekt eller et CRM-projekt, arver softwarens grænser frem for arbejdets grænser, og de tværsystemiske flows, som netop er der, hvor værdien ligger, falder ned i mellemrummene mellem sporene. Mandatet bør navngive et resultat og et flow og lade systemerne falde ind under det.

Vi begynder ved flowet og resultatet, ikke ved systemet. Før vi foreslår nogen ændring, fastlægger vi, hvad den gennemgående proces er tænkt at opnå i termer, virksomheden vil genkende, gennemløbstid, cost to serve, kontantomsætning, kundeindsats, og vi måler den nuværende tilstand op mod det ved hjælp af de event-data, systemerne allerede rummer, frem for den historie, folk fortæller i workshops. Det målte udgangspunkt afgør den første strid, om processen berettiger reengineering eller forbedring, på evidens frem for begejstring.

Hvor nytænkning er berettiget, designer vi processen, datamodellen og integrationen samlet og behandler dem som tre syn på én beslutning frem for tre sekventielle projekter. Vi afklarer ejerskabet af hvert delt faktum på tværs af CRM, SCM og ERP eksplicit, definerer integrationen som versionerede kontrakter og gør orkestreringen af flowet til et artefakt, der kan inspiceres, frem for logik spredt gennem konfiguration. Den nytænkte proces bygges til at udsende sin egen tilstand, så den kan måles i produktion op mod det samme udgangspunkt, der retfærdiggjorde den.

Vi leverer domæne for domæne og flow for flow, aldrig ved big bang-overgang. En afgrænset del af den nytænkte proces bevises i produktion, på reelle transaktioner, før den udvides, så risikoen forbliver isoleret, og virksomheden bevarer evnen til at falde tilbage. Hele vejen igennem behandler vi den organisatoriske forandring, ejerskabet, incitamenterne, rollerne, som en del af ingeniørarbejdet frem for en eftertanke, fordi en proces, som organisationen ikke er indrettet til at køre, ikke vil overleve. Vores mål er en nytænkning, der bliver ved med at forbedre sig, efter vi er gået, fordi instrumenterne til at styre den blev bygget ind fra begyndelsen.

Vi er ærlige om tempoet. En nytænkning, der spænder over tre registreringssystemer, kan ikke ærligt afsluttes på et kvartal, og ethvert forslag, der lover det, sælger en overgang frem for en nytænkning. Vi sekvenserer arbejdet, så hvert domæne giver en målbar forbedring i sig selv, hvilket vinder den tillid og opmærksomhed, der kræves til det næste, frem for at bede virksomheden om at holde vejret gennem et flerårigt program for én fjern belønning. Den sekvensering disciplinerer også selve designet: et flow, der er forpligtet til at bevise sit værd på en afgrænset del, kan ikke gemme sig bag løftet om, at alt vil hænge sammen til sidst. Hvis en del ikke forbedrer det resultat, den fik mandat til at forbedre, vil vi langt hellere opdage det på ét domæne end på alle tre på én gang.

Det, der kendetegner vores arbejde med procesreengineering, er, at vi nægter at behandle CRM, forsyningskæde og ERP som separate territorier med separate nytænkninger. Vi holder det gennemgående flow, de data der løber igennem det, og den organisation der driver det, i ét samlet syn, og vi afklarer de svære spørgsmål om ejerskab og integration som designbeslutninger frem for at udskyde dem til implementering. Det er en sværere samtale at indlede og et langt mere holdbart resultat at afslutte.

Der er også en praktisk følgeslutning, der ændrer, hvad arbejdet må antage. Når et forløb kræver en kapabilitet, der endnu ikke findes, behøver det ikke afvente en indkøbscyklus eller en leverandørs roadmap. enterprise platform er bygget til at rumme næsten enhver funktion i højt tempo gennem agentic engineering: det, der er brug for, beskrives i almindeligt sprog og genereres hurtigt, men altid inden for faste arkitekturprincipper og under stringent kvalitetssikring, så hastighed aldrig sker på bekostning af sammenhæng, sikkerhed eller kontrol. Effekten er strategisk snarere end blot bekvem. Den flytter grænsen mellem at bygge selv og at købe, holder valgmuligheder billige og lader arkitekturen følge strategien frem for at strategien bøjer sig efter, hvad der nu tilfældigvis stod på hylden.

Belønningen for denne disciplin er et sæt kerneprocesser, der gør det, virksomheden faktisk har brug for, målt op mod de resultater, den holder af, båret af en arkitektur, der kan ændre sig uden at gå i stykker, og drevet af en organisation, der er indrettet til at køre dem. Det er, hvad reengineering altid var tænkt at levere, og med nutidens værktøjer kan den det endelig.