Management Consulting and Training Since 1993
BPM Consulting & Training
menu MENU

Image is Everything

A Classic Healthcare Improvement Story

by Ralph Smith

A while back a friend of mine who is a hospital COO gave me a challenge- find and facilitate 3-5 game-changing process improvement projects. Nothing was off limits, but each project had to deliver >$1 million improvement to the bottom line. In the midst of my search, I stumbled across some interesting data.

The MRI department had a six-week backlog to get an appointment, yet the daytime utilization of their scanners was just over 50%. (They had to repeat that three times before I was sure I heard it right!). This looked like a project that checked all the boxes- management commitment, good data on the existing process, knowledgeable subject matter experts… it had it all. What about financial opportunity? Well, this was a children’s hospital. That meant a significant percentage of the patients had to be put to sleep for their scan- tough to tell a 5-year-old to hold still for 45 minutes. That made the average charge per patient over $5,000. We set a reasonable target of 70% utilization, which basically meant adding 4 scans per day- roughly one per scanner. That’s $20,000 per day… it adds up.

Every project is unique. One of the things that made this one unique was the presence of senior leadership on the team, mixed with front-line personnel. It’s tricky to pull that off unless you have the right chemistry- we did. Great leaders that knew when to chime in and when to listen. And because the leaders were there, we got buy-in as we went along. When we wanted to make changes, we had the authority to do it- we didn’t have to waste time getting approvals.

What did the team do? Analyzed the process, collected data, performed cause analysis, etc… all the things a lot of process improvement teams do. But this team was interesting in that the range of lessons learned fell into a lot of common categories:

Don’t make assumptions: For months the team kept saying they had two fast machines and one slow one. As an outsider, I assumed the slow one was slow because it was older / not state of the art. I finally asked one day, and got the unexpected answer that it was slow because it took smaller images and had to be reset to do larger area scans. Once that was on the table, someone suggested using the “slow” scanner primarily for brain scans, as they were small enough to be taken in one shot. The team therefore turned the “slow” scanner into a third “fast” one.

When everyone shares responsibility for communication, then no one is responsible: Multiple functional areas were assuming someone else was telling the parents their kids couldn’t eat before coming in for an MRI (because they would be going under anesthesia). Many times that meant they weren’t told at all. The kids-that-ate-at-McDonalds-on-the-way-in rate was much higher than it should have been, leaving utilization gaps. Nursing took accountability for this and the problem went away.

Metrics that don’t tell the whole / right story: The hospital kept track of no shows for years, and had multiple reminder mechanisms in place to prevent them. Nothing wrong with that, since the no show left a gaping hole in the schedule and hurt utilization. But no shows weren’t the whole story. When a patient cancelled or rescheduled within a day or two of the appointment, there wasn’t enough time to get a substitute patient through the insurance process and fill the slot. So late-stage cancels and reschedules had the same scheduling impact as no shows, and they happened far more often. Changing the metric to “lost slots” gave the team a bigger-picture view of the schedule, and led to modifying the timing on the reminder process so we could head off late changes before they became a problem.

We’ve always done it this way: Every organization has processes that have been around since the dawn of time, and people often assume incorrectly that they cannot be changed. In this case the Radiologists would order certain scans and the techs would run them. The problem was that often the orders weren’t specific enough, causing the techs to either a) chase down the Radiologist and ask questions, b) run the sequences they thought were necessary, creating rework when they were wrong, or c) running everything that might be needed, wasting scanner time. The team wanted to approach the Radiologists with the idea that they should protocol specific scans for each patient for the following day before leaving the night before, but assumed there would be massive pushback. Luckily, one of our team members was a senior Radiologist, and he pitched the idea. The rest of the Radiologist group had been frustrated with interruptions / questions from techs and periodic rework, and adopted the process change immediately. The % of scans protocolled was over 90% within a month, and utilization interruptions dropped measurably.

What were the results? Well, the first round of changes enabled the hospital to burn through the entire backlog in one month, dropping time-to-be-seen from six weeks to under a week. This led to improved quality and speed of patient care, and big gains in parent satisfaction.

And while a picture may only be worth a thousand words… it turned out it was also worth several million dollars.

Click here to learn more about Orion’s process improvement and strategic planning services for hospitals and medical practices.

Three Decades, Two Pieces of Bad Advice

Experts Mistakes on Process Mapping

by Paul King

Over my 30 years at Orion, I have had the opportunity to observe a lot of IT projects and collaborate with many IT consultants. It’s inarguable that the right technology implemented the right way can deliver dramatic improvements in customer satisfaction, revenue and efficiency. However, too many projects fall far short of the intended ROI – in part due to “expert advice.”

In my experience, the two most misguided examples of expert advice are:

1) Start change management efforts as soon as the new IT system is implemented. We need to make sure people use the new system and drop their old workarounds.

and

2) Don’t bother with as-is process mapping. The new ERP/CRM/SFA/Cloud system will deliver best practice processes.

No as-is analysis is like no parachute

Implementing new IT without As-Is analysis is like…

Skipping As-Is: If everyone could just buy best practices, life would be easy.

I don’t blame the salesman for telling you this car, this washing machine, this cell phone or this ERP system will change your life. Caveat emptor. But the system implementer should know better.

Sometimes, if you have a smaller organization with relatively simple processes, you can take the ERP/CRM/SFA software out-of-the-box and just force-fit operations to the new technology model. No need to map the current state. For most organizations, it’s not that easy.

This lesson has been learned the hard way, over and over and over. I first witnessed it in the 1990s when one of the Rockwell companies invested in SAPTM. After what was considered a “successful” implementation, on-time deliveries plunged from above 90% to just 15%. Unfortunately, this was not an isolated incident; many more companies faced similar operational crashes as they rushed to implement ERP systems in hopes of fending off the greatly feared Y2K bug. At Orion we joked, “Let’s develop a ‘sap recovery’ system.”

(It wasn’t really a knock on the SAP product. They just happened to have by far the largest market share back then. Not long after 2000, the City and County of Denver hired Orion to fix their processes following a disastrously successful PeopleSoftTM implementation.)

