jisha.nair

Pacemaker process can be defined as the scheduling point in the production system, so as to say it dictates the rhythm for the rest of the system by responding directly to the orders from external customers or we can say that the upstream processes don’t produce without a pull signal originating from the pacemaker. The importance and relevance of selecting an activity as a pacemaker process in the value stream lies in the fact that, how we control the production at this process sets the pace for all the upstream process, for e.g fluctuations in production volume at the pacemaker process affect the capacity requirements in the upstream process. Every piece of inventory above the pacemaker is pulled into it and everything below it flows in a smooth manner. For made-to-stock products one would typically have the pacemaker in the downstream, like in the final assembly where everything comes together, whereas for make-to-order kind of product, one would set the pacemaker in the upstream where the final specification is set or where the product becomes unique (maybe color, laptop configuration desired etc by customer.). Using a pacemaker simplifies scheduling, maintains a level output, focuses on the bottleneck and prevents over production. The pacemaker concept is similar to drum buffer rope concept in Theory of Constraints (TOC) especially in make-to-order type of scenarios. However, the process constraint, in TOC, decides the throughput of the process or the capacity of the process to meet customer demand, whereas pacemaker sets the flow to meet the customer demand. So to say we can say that TOC purposely imbalances its process to manage the constraint whereas pacemaker doesn’t do purposely but by virtue of customer demand some processes may become a constraint. Thanks Jisha Nair

Hypothesis testing is an essential procedure in statistics , it evaluates two mutually exclusive statements about a population to determine which statement is best supported by data i.e which statement is statistically significant. But, why do we need hypothesis testing ? that is because we are making our conclusion about a population basis the sample data – hypothesis tests helps assess the likelihood of this possibility that the sample data is representative of the population data. This itself makes hypothesis testing very significant as it helps us assess the population parameters using the sample statistics. Hypothesis tests can be used across Define, Measure, Analyze and Improve phase of an improvement project Define Phase : To test whether the target set is significantly different from the baseline performance. Measure phase : Understanding the likelihood that a data sample comes from a population that follows a given probability distribution (i.e. normal, exponential, uniform, etc.) Analyse Phase : For screening potential causes. Evaluating several process factors (process inputs, or x’s) in a designed experiment to understand which factors are significant to a given output, and which are not. Improve phase : Evaluating a proposed process improvement, using pilot study output, to see if its effect is statistically significant, or if the same improvement could have occurred by random chance. Thanks Jisha Nair

Inarguably all the above 4 statements holds true for Poka Yoke, as the intention of Poka Yoke is to either prevent the mistakes or detect the defects. Prevention prevents errors from occurring or prevents those errors from causing defects. Detection identifies a defect and immediately initiates a corrective action to prevent multiple defects from leaving the workstation. Detection devices are usually used to deal with the errors that is difficult to eliminate or is under review and the main idea of prevention techniques is to keep an error from producing multiple defects. Now let us take a look at the 4 statements and how poka yoke is applied to each The human error will not happen at all This is a kind of Prevention Poka Yoke and is generally associated with design. Some examples could be Kettle cut off switch, USB ports plug in, Plug points etc. Human error may continue to happen but the defect will not happen. This is a detection Poka Yoke, in such cases the mistake proofing technique is implemented such that even if the operator makes a mistake the defect will not happen e.g a machine will not start if all the components are not put in its place, a printer will wait for the paper feed if there is no paper in the tray etc Human error may happen, the defect is less likely to happen This is also a detection poka yoke, wherein the chances of defect happening is reduced but not completely eliminated. Examples of such scenario is the auto cut feature while filling petrol, Alerts on printer ink being low, machines shutting down when the sensor detects some abnormality so that operator can take corrective action and restart the machine etc Human error may happen, the defect will also happen but will be detected and corrected automatically. Another detection poka yoke scenario, one example of such scenario is Spell check feature in Microsoft office products like word, excel, email etc. wherein even if we make mistake it will be autocorrected. Thanks Jisha Nair

A false alarm, occasionally maybe okay or one may never want it similarly a missed alert may not be acceptable or sometimes it can be lived with. Too many false alarms can lead to unwarranted changes in a perfectly stable process and might lead to defects being produced at a later time, and at the same time missed alert means that the defective product will reach the customer which would have business impacts. In statistical terms, one can say that a false alarm is like a Type I error, and a missed alert is like a Type II error. As in the case of type I and type II errors, it largely depends on the consequences of these alarms which would help one decide which is more critical. Personally I would prefer a false alarm over a missed alert, as a false alarm will give opportunity to the operator / process engineer to study the cause of the alarm and then only he would take action on the process, however a missed alert passes on the fault to the next step, and the chances of the defect reaching the customer is high. Thanks Jisha Nair

Fault Tree Analysis (FTA) FTA is a top down, deductive- failure analysis. As a deductive approach, FTA starts with an undesired event, such as failure of a main system, and then determines its causes using a systematic, backward-stepping process. In determining the causes, a fault tree (FT) is constructed as a logical illustration of the events and their relationships that are necessary and sufficient to result in the undesired event, or top event. The logic relationship of events are shown by logic symbols or gates like AND or OR gate. Levels of a FTA are Top Undesired event which is broken down into Intermediate events which is further broken down into basic events. FTA is most commonly used in system reliability, maintainability and safety analysis. FTA is useful both in designing new products/services and in dealing with identified problems in existing ones. In the quality planning process, the analysis can be used to optimize process features and goals and to design for critical factors and human error. As part of safety process improvement, it can be used to help identify root causes of undesired events such as occupational injuries and illnesses. If we have the quantitative date of failure probability, failure rate and repair rate we can also use FTA to evaluate the probability of occurrence of the top event using analytical or statistical methods. Aerospace engineering also has found applications of FTA. FTA is least useful in analyzing complex systems, as it may require separate fault tree for each top event making it difficult to analyse. And mostly it relies on the tacit / subjective knowledge of the people involved in constructing the FTA and the level of detail and completeness will be limited.