BPMN ist nur ein Standard für die Definition von Geschäftsprozessmodellen, nichts weiter.
Natürlich werden mit jedem neuen Standard oder mit jeder neuen Methode Hoffnungen verbunden und auch Enttäuschungen erlebt.
Hier hilft Nüchternheit.

Es ist ein Werkzeug, das für bestimmte Aufgabenstellungen nützlich sein kann und für andere Aufgabenstellungen ist es wiederum nicht nützlich. Liegt im Hammer die Zukunft? Oder doch eher in der Zange? Vielleicht in der Bohrmaschine? Für die richtige Aufgabenstellung ist jedes dieser Werkzeuge für sich nützlich. So ist es auch mit den Modellierungssprachen.
Ein Fehler sollte nicht gemacht werden: Aus einer falschen Anwendung einer Methode Rückschlüsse darauf ziehen, ob die Methode für bestimmte Aufgaben geeignet ist oder nicht. Die Methode, die man nicht falsch anwenden kann, die ist auch noch nicht erfunden worden. Zu der Nutzung einer Methode gehört darum auch immer das “Gewusst wie!”.
Zurück zur Ausgangsfrage bezüglich der Abstimmung von Fachseite mit der IT-Seite. Die Aufgabe des Modells dabei ist es Transparenz zu schaffen, die Qualität in einer frühen Phase zu sichern (und dadurch Geldverschwendung durch die IT-Umsetzung falscher Prozesse zu vermeiden), Integration zu schaffen, Struktur zu geben und letztendlich eine höhere Stufe der Flexibiltät zu erreichen (sprich es geht schneller, wenn ein Ablauf geändert werden muss als vorher ohne Modell).

Alles in ein Modell ist sicher falsch dabei. Ein Beispiel: Ein Modell sollte nicht wesentlich mehr als um die 7 Aktivitäten beinhalten. Warum das? Weil der menschliche Geist umgefähr 7 Dinge gleichzeitig erkennen kann. Übersteigt ein Modell die Anzahl dieser Modellierungselemente wesentlich, dann wird es als verwirrend und unübersichtlich wahrgenommen. Sie glauben das ist nicht möglich? Natürlich ist es möglich. Dazu muss das Modell nur entsprechend strukturiert werden. Dazu dienen zum Beispiel die Möglichkeiten der Sub-Prozesse in BPMN.
Zudem beleuchten verschiedene Modelltypen verschiedene Aspekte des gleichen Prozesses.
Nehmen Sie zum Beispiel das Konversationsmodell

Siehe dazu auch dieses Kurzvideo:

Hier kann man mit nur drei Modellierungselementen eine gute Übersicht über eine Prozesslandschaft erstellen und der ganzen Modell-Landschaft die richtige Struktur geben. Von dort aus ist es dann möglich in weitere Ebenen darunter zu drillen.

Ein weiterer Punkt ist, dass Fachseite und IT-Seite unterschiedliche Informationsbedürfnisse haben. Die Fachseite interessiert sich mehr dafür, welche Geschäftsdokumente (Auftrag, Lieferung, Rechnung, …) wann wie erzeugt und bearbeitet werden und wer dafür verantwortlich ist. Die IT-Seite interessiert sich mehr für die Strukturierung der Anwendungen (Schnittstellen) und für die Sonderfälle (Stornierung, Änderungen im laufenden Prozess). Natürlich muss auch die Fachseite diese Fragen nach den Sonderfällen im Prozess mit beantworten, nicht aber die Strukturierung der Anwendungen (Schnittstellen). Hier kommt es darauf an, verschiedene Modelle mit verschiedenen Details des gleichen Prozesses zu machen.

