Whiteboard-Session: Use-case-basierte Projektmethodik

Bewerten
3 Bewertungen,
Durchschnitt 5,0

In dieser Whiteboard-Session erklärt Florian Stolz, COO und Teamleiter Logistik bei der SALT Software GmbH, warum sich auch ein Software-Unternehmen wie die SALT Software GmbH intensiv mit der Projektmethode für die Einführung von Software bei Kunden auseinandersetzen muss. Das Ziel ist es nämlich nicht, dem Kunden fertige Features und Functions zur Verfügung zu stellen. Er soll auch in die Lage versetzt werden, einen Mehrwert in den entsprechenden Prozessen zu schaffen.

WHITEPAPER: Unzufriedene Kunden? So verbessern Sie Ihre Liefertreue.

Logistikleiter stehen vor großen Herausforderungen: Jeden Tag verlassen unterschiedlichste Waren das Lager und sollen schnellstmöglich beim Kunden ankommen, ohne dass die Kosten aus dem Ruder laufen oder Fehler passieren. Um das zu schaffen, müssen viele Unternehmen ihre Versandprozesse optimieren. In unserem Whitepaper erfahren Sie, welche Möglichkeiten es gibt, durch Automatisierung und Digitalisierung effiziente Versandprozesse zu schaffen – und damit zufriedenere Kunden.



Video-Transkription

Herzlich willkommen!

Schön, dass Sie sich für die use-case-basierte Projektmethodik der SALT Software GmbH interessieren. Die SALT Software GmbH entwickelt Produkte, um Produktions- und Logistikprozesse bei Unternehmen zu unterstützen. Wir selbst entwickeln die Produkte mit der Projektmethodik Scrum. Das heißt, dass wir uns mit Scrum einen Rahmen geben für die Abwicklung der Entwicklung, der Qualitätssicherung und auch der Auslieferung an unsere Kunden.

Heute wollen wir uns damit beschäftigen, wie wir diese Software bei Unternehmen einführen. Sie werden sich fragen: Warum muss ich mich als eine Software Company überhaupt mit dem Thema Projektmethodik für die Einführung von Software beschäftigen? Das liegt einfach daran, dass wir mit unserer Software einem Kunden nicht nur Features und Functions bereitstellen wollen, sondern den Mehrwert in den entsprechenden Prozess beim Kunden gewährleisten.

Das bedeutet für uns, dass wir uns mit den End-to-end-Prozessen unseres Kunden beschäftigen müssen: Wir müssen sogenannte Use Cases definieren. Wir müssen uns anschauen, welche Features oder ganze Funktionsketten bei unserem Kunden einen Mehrwert stiften und welche zum Einsatz kommen müssen, um ein Projekt und dann später auch den Produktivbetrieb zum Erfolg zu führen.

Genau deshalb werden wir immer wieder von unseren Kunden gefragt: Wie unterstützt Ihr uns bei der Einführung? Ein Kunde kauft nicht nur die Software und hat sie dann im Schrank liegen, sondern es ist immer das Projekt, das den Mehrwert stiftet. Dabei geht es nämlich darum, diese Funktionen dann auch im Prozess beim Kunden an der richtigen Stelle, mit der richtigen Funktion zu implementieren. Deswegen schauen wir uns an, welchen Scope ein Projekt hat, welches Budget ein solches Projekt braucht und wie wir das Ganze controllen können. Diese drei elementaren Bestandteile müssen wir immer im Blick haben, sonst würde kein Projekt zu einem Erfolg führen. Und dann bräuchte man auch keine Software kaufen, wenn sie nicht den gewünschten Mehrwert stiftet.

Projektmethode zwischen agil und Wasserfall

Wir schauen uns dazu zwei Extreme an: die rein agile Projektmethodik gegenüber einem Wasserfall. In der rein agilen Projektmethode arbeite ich erstmal auf einem weißen Blatt Papier. Um uns das zu veranschaulichen: Stellen wir uns vor, wir gehen in einen Supermarkt und wollen die Zutaten für ein Abendessen einkaufen. Wir haben keinen Einkaufszettel geschrieben. Wir gehen durch die Regale. Wir entscheiden uns: Fisch? Fleisch? Vielleicht Reis? Gemüse? Was wollen wir eigentlich zum Nachtisch essen? Wir werden unseren Einkaufswagen füllen. Wir werden ganz tolle Zutaten kaufen. Wir werden an der Kasse stehen und dann vielleicht feststellen: Gute Features, gute Functions, aber in Summe stiftet es nicht genau den Mehrwert: Es ist nicht genau das zusammenpassende Menü, das wir uns eigentlich wünschen. Und wir kriegen eine Rechnung, mit deren Budget wir vielleicht gar nicht gerechnet hätten.

