TQM CASE STUDIES

SUHAS CHOWDHARY.J 215110068 DoMS, NIT Trichy

CASE STUDY 1
The Case of TQM and Innovation
by R Chandrasekhar

SYNOPSIS: He was sure that he had, finally, identified why there was such a dearth of innovation in the organization. Operational Efficiency programs--like Total Quality Management, Business Process Reengineering, and Activity Based Costing--were, under the guise of bettering the company's systems and processes, conditioning its employees to think only in deterministic fashions. Which could leave the company bereft of a future despite its access to technology from a transnational partner. Piramal Enterprises' Leonard D'Costa, SRF's N. Ramanathan, Qimpro Consultants' Suresh Lulla, and NOCIL's V.K. Rajpal debate the roots of Horizon's affliction. A BT Case Study. At 1:00 a.m. on a cool February night, Ranjan Jetley knew he had the answer. He closed the book he was reading, and put it back on the table alongside a huge pile of almost every tome ever written on TQM, switched off the small, but effective table-lamp that had illuminated his efforts, and went to bed. As he drifted off, Jetley was still thinking about the origins of the problem that had, so successfully, taken him back to B-school. He was, essentially, a change artiste. His business card read Vice-President (Business Planning), but Change Manager would have described his role better. A civil engineer and an MBA, Jetley worked for Horizon, one of India's largest manufacturers of two-wheelers, and a joint venture between the S.V. Group of Companies (the major partner, with a 40 per cent equity stake) and Hideo Motor Co. of Japan (a technology collaborator, with a 5 per cent stake). Jetley still remembered the day, almost 4 months ago, when his CEO, H. Narayanan, had sent for him. Narayanan was the typical hands-off CEO, content to let his managers run the company while he spent his time plotting its future. Knowing him, a sudden request for a meeting could only mean one thing: a problem. As he was being ushered into Narayanan's room, Jetley realised that he was not the only one who had been sent for. Raman Bhatia, Horizon's President (Operations), and Rahul Kansal, President (Marketing), were already there. Quick greetings were murmured all around as he took the chair Narayanan pointed at. "Gentlemen," began the CEO, "we have a problem on our hands. Something that could threaten our very survival if it is not attended to immediately. Rahul, I do not know if everyone has had the time to go through the audited marketshare figures for 1998. Could you sum up the state of the market for us?"
1

"Certainly. The two-wheelers market is fragmented into 6 segments: mopeds, scooterettes, scooters, step-throughs, two-stroke motorcycles, and four-stroke motorcycles. We are the largest player in the mopeds segment, with a 45 per cent share. In the scooters and motorcycles segments--in both of which we are late entrants--we have marketshares of 12 and 16 per cent, placed at the fifth and the fourth positions, respectively. Although these figures represent a growth over our 1997 marketshares, it is becoming increasingly difficult to keep pace with customer needs" "That's a sea-change from the time when we had no marketing department and sold everything we produced. Today, inventories are the biggest drain on our working capital," added Bhatia. "But that isn't the only operations-related issue we need to address, is it, Raman?" asked Narayanan. "Not quite. There are more. One, the emission norms that will be stipulated by 2001. To meet them, most of our models will have to be scrapped or changed radically. The second issue concerns the continuing pressure to indigenise our components. We source almost 70 per cent of our components locally, but our efforts in this area--in the face of a weakening rupee-- need to be stepped up." "Thanks. Now, these are ordinary issues, ones that any business faces. Right? What worries me, though, is our ability to find answers to them. Let me put it simply. I think we have, somehow, lost our innovative edge. Innovation, gentlemen, is a rare commodity in our company." Jetley, Bhatia, and Kansal were dumfounded. Bhatia was the first to react. As the person directly responsible for the company's manufacturing and product development, it was evident that Narayanan's observation had stung. "What about Zap?" he stuttered, referring to the 60-cc stepthrough developed in-house in 1994. "It cost us Rs 6 crore to develop the product, and we recovered this investment in 2 years. Had we not done this, and been content to live off Hideo's technology pool instead, we would have had to pay out around Rs 20 crore as technology fees" Kansal had been waiting for Bhatia to finish. "Remember our cost-cutting drive in 1992? After months of trying unsuccessfully to meet absolute targets, we decided to change our approach. And just focus on weeding out any activity that did not add value to the customer. We managed to save over Rs 100 crore in a 2-year period. That was an innovative masterstroke How can you say we are not innovative?" Narayanan did not try to refute what either of his functional heads said, but there was a smile in his voice as he answered: "We are not innovative, Rahul, and that includes me. These instances are from the past. In the last 2 years, I have not encountered a single path-breaking idea in this company. Have we been able to repeat the Zap experience? Have we been able to innovate around our cost-management initiatives? No. We have not been able to indigenously develop a four-stroke motorcycle. And every time someone from our collaborators visits us, and speaks of
2

