ERP / ENTERPRISE RESOURCE PLANNING
PROPELOO engineers custom ERP systems — from requirements engineering and domain modelling through module development, system integration, data migration and the change management that determines whether the platform is actually adopted. Off-the-shelf ERP is someone else's process model. When your operational processes are your competitive advantage, you need software engineered to match them.
The ERP implementation failure rate is notoriously high — Gartner estimates 75% of ERP projects fail to meet their original objectives. The primary causes are not technical: scope creep when business processes are re-discovered during implementation, data migration surprises when historical data does not fit the new data model, and user adoption failures when the system does not match how people actually work. PROPELOO starts every ERP engagement with process discovery — understanding how the business actually operates before designing the system that will support it. The data model is designed around the actual business entities, not a generic template. The interfaces are designed for the actual users, not for a persona in a vendor's sales deck.
A custom ERP is not one system — it is a set of integrated modules, each with its own domain complexity.
Double-entry general ledger, chart of accounts, cost centre accounting, accounts payable/receivable, bank reconciliation, multi-currency support, budget management and financial statement generation (P&L, balance sheet, cash flow).
Purchase requisition workflow, supplier management, purchase order generation, goods receipt, three-way matching (PO/GRN/Invoice), supplier performance and procurement analytics.
Multi-warehouse inventory tracking, FIFO/LIFO/weighted average costing, reorder point management, stock transfer between locations, batch/serial number tracking and inventory valuation.
Employee lifecycle management, organisational hierarchy, attendance and leave management, payroll calculation with statutory deductions, payslip generation and compliance reporting.
API integration with banking systems for payment processing, e-commerce platforms for order sync, CRM for customer data, tax software for compliance, and custom EDI for supplier/customer EDI workflows.
Configurable dashboards per role, standard financial and operational reports, ad-hoc query builder, scheduled report delivery and export to Excel/PDF for stakeholder reporting.
An ERP system encodes your business processes as software. If the processes are poorly understood before development begins, the software will encode the confusion.
The most common cause of ERP project failure is discovering the actual business process mid-implementation. We run structured process discovery workshops before writing a line of code — mapping every workflow, every exception case, every approval hierarchy and every data dependency. The process document becomes the specification. The specification becomes the test plan. Surprises in process discovery are cheap. Surprises in implementation are expensive.
Axiom:
Historical data in legacy systems is almost never clean enough to import without transformation. Supplier records have duplicates. Product codes have changed format three times. Financial data has gaps from system changes. Data migration requires: inventory of all source data, mapping to the new data model, transformation logic for every field, validation rules for acceptable data quality, and parallel-run verification that the migrated data produces correct reports. Underestimating data migration is the most common cause of ERP project overruns.
Axiom:
A big-bang ERP go-live — all modules simultaneously — maximises risk. Modular architecture enables phased implementation: financial management first (lowest operational risk), then procurement, then inventory, then HR. Each module goes live independently, users get familiar with one module before the next, and issues in one module do not delay the entire project.
Axiom:
An ERP system that users work around rather than with is a failed ERP. User adoption is influenced by the engineering choices: do the interfaces match the terminology users use? Are approval workflows the same number of clicks as the paper process they replace? Can users find their most-used functions without training? These questions should be answered by user testing prototypes before building — not by post-go-live training sessions.
Axiom:
These choices determine development timeline, integration complexity and long-term maintainability.
Impact: Custom build when your processes are genuinely differentiated and off-the-shelf would require compromising them. Open-source (Odoo) when standard processes apply and customisation budget is limited. Customising SAP/Oracle is often more expensive than custom build for mid-size companies.
Impact: API-first modular custom ERP for companies with complex, non-standard processes. Single integrated system for companies with standard processes who want simplicity. Best-of-breed only when specific domain requirements genuinely exceed what an integrated system can provide.
Impact: Design for your actual structure, not your current structure. Adding multi-entity capability to a single-entity ERP after data is in the system requires re-architecting the chart of accounts and all reports. If multi-entity is possible in the next 2 years, design for it on day one.
Impact: Configurable workflow engine is required for any ERP with procurement or HR approval flows — approval chains change regularly and should not require developer intervention. Temporal.io for complex long-running workflows (procurement that spans multiple days).
Impact: Embedded BI (Metabase) connected directly to the ERP database covers 80% of reporting requirements. A separate data warehouse is only justified when reporting load affects application performance or when complex cross-system reporting is required.
Impact: Parallel run for financial data — two months of parallel operation with reconciliation between systems before legacy shutdown. Fresh start with historical archive for non-financial modules where historical data has lower importance. Never big-bang a financial ERP without parallel run validation.
Bill of materials, production orders, shop floor management, material requirements planning, quality control and costing — integrated with financial management and procurement.
Multi-warehouse inventory, purchase order management, sales order processing, 3PL integration, route optimisation and customer delivery tracking.
Project management, time and expense tracking, resource utilisation, project P&L, client invoicing and revenue recognition for services businesses.
POS integration, multi-location inventory, purchase planning, supplier management, markdown optimisation and integrated financial reporting.
Patient billing, insurance claims management, medical supplies procurement, staff scheduling, compliance tracking and HIPAA-compliant data handling.
Custom module development for an existing ERP (SAP, Oracle, Odoo) — extending standard functionality for industry-specific requirements without replacing the core system.
Financial-grade backend with configurable workflow and embedded analytics.
Stack: Java Spring Boot, Node.js (TypeScript), PostgreSQL (primary), Redis (cache/sessions), Temporal (workflows)
Stack: React, Next.js, Ant Design / Mantine, React Query, TypeScript
Stack: Metabase (embedded BI), Apache Superset, Jasper Reports, Custom report builder
Stack: REST APIs, EDI (X12/EDIFACT), Zapier/Make connectors, SAP BAPI/RFC, Custom ETL pipeline
Stack: AWS (RDS + ECS), Terraform, GitHub Actions, Datadog, Automated backups
Stack: Python (pandas), dbt, Apache Airflow, Custom validation scripts, Parallel run tooling
Financial data, employee records and supplier relationships are high-value targets.
Every user accesses only the modules and data their role requires. Finance staff see financial modules. Warehouse staff see inventory. HR staff see employee data. No cross-module data leakage. Audit log of every data access for compliance.
Accounting entries are append-only — corrections via reversing journal entries, not data deletion. Ledger hash chaining for tamper detection. Segregation of duties enforced by the system — the person who creates a purchase order cannot also approve it.
All ERP APIs require authentication. Third-party integrations use service accounts with minimum required permissions. API access logging for all external integrations. Webhook signatures verified before processing.
Daily automated backups, point-in-time recovery, tested restore procedures. RTO and RPO defined per module — financial data has the most stringent requirements. Backup copies stored in a separate region from production.
Payroll and HR data protected with field-level encryption. Only HR and authorised managers can view salary information. Right to erasure workflow for GDPR compliance. Data retention policies enforced automatically.
Every financial transaction, every approval, every data change and every user action is logged with timestamp and actor. Audit logs are immutable and retained for the regulatory period (7 years for financial records in most jurisdictions).
Structured workshops to map all business processes, approval hierarchies, exception cases and data dependencies. Output: process document and entity model.
Module scope, data model, integration architecture, migration approach and phased delivery plan.
Core data model, user management, RBAC, audit trail and financial chart of accounts. All subsequent modules build on this.
Phased module delivery — financial management first, then procurement/inventory, then HR, then CRM.
Third-party system integrations — banking, e-commerce, tax, payroll — with reconciliation validation.
Data extraction, transformation, validation and parallel-run verification against legacy system.
Phased module go-live, user training, hypercare support period and legacy system decommission.
A custom ERP for a mid-size company (50-500 employees): 9-18 months. Finance module alone: 3-4 months. Adding procurement and inventory: another 3-4 months. HR and payroll: 3-4 months. The timeline is driven more by process discovery, data migration and user acceptance testing than by development speed. Budget for process discovery taking 4-6 weeks before development begins.
Odoo is a strong choice for companies with standard processes across standard modules (accounting, inventory, HR). It reduces initial build cost significantly for standard use cases. Custom build is justified when: your core processes are genuinely differentiated, Odoo customisation would exceed 60% of the build cost, or the Odoo data model does not fit your domain. SAP customisation is rarely cost-effective for companies under 1,000 employees — the customisation and licensing costs typically exceed a custom build.
Data migration has four phases: extract (pull data from legacy in a format we can work with), transform (map legacy fields to new data model, clean data, resolve duplicates, fill gaps), validate (run validation rules to confirm data quality meets acceptance thresholds), and load (import into ERP with verification checksums). We always run parallel operation for financial data — both systems live simultaneously for 1-2 months, with weekly reconciliation of ledger balances to confirm migration correctness before legacy shutdown.
Integration complexity varies: REST API integration (most modern systems) takes 1-2 weeks per integration. EDI integration (common for B2B supply chain) requires EDI translation layer and takes 3-6 weeks per trading partner. Legacy system integration (SOAP, flat file exchange) may require custom ETL pipeline. We document all integration points before development begins and include reconciliation validation — confirming that data transferred correctly — as part of every integration.