4.1 Identifikation

"Identifikation der Geschäftsprozesse" klingt merkwürdig, schließlich sind die Geschäftsprozesse ja meist schon da, sonst gäbe es das Unternehmen oder die Organisation nicht. Da gibt es die Leistungserstellung, die Beschaffung, die monatliche Gehaltszahlung, usw. Trotzdem gibt es in der Praxis oft Unklarheiten über die ganz konkrete Gestalt (z.B. auch Abgrenzung) eines Geschäftsprozesses. Dies kann verschiedene Ursachen haben:

Um was geht’s?

  • Es herrscht tatsächlich Chaos in der Ablauforganisation in dem Sinne, dass die Geschäftsprozesse zwar realisiert werden, aber mit vielen Schwachstellen. Da gibt es dann Mehrfacharbeiten, vielleicht auch überflüssige Tätigkeiten, usw. Kurz: Effektivität und Effizienz sind nicht in genügendem Umfang realisiert.
  • Dann gibt es Bereiche, in denen die Abläufe höchstens in den Köpfen der unmittelbar dort Aktiven klar ist. Falls möglich, sollte dies geändert und die Geschäftsprozesse dokumentiert werden.
  • Unternehmen wurden verschmolzen ("merging"), Prozesse müssen angeglichen werden. Auch hier ist im ersten Schritt die Identifizierung der Prozesse in den beiden Unternehmen nötig, bevor der An- und Abgleich erfolgt.
  • Im Rahmen einer Optimierung werden die alten Geschäftsprozesse abgelöst und durch neue ersetzt. Die neuen sind anders aufgebaut und eingebettet.
  • Im Rahmen eines Versuchs, die Automatisierung der Geschäftsprozesse voranzutreiben, werden die alten Geschäftsprozesse durch neue softwarebasierte ersetzt. Dies erfordert meist die Einrichtung völlig neuer Geschäftsprozesse.

Deshalb gehört die Identifikation und die Abklärung der Geschäftsprozesse zu den ersten Aufgaben des Geschäftsprozessmanagements. Konkret soll diese Prozessidentifizierung auch klären, welche Geschäftsprozesse nötig sind, um die Wertschöpfung zu realisieren.

Dabei muss die gesamte Prozesslandschaft berücksichtigt werden, denn (fast) kein Geschäftsprozess ist isoliert. Die Prozesse einer Organisation sind miteinander und mit Prozessen aus der Unternehmensumwelt verknüpft. Es werden also alle Geschäftsprozesse und ihre Verknüpfung festgestellt oder auch festgelegt.

4.1.1 Top Down oder Bottom Up

Geschäftsprozesse können top down oder bottom up identifiziert werden. Je nach den oben beschriebenen Szenarien muss die eine oder die andere Strategie gewählt werden.

Beim Top Down - Vorgehen löst man sich völlig von der vorhandenen Prozesslandschaft und geht von den strategischen Planungen der Organisation aus. Von dieser leitet man Schritt für Schritt die Geschäftsprozesse ab. Es eignet sich also bei vorhandener Prozesslandschaft, falls ein radikaler Neuanfang gewollt ist sowie bei einer völligen Neuentwicklung mit oder ohne Automatisierungsabsicht

Top Down

Der Rahmen für die Prozessgestaltung ist bei dieser Vorgehensweise vorgegeben durch:

  • die Geschäftsstrategie mit ihren Geschäftsfeldern und Kundengruppen
  • die Geschäftsziele, dem Kundenbedarf und den Kundenanforderungen
  • dem Leistungsspekktrum
  • den strategischen Erfolgsfaktoren
  • der Wettbewerbsstrategie
  • den Kernkompetenzen

Vgl. [Schmelzer und Sesselmann 2013, S. 140].

Diese Punkte können ergänzt werden um die folgenden, die sich aus den aktuellen Entwicklungen und Trends ergeben:

  • Wunsch nach teilweiser oder vollständiger Automatisierung. In diesem Fall sollen ja die Möglichkeiten der Automatisierung genutzt werden, was natürlich im Prozessdesign zu berücksichtigen ist.
  • Eventuelle Outsourcing-Pläne. Falls geplant ist, Teile der IT-gestützten Geschäftsprozesse in die Cloud zu verlegen, hat dies Konsequenzen für das Design der Prozesse. Zum Beispiel müssen die Schnittstellen zwischen den in die Cloud verlagerten Geschäftsprozessen und den übrigen neu gestaltet werden. Unter Umständen muss auch der Umgang der Geschäftsprozesse mit den Datenbeständen angepasst werden.

