风险管理跟踪表

合集下载

11月份重大风险管控措施跟踪表

4、每天检查副斜井内挡车装置和跑车防护装置完好情况，发现装置不完好立即修复。
10
副斜井
冬季副斜井底板可能有结冰现象，无轨胶轮车在副斜井行驶，可能造成跑车
1、加强井口暖风机维护，保证暖风机正常运转。
2、每班安排专人对副斜井进行巡查，发现结冰严禁车辆在副斜井内行驶，并对结冰段立即处理。
3、井口检身员加强入井车辆检查，严禁带病车辆入井。
2、掘进过程中及时使用前探梁进行临时支护。
3、进行永久支护时，先对顶板和两帮进行敲帮问顶，使用长把工具摘掉活岩危矸后方可进行作业。
4、支护不到位严禁任何人员进入空顶下作业。
7
5104、5105工作面、总回风巷
5105工作面上偶角、总回风巷瓦斯积聚，瓦斯超限，可能引起瓦斯爆炸
1、根据回采工作面瓦斯涌出量合理确定配风量，在工作面上偶角安装瓦检传感器，时时监测瓦斯浓度
12
全矿井
电气设备失爆产生电火花，引爆煤尘
1、井下在用电气设备必须有防爆入井合格证和煤安标志，非防爆设备禁止入井。
2、机电科每天安排专业技术人员，对井下电气设备进行巡回检查，发现电气设备失爆立即停止使用。
13
胶带输送机
胶带跑偏与H架摩擦，引燃煤炭，造成火灾
1、加强皮带巡检工安全培训，皮带巡检工不脱岗、睡岗。
2017年11月重大安全风险管控措施跟踪表
序号
风险地点
风险描述
管控措施
落实情况（落实√未落实×）
1
5105工作面采空区
5105工作面采空区自然风通过地表裂隙进入采空区，采空区内浮煤较多，煤层属I类容易自然煤层
1、加强地表巡查，发现裂隙立即夯实。
2、按防灭火设计对采空区注浆，在工作面溜头、溜尾三角区构筑黄土墙。

项目风险识别及跟踪表

因客户的资金流对应收帐款回收的风险盈利困难
6. 知识产权侵权
产品侵权，无法销售
6. 法律法规的变化
法律法规的变化
结论：
风险严重性
风险可能性
很高较高中等较低很低很高较高中等较低很低
5分 4分 3分 2分 1分 5分 4分 3分 2分 1分
风险系数
-
-
-
-
-
处理方法
转移对象
可接受
玲珑电子
项目风险识别及跟踪表
项目名称
序列号：
项目经理
参与评估的项目组成员
项目组成员会签
填写时间
项目里程碑
表单编号：PM-001-01 版本：00
序号风险分类及风险因素
具体风险内容说明
1.
市场类风险
1. 产品需求信息不明确 1
产品范围不明确，造成项目范围、进度、成本、风险不确定
1. 产品需求时间不明确 2
备注说明
1/1
4.
4.
采购类风险原材料或元器件停产
14. 2
供应商能力预估不足
原材料或元器件停产供应商能力预估不足造成无法按期供货
4. 技术资料不完整
3
4. 4
市场需求变更
5.
财务类风险
技术资料不完整,造成采购材料不符合要求市场需求变更较大，不确定性大
5. 利率ຫໍສະໝຸດ 利率5. 应收帐款 25. 项目成本过高 6. 3 法律法规类风险
3 不到位
造成产品性能不达标
2. 4
相关的仿真和软硬件测试工具缺乏
测试验证不充分造成产品不可靠
3.
进度风险
3. 人员不到位或流失

项目风险记录及跟踪表

