Porteføljerationalisering efter fusioner og opkøb

Målvirksomhedens faktureringssystem blev markeret som redundant i uge tre af integrationsprocesforløbet. Opkøberen havde sin egen faktureringsplatform, den fusionerede enhed ville ikke have brug for to, og målets system syntes at have duplikeret funktionalitet. Det var planlagt til udfasning efter seks måneder. I måned fem opdagede migreringsteamet, at målets faktureringssystem ikke blot genererede fakturaer, men indeholdt fyrre års jurisdiktionspecifik skatteberegningslogik på tværs af 63 lande, indlejret i COBOL-programmer, der var blevet vedligeholdt af et team af udviklere, der alle havde accepteret fratrædelsespakker i måned to. Opkøberens faktureringsplatform håndterede atten lande. Beslutningen om udfasning blev omstødt, udviklerteamet måtte rekonstrueres til nødkontraktrater, og synergitidslinjen blev forlænget med fjorten måneder.

Rationaliseringsbeslutningen blev truffet på baggrund af, hvad systemet tilsyneladende gjorde. Den burde have været truffet på baggrund af, hvad systemet rent faktisk gjorde. Disse ting er forskellige i enhver applikationsportefølje, og de er mest forskellige i porteføljer, der inkluderer ældre systemer med årtiers akkumuleret forretningslogik, udokumenterede afhængigheder og institutionel viden, der ikke findes andre steder end i koden.

Hvorfor M&A skaber porteføljerationalisering som et imperativ

Når man slår to virksomheder sammen, bliver man straks tvunget til at rationalisere applikationerne fra begge sider for at skabe en samlet, konsolideret holding. I det pressede miljø bestemmer evnen til hurtigt at fusionere systemer, hvor hurtigt den nye enhed kan operere effektivt.

Rationaliseringen er ikke valgfri. To organisationer, der hver især kørte deres eget ERP-, CRM-, HRMS-, faktureringsplatform-, rapporteringssuite- og datawarehouse-system, har nu to af hvert. De samlede omkostninger ved at vedligeholde parallelle systemer, licenser, infrastruktur, support og de operationelle overheadomkostninger ved at køre to instanser af, hvad der i sidste ende skulle være én, er den primære drivkraft bag de omkostningssynergier, der retfærdiggjorde købsprisen. Integrationstidslinjer er indskrevet i aftalemodellen. Synergirealisering spores af bestyrelsen. Manglende rationalisering til tiden betyder ikke blot, at man ikke når et økonomisk mål, det sætter også spørgsmålstegn ved aftalens strategiske logik.

De fleste virksomheder har en tendens til at akkumulere en stor portefølje af it-applikationer over tid, især hvis de vokser gennem fusioner og opkøb og ikke fuldt ud integrerer drift og aktiver efter hver transaktion. Set holistisk er mange af disse applikationer muligvis ikke i overensstemmelse med virksomhedens overordnede fusions- og opkøbsstrategi; de blev skabt som point-in-time-løsninger og understøtter ikke nødvendigvis forretnings- og organisationsmål efter aftalen på virksomhedsniveau.

Problemets omfang forværres med hvert efterfølgende opkøb. En organisation, der er vokset gennem serielle opkøb uden grundig porteføljeintegration efter fusionen, bærer den akkumulerede tekniske gæld fra hver handel, den ikke fuldt ud har fordøjet. Den gennemsnitlige store virksomhed kører over 370 SaaS-applikationer. Mellem 25 og 30 procent af disse licenser er ubrugte eller betydeligt underudnyttede. Organisationer efterlader anslået 19.8 millioner dollars i ubrugte licenser på bordet årligt. Tilføj det ældre applikationslag, COBOL-programmerne, proprietære ERP-tilpasninger og mainframe-batchsystemer, der ikke optræder i SaaS-licensrevisioner, og den portefølje, som rationaliseringen skal adressere, er væsentligt større, end SaaS-opgørelsen antyder.

De tre huller, der forårsager rationaliseringsfejl

De rationaliseringsbeslutninger, der fører til forlængelsen af ​​tidslinjen på fjorten måneder, er ikke udførelsesfejl. De er informationsfejl. Tre specifikke informationshuller optræder igen i rationaliseringsprogrammer efter fusioner:

Hul 1: Erklæret formål versus reelt formål

