這篇文章的結論是：對于那些準備走上自研的傳統企業的科技公司，建議最好將產品團隊和自研團隊分開，二者的人才特質、運營方式、財務模型都不相同。

正好自己既做過對內的數據產品，也做過對外的產品變現，有三個類似觀點：

1、對外產品的抽象程度高很多，業務價值實現的最后一公里很多其實是客戶自己完成的，因為最后一公里實在是太靈活了，而對內的業務價值實現往往要求全部在產品中承載，雞毛蒜皮的功能也得做，導致對內的產品越做越復雜，冗余功能越來越多。

2、對內產品的主導者是項目經理，對外產品的主導者首先是產品經理，如果兼職項目經理，有時候產品會做的不倫不類。

3、對外產品中的90%，最后都做成了定制化解決方案，能做成產品的屈指可數，在現實面前有時得低頭，市場沒有耐心，你的老板也沒有耐心。

正文開始

最近這些年，有越來越多的企業，大的、小的都有，自行研發自用的企業級信息系統。出于收回成本、品牌延展、搶占企業軟件市場等等目的，他們將自研自用的系統拿到市場上去賣。然而現實是，即使客戶因為仰慕名氣、銷售說服等，購買了這些企業號稱“產品”的自研軟件，交付質量卻往往很差，為了讓客戶滿意，金額越大的項目，虧損越大——在中國市場上，企業自研系統出街當軟件產品賣，鮮有成功的例子。

另一方面，用做套裝軟件實施的思路來搞定制化系統開發也常出亂子。有位資深架構師前幾天跟我抱怨，說他接手了某企業定制化系統開發的項目，在他前面做資源規劃的人，給他設了一個“七個業務顧問按模塊做系統設計，七個開發人員負責開發”的局，同時，業務顧問比負責開發的碼農貴很多，項目預算的大頭被只會畫PPT的顧問們拿走了，到了開發階段沒資源了.......架構師說這一看就是搞套裝軟件實施咨詢的人弄的，不懂定制化系統開發的套路；類似的事情，我也碰到過，感同身受。

這些困境背后的原因是，企業自研系統和商品軟件是有本質區別的，因而面向客戶需求的項目交付方式也迥然不同，我總結如下：

首先，自研系統是為了解決企業的具體應用需求，其功能范圍、系統架構、解決方案都是˙通過項目管理來確定，具有“項目型開發”的特點，只要能夠保質、按時交付，滿足用戶需求，就是成功的系統。

商品軟件則是需要在一定的功能范圍內，建立抽象超越單個企業，面向行業或者跨行業應用的通用模型。定義商業化企業軟件的功能邊界以及內部構成，就是“企業架構”建模，例如，傳統的ERP軟件以及ERP軟件內部，按照職能來劃分模塊（財務會計、管理控制、物料管理、銷售和分銷等等，見下圖），今天，是不是可以不從業務職能視角，而是按照端到端的流程視角來劃分模塊（例如訂單到交付OTD、采購到支付PTP等），就體現了不同的企業架構建模思想。

正是因為二者的定位不同，使得其在滿足用戶需求、交付使用的過程的軟件工程方法不同。自研系統多采用“硬編碼”（hard coding，下面也稱為“寫死的代碼”），而商品軟件則是開發出一個“可配置”的標準化產品，通過配置而非寫代碼，來滿足用戶的個性化業務需求。

“寫死的代碼”是指業務相關的主數據、參數和邏輯是用代碼的方式寫在軟件程序里的，因為業務變化，對這些對象進行修改，必須修改軟件的源代碼。在軟件工程實踐中，雖然有經驗的架構師和程序員都盡可能避免采用“寫死的代碼”，保持系統的靈活性和可擴展性，然而，由于項目型開發本身“急功近利”的特點，分析用戶需求并實現需求即可交付，在系統設計時，開發人員很難考慮到、也不需要考慮到擴展的各種可能性，所以“寫死的代碼”實際上是自研系統的普遍現象。

