如何建立IT内控风险预警体系

更重要的是，每个人都需要理解可能会影响IT企业全部业务的几乎所有的风险。 风险可以分为四类，需要不同的缓解工具： 商业运营风险。一个评估要判断解决还是忽略某个具有挑战的威胁的风险。分析挑战性的威胁可以帮助企业决定是否投入必要的资源来战胜威胁。 判断如何对来自非传统的资源的挑战性威胁做出合理反映是非常困难的。例如，许多高技术企业都认为微软只不过是一群哈佛的退学生而已。他们因为没有理解到这个风险而付出了沉痛的代价。 适当的缓解工具是一个可以评估所有相关风险的良好的商业情况。对于新的商业机会来说，一个彻底的风险评估对于成功来说，就像是精确投入资金一样重要。 计划风险。对于通过的或者现有的计划来说，管理的关键集中在计划或者项目是否会在预算之内，高质量的按时交货。风险可以通过有效的项目管理和定期监控来降低。 业务中断风险。这种类型的风险影响了公司在困难的环境下继续运营的能力。场景从崩溃的服务器到被毁灭的建筑物，范围极其广泛。在大多数情况中，一个崩溃的服务器对于某些人来说只引起了微小的问题。相反，一个被毁灭的建筑物可能让所有的企业运行都停顿下来了。 风险可以通过持续的运行（COOP）计划来降低，这个计划描述了业务如何在各种困难中继续运转。大多数企业在开始的时候都会为数据中心准备了IT灾难恢复计划（DRP）。最终，DRP需要被扩宽，以便将重点集中在重新存储业务处理和发展为一个成熟的COOP计划上。 市场风险。这种类型的风险可以划分为地域和特定行业的风险。地域风险包括战争，恐怖行动和瘟疫，还有国家和进口限制。这些风险根据不同的国家、社会供应链的复杂度，以及该行业对于政治***的重要意义而有所区别。特定行业的风险也是多种多样。例如，金融服务必须通过信用挤压，债务抵押义务的彻底崩溃，以及结构化投资手段来进行竞争。消费产品制造商可能会因为“flash mobs”通过社会网络倾销他们的产品而感到苦恼。 场景计划可以通过制定应对各种不可能的事件的反应来降低风险。最重要的是，它尝试发现先前未知的风险，因为最危险的风险通常是你没有识别的风险。 采购行为——特别是离岸——增加了各个种类的风险。对这些风险的评估必须要解决类似通讯、逻辑困难、供应商变化，以及知识产权等特殊的关键点。 在着手开始任何风险评估之前，弄清楚哪个类型的风险对于你的执行管理来说最为紧要。然后选择合适的风险降低工具来解决潜在的困难。根据财务结果，风险的保单才会被批准。 彻底的风险评估可以为解决潜在威胁的结构化准备带来创造性的思维，这些创造性的思维对于成功至关重要。正如那句流传已久的格言所说，“预先警告就是预先武装。

尽管如此，还是有必要对这些风险进行梳理。不过，在开始对风险评估之前，IT部门首先需要了解为什么会提出这样的问题以及有哪些风险需要进行评估。其中尤为重要的是，每一个人都要明白，IT面临的风险最终都会波及到企业的正常经营。

一般而言，这些风险可以分为以下四种，它们都有对应的风险控制工具:

1 业务运营风险。对此类风险的评估涉及到企业面临着何种竞争威胁，而对竞争威胁的分析有助于企业决定投入多少必要的资源来应对这种竞争威胁。

在面临那些非传统的竞争威胁时，选择合适的应对策略有时是非常困难的。比如，很多高科技企业在最初面对微软时就根本没有把它放在眼里，认为它不过是一个从哈佛退学的学生组成的一个小公司而言。最后这些企业为此付出了代价。

对于业务经营风险而言，应对策略就是参考那些好的对各种相关风险进行评估的企业案例。面对一个崭新的市场机会，进行一次全面的风险评估对保证经营的成功就像准确的财务分析报告一样重要。

2 项目风险。对于经过批准的或者是已经在开发中的项目，其管理重点通常落在项目是否能在预算内、按期、高质量地交付。其对应的风险控制方法是利用有效的项目管理和进行常规的监控。

3 业务中断风险。这类风险指的是企业在困难环境中是否能继续保持业务运转，比如，服务器突然宕机或者大厦被毁坏时。在大多数情况下，服务器崩溃只会影响少数几个人，而建筑物被毁坏可能会导致公司经营活动全部终止。

