Racjonalizacja portfela po fuzjach i przejęciach

System rozliczeniowy firmy docelowej został oznaczony jako zbędny w trzecim tygodniu prac integracyjnych. Nabywca posiadał własną platformę rozliczeniową, połączony podmiot nie potrzebowałby dwóch, a system firmy docelowej zdawał się dublować funkcjonalność. Zaplanowano jego wycofanie po sześciu miesiącach. W piątym miesiącu zespół ds. migracji odkrył, że system rozliczeniowy firmy docelowej nie tylko generował faktury, ale zawierał 40 lat specyficznej dla danej jurysdykcji logiki obliczania podatków w sześćdziesięciu trzech krajach, osadzonej w programach COBOL, które były utrzymywane przez zespół programistów, którzy wszyscy zaakceptowali pakiety odpraw w drugim miesiącu. Platforma rozliczeniowa firmy przejmującej obsługiwała osiemnaście krajów. Decyzja o wycofaniu została cofnięta, zespół programistów musiał zostać odbudowany w trybie awaryjnym, a harmonogram synergii wydłużył się o czternaście miesięcy.

Decyzja o racjonalizacji została podjęta na podstawie tego, co system pozornie robił. Powinna zostać podjęta na podstawie tego, co system faktycznie robił. W każdym portfolio aplikacji te kwestie różnią się, a najbardziej różnią się w przypadku portfolio obejmujących starsze systemy z dekadami nagromadzonej logiki biznesowej, nieudokumentowanymi zależnościami i wiedzą instytucjonalną, która nie istnieje nigdzie poza kodem.

Dlaczego fuzje i przejęcia stwarzają konieczność racjonalizacji portfela

Łącząc dwie firmy, jesteś natychmiast zmuszony do racjonalizacji wniosków każdej ze stron, aby stworzyć ujednolicony, skonsolidowany holding. W tym środowisku o wysokiej presji, możliwość szybkiego łączenia systemów decyduje o tym, jak szybko nowy podmiot będzie mógł działać efektywnie.

Racjonalizacja nie jest opcjonalna. Dwie organizacje, które korzystały z własnych systemów ERP, CRM, HRMS, platformy rozliczeniowej, pakietu raportów i hurtowni danych, mają teraz po dwa egzemplarze wszystkiego. Łączny koszt utrzymania systemów równoległych, licencji, infrastruktury, wsparcia oraz koszty operacyjne związane z uruchomieniem dwóch instancji tego, co ostatecznie powinno być jedną, są głównym czynnikiem synergii kosztowej, która uzasadniła cenę przejęcia. Harmonogramy integracji są zapisane w modelu transakcji. Realizacja synergii jest monitorowana przez zarząd. Brak racjonalizacji w terminie nie tylko nie osiąga celu finansowego, ale także podważa strategiczną logikę transakcji.

Większość firm z czasem gromadzi rozbudowane portfolio aplikacji informatycznych, zwłaszcza jeśli rozwijają się poprzez fuzje i przejęcia (M&A) i nie integrują w pełni swoich operacji i aktywów po każdej transakcji. Patrząc całościowo, wiele z tych aplikacji może nie być zgodnych z ogólną strategią M&A firmy; zostały one stworzone jako rozwiązania tymczasowe i niekoniecznie wspierają cele biznesowe i organizacyjne na poziomie przedsiębiorstwa po transakcji.

Skala problemu pogłębia się z każdym kolejnym przejęciem. Organizacja, która rozwijała się poprzez seryjne przejęcia bez rygorystycznej integracji portfela po fuzji, ponosi skumulowany dług techniczny z każdej transakcji, której nie w pełni przetworzyła. Przeciętne duże przedsiębiorstwo korzysta z ponad 370 aplikacji SaaS. Od 25 do 30 procent tych licencji jest niewykorzystanych lub znacząco niedostatecznie wykorzystywanych. Szacuje się, że organizacje co roku tracą około 19.8 miliona dolarów w niewykorzystanych licencjach. Dodając do tego starszą warstwę aplikacji, programy COBOL, zastrzeżone dostosowania ERP i systemy wsadowe dla komputerów mainframe, które nie pojawiają się w audytach licencji SaaS, okazuje się, że portfel, który musi zostać objęty racjonalizacją, jest znacznie większy, niż sugeruje inwentaryzacja SaaS.

