Ich habe eine Liste aus vergangenen Aufträgen und generelle Best (in diesem Fall ‚Worst‘) Practices zusammengefasst, in der Hoffnung, dass es Euch teure Fehler erspart:
1) Menschen mit der Automatisierung beauftragen, welche die Anforderungen nicht sehr gut kennen oder wenig Kontakt zur Nutzergruppe haben.
Die in anderen Bereichen verbreiteten Methode „Y, du machst das jetzt, hier ist das Budget“, funktioniert bei der Prozessautomatisierung nicht sonderlich gut. Die beauftragte Person ist nunmehr Product Manager, ist sich deren Rolle gar nicht richtig bewusst. Das Ergebnis: Unklare Anforderungen, Missverständnisse in der Kommunikation, teure nachträglichen Anpassungen – Einfach gesagt: Es wird sehr teuer.
2) Falsches Verständnis von Methodik, beispielsweise Agile
Salopp formuliert: Software-Leute haben viel mehr Erfahrung mit Agile, Produkt- und Prozess-Leute nicht. Setzt bitte nicht voraus, dass das gleiche Verständnis da ist wenn die Entwicklung losgeht. Im Zweifelsfall nutzt eine iterative, aber klassische Methode, die allen vertraut ist.
3) Anforderungen nur oberflächlich aufnehmen
Der bekannte Spruch „Die wissen nicht was sie wollen!“ – Gewissermaßen der Klagespruch aller ITler – hat ein Körnchen Wahrheit. Tatsächlich gibt es viele Anforderungen, die erwartet werden d.h. für Anforderern so selbstverständlich, dass diese sie überhaupt nicht erwähnen, sind jedoch enttäuscht wenn sie nicht anwesend sind (Basisanforderungen im Kano-Modell). Oft ist Anforderern erst dann klar wie genau die Automatisierung läuft sobald der Dialog mit der IT anfängt. Auch die Umsetzungsseite soll sich dessen bewusst sein und ausreichend Zeit für die Anforderungserhebung und Klärung einplanen. Spezialfall: Wenn Anforderer = Umsetzer sollen Methoden und Tools von der Organisation bereitgestellt werden. Diese sind nicht allgemein oder nur grob bekannt und es erspart auch dort lange und teure Lernkurven.
4) Für den Prozess gibt es doch schon ein Tool (Webshop, CRM-System etc.)
Ist Dein Prozess zu 99,5% identisch mit dem anderer Organisationen? Ist es ein Spezialprozess das sich prinzipiell nur darin unterscheidet, dass andere Daten aus vorhandenen Systemen ausgelesen werden? Dann hilft ein Tool – vermutlich. In anderen Fällen wächst der Preis der Toolanpassung pro 1% Unterschied mit jedem weiteren 1%. Bei „nur“ 80% kann es sein, dass bereits mittlere 6-Stellige Beträge für die Anpassung anfallen. Auch die digitale Souveränität soll hier nicht außer Acht gelassen werden
5) Die Ansprechpartner – falls extern vergeben – haben keine Entwicklungserfahrung
Je weniger Personen zwischen Nutzer und Umsetzer vermitteln desto besser. Jede weitere Schnittstelle birgt – aufgrund von Zeitprobleme, fehlende Erfahrung oder die falsche Art von Erfahrung – das Risiko, eine unpassende Automatisierung zu entwickeln. Deshalb um lange Klärungsgespräche zu vermeiden, soll der passende Skillset ausgesucht werden. In Extremfällen können spezialisierte Beraterteams die Anforderungen aufnehmen und korrekt an die umsetzende Organisationseinheit übermitteln. In den meisten Fällen jedoch ist das übertrieben. Aus meiner Sicht und bisherige Erfahrung: Wer Anforderungen aufnimmt und dokumentiert soll mind. 1 Jahr Entwicklungserfahrung haben. Auch als Junior-Entwickler, idealerweise auch Testing-Erfahrung. So lassen sich wenn nicht alle, so doch einen Großteil der Missverständnisse vermeiden.