ERP selection becomes risky when the conversation starts with screens and ends with a price. A better process starts with the business decisions, handoffs and records that need to become more reliable.
Define why the business needs ERP now
Write the business problem in plain language. Examples include missed sales follow-ups, delayed purchase approvals, uncertain stock, projects with hidden effort, payroll prepared from multiple files or management reports that take days to consolidate.
A useful objective describes a measurable operating change, not only a software installation. For example: reduce overdue follow-up, produce a trusted outstanding report every morning, connect project time to billing or make approval ownership visible.
If the ERP works well six months after go-live, what should management and users be able to do faster, more accurately or with less manual coordination?
Document workflows, not only feature names
A requirement such as "need CRM" is too broad. Document how an enquiry enters, who qualifies it, what fields are mandatory, when a quotation is created, who approves discount, how follow-up is scheduled and when the opportunity becomes a customer or project.
For each major workflow, capture the trigger, responsible role, required data, decisions, approvals, output document, exception conditions and management report. Use real examples and sample documents.
- Trigger What starts the process?
- Owner Who is responsible at each stage?
- Data Which fields, masters and attachments are required?
- Control Which validations, approvals and permissions apply?
- Outcome Which document, status or report completes the step?
Choose the first ERP phase by impact and dependency
Implementing every module at once can create unnecessary risk. Prioritize workflows that have a clear owner, usable data, frequent business impact and manageable dependencies.
A sales module may need customer and product masters. Project profitability may need accurate timesheets, expenses and billing. Payroll needs approved attendance and policy rules. Manufacturing planning may need reliable item, BOM, routing, inventory and capacity data.
| Priority test | Question to ask |
|---|---|
| Business impact | Does this workflow affect revenue, cash, delivery, compliance or customer experience? |
| Process readiness | Is the current process understood and owned? |
| Data readiness | Are the required masters and opening records usable? |
| Dependency | What must be implemented before this workflow can work? |
| Adoption capacity | Can the relevant users participate in testing and training now? |
Ask vendors to demonstrate your scenarios
A generic presentation proves that screens exist. It does not prove that the product fits your workflow. Send the vendor two or three realistic scenarios before the demo and ask them to show each step, role, exception and report.
During the session, classify every requirement as available now, configurable, integration-dependent, custom development or roadmap. Ask the vendor to document gaps rather than promising that everything is possible.
Show how a new enquiry becomes a quotation, approval, project or order, invoice, payment follow-up and management report - including what happens when information is missing or approval is delayed.
Treat data migration as a business project
ERP data is not only an IT file import. Business owners must decide which records are active, which duplicates should be merged, which codes should be standardized, how opening balances are validated and how much history is truly needed.
Prepare a migration register covering customers, suppliers, items, employees, opening transactions, active projects, outstanding invoices and other required masters. Assign one accountable owner for each data set.
- Define source file and data owner
- Remove duplicates and obsolete records
- Map mandatory fields and coding standards
- Perform trial migration and reconciliation
- Approve opening data before go-live
Evaluate the implementation plan, not only the product
Ask who will conduct discovery, configure the system, prepare migration templates, develop approved changes, test integrations, train users and support go-live. Clarify what the customer team must provide and how delays in decisions or data affect the schedule.
The plan should include scope sign-off, configuration, development, data preparation, user acceptance testing, training, cutover, stabilization and change control. A realistic timeline depends on the actual scope and customer participation.
Compare the total ERP commercial scope
Two proposals cannot be compared by subscription value alone. One may include implementation and another may not. One may limit users, branches, storage or support. Another may exclude migration, integrations or custom reports.
Ask for a commercial table that separates recurring subscription or license from one-time services and optional future work.
| Cost area | Confirm in writing |
|---|---|
| Software | Modules, users, branches, billing term, storage and update policy |
| Implementation | Discovery, configuration, testing, project management and training |
| Data migration | Templates, number of cycles, historical depth and reconciliation responsibility |
| Custom work | Features, reports, integrations, acceptance criteria and change requests |
| Hosting and support | Environment, backup, monitoring, support hours, response and exclusions |
| Future expansion | Additional users, modules, branches, integrations and support tiers |
Review access, hosting, backup and change controls
Security should be evaluated against the selected deployment. Review role design, administrative access, password or identity controls, audit history, hosting architecture, database access, encryption, backup, restoration testing, monitoring and release practices.
Ask which responsibilities belong to the software provider, hosting provider, implementation team and your own administrators. Do not treat a generic security statement as a substitute for the final technical design.
Evaluate whether the vendor communicates scope honestly
A strong ERP partner should be willing to say when a requirement is not standard, when more discovery is needed and when a requested feature belongs in a later phase. Ask for written assumptions, exclusions, dependencies and acceptance criteria.
Also review the support model, escalation path, documentation, release process, ownership of custom code or data, exit arrangements and how future changes will be estimated.
ERP selection checklist before approval
Share your current workflow and receive a focused fit discussion.
OrbitSuite will review the business model, priority modules, data dependencies and likely implementation questions before arranging the product walkthrough.
Request ERP Fit AssessmentCommon ERP buying questions
Prepare the current workflow, sample documents, user roles, approval rules, reports, data sources, integrations, major pain points and the business outcome expected from the first phase.
Usually not. A phased rollout reduces change risk and allows data, ownership and user adoption to stabilize before additional modules are introduced.
Compare vendors against the same real business scenarios, documented requirements, implementation responsibilities, data migration plan, support coverage and total commercial scope.
The proposal should separate subscription or license, implementation, data migration, training, integrations, custom development, hosting, support, travel, taxes and future expansion costs.
There is no reliable universal timeline. Duration depends on modules, process complexity, data quality, customization, integrations, user availability, validation cycles and decision speed.