ERP in BRIEF
ERP, BSS, OSS — what they are, why they matter
If you’re integrating platforms, migrating data, or trying to explain “how the business actually works” to a mixed audience, these three terms show up everywhere. This page gives you the practical meaning — not the brochure version.
ERP
The enterprise backbone: finance, HR, procurement, supply chain. It’s where the organisation keeps its official version of money, people, and governance.
Jump to ERP detail →BSS
The customer & revenue engine (common in telecoms and service businesses): products, orders, billing, CRM — the things that turn services into cash.
Jump to BSS detail →OSS
The operational plumbing: provisioning, service assurance, fault & performance management, network/service inventory — the stuff that keeps the lights on.
Jump to OSS detail →Why this matters (in the real world)
- Most integration pain comes from different “truths” living in different systems.
- Migration programmes fail when teams treat platforms as boxes, not as historical decisions made concrete.
- If you don’t know what the system was built to optimise, you’ll build the wrong interfaces and the wrong reports.
One diagram: how ERP, BSS and OSS fit together
Reading it top to bottom: OSS runs the services, BSS sells and charges for them, ERP governs and accounts for the organisation as a whole. Integration works when each layer owns its truth — and shares it deliberately.
ERP detail — enterprise backbone
ERP is designed to run the organisation’s core machinery: money, people, procurement, assets, inventory, governance. It tends to be strict, controlled, and audit-friendly — which is exactly why it often feels “hard work” to integrate with.
- Strength: consistent financial and operational truth, controls, compliance.
- Common pitfall: teams treat ERP like a reporting database (and then wonder why it’s painful).
- Good integration pattern: event/outbound feeds for operational data, governed master data in.
BSS detail — customer & revenue engine
BSS is where services become products and products become revenue. It typically covers product catalogue, quoting, ordering, billing/charging, customer management, and sales/service workflows.
- Strength: customer lifecycle and monetisation.
- Common pitfall: messy product definitions and inconsistent order states across channels.
- Good integration pattern: orchestrated order-to-activate flows, clear status models.
OSS detail — operations & assurance
OSS is the operational side: provisioning, network/service inventory, fault management, performance monitoring, service assurance. It’s typically event-heavy and operationally sensitive.
- Strength: keeping services running and observable.
- Common pitfall: inventory drift (systems disagreeing about what’s actually live).
- Good integration pattern: strong identifiers + reconciliation loops, not “one-off” loads.
Integration lens — how they should talk
A useful rule of thumb: BSS drives “sell and charge”, OSS drives “deliver and assure”, ERP drives “govern and account”. Integration works when you define which system owns which truth — and then you protect that ownership with interfaces.
- Be explicit about system of record per data domain (customer, product, asset, invoice, payment).
- Prefer events + reconciliation for operational truth, not just batch copying.
- Design for failure and replay (idempotency beats heroics).
Data lens — “system of record” without the nonsense
“System of record” isn’t a slogan. It’s a commitment: what gets mastered here, what gets referenced elsewhere, and what gets reconciled when reality diverges. The quickest way to pain is letting three platforms each become “the master” by accident.
- Define identifiers early (customer, service, asset, order) and keep them stable.
- Separate operational reporting from governed analytical reporting (OLTP vs OLAP).
- Make reconciliation a first-class citizen, not an afterthought.