Portfolio-Rationalisierung nach Fusionen und Übernahmen

Das Abrechnungssystem des Zielunternehmens wurde in der dritten Woche des Integrationsprozesses als redundant eingestuft. Der Käufer verfügte über eine eigene Abrechnungsplattform, das fusionierte Unternehmen benötigte also kein zweites System, und das System des Zielunternehmens schien Funktionen zu duplizieren. Es sollte nach sechs Monaten außer Betrieb genommen werden. Im fünften Monat stellte das Migrationsteam jedoch fest, dass das Abrechnungssystem des Zielunternehmens nicht nur Rechnungen generierte, sondern auch 40 Jahre an länderspezifischer Steuerberechnungslogik für 63 Länder enthielt. Diese Logik war in COBOL-Programme eingebettet, die von einem Entwicklerteam betreut worden waren, dessen Mitglieder im zweiten Monat Abfindungen angenommen hatten. Die Abrechnungsplattform des Käufers deckte hingegen 18 Länder ab. Die Entscheidung zur Außerbetriebnahme wurde revidiert, das Entwicklerteam musste zu Notfallkonditionen neu zusammengestellt werden, und der Zeitplan für die Synergieeffekte verlängerte sich um 14 Monate.

Die Entscheidung zur Rationalisierung basierte auf dem scheinbaren Funktionsumfang des Systems. Sie hätte jedoch auf dem tatsächlichen Funktionsumfang basieren müssen. Dieser unterscheidet sich in jedem Anwendungsportfolio, insbesondere in Portfolios mit Altsystemen, die über Jahrzehnte gewachsene Geschäftslogik, undokumentierte Abhängigkeiten und institutionelles Wissen, das nur im Code existiert, umfassen.

Warum Fusionen und Übernahmen die Notwendigkeit einer Portfoliorationalisierung schaffen

Bei der Fusion zweier Unternehmen besteht unmittelbare Notwendigkeit, die Anwendungen beider Seiten zu rationalisieren, um eine einheitliche, konsolidierte Holding zu schaffen. In diesem Umfeld mit hohem Zeitdruck entscheidet die Fähigkeit zur schnellen Systemzusammenführung darüber, wie effizient das neue Unternehmen arbeiten kann.

Die Rationalisierung ist unumgänglich. Zwei Organisationen, die jeweils ihre eigenen ERP-, CRM-, HRMS-, Abrechnungsplattformen, Reporting-Suiten und Data Warehouses betrieben, verfügen nun über jeweils zwei Systeme. Die kombinierten Kosten für die Wartung paralleler Systeme, Lizenzen, Infrastruktur, Support und den operativen Aufwand für den Betrieb zweier Instanzen eines Systems, das letztendlich nur noch eine sein sollte, sind der Hauptgrund für die Kostensynergien, die den Kaufpreis rechtfertigten. Integrationszeitpläne sind im Vertragsmodell festgelegt. Die Realisierung der Synergien wird vom Vorstand überwacht. Eine Verzögerung der Rationalisierung führt nicht nur zur Verfehlung finanzieller Ziele, sondern stellt auch die strategische Logik des Deals infrage.

Die meisten Unternehmen bauen im Laufe der Zeit ein umfangreiches Portfolio an IT-Anwendungen auf, insbesondere wenn sie durch Fusionen und Übernahmen wachsen und ihre Abläufe und Ressourcen nach jeder Transaktion nicht vollständig integrieren. Betrachtet man die einzelnen Anwendungen ganzheitlich, so stehen viele von ihnen möglicherweise nicht im Einklang mit der Gesamtstrategie des Unternehmens im Bereich Fusionen und Übernahmen; sie wurden als punktuelle Lösungen entwickelt und unterstützen nicht unbedingt die unternehmensweiten Geschäfts- und Organisationsziele nach dem Abschluss der Transaktion.

