Razionalizzazione del portafoglio a seguito di fusioni e acquisizioni

Il sistema di fatturazione dell'azienda target è stato segnalato come ridondante nella terza settimana del processo di integrazione. L'acquirente disponeva di una propria piattaforma di fatturazione, l'entità risultante dalla fusione non ne avrebbe avuto bisogno di due e il sistema dell'azienda target sembrava duplicare le funzionalità. La sua dismissione era prevista dopo sei mesi. Al quinto mese, il team di migrazione ha scoperto che il sistema di fatturazione dell'azienda target non si limitava a generare fatture, ma conteneva quarant'anni di logica di calcolo delle imposte specifica per giurisdizione in sessantatré paesi, incorporata in programmi COBOL gestiti da un team di sviluppatori che avevano tutti accettato pacchetti di buonuscita al secondo mese. La piattaforma di fatturazione dell'acquirente gestiva diciotto paesi. La decisione di dismissione è stata annullata, il team di sviluppatori ha dovuto essere ricostituito con tariffe contrattuali di emergenza e la tempistica per la realizzazione delle sinergie è stata estesa di quattordici mesi.

La decisione di razionalizzazione è stata presa sulla base di ciò che il sistema sembrava fare. Avrebbe dovuto essere presa sulla base di ciò che il sistema faceva effettivamente. Questi aspetti sono diversi in ogni portfolio applicativo, e lo sono ancora di più nei portfolio che includono sistemi legacy con decenni di logica aziendale accumulata, dipendenze non documentate e conoscenze istituzionali che esistono solo nel codice.

Perché le fusioni e acquisizioni creano l'imperativo della razionalizzazione del portafoglio

Quando si uniscono due aziende, si è immediatamente costretti a razionalizzare le applicazioni di entrambe per creare una holding unificata e consolidata. In un contesto così dinamico, la capacità di integrare rapidamente i sistemi determina la velocità con cui la nuova entità può operare in modo efficiente.

La razionalizzazione non è un'opzione, ma una necessità. Due organizzazioni che gestivano ciascuna il proprio sistema ERP, CRM, HRMS, piattaforma di fatturazione, suite di reporting e data warehouse, ora ne hanno due di ogni tipo. Il costo complessivo di mantenimento di sistemi paralleli, licenze, infrastrutture, supporto e oneri operativi derivanti dalla gestione di due istanze di quello che alla fine dovrebbe essere un unico sistema, è il principale fattore determinante delle sinergie di costo che hanno giustificato il prezzo di acquisizione. Le tempistiche di integrazione sono incluse nel modello di accordo. La realizzazione delle sinergie è monitorata dal consiglio di amministrazione. Il mancato rispetto delle tempistiche di razionalizzazione non solo comporta il mancato raggiungimento di un obiettivo finanziario, ma mette in discussione la logica strategica dell'accordo.

La maggior parte delle aziende tende ad accumulare nel tempo un ampio portfolio di applicazioni informatiche, soprattutto se crescono tramite fusioni e acquisizioni e non integrano completamente operazioni e risorse dopo ogni transazione. Considerate nel loro complesso, molte di queste applicazioni potrebbero non essere in linea con la strategia complessiva di fusione e acquisizione dell'azienda; sono state create come soluzioni puntuali e non necessariamente supportano gli obiettivi aziendali e organizzativi a livello aziendale successivi all'acquisizione.

La portata del problema si aggrava con ogni acquisizione successiva. Un'organizzazione cresciuta attraverso acquisizioni seriali senza una rigorosa integrazione del portafoglio post-fusione si ritrova con il debito tecnico accumulato di ogni operazione non completamente digerita. Una grande azienda media utilizza oltre 370 applicazioni SaaS. Tra il 25 e il 30% di queste licenze sono inutilizzate o significativamente sottoutilizzate. Si stima che le organizzazioni perdano ogni anno circa 19.8 milioni di dollari in licenze inutilizzate. Se si aggiungono le applicazioni legacy, i programmi COBOL, le personalizzazioni ERP proprietarie e i sistemi batch mainframe che non compaiono negli audit delle licenze SaaS, il portafoglio che la razionalizzazione deve affrontare risulta sostanzialmente più ampio di quanto suggerisca l'inventario SaaS.