Applikationsejeren beskriver, hvad systemet er designet til at gøre. Efter år eller årtier med akkumuleret tilpasning gør systemet betydeligt mere. Et CRM, der "styrer kunderelationer", kan også køre den kvartalsvise provisionsberegning, håndtere undtagelsesbehandling for de største konti og vedligeholde den eneste kopi af visse kontraktvilkår i et format, som downstream-rapportering afhænger af. Intet af dette er i applikationsejerens beskrivelse, fordi intet af det var i de oprindelige krav. Den akkumulerede én løsning ad gangen, der hver løste et øjeblikkeligt problem uden at opdatere nogens beskrivelse af systemets formål.

Omkostningerne ved at opdage Gap 1 efter pensionering: genopbyg de skjulte funktioner i erstatningssystemet, ofte til en nødsituation, mens virksomheden fungerer uden dem eller med manuelle løsninger.

Hul 2: Ikke-erklærede afhængigheder

Applikationen fremstår som selvstændig. Tolv andre systemer er afhængige af dens output. Afhængigheden blev aldrig formelt dokumenteret, fordi den blev etableret gennem en uformel datafeed, som en udvikler oprettede for tre år siden for at løse et rapporteringsproblem. Applikationens ejer kender ikke til afhængigheden. Ejerne af de afhængige systemer ved, at de modtager dataene, men antager, at de kommer fra "faktureringssystemet" uden at vide, hvilket program specifikt producerer dem.

Afhængigheder, som opgørelsen aldrig har nævnt, én applikation ser ud til at være engangsbrug, fordi ingen har kortlagt, hvad der var afhængig af den. Omkostningerne ved at opdage Gap 2 efter udfasning: tolv systemer fejler eller forringes på måder, der kan spores tilbage til en afhængighed, der burde have været med i rationaliseringsanalysen, men som ikke var det.

Manglende 3: Undervurdering af omfanget af datamigrering

Datamigreringsplanen estimerer målsystemets skema baseret på den aktuelle dokumentation. Skemaet har 47 varianter akkumuleret over 40 års ændringer i forretningsreglerne, hvoraf tre er dokumenterede og 44 kun er synlige i den programkode, der læser og skriver dataene. Datamigreringsindsatsen er målt i forhold til de tre dokumenterede varianter og fuldføres til tiden. Efter migreringen fejler de processer, der var afhængige af de 44 udokumenterede varianter, lydløst og producerer forkerte output, der ikke registreres, før en kvartalsrapport eller en indsendelse til myndighederne afslører uoverensstemmelsen.

Omkostningerne ved at opdage Gap 3 efter migrering: rodårsagsanalyse, datakorrektion, genbehandling og i regulerede brancher, lovgivningsmæssig anmeldelse og afhjælpning.

De fem rationaliseringsbeslutninger

Hver applikation i en kombineret portefølje er knyttet til et af fem rationaliseringsresultater. Beslutningsrammen gælder for både ældre og moderne applikationer, selvom den dokumentation, der kræves for at træffe beslutningen, varierer betydeligt:

Beslutning	Definition	Hvornår skal du anvende	Primært bevismateriale krævet
Holde	Beholdes i nuværende form, drevet af den fusionerede enhed	Unik funktionalitet, ingen tilsvarende i den anden portefølje, tilstrækkelig kvalitet	Kortlægning af forretningsfunktioner, afhængighedsanalyse
Konsolider	Flet funktionalitet fra begge porteføljeversioner til én overlevende instans	Begge organisationer kører tilsvarende funktioner; én instans er overlegen	Funktionel overlapningsanalyse, vurdering af funktionsgab, migrationskompleksitet
moderniseret	Bevar forretningsfunktionen, transformer den tekniske implementering	Funktion er påkrævet, men den tekniske kvalitet er for dårlig til at kunne opretholdes på lang sigt	Kodekvalitetsmålinger, kompleksitetsscoring, vurdering af teknisk gæld
udskifte	Tag applikationen ud af drift, og erstat den med et kommercielt eller cloud-native alternativ	Funktion er en vare; et standardprodukt tjener den tilstrækkeligt	Markedstilgængelighed af alternativer, vurdering af tilpasningsdybde
gå på pension	Nedlukning uden erstatning	Funktionen er virkelig redundant, ingen unik logik, ingen aktive forbrugere	Analyse af død kode, afhængighedskortlægning bekræfter nul aktive forbrugere

