Warum Ihr digitales Unternehmensökosystem ab 3 Tools unübersichtlich wird und wie Sie Ordnung schaffen

Ein CRM für den Vertrieb, ein ERP für Aufträge, eine Buchhaltungssoftware für Rechnungen und zusätzliche Anwendungen für Projekte, Personal und Zusammenarbeit: Jede Lösung erfüllt zunächst einen nachvollziehbaren Zweck. Unübersichtlich wird das digitale Unternehmensökosystem, wenn Daten zwischen diesen Werkzeugen wandern, ohne dass ihre Herkunft, Qualität und Verantwortung eindeutig geregelt sind.

Die Grenze liegt nicht bei exakt drei Anwendungen. Auch zehn sauber integrierte Systeme können einfacher zu betreiben sein als drei schlecht aufeinander abgestimmte. Entscheidend sind die tatsächlichen Abhängigkeiten zwischen Anwendungen, Prozessen und Mitarbeitenden.

Für Schweizer KMU mit mehreren Standorten und begrenzten internen IT-Ressourcen ist deshalb eine einfache Vorgehensweise sinnvoll: bestehende Abläufe sichtbar machen, Kosten und Risiken je Verbindung erfassen, führende Datensysteme bestimmen und Änderungen in kontrollierten Etappen umsetzen. So entsteht eine Systemarchitektur, die wachsen kann, ohne jeden neuen Geschäftsprozess in zusätzliche manuelle Abstimmung zu verwandeln.

Warum 7 Einzellösungen oft teurer sind als 1 integrierter Stack

Sieben Einzellösungen können über drei Jahre mehr kosten als eine integrierte Software-Suite, wenn Lizenzgebühren, Schnittstellenwartung, Schulungen und manuelle Doppelarbeit zusammenkommen. Das ist jedoch kein allgemeines Kostengesetz. Eine Suite kann ebenfalls teuer werden, insbesondere bei aufwendiger Anpassung oder starker Anbieterabhängigkeit. Entscheidend ist ein Vergleich der vollständigen Betriebskosten beider Architekturen.

Der häufigste Kalkulationsfehler besteht darin, ausschliesslich die monatlichen Abonnements gegenüberzustellen. Ein CRM für 100 Franken und ein ergänzendes Projekttool für 80 Franken erscheinen zunächst günstiger als eine umfassendere Lösung. Diese Beträge sind ein rein hypothetisches Rechenbeispiel, keine Marktpreise. Sobald Mitarbeitende jedoch Informationen übertragen und IT-Verantwortliche Fehler korrigieren müssen, verändert sich die Wirtschaftlichkeit.

Eine dreijährige Gesamtkostenrechnung sollte mindestens folgende Positionen enthalten:

• Direkte Kosten: Lizenzen, Einführung, Konfiguration, Datenmigration und wiederkehrende Supportleistungen.
• Integrationskosten: Entwicklung, Überwachung, Fehlerbehebung und Anpassung von Schnittstellen.
• Prozesskosten: Arbeitszeit für doppelte Eingaben, Datenabgleiche, Rückfragen und Korrekturen.
• Organisationskosten: Schulungen, interne Ansprechpersonen und Abhängigkeit von einzelnen Mitarbeitenden.
• Wechselkosten: Datenexport, Vertragsbeendigung und spätere Ablösung einer Lösung.

Die Zahl möglicher direkter Verbindungen steigt mit der Anzahl beteiligter Systeme. Bei sieben Anwendungen ergeben sich mathematisch maximal 7 × 6 ÷ 2 = 21 unterschiedliche paarweise Verbindungen, wenn jedes System direkt mit jedem anderen verbunden wäre. Tatsächlich benötigen Unternehmen meist deutlich weniger Schnittstellen. Ein zentraler Integrationsdienst kann die Anzahl direkter Punkt-zu-Punkt-Verbindungen reduzieren.

Deshalb sollte nicht die theoretische Anzahl, sondern jede tatsächlich vorhandene Verbindung gezählt werden: Welche Anwendung sendet Daten an welche andere, in welcher Richtung und mit welchem Wartungsaufwand?

