Dieses Posting ist ein bisschen Vorbereitung zum Brückenpodcast, der sich mit ERP-Beratung im Allgemeinen beschäftigen wird, während es hier ja um Infor LN im speziellen geht. Er ist ein bisschen länger und textlastiger – aber ich würde mich sehr über Ihre Meinung zum Thema freuen! Sie können unten kommentieren, oder mir auch gern eine Email schicken an ufuchs@all-in-for-erp.com

Sind Prozesse Mumpitz?

Ich will mich mal mit einem Wort beschäftigen, dass ich in der ERP-Beratungsbranche viel zu häufig häufig höre. Eines, das ich nicht mehr hören kann. Eines, das ich mittlerweile sogar für ziemlich gefährlich halte. Es geht um “Prozesse”.

Was kann man da nicht alles für Kombinationen basteln mit diesem Wörtchen: Prozessverständnis, Prozessoptimierung, die Prozesse beschreiben, die Prozesse abbilden, Prozessorientierung, Sollprozesse, Prozesslandkarte, Prozessstruktur. Ich hab sogar schon “Prozesskonzept”, “Prozessplan” und “Prozesskompetenz” gefunden. Kompetenzen sind sowieso super. Alles ganz doll wichtige Herangehensweisen. Wirklich?

Wollen Sie meine Meinung haben, basierend auf der Erfahrung aus 20 Jahren ERP-Implementierung? Ich sag sie Ihnen: Für ERP-Projekte ist das alles in der Regel Mumpitz. Die Musik spielt woanders. “Prozesse” dienen lediglich dazu, Berater-Vodoo aufzufahren und seine Beratungsarbeit irgendwie  zu kommunizieren. Bewirken, Bewegen, tut die Arbeit an Prozessen gar nichts.

Grundlage: Was ist ein Prozess?

Ein Prozess ist eine Abfolge von Tätigkeiten, die aufgrund eines mehr oder weniger klar definierten Auslösers in einer Organisation nach bestimmten Regeln durchgeführt werden. Dabei werden in der Regel aus eingehenden Informationen neue Informationen geschaffen. Ich sag jetzt mal bewusst Informationen und nicht Einsatzgüter, weil wir uns in der ERP-Welt mit der Verwaltung physischer Vorgänge beschäftigen und nicht mit dem physischen Vorgang selbst.

Ausgeführt werden die Tätigkeiten im Prozess entweder von menschlichen Bearbeitern, oder – gerade in ERP-Systemen wichtig – von automatisierten Rechenverfahren.

Die einzelnen Tätigkeiten in einem solchen Prozess können mehr oder weniger komplex sein, sie sind aber, und das ist jetzt wichtig, keine atomaren Einzelschritte. Ein Prozess und sein Regelwerk sind keine Bedienungsanleitung für die Software. Die Tätigkeit besteht in “Erfassen der Auftragsposition im ERP-System”, ggf noch “mit Programmnummer soundso”, aber nicht in “Klick auf das Icon neu”, “Eingabe der Positionsnummer”, “Tab-Taste drücken”, Eingeben der Artikelnummer, “Tab-Taste drücken”, “Eingabe der Menge” etc.

Geschäftsprozesse werden also auf einer höheren Ebene beschrieben. Im Zusammenhang mit ERP-Einführungen geht das vielleicht noch auf die Ebene der einzelnen Applikationen/Programmschritte runter, aber nicht sehr viel weiter.

Und das ist, darauf komme ich gleich, für die Einführung eines ERP-Systems nicht detailliert genug.

Wo kommt’s her?

Woher kommt nun diese Prozessorientierung, die sich in der Beratungswelt allenthalben findet?

Dazu müssen wir uns mal kurz in unsere Zeitmaschine setzen, und eine kleine Reise in die Vergangenheit machen, sagen wir mal, 20 Jahre zurück. Die große Zeit des Business Process Reengineering. Unternehmensberater verdienen Millionen damit, Kästchen und Kringel mit Pfeilen zu verbinden und die mittleren Managementebenen feuern zu lassen, weil man denen kein Kästchen zuweisen kann. Aber auch die große Zeit der ERP-Systeme, mit denen Prozesse “enabled” werden konnten, wie es so schön hieß.

Und das war ja in der Tat auch notwendig. Viele Unternehmen hatten in der Tat noch keine Sicht auf ihre Prozesse. Sondern die berühmten Zäune zwischen den Abteilungen, über die man irgendwas (was auch immer) werfen konnte, ohne sich weiter zu interessieren, was dann passierte.

