MONDAY, OCTOBER 22, 2018
Font Size
Implementation Case Studies Case Study: Using Six Sigma in a Non-Six Sigma Culture

Case Study: Using Six Sigma in a Non-Six Sigma Culture

Anyone who has worked in manufacturing has probably experienced some level of finger-pointing when shipments fall short of expectations. Though there could be multiple reasons for a missed customer delivery, somehow it is always the other department’s fault. In extreme circumstances, several months of missing targets without effectively defining the root causes and addressing them can lead to serious intercompany conflict and worse, a continued decline in financial performance.

In an organization that embraces Lean Six Sigma (or a similar process improvement methodology), launching a project or Kaizen event would be relatively easy to address problems. In contrast, an environment that embraces expert opinion over a problem-solving process requires a more creatively tailored approach as described in this case study. (Note: Some details have been purposely omitted or changed to maintain confidentiality.) Continuous improvement (CI) tools can be used in a non-intimidating way to address perceptions that affect performance.

Perceived Problem and Objective

At the surface, the problem was extreme frustration in the customer service department related to missed customer deliveries. The objective was to define a process that would promote timely responses to customer inquiries (excluding requests for quotation).

Scope

Even though sales, customer service, product management, quality, engineering, procurement, planning, manufacturing and maintenance all played a role in successfully meeting customer delivery requirements, the scope of this initiative was primarily focused on the interactions between customer service and planning.

Contextual Factors

With a high risk of interpersonal conflict, it was important to complete a cursory analysis of the people involved in the process to ensure successful change management while avoiding personnel issues. Culturally, engineers were valued differently than planners due to their irreplaceable knowledge and expertise. It was acceptable to overlook slow response times related to engineering delays. Planners, on the other hand, were not perceived as having a high level of expertise because they relied on manufacturing leads to find out when something was going to ship. If there was an issue getting a response from manufacturing leads, the expectation was that a planner would go directly to the work center(s) involved and get the required information. It is important to note that a large portion of the customer service team previously worked in planning roles.

Other Relevant Factors

The organization experienced a period of unprecedented growth. Monthly shipments were 10 times what they were in the previous decade. Work that could be completed with manual calculations or simple spreadsheets was no longer practical or possible. Due to the increase in work volume and complexity, the salaried and hourly workforce grew in number and diversity. Preparations were in place to implement a large-scale enterprise resource planning (ERP) system across several vertically integrated manufacturing sites within the company.

Expectations

There were no documented expectations for response time. The response time was defined as the requestor’s expectation based on prior experience as a planner and personal judgment, which may or may not reflect the external customer’s expectation or process capability.

Approach

Unlike a typical project where clear goals and expectations could be defined, this initiative had to start with a definition of the expectation. In a culture where expert opinion trumped a problem-solving process, the major challenge was finding a way to complete a value stream map and collect information that would define the current state and eliminate perceptions that were not based on data.

Informal Observation and Interviews

While it would be more effective to bring a group of relevant stakeholders into a room for an hour and quickly map out a process, that was not going to work in this situation. The reasonable first step was to complete some personal observations and informal interviews. After speaking with several people, there were two major methods of communication used to satisfy customer inquiries – phone calls and emails. When asked to whom phone calls and emails were directed, there was a wide variety of responses:

  • “I send it [email] to the whole group [several functions and every person within that function].”
  • “I call the person who I know will give me a response.”
  • “When I need a faster response, I send it [email] directly to the person’s manager.”

Data Collection

There had to be a way to collect response time data efficiently and effectively without affecting existing resources or budgets. Existing systems were evaluated along with the likelihood of acceptance and user capability.

  • Email: Because the existing process used multiple methods of communication, tracking email would be time consuming and represent only a fraction of the process.
  • Data log (hard copy, Microsoft Access, Microsoft Excel): Keeping a data log would introduce a high risk of inaccuracy and user acceptance. Unless the data log was standardized and electronic, significant manual work would be required to format the data for analysis.
  • Workflow: Microsoft SharePoint was commonly used for document storage, but the workflow feature was not enabled. With a little training and follow up, this was a zero-cost candidate to not only collect data, but also provide a means to standardize, control and improve the process.

Informal Project Initiation

To ensure buy-in from the start, it was determined to be best to meet with each major functional group separately to get feedback on a proposal to start using SharePoint workflow. After answering questions and taking suggestions, the most difficult decision was to pursue a policy allowing any request for information from the customer that could be answered with a quick phone call or verbally in the hallway to be done outside of the data-tracking system.

This decision was beneficial because it reduced the workload and it showed stakeholders efforts were focused on the real problem – response time to customer inquiries. In theory, if an answer could be provided on the spot 100 percent of the time, there would not be a response-time issue. The added benefit would be improved face-to-face communication and collaboration if people chose this method of communication over documentation. The biggest danger in making this decision was not being able to quantify the impact of total volume of requests on response time.