Besonders schwer sichtbar sind die Kosten der Schatten-IT. Mitarbeitende erstellen eigene Excel-Listen oder nutzen zusätzliche Cloud-Ablagen, weil offizielle Anwendungen ihren Arbeitsablauf nicht vollständig unterstützen. Solche Zwischenlösungen können spätere Migrationen erschweren und zusätzliche Risiken für Datenkontrolle und Zugriffsrechte schaffen.

Für Schweizer Unternehmen können hohe interne Personalkosten solche manuellen Tätigkeiten wirtschaftlich besonders relevant machen. Der tatsächliche Effekt muss jedoch mit eigenen Stundenaufzeichnungen und internen Kostensätzen ermittelt werden.

Bei Cloud-Lösungen gehört zudem die Kontrolle über gespeicherte Daten zur Wirtschaftlichkeitsbetrachtung. Die Informationen des Bundesamts für Cybersicherheit zu Cloud Computing behandeln unter anderem Verantwortlichkeiten, Datenexport, Sicherheitsanforderungen und Fähigkeiten der eigenen IT-Organisation. Diese Kriterien sind für die Bewertung langfristiger Anbieterabhängigkeiten relevant.

Eine Software-Suite ist also nicht automatisch die günstigere Wahl. Erst eine transparente Kostenrechnung zeigt, ob weniger Anwendungen tatsächlich weniger Aufwand bedeuten. Dafür muss zunächst die bestehende Systemlandschaft bekannt sein.

Wie kartieren Sie Ihre Systemlandschaft in 14 Tagen ohne Spezialsoftware

Sie können Ihre Systemlandschaft in 14 Tagen kartieren, indem Sie zuerst die tatsächlichen Arbeitsabläufe mit Prozessverantwortlichen aufnehmen und anschliessend Anwendungen, Datenflüsse, Schnittstellen und manuelle Übergaben in einer gemeinsamen Tabelle darstellen. Spezialsoftware ist für diese erste Bestandsaufnahme nicht erforderlich. Entscheidend ist, auch inoffizielle Werkzeuge und standortspezifische Abläufe zu erfassen.

Das zweiwöchige Vorgehen ist ein praktikabler Projektvorschlag, keine allgemein verbindliche Dauer. Bei wenigen Kernprozessen kann es ausreichen. Eine umfangreiche, historisch gewachsene IT-Landschaft benötigt möglicherweise zusätzliche Analysezeit.

Woche 1: Tatsächliche Abläufe aufnehmen. Befragen Sie die Verantwortlichen der wichtigsten Geschäftsprozesse, etwa Vertrieb, Auftragserfüllung, Einkauf, Buchhaltung und Personaladministration.

Stellen Sie bei jedem Gespräch dieselben Fragen:

• Mit welchem Ereignis beginnt der Prozess?
• Welche Anwendungen verwenden Sie nacheinander?
• Welche Informationen müssen Sie mehrfach eingeben?
• Wo speichern Sie Zwischenergebnisse?
• Wann übertragen Sie Daten per E-Mail, Datei oder Copy-and-paste?
• Welche Arbeitsschritte funktionieren nur dank einzelner erfahrener Mitarbeitender?

Die Frage nach Zwischenergebnissen ist besonders aufschlussreich. Sie macht häufig Tabellen, lokale Ordner oder zusätzliche Dienste sichtbar, die im offiziellen Softwareinventar fehlen.

Woche 2: Die Informationen zusammenführen. Erstellen Sie eine Prozess-System-Matrix in einem Tabellenprogramm. Jede Zeile beschreibt einen Arbeitsschritt; ergänzen Sie die verwendeten Anwendungen, Datenübergaben, Verantwortlichkeiten und auffälligen manuellen Aufwand.

Die Kartierung benötigt vier voneinander unterscheidbare Ebenen:

1. Anwendungen: Welche offiziellen und zusätzlichen Systeme werden verwendet?
2. Datenflüsse: Welche Informationen wechseln zwischen ihnen?
3. Schnittstellen: Erfolgt die Übertragung automatisiert, über Dateien oder manuell?
4. Transferaufwand: Wie häufig und wie lange beschäftigen sich Mitarbeitende mit der Übergabe?

Die methodische Grundlage ähnelt der Anleitung des Government Digital Service zur Erstellung einer Experience Map. Dort werden Gespräche mit verschiedenen Nutzern und eine schrittweise Visualisierung genutzt, um Abläufe und Abhängigkeiten sichtbar zu machen. Für die technische Systemkartierung müssen diese Methoden um Schnittstelleninformationen ergänzt werden.

