OSS's and Merged CLEC's

Raymond Raud
September, 2000

Companies merge for variety of reasons most of which have very little to do with OSS's. Once the merged company and its new subdivision start operating some issues are likely to surface. The disparate OSS's with overlapping functions become an obstacle to standardization and consolidation of business and operation processes, business reporting, uniform service levels and resource allocation.

Some of the issues are:

The OSS's are supporting isolated business processes, rather than combined one. For example, different subdivisions provide different quality and performance commitments to their customers as the processes support them. A customer, that has service from both subdivisions, becomes confused.
The company network resources (facilities, equipment) can't be combined smoothly because subdivisions count their resources in their OSS. Supporting service that requires resources from both subdivisions is complex, cumbersome and costly. Consider a service provisioning process where some design and assign must be done in one sub-organization, some in another. As a result, part of the customer circuit is in one, part in another database. This in turn creates maintenance challenge, as it is not clear which of these databases is the master for the circuit.
Management reporting (overview of the business performance). Same services, customers and revenues are kept in different OSS's as different subdivisions enter them for their processes. It is difficult to get correct and timely business overview reports.
Cost of operation that includes data entry, administration, process support, training,training and maintenance are multiplied by the number of OSS's with overlapping functions. A significant aspect of operation cost is user access to the OSS's from geographically distributed locations. Many past generation OSS's are designed for efficient performance on LAN, expecting closeness of servers to the clients (user terminal). User terminals implement significant functionality and must be supported and maintained in distributed environment.

The common resolution appears integration, consolidation of OSS's with unification and standardization of the captured data, presentation and process support. In many situations these OSS's are an evolution of Microsoft Office tools (MS Access and MS Excel are often used). They are not a result of a systematic design effort, but something that just will do for today and may need "patching up" tomorrow, but it works fine for small-scale operation.

1. Integration Strategies

There are many ways to accomplish integration. Each of the approaches have its drawbacks and benefits. In following sections we'll discuss some,some integration strategies that I have come across.

Replacement

Replacing old OSS's with new ones is a radical approach as it brings upon more change and instability to already turbulent organization. Yet, depending on the objectives and conditions, it is the fastest way to achieve a cohesively operating organization.

Radical replacement is a valid approach if none of the existing OSS's can support the merged organization because of technical limitations and enhancement is not timely or cost effective. If one of the existing OSS's is in condition to handle the needs of combined operation, then keeping this OSS and extending its use to all subdivisions may create less change and anxiety. The process of replacement is similar to introduction of a new OSS. The users need to be trained, the business and operation processes re-aligned, changes may be needed in methods and procedures. Among technical challenges is the timely data conversion and loading with synchronization and smooth cut over.

Phasing Out

If an OSS is service specific and the new organization is planning to phase out or change the service anyway, then phasing out OSS's together with service is the smoothest approach. There still may be need to transfer inventory and customer related data from old OSS but this is not a complex matter that needs careful synchronization with other change in the organization.

This approach is graceful to the organization, but it takes time to phase out services and capitalize on the merger benefits.

Integrated Performance Reporting

Integrated Performance Reporting provides consolidated business performance reports and supports management decision-making. Market revenues, resource usage, service and customer revenues and business unit performance are the examples of these reports.

It is simpler to integrate only reporting from the disparate databases. That would not unify the business processes, the network resources and assets would remain accounted and assigned in different OSS's and offering services based on combined resources of the merged company still remains complex and problematic. Yet, integrated reporting resolves the management reporting issue. A number of complex issues are still present in implementing integrated reporting. We will discuss them in more detail in a later sections.

Integrated Assets and Performance Reporting

Next step up from integrated performance reporting is to integrate also the assets, but leaving the service provisioning and other OSS's disparate. The integration could be constraint by geographic or product boundaries to further simplify the process. Clear benefit is possibility of service offerings based on combined resources. The business justification for additional integration must come from the additional revenues from services that rely on resource combination.

