Selection by demonstration
Vendors demonstrate their strengths. Comparing demonstrations compares sales craft, not suitability.
ERP & business systems
The platform is a consequence of the requirement, not the starting point.
ERP decisions are expensive to reverse. We separate the requirement from the product: understand how finance, supply chain and operations actually work, then evaluate platforms against that — including the option of keeping what you have.
The operating problem
Most ERP pain is requirement pain wearing a product label.
Selection processes often compare feature lists rather than fit. Implementations then spend their budget configuring around requirements that were never written down.
Undocumented process reality
The real process lives in spreadsheets and habit. Configuration starts against an idealized version and breaks on contact.
Integration treated as phase two
The ERP goes live disconnected from the systems that hold the stock, the pricing or the ledger, and manual reconciliation becomes permanent.
Recovery instead of rollout
A stalled or partially adopted implementation needs a different engagement from a new one, and is often run as though it were the same.
What we deliver
Across the full lifecycle, including recovery.
Discovery
Process, data and control mapping across finance, supply chain and operations, with the exceptions documented rather than smoothed over.
Selection
A structured evaluation against written requirements, with build-versus-buy tested rather than assumed.
Implementation
Staged rollout with testing against real tasks and real users, not a scripted demonstration environment.
Optimization
Work on an existing platform that is live but underused, where the constraint is configuration, process or adoption.
Recovery
Re-baselining a stalled implementation: what is salvageable, what must be redone, and what should be descoped.
Integration
Connecting the ERP to commerce, logistics, reporting and the systems it must stay in step with.
Selection discipline
SaaS, custom, or a hybrid — decided on evidence.
There is no default answer. The three routes fail in different ways, and the point of selection is to find which failure mode you can live with.
SaaS ERP
Fastest to a working baseline and cheapest to keep current. Constrains you to the vendor's model of your process, and integration is the usual hidden cost.
Custom
Fits a genuinely unusual operating model. Carries the full lifetime cost of ownership, and is rarely justified for finance and standard supply chain.
Hybrid
A packaged core with targeted extension where the business is genuinely differentiated. Needs disciplined boundaries or it becomes custom by accident.
Typical starting points
Where this work usually begins.
01
Finance and operations report different numbers for the same period
02
The current system cannot support a new entity, country or business line
03
An implementation has stalled and needs an independent read
04
The platform is live but large parts of it are unused
05
Month-end close is manual and slow
06
A procurement process needs a defensible evaluation, not a preference
Outcomes
What changes when this is done well.
A documented requirement
The requirement outlives the project and the vendor, and can be re-used at the next decision.
Fit over feature count
The platform matches how the business runs, so configuration effort falls and adoption rises.
One version of the numbers
Finance, operations and commerce reconcile because the systems are connected, not because someone rekeys.
A supportable estate
What was built is documented and transferable, including away from us.
How we engage
Requirement first, platform second.
Selection and implementation are separable. Many engagements stop after the requirements and options work, which is a legitimate and often correct place to stop.
Map
Document how finance, supply chain and operations run today, including the workarounds.
Define
Write the requirement, the constraints, the integration surface and the non-negotiables.
Evaluate
Test platforms and build-versus-buy against that requirement, with the reasoning recorded.
Implement
Roll out in increments, testing against real transactions before each cutover.
Operate
Support, optimize and extend once live, under explicit service ownership.
Where this applies
Industries this work most often serves.
Manufacturing
Planning, production visibility, inventory accuracy and the integration that keeps the plant and the ledger in step.
Logistics & transportation
Order and shipment visibility, warehouse operations, fleet data and the customer-facing status that removes the phone calls.
Healthcare & pharma
Supply chain, distribution, traceability and administrative systems where accuracy and audit trail are not optional.
Humanitarian & development
Programme, procurement, asset and reporting workflows with controls suited to the mission and to donor scrutiny.
Why Launch Soft Solutions
Platform-literate, not platform-loyal.
Oracle Fusion, Odoo and comparable platforms
Evaluated on fit for the requirement in front of us. We are not positioned as a single-platform implementer.
Implementation and recovery
A stalled programme needs different work from a new one. Both are in scope, and they are run differently.
Integration is not phase two
The connection surface is designed with the implementation, because that is where the reconciliation cost lives.
Related capabilities
What this usually connects to.
Integration & managed services
APIs, data flows and the continued operation of what has been delivered, under explicit service ownership rather than informal goodwill.
Custom software development
Applications, portals, workflow tools and internal systems built where no packaged product matches how the business actually works.
Digital transformation
Assessment, operating-model design and a sequenced roadmap, so modernization is absorbed by the organization rather than announced to it.
Questions
What organizations usually ask.
Are you an Oracle company or an Odoo company?
Neither. Both are platforms we work with, and both are evaluated against the requirement. ERP is one of seven capabilities, not the company identity.
Can you take over a stalled implementation?
Yes. That starts with an independent read of what is salvageable, which sometimes concludes that part of the work should be descoped rather than rebuilt.
Do we have to replace our ERP?
Often not. Where the platform is fit and the problem is process, integration or adoption, replacing it moves the cost without solving it.
Can we run selection with you and implement with someone else?
Yes. The requirement and evaluation are deliverables in their own right and are written to be used by whoever implements.
Decide on evidence, not on a demonstration.
Bring the operating problem. The platform conversation comes after the requirement is written down.