Wie vernetzen Sie Unternehmenssysteme, wenn jede Schnittstelle ein neues Risiko schafft?

Ein Auftrag wird im CRM erfasst, im ERP bearbeitet, über eine weitere Anwendung fakturiert und schliesslich an die Buchhaltung übergeben. Solange alle Verbindungen funktionieren, entsteht der Eindruck eines durchgängigen Prozesses. Doch sobald ein System sein Datenmodell ändert, eine API nicht mehr erreichbar ist oder eine Synchronisation fehlschlägt, zeigt sich, wie abhängig die Anwendungen voneinander geworden sind.

Die Herausforderung besteht nicht darin, möglichst viele Schnittstellen aufzubauen. Entscheidend ist, Unternehmenssysteme so zu vernetzen, dass Datenflüsse nachvollziehbar, Änderungen kontrollierbar und Fehler beherrschbar bleiben. Dafür benötigen IT-Verantwortliche eine Übersicht ihrer Systemlandschaft, klare Datenverträge, definierte Zuständigkeiten und eine Integrationstechnik, die zur vorhandenen Betriebskapazität passt.

Besonders in Schweizer Unternehmen mit gewachsenen ERP-Landschaften, Cloud-Diensten und lokalen Anwendungen muss die Architektur sowohl technische als auch datenschutzrechtliche Anforderungen berücksichtigen. Eine wartbare Integration beginnt deshalb lange vor der Auswahl einer API-Plattform: bei der Klärung, welche Daten tatsächlich wohin fliessen, wer sie verändern darf und welche Geschäftsprozesse von ihnen abhängen.

Wie kartieren Sie Ihre Systemlandschaft in 14 Tagen ohne Spezialsoftware?

Eine Systemlandschaft lässt sich ohne Spezialsoftware kartieren, indem Sie Anwendungen, Schnittstellen, Datenverantwortliche und tatsächliche Geschäftsabläufe systematisch erfassen. Ein 14-Tage-Plan bietet dafür einen praktikablen Rahmen: Zuerst inventarisieren Sie die Systeme, anschliessend verfolgen Sie reale Datenflüsse und bewerten die erkannten Abhängigkeiten. Ob dieser Zeitraum ausreicht, hängt von Umfang, Dokumentationsstand und Verfügbarkeit der Beteiligten ab.

Beginnen Sie nicht mit einem aufwendigen Architekturdiagramm. Eine Tabelle und Gespräche mit Systemverantwortlichen reichen aus, um die wichtigsten Zusammenhänge zu rekonstruieren. Entscheidend ist, dass Sie zwischen einer technisch vorhandenen Verbindung und einem tatsächlich genutzten Datenweg unterscheiden.

Ein möglicher Arbeitsplan verteilt die Untersuchung auf vier Etappen:

1. Tag 1–3: Anwendungen, Betreiber, Datenverantwortliche und vorhandene Schnittstellendokumentationen erfassen.
2. Tag 4–7: Datenübertragungen, Hintergrundjobs, manuelle Exporte und technische Abhängigkeiten dokumentieren.
3. Tag 8–11: Einen repräsentativen Geschäftsprozess vom Anfang bis zum Ende verfolgen und Abweichungen zwischen Dokumentation und Praxis festhalten.
4. Tag 12–14: Ergebnisse mit den Fachbereichen validieren, Risiken bewerten und offene Punkte verantwortlichen Personen zuordnen.

Für die Integrationsmatrix genügen zunächst wenige, konsequent gepflegte Spalten:

Ein konkreter Praxistest macht versteckte Abhängigkeiten erkennbar: Verfolgen Sie einen Kundenauftrag vom CRM über das ERP und die Rechnungsstellung bis zur Buchhaltung. Prüfen Sie dabei, ob Mitarbeitende Dateien exportieren, Daten manuell korrigieren oder Hintergrundjobs die Übertragung übernehmen.

