The D•I•P•O•D Process Model – Part 1

     Well-designed models can be invaluable aids to development and analysis.  3D CAD models assist the detection of physical interferences in an assembly and the rapid calculation of stresses within its components.  Mold-flow analysis helps injection molders predict processing problems.  Various forms of simulation help us evaluate potential performance and identify risks before any products are manufactured, tooling built, routes established, or services performed.
     Successful process planning, troubleshooting, and continuous improvement begins with applying fundamentals.  Therefore, a model need not be as sophisticated as mold-flow or finite-element analysis requires to be useful, nor does it require high-performance computers with extensive computational capability.  For many purposes, a simple diagram can provide the guidance needed for users to achieve breakout performance by focusing attention on what is relevant to the achievement of objectives, while clearing the clutter of distractions.  The D•I•P•O•D Process Model is a great example of effective simplicity when used for process planning, development, or troubleshooting.

     The utility of the classic Input-Process-Output (IPO) model is limited by its deficiencies.  Namely, these include:

• It lacks process monitoring
• It does not consider previous or subsequent processes
• It suffers from insufficient granularity
• It does not consider unintended or undesired outcomes
• It does not consider reactions to changes in inputs, outputs, or process parameters
• It provides no clear links to other process documents (e.g. PFMEA, PFD, CP) or troubleshooting tools (e.g. Fishbone Diagram).

     The D•I•P•O•D Process Model expands on the classic tool in order to increase its utility for process managers, be they manufacturing engineers, production managers, maintenance technicians, sales staff, service providers, or any other practitioner.  The acronym is easy to decode:
D:  Data – Inputs
I:  Inputs
P:  Process
O:  Outputs
D:  Data – Outputs
 
     This definition corresponds to a clockwise progression through the diagram below, starting at the lower left corner.  The descriptions of each element of the model will stand on their own for now.  Further discussion and example implementation will come later, but first we must explore the portion of the diagram not explicitly included in the model’s acronym – the Process Chain.

     Depicted schematically at the center-bottom of the diagram, the Process Chain serves as a reminder to users that the vast majority of processes we are likely to analyze can be modelled as a series of subprocesses.  Doing so simplifies analysis of each subprocess, minimizing the likelihood of overlooking relevant information, the inclusion of which increases the model’s utility.  Choosing an appropriate level of subdivision becomes easier and more natural with each deployment of the tool.
     When subprocesses are analyzed, the Process Chain includes a feedback loop.  Each subprocess generates data that can be used to improve itself and other subprocesses in the chain.  It is a valuable function of the model that should not be neglected.
 
The D•I•P•O•D Process Model Template
     To facilitate collection and organization of process-related information, a standard template should be used.  Doing so will ensure consistency across projects, increasing the efficiency of evaluation and simplifying transfer of information to other process management documents or troubleshooting tools.  A template is shown below.

     To use the template, begin, at the upper right, with Outputs.  List both the desired outcomes of the process (i.e. the purpose of operating the process – to be maximized) and the undesired outcomes (i.e. waste and negative side effects – to be minimized).  When documenting an existing process, the outputs are (or should be) known.  Using the template for process planning may require iteration to capture all outputs as details of the process become clearer.  It is also advantageous to record potential outputs that proper process control will prevent.  The existence of such an output then provides a clear signal of process failure easily understood by anyone reviewing the model.

     For an existing process, identify data collected to monitor outputs and evaluate process performance.  Also identify any perceived deficiencies in the data collection scheme in the “Desired” section of Data – Outputs.  Only data that assists in performance evaluation or provides feedback for process improvement should be included.
 
     With the Outputs side of the template complete, an appropriate process definition can now be crafted.  If a simple Process description that captures all of the outputs and data collection needs identified is elusive, revisit the output definitions.  Paring down the list of outputs and data could lead to a clear definition of a subprocess for which analysis is simpler and, therefore, more thorough and more valuable.
     If multiple process options are available to achieve the desired outcomes, selecting the best option requires thorough consideration of key process planning objectives:  maximize desired outcomes, while minimizing inputs, undesired outcomes, and total cost.  Process inputs have not yet been defined; therefore, iteration may be required to compare options and identify the preferred process option.  Thorough analysis in the planning phase pays dividends throughout the lifecycle of a program!
     Change management practices should be included in the process definition.  What process parameters can be modified, the individuals authorized to do so, and how the changes are to be tracked and validated (e.g. quality verification) should be clearly communicated.  Predictable process performance depends on consistent change management!  An addendum can be created, if necessary, to provide sufficient detail; if existing standards and policies are adequate, simply reference them in the model.
 
     Once a preliminary process definition is drafted (iteration and refinement may be necessary), the Inputs required to operate the chosen process can be identified.  It is imperative that all required inputs be recorded, as it is easy to take something for granted, resulting in a negative impact to the process.  For example, if a vision system is relocated without considering its lighting requirements, ambient lighting effects may cause the system to become inoperable.
     Also, there may be inputs that are not controlled by the process operator, though they impact process performance.  For outdoor work, all environmental conditions – temperature, humidity, wind, precipitation, air quality, and so on – are in this category.  Recording them ensures that consideration is given to mitigation strategies that may be necessary for successful operations.
           
     In the Data – Inputs section of the template, record the data used to monitor or verify the condition of each of the Inputs.  Uncontrolled input monitoring should be included here; though they cannot be controlled, limits may be required, beyond which operations must cease.  In many cases, uncontrolled variables are ignored in initial process developments, precluding understanding of the impacts they have on process performance.  Future troubleshooting efforts are then hampered by the lack of insight this practice causes.
     Input data is critical to process development and troubleshooting.  High variability or trends in the data can be correlated to changes in process performance, such as lower yields or higher emissions.  Monitoring all inputs allows the operator to conduct sensitivity analyses that can help identify the most favorable process parameter limits.  That is, a wider range of values may be permissible where it will not negatively impact process performance, while tighter control is placed on critical factors.  In the context of process control, this is an optimal solution.
 
     The D•I•P•O•D Process Model is now complete.  Or is it?  Each component of the model should be reviewed and updated with revelations from the ongoing analysis or iterations of model development.  The model may never be “final” or “complete;” the process may evolve or additional insight may be gained that warrants revision of the model.  Treating D•I•P•O•D model development as a one-time exercise, filing the result to never be seen again severely limits the value that can be extracted from it.
     In Part 2, an example deployment of the model will be presented and common errors will be discussed.  Additional information regarding the model’s use for troubleshooting will also be provided.  You don’t need to wait for it to begin gathering process intelligence, however.  Give it a try and check back for the next installment of The Third Degree.
 
Jody W. Phelps, MSc, PMP®, MBA
Principal Consultant
JayWink Solutions, LLC
jody@jaywink.com