Das Delivery-Modell
Vorgehen
Jeder Workstream durchläuft denselben Zyklus. Die Struktur ist bewusst langweilig, denn das Interessante soll Dein Geschäft sein, nicht unser Prozess.
Vier Phasen, je Workstream
-
Die echte Lage verstehen, das Ziel festlegen, und einen Plan liefern, den Du finanzieren kannst.
- Ist-Assessment über Produkt, Prozesse, technische Architektur und Team
- Zielbild und Anforderungen
- Toolauswahl mit TCO-Vergleich über fünf Jahre, Proof of Concept, wenn die Entscheidung knapp ist
- Machbarkeitsprüfungen an den Stellen, die am ehesten brechen
- Ein sequenzierter, kalkulierter Transformationsplan
-
Auf die vereinbarte Architektur zubauen, Release für Release, beginnend dort, wo es am meisten weh tut.
- Detaildesign: Prozesse, Anforderungen, Migrationsplan, System- und Integrationsdesign
- Iterativer Aufbau bis zu einer funktionierenden v1, niemals Big Bang
- Der schmerzhafteste Workstream zuerst
- Time and Materials mit gemischtem Team
-
In jedem Markt in den Livebetrieb bringen, mit den Menschen, die damit arbeiten müssen.
- Schulung und Change Management
- v1 zuerst in einen kleineren Markt, danach Wellen-Rollout über Märkte und Kanäle
- Support und Betrieb
- Weiterentwicklung entlang der Roadmap
-
Ein Team hinterlassen, das es ohne uns betreibt, und eine Run-Rate, die auf null geht.
- Wissens- und Verantwortungsübergabe
- Befähigung und Dokumentation: Runbooks, Architekturdokumentation
- Integration in Dein Team
- Sauberer Eigenbetrieb und Ausstieg, optional mit Support-Retainer
Workstreams (Shop, OMS, ERP, Daten) sind modular und einzeln wählbar. Sie starten versetzt, etwa im Monatsabstand, damit Senior-Kapazität sauber ausgelastet bleibt und kein einzelner Cutover das gesamte Programmrisiko trägt.
Delivery-Prinzipien
Vier Regeln, von denen wir nicht abweichen.
Das ganze Zielbild planen. In Teilen liefern.
Die finale Architektur wird vorab entschieden und nie lokal optimiert. Dann bauen wir Release für Release darauf zu, mit Tempo. Das ist kein Widerspruch. Das Erste wegzulassen ist genau das, was das Zweite teuer macht.
Der schmerzhafteste Workstream zuerst.
Nicht der einfachste, und nicht der mit dem willigsten Stakeholder. Frühe Glaubwürdigkeit entsteht dadurch, dass etwas besser wird, das Leute tatsächlich spüren.
Niemals ein Big Bang.
v1 geht in einem Markt live, der klein genug ist, um eine schlechte Woche zu verkraften, und echt genug, um das Modell zu beweisen. Danach Wellen.
Der Plan enthält sein eigenes Ende.
Die Übergabe ist eine Phase mit Datum und Umfang, keine Geste zum Schluss. Unsere Run-Rate sinkt nach einem Plan, der vor dem Start vereinbart wurde.
Verantwortung
Drei Positionen. Nie zusammengelegt.
Den meisten Programmen, die driften, fehlt es nicht an Aufwand. Ihnen fehlt eine klare Antwort darauf, wer entscheidet.
- 01
Sponsor
Bei Dir, senior, in Teilzeit, aber wirklich präsentVerantwortet Ergebnis und Budget, setzt Prioritäten, wenn sie kollidieren, und ist die finale Freigabe. Diese Position lässt sich nicht auslagern, auch nicht an uns. Eine benannte Führungskraft aus dem Geschäft funktioniert hier besser als eine Person aus der IT-Funktion, weil die schwierigen Entscheidungen meistens kommerziell sind.
- 02
Delivery-Leitung
Eine Person, nahezu VollzeitDer einzige Treiber von Plan und Umsetzung. Es gibt genau eine. Am Anfang ist das in der Regel unsere. Du benennst eine Co-Leitung auf Deiner Seite, die von Tag eins eingebunden ist und die Position zu einem definierten Zeitpunkt übernimmt, während wir auf Unterstützung und Coaching zurückgehen.
- 03
Delivery-Team
Gemischt, unsere Leute und DeineArchitektur, Engineering, Produktmanagement und Change von unserer Seite, zusammen mit Deinen Domänen- und Product Ownern. Spezialisten kommen dazu, wenn ihr Workstream startet, und gehen wieder, wenn er sie nicht mehr braucht.
Entscheidungsrechte: Die Delivery-Leitung treibt, der Sponsor gibt frei. Ein Treiber, eine Freigabe, keine geteilte Verantwortung.
Teammodell
Gemischt ist die Empfehlung. Komplett extern gibt es, und es ist schlechter.
Im gemischten Team besetzen wir die Delivery-Leitung und die zentralen Engineering-Positionen, und Deine Leute übernehmen dort, wo Kapazität und Domänenwissen schon vorhanden sind. Das kostet weniger als ein komplett externes Programm. Wichtiger noch: Es ist die einzige Struktur, die verlässlich mit einem Team endet, das das Ergebnis betreiben kann. Verantwortung lässt sich nicht im letzten Monat übergeben. Sie muss währenddessen aufgebaut werden.
Optional: Dein Team aufbauen, während wir liefern
Manche Kunden nutzen das Programmfenster, um das interne Team aufzubauen, das es später erbt. Wir können die externe Schlagkraft jetzt liefern und parallel Deine eigenen Leute rekrutieren, einarbeiten und weiterqualifizieren, mit so viel oder so wenig Recruiting-Beteiligung, wie Du möchtest.
Was die Zahl treibt
Vier Dinge entscheiden, was das kostet.
Wir klären alle vier im Discovery, denn eine Schätzung ohne sie ist eine Vermutung mit Nachkommastelle.
- 01
Wie tief die Systeme miteinander verdrahtet sind
Der Entkopplungsaufwand ist in einem Replatforming-Programm meist die größte und am stärksten unterschätzte Position.
- 02
Wie viel Prozess neu gedacht werden muss
Einen kaputten Prozess in ein neues System zu heben erzeugt einen teureren kaputten Prozess.
- 03
Wie viel das Team dazulernen muss
Eine Plattform, die niemand bedienen kann, ist keine gelieferte Plattform.
- 04
Was komplett fehlt
Die Komponenten, die noch niemand gezählt hat, ein CMS, ein PIM, eine Datenebene, tauchen erfahrungsgemäß in Woche drei auf.
Starte mit sechs Wochen.
Ein Discovery liefert Dir eine Zielarchitektur, einen kalkulierten und sequenzierten Plan und eine Empfehlung, die Du vor Deinem Board vertreten kannst. Wenn die Antwort lautet, dass Du das Programm nicht machen solltest, bekommst Du auch diese Antwort.
Oder schreib an hi@colayer.io