Trzy luki powodujące niepowodzenia racjonalizacji

Decyzje racjonalizacyjne, które skutkują czternastomiesięcznym przedłużeniem harmonogramu, nie są błędami wykonawczymi. Są błędami informacyjnymi. W programach racjonalizacyjnych po fuzji powtarzają się trzy konkretne luki informacyjne:

Luka 1: Cel deklarowany a cel rzeczywisty

Właściciel aplikacji opisuje, do czego system został zaprojektowany. Po latach, a nawet dekadach kumulacji dostosowań, system oferuje znacznie więcej. CRM, który „zarządza relacjami z klientami”, może również obliczać kwartalne prowizje, obsługiwać przetwarzanie wyjątków dla największych kont i przechowywać jedyną kopię niektórych warunków umowy w formacie, od którego zależy raportowanie. Nic z tego nie znajduje się w opisie właściciela aplikacji, ponieważ nie było tego w pierwotnych wymaganiach. System gromadził jedno obejście problemu na raz, każde rozwiązujące natychmiastowy problem, bez aktualizowania czyjegokolwiek opisu przeznaczenia systemu.

Koszt wykrycia Luki 1 po przejściu na emeryturę: konieczność odtworzenia ukrytych funkcji w systemie zastępczym, często po awaryjnych kosztach, podczas gdy firma działa bez nich lub stosując ręczne obejścia.

Luka 2: Niezadeklarowane zależności

Aplikacja wydaje się być samodzielna. Dwanaście innych systemów jest zależnych od jej wyników. Zależność ta nigdy nie została formalnie udokumentowana, ponieważ została ustanowiona za pomocą nieformalnego źródła danych, które programista utworzył trzy lata temu w celu rozwiązania problemu z raportowaniem. Właściciel aplikacji nie wie o tej zależności. Właściciele systemów zależnych wiedzą, że otrzymują dane, ale zakładają, że pochodzą one z „systemu rozliczeniowego”, nie wiedząc, który program je generuje.

Zależności, których inwentarz nigdy nie wymienił, jedna aplikacja wydaje się być zbędna, ponieważ nikt nie zmapował, co od niej zależy. Koszt odkrycia Luki 2 po wycofaniu: dwanaście systemów ulega awarii lub degradacji w sposób, który prowadzi do zależności, która powinna być uwzględniona w analizie racjonalizacji, ale tak się nie stało.

Luka 3: Niedoszacowanie zakresu migracji danych

Plan migracji danych szacuje schemat systemu docelowego na podstawie aktualnej dokumentacji. Schemat ma czterdzieści siedem wariantów zgromadzonych w ciągu czterdziestu lat zmian reguł biznesowych, z czego trzy są udokumentowane, a czterdzieści cztery widoczne są jedynie w kodzie programu odczytującym i zapisującym dane. Zakres migracji danych jest dostosowany do trzech udokumentowanych wariantów i przebiega zgodnie z harmonogramem. Po migracji procesy oparte na czterdziestu czterech nieudokumentowanych wariantach ulegają awarii, generując nieprawidłowe wyniki, które nie są wykrywane do momentu ujawnienia rozbieżności w raporcie kwartalnym lub zgłoszeniu regulacyjnym.

Koszt wykrycia Luki 3 po migracji: analiza przyczyn źródłowych, korekta danych, ponowne przetwarzanie, a w przypadku branż regulowanych, powiadomienie organów regulacyjnych i działania naprawcze.

Pięć decyzji racjonalizacyjnych

Każda aplikacja w połączonym portfolio odpowiada jednemu z pięciu rezultatów racjonalizacji. Ramy decyzyjne mają zastosowanie zarówno do aplikacji starszych, jak i nowszych, choć dowody wymagane do podjęcia decyzji różnią się znacząco:

