Smile Studio AP - stock.adobe.co
Softwareeinführung: 5 Integrationsprüfungen vor dem Rollout
Rollout-Termine im Kalender sind kein Beweis für die fertige Softwareintegration. Der Beitrag zeigt fünf Bereiche auf, die vor und nach dem Go-Live geprüft werden müssen.
Pläne für die Softwareeinführung können unfertige Arbeiten oft als weiter fortgeschritten erscheinen lassen, als sie tatsächlich sind.
Der Termin steht im Kalender. Der Anbieter hat einen Zeitplan. Für die Tests ist ein Zeitfenster vorgesehen. Für Schulungen ist ein Termin festgelegt. Dem Unternehmen wurde mitgeteilt, wann das System einsatzbereit sein wird.
Nichts davon ist schlecht. Es ist aber auch kein Beweis dafür, dass die Arbeit, die hinter dem Plan steht, bereits abgeschlossen ist.
Das ist wichtig, denn bei der Integration geht es nicht mehr nur darum, ob ein System Daten mit einem anderen austauschen kann. Das ist zwar nach wie vor die Grundvoraussetzung. Die schwierigere Frage bei der Einführung lautet jedoch, ob Daten, Workflows, Automatisierung, KI-Agenten, Geschäftsregeln und manuelle Übergaben nahtlos zusammenwirken können, ohne dass unter der Oberfläche Konflikte entstehen.
Genau hier kommen Orchestrierung und Kontext ins Spiel.
Die Orchestrierung bestimmt, wann eine Aufgabe fortgesetzt, angehalten, weitergeleitet, eskaliert oder zurückgestellt werden sollte, weil ein anderes System, ein Agent, eine Automatisierung oder ein Geschäftsprozess bereits aktiv ist. Der Kontext bestimmt, ob dieselbe Aktion in diesem konkreten Moment, für diesen Nutzer, in diesem Workflow, unter diesen Regeln und mit diesen Daten angemessen ist.
Auch die Begrifflichkeit kann tückisch sein. Anbieter verwenden die Begriffe Orchestrierung und Kontextbewusstsein möglicherweise auf unterschiedliche Weise, selbst wenn sie auf dieselbe Grundprämisse verweisen. In einem Produkt kann Orchestrierung die Weiterleitung von Workflows bedeuten. In einem anderen kann sie die Koordination von Agenten, die Durchsetzung von Richtlinien, das Hinzufügen manueller Kontrollpunkte oder die systemübergreifende Überwachung von Aktionen bedeuten. Kontext kann Benutzerberechtigungen, den Status eines Workflows, die Kundenhistorie, Geschäftsregeln, Datenverankerung oder ein anderes Signal bedeuten, anhand dessen die Software entscheidet, was als Nächstes geschehen soll.
Das führt zu einer praktischeren Frage seitens des Käufers: Was genau wird koordiniert, welcher Kontext wird herangezogen und wer kontrolliert die Regeln, wenn die Einführung in den Live-Betrieb übergeht?
Das macht nicht jede Einführung zu einem KI-Projekt. Es bedeutet jedoch, dass Softwareeinführungen unter der Haube zunehmend mehr Komplexität bewältigen müssen, während sie den Nutzern gleichzeitig eine einfachere Erfahrung versprechen.
Ein System kann verbunden sein und dennoch bei der Ausführung versagen. Ein Feld kann verschoben werden und dennoch den Kontext verlieren. Ein Workflow kann technisch gesehen von einer Anwendung zur anderen übergehen und dennoch mit einem anderen Prozess in Konflikt geraten. Eine Automatisierung kann ihre Aufgabe erfüllen und dennoch ein Problem für das nächste Team verursachen. Ein KI-Agent kann schnell handeln und dennoch im falschen Moment eingreifen.
Das ist der unangenehme Teil.
Eine Integration scheitert nicht nur, wenn Systeme keine Verbindung herstellen können. Sie scheitert auch, wenn niemand getestet hat, was die Verbindung eigentlich transportieren, koordinieren und verstehen soll.
Hier sind fünf Integrationsprüfungen, die durchgeführt werden sollten, bevor Software-Rollouts endgültig umgesetzt werden.
1. Prüfen Sie, welche Daten tatsächlich übertragen werden müssen
Die erste Frage zur Integration ist meist zu einfach: Können die Daten von einem System in ein anderes übertragen werden?
Das ist wichtig, reicht aber nicht aus.
Eine bessere Frage lautet: Was muss übertragen werden, in welcher Form, mit welcher Bedeutung, nach welchen Regeln und für wessen Entscheidung?
Daten wandern nicht allein. Sie tragen Definitionen, Zeitpunkte, Eigentumsverhältnisse, Berechtigungen, Geschäftsregeln und Prozessannahmen mit sich. Die CRM- und ERP-Integration ist ein bekanntes Beispiel: Ein Kundendatensatz, ein Lieferantenstatus, ein Mitarbeiterprofil, ein Produktartikel, eine Rechnung, ein Arbeitsauftrag oder ein Bestandsfeld mag innerhalb eines Systems übersichtlich erscheinen, wird aber verwirrend, sobald es an anderer Stelle landet.
So gewinnt die Fragmentierung von ERP-Daten an Bedeutung. Es geht nicht nur darum, dass verschiedene Systeme unterschiedliche Versionen desselben Datensatzes führen, sondern dass diese Unterschiede in die Einführung einfließen können, als wären sie bereits bekannt.
Ein Kunde kann in einem System für eine Dienstleistung bestätigt, in einem anderen jedoch aus Bonitätsgründen gesperrt sein. Ein Lieferant kann als zugelassen erscheinen, bis der Prozess in eine Region oder Kategorie mit anderen Regeln übergeht. Lagerbestände können als verfügbar erscheinen, bis ein anderes System anzeigt, dass sie reserviert, aus Qualitätsgründen gesperrt oder an eine Planungsannahme gebunden sind, die das Team nicht getestet hat.
Das sind keine exotischen Randfälle. Es handelt sich um gewöhnliche Unstimmigkeiten im Unternehmenskontext, die teuer werden, wenn sie erst spät entdeckt werden.
Bevor Rollout-Pläne feststehen, benötigen Teams eine Data-Governance-Strategie für die Datensätze, auf die es am meisten ankommt. Sie sollten wissen, welche Datensätze übertragen werden müssen, welches System die korrekten Daten hat, welche Felder für Entscheidungen entscheidend sind und wo lokale Definitionen den übergeordneten Prozess stören können.
Sie sollten auch wissen, welche Kontextinformationen mit den Daten übertragen werden müssen. Ein Feldwert reicht möglicherweise nicht aus. Das empfangende System muss möglicherweise wissen, woher die Daten stammen, ob sie aktuell sind, durch welchen Prozess sie erstellt wurden, welche Genehmigung gilt und ob ein anderer Workflow sie bereits nutzt.
Das Ziel ist nicht, jedes einzelne Datenelement vor dem Start zu bereinigen, sondern zu wissen, welche Daten nicht falsch, unvollständig oder ohne Kontext sein dürfen.
2. Überprüfen Sie die Übergabe, von der der Workflow abhängt
Integration wird oft als Verbindung von System zu System beschrieben. Das Unternehmen erlebt sie in der Regel als Übergabe: Eine Kaufanforderung wird zu einer Bestellanforderung. Ein Kundenauftrag wird zu einem Schritt in der Auftragsabwicklung. Ein Kundenproblem wird zu einer Eskalation. Eine Personaländerung wird zu einer Aktualisierung der Gehaltsabrechnung, der Sozialleistungen oder der Zugriffsrechte. Ein Projektmeilenstein wird zu einem Ereignis im Finanzwesen, in der Personalplanung oder im Berichtswesen.
Einige dieser Übergaben sind technischer Natur. Viele sind organisatorischer Art.
Deshalb muss die Zuständigkeit für den Workflow geklärt werden, bevor der Rollout-Plan zu weit fortgeschritten ist. Ein System weiß vielleicht, wohin der nächste Schritt führt, aber das Unternehmen weiß möglicherweise nicht, wer dafür verantwortlich ist, sobald er dort angekommen ist.
Dann kommt die Softwareanpassung ins Stocken. Die Plattform mag live sein, die Integration mag funktionieren, aber der alltägliche Prozess kann immer noch zwischen den Teams hängen bleiben, weil niemand die Verantwortung für den Übergang von einem System, einer Abteilung oder einem Entscheidungspunkt zum nächsten übernimmt.
Hier kommt Orchestrierung ins Spiel: Wer ist als Nächstes am Zug? Was löst den nächsten Schritt aus? Was sollte warten? Was sollte eskaliert werden? Was passiert, wenn ein anderes System, eine Automatisierung oder ein Mitarbeiter bereits an demselben Datensatz, Kunden, Fall, Mitarbeiter oder Auftrag arbeitet? Diese Fragen sind wichtig, denn bei der Orchestrierung geht es nicht nur darum, die Arbeit zu beschleunigen. Manchmal besteht die richtige Maßnahme darin, die Arbeit anzuhalten, zu unterbrechen oder anders weiterzuleiten, weil ein anderer Prozess Vorrang hat.
Deshalb ist das Timing genauso wichtig wie die Vernetzung. Den Abschluss eines Servicefalls kann der falsche Schritt sein, wenn die Rechnungsstellung noch eine Streitigkeit klärt. Die Aufhebung des Zugriffs kann ein Problem verursachen, wenn eine genehmigte Übertragung noch nicht alle erforderlichen Systeme durchlaufen hat. Die Beschaffung kann annehmen, dass ein Lieferant bereit für die nächste Phase ist, während die Risikoprüfung noch eine Überprüfung offen hat. Das Gleiche gilt für KI-Agenten. Zugriff auf den Datensatz ist nicht gleichbedeutend mit der Erlaubnis, darauf zu reagieren.
Die Übergabe muss mehr wissen als nur, wo sich das nächste System befindet; sie muss wissen, wann der nächste Schritt angebracht ist: Wer ist für die Arbeit verantwortlich, wenn sie ein System verlässt und in ein anderes übergeht? Was muss das empfangende Team wissen? Welche Informationen müssen bei der Übergabe mitgeliefert werden? Was soll geschehen, wenn das nächste System den Datensatz ablehnt, ein Feld fehlt oder ein Konflikt gemeldet wird? Wer darf das Problem beheben?
Diese Fragen mögen im Vergleich zum übergeordneten Implementierungsplan unbedeutend erscheinen.
Sie sind jedoch keineswegs unbedeutend; sie sind der Schnittpunkt zwischen Benutzererfahrung, Geschäftsprozess und Systemdesign. Ist dieser Schnittpunkt unklar, füllen Mitarbeiter die Lücke mit E-Mails, Tabellenkalkulationen, informellen Gesprächen und Behelfslösungen. Das mag die Einführung zwar am Laufen halten, schafft aber auch das nächste Integrationsproblem.
3. Überprüfen Sie Ausnahmen, bevor sie nach der Einführung zu Überraschungen werden
Jeder Rollout-Plan berücksichtigt den Happy Path. Die größere Herausforderung ist der Ausnahmefall: Was passiert, wenn der Kundendatensatz unvollständig ist? Wenn bei einem Lieferanten erforderliche Informationen fehlen? Wenn eine finanzielle Genehmigung verspätet eintrifft? Wenn sich ein Produktcode in einem System geändert hat, in einem anderen jedoch nicht? Wenn eine personelle Veränderung gleichzeitig Auswirkungen auf Personalwesen, Gehaltsabrechnung, Zugriffsrechte und Berichterstattung hat?
Die Antwort kann nicht lauten: Jemand wird sich darum kümmern. Wahrscheinlich wird das auch jemand tun. Aber das ist nicht dasselbe wie ein Prozess.
Ausnahmen sind der Punkt, an dem Annahmen zur Integration sichtbar werden. Sie zeigen, ob das Unternehmen den Prozess gut genug versteht, um ihn nach der Einführung zu unterstützen. Hier ist das Kontextbewusstsein mehr als nur ein Schlagwort der Anbieter.
Ein Standard-Workflow kann den Standardfall bewältigen. Eine Ausnahme erfordert jedoch in der Regel, dass das System, die Automatisierung, der Mitarbeiter oder die Person etwas über die jeweilige Situation versteht: den Kundenstatus, die Region, die Genehmigungsstufe, die Workflow-Phase, die Datenquelle, die Compliance-Regel, die Servicehistorie oder die geschäftlichen Konsequenzen eines voreiligen Handelns.
Das ist wichtig, weil Unternehmenssoftware in großem Maßstab selten aus einer einzigen, übersichtlichen Abfolge besteht. Software-Tools für das Geschäftsprozessmanagement können dabei unterstützen, Teile dieser Arbeit abzubilden, zu automatisieren und zu überwachen, aber das Rollout-Team muss dennoch die Workflows, Datensätze, Genehmigungen, Regeln, Integrationen und Punkte, an denen menschliches Urteilsvermögen gefragt ist, verstehen – all das muss unter Druck zusammenhalten.
Ein Rollout kann gewisse Unsicherheiten verkraften. Er kann jedoch keine endlose Ausnahmebehandlung überstehen, für die niemand verantwortlich ist.
Deshalb sollten Teams eine Handvoll unangenehmer Fälle testen, bevor der Plan feststeht – nicht nur die häufigste Transaktion, den Standard-Workflow oder den Pfad, den die Anbieter-Demo gezeigt hat.
Testen Sie die heiklen Fälle. Beginnen Sie mit den Datensätzen und Workflows, von denen man hofft, dass sie während der Einführung nicht auftreten: der Kunde mit zwei Identifikatoren, der Auftrag, der sich nach der Genehmigung ändert, der Mitarbeiter, dessen Rolle und Vorgesetzter sich gleichzeitig ändern, der Lieferant, der für eine Region in Ordnung ist, in einer anderen jedoch gesperrt ist. Das sind die Fälle, die zeigen, ob der Prozess weiß, wann er fortfahren, wann er anhalten und wann eine Person entscheiden muss.
Hier erfahren Teams, ob die Integration die Arbeit wirklich unterstützt.
Anzeichen dafür, dass die Voraussetzungen für die Integration noch nicht gegeben sind
Integrationsrisiken zeigen sich in der Regel bereits vor dem Start, wenn die Teams wissen, worauf sie achten müssen. Achten Sie auf folgende Warnzeichen:
- Teams definieren denselben Kunden, Lieferanten, Mitarbeiter, dasselbe Produkt oder denselben Auftrag auf unterschiedliche Weise.
- Die Übergabe erfolgt nach wie vor über E-Mail, Tabellenkalkulationen oder das Gedächtnis einer Person, die sich den nächsten Schritt merken muss.
- Niemand weiß genau, wer einen abgelehnten, unvollständigen oder widersprüchlichen Datensatz korrigiert.
- Ausnahmefälle wurden vor der Festlegung des Rollout-Plans nicht getestet.
- Die Berichterstellung hängt nach wie vor von manuellen Abgleichen zwischen den Systemen ab.
- Die Teams sind sich uneinig darüber, welches System die korrekten Daten enthält.
- Die Arbeit kann fortgesetzt werden, selbst wenn ein anderes System bereits denselben Datensatz oder denselben Prozess bearbeitet.
- Die Anweisungen der Anbieter zu Orchestrierung oder Kontext wurden nicht in konkrete Kontrollmaßnahmen umgesetzt.
- Es ist unklar, wer nach der Inbetriebnahme für die Integration verantwortlich ist.
- Eine lokale Notlösung wird bereits als Teil des Prozesses behandelt.
Keines dieser Anzeichen bedeutet automatisch, dass die Einführung gestoppt werden sollte. Sie deuten jedoch darauf hin, dass der Integrationsplan noch weiter ausgearbeitet werden muss, bevor die Software in Betrieb genommen wird.
4. Überprüfen Sie das Reporting anhand der integrierten Realität
Reporting wird oft als etwas betrachtet, das erst nach der Integration kommt. Das ist ein Fehler.
Reporting sollte einer der ersten Tests sein, um festzustellen, ob die Integration funktioniert. Führungskräfte wollen nicht nur, dass Systeme miteinander verbunden sind; sie wollen den Informationen vertrauen können, die die vernetzte Umgebung über das Geschäft liefert. Wenn die Einführung neue Unsicherheiten in Bezug auf Umsatz, Lagerbestände, Personaldaten, Kundenstatus, Serviceprobleme oder Prozessleistung schafft, hat sich das Integrationsproblem auf die Entscheidungsfindung ausgeweitet. Das ist ein Weg, auf dem Kosten zwischen Unternehmenssoftwaresystemen verloren gehen.
Die Kosten entstehen nicht immer durch eine fehlgeschlagene Implementierung; manchmal sind es langsamere Berichterstellung, doppelte Abgleiche, zusätzliche manuelle Überprüfungen, konkurrierende Dashboards, Schattentabellen oder Führungskräfte, die den Zahlen nicht mehr vertrauen. Deshalb sollte das Datenqualitätsmanagement Teil der Rollout-Planung sein und nicht erst dann von den Teams aufgegriffen werden, wenn Berichte voneinander abweichen.
Bevor die Rollout-Pläne feststehen, sollten Teams sich fragen, welche Berichte am ersten Tag wichtig sind, welche nach der Stabilisierung wichtig sind und welche geschäftlichen Fragen die Integration beantworten soll. Sie sollten außerdem wissen, welche Datenquellen diese Berichte speisen und wo sich die Definitionen zwischen den Systemen unterscheiden.
Dies ist nicht nur ein Problem des Berichtsteams. Wenn sich ein Workflow ändert, das Berichtsmodell jedoch nicht, können Führungskräfte möglicherweise die falschen Kennzahlen messen. Wenn sich ein Feld verschiebt, sich aber seine Bedeutung ändert, sieht der Bericht zwar korrekt aus, kann die Leser dennoch in die Irre führen. Wenn Teams weiterhin separate lokale Berichte führen, weil sie der integrierten Sichtweise nicht vertrauen, hat das Unternehmen das Problem nicht wirklich gelöst.
Reporting hilft auch dabei, Koordinationsprobleme aufzudecken. Wenn ein Prozess vorangetrieben wurde, sollten Führungskräfte erkennen können, warum dies geschah, was den Prozess ausgelöst hat, welches System aktiv wurde, ob eine Person ihn genehmigt hat und ob eine weitere Automatisierung oder ein weiterer Workflow beteiligt war.
Ein guter Integrationsplan sollte Reporting langweilig machen – nicht, weil Reporting unwichtig ist, sondern weil die Zahlen nicht jedes Mal zu einem neuen Streitpunkt werden sollten, wenn jemand fragt, ob die Einführung funktioniert hat.
5. Prüfen Sie, wer nach dem Start für die Integration verantwortlich ist
Die letzte Integrationsprüfung ist die, die Teams am häufigsten vermeiden: Wer ist nach dem Start dafür verantwortlich?
Nicht derjenige, der sie aufgebaut hat. Nicht derjenige, der sie konfiguriert hat. Nicht derjenige, der den Implementierungsplan abgezeichnet hat. Wer ist für die Integration verantwortlich, sobald die Nutzer sie einsetzen und das Unternehmen beginnt, Probleme zu entdecken?
Diese Frage ist wichtig, da Integrationen mit dem Go-Live nicht erstarrt sind. Geschäftsregeln ändern sich. Anbieter aktualisieren Systeme. Abteilungen fügen Felder hinzu. Workflows entwickeln sich weiter. Regulatorische Anforderungen verschieben sich. Verhandlungen mit KI-Anbietern können neue Funktionen, Datenbedingungen oder Preisstrukturen mit sich bringen, die beeinflussen, welche Funktionen aktiviert werden. Ein Team beginnt, eine Umgehungslösung zu nutzen, die zur Normalität wird. Ein lokaler Bericht wird zur inoffiziellen Wahrheit.
Das Gleiche gilt für die Orchestrierung und den Kontext. Die Regeln, die festlegen, wann Aufgaben weitergeleitet, angehalten, eskaliert oder einer menschlichen Überprüfung unterzogen werden, müssen sich ändern. Auch der Kontext, den ein System zur Entscheidungsfindung oder -weiterleitung nutzt, muss möglicherweise angepasst werden.
Ein Rollout-Plan kann die Integration wie eine Projektphase erscheinen lassen. Das Unternehmen erlebt sie jedoch als Betriebsmodell. Deshalb sollten frühzeitige Entscheidungen, die die Ergebnisse der Unternehmenssoftware prägen, nicht nur technische, sondern auch Verantwortlichkeitsentscheidungen beinhalten. Jemand muss wissen, welche Integrationen kritisch sind, welche Datenflüsse überwacht werden müssen, welche Übergaben Reibungsverluste verursachen, welchen Berichten man vertrauen kann und welche Orchestrierungsregeln überprüft werden müssen, bevor sie sich im gesamten Stack ausbreiten.
Diese Zuständigkeit kann sich über IT, Geschäftssysteme, Data Governance, Finanzen, Betrieb, Personalwesen, Kundenerfahrung oder andere Teams erstrecken. Das ist in Ordnung. Was nicht in Ordnung ist, ist so zu tun, als gäbe es eine Zuständigkeit, nur weil mehrere Gruppen beteiligt sind.
Auch bei geteilter Zuständigkeit braucht es ein Modell. Teams sollten wissen, wer Fehler überprüft, wer Änderungen genehmigt, wer die Dokumentation aktualisiert, wer reagiert, wenn der Geschäftsprozess nicht mehr zur Integration passt, und wer entscheidet, ob eine neue Anforderung in das Kernsystem oder in eine lokale Übergangslösung gehört. Sie sollten auch wissen, wer die Regeln kontrolliert, wenn Software zunehmend automatisiert agiert. Dazu gehören Workflow-Regeln, Eskalationsregeln, Sicherheitsvorkehrungen für KI-Agenten, manuelle Kontrollpunkte und die kontextbezogenen Signale, die das System verwenden darf. Ohne diese Struktur kann die Einführung zwar technisch gelingen, während die integrierte Umgebung jedoch langsam immer schwerer zu verwalten wird.
Der Rollout-Plan ist nicht der Integrationsplan. Er kann zwar angeben, wann das System in Betrieb genommen wird, aber er kann nicht belegen, dass die Arbeiten bereit für die Umstellung sind.
Genau darum geht es bei diesen Überprüfungen. Sie sollen nicht jedes Projekt verlangsamen oder jede Integrationsdiskussion in eine Governance-Übung verwandeln, sondern die Stellen aufdecken, an denen ein sauberer Rollout-Plan ungelöste Aufgaben verbergen kann: Welche Daten müssen übertragen werden? Welche Übergabe ist entscheidend? Was passiert, wenn der Prozess auf eine Ausnahme stößt? Ist die Berichterstattung vertrauenswürdig? Wer ist nach dem Start für die Integration verantwortlich? Diese Fragen sind praxisnah, weil sie genau dort ansetzen, wo Unternehmenssoftwareprojekte tatsächlich in Schwierigkeiten geraten – nicht im Abstrakten, nicht nur in der Architektur, sondern im täglichen Fluss von Daten, Entscheidungen, Genehmigungen, Berichten und Arbeitsabläufen über Systeme hinweg.
Sie gewinnen zudem an Bedeutung, da Software oberflächlich gesehen Einfachheit verspricht, während sie im Hintergrund mit größerer Komplexität umgeht. Der Nutzer sieht vielleicht einen übersichtlicheren Arbeitsablauf, eine bessere Benutzeroberfläche, eine automatisierte Empfehlung oder eine schnellere Antwort. Doch hinter dieser Erfahrung verbergen sich möglicherweise mehr Systeme, Regeln, Datenquellen, Automatisierungen und Akteure.
Das kann nützlich sein. Es kann aber auch riskant sein, wenn niemand weiß, was koordiniert wird, welcher Kontext verwendet wird und wer für das Ergebnis verantwortlich ist.
Bei der Integration von Unternehmenssoftware geht es nicht nur darum, Anwendungen miteinander zu verbinden. Es geht auch darum, genügend Sinnhaftigkeit, Kontrolle, Timing und Verantwortlichkeit für den Geschäftsprozess zu bewahren, damit dieser auch nach der Verbindung weiterhin funktioniert. Deshalb ist der beste Zeitpunkt, diese Fragen zu stellen, bevor der Rollout-Plan feststeht. Danach verschwinden die Fragen nicht. Sie werden lediglich teurer.
Dieser Artikel ist im Original in englischer Sprache auf Search ERP erschienen.