Bewerten Sie anschliessend jede Verbindung auf zwei getrennten Achsen: geschäftliche Kritikalität bei einem Ausfall und technische Änderungsanfälligkeit. Eine selten angepasste Verbindung kann für den Geschäftsbetrieb kritisch sein, während eine häufig geänderte Schnittstelle nur einen unkritischen Bericht versorgt. Erst die kombinierte Betrachtung schafft eine belastbare Risikokarte.

Zur Sicherheitsinventarisierung gehört ausserdem die Erfassung aktiver API-Versionen und erreichbarer Endpunkte. Die OWASP API Security Top 10 von 2023 nennt unzureichendes API-Bestandsmanagement ausdrücklich als Sicherheitsrisiko.

Mit dieser Bestandsaufnahme lässt sich gezielt untersuchen, welche Anwendungen bei einem Update gemeinsam gefährdet sind. Genau dort beginnt die eigentliche Bewertung des Integrationsrisikos.

Warum können 12 Schnittstellen durch ein einziges System-Update instabil werden?

Ein einziges System-Update kann zwölf Schnittstellen beeinträchtigen, wenn mehrere Anwendungen dieselben Datenfelder, API-Versionen oder Authentifizierungsmechanismen verwenden. Ändert sich eine gemeinsam genutzte Grundlage, können die Auswirkungen über mehrere Verbindungen weitergegeben werden. Entscheidend ist dabei nicht die Zahl zwölf, sondern wie eng die Systeme gekoppelt sind und ob Änderungen rückwärtskompatibel bleiben.

Betrachten Sie ein hypothetisches Unternehmen, dessen ERP mit CRM, Lagerverwaltung, Rechnungsstellung, Kundenportal und weiteren Anwendungen verbunden ist. Insgesamt bestehen zwölf technische Verbindungen. Nach einem ERP-Update wird ein bisheriges Statusfeld durch mehrere neue Werte ersetzt.

Einige Integrationen melden sofort Fehler, weil sie die neuen Werte nicht verarbeiten können. Andere laufen technisch weiter, interpretieren den Status aber falsch. Dadurch können Aufträge als abgeschlossen gelten, obwohl noch eine Freigabe aussteht.

Eine erfolgreiche API-Antwort beweist nicht, dass der Geschäftsprozess korrekt verarbeitet wurde. Deshalb müssen zwei Aspekte getrennt überwacht werden:

• Technische Verfügbarkeit: Sind Endpunkte erreichbar, funktionieren Authentifizierung und Datenübertragung?
• Fachliche Datenkonsistenz: Stimmen Geschäftsstatus, Beträge, Identifikatoren und Verarbeitungsergebnisse zwischen den beteiligten Anwendungen überein?

Auch Änderungen an Ereignisschemata können mehrere Verbraucher gleichzeitig beeinträchtigen. Die Microsoft-Dokumentation zum Choreography Pattern beschreibt unter anderem Risiken durch geänderte Nachrichtenverträge, Mehrfachzustellungen und unterschiedliche Verarbeitungsreihenfolgen.

Vor einem produktiven ERP-Update empfiehlt sich deshalb ein begrenzter Stresstest in einer geeigneten Testumgebung. Prüfen Sie betroffene Datenverträge, Authentifizierung, kritische Geschäftsabläufe und mögliche Seiteneffekte. Dokumentieren Sie, welche Schnittstellen angepasst werden müssen, ob eine bisherige API-Version vorübergehend parallel betrieben werden kann und unter welchen Voraussetzungen ein Rollback tatsächlich möglich ist.

Die wirtschaftliche Auswirkung sollte entlang des Geschäftsprozesses bewertet werden. Fällt eine Verbindung für einen nachgelagerten Bericht aus, entsteht möglicherweise nur eine Verzögerung. Ist dagegen die Kundenidentität betroffen, können Auftragserfassung, Rechnungsstellung und Kundenservice gleichzeitig beeinträchtigt werden.

Selbst wenn alle Schnittstellen erreichbar bleiben, kann die Qualität der übertragenen Daten leiden. Besonders kritisch wird dies, wenn zwei Anwendungen dieselbe Kundeninformation unterschiedlich interpretieren.

Der Mapping-Fehler, der Kundendaten in 2 Systemen dauerhaft auseinanderlaufen lässt

