The solutions and boxes you sell to service providers are the absolute best, right?. It’s the best cost-per-port, fastest, densest, most feature-rich, extensible, non-forklift upgradable, plug-and-play communications gear on the planet, right?
Good…now prove it!
I’m not talking about demonstrating how well the equipment performs in the network or even putting it through a series of tests that aren’t realistic (but prove every corner-case and keep engineers employed). Any solution offered must not only perform well but also prove how well it has performed by reporting, in real-time, the overall health of the network.
Carriers have been offering “Service Level Agreements” (SLA for short) for a number of years. When SLAs were first offered they were worded in a way that made difficult any attempt to prove sub-par service by the Service Provider. With fierce competition for enterprise business they have evolved. SLAs now have “teeth” in the form of substancial financial penalties for under-performance.
This financial risk has forced carriers to adopt a new factor in deciding which equipment they install in their network. That factor is the ability to report events that affect the overall health of the network. The reports must be in a protocol that is compatible with the OSS/BSS systems the carrier has chosen. That last bit is key; “compatible with the OSS/BSS systems”.
SLAs now have “teeth” in the form of substantial financial penalties
The trend in European Carriers is to implement a new functional group within the OSS/BSS department that is focused solely on SLA reporting. Carriers and Service Providers not only have to provide exceptional service to their enterprise customers (bound by SLAs) but they also have to prove it. This proof comes from the reports generated by network elements, correlated with reports from other network elements and then rationalized against metrics set by carriers’ business processes. Reporting the performance of the network is the primary function of this new group. Now it’s the carriers turn to prove it!
For network equipment providers this impacts how carriers are engaged and with whom they cultivate relationships. OSS/BSS now have more influence over which gear is chosen for the network and represent a new set of gatekeepers whose function must be respected by vendors. As one Director of a major European Telecommunications company said to me a few days ago,
“We have become an OSS/BSS company that happens to have 1000’s of kilometers of fiber in the ground”
As I’m writing this I can imagine how vendors would argue my point earlier about OSS/BSS reporting compatibility. One argument would center on standardization and how it obviates the need to care about compatibility. Unfortunately standardization isn’t always adopted in complex systems.
Another argument would take the opposite tact and place all the value in an integrated solution. Integration into OSS/BSS systems, with an incompatible protocol, requires an enormous amount of man-hours at a commensurate cost. This approach has another, more serious, impact on a product’s time to market. If the carrier is busy integrating the product into the network, they’re not selling any services based on it.
In my experience, there are two ways around this issue;
First, become the vendor that dictates, through incumbency, how the reporting/management interfaces work with the OSS/BSS systems. Here is where Alcatel-Lucent has done a fantastic job with their SAM Network Management Product (although it is long in the tooth and running out of steam)
Second, lessen the pain and therefore the barrier to entry of your product. Offer to pay for the integration from a third party or install engineers at no cost to accelerate the integration. In other words “Put up or shut up”.
{ 1 trackback }
{ 0 comments… add one now }