Solution 06
Custom ERP Development and Integration, Without the Second System of Record
Most companies do not need one more system. They need the ones they already have to stop disagreeing. Sometimes that means building an ERP around the operation, and sometimes it means integrating what exists and building only the missing layer.
Who this is for
- Companies running an ERP for accounts and spreadsheets for operations
- Businesses with a CRM, an accounting package and a production register that never reconcile
- Operations where the ERP was implemented but the shop floor never adopted it
- Companies planning an ERP decision and wanting an honest build-or-buy assessment
The problem
Why ERP projects disappoint operational businesses
- 01
The ERP models the ledger, not the process
It is strong on accounting, weak on job work, lot tracking, multi-stage conversion and shop-floor reality. So operations keeps its own records, and the ERP holds a tidy version that is always slightly untrue.
- 02
Adoption stops at the office door
Accounts and stores use it; the line does not, because the screens were never designed for a supervisor with dirty hands and thirty seconds. Production data therefore arrives late and second-hand.
- 03
Integration is a person with a spreadsheet
Data moves between systems by export, edit and import. It works until someone is on leave, and every pass introduces a chance to diverge.
- 04
No system of record was ever agreed
Two systems both hold the item master. Both are edited. Nobody decided which one wins, so both are wrong in different ways.
- 05
Customisation became a cost centre
Each change needs a vendor, a quotation and a wait. Over time the company adapts to the software instead of the other way round.
How the system works
How we approach ERP and integration work
An honest build, buy or extend assessment
We look at where your process is genuinely standard and where it is your competitive advantage. Standard gets a package. Distinctive gets built. We will recommend keeping software you already own when that is the right answer.
One declared system of record per entity
For items, customers, vendors, stock, orders and ledgers we agree which system owns each, which direction data flows, and what happens on conflict — before any code is written.
Real integration, not scheduled exports
API-based where the system supports it, database or file-based where it does not, with queued retries, error logs and reconciliation reports so failures are visible rather than silent.
The operational layer the ERP lacks
Shop floor, job work, quality, lot genealogy, planning and dispatch built as a first-class system, posting the results into your ERP so accounts get clean data without manual entry.
Accounting and statutory integration
Material, production and dispatch transactions flowing into your accounting system so the ledger is produced by the operation rather than re-keyed from it.
Reconciliation you can see
A report that shows what moved between systems, what failed and what does not match — because integration without reconciliation is just a slower way to diverge.
Automation
What stops being somebody's job
When this happens
The system does this
A dispatch is completed in operations
The invoice posts to the accounting system
A vendor or item master changes
The change propagates from its system of record
A CRM order is confirmed
It becomes an operational order without re-entry
Material is received against a PO
Stock and payables update together
An integration message fails
It is queued, retried and raised to a named owner
A reconciliation mismatch appears
It is reported the same day, not at month end
None of these need a person to remember them. That is the whole point.
Management visibility
What management can see once this runs
- A single operational picture spanning systems, not one screen per system
- What data moved between systems today, and what failed
- Mismatches between systems, listed rather than discovered
- Operational and financial views of the same order agreeing with each other
- Master data changes with an author and a timestamp
In practice
Situations this is usually bought for
Keep the accounting package, build the operations layer
The ledger, GST and statutory work stay where they are. Production, material, quality and dispatch are built properly and post their results across, so nothing is entered twice.
CRM to production without re-entry
A confirmed order in the sales system becomes an operational order with its items, quantities and dates intact — removing the re-typing step where errors and delays concentrate.
Replacing an ERP the floor never adopted
Where an ERP is genuinely the wrong fit, we replace it in stages — module by module, with both systems reconciled during transition — rather than in one high-risk cutover.
Multi-company consolidation
Several units with their own books and stock, sharing masters, transferring between each other, and consolidating for management reporting without a monthly spreadsheet exercise.
Before / after
What changes
Before
After
Two systems of record
One owner per entity, agreed in writing
Export, edit, import
Integration with retries and reconciliation
An ERP the shop floor ignores
Screens the shop floor will actually use
Every change needs a vendor quotation
A system your team can extend
How it works
From operational chaos to a connected business system
- 01
Understand
We sit with each department and learn the process as it is actually run — including the workarounds, the informal exceptions and the things people do because the official way does not work. This is where most of the value of the project is decided.
You getA written map of your current processes, departments and bottlenecks
1–2 weeks
- 02
Map
We trace how information moves between people, departments and systems: where it is created, where it is re-entered, where it is lost, and where a decision waits on something nobody can see. The re-entry points are almost always the expensive ones.
You getAn information flow map, with every handoff and duplication marked
1–2 weeks
- 03
Design
We design the target workflow — owners, rules, gates, automations and the screens each role needs — and agree it with the people who will live in it. We also agree what we are deliberately not building yet, and say so plainly.
You getA workflow design, screen list and phased build plan with scope you have signed off
2–3 weeks
- 04
Build
We build in phases, so one department is genuinely using something early rather than waiting for a full system. Each phase is delivered, tested with real data and put into use before the next begins — which is also how the awkward details get found while they are still cheap.
You getWorking software in real use, phase by phase, with integrations and reports
Phased, typically 4–12 weeks per phase
- 05
Optimize
After go-live we look at what is actually being used, which alerts are being acted on and which are being ignored, where people are still keeping a parallel sheet, and what the data now reveals that nobody could see before. Then we improve it.
You getUsage review, workflow refinements, new reports and ongoing support
Ongoing
Questions
Frequently asked questions
Still unsure whether your processes are a fit? Walk us through one of them.
Book an Operations Automation ConsultationShould we build a custom ERP or buy a packaged one?
Usually neither in pure form. Buy or keep a package for accounting and statutory work, where the rules are the same for everyone. Build the operational layer where your process is distinctive. A fully custom ERP including the ledger is occasionally right, but it is a large commitment and we will not recommend it lightly.
Can you integrate with Tally, SAP, Zoho, Odoo or Busy?
Yes. The approach depends on what each system exposes — a documented API, a database, or scheduled files. What matters more than the mechanism is deciding the system of record for each entity and building reconciliation so mismatches surface quickly.
What if our ERP vendor will not give us access?
It happens. We then work with what is available — export formats, reporting databases, or a read-only replica — and we are explicit about the limitations that creates, including how current the data can be. We would rather set that expectation up front than discover it late.
How do you avoid a big-bang go-live?
By not having one. We sequence by process rather than switching everything at once, run old and new in parallel where the risk warrants it, and reconcile during the overlap. It takes a little longer and it removes the scenario where the plant cannot dispatch on Monday.
Who maintains the system afterwards?
Either of us, and you should be free to choose. We document the data model, the integrations and the deployment, and we are happy to work alongside an in-house developer. Being the only people who understand your system is not a position we want to be in.
Keep reading
Related solutions and industries
Business Management Systems
Custom business management software for operational companies — production, orders, inventory, purchase and dispatch modelled on how your business works.
Operational Dashboards
Operations management software giving owners one real-time dashboard for orders, production, inventory, approvals, delays and department performance.
Industrial Software Development
Industrial software development built for shop-floor conditions, shift working, multi-location operations and systems expected to run for years.
Manufacturing Systems
Manufacturing software development covering production, material issue, quality, job work and dispatch — built for real shop-floor processes.
Next step
Your business has a process. Let's turn it into a system.
From manual workflows and disconnected departments to connected operations, automated processes and real-time visibility.