The only publication dedicated to OSS     Volume 1, Issue 9 - February 2005
Current Issue
  Cover Page
  Merger Problems
  Pipeline Q&A:
      Vallent

  Service Quality
     Reality

  Scouts Notes
  Growth
News Brief
Subscribe
About Us
Archives
Ed-Opps
Ad-Opps
Advertisers
Sponsors

Download and print this article
download & go

Mergers Drive Problems Before they Deliver Benefits (cont'd)

Standards and Commonality
A lot depends on if there is an existing standard for the existing systems. Vericenter, for example, a growing managed service provider, increased the size of its network by 600 percent when it acquired six data centers from Sprint. Standardizing on its existing trouble ticketing system - Remedy - made sense. Vericenter had the necessary expertise to use the tool because it is extremely common in the industry.

“We took a ‘scorched earth' philosophy,” says Paul Duda, System Architect for Vericenter. “We developed our criteria for monitoring by determining the services our customers wanted and needed. In addition, any solution had to be scaleable since we are growing so fast,” he said. The Houston Business Journal identified Vericenter as one of the fastest growing technology companies in 2002, and in 2004 Vericenter achieved record revenues.

When Vericenter began operations, the decision was made to use industry standard tools. This allowed it to start generating revenue much faster than if it had created its own tools. When Vericenter acquired the additional six data centers, it knew it was a good opportunity to re-examine its tools and solidify or improve current standards to enhance its capabilities.

For older, larger companies it's usually a different situation. With MCI, for example, it was quite common for each service to be managed in its own “silo”. The service was self contained. All provisioning, monitoring and fault correction was done for that service and only that service. This meant that each tool was designed in-house, specific to each service. There were, however, no standards for databases, for the language in which the tool was written, for terminology definitions, or for field definition. This made it nearly impossible to apply tools across a variety of services because there was no commonality to facilitate integration.

Customer Migration
Once the tools are chosen, there is still the critical matter of migrating customers and services to the new tools without interrupting service. At the same time, high quality services have to be provided to the torrent of new customers that are coming online. In Vericenter’s case, it decided that new customers would be placed on the new platforms, thus eliminating the need to migrate them at a later time. Second, the company moved all services of a given customer one at a time so that all metrics and reporting would be the same regardless of the service. The look and capabilities of the customer’s web interfaces were also changed at the same time, reducing confusion for customers.

For companies such as MCI or Sprint, or any of the large mobile operators undergoing mergers, it is a radically different situation because they have many legacy systems. It may be cost prohibitive to migrate away from their old trouble ticketing and monitoring systems. In these cases it can be a better choice to put a front end on the monitoring tools so that all services have the same look, but all the legacy systems remain intact. Sprint uses this approach when it acquires new companies.

It is a much simpler process to add a front-end rules engine that queries users for fault information and takes them to the correct trouble ticketing system based on the service being provided. This isn't the most efficient method, but it is less risky than trying to migrate to a new tool. If trouble tickets are lost and faults aren't fixed the result could be thousands or even millions of dollars in lost revenue.

 

Send Comment

 

Subscribe   About Us   Archives   Editorial Opportunities
Advertising Opportunities   News Brief   Advertisers   Sponsors

© 2005, All information contained herein is the sole property of Pipeline Publishing, LLC. Pipeline Publishing LLC reserves all rights and privileges regarding the use of this information. Any unauthorized use, such as copying, modifying, or reprinting, will be prosecuted under the fullest extent under the governing law.