Hallo zusammen,

erstmal vielen Dank für die Reaktionen auf den Artikel “Prozesse sind überbewertet“. Geantwortet haben Sie mir auf in den Kommentaren zum Artikel, auf XING, und auf Baanboard. Ich will da jetzt kein Zitate-Pingpong auf drei Seiten machen und fasse die Gedanken, die mir beim Lesen und Durchdenken der Antworten so kamen, mal hier zusammen.

Vorneweg noch eins: Ich möchte nicht, dass es so aussieht, als gehe es hier um Mäkelei an Methoden, Herstellern, Produkten oder Beratern. Ich glaube, dass wir in der Branche eine grundsätzliche methodische Lücke haben. Die in der Fachöffentlichkeit auch kontrovers und sich gegenseitig herausfordernd zu diskutieren – und zur Fachöffentlichkeit zähle ich Foren wie diese – ist wichtig. Nur so werden wir – als Anbieter, als Berater, als Öksysteme rund um ein Produkt – besser in dem was wir tun. Nur so werden unsere Produkte und Projekte besser. Und darum geht es letztlich, und nur dann verdienen wir Geld.

Schein-Prozesse

Ich möchte mit dem Beispiel der Benachrichtigung eines Einkaufsmanagers beginnen, das Herr Weiher anführte:  Denn es zeigt sehr schön, was ich mit “Prozesse sind überbewertet” meine: Er schreibt zuerst ganz richtig, dass es hier um eine funktionale Anforderung geht: Wenn eine Bestellung zu lange unbearbeitet liegt, soll der Einkaufsmanager informiert werden.

Herr Weiher fährt dann aber trotzdem prompt fort zu erklären, wie einfach das ganze doch in Infors ION Process zu modellieren sei. Man kann da ja den Prozess malen und Regeln hinterlegen, muss dann nur noch dafür sorgen, dass das ERP-System alle Bestellungen als BODs rausschubst und schwupps fliest die Email.

Nur: Das ist kein Geschäftsprozess. Auch wenn ich das in einem Geschäftsprozess-orientiertem System abbilde. Es ist eine Geschäftsfunktion.

Die gleiche Geschäftsfunktion kann ich in Infor LN ganz simpel so umsetzen, dass der Einkaufsmanager morgens die Session zur Anzeige der Bestellungen startet und nach Status und Datum filtert. Bam. Das ist kein Prozess. Das ist das, was ERP-Systeme primär und zu allererst können sollten: Wiedervorlage organisieren. Um diese Anforderung aufzunehmen, brauche ich keine Prozesssicht. Um sie umzusetzen, auch nicht.

Die Prozessicht schadet hier sogar. Denn sie würde beispielsweise dafür sorgen, dass der Manager für jede Bestellung (das Token, das durch den Prozess fliest) eine Nachricht bekommt. ION löst das zwar ganz clever, indem solche Benachrichtigung nicht zwingend per Email verschickt werden müssen sondern in einer eigenen Arbeitsoberfläche auftauchen. Aber dennoch gibt es eine Information pro Vorgang, wenn ich in Prozessen denke. Denke ich in Funktionen, gibt es eine Sammelinformation einmal am Tag, eine Punchlist oder etwas in der Art. Somit erhält der Anwender eine einzige Aufgabe, die weitaus konzentrierter abgearbeitet werden kann.

Ordnung und Struktur

Herr Dorsch wies darauf hin, dass Prozesse als Ordnungskriterium durchaus eine Berechtigung haben.

Ja, die Ansicht teile ich, aber nur begrenzt. Ich schrieb ja auch schon im Artikel, dass ich Prozesse zum Einstieg in die eigentliche Projektarbeit durchaus nutze. Sie dienen mir aber dann dazu, die funktionalen Anforderungen zu erarbeiten und zu strukturieren, weil bei dieser Aufgabe im Vorfeld in der Regel viel zu kurz gesprungen wird.