Beginnen Sie mit den Prozessen, die häufig durchlaufen werden und viele manuelle Übergaben enthalten. Eine selten genutzte isolierte Anwendung ist nicht zwangsläufig dringlicher als eine alltägliche Datenübertragung zwischen CRM und ERP.

Das Ergebnis muss nicht perfekt sein. Eine überprüfte, verständliche Karte mit bekannten Lücken ist nützlicher als eine umfangreiche Dokumentation, die den tatsächlichen Arbeitsalltag nicht abbildet. Auf dieser Grundlage lässt sich anschliessend die Zielarchitektur auswählen.

Suite oder Best-of-Breed: Was passt besser bei 2 Standorten und 5 Kernprozessen

Für zwei Standorte mit fünf Kernprozessen eignet sich eine integrierte Suite besonders dann, wenn die Abläufe weitgehend standardisiert sind und wenig interne IT-Kapazität für Schnittstellenpflege verfügbar ist. Best-of-Breed kann sinnvoller sein, wenn einzelne Prozesse spezielle Funktionen benötigen. Entscheidend sind der tatsächliche Integrationsaufwand, die Unterschiede zwischen Standorten und die langfristige Betriebsverantwortung.

Eine Suite bündelt mehrere Funktionen innerhalb einer gemeinsamen Produktlandschaft. Best-of-Breed bedeutet, für einzelne Aufgaben jeweils spezialisierte Lösungen auszuwählen und diese miteinander zu verbinden.

Beide Modelle können erfolgreich sein. Die passende Entscheidung hängt weniger von der Unternehmensgrösse ab als davon, wie gut die vorhandenen Prozesse standardisiert werden können.

Für eine konkrete Entscheidung sollten die fünf wichtigsten Prozesse an beiden Standorten nebeneinandergelegt werden. Stimmen Eingaben, Genehmigungen, Zuständigkeiten und Ergebnisse überein? Oder existieren wesentliche Unterschiede, etwa bei Lagerhaltung, Projektfreigaben oder Rechnungsprüfung?

Im ersten Fall lassen sich gemeinsame Prozesse oft leichter in einer Suite abbilden. Im zweiten Fall muss geprüft werden, ob die Suite erforderliche Abweichungen unterstützt, ohne übermässige Sonderkonfigurationen zu verursachen.

Die eigentliche Architekturfrage lautet: Wer trägt die dauerhafte Verantwortung? Eine Suite verlagert einen Teil der technischen Integration zum Anbieter, schafft aber Abhängigkeiten bei Produktentwicklung, Vertragsbedingungen und Datenexport. Best-of-Breed ermöglicht gezieltere Produktauswahl, verlangt dafür klare Zuständigkeiten für Datensynchronisation, Fehlerüberwachung und Updates.

Ein hybrider Ansatz kann sinnvoll sein: beispielsweise eine gemeinsame Plattform für standardisierte kaufmännische Prozesse und eine spezialisierte Fachanwendung für einen geschäftskritischen Sonderprozess. Auch hier müssen Datenverantwortung und Übergaben eindeutig dokumentiert sein.

Für Schweizer KMU mit kleiner IT-Abteilung sollte vor der Beschaffung geklärt werden, wer nach der Einführung Schnittstellen betreibt, Störungen analysiert und notwendige Anpassungen finanziert.

Eine tragfähige Architektur minimiert nicht einfach die Anzahl der Anwendungen. Sie reduziert unnötige Abhängigkeiten und macht verbleibende Verantwortlichkeiten beherrschbar. Besonders deutlich wird dieser Unterschied bei der doppelten Pflege von Unternehmensdaten.

Der Integrationsfehler, der 30% Ihrer Arbeitszeit in Doppelpflege verwandelt

Der entscheidende Integrationsfehler entsteht, wenn Anwendungen zwar Daten austauschen, aber keine eindeutige Verantwortung für deren Pflege und Konsistenz besteht. Dadurch korrigieren Mitarbeitende dieselben Informationen in mehreren Systemen. Ob dabei tatsächlich 30 Prozent der Arbeitszeit verloren gehen, lässt sich nicht allgemein belegen. Der Anteil muss im jeweiligen Unternehmen gemessen werden.