Beslutningen, der ligner "Tilbagefør", men i virkeligheden er "Behold": En applikation uden aktive brugere, lav transaktionsvolumen og ingen synlige downstream-forbrugere ser ud til at være en "Tilbagefør"-kandidat. Hvis den indeholder unik forretningslogik, jurisdiktionelle skatteregler, lovgivningsmæssige beregningsrutiner eller behandling af kontraktlige forpligtelser, som ikke er blevet replikeret andre steder, betyder det, at en "tilbagefør"-beslutning betyder, at logikken mistes permanent. Dette er faktureringssystemscenariet fra begyndelsen af ​​denne artikel. Beslutningen virker indlysende ud fra opgørelsen; den er forkert ud fra beviserne.

Forudsætningen for strukturel analyse

Applikationsrationalisering under fusioner og opkøb er beslutningen om at beholde, migrere, konsolidere eller trække sig tilbage, der hører hjemme i handlens model før afslutning. Parallelle licenser, skjulte integrationer og sekvensering af træk tilbage er den reelle omkostning.

At træffe disse beslutninger præcist kræver strukturel evidens, der går ud over, hvad applikationsejere kan give i interviews, hvad IT-asset management-systemer registrerer, og hvad SaaS-licensrevisioner viser. For det ældre applikationslag, COBOL-systemer, specialbyggede batchprogrammer, proprietær middleware og databasebaserede forretningsapplikationer, der har kørt i årtier, findes den strukturelle evidens kun i kildekoden.

Fire strukturelle analyseresultater, som rationaliseringsbeslutninger kræver:

Forretningslogikopgørelse. Hvilke regler koder applikationen? Ikke den funktionelle beskrivelse, som ejeren giver, men de specifikke beregninger, betingede forgreninger, valideringsregler og transformationslogik, der er implementeret i programkoden. For COBOL-programmer betyder dette at parse PROCEDURE DIVISION for at udtrække IF/EVALUATE-logikken, COMPUTE-sætningerne og de betingede behandlingsstier, der implementerer forretningsreglerne. Denne opgørelse er den specifikation, som ethvert erstatnings- eller konsolideringssystem skal matche.

Fan-in-analyse. Hvor mange andre applikationer, programmer eller processer er afhængige af denne applikations output? Fan-in er den primære indikator for risiko for tilbagetrækning: en applikation med nul fan-in kan sikkert tilbagetrækkes; en applikation med halvtreds fan-in indebærer risikoen for, at tilbagetrækning vil ødelægge halvtreds andre ting. I ældre miljøer omfatter fan-in ikke kun direkte API-kald, men også datafeedafhængigheder, delte VSAM-filforbrugere, JCL-jobstrømme, der kalder programmet, og downstream-batchprocesser, der læser dets outputdatasæt.

Procentdel af død kode. Hvilken procentdel af applikationens kode kan ikke nås fra nogen produktionsudførelsessti? Død kode, der er akkumuleret gennem årtiers funktionstilføjelser og fejlrettelser, oppuster applikationens tilsyneladende kompleksitet og de tilsyneladende omkostninger ved modernisering. At identificere og udelukke død kode fra rationaliseringsomfanget giver et mere præcist billede af, hvad der rent faktisk skal migreres, konsolideres eller erstattes.

Datamigreringskompleksitet. Hvad er postlayoutstrukturen for hvert datasæt, som applikationen administrerer? Hvor mange REDEFINES-varianter findes der? Hvilke COMP-3-felter kræver præcisionsbevarende måltypetilknytning? Hvilke forretningsregler styrer de data, som applikationens forbrugere er afhængige af? Svarene afgør, om datamigreringen er en simpel skemakonvertering eller et flermåneders datatransformationsprogram.

100-dages tidslinje: Når hastighed er i konflikt med grundighed

100-dages integrationsplanen er branchens benchmark for implementeringshastighed efter fusioner. Investorer, bestyrelsesmedlemmer og ledelseskonsulenter måler integrationssucces i forhold til denne tidslinje. Presset for at demonstrere tidlig synergi-realisering og vise markedet, at aftalen fungerer, komprimerer alle arbejdsgange, inklusive applikationsrationalisering.

Konflikten mellem tidspres og grundighed af analyser er der, hvor rationaliseringsprogrammer genererer deres dyreste fejl. En organisation, der ikke kan gennemføre en grundig strukturel analyse af sin samlede portefølje inden for 100 dage, står over for et valg: at træffe rationaliseringsbeslutninger på baggrund af ufuldstændige oplysninger eller overholde tidslinjen og stille spørgsmål om integrationens udførelse.

Den løsning, som modne opkøbere har udviklet, er ikke at komprimere analysen, men at sekvensere beslutningerne:

