DAM Evangelist by Ulrich Leidl

ACHTUNG: Diesen Artikel jetzt als Podcast auf Apple Podcast hören:

DAM Evangelist by Ulrich Leidl

Die Stakeholder und ihre User Stories ist der erste Teil meiner dreiteiligen Reihe zur agilen Software Auswahl. In meinen folgenden Beiträgen möchte ich nun gerne auf die drei Phasen eingehen, die in diesem Prozess durchschritten werden. Da es sich bei meinem Blog nun ja um einen DAM (DAM – Was ist das?) Blog handelt, werde ich dies selbstverständlich anhand der Auswahl eines DAM Systems machen.
Der Start in diesen Auswahlprozess setzt voraus, dass bereits die Notwendigkeit erkannt wurde ein DAM System einzusetzen. In der Praxis ist dieser Teil, Firmen und Anwender zu überzeugen, dass sie ein DAM System benötigen, zwar häufig der Schwierigste, aber hier nehme ich diese Hürde als bereits genommen an.

Für viele Firmen ist es ein großer Schritt einen “griffigen” Einstieg in ein Softwareauswahlverfahren zu finden.

Wie soll vorgegangen werden?

Lädt man einfach die üblichen Verdächtigen ein, die man durch die erste Google Recherche findet (dadurch findet man die Anbieter, die gerne und viel für Google AdWords bezahlen, aber nicht unbedingt denjenigen der für mich am besten geeignet ist)?
Bedient man sich z.B. im Umfeld seines CRM/ ERP Partners (meistens SAP..), oder verfasst man gar ellenlange Anforderungslisten, die meist wenig sinnvoll sind?
Zielführend und effizient sind definitiv keine dieser Methoden!
Hersteller, oder zukünftige Partner wie Integratoren lädt man erst dann zu einer individuellen Demo ein, wenn man sich darüber im Klaren ist, welchen Weg man mit dem neuen System beschreiten will und welchen Kernnutzen man aus diesem ziehen will. Anforderungslisten zu erstellen sind wiederum ein reiner Zeitkiller, der ein Projekt unnötig verschleppt. Zudem beinhalten diese Listen meist Anforderungen wie “Es muss möglich sein, Dateien im Original zu laden.” Eine notwendige und wichtige Funktion, aber ein DAM, das dies nicht erfüllt ist auch kein DAM.

Aus meiner jahrelangen Praxis Erfahrung in der agilen Softwareentwicklung habe ich mich vor längerer Zeit dazu entschieden, Teile dieses Prozesses für die Auswahl eines DAM Systems zu adaptieren. Egal welche Branche und welche Anforderungen dieses Auswahlverfahren kann immer angewendet werden, es ist zielführend, wenig Zeit aufwändig und sehr schnell umgesetzt.

An erster Stelle dieses Prozesses steht die Auswahl der Stakeholder. Stakeholder sind Personen/ Anwender, die unmittelbar oder mittelbar vom Einsatz des DAM Systems profitieren wollen/ werden.

Auf Seite des zukünftigen DAM Kunden sollte es zudem eine Rolle geben, die ähnlich der des Product Owners im Scrum Prozess ist (Scrum Product Owner). Sinnvoll ist es den internen Product Owner mit einem externen Partner zu ergänzen, der über genügend Erfahrung in der Auswahl eines DAM Systems verfügt, der den DAM Markt hinreichend kennt, der die Einführung des Systems mit begleiten und bewerten kann und der vor allem auch Kenntnis über die “üblichen” Fallstricke eines solchen Prozesses hat.

Identifikation der Stakeholder:

Ein immens elementarer und wichtiger Punkt. Die Stakeholder werden später mit dem System arbeiten, oder wollen sehen, dass durch die Anwendung des Systems Zeit und Geld gespart werden kann. Diese Auswahl ist sehr sorgfältig zu treffen.

Hier steht auch zu Beginn die Frage:
Gibt es auch externe Stakeholder? Dies ist vor allem für Agenturen, oder Mediendienstleister wichtig, die das DAM gemeinsam mit ihren Kunden nutzen wollen, oder es gar als Hosting Lösung anbieten wollen. Vielfach stehen hier die Wünsche des (End-)Kunden im Fokus und hier gilt es dann möglichst bald die richtigen Personen zu adressieren.

Wenn die einzelnen, ich nenne sie mal Stakeholder Gruppen identifiziert sind, ist es wichtig diese bei der Erstellung ihrer User Stories mit ins Boot zu holen.
Einige Beispiele für gängige User Stories der Stakeholder beim DAM Auswahl Prozess können sie hier finden:
DAM Auswahlverfahren: Fünf typische User Stories, die sie kennen sollten!

Achtung bei Formulierung und Umsetzung der User Stories steckt der Teufel häufig im Detail:

Manch ein Product Owner glaubt sehr genau zu wissen, was seine Stakeholder für Anforderungen haben, leider ist dies aber nicht immer der Fall. Häufig unterscheiden sich Anforderungen auf den ersten Blick nur marginal, allerdings ist deren Umsetzung dann doch komplett verschieden. Die einzige Lösung für dieses Problem ist es, die Stakeholder mit ins Boot zu holen und mit ihnen gemeinsam die wichtigsten User Stories zu erarbeiten.

Grundsätzlich ist es im Prozess eines Auswahlverfahren nicht zwingend notwendig User Stories zu kreieren, die in Stein gemeißelt sein sollen (bei User Stories generell selten der Fall, da sie einer iterativen Entwicklung unterliegen), sie dienen vielmehr dazu die wichtigsten Stories der Stakeholder zu identifizieren und somit zum Einen das Auswahlverfahren zu beschleunigen und zum Anderen zukünftige Partner zu qualifizieren.
Der erste Schritt, Identifikation der Stakeholder, erarbeiten der User Stories mit den Stakeholdern gemeinsam ist der elementare Auftakt zur agilen Auswahl eines DAM Systems. Dieser Schritt muss unbedingt sorgfältig geplant und durchgeführt werden, da er die Basis für das gesamte Auswahlverfahren darstellen wird.
In meinem nächsten Beitrag werde ich mich um die Auswahl des richtigen Partners (Softwarehersteller und/ oder Integrator) für das anstehende Projekt beschäftigen!

Sie haben Fragen zum Auswahlverfahren allgemein, oder zu Schritt 1?

Nehmen Sie Kontakt mit mir auf, ich helfe ihnen gerne weiter: