Den første bølgen av business process reengineering feilet av en ærlig grunn: datidens teknologi kunne ikke levere det teorien lovet. I 1993 kunne et selskap tegne en prosess på nytt på en tavle, men systemene under var rigide, batchbundne og vanskelige å integrere, slik at omformingen enten stanset ved grensen til stormaskinen eller degenererte til en kostnadskuttøvelse kledd i transformasjonens språkdrakt. Idéen var solid og verktøyet var det ikke, og de to ble husket sammen.

Den begrensningen har i stor grad løst seg opp. Programmeringsgrensesnitt (API) er nå en standardforventning snarere enn et skreddersydd prosjekt. Event streaming, skybaserte dataplattformer og orkestreringsmotorer gjør det gjennomførbart å sette sammen en prosess som løper på tvers av flere registersystemer uten å bære data manuelt mellom dem. Det som en gang var en heroisk integrasjon er nå alminnelig ingeniørarbeid. Konsekvensen er at reengineering-spørsmålet, lenge utsatt fordi det var for dyrt å besvare, igjen har blitt håndterbart, og det vender tilbake i de fleste organisasjoner under andre navn: omforming av order-to-cash, kundeonboarding, robusthet i forsyningen, akselerering av regnskapsavslutningen.

Fristelsen til å utsette reengineering-spørsmålet er forståelig og ikke lenger trygg. I årevis var det rasjonelle å vente, fordi integrasjonskostnaden ved enhver alvorlig omforming oversteg gevinsten, og selskaper samlet opp omgåelser i den trygge forventningen om at de ville bli løst ved neste systemoppgradering. Det ble de sjelden. Hver oppgradering bevarte den gamle prosessformen fordi det å migrere formen var billigere enn å stille spørsmål ved den, og den tilfeldige utformingen stivnet til tilsynelatende varighet. Det som har endret seg, er at konkurrenter som faktisk stiller spørsmålet nå kan handle på svaret, og en prosess som tar dobbelt så lang tid eller koster dobbelt så mye skjules ikke lenger av at alle andre er like trege.

Det er en annen grunn til at spørsmålet er viktig nå. Tre tiår med innføring av virksomhetsprogramvare har etterlatt de fleste store selskaper med en CRM som modellerer kunden, en ERP som modellerer transaksjonen og økonomien, og en forsyningskjedesuite som modellerer materiale og kapasitet, hver konfigurert av en ulik funksjon på et ulikt tidspunkt etter en ulik logikk. Prosessene som faktisk skaper verdi, å ta imot en ordre og oppfylle den, å skaffe en kunde og betjene dem, å planlegge forsyning mot reell etterspørsel, løper rett på tvers av alle tre. Organisasjonen er ordnet etter funksjon; arbeidet er ordnet etter flyt; og gapet mellom de to er der kostnad, forsinkelse og feil samler seg. Reengineering er disiplinen med å lukke det gapet bevisst snarere enn å dekke over det med regneark og velvilje.

Den grunnleggende innsikten i reengineering, og fortsatt den som gjør mest arbeid, er at en virksomhet beskrives mer sannferdig av sine prosesser enn av sitt organisasjonskart. Et funksjonssentrert selskap optimaliserer hver avdeling mot sine egne mål: salg maksimerer ordreinntak, drift minimerer enhetskostnad, økonomi verner om arbeidskapitalen. Hver er lokalt rasjonell og summen er ofte globalt dårlig, fordi overleveringene mellom funksjoner, der kunden faktisk venter, tilhører ingen. Et prosessentrert selskap snur dette. Det navngir de ende-til-ende-flytene som betyr noe, gir hver en eier med reell myndighet på tvers av funksjonsgrenser, og måler flyten som helhet: gjennomløpstid, first-pass yield, kostnad å betjene, kontantomløp.

Av dette følger et krevende forhåndsspørsmål, som vi insisterer på å besvare før noen omforming begynner: reengineere, eller forbedre trinnvis? De to er ikke utbyttbare, og å forveksle dem er kostbart i begge retninger. Trinnvis forbedring er det riktige valget når en prosess er fundamentalt sunn og bare tilgrodd med sløsing; her betaler verktøyene fra lean og kontinuerlig forbedring seg raskt og trygt tilbake. Reengineering er berettiget bare når prosessen legemliggjør antakelser som ikke lenger holder, når rekkefølgen av trinn finnes på grunn av en begrensning som siden har forsvunnet, eller når det ønskede utfallet er uoppnåelig uansett hvor mye man justerer den eksisterende utformingen. Testen vi anvender er nådeløs. Om du ikke kunne ha kommet frem til denne prosessen ved å designe for dagens utfall fra et blankt ark, er den en kandidat for omforming. Om du kunne, er den en kandidat for forbedring.

