Von Roger Kreier, Informatik KMU, Leiter Business Consulting bei OBT
Die Beschaffung eines ERP-Systems ist vergleichbar mit einem Hausbau: Der Bauherr entscheidet sich entweder für ein Fertighaus aus genormten Elementen, oder er lässt sich genau das Haus bauen, das seinen Anforderungen bis ins Detail entspricht. Die Voraussetzung dafür ist, dass der Architekt mit dem Auftraggeber Visionen und Ziele diskutiert, sie von Grund auf versteht und als Richtschnur für seine Planung verwendet.
Oft wird bei der Einführung neuer ERP-Systeme nach dem Wasserfallmodell vorgegangen: Der Kunde formuliert ein Pflichtenheft, der IT-Partner leitet daraus ein Konzept ab und stellt ein entsprechendes Hard- und Softwaresystem zusammen, das schliesslich implementiert wird.
Dabei kann ein wichtiger Faktor vergessen gehen: Zwar kann das System alles, was es laut den Anforderungen leisten muss, aber in vielen Fällen bildet es die Abläufe im Unternehmen nur mangelhaft ab. Denn das «Requirements Engineering» mit seinen Bullet-Point-Anforderungslisten ist weit komplexer als erwartet. Zudem wird die Tragweite der Entscheidungen, die daraus abgeleitet werden, vom Kunden gerne unterschätzt, und es drohen unerwartete Kostenfallen. So müssen beispielsweise eingespielte Prozesse mit grossem Aufwand an die ERP-Lösung angepasst werden (statt umgekehrt). Als Folge wird ein aufwendiges Change Management nötig, die Akzeptanz der User muss mühsam erarbeitet werden, und die Schulung gestaltet sich kosten- und zeitintensiv.
Den Kunden verstehen
Ein bewährtes Vorgehen, um diese Stolperfallen zu vermeiden, ist das Prinzip der Prozessorientierung. Dabei geht es als Erstes grundsätzlich darum, die Vision des Kunden zu verstehen und die Übersicht über das grosse Ganze zu gewinnen, um genau zu verstehen, was sein Business ist, wie er es betreibt und wie die internen Abläufe aussehen, wie das Geschäft heute funktioniert und was er in Zukunft verbessern und verändern möchte.
Für all das braucht es eingehende Gespräche mit Kunden durch einen Business Consultant. Thema sind dabei nicht vordergründig die Produkte (Systeme, Programme und Geräte) des Anbieters, sondern die Ideen und Ziele des Kunden. Wichtig ist es, diese Gespräche mit den richtigen Personen zu führen – in erster Linie mit den Entscheidungsträgern im Unternehmen.
Diese Gespräche gehen noch nicht tief ins Detail, sondern bleiben auf einem für alle nachvollziehbaren Diskussionsniveau. Sie sollen vor allem Verständnis für das Vorgehen wecken und die Möglichkeit bieten, wichtige Anliegen zu platzieren. Doch werden auch in dieser Phase bereits grundsätzliche Entscheide erzielt, die dann in einem Big Picture-Konzept mit den wichtigsten Eckdaten zusammengefasst werden. Die Business Consultants klären zudem die Machbarkeiten ab und holen Inputs und Ideen ein, um eine Projektvision zu erschaffen.
Als Resultat der gemeinsamen Arbeit erhält der Kunde eine übersichtliche, illustrative Projektdokumentation. Sie beschreibt die abgebildeten Unternehmensprozesse der Lösung verständlich und in seiner Sprache. Auf «Programmierer Slang» wird verzichtet. Das erleichtert es dem Kunden auch, Abweichungen von seinen Vorstellungen zu erkennen, Änderungswünsche anzubringen und auf einer soliden Wissens- und Verständnisgrundlage sein «Go» zu geben.
Verantwortungsträger und Fachspezialisten involvieren
In der nächsten Phase geht es in die Tiefe. Für weitere Workshops wird ein Gremium aus Verantwortungsträgern hinzugezogen, die für die Kernprozesse zuständig sind, also auf Kundenseite beispielsweise die Bereichsleiter von Produktion, Marketing/Verkauf, Finanzen, HR, Logistik und so weiter. Bei OBT kommen nun die Solution Consultants zum Zug, die Beratungs-Spezialisten für die verschiedenen Unternehmensbereiche.
Verfeinerung Schritt für Schritt
Basierend auf den Unternehmensprozessen aus dem Big Picture definieren die Solution Consultants mit dem Kunden die einzelnen Use Cases, also die praxisgetreuen Geschäftsfälle und Abläufe, die im System abzubilden sind. Anhand der Use Cases wird das Konzept verfeinert. Zusammen mit dem Kunden wird exakt formuliert, was er mit den Use Cases erreichen will.
Die Use Cases können sehr individuell sein; von Fall zu Fall wird entschieden, ob sie mit Standard- oder individuell angepasster Software abgedeckt werden sollen. Diese Use Cases werden durch die Fachspezialisten im System umgesetzt. In der Konzeption und Realisierung empfiehlt sich ein iteratives Vorgehen. Dazu werden die Use Cases sinnvoll gruppiert und nach Prioritäten konzipiert und umgesetzt. So können laufend in sich abgeschlossene Arbeitspakete an den Kunden ausgeliefert werden. Damit wird dem Prinzip des Minimal Viable Product (MVP) Rechnung getragen.
Die Use Cases können anschliessend durch den Kunden getestet und abgenommen werden. Das mühsame Formulieren von synthetischen Testfällen entfällt auf diese Weise ebenfalls, da die Use Cases gleich als Testfälle verwendet werden können.
Die Summe dieser Use Cases ist unter dem Strich auch die Summe der Prozesse: Sind alle Use Cases auf Programmebene realisiert, ist das ERP-System fertig und bildet alle Prozesse ab.
Die letzten zwei Jahre haben uns vor Augen geführt, dass sich während der Entwicklung eines neuen ERP-Systems die Welt weiterdreht. Plötzlich tauchen neue Herausforderungen auf, zum Beispiel mehr Remote-Arbeit mit Home-Office und virtuellen Sitzungen.
Hier sind die Vorteile des prozessorientierten Ansatzes eindrücklich zum Tragen gekommen: Dieser ermöglicht jederzeit eine schnelle, flexible Reaktion auch auf unerwartete neue Anforderungen.
Fazit
Von der prozessbasierten Vision in Kundensprache über die iterative Realisierung hin zur ERP-Lösung, die das Kundengeschäft optimal unterstützt: Das sind die Grundsätze des prozessorientierten Ansatzes. Sein Erfolg liegt im tiefen Verständnis für das Geschäft des Kunden sowie in der Fähigkeit, mit ihm in seiner Sprache zu kommunizieren und ihn in den Realisierungsprozess zu involvieren. (OBT/mc)