编者按：综合类政府到底需要什么样的信息系统？其信息化项目的验收为什么很难？在实际的电子政务建设过程中，各种各样的问题不断涌现，如何解决这些问题成为了当务之急。该文的作者通过多年的建设经验，总结出综合类政府的电子政务系统的系统模型--"鸡蛋模型"。目的在于，提醒人们在电子政务系统建设中应避免的一些误区，从而解决了这些问题。其主要的观点有：业务逻辑架构并不等同与业务；系统体系架构并不等同于系统；应用拓展和系统拓展是两个完全不同的概念；应用需求分析和系统需求分析是两个完全不同的概念。
综合类政府到底需要什么样的信息系统？
既有管理职能，又有服务职能；
与下属的专业类政府职能部门既有管理关系，又有业务关系；
没有标准的、固定的业务流程；
既有纵向关系，又有横向关系；由于电子政务以服务为到向，横向关系的处理尤为重要；
本文所指的综合类政府主要指国内地级市一类的政府，不是指那些专业类政府机构或更高、更低级别的政府，这一类政府的运作有如下特点：
要有实现组织整体战略目标的一个业务逻辑架构（ＢＬＡ）；业务逻辑架构不是业务本身，是将业务"串"起来的规则和标准。政府的业务是不断变化的，Ａ城市有１００个审批流程，Ｂ城市有１１０个审批流程，但如果两个政府的整体战略目标都是实现网上审批，那么， Ａ 城市和Ｂ城市的电子政务系统的业务逻辑架构的设计都是要"以服务为导向"的设计思路；
系统除了要有系统拓展功能，即"插件式柔性系统"，更要有应用拓展能力，即１００个审批流程和１１０个审批流程与系统无关；系统拓展和应用拓展是两个完全不同的概念，但很多人没有将这两件事区别开；
要有一个支撑业务逻辑架构的一个系统体系架构（ＳＡ），系统体系架构不是某个系统；实际上它更接近于类似"系统支撑平台"的概念；同时它是满足"系统拓展"的规则和标准的集合。
那么，综合类政府的电子政务系统到底是什么？综合类政府的信息化建设到底有那些内容？笔者认为，综合类政府的电子政务系统应满足以下几个标准：
信息化项目的验收为什么很难？
可以分析各种各样的原因，有用户不满意的原因，有系统故障的原因，有用户关系处理不好的原因，等等，但笔者认为最重要、也是难应付的原因是：系统的目标被"侵蚀"，即，项目做到后面，已经不是项目签约时的目标了，似乎用户的需求永远在变，这是上面所谈的业务运作特点所至。
实际上，很多人把项目的"系统目标"和"应用目标"混为一谈了。应用目标是无限的，系统目标是可以定义的。所以，一个成功的电子政务系统一定要科学、严谨地设计它的系统目标，并且，这个系统是能够支持政府在提出项目时的应用目标，尤其关键的是--支持政府的业务应用拓展和系统拓展。
政府的业务需求本身在不断的变，那么怎么才能满足用户的需求呢？实际上，很多问题的原因在于：很多人没有很好地区别"应用需求分析"和"系统需求分析"，就像鸡蛋一样，花了大量精力了解了表层的"蛋壳"，而不知道里面是什么。系统需求分析是要在应用需求分析的基础上，高度抽象出系统的真正内容。
系统试运行有效吗？
在综合类政府的信息化项目的建设中，如果没有弄清楚本文上面所提几个重要观点，那么轻易地进行系统试运行是有问题的。具体来说，有下列风险：
目标风险：通常有这样的情况，承建商为了加快项目的进度，提出了系统试运行的要求，用户也经常表示："可以让该套系统试运行，但如果该套系统不能满足要求，可以不验收。"这似乎规避了"投资风险"，但实际上没有规避"目标风险"。电子政务的目标并不是"等系统失败以后不验收或不给钱"，或者是"系统仅完成了用户所看到的业务功能"，而是作为技术工程应该确定的"系统目标"。因为用户只能看到具体的功能目标，不能看到系统的内核；同时当系统满足了用户目前的具体功能目标以后，出现新的需求怎么办？
另外，根据笔者多年从事大项目的经验教训，试运行最终导致的结果往往是："不论试运行的系统如何，最后只好选它"的结果。这样，好的系统没有了机会，差的系统暂时能用，等验收付款以后，开发公司撤离以后出现问题，怎么办？
技术风险：从通常意义上讲，对一个信息系统进行试运行是可以规避"技术风险"的，但如果仔细分析一下，我们发现：如果在综合类政府的电子政务项目中匆忙进行系统的试运行，反而会加大项目的技术风险！一、试运行中用户会提出各种各样的问题，开发公司也承诺解决这些问题。这样，就会出现如下情况，即：不断地修改"应用层面"，但"系统内核"仍然不行，到某一个时候，用户认为"应用层面"的问题解决了，可以正式验收运行了，开发公司也撤走了。但是，由于"系统内核"是一个病态的内核，等系统大规模运行后，势必出现问题；另外，如果系统不能支持系统拓展和应用拓展，那么，出现业务流程变化或新的业务需求后，系统无法满足，又要重新开发，浪费投资。二、用户往往不能从系统的高度提问题，只能从他们自身熟悉了的业务层面提问题，而他们熟悉了的业务流程又往往是传统的，不是电子政务系统的真正目标，这样，也会造成"目标侵蚀"。
那么是否就不能进行系统试运行呢？答案是：只有在彻底弄清楚综合类电子政务系统的系统目标后，才能进行系统试运行。
"鸡蛋模型"描述
如果将一个煮熟了的鸡蛋横向从中间切开，我们会看到上图。这个图案形象地展示了电子政务信息化建设的模型。
"蛋黄"--系统内核：系统体系架构和业务逻辑架构的核心部分，电子政务系统"系统支撑平台"的主要部件；
"蛋清"--业务（应用）组件和工具：是系统内核的插件，是实现业务应用和业务界面的应用组件和工具；
"蛋壳"--业务截面：系统的表示层，是服务品种的集合。
电子政务系统"鸡蛋模型"的建立
关键问题是：结合政府的整体目标，设计以服务为导向的"业务逻辑架构"，在此基础上设计这个"鸡蛋模型"。
"蛋黄"应选择高度抽象的系统内核，只有以业务应用无关的高度抽象的系统内核，才能真正适应综合类政务千变万化的业务应用。这个系统内核应满足：
１）是成熟的、经过"千锤百炼"的产品或产品的集成；
２）与政府的数据、数据类型无关的，能支持各种数据源；
３）与应用系统无关，能支持各种系统拓展需求的。
"蛋清"也应选择或开发出高度抽象的支持政府各项业务应用的业务组件和工具集合。应满足：
１）与业务流程无关，能支持政府各种对内、对外的业务流程（工作流）；
２）与业务表示无关，能支持各种表格、公文形式；
３）与业务规则无关，能适应政府各种政令、法规；
４）在系统无须拓展的前提下，能支持设计目标范围内的应用拓展。
"蛋壳"，整个系统的表示层，与整个系统无关，是政务业务的界面和表示层，能不断的变化、更新。
"鸡蛋模型"对信息化项目的指导意义
系统目标的界定：主要认定模型中的"蛋黄"和"蛋清"，是否满足上述标准，并通过政府典型的业务应用，检验该系统能否满足要求；
系统试运行的真正含义：是试运行模型中的"蛋黄"和"蛋清"，不是"本木倒置"地检验某些业务应用（"蛋壳"）；
资源整合和资源的可利用："鸡蛋模型"的设计标准让我们看到，系统内核支持系统拓展的，并且与原有系统和资源无关的，这些系统和资源可以被该系统整合或再利用；
投资效益的提高；有应用拓展时，不一定需要进行系统拓展，投资效益明显提高；
权利向服务转变：集成政府的各种资源，"串"起政府的各种业务，形成各种服务品种，为社会服务。