Das Problem verschärft sich mit jeder weiteren Akquisition. Unternehmen, die durch sukzessive Übernahmen ohne konsequente Portfoliointegration nach der Fusion gewachsen sind, tragen die angehäuften technischen Schulden jedes einzelnen Deals mit sich herum, die sie nicht vollständig bewältigt haben. Durchschnittlich nutzen große Unternehmen über 370 SaaS-Anwendungen. Zwischen 25 und 30 Prozent dieser Lizenzen sind ungenutzt oder werden nur unzureichend genutzt. Schätzungsweise 19.8 Millionen US-Dollar an ungenutzten Lizenzen bleiben jährlich ungenutzt. Rechnet man die Legacy-Anwendungsschicht, die COBOL-Programme, proprietäre ERP-Anpassungen und Mainframe-Batchsysteme hinzu, die bei SaaS-Lizenzprüfungen nicht erfasst werden, ist das zu rationalisierende Portfolio deutlich größer als die reine SaaS-Liste vermuten lässt.

Die drei Lücken, die zu Rationalisierungsfehlern führen

Die Rationalisierungsentscheidungen, die zu der vierzehnmonatigen Fristverlängerung führen, sind keine Ausführungsfehler, sondern Informationslücken. Drei spezifische Informationslücken treten in Rationalisierungsprogrammen nach Fusionen immer wieder auf:

Lücke 1: Angegebener Zweck versus tatsächlicher Zweck

Der Anwendungsinhaber beschreibt den ursprünglichen Zweck des Systems. Nach Jahren oder Jahrzehnten der Anpassung leistet das System jedoch deutlich mehr. Ein CRM-System, das „Kundenbeziehungen verwaltet“, kann beispielsweise auch die vierteljährliche Provisionsberechnung durchführen, Ausnahmefälle für Großkunden bearbeiten und die einzige Kopie bestimmter Vertragsbedingungen in einem Format speichern, das für nachgelagerte Berichte benötigt wird. Nichts davon findet sich in der Beschreibung des Anwendungsinhabers, da es nicht zu den ursprünglichen Anforderungen gehörte. Es wurden nach und nach Workarounds entwickelt, die jeweils ein akutes Problem lösten, ohne die Beschreibung des Systemzwecks zu aktualisieren.

Die Kosten für die Entdeckung von Lücke 1 nach der Außerdienststellung: die Nachrüstung der versteckten Funktionen im Ersatzsystem, oft mit Notfallkosten, während der Geschäftsbetrieb ohne diese Funktionen oder mit manuellen Behelfslösungen weiterläuft.

Lücke 2: Nicht deklarierte Abhängigkeiten

Die Anwendung scheint eigenständig zu sein. Zwölf andere Systeme sind jedoch von ihren Ausgaben abhängig. Diese Abhängigkeit wurde nie formal dokumentiert, da sie durch einen informellen Datenfeed entstand, den ein Entwickler vor drei Jahren zur Lösung eines Berichtsproblems eingerichtet hatte. Der Anwendungsinhaber weiß nichts von der Abhängigkeit. Die Inhaber der abhängigen Systeme wissen zwar, dass sie die Daten erhalten, gehen aber davon aus, dass diese vom Abrechnungssystem stammen, ohne zu wissen, welches Programm sie konkret erzeugt.

Abhängigkeiten, die im Inventar nie aufgeführt wurden; eine Anwendung erscheint entbehrlich, weil niemand erfasst hat, was von ihr abhängt. Die Kosten der Entdeckung von Lücke 2 nach der Außerbetriebnahme: Zwölf Systeme fallen aus oder weisen Mängel auf, die sich auf eine Abhängigkeit zurückführen lassen, die in der Rationalisierungsanalyse hätte berücksichtigt werden müssen, aber nicht berücksichtigt wurde.

Lücke 3: Unterschätzung des Umfangs der Datenmigration

Der Datenmigrationsplan schätzt das Schema des Zielsystems anhand der aktuellen Dokumentation. Das Schema weist 47 Varianten auf, die sich im Laufe von 40 Jahren durch Änderungen der Geschäftsregeln angesammelt haben. Drei dieser Varianten sind dokumentiert, 44 sind lediglich im Programmcode sichtbar, der die Daten liest und schreibt. Die Datenmigration ist auf die drei dokumentierten Varianten ausgerichtet und wird planmäßig abgeschlossen. Nach der Migration schlagen die Prozesse, die auf den 44 undokumentierten Varianten basierten, unbemerkt fehl und erzeugen fehlerhafte Ergebnisse. Diese werden erst entdeckt, wenn ein Quartalsbericht oder eine behördliche Meldung die Diskrepanz aufdeckt.

