企業數字化轉型的8點思考

來源：《智能制造那點事》、資訊化協同創新專委會（ID：CF-ICI）

比對能力模型的目标設定

很多企業的上司，尤其是偏業務部門的上司，說要搞數字化轉型，便讓HR在市場上高薪招聘一個智能制造總監，然後就說幹吧。

數字化轉型不是一個人兩個人能搞起來的，企業在确定要搞數字化轉型，在制定數字化轉型戰略目标的時候，一定不能忘記的事，要進行Capability Study，如果隻管目标制定，不對能力進行比對分析，結果往往目标可能無法落地。

關于數字化轉型能力建設，行業内有一種做法，我個人覺得還是蠻可行的，即在業務部門搭建數字化轉型團隊來牽頭企業數字化轉型整體規劃，該團隊直接彙報給負責企業數字化轉型的VP。

業務部門牽頭推動數字轉型，正常的組織能力規模可分為3類：

規模小，一般2～3人，負責與管理層、各業務部門對接，整合和落實管理層業務戰略願景，并推動具體業務部門和IT執行落地；

規模中，一般7～8人，包含各具體業務領域知識的專家，如懂供應鍊、工藝開發、生産營運、裝置标準、前沿先進技術、品質管理細分領域的；

規模稍大，人數10人以上，除包含規模中的能力外，還包含部分資料研究分析能力，能夠針對特定場景的核心過程資料，能夠進行分析，并總結、提煉，配合供應商進行模型研究。

整體規劃的重要性

其實智能制造和數字化轉型沒有統一的标準，做的多也不代表你就是智能制造，做的少也不代表你就不是，智能制造和數字化轉型其實就是要解決企業的痛點。

如果通過新一代資訊技術賦能企業業務痛點問題的解決，狹義的來講，你的項目就是智能制造項目，沒有必要去上自己不需要的東西，這裡特别強調一點，沒有必要為了新技術而新技術，新技術一定是伴随着解決某個具體問題的，如5G，是解決帶寬、延遲還是其他什麼現有網絡面臨的痛點。

整體規劃其實在做一件事情，即定義清楚在什麼時候需要解決什麼問題，鎖定的是兩個次元屬性，時間次元和需求次元。

那為什麼整體規劃這麼重要呢？

整體規劃能夠讓管理層看到未來2～3年的整體藍圖，更容易界定這個标的是不是與他對企業或者戰略發展方向的定位是相吻合的，管理層的認同對于後續下面執行層的推動是非常有利的，行業有一種說法叫“所謂上司重視的項目一般都比較好推”；

有了清晰的整體規劃，更好識别促成整體規劃可落地的相關資源要素的比對，如預算、人才等；

整體規劃也是對企業現狀的一種最好的摸底，雖然說規劃要仰望星空、對标一流，但我們不能忽視規劃最最重要的屬性，即立足于企業當下和實際。

通過整體規劃的行動，識别出企業當下面臨的困難和業務痛點，有時候我們會說，整體規劃也是一種持續改善；

如果沒有整體規劃，很容易被乙方的顧問給”帶偏了“。

乙方一般的政策是買解決方案附帶賣産品，站在乙方的視角，我也非常能了解，他們需要盡可能把自家的産品賣給客戶，賣的越好，業績就會越好。

很少有乙方在講解決方案的時候，對使用者的現狀進行全局分析的，如甲方已經有什麼，哪些地方做的好，哪些地方做的不好，我的解決方案是否真的能夠給甲方帶來價值提升，我賣的解決方案對甲方來說是must，還是nice to have？

細心的小夥伴可能會發現，很多顧問在甲方講解決方案的時候，都是一個勁的在講，我有什麼，我有什麼，估計有90%的時間都在講我有什麼，很少有顧問願意用50%的時間來分析你需要什麼，然後再用50%的時間來講我有什麼。

加強業務和IT的深度融合

