“We need a new ERP” is not a goal. It is a symptom. Measurable goals and a clearly bounded scope decide whether an ERP project steers or drifts. Executives and IT should clarify before vendor selection what should change concretely within twelve to eighteen months, who owns it, and what deliberately comes later. Only then follow software, fixed price, and schedule. Reverse that order and you buy features, then discover scope conflicts mid-project.

Why unclear goals make ERP projects fail

Without goals there is no prioritization. Every department brings wishes that all sound “important”. The project team tries to satisfy everything at once, and scope grows quietly. Typical result: delays, change requests, and a go-live that satisfies no one. Unclear goals are among the most common causes of failed implementations; see Common ERP implementation mistakes.

A goal is usable only when it is verifiable. “More transparency” is not enough. “Planning sees stock levels and open orders in one screen, without an Excel export” can be accepted. “Digitize processes” is not enough. “Quote-to-order in under X days, measured on samples from the system” is.

Which goals fit mid-market companies

Good ERP goals attach to operational bottlenecks, not feature lists. Examples that have worked in projects:

• Reduce stock levels by a defined percentage without putting delivery capability at risk
• Shorten quote-to-order lead time measurably
• Create production transparency for planning and sales
• Connect e-invoicing and DATEV without media breaks
• End dual maintenance between Excel and ERP for one clearly named process

Every goal needs a metric, a time horizon, and an accountable role. Without those three elements it remains a statement of intent. For mid-market companies the rule often holds: fewer goals with clear impact beat a long list of non-binding wishes. Industry context and typical entry points are covered in ERP for mid-market companies when you need to situate the starting point.

How goals become a reliable scope

Goals lead to scope: which processes in the first rollout, which later? Who decides exceptions? Which budget and timeframe are realistic? Scope is the deliberate boundary, not the sum of all requirements. Scope that is too large is, after missing goals, the second most common project risk factor.

Starting process-oriented reduces risk: one core process productive, then expand, instead of switching everything at once. The principle Process structure instead of module structure helps anchor scope in workflows rather than module catalogs. For fixed price and delivery date: the more precise the scope before contract signature, the more reliable price and delivery date become. Nuclos Enterprise delivers productive ERP in 30 days on agreed scope, at a fixed price from 10,000 euros plus VAT. Without agreed scope, the same claim would be unserious.

How prototype and specification secure goals

Written goals alone are often not enough. Business departments and leadership need a shared picture of what “done” means. Two paths have proven themselves:

• “A 48h prototype makes one sub-process clickable. Investment: 950 euros plus VAT, credited toward follow-on projects. Departments see early whether workflows and edge cases can be mapped.”
• A requirements specification documents processes, fields, and acceptance criteria in a structured way when multiple stakeholders or a tender need clarity.

Both paths translate goals into tangible scope before budget is committed. Which entry fits depends on starting point and decision pressure; orientation is in Which Nuclos entry path fits your situation?.

What executives and IT should record together

Goals, scope boundaries, responsibilities, and milestones belong in writing and aligned with business departments. Review regularly against the plan: What has been achieved? What has changed about the goal? What moves to phase 2? ERP is an investment in processes and data, not a purchase from a feature list. Whoever clarifies goals and scope before choosing software keeps control of price, timeline, and benefit.

Next steps

• “Typical pitfalls before you start: Common ERP implementation mistakes”
• Choose an entry path: Which Nuclos entry path fits your situation?
• Make a sub-process tangible early: What does an ERP prototype deliver before the large project?