1.1: Introduction

Last updated
Save as PDF

Page ID: 30954

\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)\(\newcommand{\AA}{\unicode[.8,0]{x212B}}\)

The application of lean concepts to the transformation of manufacturing and other systems has become ubiquitous and is still expanding (Learnsigma, 2007). The use of lean concepts has yielded impressive results. However, there seems to be a growing recognition of the limitations of lean and for a need to overcome them, that is to build upon lean successes or in other words to get beyond lean. ¹Getting beyond lean is the subject of this book.

Ferrin, Muller, and Muthler (2005) identify an important goal of any process improvement or transformation: find a correct, or at least a very good, solution that meets system design and operation requirements before implementation. Lean seems to be unable to meet this goal. As was pointed out by Marvel and Standridge (2009), a lean process does not typically validate the future state before implementation. Thus, there is no guarantee that a lean transformation will meet measurable performance objectives.

Marvel, Schaub & Weckman (2008) give one example of the consequences of not validating the future state before implementation in a case study concerning a tier-two automotive supplier. Due to poor performance of the system, a lean transformation was performed. One of the important components of the system was containers used to ship product to a number of customers. Each customer had a dedicated set of containers. The number of containers needed in the future state was estimated using a tradition lean static (average value) analysis, without taking the variability of shipping time to and from customers nor the variability in the time containers spent a customers into account. Thus, the number of containers in the future state was too low. Upon implementation, this resulted in the production system being idled due to the lack of containers. Thus, customer demand could not be met.

Standridge and Marvel (2006) describe the lean transformation of a system consisting of three processes. The second process, painting, was outsourced and performed in batches of 192 parts. Fearful of starving the third step in the process, the lean supply chain team deliberately over estimated the number of totes used to transport parts to and from the second step. In this system, totes are expensive and have a large footprint. Thus, the future state was systematically designed to be more expensive that necessary.

It seems obvious that in both these examples, the lean transformation resulted in a future state that was less than lean because it was not validated before implementation. Miller, Pawloski, and Standridge (2010) present a case study that further emphasizes this point and shows the benefits of such a validation. Marvel and Standridge (2009) suggest a modification of the lean process that includes future state validation as well as proposing that discrete event computer simulation be the primary tool for such a transformation because this tool has the following capabilities.

A simulation model can be analyzed using computer based experiments to assess future state performance under a variety of conditions.
Time is included so that dynamic changes in system behavior can be represented and assessed.
The behavior of individual entities such as parts, inventory levels, and material handling devices can be observed and inferences concerning their behavior made.
The effects of variability, both structural and random, on system performance can be evaluated.
The interaction effects among components can be implicitly or explicitly included.

¹ It is assumed that the reader has some familiarity with lean manufacturing / Toyota Production System concepts.

The discussion in this book focuses on how to build and use models to enhance lean transformations, that is to get beyond lean or to make lean more lean. The modeling perspective used incorporates the steps required to operate the system and how these steps are connected to each other. Models include the equipment and other resources needed to perform each step as well as the decision points and decision rules that govern how each step is accomplished and is connected to other steps. These models can include the sequencing procedures, routing, and other logic that is needed for a system to effectively operate.

Computer simulation models provide information about the temporal dynamics of systems that is available from no other source. This information is necessary to determine whether a new or transformed system will perform as intended before it is put into everyday use. Simulation leads to an understanding of why a system behaves as it does. It helps in choosing from among alternative system designs and operating strategies.

When a new system is designed or an existing system substantially changed, computer simulation models are used to generate information that aids in answering questions such as the following:

Can the number of machines or workers performing each operation adequate or must the number be increased?
Will throughput targets be reached that is will the required volume of output per unit time be achieved?
Can routing schemes or production schedules be improved?
Which sequencing scheme for inputs is best?
What should be the work priorities of material handling devices?
What decision rules work best?
What tasks should be assigned to each worker?
Why did the system behave that way?
What would happen if we did “this” instead?