Why did so many smart, talented technology professionals fail to see the perils of ignoring as-is business processes? For most of us, it was just the way we were taught. In one of the great ironies of my professional life, I started out as a hotshot programmer who thought “process” was a waste of my time. I did not need to draw a process map – I could see it in my head. In my mind, what really mattered was the elegant and efficient set of formulas I could devise to solve the problem. (In the 21st century, I guess they’d call it an algorithm.)

It wasn’t until I began interacting with customers and going to work sites (manufacturing plants, hospitals, government offices) that I understood that “process” is actually how work gets done. It’s how people create value. That epiphany changed my career. In some ways, it is why Orion came into being.

Many systems implementers have begun to talk the talk about business processes. Not enough of them are walking the walk. Mapping and analyzing as-is or current state business processes is not about drawing boxes and arrows. It certainly not about mastery of BPMN or a particular software tool like VisioTM, BlueworksTM, or ProcessManagerTM.

Creating charts and documenting SOPs is the easy part. The magic of as-is process mapping comes from drawing out the nuances, the necessary (and unnecessary exceptions), the key handoffs, and the customer experiences that make your processes sing. Collectively, I like to call them “process wisdom.” These ingredients create the special sauce that’s unique to your customers or your employees or your culture.

No product is going to have this special sauce out-of-the-box. By understanding and embracing what makes you special, your organization can determine which limited customizations or process designs will enable you to get the most out of your IT investment without undermining your unique capabilities/characteristics.

Other benefits of performing as-is analysis before making a major IT purchase include:


For other perspectives on the importance of doing current state analysis for leaping forward with an IT implementation, please listen to these short videos from two of my partners:

Bob Boehringer – Do NOT Skip As-Is Analysis
Mandy Dietz – Process Before IT


You can pay me now or you can pay me later

The City and County of Denver is not the only organization that called on Orion to help them recover from the operational pain caused by an ERP/IT implementation that did not include sufficient upfront process analysis. One of the most dramatic examples is from an electric utility on the East Coast. This large organization paid a top-tier consulting company tens of millions of dollars to implement an emergency management system. The system proved completely inadequate during Hurricane Sandy.

In each of these cases, the consulting costs of fixing the problem weren’t as dramatic as the old Fram oil filter commercial. The real pain came from the unexpected operational costs, lost market share, and damaged customer relationships that accumulated in the weeks and months following a “successful” go-live.

On the flip side, some of the greatest client successes Orion has witnessed came in organizations that understood the importance of the business process. There are several stories I could share from organizations whose leaders understood the wisdom of analyzing their processes before advancing to automation, but my favorite is from the Michigan Office of Retirement Services (ORS).

Back in 2000, ORS was struggling operationally. Saddled with 1970’s-era technology, the agency was consistently late delivering first pension checks and health insurance. Customer service was poor but the cost per transaction was high. It would’ve been easy for leadership to turn their future over to the vendor with the best pension administration system.

Instead, ORS took a holistic approach. They created a strategy map and balanced scorecard to provide clarity for the organization’s vision and goals. They mapped, streamlined and redesigned business processes so their new system would automate best practices. They assigned cross-functional process owners who made sure functional areas collaborated to deliver great results for their customers (members). And yes, they implemented a new IT backbone.

The results: ORS realized a 30% increase in capacity and established good customer service prior to implementation of the new IT system. The new IT system took them to the next level, where ORS consistently maintained industry leading cost-per-transaction scores in benchmarking studies. The cross-functional process governance has helped ORS maintain outstanding performance for more than 20 years.

If ORS had skipped business process analysis and just focused on the new IT system, they may have seen a good bump in short-or medium-term performance. By doing it right, they got much, much more bang for the buck.

The moral of these stories: Don’t get fooled into skipping as-is process mapping and analysis.

Three Decades, Two Pieces of Bad Advice, One Inarguable Truth

I got my first job out of college in 1986, in time to see the heydays of Quality Circles and TQM. In the decades that followed, I saw the rise and fall of Business Process Reengineering, ISO 9000, Six Sigma, Baldrige criteria, Lean, Lean Six Sigma, and other lesser-known methodologies. That’s normal. Management fads come and go. What stuck over that time is the importance of the business process.

The business process is the glue that connects our strategy, operations, culture and technology in a cohesive system. I’m not saying process is the center of the universe, just that it’s the vital part in delivering holistic solutions.

That’s why it’s so important to understand your business processes before you initiate major change. And, if you have a major change initiative – especially an IT/ERP implementation that is going to impact how work gets done across the organization – then you must get your team members involved on day one.

That’s my “expert advice.”


Trademarks of referenced products:

Three Decades, Two Pieces of Bad Advice

Part 1: Expert Mistakes on Change Management

by Paul King

Over my 30 years at Orion, I have had the opportunity to observe a lot of IT projects and collaborate with many IT consultants. It’s inarguable that the right technology implemented the right way can deliver dramatic improvements in customer satisfaction, revenue and efficiency. However, too many projects fall far short of the intended ROI – in part due to “expert advice.”

In my experience, the two most misguided examples of expert advice are:

1) Start change management efforts as soon as the new IT system is implemented. We need to make sure people use the new system and drop their old workarounds.

and

2) Don’t bother with as-is process mapping. The new ERP/CRM/SFA/Cloud system will deliver best practice processes.

We Must Force the Users (our customers) to Change

Forcing change

A change management expert could easily write a book about everything that’s wrong with the first piece of advice. The goal of change management isn’t to coerce people into using the new system as the vendor intends; it’s to involve and engage everyone’s heart and mind so that we implement a solution that yields the highest return on investment… and to foster a sense of “ownership” throughout the organization. That sense of ownership is what makes performance improvement sustainable.

You might think “coerce” seems like too strong a word, but it accurately reflects the perspective of some IT professionals. Here is a true story to illustrate this mindset.

Back in 2016, I attended PRISM – the conference for information systems professionals who work in public employee retirement agencies. After a breakout session on change management, I headed back to the tradeshow floor with other vendors, most of whom sold software or implementation consulting. I asked one of my colleagues what he thought of the session.

At first, he offered a couple of positives sentences that generated gentle nods from the two other gents. Then he blurted out:

