Thinking about White Space

I’ve been thinking a lot recently about all the stuff that happens outside of traditional enterprise applications. Enterprise software (ERP, CRM, etc) has become good at solving most of the structured work needs in organizations. But, many business problems today require work outside of enterprise applications. These ‘white space’ activities involve research, analysis , collaboration, applied knowledge, planning, resource allocation, approvals and many other human activities. Often they get managed today using email. This results in a large portion of the work done in organizations being:

• Undocumented
• Unmanaged
• Unmeasured
• Time Intensive

Alternatively, they are supported with custom development that makes changes and upgrades difficult (often in addition the above issues.)

This need cries out for something that is easy to use like email, but addresses its deficiencies. Adaptive Case Management (ACM) holds out the hope of solving this need, but I’m not sure anyone has yet met the vision and been able to deliver on the promise. I’m not even sure there is agreement on the title (Advanced, Dynamic, or Adaptive) let alone what the promise is.

Forrester recently Waved Dynamic Case Management (DCM). After a long discussion of what DCM is, they evaluate vendors (mostly incumbent BPMS providers) on only six capabilities:

1. Design
2. Development environment
3. Capture, CCM, and ECM support and security
4. Case handling and guidance
5. Case-centric application support
6. Automation and event management

More enlightened definitions, I think, come from practitioners a little closer to the field:

Keith Swenson lists six characteristics of an Adaptive Process:

1. simplified deployment: the case templates do not need to be designed in advance to fit the situation.  You deploy an uncustomized system into the organization, and then it is adapted by the case managers themselves as needed.
2. exercise: The system is not “designed” by a central planner, but instead it is trained by exercising it.  Those parts that get the most use, and have the most need of improvement, will get the most effort.
3. learning: the system as a whole learns how to support the organization.  Instead of designing for a theoretical idealized business case, it learns from the real business cases, with the real people working on them.
4. practice: the training is accomplished by doing the work, and without the need to make an abstract theory about the underlying mechanisms.
5. stability: the system can be extremely stable because it senses and responds to perturbations automatically. The case managers themselves can shift behavior as needed, without waiting for programmers or other specialists.
6. optimized: each part of the organization can optimize use to their particular needs, for their particular part of the business, and their particular employees and skills. This level of optimization can only be achieved through self-modification.

Max Pucher simplifies and then expands these ideas (I encourage all to read the full content of all posts referenced here.) He uses three criteria to define an Adaptive Process:

1. Adaptive Process is a productive system that deploys not only the organization and process structure but through backend interfaces becomes the system of record for the business data entities and content involved. All processes are completely transparent as per access authorization and fully auditable.
2. Adaptive Process enables non-technical business users in virtual organizations to seamlessly create/consolidate structured and unstructured processes from basic predefined business entities, content, social interactions, and business rules to achieve verifiable goals.
3. Adaptive Process moves the process knowledge gathering in the life cycle from the template analysis/modeling/simulation phase into the process execution. The AP system collects actionable knowledge – without intermediate analysis phase – based on process patterns created by business users.

He then goes on to catalogue increasing levels of ACM that deliver these capabilities:

He concludes by emphasizing that, “The ACM platform must allow each business and department to work as they see fit to achieve customer outcomes and avoid the failure demand and increased costs that process standardization would cause.”

Who will deliver on any of these ideas is still up for grabs in my estimation. Some social tools are starting to hit close to these promises, but none have quite hit the mark . Let me know who you think gets close.

How Long Does it Take?

This post continues a series of  blog posts on Measures by exploring Cycle Time.

Cycle Time is one of my favorite measures. It is at the heart of Lean and forms a basis for improvement that is typically at the center of good customer experience and process agility. In my opinion, any process not tracking this measure cannot be meaningfully improved.

Cycle Time is defined as the total duration for a process to complete. This includes all time from a customer’s perspective to transform inputs to outputs including wait, process, transport, inspect, and other value add and non-value add time.

Cycle Time (CT) is easily measured for any process. You could measure it directly by starting a clock when a work item enters a process and timing until the process is completely finished with an end product. Of course, you’d have to allow for different exception paths that may take longer than the happy path on some repetitions of the process. The neat thing however, is that on average, Cycle Time can be calculated using two other readily available metrics. Cycle time is equal to the work in process (WIP = work that has started the process, but is not yet finished) divided by the capacity (Exits = output of the process over a period of time.) That is:

CT = WIP / Exits.

Consider a bank line. There are 10 people in line in front of you for the teller. You notice that one person is finishing on average every 2 minutes. How long will you wait in line – what is your bank line cycle time? WIP = 10 people in line. Exits = 1 person/2 minutes = 0.5 person /minute.

CT = WIP/Exits = 10 person / (0.5 person/ minutes) = 20 minutes

Want cycle time to improve? Reduce the WIP. If 5 people leave the bank line, you’ll wait half as long. Same process, half the CT. Or, improve the process capacity. With a second teller working, the Exits increase to 1 person/minute and again you wait half the time. Best yet, make the single teller twice as productive. Again, Exits double and CT is cut in half.

