sheelamohanachandran - Fotolia
It is an oft-repeated mantra in the ERP world that companies should not modify ERP packages. Consultants, experienced users and software vendors will tell you that modifications to ERP packages are difficult, expensive and detrimental to the ongoing operation, maintenance and development of a system.
Yet, it is widely acknowledged that a packaged software product cannot fully meet the needs of any one company. In response to this conundrum, software developers build a considerable amount of flexibility into their ERP packages to allow users to tailor the look, feel and functionality to better suit their needs and desires. Ideally, this built-in flexibility enables the user to adapt the package enough to eliminate the need for customization -- and, in fact, that is the case for many companies.
The tailoring capability in ERP software packages can be as simple as the ability to move things around on screens and menus or as extensive as changes in calculations, database formats and content. Generally speaking, such changes are stored in a control table that is not altered or replaced when the software is updated by the developer. This means the changes will survive an upgrade and do not have to be redone or revalidated when a new release is installed.
Here is an overview of the types of changes allowed by major ERP software packages. Understand that each developer has its own tools and approaches, so your package may include some of these or others not listed.
Tailoring the user interface
Most ERP packages have some capability to alter the user interface by moving items around, changing labels, adding or removing items, etc. Often, these changes can be made and stored by an individual user or group of users -- such as all users within a division or department -- or for all users.
Similarly, you can make the data fields on certain screens view-only or restricted to certain acceptable entries. The ability to change labels can be extended to multiple language capabilities: user x's or division y's screens are in Spanish or French, for example.
These kinds of changes work in conjunction with access security that limits each user to certain screens. Removing an item from a user's screen in effect removes their access to that information, although the user may be able to access the data through alternate methods using data retrieval tools like SQL, for example.
Modifying ERP functions
Most ERP systems allow users to tailor their functions as a way to customize the system without modifying the code. Through various means, the user is allowed to turn certain functions on or off, change the way calculations are done or data is displayed, define the organizational structure and relationships, and much more.
But this can be a case of good news and bad news. The good part is the ability to truly refine the packaged ERP software's functionality to match what the organization needs. The bad part is increased difficulty in installing and implementing the system. The more flexibility there is in the package, the more complicated the implementation becomes.
To overcome some of this complexity, ERP developers pre-tailor their packages to fit certain vertical industry segments -- say, industrial equipment or pharmaceutical manufacturers, to name two very different examples. While these pre-tailored offerings eliminate much of the tailoring requirement, most companies perform additional tweaking to create a better, more personalized fit.
Some ERP suppliers have also developed software to help tailor the ERP. These configuration tools typically enable users to map business processes, and then use these process maps to set the tailoring options so the ERP system works as desired.
Limited database capabilities
One of the biggest issues in modifying ERP software packages is changing the database, usually by adding data fields and tables to support additional functions not included in the package. Added fields must be linked to existing data to ensure consistency, completeness and validity, and they may not be fully coordinated, backed up and restored with the ERP data.
Tinkering with a packaged system's database is a delicate and risky undertaking, and release-level changes to the ERP database can be particularly hazardous to modifications.
Recognizing this, many ERP developers have included the limited ability to change existing fields and formats, and to add new data to tables, screens and reports. Developers use various tools to accomplish this and, therefore, capabilities and flexibility vary from one supplier to the next.
User exits and APIs
While not technically in the realm of tailoring, be aware that many ERP software package programs are designed with built-in escape hatches that allow outside programs to communicate with the ERP in a less invasive way.
Let's say you have a unique way of calculating credit authorization, and your order entry system cannot be tailored to do the calculation the way you want. The ordering program may have an exit to which you can attach your calculation program that will pass the required data through the exit and receive the resulting data back into the ordering program flow. Such an exit is, in fact, a modification to the program, but is easier to control and maintain because it only minimally affects the internal code.
An API stand works in much the same way. Admittedly, this is a high-level, imprecise explanation of exits and APIs, but it should give you an idea of ERP developers' appreciation of the desire and need to change things in their packages and their interest in helping users make those changes in the least destructive way.
Take advantage of the best practices in your ERP
Learn why you shouldn't customize ERP
Decide which ERP processes to move to the cloud