“For me, change management is getting the user to use the new system. These people think they can just ignore the new system and keep using their personal spreadsheets, even though their employer just spent millions of dollars on an upgrade. Change management is getting the user to change. Am I right or am I right?”

At this point, the gentle nods from his peers became vigorous. It was like watching a trio of bobblehead dolls.

To be fair, it’s important to point out his attitude was not a function of arrogance or the need for control. He was frustrated – frustrated because he had multiple clients whose ROI lagged due to poor user adoption. Even though he heard the words of the change management professional in the training session, he did not really believe them because his experience told him the user is the problem. Chances are, this consultant participated in or led several projects that achieved technical success but never quite got the human side of change management right.

Change management begins on Day 1. Not on Day 1 after we’ve determined the solution. Not on Day 1 after the technology is implemented. Not on Day 1 of end-user training as we go live. No, it must be Day 1 of the entire initiative.

What does good change management look like? It should deliver a:

There are a lot of good models (Kotter, ADKAR, Nudge Theory, etc.) that can help you achieve these outcomes. I like an approach my colleague Ralph Smith created called CODE. It’s a question-based approach that helps you think through the technical, behavioral and cultural issues that are key to achieving the intended ROI and sustainable performance improvement. Regardless of the methodology you choose, make sure you engage stakeholders from the very beginning, before the “perfect solution” is designed or implemented.

Part 2: Experts Mistakes on Process Mapping

Three Decades, Two Pieces of Bad Advice

Experts Make Mistakes, Too

by Paul King

Over my 30 years at Orion, I have had the opportunity to observe a lot of IT projects and collaborate with many IT consultants. It’s inarguable that the right technology implemented the right way can deliver dramatic improvements in customer satisfaction, revenue and efficiency. However, too many projects fall far short of the intended ROI – in part due to “expert advice.”

In my experience, the two most misguided examples of expert advice are:

1) Start change management efforts as soon as the new IT system is implemented. We need to make sure people use the new system and drop their old workarounds.

and

2) Don’t bother with as-is process mapping. The new ERP/CRM/SFA/Cloud system will deliver best practice processes.

No as-is analysis is like no parachute

Implementing new IT without As-Is analysis is like…

A change management expert could easily write a book about everything that’s wrong with the first piece of advice. The goal of change management isn’t to coerce people into using the new system as the vendor intends; it’s to involve and engage everyone’s heart and mind so that we implement a solution that yields the highest return on investment… and to foster a sense of “ownership” throughout the organization. That sense of ownership is what makes performance improvement sustainable.

You might think “coerce” seems like too strong a word, but it accurately reflects the perspective of some IT professionals. Here is a true story to illustrate this mindset.

Back in 2016, I attended PRISM – the conference for information systems professionals who work in public employee retirement agencies. After a breakout session on change management, I headed back to the tradeshow floor with other vendors, most of whom sold software or implementation consulting. I asked one of my colleagues what he thought of the session.

At first, he offered a couple of positives sentences that generated gentle nods from the two other gents. Then he blurted out:

“For me, change management is getting the user to use the new system. These people think they can just ignore the new system and keep using their personal spreadsheets, even though their employer just spent millions of dollars on an upgrade. Change management is getting the user to change. Am I right or am I right?”

At this point, the gentle nods from his peers became vigorous. It was like watching a trio of bobblehead dolls.

To be fair, it’s important to point out his attitude was not a function of arrogance or the need for control. He was frustrated – frustrated because he had multiple clients whose ROI lagged due to poor user adoption. Even though he heard the words of the change management professional in the training session, he did not really believe them because his experience told him the user is the problem. Chances are, this consultant participated in or led several projects that achieved technical success but never quite got the human side of change management right.

Change management begins on Day 1. Not on Day 1 after we’ve determined the solution. Not on Day 1 after the technology is implemented. Not on Day 1 of end-user training as we go live. No, it must be Day 1 of the entire initiative.

What does good change management look like? It should deliver a:

There are a lot of good models (Kotter, ADKAR, Nudge Theory, etc.) that can help you achieve these outcomes. I like an approach my colleague Ralph Smith created called CODE. It’s a question-based approach that helps you think through the technical, behavioral and cultural issues that are key to achieving the intended ROI and sustainable performance improvement. Regardless of the methodology you choose, make sure you engage stakeholders from the very beginning, before the “perfect solution” is designed or implemented.

Skipping As-Is: If everyone could just buy best practices, life would be easy.

I don’t blame the salesman for telling you this car, this washing machine, this cell phone or this ERP system will change your life. Caveat emptor. But the system implementer should know better.

Sometimes, if you have a smaller organization with relatively simple processes, you can take the ERP/CRM/SFA software out-of-the-box and just force-fit operations to the new technology model. No need to map the current state. For most organizations, it’s not that easy.

This lesson has been learned the hard way, over and over and over. I first witnessed it in the 1990s when one of the Rockwell companies invested in SAPTM. After what was considered a “successful” implementation, on-time deliveries plunged from above 90% to just 15%. Unfortunately, this was not an isolated incident; many more companies faced similar operational crashes as they rushed to implement ERP systems in hopes of fending off the greatly feared Y2K bug. At Orion we joked, “Let’s develop a ‘sap recovery’ system.”

(It wasn’t really a knock on the SAP product. They just happened to have by far the largest market share back then. Not long after 2000, the City and County of Denver hired Orion to fix their processes following a disastrously successful PeopleSoftTM implementation.)

Why did so many smart, talented technology professionals fail to see the perils of ignoring as-is business processes? For most of us, it was just the way we were taught. In one of the great ironies of my professional life, I started out as a hotshot programmer who thought “process” was a waste of my time. I did not need to draw a process map – I could see it in my head. In my mind, what really mattered was the elegant and efficient set of formulas I could devise to solve the problem. (In the 21st century, I guess they’d call it an algorithm.)

It wasn’t until I began interacting with customers and going to work sites (manufacturing plants, hospitals, government offices) that I understood that “process” is actually how work gets done. It’s how people create value. That epiphany changed my career. In some ways, it is why Orion came into being.

Many systems implementers have begun to talk the talk about business processes. Not enough of them are walking the walk. Mapping and analyzing as-is or current state business processes is not about drawing boxes and arrows. It certainly not about mastery of BPMN or a particular software tool like VisioTM, BlueworksTM, or ProcessManagerTM.

