Leitfaden für Anfänger in der Geschäftsprozessmodellierung

Smartsheet kostenlos testen
Get a Free Smartsheet Demo

By Kate Eby | 11. November 2016 (aktualisiert 4. August 2023)

Wie können Sie visualisieren, wo sich Ihr Unternehmen befindet und wo es sein sollte? Diese Art von Vorhersage ist schwierig, zum Glück gibt es also ein Tool, das helfen kann. Geschäftsprozessmodellierung ist ein Qualitätsmanagement-Tool, das Teil des modernen Geschäftsprozessmanagements (Business Process Managment/BPM) ist. Das Tool stellt die aktuellen Prozesse einer Organisation zur Analyse oder Verbesserung auf formalisierte Weise dar. In diesem Artikel konzentrieren wir uns auf zwei verschiedene Perspektiven: die Geschäftsperspektive und die Softwareentwicklungs-Perspektive. Für beide Bereiche sind Prozesse von größter Bedeutung. Wir betrachten die praktischen Grundlagen der Geschäftsprozessmodellierung sowie die verschiedenen Methoden, Sprachen und ihre Zukunft. Nebenbei geben unsere Modellierungsexperten ihre Einschätzungen ab.

Warum sollte man die Geschäftsprozessmodellierung verwenden?

Organisationen verwenden die Geschäftsprozessmodellierung (GP-Modellierung), um ihre Prozesse visuell zu dokumentieren, nachzuvollziehen und zu verbessern. Die GP-Modellierung ist Teil des Geschäftsprozessmanagements (Business Process Management/BPM) und wurde als organisatorisches Tool verwendet, um den „Ist-Zustand“ als Basis auszulegen und die Zukunft (oder den „Soll-Zustand“) mit entsprechenden Verbesserungen zu bestimmen. Die GP-Modellierung stellt alle verbindenden Aktivitäten, Ereignisse und Ressourcen des Prozesses eines Produkts oder einer Dienstleistung visuell dar, um ihn effizienter zu machen. GP-Modellierung kombiniert oft die Disziplinen Prozessabbildung, Prozessfindung, Prozesssimulation, Prozessanalyse und Prozessverbesserung. Im Rahmen eines Geschäftsprozess-Reengineerings (Business Process Reengineering/BPR) wird GP-Modellierung verwendet, um zu beleuchten, welche Prozesse bereits verwendet werden, und um neue Prozesse darzustellen. Einige der anderen Gründe, GP-Modellierung zu verwenden, sind folgende:

  • Visuelle Modelle von Prozessen erstellen – Dokumentation mit Word reicht oft nicht aus, damit Mitarbeiter nachvollziehen können, wie ein Prozess ausgeführt wird. Die zusätzliche visuelle Darstellung trägt dazu bei, ein umfassendes Bild zu erstellen.
  • Betriebsabläufe aufeinander abstimmen – Bei jeder neuen Geschäftsstrategie muss für konsistente Prozesse nach einer Änderung herausgefunden werden, wie Sie innerhalb der gesamten Organisationsstrategie bleiben. Analysen werden auch durchgeführt, um Engpässe und Ineffizienzen zu identifizieren und Prozessagilität zu ermöglichen.
  • Prozesskommunikation verbessern – Kommunikation ist der Schlüssel für alle der folgenden Aufgaben: Formalisierung bestehender Prozesse (die einst informelles Wissen waren), Erstellung einheitlicher Prozesse, Beseitigung von Unklarheiten bezüglich Geschäftsregeln, Umgang mit Ausnahmen, Einhaltung regulatorischer Vorschriften, Sicherstellung, dass Geschäftsleute verantwortlich sind und Unterstützung neuer Initiativen (wie Lean Six Sigma).
  • Betriebliche Effizienz verbessern – Die Modellierung von Prozessen fördert die Optimierung, indem sie Simulationen ermöglicht und notwendige Verbesserungen veranschaulicht. Dies verkürzt die Zykluszeit und fördert eine bessere Ressourcennutzung. 
  • Wettbewerbsvorteil verschaffen – Ein Prozess ist insgesamt besser, wenn er ständig verfeinert und mit den Strategien des Unternehmens in Einklang gebracht wird. Diese Effizienz versetzt das Unternehmen in eine zukunftsorientierte Position, um besser als die Konkurrenz zu sein.

 

Geschäftsprozessmodellierung in der Softwareentwicklung

 

