Last time, I ventured to suggest that the value of simulation in the BPM world lies somewhere between slim and none. A number of you took issue with my comments, which was fun, because it gets awfully boring around here if we're just, you know, agreeing all the time.
In a well-considered response, software exec John Januszczak explained how he was initially put off by my position, but after taking another look, found some common ground. (John's posting was also very appealing visually--ebizq blogmasters, please take note.)
Anyway, John makes a very important point at the end of his posting:
Automation collects the data required by simulation models. [...] Simulation, when used in this way, is positioned to provide predictive capabilities for BPM systems that are extremely valuable to management. It's also consistent with the latest trends in BPM: specifically the process prediction component of process mining and prescriptive analytics answering such questions as: When will my process end?
I couldn't agree more. The only difference we have is that when one talks about collecting data from running processes, I no longer think of the resulting model as simulation, but rather as prediction. Semantics.
John thus becomes one of few BPM thought leaders I've encountered who envisions what to me seems to be the next logical step in BPM evolution: the ability to predict the behavior of a process.
- How long will this process take?
- What effect will a delay in one activity have on a later actiivity?
- Which users tend to complete this activity on time, and which do not?
- At this moment, which activities are likely to complete on time? Late? Early?
Leave a comment