UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Developing and implementing industrial engineering methods for process improvement at Telus communications Mojica, Tomas 2004

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-ubc_2004-0276.pdf [ 5.79MB ]
Metadata
JSON: 831-1.0091605.json
JSON-LD: 831-1.0091605-ld.json
RDF/XML (Pretty): 831-1.0091605-rdf.xml
RDF/JSON: 831-1.0091605-rdf.json
Turtle: 831-1.0091605-turtle.txt
N-Triples: 831-1.0091605-rdf-ntriples.txt
Original Record: 831-1.0091605-source.json
Full Text
831-1.0091605-fulltext.txt
Citation
831-1.0091605.ris

Full Text

DEVELOPING AND IMPLEMENTING INDUSTRIAL ENGINEERING METHODS FOR PROCESS IMPROVEMENT AT TELUS COMMUNICATIONS by TOMAS MOJICA B.ENG. in Mechanical Engineering, University of Victoria, 2000 A THESIS SUBMITTED IN PARTIAL FULFILMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE IN BUSINESS ADMINISTRATION in y THE FACULTY OF GRADUATE STUDIES Faculty of Commerce and Business Administration We accept this thesis as conforming to the required standard THE UNIVERSITY OF BRITISH COLUMBIA February 2004 © Tomas Mojica Library Authorization In presenting this thesis in partial fulfillment of the requirements for an advanced degree at the University of British Columbia, I agree that the Library shall make it freely available for reference and study. I further agree that permission for extensive copying of this thesis for scholarly purposes may be granted by the head of my department or by his or her representatives. It is understood that copying or publication of this thesis for financial gain shall not be allowed without my written permission. Name of Author (please print) Date (dd/mm/yyyy) Title of Thesis: (#J#Uffl* ^ Degree: /{£<L ^i£?tte&5 / ^ ^ / ^ / o 7 ^ / Y e a r : -ZO£>^ Department of fa/M/Mt ( ^ O M ^ S&ttfX?/ ^^67^^) The University of British Columbia Vancouver, BC Canada ABSTRACT T E L U S , a large Canadian telecommunications company primarily based in Western Canada, provides a full range of telecommunications products and services including data, Internet protocol (IP), voice and mobile wireless services. Every month T E L U S processes high volumes of customer orders either for new service or changes in existing service. Within T E L U S , the Assignment and Activation group processes all orders and is responsible for changes in the mainframe computers and switches as well as coordination with field service representatives that actually perform physical installations of and changes to customer equipment. The challenges faced by the order processing center include difficulty meeting current throughput and lead time requirements, as well as uncertainty regarding the metrics used for quality and process measurement. Further, increased competition in the telecommunications industry has pressured T E L U S to cut costs, resulting a major workforce reduction and widespread process and service reorganization. This thesis describes the development and application of simulation to study the Assignment and Activation group. The data analysis and model development procedure is outlined and results are discussed. Although simulation model development was hindered by difficulties collecting process data, the model building and data analysis process helped identify several opportunities for improvement. The steps required to continue developing the simulation, therefore enabling more detailed questions about the process to be evaluated, are also outlined. Based on the simulation analysis it is recommended that better data collection be implemented to measure key metrics, especially processing time distributions. Putting the uncertainty in the confidence level of the processing estimates aside, this study found that improving the Auto Front End Assignable or the exception rates would have a negligible effect on throughput if the processing times are close to average. In addition, shifting the days out ahead by three days resulted in a 3% increase in on-time completions. Finally in most of the scenarios evaluated, the operator utilization appeared unrealistically high indicating a general staff shortage. TABLE OF CONTENTS ABSTRACT II TABLE OF CONTENTS Ill LIST OF TABLES VI LIST OF FIGURES VII LIST OF FIGURES VII ACKNOWLEDGEMENTS VIII 1 INTRODUCTION 1 1.1 T E L U S B A C K G R O U N D 1 1.2 T H E A S S I G N M E N T A N D A C T I V A T I O N S G R O U P ' S R O L E WITHIN T E L U S 1 1.3 P R O B L E M S WITHIN A S G / A C T 2 1.4 P R O J E C T O V E R V I E W 2 2 ASG/ACT PROCESS MAPPING AND DESCRIPTION 4 2.1 O V E R V I E W O F A S G / A C T P R O C E S S 4 2 . 2 D E T A I L E D P R O C E S S M A P 4 2 .2 .1 Call Processing 4 2 . 2 . 2 Email Processing 5 2 . 2 . 3 Order Processing 5 2 . 3 R E S O U R C E A L L O C A T I O N A N D O P E R A T I N G H O U R S 5 2 . 4 P R O C E S S M E T R I C S 7 2.4 .1 Days Out 7 2 . 4 . 2 Due Dates Met 7 2 . 5 P R O C E S S P A R A M E T E R DEFINITION 7 2.5 .1 Percent A F E A 7 2 . 5 . 2 Exceptions 7 2 . 5 . 3 Rework and New Requests 8 2 . 5 . 4 Orders Requiring Manual Assignment vs. Activation 8 3 LITERATURE REVIEW 9 4 DATA ANALYSIS 10 4.1 A R R I V A L DISTRIBUTIONS E S T I M A T I O N 1 0 4 .1 .1 Call Arrival Analysis 1 0 4 . 1 . 2 Email Arrival Analysis 11 4 . 1 . 3 Order Arrival Estimation 1 2 4 . 2 P R O C E S S I N G T I M E ESTIMATION 1 2 4 . 3 P R O C E S S P A R A M E T E R E S T I M A T I O N 1 3 4 .3 .1 Percent A F E A 1 3 4 . 3 . 2 Exception Occurrence Analysis 1 3 4 . 3 . 3 Rework and New Requests Occurrence Analysis 1 4 4 . 3 . 4 Assignment vs. Activation Occurrence Estimation 1 4 4 . 4 O R D E R P A R A M E T E R S E S T I M A T I O N 1 4 4 .4 .1 Due Date Distribution Analysis 1 4 4 . 4 . 2 Install Type Analysis 1 5 5 SIMULATION 16 5.1 INTRODUCTION TO S I M U L A T I O N 1 6 5 .2 S I M U L A T I O N M E T H O D O V E R V I E W 1 6 5.3 A S G / A C T S I M U L A T I O N ' . . 1 6 5.3.1 Feature Overview 1 7 5 . 3 . 2 Animation 1 8 5.4 V A L I D A T I O N R E Q U I R E M E N T S 1 8 6 RESULTS 19 6.1 V A L I D A T I O N C H A L L E N G E S 1 9 6 .2 S I M U L A T I O N O U T P U T 2 0 6.2.1 Effect of Percent A F E A on Throughput 2 0 6 .2 .2 Effect of Percent Exceptions on Throughput 2 1 6 . 2 . 3 Effect of Days Out on On-Time Completions 2 1 6 .2 .4 Effect of Volume on Operator Utilization 2 1 6 .3 D A T A R E Q U I R E D TO U P G R A D E T H E S I M U L A T I O N 2 2 6.3.1 Arrival Data 2 2 6 .3 .1 .1 Calls 2 2 6 . 3 . 1 . 2 Email 2 2 6 . 3 . 1 . 3 Orders 2 3 6 . 3 . 2 Processing Time Data 2 3 6 .3 .2 .1 Cal ls '. 2 3 6 . 3 . 2 . 2 Email 2 3 6 . 3 . 2 . 3 Orders 2 3 6 . 3 . 2 . 4 Exceptions 2 3 6 . 3 . 3 Process Parameters 2 4 6 .3 .3 .1 Exception Occurrence Data 2 4 6 . 3 . 3 . 2 Rework and New Requests Occurrence Data 2 4 6 . 3 . 4 Order Parameters 2 4 7 CONCLUSIONS 25 8 RECOMMENDATIONS 26 9 FUTURE WORK 27 9.1 U P G R A D E S I M U L A T I O N WITH I M P R O V E D D A T A 2 7 9 .2 U P D A T E S I M U L A T I O N TO I N C L U D E O T H E R A S G / A C T P R O C E S S E S 2 7 9.2.1 Potential Processes to Add 2 7 9 .2 .1 .1 L Y N X (Trouble Analysis System) 2 7 9 . 2 . 1 . 2 Local Number Portability 2 7 9 . 2 . 1 . 3 Centrex 2 7 9 .3 S T U D Y PRIORITIZATION E F F E C T S O N T H E FW B U F F E R 2 8 9.3 .1 Expanding the Simulation to Model the FW Buffer 2 8 9 . 3 . 2 Additional Data Requirements 2 8 9 . 3 . 3 Current Work Prioritization Rules 2 8 9 . 3 . 4 Developing Alternative Work Prioritization Rules 2 8 9 .4 S T U D Y S C H E D U L I N G E F F E C T S O N A S G / A C T 2 9 9.4.1 Current Scheduling Rules 2 9 9 . 4 . 2 Proposed Alternative Scheduling Rules 2 9 9 . 4 . 3 Evaluating Scheduling Changes with Simulation 3 0 DAYS OUT AND THROUGHPUT WOULD STILL BE RELEVANT METRICS, HOWEVER IT WOULD BE IMPORTANT TO INCLUDE OPERATOR UTILIZATION (ESPECIALLY DURING NON-PEAK HOURS) AND THE NUMBER OF LATE ORDERS OCCURRING FOR EACH CONFIGURATION 30 GLOSSARY 31 REFERENCES 33 C I T E D R E F E R E N C E S 3 3 G E N E R A L R E F E R E N C E S 3 3 APPENDIX: ADDITIONAL RECOMMENDATIONS 34 B A C K G R O U N D 3 4 N O N - D O A B L E W O R K A N A L Y S I S 3 4 M I S S E D C O M M I T M E N T S 3 7 QUALITATIVE R E C O M M E N D A T I O N S 3 7 Communication 3 7 Training 3 7 Documentation Control 3 8 Task Prioritization 3 8 Demand Input on New Product Offerings 3 8 M E T R I C R E C O M M E N D A T I O N S 3 8 V LIST OF TABLES Table 1 Typical Staffing Requirements for A S G / A C T 6 Table 2 Average Daily Order Volumes for A S G / A C T 12 Table 3 Average Task Processing Time Data 13 Table 4 Percent A F E A for January to April 2003 13 Table 5 Percent of Daily Orders Resulting in Exceptions 14 Table 6 Email Rework and New Request Occurrence Summary 14 Table 7 Order Install Types for Q2 2003 15 Table 8 Recommended Metrics for Improving Simulation Model 26 Table A1 Recommended Metrics and Estimated Benefits 39 LIST OF FIGURES Figure 1 Typical Order Flow Through T E L U S 1 Figure 2 Top Level Process Map of A S G / A C T 4 Figure 3 Detailed A S G / A C T Process Map 5 Figure 4 A R E N A Input Analyzer Output Distribution: F S R Call Arrival 10 Figure 5 A R E N A Input Analyzer Output Distribution: Email Arrival at Assignment Inbox 11 . Figure 6 Order Due Date Distribution for June 2003 15 Figure 7 A S G / A C T Simulation Model Animation 17 Figure 8 Throughput vs. Percent A F E A 18 Figure 9 Throughput vs. Percent Exceptions ...20 Figure 10 Percent On-Time Completions vs. Days Out 20 Figure 11 TNW Operator Utilization vs. Volume 21 Figure 12 TNW Operator Utilization vs. Volume 22 Figure A1 Non-Doable Work Summary Chart 34 Figure A2 Modified Non-Doable Work Summary Chart 35 Figure A3 Pareto Chart for Weekly Non-Doable Work 35 Figure A4 Time Series Chart for Incorrect RIT - Incorrect Use 36 Figure A5 IMR Control Chart for Weekly Errors 36 ACKNOWLEDGEMENTS This thesis would not have been possible without the support and cooperation of the people at T E L U S and the C O E . I would like to thank all of those who helped with the development and analysis of this project. In particular I would like to thank Professor Tom McCormick for his guidance both with the project and thesis. I thank John Wiseman for his support in championing this project within T E L U S and Sandy Renaud who always answered all of my questions with a smile and helped me understand the Assignment and Activation process. On a more personal note I would like to acknowledge my family's support and understanding throughout this endeavor: thank you AN and Adey. "with God all things are possible" Matthew 19:26 viii 1 INTRODUCTION 1.1 TELUS Background In 1998 British Columbia's BC T E L E C O M and Alberta's T E L U S Corporation merged to form the largest telecommunications company in western Canada, T E L U S Communications Inc. (TELUS). Before the union the companies had operated in their respective provinces for nearly a century. Today T E L U S is the second largest telecommunications company in Canada, providing a full range of telecommunications products and services including data, Internet protocol (IP), voice and mobile wireless services, connecting Canadians to the world. Although T E L U S ' s historical core competency was providing land based telephone service, T E L U S ' s strategic emphasis has shifted to the rapidly expanding wireless and IP market. In the past T E L U S essentially held the monopoly for phone service in B C and AB , however it is now facing increasing competition both in terms of local service and long distance. Further, T E L U S ' s relatively recent addition of Internet and wireless service provisioning are part of a highly competitive market in Canada. This competitive change has created pressure at T E L U S to cut costs and resulted in a major workforce reduction and widespread process and service reorganization. 1.2 The Assignment and Activations Group's Role within TELUS Every day the Assignment and Activations Group (ASG/ACT) handles thousands of orders, and hundreds of order-related calls and emails. Most orders are delivered via T E L U S ' s computerized system, T E L U S National Workflow (TNW), and are Auto Front End Assignable (AFEA). This means that no manual work needs to be performed by the A S G / A C T operators. Non-AFEA orders, phone calls and email consume the bulk of an A S G / A C T operator's time. As T E L U S continues to offer new services and bundle features into different packages, a decreasing number of these new offerings can be automatically assigned, so the number of manual orders that need to be processed by A S G / A C T is increasing. Clearly T E L U S should try to increase the percentage of A F E A orders in order to reduce staffing requirements, but it has become increasingly difficult to offer new services alongside T E L U S ' s older equipment. When telephone customers order new products or request changes to their service, the ensuing service order flows through several major T E L U S business units depending on the type of work the order represents. After a customer contacts the Customer Service Representatives (CSR), either in one of the T E L U S retail stores or through the call center, the C S R generates a service order. The service order flows electronically to A S G / A C T , which is responsible for assigning and activating orders. If the change required entails changing a software configuration, as is the case with many calling features, the work is completed within A S G / A C T . If the order requires physical changes to a customer's equipment or premises it is passed on to the Dispatch Management Center (DMC), which schedules the work for the field service group who then complete the order. Figure 1 shows a high-level view of how orders flow through A S G / A C T . Customer Service ASG/ACT Field Service Order Complete Figure 1 Typical Order Flow Through TELUS 1 Orders are classified into three major work types based on the work required to execute them; Software orders (SW), Rack Work (RW) and Field Work (FW). All orders require assignment, which consists of setting up the required changes in TELUS ' s mainframe computers to occur at the specified time. Order assignment essentially results in a batch file that is held until the appropriate time and then run through the mainframe computer, at which time the order is activated and the changes associated with the order take effect. Manual Activation is only required for certain S W orders, in cases where changes have to be made that cannot be executed via a batch file, or in the case of an exception (see Section 2.5.2). RW orders require a physical change to be made at one of the Central Offices (CO). In this case, a worker is sent to the C O and a physical change is made in the wiring that connects a customer to the T E L U S system. FW orders require a Field Service Representative (FSR) to go to the customer's location and make a physical change to their internal or external telephone equipment. 1.3 Problems within A S G / A C T Currently there are deficiencies in evaluating whether or not the required equipment is in place when the order is placed. Work orders are processed in a priority sequence based on the due date and the lead-time required. The lead time required is one day for S W orders, two days for RW and three days for FW. Often the problem of insufficient equipment is only noticed when the installation is in progress. If the equipment cannot be sourced and installed quickly, either the customer does not get service when planned or overtime must be put in to meet the desired service date. Additionally, the quality assurance processes regarding customer fulfillment need to be reviewed and assessed. Currently, the processes are structured in such a way that T E L U S assumes that customers are satisfied if they don't call to complain. Recently T E L U S has undergone a large work force reduction; this has had a major impact on the A S G / A C T process. Currently managers are struggling to balance all the demands put on the process and complete work on time. This effect is especially noticeable with F W orders. These orders require substantial co-ordination after assignment; clerks in the DMC ensure that orders are complete and assigned before releasing them to the F S R s . In terms of FW, A S G / A C T has become a bottleneck. Increasingly, FW orders are not released soon enough for timely completion. This has made the DMC's scheduling job more challenging as well as resulting in increased idle time for the F S R s who have a difficult time finding enough work to stay busy. Since F S R s are the highest paid workers idle time for them is highly undesirable. 1.4 Project Overview The Center for Operations Excellence (COE) at the University of British Columbia's (UBC) Sauder School of Business was contracted to help improve operations A S G / A C T . This project's goal was to make it possible for T E L U S to enhance A S G / A C T performance. Our approach started with meeting the various groups and managers within A S G / A C T and observing the processes. Meetings were also scheduled with A S G / A C T ' s suppliers and downstream customers. An iterative procedure was used to develop and verify detailed process maps that captured the workflow through A S G / A C T . In addition, the C O E accessed and analyzed performance metric data available through TELUS ' s intranet. Once the C O E thoroughly understood A S G / A C T , analysts and in-house experts discussed how operations research could best add value and help enhance A S G / A C T . Simulation was chosen as the best method to help analyze A S G / A C T and suggest and evaluate potential improvements. This thesis documents the simulation model's development and results, however during the course of the project other analyses and investigations led to recommendations regarding metrics and data analysis as well as qualitative recommendations. These are detailed in the Appendix: Additional Recommendations. After the introduction in Section 1, Section 2 begins with a detailed description of A S G / A C T and shows how work progresses through the process. Section 3 provides an overview of the research 2 that has been performed with respect to call centers and improving their operation via simulation Section 4 explains how the A S G / A C T data was analyzed and changed into inputs for Section 5, which outlines the development of the simulation model. Simulation results are reviewed in Section 6, followed by conclusions in Section 7 and recommendations in Section 8. Finally Section 9 outlines future work that should be undertaken to add more features to the simulation and provide more insight to the A S G / A C T process. 3 2 ASG/ACT PROCESS MAPPING AND DESCRIPTION 2.1 Overview of ASG/ACT Process Figure 2 shows a black box model of A S G / A C T . Some of the major inputs include computer systems and databases that deliver and track orders, operators that complete all of the manual work, training and metrics for improving and measuring performance and the fluctuation in demand based on factors such as month end and season. The internal customer requirements include order assignment and activation, record keeping and technical help for A S G / A C T ' s partner groups. The process's major resources are the operators assigned to completing the orders; this essentially consists of a person sitting at a desk in front of a computer terminal where all of the actual work on the orders is completed. Although the A S G / A C T group contains a few small units that are responsible for other services, this study focused on the areas where most resources and order volume were being utilized. 2.2 Detailed Process Map Figure 3 shows a detailed process map of A S G / A C T . Essentially the majority of the work performed within A S G / A C T originates from three major sources: phone calls, email and T E L U S National Workflow (TNW, which is specialized order delivery and tracking software)- All orders passing through A S G / A C T have an associated record in TNW that contains information about the requested work. Calls and email associated with a pending order within TNW usually result in its completion, unless more information is needed. A F E A orders flowing through TNW are held in a virtual pen until their scheduled completion time when they are released to the switch. The switch reads and executes the changes required at which point the order is activated (completed). Manual orders may either require assignment or activation or both. Orders are assigned when they are configured properly to run through the switch; they are only activated once they have passed the switch. A detailed explanation of the other parameters follows below. 2.2.1 Call Processing Calls come in to A S G / A C T from two major users; F S R s and retail stores. The calls are routed through call center software into queues. Operators logged into the queues from their desks answer calls on a first come first serve basis. The retail calls originate from C S R s in T E L U S ' s retail stores. Their requests represent orders for customers waiting in the store. In comparison the F S R calls are from workers on site at the customer's premises who need immediate help to complete orders. Due to a relative shortage of call operators, all calls coming into the center are for urgently pressing matters; there are guidelines for the types of situations when A S G / A C T can be contacted directly by phone. If the matter can wait a few hours, callers are instructed to email their questions or requests to A S G / A C T instead. Process Inputs • Operators Metrics Training ' Computer Systems & Databases Demand Fluctuation Assignment & Activation ^ Process Outputs Order Assignment Order Activation Technical Support Accurate Records Figure 2 Top Level Process Map of ASG/ACT 4 2.2.2 Email Processing Email requests come into A S G / A C T through two major email inboxes, which act as queues. Operators are able to see the subject of each request and use the information to prioritize the tasks. Email operators are often assigned to work on a specific type of order within each queue, e.g. "rush" orders. In addition to lower priority requests and questions from retail and field service, the greater part of the email originates from C S R s at TELUS ' s customer service call centers. Phone Calls Email ASG & ADSL email New or x :eworkV Yes Orders TNW Remove from Order Queue Process Call No Remove from Order Queue Process Email No Yes AFEA Order Holding Pen / \ Yes / \ Yes ManualX. Manual ASG Processing / A u t o X A S G ? / - ^ ^ \ A C T ? / Yes No Manual ASG Processing Order Complete Exceptions Figure 3 Detailed ASG/ACT Process Map 2.2.3 Order Processing The vast majority of manual orders processed in A S G / A C T flow through TNW (AFEA orders flow directly to the mainframe and are not monitored unless there are problems; see Section 2.5.2 below). Operators logged into the TNW queue are able to pick orders, work them in the required data system, and then complete them within TNW. TNW was originally implemented as a means of tracking orders and determining their status at any given time throughout the process. Recent improvements such as the G O P H E R software tool (which aids manual order assignment by automatically opening forms, presenting the operator with required information, and eliminating repetitive tasks) have greatly increased order-processing time within TNW. Many formerly manual orders have been either partially or fully automated (order types that are successfully automated via G O P H E R are eventually removed from TNW and become A F E A orders). 2.3 Resource Allocation and Operating Hours In the past operators were assigned by area of expertise and job function, but the recent downsizing has made it necessary for all operators to be cross-trained in all functions. This has simplified scheduling and operator requirements, but has created some difficulty since keeping everyone trained and current in all tasks requires job rotation. A S G / A C T operates from 7:00 A M to 8:00 P M on weekdays, 7:00 A M to 5:00 P M Saturdays and 8:00 A M to 5:00 P M on Sundays. In 5 addition to job rotation scheduling, union requirements make the regular rotation of operator through all shifts necessary. Operators are assigned to specific tasks during their shifts with secondary tasks in case of a lull in their primary activity. During busy times or when excessive volumes build up in particular areas, i.e. phone lines, supervisors may move staff to meet processing needs. At particularly busy times these shifts may occur several times a day. Table 1 shows typical staffing requirements for A S G / A C T . Table 1 Typical Staffing Requirements for ASG/ACT Duty Minimum Staff Description/DetaiIs Day Shifts PHONES 8 EXCEPTIONS 3 EMAIL 5 1 ea. TD & interconnect emails, SER & HOET LNP 2 Phones & SOTS, move to Calgary by Aug PRINTER/START STOP/PIC -| LYNX 2 TNW SHIFT 1 1 Clean up simple pots TNW SHIFT 2 1 Clean up complex pots TNW SHIFT 3 -| Clean up ADSL TNW SHIFT 8 1 Current enter SDAS DSW 1 Delayed switch work orders GOPHER SW 5 GOPHER RW 6 GOPHER FW 6 GOPHER DSL & ADSL EM i DSL filter in Gopher for SW, RW & FW Evening Shifts: total 8 - Everyone takes phone calls for entire shift 12:00-8:00 LYNX -| EXCEPTIONS -I GOPHER DSL & ADSL EM 1 DSL filter in Gopher for SW, RW & FW EMAIL 2 GOPHER 3 Saturday Shifts: total 10 - Everyone takes phone calls for entire shift LYNX 1 EXCEPTIONS 2 LNP -I Phones & SOTS, Gopher otherwise Gopher DSL & ADSL EM 1 DSL filter in Gopher for SW, RW & FW EMAIL 2 Gopher 3 Sunday & Holiday shifts: total 8 - Everyone takes phone calls for entire shift LYNX •! EXCEPTIONS 2 LNP -j Phones & SOTS, Gopher otherwise Gopher DSL & ADSL EM -) DSL filter in Gopher for SW, RW & FW EMAIL 1 Gopher 2 6 2.4 Process Metrics T E L U S uses a variety of metrics to track performance within A S G / A C T . It could be argued that there are too many different measurements being used to monitor the process. Instead of going into excessive detail and on all the metrics, we shall focus on two critical ones. 2.4.1 Days Out In order to complete orders on time, work within A S G / A C T is started some days before the due date. A standard time allowance is specified for orders to be processed and either completed or passed on to its partner groups. This quasi lead-time is known as "days out"; it indicates how far ahead orders are worked. For example, S W orders are started one day ahead of their due date to ensure timely completion. Similarly RW and FW orders use two and three days out respectively. Days out includes an allowance for recovery or correction of problem orders, although T E L U S ' s ability to meet customer requirements when a problem develops with an order largely depends upon when the problem is detected. Every morning before A S G / A C T opens, the days out status is checked. If a particular type of order is behind, resources may be moved. The metric is also sporadically checked throughout the day by supervisors to get up to date pictures of the situation. Since orders arrive throughout the day, the days out status can change quickly. 2.4.2 Due Dates Met One of the metrics commonly used to track on time orders is due dates met. This is a percentage measurement of the total orders that were completed on time in a given day. Typically this number is very high, between 96% and 98%. Although these numbers may seem acceptable, the relatively small percentage of missed orders actually is a sizeable problem, when the number of orders processes each day is taken into account, e.g. if on average 180,000 orders pass through A S G / A C T every month and 2% do not get completed on time, roughly 3600 customers do not get service when they anticipated it. Given the increasingly competitive market T E L U S faces, it can ill-afford to lose existing customers. 2.5 Process Parameter Definition As shown in Figure 3, there are several important parameters that govern the volumes that pass through each channel in A S G / A C T . These are percent A F E A , exceptions, rework and new requests and assignment vs. activation. 2.5.1 Percent A F E A Roughly 60% of the orders entering A S G / A C T are A F E A . This means that they require no manual assignment and do not show up in TNW although if necessary they can be accessed and changed through the old mainframe interface system, Facilities Management System (FMS). Clearly T E L U S ' s ability to increase % A F E A and therefore the number of automatically processed orders has a major impact on the amount of manual work required by A S G / A C T . The problem with increasing % A F E A is that whereas at one time T E L U S ' s order automation was very good, it is now outdated. With the continuing increase in new calling features and bundles it has become increasingly difficult for T E L U S ' s IT group to make improvements in the proportion of A F E A orders. 2.5.2 Exceptions After orders have been assigned either manually or automatically they are batched in an electronic queue by their due dates. When they are due they are released to the switch where the changes represented by the order are made within the mainframe (activation). If the switch is 7 successful in reading and executing the change the order is completed. In five to 10 percent of the cases the switch is unable to process the request and the order "falls out"; this is referred to as an exception. Exceptions represent a substantial amount of rework. Operators must look at each exception, determine what went wrong and then fix the problem and resubmit the order manually (manual activation). This process tends to require a great deal of knowledge and experience with the mainframe as well as some detective skills. 2.5.3 Rework and New Requests Unlike orders processed through TNW, calls and email fall into three major categories, existing orders, new requests and rework. Phone and email related to existing orders are needed in complicated situations when more information than can be sent through T N W is needed to complete the work or when circumstances require special treatment for the order. Through the process of answering the email or call and addressing the issue, the associated order in TNW is completed. In addition to inquiries related to existing work, calls and emails are fielded regarding completely new work requests (usually to fix a recurring or complicated problem) and rework, e.g. when the order was not completed properly the first time. 2.5.4 Orders Requiring Manual Assignment vs. Activation Most manual orders that pass through the system require only manual assignment, but a small percentage require either manual activation or both. This usually occurs in cases where the order is very complicated or requires special changes. As outlined above all exceptions also require manual activation. 8 3 LITERATURE REVIEW Call centers have been a focus area in academic and industrial research for almost a century [1], but the level of sophistication in the approaches used to improve their performance has increased substantially over the last twenty years. Historically, the main focus has been on forecasting demand and then determining adequate or optimal staffing levels and schedules [2], [3], [4], [5] to meet a required service level. However, simulation has been used extensively in call center modeling; many simulation software packages include specialized toolkits for this purpose [6]. In the late 1970's AT&T started work on a call processing simulator that eventually developed into a model for analyzing call centers [7]. It was eventually turned into a consulting tool used to evaluate and optimize external client's processes. Traditionally, most of this simulation work has focused on call centers dealing with calls only, as opposed to other work delivery methods such as email or via a computer system. Hence, the variation in processing times is usually a function of skill level and the variation of complexity represented by the expected calls. However, with the increasing use of email and web based tools for ordering, some simulation software companies have begun to provide means for incorporating these additional work streams. In the situation described in this thesis, commercial software was used to build a detailed model of T E L U S ' s A S G / A C T process. Although the model itself and the ensuing results are specific to T E L U S , the general approach and many of the insights are applicable to a broad variety of similar simulations. In this model, work arrives to the call center via three different paths, phone, email and computer system, and operator skill levels vary both within and across each task type. Generally all the work that passes through the process is connected to and delivered via the computer system, but due to various reasons such as complications and rework, sometimes additional work delivered either by phone or email is required. In this simulation all agents are assumed to be cross-trained so that when the primary queue that they are assigned to is empty they will assist in the completion of tasks in other queues, however research is being done to determine if an optimum mix can be found between dedicated and cross trained operators in a multi skilled environment [8]. 9 4 DATA ANALYSIS Although A S G / A C T had been identified as a problem area and data was being collected on its performance, no analysis had been done with respect to the frequency or pattern that work arrived in or was processed. Traditionally the metrics had emphasized average performance rather than evaluating variation. In terms of process parameters this meant that there was little understanding of how the parameters varied over time. As for order parameters there was no understanding of the variation in due dates or the relative frequencies of install types. Quantification of processing and inter-arrival times would provide options for more detailed and advanced analysis and modeling. In an effort to gain insight to the distributions of these variables existing data was analyzed as follows. 4.1 Arrival Distributions Estimation 4.1.1 Call Arrival Analysis T E L U S uses commercial software to collect data and manage its phone systems and reports are readily available through its intranet. Unfortunately, the information is binned into half hour increments, which makes it more difficult to determine inter arrival times. For each phone line (queue) the information available includes: number of incoming calls, number of abandoned calls, average call time, time and average wait time. Although the operating hours for the call centers remained constant as outlined above, the data is only recorded while at least one operator is logged into the system, hence the amount of data available each day varies substantially. Often operators would either log out at different times or forget entirely (after hour calls are rare). distribution: Beta Expression: -0.5 * 26 * BETA(0.331, 0.372) Square Error: 0.033160 CM Square Test • SuSiber 6£ intervals ;» 4 Degrees of freedom * 1 Test Stat ist ic • 3.7 Corresponding p-value • 0.0562 pate Suamaxy Humjaer 0 f Data Points « 27 Bin Date Value • 0 flax Data Value . » 25 Sample Hean » 11.7 .e Std Dev « 9.94 Figure 4 ARENA Input Analyzer Output Distribution: FSR Call Arrival Data for call arrivals was analyzed using A R E N A ' S input analyzer function. This software tool finds the statistical distribution that most closely fits the data and provides the equation for the distribution. The data was analyzed in half hour increments. From a statistical standpoint the 10 model resulted in a poor fit and had a low p-value, indicating that the model was significantly different from the empirical data. As shown in Figure 4, which shows the input analyzer output graph for the number of calls received every half hour from F S R s , the beta distribution approximated the actual data poorly. However this approach was deemed close enough for a first approximation. Using this method, the following two equations were developed for the number of incoming calls per half hour time segment. Field Service Calls: - 0.5 + 26(BETA (0.331, 0.372)) Retail Calls: - 0.5 + 3(BETA (0.975, 0.842)) 4.1.2 Email Arrival Analysis All the email that arrives to the various mailboxes within A S G / A C T is periodically archived, so we were able to get copies of all the files for the month of June 2003. Since the email file's header contained a time and date stamp, the arrival times were easy to determine. However, a substantial amount of work was required to get the data into a useful format. Using a similar approach as for the call arrival the email arrival patterns were estimated for the two A S G / A C T email inboxes. Figure 5 shows the distribution and fit for arrivals in the B C assignment email inbox. In this case the exponential distribution resulted in the best fit, although again the model significantly differed from the real data. BCAssignment@TELUS.com: - 0.001 + EXPO (4.34) BCADSL@TELUS.com: - 0.001 + EXPO (5.35) • Input Analyzer - [Input3] D i s t r i b u t i o n ; E x p o n e n t i a l . . .. E x p r e s s i o n : - 0 . 0 0 1 + :'EXPO (4.34} Square: E r r o r : 0 .000461 C h i Srjuare T e s t . Number o f i n t e r v a l s Degrees at f reedom - 1 T e s t S t a t i s t i c * 399 C o r r e s p o n d i n g p - v a l u e < 0 .005 JKolmooorov-Smarnov T e s t T e s t S t a t i s t i c = 0 . 2 1 ? C o r r e s p o n d i n g p - v a l u e < 0.01 D a t a Summary dumber o f D a t a P o i n t s - S0S5 Figure 5 ARENA Input Analyzer Output Distribution: Email Arrival at Assignment Inbox 11 4.1.3 Order Arrival Estimation Although T E L U S did have some measurements in place to count the daily number of active and completed orders, there was no way to determine the rate or pattern in which orders arrived. T E L U S ' s information systems group was contacted and tasked with designing a report to capture all orders generated through the C S R order generating software tool, CRIS. Although the report was built it was unable to capture the order creation time, a vital piece of information for building an arrival distribution. Further, our data analysis indicated that most records were removed from the database from which the report was generated within a few days of creation, i.e. fewer records were available the farther back into the past we went. After investigating the situation we found that in order to capture the total daily order volume the report would have to be run every day for the desired period of time, which in our case would ideally be a few months. At this point time and resources became constraints. Since volume data was available through other available reports, it was used to determine daily averages by day of the week. An Analysis of Variance (ANOVA) of the averages for each day of the week indicated that there were no significant differences in volume based on the day of the week. Table 2 shows a summary of the daily volume data. Table 2 Average Daily Order Volumes for ASG/ACT Day Average Order Volume Sunday 5524 Monday 5249 Tuesday 5857 Wednesday 5858 Thursday 6682 Friday 7175 Saturday 6223 4.2 Processing Time Estimation At the start of the project the only data for email, order and exception processing times were old estimates of averages. For the phone calls there was data from the call management software, but because it was binned into half hour segments it was difficult to determine exact call processing times since most of the time there were multiple calls per segment. It would have been ideal to collect detailed data on actual processing times for several operators for each function, but resource constraints prevented detailed data collection. However, A S G / A C T was able to provide updated average processing times by taking one operator at each skill level and having them complete 10 of each of the tasks. These processing times were broken down into three skill levels (strong, medium and weak), which roughly corresponded to operator's experience, e.g. an operator with 10 years experience in A S G / A C T could generally complete tasks more quickly than a recent trainee. Table 3 shows the processing times for these different tasks. Unfortunately, the individual times were not available; it would have been useful to measure the variation in completion times. Although it would be ideal to perform a more in depth study to determine the variation in processing times, this data provided a starting point for analysis. It was interesting to note that for a few of the tasks operators with a strong rating took significantly longer to process a given task on average than operators with a weak or medium rating, e.g. FW, RW, email. This issue was 12 discussed with A S G / A C T management who provided two possible explanations. Either the experienced operators focused on working more complicated orders (which required more time to complete) that inexperienced operators could not complete, or the newer (and more recently trained) operators were more apt to follow new procedures designed to speed order processing. By sitting with operators and observing their work it was clear that experienced staff often knew of several ways to complete tasks. Table 3 Average Task Processing Time Data Average Processing Time (Minutes) Strong Medium Weak Average Worst S W 0.96 2.78 6.41 3.38 6.41 R W 6.09 4.04 6.11 5.41 6.11 FW 19.84 15.29 17.42 17.52 19.84 Phone Calls 6.07 6.37 7.83 6.76 7.83 Email 10.77 6.37 16.46 11.20 16.46 Exceptions 1.96 5.91 11. 5 3.94 11.5 4.3 Process Parameter Estimation 4.3.1 Percent A F E A Percent A F E A is an important parameter within A S G / A C T since it has a major effect on the amount of manual work that is required. Estimates were readily available from existing T E L U S reports. Table 4 shows A F E A percentages for the first four months of 2003. Table 4 Percent AFEA for January to April 2003 Month AFEA % January 54% February 55% March 56% April 67% Average 58% 4.3.2 Exception Occurrence Analysis Exception data was relatively limited. However, there was one report available that summarized total occurrences for user-specifiable periods of time. Although there were no time stamps, the daily percent of orders resulting in exception was available. A N O V A analysis showed that exception rates fell into three distinct groups. On weekdays the average exception rate was roughly four percent, but it climbed to five and then 18 percent on Saturday and Sunday respectively as summarized in Table 5. In order to estimate the exception occurrence pattern, system queries were run one day at half hour intervals. This was able to capture the vast majority of exceptions occurring during a 24-hour period. The data indicated that exceptions occurred in two general modes. The first type of exception resulted from A F E A orders executed early in the morning, between 12:00 and 6:00 A M . This is generally a good time to activate A F E A orders since system resources are less busy and there is a reduced chance of interrupting customer service. Usually these exceptions are not addressed until the first A S G / A C T shift arrives in the morning. The second type of exception 13 occurs during the morning and early afternoon, and these are generally caught and corrected as they occur. Manual activations are checked to make sure the order executes correctly and does not go into exception. Further, during the day A F E A related exceptions are identified and managed by operators assigned to process exceptions. Table 5 Percent of Daily Orders Resulting in Exceptions Day Average % Exceptions Sunday 18 Monday 4 Tuesday 4 Wednesday 4 Thursday 4 Friday 4 Saturday 5 4.3.3 Rework and New Requests Occurrence Analysis In order to estimate the proportion of email that represents new requests or rework, the email received during the month of June 2003 was examined. Since this was time consuming, a sample percentage of the emails in each mailbox was opened and checked to determine if they were requests for new work or rework as opposed to queries or comments related to existing orders. The study of the two major email inboxes in A S G / A C T showed that 68% of the total email received was either for new requests or for rework. Table 6 summarizes this data. Table 6 Email Rework and New Request Occurrence Summary Email Mailbox June Sample % Sample New Requests Existing % Existing Total Total or Rework Orders Orders BC ADSL 1829 9% 168 35 133 79% BC Assignment 6419 7% 430 150 280 65% Weighted Average 68% Unfortunately hard data for rework and new requests arriving via phone calls was not available. However, A S G / A C T management estimated that roughly 20% of the calls into A S G / A C T were either requests for new work or rework. 4.3.4 Assignment vs. Activation Occurrence Estimation Inspection of daily order volume reports from April to June 2003 showed that on average 89% of the manual orders required assignment. The remaining 11% required activation. This ratio remained relatively constant from day to day. 4.4 Order Parameters Estimation 4.4.1 Due Date Distribution Analysis One of the most important features of the orders passing through A S G / A C T is the due date. In order to analyze the distribution of the order due dates, daily summaries with counts for the number of days until an order was due were compiled for Q2 2003, i.e. for all the orders entering A S G / A C T during this period the amount of time until the order was due was tallied. This allowed 14 us to understand how much advance notice orders usually arrive with. Figure 6 shows the typical cumulative distribution of the due date for orders of the three major install types. Compared to the days out (actual lead times) used by A S G / A C T , it is clear that a significant number of orders arrive with substantial advance notice. For example, roughly half of the FW orders that arrive on a given day are not due for at least 14 days, well above the three day standard 1. This indicated that there might be room for substantial improvement in order completion rates if the orders could be processed sooner. Further, this surplus lead-time could also be used to provide customers with preferential pricing based upon the amount of advance notice they provided. As the situation is, it could be argued that T E L U S is currently providing a service that it does not charge for. Figure 6 Order Due Date Distribution for June 2003 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 >30 Days Until Order Due 4.4.2 Install Type Analysis Based on the data from Q2 2003 summarized in Table 7 below, the proportion of order install types is stable from month to month and only varies by a few percentage points. In addition to the three major order types there are several rarely used install types that account for less than 1 % of the total orders. Table 7 Order Install Types for Q2 2003 Install Type SW RW FW April 77% 13% 9% May 80% 11% 9% June 80% 10% 9% Average 79% 11% 9% 1 A s detailed previously F W orders are processed three days out, or three days before they are due. 15 5 SIMULATION 5.1 Introduction to Simulation With simple processes it is usually easy to observe and predict input and output behavior. However when the level of complexity increases it can be difficult to estimate what effect each parameter has on the system as a whole. Simulation is one method for observing the entire process and evaluating the relationship between inputs and outputs. It involves building a mathematical model of a process (usually using software) that behaves like the real system. The advantage is that changes can be evaluated without costly or difficult implementation. The model can help answer "what i f questions about a process. Once the simulation is built and validated it can be run as many times as necessary to check the effects of changes and to build confidence about proposed changes. In order to build a successful simulation, two basic requirements must be met. A model cannot be built without a solid understanding of the process in question, but more importantly sufficiently detailed data must be available. Data is required not only for creating inputs and parameters, but also for model validation, which is the most critical step where model performance is compared to the behavior of the real system. Usually this involves sending the same type of input through the simulation that has been observed with the actual process and ensuring that the outputs of both systems match within an acceptable margin. It is important to note that while simulation can be used to evaluate average scenarios, it can be a much more powerful tool if instead of average input values, distributions of the critical parameters are used. Simulation can evaluate best and worst case scenarios as well as identify their likelihood. This is similar to evaluating the effects of statistical fluctuations, e.g. the simulation can show what the effect is when the slowest operator gets the longest task and how often it is likely to happen. Lastly, the model can be run to evaluate the sensitivity of the system parameters, which is useful when trying to develop a robust process. 5.2 Simulation Method Overview The method used to build a simulation can be broken down into a few basic steps. It's important to decide the model's purpose and clearly identify what parts of the process should be included at the beginning. After the process has been mapped a model is built using software. Next, data for the model parameters and inputs must be collected and analyzed to build distributions for the variables and parameters. Once the model has been configured according to the data analysis results to behave according to the data analysis, it must be validated. This consists of running the model and ensuring that the results mimic the real system. Usually validation is an iterative process since many errors are easier to detect once the model is operational and results can be compared to real data. After a sufficient level of trust has been developed in the simulation, it can be used to compare proposed system changes such as adding resources, improving processing speed or increased incoming volumes. 5.3 ASG/ACT Simulation The A S G / A C T simulation was built using A R E N A (6.0) software 2. The emphasis was on the processes that represented the greatest volumes of work and the most resource requirements. Hence a few of the low volume and smaller tasks performed by A S G / A C T were not included. Since A S G / A C T ' s resource constraints were an issue, this model was built as an aid to help with decisions concerning what parameters should be focused on and how the process should be run. It was thought that this simulation would help understand how variations in inputs like skill level, 2 www.arenasimulation.com 16 percent A F E A , exception rate, staff level, days out, and prioritization affect order throughput time, volume, and resource utilization. In addition, we wanted to see how the bottlenecks moved through the process as different parameters were changed. 5.3.1 Feature Overview The A S G / A C T simulation was assembled using the three linked sub models shown in Figure 7: TNW, email, and phone calls. The largest sub model, TNW, generated orders with due dates and install types according to the distributions discussed in Section 3. Phone Calls Remove from Order Queue Process Call Email Remove from Order Queue Process Email Orders TNW Yes AFEA Order Holding Pen / \ Yes Yes Manuafx A S G T / ^ - ^ Manual ASG Processing _ ^ / / A u t o \ ^ \ A C T ? / Yes No No Manual ASG Processing Order Complete Exceptions Figure 7 Detailed ASG/ACT Process Map Based on the probability of an order being A F E A , the order proceeded either to the switch queue or the manual processing queue where it was released according to days out. The manual orders were released as soon as an operator became available. For the manual orders probabilities outlined above determined whether an order required manual assignment and/or activation. After passing through the switch orders were completed unless they went into exception, which was again determined by the exception rate discussed above. The email submodel used two functions (one for each mailbox) to generate email according to the distributions resulting from the data analysis. The email then proceeded to an inbox queue where it was worked on a First-In-First-Out (FIFO) basis whenever an operator became available. According to the probability determined during analysis an email represented rework or a new request, or was associated with an existing order that was in the pending order queue in the TNW submodel. If the latter case were true, upon email completion the corresponding order was removed from this queue. The phone call sub model was exactly the same as the email sub model, with the exception of the parameter values and processing times. 17 5.3.2 Animation Usually the results from simulation model runs are numerical output collected in tables or graphs, but most simulation software also allows the process to be animated so that the resources and orders can be observed as they move through the process. This allows the user to see how and where queues develop and watch resource utilization. An additional feature is that the simulation speed can be set faster or slower than real time depending on what the observer wants to see. The TNW and phone sections of the A S G / A C T simulation animation are shown in Figure 8. It shows the order queues and totals, information on operator utilization and date and time information. In addition the animation indicates what each operator is currently doing. When operators are busy they can be seen sitting at their desks, which turn red. If they are idle the desks turn brown. Empty desks indicate that an operator is not scheduled, whereas if there are items on the desk but the operator is not there they are on break. Email and exception operators were animated the same way. March 31 2003 nday 07:16:52 4 2 2 4 I Orders Created Orders Processed T N W Operators 2 0 2 Orders Processed Order Queue Operators Scheduled Operators Busy M D D D D D D WWU ODD WU U D UWW DDDDDDDD W Phone Open 0 Calls Processed Queue Operators Scheduled Operators Busy D • D D Figure 8 ASG/ACT Simulation Model Animation 5.4 Validation Requirements Since every simulation model is unique, validation requirements vary, but ultimately the level of trust in a model's results hinges on the simulation's ability to emulate the actual process. At the most basic level the A S G / A C T simulation's steady state order throughput needed to match real output volumes while the model operated with the "as-is" configuration. In addition, the call and email quantities and queues needed to agree with real data within reason. Further signs of model validity include observing queues and operator utilizations that agreed with real system observations. 18 6 RESULTS 6.1 Validation Challenges The simulation was run for a 30-day period to reach steady state. This was necessary because when the model starts, there are no orders, email or exceptions already in the system. Allowing the orders to build up for a month represents the actual daily A S G / A C T process more closely since there are always orders waiting to be completed for future work. After the warm up period, the model was run five times consecutively and the averages of the throughput and utilization statistics were used. There were significant problems validating the model using the input distributions modeled in Section 3.1 and the given staffing schedule. The volume of work generated by the model was much lower than expected for orders, email and calls. This resulted in throughputs about 30% less than expected. The input data was re-analyzed and changes were made to simplify the model inputs, but low throughput volume remained a problem. In addition, the staff schedules appeared to have too much capacity: there were high idle rates. Eventually the root cause was identified as a low initial input volume and the problem was corrected by using an input based on the monthly volume divided by the amount of time A S G / A C T was open during the month. This seemed to solve the volume and throughput problem. However the operator utilization rates were still lower than expected: our observations of the A S G / A C T process indicated that all areas were busy all the time and overtime was the only way to "make the numbers". It was probably a combination of several issues that resulted in the less-than-ideal model validation. First and foremost, not having a clear picture of the actual processing times led to uncertainty for a major model feature. Based on the data provided there are still major questions to be answered about how skill level affects processing times and why more experienced operators sometimes take longer to complete a task. The problems encountered with the input distributions that were developed indicate that these analyses need to be run again on larger and more current data sets. Another issue was the parameter estimates; there is strong evidence to suggest that given the monthly and weekly fluctuations in service and install type, parameters such as percent A F E A fluctuate as well. The exceptions analysis showed that the rate of occurrence depended upon the time of day and the volume depended on the day of the week. In addition there were several staffing issues confounding the validation process. In terms of operator deployment, task prioritization had already been identified as a weak spot. Although there were some guidelines for assigning people based on the relative completion levels of the different types of tasks, line managers used a high level of subjective judgment. Although this was difficult to build into the model, the effects in terms of throughput variation may well have been major. Similarly it was difficult to develop clear rules for allowing overtime, so it was left out of the model. The model also assumed perfect cooperation. Although operators were assigned to specific functions, if they were idle and had no work to do they would proceed to the next area and help with other tasks. Although in the real situation operators are often assigned to more than one area, it is doubtful that they are as efficient when switching tasks as the model's operators. It would have been ideal to have access to more data that would allow updating the model, because this would have enabled us to provide more detailed answers. However, aside from these limitations, this model was certainly capable of producing useful information and we were able to validate the model behavior at an overall process level in terms of general volumes and throughput. Due to the uncertainty in the processing times two sub cases were run for each scenario: one with average processing times (across all operators), and one with the worst case 19 processing times. These two variations were used to establish upper and lower performance bounds. 6.2 Simulation Output 6.2.1 Effect of Percent A F E A on Throughput Figure 9 Throughput vs. Percent AFEA 175 140 -I , , 65 75 85 % AFEA The first scenario evaluated was aimed at determining the effect of percent A F E A on A S G / A C T ' s throughput. For this scenario evaluation the monthly throughput was held constant and the A F E A rate was varied. As Figure 9 shows if most of the A S G / A C T operators are performing close to the average, there are no significant gains to be had by focusing on improving the A F E A rate. If on the other hand there is a great deal of variation in order processing time or a significant number of the operators are performing closer to the worst case scenario, improving the A F E A rate would be beneficial. The next question is clearly "how confident are we that operators are performing at the average level?" Figure 10 Throughput vs. Percent Exceptions 175 125-1 , , , , , , , 1 0 2 4 6 8 10 12 14 16 % Exceptions 2 0 6.2.2 Effect of Percent Exceptions on Throughput Next, the exception rate's effect on order throughput was evaluated. Again, as indicated in Figure 10, the exception rate's importance hinges upon A S G / A C T ' s general processing speed. Putting aside the processing speed (average and variation) issue, it would seem, based on the exception rates derived in the analysis above, that small reductions in the exception rate would not result in major throughput gains. 6.2.3 Effect of Days Out on On-Time Completions Figure 11 Percent On-Time Completions vs. Days Out c o 0> Q. 85 • E o u <]> : - 80 • -Average Processing Times Worst Case Processing Times 3 4 5 6 7 Days Out (SW; RW & FW Offset by 2 & 3 Days) Figure 11 shows the effect of varying days out on percent on-time completions. In this scenario analysis, the relative difference in days out was kept constant, i.e. FW always was one day further out than RW and RW was always one day farther out than S W . In the worst-case scenario, no effect is noticeable, probably because under these processing times the operators are not able to meet current demands, let alone get ahead. However, based on the average processing times it does appear that shifting the days out by three days, i.e. S W is four days out, RW is five days out, and F W is six days out, does provide about a three percent improvement in on-time completions. Again, it would be interesting to see what the effect of the true processing speed variation would be on this graph. 6.2.4 Effect of Volume on Operator Utilization Four scenarios were prepared for evaluating the effect of work volumes on operator utilization, one for each major function, i.e. orders (via TNW), email, calls and exceptions. Figure 12 shows the graph for TNW operators. The data showed the same pattern for all of the major functions but it was more pronounced for the order operators. The volume was varied while the ratio between orders, email and calls was kept constant. In these graphs the worst-case line outlines a fundamental problem: utilization is very high. Assuming the average processing times are closely met by the bulk of TNW operators, there still is an unreasonable high utilization rate when volumes increase to 120%. In the case of call and exception operators the gap between these lines was very small and utilization was always high. The email data showed that under the average processing time scenario utilization was already at 80%, which is again high. 21 Theoretically high utilization rates should be possible, however in reality this is never the case. Inevitably operators have tasks that fall outside of the scope of their immediate assignments, e.g. meeting with managers, keeping abreast of work related issues and bulletins etc. Figure 12 TNW Operator Utilization vs. Volume 95,0% - . 55.0% -I , , 1 , , , , 1 1 80% 90% 100% 110% 120% 130% 140% 150% 160% 170% Order Volume (180K = 100%) 6.3 Data Required to Upgrade the Simulation The challenges faced during the validation stage were driven by a lack of detailed enough data; this led to difficulties analyzing and estimating the model inputs. A better understanding of certain inputs and parameters must be developed based upon detailed information in order to improve the simulation's level of validation. Further, the changes that have occurred within the A S G / A C T process during the study indicate that generally all of the analyses should be run again with more current data and if necessary, changes to the model to reflect the new process. The following sections outline the required information and possible approaches for improved analysis. 6.3.1 Arrival Data 6.3.1.1 Calls Since there was already a computerized system in place for managing the phone queues and recording summaries on their use, the data required to build a good distribution is probably available. The two issues that need to be addressed are collecting enough data and finding a reasonable approximation for the distribution of call arrival. Although the first attempt at fitting distributions to the data was unsatisfactory, it is probable that with more data, e.g. at least six months, a pattern would emerge. Even if this was not the case, it is possible that grouping all the data together is not the best approach, i.e. the data needs to be analyzed in specific groupings such as morning, afternoon or day of the week. As a last resort with enough data an empirical distribution could be used to fit the distribution. 6.3.1.2 Email Since all email is collected and archived, there is a high level of potential detail. Although transforming the information into a useful format does require some work, the approach used before could be used again but with more data, e.g. three months worth, to determine the 22 distribution of arrival times. Since this is largely a batch process, it wouldn't take much longer to process three months worth of email than it would to process one month. 6.3.1.3 Orders One of the most important elements of data missing from the simulation was a distribution for order arrivals. Since orders constitute such a large component of A S G / A C T ' s work, not having a stochastic input for order arrival was probably a major contributor to the difficulties with validation. Currently there is no method available to capture the times that orders are created (or arrive) at A S G / A C T . Since this is such a major input for the A S G / A C T process just looking at the order arrival pattern would probably be very useful apart from the ability to improve the simulation. Hence, the development of a dedicated system and/or database query and report is justified. Ideally this type of information would be required for several months in order to observe demand fluctuations based on month end, weekday, etc. 6.3.2 Processing Time Data 6.3.2.1 Calls Since the software used to collect data for the phone system is configured to batch information into half hour bins it has been difficult to use the other detailed information in the available reports to determine processing times. However, there are two possible methods to get call processing time information. The simple method would be to collect data by hand, i.e. design data collection forms that operators fill out. The advantages would be that it would be easy and quick to implement and it could be iteratively improved or changed. Also the data would only need to be collected for a few days and the task could be split among operators to help capture variation. The alternative would be to have the call management software and reports configured to allow users to see individual call information. This would be more useful because it would allow more complex questions to be answered and it probably would provide a better (unbiased) estimate of processing time. In addition, it would accurately allow the contrasting of processing times between users, days and busy periods such as month ends. 6.3.2.2 Email Email processing times would be much more difficult to capture automatically, i.e. using software. Even without considering the implications of multitasking or stopping and starting tasks, there is no way for computer systems to know what particular application (email) a user is focusing on let alone record the time. The best way to capture email processing times would be to implement data collection forms as outlined in Section 5.3.2.1. 6.3.2.3 Orders Technically, some order processing data is available via TNW and G O P H E R , although it isn't possible to capture true order work time if the operator partially works an order and then pauses to complete another task while waiting for information. At best, the start and finish times for the order processing could be recorded. Therefore, collecting data by hand as outlined in Section 5.3.2.1 would be the most feasible and accurate method to determine processing times. 6.3.2.4 Exceptions Data on exception processing times is probably best collected by hand because similar to email and order processing times, it would be difficult to capture the true amount of time spent on any one exception. By their very nature exceptions require some degree of detective work to fix and many times operators work on multiple exceptions while waiting for information. 23 6.3.3 Process Parameters 6.3.3.1 Exception Occurrence Data Although some data collection and reporting on the exception occurrence rate already is in place, some useful details are missed. Through conversations with the technicians involved with the computer systems related to exceptions, it was determined that recording the time stamp and other key information such as install type would require a new software application to be built. Apart from the benefits this data would have for the simulation, it would be very useful for A S G / A C T to be able to compare exceptions and look for common traits either in timing or order features to enable systematic problem solving and exception reduction via Pareto analysis. 6.3.3.2 Rework and New Requests Occurrence Data Two more major parameters that require investigation are the rates at which rework and new requests enter A S G / A C T via the phones and email. Currently expert estimates are the only way to approximate these rates for phone calls. As a starting point manual tallies for a few days would provide the basis a much better estimate, but possible variations could only be detected if these tallies were kept up over a few month period. In contrast, for email it would be possible to follow the same procedure as before and sample a percentage of all the email to determine these rates. It would be advisable to use recent data and expand the scope to cover at least three months. Since rework rates can have a major impact on a processes ability to meet demand it is important to identify all rework loops (including rework originating in areas outside A S G / A C T ) and develop an understanding of the amount of processing capability being lost. 6.3.4 Order Parameters There are four order parameters that could benefit from further analysis: due dates, install and service types and assignment vs. activation. Since there have been significant changes to the process since the analyses were last run, these should all be reanalyzed with more recent data. It also might be helpful to observe how the relative distributions change with time, e.g. are there more orders of a certain install type at month end? One major convenience is that all of this data would likely be available from the same source as the order creations time stamps: one properly designed computer system query might be able to collect all the information into a few reports albeit over a period of time. 24 7 CONCLUSIONS This study shows how simulation can be used to model a complex system with several sub-processes and provide information on the relative extent of the effects of system changes. Although the model was limited to some degree by the detail level of the available data, this simulation provided useful information about proposed changes and raised important issues. The simulation results show that further data collection and analysis is warranted and should be pursued. However, the process of building the simulation also showed that the data analysis alone is able to provide valuable insight, e.g. in this case charting the due date distribution showed that a significant number of orders arrived with a substantial lead time that was not being fully taken advantage of. In addition, it may be possible to improve on-time completions if the processing times can be kept at the average level (as opposed to the worst case) and days out are shifted three days ahead. Operator utilization is most likely too high, although the exact extent of the problem can only be determined by moving ahead with the investigation outlined above. Clearly a better understanding of the work processing times within A S G / A C T needs to be developed if T E L U S management wants to understand how A F E A and exceptions affect throughput as well as the precise impact that volume fluctuations have on utilization. Order processing times appear to have a major effect on the need to improve both A F E A and exception rates. Accurately determining the variation in these processing times within A S G / A C T would help identify problem areas more clearly. 25 8 RECOMMENDATIONS Undoubtedly the most pressing recommendation resulting from this study is the need for more data collection. Even without going through the extra step of upgrading the simulation and running the scenario analyses again with more detailed data, the data can give a lot of insight about the process and help explain how factors that are not currently quantified, e.g. how work processing times affect overall performance. The extent to which exception rates need to be reduced and A F E A rates need to be increased is really dependent upon the true distribution of work processing times. FW should be worked six days out instead of three. Although the simulation lacked enough granularity to give exact numbers, it was obvious that working farther ahead would result in more time to catch and correct potential missed commitments. With more detailed data and an updated simulation a more optimum value for days out could be determined, however in the meantime this is a good starting point. Similar benefits are probably realizable with both RW and S W , although to a lesser extent. Further, days out metrics need to be charted clearly and often. Everyone within A S G / A C T should be able to see where current performance is with respect to expected targets. This will help reduce the subjectivity in decisions regarding workforce assignment. Most operators are probably over-utilized at current volumes. Given a choice, adding operators to the TNW queue first would have the greatest impact on increasing throughput. One of the assumptions in this model was effective cross training; if this is not the case then utilization rates across functions are probably subject to a higher degree of variability. In addition, given the long lead times available for most orders some investigation should be pursued regarding the possibility of segmenting the demand into regular customers and those willing to pay more for short notice service. Finally, Table 8 lists the minimum requirements for improving the simulation model. Table 8 Recommended Metrics for Improving Simulation Model Metric Estimated Benefit Processing Times - Time stamps for working each type of order Determine actual time to process different types of orders as well as best and worst case scenarios Orders - Arrival times, install & service type, AFEA status, ASG or ACT required Determine order arrival patterns by type and feature, % AFEA by time of day/month New/Rework % - Number of calls & email not related to existing orders Determine the amount of additional work that comes into ASG/ACT through calls and email Exceptions - Time, install & service type, associated features, etc. Determine probability of exception by order type (features) and time of day 2 6 9 FUTURE WORK 9.1 Upgrade Simulation with Improved Data Although the simulation was able to provide value, running it with updated data as detailed in Section 6 would enable more detailed questions to be addressed. The work so far has provided a template for building and improving the model. It should be relatively simple to include new information as updates and more detailed data becomes available. The following sections outline possible features that could be included in future models. 9.2 Update Simulation to Include Other ASG/ACT Processes 9.2.1 Potential Processes to Add As previously stated, this model focused on the process at the B C A S G / A C T site and some of the low volume sub processes were left out because they were thought to have a relatively low impact on order processing and operator utilization. However, it could be argued that developing a more detailed understanding of A S G / A C T ' s operators other tasks would help to more accurately determine how much time was available for their main responsibilities. There are several smaller functions that A S G / A C T is responsible for performing; the three largest are listed below. 9.2.1.1 LYNX (Trouble Analysis System) Since A S G / A C T has access to the computer systems where customer services are configured, their help is often required when there are major problems with a particular customer's service. In comparison to the problems that are passed to A S G / A C T via email and phone calls, the work that flows into L Y N X consists of service failures (troubles) identified by customers and called into TELUS ' s help desk. These troubles are almost always connected to orders that were completed but for some reason the service the customer has asked for isn't working. The method for working troubles is similar to exceptions; it requires a lot of detective work and co-operation between groups to access the required information. In terms of process flow, L Y N X represents rework that has usually originated outside of A S G / A C T . When the trouble volume is low L Y N X operators (usually one or two) focus on secondary priorities. 9.2.1.2 Local Number Portability Local Number Portability (LNP) refers to the relatively recent option of having a phone number move with the customer. This allows established businesses that may have already invested substantially in advertising their existing numbers to keep their number when they move. The work required to enable a customer to move a phone number from one physical location to another can be substantial depending on the distance and the compatibility of the switches and other equipment involved. A small group in Alberta of about eight operators works LNP orders. 9.2.1.3 Centrex Centrex is an advanced phone feature package for business customers. Frequently businesses require sophisticated phone systems with features such as after hours call routing, voice mail, and other internal calling options, e.g. the four digit dialing that many companies employ within their offices can be provided with Centrex. As an alternative to expensive in-house phone systems that companies buy, they can get the same features by renting the service from T E L U S . A S G / A C T in B C has a special group consisting of about six full time operators dedicated to Centrex functions. Currently Centrex orders are delivered by a system external to TNW and they 27 are activated differently; operators configure and execute orders directly in the switch rather than by using a software application to parse the requests. 9.3 Study Prioritization Effects on the FW Buffer 9.3.1 Expanding the Simulation to Model the FW Buffer Up to this point, the simulation has only focused on FW orders as they pass through A S G / A C T . Since FW order throughput has been identified as a problem, it would be beneficial to modify the simulation to include the additional FW order processing outside A S G / A C T . The advantages of expanding the model this way include identifying any major bottlenecks outside of A S G / A C T as well as other factors affecting completion times. After A S G / A C T FW orders proceed to the D M C they are split into two groups depending upon the amount of work required: major work requires F S R time to be booked ahead. After an additional error checking stage, the FW orders are released with a FIFO priority to the F S R s via yet another work delivery computer system. The volume of orders released is coordinated with F S R staffing levels to help ensure that enough labor is available to complete the required work on the due date. 9.3.2 Additional Data Requirements In order to add the extra FW order detail, data for the additional processing would be required. This would include a detailed process map of the order flow through the D M C and any major decision points and rates where orders are either routed according to their characteristics. As before, processing time and error rate data or estimates would be required. Any prioritization rules that apply to FW orders passing through the D M C and F S R work queue would also need to be clearly outlined. 9.3.3 Current Work Prioritization Rules In broad terms, orders are prioritized by install type and the days out that A S G / A C T is committed to meeting, i.e. 2 days for RW. The days out targets are the result of back scheduling from the due date promised to the client, so they represent the time required to complete each install type most of the time. Although attempts have been made in the past to work the orders farther ahead of schedule and temporary gains have been realized by using a lot of overtime, there has been great difficulty in maintaining these leads. Eventually the orders regress to being completed shortly before they are due. 9.3.4 Developing Alternative Work Prioritization Rules Based on the days out analysis for the A S G / A C T process it would be important to evaluate the effect of working FW orders earlier, not only to see the effect on completion rates but also to determine the effect on other resources, e.g. the D M C staff and F S R s . First, it would be important to clearly define all the internal and external metrics, e.g. days out targets and Canadian Radio-television and Telecommunications Commission (CRTC) specifications. In addition to varying days out targets both as a group and independently it would be interesting to attempt to implement a priority system based upon features other than install type, i.e. break each install type down into subcomponents and use a Pareto chart to identify those most likely to miss due dates. The orders with the highest potential for errors or missed commitments could then be flagged and given higher priority. This would help to find a way to structure the sequence that orders are worked in so that those most likely to cause problems are addressed soon early enough. 28 There has been some discussion about implementing a FIFO priority structure for the orders; one of the benefits would be that customers that plan ahead and give T E L U S sufficient warning would get their work and orders attended to first. Essentially this would reward customers for planning ahead and encourage more people to do so. This would be especially effective if T E L U S also considered implementing variable rates based on the amount of advanced warning that a customer provided before ordering, e.g. a customer who notified T E L U S that they were moving two weeks ahead of time would pay less than one who called in on the day of the move. This "yield management" approach could provide T E L U S with an effective way to increase its revenue. Currently all orders of a certain type are treated with the same priority, but as outlined in the recommendations it could be argued that being able to call in with much less notice and still get the order put through is an extra value that T E L U S provides but is not charging for. 9.4 Study Scheduling Effects on ASG/ACT 9.4.1 Current Scheduling Rules Within A S G / A C T , resource allocation is closely tied to work prioritization. As outlined in Section 2.4.1, supervisors use the daily days out report compiled in the morning to make decisions about staff, allocation. Meeting the days out targets for all three install types requires careful and constant juggling; frequently A S G / A C T will be exceeding in one area and lagging behind in the other two, e.g. FW might be four days out, but RW and S W only at one and zero days out respectively. Depending on the amount of outstanding work for each task, operators are constantly shuffled around to ensure all goals are met. Similarly, due to the C R T C guidelines that T E L U S must meet on a monthly basis, if one area's service level is below expectations then resources from other areas may be added to improve performance for a few days so that the monthly targets are met. As a result, each supervisor makes a subjective judgment aimed at meeting these competing goals. However, other than these guidelines there are no well-defined rules; instead this reassignment is based on general guidelines and management experience. Since the current resource allocation and prioritization system is reactive and subjective, it could be argued that it may be adding to the problems to some degree. 9.4.2 Proposed Alternative Scheduling Rules From an implementation and performance measurement standpoint it is clear that more detailed rules for scheduling should be specified, first so that the scheduling and deployment becomes repeatable and stable, and second so that the effects of changes can be evaluated in a systematic manner. With this in mind, simulation can be used to evaluate some of these options before they are implemented and speed the evaluation process. Currently, operator shifts generally coincide with regular business hours. This makes sense since most of the calls from customers that eventually result in contact or requests to A S G / A C T are bound to occur during the daytime. However, the A S G / A C T process is always running. Orders are executed around the clock and many exceptions occur shortly after midnight. This leads to the idea of staffing A S G / A C T either around the clock or at least extending the hours in order to peak shave the demand during busy times. Although it would not require a large workforce during the non-peak hours, having some operators on hand at all times would guarantee some degree of continuity for difficult problems. It would also allow A S G / A C T to stay abreast of some of the work as it develops, e.g. exceptions could be worked as they occur. This move might also change the mentality from a batch process to a flow process. Currently daily targets are to maintain at a certain level of days out by the end of each day. By changing to continuous operation, operators would think more in terms of rolling targets rather than meeting quotas. Even if round the clock operation was not an option, it might make sense to extend the hours during which A S G / A C T is staffed, since this would still provide some of the benefits outlined above. 29 In addition to developing structured rules for scheduling, it would be interesting to use a best estimate at staffing levels and then keep them the same for an extended period of time to see if queues build infinitely or if they wax and wane but are manageable in the long run. Another option would be to modify the cross training schedule so that employees spend only half of their time on any given shift either learning new or refreshing existing skills. The rest of the time operators would be assigned to their area of expertise, i.e. the processes that they were either the most effective or speedy at completing. This would provide a trade off between cross training and keeping order processing speeds high. 9.4.3 Evaluating Scheduling Changes with Simulation Most of the scheduling changes can be easily modeled by making simple changes to the resource availability schedules in the simulation. The scenarios can either be tested individually or run in combinations, i.e. as in structured "design of experiments" tests. Processing time variations, based on operators switching between cross training jobs and tasks they are already highly proficient at (described in the previous section) would be slightly more difficult to incorporate with the simulation. The easiest way to model the different processing speeds would be to assign individual processing speed characteristics to each operator in the simulation. In order to model the actual system more closely it would be important to add a lag time between switching from one task to another to represent the time required by operators to start a different type of job. Days out and throughput would still be relevant metrics, however it would be important to include operator utilization (especially during non-peak hours) and the number of late orders occurring for each configuration. 30 GLOSSARY Activation: Once orders have been assigned they must be activated for the desired changes to take effect. Activation entails running the assigned order through the switch, which executes the changes and makes the required changes within the mainframe computer. AFEA (Auto Front End Assignment): The vast majority of the orders that pass through A S G / A C T are configured in a way that allows them to be automatically assigned with software; this is referred to as A F E A . ASG/ACT (Assignment and Activation Group): A S G / A C T is the internal group within T E L U S responsible for assigning and activating orders maintaining record accuracy and configuring software orders. Assignment: Assignment refers to making an order ready to be executed (assigned). It requires setting up the changes in a way that can be parsed into low-level machine code and read by the switch. All orders entering A S G / A C T require assignment. Centrex: Centrex is a small group within A S G / A C T that sets up advanced phone systems for T E L U S business customers on a rental basis as an alternative to buying the equipment and software from a third party. CO (Central Office): C O s are the service marshalling warehouses throughout B C and A B . All T E L U S customers are connected to a local C O . Each C O contains a rack, which is essentially a large switchboard where customer phone lines are connected to the T E L U S system with wires. COE (Centre for Operations Excellence): The C O E is an operations research consulting group closely associated with the Sauder School of Business at the University of British Columbia. CRIS (Customer Resource Information System): CRIS is the software tool used by C R S s in the call center and retail stores to enter customer's orders. The orders generated in CRIS are the input for A S G / A C T . CRTC (Canadian Radio-television and Telecommunications Commission): An independent agency responsible for regulating Canada's broadcasting and telecommunications systems CSR (Customer Service Representative): C S R s are the T E L U S employees that work directly with outside customers either through T E L U S retail stores or call centers. They are responsible for creating service orders. Days Out: Days out is a term that indicates how far ahead of actual demand A S G / A C T is in terms of completed orders. For example if A S G / A C T ' s goal is to be 3 days out for FW, then all orders due within the next three days should be assigned. DMC (Dispatch Management Center): The D M C takes FW orders from A S G / A C T and schedules them for the F S R s . Exception: Orders that pass through the switch and fail to be assigned are called exceptions; they require manual reconfiguration and activation to be fixed. FMS (Facilities Management Service): F M S is the old system used for accessing the T E L U S mainframe and assigning orders. It has been partially replaced by TNW, however F M S is still used to access and configure orders in some special cases. 31 FSR (Field Service Representative): F S R s are the T E L U S employees that actually go to customer sites and perform work to connect their phones. FW (Field Work): Orders that require a F S R to go to the customer's site and make physical changes to the telephone equipment. GOPHER: G O P H E R is a recently developed software tool that works in conjunction with TNW and F M S . It speeds order completing by automating repetitive and simple tasks and allows the operator to focus on the difficult questions. Conservative estimates indicate that G O P H E R has increased productivity by 150 to 200%. Install Type: An order's install type indicates the type of work it requires, e.g. FW, RW or S W . IP (Internet Protocol): (IP) The network layer for the TCP/ IP protocol suite widely used on Ethernet networks. IP is a connectionless, best-effort packet switching protocol. It provides packet routing, fragmentation and re-assembly through the data link layer. T E L U S ' s IP customers get access to the Internet as well as other associated services, e.g. email, web page hosting etc. LNP (Local Number Portability): LNP is a small group within T E L U S that helps customers that want to move small distances keep their existing phone numbers. This is useful for established businesses that have a well-known contact number. LYNX: L Y N X is a computer system used in A S G / A C T to track and fix troubles (orders that have not been fixed properly and requests for rework). LYNX requires one or two operators and the work falls outside of the stream of regular work in A S G / A C T . RW (Rack Work): Orders that require a change to the customer's physical configuration within the rack at the local C O . SW (Software Work): Orders that require changes within T E L U S ' s mainframe computers and switches in order to be executed. Most S W orders can be implemented by A S G / A C T without any outside help. TNW (TELUS National Workflow): The computer system that tracks orders as they pass through A S G / A C T . 32 REFERENCES Cited References [1] V. Bapat and E. B. Pruitte, Jr., "Using Simulation In Call Centers," in Proc. of the 1998 Winter Simulation Conference (Washington D.C.) p.1395-1400, 1998. [2] B. Andrews and S. Cunningham, "L.L. Bean Improves Call-Center Forecasting." Interfaces 25(6), 1-13., 1995. [3] B. Andrews and H. Parsons, "Establishing Telephone-Agent Staffing Levels through Economic Optimization." Interfaces 23(2), 14-20., 1993. [4] T. A. Grossman, Jr., S. L. Oh, T. R. Rohleder, D. A. Samuelson, "Call Centers," Encyclopedia of Operations Research and Management Science, 2nd Edition, 1999. [5] R. Klungle and J . Maluchnik, "Call Center Forecasting at A A A Michigan," Journal of Business Forecasting, 1997 -1998 Winter; p. 8-12., 1998. [6] Arena Contact Center Edition, Rockwell Software Inc., 2004. Available at: http://www.arenasimulation.com/20products/24_contactctr.htm. [7] A . J . Brigandi, D. R. Dargon, M. J . Sheehan, and T. Spencer, III, "AT&T's Call Processing Simulator (CAPS) Operational Design for Inbound Call Centers." Interfaces 24(1), 6-28., 1994. [8] G . Koole, A. Pot and J . Talim, "Routing Heuristics For Multi-Skill Call Centers," in Proc. of the 2003 Winter Simulation Conference (New Orleans), 2003. General References D. W. Kelton,.D. A. Sadowski and R. P. Sadowski, Simulation With Arena, Third Edition, New York: McGraw-Hill College, 2003. D. Powis, Understanding Simulation Modeling for the Contact Center, Vanguard Communications Corporation. 2002. Available at: http://www.vanguard.net/DocLib_Docs/Simulation_Modeling_dp_0204.pdf. 33 APPENDIX: ADDITIONAL RECOMMENDATIONS Background Before determining that building a simulation model would be the best way to provide value and insight to T E L U S about the A S G / A C T process, much time was spent meeting with people in A S G / A C T as well as it's partner groups and existing data and metrics were reviewed. During periodic review sessions with T E L U S , these findings and the recommendations based upon them were presented and discussed. Although these analyses and recommendations were relevant in terms of helping T E L U S identify areas to improve, they were not directly related to the simulation modeling and hence appear separately. Non-Doable Work Analysis One of the recent improvement initiatives launched throughout T E L U S is called Doable Work. This initiative focuses on helping the partner groups work more cohesively across the value chain by helping each group identify its input requirements clearly to its supplier. One of the major problems that had been identified throughout T E L U S was that teams were not receiving all the information or resources required to do a job. Simply put, if a C S R fills out a service order correctly and includes all the information required for the A S G / A C T group to do their job, that C S R has provided Doable Work. Through this initiative each partner group provided feedback to its upstream supplier on the amount of non-doable work that it had received. In theory this would allow the supplier to evaluate their customer requirements and take action to meet them more consistently. Figure A1 Non-Doable Work Summary Chart NonDoabteMay25-31 ADSL Port Missing: 001 • A D S L Port Missing: 001 • A D S L A A I S Discrepancy: 019 • A D S L Incorrect Qualification : 017 • A D S L Port Booking Error 018 •Attribute Error 020 • Due Date Interval Not Followed: 016 • Feature Dependency: 022 •Feature Unavail for Switch or Svc Type: 021 • Incorrect Order Type : 030 • Incorrect RIT - CP/LE missing/robbed: 023 • Incorrect RIT - Incorrect Use: 024 • LNP error: 032 • No Clearance: 025 • Ord ers Ou t of Seq uen ce: 029 • S&E Code Error: 027 • Service Address Discrepancy: 010 • Smart Ring Error 028 • TN Conflict: 031 •Winback Errors: 033 At the time of this analysis A S G / A C T had been recording the non-doable work it received from its supplier, the Customer Service Group, and sending back a weekly report summarizing the problems by type for about four months. Figure A 1 shows a sample summary chart of a non-34 doable work report. The data represents the different error types for non-doable work occurring during a typical week. Figure A2 Modified Non-Doable Work Summary Chart System Problems ADSL Problem ADSL Problem Feature Problem LNP Problems Order Problem RIT Problem System Problems Order Problem LNP Problems 13% 2 % One potential problem that was immediately apparent was that there was too much detail in the pie chart. With so many different types of errors it might be difficult to select a method for taking action in a structured and effective manner. Therefore, our first recommendation was to group the causes into larger cause groups as proposed below in Figure A2. By grouping the individual error codes into major error types it is easy to identify feature problems as the largest problem. Clearly some action should be taken to eliminate this problem as a whole rather than solving each individual fault. Figure A3 Pareto Chart for Weekly Non-Doable Work Further, the errors could be quantified more effectively by using a chart with a higher information density, such as the sample Pareto chart shown in Figure A3. In this case the individual error causes are ranked by frequency. This Pareto chart was created based on the most frequent 3 5 errors; only the top three errors were taken for each week and then ranked for the whole four-month period. One problem with these charts is that they cannot show how the occurrence varies over time. This led us to plotting time series charts for the error causes in Figure A3. A sample time series is shown in Figure A4. Each data point represents a week's worth of data. This chart does not seem to indicate that the number of these errors is decreasing; instead they appear to be increasing slightly. Figure A 4 Time Series Chart for Incorrect RIT - Incorrect Use Week Number In order to determine if the number of errors had significantly increased an individual and moving range control chart was built for the same time period. This chart, shown in Figure A5, has two parts. The top part shows the individual data values and is essentially a time series. The bottom chart shows the range or difference between data points; it quantifies the week-to-week change. The centerlines represent the average and the upper and lower lines for each graph are the control limits. Figure A 5 IMR Control Chart for Weekly Errors 1.5 H CD • i 1-0 03 _ 0.5 > £ 0.0 Subgroup —r~ 10 3.0SL=1.245 X=0.6017 -3.0SL=-0.04179 T 20 CD O ) c CD rr D ) 0.9 - r 0.8 -I 0.7 0.6 0.5 -0.4 -0.3 -0.2 -0.1 0.0 3.0SL=O.7905 R=0.2419 -3.0SL=0.000 3 6 The limits are used to evaluate whether or not the process, in this case the number of errors created every week, is "in control". When a process is in control the variation in output is limited to an expected range based on a normal distribution. Therefore this chart shows that the number of errors due to this particular cause have neither increased nor decreased, but have stayed the same. This type of analysis was repeated for the top three causes in Figure A3. None of the frequencies had significantly dropped. The conclusion was that although A S G / A C T had been providing weekly feedback to a partner group for about four months any action that was being taken was not being effective in reducing the number of errors. Missed Commitments In addition to the analysis on days out and the identification of the significant lead-time that was not being fully used, there are a few more fundamental steps that can be taken to reduce the occurrence of missed commitments. Currently there is no in depth analysis performed on missed commitments, but data should be collected on as many order details as possible, e.g. service type, location, features etc. Once this information is collected a similar analysis as outlined above could be carried out, by quantifying the characteristics of missed commitments it would be easier to identify which orders were most likely to become missed commitments. Armed with this information A S G / A C T might be able to work potential missed commitments with a higher priority than other orders. Qualitative Recommendations As outlined above, during the investigation stage of the project meetings with various different groups were conducted. One of the results of these meetings was a lot of feedback on issues surrounding communication and interaction both within and across partner groups. Our recommendations resulting from this feedback are outlined below. Communication Based on the pre-existing "silo" culture where each group concentrated solely on their own tasks, we recommended increasing the communication across jobs. Recurring comments heard form each group were based on a lack of understanding of each other's jobs at the operational levels. Operators within the individual groups felt that they were often working against each other. Our suggestion was to co-locate some of the operators from partner groups to increase the frequency and speed of feedback and to foster an inter-group team mentality, i.e. try to build cross functional teams at the operator level responsible for the entire process of order completion. As an alternative T E L U S could sponsor "career fairs" where operators could spend a few days learning about each other's jobs and understanding each other's requirements. Training Although much effort was being concentrated on improving training during this study, there were still some key elements that might be improved. Each trainer taught his or her own methods, instead of all agreeing on one best method. Since the training for A S G / A C T operators requires over four weeks, each trainer had to stay with the same group for the entire period. This caused problems when either the trainees or the trainers had absences, e.g. vacations or illnesses. By standardizing the training format and methods and by modularizing the four weeks into weekly and eventually daily segments these problems could be avoided or reduced. This would also help to reduce the variation in the processes and enable problems to be identified more quickly. 37 Documentation Control Each operator was issued a training manual which they could add notes to. Periodically updates and bulletins were provided either via email or the internal web site. Due to the sheer number of information bulletins and email it is questionable whether all the updates were received and included in the manuals. The result was each person having slightly different documentation. Although updated versions were usually available on the intranet, the sheer volume of information on the intranet made it difficult to find the correct information at times. Stricter document control would help ensure uniformity in the methods used. This would have to include a system for separating the documentation updates from the other bulletins and email that add to the confusion. Task Prioritization One issue that made it difficult to evaluate the system was the high degree of subjective judgment that all A S G / A G T supervising managers used in assigning operators to tasks. This resulted in poor repeatability from manager to manager. Given the same set of circumstances different mangers might deploy the workforce differently. In addition, it was unclear at times what criteria was being used to make decisions. Establishing clear rules based on the importance of each task relative to the others and charting or posting the information required to make prioritization decisions would help ensure repeatable behavior. This would make it much easier to evaluate the effects of changes in strategy and prioritization. Customer Service Assessment During this project a remarkable amount of unsolicited negative feedback was received by the project team from T E L U S customers. It quickly became apparent that T E L U S didn't realize how difficult it could be to deal with from a customer's viewpoint. Although customer service was a highly important issue, T E L U S management didn't seem to understand how frustrating it was to be an outside customer being passed from one call center queue to another often having to wait for long periods of time. In addition many customers reported that a common answer to their complaints was to shift the blame onto another internal department with no follow up. Our recommendation is for T E L U S operators and management to observe the process of being a customer without any T E L U S knowledge calling in and asking for service, i.e. to be the customer and see the service from their point of view. Demand Input on New Product Offerings One increasing problem for A S G / A C T is providing constantly changing and newer services with an aging computer system. Many times the new products that are introduced result in additional work when being implemented by A S G / A C T . This causes two problems, first more operator time is required for each order that cannot be automatically assigned and activated and second the true cost to provide the service isn't being reflected in the price. Taking an activity based costing approach for each service could ensure that margins are being maintained, but before that can happen A S G / A C T must be represented in decisions concerning new services and their prices. Metr ic Recommendat ions T E L U S had also asked for suggestions in terms of the metrics that should be collected to support other recommendations. The Table A1 summarizes these findings. It should be noted that some of these metrics are also required in order to improve the simulation model and are listed in the recommendations section of the thesis. 38 Table A1 Recommended Metrics and Estimated Benefits Metric Benefit Missed Commitments - Time, install & service type, features, S&E codes, etc. Non-Doable Work - Pareto charts; time series or control charts for top causes Due Dates Met - Number of people affected by missed commitment as opposed to % met Order/Call/Email Processing Times -Time stamps in & out Days Out -each day Recorded several times Identify potential problem orders so they can be prioritized Systematic root cause identification, control charts show suppliers when improvement isn't happening Quantify the potential for unhappy customers, brings the focus back onto the customer Realistic estimates for processing times and quotas; see how processing times change daily, hourly, weekly etc.; can help process stay at set days out if posted Identify changes in days out throughout the day; help predict changing priorities; build a long term picture of process capability Order Times - Creation time Determine order arrival pattern and help with staffing decisions Exceptions - Time, install type, service Would allow systematic root cause identification. Also type, associated features, etc. occurrence patterns would help with scheduling Non Queue Calls - Daily/weekly number and average duration of calls into locals a c c e p t a b l e c h a n n e | s Posting these numbers would bring focus to keeping outside calls to a minimum and forcing outside contacts to go through 39 

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
https://iiif.library.ubc.ca/presentation/dsp.831.1-0091605/manifest

Comment

Related Items