Case Study: Purchase Order Number Skimmer - PONSkimmer

Case History

In February of 2000, the FCC permitted the Regional Bell Operating Companies (RBOC) to offer Digital Subscriber Line (DSL) services for general sale to the public, with the restriction that the RBOCs had to provide parity for competitive carriers. One major telecommunications provider took the approach of spinning DSL sales and operations into a separate entity and affording it the status of a competitive local exchange carrier (CLEC). This new entity would have to deal with the incumbent local exchange carrier (ILEC) on the same basis as other competitors, even though the RBOC itself was the ILEC.

The company created a parallel information system for the new unit, copied from the existing system at the ILEC operation. An EDI-type interface was implemented to feed orders out of the CLEC in the external order specification used by other CLECs. Although this seemed to be a straightforward strategy, several factors complicated real-world performance. The original ILEC software was fully integrated. Orders were designed to flow in an uninterrupted process from order taking to order fulfillment and billing. Since orders were now interrupted between the CLEC unit and the ILEC unit responsible for provisioning the circuit, orders would experience difficulties at the hand- off between systems. Timing issues surfaced as orders and changes to orders flew between the organizations. In pilot studies, orders were lost or delayed significantly, and single orders were often duplicated multiple times as customer service representatives tried to expedite customer orders. Work-around procedures were identified and implemented. Although the system covered the bases in theory, the small pilot used to design the process would prove to be inadequate for the system under full operational demand.

The Problem

In the fall of 2000, the company began aggressively marketing DSL into its service areas. Almost immediately, the inadequacies of the software solution surfaced. Orders were delayed for weeks. Some were lost completely. IT responded as quickly as possible, but the complexity of the environment exacerbated their efforts. Old legacy systems and new web-enabled interfaces were hard to mesh. New problems arose as soon as old ones were retired. Ultimately, resolving these problems would take several months.

In the meantime, the company needed to provide for the huge demand for DSL service. Within a few weeks, customer service representatives were entering thousands of orders. Hundreds of customer support representatives were needed to marshal the orders through the system. Their work week averaged over 60 hours for months and turnover took a heavy toll on managers and customer support representatives. Order fallout was very high, and resolution relied on the skills of customer service representatives in various regional call centers. Lacking the experience and the tools to quickly resolve errors, some orders were not fulfilled for weeks, and some were never fulfilled. Cancellations were common and customer frustration was very high. New product promotions threatened to drown the customer support systems.

As the first line of response, call center personnel had a problem that was not easily resolved. Because of system architecture, customer support representatives had to correlate information from at least three different computer systems in order to resolve even simple problems. Incredibly, there was no common order-based key linking all systems. Additionally, each system had a unique interface, complicating training strategies. Two systems ran on mainframes and required knowledge of proprietary interfaces and special search methods. The information needed to track orders passed to and from the ILEC consisted of a variety of text reports posted to websites. The order interchange software used a Java-based GUI to a client-server system, completely unlike the 3270-style mainframe programs. Because of explosive growth in new offerings, customer service representatives were added quickly, with no experience using the old, legacy mainframe applications. Even experienced mainframe users were spending an inordinate amount of time searching all the scattered sources for information. Fallout rates and backlogs were enormous and growing. On top of it all, computer staff from IT were swamped rolling out fixes to the new systems and adapting to the changing environment.

The Solution

Management responsible for data operations support and customer satisfaction wanted a way to have all the information the customer service representatives would need to resolve their problems gathered automatically and presented in a single, unified format. They wanted a system that could run with minimal support from center staff or from IT. They wanted the ability to home in on specific categories of problems. Finally, they wanted a way to help managers assign and follow up on customer representative work loads.

Using these needs as the basis for a solution, a prototype system using Skimmer Technology was developed in approximately four weeks. Within eight weeks, the initial production system was running delivering a dozen customer reports to service representatives and their managers by 9 a.m. across four time zones. A Skimmer Technology solution extracted information from all sources, correlated orders in all systems, validated the data for completeness, and presented it in a series of optimized spreadsheets. Since spreadsheets were standard on every desktop and used widely, training needed for the new tool was very minimal. Even newly-hired representatives had sufficient spreadsheet training to immediately use the information. Filtering and sorting tools allowed representatives and their managers to isolate information based on any column in the report. Managers could also see which people were assigned to each troubled order, allowing them to monitor progress and balance work loads.

Within weeks, backlogs were eliminated, customer frustration reduced, and workloads normalized. Processes were streamlined and efficiencies increased. Within two months, overtime demands were reduced significantly and personnel turnover dropped. Thousands of hours (and millions of dollars) of overtime were eliminated.

Conclusion

By using a business information integration approach, an enormously expensive problem was solved in a very short time for a fraction of the cost of software enhancements to the underlying IT systems. This approach has worked time and again at this same customer site, enabling them to address their own bottlenecks and problems using office automation-based tools.