Det tredje prinsippet er at en prosess som spenner over CRM, SCM og ERP ikke kan omformes i ett av dem alene. Kundemasteren, produktmasteren, prislogikken og ordretilstanden er delte fakta som lever, redundant og ofte inkonsistent, i alle tre systemene. En reell omforming må avgjøre hvor hvert faktum forfattes, hvordan det forplanter seg, og hvilket system som stoles på når de er uenige. Dette er grunnen til at vi behandler data og integrasjon ikke som en nedstrøms implementeringsbekymring, men som selve substansen i utformingen. Prosessmodellen og datamodellen er to syn på det samme, og en reengineering-innsats som produserer vakre prosessdiagrammer og lar dataeierskapet stå uløst har i realiteten ikke reengineert noe som helst.

Et fjerde prinsipp ligger til grunn for de tre andre: en prosess, et system og en organisasjon er ikke tre ting som skal samordnes, men én ting sett fra tre vinkler. Når de behandles som separate arbeidsstrømmer med separat styring, optimaliserer hver for sin egen fullføring, og de møtes ved lansering i gjensidig motsetning. Systemet håndhever en flyt organisasjonen ikke er bemannet til å kjøre, mot data prosessen antok var ren. Å designe dem som én beslutning er mer intellektuelt krevende og langt billigere i praksis, fordi motsetningene finnes på papiret snarere enn i produksjon.

Feltet er i bevegelse, og ikke alltid i den retningen leverandørene annonserer. Noen få mønstre fortjener å nevnes klart fordi de endrer hvordan en omforming bør angripes.

Komponerbarhet fremfor monolitten. Antakelsen om at én ERP-suite bør eie mesteparten av prosessen viker for en arkitektur av spesialiserte systemer koblet sammen av integrasjon. Kundeengasjementlaget, planleggingsmotoren, den finansielle kjernen og oppfyllelsessystemene er i økende grad atskilte, valgt på egne meritter og satt sammen til en flyt. Dette er frigjørende for prosessdesign, fordi du ikke lenger er bundet til én leverandørs oppfatning av hvordan order-to-cash bør fungere, men det flytter vanskeligheten inn i integrasjons- og styringslaget, som nå bærer den koherensen monolitten pleide å gi.

Process mining som bevis. I det meste av sin historie begynte reengineering med workshops der folk beskrev hvordan de trodde prosessen fungerte, hvilket pålitelig var en fiksjon. Process mining rekonstruerer den faktiske prosessen fra hendelsesloggene systemene allerede sender ut, og viser hver variant, omarbeidsløkke og omgåelse slik den virkelig forekommer. Vi anser nå det å starte en omforming uten dette beviset som nær uaktsomhet. Det erstatter meninger med en målt baseline og gir senere det instrumentet som forteller deg om omformingen oppfører seg som tiltenkt i produksjon.

Cloud ERP og totrinns-virkeligheten. Overgangen til cloud ERP selges ofte som en sjanse til å vende tilbake til standardprosesser og forlate år med tilpasning, og for genuint alminnelig arbeid er det godt råd. Men den samme overgangen stivner ofte til et totrinns-landskap, en standardisert kjerne omgitt av de spesialiserte systemene som bærer et selskaps faktiske særpreg. Designspørsmålet er derfor ikke om man skal tilpasse, men hvor særpreget legitimt bor, ved å holde kjernen nær standard mens randen tillates å avvike, og integrere de to bevisst snarere enn ved en tilfeldighet.

Automatisering flytter fra oppgave til prosess. Den første generasjonen av automatisering, robotic process automation i særdeleshet, etterlignet stort sett et menneske som klikker gjennom skjermbilder, hvilket sementerte den eksisterende prosessen snarere enn å omforme den. Det mer nyttige mønsteret nå er å automatisere den omformede flyten på prosessnivå, ved bruk av orkestrering og innebygd integrasjon, og å reservere automatisering på skjermnivå for de genuine randtilfellene der ingen grensesnitt finnes. Å automatisere en dårlig prosess lar deg bare utføre den raskere.

En reengineert prosess er bare så god som arkitekturen som bærer den. Flere designprinsipper skiller omforminger som holder fra dem som stille går tilbake.

Én kilde til sannhet per faktum, ikke per system. Instinktet om å erklære ett system som master for alt er like feil som å ha ingen master i det hele tatt. Disiplinen er finere: for hver betydelig entitet og attributt, navngi nøyaktig ett system som forfatter det, og la de andre abonnere. CRM-en kan eie kunderelasjonen mens ERP-en eier den juridiske kontoen og kredittposisjonen; det som betyr noe er at eierskapet er eksplisitt, avtalt og håndhevet, slik at avstemming slutter å være et månedlig ritual.

