之前嘉宾抵到危机管理和BCM和应急管理，包括风险管理，他们之间的关系到底怎么样？原本我打算只介绍一下现在的事故管理和业务管理的关系，我想就之前演讲的几位嘉宾讲的情况，我想谈一下我的理解。
首先，风险管理，风险管理我个人认为强调的是怎么避免灾难的发生，强调的是事前的监控，一个报告。业务持续性管理，他关注的是事情发生之后和发生的时候，发生时你怎么应对，发生之后怎么恢复你的业务。
事故管理，他关注的是一些预期的事件，就是发生问题的时候我们要事先准备好我们应该怎么处理。
还有像危机管理，危机管理在银行业还是属于业务持续性管理的框架之内，通常在银行里面谈到危机，是指整个银行的层面上，我们管理层发生问题之后，我们的危机管理团队，他们怎么样根据危机进行一些，针对这些紧急情况的决定，银行层面的决定，以及我们对应这些业务部门和支持部门，他们怎么来针对这些情况进行自己部门的智能的部署。
在这个图里面表述出来，大家可以看到我们预期的事件，其实发生频率比较高，但是他的影响比较小。其实针对这种事件，我们银行内部的事故管理的框架已经可以覆盖了，我举一个例子，比如像银行某一个IT系统出现一个小问题，负责这个系统的IT人员，可以根据自己制定的故障处理办法可以很快解决，不需要激活危机管理的团队，也不需要激活部门的必需品。
但是还会有一些问题，他发生的频率可能不会很高，但是他的影响、严重性很高，这种风险我们一般在风险管理的概念中我们把它称之为尾部风险，针对这种风险，使我们业务持续性管理比较关注的事件。
同时，针对我们外资银行来说，因为我们一般来说母航在国外，我们集团总公司是在国外，所以根据事件影响性的由小到大，通常我们首先是要激活本土的危机管理的团队和危机管理的框架，当你事情的严重性已经逐渐扩大的时候，我们逐渐恢激活区域的危机管理以及全球的危机感觉。
我给大家简单介绍一下BCM的流程是怎么走的，这和之前25999的标准制定也是很相似的，首先要进行风险评估和分析，这一块要针对目前社会上、世界上，以及行业之内有哪些风险可能会针对我们公司造成影响，针对这些风险进行评估和分析。然后识别出来针对我们公司风险最高的事件。
然后我们会结合这些风险比较高的事件，联系每一个部门，来进行每一个部门和职能的业务冲击分析，业务冲击分析，大家可能也比较熟悉这个概念，我们在这个环节主要希望得到一个结果是，我们公司哪些部门，哪些职能是最重要的，他们对RTO的要求怎么样，还有内部不同部门，不同职能之间有什么依存关系。
在业务冲击分析之后，我们会帮助每个部门和职能制定自己的恢复策略，这个所谓的恢复策略一般指通过哪些方式恢复自己的职能，比如说我们有一个专门的后备场所，在北京的郊区，或者是说我们在北京和天津两个营业部可以互相备份，或者某些员工可以在家办公。如果可能把在北京的一部分职能和员工把他派到其他的地方，当然这也取决于监管机构的要求。
有了恢复策略之后，会要求每个部门和职能制定自己的BCP，也就是预案。
在有预案之后，我们会对员工和一些关键的，像危机管理团队的成员做一些培训，像刚刚日本专家介绍的，我们分几种，首先是培训，我们结合新员工培训，每年做一次针对所有员工的培训，只是介绍BCM的简单框架和简单的概念。
因为坦率来说，我们不期望也不要求，每一个员工，他们非常清楚BCM的框架是怎么样的，我们也不要求自己部门BCM管理的环节。但是我们是要求某一些关键员工，一些危机管理团队要特别清楚，所以我们在培训基础上还会专门针对BCP、BIA，各种演练给他们进行一些相关的培训，主要培训有两种。
在培训之后我们每年会进行很多测试，测试类型大家可能通常比较熟悉的是像办公场所的灾备切换测试，还有IT数据中心的测试，BCM还有很多其他的测试，包括联络数的测试，测试内容是说，我们发生紧急情况之后，从我们银行的管理层，一层一层往下到所有员工，怎么样通知到每一个员工，不管通过员工手动打电话的方式或者是短信的方式，还是通过IT系统，由他通过电信运营商群发电话或短消息的方式，目的是确保员工的联络方式是正确的，确保每个人知道在发生危机的时候他们应该通知谁，他们应该被谁通知。
除了测试之外还有危机管理的模拟测试，就是桌面演练，主要内容是说目前模拟的紧急情况，让我们银行的危机管理团队，管理层，他们集中在一个会议室里面，大家集中讨论，针对这个紧急情况，我们银行应该做出哪些重要的决策，每个部门应该进行哪些工作。
还有其他的演练方式，但是有哪些需要经常做，哪些结合部门做，完全取决于自己银行的实际情况。
测试之后，一年至少走完一次，现在工作银行比较高，一年有两次，走完一次以后第二年会走一遍，换句话说BCM不是一个项目，需要不停的循环和改善的工作。
在整个培训过程当中，发现每个部门的业绩预案，BCM有什么信息不完善，不完整需要及时更新，同时要安装在各个环节里面去。
还是结合刚才的话题，就是风险管理和BCM的证券关系，我特别想跟大家单独谈一下BCM和ORM的关系，我们有市场风险、操作性风险，关系最大就是操作性风险，就是ORM。针对ORM和BCM的关系，我的理解是这样，首先操作风险部门会进行一个风险识别的工作，在这个环节里面他们会进行一些风险评估，但是他们风险评估不光针对BCM所针对这些外部事件，他可能还要针对银行一些自身业务的发展，整个金融市场的变化等等做一些风险评估。
同时在这个环节他们还会做风险影响的级别的划分，一个量化识别。
在第二个环节，我们有一个评估与监控，这个也是操作风险部门负责的，这个环节里面，他们主要目的是希望对风险进行监控。
监控就是两方面，操作风险部门会结合每个部门定期做一个风险自评，风险自评的内容是结合自己的实际情况，对自己部门可能有的风险进行评估。
第二，操作风险部门有一个关键风险指标，在这个指标模板之内有规定，哪些事件数量关键风险，通常这些风险是对我们银行，对我们部门影响比较大的风险，我们每个部门都需要定期向操作风险部门来报告，这个部门自己发生的实际情况。
举一个例子，比如银行有后台的操作部门，操作部门可能有某一个员工，某一天在自己的系统里面输入转帐的金额的时候，可能都打了一个0，这个时候在操作风险部门来看，这可能就是属于一个关键风险，在当月部门上报关键风险指标的时候，就需要把这个事件录入到报告里面去。
操作风险部门还需要针对每个部门上报上来的情况进行一个风险事件的报告，从而告诉管理层，现在哪些风险可能是对银行造成影响比较大的。
某种意义来说，如果操作风险可以做的很好，需要激活BCP，这种待遇就会大大降低。如果操作风险做得不好，或者是说操作风险有一些覆盖不到的低概率事件，这个时候就要启动BCM的管理框架，作用主要是风险的缓释。
首先在BCM框架下面有危机管理，刚才我已经跟大家解释过了，其次有传统意义的BCM，最后我们还有BCM框架下的IT的灾备，在BCM框架下，在银行里面的IT灾备还是很重要的一部分。
最后，在风险管理和业务持续性管理的基础上，我们每个银行，相信每家公司也是这样，还会额外购买保险，保险目的是转移风险，也就是说有些东西我们可以选择怎么恢复职能，但是在恢复过程中可能涉及到财政上的损失，这个时候我们就需要由保险公司帮我们承担这部分风险。
这里面保险公司一般会结合银行的实际情况，让我们确定到底买哪些品种的保险，这个也是要结合我们之前的一个风险分析进行保险的购买。如果之前风险分析的结果下来，感觉是银行受到某一种影响的可能性很小，这个时候保险在这一块购买的金额就会很少。
BCM实施挑战。很多BCM跟我谈BCM，都有一个共同的困难，得不到高层的支持，这是其他行业常见的问题，BCM如果在企业内推动，如果没有高层的支持肯定做不到。
我们需要制定BCM的框架，提高通用方法，这个就是要求每个公司需要有专门的BCM的政策，有指引，要有管理的文，要告诉我们有哪些事情比较做，同时我们要有一个指引，告诉我们怎么具体实践。
我们还需要澄清，在我们银行内部，每一个危机管理团队人员，或者每一个员工，他们在BCM框架中他们的角色和职责，我们通常碰到一个问题，当我们和一些部门主管，尤其是业务部门的主管谈论BCM的时候，他们经常会说我不知道BCM是什么，我不知道我们部门的BCP是怎么样的，所以需要经常向他们灌输BCM的体系，和BCP的概念。
要把握业务的变化，比如银行要有一些新的部门，新的职能，或者新的产品，这个时候必须在他们上线之前要对他们进行BCM这一套东西，这也是银监会的要求，但是实际上没有几家银行真正做这件事情。
监管的支持，这是因为我们之前在国内，我们监管机构对BCM的重视程度不是很高，但是很欣喜的看到，最近在监管要求和标准指引方面有一个很大的提升，25999马上变成ISO的标准，我们国家标准委员会也在专门制定BCM的国标，银监会也会发布BCM的指引。
我们要针对过去的事件进行一个记录，进行一个报告，这个就是说，如果我们银行发生一些问题的时候，我们必须把它记录下来，做汇总和统计，这个结果会直接反映到风险分析或者是业务冲击分析，或者是BCP里面去。
第二部分，成本风险的均衡。首先我们要理解一个银行内部不同业务部门之间，不同职能之间，他们的重要性的关系。根据我们BCM实际使用的资源情况，我们来确定针对哪些重要的职能，重要的部门，重要的系统进行BCM的管理。
我们要知道恢复劣势，任何一种恢复策略，恢复解决方案都不可能覆盖所有的解决情况，势必有它的缺点、缺陷，我们要知道在发生什么问题的时候，我们恢复策略也是有问题的，也是有不足的。
第三，我们要确定适宜的解决方案，刚才提到每个部门，每个职能有好几种解决方案可以选择，到底选择哪一种，可以结合业务的程度，结合成本分析做出最后的决定。
最后要测量风险管理和投资的回报率，这是行业当中比较让人头痛的问题，某一个老总会告诉你说，我为什么做BCM，我每年投入几百万，但是没有任何回报，但是要解释BCM的价值在什么地方，如果没有BCM会怎么样。
有些信息要透明化，测试结果要透明化，IT做数据中心灾备切换的时候，最后给你一个很简单的报告，我们今年做过了，测试结果是正常，系统都是没有问题的，但是中间到底有没有，这是很多业务部门，很多管理层看不到的，怎么能够让他们知道这个结果，同时他们又不需要有很专业的技术背景，这也是我们考虑的问题。
我们限制恢复方案成本，我们根据现有的恢复方案知道怎么样能够更完善它，减少恢复方案，到时候如果不能发挥作用的可能性。
还有一点，就是监管指标的差异化，现在我工作的银行需要接受多个监管机构的要求，证监会，银监会，包括国外的要求，所以监管机构之间要求都是有一些不同的，怎么样能够同时满足他们的要求，又减少我们花费的资源，也是要考虑的问题。
最后BCM比较大的挑战就是依赖性，首先要帮助业务部门和IT部门绘制流程图，我们从前台、中台、后台，不同系统当中有接口，从前台一直到最后这个单完成，这个东西经常是业务部门和IT五部门没有办法提供的东西，但是真的发生问题的时候，我们经常发现没有这个东西可能真的发生问题的时候就慌了，不知道会发生什么问题。
比较实际的例子，就是日本大地震的时候，某一家银行，他们发生问题的时候IT根本没有办法告诉管理层，哪些系统可以用，哪些系统不可以用，就是因为之前没有做过这样一个整体的分析，他们都只知道我的某一个系统我应该怎么恢复，某一个系统如果不可用应该怎么办，但是他们没有一个全景的图在脑子里面。
同时，我们BCM的附加价值，就是能够帮助银行简化运营流程，通过我们之前的不同部门智能之间的流程图的分析，以及我们之前做的BIA，我们可以帮助银行简化我们现有的运营流程，这是可以向管理层解释的BCM的价值所在。
我们要通过提高测试的复杂性，更好的理解依赖关系，这一点是中国BCM的实践做得不太足的地方。通常大家提到IT中心，比如我们今年约好一个时间，9月30号，可能已经花了一个月，两个月的时间准备测试，测试当天可能早晨8点钟开始切换，所有都正常，再切换回去，这样是不是有意义，只能说某些场景有意义，真的发生实际情况的时候要其他问题，IT中心切换不是由一个人说了算，要由银行感觉层做决定，他们说你可以切换你才可以切换，银行管理层是不是在第一时间告诉银行你可以切换，肯定不是这样，因为他们势必根据银行的情况，根据你切换的风险来进行一个讨论，进行一个分析，最后做出最后的决定。
还有一个情况，是不是信息系统发生问题，我们马上可以切换呢？从实际情况来看也不是这样，在发生问题的时候，我们通常等一段时间，看这个问题是不是在一段时间之内解决，还有就是说切换是不是要切换整个数据中心，如果是切换数据中心一部分系统的话，你切换这部分系统和没有切换那一部分系统，他们中间如果有接口，如果有上下游的关系，会不会产生一些问题，这是简单的整个数据中心切换过程当中体现不出来的。
我们不同管辖地的方式保持一致，这是外资银行独有的特点，在不同国家，在不同地区，我们要求BCM必须按照同一标准执行。
最后是本土地区和全球的业务，有些业务可能不是一个仅限于中国的业务，业务的前台可能在美国，中台可能在新加坡、香港，后台可能是在中国，后台进行清算交易的，可能要到上交所，或者是深交所，要考虑整个地区和全球业务区域性，要考虑到时差，考虑到支持系统，支持业务的人员有一些相互的依存关系，还有一些风险，通常只在中国做BCM是不知道美国那边怎么样，势必要通过之前分析了解这些信息。
以上就是我给大家介绍的BCM在银行业的实践。

责任编辑：Mary