Sprich es ergibt sich eine Modell-Landschaft, die aber untereinander verbunden ist. Änderungen, die sich in einem Modell ergeben können – das richtige Tool vorausgesetzt – dann leicht in anderen Modellteilen nachvollzogen werden, da es für die entsprechenden Elemente (Geschäftsobjekte) Verwendungsnachweise gibt – also die Auskunft in welchem anderen Modell dieses Geschäftsobjekt – das jetzt geändert werden soll – ebenfalls vorhanden ist, und das damit ggf. ebenfalls angepasst werden muss. Diese Möglichkeiten wurden erst durch das BPMN Metamodell erschaffen.
Diese Änderungen wiederum sollten natürlich, vor allem wenn es eine größere Modell-Landschaft ist, einem Reviewprozess unterworfen sein. Gerade der ordentliche Reviewprozess wird oft gerne vernachlässigt. Man denkt: Naja – wir reden eben schnell einmal darüber oder wir machen einen Workshop. Da kommt es oft zu mehr Missverständnissen als Lösungen. Ein strukturierter Reviewprozess sorgt dafür, dass bei jeder relevanten Änderung, die Einfluss auf andere Bereiche hat, den entsprechenden Stakeholder eine Reviewphase zugebilligt wird, offene Punkte formuliert werden, und diese strukturiert abgearbeitet werden. Das ist in der Summe weniger aufwändig, als es “Auf Zuruf” zu machen, weil eben viele Missverständnisse vermieden und von Anfang an ausgeschlossen werden. Es gibt auch keine Modellierungsmethode der Welt, die einen solchen Prozess überflüssig macht, wenn die Aufgabenstellung eben entsprechend groß ist. Für kleinere Aufgaben kann der Reviewprozess natürlich schlanker sein – das ist klar.

Im Reviewprozess wird ein Leitfaden zugrunde gelegt. Dieser Leitfaden wird für ein spezifisches Projekt maßgeschneidert erstellt und legt die Regeln fest. Die Regeln besagen, welche Modellierungselemente für welche Ebene des Modells erlaubt sich und welche nicht. Das generell und allgemeingültig festzulegen ist nicht sinnvoll, da es immer vom Projekt abhängt und von der Aufgabenstellung, die das Projekt erfüllen muss. Natürlich gibt es einige Gemeinsamkeiten mit anderen Projekten. Jedenfalls ist der Leitfaden die wesentliche Grundlage dafür, welche Modellierungselemente zu Einsatz kommen. Das vom Standard zu erwarten heißt, den Standard zu überfordern. Der Standard hat schon einige solcher Regeln bereits festgelegt, aber eben genug Freiraum gelassen, damit sowohl die Bedürfnisse der Fachseiten als auch die der IT-Seiten berücksichtigt werden können.
Ob BPMN zu viele Modellierungselemente hat? Ich sage einmal so: 20% der Elemente werden in 80% der Fällen verwendet. Und das ist auch gut so. Ich halte einige der Elemente ebenfalls für überflüssig oder warne sogar vor deren Einsatz. Aber viele sind auch gut, und gerade mit BPMN 2.0 sind wieder sehr gute neue Modellierungsmöglichkeiten dazu gekommen, die beispielsweise viel Transparenz in B2B Prozesse bringen können.  Was auch wichtig ist: Die Fachseite vesteht konkrete Modellierungselemente viel besser als abstrakte. Konkret ist beispielsweise: Datenobjekte (Geschäftsobjekt wie Rechnung, Bestelltung, Lieferung, …), der Status eines Datennobjektes (Offen, Erledigt, In Bearbeitung, Genehmigt, Bezahlt, …) die Aktivität (wie Freigeben, Genehmigen, …) als auch eine Rolle (Einkäufer, Gruppenleiter, …). Ich hatte noch nie und bei niemandem Probleme mit der intuitiven Verständlichkeit eines solche Modells. Intuitiv heißt hier: Ohne Schulung. Schlechter verstanden werden dagegen abstrakte Modellierungselemente wie Gateways, Events, etc. pp.  Ungefähr in der Mitte sind Nachrichten und Nachrichtenflüsse. Es ist die Aufgabe des Leitfadens, den Einsatz der Modellierungselemente dahingehend zu regeln.

Man darf nicht die Leistung, die man eigentlich von einem ordentlichen Reviewprozess erwarten muss, von der Methode erwarten.
Ist BPMN die Zukunft? Ich sage: Es ist im Moment sehr nützlich, wenn es richtig – also für den richtigen Zweck und auf die richtige Weise – eingesetzt wird. Und dazu gehört definitiv die Abstimmung zwischen Fachseite und IT.

If we take for example (Allweyer, 2009) chapter 2 we find a first simple BPMN model in figure 1 (translated by me). There is a remarkable statement about this model.

In practice the process of creation and publication of a job post can be much more complex and considerably larger. This model is a strong simplification – as all models in this book are. The purpose is to have clearly arranged models in order to be able to well explain the BPMN modeling elements. (Allweyer, 2009) – Translation by me.