Die Kosten für die Entdeckung von Gap 3 nach der Migration: Ursachenanalyse, Datenkorrektur, Neuverarbeitung und in regulierten Branchen behördliche Benachrichtigung und Abhilfemaßnahmen.

Die fünf Rationalisierungsentscheidungen

Jede Anwendung in einem kombinierten Portfolio lässt sich einem von fünf Rationalisierungsergebnissen zuordnen. Der Entscheidungsrahmen gilt sowohl für ältere als auch für moderne Anwendungen, wobei die für die Entscheidungsfindung erforderlichen Nachweise jedoch deutlich unterschiedlich sind:

Entscheidung	Definition	Wann bewerben?	Primärnachweis erforderlich
Behalten	Beibehaltung in der jetzigen Form, betrieben vom fusionierten Unternehmen	Einzigartige Funktionalität, kein Äquivalent im anderen Portfolio, angemessene Qualität	Geschäftsfunktionsabbildung, Abhängigkeitsanalyse
Sammeln	Die Funktionalität beider Portfolio-Versionen in einer einzigen verbleibenden Instanz zusammenführen	Beide Organisationen erfüllen gleichwertige Funktionen; eine Instanz ist überlegen.	Analyse funktionaler Überlappungen, Bewertung von Funktionslücken, Migrationskomplexität
Modernisieren	Die Geschäftsfunktion beibehalten, die technische Umsetzung transformieren	Die Funktionalität ist erforderlich, aber die technische Qualität ist zu mangelhaft, um sie langfristig aufrechtzuerhalten.	Codequalitätsmetriken, Komplexitätsbewertung, Bewertung technischer Schulden
Ersetzen	Die Anwendung sollte eingestellt und durch eine kommerzielle oder Cloud-native Alternative ersetzt werden.	Funktion ist Ware; ein Standardprodukt erfüllt diesen Zweck ausreichend.	Marktverfügbarkeit von Alternativen, Bewertung des Anpassungsgrades
In den Ruhestand gehen	Außerbetriebnahme ohne Ersatz	Die Funktion ist tatsächlich überflüssig, keine eigene Logik, keine aktiven Nutzer.	Analyse des toten Codes und Abhängigkeitsanalyse bestätigen, dass keine aktiven Konsumenten mehr vorhanden sind.

Die Entscheidung, die wie „Außer Betrieb nehmen“ aussieht, aber tatsächlich „Beibehalten“ bedeutet: Eine Anwendung ohne aktive Nutzer, geringes Transaktionsvolumen und ohne sichtbare nachgelagerte Kunden scheint ein Kandidat für die Außerbetriebnahme zu sein. Enthält sie jedoch einzigartige Geschäftslogik, länderspezifische Steuervorschriften, regulatorische Berechnungsroutinen oder die Verarbeitung vertraglicher Verpflichtungen, die nicht anderweitig repliziert wurden, bedeutet die Außerbetriebnahme den dauerhaften Verlust dieser Logik. Dies ist das Szenario des Abrechnungssystems aus dem Anfang dieses Artikels. Die Entscheidung erscheint anhand der Bestandsaufnahme offensichtlich; die Beweislage ist jedoch falsch.

Die Voraussetzung für die Strukturanalyse

Die Anwendungsrationalisierung im Rahmen von Fusionen und Übernahmen umfasst die Entscheidung, Anwendungen beizubehalten, zu migrieren, zu konsolidieren oder stillzulegen, und gehört vor dem Abschluss in das Transaktionsmodell. Parallele Lizenzen, versteckte Integrationen und die Reihenfolge der Stilllegung verursachen die eigentlichen Kosten.

