Ein Modul, drei Teams: sauber liefern im Enterprise-Projekt mit mehreren Anbietern

In einem großen Enterprise-Rollout baut niemand das Ganze. Das interne Team des Kunden verantwortet das Kernsystem. Ein anderer Anbieter verantwortet die Middleware. Ein drittes Team baut die Anwendung, die die Nutzer tatsächlich in der Hand haben. Jedes Team kann seinen Teil.

Solche Projekte scheitern selten daran, dass ein Team seinen Teil nicht bauen kann. Sie scheitern an den Rändern. Dort, wo die Annahme des einen Teams zur Nacharbeit des anderen wird. Die entscheidende Frage an einen Spezialanbieter lautet deshalb nicht: Können Sie das Modul bauen? Sie lautet: Können Sie es liefern, ohne den anderen beiden Teams Arbeit zu machen?

Wir haben mehrfach in genau dieser Rolle geliefert. Das braucht es dafür.

Die Grenze gehört zum Lieferumfang

Bei der Kiosk-App eines Schmuckherstellers war die Konstellation genau die von oben. Ein internes SAP-Team verwaltete die Backend-Daten. Ein bestehender Middleware-Anbieter übernahm die Synchronisation. Unser Umfang war die native iPad-Anwendung, ausgerollt auf über 500 Kioske in ganz Europa.

Dieser Umfang stand vor der ersten Zeile Code fest, und diese Klarheit war ein Vorteil. Alle wussten, was wir verantworten, was wir nutzen und was wir nie anfassen. Die SAP-Umgebung stand vom ersten Tag an in der letzten Kategorie.

Eine unklare Grenze ist die häufigste Ursache für Umfangskonflikte, die wir sehen. Keine böse Absicht. Nur drei Teams, die jeweils annehmen, eine Grauzone gehöre jemand anderem. Schreiben Sie die Grenze auf. Und behandeln Sie sie als Liefergegenstand, den alle drei Teams abgenommen haben, nicht als Zeile im Angebot.

Schnittstellen sind Verträge zwischen Teams, nicht nur zwischen Systemen

Eine Schnittstelle wird meist technisch beschrieben: Felder, Formate, Endpunkte. In einem Projekt mit mehreren Anbietern ist sie auch etwas Soziales. Sie ist die Vereinbarung, was der Middleware-Anbieter zu liefern verspricht und was wir zu verarbeiten versprechen.

Deshalb haben wir direkt mit dem Middleware-Anbieter gearbeitet, nicht über den Kunden als Zwischenstation. Die Integration war auf beiden Seiten dokumentiert, gegen abgestimmte Daten getestet und zuverlässig genug für 500 Geräte. Steht der Vertrag auf Papier, ist die Frage „Wessen Fehler ist das?“ in Minuten beantwortet statt in einem Meeting.

Das Kernsystem bleibt unangetastet

Die Versuchung in jedem Enterprise-Projekt ist, etwas weiter oben zu reparieren. Die Daten wären sauberer, wenn SAP dies täte. Die Synchronisation wäre schneller, wenn die Middleware jenes täte. Manchmal stimmt das sogar.

Widerstehen Sie, solange der Kunde nicht darum bittet. Das Kernsystem ist die Stelle, an der Änderungen am langsamsten, riskantesten und teuersten sind, und es gehört einem Team mit eigener Roadmap. Die Kiosk-App hat sich an die bestehende Middleware angebunden, ohne eine einzige Änderung am Backend. Für die Besucher-Compliance-App eines Herstellers haben wir eine eigene Middleware-Schicht gebaut, damit der neue iPad-Ablauf mit dem vorhandenen Besuchermanagementsystem zusammenarbeitet, statt es zu ersetzen.

Anpassungen auf der eigenen Seite der Grenze kosten Sie Aufwand. Änderungswünsche auf der anderen Seite kosten das ganze Projekt Zeit.

Full Lifecycle gilt auch für ein einzelnes Modul

Ein Modul zu verantworten heißt nicht, weniger von seinem Leben zu verantworten. Die Kiosk-App wurde für den Rollout im großen Maßstab ausgelegt und dafür, dass neue Standorte ohne nennenswerten Zusatzaufwand dazukommen. Die Compliance-App läuft an mehreren Standorten mit vollständigem Prüfpfad. Beide wurden für die Standorte gebaut, die nach dem Go-live kommen, nicht nur für den ersten Rollout.

Das bedeutet Full Lifecycle, wenn der Umfang ein Modul ist und kein System: Die Grenze ist schmal, aber die Verantwortung darin reicht vom Entwurf bis zu Jahren im Betrieb. Die eigenen Teams des Kunden müssen das Modul übernehmen können, falls sie es je müssen. Deshalb gehören Dokumentation und ein sauberes Deployment zur Arbeit, nicht zu den Extras.

Wenn Sie einen Anbieter für ein Modul dazuholen

Lassen Sie sich zeigen, statt sich erzählen zu lassen. Die schriftliche Grenze aus seinem letzten Projekt mit mehreren Anbietern, und was dort auf der Seite „fassen wir nie an“ stand. Das Schnittstellendokument, das er mit einem anderen Anbieter abgestimmt hat, und wen er angerufen hat, als sich etwas änderte. Wie er vor dem Integrationstag gegen die Teile der anderen Teams getestet hat. Wer in den ersten Monaten nach dem Go-live ans Telefon gegangen ist. Und was das eigene Team des Kunden am Ende erhalten hat, damit das Modul keine Blackbox in seiner Systemlandschaft wurde.

Wer Ihnen das zeigen kann, hat schon einmal in einem fremden Projekt gearbeitet. Wenn Sie ein Modul so geliefert brauchen, lesen Sie, wie wir mit Enterprise-Teams arbeiten, oder sprechen Sie mit uns.