Standard product or custom development: how to decide

Every implementation meets the same argument. Users say the system must work the way they work. The supplier says the standard product should be changed as little as possible. Both are partly right, and the decision is easier when it is made by a rule and not by who argues longer.

What a change really costs

The price of a modification is not the hours of the programmer who writes it. It has to be specified, tested, documented and explained to users. After that it has to be checked with every update of the standard product for as long as the system lives. A change that took a week to write can take more than that over the following years.

This is why the question is never "can it be done". On a platform as open as 1C:Enterprise almost anything can be done. The question is whether the benefit is larger than the cost over the whole life of the system.

Three groups of requests

It helps to sort every request into one of three groups.

The law and the regulator. Statutory reports, tax rules and mandatory documents. These are not discussed. They are implemented, where possible through the localization that the product already has.

Competitive advantage. The way the company prices, plans production or serves customers, when that way really earns money. Here a modification is justified, and it deserves good design.

Habit. The form looks different, the report had another order of columns, the approval went through other people. This is the largest group, and the right answer is usually to change the habit. A standard process carries the practice of many companies and costs nothing to maintain.

Questions for each request

Before a modification is approved, somebody on the client side should answer four questions in writing.

• What happens if we do not do it? If the answer is "users will be unhappy for a month", it is a habit.
• How many people does it affect, and how often?
• Can the same result be reached by a setting, a report or a change in the process?
• Who will own this function and confirm in two years that it is still needed?

How to change without losing updates

When a modification is justified, the way it is made matters as much as what it does. Changes kept separate from the vendor's code, as extensions, allow standard updates to be installed in the usual way. Changes written into the standard code turn every update into a small project, and after a few years such systems stop being updated at all.

Ask the supplier how each modification will be made and how updates will be installed afterwards. The answer belongs in the specification.

A working rule

Start with the standard product and work in it for one full reporting period. Many requests disappear by themselves once people learn the new way. What remains after that period is the real list of modifications, and it is usually shorter than the list written before the start.