Um diese Entscheidungen präzise treffen zu können, sind strukturelle Nachweise erforderlich, die über die Informationen hinausgehen, die Anwendungsbetreiber in Interviews liefern können, die IT-Asset-Management-Systeme erfassen und SaaS-Lizenzprüfungen ergeben. Für die Legacy-Anwendungsschicht – die COBOL-Systeme, die individuell entwickelten Batch-Programme, die proprietäre Middleware und die datenbankgestützten Geschäftsanwendungen, die seit Jahrzehnten im Einsatz sind – existieren die strukturellen Nachweise ausschließlich im Quellcode.

Vier Ergebnisse der Strukturanalyse, die für Rationalisierungsentscheidungen erforderlich sind:

Inventar der Geschäftslogik. Welche Regeln kodiert die Anwendung? Nicht die vom Eigentümer bereitgestellte Funktionsbeschreibung, sondern die spezifischen Berechnungen, bedingten Verzweigungen, Validierungsregeln und Transformationslogiken, die im Programmcode implementiert sind. Bei COBOL-Programmen bedeutet dies, die PROCEDURE DIVISION zu analysieren, um die IF/EVALUATE-Logik, die COMPUTE-Anweisungen und die bedingten Verarbeitungspfade zu extrahieren, die die Geschäftsregeln implementieren. Dieses Inventar ist die Spezifikation, die jedes Ersatz- oder Konsolidierungssystem erfüllen muss.

Fan-in-Analyse. Wie viele andere Anwendungen, Programme oder Prozesse sind von den Ausgaben dieser Anwendung abhängig? Der Fan-in-Wert ist der wichtigste Indikator für das Ausfallrisiko: Eine Anwendung mit einem Fan-in-Wert von null kann problemlos außer Betrieb genommen werden; bei einer Anwendung mit einem Fan-in-Wert von 50 besteht das Risiko, dass die Außerbetriebnahme 50 andere Systeme beeinträchtigt. In älteren Umgebungen umfasst der Fan-in-Wert nicht nur direkte API-Aufrufe, sondern auch Datenfeed-Abhängigkeiten, gemeinsam genutzte VSAM-Dateikonsumenten, JCL-Jobstreams, die das Programm aufrufen, und nachgelagerte Batch-Prozesse, die die Ausgabedatensätze lesen.

Anteil toten Codes. Welcher Anteil des Anwendungscodes ist von keinem Produktionspfad aus erreichbar? Toter Code, der sich über Jahrzehnte durch Funktionserweiterungen und Fehlerbehebungen angesammelt hat, lässt die Anwendung komplexer erscheinen und die Modernisierungskosten höher ausfallen. Die Identifizierung und der Ausschluss toten Codes aus dem Rationalisierungsumfang liefern ein genaueres Bild davon, was tatsächlich migriert, konsolidiert oder ersetzt werden muss.

Komplexität der Datenmigration. Wie ist die Datensatzstruktur der einzelnen vom Programm verwalteten Datasets? Wie viele REDEFINES-Varianten existieren? Welche COMP-3-Felder erfordern eine präzise Zieltypzuordnung? Welche Geschäftsregeln bestimmen die Daten, auf die die Nutzer des Programms angewiesen sind? Die Antworten entscheiden darüber, ob es sich um eine einfache Schema-Konvertierung oder ein mehrmonatiges Datentransformationsprogramm handelt.

Der 100-Tage-Zeitplan: Wenn Schnelligkeit und Gründlichkeit im Konflikt stehen

Der 100-Tage-Integrationsplan gilt in der Branche als Maßstab für die Umsetzungsgeschwindigkeit nach einer Fusion. Investoren, Vorstandsmitglieder und Unternehmensberater messen den Integrationserfolg anhand dieses Zeitrahmens. Der Druck, frühzeitig Synergien zu realisieren und dem Markt zu zeigen, dass die Transaktion funktioniert, beschleunigt alle Arbeitsabläufe, einschließlich der Anwendungsrationalisierung.

Der Konflikt zwischen Zeitdruck und Gründlichkeit der Analyse führt bei Rationalisierungsprogrammen zu den kostspieligsten Fehlern. Eine Organisation, die innerhalb von 100 Tagen keine umfassende Strukturanalyse ihres Gesamtportfolios durchführen kann, steht vor der Wahl: Entweder sie trifft Rationalisierungsentscheidungen auf Basis unvollständiger Informationen oder sie verpasst den Zeitplan und muss sich Fragen zur Umsetzung der Integration stellen.