It is important to differentiate between integration and replacement in this context. Integration may not require change in the users task support. This function is still performed by the same OSS's as before. As a result, change in organization and processes are reduced together with training needs and productivity impact. OSS's integration for network resources, for example, can be accomplished by establishing a common master database for all resources that will supply the data to user supporting OSS's as requested.

Combined Approach

As usual, in engineering mission critical business support systems "one size does not fit all". Depending on the business needs, merger objectives and maturity of business processes in merged organizations different approaches may be viable in support of each specific functional domain. The approaches may also be combined in time, starting out with least intrusive and gradually introducing new, consolidated business processes.

2. Implementing the Strategy

Selecting and deciding on the strategy is just the beginning of the road. Real resistance, problems and issues come with implementation. The change projects are often understaffed and under funded to reach the expected business benefits. This, in turn, discredits the project, frustrates team members and users alike. We'll discuss the issues I have seen becoming problematic in these projects.

OSS Replacement

OSS replacement differs from new OSS' implementation in some aspects. It introduces a fundamental change to the business processes. A strong and credible leader is ultimately needed for success. The project should start with buy-in from all participants, realistic timeframes and expectations.

In addition to new OSS vendor implementation activities the CLEC's organization must fit this capability into their business processes, establish proper rules and standards for data entry and retrieval during the operation, train all users for the process and allow for temporary productivity decrease after cut-over. Here's the sequence of activities and tasks for OSS Replacement:

Develop business processes based on the new OSS
Data clensing and mapping to new OSS
Data conversion utility development
Installation of new OSS and loading with converted data for user training
Hands on user training with new OSS and real life data
Installation of new OSS for production and loading with converted data
New OSS cut-over

The new process in training mode must operate in parallel with old process in production mode for a while. Besides complexity of specific tasks and activities, staff training and operation synchronization becomes a real issue. Specifics of each of the operations is discussed later in the text.

OSS Database Integration

To avoid the change in processes, but still gain the advantage of consolidated resources, a CLEC could introduce an integrated inventory. This new database would serve as the master for the existing user facing OSS's that would not need to change. This way the business processes will not change fundamentally, minimal re-training is required and the advantages of consolidated assets become realizable.

Even though it is a simpler approach from change management viewpoint, the same technical issues remain and there are more of them. The additional complexity comes from the need to:

Create a real-time data mapping facility for conversion in both directions and
Change all existing OSS's for real-time synchronization with the new master database

Here are the major steps:

Data mapping of all existing databases to the common database.
Development of process changes as needed
Development of bi-directional data conversion utility
Modification of existing OSS's for real-time data synchronization
Extraction and data cleansing of data from the existing OSS's
Installation and testing of new OSS
Conversion and data loading to new master database
Testing the new system
Training users for process changes
Cut-over to the new system

Additional burden is the operation and maintenance cost of new OSS in addition to the existing OSS's together with the maintenance of the integration software. Some process changes are likely, as the inconsistent use of data fields relative to common storage must be eliminated for the new system to operate properly.

Since the new OSS's database consolidates only data for a specific functional domain (for example, equipment and facility inventory), integrated comprehensive business reporting is still not available with this approach. Unless the newly installed OSS provides web access, even distributed access to consolidated functional domain data is not supported.

Web Portal and OSS Integration

A web portal over multiple OSS databases provides the access to disparate data. It is becoming popular because of its simplicity and lack of intrusiveness. A web portal creates an efficient user access distribution layer atop of the OSS databases leaving the "old" interface intact. The web portal can be unidirectional -- addressing the unified reporting need or bi-directional, providing the users also data entry and modification access to the databases. The clear benefit is lightweight, standard browser based user terminal that does not require high bandwidth WAN connections, distributed maintenance, support, special hardware and extensive training.