风险类别编号风险项是否存在此类风险R01没有有足够的人员可用；是R02项目成员不能及时到岗；否R03项目成员及项目经理没有类似项目的经验；是R04项目成员不具有所需的、适合的专业技术；R05项目成员未完全理解、熟悉个人需负责的任务；R06项目中有一些人员只能部分时间工作；R07开发人员不能自始至终的参加整个项目的工作；R08开发人员的流动可能不能保证工作的连续性；R09开发人员没有接受过必要的培训；R10在项目进行期间，关键项目成员有可能离职；R11其它风险；M01项目目标不清楚；M02项目范围不能准确界定；M03对项目需求调研不充分、可能有遗漏；M04客户、用户参与不充分；M05需求没有经过正式评审、未取得客户的书面确认记录；M06需求变更没有受到控制、未经过变更控制流程；M07没有将各种评审的结果进行文档化，使修改的需求、设计、编码等都有据可依；M08项目活动工作量及活动成本的估算不充分、没有历史数据可以参考；M09制定的项目计划不合理、没有经过正式评审；M10没有及时更新项目计划数据，特别是进度发生重大偏差时；M11没有对项目设计进行正式评审、未取得客户的书面确认记录；M12没有对变更进行严格控制；M13对项目执行过程进行监控不到位、没有与项目成员进行及时而有效的沟通；M14项目成本估算存在遗漏、不合理；M15其它风险；T01项目需要使用不成熟的技术；T02项目需采用以前未曾使用过的技术；T03对某个开发工具过度依赖；T04采用了不适合的开发方法；T05需要开发大量的接口以与其它系统连接；项目风险记录及跟踪表技术风险人力资源风险项目名称及合同号：过程管理风险。

erp 风险跟踪记录表

●风险值是上述风险可能性和风险影响的乘积：风险值＝风险可能性X风险影响对每一个风险都要计算风险值。 ●风险分类可以按照前面风险识别的分类进行，这样容易看出在开发过程中的哪个开发区域存在高风险的情况，为制定风险缓解计划提供了有效的指导。由于每个项目的资源都是有限的，所以风险管理(处理、减缓、监视和控制)必须把精力集中在最重要的风险子集上。风险优先级分为两级：需管理的、仅跟踪的。使用以下方法确定需管理的风险项。 ●Top 10 Risks选择直接对风险值排序，选择风险值最高的前10位。 ●评价Top 10 Risks是否覆盖了大多数的风险情况计算Top 10 Risks的风险值之和占全部风险的风险值之和的比例，如果超过50％，可以将这些风险可作为初始阶段的风险处理和缓解计划的输入；否则，应考虑在初始阶段的风险处理和缓解计划中覆盖更多的风险项，直到初始阶段的风险处理和缓解计划中可以涵盖超过50％风险值的风险为止。
项目团队风险
客户配合风险非项目任务书内的任务，或者其它非项目范围任务的影响（如出差、技术支持，临时性任务安排等）项目经理的项目经验较少，对实施和公司过程规范了解较少合计
项目收益风险
产品交付客户不顺利，项目无法正式结项客户单方面改变主意，放弃合作项目的结束时间、客户验收方式、系统最早提交方式等都未知合计
0 0 0
0
0 0 0 0 0 0 1
0 极高极大 1 1 H-高 H-高
风险分析指南风险分析步骤 ●风险发生的可能性使用极高、高、中、低、极低五级进行评估，可以参考以下概率估计表估算风险发生的可能性。其中最后一列为得分为计算风险值时使用。分级极大大中小极小发生概率（X） X ≥ 90% 90% > X ≥70% 70% > X ≥40% 40% > X ≥20% 20% > X

附录2 风险管理与跟踪表

风险评估、管理与跟踪表
注：
1、“风险严重性”、“可能性程度”和“风险系数”请参见“风险参数”中的说明
2、“阈值”填写风险必须采取行动临界点
3、“影响范围”请说明风险影响项目的事项及程度
4、项目经理（或其指定成员）对风险进行评估和分析时必须考虑风险的应对措施
5、应对策略：
规避——通过变更项目计划，从而消除风险或风险产生的条件或保护项目目标免受风险影响。

转移——把风险及其后果转移到第三方。

转移风险的方法一般包括两种：1）利用第三方成果；2）通过签订合同把特定的风险转移给相关厂商。

缓解——设法将某一负面风险事件的概率和（或）其影响降低到一个可以承受的限度。

接受——项目团队决定以不变的项目计划去应对某一风险，或项目团队不能找到其它合适的风险预防策略。

6、“已经采取的行动”记录项目组为规避或减缓该项风险所采取的行动
7、对于规模较小，面临的风险明确、清晰的项目可以裁剪掉“阈值”列，但必须将影响范围描述清楚
跟踪表
风险转移给相关厂商。

2017煤矿重大安全风险管控措施跟踪落实检查表

