How can an operator streamline the as-built process? How can an operator build their own serviceability application quickly and easily? Can equipment and device monitoring be enhanced using location? Can an operator combine a trouble ticketing system with a location intelligence system?
How can we address these questions? Hint...it's a three-letter acronym that starts with a "G". Yes, that is correct. GIS, or Geographic Information Systems. There is no one system to rule them all, but in the world of telecom operations and service fulfillment, the concept of location is applicable to so many activities that the incorporation of a GIS into the operational side of the business is no longer a nice to have, but a must!
"Fulfillment and Operations". What exactly does that mean? Allow me to set the stage. First things first, this topic is applicable for telecom operators. Big, small. Wireline, wireless. It doesn't matter. What this topic refers to is that of the operational side of a telecom operator's traditional line of business, connectivity. Quite often this is referred to as the OSS or Operational Support Systems. And so, the topic of this post is related to the activities that happen on the OSS side of a telecom business with emphasis on how Geographic Information Systems (GIS) can help support the many activities that happen in this realm.
There are a LOT of activities that occur on the OSS side of the fence, with most of the effort geared towards delivering and supporting communication services for residential and business markets. This represents a big chunk of an operators’ business in selling services and maintaining the network. The “bread and butter”, so to speak. There are many systems, many data repositories, tons of workflows all working to support this part of the business.
What is interesting is that there is, in fact, a common denominator throughout all the activities in the OSS landscape that could be leveraged to help drive efficiency and creativity across these systems and workflows. That common denominator is location. The concept of location to support the various activities is often forgotten, but that's what I am here for! Let's look at some of the ways that location and GIS can help support some of the many activities that happen on the OSS side of a telecom operator's business.
As-Built Corrections and Map Notes
In greenfield network deployments and brownfield network upgrades there are always changes. It's a given. The challenge lies in the workflow and tools used to communicate and push these changes, or as-builts as they are referred to in the industry, back into a formal engineering system of record. Why is it a challenge? You could chalk it up to the scale of the work, the duration of the work, the number of stakeholders involved in the work, and the tools used to communicate the work. That long-winded sentence alone should be enough to give you an idea of the complexity of the design to the as-built process.
With so many variables in play, the time it takes to move as-built information from the field into the engineering system of record can be quite long. Compound this effort with the quantity of operational work orders on the go for a very large network and now you have accumulated a backlog of as-builts that is near impossible to catch up on!
But what if the tools used to design the work (engineering) and communicate the backlogs (construction) were all done using the very same system? Well now, that is an interesting thought. Imagine an operator and build partner, or operator and their field group using the very same system to see the network and make changes to the network without having to import/export and move static files around? That would be magical and yet, completely in the realm of the possible!
A spatially enabled ecosystem that facilitates the seamless communication of network assets from the office to the field and back to the office exists and can, indeed, help alleviate the burden of as-builts. Create an operational work order, implement network changes, make notes directly to the work order with redlines, and notify the engineering team of work order completion all using an enterprise grade GIS solution! PDF files, Excel files, CAD files, and paper, well, they don't have to go away. Use them. Attach them. But when it comes to the actual as-builts, isn't it time to improve on this workflow by leveraging digital automation? The time savings could be significant!
Service Qualification and Provisioning
Ah, the age-old question, can I get service?! I can't think of anything more dependent on location than this question. It is the beginning of the serviceability journey. It is the starting point for onboarding new customers and upgrading existing ones. It is critical that customers start off on the right foot by answering this question right from the get-go to help with new sales and customer retention.
So, how is it solved? Well, civic addressing and network information are two key pieces to this puzzle. We need to know where the customer is and what type of services are available based on the network, or at least the proximity of the network to the customer location. Are you going to build your own address locator? No. Are you going to use a solution that doesn't have the ability to incorporate network information? No. This is where GIS shines! An enterprise GIS solution allows operators to easily identify customer location and compare that to network information to help identify what type of services are available, AND if a service isn't available, use a spatially enabled form-based tool to document the service request and the customer location to help drive network planning for future builds? It makes sense. An enterprise GIS solution is in a perfect position to help the serviceability journey, even if you are building your own interface or leveraging a no-code/low-code approach. Using GIS in this scenario is a no-brainer!
NOC. Surprise! Another acronym! NOC, in the telecom context stands for Network Operations Center. This is the central location for the monitoring of all things operational regarding the network. Monitoring devices, monitoring equipment, truck rolls, network traffic, and many, many other metrics all related to the network. With so many different types of "things" to monitor, the information, as you can imagine, will come from a variety of disparate systems, often unique to the vendor of the equipment. So, you can picture a "command center" with a sea of computer screens flashing all kinds of metrics and KPIs (Key Performance Indicators) with a select few lucky individuals spinning around to keep their eyes on the health and status of the network.
What happens when there is an issue with the network? With all these systems and sources, how is the root cause identified, both operationally and spatially? Jump from screen to screen, to screen and start creating an organized crime pyramid on a corkboard? As fun as this would be, no, we don't want to do that. What about a single, centralized dashboard of network parameters highlighting the location of said assets related to the root cause? Hmmm. That could work! Regardless of the component of the network one is monitoring, understanding how it relates to the physical plant and knowing where that is in the context of the network footprint is the goal when monitoring the operational health of the network. Having the IP address of a device that is giving you trouble is great, but knowing what needs to be done and where, well now, that's what makes NOC staff superheroes!
Okay, this is the last example that I am going to share of an operational activity that can benefit from an enterprise GIS solution. Damage Assessment. The location of the damage, the location of the workforce, and the ability to tie network information and ticket information, together, into a single damage assessment workflow has many advantages. But the one that stands out the most, for me anyway, is the ability to pull in pertinent network information into the trouble ticket to help with the damage assessment and repair. Quite often, these two systems, trouble ticketing and network management, are separate. That is understandable. However, servicing the network and visibility on network assets in terms of what it is and where it is, shouldn't be mutually exclusive. No. That is an old paradigm.
This is where an enterprise GIS solution can help. Engineering is capturing the network as it lives in geographic space, along with the attributes of the network components of interest. Why not integrate these details with the trouble ticketing system? Perhaps "damage" isn't the right word for this subtopic. Maybe it is simply "troubleshooting". Network Troubleshooting. And this could be the physical plant that customers use or the internal network that an operator needs. Tickets, equipment, location, and steps for action represent a recurring pattern that could be used for internal or external use. Regardless, implementing a solution where physical location of network assets in the remediation of service interruption is critical and an enterprise GIS is ideal to helping in these workflows.
In this blog post, I strategically picked a few activities that happen on the operational side of a telecom operator's business to illustrate the need for an enterprise GIS solution. If you would like to dig deeper, perhaps with some examples of GIS technology and how it can be used for fulfillment and operations from a telecom operator's point of view, check out this ArcGIS StoryMap entitled, "ArcGIS and Telecommunication Fulfillment & Operations". The same activities are discussed highlighting the challenge and potential GIS solutions to take into consideration when trying to address some of these challenges with the context of location in mind. I hope you find it informative. Until next time...