业务持续性计划

业务持续性计划（精选5篇）

业务持续性计划 篇1

1 背景

日益激烈的市场竞争和不断提高的客户服务质量需求对业务支撑系统 (简称:BOSS系统) 业务支撑能力和可靠稳定运行的要求越来越高, 从面向客户服务的角度而言, 需要中国移动提供不间断的业务支撑服务, 以保证客户满意度、客户服务质量等不受影响, 增强企业竞争力。

2009年期间, 由于数据库故障、生产机房网络故障等原因, 造成广西BOSS系统当年累计退服时长达近20个小时、故障期间因无法缴费、充值后无法开机等问题造成的用户投诉/抱怨工单件数共5000多件, 严重影响了本地客户的满意度和使用感知。由于数据库故障和网络故障等突发性问题可控度不高, 因此如何降低故障处理期间对用户的影响、更进一步地考虑实现故障期间系统不中断运行, 成为广西公司业务发展和客户满意度提升工作面临的一项紧迫任务。

2 研究思路

根据广西公司运营支撑水平的实际情况, 采用关键业务应急的方案, 建设一个覆盖BOSS系统各主要业务受理渠道 (包括:营业前台、短信厅、网厅、客服系统、IVR充值等) 关键业务的应急系统。当BOSS系统出现重大故障的情况下, 应急系统对外提供各类关键业务的受理, 确保业务服务连续性, 满足客户最迫切的业务需求。

由于涉及较多渠道和系统, 切换环节众多, 手工切换时间较长, 而且存在人为误操作的风险, 为了达到快速切换和减少人为操作风险的目的, 应急系统提供应急切换统一操作管理平台, 提供自动快速的应用切换手段, 缩短服务重启等耗时长的操作时间。

用户在应急系统办理业务, 使用的是生产系统同步过来的数据, 并且在应急系统办理的业务数据, 在生产系统恢复正常后, 同步回生产系统, 保证用户在生产系统中正常的办理业务和使用服务。因此必须保证应急系统和生产系统之间的数据同步, 采取有效手段保障两个系统之间的数据一致性, 从而保证业务受理和数据的准确性。

3 建设方案

3.1 系统部署

广西生产中心和应急中心的双中心体系采用同城异址的建设方式、保证了硬件设备的独立性, 生产中心部署生产设备, 容灾中心部署应急设备, 保证灾害或故障发生时系统冗余可用。其中生产中心设在608第三机房、容灾中心设在608第二机房。

根据广西公司的实际情况, 当前广西公司应急系统硬件配置约为生产系统的1/2、业务承载能力约为生产系统的1/2, 性能足够支撑当前应急系统中提供的关键业务。

应急系统部署分为三层结构:

(1) 客户端:生产系统和应急系统的客户端的PC机是共享的。应急系统和生产系统之间的切换, 通过F5的请求指向修改来完成。在启动应急系统时, 营业员只需要通过统一的URL重新登录即可。

(2) 应用服务器:生产系统的WEB服务和中间件服务部署在生产中心主机上, 应急系统的WEB服务和中间件服务部署在容灾主机上。生产系统和应急系统的切换/回切通过F5实现。当BOSS系统出现故障时, 通过F5将前台业务请求接入到应急系统。生产系统恢复正常后, 通过F5进行回切, 将请求发送到生产系统。

(3) DB层:应急系统使用的是生产系统的克隆库, 克隆库与生产库是互相独立的。应急系统数据同步采用DSG方式从生产库中同步至应急库。

3.2 体系架构

广西生产系统及应急系统逻辑架构相同、部署的应用程序一致, 减少了程序部署和系统升级的复杂度、也保证了应急系统的可用性。应急系统采用B/S结构的处理方式。首先采用B/S结构的业务受理界面, 是BOSS系统设计的主流发展方向, 可以方便系统的升级, 利用前台用户的使用, 收敛后台的业务流程等优点;其次, 采用B/S结构, 使得生产系统与应急系统的受理界面互不影响, 便于快速实现系统的切换, 也避免了对现有前台营业受理界面修改对系统的影响。

BOSS应急系统架构可以分为三层结构, 分别为接入层、业务层、数据层。

(1) 接入层:跟用户接触的各个渠道的接入方式, 包括:营业厅WEB方式接入、网厅、IVR自动语音充值管理平台接入等。

(2) 业务逻辑层:进行各种业务操作和业务规则处理。采用组件技术实现, 将所有的业务逻辑都封装在组件中, 并利用组件提供业务服务。

(3) 数据层:主要功能是存储核心数据, 包括用户资料数据、卡资源数据、号码资源数据等。

3.3 系统功能

应急系统功能包括两大部分:应急系统管理和应急业务受理。

1) 应急系统管理:包括应急切换控制、应急系统初始化、应急业务数据恢复等功能。

(1) 应急切换控制:包括应急自动切换平台和应急切换后台控制。

i.应急自动切换平台:对整个应急切换操作进行了整合, 实现全自动化应急系统应用切换与回切, 有效避免了人为误操作的风险;并设计了申请、审批两级操作流程, 操作人员和管理人员能通过平台进行切换操作管理。切换的时候生成前台切换通知, 告知操作员启用应急系统, 并提示能办理哪些业务;当从应急系统回切到生产系统时, 告知系统已经恢复正常, 可正常办理业务。

