B 端的产品化

B 端产品化基本上出于以下三个原因：

1. 作为高科技企业，软件公司希望提升毛利，赚取软件产品被复制使用的钱。软件公司经过多年的打磨和沉淀，都会尝试构建标准化产品，收取软件售卖的费用。

2. 产品化能力的强弱决定了实施成本。产品化做得好，实施工作就简单，产品厂商也能节省很大一笔成本。

3. SaaS 模式的发展，进一步推动了软件产品标准化建设。因为 SaaS 作为一套标准产品部署在云端，更加需要灵活的功能设计来适配不同客户的需求。

B 端产品化的层次也可以分为商业、功能、生态这三方面。

商业层面，任何产品都是公司战略的载体，必须追本溯源，从公司战略、目标客群、产品价值、覆盖场景这些角度，去思考产品的核心本质和灵魂。

具体来说，需要做这么几件事。

第一件事：找到并聚焦细分客群。

这件事是软件产品化成功运作的关键要素之一。同类特征的客户群体，具有高度相似的业务特征、管理模式、场景和痛点，这就为软件的标准化设计创造了天然的良好条件。不论是商业运作还是功能设计，都会更清晰、更可落地。

如果客户群体比较发散，那么需求一定无法收敛。

第二件事：明确价值主张。

做产品最难的不是选择做什么，而是选择不做什么。

在商业上取得成功的产品，一定不是满足了所有客户的所有需求，而是满足了目标客群的核心需求。所以，作为产品经理，在思考产品功能是不是要覆盖更多场景，或提供更多拓展功能的时候，要反问自己：这样做能不能给产品解决核心问题，带来更大的价值和帮助？

如果不能，相当于要进入一片全新的领域，那么客户是否已经有了其他更好的解决方案？这种情况下，我的竞争力在哪里？

这些问题都是产品经理要慎重思考的。

第三件事：规划发展路径。

在产品发展演化路径里，一切决策都应该基于商业诉求。所以，看似技术化的架构和路线选择，本质上依然都是商业问题。要根据发展阶段选择相应的产品形态，结合商业策略和计划，做好充分规划。

功能层面，功能属于产品的基本特性。业务型 B 端产品面临的是错综复杂的场景，如何提炼需求、抽象业务，设计出具有高度拓展性和灵活性的软件解决方案，通常面临比较大的挑战，但也有可借鉴的路径。

如果面临的业务方只有一个，就相当于一直在做定制版系统。但如果设计的系统要给不同客户使用，不同客户会有不同需求，这时就要进行取舍：把不同客户的需求抽象、提炼成配置，使其成为标准化产品的一部分。有些时候，甚至可以拒绝某些不合理的个性化需求。

如何准确把握需求，找到背后的本质诉求，并进行抽象设计，需要产品经理对客户群体有很深的理解和洞察。有时候客户的需求并不一定合理，或者产品经理也不确定是不是共性需求，就可能忽略这些需求。

如果某个功能不实现，大客户就要换其他家的产品。这种时候，就要学会引导客户控制预期，或者直接给客户做单独部署的定制版。

为了提前应对这种情况，做产品的时候一定要保证标准版简洁干净。如果什么功能都往上面累加，最终会让系统变得不堪重负，不仅难用，代码维护也会越来越困难，更不要提定制开发或者二次开发了。

对于业务型产品，个性化最难处理的部分，还是在于业务逻辑和背后的业务数据对象。

如果产品形态比较简单，或者客户群体足够细分，那么通过提炼、抽象、配置参数，可以实现一套标准化产品的业务逻辑底层封装。但如果客户群体多元化，或者业务场景非常复杂，通过参数配置的方式来实现就有些力不从心。

业务型产品背后，通常隐藏着复杂的业务单据、业务约束和业务规则。除了已有数据的字段可以自定义，还要支持新增数据对象。所以，标准化产品要通过一些底层能力的构建，实现对数据底层对象的编辑和自定义。

对于业态不是特别复杂的产品，可以考虑表单驱动的设计，比较容易上手，配置简单。但缺点是灵活性有限，不能实现更加复杂的诉求。更加复杂的商业软件通常会采用模型驱动的设计。

在业务型产品设计里，有大量业务逻辑，可以将其提炼总结成一个范式：在什么情况下，对什么数据做什么处理。

首先需要定义业务逻辑的触发条件，可能是某个数据被修改，也可能是到了某个时间点，或者用户做了某个动作。定义触发条件之后，接下来要描述业务逻辑。业务逻辑可能包括数据的增删改查，或者发送指令、执行代码之类的。

设计强大的对象编辑器、流程编辑器，是复杂业务型产品必须具备的能力，也是所谓 PaaS 的核心能力。这种编辑器确实可以大幅减少研发的编码工作，但也需要投入巨大的研发资源，沉淀打磨很多年，才能真正发挥出价值。如果产品本身很轻，客户群体也非常聚焦，就没有必要做这么重的 PaaS 底层，通过参数配置就可以支持业务。

刚才我们说到流程编辑。严格来讲，审批流是工作流中的一种，而且相对简单一些，因为审批流是针对一个数据表单的多人协同处理，不涉及复杂场景下的多数据流转问题。不同公司的产品有不同的设计理念，有些会把审批流单独提炼出来作为一个功能，跟工作流互相独立，方便管理员理解和使用。

