An ERP purchase should not begin with a software demonstration. It should begin with evidence that the current operating model is losing control. Growth exposes handoffs that once lived safely in one person’s memory: a quote becomes an order, an order changes inventory, delivery triggers an invoice, and finance needs the same truth as sales. When every department maintains its own version, the organization spends more time reconciling reality than serving customers. This guide shows how to distinguish ordinary spreadsheet inconvenience from an ERP-level problem, how to define a credible first phase, and how to avoid replacing flexible chaos with rigid chaos.

Signal one: the same fact has several owners

Customer names, stock quantities, tax details, and order status appear in multiple files, and none is consistently authoritative. Teams compensate by messaging one another for confirmation, so the real system becomes a chain of interruptions rather than a controlled record. The important distinction for owners, operations leaders, finance teams, and implementation sponsors in growing companies is whether the team can connect that observation to a decision, an owner, and a measurable operating result. A polished dashboard is not proof of control; evidence appears when the process produces the same answer under normal pressure, when a handover occurs, and when an exception has to be resolved.

Field perspective. A useful discovery exercise follows one recent transaction from first inquiry to payment and records every re-key, copy, export, and manual confirmation. Define a system of record for each critical object before discussing modules, vendors, or migration dates. This is where discovery should move from opinions to artifacts: sample records, screen recordings, error logs, approval histories, user interviews, or timed task observations. The team should record what was observed, what remains an assumption, and what would change the recommendation. That discipline prevents a persuasive anecdote from becoming an expensive architecture decision.

Decision test: Select twenty completed transactions and calculate how many fields were typed more than once, how many corrections were needed, and how long reconciliation took.

The strongest evidence is a timestamped trail showing conflicting values and their operational consequence, not a general complaint that spreadsheets feel old. The following review prompts make the issue concrete and keep the workshop focused on behavior rather than feature wish lists:

  • Which customer field most often disagrees?
  • Who can correct the master record?
  • What downstream report inherits the error?
  • How is a correction communicated today?

A small amount of duplication can be rational when teams need offline resilience or a controlled working copy; the problem is ungoverned divergence. A sensible rollout therefore starts with a reversible test, a named baseline, and a date for review. If the result does not improve the baseline, the team should be willing to stop, simplify, or choose a different intervention instead of defending sunk cost.

Signal two: approvals disappear into chat and inboxes

Discounts, purchases, refunds, and exceptions are approved in messages that cannot be searched reliably during month-end or an audit. The business may know that approval happened without being able to prove who saw the full context, what threshold applied, or whether the request changed later. The important distinction for owners, operations leaders, finance teams, and implementation sponsors in growing companies is whether the team can connect that observation to a decision, an owner, and a measurable operating result. A polished dashboard is not proof of control; evidence appears when the process produces the same answer under normal pressure, when a handover occurs, and when an exception has to be resolved.

Field perspective. Map three approval types and compare the stated policy with the last ten real decisions, including urgent cases and decisions made during staff absence. Design approval rules around value, risk, segregation of duties, escalation time, and substitute ownership instead of copying the current org chart into software. This is where discovery should move from opinions to artifacts: sample records, screen recordings, error logs, approval histories, user interviews, or timed task observations. The team should record what was observed, what remains an assumption, and what would change the recommendation. That discipline prevents a persuasive anecdote from becoming an expensive architecture decision.

Decision test: Track median approval time, exceptions older than the target, requests returned for missing information, and changes made after approval.

A signed-off workflow matrix and sample audit trail provide better procurement criteria than a vendor slide promising configurable approvals. The following review prompts make the issue concrete and keep the workshop focused on behavior rather than feature wish lists:

  • What value triggers a second reviewer?
  • Can requesters approve their own changes?
  • Who acts when an approver is unavailable?
  • Which evidence must remain attached?

Automation does not fix an unclear delegation policy; it can make bad authority faster and harder to challenge. A sensible rollout therefore starts with a reversible test, a named baseline, and a date for review. If the result does not improve the baseline, the team should be willing to stop, simplify, or choose a different intervention instead of defending sunk cost.

Signal three: reporting requires a monthly rescue operation

Management reports are assembled through exports, lookup formulas, copied totals, and last-minute explanations that only one analyst understands. By the time a number is accepted, it describes a past that is too old to guide inventory, staffing, collections, or customer commitments. The important distinction for owners, operations leaders, finance teams, and implementation sponsors in growing companies is whether the team can connect that observation to a decision, an owner, and a measurable operating result. A polished dashboard is not proof of control; evidence appears when the process produces the same answer under normal pressure, when a handover occurs, and when an exception has to be resolved.

Field perspective. Reconstruct the production of one board or management report and time data extraction, cleaning, reconciliation, review, and correction separately. Define decision-grade metrics with an owner, calculation rule, refresh frequency, source field, and exception treatment. This is where discovery should move from opinions to artifacts: sample records, screen recordings, error logs, approval histories, user interviews, or timed task observations. The team should record what was observed, what remains an assumption, and what would change the recommendation. That discipline prevents a persuasive anecdote from becoming an expensive architecture decision.

Decision test: Compare total preparation hours with the time leaders spend acting on the report, then count post-publication corrections.

Version history and reconciliation notes reveal whether the delay comes from technology, ambiguous definitions, missing data, or all three. The following review prompts make the issue concrete and keep the workshop focused on behavior rather than feature wish lists:

  • Which metric causes the longest debate?
  • What manual adjustment is never documented?
  • When is a report too late to matter?
  • Who signs off the final definition?

Real-time reporting is not automatically valuable; some decisions need controlled period close rather than continuously changing numbers. A sensible rollout therefore starts with a reversible test, a named baseline, and a date for review. If the result does not improve the baseline, the team should be willing to stop, simplify, or choose a different intervention instead of defending sunk cost.