Integrasjon som en kontrakt, ikke en tilkobling. Punkt-til-punkt-grensesnitt bygget i hast blir den mest skjøre delen av systemlandskapet, fordi hvert koder antakelser ingen skrev ned. Vi designer integrasjon som versjonerte kontrakter med definerte hendelser, nyttelaster og semantikk, formidlet gjennom et lag som kan absorbere endring på begge sider. Målet er at et system kan erstattes bak sin kontrakt uten at hver nabo trenger å vite det.

Design prosessen for å være observerbar. En prosess som ikke kan måles i flukt kan ikke styres, og de fleste kan ikke det. Vi bygger den omformede flyten slik at dens tilstand, dens tidsmålinger og dens unntak sendes ut som hendelser i sin konstruksjon, og mater den samme process mining som etablerte baselinen. Observerbarhet er ikke instrumentering lagt til i etterkant; det er en egenskap designet inn, og det er det som lar prosessen fortsette å forbedre seg etter at prosjektet er ferdig.

Design for reverserbarhet. En omforming som bare kan gå fremover er en omforming som vil bli motarbeidet, fordi kostnaden ved å ta feil er katastrofal. Vi bygger migreringen slik at hvert trinn kan settes på pause, kjøres parallelt med det eksisterende, og rulles tilbake om beviset krever det. Dette er ikke feighet; det er det som gjør dristighet overkommelig. Når en endring kan reverseres billig, vil en organisasjon forsøke endringer den aldri ville risikere under en alt-eller-intet-overgang, og det er nettopp de forsøkene som legger seg sammen til reell transformasjon.

Design for unntaket, ikke for lykketreffet. De fleste omforminger tegnes for transaksjonen som oppfører seg, og mesteparten av kostnaden ligger i dem som ikke gjør det: den delvise forsendelsen, den omtvistede fakturaen, kunden som finnes to ganger under litt ulike navn. En prosess som ruter sine unntak til et regneark og en villig person har ikke blitt designet; den har blitt halvdesignet og overlatt til menneskelig velvilje for resten. Vi modellerer unntaksveiene eksplisitt, avgjør hvilke som er vanlige nok til å fortjene en førsteklasses rute gjennom systemet og hvilke som er genuint sjeldne nok til å overlate til gjennomtenkt manuelt arbeid, og vi gjør det skillet til et bevisst valg snarere enn en tilfeldighet av hva programvaren tilfeldigvis støttet. Det sanne målet på en omforming er hvordan den oppfører seg på sin verste tirsdag, ikke sin beste.

Måtene disse programmene feiler på er konsistente nok til å kunne katalogiseres, og de fleste er svikt i dømmekraft snarere enn i teknologi.

Big-bang-utskifting av ERP. Den dyreste enkeltfeilen er å skifte ut ERP-en og reengineere prosessene i én samtidig overgang på tvers av hele virksomheten. Teorien er at et rent brudd unngår kostnaden ved å kjøre to verdener; praksisen er at risiko forsterker seg, fordi hvert problem dukker opp samtidig uten noen måte å isolere årsaken på, og virksomheten mister evnen til å falle tilbake. Vi foretrekker omforming levert per prosess og per domene, med den nye flyten bevist på et avgrenset omfang før den utvides. En trinnvis migrering er tregere og langt mer sannsynlig å komme frem.

Å automatisere det eksisterende rotet. Et program som kartlegger den nåværende prosessen, automatiserer den trofast og kaller resultatet transformasjon har brukt en stor sum på å bevege seg raskere i feil retning. Automatisering bør følge omforming, aldri erstatte den.

Å reengineere diagrammet, ikke organisasjonen. En omforming som endrer systemet og prosessen, men lar insentivene, rollene og rapporteringslinjene være urørt, vil stille bli reversert av de menneskene den er til bry for. Om prosessen nå er tverrfunksjonell, men bonusene forblir funksjonelle, vinner de funksjonelle målene. Prosesseierskap uten myndighet er dekorasjon.

Utsatt datagjeld. Team utsetter rutinemessig masterdata- og kvalitetsarbeidet som lite glamorøst, med den hensikt å ta det senere. Senere møter den omformede prosessen, som antok rene og konsistente data, den virkelige tingen og stanser. Datakvalitet er ikke en oppryddingsoppgave ved siden av prosjektet; det er en forutsetning for at prosessen fungerer i det hele tatt. Konsulentledet design uten operatører i rommet forverrer dette: en omforming tegnet utelukkende av spesialister vil overse den tause kunnskapen til de menneskene som driver arbeidet, grunnen til at et trinn som ser overflødig ut faktisk er bærende, unntaket som forekommer ukentlig og aldri ble dokumentert. Når de operatørene først møter den nye prosessen under opplæring, oppdager de dens hull, og deres tillit, når den først er tapt, er kostbar å gjenvinne.

