Choose an ERP system and organise implementation
An ERP connects several activities through shared data. Its usefulness depends on the processes covered, clear responsibilities and data quality. To compare quotes, define the initial scope, organisational size and implementation work rather than considering the number of modules alone.
Define the project through business processes
First implementation, replacement and extension require different work. Describe existing problems such as duplicate entry, hard-to-track orders or manual reconciliation. A complete example helps more than a generic wish list.
Specify the areas involved: finance, sales, purchasing, stock, production, projects or service. Decide which must start together and which can follow in a separate phase.
Distinguish businesses, sites and users
Several businesses may need separate accounts, permissions and rules. Different warehouses or workshops may belong to the same business. These dimensions affect configuration and licensing differently. Count the people who will actually need access and describe their tasks.
| Dimension | Describe in the request |
|---|---|
| Businesses | Separate data and accounts, possible consolidation |
| Sites | Warehouses, workshops and operations between sites |
| Users | Number of people, tasks and permissions |
| International | Relevant countries, languages and local requirements |
Ask for a complete process demonstration
Use a representative case: purchasing, receipt, stock, shipping and invoicing, or a project, time entry and billing. Check the handover between teams and how a correction is handled.
The demonstration should show who changes data, who approves it and how it appears in reports. A common database does not automatically eliminate errors or unclear responsibilities.
Separate standard functions, configuration and development
Examine standard and industry functions first. Configuring fields, permissions or rules differs from developing a custom feature. Justify necessary departures through a concrete process.
Document extensions, maintenance and tests after upgrades. Available functions can differ by version, edition and operating model; request confirmation in the quote.
Plan a controlled data migration
Identify the master data, open orders, stock and balances to transfer. Define cleansing, field mappings and responsible people. Transferring a full history is a different assignment from starting with active records.
Plan a trial import, control totals and a cutover date. Account for transactions during transition, readable access to archives and a fallback procedure.
Review interfaces, operation and access together
Name the programs that will stay: CRM, shop, payroll, banking or document management. For each interface, specify exchange direction, authoritative records, error handling and additional charges.
Compare responsibilities for updates, backups, restoration and export. Access rights and data-processing conditions still require review. An initial request can describe systems without sharing passwords or confidential business records.
Compare total cost and project assumptions
Compare quotes for the same businesses, users, modules, sites and period. Separate licences, project work and internal effort. Work excluded from the initial price may still be essential.
Ask for assumptions, exclusions, milestones and change rules. Consider future access, upgrades and data handover. Staff training and acceptance work also require time.
| Cost area | Check separately |
|---|---|
| Use | Edition, roles, businesses and modules |
| Project | Processes, configuration and acceptance |
| Migration | Cleansing, transfer and reconciliation |
| Extensions | Development, testing and upgrade compatibility |
| Operation and exit | Support, restoration, export and documentation |
Organise ownership and acceptance
Appoint an owner for each area. Define a pilot, training and acceptance criteria before committing to a cutover date. Test processes, permissions and reports with the people who will use them.
Plan issue handling and support after launch. For an initial quote, describe the areas, user and business counts, relevant sites and current systems. A short transition brief is enough; confidential data can be examined later through a suitable channel.
Frequently asked questions
What determines ERP cost?
Users, businesses, modules and sites, together with interfaces, adaptations, data migration and implementation work. Compare total cost over the same period.
Must all modules be implemented together?
Not necessarily. A phased implementation is possible if dependencies, data exchange and responsibilities between phases are clearly defined.
Is a business the same as a site?
No. One business may have several sites, and several businesses may share a site. Data separation and physical operations create different requirements.
Is custom development necessary?
Check standard functions and configuration first. An extension should meet a justified need with maintenance and compatibility testing planned.
Can existing programs remain?
Often, but concrete interfaces, responsibilities and limitations need review. Do not assume every connection is included in the licence.
Must I send business data with the request?
No. Describe the areas, organisational size and systems. Confidential files and access can be agreed securely later.
