Examining the Case for Automated Inventory

There's a basic tenet in the communications industry that's often agreed upon but rarely observed: you can't deliver service if you don't know your network. Yet stories abound about service providers having no better than 70 percent accurate data in their inventory stores. Generally the inaccuracy rate is far worse.

OSS vendor development has evolved from process-driven applications to systems that rely on a potent network inventory capability that provides a clear view of the network at any given time. According to inventory vendors, service providers understand that this new approach can bring efficiency to operations, sales and marketing. However, service providers have yet to make a widespread move to get to the root of many of their service delivery and revenue assurance problems-bad inventory data.

Improved network inventory represents an enormous opportunity for service providers to attack a critical, long-term challenge that would significantly improve their bottom line. The question is whether service providers are ready to take it on, or even understand the mixed messages with which vendors sometimes inundate them.

What Is 'Process-Driven' Inventory?

To understand today's approach to network inventory it's easiest to contrast it with older methods. Mark Mortensen, chief marketing officer at Granite Systems, explains that traditional provisioning involves tasks driven by orders for services. There's a design-verify-assign process where data is entered or updated in the inventory database. Then "someone goes out and bangs on the network to make it look like the database," says Mortensen.

Essentially two problems afflict this approach. First, the ordering process is dictating what the inventory database will look like, rather than looking at inventory as a representation of available and planned network resources that can be sold as services. In many cases, inventory data is spread across numerous databases that are each dedicated to individual technologies, processes, regions or organizations within the service provider. There's little integration among them, increasing the chance for inaccurate data entry, and essentially no way to derive a complete view of the network. As orders are pushed through, all kinds of exceptions and errors occur. The only way to improve such processes is to handle the transactions and exceptions faster.

But faster processing does not address the second problem, inaccurate data. Flawed inventory information instigates the assignment of service delivery dates that can't be met, or the sale of services that can't be delivered, because equipment or capacity that was thought to be available actually isn't. Service validation processes become tedious and unreliable. Customer care, provisioning and engineering personnel deal with the infamous "swivel chair" syndrome. Technicians are dispatched multiple times to fix the same problem because the wrong skill set was identified, and so on. This all-too-common scenario leads to higher costs to deliver service, lost billing and poor customer service. The bottom line is that bad inventory is a significant root cause for revenue leakage and shrinking operating margins.

Why the Problem?

Jim Janicki, chief technology officer at MetaSolv Software, explains that it's actually pretty logical why inventory problems have increased dramatically in recent years. "Telephone companies are good at delivering telephone service," he says. "They've done it for more than a hundred years. They've got the processes oiled and the accounting worked out to a thousand decimal places." They've also got inventory systems like TIRKS that are refined specifically to handle the circuit-switching infrastructure and can churn out any report imaginable.

But this, Janicki says, is only the line side of the switch. On the trunk side, things have become a morass of varying technologies that change constantly. So, when a service provider makes what appears to be an economically wise move and tries to leverage TIRKS or another telephony legacy system to handle trunks, big problems erupt. The legacy applications can't make the shift, so temporary patches start to appear. Now data, application functionality and processes are fragmented. Trunk-side inventory thus grows increasingly inaccurate as the entire system becomes more cumbersome and difficult to manage. In the end, service delivery is "really difficult without knowing what's really there," says Mortensen.

How Should Inventory

Be Handled?

Among OSS vendors such as Granite Systems, Eftia, Cramer Systems and MetaSolv (which recently acquired Lat 45, a vendor of inventory systems using geospatial information technology), there seems to be consensus. It's generally agreed that service providers should employ inventory capabilities that can support traditional process-oriented views of inventory data and services as well as a detailed, accurate view of the active and future states of the network and its relationship to customers.

When evaluating inventory's importance to the OSS platform, the first question to ask is, What is a service provider's business? The answer is "to create capacity, which they do by building out networks, and to fill that capacity by selling services," says Kimber Lewis, North American president of Cramer Systems and a former service provider executive.

With this explanation in mind, consider that capacity and services are abstractions of the physical network. Capacity is a measurement of the network's ability to move traffic. A service is a collection of network capabilities provided to a user. Billing is determined by the network and how it's been used or applied. Even a customer is defined by his or her relationship to the network and its services. The service provider's entire business is an abstraction of its network.

