甲方 IT 日益壯大，企業服務軟體行業面臨的困境與出路

作者 | 付曉岩

審校 | 羅燕珊

近年來，随着數字化轉型的深入發展，軟體行業的企業服務端正是“忙”時候，畢竟也算是多個周期的疊加：國産化周期、數字化周期、自發重構周期、基礎設施更新周期等，多種因素都在推動軟體的大規翻新，這裡還沒有加上若隐若現的“人工智能”周期。

但是，“忙”歸忙，收入好像不太如意，甚至到了有些“危險”的境地，近年來确實不乏乙方公司單子越大越虧的情況，是以也有業界專家為此鳴不平。到底該如何看待這個現象？做企業服務的軟體公司未來會是何種走向？這些問題不容易回答，畢竟有些事情行業裡的人就算心知肚明也無可奈何，而未來從來都是充滿不确定性的。筆者就根據自己的感受聊聊這個話題吧。

筆者自己現在算是個獨立的小微乙方，提供企業架構、業務架構咨詢服務，由于這兩項專業服務現在與數字化轉型關系密切，是以也會提供數字化轉型方面的服務，算是服務能力的延伸吧。筆者自立門戶也就一年半左右，之前曾在國有大行工作了 20 年，業務線 12 年、IT 線 8 年，在内部甲方提過需求、在内部乙方參加過企業級工程實施，做過核心業務架構師，還随着企業組織結構調整，得以在銀行系最大的金融科技子公司管了 2 年多的風險合規工作。離開銀行後在 IT 頭部外資咨詢公司、頭部網際網路企業雲服務團隊工作過，在網際網路中小型企業也做過一段時間高管。就甲乙方的工作來講，筆者采購過别人，也被别人采購過，兩方面都有些體會，隻不過采購經驗談不上深。

關于企服端軟體行業經營的不如意，筆者自己也跟一些大乙方打過交道，是以也略有耳聞，在這面，筆者有如下感想：

低價的長期影響

從現象看，單就價格問題來講，長期“低價”并非好事情。這個并非針對軟體行業而言，放在整個經濟領域都是如此，站在經濟學視角看，“價格”也相當于經濟的“體溫計”，人要想活得舒服，就得維持在 36.6 度上下，不能差太遠。

企業就相當于經濟中“人”，“價格”就是企業的體感溫度，當然，穿透了看，“利潤”更代表真實溫度，但是，“價格”對“利潤”的影響很直接，而且“價格”更“可見”，是交易中談判的“對象”，成交也是達成一緻的“價格”，是以，通常用“價格”來解釋一切。“價格”太低，“人”就會一直“打哆嗦”來增加“體溫”，但是“打哆嗦”消耗能量很快，打着打着，企業可能就“打”沒了。

其實這麼多年來的網際網路發展，雖然讓老百姓在消費方面赢得了很多實惠，但是長期的“低價”也會讓提供消費服務的企業發展遇到困難，而且這個困難會沿着産業鍊傳遞，從 ToC 的企業一點兒一點兒傳遞給 ToB 的企業，這時候隻有壟斷資源或具有一定壟斷性的行業會好過些。其實，經濟學上認為溫和的物價上漲對經濟發展最有利，就像人在夏天，尤其是夏初，會很活躍一樣，溫度很舒服，行動很友善。“價格”太高就麻煩了，大熱天，40 多度，人除了吹空調可能啥也不想幹，這個時候經濟就容易出問題了，不活躍了。

經濟學上的基本道理，放在企業身上也一樣，畢竟理論就是來源于對企業經濟活動的思考。“價格”太低，企業可能就“打哆嗦”把自己“打”沒了；“價格”太高，錢都燙手了，企業想拿也拿不到了，沒人出來活動了。