Folgende Vorgehensweise ist bei dieser Strategie sinnvoll:

  • Identifizierung der primären Geschäftsprozesse (Kerngeschäftsprozesse). An deren Anfang steht der Bedarf der externen Kunden, am Ende die Bereitstellung der geforderten Leistungen an dieselbigen. Es entstehen Kurzbeschreibungen der primären Geschäftsprozesse.
  • Die so gefundenen primären Geschäftsprozesse werden zerlegt in einzelne Arbeitsschritte und Subprozesse. Dabei entdeckte Optimierungspotentiale werden genutzt/umgesetzt. Hierbei entstehen Sollprozesse. Im nächsten Schritt werden die Automatisierungsmöglichkeiten ausgelotet: Welche Prozessabschnitte können, welche sollen in Software gefasst werden. Falls der Prozess vollständig automatisiert werden soll, muss eine Prozessmodellierung für das Anforderungsmanagement der Softwareentwicklung erfolgen.
  • Festlegung der sekundären Geschäftsprozesse.

Vgl. auch [Schmelzer und Sesselmann 2013, S. 140], [Gaitanides 2012, Pos. 152].

Wichtig ist, dass die Top Down - Neugestaltung der Prozesslandschaft von der Aufbauorganisation abstrahiert, da der Prozessgedanke ja die Überwindung der Aufbauorganisation zur Grundlage hat.

Diese Vorgehensweise birgt Risiken und Chancen. Zu den Risiken gehören:

(1) Großer Aufwand. Schon die Modellierung der Primär- und Kernprozesse ist sehr aufwendig, wenn man wirklich auch alle Sekundärprozesse so entwickeln möchte, wird der Aufwand riesengroß. Letzteres ist auch u.U. nicht sinnvoll, da es dafür Referenzprozesse gibt, die man, z.B. auch über eine entsprechende ERP-Software, einfach geliefert bekommt.

(2) Ein solches Vorgehen ist teilweise eine Illusion. Wer auf diese Art und Weise Geschäftsprozesse entwickelt, kann dies nur tun, wenn er eine Vorstellung von den Geschäftsprozessen hat. Es gibt also durchaus eine Vorprägung, zumindest eine abstrakte. Die Leistung besteht darin, mit dieser "Vorprägung" kompetent umzugehen.

(3) Verlorener Realitätsbezug. Prozesse nach strategischen Vorgaben (Zielen) zu erstellen, kann auch zu nicht realisierbaren Ergebnissen führen.

Zu den Chancen gehört, dass tatsächlich eine völlig neue Fassung wichtiger Geschäftsprozesse entsteht. Wird dies kompetent realisiert, kann eine Optimierung gegenüber der vorliegenden Situation erfolgen.

Chancen

Bei einer sehr unterentwickelten Prozesslandschaft kann diese Vorgehensweise vorteilhaft sein, weil eine solche sich nicht als Ausgangspunkt eignet. Für Sekundärprozesse ist sie aber nicht sinnvoll, hierfür gibt es standardisierte vorgedachte Geschäftsprozesse.

Das Bottom Up - Vorgehen geht von der bestehenden Prozesslandschaft und der vorhandenen Aufbauorganisation aus. Folgende Schritte werden vorgeschlagen:

Bottom Up

  • Erhebung und Modellierung der Istprozesse
  • Schwachstellenanalyse der Istprozesse
  • Modellierung von Soll-Prozessen, die auf den von Schwachstellen bereinigten Ist-Prozessen basieren.