Ein typisches Beispiel ist die Kundenadresse. Der Vertrieb korrigiert sie im CRM, die Buchhaltung verwendet weiterhin den alten Datensatz im ERP und die Projektleitung hält eine dritte Variante in einer Tabelle fest. Eine technische Schnittstelle kann existieren und trotzdem falsche oder veraltete Daten übertragen.

Das Problem liegt dann nicht ausschliesslich in der Datenübertragung, sondern in fehlenden Regeln zur Datenherrschaft.

Die folgenden Symptome helfen bei der Ursachenanalyse:

Ein führendes System pro zentralem Datentyp ist eine wichtige organisatorische Regel. So kann das CRM für definierte Kundendaten verantwortlich sein, während das ERP bestimmte Artikel- und Buchungsdaten führt. Andere Anwendungen verwenden diese Informationen lesend oder ergänzen ausdrücklich zugewiesene Felder.

Die technische Microsoft-Dokumentation zu Datenintegrationsmustern behandelt das sogenannte System of Record sowie Übertragungsrichtung, Synchronisationsbedarf, Fehlerbehandlung und Skalierbarkeit als Kriterien für Integrationsentscheidungen.

Die Regel muss auf Datenfeldebene ausreichend präzise sein. Ein CRM kann beispielsweise die allgemeine Kontaktadresse eines Kunden verwalten, während das ERP rechtlich oder fachlich relevante Rechnungsinformationen nach eigenen Freigaberegeln führt. Die gesamte Entität «Kunde» muss nicht zwangsläufig einer einzigen Anwendung vollständig gehören.

Für die Messung von Doppelpflege genügt zunächst eine einwöchige Arbeitszeiterfassung. Mitarbeitende dokumentieren, welche Informationen sie mehrfach erfassen, wie oft das geschieht und wie lange die jeweiligen Tätigkeiten dauern.

Die Auswertung setzt den erfassten Zeitaufwand ins Verhältnis zur tatsächlich verfügbaren Arbeitszeit der betroffenen Personen. So entsteht eine unternehmensspezifische Kennzahl statt eines ungeprüft übernommenen Prozentwerts. Wichtig ist, notwendige fachliche Kontrollen von unnötiger Doppelpflege zu unterscheiden.

Erst wenn klar ist, welche Daten führend sind und welche Übertragungen unnötig erfolgen, sollten Integrationen umgebaut oder Anwendungen abgelöst werden. Andernfalls kann eine Migration dieselben Probleme lediglich in eine neue Softwarelandschaft verschieben.

In welcher Reihenfolge sollten Sie 4 Systeme ablösen, ohne den Betrieb zu stoppen

Vier bestehende Systeme sollten anhand ihrer Betriebskritikalität, Schnittstellenabhängigkeiten und Migrationsrisiken abgelöst werden. Häufig eignet sich eine weniger kritische Anwendung mit klar begrenzten Schnittstellen als erster Schritt. Besonders eng verflochtene Kernsysteme folgen später. Diese Reihenfolge ist eine Orientierung, keine starre Regel: Zusammengehörige Funktionen müssen gegebenenfalls gemeinsam migriert werden.

Vor der Planung ist deshalb die Systemlandkarte entscheidend. Sie zeigt, welche Anwendungen Daten liefern, welche davon abhängen und an welchen Stellen ein Austausch andere Prozesse unterbrechen könnte.

Ein hypothetisches Schweizer KMU möchte vier Anwendungen ersetzen: eine interne Aufgabenverwaltung, ein separates Dokumentenarchiv, ein CRM und ein ERP. Eine mögliche Reihenfolge könnte so aussehen:

1. Die Aufgabenverwaltung ablösen, sofern keine kritischen automatisierten Prozesse von ihr abhängen.
2. Das Dokumentenarchiv migrieren, nachdem Zugriffsrechte, Ablagestruktur und Verweise auf Dokumente geprüft wurden.
3. Das CRM umstellen, nachdem Kundenstammdaten, Integrationen und Verantwortlichkeiten geklärt sind.
4. Das ERP zuletzt migrieren, wenn seine Abhängigkeiten und zentralen Geschäftsprozesse vollständig verstanden und abgesichert sind.

