普查系统用过不再扔掉

1、普查系统用过不再扔掉国家统计局计算中心的张富民处长在过去十余年里 参与了多次全国普查系统的设计、开发工作，在兵来将挡、 水来土掩间，早已是身经百战的“老将” ，大大小小的信息 化难题在他眼里多是小菜一碟。但是，刚刚过去的第一次全 国经济普查，却着实给张处长出了个大难题。普查需要通用平台2003 年 12 月 2 日，国务院下发的国务院关于开展第 一次全国经济普查的通知掀开了中国第一次全国经济普查 筹备工作的序幕。国家统计局早在 2000 年以前就开展过六 七次全国普查活动，包括人口普查、工业普查、基本单位普 查、第三产业普查和农业普查等。而从 2000 年开始，工业 普查、基本单位普查和第三产

2、业普查逐步统一合并为经济普 查，并且从 2005年 1月 1日起正式开始第一次全国经济普 查，成为几大类普查合并后开展的第一次大规模普查活动。在以前的历次普查中，都是一次普查开发一个系统，并 且基本上都是用完以后就扔掉了。所以此次的经济普查面临 一个重要的工作，就是开发一个新的普查系统来支撑经济普 查工作。究竟这一次的普查系统该怎么做呢？国家统计局计 算中心的上上下下都在思考着这个问题。是否还能像以前那 样做一个针对此次经济普查的专用系统呢？从信息化投资回报的角度讲，以前的做法确实有些浪费， 因为每次做的普查系统基本上都只用了一次就扔掉了。而从 另一个角度讲，由于每次普查都可以说是和平时期的最

3、大社 会动员，比如一次全国人口普查动员的直接参与调查人员就 达 600 万人，因此每一次重新设计、开发普查系统，都需要 针对新的系统进行大规模的基层人员的技术培训。这不仅增 加了基层统计工作的负担， 也增加了每次普查的成本。 因此， 无论是从信息化建设的投资回报角度，还是从用户的工作负 担角度考虑，统计局计算中心都需要彻底改变普查系统开发 的传统做法，建立一个能为各种类型普查工作进行数据处理 的通用平台，从而让针对经济普查而设计、开发的平台在以 后的普查中仍能发挥作用。事实上，建立一个普查工作的通 用平台也正是整个国家统计局多年来的夙愿。除此之外，还有一个更加现实的难题也迫使计算中心必 须开发

4、出一个通用平台。因为如果要开发一个经济普查专用 的系统，计算中心就得对用户有非常全面的了解，但是，从 2003 年 12 月 2 日到 2005 年 1 月 1 日正式开始经济普查， 留 给整个统计局的时间只有一年多一点。而在这一年多的时间 里，统计局既要做经济普查的普查方案设计，还得做数据处 理系统的设计、开发工作，特别是两项工作必须基本上同步 进行，这也就是说，计算中心只能将用户需求调查的阶段与 数据处理系统的设计、开发阶段的工作基本同步推进。最终 结果是，计算中心无法针对经济普查做一个专用系统，因为 他们无法全面了解用户的需求，他们惟一的选择就是必须设 计、开发出一个功能足够强并且能随需

5、应变的系统，即一个 各种类型普查都能用得上的通用平台。双项目组长管理制倒计时由于无法全面了解用户的需求，开发人员是否具备从事 普查的数据处理的经验就显得尤为重要，他们最好能对普查 中可能发生的问题做出预测。这就意味着没有任何一家公司 能够独立承担该系统的开发和设计任务，因为统计局无法找 到一个具有丰富的普查数据处理经验的公司。国家统计局只 有以计算中心为核心，充分调动用户、统计系统内部和社会 力量来打这个攻坚战。最终，统计局成立了包括统计局、各 省市县相关用户、三个合作公司在内的共约 50 人的开发小 组，并最终决定采用非常规的开发方式一一封闭式开发，以 确保开发小组能在不到一年的时间内如期完

6、成任务。开发小组在 2004年 3月 14日一进入封闭开发现场，就 面临一个紧急任务，必须在 5 月份做出一个初步的产品来对 经济普查方案进行综合试点，让用户到现场去填经济普查表， 看指标填写的难度和指标设计的合理性。为此，开发小组采 取了一系列的独特措施：根据个人的特长重新进行任务分工， 设立了双项目组长管理制，设置了倒计时牌，提出了“建设 一流沟通团队”的口号，作息表甚至严格规定开发小组成员 每晚至少加班到九点半。经过两个月的鏖战， 开发小组终于不辱使命， 在 5 月 20 日做出了一个产品。但是，开发小组最终收获的却是用户对 产品的否定和对小组开发能力的怀疑。因为四个试点用户认 为，他们