Der häufig unterschätzte Mapping-Fehler besteht darin, ähnlich benannte Datenfelder aus CRM und ERP ohne Prüfung ihrer fachlichen Bedeutung gleichzusetzen. Ein CRM-Kontakt kann beispielsweise eine einzelne Ansprechperson beschreiben, während ein ERP-Debitor eine abrechnungsrelevante Kundenidentität repräsentiert. Werden beide Objekte ungeprüft synchronisiert, entstehen widersprüchliche Kundendaten, fehlerhafte Zuordnungen und wiederkehrende Korrekturen.

Die technische Verbindung kann dabei vollständig funktionieren. Das Problem liegt in der Semantik: Ein Feld mit dem Namen «Kunde» muss in zwei Anwendungen nicht dasselbe Geschäftsobjekt bezeichnen.

Bevor Sie Kundendaten übertragen, sollten die Fachbereiche die Zuordnung relevanter Informationen festlegen.

Diese Zuordnungen sind Beispiele und keine universell gültigen CRM- oder ERP-Regeln. Entscheidend ist, welches System für jedes Attribut eine Änderung verbindlich vorgeben darf.

Feldmapping und Datenhoheit sind zwei unterschiedliche Architekturentscheidungen. Das Mapping beschreibt, wie Daten übersetzt werden. Die Datenhoheit legt fest, wo gültige Werte entstehen und welche Anwendungen diese lediglich übernehmen.

Bei bidirektionaler Synchronisation kann ein Konflikt entstehen, wenn Mitarbeitende denselben Kunden nahezu gleichzeitig in beiden Anwendungen ändern. Die Regel «letzte Änderung gewinnt» ist problematisch, wenn Zeitstempel nicht vergleichbar sind oder fachliche Prioritäten fehlen. Dabei kann eine gültige Änderung unbemerkt überschrieben werden.

Eine belastbarere Lösung verwendet stabile Identifikatoren und attributbezogene Konfliktregeln. Beispielsweise kann das CRM für die Kontaktperson zuständig sein, während das ERP die Rechnungsadresse verwaltet. Nicht eindeutig entscheidbare Konflikte gelangen in eine dokumentierte manuelle Klärung.

Ergänzen Sie die Synchronisation um einen regelmässigen Datenabgleich. Vergleichen Sie Datensätze anhand ihrer stabilen Identifikatoren, erkennen Sie Dubletten und fehlende Zuordnungen und erfassen Sie Abweichungen mit Ursache, Verantwortlichkeit und Bearbeitungsstatus. Der Anteil ungeklärter Abweichungen kann als projektspezifischer Qualitätsindikator dienen, sofern Bezugsmenge und Messmethode konstant bleiben.

Sobald Bedeutung und Verantwortung der Daten feststehen, lassen sich daraus gemeinsame Integrationsregeln ableiten. Diese Regeln sollten auch bei der Einführung neuer Anwendungen gelten.

Wie definieren Sie 5 Integrationsstandards, damit neue Tools einfacher angebunden werden?

Fünf unternehmensinterne Integrationsstandards schaffen eine wiederverwendbare Grundlage für neue Anwendungen: API-Verträge und Versionierung, gemeinsame Datenmodelle, Authentifizierung und Berechtigungen, Fehlerbehandlung sowie Monitoring und Betriebsverantwortung. Damit wird die Integration neuer Tools planbarer. Vollständig automatisch funktioniert sie dennoch nicht, denn Datenlogik, Sicherheitsanforderungen und Ausnahmen müssen weiterhin geprüft werden.

Diese fünf Kategorien sind ein pragmatisches internes Regelwerk und keine allgemeingültige technische Norm. Ihr Nutzen besteht darin, dass neue Projekte nicht jedes Mal dieselben Architekturentscheidungen neu treffen müssen.

Bei der Softwareauswahl können diese Kriterien bereits in die Anbieterbewertung einfliessen. Fragen Sie nicht nur, ob eine Anwendung über eine API verfügt. Lassen Sie sich auch zeigen, wie Änderungen angekündigt werden, welche Authentifizierungsverfahren unterstützt werden, ob Fehler eindeutig erkennbar sind und welche Betriebsinformationen exportiert werden können.