ii.应急切换后台控制:控制营业前台、各渠道系统和接口连接到应急系统还是生产系统。后台自动切换功能采用切换消息发布服务器+切换消息接收代理进程模式实现, 有效降低自动切换平台的复杂度。将应用程序的实际切换操作封装成可执行脚本、仍放置在应用主机上, 相应地在应急主机部署了一套切换代理进程, 由代理进程解析切换请求、调用执行脚本完成实际切换操作。

(2) 应急系统初始化:应急系统使用的数据库是BC复制库, 每天凌晨会全量备份并覆盖应急系统数据库中的数据, 然后通过DSG增量同步定时同步生产系统和应急系统的数据, 由于应急系统与生产系统在业务控制的细节上的差异, 所以, 每次同步完成后应急数据库中的数据还不能直接用于应急系统, 要进行一些数据上的清理与准备工作。

(3) 应急业务数据恢复:针对在应急系统受理的业务, 在BOSS系统恢复正常后, 自动同步受理的业务数据到生产系统。

2) 应急业务受理:由于业务支撑系统中各个系统以及外围系统的关联性, 要实现对应急系统的业务受理和服务功能使用, 除了受理业务的各个渠道要进行业务受理功能改造外, 相关的后台 (如计费、开通) 和外围系统 (如充值卡平台) 也需要进行相关的改造。主要改造的系统和功能如下:

(1) 受理渠道改造

各受理渠道要实现对应急系统的改造, 一方面需要支持实时读取应急切换标记, 另一方面需要修改系统内部业务受理的实现模式, 将跨子系统或跨库等跳出自身系统范围内的功能调用都改造成不执行实际调用, 仅保存数据在应急数据库中, 待生产系统恢复正常之后进行数据恢复时再执行实际外部系统接口调用;同时, 还需要提供生产系统恢复正常之后的数据恢复方式, 并保证数据正确性与生产系统正常受理结果一致。下面列出具体改造点:

i.实时读取应急切换标记

通过应急控制平台界面进行切换时, 应急控制系统向受理渠道发送应急切换标记, 受理渠道要能及时获取, 并切换到应急状态;实现方式可以为socket或中间件接口, 由应急控制平台连接或调用。

ii.调用跨库跨系统接口逻辑修改

当应急标记切换之后, 受理渠道内部业务受理逻辑进行修改, 以适应应急系统的软、硬件环境。

iii.数据恢复的实现

受理渠道提供生产系统恢复正常之后, 应急期间办理的业务恢复手段, 同时提供稽核恢复数据正确性的手段。

在生产系统恢复正常后, 需要把应急系统受理的业务数据以业务办理当时场景的信息恢复到生产系统。应急系统的数据恢复, 是一个后台进程 (多线程) , 恢复进程启动后, 会按受理时间顺序检索应急工单主表所受理的业务记录, 并根据业务类型, 去相关的业务记录表中获取业务数据, 再分别调用生产系统中的对应的后台服务, 将应急业务的业务数据送给生产系统的后台受理服务接口中, 由生产系统的后台受理完成应急业务在生产系统中的再受理过程, 从而保证数据正确性与生产系统正常受理结果一致。通过生产环境执行业务受理过程, 对应的用户编号、工单编号等通过序列号产生器产生的编号存在不相同的情况, 相同的情况机率也非常小, 避免了将应急系统数据库相关序列号值同步到生产环境的问题。

为了缩短业务中断的时间, 应急系统回切回生产系统后, 应急系统办理业务的数据恢复回生产系统的同时, 生产系统对外提供业务办理, 应急业务数据恢复完成前, 在应急系统办理过业务的用户不能在生产系统办理业务, 以保证数据的一致性。

(2) 相关系统改造

i.充值卡平台

当应急系统启动时, 充值卡平台需要将原来BOSS生产系统提供的调用接口, 转发到BOSS应急系统提供的调用接口, 完成充值流程。

ii.统一开通平台

统一开通平台与应急系统走接口表的方式, 应急系统把需要开通的记录插入接口表中, 由统一开通平台负责后续的开通指令拼装和发送, 并回写开通结果到接口表, 不需要与应急系统程序进行交互, 直接由统一开通平台读取接口表数据。具体接口表的字段或格式与生产系统类似。

统一开通平台在完成开通操作之后, 根据HLR的结果, 将开通处理结果回写到接口表中, 应急系统调度进程定时读取接口表开通结果, 更新应急受理工单状态。

iii.计费平台

应急系统新装开户完成之后, 需要将新用户资料上发给计费平台, 计费平台与应急系统走接口表的方式实现数据交互, 应急系统在完成开户受理之后, 将新的用户资料插入到接口表中, 计费平台定时从接口表获取新的用户资料到应急MDB系统进行计费, 避免出现用户高额欠费等问题。另外, 其它如产品变更、计划变更等与计费相关的资料上发规则处理原则一致。

4 应用效果

应急系统建设完成后, 根据集团公司《业务支撑网应急保障管理办法》要求, 广西公司定期进行应急系统切换的应急演练。演练按照各个流程进行操作, 演练的结果达到了预期的目的:

