Title: VP Operations and Business Support Strategies, ARRIS
Broadband Background: Cruickshank provides strategic direction to the design, development and deployment of ARRIS Operations and Business Support Systems and led the development of DOCSIS at CableLabs. He joined ARRIS in 2007 as part of the acquisition of C-COR. Prior to that, he co-founded Stargus and was VP and interim CTO of Road Runner.
Your recent CT article on SDV service assurance mentions the need for tight integration of the different assurance tools used by different personnel (CSRs, NOC people, deployment engineers). Could you elaborate?
Tight integration is fundamental to improving service levels. First, you want different personnel to access the same assurance system so that installers, plant technicians, supervisors, CSRs, TSRs, NOC staff and others all have a common reference in understanding and sharing details about any service issue. Second, you want as much information as possible to pinpoint problems and quantify their impact on subscribers.
For example, with the assurance systems available today, we don’t need subscribers to call a CSR to tell them about "anything DOCSIS" that’s not working. Assurance systems proactively monitor the service level being delivered to any connected CPE and automatically report on how severely and how long the service is being affected. As an industry, we need to commit that we are going to be proactive about integrating this service assurance data, so that the customer doesn’t have to call in the first place.
Presumably this integration has been a challenge in the past. Can you mention any examples?
We designed DOCSIS to be the most manageable network in the world, though as an industry we’re still not exploiting all the manageability features that the DOCSIS authors specified in great detail – which ultimately lead to improved service quality.
One can cite any number of examples, but the point is that cable needs to shed itself of a reputation for lower quality, and service assurance is the means to accomplish this. These tools exist today, but are underutilized, even though by most measures they contribute measurably to an MSO’s bottom line, whether in reducing truck rolls or subscriber churn.
Assurance tools that involve every aspect of the delivery process can streamline operations. Conversely, tools that result from a patchwork of home-grown technology initiatives inevitably yield "spaghetti" processes that adversely impact subscriber satisfaction.
That said, these tools are only as good as the knowledgeable personnel who operate them. Operators that are succeeding on this front today are adopting comprehensive tools and making sure their employees are trained to use them.
How does service assurance fit into overall system reporting and tracking mechanisms? What’s ideal?
Ideally, service assurance drives proactive behavior, beginning with the first install and following through future upgrades, service calls and plant maintenance. Every aspect of service delivery should be traceable so that supervisors, managers, directors, VPs and GMs can easily get involved in reviewing the service levels delivered by their respective teams. Ideally, service level information is available throughout the organization – so that installers, CSRs, network operations and the executive teams have a live, right-now view of device and network status.
For example, with birth certificates, a technician can immediately verify whether a service or device has been successfully installed and begin tracking service quality immediately, vs. hours or days, which has typically been the case.
Given the scope of the system described in the article, OSSs immediately come to mind. Is a service assurance system necessarily a subset of an OSS? If not, at what point does it logically tie into an OSS or BSS?
Assurance is a component of a complete OSS. The intelligence of the assurance system reaches deep into the back office so that any one piece of CPE can be assigned a service level or SLA. Likewise, any collection of CPE can be assigned to an account for monitoring purposes, and in turn, these accounts can be tied to their supporting infrastructure: a tap, amplifier, node, CMTS, VOD server, call management server, or any other active piece of infrastructure in the network. A healthy OSS/BSS has numerous ties to service assurance.
The article also stresses the need for a common service assurance framework across all services – video, data and voice. Wouldn’t the traditional siloed nature of these services present a challenge there?
Yes and no. If you have many home-grown tools created to report outages, than yes, there are some insurmountable challenges in calculating voice, video and data service levels delivered to a home or business. Traditionally with these systems, you are largely unable to quantify the magnitude of pain when a subscriber calls a customer service rep to say, “It still doesn’t work.”
On the other hand, if you have deployed a system that tracks every hour of service (good or bad) delivered to every piece of CPE, then you’ve got an inherent way to compare your own teams’ abilities to expand the network and provide the best possible service, on a region by region basis. You can readily ascertain which of your installation, maintenance and management teams are delivering the best service and which teams need help. The good news is that such a system is available and has been helping MSOs around the world for more than six years.
You sound like you never stopped working on DOCSIS? Is that so?
Absolutely. In undertaking DOCSIS, we made a number of promises with regard to functionality, price and schedule. One of these promises that has yet to be realized is subscriber and service level manageability. Our industry has been blessed with several who understand the importance of OSS/BSS and have really pushed the development and deployment of service assurance and OSS systems. When these systems are being used – far and wide – as intended by the creators of DOCSIS, I am going to feel that I played my part in pushing DOCSIS over the finish line.