What we do in a Business Process Review (BPR) is pretty straight forward, and we perform several for our clients over the course of a typical year. In the review, we observe how the ERP processes have been built to manage the business. Then, we make recommendations to streamline and improve the processes and procedures related to the flow of data in the company. For example, how to use the ERP to alert procurement of projected material shortages, as opposed to having them look for shortages in a spreadsheet – usually after it was manually updated. In essence, an ERP business process review is a gut check on how things are working, and what can be done to make them better.
Most customers expect our BPR to focus on observing and finding problems. This is a common misconception. You may be surprised to hear this, but unearthing problems isn’t what we do in an ERP business process review. Why? Because we usually hear about the problems before we start. If your issue is material shortages like the example above, it was probably cited as one of the reasons our BPR is needed:
Customer (waving arms): “We have an ERP system, and we use a spreadsheet to find shortages! That’s crazy!”
Customers know what their problems are, they just don’t know how to fix them. That’s where we come in with the BPR: The customer educates us on their problem, we find the source of the problem, and then lay out a plan to fix it. This is no different from any other repair service you may need. I’ve never called a plumber to find a problem. I call a plumber because I know I have a problem and want it fixed.
In some cases, customers will fix their ERP processes on their own once they understand the causes and solutions. In other cases, we manage the project of fixing the issues. Many times, it’s a mixture of both.
Here is something to keep in mind if you want to tackle the issues on your own: Implementing any solution always results in unintended side effects. That is simply the nature of change. We may have given you the solutions to the problems outlined in the BPR, but you won’t have solutions for the inevitable side effects that come with making any type of change. This, along with people poking holes in the new processes, usually derail the project if you don’t have someone with knowledge and experience there to help navigate the twists and turns of the journey.
Is that a plug for our services? I guess it is. But it’s also a fact. Remember, the goal of a BPR isn’t to find problems—it’s to find solutions. And it’s not an actual solution until it’s implemented. In my experience, if help is needed to identifying the solutions, you probably need help implementing them.
When we review the findings of a BPR, it feels good for everyone involved. The customer leaves the meeting with a sense of clarity and direction, and our team is happy to have provided that. But it’s important to note that nothing in the business has changed yet. Knowing what to do and actually doing it are two different things.
To put this in context, let’s back up. Why did we do a Business Process Review to begin with? It’s because a company wanted to use their ERP better to address known business issues. The BPR isn’t the goal; it’s one step toward the goal. It provides clarity and direction, but not actual change. Only by enacting change can the customer reach the goal.
Change is the hard part. This is where resistance shows up. Generally, there is no resistance to change during the BPR. Employees gleefully tell us all the things that aren’t working, how hard it is to get the information they need, and how they know it can be better. Talking about problems and solutions is the easy part. Doing something to fix the problems is much different. It means changing how things are done and going through a learning curve. That is uncomfortable, so a natural by-product is resistance. And there is always resistance. Don’t think your company is going to be different. You won’t be.
Companies that are successful in implementing change have learned how to funnel the resistance into a positive force. They don’t ignore it; they embrace it and deal with it. They understand that it’s OK for employees who are responsible for getting a job done to be skeptical of change. Their concerns need to be heard and addressed. It is the burden of the change agent to prove that the new process is an improvement on the old. After the concerns of the employees are discussed, the process is usually modified for the better. In this scenario, the resistance is a positive force because it was harnessed properly.
At this point, the resistance needs to subside. If it doesn’t, it can derail the entire project because it’s driven by emotion rather than facts. The only thing that can effectively address this type of resistance is strong leadership.
So, what makes a good leader? First and foremost, the leader must believe in the proposed solution. Not believe that’s it’s perfect, but that it’s better than the current process. That belief will tamp down any resistance and keep the project on schedule. If the leader doesn’t believe in the solution, they will become part of the resistance. Once the leader of the project exhibits signs of resistance, the project is most likely going to derail.
The leader also needs to be empowered to make decisions and guide the users through the change. Not empowering the leader is an avoidable error that drastically reduces chances of success. Consider this: The reason for the BPR is to improve the use of the ERP; and this requires change. The leader is leading the company through change. It’s fine for the leader to have oversight, but make sure they are empowered.
Lastly, an ERP expert needs to be involved in the implementation of the solutions proposed in your BPR. If our team is doing an ERP Business Process Review, chances are you don’t have an in-house expert. There is no shame in this. Acknowledge it, let us assist you, and be successful in implementing the change you want.