大集中模式（共11篇）
大集中模式 篇1
1. 现状及需求
1.1 现状
从2008年开始, 我市建立了重庆市主城范围内集中统一管理的城镇地籍数据库, 实现了城镇土地登记系统和数据的大集中, 中心数据库采用ORACLE数据库平台。
按照我市土地和房屋合一登记的管理模式的要求, 从2010年开始, 我市各房屋登记中心在全市集中的城镇地籍数据库的基础上, 结合原有的房屋登记系统, 以宗地为线索开展了房屋登记数据的清理工作, 建立了全市集中统一的城镇地房籍数据库和应用系统。
1.2 需求
由于我市实行的是大集中的数据管理模式, 中心生产数据库在出现故障的情况下如不能得到及时恢复, 将导致全市土地和房屋登记业务停顿, 因此必须在中心机房建立与生产数据库实时同步的数据库, 确保在生产数据库出现较长时间不能恢复的故障的情况下, 启用备用数据库, 保证业务的连续。
同时, 由于数据在市局统一存放, 各单位无数据库。而各单位由于对数据使用的需求千差万别, 无法在市局统一的数据库上满足其个性化的需求。因此需将市局集中的数据同步到各区, 既可实现数据的异地备份, 同时各区可利用改回备数据进行各类统计分析和专题利用。
2. 技术比较
目前基于Oracle数据库的数据同步技术大体上可分为两类:Oracle自带的数据同步技术和第三方厂商提供的数据同步技术。Oracle自带的同步技术主要有DataGuard, Streams, GoldenGate三种技术。第三方厂商的数据同步技术有Quest公司的SharePlex和DSG的RealSync。
本文重点就ORACLE本身提供的Data Guard, Streams, GoldenGate三种同步技术进行比较。
2.1 DataGuard技术
DataGuard是Oracle数据库自带的数据同步功能, 基本原理是将日志文件从原数据库传输到目标数据库, 然后在目标数据库上应用 (Apply) 这些日志文件, 从而使目标数据库与源数据库保持同步。
DataGuard为源数据库提供了两种日志传输方式, ARCH传输方式和LGWR传输方式, 其中, LGWR传输方式可实现同步和异步的传输。在这些日志传输的方式上, 可提供三种数据
保护模式, 即最大性能 (Maximum Performance Mode) 、最大保护 (Maximum Protection Mode) 和最大可用 (Maximum Availability Mode) 。
根据目标数据库对日志应用方式 (Log Apply) 的不同, 该技术可分为Physical Standby (Redo Apply) 和Logical Standby (SQL Apply) 两种方式。物理同步是指目标库通过介质恢复的方式保持与源数据库同步。逻辑同步是指目标数据库通过LogMiner挖掘从源数据库传输过来的日志, 构造成SQL语句, 然后在目标库上执行这些SQL, 使之与源数据库保持同步。
2.2 Streams技术
Streams技术是指利用挖掘日志文件生成变更的逻辑记录, 然后将这些变更应用到目标数据库上, 从而实现数据库之间或一个数据库内部的数据同步。
其实现步骤为利用Capture进程分析日志, 生成逻辑记录 (LCR) , 将其放入一个队列。Propagation进程将生成的逻辑记录发送到目标数据库中。目标数据库利用Apply进程将LCR应用到数据库中, 实现与源数据库的同步。
Capture进程一般位于源数据库, Capture进程将日志分析后生成的LCR, 然后再传输到目标数据库中进行应用。也可将Capture进程配置在目标数据库中, 源数据库直接将日志文件传输到目标数据库, 然后再利用配置在目标数据库的Capture进程进行分析, 生成逻辑记录再利用Apply进程进行应用。
2.3 GoldenGate技术
GoldenGate数据同步的基本原理是由Extract进程读取源数据库的事物日志 (Oracle中是redo log) , 将其中的变更操作 (insert、update、delete等) 按事务执行的顺序组合在一起, 直接将其发送到目标服务其上, 或者存放到Trails文件中, 然后由Data Pump进程将Trails文件传输到目标服务其上, 在目标服务器上Collector进程接收从源服务器传送过来的Trails文件, 最后由Replicat进程将Trails文件中的数据装载到目标数据库中。GoldenGate通过网络传输的数据量通常是日志量的1/4或更少。
以下为三者的优劣比较:
3. 技术选择
3.1 中心数据库与本地数据库同步技术选择
为避免中心数据库在出现长时间不能恢复故障引起业务的长时间停顿, 我们利用2004年购置的IBM P650小机建立了中心数据库的镜像数据库。考虑到中心数据库和镜像数据库均使用UNIX操作系统, 而且都在一个局域网内, 为方便配置, 我们通过DATA GUARD实现中心数据库与镜像数据库的数据同步。同时, 为确保数据数据的零丢失, 日志传输采用最大保护模式。
3.2 中心数据库与区 (县) 数据库异地同步的技术选择
由于我市市级集中的中心数据库安装在UNIX操作系统上, 而各区只能提供普通的PC服务器均安装的为WINDOWS操作系统进行数据回备, 而且单位数量有三十多个, 由于DATA GUARD只支持同平台的数据库之间的数据同步, 而且只支持最多9个的STANDBY数据库。同时考虑到中心数据库之间与其他单位的数据库分别处于不同地方, 之间用6M的网络相连, 正常工作时间还需通过网络传输大量的业务数据, 而通过STREAM的数据同步技术需占用大量的网络带宽。
由于中心数据库与区 (县) 数据库平台操作系统平台异构, 同时要实现一个中心数据库与30多个数据库的同步, 尽量减少因同步数据对网络带宽的占用, 考虑到GOLDEN GATE在这些方面都具有明显优点, 因此中心数据库与区 (县) 数据库的同步采用GOLDEN GATE的技术实现。
摘要：为确保在大集中数据管理模式下数据的安全, 本文就目前流行的ORACLE数据同步技术DATA GUARD、STREAM、GOLDEN GATE技术进行比较, 分析其优劣, 并结合业务需求, 就如何建立同地和异地的数据同步机制进行探讨。
关键词：数据库,ORACLE,数据同步,安全
参考文献
[1]郭伟华浅谈ORACLE数据同步技术《科技资讯》2010.2
[2]杨朝红, 宫云战, 桑伟前, 等.基于主从异步复制技术的容灾实时系统研究与实现.《计算机研究与发展》2003.40
大集中模式 篇2
---DSG容灾解决方案RealSync在长江证券集中交易系统备份系统的应用
DSG容灾解决方案RealSync在长江证券集中交易系统备份系统的应用，被中国计算机报评为“2004存储应用典范”！在中国计算机报存储世界8月容灾特刊，DSG发表了题目为“确保大集中后的数据安全”的文章，文章集中介绍了长江证券集中交易系统容灾备份系统的建设需求及DSG RealSync方案的建设目标和方案介绍。全文在中国计算机报“存储世界”2005 No.4（总第10期）发表。
【全文】
该项目为RealSync在证券行业的示范工程，作为证券行业集中交易系统的安全灾备系统，相比与其他行业的需求存在着非常明显的特征：对可靠性要求非常高、要求延迟尽量小、带宽有限交易查询分离等。DSG RealSync数据复制和备份解决方案在满足长江证券的业务需求上具有如下特点：支持1:2的复制模式，满足一个数据源复制到多个目标数据库的业务需求；备份数据库处于打开状态，通过该打开数据库可分担集中交易系统的查询和统计等业务功能；支持异构模式的数据复制，支持数据源、目标数据库之间采用灵活的软件和硬件平台，而无需要求相同的操作系统和数据库版本；在相对有限的2M带宽下实现了集中交易系统的远程容灾；数据复制实时性好延迟时间减少到秒级，降低了系统风险。
----整个方案详细介绍如下：
确保大集中后的数据安全
――DSG RealSync在长江证券的应用
用户概况
长江证券有限责任公司是一家致力于为客户提供全面理财服务的全国性金融机构，已在全国20多个城市设立了营业网点。长将证券从2004年开始着手全公司大集中交易系统建设工作，集中交易系统的目的是实现所属所有网点数据大集
中，涵盖长江证券目前现有业务，包括：AB股，基金、债券、三板、集合理财、银证通、多币种等。
用户需求
长江证券集中交易系统的业务需求在于：争创全国最佳创新证券公司；实现技术领先的经营策略；进行交易集中改造，将分散在营业部的交易系统改造为集中系统；将位于总部的集中交易系统复制到异地灾备中心；同时在同一机房内复制一套系统用于本地备份和数据查询；要求数据丢失控制在1秒以内。
随着证券集中交易系统的建设，对系统的安全性、可靠性和业务连续性方面也提出了更高的要求，因为该系统是长江证券的业务得以正常运转的前提和保证。因为证券交易系统是一种典型的“任务关键型”应用系统，涉及近百万客户，并且是一种实时交易行为，因此系统的安全与稳定性极其重要。长江证券提出了建设一套高效、可靠、投资回收比高的灾难备份系统，以确保系统数据的安全和灾难发生后数据的快速恢复。
作为证券行业集中交易系统的安全灾备系统，相比其他行业的需求存在着非常明显的特征：
第一，对可靠性要求非常高。证券集中交易系统涉及的资金量和客户数，要求必需保证系统数据复制的可靠性非常之高，必需做到数据非常精确。因此对于证券行业数据正确性的比较和修复就尤为重要。
第二，要求延迟尽量小。因为大量的实时交易只有被及时的复制到容灾系统上以后，才具有抵御生产系统上各种风险的能力。因此在证券行业复制的实时性上，必需能够做到秒级的延迟，并且尽可能的缩短。
第三，带宽有限。对于大量的证券用户来说，由于是租用电信线路，不可能像电信企业那样随便使用带宽，因此线路的带宽成本将是灾备系统运行的重要变动费用之一，并且是一笔非常大的开销。在目前来看，各大证券行业的带宽大都只能确保在2M左右，如何在如此有限的带宽上实现实时复制、减少数据延迟、加快数据同步将是一个非常重要的目标。
第四，交易查询分离。为了提高证券集中交易系统的高峰期业务处理能力，提高系统查询响应速度，提高客户服务质量，证券行业普遍要求将查询与交易分离，这样能够获得更大的性能价格比。
建设目标
针对证券行业的特殊需求，迪思杰（北京）数码技术有限公司推出RealSync容灾解决方案，该解决方案的主要应用目的是将一个Oracle系统上的数据实时复制到另外一个Oracle系统上。
DSG RealSync容灾解决方案的建设目标如下：
实现集中交易系统的容灾备份：数据复制的建设目标首先是实现对业务关键数据的容灾及保护，在不影响生产数据库性能的同时为生产数据库在本地或异地建立一份准实时镜像，以保证在生产数据库发生灾难时可使用容灾数据库进行业务接管和数据恢复。
利用容灾系统提供交易查询功能：在建设容灾备份系统的同时，能够充分发挥容灾中心的软硬件资源，提高灾备系统的投资回报率，因此建议该容灾系统不仅能够提供基本的灾备支持，更重要的是能够利用灾备系统的投资支持更多的业务类型，如将历史数据查询、统计报表、等模块部署到灾备系统上运行，从而实现负载分担。
在有限的带宽下保证复制的迟延性：DSG解决方案提供用户在2M带宽下，确保主要的交易数据延迟保持在秒级秒左右。
提供灵活的1对多的复制模式：因此大量的证券公司在建设容灾方案时可能选择在本地和异地各作一套备份，实现１对多的容灾备份架构，从而进一步保证系统的安全可靠性。
对生产系统的资源占用低：将集中交易系统上的CPU资源占用控制在5%左右。
解决方案
DSG作为数据管理平台解决方案的提供商，推出了包括数据安全、数据共享和数据生命周期管理等在内的全套数据管理解决方案。并且，长江证券也选择了
DSG RealSync作为其集中交易系统的复制和备份解决方案。RealSync 容灾解决方案提供对主流Linux和Unix等跨平台的Oracle数据库系统的复制和备份支持，在工作组和企业级的关键应用容灾支持上，成本更低、投资回报更高、结构更灵活、更容易实施和维护。在大型企业和数据中心级的关键应用上，RealSync是完全满足数据中心级每秒数千条交易量的实时复制支持、以减少数据丢失。同时，通过处于打开状态的备份数据库提供数据查询、统计报表等支持企业应用模块的重新部署。
长江证券集中交易系统容灾备份系统建设的结果如下：
本地复制――将集中交易系统的数据复制到局域网内部的系统上，可同时实现查询和本地业务接管的功能。这样可以提高高峰期业务的处理能力，提高系统查询的响应速度，进而提高客户服务质量、获得更大的性能价格比。
远程异地复制――将集中交易系统在广域网链路2M的环境下，远程复制到远程灾备中心，以避免在本地集中交易系统遭到破坏时，造成数据丢失、业务中断等灾难。
满足业务备份和恢复指标――要求灾难发生时数据丢量控制在最小范围之内，业务恢复时间缩短，减少对证券用户的交易影响。
关于DSG
DSGuardian Inc.公司，是全球领先的致力于数据存储管理的专业厂商，拥有先进的存储管理核心技术，提供数据存储备份和容灾复制等灾备软件产品及解决方案。其数据备份产品SnapAssure和异构热容灾产品RealSync以其功能强大、性能优越和性价比高等特点为企业关键业务系统的不间断运行提供保障，受到客户的广泛好评！
2002年8月，DSG进入中国，在中国北京设立全球战略中心、技术研发中心和支持服务中心，全面拓展中国市场。目前成功案例遍布中国的电信和金融行业，如中国电信、中国网通、中国联通和中国移动；银河证券、信息产业部等。
DSG（中国）数据容灾备份案例：
●中国电信：电信总部、江苏电信、重庆电信、江西电信、广西电信、新疆电信、青海电信、海南电信、贵州电信、甘肃电信、宁夏电信以及电信北方事业部、成都电信；
●中国移动：江西移动、广西移动、甘肃移动；
●中国网通：辽宁网通、周口通信、沧州通信；
●中国联通：广东联通、江苏联通、天津联通、辽宁联通、山东联通、陕西联通、四川联通、河北联通；
●政府机构：信息产业部（含浙江、江苏、陕西、黑龙江、福建、江西、甘肃、吉林、宁夏和重庆等信产部直属机构）、河北省地方税务局、上海市松江区财政局、广州公安等
●证券行业：银河证券、长江证券、国联证券；
扬州政务“不搞大集中” 篇3
“腰缠十万贯，骑鹤下扬州”。这是古人对繁华杨州的赞誉与向往。历史上的扬州曾经是全球十大繁华都市之一，地位堪比今天的纽约、巴黎。然而自近代以后，传统的水路运输受到公路和铁路的挑战，处于运河与长江枢纽位置的扬州盛世难再。“交通不畅以致信息闭塞，信息的闭塞让城市逐渐衰落。”
不过在20世纪90年代之后，扬州以信息化带动工业化的发展策略初见成效，扬州信息化建设的“12345”模式成为中小城市信息化建设的典范之一，一个新的扬州在长三角重新崛起。目前，扬州的信息产业占其GDP的比重将近6%，位居江苏省第五，列苏中之首，LCD、TFT、移动通讯等产业集群初具规模。
唐正元，现任扬州市信息化办公室副主任，过去是一名农业技术推广专家，他亲身体会了这些年来扬州信息化建设的变化。
不搞“大集中”
“扬州电子政务系统最大的特点就是不搞大集中、大集成，”唐正元对《互联网周刊》记者说，“我们没有打破原有的行政体系，而是以现有管理体系为基础。”
2002年12月24日，这是一个令唐正元记忆犹新的日子，当时他们刚刚有了“电子政务不打破原有行政体系”的想法，立刻引来了广泛争论，遭到了几乎所有专家的反对—当时以“南宁模式”为代表的集权模式是主流建设模式。
唐正元以城市应急指挥中心为例，讲述了“扬州模式”和“南宁模式”的不同。
南宁的集权模式整合了政府和社会所有的应急资源，成立专门的应急联动中心，由该部门代表政府全权行使应急联动指挥大权。这样的应急指挥中心由公安、消防、医疗、卫生等所有部门抽调人员集中组成，所有人员仍隶属于原行政机关，但“尽管集中到一个地方办公，工资、奖金还是由原来部门发。”
由于几乎重构了城市应急体制，与现有行政体制冲突比较大，不仅建设难度增加，投资也大。有紧急情况发生时，应急指挥中心的人员很难从全局的角度出发，考虑更多的仍是原来部门的利益。单一指挥层次上也不利于发挥职能部门的能动性，特别是传统应急反应部门的能动性—公安部门既不可能指挥得动医疗部门，税务也无法对消防部门指手画脚。投入了上亿元人民币的应急指挥系统，却很难避免“指挥不动”的情况发生。
但由于扬州是中小城市，市政府对行政体制调整没有太多的权力，现阶段也不可能有庞大的资源来重构应急指挥体系。“依托现有的行政架构，集中资源解决应急联动的实质问题，不失为明智之举，”唐正元表示。
扬州市的应急指挥中心由政府指挥中心和部门指挥中心（如公安指挥中心、交通指挥中心、消防指挥中心、急救调度中心等）两部分组成，并不打乱现有的行政管理体系。政府指挥中心“战时”侧重于重大事件的协调、决策和监督，建立预案，平时则侧重于应急事件的管理、预防和监测。而部门指挥中心侧重于对紧急呼叫的快速反应，先期处置。部门指挥中心还建有远程终端，主要是用于在网上快速接收指令并及时反馈，平时上传应急指挥的基础数据，在条件许可的情况下，还可以由公安统一接警，也可以成立专门的接警部门。
这样一来，一般的事件可以由部门指挥中心直接处理，重大事件通过网络自动被市政府的指挥中心捕获，市政府指挥中心可以联合各部门指挥中心和政府的其它部门共同处置。目前，扬州包括七个县、市、区和市公安、卫生、水利、安检等相关部门在内的36类到口信息已经接入了应急指挥中心，扬州的应急指挥系统也已开始全面测试。
唐正元说：“和其它城市动辄上亿元的投资相比，扬州的应急指挥系统实用、高效、节约。”其实，城市应急指挥系统只是扬州电子政务建设的一个缩影。2003年，扬州市信息化工作以推进信息化试点城市建设和国家863/3S项目为契机，以实施电子政务取得应用实效、实施信息化带动工业化、实施社会信息化让老百姓得到便利实惠为目标，形成了信息化建设的著名的“扬州模式（12345）”，即贯彻一条主线、解决两类问题、实现三级服务、采取四个机制、取得五种效益。
“不是工程，不是技术”
正是以“应用为核心”为基本立场，扬州市政府信息化的招标也与其它城市有所不同。2002年，扬州市政府首先做了方案招标，在经过三个月的调研确定方案后，才做项目投标。在全国300多家公司的竞标方案中，确定了东软软件公司的方案，东软也成为该项目的总集成商。
尽管这种招标方式被普遍认为过程太慢了，唐正元认为还是值得的：“正是因为有全国300多家公司来做方案投标，有专家进行方案评审，又经过三个月的调研，才能做到整个工程投资很小，效益很大。整个投资才1200万元，却建成了全国领先的电子政务系统。”对此，唐正元很自豪：“信息化的目的是应用，不是工程，不是技术。”
事实上，唐正元从农业技术推广专家到信息中心主任的经历，也印证了扬州务实的工作作风。唐正元当年在扬州所辖的一个县里做农业局局长时，首先抓的就是农业基础数据汇总、分析，并利用数据分析结果为农业生产服务。从农业信息化到政府信息化，唐正元认为数据共享是信息化应用的基础。
在扬州，尤其值得一提的是人口基础信息的共享。以往，人口信息分散在公安、劳保、税务等各个部门，在这种管理方式下，信息往往得不到统一，常会造成不法分子冒领养老金、骗取保险金、欠缴税款的现象。然而，各个行业之间的资源共享又会涉及各部门的利益，信息化领导办公室作为与公安、劳保、税务等平级的部门，无法用行政干预的手段实现数据共享。
人口基础信息库的建立将改变这种状况。2004年，由国务院信息化办公室、公安部、劳动保障部、税务总局、国家标准委等五部委联合启动的《人口基础信息共享试点》工作正式展开，扬州市是全国三个试点城市之一。通过将公民身份证号码、常住户口地址、死亡日期等信息进行汇总，并使用统一的数据交换代码实现资源共享，使各部门能随时监控公民的个人信誉记录、纳税状况等信息。
“即使是政府部门之间也是利益对等的关系。”唐正元说，“这样我们就可以用最准确的人口基础信息和工商、税务、劳保等各部门进行数据交换，实现信息共享了。”
扬州市政府考虑的是更深层次的问题，正如扬州市市长王燕文在“东软解决方案论坛2004(扬州)”上问的，“扬州有2500年的历史，有悠久的文化，有秀丽的风光，如何转换成生产力？”
大集中模式 篇4
针对电子政务数据大集中的模式, 以重庆工商局和重庆市涪陵区为试点, 建立了电子政务信息安全保障体系。
重庆市总结了一套系统工程实施的方法, 这个方法是由“三分析一筛选”和“123Y立方”的方法组成。“三分析一筛选”的方法是为了区分同属数据大集中模式但处于不同发展阶段的电子政务系统, 主要方法是“依次分析数据特征、业务特征和应用需求, 然后筛选安全保障措施”。而将信息安全风险评估的三个流程“资产识别”、“安全威胁分析”和“系统脆弱性评估”与电子政务信息安全等级保护的三个阶段“进行定级”、“规划与设计”和“实施、验证与运维”进行嫁接, 就是“123Y立方”的方法。
其创新点就是针对风险评估与等级保护的内在联系, 强化业务的重要性、安全危机验证的重要性, 以及系统评估对整个系统的影响的重要性。在具体实施的过程中, 重庆两家试点单位制定了分期、分批实现的计划, 利用风险评估的方法, 使试点单位真正达到安全风险可控的要求。
大集中模式 篇5
为了确保全员人口信息数据大集中的数据质量，根据《山西省全员人口信息数据大集中实施方案》和临汾市和侯马市关于做好信息数据大集中工作的通知要求，现就做好我乡全员人口信息数据大集中验收工作，制定如下方案。
一、验收的主要内容和标准
（一）人口信息
1、项目：包括总人口数、出生人数、死亡人数。此指标以村为单位进行核查。将人口计生部门采集到总人口和相关部门人口数进行比对。
2、质量要求：经过比对分析，如果人口计生部门采集的人口数和相关部门提供的人口数差异较大，误差超过5‰时要认真查找原因，必要时可重新入户核查、重新采集。清查核实过程中要求入户率达到95%以上，流动人口核查率达95%以上。
（二）已婚育龄妇女信息
1、指标：已婚育龄妇女录入率。以行政村为单位进行核查。
2、指标解释：已婚育龄妇女录入率指标录入数据库的已婚育龄妇女人数占全部已婚育龄妇女总数的比例。
3、质量要求：经过核查，对已婚育龄妇女录入率低于95%的行政村，要认真进行摸底排查，切实按照“村不漏户、户不漏人”的原则，重新入户采集。
（三）全员人口个案信息
1、指标：主要数据项准确性（率）和主要数据项完整性（率）。以行政村为单位进行核查。
2、指标解释：①主要数据项：全员人口主要数据项包括：姓名、性别、出生年月、户口性质、户籍地、现居住地、管理属性、管理属性变动时间、注销原因、注销时间、身份证号。已婚育龄妇女主要数据项除以上信息外还包括：婚姻状况、现有男孩数、现有女孩数、最小子女出生年月、最小子女性别、政策内外、当前避孕措施、当前措施时间、90年以来超生子女数、社会抚养费应征金额、社会抚养费实行征金额；②主要数据项准确性指录入数据库的个案信息的主要数据项与实际情况相符合；③主要数据项完整性指录入数据库的个案信息的主要数据项没有空填。村级核查时，要对个案信息主要数据项逐人逐项核查；乡级单位在进行核查时，要对主要数据项准确率和完整率进行核查。
3、质量要求：经过核查，对于主要数据准确率或完整率低于95%的行政村，要认真进行摸底排查，严格按照“人不漏项，项不出错”的原则，重新入户采集。
（四）逻辑关系信息
1、指标：主要数据项之间逻辑关系误差率。以行政村为单位进行核查。（通过单机版数据审核功能实现）
2、指标解释：按照新版单机版软件审核条件进行审核。
主要数据项逻辑关系误差率；（数据库中列出的10条逻辑关系错误的总条数）÷（数据库中已婚育龄妇女数×10）×100%。例如，某村共160名已婚育龄妇女，经审核，共出现40条逻辑关系错误，那么其主要数据项逻辑关系误差率=（40÷（160×10）×100%=2.5%。
3、质量要求：经过核查，对于主要数据项逻辑关系误差率高于10%的行政村，要重新逐户清查核实。低于10%的，要对有逻辑错误的户进行核查。
二、验收的方法和步骤
验收工作采取分级分批验收的办法，由下级向上级提出书面验收申请，然后组织人员进行验收。验收以行政村为单位，对已婚育龄妇女的抽查：2000人以上的村抽查率不低于5%；1000—2000人的村抽查率不低于10%；1000人以下的村抽查率不低于15%。
三、验收的具体要求
一是严格申报程序。凡认为能达到验收标准的，要写出书面验收申请。经过验收，对达不到验收标准的，要书面通知其重新核查登记。严格履行审核、把关、签字程序。
二是严格验收标准。验收坚持“宁可慢一些，也绝不降低标准”的原则，对达不到要求的人，坚决“回查、回登、回录”，决不因为赶进度而影响核查数据的质量。
三是严格奖惩兑现。将数据大集中验收情况纳入年度目标责任制考核。对验收中存在弄虚作假、瞒报、漏报影响数据大集中整体工作的，年底考核实行“一票否决”。
大集中模式 篇6
建设内容
山东国税网站是由省局统一对全省网站进行规划和改造,各县(市)现有网站全部迁移到省局网站平台重新建设,各县(市)在省辖市局网站上建网页,首页展现拥有相对统一的风格,所有管理维护工作在同一个系统后台进行,各级信息资源通过站间的共享、呈送、引用等多种方式实现共享。此外,在涉税业务查询、在线访谈、纳税咨询、互动信箱、政策法规库也实现了统一应用,减轻了基层的开发负担。对于网站安全规划方面,集中引进了强大的安全软硬件设备,顺利实现了各个应用、数据库的异机备份,实时监控到网络的运行和服务器的访问、攻击等情况,极大地提高了整个网站群的安全防范水平。
在栏目管理和维护方面,一是将推行政务公开作为网站工作的重要内容,依托网站进一步深化政务公开工作,针对实际情况变化,及时发布机构概况、涉税公告、文件通知、工作计划、收入统计、办税指南、行政许可审批、税务部门工作动态等内容;统一开发全省统一的政府信息公开平台,对政府信息公开目录、公开指南、公开年报、公开场所、监督投诉、各项公开制度规定以及依申请公开等,作了进一步规范,对主动公开的信息从编号索引到内容分类、公开范围、时限以及责任单位等都进行了明确。二是将网站作为纳税服务的重要平台,紧紧围绕税收中心工作,通过升级完善政策法规库、大力加强纳税咨询工作、积极开辟各类税收专题、努力丰富服务形式等措施,不断创新服务手段,加强税法宣传,开展纳税辅导,深化网上办税,有效推动了纳税服务水平的提升。三是充分发挥网站的桥梁作用,积极利用各种形式,进一步加强征纳互动:邀请省、市局领导、业务骨干走进网站“在线访谈”室,实时解答纳税人疑问,宣传税收政策;高度重视纳税人和社会公众通过局长信箱、举报投诉、意见箱等反映的意见和建议,积极办理各类来信;积极发挥网上调查的作用,面向纳税人和社会公众开展问卷调查,征集意见和建议;通过图文直播系统,对重要会议和活动进行网上直播,并邀请嘉宾开展网上现场评论;充分发挥网络手段,利用QQ群、博客等形式与纳税人开展交流互通。四是建立完善的管理制度,先后出台若干管理办法和通报考核制度,对网站的日常维护管理进行了规范,加强了对网站的管理力度,督促各级网站提升维护水平,积极引导各级网站的发展方向。
在安全保障方面,根据当前的访问情况配备了负载均衡设备,对提供静态网页访问的服务器进行访问分流,将局长信箱、纳税咨询、在线访谈等应用交互模块单独部署在专门的服务器上,部署了入侵检测系统和页面防篡改系统,数据采取“内网维护、外网展现”的模式,互动类应用采取内外网数据实时同步方式,通过网闸的摆渡来保证内外网数据的一致。
在组织和人员方面,山东国税成立了由分管局领导任组长,有关处室负责同志为成员的网站领导小组,具体负责研究、部署、协调网站建设与管理的重要事项,同时成立网站办公室,具体负责落实领导小组的各项工作部署,对各级网站进行规划、建设、维护和管理。目前,省局网站的专职管理人员有三名,各处室设一名网站联络员,各市局至少配备一名专职网站管理员,各市局相关科室、各县局配备相应的网站联络员。
在系统运行环境方面,站群体系采用的操作系统为linux,数据库为oracle,中间件为weblogic。
站群架构如下图:
建设亮点
一是大规模网站群省级大集中建设。山东省国税局采用政府门户网站群内容管理系统,对“山东省国税局内外网门户群”基础平台进行搭建,在此基础平台上集中建设包括外网门户网站、内部办公网站及各市局、税务机构子网站群。
二是内外网数据同步。为保证内网信息的安全性,山东省国税局采用了安全隔离网闸实现内外网的物理隔离,我们对内网门户办公平台的信息资源整合,通过内外网前置机处理方式,信息交换接口,完成实现了内网到外网的信息交换。
三是人性化的税务查询。山东省国税局门户网站提供的众多的查询项目,主要包括公告查询、通知查询、公用查询、专项查询、发票信息查询、申报情况查询、税款缴纳情况查询等,查询项目分别分布在不同的子站的不同页面中,入口较为离散。我们本次的建设将统一查询平台、多平台入口的耦合标准,并对表单提交与反馈进行格式标准化,从而实现用户人性化的查询,同时平台又具有充分的可扩展性。
四是个性化的网上办公平台。个性化的需求也成为具体办公人员所关心的内容,搭建高效个性化的办公平台也是本次项目建设中的重要需求。我们通过对内网信息资源整合,实现个性化信息展现;根据不同级别、不同部门、不同用户的需求,建立不同的办公门户平台展现信息资源,满足信息资源组织个性化需求。
五是税务内部所有业务系统的大集中。内网办公平台中,集成了税务内部所有业务系统,统一了内网的入口访问,所有信息资源整合进入信息平台,用户通过单点登陆统一入口访问授权信息资源,不用关心信息资源的形式和存在位置。
创新共赢,大集模式多元化 篇7
（一）“集超对接”推动大集商品进入超市
长期以来，超市系统门槛较高，中小企业受困于实力单薄、渠道不畅，很难进入超市营销渠道。而北京市商务委员会推行的“集超对接”活动，为各地参加大集的优质产品打开了超市之门。自2011年起北京市商务委员会在北京家乐福、华堂及顺义仁和石园大卖场、城乡贸易中心共举办10个省份19场次的“集超对接”活动，超市采购人员在大集上选择热销产品到“己方”门店内试销，并减免相关进场费用，让各地企业真正了解了自身产品在超市内的经营状况，从而调整各自的产品定位。这一创新举措获得了超市、参展商、经销商、消费者、主办方的认可，再一次实现了五方共赢的目标，丰富了首都市场。
（二）“各地精品大集”延长大集举办时间
为巩固大集成果，协助参加“各地商品大集”的企业进入首都市场，为企业打通市场流通环节提供帮助，同时也为北京市消费者购买大集热销商品提供便利，自2011年起，北京市商务委员会在新奥购物中心、城乡超市、顺义新世界百货、百联清城购物中心等商场、超市共举办了11个省份19期28场次“各地精品大集”活动。活动在大集结束后举办，延长了大集热销商品的销售时间，在不同区域同时举办，方便了北京各地区市民参与其中，选购大集热销商品。参展企业普遍增强了进入北京商超系统的信心。
（三）“畅想品牌展”及“行业大集”提升大集丰富性
大集中模式 篇8
项目建设背景
由于历史原因, 广东省农村合作金融机构电子化建设缺乏统一规划, 99家联社运行着6家不同开发公司的28套计算机系统, 信息化建设已经难以跟上其他金融机构的发展步伐, 而且存在着较大的操作风险和管理风险。主要表现在:一是大部分计算机系统比较落后, 人才缺乏, 管理意识和技术水平较差, 技术措施不到位, 系统隐患大, 极易发生系统事故;二是各地系统技术架构陈旧, 业务功能单一, 业务处理流程缺乏规范性, 安全漏洞大, 案件防范的技术水平低, 风险控制不严密;三是各地各自为政, 单个看投资严重不足, 整体看重复投资、重复建设严重, 造成全省IT资源的极大浪费;四是缺乏统一的品牌和形象, 不利于广东省农村合作金融机构的整体发展。2009年, 银监会下发了银监办[2009]269号文, 明确要求“各省级联社要对全辖的IT系统、监控系统进行全面检查, 作出评估, 针对缺陷和薄弱环节, 根据业务发展状况和风险管理需要, 借鉴大型商业银行和股份制商业银行的成熟经验, 提出升级改造方案或建设规划, 高标准地建立和完善综合业务系统。”因此, 数据大集中建设不仅是广东省农村合作金融机构业务发展的自身要求, 而且也是监管部门提出的要求。
建设原则和整体规划
根据广东省深化农村信用社改革试点领导小组对数据大集中项目建设的批复精神, 省联社党委明确了项目建设的基本原则, 即大集中系统必须具有相对的先进性, 同时要讲求实用, 符合广东省农村合作金融机构的实际;数据中心按国家A级标准建设;建设过程依法合规, 严格按流程办事, 能招标的项目一律实行社会招标;项目建设实行专业化管理, 聘请专业公司把关并对大集中项目进行整体规划, 总体上分为两个建设阶段。第一阶段建设三大应用系统, 即核心系统、前置和柜面系统、财务系统, 以满足日常业务处理需要。同时建设全省数据中心, 搭建全省网络系统和建立省中心主机硬件系统。第二阶段进一步完善核心系统功能, 同时建设一系列经营管理系统。预计项目总投资约12.65亿元, 总建设期5年。
项目建设概况
2007年4月末项目启动, 聘请了国际知名的法国源讯公司作为咨询公司, 委托省机电设备招标中心和志正招标中心作为招标代理机构。数据中心建设方面:2007年10月份经广东省政府批准, 购买大集中数据中心场地;2008年10月, 数据中心动工建设, 2009年6月末投入试运行。应用系统建设方面:2007年10月份选定TCS FS公司为核心系统承建商;2008年1月份选定北京先进数通公司为前置和柜面系统承建商;2008年9月份选定O racle公司为财务系统承建商;2009年3月财务系统上线, 目前已推广到66家联社使用。
2007年12月至2008年2月, 核心和前置厂商陆续进场后, 开始实施系统建设, 由于我们引进的“洋核心”与国内前置系统的结合尚属首次, TCS FS的BA N CS系统没有技术文档, 前置厂商读不懂核心厂商的设计意图, 我们在迷茫中摸索了半年。系统安装后, 我们在BA N CS系统上不断测试、摸索, 逐步掌握了其内在规律。2008年10月份, 项目建设逐步走上正轨。
数据移植也碰到了严峻的挑战, 2008年到2009年上半年, 数据移植摸索了一年多, 每次移植都是问题成堆, 技术的、历史的、新会计准则等方面的问题交织在一起, 困难重重, 2009年的7, 8月份才逐步找到了可行的方法。在近两年的时间里共移植了200多版数据, 每次问题都在不断减少, 每次移植都要人工干预才能完成, 只有上线的那一次没有人工干预, 顺畅完成。
系统特点和功能
首先, 大集中系统具有产品化、平台化、参数化、业务处理分工专业化等技术特点, 相对于国内传统的综合业务系统, 具有较大的灵活性和扩展性。其次, 大集中系统可以提供满足广东省农村合作金融机构业务需求的业务功能 (如建立全省卡积分功能, 支持各种卡业务的市场营销) , 甚至包括国外银行的先进业务功能 (如集团客户现金管理等功能, 帮助客户提高资金利用率和资金收益) 。第三, 可以建立全省统一的业务功能规范, 严格执行有关法律法规, 做好分级授权, 加强风险管控, 堵塞操作漏洞, 防止案件发生。第四, 利用大集中系统能迅速推出符合市场需求的各种金融创新品种, 参与市场竞争, 有力促进广东省农村合作金融机构的业务发展。总之, 数据大集中是化解广东省农村合作金融机构计算机风险最根本的措施, 是规范业务操作, 提高技防水平的有效途径;能为广东省农村合作金融机构金融创新、业务发展提供广阔的空间;能降低广东省农村合作金融机构的经营成本、提高经营效益, 极大地改善全省农村信用社的经营现状;将有利于创立广东省农村合作金融机构统一品牌, 增强整体合力, 促进全省农村信用社的发展。
工作体会
回顾项目开发和试点上线工作的每一个环节, 我们深深体会到成功来源于以下五个方面:
一、省联社党委的科学决策和高度信任, 是项目成功的关键。省联社党委思想统一, 高度重视, 调动一切可以调动的资源, 支持大集中工程, 特别是在项目建设过程中的每一个重大节点上, 省联社党委都能做到及时、科学的决策, 敢于承担风险和责任;省联社党委充分尊重知识、尊重科学和尊重人才, 充分发挥专业人才在重大技术问题决策中的作用, 信任项目组的分析和判断, 信任下属在职权范围内独立处理问题的能力, 从而保证了项目的专业化建设和管理。
二、纪律严明, 是项目成功的保证。为做好项目建设工作, 我们从作风建设、廉政建设、工作纪律等各方面完善制度、规范程序、讲究实效, 保证了项目的顺利开展。特别是在廉洁纪律方面, 项目建设严格按流程办事, 有标准的、能招标的项目一律实行社会招标, 并对招标过程进行全程监督;在项目建设过程中, 严格控制经费支出;在资金使用中, 加强财务管理, 严肃财经纪律, 严把监督审核关, 力求“花最少的钱办成最大的事”。
三、精诚合作的团队精神, 是项目成功的前提。在项目建设过程中, 参建各部门、各单位干部员工树立了精诚合作的团队精神和大局意识。各岗位紧密配合, 协同作战, 真正做到了“有任务不推诿, 有问题不扯皮, 有责任不逃避”, 确保了各项工作衔接有序。
四、坚持项目建设的绝对主导权, 是项目成功的基石。在学习和吸取其他商业银行建设数据大集中工程成功经验的基础上, 我们通过严格掌握和控制项目建设进度, 要求合作公司严格按照我们的思路配合好各项工作等措施, 保证了工作的整体性、决策的科学性行动的快捷性和实施效果的精确性, 避免了多走弯路。
五、试点联社的鼎力支持, 是项目成功的条件。中山联社与省联社保持高度一致, 最大限度地提供人、财、物的支持。对系统出现的漏洞和问题绝不隐瞒, 毫无保留地提出了很多关键性的意见, 促使很多难点问题及时得到了解决。面对繁重的工作任务, 中山联社通过周密的项目计划、紧凑的进度跟踪、及时的问题处理、定期的项目例会以及严格的考核等管理手段, 高质量、出色地完成了任务, 树立了项目建设的典范。
大集中模式 篇9
(一) 会计核算管理模式高度集中
ABS时期, 中央银行的数据分散存于各地市中心支行A B S之中, 全国共341个中心支行, 每年就要形成341本账, 难以为货币政策和金融稳定提供及时、有效的决策支持。ACS上线后彻底改变这种数据分散的局限性, 通过业务流程再造, 基层人民银行实际上已成为分布在不同区域的业务延伸柜台, 其账务处理的独立性被彻底颠覆, 会计业务剥离至总行业务处理中心, 分支行网点只需受理凭证和影像扫描, 这种前后分离的模式最终将ABS全国341本账改造为ACS全国一本账, 实现会计核算扁平化管理, 从而达到业务数据和信息资源全国集中, 增强了数据分析的时效性和准确性。
(二) 会计业务处理流程简化
ACS系统充分利用劳动分工原理, 通过合理分解操作流程, 将前台受理和后台处理严格分离, 各地营业网点仅作为前台受理业务, 只需将商业银行的纸质凭证扫描上传至业务处理中心, 由外聘人员集中录入、核对会计凭证要素, 进行业务集中处理。较之ABS, 这种业务处理流程有着颠覆性的变化, 从而大大简化了基层央行会计业务处理流程。
(三) 岗位设计更为灵活
较之ABS系统而言, ACS系统在岗位设置方面极大地减少了岗位人员。会计核算中心由网点柜、联行柜、综合柜三柜并存转化为前台网点, 不再设立综合柜, 联行柜。地市以上营业部门只需设立业务受理岗、网点主管岗、综合管理岗、会计主管岗四个岗位;县支行仅需设立业务受理岗、网点主管岗两个岗位, 从而, A C S系统有效解决岗位设置的刚性与基层人员总体较少的突出矛盾, 可以根据业务量灵活调整岗位, 大大减少了系统岗位设计对人力资源的依赖性。
(四) 监督实现同步跟进
ABS模式下, 事后监督主要通过中央银行会计凭证影像事后监督系统 (IAS) 与ABS共享服务器, 采取复核式比对的方法实现监督职能, 导致事后监督滞后, 事中监督控制不足等问题。而在ACS模式下, 事后监督子系统与ACS系统直接连接, 将风险控制关口前移, 实现监督进程与核算流程同步进行。
二、数据大集中趋势下基层央行会计工作面临的挑战
(一) 会计人员素质要求更高
ACS系统上线后, 会计人员只需扫描凭证, 不需进行账务处理, 会计工作看似变得轻松了, 其实不然, 全新的ACS运行模式与传统会计模式的截然不同, 各网点受理的业务质量高低直接影响全国的核算运行和业务安全。这种质的变化反而对基层央行会计工作, 特别是柜面监督提出了更高、更严、更新要求。陈旧的知识、单一的技能已不能适应数据大集中的需要。
(二) 会计管理职能增强
A B S时期, 受基层行会计人员限制, 有的会计人员长期处于一个岗位, 有的会计人员身兼多岗, 随着A C S系统的上线运行, 有效地解决了基层会计人员与岗位繁多的矛盾, 基层会计人员从繁冗的操作岗位解脱出来, 更多地需要从事管理、综合类岗位, 基层会计职责不但没有弱化反而进一步加强, 必须遵循服务与管理并重、寓管理于服务之中的原则, 多措并举, 认真履行会计管理职责, 提高服务水平, 完善风险控制措施, 确保资金安全。
三、数据大集中趋势下对基层央行会计工作的几点建议
(一) 统一思想, 转变传统的会计工作理念
A C S系统的上线对营业部门带来的最直接的变化之一就是岗位设置和人员需求减少, 原有会计工作岗位和人员随着新系统的变化必然有较大的调整和改变。2014年总行下发《关于调整中国人民银行地 (市) 中心支行内设机构设置的指导意见》文件, 意在优化资源配置, 强化对外履职, 提升履职合力, 地 (市) 中心支行营业室与支付结算科、反洗钱科合并一个科室。业务上的变化及内部科室的从组调整, 对一线会计人员尤其是基层人民银行会计人员在过渡期的思想上造成较大的影响, 甚至会出现人心不稳, 消极工作的局面, 因此, 应切实开展多层次的职工思想教育活动显得尤为必要, 畅通思想交流与沟通路径, 引导职工树立正确的认识, 激发职工的工作积极性和主观能动性, 在实践中总结出一套科学化, 人文化的管理模式, 履行好人民银行职能, 创造性地开展各项工作。
(二) 学无止境, 继续开展会计人员再教育活动
为了适应数据大集中后的会计业务处理流程变化, 人民银行分支机构, 尤其是基层行会计工作岗位设置及人员都发生了变化。营业网点会计人员变成办理柜面业务的一般操作人员, 已不是传统意义上的会计人员。而一名合格的会计人员不仅需要具备一定的思想素质, 具有较强的工作责任心和风险防范意识, 同时还应拥有扎实的专业基础知识和良好的核算操作技能。随着会计业务不断创新、核算系统不断更新, 有针对性、有层次地开展会计人员继续教育活动显得尤为重要。因此, 建议开展形式多样的继续教育, 以提高会计人员业务素质。同时, 各级行应当对会计人员给予更高、更多的人文关怀, 以促进会计人员的职业认同感、归宿感。提供职业发展空间与平台, 打造会计文化、团队文化, 增强会计人员的集体意识, 全面突出人本建设, 激发会计人员的工作积极性。
(三) 与时俱进, 注重复合型会计队伍建设
随着社会经济的发展, 单一的技能已不再适应A C S的需要, 数据大集中对基层会计人员提出更高的要求, 会计人员都应直面数据大集中这一挑战, 由操作型向复合型人才转变, 拓展自身的综合能力, 具备较高的理论水平和业务处理能力, 能够发现并控制业务流程、内部控制的薄弱环节, 具备对下级行进行会计业务的检查、辅导能力等, 努力向复合型会计人才目标靠近。
参考文献
[1]董艳芬.ACS上线对事后监督的影响及建议.金融参考.2014.
[2]蒲慧慧.中央银行会计业务集中处理系统建设与管理的思考.武汉金融, 2014.
大集中模式 篇10
根据人民银行信息化发展实现应用系统整合和数据共享的总体思路, 近几年来, 人民银行已经先后实现了货币金银管理系统、金融统计调查系统、征信系统、国库核算类系统、中央银行会计核算系统等重要业务系统和邮件系统、人事信息系统、防病毒系统等系统的数据集中及整合。数据集中后的基层央行IT系统现状如下:
(一) 中心机房服务器群规模迅速缩小, 科技部门系统维护的工作量减少
随着数据大集中的推进, 基层央行撤消了原来的信贷登记系统服务器、国库类服务器以及中央银行会计核算类服务器。服务器的撤销减轻了基层央行科技部门的日常运维、数据管理、系统升级等工作量。
(二) 基层央行科技部门的工作重点发生变化
在数据大集中前, 基层央行科技部门的主要工作是保障各个重要业务系统的安全稳定运行, 在数据大集中后, 形成了以总、分行为数据中心的业务格局, 各个业务系统的操作通过网络进行, 网络安全和客户端安全成了基层央行科技部门的重点工作。
(三) 在人民银行争先创优背景下, 基层央行各业务部门在现有的业务系统体系下结合实践开发创新系统的需求增加
业务需求不是一层不变的, 基层央行业务部门作为业务系统的操作者和实践者, 对业务需求的变化和改进最具发言权。在争先创优的政策鼓励下, 基层科技部门也会投入更多精力配合业务部门实现创新业务系统的开发。
二、数据大集中下基层央行主要IT风险
数据大集中改变了基层央行IT部门的工作重点, 同时也使得IT风险不断变化。结合基层央行现形势下的实际工作, 基层央行数据大集中后面临的主要风险有:
(一) IT风险管理工作流于形式
自2007年以来, 人民银行一直在开展信息安全风险评估工作。此项评估要求人民银行各级机构通过对机房环境、网络安全、应用安全、保密技术、信息安全管理、安全运维等几方面进行自查评估并定时整改。整体上来讲, 信息安全风险评估囊括了人民银行IT系统的方方面面, 从管理、运维、审计等多个角度促进了IT系统的不断完善。但是, 信息安全风险评估执行多年来, 已经成为了一项流于形式的考核工作。多数基层央行除了在第一次评估时投入了较多的精力, 在一年一度的信息安全基线工作中, 没有认真核实当下信息安全风险点的变化, 对IT风险管理工作不够重视。
(二) 网络安全风险问题突出
数据大集中后基层央行的网络成了IT部门保障的重点, 但就目前来看, 基层央行网络风险问题是IT系统风险中最突出的。
第一, 基层央行网络信息安全意识仍然处于被动的封堵漏洞状态, 网络监测、防护、响应、恢复和抗击能力较弱, 网络信息安全防范机制有待提升;
第二, 基层央行网络安全管理水平不高。对于基层央行特别是县市支行, 缺乏专业的网络管理人员, 一方面, 网络维护人员的风险防范意识较差, 另一方面, 网络维护人员缺乏网络安全相关知识的系统培训, 知识结构相对老化, 无法正确把握网络系统中存在的安全问题;
第三, 网络客户端的安全隐患仍然存在, 虽然人民银行对网络客户端实施了病毒防护、软件补丁升级控制等操作, 但是不能防范由于内部人员违规操作、人为破坏等因素造成的网络风险。
(三) 客户端隐患严重
一直以来, 基层央行客户端的操作系统和应用软件无法正版化是困扰基层央行科技部门的大问题, 直至近几年, 总行实施集中采购, 操作系统正版化才逐步得到解决。但是客户端隐患仍然严重, 举两个例子来说, 基层央行无法使用正版的WINDOWS7系统, 一旦安装该系统, 人民银行非法外联系统就会报警, 显示该机器有非法外联行为;微软已经停止了对OFFICE2003的技术支持, 但基层央行的大部分机器仍然使用该软件。
(四) 新系统开发缺乏控制
由于数据大集中, 基层央行业务部门对自身业务的需求大多数是通过本级科技部门开发新系统实现。为了提高系统开发标准化和软件开发质量, 人民银行科技司发布了《中国人民银行软件开发规范V3.3》, 作为各级人民银行科技部门的开发指引。对于基层央行, 系统开发存在的主要问题有:科技力量有限, 系统开发过程中使用的相关技术可能不符合安全指引;对于有共性需求的小业务, 各地存在独自开发、重复建设的问题;缺乏规范的控制措施检验基层央行自行开发的系统。
三、数据大集中下基层央行主要IT风险控制
针对基层央行现阶段的主要IT风险, 建议主要从制度、人员、监督等几方面加强控制。
(一) 加强风险认识、完善IT风险管理制度
基层央行应该正确认识IT风险, 不断完善IT风险管理制度。在人民银行信息安全风险评估的基础上, 制定人员管理、岗位管理、网络管理、应用管理等多方面的安全管理规范指引, 对可能出现的风险问题进行细化并通过完善应急预案来保障IT系统安全。
(二) 加大基层央行科技人员培训力度
基层央行特别是县市支行的科技力量不足是制约基层央行技术发展的一个瓶颈。基层央行应加强科技人员培训力度、提高科技人员素质, 一方面组织基层科技人员积极参加上级行推广的业务应用系统培训, 可以及时了解业务系统使用中的风险管理要点, 另一方面, 上级行定期组织科技专业知识培训包括网络管理、安全防范、软件开发等, 及时更新基层科技人员的知识结构, 增强技术人员发现安全问题并处理问题的能力, 适应央行信息化发展的工作需求。
(三) 上级部门加强指引和监督
在数据大集中下, 总行的软件开发规范、分行的网络运行管理规定等都是对基层央行IT技术管理的有效指引。除了将指引通过文件形式下发到基层央行外, 上级行应该建立奖惩制度, 通过审核、监督等行为督促基层央行实现IT风险有效管理, 使得规范、指引落实到位。同时上级部门也可以通过调研、实地考察等手段收集基层央行IT风险工作中的要点、难点, 提供合理的建议帮助基层央行解决IT风险问题。
摘要：近几年来, 随着我国信息化建设的不断发展, 人民银行逐步实现了业务系统的数据集中。数据大集中后, 基层央行科技部门的重点也随之发生了变化, 从以前的系统维护、数据管理转移到系统的运行管理和网络管理, 基层央行的IT风险点也在变化。本文将结合基层央行实际, 概述数据大集中下基层央行的IT主要风险, 并提出风险控制的相关建议。
大集中模式 篇11
1需求分析
房地产管理系统要全面反映相关纳税人信息、项目信息、 税源信息等基础信息和日常管理、检查清算、比对分析、统计查询、后续管理等税收征收管理信息。房地产项目类型主要包括土地使用权转让、建筑安装、商品房销售、二手房转让、房屋出租、纳税人登记等六个方面[4]。
1)土地使用权转让。土地使用权转让的功能主要包括土地使用权项目信息采集、土地使用权项目立项、征免政策审查、 税源管理、销售不动产发票开具和项目信息的修改、变更及查看等基本内容。
2)建筑安装。建筑安装以单个项目作为管理对象,全面归集建设单位和施工企业(纳税人)相关基础信息,同时以施工企业申报的项目信息作为计算相关税源和日常管理依据,以从建设、规划等相关部门采集的涉税信息作为项目的比对信息。家居装修作为建筑安装税收管理中一个特殊的项目,在建筑安装项目内单独建立项目管理信息。
3)商品房销售。商品房销售主要功能包括商品房销售项目信息采集、商品房销售项目立项、商品房销售(预售)情况登记、税源管理、预售购房款专用收据开具、销售不动产发票开具和税收结算等基本内容。
4)二手房转让。二手房转让的主要功能包括二手房交易项目信息采集、二手房交易项目立项、征免政策审查及税收优惠审查、税源管理、销售不动产发票开具和项目信息修改、变更及查看等基本内容。
5)房屋出租。房屋出租主要功能包括房屋出租项目信息采集、房屋出租项目立项、税源管理、租赁业发票开具和项目信息修改、变更及查看等基本内容。
6)纳税人登记。其主要功能包括增加、删除房地产纳税人资金来源信息、纳税人信息登记表等基本内容。
2基于大集中系统的房地产税收管理系统设计
省级大集中系统是运行多年、十分稳定的税收征管管理系统,新开发的房地产税收管理系统应该沿用大集中系统已有的成果。因此,本系统沿用省级大集中系统的架构,即采用基于J2EE技术的B/S客户端,基于MVC的分层体系架构,基于TUXEDO中间件技术的C/S客户端,数据库采用Oracle大型数据库[5,6]。房地产税收管理系统整体系统框架如图1所示。
各层所采用的技术及其实现功能介绍如下:
1)展示层。展示层在展示风格与操作习惯上要与总局业务工作门户保持一致,且要基于省局业务工作门户的基础框架和应用门户集成规范实现。展示层采用HTML、CSS、Java S cript、Active X、Portlet技术实现。
2)交互层。主要包括统一业务办理接口、访问控制过滤器、流量控制器、接入管理和会话管理等五个部分内容,使用Spring作为交互层服务组件的基础容器,使用Struts框架和Servlet技术实现各系统与界面逻辑的交互,使用CXF框架实现对外的Web Service服务,使用Java Bean实现控制层的组件逻辑。交互层采用Servlet、Spring、Struts、CXF、Java Bean技术实现。
3)业务层。主要包括实现土地使用权转让、建筑安装、商品房销售、二手房转让、房屋出租和纳税人登记等六个方面的业务功能。由于业务组件是可重用的Java Bean组件,因此,如有特殊访问协议要求的业务组件,可通过EJB、JMS扩展框架将Java Bean封装的业务组件接口暴露出去,对数据库层的访问统一采用My Batis组件及基于My Batis二次封装的组件。业务层可采用Spring、My Batis、Java Bean、JMS、EJB技术实现。
4)基础框架层。基础框架主要包括协同消息管理、系统管理、权限管理和用户管理等四个方面内容,它是基于有着多年开经验的公共基础组件和根据项目要求定制开发的公共基础组件。基础组件包括基于Java源码调用的Java Bean组件和基于SOA技术封装的公共构件两种。基础架构层主要采用Java Bean、Java Script、HTML、CSS、JMS、EJB等技术实现。
3结束语
房地产税收管理是各级政府都非常关注的涉及房地产税收的工作平台,本文在分析房地产税收的业务需求的基础,提出基于大集中系统的房地产税收管理系统的整体系统框架,并对该系统框架的功能模块进行了详细的介绍。下一步的工作中,我们将致力于实现该系统,并运用到实践中。
摘要：分析房地产税收存在的问题,提出基于大集中系统的房地产税收管理系统的设计思想,并进行系统的需求分析,提出系统的整体架构图,为我国税收信息化建设提供可供参考的建议。