Creating charts and documenting SOPs is the easy part. The magic of as-is process mapping comes from drawing out the nuances, the necessary (and unnecessary exceptions), the key handoffs, and the customer experiences that make your processes sing. Collectively, I like to call them “process wisdom.” These ingredients create the special sauce that’s unique to your customers or your employees or your culture.

No product is going to have this special sauce out-of-the-box. By understanding and embracing what makes you special, your organization can determine which limited customizations or process designs will enable you to get the most out of your IT investment without undermining your unique capabilities/characteristics.

Other benefits of performing as-is analysis before making a major IT purchase include:


For other perspectives on the importance of doing current state analysis for leaping forward with an IT implementation, please listen to these short videos from two of my partners:

Bob Boehringer – Do NOT Skip As-Is Analysis
Mandy Dietz – Process Before IT


You can pay me now or you can pay me later

The City and County of Denver is not the only organization that called on Orion to help them recover from the operational pain caused by an ERP/IT implementation that did not include sufficient upfront process analysis. One of the most dramatic examples is from an electric utility on the East Coast. This large organization paid a top-tier consulting company tens of millions of dollars to implement an emergency management system. The system proved completely inadequate during Hurricane Sandy.

In each of these cases, the consulting costs of fixing the problem weren’t as dramatic as the old Fram oil filter commercial. The real pain came from the unexpected operational costs, lost market share, and damaged customer relationships that accumulated in the weeks and months following a “successful” go-live.

On the flip side, some of the greatest client successes Orion has witnessed came in organizations that understood the importance of the business process. There are several stories I could share from organizations whose leaders understood the wisdom of analyzing their processes before advancing to automation, but my favorite is from the Michigan Office of Retirement Services (ORS).

Back in 2000, ORS was struggling operationally. Saddled with 1970’s-era technology, the agency was consistently late delivering first pension checks and health insurance. Customer service was poor but the cost per transaction was high. It would’ve been easy for leadership to turn their future over to the vendor with the best pension administration system.

Instead, ORS took a holistic approach. They created a strategy map and balanced scorecard to provide clarity for the organization’s vision and goals. They mapped, streamlined and redesigned business processes so their new system would automate best practices. They assigned cross-functional process owners who made sure functional areas collaborated to deliver great results for their customers (members). And yes, they implemented a new IT backbone.

The results: ORS realized a 30% increase in capacity and established good customer service prior to implementation of the new IT system. The new IT system took them to the next level, where ORS consistently maintained industry leading cost-per-transaction scores in benchmarking studies. The cross-functional process governance has helped ORS maintain outstanding performance for more than 20 years.

If ORS had skipped business process analysis and just focused on the new IT system, they may have seen a good bump in short-or medium-term performance. By doing it right, they got much, much more bang for the buck.

The moral of these stories: Don’t get fooled into skipping as-is process mapping and analysis.

Three Decades, Two Pieces of Bad Advice, One Inarguable Truth

I got my first job out of college in 1986, in time to see the heydays of Quality Circles and TQM. In the decades that followed, I saw the rise and fall of Business Process Reengineering, ISO 9000, Six Sigma, Baldrige criteria, Lean, Lean Six Sigma, and other lesser-known methodologies. That’s normal. Management fads come and go. What stuck over that time is the importance of the business process.

The business process is the glue that connects our strategy, operations, culture and technology in a cohesive system. I’m not saying process is the center of the universe, just that it’s the vital part in delivering holistic solutions.

That’s why it’s so important to understand your business processes before you initiate major change. And, if you have a major change initiative – especially an IT/ERP implementation that is going to impact how work gets done across the organization – then you must get your team members involved on day one.

That’s my “expert advice.”

 

Trademarks of referenced products:

sea plane awaiting departure

A tale of customer experience

I was recently in the Caribbean for a family member’s wedding, and we stayed at a resort that had an absolutely wonderful staff. The front desk personnel were cheerful and helpful, and got our trip off to a very positive start (“We have a wonderful welcome drink to offer you — lemonade mixed with ginger and rum. Would you like one or two?”) We had lunch and drinks by the ocean and the wait staff and bartenders were friendly and timely. Good food. The valet drove us to a wedding event himself to keep us from being late. And on and on and on. It was fantastic. Then, as we were loading the bags in the taxi for the ride back to the airport, the valet asked:

“Will you be coming back to our island?”

Simple question, right? Especially from this man we were fond of because, after all, he had been so helpful. I would have actually felt guilty to say no at that point. But when he asked the question, my business brain took over and a dozen things ran through my head. The taxi service on the island was a per-person charge, not a per-trip charge. Four of us round trip to a wedding dinner cost us $200 for a 6-mile ride, which made my head spin completely around. But the resort doesn’t set the taxi pricing, so that isn’t their fault. The convenience store outside the resort had hours of 9:00-7:00, but they were on “island time”- meaning that the hours posted are more guidelines than rules. We showed up at 9:00 for coffee and supplies and no one was there. We waited until 9:20 and nobody showed up, which was a very inconvenient way to start the day — but that wasn’t the resort’s fault either. There were multiple things about the trip that impacted our visitor experience in a negative way, but very little of it had anything to do with the resort.

So what’s the point? When a business thinks about customer experience, it’s important to think about things from a big-picture perspective. If you focus solely on issues you can completely control, then you may not get all the information you need. Our decision to return to the island would definitely be impacted by the peripheral stuff. What should the resort do to encourage more repeat business? Well, they could lobby their government to change the system for charging taxi fares… or they could offer their guests a coupon for an appetizer (or a ginger-rum-lemonade!) whenever they return from a long taxi ride. Some people wouldn’t take it — but they would remember it. And those that did take it would almost certainly spend more money onsite — win-win. They could potentially incorporate a convenience store into the resort property so they could manage the hours. And so on. But the one thing they can’t do is sit back and say, “We do our part — the rest isn’t our problem.”

So what did I say to the valet when he asked if we’d return? I said yes, of course. I didn’t want to be a jerk…

Ralph Smith

 

No Vacancy sign

How to use a powerful technique (stratification) to find answers hidden in a large pool of data

