Custom enterprise software · 2010
Motorola repair factory: three systems, one barcode, 0.1-second approvals
Three cooperating systems for a global handset repair factory — FCS for repair flow, ERP NEW for batch-level inventory, eProcess for agent approvals on mobile — joined by barcode identity and interfaces instead of one database.
The situation
A handset repair factory is not one business, it is three that share a building. Repair engineering owns the process: which node a board is at, who worked on it, what was replaced, where the failure actually came from. The warehouse owns the inventory: parts arriving in batches, being issued against work orders, and being counted. The commercial side owns the agent network: authorised service agents submit requests, and someone has to approve them under rules that change far more often than anyone admits.
Motorola ran these as three systems with three owners. Our work was to build and integrate them: FCS for repair flow control, ERP NEW for factory inventory and materials, eProcess for agent certification and approval — the last one replacing an older workflow product. The factory’s repair network is distributed, so materials and repair dispatch had to work across sites, not just at one bench.
The call we made
The tempting architecture was a single integrated suite: one database, one login, one model of the world. We argued against it, and that is the judgement this project rests on.
The three questions change at different speeds. Approval rules — agent classes, regions, thresholds, forms — change monthly and are owned by the commercial team. Inventory must not be restructured during a stock window; its schema is stable and its processes are audited. Repair workflow nodes change whenever process engineering changes the line. Put them in one schema with one release train and the fastest-changing requirement sets the pace for the two that should barely move. Three systems with explicit interfaces let each owner change their own thing on their own schedule, which for a factory network is the whole point.
So the integration had to carry identity, not data volume. Barcode is the join: board label, back label, box label all encode the same unit, and the same code is scanned at receiving, at parts issue, at repair, at QC and at packing. On top of that, interfaces synchronise IMEI, warranty and ERP data in both directions, with one permission model and one set of master data shared across the three systems. Nothing has to be re-keyed, and no system holds a private opinion about what a unit is.
Two smaller calls followed.
First, when eProcess replaced the old workflow tool, we moved approval authority process by process rather than running both systems in parallel for a quarter. Parallel running feels safe and is how approval migrations stall: two queues, two truths, and approvers quietly working out of one of them. A process moved when its rules were configured and its historical records were readable, and then the old path was closed.
Second, the 0.1-second approval response is not a general page-speed claim. An approver on a phone has exactly one job: see what is waiting and decide. So the pending-task read was built as a single pre-joined list per approver rather than as a filtered query over all tasks. That is a narrow optimisation, deliberately narrow — the rest of the UI did not get the same treatment, and did not need it.
What we built
FCS — repair flow control. Work order creation, dispatch, movement and archiving; configurable workflow nodes with automatic hand-off between process steps; technician performance statistics; barcode printing including back and box labels; parts attrition analysis broken down to component level; multi-condition queries and report export. The point of the node-level control is that a board’s position on the line is a recorded state, not a verbal one, and an omission shows up as a stuck board rather than as a lost week.
ERP NEW — factory inventory. Receiving by batch and physical content; repair dispatch and return registration; online material requests with approval; bulk upload of new-parts purchase data to replace manual entry; pick-list detail reports that can be exported and printed; interfaces to the barcode and ERP systems. Batch-level granularity is what makes the stock count survivable across multiple sites.
eProcess — agent certification and approval. Graphical approval-flow design and configurable forms, so the commercial team can restructure a process without a release; email and SMS reminders on two channels; mobile approval and reporting; agent classification and region management; turnaround time and pass-rate analysis. Both channels matter because an approval that waits for someone to open a laptop is an approval that waits until Monday.
The end-to-end chain runs receive and inbound, work order, parts issue, repair, QC, packing and despatch, agent settlement — with the barcode making sure data does not stop at a department boundary.
Result
FCS gave the factory node-level control of the repair process, and its component-level attrition analysis is what lets engineering locate the parts that are actually failing rather than the ones people suspect — the lever for reducing Failure Back. ERP NEW carries materials across the distributed repair network with batch-level stock and upload instead of keying. eProcess replaced the old workflow system with a mobile-capable approval chain that responds in the 0.1-second range for a pending task, and produces turnaround and pass-rate data instead of an anecdote about how long approvals take.
The structure has held because it matches how the business is actually owned. Three systems, one identity, interfaces in both directions, and no single release train that everything has to wait for.
Technology
| Stack | B/S web application · Mobile web approval · Barcode label printing (board / back / box) · REST and SOAP system interfaces · Email and SMS reminder gateway · Oracle |
|---|---|
| Delivery model | Private deployment, B/S plus mobile, three integrated systems |
| Client | Motorola — repair factory and authorised agent network |
| Status | Delivered |
What we cannot show
Agent identities, commercial terms, per-site volumes and failure data are withheld. Screens show configured example flows and redacted queues, not live production records.
Similar problem?
If this looks like something you are dealing with — a legacy system that must keep running, a workflow no product covers, an integration nobody wants to touch — send a short description. We will tell you honestly whether we are the right team, and what the first two weeks would look like.