Service
The system the whole company actually opens.
ERP and CRM work for companies whose operations have outgrown spreadsheets, email threads and one person's memory. We map how the work really runs, implement against that rather than the org chart, and stay involved through go-live and the weeks after.
The Problem
Where these programmes go wrong.
ERP and CRM projects rarely fail on features. They fail on the parts nobody scoped — the exceptions, the migration, and the week the team quietly reopens the old spreadsheet.
- 01
The documented process is not the real one
Configuration gets built from the workflow on paper. The live one has exceptions, side agreements and someone who knows which orders skip a step. All of it surfaces after launch.
- 02
Migration is treated as a task
Years of records arrive with duplicate customers, dead product codes and fields quietly used for something other than their label. Loading them unchanged moves the mess into a more expensive system.
- 03
Adoption is assumed
Training happens once, right at the end. When the new screen takes longer than the old habit, people route around it — and the reporting that justified the project stops being true.
The Approach
Map first, configure second.
We treat a rollout as an operations change that happens to involve software. Configuration is the predictable half. Sequencing, data and people are where the attention goes.
- 01
Follow the work end to end
We trace how an order, a case or a lead actually travels — including the steps handled from memory — before deciding what gets configured, what gets built, and what should simply stop.
- 02
Migration as its own workstream
A separate track with its own owner: extraction, cleansing rules you approve, and a trial load of the full set rather than a tidy extract. You see your data inside the new system while changing your mind is still cheap.
- 03
Cut over in slices
Where the operation allows, we land one department or one flow at a time, run it alongside the incumbent and keep a reversible path back. A big-bang switch is a decision, not a default.
Capabilities
What we take on.
Whether the answer is a configured platform, a purpose-built system or a smaller change to what you already run, the same ground gets covered.
-
Process mapping and scoping
Workshops with the people who do the work, not only the people who describe it. The output is a mapped process, a decision log, and a scope with the expensive requests named as expensive.
-
Platform implementation
Configuring a commercial ERP or CRM against the mapped process — modules, roles, approval chains, numbering, document templates — and holding customisation to what the platform genuinely cannot do.
-
Custom ERP and CRM builds
When an operation is genuinely unusual, a built system costs less than fighting a product's assumptions for years. Naming which of the two you are in is part of the work, not an upsell.
-
Data migration and cleansing
Extraction from legacy databases, spreadsheets and the occasional shared drive, with deduplication and field mapping agreed in writing, plus reports that show what moved, what changed and what was deliberately left behind.
-
Integration with incumbent systems
Accounting, warehouse, storefront, payroll and the in-house tool that is not going away — joined through APIs and queues, with retries, alerting and a record of what failed instead of unattended file drops.
-
Adoption and change management
Role-based training, documentation written for the job rather than the menu, and time alongside the team once the system is live to fix whatever runs slower than the process it replaced.
Technologies
What we implement and build with.
The decision follows the operation, not a shortlist. These are the platforms and tools we work with, and we will point you outside the list when something else fits better.
Platforms
Custom build
Data and migration
Integration and operations
Process
How an engagement runs.
- Step 01
Operational audit
We sit with finance, sales, operations and the people on the tools. What comes out is a picture of the work as it stands, where it stalls, and which steps exist only because a system once demanded them.
- Step 02
Fit decision
A written recommendation — configure, build, or both — with the trade-offs stated, the customisation you would be committing to maintain, and the requirements we think you should drop.
- Step 03
Configure and migrate together
The build and the data track run in parallel, because a system configured against sample records is a demo. Each dry run produces findings that change the configuration, not a pass mark.
- Step 04
Pilot one real flow
A single team runs a genuine end-to-end case — a real order, a real month-end — while the current system stays live. What that surfaces goes back into configuration; nobody else moves until it is closed.
- Step 05
Cutover and hypercare
The move runs in a fixed order, with a path back if the numbers disagree, then a support window where questions come from the people using the system, not the steering group. Handover is the runbook, admin rights and documentation.
Start with the process, not the platform.
Send the outline of your operation — what runs where, which systems have to stay, and what you have already tried. We will come back with a view on fit before anyone discusses licences.