0 前言

    “已有的研究表明，不像人們想象的那樣，復雜系統一定都要有很大的規模，都要由大量的元件組成......但是引起系統復雜行為的主要原因并不是元件的數量，而是元件之間的交互。”這句話同樣適用企業信息系統，企業信息系統的復雜性是由于不同系統和模塊之間的交互。降低系統復雜性將使得迭代優化非常方便，這將使得系統建設成功比例的提高，同時也將實現成本的降低。最終會實現讓“使用、構建、測試的用戶能夠感到由衷的高興”的美麗架構。

    從上世紀90年代開始，企業架構的方法論開始在國際上逐漸得到接受和使用。目前來看，能夠站在全局實施EA的企業非常的少。一些IT作為其核心競爭力的大公司開始有步驟地全面在展開，如一些世界500強的銀行。而在中國國內，由于對于IT價值的認識還遠遠落后于發達國家。這也導致許多方法論的實施無法得到企業最高層的重視和理解。而企業架構是業務戰略流程和IT架構的有機結合，是IT支撐企業實現靈活、快速、透明、智能的業務方法論。如果沒有最高層的理解和支持，可能變成了畫虎不成反類犬了。對于大而全的企業架構方法論，目前在中國的許多企業實施會面臨著許多的挑戰，有時這也會帶來不必要的復雜性。

    “根據我的經驗，企業架構的成功一般都和復雜性相關。企業架構越復雜，它成功的可能性就越小。換句話說，你期望企業架構給你帶來的越多，你成功的可能性就越小。”  因此對于許多企業而言，通過“解耦”實現分而治之，可能更加現實。由于解耦后問題變得簡單，從而可以集中資源實現最大的效果。

    企業架構的框架和方法論已經有了Zachman、TOGAF、FEA、GARTNER和企業總體架構。目前使用較為廣泛的是TOGAF，它也定義了明確的開發方法，如圖1所示。狀態B包括業務建模、詳細業務分析和技術需求文檔。業務架構在企業架構中是基礎，合理地進行業務架構的分層和分解可以有效地降低后面設計的復雜性。

圖1 TOGAF架構開發方法（ADM）

    根據TOGAF標準，狀態E首先要“把重點放在短期的項目，以此來促進長期的項目”�！八���，我們應該竭力尋找那些投入少，產出多的項目。這樣的項目大多出自組織的痛處，讓企業確信采取企業架構策略的最初的地方。”（明確這里的論述來自哪里）但是同時可以發現，由于方法論中缺少對于復雜性的分析，很多時候，都陷入了瑣碎的事物中忘記了方向。ADM作為方法論如果能夠有效地結合降低復雜性的分析，將會得到可以迭代的少投入、快產出的項目。從而實現可不斷進行迭代優化，這不但可以保障項目的成功，也符合當前市場競爭環境下的業務變化的需求。

    貫穿本文的核心觀點是通過迭代的方式降低企業架構實施的復雜性，從而有效降低風險，實現最大的收益。特別需要強調的是，本文不是完備的方法論，而是對于基本方法論缺少論述的復雜性的思考及解決方案。具體的EA方法論可以參考TOGAF或者企業總體架構，企業架構的構成請參考圖2。

圖2 企業架構的構成

    本文的組織如下：

    第1部分將提出根據企業戰略，在最高層次對業務進行解耦，這里將借鑒企業精簡架構的ABC（自治業務能力）的方法論。并且對于汽車行業以OTD為例進行說明。

    第2部分將描述信息架構，根據業務架構來定義信息架構。這里將會涉及到業務分層以及主數據的分級管理問題的討論。將以企業生產管理和生產管控系統為例進行說明。

    第3部分將描述技術架構降低復雜性的方面。許多企業在IT技術方面已經投入了許多資金，IT技術架構也可以采用逐漸迭代的方法實現復雜性的降低。這里也將舉一個小型機+開放平臺的案例。

    第4部分將綜合進行分析，討論如何通過迭代的方式讓企業架構方法論離大家不再遙遠，真正能夠在給企業帶來最大的價值。

