企業架構 | 亂七八糟的系統建設是怎樣形成的、該怎麼治

IT公社
Apr 14, 2022

--

文章來源於陳果George ,作者GEORGE陳果

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

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

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

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

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

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

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

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

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

總之,很多企業內部亂七八糟的系統建設狀況,不是IT部門不努力,是業務部門“太要”、“太作”,而IT和業務之間又缺乏企業架構管理的協調和仲裁。

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

我認為要從根本上改變企業亂搭亂建資訊系統的現象,企業管理者、業務管理者、IT管理者、諮詢公司顧問們,從理念上要改變三大意識:

一、缺乏“系統實施”的意識,老想重複造輪子:

資訊系統開發的基礎是對資料和業務邏輯的建模,在業務流程和資訊展現層,都是對這些模型的應用。每個資訊系統背後都有一套業務模型,系統越強大,模型越完善;然而每造一個新系統,都需要定義一套業務模型,系統數量越多,就會造成模型重複定義、模型之間口徑打架的問題。

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

2、缺乏“整體架構”的全域性意識:

複雜的大型企業資訊系統,是從組織、流程等不同的角度、多個組織層級對企業進行資料、資訊的建模,大型企業資訊系統不是解決企業內單一業務、單一組織問題的,而恰恰是在單一的一個系統裡,同時支援多組織、多種業務模式的資訊處理和資料整合,這就是大型企業系統和小型系統、自開發系統最大的區別。

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

業務資訊系統建設要基於完整的頂層設計,方能實現資訊整合。

SAP管理控制(CO)的組織建模
SAP銷售和分銷的組織建模
SAP物料管理(MM)的組織建模
SAP生產管理(PP)的組織和資料模型

3、在企業管理資訊系統建設中謹慎引入敏捷方式:

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

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

文章來源於陳果George ,作者GEORGE陳果

※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※

更多精彩內容,按讚我的臉書 IT Value 研討社,獲得24個行業240份企業數位轉型資料喔!等你來看喔 😃

推薦閱讀

企業數位轉型的點、線、面、體!

CIO 必看的有效 IT 管理指南

數智化管理系統| 戰略績效、產銷協同、客戶體驗、智慧運維

盤點5大高頻移動端場景,你不會用就落後了!(內附模板下載)

--

--