Die Lösung, die erfahrene Akquisitionsunternehmen entwickelt haben, besteht nicht darin, die Analyse zu verkürzen, sondern die Entscheidungen zu sequenzieren:

Welle 1 (Tage 1–30): Nur klare und eindeutige Entscheidungen. Anwendungen, die eindeutig redundant sind und keine eigene Logik aufweisen, Anwendungen, die eindeutig beibehalten werden sollen und für die es keine Konsolidierungskandidaten gibt, sowie Anwendungen, deren Außerbetriebnahme bereits in der Roadmap einer Organisation vorgesehen ist. Diese Entscheidungen erfordern keine tiefgreifende Strukturanalyse, da das Ergebnis eindeutig feststeht. Eine zügige Entscheidungsfindung demonstriert die Dynamik der Integration, ohne das Risiko von Fehlentscheidungen aufgrund unvollständiger Informationen einzugehen.

Welle 2 (Tage 31–90): Entscheidungen, die eine gezielte Analyse erfordern. Anwendungen, die redundant erscheinen, deren Rationalisierungsergebnis jedoch von spezifischen strukturellen Erkenntnissen abhängt: Gibt es eine einzigartige Geschäftslogik? Wie hoch ist die Anzahl der Fan-In-Anschlüsse? Wie komplex ist die Datenmigration? Die Strukturanalyse wird speziell für die Anwendungen dieser Kategorie in Auftrag gegeben, wobei die Ressourcen auf die Entscheidungen konzentriert werden, deren Ergebnis durch die Analyse beeinflusst wird.

Welle 3 (ab Tag 91): Entscheidungen, die eine eingehende Analyse erfordern. Anwendungen, deren Komplexität eine Rationalisierung innerhalb von 90 Tagen unangebracht macht, Altsysteme mit jahrzehntelang angesammelter Logik, gemeinsam genutzte Datenplattformen beider Organisationen, unternehmenskritische Batch-Programme, deren Verhalten nicht vollständig verstanden ist. Diese Entscheidungen werden mit dokumentierter Begründung explizit verschoben, um nicht vorschnell zu einer falschen Entscheidung zu gelangen.

Dieser sequenzielle Ansatz bringt den Zeitdruck mit dem Erfordernis der Gründlichkeit in Einklang: Frühe Wellen demonstrieren Dynamik; spätere Wellen schützen vor katastrophalen Fehlentscheidungen, die zu vierzehnmonatigen Zeitverlängerungen führen.

Veräußerung: Das umgekehrte Problem

Akquisitionen erfordern die Zusammenführung zweier Portfolios zu einem einzigen. Veräußerungen hingegen schaffen das umgekehrte Problem: die Aufteilung eines Portfolios, das als integriertes Ganzes aufgebaut wurde, in zwei unabhängige Portfolios, die jeweils ohne das andere funktionieren können.

Im Rahmen einer Unternehmensausgliederung startet die ausgegliederte Gesellschaft (SpinCo) oft mit einem aufgeblähten Portfolio, bestehend aus den bestehenden, ausschließlich von ihr genutzten Anwendungen und den gemeinsam mit der Muttergesellschaft (ParentCo) genutzten Anwendungen wie HR- und ERP-Systemen. Die Muttergesellschaft hingegen bleibt häufig auf den Kosten für Anwendungen sitzen, die sie zusammen mit der SpinCo abgibt.

Die Herausforderung der Rationalisierung bei Veräußerungen unterscheidet sich grundlegend von der Herausforderung bei Akquisitionen, da zunächst die Frage der Trennbarkeit beantwortet werden muss: Kann diese Anwendung unabhängig betrieben werden oder ist sie so in die verbleibende Organisation integriert, dass eine saubere Trennung unpraktisch ist?

