企業軟件產業是由供應商、客戶和第三方共同構成的。而為企業提供數字化能力的，包括提供標準能力的產品化軟件、提供定制開發服務和人力外包的軟件服務商，以及客戶的IT自研團隊。
這幾方力量是如何組織在一起，形成數字化能力的呢？
我將自己的實踐經驗和觀察做了個總結，做出了這張表。今天就來詳細介紹下：
模式一：離散式應用系統
離散式的應用系統，是按照使用者的需求量身定做的軟件。其中有規模較大的一整套定制化系統，也有規模比較小的煙囪式獨立模塊。
為滿足個性化需求做出來的系統，隨著業務規模擴大和需求不斷調整，會逐漸暴露出各種問題。增加的補丁和新功能也會對系統的安全性、穩定性持續產生沖擊，最終系統爛到難以為繼了，只好推倒重來。
尤其進入到大數據時代后，離散式系統產生的數據缺乏標準化設計，想打通數據孤島就要去做數據治理，系統改造周期長、成本高。
后來者可以站在上帝視角批判以離散模式系統存在的系統的各種問題；但這種模式也有其優勢，有適合的場景。
對于初創型企業，或者成熟企業里的創新業務來說，往往需要以試錯的方式，利用有限的時間窗口進行快速探索。
在這個階段，需求是在不斷迭代中持續完善的，甚至朝令夕改反復調整。需求不固化，應用系統缺乏穩定的運行環境，可靠性穩定性等指標不會好看；但對新需求的響應速度，變更內容的上線速度，是這個階段評判系統優劣最重要的因素。
在這個階段，負責應用軟件系統的人說這樣做不行，那樣做不符合標準，做個變更要一年多，你看業務部門和公司領導會不會打你。
模式二：集中式應用系統
顧名思義，集中式指的是多個使用者共用同一套系統和平臺，或者說不同的使用者使用相同的功能。所以集中式還有個變形版本，就是使用標準無定制的產品化軟件，一樣也是為不同使用者提供完全一樣的功能。
集中式應用系統具備規模效益。規模越大，成本越低，且邊際成本遞減，是供給側最希望看到的。
集中式應用系統還有一個好處，就是軟件能統一升級迭代，即便某個使用者自己沒有提需求，只要完成了系統更新升級，就可以具備最先進的能力。
但是，這種模式的不足之處也很明顯。
無論是集中部署的系統，還是產品化的軟件，更新迭代多由供給側發起。新技術的引入、架構設計的優化、增加調整哪些功能，都要統籌考慮。尤其對功能進行調整，不會滿足所有客戶的需求，而是對各處反饋的信息進行梳理和評估，最終形成的研發需求。
如果是小眾客戶的需求，或者經過評估之后認為不足以納入新版本了，就意味著需求被拒絕。而這，對于產品化供應商來說，并不是什么了不得的大事。
即便這個需求被采納，那么按照產品研發的流程計劃，要完成需求分析、概要設計、詳細設計、編碼、測試等一系列規范性動作，才能交付出去。而交付完的軟件，其安裝和適配改造也需要時間。這一串工作做下來，是不是得幾個月？
要知道，這還是理想狀態。在實際操作的時候，還可能被各種因素干擾，或者必須增加一些環節，導致周期更長。
有沒有可能因為某個客戶著急，先把重要的功能做出來讓客戶用？對不起，產品化軟件是不允許這么瞎搞的！
至于其他問題，比如在一個軟件包里存在很多客戶不需要的功能，但在客戶購買的時候依然要為其付費；并要提供與之相配的冗余硬件設施，抬高了硬件成本和運營成本等。多花點兒錢就能搞定的，相對來說只是小問題。
所以，集中式適合部署在成熟的、需求相對固化的、規?；钠髽I，尤其對于那些試圖借助軟件系統提升管控能力的企業來說，借助產品化軟件和集中化部署來消除各種差異化和特殊現象。
如何讓客戶需求收斂，避免提出個性化開發任務，這是令供應商頭疼不已的難題。而在集中式體系里，個性化需求有可能靠客戶利用行政手段強行壓制。
當企業處于穩定運轉狀態時，希望通過實施精細化管理來提升效益，因此有意愿壓縮各層級靈活操作的空間。此時采取集中式來優化管理，借產品化之力統一思想和行動，企業在實現權力集中的同時，也推進了內部降本增效工作。
模式三：組合式應用系統
組合式，就是由不同的軟件、系統和模塊組合在一起，向企業客戶提供其需要的能力。
組合方式也可以細分成兩類：一類是產品化軟件和定制化開發的組合；另一類將各種產品化軟件和模塊組合在一起形成能力。
組合式系統往往是這樣建設的：
1. 按照規劃的方式建設系統，系統建成后提供既定的數字化能力；
2. 如果需求變更，先嘗試通過產品配置的方式完成；
3. 如果配置不能做，再看能否通過與其他產品的組合來滿足；
4. 還搞不定，就用定制化服務開發來兜底。
相對于集中式，組合式更能滿足客戶的個性化需求；而相對于離散式，組合式里有產品化的內容。所以說組合式兼顧了產品的標準化和定制的個性化，兼顧了服務的靈活性和產品的穩定性，大家各司其職，發揮各自的優勢，反正最后有定制化服務守底線，總能搞定的。
但在實踐的過程中，我也看到了組合式的一些問題。
首先，如果是達成既定的目標，產品+服務的模式成本未必最優。
每個產品化軟件提供的功能都是有限的，如果大量的功能需要服務廠商來做，那還不如全做定制，這樣還能省點兒接口適配和集成的活兒。
所以同樣是滿足客戶個性化需求，組合模式會比單純的定制化服務成本更高、資源要求更高、開發周期更長。
其次，組合模式需要多廠商協同，無論是產品+服務，還是產品直接組合，都一樣。
無論是在系統建設過程中，還是在運行時出現故障，都可能涉及不同廠商的責任界定、能力確認、利益分配的問題。
對好做的能拿錢的功能就搶，對不好做純付出的事情就躲，技術問題被扯來扯去，簡單問題復雜化了。
再有，如果產品的可配置項比較多，或者軟件能力是由多個產品組合而成的，可能導致配置的工作過于復雜，甚至超出了配置人員的能力。
曾經在一個項目里，看到負責進行產品配置的是個非常高職級的研發人員，因為這些工作除了他，別人搞不定。
這都不是最可怕的。每套組合式系統里，各個廠商都有自己的產品演進策略，有產品端下發的升級時間進度表，當出現矛盾和沖突的時候，協調難度往往非常大。
一套在線運行的系統，突然說某個主要產品必須升級，怎么辦呢？
先要分析升級可能涉及的內容，再評估對現有各組成部分的影響，制定調整方案后去實施，搞不好幾乎就是把系統重新做一遍。
剛搞完沒過倆月，接到通知，另一個主要產品又要升級。
成年人的崩潰，往往就在一瞬間。
企業軟件要適配企業的發展，汝之蜜糖，彼之砒霜
展望未來，各行各業的數字化程度必然會越來越高，企業是攻還是守，是求變還是求治，都需要企業軟件的支撐和配合。
企業在不同發展階段，對數字化能力的要求是不一樣的，部署模式也需要隨之調整。
我認為：企業軟件的能力組成模式沒有唯一的標準答案。數字化能力要適合企業的發展狀態，每類存在模式都有其合理性。
總體來說，組合式是企業兼顧穩定與創新的最佳選擇：成熟的產品化軟件穩定輸出，提供有邊界的能力；創新則通過產品組合或者定制開發來實現。
但如果客戶的需求完全能夠被產品化軟件支撐，或者使用者比較被動、只能使用有限的功能，那么最好用的就是集中式。
而如果客戶的需求無法固化，經常變動，尤其在規模不大的時候，離散式的模式挺好的。
核心在于：企業軟件不能被動地限制企業發展，而是要主動地幫助和支持企業成長。
企業運營階段追求降低成本、穩定可靠；而遇到創新和突破的機會，就要采取積極的應對態度。
當需要對數字化能力進行大幅度變更時，可以先用離散式的方式，用獨立的系統去試錯；待需求穩定后，再研究納入其實現的最佳方式。
循環往復，在變化中找機會。所以我認為，企業應該在這個過程中，逐漸培養自己的IT能力，將產品組合配置、定制化開發、系統集成這些工作承擔起來。
這是打造企業客戶自身數字化能力的最終選擇。
來源：虎嗅APP
文章轉載于其他網絡，如有侵權請聯系我們及時刪除！