Le tre lacune che causano i fallimenti della razionalizzazione

Le decisioni di razionalizzazione che hanno portato alla proroga di quattordici mesi non sono dovute a errori di esecuzione, bensì a carenze informative. Nei programmi di razionalizzazione post-fusione si riscontrano tre specifiche lacune informative:

Divario 1: Scopo dichiarato contro scopo reale

Il proprietario dell'applicazione descrive lo scopo per cui il sistema è stato progettato. Dopo anni o decenni di personalizzazioni accumulate, il sistema fa molto di più. Un CRM che "gestisce le relazioni con i clienti" può anche occuparsi del calcolo trimestrale delle commissioni, gestire le eccezioni per i clienti più importanti e conservare l'unica copia di determinate clausole contrattuali in un formato necessario per la reportistica successiva. Nulla di tutto ciò è presente nella descrizione del proprietario dell'applicazione perché non era incluso nei requisiti originali. Si è accumulato un workaround alla volta, ognuno dei quali risolveva un problema immediato senza che la descrizione dello scopo del sistema venisse aggiornata da nessuno.

Il costo della scoperta del Gap 1 dopo la dismissione: ricostruire le funzioni nascoste nel sistema sostitutivo, spesso con costi di emergenza, mentre l'azienda continua a operare senza di esse o con soluzioni manuali.

Gap 2: Dipendenze non dichiarate

L'applicazione appare autonoma. Dodici altri sistemi dipendono dal suo output. La dipendenza non è mai stata formalmente documentata perché è stata stabilita tramite un flusso di dati informale che uno sviluppatore ha configurato tre anni fa per risolvere un problema di reporting. Il proprietario dell'applicazione non è a conoscenza di questa dipendenza. I proprietari dei sistemi dipendenti sanno di ricevere i dati, ma presumono che provengano dal "sistema di fatturazione" senza sapere quale programma specifico li produca.

Dipendenze mai elencate nell'inventario, un'applicazione sembra usa e getta perché nessuno ha mappato cosa dipendesse da essa. Il costo della scoperta del Gap 2 dopo il pensionamento: dodici sistemi si guastano o si degradano in modi riconducibili a una dipendenza che avrebbe dovuto essere inclusa nell'analisi di razionalizzazione ma non lo è stata.

Lacuna 3: Sottostima dell'ambito della migrazione dei dati

Il piano di migrazione dei dati stima lo schema del sistema di destinazione sulla base della documentazione corrente. Lo schema presenta quarantasette varianti accumulate in quarant'anni di modifiche alle regole aziendali, di cui tre documentate e quarantaquattro visibili solo nel codice del programma che legge e scrive i dati. L'attività di migrazione dei dati è definita in base alle tre varianti documentate e si conclude nei tempi previsti. Dopo la migrazione, i processi che si basavano sulle quarantaquattro varianti non documentate falliscono silenziosamente, producendo output errati che vengono rilevati solo quando un report trimestrale o una comunicazione normativa rivelano la discrepanza.

Il costo della scoperta del Gap 3 dopo la migrazione: analisi delle cause profonde, correzione dei dati, rielaborazione e, nei settori regolamentati, notifica alle autorità di controllo e azioni correttive.

Le cinque decisioni di razionalizzazione

Ogni applicazione in un portafoglio combinato corrisponde a uno dei cinque possibili esiti di razionalizzazione. Il quadro decisionale si applica sia alle applicazioni legacy che a quelle moderne, sebbene le prove necessarie per prendere la decisione differiscano in modo significativo:

Decisione	Definizione	Quando applicare	È richiesta la prova primaria
mantenere	Mantenere la forma attuale, gestita dall'entità combinata	Funzionalità uniche, senza equivalenti in altri prodotti del portfolio, qualità adeguata	Mappatura delle funzioni aziendali, analisi delle dipendenze
Unisci	Unire le funzionalità di entrambe le versioni del portfolio in un'unica istanza funzionante.	Entrambe le organizzazioni svolgono funzioni equivalenti; una delle due è superiore	Analisi della sovrapposizione funzionale, valutazione del divario di funzionalità, complessità della migrazione
Modernizzare	Mantenere la funzione aziendale, trasformare l'implementazione tecnica	La funzionalità è necessaria, ma la qualità tecnica è troppo scarsa per garantire la durata nel tempo.	Metriche di qualità del codice, punteggio di complessità, valutazione del debito tecnico
sostituire	Ritirare l'applicazione e sostituirla con un'alternativa commerciale o nativa del cloud.	La funzionalità è una merce; un prodotto standard la svolge in modo adeguato	Disponibilità sul mercato di alternative, valutazione della profondità di personalizzazione
Andare in pensione	Dismissione senza sostituzione	La funzione è effettivamente ridondante, non c'è una logica univoca, non ci sono consumatori attivi	Analisi del codice morto, mappatura delle dipendenze che conferma l'assenza di consumatori attivi

La decisione che sembra essere "Ritirarsi" ma in realtà è "Mantenere": un'applicazione senza utenti attivi, con un basso volume di transazioni e senza consumatori finali visibili sembra essere una candidata al ritiro. Se contiene una logica aziendale unica, norme fiscali giurisdizionali, routine di calcolo regolamentari, elaborazione di obblighi contrattuali, che non sono state replicate altrove, ritirarla significa perdere definitivamente tale logica. Questo è lo scenario del sistema di fatturazione descritto all'inizio di questo articolo. La decisione appare ovvia in base all'inventario, ma è errata alla luce dei fatti.

Il prerequisito per l'analisi strutturale

La razionalizzazione delle applicazioni durante le fusioni e acquisizioni (M&A) consiste nella decisione di mantenere, migrare, consolidare o dismettere le applicazioni, decisione che deve essere inclusa nel modello di transazione prima della chiusura. Licenze parallele, integrazioni nascoste e sequenze di dismissione rappresentano il costo reale.

Per prendere decisioni accurate in questo ambito, è necessaria una documentazione strutturale che vada oltre quanto i proprietari delle applicazioni possono fornire durante le interviste, quanto registrato dai sistemi di gestione degli asset IT e quanto emerso dagli audit delle licenze SaaS. Per il livello applicativo legacy, costituito da sistemi COBOL, programmi batch personalizzati, middleware proprietari e applicazioni aziendali basate su database in funzione da decenni, la documentazione strutturale è disponibile solo nel codice sorgente.

Quattro risultati dell'analisi strutturale necessari per le decisioni di razionalizzazione:

Inventario della logica di business. Quali regole codifica l'applicazione? Non la descrizione funzionale fornita dal proprietario, ma i calcoli specifici, i rami condizionali, le regole di validazione e la logica di trasformazione implementati nel codice del programma. Per i programmi COBOL, ciò significa analizzare la sezione PROCEDURE DIVISION per estrarre la logica IF/EVALUATE, le istruzioni COMPUTE e i percorsi di elaborazione condizionale che implementano le regole di business. Questo inventario rappresenta la specifica a cui qualsiasi sistema di sostituzione o consolidamento deve corrispondere.

Analisi del fan-in. Quante altre applicazioni, programmi o processi dipendono dagli output di questa applicazione? Il fan-in è il principale indicatore del rischio di dismissione: un'applicazione con fan-in pari a zero può essere dismessa in sicurezza; un'applicazione con cinquanta fan-in comporta il rischio che la dismissione comprometta il funzionamento di cinquanta altri elementi. Negli ambienti legacy, il fan-in include non solo le chiamate API dirette, ma anche le dipendenze dai flussi di dati, i consumer di file VSAM condivisi, i flussi di job JCL che richiamano il programma e i processi batch a valle che leggono i suoi set di dati di output.

