Products and services that are sold by the service providers use multiple technologies that are implemented by multiple vendors. These vendors deployed their NEs into the provider’s network infrastructure. Each vendor also deployed an EMS system which is capable to manage their (and only their) NEs. These EMS systems are very welcomed by the providers as these systems enabled them to run the FCAPS functions for the multiple devices.
As the demand grows, providers needed to scale their infrastructures. To do this, they expanded their NE sets. In the mean time, the technologies were also standardized. An SDH technology, for example, can run on multiple brand SDH nodes to deliver an e2e VC12 circuit. This interoperability, gave the change to operators introduce multiple vendors/brands into their infrastructure. The drivers of this were lower costs and reduced vendor dependencies.
Each new vendor’s equipment brought another EMS to the network and the EMS layer started growing. In the mean time, new technologies emerged. The operators needed to deliver these technologies very quickly. And if this technology is a completely new technology that cannot be delivered on the current NEs, new NEs and EMS systems are introduced again. To cope with this growth, network management layer grew on the top of the EMS layer, providing the same FCAPS functionality but in a more consolidated way. We deployed fault managers, performance managers, configuration managers and inventory managers to the NMS layer.
The OSS investments are triggered by functional department needs. For example, the transport division who is responsible for the SDH/PDH systems had their own NEs, EMS and NMS systems. They had Fault Managers, Performance Managers etc. that are managed by them. (Or sometimes these are given free by the NE vendors during the deployment time and nobody is using them). The access network division also did the same thing.
This caused the silos to appear within the infrastructure. Silos had a problem. You were not able to see your end to end infrastructure view easily. Suppose, there is an SDH problem appeared in the network. SDH devices would send alarms to their EMS systems and those would report them to their NMS systems. Because of this L1 problem, ATM VCs would be impacted and the same alarm propagation would again happen on the ATM side. ATM DSLAM, which sensed that uplink failure, would also start complaining. Since there is no end to end visibility of given services, every division would send the responsibility to the other. This would increase the problem-to-resolution process times. Some operators invested on manager of manager systems to cope with this problem. However, for me, this is another cost (both operational and capital) to the operator which needs to be eliminated.
Silos bring inefficiency, increase capital and operational expenses. However, during the golden ages of telecommunications, where there were very high margins, upper management did not care at all the operations burden that is growing at the bottom. At last there are just 10 more salaries to pay.
Today’s conditions are different. Technology costs decreased and new players came to the market. Regulatory bodies started monitoring unfair activities that are against the competition which are leading to monopolies.
As the competition increased, the margins started to fall. In order to make more revenues or just keep the current revenues stable, operators started to create new product offerings. Only voice and data were not bringing the enough value. And there came the value added services concept. SMS, MMS, Mobile TV are such kind of services the operators began to offer.
Other ways to survive in this arena was to lower the costs (OPEX and CAPEX) and to improve customer satisfaction.
The transformation concept is introduced at this point. We now have the best practices frameworks to tell us how we should build and run our OSS/BSS infrastructure. We have past experiences. We should utilize those to transform the way we operate.
Transformation projects (OSS or BSS) start with a as-is analysis of the current infrastructure. In this analysis, we identify all the business processes, systems and people who run those processes. We also construct a to-be analysis that is driven by the best practices (such as NGOSS etc.). We then try to transform our infrastructure from as-is to to-be in a transformation program. During this study, we will possibly find duplicate processes and systems. We will also see some business process gaps that need to be implemented for efficiency. (SQM and SLA management processes are most likely to be introduced). Consolidation will be necessary in most areas.
Transformation programs are hard to implement. They are spread across multiple functional organizational groups. They need to have CxO level commitment and the most important fact is they should be continuous.