Selecting an ERP system is a major decision. It is not the decision that determines success. Success is determined by what the organization does next.

After months of requirements gathering, demonstrations, reference calls, pricing discussions, and contract negotiations, selecting an ERP platform feels like a major finish line. The executive team has approved the investment. The vendor has been chosen. The project can finally begin.

That sense of completion is understandable—and dangerous.

Software selection proves that a platform can support the business. It does not decide how the company will use it, who will own the new processes, which data can be trusted, what should be configured or customized, how users will be prepared, or how the organization will operate on the first day after go-live.

After more than 30 years of ERP consulting, product development, and implementation work, I have seen capable products placed at the center of troubled projects. The software was not always the primary problem. The project lost discipline after the purchase decision.

ERP projects most often fail in the space between software capability and organizational execution.

This is true regardless of platform, and it’s part of why we built GoldFinch natively on Salesforce: removing technical friction so more of the project’s energy can go toward these operating decisions.

During selection, teams compare features: order management, inventory, purchasing, manufacturing, accounting, reporting, integrations, security, and workflow. Those comparisons matter, but they can create the impression that choosing the right feature set resolves the difficult questions.

It does not.

A demonstration shows what the software can do. An implementation must define what the business will do. Those are different questions. Two companies can purchase the same ERP system and experience completely different outcomes because they make different decisions about governance, process, data, testing, and adoption.

The contract closes the buying process. It opens the operating-model decisions.

Executives and department leaders are usually deeply involved during software selection. They attend demonstrations, participate in discovery meetings, compare solutions, and help define requirements.

Once the contract is signed, however, their attention often returns to daily operations. Responsibility gradually shifts to IT, a project manager, or the consulting team, with the assumption that the implementation team can handle the remaining details.

But the most important implementation questions cannot be answered by IT or consultants alone:

• Who may approve a sales order, purchase, credit adjustment, or journal entry?
• When should inventory become available, committed, consumed, or valued?
• Which exceptions require review, and who owns the decision?
• What information must be captured at each step?
• Which reports will management use to run the business?

These are business decisions. When accountable process owners are unavailable, the project team has only three choices: wait for answers, make assumptions, or reproduce the existing process. Waiting delays the project. Assumptions create risk. Reproducing the current process may carry old inefficiencies into the new system.

A successful ERP project therefore needs both an executive sponsor who can remove obstacles and business process owners who have the authority, knowledge, and availability to make timely, binding decisions.

Once users see the new system, they begin imagining improvements. A new approval, report, interface, automation, exception, or historical-data request appears reasonable in isolation. Together, they can overwhelm the project.

This is how an implementation becomes a redesign of the entire company before the company has learned to use the new platform.

The safer approach is crawl, walk, run. Start with the smallest scope that allows the company to transact accurately, serve customers, control inventory, close the books, and meet regulatory obligations. Add optimization after the core processes are stable and the team has real operating experience.

Phasing is not a lack of ambition. It is a way to protect the business while preserving the long-term vision.

In one implementation, users began requesting enhancements as soon as they saw the new order-entry screens: a custom approval routing, an extra inventory report, a request to load two years of sales history that wasn't in the original scope. Individually, each request seemed reasonable. Together, they would have pushed go-live back by nearly two months. The project team held the line by logging every request in a backlog and revisiting it after the core processes were stable, which kept the original timeline intact and gave the client a prioritized roadmap for phase two.

ERP systems expose ambiguity. A company may have relied for years on spreadsheets, email approvals, undocumented workarounds, and knowledge held by a few experienced employees. During implementation, those informal practices must become explicit rules.

When a team cannot agree on a process, it may ask the consultant to configure the software anyway. Configuration then becomes a substitute for business alignment. The result is often a complicated design that attempts to satisfy every variation without establishing a standard way of working.

For example, one team could not agree on when a return should reduce inventory versus wait for inspection. Rather than resolve the policy, they asked the consultant to build a workflow that handled both paths depending on user judgment at the time of entry. The result was a screen with extra fields and conditional logic that few users understood and no one could explain to auditors.

Good implementation workshops should not begin with, ‘How do we make the new system behave like the old one?’ They should begin with, ‘What outcome and control do we need, and what is the simplest reliable process that produces it?’