What can we conclude from this? Can we conclude that if BPMN models reflect the full lifecycle and variants of a real job post creation and publication the models are too big and complex to be arranged clearly?

Well – I know the difference between a real modeling project and a didactical book chapter or training. I am giving training myself and therefore simplification for didactical reasons has my full sympathy.

But still it is a remarkable statement, if we think about it for a moment.

Adaptive Process Modeling would state it differently. Adaptive Process modeling would say:

What are the real requirements of the full lifecycle of the creation and publication of a job post including all variants and complexities? How can this be modeled in a simple, concise way? How can the resulting model be free of unnecessary repetitions? How can the model be easy to maintain? Which of the BPMN modeling elements can or must we use for that purpose (and which do we not use)? How do we combine these elements, which rules (or style) govern the composition of these elements to models that fulfill these criteria?

It is a different question and a different approach. Just to make one example: An adaptive process model would always contain data objects (without or with state). Why is this so important? I leave the answer to this question to another post. An adaptive model tries to avoid all the problems that come with tokens and gateways. Tokens and gateways are extensively discussed in chapter 2 and 3 of (Allweyer, 2009). You can see there what happens if a two start tokens are created and run through the process, how tokens are duplicated by gateways, how they circle around in loops and make the whole model very difficult.

The basic flaw of most process models is this: There are two ways of capturing process state:

1. Tokens running through a process.
2. The state of data objects that are used in or are part of the process

Alternative 2) is by far the better way of capturing process state. It is more natural to say the job posting is approved, than to have an artificial invisible token in a sequence flow line after an activity “approve job posting”. It makes models much simpler, cleaner and concise. Why is this? Because the result of a task is much more important that the task itself. This gives much more flexibility to a process. Why? Because there can be many ways to achieve the same result, and many ways to use the result (the approved job posting for example). In token flow, all of these variants have to be combined into chains and this makes a model complex. Modeling the data object and it`s state is a natural way to decouple parts of a process and adding a point of flexibility.

Notwithstanding 95% of the models I see try to solve their problems with method 1). Why is this so? I do not know. Probably data objects and their state are not considered as part of the process. This is a great error. Actually we need to establish an understanding in which data objects and their states are completely part of the process just as activities are.

And this leads us into the direction of Adaptive Case Management as well. Because Adaptive Case Management is said to be a goal oriented way of modeling instead of a task oriented way of modeling. So the result counts more that the tasks, that lead to the result. The goal in ACM is to achieve a certain result. Just as with data objects and their state. We can say goal oriented modeling, result oriented modeling or data object state oriented modeling. In the end it is very similar.

I teach these principles in (Kraft, 2011).

References

Allweyer, T. (2009). BPMN 2.0 – Business Process Model and Notation: Einführung in den Standard für die Geschäftsprozessmodellierung. Books on Demand.

Kraft, F. M. (2011). Training: BPMN 2.0 smart anwenden. Retrieved from http://www.adapro.eu/site/seminar/sem-bpmn

Also many people ask me: What is the relationship between BPMN and Adaptive Processes and Adaptive Case Management?

BPMN is standardized modeling notation and meta model for modeling business processes. It defines modeling elements, their relationships, attributes and their execution semantics – i.e. what happens if the model is loaded into a workflow engine. Modeling tools and workflow engines can be built based on this specification – and in fact many are. Training of BPMN mainly is learning the modeling elements, their meaning and also how to use then in context – i.e. how to solve some modeling problems with them – as for example in (Allweyer, 2009). Some go further and propagate a certain style of using BPMN, as for example the famous Bruce Silver (Silver, 2009). It is always limited to the BPMN syntax and semantic – i.e. the definition of BPMN modeling elements and the execution semantics. On the other hand, Bruce Silver claims, that if people follow his style, then their BPMN models will be in a certain sense “better” than other BPMN models, that is they fulfill more quality criteria than “just BPMN” models. For that the Bruce Silver style defines additional recommendations and rules that go beyond the BPMN syntax and semantic rules.

Adaptive Processes is a paradigm, that takes a step back and looks at all of this and asks: “Wait a moment – what are we doing here? Is this working? If not, why not? And what can or must be done in a different – better – way?” In that sense Adaptive Processes is not limited to BPMN syntax and semantics. Adaptive Processes is allowed to take any modeling language or even invent a new one, if the solution to modeling problems is better. Adaptive Processes can utilize BPMN plus other process modeling languages, but is not limited to that. It can and does also take elements from SOA and from data modeling like UML. At the same time Adaptive Processes shapes a modeling style for using each of these modeling languages individually and together. It defines a certain style to use BPMN, SOA, UML or more and all of them together. In that sense Adaptive Processes is a BPMN style, yes. It is not the Bruce Silver style. It is a different style. But yes, some of Bruce’s recommendations and rules conform to Adaptive Processes, while others won`t.

