编者语:
　　 分析了当前制约我国政府行业信息化建设进程的关键因素在于“缺乏一个在对业务战略和流程进行充分分析和理解的基础上，进行信息化顶层设计的架构”；介绍了美国联邦政府组织架构FEA2 和英国电子政务的e — GIF 两种成功的架构模式；并提出了我国应“明确一个权威的官方机构主导建设”、“构建我们自己的顶层设计架构”、“建立详细且可操作的表层业务准入及评价体系”及“通过成功的实施体现应用支撑平台的核心价值”来规划我国的政府行业信息化整合之路 
　【摘要】分析了当前制约我国政府行业信息化建设进程的关键因素在于“缺乏一个在对业务战略和流程进行充分分析和理解的基础上，进行信息化顶层设计的架构”；介绍了美国联邦政府组织架构FEA2 和英国电子政务的e — GIF 两种成功的架构模式；并提出了我国应“明确一个权威的官方机构主导建设”、“构建我们自己的顶层设计架构”、“建立详细且可操作的表层业务准入及评价体系”及“通过成功的实施体现应用支撑平台的核心价值”来规划我国的政府行业信息化整合之路。

　　【关键词】电子政务；信息化；应用支撑平台；顶层设计

　　当前政府行业信息化建设中，随着应用水平的逐步提高及应用目标的提升，整合已经成为了一个热门的话题，但究竟如何进行整合？整合的核心价值是什么？整合如何才能避免走弯路？就这些问题，笔者提出一些自己的想法，并在此基础上，进一步提出基于应用支撑平台的集成化核心业务解决方案。

　　一、政府行业信息化建设的瓶颈

　　与所有的信息化系统建设一样，政府行业的信息化建设大致可分为4 个阶段：第一阶段为初步的电子表格阶段，解决信息数字化的问题，使纸质数据变为电子数据；第二阶段，为单一系统建设阶段，解决单一业务的信息化处理，解决替代手工作业的问题；第三阶段，为系统互联阶段，系统引入了局部的业务处理流程，部分系统之间进行有限的数据交换，解决局部信息交换通畅的问题；第四阶段，为一体化建设阶段，在这个阶段，将要实现系统的结构统一、数据共享、流程整合及业务协同等目标，并且要实现数据资源的再利用。

　　当前的政府行业信息化建设，笔者认为正处于从第三阶段到第四阶段的关键转轨期。这个转轨期不同于前几个阶段的转变，应该说是一次量变到质变的过程。对于政府行业信息化建设过程中，哪些问题是制约系统进一步提升的瓶颈，说法各异，以下是一些比较常见的说法：“信息孤岛说”，“重复建设说”，“技术落后说”，“应用水平不高说”，“数据口径不统一说”，等等。综合国内外信息化建设的经验及教训，可以认为，当前制约信息化建设进程的主要问题，是缺乏一个在对业务战略和流程进行充分分析和理解的基础上，进行信息化顶层设计的架构。

　　二、当前系统整合及应用支撑平台建设的一些误区

　　（一）把整合当做目的，为整合而整合

　　由从前分散在各个业务部门中面向职能的系统，转化到今天整个政府行业范围内面向流程的管理级信息系统，从而有效支持管理层提升管理水平，增强科学执政能力，这是系统整合最根本的目的。有些人错把建设信息系统或者进行系统整合本身当成政府行业信息化的目的，还是没有意识到信息化系统的整合是为了满足和适应管理的需求和变革，因而造成了为整合而整合，把整合当作目的的情形。

　　（二）整合不得其法，头痛医头，脚痛医脚

　　都知道当前政府行业信息化的关键是在于整合，但究竟怎样整合，却没有好的解决方案。造成这个局面的很重要的原因，就是没有找到当前信息化建设的关键瓶颈，因此，头疼医头，脚痛医脚，在所难免。

　　（三）看上去很美的一体化大系统方案

　　政府行业信息化是一个庞大的系统工程，但某些公司为了迎合部分管理层短时期内希望解决信息化进程中所有问题的急切心情，不从科学规划的角度出发，而是从市场利益考虑，匆忙推出一些所谓的一体化大系统方案。但在真正实施的过程中，没有哪个系统是特别成功的。笔者认为，虽然我国的政府行业信息化建设进行了不少年头，但与国外成熟的信息化建设都经历了数十年的历程相比，尚处于初级阶段。在这个阶段，盲目地追求大而全是不恰当的。

