Reifegradmodell aus dem Governance-Workshop

[Andrea Urbschat]

Hey zusammen,

auf dem smapLand Festival sind wir in das Thema Governance tiefer eingestiegen. Wir haben erste Impulse gegeben, dann in zwei kleineren zunächst eine Fallstudie angeschaut und die 5 wichtigsten Punkte in einem Governance-Modell besprochen, Erfahrungen und Best Practices ausgetauscht.

Dort blieb ein Wunsch offen: die gezeigten Informationen zum 3-Zonen-Governance-Modell noch einmal nachlesen zu können und auch einen Detailblick in das von @Nina Dönhoff entworfene Reifegradmodell der Seifert Logistics Group zu zeigen. 

And here we are. 🙂 

 

Das 3-Zonen-Governance-Modell

Nicht jedes Unternehmen oder Digitalisierungsprojekt benötigt das gleiche Maß an Kontrolle: Während gerade komplexere Projekte mehr Aufmerksamkeit der IT erfordern, sollte man bei unkritischeren Bereichen darauf achten, Dynamiken nicht unnötig einzuschränken. Sehr hilfreich kann hier das Governance-Framework von Gartner sein. Es unterteilt Projekte in verschiedene „Ampel“-Zonen.

Es zeigt anhand der Farbcodierung, in welchen Bereichen frei ausprobiert und "herum gespielt" werden kann und in welchen Bereichen weitere Instanzen im Unternehmen relevant werden. Details zum 3-Zonen-Modell findet ihr auch noch einmal in diesem Blogbeitrag zum nachlesen. 

Die Herausforderung für Unternehmen ist es, nun genau diese Zonen zu definieren. Dabei ist eine Art Fragenkatalog hilfreich, der bspw. am Ende in solch eine Art Matrix führt. Den Fragen kann eine Likert-Skala zugeordnet werden und je höher das finale Scoring, desto kritischer die smap und ihre Inhalte.  Entsprechend sollte dann die IT und weitere Instanzen unterstützen um definierte Standards sicherzustellen und Datensicherheit/-Schutz zu gewährleisten. 

 

Das Reifegradmodell der Seifert Logistics Group

In diesem Zusammenhang hatte @Nina Dönhoff das aktuelle Reifegradmodell ihres Unternehmens vorgestellt, was in sieben aufeinander folgenden Phasen den Lebenszyklus einer smap abbildet. Ein solches Reifegradmodell beschreibt Abläufe (Prozesse) und hilfreiche Praktiken für eine Produktentwicklung innerhalb des Unternehmens, in diesem Fall die Entwicklung einer smap- von der Idee, über die Projektierung, das Prototyping, Testing und Freigabevorgehen bis hin zum Go Live und dem abschließenden Monitoring der smap. Sie bilden die Basis zur Beurteilung der Qualität von smap-Prozessen bei der Seifert Logistics Group und definieren Standards, die bspw. in allen smaps gleich sein sollen. 

In jeder Phase werden mittels Rechte- und Rollenkonzept Verantwortlichkeiten definiert und das Regelwerk hilft , keinen gemeinsam definierten Punkt zu vergessen. So beinhaltet dieses Regelwerk zum Beispiel in Phase vier "TESTING" eine (mit den Creatoren abgestimmte) Checkliste an Prüfpunkten, die erledigt werden müssen, bevor die smap in Phase fünf übergeben werden kann. Gleiches gilt auch für Phase 6, in der der Rollout je nach Art und Umfang der smap gestaltet wird. Zentrale Frage ist hier: wird es in einer Abteilung, einem Standort oder dem gesamten Unternehmen ausgerollt. Entsprechend einfach oder komplex fächert sich danach der Rollout-Plan auf. 

 

Wichtig ist hier, dass dieses Modell lediglich eine Orientierung darstellt. Da gibt es (leider) kein "one size fits all". Das muss jedes Unternehmen für sich selbst definieren. Manche Unternehmen nutzen mehr Phasen, andere weniger. Hier empfehlen wir wieder ein agiles Vorgehen: Standards definieren, Details mit Creatoren anschauen, ausprobieren, anpassen.. and again. 🙂 Probiert euch da wirklich aus. 