1 業務架構

    對于企業實施業務架構，如果開始時就進行全業務范圍的分析，無疑是沒有必要的。但是這里需要強調的是，需要在企業價值鏈層面進行第一層次的ABC劃分。然后選擇重點期待研究的業務，進行第二層的ABC劃分。在第二層中也可以挑選重點領域進行深入的ABC劃分。最終實現的目標是根據業務重點劃分出具有較為自治的業務功能，各業務功能之間具有較低的耦合，也即相互之間的信息交換最小化。具體的劃分方法論可以參考《企業精簡架構》一書。

    下面舉一個例子來說明如何進行業務第一層的ABC劃分。對于汽車主機廠而言，OTD是其核心價值鏈， OTD涉及到的業務包括銷售線索管理、需求預測、訂單管理、產品研發和制造管理、零件采購與入場物流、生產排產和執行、整車物流。OTD的各環節及相關業務見圖3。

圖3 汽車OTD流程

    由于OTD的復雜性，因此對于該業務必須進行詳細的分析才能夠發現問題的復雜性。僅僅從圖3來看，無法發現各業務深層的聯系，因此我們需要對各業務進行進一步的分解。

圖4 汽車OTD流程層次分解圖

    從以上的業務關系來看，可能重新將業務分組打包后，業務關系更加明確，見下圖所示。

圖5 重新分組后的關系圖

    從上圖可以看出，重新分組后，每組間的關聯性變小，而組內的業務關聯性是較大的。下面將說明重新分組打包后的好處。

    1 業務耦合降低，職責明確。如感知與預測由市場部負責，訂單管理與執行由銷售部負責，生產與采購部分由生管部負責。大部分業務屬于部門內部，業務流程清晰明確。

    2 由于每個包內耦合度較高，包間耦合度較低。因此整體的業務優化就變成了在滿足外部較少約束前提下的獨立優化。這將大大降低業務優化的復雜性。

    3 系統規劃時，可以將每個包做成一個系統或者模塊，從而實現了系統之間的解耦。降低了系統之間信息交互的復雜性。

    以上僅僅以OTD的業務流程為例進行了分析，并且分析的層次僅限于比較高的層級。如何進行業務ABC的分解，《企業精簡架構》一書中有著較為嚴密的定義及方法論。這里需要特別強調的是，由于各種限制條件（如保護投資、距離限制）等，不見得能夠完全實現ABC的分解。但是，這里再次強調，業務架構是未來系統建設的前提。如果業務架構不能夠非常仔細地推敲，不能夠把業務模塊之間的信息流描繪清晰。未來的系統建設在這個階段就已經埋下了隱患。舉例來說，就如汽車各總成系統的關聯都沒有分析清晰，就期待能夠做出質量和操控感都好的汽車一樣。

2 信息系統架構

    信息系統架構包括了對于應用架構和數據架構。這里不再介紹具體的方法論，而是考慮如何在設計信息系統架構時有效地避免復雜性。在應用系統層面將通過分層和配置的方式來簡化應用系統，從而可以獲得簡單的架構。在數據架構層面將通過分層主數據的思想來考慮我們如何來管理主數據。

    2.1 應用架構

    來看一個業務應用場景。企業從生產/采購計劃開始，到生產/采購管理，以及現場制造的執行。可以將應用系統劃分為兩種模式，如圖6所示：

圖6 生產/采購應用系統劃分

左：同一個系統，不同的模塊；右：根據層次，分為兩個系統

    乍一看，好像統一的應用系統比較理想。但需要站在業務的角度重新思考：

    1）計劃和管理的緊急度和執行不同。有些企業的計劃是月度或者周間計劃，有些是每日的計劃。但是生產執行的系統其要求的程度是分鐘級別。

    2）計算模式不同。生產/采購計劃含有大量的批處理，主要利用的是計算處理能力。而生產/物流的執行涉及到大量的信息采集和信號控制，因此需要快速的交互能力。

    3）對于不同響應級別的系統，其系統需要的高可用和運維級別差異較大。如生產/物流執行系統需要實時熱備，而計劃和管理對于一般制造業而言，具備小時級別的恢復能力就可以了。

    而這里沒有把計劃和管理分開基于兩個模塊的交互信息多，而且其響應級別差異不大，因此將其放在同一系統中。在汽車行業內，計劃/管理一般作為MRP系統，而執行一般作為MES系統。

    談完了系統的分層問題，下面再談談關于實現和配置的復雜性問題。圖7是一個具體的例子，其中類型是應用的類型，實現指具體的系統實現，配置是指對應用系統配置完成具體的業務功能。圖中上半部分指對于生產線的信息采集和發送類型的應用，經過多年的發展，形成了一個非常復雜的系統群。這導致了架構復雜，數據重復，管理運維困難，升級困難等問題。

