Today’s industrial black belt typically trains for six months. Seventy-five percent of this training time is spent learning theory, and the balance is spent in practice. Often when the black belt returns to the real world to tackle inefficiencies, he finds that there are no takers for his logic and passion – his Six Sigma entreaties fall on deaf ears. She begins to wonder how one can get started and realizes that the struggle to change the mindset is as important as the actual improvements themselves.

This case study will show that demonstrating breakthrough business results is the best way of changing a company’s long-term mindset about the value of Six Sigma. This case study is an example of a breakthrough improvement in a medical transcription company in India. It unfolds in the same chronological sequence as in real life, pointing out the critical stages where mindsets changed and how this was achieved. This experience set the company firmly on the road to achieving world-class performance using the techniques of Six Sigma and Lean Enterprise.

Introduction

The Medical Transcription business consists of receiving dictations from doctors, transcribing them according to set rules, editing the output for errors, and transmitting it back to the sources of the recordings. Turnaround times typically demand that recordings are returned by the start of the next working day. Quality obviously is important as mistakes can affect the treatment of patients.

On a Wednesday morning Mr. PTT, the MD of Xtel Technologies (names changed), a Medical Transcription company based in India with customers in the US, had walked into his office at 9 a.m. As usual he glanced over yesterday’s performance:

“The incoming load was heavy…that is good for revenues. But the deliveries were late again.”

He was about to call in his bleary eyed staff for a rerun of their often repeated discussion on dispatch schedules – absenteeism, tough doctors, too much load, etc. – when the phone rang. Answering the long distance caller’s query about his company’s performance in meeting their needs, he remembered noticing the e-mail entitled “Breakthrough Improvements in Business Performance” a couple of days ago and, yes, he was interested in finding out how it could apply to his business.

Two weeks, a meeting, and a presentation later the dice were cast. Xtel Industries committed itself to trying the Six Sigma quality approach and measuring the return for his business.

The Journey Begins

A two-day introductory program covering the concepts, cases, implementation strategies and imperatives of Lean/Six Sigma was conducted for the 20 most senior personnel of the organization. This program proved simple, interesting and powerful, using interactive exercises and real life case studies to excite the interest and enthusiasm of the group. The meeting also committed resources for a demonstration project facilitated by the external consultant. If the improvements were large enough then the full program would be undertaken.

From here on the narrative follows the seven steps of problem solving in the same sequence as occurred during the project:

Step 1: Define the Problem

1.1 Selection of the theme (CTQ) and the customer line to be tackled. A meeting of the senior management of the company was held and a brainstorming session produced a list of more than 20 problems. These were affinitized into two categories:

• End result problems faced by external customers
• Internal problems that were causes of customer problems, rather than basic problems themselves.

The realization that the first category (customer focus) of problems had to be attacked came spontaneously. Prioritization using the weighted ranking system and a quick discussion produced consensus on the CTQs – “Consistency of Quality and Timeliness.”

Between the two CTQs, Timeliness (i.e., turnaround time) was agreed to be addressed first. The largest volume practice (Practice A) was chosen for attack and a suitable cross-functional team was formed.

1.2 Precise definition of the problem as per the equation: Problem = customer desire – current state. This step necessitates the definition of the appropriate metrics. Customer desire: what was the turnaround desired by the customer? Individual group member perceptions were queried, recorded and summed up: “The customer expects dispatch by 5:30 p.m. every day.”

This led to the question: “Which data was to be dispatched by 5:30 p.m. every day?” After a lot of discussion it was agreed that the customer desire precisely stated was that recordings received between 7:30 a.m. on day X and 7:30 a.m. on Day (x+1) must be dispatched by 5:30 p.m. on day (x+1).

What is turnaround? Turnaround was defined as the time taken from receipt to dispatch of a file. This meant files received at the 7:30 a.m. on day X could have a turnaround of 34 hours compared to only 10 hours for the files received at 7:30 a.m. on day X+1. So what was the turnaround expected of the process?

Suddenly clarity emerged in the group. The problem was “meet the dispatch deadline of 24 hours of data” rather than “reduce turnaround of data.” Preliminarily the metric suggested was a very simple one: Discrepancy between time of dispatch and the customer’s deadline (i.e., 5:30 p.m.)

Measure the Current State: A suitable check sheet was designed and data for the actual time of dispatch was collected for two weeks. When compared to the target there was a wide variation in the performance.

Average delay = 89 minutes, and the concept of variability, sigma and quality as a distribution was introduced. Calculations showed:

sigma = 82 minutes

Thus (average + 3 sigma) = 335 minutes.

Problem definition: For 99.7 percent on time delivery, we would need to reduce 335 minutes to zero. In fact this would mean 99.85 percent on time delivery, as earlier dispatches were not a problem and therefore only one side of the normal curve needed to be taken into consideration.