(1) 应急系统和生产系统之间的切换/回切, 通过应急调度管理界面进行切换, 后台通过F5的请求指向修改来完成, 各个受理渠道的切换过程可以在10分钟之内完成, 较好的保证了BOSS重要业务受理的连续性。

(2) 在应急系统受理的缴费、停开机等涉及HLR开通的业务, 能实时发送到开通系统和HLR, 处理效率跟生产系统相比没有明显降低。

(3) 当生产系统恢复正常, 从应急系统切换回生产系统后, 把应急系统受理的业务数据以业务办理当时场景的信息恢复到生产系统。通过后台进程 (多线程) 进行生产系统数据恢复, 在恢复过程中, 在应急系统办理过业务的用户暂时限制在生产系统办理业务, 对其它用户则没有影响, 因此一旦应急系统回切到生产系统后, 即可正常为用户办理业务, 对业务连续性起到了较好的保障。

(4) 应急系统回切回生产系统后, 在生产系统恢复正常并且数据恢复完成后, 经过稽核, 生产系统和应急系统的数据一致, 确保了应急业务受理的数据一致性要求。

5 小结和展望

中国移动广西公司通过建设BOSS应急系统, 实现了当BOSS系统出现重大故障时, 能够快速切换到应急系统, 在各个渠道提供关键业务的受理, 提升了BOSS系统重要业务的服务连续性, 对提升客户服务满意度起到良好的效果。

下一步将考虑扩大应急系统业务受理的范围, 并且通过技术手段对应急调度自动切换的功能进行优化, 进一步缩短应急切换及回切环节的耗时, 同时考虑将应急后台自动切换的关键步骤及流程展现在应急自动切换平台界面上, 有助于操作及管理人员实时监控后台切换管理过程, 对切换过程中的异常情况及时发现处理。

参考文献

[1]中国移动通信有限公司《业务支撑网应急保障管理办法1.0.0》, 2010年11月

[2]中国移动通信有限公司《NGBOSS2-BOSS (V3.0) 业务规范》2010年6月

业务持续性计划 篇2

一、1 1.1 1.2 业务目标 经营目标

保证股份公司现时及未来生产经营的正常进行。按照公平公正的定价原则和交易方式实现关联交易，保证交易规范进行，不发生利润转移。

1.3 2 2.1 2.2 3 3.1 3.2 3.3 3.4 3.5 保证股份公司资产安全、完整。财务目标

保证对关联交易项目单独统计、核算。保证关联交易数据真实、准确、完整。合规目标

关联方确认清楚。

关联交易总额符合上市地豁免条件。关联交易符合批准程序。关联交易符合披露程序。

关联交易行为符合关联交易合同（协议）的约定。

①3.6 关联交易合同（协议）符合合同法等国家法律、法规和股份公司内部规章制度。

① 持续性（经常性）关联交易内容：按照股份公司与集团公司签订的总体《关联交易协议》及香港联交所给予的豁免限额内的，货品和辅助服务互供、文教卫生服务、租赁（土地、房屋、加油站）、知识产权许可使用、销售代理服务、油库加油站油品专营等。本流程所指关联交易对象为集团公司及其所属单位。

2008年 B 8.1－1

8.1持续性（经常性）关联交易业务流程

二、1 1.1 业务风险 经营风险

交易活动中断，使股份公司正常的生产经营受到影响。

1.2 1.3 定价不合理，客观上导致利润转移。

没有及时结账，导致资金被占用，影响股份公司生产经营。

1.4 未经审核，变更关联交易合同（协议）中涉及权利、义务条款导致的风险。财务风险

财务报表中关联交易的信息不准确，交易数据不真实、准确、完整，包括：

2.1 2.2 未单独统计、核算关联交易项目。

因关联方识别错误，导致少计或多计，引发统计核算出现偏差、财务核算失真、对外披露不准确。

2.3 提前入账或未及时入账，导致关联交易数据失真。3 3.1 合规风险

产权关系或投资关系界定不清，导致关联方识别错误。

3.2 客观上造成利润转移，构成对股东权益的损害，导2008年 B 8.1－2

8.1持续性（经常性）关联交易业务流程 致股东对股份公司及董事、监事、总裁、财务总监、董秘等高级管理人员的诉讼。

3.3 关联交易违规，造成审计师拒绝向董事会出具审计师证明书，监管机构取消关联交易豁免或会受到监管机构的惩戒，导致股份公司及高级管理人员形象受损。

3.4 关联交易合同（协议）不符合合同法等国家法律、法规和股份公司内部规章制度的要求，造成损失。

三、1 1.1 业务流程步骤与控制点 确认关联方的身份和行为

分(子)公司法律事务部门会同财务部门每半年根据并表范围和股权关系，编制并及时更新产（股）权结构图表，报法律事务部；董事会秘书局负责向公司的大股东（持有股份公司股权5%以上）定期索取其产（股）权结构图，交法律事务部。

1.2 法律事务部对产(股)权结构图审核后交财务部，由财务部会同法律事务部、董事会秘书局每半年对关联人士或联系人名单进行更新,并下发给各分(子)公司。