kaizen or continuous improvement, I feel a twinge of guilt. How long has it been since a worker came up with an improvement technique, however marginal? How long has it been since one of us came up with an innovative way to, say, beat the recession? If this goes on, we could soon be dead." Kansal and Bhatia couldn't really argue with that. Busy with the details of actually managing the company on a day-to-day basis, neither had noticed the absence of the innovative spark. But what Narayanan was saying did, in hindsight, make sense. "The only way to solve this problem," said Narayanan, "is to get someone to study it, and find out what is killing the innovative streak in our people and the company. That is what I want you to do." He was looking at Jetley. Four months later, Jetley finally knew what was wrong. The meeting was scheduled for 8:30 a.m. in a small conference-room adjoining Narayanan's office, but Jetley was there at 8:15 a.m., with a sheaf of slides and pre-prepared answers for the questions he knew he would be asked. Kansal, Bhatia, and Narayanan walked in. "Ready?" asked Narayanan. Jetley nodded. "Let's go." Without a preamble--everyone knew why they were there--Jetley began. His first question was addressed to Narayanan. "When do you believe the rot set in at Horizon?" "Top of my mind, I would say 1995." "1995, coincidentally, was also the year when we launched our TQM initiative, with the ISOcertification programme. This imposed a discipline on our people, and ensured that they conformed to pre-determined norms. On the flip side, it may have also created a bureaucracy of its own. It discouraged any attempt on the part of an individual to think outside-the-box. We fared no better with TQM, which we adopted quickly thereafter. I believe that there are several things wrong with TQM at a conceptual level. First, the focus is on gradual, incremental change. Second, by making team-work, consensus, and minimum confrontation the tripod of its ethos, TQM has cut off the roots of individual creativity, which drives innovation."

The first question came from Bhatia. "What, if I may ask, is the exact problem with TQM?" Jetley loaded another slide onto the projector. "You must all be familiar with this. It is the selfassessment framework that forms the basis of our TQM efforts." "I know," interrupted Kansal, "and I remember receiving a memo last month that highlighted the fact that our score had increased from 600 points in 1996 to 850 points in 1998" "On a maximum score of 1,500," Jetley completed. "But, I suspect, the issue at Horizon is more fundamental. And the problem lies with the model that we have been using. Its parameters, and their weightages, have remained static over the past 3 years. I know that the weightages attached to the criteria for the Malcom Baldrige Award are changed at regular intervals to reflect the changing conditions. Aren't we stifling ourselves by sticking to the same parameters?" "You may have a point there," accepted Narayanan, "but do you have any other evidence to prove this?" "One of the highlights of a survey we conducted before launching our TQM drive was that customers wanted lower costs, higher quality, shorter delivery-schedules, and continuous product-innovations. That was when cost, quality, and shorter lead-times were the differentiators in the auto industry, and they became the prime objects of our attention. The between-the-lines conclusion that we all seem to have missed is that customers want not any one or two of these, but all 4. Not only did we ignore innovation, our success in the other 3 areas has only eroded the innovativeness of our employees." "If we are looking at the rigidity of TQM as a reason for the death of innovation, what about systems-driven approaches, like ABC (Activity-Based Costing) and BPR (Business Process Reengineering), which we subsequently implemented?" asked Bhatia. "I was just coming to that. I believe that it may not be possible to focus on innovation using techniques like TQM, BPR, and ABC. Innovation requires a unique culture, which none of these techniques may be able to provide. By burdening low-volume new products with punitive levels of overhead, ABC poses a threat to innovation. True, it has enabled us to capture our costs with mathematical precision. But when you consider what it has done to innovation, I wonder if we did the right thing in adopting ABC" "What about BPR?" prompted Kansal. "BPR does not fare any better. Designed as an initiative which brings about the radical redesign of business processes through dramatic improvements, it has its flip sides too. BPR has crippled the support functions at Horizon simply because those are always the most vulnerable to retrenchment. By fostering anxiety, and promoting a cautious approach, it has nipped creativity

in the bud. How do we now undo the damage? When it comes to that, your guess is as good as mine." Narayanan was the first to congratulate Jetley. "I think you may have hit upon the source of our problem, Ranjan. In our quest for quality, in our desire to perfect our processes, we could have created a system that stifles creativity in any form. Not overtly, but covertly, with our emphasis on cycle-times, the number of defects, and conformance. In the process, Horizon's culture has undergone a shift. I believe it is less-vibrant, and more sanitised than it was before we went in for these operational effectiveness improvement techniques. I am not saying that we haven't achieved anything with them, but the death of innovation is a most undesirable side-effect. What do we do now?"

CASE STUDY 2
Bharti Broadband saves with Six Sigma
Six Sigma helped the service provider improve its customer service Bharti Broadband Networks (BBNL) is a leading integrated broadband service provider operating in the broadband, Internet and VSAT markets. It provides customized and integrated solutions to corporate customers. The company had a goal of delivering error-free services to customers by doing the job right the first time, every time. Six Sigma ahoy With the quality objective having been decided, an executive committee (EC) comprising nine officials, including the CEO, was formed. The committee studied various other quality tools and processes like ISO and TQM in addition to Six Sigma. The choice for Six Sigma was made as it was closely aligned with the outlined quality objective. According to Ashok Juneja, CEO, BBNL, "We realised that the telecom industry is undergoing rapid change and so are customer requirements. Six Sigma met the requirements of this changing environment." There were already several case studies of successful Six Sigma implementations in large companies like GE, Motorola, Wipro, TCS and Satyam. Making the customer a priority Having decided upon IGE as the consultant, the Six Sigma initiative was formally launched in June 2003 with the tagline: 'Six Sigma-my customer, my priority'. The company has outlined that improving customer satisfaction is the business objective for first year of the initiative. The executive committee identified the processes that were in conjunction with this focus area. In the first phase, critical business processes were aligned with business objectives. The critical objectives identified are customer satisfaction, employee satisfaction, improving revenue and free cash. First, the projects with processes mapped against these objectives were to be undertaken. And then the quality improvement projects for existing and new products were to be undertaken. Almost 85 percent of Six Sigma projects at BBNL are based on customer satisfaction. A cross-functional team was formed to tackle each project. The team comprises a sponsor, a leader and four to five team members. The leader, also called the 'Champion' can be either a Green Belt or Black Belt. The duration for each project can range between three to four months. For the first phase the team chose 15 critical projects that offered substantial gains. Black Belts are involved full-time in the quality improvement process while Green Belts spend around 8-10 percent of time on quality improvement. A Black Belt can be engaged in two to three different projects simultaneously. Each project follows a five-phase methodology. These include defining and quantifying the problem, measuring the defect rate, i.e. the baseline. This is followed by the analysis phase where analysis is done on when, where and how the defects
6

