tqm cases 1

TQM CASE STUDIES

SUHAS CHOWDHARY.J

215110068

DoMS, NIT Trichy

1

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?"

2

"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 step-

through 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

3

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 ISO-

certification 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."

4

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 self-

assessment 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

5

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?"

6

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

7

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.

8

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 [email protected]

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 newspaper’s 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 ad-

processing 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.

9

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 Deadline

Ad receiving 4 p.m.

Dummy "dump" 4:30 p.m.

Pagination complete 6:30 p.m.

10

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 Effect Root Cause Solution

Missing material removal 15 to 30

min.

Material delayed or not

received

Only feed ads once all

materials received

Error file found after last

release 10 min. Not checking pre dump

Check for errors pre

dump

Special placement

instructions not followed 10 min.

Processing team not aware

of special instructions

Give instructions as

received

Distorted ads in PDF 15 min. Ads not corrected before

feeding

Correct before feeding,

include in SOP

Ads inserted post

pagination completion 20 min. Ads accepted after deadline Enforce deadline

Total time savings

possible

70 to 85

min.

11

The process was repeated four times (Table 3).

Table 3: Further Process Observations

Problem Effect Root Cause Solution

Observation 2

Repeating old practices Reiterate SOPs

Scanning of materials delayed 45

min.

Agree on scan turnaround

time

PDF conversion problem 15

min. Programming problem IT to resolve

Zip error file not scanned Zip not required

Observation 3

System failure at peak time 75

min. Use back-up system

Observation 4

Add-on section integration

delayed

25

min.

Start integration in pre-

dumps Add to SOP

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.

12

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-value-

added 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).

13

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? 2nd Why? 3rd Why? Countermeasure

Wrong

billing

Unbilled charge picked up;

Discount applied incorrectly

to all ads in series

System bug Removed

Wrong

rate

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

Sales cards

not updated;

Bill system

does not pick

up entry

SOP

Free

ads

billed

System does not pick up

operator entry

Modify system to pick up operator's

entry when prompted, rather than

automatically taking billing

information from the rate table.

14

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.

15

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:

Call

Closure Time

< 30

Mins.

< 60

Mins.

< 2

Hours

> 2

Hours

< 24

Hours

< 48

Hours

> 48

Hour

16

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

17

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.

18

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 Calls Minutes Minutes/Call

Log-in 39 2720 70

Printing 16 1672 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.

19

Step 3 (Phase B) - Finding the Root Cause: Why did the printer driver need frequent re-

installation? 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 re-

installation? 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.

20

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.

21

CASE STUDY 5

Fixing Payroll Problems: A TQM Case Study in Human Resources

By Niraj Goyal

The following case study details a consumer goods company’s experience using the TQM

methodology’s 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 company’s experience using the TQM methodology’s 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

company’s 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 Result 1 Result 2

Accuracy of data Delay Errors

Delayed output Delay

Functioning of payroll centralization process Delay

Manual data generation Delay

Follow-up on data Delay

High recruitment turnaround

Lack of standard operating procedures (SOPs) Delay Errors

Communication

Delayed response to employees Delay

22

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 Score

Employee database 169

Payroll 139

Separation 125

Recruitment transfers 117

Budget 114

Talent development 113

Performance management 98

Communication 90

Training 64

Reimbursements 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

23

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

24

Table 3: Top Seven Overtime Causes

Problem Overtime Percent

Recruitment 17

Meetings 16

Data crunching 14

Employee relations 14

Master changes in SAP 10

Special projects 5

Head office formats 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.

25

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

26

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.

27

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

28

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:

29

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:

30

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

31

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.

32

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.