信息中心
資深CIO眼中信息系統的“造橋”與“修路”
一位經常往來于杭州與溫州之間的朋友說，“坐在車上，不用看交通標識牌，也不用計算時間，只要留意一下上橋與下橋的感覺，就知道是不是已經到溫州境內了”。為什么呢？他說，“溫州橋和路之間總有2-3厘米的落差，發現有頻繁的顛簸，就可以斷定到溫州了”。他說的是實話，不過，如果我們認為這是造橋和筑路的單位工作銜接方面沒有到位所形成的，那實在是冤枉了。究其根本是溫州的地質條件決定的，這是典型的丘陵地區，看上去平的地方其實早先是灘涂濕地，路基很軟。造橋的時候都會打樁，筑路一般不用打樁，新的公路修好之后，原本路橋之間沒有落差的，時間長了，受原始規律支配，自然也就有了落差。但就工程而言，據說現在就是筑路，也開始考慮打樁了，顯然這個代價是相當大的，多說一句，即便有落差了，用幾包水泥做“補丁”，或許能彌補這樣的落差，有人這樣建議過，后來沒有什么結果，這是另外一個面上的問題了。
由于橋和路的原始地基是不一樣的，我們本來希望它們能夠統一成平坦路途，但是最終的結果往往還是決定于原始的地基。這個情形引起了我對信息系統的一些思考，在信息系統中，就許多應用而言，也存在著路和橋一樣的情況，所不同的是，它有鮮明的時間與空間的關系，同時，系統中的“路”和“橋”還有互相轉化的可能。在最近幾年的實際工作中，我對此體會深刻。
民間版的路橋哲學
通常情況下，修路的成本要比修橋的成本低，現在越來越多的亦橋亦路的高架橋啊、立交橋啊另當別論。我們默認的是，路在陸地，橋則在水面之上。對于路的追求我們自然是希望保持平坦順暢，而橋，單就交通的需要來看，我們是希望它盡量地少。局限于許多條件，很多時候不得不要修橋，修了橋之后，一方面我們會習慣的將橋當作路，比如數十公里長的杭州灣大橋，常常是默認它為海上之路的，另外一個方面，有往往希望它能被新的路替代了，歷史變遷所留下的許多帶橋字樣的地名已經幫我們說明了這一點。
在信息系統中造橋往往是為了筑路，而道路拓寬之類又常常以造橋的方式來進行。這或許是我比較局限的個人項目體驗，但是似乎存在著一定的普遍道理。
2007 年，我們在為公司的供應鏈管理項目進行業務建模的時候，就包裝物的產品化做了許多探索。圖中所顯示的三個階段，分別處于2008年以前、 2008-2009、2010之后。就技術條件來說，業務建模的核心工作--產品結構設計是完全可以做到網絡產品化階段的，也就是說，可以直接做成通過很少的產品屬性，但是可以很精確地表達出產品在各個工序（知識生產性質的工序與物質生產性質的工序都包含）的模式。這樣做起來技術負擔不大，但是我們采取了 “造橋”的方式，增加了技術負擔，由于產品為系統的核心基礎資料，它的變更將引起整體構架上的變更，項目風險顯著增大，之所以如此決策，主要是考慮到業務發展的進程需要一個艱辛的語言統一過程。信息化在業務進化的不同階段發揮不同的作用，在個別產品化階段，就是工具，在普通產品化階段，它其實是BPR的載體，是促進規范的一個過程，而在網絡產品化階段則是一個完全蝶化的過程，是引領業務變革的巨大引擎。
項目在2008年10月13日全部上線之后，直到2009年底2010年初這個時間里面，信息系統所起的作用與其說是業務財務一體化的多功能發力于企業管理，還不如說是為下一代的系統做測試，做demo，做基礎資料。事實上從上線到2009年3月份，客戶的產品已經豐富到一個驚人的數量級，這是一個結構化的將隱性的行業規則呈現的過程，信息化如果只停留在這個層面上謀求對業務的支撐，顯然是相當短視的，雖然，相比以前，已經為業務帶來一個嶄新的改善。
當然我們不會滿足于此，就這個行業的發展趨勢來說，必須做到產品網絡化的程度，唯有到此境地，才能實現全局急速而又穩健擴張的戰略意圖。
這個看上去顯得很冗余的過程，其實是一個基于新業務邏輯的“中介核”-產品內在規律的認識過程。我們蘇北有一句俗語叫做“兩場芝麻一場打”，這個過程既滿足了眼下管理升級與業務持續發展的需要，也為未來的戰略實現鋪了底。消耗了比較多的技術資源，目的卻不是希望這個模塊長期的用下去，不是被動的，而是主動的安排，這樣的安排有可能為未來帶來比較大的戰略縱深。
深圳時代華信科技有限公司CEO萬小青在上一期的《軟件世界》上有一篇文章《需求持續演化，技術實現如何如影相隨》，我對其中的一段文字感同身受！
“ 一個商業軟件的應用生命周期應該少于18個月”，是完全基于業務邏輯演化的頻率而提出了，雖然在數字上類似于IT硬件上CPU更新的摩爾定律，但是在管理軟件上為什么會是這樣的一個周期？......發現在系統上線或者一個業務模式在事實上確定后，通常在第九個月進入震蕩期，當然這個時間間隔在2000年之前通常為2年。所謂震蕩就是業務邏輯與業務過程不夠匹配，有太多的異常需要處理了。然后又進入一個相對的平穩期，但是這個時期經常有小幅度的調整，在過了一年之后到了大約第15個月的時候，一個更大規模的震蕩又開始了。這個時候企業的運營系統一般都會捉襟見肘，通常會以升級的方式來平衡兩者關系，事實上是打補丁，而補丁與之前的架構是沒有血緣關系的，問題也就趨于嚴重。這個時候必須衍生出第二代的業務邏輯來，好似一些動物的蛻變，這個時候已經不是技術方面的問題。從技術構造成本來說，這個時候重新構造可能更合算。
這個可以成為軟件“摩爾定律”的初步認知，恰好與我所理解的這種冗余相呼應。上線的軟件或者應用，在某種意義上成了新一輪業務流程重組的驅動器，而不是應用的終結，我們都主動的將它們應用于實踐。對相對成熟的應用進行主動放棄，在新的業務邏輯中繼承與發揚老業務過程中的戰略，從而使得企業贏得一個蛻變與進化的比較從容的時間差。
橋和路迭代互濟前行
我們非常清楚，信息系統的構造不是一勞永逸的，如何實現隨需而變？上面的討論已經基本明確了一個重要的指導原則，就是需要做好“橋”與“路”的銜接，同時確定“橋”是手段，“路”是目的，在手段上我們或許要投入幾倍于目的的資源，這恰是虛實之策略。
一般來說只有上了第二級臺階，才可以上第三節臺階，雖然第三節臺階很好構造，也能邁上去，但是硬上，可能會帶來“硬著陸”的痛苦，對事業有不利影響。
回顧一下我們在一期項目中，引入了虛擬產品的概念，將之前完全個性化的通過訂單的參數對產品進行描述，變更為在商務確認之前進行虛擬產品構造，商務關系建立之后，直接選取虛擬產品進行少量的參數設置后即可安排供應與生產計劃。這是一個重大變革，為了有效保障項目實施效果，系統設計時，有意對虛擬產品的唯一性沒有作出限制，這樣可以滿足沒有經過嚴格規范的虛擬產品也能正常的下訂單。這個設計就是“橋”的設計，它消耗的技術資源確實比正常的“路”要多。我們通過半年多的基礎資料維護工作，將98%的虛擬產品都羅列進了系統，然后在這個基礎上再去做“緊箍咒”的工作，一個客戶有200多種虛擬產品，通常會壓縮到 40-80種。這個變革過程已經設計在系統里面了，這個過程在2009年的4、5月間將全面啟動，那將是全面締造一個新的業務過程的過程。
前面提到，在“橋”的階段，軟件既是業務之應用，也是BPR的工具，這其實是作為“橋”的真正價值。通過軟件自己來做BPR工作，系統本身具有BPR的功能。由于核心業務過程是基于同一流程展開的，這些局部甚至全局BPR的工作就比較簡單，綜合的實施成本必將顯著降低。業務邏輯的延續性和業務過程進化的延續性將不是問題，組織變革的風險將得到有效控制，這恰是眾多成長型企業所需要的。
集成系統網絡情報信息數據庫
CIO頻道人物視窗
CIO頻道方案案例庫
大數據建設方案案例庫
電子政務建設方案案例庫
互聯集成系統構建方案案例庫
商務智能建設方案案例庫
系統集成類軟件信息研發企業名錄