Fakturační systém cílové společnosti byl ve třetím týdnu integračního procesu označen za nadbytečný. Nabyvatel měl vlastní fakturační platformu, sloučený subjekt by nepotřeboval dvě a systém cílové společnosti se zdál duplicitní. Jeho vyřazení bylo naplánováno na šest měsíců. V pátém měsíci migrační tým zjistil, že fakturační systém cílové společnosti nejen generoval faktury, ale obsahoval i čtyřicet let logiky výpočtu daní specifických pro danou jurisdikci v šedesáti třech zemích, zabudované v programech COBOL, které spravoval tým vývojářů, kteří všichni ve druhém měsíci přijali odstupné. Fakturační platforma nabyvatele zvládala osmnáct zemí. Rozhodnutí o vyřazení z provozu bylo zrušeno, vývojářský tým musel být rekonstruován za nouzové smluvní sazby a časový harmonogram synergie byl prodloužen o čtrnáct měsíců.
Rozhodnutí o racionalizaci bylo učiněno na základě toho, co systém zdánlivě dělá. Mělo být učiněno na základě toho, co systém skutečně dělá. V každém aplikačním portfoliu se jedná o jiné věci a nejvíce se liší v portfoliích, která zahrnují starší systémy s desítkami let nahromaděné obchodní logiky, nezdokumentovanými závislostmi a institucionálními znalostmi, které neexistují nikde jinde než v kódu.
Vězte to, než začnete racionalizovat
SMART TS XL extrahuje vložená pravidla, jurisdikční logiku a výpočetní větve, které popisky aplikací a rozhovory s vlastníky nikdy neodhalí.
ZJISTĚTE VÍCE…Proč fúze a akvizice vytvářejí imperativ racionalizace portfolia
Když sloučíte dvě společnosti, jste okamžitě nuceni racionalizovat aplikace z obou stran a vytvořit tak jednotný, konsolidovaný holding. V tomto prostředí s vysokým tlakem určuje schopnost rychlého sloučení systémů, jak rychle může nový subjekt efektivně fungovat.
Racionalizace není volitelná. Dvě organizace, které provozovaly vlastní ERP, CRM, HRMS, fakturační platformu, reportingový balíček a datový sklad, nyní mají od všeho po dvou. Kombinované náklady na údržbu paralelních systémů, licencování, infrastrukturu, podporu a provozní režie provozování dvou instancí toho, co by nakonec mělo být jednou, jsou hlavním faktorem synergií nákladů, které odůvodnily akviziční cenu. Harmonogramy integrace jsou zapsány v modelu transakce. Realizaci synergií sleduje představenstvo. Nedodržení harmonogramu racionalizace nejenže neznamená dosažení finančního cíle, ale také zpochybňuje strategickou logiku transakce.
Většina společností má tendenci v průběhu času nashromáždit rozsáhlé portfolio aplikací informačních technologií, zejména pokud rostou prostřednictvím fúzí a akvizic a po každé transakci plně neintegrují provoz a aktiva. Při holistickém pohledu se mnoho z těchto aplikací nemusí shodovat s celkovou strategií společnosti v oblasti fúzí a akvizic; byly vytvořeny jako řešení v určitém okamžiku a nemusí nutně podporovat obchodní a organizační cíle na úrovni celého podniku po uzavření obchodu.
Rozsah problému se s každou další akvizicí zhoršuje. Organizace, která rostla prostřednictvím sériových akvizic bez důsledné integrace portfolia po fúzi, nese nahromaděný technický dluh z každé transakce, kterou plně nestrávila. Průměrný velký podnik provozuje více než 370 SaaS aplikací. 25 až 30 procent těchto licencí je nevyužitých nebo výrazně nedostatečně využívaných. Organizace každoročně nechávají na stole odhadem 19.8 milionu dolarů v nevyužitých licencích. Připočtěte k tomu vrstvu starších aplikací, programy COBOL, proprietární úpravy ERP a dávkové systémy pro mainframy, které se neobjevují v auditech licencí SaaS, a portfolio, které musí racionalizace řešit, je podstatně větší, než naznačuje inventář SaaS.
Tři mezery, které způsobují selhání racionalizace
Rozhodnutí o racionalizaci, která vedou k prodloužení časového harmonogramu o čtrnáct měsíců, nejsou selháním provedení. Jsou to selhání informací. V programech racionalizace po fúzi se opakují tři specifické informační mezery:
Mezera 1: Uvedený účel versus skutečný účel
Vlastník aplikace popisuje, k čemu byl systém navržen. Po letech nebo desetiletích nahromaděných úprav systém zvládá podstatně více. CRM, které „spravuje vztahy se zákazníky“, může také provádět čtvrtletní výpočet provizí, zpracovávat výjimky pro největší účty a uchovávat jedinou kopii určitých smluvních podmínek ve formátu, na kterém závisí následné reportování. Nic z toho není v popisu vlastníka aplikace, protože nic z toho nebylo ani v původních požadavcích. Aplikace hromadila jedno alternativní řešení, každé řešilo okamžitý problém, aniž by se aktualizoval popis účelu systému.
Náklady na objevení mezery 1 po odchodu do důchodu: přestavba skrytých funkcí v náhradním systému, často za cenu nouzové situace, zatímco podnik funguje bez nich nebo s manuálními řešeními.
Mezera 2: Nedeklarované závislosti
Aplikace se jeví jako samostatná. Na jejím výstupu závisí dvanáct dalších systémů. Závislost nebyla nikdy formálně zdokumentována, protože byla stanovena prostřednictvím neformálního datového kanálu, který vývojář nastavil před třemi lety, aby vyřešil problém s reportingem. Vlastník aplikace o závislosti neví. Vlastníci závislých systémů vědí, že data přijímají, ale předpokládají, že pocházejí z „fakturačního systému“, aniž by věděli, který program je konkrétně vytváří.
Závislosti, které inventář nikdy neuváděl, jedna aplikace vypadá jako jednorázová, protože nikdo nezmapoval, co se na ní spoléhalo. Náklady na objevení mezery 2 po vyřazení z provozu: dvanáct systémů selhává nebo se zhoršuje způsobem, který se vrací k závislosti, která měla být součástí racionalizační analýzy, ale nebyla.
Nedostatek 3: Podhodnocení rozsahu migrace dat
Plán migrace dat odhaduje schéma cílového systému na základě aktuální dokumentace. Schéma má čtyřicet sedm variant nashromážděných za čtyřicet let změn obchodních pravidel, přičemž tři jsou zdokumentovány a čtyřicet čtyři jsou viditelné pouze v programovém kódu, který data čte a zapisuje. Migrace dat je zaměřena na tři zdokumentované varianty a je dokončena podle plánu. Po migraci procesy, které se spoléhaly na čtyřicet čtyři nezdokumentovaných variant, tiše selhávají a produkují nesprávné výstupy, které nejsou detekovány, dokud čtvrtletní zpráva nebo regulační podání neodhalí nesrovnalost.
Náklady na odhalení mezery 3 po migraci: analýza hlavní příčiny, oprava dat, přepracování a v regulovaných odvětvích regulační oznámení a náprava.
Pět racionalizačních rozhodnutí
Každá aplikace v kombinovaném portfoliu se mapuje na jeden z pěti výsledků racionalizace. Rozhodovací rámec platí jak pro starší, tak pro moderní aplikace, ačkoli důkazy potřebné k rozhodnutí se výrazně liší:
| Rozhodnutí | Definice | Kdy použít | Požadované primární důkazy |
|---|---|---|---|
| Udržet | Zachovat v současné podobě, provozováno sloučenou entitou | Unikátní funkcionalita, bez ekvivalentu v jiném portfoliu, odpovídající kvalita | Mapování obchodních funkcí, analýza závislostí |
| Konsolidujte | Sloučit funkce z obou verzí portfolia do jedné přežívající instance | Obě organizace provozují ekvivalentní funkce; jedna instance je nadřazená | Analýza funkčního překrytí, posouzení mezer ve funkcích, složitost migrace |
| modernizovaný | Zachovat obchodní funkci, transformovat technickou implementaci | Funkčnost je vyžadována, ale technická kvalita je příliš nízká na to, aby se dlouhodobě udržela. | Metriky kvality kódu, hodnocení složitosti, hodnocení technického dluhu |
| Nahradit | Ukončete aplikaci a nahraďte ji komerční nebo cloudovou alternativou. | Funkce je komodita; standardní produkt jí slouží adekvátně | Dostupnost alternativ na trhu, posouzení hloubky přizpůsobení |
| Odejít | Vyřazení z provozu bez náhrady | Funkce je skutečně redundantní, bez jedinečné logiky, bez aktivních konzumentů | Analýza mrtvého kódu, mapování závislostí potvrzující nulové aktivní uživatele |
Rozhodnutí, které vypadá jako „Stáhnout do vyřazení“, ale ve skutečnosti je „Ponechat“: Aplikace bez aktivních uživatelů, nízkého objemu transakcí a bez viditelných následných spotřebitelů se jeví jako kandidát na „Stáhnout do vyřazení“. Pokud obsahuje jedinečnou obchodní logiku, jurisdikční daňová pravidla, regulační výpočtové rutiny, zpracování smluvních závazků, které nebylo jinde replikováno, její vyřazení znamená trvalou ztrátu této logiky. Toto je scénář fakturačního systému z úvodu tohoto článku. Rozhodnutí se z inventáře jeví jako zřejmé; na základě důkazů je chybné.
Předpoklad pro strukturální analýzu
Racionalizace aplikací během fúzí a akvizic spočívá v rozhodnutí o ponechání, migraci, konsolidaci nebo vyřazení, které je součástí modelu transakce před jejím uzavřením. Skutečnou cenou jsou paralelní licence, skryté integrace a sekvence vyřazení.
Přesné rozhodování vyžaduje strukturální důkazy, které jdou nad rámec toho, co mohou vlastníci aplikací poskytnout v rozhovorech, co zaznamenávají systémy správy IT aktiv a co odhalují audity licencí SaaS. Pro starší aplikační vrstvu, systémy COBOL, zakázkové dávkové programy, proprietární middleware a databázové podnikové aplikace, které běží po celá desetiletí, existují strukturální důkazy pouze ve zdrojovém kódu.
Čtyři výstupy strukturální analýzy, které jsou nezbytné pro racionalizační rozhodnutí:
Inventář obchodní logiky. Jaká pravidla aplikace dekóduje? Nejde o funkční popis poskytnutý jejím vlastníkem, ale o specifické výpočty, podmíněné větvení, ověřovací pravidla a transformační logiku, které jsou implementovány v programovém kódu. U programů v COBOLu to znamená analýzu příkazu PROCEDURE DIVISION za účelem extrakce logiky IF/EVALUATE, příkazů COMPUTE a podmíněných cest zpracování, které implementují obchodní pravidla. Tento inventář je specifikací, které musí odpovídat jakýkoli náhradní nebo konsolidační systém.
Analýza fan-inů. Kolik dalších aplikací, programů nebo procesů závisí na výstupech této aplikace? Fan-in je primárním prediktorem rizika vyřazení z provozu: aplikace s nulovým fan-inem může bezpečně vyřadit z provozu; aplikace s padesáti fan-iny nese riziko, že vyřazení z provozu poškodí padesát dalších věcí. Ve starších prostředích fan-in zahrnuje nejen přímá volání API, ale i závislosti na datových kanálech, sdílené příjemce souborů VSAM, streamy úloh JCL, které volají program, a následné dávkové procesy, které čtou jeho výstupní datové sady.
Procento mrtvého kódu. Jaké procento kódu aplikace je nedosažitelné z žádné produkční cesty? Mrtvé kódy, které se nahromadily po desetiletí přidávání funkcí a oprav chyb, zvyšují zdánlivou složitost aplikace a zdánlivé náklady na modernizaci. Identifikace a vyloučení mrtvého kódu z rozsahu racionalizace poskytuje přesnější obraz o tom, co je skutečně nutné migrovat, konsolidovat nebo nahradit.
Složitost migrace dat. Jaká je struktura rozvržení záznamů každé datové sady, kterou aplikace spravuje? Kolik variant REDEFINES existuje? Která pole COMP-3 vyžadují mapování cílového typu se zachováním přesnosti? Jaká obchodní pravidla řídí data, na kterých jsou závislí uživatelé aplikace? Odpovědi určují, zda je migrace dat přímočarou konverzí schématu nebo několikaměsíčním programem transformace dat.
100denní časová osa: Když rychlost střetává s důkladností
Stodenní integrační plán je oborovým měřítkem pro rychlost realizace po fúzi. Investoři, členové představenstva a konzultanti managementu měří úspěšnost integrace podle tohoto časového harmonogramu. Tlak na prokázání včasné realizace synergie a na ukázání trhu, že transakce funguje, zhušťuje všechny pracovní procesy, včetně racionalizace aplikací.
Konflikt mezi tlakem časového harmonogramu a důkladností analýzy je místem, kde racionalizační programy generují své nejdražší chyby. Organizace, která nedokáže dokončit důkladnou strukturální analýzu svého kombinovaného portfolia do 100 dnů, čelí volbě: činit racionalizační rozhodnutí na základě neúplných informací, nebo promeškat časový harmonogram a čelit otázkám ohledně provedení integrace.
Předsevzetí, které si dospěli zralí akvizitéři, není zkrátit analýzu, ale seřadit rozhodnutí v pořadí:
Vlna 1 (dny 1–30): Pouze jasná a jednoznačná rozhodnutí. Aplikace, které jsou zjevně redundantní a nemají žádnou jedinečnou logiku, aplikace, které jsou jasně kandidáty na ponechání bez možnosti konsolidace, aplikace, které jsou již v plánu jedné organizace naplánovány k vyřazení. Tato rozhodnutí nevyžadují hloubkovou strukturální analýzu, protože výsledek je nepochybný. Jejich rychlé přijetí demonstruje dynamiku integrace bez rizika chybných rozhodnutí na základě neúplných informací.
Vlna 2 (dny 31–90): Rozhodnutí vyžadující cílenou analýzu. Aplikace, které se zdají být redundantní, ale jejichž výsledek racionalizace závisí na specifických strukturálních důkazech: existuje jedinečná obchodní logika? Jaký je počet migrací dat? Jak složitá je migrace dat? Strukturální analýza je zadávána konkrétně pro aplikace v této kategorii a zdroje se zaměřují na rozhodnutí, u kterých analýza mění výsledek.
Vlna 3 (91+ dní): Rozhodnutí vyžadující rozsáhlou analýzu. Aplikace, jejichž složitost činí 90denní racionalizační rozhodnutí skutečně nevhodnými, starší systémy s desítkami let nahromaděné logiky, sdílené datové platformy sloužící oběma organizacím, kritické dávkové programy, jejichž chování není plně pochopeno. Tyto aplikace jsou explicitně odloženy s dokumentovaným zdůvodněním, nikoli uspěchané s nesprávnou odpovědí.
Tento přístup k sekvenování slaďuje tlak časové osy s požadavkem na důkladnost: rané vlny demonstrují dynamiku; pozdější vlny chrání před katastrofálně chybnými rozhodnutími, která vedou k čtrnáctiměsíčnímu prodloužení časové osy.
Odprodej: Opačný problém
Akvizice vytvářejí potřebu konsolidovat dvě portfolia do jednoho. Odprodeje vytvářejí opačný problém: rozdělení portfolia, které bylo vybudováno jako integrovaný celek, na dvě nezávislá portfolia, která mohou fungovat bez sebe.
V kontextu odprodeje investičních aktiv společnost SpinCo často začíná svůj nový život s nafouklým portfoliem, které se skládá ze stávajících aplikací používaných výhradně společností SpinCo a aplikací, které sdílela s mateřskou společností, jako jsou HR a ERP. Mateřská společnost mezitím často čelí uvízlým nákladům na aplikace, kterých se zbavila spolu se společností SpinCo.
Problém racionalizace odprodeje se zásadně liší od problému akvizice, protože nejprve je třeba zodpovědět otázku oddělitelnosti: může tato aplikace fungovat nezávisle, nebo je integrována se zbývající organizací takovým způsobem, že čisté oddělení je nepraktické?
Program v COBOLu, který slouží odprodané obchodní jednotce, ale čte ze sdílené databáze na mainframe, která slouží i zbývající obchodní jednotce, není čistě oddělitelný. Možnosti oddělení jsou: replikace databáze (se složitostí udržování synchronizace během přechodu), migrace odprodaného programu do nové instance databáze (se složitostí migrace dat a rizikem behaviorální divergence) nebo pokračování v uspořádání sdíleného přístupu po oddělení (se složitostí správy dvou nezávislých subjektů sdílejících datovou infrastrukturu).
Každá z těchto možností má jiné dopady na náklady, riziko a časový harmonogram. Žádnou z nich nelze vyhodnotit bez přesné znalosti toho, jak program používá sdílenou databázi, které tabulky, která pole, v jakých přístupových vzorcích, s jakým objemem a frekvencí. Jedná se o strukturální analýzu staršího kódu, nikoli o kontrolu dokumentace.
Starší kód v oblasti fúzí a akvizic: Dimenze, kterou nikdo nezohledňuje
Problém racionalizace SaaS, tedy které aplikace si ponechat, které smlouvy ukončit a které dodavatele konsolidovat, je dobře řešen stávajícími nástroji a frameworky. Problém racionalizace staršího kódu nemá ve většině organizací ekvivalentní nástrojovou podporu.
Pokud jak nabyvatel, tak cílová společnost používají pro své hlavní obchodní procesy mainframové systémy COBOL, rozhodnutí o racionalizaci vyžaduje zodpovězení otázek, na které rozhovory s vlastníkem aplikace a systémy správy IT aktiv nemohou odpovědět:
Které programy v COBOLu jsou pro každou organizaci jedinečné? Portfolio mainframeů nabyvatele a portfolio mainframeů cílové společnosti se mohou překrývat ve funkci (obě provozují správu účtů), ale lišit se v implementaci (každý má desítky let akumulace jedinečných obchodních pravidel). Identifikace skutečného funkčního překrytí vyžaduje analýzu programů, nikoli čtení jejich označení.
Které programy jsou sdílené a které jsou specifické pro danou obchodní jednotku? Obslužný program JCL volaný čtyřiceti programy v rámci kombinované organizace je sdílená infrastruktura. Výpočtová rutina COBOL volaná třemi programy obsluhujícími jednu obchodní jednotku je specifická pro danou obchodní jednotku. Analýza fan-in v rámci kombinovaného inventáře programů tuto klasifikaci vytváří automaticky.
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.
Tento program vytváří specifický, auditovatelný výstup pro každou jurisdikci, kterou zpracovává. Jeho ukončení vyžaduje buď replikaci každé klauzule WHEN a každého podkladového cíle PERFORM v náhradním systému, nebo akceptování toho, že nahrazení bude pro některé jurisdikce produkovat odlišné výstupy. Ani jeden z výsledků není viditelný v inventáři aplikace. Oba jsou viditelné ve zdrojovém kódu COBOL.
Jaký je rozsah migrace dat pro každou aplikaci? Data spojená se starší aplikací v COBOLu jsou definována v položkách FD a sešitech, které mohly obsahovat více variant REDEFINES, pole COMP-3 vyžadující mapování s ohledem na přesnost a vložená omezení platnosti zachycená v názvech podmínek na úrovni 88. Migrace dat vymezená podle dokumentace, nikoli podle skutečného schématu, způsobuje selhání Gap 3.
Které programy obsahují nefunkční kód, který lze vyloučit z rozsahu migrace? Nefunkční kód ve starších programech zvyšuje zdánlivou složitost modernizace nebo migrace. Programy s 40 procenty nefunkčního kódu vyžadují analýzu a migraci o 40 procent více kódu, než kolik ve skutečnosti vyžaduje provozní chování. Identifikace nefunkčního kódu před uzamčením rozsahu migrace snižuje odhady úsilí a zlepšuje přesnost časové osy.
Kontrolní seznam pro rozhodnutí o žádosti o racionalizaci portfolia fúzí a akvizic
Pro každou aplikaci v rozsahu jsou před spolehlivým rozhodnutím o racionalizaci vyžadovány následující důkazy:
Posouzení obchodní logiky
- Byla skutečná funkce aplikace ověřena analýzou kódu, nikoli pouze rozhovorem s majitelem?
- Jsou všechna obchodní pravidla zakotvená v kódu zdokumentována ve formě, které musí odpovídat i náhrada?
- Pro programy v COBOLu: byly inventarizovány všechny větve EVALUATE, podmínky IF a příkazy COMPUTE?
Posouzení závislosti
- Bylo zavádění ventilátoru změřeno strukturálně (neodhadnuto vlastníkem aplikace)?
- Jsou všechny závislosti datových kanálů na úrovni JCL, souboru a databáze vyjmenovány?
- Byly vysledovány dynamické závislosti CALL, nejen statické hrany grafu volání?
Posouzení migrace dat
- Bylo z položek FD a členů COPY extrahováno kompletní rozvržení záznamu?
- Byly identifikovány všechny varianty REDEFINES a zdokumentovány jejich rozlišovací podmínky?
- Byla všechna pole COMP-3 a binární pole namapována na cílové typy s odpovídající přesností?
Posouzení mrtvého kódu
- Byl identifikován nefunkční kód a byl vyloučen z odhadů rozsahu migrace?
- Jsou rozhodnutí o vyřazení potvrzena analýzou mrtvého kódu (nulové navázání na funkcionalitu z produkčních cest)?
Klasifikace rizik
- Bylo skóre kritičnosti aplikace ověřeno oproti výsledkům strukturální analýzy?
- Je časový harmonogram udržení, migrace nebo odchodu do důchodu v souladu se složitostí závislostí?
Jak SMART TS XL Podporuje racionalizaci portfolia fúzí a akvizic
SMART TS XL poskytuje strukturální vrstvu důkazů pro racionalizační rozhodnutí, která nelze správně učinit pouze na základě dokumentace a rozhovorů.
Funkce statické analýzy kódu extrahuje inventář obchodní logiky z programovacích jazyků COBOL, JCL, Java, Python a všech ostatních jazyků v portfoliích obou organizací, čímž vytváří kompletní obraz o tom, co každá aplikace skutečně dělá, nejen o tom, co je uvedeno v jejím označení. U programů v COBOLu, jako je výše uvedený příklad výpočtu daně, tato analýza vyjmenovává každou jurisdikci, každou podmínku pravidla a každou větev výpočtu, kterou musí náhradní aplikace implementovat, aby dosáhla ekvivalentních výsledků.
Mapování závislostí aplikací poskytuje analýzu fan-in a fan-out, která určuje riziko vyřazení a pořadí konsolidace. U portfolií obou organizací analyzovaných současně mapa závislostí ukazuje, které programy jsou skutečně samostatné, které jsou hluboce integrovány do sdílené infrastruktury a které nesou skryté závislosti na downstreamu, ze kterých jsou tvořeny selhání Gap 2.
Díky analýze dopadů je každé navrhované racionalizační rozhodnutí před jeho provedením testovatelné: pokud bude tento program vyřazen z provozu, které další programy ztratí závislost? Pokud bude tato datová sada migrována, které programy musí být aktualizovány, aby mohly číst z nového umístění? Rozsah dopadu každého navrhovaného rozhodnutí je vyčíslitelný ze strukturálního modelu, čímž se racionalizační rozhodnutí převádějí z odhadů rizik na definované plány s omezeným rozsahem.
Analýza modernizace starších programů poskytuje skóre složitosti a identifikaci mrtvého kódu, což umožňuje přesné odhady úsilí: programy v dolním kvartilu složitosti s vysokým procentem mrtvého kódu jsou silnými kandidáty na vyřazení nebo modernizaci; programy v horním kvartilu složitosti s vysokým podílem fan-in jsou kandidáty na zachování bez ohledu na zdánlivou redundanci.
Díky funkci podnikového vyhledávání lze v kombinovaném portfoliu vyhledávat dotazy v celém racionalizačním programu: lze během několika sekund najít každý program, který přistupuje ke konkrétní datové sadě, každý program, který implementuje konkrétní obchodní funkci, každý program v COBOLu s cyklomatickou složitostí nad určitou prahovou hodnotou, a to napříč miliony řádků kódu obou organizací dohromady.
Pro organizace provádějící racionalizaci pod tlakem časového harmonogramu, SMART TS XLAnalýza zkracuje časový harmonogram strukturální analýzy: kompletní mapu závislostí, inventář obchodní logiky a hodnocení složitosti pro kombinované portfolio lze vytvořit během několika dní, nikoli za týdny nebo měsíce, které by vyžadovala manuální kontrola kódu. Tato komprese je to, co dělá přístup sekvencování Vlna 1 / Vlna 2 / Vlna 3 životaschopným, cílenou strukturální analýzu pro aplikace Vlna 2 lze dokončit v 90denním okně, které časový harmonogram umožňuje.
Rozhodnutí, které uděláte, je jen tak dobré, jako důkazy, které za ním stojí
Racionalizace portfolia po fúzi probíhá pod skutečným časovým tlakem, skutečným finančním tlakem a skutečným organizačním tlakem, aby se prokázalo, že dohoda funguje. Všechny tyto tlaky tlačí směrem k rychlejšímu rozhodování. Žádný z nich nemění cenu chybného rozhodnutí.
Fakturační systém, který byl naplánován k vyřazení z provozu a poté byl vyřazen z provozu za nouzové náklady, není varovným příběhem o příliš pomalém postupu. Je to varovný příběh o postupu bez důkazů, které by rozhodnutí změnily. Strukturální analýza, která odhaluje, co systém skutečně dělá, jeho vloženou obchodní logiku, skryté závislosti a složitost migrace dat, racionalizaci nezpomaluje. Zpřesňuje ji. A přesnost je v kontextu integračního programu po fúzi, kde chybná rozhodnutí generují osmnáctiměsíční prodloužení časového harmonogramu a devítimístné překročení nákladů, nejcennější vlastností, kterou může racionalizační rozhodnutí mít.
Úspěšná racionalizace portfolia není ta nejrychlejší. Je to ta, která ví, co racionalizuje.
