Process

By Jon Hoffman, CIO/CTO, Wataniya

In the Move to an All-IP Network, One CIO Says That Process Is a Greater Challenge than Technology

The competitive landscape of telecommunications is changing as quickly here in Kuwait as it is in the United States and Europe. Wataniya began as a provider of mobile communications, but we've just recently started to offer fixed and mobile voice and data communications. We have one million customers here, about 45 percent of the mobile market. We currently compete against the legacy telecom provider, Mobile Telecommunications Company (MTC), which operates in 6 Middle Eastern and 14 African nations, and the Kuwaiti government plans to grant a license to a third telecom provider in the future.

In order to innovate quickly across all these communications channels—fixed and mobile, voice and data—we're deploying a converged, all-IP network. Convergence gives us an infrastructure that will allow the organization to become a more efficient enabler of new services for the business. With a single infrastructure, we can bundle services more easily and have them appear on one bill. (This also simplifies our back-office needs, because otherwise we would have to have separate billing systems for each service.)

The interesting thing I'm finding is that the challenge of convergence comes less from the technology than from the process optimization.

First, we have to develop our employees' skills to fit the new infrastructure. The classic structure is to have two groups: one focusing on the network and data telecommunications; the other, on voice communications. Now we have to move staff rich in knowledge of T1/E1, ATM, and mobile telecommunications' GSM protocol and help them understand the latest IP technologies. The need for skills starts in our planning department, responsible for all technical installations, and continues into our network operations center.

We also have to learn how to be more process-oriented, rather than function-oriented. When you have many services running on top of the same equipment, you have to understand that when you change something on the voice service, it might affect something related to the data service. You have to look at the services going across the network as a whole, and think about the process for all of them. In the past, you might have been responsible for or concerned with a single vertical function.

We also need to develop a new mindset about reliability. If you're converging your services on one network, and the network suffers an interruption, it affects all your communications. We use IP within the company, and traditionally it has been OK if a router goes out for an hour. But that's not OK if you're a carrier-grade operator who wants to derive revenue streams from an IP network.

Your whole culture has to shift to a mindset that strives to deliver customer access that's 99.99 percent available. You have to engineer for high availability and redundancy. You need to set up your organization to think proactively about maintenance and incident handling. And you have to think differently about response time. In the old days, dealing with the internal IP network, IT was available during business hours; now, they have to be available 24 hours a day. Inherent to this is creating a policy of incident escalation, depending on the severity of a problem.

You also have to think differently about documentation and knowledge management. If only one person understands how a router was set up, and that person leaves or is unavailable during an outage, that's a problem. You need to maintain a repository of information so that staff can respond as quickly as emergency services workers, or can at least know where to find the information they need.

To accomplish this, we're sending staff to more frequent training and asking them to qualify for certain vendor certification. But we are also working to define our policies, procedures, and processes so that we can respond quickly. For us, that kind of knowledge needs to be internal.

As we've embarked on these changes, we've also had to consider the staff's reaction. Change is daunting, and you should plan to deal with people's emotional reactions during any change process. When you shift from one technology to another, it can be disruptive for people who feel that their specialized domain knowledge gives them job security. In our new system, in which we share trouble tickets and document everything about a problem, it's natural for people to feel vulnerable.

If I'd had more time to oversee this shift to the new network, I would have allowed more time for the staff to adjust. But given our competitive pressures, I'm forcing them to adjust quickly. That brings uncertainty. To combat this and to smooth the transition, we brought experienced people from other companies that have gone through this. We initiated free-ranging discussions in which our people could ask any question and air any frustration they might have. The forum was a good catalyst for further discussions about how we could continue to evolve our environment.

It has been a tremendous experience to transform a dusty IT network organization—with old switches and infrastructure—into a brand new architecture and organization. There's been a lot of change—all of it exciting.