4 市场风险。这类风险又可以分为地缘政治风险和特殊行业风险。地缘政治风险包括战争、恐怖袭击、瘟疫以及进出口限制等，此类风险的大小取决于具体的国家、企业供应链的复杂程度以及所处的行业与政治之间的关系等。特殊行业风险指的是国家对某些行业的特殊限制政策等，例如从事金融服务业必须考虑国家的银根紧缩政策、债务抵押业务的彻底崩溃以及类似目前袭击全球的次贷风波等; 从事日常消费品生产的制造商必须小心快闪族通过社交网络唾弃它们的产品。

这类风险的控制主要依赖于快速对各种不确定的事件制定出相应的对策。其中最为重要的是，要努力去发现各种可能的风险，因为最大的风险恰恰是我们不知道有何种风险。

外包特别是离岸外包会增加上述各种风险的危险性。对外包的风险进行评估时必须特别关注通信、物流供应以及供应商的变化和知识产权等问题。

另外，在进行任何风险评估之前，还必须了解公司的管理团队面临的困难，然后再选择合适的办法来应对潜在的因难。如果经济状况允许，也可以考虑对风险进行投保。

(1)

确定

IT

内控风险预警范围

(2)

对选定范围进行风险识别和评估

(3)

对潜在

IT

风险实时监控，并实施有效的控制措施

(3)

对潜在

IT

风险实时监控，并实施有效的控制措施

建立起全面

IT

风险预警机制的核心一步，是根据风险识别、评估的结果，针对相关

IT

风险源制定统一的风险管理战略，加强实时监控。例如，对

IT

风险预警系统的有效运行进

行持续监控与个别评估，充分发挥对潜在

IT

风险的实时监控作用，实现对潜在风险的实时

监控与内部控制措施的有效结合，以改善

IT

风险控制与管理的效果。

5)

培训宣贯与运行推广实施

IT项目管理的风险有哪些

项目风险是一种不确定事件或状况，一旦发生，会对至少一个项目目标，如进度、成本、范围或质量目标产生积极或消极影响。那么IT项目管理的风险有哪些呢？一起来了解下吧：

(1)技术风险。

核心系统升级引入了外包厂商的最新产品，使用了很多新技术，行内研发人员熟悉这些技术需要一定的时间，而在项目过程中却不可避免地会遇到一些技术问题。如何能快速解决这些棘手的技术问题我们的做法是：第一，指定行内外包厂商接头人，由接头人负责和外包厂商的技术人员进行沟通，同时该接头人也是行内对厂商产品最熟悉的人，一般性的小问题基本上此人就可以解决，比较复杂的问题才提交给厂商解决，这样比起全部问题都去找厂商解决，节省了时间。第二，购买厂商的人力进行技术支持，请厂商的研发人员来到开发现场和我们一块研发。第三，预约厂商在系统上线期间到现场待命，以应对紧急问题发生，对可能出现的问题进行第一时间的响应。

(2)沟通风险。

参与项目的外包厂商有多个，沟通渠道多，沟通成本大，而且容易出现理解不一致的情况。所以，项目组成立了专门的PMO，负责制定相应的沟通计划，为每个厂商指定行内的接头人，对内部人员实行分级管理，组织定期例会解决项目过程中出现的问题，防范由于对需求理解不一致造成的项目延误，充分利用已有的邮件、会议、电话和短信等沟通工具，并推广使用某即时通讯工具以作为主要的工作沟通工具。

(3)需求变更风险。

针对IT软件项目中不可避免的需求变更活动，在项目开始后，我部就停止了除政策性需求以外的所有规模超过20人/天的新业务需求，同时制定了需求变更流程：所有业务需求的变更必须由业务方的代表统一提出，变更必须有书面记录，开发人员仔细评估是否接受，最后由总管变更的领导(CCB)复审，总管领导具有一票否决权，从而精简了一些不合理的需求变更。在项目中期引入了IBM的配置管理工具CCCQ来管理代码和缺陷，所有Bug都进行了分类，并录入CQ系统，防止重复修改和修改后无记录等情况的发生。迁移演练之后的缺陷都由各个系统的负责人统一对缺陷进行分析评审，消除Bug修复可能导致的系统关联问题。

(4)进度风险。