Softwareentwicklung ist ein riskantes Fachgebiet. Vor zwanzig Jahren ergab die CHAOS-Studie der Standish Group von 1995, dass 90 Prozent aller Softwareprojekte scheitern. Heute sind diese Zahlen geringer, spiegeln aber trotzdem wider, dass es noch viel zu tun gibt. In der vom gleichen Unternehmen durchgeführten Studie aus dem Jahr 2015 lag die Erfolgsquote von Softwareentwicklungsprojekten immer noch bei nur 29 Prozent. Die Empfehlungen des Unternehmens, diese Zahlen zu verbessern, sind im Laufe der Jahre mit neuen Trends abgeebbt und wieder aufgekommen, aber eine Hauptempfehlung gilt noch immer: Kommunikation mit allen Stakeholdern, insbesondere mit den Endbenutzern, da die Endbenutzer diejenigen sind, die am Ende die Anforderungen definieren. Experten empfehlen, in Projekten frühzeitig klare Modelle mit verständlicher Dokumentation zu entwickeln, um die Anforderungen an die Software zu validieren. GP-Modellierung ermöglicht es Softwareentwicklern, mit Stakeholdern zu verhandeln, um basierend auf dem, was für beide Gruppen optimal ist, das zu erstellende System zu bestimmen. 

Die meisten GP-Modelle wurden im Rahmen bestehender Unternehmensarchitekturen entwickelt, was zeigt, dass die Absicht bei der Entwicklung darin besteht, dass der Endbenutzer repräsentiert wird. Diese Modelle wurden jedoch aus einer Reihe verschiedener Perspektiven entwickelt, darunter funktionale, verhaltensbezogene, organisatorische und informatorische. Experten sind sich einig, dass die Kombination dieser Perspektiven für das Prozessdesign die beste Methode ist.

  • Die funktionale Perspektive zeigt, welche Prozesselemente ausgeführt werden und welche Informationen für diese relevant sind.
  • Die verhaltensbezogene (oder dynamische) Perspektive zeigt die Abfolge der Interaktion und wie Prozesselemente ausgeführt werden. 
  • Die organisatorische Perspektive zeigt, von wem und wo die Elemente eines Prozesses ausgeführt werden.  
  • Die informatorische perspektive stellt den Ursprung der Informationen dar, die produziert oder analysiert werden.

Geschäftsprozessmodellierungssprachen in der Software-Geschäftsprozessmodellierung

Alle existierenden Geschäftsprozessmodellsprachen stammen von verschiedenen Facetten der wissenschaftlichen Tradition und wurden für die eine oder andere Perspektive entwickelt. Es gibt erhebliche Überschneidungen in den Sprachen, aber es gibt vier große Kategorien von Geschäftsprozessmodellierungssprachen.  

  • Traditionelle Prozessmodellierungssprachen: Von der Management-Informationssystems-Tradition (MIS) der Informationstechnik stammend, sollen diese Sprachen verständlich sein und sind in der Regel nicht formal. Dazu gehören IDEF, Petri Nets, EPC, Rolle-Aktivität-Diagramme, REA und BPML.
  • Workflow-Modellierungssprachen: Diese Skriptsprachen dienen der Beschreibung von Workflows für ein Workflow-Managementsystem (WfMS). Zu diesen sehr formalen Sprachen gehören die Workflow Process Description Language (WPDL) und vorgeschlagene Austauschformate (PIF, PSL).
  • Prozessintegrationssprachen: Diese Sprachen dienen der Integration zwischen Unternehmen und erfassen verschiedene Ebenen der Semantik in Prozessen. Dazu gehören RosettaNet, ebXML und BPEL4WS.
  • Objektorientierte Sprachen: Diese Sprachen sollen sowohl für IT- als auch für Domänenexperten verständlich sein und stellen die Softwaredomäne dar. Der Großteil der objektorientierten Modellierung berücksichtigt die funktionalen, verhaltensbezogenen und informatorischen Perspektiven.  

Hafedh Mili et al. empfehlen Teams, eine Hauptsprache für die Modellierung zu verwenden und dann verschiedene Teile, die zum Prozess passen, in anderen Sprachen zu nutzen. In diesem Fachgebiet scheint es, als wären sich Experten darüber einig, dass auch die Sprachen von den Aufgaben gesteuert werden sollten.

 

Wie man ein Geschäftsprozessmodellierungsprojekt angeht