Decyzja	Definicja	Kiedy złożyć wniosek	Wymagany dowód pierwotny
Trzymać	Zachować w obecnej formie, obsługiwane przez połączony podmiot	Unikalna funkcjonalność, niedostępna w innych ofertach, odpowiednia jakość	Mapowanie funkcji biznesowych, analiza zależności
Konsolidować	Połącz funkcjonalność z obu wersji portfolio w jedną istniejącą instancję	Obie organizacje pełnią podobne funkcje, ale jedna z nich jest lepsza	Analiza nakładania się funkcji, ocena luk w funkcjach, złożoność migracji
zmodernizowany	Zachowaj funkcję biznesową, zmień wdrożenie techniczne	Funkcjonalność jest wymagana, ale jakość techniczna jest zbyt słaba, aby utrzymać ją w dłuższej perspektywie	Metryki jakości kodu, ocena złożoności, ocena długu technicznego
zastąpić	Wycofaj aplikację, zastąp ją alternatywą komercyjną lub natywną w chmurze	Funkcja jest towarem; standardowy produkt spełnia ją w wystarczającym stopniu	Dostępność alternatyw na rynku, ocena głębokości dostosowania
Przejść na emeryturę	Wycofanie ze służby bez zastąpienia	Funkcja jest rzeczywiście zbędna, nie ma unikalnej logiki, nie ma aktywnych konsumentów	Analiza martwego kodu, mapowanie zależności potwierdzające brak aktywnych konsumentów

Decyzja, która wygląda jak „Wycofaj”, ale w rzeczywistości brzmi „Zachowaj”: Aplikacja bez aktywnych użytkowników, z niskim wolumenem transakcji i bez widocznych odbiorców końcowych wydaje się być kandydatem do wycofania. Jeśli zawiera unikalną logikę biznesową, przepisy podatkowe obowiązujące w danej jurysdykcji, procedury obliczeniowe, przetwarzanie zobowiązań umownych, które nie zostały powtórzone gdzie indziej, wycofanie jej oznacza trwałą utratę tej logiki. To scenariusz systemu rozliczeniowego z początku artykułu. Decyzja wydaje się oczywista na podstawie inwentaryzacji; jest jednak błędna w świetle dowodów.

Wymagania wstępne analizy strukturalnej

Racjonalizacja aplikacji podczas fuzji i przejęć to decyzja o zachowaniu, migracji, konsolidacji lub wycofaniu, która jest częścią modelu transakcji przed jej zamknięciem. Licencje równoległe, ukryte integracje i sekwencja wycofywania to prawdziwy koszt.

Dokładne podejmowanie tych decyzji wymaga dowodów strukturalnych wykraczających poza to, co właściciele aplikacji mogą dostarczyć w wywiadach, co rejestrują systemy zarządzania zasobami IT i co ujawniają audyty licencji SaaS. W przypadku starszej warstwy aplikacji, systemów COBOL, niestandardowych programów wsadowych, zastrzeżonego oprogramowania pośredniczącego i aplikacji biznesowych opartych na bazie danych, które działają od dziesięcioleci, dowody strukturalne znajdują się jedynie w kodzie źródłowym.

Cztery wyniki analizy strukturalnej, których wymagają decyzje racjonalizacyjne:

Inwentaryzacja logiki biznesowej. Jakie reguły koduje aplikacja? Nie opis funkcjonalny dostarczony przez jej właściciela, ale konkretne obliczenia, rozgałęzienia warunkowe, reguły walidacji i logikę transformacji zaimplementowane w kodzie programu. W przypadku programów COBOL oznacza to analizę składniową DZIAŁU PROCEDURE w celu wyodrębnienia logiki IF/EVALUATE, instrukcji COMPUTE oraz ścieżek przetwarzania warunkowego implementujących reguły biznesowe. Ta inwentaryzacja to specyfikacja, którą musi spełniać każdy system zastępczy lub konsolidujący.

Analiza „fan-in”. Ile innych aplikacji, programów lub procesów jest zależnych od wyników tej aplikacji? „fan-in” jest głównym predyktorem ryzyka wycofania: aplikacja z zerowym „fan-in” może bezpiecznie wycofać się z eksploatacji; aplikacja z pięćdziesięcioma „fan-in” niesie ze sobą ryzyko, że wycofanie z eksploatacji spowoduje awarię pięćdziesięciu innych elementów. W starszych środowiskach „fan-in” obejmuje nie tylko bezpośrednie wywołania API, ale także zależności od źródeł danych, współdzielonych odbiorców plików VSAM, strumienie zadań JCL wywołujące program oraz dalsze procesy wsadowe odczytujące jego wyjściowe zestawy danych.