occur. The fourth step is improvement, finding probable solutions and applying them. The final step is control in terms of sustaining the improvements. BBNL is applying Six Sigma to processes for timely complaint resolution, timely order implementation, timely invoice submission and NOC complaint resolution. When the teams started measuring critical business processes they found that the baseline was not as per customer expectations. There were gaps of around 30-40 percent in some processes. The baseline having been measured, targets were set for improving the processes. After analysing defects, process improvement kicks in. Simplifying the process instead of changing the entire process brings in the improvement. The tool essentially requires fine-tuning the process and eliminating those that do not add value. "When you are simplifying the projects productivity goes up within the same resources, thereby leading to optimum utilisation of the resources," says Juneja. One of the ways of simplifying processes is to use IT for automating processes. The executive committee continuously monitors the projects. There are monthly reviews carried out by the Champion, Sponsor and IGE. A quality dashboard has also been created, wherein every month performance is reported. The CEO and the COO monitor whether the objectives are being met. Benefits In six months BBNL had achieved timely complaint resolution 66 percent from the baseline, timely order implementation up 70 percent from baseline, timely invoice submission up 51 percent from baseline and NOC complaint resolution that was 49 percent from baseline. The Six Sigma process improvements have translated into productivity enhancements, improved customer satisfaction and process effectiveness. BBNL is targeting an estimated saving of around Rs 10 crore in the first year of operation. The target was to achieve 99 percent (i.e. approximately four Sigma level) ('First Time Right') with respect to respective set norms by March 2004 on all key critical processes. Since Six Sigma is a continuous improvement initiative, the company will be undertaking another business objective for the next financial year. On the future roadmap are Six Sigma for all processes and higher E-SAT (employee satisfaction) and C-SAT (customer satisfaction) index. BBNL plans to get almost 90 percent of the employees to be Green Belts by 2005, with almost 100 percent of the employees to be involved in the Six Sigma journey by the same time.

About the Author Niraj Goyal has 25 years of experience in multinationals in various operating roles, among them operations director of Cadbury India Ltd., where he was among the leading implementers of the quality movement. He is the founder of Cynergy Creators Private Ltd. Mr. Goyal consults in India and the United States with manufacturing, IT, media and financial services industries. He specializes in training and facilitating the implementation of the techniques of Six Sigma/TQM. Mr. Goyal can be reached at nirajgoyal@vsnl.in

CASE STUDY 3
Newspaper Focuses on Customer Service
By Niraj Goyal

Improving customer service was the focus of two projects within the deployment of Total Quality Management in a mid-sized newspaper in India. The projects involved adjusting advertisement deadlines and reducing the number of billing errors. Quality in the Total Quality Management (TQM) method is defined as customer delight. Customers are delighted when their needs are met or exceeded. The needs of the customer are: Product quality Delivery quality Service quality Cost value Improving customer service was the focus of two projects within the deployment of TQM in a mid-sized newspaper in India. This is the second piece in a three-part series of articles featuring case studies from that deployment; Part 1 of the series featured projects leading to improvements in product quality. Reducing Advertisement Processing Time The newspaper closed its window for booking advertisements at 4 p.m. every day. However, many of the newspapers advertisers expressed that they would be delighted if this limit could be extended to 5 p.m., as they were not able to send ad materials on time for the 4 p.m. deadline. The TQM leaders formed a team consisting of representatives from each link in the adprocessing chain of work. The team attended a two-day quality-mindset program to expose them to the concepts of TQM and also to open their minds about experimenting with change.

Defining the Problem In TQM, problems are defined as Problem = Desire Current status. Therefore, in this case: Problem = Desired closing time Current closing time = 5 p.m. 4 p.m. = 60 minutes The 4 p.m. deadline had been instituted because: Deadline for sending the ad pages to the press was 6:30 p.m. Standard cycle time for processing ads into pages was 2.5 hours

Achieving a 5 p.m. ad closure deadline meant reducing the standard ad processing time by 40 percent, or one hour. To define the current state, the actual time spent preparing pages to go to press was collected over several days. Defining the metric: If T = (page processing time page-to-press deadline), then for 99.7 percent on-time delivery, or 3 sigma performance, the average T + 3 standard deviations of T should be less than 0. Measure the current state: The ad closing deadline could not be delayed by an hour without delaying the dispatch of the newspaper to press by an equivalent amount. Therefore, the current state was calculated by measuring the delay compared to a notional 5:30 p.m. dispatch time rather than the actual deadline of 6:30 p.m. Calculations showed that: Average T = 72 minutes Average T + 3 sigma of T = 267 minutes

The problem was defined: reduce 267 minutes to less than 0 minutes. Analyzing the Problem The team monitored the time spent on each activity of the ad process (Table 1). Table 1: Time Spent on Ad Process Activity Ad receiving Dummy "dump" Pagination complete Deadline 4 p.m. 4:30 p.m. 6:30 p.m.

During the 4 to 4:30 p.m. period, ads received at the last minute were still being processed. At 4:30 p.m., the material was dumped into the layout for pagination, meaning arrangement on the newspaper pages using software and manual corrections. To achieve the objective of a 5 p.m. ad content deadline, the pagination time had to be reduced. Brainstorming why pagination took two hours produced three possible major reasons:

