Process Goals, Rules, Patterns and Templates
The line-up of Adam Deane’s BPM Quotes of the week is well aligned with my own subjects.
The first one is Jim Sinur of Gartner Group who wrote a blog post “Goal Driven Processes: The Future Target of BPM” in which he acknowledges the future importance of goal-oriented processes. Jim distinguishes goals driven by outcomes, policies/rules or constraints. I think this is great, while I do not fully concur with his assessment of what can constitute a process goal. As this is only future for the established BPMS vendors his perspective is understandable.
Goal-oriented processes in BPM have been pioneered by Whitestein Technologies who use goals and subgoals with defined subprocesses as a great way to simplify and rationalize the definition of conditional execution by allowing multiple happy paths. As goal orientation is a BPM design pattern, all goals, rules and constraints have to be defined before execution. It is still MUCH better than conditional execution of flowcharts with gateways.
A subprocess design pattern with or without goals focuses on HOW to do things. Allowing changes at runtime would create uncontrollable results. That is the understandable reason why BPM flowcharters see my proposal of adaptability as problematic. MY reason to use goals is to do process planning using WHY in terms of goals and leave the HOW to those who know – the participants. As an executive or manager I do not care about HOW as long as my goals are fulfilled. Goal-oriented process planning starts at the outcome.
While my approach can also plan forward by using constraints to select the best path from optional subgoals, my primary interested is to support decision-making and not replace it. Humans decide by pattern matching and related emotions but not with logic. Inferring rules is therefore nonsense and emotional computers haven’t been invented yet. But to distill some user decision knowledge from the process one can not just look at the process flows, but one must look at all patterns of data, content, structure and relationships that the human uses. Following the concepts of Gigerenzer’s ‘bounded rationality toolbox’ used by humans, I chose in 2005 a heuristic concept for un- and structured processes where the best path is determined by learning from business user decisions by means of pattern matching. Rather than automating/replacing user decisions with rule logic, I decided to see user’s applying knowledge as decision points and complex event triggers. Knowing which information to use for a decision and adding it to the process is ALSO knowledge.
One cannot add new information and thus value to a rigid process. ADAPTIVE is changing the process or any resources ad-hoc and learning from it directly by changing the template and/or decision patterns! This is done by the famous User-Trained Agent. Most ‘dynamic’ solutions allow runtime modification of the flow by adding steps or routing them to other participants. That is not adaptive.
The other widely discussed subject last week was design patterns. Goal-orientated processes with human decision points are templates for use by business people, because design patterns are for engineers. While a goal can be several things I see them as a perfect way to organize and reuse knowledge templates. A template does not have to be an end-to-end, drop-in process as has been suggested.
If the goal as outcome is defined as the completion of certain tasks then the goal is just a milestone or checklist. If the outcome is a certain measurable result then the goal is a rule defining a metric. But the outcome can also be a certain customer perception and one has to get his feedback into the process. If the goal’s tasks have to be performed in a certain sequence then it is a subprocess.
Goals are in principle rules, which means they need an embedded rule capability in the BPMS and not a separate BRE. But a rule alone makes not yet a goal-oriented process. If the goal is at the end of the playing field, it is the policies and rules that define it (boundary rules), just as the authority of players and the game rules. So policies and rules make a goal oriented process possible, but they aren’t goals.
You truly use goals if they remain the same while the subgoals, tasks, participants and resources can be added, changed, deleted during process execution. Process goals can and should be linked to operational targets and strategic objectives. There is no overall defined flow, because in reality most processes have to deal with complex business events and decision points.
But it was not just Jim Sinur who posted on goals. Last week Craig LeClair and Derek Miers of Forrester Research held a teleconference on Dynamic Case Management, in which they also presented process goals as a key element. They showed the connection between strategic objectives, operational targets and process goals in a very similar way to my recent presentations. Here is one where I show the real-time optimization loop with customer outcomes.
Another post on Adam’s list that aligns with this was Loraine Lawson and her interview with Sandra Kemsley on “BPM simplified for non-techies.” Loraine asked Sandra all the right questions.
Loraine concluded at the end: “So BPM is sort of like a traffic cop, but with really good memory.” Sandra – whose knowledge and expertize I have the utmost respect for – answered “Exactly!” I don’t agree with that answer, because BPMS is NOT a traffic cop, but a dumb traffic SEMAPHORE that doesn’t understand how much traffic there is, what time of day it is or what the weather conditions are. A traffic cop would deal with all that using his experience!
My focus in my research and software development is to create BPMS functionality that will actually empower the TRAFFIC COP with more business transparency to coordinate all the traffic lights in real-time and allow each driver to understand the current situation and chose his optimal route and goals. That is necessary because the cars aren’t robots but driven by humans who are free to decide.
Also here the subject of rules came up and I disagree with Sandra’s recommendation in the article to support BPMS with externalized business rules in a BRE. I know this a common analyst view so I don’t hold that against her. Rules make only sense DURING PROCESS execution and therefore keeping data, rules and processes is sync in different engines is a management nightmare. Having to link various systems and hard-coded applications to such a BRE backend is neither practical nor realistic to manage. Rules must furthermore be written by business users in non-technical form and verified against the process and the master data in a central repository and not coded by experts into a BRE. Embedded rules are a must for goal-orientation!
The purpose of BPMS technology is not to provide tools for the process and rule programmers, but to empower the business users to create and adapt their own processes. Not in the overly simplistic manner proposed by IBM Blueworks (ex Lombardi Blueprint) but user-adaptable templates that can contain all necessary resources in context with the process goals.
I propose a template approach for adaptive, goal-oriented processes that:
- can be created by business users by simple assembly;
- are organized in understandable goals and linked subgoals following business strategy;
- contain EVERYTHING that makes the process executable including backend data mapping;
- where goals and rules can be added by business users to a process at any time;
- can be modified where authorized and necessary at runtime;
- allow the user to react to unexpected events by adding tasks, performers or goals;
- support the user decision points that add value to the process;
- are guided and controlled by policies, rules and constraints;
- and finally, allow template modifications to be reusable by other business users.
The business user works in real-time at real business problems while the flowcharting engineer is in the dug-in trenches of process theory! I ask you, which is the better place to create a process? A business user has several times the creative and expressive power over an engineer fumbling with his large library of abstract design patterns disconnected from the business problem. The focus has to be on the performer or participant and what he can do. IBM calls them ‘contributors’ while the people who create the process are called authors. I don’t like that distinction while participants can have varying authorities based on needs. Processes are created for and by them and it must be a continuing, ongoing activity and not BPM projects with start and end-points and intermediate AGILE governance activities.
Processes have to be looked at from the viewpoint of the contributors/participants only. I am not just talking about the GUI experience and moving to mobile but about authority, goals and means – a.k.a. EMPOWERMENT! And that is surprisingly a large element in the message of Terry Schurter’s post: “Bringing the best of BPM to participants.”
Yes! We have to finally lose the ‘M’ in BPM.