Facilitating a Process Mapping Team, Part 3: The Skinny on Lean Six Sigma (LSS)

This article is the third in a series about facilitating process mapping. The first presented the basics of setting up the team and planning key facilitation tasks. The second, Conducting a Process Maturity Assessment, defined the organization according to the type of processes being mapped and provided key questions to assess the organization's overall process maturity. 

This article will:

• Describe the origin of sigma (σ).
• Introduce the six concepts that comprise Six Sigma.
• Explain why these tools are considered lean.
• Discuss the philosophy, formula, and laws of Lean Six Sigma.

Overview
A brief history of Six Sigma and lean thinking will help you understand how LSS came about, and how selected Lean Six Sigma tools are used in process mapping.

Six Sigma Defined
Sigma (σ) is a letter from the Greek alphabet that is used in statistics to measure variability. In Six Sigma methodology, a company's performance is measured by the sigma level. Sigma levels are a measurement of error rates. Because it costs money to fix errors, savings from reducing errors can be transferred directly to the bottom line.

Six Sigma was developed in 1981 by Motorola to reduce defects. Six Sigma incorporated Total Quality Management (TQM) and Statistical Process Control (SPC), and extended from a manufacturing focus to other industries and processes. Motorola documented $16 billion in savings, inspiring other firms to adopt the model. In 1988, Motorola won the Malcolm Baldrige National Quality Award (MBNQA) for its Six Sigma program.
 
Six Sigma specifies exactly how management should set up a project to achieve the most effective process.

The Six Concepts of Six Sigma

• Critical to Quality: Attributes most important to the customer
• Defect: Failing to deliver what the customer wants
• Process Capability: What the process can deliver
• Variation: What the customer sees and feels
• Stable Operations: Ensuring consistent, predictable processes to improve what the customer sees and feels
• Design for Six Sigma (DFSS): Aiming to meet customer needs and process capability

Six Sigma is based on statistical thinking and strives for defect reduction, process improvement, and customer satisfaction. It assumes that everything is a process and that all processes have inherent vulnerability.

Six Sigma theory relies heavily on data to understand the variability and drive process improvement decisions. It's all about reducing errors, mistakes, or defects. The table below shows the Sigma levels.

 

Thinking Lean
A great resource on the origin of lean thinking is The Quality Toolbox by Nancy R. Tague. Lean thinking is the application of the lean manufacturing concept to service operations. It is distinct in that lean services are not concerned with the making of "hard" products. Six Sigma is data and statistics driven. Lean thinking takes into consideration other factors such as gut feelings and the voice of the customer. Once the two are combined into Lean Six Sigma (LSS) the focus shifts to using the simplest possible graphs and explanations when presenting the research and solutions.

Eliminating obvious and hidden wastes are the main concerns of lean thinking. Obvious waste includes wait time, over-production, transportation time, and transactions that must be repeated. Hidden wastes are activities that do not add to the value of the item or service: for example, excess processing which occurs when two employees perform duplicate tasks. LSS relies heavily on Value Stream Mapping (VSM) to identify areas of waste. In project management, VSM is similar to Critical Path analysis. VSM can use tools and symbols similar to process maps. The idea behind VSM is that the viewer can easily see where resources need to be allocated. LSS is concerned with process capability and relies heavily on Critical to Quality (CTQ), going so far to build in analyses for measuring the measurement systems. The ultimate goal is to stabilize processes and build predictability into them, because a consistent stable process is one that can be improved more easily.

LSS for Success
LSS is often considered a formula for success, the core philosophy of LSS:

Customer Satisfaction = Process Improvement Success

Lean Six Sigma: Practical Bodies of Knowledge, by Terra Vanzant Stern, is a valuable resource on the topic because of its in-depth look at key LSS terms and concepts.

The Five Laws
(Derived from a combination of the principles of Six Sigma and Lean Manufacturing)

Customer satisfaction is the highest indicator of process improvement success.

Law 0- The Law of Market: The foundation for the five laws is referred to as the Zeroth Law. It states that Customer Critical to Quality is the highest improvement priority, followed by Return on Investment (ROI).
Law 1- The Law of Flexibility: The overall success and productivity of a process is dependent upon the presence of cross-trained employees that can effectively handle a variety of situations.
Law 2- The Law of Focus: The focus of process improvement originates from the theory that 20% of the activities cause 80% of the processing delay. Management can greatly improve results by targeting their efforts on improving the most problematic activities first.
Law 3- The Law of Velocity: The velocity of a process is inversely proportional to the amount of Work in Progress (WIP). Keep things off the to-do list.
Law 4- The Law of Complexity: The complexity of a service or product offering adds more non-value, costs, and WIP than either poor quality (low Sigma) or slow speed (un-Lean). Keep it simple.