提到兩化融合，工業化和資訊化的融合，大家都不陌生，站在甲方的視角，真正落實兩化融合，首先最應該做的，在管理模式上要落實業務部門和IT部門的融合。

業務融合這個概念很多年前就有人提，提這些概念的人希望傳統IT的從業者，能夠更加主動地、積極地多了解業務、多深入業務、還有人說業務融合的最高目标是IT人要比業務更懂業務。

制造企業和網際網路企業不同，網際網路企業，一個211/985計算機專業畢業的應屆生，一般3個月到半年時間就可以在Team内獨立的工作，3年内，悟性不錯的人，基本就可以晉升為Team Leader，獨當一面帶團隊。

相比網際網路行業，制造業的流程和體系更為複雜，我身邊認識一些985名校畢業的研究所學生，一些工作2年以上，也隻能做些點狀的事情。

經常會有朋友問，數字化轉型誰牽頭會更合适。

我個人不成熟的觀點是，業務架構（我要什麼）由業務規劃團隊牽頭規劃、技術架構（我怎麼實作）由IT團隊牽頭規劃，基于3點考慮：

①業務架構更多展現業務管理層對于部門業務中長期的發展戰略定位和業務部門運作流程，業務比IT更了解業務，更重要的一點，相比IT，業務規劃團隊有獨特的優勢，他們有更多的機會和管理層進一起開會、訪談交流，他們更懂管理層的心聲；

②技術架構更偏向底層技術，IT會比業務更懂，知道如何進行資源部署配置，實作性能最優，如使用5G還是wifi，部署私有雲還是公有雲等；

③IT要和業務保持密切的協作，建構管理Council機制，IT人員前期可以參與業務架構規劃的讨論和交流中，從技術層面，給業務人員提供技術指導，便于業務架構最終可實施的可能性。

業務和IT深度融合的過程中，有一點稍微提一下，可能有些企業在推這種模式中面臨的問題，功勞屬于誰。

業務和IT的深度融合，要求雙方團隊都要保持開放、包容的心态，因為這種合作模式和傳統的業務隻提需求，IT全權負責的模式可能有些不同，這種模式前期業務主導，後期IT主導。

是以關于誰的功勞更大，其實這個問題本身也不是問題，畢竟IT彙報給IT線，業務彙報給業務線，本身也不是一條線彙報，IT不必和業務計較，業務也不必和IT計較，各有各的績效考核管理線。

項目做的好，雙方都可以得到褒獎。

精選産品供應商組合政策

數字化轉型涉及的業務面非常廣，要落實企業基于一個流程的執行，很多企業都實施了幾十個，上百個不同的IT系統。表面上看呢，感覺資訊化做的很成功的，但仔細一分析，很多系統都是靠着兄弟們的血汗在人肉運維才可以支撐下去。

一般業務在做業務架構規劃時，是基于企業的價值鍊流程來識别業務需求，是以作為甲方數字化轉型相關的規劃團隊，除了日常要不斷積累業務經驗，也不要忘記去多走出去，了解和對标行業内标杆企業和标杆乙方解決方案，有能力去識别、判定和積累，形成符合企業潛在需求的知識庫，以便在項目真正來臨的時候，不至于盲人摸象，不知所措。

拿汽車行業來說，有人說選擇大品牌肯定是不會錯的，我都選西門子、我都選SAP，或者我都選達索，仔細研究過的小夥伴們會發現，其實這些大公司，他們雖然産品鍊很廣，但并不是每一個産品都是你所在的行業的最佳解決方案。

對乙方而言，他們肯定想賣全套解決方案，賣點很簡單，同一家産品，容易整合，但知道内情的小夥伴也了解，其實很多軟體也是他們買回來後再整合的，整合的力度是否真的好，也是有疑問的。

是以，如何選擇供應商組合政策，這個工作乙方一般給不了，隻有靠甲方自己，通過時間和實踐不斷去摸索和總結、提煉，因為即使一個咨詢項目，偏産品解決方案的供應商他們帶有産品傾向性，那些純咨詢公司往往又偏向頂層戰略、流程規劃。

