If your first meeting with an ERP consultant begins with a softwaredemonstration, be careful.
Before anyone shows you System A or System B, they should understandhow your business operates, where its current processes fail and whatthe new system must achieve. Otherwise, you are not selecting softwareto fit your business. You are being encouraged to fit your businessaround the software the consultant already sells.
A good ERP consultant should begin with questions, not screens. Theyshould analyse your requirements, challenge assumptions and thenrecommend the most appropriate approach—even when it is not the productthey normally implement.
This guide explains how to find that consultant and retain enoughcontrol to ensure the delivered system genuinely fits yourorganisation.
Start with thebusiness, not an ERP product
ERP projects are easily framed as software-purchasing exercises. Abusiness decides it needs a new system, contacts several vendors andattends polished demonstrations. Each system appears capable becauseeach demonstration has been designed to make that product look good.
The real question is not, “Which ERP has the most features?” It is,“What does our business need to achieve, and which approach will supportit without unnecessary cost or rigidity?”
That cannot be answered from a standard demonstration.
An ERP project can affect finance, sales, purchasing, stock,operations, reporting and customer service. Oracle's implementationguidance includes business-process changes, data migration and employeetraining—not merely software installation. It also recommends across-functional implementation team. Oracle:Creating an ERP Implementation Project Plan
The consultant therefore needs to understand the organisation acrossdepartmental boundaries. They must discover where informationoriginates, who changes it, which decisions depend on it and why peoplemaintain workarounds outside the existing system.
Only then can software be assessed responsibly.
Why aready-made recommendation should raise an alarm
Ready-made ERP software is not inherently a bad choice. Establishedproducts can provide proven accounting, purchasing, inventory andreporting functions without requiring a business to build everythingitself.
The alarm bell should ring when an ERP consultant decides that aparticular product fits before analysing the business.
This often happens because the “consultant” is primarily a reselleror implementation partner for one product. Their knowledge may beexcellent, but their commercial model naturally leads towards the systemthey sell. If every problem has the same answer, you are receivingproduct implementation advice rather than an independent systemrecommendation.
Ask directly:
- Which ERP products do you sell or implement?
- Do you receive licence revenue, referral fees or commission?
- Are you willing to recommend a different product or approach?
- What analysis will you complete before making a recommendation?
- Who owns the requirements and other work produced duringdiscovery?
Commercial relationships do not automatically disqualify aconsultant. They simply need to be visible. The business can then decidewhether it wants vendor-neutral advice, product-specific expertise orboth from separate providers.
Whatproper ERP requirements analysis should include
A requirements analysis should explain the business before itattempts to specify the software. It must go beyond collecting a wishlist from department heads.
Business objectives
Why is the organisation changing its system? Possible reasons includepoor visibility, duplicated work, disconnected applications, growthconstraints or processes that can no longer be controlled reliably.
The objectives should be specific enough to guide decisions later.“Modernise our ERP” is vague. “Provide one reliable view of availablestock across three locations” can be examined and tested.
Current processes andproblems
The ERP consultant should speak to people who perform the work, notonly senior managers. Formal procedures often differ from what happensin practice.
This is where spreadsheets, manual rekeying, unofficial databases andother workarounds emerge. Some exist because the current system isinadequate. Others compensate for unclear responsibilities orinefficient processes. Replacing the software without understanding thedistinction can recreate the same problems in a more expensivesystem.
Future processes
Requirements analysis should not preserve every existing processautomatically. A consultant who agrees with every request may feel easyto work with, but is not necessarily serving the client well.
The consultant should help distinguish between:
- Processes that give the business a genuine advantage.
- Necessary controls or regulatory obligations.
- Sensible standard practices that an existing ERP can support.
- Historical habits that should be changed rather thancustomised.
Software should fit the business, but “fit” does not mean reproducingevery old workaround.
Data and integrations
The analysis must identify master data, transactions, documents,spreadsheets and external systems that need to be migrated orconnected.
Microsoft distinguishes configuration data, which controls how asolution operates, from migration data such as customers, products andopen transactions. Its guidance recommends an explicit migrationstrategy, assigned responsibilities and validation of data quality andaccuracy. Microsoft:Manage configuration and migration data
If personal data will be transferred, the organisation also retainsresponsibility for its accuracy, relevance and security. ICOguidance on sharing personal data in databases and lists
Priorities and constraints
Not every requirement has equal value. The analysis should classifywhat is essential for launch, what can follow later and what is merelydesirable.
It should also record practical constraints: budget, internalcapacity, deadlines, security needs, deployment preferences, reportingobligations and dependencies on other projects.
Without priorities, every department can treat its requests asmandatory and the project becomes difficult to control.
Measurable acceptancecriteria
A requirement such as “the stock screen must be user-friendly” isalmost impossible to accept or reject objectively. A strongerrequirement describes the task and expected result:
A warehouse user must be able to locate an item and see available,allocated and incoming quantities for every location from a singleview.
Acceptance criteria turn requirements into a basis fordemonstrations, estimates, testing and final sign-off.
What should therequirements phase produce?
Before product selection, you should expect a usable body of workrather than a presentation that disappears when the meeting ends.Depending on project size, this may include:
- Agreed business objectives and success measures.
- Current and proposed process descriptions.
- Prioritised functional requirements.
- Data migration and integration requirements.
- Security, reporting and deployment requirements.
- Identified risks, assumptions and unresolved decisions.
- Representative business scenarios.
- Measurable acceptance criteria.
- A recommendation with reasons and alternatives considered.
These materials should belong to the customer and remain useful ifthe business changes consultant or supplier.
Make ERP vendorsdemonstrate your business
Once the requirements are understood, demonstrations becomeuseful—but they should be based on your scenarios.
Instead of asking a vendor to “show the sales module”, provide arealistic journey. For example:
- A customer requests an item that is not available in the nearestwarehouse.
- The salesperson checks stock elsewhere and gives a reliable deliverydate.
- The order reserves stock and triggers purchasing wherenecessary.
- A manager can see the effect on availability, margin and cashrequirements.
- The customer receives the correct confirmation without informationbeing rekeyed.
This exposes how the system handles connections between departments.It also makes competing products easier to compare.
If an important step is missing, ask whether it can be configured,requires an extension or cannot be supported. Record the answer and itscost implications. Do not accept “the system can do that” without seeinghow.
Choose the right typeof ERP consultant
“ERP consultant” can describe several different roles:
RolePrimary contributionMain risk to checkIndependent adviserRequirements, selection and customer-side oversightMay not provide hands-on implementationFunctional consultantProcesses and system configurationMay be tied closely to one productTechnical consultantDevelopment, integration and migrationMay lack broader business authorityImplementation partnerMultidisciplinary delivery of a particular ERPCommercial incentive to sell its own solution
For a smaller project, one provider may cover several rolessuccessfully. For a larger or higher-risk project, it can be valuable tokeep independent customer-side advice separate from the implementationpartner.
The important questions are: Who recommends? Who sells? Who delivers?Who checks the delivery? And who represents the customer's interestswhen priorities conflict?
How to evaluate an ERPconsultant
Ask candidates to describe how they work before asking which productthey recommend.
Look for questions beforeanswers
A credible consultant will want to understand your goals, processes,data, people and constraints. Someone who produces confident answersimmediately may simply be matching you to a familiar salesproposition.
Ask for comparableexperience
Request examples of projects with similar operational complexity, notmerely customers from the same industry. Ask what the consultantpersonally delivered, which problems arose and how decisions weremade.
Examine theirwillingness to challenge you
The consultant should challenge unnecessary customisation,unrealistic deadlines and conflicting requirements. The aim is not tofind someone who agrees with everything, but someone who can explaintrade-offs clearly.
Check how they approachdata and users
Weak proposals frequently concentrate on features while treating datamigration, testing, training and adoption as secondary matters. Strongcandidates raise these issues early because they understand that atechnically functioning system can still fail its users.
Understand all commercialincentives
Ask for clarity about licences, referral arrangements, subcontractorsand continuing support revenue. You need not reject a consultant withvendor relationships, but you should know when advice and sales arecombined.
How to makethe consultant deliver a fitting system
Selecting the right consultant is only the beginning. The engagementmust convert the requirements into practical control over delivery.
Put the requirementsinto the contract
The agreed scope should reference prioritised requirements,deliverables and acceptance criteria. Important commitments must notexist only in demonstration notes or emails.
Use staged decisions andpayments
Separate discovery, design, configuration, migration, testing andgo-live into visible stages. Each stage should produce something thatcan be reviewed before the project moves forward.
Maintain a requirementstrace
Every important requirement should connect to a design decision,configuration or development item and test result. This preventsessential needs from quietly disappearing between sales anddelivery.
Control changes
Requirements will evolve, but changes need an agreed process. Foreach proposed change, record why it is needed and its effect on cost,timing, maintenance and other requirements.
Keep business ownership
The consultant supplies expertise; the organisation must stillprovide decisions, process owners, data knowledge and users for testing.Outsourcing the project does not outsource accountability for how thebusiness will operate.
Test real end-to-end work
User acceptance testing should follow the same representativescenarios used during selection. Microsoft recommends a defined testplan covering scope, test types, cycles and outcomes so the solution canbe checked against business requirements. Microsoft:Create a test plan
Before launch, complete migration, cutover, training, security andproduction-support plans. Microsoft:Prepare to go live
Considermore than packaged ERP versus bespoke development
After analysing the requirements, a good consultant should considerthe full range of possible approaches:
- Use an existing ERP largely as supplied.
- Configure and integrate an existing ERP.
- Extend an existing platform for a small number of distinctiverequirements.
- Commission bespoke software where the need genuinely justifiesit.
- Consider an adaptable, metadata-driven platform that aims to combinereusable foundations with business-specific configuration.
Traditionally, businesses have faced an uncomfortable choice: adapttheir processes to a ready-made ERP or commission custom software thatcan be expensive and slow to develop. An adaptable platform couldprovide another route by reusing common capabilities while allowing moreof the application to follow the business's requirements.
Sevenlake's planned approach
Sevenlake is being designed around that alternative. Its plannedopen-source, metadata-driven platform aims to support ERP, CRM andcustom business applications through reusable modules, structuredapplication definitions and AI-assisted customisation.
The objective is to make it easier to adapt software to the businessrather than forcing the business into one rigid workflow, withoutrepeatedly building every common software component from scratch.
Sevenlake is currently at the vision and architecture stage and ismoving towards a proof of concept. It is not yet a finished ERP productor available for production implementation. Its modules, AI Builder,marketplace and formal partner programme are planned rather thancurrently available.
Within the intended future ecosystem, consultants would begin withbusiness requirements and then help configure, customise, implement andsupport appropriate Sevenlake-based solutions. They could also turnprocess and industry expertise into reusable templates or modules.
Frequently asked questions
Shouldan ERP consultant recommend software at the first meeting?
No responsible recommendation can be made without understanding thebusiness. A consultant may discuss possible approaches, but productselection should follow requirements analysis.
Is aproduct-specific ERP consultant necessarily biased?
Not necessarily. Product expertise can be extremely valuable duringimplementation. However, the consultant's commercial relationship shouldbe clear, and the customer should decide whether independent selectionadvice is also required.
Should ERPsoftware fit every existing process?
No. Requirements analysis should identify which processes aregenuinely valuable and which should be simplified or replaced. Fittingthe business does not mean preserving inefficient habits.
How can we provethat the delivered ERP fits?
Use prioritised requirements, measurable acceptance criteria,representative scenarios and traceable test results. Do not rely ongeneral promises that the system “supports” a function.
Who should own therequirements analysis?
The customer should own and retain the resulting documents anddecisions, even when a consultant prepares them. They form the basis forselection, contracting, delivery and future improvement.
Requirements first,recommendation second
The right ERP consultant does not begin by showing you what they wantto sell. They begin by learning how your business works and what the newsystem must achieve.
Insist on requirements analysis before product selection. Makevendors demonstrate your scenarios. Turn the agreed requirements intocontractual deliverables and measurable tests. Most importantly, appointa consultant who is prepared to recommend the right approach rather thanautomatically recommending the product they already know.
Interested in a future platform designed to make business softwaremore adaptable? Register yourinterest in Sevenlake's planned partner ecosystem and follow itsdevelopment.