Die Wahl eines Ansatzes für die GP-Modellierung ist genauso wichtig wie deren Ausführung. Der Ansatz, der von der eigentlichen Aufgabe an sich abhängt, ist keine „Einheitsgröße“. Bevor ein Projekt durchgeführt wird, sollten einige Klassifizierungen vorgenommen werden. Laut Bider sollten Fachleute drei Faktoren berücksichtigen: die eigentlichen Geschäftsprozesse, die Merkmale der Modellierungsumgebung und die beabsichtigte Verwendung des Modells. Diese drei Faktoren lassen sich in bestimmte geschäftliche Überlegungen untergliedern.

 

  • Die Geschäftsprozesse – Unternehmen sollten ihre aktiven und passiven Teilnehmer berücksichtigen, inwieweit sie ihre betrieblichen Ziele erreichen, wie eng der Prozess mit der Umgebung interagiert und die Art und Planmäßigkeit des Prozessablaufs. 
  • Die Merkmale der Modellierungsumgebung – Für die Modellierungsumgebung sollten Unternehmen die Reife ihrer bestehenden Prozesse berücksichtigen und ob Personal zur Verfügung steht, das die sehr formale Notation versteht, oder nicht.  
  • Die beabsichtigte Verwendung des Modells – Unternehmen sollten ihre Vorgaben für das Entwerfen von Modellen berücksichtigen und welche Grundlage sie für die Erstellung von Modellen verwenden. Sie könnten zum Beispiel versuchen, die aktuellen Prozesse zu verbessern, Analysen oder Reengineering durchzuführen oder ein neues Computersystem zu erstellen.

Da es keinen allgemeingültigen Ansatz für GP-Modellierung gibt, empfehlen Experten, alle einzigartigen Geschäftsfaktoren zu berücksichtigen. Einige Fachleute empfehlen einen präzisierten formalen Ansatz, bei dem alle Informationen erfasst werden, bevor Tools ausgewählt werden, während andere bestimmte Tools empfehlen, die in der Vergangenheit bei ihnen funktioniert haben. Zwei unserer Experten geben im Folgenden ihre Empfehlungen ab.

Laut Dani Peleva, Managing Director von Local Fame Ltd:

 

“When approaching a business process modeling task, I’d always break it through the prism of project management as it helps me get an idea of the objective of the system that needs engineering, the time the process needs to be completed for, as well as the resources available. Once you know what the requirements are, i.e. the purpose of the process is, what the deliverables are, the budget/resource constraints and so forth, it is a lot easier to approach the design/engineering stage. 
When it comes to process engineering at Local Fame, we always have efficiency and effectiveness in mind - the most cost-effective, timely and optimized manner that a process can flow. For this purpose, I always approach the task from a few different angles - from the start of the process, as well as from the end of the process backwards. When you do not limit yourself with the direction of the process flow you can identify gaps and possible flaws in the strategy and implementation, as well as possible bottlenecks. Once I come up with a few different models I test those applying different scenarios in order to understand how sustainable those are in turbulent environment. This is when usually you sift through the best models and shortlist one or two successful ones. 
Additionally, an intrinsic part of business process modelling for me is risk management, more specifically, identifying the potential flaws of the model and where and under what circumstances the model can fail. Identifying those weaknesses of the process helps you create contingency plans and backups, and as you often may find yourself, you get to optimize the process even further and scrap some of the chunks you initially considered essential, but later on realized you could go without. When thinking about risk management, however, one should know a risk could be both a positive and a negative, risk can create opportunities for the process to fail or get delayed, but also speed up and become more efficient, which again leads to the process optimisation and potential changes in the model. Tools I often use when doing business process modelling are Gliffy, Activiti Modeller, and Gantt charts. 
To conclude, when modelling a process or re-engineering an existing one, I usually approach the task from a project management perspective analysing the requirements fully before moving to the design stage. After design stage, I test the model numerous times in different scenarios and if needed I return to different stages to optimise and tweak it further. Lastly, I always think about risk management and contingency to make sure that the process is resilient and sustainable.”

 

Ray McKenzie, Founder and Principal, Red Beach Advisors, recommends, “As a management and business consultant for small- to medium-sized companies, a primary duty of mine is to develop efficient and optimized process for every organization to be productive. I always start with examining the problem and finding out the history of the problem, the different parts of the problem, and the effect the problem has on the business. Understanding the problem and components are core pieces to developing an effective process model to improve. Start with the problem. Examine the parties involved. Understand the current performance and measurements. Define the performance improvement goals. Outline an efficient process which drives results and displays success.”  

 

Workflows und Business Service Oriented Approach (BSOA)

Einige Experten betrachten die GP-Modellierung für die Softwareentwicklung als einen Vorher-Nachher-Ausblick, der sich um die Einführung von Webdiensten dreht. Vor der Entwicklung des Webs war der Hauptansatz für die Entwicklung von Prozessen Workflows. Im Workflow-Ansatz werden die Geschäftsprozesse vorbestimmt. Die geeignetsten Sprachen sind Business Process Execution Language (BPEL) und Flow Definition Language (FDL). Am Workflow-Ansatz wurde kritisiert, dass er in einem modernen Umfeld nicht sehr flexibel sei.