Suppose you are a hotel manager and your occupancy rate for the first five months of the year has been steady: 72% – 71% – 73% – 70% – 71%. Corporate headquarters has just announced large incentive bonuses for all hotel managers who deliver an occupancy rate of at least 85% in the coming month.

What will you do to get to 85%?

I’ve been posing this question in seminars for years, and heard both obvious and unorthodox answers:

While many businesses certainly do take a ready-fire-aim approach to solving business problems, this is a tailor-made application of the analytical technique known as stratification — breaking a large data set down into component classes to see what can be learned. For example, what if we broke the overall occupancy rate down by day of week and got the below:

Stratification - Occupancy by Day of Week

This gives an average occupancy of just over 71%, which is line with the year-to-date data. It also demonstrates crystal clearly that weekends and weekdays are dramatically different – which is the profile for a hotel in a business district. Think about the impact of the idea to reduce prices by 15%- it is a lose-lose proposition. Since the hotel is basically full 4-5 days per week already, a 15% reduction will cut into revenue-per-room without adding significantly more guests- ouch. And a 15% reduction on the weekend is not likely to draw a lot more people to a business district. This is a great example of the fallacy of proposing a global solution to solve a specific problem — low weekend occupancy.

What if the stratification by day of week didn’t reveal anything useful? Still valuable information because it enabled us to rule something out as a potential cause for variation. But since it doesn’t solve the problem of getting to 85%, we can stratify other ways. Suppose you choose to look at historical data stratified by month and got this picture:

Stratification - Occupancy by month

This would be representative of a hotel that is in a summer resort location; jammed full in the hot weather months but steady at a lower occupancy rate in the off season. So, if headquarters is telling you that you’ll get incentives for hitting 85% in June… what will you do? Spend time and effort to set up package deals with local vendors? Not unless the deals are profitable on their own, because you don’t need it to get to 85%. Close down a wing of the hotel so the occupancy denominator is smaller? Only if you want to take a significant revenue hit to meet a target you are certain to meet anyway.

So is the “solution” to sit back and do nothing? Of course not! You need to get busy creating a narrative that supports the fantasy that the occupancy rose in June specifically as a result of the actions you took- and then taking credit for the rise when it happens. (Sorry, was that out loud?)

The point is that stratification is an extremely useful technique, whether executed via sophisticated algorithms on large and complex data sets or via pivot tables in Excel. It can help you target specific problems and formulate specific solutions… and hopefully get those occupancy incentives!

More from Ralph Smith

Stratification is one technique Orion teaches in workshops like:

Each of these workshops can be customized to meet your company’s specific goals.

What happens in the blender?

A key consideration when selecting process improvement solutions

Suppose you and a few friends go to a local restaurant, and one of your friends orders a strawberry-banana smoothie. He watches it being prepared and sees that precisely 5 strawberries are placed in the blender. Once the mixing is complete, he tastes it and says:

“Wow, that 3rd strawberry is really delicious!”

Is that realistic? Of course not… at least when the subject is smoothies. It’s possible to evaluate the taste of the 3rd strawberry before it hits the blender. But once the strawberries are mixed with the other ingredients, it’s a completely different story. The interaction makes it impossible to accurately assess their individual taste.

The same is true when it comes to process improvement. I worked in a children’s hospital once that was trying to improve the utilization of their MRI machines. They pinpointed several problems, many of which had simple fixes:

There were a few more, but you get the idea. The hospital implemented a wave of priority one recommendations at the same time, and utilization went up 12%. Good news? Certainly… but there could be smoothie implications.

How successful was each solution? Some analysts might break it down as if each solution was independent- shift time adjustments were responsible for 2.4%, improved specificity of instructions contributed 5.2%, etc. But that can be like evaluating the taste of each strawberry. If you implement six solutions at once, they all go in the blender and interact. There’s a critical piece of information here that serves as a great example of the dangers of assuming independence: many parents didn’t realize their kids needed to be put to sleep for an MRI. This implies time to get them to sleep and for recovery, which is why the procedure took four hours.

So what? Well, the pre-procedure call was conducted very close to the day of appointment. When the scripting was changed it could definitely increase the on-time arrival percentage for the families that showed up. Unfortunately, it could also increase the last-minute reschedule rate when families were told they would need to be at the hospital for four hours. That “solution” could actually be damaging to utilization, because the hospital couldn’t substitute a patient in with so little notice. Without this “improvement” they might have gone up 16% instead of 12%.

Another response to the question of how successful each solution was could be “who cares- we went up 12%?” The above illustration shows that reaction also misses the point.

So what’s the best approach? Is it the glacially slow and terminally boring method of making one change, measure, make one more, measure, and so on? Could be. But the best-case scenario is having enough process knowledge to determine which subset of potential solutions truly are independent from each other.

That’s when things will improve the fastest and the smoothiest.

More from Ralph Smith

Unlocking Hidden Ways to Improve Speed, Lower Costs and Eliminate Headaches

Evaluating a process map

Many processes seem very simple at first glance. We expect the workflow to be as easy as 1, 2, 3 and done. In reality, there is usually more complexity under the surface – especially if good process documentation is not available.

process documentation

As my colleague, Steve Wall, says getting from Point A to Point B in business is usually more circuitous than a straight line. This could be due to handoff delays, bad inputs that cause rework, or many other factors that seem easily avoidable in hindsight. Process mapping and process documentation initiatives are the easiest ways to reveal and remove these twists and turns.

Orion has facilitated hundreds of process documentation projects over the last three decades. Many of these efforts focused on transformation or information technology projects but most organizations were simply trying to get a handle on operations and establish their own best practice processes. This blog addresses some common themes that emerge during documentation projects. They include:

  1. People Variation – The “same” process being executed using different methods.
  2. Customer Variation – The unintended Burger King syndrome.
  3. Sequential Processing – Siloed work that causes delays and slows cycle times.
  4. Unbalanced Work – A process undermined by the weakest link in the chain.
  5. Handoff Issues – Every department is doing great job but somehow…
  6. Bad Inputs – We built Band-Aids and workarounds rather than fix the root cause.