Diese funktionalen Anforderungen organisiere ich nicht nach Prozess, sondern nach Funktionsbereichen. So erhalte ich Arbeitspakete für die Berater und einen Produktstrukturplan (der ist ein bisschen was anderes als ein Projektstrukturplan). Auf diesem Plan überwache ich den Projektfortschritt. So arbeite ich vom gedanklichen Ansatz her wertschöpfend am Produkt (funktionierendes ERP-System) statt am Projekt (ERP-System einführen). Denn was verfolgen wir denn auf diesen elenden Todo-Listen? Doch nicht, ob der Unterprozess “Materialbeistellung” umgesetzt ist, sondern dass ganz konkret die Materialbeistellung für den Schweizer Fremdfertiger vom österreichischen Lager nicht geht, wenn man da eine Entnahmeprüfung vorsehen will, weil das System dann irgendwelche seltsamen Probleme mit der Umsatzsteuer meldet. “Vom österreichischen Lager muss geprüftes Material für Schweizer Fremdfertiger beigestellt werden können” ist aber eine funktionale Anforderung, und die ist das eigentliche Ordnungskriterium in der Projektarbeit.

Eine solche Anforderung fällt übrigens auch in der Regel nicht aus einer Analyse von Prozessen raus, sondern aus einer Analyse von Strukturen.

Sofern ich’s richtig verstanden hab, springe ich daher nach Meinung von Herrn Herko mit dem funktionalen Ansatz sogar zu kurz: Funktionen kann man im Projekt immer irgendwie liefern. Wenn aber die Grundstrukturen nicht passen, ist man aber ziemlich am Ende mit seiner Weisheit. Das stimmt sicher, und das ist glaube ich der entscheidende Punkt bei der Softwareauswahl. Die Software muss strukturell passen: Eine Software, die aus ihrer Historie her für Anlagenbauer gemacht ist, wird bei einem Einzelhändler schwerlich einzuführen sein. Dieses strukturelle Übereinpassen gut beurteilen zu können sollte die Kernkompetenz von Auswahlberatern sein. Nicht Prozesse-malen und Wischiwaschi-Lastenhefte-basteln.

Warum die Kästchen eines Prozesses keine Geschäftsfunktionen sind

Dann würde ich gerne noch mit einem Missverständnis aufräumen: Geschäftsfunktionen sind mitnichten die Elementarbestandteile von Geschäftsprozessen. Sie sind Gruppen zusammengehöriger, extrem detaillierter funktionaler Anforderungen, die in ihrer Summe dazu führen, dass die Anwenderorganisation einen oder mehrere Prozess oder einen Teil eines Prozesses durchführen kann.

Woraus hingegen ein Geschäftsprozess zusammengesetzt ist, sind Tätigkeiten, Aufgaben, Aktivitäten, wie auch immer man das nennt. Wenn die gut beschrieben sind, hilft das zwar, auch die Geschäftsfunktionen zu beschreiben. Aber die sind dennoch etwas inhärent anderes.

Geschäftsfunktionen stehen orthogonal zu den Prozessen: Mathematisch betrachtet kann man die eine Modellierungssicht nicht formal auf die andere abbilden.

Nehmen wir beispielhaft einen Wareneingangsprozess, den man als Prozessberater sich ganz fix ausdenken und aufmalen kann. Da zieht man ein paar Kästchen auf die Arbeitsfläche und schreibt rein: “Abladen”, “Sichtprüfung auf beschädigte Verpackung”, “Abscannen des Wareneingangslabels mit Scanner” und “Ggf. Korrektur der Wareneingangsmenge im Scanner”. Das sind die kleinsten Tätigkeiten, auf denen ein solcher Prozess modellierbar wäre. Die interessante Geschäftsfunktion hingegen ist “Buchen von Wareneingängen über Handscanner”.

Dazu gehört weit mehr, als diese zwei darauf bezogenen Tätigkeiten. Dazu gehört, dass eine Software auf diesem Scanner läuft, die Barcodes erkennt und mit dem ERP kommuniziert. Dazu gehört, dass der Handscanner eine Tatstatur haben muss. Dazu gehört, dass der Lieferant diese Labels drucken können muss oder sie von uns beigestellt bekommt. Dazu gehört, dass geklärt ist, ob die Handscanner auch dann (Nachtschicht Freitag auf Samstag) funktionieren sollen, wenn das ERP-System gerade für eine Wartung heruntergefahren sein muss. Wenn das der Fall sein muss, gehört dazu, dass irgendeine Software die Daten zwischenpuffert.