1.3 分(子)公司财务部门会同法律事务部门，根据财务部随时更新的关联人士或联系人名单，与交易对方确认2008年 B 8.1－3

8.1持续性（经常性）关联交易业务流程 交易性质是否为关联交易。2.1 确认关联交易计划

分(子)公司财务部门会同生产经营计划等部门，根据生产经营计划，每年一季度填报关联交易买入卖出表，由财务部门负责人审核后报财务部。

2.2 财务部汇总关联交易买入卖出表，会同生产经营管理部、董事会秘书局等部门审核，股份公司关联交易总额按规定权限报批后分别回执分(子)公司，作为签订关联交易合同或协议的依据。3.1 起草关联交易合同（协议）

双方关联交易主管部门根据股份公司的定价原则和价格管理权限确定具体价格，超出授权范围的定价，双方意见一致后报各自主管部门（上级财务部门）审批。双方关联交易主管部门须提出拟采用的定价原则及依据。

3.2 双方关联交易主管部门应按照经法律事务部审定的示范合同文本起草关联交易合同（协议）。4.1 审批、签订具体关联交易合同（协议）

依照股份公司合同授权管理权限，分别由分(子)公司、财务部、总裁、董事会和股东大会审批关联交易合同（协议）。由法定代表人或被授权人签订具2008年 B 8.1－4

8.1持续性（经常性）关联交易业务流程 体的关联交易合同（协议）。

4.2 关联交易合同（协议）必须每年在一季度内签订完毕后，上报集团公司财务计划部和股份公司财务部备案。5.1 执行关联交易合同（协议）

采购、生产、营销等业务部门经办人员确认结算项目和业务量，按相关业务流程规定的程序办理审核、审批手续后，有关结算凭据交财务部门。

5.2 财务部门经办人员根据双方签订的关联交易具体合同（协议），审核拟结算项目、金额、收、付款时间要求，经财务部门负责人审核无误后办理结算业务并进行账务处理。

关联交易项目须单独统计。

5.3 财务人员月末检查结算情况，并将未结算情况报告财务部门负责人和相关业务部门负责人，由关联交易双方制定处理办法。

5.4 由专门的财务人员建立关联交易档案和台账，对关联交易账目与关联方有关人员至少每季核对一次，按时正确填报关联交易会计报表。本分立单位间的关联交易会计报表需由关联交易双方的总会计师或分管副经理在季度、末签字确认。

2008年 B 8.1－5

8.1持续性（经常性）关联交易业务流程 5.5 财务部门负责人按照关联交易合同（协议）及有关规定，对关联交易项目及关联交易会计报表进行审核无误后及时上报财务部。

5.6 财务部至少每季对关联交易报表和价格执行情况进行审核、分析，纠正存在的问题或提出完善的意见和建议。6.1 披露关联交易信息

董事会秘书局、财务部、法律事务部确认关联交易是否已作披露以及是否在上市地披露豁免条件内。超出豁免条件或新发生的持续性（经常性）关联交易，依照本流程“步骤7申请批准和豁免”的规定办理。

6.2 董事会秘书局根据境内外监管规则的要求，依据审计结果按照规定的方法定期对外披露关联交易有关信息，参见《11.6信息披露业务流程》。

6.3 财务部按季将关联交易的数据提供给董事会秘书局，数据提供前须经财务部主任审核。董事会秘书局对外披露前须经法律事务部复核。7.1 申请批准和豁免

董事会秘书局根据境内外监管规则的要求，负责履行申请关联方交易豁免批准程序。

2008年 B 8.1－6

8.1持续性（经常性）关联交易业务流程 7.2 对新发生的持续性（经常性）关联交易，董事会秘书局应负责履行相应的批准程序。

7.3 财务部发现或预计持续性（经常性）关联交易已经或将超出现有豁免限额的，应立即书面通知法律事务部和董事会秘书局，董事会秘书局负责申请批准和披露工作。

四、相关制度目录（制度后标号为《内控手册配套规章制度汇编》目录索引号）上海证券交易所《股票上市规则》（2004年修订）

----9.21 2 香港联合交易所：《香港联合交易所有限公司证券上市规则》（2006年3月修订）----9.22 3 《上市公司信息披露管理办法》----9.33 4 《中国石油化工股份有限公司信息披露制度》

----1.1.1 5 关于印发《关联交易管理暂行办法》（中国石化

[2001]财工字9号）----2.6.2 6 关于印发《中国石油化工股份有限公司合同管理实施细则（试行）》的通知（石化股份法 [2003] 419号）----1.12.1

业务持续性计划 篇3

一、“六步法”预防措施

1、在组织人力资源部管理人员的帮助下，准确掌握员工健康状况。

2、不鼓励管理层采取极端措施，建议管理部门通过公告、宣传栏或广播等形式教育员工不要轻信“怀疑”事件或谣言。

3、提供进行体温检查的场所。

4、对受“非典”感染的区域进行隔离、封闭，以确保工作人员的健康。

5、确定以前在重要职位上工作过的员工，他们可以作为替补人员来替代被“非典”感染的相应重要部门人员，以保证在A组感染“非典”的时候，B组能替换。

6、对于“非典”，我们在“战略上要蔑视，在战术上要重视”。