From this business perspective, most OSS processes should be designed around getting accurate data into and out of a single, detailed inventory store that provides core intelligence to the entire business. These processes should focus on representing the actual state of the network as it changes and the network's capabilities. OSS vendors generally agree that inventory is the heart of the business and that it's a hinge on which most other OSS processes and applications swing. Being the center of the OSS universe is a claim numerous application vendors like to make, but here it's safe to say that the network picture is the center of at least the service delivery and revenue assurance universe. The service provider must know what it can sell now, what it will be selling tomorrow, what and to whom it's already sold, and that it's banking every bit of loot it should be.

System Architecture from a Business Perspective

During the past few years, OSS design has made a major shift away from two-tier architectures, which involve fat-client desktop applications interacting with a back-end database. In their place are three-tier architectures, which utilize thin clients and an abstracted application layer that manages transactions between the back-end database and thin clients, other OSSs and business applications. Having the middle application layer eases system management and integration with other systems. It also provides some flexibility for accessing backend data and functions from a range of client interfaces. The three-tier architecture essentially centralizes the inventory management application functions and data so they can be accessible to the entire OSS suite.

As represented in Figure 1, the inventory store is the central component, and this source must be clean, accurate and accessible to a range of applications. The ring surrounding the inventory store is the inventory application. According to Mortensen, this element is "essentially an advanced database management system that provides the keys for getting data into and out of the inventory store."

The "thin client" can be any thin-client application, generally browser-based and integrated with the inventory application, including the vendor's own interface into the system. Other thin clients can include workforce applications that allow field technicians to interact directly with the inventory application from a handheld device as they physically make changes to the network's state, or bar code applications used for network auditing that can be integrated directly to the inventory application.

The "interfaces to other OSS applications" are the APIs or other mechanisms through which other applications-provisioning, activation, service ordering, network management-connect with the inventory store to check on, validate or alter its state. The inventory application portion handles the transactions between other OSSs and the inventory store itself.

Inventory's Place in the

OSS Suite

The basic architecture of an inventory system is central to a service delivery-focused OSS suite. Inventory is at the center of sales and customer service, ordering (for service validation), provisioning, and activation processes and applications. Among Granite, MetaSolv, Eftia and Cramer, all but Granite offer an integrated, inventory-centric service delivery suite. Granite, a pioneer of what it calls a "service resource" approach, offers a stand-alone inventory application; however, it has invested significantly in integration efforts with other systems.

The reason it's critical for vendors to deliver inventory capabilities with some preintegration, or as part of a suite, is that one of the main pressures they face from service providers is to reduce their overall number of interface or integration points. The best-of-breed systems appearing over the past several years have often left service providers spending millions to integrate a large number of individual components that sometimes just can't be integrated effectively. Since no single vendor yet provides a do-all OSS platform, vendors are competing to become "best in suite" as opposed to "best of breed," bringing larger, preintegrated applications to the table to reduce the overall integration burden.

The service provider's business generally falls into four quadrants, each representing a potential integrated suite. These include business (accounting and billing), service delivery, functions of the network operations center, and the network itself. The goal is to provide preintegration within each area, and then focus on implementation and ultimately on integrating the quadrants together in the ways the business demands; effectively reducing the number of integration points among the quadrants. Inventory has some relationship to each of the areas, but it's most central to the service delivery process.

What data the inventory store should actually house and how services are created are subjects of debate, and where inventory vendors tend to differentiate-particularly in how far they take the inventory store's scope and responsibilities.

Creating Services

Chris Dean, chief technology officer at Eftia, describes his company's approach to service definition as one that deals with "telecom inventory," including hardware assets and circuits, and "identifiers," including domain names, IP addresses, phone numbers, and the like. "To create a service, you bundle an identifier with a circuit, a piece of equipment, a port, and draw the linkages all the way down the chain," says Dean. "A service is a layer of abstraction and is defined by these linkages." With this method, a product catalog is effectively a set of product names with pointers to the inventory database-lightweight and easily modified.

Cramer Systems takes a different approach. Accordingly to Lewis, the inventory store is a "carrier resource platform" that "captures and applies technical and business rules between the demand- and supply-side systems." Services are essentially collections of business rules that are translated into technical rules that represent how the network should be delivered based on the business request.

Regardless of the approach, the important issue is whether the system can insulate service definitions from the network, so that changes in the network don't need to be reflected in each service definition and vice versa. There are numerous ways to accomplish this task.

What Should

Inventory Include?

What's actually stocked in the inventory store probably differentiates vendors the most. They all agree that it must be complete, in the sense that it must model the entire network, including device types, active and passive technologies, and the relationships among them all and to customers. The inventory platform should have prebuilt models for available devices, as well as the ability to model uncommon ones that might pop up. It should also be able to tie together disparate technologies, abstract services and real customers into a complete view of how customers are being served.

