BPM as “process-oriented management discipline to help an enterprise to realise its vision, by managing the flow of business activities in a holistic way thus considering together modeling (or planning), automation (or instrumentation), execution, control, measurement and optimization of business processes”. Below I illustrate a few variants of how those 6 functions can be applied.
Variant 1 – classic (one template is used for many instances)
Variant 2 – tailoring (a template is adjusted for each instance)
Variant 4 – proactive planning (similar to variant 3, but a few next activities [fragment] are executed together; whose fragments can be predefined [e.g. patterns] or designed as needed)
Variant 5 – scenario-based (similar to variant 4, but a few scenarios are considered [e.g. optimistic, realistic and pessimistic)]
1. Optimise / Reflect / Refactor + Model / Plan / Simulate + Automate / Instrument
2. Execute + Control + Measure
3. Execute + Control + Measure
4. Execute + Control + Measure
Variant 6 ...
Example for this variant is from the healthcare - thanks @Karl
Note 1 – Those illustrations show only diagrams, not all other necessary parts of the business process such as roles, rules, services, data, documents, and KPIs. Obviously, all parts have to be treated equally.
Note 2 – Ideally, some of those variants have to be intermixed within a process – selecting one of them should be easy as changing the gear.
Thanks,
AS
Posts
16 comments:
Well done. These are clear graphic representations that nicely distinguish procedural process from emergent process.
I appreciate that you seem to be broadening the definition of BPM to be inclusive of non-BPMN methods (just as Service Orientation has expanded to include REST).
An inclusive definition can reduce focus on dogma and help move industry discussions to a more practical place re: best meeting the needs of business.
Best Regards,
Dave
Great resource.
Thanks.
Alexander,
As always very elaborate and clear cut, yet I seem to miss the adaptive part that's eluded to in the headline. Also in that other post that you refer to there is a rather wholesale account of what a case can be but no specific differentiation. Is this intentional or do you plan a follow-up?
Thanks Michael.
To be adaptive, a system needs to be able to change its parts (or components) and their relationships to each other and the environment. Such a change (without talking about the reasons for it) should be done at reasonable time, with reasonable efforts and without negative side effects. A business process consists of many parts (artefacts) and relationships (see note 1). With typical BPM tools, it is possible to change (rather easily) some parts/relationships, except diagrams (or flowcharts). May be you heard about “rigid flowchart BPM model”. So, in this post I showed that BPM as a discipline has no such limitation, although some BPM tools have.
Classification of case types? I think it should be done by academic researchers.
Thanks,
AS
Alexander, thanks for the clarification. And, yes, I've heard of "flowchart rigidity".
Best,
Michael
Alexander, interesting elaboration on the dynamics of processes. It does however not really discuss the ADAPTIVE concept, meaning the feedback from the execution into templates. Emergent is not simply building a process from scratch as some might believe, but an iterative collaboration of various agents on actual process instances.
DNA is not 'designed' and then modified. It emerges and is modified during use and optimized by surviving as the most successful. I don't see that in those charts of yours.
Yes, and simply to say that all resources have to be handled the same way is nice, but not helpful. HOW is the question if it is not part of the flowchart. And REST as a protocol has no functionality for any of that at all.
Thanks for the discussion, Max.
Thanks Max,
Sure, the ADAPTIVE concept is wider than this post which is only showing that BPM (as a discipline) is not equal to “rigid processes”. A decision making process on selection of “next activity (-ies)” has not been discussed in the post (maybe this process should follow the chess thinking).
Also a bigger improvement process for collecting and, ideally, formalising the successful instances and fragments or patterns (similar to debuts, standard combinations, etc. in the chess game) is deliberately not in the post. Those illustrations are basic “mechanisms”.
Re your HOW - I consider it as how to make software-intensive process-oriented (or case-oriented) systems/applications flexible? I wrote about this already in http://improving-bpm-systems.blogspot.com/2010/01/linkedin-how-does-architecture-ensure.html
Agree about REST.
Thanks,
AS
Thanks for this big help..very informative and please keep updating as i have bookmarked!
Business Process Questionnaire
If you simply decompose BPM into one-bite kebabs to get around the inherent 'rigidity problem' of BPMN flowcharts it is fair to ask why use BPMN at all.
Using SOA to be a repository of one-bite kebabs introduces significant system complexity, indirection, latency and expense, which Alexander acknowledged in an exchange we had about six months ago.
In addition, the combination of SOA and BPM doesn't do anything to address the arms length relationship they both have with data.
I don't recall anyone saying REST in and of itself was a silver bullet, I'd be the last person to say that. While REST has its own limitations, it is a successful network architecture for link traversal, which is a form of control flow.
Instead of being dogmatic (SOA vs REST, structured vs unstructured, etc.) a good architect/engineer picks and chooses constraints based on desired properties.
We take a practical view and have developed a hybrid architecture, Resource-Oriented, not REST, that addresses limitations of SOA and REST to support information intensive processes, transactions, version-control, governance, and co-evolution of applications with the lifecycles of their constituent resources.
Hope that clarifies my position.
Dave
Alexander,
very good illustration. Your view is in refreshingly complete accordance with our own view on the topic, based on which we developed UBPML.
Concerning Max's HOW, I think the template/instance differentiation points exactly into the direction of an answer. That answer is - for better or for worse - orthogonal to the matter of feedbacking from execution.
Andreas Leue
- process terms (@template/instance):
http://wiki.ubpml.org/index.php?title=UBPML_Prozessbegriffe&setlang=en
- meta model (@HOW)
http://wiki.ubpml.org/index.php?title=UBPML_Meta_Modell&setlang=en
Great illustration...
One of the big things I like about the APG (Adaptive Process Guidance) concept is that embraces both ways of working, essentially blending traditionl BPM and ACM together, and providing greater freedom to tie a "process" to a given user objective or business goal.
This is the future for managing processes within the enterprise, why? Because that single platform can then cater for all types (variants) of process needs and therefore work across the complete enterprise. So all the benefits we associate with BPM can be exploited in all areas of our business...
Alexander, thanks for your reference to my blog posts. Much appreciated.
Even if I can make flows more dynamic at runtime they still have to be created and implemented by experts.
In terms of 'adaptiveness' you translate that to users modifying the flow of the process ad-hoc. We define adaptiveness that there is no flow at all upfront and that users can create a sequence of activities at will. These can then be looked at in terms of a historic flow and reused as a template.
In my mind that must include the runtime creation of content and rules that control the context for compliance.
As such I do not see that standard BPMN enables ACM.
Thanks Max for your comments.
As you may see i nthe post, variant 3 does not have flow up-front. I believe that it should the choice of users which variant to use in what situation - like with the gear box.
Also, we need to give to users different coordination techniques - http://improving-bpm-systems.blogspot.com/2012/07/coordination-techniques-in-bpm-social.html
BPMN is a good step forward for making BPM less vendor-driven although BPMN does not cover yet all coordination techniques which we need for ACM.
Thanks,
AS
Alex,
In this blogpost you have covered the gist of business processes without resorting to the baggage of BPM and or ACM. I like your focus on the various variants, and the way you identify the various options in each variant. Speechless, next time, I have to explain BPM, dynamic and adaptive processes and ACM - as cited in blogosphere - this blog post will be my favorite.
Is the black line suggesting the control flow or as some folks refer to it - token flow.
Identifying sequence of activities leads to a flow. You dont have to start with a flow - you can start with just an event or a task.
How great, if we (and our maintenance teams) would always have the corresponding version of the requirements available when looking at some implementation artifact?
process management bpm
Post a Comment