二、以人为核心的提高组织免疫力“四步法”措施

1、发布旅行资讯信息，减少到被传染区域出差旅行。

2、经常保持个人卫生和环境卫生。

3、促使人力资源管理主管监控病人及观察其症状，确定被潜在影响的“高度威胁”的员工。

4、要有畅通的意外事件汇报渠道。

三、“三步法”控制措施

1、识别核心业务：识别核心业务可以采用“业务风险等级排列”方法，这种分析方法是依据灾难发生后，所需复原的时间及中断发生的可能性来进行业务风险等级排列。

2、进行业务影响分析：正确地进行BIA(Business Impact Analysis )，首先应该了解组织的整体情况、关键业务处理流程和组织处理关键业务使用的资源。执行BIA有许多方法。其中最流行的方法是问卷调查法，首先要设计一个详细的调查问卷，并分发给重要的业务人员和IT人员，然后对收集的信息进行归类、分析，如果发现有用的信息，BIA团队则与相关人员联系做进一步了解。另一种比较流行的方法是拜访关键用户，通过分析面谈收集来的信息，开发一个详细的BIA计划和策略。

3、制定业务持续计划。业务持续计划的制定应结合业务影响分析的结果，并围绕这些结果进行。针对每项核心业务流程，都应有相对应的单独应急变计划。业务持续计划应该保证：在事故发生后能够在需要的时间内执行计划，维护或恢复业务运作。因此，业务持续计划过程应该考虑下列情况：

* 了解组织所面临的风险及其影响，包括关键的业务的识别和优先化处理。

* 了解中断很有可能对关键业务的影响，找到威胁组织生存能力的关键事件的处理办法。

* 考虑购买可能影响业务持续性的关键部分的保险。

* 阐明和归档业务持续性策略并在业务目标和优先权上达成一致。

* 保证业务持续性管理被并入组织处理流程和结构中。

* 所有责任和紧急事件过程的识别。

* 在需要的时间范围内实施紧急恢复，应特别关注相关部门的配合情况。

* 培训员工在紧急情况下的恢复处理流程。

* 指定执行计划的各个组成部分的具体人员以及备用人选。

* 业务持续计划的负责人员，选择技术服务的解决方案等。

* 实施前进行测试。

* 当情况发生变更时应及时更新计划。

计划的过程应该着重于关键业务目标，例如在指定时间内恢复客户的某种服务。围绕该服务的各种资源应该予以考虑，包括人员、信息处理资源以及信息处理设施等。

论会计业务流程的持续监控 篇4

持续监控是在一个较高频率的基础上对会计业务流程相关内部控制的建立和实施的整体情况进行的持续的、全面的、系统的和动态的监控活动。实施持续监控, 既是IT内部控制环境的客观需要, 也是开展持续审计的必然要求。

1. 适应IT内部控制环境。

当今的法规对于企业的内部控制提出了越来越严格的要求。对大型企业来说, 按这个要求建立起来的内部控制流程和关键控制点纷繁复杂且体系庞大, 采用手工方式对其进行监控, 会面临技术、时间、成本等多方面的障碍。

持续监控将一些重复的、分析性的工作自动化, 监控范围覆盖了会计业务流程中的全部交易数据, 通过明确权责关系, 在发现“例外事件”时, 即以“警报”方式发送给相关责任人, 使问题在萌芽状态即可进行识别和纠正, 并全程追踪问题的解决。通过持续监控, 还可以对识别出来的问题进行根源分析, 从而改进和优化内部控制。

2. 支持持续审计。

虽然持续审计并非需要依赖于持续监控才能存在, 但是内部审计作为内部控制的一项重要监控职能, 它所使用的持续审计技术与持续监控技术是类似的, 通常完善的持续监控系统内含了持续审计的功能。正因如此, 为了避免两者之间工作的重复, IIA要求审计人员在执行持续审计时, 应该将持续审计与持续监控进行整合, 在管理层已经对某项内部控制进行持续监控的情况下, 相同层次的详细交易测试就无需再进行, 取而代之的是, 对管理层持续监控程序有效性的评估 (IIA, 2005) 。同样, 外部审计人员在对管理层持续监控程序有效性的评估的基础上, 也可以借以开展持续审计。

二、会计业务流程持续监控的基本过程与方法

COSO (2009) 指出, 一个有效的监控计划包含建立基线、变更识别、变更管理和控制再验证四个组成部分。本文即据此来设计会计业务流程持续监控的基本过程与方法。

1. 建立基线。

基线是进行持续监控的依据, 它是在某个时点认为是有效的内部控制系统设计和运行状态的一个快照。常见的基线包括应用系统或者基础设施的配置设置或参数, 关于交易如何发生、处理和记录的业务处理规则。建立基线始于对会计业务流程面临的风险的全面了解, 识别出那些需要监控的、对会计业务流程控制目标“有意图”的风险, 并根据风险的重要性程度进行排序。而后, 识别出应对这些风险的关键控制。最后, 确定评估这些控制是否已经被实施、是否按照设计来运行所需的“有说服力”的信息, 由此确定基线的具体内容。

