Linkedin: How do we measure work flow across multiple business units? Managers are finding it difficult to monitor and follow up with process on priority basis.

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=61365&discussionID=14793570&sik=1267787964487&trk=ug_qa_q&goback=.ana_61365_1267787964487_3_1" />

I am with Ralph – just priority is not enough and some performance (and other) information should be used at some control points.

Below is a fragment from my book (www.samarin.biz/book):
One of the possible interpretations of performance information is a proactive control of the SLA. As any process is a service, so it has to have an SLA, e.g. an agreed execution time. Typically, process engines are good for generating an alarm (e.g. an e-mail) that a particular process instance took more time than that agreed. But this is not sufficient because it addresses the effect and not the cause.

The imposition of a fixed SLA on all activities within a process template leads to a fussy BPM system which produces too many “false alarms”, e.g. if some execution time has been saved at the beginning of a process instance then the control on subsequent activities can be loosened somewhat; alternatively some activities may “catch up” the time lost by some preceding activities.

Ideally, the process owners have to be warned in advance about any potential non-respect of the SLA by a particular process instance. Control points are good places to run “health check-ups” of SLAs. These check-ups should evaluate the current situation and provide proactive control to achieve flexibility in the execution of the complete process, thus really helping business process managers. In addition to the process SLA, each activity is considered as a “spring” with some limits to stretch and to compress. The activity SLA needs to be defined to include both the nominal size of the “spring” together with its upper (stretched) and lower (compressed) limits.

Figure 7.3 provides an example of the dynamics of such a proactive control. As completion of the activity “Activity01” took more time than planned, then the SLAs for the other two activities were reduced (i.e. the springs were compressed). As completion of the activity “Activity02” again took more time than planned then the last activity needs to be compressed even more. It may happen that the last “spring” doesn’t reach its lower limit and thus the process instance may be completed within its SLA. Otherwise the process owner has to take some action because this process instance will break its SLA.

Thanks,
AS