We often receive very detailed requirements specifications written by consultants as part of an ERP selection process.
Clear advantages
- Clear identification of the company's needs and expectations in terms of required features and specific modules. This helps select a system that will best meet the company's requirements.
- Ability to compare several solutions available on the market against specific criteria. This makes it easier to select the ERP that will best meet the company's needs in terms of features, costs, technical support, and so on.
- Provides an objective evaluation framework for service providers and software vendors. It makes it possible to measure their ability to meet the company's specific requirements and to select the one that best matches its needs.
But also major drawbacks
- Using a requirements specification can limit the options available when choosing a management tool. If the requirements are too specific or restrictive, the number of vendors able to meet them may shrink, thereby limiting the company's choice.
- A company's needs can change over time due to internal or external changes. A specification that is too rigid may not take these changes into account and make it hard to adapt the ERP to the company's new needs. Too often, the specification describes the company's past and does not allow it to look ahead. Moreover, the selection grids (up to 700 lines!) are often copy-pastes reused by consultants from one study to the next. This sometimes leads to major inconsistencies, as I have seen in files we recently responded to.
- Drawing up a detailed specification requires time, resources and specific skills. Evaluating vendors, analyzing proposals and negotiating contracts can generate significant costs for the company. These costs include the consultant's time, the employees' time, and the providers' time. The total time spent by these various parties can sometimes exceed the total cost of delivering the project.
At Auguria, we believe you should start from a simple statement of needs describing the challenges. This allows the vendor/integrator pair to position themselves and propose a demonstration. If it is convincing and shows good coverage of the needs, there is always time to propose an operating procedure. Our integration approach includes an initialization step that makes it possible to detail the real needs and the delivery schedule precisely.