What does that mean for BPMN modeling? That means if someone just draws a BPMN model, it is nearly sure, that it is not adaptive. This is the case from the first model. And in fact, if I look into BPMN books that are around even the first models are not adaptive. This is not to blame anybody, because Adaptive Processes of course is an innovation, the result of a steep learning curve of us process experts.

But at the same time Adaptive Processes questions the limitations of BPMN and some of its basic meta model flaws. Of course the Adaptive Process BPMN style tries to avoid these flaws – for example by not allowing certain modeling elements, or by recommendations or rules as of how to use the modeling elements more effectively. But in the end the result will always be limited to what BPMN is able to do. Therefore new modeling languages are being invented, that have the Adaptive gene from the beginning. This currently is an ongoing process and currently it is not standardized as of yet. Different companies propose different solutions and so does AdaPro. After some time these will be standardized. Then I expect that we will have a new process modeling language that is – as I said – adaptive from the beginning. If this is the case, then a mapping can be defined from BPMN to the adaptive modeling language and vice versa. And guess what – the mapping will be easy if people stuck to the Adaptive Process BPMN modeling style, and it will be difficult or impossible, if they haven’t. So if I propagate the Adaptive Process modeling style, then I am anticipating what is coming as a new standard in the future for modeling business processes.

That is why I can propagate a certain BPMN modeling style and criticize BPMN at the same time – which seems paradox. But with this explanation it is not.

I intent to discuss certain models from current literature, show their limitations and problems and by this make clear, why we need Adaptive Processes. It will then be up to you to decide, if you subscribe the Adaptive Process philosophy. I want to be very open about this. It is a yes – no decision. If you decide no – then you will have more freedom to use BPMN, but also more problems as I will argue. If you subscribe to it, it is best done before your modeling project begins. Yes, it is also possible to remodel an existing landscape to be adaptive, but it is clearly more effort than if it is done from the beginning. On the other hand it solves problems you have with your current model landscape that you thought were impossible to solve.

I have experienced this with many clients. Unconsciously the models become simpler, less spaghetti-style and less repetitions, easier to maintain. Often people don`t even know that I teach them the adaptive style, and I don`t tell them if they do not want to know. But I tell you, because I want to establish and argue for the adaptive style, convince you so that you are prepared for the things to come.

Works Cited

Allweyer, T. (2009). BPMN 2.0 – Business Process Model and Notation: Einführung in den Standard für die Geschäftsprozessmodellierung. Books on Demand.

Silver, B. (2009). Bpmn Method and Style: A Levels-Based Methodology for Bpm Process Modeling and Improvement Using Bpmn 2.0. Cody-Cassidy Press .

This in my eyes is an encouraging sign that the ideas and concepts of Adaptive Case Management are being picked up and replicated.

There is an introduction about Taylorism in office work and their effects on BPM, especially the unfitness of this philosophy for the knowledge worker. They argue as we do in (Swenson, et al., 2010) that this is the reason, why BPM is not as pervasive as initially expected by experts. My thoughts on Taylorism have been published here.

BPM is currently limited to repetitive and well-structured processes and they say only within organization units (as opposed to cross many organization units). Processes like on-boarding of new employees as they write, with many approvals on many levels of management.

They propose to define BPM as consisting of normative BPM (nBPM) and adaptive BPM (aBPM) from now on, where aBPM covers all the new requirements and capabilities that come with Adaptive Case Management. I am happy that this is perfectly in line of what I proposed here , where I already proposed the Term ABPM. It makes sense to define the “rest” of BPM with another term and I like the term normative BPM, I can agree to this. Both are tools in the toolbox that are used for the right purpose – we are in perfect agreement on this.

