kathi.penrod
How can I make this scenario be different if it was tracking the…
How can I make this scenario be different if it was tracking the time needed for a nurse to complete their rounds in a hospital? How can I apply the same methodology from the scenario and in the number of rooms the nurse needs to visit?
CASE STUDY: A TRIP TO THE SUMMERHOUSE
We will draw on this example throughout this chapter, introducing concepts such as KPIs, performance management (also called corporate performance management [CPM] and business performance management [BPM]), lead information (information for business process reengineering), lag information (information for monitoring and controlling processes), and the definition of information requirements based on critical success factors (lead and lag information combined) and dashboards (a tool for monitoring the organization’s processes). So lean backwe’re going on a trip to the summerhouse. The route we’re taking is 60 miles long and is expected to take 60 minutes. As we continue, we will monitor and measure the operational process required to take this trip. From a business perspective, we are looking for answers to three questions; our BA function must answer them.
Status: “Have we gone far enough in relation to how long we’ve been on the road?”
Trend: “Are we accelerating up or down, or is our speed constant?”
Projection: “Given our speed and how far we’ve gone, will we reach the summerhouse at the expected time?”
Specification of Requirements
We can now start making our specification of requirements for the performance management dashboard. The goal is to drive 60 miles in 60 minutes. We can now place in our budget a goal line, as shown in Exhibit 3.2, which is a straight line and a function of time. In other words, we choose a goal that is to drive with the same speed all the way. To do that, we must be halfway through after 30 minutes.
Image transcription text
Status (dot): Miles Status 60 Actual/ Budget/ Realized miles
Target miles 2 KPI > 1 40 Trend KPI < 1 20 KPI > 1 KPI
< 1 Projection 0 Time (min) O 10 20 30 40 50 60 Cit...
Show more
Exhibit 3.2 Example of a Performance Management Dashboard for the Trip
Our KPI must specify key elements of the performance and give us an idea of the degree of success with the project. An obvious choice for KPI will therefore be the relationship between what we have achieved and what we plan to achieve.
Visually, this means that the graph with actual miles is lying above the target curve, when our KPI is more than 1 (see Exhibit 3.2).
In addition to the graph, we could set up a "cockpit" or performance management dashboard, consisting of a number of simple indicators for the process. Here we have made a status indicator showing our current KPI, and this is more than 1 when the status line is over our target line.
We have also added a trend meter, which points downward if the speed in the current period is lower than the speed in the previous period. The situation at the black dot in Exhibit 3.2 is therefore that we are doing well overall, but that we should be aware that we are losing speed. Further, we have added a smiley face on this dashboard with information about whether the summerhouse will be reached on time given the current location and acceleration. This last KPI is illustrated by a smiley that is happy, neutral or unhappy, depending on a projection of whether we will reach our destination on time, might reach our destination on time, or won't reach our destination on time, based on current statuses. At an overall level, we just have to keep an eye on the smiley.
Technical Support
So what do we need in terms of technical support to realize this specification of requirements? Exhibit 3.3 shows a section of our base table.
Start Time Time in Minutes Budget/Target Miles Actual Miles
14.32 - 20 Feb 10 0 0 0
14.32 - 20 Feb 10 0 1.00 (60/60) ? (not known till 1 minute after start)
14.32 - 20 Feb 10 - -
14.32 - 20 Feb 10 59 59.00 (1.00 × 59) 60.00 (I reach my target after 59 minutes)
14.32 - 20 Feb 10 60 60 (1.00 × 60) ?
Our data in the start time, budget, and time columns is fixed before we begin the trip. These values are static. The column with actually driven miles is updated on an ongoing basis by program code that reads the number of driven miles. A new figure is added to the table in the column with actual miles every minute. Then the graphics on the data-driven and dynamic dashboard are updated. All the data in the table is read every minute to the graphical object that shows the curve and actual and expected miles. Then our KPI is computed by dividing the latest number of actual miles by the number of expected budget miles, and the change can be seen in real time on the dashboard, along with any replaced GIF arrow (graphic image of an arrow) and smiley. If we drove faster in the previous minute (actual miles/time) compared to the minute before, the GIF arrow pointing upwards is loaded. If the latest KPI is computed to be more than 1, the happy smiley is loaded for our performance dashboard in Exhibit 3.2.
Off We Go to the Summerhouse
We start our journey, and the first couple of points on our status curve in Exhibit 3.2 appear on the dashboard after a minute, along with the other graphics. We're driving in the city and are therefore under the target line. Our KPI is under 1, and our smiley is unhappy. Our trend arrow, however, is pointing upwards most of the time as we slowly, minute by minute, increase speed on our way out of the city. Performance monitoring encourages us to drive faster, but that just won't do on city roadsand isn't that annoying! Once on the highway, we finally speed up and move over the target line; the KPI is now over 1. Out smiley becomes neutral and then happy, and the trend arrow is still pointing upwards, as we continue to increase our speed. But then we run into traffic on the interstate. Our KPI falls back through 1, as we're now getting under the budget line. Then the smiley is unhappy and the trend arrow begins to point straight ahead, as we have to stop the car!
However, the traffic quickly dissolves, and we increase speed significantly to get to our summerhouse on time. Our KPI goes from 0.9 and breaks through 1. The smiley is happy again (just as we are), and our trend arrow has pointed upward ever since the traffic became lighter. When, after a while, we leave the highway, our KPI is 1.1 (10 percent over target or budget). For the last bit of the trip, we'll be driving on smaller roads and our speed will therefore fall. The trend arrow points downwards, the status speedometer slowly drops towards 1. But we're feeling optimistic, because we know that we have enough margin for the last part of the trip, as the smiley and KPI both show us.
By means of the above example, we've tried to illustrate the idea behind KPIs and performance management. The example may seem trivial, but it does provide a useful insight into key concepts and how to monitor a business process.
Lead and Lag Information
The summerhouse example also gives us an understanding of the two types of information used by the BA functionlead and lag information.
Lag information is retrospective information, which we choose to register on an ongoing basis in our data warehouse in connection with performance management. In the summerhouse example, the lag information is the actual number of miles. Lag information is typically stored in tables in the business's data warehouse and is used for analyses to create a learning loop back to the strategy (see Chapter 2 on strategy) or for new lead information.
Lead information has a completely different character than lag information. Lead information is used to improve existing business processes or initiate ones. Lead information in the BA framework is typically created on the basis of an analysis of lag information and is therefore usually not stored in tables, since this information, as already mentioned, is the outcome of an analytical process. Lead information will typically have the character of "breaking insight," which can be used to improve overall business processes and provide learning loops back to the strategic level. An analytical process using, for instance, a data mining methodology on our base table in Exhibit 3.3 (naturally, after we've done the trip to the summerhouse several times) would be a useful tool for uncovering key factors to provide us with knowledge about why we tend to arrive at the summerhouse early () or late (). This knowledge will, in future, help us arrive at our target on time, thereby achieving success. Our breaking insight, which is the outcome of these analytical processes on our historical data, could be a statistically significant correlation between the value of our KPI, when we reach our target, and the start time of our journey. The correlation is illustrated in Exhibit 3.4.
The trip to the summerhouse is usually successful if we start driving before 2~PM or after 7~PM (KPI > 1). The worst time to start is between 4~PM and 5~PM. If we start within this time interval, our chances of reaching our target on time are minimal. The explanation is, of course, that it takes longer to get through the city in rush-hour traffic, and we’ll almost always end up in a slow line on the motorway. Our breaking insight or lead information, which we could also call our critical success factor, will be: We must start our trip to the summerhouse before 2~PM or after 7~PM in order to optimize/improve our operational process and be successful in our endeavor.
Note that the new important lead information identified by analytics obviously works to provide a learning loop back to the strategic level (see Chapter 2) to be used next time a strategy is developed for the coming year. In this section, we’ll take a closer look at what KPIs are, how they are generated, and what they can be used for. The creation of KPIs is normally intuitive as illustrated in the above summerhouse example.
Generally speaking, KPIs describe the relationship between the organization’s activities and its main objectives. KPIs can be financial key indicators, index figures specified for the occasion, or other SMART (specific, measurable, agreed, realistic, time-bound) objectives. What is required of KPIs is simply that they on the one hand set some standards for how business processes must perform (lag information) and on the other help us define which activities have “gone wrong,” if the process does not meet its objectives. This means that if we have a KPI, and we are below target, we always know which consequences this will have in the long run. This knowledge enables us to adjust activities and thereby ensure that the overall targets in the corporate strategy are achieved.
KPIs therefore work as warning signals. Generally speaking, if some KPIs are not achieving their targets, we must look into why. Is it a question of a lack of strategic focus (i.e., the organization for some reason is not focused in its efforts to meet the strategic objectives). Is it a case of correct execution of the desired activities, but with a lack of competencies or resources, which means that the activities do not reach the desired level? Did something change that we did not plan for, or was the strategic target too stretched, as they often are? Every year companies plan for growth above the market growth, else they would be planning to lose market presence. But not all companies can grow more than the market.
Another important function of KPIs is that they are able to stop activities again. It is not uncommon for CRM departments to have to take on many troubleshooting tasks. When we face a problem, we solve it by starting a new and corrective process. But when do we stop these processes again? If we fail to do so, the organization’s CRM strategy will become a patchwork quilt of historical troubleshooting exercises. If we are constantly patching things up, more and more resources will be needed over time to maintain these stopgap measures throughout the organization.
When systematically collected, KPIs also provide the organization with a memory, which means that learning can be derived from successful projects. This learning may come by means of analytics, which we will cover in the following section, but also by holding people to their promises. It is quite a common phenomenon to have people who are extremely good at convincing management that they have a great idea for a campaign. And then there are people who make great campaigns. As the two are not necessarily the same, measuring KPIs will tell the organization which campaigns are working. In the long run, this means that we get an organization where the focus is on results, rather than on what sells internally.
More about Lead and Lag Information
As mentioned in the introduction and in the summerhouse example, BA often distinguishes between lead and lag information, where lead information is the knowledge we need to initiate or improve a process. If we take our point of departure in our trip to the summerhouse, there are two possibilities; either it’s our first trip there on that route, or we’ve gone that way before.
If it’s our first time on that route, we must initiate a new process, because we’re doing something for the first time. This also means that we have no historical knowledge about how long it takes to take that route, and we therefore have to plan our trip based on other information, such as directions from the Internet or general experience with how long that kind of trip takes. What we’re talking about here is lead information, the information that will get us to the summerhouse using the correct route with arrival on the correct time. Therefore, it is information that we need to have before we start our trip.
As we are driving toward the summerhouse, we receive a large amount of lag information. The nature of lag information is that it monitors our process. We can react to it and adjust our actions by driving faster or slower, but it will not change the actual process we are in, based on this information. This is information we collect and use in the course of the process.
If we get fed up with the route we’ve chosen and want to find a new one, we have to start looking for new lead information to find out whether there is another route that may be quicker and easier. If we then choose to go by the new route, we will again start generating lag information, based on which we will create expectations to whether we reach the summerhouse on time. If it is not the first time we take the given route to the summerhouse, we already have knowledge about the usual course of the trip. We have, in other words, lag information telling us how long the trip usually takes, whether the traffic is different at different times of the day, week, and year. Based on the lag information we’re already in possession of, we can generate new lead information because we know when we want to reach the summerhouse, and how the traffic usually is at the given time. We can therefore count back and find out when we need to leave, and plan whether there is time for other activities before we go. We can, in other words, learn from our internal knowledge and optimize the process, which is the trip to the summerhouse. This is exactly what we do in connection with process optimization, where we are not just using lag information to monitor whether the process meets its objectives. Rather, we are also saving this lag information for future analyses to improve this process via lead information that has the character of being breaking insight.
Since the subject of this book is how to optimize business processes based on strategic requirements, we have chosen to include two perspectives. One perspective is the establishment of a process for the first time, which includes identifying which lead and lag information is required in the organization, so that we can initiate and manage the given process.
The second perspective is taking its point of departure in a strategic demand for the optimization of given business processes. Since this process is already established, we can use saved lag information describing the correlation between the process, the way in which it has been influenced, and the effect it had on the process, and derive knowledge about how we can optimize the process. So, based on lag information, we can generate lead information, and if the nature of the process is not being completely restructured based on learning from the new lead information, this learning cycle can be maintained.
In terms of our trip to the summerhouse, we can continue to cut back on minutes and seconds of the drive while potentially minimizing petrol consumption, if we measure that, too, and thereby improve our process on an ongoing basis. This is a case of optimizing processes by improving the use of resources (less petrol consumption, for instance, if we observe traffic regulations and do a bit of shopping, which should otherwise have been done separately) and optimized user satisfaction with the process (the fact that we arrive exactly on time without stressing, and maybe get out and stretch our legs on the way, if that is what the users ask for at the beginning). The reason for separating the two is the fact that passengers in the car don’t always want to get out to shop, or to start the trip early and drive at 50 miles per hour to minimize fuel consumption. Passengers are not likely, either, to appreciate the excellent service it would have been if we could get them to the summerhouse in half the normal time by driving 160 miles per hour. The same thing occurs in a restaurant where service has been cut back too much, or the level of service has been raised so high that we don’t want to pay for it. To optimize resources in a business process, it is necessary to take user satisfaction into consideration, which is a fundamental rule in performance management.
