When working with new-to-BPM clients I often have to help them differentiate between traditional Business Performance Reports and Process Performance Reports.
A Business Performance Report generally answers questions something like the following:
Process Performance is all about "How long did it take?". If you want to know "How long?" then you have to know when "it" started and when "it" finished.
If they don't give it much thought, when asked where to capture time stamps in their process your typical business owner is likely to say:
Before you start tracking anywhere, you really need to identify all of the Process Performance reports that the business needs. Defining these reports is clearly the responsibility of the business owner, but you may have to give them a little help. My suggestion is to focus on what questions each report is meant to answer, rather than on what the report is going to look like (bar charts, pie charts, etc.) There are many ways to present data - at this point you have to be focused on getting the data in the first place.
Here are some questions that might be asked about the rather generic Request Resolution process you can see later on this page:
Most BPM suites can automatically give you the durations of all activities... but often your report is interested in durations that are measured across multiple activities or whose start and end points are dependent on the path the process takes... as is the case with the questions I just posed.
If it's not obvious where in your process you need to capture a time stamp, then a good place for you to start is to identify the major phases of your process. For example, many processes have a Preparation, Decision Making, and Implementation phase. If you track the transitions between these phases, then you will probably have most of the time stamps that your reports will need.
Another good place to start it to identify all of the significant milestones and events in your process. Often these points correspond to the phases of your process, but there may be other points that are "exception points" in the process, like the withdrawal of a request.
In the following diagram, you'll see that I have added "Tracking Points" where the process flow crosses the phase boundaries and at some significant "exceptions":
This Business Process Diagram (BPD) is from IBM's WebSphere Lombardi Edition - and utilizes the Intermediate Tracking Event to indicate the specific points where I want to capture a time stamp. Other BPM suites may use other mechanisms, but the point is - I need to know when the process flow passes any of those points.
Once I have identified all the points in my process where I want to capture a snapshot, I need to figure out what business data I need to associate with each tracking point... and that can sometimes be tricky.
If you ask your typical business owner what to track, they will most likely say:
Unfortunately, it's just not practical to "Track Everything!" Your tracking data base will quickly become huge, and there will be loads of superfluous and redundant data.
So how do we narrow down what business data to track?
Start with the bare minimum - What do the Process Performance reports need?
At a minimum, we have to track the business data that is required to answer the questions that our reports are meant to answer. If we have a report that needs the business data, then we track the business data - If not we don't.
Take a look at the process diagram on this page, and let's assume that we want to build a report that answers the question: "How much time do we spend reviewing requests that are eventually declined?"
We've got the time stamps for this report - Start Review is the beginning and Declined is the end. With the time stamps of those two points we can answer our question.
Now let's ask a different question: "Do some reviewers take significantly longer to decline a request than others?"
This report relies on the same tracking points, but now we have to capture the identity of the reviewer. Note that we only have to capture the reviewer's identity at Declined to prepare this report.
I am sure you can think of a host of other questions, such as "Is there something about the request itself that complicates the decision to decline the request?"
Perhaps there are a few elements of the business data that could help answer this question, but we may have just crossed the line from data that we should track to data that belongs in the company's system of record.
Data about the request that does not change over the course of the process usually doesn't need to be tracked. New records are added to your tracking data store every time your process passes a tracking point. If you also have a business data store - that holds the "current" details of the request, then nothing is gained by also storing that information with all of your tracking points.
We're pretty much done at this point. We've identified all of the points in the process where we need to capture a time stamp, and we've identified all of the business data that we need to store along with those time stamps. The only thing left to do is to take one more look at all of the Process Performance reports that the business identified and make sure that nothing was missed.
The process that I've outlined for defining where and what to track is admittedly subjective but it's also pretty easy for a good Business Analyst to follow.
Starting with a Process Diagram and a list of Process Performance Reports, the Business Analyst can (and should) define their Perspective of the Process Data (where to track data and what data to track).
With the Analyst's Perspective of the process data defined, we're one step closer to finishing our process application, and one step closer to giving our business folks a great return on their BPM investment... and that ought to make everyone happy.
A Business Performance Report generally answers questions something like the following:
A Process Performance Report generally answers questions something like the following:
- How many units of X did the Y group process last month?
- How does the X processing rate of the Y group compare to last years processing rate?
Everybody knows how to gather the data that they need for their Business Performance Reports... and once they give it some thought most folks can also grasp how to gather the data for their Process Performance Reports. They just need a little nudge to change their thinking from "how many" to "how long".
- How long (on average) did it take Y group members to process an X?
- Why did it take longer for the Y group to process an X in these instances?
Process Performance is all about "How long did it take?". If you want to know "How long?" then you have to know when "it" started and when "it" finished.
If they don't give it much thought, when asked where to capture time stamps in their process your typical business owner is likely to say:
"Track Everywhere!"That's not necessarily a bad thing - but you need to remind your business owner that the purpose of tracking is to gather timing and business data that their Process Performance reports are going to require.
Before you start tracking anywhere, you really need to identify all of the Process Performance reports that the business needs. Defining these reports is clearly the responsibility of the business owner, but you may have to give them a little help. My suggestion is to focus on what questions each report is meant to answer, rather than on what the report is going to look like (bar charts, pie charts, etc.) There are many ways to present data - at this point you have to be focused on getting the data in the first place.
Here are some questions that might be asked about the rather generic Request Resolution process you can see later on this page:
- How much time do we spend reviewing requests that are eventually declined?
- Do some reviewers take significantly longer to decline a request than others?
Most BPM suites can automatically give you the durations of all activities... but often your report is interested in durations that are measured across multiple activities or whose start and end points are dependent on the path the process takes... as is the case with the questions I just posed.
If it's not obvious where in your process you need to capture a time stamp, then a good place for you to start is to identify the major phases of your process. For example, many processes have a Preparation, Decision Making, and Implementation phase. If you track the transitions between these phases, then you will probably have most of the time stamps that your reports will need.
Another good place to start it to identify all of the significant milestones and events in your process. Often these points correspond to the phases of your process, but there may be other points that are "exception points" in the process, like the withdrawal of a request.
In the following diagram, you'll see that I have added "Tracking Points" where the process flow crosses the phase boundaries and at some significant "exceptions":
Once I have identified all the points in my process where I want to capture a snapshot, I need to figure out what business data I need to associate with each tracking point... and that can sometimes be tricky.
If you ask your typical business owner what to track, they will most likely say:
"Track Everything!"This is an understandable reaction - "Something" may be important, and if you don't track it you can't evaluate its effect on the process.
Unfortunately, it's just not practical to "Track Everything!" Your tracking data base will quickly become huge, and there will be loads of superfluous and redundant data.
So how do we narrow down what business data to track?
Start with the bare minimum - What do the Process Performance reports need?
At a minimum, we have to track the business data that is required to answer the questions that our reports are meant to answer. If we have a report that needs the business data, then we track the business data - If not we don't.
Take a look at the process diagram on this page, and let's assume that we want to build a report that answers the question: "How much time do we spend reviewing requests that are eventually declined?"
We've got the time stamps for this report - Start Review is the beginning and Declined is the end. With the time stamps of those two points we can answer our question.
Now let's ask a different question: "Do some reviewers take significantly longer to decline a request than others?"
This report relies on the same tracking points, but now we have to capture the identity of the reviewer. Note that we only have to capture the reviewer's identity at Declined to prepare this report.
I am sure you can think of a host of other questions, such as "Is there something about the request itself that complicates the decision to decline the request?"
Perhaps there are a few elements of the business data that could help answer this question, but we may have just crossed the line from data that we should track to data that belongs in the company's system of record.
Data about the request that does not change over the course of the process usually doesn't need to be tracked. New records are added to your tracking data store every time your process passes a tracking point. If you also have a business data store - that holds the "current" details of the request, then nothing is gained by also storing that information with all of your tracking points.
We're pretty much done at this point. We've identified all of the points in the process where we need to capture a time stamp, and we've identified all of the business data that we need to store along with those time stamps. The only thing left to do is to take one more look at all of the Process Performance reports that the business identified and make sure that nothing was missed.
The process that I've outlined for defining where and what to track is admittedly subjective but it's also pretty easy for a good Business Analyst to follow.
Starting with a Process Diagram and a list of Process Performance Reports, the Business Analyst can (and should) define their Perspective of the Process Data (where to track data and what data to track).
With the Analyst's Perspective of the process data defined, we're one step closer to finishing our process application, and one step closer to giving our business folks a great return on their BPM investment... and that ought to make everyone happy.
No comments:
Post a Comment