How to succeed in an ERP project-business process re-engineering (BPR)

I looked at the last post about why to do ERP. As mentioned before, if you build ERP, most people think it's IT.

In that case, I explained, "All projects fail with a 99.9% probability." This is because ERP is only a system that is built on the surface, not an idea.

Project BPR that must be successful before ERP construction

To explain a bit, ERP is a tool that enables integrated management of all resources that go to the company.

In order to operate so well, all you have to do is to leave only the core resources, and in other words, you have to remove unnecessary resources.

From now on, what I'm going to talk about will be about Business Process Re-engineering (BPR), which standardizes and eliminates unnecessary work and establishes a system by looking at the company's work flow. (It is also called PI (Process Innovation) depending on the company.)

BPR is an innovation technique for management innovation activities, and it is a story that applies not only to IT but also to all areas. It is also a task that companies must do someday to jump-up and take a leap forward.

And the ERP project that only moves IT fails 99.9%, and it is BRP that determines the successful ERP. In other words, it is a story that ERP can be successful only if a well-organized and standardized business process is well designed (BPR must work properly). The importance of BPR is not overwhelming, even if more time is known.

Points to note when carrying out BPR projects

The first is that you should not blind your current system.

When starting a BPR project before ERP construction, the usual start is the first IT-driven work process redesign.

This is because, as the company grows, the part that has been organized is the system side, and we are not making manuals, creating flowcharts, or organizing in the field.

However, the system is a product that creates a system for work and work, and there is a lot of work flow in those things.

However, the point to note here is that not all areas are built on a system basis, and it is often a process created by needs rather than a core business process.

Second, the core area and the non-core area must be clearly distinguished.

In the process of designing and standardizing work, a series of flows changes. And for the core tasks of critical companies, those that require standardization, a flexible design is created to create new business value.

However, it is at this moment that the most friction between the consulting company and the business performing the BPR project occurs.

It is very important that the person in charge of the TF in the project is working. However, your work may not be the main process from an enterprise-wide perspective.

Third, standardization is not just for a single company.

As you may have noticed from the foregoing, the core of BRP is not the standardization design of the work I am currently working for. It is a standardization for all group companies.

That's why it's always necessary to keep a cool view, and it's difficult to paint too ideally.

Think about it. How many business processes can the three companies that make and sell clothes, sell online, and farm have common sales processes and move under the same flow?


ERP is a standard system of all group companies, and BRP is a task that defines all the ideas that melt into ERP in advance. If you have BRP, an essential course that has been completed properly, the ERP project will never fail for some reason.