Bei unterschiedlichen Datenmodellen kann eine Adapter-Schicht zusätzliche Stabilität schaffen. Sie übersetzt herstellerspezifische Datenformate in einen vereinbarten internen Vertrag. Nachgelagerte Anwendungen müssen dadurch nicht jede Änderung einer externen API unmittelbar übernehmen.

Die AWS-Dokumentation zum Anti-Corruption-Layer-Muster beschreibt diesen Ansatz als Vermittlung zwischen unterschiedlichen fachlichen Modellen. Gleichzeitig weist sie auf zusätzliche Anforderungen an Betrieb, Wartung, Fehlertoleranz und mögliche Latenzen hin.

Eine Adapter-Schicht lohnt sich daher besonders, wenn mehrere Anwendungen von derselben externen Schnittstelle abhängen oder sich herstellerspezifische Modelle häufig ändern. Bei einer einfachen, stabilen Einzelverbindung kann sie dagegen unnötige Komplexität erzeugen.

Ein neues Tool sollte erst dann als ausreichend integrierbar gelten, wenn ein realistischer End-to-End-Test bestanden wurde. Dazu gehören die korrekte Datenübertragung, eingeschränkte Berechtigungen, Datenqualitätsprüfungen, Wiederholungen nach Fehlern und ein benannter Betriebsverantwortlicher. Verbleibende Sonderanpassungen gehören ausdrücklich in die Dokumentation.

Die Standards legen fest, was eine Integration leisten muss. Welche Plattform oder Entwicklungsmethode diese Anforderungen wirtschaftlich erfüllt, ist eine separate Entscheidung.

iPaaS oder individuelle API: Was passt bei 6 Systemen und wenig Entwicklerkapazität?

Bei sechs Unternehmenssystemen und begrenzter Entwicklerkapazität kann eine iPaaS sinnvoll sein, wenn geeignete Standardkonnektoren existieren und die Integrationslogik überschaubar bleibt. Individuelle APIs bieten mehr Kontrolle bei besonderen Geschäftsregeln oder technischen Anforderungen. Die richtige Entscheidung hängt nicht von der Systemanzahl ab, sondern von Komplexität, Sicherheit, Änderungsfrequenz und verfügbarem Betriebspersonal.

Eine Integration Platform as a Service (iPaaS) stellt Funktionen bereit, mit denen Anwendungen, Datenflüsse und Schnittstellen über eine gemeinsame Plattform verbunden werden können. Das reduziert bestimmte Entwicklungsarbeiten, beseitigt aber weder fachliche Mapping-Probleme noch die Verantwortung für den laufenden Betrieb.

Für eine beispielhafte Landschaft aus CRM, ERP, Buchhaltung, Kundenportal, Marketing-Anwendung und Lagerverwaltung lohnt sich folgende Entscheidungsmatrix:

Die Gesamtkosten sollten über den gesamten Nutzungszeitraum betrachtet werden. Bei einer iPaaS gehören dazu Lizenzierung, Transaktionsvolumen, kostenpflichtige Konnektoren, Plattformadministration und Anpassungen. Bei individuellen APIs fallen Entwicklung, Tests, Dokumentation, Hosting, Monitoring und langfristige Wartung an. Für beide Varianten sind spätere Änderungen und ein möglicher Anbieterwechsel zu berücksichtigen.

Ein hybrides Integrationsmodell kann die sinnvollste dritte Option sein. Standardisierte SaaS-Prozesse können über eine iPaaS laufen, während zeitkritische oder stark individualisierte Kernprozesse über eigene APIs integriert werden. Voraussetzung ist, dass die Zuständigkeiten und Datenverträge über beide Ansätze hinweg konsistent bleiben.

