公司業務眾多，同時該公司的下屬子公司在地域上分布也比較散，下屬的八個大型一級子公司分布在四省兩市，作為整個集團企業的C公司在綜合協調管理方面存在非常大的難度。
        為了搞好全公司的綜合管理，使總公司能夠全盤了解整個企業的經營狀況，協調各方面有效運作，使各個分公司步調一致地運轉，從而發揮整體優勢，總公司專門成立了一個經營活動分析決策小組。組長由副總經理林剛擔任，小組全盤負責整個集團的經營信息的收集、整理和分析，并提出決策思路。C公司有一個信息中心，主要負責企業的計算機管理系統的維護和開發，其中，開發這塊是一個叫梅鐵的人負責。
        數據拖經營后腿
        工作組工作的頭幾個月里，已有不少問題顯現出來。
        具體表現在三個方面：
        一、下屬子公司數據難以及時匯總提交。除了子公司統計上報有時不及時外，各公司數據上傳方式也各不相同--傳真、郵寄書面報表、通過電話線直接報數據，還 有的是通過軟盤（那時互聯網還不普及），五花八門。這些數據到總公司各部門后又經過手工匯總填表才成為決策分析能夠用的數據。整個傳遞、匯總、分析填報的 過程要花2到3周。經常出現的情況是當數據收集齊了、報表出來了，工作組開會作經營決策分析的時候，決策的內容是上個月的，也就是事后決策，毫無意義了。

       二、數據不一致，即經過匯總的數據，通過各部門的報表出來后，相同的指標具體數值卻不一樣。如財務處的人員工資總額與勞資處報的不一樣，運輸處報的每噸公里耗油量與技術處報的不一樣，如此種種，雖然差別不大，但常常使經營分析小組無所適從。
       三、數據和分析手段有限，無法進行深入分析。各部門提交的數據是經過層層匯總填報出來的，到了工作組就只有一個總數了，當發現一項數據有必要進一步分析時往往只能向下追索一層數據，如果還找不到問題就只有作罷。同時作為手工計算難以運用數學模型作出復雜的分析計算。
       這三個方面問題的存在，使得經營活動分析工作難以有效開展。
       在這種情況下，林剛想到通過計算機數據快速傳輸和快速處理，應該能很好地解決這個問題。具體任務落在了梅鐵身上，并要求在兩個月內完成。

       邊界問題
      信息中心有一定的開發力量，而開發這套系統需要對C公司各部門業務和現在使用的計算機管理系統很熟悉，梅鐵決定由信息中心自身承擔起這項開發工作。隨著開發的進展，梅鐵意識到這是一個混亂和充滿變數的項目。

       首先是系統的邊界問題。各部門已經不同程度地用了計算機管理。財務這一塊已經建立了比較完善的財務管理系統，總公司、二級和三級子公司都應用了統一開發的財務管理系統，并且能夠通過點對點的數據傳輸實現報表的匯總；技術處也已有燃耗統計系統，但是數據是由各子公司報上來再由技術處錄入后生成各種報表；勞資處是信息中心自己開發的管理系統，有什么進一步的需要都好說。其他部門基本上還沒有相應的計算機管理系統。
       如果系統邊界定在各子公司，那么財務系統不僅沒有充分利用，而且還要增加財務人員的數據錄入量。這樣的話，等于又重復開發了部分財務報表系統，不僅得不償 失而且在時間上也是來不及的。燃耗系統和人力資源管理系統都有相同的情況。邊界統一劃在子公司，還面臨是否與子公司現有系統接口的問題。經過反復考慮，梅鐵決定不統一劃定邊界，如果總公司現有的系統能夠連接就與之連接，從現有系統中抽出分析所需的基礎數據。沒有系統的就由子公司相關人員錄入再將數據傳輸到總公司匯總。至于子公司的系統一律不考慮連接。
       系統邊界定下來后，接著就是數據的統一問題。在上報的數據中，來源于不同部門的指標相同但數據值有很多不一致。

       能不能通過計算機來解決，如何解決，這是必須考慮的問題。通過深入細致的分析，梅鐵認為，有些可以通過計算機解決，有些是管理方面的問題，在相關部門的配合下可以解決一部分。
        第三個問題是如何運用各種數學模型對數據進行深入分析。考察了相關工具和平臺后，梅鐵認為這方面沒有太大的問題。確定了這些大政方針后，梅鐵就帶領開發隊伍邊作詳細設計邊開發了。然而當他們作手具體的開發工作時，才發現更大的問題還在后面。

        統一數據
        首先是與現有系統相銜接的問題。財務系統是由子公司投資的一家計算機公司開發的，該公司在技術上十分配合，但問題是兩套系統在技術平臺上很難結合。
        財務系統開發的比較早，同時也考慮到可靠性的問題，應用的是UNIX操作系統和INFORMIX數據庫，這種平臺與當前系統的WINDOWS NT和MS SQL SERVER很難直接連接。
        好在財務系統的開發商非常配合，共同研究想出了一個變通的辦法。那就是在財務系統上開發一個小程序，將需要的財務數據傳換成通用格式的文件，通過這個文件將數據導入新的系統。
       同樣的問題也在燃耗系統發生，具體原因倒不是平臺不一致，而是數據結構不清楚。該系統是3年前請某高校的一個教研室開發的，由于人事變更當初的開發者早就去無蹤了，又沒留下相關文檔，直接分析現有系統又不現實。面對大量的數據而無從下手，只好放棄該系統，自己從基礎做起。
       人力資源系統相對要順利一些，可以直接與現有系統相連并可以實時取出數據。對于子公司五花八門的應用系統，信息中心是再也沒有精力和耐心與它們一一對接 了，統一做一個錄入程序，讓子公司各部門有關人員各自錄入。雖然數據總量比較大，好在分散在各子公司各部門，錄入人員基本上能接受。

       數據是能夠收集上來了，但由于數據的來源不一，這些數據是按照不同的格式和標準組織的，相同的數據在不同的數據表中按照不同的字段名和不同的格式存儲。這 種不一致的數據格式在整個數據庫中占20％多，而這些相同指標的數據只有統一對應起來才能進行與其他數據的關聯比較，否則的話數據再多也只是一盤散沙。
        數據分析功能的開發相對數據采集和整合要容易一些。原先的構想是對運用一些商業智能工具如BO、SPSS來對集中的大量數據進行挖掘和分析，但是后來改變 了這一思路。一是因為購買正版的商業職能工具所花費用不是一個小數目，一套基本版的BO就要40萬人民幣，這大大超出了預算，同時也需要花一定的時間來熟 悉使用。另一方面作為分析系統的用戶――工作組，主要還是需要他們自己設計的一些表格，至于進一步的數據挖掘，要求并不很高。梅鐵采取了折衷的辦法，先完 成必要的報表，再運用一些分析工具制作一些常用數學模型分析。
        經過歷時2月的緊張開發，整個系統終于完成了。把歷史數據拿來試一試，結果基本正確，為了趕在月度分析會上使用，系統測試就這樣簡短而匆忙地完成了。通過連接、安裝、分發，系統基本到位，萬事具備只等數據了。

        建設沒有變化快
        工作組在系統開發的這兩個月里，仍然采用老一套的報表收集和分析方法，問題是越來越大。工作組大部分時間不是用在分析上，而是花在數據的收集和計算上，決策工作難以推進。現在希望的目光都集中在這套新上的系統上。信息中心也不負眾望，在工作組的督促和信息中心人員的指導下，數據通過各種渠道陸陸續續匯集到總公司計算機房服務器的數據庫中。開會的那天，林剛著實得意了一把。看著投影屏幕上嘩嘩翻動的表格、流暢滾動著的數據、色彩豐富形式各異的分析圖形，興奮之情溢于言表。除了贊嘆計算機應用的美妙外，也把信息中心的工作大大肯定了一番。
       這次分析決策系統的亮相算是一切順利，再往后，問題就慢慢地暴露出來了。由于這套系統本身就搭建在一個不統一不堅實的基礎上，就像建筑在一堆亂石上的樓 房，一旦有那一塊石頭發生松動，整棟樓房就會分崩離析。而基礎的改變，在這樣一個競爭激烈的市場環境中是無法避免的，系統的崩潰也就只是時間的問題了。
       第一塊松動的石頭就是人力資源系統。該系統是公司自己開發的，系統的開放性較好，數據的提取很方便。但從功能上講比當前市場上成熟的人力資源管理系統要簡單，只能夠滿足人員管理的一般需要。同時計委和經貿委共同推薦了一套人力資源管理系統，雖然沒有要求必須購買，但是很多要上報的報表在該系統中都有現成的。在勞資處強烈要求下，人力資源管理系統更換了，于是分析決策系統的問題就來了。

       第二塊松動的石頭就是工業子公司的組建。總公司下屬的很多子公司都是綜合性公司，有運輸的也有制造的、房地產的。現在總公司實施了一個工業重組的方案，把 所有子公司下屬的工業企業合并一個獨立的子公司，由總公司直接管理。這樣一個合并不僅帶來機構人員的變化，也帶來了數據上報來源、統計數據指標以及統計分 析方法的變化。這些變化都需要分析決策系統作出相應調整。
        第三塊松動的石頭是部分業務統計指標的增加。由于分析決策系統采用了大量的關聯對照表來解決基礎數據規則不統一的問題，因此每次涉及到這些關聯數據的運算 都要一一查詢相關的關聯表，大大降低了系統的運行效率。而這些關聯表的數量會隨著不一致指標的增加呈幾何級數增加。這些關聯的增加不僅降低系統性能，也使 系統復雜度大大增加，達到一定數量后，系統就達到崩潰的邊緣了。以燃耗統計指標為例，為了降低燃耗成本，總公司在一定范圍內推行一種新型的燃油，以替代原 來使用的燃油。新燃油的使用情況需要通過報表數據反映出來。這一個燃耗指標的增加，相應增加了3個關聯對照表，燃耗統計數據的速度大大下降。
      接著第四、第五塊石頭松動了……

      變化的速度大大快于信息中心開發速度，問題不斷產生，開發人員也不斷修改，但缺口是越來越大。在第二個月的分析會上就已經有少數數據出不來，到第三個月就有不少的數據出不來，到第四個月就只有少數數據出來，第五個月……
         一年以后，當梅鐵看著桌上剛剛完稿的厚厚的一本公司信息化規劃時，才感到由一年前一個失敗項目所背負的責任稍稍減輕了一些，從失敗中吸取教訓并避免犯同樣的錯誤是他制定信息化規劃的原因之一。