From there, the opinions differ. Granite's strength, for example, is in providing a comprehensive view of the network's configuration, or state, and its relationships to customers. This view also includes rules for sending field technicians with the appropriate skills to fix a problem, and other practical bits of information. Essentially, Granite is saying "this is what the network can provide and how it's behaving right now, based on what the network itself and the folks in the field report."

This philosophy represents the culmination of a long-term trend. Mortensen at Granite Systems, for example, is credited with coining the phrase "the network is the database," which was an interesting and popular concept that proved to be unwieldy. As he says, this concept meant "blowing away the external data store." It was an interesting idea, but it created a need for too much intelligence and processing in the network. "Data networks would have been passing all that data around, and it didn't make sense," says Mortensen. "Plus, anything that increases the cost of a channel unit by a dime, when you're selling 10 million, doesn't fly, [considering that] everyone goes by first costing."

Granite's result is an effective compromise between the process-based and network-is-the-database approaches. Ultimately, the network is the place to go for state information if there's ever a discrepancy, but the inventory data store is the place for all of the network-associated information, including information on services and customers. The tradeoff for improved performance is the need to keep the inventory store and the network synchronized.

Manage the Future

Cramer's Lewis believes that "using the network as a database of record is no longer good enough." She stresses the importance of both the current and future states of the network. "To do any capacity modeling, you need to manage what you own and what you'll sell. It's about preplanning, and provisioning against and documenting the future state of the network, as well as the current state," she says.

MetaSolv's Janicki follows a similar thrust, and he stresses the benefits of geospatial information for network planning and sales and marketing support. "With geospatial capabilities, I can figure out where my network really is in the world and then do overlays that are sales- and marketing-focused. I can determine where the network appears in a country or city, where new construction is happening, and I can determine how I should evolve my network to sell into those areas." Such capabilities helped drive MetaSolv to acquire Lat45, and Janicki feels the new technology, once integrated, will help reinvent his company's offering. Though all of the vendors agree on fundamental goals for a complete inventory record, the Lat45 data model seems to be the most inclusive. That's not to say that it is or is not the best approach, just that it represents one end of the spectrum for the all-inclusive inventory store.

Customer Data and the Product Catalog

One of the fuzzy areas encompasses product catalogs and customer data. Where should it all be stored? This is where strong integration among the quadrants mentioned earlier becomes critical. For example, a billing system is still going to house billing records, rating plans and the like. A sales or customer care application can house data relating to special offers or bundles, customer histories, and so on. The inventory system should focus on the network, its capabilities and how it connects to customers. But a product catalog can span billing, inventory, customer care and sales systems. So the question becomes, should the inventory system own the product catalog?

Well, it already does, in the sense that what's in inventory should be ultimately translated into product offerings-though in reality the process often works the other way around. Any system that needs to know what the network is doing, or what it is planned to do, should refer to the inventory store. As discussed earlier, nearly every vendor regardless of function will claim that its database must be the master. But to boil it all down, billing, product catalogs, ordering processes, rate plans-everything ultimately relies on what's in the network. Other data stores will deal with application- or process-specific functions; rate plans in the billing system are a perfect example. But the common network data to which all of these systems must refer has to be accurate and easily accessible, and its place is in the inventory store.

Adapting to the Environment

In a legacy environment, building a master data store isn't always simple, nor is it always entirely necessary. Cramer's Lewis argues that the inventory system, though at the center of many processes, doesn't necessarily have to master all of the relevant data. Given the quantity of legacy data and existing processes out there, she says, it's more important for the inventory system to be able to access data from other reliable and perhaps domain-specific sources, like a TIRKS database. This can help create a migration path to a clean data store in the new system, rather than pressing a service provider to migrate to new systems all in one shot.

Eftia's Dean also suggests that there's been a shift from out-of-the-box systems back to more tool-based needs. "When you get into larger players," he says, "there are nuances in their systems and organizational reasons behind them. They don't want the pain and cost of shifting their processes." Though an inventory system doesn't necessarily define end-to-end processes, it will be part of a suite of systems and must be flexible enough, on its own or as part of an integrated suite, to support whatever processes might surround it. That is simply what service providers require.

Benefits… and a Big Stumbling Block