Ein COBOL-Programm, das die ausgegliederte Geschäftseinheit bedient, aber auf eine gemeinsam genutzte Mainframe-Datenbank zugreift, die auch von der verbleibenden Geschäftseinheit genutzt wird, lässt sich nicht sauber trennen. Die Trennungsoptionen sind: die Datenbank replizieren (mit dem Aufwand, die Synchronisierung während der Übergangsphase aufrechtzuerhalten), das ausgegliederte Programm auf eine neue Datenbankinstanz migrieren (mit dem Aufwand der Datenmigration und dem Risiko von Verhaltensabweichungen) oder die gemeinsame Zugriffsvereinbarung nach der Trennung fortführen (mit dem Aufwand der Governance zweier unabhängiger Einheiten, die sich die Dateninfrastruktur teilen).

Jede dieser Optionen birgt unterschiedliche Kosten-, Risiko- und Zeitrahmenrisiken. Ohne genaue Kenntnis darüber, wie das Programm die gemeinsam genutzte Datenbank verwendet – welche Tabellen, welche Felder, welche Zugriffsmuster, in welchem ​​Umfang und mit welcher Häufigkeit –, lässt sich keine der Optionen bewerten. Es handelt sich hierbei um eine Strukturanalyse des bestehenden Codes, nicht um eine Dokumentationsprüfung.

Legacy-Code bei Fusionen und Übernahmen: Die Dimension, die niemand berücksichtigt

Das Problem der SaaS-Rationalisierung – welche Anwendungen beibehalten, welche Verträge gekündigt und welche Anbieter konsolidiert werden sollen – lässt sich durch bestehende Tools und Frameworks gut lösen. Für die Rationalisierung von Legacy-Code gibt es in den meisten Unternehmen keine vergleichbare Unterstützung durch geeignete Tools.

Wenn sowohl der Erwerber als auch das Zielunternehmen Mainframe-COBOL-Systeme für ihre Kerngeschäftsprozesse nutzen, erfordert die Rationalisierungsentscheidung die Beantwortung von Fragen, die durch Interviews mit den Anwendungseigentümern und IT-Asset-Management-Systeme nicht beantwortet werden können:

Welche COBOL-Programme sind für die jeweilige Organisation einzigartig? Das Mainframe-Portfolio des Käufers und das des Zielunternehmens können sich zwar funktional überschneiden (beide führen Kontoverwaltungsprogramme durch), aber in der Implementierung unterscheiden (jedes verfügt über jahrzehntelange Erfahrung mit einzigartigen Geschäftsregeln). Um die tatsächliche funktionale Überschneidung zu ermitteln, ist es notwendig, die Programme zu analysieren, nicht nur die Bezeichnungen zu lesen.

Welche Programme gehören zur gemeinsamen Infrastruktur und welche sind unternehmensspezifisch? Ein JCL-Hilfsprogramm, das von vierzig Programmen im gesamten Unternehmen aufgerufen wird, gehört zur gemeinsamen Infrastruktur. Eine COBOL-Berechnungsroutine, die von drei Programmen eines einzelnen Geschäftsbereichs aufgerufen wird, ist unternehmensspezifisch. Diese Klassifizierung wird automatisch durch eine Fan-in-Analyse des gesamten Programmbestands erstellt.

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.

Dieses Programm erzeugt für jede verarbeitete Jurisdiktion eine spezifische, nachvollziehbare Ausgabe. Für die Ablösung des Programms müssen entweder alle WHEN-Klauseln und alle zugrunde liegenden PERFORM-Ziele in einem Ersatzsystem repliziert werden, oder es muss akzeptiert werden, dass das Ersatzsystem für einige Jurisdiktionen abweichende Ausgaben erzeugt. Beide Ergebnisse sind in der Anwendungsübersicht nicht sichtbar, jedoch im COBOL-Quellcode.

Welchen Umfang hat die Datenmigration für jede Anwendung? Die Daten einer bestehenden COBOL-Anwendung sind in FD-Einträgen und Copybooks definiert, die möglicherweise mehrere REDEFINES-Varianten, COMP-3-Felder mit präziser Zuordnung und eingebettete Gültigkeitsbedingungen in 88-stufigen Bedingungsnamen enthalten. Eine Datenmigration, die sich an der Dokumentation statt am tatsächlichen Schema orientiert, führt zu einem Fehler (Gap 3).