Wenn ihr Fragen habt an @Nina Dönhoff, @Thomas Schwarz oder mich, werft sie gern alle hier rein. Lasst uns gern wieder untereinander Erfahrungen teilen, so wie wir das letzte Woche auf dem SMLD Festival auch schon gemacht haben. 

Und wenn ihr Hilfe braucht beim Aufsetzen eines Governance-Konzepts, pingt mich gern an. Wir haben natürlich einige Erfahrungen mit Kunden und eine Art "Leitfaden" entworfen, den wir in einem Gespräch und/oder gemeinsamen Workshop erarbeiten können. 🙂 

 

[Bülent Erbas]

Vielen Dank @Andrea Urbschat Das ist wirklich sehr spannend!

Mir stellt sich hier direkt die Frage im Zusammenhang mit dem LifeCycle-Management wie mit Updates umgegangen wird?
Optimierungen können kleinere, aber auch größere, umfangreichere Veränderungen mit sich bringen, die ggf. erneut geprüft und bewertet werden müssten bevor man das Update wieder ausrollen kann. 
Sowie mit jeder anderen etablierten Lösung ja auch... 

Wie geht ihr damit um @Nina Dönhoff?
Welche Erfahrungen habt ihr gesammelt @Thomas Schwarz @Andrea Urbschat

Vielen Dank!

 

Bearbeitet 24. April von Bülent Erbas

[Andrea Urbschat]

vor 14 Minuten schrieb Bülent Erbas:

Vielen Dank @Andrea Urbschat Das ist wirklich sehr spannend!

Mir stellt sich hier direkt die Frage im Zusammenhang mit dem LifeCycle-Management wie mit Updates umgegangen wird?
Optimierungen können kleinere, aber auch größere, umfangreichere Veränderungen mit sich bringen, die ggf. erneut geprüft und bewertet werden müssten bevor man das Update wieder ausrollen kann. 
Sowie mit jeder anderen etablierten Lösung ja auch... 

Wie geht ihr damit um @Nina Dönhoff?
Welche Erfahrungen habt ihr gesammelt @Thomas Schwarz @Andrea Urbschat

Vielen Dank!

 

Nach meinem Verständnis müssten (wenn wir uns an Ninas Modell orientieren), Updates quasi in Phase 2 aufschlagen und die restlichen Phasen dann quasi verkürzt durchlaufen. Das Rechte-Rollenkonzept müsste dann auch definieren, wer für die Anpassungen, Testing und Rollout verantwortlich ist. 

Mal schauen, wie Nina das sieht. 😊

[Bülent Erbas]

vor 24 Minuten schrieb Andrea Urbschat:

Nach meinem Verständnis müssten (wenn wir uns an Ninas Modell orientieren), Updates quasi in Phase 2 aufschlagen

Das wäre auch mein Verständnis, evtl. sogar Phase 1 je nachdem wie gravierend die Veränderungen in die Governance eingreifen.
Es müsste quasi die selben Phasen wie bei einer Neuentwicklung durchlaufen, was meiner persönlichen Meinung nach, an Effizienz verlieren würde.

vor 27 Minuten schrieb Andrea Urbschat:

Mal schauen, wie Nina das sieht. 😊

Bin auch gespannt 😊

[Nina Dönhoff]

Hallo zusammen 🙂