Bevor eine Plattformentscheidung fällt, sollte ein Proof of Concept einen vollständigen Geschäftsprozess abbilden. Testen Sie nicht nur die erfolgreiche Übertragung, sondern unterbrechen Sie die Verbindung kontrolliert, erzeugen Sie doppelte Nachrichten und prüfen Sie die Rechteverwaltung. Anschliessend muss das tatsächlich verfügbare IT-Team einen simulierten Fehler diagnostizieren und beheben können.

Gerade bei wiederholter Nachrichtenübertragung ist eine idempotente Verarbeitung relevant: Dieselbe Nachricht darf bei erneuter Zustellung nicht unbeabsichtigt einen zweiten identischen Geschäftsvorgang erzeugen. Ob dies bereits durch die Plattform oder durch die angebundenen Anwendungen gewährleistet wird, muss praktisch nachgewiesen werden.

Sobald Anwendungen sowohl in der Cloud als auch lokal betrieben werden, erweitert sich diese Entscheidung um Netzwerkverfügbarkeit, Datenstandorte und mögliche grenzüberschreitende Zugriffe.

Wie bauen Sie hybride IT-Infrastruktur, wenn Daten teils in der Cloud und teils lokal bleiben müssen?

Eine hybride IT-Infrastruktur verbindet Cloud-Dienste und lokale Anwendungen über kontrollierte Netzwerke, Identitätsverwaltung und dokumentierte Datenflüsse. Welche Daten wo verarbeitet werden, sollte anhand ihrer Schutzanforderungen, vertraglichen Vorgaben und technischen Abhängigkeiten entschieden werden. Für Schweizer Unternehmen ist besonders wichtig, auch externe Dienstleister, Unterauftragsbearbeiter und mögliche Datenbekanntgaben ins Ausland in die Architekturprüfung einzubeziehen.

Die pauschale Regel «sensible Daten lokal, andere Daten in der Cloud» reicht als Architekturentscheidung nicht aus. Auch lokale Systeme können unzureichend geschützt sein, während Cloud-Dienste unterschiedliche Sicherheits- und Kontrollmöglichkeiten bieten. Die passende Lösung ergibt sich aus den konkreten Anforderungen.

Prüfen Sie für jede Anwendung, welche Daten sie verarbeitet, welche Personen und Dienstleister darauf zugreifen können und welche Schutzmassnahmen erforderlich sind. Neben internen Sicherheitsvorgaben können Kundenverträge, branchenspezifische Anforderungen und anwendbare Datenschutzvorschriften die Entscheidung beeinflussen.

Der Eidgenössische Datenschutz- und Öffentlichkeitsbeauftragte erläutert in seinen Informationen des EDÖB zum Cloud-Computing, dass Verantwortliche die datenschutzkonforme Bearbeitung ausgelagerter Personendaten sicherstellen müssen. Die Prüfung umfasst insbesondere Auftragsbearbeiter, Unterauftragsbearbeiter, Datensicherheit und gegebenenfalls die Voraussetzungen für Bekanntgaben von Personendaten ins Ausland.

Entscheidend ist dabei nicht nur, wo eine Datenbank gespeichert wird. Auch API-Gateways, Integrationsplattformen, temporäre Zwischenspeicher und administrative Supportzugriffe können Personendaten verarbeiten oder zugänglich machen.

Eine vollständige Datenflussprüfung unterscheidet deshalb:

• Speicherung: In welchen Systemen und Ländern werden Daten dauerhaft oder temporär abgelegt?
• Übertragung: Über welche Komponenten und Dienstleister werden sie ausgetauscht?
• Administrative Zugriffe: Welche internen oder externen Personen können die Daten aus welchen Ländern einsehen oder bearbeiten?
• Verantwortlichkeit: Wer beurteilt die Schutzanforderungen und kontrolliert die beteiligten Dienstleister?

Die technische Stabilität verdient dieselbe Aufmerksamkeit. Angenommen, ein Cloud-CRM übermittelt freigegebene Aufträge an ein lokales ERP. Fällt die Internetverbindung vorübergehend aus, muss geklärt sein, ob eingehende Aufträge zwischengespeichert werden können oder eine spätere Wiederholung notwendig ist.