過度的競争，拉低價格，最終會砸了行業的飯碗，而甲方也不會真從太低的價格中受益，筆者自己也見過，乙方價格太低，甲方心裡也清楚，一開始雙方還覺得可以通過甲方做基石客戶，打造乙方産品，從其他客戶身上盈利，結果這一單虧得遠超預期，乙方“躺平”了，甲方也沒辦法，也知道乙方虧大了，沒法提更高要求，最終當然是項目沒法達到最初預期效果。這種還算是當初有“餅”在的，也有些沒“餅”都硬吃的，最終也就是因為雙方的“面子”問題，不至于公開地“不歡而散”吧。單就現象講，這對行業是沒有好處的。

多元成因分析

從成因的角度看，這個問題不好解決。單看現象沒有什麼意義，畢竟解決不了的話，談都是浪費時間，隻能自求多福。造成這個局面的原因很多，絕對不是單一因素造成的，畢竟行業裡有些乙方還處在有一定“話語權”的位置上，是以，企服端軟體行業的“困難”并非一概而論的，與細分領域的競争情況有一定關系。筆者隻說幾個自己觀察到的因素：

（一）價格高度透明

這本是市場競争的必然結果和好處，尤其是對甲方而言，但是對于擅長搞采購的大甲方而言，這已經不僅僅是好處了，都能到“殺器”的級别了，對于常年開展 IT 采購業務、采購類型衆多的大甲方來講，全市場的價格都是完全清楚地，乙方的實際能力水準、産品性能幾乎也是“一清二楚”，對于這種大甲方（甚至再小一些的）而言，乙方幾乎沒有議價能力，如果想要維持價格，就得冒着落标的風險“硬抗”，但是能“扛”得動的很少。

比如，甲方是特大型采購，而且需要維持多個乙方中标來避免實施風險，這種情況下，有時候行業内排名靠前的乙方不入圍可能甲方自己也不好解釋，是以，大乙方有點兒“扛”價餘地。但如果切換到單一中标的環境下，高價格中标反倒需要很多解釋工作，而甲方非常清楚曆史價格、目前價格，乙方很少有什麼“扛”價餘地，甲方也不會願意給自己找這種“麻煩”。

這種局面的形成時間已經不短了，即便現在取消最低價中标的管理要求，也很難會讓乙方得以“溢價”，因為“溢價”的來源并不是投标管理，是“品牌”價格、“産品”價格，不少國内乙方在與外資競争的十幾二十年裡，隻能靠壓低價格與國外品牌、産品競争，就算現在競争産品退出市場，也并非一下就能把“溢價”還給國内乙方，因為在甲方記憶裡，乙方就是這個價格，改變别人的印象是很困難，甚至是徒勞無功的事情。

（二）雙方 IT 力量膨脹

如果一件事情隻有某個角色能做，這個角色就有“叫價”的資本。十幾二十年前的 IT 行業，科技人員仍然是“稀缺”資源，就算是網際網路企業，在發展初期，不也傳出過很多半路出家的程式員搭上了網際網路快車緻富的佳話。那個時候，說企業有千人規模的 IT 團隊都是難以想象的，畢竟筆者所在的銀行業，就算是 IT 鈔能力不菲的國有大行，在十幾年前，也是剛有千人規模的 IT 團隊，但這裡邊大概有一半左右還不是做開發的，甲方“盛産”的 IT 人員是需求分析和項目經理。

如今，頭部的城商行，也就是相當于國有大行省分行一級的機構（這是以經營區域論，就人員和規模來講比國有大行的省分行還是要大的），都有上千人的 IT 團隊了，而國有大行均在上萬人了，單論人數，可能比服務他們的乙方企業還多。一些央企在數字化轉型過程中成立了數字科技公司，人員規模也在幾百到近千不等。近年來汽車企業随着新能源車的發展，IT 團隊也迅速擴張。

其實這是軟體行業自己“惹”的禍，我們自己宣傳“軟體定義一切”、“數字企業就是軟體企業”、“一切業務數字化、一切數字業務化”、“數字化轉型是生死存亡”等理念，甲方接受了，但是接受之後的反應并非更依賴乙方，而是更試圖加強自身能力。畢竟，如果覺得一件事關系到未來競争，甚至生死存亡，那一定會抓在自己手裡，哪怕是一部分，不然不會安心。

