Business Process Visualization

Scott Francis
Next Post
Previous Post

I’ve read a couple of articles recently related to business process visualization.  I think this topic is particularly interesting because most people think they have what they need once they buy a BI tool or a good enterprise reporting tool (and there are several that are quite good).But the thing that makes process visualization so interesting is the context of the process in which the data are generated. 

John Reynolds’ Thoughtful Programmer blog has a good post on the topic of Visualization.  In it, he makes a few great points that should resonate with anyone pursuing BPM excellence.  The dream that everyone working in a business will not just understand the activities for which they are responsible, but the role of those activities in the business processes they impact. 

It has been shown that feedback loops improve performance by focusing on how individual performance affects overall results. John also hits on another favorite of mine:  the idea that the same model should support views/layers/aspects that allow different users to understand the model and interact with it ways that are different, but compatible (and enabling).  He also references Phil Gilbert’s dream of BPM on every desk in an enterprise- which makes sense when you think how most processes are executed today – via email/paper/fax – and every single desk in an organization is involved in its business processes… they just don’t have the right tools to support the processes they execute (at least, in many cases!). So, I think John does a great job of making the case for why visualization matters. 

But I think if one hasn’t read his other posts, you might miss some of the context:  that the reason this visibility matters is precisely because of the process context.  It is the lack of context that makes using existing BI and reporting tools challenging.  You can get the data, but does your IT staff know when (in the process) to collect the data? Can the business articulate this need to IT?  Often these decisions are driven as much by convenience as by design because no one has the right answer with respect to the process.

Another issue to discuss with respect to visualization is the lack of standards.  While some vendors use very easily read/used/manipulated data formats for their process information, they are still considered to be “proprietary” formats by customers and the industry (proof that the definition of proprietary continues to evolve.  Once upon a time, just having your data accessible in a published relational database schema was considered being “open” rather than “proprietary”!  Now, if you don’t adhere to some industry standard schema you are closed or proprietary… even if such a schema doesn’t exist yet… )

This brings me to an article on The Business Process Analytics Format (BPAF).  Good read, and a good reminder that there are folks out there trying to put standardized formulations around the Business Process Data that feeds into analytics.  I’m encouraged that the format appears to be consistent/compatible with the tools I’m familiar with, but of course some of the terminology could use a BPMN overhaul (or at least a primer for those who are more familiar with other BPM* standards). For example, there is a focus on the Business Process Audit Format XML… Which has a defined Business Process Analytics Format Event. In isolation this is a good naming convention, but I think it would help everyone see the relevance if the standard also related this Audit event to where it might occur in a BPMN-defined diagram – is it a standalone event in that diagram, or is it an artifact of other items in the diagrams – and if so, which ones? Even without this context in terminology, BPAF might turn out to be important. 

After all, if you can standardize on what a measurable “event” looks like, then you can actually build analytics that are cross-vendor and consume BPAF compatible events. 

Eventually you  could have standard analytic packages… But of course the goal isn’t to have standard packages… the goal is for people who run businesses (and manage processes), to be able to visualize, comprehend, manage, and improve their processes.  That makes visualization central, if not the heart, of what will make BPM relevant to every desktop in the enterprise, even if it is dependent on delivery of executable processes to have full process context in that visualization.

  • Michael zur Muehlen

    Scott, I enjoy your blog and appreciate your thoughts on BPAF. To clarify the notion of a BPAF event:

    At the analytics level we are talking about events that are generated by the state changes of a process instances and its components (i.e., activity instances, process performers etc.) at run time. In the context of a BPMS all process activities have a common internal state model that is independent of the activity semantics. That means at runtime the activity “post invoice” and the activity “review application” both transition through states such as “ready”, “running”, and “completed”. Whenever a change from one state to the other occurs, this can be recorded as an event. These events are typically not modeled in a designed process model, but they could be used to construct one in a bottom-up fashion (through process mining).

    BPMN diagrams by nature describe processes at the model level (i.e. they can serve as a root for the instantiation of multiple instances that may follow different execution paths). The event types supported by BPMN (message, timer, complex, etc.) describe conditions under which a particular process path can be traversed (in the case of catching events), or are representations for specialized activities that result in communication activities (throwing message, signal events).

    So, in brief, BPAF events and BPMN events are described at different levels of generalization. BPAF events are instance events, while BPMN events are model events.

  • Michael zur Muehlen

    Scott, I enjoy your blog and appreciate your thoughts on BPAF. To clarify the notion of a BPAF event:

    At the analytics level we are talking about events that are generated by the state changes of a process instances and its components (i.e., activity instances, process performers etc.) at run time. In the context of a BPMS all process activities have a common internal state model that is independent of the activity semantics. That means at runtime the activity “post invoice” and the activity “review application” both transition through states such as “ready”, “running”, and “completed”. Whenever a change from one state to the other occurs, this can be recorded as an event. These events are typically not modeled in a designed process model, but they could be used to construct one in a bottom-up fashion (through process mining).

    BPMN diagrams by nature describe processes at the model level (i.e. they can serve as a root for the instantiation of multiple instances that may follow different execution paths). The event types supported by BPMN (message, timer, complex, etc.) describe conditions under which a particular process path can be traversed (in the case of catching events), or are representations for specialized activities that result in communication activities (throwing message, signal events).

    So, in brief, BPAF events and BPMN events are described at different levels of generalization. BPAF events are instance events, while BPMN events are model events.

  • Michael-

    Thanks for the very thoughtful reply – I think this is a very good summary of BPAF events as they relate to BPMN. I realize they are at different levels of generalization, but keep in mind that those BPMN models will be instantiated, and so the events that appear at the model level will become instance-level events when the process is instantiated. So I think its important to BPMS vendors to appreciate how BPAF (and BPAF events) correspond to the BPMN models their customers and process authors are likely to create.

    Equally, they’ll want to provide baked-in measurement and analysis based on these standards (I hope). Well, if not, I’m sure 3rd party tool vendors will fill the gap if BPMS tools continue to grow the market.

    Thanks again, appreciate the insights!

  • Michael-

    Thanks for the very thoughtful reply – I think this is a very good summary of BPAF events as they relate to BPMN. I realize they are at different levels of generalization, but keep in mind that those BPMN models will be instantiated, and so the events that appear at the model level will become instance-level events when the process is instantiated. So I think its important to BPMS vendors to appreciate how BPAF (and BPAF events) correspond to the BPMN models their customers and process authors are likely to create.

    Equally, they’ll want to provide baked-in measurement and analysis based on these standards (I hope). Well, if not, I’m sure 3rd party tool vendors will fill the gap if BPMS tools continue to grow the market.

    Thanks again, appreciate the insights!

  • Pingback: Column 2 : links for 2009-02-27()

  • It has been shown that feedback loops improve performance by focusing on how individual performance affects overall results.