完整的产品化还包括对前端应用层的自定义配置化能力。不同客户对列表页、详情页、编辑页的查询条件、字段呈现和排版逻辑的需求都不同。

如果通过硬编码来实现这些页面，随着客户数量变多，就会陷入无穷无尽的二次开发工作。所以，必须实现可配置的前端应用层能力，支持前端页面的各种灵活呈现。

所以到这里，我们可以总结出业务型 SaaS 产品的功能架构。

模型层，也就是数据底层。灵活的商业化产品可以做到用户自定义数据模型。这个层面的用户是业务管理员和乙方实施顾问，构建目的是初始化系统、定义核心逻辑，并根据需要随时调整。基本要素是预制数据对象和对象编辑器。

控制层，也就是业务逻辑层。灵活的商业产品背后的业务流程，都可以用流程引擎自定义设计。这一层的用户是业务管理员和乙方实施顾问，构建目的是初始化系统、定义核心逻辑，并根据需要随时调整。基本要素是预制业务逻辑和流程引擎。

视图层包括各种基本的前端组件，用户就是甲方用户，目的是使用这个产品的功能。基本要素有首页、工作台、待办任务或日程、搜索、消息、公告，以及一些自定义页面、自定义报表、自定义仪表盘、自定义视图列表、自定义详情页。

除了这三层，B 端产品还要再加入一个配置管理层。用户就是甲方管理员，目的是初始化系统、管理基本参数。需要的要素有 UI 管理、用户角色、权限管理、组织结构、参数配置、数据导入、字典管理、国际化之类的。

除此以外，还要有开放 API 层。开放 API 的用户就是内外部开发者，构建目的是系统集成、开放生态，基本要素是各类同步、异步或订阅的接口。

如果是 SaaS 产品，还需要通过租户管理模块实现对多租户客户的交易、产品权限的管理。这个模块的用户就是乙方运营，目的是管理组合，包括订单权限之类的。基本要素要有租户管理、交易管理、权限管理、CMS、统计分析、财务管理。

相比于业务型 SaaS 产品，工具型 SaaS 产品的功能架构会更为简单。因为对于工具型产品来说，核心并不是数据表单与业务流程，而是场景化的解决方案。因此也不需要模型层、业务逻辑层的自定义能力，甚至也不需要页面的自定义能力，只需要完备的功能、丰富的 OpenAPI 以及基本的配置即可。

私有化产品不一定只能采用 SaaS 模式，私有化部署的软件一样可以做出标准化产品。非 SaaS 形态的标准化产品具有其他类型标准化产品相似的架构，无非是去掉了租户版里的模块。

生态层面，一方面，可以通过 OpenAPI 将软件能力对外暴露出去，让市场中更多第三方接入，一起围绕软件构造外围应用。另一方面，可以基于产品能力和数据，打通产业链上下游，创建全新的商业运营模式。

接口可以对软件背后的业务能力进行封装，并将封装后的业务能力对外暴露，既可以完成系统对接，也可以扩展应用场景，或放大业务价值。所以，应用程序的接口抽象和服务化并不是单纯的技术问题，还可能是业务问题，甚至上升到商业问题。

从应用系统自身来讲，如果想让系统融入客户的应用架构环境，就必须确保系统有丰富的接口能力，能够实现数据打通和系统集成。

从商业化角度来讲，一个灵活开放的接口体系可以吸引更多第三方开发者参与生态建设，共建更加丰富的应用选项。这样既可以满足甲方的多样化需求，又可以为乙方构建丰富的生态，还可以帮助 ISV 或独立开发者创收。

任何一款在企业里使用的软件产品，都不可能是独立或封闭的，必须考虑与企业应用架构融合的问题。

从数据底层打通到接口服务化，各个系统、各个模块既要保证松耦合、高内聚的设计特点，又必须实现组件化、可插拔的接口能力。良好的接口设计可以加强产品标准化能力，减少个性化需求对产品的影响。

所以，接口设计虽然是技术问题，但需要产品经理对业务有很高的理解，才能抽象出合理的颗粒度和功能。产品经理和技术人员需要一起参与接口设计工作。

虽然我们刚才讲的是 B 端的产品化，但实际上，对于资源有限的团队，前期重点是验证市场、打磨核心产品能力，所以没有必要实现所有标准化功能。

同样，也并不是所有产品都必须演化到最终形态，最终形态也不一定适用于所有产品类型。

如果是自研系统，可以选择商业化。但是，自研系统和商业化产品区别比较大。如果企业决定把自研系统对外售卖，大概率需要将系统从原有的应用环境中解耦出来，然后进行全面重构，否则很难支持不同客户的不同需求。

而相关的抽象设计能力，技术团队并不一定擅长，或者需要很长时间的积累和沉淀才能拥有这种能力。

这不只是技术问题，还有业务运作问题。IT 团队负责人如果欠缺商业化和业务管理经验，直接去驾驭科技公司的商业运作，会有不小的挑战。

当然，如果企业本身在行业里已经属于头部标杆，那么使用的软件系统相当于融入了业务管理和运营的最佳实践，行业内的潜在客户一定会非常感兴趣。所以，相比其他专门做软件的公司，市场可能会更大。