亂七八糟的系統建設是怎樣形成的、該怎么治？

發布時間：2021-11-15 瀏覽次數：

導讀：現在時髦講數據治理，我認為企業系統建設混亂也是數據質量低下的主要原因之一。

我經常聽到大企業CIO的抱怨，在他們企業內部，每搞一個新業務，用IT技術來支撐業務是必須的，就要搞一個新系統；每個部門為了有一個自己使用、自己能控制的系統，就一定要專門為自己部門建一套系統。因而，系統建設需求層出不窮，IT部門疲于應付業務部門需求，各種系統亂搭亂建，相應的系統間集成、后續運維也非常復雜?，F在時髦講數據治理，我認為企業系統建設混亂也是數據質量低下的主要原因之一。

以我在CRM領域里的一些觀察為例：例如某金融集團的某個集團總部管理部門為了促進集團內各成員單位的商機轉介紹以及銷售協同，提升集團整合對外的交叉銷售，花了很大功夫新建一個“交叉銷售管理系統”。

又例如，某銀行的對公業務提出了做深行業客戶、賦能客戶經理，對客戶提供具有行業性特色的服務的業務戰略，由于各個行業的客戶的銷售流程、金融產品服務各有不同，這家企業對不同行業的客戶開發了不同的營銷管理平臺，例如面向制造業、房地產行業、物流行業等客戶的數字化系統都各不相同。

再例如某大型金融服務機構發起了大客戶營銷戰略，過去，該司不同的業務線和不同區域對全國性大客戶缺乏整合的營銷和交付體系，為此，該司在總部成立了專門的組織，來統一協調大客戶銷售，由于是新的組織、流程和績效體系，因而要專門開發一套“大客戶銷售管理系統”。

又例如某大型企業在銷售的合同處理流程中，風控、合規、法務、審計、定價審核等等都是不同的部門在管，每個部門都一定要搞個自己部門可控的IT系統，抓著IT部門非要不可，所以這家企業在處理一個客戶合同時，需要在不同的信息系統中批來審去。

我認為以上這幾個例子，單獨建設新的信息系統可能都存在著對企業架構認識的誤區——這些業務實際上都是企業級銷售管理體系的一部分，應該是對現有CRM系統的實施改造，或者/并且基于現有CRM系統的前端外掛系統開發：其一，交叉銷售是典型的CRM內部流程，其二，現代銀行CRM都應該整合客戶信息分析（KYC）或者反洗錢（AML）的外掛平臺，其三，大客戶銷售只是CRM中的一套流程體系，而不是另外再搞一個獨立的CRM系統，其四，合同處理是個端到端的流程，各個管理機構應該是提供流程服務，而不是各建獨立王國。

有意思的是，這類系統亂搭亂建的現象在制造業里相對來說似乎比較少，可能是由于制造業很早就形成了信息系統應用架構的共識，以ERP為企業核心系統，PLM、MES、SCM等系統各歸其位，和金融機構比，制造業的企業架構模式相對來說比較標準化。

其次，因為制造業的工業化組織特點以及受ERP管理理念影響較深，與之相對，金融行業這類服務行業的外部環境變化動蕩，內部管理更強調績效結果而非流程管理，組織文化強調個體或部門業績而非整體協作，因而，制造企業的跨部門信息集成、業務流程管理的思想理念，相對來說要強于金融企業。

這些因素造成了中國金融行業的信息化建設和制造業相比，不愛用套件，偏愛自己開發，也確實有資源搞系統開發——中國的銀行、保險、證券公司的IT部門動不動就幾百人、上千人。目前在中國，企業架構治理、數據治理這些課題，和其他行業相比，金融行業看起來最熱，為什么？因為金融行業的企業架構從理念到實踐都最混亂，因為亂才需要治理??！除了金融行業外，消費品、零售、物流等服務性行業也是企業架構管理的重災區。

總之，很多企業內部亂七八糟的系統建設狀況，不是IT部門不努力，是業務部門“太要”、“太作”，而IT和業務之間又缺乏企業架構管理的協調和仲裁。（參見《數字化轉型亂象｜數字化越努力，管理水平越低》）

不僅是企業管理者，不少很有經驗的咨詢顧問、技術工程師都容易犯這個錯誤——咨詢顧問是客戶要什么，我就順著客戶把故事編圓了；技術工程師是客戶要什么，我就幫客戶用技術來實現。他們這些因為工作性質而帶來的工作習慣，都是因為缺乏架構思維；一個真正能交付客戶價值的數字化轉型項目，應該是咨詢顧問、架構師和工程師協同工作，充分發揮個體特長，把握正確的項目方向。

我認為要從根本上改變企業亂搭亂建信息系統的現象，企業管理者、業務管理者、IT管理者、咨詢公司顧問們，從理念上要改變三大意識：

一、缺乏“系統實施”的意識，老想重復造輪子：

信息系統開發的基礎是對數據和業務邏輯的建模，在業務流程和信息展現層，都是對這些模型的應用。每個信息系統背后都有一套業務模型，系統越強大，模型越完善；然而每造一個新系統，都需要定義一套業務模型，系統數量越多，就會造成模型重復定義、模型之間口徑打架的問題。（參見《中臺建設記》）

很多企業缺乏“系統實施”意識，即利用一個信息系統套件（COTS），通常商品化套件因為經過多個企業使用，具備較為規范、完善、跨企業的業務建模。根據系統蘊含的內在邏輯，在現有業務和系統邏輯之間找到折衷的目標運作模式，即所謂的“業務藍圖”，并按照業務藍圖來改變現有業務以適應系統使用。即便是開發新系統，要充分利用現有IT系統的數據模型和服務，盡可能減少新增模型的復雜度。

二、缺乏“整體架構”的全局意識：

復雜的大型企業信息系統，是從組織、流程等不同的角度、多個組織層級對企業進行數據、信息的建模，大型企業信息系統不是解決企業內單一業務、單一組織問題的，而恰恰是在單一的一個系統里，同時支持多組織、多種業務模式的信息處理和數據整合，這就是大型企業系統和小型系統、自開發系統最大的區別。

SAP ERP系統可以說是企業架構的巔峰之作，而這在三十年前就已經形成了——企業架構并不是一個新東西。前段時間我和一個同事聊起某全球性大企業在不同國家、有不同業務線和業務模式的IT規劃，同事說，這得有多少套IT系統啊！我說這就是SAP ERP最擅長的領域，也是SAP ERP區別于其他所有信息系統的獨特之處——SAP ERP的架構就是在一個系統里支持復雜的全球性企業，無論是多維的管理控制主體、會計核算主體、多種會計準則、公司間交易，還是物料管理的全球采購組織、庫存業財一體化，銷售管理的銷售渠道和銷售組織設計，制造管理的計劃參數、產品核算等，都支持集團化企業的不同維度、不同模式的各種交叉組合。

業務信息系統建設要基于完整的頂層設計，方能實現信息整合。

三、在企業管理信息系統建設中謹慎引入敏捷方式：

在數字化轉型時代，“敏捷”成為一種時髦的數字化理念，我觀察到國內甚至有些銀行、證券公司在某些咨詢公司推動下實現了全盤敏捷化組織——分拆IT部門，鼓吹全面解耦、分拆穩態的企業級后臺系統，

對于建設面向復雜環境的數字化前端，敏捷方法是有意義和價值的，但是，對企業后臺管理系統不能亂搞敏捷，要充分利用現有的后臺系統的業務模型。缺乏企業架構治理約束的敏捷，容易帶來系統和數據的混亂。

版權歸原作者所有,如有侵權請聯系刪除。