git战略规划案例.pdf

从一个失败案例看从一个失败案例看 IT 战略规划战略规划 C 运输公司位于华中某地，是中国较大的运输企业之一主要从事货运、油运、集装箱运输 及其他特种运输服务，除此之外，该公司还经营旅游、房地产、制造等多种业务 公司业务众多， 同时该公司的下属子公司在地域上分布也比较散， 下属的八个大型一级 子公司分布在四省两市，作为整个集团企业的 C 公司在综合协调管理方面存在非常大的难 度 为了搞好全公司的综合管理， 使总公司能够全盘了解整个企业的经营状况， 协调各方面 有效运作，使各个分公司步调一致地运转，从而发挥整体优势，总公司专门成 立了一个经 营活动分析决策小组 组长由副总经理林刚担任， 小组全盘负责整个集团的经营信息的收集、整理和分析，并提出决策思路C 公司有一个信息中心，主 要负责企业的计算机管理系统 的维护和开发，其中，开发这块是一个叫梅铁的人负责 数据拖经营后腿 工作组工作的头几个月里，已有不少问题显现出来 具体表现在三个方面： 一、下属子公司数据难以及时汇总提交除了子公司统计上报有时不及时外，各公司数据上传方式也各不相同--、邮寄书面报表、通过线直接报数据，还 有的是通过软 盘（那时互联网还不普及） ，五花八门。

这些数据到总公司各部门后又经过手工汇总填表才 成为决策分析能够用的数据整个传递、汇总、分析填报的 过程要花 2 到 3 周经常出现的情况是当数据收集齐了、报表出来了，工作组开会作经营决策分析的时候，决策的内容是 上个月的，也就是事后决策，毫无意义了 二、数据不一致，即经过汇总的数据，通过各部门的报表出来后，相同的指标具体数值却不一样 如财务处的人员工资总额与劳资处报的不一样， 运输处报的每吨公里耗油量与技 术处报的不一样，如此种种，虽然差别不大，但常常使经营分析小组无所适从 三、数据和分析手段有限，无法进行深入分析各部门提交的数据是经过层层汇总填报出来的， 到了工作组就只有一个总数了， 当发现一项数据有必要进一步分析时往往只能向下 追索一层数据， 如果还找不到问题就只有作罢 同时作为手工计算难以运用数学模型作出复 杂的分析计算 这三个方面问题的存在，使得经营活动分析工作难以有效开展 在这种情况下， 林刚想到通过计算机数据快速传输和快速处理， 应该能很好地解决这个 问题具体任务落在了梅铁身上，并要求在两个月内完成 边界问题 信息中心有一定的开发力量， 而开发这套系统需要对 C 公司各部门业务和现在使用的计算机管理系统很熟悉，梅铁决定由信息中心自身承担起这项开发工作。

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

能不能通过计算机来解决，如何解决，这是必须考虑的问题通过深入细致的分析，梅铁认为，有些可以通过计算机解决，有些是管理方面的问题，在相关部门的配合下可以解决 一部分 第三个问题是如何运用各种数学模型对数据进行深入分析考察了相关工具和平台后，梅铁认为这方面没有太大的问题 确定了这些大政方针后， 梅铁就带领开发队伍边作详细设 计边开发了然而当他们作手具体的开发工作时，才发现更大的问题还在后面 统一数据 首先是与现有系统相衔接的问题财务系统是由子公司投资的一家计算机公司开发的， 该公司在技术上十分配合，但问题是两套系统在技术平台上很难结合 财务系统开发的比较早，同时也考虑到可靠性的问题，应用的是 UNIX 操作系统和INFORMIX 数据库，这种平台与当前系统的 WINDOWS NT 和 MS SQL SERVER 很难直接连接 好在财务系统的开发商非常配合， 共同研究想出了一个变通的办法 那就是在财务系统 上开发一个小程序， 将需要的财务数据传换成通用格式的文件， 通过这个文件将数据导入新的系统 同样的问题也在燃耗系统发生，具体原因倒不是平台不一致，而是数据结构不清楚该 系统是 3 年前请某高校的一个教研室开发的， 由于人事变更当初的开发者早就去无踪了， 又没留下相关文档，直接分析现有系统又不现实。

面对大量的数据而无从下手，只好放弃该系 统，自己从基础做起 人力资源系统相对要顺利一些， 可以直接与现有系统相连并可以实时取出数据 对于子公司五花八门的应用系统，信息中心是再也没有精力和耐心与它们一一对接 了，统一做一 个录入程序，让子公司各部门有关人员各自录入虽然数据总量比较大，好在分散在各子公 司各部门，录入人员基本上能接受 数据是能够收集上来了， 但由于数据的来源不一， 这些数据是按照不同的格式和标准组 织的，相同的数据在不同的数据表中按照不同的字段名和不同的格式存储这 种不一致的 数据格式在整个数据库中占 20％多，而这些相同指标的数据只有统一对应起来才能进行与其他数据的关联比较，否则的话数据再多也只是一盘散沙 数据分析功能的开发相对数据采集和整合要容易一些 原先的构想是对运用一些商业智 能工具如 BO、SPSS 来对集中的大量数据进行挖掘和分析，但是后来改变 了这一思路一是因为购买正版的商业职能工具所花费用不是一个小数目，一套基本版的 BO 就要 40 万人 民币，这大大超出了预算，同时也需要花一定的时间来熟 悉使用另一方面作为分析系统 的用户――工作组，主要还是需要他们自己设计的一些表格，至于进一步的数据挖掘，要求并不很高。

