WHY DO PRECISE DEFINITIONS OF ERP PROJECTS WASTE TIME AND MONEY?

The fundamental problem with purchasing an enterprise resource planning system is that the detailed specification is also an agreement on what kind of system will be obtained for the agreed amount of money.

A normal system project begins with a definition by the company.

After this, the company conducts a tender and selects a system supplier.

The company makes a detailed specification with the selected supplier, agreeing on what kind of system will be delivered.

Already at this stage, the project starts to consume valuable time, because making precise specifications is difficult and does not happen instantly.

The biggest problem with precise definition is that no one's imagination is enough to define in advance all the different little scenarios, features, and quirks related to a company's operations and system.

Few customer companies outside the IT sector are experienced enough as system purchasers to be able to mention all the relevant operational issues. System suppliers, on the other hand, usually do not know how to ask about all these operational practices at a sufficiently detailed level, because they either do not specialize in their customer's industry or, despite their industry expertise, do not notice all the specific features and nuances of their customer's operations.

Often, special features and details only begin to emerge when the system is first tested by the customer.

At this stage of the project, the company's cash flow needs to be turned on, as even small changes require money.

In practice, system suppliers only try to do what has been agreed and priced. The customer, on the other hand, would like to change everything because it is slowly starting to dawn on them that the system does not work as desired, even if it fulfills the functionality specified. When changes or additions are made to the system that deviate from the specification, it costs the company more. Many times.

At this stage of the project, the ERP acquisition is already starting to rob too many people of sleep.

When the customer wants to make changes to the system as a result of the system test, they are effectively asking the supplier to do work that is not part of the contract. This entitles the system supplier to switch to hourly billing, which ultimately increases the customer's system acquisition costs far beyond the budgeted costs.

Instead of precise specifications, it is better to deliver the system through iteration, which means that the client company does not have to think about every little nuance and detail in advance, because it cannot do that. No one can, because the special features are only revealed during the testing phase.