As a matter of fact, it still happens that a company

spends significant amounts of money (millions

of Baht in Thailand) to replace an existing IT

system, often a patchwork of several software

applications, with one integrated ERP system.

However, once the new ERP is up and run-

ning, the management feels as if nothing

has changed; just a new name, a different

screen layout supporting the  same old

processes and procedures. Why?

​

Imagine a business, maybe in pro-

duction, that has been growing over

time. Visit the factory and you will

typically see many different buildings

housing different business units. Each

building has its own roof (software) and

space has not always allowed the new buildings

to be placed where they really should be, so they are a bit scattered all over the place, compromising efficiency and complicating procedures. One day management decides that this is not working anymore, and asks for the entire business to be put under one and the same roof (ERP system).

​

Following the decision of implementing a new ERP software, two main stakeholders start to work together. The key users from the business who wants to implement ERP and the ERP consultants who configure the ERP software. The key users are somehow senior people with five to fifteen years of experience in that company. They know how the show goes; they are the experts in their department or business unit. The ERP consultants are typically IT technologists. They are experts in their specific ERP module(s) and about how it connects to other modules. They know what can be done in ERP and what can’t. These two groups of people together work out the blue print for the future ERP software configuration; they together build the new roof under which the entire organization will be placed.

​

It is very natural for the key users, to inform the ERP consultants in detail about the currently used work processes without further questioning those processes; after all, they have done it this way for the past decade and it worked. It is also normal for ERP consultants to accept these currently used work processes as process requirements that ERP will have to support; after all, the key users are the process experts and the ERP consultant’s customer. The result however, is a new car, driving down the old roads.

​

Of course, the change to one integrated software covering all business processes will somehow increase efficiency. Similar to implementing ISO 9001:2000 where you have to write down every process to make sure everybody is doing it the same way. But while having everybody doing it the same way is an efficiency increase to some extent, it does not mean that the way itself of doing it is necessarily efficient. The same applies to any ERP system. It can be configured to support all the business processes outlined by the key users, regardless whether these processes are efficient and/or really add value to your business.

​

If you don’t want to buy a Ferrari and then drive at the same speed you did with your old Volkswagen, then you also need to straighten out the roads and eventually remove some traffic lights. This must be done before implementing the new software, i.e., before the blue print phase. It requires a different skillset than that of most ERP consultants and is usually done by Business Process Consultants. The aim of the Business Process Consultant is to eliminate every non-value adding step from a given process in order to make that process as clean and lean as possible. Once the new processes have been confirmed and agreed upon by the Key Users and Management, the ERP consultants come in for the blue print phase and to configure the system.

​

Example: the company has a warehouse with a certain number of items that need replenishment based on stock quantity. Every time the minimum stock quantity is reached, the staff issues a purchase request. The purchase request gets forwarded to the warehouse manager who signs it off before it goes to the purchasing department. This process can without any problem be configured in ERP. But can this process also be straightened out?

When the Business Consultant asked a few process questions such as ‘why does the warehouse manager have to sign every PR?’, ‘what happens if the warehouse manager is absent?’, and ‘how many PR’s out of ten does the warehouse manager reject (not sign)?’ we get interesting answers. He has to check every PR to see whether there is an upcoming event that would need additional quantities of one or more items listed in that PR. If so, the PR would be modified to include these additional quantities. If the manager is absent, the PR would sit at his desk until he is back, and, he never ever rejects a purchase request.

​

Rather than to support the old way, today the new ERP system checks the stock, issues a purchase request when the minimum stock level is reached and sends it directly to the purchasing department. No PR is held up at the warehouse manager’s desk (eliminating the red light) and instead of checking every single PR, he only monitors the material needs of upcoming events and issues a separate event specific PR if necessary, while the basic stock replenishment is completely automated and handled by the new ERP system. In other words, business as usual is fully handled by the system and only exceptions are handled by people; not only a new car, but also a straight, new road.

​

 

Bangkok, August 2013

Published: scribd.com, 29th August 2013

​