xxxxx 矿领导带班跟踪落实重大安全风险
管控
措施检查表
xxxxx 矿
二◦一七年十月
XXXXX矿领导带班跟踪落实重大安全风险管控措施检查表
XXXXX矿领导带班跟踪落实重大安全风险管控措施检查表
xxxxx 矿领导带班跟踪落实重大安全风险
管控措施检查表填写说明
一、姓名、时间、班次及检查地点部分，根据实际情况填写。

二、存在问题部分的内容应是跟踪重大安全风险管控措施落实过程中发现的问题，无问题时填写“管控措施执行到位，无问题” 。

三、处理情况或要求填写说明（一）无问题时填写“持续跟踪落实管控措施” 。

（二）存在问题时处理情况或要求根据实际情况填写以下三种中的一种： 1. 现场已由某某队某某整改； 2. 提交分管领导或相关单位负责制定整改措施，组织落实； 3. 提交下班领导，持续盯防。

XXXXX矿领导带班跟踪落实重大安全风险管控措施检查表（模板一）
XXXXX矿领导带班跟踪落实重大安全风险管控措施检查表（模板二）
XXXXX矿领导带班跟踪落实重大安全风险管控措施检查表（模板三）
XXXXX矿领导带班跟踪落实重大安全风险管控措施检查表（模板四）姓名：时间：年月曰班次：点班
检查地点:
检查区域内重大安全风险管控措施落实情况
精选资料。

风险管理跟踪表

项目编号：项目编号：编号发现日期
项目名称：项目名称：图书管理系统风险类型风险来源风险描述
项目经理
FX001
2011.4.4
管理风险
项目计划
进度计划安排紧张，没有合理的缓冲时间
FX002
2011.4.4
管理风险
项目计划
任务分配可能存在不恰当的情况，有可能会影响进度技术开发队伍有实习生，对其产生的代码质量不好把握
采取措施组织加班。
负责人
张朋心
1．针对拖延的任务进行周例会讨论； 2．由其他成员协助拖延任务责任人加班完成任务。 1．制定编码规范，要求按照执行； 2．由项目经理和技术高的项目组成员定期对实习生代码进行检查并协助纠正指导。
张朋心
张朋心
1．首先根据确认的系统原型基础上做报备子系统的开发； 2．在报备初步完成总体功能后，积极组织对总局客户的汇报演示，总局用户提出了批量变更，项目组停止了第二段的设计开发工作，和客户积极讨论解决办法，并根据办法说明对我们项目的影响； 3．不断修正报备的需求，第一阶段的需求和开发完善后，再次组织向客户汇报演示进行确认； 5．积极推进第二阶段的需求再次确认，在第二阶段原型确认后，开始第二阶段设计开发工张朋心作； 6．系统在开发过程中多次与客户沟通讨论，并在系统完成整体功能情况下再次向客户汇报演示并确认
1．与公司平台支持组针对本系统成功实现的可行性进行讨论； 2．安排平台支持组对系统设计开发人员进行多次培训和指导； 3．根据平台开发的页面风格及早与客户进行沟通确认，接受我们平台的页面风格； 4．开发过程中，平台支持组针对系统开发和设计出现的问题进行协助解决； 5．对平台版本升级过程中，公司平台支持组队项目组进行了培训和辅导； 6．系统开发完成第一个报备子系统后，对总局客户进行演示汇报，对我们的页面风格和设计开发认可并确认。

项目风险管理表

项目风险管理表风险名称：市场需求不稳定风险描述：由于市场竞争激烈和需求波动，项目在运作期间可能会面临市场需求不稳定的风险。

风险影响：市场需求不稳定可能导致项目销售下降，利润减少。

风险概率：中风险名称：技术能力不足风险描述：项目所需的技术能力可能超出团队的现有能力水平，导致在项目实施过程中遇到技术难题无法解决。

风险影响：技术能力不足可能导致项目延期或质量不达标。

风险概率：高风险名称：供应链中断风险描述：在项目进行时，由于供应商的倒闭、物流问题或天灾等原因，供应链可能中断，无法按时获取所需的材料和设备。

风险影响：供应链中断可能导致项目停工，延误交付期限和增加成本。

