OCAP的基础

Ash_of_diamond

谈到SPC我倒是想起一个搁置了很久的话题，有一些朋友问我到底什么是OCAP（Out of Control Action Plan)，我说这个东西很难拿到案例，因为这是公司的knowhow，是知识累计，不会拿出来示人的。OCAP说起来容易做起来，需要失败总计，需要不断累积，需要一次次详细和具体记录，需要总结，需要改进，需要多少年如一日的积累，数据少了，做不出OCAP，OCAP是SPC的母体，但你有就是有，没有就是没有，靠编是编不出来的。于是有人认为这东西，SPC手册里都没写，搞出了名词来忽悠人的，我只能呵呵一乐，一笑而过，在我心目中没有OCAP，SPC才是真正的忽悠人的东西。

我用“三星健康”做记录有一段时间了，我习惯性地把一些特殊的事件记录在曲线上，今天我把这些记录翻出来看的时候，我忽然发现这其实就是OCAP的基础数据之一，Log（日志）：

骑车的Log：

12月1日，下班，正常

正常

12月3日上班，逆风，阵风6级，最高时速低过历史水平

超风速

12月3日，下班，逆风，阵风6~7级， 瞬间超风速，最高时速破纪录

不过

12月16日，上班，逆风，持续5级，挡位由7降为5，双井桥下，长时间等待，GPS数据不正常，-40米和90公里的时速为软件Bug。

拥堵

12月16日，下班，顺风4级，走中街，中街有两路公交车，通行缓慢。



12月16日，温度为零下（天气预报，今夜为-7度），“今天没用围巾盖住口鼻”，导致直接吸入了大量的冷空气，大约400米后，肺不舒服，连续咳嗽，不得不降速，配速低于12.5公里/小时。


OCAP的基础就是这样的日志，在生产过程中，工人记录下每个检测时段的状况，正常则记录得简单，异常则要写明状况，若有了措施，要记录原因分析过程，对策，结果，没有对策，只做了原因分析，就记录下分析的过程和结果，如果，没做分析，只做了点检，就记录下检查了什么等等，说白了就是个流水账。上了班就记，下了班就把记录的内容输入在电脑里，日复一日，年复一年。

过程工程师会把这些数据拿出来看，分类做汇总。如某个参数在控制图上连续出现漂移， 当班的工人发现，这个漂移是由于导轨的螺丝松动导致的，检查后拧紧恢复正常，这就是针对一个Out of Control 的现象的Action，或者产线工人不知道产生原因，但他为设备做了保养，结果回复了正常，他也记录下，工程师把这样的action，提取出来放入履历，当这样的Action 多了，履历丰富了，再总结出来，就可以当作预防的计划来用，这就是OCAP。当操作人员看到控制图上出现异常的信号，就打开这样的OCAP，针对着计划中的提示逐项检查。

像我在文中提到的，16日晚上跑步时出的状况，我提出的对策是未经证实，这可以用作参考，经过验证后才可算作对策。

我认为OCAP是SPC的内核，没有这个为基础，控制图就没有办法真正的用起来，但OCAP却是在SPC中最容易理解，却最难以做到的一部分，因为这不是靠突击，靠抄袭，靠山寨，靠聪明，靠黑带的指点就能做到的。也许没有OCAP这样的工具，控制图做得再好，也是“零”。

xhjfbi

就是基础数据库。