建立基线的目的是为了识别内部控制的变更情况。如果企业内外部环境发生变化, 而内部控制未能及时调整, 或者内部控制设计和运行发生了改变, 而基线未能及时反映, 这些都会在交易流的异象中体现出来。所以, 以基线为依据对交易进行分析, 识别交易中的例外、异常模式和趋势, 或者其他可能代表风险的因素, 抑或与期望的绩效指标相违背的情况, 可以有效识别控制是否需要变更或者已经发生了变更。

2. 变更识别。

进行变更识别, 持续监控需要对会计业务流程中的三类数据进行分析:常规的硬数据, 即能够清楚地定义、解释和计量的交易基础数据 (如价格) ;非常规的硬数据, 即需要从别的信息源获取信息, 并经过计算使它们能够解释和计量的数据 (如应计项目) ;软数据, 即具有高度主观性, 需要通过会计人员进行估计和判断的数据 (如存货的净现值) 。由于计算机目前还不能完全替代人工判断, 要全部实现对这三类数据的自动化分析还不可能。因此, 可以考虑一种比较可行的方法, 即将这些数据根据所需会计人员专业判断的多少进行分层。

Vasarhelyi等 (2004) 提出将对交易数据的分析区分为交易验证、合规验证、估计验证和判断验证四个层次。在这四个层级中, 层级越高, 需要的人工判断就越多, 自动化程度越低, 持续监控的效果越差。

交易验证针对的是未经汇总加工的交易“元数据”, 包括:验证原始凭证的录入是否符合基线中的相关规则;通过数据仓库中数据之间的勾稽关系, 或者价值链成员企业的信息沟通来检测虚假交易或者窜改过的交易;将业务流程的工作流程规范用持续方程进行表达, 来检查交易是否根据规定的业务流程持续、完整地进行了处理;借助现代安全技术 (如加密和数字签名) 来检测交易是否被非法处理;利用模式识别技术来发现交易中隐含的舞弊行为。

合规验证是证实交易的计量是否遵守了公认的会计准则。由于会计计量规则的模糊性、企业交易的复杂性和多样性, 要将这些规则全面纳入基线不可行。对于会计准则中明确规定的计量规则, 可以直接纳入基线。一些模糊的计量规则可以参照人工智能和专家系统的构建方法, 尝试运用知识表示和自动化的推理技术, 将它们转换为适合计算机执行的规范模式。这个层次的持续监控将使用模式匹配和其他技术来验证对计量规则的使用情况。对于可以直接验证的部分, 系统将自动化地判定该项应用是否合理。对于系统不能直接判定的部分, 则提交监控人员加以考虑。

由于不确定性的存在, 会计估计通常被认为只有通过人类专家才能进行。但是, 专家系统应用的经验告诉我们, 人类专家进行某些会计估计所需的参数, 可以通过将企业的内部参数 (如过去的应收账款回收率等) 和外部参数 (如市场利率、失业率、各种经济增长指标等) 采集和规范到一个估计模型中。在进行持续监控时, 可以将一些经过模型化的会计估计纳入基线。这个层次的持续监控可采用各种自动化的分析性复核程序。这些分析性复核程序不仅基于内部参数, 还包括外部参数。这些外部参数是持续监控系统获取的一个外部反馈, 例如, 将应收账款账龄的划分自动与同行业的其他公司的划分相比较, 来识别两者之间是否存在重大差异。

现代企业使用了大量的先进金融工具, 对这类交易进行持续监控, 需要复杂的、高层次的专业判断。这种判断可能要应对一些诸如持续经营决策、关联方交易的范围、企业系统的边界、价值链企业之间关系的性质等等。显然, 要实现对这种复杂的、高层次的判断的自动化分析是极其困难的。但是, 持续监控系统可以通过提供一些辅助信息, 来帮助监控人员进行判断, 例如, 可以借助对法规数据库和主要的信息源进行搜索的工具, 来获取一些进行判断所需的信息。

3. 变更管理。

持续监控会将上一步骤识别出来的变更, 以“警报”形式发送给相关责任人。警报的基本内容包括监控分析的具体细节、报送时间、报送对象、报送方式、对策建议、期望得到响应的日期。警报有轻重缓急之分, 为了避免某一时间段警报密集出现, 在设计警报过程中, 应该设计一种打分机制, 根据分数进行排序, 确定报送时间。根据警报的性质, 可能需要对控制设计和运行进行修正或完善, 或者建立起新的基线, 持续监控必须对这些后续处理进行全程追踪。此外, 持续监控系统使用者操作日志、基线的设定、警报及其后续处理的信息都应该予以保存。

4. 控制再验证。

当持续监控可以获取具有高度说服力的信息的时候, 它可以持续地对控制有效性进行证实。但是, 当持续监控所获取的信息说服力不足, 或者当风险达到一定程度的时候, 监控就需要采用专项评价的方式, 来周期性地对控制进行再验证。专项评价的执行频率和范围取决于被控制的风险的重要性水平、用于减低这些风险的控制是否重要和持续监控的有效性。

三、加强我国会计业务流程持续监控的若干思考

