Business Process Visualization

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.