Jim SinurI have gone around and around in my mind with a couple of questions. Where does a process start and what is in control of the process? The BPMS and other business process management technology vendors would say that it starts in the process, but those who are in the events business would say all process start with an event. Maybe this is like trying to count the “angels on the head of a pin”, but this is certainly worth a friendly discussion. Roy Schulte (our events guru) and I have been on both sides if the fence on this one more than once. Fortunately we are both quite calm in our debates.
![MP900448350[2]](http://blogs.gartner.com/jim_sinur/files/2010/05/WindowsLiveWriterWhereDoesaProcessStart_788AMP9004483502_2.jpg)
Processes Start with Events:
All processes have to be triggered by some initiating event. Maybe it’s a tick of a clock, and arrival of a form, a person deciding to do a piece of work. In fact most BPM tools leverage some form of event state machine inside of itself. When a state changes in a case, when a step is done, when an alarm goes off to catch the eye of the process manager, these all employ event emission and control the process. It’s all about events and events are in complete control. Pure and simple, events rule and processes seek out expected events and maybe try and catch unexpected events.
Processes Start Things Flowing;
This is hair splitting. Process have a start and control the flow with the predetermined process model, that might be fitted with some dynamic collaboration steps where work can’t be modeled completely. Case management is controlled by the change in state data and there is always an overriding high level model. While each of the individual steps might not be known, the process again is in control. Events are things that are leveraged to control the process to desirable outcomes and are subservient to processes. Sure there are unexpected events, but he process model can be tweaked to include these new events/representing exceptions unless the unexpected events obviate the need for the process and undermine the design assumptions for the process.
http://blogs.gartner.com/jim_sinur/2009/04/20/oh-process-how-do-you-flow/
I really believe that both view points have a place. There are known process snippets even in the most flexible of processes and processes can be dynamically driven by events. The new world of BPM will balance the need for both.
Category: BPM Business Process Improvement Business Rules Optimization Tags: BPM, Business Rules, events, Optimization
5 responses so far ↓
1 Jacob Ukelson May 20, 2010 at 10:08 am
Jim,
I think there are two separate issues here:
1. What starts a process?
2. Once started does the process control the events, or do the events control the process
I think that everyone would agree that processes are started by some type of event.
There is much less agreement about whether the process is in control (doing by design) or events are in control (design by doing). I would say that currently most BPM suites assume the process is in control, and only events accepted by the process can be handled – eveything else throws an exception and is handled outside the process (or just ignored). This is true even for those that handle cases – since the process is modeled apriori to its execution (either via BPMN or rules, or some combination).
The advanced case management (ACM) folks would claim that in many cases reality dictates that events (which include humans decisions) are in control making the process flow inherently unpredictable – and require a different approach, Think of a case that hasn’t been seen before – how could someone even try and model it? – the only way it can be done is via design-by-doing.
Just to make sure that people don’t think that unpredictable processes are oddbal, uncommon processes, let me pose a simple question – since most of your readers are probably knowledge workers –
How many readers think that their jobs are so predictable that it could be modeled? How many use a BPM system for their everyday work?
I’ll bet very few raise their hands… In the world of knowledge work – events (including what goes on between our ears) rule.
Jacob Ukelson – CTO ActionBase
2 Gartner: Processes start with “events”… | Complex Event Processing (CEP) Blog May 20, 2010 at 3:08 pm
[...] to see Jim Sinur post on the “event viewpoint” in his BPM [...]
3 John Bates May 20, 2010 at 3:54 pm
Hi Jim
Couldn’t resist commenting
….
Everything in life can be described with 2 simple abstractions: events and processes. Events are asynchronous occurrences; processes synchronous. So to your question – events cause processes to start and transition. Even the BPML(2) standards captures that. Process instances can’t just start. Even the universal process required the \big bang event\!!
What we at Progress have noticed in our customers’ use cases is the need for processes to go beyond the fixed set of events they know about in regular processes. It is often a requirement to extend processes’ \sensory nervous systems\ to be able to asynchronously respond to events or even \patterns in events\ in their environment. In this way \responsive process management\ (RPM) is born — which enables a more organic process that creates a deeper link between event and process. One can call this \sense and respond\. RPM adds context to events – through their relationship to the process they affect, thus adding “intelligence” to the decisions to optimize and modify the process. We’ve seen this in use cases ranging from high frequency trading processes that can respond to trading opportunities and temper themselves by monitoring their own risk — to sets of cooperating smart airline processes that know, for example, to not blindly load the plane because the pilot is delayed on another delayed flight.
John
4 Jim Sinur May 20, 2010 at 5:38 pm
Comments are most welcome. Don’t apologize
JIm Sinur
5 Bruce Levitan May 24, 2010 at 4:49 am
What’s fascinating about this debate is that as well as the process/event issue, there are other issues that affect the approach including things such as:
* Environment
* Change state
* Strategy and goals
(and there are likely to be others).
Under environment I’d include things like the degree of predictability – so the question posed by Jacob simply points to a specific environment where predictability is low; there are others where it is much higher. So I guess the issue here is that “process thinking” is more useful in some environments than others.
Under change state I’d include the drivers for looking at process. In most cases one starts to look at process because one wants to improve something – in other words the “change state” is active. In this scenario one usually identifies a process (or set of processes) to be changed, and therefore sets arbitrary (if logical) limits. So a recruitment process might start with the point when a new post is identified to be advertised (the event) – but in reality it’s part of a continuum where there was something that happened before this that caused the recruitment need to arise, and so forth. So here what I’m saying is that we create semi-artificial boundaries so that we can define processes in event-driven terms. It’s a convenient handle for planning the change. (A different approach, that is not so process-specific, is to use continuous improvement tools like capability charts which help us to continually and incrementally change the process).
Finally, under strategy and goals I’d include things like the drivers for change – these are the things that make the “change state” switch between “on” (actively looking to make a change) and “off” (business as usual). This creates a bit of a problem because it can lead to a “hunt and peck” way of making change as strategy gets reviewed and the goal-posts are moved.
I realise this may seem to be drifting away from the initial event/process issue, but I feel it’s relevant, because – as ever in a complex world – the real answer is: “it depends”! On the one hand I think this means we shouldn’t worry too much about these issues, and simply get on with the job; but on the other hand it’s useful to stand back from time to time and take stock. So thanks for raising this interesting topic.