Dabei sind die Reihenfolge der Verarbeitung, das Verhalten bei mehrfach zugestellten Nachrichten und der Wiederanlauf nach einer Unterbrechung zu definieren. Eine lokale Pufferung ist nur dann hilfreich, wenn sie ausreichend geschützt, überwacht und mit den Konsistenzanforderungen des Geschäftsprozesses vereinbar ist.

Für besonders kritische Prozesse sollte auch feststehen, wie Mitarbeitende eine Unterbrechung erkennen und welche Tätigkeiten vorübergehend manuell möglich bleiben. Die technische Wiederherstellung einer Verbindung bedeutet nicht automatisch, dass alle zwischenzeitlich offenen Aufträge korrekt nachverarbeitet wurden.

Diese Anforderungen lassen sich in einem überschaubaren Architekturentwurf zusammenführen. Dafür sind zunächst die wesentlichen Bausteine wichtiger als jedes einzelne technische Produkt.

Wie planen Sie eine hybride IT-Architektur in 5 Bausteinen, ohne sich in Details zu verlieren?

Eine hybride IT-Architektur lässt sich zunächst in fünf Bausteinen planen: System- und Datenstandorte, sichere Netzwerkverbindungen, Integrations- und API-Schicht, Identitäts- und Zugriffsverwaltung sowie zentraler Betrieb und Monitoring. Für den ersten Entwurf reichen die wichtigsten Datenwege, Verantwortlichkeiten und Risiken. Technische Details sollten erst vertieft werden, wenn sie Sicherheit, Betrieb oder Erweiterbarkeit wesentlich beeinflussen.

Der Zweck dieses Architektur-Minimums besteht darin, zentrale Entscheidungen früh sichtbar zu machen, ohne sich bereits auf sämtliche Produkte, Protokolle und Konfigurationen festzulegen.

Ein hypothetischer Auftragsprozess zeigt, wie die Bausteine zusammenspielen. Ein Cloud-CRM gibt einen Kundenauftrag frei. Die Integrationsschicht übernimmt die Nachricht über eine authentifizierte Verbindung, prüft das Format und übersetzt relevante Felder. Anschliessend übermittelt sie den Auftrag an ein lokales ERP, das eine weitere Anwendung versorgt.

Im Zielarchitekturdiagramm sollten drei Stellen ausdrücklich markiert sein: Wo erfolgt die Authentifizierung? Welche Komponente übernimmt die Datentransformation? Wo werden Übertragungsfehler erkannt und einem Geschäftsauftrag zugeordnet?

Für die Fehleranalyse ist eine durchgängige Korrelationskennung hilfreich. Sie ermöglicht es, denselben Vorgang über CRM, Integrationskomponente und ERP hinweg nachzuvollziehen, ohne sich ausschliesslich auf einzelne technische Fehlermeldungen zu verlassen.

Ebenso wichtig ist eine gemeinsame Betriebsverantwortung. Legen Sie fest, wer bei einem nicht abgeschlossenen Auftrag die erste Diagnose übernimmt, wer Zugriff auf relevante Protokolle besitzt und wann der Vorfall an einen Cloud-Anbieter oder einen externen IT-Dienstleister eskaliert wird.

Prüfen Sie den Entwurf anschliessend anhand von drei Veränderungen: Ein weiterer SaaS-Dienst wird eingeführt, ein bestehender Anbieter wird ersetzt und eine zentrale Infrastrukturkomponente fällt aus. Zeigt sich dabei, dass jede Änderung zahlreiche direkte Anpassungen erfordert, sollte die Kopplung der Anwendungen nochmals untersucht werden.

Eine Architektur ist nicht deshalb zukunftsfähig, weil sie viele Technologien enthält. Sie muss nachvollziehbar erweitertet, betrieben und im Fehlerfall wiederhergestellt werden können. Das kann auch bedeuten, bewusst auf zusätzliche Komponenten zu verzichten.

Ist diese Grundlage ausreichend belastbar, stellt sich die nächste Frage: Welcher Integrationsschritt schafft zuerst einen nachweisbaren geschäftlichen Nutzen?

Welche Systeme sollten Sie zuerst anbinden, damit der Nutzen nach 30 Tagen sichtbar ist?