　　（四）谁都认为自己可以做应用支撑平台

　　“应用支撑平台”是数据标准、业务标准和技术标准的承载体。平台作为3 个核心标准的

承载体，任何公司都没有足够的权威性主导平台的开发，特别是主导支撑平台的3 个核心标准的制定工作。必须在一个权威的官方组织主导下，才能够顺利进行。

　　（五）平台建设有过分追求“完美”的倾向

　　提到“平台”二字，人们往往与“通用”、“定制”这些字眼联系在一起。因此，平台的建设往往容易走入极端，追求过分的“完美”，业务定制、流程定制、权限定制、报表定制，等等，都可以通过应用支撑平台定制出来。但笔者认为，在技术能力达不到一定高度的前提下，过分地追求技术上的完美是不合适的。

　　三、国外一些成功的政府信息化整合经验

　　（一）美国联邦政府组织架构F E A

　　2002 年，美国预算管理办公室（O M B ）根据“联邦政府组织架构框架”的基本精神，提出了“联邦政府组织架构”（Federal Enterprise Architecture，FEA），并为此成立了“FEA 项目管理办公室（FEAPMO ）”。FEA 的目的是将整个联邦政府所有机构的错综复杂的关系当作一个大型的组织系统，根据信息化和电子政务的基本规律，大胆地规划网络环境下的全新的联邦政府行政管理体系（参见图１）。

（二）英国电子政务的e — GIF

　　2005 年3 月18 日，英国内阁办公室推出了英国电子政务互操作框架（E-Government Interoperability　Framework,E-GIF）最新版—— 6.1 版。E-GIF6.1 的主要内容包括互操作的政策与机会、技术政策、实现支持、管理流程、变化管理、遵守E-GIF。

　　四、从国外先进电子政务模式中得到的启示

　　（一）由权威官方机构进行主导

　　美国的联邦组织架构（F E A ）由预算管理办公室（OMB ）直接主导建立，并为此成立了专门的FEA 项目管理办公室（FEAPMO）。英国的E-GIF 则是由更高层的内阁办公室主导规划和建立。虽然国外有很多管理软件业的巨人，比如SAP、ORACLE 等，但没有哪个电子政务的整体架构及行业标准是由这些企业主导的。这些软件巨人的定位就是如何用自己的软件去适应这些政府主导的构架和标准。因此，我们得出的启示就是，政府行业的电子政务工程必须由权威的官方机构进行主导，而不是某家公司。

　　（二）有顶层的架构体系

　　从以上对美国FEA 及英国E-GIF 的简单介绍我们可以看出，国外先进的电子政务体系均强调顶层的架构体系，都是从梳理业务流程及绩效目标为切入点，而技术及数据仅仅是底层的支撑, 这正是我国电子政务所忽略的。虽然我国也常提出一些整体规划，但由于过多地强调系统实现及技术架构，往往不具有长期稳定性，起不到持续指导信息化建设进程的目的。

　　（三）重点在规范及标准建设

　　国外的电子政务架构体系都强调顶层架构设计，将重点放在规范及标准的模型建设上。这些规范及标准主要包括绩效模型、业务模型、数据模型及技术模型等。而在这些模型中，业务模型又是其中最重要的，业务模型建立的原则主要是强调对业务的梳理和重组，打破组织和部门的条块分割，抛开部门之间的狭隘观念。在业务模型下，才是依靠数据及技术模型进行支撑。这与我国电子政务往往技术至上的建设模式，存在较大的差异。

　　（四）刚性约束与弹性相结合

　　作为一个宏观的顶层架构，其约束性，必然是刚性约束与弹性相结合的，而且必然是弹性比较大，这也是其宏观策略所必然决定的。其刚性约束主要体现在业务组件的划分、数据标准及数据交换标准上；而弹性主要体现在具体的实现上，特别是业务组件的内部实现上，即技术标准是具有一定弹性的。这也是为什么国外的电子政务体系中，存在着多家公司通过不同技术体系实现的系统，只要是符合其刚性约束的，不管其内部实现机制如何，均可以进行良好的协作运行。

　　（五）有详细且可操作的准入与评价体系

　　由于对业务实现没有进行刚性的约束，如何对业务系统或者业务组件进行准入和评价，就显得尤为重要。首先，在业务系统的宏观构成上需要满足业务模型或者业务组件模型；其次，还必须满足数据标准及数据交换标准。判断业务系统是否满足这些标准，接入系统后，是否可以良好运行，需要一套详细的评价体系进行评价。只有经过这套评价体系评判的系统，才能确定其准入资格。