Diese beispielhafte Reihenfolge wäre ungeeignet, wenn beispielsweise das Dokumentenarchiv unmittelbar für einen kritischen ERP-Prozess benötigt wird oder das CRM eine zentrale Datenquelle für zahlreiche andere Anwendungen darstellt.

Die grundlegende Methode ist eine Migration in kontrollierten Funktionsblöcken. Statt alle Anwendungen an einem Wochenende auszutauschen, werden klar abgegrenzte Fähigkeiten nacheinander übernommen.

Die Microsoft-Architekturdokumentation zum Strangler-Fig-Muster beschreibt ein entsprechendes Prinzip zur schrittweisen Modernisierung: Neue Komponenten übernehmen ausgewählte Funktionen, während verbleibende Funktionen zunächst weiterhin vom bisherigen System bereitgestellt werden.

Dieses Muster eignet sich nicht für jede Unternehmenssoftware. Technische Voraussetzungen, Herstellerbeschränkungen und eng gekoppelte Datenmodelle können eine andere Migrationsstrategie erforderlich machen.

Besonders kritisch ist der Parallelbetrieb. Wenn zwei Anwendungen denselben Prozess bearbeiten, entstehen vorübergehend zusätzliche Kosten und Risiken für widersprüchliche Daten.

Deshalb braucht jede Migrationsetappe vor ihrem Beginn überprüfbare Kriterien:

• Welche Daten müssen vollständig und korrekt übernommen sein?
• Welche Geschäftsprozesse müssen in der neuen Lösung erfolgreich funktionieren?
• Welche Schnittstellen müssen getestet und überwacht werden?
• Wer gibt die Umstellung fachlich und technisch frei?
• Unter welchen Bedingungen wird die Migration angehalten oder zurückgesetzt?

Die Stilllegung des Altsystems darf nicht nur an einem Kalendertag hängen. Ein Unternehmen kann beispielsweise zwei vollständig durchlaufene und abgeglichene Geschäftsperioden als internes Freigabekriterium festlegen, wenn dies zum jeweiligen Prozess passt. Die Zahl ist eine mögliche Projektentscheidung, keine allgemeine technische Vorgabe.

Der wichtigste Vorbereitungsschritt bleibt die genaue Abgrenzung der Prozesse und ihrer Übergaben. Dafür muss nicht jedes Unternehmen zuerst ein komplexes Prozessmodellierungsprojekt starten.

Wie dokumentieren Sie 1 Kernprozess in 90 Minuten, ohne dass es akademisch wird

Ein Kernprozess lässt sich in 90 Minuten ausreichend dokumentieren, wenn der Workshop auf tatsächliche Arbeitsschritte, beteiligte Anwendungen und Datenübergaben konzentriert bleibt. Statt ein vollständiges Prozesshandbuch zu erstellen, verfolgen Sie einen konkreten Vorgang vom Start bis zum Ergebnis. Eine einfache Tabelle reicht aus, um die wichtigsten Integrationspunkte und ungeklärten Verantwortlichkeiten festzuhalten.

Diese Methode dient der Vorbereitung von Systementscheidungen und Schnittstellenprojekten. Sie ersetzt weder umfassende technische Spezifikationen noch formelle Prozessnachweise, wenn solche für andere Zwecke benötigt werden.

Für einen kompakten Workshop bietet sich folgende Aufteilung an:

1. 15 Minuten – Prozessrahmen: Startauslöser, erwartetes Ergebnis, Beteiligte und Verantwortliche festlegen.
2. 45 Minuten – Tatsächlicher Ablauf: Einen typischen Vorgang Schritt für Schritt mit der ausführenden Person durchspielen.
3. 15 Minuten – Systemwechsel: Manuelle Übertragungen, Datenwechsel und Schnittstellen markieren.
4. 15 Minuten – Offene Punkte: Unklare Regeln, Sonderfälle und noch zu prüfende Abhängigkeiten dokumentieren.

Ein geeigneter Prozess wäre beispielsweise der Weg vom angenommenen Kundenauftrag bis zur Rechnungsfreigabe. Die Beteiligten erklären nicht nur, was laut Prozessbeschreibung geschehen sollte, sondern zeigen anhand eines geeigneten Vorgangs, welche Schritte sie tatsächlich ausführen.

