Category: process

Last session of the day for me: I’m headed off to the airport following this, although I realize that the probability of a flight in or out of Chicago being on time when it’s snowing is near zero. With some luck, I’ll make it home tonight. The only thing that I’m missing is some sessions where the vendors get to show off their products, and a final wrapup keynote.

This session by Dan Madison is on Creating the “To Be” Process, something that I often do with customers, and I’m always looking to learn new tips and techniques from others who do the same thing. This session is part of the Organizational Performance symposium, the first of those that I’ve attended these two days.

He suggests a number of “lenses of analysis” to look at processes and derive the “to be” processes from the problems seen in that process.

First, create a customer report card, which for each ranked criteria, shows the current process performance (usually around quality and timeliness), what the best possible performance in that process would look like, and the two main competitors or outsourcers.

Second, look at the things that frustrate the people who are currently participating in the process, since there’s a high correlation between frustration and quality problems: frustration has the ability to act as a lens focussed on problem areas. Once frustrations are identified, the process participants tend to generate a ton of ideas on how to fix the problems, and there’s a huge amount of buy-in for changing the process from the grassroots level. I’ve definitely seen this with my customers. There was an audience question about how to keep this from becoming a bitch session, and Dan said that he uses some basic rules if things start to go that way: only process problems are discussed, not people problems; and each person can only bring forward their three main frustrations.

Third, look at the time required for each type of work in the process: processing, waiting, rework, moving, inspecting and setup. He finds that processing — the actual work — is typically only 2-20% of the time, which indicates that there’s a huge amount of inefficiency in the process. Of that small percentage, even all of that may not be time that adds value to the process. If you’ve automated your process with BPM, then you can gather this information with your system, but if your processes are still manual, then figuring out how your process breaks down will be manual, too.

Fourth, a cost lens such as activity-based costing; ABC calculates what it really costs to deliver a specific product or service by looking at the labour, overhead and material costs of each step in a process.

Fifth, a quality lens such as Six Sigma for measuring defect rates or some other relevant quality measure.

Last, take a look at benchmarks and best practices, by looking at your direct competitors and what they’re doing; and by looking at companies that have a process similar to your problem process and are considered to be world class, regardless of their industry.

He then moved on to design principles for the to-be process:

• Design the process around value-adding activities.
• Provide a single point of contact for customers and suppliers.
• If the inputs coming in to the process naturally cluster, create a separate process for each cluster.
• Ensure a continuous flow of the “main sequence.”
• Bring downstream information needs upstream.
• Involve as few people as possible in performing a process [our old adage of reducing handoffs lives!].
• Ensure 100% quality at the beginning of the process.
• Use co-located or networked teams for complex issues.
• Redesign the process first, and then automate it.

Putting it all together, creating the to-be is the synthesis of:

• Customer feedback
• Worker frustrations
• Time analysis
• Cost analysis
• Quality analysis
• Benchmarking and best practices
• Design principles
• Information technology

Dan’s obviously experienced at this: he does it as a consultant, he teaches process mapping and improvement at the local university, and he has a couple of books that he’s written on it. I haven’t read his books, but I’ll be checking them out soon.

I didn’t come to Chicago specifically for the snow, but it didn’t disappoint me nonetheless: big wet snow dripping down, just enough to get me wet crossing the road from my hotel to the Drake.

We started the day with a keynote by Andrew Spanyi, who I didn’t give a great review earlier this year for his talk at ProcessWorld, and it seems to be a very similar talk that he gave there about business process governance although he’s promising some new research data. Also, this time it’s at the beginning of the day rather than the end, so I likely have a better attention span. Besides, he’s a fellow Canadian (although transplanted to the US), so he knows how to pronounce “process” 🙂

He starts out with his 2003 and current definitions of BPM, the latter of which adds (no surprise) the words “management practice”, before putting in a plug for his two books.

The study that he did through Babson College was a “mindset” study, which explored the role of executive mindsets in enabling a BPM focus, with the hypotheses that if a firm has embraced business process thinking, then they’d have an enterprise-level business process relationship map, they’d measure things from a customer’s point of view, they’d have assigned process owners with accountability for cross-functional processes, and they’d have a plan for business processes within the organization.

Only a third of the 18 respondents (five, by the sounds of it), however, reported that they actually had all of these things (I have a question as to whether 18 data points is a statistically sufficient sample size, but then I never was all that good at stats). There were some common characteristics in these five companies: a supportive and vocal CEO, passion about performing for their customers, some sort of competitive or environmental threat, and a receptive culture within the organization.

The companies often used a framework to help them bootstrap their efforts, which allowed them to develop their process management models and plan in a relatively short period of time, and they were enjoyed a fair degree of success as corporations.

He went back to a subset of the original sample set for a follow-up survey — nine companies, four of which were in that earlier “leaders” category — and found that they still identified the same challenges. Some lessons learned emerged from this:

• Change management is key and takes longer than you think.
• IT enablement is critical to make all this happen, often by taking away the old tools and replacing them with newer tools.
• Build an organization-agnostic view of the process.

The outcome from all of this is that the organizations are seeing more cross-departmental collaboration (and less finger-pointing) due to the end-to-end view of the business processes, and that there’s a much bigger focus on the processes rather than departments — ultimately, this process-centric view is what’s going to drive success.

In the Q&A, he made the statement that BPM and BI must converge, and that companies that he talked to in the survey said that they wouldn’t buy software unless it had both — and intriguing statement that I would have loved to hear more about.

I still found that Spanyi covers too much ground in a short period of time, and flips through his slides too quickly to absorb a lot of the information: there was one five-point slide with some pretty critical summary information, maybe 20 words in total on the slide, and I could only jot down the first three points before he flipped to a rather meaningless graphic where he stayed for two minutes. However, he’s obviously knowledgeable about this stuff and I liked his talk this time around.