Later in the article, the authors show a model of a process that is an example for the limitations of classical (normative) process modeling.

Figure 1 Insurance Claim Process from (Maier, et al., 2012) – translated to english

I want to elaborate a little bit in this post on what are exactly the limitations.

The first gateway is an inclusive gateway, meaning one of both paths is chosen, depending on what is necessary. This is certainly something a knowledge worker wants. But I must remember, that a BPMN model has a clearly defined execution semantics, meaning that if this model is loaded into any workflow engine, then the workflow engine executes the process according to this semantics – which is a token flow semantics. In other words, only those tasks appear on the screen, which are activated by the token. Based on that execution semantics, it is possible to simulate such a behavior. So let us do this. For this I am using the new BPMN token flow simulation tool from Prof. Allweyer. For that I must tweak the model a little bit, because the tool currently does not support ad-hoc tasks. I just remove the ad-hoc attribute from the two expanded sub-processes “Customer Service” and “Claims Processing”. The execution semantics is still the same.

A token is marked as a star in the model.

Figure 2 Token before Inclusive Gateway

The first problem we see in Figure 2 and Figure 3. The data-based gateway (and the inclusive gateway is a data-based gateway) is defined in a way, that the decision must be done as soon as the token reaches the gateway. That means, before the decision the token is before the gateway as in Figure 2, and after the decision the token is after the gateway as in Figure 3.

Also the semantics is that the decision must be made based on data from the process. Where is this data coming from? What is the role of the knowledge worker here? But let this be only a side remark.

Figure 3 Token after decision of Inclusive Gateway

Suffice it to say that after the decision has been made, it cannot be revised. If the token is after the gateway, then it is not possible to activate the other branch, like “Customer Service”. Yes, because it is an inclusive gateway, the decision could have been to send the token into both paths. But inclusive also allows for only one path. So if the decision is done, it is irrevocable. And the decision is already irrevocable, before even the first succeeding activity has been started. This is not how knowledge workers work.

I call this pattern of knowledge work “The XOR lie” in (Kraft, 2012). Ok – if I consider the inclusive gateway I should name it “The gateway lie” – but the argument is the same. Adaptive Case Management is not bound to the gateway lie. It is more flexible. In (Kraft, 2012) I explain this in more detail. My point here is only to explain the problem.

Figure 4 Token in Ad-Hoc Sub-Process “Claims Processing”

There is another problem with the model in the ad-hoc part. As we see in Figure 4 all tasks of the ad-hoc sub-process are activated, as soon as the token reaches the ad-hoc sub-process “Claims Processing”. But as soon as the token leaves “Claims Processing” – as in Figure 5, none of the tasks is active. What does that mean? That means, that the tasks of “Claims Processing” can be executed as long as the token is there. The knowledge worker can decide which task he executes, and he can decide the sequence in which the tasks are executed. But as soon as the token leaves “Claims Processing” it is over. Finishing “Claims Processing” is irrevocable. What is there is delayed Case based information collected, which does influence the whole case? It is not possible in this process to reopen the Claims Processing again. That is because the decision to finish it is irrevocable. That is not how Knowledge Workers work.

Figure 5 Token after “Claims Processing”

