IT, Process Mapping and Change Management
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.
2) Don’t bother with as-is process mapping. The new ERP/CRM/SFA/Cloud system will deliver best practice processes.
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:
- Compelling vision that your people can rally around
- Clear understanding of how each role or department will benefit (WIIFM)
- Mitigation strategy for those that will not directly benefit
- Mechanism for many people to participate in defining the solution
- Plan to proactively combat fear
- Communication plan with tailored messages for every level in the organization
- Measurement system to monitor progress
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:
- Business Requirements – Process mapping is the best way to get the requirements right. You can’t get to the business need if don’t understand what the current processes are trying to accomplish.
- Migration Plan – It’s hard to design a path to your future state if you don’t know your current location.
- Immediate Efficiency – As-is mapping reveals what NOT to do. If activities don’t add value, they should be discontinued rather than automated.
- Reduced Cost – By evaluating which business exceptions are truly exceptional, we can reduce the complexity of our system prior to automation. A simpler software solution is less expensive to implement and maintain.
- Data Quality – We don’t want our IT solution to deliver a faster form of garbage-in, garbage-out. Current state analysis will also identify and correct data input issues that undermine performance.
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:
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:
- SAP is a trademark of SAP.
- PeopleSoft is a trademark of Oracle.
- Visio is a trademark of Microsoft.
- BlueworksLive is a trademark of IBM.
- ProcessManager is a trademark of Nintex.