Systeme konsolidieren

Eine typische Systemlandschaft im Mittelstand hat einen Shop, ein separates PIM, ein Suchprodukt, ein CMS, ein Middleware-Werkzeug für die ERP-Anbindung, ein BI-Tool für die Berichte, eine Handvoll Plugins und für jedes davon einen Wartungsvertrag. Jedes einzelne war am Tag des Kaufs eine vernünftige Entscheidung. Zusammen sind sie der Grund, warum eine Änderung an einem Produktattribut sechs Wochen dauert und vier Personen beschäftigt, die einander nicht unterstellt sind.

Warum das schwerer ist, als es klingt

Die Kosten einer zersplitterten Landschaft sitzen fast vollständig in den Nahtstellen, und keine Budgetzeile heißt „Nahtstellen". Lizenzen sind sichtbar und vergleichsweise klein. Unsichtbar ist, dass eine einzige Änderung (etwa ein neues filterbares Attribut) im PIM angelegt, in der Middleware zugeordnet, im Suchprodukt neu indexiert, im CMS in Templates eingebaut und dann über alle vier hinweg getestet werden muss, jedes mit eigenem Release-Kalender. Ein Business Case, der nur Lizenzersparnis zählt, unterschätzt den Nutzen und, unangenehmerweise, auch den Aufwand.

Die Fehlerart ist konkret und lohnt sich zu merken: Konsolidierung scheitert, wenn zwei Systeme weiterhin dasselbe Feld schreiben. Sie scheitert selten laut. Die neue Plattform und das Altsystem aktualisieren beide die Beschreibung, je nach Reihenfolge der Synchronisation gewinnt eines davon, und drei Monate lang kann niemand erklären, warum eine Beschreibung über Nacht zurückspringt. Die Datenhoheit muss pro Entität und, wo es darauf ankommt, pro Feld geklärt sein, bevor der erste Datensatz migriert wird.

Dann die Archäologie. Irgendwo in der Landschaft steckt ein Plugin, das 2018 ein inzwischen ausgeschiedener Entwickler geschrieben hat, das niemand erklären kann und von dem die Rechnungen abhängen. Es gibt einen geplanten Export, der das System eines Kunden füttert und in keiner Dokumentation auftaucht. Beides taucht in der Migration auf, und zwar als dringend. Planen Sie Zeit fürs Finden ein statt fürs Überraschtwerden.

Zwei weitere Bremsen, beide nicht technisch. Systeme haben Besitzer: Das Suchprodukt gehört dem Marketing, das PIM dem Produktmanagement, die Middleware der IT. Wer ein System entfernt, nimmt jemandem etwas aus dem Zuständigkeitsbereich. Und versunkene Kosten reden laut, wenn eine Plattform vor zwei Jahren mit Fünfjahresvertrag gekauft wurde. Keines der beiden Argumente ist unzulässig. Beide sind am Anfang offen besser aufgehoben als im vierten Monat als stiller Widerstand.

Die Hebel

Feststellen, was die Plattform bereits abdeckt

Einiges, was üblicherweise separat gekauft wird, ist Teil der Plattform, allen voran ein vollwertiges PIM statt einer dünnen Produkttabelle mit Beschreibungsfeld.

So sieht es gut aus: eine schriftliche Fähigkeitenkarte. Für jedes System, das Sie betreiben: was es tut und ob die Plattform es abdeckt, mit einem ehrlichen „Nein", wo die Antwort Nein ist.

Wovon es abhängt: davon, das gegen Ihre echten Anforderungen zu prüfen statt gegen eine Funktionsliste. Ein PIM-Vergleich entscheidet sich an Varianten, Referenzentitäten und kanalspezifischen Werten, genau dort, wo ein oberflächlicher Vergleich aufhört hinzusehen.

