鱼骨图分析

分析人：张伟

部门：产品研发中心

日期：0000年9月19日

问题：9月需求确认平均延误4天

结论：主因是材料发出偏晚，结论当天未落成文字

一、问题陈述

9月应当确认的8条需求，从材料齐套到目录里出现结论，平均比约定日晚4天。样本是9月的8条需求，最早晚2天，最晚晚6天。约定日写在每条需求的期望确认日上。张伟在9月19日用鱼骨图把原因分成人员、方法、信息、协作四类，供陈静在9月22日评审前看。目标是10月的确认不再整批晚于约定日。

样本8条，平均延误4天，区间2天到6天。
延误的终点是目录里出现带负责人的结论，不是会上口头说完。
分析日9月19日，阅读人是陈静。
改进要在10月的两场评审里看到变化。

二、分析范围

只分析产品研发中心9月这8条需求的确认过程。四类原因是人员、方法、信息、协作。每类先写已经发生的事实，再判断哪一条最能解释4天。外部补丁和测试环境故障不放进这张图，它们影响的是缺陷关闭，不是确认日。分析完成后，改进只改材料和结论两件事。

样本限定为9月的8条需求。
四类：人员、方法、信息、协作。
缺陷修复的环境问题另案跟踪。
改进落在发材料的时间和结论落盘。

三、原因分解

下图以「需求确认延误」为中心，四类原因各有两条已发生的事实。张伟与刘洋、周敏在9月19日上午核对过这些事实的日期。

四、主因判断

四类里，方法类最能解释平均4天。8条里有6条的材料在会前半天发出，参会人在会上才读，讨论被读材料占去，结论改到会后写，目录因此晚一天到两天。再加上9月9日出差把一场会推迟两天，两条加在一起接近4天。信息类的两版附件和3处字段，只出现在2条需求上，解释不了全部样本。协作类的反馈晚到，影响的是李婷相关的2条，不是8条的平均数。

6条材料在会前半天发出，是出现次数最多的事实。
出差推迟两天，只影响9月9日那一场。
两版附件出现在2条需求上。
反馈晚两天出现在与李婷相关的2条上。

五、改进措施

针对主因做两条，10月就开始。第一条，材料在会前两个工作日发出，当天发不出的议题改到下一场。第二条，结论在散会前写入目录，写明负责人和完成日，口头结论不当作确认完成。附件只保留会前发出的那一版，新版本另开一条需求。李婷在收到材料后一个工作日内回复，这条从10月的需求确认开始执行。

会前两个工作日发材料，逾期议题改期。
散会前落盘，目录里要有负责人和完成日。
附件以会前那一版为准，改动另开条目。
李婷的回复时限是材料发出后一个工作日。

六、验证安排

10月用两场评审验证。张伟记录每场的材料发出时间、会时、当场写入目录的结论数。若两场都是提前两个工作日发材料，并且结论在散会前落盘，则主因判断成立，做法保持到12月。若仍出现平均延误超过1天，张伟在10月31日重画一次鱼骨，把新的事实补进四类。验证结果用一页纸交给陈静。

验证场次是10月的两场需求评审。
记录三项：发出时间、会时、当场结论数。
保持条件是两场都提前两个工作日，且当天落盘。
未改善时，10月31日重画，并交出一页结果。