Picture a mid-size manufacturing company where the accounting manager asks for a new field on the invoice screen, the warehouse supervisor wants two extra columns on the stock report, and the sales director needs the customer list sorted differently. Each request looks small on its own. But six months later, if the programmer spends hours every time a new version needs to be installed, something has gone seriously wrong.
ERP — short for Enterprise Resource Planning — software brings together accounting, inventory, purchasing, and sales under one roof. These programs come loaded with features. But every company has its own habits and workflows. One firm wants the tax number at the top of the invoice; another wants it at the bottom. One wants color-coded stock alerts; another does not. So software vendors make company-specific changes, usually called ‘customizations’ or ‘adaptations.’ The trouble starts when these requests pile up without any control.
Think of each customization as a patch sewn onto a pair of trousers. One patch looks fine. But ten patches on top of ten more patches, and the trousers are no longer recognizable. The same logic applies to ERP software. Every line of custom code pulls the system further away from its original structure. When the software vendor releases a new version, those custom patches often do not fit. The company then faces a choice: skip the new version entirely, or rewrite every customization from scratch. Either way, it costs money and time.
The first step toward fixing this is to filter every request before it reaches the programmer. In larger companies this is called a ‘change request board.’ For a small or medium-sized business, the board does not need to be a formal committee. One manager, one accountant, and one person who understands the technical side of the program is enough. These three people should ask one question about every request: does the business actually stop without this change, or is it just a matter of habit? Most requests fall into the second category. If the screen layout changes, work does not stop — only a routine shifts. Requests like these should be rejected or postponed.
When a request genuinely passes that test, the next step is an ‘impact analysis.’ This simply means asking: if we make this change, what else in the program does it touch? Adding a new field to the invoice screen may affect not only the invoicing module but also the accounting integration and inventory movement records. Knowing this in advance prevents surprises. The software vendor’s technical team should carry out the analysis, but the manager who made the request should be part of the conversation. The technical team knows the code; the manager knows what the business process actually means in practice.
The third step is to attach approved changes to a schedule. Not every approved request should be implemented immediately. Instead, requests should be collected and processed together at set intervals — a practice known as ‘release planning.’ For example, all approved changes from a three-month period can be bundled and applied at once. This approach has two clear advantages. First, the programmer works in one focused session rather than making isolated changes every few days, which improves both speed and consistency. Second, changes can be tested before going live. Rushed changes made directly to the live system sometimes cause unexpected errors. A company that tests in a separate environment avoids those surprises.
In practice, the hardest part is simply writing requests down. In smaller firms, most requests travel by phone call or a quick word in the corridor. The accountant catches the programmer in the hallway and says ‘just change that for me.’ The programmer does it. But nothing gets recorded. Six months later, nobody remembers what was changed or why. The simplest remedy is to write every request on paper or in a plain text file: the date, who asked, what they asked for, and why. Without that record, a change board and an impact analysis have no foundation to stand on.
Any small or medium business owner who has invested in an ERP program should keep one thing in mind: buying the software is perhaps forty percent of the job. The remaining sixty percent is using it correctly and managing it well. Bringing change requests under control is one of the most important parts of that management. Setting up a small review board, asking for an impact analysis, and sticking to a release schedule are not complicated tasks. But companies that skip these three steps gradually lose track of their own system. At that point, either the program has to be rebuilt from the ground up, or the business keeps living with a patchwork it can no longer trust. Both options are expensive.
This article was originally written in Turkish by Gökhan MERCANOĞLU on July 12, 2004 and has been automatically translated into English and other languages using machine translation.