I would like to start a series of articles reflecting the University of Kassel’s research in deploying Six Sigma within cross–domain industrial applications. They cover the following topics:

• Six Sigma trends
• Advanced strategies
• Innovative team training

I will certainly appreciate if these articles launch a discussion. Getting feedback, I will be able to tailor the scope of the following articles to the frequently asked questions and to the voice of article’s customers, i.e., readers.

1. How We Select And Define Projects Now

Let’s summarise the current practices in project definition.

Six Sigma projects are usually defined as spin-offs from high-level business cases which are aimed at reducing the gap between the current and target process performance, i.e., its variability.

Processes are mostly viewed as a set of activities which transform inputs from suppliers into the outputs to the selected customers (so-called SIPOCs). Both core and support business processes could be the subject of a project.

Metrics which characterize current and target process performance are defined in direct relationship to the customer requirements and may represent:

• Process/product quality, and/or
• Process/product life cycle, and/or
• Costs of poor quality and/or of the poor lifecycle.

Both external and internal customers are considered.

Metrics are usually prioritized as primary, i.e., most critical for business and secondary, which particularly focus on prevention of any potential negative consequences of improvements, also outside the process boundaries.

We evaluate current performance by selecting a representative time period, and strive to find such period when the process to be improved is stable.

Further efforts are focused on using data to narrow the scope of the project to:

• One of the highest return on investment
• Feasibility under time, budget and resources constraints, etc.

Usual duration requested, e.g., for the typical Black Belt project is 3 to 5 months.

2. Obstacles

Due to rapid development of markets, their diversity and increasing competition, the procedure described above often becomes idealistic. In fact:

• Life cycles of products and processes are often shorter than expected project duration;
• Due to the permanent changes and change management it may be difficult to find a time period long enough for analysis of the process’s current performance, when the process is stable;
• Rapid changes (in suppliers’ and customers’ organizations, in their requirements, production volumes, in internal process organization, underlying technologies and ‘actors’ participating in the process) are almost inevitable and may occur often during the project lifecycle.

All that means that we have both moving targets and changing process environments and constraints. The dynamics are often comparable to or even quicker than the project lifecycle, i.e., requirements and processes are often (and not occasionally) unstable and non-stationary.

3. Challenge

In fact, speed and efficiency of process transformation and adaptation to the changing customer requirements and environment are becoming some of the most critical factors in the business survival performance characteristics.

Therefore, we have to expand classical Six Sigma ‘static’ project definitions, metrics and process descriptions and tools with dynamic ones. Forecast of potential changes in targets, environments and processes have to be performed during the business case and project definition phase. It will also serve as a basis for simulation and evaluation scenarios during the Improve and Control phases.

Inevitably we have to consider more advanced tools of adaptive modelling, predictive control etc., that are relevant for efficient improvement of non-stationary processes, managing changes and process transformations.

4. Side Effects

One of the most reasonable strategies to provide business flexibility and improve its ‘static’ and ‘dynamic’ performance is not to shorten the lifecycle of the projects or of the project phases and hence strive to narrow the scope appropriately, but to iterate them more frequently even within one project lifecycle.

The philosophy is to “improve a little, test a little.”

A similar philosophy is relevant for Design for Six Sigma (DFSS) projects, i.e., “design a little, test a little.”

To realize this operational strategy, the business cases have to be elaborated, monitored and analysed with a much greater level of detail. Market and technology forecasts have to be considered when defining and evaluating these business cases.

5. Voice of Users Versus Voice of Customers

Customers of our end-products and/or services are not necessarily the end-users.

Customers who make the formal decision to buy the product may (and often do) oversee the end-user’s requirements to the products in terms of so-called usability, i.e., effectiveness, efficiency of use and user satisfaction. Costs of poor usability (COPU), especially for interactive products consist of extra training, maintenance costs, time losses due to user-errors and recovery from errors, etc., and may exceed overall product development costs. Repair of usability errors is extremely expensive and may lead to a total redesign of the product.

Therefore, both usability engineering concepts in DFSS projects and usability metrics (including COPU) have to be bridged with both Six Sigma concepts and with practical approaches and tools for the project definition and management.

6. Process Maps: Multiple Views

In many projects we observe a (wrong) tendency to map the processes with little or no consideration of the project goal, metrics and scope. It happens especially often during the first Black or Green Belt projects.

In fact, efficient process mapping has to be project goal-driven.

First, we need to map and to zoom the process to be improved only within certain system and process boundaries.

Second, the level of details as well as views on the process have to be sufficient (good enough) to present where and when relevant Xs (causes) and Ys (responses, that quantify selected primary and secondary metrics) that arise and how and who may measure them.

One most frequently used view of the process as a set of activities (so-called activity diagram) is useful but rarely sufficient.

Operational, organizational, data system, and technical views as well as cultural and demographic views which reflect end-user and customer profiles and which are concordant with each other at all levels of hierarchical presentation are often needed, especially for DFSS projects, e-business, transactional processes, for their adequate modelling and simulation.

7. System Versus Process Boundary

As far as different views are concerned, we have to define not only process (SIPOC) boundary but also (and first!) overall system boundary when narrowing the scope of the project.

We may define this boundary, iteratively answering the questions:

• What (products, processes, components)?
• Who (actors, their roles)?
• How (functions, activities etc.)?

A systematic approach, efficient system and process modelling tools will be therefore be increasingly in demand.

Discussion

The analysis of the tendencies in business processes and Six Sigma approaches and tools and the attempts to forecast its future development trends given in this article are certainly not exhaustive.

It shows, however, the apparent trends of increasing complexity, the dynamic nature, end-user orientation, and interdisciplinarity.

Looking at the positive side of these issues, one sees many opportunities for future Six Sigma innovation and of upgrading training programs.