风险概率：低风险名称：人力资源短缺风险描述：项目所需的人力资源可能不足，无法满足项目进展所需的速度和质量。

风险影响：人力资源短缺可能导致项目延期、效率低下和质量下降。

风险概率：中风险名称：财务需求超出预算风险描述：项目执行过程中，财务需求可能超出预算，导致项目无法按计划进行。

风险影响：财务需求超出预算可能影响项目的正常运行，增加融资压力和项目风险。

风险概率：低风险名称：政策法规变化风险描述：在项目执行期间，相关的政策法规可能发生变化，影响项目的合规性和可行性。

风险影响：政策法规变化可能导致项目付诸徒劳，无法达到预期目标。

风险概率：中风险名称：外部环境变化风险描述：项目所处的外部环境可能发生变化，如经济形势、自然灾害等，对项目进展造成不利影响。

风险影响：外部环境变化可能导致项目成本增加、时间延误和利润降低。

风险概率：高风险名称：沟通与协作不畅风险描述：团队成员之间的沟通和协作能力可能不足，影响项目的顺利进行和团队的凝聚力。

风险影响：沟通与协作不畅可能导致项目进展缓慢、冲突频发和工作质量下降。

风险概率：中风险名称：技术演进速度过快风险描述：项目所采用的技术可能存在技术演进速度过快的问题，导致项目投资的技术很快过时。

风险影响：技术演进速度过快可能导致项目投资的技术无法长期使用，增加项目成本和风险。

动态风险跟踪表

附录B 动态风险跟踪表
B.0.1 动态风险跟踪表
动态风险跟踪主要记录已识别的风险清单中各个风险事件变化情况、风险事件表征值的变化情况和过程中采取的风险预控措施及落实时间，由项目实施单位的技术人员填写，见表B.0.1。

主要要求如下：
1初始状态主要记录风险事件开始跟踪时的状态，包括风险等级、风险表征形式、风险表征值（如果可量化）等信息；
2当前状态主要记录风险事件跟踪过程中的阶段状态，包括风险等级、风险表征形式、风险表征值（如果可量化）等信息；
3风险事件描述主要记录风险事件的发展情况、等级变化情况等信息；
4风险预警信号描述主要记录风险是否达到了预警指标、预警等级等信息；
5风险控制措施主要是指针对风险的变化情况、风险等级变化情况和预警等级情况采取的针对性的技术和管理措施要求。

表B.0.1 动态风险跟踪表。

风险跟踪表样例

项目名称：
填写人：胡庆妙
1Issue 人力资源管理若公司更高优先级的项目启动，将可能抽
调人员进度延误
2Active 人力资源管理加贸平台已有一项功能“南头企业资信库”，但南头关的企业使用这块功能申报的数据并不是很规范。

而本次开发要规范这些数据，这就使得需要对原有的少部分不规范的数据进行整理和迁移，并且对已有
功能做适量修改。

但原有的这块功能的基
于一个复杂难懂的技术架构实现的，这使
得在其上进行修改很困难。

进度延误3Issue 生产安全由于11月份公司搬迁，搬迁的那个周六周
日的时间将不能为项目利用；并且可能搬迁后可能会出现2~3天无法共享源码。

进度延误
4Issue 实施与部署
由于部署上线后，众多企业将集中申报资料，而回贸平台公共端的服务器已经负荷较重，这样将可能影响到已有业务的运行.加贸平台公共端不能正常运行5Issue 合同签订与商业谈判由于部分加贸企业并没有安装Epass, 在海关强制要求其申报企业资料的情况下，这些企业将被迫安装Epass，而这样可能会
带来企业的不满。

影响公司的知名度6Issue 测试与验收客户签字有可能因各种原因推迟。

会使得项目组保留1
名开发人员而不能
释放，会增加少量
成本;项目风险跟踪表
ID 状态类别描述企业资信库项目可能造成的危害
说明：
Issue表示项目风险处于被识别状态，Close表示项目风险已经发生并被缓解已处于关闭状态。

缓解已处于关闭状态。

风险管理记录表

风险管理记录表1. 风险管理目的本文档旨在记录项目中的风险管理过程，确保项目能够及时识别、评估和处理风险，降低项目风险对项目目标的影响。

