从一个失败案例看IT战略规划

       公司业务众多，同时该公司的下属子公司在地域上分布也比较散，下属的八个大型一级子公司分布在四省两市，作为整个集团企业的C公司在综合协调管理方面存在非常大的难度。
        为了搞好全公司的综合管理，使总公司能够全盘了解整个企业的经营状况，协调各方面有效运作，使各个分公司步调一致地运转，从而发挥整体优势，总公司专门成立了一个经营活动分析决策小组。组长由副总经理林刚担任，小组全盘负责整个集团的经营信息的收集、整理和分析，并提出决策思路。C公司有一个信息中心，主要负责企业的计算机管理系统的维护和开发，其中，开发这块是一个叫梅铁的人负责。
        数据拖经营后腿
        工作组工作的头几个月里，已有不少问题显现出来。
        具体表现在三个方面：
        一、下属子公司数据难以及时汇总提交。除了子公司统计上报有时不及时外，各公司数据上传方式也各不相同--传真、邮寄书面报表、通过电话线直接报数据，还 有的是通过软盘（那时互联网还不普及），五花八门。这些数据到总公司各部门后又经过手工汇总填表才成为决策分析能够用的数据。整个传递、汇总、分析填报的 过程要花2到3周。经常出现的情况是当数据收集齐了、报表出来了，工作组开会作经营决策分析的时候，决策的内容是上个月的，也就是事后决策，毫无意义了。

       二、数据不一致，即经过汇总的数据，通过各部门的报表出来后，相同的指标具体数值却不一样。如财务处的人员工资总额与劳资处报的不一样，运输处报的每吨公里耗油量与技术处报的不一样，如此种种，虽然差别不大，但常常使经营分析小组无所适从。
       三、数据和分析手段有限，无法进行深入分析。各部门提交的数据是经过层层汇总填报出来的，到了工作组就只有一个总数了，当发现一项数据有必要进一步分析时往往只能向下追索一层数据，如果还找不到问题就只有作罢。同时作为手工计算难以运用数学模型作出复杂的分析计算。
       这三个方面问题的存在，使得经营活动分析工作难以有效开展。
       在这种情况下，林刚想到通过计算机数据快速传输和快速处理，应该能很好地解决这个问题。具体任务落在了梅铁身上，并要求在两个月内完成。

       边界问题
      信息中心有一定的开发力量，而开发这套系统需要对C公司各部门业务和现在使用的计算机管理系统很熟悉，梅铁决定由信息中心自身承担起这项开发工作。随着开发的进展，梅铁意识到这是一个混乱和充满变数的项目。

       首先是系统的边界问题。各部门已经不同程度地用了计算机管理。财务这一块已经建立了比较完善的财务管理系统，总公司、二级和三级子公司都应用了统一开发的财务管理系统，并且能够通过点对点的数据传输实现报表的汇总；技术处也已有燃耗统计系统，但是数据是由各子公司报上来再由技术处录入后生成各种报表；劳资处是信息中心自己开发的管理系统，有什么进一步的需要都好说。其他部门基本上还没有相应的计算机管理系统。
       如果系统边界定在各子公司，那么财务系统不仅没有充分利用，而且还要增加财务人员的数据录入量。这样的话，等于又重复开发了部分财务报表系统，不仅得不偿 失而且在时间上也是来不及的。燃耗系统和人力资源管理系统都有相同的情况。边界统一划在子公司，还面临是否与子公司现有系统接口的问题。经过反复考虑，梅铁决定不统一划定边界，如果总公司现有的系统能够连接就与之连接，从现有系统中抽出分析所需的基础数据。没有系统的就由子公司相关人员录入再将数据传输到总公司汇总。至于子公司的系统一律不考虑连接。
       系统边界定下来后，接着就是数据的统一问题。在上报的数据中，来源于不同部门的指标相同但数据值有很多不一致。

       能不能通过计算机来解决，如何解决，这是必须考虑的问题。通过深入细致的分析，梅铁认为，有些可以通过计算机解决，有些是管理方面的问题，在相关部门的配合下可以解决一部分。
        第三个问题是如何运用各种数学模型对数据进行深入分析。考察了相关工具和平台后，梅铁认为这方面没有太大的问题。确定了这些大政方针后，梅铁就带领开发队伍边作详细设计边开发了。然而当他们作手具体的开发工作时，才发现更大的问题还在后面。

        统一数据
        首先是与现有系统相衔接的问题。财务系统是由子公司投资的一家计算机公司开发的，该公司在技术上十分配合，但问题是两套系统在技术平台上很难结合。
        财务系统开发的比较早，同时也考虑到可靠性的问题，应用的是UNIX操作系统和INFORMIX数据库，这种平台与当前系统的WINDOWS NT和MS SQL SERVER很难直接连接。
        好在财务系统的开发商非常配合，共同研究想出了一个变通的办法。那就是在财务系统上开发一个小程序，将需要的财务数据传换成通用格式的文件，通过这个文件将数据导入新的系统。
       同样的问题也在燃耗系统发生，具体原因倒不是平台不一致，而是数据结构不清楚。该系统是3年前请某高校的一个教研室开发的，由于人事变更当初的开发者早就去无踪了，又没留下相关文档，直接分析现有系统又不现实。面对大量的数据而无从下手，只好放弃该系统，自己从基础做起。
       人力资源系统相对要顺利一些，可以直接与现有系统相连并可以实时取出数据。对于子公司五花八门的应用系统，信息中心是再也没有精力和耐心与它们一一对接 了，统一做一个录入程序，让子公司各部门有关人员各自录入。虽然数据总量比较大，好在分散在各子公司各部门，录入人员基本上能接受。

       数据是能够收集上来了，但由于数据的来源不一，这些数据是按照不同的格式和标准组织的，相同的数据在不同的数据表中按照不同的字段名和不同的格式存储。这 种不一致的数据格式在整个数据库中占20％多，而这些相同指标的数据只有统一对应起来才能进行与其他数据的关联比较，否则的话数据再多也只是一盘散沙。
        数据分析功能的开发相对数据采集和整合要容易一些。原先的构想是对运用一些商业智能工具如BO、SPSS来对集中的大量数据进行挖掘和分析，但是后来改变 了这一思路。一是因为购买正版的商业职能工具所花费用不是一个小数目，一套基本版的BO就要40万人民币，这大大超出了预算，同时也需要花一定的时间来熟 悉使用。另一方面作为分析系统的用户――工作组，主要还是需要他们自己设计的一些表格，至于进一步的数据挖掘，要求并不很高。梅铁采取了折衷的办法，先完 成必要的报表，再运用一些分析工具制作一些常用数学模型分析。
        经过历时2月的紧张开发，整个系统终于完成了。把历史数据拿来试一试，结果基本正确，为了赶在月度分析会上使用，系统测试就这样简短而匆忙地完成了。通过连接、安装、分发，系统基本到位，万事具备只等数据了。

        建设没有变化快
        工作组在系统开发的这两个月里，仍然采用老一套的报表收集和分析方法，问题是越来越大。工作组大部分时间不是用在分析上，而是花在数据的收集和计算上，决策工作难以推进。现在希望的目光都集中在这套新上的系统上。信息中心也不负众望，在工作组的督促和信息中心人员的指导下，数据通过各种渠道陆陆续续汇集到总公司计算机房服务器的数据库中。开会的那天，林刚着实得意了一把。看着投影屏幕上哗哗翻动的表格、流畅滚动着的数据、色彩丰富形式各异的分析图形，兴奋之情溢于言表。除了赞叹计算机应用的美妙外，也把信息中心的工作大大肯定了一番。
       这次分析决策系统的亮相算是一切顺利，再往后，问题就慢慢地暴露出来了。由于这套系统本身就搭建在一个不统一不坚实的基础上，就像建筑在一堆乱石上的楼 房，一旦有那一块石头发生松动，整栋楼房就会分崩离析。而基础的改变，在这样一个竞争激烈的市场环境中是无法避免的，系统的崩溃也就只是时间的问题了。
       第一块松动的石头就是人力资源系统。该系统是公司自己开发的，系统的开放性较好，数据的提取很方便。但从功能上讲比当前市场上成熟的人力资源管理系统要简单，只能够满足人员管理的一般需要。同时计委和经贸委共同推荐了一套人力资源管理系统，虽然没有要求必须购买，但是很多要上报的报表在该系统中都有现成的。在劳资处强烈要求下，人力资源管理系统更换了，于是分析决策系统的问题就来了。

       第二块松动的石头就是工业子公司的组建。总公司下属的很多子公司都是综合性公司，有运输的也有制造的、房地产的。现在总公司实施了一个工业重组的方案，把 所有子公司下属的工业企业合并一个独立的子公司，由总公司直接管理。这样一个合并不仅带来机构人员的变化，也带来了数据上报来源、统计数据指标以及统计分 析方法的变化。这些变化都需要分析决策系统作出相应调整。
        第三块松动的石头是部分业务统计指标的增加。由于分析决策系统采用了大量的关联对照表来解决基础数据规则不统一的问题，因此每次涉及到这些关联数据的运算 都要一一查询相关的关联表，大大降低了系统的运行效率。而这些关联表的数量会随着不一致指标的增加呈几何级数增加。这些关联的增加不仅降低系统性能，也使 系统复杂度大大增加，达到一定数量后，系统就达到崩溃的边缘了。以燃耗统计指标为例，为了降低燃耗成本，总公司在一定范围内推行一种新型的燃油，以替代原 来使用的燃油。新燃油的使用情况需要通过报表数据反映出来。这一个燃耗指标的增加，相应增加了3个关联对照表，燃耗统计数据的速度大大下降。
      接着第四、第五块石头松动了……

      变化的速度大大快于信息中心开发速度，问题不断产生，开发人员也不断修改，但缺口是越来越大。在第二个月的分析会上就已经有少数数据出不来，到第三个月就有不少的数据出不来，到第四个月就只有少数数据出来，第五个月……
         一年以后，当梅铁看着桌上刚刚完稿的厚厚的一本公司信息化规划时，才感到由一年前一个失败项目所背负的责任稍稍减轻了一些，从失败中吸取教训并避免犯同样的错误是他制定信息化规划的原因之一。