Change Management in Complex Environments

Unique services, such Nextel’s Direct Connect push-to-talk offering, separate a service provider from the rest of the pack. Winning first-to-market, however, takes a toll on the OSS when billing for the new service demands changes to both upstream and downstream systems.

“Customization projects, new services and efforts to integrate multiple systems can severely affect the value chain and revenue assurance if operators do not have effective change control in place,” says Katherine Kisovec, U.S. business support systems service line director for Cap Gemini Ernst & Young’s Telecom Media Networks division.

Introducing more complex services, such as wireless picture phones, voice over IP, push-to-talk or bundled services, means larger scale customization and integration projects that demand effective change management. Any of these services, as well as smaller customization projects with minimal changes to a single system could require changes to billing, mediation, provisioning, inventory, customer care and other support systems.

For example, the mediation system may need to be modified to collect different data for the call detail record or modify its rating. The provisioning system may need to be reconfigured to receive order and customer information. Inventory may need an adjustment to understand which elements are affected by the new service. And customer care may need to be updated to provide service representatives with the necessary customer and service information to support the new offering.

Other systems, especially those in marketing and finance, may also need adjustments. And even third-party systems maintained by partners could require modifications. Accommodating the more complex services requires large-scale, cross-department change management efforts at a time when carriers have fewer staff and decreased budgets.

Approaching Change with Project Management

Most operators, especially the Tier 1 providers, have become familiar with the best practices for change management and project management due to their experiences with mergers and acquisitions. They realize that customization projects require cross-department cooperation and communication.

At times the magnitude of the project prevents some operators from tackling a much-needed overhaul or a minor update. “Operators tend to let inertia settle in,” says Julie Wingerter, vice president of strategy at NetCracker. “Faced with justifying ROI [return on investment], defining a solution, and developing a team that can define a strong OSS strategy across multiple departments, they will sometimes do nothing.”

More sophisticated operators have project management offices that manage the overall project and ward off inertia. This group is responsible for researching the project, investigating which systems will be affected, defining the best approach for implementing the necessary changes, and outlining the project from start to finish. “A PMO [Project Management Office] takes a long-term and short-term look at how one change enables business and affects potential processes,” says Kisovec.

The biggest challenge for this group, especially in a large environment, is sequencing the changes across departments in the proper order, says Don Tiedeman, director of business architecture, telecommunications industry, for Fujitsu Consulting. “[Multiple groups] will have changes, and it’s important to prioritize them across all departments without disrupting the environment and while meeting time-to-market needs.”

Having a single group manage the changes is often a better choice for complex customization projects, but some organizations may choose a less formal approach due to money or time constraints. These decisions, cautions Kisovec, can be risky.

“The long-term cost of change can be disastrous if not managed properly,” she says. “It’s well worth the effort to approach change in a structured, methodical way.”

Billing Customizations Present Unique Challenges

Because critical customer data resides in billing systems, they are often at the center of customization and integration projects. Michael Murphy, executive vice president at Am-Beo, says he’s seen complex billing systems that have more than 150 point-to-point interfaces to upstream and downstream systems.

Tapping into a billing system’s database through an interface is no easy feat, and the multiple interfaces can lower input/output transactions. “It’s a universal problem,” says Murphy. “Many companies live in their billing system. If all the data resides in the billing system, service providers are asking the biller to do much more than it was originally designed for, and it makes it hard for other systems to use the data.”

Other systems must access billing’s data to activate customer services and to enable business efficiencies such as revenue assurance, customer relationship management or a better understanding of network activity and how it relates to the customer. Billing systems are not equipped to support these activities, but as the central repository for customer data, other systems must access the biller.

One potential solution for decreasing the number of interfaces to billing and to make customer data more accessible to other systems is by creating separate synchronized databases. As real-time technology within the infrastructure advances, service providers now have the option of building two synchronized data stores that share customer information in real-time. This alternative limits direct interfaces to the billing system, maintaining input/output transactions, while opening up the data to other systems.

“Companies that have solid data warehouses are ahead of their competition in terms of managing and using data wisely,” says Murphy.

Has BSS and OSS Interconnectivity Simplified Change Management?

In the last few years the industry has made good progress toward integrating disparate support systems. The vision of no-touch, flow-through systems never fully materialized within service providers’ environments, yet the adoption of commercial software and requirements to interconnect with CLEC support systems has made exporting and importing data to billing and OSS easier.

Given that more support systems are interconnected—and are no longer stranded islands of data—is customizing one system more difficult? Has the effort to interconnect systems hampered development to a single system?

Some, like David Sharpley, senior vice president of marketing at MetaSolv, continue to preach that integrated systems are the best means to lower total cost of ownership and speed time to market. Others recognize that the more interconnected systems are a positive shift, but the interconnectivity has drawbacks that can sometimes hamper projects.

“[Integrated systems] might lessen the effect of a customization project but it impacts time to market,” says Tiedeman. “IT staffs have a long queue of projects, and the more complex requests may get a lower priority. When the databases are separated, he explains, “the marketing manager is in a better position to have a change made quickly.” Separate databases also allow greater functionality, he adds.

If considering a billing customization project solely from the effort required to update changes across multiple systems, NetCracker’s Wingerter agrees that data kept in silos does limit the overall impact. But, she warns, breakdowns will occur if the other systems are not modified.