Bølge 1 (dag 1-30): Kun klare og utvetydige beslutninger. Applikationer, der er klart redundante uden unik logik, applikationer, der klart er kandidater til "Keep" uden konsolidering, og applikationer, der allerede er planlagt til pensionering i en organisations roadmap. Disse beslutninger kræver ikke dybdegående strukturel analyse, fordi resultatet ikke er i tvivl. At træffe dem hurtigt demonstrerer integrationsmomentum uden risiko for at træffe forkerte beslutninger baseret på ufuldstændige oplysninger.

Bølge 2 (dag 31-90): Beslutninger, der kræver målrettet analyse. Applikationer, der virker overflødige, men hvis rationaliseringsresultat afhænger af specifik strukturel evidens: er der unik forretningslogik? Hvad er fan-in-antallet? Hvor kompleks er datamigreringen? Den strukturelle analyse bestilles specifikt til applikationerne i denne kategori med fokus på ressourcerne på de beslutninger, hvor analysen ændrer resultatet.

Bølge 3 (dag 91+): Beslutninger, der kræver udvidet analyse. Applikationer, hvis kompleksitet gør 90-dages rationaliseringsbeslutninger virkelig upassende, ældre systemer med årtiers akkumuleret logik, delte dataplatforme, der betjener begge organisationer, missionskritiske batchprogrammer, hvis adfærd ikke er fuldt ud forstået. Disse udskydes eksplicit med dokumenteret begrundelse og forhastes ikke til et forkert svar.

Denne sekventeringstilgang forener tidslinjepresset med kravet om grundighed: tidlige bølger demonstrerer momentum; senere bølger beskytter mod de katastrofale forkerte beslutninger, der genererer de fjorten måneders tidslinjeforlængelser.

Frasalg: Det omvendte problem

Opkøb skaber behovet for at konsolidere to porteføljer til én. Frasalg skaber det omvendte problem: at opdele en portefølje, der blev bygget som en integreret helhed, i to uafhængige porteføljer, der hver især kan fungere uden den anden.

I en frasalgskontekst starter SpinCo ofte sit nye liv med en oppustet portefølje bestående af de eksisterende applikationer, der udelukkende bruges af SpinCo, og de applikationer, det delte med ParentCo, såsom HR og ERP. ParentCo står derimod ofte tilbage med strandede omkostninger for applikationer, det har afskaffet sammen med SpinCo.

Udfordringen med rationalisering af frasalg er fundamentalt forskellig fra udfordringen med opkøb, fordi spørgsmålet om adskillelse skal besvares først: kan denne applikation fungere uafhængigt, eller er den integreret med den resterende organisation på måder, der gør ren adskillelse upraktisk?

Et COBOL-program, der betjener den frasolgte forretningsenhed, men læser fra en delt mainframe-database, der også betjener den resterende forretningsenhed, kan ikke rent adskilles. Adskillelsesmulighederne er: repliker databasen (med kompleksiteten ved at opretholde synkronisering under overgangen), migrer det frasolgte program til en ny databaseinstans (med kompleksiteten ved datamigrering og risikoen for adfærdsmæssig divergens) eller fortsæt den delte adgangsordning efter separationen (med styringskompleksiteten ved to uafhængige enheder, der deler datainfrastruktur).

Hver af disse muligheder har forskellige konsekvenser for omkostninger, risici og tidsrammer. Ingen af ​​dem kan evalueres uden at vide præcis, hvordan programmet bruger den delte database, hvilke tabeller, hvilke felter, i hvilke adgangsmønstre, med hvilken mængde og hyppighed. Dette er en strukturel analyse af den ældre kode, ikke en gennemgang af dokumentation.

Legacy Code i M&A: Den dimension, ingen tager højde for

SaaS-rationaliseringsproblemet, hvilke applikationer der skal beholdes, hvilke kontrakter der skal opsiges, og hvilke leverandører der skal konsolideres, håndteres godt af eksisterende værktøjer og frameworks. Problemet med rationalisering af ældre kode har ingen tilsvarende værktøjsstøtte i de fleste organisationer.

Når både køberen og målet bruger mainframe COBOL-systemer til deres kerneforretningsbehandling, kræver rationaliseringsbeslutningen besvarelse af spørgsmål, som applikationsejeren interviewer, og som IT-asset management-systemer ikke kan besvare:

Hvilke COBOL-programmer er unikke for hver organisation? Opkøberens mainframe-portefølje og målets mainframe-portefølje kan overlappe hinanden i funktion (begge kører kontostyring), mens de afviger i implementering (hver har årtiers unikke forretningsregelakkumulering). Identificering af ægte funktionel overlap kræver parsing af programmerne, ikke læsning af etiketterne.

