The business case for network monitoring and control

Build the case from your own numbers. Price the outages you had last year, count the tools and hours the new system replaces, and show how it scales and what happens if a server or the vendor fails. Then ask for a proof of concept with agreed success criteria, not for the whole budget at once.

Lead with the outages you have had

Leadership remembers the incidents that reached viewers, customers or regulators. Start there, with last year's list, before any feature or price.

For each incident, write down the facts you can stand behind. Estimates are fine if you say how you made them.

• How long the service was degraded or off air, and who noticed first: an alarm, a viewer, a customer or a regulator.
• What it cost: lost advertising or subscription revenue, make-goods, service level credits and penalties.
• Who was involved and for how long, including overtime and call-outs.
• Whether anyone had to travel to a site to find or fix the fault.
• How long it took to find the cause, separate from how long it took to fix it.

Count the tools and the time

A multi-vendor network usually has a management tool per vendor, plus spreadsheets and scripts that fill the gaps. Each one has a cost that rarely appears in one place.

• List every monitoring and element management tool in use, with its license, support contract and the server it runs on.
• Estimate the hours each week spent on routine checks, switching between screens and reports assembled by hand.
• Count the site visits made to check or reset equipment that could be reached remotely.
• Note the knowledge that lives with one person: the scripts only they understand and the panels only they can change.

Put it in the terms leadership uses

Group what changes under the five concerns a CEO or CFO raises, and give each one a number from your own operation where you can.

• Continuity: faults found and traced before they reach the audience, and what happens when a monitoring server fails.
• Efficiency: the routine work rules, scripts and schedules take over, and the hours that returns to the team.
• Scale: how sites and devices are added, and whether the license grows in steps you can plan for.
• Cost: the tools retired, the outage minutes avoided and the site visits saved, against the cost of the new system.
• Risk: where the data lives, who can change the system, and how access and changes are audited.

Answer the vendor question directly

A smaller specialist vendor often loses to a larger one on perceived risk rather than on the technology. Raise the question yourself, and answer it with facts you have checked.

• Where it runs: on your own servers, or as a service someone else operates.
• Who owns the data, and whether history is in a standard database you can query without the vendor.
• What your own engineers can change: drivers, panels, rules and scripts, without a support ticket.
• Which customers run it on networks like yours, and whether you can speak to one.
• What the support terms say, including hours, response times and how long a release is supported.

Prove it before you ask for the budget

A proof of concept turns the case from a promise into a result. Agree the scope and the success criteria with leadership first, so the decision afterward is a formality.

• Choose three to five failures from your incident list and replay them.
• Connect a slice of real equipment, including the oldest and most awkward devices.
• Write the pass marks down: time to detect, time to find the cause, alarms per incident, changes your team made without the vendor.
• Set a date to decide, and say who signs off.

The one-page summary

Most approvals are decided on one page. Keep the detail in an appendix.

• The problem, in one sentence, with last year's incident cost.
• What it costs today: tools, time and outages.
• The proposal: the system, the scope and the timeline.
• The expected change, in the five terms above.
• The risks and how the proof of concept addresses them.
• The decision you need and by when.

Common questions

How do I estimate the cost of an outage?

Multiply the minutes of degraded or lost service by what those minutes are worth: lost revenue, credits and penalties, plus the staff time spent on the incident. Use real incidents from the last year, and show how you made each estimate.

Should I use the vendor's figures in the business case?

Use them as context, not as the case. Figures from your own incidents and tools carry more weight with leadership, and a proof of concept on your own equipment gives you results you have measured yourself.

How does Mosaic answer the vendor risk question?

Mosaic runs on your own Windows or Linux servers, keeps its history in a standard SQL database you own, and can be extended by your own engineers with drivers, panels, rules and scripts. You can test it on your own equipment with a proof of concept before you commit.