Welche Programme enthalten toten Code, der vom Migrationsumfang ausgeschlossen werden kann? Toter Code in Altsystemen erhöht die scheinbare Komplexität der Modernisierung oder Migration. Programme mit 40 Prozent totem Code erfordern die Analyse und Migration von 40 Prozent mehr Code, als im laufenden Produktivbetrieb tatsächlich notwendig ist. Die Identifizierung von totem Code vor Festlegung des Migrationsumfangs reduziert den geschätzten Aufwand und verbessert die Genauigkeit des Zeitplans.

Checkliste für die Antragsentscheidung zur Rationalisierung des M&A-Portfolios

Für jeden in den Geltungsbereich fallenden Antrag sind folgende Nachweise erforderlich, bevor eine Rationalisierungsentscheidung mit Sicherheit getroffen werden kann:

Bewertung der Geschäftslogik

• Wurde die tatsächliche Funktion der Anwendung durch eine Codeanalyse und nicht nur durch ein Interview mit dem Inhaber überprüft?
• Sind alle im Code eingebetteten Geschäftsregeln so dokumentiert, dass ein Ersatzcode dieser Dokumentation entsprechen muss?
• Für COBOL-Programme: Wurden alle EVALUATE-Zweige, IF-Bedingungen und COMPUTE-Anweisungen inventarisiert?

Abhängigkeitsbeurteilung

• Wurde der Fan-in strukturell gemessen (und nicht vom Anwendungsinhaber geschätzt)?
• Sind alle Datenfeed-Abhängigkeiten auf JCL-, Datei- und Datenbankebene aufgelistet?
• Wurden dynamische CALL-Abhängigkeiten verfolgt, nicht nur statische Kanten im Aufrufgraphen?

Bewertung der Datenmigration

• Wurde das vollständige Datensatzlayout aus den FD-Einträgen und COPY-Mitgliedern extrahiert?
• Wurden alle REDEFINES-Varianten identifiziert und ihre Unterscheidungsbedingungen dokumentiert?
• Wurden alle COMP-3- und Binärfelder auf die für die jeweilige Genauigkeit geeigneten Zieltypen abgebildet?

Bewertung von totem Code

• Wurde toter Code identifiziert und von den Schätzungen des Migrationsumfangs ausgeschlossen?
• Werden die Entscheidungen zur Außerbetriebnahme durch die Analyse von totem Code bestätigt (Null-Fan-In aus den Produktionsausführungspfaden)?

Risikoklassifizierung

• Wurde der Kritikalitätswert der Anwendung anhand der Ergebnisse der Strukturanalyse überprüft?
• Steht der Zeitplan für Beibehaltung, Migration oder Ruhestand im Einklang mit der Komplexität der Abhängigkeiten?

Wie SMART TS XL Unterstützt die Rationalisierung des M&A-Portfolios

SMART TS XL liefert die strukturelle Evidenzebene für die Rationalisierungsentscheidungen, die nicht allein auf der Grundlage von Dokumentation und Interviews korrekt getroffen werden können.

Die statische Codeanalyse extrahiert die Geschäftslogik aus COBOL, JCL, Java, Python und allen anderen Sprachen im Portfolio beider Organisationen. So entsteht ein vollständiges Bild der tatsächlichen Funktionsweise jeder Anwendung, nicht nur deren Bezeichnung. Bei COBOL-Programmen wie dem oben genannten Beispiel zur Steuerberechnung listet diese Analyse jede Zuständigkeit, jede Regelbedingung und jeden Berechnungszweig auf, den eine Ersatzlösung implementieren muss, um gleichwertige Ergebnisse zu erzielen.

Die Abbildung der Anwendungsabhängigkeiten ermöglicht die Fan-In- und Fan-Out-Analyse zur Bestimmung des Stilllegungsrisikos und der Konsolidierungsreihenfolge. Für die gleichzeitig analysierten Portfolios beider Organisationen zeigt die Abhängigkeitskarte, welche Programme tatsächlich eigenständig sind, welche tief in eine gemeinsame Infrastruktur integriert sind und welche die versteckten nachgelagerten Abhängigkeiten aufweisen, die für Ausfälle der zweiten Lücke verantwortlich sind.