Führte man vor zwanzig Jahren also eine ERP-Software ein, so war die Hauptarbeit tatsächlich, der Kundenorganisation klar zu machen, dass Daten grundsätzlich auf Basis formeller oder informeller Prozesse durchs Unternehmen fließen und an diversen Stellen Aktivitäten und neue Daten auslösen. Naja, Klammer auf: Dass die Daten so fließen könnten – und sollten.
Es ging darum, tatächlich mal ein Verständnis dafür aufzubauen, dass das, was ein Lagermitarbeiter an den Kunden ausliefert, genau das ist oder sein sollte, was ein Vertriebler als Verkaufsauftragsposition erfasst hat. Und dass, wenn die Verkaufsauftragsposition ordentlich erfasst ist, der Vertriebler dem Lagermitarbeiter eben nicht noch mal extra sagen muss, dass er jetzt ausliefern soll, sondern dass dann das ERP-System dafür sorgen wird, dass der Lagermitarbeiter angetriggert wird. Dass man das auch nicht nach der Lieferung neu als geliefert ins Lagersystem eintippen muss.

Durch die Einführung der ERP-Systeme mit relativ breiter Funktionalität ließen sich vor zwanzig Jahren also tatsächlich Prozesse optimieren, Verwaltungstätigkeiten von den Menschen und Wiedervorlagemappen in die IT-Systeme verschieben.

In der Zeit sind die ERP-Firmen, ihre Methoden und ihre Sicht auf Organisationen und Projekte großgeworden. Und man muss leider sagen, sie haben sich wenig verändert.

Die Welt der Unternehmen aber schon.

Denn heute?

 

Heutiger Zustand

Heute haben alle Unternehmen ERP-Syteme. Heute ist die Prozesssicht viel selbstverständlicher als vor 20 Jahren. Die Kundenmitarbeiter können ihre Prozesse in der Regel aufmalen oder aus dem ISO-9000-Handbuch rauskopieren. Sie müssen sie nicht erst erarbeiten. Aufgabe einer ERP-Einführung ist es also inzwischen eher, einen gegebenen Prozess wieder umzusetzen. Wenn’s geht, effektiver als vorher. Aber in der Masse der ERP-Projekte muss man den Prozess an sich nicht mehr erarbeiten, der ist da.

Klar, Ausnahmen bestätigen die Regel: Es gibt immer wieder Unternehmen, die klein mit Excel und Insellösungen anfangen und irgendwann auf eine ERP-Lösung umsteigen. Da wird man erst mal die Prozesse ordentlich definieren. Aber die Masse der ERP-Projekte braucht sich dieser Herausforderung einfach nicht mehr zu stellen.

Und auch klar: Prozessverständnis und die Abbildung von Prozessen sind fraglos wichtig. ERP-Systeme können erst dann vernünftig parametriert werden, wenn die Prozesse verstanden sind. Selbstverständlich sieht man sich bei der Beratungsarbeit die Prozesse an. Ich mache das gerne zum Einstieg. Und natürlich fallen einem dabei oder bei der intensiven Beschäftigung mit Funktionen Prozessschritte auf, die vielleicht inzwischen unsinnig sind. Oder man hat neue Softwarefunktionalitäten in seinem ERP-System, die bestimme Prozessschritte oder auch Prozesse überflüssig machen und/oder  vielleicht einen ganz anderen Prozess erforderlich machen.

Die Musik spielt in den funktionalen Anforderungen

Zentral für die Vollständigkeit, das gute Gelingen des Projektes, sind aber heute die funktionalen Anforderungen. Jedes ERP-Produkt kann den Prozess eines Verkaufsauftrags abbilden. Vorne wird die Auftragsposition eingegeben, daraus ergibt sich irgendwann eine Anforderung ans Lager, die wird bedient, es entsteht ein Lieferschein und auf Basis dieser Daten dann eine Rechnung. Da sind alle ERP-Systeme und alle Anwenderunternehmen gleich, und drum kann jedes ERP-System bei jedem Anwenderuntehmen diesen Prozess schon irgendwie abbilden.

Ob es diese Abbildung aber so vornimmt, dass am Ende eine notwendige Auftragseingangs- oder Bestandsstatistik rauskommt, ist eine Funktion. Ob und wie dabei eine Losverfolgung abgebildet wird, ist eine Funktion. Wie Materialbeistellungen an Fremdfertiger im Ausland steuerlich und intrastatmäßig behandelt werden, ist eine Funktion.

Das sind kein Prozesse. Das, was in ERP-Projekten die Arbeit macht, ist die Abbildung von Funktionen, die der Kunde haben will.

Ich habe in einem aktuellen Finance-Einführungsprojekt 360 einzelne funktionale Anforderungen nur für die Finanzbuchhaltung gezählt, und da fehlen sicher noch einige. Bei vielleicht einer Handvoll echter Prozesse, die es in einer Finanzbuchhaltungsabteilung so gibt. Mal ganz ehrlich: Worauf sollte man sich eher konzentrieren?

