1. 前言
上一篇文章发出去之后，有位前辈帮我指出了一个比较大的问题：“计算机化系统”。在此先给大家道个歉，由于自己疏忽没有用正确的文字去描述，在此更正。
开始前，我本来想自己解释下关于“计算机系统”与“计算机化系统”的概念或者区别，后来百度之后发现另一个前辈解释的更好，在此我就引用这位前辈的解释了（如果涉及到相关版权问题，我将尽快删除这段解释）。
PIC/S中关于“计算机系统”的定义是：软件与硬件的组合，实现特定的功能。
“A group of hardware components and associated software, designed and assembled to perform a specific function or group of functions.”
PIC/S中有另外的对于“计算机化系统”的定义是：通过计算机系统实现、与计算机系统集成的一系列的流程或者操作。“计算机化系统”的关键词在于前半句“Process or operation”。
“A process or operation integrated with a computer system.”
谈到“计算机化系统”，实际包括的不仅是物理存在的系统本身，也包括与系统所支持的流程与操作。现在很多的企业在做“计算机化系统”验证的时候，更多侧重的往往是项目阶段的系统实施，侧重的是对“计算机系统”本身的功能需求与功能测试，当然这不能说做得不对，但确实是做得不够。
以笔者的感觉而言，很少有企业能够理解计算机系统运行、维护阶段的要求也是验证的一部分；很少有企业能够清楚讲清楚系统究竟如何支持业务流程，产生哪些数据，这些数据应该如何保留，如何销毁；很少有企业能够真正管理好计算机化系统，保持其验证状态......运维阶段对于“计算机化系统”而言其实往往比项目阶段的系统实施更为重要。
之前写了一篇关于计算机化系统（更正后）验证的概述的文章，写的确实很粗，当时因为篇幅有限，无法完成整个计算机化系统验证的相关知识点的总结。接下来我会用N个“文章”来具体说明，还是之前那句话，希望对新人有所帮助。
本篇我主要是想阐明关于风险评估的一些关键知识点，当然这些也都是自己通过各种渠道掌握或总结而来，如果有不对的地方还请大家指正。
同样的，还是围绕“为什么做，怎么做，谁去做，什么时候做”来一一阐述，希望大家在读这篇文章的时候仍然按照这个逻辑去读。
2. 风险评估概述
关键字：风险评估 概述
风险评估是在GAMP5中被加入进来的，而且是验证全过程进行风险评估及基于风险评估进行决策，其目的和原因当然就很简单了，如果拿项目来说，是为了降低交付的产品、服务或成果的产生的风险。在计算机化系统验证过程中，按照验证的V模型划分为规划、规范、配置/开发、确认、报告等5个阶段，在每一个阶段都应进行相应的风险评估。而如果按照风险过程划分的话，可划分为初步风险评估及决策、进一步风险评估及决策。
至于是否要做风险评估，大家认可的可能都是由质量部来决定。而这个由质量管理部“决定”的依据是什么？是否有完整的方法？这本身就是一个风险。那要降低这个“决定”的风险，首先我们要做的就是风险评估SOP，明确什么情况下要进行风险评估（相关的SOP我会在后续整理出来）。在此基于我的理解，我举几个例子说明下什么情况下（不限于以下情况）应该进行风险评估。
1） 安装新的与产品质量相关（除无影响而外，如安装个打印机）的系统或设备；
2） 现有系统或设备发生了变化，如运行环境的改变；
3） 与现有系统或设备相关的人员组织结构发生变化，如原技术服务商撤销；
4） 发生偏差后，调查结果发现系统处于非受控状态，或者相关操作规程无法避免事件的再次发生。
5） ……
3. 风险评估
关键字：风险评估、方法
关于风险评估，网上的例子一大堆，之前在学习这部分的时候看的我很蒙圈，往往是看完之后不知所以然。在此我还是总结下自己的相关理解。
关于是否要进行风险评估，在概述中我已说明，在此不做重复。首先我们看下风险评估
图1 风险评估流程
如图示，成立风险评估小组，即“谁去做”。该小组作为执行人，必须经过相关的培训，熟悉相关流程以及具备相关的知识结构。而领取编号其目的是为了做到任一个风险评估的管理的追溯性。风险评估过程以及应对决策应有完整的方法论，包括风险的识别、风险的定量分析、风险的定性分析、风险的应对策略、未知风险的相关储备等。后续的风险报告的审核，主要是对风险的识别是否完整、风险的应对策略是否合理等进行审核，确保对已识别风险的高低进行最低化控制处理。同时对未知风险的相关储备的合理性进行审核确认，确保未知风险来临时有足够的储备进行风险处理。
3.1. 风险识别
对于风险的识别，想必很多人都跟我一样，懵！有时候识别出来的风险都不见得是有用的。后来我再次去看了下关于信息系统项目管理的相关书籍，回头再看也就不那么迷糊了。关键点就一句话：未来或变化或选择的人或事或物是否对我当前的人或事或物产生影响，包括积极的影响。说白了就是可能发生的事是否对我现在要做的事产生影响。风险识别过程应做好详细的记录，同时对风险进行分类，包括积极地、消极的、高风险、中风险、低风险等。
至于风险的识别方法，可采用的有很多，我最常用的就是图解法、假设法以及头脑风暴。原理也很简单。图解法就是将整个过程进行依次分解为最小工作单元，而后逐一列出每个工作单元相关的人、事、物，而后进行逐一判断。假设法就更简单了，就是如果怎么样就怎么样的逐一进行分析。头脑风暴，并非天马行空，而是以共同目标为中心，相关参与人员畅所欲言，参会人员在他人的看法上建立自己的意见。
以上三种方法并没有什么特定的使用环境，一般是想结合进行，从而确保对风险识别的完整。当然，对于识别出来的风险我们要逐一整理而后进行风险分析。
题外话：上初中的时候，我们数学老师跟我们说过，中小学生守则上写的都是不准怎么样，这样导致学生犯错误的几率太高了，因为不准的事永远考虑不周全，建议写成必须怎么样。尽管是个小插曲，但我想说的是，我们采用的假设法其实就是个不周全的方法，因为如果太多太多……当然这件事也影响了我后来在编程软件系统的时候的一些逻辑，少采用if…else…，尽量只写应该怎么做。
3.2. 风险分析
风险分析包括了定性分析和定量分析。定性分析其实就是对风险进行等级划分。对于已识别的风险，风险小组应为风险进行打分，至少为1分。
根据每个风险发生的概率，来确定风险的等级，并给出相应分数。其概率的估计可采用客观概率估计，即根据历史数据或大量的试验来推定其概率。也可采用主观概率估计，即根据个人经验、预感或直觉估算出概率。高概率（3分）、中概率（2分）、低概率（1分）
根据风险的可检出性来确定风险的优先级，并给出相应分数。可检出性可采用检出频次来进行划分，如凭运气检出 （3分）、可能检测到（2分）、一直检测到（1分）。
根据风险的严重性进行划分，并给出其相应的分数，如严重（3分）、较严重（2分）、一般（1分）。大多数制药企业采用的是那种死亡、重大伤害、轻度伤害……的严重程度进行划分。对于计算机化系统本身来说，其严重性划分如采用此类方式，并不能准确的覆盖。
我推荐使用如
1）严重：系统崩溃、数据丢失、数据毁坏
2）较严重：操作性错误、错误结果
3）一般：小问题，不影响使用。
将以上三种分数相乘，即可得出总体风险分数，风险总体分数（RPN）=严重性×发生可能性×可检出性，而后再根据这个总体风险分数将所有风险归类划分。
图2 风险等级与优先级矩阵
定量分析是在定性风险分析的基础上进行，定量分析并不是获得数字化的结果，而是得到更精确的风险情况。是对这些风险事件的影响进行分析，从而得出更准确的风险等级。其具体的方法有很多，我就在这里不啰嗦了。
总之，不管采用哪一种风险分析，其目的都是找到风险，从而确定风险的等级。为后续的风险应对决策做好准备。
4、风险 应对决策
关键字：风险应对、决策
风险的应对决策应根据风险情况制定具体的措施，其目的是降低/消除其风险。当然完全消除风险是基本不可能的。在此我就举几个系统功能上的风险应对措施
例一：身份证号文本输入框，人工输入时的风险根据其发生错误的概率、影响以及检测性可将此风险定位高风险。
应对措施：通过软件编码增加各种权限控制，，从而达到降低风险的措施。如身份证号码位长度判断、末尾字母判断等措施进行风险的降低。此时还并未消除风险。进一步降低则可使用与户籍系统对接，而后通过判定身份证号码的有效性来达到降低风险的目的。此时看来风险已经被消除了，然则，与户籍系统对接后的接口风险的存在，从而并未达到风险的消除的目的。所以如之前我说的，完全消除风险是几乎不可能的。
例二：计算机化系统数据备份风险，由于其备份方式的不同从而风险等级不同。
应对措施：为降低这类风险，我们可采用多次备份、异位（地）备份、、实时备份等不同的方式进行风险的降低。关于异位还是异地的解释，我在第一篇文章中有具体的解释，还是那句话，我认为做到异位的备份即可达到数据备份风险的接受。
5. 风险评估步骤
风险评估步骤这部分，可根据不同的计算机化系统进行具体的分步，一般采用的是初步风险评估，即该系统的整体化风险评估以及进行风险应对决策。其次进行规划阶段的风险评估及应对决策，再次进行的是功能性风险评估分析及应对决策。还有变更控制下的风险评估及应对决策。最后进行系统退役阶段进行相关的风险评估及应对决策。
在此我就简单说下初步风险评估的做法。
初步风险评估中的风险包括：
1） 计算机化系统的特定风险对质量体系的影响风险
2） 具体的业务流程采用计算机化系统后的影响风险
3） 计算机化系统的合规性风险
4） 企业相关人员整体素质风险
5） 项目实施对当前工作的影响风险
6） ……
针对以上风险，企业根据其自身情况给出其应对决策即可。
ouryao-com·因为有你