2009年4月, 财政部在《关于全面推进我国会计信息化工作的指导意见》 (下称《意见》) 中提出:“未来5~10年要实现大型企事业单位会计信息化与经营管理信息化融合, 同时要根据企事业单位内部控制规范的要求, 将内部控制流程、关键控制点等固化在信息系统中, 促进各单位内部控制规范制度的设计和运行更加有效, 形成自我评价报告。”可见, 在会计流程与业务流程进行融合的基础上, 实现内部控制的信息化, 并将其嵌入会计业务流程中, 是我国未来会计信息化工作的主要任务之一, 而且《意见》要求的“形成自我评价报告”, 又客观要求实现对内部控制监控的信息化。

根据莆瀚咨询公司 (2010) 发布的《中国企业内部控制共性问题》中指出, 目前企业普遍存在着对信息系统内部控制认识不足或存在偏差, 未能建立完善的信息系统内部控制体系, 而且IT治理不完善等问题。鉴于我国目前信息系统内部控制基础还比较薄弱的现状, 笔者建议从以下几个方面加强我国会计业务流程的持续监控。

1. 夯实标准化的会计信息化基础。

标准化的会计信息化环境, 是推广对会计业务流程的持续监控的前提。在一个未规范化的会计信息化环境下开展持续监控, 企业只能根据自身会计业务流程、交易数据、内部控制、业务处理规则的特点来进行大规模定制, 由此产生的技术方面的障碍和成本方面的压力, 并非每个企业所能应对。

我国即将建立的会计信息化标准体系, 将为持续监控提供一个标准化的会计信息化环境。其中, 会计基础工作标准, 将为构建标准化的会计业务流程提供依据;数据信息标准, 将会是一套涵盖会计信息生成、报告、披露与利用全过程的、比较完整的XBRL分类体系, 这给持续监控提供了规范化的分析数据;软件技术标准, 将为持续监控嵌入会计业务流程提供技术参考;应用性控制标准, 将指明所需要进行持续监控的内部控制流程和关键控制点。

2. 挖掘现有信息系统的持续监控功能。

我国会计信息化经过30余年的发展, 许多企业已经过渡到了更高层次的会计信息化阶段, 企业在会计信息化基础设施方面已经进行了大量的投入。但是, 由于传统的内部控制观念根深蒂固, 许多企业仅仅是将AIS (或ERP) 作为一种自动化会计业务流程的工具, 对于其中的内部控制功能较为忽视, 出现了书面内部控制与IT内部控制“两张皮”的现象。

出现上述现象的一个主要原因在于管理层对于IT内部控制认识不足, 对越来越多的嵌入AIS (或ERP) 中的内部控制充满神秘感, 对其进行监控不知如何着手。当前, 国际上一些著名的ERP软件厂商 (如SAP、Oracle) 推出的“公司治理、风险管理与法规遵循” (GRC) 产品, 能够与他们的ERP软件集成, 实现对业务流程的持续监控。以SAP GRC为例, 通过它可以方便地了解当前的ERP系统已经实现了哪些控制点, 还有哪些没有实现, 而且可以实现对这些控制点的自动化监控与测试, 并生成控制报告。

3. 提高内审人员实施持续监控的能力。

COSO指出, 有效的监控是由具备恰当胜任能力和客观性的监控人员来进行的。胜任能力是指监控人员具备内部控制和相关流程方面的知识, 包括对内部控制如何运行、哪些因素能够导致一个控制缺陷的了解。监控人员的客观性是指在进行监控过程中, 不会有个人私利方面的考虑。显然, 内部审计的客观性和独立性, 加上内部审计与内部控制的天然关系, 内审人员必然是执行持续监控的主体。

对于内审人员而言, 他们并非消极地执行管理层所实施的持续监控技术, 由于持续审计技术与持续监控技术的共通性, 内审人员在管理层还没有实施持续监控的地方, 甚至可能主动来帮助企业建立风险管理和控制评估程序。这就是说, 从内审人员开展持续审计的角度出发, 需要具备实施持续监控的能力。另外, 持续监控包含的审计功能越多, 它的可利用性越强, 所以, 内审人员在管理层实施持续监控过程中, 会充分发挥它的咨询作用, 从自身需求出发提出建议, 帮助完善持续监控系统。

我国的内审人员主要是财务审计人员, IT方面的技能非常欠缺。而实施持续监控需要内审人员熟悉会计审计准则, 能够理解并应用会计信息化标准, 了解IT内部控制的内容、方法和相关规范, 对于会计信息化软件有一个较深的认识, 而且还必须具备将这些知识应用到持续监控的基线设置和交易监控过程中的能力。显然, 单个审计人员要同时具备这些素养是非常困难的。比较可行的办法是, 组建一个不同专业背景的、分工明确的、密切配合的审计团队。

4. 开发会计业务流程持续监控软件。

长期以来, 由于企业对于持续监控的需求能动性不足, 导致持续监控软件市场狭窄, 软件厂商都不愿介入。随着《萨班斯法案》的发布, 人们对于公司治理、风险管理和法规遵循重要性认识的加深, 持续监控软件市场才逐渐兴起。在国际上, 以SAP、Oracle为代表的ERP软件厂商, 已经推出了各自产品配套的GRC解决方案;以ACL为代表的审计软件厂商, 推出了持续监控解决方案。