We'll wrap up here with the introduction of the seven core quality management tools of LSS (listed below). Blogging with Bliss will follow up with our next installment about the first of the seven core LSS quality management tools, the process map.

The Seven Core Lean Six Sigma Quality Management Tools

• Process Map
  
• Cause and Effect Diagram 
  
• Pareto Chart
  
• Histogram
  
• Checksheets
  
• Scatter Plot
  
• Control Chart 
  

Our guest contributor, Stephen Mercer, is an organization and process consultant. Stephen has diverse experience in a wide variety of industries. His background includes ten years as a senior technical writer, skilled in collecting, analyzing, reworking, and disseminating information tailored to specific audiences, and software process improvement and methodologies (e.g., Capability Maturity Model; CISA designation).

Facilitating a Process Mapping Team, Part 2: Conducting a Process Maturity Assessment By Stephen Mercer

This is the second in a series about facilitating a process mapping team. The first dealt with the basics of setting up the team and preparing for key facilitation tasks. The current article covers the concept of the organization's Process Maturity, defines the organization according to the type(s) of processes they are mapping, and provides key questions that you can ask to assess the organization's overall process maturity.

Below is a quick review of the key tasks that were listed in the last article:

• Identify the key stakeholders and process owners.
  
• Define the project scope and deliverables.
  
• Identify what you are measuring.
  
• Determine the method and type(s) of process maps to create.
  
• Review and validate the process maps.
  
• Baseline the processes and conduct a formal handoff.
  

OK, now that you have assembled your team, you are ready to forge ahead by performing the key tasks as listed. By following the key tasks, you will be able to develop a set of processes for the organization.
 
Questions to consider:

• What kind of team are you working with?
  
• How experienced are they at developing process flows?
  
• Do they follow predefined standards and/or templates?
  
• Do they think in terms of processes, or do they think in terms of functional units?
  

Before you move into defining the scope, identifying measurements, and determining the process mapping method, there is one step that will help to understand how to approach your team. It addresses a key concept that you will be hearing more of in the years to come, namely the concept of Process Maturity. 

Similar to maturity models utilized for software process improvement, such as the Capability Maturity Model (CMM), there are existing maturity models available that address process improvement. In 2007, Dr. Michael Hammer introduced this concept in an article for the Harvard Business Review. The article introduced a new comprehensive framework entitled The Process and Enterprise Maturity Model (PEMM™), which is used to evaluate the maturity of a business process and to determine how to improve its performance. You can learn more about this model by going to their website.

Conducting a Process Maturity Assessment 

A complete process maturity assessment is beyond the scope of this article, but you can conduct an assessment or "mini-audit" that is effective in helping your team to scope out the deliverables and build an effective process. This can be done as part of your interview questions rather than a formal audit. The remainder of this article addresses key tasks and questions to ask when conducting a Process Maturity Assessment for the organization. Some of these items are my own, and some are derived from the PEMM™ model. Bear in mind that this is not intended to be a formal Process Maturity Assessment, but it goes a long way toward determining the maturity level of your team and the organization.

Let's begin by defining process types from the perspective of the model. The PEMM™ model defines three main categories designed to help an organization assess its overall process maturity and to begin thinking in more process-centric terms. The three main types of processes are defined as follows:

• Core Process: Defined as core processes that convert inputs into outputs of greater value to customers, e.g., supply chain, order fulfillment, prospect to order. This may mean faster turnaround time, lower manufacturing costs, and/or higher quality.
  
• Enabling Process: Defined as enabling processes that support one or more other processes, typically by supplying indirect inputs, e.g., hire to retire, design to automate. This is where cross-functional processes come into play. If you are doing hand-offs to other organizations and depend upon them to support your processes (and vice-versa), then involving a cross-functional team is of paramount importance. Most enterprise-wide strategies sponsor initiatives that span across organizations and impact many employees. At this point you can begin to break down the silos and help the organization make a shift in thinking from departmental/functional to process-oriented.
  
• Governing Process: Defined as governing processes through which the work of the enterprise is directed and controlled to ensure success.
  For example:
  
  
  As an organization becomes more mature in its process mapping efforts, you will see more of these tasks incorporated into its processes. Has your organization adopted this viewpoint? Does it represent a long-term goal for the organization or enterprise? Is management taking a process-oriented perspective, and have they formally assigned a process owner to ensure compliance and follow-through?

