范文一:项目管理-事态升级管理
项目管理 -事态升级管理规定
一、目的:
启动项目事态升级的目的是为了保证 APQP 小组能够按时按质按量完成汽车 项目开发任务, 及时纠正各个阶段中出现的问题, 降低项目风险, 确保项目进度 和顾客满意。
二、范围:
适合于所有汽车项目新产品开发过程。
三、职责:
3.1 APQP组长:项目开发过程中出现问题时, 对问题加以明确并组织解决问题; 当问题不能有效解决时启动项目事态升级程序,并持续跟进问题的解决。
3.2 总经理:关注项目事态升级, 当项目组长在其责任层次上不能有效解决问题 时, 召集会议作出决策, 同时为问题有效解决提供强有力的支援。 当确定公司内 部综合能力不能达成客户要求时,指示客户协商或客户支持。
四、定义:
3.1 项目事态升级:当项目开发过程中出现问题时,必须评估项目风险,根据风 险大小升级到某一个层次,一般有四个层次:项目会谈、高层决策、客户协商、 客户支持。
3.2 项目会谈(1级):当项目进程与计划进度及项目目标出现偏差时,项目组 长邀请各部门相关人员参加会谈, 检讨问题解决方案, 落实责任人和完成期限。 3.3 高层决策(2级):如果 1级项目会谈没有达到期望效果,或现有能力不能 有效解决问题时,由项目组长报告总经理,启动高层决策。
3.4 客户协商(3级):如果 2级高层决策确定公司内部综合能力不能达到客户 要求时,由总经理指示相关人员与客户协商。
3.5 客户指导(4级):若以上几级均不能有效解决问题,则由总经理裁定并安 排邀请顾客到现场进行深入指导, 举行顾客与公司高层的会谈, 确定最终改进方 案。
五、内容 :
5.1 汽车新项目启动时,公司高层指定项目组长,并成立项目小组。项目组长需 依照客户需求确定项目目标,编制【项目进度计划表】,并报经公司高层批准。 5.2 项目组长按照项目开发节点定期或随时召集项目小组会议,确定项目进度、 重点工作完成状况、布置下一阶段工作任务,评估项目风险。 通常存在的项目 风险并导致事态升级的原因可能是:
A 、未遵守预定的开发期限;
B 、未实施决定性措施;
C 、质量能力 /质量绩效得不到保障;
D 、看不到进步;
E 、未遵守承诺;
F 、项目流程中出现的偏差在目前的责任层上无法解决。
5.2.1当项目开发进度正常时,项目组长在【项目进度计划表】中用绿色标识已 完成事项。
5.2.3当某一事项未按时完成或完成结果偏离目标时,项目组长评估此事项是否 会影响整体项目进程或对客户端带来不良影响, 若没有影响或影响轻微, 则由项 目组长与责任部门相关人员进行项目会谈, 确定问题解决方案, 落实责任人和完 成期限。 并将项目会谈结果通报项目小组全体成员公司及公司高层。 项目组长在 【项目进度计划表】中用黄色标识出有问题的事项。
5.2.3当该事项严重影响整体项目进程或对客户端带来不良影响,或者项目会议 后仍未能消除问题, 则项目组长启动事态升级, 报告公司高层决策, 高层决策结 果通常为:责令责任人限期改进、 动用其它人员及资源解决此问题、 当公司现有 能力和资源不能有效解决问题时进一步启动项目升级,指示客户协商或客户指 导。项目组长在【项目进度计划表】中用红色标识出有问题的事项,并跟进问题 的解决。
5.3 公司高层指示客户协商或客户指导时, 项目组长和相应人员需充分了解问题 状况及原因, 明确协商事项和协商目标; 当需要请求客户指导时, 需要明确客户 支持人员、指导内容、内部协调事项等。
5.4 项目组长需落实做好事态升级的启动、处置、跟进记录,需要时进行总结并 持续完善新品开发制度和流程。
六、流程
项目事态升级管理过程详见以下流程图:
范文二:什么是事态升级
什么是事态升级?
是指在新产品实现过程、产品交付过程等任何一个阶段所发生的影响客户新品开发进度和质量保证、影响产品正常交付的一切不良事件,都可称为升级管理事件,或作为事态升级管理,,
2、如何实施事态升级管理?
对于以上所说的不良事件,一旦发生或发现则要汇报给有权力和管理职责的领导来处理,由管理者确定和启动必要的改善措施,,,任何不良事件一定要开展风险分析,分析其本身的不良风险程度和对后续客户的影响风险,并根据风险大小采取进一步的改善和遏制措施,所有这些汇报、分析、处理、改善、验证、解决的工作流程最好形成规定的程序,以便标准化管理和后期工作人员快速使用。
事态升级管理,可以说是一种为了解决正常管理工作流程中出现异常情况的特定要求的管理方法,其最终管理目的是避免和防止工作失误的不良影响扩大或导致特定工作的中断,,
范文三:事态升级管理规定
文件名称:事态升级管理规定 文件受控章
一、 目的:
启动项目事态升级的目的是为了保证 APQP
及时纠正各个阶段中出现的问题,降低项目风险,确保项目进度和顾客满意。
二、范围:
适合于所有汽车项目新产品开发过程。
三、职责:
3.1APQP 组长:项目开发过程中出现问题时,对问题加以明确并组织解决问题;当问题不能 有效解决时启动项目事态升级程序,并持续跟进问题的解决。
3.2总经理:关注项目事态升级,当项目组长在其责任层次上不能有效解决问题时,召集会议 作出决策,同时为问题有效解决提供强有力的支援。当确定公司内部综合能力不能达 成客户要求时,指示客户协商或客户支持。
四、定义:
3.1项目事态升级:当项目开发过程中出现问题时,必须评估项目风险, 根据风险大小升级到 某一个层次,一般有四个层次:项目会谈、高层决策、客户协商、客户支持。 3.2项目会谈(1级) :当项目进程与计划进度及项目目标出现偏差时,项目组长邀请各部门 相关人员参加会谈,检讨问题解决方案,落实责任人和完成期限。
3.3高层决策(2级) :如果 1级项目会谈没有达到期望效果,或现有能力不能有效解决问题 时,由项目组长报告总经理,启动高层决策。
3.4客户协商(3级) :如果 2级高层决策确定公司内部综合能力不能达到客户要求时,由总 经理指示相关人员与客户协商。
3.5客户指导(4级) :若以上几级均不能有效解决问题,则由总经理裁定并安排邀请顾客到 现场进行深入指导,举行顾客与公司高层的会谈,确定最终改进方案。
五、内容 :
5.1汽车新项目启动时,公司高层指定项目组长, 并成立项目小组。 项目组长需依照客户需求 确定项目目标,编制【项目进度计划表】 ,并报经公司高层批准。
5.2项目组长按照项目开发节点定期或随时召集项目小组会议, 确定项目进度、 重点工作完成
文件名称:事态升级管理规定 文件受控章
状况、布置下一阶段工作任务,评估项目风险。 通常存在的项目风险并导致事态升级的 原因可能是:
A 、未遵守预定的开发期限;
B 、未实施决定性措施;
C 、质量能力 /质量绩效得不到保障;
D 、看不到进步;
E 、未遵守承诺;
F 、项目流程中出现的偏差在目前的责任层上无法解决。
5.2.1当项目开发进度正常时,项目组长在【项目进度计划表】中用绿色标识已完成事项。 5.2.3当某一事项未按时完成或完成结果偏离目标时,项目组长评估此事项是否会影响整体 项目进程或对客户端带来不良影响,若没有影响或影响轻微,则由项目组长与责任部门 相关人员进行项目会谈,确定问题解决方案,落实责任人和完成期限。并将项目会谈结 果通报项目小组全体成员公司及公司高层。项目组长在【项目进度计划表】中用黄色标 识出有问题的事项。
5.2.3当该事项严重影响整体项目进程或对客户端带来不良影响,或者项目会议后仍未能消 除问题,则项目组长启动事态升级,报告公司高层决策,高层决策结果通常为:责令责 任人限期改进、动用其它人员及资源解决此问题、当公司现有能力和资源不能有效解决
中用红色标识出有问题的事项,并跟进问题的解决。
5.3公司高层指示客户协商或客户指导时,项目组长和相应人员需充分了解问题状况及原因,
内部协调事项等。
5.4项目组长需落实做好事态升级的启动、处置、 跟进记录, 需要时进行总结并持续完善新品 开发制度和流程。
六、流程
项目事态升级管理过程详见以下流程图:
文件编码规则 BT-C-Q-054版 次 01页次 4/3文件名称:事态升级管理规定 文件受控章
七、参考文件 :
7.1APQP 质量策划管理程序 BT-B-P-002APQP
八、表单 :
无
修 订
记 录
版本 修订内容 实施日期 编制 审核 批准
范文四:事态升级管理
编号 A0
制订日 年 月 日 事态升级管理办法
修改日
隶属标准
1 目的
建立和保持一个文件化的升级流程以解决公司生产活动中遇到的各种事态升级问题的处理,特制订本办法。
2 范围
2.1本办法适用于公司以下事态升级问题的处理:
? 供应商质量问题;
? 不合格品处理(含过程、终检等发现的不合格品);
? 客户反馈/客户投诉;
? 环境、安全事故及其它问题。
3 管理职责
3.1 综合办是事态升级管理的归口管理部门:
3.1.1 负责本办法制定、修改并组织实施。
3.1.2 负责对本办法的实施情况予以监督、检查和考核。
3.1.3 负责把事态升级过程中发现的问题及时向主管领导及相关部门、上级公司人力资源部反馈。
3.2 各部门负责人:
3.2.1 负责本办法组织本部门实施,并对实施情况予以监督、检查、考核。
3.2.2 负责把实施过程中发现的问题及时向综合办门反馈。
4 事态升级管理流程与要求
4.1供应商质量问题升级管理流程
输入 活动 责任人 升级原因/升级内容 输出 供方来料来料检验员 来料检验员将不良状况反馈给项可疑产品标签 外观/尺供方来料外观/尺寸 目组质量工程师和项目工程师。 寸不符合不符合要求,供方延 升级可能原因: 要求,供期交付等 1、相关工程师不能做最终判定。 方延期交 2、判定标准不清晰。 付等
Y 质量工程师项目组质量工程师和项目工程师 项目工程师确认 和项目工程根据不良信息和接收标准判定是
师 否可以接收。 N
升级可能原因:(同上) Y 各部门长、来料检验员召集各部门评审,探讨不合格评审表 各部门评审 N 来料检验员 不合格品处置方式。
升级可能原因:各部门长意见不能 N 统一。
总经理终评 总经理 总经理给出最终处理意见 Y
Y
通知供应商整改 来料检验员 来料检验员通知供应商整改。 纠正预防措施
供应商 表
8D报告
问题解决 供应商 供应商提交整改报告,完成整改。
采购员
4.2不合格品处理(含过程、终检等发现的不合格品)升级管理流程 输入 活动 责任人 升级原因/升级内容 输出 产品外观检验员、操操作员将不良状况反馈给班组长可疑产品标签 /尺寸不作员 和检验员。
产品外观/尺寸不符符合要求 检验员将不良状况反馈给项目组
合要求 质量工程师或项目工程师。
升级可能原因:
1、相关工程师不能做最终判定。
2、生产部对最终处置方式不满意。
3、判定标准不清晰。
Y 质量工程师项目组质量工程师和项目工程师 项目工程师确认
和项目工程根据不良信息和接收标准判定是不合格评审表
师 否可以接收。 N 升级可能原因:
1、相关工程师不能做最终判定。
2、客户接收标准不清晰。
各部门评审 各部门长、检验员召集各部门评审,探讨不合不合格评审表 Y
检验员 格品处置方式。
升级可能原因:各部门长意见不能 N
统一。
客户 业务经理与客户进行沟通,将不良 客户技术支持 业务经理 信息传递给客户,让顾客评审验证
不良状况的影响程度,在客户处进 Y 行试装,验证试装效果。
质量部 质量部根据评审结果或者客户技 品质部分解、落实整改措施 责任部门 术支持对问题进行分析,确认根本
原因,分解、落实责任部门进行整
改措施,并要时提交客户确认。
问题解决 质量部验证整改措施,完成整改。 4.3客户反馈/客户投诉升级管理流程
输出 输入 活动 责任人 升级原因/升级内容 交付产品业务经理、业务部或质量部接到客户反馈,将确认不良状态 在客户端质量工程师 不良的状态信息传递给质量工程 查库存(客户交付产品在客户端已组已组装或 师 处,运输途中, 装或终端市场上反馈外 成品库),半 终端市场观/尺寸/功能不符合客 成品,原材料。 上反馈外户要求 顾客质量信息观/尺寸/
功能不符 反馈表 合客户要 求 质量工程师及时安排确认不良状8D报告 Y 质量工程师态,并按文件要求召开相应的8D顾客质量信息项目工程师确认
和项目工程会议对应改善措施,告知客户改善反馈表
师 方案与完成时间。 客户退货申请N 升级可能原因: 表
1、交货时间紧急开发不能满足要
求,强行要求按此状态交货。
2、顾客索赔金额大于1000元。
各部门长、质量部按要求出相应的8D报告给 各部门评审 Y 检验员 相关部门长审核,由质量部跟进改
善措施与完成时间。 N 升级可能原因:
输出 输入 活动 责任人 升级原因/升级内容
交付产品业务经理、业务部或质量部接到客户反馈,将确认不良状态 在客户端质量工程师 不良的状态信息传递给质量工程 查库存(客户交付产品在客户端已组已组装或 师 处,运输途中, 装或终端市场上反馈外终端市场 成品库),半 观/尺寸/功能不符合客上反馈外 成品,原材料。 户要求 观/尺寸/ 客户投诉处理
功能不符 记录表
合客户要
求 质量工程师及时安排确认不良状8D报告 Y 质量工程师态,并按文件要求召开相应的8D 项目工程师确认
和项目工程会议对应改善措施,告知客户改善
师 方案与完成时间。 N 升级可能原因:
1、交货时间紧急开发不能满足要
求,强行要求按此状态交货。
各部门评审 各部门长、2、顾客索赔金额大于3000元。 Y
检验员
N
质量部按要求出相应的8D报告给不合格评审表
客户 相关部门长审核,由质量部跟进改 客户技术支持 业务经理 善措施与完成时间。
升级可能原因: Y 1、相关工程师不能做最终判定。
2、客户接收标准不清晰。 不合格评审表
质量部 检验员召集各部门评审,探讨不合 品质部分解、落实整改措施 责任部门 格品处置方式。
升级可能原因:各部门长意见不能
统一。
业务经理与客户进行沟通,将不良
信息传递给客户,让顾客评审验证 问题解决 不良状况的影响程度,在客户处进
行试装,验证试装效果。
质量部根据评审结果或者客户技
术支持对问题进行分析,确认根本
原因,分解、落实责任部门进行整
改措施,并要时提交客户确认。
质量部验证整改措施,完成整改。
附加说明:本办法由综合办归口并解释。本办法自修订之日起实施。
文件会签单
修改内容:
修改履历
版本 修订日期 修订原因及内容摘要 修订人
是否需要会签: ? 是 ? 否 是否需要分发: ? 是 ? 否
分发分发会签部门 会签者 会签部门 会签者 份数 份数 ? 总经理 ? 财务部 ? 技术部 ? 业务部 ? 综合办 ? ? 生产部 ? ? 质量部 ? ? 采购部 ?
编制或修订者/日期 审核/日期 批准/日期
范文五:事态升级程序[教学]
上海德朗能动力电池有限公司
DLG power battery ,Shanghai,Co., Ltd
文件编号 DLG/QP-26 文件版本 A.0 文件页数 共 7 页 编制部门 技术部
编制 审核 批准 盖章
Jason Chen
1.目的:识别在过程设计、生产中和销售后可能出现的“缺点”及其“原因”提前采取改善措施,保证提交给客户高质量的产品和服务。
2(范围:适用于本公司汽车产品在制造过程开发、生产中和销售后整个生命周期的风险识别和管理。
3(权责:
3.1最高管理者:最高管理者作为本公司产品风险的负责人,负责: 3.1.1制定本公司的风险管理方针;
3.1.2为风险管理活动配备充分的资源和有有资格能胜任的人员; 3.1.3规定风险管理的职责和权限,授权品管部确定风险管理小组成员; 3.1.4主持每年的风险管理活动评审;
3.1.5批准《风险管理报告》。
3.2品管部:品管部作为本公司风险管理的主管部门,为确保在计划的规定阶段完成风险管理活动:
3.2.1负责指定各项目风险管理负责人;
3.2.2负责批准风险管理计划;
3.2.3负责组织协调风险管理活动;
3.2.4负责跟踪检查风险管理活功实施情况。
3.3项目风险管理负责人:
3.3.1负责制定风险管理计划;
3.3.2负责组织风险管理小组实施风险管理活动;
3.3.3负责跟踪相关活动,包括生产和生产后的信息,对涉及风险管理活动的内容,必要时执行风险管理活动;对涉及重大风险的,可直接向最高管理者汇报。 3.3.4负责整理风险管理文档,确保风险管理文档的完整性和可追溯性。 4(定义:
4.1剩余风险:采取风险控制措施后余下的风险。
4.2风险控制:作出决策并实施措施,以便降低风险或把风险维持在规定水平的过程;
4.3风险评价:将估计的风险和给定的风险准则进行比较,以决定风险可接受性的过程;
4.4风险估计:用于对损害发生概率和损害严重度赋值的过程; 4.5生命周期:在产品寿命中,从初始概念(本公司为:样件)到最终停用或处置的所有阶段。
4.6生产后:在设计己完成并且产品生产以后的产品生命周期部分,如运输、贮存、安装、产品使用、维护、修理、产品更改、停用和废置。
5(流程图:
5.1过程开发风险识别、评价与管理流程图,参见(附件一); 5.2生产和上市后风险管理流程图,参见(附件二)。
6(作业程序和内容
6.1建立风险管理方针
最高管理者应充分评价外部及肉部相关信息,制定本公司的风险管理方针。最高管理者每年至少一次对风险管理活动进行评审,必要时可增加评审的次数。最高管理者对新产品批量交货前的风险管理评审活动形成的结果《风险管理报告》进行审批。 6.2组成风险管理小组
6.2.1本公司风险管理小组成员由项目小组成员承担,风险识别、评价人员应接受风险分析工具的培训,并经考核合格。
6.2.2风险管理小组的构成必须包括熟悉产品原理及功能组成的成员(如:工程师、生技等),熟悉产品制造成员(如生产部主管)以及熟悉产品应用的成员(如:品管)。小组成员应具有和赋予他们的任务相 适应的产品及其应用的知识和经验,以及具有风险管理技术知识。
6.3风险管理活动
6.3.1风险管理计划
原则上,每一规格型号的产品都应建立风险管理计划,如果相似产品使用同一份计划时,应说明适应性。
计划至少应包括:
a)策划的风险管理活动范围:判定和描述医疗器械和适用于每个要素的生命周期阶段;
b)职责和权限的分配;
c)风险管理活动的评审要求;
d)基于制造商决定可接受风险方针的风险可接受性准则,包括在损害发生概率不能估计时的可接受风险的准则;
e)验证活动;
f)相关的生产和生产后信息的收集和评审的有关活动。
6.3.2风险管理过程
?过程开发过程
(1)本公司没有产品的开发过程;过程的开发按《项目过程管制程序》执行。过程开发过程风险管理应对产品整个生命周期内的风险管理进行策划。
(2)在过程开发策划阶段,新项目负责人和风险管理负责人组织风险管理小组并制定产品《风险管理计划》,并应经品管部负责人审批。
(3)风险管理小组按照要求,进行初始风险分析。此次风险分析的结果应形成记录,作为风险管理文档保存。风险分析的结果还应作为过程开发输入的一部分,并在对过程开发输入阶段评审时对此进行评审。
(4)项目人员在开始进行过程开发时,必需了解所负责过程开发部分的风险,并获得相关的风险管理文档, 同时将相应的风险控制措施落实在具体的过程开发方案中。
(5)在过程开发阶段,对涉及有关安全性问题的失效,特别是对风险设计和开发输入阶段尚未识别的风险做进 一步的风险分析。
(6)过程开发输出文件,其中包括最终确定的风险控制措施及相关设计文档。应对风险控制措施实施评审,
评价采取风险控制措施后的剩余风险及采取风险控制措施后是否会引发新的风险,评审结果记录。
(7)过程开发验证应包括对风险控制措施的有效性和风险控制措施的落实情况进行验证,验证结果应记录于风险管理文档。过程开发确认阶段,应结合客户的要求进行分析,最终判断产品的综合剩余风险是否可接受,产品收益是否大于风险,为产品最终是否可以顺利交货作出初步判断。
(8)项目管理人员将根据过程开发计划安排是否需要试生产,在试生产阶段有关安全性的问题应予以记录,并进行评审,以决定是否需要执行相关的风险管理流程。 ?风险管理报告
在产品批量交货前,风险管理小组应对已往的风险管理活动进行评审,必要时可补充确定评审人员。评审内容包括:对风险管理计划实施情况的评审;对综合剩余风险是否可接受的判断;是否已有适当的方法获得相关生产的生产后信息。上述评审的结果应作为《风险管理报告》予以记录,该报告最终由最高管理者审批通过,作为产品能否批量生产和交货的最终结论依据。
?生产和生产后的风险管理
(1)公司建立收集和评审产品信息时,尤其应当考虑:a)由产品的生产者、或负责产品组装和维修人员所产生信息的收集和处理机制;b1新的或者修订的标准。
(2)同时,也应当将最新技术水平因素和对其应用的可行性考虑在内;并应注意该系统不仅应当收集和评审本企业类似产品的相关信息(即内部信息),也应当收集和评审客户端其他类似产品的公开信息(即外部信息)。
(3)生产和生产后信息的收集
信息收集通常可以从质量管理体系中得到。有关信息的获取方法和职能部门见下表:
生产和生产后信息 获取方法,时机 责任人
法规(如:环保标准)的变化 定期网上(客户端)收集 技术部
不良事件(内部、外部) 不良事件报告 品质部
通告,退货 按通告,退货流程 工程部、品质部 客户退货(顾客抱怨)信息 调查(分析)和评审结果 市场部、品质部 设计更改 样品需求评审PFMEA 技术部
采购产品的质量情况 采购产品质量分析 品质部
制造过程的问题 纠正,预防措施 技术部、生产部 产品检验结果和留样产品分析 每月汇总产品检验质量信息 品质部
(4)生产和生产后信息的评审
相关人员在收到信息后,应及时与风险管理负责人沟通,风险管理负责人将视具体情况召集风险管理小组,执行相关的风险管理活动,见附件二。
(5)对分析结果可能涉及安全性的信息,应评价是否存在下列情况: 是否有先前没有认识的危害或危害处境出现,或是否由危害处境产生的一个或多个估计的风险不再是可接受的。如果上述任何情况发生,一方面,应对先前实施的风险管理活动的影响进行评价,作为一项输入反馈到风险管理过程中,并且应对产品的风险管理文档进行评审。如果评审的结果可能有一个或多个剩余风险或其可接受性已经改变,应对先前实施的风险控制措施的影响进行评价,必要性进一步采取措施以使风险可接受。然后,应根据前面分析和评审结果,寻找产品改进方向,重复和完善适当的风险管理过程,修改相应的风险管理文档和风险管理报告。
6.4风险评价和风险可接受标准
本公司虽然针对涉及的产品,在风险管理方针的基拙上,制定了风险评价和风险可接受标准。但针对每一特定的产品,在制定风险管理计划时,仍须对此风险可接受标准的适宜性进行评价,如不适宜应重新制定。
表1风险的严重度(S)评价准则:
等级名称 严重度 系统风险定义
轻微 1 需要在生产线上原工位返工,
外观质量缺陷很轻微,很少顾
客发现有缺陷
很低 2 产品经筛选,部分需要返工,
外观质量有缺陷,多数顾客能
发现
低 3 产品需100%返工,产品能使
用,有较多缺陷,顾客有些不
满足
中等 4 部分产品报废(不筛选),产品
能使用,但性能稍有下降,顾
客不太满足 高 5 产品需筛选,部分报废,部分
可使用,但性能下降,顾客不
满意
很高 6 可能100%的产品要报废,造成
产品无法使用,丧失基本功能,
顾客非常不满意
有警告的严重危害 7 可能危害产品使用者。潜在失
效模式严重影响客户组装和安
全或包含不符合政府法规项,
严重度很高。失效发生时有警
告
无有警告的严重危害 8 无有警告的可能危害产品使用
者。潜在失效模式严重影响产
品安全或包含不符合政府法规
项,严重度很高。失效发生时
无警告
表2风险发生频率(S)评价准则
失效发生可能性 频度 频次(每年)
-6极少:失效不大可能发生。几1 <10>10>
乎完全相同的过程也未有过
失效
-4-6非常少:很少几次与几乎完全2 10-10
相同的过程有关的失效
-2-4很少:很少儿次与相似过程有3 10-10
关的失效
-1-2与前时有失效发生,但不占主4 10-10
要比例的过程相类似的过程
有关
-1有时:一般与以前经常发生失5 1-10
效的过程相似的过程有关
经常:失效几乎是不可避免的 6 >1
表3风险评价表
严重程度
概率 1 2 3 4
轻度 重度 致命 灾难性
经常 6 R U U U
有时 5 R R U U
偶然 4 R R R U
很少 3 A R R R
非常少 2 A A R R
极少 1 A A A A 说明:A:可接受风险;R:合理可行降低的风险;U:不经过风险/收益分析即可判定为不可接受风险
6.4.1产品安全标准的应用
?在有适用的产品安全标准时,应通过符合安全标准的要求来降低产品的安全风险。即使产品有相关的安全标准,也必须走风险管理规定的流程。因为符合安全标准并不能保证产品是安全的。评价产品的安全风险时总是需要考虑标准之外的因素。
?产品必须在过程开发阶段输入相关的安全标准,确保其符合安全标准要求。己批量交货的产品若发生相关安全标准的变化,应作出评价,必要时与顾客进行沟通,进行设计更改以符合标准要求。
?如果安全标准中规定了结构上的安全规范和,或规定了安全指标的限制,必须在风险控制措施中引入,并实施相关的风险控制措施的验证。对该风险的初始风险估计可以省略,且采取该风险措施后,可认为损害发生的概率为最低,剩余风险可接受;除非有进一步的数据和资料显示须对风险重新评价。
6.4.2风险管理档案
?品管部针对每种汽车用电芯产品建立和保持完整的风险管理裆案。风险管理档案提供每一个判定危害的追溯性信息,包括:风险分析、风险评价、风险控制措施的实施和验证、任何剩余风险可接受性的估计。
?风险管理档案包括所有与风险管理各阶段有关的文件和记录。 7(相关文件:
7.1项目过程管制程序
7.2文件和资料控制程序
设计风险管理阶段划分 风险管理活动
评审 评审
风险管理计划
审批和评审※预期用途※识别危害设计和开发※功能、性能和安全要求※风险估计 风险管理计※适用的法规和法规安全要求※风险评估策划 ※以前的相似产品安全信息※风险控制措施要求划 ※其它安全要求
风险是否降低风险控制方设计和开发 案可行性评输入 估
剩余风险可接受
评价风险控制措实施各项风险控过程设计施后的剩余风险制措施,并实施PFEMA及是否会产生新设计开发 必要的验证风险
是否产生新风险设计开发输 风险控制的完整性检查出
设计开发验设计开发验证应包括对风 险控制措施的有效性和风险控制落实情况进行验证证
综合剩余风险是否项目取消或重新设计收益是否大于风险可接受设计开发确 认
试生产阶段是否产生新产品上市前评估并形成风险管理报告的安全性问题设计转换
附件二:
文 件 更 改 履 历 表
? 文件版次 更 改 内 容 更改日期 1
转载请注明出处范文大全网 » 项目管理-事态升级管理