In der Literatur wird diese Vorgehensweise nicht geschätzt. Dabei wird von einer sehr unterentwickelten Prozessarchitektur ausgegangen und folgendes kritisiert [Schmelzer und Sesselmann 2013, S. 141f]:

  • der große Aufwand für die Modellierung der Istprozesse
  • die Orientierung der vorhandenen Prozesse an Abteilungs- bzw. Organisationsgrenzen
  • Redundanzen zu anderen vergleichbaren Prozessen würden nicht erkannt
  • Vorgehen sei eher auf die Beseitigung von Schwachstellen als auf Chancennutzung ausgerichtet
  • der Istzustand würde nicht infrage gestellt und bliebe im Prinzip erhalten
  • Kreativität würde gehemmt
  • funktionales Denken würde konserviert
  • der direkte Bezug zu Kunden würde nicht hergestellt
  • der direkte Bezug zu strategischen Aspekten würde nicht hergestellt
  • die Durchgängigkeit der Geschäftsprozesse über Abteilungen, Unternehmen, usw. sei nicht gesichert

Diese Kritikpunkte befremden etwas. Sie gehen wohl von einer sehr unterentwickelten Prozesssituation aus, wie man sie zu Beginn der Phase der Prozessorientierung tatsächlich vorfand. Inzwischen ist aber, so die Erfahrung des Verfassers, der Wissensstand der Beteiligten und der Reifegrad der Prozesslandschaft so, dass die meisten dieser Fehler vermieden werden (können).

Trotzdem bleibt es dabei: Dem Bottom Up - Vorgehen fehlt der Reiz des Neuanfangs und vieleicht macht dies den Top Down - Ansatz für viele so attraktiv.

Die Realität der Prozessgestaltung in den Unternehmen ist aber heutzutage sehr oft eine völlig andere, als es oben erscheint. Meist werden vorgedachte Geschäftsprozesse einer integrierten prozessorientierten Standardsoftware (z.b. ERP-Software) eingekauft (vgl. auch [Staud 2006, S, 34f]). Da hat dann das "Finden" und die Gestaltung der Prozesse und ihre Abbildung in Software im "Standardsoftwarehaus" stattgefunden und man prüft als Unternehmen letztendlich nur, welche der angebotenen Lösungen am besten auf die eigenen Vorstellungen passen. Dies wird lediglich für Kerngeschäftsprozesse durchgeführt, bei Supportprozessen wird meist die Lösung der Integrierten prozessorientierten Software gewählt.

Vorgedachte Geschäftsprozesse

Genauso, wenn wirklich mal ganz vorn vorne begonnen wird, z.B. im Rahmen einer Neugründung oder einer völligen Neudefinition der Geschäftsprozesse. Dann greift man für das Unternehmen ("Start up") oder den Unternehmensbereich ("CRM") in der Regel auf eine entsprechende für den Bereich erstellte Anwendungssoftware zurück und damit auf deren vorgedachte Geschäftsprozesse.

Wo bleibt da das Geschäftsprozessmanagement, bzw. was bleibt davon übrig? Nun, es findet vorab statt. Vor der Einführung der prozessorientierten Software. Die gewünschten Geschäftsprozesse werden festgelegt, dann wird die Software gesucht, die am besten den Vorstellungen entspricht. So wird es v.a. mit Supportprozessen geschehen. Bei Kernprozessen wird die Vorgehensweise eher auf Eigenentwicklung, Branchensoftware oder stark angepasste ERP-Software setzen.

4.1.2 Orientierungsrahmen für die Prozessgestaltung

Unabhängig davon, welche Strategie man für die Prozessfestlegung wählt, benötigt man Kriterien, nach denen Prozesse identifiziert werden. Dies sind:

  • Zielmärkte und Kundengruppen
  • Kundenbedürfnisse, -anforderungen und -erwartungen
  • Wettbewerbsstrategie
  • Produkt- und Leistungsprogramm
  • Kernkompetenzen

Geht es dann um die Gewichtung der Geschäftsprozesse sind folgende Angaben wichtig:

  • kritische Erfolgsfaktoren des Geschäftes
  • Wettbewerbsstrategie
  • Kernkompetenzen
  • Stärken und Schwächen des Geschäftes

Diese Daten sollten den strategischen Festlegungen entnommen werden können (vgl. auch [Gaitanides 2012, S. 154ff], [Schmelzer und Sesselmann 2013, S. 143]).

4.2 Standardisierung