Without additional, data integration, reporting on the whole organization is not available. Integrated data storage and mapping the data into a common data model is required to create the information for consolidated reporting. With that and new databases for common resources, we have created a 4 layer complex OSS infrastructure that serves the purpose, but is expensive to create, complex and expensive to operate.

Figure 1: Integrated OSS and Reporting

Most of the operation complexity comes from the constant data synchronization need. As the changes occur in the existing OSS layer, the Common Resource must be updated in the same transaction to avoid assignment and reservation conflicts, concurrently the changes must reach the Integrated Business data layer so that appropriate business decisions can be made. This project will make some middleware vendors happy, but it is costly and complex nevertheless. In addition to the transaction level synchronization, each of the connecting lines on the diagram represents a bi-directional data conversion utility, such that each of the existing OSS's is changed as little as possible.

Massive and ongoing synchronization effort and the resources required for that is the main drawback of this architecture. Luckily, there is some simplification possible if we would account for the actual telecom operation process requirements rather than taking generic IT approach. Likewise, the synchronization with the integrated business data layer can be simplified with deep understanding what is critical to synchronize and how it must be done. Knowing what the business users want and need to see, how it must be formatted and how frequently synchronized simplifies the development and operation significantly, but it requires telecom business knowledge at design time. This knowledge, embedded in the system behavior leads to an efficient distributed system discussed in the next section.

A Set of Collaborating Servers

Note, that the Servers should not be equated with databases. Databases are created to support data persistence. Extensive use of databases where persistence is not a requirement creates more problems with synchronization than the benefit of having the database for other functionality. It sure is simpler from IT viewpoint and as long as software engineers get their way, they will continue developing and installing new databases. The operations folks are stuck with them after deployment.

So, how does it work with fewer databases? To avoid boring other people with technical issues, I’ll be happy to discuss this topic offline, on interest. Drop me a note, or call.

3. Implementation Activities and Tasks

A number of operations are common whichever the implementation strategy. I discuss them briefly in the sections below. More details would probably bore people interested in an overview. Ask if you need or are interested.

Changing the Process

Change in the process is the most complex issue to deal with in an production environment. It is important to make sure that the new process is noticeably better for the users, better supported by OSS's and improve the recognized and acknowledged deficiencies in the existing process. The process definition introduces task and activity sequences, resource and other entity naming conventions, resource allocation business rules, formats and procedures not strictly enforced by the OSS's.

The process definition introduces the methods and procedures for using the OSS's. Like any program, it must be tested to ensure the integrity of data and possibility to execute all required business functions. While testing the process definition it is important to validate that despite possible user errors and misinterpretations, execution of all business functions is guaranteed. OSS's are typically large databases and the value of the data in them is only as high as the integrity and completeness of the processes that control the data entry and processing.

Data Cleansing

Lax processes are common for new organizations. They rely on user's intelligence, industry knowledge and experience more than on strict definitions. No matter how knowledgeable, each user applies its intelligence based on its personal experience and that differs from user to user. As a result, the users enter data differently into the OSS. It may not be a problem as long as humans in the same, small team interpret the data, but it becomes a problem if other OSS's (for reporting) of other people elsewhere in the organization must process the same data. That applies to inconsistent abbreviations, different use of data entry fields depending on implicit use of the record, inconsistent entity identification conventions etc.

Data clensing is typically a needed operation before data can be loaded from one OSS to another. It involves identification and unification of data fields, introduction of common identification and abbreviation standards. Elimination of redundant and consolidation of repetitive data records. Data cleansing is time-consuming intellectual work that can only be partially automated. Specifically difficult is identification and elimination of implicit data field usage as it requires prior knowledge of evolution and actual use of the OSS.

A number of vendors are offering data cleansing as service. There are also tools available that help with routine operations. Bulk of this operation is still manual. Good planning and special measures are appropriate to avoid re-doing the manual portion of data cleansing many times over. Like with any manual operation, errors are inevitable. Careful, well thought through process can catch most of them, but hardly all.