IT 從業人員持續增多，甲方自身力量持續膨脹，對軟體重視程度不斷提高，這是不争且不可逆的事實，每年可能還有上百萬新增就業大軍試圖進入 IT 領域。就像筆者在企業架構課上常講的，如果甲方聚集了這麼多 IT 力量，不讓他自己做點兒什麼，還成天買産品、買套件，那是想讓他再把 IT 團隊解散了嗎？是認為甲方的 IT 團隊一點兒學習能力都沒有，手頭兒的系統永遠都搞不會嗎？

（三）甲方企業架構能力的被動提升

這一點也是順着上邊的因素延展下來的，由于系統增多、IT 人員增多，加上業務的複雜度也上升，現在無論乙方企業有多大能力，甲方企業都不得不思考自己内部的 IT 治理問題。企業架構能力以前對甲方企業來講若有若無，也是可有可無，系統沒那麼多，人也沒那麼多，都交給外邊還“清閑”些。

但是現在大不一樣了，系統的“家底兒”越攢越厚，還越攢越亂，乙方也沒能力幫甲方打理這麼大個“大 house”，甲方想不自己打理也不行，總是那種規劃交給外邊，對錯都搞不清楚的幹法早就玩不轉了。甲方企業現在是被動在提升企業架構能力，或者叫基于整體架構的 IT 治理能力，連國資委都給央企提這個要求，對筆者而言這是好事情，畢竟，這個“冷炕”想“熱”起來不容易。

現在不是問企業架構好不好用、有沒有價值的時候了，而是企業無論采取什麼辦法，都給自己家裡畫出個“地圖”來，不然 IT 治理就會成為企業痛點，不但解決不好業務問題，還會給企業增添技術問題。更“要命”的是，這種整體架構能力本身就是軟體研發領域中比較進階的“整體設計能力”，雖然不是說有就能有的，但卻是有了就一定要說了“算”的，也就是說，如果甲方的“整體設計能力”上升了，乙方的“話語權”隻能進一步下降。

以目前的情況來看，這種現象不僅已經在一部分行業出現，而且會随着大規模轉型工作的推進，在更多行業中擴散開，這隻是時間問題，對甲方而言，這并非不可企及的“能力”問題，隻要敢堅定地做就一定會提升，肯定比 “造火箭”容易多了。

（四）軟體研發模式的緩慢變化

軟體設計領域一直有“積木化”的夢想，其實隐含在“積木化”夢想之後的是軟體的快速工業化生産。關于軟體行業的生産，筆者一直有個開玩笑的形容方式，“大規模小團隊手工作坊”，自己認為還挺形象的，再大的企業、再大的 IT 團隊，開發起來也是切小塊，由小團隊以手工撸代碼的方式為主來做，一直沒能“工業化”，“靈活”以加班為主，也并非以方法為主，甲乙雙方都如此，截止目前，應該沒有真“靈活”企業出現。

盡管上個世紀還處在缺人年代的老師傅就說過軟體行業不是單純靠“堆人”就能提升效能的行業（《人月神話》），但是目前我們在總體生産力提升上，除了加人之外并沒有更好的方法可用。不過理論研究倒是有在一直發展，并且還趨同了，就像在企業架構領域，主流方法論都将自己的研究指向了“業務能力”定義，面向“業務能力”的軟體設計，分散、獨立地定義“業務能力”，那也就意味着軟體應該繼續走向“零件化”、“積木化”，方向是沒錯的，方法也開始支援（其實流程和能力分離的設計思想也有二三十年了，筆者寫《聚合架構》這本書時略微做過考古），就剩下更充分的實踐了。

筆者作為業務架構領域的從業者，自己也在接觸到越來越多想要重新做面向能力、面向抽象的架構設計，這種訴求也包括來自一些網際網路領域的企業。畢竟，隻有設計是“零件化”、“積木化”的，才有組裝式生産的可能，才有向工業化效率靠近的可能。不少的企業都在嘗試将業務設計“能力”化，曾經紅了半邊天的半套企業架構方法論——“中台”方法論也是這個範疇，完整的企業架構方法論基本上也都指向這個方向。

