Transforming the OSS

 OSS/BSS Transformation  Comments Off on Transforming the OSS
Dec 112010

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.


 OSS/BSS Transformation  Comments Off on OSS/BSS Silos
Dec 112010

Silos are seperately deployed OSS/BSS functions that are duplicated by technological domains. In a service provider environment, we face several of them in the core and access areas. These are DSL, PSTN, ATM/FR, Packet Core, Circuit Core, Radio, NGN to name a few. These technologies are normally managed by different organizational units. And most of them utilize some kinds of OSS/BSS systems to survive. Some complex units utilize highly scaled OSS/BSS systems while others may be applying some FCAPS  on their EMS layer.

We should not introduce any more silos to our infrastructure. Rather, we should transform our ecosystem via simplifications and improved automations to reach reduced costs, reduced TTM and increased efficiency. Ok, but, why we have them? There are several reasons:

  • Lack of customer focus,
  • Lack of customer awareness,
  • Sales strategy

Lack of customer focus:

Historically, OSS systems were seen as operating costs and these costs were bundled into the pricing of the service. A service provider with a monopoly, rules the market prices. So, if you are selling fine with the current price without any problem, why care about the costs?

This thinking has changed with the regulations and increasing competition  in the market. In order to survive, the service provider can play with price, quality or service differentiation metrics. The easiest and (most of the times) the most effective one is the price. Pricing is a complex study but basically it has 2 basic elements: margin and costs. Service providers reduced their margins dramatically after the deregulations. Now it is time to reduce the costs and Service Providers are fully aware of that. So, the strategy should be the transformation and the OSS/BSS integrators/vendors should push that strategy.

Lack of customer awareness:

Most customers realize that they need a change but they don’t know how to proceed. Here, SIs and vendors step in to explain the customers best practices. SIs will need to invest in  “customer training” sessions. Most SIs do this regularly, however for me, they are targeting the wrong audience in the customer organization. Nowadays, we come across CIO’s who have financial background. This CIO would not be interested and find it very complex when he is involved in a next generation SQM meeting. The technical people will definitely be interested in a PoC of SQM but not in financial figures. SIs should formulate a strategy to push a concept to multiple levels of the customer organization with the right focus.

Sales Strategy:

Let me tell you a story about an SI company who were doing a transformation project for a Tier-1 customer. They had the full support of the customer executives. They were able to aggresively push the newest NGOSS concepts to the transformed infrastructure. It was a chalenging but smoothly running transformation project. During that time, another functional group in the customer organization decided to invest on a new technology. They issued an RFP for this and one section of the RFP was dedicated to the OSS/BSS systems that will manage this new line of business. The executives of this SI company decided to respond to this RFP. However, instead of offering integration options with the ongoing transformation project they offered new OSS/BSS licenses and services.  Where’s the strategy? Where are the “we care some much about you and we will move you to the next generation OSS” things? Obviously it is easier for a sales guy to offer a new silo. First, your interface within the organization is just one department. You do not need to visit the board of directors to justify your more flexibile and simple business process that will solve common problems. Second, there will be a resistance from that department that issued the RFP  because they would want to “own” these OSS systems. Third, the money will come soon and will be reflected as a bonus at the end of the year. However, if they’d somehow push the best practices option, obviously their footprint will increase in the customer environment that will lead to further winnings in the mid-term. Farmers earn more than hunters in this service business.

We should avoid silos but they will be around for some time. As an SI, we should be consistent in our transformation strategy. We should invest in the training of our customers to make them proactive and responsive. This way, both sides win and the customers can become our partners.