Hvilke programmer er delt infrastruktur versus forretningsenhedsspecifikke? Et JCL-hjælpeprogram, der kaldes af fyrre programmer på tværs af den kombinerede organisation, er delt infrastruktur. En COBOL-beregningsrutine, der kaldes af tre programmer, der betjener en enkelt forretningsenhed, er forretningsenhedsspecifik. Fan-in-analyse på tværs af den kombinerede programinventar producerer automatisk denne klassificering.

COBOL

      *> Target company's tax calculation -- 40 years of jurisdiction rules
      *> 63 countries, 847 tax rule conditions, embedded in this program
      *> Not documented anywhere except in this PROCEDURE DIVISION
       CALCULATE-TAX.
           EVALUATE WS-COUNTRY-CD
               WHEN 'US' PERFORM US-TAX-CALC
               WHEN 'UK' PERFORM UK-VAT-CALC
               WHEN 'DE' PERFORM GERMAN-MWST-CALC
               WHEN 'FR' PERFORM FRENCH-TVA-CALC
               *> ... 59 more WHEN clauses
               WHEN OTHER PERFORM DEFAULT-TAX-CALC
           END-EVALUATE.

Dette program producerer et specifikt, auditerbart output for hver jurisdiktion, det håndterer. At tage det ud af drift kræver enten at replikere hver WHEN-klausul og hvert underliggende PERFORM-mål i et erstatningssystem, eller at acceptere, at erstatningen vil producere forskellige output for nogle jurisdiktioner. Ingen af ​​resultaterne er synlige fra applikationens inventar. Begge er synlige i COBOL-kildekoden.

Hvad er datamigreringsområdet for hver applikation? Dataene, der er knyttet til en ældre COBOL-applikation, er defineret i FD-poster og kopibøger, der kan have akkumuleret flere REDEFINES-varianter, COMP-3-felter, der kræver præcisionsbevidst kortlægning, og indlejrede gyldighedsbegrænsninger, der er fanget i betingelsesnavne på 88 niveauer. Datamigrering, der er målt i forhold til dokumentationen i stedet for det faktiske skema, forårsager Gap 3-fejlen.

Hvilke programmer indeholder død kode, der kan udelukkes fra migreringsområdet? Død kode i ældre programmer forstærker den tilsyneladende moderniserings- eller migreringskompleksitet. Programmer med 40 procent død kode kræver analyse og migrering af 40 procent mere kode, end den faktiske driftsikkerhed kræver. Identifikation af død kode, før migreringsområdet låses, reducerer tidsrammens estimater og forbedrer nøjagtigheden af ​​tidslinjen.

Tjekliste til ansøgningsbeslutninger vedrørende rationalisering af M&A-porteføljer

For hver ansøgning inden for rammerne kræves følgende dokumentation, før en rationaliseringsbeslutning kan træffes med sikkerhed:

Vurdering af forretningslogik

• Er applikationens faktiske funktion blevet verificeret gennem kodeanalyse, ikke blot et interview med ejeren?
• Er alle forretningsregler indlejret i koden dokumenteret i en form, som en erstatning skal matche?
• For COBOL-programmer: er alle EVALUATE-grene, IF-betingelser og COMPUTE-sætninger blevet opgjort?

Afhængighedsvurdering

• Er fan-in blevet målt strukturelt (ikke estimeret af applikationsejeren)?
• Er alle datafeedafhængigheder, på JCL-niveau, filniveau og databaseniveau, opregnet?
• Er dynamiske CALL-afhængigheder blevet sporet, ikke kun statiske kaldsgrafkanter?

Vurdering af datamigrering

• Er det komplette postlayout blevet udtrukket fra FD-poster og COPY-medlemmer?
• Er alle REDEFINES-varianter blevet identificeret, og deres skelnende betingelser dokumenteret?
• Er alle COMP-3- og binære felter blevet kortlagt til præcisionstilpassede måltyper?

Vurdering af død kode

• Er død kode blevet identificeret og udeladt af estimater for migreringsomfang?
• Bekræftes beslutninger om tilbagetrækning af analyse af død kode (nul fan-in fra produktionsudførelsesstier)?

Risikoklassificering

• Er applikationens kritikalitetsscore blevet verificeret i forhold til resultaterne af den strukturelle analyse?
• Er tidslinjen for fastholdelse, migrering eller tilbagetrækning i overensstemmelse med afhængighedens kompleksitet?