Procent martwego kodu. Jaki procent kodu aplikacji jest niedostępny z poziomu dowolnej ścieżki produkcyjnej? Martwy kod, który nagromadził się przez dekady dodawania funkcji i poprawek błędów, zawyża pozorną złożoność aplikacji i pozorny koszt modernizacji. Identyfikacja i wykluczenie martwego kodu z zakresu racjonalizacji daje dokładniejszy obraz tego, co faktycznie należy zmigrować, skonsolidować lub zastąpić.

Złożoność migracji danych. Jaka jest struktura układu rekordów w każdym zbiorze danych zarządzanym przez aplikację? Ile istnieje wariantów REDEFINES? Które pola COMP-3 wymagają mapowania typu docelowego z zachowaniem precyzji? Jakie reguły biznesowe rządzą danymi, od których zależą odbiorcy aplikacji? Odpowiedzi na te pytania decydują o tym, czy migracja danych jest prostą konwersją schematu, czy też wielomiesięcznym programem transformacji danych.

100-dniowa oś czasu: kiedy prędkość kłóci się z dokładnością

100-dniowy plan integracji jest branżowym punktem odniesienia w zakresie szybkości realizacji po fuzji. ​​Inwestorzy, członkowie zarządu i konsultanci ds. zarządzania mierzą sukces integracji w oparciu o ten harmonogram. Presja na wczesne wykazanie synergii, aby pokazać rynkowi, że transakcja działa, kompresuje każdy etap prac, w tym racjonalizację aplikacji.

Konflikt między presją terminową a dokładnością analizy to miejsce, w którym programy racjonalizacji generują najkosztowniejsze błędy. Organizacja, która nie jest w stanie przeprowadzić gruntownej analizy strukturalnej swojego połączonego portfela w ciągu 100 dni, stoi przed wyborem: podjąć decyzje racjonalizacyjne na podstawie niekompletnych informacji lub przegapić termin i stanąć przed pytaniami dotyczącymi realizacji integracji.

Rozwiązanie, jakie opracowali dojrzali nabywcy, nie polega na kompresji analizy, lecz na sekwencjonowaniu decyzji:

Fala 1 (dni 1-30): Tylko jasne i jednoznaczne decyzje. Aplikacje ewidentnie redundantne, bez unikalnej logiki, aplikacje wyraźnie oznaczone jako „zachowaj” bez kandydata do konsolidacji, aplikacje, które są już zaplanowane do wycofania w planie działania jednej organizacji. Decyzje te nie wymagają dogłębnej analizy strukturalnej, ponieważ ich wynik nie budzi wątpliwości. Szybkie podejmowanie decyzji pokazuje dynamikę integracji bez ryzyka podjęcia błędnych decyzji w oparciu o niekompletne informacje.

Fala 2 (dni 31–90): Decyzje wymagające ukierunkowanej analizy. Aplikacje, które wydają się zbędne, ale których wynik racjonalizacji zależy od konkretnych dowodów strukturalnych: czy istnieje unikalna logika biznesowa? Jaka jest liczba zgłoszeń? Jak złożona jest migracja danych? Analiza strukturalna jest zlecana specjalnie dla aplikacji z tej kategorii, koncentrując zasoby na decyzjach, w których analiza zmienia wynik.

Fala 3 (dni 91+): Decyzje wymagające rozszerzonej analizy. Aplikacje, których złożoność sprawia, że ​​90-dniowe decyzje racjonalizacyjne są rzeczywiście nieodpowiednie, przestarzałe systemy z logiką nagromadzoną przez dekady, współdzielone platformy danych obsługujące obie organizacje, krytyczne dla misji programy wsadowe, których działanie nie jest w pełni zrozumiałe. Są one wyraźnie odraczane z udokumentowanym uzasadnieniem, a nie pochopnie podejmowane w celu uzyskania błędnej odpowiedzi.

To podejście sekwencyjne łączy presję związaną z harmonogramem z wymogiem dokładności: wczesne fale pokazują dynamikę, późniejsze fale chronią przed katastrofalnymi błędnymi decyzjami, które generują czternastomiesięczne wydłużenie harmonogramu.