1. Wie Produktinformationsmanagement funktioniert
2. Das Katalog-Datenmodell
3. Wie Storefronts funktionieren
4. Tenants, Apps und Pakete
5. Apps und der Marketplace
6. Studios, wofür die einzelnen Teile der Plattform da sind

Datenhoheit klären, bevor Sie irgendetwas migrieren

So sieht es gut aus: eine Tabelle mit einer Zeile pro Entität (Produkte, Attribute, Preise, Bestand, Kunden, Bestellungen, Dokumente), die genau ein besitzendes System und eine Flussrichtung benennt. Wo zwei Systeme einen Wert halten müssen, steht in der Tabelle, welches gewinnt.

Wovon es abhängt: von einer Entscheidung, nicht von einer Analyse. Die Analyse ist meist an einem Vormittag erledigt; die Entscheidung dauert Wochen, weil sie Verantwortung zwischen Abteilungen neu verteilt.

1. Datenhoheit festlegen
2. Integrationsmuster
3. Feldzuordnung

Die Daten migrieren

Fast die ganze Arbeit ist die Vorbereitung der Dateien. Der Import selbst ist ein Nachmittag.

So sieht es gut aus: Sie modellieren zuerst die Zielstruktur, ordnen die Altfelder ausdrücklich zu, migrieren einen repräsentativen Ausschnitt, prüfen ihn gegen die Quelle und lassen erst dann den ganzen Bestand laufen.

Wovon es abhängt: vom entworfenen Ziel-Datenmodell. Wer eine Altstruktur unverändert importiert, reproduziert jeden Kompromiss, den das alte System erzwungen hat, und lebt jahrelang damit.

1. Datenmodell planen
2. Attribute und Attributgruppen
3. Importdatei vorbereiten
4. Produkte massenhaft importieren
5. Preise massenhaft importieren
6. Viele Produkte auf einmal bearbeiten

Sauber abschalten

Diesen Hebel lassen alle aus, und genau deshalb liefern so viele Konsolidierungsprogramme ein neues System und keine der versprochenen Einsparungen.

So sieht es gut aus: Das alte System wird an einem festen Datum abgeschaltet, seine Schnittstellen werden entfernt, sein Vertrag wird vor der Verlängerung gekündigt und seine Zugänge werden entzogen. „Läuft noch eine Weile lesend mit" ist die Variante, die nie endet.

1. Synchronisationen überwachen
2. Häufige Synchronisationsfehler
3. Sicherheit und Datenschutz
4. Abonnement und Abrechnung

Eine sinnvolle Reihenfolge

Phase 1: Inventur und Datenhoheitskarte. Listen Sie jedes System, jede Schnittstelle dazwischen, jeden Vertrag mit Verlängerungsdatum und jede Entität mit ihrem Besitzer. Diese Phase verändert keine Software und ist die wertvollste Woche des Programms: Hier finden Sie die Felder, die zwei Systeme schreiben, die Schnittstelle, von der niemand wusste, und den Vertrag, der sich in elf Wochen verlängert. Voraussetzung: Zugang und Ehrlichkeit, sonst nichts.

Phase 2: eine Domäne konsolidieren, vollständig. Fast immer zuerst die Produktdaten, weil alles andere davon abhängt und weil das PIM meist die klarste Überschneidung ist. Migrieren, das alte System für einen festgelegten, kurzen Zeitraum parallel laufen lassen, wobei das neue bereits maßgeblich ist, dann umschalten und abschalten. Eine vollständig abgeschlossene Domäne ist mehr wert als vier angefangene, und sie zeigt Ihnen, was die nächste kostet.

Phase 3: die nächste Domäne und die Nahtstellen. Inhalte, Suche, Berichtswesen und die eigene Middleware. Inzwischen ist die Datenhoheitskarte real und die Migrationsmechanik bekannt, sodass jede weitere Domäne günstiger wird als die vorige. Ersetzen Sie die selbst gebaute Middleware zuletzt durch konfigurierte Konnektoren, wenn Sie genau wissen, was sie tut. Dieses Wissen hat Phase 2 eingebracht.