In diesem Abschnitt wird die in Abschnitt 13.3.5 eingeführte Unterscheidung von Prozessmodell und Prozessinstanz benötigt. Das Prozessmodell gibt an, welche Durchgänge durch den Prozess möglich sein sollen. Eine Prozessinstanz gibt einen konkreten Durchgang an.

Prozessmodell vs. Prozessinstanz

Wer in einem hinreichend großen Unternehmen tätig ist, kennt es. Ein Geschäftsprozess („Beschaffung“) wird an verschiedenen Stellen im Unternehmen unterschiedlich realisiert. Die allgemeine Prozessvorstellung ist also in Unternehmensbereichen oder auch Abteilungen unterschiedlich. Dies ist in einer Zeit, in der schon mittelständische Unternehmen weltweit Tochtgesellschaften oder Vertretungen haben, ein wichtiges Thema:

Quellen des Standardisierungs­bedarfs

  • In einem Unternehmen mit Tochtergesellschaften im nationalen Rahmen werden u.U. dieselben Prozesse in den Tochtergesellschaften auf unterschiedliche Weise durchgeführt.
  • In einem international agierenden Unternehmen sind in den jeweiligen nationalen Gesellschaften Geschäftsprozesse unterschiedlich realisiert. Und dies nicht nur wegen kultureller Unterschiede oder wegen Unterschieden in Bezug auf rechtliche und gesetzliche Festlegungen.

Eine weitere Quelle für den Standardisierungsbedarf ist das Verschmelzen von Unternehmen ("merging"). Dabei treffen oft ganz unterschiedliche Prozesskulturen aufeinander und ganz unterschiedliche Realisierungen derselben Prozesse. Diese Vielfalt ist in der Regel nicht erwünscht und soll beseitigt werden.

Die Standardisierung ist auch sinnvoll, weil ihre Realisierung die Abbildung des Prozesses in eine IT-Lösung wesentlich erleichtert bzw. erst sinnvoll erscheinen lässt.

Grundsätzlich ist eine Standardisierung allerdings nur dann sinnvoll, wenn der Geschäftsprozess viele Routineanteile enthält und wenn er häufig realisiert wird. Meist treten diese beiden Merkmale auch zusammen auf. Sie ist nicht sinnvoll, wenn es sich um kreative oder chaotische Prozesse handelt (vgl. Abschnitt 3.4).

Die Standardisierung bringt zahlreiche Vorteile. Sie schafft ein einheitliches Erscheinungsbild gegenüber den Kunden und Lieferanten, gewährleistet einheitliche Unternehmensschnittstellen mit Kunden, Lieferanten und Partnern und erleichtert die Kommunikation.

Vorteile der Standardisierung:

Auch der Personaleinsatz wird erleichtert:

  • Schulungen sind einfacher, müssen nicht in "Varianten" durchgeführt werden.
  • Personal ist leichter austauschbar.
  • Einheitliche Rollenbeschreibungen und Verantwortungsregelungen werden geschaffen.
  • Prozesstransparenz (Prozessstrukturen, -Schnittstellen,-leistungen) wird erhöht, was zu einer Senkung des Koordinationsaufwands führt.
  • IT-Applikationen können harmonisiert werden.

Vgl. [Schmelzer und Sesselmann 2013, S. 239], [Gaitanides 2012, S. 139].

Obwohl die Standardisierung heute unumgänglich ist, weil ohne sie IT-Untersützung und Automatisierung kaum möglich ist, gibt es auch Nachteile bzw. Risiken, die aber nicht die Standardisierung als solche, sondern deren Realisierung betreffen:

Nachteile/Risiken der Standardisierung:

  • Falls Geschäftsprozesse standardisiert werden, deren Unterschiede durch Kundenwünsche oder regionale Besonderheiten begründet sind und die besser erhalten geblieben wären. Dies kann zu Einbußen an Flexibilität, Kundennähe und Wettbewerbsvorteilen führen. In einem solchen Fall ist es sinnvoller, Varianten des Prozesses zu etablieren und nur die Abschnitte der Prozesse zu standardisieren, die nicht diese wichtigen Besonderheiten aufweisen.
  • Falls in der Standardisierung nicht die beste Lösung durchgesetzt wird. Es ist immer darauf zu achten, dass die leistungsstärkste Variante zum Standard gemacht wird.