梅铁采取了折衷的办法，先完 成必要的报表，再运用一些分析工具制作一些常 用数学模型分析 经过历时 2 月的紧张开发，整个系统终于完成了把历史数据拿来试一试，结果基本正确，为了赶在月度分析会上使用，系统测试就这样简短而匆忙地完成了通过连接、安装、 分发，系统基本到位，万事具备只等数据了 建设没有变化快建设没有变化快 工作组在系统开发的这两个月里， 仍然采用老一套的报表收集和分析方法， 问题是越来 越大工作组大部分时间不是用在分析上，而是花在数据的收集和计算上，决 策工作难以 推进现在希望的目光都集中在这套新上的系统上信息中心也不负众望，在工作组的督促和信息中心人员的指导下，数据通过各种渠道陆陆续续汇集到 总公司计算机房服务器的数 据库中开会的那天，林刚着实得意了一把看着投影屏幕上哗哗翻动的表格、流畅滚动着 的数据、色彩丰富形式各异的分析图形，兴奋 之情溢于言表除了赞叹计算机应用的美妙外，也把信息中心的工作大大肯定了一番 这次分析决策系统的亮相算是一切顺利，再往后，问题就慢慢地暴露出来了由于这套 系统本身就搭建在一个不统一不坚实的基础上，就像建筑在一堆乱石上的楼 房，一旦有那一块石头发生松动，整栋楼房就会分崩离析。

而基础的改变，在这样一个竞争激烈的市场环 境中是无法避免的，系统的崩溃也就只是时间的问题了 第一块松动的石头就是人力资源系统 该系统是公司自己开发的， 系统的开放性较 好，数据的提取很方便但从功能上讲比当前市场上成熟的人力资源管理系统要简 单，只 能够满足人员管理的一般需要 同时计委和经贸委共同推荐了一套人力资源管理系统， 虽然没有要求必须购买， 但是很多要上报的报表在该系统中都有现成 的 在劳资处强烈要求下， 人力资源管理系统更换了，于是分析决策系统的问题就来了 第二块松动的石头就是工业子公司的组建 总公司下属的很多子公司都是综合性公 司，有运输的也有制造的、房地产的现在总公司实施了一个工业重组的方案，把 所有子 公司下属的工业企业合并一个独立的子公司， 由总公司直接管理 这样一个合并不仅带来机构人员的变化，也带来了数据上报来源、统计数据指标以及统计分 析方法的变化这些变 化都需要分析决策系统作出相应调整 第三块松动的石头是部分业务统计指标的增加 由于分析决策系统采用了大量的关 联对照表来解决基础数据规则不统一的问题，因此每次涉及到这些关联数据的运算 都要一 一查询相关的关联表， 大大降低了系统的运行效率。

而这些关联表的数量会随着不一致指标的增加呈几何级数增加这些关联的增加不仅降低系统性能，也使 系统复杂度大大增加， 达到一定数量后，系统就达到崩溃的边缘了以燃耗统计指标为例，为了降低燃耗成本，总 公司在一定范围内推行一种新型的燃油，以替代原 来使用的燃油新燃油的使用情况需要通过报表数据反映出来这一个燃耗指标的增加，相应增加了 3 个关联对照表，燃耗统计数 据的速度大大下降 接着第四、第五块石头松动了„„ 变化的速度大大快于信息中心开发速度，问题不断产生，开发人员也不断修改，但缺口是越来越大 在第二个月的分析会上就已经有少数数据出不来， 到第三个月就有不少的 数据出不来，到第四个月就只有少数数据出来，第五个月„„ 一年以后， 当梅铁看着桌上刚刚完稿的厚厚的一本公司信息化规划时， 才感到由一 年前一个失败项目所背负的责任稍稍减轻了一些， 从失败中吸取教训并避免犯同样的错误是 他制定信息化规划的原因之一 IT 与业务与业务 当你拥有了半打的内河船赌博设施时，很重要的一点就是每个人都遵守相同的游戏规 则 总部位于美国伊利诺伊州奥尔顿市， 在密西西比河上拥有 6 条游乐船的黑格西娱乐事业 公司（）决定将所有客户数据集中起来，以改进运营管理的视角并帮助强化客户关系。

为了实现这些目标，公司需要访问很多的数据库，还要开发一个抽取、转 换和转载（ETL）系统，以创建并维护中心数据系统 贾森·福腾伯里是一名构建数据仓库的分析员，他是在 2001 年黑格西的数据仓库项目启动时进入公司的他说，采用 Hummingbird 公司 Genio ETL 软件工具后，他的工作变得简 单了，该工具可以帮助他连接系统并实现处理过程的自动化但同他经历的其他项目一样， 他感到最难的一环在于为 ETL 过程做准备，这同拥有合适的软件一样重要 每条船上都有许多独特的、与众不同的定义操作活动和客户特征的方法——这些漂浮 的娱乐场所经营的游乐项目大体相同，但却遵循着不同的规则但是，在公司数据仓库产生 的报告出现不一致或问题数据之前，这些问题一直没有被发现当时，福腾伯里及同事在很多数据类型的定义中发现了冲突——他真希望能早点发现这些问题 福腾伯里的麻烦——也 是他的成功之处——是具有代表性的 ETL，它是数据仓库成功的一个复杂且昂贵的前奏 经过一年来的ETL项目工作， 黑格西公司的福腾伯里说Hummingbird公司的Genio套件，一个数据集成和 ETL 工具，很快成为该公司数据仓库项目的“中枢神经系统” ，负责协调源 数据抽取和数据仓库加载过程。

但对黑格西公司来说，将所有数据装入数据仓库并没有立即产生可有的、可靠的结果教训是人们认为他们在谈论同一件事，但是事实上他们没有 ”福滕伯里说举个例子， 他解释， 不同的游乐船计算顾客光顾次数的方法不同 有的游乐船只有当顾客玩了投。