Als Minimalformat genügt eine Tabelle mit fünf Spalten: Prozessschritt, ausführende Person oder Rolle, verwendetes System, Eingabe und Ausgabe.

Das Beispiel ist hypothetisch. In einem konkreten Unternehmen müssen die tatsächlichen Schritte und verwendeten Systeme aufgenommen werden.

Markieren Sie anschliessend jeden Wechsel von einer Anwendung in eine andere. Prüfen Sie, ob Daten automatisch übertragen, manuell neu eingegeben oder erst nach einer persönlichen Rückfrage vervollständigt werden.

Sonderfälle sollten zunächst in einer separaten Liste stehen. Wird bereits während des ersten Workshops versucht, jede Ausnahme vollständig zu modellieren, bleibt häufig zu wenig Zeit für die zentralen Integrationsprobleme.

Das Ergebnis wird direkt in die übergeordnete Systemlandkarte übertragen. Dort lassen sich gleiche Schnittstellen, wiederkehrende Datenprobleme und kritische Abhängigkeiten über mehrere Prozesse hinweg erkennen.

Eine gute Dokumentation ist nicht möglichst umfangreich, sondern für die nächste Entscheidung verwendbar. Das gilt besonders bei Systemupdates, die bestehende technische Abhängigkeiten verändern können.

Warum 12 Schnittstellen plötzlich instabil werden, sobald 1 System-Update kommt

Ein einzelnes Systemupdate kann mehrere Schnittstellen gleichzeitig beeinträchtigen, wenn es Datenfelder, API-Versionen, Berechtigungen oder Verarbeitungsregeln verändert. Bei zwölf angeschlossenen Schnittstellen können unterschiedliche Prozesse betroffen sein, obwohl nur eine Anwendung aktualisiert wurde. Entscheidend ist nicht allein die Anzahl der Verbindungen, sondern welche technischen Annahmen sie gemeinsam nutzen.

Ein CRM-Update kann beispielsweise die Benennung eines Datenfelds verändern, eine bisher genutzte API-Version ablösen oder strengere Zugriffsberechtigungen einführen. Davon können gleichzeitig eine ERP-Anbindung, ein Reporting-Prozess und ein automatisierter Datenexport abhängen.

Ein anderes Risiko besteht darin, dass Schnittstellen weiterhin technisch erreichbar sind, aber fachlich falsche Informationen übertragen. Ein verändertes Feldformat kann Datenverarbeitung stören, ohne dass jede Anwendung unmittelbar eine sichtbare Fehlermeldung erzeugt.

Ein Schnittstellenregister schafft deshalb eine wichtige Grundlage für kontrollierte Updates. Für jede Verbindung sollten mindestens diese Informationen vorliegen:

• Quell- und Zielsystem sowie fachlicher Zweck.
• Technisch und fachlich verantwortliche Person.
• Übertragene Datenfelder und Datenrichtung.
• Verwendete API-Version beziehungsweise Übertragungstechnik.
• Bekannte Abhängigkeiten und erforderliche Aktualisierungsintervalle.
• Vorhandene Tests, Überwachung und Verfahren zur Fehlerbehandlung.

Vor einem Update wird dieses Register mit den angekündigten Produktänderungen verglichen. Dadurch entsteht eine konkrete Liste potenziell betroffener Schnittstellen, anstatt sämtliche Verbindungen ohne Priorisierung zu untersuchen.

Ein einfacher Update-Testkatalog sollte die Anmeldung, die erfolgreiche Datenübertragung, die korrekte Feldzuordnung, die Behandlung fehlerhafter Datensätze und die fachliche Vollständigkeit prüfen.

Besondere Aufmerksamkeit verdienen Schnittstellen, die nur selten hohe Datenmengen verarbeiten oder ausschliesslich bei periodischen Geschäftsvorgängen aktiv werden. Fehler können dort erst bei Monatsabschlüssen, Jahreswechseln oder aussergewöhnlichen Lastsituationen sichtbar werden.

Bei Neuanschaffungen sollten Schweizer KMU zudem vertraglich klären, welche API-Versionen unterstützt werden, wie Änderungen angekündigt werden und wer notwendige Schnittstellenanpassungen übernimmt. Dabei handelt es sich um sinnvolle Beschaffungskriterien, nicht um eine hier behauptete allgemeine gesetzliche Verpflichtung.