Sprzedaż: problem odwrotny

Przejęcia stwarzają konieczność konsolidacji dwóch portfeli w jeden. Sprzedaż aktywów stwarza problem odwrotny: rozdzielenie portfela, który został zbudowany jako zintegrowana całość, na dwa niezależne portfele, z których każdy może funkcjonować niezależnie od drugiego.

W kontekście sprzedaży aktywów, SpinCo często rozpoczyna nowe życie z rozdętym portfolio składającym się z istniejących aplikacji używanych wyłącznie przez SpinCo oraz aplikacji współdzielonych z ParentCo, takich jak HR i ERP. Tymczasem ParentCo często ponosi koszty utraconych aplikacji, które pozbyło się wraz ze SpinCo.

Wyzwanie związane z racjonalizacją sprzedaży aktywów zasadniczo różni się od wyzwania związanego z przejęciem, ponieważ najpierw należy odpowiedzieć na pytanie dotyczące możliwości oddzielenia: czy ta aplikacja może działać niezależnie, czy też jest zintegrowana z pozostałą częścią organizacji w sposób, który sprawia, że ​​całkowite oddzielenie jest niepraktyczne?

Program COBOL, który obsługuje wydzieloną jednostkę biznesową, ale odczytuje dane ze współdzielonej bazy danych mainframe, która obsługuje również pozostałą jednostkę biznesową, nie jest całkowicie rozdzielny. Opcje rozdzielenia to: replikacja bazy danych (ze złożonością utrzymania synchronizacji podczas przejścia), migracja wydzielonego programu do nowej instancji bazy danych (ze złożonością migracji danych i ryzykiem rozbieżności w działaniu) lub kontynuacja współdzielonego dostępu po rozdzieleniu (ze złożonością zarządzania dwoma niezależnymi jednostkami współdzielącymi infrastrukturę danych).

Każda z tych opcji wiąże się z innymi kosztami, ryzykiem i implikacjami czasowymi. Żadnej z nich nie można ocenić bez dokładnej wiedzy o tym, jak program korzysta ze współdzielonej bazy danych, z których tabel, pól, w jakich wzorcach dostępu, z jaką objętością i częstotliwością. To analiza strukturalna starego kodu, a nie przegląd dokumentacji.

Kod legacy w fuzjach i przejęciach: wymiar, którego nikt nie bierze pod uwagę

Problem racjonalizacji SaaS, czyli wybór aplikacji do zachowania, umów do rozwiązania, dostawców do konsolidacji, jest dobrze rozwiązywany przez istniejące narzędzia i frameworki. Problem racjonalizacji kodu źródłowego nie ma jednak odpowiedniego wsparcia w większości organizacji.

Gdy zarówno nabywca, jak i podmiot przejmowany wykorzystują systemy mainframe COBOL do przetwarzania swojej głównej działalności, decyzja o racjonalizacji wymaga udzielenia odpowiedzi na pytania, na które nie można udzielić odpowiedzi za pomocą wywiadów z właścicielami aplikacji ani systemów zarządzania zasobami IT:

Które programy COBOL są unikalne dla każdej organizacji? Portfolio komputerów mainframe nabywcy i portfolio komputerów mainframe podmiotu przejmowanego mogą się pokrywać pod względem funkcji (oba służą do zarządzania kontami), a jednocześnie różnić się pod względem implementacji (każdy z nich ma dziesiątki lat unikalnych reguł biznesowych). Identyfikacja rzeczywistego nakładania się funkcji wymaga analizy programów, a nie odczytywania etykiet.

Które programy są współdzielone, a które specyficzne dla danej jednostki biznesowej? Program narzędziowy JCL, wywoływany przez czterdzieści programów w całej połączonej organizacji, jest współdzieloną infrastrukturą. Procedura obliczeniowa COBOL, wywoływana przez trzy programy obsługujące jedną jednostkę biznesową, jest specyficzna dla danej jednostki biznesowej. Analiza typu „fan-in” w całym połączonym inwentarzu programów automatycznie generuje tę klasyfikację.

kobol

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