Nach der Entwicklung von Webdiensten wurde der Ansatz der GP-Modellierung für die Softwareentwicklung fokussierter und als der Business Service Oriented Approach (BSOA) identifiziert. Die Prozessmodellierung basiert auf der flexiblen Zusammensetzung von Geschäftsdienstleistungen. Der Ansatz kann durch die Verwendung von Bausteinen auf die Ziele und Anforderungen des Designers in der Architekturentwicklung zugeschnitten werden. Dienstleistungen erledigen kleine Aufgaben wie die Datenentwicklung oder einfache Serviceverfahren. Alles in allem ist BSOA ein System mit hohem Wiederverwendungswert, das angepasst werden kann und für das regelmäßig Upgrades durchgeführt werden können. Dieser Ansatz wird in die Kategorie Agile eingestuft und kann in vielen verschiedene Arten von Organisationen angewendet werden.

 

Verschiedene Möglichkeiten der Geschäftsprozessmodellierung

Zwischen all den Standards und standardisierten Sprachen denken einige Fachleute, dass die Kreativität bei der Gestaltung von Prozessen abhandenkommt. Alternative Ansätze können einen Teil dieser Kreativität wiederherstellen. Einige der beliebtesten Techniken, die alleinstehend sein können oder sogar formellere Ansätze ergänzen können, sind die folgenden:

  1. Flussdiagramm-Technik
  2. Datenflussdiagramme – Die Technik von Yourdon
  3. Rolle-Aktivität-Diagramme (RAD)
  4. Rolle-Interaktion-Diagramme (RID)
  5. Gantt-Diagramm
  6. Integrierte Definition für Funktionsmodellierung (IDEF)
  7. Farbige Petrinetze (Colored Petri-nets/CPN)
  8. Objektorientierte Methoden (OO)
  9. Workflow-Technik
  10. Simulation
  11. Geschäftsprozessmodellierungsnotation (Business Process Modeling Notation/BPMN)
  12. UML-Aktivitätsdiagramm
  13. Transformationelle Prozessmodelle
  14. Storytelling
  15. Hierarchische Prozessmodelle
  16. Visualisierung

 

According to Bernard Lee, President of Charlotte Search Engine Consultants, there are other ways to model your projects visually. He points out that, “As a lifelong entrepreneur who started my first business at 20, I am now 53 and am considered a ‘college dropout.’ It has always been about systems, automation, and measuring risks to achieve our stated goals. This has been true in my career as a wealth manager, a Healthcare IT executive, and now as the founder of a digital marketing agency that specializes in SEO. Yes, SEO is about metrics, analytics, and CTR (click-through rate). Nevertheless, I've found the creative aspects is what separates the pretenders from the achievers. We are Google partners so we believe in the usual success measurements, but get there differently. YouTube, Geo-Tagging, and unorthodox combinations of our client's digital properties consistently land multiple properties on page one for the most important keywords. The visual of multiple positions on page one always has an immediate impact on our client’s brand, traffic, and conversions while moving competitors to page two.”

Prozesserfassung vs. Prozessmodellierung

Die Prozesserfassung ist eine Übersicht über eine Organisation als einzelne Entität mit miteinander verbundenen Teilen. Der Fluss von Geschäftsprozessen durch die Organisation wird überprüft, um zu klären, wer was tut, wie Prozesse ausgeführt werden und nach welchem Standard sie beurteilt werden. Bei der Prozessmodellierung konzentrieren sich Fachleute eher darauf, wie effizient die Prozesse sind, und verwenden bewährte Geschäfts- und Wirtschaftsvorgehensweisen. Obwohl beide die Prozesse grafisch darstellen, ist die Prozessmodellierung ein tieferer Einblick in die Beziehungen, welche die Dienstleistungen und Ergebnisse produzieren.


Framework für die Modellierung und Bewertung von Softwareprozessen (Framework for the Modeling and Evaluation of Software Processes/FMESP)


Eines der komplizierten Probleme, das durch die Entwicklung standardisierter Geschäftsprozesse aufkam, ist der Gedanke, dass ihre Wirksamkeit bestimmt werden muss. Mit anderen Worten, wie erfolgreich sind Geschäftsprozesse? FMESP ist eine Reihe von Messzahlen, mit denen konzeptionelle Modelle von Geschäftsprozessen bewertet werden: was sie tun und was sie nicht tun. Bei FMESP wird die strukturelle Komplexität von Softwareprozessmodellen und dann der Aktivitäten, Rollen und Arbeitsprodukte gemessen. Dieses Framework soll Unternehmen objektive Informationen zur Wartbarkeit ihrer Modelle geben.

 