　　五、如何规划我国的政府行业信息化整合之路

　　（一）明确一个权威的官方机构主导建设

　　在政府行业信息化建设的初期，由于主要是单个业务系统的建设，解决独立业务的信息化问题，因此，承担主导建设的往往是政府行业的某个业务部门，在一些应用水平不是很高的低级别地方政府行业，甚至可能是由某家公司来进行信息化的主导工作，而本应承担政府行业信息化建设重任的各级信息网络中心，反而在大部分地方都处于一个靠边站的尴尬境地。

　　因此，应该明确这么一个权威机构：由主管信息化建设的一级领导挂帅，信息网络中心主导，业务部门及软件提供商共同参与的组织主导当前的建设工作。

　　（二）构建我们自己的顶层设计架构

　　参考美国及英国电子政务的成功经验，可以看出，提出一个信息化顶层设计的政府行业组织构架，将是解决目前政府行业信息化建设瓶颈的有效策略，也是有效进行数据整合及业务整合的前提保障（参见图２）。因此，我们建议主要借鉴美国F E A 的架构模型，结合我国政府行业的自身特点，应尽早提出和规划我们自己的政府组织架构。由原先的注重具体项目、技术及表层应用的建设体系，转向通过引入绩效管理、制定业务规范、明确技术标准而将金财工程建设纳入制度化运行轨道的例行管理（参见图３）。

　　建议政府行业组织架构由5 层结构组成，分别包括绩效参考模型、业务参考模型、服务构件参考模型、数据参考模型、技术参考模型。

　　由5 大参考模型构成的政府行业组织架构的建立，需要一个循序渐进的过程，需要一个逐步完善的周期。因此，对各个参考模型当前的工作突破点，提出如下建议：——绩效参考模型。应该初步建立电子政务绩效评估的指标体系和投入产出的考核标准。

　　——业务参考模型。当前首要任务就是清理政府行业业务流，按照业务流程原则而不是内部组织结构的划分，对政府行业业务进行重新规划，并尽早提出《政府行业表层业务划分规范》、《政府行业业务整体流程》等规范性文件。

　　——服务构件参考模型。该模型是对表层业务软件的选型起指导性的参考模型，在业务参考模型的相关规范性文件出台的前提下，需要进一步针对信息系统的业务过程或者服务及政府行业系统功能模块构架进行整理。——数据参考模型。应该包括已经出台的基础数据规范及正在制订的数据交换规范等。

　　——技术参考模型。应该初步制定政府行业的信息系统开发规范及技术规范。

　　（三）建立详细且可操作的表层业务准入及评价体系

　　参考我们提出的政府行业组织架构，表层业务的准入及评价体系应该包含如下几个方面：①综合运行指标，是否符合组织架构绩效参考模型的要求；②表层业务的划分原则，是否符合组织架构业务参考模型的要求；③业务域及业务组件的定义，是否符合组织架构服务构建参考模型的要求；④数据的定义、存储及数据交换，是否符合组织架构数据参考模型的要求；⑤提交的技术文档及源代码，是否符合组织架构技术参考模型的要求。

　　针对以上几个考核要点，应该制定出相应的评价体系，并需要相应配套的评价细则，对应用支撑平台的表层业务进行有据可依的评价。

　　（四）如何通过成功的实施体现应用支撑平台的核心价值

　　⒈应用支撑平台实施是一把手工程

　　应用支撑平台的实施是一把手工程，若不能始终如一地贯彻一把手工程，则应用支撑平台实施很可能半途而废。原因如下：

　　①应用支撑平台实施涉及范围广。其牵涉范围为整个政府行业业务部门，甚至是与政府行业相关的整个政府系统。要打通部门之间的隔离墙，让信息更加通畅，让应用支撑平台在信息共享与信息及时性方面给政府行业带来更大的效益，这都要“一把手”的强大支持。

　　②在应用支撑平台实施过程中，一把手是流程重组的驱动力。应用支撑平台实施中最重要的就是管理流程的重组，这就必然会改变政府行业系统内部现有的不规范的操作模式。要改变各级业务人员原来的操作习惯，非要借助一把手的“尚方宝剑”不可。