Die Auswirkungsanalyse ermöglicht es, jede vorgeschlagene Rationalisierungsentscheidung vor ihrer Umsetzung zu testen: Wird dieses Programm eingestellt, welche anderen Programme verlieren dann ihre Abhängigkeit? Wird dieser Datensatz migriert, welche Programme müssen aktualisiert werden, um vom neuen Speicherort zu lesen? Der Wirkungsbereich jeder vorgeschlagenen Entscheidung lässt sich anhand des Strukturmodells abschätzen, wodurch Rationalisierungsentscheidungen von Risikoeinschätzungen in definierte, abgegrenzte Pläne umgewandelt werden.

Die Analyse der Legacy-Modernisierung liefert die Komplexitätsbewertung und die Identifizierung von totem Code, die genaue Aufwandsschätzungen ermöglichen: Programme im untersten Quartil der Komplexität mit einem hohen Anteil an totem Code sind starke Kandidaten für eine Stilllegung oder Modernisierung; Programme im obersten Quartil der Komplexität mit einem hohen Fan-In sind Kandidaten für die Beibehaltung, unabhängig von einer scheinbaren Redundanz.

Die unternehmensweite Suchfunktion ermöglicht die Abfrage des gesamten Portfolios während des Rationalisierungsprogramms: Finden Sie innerhalb von Sekunden jedes Programm, das auf einen bestimmten Datensatz zugreift, jedes Programm, das eine bestimmte Geschäftsfunktion implementiert, jedes COBOL-Programm mit einer zyklomatischen Komplexität oberhalb eines Schwellenwerts – und das über Millionen von Codezeilen beider Organisationen hinweg.

Für Organisationen, die unter Zeitdruck eine Rationalisierung durchführen, SMART TS XLDie Analyse von [Name des Unternehmens] verkürzt den Zeitrahmen für die Strukturanalyse: Die vollständige Abhängigkeitsübersicht, die Geschäftslogik-Inventarisierung und die Komplexitätsbewertung für ein kombiniertes Portfolio lassen sich innerhalb von Tagen erstellen, anstatt der Wochen oder Monate, die eine manuelle Codeüberprüfung in Anspruch nehmen würde. Diese Verkürzung macht den Ansatz der Sequenzierung in Welle 1, Welle 2 und Welle 3 praktikabel; die gezielte Strukturanalyse für Anwendungen der Welle 2 kann innerhalb des durch den Zeitplan vorgegebenen 90-Tage-Fensters abgeschlossen werden.

Die Qualität Ihrer Entscheidung hängt von den Beweisen ab, die ihr zugrunde liegen.

Die Portfolio-Rationalisierung nach Fusionen steht unter echtem Zeitdruck, echtem finanziellen Druck und echtem organisatorischem Druck, den Erfolg der Transaktion nachzuweisen. All diese Faktoren drängen auf schnellere Entscheidungen. Nichts davon ändert jedoch die Kosten einer Fehlentscheidung.

Das Abrechnungssystem, dessen Stilllegung geplant war und das dann mit Notfallkosten wieder in Betrieb genommen wurde, ist kein warnendes Beispiel für zu langsames Handeln. Es ist vielmehr ein warnendes Beispiel dafür, wie man ohne ausreichende Beweise handelt, die die Entscheidung hätten ändern können. Die Strukturanalyse, die die tatsächliche Funktionsweise eines Systems, seine eingebettete Geschäftslogik, seine versteckten Abhängigkeiten und die Komplexität der Datenmigration aufdeckt, verlangsamt die Rationalisierung nicht. Sie macht sie präzise. Und Präzision ist im Kontext eines Post-Merger-Integrationsprogramms, in dem Fehlentscheidungen zu 18-monatigen Projektverzögerungen und Kostenüberschreitungen im dreistelligen Millionenbereich führen, die wertvollste Eigenschaft einer Rationalisierungsentscheidung.

Die Portfolio-Rationalisierung, die erfolgreich ist, ist nicht die schnellste. Sie ist diejenige, die weiß, was sie rationalisiert.