Gute Geschäftsprozessmodelle entwickeln

Wo fangen Fachleute bei einem GP-Modell an? Einer der gängigen Ansätze spricht sich dafür aus, ein Problem auszusuchen, die Methode auszuwählen und dann das Problem zu lösen. Die Dinge einfach zu halten stellt sicher, dass alles Relevante im Modell ist und alles, was im Modell ist, relevant ist.  
Weitere professionelle Tipps sind:

  • Stellen Sie sicher, dass Sie wissen, wer Ihre Ressourcen sein werden. Erstellen Sie Listen mit Aufgaben, Personen und der Zeit, die für die Fertigstellung des Modells erforderlich ist. 
  • Führen Sie Vorstellungsgespräche in der Reihenfolge durch, in der die Rollen im Prozessmodell stehen.
  • Dokumentieren. Dokumentieren. Dokumentieren.
  • Überprüfen Sie alle Ihre Symbole erneut, stellen Sie sicher, dass es einen Schlüssel gibt, und befolgen Sie jeden Schritt, um sicherzustellen, dass der Pfad Sie entweder zurück an den Anfang oder nach vorne führt.
  • Kennen Sie Ihr gewünschtes Ergebnis im Voraus.
  • Ermitteln Sie Ihre Start- und Endpunkte.
  • Besorgen Sie sich die Dokumente und Formulare, die Teil des Prozesses sind, im Voraus.
  • Verwenden Sie Vorlagen, wann immer Sie können.

Laut Steve Wallis, Mitbegründer/Analyst/Consultant bei ASK MATT, Foundation for the Advancement of Social Theory (FAST) – Theory for a better World:

 

“BPM is incredibly useful for showing ‘what goes on’’ within a business organization. However, it can also create a false sense of comfort. When the map says, ‘You are here’ we feel a sense of security. However, unless the map shows how to get from ‘here’ to ‘there’ it is not going to be very useful. More importantly for the ever-shifting world of business, a map needs to show multiple paths so that leaders can take advantage of new options when unanticipated problems arise (and you know they will). Research in this area suggests that models (maps) which are more complex and have more interconnections are more useful for understanding how organizational processes work, and how they might be changed when the need arises. What does NOT work is a simple, linear model such as: 

 

Bildquelle: Steve Wallis


Oh, wenn das Leben nur so einfach wäre – und so vorhersehbar, allerdings ist es das nicht. Daher suchten wir nach einem etwas anderen Ansatz für die Geschäftsprozessmodellierung. Wir nennen es Strategic Knowledge Mapping (SKM/strategische Wissenserfassung) und konzentrieren uns dabei auf die transformativen Aspekte der Modellierung. Anstatt zu modellieren, was auf der „Oberfläche“ passiert (z. B. liefert die Forschung Informationen für die Herstellung), regen wir unsere Kunden an, zu betrachten, welche Änderungen in allen miteinander verbundenen Schritten des Prozesses auftreten. Mithilfe unserer Forschung und Erfahrung haben wir zwei einfache Techniken für die Entwicklung guter Modelle entwickelt. 
Erstens, um eine Transformation in einem Modell zu verstehen, muss es mehr geben, als ein Pfeil der auf eine Box zeigt. Wenn es zum Beispiel um die Herstellung von Backwaren geht, erfordert der Herstellungsprozess Rohstoffe (Mehl, Eier, Zucker, Schokolade usw.) und Ausrüstung (Ofen, Regale, Mixer usw.) und Köche (mit einem gewissen Maß an Fachwissen). Deshalb erstellen wir, um die Transformation besser zu verstehen, ein Modell, das zeigt, wie alle diese ‚Inputs‘ kombiniert werden, um den transformierten ‚Output‘ zu erzeugen. Für einige mag das offensichtlich erscheinen. Die versteckte Erkenntnis (z. B. Schokoladenfüllung) ist hier jedoch: Wenn Sie ein Modell haben, bei dem nur ein Pfeil auf etwas zeigt, deutet das Fehlen zusätzlicher Pfeile auf eine Lücke im Modell hin. Für die Verwaltung des Prozesses fehlt ihnen ein alternativer Pfad. 
Der zweite Tipp für die Erstellung effektiver Modelle besteht darin, jeden Pfeil als ‚kausal‘ zu betrachten. Dies ist einer der großen Teile des ‚in Vergessenheit geratenen Wissens‘ in der Geschäftswelt. Kausalität ist die Essenz des wissenschaftlichen Verständnisses. Um den Transformationsprozess und Geschäftsprozesse im Allgemeinen zu verstehen, reicht es nicht aus, einfach nur zu sagen: ‚Der Koch mischt die Zutaten und backt die Kuchen.‘ Ein guter Manager weiß, dass mehr Rohstoffe, mehr Ausrüstung und mehr Fachwissen die Transformation in ein marktfähiges Produkt (oder eine Dienstleistung) bewirken. Und für die Verwaltung dieses Prozesses kann es einige Abstriche geben (ein wirklich guter Experte kann den Rohstoff möglicherweise ein wenig ausdehnen), aber jeder Aspekt ist erforderlich, um das Endprodukt herzustellen. Ohne Rohstoffe werde ich kein Gebäck zu meinem Kaffee haben!“

