Prozessmodellierung: Auf grüner Wiese beginnen?

01. November 2013

ERP-Projekte haben immer auch mit den geschäftlichen Abläufen zu tun. Soll die entsprechende Geschäftsprozessanalyse und –optimierung anhand vorgefertigter Beispiele erfolgen, oder ist die Benutzerakzeptanz höher, wenn man das nicht tut?

 

Geschäftsprozesse im ERP-Projekt

Zu Beginn eines ERP-Projektes zunächst die Geschäftsprozesse zu betrachten, halte ich für sehr sinnvoll (warum die Prozesse sich im Projekt nicht automatisch optimieren, kann man hier nachlesen). Dazu kann man einen externen Prozessberater hinzuziehen oder sogar den ERP-Anbieter selbst bitten, vor den ERP-Workshops zunächst eine Prozessanalyse durchzuführen.

Hier beschäftigt mich die Frage: Startet man mit vorgefertigten Beispielprozessen, oder beginnt man besser auf der „grünen Wiese“ (bzw. dem blanken Whiteboard) loszumodellieren?
Wie immer sind die Meinungen dazu geteilt.

Vielfalt im Standard

Ich kenne einen ERP-Partner, der mit Microsoft Dynamics Produkten unterwegs ist und mit seinen Zusatzmodulen hauptsächlich Kunden aus dem zertifizierten Umfeld der Pharmaherstellung bedient. Er hat alle durch die Zertifizierung vorgegebenen Geschäftsvorfälle durchdefiniert und als Prozesse im Detail beschrieben, und er demonstriert damit sehr erfolgreich seine Fachkompetenz in der Branche. Seine Software-Lösung passt auf diese Prozesse ganz genau. Dahinter steckt natürlich eine umfangreiche Vorarbeit und ein großer Aktualisierungsaufwand – aber für diesen speziellen Anbieter hat sich das gelohnt.

Für andere Branchen, wo die Vielfalt der Geschäftsprozesse – mangels normativer Vorgaben – ungleich größer ist, ist auch der Aufwand noch um ein Mehrfaches höher. Ich war selbst mal in einem Team, das für eine ERP-Lösung aus der Medizinprodukte-Branche alle möglichen Geschäftsvorfälle ausmodellieren wollte. Obwohl auch bei der Rezeptabrechnung  die Krankenkassen bestimmte Abläufe fest vorgeben, hat das nicht mehr funktioniert: Es gab hier schon für die einfachsten Abläufe so viele Varianten, die die ERP-Lösung auch ohne kundenindividuelle Programmierung bereits unterstützt hätte, dass wir vor lauter „Wenn/Dann“-Verzweigungen im Prozessschaubild sehr schnell kein Land mehr gesehen haben.

Ein einfaches Beispiel: Soll die Eingangsrechnung eines Lieferanten im Einkauf oder in der FiBU gebucht werden? Beides ist möglich und wird von den meisten ERP-Systemen ohne weiteres unterstützt, aber die entsprechenden Verantwortlichkeiten und  Prozess-Schaubilder sehen ganz unterschiedlich aus.

Identifikationsbremse „Beispielunternehmen“

Ein Ausweg wäre gewesen, ein Beispielunternehmen zu erfinden, sich dort für bestimmte Möglichkeiten der Vorgehensweise zu entscheiden, für dieses fiktive Unternehmen die individuellen Prozessdiagramme zu zeichnen und eine dazu passende ERP-Demolösung zu konfigurieren. Aber kann ich damit zum Kunden gehen? Wird er sich damit identifizieren? Wird er das honorieren und diesen Aufwand (indirekt) mitbezahlen wollen? Ich denke: Nein.

Ein guter Verkäufer macht sich die Mühe, bei seinem Interessenten ein paar Rahmendaten abzufragen, Lieferanten, Artikel und Kunden, und damit eine Demonstrationsversion seines ERP-Produkts zu füttern: Höherer Wiedererkennungswert bedeutet höhere Akzeptanz.

Akzeptanz ist das Schlüsselwort

Bei Prozessschaubildern schafft der ERP-Anbieter diesen Wiedererkennungswert, wenn er die Bilder mit dem Kunden zusammen aufbaut. Natürlich ist es dabei sehr hilfreich, wenn der Moderator der Veranstaltung die möglichen Standardabläufe seiner ERP-Lösung bereits im Hinterkopf hat, und es ist nichts ehrenrühriges, wenn er den Kunden bei der Prozessmodellierung schon sanft darauf hinlenkt – immerhin erspart er ihm dabei mögliche Kosten für Individualprogrammierungen.

(Deswegen rate ich auch davon ab, die Prozessanalyse im Vorfeld des ERP-Projektes mit einem unabhängigen Prozessberater zu machen: Dieser kann nur die „Ist-Prozesse“ erfassen und auf ihre eventuellen Unzulänglichkeiten hinweisen, aber nichts dazu sagen, was im künftigen System die effizientesten „Soll-Prozesse“ sein können.)

Obwohl man im Rahmen dieser „lösungsbezogenen Prozessberatung“ vielleicht bei fast den gleichen Abläufen landet, wie der Anbieter sie auch als Demo hätte vorab anfertigen können, hat der Kunde diese Prozesse nun selbst mitgestaltet – seine Identifikation und damit seine Akzeptanz sind dann viel höher. Komme ich hingegen mit vorgefertigten und dem Kunden zunächst fremden Abläufen, bekomme ich nach kurzer Zeit zu hören (O-Ton): „Könnten Sie jetzt bitte damit aufhören und sich um UNSERE Prozesse kümmern?“