These same concepts apply easily to processes improvement. Usually, we can control the WIP in a process. Pull or Kanban systems are set up to do just this. Once the established WIP level is reached, no new inventory enters the process until another item exits. Generally, work should stay in its most unprocessed form until there is demand and capacity for it. Why is this important? When WIP is reduced all kinds of good things happen:

1. Reduced Investment. WIP represents an investment that has not yet paid off. Reduce WIP, and you reduce the capital needed to run a process. Or, for service processes, think of reducing the investment in unbillable work “laying” around the office.
2. Less Waiting. WIP that is waiting to be worked on is potentially wasted. Specifications and demand can change and WIP can get damaged and decay causing rework, excess and waste. Even for items that don’t need preserved, it is helpful to think of WIP has rotting any time it is in a queue.
3. Less Storage. If WIP is not in the process, it does not need to be stored on the floor, in warehouses, or in file cabinets and desks.
4. Easier Logistics. Unless you’re a long haul railroad, it is easier to schedule and move smaller loads.
5. More Focus. If work gets stuck in the process, it is much easier to find the bottle neck or constraint and take corrective actions.

In general, WIP should be reduced to just enough to cover the bottle neck activity. Consider our 3 step loan approval process of: Capture, Approve, Fund. If Approve can process only 10 loans a day while Capture and Fund can do 20 per day, marketing should generate demand for only 10 loans per day to meet a 1 day cycle time. Any more, and the cycle time will increase to over 1 day. Want to be able to handle more loans each day at the same CT –  you’ll need to improve capacity (Exits) at the bottleneck. To process 20 loans at 1 day cycle time, you’ll need to double Approval processors or make them twice as efficient (normally using a Lean technique to focus on value add or Six Sigma technique to reduce errors and variability.) The Capture and Fund processors already have that capacity.

Looking at improvement from another perspective, as cycle times are reduced, capacity (Exits) increases proportionally. That is Exits = WIP/CT. A fifty percent reduction in cycle time at the same load means capacity has doubled.

Measure and focus on Cycle Time improvement to maintain customer satisfaction, reduce costs and improve capacity.

How Many?

When setting process measures, there are four key areas where I start:

1. Volume
2. Cycle Time
3. Efficiency
4. Quality

I’ll be exploring these over a series of blog posts on Measures starting with this post on Volume.

Volume seems like a simple measure. At its root, it is concerned with how many. Lets consider a simple a simple loan process and dig in a little deeper.

First, should I measure the number of loans, or the $ value of the loans processed? Is there another weighting factor that affects the process that I should measure?

The loan process has two types of loans. Do I need to measure volume separately for each type or jointly? What if there is different process requirements for each type?

Our process has 3 steps: Capture, Approve, Fund. There is drop-off after each step, so that volume at the first step will be different than subsequent steps. How do I account for this? If there are dependencies, and parallel steps, they may also need to be accounted for. Volume measurement gets more interesting as transactions become longer running. Over what period do I measure? Do I care about:

• The number in each step (how many loans need funded),
• The number that passed through each step (how many loans got approved today and may or may not yet be funded regardless of when we captured the loan), or
• The number that got converted through the process steps (of the loans captured this week, what percent were approved, are funded)

I have multiple processors at each step. Do I want to measure volume separately for each processor, or is jointly OK? What if the processors are more specialized or have different levels of approval authority?

Volume measures can get complex very quickly. So, be sure to understand how volume measures are being used. Depending on what level of visibility is required and how it impacts management or the ability to optimize processing, there can be many dimensions to how volume gets tracked and reported.

CU’s Business Process Management Class

Thanks to Dr. Judy Scott and all the thoughtful University of Colorado students who participated in last night’s engaging class discussion around BPM. Good to know that BPM has grown into a graduate course with good critical thinking around the concepts and applicability.

Here is a link to my presentation materials on the Business Value of BPM. I look forward to follow up discussions in the comments below or on the course discussion forum.

Forrester Waves Dynamic Case Management

“While BPM products tend to focus on repeatable, structured processes, case management applies to more dynamic, unstructured, ad hoc processes.” And so, a new wave is born in Q1 2011. Forrester now separates DCM from traditional BPM with a separate wave. The usual suspects make up most of the leaders. Some interesting up and comers also make the short list of vendors profiled. Their explanation of Dynamic Case Management is worth a read of the full article.

Is Process Improvement Strategically Important?

What a great blog over at HBR. I agree with most everything Brad Power discusses. In a recent installment he tackles a question often overlooked. The title speaks for itself:  When Is Process Improvement Strategically Important? He starts with the assertion that, “Process improvement programs that do not expressly target competitive advantage are doomed to fail.” Agreed. He then goes on to describe when programs have the right target. Among other jewels, he discusses a quad matrix to quantify the importance of process to strategy using  focus (efficiency vs. growth) and time-frame (short-term vs. long-term). Hint: The requirement for a long-term focus may be why some organizations discount the strategic importance. Go read the post, then browse the whole blog.

2010 Gartner BPMS Magic Quadrant

If you missed it, here’s the Gartner BPMS Magic Quadrant for 2010, freshly published October 18^th

And a Link to the full document: Gartner 2010 BPMS Magic Quadrant.pdf