数据集中管理（精选8篇）
数据集中管理 篇1
大数据被越来越多的企业关注, 核心还在于“数据”本身。对于国内大部分企业而言, 企业数据资源通常存在于多个异构或同构的系统中, 数据的采集与使用也面临着两大问题:
一是数据缺乏完整性和一致性, 重复数据多;二是数据标准不统一, 共享过程中不知以谁为“主”。
为解决上述现象, 实现数据在整个企业范围内保持一致性、完整性和正确性, 就需要进行主数据管理。也就是从企业的多个业务系统中整合核心的、需要共享的数据 (主数据) , 集中进行数据的清洗和丰富, 并且以服务的方式把统一的、完整的、准确的、具有权威性的主数据分发给全企业范围内需要使用这些数据的操作型应用和分析型应用, 包括各个业务系统、业务流程和决策支持系统等。
用友UAP的主数据管理系统负责主数据服务管理调度、数据读取转换存储以及和其他业务系统的数据交换。在实践经验中, 用友UAP发现很多企业由于分子公司较多, 并且使用的系统多样, 主数据系统和其它业务系统很难实现统一, 并且很难快速筛选出重要信息。
用友UAP主数据管理系统以服务的方式把统一的、完整的、准确的、具有权威性的主数据分发给全企业范围内需要使用这些数据的操作型应用和分析型应用。完全实现具备集成、共享、数据质量、数据治理等关键要素, 将分散的主数据统一集中管理。
比如某金融机构, 面临这样的问题:基础数据不统一, 系统与系统之间数据无法共享, 大量数据重复录入。另外, 针对不同角色人员, 他们希望拥有可定制的自助服务页面, 使信息获取准确、及时。用友UAP根据此客户的系统现状和需求, 将用户数据、单位数据、部门数据、岗位数据、职务数据、人员数据、客户档案数据等都纳入主数据管理。这些数据需要通过主数据管理平台进行统一的管理, 以避免这些同类型数据在各个系统中的重复录入;同时, 用友UAP在该企业服务规范中, 为每种主数据制定相关的数据管理服务, 这些服务对所有应用系统开放。企业内的所有系统均可以通过这些服务获取主数据, 并参与主数据的管理。
面对企业内部异构的系统, 如何从不同系统中快速获取对自己有价值的数据, 成为一大问题。针对于此, 用友UAP采用数据推送的方式。数据源端系统可以发布数据, 同时对该数据感兴趣的系统可以订阅并接收源端系统发出的数据然后对数据进行处理。
首先, 数据发布方通过ESB提供的服务接口将数据放入ESB中, ESB得到数据后, 将其写入消息队列中。然后, 异构系统通过ESB提供的服务订阅感兴趣的数据, ESB在收到数据后通知异构系统有新数据到达。之后, 异构系统通过ESB提供的服务主动访问ESB去取数据, ESB得到取数据请求后, 访问消息队列取出数据。最后ESB将数据返回系统。
用友UAP的这种设计, 核心是通过ESB的多协议间传递数据的能力, 通过ESB用消息队列做数据的中转, 从而实现多系统间的数据推送。通过系统自动推送数据, 并且实现多系统间的推送, 集团可以得到及时了解, 提高了汇报效率。
数据集中管理 篇2
一、传统集团资金管理方式存在的弊端
传统集团资金管理方式大部分是集权式管理模式, 高度集权式的资金管理方式本身存着在一些严重弊病。
(一) 集团总部与各成员企业之间财务信息不能及时共享
资金管理权高度集中, 财务部全权控制资金。这样虽然可以使资金的筹集和使用得以集中, 能够从集团整体利益的角度出发, 进行有关项目的投资。但是, 这样往往会对资金统管得太死, 失去了流动资金的灵活性, 不利于规范财务管理, 影响集团生产经营活动的正常进行和集团资源的整合。
(二) 信息失真, 难为科学决策提供依据
现代企业管理的根本是信息管理, 企业必须及时掌握真实准确的信息来控制物流、资金流。然而, 目前我国相当多集团公司的信息不透明、不对称和不集中。集团公司的高层决策者难以获取准确的财务信息, 从而导致集团无法监控下属单位资金流向, 资金使用效率低下, 资金风险大。
(三) 监控不力, 缺乏事前、事中的严格监督
目前, 母公司对子公司、公司管理层对各资金运动环节普遍存在着监控不力、内部人控制的现象。
(四) 资金散乱, 使用效率低下
目前, 集团公司内部资金分散的现实已成为现阶段企业财务资金管理中最突出的问题。一是子公司多头开户的现象比较普遍;二是投资决策随意性大;三是资金沉淀严重, 欠款居高不下, 流动资金占用有增无减, 企业信用和盈利能力下降。
二、数据集中管理模式概述
(一) 方案概述
某软件公司推出了M5资金协同管理软件, 通过多公司一个账套集中管理模式, 为集团建立统一的资金管理平台, 集团下属公司通过平台, 把本公司的资金收付信息实时登记到系统中, 集团通过平台对下属公司的收付款过程进行在线控制, 既增强了收付款的安全, 又提高了资金收付工作的效率, 使出纳、资金会计、相关领导能实时获得整个集团资金变动情况。
(二) 功能描述
1. 收款管理
收款管理主要是处理企业所有的对外收款的业务。包括银行收款和现金收款两类。 (1) 收款编制:包括直接收款录入、现销业务收款及从网上银行导入三种方式;录入收款单时, 若结算人有相应的应收记录, 可选择按往来单据金额进行收款, 系统自动建立核销关系, 收款确认后可自动核销;现销收款为在销售单上直接收款, 生成收款单, 并核销相应往来;网银收款明细导入:通过下载网上银行收付明细记录, 从收款信息直接导入生成系统内银行收款单。 (2) 收款确认、登账:出纳根据收款底单或现金核对系统收款金额, 并进行“收款确认”。确认后该笔收款自动登账、自动产生相应往来收款记录, 并可在往来系统进行核销。
2. 付款管理
付款管理主要处理企业所有的对外付款的业务。有现金付款和银行付款两种形式。 (1) 付款分类管理:付款分为预付款、应付往来单位款、应付内部公司款、应付员工往来款等四类。可设定不同岗位负责不同的付款申请、审批。细化付款管理监控、降低支付风险。 (2) 付款过程的管理:付款过程包括付款单编制、付款审批、支付票据打印、网上银行支付提交、登账、核销等工作的全程管理, 所有工作均在线完成。
3. 转户管理
资金转户包括转户申请、付款 (转出) 确认、收款 (转出) 确认、登账等过程, 系统可在线记录每个过程的执行信息, 未确认的为在途资金, 保证转户资金安全。
4. 网上银行对接功能
网上银行接口功能可实现资金系统数据与网上银行数据的对接。 (1) 从资金系统到网银:通过“生成银行支付文件”功能, 可以批量处理需要通过银行支付的付款单生成网上银行接受的支付文件, 并直接通过网银进行支付。 (2) 从网上银行下载数据导入资金系统:通过“下载银行收付记录”功能, 可以随时从网上银行下载银行收付名细, 在公司内部网络可以查看与银行同步的数据, 包括账户余额, 并且可以将收款记录直接生成银行收款单。 (3) 银行对账:可以动态、实时进行资金数据与银行数据进行核对, 生成银行未达账。
5. 资金统计报表
只要数据一录入, 即可实时查到整个集团各公司的资金统计表。包括资金日记账、余额表、资金变动趋势表等。 (1) 资金日记账:可以按账户等条件查询各资金账户的发生额及结余情况。 (2) 账户余额表:可以按年月、公司、账户对各资金账户的发生额及结余情况进行分类汇总。以下为多个公司的账户余额表, 可逐级展开到明细数据。 (3) 整个集团资金余额变动趋势:可任选多个公司查看其总余额的变动趋势。
6. 过程控制
资金账户的控制权落实到个人, 便于多账户的管理;将外部单位的账户的修改经过记录到修改日志中, 使账户的安全性得到控制;对付款单的打印次数进行控制, 保证付款单的唯一性, 提高有效支付的安全程度;可按应付款生成付款单;付关联公司款项时, 系统自动生成对应公司的收款单, 保证付款的关联性;资金单据自动生成会计凭证, 保证资金系统与总账系统的一致性;可依据网上银行的收款记录生成银行收款单, 及时反映银行账户的到款情况。
三、应用效果
(一) 实现集团资金集中管理
按多公司一个账套的模式, 把所有公司的资金账户进行统一管理, 在现有账户结构基本不变的情况下, 集团总部可实时掌握所有公司的资金收付情况, 实现集中支付、集中审计、集中划拨等
(二) 提高付款、收款的安全性
消除了手工填写付款单, 付款记录在申请支付时即已进入系统:付款审批可使用在打印的付款单上手工审批或通过网络在线审批;收款实时登记与确认, 保证资金信息的及时性与准确性;所有账户纳入统一管理, 加强了现金账户的管理。
(三) 提高出纳工作效率
出纳的全部资金收付工作能在系统上完成, 消除了手工填单和手工登账, 极大地提高了出纳工作效率, 减少差错。
(四) 实时监控、实时查询、统计分析
只要录入了收、付款单, 即可实时掌握各个账户的资金变动和结余状况, 便于进行资金调度和资金管理。管理人员可以在线查询收付款情况, 完成各类收/付统计。同时还提供了员工收款在线查询。
(五) 网上银行
数据集中管理 篇3
1.业务需求方面，企业将关注点越来越多地从“CRM前台”的建设转向“CRM后台”。众所周知，CRM系统主要涉及企业在销售、营销和客户服务等三个关键方面。其中，客户服务/销售流程的管理可以称之为CRM的“前台”系统，而客户营销则可以看作为“后台”系统。在前几年，国内企业CRM系统的建设主要从客户服务和销售方面入手，大力建设企业的客户服务系统、销售自动化系统等，来规范企业内部的服务/销售流程，提高效率，
之所以选取这两个方面，主要是由于这两个方面是企业急需改善的环节，实施起来相对容易，而且见效快。经过几年的建设，企业越来越多地关注客户个性化体验，主动的“一对一”营销等功能。
2.从采用的技术而言，操作型CRM系统建设高潮逐渐回落，企业对分析型CRM系统的实施日趋重视，尤其在电信、银行业。前几年，国内企业CRM系统建设以采用CTI、Web等核心技术为主来建设Call Center、Web门户系统。随着呼叫中心、网上自助服务系统的建立和完善，企业与客户之间沟通的渠道得到了极大的扩展，但如何利用业务系统以及渠道系统收集的客户信息进行深层次的分析和挖掘，提升操作型CRM系统的业务价值，以便更好地服务于企业业务发展目标，成为企业的当务之急。以数据仓库技术、数据挖掘等为基础的分析型CRM技术越来越多地被企业所采用。
数据集中管理 篇4
关键词：数据集中,会计核算,会计管理
从手工核算、计算机单机版核算到计算机网络版会计核算数据大集中 (TCBSTIPSTMIS) , 国库业务处理和国库会计核算工作日趋集中化和自动化。数据集中后, 基层国库在整个业务处理流程中一般只需负责少量外来凭证数据的手工录入, 绝大部分业务处理需对电子信息进行审核和提交, 账务处理全部由计算机系统后台集中自动处理, 自动账务平衡。国库会计数据集中为国库实现高效统一的业务处理流程和会计核算标准化管理奠定基础, 国库风险防范效果显著增强, 国库核算效率和管理水平不断提高。
一、国库数据集中对会计核算的影响
数据集中处理使国库会计核算环境产生了巨大的变化, 国库会计核算业务从设计理念到处理模式均发生了根本性变革, 具体如下:
(一) 对会计核算方法的影响。
数据集中前, 国库核算采取“单讫记账”原则, 将国库业务划分为资金和收支明细信息的两种核算内容, 并先后对国库资金往来和国库收支信息进行分岗位的核算处理。
数据集中后, 国库核算采取“一记双讫”原则, 国库业务的资金往来与国库收支信息“被统一”进行录入操作, 取消资金岗和收支明细核算的业务分工, 简化了业务处理过程。
(二) 对国库资金清算方式的影响。
数据集中前, 国库资金清算采取“行库往来”, 或以省库为单位直接加入支付系统的“多点接入”、“非集中”方式进行处理。总库和省库资金以支付系统直接参与者的身份进行清算;区县级等基层国库以支付系统间接参与者的身份, 通过省库 (清算国库) 进行清算;区县级等基层国库与省库之间通过“国库内部往来”的方式进行清算。
数据集中后, 国库资金以总行“一点接入”支付系统的方式进行清算。总库资金为清算国库资金, 以支付系统直接参与者的身份进行清算;省库、区县级基层国库以支付系统间接参与者的身份进行清算;总库、省库和区县级基层国库之间的资金清算都通过“国库内部往来”的方式进行清算。
(三) 对会计账务体系的影响。
数据集中前, 国库会计核算分为明细核算和综合核算两部分。其中, 明细核算包括凭证———分户账 (登记簿) ———余额表;综合核算包括凭证———科目日结单———总账———日记表。
数据集中后, 会计账务处理全部由系统根据录入的收支业务初始数据自动汇总而成, 所有加工和处理完的数据由计算机系统自动检验和自动会计账务平衡, 自动产生分户账和总账, 无需进行手工生成科目结单等会计明细核算和综合核算的分工处理操作。
(四) 对业务处理模式的影响。
数据集中前, 国库业务基本使用单机版的国库会计核算系统进行处理。所有的收支业务数据必须通过手工原始录入或数据导入方式输入核算系统, 自动化程度不高。
数据集中后, 国库业务由国库会计数据集中系统 (TCBS) 进行处理。TCBS是网络版的计算机应用系统, 具有强大的网络数据传输与接收功能, 便于国库实现信息化的业务处理模式。数据集中后, 国库业务处理的信息化程序越来越高, 手工劳动强度越来越低。以海南为例, 90%的国库收入业务和100%的财政支出业务实现联网方式处理, 预算收入退库业务的电子化程度也越来越高。
(五) 对业务处理内容的影响。
数据集中前, 处理国库业务既需要完成对收支业务信息的录入处理, 还需要对国库会计分录、国库会计试算平衡、国库资金与业务对账等会计账务流程进行分开核算。
数据集中后, 国库业务处理只需将收支业务信息录入国库系统终端即可, 相应的会计账务处理全部由国库核算系统自动完成。
二、国库数据集中对国库会计管理的影响
国库会计核算数据集中后, 基层国库在日常工作中, 作为分散网点只负责业务受理、数据提交工作, 账务处理集中由TCBS、TIPS和TIMS中心系统后台自动完成, 数据集中存储总行数据中心, 会计机构趋于扁平化, 会计管理趋于标准化、高效化。
(一) 对国库系统管理的影响。
数据集中前, 国库系统基本采取用户单一审核、单一检验、系统软硬件本地化维护的管理方式。数据集中后, 国库系统用户管理实行双签制, 系统参数实行审批制。设置系统用户时, 国库会计主管和系统管理员由上一级的国库系统管理员维护, 上一级会计主管审批;操作员用户由本级国库系统管理员设置, 本级会计主管审批;设置业务参数时, 由本级系统管理员维护, 本级会计主管审批。用户登录系统时, 系统需要对用户登录密码和用户CA证书密码进行双重身份验证。数据集中后, 系统软件升级、服务器硬件的维护管理、业务数据的存储和备份都由总行数据中心集中处理。业务系统中财政体制等重要参数设置权限上收TCBS中心, 由中心相关人员设置并审批。
(二) 对人员素质管理的影响。
数据集中前, 国库收支业务和会计账务核算被“分割”, 且两者均需完全手工处理或部分手工处理, 要求国库业务人员具备较高的会计核算能力和理论水平。数据集中后, 业务处理人员办理业务时只要按照系统界面要求在终端中简单录入必要的原始信息, 系统就会自动生成账簿并产生会计结果。会计核算业务人员的主要职责变成了原始信息的录入和核实, 相应的素质要求只需具备相对简单的系统录入技能即可。数据集中后, 国库职能发生较大变化, 国库重点工作向国库风险管理和数据管理逐渐转变, 要求国库管理人员和国库数据分析人员具备更高的理论水平和实践经验。
(三) 对国库岗位管理的影响。
数据集中前, 根据国库系统用户的权限分工不同和风险管理的需要, 国库部门设置国库主任、会计主管、明细核算员、资金清算员、综合核算员、系统维护员等岗位。其中在系统中设置的岗位用户包括:会计主管、明细核算员、资金清算员、综合核算员、系统维护员等。数据集中后, 为满足新环境下国库业务处理和国库风险管理的需要, 国库部门设有岗位包括国库主任、国库部门负责人、会计主管、系统管理员、系统管理员等5类, 在国库系统设置的岗位用户有会计主管、系统管理员和系统操作员3大类。根据岗位职责管理需要, 系统操作员还可根据收支业务类型进行权限再细分, 设置更明细的操作员岗。
(四) 对国库风险管理的影响。
数据集中前, 国库系统由各地独自管理、业务处理和会计账务独自核算, 其系统运行风险由各级国库自身负担;数据集中后, 国库环境发生变化, 国库风险发生转变或转移, 具体情况如下:
1、系统风险。
一方面数据集中后, 业务处理及存储后台集中在人民银行总行, 系统风险集中在人民银行总行, 一旦系统运行出现故障, 应急管理难度增大, 直接影响全国各级国库、财政和征收机关的业务处理, 影响巨大;另一方面数据集中后, 国库业务处理模式电子化程度越来越高, 国库系统直接连接财政、税务、商业银行等多个部门系统, 增加了对外部系统的依存度, 增加了外部转嫁风险和网络风险。
2、会计核算风险。
数据集中后, 国库业务流程、国库资金清算方式、国库业务处理模式和主要处理内容的变化使国库会计核算风险也发生改变。如TCBS日终汇总凭证是由TCBS数据后台根据全国业务发生和各地系统自行设置情况自动产生, 容易导致TCBS汇总凭证编号存在跳号现象, 无法对凭证是否漏打和缺失进行控制。
3、事后监督风险。
数据集中后, 事后监督方式、流程都没有随国库业务操作方式和流程的变化进行同步相应的调整, 监督仍以手工方式为主, 监督效果不明显。
三、加强国库数据集中后国库会计核算与管理的建议
(一)
切实加强国库计算机系统的计算机外在风险、计算机硬件风险、计算机软件风险、计算机网络风险和操作风险的认定与评估, 采取合理的控制手段, 确保计算机系统的安全运行。
(二) 加强国库会计核算与管理的标准化、规范化建设。
制定与国库会计数据集中相配套的规章制度和事后监督管理办法等制度体系, 针对数据集中后出现的新情况、新问题, 结合业务发展中的岗位设置、人员配备等实际情况, 进一步修订和完善国库会计制度和相关规定, 明确各类国库业务的操作流程, 增强业务的规范性、操作性和程序性, 使国库业务管理有法可依, 有章可循, 从制度法规上为国库业务发展提供保障。
(三) 加强对会计核算的监测预警。
及时对会计操作信息进行跟踪分析, 对带苗头性、有疑点的问题实时报警, 对产生的会计业务异常处理和会计差错及时做出反应、及时采取纠正处理, 确保各项内部控制制度被切实执行, 各项国库业务处理结果准确无误。
(四) 对各种国库岗位人员应进行区别管理。
根据不同的职责分工有针对性地加强专项培训, 同时将职业技能的培训和职业道德素质提高有机结合, 使每个员工成为国库工作的行家里手时, 具有较高的道德素质, 能有效提高风险防范意识。
(五) 针对环境的变化, 强化国库风险管理。
数据集中后, 应针对系统功能变化可能带来的风险隐患, 完善内控, 加强管理。在日常业务管理中, 要更加强调业务环节之间的衔接和制约, 保证各个业务管理环节的无缝连接和相互监督。
参考文献
数据集中管理 篇5
(一) 业务处理流程进一步优化
ACS对中央银行会计核算业务流程进行了全面改造, 从设计理念到核算模式均发生了根本性变革。营业网点作为会计核算的前台, 只负责业务受理审核、凭证扫描等基础工作, 会计核算信息录入、账务处理被剥离至全国业务处理中心;所有在人民银行开户的单位之间的账务往来均变为内部转账, 节约了成本, 提高了效率;系统自动校验功能增强, 减少了核算差错的发生;账务处理自动化程度大大提高, 如同城票据交换轧差净额清算以电子信息格式导入ACS后自动记账, 交存款业务由银行机构通过综合前置系统提交电子信息后系统自动处理等, 核算流程再造减少了凭证填制和业务处理环节, 业务处理时间大大缩短, 业务处理效率显著提高。
(二) 基层核算岗位配置进一步精简
按业务处理需要和内控管理的要求, ACS模式下地市核算主体设置市级运管中心主管岗、参数管理岗、营业网点主管岗、业务受理岗4个岗位, 较中央银行会计集中核算系统 (ABS) 模式下岗位设置大为减少, 有效地化解了基层央行因会计核算人员数量不足、岗位业务量不均衡等原因所致的兼岗过多、违规兼岗等问题, 有力保障了会计人员轮岗、强制休假等内控制度的执行力度。
(三) 业务风险减少且控制难度降低
ABS模式下, 基层央行营业部门承担业务处理中的会计核算、联行往来和综合管理等风险。ACS模式下, 营业部门的会计核算风险、联行风险上移至业务处理中心, 核算处理流程的变革大大减少了营业部门业务风险, 且风险性质变得较为单一, 风险点主要集中于外来凭证审查及凭证编制。风险控制难度有效降低, 在日常核算业务处理过程中, ACS通过账务集中处理、流程参数化控制等措施, 使得基层央行的操作风险、系统风险得以有效降低或规避。
(四) 会计核算监督控制进一步强化
会计监督是提高会计核算质量的重要手段。传统的会计核算监督基本上是事后监督, 由于人为因素和监督的滞后性, 会计核算监督的质量有待进一步提高。ACS通过重塑会计核算业务监督机制, 利用影像信息和会计核算档案数据库, 采用预警、控制等方式强化过程监督, 使得整个会计核算过程成为“阳光操作”, 实现业务流程与风险监控同步化。通过事先设定监督条件, 对开销户、参数维护和非工作时间操作等业务进行实时监督 (T+0监督) , 将风险控制关口充分前移, 对会计风险的控制贯穿于会计核算的全过程。
(五) 会计信息决策价值进一步提升
ACS运行后, 实现了人民银行会计数据等信息的纵向集中和横向整合, 将以往因地域和部门限制而形成的“信息孤岛”有效连接, 克服了会计数据分散、采集环节过多、逐级汇总延时等弊端, 会计报表的汇总时间由原来的一个月缩短至次日, 信息的时效性、完整性和准确性大大增强。基层央行的会计核算工作重点也随着系统功能的变化而进行了适时调整, 由业务操作型向管理型转变, 由注重会计核算数据的准确性、及时性向提高会计核算数据的分析利用转变, 通过从海量会计数据中甄选出有价值的会计信息并进行深度挖掘, 为中央银行政策制定实施提供信息支持和决策参考。
二、ACS运行对基层会计核算的挑战
(一) 全新账务处理模式使得传统内控制度不再适用
中央银行会计集中核算的运行操作和内控管理都必须依靠制度的约束才能完成。ACS运行后, 原有的会计核算制度已经滞后于业务的发展, 在业务处理方式已完成转变、新旧制度交替期内, 基层会计核算人员对原有部分制度的执行存在偏差。同时, 在账务处理集中模式下, 核算业务系统已将凭证接柜、业务受理与会计记账、账务核算相分离, 营业网点不参与记账和核算, 这使得营业网点的核算人员变成了办理柜面业务的操作人员, 而非传统意义的会计核算人员。随着基层核算主体岗位职责的变化, 新的会计核算内控要求与传统会计核算内控制度存在脱节现象, 使得传统会计核算内控制度的很多制约性内容失去了针对性、适用性, 易产生新的内控风险。
(二) 会计核算业务风险点发生转移
在ACS中一些传统的会计核算控制措施被省略或内置到会计核算应用系统中, 如各种重要空白凭证登记簿、账号户名的一致性等均可在系统中进行自动校验和控制, 克服了以往核算模式下操作弹性管理的弊端。会计核算账务处理由系统自动完成, 现行的以不相容岗位职责相互分离为重点的风险控制措施已不再适用, ACS模式下会计核算业务风险点与传统会计核算模式下的风险点存在显著差异, 这就需要基层央行重新对会计核算工作进行风险评估。如ACS中会计信息和报表的正确性、真实性和完整性完全取决于原始凭证数据的准确性和真实性, 这使得对原始凭证的业务受理、审核、账务处理和监督成为风险控制的重点;营业部门根据业务需要自行编制凭证的业务、同城票据交换业务等都是资金案件易发区, 因此, 确保对每笔存在风险隐患的业务进行授权控制尤为关键。
(三) 应急管理工作面临严峻形势
随着ACS业务处理和数据存储的集中, 原来分散的风险也随之集中, 但目前基层央行对集中风险的处理能力不强, 仍停留在对单个系统的应急流程处置和故障恢复的风险防范阶段。同时, 目前ACS日常应急管理中也存在一些问题。一是ABS已无法作为ACS的日常应急备份。由于ACS与ABS系统运行平台完全不同, 数据格式不同, 导致两者之间数据衔接难以实现, 同时ABS设备老化严重、业务人员对ABS的操作技能渐缺等问题的存在, 使得ACS回退到ABS的可行性、时效性和可操作性不强。二是ACS业务处理模式下, 基层会计核算人员只负责凭证受理扫描、审核和上传, 不参与真正的账务处理, 随着时间推移, 基层会计核算人员将慢慢变成熟练的扫描员, 渐渐不明白真正的账务处理原理, 如遇突发事件须启动手工处理账务时, 可能出现无法应对的局面。
(四) 安全管理作为业务系统的支撑变得尤为重要
数据大集中后, 业务处理和风险控制对计算机程序、软硬件设施、通信网络的依赖性增强, 技术性风险成为会计核算数据集中系统的重要风险, 且风险的突发性、传染性更大, 信息和数据的安全管理是数据大集中模式下面临的最为严峻的挑战之一。ACS充分利用计算机及网络通信技术, 管理效率的高低在很大程度上取决于业务系统和网络的稳定与否。目前, ACS正处于上线运行磨合期, 系统与网络安全管理须进一步完善, 有效防范和化解因网络、技术等故障导致错账、统计错误甚至业务无法正常处理的风险尤为重要。
(五) 对基层会计核算人员综合素质要求提高
一是基层央行营业部门会计核算人员老化, 从业务操作型向管理分析型转变难度较大。二是基层会计核算人员长期从事单一会计岗位, 从事程序化、重复性业务操作, 容易产生“操作定势”和“经验做法”这些不合规的“习惯性操作”, 导致业务人员形成惯性思维, 容易在进行重要风险岗位业务操作时增加风险的机会。三是ACS模式下, 基层会计核算人员从事的业务看似简单, 但事关业务的真实性、凭证的合规性, 其素质的高低直接关系到会计核算质量的高低和核算风险能否有效规避。四是ACS打破了原有会计核算模式, 通过流程再造将会计人员从简单的操作工作中解放出来, 从事会计管理相关工作, 这对会计人员提出了更高要求。
三、ACS模式下完善会计核算工作的建议
(一) 完善ACS内控制度, 提高内控管理能力
ACS上线运行后, 全国341个核算主体均依据相同的标准, 采取统一的方式进行会计核算业务的处理, 营业网点的业务种类趋同, 区域差异缩小。在新会计核算和账务处理模式下, 加强顶层设计, 由总行考虑在会计核算整体管理职责的基础上制定统一的、具有前瞻性、稳定性和连续性的会计核算内控制度;各分行、省会中支细化和制定针对ACS内控制度具体措施, 确保《中国人民银行会计集中核算管理规定》等制度进一步落到实处。对原有会计核算不实用、过时的核算制度, 尤其涉及岗位衔接、岗位职责划分等事项的内部控制, 应及时作出相应的调整和修改, 尽可能有针对性地制定预防和防范资金风险的措施, 确保会计核算制度的严谨有效。
(二) 全面分析业务流程, 加强风险防范能力
基层营业部门根据新的业务流程和内控管理需要重新进行风险评估, 有针对性地采取有效措施, 从业务受理, 凭证填制, 数据录入、处理、输出等环节加以控制。加强业务受理和凭证要素审核, 从源头上控制凭证填写要素错误或凭证使用错误等问题, 避免上传未经审核的数据影像信息。加强录入控制, 确保经审核后的数据能完整、正确地录入并转换为系统可识别的形式。完善处理过程控制, 确保已录入数据完整、准确地传输和处理, 防止数据丢失、重复或出错。强化输出控制, 保证为有权限的会计信息使用者提供准确、完整的数据信息。
(三) 加强应急管理, 提升应急处置能力
一是为了提高应对突发事件的能力, 各核算主体应根据总行应急处置预案定期或不定期开展应急演练, 强化应急演练效果, 提高突发事件应对能力, 确保突发事件发生时, 会计核算人员能及时、快速做出准确应对。二是建议通过开发单机版ACS应急处理程序的方式满足应急管理需要, 一旦ACS出现瘫痪, 各营业网点可临时使用该系统完成简单的账务处理, 待ACS恢复运行后, 可将数据导出后迁入ACS继续使用。三是储备会计核算人才, 加强会计基本技能锻炼, 如会计核算应用系统突遇特殊情况宕机, 不得不启用手工操作时, 核算人员应具备会计业务手工处置基本能力。四是根据会计核算业务纵向集中的特点, 强化条线管理, 密切上下级沟通联系, 拓宽交流渠道, 构建纵向风险联防机制。
(四) 加强安全管理, 提高会计核算安全意识
为确保系统安全稳定运行, 业务部门和技术部门要形成有效的协同联动机制, 建立信息安全保障机制, 通过强化生产安全和信息安全, 将集中风险控制到最低点。从技术和管理上防止计算机软硬件出现故障导致信息丢失或系统瘫痪。采用先进的网络安全控制技术和有效的计算机病毒防范体系、网络漏洞检测和攻击防御系统, 防止病毒和黑客的入侵, 确保会计信息安全。建立数据备份和数据档案管理制度, 保持会计核算业务连续和稳定运行。同时, 进一步提高基层央行会计核算人员的安全意识, 提高风险预警能力, 对日常业务处理中发现的网络异常导致的苗头性问题, 如上传文件异常、待启动业务处理流程等情况要高度重视, 及时有效地开展风险排查, 强化日常运维管理。
(五) 建立人才培养长效机制, 提高核算队伍综合素质
一是重视会计核算基础工作和人才成长环境建设, 加强职业道德教育, 创新培训方式, 加强业务培训和交流, 如集中学习、网络在线培训、交流学习、技能竞赛等方式, 促进基层会计核算人员尽快适应角色转换。二是不断提高核算人员综合业务素质, 在ACS全新的核算模式下, 基层核算人员作为前台会计核算人员, 要着力提高对业务系统的应用能力、对会计业务的审核能力和对会计账务处理能力;作为会计管理人员要提高专业分析水平, 充分运用强大的数据仓库功能, 强化会计信息分析能力, 实现由分散数据物理集中向海量数据集成应用的提升, 加强会计分析与宏观决策有效结合的研究能力, 为中央银行制定和执行货币政策、加强宏观调控、维护金融稳定以及优化金融服务提供支持。
摘要：中央银行会计核算数据集中系统 (ACS) 已于2014年6月在全国成功推广上线, 实现了业务处理和数据管理的全面集中, 这给基层央行会计核算管理工作带来了挑战。本文通过深入分析系统运行带来的影响和挑战, 进而提出数据集中模式下完善会计核算工作的建议。
关键词：ACS,会计核算,挑战,建议
参考文献
[1]刘春雷.对中央银行会计核算数据集中系统上线后有关问题的思考[J].内蒙古金融研究, 2014 (8) :69-70.
[2]刘莉亚, 王海英.中央银行会计核算数据集中系统 (ACS) 存在的问题及建议[J].河北金融, 2013 (12) :64-65.
数据集中管理 篇6
“实际上现在大家都没‘锁门’, 只是怀着侥幸心理, 自认为没有人知道而已。”
当谈到目前数据管理的最大问题时, 赛门铁克中国区技术总监李刚这样表示。在他看来, 数据的安全现在仍是首要敏感问题, 其管理和防护实际上十分不到位。
他认为, 端到端的集中式管理需要启动。
业务标准与技术手段不足
集中式数据管理已经成为IT业界实现有效数据管理的发展趋势, 但具体落地到电信行业, 由于传统IT系统建设多为竖井式, 随着电信业务的复杂度不断提升, 数据应用往往需要跨多个主机, 因而使得端到端管理变得较为困难。
“集中监控和管理是一个目标, 并不是手段。目前运营商们关注目标, 却不知道该怎么做。其实这里更重要的是, 在整个公司层面, 对数据要有从业务角度的理解和标识, 同时又要有管理流程和策略。这是第一步, 接下来才是真正去做端到端监控和管理。”李刚表示。
李刚认为, 集中监控管理需要的是业务标准与技术手段的配合, 而目前就全球来说, 普遍在这两方面都有差距。
首先, 业界相应技术手段较缺乏, 只有赛门铁克等少数厂商提供。其次, 多数用户在其内部业务标准和流程定义方面也存在问题, 比如业务属性描述等方面没有统一标准, 难以定义数据价值, 数据敏感性、留存期、拥有者、潜在使用者定义和标准缺失, 谁来用、怎么用、在哪些范围用、何时销毁等流程问题也缺乏定义。
“这样会带来很多问题, 比方说企业中存储量的攀升也是源于此。”李刚说, “现在用户基本上不删除数据, 他们自己有句话叫‘宁滥勿缺’, 怕将来出问题而不敢删。这都是由于缺乏很好的存储管理和安全策略而造成的。”
李刚认为, 集中式数据管理的启动其实不用太复杂, 可以从核心部分先入手, 将一些核心数据、敏感数据先集中管理起来, 然后慢慢逐步进行。他认为一开始就大规模全局梳理反而难以见效。
Data Insight可深入洞悉非结构化数据
正如前文所说, 实现集中式数据管理的前提之一是做好数据定义, 对敏感数据进行定义, 并识别这些数据的所有者。
但在Gartner研究副总裁Eric Ouellet看来, 识别数据所有权是个巨大的问题, 尤其是对非结构化数据来说, 而非结构化数据却往往包含了关键的业务信息。
“通过深入洞悉非结构化数据的使用情况, 企业将可以更好地认识自身战略上的差距, 可以用更好的工具和手段来确定企业的需求, 并且可以为实施数据治理方案做更充分的准备, 从而帮助企业降低风险。”Eric Ouellet认为。
赛门铁克的Data Insight技术则是市场上少数能够实现对非结构化数据使用情况进行深入洞悉的技术之一。它可帮助用户通过洞察非结构化数据 (如文档、电子表格和电子邮件等) 的所有权及使用情况, 提升对数据的治理。Data Insight技术还被整合到赛门铁克的整个安全和存储产品系列中, 为企业提供一个统一的数据治理方法。
结合了Data Insight技术的赛门铁克数据丢失防护解决方案可以帮助企业识别最关键的信息, 并通过自动识别数据所有者身份来简化数据清理和补救工作。Data Insight还可对数据的使用情况提供持续的监测与审核, 从而确保其与企业政策及法规遵从保持一致。此外, Data Insight还能监控谁曾读取或修改过哪些文件, 并将会通知信息安全团队和数据所有者, 哪些数据正面临怎样的风险。由于能够直观地了解哪些人正在读取和使用信息, 企业可以根据规则推断数据的所有权情况, 并更改访问存储数据的权限, 以防信息遭受侵害。
此外, Data Insight技术与赛门铁克的存储及信息解决方案的整合将使企业有机会优化其非结构化数据所耗费的存储成本, 并根据数据的使用背景和使用频率做出智能的备份和恢复决策。
link
敏感信息防泄露技术
当前主流的敏感信息防泄露技术主要有三类:控制类技术, 通过权限的设置, 对数据进行集中控制和管理, 并定期进行检查和事后审计, 实现对关键数据的传输进行控制, 防止未经授权的数据外泄;加密类技术, 主要包含文件级加密技术、磁盘级加密技术、硬件级加密技术和网络级加密技术;过滤类技术, 在内网的出口, 即网关处安装内容过滤设备, 这些设备可以分析HTTP、POP3、FTP、即时通信等常见网络协议, 并且对协议的内容进行分析及过滤。
集中监控和管理是一个目标, 并不是手段。目前运营商们关注目标, 却不知道该怎么做。其实这里面更重要的是, 在整个公司层面, 对数据要有从业务角度的理解和标识, 同时又要有管理流程和策略。这是第一步, 接下来才是真正去做端到端监控和管理。
数据集中管理 篇7
一、主要措施
(一) 新建国库业务虚网, 进行TBS服务器集中管理。
在中支局域网内建立国库业务虚网, 将中心支库及辖内所有县支库纳入虚网管理, 在此基础上, 将辖内县支库TBS服务器全部集中到中支核心机房集中存放管理, 网内对每台TBS服务器设置固定的IP地址, 县支行客户端通过2 M专线登陆各自服务器进行业务操作。
(二) 合理划分科技部门、中心支库及县支库三方职责, 实行异地监测。
按照“属地管理, 异地存放, 上下共管”的原则, 中心支库通过数据自动分发管理日志, 监测县支库是否及时将完整备份取回当地留存;科技部门负责定期对县支库TBS服务器进行巡检, 负责系统的升级维护, 保证系统安全运行;县支库负责操作权限管理、参数维护管理及日常业务处理。通过制定《柳州市辖区TBS系统及数据管理暂行办法》明确职责, 确保辖区TBS系统的稳定运行及数据的安全管理。
(三) 自编脚本程序, 实现TBS数据自动备份和恢复。
每日日终后, 县支库在客户端进行完整备份, 备份保存在服务器指定的目录下。每日零点, 按设定的计划任务, 脚本程序自动对存放在指定目录下的完整备份进行压缩处理后, 传输到TBS备份服务器上实行第三方备份保管。下一工作日, 各支库操作员先手动触发数据恢复快捷方式, 从TBS备份服务器下载完整备份数据包, 解压验证后自动在备机完成数据恢复, 操作员检查主备机数据一致后, 再进行初始化工作。
二、取得成效
(一) 确保全辖TBS数据完整。
通过TBS服务器集中管理和对系统数据安全管理新模式, 改变了过去在分散管理的模式下中心支库对县支库TBS数据管理的难题, 避免了由于支库工作人员疏忽未作备份带来的数据丢失情况发生, 中心支库通过监控各支库备份数据的下载情况, 保证了主、备机双备份及第三方备份数据的完整性和连续性。
(二) 确保业务处理的连续性。
日初始化要求做TBS系统主、备机数据的同步检查工作, 能保证异地主机和当地备机数据一致, 即使系统或网络出现故障, 县支库只要启用备机即可进行账务处理, 日常核算工作不会因故障而中断, 保障了国库业务处理的连续性。
(三) 提高国库TBS的应急能力。
集中管理模式的数据异地备份, 实现了TBS数据文件主机—备机—第三方 (异地) 的“三保险”, 提高了系统应对自然灾难和意外事件的能力, 在县支库主、备机同时崩溃时, 县支库可通过远程控制在中支预先准备好的备份服务器中安装CA证书, 10分钟内就能恢复正常业务。
(四) 减轻县支库的工作压力。
数据集中管理 篇8
目前, 计费数据大多采用省集中存储、数据库表结构的存储模式, 这种简单的表数据存储和存放方式给大用户量和大话单量数据的插入、查询和更新操作带来了巨大的系统开销, 应用系统的性能瓶颈往往表现在数据库操作的性能瓶颈上。
根据当下电信业数据集中化的主流发展趋势, 运营商如果想实现计费的全国集中, 首先需要解决的问题是计费数据的云存储和云计算问题, 否则的话, 则只有具备一个巨型计算机才能完成如此庞大的数据存储和计算任务, 换句话说, 如果不解决计费数据的云存储问题, 全国集中化就是不可实现的。
对于如何解决大量的计费数据集中存储问题?笔者认为, 首先通过分布式云数据存储实现分布式计算, 把负载分摊到有能力承载的主机上并进行分布式运算, 实现数据云化, 同时需要对计费数据进行多个维度的分类, 实现数据分布式存储和计算。
笔者将通过四个部分来论述如何将计费数据进行分割实现云存储和云计算:第一, 介绍计费数据分割的理论基础和基本原理;第二, 如何部署分割后的计费数据;第三, 讲述分布式数据对象的存取方法;第四, 分布式数据如何实现集中式的统计查询。
以三大维度分割计费数据
计费系统从最初的本地网已经发展到了如今的省集中, 并且还有了全国集中的发展趋势。但是, 在绝大多数情况下, 客户之间都是彼此独立且其关联度也很薄弱, 客户之间的关联可以在独立客户基础之上进行组群关联。比如从早期的专业计费系统的竖井结构、烟囱式的建设模式看, 各个专业计费系统之间都是独立的, 并且业务间也存在独立性。
对此, 我们将计费数据按照客户维度、时间维度和业务维度这三大维度进行分类, 并根据数据的分类进行数据的分布和分割。
按客户维度分布
将计费数据根据客户地域进行分布式存储, 客户组群可大可小且具有伸缩性, 通过全局逻辑客户视图和实际客户库之间的映射关系, 将全局逻辑客户分布到区域组群客户库中, 实现系统处理上的全局统一客户视图——存储层实现分布式存储, 运算层分布式运算。全局数据操作对象定位器实现分布式客户对象的注册、定位和存取功能。
按时间维度分布
区域内客户组群的计费数据还可以按照时间周期进行分布, 可分为当前帐期、上一个帐期、3个月内帐期、半年内帐期、一年内帐期和一年外帐期等阶段。不同阶段的数据、计算的频率、访问的次数都不同, 导致了存储方式和运算方式的不同, 这其中“当前帐期”数据运算量最大, 访问频率最高, 因此需要在内存中进行运算, 且还需要对数据近一步分开, 以降低数据集中度。
按业务维度分布
单个客户对象数据还可以再分为主客户数据、支付数据、统计数据和业务数据, 业务数据还可以根据业务种类分成客户业务1数据, 直至客户业务N数据, 这些数据都可以分布在不同的主机上分布计算。业务模版数据作为公共的基础数据可以单独主机进行参数配置和存储。
全局客户视图实现数据统一运算
全局逻辑客户数据按照客户维度、时间维度和业务维度三大维度进行数据切割, 并分布在不同的主机上, 因此不同的主机存储和内存中分布着不同的数据对象。
通过设计全局数据操作对象定位器定位和查找分布在不同主机上的数据对象, 可以形成一个全局的客户数据视图展现给上层应用程序, 实现分布式云存储和统一的数据运算 (全局数据操作对象定位器设计示意图如图1) 。
“逐层累计”实现数据的统计查询
以上设计的系统是针对单个客户的计算, 如果遇到需要对数据进行统计查询的情况时, 就将涉及到对所有客户的扫描工作。
这种运算在分布式数据情况下, 需要对各个子数据块产生的统计结果进行三层累积, 分别经过业务层次累积、时间层次累积和客户区域层次累积, 以产生最终的统计结果 (统计查询原理示意图如图2) 。