Choose a narrow ERP first phase

ERP programs fail when every department treats implementation as a chance to request every feature it has ever wanted. Scope expands, data cleanup is postponed, testing becomes superficial, and teams discover too late that the new workflow does not fit daily work. The important distinction for owners, operations leaders, finance teams, and implementation sponsors in growing companies is whether the team can connect that observation to a decision, an owner, and a measurable operating result. A polished dashboard is not proof of control; evidence appears when the process produces the same answer under normal pressure, when a handover occurs, and when an exception has to be resolved.

Field perspective. A practical first phase usually follows one end-to-end value stream, such as quote-to-cash or purchase-to-pay, with explicit interfaces to systems left unchanged. Prioritize work using transaction volume, error cost, control risk, user readiness, and dependency count rather than executive enthusiasm alone. This is where discovery should move from opinions to artifacts: sample records, screen recordings, error logs, approval histories, user interviews, or timed task observations. The team should record what was observed, what remains an assumption, and what would change the recommendation. That discipline prevents a persuasive anecdote from becoming an expensive architecture decision.

Decision test: Publish phase success criteria such as fewer invoice corrections, faster order confirmation, lower stock variance, or shorter close time.

A baseline measured before configuration lets sponsors tell the difference between a successful go-live and a screen that merely became available. The following review prompts make the issue concrete and keep the workshop focused on behavior rather than feature wish lists:

  • What business outcome funds phase one?
  • Which process boundary is explicit?
  • What will remain manual temporarily?
  • What condition pauses deployment?

A narrow phase must still include the minimum master data and controls required for reliable downstream reporting. A sensible rollout therefore starts with a reversible test, a named baseline, and a date for review. If the result does not improve the baseline, the team should be willing to stop, simplify, or choose a different intervention instead of defending sunk cost.

Treat data migration as an operating decision

Teams often assume every historical row must move, even when years of duplicate customers, obsolete products, and inconsistent units would pollute the new system. Migration is not a copying task; it determines which history remains searchable, which balances are trusted, and which errors acquire new legitimacy. The important distinction for owners, operations leaders, finance teams, and implementation sponsors in growing companies is whether the team can connect that observation to a decision, an owner, and a measurable operating result. A polished dashboard is not proof of control; evidence appears when the process produces the same answer under normal pressure, when a handover occurs, and when an exception has to be resolved.

Field perspective. Profile source data by completeness, uniqueness, format validity, age, business use, and reconciliation to controlled totals. Assign business owners to approve cleansing rules and create a retained archive for history that should remain accessible but not enter live operations. This is where discovery should move from opinions to artifacts: sample records, screen recordings, error logs, approval histories, user interviews, or timed task observations. The team should record what was observed, what remains an assumption, and what would change the recommendation. That discipline prevents a persuasive anecdote from becoming an expensive architecture decision.

Decision test: Use trial migrations to report rejected rows, unresolved duplicates, reconciled balances, and the time needed for business validation.

Signed reconciliation and sampled transaction tracing are stronger acceptance evidence than a technical message that an import completed. The following review prompts make the issue concrete and keep the workshop focused on behavior rather than feature wish lists:

  • Which history has a legal retention need?
  • What record defines opening balance?
  • How will duplicates be merged?
  • Who approves excluded data?

No migration produces perfect data; the goal is understood residual risk, controlled exceptions, and a process for correcting records after launch. A sensible rollout therefore starts with a reversible test, a named baseline, and a date for review. If the result does not improve the baseline, the team should be willing to stop, simplify, or choose a different intervention instead of defending sunk cost.

Make adoption observable after go-live

A project can be declared complete while users maintain shadow spreadsheets, share logins, or bypass controls to keep work moving. These workarounds are operational feedback: they may signal missing training, slow screens, unrealistic policy, incomplete data, or a legitimate exception path. The important distinction for owners, operations leaders, finance teams, and implementation sponsors in growing companies is whether the team can connect that observation to a decision, an owner, and a measurable operating result. A polished dashboard is not proof of control; evidence appears when the process produces the same answer under normal pressure, when a handover occurs, and when an exception has to be resolved.

Field perspective. Combine usage logs with floor observation, support tickets, short user interviews, and a review of files that continue to circulate outside the system. Create a thirty-, sixty-, and ninety-day stabilization plan with named owners for defects, training gaps, master-data issues, and policy decisions. This is where discovery should move from opinions to artifacts: sample records, screen recordings, error logs, approval histories, user interviews, or timed task observations. The team should record what was observed, what remains an assumption, and what would change the recommendation. That discipline prevents a persuasive anecdote from becoming an expensive architecture decision.

Decision test: Monitor active use by role, process completion, exception volume, support recurrence, data quality, and the business outcome selected before implementation.

Adoption is demonstrated when the controlled process becomes the easiest reliable way to finish work, not when attendance sheets show that training occurred. The following review prompts make the issue concrete and keep the workshop focused on behavior rather than feature wish lists:

  • Which shadow file still exists?
  • What task takes longer than before?
  • Which exception has no route?
  • When will benefits be reviewed?

Usage counts alone can reward unnecessary clicks; pair them with completion quality and user effort. A sensible rollout therefore starts with a reversible test, a named baseline, and a date for review. If the result does not improve the baseline, the team should be willing to stop, simplify, or choose a different intervention instead of defending sunk cost.

What to do next

Start with a two-week evidence sprint, not a request for proposals. Follow real transactions, inventory the repeated data, time the approvals, reconstruct one management report, and quantify the business consequence of delay or error. If the evidence shows a connected control problem, define one value stream and a baseline before meeting vendors. If it shows only a local inconvenience, improve the local process first. ERP is justified when integration and control create measurable operating value—not when a business feels embarrassed by its spreadsheets.