论文部分内容阅读
就政府信息系统来看，中美两国的最大区别是在管理模式上。美国地方政府，无论大小，对信息系统的管理基本上是中心化的。信息部直接挂在政府CEO 之下，不仅与公安消防、市政工程、财政等主要部门“齐名”，而且对整个市政府的信息系统(从软件到硬件)的设置、购买、运作、维护，数据的管理和使用方式，都有决定权。权力大，责任就大。所有其他部门都是政府CIO的客户，他们使用政府CIO提供的服务。难怪美国越来越多的政府组织都将其信息部门更名为“信息服务部”（Information Services Department）。
整个信息部门是在集中的模式下运作，但是对运维的管理却没有在一个统一的模式下进行。很多时候美国的政府CIO也会对一些运维管理问题束手无策。
政府信息系统的应用范围，在美国也好，中国也罢，按功能区分不外乎公共安全、市政工程、土地建筑规划和管理、财政人事管理（ERP）、内部文件档案管理几大块。近年来，随着互联网的发展，大部分政府信息都被搬上了互联网（政府对外网站和内部网站）。于是，网站也被列为政府信息系统的一部分。
系统大集中 但运维各异
美国IT领域的发展可以用“百花齐放，百花争妍”这句话来形容。从网络系统、公共安全系统、财政系统到各种市政工程运作的系统，都有许多相关的软件公司。各个公司之间的竞争十分激烈。几年前，我们要购买一套办公室流程管理系统（Process Management System）时，参加投标竞争的公司多达9家。各公司的产品各具特点，价格也是大相径庭。拿ERP系统为例，比较大型的有Pentamation、 HTE/Sunguard、Tylor、Microsoft等十几家。近年来，微软并购了八家公司，企图以自己的实力占领ERP市场。美国软件市场多样化的特点为政府组织信息系统的运维带来了一个很突出的问题：多样化的软件导致运维项目难以统一。虽然政府部门的管理模式是中心化的，但系统的运维却没有统一的模式。我们可以从两个方面来讨论。
第一，信息系统中有许多不同的软件在运行，反映了政府运作中的不同需求。但各类不同软件之间的数据交换就成了问题。如何使各种软件在运行中能够进行“数据交谈”（Data Communication）是一件十分重要的任务。看这个简单的例子：如果一个欠着市政府水费的居民到车辆管理处购买停车证，那么车辆管理系统（Parking Permit System）就应该自动将这位居民欠水费的情况识别出来。这就需要车辆管理部门的系统能够与财政部门的水费账目系统（Utility Billing）相互“交谈”。这就是一种叫做“系统通用识别”（Universal Flagging） 的功能。在这个例子中，车辆管理系统和水费账目系统是两种不同的软件系统。一般说，前者会是公共安全系统中的一个模块（Module），而后者却是ERP 系统的一部分。
由于美国地方政府各自独立的特点，各个政府机构使用的软件更是五花八门。说到ERP系统，有的市政府希望居民在网上交费，而本身的ERP 系统因“年老失修”又不具备在网上运作的功能，就干脆另外购买单独的水费账目系统。虽然这种情况是任何一位政府CIO都不原意看到的，但如果社区居民有如此的要求，也只好如此。
第二，鉴于上述的系统设置和运行情况，系统的维护也就有一个突出的特点：各个软件公司负责为客户提供系统维护、升级、换代服务。这主要是指软件而言的。信息系统的硬件，诸如服务器、网络连接设备、交换机等，一般是由生产厂商或者销售商负责。比较典型的维护方式就是生产厂商提供的售后服务。这样一来，信息系统运维的问题就落在软件上了。
从这里的介绍可以看到，美国地方政府信息系统的运维很难统一起来。去年北京市公布了《北京市电子政务IT运维服务支撑系统系列规范》。这种统一的“规范”很难在美国实施。
资金限制下不得宠的系统运维
在美国IT领域的大环境中，系统的运维管理始终是一个焦点。尤其在政府的系统管理中，资金是一个很严重的问题。但幸运的是，我自己在过去的十几年中，只经历过一次“重大事件”。在那次事件中，为市政府机关提供互联网服务的网络终端服务公司（Last Mile provider），因发展太快，无力偿还银行贷款，并几次忽视法庭的传票，而被查封、变卖以偿还贷款。我前一天还到那家公司谈今后的合作问题，第二天却发现市政府的互联网被切断。我在上午几次电话联系，无人回答。下午只能驱车前往。却发现那么一幢大楼已人去楼空，设备也被全部查封。在那次事件中，市政府的网站和工作人员的电子邮件全部停运，社区居民十分不满意。
在上述的技术环境中如何保证系统运行呢？从用户的角度看，市政府的各个部门不懂得什么是硬件、软件，什么是服务器、路由器，什么是运维。他们所需要的是，打开计算机，系统就应该运转；社区居民想上网交税，他们就应该能在网上进行交税的活动。如果系统维护不当，用户部门或者居民感到不满意，CIO很难从技术角度来进行辩解。为此，对于CIO来讲，系统运维问题后面还具有一定的政治风险。虽然，从技术方面看系统运维对政府机构和企业来说没有区别的，但在美国的政治、经济、社会环境中，企业为了在竞争中立于不败之地，必须承受任何系统运维的成本。但政府机构的运作却在很大程度上受限于资金。政府运作资金是纳税人的钱，那些对计算机技术不甚了解的社区居民对政府计算机系统的运行也就有了发言权。特别是在每次年度预算的时候，政府的预算过程是在社区众目睽睽之下进行的。这样一来，有关信息系统的项目就很难与公共安全、道路维修、清除积雪、排污水等项目竞争。
于是，政府的CIO就不得不将自己管辖下的各类系统按照重要程度排序，然后在资金有限的情况下计划如何进行运维。在美国IT的标准中，一个系统每年正常运转的时间必须保持在99.999% 之上。换言之，这就意味着每年系统因故障而停运的时间不得超过6分钟。就网上交费的功能来看，政府的网站停运几分钟甚至几小时，是不会出大问题的。如果是在夜间，可能都没有人注意到。但是，要是政府“911呼救中心”的系统停运几分钟，潜在的问题会很严重，因为涉及居民的生命财产。所以，较多的资金就会用于为“911”系统设置热备份（Hot Backup）。
看好来自厂商的运维服务
如前文所述，运维管理中，软件的运维管理比较复杂。美国政府机构，从联邦到地方，一般不太會自己编程，设计所需的软件。在购买软件时，软件公司会提供与技术相关的售后服务（技术支持）。在购买软件系统的过程中，参加投标公司对自己产品的技术支持水平是一个重要的选择标准。目前，许多软件公司将技术支持与自己产品的软件许可证捆绑起来。软件许可证的数量越大，许可证单位价钱就越低。从价钱上看，无论是否捆绑许可证，技术支持的价格约占产品价格的16%~18%，最高的可达22%。
有一些软件公司，并不直接与客户发生买卖和技术支持的关系，而是授权一些技术实施公司投标，签合同，安装、提供售后的技术支持。通常，这样的技术实现公司只提供一、二级的技术支持。只有到三级的技术问题才直接转到软件公司那里去。我比较喜欢这样的中小公司。他们通常会为了让客户满意，专门指派一个技术人员专门来负责几个客户。这样的服务，电话一打就通，问题立刻可以得到解决。一般讲，中型偏小的公司比较能兑现“7×24×365”的全天候技术支持，而且很少有这样的公司将一级技术支持的部门转移到海外的。
这种依靠软件公司为自己的产品提供运维服务的模式有一个“天生”的缺陷：如果软件因某种原因不复存在了，客户怎么办？从现实中看，美国政府CIO手无良策。唯一的办法是在购买过程中仔细审查软件公司的经营方式以及财政收入情况，对投标公司的前景做到心中有数。
整个信息部门是在集中的模式下运作，但是对运维的管理却没有在一个统一的模式下进行。很多时候美国的政府CIO也会对一些运维管理问题束手无策。
政府信息系统的应用范围，在美国也好，中国也罢，按功能区分不外乎公共安全、市政工程、土地建筑规划和管理、财政人事管理（ERP）、内部文件档案管理几大块。近年来，随着互联网的发展，大部分政府信息都被搬上了互联网（政府对外网站和内部网站）。于是，网站也被列为政府信息系统的一部分。
系统大集中 但运维各异
美国IT领域的发展可以用“百花齐放，百花争妍”这句话来形容。从网络系统、公共安全系统、财政系统到各种市政工程运作的系统，都有许多相关的软件公司。各个公司之间的竞争十分激烈。几年前，我们要购买一套办公室流程管理系统（Process Management System）时，参加投标竞争的公司多达9家。各公司的产品各具特点，价格也是大相径庭。拿ERP系统为例，比较大型的有Pentamation、 HTE/Sunguard、Tylor、Microsoft等十几家。近年来，微软并购了八家公司，企图以自己的实力占领ERP市场。美国软件市场多样化的特点为政府组织信息系统的运维带来了一个很突出的问题：多样化的软件导致运维项目难以统一。虽然政府部门的管理模式是中心化的，但系统的运维却没有统一的模式。我们可以从两个方面来讨论。
第一，信息系统中有许多不同的软件在运行，反映了政府运作中的不同需求。但各类不同软件之间的数据交换就成了问题。如何使各种软件在运行中能够进行“数据交谈”（Data Communication）是一件十分重要的任务。看这个简单的例子：如果一个欠着市政府水费的居民到车辆管理处购买停车证，那么车辆管理系统（Parking Permit System）就应该自动将这位居民欠水费的情况识别出来。这就需要车辆管理部门的系统能够与财政部门的水费账目系统（Utility Billing）相互“交谈”。这就是一种叫做“系统通用识别”（Universal Flagging） 的功能。在这个例子中，车辆管理系统和水费账目系统是两种不同的软件系统。一般说，前者会是公共安全系统中的一个模块（Module），而后者却是ERP 系统的一部分。
由于美国地方政府各自独立的特点，各个政府机构使用的软件更是五花八门。说到ERP系统，有的市政府希望居民在网上交费，而本身的ERP 系统因“年老失修”又不具备在网上运作的功能，就干脆另外购买单独的水费账目系统。虽然这种情况是任何一位政府CIO都不原意看到的，但如果社区居民有如此的要求，也只好如此。
第二，鉴于上述的系统设置和运行情况，系统的维护也就有一个突出的特点：各个软件公司负责为客户提供系统维护、升级、换代服务。这主要是指软件而言的。信息系统的硬件，诸如服务器、网络连接设备、交换机等，一般是由生产厂商或者销售商负责。比较典型的维护方式就是生产厂商提供的售后服务。这样一来，信息系统运维的问题就落在软件上了。
从这里的介绍可以看到，美国地方政府信息系统的运维很难统一起来。去年北京市公布了《北京市电子政务IT运维服务支撑系统系列规范》。这种统一的“规范”很难在美国实施。
资金限制下不得宠的系统运维
在美国IT领域的大环境中，系统的运维管理始终是一个焦点。尤其在政府的系统管理中，资金是一个很严重的问题。但幸运的是，我自己在过去的十几年中，只经历过一次“重大事件”。在那次事件中，为市政府机关提供互联网服务的网络终端服务公司（Last Mile provider），因发展太快，无力偿还银行贷款，并几次忽视法庭的传票，而被查封、变卖以偿还贷款。我前一天还到那家公司谈今后的合作问题，第二天却发现市政府的互联网被切断。我在上午几次电话联系，无人回答。下午只能驱车前往。却发现那么一幢大楼已人去楼空，设备也被全部查封。在那次事件中，市政府的网站和工作人员的电子邮件全部停运，社区居民十分不满意。
在上述的技术环境中如何保证系统运行呢？从用户的角度看，市政府的各个部门不懂得什么是硬件、软件，什么是服务器、路由器，什么是运维。他们所需要的是，打开计算机，系统就应该运转；社区居民想上网交税，他们就应该能在网上进行交税的活动。如果系统维护不当，用户部门或者居民感到不满意，CIO很难从技术角度来进行辩解。为此，对于CIO来讲，系统运维问题后面还具有一定的政治风险。虽然，从技术方面看系统运维对政府机构和企业来说没有区别的，但在美国的政治、经济、社会环境中，企业为了在竞争中立于不败之地，必须承受任何系统运维的成本。但政府机构的运作却在很大程度上受限于资金。政府运作资金是纳税人的钱，那些对计算机技术不甚了解的社区居民对政府计算机系统的运行也就有了发言权。特别是在每次年度预算的时候，政府的预算过程是在社区众目睽睽之下进行的。这样一来，有关信息系统的项目就很难与公共安全、道路维修、清除积雪、排污水等项目竞争。
于是，政府的CIO就不得不将自己管辖下的各类系统按照重要程度排序，然后在资金有限的情况下计划如何进行运维。在美国IT的标准中，一个系统每年正常运转的时间必须保持在99.999% 之上。换言之，这就意味着每年系统因故障而停运的时间不得超过6分钟。就网上交费的功能来看，政府的网站停运几分钟甚至几小时，是不会出大问题的。如果是在夜间，可能都没有人注意到。但是，要是政府“911呼救中心”的系统停运几分钟，潜在的问题会很严重，因为涉及居民的生命财产。所以，较多的资金就会用于为“911”系统设置热备份（Hot Backup）。
看好来自厂商的运维服务
如前文所述，运维管理中，软件的运维管理比较复杂。美国政府机构，从联邦到地方，一般不太會自己编程，设计所需的软件。在购买软件时，软件公司会提供与技术相关的售后服务（技术支持）。在购买软件系统的过程中，参加投标公司对自己产品的技术支持水平是一个重要的选择标准。目前，许多软件公司将技术支持与自己产品的软件许可证捆绑起来。软件许可证的数量越大，许可证单位价钱就越低。从价钱上看，无论是否捆绑许可证，技术支持的价格约占产品价格的16%~18%，最高的可达22%。
有一些软件公司，并不直接与客户发生买卖和技术支持的关系，而是授权一些技术实施公司投标，签合同，安装、提供售后的技术支持。通常，这样的技术实现公司只提供一、二级的技术支持。只有到三级的技术问题才直接转到软件公司那里去。我比较喜欢这样的中小公司。他们通常会为了让客户满意，专门指派一个技术人员专门来负责几个客户。这样的服务，电话一打就通，问题立刻可以得到解决。一般讲，中型偏小的公司比较能兑现“7×24×365”的全天候技术支持，而且很少有这样的公司将一级技术支持的部门转移到海外的。
这种依靠软件公司为自己的产品提供运维服务的模式有一个“天生”的缺陷：如果软件因某种原因不复存在了，客户怎么办？从现实中看，美国政府CIO手无良策。唯一的办法是在购买过程中仔细审查软件公司的经营方式以及财政收入情况，对投标公司的前景做到心中有数。