Reduce fragmentation
Define where important records belong and how teams use them instead of maintaining conflicting copies.
Operations / Data / Decisions
One system. Clearer work.
Hich Web plans and builds custom ERP systems around the people, information, approvals and exceptions that keep a business moving—without pretending every operation fits the same template.
ERP / Operating modelRole-based
01 / StructureModules
02 / ActionWorkflow
03 / RecordData
04 / InsightControl
01 / PeopleRight role
02 / ProcessClear next step
03 / DataKnown source
04 / ControlVisible status
Custom ERP, defined
Connected business software shaped around real operations.
A custom ERP brings selected workflows, operational records, user roles, approvals and reporting into a planned system. It should reduce avoidable fragmentation while preserving the controls and exceptions the business genuinely needs.
01 / ERP fit
Solve the operating problem first.
Custom software adds value when it makes important work clearer and more dependable. It should not be used merely to reproduce every existing spreadsheet in a browser.
Clarify handoffs
Make ownership, status, approvals and exceptions visible across a process rather than relying on memory.
Match access to work
Give each role the actions and information needed for its responsibilities, with sensitive boundaries agreed explicitly.
Report from the process
Shape operational reporting around trustworthy captured data and the decisions teams actually need to make.
02 / Module map
Connected modules, purposeful boundaries.
These are common operational areas, not a fixed feature package. Discovery determines what belongs in the system, what stays elsewhere and what needs to connect.
Sales & customers
Track agreed stages from enquiry or account context through quotation, order or service activity.
- Customer records
- Sales stages
- Quotes and orders
Inventory
Represent products, stock locations, movements and adjustments with clear ownership and traceability.
- Items and locations
- Receipts and issues
- Transfers and adjustments
Procurement
Structure supplier information, requests, purchasing stages, receipt and the approvals the process requires.
- Suppliers
- Purchase workflow
- Receiving status
Finance visibility
Support agreed operational totals, payment states, exports or integrations without making unsupported accounting assumptions.
- Transaction status
- Operational summaries
- Exports or connections
People & roles
Model staff records, responsibilities, access and selected workforce workflows according to the project scope.
- User roles
- Team structures
- Selected people workflows
Jobs & service
Coordinate work orders, projects, appointments or field tasks when service delivery is central to operations.
- Work status
- Assignments
- Service records
03 / System design
Data needs ownership. Actions need context.
The most important ERP decisions often sit between modules: who may act, where data originates, what happens when something fails, and how a team verifies the result.
| Design area | What must be defined | Why it matters |
|---|---|---|
| Roles & permissions | Responsibilities, view access, create/edit rights, approvals and sensitive actions | Access should support work without exposing unnecessary capability. |
| Workflow & status | Entry conditions, owners, transitions, exceptions, cancellation and completion | Teams need to understand what happened and what comes next. |
| Data ownership | Authoritative records, required fields, identifiers, history and retention | Connected modules are only useful when shared information is dependable. |
| Approvals | Thresholds, approvers, delegation, rejection and supporting evidence | Important decisions need a practical route and appropriate accountability. |
| Integrations | Direction, frequency, mapping, validation, retries and reconciliation | An external dependency must not turn silent failure into bad operational data. |
| Reporting | Audience, decision, filters, definitions, freshness and export needs | A report should answer a real question using data captured by the process. |
Operational safeguards
Designed for responsible use.
The exact controls depend on the sensitivity and context of the system. These concerns should be addressed during discovery, not added as a launch-week checklist.
01 / AccessRole model
02 / AccountabilityAudit needs
03 / ContinuityBackup plan
04 / RecoveryError paths
05 / DataMigration checks
06 / AdoptionTraining plan
04 / Implementation
A controlled move from current to new.
ERP implementation combines software delivery with data preparation, process decisions, user readiness and a deliberate cutover.
Observe the work
Map current processes, records, users, pain points, exceptions, external systems and constraints.
Set the model
Agree module boundaries, core data, roles, workflows, integrations, reports and a phased roadmap.
Prototype flows
Test representative tasks and interface decisions with the people who understand the process.
Build and migrate
Deliver working increments while preparing, trialing and checking required data and integrations.
Roll out with care
Verify access, train users, document responsibilities, manage cutover and prioritize post-launch learning.
05 / ERP planner
Map an indicative first scope.
Select relevant modules and system concerns. The summary is an input to discovery, not confirmation that every selected feature belongs in one release.
06 / Useful answers
Questions before custom ERP.
ERP decisions affect daily operations. These answers are deliberately practical and avoid promising a fit before discovery.
When is a custom ERP appropriate?
A custom ERP may be appropriate when important workflows, roles or integrations cannot be handled sensibly by existing tools and the value of a tailored process justifies the additional design, implementation and ownership responsibility. Hich Web first examines whether configuration or focused integration could solve the problem more simply.
Can an ERP begin with only a few modules?
Yes. A phased ERP can begin with a coherent operational area and expand after its data, responsibilities and adoption are stable. Phase boundaries must protect the shared data model and avoid creating another disconnected system.
Can existing spreadsheet or software data be migrated?
Potentially. The data must first be profiled for ownership, structure, duplication, missing values and historical relevance. Migration includes mapping, cleaning responsibilities, trial imports, validation and a documented cutover plan.
Can the ERP connect to an e-commerce store or other software?
Integrations can be considered where the other system offers an appropriate technical interface or data exchange method. Each connection needs defined ownership, direction, frequency, validation, failure handling and reconciliation.
How are ERP permissions and accountability handled?
Roles and permissions are mapped to actual responsibilities and separation needs. Sensitive actions, approvals and relevant changes can be designed with explicit access rules and audit requirements agreed during discovery.
How much does a custom ERP cost and how long does it take?
Cost and timing depend on modules, workflows, locations, user roles, reports, integrations, data migration, training, security and rollout needs. A reliable estimate requires process discovery and a phased implementation plan.
What support is needed after ERP launch?
An operational system needs clear ownership after launch. Agreed support may include monitoring, issue handling, user administration guidance, updates, data or report review and a prioritized improvement backlog.
07 / Related services
ERP rarely stands alone.
Operational software may need a product interface, carefully governed external connections and dependable post-launch support.
Ready to untangle an operational workflow?