Error correction Delayed receipt of ad material for a booked ad Last-minute updates from advertiser All this work was carried out after the last ad was submitted. Team members suggested that if ads were released for pagination earlier, removing errors could begin simultaneously with the processing of the last ads in order to reduce cycle time. They agreed to give two early outputs at 3:30 and 4 p.m., before the final dump at 4:30 p.m.

Testing the Ideas Table 2: Problems with New Process Problem Missing material removal Effect Root Cause delayed or Solution not Only feed ads once all materials received Check dump for errors pre as

15 to 30 Material min. received

Error file found after last 10 min. release Special placement 10 min. instructions not followed Distorted ads in PDF 15 min.

Not checking pre dump

Processing team not aware Give instructions of special instructions received

Ads not corrected before Correct before feeding, feeding include in SOP Ads accepted after deadline Enforce deadline

Ads inserted post 20 min. pagination completion Total time possible savings 70 to 85 min.

10

The process was repeated four times (Table 3). Table 3: Further Process Observations Problem Observation 2 Repeating old practices Scanning of materials delayed PDF conversion problem Zip error file not scanned Observation 3 System failure at peak time Observation 4 Add-on delayed section integration 25 min. Start integration in preAdd to SOP dumps 75 min. Use back-up system 45 min. 15 min. Programming problem Reiterate SOPs Agree on scan turnaround time IT to resolve Zip not required Effect Root Cause Solution

Checking the Results Nine weeks of continuous implementation yielded dramatic improvement. Average processing time was reduced by an hour, from 72 minutes to 12 minutes. However, the level of variability, although 50 percent lower, was still unacceptable. Analysis of the variability showed that it was largely due to slip-ups in implementing the SOPs. Standardizing Controls The team used an x-bar control chart (Figure 1) to monitor and improve performance regularly.

11

Figure 1: Control Chart of Ad Processing Time

Gradually the performance improved. Two months after implementation, delivery time had progressed from 267 minutes late to 12 minutes early. The deadline for receiving ads could now be relaxed to 5 p.m., delighting the advertisers. Reducing Customer Complaints Management indicated that the number of credit notes given to advertisers was too high. Credit notes, issued to rectify errors made in sales invoices, were used to fend off considerable customer annoyance. But this system caused trouble for the paper. Besides increasing non-valueadded work, credit notes sometimes resulted in financial loss because customers could use the credit toward ads that had already been booked as sales. During the previous 12 months, the newspaper had received 80 credit notes per week. The team agreed to try to reduce that number by 50 percent in Phase 1. Finding the Root Causes About 200 credit notes were examined to determine why they had been issued. Categorization of the causes was charted in a Pareto (Figure 2).

12

Figure 2: Pareto Chart of Complaints Resulting in Credit

Three causes constituted 84 percent of the problem: 1. Wrong billing - 46 percent 2. Wrong rate - 24 percent 3. Wrong material used - 14 percent Table 4 shows the root causes of a majority of the credits issued, determined using the 5 Whys method, and their corresponding countermeasures. Table 4: Explanation of Credit Causes and Countermeasures 1st Why? Wrong billing 2nd Why? 3rd Why? Countermeasure

Unbilled charge picked up; Discount applied incorrectly System bug to all ads in series Sales scheme not in sales card; Old scheme continues after updating of sales rate card; Scheme in rate card but not picked up by system System does not pick up operator entry

Removed

Wrong rate

Sales cards not updated; Bill system SOP does not pick up entry Modify system to pick up operator's entry when prompted, rather than automatically taking billing information from the rate table.

Free ads billed

13

The team tested the ideas, which resulted in an 80 percent reduction in credit notes, from 80 per week to 14 per week. The process was adopted in regular operation, and the results were documented and presented to senior management. Change in Thinking TQM often leads to radical changes in employee mindsets. The improvements resulting from the two customer service-related projects helped to create a team environment in which any change idea is easily accepted, tested and if it works implemented.

14

CASE STUDY 4
Reducing IT User Downtime Using TQM
by Niraj Goyal

This IT case study was done during the implementation of TQM in a financial services company with several hundred computers and computer users in multiple locations throughout India. The results have widespread applicability. This Information Technology (IT) case study was done during the implementation of Total Quality Management (TQM) in a financial services company with several hundred computers and computer users in multiple locations throughout India. The results have widespread applicability and in particular are aimed at organizations with large computer networks, IT facilities management companies and customer service providers. Success in any improvement effort is a function of techniques accompanied by a mindset change in the organization. This project was undertaken as part of the second wave of projects aimed at spreading the quality mindset in the organization. The narrative unfolds in the chronological sequence of TQM's Seven Steps of Problem Solving (similar to DMAIC in Six Sigma), describing the critical process stages where results were achieved and mindsets changed. Step 1 - Define the Problem Selecting the theme: After an initial two-day TQM awareness program, the company's senior management selected a theme by consensus: "Dramatic Improvements in Customer Service." As part of the theme, one of the improvement areas selected was "Reducing the response time to resolve IT (hardware and software) problems faced by internal customers." The company had outsourced its network and facility management. A small technical services management team and "help desk" oversaw the vendors' work. Problem = Customer desire - actual status: Detailed data was available regarding the time of receipt of each call from the customer (in this case, the network users) and the time of call closure. Monthly management reports aggregated the performance by enumerating the number of calls that were resolved in the following categories: < 30 Mins. < 60 Mins.

Call Closure Time

< 2 Hours

> 2 < 24 Hours Hours

< 48 > 48 Hours Hour

15

