Stop the Archaeological Dig: Bringing Your OSS Dinosaur Back to Life

Are you worried that your OSS/BSS stack, or parts of it, might be in desperate need of an overhaul?

Many OSS experts love being archaeologists, down on their knees, carefully brushing off the dust to unearth their OSS fossil and painstakingly preserving it. But modern network operations aren’t archaeological digs. We can’t just make educated guesses from bone fragments and the wise insights of our best historians.

We need to make immediate decisions based on observable insights from the living, breathing beast that is the modern telco.

Today we’ll go through the steps of:

1. Assess: Assessing the “age” of your OSS (from prehistoric to alive)
2. Justify: Building the case with justification for modernising
3. Re-Animate: How to plot a path to bringing your OSS alive again

.

Where does your OSS rank – Prehistoric to Alive?

You don’t need complex maths to know when your OSS has crossed the tipping point and is desperately needing modernisation. You can use simple, repeatable indicators that anyone can verify, such as:

1. False alarms and blind spots: Are operators swamped by noisy alerts while real faults slip through? Consistent false-positives/negatives signal model and telemetry failures

2. Topology / Resources drift: Do live routes/paths or assigned resources differ from what inventory says? Repeated mismatches mean your “source of truth” isn’t (a source of truth)

3. Order fall-out rate: What % of standard orders fail and need manual rescue? A rate of >5% and/or rising fall-out is a canary for broken data, integrations, exception handling and rules

4. Shadow spreadsheets: If teams keep their own lists or sidebar workflows to get work done, the OSS has lost credibility. Not only that, but it’s effectively an offline data store, which is an early red flag that your data is likely to get into a death spiral
5. Swivel-chair steps: How many screens or systems must an operator touch to complete a task? If it’s 3+ for routine work, UX/CX / integration debt is high

6. Duplicate tools: Are multiple teams using different tools for the same job? Tool sprawl fragments data and process consistency

7. Backlog age: How long do “simple” fixes sit in the queue? If small hygiene items age out, the platform is resisting change (or overwhelmed by it!)

8. Reconciliation misses: How often do inventory-to-network or billing-to-inventory reconciliations over-run, fail or get skipped? Misses compound into costly errors.
9. Key-person risk: Does one person taking a holiday stall essential OSS tasks and projects? If yes, key knowledge lives in heads, not systems

10. Unsupported versions: How many core components are out of vendor support or running at n-2 from the current versions? Security and upgrade paths are closing in on you and the eventual uplift project is getting more expensive with each skipped release

11. Change lead time: How long is the time from request to deployed OSS change (especially for a small rule or mapping)? Weeks for a one-liner screams frailty and/or problems with your change management process

12. Environment drift: Do dev/test/stage behave differently from prod? If parity is poor, quality and speed both fall

13. Thick clients: If your solutions are still using a thick-client architecture, then this is the first sign that you’re using prehistoric tools. Not only that, but your maintenance and operations efficiency is impacted

Rule-of-thumb: if more than two or three of these indicators are red, you are paying an archaeology tax every day. That is your signal to act, not to schedule another patch (a patch that doesn’t get approved by change management for another 6 weeks from now).

.

Justifying the modernisation investment – From Fossil to Flight

Executives do not fund technology refresh for its own sake. They fund outcomes they can measure.

This is something we consistently fail at as an industry. It’s too easy to just pass off the benefits as intangible, leaving un-fundable business cases.

That’s not good enough. We have to find ways to translate pain into plain dollars. The following is just the tip of the iceberg to give you a few ideas to help you turn intangibles into monetary values to justify your next OSS/BSS modernisation project:

1. Rules of thumb: We use an excuse of “perfection” as a procrastination mechanism. Sometimes we just need to use rough rules of thumb to get a feel for the size of a problem
2. People time: Add weekly hours spent hunting data, reconciling sources and reworking tickets. Multiply by a standard rate to get $ per week
3. Data Integrity Cost Contagion: Download our Data Quality Contagion Cost Calculator [DQCCC] here
4. Fix-on-First or First-time-right rate: Each failed fulfilment adds a second truck roll or engineer shift. $ per month = number of repeat visits x avg visit cost
5. Revenue Delay: $ per month = blocked orders × avg margin/order
6. Inventory inaccuracy: Ghost assets, duplicate licences, lost spares. $ per quarter = write-offs + unnecessary purchases avoided if accuracy ?95% (I admit that this one is tricky to measure because you don’t know what you don’t know. Who you gonna call? Ghostbusters!)
7. Check out our OSS Business Case Builder for more examples

To make a compelling case, you will probably map out at least two options to compare:

• Current State: patch and cope (and hope!) vs
• Desired Future State: modernise

.

Planning the re-animation (using WBS)

When planning to bring an OSS dinosaur back to life, there are many steps and equally many dependencies. We always generate a Work Breakdown Structure, as described in the Ultimate Framework for Planning Large-Scale OSS Transformations article.

.

Keep it breathing

Modernisation is complete only when the old habits are gone, not simply when the new platform is live.

People don’t like change, so you may even need to put guardrails in place to prevent a slide back into archaeology.

When your best people are behaving more like archaeologists than OSS operators, you are already paying for it in rework, slow fixes, data quality contagion and missed insight. Use simple indicators to call the tipping point, justify the shift in $, and let WBS plan the re-animation. Replace dust and guesses with live truth – and bring your OSS back to life again.