Data Field Mapping

Second challenge in this activity is data mapping. Duplicate tables and fields, extensive indexing are typical in ad-hoc designed and enhanced OSS databases. Finding the values for all required fields or deriving them from existing database schema and content is high skilled intellectual work. It requires knowledge of both, the old and the new database schemas, relevant business processes and practices. This activity creates specifications for the algorithms to map or derive the required data elements of the new OSS from the existing database.

To enable proper effort estimates for this task we'll go through a typical example below. Collaboration of a data-modeling specialist with deep industry knowledge and actual users of the database is required for this activity. Let's assume, that the OSS database consists of 50 tables, each having 15 fields in average with total of 750 fields per database. The steps involved in data mapping exercise are:

Study the Data model and Analyze the Schema,
Establish the main purpose of fields, their formats and coding rules.
Study the actual use of DB fields
Validate semantics of the fields
Create field mapping to new tables and fields
Create conversion, queries and rules
Document field mapping specifications
Validate mapping with users
Document field query
Validate mapping -- Review
Update specifications

Considering reasonable time to perform each of the tasks mapping of a database will cost around $60 - 75k if you bring in consultants. It may be little less if internal skills can be found.

Like the data cleansing, mapping can be done, but it takes time and resources. The trick is in appropriate planning, budgeting and schedule synchronization to avoid repetitive mapping and cleansing efforts.

Training

Introduction of new OSS or change in use of existing is a change in established process. Extensive, hands on training with real data is critical for the success. The real data for training requires data conversion and loading from existing systems for training. Since the business process itself continues supported by old OSS's, a second data load must be scheduled before actual cut-over to the new OSS.

Prerequisites for training are:

Written process description (Methods & Procedures)
Installed OSS loaded with actual data of the organization
Training materials covering all scenarios the users will encounter
Training validation utilities that evaluate the effects of user actions with the OSS
User feedback mechanism for errors and issues with the M&P, OSS and training materials

Comprehensive training takes time. Besides rendering trainees unproductive for this time, it also creates a tricky situation where they have to learn the new way of performing their tasks while still using the old systems for production. The scheduling is tricky. Best, if the users could be trained in groups such that once trained they will start operating the new system while the next group is trained.

Transactional Data Conversion

The data conversion software development for matching fields is not a complex task once specified properly. Finding the fields may be very complex task, though, as the disparate database schemas typically do not have matching keys. For example, how would you find matching customer records in different databases if the key identifiers are independent and name abbreviation rules have been different during the operation of the OSS? Clearly, if the name field is not standardized then other fields must be used for unambiguous identification. The identification of matching records in disparate databases without human interference is the central issue for this facility. If these fields do not exist, then they must be created, (potentially, with the help of users initially) and process changes must be introduced to make automatic matching possible for operation.

Mapping and finding data elements (objects) without common keys is one of the functional complexities that must be resolved at the specification phase. It includes the methods and field values and performance engineering issues. The last is not critical for one-time data loading utilities, but will become the key for bi-directional data conversion functions in case of collaborating OSS's that need to be synchronized on transaction basis. The size and complexity of typical telecom OSS's may present a performance engineering challenge. Bi-directional mapping requires a functionally equivalent facility for both directions. There is a "bag of tricks" for situations like that. Each of the tricks is applicable in specific scenarios, but there is no general "magic wand".

For example, the table indexing and hashing techniques may not work well because of size, multiplicity of fields required for the search and a large number of the records. An old-fashioned containment hierarchy "walk-the-tree" search may be the most efficient technique, keying from fields that are consistently filled and used in the process. The options that require some modifications to the existing OSS's may not be viable for other reasons.

4. Current State

This is about what I am able to contribute at this time. As it appears I’ll continue working on this topic and new material may appear as I learn it. Of course, it is possible, that I missed some topics that are interesting to you. Ask, I’ll write back if I know.