Percentuale di codice morto. Qual è la percentuale di codice dell'applicazione irraggiungibile da qualsiasi percorso di esecuzione in produzione? Il codice morto accumulatosi nel corso di decenni di aggiunte di funzionalità e correzioni di bug aumenta la complessità apparente dell'applicazione e il costo apparente della modernizzazione. Identificare ed escludere il codice morto dall'ambito della razionalizzazione fornisce un quadro più accurato di ciò che deve effettivamente essere migrato, consolidato o sostituito.

Complessità della migrazione dei dati. Qual è la struttura del layout dei record di ogni dataset gestito dall'applicazione? Quante varianti di REDEFINES esistono? Quali campi COMP-3 richiedono una mappatura del tipo di destinazione che preservi la precisione? Quali regole aziendali governano i dati da cui dipendono i consumatori dell'applicazione? Le risposte determinano se la migrazione dei dati sarà una semplice conversione dello schema o un programma di trasformazione dei dati che richiederà diversi mesi.

La cronologia dei 100 giorni: quando la velocità si scontra con la completezza

Il piano di integrazione di 100 giorni rappresenta il punto di riferimento del settore per la velocità di esecuzione post-fusione. Investitori, membri del consiglio di amministrazione e consulenti direzionali misurano il successo dell'integrazione in base a questa tempistica. La pressione per dimostrare tempestivamente la realizzazione delle sinergie, per mostrare al mercato che l'accordo sta funzionando, comprime ogni flusso di lavoro, inclusa la razionalizzazione delle applicazioni.

Il conflitto tra la pressione delle scadenze e l'accuratezza dell'analisi è il punto in cui i programmi di razionalizzazione generano gli errori più costosi. Un'organizzazione che non riesce a completare un'analisi strutturale approfondita del proprio portafoglio combinato entro 100 giorni si trova di fronte a una scelta: prendere decisioni di razionalizzazione basandosi su informazioni incomplete, oppure non rispettare le scadenze e dover rispondere a domande sull'esecuzione dell'integrazione.

La strategia adottata dagli acquirenti più esperti non è quella di comprimere l'analisi, bensì di sequenziare le decisioni:

Fase 1 (giorni 1-30): Decisioni chiare e inequivocabili. Applicazioni chiaramente ridondanti senza alcuna logica univoca, applicazioni chiaramente da mantenere senza candidati al consolidamento, applicazioni già programmate per la dismissione nella roadmap di un'organizzazione. Queste decisioni non richiedono un'analisi strutturale approfondita perché l'esito non è in dubbio. Prenderle rapidamente dimostra lo slancio dell'integrazione senza il rischio di prendere decisioni errate sulla base di informazioni incomplete.

Fase 2 (giorni 31-90): Decisioni che richiedono un'analisi mirata. Applicazioni che appaiono ridondanti ma la cui razionalizzazione dipende da specifiche evidenze strutturali: esiste una logica aziendale univoca? Qual è il numero di utenti interessati? Quanto è complessa la migrazione dei dati? L'analisi strutturale viene commissionata specificamente per le applicazioni di questa categoria, concentrando le risorse sulle decisioni in cui l'analisi modifica l'esito.

Fase 3 (dal giorno 91 in poi): Decisioni che richiedono un'analisi approfondita. Applicazioni la cui complessità rende le decisioni di razionalizzazione a 90 giorni effettivamente inappropriate, sistemi legacy con decenni di logica accumulata, piattaforme dati condivise al servizio di entrambe le organizzazioni, programmi batch critici il cui comportamento non è completamente compreso. Queste decisioni vengono esplicitamente rinviate con motivazioni documentate, non prese in fretta e furia per arrivare a una risposta errata.

