前言

企业系统纷繁复杂，独立负责一款这样的产品，我们需要有一套逻辑章法支撑，一步一步把产品搭建起来。

什么是企业系统产品

什么是企业系统产品？首先在我的认知体系中，将产品的类型进行了如下划分。

以主体维度划分——

产品类型可分为“消费级产品”和“企业级产品”，也就是我们常说的“C端产品”和“B端产品”。

消费级产品和企业级产品的区分特征在于，产品的客户和用户是否为同一主体。所谓客户，就是付费的那类人；所谓用户，就是使用的那类人。

消费级产品，付费的和使用的都是同一类人；而企业级产品，付费的和使用的不是同一类人。基于以上的阐释，我们可以给出书面的定义——

消费级产品，是指客户和用户为同一主体的产品。

企业级产品，是指客户和用户非同一主体的产品。

以需求维度划分——

产品类型可分为“工具类“、“社交类”、“生活类“、“信息类”、“娱乐类”、“游戏类“六种。

具体的类型定义我就不做冗余阐述了，这些类型还是比较好理解的。

回到文章开头提到的问题，那什么是企业系统产品呢？

所谓企业系统产品，根据上述的分类，就是指企业级的工具类产品。传统概念的企业系统包括ERP、CRM、OA等等，这类产品旨在面向各类业务角色解决企业内部管理线上化的问题。在我看来，企业系统的概念不应局限在内部管理上，而应该还要涵盖外部管理，并且要以核心企业为出发点，所以我认为例如开放平台这类产品也应该属于企业系统的范畴。

综上，我们可以给出企业系统产品的概念，即企业系统产品是企业级的工具类产品，面向各类业务角色，为企业内外部管理线上化提供服务。

0到1的必经步骤

1 评估产品的投入和产出

在建设任何一个产品或功能前，首先都需要考量建设的必要性，企业系统产品更不能例外。对于必要性的考量，无非就是要回答以下几个问题：

①能带来什么价值？

这个问题是产品的基石，实际是在思考用户的本质需求。在这个阶段我们很容易犯的错误就是把解决方案当成是价值本身。

用个大家烂熟于心的例子，用户说想要一匹马，但用户的本质需求其实是想要提高通勤效率。那么我们在回答这个问题时，就不能浅显的认为答案是“我可以给用户提供一匹汗血宝马”，“提供马”只是带来价值的一种解决方案，并不是价值本身。

②价值怎么量化？

一般工具类产品的价值就是降本或增效，那到底能降多少本、能增多少效，是需要给出量化评估的。成本一般可用人力成本、硬件成本来评估，效率一般可用耗时来评估。

这里给出的量化评估，细化后就是后续产品的关键指标和目标。

③影响范围有多大？

影响范围其实可以归入到价值量化的问题中，这里单拎出来的原因是因为这一点很多时候会被我们忽略。在企业系统产品中，影响范围一般可通过角色数、用户数来进行评估。

同样的，影响范围也是后续产品的关键指标和目标。

④需要投入多少资源？

作为产品经理，需要具备一定的成本意识。对于产品开发的投入，一般会通过工时（人日）、硬件、外部采购这三个纬度来评估显性成本。同时，从经济学的角度看，人力资源、部门预算属于私用品，有时我们还需要考量其他产品因未能使用到资源而产生的价值损失等这类隐性成本。

TIPS：前三个问题是从“产出”的角度出发，第四个问题是从“投入”的角度出发。正如微观经济学的厂商理论中，会分为生产理论和成本理论两个方向来研究。

2 业务流程与产品架构

当验证完产品建设的必要性，决定要开发这款产品后，就该进入到业务流程的梳理和产品架构的设计阶段。这是产品从0到1建设时独有的一个必经阶段，我们必须严肃、认真、敬畏。

业务流程，包括了业务流、状态流、数据流，涉及钱的系统还会有资金流。产品架构，是指产品中的功能模块或子系统组合。

对于复杂的企业系统，一般需要先梳理业务流程，再设计产品架构。产品架构会随着业务流程的梳理而逐步呈现，这是一个很自然而然的过程。

在这个阶段，我们会需要借助一些图工具，包括业务流程图、状态图、数据流程图、时序图。

业务流程图主要描述的是业务需要经历的主步骤，是状态图、数据流程图的基石。

状态图主要描述的是业务步骤中存在的各种状态，是梳理异常业务流的强有力的工具。

数据流程图主要描述的是业务系统中会存在哪些数据，这些数据在每个业务步骤中如何流转、如何存储、如何关联。在数据流程图中，功能模块已经可以得到体现，产品架构其实已经初见雏形。

时序图主要描述的是功能模块间的业务、数据、信息、资金的流转，是基于数据流程图对产品架构的最终呈现。

TIPS：注意“这是产品从0到1建设时独有的一个必经阶段”的理解。这个阶段虽然在后续产品迭代（从1到100）的建设中不是必须经历，但是并不意味着就完全不会经历。一切都在变化之中，产品架构也会跟随业务变化发生调整。这并不是鼓励我们可以随随便便的在迭代中重启产品架构设计，架构设计一旦重启，就意味着业务主流程的缺失或冗余，随之而来的就是整个系统问题。这个时候，就提头去见开发哥哥吧。

3 优先级的考量