目前我国的软件厂商还没有涉足持续监控软件领域。《意见》指出, 在推进会计信息化工作中, 应当重视发挥会计软件公司和有关服务商的技术支持作用, 着力培育一个能够满足信息化发展需要的会计信息化服务产业。鉴于我国会计信息化软件较高程度的国产率, 笔者建议国内领先的ERP软件厂商适时推出持续监控软件。具体可以采用三种方式:ERP软件厂商推出与之配套的GRC软件;会计信息化软件 (或ERP) 构建过程中直接内嵌持续监控 (审计) 模块;待会计信息化标准体系建立之后, 再研究开发通用的持续监控软件。

综上所述, 持续监控是在一种较高频率下执行对交易数据的分析, 来反映控制缺陷的一种反馈控制机制。持续监控的自动化程度取决于它替代人工进行判断的能力、交易数据能够及时获取、能否实现与会计业务流程的无缝结合。持续监控的成效取决于对于警报能够及时处理、基线是否能够及时反映环境的变化、监控人员是否具备恰当的胜任能力和客观性。标准化的会计信息化基础和持续监控软件的支持, 是持续监控发展的重要推动力。

摘要：在会计流程、业务流程和控制流程集成的基础上, 通过建立控制基线、变更识别、变更管理和控制再验证四个环节来实施一个有效的持续监控计划, 是内部控制持续有效的保证。在我国内部控制尚且薄弱的情况下, 可以通过夯实标准化的会计信息化基础、挖掘现有信息系统的持续监控功能、提高内审人员实施持续监控的能力、开发会计业务流程持续监控软件等措施来加强我国会计业务流程的持续监控。

关键词：内部控制,持续审计,持续监控

参考文献

[1].IIA.Global Technology Audit Guide (GTAG) 3:Continuous Auditing:Implications for Assurance Monitoringand Risk Assessment.Maitland Ave:Altamonte Springs, 2005

[2].Vasarhelyi, M.A.Alles, A.Kogan.Principles of analyticmonitoring for continuous assurance.Journal of Emerging Technologies in Accounting, 2004;1

如何保障业务连续性的数据安全 篇5

也是重中之重。

连续中的漏洞

根据国家信息中心数据修复中心三月底发布的《中国数据修复市场报告》，超过八成的大中型企业仅仅具有BC建设的雏形。更加让人遗憾的是，即便是系统雏形，仍然问题多多，其中90%的业务连续性失败出现在内部子系统上。

记者发现，在大部分建设了BC保护的企业中，用户的共同习惯是搭建核心系统双机热备。在备份机器的内部，无一例外都采用了RAID技术。但就是这个RAID，对很多企业的BC安全造成了灾难。

从原理上说，RAID就是一种把多块独立的硬盘按不同方式组合起来的一个硬盘组（逻辑硬盘），提供比单个硬盘更高的存储性能和数据冗余技术，既保证了存取数据的快捷方便和简单地管理客户端，也解决了存储海量数据的问题，同时提供了较高的容错性。它可以在不停机的情况下自动检测故障硬盘、替换硬盘，还可以扩充硬盘容量、重建故障硬盘上的数据。

企业使用RAID的目的，就是利用硬盘空间的冗余实现数据容错，确保数据的安全。然而，RAID并不是一劳永逸的方法，有时也会出错。如果处理不当，有时会丢失企业大量的业务数据。

比如企业最常用的RAID5，在一块硬盘发生故障后，RAID组从Online变为Degraded方式，I/O读写不受影响，直到故障盘恢复，

但是，如果Degraded状态下又有第二块盘故障，整个RAID组的数据将丢失。从《2006中国数据修复市场报告》披露的数字看，这个比率相当高，约占到BC失败的一半左右。

另一个BC失败的大头，就是意外事件影响。比如突然断电，或者重新配置RAID阵列，甚至用户的某些错误操作，都可能造成RAID硬盘阵列卡信息的丢失，从而导致数据的丢失。一旦出现类似情况，企业就会遭遇比较严重的数据安全风险。

国家信息中心数据修复中心负责人叶红在接受采访时表示，在企业BC系统发生安全故障的时候，为了最大程度地保护数据安全，必须进行应急响应，重新建立安全冗余机制。相对而言，对于丢失的业务数据，数据修复是比较理想的恢复手段。

杜绝BC安全隐患

《2006中国数据修复市场报告》中披露，常见的BC安全风险分为三类：硬盘阵列出错、信息系统故障、硬盘本身故障。

据悉，硬盘阵列出错的具体原因有阵列卡损坏、阵列卡电池电力耗尽、槽口控制芯片损坏等。虽然这类情况的数据恢复率相当高，但也有失败的案例。据专家介绍，当发生阵列卡损坏时，随意更换新的阵列卡极易造成硬盘ID号紊乱，导致数据风险。而系统故障主要是指系统崩溃时，一些用系统自带功能创建的硬盘阵列或者用第三方软件组建的硬盘阵列会发生数据丢失。此时，阵列日志和相关记录是相当重要的。

在硬盘故障方面，由于管理不善和服务器相对稳定的特性对管理者造成麻痹，发生超出允许数量坏硬盘的事故屡屡发生。一旦RAID阵列出现故障，硬件服务商只能给客户重新初始化或者重建，这样企业的数据安全将会无法挽回。