The dependency of one supplier…

Traditionally, operators have built the solutions needed to manage their networks themselves. Usually ad hoc and with focus on “solving the present problem” rather than fulfilling requirements for long term functionality or documentation, or considering future cost structure. The result is that the networks are not fully transparent and a dependency on a particular hardware provider is often created because of reluctance to bring in new vendors due to fear of negative consequences. A cumbersome approach that nevertheless has worked so far.

However, the maintenance of this hard-coded environment tends to be very time consuming and costly, as any changes in e.g. hardware, service portfolio or integration with other systems becomes more complex over time. System changes also become dependent on specific individuals meaning that operators become more vulnerable.

To change this way of working through harmonization and automation of the network via a third-party software, would be an effective solution. But, the realization of this has often failed due to two persistent myths:

Costs – On paper it looks more expensive for operators to take this step than to continue as before, as the costs for the already employed dedicated staff are rarely included in the calculation. Also the inefficiency of the current solutions affect many parts of the organizations and not only the teams responsible for the network management. These costs are usually not considered either.

Dependency – It is understandable that operators can see a potential problem in replacing one dependency (hardware) with another (software).

But myths aside, the arguments for network automation are several:

  • The value of harmonizing. In manually controlled environments, the knowledge of the network details decrease over time and is also usually distributed among several people and systems. The network harmonization allows you to abstract and simplify, enabling full control and overview of the network, including capacity and resources you have available.
  • Business development. By automating routine tasks the dedicated staff can be released for business development rather than working with pure maintenance. So the effect is two-fold: Cutting operational costs means releasing the innovative power of the organization.
  • Greater negotiating power. Network harmonization reduces the dependency of a particular hardware supplier. For an operator this means greater negotiating power in procurement. Also internal processes do not need to be based on a particular hardware type, but can easily be adjusted as the requirements change.
  • Simplified roles at the operator. In the hard-coded environment, product management is often a kind of a “hostage” in the organization. They are expected to solve what sales promised to customers, but are limited to what Network Operations can deliver, and even more so when the network is poorly documented. The time is ticking at all organizational levels.
  • Customer Service. How do you value good customer service and customer satisfaction? What is it worth to be able to promise customers delivery of new services in minutes instead of days? You could think that harmonization is contradictory to flexibility. This is however not a correct assumption. Instead it enables a fast and flexible environment for delivering new services.

 

So, with a third-party software, such as BECS, there will be structure, flexibility and capability to introduce new services faster. To take the steps needed in order to achieve these benefits may seem overwhelming, not least in terms of practical procedures, but also through the barriers in the organization as third-party software will manage tasks that technicians so magically have solved earlier. And, not least, to take the step may also be hampered by a sort of catch-22 thinking – “We do not have time to look in to this at the moment because of the existing workload”.

However, the long term effects are far greater than the temporary increase in workload. And you do not need to do everything at once. In short this means that it is better to begin the harmonization now, if only by taking small steps at a time. With a harmonization already in progress, the implementation of SDN will be a lot easier.

And finally, the issue of dependency: We dare to claim that a third-party software is easy to replace compared to a manually managed network due to the full harmonization and documentation available, allowing an easy move to a new tool if the need should arise in the future.

Small steps – major progress

As we have seen in two previous blog posts it IS a prerequisite to automate the networks in order to enable innovative new offerings, business and services. Operators do have this insight, but as it often involves complex structures, all dependent on each other in various ways, the thought “should we do this? Can we do a total overhaul and go all-in in the process”, easily arises.

It is understandable that this creates a kind of paralysis, and a “wait-and-see” attitude easily wins. You know what you have, but not what you will get. The technicians, who are often busy keeping the networks up and running, raise their concerns and stall the process. Usually as a self-protective measure, but not seldom because they want to maintain their position as “the Masters of the Network”. Consequently the whole process easily comes to a halt.

However, we believe that the risk does not lie in the automation of the networks. The greatest risk is instead to continue to maintain time-consuming manual processes and allow competitors to get ahead with greatly improved profitability and innovation power as a result.

The key is to take into account the concerns that major changes raises and take small steps in the right direction instead of thinking massive overhaul projects. It is both possible and so much better to start “somewhere” than “nowhere”. But where to start then?

Step one is to start automating a small manual task in the chain of processes in a network. Such a task could be:

  • A specific service, for example a corporate or private client service
  • A part of the network, such as a geographic area
  • A specific network layer, such as MPLS nodes, access switches or end-user equipment
  • A specific function, such as the rollout of new hardware

Or perhaps a combination of several of these tasks: e.g. Automation of the access switch configuration for end-users in a particular city.

By working in a small scale initially and assisted by a solution that supports this approach, one can achieve a process where the steps with the greatest benefits and lowest complexity are automated first.

An incremental automation enables a network built on modularity, where the implementation of new services can be achieved much faster and more efficient. This facilitates for the marketing and sales department to come up with ideas for new services, which can quickly be realized by the technicians.

We believe that the technicians should minimize the time they spend on routine tasks. They should instead use their technical skills to defining the standardized components, which the sales organization can use to build their offerings upon. On top of that an automated network provides an opportunity to test new services ad-hoc to see which ones are appreciated by the end-customers.

Furthermore, the technicians can use their time to develop the network for the future – including quality, capacity, robustness needs, i.e. aspects that have an actual effect on the perceived quality by the end customers. And thus directly impact customer satisfaction and the ability to earn money on the networks.

Cutting costs and increasing productivity in the telecommunications industry are all about the same things as in other industries, namely automation. The road to more cost effective and innovative company starts with small steps. Take time for the conversion if needed, but the important message is to start now. And to think modular.