Typische Fehler

• Migrieren, bevor die Datenhoheit entschieden ist. Zwei Systeme, die dasselbe Feld schreiben, sind der Fehler, der Monate Diagnose kostet und mit einem Wochenende Vorarbeit vermeidbar war.
• Big Bang über alle Domänen. Jede Abhängigkeit fällt gleichzeitig aus, und nichts lässt sich einzeln zurückrollen.
• Parallelbetrieb ohne Enddatum. Parallelbetrieb kostet mehr als jedes System allein, und solange das alte verfügbar ist, benutzt es jemand weiter.
• Auf etwas konsolidieren, das die Fähigkeit nicht abdeckt. Prüfen Sie die harten Teile (Varianten, kanalspezifische Werte, kundenspezifische Sortimente), bevor Sie etwas kündigen.
• Ein Business Case nur aus Lizenzen. Die größere Ersparnis sind Abstimmungskosten und Durchlaufzeit für Änderungen. Messen Sie beides vorher, sonst können Sie den Nutzen hinterher nicht belegen.
• Das alte System eingeschaltet lassen. Die Ersparnis entsteht am Kündigungsdatum, nicht am Go-live.

Woran Sie erkennen, dass es funktioniert

• Systeme im kritischen Pfad einer Bestellung. Zählen Sie: Wenn eines davon ausfällt und keine Bestellung mehr aufgegeben oder ausgeliefert werden kann, gehört es zum Pfad. Das ist die Kennzahl dieses Ziels.
• Aktive Schnittstellen, die Sie am Leben halten müssen, einzeln gezählt. Jede kann um drei Uhr nachts kaputtgehen.
• Felder, die mehr als ein System schreibt. Ziel: null. Jede andere Zahl ist ein angekündigter Vorfall.
• Durchlaufzeit einer Änderung an Produktdaten, von der Anfrage bis live. Messen Sie eine echte Änderung, bevor Sie anfangen. Das ist die Zahl, die das Unternehmen spürt.
• Gekündigte Verträge, mit Datum. Benennen Sie sie. Ein Konsolidierungsprogramm ohne gekündigte Verträge hat nichts konsolidiert.
• Vorfälle pro Quartal durch Synchronisation zwischen Systemen. Die Zahl sollte ungefähr mit der Schnittstellenzahl sinken. Tut sie das nicht, waren die entfernten Schnittstellen nicht die, die Ärger gemacht haben.

Verwandte Ziele

• Manuelle Arbeit reduzieren: weniger Nahtstellen heißt weniger Nacharbeit, aus derselben Ursache.
• Auf echten Zahlen entscheiden: widersprüchliche Zahlen sind meist ein Symptom der zersplitterten Landschaft.
• Einen digitalen Produktkatalog veröffentlichen: die Domäne, mit der die meisten Konsolidierungsprogramme anfangen sollten.

Was Sie bauen

ERP und Finanzbuchhaltung bleiben, wo sie sind. Die Plattform übernimmt das PIM, die Preise, die das ERP nicht besitzt, das Kundenmodell, den Bestellweg und die Storefront; das Integration Studio ersetzt die Middleware dazwischen. Das alte PIM, das CMS und die eigene Middleware werden an einem Datum abgeschaltet und ihre Verträge gekündigt. Alles, was weiterhin separat gekauft wird, steht mit Begründung auf der Liste.