目前，針對這個情況，若甲方真的不具備能力做規劃，一種可行的辦法是找行業内口碑不錯的，第三方監理機構，他們可能更加中立。

細分産品Make / Buy開發政策

構成數字化轉型的系統，主要有兩類，一類是自主開發Make，一類是采購Buy，在工業網際網路時代，伴随着開源軟體、靈活開發、使用者體驗、透明營運管理、資料分析等需求越來越多，Make的需求也變的越來越多，那我們在前期規劃時，哪些系統适合采購商業化套件，哪些适合自主獨立開發呢，才能形成比較完善的開發疊代模式？

偏向工業知識know how多的，這類的軟體都比較适合Buy，如PLM、仿真軟體、SAP、MES等。

如果選擇自主開發，一方面周期長，另一方面，這些系統的底層資料模型非常複雜，沒有對業務非常精通的架構師，開發出來的系統，後期對業務可持續拓展的能力是非常薄弱的；

傳統工業軟體的輕量化适合Make，比方說PLM軟體的很多loading、UI界面、各種使用者傳遞的data reports等。

SAP系統的生産計劃和MRP，我個人覺得這些國外的工業軟體最大的優勢是底層的data model的規劃，最大的缺點是笨重，開發了很多使用者不需要的功能，顯得非常笨重，使用者體驗不好，随着帶來的問題就是性能慢。

面向終端使用者2C的，如果甲方IT開發能力比較強，可以選擇Make，因為這塊業務是最能彰顯企業對于使用者體驗和個性化需求的追求；

面向企業營運管理的，一般建議Make。

一方面這些資料量不是特别多，而且資料基本都較為保密。

另外一方面，這些資料往往都來源于上下遊各個應用系統，甲方主導來協調各方面資源、推動起來會比乙方更容易一些，營運資料管理本身也沒有特别大的技術難度。

變革甲乙雙方合作模式

甲方乙方的合作模式乙方有兩種，固定總價合同fixed price和人天合同T&M，以前很多企業的資訊化項目都比較傾向于選擇fixed price，這個對甲方來說，簡單而且風險低，傳遞的品質和過程管控的壓力都丢給了供應商，fixed price合同不好的地方是什麼呢？

耗費周期長，因為固定總價，是以潛在甲乙雙方在準備SOW的時候，字字斟酌，乙方擔心前期若範圍不談清楚，後期範圍的變更承受不了；

靈活性差，偏管理類的資訊化項目，即使前期規劃的很多，但是在具體實施過程中，還是會存在很多需求的變更和調整，針對fixed price的合同，後期的每次需求變更都需要反複和乙方扯皮；

不可持續，fixed price合同一般都有固定的項目結束周期，項目上線傳遞後，乙方通過驗收，基本就撤離了，交給甲方來營運管理，很多企業的甲方一方面可能沒有能力、另外一方面可能也不是很重視營運，導緻很多上線的項目和系統，半年後，就黃了，很少有人用。

數字化轉型時期，一種新的甲乙合作模式可能會更加适應這種快速疊代、靈活和多變性：

甲方負責整體規劃和項目管理，甲方根據内部人力資源缺口，重點是資源能力缺口，定義各種外部資源不同組合的能力模型需求，比方說，方案顧問、實施顧問、開發顧問、測試顧問等。

根據不同能力需求去乙方挑選不同的人來支援這個項目，能力要求高的可以去原廠商挑，能力要求弱些的可以去原廠商的代理商挑。

這樣乙方不在是賣項目的傳遞，是賣能力和知識的傳遞，甲方也不是甩手掌櫃了，甲方要真正承擔起項目最終傳遞品質的職責和義務。

這種做法可以為企業節省很多成本，我之前管理的一個項目群，就是按照這個模式來運作的，少說會公司節省小幾百萬的投資。

甲方要真正能朝着這個合作模式走，有3個必要的條件要滿足：