Data migration is often described as extracting, transforming, and loading records. The technical steps are important, but the harder work is deciding what the data means and whether it can be trusted.

Duplicate customers, inactive vendors, inconsistent item numbers, missing units of measure, incorrect inventory, incomplete bills of material, old open orders, and unreconciled accounting balances do not become accurate simply because they are loaded into a new system.

The business must own data quality. Each data set needs an owner, inclusion rules, a reconciliation method, and a deadline. Whenever practical, convert clean master data and open balances rather than years of detailed transaction history. Historical information can often remain available through an archive or reporting source.

A smaller amount of reconciled data is more valuable than a large amount of questionable data.

Every organization has legitimate requirements. Some customization may be necessary, especially for customer-facing documents, regulatory needs, industry-specific processes, or capabilities that create real competitive value.

The risk begins when ‘we have always done it this way’ becomes the design standard.

Recreating every legacy screen, report, approval, and workaround increases cost, extends the timeline, complicates testing, and makes future upgrades harder. It also preserves processes the organization intended to improve.

Before approving a customization, ask four questions: Is it legally required? Is it customer-facing? Does it protect a material control? Does it create meaningful competitive advantage? If the answer to all four is no, standard configuration should receive serious consideration.

Applying that test to a recent project: a client asked for a custom multi-level approval matrix that mirrored their old system exactly. It wasn't legally required, wasn't customer-facing, didn't strengthen a control, and didn't create competitive advantage. Standard approval workflows delivered the same outcome with far less configuration and no ongoing maintenance burden.

Industry-focused ERP solutions reduce this risk because more of the required business logic is already part of the product. Even then, disciplined design matters.

Many project plans place training shortly before go-live. By then, major decisions have already been made, the schedule is tight, and users are expected to absorb new processes while continuing their normal work.

Training should begin earlier and extend beyond button clicks. Users need to understand why the process is changing, how their work affects downstream departments, what controls the system enforces, and what to do when an exception occurs.

A train-the-trainer model works well when department leaders are involved early, practice realistic scenarios, and become the first line of support for their teams. In cloud environments, a refreshed sandbox can provide a safe place for repeated practice without contaminating production data.

Attendance is not adoption. Users are ready when they can complete their work, recognize exceptions, and explain the consequences of their actions.

A test that proves a user can create a sales order is incomplete. The real question is whether the organization can receive an order, allocate inventory, ship accurately, invoice the customer, recognize the accounting impact, collect payment, and reconcile the results.

ERP testing must follow complete business cycles across departments. It should include normal transactions, exceptions, approvals, reversals, partial shipments, returns, failed integrations, period-end procedures, and reconciliations.

The best tests use realistic data and are performed by the people who will own the processes after go-live. Testing is not merely quality assurance for the software. It is a rehearsal for the business.

A project can be technically live while the organization is not operationally ready. Interfaces may be working, but users may still depend on spreadsheets. Transactions may be entered, but inventory and accounting may not reconcile. Questions may be submitted, but no one may have the authority to resolve cross-functional issues quickly.

A strong go-live plan defines cutover responsibilities, decision authority, reconciliation checkpoints, support channels, and escalation rules. Hypercare should include several subject-matter experts—often experienced department leaders—not one project person attempting to answer every question.

The first objective after go-live is not perfection. It is controlled, visible stabilization. Problems should be captured, prioritized, assigned, and resolved without allowing informal workarounds to become permanent.

The disciplines that reduce implementation risk are straightforward, even when the work is demanding:

An ERP platform can provide integrated data, stronger controls, faster decisions, and a foundation for future automation. But software does not create those outcomes by itself.

The organization creates them through disciplined decisions about ownership, scope, process, data, customization, training, testing, and change.

The most successful ERP projects do not try to solve everything before go-live. They establish a stable operational foundation, help users adopt it, and improve it continuously as the business learns.

Software selection determines what is possible. Implementation discipline determines what becomes real.

Planning an ERP implementation?
GoldFinch combines Salesforce-native ERP technology with a disciplined, phased implementation approach developed through more than 30 years of ERP consulting and product experience.