flowchart LR
  ERP["Ihr ERP und die Finanzbuchhaltung"]
  subgraph IS["Integration Studio"]
    WF["Workflows und Importprofile"]
    RUN["Läufe und Überwachung"]
  end
  subgraph CS["Commerce Studio"]
    P["Produkte: das PIM"]
    PR["Preise"]
    C["Kunden"]
    O["Bestellungen"]
    INV["Bestand"]
  end
  subgraph XS["Experience Studio"]
    SF["Storefront und Seiten"]
  end
  subgraph OFF["Abgeschaltet, Verträge gekündigt"]
    LPIM["Altes PIM"]
    CMS["CMS"]
    MW["Eigene Middleware"]
  end
  ERP -- "Artikel, Konditionen, Bestand" --> WF
  WF --> P
  WF --> PR
  WF --> INV
  WF --> C
  P --> SF
  SF -- "Bestellung" --> O
  O --> WF
  WF -- "Bestellung" --> ERP
  WF --> RUN

Was Sie brauchen

• Eine Inventur jedes Systems, jeder Schnittstelle und jedes Vertragsverlängerungsdatums — Datenhoheit festlegen
• Eine Datenhoheitstabelle: ein besitzendes System pro Entität, und pro Feld, wo zwei Systeme einen Wert halten — Integrationsmuster
• Eine Fähigkeitenkarte, die ehrlich sagt, was die Plattform abdeckt und was bleibt — Tenants, Apps und Pakete
• Das Ziel-Datenmodell, entworfen bevor ein Altdatensatz geladen wird — Datenmodell planen
• Eine ausdrückliche Zuordnung jedes Altfelds zum neuen Modell — Feldzuordnung
• Einen datierten Abschaltplan pro System, abgestimmt mit dessen Besitzer — Abonnement und Abrechnung
• Eine Ausgangsbasis: eine echte Produktänderung, gemessen von Anfrage bis live, und die aktuelle Zahl der Schnittstellen — Die Kennzahlen, die im B2B zählen

So bauen Sie es

1. Listen Sie jedes System, jede Schnittstelle dazwischen und jeden Vertrag mit Verlängerungsdatum — Datenhoheit festlegen
2. Schreiben Sie die Datenhoheitstabelle pro Entität und, wo zwei Systeme einen Wert halten, pro Feld — Integrationsmuster
3. Schreiben Sie die Fähigkeitenkarte gegen Ihre echten Anforderungen: Varianten, kanalspezifische Werte, Kundensortimente — Wie Produktinformationsmanagement funktioniert
4. Entwerfen Sie das Ziel-Produktmodell, bevor Sie den Altexport anfassen — Datenmodell planen
5. Ordnen Sie jedes Altfeld ausdrücklich dem neuen Modell zu — Importdatei vorbereiten
6. Migrieren Sie einen repräsentativen Ausschnitt und prüfen Sie ihn Zeile für Zeile gegen die Quelle — Import
7. Lassen Sie den vollständigen Produktimport laufen, danach den Preisimport — Preise massenhaft importieren
8. Bauen Sie die ERP-Flüsse als Workflows und Importprofile nach und ersetzen Sie die Middleware-Routen eine nach der anderen — Ein System anbinden
9. Lassen Sie das alte System für einen festen, kurzen Zeitraum parallel laufen, mit der Plattform als maßgeblichem System — Synchronisationen überwachen
10. Schalten Sie die Storefront auf Katalog und Seiten der Plattform um — Eine Storefront anlegen
11. Schalten Sie das alte System ab, entfernen Sie seine Schnittstellen, entziehen Sie die Zugänge, kündigen Sie den Vertrag — Sicherheit und Datenschutz
12. Wiederholen Sie das für die nächste Domäne: Inhalte, Berichtswesen, dann die restliche Middleware — Einen Workflow bauen
13. Messen Sie Durchlaufzeit, Schnittstellenzahl und Felder mit mehreren Schreibern erneut gegen die Ausgangsbasis — Berichte und Exporte

Entscheidungen, die Sie treffen müssen

Verwandte Produktbereiche

• Commerce Studio: Produkte · Import · Familien · Attribute · Preislisten · Organisationen · Bestellungen
• Experience Studio: Sites · Seiten · Themes · Domains
• Integration Studio: Zugangsdaten · Workflows · Läufe · Import/Export · SFTP-Server