本文从角色、数据、逻辑三个角度分析了——为什么说B端产品用户是流程。
笔者之前设计了一企业服务SaaS产品，如今产品已经上线。C端产品的用户是个人，那B端产品也是如此么？
我认为：B端产品的用户是流程。下图是笔者设计的一个产品功能的流程图（泳道图）。结合此图讲解下为什么说B端产品用户是流程。
这张图由3部分构成：角色（管理员、其他业务角色）、数据（业务数据、系统数据）、逻辑（节点和分支）。
角色
首先说说“人”，也就是使用者。在C端产品中，大多数情况下都是单人使用。这类产品用户往往以自我为核心，产品是否满足了需求？产品解决了什么问题？这些都有单个人决定。
但是在B端产品中，一个人通常是一个角色，如仓管，财务，销售等等，这个人只是参与了工作流程中的一部分（如上图中的管理员，仅起到了平台管理的作用），更确切地说是某个角色参与了其中，而这个角色并不能完全决定产品是否满足了其需求。
在考虑人的问题上，需要从个体和整体出发。个体即单个使用者，系统不是强人工智能，很多事情需要人来完成，用户的交互体验在这个时候B/C端无异，都需要有友善的交互，友好的界面来实现。
但在整体上，B端就需要思考一个C端产品通常没有的功能：权限。每个角色都需要参与，但不同的角色可操作的或者可见的数据都不一样，在这里笔者推荐B端产品同学学习下RBAC模型，可适用于广泛的后台系统。
上图中我们可以看到，TK仅可做发起和结束的操作，对应的数据可见性也是如此（上图中TK不可见JW操作的数据）。不同的角色拥有不同的权限，根据企业客户的需求配置权限是B端产品的基本功能。
三级RBAC模型有岗位和角色设置，可以满足大部分企业需求
说完角色，我们再说说数据。
数据现在越来越被重视，在一个企业运行过程中，其实都是对数据进行操作。每个公司都有不同的业务数据，就算是通用的流程如审批、请假等也可能会有不同的数据产生。在不同的业务中，我们就需要梳理不同的业务模型，其实也就是梳理数据的流动（上图中数据来源是TK，中间经过不同角色处理，最后再回到TK）。在做数据梳理的时候，需要注意版本和统计。
企业生产的产品的迭代更新过程也就是数据的变更过程。积淀下的数据作为历史版本保留是每个企业发展过程的必要需求，一方面历史版本可在后续产品变更过程中起到避免踩坑的作用（互联网产品也不是如此么）；另外历史版本的记录可以作为追溯材料，一旦后续生产过程中出现问题，即可了解原因以及追责。做B端产品的时候，如果开发同学没有做对应的功能准备，记得一定要提醒他们为版本对比、版本记录做好准备工作。
数据另一个必须的操作就是统计。
产品在生产过程中一定会遇到各种异常（生产制造业有良率、合格率），统计生产过程中的数据，了解生产过程中的异常是大型企业必做的工作（通常有个质量管理部门做这个工作）。
其实除了生产的数据需要结合实际业务需要做有关统计外，企业用户往往不会想到一些基础的系统数据：日期、生产批次、处理时间等。在做数据统计时候，一定要提前考虑到这些看似与业务无关的数据，痛点问题其实往往隐藏在这些不经意的数据中。因此，作为产品经理也需要提前考虑到这些数据的采集埋点工作。
PCBA工艺流程
逻辑
说完了数据，最后说下流程中的逻辑。
上一节中有讲到数据的流动，数据怎么流动就是产品设计中的产品逻辑。思考B端产品逻辑往往是考验B端产品经理最基础的基本功。笔者个人认为，梳理产品逻辑的前提是对业务逻辑的梳理，而业务逻辑的梳理就是数据流动的梳理。
绝大多数情况下，产品逻辑是不止一条单向路径的，这也往往是企业用户的痛点所在：内外运作过程中，涉及到不同的人，不同的流程，人在处理这些事务的时候无法像机器一样工作而不出差错，通常情况下就是靠更多的人力来解决。那么B端产品就是将这些业务逻辑抽象成产品逻辑，用软件产品代替人力工作。产品服务对象之一即逻辑。
该图是产品中的一个子功能模块（NPI功能），该图显示了在不同的情况下（节点），数据的不同走向（分支）。如何才能相对完整的做出一个数据流程图？个人认为就是考虑闭环。数据闭环一定是有始有终的，如果发现某一个数据没有出现在任何分支中，那说明这个逻辑肯定出了问题。
在考虑产品逻辑的时候，可能因为分支多节点多，一下子考虑不清楚，个人建议先做主流程的梳理（上图中最左边竖直的流程），通常来说业务流程都会有一个很顺利的主线（最短线路），优先完成该主线路再思考其他线路会比较条理清晰。思考分支线路的时候，还是注意闭环，当出现一个分支选择的时候，先理清其中一条线，再去考虑其他的分支，完成了一个循环再做下一个。在设计过程中，尽可能避免大闭环中套小闭环，不然在程序设计上会非常麻烦，在用户体验上也可能导致层次不清的糟糕体验。
综上所述：B端产品服务于角色、数据、逻辑，而该三者构成的即是流程。缺少任何一个，其余两者皆构不成企业运作。
角色的重点在于权限，不同的角色有不同的功能；
