我用幾個圈來表示三類產品滿足客戶需求的大概關系（也不是絕對的），最中間的是純定制開發，假如大圈減小圈的面積差是需要定制開發的部分，那么純定制開發在業務上的復用度是很低的，所以成本是相當高的。

在某一個領域內成熟的OP產品（例如SAP）則比作第二個圈，也有一定的時間和產品功能沉淀。但是因為歷史的原因，產品的業務模型是基于局域網時代內部協同為視角的世界觀，基于可獲取的數據和相關假設都是“以人驅動流程”的流程觀。OP產品到企業后，需要通過一定的定制才能滿足客戶的個性化需求。特別地，后續客戶的個性化需求和為了響應內外部環境變化產生的需求，定制成本是非常高的，每一個很小的需求，成本都是數以萬計的。

SaaS因為誕生的時間較晚，基本上趕上了國內移動互聯網、云計算和人工智能等相關技術的成熟期。同時，SaaS系統本身在設計的時候，就需要考慮以下幾點：

• 通過抽象提煉來兼容不同企業的需求；

• 基于生態鏈數據打通和新的業務解決方案而設計的業務模型和數據模型架構；

• 持續可擴展性和兼容的設計。

正因為以上特點，SaaS產品較之于傳統OP產品最大的優勢是如果企業的業務和管理變化比較頻繁的話，可以較好地共享平臺持續迭代帶來的功能。按傳統OP模式，企業必須投入研發成本（自己或供應商）以適應相應的變化和需求。

也有人可能會說，“感覺OP模式需求響應會更快”。其實我覺得在絕大多數情況下，這是一種錯覺。因為，當我們享受SaaS平臺升級便利帶來的每年上千個需求迭代時，很多用戶覺得不是他提的所以沒有參與感。當客戶提出自己個性化需求時，覺得SaaS產品響應的沒那么快，反而覺得OP模式響應個性化需求更快，這其實是一種“幸存者偏差”。因為讓客戶有感知的是個別沒響應的，如果將每年迭代的很多功能和底層能力統計在內的話，其實平均的需求等待時間不見得長，甚至是很短的，因此需要站在全局的視角看待這個問題。

另外，如果客戶愿意付出相應的開發成本，我相信SaaS廠商也能提供非常好的響應時效。只是很多客戶只希望支付SaaS服務費，又想讓廠商免費開發個性化的需求，這對SaaS廠商來說肯定是無法實現的。因為SaaS服務費一般也不高，隨便做個需求成本都要好幾萬以上，有些需求的開發成本可能幾十萬，這個時候客戶覺得年訂閱費才幾萬或者10來萬，做幾個需求要那么多錢有點接受不了。但其實OP模式的實際維護成本綜合下來要遠超SaaS模式，哪怕OP模式的產品看上去比SaaS產品賣的更便宜。

很多有經驗的企業都可以發現，OP產品到一定時間就會出現改不動的現象。業務部門向IT部門提需求時，就會遇到“這也做不了，那也做不了”。OP模式的二開生命周期一般也都在3-5年左右。這有很多原因：

• 企業內部因為IT需求多，大家都在競爭IT資源；

• IT人才的流動性整體較高，人員流動導致認知流失；

• 系統建設的過程中，往往對于可擴展性和可維護性的考量欠缺；

• OP系統經過二開后，就無法很好地兼容廠家的升級包。

我認為綜合起來，SaaS產品的平臺屬性，在響應外部生態環境變化的能力上，是OP模式無法比擬的；對于響應內部變化的能力，OP模式在溝通協同上有一定優勢，但是對于整體的需求響應交付的平均時效而言，SaaS模式也是有很大優勢的。雖然對于一些細微的、非復雜功能的響應，OP模式確實可以做到更快的響應。

很多企業現在系統中的數據并不能很好地支撐很多新的管理思想的落地，那是因為傳統基于流程和表單的設計已經是過去式。在這個多變的時代，企業的戰略、業務、組織架構和管理都在不斷變化，要落地有價值的管理思想，企業對于未來數據的要求一定是要能支撐管理報告的生成和管理運營的持續落地。原本基于流程和表單的設計，已經無法滿足面向管理的需求，新一代的設計應該是拉通管理目標，通過流程與表單收集基于專業領域模型的高質量數據。沒有拉通的結果就會出現數據有斷點、流程跟不上管理、管理拿不到數據等問題。

所以，新一代領域專業管理系統需要全面拉通三個層面：

1. 管理層：管理目標為導向（不可見）

2. 數據層：專業的領域數據模型為基礎（不可見）

3. 業務層：靈活的流程和表單為載體（可見）

這對于系統的架構來說，要系統性地考慮到四方面的架構：應用架構、業務架構、數據架構和技術架構。

沒有一樣東西是絕對好的，也沒有一樣東西是絕對不好的，我們在決策時，還是要選擇最合適的。對于很多有歷史包袱的企業來說，是應該選擇在原來系統上做小優化還是做變革呢？也沒有標準答案，從結果上看，也許有時候更取決于環境和領導者性格。但是，我希望有更多的人能夠邁出勇敢的一步，只有這樣，中國的SaaS領域才有未來，只有這樣，中國的軟件行業才能進化。