Omfang etter system snarere enn etter utfall. Programmer chartret som et ERP-prosjekt eller et CRM-prosjekt arver programvarens grenser snarere enn arbeidets grenser, og de tverrsystemiske flytene, som er nettopp der verdien ligger, faller ned i gapene mellom strømmene. Charteret bør navngi et utfall og en flyt, og la systemene falle innenfor det.

Vi begynner fra flyten og utfallet, ikke systemet. Før vi foreslår noen endring fastslår vi hva ende-til-ende-prosessen er ment å oppnå i termer virksomheten vil kjenne igjen, gjennomløpstid, kostnad å betjene, kontantomløp, kundeanstrengelse, og vi måler nåtilstanden mot det ved bruk av hendelsesdataene systemene allerede holder snarere enn historien folk forteller i workshops. Den målte baselinen avgjør det første stridsspørsmålet, om prosessen berettiger reengineering eller forbedring, på bevis snarere enn entusiasme.

Der omforming er berettiget, designer vi prosessen, datamodellen og integrasjonen sammen, og behandler dem som tre syn på én beslutning snarere enn tre sekvensielle prosjekter. Vi løser eierskapet til hvert delte faktum på tvers av CRM, SCM og ERP eksplisitt, definerer integrasjonen som versjonerte kontrakter, og gjør orkestreringen av flyten til et inspiserbart artefakt snarere enn logikk spredt gjennom konfigurasjon. Den omformede prosessen bygges til å sende ut sin egen tilstand, slik at den kan måles i produksjon mot den samme baselinen som rettferdiggjorde den.

Vi leverer per domene og per flyt, aldri ved big-bang-overgang. En avgrenset del av den omformede prosessen bevises i produksjon, på reelle transaksjoner, før den utvides, slik at risiko holdes isolert og virksomheten beholder evnen til å falle tilbake. Gjennom hele forløpet behandler vi den organisatoriske endringen, eierskapet, insentivene, rollene, som del av ingeniørarbeidet snarere enn en ettertanke, fordi en prosess organisasjonen ikke er innrettet til å kjøre ikke vil overleve. Vårt mål er en omforming som fortsetter å forbedre seg etter at vi drar, fordi instrumentene til å styre den ble bygget inn fra starten.

Vi er åpne om tempo. En omforming som spenner over tre registersystemer kan ærlig talt ikke fullføres på et kvartal, og ethvert forslag som lover det selger en overgang snarere enn en omforming. Vi sekvenserer arbeidet slik at hvert domene gir en målbar forbedring på egen hånd, hvilket fortjener tilliten og oppmerksomheten som trengs for det neste, snarere enn å be virksomheten holde pusten gjennom et flerårig program for en enkelt fjern belønning. Den sekvenseringen disiplinerer også selve designet: en flyt som er forpliktet til å bevise sin verdi på en avgrenset del kan ikke gjemme seg bak løftet om at alt vil henge sammen til slutt. Om en del ikke klarer å forbedre det utfallet den ble chartret til å forbedre, vil vi langt heller oppdage det på ett domene enn på alle tre samtidig.

Det som skiller vårt arbeid i prosess-reengineering er at vi nekter å behandle CRM, forsyningskjede og ERP som separate territorier med separate omforminger. Vi holder ende-til-ende-flyten, dataene som løper gjennom den og organisasjonen som driver den i ett samlet syn, og vi løser de vanskelige spørsmålene om eierskap og integrasjon som designbeslutninger snarere enn å utsette dem til implementering. Det er en vanskeligere samtale å starte og et langt mer varig resultat å fullføre.

Det er også en praktisk konsekvens som endrer hva arbeidet er tillatt å anta. Når et oppdrag krever en kapabilitet som ennå ikke finnes, trenger det ikke vente på en anskaffelsessyklus eller en leverandørs veikart. enterprise platform er bygget til å romme nesten enhver funksjon i høyt tempo, gjennom agentic engineering: det som trengs beskrives i klart språk og genereres raskt, men alltid innenfor faste arkitekturprinsipper og under streng kvalitetssikring, slik at hastighet aldri kommer på bekostning av koherens, sikkerhet eller kontroll. Effekten er strategisk snarere enn bare bekvem. Den flytter grensen mellom å bygge og å kjøpe, holder valgfrihet billig, og lar arkitekturen følge strategien snarere enn at strategien bøyer seg for hva som tilfeldigvis fantes på hyllen.

Belønningen for denne disiplinen er et sett med kjerneprosesser som gjør det virksomheten faktisk trenger, målt mot utfall den bryr seg om, båret av en arkitektur som kan endres uten å brekke, og drevet av en organisasjon innrettet til å kjøre dem. Det er hva reengineering alltid var ment å levere, og med dagens verktøy kan det endelig gjøre det.