We hope you benefit from learning about these problems/opportunities. Or probletunities, as my colleague Susan Williams used to say. Special thanks to Bob Boehringer and Ralph Smith for providing some of the real-world examples I used in this blog.

Process Doc Opportunity #1: People Variation

Finding Your One True Process

People variation at IRSThere is an old joke that if you don’t like what you heard from the IRS, call back in 15 minutes and see if you get a better answer from a different representative.

Most organizations do not have the regulatory complexity that may cause output variation at the Internal Revenue Service but we frequently see different people executing the “same” process in different ways in all types of organizations. I do not mean stylistic differences like you pick up the phone with your left hand and I pick up the phone with my right hand or Representative 1 responds to email inquiries first and then voice messages whereas Representative 2 prefers to mix it up. I mean significant differences in workflow, methods or emphasis.

How does this happen? Partly, it’s just human nature. We instinctively want to improve the things we do. Can I find a quicker route to work? How can I be more consistent shooting free throws in basketball? Can we get the kids out to school with less chaos in the morning? At work, this typically means coming up with ad hoc ideas to deal with bad inputs or to alleviate specific customer complaints.

Different managers and different process performers will put their own spin on how work “should be done.” When a new employee comes along, they will learn a customized version of the work processes from their mentor. Within a couple of years, there can be numerous unofficial versions of any given work process. All are well-intended, but collectively they often undermine both your organization and its customers.

In the following fictitious example from a financial services organization, two customers contact the firm because they think there was an error in the interest calculation on their most recent statement. In each case, the Customer Service Rep creates a record in the CRM and sends a message to the testing department. Here is where things diverge.

Testing Rep 1 uses the standard process that requires multiple validations using the firm’s ERP system. Testing Rep 2 employs an Excel macro workaround she developed a few years earlier. On the maps below, you can see the critical process differences highlighted with starbursts. Map #2 has fewer steps for the Testing Rep. The Excel macro is “unauthorized.” (Note: This is surprisingly common in companies. Team members will often resist giving up their workarounds and special programs, even after a technology upgrade is implemented that would make the workaround obsolete.)

Flowcharts: People variation in business process

As a result of using the macro, Testing Rep 2 needs an additional inspection point. She can’t risk an error slipping through. She must also make manual entries into the ERP and manually contact the Customer Service Representative when the question is resolved. These manual operations may introduce errors or delays.

So, does that mean Testing Rep 1 is doing it “right” and Testing Rep 2 is wrong? Maybe. It is more likely that Testing Rep 2 and other colleagues have added value to the process in different ways over time. In environments with limited process management (i.e. most organizations), this added magic gets trapped in a less-than-optimal process flow and is not shared with other people who are executing their versions of the “same” process.

A collaborative process documentation project brings all that magic to the surface, while revealing inefficiencies and inconsistencies. By working together to create the “one true process,” your organization can establish its own best practices and base all future improvements on that agreed-upon standard.

Want to learn more? Check out Bob Boehringer’s video: Repeatable vs. Reproducible.

Click here to learn more about Orion’s Business Process Documentation Services.

Click here to learn more about Orion’s Process Mapping training options.

Process Doc Opportunity #2: Customer Variation

Overcoming the Unintended Burger King® Syndrome

Burger King logoThe fast food restaurant Burger King is noted in marketing circles for its great and not-so-great advertising campaigns. Perhaps their most successful slogan was “Have it your way.” The value proposition in their battle against McDonald’s was simple: We will make your burger the way you like, not one-size-fits-all like the other guys.

Of course, in order to make that work, Burger King’s processes and kitchen layout were created to deliver customized burgers quickly. Unfortunately for many organizations that are customer-responsive, customer-specific activities are not planned as thoroughly. Ad hoc changes –some of which were intended to be one-time events– add complexity, cost and have a negative impact on overall customer satisfaction.

Orion has been fortunate to support process improvement and member satisfaction initiatives for multiple public pension agencies across the United States. A public pension agency manages retirement services for public employees like teachers, police officers, administrators, etc. These employees are the agencies’ members. The business environment is usually very member-focused, meaning staff will go the extra mile for their customers be they the members themselves or the departments (e.g. Police) the members work for.

Customer focus is certainly a worthy attribute… but it can go too far. On a process-by-process basis, introducing and maintaining many exceptions for individual customers can create a great drag on the system as a whole. Unless your processes are designed for mass customization (a la Burger King) then bad outcomes are likely. The next time the customer calls, a different representative may not know this customer’s special service workaround. That could make for an unhappy customer or a customer who insists on always having a representative of choice. If the special service becomes the standard operating procedure – regardless of whether most customers need this workaround – then time and cost will be added operations. It may also be a net negative for overall customer satisfaction.

The same goes for corporate clients. A common process among public pension agencies is called Service Purchase. In some circumstances, employees can “purchase” more service time thereby moving them closer to their retirement date. At one of Orion’s public pension clients, the agency had several variations of their Service Purchase process. To some extent, this was expected. Different employers (police, teachers, etc.) will often have different business rules. However, when we opened up the black box, there were 15 distinct variations of the Service Purchase process. These could involve different workflows, different IT systems, different validation steps, etc. The complexity made life difficult for staff and members… and added no benefit for the “corporate clients.”

It was an example of unintended “mass customization.” To solve the problem, the pension system created a “happy path” business process for Service Purchase, then added employer-specific business rules to individual steps as needed. For instance, if the teachers and police had different interest calculations, then that distinction only applied to a single process step. The changes greatly improved cycle time while reducing cost and rework.

In the moment, it may feel good to cater excessively to customer demands –to go the extra five miles– but in reality, sometimes the right thing to do is make sure you have it your way, not the various ways customers may demand.

Unintended mass customization or excessive customer-based variation is one of the most important – and often surprising – revelations from a process documentation project. You open the box on a process that “everyone” understands, multiple versions may pop out like that old spring snakes in a can toy. Cut down on that “customer variation” and performance will soar.

Click here to learn more about Orion’s Business Process Documentation Services.

Click here to learn more about Orion’s Process Mapping training options.

Burger King is a registered trademark of Burger King Corporation.

Process Doc Opportunity #3: Parallel vs. Sequential Processing

Reducing Cycle Time by Improving Teamwork and Coordination