Beginnen Sie mit den Systemen, deren Verbindung einen klar messbaren Geschäftsprozess verbessert und gleichzeitig ein beherrschbares Einführungsrisiko besitzt. Häufig eignet sich ein abgegrenzter Datenaustausch zwischen CRM und ERP als Pilot. Innerhalb von 30 Tagen lässt sich unter geeigneten Voraussetzungen prüfen, ob manuelle Arbeit, Übertragungsfehler oder Nachkorrekturen zurückgehen. Eine garantierte Implementierungsdauer ist dieser Zeitraum nicht.

Der erste Integrationsschritt sollte nicht automatisch den grössten Datenbestand oder die technisch anspruchsvollste Verbindung betreffen. Wichtiger ist das Verhältnis zwischen erwartetem Nutzen und Aufwand.

Bewerten Sie mögliche Vorhaben anhand einer einfachen Priorisierungsmatrix mit folgenden Kriterien:

• Geschäftsnutzen: Welcher konkrete Prozess wird schneller, zuverlässiger oder nachvollziehbarer?
• Manuelle Bearbeitungszeit: Welche wiederkehrenden Übertragungen und Kontrollen können entfallen?
• Fehlerfolgen: Welche Auswirkungen haben unvollständige oder falsche Daten?
• Umsetzungsaufwand: Wie gut sind Schnittstellen, Datenmodelle und Berechtigungen dokumentiert?
• Projektabhängigkeiten: Müssen andere Anwendungen, Freigaben oder Infrastrukturkomponenten zuerst angepasst werden?

Ein sinnvoller hypothetischer Pilot könnte die Übertragung freigegebener Kundenaufträge vom CRM in das ERP umfassen. Der Umfang bleibt bewusst begrenzt: Nur eindeutig definierte Aufträge werden übertragen, die Datenhoheit ist geklärt und die Fehlerbehandlung wird von Anfang an berücksichtigt.

Ein 30-Tage-Rahmen kann wie folgt aufgebaut werden:

1. Tag 1–7: Ausgangszustand messen, Datenfelder zuordnen und Erfolgskriterien festlegen.
2. Tag 8–18: Den begrenzten Integrationsfluss umsetzen und technische sowie fachliche Tests durchführen.
3. Tag 19–25: Den Prozess kontrolliert mit geeigneten realen Vorgängen erproben und Abweichungen dokumentieren.
4. Tag 26–30: Ergebnisse mit dem Ausgangszustand vergleichen, Betriebsfähigkeit beurteilen und über die nächste Ausbaustufe entscheiden.

Diese Etappen sind eine anpassbare Projektstruktur. Bei Legacy-Systemen, fehlenden Schnittstellen, komplexen Datenschutzprüfungen oder umfangreichen Freigabeprozessen kann der Zeitraum deutlich abweichen.

Vergleichen Sie insbesondere die Anzahl manueller Übertragungen, die Bearbeitungszeit pro Auftrag, fehlgeschlagene Synchronisationen und notwendige Nachkorrekturen. Verwenden Sie dafür vorab definierte Messmethoden und vergleichbare Vorgänge. Ein funktionierender API-Aufruf allein ist kein Nachweis für eine verbesserte Prozessleistung.

Nach dem Pilot sollte eine ausdrückliche Entscheidung über die Skalierung erfolgen. Prüfen Sie, ob sich die Datenqualität stabil verhält, Ausnahmen kontrolliert bearbeitet werden und Mitarbeitende den Prozess auch bei Störungen nachvollziehen können. Zudem ist zu untersuchen, ob neue technische Abhängigkeiten entstanden sind.

Wählen Sie als nächsten Schritt einen konkreten Auftrags- oder Stammdatenprozess, erfassen Sie dessen heutigen Aufwand und vereinbaren Sie einen begrenzten Integrationstest mit klaren Abnahmekriterien. Erst wenn der geschäftliche Nutzen und die Betriebsfähigkeit nachgewiesen sind, sollte dieser Ansatz auf weitere Unternehmenssysteme übertragen werden.