The system becomes part of how the company operates
An enterprise resource planning system—ERP—connects core business activities such as purchasing, accounting, inventory, and planning. Implemented well, it gives a growing life-sciences company consistent processes, reliable records, and a clearer view of its resources. Implemented poorly, it can make ordinary work harder and spread inconsistent information across departments.
A purchase that cannot be approved, material that cannot be received correctly, or spending that cannot be attributed to the right program is not simply an IT issue. It affects the company's ability to support the science and make sound operating decisions.
ERP success depends on the business decisions surrounding the software as much as the software itself. Those decisions need accountable owners before configuration begins.
Engage the people who own—and perform—the work
Finance may sponsor the project, but Finance alone cannot define how the entire business should operate. Engage procurement, research operations, supply chain, manufacturing where applicable, IT, and Quality in the processes that affect them. Include the employees who request, receive, reconcile, and resolve exceptions—not just department heads.
Map a few real transactions from beginning to end. Who requests a critical reagent? Who approves the commitment? What happens when only part of the order arrives, the invoice differs, or a project code changes?
These handoffs expose requirements that a feature checklist can miss. Give each major process an owner with authority to resolve competing needs, approve its future design, and accept the tested result.
Stakeholder engagement also requires capacity. Protect time for workshops, data cleanup, testing, and training. A project cannot depend on busy employees fitting every decision around their existing workload.
Select for the business you have—and the one you are building
Start with the operating requirements, not a preferred vendor or an impressive demonstration.
An early research company may need dependable purchasing, program-level spending visibility, and a disciplined close. As it grows, its needs may include multiple entities, clinical supply, outsourced manufacturing, lot and expiry visibility, or commercial operations. A potential public-company transition also warrants early attention to financial controls, access design, and evidence of approvals.
Separate requirements into three groups:
- Needed now: Capabilities essential to run the current business reliably.
- Needed at a defined milestone: Capabilities tied to a credible growth event, with a practical activation path.
- Possible later: Options worth understanding without burdening the initial implementation.
Ask shortlisted providers to demonstrate the company's own scenarios, including exceptions. Distinguish standard functionality from configuration, paid extensions, third-party tools, and custom development. Confirm the cost and effort of maintaining each dependency.
Assess total ownership cost: implementation, integrations, migration, internal staff time, training, support, and upgrades—not just subscriptions. Select a platform that can grow without buying and deploying every future capability on day one.
Put two kinds of expertise beside the business owner
An expert technical resource and an experienced project manager serve different purposes. Neither substitutes for the other.
The technical lead should understand the selected platform deeply enough to evaluate architecture, configuration, integrations, permissions, data migration, reporting, and upgrade implications. This person must be able to challenge an attractive shortcut that creates a fragile long-term dependency.
The project manager should have experience with both the specific tool and the business processes it will support. Scheduling meetings and tracking tasks is not enough. The role requires translating operational needs into deliverables, recognizing dependencies, surfacing unresolved decisions, and understanding whether a technically completed task actually works for the business.
An implementation partner may supply one or both roles. Verify the experience and availability of the people assigned—not only the firm's credentials. Preserve an accountable internal sponsor and process owners who can make decisions and protect the company's interests.
Microsoft's implementation governance guidance provides a useful vendor-specific reference for connecting business goals, project structure, and risk management. The broader principle applies regardless of platform: governance must turn decisions into accountable action.
Treat data and integrations as core workstreams
Moving inconsistent records into a new system does not make them trustworthy. Assign ownership for supplier records, item definitions, units of measure, account structures, and opening balances. Agree on cleanup, migration, reconciliation, and acceptance before loading production data.
Define which system owns each record and how changes move between applications. An ERP does not need to replace an ELN, quality system, or every specialist application. It does need clear boundaries and dependable connections where information is shared.
For example, an inventory interface should have a defined response to a failed transfer or duplicate transaction. Otherwise, a clean dashboard may conceal a broken handoff.
Where regulated workflows or financial controls are affected, involve the responsible Quality, Finance, and assurance teams early to determine the applicable requirements and evidence. Buying an ERP does not, by itself, establish compliance.
Prove readiness before committing to go-live
Test complete business scenarios with actual process owners and representative data. Include ordinary transactions, exceptions, role restrictions, interfaces, reconciliations, and reporting. A successful demonstration is not user acceptance testing.
Train employees for the work they perform, using the configured system and realistic examples. Rehearse the transition: open orders, inventory, balances, access, support coverage, and the first close all need explicit owners.
Set go/no-go criteria in advance. Define which defects prevent launch, who accepts remaining risks, and what contingency is workable if the transition fails. The calendar should not overrule evidence that the business is unready.
After launch, provide dedicated stabilization support and measure outcomes such as transaction exceptions, reconciliation effort, close performance, and persistent spreadsheet workarounds. Go-live is a milestone, not proof of value.
Operational takeaway
Do not approve an ERP implementation solely because the software fits the budget. Approve a business-led plan to make it work.
Before committing, establish engaged process owners, requirements grounded in current needs and credible growth, an expert technical lead, and a project manager experienced in both the platform and the business. Fund the employee time needed to clean data, test processes, and build adoption.
The objective is not simply to launch an ERP. It is to give the company a dependable operating foundation that supports its next stage without disrupting the work it must accomplish today.