To customise or not to customise

It’s a thorny question that has baffled many.
Ipshita Basu examines the pros and cons of customising ERP.

Your company has decided to go in for an ERP application. The product is selected and the implementation begins. The ERP vendor has promised the moon in its sales pitch. The future with ERP is painted in varied hues. Slowly, however, users realise that certain processes, forms or reports are not in conjunction with company practices. End-users start displaying a negative attitude towards the implementation and grumble about the features. How do we resolve such discrepancies?

Solution or inviting trouble?

The first thought that comes to a layman’s mind is to modify the software. Let’s tinker with the database structure and the layouts to suit our needs. This might solve the problem. Or it could also be the beginning of a series of wrong moves which might jeopardise the entire implementation. The choice is in the hands of the company’s project manager (PM). Every modification in the package will entail some cost—man, machine and money. Generally, the SMB ERP vendors will prefer some modifications without explaining the flip side of these. User companies also lack the expertise to visualise the obstacles in depth. Should we customise or not, and if yes, then to what degree—this is an issue which should be dealt with in depth and diversity before pursuing as it will have far-reaching effects.

To customise…

Most ERP products are generic. There are many industry-specific solutions available, which are designed using industry best practices. Many have processes that help companies comply with ISO certification requirements. They are justified in using a particular workflow, layout or method. Thus, it is prudent to follow the processes. The fact is—it is not always possible to do so. Companies have various terms and conditions with suppliers, customers, divisions, strategic business units, third parties, etc. It is not feasible to go for an entire makeover. Hence, some customisation is needed to suit the company’s needs. Optimal customisation is subjective with no definite rules.

Commonly customisation occurs in the case of reports and layouts. Companies need certain data in reports for decision-making. Currently, this might be achieved by manual spreadsheets. The content of reports defines what we should have in the data-entry forms. If certain input is not available or cannot be calculated, then it cannot be displayed in the reports. Hence, it is imperative that the reports are modified.

The stages of a process can be shortened. A normal material requisition cycle has stages such as requisition, quotation, comparison, purchase order, goods receipt, quality check and payment. We have the choice of following all the steps or starting from a particular step or even omitting a step. This will increase the efficiency of the system. Depending upon the size of the company, certain processes may be redundant as the same person might be handling both. For example, creating a purchase requisition and authorising it.

Companies have different structures in terms of sister-concerns, branches and sub-divisions. These are created for certain competitive as well as regulatory advantage. Though it is recommended that during evaluation, features should be checked in accordance with the company, certain issues might still be left out. Modifying a structure alone is not possible; systems and strategies will have to be modified too. Hence, it is better to make changes in the ERP flow itself. The extent of customisation should be discussed by the PM with the end-user and the ERP consultant. It should not cause any hindrances at later stages of the implementation of the same module or of related modules. After all we are modifying an integrated system. Each modification can have a ripple effect across other areas.

…or not to customise

What do ERP consultants advise? Do not customise and modify the application! There are several reasons for this.

Firstly, customisation is subjective. People do not understand where to draw the line. End-users are not always technically equipped to understand the far-reaching implications of the changes that they are demanding. The normal attitude is “Since we are paying for the product, do as we say.” Many of them are not able to articulate their requirement, as sometimes they do not understand what they want.

There is a cost to customisation. The ERP vendor will charge you for the modifications either on man-days or on the number of changes. The implementation time will also increase. This can lead to a serious increase in the project cost though it might not make it unviable. Is it really necessary to change a particular layout? It is essential to consider these issues before embarking on a customisation spree. ERP implementation is the right time for Business Process Re-engineering. Instead of modifying an application, it is better to modify the company processes as per the ERP standards since they already have the best practices incorporated in them.

People change on both sides. The end-user or the ERP consultant might quit. This is quite common and a major cause of concern. Everyone who has worked with some ERP might have faced this situation at least once. The next person in-charge might have to start from scratch to understand what customisation has been initiated and why. There is a chance that he might not find it necessary and hence, order a rollback. Perspective is never correct or incorrect, but two persons might not share the same perspective.

This problem is further compounded by the lack of proper documentation and the tracking of the changes which have been initiated.

Customised coding is again a costly affair. Generally, companies do not have skilled programmers so they have to depend on the ERP vendor. These codes require maintenance and updating. Programming logic also differs from one person to another. There is always a risk of destabilising the core application. Is it really worth it?

Now comes the most crucial part. You have customised your ERP to suit your needs. The government issues some changes in the tax structure or the ERP vendor has incorporated some additional features. They issue a patch or an upgrade of their product to their customers. Will it work for you? No. It will not work for your installation because the basic structure has been modified. What is the recourse? You have to again customise. The custom codes will have to be modified. Hence, it goes into an infinite loop.

Therefore, the answer is to...

Customisation of ERP is a complex matter, and it should be used as a fire-fighting tactic. It is a strategic matter rather than operational. It has both pros and cons, but requires careful analysis, planning and execution considering the long-term vision of the company. The PM has to keep tight control over end-users and their demands when it comes to any modification. The ERP consultants should be considered as a part of the team, and their views should be heeded. They know their product best, and most of them have experience in implementation. They also have exposure to the business processes of other clients which can be emulated to solve a problem. Many ERP vendors have functional experts to implement a certain module. They will invariably have some logical solution to problems requiring modifications. We cannot deny that some customisation is required in the best of applications, but to what extent it is justifiable and viable is highly debatable. Modifying the report layouts is acceptable especially in case of financial information which can be used for good MIS. The core structure of the application should not be modified under any circumstances. ERP vendors generate revenue by undertaking customisation. They earn in addition to the cost of the product. The interest of the company (client) is not their top priority.

The PM should assess the amount of time, money and manpower that a particular modification will require before allowing it. Once certain changes are made, every activity should be thoroughly documented. The changes should be initiated through a central command. End-users should not be allowed to make their demands to consultants. Customisation can make or break your implementation and affect the fate of your project. Strike the right balance.