We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion

Is process performance all about, "How long did it take?"

Vote 0 Votes
Scott Francis raises the question in this blog, Beginner's Guide to Performance Reports, is process performance all about, "How long did it take?"

12 Replies

| Add a Reply
  • "How long" is important, but so is "how many" and "who" and "what's up with the exceptions" in the way Scott articulated. But I like to see organizations go further than this, and ask "are these processes as efficient as they could be?" Simply working faster isn't the answer if it still is possible to work smarter. The "what's up" question is a great way to open this line of inquiry.

  • To me, "how good was the outcome" it's at least as important. This is especially critical in case of knowledge work.

    Second in line, after the ones you and Steve already mentioned, comes "How much satisfied/motivated were the workers?"

  • I agree with Steve and Marco. Quality, effort and experience are good metrics to be looking at. Although reducing elapsed processing time may be good in many scenarios, you could inadvertently miss some of the unexpected ways of improving the perception of the process by its customers. For example, often the speed of the initial response sets the tone for the rest of the process. Pick up the phone faster, respond to the first email faster, and understand the issue and communicate what will happen next, is better than a slow response but resolving the issue immediately.

    Think of how many times you have called a call center to wait 30 minutes. Your perception is bad from the start of speaking to an associate. Instead, if they pick up in 60 seconds, and spend just a little time understanding your problem and communicating how the issue will be resolved, you feel better, because you got half and hour of your day back.

    Of course, this all depends on having the ability to communicate with customers through multiple channels, not just the primary point of contact.

    Hmm, I could go on. Thought provoking...

  • Great question. Considering how important time is to business processes, it's amazing how poorly many BPM solutions address time as a critical element in planning and management.

    On that point, "How long did it take?" is an important—but terribly easy—question to answer. What I want to know, as the owner of a long, complex, process is: "How long WILL this take?", and, even more importantly: "If this activity runs long, how will the overall timeline be affected?"

    To the extent a BPM solution can't answer that question, it's not providing the type of proactive support that process owners need in order to keep on top of changing business conditions.

  • No, in enlightened organizations, it should be all about how much more efficient did we get and how much shorter is our essential cycle time.

    Bill Roth

  • Yes, if you are designing for speed, "how long did it take" is the critical performance metric. However, if you are optimizing for something else or balancing several key parameters then the question about how long may be less relevant. You have to define what success looks like and track key performance indicators that reflect those critical success factors.

  • If your approach to BPM is not firmly pivotted around creating business value for the organization, then it is likely that you will look at process performance and business performance separately. That's when you chase the wrong parameters to assess process performance. Aligning business and process performance is a crucial factor for BPM success, no matter what (time, cost, etc) you look at.

  • I am with Scott – processes can answer (with a good level of confidence) questions like “Are we still within SLA” and “What should be changed in the currently executed process to be still within SLA”.

    Just a few paragraphs from my 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 nonrespect 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.

    See the illustration - http://www.improving-bpm-systems.com/misc/atre-KPI-c.png


  • -- "How long did it take?" --

    "How long" is certainly an important criterion in driving process improvement, provided the "it" is defined right and aligned to business goals. I have seen the meaning of "it" getting lost all too often as we traverse organizational hierarchies, silos and boundaries.

    Let me illustrate the point with a real-life example. The case of a telco call center where customers' calls get answered in less than 30 seconds every time they call, and their trouble tickets get closed within 48 hours. The call center meets its SLAs consistently and was rewarded for the best BPM program within the organization.

    But many customers' problems remain unresolved for weeks, or even months - contributing to higher than usual customer churn and general discontent is continually voiced in social media.

    What was measured (the "it") to define performance (how fast was the call answered? how long did it take to close the ticket?) was wrong or incomplete, at best. What should have been measured is how long it took to resolve the customer's issue - and this could span multiple calls or tickets.

    In short, what is efficient may not be effective. "How long" indicates the efficiency, but it is how you define the "it" that drives effectiveness - and you need both to drive true process performance.

  • I think it isn't about "how long" but about customer satisfaction

  • Measurement of a process should first be weighed against "what" is the process and the value brought to the organization as opposed to duration. Duration has to be part of the analysis equation, not as priority. I have a blog entry on e2e processes using a change management process that has some relevance to this thread, www.iqullc.com. Some processes will require time; with a well thought out plan of action any effort can be managed effectively and expeditiously.

  • Here is the direct link to the entry....http://wp.me/pO8n7-3E

Add a Reply

Recently Commented On

Monthly Archives