Questo approccio di sequenziamento concilia la pressione delle scadenze con l'esigenza di accuratezza: le prime fasi dimostrano lo slancio acquisito; le fasi successive proteggono dalle decisioni errate catastrofiche che generano le proroghe di quattordici mesi.

Disinvestimento: il problema inverso

Le acquisizioni creano la necessità di consolidare due portafogli in uno solo. Le cessioni creano il problema inverso: separare un portafoglio, costruito come un tutt'uno integrato, in due portafogli indipendenti, ciascuno dei quali può operare indipendentemente dall'altro.

In un contesto di cessione, la SpinCo spesso inizia la sua nuova vita con un portafoglio gonfiato, composto dalle applicazioni esistenti utilizzate esclusivamente dalla SpinCo e da quelle condivise con la ParentCo, come ad esempio i sistemi HR e ERP. La ParentCo, dal canto suo, si ritrova spesso con costi irrecuperabili per le applicazioni dismesse insieme alla SpinCo.

La sfida della razionalizzazione delle cessioni è fondamentalmente diversa da quella delle acquisizioni perché è necessario rispondere prima alla questione della separabilità: questa applicazione può operare in modo indipendente, oppure è integrata con la restante organizzazione in modi che rendono impraticabile una separazione netta?

Un programma COBOL che serve l'unità aziendale scorporata ma legge da un database mainframe condiviso che serve anche l'unità aziendale rimanente non è facilmente separabile. Le opzioni di separazione sono: replicare il database (con la complessità di mantenere la sincronizzazione durante la transizione), migrare il programma scorporato a una nuova istanza di database (con la complessità della migrazione dei dati e il rischio di divergenza comportamentale) o continuare l'accordo di accesso condiviso anche dopo la separazione (con la complessità di governance di due entità indipendenti che condividono l'infrastruttura dati).

Ognuna di queste opzioni presenta implicazioni diverse in termini di costi, rischi e tempistiche. Nessuna di esse può essere valutata senza sapere esattamente come il programma utilizza il database condiviso, quali tabelle, quali campi, con quali modelli di accesso, con quale volume e frequenza. Si tratta di un'analisi strutturale del codice legacy, non di una revisione della documentazione.

Il codice legacy nelle fusioni e acquisizioni: la dimensione che nessuno considera

Il problema della razionalizzazione del SaaS, ovvero quali applicazioni mantenere, quali contratti rescindere, quali fornitori consolidare, è ben gestito da strumenti e framework esistenti. Il problema della razionalizzazione del codice legacy, invece, non ha un supporto equivalente in termini di strumenti nella maggior parte delle organizzazioni.

Quando sia l'acquirente che la società target utilizzano sistemi mainframe COBOL per le loro attività aziendali principali, la decisione di razionalizzazione richiede di rispondere a domande a cui le interviste con i responsabili delle applicazioni e i sistemi di gestione degli asset IT non possono rispondere:

Quali programmi COBOL sono specifici di ciascuna organizzazione? Il portfolio di mainframe dell'acquirente e quello dell'azienda target possono sovrapporsi a livello funzionale (entrambi gestiscono gli account), pur divergendo nell'implementazione (ognuno ha accumulato decenni di regole aziendali specifiche). Per identificare la reale sovrapposizione funzionale è necessario analizzare i programmi, non limitarsi a leggerne le etichette.

Quali programmi sono infrastrutture condivise e quali sono specifici di una singola unità aziendale? Un programma di utilità JCL, richiamato da quaranta programmi nell'intera organizzazione, è un'infrastruttura condivisa. Una routine di calcolo COBOL, richiamata da tre programmi al servizio di una singola unità aziendale, è specifica di una singola unità aziendale. L'analisi del fan-in sull'intero inventario dei programmi genera automaticamente questa classificazione.

cobolo

      *> 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.