7、需要的是全过程的数据处理系统，包括了录入、编 辑、审核、汇总四个环节， 而目前的系统虽然具备这些功能， 性能和效率却都不是很高，特别是汇总的性能较差。而这一 功能在整个数据处理系统中占据非常重要的地位。对开发小 组而言，时间又少了两个月，而两个月的鏖战也使整个开发 小组人困马乏，系统的失败更让小组成员的情绪非常低落， 有人甚至开始怀疑自己的能力。惟一让开发小组成员感到庆 幸的是，通过与用户的面对面沟通，开发小组成员对开发的 目标有了更加清晰的认识，同时也开始反思最初的设计思路 是否正确。围绕设计问题，在开发小组内部爆发了一场激烈 的争论：是推倒重来，还是坚持原来的思路？大家最终达成 一致：推倒

8、重来！巧妙设计修成正果从 2004 年 6 月 1 日到 7 月 1 日，开发小组做了一个大 胆的决定，所有的工作停下来， 重新做设计， 重新调整人员。 而与此同时，统计局更是做了一个让开发小组成员备感压力 的措施：为数据处理系统做了个备份，让另外一家公司开始 开发经济普查的数据处理系统。因此，从7月 1日起，封闭开发现场就出现了两拨人，二者将在后面的几个月里，决一 雌雄。经过一个月的努力， 开发小组的新设计方案在 2004 年 7 月初正式出炉。由于要做的是普查的通用平台，故所设计的 系统可以根据普查业务的变化，通过二次定制来适应业务需 要。而其实现的关键就是在设计思想上希望通过对业务规则

9、的描述，来驱动数据处理系统工作，即如果普查类型变了， 则其普查的业务规则也变了，这时候就需要相应的业务描述 随之改变，这样数据处理系统在业务规则描述驱动下，处理 数据的方式也就变了。所以，事实上，经济普查数据处理系 统可以划分为两个系统：第一个系统是支撑业务规则描述系 统，又叫统计制度管理系统，需要将统计调查方案转化为电 子化的方案，并把方案描述加载到数据处理系统中去，来指 导系统工作。比如对统计来讲，有两个指标有关联关系，就 需要在统计制度管理系统中把这种关联关系描述好，这样在 数据处理过程中就会监测这种关联关系，如果关系不符合要 求，系统就会报错，这是保证数据质量的措施。第二个系统 是真正

10、意义上进行数据处理的系统，叫数据处理系统。两个 系统合在一块，就叫数据处理系统。这样，通过两个子系统 的协作，开发人员针对不同的普查，只须把统计制度系统中 的业务规则描述改变一下，就能支撑相应的普查数据处理要 求。同时，也正是基于这样的设计机制，开发小组在对用户 需求不很清楚的情况下开发出的经济普查数据处理系统，也 可以随着经济普查方案的逐步细化和用户需求的不断清晰 而逐步修改、完善。技术方案的巧妙设计为成功完成经济普 查数据处理系统的开发工作奠定了坚实的基础，同时也奠定 了普查通用平台的坚实基础。2004 年 9 月份，开发小组又组织用户到开发现场试用基 于新的设计方案开发的系统。这一次用户

11、充分肯定了开发小 组的设计思路，认为开发小组的产品比 5 月份的产品取得了 长足的进步。同时，在 2004 年 9 月初，开发小组在贵州省 进行第一次数据处理的试点，结果显示，开发小组的产品性 能已经可以跟备份公司的产品相提并论。 9 月底，开发小组 很有信心地开始把产品推向全国各省，组织各省的技术人员 参与数据处理系统的培训。培训收到了非常好的效果，特别 是用户在培训后已经由原来对开发小组能力的怀疑，转变为 希望开发小组能把系统做得更好。 2004 年 10 月，时间已经 直逼年底，开发小组也迎来决定生死的一次大考：在河南省 的第二轮、也是最后一次的数据处理试点。在试点现场，国 务院经济普查办公室主任和统计局的一位副局长率领国家 统计局十几个司局的局长亲临现场，全过程参加试点。试点 最终取得非常大的成功，开发小组的数据处理系统的性能已 经全面超过了备份公司的产品，并且能够满足经济普查的数 据处理要求， 同时也基本完成了通用平台的开发工作。 所以， 开发小组在 2004年 11 月 5日正式结束了封闭式开发。这也 标志着经济普查数据处理系统基本开发成功，统计局十几年 的夙愿得以实现。从 20