Erst aus dieser Betrachtung ergeben sich dann funktionale Anforderungen: “Ein mobiler Handscanner mit einer eigenentwickelten Software, die im Projekt nicht abgelöst werden soll, muss einen vom System bereitgestellten Webservice ansprechen. Dieser Webservice muss einen 20-stellige Wareneingangslabelcode entgegen nehmen. Der Service muss anhand dieser Nummer die zugehörige Bestellposition ermitteln, und die Soll-Menge zurückgeben”. Ein zweiter Service muss Code und Menge entgegenehmen und die Menge auf der entsprechenden Bestellposition als Wareneingangsmenge verbuchen”. Aber mit etwas Nachdenken kommt man schell auf weitere funktionale Anforderungen: “Stehen die Services zur Verfügung, muss die Rückmeldung innerhalb von 1 Sekunde erfolgen”. Oder diese hier: “Das System muss gleichzeitig mit dem Bestellpapier einen Barcode-Aufkleber mit einem 20-stelligen Wareneingangslabelcode drucken…”  Oder auch diese: “Die Lieferanten müssen dahin gebracht werden, die entsprechenden Labels aufzukleben”. All das sind die Baustellen, die es abzuarbeiten gilt, bis diese zwei fix gemalten Tätigkeiten auch funktionieren.

Wenn man einen Hammer hat…

Um sicherzustellen, dass die UST-Voranmeldung ans Finanzamt hochgeladen werden kann, ist mir völlig wumpe, dass ein Teil der Daten am Ende aus dem Order-to-Cash-Prozess rausfällt. Ich muss sicherstellen, dass die Buchungen so mit den notwendiggen Kategorien markiert werden, dass sie in die richtigen Summen einfließen können. Ich muss sicherstellen, dass der Vertrieb in seinen Aufträgen umsatzsteuerrelevante Ausnahmesituationen (Freihafen, Abholung durch EU-Auslandskunden etc.) erstens erkennt und zweitens im System sauber markieren kann. Ich muss sicherstellen, dass ein generisches, international einsetzbares UST-Reporting so konfiguriert ist, dass die Datei für’s deutsche Finanzamt richtig aufgebaut wird. Ich muss sicherstellen, dass die entsprechenden Algorithmen richtig rechnen (soll heißen: wenn’s einen Bug gibt, muss ich dem hinterherrennen und organisieren, dass er totgeschlagen wird). Ich muss sicherstellen, dass der Applikationsrechner das Ding zum Finanzamt hochladen kann (und nicht durch Firewalls, Zertifikate, seltsame DNS-Einstellungen und weiß der Teufel was für Nickeligkeiten daran gehindert wird). All das sind Aufgaben, Arbeiten, die in ERP-Projekten wahrscheinlich bis zu 70% des Aufwands ausmachen, und die haben mit “Umsetzung von Prozessen” nicht das geringste  zu tun.

Mir kommt es ein bisschen so vor wie die Geschichte mit dem Hammer, der alles wie einen Nagel aussehen lässt: Vor über 25 Jahren hat Prof. Scheer mit Aris das erste Geschäftsprozess-Modellierungstool auf den Markt geschmissen. Heute sind die Anbieter Legion. Und weil alle Welt so’n Ding hat, will’s alle Welt nutzen, und sieht überall Prozesse, wo keine sind.

Worauf ich aber eigentlich herauswollte mit dem Artikel: Weil alle inzwischen überall Prozesse sehen, und auf Teufel komm raus auf diesen Prozessen rumgeritten wird, glaubt “das Management” inzwischen, mit der Prozessbeschreibung und Prozessdefinition sei die Arbeit getan: “Sie haben ja hier unsere Sollprozesse, die brauchen Sie ja bloß noch in Ihrem System abzubilden, das kann das doch alles angeblich! Warum dauert das denn so verdammt lang?!?”

Ganz einfach: Weil es auf Prozesse überhaupt nicht ankommt.