Selection advice comes from parties paid on the outcome
The organisations recommending a platform frequently earn implementation fees or licence margin on it. The advice may still be right, but you have no way to tell.
ERP and business application consulting
ERP decisions are among the most expensive and least reversible an organisation makes, and they are usually taken with advice from parties who are paid on the outcome. We sell no licences and take no commissions, so our recommendation is only worth what the analysis is worth.
Business challenges
This advisory is commissioned when a core business system has become a constraint, or when one is about to be chosen.
Customisation has trapped the system on an old version
Modifications made to fit the business now block every upgrade, so the platform ages in place and the cost of moving grows each year.
The ERP is a data island
Integration was scoped as an afterthought, so information moves between systems by export, re-keying and reconciliation.
Requirements were written as a feature list
Vendors are compared on checkbox coverage rather than on how well each supports the handful of processes that actually differentiate the business.
Migration is discovered to be the hard part
Master data quality, historical records and cutover sequencing were underestimated, and the programme date slips for reasons unrelated to the software.
Adoption never happened
The system went live and the business kept its spreadsheets, so the organisation now runs two processes and reconciles between them.
Business outcomes
What changes when the selection and the integration are engineered rather than delegated to the implementer.
- A selection decision supported by evidence you can inspect, from a party with no stake in it
- Configuration preferred over modification, so upgrades remain possible
- Integration designed as part of the programme rather than discovered during it
- Migration scoped against actual data quality rather than an assumption about it
- A defined position on which processes change to fit the system and which do not
Why independence matters most in this decision
An ERP choice is expensive, long-lived and difficult to reverse.
Core business systems are usually operated for a decade or more. The licence cost is rarely the largest number: implementation, integration, migration, training and the ongoing cost of process misfit generally exceed it, and none of those appear on a vendor comparison sheet.
Most advice available at the decision point comes from parties with a commercial interest in the answer — implementation partners, resellers and vendors. That does not make the advice wrong, but it does make it impossible for you to distinguish from advice that is.
We resell nothing, hold no partner status and take no commission on any platform. Our recommendation is worth exactly what the analysis behind it is worth, and we show you the analysis.
Our consulting approach
Four commitments that shape every ERP engagement.
Independent of every vendor
No licence resale, no partner status, no commission. Recommending a smaller platform, or no replacement at all, costs us nothing.
Process before product
Requirements are written as processes and outcomes, not as a feature list. Feature lists compare vendors on the wrong axis.
Configure, do not modify
Every modification is a permanent upgrade cost. We hold a high bar for it and are explicit about what each one will cost you later.
Total cost, not licence cost
Implementation, integration, migration, training and process misfit are modelled alongside licensing, because together they dominate it.
Requirements definition
Requirements written as a feature list produce a comparison in which every serious vendor scores highly, because modern platforms all have the features. The comparison then turns on price and presentation.
We write requirements as processes and outcomes, and separate the few that genuinely differentiate your business from the many that are standard. The differentiating ones decide the selection; the standard ones should be adopted as the platform does them.
- Processes documented as they actually run, not as the procedure describes them
- Differentiating requirements separated from standard ones explicitly
- Statutory and reporting obligations captured as hard constraints
- Volume and growth assumptions stated, because they affect edition and cost
Vendor-neutral selection
A selection process is only as good as its ability to distinguish between candidates. Scripted demonstrations rarely do, because vendors prepare them.
We evaluate against your differentiating processes using your data, score openly against weighted criteria agreed before the demonstrations, and record why each candidate placed where it did. The recommendation is inspectable, which matters when it is questioned two years later.
- Criteria weighted and agreed before any vendor is seen
- Evaluation against your differentiating processes using your data
- Scoring recorded with reasoning, so the decision remains inspectable
- Total cost modelled over the expected life, not the first year
Fit-gap analysis
Every gap has three possible answers: change the process, configure around it, or modify the system. The third is chosen far more often than it should be, usually because the process is assumed to be a requirement when it is a habit.
We test that assumption on every gap. Where a process genuinely differentiates the business, it is worth accommodating; where it exists because a previous system worked that way, it is worth reconsidering before it becomes a permanent upgrade cost.
Customisation and the upgrade path
Modification is what traps organisations on old versions. Each change is individually reasonable and collectively becomes the reason an upgrade is deferred, which raises the cost of the eventual move every year.
We hold a deliberately high bar: extension through supported interfaces wherever possible, modification only where a differentiating process genuinely requires it, and the future cost of each one stated at the point the decision is taken rather than discovered later.
- Extension through supported interfaces preferred to core modification
- Each modification's upgrade cost stated when the decision is made
- A register of modifications with the business reason for each
- Periodic review of whether a modification is still earning its cost
Integration architecture
The ERP is never the only system. Integration with commerce, manufacturing, logistics, banking, payroll and reporting platforms is usually where the effort actually goes, and it is regularly scoped last.
We design integration as part of the programme: which system masters which entity, how data flows and in which direction, and what happens when an interface fails. Detailed design draws on enterprise architecture.
- A stated position on which system masters which entity
- Interface contracts specified before implementation begins
- Failure behaviour defined per interface rather than assumed
- Reconciliation designed in where correctness is contractual
Data migration
Migration is the most consistently underestimated part of an ERP programme, because effort is proportional to data quality, and data quality is unknown until someone profiles it.
We profile early, decide deliberately what is migrated rather than defaulting to everything, and treat cleansing as business work rather than a technical step — only the business can decide which of two conflicting customer records is correct.
- Data profiled early, so migration effort is estimated rather than assumed
- Migration scope decided deliberately: master data, open items, history
- Cleansing owned by the business, because only it can resolve conflicts
- Trial migrations run repeatedly, with reconciliation to source each time
Implementation governance
Where the implementation partner also reports on the implementation, problems surface later than they should. Independent oversight is not adversarial; it is what makes early escalation possible.
We represent your interests during delivery: reviewing design decisions, testing the assumptions behind estimates, and raising risks while there is still time to act. We are explicit that we do not implement the platforms we advise on, which is what makes the oversight credible.
- Design decisions reviewed against the requirements they are meant to satisfy
- Estimates and dependencies tested rather than accepted
- Change requests assessed for whether they are genuinely new scope
- Risks raised early, in writing, while there is still time to act
Testing and acceptance
ERP testing is a business exercise. The question is not whether the software functions but whether the organisation can complete its processes end to end, including period close, statutory reporting and the exceptions that occur monthly rather than daily.
We define acceptance criteria before build so a go-live decision is a matter of evidence rather than judgement under pressure. Automation of the surrounding estate is quality engineering work.
Cutover and go-live
Cutover is a sequencing problem under a time constraint: final migration, reconciliation, opening balances and the point beyond which the old system is read-only. Each step has a duration, and the sequence has to fit the window the business can tolerate.
We plan it as a rehearsed procedure with a decision point and a defined fallback. A cutover plan with no fallback is a commitment made before the evidence is available.
- The sequence rehearsed end to end, with each step timed
- A go/no-go decision point with criteria agreed in advance
- A fallback position defined and verified rather than assumed
- Hypercare staffing planned, because the first close is the real test
Adoption and process change
The most common way an ERP programme fails is quietly: the system goes live, the business keeps its spreadsheets, and the organisation now runs two processes and reconciles between them.
Adoption is a design concern, not a communications exercise. Where the new process is slower or less capable for the people doing the work, they will keep the old one, and no amount of training changes that. We identify those cases during fit-gap, while they can still be addressed.
Licensing and total cost
Licence models are structured to be difficult to compare: named versus concurrent users, module bundling, edition thresholds and consumption metrics that behave differently at scale.
We model total cost over the expected life against your actual volume and growth, including implementation, integration, migration, training and support. Because we take no commission, the model has no interest in arriving at a particular answer.
Getting more from the ERP you already have
A meaningful share of ERP engagements should not end in a replacement. Frequently the platform is capable and the problems are elsewhere: unused modules, configuration that no longer matches how the business runs, integration gaps, or reporting built around the system rather than in it.
Replacement is expensive, disruptive and carries its own failure modes. Where the existing platform can be made to serve, we will say so — and a recommendation not to replace is one an implementation partner is poorly positioned to make.
- Capability already licensed but unused identified before replacement is considered
- Configuration reviewed against how the business runs now
- Integration and reporting gaps assessed as separable problems
- Replacement recommended only where the platform is genuinely the constraint
What you receive
Requirements, an evidenced selection recommendation, and the integration and migration design the implementation depends on.
- Requirements written as processes and outcomes, with differentiators separated
- Weighted selection criteria agreed before vendor engagement
- Evaluation record with scoring and reasoning, inspectable after the decision
- Total cost model over the expected life, not the first year
- Fit-gap analysis with a configure, change-process or modify decision per gap
- Integration architecture with mastering, contracts and failure behaviour defined
- Migration plan based on profiled data quality, with cleansing ownership assigned
- Cutover plan with rehearsal, decision criteria and a verified fallback
Engagement models
Initial project design
Engaged before significant code exists, when structural decisions are still cheap to change. Produces the target-state architecture, the technology selection rationale, and a sequencing plan the delivery team can execute.
Mid-project assistance
Engaged when delivery has slowed, costs are rising, or a design that fitted the original problem no longer fits the current one. Diagnostic first: we establish what is actually causing the drag before recommending change.
Ongoing support
A named architect available as the system evolves, covering design review, technology decisions and course correction. Delivered under a subscription rather than a fixed project scope.
Enterprise delivery
How an ERP engagement runs.
Free first consultation
Your current systems, the constraint you are experiencing, and whether replacement is likely to be the right instrument.
Requirements and current state
Processes as they actually run, data quality profiled, and the obligations that act as hard constraints.
Selection
Weighted criteria, evaluation against your processes and data, and a recommendation with the reasoning recorded.
Design
Integration architecture, migration approach and fit-gap decisions, completed before implementation begins.
Implementation oversight
The partner implements; we represent your interests, review design and raise risks while there is time to act.
Cutover and stabilisation
Rehearsed cutover, go/no-go against agreed criteria, and support through the first period close.
Technologies and platforms
We advise on these; we do not resell any of them.
Enterprise ERP suites
The large-vendor platforms, assessed on fit and total cost rather than on market position.
Mid-market ERP
Platforms that frequently fit better than enterprise suites at mid-market volume, and cost materially less to run.
Cloud and SaaS business applications
Subscription platforms, assessed including the exit position and data portability.
Open-source ERP
Viable where internal capability exists to operate them; assessed honestly on that condition.
CRM platforms
Customer systems and their boundary with the ERP, which is a frequent source of mastering conflict.
HR and payroll systems
Statutory requirements and the integration to finance.
Warehouse and manufacturing systems
Operational platforms and their interface to the core system.
Integration platforms
Middleware and API layers where point-to-point integration would not remain maintainable.
Reporting and analytics
Reporting built on a governed data foundation rather than extracted per request.
Migration tooling
Profiling, transformation and reconciliation for the migration itself.
Industries served
Sector determines the process fit, the statutory requirements and the cost of getting the choice wrong.
Industry
Manufacturing
Production planning, bill of materials and shop-floor integration.
IndustryRetail & E-commerce
Inventory across channels and reconciliation to commerce platforms.
IndustryHealthcare
Clinical and administrative system boundaries, and data sensitivity.
IndustryBanking & Financial Services
Statutory reporting and audit trail obligations on core records.
IndustryInsurance
Policy and claims platforms interfacing with finance.
IndustryTelecommunications
High-volume billing and provisioning interfaces.
IndustryGovernment & Public Sector
Procurement structure, transparency and long system life.
IndustryEducation
Student, finance and HR systems that are frequently poorly integrated.
IndustryEnergy & Utilities
Asset-intensive operations and regulated reporting.
IndustryLogistics
Warehouse, transport and order systems with continuous operation.
Why NG&NR
No licence resale, no commission
We hold no partner status with any ERP vendor. Recommending a smaller platform, or no replacement at all, costs us nothing.
We do not implement what we recommend
That separation is what makes independent oversight credible, and we state it plainly rather than positioning selection as a route to a larger engagement.
The analysis is inspectable
Weighted criteria, scoring and reasoning are recorded, so the decision can still be defended when it is questioned two years later.
Named accountability
A named lead owns the technical outcome and remains the point of contact for the engagement.
Frequently asked questions
The question has no general answer, and any consultancy offering one is telling you about its commercial arrangements rather than your business. Fit depends on your differentiating processes, volume, statutory obligations and the capability you have to operate the platform. We evaluate against those.
Neither. We hold no partner status, take no commission and do not implement the platforms we advise on. That separation is what makes the recommendation and the implementation oversight worth anything.
Frequently the latter, and it is worth testing before committing. Many estates have licensed capability that is unused, configuration that no longer matches how the business runs, or reporting gaps that are separable problems. Replacement is expensive and carries its own failure modes.
It depends on scope, data quality and how much process change the organisation will accept — and the second of those is usually unknown until data is profiled. We estimate after that profiling rather than before it, because an estimate given beforehand is a guess presented as a plan.
Because the effort is proportional to data quality, and data quality is unknown until someone profiles it. Cleansing is also business work rather than a technical step — only the business can decide which of two conflicting records is correct — and that capacity is rarely planned for.
Less than most programmes end up with. Every modification is a permanent upgrade cost and is what traps organisations on old versions. We hold the bar at differentiating processes only, and state each modification's future cost at the point the decision is taken rather than letting it emerge later.
Usually because the new process was slower or less capable for the people doing the work, so they kept the old one. That is a design outcome rather than a training failure, and it is identifiable during fit-gap while it can still be addressed.
Yes, and it is a common engagement. We review design decisions against the requirements they are meant to satisfy, test estimates and dependencies, and raise risks in writing while there is still time to act. Where the partner also reports on its own delivery, problems surface later than they should.
By modelling total cost over the expected life against your actual volume and growth — including implementation, integration, migration, training and support, which together generally exceed the licence. Licence models are structured to resist comparison, which is why the comparison has to be built rather than read.
Then that is the recommendation, and we have made it. It costs us the implementation work that would have followed, which is precisely why it is worth commissioning advice from a party that does not do that work.
Integration design draws on enterprise architecture. Where the surrounding estate needs custom work, that is software development. Where reporting is the real constraint, it is usually data engineering.
Typically a fixed-scope requirements and selection phase, then optional implementation oversight through a subscription for the duration of the programme. Pricing is transparent and includes GST. The first consultation is free.
Next step
Discuss an ERP or business application decision
A free first consultation covering your current systems, the constraint you are actually experiencing, and an honest view of whether replacement is the right instrument — from a party that earns nothing either way.
No cost, no obligation. Pricing is transparent and includes GST.