经济学家说，社会的资源总是不够的，人类的欲望总是多样的。同样的，完成了产品架构的建立，我们对产品所要具备的功能模块或子系统已经了然于胸，但开发资源是有限的。这个时候就需要一套机制或一种逻辑支撑我们做抉择，决定哪些功能要先开发，哪些功能可以后面慢慢迭代。优先级是产品工作中常常挂在嘴边且永远绕不开的话题。

优先级本质上是对功能或需求的一种分类维度，而分类标准可以有两种：用户价值标准、企业价值标准。

以用户价值为标准对优先级进行考量，最经典的就是Google的“牙刷理论”。牙刷理论把功能分为三个层次：很多人用、很多人经常用、很多人不仅经常用而且必须用。

以企业价值为标准对优先级进行考量，可以把功能分为三种：生死功能、特性功能、扩展功能。生死功能是指刚性、痛点、决定产品生死的功能，如数据分析产品的准确性；特性功能是指为了契合用户、提高收入的功能，如数据分析产品的美观性；扩展功能是指不决定生死、不决定定位、不决定体验、但又不可缺少的功能。

通过以上两种标准综合考量，功能模块或子系统的优先级基本也可以梳理出来了。

4 概念模型与操作

接下来，我们就要开始进入具体功能模块的策划。诶，先别急着画原型。在这个阶段，我们需要思考，如何让用户理解系统功能的运作方式，这个过程就是在建立概念模型。

举个栗子，我们常用的电脑，无论是Windows还是macOS，在对文件进行归档时，我们会直接拖动文件到相应的文件夹中。这就是电脑给我们建立的一个概念模型，而且是非常棒的一个模型，基本不用学习，我们就知道要怎么操作文件归档并可在需要的时候快速找到这份文件。但实际在电脑的存储中，这份文件并不是如我们表面看到的那样存放在了具体某一个位置，而是被分散的存放在了许多不同的储存区域。文件和文件夹，以及这种拖动存放，是一种方便用户理解电脑系统在存储方面如何运作的概念模型。试想，如果电脑系统直白的将它原本的运作方式呈现给我们使用，估计我们很多人要烧脑的学习半天才能掌握，并且每次操作都会十分繁琐。

看完这个栗子相信大家应该对概念模型这个东西有点感觉了。概念模型帮助我们把复杂的自然现象转化成可用的、可理解的心理模型，它是组织和理解复杂事物的非常重要的工具。一个好的概念模型，可以化繁为简，减少用户的学习成本，这也是概念模型的意义所在。

完成了概念模型的选型和建立，用户在这个功能模块中需要执行哪些操作以及操作的步骤都将很自然的呈现出来。正如上述电脑的栗子，确定了“文件和文件夹”概念模型，用户要执行的操作就是打开某个文件夹、选中某个文件、拖动文件到另外的文件夹。

TIPS：根据复杂度守恒定律（Tesler's Law）， 无论在产品开发环节还是在用户与产品的交互环节，这一固有的复杂度都无法依照我们的意愿去除，只能设法调整、平衡。所以在建立概念模型时，产品经理不能仅仅关注用户使用的复杂度，还需要考虑当前概念模型的技术可行性，要多和开发哥哥交流。

5 信息架构与页面交互

这个阶段处理的是用户体验要素中“框架层”和“表现层”的事物，相关的理论和方法有很多，我这边就不赘述了，给大家回顾一下交互十大可用性原则吧。

6 关键指标制定

产品的效果必须要有可量化的指标来衡量，而且在产品的不同阶段，需要关注的指标也会有所差异。关键指标的制定需要遵循以下3个步骤：

①明确产品阶段；

②明确每个阶段需要关注或突破的问题；

③针对问题制定有效反馈指标。

根据以上步骤，对于企业系统产品，我们可以梳理出以下关键指标：

其中，“系统触达业务”是指使用系统功能完成了某个业务任务，“系统触达业务数”是指使用系统功能完成了某个业务任务的数量。这个指标主要反映的是，用户是在使用系统功能来处理业务，还是仍然按照传统方法在处理业务。

7 发布计划制定

这个阶段要解决的问题，是如何让用户更快更好更容易的接受产品新功能。我们可以用一句话来描述：在什么时间点，针对哪些角色，针对哪些用户，灰度或全量发布什么产品内容，发布后通过哪些方式教育用户。

总结一下就形成以下的表格：

其中发布策略包括：灰度、全量。教育方式包括：培训、页面指引、页面宣传等。

8 反馈的收集与分析

在这个阶段的指导思路，我们可以采用望、闻、问、切。

望，观察用户的操作。

闻，听用户的吐槽、抱怨、建议。

问，向用户提问，注意要区分目的性提问和探索性提问。

切，分析指标数据，注意要对数据进行清洗和修正。

反馈的收集和分析是一门很深且很有意思的学问，我自己也还在研究积累中，后面会为这个阶段的详细方法单独写一篇文章。

TIPS：问题的答案不是重点，重点是问题背后的意义。不了解问题背后的意义，即使知道答案，也只是照猫画虎、东施效颦。

最后想说的

产品搭建的套路是相通的，以上的8个步骤其实也可以应用到其他类型产品的搭建中。

产品搭建的套路又是不通用的，方法的适合度总是因人而异。所以，试着在你目前的产品建设中对以上套路实践一番，你或许能理解的更到位，同时还能改造优化成更适合你自己的一套方法论。

认知浅薄，欢迎讨论。

                                                                                                            copyright ©️ 山鸡Samson 版权所有