Werden solche Funktionen unzureichend abgebildet, scheitert ein ERP-Projekt. Weil die Anwender anfangen, Parallelsysteme in Excel aufzubauen. Weil sie zu lange brauchen, die Daten einzugeben oder zu finden. Weil sie Daten mehrfach eingeben. Weil Daten in diesen Systemen nicht zusammenpassen. Weil das Management irgendwann auf den Trichter kommt, dass mit dem neuen ERP-System genau diese Verwaltungstätigkeiten einfach funktionieren sollten und nicht einen Riesenaufwand verursachen. Man beachte das Wort: Funktionieren hat was mit Funktion zu tun.

Prozess-Vodoo

Prozesse malen ist einfach. Da muss man sich nicht mit den fiesen Details der Software oder den funktionalen Anforderungen, die die am Prozess unmittelbar und mittelbar beteiligten Personen haben, auseinandersetzen.

Man muss die Software auch nicht so richtig in der Tiefe kennen, um über Prozesse zu diskutieren. Wenn man mit Abteilungsleitern oder höheren Ebenen zu tun hat im Projekt, sind das Leute, die die Software gar nicht in der Tiefe kennen wollen. Und auch nicht die funktionalen Anforderung oder die täglichen Nöte bei der praktischen Arbeit, die ihre Mitarbeiter haben. Dieses ganze Detailgefummel, das braucht und will man als Führungskraft doch nicht. Gib mir das große Bild, und zeig mir (nur mit diesem großen Bild), dass mit Deiner Software alles besser wird als mit meiner alten. Am Ende will ich auf einer DIN-A4-Seite alle Informationen, die wichtig sind, aber bitte keine Details. Nur die, die wichtig sind.

Man kennt das.

Nur: Prozesse in Unternehmen sind heute eben schon gut. Da kann man nicht mehr viel verbessern, auch durch eine neue ERP-Software nicht. Die Verbesserungen liegen auf anderer Ebene (bessere Integration, Aufbrechen von Verkrustungen etc., Zukunftsfähigkeit, viele viele Details in denen das neue System Dinge besser macht als das alte und die sich in Summe zu einer bemerkbaren Gesamtverbesserung addieren). Die aber blöde, nervige, funktionale Details sind.

Und der bequeme Ausweg: Man malt Prozesse. Die aus der Analyse (Ist-Zustand) möglichst kompliziert mit möglichst viel Detailschritten. Und die Soll-Prozesse im neuen System mit möglichst wenig Detailschritten. Die Detailschritte wird’s genauso geben, vielleicht sogar mehr als im Altsystem (man will ja z.B. auch mehr Wissen aus dem neuen System ziehen, das bedingt, dass ganz unten jemand mehr Informationen reinstecken muss). Man malt die Detailschritte nur nicht. Durch diesen simplen Trick, zwei unterschiedliche Flughöhen zu wählen, kriegt man ein schönes Bild in die Köpfe, dass alles besser werden wird.

Das Problem ist aber: Damit bekommt man zwar die Entscheiderebenen ruhig gestellt. Aber nicht wirklich vorwärts im Projekt.

Fazit

Um’s zusammenzufassen: Als zentrales Konzept, um das sich im Projekt alles drehen sollte, sind Prozesse definitiv überbewertet. Wo die Musik spielt, sind die funktionalen Anforderungen. Und die umzusetzen, das macht Arbeit, ist fummelig, kostet Zeit und Nerven aller Projektbeteiligten. Aber man sollte sich als Berater nicht verführen lassen, den einfachen Weg zu gehen und die ganze Zeit nur auf die Prozesse zu schielen, weil man da die ganzen fiesen Details so schön wegblenden kann.

Denn dann kommt man nicht vorwärts.

Oder doch, man ist nach einiger Zeit einmal eine Ringstraße um den Berg Arbeit rumgewandert und steht wieder am Ausgangspunkt, ist aber kein Stück weiter oben. Den Berg bezwingen kann man nur, wenn man den steinigen Weg bergauf geht, sich die hunderte funktionalen Anforderungen Stück für Stück vornimmt und mühsam abarbeitet. Da stur bergauf vorantrotten zu können wie ein Maulesel, und die Kundenmitarbeiter und Kundenorganisation auf diesem Weg mitzuziehen, ist eine der Kernkompetenzen eines guten ERP-Beraters.

 

Haben Sie bis hierhin durchgehalten? Das freut mich sehr! Noch mehr freue ich mich natürlich auch über Ihre Meinung zum Thema. Liege ich falsch? Ist was dran an meinen Thesen? Sagen Sie’s mir, hier in den Kommentaren oder gerne auch per Mail an: ufuchs@all-in-for-erp.com