2. 风险管理流程2.1 风险识别在项目启动阶段，由项目团队成员共同参与风险识别工作坊，通过头脑风暴、专家访谈、历史数据分析等方法，识别可能存在的风险。

将风险以及其可能带来的影响和概率进行具体描述，并制定风险识别表。

2.2 风险评估针对已识别出的风险，进行风险评估。

评估包括对风险的概率、影响程度和优先级进行定量和定性的评估。

将评估结果记录在风险评估表中，并为每个风险制定对应的应对措施。

2.3 风险应对根据风险评估结果，在项目计划中明确风险应对措施，并为每个风险指定责任人和应对计划。

风险应对措施可能包括风险规避、风险转移、风险控制、风险接受等。

同时，监控风险的实施情况，及时调整应对策略和计划。

2.4 风险监控风险监控是项目风险管理的重要环节。

定期对风险进行监控和跟踪，确保项目团队及时了解风险的变化和演变趋势，及时采取相应的措施，避免风险发生和扩大。

3. 风险管理记录表样例4. 风险管理记录更新风险管理记录表将在每次风险管理工作中进行更新。

项目团队成员需要及时完成风险识别、评估、应对和监控工作，并将最新的风险信息记录在风险管理记录表中。

项目经理负责监督和协调整个风险管理过程，并确保风险管理记录的及时更新。

5. 风险管理报告根据风险管理记录表中的风险信息，项目经理将定期编制风险管理报告，向相关利益相关方汇报项目的风险情况和风险管理进展。

风险管理报告可以包括风险趋势分析、风险热点分析、风险应对效果评估等内容，以帮助相关利益相关方了解项目的风险状况，做出相应的决策和调整。

结论风险管理记录表是项目管理中重要的工具，通过规范的风险管理流程和有效的风险管理记录，可以帮助项目团队及时发现和处理风险，降低项目风险对项目目标的影响。

项目团队应按照风险管理流程执行风险管理工作，并确保风险管理记录表的及时更新和使用。

风险与管理计划及跟踪表

风险与管理计划及跟踪表项目风险分类1. 需求需求没有文档化[1] 是否仅有未成文的需求？如果项目的需求只是通过口头表达，则需要考虑风险。

需求不稳定[2] 需求是否正在变化或是已经确定下来了？如果需求正在被增加、变更或是没有被确定下来，则需要考虑风险。

需求不完全[3] 需求中所有项目是否都有详细说明？如果需求中有未列出详细说明的项目，则需要考虑风险。

需求可读性差[4] 需求文档的可读性如何？如果需求文档的可读性差，则需要考虑风险。

需求不清晰[5] 你是否可以理解需求，如同作者想要表达的？如果关键的需求是模糊的、不明确的，则需要考虑风险。

需求进度紧张[6] 进度中是否安排了足够的需求分析时间？如果需求分析阶段的进度紧张，则需要考虑风险。

需求分析能力有限[7] 需求分析人员的能力是否有限？如果需求分析人员的能力有限，则需要考虑风险。

需求无经验可借鉴[8] 项目需求的关键部分是否有以往的经验可以借鉴？如果需求的关键部分无法借鉴以往项目的经验，则需要考虑风险。

需求不可行[9] 是否存在在实现时有技术困难的需求？如果不能确定某一项需求在所用的开发语言环境中实现的方法，则需要考虑风险。

需求不可跟踪[10] 是否有计划在设计、编码和测试阶段对需求进行跟踪？如果需求与开发过程出现偏差，或是在各个阶段没有被把握住，则需要考虑风险2. 设计设计的算法有问题[11] 是否存在没有满足需求或是仅仅部分满足需求的算法？如果算法有可能是错误的、不完整的，或是太复杂，则需要考虑风险。

设计难度大[12] 是否存在难于设计的需求或是功能？在某些时候，如一个复杂的树的查询可能需要很多的精力来设计，则需要考虑风险。

设计难度偏大过偏小[13] 设计中的任何一部分是否是基于不切实际的或是乐观的假设？如果对需求的设计太乐观或者太悲观，则需要考虑风险。

设计的接口定义不完全[14] 是否内外部接口都已经很好的定义了？如果在系统内部或是系统间存在复杂的、大量的联系，则需要考虑风险设计不易测试[15] 软件是否易于测试？如果在测试产品时有很大的复杂性，则需要考虑风险。