Geschäftsprozessmodellierungsnotation (Business Process Model and Notation/BPMN)

BPMN wurde von der Business Process Management Initiative (BPMI) als offener Branchenstandard entwickelt und wird aktuell von der Object Management Group (OMG) verwaltet. Keine Software und kein Beratungsunternehmen besitzt es. Es ist eine grafische Notation für die Erstellung von Prozessmodellen, ähnlich wie Flussdiagramme, die branchenweit verwendet und verstanden wird. Viele Software-Tools unterstützen BPMN. Die Bedeutung der Formen und Symbole besteht jedoch unabhängig von diesen Tools und diese Bedeutungen sind genau. BPMN ist ein zentraler Bestandteil des Geschäftsprozessmanagements (Business Process Management/BPM), einer Initiative von Unternehmensarchitekturen. Die derzeit verwendete Version von BPMN ist v2.0, zuletzt aktualisiert im Jahr 2011. Fachleute können sich im Rahmen des OMG-Prüfungsprozesses in BPMN v2.0 zertifizieren lassen. Die OMG bietet auch Leitfäden an, die zeigen, wie die Notation in die Gruppen Ereignisse, Aktivitäten, Abläufe, Daten, Artefakte usw. unterteilt wird. Elemente werden in vier Hauptgruppen unterteilt, die als Ablaufobjekte, verbindende Objekte, Swimlanes und Artefakte bezeichnet werden. 

 

Quelle: OMG


Die Absicht von BPMN ist, technischen und geschäftlichen Benutzern zu ermöglichen, eine gemeinsame diagrammatische Sprache zu verstehen. BPMN basiert auf einer Flussdiagrammtechnik, die einer aus der Unified Modeling Language (UML) entwickelten Technik ähnelt, und kann direkt der Business Process Execution Language (BPEL) zugeordnet werden, einer XML-basierten Sprache, die verwendet wird, um Unternehmensdienstleistungen innerhalb von Webdiensten zu definieren.

Kritik an BPMN


Die Branchenmeinung ist hinsichtlich der Verwendung von BPMN für die GP-Modellierung gespalten. Kritiker argumentieren, dass BPMN viel komplexer und fortschrittlicher ist, als es für Stakeholder sein muss, die dem tatsächlichen Prozess möglicherweise nicht sehr nahe stehen. Darüber hinaus ist es bei so vielen Symbolen leicht, Fehler zu machen, was den Zweck der Verwendung verfehlt.  
Befürworter von BPMN sagen, dass die meisten Fachleute nur eine Handvoll Symbole verwenden, was die Kenntnis obskurer Symbole nicht nötig macht. Einige internationale Unternehmen erfordern die Konsistenz von BPMN, insbesondere wenn verschiedene Sprachen verwendet werden. Die Prozesse mit einer standardisierten Notation zu verstehen ist keine so große Herausforderung. 

 

Andere Arten von Notationen und Diagrammen

Im Jahr 2012 führte Cristina Venera eine Studie zweier beliebter Notationssprachen durch, BPMN und UML Activity Diagram (UML AD). Unter Fachleuten und in der Literatur stellte sie fest, dass beide Sprachen durch Stakeholder, die sich für GP-Modellierung interessieren, gleichermaßen leicht zu verstehen sind und dass beide in der Tat ähnliche Lösungen bieten. Der Unterschied bestand jedoch darin, dass BPMN (WS)BPEL zugeordnet werden kann, während UML AD nicht automatisch einer BPEL zugeordnet werden kann.  
Andere Arten von Notationen sind Event Driven Process Chain (EPC/Ereignisgesteuerte Prozesskette), Workflow-Diagramme und Mindmaps. EPC wird am häufigsten für übergeordnete Geschäftsprozesse verwendet, besteht aus fünf Elementen und Regeln und beginnt und endet immer mit einem Ereignis. Dazwischen gibt es Regeln: „OR“ (oder), „AND“ (und) oder „XOR“ (X oder), die als grafischer Connector dargestellt werden.
 

