Lean Six Sigma (LSS) teams focus on the statistical analysis of metrics when identifying opportunities for improvement. The strong focus on data-driven evaluation, however, can overshadow the human element that exists behind the data collection plan. Despite its importance, the impact of human interaction is not easily visible or quantified, buried under reams of data. The common expression “numbers do not lie” may be true, but a clear understanding of where the numbers came from, and of the human factors involved, is required to reveal the truth in the data, as demonstrated in this case study.

Data Vs. Performance

Due to a rising occurrence of late deliveries, Company X initiated an investigation of a process that was failing to meet the required output on time. The process was considered stable and capable of meeting customer requirements until the past two months. There were no records of recent changes that could account for this downward performance trend, making it more difficult to pinpoint the cause or causes of failure.

The leader of the project investigating the process decided to perform a cycle time study by accessing the process database (“desktop time study”) in lieu of a plant visit. The desktop time study was repeated multiple times with similar results each time.

The desktop time study focused on the process start and end time stamps. At initial glance, the data showed capability to meet the required lead time without the need for additional resources. There also was a high level of confidence in the accuracy of cycle times since the data had come from computer time stamps before and after completion of each task. To everyone’s dismay, however, the wave of late shipments persisted.

Due to the incongruity between the data and performance, the project leader decided to visit the center and perform a visual audit. Eureka! During observation of the process and interviews with the operators, the project leader discovered the main cause of this erratic performance level, discussed below.

Mistaken Process Capability

The process occurs in two parts, Process A and Process B. The operators for Process A (Team A) had been with the company for a long time and had developed repeatable Lean-based techniques to simplify the flow and still maintain a high level of quality. Their improvements had allowed the operators to complete their process earlier than the anticipated cycle time.

The supervisor of the succeeding process took advantage of this opportunity and utilized the extra time of Team A to perform data entry for the start-up of Process B. The result was a shortened cycle time – and thus improved capability – for Process B. The shift in resource allocation was not documented, however, giving the impression that Process B had increased its capability utilizing the existing resources of Team B. In reality, only Process A had the extra capability attributed to Lean streamlining.

After a period of time operating this way, the business experienced a change in volume that required Team A to focus solely on its own process, leaving no extra time to help with Process B. Since the system was based on an erroneous calculation of capability for Process B, it was not known that the change in volume – and thus the change in where Team A’s time was spent – required additional resources to be assigned to Process B to maintain productivity. The true capability of Process B was revealed, which in turn led to the late deliveries.

In a nutshell, it was a case of mistaken process capability (see figure below).

Fixing the Problem

Meanwhile, the salespeople of the company were producing pricing and delivery-time proposals based on the erroneous cycle-time and resource-allocation information. Without the borrowed capability from Team A, the true capability of Process B was lower. Therefore, the actual capability did not match quoted capability and fell short of customer requirements.

The salesperson who made the initial bid would rather waive their commission than have to tell the customer, “Sorry, the price bid is wrong and now we have to increase the price.” A quick solution that could also stand the test of time was needed.

To address the problem, the improvement team implemented several different action plans, including:

• Mirror the Lean improvements from Process A to shorten total process cycle time.
• Utilize the expertise of Team A in Lean implementation for cross-training.
• Require time study methods to be approved by subject experts or process owner to capture any undocumented yet critical knowledge about the process. 
• Require periodic reviews of capability measurements to ensure continuous optimization.

Lesson Learned

Although numbers do not lie, their origin and meaning must be carefully interpreted. Using the right methodology, creativity and a willingness to consider the human element will achieve better results.