Industrial software specifications: the 7-step method

In short:

1. Industrial software specifications are built in 7 steps, from framing to consultation.
2. They describe needs and processes, never a solution or a vendor name.
3. Requirements are best ranked on 3 levels: essential, important, nice to have.
4. A weighted scoring grid and demos based on real scenarios make offers comparable.

Why specifications shape the project

CMMS, ERP, MES or QHSE software: industrial software is installed for years and affects the daily work of many people. Overly vague specifications lead to comparing sales demos rather than answers to needs. Overly detailed specifications, copied from the existing tool, reproduce the old system’s flaws.

The following method applies to most production and maintenance software.

Step 1: frame the project

Framing sets measurable objectives (reduce unplanned downtime, make spare parts stock reliable, eliminate double data entry), the scope (sites, departments, number of users) and schedule constraints.

Step 2: describe the current situation

List the tools in place, spreadsheets included, data volumes (equipment, items, work orders) and pain points reported by users. This description avoids underestimating data migration.

Step 3: map the target processes

For each process concerned, the specifications describe the desired operation. For a CMMS, for example: work requests, preventive, corrective, spare parts management, cost tracking.

Step 4: list and prioritise functional requirements

Each requirement is worded in a verifiable way and ranked by importance:

Step 5: specify technical requirements

This part covers hosting (on-premise or SaaS), security, connectors with existing systems (ERP, supervision, directory), mobile or tablet use on the shop floor and data reversibility at the end of the contract.

Step 6: build the scoring grid

The grid lists requirements and their weighting, and adds cross-cutting criteria: total cost over several years, quality of support, references in the sector, vendor soundness. It is set before offers are received, to avoid adjusting it in favour of one solution.

Step 7: organise the consultation

The consultation often takes place in two stages:

1. a request for information to a broad panel, to rule out off-target solutions;
2. a request for proposal to two to four finalists, followed by demos based on scenarios drawn from the company’s real processes.

A demo on an imposed scenario reveals much more than a free presentation prepared by the vendor.

Example requirements for a CMMS

To illustrate the method, here is an extract from a functional requirements grid for an industrial site CMMS. Each line is worded so that it can be verified during a demo.

The same exercise applies to an ERP, an MES or QHSE software, with different processes. What matters is that each requirement can be observed, not simply declared by the vendor in a questionnaire.

Assessing total cost of ownership

Comparing offers on licence or subscription price alone leads to surprises. Total cost of ownership, calculated over the planned period of use, includes several items:

• licences or subscription, depending on the number and type of users;
• configuration and integration, including connectors with the ERP or supervision systems;
• data migration from the existing tool, which often requires prior clean-up;
• training for key users, then end users;
• maintenance and support, including version upgrades;
• internal time, for the project manager, key users and the IT team.

Internal time is the item most often forgotten. Yet it weighs heavily, since key users must take part in configuration, testing and training their colleagues, on top of their usual work.

Consultation pitfalls

Several biases distort the comparison of offers:

1. The self-declared questionnaire. A vendor rarely answers “no” to a requirement. Only a scenario-based demo distinguishes a standard feature from custom development.
2. Demos on the vendor’s data. A prepared dataset hides difficulties; it is better to provide a sample of real data.
3. The last-presentation effect. Scoring each solution right after its demo, with the grid set in advance, limits this bias.
4. Forgetting field users. Software chosen without the technicians or operators who will use it risks being bypassed.

Preparing deployment from the moment of choice

The specifications remain useful after selection. They provide the basis for the contract, acceptance tests and the deployment plan. Three practices make the next steps easier:

• start with a pilot site or workshop, to adjust configuration before rolling out;
• appoint key users trained first, who then support their colleagues;
• set success indicators derived from the framing objectives, measured a few months after go-live.

Keeping the specifications alive

Specifications are often filed away once the contract is signed. Keeping them up to date during deployment is more useful: each change request, each requirement abandoned or postponed and each new need identified on the pilot site can be recorded in the document. It then becomes a reference for later phases, such as extending the software to other sites, and a basis for the review a year after go-live, when the success indicators are measured against the initial objectives.

Standard software or custom development

One question comes up in almost every project: should the software be adapted to the company’s processes, or the processes to the software? Custom development seems attractive, since it faithfully reproduces working habits. Yet it has a lasting cost: each vendor version upgrade requires checking, or even reworking, the adaptations made.

The most common practice is to favour the standard and reserve custom work for truly differentiating requirements, those related to the company’s own know-how or to a regulatory constraint in its sector. The specifications can anticipate this by asking vendors to state, for each requirement, whether it is covered as standard, through configuration or through development.

Indicators to track after go-live

The objectives set during framing become the project’s success indicators after start-up. For a CMMS, these may include the share of preventive maintenance in total work orders, mean time to repair, availability of critical equipment or the reliability of spare parts stock. For an ERP or MES, indicators focus instead on eliminating double data entry, the reliability of announced lead times or batch traceability.

Measuring these indicators before the project is essential: without a starting point, it is impossible to demonstrate a gain. A first measurement a few months after go-live, followed by an annual review, helps identify underused features and additional training needs.

Documenting decisions

Recording why each solution was retained or rejected, with the scores from the grid, protects the project if the choice is questioned later and helps when the next consultation begins.

Frequently asked questions