While the information about what happened was well recorded, there was no information about what users had desired to have happen. The deviation from user desires or even the service standard promised to users was not measured. Defining the problem therefore resulted in a changed mindset from data being used just as an internal record to measuring and "assuring a service standard to the user." The calls were categorized into groups that would be expected to have a service standard time of closure as defined in the table above. A month of data was analyzed by subtracting the service standard time expected to be delivered and the actual time taken to resolve each call. The gaps between the actual closure time and the standard time were a measure of the problem. It was clear that the data needed to be prioritized in order to proceed. A Pareto diagram was drawn (Figure 1). It indicated that two categories < 30 minutes (67%) and > 120 minutes (27%) constituted 87% of the incoming load. It was decided to attack the < 30 minutes category first.

Definition of metrics: In order to define clear metrics, the concept of sigma was introduced to represent variability in timeliness of service. It was quickly grasped by the group that a 3-sigma standard translates into a 99.7 percent on-time performance. (Average + 3 sigma) of the actual closure times should be less than the service standard. This meant that for the < 30-minute call category: If T30 = average + 3 sigma of 30-minute calls' closure times T30 < 30 minutes for a 99.7 percent on time performance The past month's data revealed: T30 = 239 minutes The objective was now clearly defined: Reduce T30 from 239 to <30, i.e. by 85 percent
16

Dividing the Task into Phase A and Phase B Since making such a big reduction was too daunting a task for a team embarking on its first project, using the concept that "improvement occurs step by step," the initial objective, or Phase A, was to reduce T30 by 50 percent. A project charter was drawn up accordingly. Step 2 (Phase A) - Analyze the Problem: The T30 calls were arranged in descending order according to actual time of closure. Those calls that had taken more than 30 minutes were segregated for analysis. It was recognized that the problem of quality was one of variability, and that the most effective solution to the problem would be ending the causes of calls with a very high time of closure. Thus, T30 calls that had taken more than 130 minutes (T30:130) were analyzed first (Figure 2).

The top three categories contributed approximately 75 percent of the problem. To sequence the order of attack, the group chose "big and easy" to precede "big and difficult" problems. Using that criteria, "Not Aware of Change Rule" was chosen. Step 3 (Phase A) - Find the Root Cause: In these cases the engineer attending to the call had not closed the call after attending to it. The "Five Whys" technique was used to determine the root cause - Why had he not closed the call? Why was he not aware that he was supposed to close the call? Why was the procedure of call closure changed and he was not informed? Why is there no standard operating procedure to inform employees before closing the call? Step 4 (Phase A) - Generate and Test Countermeasure Ideas: Countermeasures were easily identified - first, inform all the engineers; second, develop a standard procedure for informing all users before making a change in procedure which affects them. The engineers were informed of the new procedure.

17

Step 5 (Phase A) - Check the Results: The next three weeks showed a dramatic drop in the T30 value from 239 to 121 minutes. The objective of 50 percent reduction had been achieved. Step 6 (Phase A) - Standardize the Results: A standard operating procedure was drawn up for future reference. An X Bar control chart (Figure 3) was introduced for routine day-to-day control. Step 7 (Phase A) - Present a Quality Improvement Report: Drawing up the quality improvement report was deferred due to the project being continued to attempt to make further improvements Figure 3: Control Chart for 30-Minute Calls (September)

Phase B to Further Reduce Downtime Step 2 (Phase B) - Analyze the Problem: The second phase of the project, or Phase B, was to reduce the T30 value by 50 percent again, from less than 120 minutes to less than 60. The T30 calls which took more than 30 minutes to close were collated and arranged by category in descending order of time to close. There were two categories with the following data: Categories Log-in Printing Calls 39 16 Minutes 2720 1672 Minutes/Call 70 104

Based upon the "big and easy" principle, the group chose to attempt the printing problem first. The printing calls were sub-categorized by "location" and then by "solution" since they had already been resolved. Seven of the 16 calls were from Location 1,and seven of the 16 calls had been solved using the same remedy - reinstalling the printer driver.
18

Step 3 (Phase B) - Finding the Root Cause: Why did the printer driver need frequent reinstallation? The group brainstormed and generated 10 possible causes. A check sheet to collect data was designed. For the next two weeks, the engineers were asked to record the reason of why the printer driver needed to be reinstalled each time they were attending to such a call. Step 3 (Phase B) - Finding the Root Cause: Why did the printer driver need frequent reinstallation? The group brainstormed and generated 10 possible causes. A check sheet to collect data was designed. For the next two weeks, the engineers were asked to record the reason of why the printer driver needed to be reinstalled each time they were attending to such a call. Figure 4: Control Chart for 30-Minute Calls (October)

When reviewed, the data surprised the group members. It clearly illustrated the superiority of data-based problem-solving over intuitive problem-solving. And it acted as a major mindset changer. The problem, the data showed, was that the printer was going off-line rather than its driver needing reinstallation. Why was the printer going off-line? Brainstorming quickly produced the cause: The machines being used had three versions of the Windows operating system - 98, 2000 and XP. In the Windows 98 version there was a problem - if a user tried to print without logging-in, the printer would go off-line and the next user would experience the problem. The cause was quickly confirmed as the root cause by one of the members trying to print without logging- in. Step 4 (Phase B) - Generate and Implement Countermeasure Ideas: The group discussion produced the idea of adopting a software change to not allow a user to try printing without logging-in. All the machines using Windows 98 were identified, and the change was implemented. Applying the standard operating procedure used in Phase A, the group was careful to inform all users of the change before implementing it.
19