随着企業“被動”提升企業架構能力（不是隻認識到，而是能執行），企業自己的“業務能力”識别、定義、設計水準也會逐漸增強，這會在軟體要求方面進一步與乙方“理想”的輸出模式産生沖突，目前一些軟體項目要求的服務化設計并不僅僅是為了內建友善，也是在尋找更為靈活的面向能力的架構。這一模式目前變化還是較為緩慢的（畢竟甲方能力的提升總體而言還是在少數企業），但是總體是方向還是明确的，基于能力組裝企業應用是大家都想做的，那組裝一般應是基于“零件”而非“套件”。

因為緩慢，是以乙方可能更“痛苦”，這個階段，新的模式沒完全出來，舊的模式還不如意，定制越來越強（目前 IT 能力不那麼強的甲方也有定制傾向），項目成本越來越難控制，也許還不如來個“痛快”的。

這幾個成因也許算不上什麼根因，但在筆者看來，基本上都屬于不可逆轉的因素。

乙方企業可以考慮做的改變

筆者要說的這些改變也許不能成為上述問題的“解決之道”，但可能會成為“适應之道”，畢竟，可能 5-8 年之後，軟體行業可能還有更大的“變數”會到來，不先“适應”一把，後邊的“變數”也許會更不好接受。

筆者認為乙方企業要做的最大适應應該還是軟體産品形态的變化，變“套件”輸出為以“零件”輸出為主的多樣化輸出，如果有機會做，那就對既有的套件做徹底的“零件化”，完成流程與能力分離的設計。筆者“産品化”的經驗尚淺，從自己的角度看，“套件”中最不容易适配的就是界面、流程、角色、權限這些與“套件”實際包含的“真知識”（規則）關系不大的部分，可能讀者會覺得“流程”不是“真知識”嗎？“流程”是，但準确地講，是“不穩定真知識”、“不通用真知識”，不同企業的“流程”會因組織規模、結構的差異而有很大不同，“流程”非常重要，卻不能輕易搬來搬去，與之相對的是，“規則”适用性會更廣，并且也有機會做更綜合性的抽象，變成“産品化”能力。

有些乙方企業也詢問過做産品抽象的方式，筆者自己結合業務架構的經驗思考，“對象 - 規則 - 流程 - 界面”，這四層抽象順序應該是做“産品化”抽象的可借鑒順序。

“對象”是邏輯級資料實體，也就是業務處理對象，先抽象業務處理對象，這層設計很多企業其實考慮的是庫表抽象，不是實體抽象，這裡需要改變；之後是處理“對象”的“規則”，規則通常是可以“參數化”、“整合”的；之後是“流程”，但一般是結合流程引擎做些變通，實際上很多時候在內建時都要考慮改流程，是以，“流程”很不穩定，抽象了也基本上隻能給連“流程”都“懶”（也可能是沒有業務人員支援）得想的甲方用；最後是“界面”，最不成功的抽象往往就是界面，誰能做出人見人愛的呢？甲方企業自己還有統一門戶呢。

從這個角度講，乙方如果能夠順應目前甲方出現的“緩慢”變化趨勢進行産品調整，将專業能力聚焦在更小的“零件”上，也許更有機會提升“專業”性，畢竟所謂的乙方專業性是要比甲方專業性付出更大努力的，畢竟甲方再懶得總結知識，也是天天要做業務，業務也還是時常有變化的，嚴格說來，乙方的能力如果能聚焦在“規則”上，做好“規則”級“零件”已經很不容易了，畢竟不是業務源頭，業務創新又不會發生在乙方。