　　③应用支撑平台实施周期长，存在“项目组成员的变化、表层业务产品路线的变化、业务模式的变化”等不确定因素。这些不确定因素往往会导致应用支撑平台实施周期的延长及成本的提高，如何控制不利因素的发生，协调其中的利弊，这都是一把手在实施过程中能够考虑和解决的问题。

　　⒉实施与政府行业管理体制变革需紧密配合

　　应用支撑平台只是一个管理变革的载体，它所提供的只是操作模式，操作模式需要政府行业的管理变革来相互配合。政府行业的变革不仅要制订高效的办事程序，而更重要的是想办法让业务人员接受并自觉执行高效的程序，同时还要建立相应的管理体系保障高效办事程序的执行。有了高水平的操作模式及办事程序，政府行业并不一定就能高效地运作，还需要进行高效运作的环境和技能。实施应用支撑平台充其量只能是政府行业管理变革的一个组成部分——手段的变革，它需要政府行业其他方面变革的配合和支持，只能推动而不能代替政府行业的变革。想通过实施应用支撑平台走捷径，其结果肯定是事与愿违。

　　传统的政府行业管理模式是按职能展开的，其组织结构的特征是纵向分层次、横向分部门。在强调构建高效、科学施政的政府行业管理的今天，传统的管理模式就显得很僵化。信息系统成功运行的先决条件是有与之相适应的管理模式，如果政府行业管理层对这一点没有充分的认识，将会导致应用支撑平台在实施过程中半途而废。

　　对于政府行业管理体制的变革，其实在很多时候与企业是类似的，结合E R P 的实施经验，主要是需要做到如下几点：

　　①政府行业组织结构扁平化；

　　②政府行业组织应以作业过程而非职能部门为中心；

　　③所需信息完整地一次性获取，政府行业管理建立在集约信息系统之上；

　　④政府行业各部门活动并行化，而非顺序式运作。

　　⒊实施的不仅仅是软件，更是先进业务模式的重建和推广

　　实施应用支撑平台是一个管理模式重建的过程，同样，也是一个先进业务模式的重建和推广过程。管理模式的变革可以带来工作效率的提升，而先进业务模式的重建和推广，则将带来工作质量的大幅度提升。因此，我们建议在应用支撑平台实施以前，归纳总结出几套优秀的核心业务模式。通过应用支撑平台实施这个载体，将这些业务模式进行推广，以便达到整体提升整个政府行业应用水平的目的。

　　⒋充分考虑人的因素，一切以人为本

　　应用支撑平台实施是一场变革，既是一个“从上到下”的过程，也是一个“从下到上”的过程。“从上到下”就是变革源于各级政府行业最高领导人“一把手”的决心，没有“一把手”的战略思考和变革决心，就谈不上变革。“从下到上”指的是变革需要广大政府行业业务人员的广泛参与，否则变革难以成功。因此，需要把“一把手”的变革决心转变成为各级业务人员的自觉行动，应用支撑平台的实施才能有必胜的把握。这需要反复的沟通、利益的协调和激励机制的建立，而不是通过简单的行政命令就可以实现的。通过行政命令实现的政府行业管理变革将是短命变革，要么达不到预定目标就停止，要么在达到了目标之后会发生反弹、产生逆转，又回到原来出发的地方，因为人没有被改变。

　　⒌要注重实施后的持续跟踪和改进

　　国际上大型的E R P 实施流程中，特别重视实施后的持续跟踪和改进。作为与E R P 实施十分类似的应用支撑平台实施，同样需要注意实施后的工作。这是因为，系统在政府行业中的运行状况是不断变化的。随着时间的推移，政府行业的业务和人员发生了变化，信息化系统的业务流程也应该进行调整。但是在已往的实施中并未做到这一点，这时系统开始与实际脱节，然后这种情况会愈演愈烈，最终导致实施的失败。

　　因此，建议建立年度系统评估制度，对未来运行过程中出现的问题进行不断的跟踪和改进。

　　参考文献：

　　1. 国家标准化管理委员会，国务院信息化工作办公室．电子政务标准化指南[S]. 2002.

　　2. 国家标准化管理委员会,国务院信息化工作办公室. 电子政务总体设计要求[S]. 2005.

　　3. 韦东方,仲伟俊.我国电子政务顶层设计与管理中亟待解决的问题及其对策[J]. 电子政务,2006(6).

　　4. 杨吉江, 贺炜. 加强顶层设计 推动电子政务深入发展[J]. 电子政务，2006(1/2).