企业自研系统能拿到市场上去当软件产品卖吗？

这篇文章的结论是：对于那些准备走上自研的传统企业的科技公司，建议最好将产品团队和自研团队分开，二者的人才特质、运营方式、财务模型都不相同。

正好自己既做过对内的数据产品，也做过对外的产品变现，有三个类似观点：

1、对外产品的抽象程度高很多，业务价值实现的最后一公里很多其实是客户自己完成的，因为最后一公里实在是太灵活了，而对内的业务价值实现往往要求全部在产品中承载，鸡毛蒜皮的功能也得做，导致对内的产品越做越复杂，冗余功能越来越多。

2、对内产品的主导者是项目经理，对外产品的主导者首先是产品经理，如果兼职项目经理，有时候产品会做的不伦不类。

3、对外产品中的90%，最后都做成了定制化解决方案，能做成产品的屈指可数，在现实面前有时得低头，市场没有耐心，你的老板也没有耐心。

正文开始

最近这些年，有越来越多的企业，大的、小的都有，自行研发自用的企业级信息系统。出于收回成本、品牌延展、抢占企业软件市场等等目的，他们将自研自用的系统拿到市场上去卖。然而现实是，即使客户因为仰慕名气、销售说服等，购买了这些企业号称“产品”的自研软件，交付质量却往往很差，为了让客户满意，金额越大的项目，亏损越大——在中国市场上，企业自研系统出街当软件产品卖，鲜有成功的例子。

另一方面，用做套装软件实施的思路来搞定制化系统开发也常出乱子。有位资深架构师前几天跟我抱怨，说他接手了某企业定制化系统开发的项目，在他前面做资源规划的人，给他设了一个“七个业务顾问按模块做系统设计，七个开发人员负责开发”的局，同时，业务顾问比负责开发的码农贵很多，项目预算的大头被只会画PPT的顾问们拿走了，到了开发阶段没资源了.......架构师说这一看就是搞套装软件实施咨询的人弄的，不懂定制化系统开发的套路；类似的事情，我也碰到过，感同身受。

这些困境背后的原因是，企业自研系统和商品软件是有本质区别的，因而面向客户需求的项目交付方式也迥然不同，我总结如下：

首先，自研系统是为了解决企业的具体应用需求，其功能范围、系统架构、解决方案都是˙通过项目管理来确定，具有“项目型开发”的特点，只要能够保质、按时交付，满足用户需求，就是成功的系统。

商品软件则是需要在一定的功能范围内，建立抽象超越单个企业，面向行业或者跨行业应用的通用模型。定义商业化企业软件的功能边界以及内部构成，就是“企业架构”建模，例如，传统的ERP软件以及ERP软件内部，按照职能来划分模块（财务会计、管理控制、物料管理、销售和分销等等，见下图），今天，是不是可以不从业务职能视角，而是按照端到端的流程视角来划分模块（例如订单到交付OTD、采购到支付PTP等），就体现了不同的企业架构建模思想。

正是因为二者的定位不同，使得其在满足用户需求、交付使用的过程的软件工程方法不同。自研系统多采用“硬编码”（hard coding，下面也称为“写死的代码”），而商品软件则是开发出一个“可配置”的标准化产品，通过配置而非写代码，来满足用户的个性化业务需求。

“写死的代码”是指业务相关的主数据、参数和逻辑是用代码的方式写在软件程序里的，因为业务变化，对这些对象进行修改，必须修改软件的源代码。在软件工程实践中，虽然有经验的架构师和程序员都尽可能避免采用“写死的代码”，保持系统的灵活性和可扩展性，然而，由于项目型开发本身“急功近利”的特点，分析用户需求并实现需求即可交付，在系统设计时，开发人员很难考虑到、也不需要考虑到扩展的各种可能性，所以“写死的代码”实际上是自研系统的普遍现象。

让我们来打个比方，用系统来实现兰州拉面的业务，当我们穷尽地、逐一罗列一家兰州拉面馆所有可向顾客销售的产品，每种产品选择都对应不同的定价、生产工艺和成本等，例如，红烧牛肉面是一个产品，其浇头加量就成了另一个产品，标准红烧牛肉浇头再加打卤浇头，又成了一种产品。在做销售活动时，选择这个产品集的一个或几个产品进行销售，这就是对牛肉面的业务进行了“写死的代码”：

死代码方式存在着灵活性问题，例如客户要一碗清汤牛肉加打卤面，或者新创一种浇头，系统就不能处理了。不过，只要能够满足企业用户需求，系统就能用起来，即便系统交付后业务出现变化，由于是自己拥有源代码的自研系统，自己负责运维，找得到人去改代码。这也是为何有些企业在购买商品软件时，要求要获得源代码的原因之一，“写死的代码”是他们根深蒂固的软件工程思想。

自研系统和商品软件对购买企业的价值主张不同。几十年前业界就已经有共识：自研系统是固化现有业务，是现有业务的简单线上化、数字化，而商品软件是代表先进企业的“最佳业务实践”，对企业来说是外部性知识输入。企业实施信息系统目的是提升组织能力，必须持续要有外部输入，好的第三方产品和服务本质上就是不断为企业输入有意义的外部知识。

把各家的面馆的面都抽象出来，甚至能够反映整个面馆行业的行业规则——“一碗面”是由面条、浇头、汤以及其他选配项，以及背后的选配规则构成的。对于主数据变化，通过调整参数来实现，既可以覆盖企业目前业务，还可以不经过改源代码就扩展到行业标准的新产品，例如面条目前有刀削和拉面两种，你可以将拉面再分为拉细条和拉粗条：

下图是ERP的后台配置画面， ERP 有所谓“后台配置”和“前台配置”之分：基础性的主数据和业务规则由系统管理员（或实施顾问）在后台配置，业务用户看不到；而业务管理人员基于后台配置的基础，配置业务流程的规则，属于“前台配置”。打个比方，某个集团的某公司有哪些物料移动的记账方式，在后台配置中由系统管理员预先设定好，而在业务流程中，某个具体的业务活动适用于哪些记账方式，则由业务管理人员在前台设定，这样业务操作人员在操作中，就可以使用这些预先设置好的流程规则；这也体现了大型企业管理软件的业务控制思想。

显然，能够实现“软件配置”的商业化软件产品开发方式，要对业务有高度的抽象能力，而且对于行业或职能的外部性（而非企业内部视角）知识，有极高的广度和深度的要求。“产品化”和“项目化”软件开发的复杂度、艰巨度，以及对于软件产品负责人的要求，是不同的量级。

因而“自研系统”和“商品软件”的关键角色和技能也是不同的：前者需要有“架构师”来转化用户需求和技术实现的技术能力，要有项目型的软件工程技能，包括今天流行的敏捷和DevOps方法。

而后者的灵魂人物分为两阶段，产品开发阶段是“产品经理”，对于业务有极广的视野和极深的洞察，有高度抽象能力、想象力，能抽象出以不变应万变的产品特性，产品交付阶段是“实施顾问”，对复杂软件产品有深入全面了解，同时面对用户有极强的沟通、说服能力，说服用户使用标准化功能。

中国的企业软件行业正方兴未艾，企业自研系统变为商品化软件绝非易事，对于那些准备走上这条路的传统企业的科技公司，我建议最好将产品团队和自研团队分开，二者的人才特质、运营方式、财务模型都不相同。