Choose "Save as PDF" in your browser's print dialog.
ERP Consolidation and Operations Platform for a 28-Branch Retail Chain
Replaced disconnected branch spreadsheets, legacy POS workflows, and fragmented approval chains with a centralized event-driven operations platform architected to support controlled expansion to 75 branches.
ONGOING · 6 ENGINEERS · ERP + OPERATIONS PLATFORM
§01 / THE BRIEF
A retail chain operating 28 semi-autonomous branches was running billing, inventory, procurement, and vendor management across a combination of spreadsheets, WhatsApp approvals, and a vendor ERP whose per-branch licensing costs were scaling aggressively toward the expansion target. Headquarters had no real-time inventory visibility, approval chains were informal and unaudited, and monthly reconciliation consumed up to five business days of manual effort. The business needed a purpose-built platform that could standardize branch workflows, enforce procurement governance structurally, and sustain offline branch operations without data loss — before attempting to scale to 75 locations.
§02 / SYSTEM ARCHITECTURE
Event-driven, offline-first platform spanning branch service nodes, a central Kafka event bus, operational and analytical storage layers, and multi-surface client interfaces.
§03 / THE WORK
- 01
Operational Workflow Mapping
Spent three weeks across branch locations and headquarters documenting actual workflows as-executed rather than as-documented. Procurement approvals in practice collapsed a three-tier chain into a single WhatsApp message; inter-branch transfers had no in-transit state; inventory adjustments were applied directly without reason codes or approver attribution. The platform was designed around the real workflow distribution, not the intended one.
- 02
Event-Driven Inventory Ledger
Built inventory as an append-only event stream rather than a mutable stock record. Every receipt, adjustment, transfer, and sales deduction is an immutable event. Current position is derived by projection, meaning any past inventory state can be reconstructed for audit or investigation without relying on manually maintained logs — eliminating the class of 'unexplained variance' that previously consumed reconciliation cycles.
- 03
Procurement and Approval Workflow Engine
Modelled approval chains as configurable state machines with role-bound transitions and value-tier thresholds. Approval bypass is structurally prevented at the API layer — a purchase order cannot be transmitted to a vendor until all required approvals are recorded. Escalation triggers automatically when an approval stage exceeds its configured deadline, routing to the next authority tier without requiring manual follow-up.
- 04
Offline-First Branch Operations
Each branch runs a local service layer maintaining a branch-scoped cache and a persistent local event queue. Operations continue normally during connectivity disruptions. On reconnection, the queue drains to the central broker with idempotent delivery, and conflict resolution follows deterministic per-entity merge strategies rather than last-write-wins. Branch staff experience no operational change during network outages.
- 05
Centralized Reporting and Reconciliation Layer
The reporting layer is physically separated from the transactional path, fed by projection workers consuming the event stream into a ClickHouse analytical store. Background reconciliation workers run continuously — comparing projected inventory against physical counts, matching POs to delivery notes, and tracking in-transit transfers beyond expected windows — surfacing exceptions for review rather than waiting for monthly discovery.
- 06
Branch Onboarding and Migration Tooling
Built a structured branch activation workflow covering data migration from legacy spreadsheets, staff account provisioning, device enrollment, and a parallel-run validation period. Automated reconciliation checks compare the legacy source against new platform state before cut-over is approved. This workflow reduced new branch activation from four to eight weeks of manual setup to a target of five days.
§04 / RESULTS
Figures marked "target" are engagement objectives. Results marked "enforced" reflect architectural constraints rather than behavioural targets.
- MANUAL RECONCILIATION EFFORT, MONTHLY
- −80% (target)
- PROCUREMENT APPROVAL BYPASS RATE
- →0 (enforced)
- NETWORK INVENTORY DATA FRESHNESS
- 7 days→<5 seconds
- NEW BRANCH ACTIVATION WINDOW
- 4–8 weeks→5 days (target)
- SPREADSHEETS RETIRED ACROSS BRANCHES
- 28+
- ERP LICENSING COST AT 75-BRANCH SCALE
- Eliminated (vendor dependency removed)
§05 / CONTEXT
- 01
Fragmented Operational Baseline
Each of the 28 branches operated as a semi-autonomous unit with its own spreadsheet setup, local stock tracking, and ad-hoc vendor relationships. There was no standard process for inventory adjustments, inter-branch transfers, or purchase approvals — each branch manager had evolved their own workflow over years of operation. 'How things were done' was held entirely in individual institutional knowledge rather than system state.
- 02
Approval Chains in Name Only
The documented procurement policy described a three-tier approval hierarchy. In practice, this had collapsed into a single WhatsApp message to a senior manager who would reply with a thumbs-up. There were no audit trails, no value-tier thresholds, and no escalation paths. High-value orders and routine consumable restocks went through identical informal processes — creating equal risk exposure for vastly different transaction categories.
- 03
Mounting Reconciliation Burden
Monthly inventory reconciliation was consuming four to five business days of combined effort from branch managers, warehouse staff, and the central finance team. The process involved manually cross-referencing branch spreadsheets against purchase receipts, delivery notes, and POS logs. Discrepancies were common and often unresolvable because the data trail to identify the source of a variance simply didn't exist.
- 04
ERP Licensing Cost Trajectory
The incumbent vendor ERP charged per-branch licensing fees. At 28 branches the cost was manageable; at the planned 75-branch expansion target the licensing trajectory made the vendor ERP economically unviable. The business needed to replace the ERP before beginning the next expansion phase — not during it.
§06 / ARCHITECTURAL DECISIONS
- 01
Why Kafka for the Event Bus
Apache Kafka was selected to decouple operational workflows from analytical processing and to support replayable inventory events. Kafka's durable log enables the system to replay inventory projections from any point in time — critical for audit scenarios and for bootstrapping new analytical workloads against historical data. The decoupling also means that reporting pipeline disruptions cannot affect transactional processing, and vice versa.
- 02
Why Event Sourcing for Inventory
Inventory was modelled as an event stream because the fundamental requirement was auditability, not just current stock position. A mutable record can tell you what inventory is; an event log tells you why it is that way, who changed it, when each movement occurred, and what the state was at any historical point. This directly eliminated the class of unresolvable variance that was consuming reconciliation cycles.
- 03
Why Offline-First Architecture
Several branch locations experienced intermittent connectivity disruptions during peak trading hours. Designing for online-first with offline fallback would have meant staff encountering application errors during network instability — exactly the conditions under which operational pressure is highest. Offline-first inverts the assumption: the branch operates normally always, and synchronization is an asynchronous background concern.
- 04
Why Projection Workers Over Direct Queries
Separating the analytical store from the transactional store via projection workers means complex reporting queries run against a purpose-built ClickHouse store without contending with transactional write load on PostgreSQL. The analytical schema can evolve independently of the operational schema, and reports can be rebuilt from scratch by replaying the event stream.
- 05
Why Configurable State Machines for Approvals
Hard-coding approval chains would have required engineering changes for every policy update. Configurable state machines allow the operations team to adjust value-tier thresholds, add approval stages for specific procurement categories, or change role assignments without a deployment cycle. The state machine configuration is versioned, so historical approval decisions can always be validated against the policy active at the time.
§07 / MILESTONES
Phase 1 — Discovery & Architecture
Weeks 1–6- ·Embedded three-week workflow documentation across branch locations and headquarters
- ·Mapped actual vs. documented approval chains and inventory adjustment patterns
- ·Defined event schema for inventory, procurement, and transfer domains
- ·Finalised technology selection and architecture design
- ·Established branch connectivity and infrastructure baseline
Phase 2 — Core Platform Build
Months 2–7- ·Event-driven inventory ledger with projection engine
- ·Procurement and approval state machine with configurable thresholds
- ·Branch local service layer with offline queue and idempotent sync
- ·Central Kafka broker cluster with consumer group isolation
- ·Core PostgreSQL schema and TypeScript service layer
Phase 3 — Reporting & Analytics
Months 7–11- ·ClickHouse analytical store and projection worker pipeline
- ·Background reconciliation workers for continuous exception detection
- ·Headquarters dashboard (Next.js) — network inventory, approval queues, vendor spend
- ·Branch operations UI (React Native) for stock receipt and transfer management
- ·Automated PO-to-delivery matching and in-transit transfer tracking
Phase 4 — Pilot and Migration
Months 11–15- ·Pilot deployment across five branches with parallel-run validation
- ·Branch activation tooling and spreadsheet migration workflows
- ·Staff onboarding and training program development
- ·Cut-over validation checks and rollback procedures
- ·Performance baseline and load profiling at pilot scale
Phase 5 — Full Rollout & Optimisation
Months 15–18- ·Staged rollout across remaining 23 branches
- ·Legacy ERP decommissioning for migrated branches
- ·Reconciliation worker tuning and exception threshold calibration
- ·New branch activation workflow validation to 5-day target
- ·Ongoing optimisation, observability, and expansion readiness review
§08 / IMPACT
- 01
Reconciliation Effort Reduced by 80%
Monthly inventory reconciliation previously required four to five business days of combined effort from branch managers, warehouse staff, and the central finance team. After centralized event projections and continuous reconciliation workers, the monthly close process targets an 80% reduction — from five days of manual cross-referencing to a review of system-surfaced exceptions that typically runs to a few hours.
- 02
Procurement Approval Bypass Reduced to Zero
Before the platform, informal approval bypass was effectively undetectable — a WhatsApp approval left no structured trail. After structural enforcement at the API layer, bypass is architecturally impossible. Every purchase order carries a complete, timestamped approval record. Audit queries that previously couldn't be answered at all can now be resolved in seconds.
- 03
Inventory Visibility from 7 Days to Under 5 Seconds
Headquarters previously relied on manually compiled weekly branch reports for inventory visibility. Network inventory position is now available in near real-time via the event projection pipeline — freshness of under five seconds for consolidated views, versus the previous seven-day reporting lag. This enables same-day inter-branch transfer decisions and vendor order timing that was previously impossible.
- 04
Branch Activation Compressed from Weeks to Days
Under the legacy setup, onboarding a new branch required four to eight weeks of manual account setup, spreadsheet configuration, and ERP provisioning via the vendor's support process. The new branch activation tooling targets a five-day activation window, including data migration validation, device enrollment, staff account provisioning, and parallel-run sign-off.
- 05
ERP Licensing Cost Eliminated at Scale
The per-branch licensing structure of the incumbent ERP made the cost trajectory to 75 branches economically unviable. The purpose-built platform eliminates variable per-branch licensing entirely. At the 75-branch target, the infrastructure cost of the new platform is significantly below what the vendor ERP licensing would have cost — creating a compounding cost advantage with every additional branch.
§09 / ARCHITECTURE DETAIL
- 01
Branch Service Layer (Local Node)
Each branch runs an isolated local service layer on an on-premises node maintaining a branch-scoped PostgreSQL instance for operational state, a Redis cache for hot-path lookups, and a persistent Kafka producer for event exchange with the central broker. The local service exposes the same API surface as the central platform, allowing branch staff to operate without awareness of the underlying connectivity state.
- 02
Central Event Broker — Apache Kafka
The Kafka cluster operates as the authoritative event backbone. All inventory movements, procurement state transitions, transfer confirmations, and approval events are written to topic-partitioned streams with full event history retained. Consumer groups are isolated per workload type — transactional processors, projection workers, and notification services consume independently without coupling.
- 03
Core ERP Services — TypeScript + PostgreSQL
The core service layer is a stateless TypeScript application backed by PostgreSQL implementing the domain logic for inventory management, procurement workflow, vendor management, and branch operations. Role enforcement and approval state transitions are validated at the service layer before persistence. The service layer consumes from Kafka for inbound events and publishes outbound events for downstream consumers.
- 04
Analytical Store — Python Workers + ClickHouse
Python-based projection workers consume the full event stream and maintain a ClickHouse analytical store optimized for aggregation queries. The projection workers are idempotent and can be rewound to rebuild the analytical store from any historical point. The reporting layer queries exclusively against ClickHouse, ensuring zero read contention with operational PostgreSQL instances.
- 05
Client Surfaces — Next.js + React Native
Headquarters and regional management use a Next.js web dashboard for network-wide visibility, approval management, and reconciliation exception review. Branch staff use a React Native application for day-to-day operations — receiving stock, recording adjustments, raising purchase requests, and confirming inter-branch transfers. Both surfaces share the same API contracts and operate against the local service layer at branch level.
§10/ SECURITY & GOVERNANCE
Role-Based Access Enforcement
Every API endpoint and state transition is gated by role-bound authorization. Branch staff, branch managers, regional managers, procurement officers, and headquarters administrators each operate within a strictly defined permission surface. Role assignments are managed centrally and propagate to branch nodes on next sync — there is no local role override capability.
Immutable Audit Trails
The event-sourced inventory and approval ledgers are append-only by design. No update or delete operation modifies historical event records. Every state change carries a timestamp, the authenticated user identity, the device identifier, and the branch context. Audit queries against the event log are deterministic and tamper-evident without requiring a separate audit logging system.
Signed and Encrypted Synchronization Events
Events produced by branch nodes to the central Kafka broker are signed with branch-scoped keys. The broker validates event signatures before accepting them into the authoritative stream. All inter-service traffic runs over TLS. Branch node credentials are enrolled during the branch activation process and can be revoked centrally without requiring physical access to branch hardware.
Structural Approval Enforcement
Approval governance is enforced at the API layer, not the UI layer. A purchase order state machine cannot transition to 'approved' without all required approval records being present and valid. There is no administrative override path that bypasses the approval state machine — policy exceptions are themselves logged approval events rather than silent bypasses.
§11 / SCALE READINESS
DESIGNED FOR
75+ Branches Without Core Redesign
The platform was architected from day one to support controlled expansion toward 75+ branches without requiring core workflow redesign. New branches are enrolled as isolated service nodes that participate in the existing event topology — no schema changes, no new consumer groups, no manual Kafka topic provisioning. Branch activation is automated through the onboarding tooling, targeting a five-day window from approval to live operations. The Kafka-based event backbone scales horizontally by partition; the ClickHouse analytical store scales independently of the operational PostgreSQL layer; and the stateless TypeScript service tier scales by replica count. The architecture does not contain branch-count-sensitive bottlenecks at any layer.
§12 / LESSONS
- 01
Design for the Real Workflow, Not the Documented One
The three-week discovery phase revealed that actual operating patterns were substantially different from the procedures described in policy documents. Designing the system around documented workflows would have created a platform that staff worked around rather than with. Discovering real patterns first — including which shortcuts were legitimate adaptations and which were compliance gaps — resulted in a system that met staff where they were while enforcing the governance that genuinely mattered.
- 02
Structural Enforcement Outperforms Policy Enforcement
The approval bypass problem wasn't solved by training or by policy reminders — it was solved by making bypass architecturally impossible at the API layer. Systems that rely on human compliance with policy rules will always experience drift. Systems that make non-compliant paths unavailable don't need monitoring for that drift.
- 03
Offline-First Is a Feature, Not a Compromise
Designing for offline operation was initially framed as a fallback for unreliable connectivity. In practice it became a key staff adoption driver — the platform works the same way regardless of connectivity state, removing the anxiety of knowing that a network disruption during a busy trading period means operational downtime.
- 04
Continuous Reconciliation Changes the Discovery Model
Monthly reconciliation finds variances after they've had weeks to compound and obscure their origins. Continuous background reconciliation surfaces exceptions within hours of occurrence, when the data trail is still fresh and the people involved can recall the context. This fundamentally changes resolution from forensic archaeology to operational exception management.
§13/ TEAM & STACK
TEAM
| ROLE | COUNT |
|---|---|
| Platform Architect | ×1 |
| Backend Engineers | ×3 |
| Frontend Engineer | ×1 |
| Implementation Lead | ×1 |
| Duration | 18 MONTHS |
STACK
- TYPESCRIPT
- POSTGRESQL
- APACHE KAFKA
- REDIS
- NEXT.JS
- REACT NATIVE
- PYTHON
- CLICKHOUSE
Have a brief that looks like this?
LOGISTICS & FLEET OPERATIONS
Fleet dispatch and depot operations platform for a 19-depot logistics network
Proposed replacement of per-depot dispatch spreadsheets, WhatsApp-coordinated driver assignments, and disconnected route tracking with a centralized event-driven fleet operations platform architected to support expansion to 50 depots without compounding dispatch failures or load visibility gaps.
FIELD SERVICE & FACILITIES MANAGEMENT
Work order and field service operations platform for a 23-region facilities management network
Proposed replacement of region-level work order spreadsheets, phone-coordinated technician dispatch, and paper-based SLA tracking with a centralized event-driven field service platform architected to support expansion to 60 regions without compounding SLA breach exposure or asset maintenance visibility gaps.