Questo programma produce un output specifico e verificabile per ogni giurisdizione che gestisce. La sua dismissione richiede o la replica di ogni clausola WHEN e di ogni target PERFORM sottostante in un sistema sostitutivo, oppure l'accettazione del fatto che il sistema sostitutivo produrrà output diversi per alcune giurisdizioni. Nessuno dei due risultati è visibile dall'inventario dell'applicazione. Entrambi sono visibili nel codice sorgente COBOL.

Qual è l'ambito della migrazione dei dati per ciascuna applicazione? I dati associati a un'applicazione COBOL legacy sono definiti in voci FD e copybook che possono aver accumulato più varianti REDEFINES, campi COMP-3 che richiedono una mappatura precisa e vincoli di validità incorporati acquisiti nei nomi delle condizioni di livello 88. La migrazione dei dati basata sulla documentazione anziché sullo schema effettivo produce l'errore Gap 3.

Quali programmi contengono codice obsoleto che può essere escluso dall'ambito della migrazione? Il codice obsoleto nei programmi legacy aumenta la complessità apparente della modernizzazione o della migrazione. I programmi con il 40% di codice obsoleto richiedono l'analisi e la migrazione di un 40% di codice in più rispetto a quanto effettivamente richiesto dal comportamento in produzione. Identificare il codice obsoleto prima di definire l'ambito della migrazione riduce le stime di impegno e migliora la precisione delle tempistiche.

Lista di controllo per la decisione di applicazione della razionalizzazione del portafoglio di fusioni e acquisizioni

Per ciascuna applicazione rientrante nell'ambito di applicazione, prima di poter prendere una decisione di razionalizzazione con sicurezza, è necessaria la seguente documentazione:

Valutazione della logica aziendale

• La funzionalità effettiva dell'applicazione è stata verificata tramite analisi del codice, e non solo intervistando il proprietario?
• Tutte le regole aziendali incorporate nel codice sono documentate in una forma tale che un eventuale codice sostitutivo debba necessariamente corrispondere?
• Per i programmi COBOL: sono stati inventariati tutti i rami EVALUATE, le condizioni IF e le istruzioni COMPUTE?

Valutazione della dipendenza