Hvordan SMART TS XL Understøtter rationalisering af M&A-porteføljer

SMART TS XL giver det strukturelle evidenslag for de rationaliseringsbeslutninger, der ikke kan træffes korrekt alene på baggrund af dokumentation og interviews.

Funktionen til statisk kodeanalyse udtrækker forretningslogikbeholdningen fra COBOL, JCL, Java, Python og alle andre sprog i begge organisationers porteføljer, hvilket giver et komplet billede af, hvad hver applikation rent faktisk gør, ikke kun hvad dens etiket siger. For COBOL-programmer som skatteberegningseksemplet ovenfor opregner denne analyse alle jurisdiktioner, alle regelbetingelser og alle beregningsgrene, som en erstatning skal implementere for at producere tilsvarende resultater.

Applikationsafhængighedskortlægningen leverer fan-in og fan-out-analyser, der bestemmer risikoen for pensionering og konsolideringssekvensering. For begge organisationers porteføljer, der analyseres samtidigt, viser afhængighedskortet, hvilke programmer der virkelig er uafhængige, hvilke der er dybt integreret i den delte infrastruktur, og hvilke der bærer de skjulte downstream-afhængigheder, som Gap 2-fejl er lavet af.

Effektanalysefunktionen gør alle foreslåede rationaliseringsbeslutninger testbare , før de udføres: Hvis dette program udfases, hvilke andre programmer mister så en afhængighed? Hvis dette datasæt migreres, hvilke programmer skal så opdateres for at læse fra den nye placering? Effektomfanget af hver foreslået beslutning kan opregnes fra den strukturelle model, der konverterer rationaliseringsbeslutninger fra risikovurderinger til definerede, omfangsrige planer.

Analysen af ​​ældre moderniseringer producerer kompleksitetsscoring og identifikation af død kode, der gør indsatsestimater nøjagtige: programmer i den nederste kvartil af kompleksitet med en høj procentdel af død kode er stærke kandidater til at blive pensioneret eller moderniseret; programmer i den øverste kvartil af kompleksitet med høj fan-in er kandidater til at beholde uanset tilsyneladende redundans.

Virksomhedssøgningsfunktionen gør den kombinerede portefølje forespørgselsbar i hele rationaliseringsprogrammet: find alle programmer , der tilgår et specifikt datasæt, alle programmer, der implementerer en specifik forretningsfunktion, alle COBOL-programmer med cyklomatisk kompleksitet over en tærskel, på få sekunder, på tværs af begge organisationers kombinerede millioner af kodelinjer.

For organisationer, der udfører rationalisering under tidspres, SMART TS XLs analyse komprimerer tidslinjen for den strukturelle analyse: det komplette afhængighedskort, forretningslogikopgørelsen og kompleksitetsscoringen for en kombineret portefølje kan produceres på dage i stedet for de uger eller måneder, som manuel kodegennemgang ville kræve. Denne komprimering er det, der gør Wave 1 / Wave 2 / Wave 3-sekventeringsmetoden levedygtig, og den målrettede strukturelle analyse for Wave 2-applikationer kan gennemføres inden for det 90-dages vindue, som tidslinjen tillader.

Den beslutning, du træffer, er kun så god som beviserne bag den

Porteføljerationalisering efter fusioner foregår under reelt tidspres, reelt økonomisk pres og reelt organisatorisk pres for at demonstrere, at aftalen fungerer. Alt dette pres skubber i retning af hurtigere beslutninger. Ingen af ​​dem ændrer omkostningerne ved at træffe den forkerte beslutning.

Faktureringssystemet, der var planlagt til pensionering og derefter blev taget ud af drift til en nødsituation, er ikke en advarsel om at bevæge sig for langsomt. Det er en advarsel om at bevæge sig uden de beviser, der ville have ændret beslutningen. Den strukturelle analyse, der afslører, hvad et system rent faktisk gør, dets indlejrede forretningslogik, dets skjulte afhængigheder, dets kompleksitet i datamigrering, gør ikke rationalisering langsommere. Det gør rationalisering præcis. Og præcision, i forbindelse med et integrationsprogram efter en fusion, hvor forkerte beslutninger genererer atten måneders tidslinjeforlængelser og nicifrede omkostningsoverskridelser, er den mest værdifulde egenskab, en rationaliseringsbeslutning kan have.

Den porteføljerationalisering, der lykkes, er ikke den hurtigste. Det er den, der ved, hvad den rationaliserer.