ERP / CRM
Eighty per cent of a standard package is functionality you will never use, and the twenty per cent you actually need comes back as customisation cost.
Built around your real approval lines and item hierarchy, not around a package assumptions.
What usually goes wrong
The spreadsheet is the real ERP
Inventory, orders and settlement are spread across several files, and nobody is confident about live stock.
The package does not fit the work
The system that was bought cannot hold the real approval line or pricing structure, so a second set of records appears.
Sales history belongs to a person
When the account manager leaves, the customer history leaves with them.
How we approach it
- 01Review process and dataWe take the sheets and documents you use today as they are and reverse-engineer the entities and state transitions from them.
- 02Stage the designWe do not build all of it at once. Of order, inventory and settlement, the bottleneck axis opens first.
- 03MigrationCleansing rules for the existing data are documented, and migration accuracy is confirmed with a reconciliation table.
- 04Permissions and auditRole-based permissions and a change history are part of the base design, not an addition.
What you receive
| Data model documentation | ERD, state transition diagram, code structure |
|---|---|
| The modules themselves | Order, inventory, purchasing, settlement and CRM pipeline within the agreed scope |
| Migration artefacts | Cleansing rulebook, migration scripts, row-count and total-value reconciliation table |
| Permission specification | A matrix of role, screen and field-level permissions |
| Integration interfaces | E-tax invoicing, bank transactions, courier APIs, your existing groupware |
How it runs
| Review and scope | 2 weeks | Process interviews, data inspection, agreement on the first release scope |
| Design | 2 weeks | ERD, permissions, screen design, migration plan |
| Build | 6-10 weeks | Module development with weekly demos |
| Migrate and run parallel | 2-3 weeks | Data migration and comparison against the existing method |
| Launch and stabilise | 2 weeks | Training, issue response, reporting setup |
Frequently asked
How do you migrate our existing data?
We take the spreadsheets or the existing database, document the cleansing rules, migrate with scripts and verify with a row-count and total-value reconciliation table. Rows that cannot be cleansed are listed for your team to decide on.
Will it integrate with our groupware and accounting software?
Through the API where a standard one exists, and otherwise through a file interface or a database link. We confirm and state what is possible for each target system before the engagement starts.
Why not a standard ERP package?
You do not pay for modules you never use, and your real approval line and pricing structure are reflected as they are. Conversely, for standard areas such as period-end accounting we recommend keeping your existing specialist package and integrating with it.
How far can the permission design go?
Screen access by role, field-level masking for figures such as cost and unit price, and edit rights by approval stage. Every change is recorded in history for audit.
How do we add functionality later?
Improvement items are collected monthly under the operations agreement and prioritised. The contract states explicitly what code and documentation belong to you.
Who owns the source code and the data?
Within the contracted scope, deliverables and data transfer to you as your own assets. We retain rights only over the reusable common framework.
A 30-minute call first
We do not quote a rate before the scope is defined. We map your current flow on a call and reply with a draft architecture and a staged cost range within a week.