项目进行核心升级，引起了客户面数据结构和一些外部接口的变化，同时前端业务平台也做了很大的调整，如开发了新的权限系统、迁移主机老权限系统上的权限数据到微机、替换传输协议XML为JSON、改造微机调用主机框架等。主机平台和开放平台开发工作量巨大，需要留有足够的ST、UAT测试时间，项目开发时间有限，为了应对可能造成的进度延误，我们采用了以下应对方法：一是制定详细的进度计划，明确每个人的任务，各项目组每周定期检视项目进度，如出现偏差及时纠正;二是与外包公司合作，引入外包人力，为项目临时增派了多名生力军;三是强制加班;四是并行化详细设计和编码同时加强代码评审，在加快进度的同时减少返工。

(5)数据迁移风险。

项目涉及的系统多达上百个，系统集成环境复杂，需要迁移的数据量庞大，而且数据迁移对数据的准确性和完整性有着很高的要求。项目制定了分阶段集成和多次迁移演练的策略：将迁移工作进行提前预演，模拟真实上线迁移场景。经过多次演练以后，问题大大减少，减轻了系统上线的数据迁移风险。

(6)人力资源风险。

项目建设周期长，历时两年，大范围人员流动可能会造成项目延误。针对这一风险，应对的方法是：做两手准备，尽力挽留要走的人员，晓之以理，动之以情，请求公司人力资源部提升员工待遇;同时加紧社会招聘，在重要的岗位上安排备份，防止由于成员生病、离职等意外造成的减员。最终这个风险没有成为问题。

在项目升级项目中，我负责两个子系统的开放部分，由于高层对风险管理的重视，我在执行的时候也特别重视对风险的控制。项目组有四个人，沟通成本比较低，所以我们每隔一周进行一次代码评审，解决遇到的一些技术难题和编码规范问题，在实际开发中使用Checkstyle进行代码规范检视，及早扼杀了可能出现的Bug和不规范的代码;制定组员每周报告进度制度，防范进度偏差;面对前端最可能出现的需求变更——UI变更，我尝试在设计初期使用原型方法和业务进行有效沟通，大大减少了后期UAT阶段UI变更需求。回想刚进公司时我做过的某个项目，由于没有考虑到UI类需求变更风险，前期没有进行UI设计的交流，导致UAT阶段大量返工，使项目延误了一个多月，并且浪费了不少人力资源。设想如果当时识别了这类风险，在早期就把风险发生的概率降低，那么项目可能会顺利得多。

由于前期风险控制得当，一直到迁移演练前我负责的项目都很顺利，但是在迁移演练过程中出现了一些问题，其中一个问题是导库程序不能正常执行，并多次发生。我和同事花了很多时间研究问题，最后找到的原因是某个配置参数的问题，研发人员使用了错误的配置参数，ST、UAT期间导库的数据量比真实演练期间的数据量小太多，所以没有被发现，修改配置后再演练环境导库成功。还有一些问题是没有有效沟通导致的。例如，在演练的时候用户反映某个查询交易很慢，经排查，后台人员说前台调错了交易，前台人员提出异议：为什么ST环境查询很快原来后台人员写了多个查询交易，新交易确实能提升查询速度，但是没有在正式的文档上注明前台应使用新交易替换老交易，也没有通过别的途径告知前台，这样前台调用的还是老交易，导致了查询性能问题。由于ST、UAT环境和生产环境的差异性，上述两类问题很难暴露，试想如果没有进行迁移演练，这个问题恐怕要在生产上出现了。迁移演练提前暴露了ST、UAT所不能测出的系统缺陷，使得研发人员能有充分的时间去排查问题和修复缺陷，有效降低了系统上线风险。

经过这次核心升级项目的洗礼，我深深认识到风险管理在IT项目中的重要性，正因为对风险管理足够重视，提前制定了风险应对计划，我们才得以如庖丁解牛般化解项目中遇到的各种风险，并最终取得了上线的胜利。任何项目都不能回避风险问题，风险的存在导致几乎每个项目都不可能顺风顺水地完成项目目标，良好的风险管理技能将帮助项目经理处理好项目中的不确定因素，保证项目的顺利进行。

;

以上就是关于当今企业面临的IT风险是什么全部的内容，包括:当今企业面临的IT风险是什么、CIO经常关注企业IT系统面临哪些风险、如何建立IT内控风险预警体系等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！