Ten program generuje konkretne, audytowalne dane wyjściowe dla każdej obsługiwanej jurysdykcji. Wycofanie go wymaga albo replikacji każdej klauzuli WHEN i każdego bazowego celu PERFORM w systemie zastępczym, albo zaakceptowania, że ​​system zastępczy wygeneruje inne dane wyjściowe dla niektórych jurysdykcji. Żaden z tych wyników nie jest widoczny w inwentarzu aplikacji. Oba są widoczne w kodzie źródłowym COBOL.

Jaki jest zakres migracji danych dla każdej aplikacji? Dane powiązane ze starszą aplikacją COBOL są zdefiniowane we wpisach FD i kopiach, które mogły zawierać wiele wariantów REDEFINES, pola COMP-3 wymagające mapowania uwzględniającego precyzję oraz osadzone ograniczenia ważności zapisane w nazwach warunków 88-poziomowych. Migracja danych ograniczona do dokumentacji, a nie do rzeczywistego schematu, powoduje błąd Gap 3.

Które programy zawierają martwy kod, który można wykluczyć z zakresu migracji? Martwy kod w starszych programach zawyża pozorną złożoność modernizacji lub migracji. Programy zawierające 40% martwego kodu wymagają analizy i migracji o 40% więcej kodu niż w rzeczywistości wymaga środowisko produkcyjne. Identyfikacja martwego kodu przed zablokowaniem zakresu migracji zmniejsza szacunki nakładu pracy i poprawia dokładność harmonogramu.

Lista kontrolna decyzji aplikacyjnych dla racjonalizacji portfela fuzji i przejęć

W przypadku każdego zastosowania objętego zakresem, aby można było podjąć decyzję o racjonalizacji z pewnością, wymagane są następujące dowody:

Ocena logiki biznesowej

• Czy faktyczna funkcjonalność aplikacji została zweryfikowana poprzez analizę kodu, a nie tylko wywiad z właścicielem?
• Czy wszystkie reguły biznesowe osadzone w kodzie są udokumentowane w formie, którą musi spełniać zamiennik?
• W przypadku programów COBOL: czy wszystkie gałęzie EVALUATE, warunki IF i polecenia COMPUTE zostały zinwentaryzowane?

Ocena zależności

• Czy fan-in został zmierzony strukturalnie (a nie oszacowany przez właściciela aplikacji)?
• Czy wszystkie zależności kanałów danych na poziomie JCL, pliku i bazy danych są wymienione?
• Czy śledzono dynamiczne zależności CALL, a nie tylko statyczne krawędzie grafu wywołań?

Ocena migracji danych

• Czy kompletny układ rekordu został wyodrębniony z wpisów FD i członków COPY?
• Czy zidentyfikowano wszystkie warianty REDEFINES i udokumentowano warunki je wyróżniające?
• Czy wszystkie pola COMP-3 i binarne zostały zamapowane na typy docelowe o odpowiedniej precyzji?

Ocena martwego kodu

• Czy zidentyfikowano martwy kod i wyłączono go z szacunków zakresu migracji?
• Czy decyzje o wycofaniu oprogramowania są potwierdzane analizą martwego kodu (brak wpływu ze ścieżek wykonania produkcyjnego)?

Klasyfikacja ryzyka

• Czy wynik krytyczności aplikacji został zweryfikowany na podstawie wyników analizy strukturalnej?
• Czy harmonogram retencji, migracji i wycofania jest zgodny ze złożonością zależności?

W jaki sposób SMART TS XL Wspiera racjonalizację portfela fuzji i przejęć

SMART TS XL zapewnia warstwę dowodową strukturalną dla decyzji racjonalizacyjnych, których nie można podjąć prawidłowo wyłącznie na podstawie dokumentacji i wywiadów.

Funkcja statycznej analizy kodu wyodrębnia inwentarz logiki biznesowej z języków COBOL, JCL, Java, Python i każdego innego języka w portfolio obu organizacji, tworząc pełny obraz tego, co każda aplikacja faktycznie robi, a nie tylko tego, co oznacza jej etykieta. W przypadku programów COBOL, takich jak powyższy przykład obliczenia podatku, analiza ta wymienia każdą jurysdykcję, każdy warunek reguły i każdą gałąź obliczeniową, którą zamiennik musi zaimplementować, aby uzyskać równoważne wyniki.