“An organization must develop a thoughtful OSS strategy that includes an architecture that makes updates without negatively impacting other areas,” she says. “To do this, they need a database model in which they can change the information store without re-coding the core software. This type of architecture creates a solution that grows as the service provider grows.”

To overcome the negative effects of customization projects, Kisovec suggests that service providers strive to build an enterprise, horizontal view across all systems. Making a single change in this type of environment is less complicated, she says, because the service provider has a more global view of the business, the systems and the customer.

Is Middleware the Answer?

During telecom’s more expansive years, middleware came to the forefront as a potential solution for easing change. The vision was that an additional layer of software that acted as a hub, interfacing with all systems and translating data between systems, would allow service providers to introduce new services and modify current systems more easily.

For some, middleware has lost its luster, and expensive projects that didn’t reap the promised results have left the industry more cautious toward it.

“Two years ago everyone was in a rush to use middleware to connect all the various systems and simplify change management. As the communication bubble burst, and people became more cost conscious, it became obvious that middleware was a good technology solution but not a good cost solution,” says Tiedeman. “We are hearing more stories of companies using more traditional methods for direct connect.”

Integration projects, using middleware and interconnecting up to 10 and 12 different systems and applications, are a management challenge from a software and vendor perspective. The software is often being shelved for more familiar, less resource-intensive systems.

“Many carriers don’t have enough personnel to support all their systems, and software needs forethought, planning, support, and maintenance to make it work as advertised,” says Kisovec.

Support for middleware as a technology, though, has not wavered among service providers or integrators. “Middleware provides a standard interface to go into OSS/BSS systems without impacting the interior operations of those systems,” says Am-Beo’s Murphy. “Middleware may not receive the same buzz as it used to, but it does have benefits. It simplifies the number of interfaces and makes system management more efficient.”

The expectation among some is that the concepts of middleware will be expanded with technical advancements, such as Web services. “Middleware is a stopover point, or bridge, that is solving problems until Web services are mature,” says Daniel Kenyon, communications industry solutions at PeopleSoft. “Service providers want to move to Web services, but they are being forced to get by with point-to-point solutions or a hub-and-spoke architecture because they are the only practical ways to approach integration now.”

Kenyon predicts that the middleware players that have not been able to maintain their library of interfaces will disappear, and the survivors will rely more on Web services.

More Software Advancements Needed

More accessible data and flexibility are two of the benefits service providers have gained from commercial software. As BSS and OSS software continues to mature, operators should realize more advantages, such as more effective methods to introduce system changes. Before change management eases, the software must overcome current drawbacks, such as a tendency to restrict access to certain portions of the code.

The top complaint about today’s software is that it is not open, which makes customizing any system onerous. Even though the industry says the right words, “standards-based,” “non-proprietary,” and “open,” these terms are often meaningless or half-truths when the software is put to the test. Service providers are still unable to easily reach critical aspects of the software, and these limitations hinder their customization and integration plans.

“Billing developers tend to not want to open their interfaces,” says Am-Beo’s Murphy. “They say they are creating open software, but it’s really closed. They need to open up interfaces to areas that are not part of their core software.”

The closed software is often explained as the developer’s attempt to maintain market share. PeopleSoft’s Kenyon says those competitive efforts will ultimately fail.

“Over time [closed systems] will frustrate carriers, and those software companies will lose business,” he says. “Service providers will seek software that has published APIs, open source code, and common interfaces such as XML, SOAP [Simple Object Access Protocol], and WDDI [Winpath Device Driver Interface]. Carriers are tired of developers using gateways, connectors and adaptors as ransom to get to their data.”

To make data more accessible and customization less risky, NetCracker’s Wingerter says software must follow three rules: “First, the software must have different tiers of stored information with the business logic at the top tier. Second, integration and customization should be executed at the business layer, integration layer or message bus, not from database to database. And third, all software should use standards, such as J2ME and XML, and expose APIs so that data can be moved into and out of systems.”

The challenge within many service providers is that they are still tied to older code, such as C and C++, which makes customization projects difficult. Adopting software development languages, such as Java and J2ME, will decrease the effort required to customize a billing system or other support system. Fujitsu’s Tiedeman points out that because many systems already support these higher-level languages, some change requests do not have to go through the IT department. “Programmers are no longer needed for many changes,” he says. “A layperson can make the change.”

Standardized Platform to Improve the Environment

The service provider’s complex environment is the major contributor to making customization projects so difficult to manage and implement. Legacy systems, non-standard platforms, and multiple billing, mediation and inventory systems, make introducing new services, bundling services, or changing current services a gargantuan task for operators with tight budgets and limited resources.

To reduce the impact of customization and ease change management, Fujitsu’s Tiedeman advises that carriers choose a single platform.

“Many service providers have every platform known to man in their environment. At one point that may have made sense, but it makes for a complex world,” he says. “A single platform makes for less customization in the long run because it has the same rules and protocol standardization.”

As soon as Tiedeman states the obvious, he quickly adds, “One platform is perfect but probably not likely.”

Since no operator is leveling its current environment with a full-scale replacement of next-generation BSS/OSS software, service providers will continue to forge ahead with manageable, customization projects that reflect the overall OSS strategy and help them reach their business goals quickly and cost effectively.

“Carriers have stopped being so reactive,” says Kisovec. “In the coming year, they will continue to make decisions about customization projects based on if they are strategic to the overall business.”