A by-product of automating work is the records is made that indicate precisely when each task is started and completed. Analytic information about how your organization is working can actually be far more valuable than the cost savings derived from the automation. A lot can be learned from this analysis that can help you improve your organization. Some claim that this is the principle benefit of BPM.
In an earlier post, I introduced the concept of a “Model Preserving Strategy” versus a “Model Transforming Strategy” and defined them as two approaches that a BPMS can take in the lifecycle of a business process. This post delves into how process analytics are effected by model strategy.The raw data consists of records of when an activity within a process changes state. For example, a record is made when an activity starts, and another when the activity ends. There can be other records if the activity goes through other internal states. Business managers want to know how long an activity typically takes. This is calculated as the difference between the start time and the end time.
Model Transforming Strategy
When a model is transformed, the activities within a process are replaced with activities that are appropriate for another domain. In the business domain you may want an activity to represent the review and approval of a document. In the system domain there is an activity for retrieving the document, an activity for sending an alert message, an activity for a possible reminder message, and an activity to sit and wait for the response. In other cases, multiple steps at the business level may be consolidated into a single step at the system domain.
The transformation is not trivial because there are logic constraints in each domain that may not be compatible. The business level may allow unbounded loops, while the system level requires strict nesting. There may be logic patterns allowed in one domain, but not in the other.
The analytic information collected by the runtime engine tells when activities started, when they completed, how long they took, and how often different branches are taken. However this information is not useful to the business analyst because it does not match the model that the business person is familiar with. There will be statistics about activities that the business person has never seen, and information about activities that exist only in the business domain will be completely missing.
Model Preserving Strategy
In the Model Preserving Strategy, the model in the business domain retains the same form in the system domain as well as when installed into the enactment engine. The analytic information about when an activity starts and completes, how long activities take, and how often a given branch is taken is all useful in a discussion with the business person because the form of the model is the same. A business person can point to a particular activity in a model, and mine the Analytics records to find out how long that activity typically takes. The Analytic information is meaningful to the business analyst, as well as to the users and system integrators.
The software engineering field has had a lot of success with a Model Transforming Strategy in producing software of all types. One huge difference between producing an application and supporting a business process is that a typical user has no need to know the internal state of a running application. For example, the user has no interest in knowing how many times a particular branch is taken inside a typical word processor. The users of an application are not engaged in a continual improvement of the application.
While an application program can be a black box to people who use it, Business Process Management requires some amount of transparency into how well the processes are being enacted so that the organization can enter into a cycle of continual improvement. The Model Preservation Strategy allows the organization to capture analytics that are more useful to the business person, and to more effectively measure the performance of the business.
Couldn’t agree more with your assessment. Analytics of this sort are one of the things that separates BPM from “application development” – and when you have good analytics on your process, that is what leads to low-cost, high-return improvements in processes going forward.
A transforming tool might be able to get around this deficiency if it had a way to explicitly model the “tracking points” of the process, and then (at least) preserved those points and their relative position within the transformed output. But it is a stretch until someone demonstrates doing it with a transforming strategy. A model-preserving strategy seems to benefit from the principle of “keeping it simple”, when it comes to analytics.
Pingback: Process for the Enterprise » Blog Archive » Keith Swenson on Model-Preservation vs. Model-Transformation