Unstructured, Semi-Structured and Structured Processes makes a distinction between
- structured,
- unstructured and
- semi-structured
processes, that I like. It is interesting, that in the definition of process the emphasis on the post is less on the sequence of activities, but more on the business goal to reach. That was, what I proposed earlier. And it makes sense. In the end it is more important, what the result of a process is, than what has been done or should be done in which order to try to (!) achieve it. I said “try to” because sometimes just doing a thing can not guarantee that the desired result is achieved. That’s why I say that the result is more important than the doing of an activity or task itself.
Of course it is inevitable that when a business process is implemented in an business process platform, that it is structured. Otherwise it is impossible to implement the business functionality that transforms the business objects that are part of the business process from one state to another. That is said modulo that there may be some generic functionality like a process engine for workflow or generally for execution of modeled process parts of course.
BPMN supports some Ad-Hoc modeling cababilities. There are Ad-Hoc tasks where the sequence is not defined or where it is not defined if none, one or all of them are executed. However one would expect, that any task that can be executed is modeled – at least if it is not, it can not be system supported. Also it is a difference, if the Ad-Hoc cababilities are on the process type level, or on the instance level, meaning that a concrete process instance can be adapted to a new, unexpected flow, sequence or even new Ad-Hoc Tasks.
However the more the tasks become Ad-Hoc the more they become an empty shell. What do I mean by this?
Create an Ad-Hoc task “Calculate stock losses based on financial crisis”. Of course if this is done the first time, there is no busines logic implementation for this. Even if there is a SOA service offering the solution, there needs to be some implementation of calling the service, which means gathering and providing the needed parameters and using the result in other processes.
So – as soon as a process is implemented in a business process platform it has at least some constraints.
Which is ok – because it has been formalized, because it’s execution is more repetitive.
On the other hand especially in times of crisis the importance of Ad-Hoc processes grows to account for the need to compensate unforeseen difficulties in the daily “business as usual”.
The important thing is, that the structured, the unstructured and the semi-structured processes can be integrated as seamless as possible. This is only possible, if there is a common notion of result of a process or of an activity in the process. Furthermore it is an interesting question – especially in semi-structured processes – how much constraints are desribed.
- None Constraints: Unstructured.
- Some Constraints: Semi-Structured.
- All Constraints: Structured.
[ad]
As a general consideration the underlying problem discussed in the executable modeling debate is this: If Process Modeling is done, there are different purposes for it, as I already stated:
http://www.bpmnforum.net/blog/bpmn/bpmn-in-practice/process-modeling-purpose/
and
http://www.bpmnforum.net/blog/bpmn/bpmn-in-practice/more-on-modeling-purpose/
And yes – most BPMN models today are done for documentation purposes. But ImhO this is quite natural.
BPMN modeling is always done with a purpose. It is done or is most prudently done within a context of a BPM strategy that includes a BPM transformation. For a discussion about this see for example (1). One part of this BPM transformation is the as-is modeling of processes – for which a process documentation is needed. So in such a phase BPMN can serve as the as-is analysis modeling language – which it mostly does as of today. But that is not the whole purpose of the BPM transformation. It is a first step. The subsequent steps are shall-be process design and realization of the shall-be process. The realization is not necessarily done or always done with IT systems. But even for a process execution within a non-IT context consistency and completeness of a process model makes sense. Furthermore the more a process model goes into being the foundation of an IT realization, the more it must become executable – or at least be usable for development and ideally for model driven development. Therefore as the maturity of BPM transformations is progressing with time, the importance of the executable modeling aspect increase.
Bibliography
1. Snabe, Jim Hagemann, et al. Business Process Management – the SAP Roadmap. Bonn, Boston : Galileo Press Inc., 2009. ISBN 978-1-59229-231-8.
[ad]
There have been complaints, that BPMN 2.0 is only designed with the goal of defining an executable process modeling language and that this impairs the usage of the modeling language for the purposes that it is currently most often used for: documentation.
http://www.brsilver.com/wordpress/2009/01/19/bpmn-20-update/
The complaint is that a model would not be counted as valid, if it is not executable. The demand is that it should also be valid, if it is not executable.
To shed some more light on the issue it is necessary to discuss several aspects. These come to my mind immediately:
- Choreography Modeling and Execution
- The concept of enforceability
- Conformance
- Abstract Processes
Ad 1) A new feature in BPMN 2.0 is the choreography model. Modeling a choreography model with BPMN 2.0 means modeling an abstract process representing the view of an independent observer on the exchange of the messages that are exchanged between participants. This process is by definition abstract, because it is “in the middle between” the participants. So by definition such a process can never be executed directly or be executable. It can only be realized by means of processes within the participants. But the realization is not necessary for a choreography model to be valid.
Ad 2) Enforceability of a choreography process is an attribute, that holds true, if a choreography model can be realized at all. Not all choreography models are able to be realized. This is completely independent of any technology. It is because of logic only. To make an example If we define this process between John, Mark and Jane, which are in different cities: First John calls Mark and tells him the weather. Then after this Jane calls Mark and they plan the weekend trip. This process is not enforceable. Because Jane cannot know when John has called Mark. So to make the process enforceable, John or Mark need to call Jane to tell her, that John and Mark have phoned. Which of both is better is another thing – but the first process is not enforceable – completely independent of the technology.
So yes, there are some rules in BPMN 2.0 Choreography model that must be kept with a choreography process so that the enforceability is not destroyed. But this has merely logical reasons.
Ad 3) There is a difference between Process Modeling Conformance and Process Execution Conformance. Process Modeling Conformance does explicitly not require that the Process Execution Semantics is kept. However the Process Execution Semantics is most clearly defined. But because this is optional, it is only for those who want to execute. And for those, an execution semantics is very helpful.
Ad 4) Abstract Processes are Processes that have the process type abstract. By definition they are not executed as is, but they are an abstraction of the process, that is really executed.
Good discussion though and I might continue to post on this.