Workflow-Diagramme illustrieren Phasen und Beziehungen zwischen allen Teilen eines Unternehmens. In Workflow-Diagrammen gibt es keine vereinbarten (Standard-)Symbole. Es ist schwieriger, Modelle unterschiedlicher Abteilungen einer Organisation zu vergleichen, aber es räumt mehr Freiheit für Kreativität ein.

Mindmaps sind die am wenigsten einschränkenden der hier aufgeführten Techniken. Obwohl sie in der Regel hierarchisch sind, können sie, wenn nötig, per Hand auf einer Serviette in einer Kneipe erstellt werden. Mit Mindmaps lassen sich Beziehungen rund um ein einzelnes Konzept sowie alle Assoziationen darstellen. Sie sind in ihrem Ablauf uneingeschränkt und erlauben maximale Kreativität.

 

Quelle: Jennifer Frith

Worauf Sie bei Software für die Geschäftsprozessmodellierung achten sollten

Aus all den Expertenmeinungen und Forschungsarbeiten scheint hervorzugehen, dass es kein Tool gibt, das stets allen Bedürfnissen einer Organisation gerecht wird. Die wichtigsten Anforderungen, die an ein Tool oder eine Tool-Suite gestellt werden, sind, dass sie schnell (zu erlernen) und kostengünstig sind. Auf der BPMN-Homepage sind 74 BPMN-konforme Tools aufgelistet. Wenn BPMN-Compliance eine Anforderung ist, ist die Suche bereits eingeschränkt. Andernfalls sollten Benutzer ihre Vorgaben und Anforderungen festlegen, welche Tools ihren Anforderungen entsprechen, was die wichtigsten Kriterien sind und wofür die potenziellen Tools gebraucht werden könnten. Anschließend sollten Sie TESTEN.  Das richtige Tool zu finden ist zwar ein Prozess, aber keiner, den Sie bedauern werden.

Norbert Nogrady, Managing Director und Miteigentümer der JCM Ltd, sagt: (norbert.nogrady.bpralumni@gmail.com, Twitter: @kgordos)

 

 

“I started to reorganize organizational units more than 15 years ago. At the time, the number of available process modeling tools was very limited, much less their functionality. However, as time went by, I witnessed the evolution of such tools. In the beginning, I used large sheets, then Microsoft Word and Visio. However, I had a number of serious issues with these tools. The biggest problem is that BPR projects tend to be lengthy and thus overwhelming. The usual routine at the large corporations I worked for was (one of the following):

 

  1. Das Management hat die IT-Abteilung beauftragt, ein Tool für das Geschäftsprozessmanagement (Workflow) zu finden, das den IT-Anforderungen gerecht wird.
  2. Führungskräfte auf Managementebene erstellten mit BPR-Entwicklern ihre jeweils eigenen Prozesse.
  3. Prozessdiagramme wurden mit verschiedenen Tools erstellt.
  4. Die Prozesse wurden dann an die IT-Abteilung weitergereicht, um zu bewerten, ob die Prozesse zu dem von ihnen gewählten Workflow-System passen.
  5. Nach einer Reihe von Iterationen – die meist zu Kompromissen bei den Prozessen führten – begann die IT-Abteilung, die Prozesse in das Workflow-System zu programmieren.
  6. Die Prozesse wurden in der Organisation implementiert, mit der sofortigen Notwendigkeit, viele von ihnen zu überarbeiten.
  7. Die Punkte zwei bis sechs wurden lange wiederholt, bis ein halbwegs akzeptabler Satz an Geschäftsprozessen erstellt war.

Wie aus den obigen Schilderungen klar wird, war BPR auf diese Weise nicht einfach, sondern sehr zeit- und ressourcenaufwändig. Darüber hinaus wurde mir sehr schnell klar, dass Abteilungen ihre eigenen Prozesse erstellen sollten, anstatt mit der IT zu iterieren; so hätten eine Menge Prozesskompromisse vermieden werden können. Außerdem hat es sehr lange gedauert, die erstellten Prozesse mittels Programmierung in das Workflow-System zu implementieren. Beide Probleme haben mich so sehr gestört, dass ich nach einer Lösung suchte, die den üblichen IT-Anforderungen gerecht wird und meine BPR-Aktivitäten vollständig unterstützt.“