Step 2: Analyze the Problem – Why? Why? Why? Why? Why?

A brainstorming session produced variety of causes: absenteeism, peaking of loads on some days, inefficient transcriptionists not delivering the expected outputs, drowsiness during the night shift, lack of supervision in the night shift, planning and allocation of files, too little capacity, doctors that were tough to understand, etc. Attempts to relate one or other to the data collected led to confusion, as the data was not detailed enough. A more detailed data collection was therefore undertaken to unearth the vital causes of the problems. A check sheet was developed to record the following: start time of processing, input loads, transcriptionists allocated and present, capacity per transcriptionist, and the finishing time.

These were observed for several days. A glance at the neatly compiled data for the first week revealed one surprising fact – the bulk of the data collected between 7:30 a.m. on day X and 7:30 a.m. on day X+1, which was to be dispatched by 5:30 p.m. on day X+1 started processing by design only at 8:00 a.m. on day X+1. Severe batching was occurring. What was the vital problem one of batching? Would converting to flow solve a large part of the problem?

The query “can processing begin earlier?” prompted the reply, “the data comes from U.S., and doctors tend to dictate at the end of the day and this corresponds to AM in terms of Indian time. Therefore, not much data is available for processing during the night.”

Invoking the slogan “In God we trust, the rest of us bring data!” the group was asked to collect the arrival pattern of data from the U.S. every hour for a week. A check sheet was designed, hardware and logistics difficulties were overcome, and the data was collected. The figures proved to be a revelation in more senses than one. The voice recordings were coming in a steady stream from 7:30 p.m. Indian time on day X-1 to 7:30 a.m. on day X, peaking typically between midnight and 2 a.m. Suddenly the old mindsets were shattered and new ideas could begin forming.

Step 3: Generate Ideas

Applying the Lean principle of Batch to Flow, processing could begin at about 8:00 p.m. as the data was flowing in rather than 8:00 a.m. the next day when all the data was in. This could give a lot of leeway to improve the dispatch timings. Based upon the average arrival pattern of data two alternatives were suggested:

• Bring two teams during the night shift and one during the day shift
  OR
• Bring one team at night, one in for an early morning shift, and one in the day shift.

The former idea was preferred.

Step 4: Testing The Idea

There was a feeling among the participants that lower efficiencies resulted in the night due to the nature of the work. This was put to the test; detailed hour-to-hour data was collected. Again the readings demonstrated that lower outputs, whenever they occurred were mostly due to other reasons like non-routine work rather than basic deterioration in efficiencies. In fact in a majority of cases the expected outputs were achieved, and even in some cases surpassed the expected outputs.

With this background the test was begun. A clear demonstration of the senior management commitment to the process was that they went into the night shift to ensure that operational issues with assignable causes were sorted out expeditiously and did not interfere with the results of the trial.

The first two days of testing were so successful that dispatches were made up to two hours before schedule. It was at this stage the mindset really changed among the group. They decided on their own to waste no further time and extend the trial into routine operation.

Step 5: Implementation Plan

Regular production was commenced. The record of dispatch timings rapidly improved as smaller operating issues were ironed out. And a very useful by-product of the effort resulted: On the occasions when the data inflow for Practice A was low and the transcriptionists were idle, some data from other practices started to be fed to them for processing.

The “flow” started spreading through the entire operation. Flexibility between operators grew, and the timings of all practices started to improve.

Step 6: Review The Results

Once the operation had settled down data was collected. The third week after the changes (blue line) were compared to the week before the project began (red line) and revealed a dramatic improvement in dispatch timings, as shown below:

The system handled:

• 22 percent higher load
• 33 percent higher peak load
  With
• Average dispatch 134 minutes early compared to 89 minutes late
• 99.7 percent (average + 3 sigma) delivery on time compared to 335 minutes late

The project objective had been achieved.

Step 7: Standardize Control And Document The Improvement Story

A six-day moving average control chart was introduced to monitor the process and ensure that deterioration in process performance was quickly detected and resolved.

A special training session entitled “Grind it in!” was conducted with the line personnel, and provided instruction on how to plot the control charts. A format was prepared for a regular quality report to senior management, and a Standard Operating Procedure was developed to ensure regular review of performance. Finally, a quality improvement story was compiled by the project leader for training purposes and to help motivate employees in other practices.

Future Action

Just as the journey of quality never ends, improved performance only creates even higher customer expectations. The group has now resolved to improve the quality (i.e., reduce errors) for this practice to unleash the famous Lean-Six Sigma connect. Improving the quality will reduce rework and inspection and thereby further improve productivity and turnaround.

And last but not least, official recognition of the good work done by the group and Six Sigma’s impact on the company was made in an evening get-together of the employees and senior management. At this meeting the benefits from the Six Sigma approach were narrated and the resolve to continue using it was communicated. The process had taken firm root.