IT-Zielarchitektur in der PMI: Welche Systeme überleben – und wer entscheidet das?
Spätestens nach dem Closing stellt sich eine Frage, die niemand offiziell auf die Agenda setzt: Wessen ERP-System bleibt? Wessen Cloud-Strategie setzt sich durch? Wessen ITSM-Plattform wird zum Standard? Sobald diese Fragen im Raum stehen, verändert sich die Dynamik im Integrationsteam – Mitarbeiter neigen dazu, sich Optionen zu sichern und Arbeitsgruppen beschäftigen sich möglicherweise mit Symbolfragen statt mit Architekturentscheidungen.
Das IT-Governance-Vakuum der ersten Wochen erzeugt das Momentum für diese Dynamik. Die IT-Zielarchitektur-Entscheidung ist der erste Moment, in dem sich zeigt, ob die etablierten Governance-Strukturen greifen – oder ob sie nur auf dem Papier existieren.
Ein IT-PMI-Lenkungskreis, der keine inhaltlich schwierigen Entscheidungen trifft, ist kein Steuerungsgremium – sondern bestenfalls ein Koordinierungsgremium. Die IT-Zielarchitektur-Frage ist die erste Entscheidung, bei der das Gremium zeigen kann, ob es tatsächlich mandatiert ist und ob die drei Prinzipien – keine neuen Investitionen ohne Abstimmung, kein Abschalten ohne Impact-Analyse, kein Systemaufbau außerhalb der Zielarchitektur – tatsächlich gelten.
Hinter jeder Systementscheidung stehen oftmals Menschen, die ihr Umfeld kennen, Vertrauen in ihre etablierten Werkzeuge haben und häufig Veränderungen skeptisch gegenüberstehen. Das ist keine Schwäche – es ist eine berechenbare Dynamik, die nicht ignoriert werden darf und gesteuert werden sollte.
Unternehmen, die die Zielarchitektur-Entscheidung als rein technische Frage behandeln, scheitern oftmals. Unternehmen, die sie als rein politische Frage behandeln, scheitern ebenso – nur teurer.
Die Frage, welches Integrationsmodell ein Unternehmen wählt – ob Vollintegration, Holding-Struktur oder ein Best-of-Breed-Ansatz – ist die strategische Vorentscheidung, die alles Weitere beeinflusst. Doch selbst wenn sie klar definiert ist, beantwortet sie eine entscheidende Folgefrage nicht: Welche konkreten Systeme überleben unter diesem Modell – und auf Basis welcher Kriterien wird das entschieden?
Genau hier entsteht in der PMI-Praxis die größte Handlungslücke. Ein vereinbartes Integrationsmodell gibt eine Zielrichtung vor. Es gibt aber keine Auskunft darüber, ob das ERP-System des Käufers oder das des Targets die Basis für die gemeinsame Zukunft bildet. Es klärt nicht, welche Hosting- und Betriebsumgebung als Standard etabliert werden soll. Es entscheidet auch nicht, welche (Sicherheits-)Tools etc. weiterhin Bestand haben und welche abgelöst werden.
Diese Lücke zwischen strategischem Rahmen und operativer Systementscheidung ist der Raum, in dem Integrationen scheitern – nicht weil die Strategie falsch war, sondern weil niemand einen strukturierten Prozess etabliert hat, der aus der Strategie konkrete Entscheidungen ableitet.
Eine belastbare Systementscheidung im Rahmen des IT-Zielarchitektur-Roadmappings braucht mehrere Bewertungsdimensionen – die in der Praxis selten gleichzeitig betrachtet werden.
Systementscheidungen, die nur auf technischen oder nur auf finanziellen Kriterien beruhen, erzeugen regelmäßig Nacharbeit in den nicht betrachteten Dimensionen. Das kostet nicht nur Geld – es kostet das Vertrauen der Stakeholder in den Integrationsprozess insgesamt.
Welches System erfüllt langfristig die funktionalen Anforderungen des Unternehmens? Mit welchem Aufwand können Systeme betrieben, integriert und skaliert werden? Welche technischen Schulden sind vorhanden?
Was kosten Betrieb, Migration und Transformation? Welche Vertragsfristen begrenzen den Entscheidungsspielraum? Jede kleinste Entscheidungsverzögerung kann dazu führen, dass sich Verträge automatisch verlängern. Dies verschiebt eine Konsolidierung potenziell um eine volle Vertragsperiode – ein Effekt, der in der Praxis regelmäßig zu sechsstelligen Mehrkosten führt, die kein Integrationsbudget eingeplant hat.
Welche Compliance-Anforderungen sind an das System geknüpft? Verarbeitet es personenbezogene Daten? Ist es im Scope einer bestehenden Zertifizierung z.B. nach ISO 27001 oder regulatorischer Anforderungen, z. B. gem. DORA? Eine Entscheidung für die Weiterführung oder Ablösung eines Systems hat oftmals regulatorische Konsequenzen – die im Entscheidungsprozess berücksichtigt werden muss.
In der PMI-Praxis verlieren Systeme nicht immer, weil sie schlechter sind. Sie verlieren aus anderen Gründen – und wer diese Dynamiken kennt, der kann sie auch steuern.
Das Heimvorteil-Prinzip wirkt systematisch: Das System des Käufers hat im Zweifel den Vorteil, dass die Menschen, die über die Weiterführung entscheiden, es kennen. Das Target-System ist das Fremde – und das Fremde trägt eine höhere „Beweislast“, auch wenn es technisch überlegen ist. Ohne eine explizit neutrale Bewertungsmatrix reproduziert jede Entscheidungsrunde potenziell diesen Effekt.
Sunk-Cost-Denken verzerrt Bewertungen: Wer in den letzten drei Jahren eine Plattform aufgebaut hat, bewertet ihren Fortbestand anders als eine neutrale Kosten-Nutzen-Analyse es täte. Das ist keine Böswilligkeit, sondern eine gut dokumentierte kognitive Verzerrung – die im Entscheidungsprozess explizit adressiert werden muss.
Fehlende Entscheidungsfristen lassen Zwischenzustände zur Dauerlösung werden: Wenn niemand festlegt, bis wann eine Systementscheidung gefallen sein muss, laufen beide Systeme mit ähnlicher Funktionalität weiter – Veränderungen bedürfen Ressourcen zur Analyse, Entscheidungsfindung und der erfolgreichen Umsetzung.
Ein wirksamer Gegenmechanismus: Systementscheidungen werden im IT-PMI-Lenkungskreis mit expliziten und dokumentierten Fristen getroffen.
Systemwechsel sind Kompetenzverluste für Menschen – wenn man sie nicht aktiv managed. Wer seit Jahren auf einer Plattform arbeitet, hat sich ein Wissen aufgebaut, das sich nicht einfach auf ein neues System übertragen lässt. In der PMI-Phase, in welcher Schlüsselpersonen ohnehin einem erhöhten Abwanderungsrisiko unterliegen, ist darauf stark zu achten.
Das bedeutet nicht, dass Systementscheidungen aus Rücksicht auf Personen aufgeschoben werden sollten. Es bedeutet, dass jede Systementscheidung von einer Kompetenz- und Transferplanung begleitet werden muss: Wer trägt das Wissen über das abzulösende System? Wie wird es gesichert? Wie wird der Übergang in das neue System strukturiert?
Unternehmen, die diese Thematik vernachlässigen, laufen Gefahr Mitarbeiter und deren Fachwissen in einer kritischen Phase zu verlieren.
Die IT-Zielarchitektur-Entscheidung ist keine technische Nebenaufgabe der PMI. Sie ist der erste große Praxistest der Governance-Strukturen und entscheidet darüber, ob die Integration in einem angemessenen zeitlichen Rahmen abgeschlossen werden kann oder dauerhaft in einem Zwischenzustand verbleibt.
Mehrere Prinzipien machen den Unterschied: Systementscheidungen brauchen einen strukturierten Prozess, der aus dem gewählten Integrationsmodell konkrete operative Konsequenzen ableitet – statt sie dem politischen Kräftespiel zu überlassen. Sie brauchen eine dreidimensionale Bewertung aus Funktion/Technologie, Kosten und Compliance, die explizit dokumentiert und im Lenkungskreis beschlossen wird. Und sie müssen von einer Kompetenz- und Wissenstransferplanung begleitet werden, die den Verlust von System-Know-how und relevanten Mitarbeitern aktiv adressiert.
Governance-Strukturen ohne inhaltliche Entscheidungen bleiben wirkungslos. Die IT-Zielarchitektur ist die erste Gelegenheit, aus Struktur Wirkung zu machen.