Nach vielen Versuchen fand Nogrady schließlich eine Lösung, die für ihn funktionierte. Nach seiner erfolgreichen Suche schlägt er vor, nach einem Workflow-System zu suchen, das über ein integriertes Prozess- und Workflow-Editor-Tool mit einer grafischen Oberfläche verfügt, was die Prozessprogrammierung obsolet macht. Der Vorteil: Sobald ein Prozess im grafischen Workflow-Editor erstellt wurde, braucht es nur einen Klick auf eine Schaltfläche, damit er sofort im Workflow-System ausgeführt wird. So können alle Abteilungen ihre eigenen Geschäftsprozesse erstellen, ohne programmieren zu müssen. Wenn Sie diesen Weg gehen, gibt es wenig bis keine Kompromisse in den Workflows und vor allem können auf diese Weise viel Zeit und Ressourcen geschont werden. Schließlich erfordert eine gute Lösung viel weniger Zeit und Mühe für das Testen der Prozesse. Auf diese Weise kann, wenn ein Prozess verbessert werden könnte, jeder in der Abteilung Vorschläge unterbreiten, und wenn der Abteilungsleiter dies genehmigt, sollte der modifizierte Prozess innerhalb weniger Stunden im Workflow-System ausführbar sein. 

Die Zukunft der Geschäftsprozessmodellierung

Ein kritischer Bereich für die Zukunft der GP-Modellierung ist die Frage, wie Modellierungsansätze standardisiert werden können. Viele Unternehmen steigen auf eine Agile-Plattform um, aber GP-Modellierung geht nicht unbedingt Hand in Hand mit Agile-Prozessen. Ein Modellierungsansatz kann nur für einige Arten von Prozessen als Agile angesehen werden, so eine aktuelle Studie von Nancy Alexopoulou.  

 

Ian Gotts, Gründer und CEO bei Elements.cloud und Kolumnist bei Digital Business, stellt ebenfalls fest: „Es gibt große Probleme im Bereich der GP-Modellierung. Anbieter von BPM-, Automatisierungs- und Workflow-Software haben BPM gekapert, so dass das B in BPM verschwunden ist. Modellierung bedeutet jetzt, Workflows der IT für die IT zu definieren. Die Prozessvisualisierung (Geschäftsprozessmodellierung) ist jedoch für Endbenutzer wertvoll. Sie verwenden die Geschäftsprozessdiagramme, um sich darauf zu einigen, wie die Arbeit erledigt wird. Das ermöglicht dann einen Blick hinter die Kulissen der IT. Dennoch ist der Versuch, die BPMN-Notation als Modell für alle zu verwenden, ein schwieriges Unterfangen; mit so vielen Symbolen sieht es verworren aus und Geschäftsleute sind schnell unzufrieden und fragen sich, warum sie das tun. 

 

“There is a notation - Universal Process Notation (UPN) -  that works for business people, that has been very successful. It is outlined in Chapter two of the e-book, Analysis, Automation & Adoption for #AwesomeAdmins. The first principle that is relevant here is that we are not building a huge flowchart, but a hierarchical process map, where every diagram is easier to follow. For example, at a bank, there may be 10,000 diagrams for all of the processes, but they are organized in a hierarchy so no diagram is overwhelming. Second, the notation is a simple model using an activity box or step with inputs and output, resources identified (or swimlanes), and hyperlinks to supporting information. This process map is useful for end users, but it is also valuable for compliance, IT, and management where metrics can be viewed in the context of a process. Using this approach is valuable for app vendors to improve adoption. An end-to-end process can make sense of the detailed flow of apps.”

Erfahren Sie mehr über die Geschäftsprozessmodellierung

Möchten Sie mehr über GP-Modellierung erfahren und wie Sie es in Ihrem Unternehmen implementieren können? Im Folgenden finden Sie Listen mit Ressourcen für weitere Informationen.


Bücher und eBooks

Whitepaper

Software

Andere Arten von Diagrammen

 

Smartsheet verbessert die Geschäftsprozesse

Befähigen Sie Ihr Team, über sich selbst hinauszuwachsen – mit einer flexiblen Plattform, die auf seine Bedürfnisse zugeschnitten ist und sich anpasst, wenn sich die Bedürfnisse ändern. Mit der Plattform von Smartsheet ist es einfach, Arbeiten von überall zu planen, zu erfassen, zu verwalten und darüber zu berichten. So helfen Sie Ihrem Team, effektiver zu sein und mehr zu schaffen. Sie können über die Schlüsselmetriken Bericht erstatten und erhalten Echtzeit-Einblicke in laufende Arbeiten durch Rollup-Berichte, Dashboards und automatisierte Workflows, mit denen Ihr Team stets miteinander verbunden und informiert ist. Es ist erstaunlich, wie viel mehr Teams in der gleichen Zeit erledigen können, wenn sie ein klares Bild von der geleisteten Arbeit haben. Testen Sie Smartsheet gleich heute kostenlos.

 

Verbinden Sie Ihre Mitarbeiter, Prozesse und Tools mit einer einfachen, benutzerfreundlichen Plattform.

Smartsheet kostenlos testen Get a Free Smartsheet Demo