01

甲方内部有這方面有規劃能力、綜合項目管理能力的人；

02

甲方可以和相關潛在合作供應商簽署戰略人天合作架構協定；。

03

乙方也願意配合甲方這種人天合作模式。

重視上線營運管理政策

偏強業務管理類的系統，如PLM、ERP、MES，傳統的桌面運維helpdesk是運維不了的，我們所說的營運，不是隻是保證伺服器不當機，那個是狹義的運維，不是營運，系統營運的概念，首先得了解和熟悉這個系統内落地實施的流程，在使用者不清楚或者不懂的情況下，具備教育訓練和引導的職責，同時對系統運作的資料可進行配置、運作狀态進行分析和提出優化改善建議。

一個系統或者項目上線，隻是萬裡長征邁開了第一步，其實真正的挑戰和困難是營運不是上線。為什麼現在很多企業的資訊化項目上了很多，但回報都是用的不好呢，這有很多原因造成的：

很多軟體不是為企業的業務量身定做的，項目實施過程期間，真正的使用者往往參與的時間很短。

一般就需求調研階段和使用者接受測試UAT（User Acceptance Test）階段，加起來估計也不足半個月，而且好多業務關鍵使用者在這個參與其間，又不是全職，還有很多本職的工作。

是以在這個階段，想讓最終使用的使用者能對系統功能和體驗做出很恰當判定是不可能的；

項目功能測試的資料也是僞造的，UAT測試不可能把所有的業務流程都能按照1：1實物流程運作一遍，這個時候的測試往往并不能識别很多潛在的問題；

業務的需求在不斷的變化，很多業務本身也是在不斷通過項目不斷優化和完善，是以不可能基于半年前或者一年前提的需求，還能那麼好的相容；

軟體系統的笨重和複雜，若沒有足夠的營運支援和不斷的教育訓練推廣，很多使用者就放棄使用了。

那如何制定合适的營運政策呢？

系統IT系統運維政策，保證系統的運作穩定性、可靠性和性能；

制定業務資料營運，針對系統内的業務資料品質和流程，根據實際使用者的使用情況，定期分析和評估判定，識别出影響系統應用的潛在問題和風險，并和規劃團隊進行溝通，制定改善政策；

制定系統使用者推廣機制，包含教育訓練、日常問題對接處理響應機制。

不忘前沿技術的研究儲備

如果說第1～第7點都是腳踏實地，那第8點算是錦上添花。

新技術的誕生到商業化的應用，一般都有一個很漫長的時間差。對于傳統制造業來說，這個時間差可能會更長。

有人說，針對新技術的應用，傳統制造業要比網際網路行業至少落後5～10年。那作為制造企業的數字化轉型團隊，如何做到既保障内部穩定，又不落後于行業的先行者們呢？

參觀對标交流，通過學習别人的案例，了解前沿技術的儲備和應用情況，這個也是最簡單、最直接、最可行的方式，通過看和聽來了解；

嘗試和一些具有代表性的企業展開一些合作研究，比方說AI算法如何應用于工藝過程品質預防；

經濟條件允許的企業，可以内部設定一些先進技術研究實驗室，可以聯合高校、生态圈其他同行建立聯合創新項目，真正落實産學研一體化融合，讓高等學府的孩子們能夠盡早了解企業的需求。

總結

數字化轉型是一個複雜的體系化工程，對于甲方來說，要有真正勝任的人來牽頭，整合内部資源和外部資源，形成真正的數字化轉型生态圈或者聯盟，讓合作更加融合，讓模式更加多元化。

數字化轉型不是一朝一夕的事情，要做好打持久戰的準備。

作為企業數字化轉型的牽頭人，要能深刻認識到，數字化轉型不是一批項目上線就結束了，要始終秉持持續的、精益的營運改善思維和理念，在數字化轉型過程培養人才，在培養人才過程中促成企業數字化轉型更新。

轉自公衆号：工業網際網路前線