Alternativ könnte man sich nun zuhause hinsetzen und könnte den Einkaufszettel ganz detailliert aufschreiben. Wir könnten sagen, woher der Fisch kommen soll, dass wir Basmatireis möchten, dass wir einen grünen Salat und ein Eis zum Nachtisch wollen. Dann können wir ganz genau spezifizieren, dass da noch heiße Himbeeren mit drauf müssen, und sind damit auf einmal in einem klassischen Wasserfallprojekt, in einem klassischen Pflichtenheft. Da sind alle Dinge ganz genau beschrieben. Wir gehen wieder durch den Supermarkt. Wir wissen genau, in welches Regal wir müssen. Wir greifen danach und stellen auf einmal fest: Basmatireis ist aus, das Gemüse hat keine Saison. Wir stehen also vor einem Change: Wir müssen zuhause anrufen, denn wir müssen uns abstimmen. Wir müssen das Budget prüfen und die Auswirkungen auf das Gesamtmenü. Alle sind frustriert. Wir kommen nach Hause. Beim Abendessen wird viel lieber darüber diskutiert, was wir eigentlich alles wollten und nicht bekommen haben, anstatt das gute Essen zu genießen.

Use-case-basiert durch Projekte

Die Frage, die sich nun stellt, ist: Wie finden wir einen Mittelweg? Wie können wir das Gute aus der Agilität und die Planungssicherheit und Struktur aus einem klassischen Wasserfall-Pflichtenheft-Prozess und -Projekt gewinnen? Die Antwort ist die use-case-basierte Projektmethode.

Was verstehen wir darunter? Wir wollen mit unseren Kunden über Use Cases sprechen: Welche Prozesse hat der Kunde? Welche Mehrwerte können denn unsere Produkte, unsere Product Suite, unsere Lösungen, die wir anbieten, an einem gewissen Punkt oder in einer Kette von benötigten Funktionen stiften?

Warum können wir das? Wir können das deshalb, weil wir Produkte haben, mit denen wir einen ganzen Katalog an Features und Functions haben, den wir entlang des Use Cases an genau der richtigen Stelle einbauen. Wir wissen natürlich, dass unsere Produkte nicht zu 100 Prozent auf den Prozess passgenau sind, weil die Prozesse unserer Kunden nicht zu 100 Prozent gleich sind. Deswegen haben wir an den richtigen Stellen die Möglichkeit geschaffen, agil zu sein, sich flexibel zu entscheiden.

Wir gehen also durch den Supermarkt mit der Einkaufsliste an groben Features entlang der Prozesskette, entlang der Mehrwertpunkte, die wir stiften möchten, und entscheiden uns dann, wenn wir vor dem Regal stehen, ob wir Variante A oder B möchten – oder vielleicht sogar beides! Aufgrund dieses Einkaufszettels und aufgrund dieses perfekten Mix zwischen den planbaren Bestandteilen und dieser Agilität haben wir immer die drei elementaren Bestandteile im Blick: Den Scopes als Use Case, das Budget aufgrund von den festen und den restlichen variablen Elementen und aufgrund einer organisierten, strukturierten Projektmethodik à la Scrum, eine Controlling- und Monitoring-Sicht auf den Abarbeitungsstand und auf das Budget. Nur so kann es aus unserer Sicht funktionieren.

Den Anwender bei Projekten im Blick behalten

Es gibt zusätzlich noch einen Erfolgsfaktor: den Anwender. Den Anwender sollten wir von Anfang an mit in den Prozess nehmen, denn er ist derjenige, der das, was das Projektteam definiert und die Dialoge, die wir designen, jeden Tag anwendet. Und wenn er mit am Tisch sitzt, dann haben wir alle Elemente beisammen, die wir brauchen, um den Use Case klar zu umreißen und auf den Punkt einzuführen. Das ist genauso wie bei Ihrem Abendessen: Sie überlegen sich auch: Wen laden Sie ein? Was hat er für Vorlieben? Was hat er für Allergien? Und danach designen wir unsere Zutaten für ein perfektes Abendessen, welches wir von der SALT Software GmbH Ihnen gerne zubereiten! Vielen Dank!

Keine Updates mehr verpassen: 1

Zurück