Technische Tests ersetzen allerdings keine fachliche Kontrolle. Auch bei erfolgreicher Übertragung muss geprüft werden, ob die Daten in der Zielanwendung richtig interpretiert und verarbeitet werden.

Damit wird die Integrationsarchitektur robuster. Dauerhaft zuverlässige Geschäftsprozesse entstehen jedoch erst, wenn neben dem Datenaustausch auch die Übergabe von Verantwortung geregelt ist.

Warum ganzheitlich vernetzte Systeme trotz Integration an Übergaben scheitern

Ganzheitlich vernetzte Systeme können trotz funktionierender Schnittstellen an Übergaben scheitern, weil technischer Datenaustausch keine organisatorische Verantwortung ersetzt. Eine Anwendung kann Informationen vollständig übertragen, ohne sicherzustellen, dass die empfangende Abteilung sie geprüft, verstanden und übernommen hat. Zuverlässige Übergaben benötigen deshalb festgelegte Pflichtinformationen, Verantwortlichkeiten und überprüfbare Abnahmekriterien.

Der Unterschied zeigt sich besonders deutlich an den Schnittstellen zwischen Abteilungen.

Bei der Übergabe vom Vertrieb an die Projektleitung können Kundendaten und Auftragsnummer korrekt übertragen werden. Fehlen jedoch vereinbarte Leistungsgrenzen, Termine oder besondere Anforderungen, muss die Projektleitung trotzdem Rückfragen stellen.

Bei einer kaufmännischen Übergabe an die Buchhaltung können alle Rechnungsdaten technisch vorhanden sein, während die fachliche Leistungsfreigabe noch aussteht. Eine automatisierte Übertragung darf nicht mit einer erteilten Genehmigung verwechselt werden.

Auch zwischen Entwicklung und Produktion können technisch korrekte Dateien unvollständig sein, wenn wichtige Versionsangaben, Freigaben oder ergänzende Arbeitsanweisungen fehlen.

Ein wirksames Übergabeprotokoll beschreibt daher nicht nur die beteiligten Systeme, sondern beantwortet vier Fragen:

1. Wer ist für die Bereitstellung der Informationen verantwortlich?
2. Welche Daten und Dokumente müssen vorliegen?
3. Wer prüft die Vollständigkeit und fachliche Qualität?
4. Wann gilt die Verantwortung als offiziell übernommen?

Für die Übergabe vom Vertrieb an die Projektleitung könnte das beispielsweise bedeuten: Der Vertrieb übermittelt einen freigegebenen Auftrag mit definiertem Leistungsumfang und vereinbarten Terminen. Die Projektleitung übernimmt den Vorgang erst, wenn die notwendigen Angaben vollständig sind. Fehlende Informationen werden an die verantwortliche Stelle zurückgegeben, anstatt stillschweigend ergänzt zu werden.

Diese Regeln können in vorhandenen Anwendungen durch Pflichtfelder, Statuswechsel und Freigabeschritte unterstützt werden. Entscheidend bleibt, dass die technische Umsetzung den tatsächlichen Arbeitsprozess widerspiegelt.

Hinzu kommt die organisatorische Seite. Wenn ein bisher führendes System durch eine gemeinsame Plattform ersetzt wird, verändern sich oft Rollen und Zuständigkeiten. Mitarbeitende müssen verstehen, welche Informationen sie weiterhin bearbeiten dürfen und welche Entscheidungen künftig an anderer Stelle getroffen werden.

Ohne diese Klärung entstehen leicht zusätzliche Schattenprozesse: persönliche Kontrolllisten, parallele Freigaben oder manuelle Rückfragen trotz bestehender Automatisierung.

Ein Übergabeprotokoll sollte deshalb mit den beteiligten Teams anhand realer Vorgänge getestet und bei Änderungen der Arbeitsabläufe angepasst werden. Es ist keine einmalige Formalität, sondern ein Instrument zur Sicherung des laufenden Betriebs.

Wählen Sie als nächsten Schritt einen häufig genutzten Kernprozess, dokumentieren Sie seine Tool-Wechsel und definieren Sie für jede kritische Übergabe eine verantwortliche Rolle und ein Abnahmekriterium. Erst danach sollte entschieden werden, welche zusätzliche Integration, Vereinfachung oder Systemablösung tatsächlich notwendig ist.