The fastest relay team in the world can run 400 yards in less than 37 seconds. Four people running next to each other can run a collective 400 yards in less than 10 seconds.

Of course, the purpose of a relay race is for the team to run in sequence. In business, the goal is to deliver value to your customers as quickly and cost-effectively as possible. Sequential processing is bad for both business outcomes. Parallel processing, when possible, can save time and cost.

In 2020, the world got a giant example of sequential versus parallel processing: Operation Warp Speed. Traditional vaccine development takes a lot of time (5-10 years) and money ($500 million on average). Due to the low success rate of potential vaccines, pharmaceutical companies usually follow a linear sequence of steps, with long pauses for testing and data analysis.

During the early days of the COVID-19 crisis, it was clear the traditional process did not meet the needs of the global emergency. Here is an illustration of the Operation Warp Speed vaccine development process:

The work performed in each step was not reduced, though trial phases were combined. Certain steps were performed simultaneously with shorter breaks between steps. Pharmaceutical companies also prepped for manufacturing before vaccines were approved. This added to the financial risk for each potential vaccine project but given the number of “customers” to serve, it was a risk companies were willing to take.

Regardless of what you think of the post-emergency use of COVID-19 vaccines, Operation Warp Speed was a dramatic example of what is possible when you can move from sequential to parallel processing. In this case, the 5- to 10-year cycle was reduced to 1-2 years.

A more mundane example is the classic IBM Credit story. This is an extreme example of sequential processing driven by task specialization. Similar to a relay race, each “swim lane” performs a series of tasks before passing the baton to the next player in a different lane. This workflow is not necessarily bad but it is always an opportunity to reconsider process design.

Figure 1: Credit review process, pre-improvement

In general, there are two ways to improve such a flow. IBM took the dramatic approach of reengineering. They leveraged information technology to enable the consolidation of several different job roles into a generalist position. (Figure 2.) In many cases, it is possible to enable some parallel processing by improving information sharing and streamlining inspection checkpoints. The results could look like Figure 3. In either case, cycle time and handoffs are reduced.

Figure 2: Credit review process, reengineered

Figure 3: Credit review process, improved (concept)

Excessive reliance on task specialization and sequential processing is an opportunity that “jumps off the process map” and is easy to explore during process documentation workshops. Optimizing workflow will help your team win the race!

Click here to learn more about Orion’s Business Process Documentation Services.

Click here to learn more about Orion’s Process Mapping training options.

Process Doc Opportunity #4: Fixing Unbalanced Work

Increasing Throughput by Helping the Weakest Link in the Value Chain

My all-time favorite process improvement video is Lucy in the Chocolate Factory. It teaches lessons about management style, training, and the risks associated with unbalanced workflow.  It’s also a fun illustration of the theory of constraints.

If you do not have time to watch it, Lucy and her friend Ethel get a job in the wrapping department of a chocolate company. Their task is to take freshly made pieces of chocolate and wrap them in tissue paper. The chocolate rolls in on a conveyor belt from the kitchen and then rolls out to the packing room. Sounds simple enough, but…

Lucy and Ethel get no training but are forewarned “if one piece of candy gets past you, You’re Fired!” Things start off well, but as the pace of the conveyor belt quickens, havoc ensues. While it’s easy to see the ladies as ineffective employees, it’s clear by the end of the video that the kitchen turns out chocolate much faster than any two people could wrap it.

Suppose the sales department said, “We need more chocolate. Demand is higher than production.” Would it make any sense to invest money in new kitchen machinery that would produce even more candy?  No, because the wrapping department still limits how much candy we can deliver to our customers. A faster machine would just make the process more unbalanced.

Orion ran into a similar – but less funny – situation in Dakota County, MN. Child support was an important process that made sure single parents received the financial resources they were due. The level of effectiveness was also critical because there were federally funded incentives to close a high percentage of cases.

The process sailed through all the swim lanes until it got to Legal. Not only was the Legal team’s work more complicated, but it was also dependent on the calendars of judges… something they could not control. The Legal department was the bottleneck.  Dakota understood the Lucy-in-the-Chocolate-Factory management approach was not the answer. (“If one case is not closed on time, you’re fired!”)  They needed to take the load off Legal.

One simple solution was to have clerks instead of lawyers show up in court for uncontested hearings. There was no legal mandate to have a lawyer if the case was uncontested, but they’d always done it that way. This allowed Dakota to add more capacity without adding more cost. It led to a greater level of success in their mission – getting financial resources to single parents. It also helped them qualify for an additional $1 million in support from the federal government.

When documenting processes, always try to find the bottleneck or the weak link in the chain from a capacity perspective. Eliminating that bottleneck is crucial to the effectiveness of any process improvement solution.

Click here to learn more about Orion’s Business Process Documentation Services.

Click here to learn more about Orion’s Process Mapping training options.

"I Love Lucy" is a trademark of CBS Broadcasting.

Process Doc Opportunity #5: Handoff Issues

Identifying Points Where Teamwork Fails

In business, a “handoff” occurs whenever the workflow, data or a work-in-progress passes between individuals, departments or external entities. On a cross-functional process map or swim lane chart, this occurs whenever the process flow (arrow) crosses a horizontal line.

Flowchart with handoffs

As illustrated in Jordan Smith’s blog, the quintessential metaphor for a handoff failure is the dropped baton in a relay race. The dropped baton is a catastrophic failure from which no track team can recover during a competition.

Most handoff problems in business are not catastrophic. Indeed, they often go unnoticed by management. It could be as simple as work sitting in the proverbial inbox. Or data that needs to be reformatted due to different standards in adjoining departments. The latter example not only causes delays, but it opens up the possibility of errors during the unnecessary conversion.

In the example above, five handoffs are noted with red circles. For this Hiring Approval process, two of the handoffs proved critical. During the first handoff – when the line manager submitted a Request to Hire form to his executive – not understanding the executive’s decision criteria often led to insufficient justification. As a result, an important hire could be disapproved.

The second troublesome handoff was between the HR Manager and the Recruiter. The Recruiters supported multiple functional departments and were not given any sense of the relative urgency for each hire. Thus, the process could stall for weeks before the Recruiter began work to get resumes so the company can fill a critical position.