• Il fan-in è stato misurato strutturalmente (e non stimato dal proprietario dell'applicazione)?
• Sono state elencate tutte le dipendenze del flusso di dati, a livello di JCL, di file e di database?
• Sono state tracciate le dipendenze dinamiche delle chiamate, e non solo i collegamenti statici del grafo delle chiamate?

Valutazione della migrazione dei dati

• È stato estratto il layout completo del record dalle voci FD e dai membri COPY?
• Sono state identificate tutte le varianti di REDEFINES e sono state documentate le condizioni che le caratterizzano?
• Tutti i campi COMP-3 e binari sono stati mappati a tipi di destinazione appropriati alla precisione?

Valutazione del codice morto

• Il codice obsoleto è stato identificato ed escluso dalle stime di portata della migrazione?
• Le decisioni di ritiro dal mercato sono confermate dall'analisi del codice inutilizzato (zero fan-in dai percorsi di esecuzione in produzione)?

Classificazione del rischio

• Il punteggio di criticità dell'applicazione è stato verificato rispetto ai risultati dell'analisi strutturale?
• La tempistica di mantenimento, migrazione o pensionamento è coerente con la complessità delle dipendenze?

Come SMART TS XL Supporta la razionalizzazione del portafoglio di fusioni e acquisizioni

SMART TS XL Fornisce lo strato di prove strutturali per le decisioni di razionalizzazione che non possono essere prese correttamente sulla base della sola documentazione e delle interviste.

La funzionalità di analisi statica del codice estrae l'inventario della logica di business da COBOL, JCL, Java, Python e da ogni altro linguaggio presente nei portfolio di entrambe le organizzazioni, fornendo un quadro completo di ciò che ogni applicazione effettivamente fa, non solo di ciò che indica la sua etichetta. Per i programmi COBOL come l'esempio di calcolo delle imposte riportato sopra, questa analisi elenca ogni giurisdizione, ogni condizione di regola e ogni ramo di calcolo che un'eventuale sostituzione dovrebbe implementare per produrre risultati equivalenti.

La mappatura delle dipendenze delle applicazioni fornisce l'analisi fan-in e fan-out che determina il rischio di dismissione e la sequenza di consolidamento. Per i portafogli di entrambe le organizzazioni analizzati simultaneamente, la mappa delle dipendenze mostra quali programmi sono veramente autonomi, quali sono profondamente integrati in un'infrastruttura condivisa e quali presentano le dipendenze a valle nascoste che sono alla base dei guasti Gap 2.

La funzionalità di analisi d'impatto rende ogni decisione di razionalizzazione proposta testabile prima della sua esecuzione: se questo programma viene dismesso, quali altri programmi perdono una dipendenza? Se questo dataset viene migrato, quali programmi devono essere aggiornati per leggere dalla nuova posizione? L'ambito d'impatto di ogni decisione proposta è enumerabile a partire dal modello strutturale, convertendo le decisioni di razionalizzazione da stime di rischio in piani definiti e circoscritti.

L' analisi di modernizzazione dei sistemi legacy produce un punteggio di complessità e identifica il codice obsoleto, rendendo accurate le stime di impegno: i programmi nel quartile inferiore di complessità con un'alta percentuale di codice obsoleto sono ottimi candidati per la dismissione o la modernizzazione; i programmi nel quartile superiore di complessità con un elevato fan-in sono candidati per il mantenimento, indipendentemente dall'apparente ridondanza.

La funzionalità di ricerca aziendale rende il portfolio combinato interrogabile durante l'intero programma di razionalizzazione: trova ogni programma che accede a uno specifico set di dati, ogni programma che implementa una specifica funzione aziendale, ogni programma COBOL con complessità ciclomica superiore a una determinata soglia, in pochi secondi, tra i milioni di righe di codice complessive di entrambe le organizzazioni.

Per le organizzazioni che conducono processi di razionalizzazione sotto pressione temporale, SMART TS XLL'analisi di 's comprime i tempi dell'analisi strutturale: la mappa completa delle dipendenze, l'inventario della logica di business e il punteggio di complessità per un portfolio combinato possono essere prodotti in pochi giorni anziché nelle settimane o nei mesi che sarebbero necessari per una revisione manuale del codice. Questa compressione è ciò che rende praticabile l'approccio di sequenziamento Wave 1 / Wave 2 / Wave 3: l'analisi strutturale mirata per le applicazioni di Wave 2 può essere completata entro i 90 giorni previsti dalla tempistica.

La validità di una decisione dipende esclusivamente dalle prove su cui si basa.

La razionalizzazione del portafoglio post-fusione opera sotto una reale pressione temporale, finanziaria e organizzativa, per dimostrare che l'operazione sta funzionando. Tutte queste pressioni spingono verso decisioni più rapide. Nessuna di esse, tuttavia, modifica il costo di una decisione errata.

Il sistema di fatturazione, la cui dismissione era stata programmata e poi riattivato a costi di emergenza, non è un monito contro la lentezza nell'agire. È un monito contro l'agire senza le prove che avrebbero potuto cambiare la decisione. L'analisi strutturale che rivela cosa fa effettivamente un sistema, la sua logica aziendale intrinseca, le sue dipendenze nascoste, la complessità della migrazione dei dati, non rallenta la razionalizzazione. La rende accurata. E l'accuratezza, nel contesto di un programma di integrazione post-fusione in cui decisioni errate generano proroghe di diciotto mesi e sforamenti di budget a nove cifre, è la qualità più preziosa che una decisione di razionalizzazione possa avere.

La razionalizzazione del portafoglio che ha successo non è la più veloce, ma quella che sa cosa sta razionalizzando.