圖7 信息采集應用系統

    而經過分析，發現這些應用系統的基本功能有許多共同之處，發現系統的類型可以歸結為信息收集和發送。通過設定不同設備接口的配置，可以實現配置實現對生產現場的信息采集以及控制。因此簡化后的應用系統如圖7中的下圖所示。造成這種復雜性的原因是系統在建設時缺少統一的規劃，尤其是缺少未來系統增多時的靈活擴展的考慮。最終造成了出現了大量的煙囪。

    2.2 數據架構

    在業務架構進行合理劃分以及應用系統進行有效分層后，許多時候就將一些數據應該存在的范圍定義下來了。但是企業內部存一些許多系統都會使用到的數據，這些數據稱之為主數據。有的解決方案看起來很美，如下圖：

圖8 主數據的管理和使用

    但是，對于許多企業而言，這種做法不見得是最有效的，有時可能就是一個災難。而且由于涉及到數據的管理流程更多，主數據管理又需要獨立的系統，因此有必要考慮一種簡單的主數據管理方式。首先考慮HR系統，真的有必要把HR系統的主數據獨立于HR的應用系統放在主數據系統中嗎？同樣對于生產的車型信息放在主數據中管理也帶來了較大的復雜性。因為這些系統只提供數據，而且它們的變化速度很慢，外部的系統也不會修改他們的數據。他們只要定期將變化點發送到相關系統即可。因此借助ESB的概念，利用ESB來定期更新其他系統的數據即可，如圖9所示。

圖9 有效利用整合工具來管理主數據

    此外的一種數據，比如對于銀行或者汽車企業的顧客信息。由于其來源廣，信息的真實性以及信息變化后的更新都有較高的要求，可以借鑒主數據管理的流程。但是需要說明的是，可以將同顧客信息緊密相連的應用進行改造，使得它們變成天然一體的應用系統。對于其他需要用到顧客信息的系統可以利用ESB獲取顧客信息以及顧客信息的變化。

    《理想的數據架構的研究和實現》給出的層次模型我比較認可，見圖10。但對于主數據而言，其實現模型值得商榷。從業務架構、應用架構和數據架構綜合考慮才能夠確定是否需要集中的MDM。至少，對于許多已經具有許多系統的企業而言，根據業務和應用系統將主數據的管理分散在不同系統中是個明智的選擇。當然也不能忘記，有些數據雖然不列為公司層次的主數據。但是它們在應用系統中仍然得到大量的使用，可以借鑒主數據的管理思路來有效地管理它們，實現在應用系統層面的集中管理。從而使得應用系統簡單和高效。

圖10 理想的數據架構

    對于交易型系統而言，盡可能做到數據量最小化，這將使得交易系統的性能優良。此外，也使得運維便利。但是數據架構的這些內容最好最到對于用戶透明，通過Portal可以讓用戶的體驗就像在一個系統中一樣。

3 技術架構

    關于技術架構，站在現在的IT發展階段來看。虛擬化和云應該是一個方向，基礎平臺的虛擬化，軟件平臺的統一化將極大地降低復雜性。但是，站在歷史的角度來看，許多企業的軟硬件平臺繁多，軟件版本不同。如何去做才能夠即降低復雜性，又能夠降低風險呢？在該部分主要探討對于小型機應用和開放平臺并存的企業，如何在保護已有投資的基礎上降低復雜性。

    隨著虛擬化技術的逐漸成熟，許多企業將小型機的應用逐漸向虛擬化平臺轉換。而且應用平臺也逐漸向開放平臺轉變，比如從RPG語言向Java的轉變。以第2部分應用架構為例，由于歷史原因，其生產和物流相關的系統多種多樣，企業的生產/采購相關系統如圖11所示。這樣就造成了系統分散和接口復雜，維護困難。