Step 5 (Phase B) - Check the Results: The calls were monitored for another two weeks and the results amazed the group. The data showed a dramatic drop of the T30 value from 121 to 47 minutes (Figure 4). A total reduction of 80 percent had been obtained in the T30 value. The question arose why had the reduction been much more dramatic than the data as per the Pareto chart would indicate. There are two reasons: 1. While the problem-solving method identified the vital problems using the calls that took a long time to resolve, there were undoubtedly many calls with the same problem and cause that were attended to within the standard time and therefore did not show in the analysis. 2. The system of daily control chart plotting and review with the engineers and the group raised the awareness of timeliness and thereby increased the urgency for a solution. Step 6 (Phase B) - Standardize the Results: A standard procedure was developed and circulated to all regions to implement the change at all locations. Step 7 (Phase B) - Present a Quality Improvement Report: A quality improvement report was written and presented to the Steering Committee. Future Work and Conclusions The work of the group is continuing in the following directions: 1. The T30 calls are now being analyzed to further reduce the time. Two interesting solutions are emerging that promise to cut the downtime further. 2. T60 calls are now under study. The average + 3 sigma of closure time of this category has been measured at 369 minutes. Work is being done to reduce it to < 60 minutes. This case study demonstrates several principles of TQM and Six Sigma: 1. What cannot be measured cannot be improved. (Establishing service standards and the use of sigma and control charts for on-time delivery of services were essential in making improvements.) 2. It is important to develop customer-oriented metrics. 3. Mindset change is crucial to the success of any improvement effort. 4. Standardizing the improvement can take longer than the improvement itself. (It is still continuing in this application.) 5. There is value in step-by-step improvement and continuous improvement.

20

CASE STUDY 5
Fixing Payroll Problems: A TQM Case Study in Human Resources
By Niraj Goyal The following case study details a consumer goods companys experience using the TQM methodologys Seven Steps of Problem Solving in its human resources department to address the payroll process. A large, Indian, fast-moving consumer goods company had completed successful Total Quality Management (TQM) projects to improve its manufacturing efficiency, expedite vendor payments and increase availability of finished products. For its next project, the company wanted to address problems in human resources (HR). By working with HR process owners, a focus for the project emerged the payroll process. The following case study details the companys experience using the TQM methodologys Seven Steps of Problem Solving to address the issue. Pre-step 1: Select the Problem After attending an introductory two-day training program in TQM, the project leader asked the companys HR employees to brainstorm key problems in human resources. They also considered the results of each problem (Table 1). Table 1: Problems in the Payroll Process Problem Accuracy of data Delayed output Functioning of payroll centralization process Manual data generation Follow-up on data High recruitment turnaround Lack of standard operating procedures (SOPs) Communication Delayed response to employees Delay Delay Errors Result 1 Delay Delay Delay Delay Delay Result 2 Errors

21

From this list, the group could see that the real problem was that internal customers were facing delays and errors. The group went on to brainstorm and prioritize the major areas of errors and delay within HR (Table 2). Table 2: Prioritized Areas Where Employees Encounter Errors and Delays Problem Area Employee database Payroll Separation Recruitment transfers Budget Talent development Performance management Communication Training Reimbursements Score 169 139 125 117 114 113 98 90 64 63

Discussion revealed that the employee database is not a problem in itself; the team decided to tackle the payroll process instead. HR employees told the group that completing their job each month without delays or errors required a lot of pressure and running around. A representative group from the finance department, the payroll manager, key payroll personnel and the four regional HR managers were selected for the project team. A leader and secretary were nominated, and the team began meeting every other week. Step 1 Defining the Problem In TQM, a Problem = Desire Actual Status; problems also must be measurable. The team faced the challenge of measuring undue pressure on behalf of the payroll employees. They decided that the metric employee overtime could represent this pressure. The team set out to record how much overtime each employee was incurring daily and what activities they worked on during that overtime. Measurements during the first month yielded an average of 36 minutes of overtime per person per day. This average did not appear so bad. In reality, however, the problem was the peaks rather than the average. Employees tend to remember the stressful days when overtime is high. To get a
22

better picture, the team calculated a standard deviation of 18.8 minutes. This meant that on the worst days, overtime was an average of 92 minutes per person (average + 3 standard deviations) and on those days there were two or three employees whose overtime was much higher than 92 minutes. Therefore, the team decided to work to reduce the average + 3 standard deviation limit to address the problem. They set a Phase 1 target to reduce the average + 3 standard deviation time by 50 percent. Step 2: Finding the Root Causes The team mapped overtime activities in a Pareto diagram to ascertain the vital causes (Figure 1). Table 4 shows the top 7 causes accounting for 81% of the OT. Figure 1: Overtime Activities

23

Table 3: Top Seven Overtime Causes Problem Recruitment Meetings Data crunching Employee relations Master changes in SAP Special projects Head office formats Overtime Percent 17 16 14 14 10 5 5

Recruitment necessitated after-hours interviews, while meetings involved other departments not yet trained in TQM. The causes that the team could change were data crunching, master changes in SAP (the enterprise resource planning program) and repeated changes in data formats requested from the head office. These three areas constituted 29 percent of the overtime and were addressed first. Sixty percent of the overtime in these areas emanated from two regions; another 35 percent came from two employees in the head office. Why? The other region representatives explained that they had put in a special one-time effort to develop data entry and storage formats for the diverse information requested by the head office to reduce future data crunching. They shared this standardized formatting with the two lagging regions to reduce their overtime. But why were the regions developing formats in the first place? Were the formats not present already? The team mapped the current process steps: 1. Regions enter changes to be made in the SAP personnel master into an Excel sheet 2. Excel sheet sent to head office 3. Head office employees enter data into SAP before the payroll each month. The payroll employees face intense pressure due to gaps and errors in the data entry. Step 3: Countermeasure ideas The team suggested a two-phase process change using just-in-time principles: Phase 1: Replace batching with flow processing. With this method regions enter and send data weekly, and the head office enters weekly, without waiting until the end of the month. Phase 2: Eliminate non-value added stages. Eventually, the regions should be able to enter data directly into SAP weekly, and the head office will enter its own entries weekly.