@Bülent Erbas ja das ist in der Tat eine sehr gute und wichtige Fragestellung.
Wir lösen das generell so: Angenommen eine bereits existente Smap befindet sich im Monitoring und es wird Optimierungspotential festgestellt. Dann kommt es auf die Art der Optimierungslösung an, wie damit umgegangen wird. Kleine Anpassungen werden von einem Key-Account (wir haben Key-Accounts pro Bereich/Standort), welcher die Smap verwaltet, selbst vorgenommen. Soll um die Smap herum eine Automatisierung implementiert werden, gibt es je Komplexität definierte Prozedere mit zuständigen Rollen (für z.B. Umsetzung, Freigabe, Kommunikation, Schulung, Dokumentation..). Soll die Smap auf andere Bereiche ausgerollt werden, gibt es dafür ebenfalls ein definiertes Prozedere mit zuständigen Rollen. Dasselbe mit Backup-Prozessen, Dashboard-Erstellung etc.

Da bei uns der LowCode-Bereich direkt am Prozessmanagement hängt, sind wir sehr Prozess-fixiert. Die Kunst dabei ist, für uns als steuernde Abteilung die Prozesse genau zu definieren, es dem Citizen-Developer aber so einfach wie möglich zu machen, diese Prozesse zu triggern.

Wenn zunächst noch keine Prozesse oder Rollenverteilung für die spezifischen Smap-Anpassungs-Fälle bei Euch definiert sind, kann es zunächst helfen, zumindest eine zentrale Anlaufstelle zur Verfügung zu stellen und es von da aus erst einmal individuell zu steuern, sowie Regelmeetings mit Creatoren einzuführen um beidseitig über aktuelle oder zukünftige Änderungen informiert zu sein und zeitnah reagieren zu können.
Kommunikation ist alles 🙂

Hoffe ich konnte damit etwas helfen.

[Bülent Erbas]

Hallo @Nina Dönhoff

vielen Dank für die ausführlichen Informationen.

Tatsächlich wäre ich von der Logik auch so vorgegangen, da ich auch sehr gerne prozessorientiert agiere.

Und in der Tat ist genau da die Herausforderung Prozessvorgaben / "freiere Vorgehensweise" vernünftig auszubalancieren.
Wenn ihr das so umgesetzt habt - kann ich nur sagen: Respekt!

Aber nochmals vielen Dank - deine Ausführung hat mir weitergeholfen.

[Nina Dönhoff]

@Bülent Erbas kein Problem!
Am meisten hat uns dabei ein interner smapOne Workshop (mit @Andrea Urbschat) geholfen, in dem wir das "Wie" des Reifegrad-Konzepts (das "Regelwerk" des Reifegradmodells) mit allen Haupt-Creatoren aus unterschiedlichen Standorten gefüllt haben. Dort haben wir alle gemeinsam in unseren unterschiedlichen Rollen die Bottlenecks diskutiert. Also wo gewisse Regeln wichtig sind und warum, und wo aber weiterhin genug Freiheit gelassen werden muss, und warum. Es ging natürlich hitzig zu 😉 was gut war. Vor allem wurde verstanden, dass eine gewisse Einheitlichkeit ALLEN Beteiligten hilft, Übersicht zu behalten. Im Nachhinein haben wir gemeinsam eine Lösung geschaffen, mit denen alle dakor sind und deren Maßnahmen wir nun nach und nach umsetzen. Am Ziel sind wir noch lange nicht 🙂 

[Thomas Schwarz]

Danke,@Andrea Urbschat, für die Zusammenfassung und Danke an @Nina Dönhoff, dass wir das hier zeigen dürfen (und natürlich auch für die kompetente Unterstützung bei unserem Workshop)!

Ich ergänze noch mit dem Zonenmodell, das bei Shell (die das nun wirklich in extrem großem Maßstab ausgerollt haben), zum Einsatz kam:

(Quelle: Carroll, Noel & Maher, Mary. (2023). How Shell Fueled Digital Transformation by Establishing DIY Software Development. MIS Quarterly Executive. 22. 99-127. 10.17705/2msqe.00076.)

Auch wenn das vielleicht auf den ersten Blick etwas überkomplex wirkt, finde ich die einbezogenen Dimensionen recht spannend, vor allem:

• Externe Wirkung (intern, B2B/Partner/Subs, extern/Kunden/public)
• Komplexität
• Business Criticality
• Vertraulichkeit