圖11 生產/采購相關系統（優化前）

    結合第二部分的討論，由于生產/采購計劃和管理結合緊密而且計劃層面有非常大量的批處理計算，因此可以分步實施降低復雜性，從而保證整合的成功。因此第一步可以考慮結合應用架構的討論得到第一步。

圖12 生產/采購相關系統（優化后）

    更進一步，可以考慮將生產/物流管理剝離到開放平臺，最后將生產/采購計劃也可以遷移到開放平臺。

4 迭代實現簡單的架構

    在《人月神話》一書中，作者給出了對于大型軟件項目人員和時間關系圖，如圖13所示。從圖中可以發現，如果任務能夠有效分解，人員的投入可以有效降低交付時間。而對于無法進行有效分解導致關系錯綜復雜的任務，人員的投入可能會導致任務更加復雜，從而需要更多的時間去解決問題。

圖13 大型軟件項目人員和時間關系圖

    站在系統論的角度來看，系統的功能大于各元件（或者子系統）功能之和，這是系統的特點。那么對于企業IS而言，如何有效地減少子系統的復雜性而不影響總體系統的功能呢？或者換句話說，如何能夠有效地分解系統，形成功能較為獨立的子系統，而又能很好地實現系統的總體功能呢？結合系統論和IS系統的特點以及上文的一些討論，作者給出了一些關于企業IS建設的建議：

    一、子系統的分割：

    1.1 快慢系統最好在軟硬件上進行分割，通過有效地設計通訊接口服務實現數據的交換。比如單獨的生產實時控制系統和其他業務系統的分割。

    1.2 對于業務功能耦合度低的系統進行有效分割，盡最大可能解耦系統，分割成獨立功能的子系統或者功能模塊。實現單獨業務系統對外的數據服務接口。

    1.3 不同安全級別系統進行有效的分割，比如研發系統、生產系統和辦公系統進行有效分割，其數據交換接口設計為具有安全檢測功能的服務接口。

    1.4 業務處理系統和業務分析系統的分割，確保業務處理系統盡可能輕量級。

    以上分割的基本原則即考慮了系統的解耦，也考慮了較優的投資回報。

    二、子系統的整合

    2.1 構建統一用戶安全管理平臺，管理用戶權限和系統使用安全。

    2.2 構建星形的數據交互平臺，而不要讓各子系統直接通訊，形成太多不必要的耦合。

    2.3 對于主數據管理，建立適當范圍內的主數據。可以考慮分為公司級及應用系統級別（部門級）。

    通過有效地分割和整合，可以實現不同子系統獨立優化，隨著技術的變更或者流程的變更而實現靈活的變更。

    架構的規劃大部分內容是否可以交給供應商呢？當然可以，不過不能夠完全依靠供應商，即使是世界最知名的IT咨詢供應商。IS部門必須培養出較為強大的系統架構能力。因為這是既想節省成本，又想提升IS價值必須培養的能力。(關于新型IS組織的必要能力請參考《新型CIO》領導)

    最后我還想用汽車行業舉一個例子：一輛汽車目前有上萬個零部件，各個級別的供應商加起來可能有上千個。那么到了汽車制造廠的總裝車間，會發現組裝汽車好像很簡單，利用經過簡單培訓的工人即可完成。但是，要看到背后大量智力的投入，那就是良好架構的設計。同樣的，系統的架構設計同汽車設計人員的工作一樣，把系統有效分解，最后實現通過簡單的“拼裝與組合”就可以實現有效支持業務的系統。

核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。

轉載請注明出處：拓步ERP資訊網http://m.guhuozai8.cn/

本文標題：實施精簡的企業架構

本文網址：http://m.guhuozai8.cn/html/consultation/1082004684.html