In the course of my travels, I meet with a lot of companies in a wide variety of industries. These companies truly represent a cross-section of American industry and entrepreneurialism. My presentations run from 1 to 10 hours in length. Much of this time is spent discussing their business processes, their current systems, and how they plan for the investment in new technology will help them grow, compete, transform and/or simply keep up with the competition.
I hear a lot of common themes. Every company has unique challenges and goals but the concerns and questions of top executives are usually quite similar. One topic that most concerns executives, regardless of company size, is change management. Executives all understand that SAP delivers functional platforms. I rarely have a President or CFO ask me to show how to post a Journal Entry. On the other hand, they almost always ask how we plan to train their people and make them comfortable with the new software. They also always ask us how we approach helping their employees adopt the new processes and technology. In sum, they want to understand how we will help the people change their processes and in some cases habits built up over years of repetition.
This concern with change management vs technology has become ever present in today’s companies, frankly because technology has become so engrained in society. There are now smart phones connected to the internet than computers. Employees are often pushing paper and entering data in green-screen legacy systems at work while using Facebook and playing video games during lunch. Savvy managers understand the use of technology is no longer intimating. Managing employee use of technology and business process change is often as important as the technology being implemented. I don’t think you can easily find anyone with more than one or two implementation experiences under their belt that would disagree.
Example 1
A good example of human management being more important than the technology comes from a company I worked with that moved from using paper pick tickets to a bar code scanner based system that used directed walk-through picking. This was a large change for the warehouse.
Though the go-live of a new ERP (Enterprise Resource Planning) solution was successful and they were able to ship record numbers of orders within the first few weeks, things in the WMS (Warehouse Management System) began to get ‘funky’. The product was not in bins when the system indicated it should be available. Customers began to complain about missing goods and mispacked orders. These were problems that the barcode scanners should have kept from happening. Initial blame went immediately to the scanners and the warehouse management system. Closer inspection of the transaction logs and a quick cycle count of a few aisles told a different story.
Not all the pickers embraced the new technology. Some long time employees didn’t want to be told what orders to pick and in which order. They certainly didn’t want to use scanners and follow the strict scanning process. They had always picked goods by knowing where everything was located and by reading the box labels in the bin. Also, the paper-based system was also a seniority based system. Senior pickers got to go through the pile and pick the orders they liked then the less senior, etc. Management had meant to disrupt this culture but didn’t anticipate the push back from the employees.
So, for example: instead of pushing boxes back on a shelf to load more product they would simply put it in the empty slot next to the bin they scanned. In other words, they told the system the product was in bin 1 but put it in bin 2. The problem was magnified when the next picker would walk up and look for the product in bin 1 and see it empty. Not thinking to look to the bins left, right, up, and down for the missing product, they would ask for the next bin location. The system, not knowing the product was in Bin 2 would then flag the bin for a cycle count. The cycle count would confirm the product was missing which would trigger an inventory adjustment. It looked like Inventory was ‘disappearing’.
Example 2
Another example: Shortly after the trainers left, some users had also started carrying a clipboard full of barcode stickers. They would not actually scan the product, but simply scan the clipboard when they pulled what they thought was the right product.Coincidently these users were the most vocal about the system not working but were actually the root cause. So, what to do? The first thing was to pull the logs from the WMS. This gave us the data to see who was putting the wrong product into the bins. Once we had the ‘proof’, we sat down to explain one-on-one to the offenders the impact of their shortcuts on their co-workers and the overall efficiency of the warehouse. No one was pointed out at a culprit. The trainers were brought back in to retrain everyone. It was also made generally known how the system allowed us to clearly see who did what and when. Call it organizational truth serum.
Other changes were also made. The product was previously tagged and then placed in a poly bag through which scanning could not be performed. It was time-consuming for the pickers to reach into the bag and scan the product. The pickers had a point, scan the product in the polybags was inefficient. Management made a point of validating this concern and additional bar-code was put on the outside of the poly bag to make it faster and easier to scan product. The WMS was also tweaked to improve some pick paths.
Shortly after this was all implemented, the problems with the WMS simply vanished. Over time the new processes became embraced and the consensus was that they were happy to be done with paper.
Here are some key lessons learned, mostly the hard way, that may help you manage change within your organization.
8 Lessons to learn before implementing a new ERP solution
1) Make sure everyone in every role knows why you have to make the change. No sane organization changes ERPs for fun. There is usually a very good reason a company is going to undertake this process. Your people need to know and understand this reason. You can’t expect people to buy into change if they think it is just for the sake of change. They need to understand why the change is coming and have a vision of how their role will change with the new system. If people are worried about their job security, keeping things quiet will only increase their insecurities.2) Listen to your people. Take time to let them list what works for them in their current process and list what doesn’t. The reality is some people in your organization are probably spending hours a day doing double-entry or following endless click sequences to get things done. I often see people with “I’ve been wasting my life” look when they see how SAP’s ERP solution can sometimes reduce 20 clicks to 1. You may find that people you think will push back may be some of the most enthusiastic proponents of change if you can make their daily lives better.
3) Document everything. I suggest giving people binders and highlighters. Ask them to print out the reports and forms they use and highlight the information they actually care about. The reports that come out of your new system will usually have a different format. It is easy to overlook critical fields and metrics when going through hundreds of reports during a new system go-live. Murphy’s law predicts the column or sum missing from at least one report is the one you actually care about. Highlight only what you care about. The rest can be handled later. Also, be prepared to tell your consultant why that number matters and why you need it printed on paper.
4) Incorporate user feedback where possible. Just because someone is pushing back against new technology doesn’t make them wrong. They often have valid concerns that need to be heard and considered. Incorporating user feedback gives ownership which is key to buy-in. That said, don’t be afraid to say no. It is folly to try to recreate your old system in a new system. Things will change.
5) Help people understand the value chain of a click. Not everyone is going to have less to do. Sometimes users will be asked to enter more data at an earlier step than in a previous system. I have heard many people say “my system only requires me to enter and click X times, I don't want to have to enter more and have Y clicks in a new system. Those people are thinking in terms of their personal job and role and not looking at their part in a business process that often spans multiple departments. Spending a few seconds entering one or two data elements earlier in a business process can sometimes save multiple minutes of labor further along the process chain. It is rare to see pushback here when the full value of a data entry process is understood.
6) Testing, Testing, and more Testing. Testing is the most important phase of implementation. I tell everyone that there is a direct correlation between how well you test prior to go-live and the smoothness of go-live. It will always be stressful but should never be chaotic. Chaos indicates you failed to test something completely or correctly.
7) Training is a process and not just a project milestone. New system training often follows a train-the-trainer approach. It is important those trainers are themselves good at training. Few small to mid-sized companies have dedicated trainers. Fewer still actually invest in sending the trainers to seminars to learn training skills. It is money well spent. It is also important to recognize that not all training methods work best for all people. Some users will read the manual over the weekend and come in on Monday, ready to go. Other users attend the training, do a few practice exercises and are ready to go. Yet other users require one-on-one coaching. It is always worthwhile to identify who will benefit from which approach and make sure they get the help they need in the form they are best able to benefit. It is always time and money well spent. Once you go live – wait 30 days or so and set up some additional training. People often focus on learning their core operations as part of go live. During go-live, they will be absorbing a lot of information in a relatively short period of time. An example is users will start complaining a few weeks after go-live that they wish they could have some information on a screen but not realize a right click of the mouse may actually give them the information. Information overload during training caused the person to hear the information but not to absorb the knowledge. Post go-live training allows people to ask additional questions and sometimes greatly improves end user satisfaction.
8) Watch out for process creep or process backsliding. It is not unusual for people to wait for the consultants to leave and to go back to doing things as close to the ‘old’ way as possible. Management needs to make a point of auditing processes to make sure new processes are being followed. If you identify creep or backsliding, take the time to go back through items 1 – 7. Understand why the backsliding occurred. It maybe you missed a process or didn’t test something correctly. Perhaps the user is frustrated with a system process and feels the need to take shortcuts to keep things running smoothly. Perhaps not enough data is being captured or reported upon so the person needs to keep a side spreadsheet. There are many reasons people abandon new processes. It is rarely as simple as ‘resisting change’.
Every company is different. Every implementation is different. Change management is a constant element of every implementation. Remember, it’s probably not about the technology.
We, at Navigator Business Solutions, understand change management. We have helped more than 500 companies make the change to a World-class SAP ERP solution. Applying our unique knowledge and best practices help make the inevitable change smoother and more effective.
Richard Haugen | VP, Value Engineering
As the Vice President of Value Engineering, Richard helps Navigator customers and prospects select the best SAP solution for their business by acting as a single source of broad, in-depth industry, and product knowledge.
