引言
上周發表了一篇《站在甲方視角，淺談工業互聯網平臺那點事兒》，結果收到了來自圈內各位前輩、良師益友的私信、朋友圈轉發和點評，閱讀量近3000，之一次發文，收到這么多的點評，真是蠻感動的。有人覺得觀點挺好的，視角獨特，讀完之后很受啟發；也有人觀點過于偏激，有點負能量；也有人私信我說，那你是不是也可以站在甲方視角，說說咱們工業互聯網時代到底需要什么呢？那么今天，站在甲方視角，簡單和大家一起來聊聊工業互聯時代，企業數字化轉型的8點思考。
1、匹配能力模型的目標設定
很多企業的領導，尤其是偏業務部門的領導，說要搞數字化轉型，便讓HR在市場上高薪 *** 一個智能制造總監，然后就說干吧。數字化轉型不是一個人兩個人能搞起來的，企業在確定要搞數字化轉型，在制定數字化轉型戰略目標的時候，一定不能忘記的事，要進行Capability Study，如果只管目標制定，不對能力進行匹配分析，結果往往目標可能無法落地。
關于數字化轉型能力建設，行業內有一種做法，我個人覺得還是蠻可行的，即在業務部門搭建數字化轉型團隊來牽頭企業數字化轉型整體規劃，該團隊直接匯報給負責企業數字化轉型的VP。業務部門牽頭推動數字轉型，常規的組織能力規?？煞譃?類：
添加微信好友, 獲取更多信息
復制微信號
規模小，一般2～3人，負責與管理層、各業務部門對接，整合和落實管理層業務戰略愿景，并推動具體業務部門和IT執行落地；
規模中，一般7～8人，包含各具體業務領域知識的專家，如懂供應鏈、工藝開發、生產運營、設備標準、前沿先進技術、質量管理細分領域的；
規模稍大，人數10人以上，除包含規模中的能力外，還包含部分數據研究分析能力，能夠針對特定場景的核心過程數據，能夠進行分析，并總結、提煉，配合供應商進行模型研究。
2、整體規劃的重要性
其實智能制造和數字化轉型沒有統一的標準，做的多也不代表你就是智能制造，做的少也不代表你就不是，智能制造和數字化轉型其實就是要解決企業的痛點，如果通過新一代信息技術賦能企業業務痛點問題的解決，狹義的來講，你的項目就是智能制造項目，沒有必要去上自己不需要的東西，這里特別強調一點，沒有必要為了新技術而新技術，新技術一定是伴隨著解決某個具體問題的，如5G，是解決帶寬、延遲還是其他什么現有 *** 面臨的痛點。
整體規劃其實在做一件事情，即定義清楚在什么時候需要解決什么問題，鎖定的是兩個維度屬性，時間維度和需求維度。那為什么整體規劃這么重要呢？
整體規劃能夠讓管理層看到未來2～3年的整體藍圖，更容易界定這個標的是不是與他對企業或者戰略發展方向的定位是相吻合的，管理層的認同對于后續下面執行層的推動是非常有利的，行業有一種說法叫“所謂領導重視的項目一般都比較好推”；
有了清晰的整體規劃，更好識別促成整體規劃可落地的相關資源要素的匹配，如預算、人才等；
整體規劃也是對企業現狀的一種更好的摸底，雖然說規劃要仰望星空、對標一流，但我們不能忽視規劃最最重要的屬性，即立足于企業當下和實際。通過整體規劃的行動，識別出企業當下面臨的困難和業務痛點，有時候我們會說，整體規劃也是一種持續改善；
如果沒有整體規劃，很容易被乙方的顧問給”帶偏了“。乙方一般的策略是買解決方案附帶賣產品，站在乙方的視角，我也非常能理解，他們需要盡可能把自家的產品賣給客戶，賣的越好，業績就會越好。很少有乙方在講解決方案的時候，對用戶的現狀進行全局分析的，如甲方已經有什么，哪些地方做的好，哪些地方做的不好，我的解決方案是否真的能夠給甲方帶來價值提升，我賣的解決方案對甲方來說是must，還是nice to have？細心的小伙伴可能會發現，很多顧問在甲方講解決方案的時候，都是一個勁的在講，我有什么，我有什么，估計有90%的時間都在講我有什么，很少有顧問愿意用50%的時間來分析你需要什么，然后再用50%的時間來講我有什么。
3、加強業務和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計較，各有各的績效考核管理線。項目做的好，雙方都可以得到褒獎。
4、精選產品供應商組合策略
數字化轉型涉及的業務面非常廣，要落實企業基于一個流的執行，很多企業都實施了幾十個，上百個不同的IT系統。表面上看呢，感覺信息化做的很成功的，但仔細一分析，很多系統都是靠著兄弟們的血汗在人肉運維才可以支撐下去。
一般業務在做業務架構規劃時，是基于企業的價值鏈流程來識別業務需求，所以作為甲方數字化轉型相關的規劃團隊，除了日常要不斷積累業務經驗，也不要忘記去多走出去，了解和對標行業內標桿企業和標桿乙方解決方案，有能力去識別、判定和積累，形成符合企業潛在需求的知識庫，以便在項目真正來臨的時候，不至于盲人摸象，不知所措。
拿汽車行業來說，有人說選擇大品牌肯定是不會錯的，我都選西門子、我都選SAP，或者我都選達索，仔細研究過的小伙伴們會發現，其實這些大公司，他們雖然產品鏈很廣，但并不是每一個產品都是你所在的行業的更佳解決方案，對乙方而言，他們肯定想賣 *** 解決解決方案，賣點很簡單，同一家產品，容易整合，但知道內情的小伙伴也了解，其實很多軟件也是他們買回來后再整合的，整合的力度是否真的好，也是有疑問的。所以，如何選擇供應商組合策略，這個工作乙方一般給不了，只有靠甲方自己，通過時間和實踐不斷去摸索和總結、提煉，因為即使起一個咨詢項目，偏產品解決方案的供應商他們帶有產品傾向性，那些純咨詢公司往往又偏向頂層戰略、流程規劃。目前，針對這個情況，若甲方真的不具備能力做規劃，一種可行的辦法是找行業內口碑不錯的，第三方監理機構，他們可能更加中立。
圖1：基于全價值鏈供應商組合策略sample
5、細分產品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，一方面這些數據量不是特別多，而且數據基本都較為保密，另外一方面，這些數據往往都來源于上下游各個應用系統，甲方主導來協調各方面資源、推動起來會比乙方更容易一些，運營數據管理本身也沒有特別大的技術難度。
6、變革甲乙雙方合作模式
甲方乙方的合作模式乙方有兩種，固定總價合同fixed price和人天合同T&M，以前很多企業的信息化項目都比較傾向于選擇fixed price，這個對甲方來說，簡單而且風險低，交付的質量和過程管控的壓力都丟給了供應商，fixed price合同不好的地方是什么呢？
耗費周期長，因為固定總價，所以潛在甲乙雙方在準備SOW的時候，字字斟酌，乙方擔心前期若范圍不談清楚，后期范圍的變更承受不了；
靈活性差，偏管理類的信息化項目，即使前期規劃的很多，但是在具體實施過程中，還是會存在很多需求的變更和調整，針對fixed price的合同，后期的每次需求變更都需要反復和乙方扯皮；
不可持續，fixed price合同一般都有固定的項目結束周期，項目上線交付后，乙方通過驗收，基本就撤離了，交給甲方來運營管理，很多企業的甲方一方面可能沒有能力、另外一方面可能也不是很重視運營，導致很多上線的項目和系統，半年后，就黃了，很少有人用。
數字化轉型時期，一種新的甲乙合作模式可能會更加適應這種快速迭代、靈活和多變性：甲方負責整體規劃和項目管理，甲方根據內部人力資源缺口，重點是資源能力缺口，定義各種外部資源不同組合的能力模型需求，比方說，方案顧問、實施顧問、開發顧問、測試顧問等，根據不同能力需求去乙方挑選不同的人來支持這個項目，能力要求高的可以去原廠商挑，能力要求弱些的可以去原廠商的 *** 商挑，這樣乙方不在是賣項目的交付，是賣能力和知識的交付，甲方也不是甩手掌柜了，甲方要真正承擔起項目最終交付質量的職責和義務。這種做法可以為企業節省很多成本，我之前管理的一個項目群，就是按照這個模式來運作的，少說會公司節省小幾百萬的投資。
甲方要真正能朝著這個合作模式走，有個必要的條件要滿足：
甲方內部有這方面有規劃能力、綜合項目管理能力的人；
甲方可以和相關潛在合作供應商簽署戰略人天合作框架協議；
乙方也愿意配合甲方這種人天合作模式。
7、重視上線運營管理策略
偏強業務管理類的系統，如PLM、ERP、MES，傳統的桌面運維helpdesk是運維不了的，我們所說的運營，不是只是保證服務器不宕機，那個是狹義的運維，不是運營，系統運營的概念，首先得了解和熟悉這個系統內落地實施的流程，在用戶不清楚或者不懂的情況下，具備培訓和引導的職責，同時對系統運行的數據可進行配置、運行狀態進行分析和提出優化改善建議。
一個系統或者項目上線，只是萬里長征邁開了之一步，其實真正的挑戰和困難是運營不是上線。為什么現在很多企業的信息化項目上了很多，但反饋都是用的不好呢，這有很多原因造成的：
很多軟件不是為企業的業務量身定做的，項目實施過程期間，真正的用戶往往參與的時間很短，一般就需求調研階段和用戶接受測試UAT（User Acceptance Test）階段，加起來估計也不足半個月，而且好多業務關鍵用戶在這個參與其間，又不是 *** ，還有很多本職的工作，所以在這個階段，想讓最終使用的用戶能對系統功能和體驗做出很恰當判定是不可能的；
項目功能測試的數據也是偽造的，UAT測試不可能把所有的業務流程都能按照1：1實物流程運作一遍，這個時候的測試往往并不能識別很多潛在的問題；
業務的需求在不斷的變化，很多業務本身也是在不斷通過項目不斷優化和完善，因此不可能基于半年前或者一年前提的需求，還能那么好的兼容；
軟件系統的笨重和復雜，若沒有足夠的運營支持和不斷的培訓推廣，很多用戶就放棄使用了。
那如何制定合適的運營策略呢？
系統IT系統運維策略，保證系統的運行穩定性、可靠性和性能；
制定業務數據運營，針對系統內的業務數據質量和流程，根據實際用戶的使用情況，定期分析和評估判定，識別出影響系統應用的潛在問題和風險，并和規劃團隊進行溝通，制定改善策略；
制定系統用戶推廣機制，包含培訓、日常問題對接處理響應機制。
8、不忘前沿技術的研究儲備
如果說第1～第7點都是腳踏實地，那第8點算是錦上添花。新技術的誕生到商業化的應用，一般都有一個很漫長的時間差。對于傳統制造業來說，這個時間差可能會更長。有人說，針對新技術的應用，傳統制造業要比互聯網行業至少落后5～10年。那作為制造企業的數字化轉型團隊，如何做到既保障內部穩定，又不落后于行業的先行者們呢？
參觀對標交流，通過學習別人的案例，了解前沿技術的儲備和應用情況，這個也是最簡單、最直接、最可行的方式，通過看和聽來了解；
嘗試和一些具有代表性的企業展開一些合作研究，比方說AI算法如何應用于工藝過程質量預防；
經濟條件允許的企業，可以內部設置一些先進技術研究實驗室，可以聯合高校、生態圈其他同行建立聯合創新項目，真正落實產學研一體化融合，讓高等學府的孩子們能夠盡早了解企業的需求。
總結
數字化轉型是一個復雜的體系化工程，對于甲方來說，要有真正勝任的人來牽頭，整合內部資源和外部資源，形成真正的數字化轉型生態圈或者聯盟，讓合作更加融合，讓模式更加多元化。數字化轉型不是一朝一夕的事情，要做好打持久戰的準備。作為企業數字化轉型的牽頭人，要能深刻認識到，數字化轉型不是一批項目上線就結束了，要始終秉持持續的、精益的運營改善思維和理念，在數字化轉型過程培養人才，在培養人才過程中促成企業數字化轉型升級。