Mapowanie zależności aplikacji zapewnia analizę typu „fan-in” i „fan-out”, która określa ryzyko wycofania z eksploatacji i kolejność konsolidacji. Dla portfeli obu organizacji analizowanych jednocześnie, mapa zależności pokazuje, które programy są prawdziwie autonomiczne, które są głęboko zintegrowane ze wspólną infrastrukturą, a które niosą ze sobą ukryte zależności downstream, będące przyczyną awarii Gap 2.

Możliwość analizy wpływu sprawia , że ​​każda proponowana decyzja racjonalizacyjna jest testowalna przed jej wykonaniem: jeśli ten program zostanie wycofany, które inne programy utracą zależność? Jeśli ten zbiór danych zostanie zmigrowany, które programy muszą zostać zaktualizowane, aby odczytywać dane z nowej lokalizacji? Zakres wpływu każdej proponowanej decyzji jest wyliczalny z modelu strukturalnego, co pozwala na przekształcenie decyzji racjonalizacyjnych z szacunków ryzyka w zdefiniowane, określone plany.

Analiza modernizacji starszych systemów generuje ocenę złożoności i identyfikuje martwy kod, co pozwala na dokładne oszacowanie nakładu pracy: programy w dolnym kwartylu złożoności z wysokim odsetkiem martwego kodu to solidni kandydaci do wycofania lub modernizacji; programy w górnym kwartylu złożoności z wysokim wskaźnikiem zainteresowania to kandydaci do zachowania bez względu na pozorną redundancję.

Funkcja wyszukiwania w przedsiębiorstwie umożliwia przeszukiwanie połączonego portfolio w całym programie racjonalizacji: w ciągu kilku sekund można znaleźć każdy program uzyskujący dostęp do określonego zestawu danych, każdy program implementujący określoną funkcję biznesową, każdy program COBOL o złożoności cyklomatycznej przekraczającej określony próg, we wszystkich łącznie milionach wierszy kodu obu organizacji.

Dla organizacji przeprowadzających racjonalizację pod presją czasu, SMART TS XLAnaliza kompresuje oś czasu analizy strukturalnej: kompletną mapę zależności, inwentaryzację logiki biznesowej i ocenę złożoności dla połączonego portfela można uzyskać w ciągu kilku dni, a nie tygodni czy miesięcy, jak w przypadku ręcznego przeglądu kodu. To właśnie ta kompresja sprawia, że ​​podejście sekwencyjne Fali 1/Fali 2/Fali 3 jest wykonalne, a ukierunkowana analiza strukturalna dla aplikacji Fali 2 może zostać ukończona w ciągu 90 dni, na jakie pozwala oś czasu.

Decyzja, którą podejmujesz, jest tak dobra, jak dowody, które ją potwierdzają

Racjonalizacja portfela po fuzji odbywa się pod prawdziwą presją czasu, prawdziwą presją finansową i prawdziwą presją organizacyjną, aby wykazać, że transakcja się sprawdza. Wszystkie te naciski skłaniają do szybszego podejmowania decyzji. Żadna z nich nie zmienia jednak kosztów podjęcia złej decyzji.

System rozliczeniowy, który miał zostać wycofany, a następnie wycofany z użytku z powodu kosztów awaryjnych, nie jest przestrogą przed zbyt powolnym działaniem. Jest przestrogą przed działaniem bez dowodów, które mogłyby zmienić decyzję. Analiza strukturalna, która ujawnia faktyczne działanie systemu, jego wbudowaną logikę biznesową, ukryte zależności i złożoność migracji danych, nie spowalnia racjonalizacji. Sprawia, że ​​racjonalizacja jest dokładna. A dokładność, w kontekście programu integracji po fuzji, gdzie błędne decyzje generują osiemnastomiesięczne wydłużenie harmonogramu i dziewięciocyfrowe przekroczenie kosztów, jest najcenniejszą cechą, jaką może mieć decyzja racjonalizacyjna.

Racjonalizacja portfela, która się powiedzie, nie jest najszybsza. To ta, która wie, co racjonalizuje.