原文作者：kaiyun開云創(chuàng)新CEO 馬洪喜
“老馬閑評”系列文章正在“深圳kaiyun開云創(chuàng)新”公眾號連載，感興趣的朋友請關(guān)注我們的公眾號，不迷路……
導語
開年過后業(yè)務特別的繁忙，出差也比較多，所以有段時間沒更新了，對不住大家！
上一集（您可以查看“kaiyun開云創(chuàng)新”主頁閱讀原文）咱們聊了數(shù)字化轉(zhuǎn)型的“想轉(zhuǎn)、急轉(zhuǎn)、不敢轉(zhuǎn)”的企業(yè)現(xiàn)狀，主要還是有很多擔心，比如：到底是業(yè)務部門還是技術(shù)部門牽頭，這就是首當其沖的問題。今天，我們再聊聊其他方面的擔憂，就拿“數(shù)字化轉(zhuǎn)型是否會被供應商拿捏住”這個事開聊吧。
正文
老馬我大學畢業(yè)就做乙方了，從來沒體驗過甲方的快樂和苦惱。但是，這么多年我結(jié)交了各行各業(yè)、國內(nèi)國外甲方的好朋友，在閑聊中也體驗到個中滋味。所以我經(jīng)常對我的伙伴們說，簽合同前甲方是牛氣，簽完合同就不同了。如果乙方搞砸項目，最多就是收不了款拍拍屁股做了下一個項目，但甲方面臨的是爛攤子，當初支持乙方的甲方領(lǐng)導可能因為這個項目影響到他的職業(yè)生涯。所以，作為乙方要有“如履薄冰”的心態(tài)，做“對得起朋友，不辜負信任的事兒”。
供應商不認真做事還不能算是被其拿捏，最多是當初看走眼，自食其果。那是否有供應商通過低價或是其他的策略進入一期項目，想進去后通過二期盈利呢？雖然這對大家都不太好，但目前來看這種現(xiàn)象是有的。不僅私有云有，公有云也蠻多的，給予新客戶極大的折扣，來年就恢復原價。但我個人認為，雖然不太爽，但考慮到更換供應商的成本和對方確實此前付出了很多，只要不是太過分的，大多甲方還是會通過談判與乙方繼續(xù)合作，這種也不能算是拿捏。
真正的“拿捏”往往是不受甲乙雙方之可控，但對雙方特別是甲方影響甚大，我列舉以下幾個示例。
前一天還一起加班，第二天被通知離場，項目中斷。我聽說這么一個故事，某甲方公司項目組和某外企供應商的咨詢團隊長期合作，一起加班熬夜上線系統(tǒng)，一起宵夜燒烤啤酒，都混成兄弟了。突然間外企的咨詢團隊收到內(nèi)部郵件，由于該甲方公司被A國列入所謂的“實體名單”，所以必須馬上停止提供技術(shù)服務?？上攵p方項目人員都是懵逼的，其對項目的影響也是巨大的。這種情況可以稱之為“黑天鵝式拿捏”。
沒有一個是錯的，但加在一起有點不對。多供應商參與信息化、數(shù)字化建設(shè)很普遍，在精細化分工大趨勢下，未來將是越來越如此。在傳統(tǒng)合作模式下，特別是分不同包離岸開發(fā)的場景，不同的乙方都有一套自己的“玩法”。就拿中間件來說，有的用Kafka, 有的用RocketMQ，有的用RabbitMQ，選擇什么中間件、技術(shù)框架大多是看乙方架構(gòu)師、程序員的個人擅長或是喜好。各自都沒錯，但當有這樣的若干個項目交付給甲方之后，甲方的運維人員是一頭包：他們面臨N多種技術(shù)組件的N多個版本，監(jiān)控手段、安全手段、排錯和備份手段都不一樣。這樣的尷尬情況可以稱之為“群體性拿捏”。
痛點不大但很痛，求人求己皆不能。我有一個客戶，他們在制造業(yè)也算頭部了，很多業(yè)務系統(tǒng)早就建成了，但當初建設(shè)的時候都是一個個垂直的煙囪，沒有考慮到有一天需要一個橫向的流程，跨越多個系統(tǒng)往復交互數(shù)據(jù)。這個需求還沒有大到專門申請一筆預算立項、招標、采購、項目管理、驗收。而且這個痛點的“痛法”恐怕也是獨特的，沒有供應商駕輕就熟，最多就是在眾多煙囪系統(tǒng)間再橫上個桿子。問題是類似的痛點不止一處，未來還有新的痛法，“治標不治本”的方法只能讓事情更復雜。這個局面不是任何一個供應商造成的，我們稱之為“自我拿捏”。
前面第二集（您可以查看“kaiyun開云創(chuàng)新”主頁閱讀原文）中提到，數(shù)字化轉(zhuǎn)型是“求活路”，本質(zhì)是靠自己，如果輕易的靠某個供應商的某個業(yè)務系統(tǒng)就數(shù)字化成功了，那就不叫轉(zhuǎn)型了，所以“自主可控、數(shù)字化命運掌握在自己手中”是數(shù)字化轉(zhuǎn)型的核心要素。
前面提到的三個“供應商拿捏”的情況，我們再分析一下：
· 黑天鵝式拿捏——根因是過度依賴單一供應商，沒了他,項目玩不轉(zhuǎn)了。
· 群體性拿捏——根因是沒有建立一套甲方自己的標準，任由不同供應商各搞各的。
· 自我拿捏——無論在流程還是技術(shù)上，都缺少跨供應商、跨業(yè)務系統(tǒng)的協(xié)同能力。
無論哪種情況的避免，都需要甲方有自主可控的數(shù)字化建設(shè)思維。這種思維體現(xiàn)在意識、管理、組織、流程、技術(shù)等多個維度。
金融領(lǐng)域一直是數(shù)字化建設(shè)的排頭兵，也是國家層面數(shù)字化指導政策的風向標。早在去年年初，就有《中國銀保監(jiān)會辦公廳關(guān)于銀行業(yè)保險業(yè)數(shù)字化轉(zhuǎn)型的指導意見》一文，該文高屋建瓴的給出了一些具體的指導意見，老馬深表贊同，也建議跨行業(yè)的朋友認真的研究參考一下，這里引用幾點具體的意見：
· 自主研發(fā)——對關(guān)鍵平臺、關(guān)鍵組件以及關(guān)鍵信息基礎(chǔ)設(shè)施要形成自主研發(fā)能力，降低外部依賴、避免單一依賴。
· 研發(fā)平臺——建立能夠快速響應需求的敏捷研發(fā)運維體系，積極引入研發(fā)運維一體化工具，建設(shè)企業(yè)級一站式研發(fā)協(xié)同平臺。
· 標準模塊——主要業(yè)務系統(tǒng)實現(xiàn)平臺化、模塊化、服務化，加強企業(yè)架構(gòu)設(shè)計，實現(xiàn)共性業(yè)務功能的標準化、模塊化。
· 多活中心——優(yōu)化數(shù)據(jù)中心布局，構(gòu)建多中心、多活架構(gòu)，提高基礎(chǔ)設(shè)施資源彈性和持續(xù)供給能力。
我理解其核心要義還在是“自主可控”四字上。自主可控絕對不是指啥事都自己干了，完全不依賴于供應商了，這不僅沒必要，而且是一種巨大的浪費，在“術(shù)業(yè)有專攻”和“越來越精細化”的大背景下，一定是擅長的人做擅長的事是對所有人都好。自主可控是解決被供應商拿捏的手段，但除了主觀上想這樣，還有什么方法論或是配套設(shè)施能“我的地盤我做主”又能“一個好漢三個幫”？答案就是“（甲方）搭臺（多個乙方）唱戲”。先搭好一個臺子，不僅僅是意識之臺、管理之臺、組織之臺、流程之臺，也是技術(shù)之臺，而且往往是通過一個技術(shù)平臺把意識、管理、組織、流程表現(xiàn)出來的。
這個技術(shù)平臺叫什么？有人叫他技術(shù)中臺、業(yè)務中臺，有人叫他PaaS，我們行云稱之為企業(yè)數(shù)字化創(chuàng)新平臺。叫什么其實無所謂，關(guān)鍵是有沒有踐行“搭臺唱戲”的原則，是否能讓甲方在數(shù)字化中“當家作主”，又能組織多個乙方“群策群力”，最終能聚力于數(shù)字化轉(zhuǎn)型這個核心目標上。
后記
有朋友可能看完會說，這不就是“中臺戰(zhàn)略”嘛，人家XXX都已經(jīng)不提中臺了，中臺是偽命題。首先我想說的，那個XXX其實還是提中臺的，是中臺的擁護者。其實，中臺也好，PaaS也好，搞好這些臺子，特別是達到前述效果不太容易，涉及到的復雜因素蠻多的，數(shù)字化轉(zhuǎn)型雖然急迫，但也不能“一口吃成個胖子”。無論選擇什么樣的建設(shè)思路或是技術(shù)路線，終究還是得研究透，這個過程中也是需要有供應商一起出謀劃策的，而不是“閉門造車”。像行云這樣的“見得多點、聊得多點、做得多點”，又長期聚焦于幫助甲方“搭臺唱戲”的團隊，我想能幫到您少走點彎路、做些即務實又長遠的規(guī)劃和建設(shè)。期待和您交個朋友，一起聊聊數(shù)字化轉(zhuǎn)型那些事。
同角度的觀點或是有趣的故事，還請您不吝賜教，期待能成為您數(shù)字化路途上的朋友。
讓企業(yè)都能高效創(chuàng)新
企業(yè)云原生數(shù)字化創(chuàng)新平臺CloudOS?
可插拔云原生工具集Cloud Native Toolkit
開發(fā)者專屬一站式在線服務Methodot