24

Steps 4 and 5: Testing Ideas and Checking Results The countermeasure ideas took two months to test. An X-bar control chart was introduced to track the average overtime per person per day. The chart showed a 48 percent reduction in average time + 3 standard deviations, from 92 minutes to 50 minutes. Step 6: Standardizing Operations The 3 standard deviation limit was maintained. Simultaneously, however, employees were also experiencing stress and working overtime due to errors or incomplete entries during the payroll run and frantic queries for the correct information. Finding the most frequent errors, their root causes and countermeasures would eliminate this problem. The team selected the metric errors per query per payroll. There were 65 in the first run. Following is an example of an error, its cause and the countermeasure the team developed to resolve it:

Error: Incorrect deduction of lunch coupons Number of occurrences: 11 in two months, or 15 percent of total errors Root cause analysis:All errors occurred in one region. The region with errors gave lunch coupons at the beginning of the month, while other regions gave them at the end of the month, thus making the accounting foolproof. Countermeasure: Adopt standard process Check the result: No errors post implementation. Within three months, errors and queries were reduced by 98 percent from 65 per payroll run to 1. Regular progress tracking was introduced (Figure 2). Figure 2: Errors and Queries Per Payroll Run

25

Step 7: Maintain Improvements The team compiled the improvement results and presented them to management. In the future, the payroll manager will meet with the staff after each Payroll run to analyze and address any errors that are occurring. The overtime control chart will be plotted every day, and any unusual spikes also will be analyzed and addressed. The project also led to changes in the mindsets of the employees involved. For instance, after the project, the human resources director remarked how one of the participants made an error in his work and reported it, along with a 5 Why and countermeasure analysis something that would never have happened earlier.

26

CASE STUDY 6
Improving Financial Services Through TQM: A Case Study A young, rapidly expanding company in the financial services sector with no previous experience with Total Quality Management takes its first steps toward TQM. And it immediately learns the value of a formal program to improve quality. By Niraj Goyal and Lalitha Bhatia The work described in this case study was undertaken in a young, rapidly expanding company in the financial services sector with no previous experience with Total Quality Management (TQM). The quality project began with a two-day introductory awareness program covering concepts, cases, implementation strategies and imperatives of TQM. The program was conducted for the senior management team of the company. This program used interactive exercises and real life case studies to explain the concepts of TQM and to interest them in committing resources for a demonstration project. The demonstration project, which used the Seven Steps of Problem Solving (similar to DMAIC), was to show them how TQM concepts worked in practice before they committed resources for a company-wide program. Main Components of TQM For Six Sigma practitioners who may not be familiar with TQM, the program has three main components -- Just in Time (JIT), Total Quality Control (TQC) and Total Employee Involvement (TEI). The relationship between the three legs of TQM is: JIT exposes the cause of problems; TQC helps provide a solution to problems. Lastly, since the employees do all improvements; they need to be involved in the process of change. TEI helps elicits this involvement. JIT uses techniques similar to Lean, and TQC uses tools and techniques similar to Six Sigma tools.

Step 1. Define the Problem

1.1) Selecting the theme: A meeting of the senior management of the company was held. Brainstorming produced a list of more than 20 problems. The list was prioritized using the weighted average table, followed by a structured discussion to arrive at a consensus on the two most important themes -- customer service and sales productivity. Under the customer service theme, "Reducing the Turnaround Time from an Insurance Proposal to Policy" was selected as the most obvious and urgent problem. The company was young, and therefore had few claims to process so far. The proposal-to-policy process therefore impacted the greatest number of customers. An appropriate cross functional group was set up to tackle this problem. 1.2) Problem = customer desire - current status: Current status: What did the individual group members think the turnaround is currently? As each member began thinking questions came up. "What type of policies do we address?" Medical
27

policies or non-medical? The latter are take longer because of the medical examination of the client required. "Between what stages do we consider turnaround?" Perceptions varied, with each person thinking about the turnaround within their department. The key process stages were mapped:

Several sales branches in different parts of the country sent proposals into the Central Processing Center. After considerable debate it was agreed at first to consider turnaround between entry into the computer system at the Company Sales Branch and dispatch to the customer from the Central Processing Center (CPC). Later the entire cycle could be included. The perception of the length of turnaround by different members of the team was recorded. It averaged: Non-Medical Policies 17 days Medical Policies 35 days Invoking the slogan from the awareness program "In God we trust, the rest of us bring data" the group was asked to collect data and establish reality. Armed with a suitably designed check sheet they set about the task. Customer desire: What was the turnaround desired by the customer? Since a customer survey was not available, individual group members were asked to think as customers -- imagine they had just given a completed proposal form to a sales agent. When would they expect the policy in hand? From the customer's point of view they realized that they did not differentiate between medical and non-medical policies. Their perception averaged out six days for the required turnaround. "Is this the average time or maximum time that you expect?" they were asked. "Maximum," they responded. It was clear therefore that the average must be less than six days. The importance of "variability" had struck home. The concept of sigma was explained and was rapidly internalized. For 99.7 percent delivery within the customer limit the metric was defined. Customer desire: Average+3 Sigma turnaround = less than 6 days

Current status:
28

Non-medical policies (Average 19/Sigma 15) Average+3 sigma= 64 days Medical (Average 37/Sigma 27) Average+3 sigma= 118 days The Problem was therefore defined: Reduce Average+3 sigma of turnaround for: Non-Medical Policies From 64 to 6 days Medical Policies From 118 to 6 days The performance requirement appeared daunting. Therefore the initial target taken in the Mission Sheet (project charter) was to reduce the turnaround by 50 percent -- to 32 and 59 days respectively.