Key questions to ask when performing a Process Maturity Assessment

• Who are the contributors?
  Is the team balanced as far as those who will contribute, or is it weighted toward any one or two functions? It is important to understand that processes are sequences of activities working as a whole to produce something of tangible value. Processes need to transcend organizational boundaries; hence it is critical to involve participants from all organizations involved with the process. Once you have identified your stakeholders take note of their level of contribution to the project. On some teams, the Subject Matter Experts (SMEs) and process performers provide most of the input. By contrast, I have seen projects in which the manager provides nearly all of the input with no team effort involved. This may be due to busy staff schedules, a more simplistic goal, or the presence of an over-controlling manager. Whoever your contributors are, it is crucial for them to know that their ideas are respected; after all they are the ones who know the process the best and are able to provide the most useful input.
  
• How much experience do they have at mapping processes?
  Does your team understand the difference between a functional and process-based organization?
  This is critical to understanding how good business process mapping works. Functionally aligned organizations do not lend themselves well to process-oriented thinking. In fact, it is precisely the doing away with functional divisions (i.e. silos) that can enable an organization to improve its processes and overall performance.
  The PEMM™ model reminds us that the concept of enterprise process is end-to-end work across the organization. It is a designed group of related tasks that work together to create a result of customer value. Processes are not merely new names for traditional departments; they are cross-functional sequences of activities rather than groups of people, transcending organizational boundaries.
  
• How often has your team used cross-functional processes to improve performance?
  This is a good follow-up question to the one above. I have found that very few people have formal process training, but are expected to map process flows without no experience. This can make the task seem daunting and even cause people to back away from providing input. In this case, it may be useful to conduct a basic training class in process mapping. I have found that investing as little as an hour to train the participants can help them to develop better processes, feeling more empowered and better equipped to provide input into the process mapping effort.
  
• Do you have external and/or benchmarked metrics to use for comparison?
  Does the end-to-end process have end-to-end metrics derived from external customer requirements? There is a great deal of research available that can help determine adequate performance levels for organizations which provide similar products or services. The question from a process maturity perspective is to determine to what extent the organization uses benchmarks to define metrics and set goals. It may be necessary to help the team to define metrics (to be covered in a later article).
  
• Are there other organizations that are part of the process?
  Does your team need to hand off deliverables to someone outside of your immediate organization, or vice-versa? If so, are SMEs from the other organizations participating in the development of the process maps? This should be a standard practice to include representatives from any organizations that play a part in the process. One of the key principles of process management is to look at the process end-to-end and, where possible, break down the barriers that keep an organization fragmented. Remember that enterprises that are structured as functional organizations generally do not perform as well as those that have adopted a process-oriented perspective.
  
• Is your process part of a larger initiative, such as an infrastructure improvement or an onboarding and provisioning initiative?
  Does your process deal with materials and supplies, or are you dealing with HR processes? Will this be a phased implementation in which new processes are introduced and/or improved over time?
  
• If your process involves technology, does your team have good representation and support from the IT organization?
  Has the solution taken into consideration the manual tasks and handoffs? Will the new technology enable more efficient operations? Your process performers may have difficulty navigating through a new user interface or they may need to depend upon someone else to provide them with the correct information or documents at the right time. Be sure to ascertain whether the technology is driving the process, or the process is driving the technology. All too often, technology solutions are adopted that do not consider the non-technology part of the overall process. This can cause trouble during the implementation and may be indicative of a poorly defined process.
  
• Is your team prepared to adapt to significant changes in their work processes?
  This topic is beyond the scope of this article, but I will mention that changing the structure and/or management of an organization is a significant undertaking and may well necessitate the skills of an outside consultant.
  

Your answers to these questions will tell you a lot about your team and give you valuable insight into the most efficient way to work with them. Once you have performed a Process Maturity Assessment, you will have a much better picture of your team and how the enterprise functions. In addition, by performing this assessment and analyzing overall process maturity, you may be laying the groundwork for future implementations. It is often this "extra mile" that results in better end products and happier clients.

Our guest contributor, Stephen Mercer, is an organization and process consultant. Stephen has diverse experience in a wide variety of industries. His background includes ten years as a senior technical writer, skilled in collecting, analyzing, reworking, and disseminating information tailored to specific audiences, and software process improvement and methodologies (e.g., Capability Maturity Model; CISA designation).