User Storys im ERP-Umfeld

Ich gebe zu: Es freut mich sehr, dass sich immer mehr Unternehmen dazu entscheiden, für die Entwicklung und Einführung ihrer Enterprise Software auf alternative Vorgehensmodelle zu setzen. Das klassische Fachkonzept, das in einer monatelangen Analyse- und Konzeptionsphase geschrieben wird, hat ausgedient. Für die Herausforderungen der Zukunft sind agile Geschäftsprozesse, die mit den Anforderungen mitwachsen, besser geeignet. Ein paar Feinheiten sollte man im ERP-Umfeld dennoch beachten – zum Beispiel beim Schreiben von User Storys. Der Unterschied zu anderen Kontexten ist nicht gravierend, aber doch eine Besonderheit, der man ein wenig Aufmerksamkeit widmen sollte.User Storys im ERP-Umfeld leiten sich in der Regel immer von den Geschäftsprozessen eines Unternehmens ab. Oft werden parallel zur Entwicklung und/oder Einführung einer neuen Enterprise Software auch diese Geschäftsprozesse fachlich und organisatorisch modelliert, was eine zusätzliche Herausforderung ist. Ich finde in diesem Zusammenhang das Konzept des Minimum Viable Products von Frank Robinson sehr hilfreich. Dabei soll ein Produkt geschaffen werden, das für den Markt akzeptabel genug ist, dass es verkauft werden könnte.Werden Geschäftsprozesse für eine Enterprise Software nach dem MVP-Konzept modelliert, bedeutet das: Die Prozesse sind gerade so ausgestaltet, dass sie von den Anwendern verwendet werden können. Diese minimale Prozessausprägung sollte zudem ...

• ... der Massengeschäftsfall (Standarddurchlauf gemäß der 80/20-Regel) sein.
• ... die Variante ohne „Abzweigung“ sein – also die kürzeste Prozesskette von Start bis Ende.

Ist dieser Prozess gefunden, kann er eins zu eins als User Story übernommen werden. Ist diese Story zu groß für einen Sprint, muss noch einmal geschnitten werden. Das kann auf unterschiedlichste Art und Weise erfolgen, mir persönlich gefallen besonders diese zwei Varianten:

1. Versuche, noch dünnere Prozessausprägungen zu schneiden, auch wenn diese kein sinnvolles MVP mehr ergeben.
2. Versuche, den Prozess in Teilprozesse zu gliedern, um jeden Teilprozess in weiterer Folge als User Story aufzunehmen.

Variante 1

Für die erste Variante kann es sich anbieten, das Verb der User Story genauer zu untersuchen. Möglicherweise kann es weiter konkretisiert werden. Sehen wir es uns an einem Beispiel zur Auftragssteuerung für regionale Einheiten oder externe Dienstleister an. Die ursprüngliche User Story könnte in etwa so lauten:

„Als Vertriebsmitarbeiter möchte ich meine Aufträge steuern, um jederzeit Kontrolle über diese zu haben."

Das Wort „steuern“ ist in diesem Beispiel bewusst gewählt, um zu zeigen, dass es weiter konkretisiert werden kann:

• „Als Vertriebsmitarbeiter möchte ich neue Aufträge anlegen, um alle Informationen über den Kundenwunsch abzuspeichern und jederzeit verfügbar zu machen."
• „Als Vertriebsmitarbeiter möchte ich bestehende Aufträge an regionale Einheiten zuweisen, um eine Bearbeitung der Aufträge zu initiieren."
• „Als Vertriebsmitarbeiter möchte ich bereits zugewiesene Aufträge einer anderen regionalen Einheit neu zuweisen, um Auslastungsspitzen nivellieren zu können."
• „Als Vertriebsmitarbeiter möchte ich bereits zugewiesene Aufträge wieder stornieren, um einem Stornierungswunsch des Kunden Folge zu leisten."

In diesem Fall haben wir die User Story nun weiter detailliert. In vielen Fällen handelt es sich jedoch nicht um solch triviale Beispiele, sodass kleinere User Storys durchaus kein sinnvolles MVP ergeben können. Nichtsdestotrotz kann ich diesen Ansatz empfehlen.

Variante 2

Bei Variante 2 wird eine Story Map (Idee von Jeff Patton) erstellt. Dazu können Hauptgeschäftsprozesse in Prozesse und diese in weiterer Folge in Teilprozesse gegliedert werden. Der Geschäftsprozess „Einkauf“ kann beispielsweise in folgende Teilprozesse untergliedert werden:

• Anlegen eines neuen Lieferanten
• Anlegen einer Bestellung inkl. Freigabeprozess
• Auslösen der Bestellung
• Eingang der Bestellung
• Eingang der Rechnung inkl. Prüfungsprozess
• Auslösen der Bezahlung

Für jeden dieser Teilprozesse kann nun eine User Story formuliert werden. Auch der Tipp aus Variante 1 bietet sich hier wieder an. So kann es in einem ersten Schritt durchaus gewollt sein, dass ...

• ... neue Lieferanten nur angelegt, aber nicht weiter editiert werden können.
• ... Freigabe- und Prüfungsprozesse nur positiv ausgesteuert werden können.
• ... eingehende Bestellungen nicht per System reklamiert werden können.

Es sind nur kleine Kniffe. Aber sie helfen manchmal sehr dabei, auch bei der Modellierung und Abbildung von Geschäftsprozessen auf die agilen Grundsätze wie eine End-to-End-Betrachtung von User Storys und den Fokus auf das „Minimum Viable Product“ zu vertrauen.