Wie Changemanagement im AMS-Umfeld gelingt

Typische IT-Projekte laufen folgendermaßen ab: Nach der Budgetplanung werden der IST-Zustand sowie die gewünschten Prozesse beschrieben, umgesetzt und nach einer erfolgreichen Testphase live genommen. Doch erst im Realbetrieb fallen Punkte auf, die für die Anwender umständlich sind oder die sich in der Praxis statt linksherum doch eher rechtsherum bewähren. Oder der Button in einem Touch-Dialog soll in gewissen Fällen inaktiv sein, während ein anderer Button größer sein soll.

Das ist der Zeitpunkt, an dem das Changemanagement beginnen kann.

Unser Tipp: Priorisierung der Change-Wünsche

Es ist empfehlenswert, gemeinsam mit dem Kunden alle Change-Wünsche innerhalb eines Product Backlogs aufzunehmen und gemäß den agilen Methoden zu ordnen und zu priorisieren. Für die Priorisierung können diverse Fragestellungen relevant sein:

  • Ist der Änderungswunsch detailliert genug beschrieben?
  • Ist ein Testbeispiel vorhanden, das beschreibt, in welchem Fall sich was verändern soll?
  • Wie hoch ist der positive Impact eines Punktes auf den Produktivbetrieb?
  • Welche Punkte sind essentiell für einen reibungslosen Produktivbetrieb und welche sind „nice to have“?

Changemanagement im AMS-Umfeld

Sofern ein Supportvertrag vorliegt, übernehmen Kollegen aus dem AMS-Bereich schon während der Implementierungsphase Entwicklungs- und Testaufgaben und lernen so den Kunden und dessen Prozesse kennen. Nach Gesamtabnahme eines Projekts wird ein Kunde vollumfänglich durch einen AMS-Berater betreut und kann sein Product Backlog mit diesem abstimmen.

Entwicklungen werden im AMS-Umfeld im Sinne einer verlängerten Werkbank der Projektteams nach den agilen Prinzipien Scrum und Kanban umgesetzt. Doch wie betreibt man Scrum nicht nur für ein einzelnes Produkt bzw. einen Kunden, sondern für eine Vielzahl unterschiedlicher Entwicklungsanforderungen verschiedener Kunden in verschiedenen SAP-Modulen?

Die Lösung: User Stories

Dieser Frage sind wir nachgegangen und haben eine Organisation geschaffen, in der  durch zertifizierte Product Owner und Scrum Master in einem hoch agilen Umfeld diverse technische Anforderungen als User Stories verschiedener Stakeholder umgesetzt werden. Egal ob es sich um minimalste Anpassungen oder kleinere Projekte handelt.

Entwicklung und Beratung arbeiten eng zusammen. Die Kunden steuern durch ihre Product Backlogs und deren Priorisierung über die Kundenberater die detaillierten Anforderungen ein. Diese werden technisch geschätzt und bewertet, ggf. nachgestellt und in Sprints eingeplant.

Am Ende eines Sprints werden allen beteiligten Kunden die zugesicherten Ergebnisse, die als Sprintziel getestet wurden, zur Verfügung gestellt. Ein Sprint Review rundet den Sprint ab, und ein neuer Sprint kann beginnen.

 

 

 

 

 

Nach oben