Also there is another caveat in this type of model. Only those activities can be processed in the process (i.e. tracked in the workflow system) that have been modeled in advance. For example it is not possible in this model to include something like “get mangers advice about case”. Yes – the knowledge worker can always ask his manager – even without the workflow system. But the task cannot be tracked. This is how knowledge work is done today – just do it without workflow system. Send and Email, phone, meet. Whatever. But what we want is, that the new task is also tracked, even if it was not preplanned. The knowledge worker wants to collaborate with is manager over this task, referencing all case information in the Adaptive Case Management System (that is available already) plus adding some special information for the task as attachment to the task, forward the link to the task, search it, estimate how long it takes, see if the deadline can still be met, see a statistics in which can be seen how many cases of a certain type needed manager`s advice and so on – in one word: Manage the task. That is why it is called Adaptive Case Management.

So with this model – and by this with any workflow engine that uses this model – it is not possible to manage tasks, which have not been modeled before. That is not how Knowledge Workers work.

If this model was to be transformed to an adaptive model, then It would be necessary to model also data objects and their state, which is absolutely vital in every adaptive process. The model does not have a data object modeled (“Claim”) not their state ([Incoming], [Evaluated], [Not Relevant], [Assinged], [Released], [Paid], [Rejected], [Closed]). Adaptive Processes are not merely tasks. Adaptive Processes are the wedding between task and data – between business processes and business objects. Furthermore as we can see this model is task-oriented instead of goal-oriented.

So this model demonstrates very good the current limitations of classical (normative) modeling if we try to capture adaptive processes with classical means. Thereby fundamental principles of adaptive processes are violated:

These are:

1. Goal-Oriented instead of task-oriented.
2. Not fully prescribed – individual processes.
3. Changes in the running process
4. A clear status of the business object

It is important to understand this, because then it becomes clear why Adaptive Case Management is something really new – something revolutionary. Not just using current technology in a slightly different way.

The authors and me are in perfect agreement about these facts. That is why they made this model as an exampel of the limitations of normative process modeling with regards to adaptive processes.

Of course it is a pity, that there is currently not yet an internationally standardized graphical notation for Adaptive Case Management models, as with BPMN. Not yet. I must emphasize that there is still some work to do, before this can be achieved. But it is on the way.

The article closes with stating, that currently there is no standard software supporting Adaptive Case Management. While I agree that it is a young discipline, and software is currently being developmed by different companies, there are some companies, that offer ACM. IBM, Isis Papyrus and last but not least of course AdaPro offers standard software for Adaptive Case Management – and these are not all. Some of them are in pilot mode, others in productive.

So we can see that now the train of Adaptive Case Management and Adaptive Processes in general is picking up speed, the requirement for managing unstructured processes is now recognized and confirmed, and the discussion how this can be achieved reaches the BPM and SOA communities around the globe as well as in Germany. I am happy to see that and I am sure, that by honestly analyzing the problems of current technology and proposing better solutions this will revolutionize the realm of process management.

References

Kraft, F. M. (2012). Adaptive Case Management – On-Demand Training. Retrieved from AdaPro: http://www.adapro.eu/site/seminar/sem-acm-on-demand/

Maier, B., Normann, H., Scheithauer, G., Schmiedel, D., Kress, J., Utschig-Utschig, C., et al. (2012, 03). BPM: Annäherung statt normativer Prozesse. Computerwoche, pp. 32-34.

Swenson, K. D., Jacob P. Ukelson, J. T., Khoyi, D., Kraft, F. M., McCauley, D., Palmer, N., et al. (2010). Mastering the Unpredictable. Tampa, FL, USA: Meghan-Kiffer Press.

Folgendes 4:30h On Demand Video Seminar enthält hochkarätiges Wissen über Adaptive Case Management:

http://www.semigator.de/schulungen/Adaptive-Case-Management-On-Demand-Videos-1403025-0

Lernziele
* Was ist “Adaptive Case Management”?
* Technologie des Adaptive Case Management
* 20+ Muster der Wissensarbeit
* Wie arbeitet Adaptive Case Management mit BPMN zusammen?
* Praktische Demos am System
* Die Bücher “Mastering the Unpredictable” und “Taming the Unpredictable”
* Allgemeingültige Kriterien zur Beurteilung von Adaptive Case Managementsystemen.

Termine und Orte

17. April 14:00 Uhr bis 18:00 Uhr in München. [Buchen]

New Capabilities with BPMN 2.0 from AdaPro GmbH on Vimeo.

I know there are more new things like the metamodel, additions on executeable BPMN and other changes like non-interrupting events. But for me the most important innovation is what I describe in the video – and most important what you can do with it.

And yes, I know that BPMN 2.0 is around for some month. However these new capabilities still wait to be exploited. They are only used very rarely – if they are used at all currently.

Please also help me understand which BPMN 2.0 offerings you would like to see by voting or adding a new idea to the BPMN 2.0 Offerings Wishlist.

Neue Möglichkeiten mit BPMN 2.0 from AdaPro GmbH on Vimeo.

Short description

The training explains how BPMN 2.0 can be used for these purposes: “documentation”, “specification”, “model execution” and “model driven development”. The goals for modeling are transparency, integration and flexibility.

The model types of BPMN 2.0 and their purpose-driven application will be explained. You will learn how to use the right modeling elements for the right purpose. You will learn how to assure the quality of the models and how a guideline will support your model creation.

The guideline taught in this training has been proven to achieve short modeling project duration and high customer satisfaction even for difficult modeling tasks. It is based on deep experience in the bpm modeling space and in bpm mentoring.

The training will be in german.

Dates, Locations, Registration and Details:

http://www.adapro.eu/site/seminar/SEM-BPMN

He argues, that taylorism is good, because it makes work effective, predictive and scalable – which are in essence the same arguments that Taylor himself brought up – that´s why it is called “Taylorism”.

My answer to this is: It depends. Taylorism is not a good thing per se nor a bad thing per se. It is a good tool if it is used for the right purpose but it is a bad tool, if it is used for the wrong purpose. Take for example physical production of goods – cars, machines and jewelry for example. The production of these typically follow different production types. Cars are typically produced with the production type of line production (Linienfertigung) (this is where all the “Toyota production system” and “Lean Production” ideas come from). Machines are typically produced in job shop production (Werkstattfertigung) and jewelry is typically produced in manufacturing production (Manufakturfertigung). All of these production types follow different rules and management principles. The key is to use the right tool for the right type of product. It is not right to conclude from the fact that line production is good for cars that it is good for jewelry as well.

Now in the area of business process management we are talking in most part about intellectual work or brain work – not so much about physical production. We cannot conclude that if a management style is good for physical production that it is good for brain work as well. Also within brain work we have different types of work that require different styles of work. We cannot conclude that if a work style is good for one kind of brain work, that it is good for the other as well. We need to differentiate.

Yes, the discussions about Adaptive Case Management versus classical Business Process Management are sometimes heated – but I think this is fine. Sometimes it may sound like: “ACM is the only thing” – no – “BPM is the only thing”. Both is not true. It depends. So far we only had BPM and no ACM. So far we tend to see every problem as a nail because we only had a hammer. No – BPM is not the answer to every process management problem; especially not for knowledge work. So far there was no other solution. Now we have ACM – the new kid in town. Now we have more tools available and we are able to address more types of processes that we were able to address before.

BPM itself is a technology to make processes more flexible than – standard software. So BPM is more flexible than standard software and ACM is more flexible than BPM. We need all of the three. No one claims that we do not need standard software in the future. Nor anyone claims that we do not need BPM in the future – at least no one I know. But yes – we claim that we also need ACM in the future. It depends on the type of work. Knowledge work is clearly ACM. But there will also and in the future a lot of routine work that is best done by BPM or by standard software. In routine work effectiveness, predictiveness and scalability are the main attributes. But in knowledge work it is not. In Knowledge work problem solution, creativity and flexibility and goal achievement are the main attributes. These contradict with effectiveness, predictiveness and scalability to some degree. There are always work types that are kind of “in the middle”. For example customer problem processing. Who is more effective? The worker that solves 5 very easy customer problems per hour; or the one that solves a very difficult customer problem in three days? See – it is just wrong to measure work only by throughput.

So my claim is: The right type of tool for the right type of work.

It also depends on the degree of process maturity. If a process is immature – and we always have immature processes if we have innovation – then it is less predictable than a process that is mature. If it is a mature process, it is predictable and scalable.

This is why mature processes can be implemented in ERP Systems, half-mature processes can be modeled with workflow and immature processes cannot. However – now they can be managed by using ACM. In my view it is obvious that there are far more immature processes than there are mature processes. A typical employee has far more emails in his inbox than workflow items. Most of the emails represent knowledge worker processes – processes for ACM.

And – what we need is a “process funnel” – as I tried to depict in the diagram. That is – a process that today is a completely unmanaged process (only by email) should become an ACM managed process. After a while – if it is a mature process – it can become a BPM managed process (for example by exporting it from an ACM system and importing it into a BPM system). After a while – if the process has further matured – it may become part of an ERP system. This approach has the advantage that each step is easier than doing the whole thing from scratch. And only proven processes become part of the mature process landscape. But even then there will be new more unpredictable processes – and that is a good thing. Because they spawn creativity, challenge, competition, achievement and all things that make life interesting and companies flourishing.

An important aspect to this is, that the seamless integration best works if all of those levels follow some basic rules, that I call rules of adaptive processes (that covers more than just adaptive case management). I work to promote the concept of adaptive processes that is a holistic approach to the whole process landscape – be they standard processes, workflows or adaptive case processes – and makes all levels fit to each other.