Another important decision made after initial meetings was to limit the point of contact for inquiries to planning. While it may be considered taboo to modify the process before it is measured and evaluated, this decision limited the complexity of the initiative. It made sense to have the planning group responsible for obtaining information even if they were not accountable for it.

Project Kickoff

To kickoff the informal project, customer service and planning met as a group to get on the same page regarding scope and purpose. This meeting addressed the desired future state (vision), training required (skills), incorporation into performance management (incentives), who would be actively involved/contribute on a regular basis and sponsor the activity (resources), and timeline for next steps (action plan). This session went well thanks to the individual meetings held beforehand to address issues before needed to be raised in a larger group setting. Because everyone was well informed in advance, there was active engagement from every party and little-to-no resistance to ideas presented.

Future State

Simply stated, the vision was to have timely responses to non-quotation customer requests.

Training

There was no in-house SharePoint workflow expert, so the project leader completed informal training by using Microsoft tutorials and YouTube videos. The information technology (IT) department set up a test site at no cost. The self-taught project lead created simple Microsoft Word documents for two audiences: administrators/power users and standard users. For administrators, the document outlined work required to set up the workflows and forms for knowledge management purposes. For users, the document provided screen shots and detailed instructions on how to create items and use workflows.

The training documents were reviewed in a group setting and distributed; individual training sessions were completed after that. The system was launched in pilot mode, and after collecting data and feedback for about a month, the entire group reconvened to identify concerns and make improvements. One of the recommendations was to create a frequently-asked questions (FAQ) document. This was an excellent suggestion and used for change management purposes. Each week, one or more of the FAQ was emailed to the broader group as a weekly tips message to mitigate the risk of participants resuming old habits.

Incentives

This initiative was tied to a performance management goal of completing a continuous improvement effort as a team; the performance management system was flexible enough to be modified throughout the year with employee/supervisor agreement.

Resources

Though interviews and meetings were completed during standard work hours, the SharePoint tutorials and documents were generated off-hours for two primary reasons.

  1. Where a continuous improvement culture does not exist, higher levels of leadership, coworkers or subordinates can take issue with time being spent on data collection, analysis or training that is not directly tied to the bottom line. To avoid any surprise disruptions, it made sense to use standard work hours only for items requiring face to face collaboration.
  2. During the explosive growth period, it took every hour of the workday and more to keep up with day-to-day responsibilities; “extra” activities had to be prioritized accordingly.

Due to the entrepreneurial nature of the initiative, other than requesting a test site from the IT department at no cost, no additional resources were required to complete this project.

Action Plan

To keep the initiative bound to a six-month timeframe, training was developed in tandem with the specifications for the standardized form and workflow definitions (e.g., repeatable list of recipients based on subject matter, priority, complexity, etc.). Meetings were held monthly to review data for the current month along with cumulative data to determine trends. Meetings were limited to one hour but were frequently less than 30 minutes. Recommendations for improvement (e.g., add additional fields to the form, add cc features for managers, create standardized reports and change view format) were documented and implemented before the next monthly meeting.

At the end of six months, the process was fully implemented with established expectations and metrics for response time. Unplanned benefits included a repository for data that was used to create a supply chain scorecard. Future plans included leveraging best practices to other transactional operations.

Results and Analysis

Close to six months of data revealed there were almost 50 unique types of requests for information ranging from packaging questions to site visits to contractual details. On average, there were about 30 requests per month. Requests for lead time and expediting deliveries were the most frequent entries (shown in the figure below). Implementing a new method of communication and data collection eliminated the perception that customer deliveries were missed due to slow response time because data showed response time was, with few exceptions, two to three business days (not the weeks or months previously reported). Without historical data, one could argue that there was a real problem in the past or that the cross-functional collaboration and regular discussion created a Hawthorne effect (behaviors change because participants know they are being observed), but there would be little return for the investment to prove or disprove additional theories.

Pareto Chart of Repeat Requests (Excludes One-Off Requests)

Pareto Chart of Repeat Requests (Excludes One-Off Requests)

Key Takeaways

Using typical Six Sigma or other process improvement tools in an environment where CI is not part of the culture may be ineffective. Adapting CI tools to be less intimidating creates less resistance to change and improves the likelihood of successful project completion. Taking the time to understand perceptions and how to eliminate them with effective low- or no-cost creative solutions is critical to the long-term financial performance of any organization.

Register Now

  • Stop this in-your-face notice
  • Reserve your username
  • Follow people you like, learn from
  • Extend your profile
  • Gain reputation for your contributions
  • No annoying captchas across site
And much more! C'mon, register now.

Leave a Comment



Comments

Chris Seider

Neatly written story. thanks.

Reply


5S and Lean eBooks

Six Sigma Online Certification: White, Yellow, Green and Black Belt

Six Sigma Statistical and Graphical Analysis with SigmaXL
Six Sigma Online Certification: White, Yellow, Green and Black Belt
Lean and Six Sigma Project Examples
GAGEpack for Quality Assurance
Find the Perfect Six Sigma Job

Login Form