Bob Boehringer: Why Handoffs Fail (Vimeo)

Orion had one client that was rolling out a new software solution to its salesforce. This company sold and serviced Point of Purchase (POP) credit card devices, the ones you swipe or tap or insert your credit and debit cards into. Their primary customers were mom and pop independent convenience store owners.

The goals of the software investment were to:

Clearly a win-win scenario that would make life easier for the customers and generate more revenue with fewer hassles for all parties. But…

Each store had a unique set of IT configuration requirements. Those requirements needed to be identified upfront so the POP devices would be properly configured before being shipped. If the device wasn’t properly configured, store owners would call customer service to complain that the new device did not work. Since the call center rep did not have eyes on the ground, figuring out what was wrong could be difficult and time-consuming.

Therefore, it was incumbent upon the sales staff to invest their time in gathering all the information required when they were closing the sale at each store. Over the years, this company developed a “sales driven” culture. The sales staff focused almost exclusively on sales and relied on support staff to clean up the details.

The new solution required a change in sales staff behavior, but sales management neither provided adequate training nor enforced the change in process due to their fear it would negatively impact sales. That resulted in a bad handoff between sales and the POP configuration team. The sales team continued to do a great job selling. The new software solution was technically a great success. However, due to this bad handoff, the new solution was rolled out with a dramatic “thud.”

The cost and time savings did not materialize. The need for the sales support staff was increased rather than diminished. The new software solution still had great promise, but that promise would not be realized until the handoff was fixed.

When analyzing a process map, each handoff is worthy of inspection. These are spots where performance improvement opportunities may be found. They are also good pulse points to monitor both operational performance and cross-functional team effectiveness.

Click here to learn more about Orion’s Business Process Documentation Services.

Click here to learn more about Orion’s Process Mapping training options.

Process Doc Opportunity #6: Bad Inputs

Seeing and Fixing “Garbage In” So Your Process Works as Intended

In order for a process to function as it was designed, as it was intended… it MUST be provided all the inputs it requires to be successful. The notion that “garage in” yields “garbage out” is not a new idea. But it is remarkable how often we have become so accepting of this very situation.

That is why Orion includes some level of systemic analysis in any process documentation or process improvement assignment. The analysis can be as simple as a SIPOC diagram or as complex as a full-on System Map. If your process is the black box in the middle of the business system, then we need to understand the quality of its inputs… lest we create a more efficient system of converting bad inputs into unacceptable outputs.

We often think of inputs as information or materials we receive from external suppliers. However, bad inputs from internal suppliers – such as upstream departments or management – can just as easily undermine a good business process.

In the diagram above, Department B and Department C both crunch numbers. The leaders of Department B make sure their staff members use methods and formats which best meet regulatory requirements. Department C uses time frames and formats that best meet customer needs. That requires non-value-added data conversions and sometimes leads to confusing or inaccurate reports. As a result, Department C deals with many customer complaints. However, the root cause of the problem is not within Department C’s processes; it lies in the upstream handoff from Department B.

The company can solve this problem in one of two ways:

  1. Create extra subroutines (and costs) within Department C to make sure the data conversions do not create customer problems.
  2. Fix the handoff – the root cause of the problem.

Too many companies choose option 1. Why? Because they focus on the procedure at hand but did not consider bad inputs that may be undermining the process.

One of Orion’s hospital clients was struggling with wait times for an MRI appointment. They could stretch multiple weeks, even though on paper there was more than enough machine capacity to meet patient demand. It is easy to get caught in the trap of focusing on what happens inside the Radiology Department. What can we do to increase patient throughput? Can we cut out some steps inside the room?

While the hospital was able to find minor improvements within Radiology, it turned out the delays were the result of a mixture of upstream input problems. One example: If you are taking an MRI of a small child then you need to use anesthesia because it’s highly unlikely a six-year-old will lie perfectly still for 20 minutes. However, if the Scheduling Department did not make it clear to the parents that their child should not eat for three hours before receiving anesthesia then Radiology gets a bad “input.”

In this case, there is a significant delay (and machine downtime) while we wait until the young patient can safely receive anesthesia. The hospital eliminated more than 80% of the scheduling delays by resolving this and other input issues.

Bob Boehringer: Cost of Bad Inputs (Vimeo)

One of the most challenging handoff failures Orion encountered was at a financial services company. The handoff was not between departments, but between the customer and the company. The financial services firm needed customer data to do its analysis and make proper investments. In this scenario, the customer was actually a key supplier.

However, multiple customers routinely submitted incomplete data or data that included figures from the wrong date range. Rather than “inconvenience” the customer, the firm tried different solutions over time. These included assigning staff to scrub the data, creating computer programs to identify and correct mistakes, and calling customer staff members to fill in the blanks.

None of these Band-Aids were completely effective… and they consumed both time and money, costs that were not passed along to all customers. The firm finally decided it had to impose a standard electronic format for customer data. Rather than inconvenience to customers, this led to better service, stronger relationships and a better profit margin.

Resolving input problems leads to better business process performance and can also improve cross-functional teamwork. So, before you dive into the black box and start mapping your process, create a SIPOC or System Map so that you understand how inputs are influencing the outputs your process creates.

To learn how to create a System Mapping, click here to consider Orion’s 45-minute webinar.

Click here to learn more about Orion’s Business Process Documentation Services.

Click here to learn more about Orion’s Process Mapping training options.

Conclusion

Documenting your business processes does more than create playbooks that show employees how work should be done. It’s an opportunity to improve performance by:

  1. Defining your One True Process – Establish your best practices by eliminating variation in how work gets done by your people.
  2. Eliminating rampant exceptions or unintended mass customization – Create the happy path for your core customers.
  3. Improving speed of execution by replacing sequential processing (the relay race) with parallel processing.
  4. Optimizing productivity by strengthening the weakest link in your chain and balancing capacity.
  5. Enhancing teamwork –and eliminating unnecessary delays– by fixing handoff problems.
  6. Reducing rework and hassles by stopping bad inputs (“garbage in”).

We hope you enjoyed this blog series. For more guidance on process mapping and analysis, check out 10 Tips for Business Process Mapping.

Paul King