如果“零件”能做好，那麼對大甲方的輸出應該以零件為主，這裡筆者特别想說的就是大甲方應該自己做“流程”，對于大甲方而言，遲早架構能力會掌握在自己手裡，自己的開發資源至少要覆寫對“流程”的開發，畢竟開發資源也不少，甲方做“流程”不僅是因為它具有強烈的企業本地化特征，而且從企業架構視角看，“流程”是橫向的應用視角，也就是對“能力”的調用、串接視角，是很強的業務視角，也是業務創新的表現，本身流程的變化、對調用的重新編排就是業務創新的方式，是以這部分該由甲方企業自己做，乙方提供的是更強的“規則”式“零件”，也許采購金額下降了，但是乙方成本也降了，并且在該專業的地方可能也更專業了。不過，很多“規則”甲方也許自己也會做，這個也沒辦法。對于連“流程”的開發資源都不足的甲方，這就是賣“套件”的對象了。

這會不會導緻乙方企業規模縮減，未必，因為“零件”不見得就必須很便宜，畢竟是“專業級産品”（如果乙方打造得夠專業的話），但這也會“暴露”出軟體原本哪裡就不那麼“昂貴”。不過，如果發展的趨勢最終是乙方規模縮減了，那該做的如果都做了，也沒有什麼可以遺憾的，畢竟，軟體行業發展的目标已經灌輸給我們的客戶了，“數字企業都是軟體企業”。

企業服務端軟體生産能力的大幅度提升是否一定伴随着特定軟體企業的大規模發展，這個不好說，也許這正是軟體行業與制造行業不同的地方，大規模軟體生産不特殊依賴于特定的“生産裝置”供應商，因為就行業來看，軟體生産所需的基礎實施在各行業裡本就已經是“分布式”的了，隻差能力的“分布式”了，而這個“分布式”也已經是“進行時”的。

人工智能的未來變數

今年三月首個 AI 工程師 Devin 誕生了，之後就是若幹個開源版、加強版，還沒等 Devin 自己公開源碼，别的版本都已經開源了。記得去年還是不少人覺得 AI 程式設計不太靠譜，結果在一片“懷疑”中，今年 AI 工程師又進步了。這輪大語言模型帶來的發展對個體能力的增強是非常令人關注的，也是筆者相信的發展方向。

别的不講，再給它五年，有幾個人敢賭定 AI 在程式設計方面還是“垃圾”一個？五年的話，是不是再說不過去也能讓個體程式設計效率提升個 50% 吧（筆者還沒敢按照數倍提升去看），那麼以大甲方目前的 IT 人員數量看，甲方自己搞定全部業務系統的主要實施、重構到底是能還是不能呢？至少沒有生産力方面的問題，而設計能力、知識萃取能力、工程管理能力，隻要企業真重視，肯下功夫，也是可以大幅度提升的，那時的乙方又要怎麼辦呢？

AI 的未來我們就不去“焦慮”那麼多了，僅這一個趨勢就足夠乙方企業思考了。回到目前，現在的困難如果需要幫助，尤其是政府幫助，那也許可以考慮一些補貼、商業政策的調整之類的。但是，在産品、軟體模式、開發理論、核心技術等方面的核心競争力，還是得靠企業自己去解決，外人隻能幫幫環境，“适應”還得靠自己，“保護”無法提升能力。《侏羅紀公園》中有個名句：“生命會自己尋找出路”，筆者還會狗尾續貂一句，“隻要生命力夠強”。

作者介紹

付曉岩，《企業級業務架構設計：方法論與實踐》、《銀行數字化轉型》和《聚合架構：面向數字生态的構件化企業架構》三書作者。北京天潤聚糧咨詢服務有限公司執行董事總經理，數孿模型科技公司進階副總裁；工業和資訊化重點領域數字化轉型與人工智能産業人才基地專家委員會副主任；中國計算機學會軟體工程專委會委員、數字金融分會首批執行委員；信通院企業架構推進中心、組裝式推進中心技術專家；中華全國數字化人才培育聯盟專家委員會特聘專家；工信部中小企業發展促進中心産教融合産業實踐教授；國家工程實驗室金融大資料應用與安全研究中心研究員；CIC 金融科技與數字經濟發展專家委員會成員；國家網際網路資料中心産業技術創新戰略聯盟專家委員會副主任專家委員。

原文連結：甲方IT日益壯大，企業服務軟體行業面臨的困境與出路_數字化轉型_付曉岩_InfoQ精選文章