Overall, then, a strong inventory capability integrated to other key applications will improve service delivery by providing a clear view of the network's state and an integrated capability to affect that state. This streamlines and reduces the cost of service validation and delivery, and can be used to target sales and marketing more effectively. It can decrease the number of exceptions and "kick outs," because ordering applications won't be able to shove invalid requests into the service delivery process. By linking the network to the customer it can bolster trouble management, and it enables things like "proactive customer management" that the boardroom loves to hear about and that ultimately leads to better customer relationships and more sales (see "Wall Street Perspective").

However, an essential element of the inventory system is a complete, accurate data store. But accurate, all-encompassing data stores are nearly nonexistent.

To build one generally requires a network audit and a serious data migration effort. Tools like autodiscovery can help to audit the network, but they can't create a complete, logical view of it or tell the provider where gear exists in the physical world.

The Service Provider Mindset

To be fair, no vendor has been foolish enough to suggest that a service provider should move to a new, clean inventory database all at once. That would be practically impossible and would be extremely risky, as "big bang" projects often fail miserably (see "Project Failures Spur Management Back to Basics"). What a provider does need, however, is a clear migration path to the new environment that mitigates risk and assuages fear.

From the service provider's perspective, moving the organization to a new inventory model and capability is a strategic decision. It affects numerous systems, processes and organizations. It changes the foundation for many current business processes and data flows. So, before the provider ever considers the long-term benefits, it's faced with multiple short-term headaches that can turn into major projects themselves. The risks and costs increase with each step. It becomes a matter of trying to save $100 million by spending $30 million. It sounds great on paper, but it's tough to manage and relatively likely to fail or turn into a white elephant, which can mean career death for an up-and-coming executive.

With a Tier 1 service provider, even a small improvement in process efficiency can save millions when spread across the entire organization. So a short-term bandage that minimizes risk but shows tangible results is just a safer bet-it's manageable, deliverable and quantifiable. So it's no wonder that service providers aren't breaking down vendors' doors to buy new inventory systems. They're interested, but ultimately they seem to choke on the costs and risks.

Ultimately the problem isn't really about technology. It's about organizations and people. People are risk-averse and prefer to duck tough decisions. People from different organizations might not get along, and when it comes time to integrate systems, they have trouble succeeding together. Service provider organizations are highly fragmented, so taking on a large, cross-organizational project involves a level of coordination and diplomacy that few can deliver and isn't what the provider is accustomed to doing

The Vendor Message

Vendors largely downplay data migration risks and network audit challenges, although doing so will not assuage fear. Eftia's Dean is a notable exception, saying that "fear of data migration is good, because it helps with realistic expectations. But it's not a matter of challenging the provider with what needs to be done, it's a matter of showing them how bad their data is" and helping them understand why it needs to improve.

As the vendors describe their migration paths to deal with such issues, their messages can become unclear. This flaw may be the culprit that restrains this application segment. What the vendors try to describe is a scenario where the network inventory basically builds itself: Existing network inventory records are left in place. When they need to be accessed in the course of a business process, the data must be verified (perhaps physically) for accuracy, modified to reflect the current or planned state of the network resource in question, and then updated in the new inventory store.

However, what this sounds like is a process-driven approach to network inventory that may only succeed in moving bad data from one system to another. Whether that's true or not, it sounds contradictory, and is probably confusing to a service provider.

It's a "mixed message," says Hampton Adams, senior equity analyst with CIBC World Markets, "and it's tough for service provider executives to hear all of these mixed messages from software vendors, consultants and systems integrators and get a clear idea of what to do." Some of the burden falls on the vendor community to clarify the message-if it's really not all that tough to migrate to these new systems, then explain it in a way that makes sense and isn't contradictory.

Finally, perhaps the biggest challenge inventory vendors face is that they lack a Great Inventory Story. There isn't a "Friends and Family" equivalent in the inventory market. WorldCom and AT&T haven't come out and said, "We consolidated and automated our entire inventory capability and revolutionized our business." The path isn't clear, and neither is the payback-intellectually, we as technologists know it's there, but as business people we are skeptical. OSS vendors have over-promised and under-delivered before, and haven't done enough yet to alter that perception, whether it remains accurate or not. That alone will stop a service provider from making what's already a risk-laden decision.

An OSS vendor will have to show not only that its technology is strong, but also that it can deliver on a Tier 1 carrier's scale. It will take some forward-looking, gutsy service provider to move toward inventory-centric OSS, have amazing success with some fortunate vendor and pocket many tangible benefits. Until that happens, automated inventory-arguably the key to solving the root cause of most service delivery problems-will remain a fantastic idea and a tough sell.