讓我們來打個比方，用系統來實現蘭州拉面的業務，當我們窮盡地、逐一羅列一家蘭州拉面館所有可向顧客銷售的產品，每種產品選擇都對應不同的定價、生產工藝和成本等，例如，紅燒牛肉面是一個產品，其澆頭加量就成了另一個產品，標準紅燒牛肉澆頭再加打鹵澆頭，又成了一種產品。在做銷售活動時，選擇這個產品集的一個或幾個產品進行銷售，這就是對牛肉面的業務進行了“寫死的代碼”：

死代碼方式存在著靈活性問題，例如客戶要一碗清湯牛肉加打鹵面，或者新創一種澆頭，系統就不能處理了。不過，只要能夠滿足企業用戶需求，系統就能用起來，即便系統交付后業務出現變化，由于是自己擁有源代碼的自研系統，自己負責運維，找得到人去改代碼。這也是為何有些企業在購買商品軟件時，要求要獲得源代碼的原因之一，“寫死的代碼”是他們根深蒂固的軟件工程思想。

自研系統和商品軟件對購買企業的價值主張不同。幾十年前業界就已經有共識：自研系統是固化現有業務，是現有業務的簡單線上化、數字化，而商品軟件是代表先進企業的“最佳業務實踐”，對企業來說是外部性知識輸入。企業實施信息系統目的是提升組織能力，必須持續要有外部輸入，好的第三方產品和服務本質上就是不斷為企業輸入有意義的外部知識。

把各家的面館的面都抽象出來，甚至能夠反映整個面館行業的行業規則——“一碗面”是由面條、澆頭、湯以及其他選配項，以及背后的選配規則構成的。對于主數據變化，通過調整參數來實現，既可以覆蓋企業目前業務，還可以不經過改源代碼就擴展到行業標準的新產品，例如面條目前有刀削和拉面兩種，你可以將拉面再分為拉細條和拉粗條：

下圖是ERP的后臺配置畫面， ERP 有所謂“后臺配置”和“前臺配置”之分：基礎性的主數據和業務規則由系統管理員（或實施顧問）在后臺配置，業務用戶看不到；而業務管理人員基于后臺配置的基礎，配置業務流程的規則，屬于“前臺配置”。打個比方，某個集團的某公司有哪些物料移動的記賬方式，在后臺配置中由系統管理員預先設定好，而在業務流程中，某個具體的業務活動適用于哪些記賬方式，則由業務管理人員在前臺設定，這樣業務操作人員在操作中，就可以使用這些預先設置好的流程規則；這也體現了大型企業管理軟件的業務控制思想。

顯然，能夠實現“軟件配置”的商業化軟件產品開發方式，要對業務有高度的抽象能力，而且對于行業或職能的外部性（而非企業內部視角）知識，有極高的廣度和深度的要求。“產品化”和“項目化”軟件開發的復雜度、艱巨度，以及對于軟件產品負責人的要求，是不同的量級。

因而“自研系統”和“商品軟件”的關鍵角色和技能也是不同的：前者需要有“架構師”來轉化用戶需求和技術實現的技術能力，要有項目型的軟件工程技能，包括今天流行的敏捷和DevOps方法。

而后者的靈魂人物分為兩階段，產品開發階段是“產品經理”，對于業務有極廣的視野和極深的洞察，有高度抽象能力、想象力，能抽象出以不變應萬變的產品特性，產品交付階段是“實施顧問”，對復雜軟件產品有深入全面了解，同時面對用戶有極強的溝通、說服能力，說服用戶使用標準化功能。

中國的企業軟件行業正方興未艾，企業自研系統變為商品化軟件絕非易事，對于那些準備走上這條路的傳統企業的科技公司，我建議最好將產品團隊和自研團隊分開，二者的人才特質、運營方式、財務模型都不相同。