- By Francois Yves Simon
- January 01, 0001
The methodology proposed in this paper can be applied to any processes i.e. manufacturing, management, software development, financial, etc.
A lot of papers, articles, and guides have been written over the recent years addressing Continuous Process Improvement (CPI). However very few address methodologies related to the improvement of the process itself, that is, the processing of the metrics used to measure the effectiveness of a process. The methodology proposed in this paper can be applied to any processes i.e. manufacturing, management, software development, financial, etc.
“A process is a planned series of actions that advances a material or procedures from one stage of completion to the next. It includes the steps and decision involved in the way work is accomplished.” 
In most cases, a process is a recursive ‘series of actions’ or tasks executed in a closed loop fashion - as opposed to a linear process which is a ‘one shot deal’. A linear process cannot be subjected to the CPI. Therefore, only the recursive process will be addressed in this paper. The cycle time of a recursive process may vary greatly depending on the application. Some process cycles are very short, especially if the process is embedded in a computerized system – in order of seconds or minutes. Other can be quite long, such as in financial and economic applications.
Figure 1: Process Model Including CPI
CPI Simple Overview
The Continuous Process Improvement is” an ongoing effort to incrementally improve how products and services are provided and internal operations are conducted.” 
In order to assess if improvement of a process or part of a process (task) is needed, one or more metrics reflecting the performance status of a particular task, are poled periodically. The metric value is compared to the corresponding reference used as the baseline for this particular task performance. The improvement of the process or task is dependent on the result of this comparison.
- If the metric value is equal to the reference value, then no corrective in the process is required; the system is said to be stable.
- If the performance metric valuefalls below the reference expectation, then corrective action in the process or task is required; the system is said to be below expectation.
- If the metric value exceeds the reference expectation: then no corrective action required to the process. However, the reference value can and should be changed accordingly to reflect the new baseline – ‘raising-the-bar’; the system is said to be above expectation.
This is the base of the algorithm and reviewed later in more details.
Metrics within any process are selected very carefully. The metrics must be appropriate to the each task within the process and represent a well balanced view of the entire process. The metrics should be defined during the ‘Design Phase’ of the process and selected based on value-add to the process and its implementation cost. The number of metrics should be kept to the minimum because of the interaction between tasks. An improvement implemented in a task may affect the metric in another task increasing the complexity and cost of implementing CPI. For example if an improvement was made to improve the quality of a ‘widget’ may affect the time (e.g. increase) to produce the widget; the time metric baseline (Refx(time)) may require a new baseline value. The bottom line: “keep it simple”.
For each action or task, a single or a set of performance metric(s) is defined. The metrics need to be of tangibles types; intangible metrics are out of scope of this paper. The metrics are process-dependent. Examples of tangibles metrics, not all inclusive, are:
- Error count
- Quantity produced
- Revenue ($)
- Number of resources
Performance Metrics Values
It highly recommended that the metric values selected are numerical and positive integers between, 0 (included) and +∞. While there are metrics such as temperature which would inherently include negative values in the Celsius and Fahrenheit scales, this can be solved by using the Kelvin scale instead which has only positive values.
There are two types of ‘improvement’ metrics values to consider:
- Ascending values where the improvement is expressed in ascending fashion (0 to +∞) (e.g. revenue in $).
- Descending values where the improvement is expressed in descending fashion (+∞ to 0) (e.g. cost of producing a ‘widget’).
Depending on the application, the improvement metric value may be ascending or descending. This characteristic must be defined during the metric selection process.
CPI Algorithm Model
For discussion purposes, the process is already established and is in the ‘Implemented Phase’ and its performance metrics and associated parameters have already been selected.
The CPI algorithm proposed here is based on very well known cybernetics ‘negative feedback’ principle. In a negative feedback the feed back signal is compared with the control signal which is essentially the difference between the input signal and the output signal. It is written symbolically as:
(θi - θo) = e 
In the proposed CPI algorithm there are actually two negative feedback loops: a) one controlling the process and/or task; b) the other controlling the ‘Reference’.
The Figure 2, below, represents the model diagram of the proposed CPI algorithm.
Figure 2: CPI Algorithm Model
Task within a Process
This block is addressed in Figure 1. While several improvement metrics can be associated with a single task, for simplicity, only a single metric is shown. Figure 2 shows the CPI model of a single metric.
Depending on the process or task application, it may be desirable to sample several iterations (Hysx) of the process before making the decision of the final value (mzx) we want to use for comparison with the Reference value (Refx). This function filters temporarily erratic behavior of the process, especially in the initial phases of execution when ‘things’ are settling down. Any statistical method can be used. One which comes to mind is the mean of multiple samples of mx:
mzx = (mx1 + mx2 + ………mxn) / n
If one sample is sufficient (simplest CPI process) then the equation become
mzx= (mx / n); where n =1 è mzx= mx
As a general rule, the longer the process / task cycle is, the fewer the number of sample (Hysx) should be used; one cannot wait for very long period of time before taking improvement actions. The mxSync (poling status) from the task indicates that there is an updated value of mx. The mxSync may be synchronized with the process and/or task cycle and is its responsibility to control this input. In the same fashion, mzxSynch indicates that there is an update of mzx available to the comparator after statistical analysis of multiple samples of mx. It is the responsibility of the Hysteresis function to control it.
The Reference is the desired value of performance associated with a given metric. The task performance metric is measured against this reference to make a decision if improvement to the process and/or task is required.
During the development phase of the process, one may have some notion about the value to assign to each reference in the process. This value (Initial Refx) is a positive number that may be assigned to the Reference as a starting point.
Another method is to let the CPI processing ‘learn’ the initial value of the reference during the initial executions of the process. In this case, the Initial Refx= 0 for Ascending improvement reference and equal a large number (not likely to be valid) for Descending improvement reference. The reference will be updated automatically after one or more mxpoling cycles, depending on the value of Hysx.
When ‘improvement’ as been detected by the comparator, the old reference value (Refx) is replaced by the current performance metric (mzxRef) which is essentially the mzx value so that a new reference is available for the next poling cycle. When the ‘ratchet’ (Rtchx) is ON, the reference value, Refx, is not allowed to be changed when mzx falls below improvement expectation, thus providing true Continuous Performance Improvement (CPI). However, one must consider interaction between tasks or event in the process. When a corrective action or changing metric values takes place in one task, it may require to ‘lower-the-bar’ (reference) in another. In this case, turning the ‘ratchet’ OFF will allow downgrading the reference (Refx) to the new mzxRef.. When the process is settling, Rtchx can be turned ON again.
The Comparator is the heart of the performance metric of the CPI. Its major role is to compare the value of mx, reflecting the current task performance against the latest performance reference, Refx, which was defined at the last poling period and determine if corrective action, cax, is required. cax provides an indication (positive or negative value) thus, a clue on how to proceed taking corrective action. The actual corrective action is application dependent. The comparator has to know if the improvement is in ascending or descending directions – A/D Control – in order to process the comparison correctly. It also needs to know when a new sample is available by checking the status of mzxSync.
It should be noted that the control variables of this CPI process is out of the scope of this paper. The processing of these variables are very much application dependent. Since the algorithm proposed here addresses a single performance metric, the implementation of CPI for an entire process including multiple tasks and performance metrics would be best controlled by a state machine. The variables in questions are:
- A / D Control: Ascending / Descending improvement metrics set-up
- mxSync: Performance metric poling synchronization
- Hysx: Hysteresis control (i.e. number of sample to process)
- Rtchx: Ratchet value
- Initial Refx: Initial Reference; baseline
The proposed CPI solution can be implemented in software or firmware; though in many applications it would be embedded in the process application itself or in a remote operation center system. However in other means like pencil and paper or spreadsheets will also do!
CPI stands for ‘Continuous’ ‘Performance’ ‘Improvement’. A ‘Process’ is usually recursive and its life cycle can be very long such as financial, economic, or relatively short such as industrial, manufacturing, Information Technology (IT) operation centers applications, etc.
Regardless of the life cycle time, in almost all cases, the end goal is to provide better quality products at the least cost to produce them. In order do achieve this, a process must be ‘Continuously’ monitored and ‘Improved’ in time. The improvement implies that the reference that we are measuring the process against must also change – Raising the Bar – as improvement occurs. By definition, this can only be done by ‘feedback’ mechanisms as shown in this paper.
 “Big Dog’s Continuous Process Improvement Page” – Donald R. Clack – 1988.
 Cybernetics Simplified – Arthur Porter – 1970
Did you enjoy this great article?
Check out our free e-newsletters to read more great articles..Subscribe