Step 2. Analysis of the Problem

In a session the factors causing large turnaround times from the principles of JIT were explained. These were:Input arrival patterns Waiting times in process - Batching of work - Imbalanced processing line - Too many handovers - Non-value added activities, etc. Processing times Scheduling Transport times Deployment of manpower Typically it was found that waiting times constitute the bulk of processing turnaround times. Process Mapping (Value Stream Mapping in Lean) was undertaken. The aggregate results are summarized below: Number of operations 84 Number of handovers 13 In-house processing time (estimated) 126 man-mins. Range of individual stage time 2 to 13 mins. Could this be true? Could the turnaround be 126 minutes for internal processing without waiting? The group started to question of the status quo. The change process had begun. To check this estimate it was decided to collect data -- run two policies without waiting and record the time at each stage. The trial results amazed everyone: Policy No. 1 took 100 minutes and Policy No. 2 took 97 minutes. Almost instantly the mindset changed from doubt to desire: "Why can't we process every proposal in this way?"

Step 3. Generating Ideas

In the introductory program of TQM during the JIT session the advantages of flow versus batch processing had been dramatically demonstrated using a simple exercise. Using that background a balanced flow line was designed as follows:
29

1. Determine the station with the maximum time cycle which cannot be split up by reallocation -8 minutes. 2. Balance the line to make the time taken at each stage equal 8 minutes as far as possible. 3. Reduce the stages and handovers -- 13 to 8. 4. Eliminate non-value added activities -- transport -- make personnel sit next to each other. 5. Agree processing to be done in batch of one proposal. Changing the mindset of the employees so they will accept and welcome change is critical to building a self-sustaining culture of improvement. In this case, the line personnel were involved in a Quality Mindset Program so that they understood the reasons for change and the concepts behind them and are keen to experiment with new methods of working. The line was ready for a test run.

Step 4. Testing the Idea

Testing in stages is a critical stage. It allows modification of ideas based upon practical experience and equally importantly ensures acceptance of the new methods gradually by the operating personnel. Stage 1: Run five proposals flowing through the system and confirm results. The test produced the following results: Average turnaround time: < 1 day In-house processing time: 76 mins. There was jubilation in the team. The productivity had increased by 24 percent. The head of the CPC summarized: "I gave five files for processing, and went for a meeting. Emerging from the meeting about 30 minutes later I was greeted by the dispatch clerk jubilantly reporting, "'Madam, the TQM files are ready for dispatch.'" The mindset was dramatically changed and line personnel were now keen to push the implementation. Stage 2: It was agreed to run the new system for five days -- and compute the average and sigma of the turnaround to measure the improvement. It was agreed that only in-house processing was covered at this stage and that the test would involve all policies at the CPC but only one branch as a model. This model, once proved, could be replicated at other branches. The test results showed a significant reduction in turnaround: 1. For all non-medical policies From 64 to 42 days or 34% 2. For policies of the model branch From 64 to 27 days of 60% The Mission Sheet goal of 50 percent reduction had been bettered for the combined model branch and CPC. Further analysis of the data revealed other measures which could reduce the turnaround further. Overall reduction reached an amazing 75 percent. Turnaround, which had been pegged at 64 days, was now happening at 99.7 percent on-time delivery in 15 days.

Step 5. Implementing the Ideas

Regular operations with the new system was planned to commence. However, two weeks later it was still not implemented. One of the personnel on the line in CPC had been released by his
30

department for the five-day trial to sit on the line but was not released on a regular basis. The departmental head had not attended the TQM awareness program and therefore did not understand why this change was required. There were two options -- mandate the change or change the mindset to accept the change. Since the latter option produces a robust implementation that will not break down under pressures it was agreed that the group would summarize TQM, the journey and the results obtained in the project so far and also simulate the process with a simple exercise in front of the department head. This session was highly successful and led to the release of the person concerned on a regular basis.

Step 6. Check the Result

The process was run for one month with regular checks. The results obtained were marginally better than the trials conducted in Step 5: Average 11 days Sigma 9 days Average+3 sigma 38 days

Step 7. Standardize Control/Document the Improvement Story

Essentially the in-house processes in two centers of processing -- the CPC and one sales branch - had been impacted so far. To make sure that the gains were held, control charts were introduced in both locations. Sample x-bar and sigma-control charts for the CPC are shown below:

A special "Grind It In" session was conducted for line personnel to ensure that the control chart was updated every day, and any deterioration was dealt with by finding and killing the root causes of the problems.
31

Customer reaction: Sales management and sales agents (internal customers) clearly noticed the difference. For instance one sales manager reported that a customer had received a policy within a week of giving a proposal and was so amazed that he said, "If you give such service I will give you the next policy also!" Adoption of a similar process at the CPC and the model branch for medical policies has already reduced the average+3 sigma of turnaround time by 70 percent -- from 118 days to 37 days. The corresponding all-India reduction was from 118 days to 71 days -- a 60 percent reduction. The project objective of 50 percent in the first stage has been achieved. A quality improvement story was compiled by the project Leader for training and motivating all employees.

Future Actions Non-medical policies: Goal to reduce turnaround from 42 days to about 15 days. 1. Roll out process to branches to achieve 24 days throughout the country. 2. Minimize rework by analyzing, prioritizing and training sales branches to avoid the causes of rework. 3. Working with the bank to improve the turnaround time of banking checks. 4. Considering processing proposals while check clearance is in progress. Medical policies: Goal to reduce turnaround from 71 days to about 24 days. 1. Roll out process to branches to reduce turnaround from 71 to 37 days. 2. Streamline the process of medical exam of the client from 37 to 24 days.

32