如何构建一个能够“容纳”不同角色的用户体系并行处理业务，实现跨流程的协作？
我们之前谈到了基于用户洞察设计产品的业务架构 ，其目的是：实现业务的解耦，以便构建一个“轻型”的2B业务系统，实现可扩容的架构，使得整个系统能够跟上业务快速发展的步伐，而不必为了新业务的增长而重构系统。
我们也花了几个篇幅来介绍“产品架构”的概念、思路和设计的方法，并复盘了一个 2B产品的多租户架构设计 案例。
如果你稍微细心，就能发现其中还缺少了一个关键的环节。
是的，这个环节就是 “用户对象”的问题，就是整套业务系统里面，到底应该如何构建一个能够“容纳”不同角色的用户体系并行处理业务，如何实现跨流程的协作。
事实上，这个问题对系统的影响还包括如何构建角色和权限模型，这一点在后续将继续展开。
作为整个系列的第12篇文章，本文仍然以“O2O平台”作为案例展开。
01 基于工作流梳理用户对象
2B的产品，简单的来说，就是解决很多的用户（发布在很多业务部门，涉及各种交叉并行的业务流程）如何高效率的协同工作的问题。不管是我们常见的OA系统，还是各种复杂的ERP、CRM系统，还是前些年火热的O2O平台。
对任何面向企业的产品来说，都是一头挑起各种不同的用户角色，另一头挑起协作效率的重任。
对普通的使用者来说，这套系统的价值在于节省时间和工作量，通过使用这套系统来实现自身（个人或部门）“业绩”和能力提升。
对企业的管理、决策者来说，这套系统的最多价值在于如何有效的提升整个企业的业务能力。
换一种说法就是：2B的产品，本身指是一个实现企业业务运作协作的工具。它的难点在于： 如何更有效率的容纳N中角色和N多并行业务的处理能力，并通过这一产品，实现企业业务流程的优化创新 ？
2B产品的设计实践，也就是思考如何基于企业客户的业务场景，实现个人 vs 组织的“矛盾性”需求的过程。
不管各种新奇的理论如何，我们首先做的第一件事情始终都是在围绕用户展开，通过实地的业务模拟，考察和分析推演，结合具体的业务流程和工作流程，拆分各个“群体”——系统的服务实体对象。
1. 业务还原
在构建整个 O2O平台的过程，我们大致梳理的业务过程，包括用户发起服务请求、后台处理服务请求、前端完成服务请求三个过程。
简单描述如如下图所示：
业务闭环示意图
服务请求：
用户（不管是2B的客户，还是2C的终端用户）可以通过多种方式发起客服服务请求，在这个过程中，坐席端的首要任务就是如何及时响应用户端的请求，完整的记录用户的问题，并快速解决用户的问题。
从这个过程中，可以拆分的产品价值包括用户端的体验问题以及坐席端的效率问题。
也就是，在这个过程中，需要拆分和解决的问题包括：
这些问题不但涉及到产品的架构设计，也是产品的交互和视觉设计的重要参考依据，必须充分结合实际工作场景，方式和流程，来考虑在交互上的便捷性，甚至视觉上减轻使用者的疲劳感。
实际上，这也是技术选型的重要指标性因素。所以通常来说，产品的需求文档必须要有明确的技术性指标，包括响应时间，并发数等。
ps：在前文 浅析产品的信息架构、产品架构与业务架构谈到的“产品的抽象能力”，指的是这种从上往下的业务分析能力，而不是指能从下往上看各个细节。
对产品经理来说，面向任何一个业务需求，都首先要从大方面思考，再深入到细节性流程，一旦反过来，则整个产品只有功能，而没有业务。
服务调度：
调度，指的是针对某类型用户/客户，发起服务请求的响应和处理。
也就是基于“效率至上”的原则，如何调配最合适的工程师解决用户的问题是最经济、最高效？在这个过程，涉及到很多种场景的优先考虑，比如：有些问题只是一般性的咨询，有的问题则严重的质量问题，还有的问题可能已经引发了群体性和舆论性问题。
这不但需要建立一种完备的处理机制和流程，首先则是需要赋予一线“接线员”相应的权限和能力，能够第一时间识别到风险，也能快速调动相关的资源，及时处理用户问题。
在产品和技术上的处理细节，还需要考虑到资源的瓶颈性，系统必须要能人工干预的调度资源，还要能建立一个“众包”的通道，打通更多的社会性资源加入“平台”。同时，也在一定程度上激发工程师的积极性，来提高服务的处理效率。
服务履约：
这个环节，也是最终如何处理用户服务请求的过程，也是一个对服务质量考核的关键节点，包括服务响应时间、服务质量、用户评价等过程。
业务上，这个环节在某些场景还可能存在服务和产品的二次销售行为。
综上所述，我们就能够把整个复杂的业务过程，抽象成三大“业务动作”，也就是支撑整个系统能够正常运转的基本节点。想象一下房子的支柱，即可理解这种思路设计的系统有那些优势。
换言之，我们在第一阶段设计产品的架构时，根本无需过多的考虑分支流程和细节性逻辑，只需要构建一个支撑平台即可完整的还原整个业务流程。
也就是，我们可以想象自己在打造一个桌面，只需要考虑桌子的四个角之间的构造合理性、稳定性和承重能力，就可以保障未来的业务扩展。
在架构设计的阶段，我们可以把上述的业务流程进一步抽象，整个的业务模型可以表达如下：
O2O平台业务模型
从整个模型上，我们既能看到要服务的用户对象，也能看到各个服务的实体，以及在整个过程中关键业务动作。围绕这些动作，即可完成各种不同场景下的业务订单。
这个平台是一个高度解耦的系统，能够兼容不同的业务和不同的单据格式和内容，对整个系统而言，表现层的内容对业务本身不构成影响因子，整个平台仅依赖“业务动作”的高效运转。
2. 实体拆分
从整个业务模型中，我们梳理出了一个业务全貌，可以清晰的识别到各个服务层所承载的服务能力，即可根据各自的能力进一步的拆分出实体的“业务范围”。
我们也就能基于对整个业务场景的透彻理解，从实际业务的角度逐级分解整个用户角色的边界和在流程中的承接和交互关系。
这种从逻辑层的分解，在系统的设计中，就直接演变对应到实际中的“业务实体”，也就是不同的业务应用对象，他们直接承载着整个平台的业务运作。
(ps：在实际的产品设计中，只需要依据业务场景的展开，即可完整的勾绘出整个平台的业务关系。本文为方便描述，本文示例进行了大量的简化工作。)
角色示例
从上图可以清晰的看到不同的实体，他们的业务边界非常的清晰。在这个逻辑下，我们可以清晰的设计各自的工作流，也就能清晰的界定不同的用户角色权限。
以“门店”为例：TA在这个角色关系中，实际上处于一种“上下承接”的关系。
向上对接订单的调度，负责总部的调度机制和工单协调机制；向下，对接其旗下的服务工程师，负责工程师的调度和工单的协调。
按照这种思路，我们在设计“门店”这个角色和工单的流转业务中，就能很明确的限定它在这个平台中的地位。换句话说，也就能界定它的权限范围和需求范围。也就不会再出现随意性的变更，因为它受制于整个平台的管理规范。
基于这种思路，我们就能够 有效的拆分复杂的应用，解耦整个系统的框架设计，也就能清晰的描述各个用户角色在平台上的职责、权限和价值体现。
整个平台是基于角色的工作流作为出发点，而不是账户，两者可实现柔性的关联关系，而不是强制性的管理关系。
任何用户，只需要符合某种角色身份就可以在平台中自由完整的执行业务动作。这也是整个平台账户体系设计的基本思路。
越是大型的系统，越是要能界定边界，沥青责权。
02 专注于动机设计用户标签
“标签”的目的，除了简化系统设计以后，还有一个重要属性就是构建柔性的网络管理规则，可以根据不同的业务需求，直接配置不同对象。
标签系统可以根据角色的类别、属性、业务动作等进行分解，如下图所示：
这个图，有出现“类别”、“属性”、“可视范围”、“业务动作”这些名词。实际上这四个名词并非通用性术语，而是在构建这个平台以及制定整个平台的SOP采用的一种项目化语言。
根据我的经验，采用这一约束性的项目化语言，有助于团队快速的理解需求，并在规范的范围内加速产品的应用落地。
这里还引入了一个重要的属性：可视范围。
简单的说，就是一个坐席、或者门店，工程师可以根据他们的实际情况，配置他们所能履约完成的业务范围，比如：A门店具备上门服务的能力等。
对于一个产品 / 系统来说，决定业务的是每一个独特的实体对象，也就是在整个工作流过程中的角色，只需要紧扣角色对象，就能够清晰的界定整个平台的边界范围——直接给业务实体打标签。但我们却容易停留在表面，而没有能够深入业务，更谈不上对用户动机的深刻洞察。
换句话说，我们在用户调研过程中，过于倾向于关注用户的行为动作，而不是动机——用户画像过多的停留在个人信息和人口学属性的集合，而没有能够深入到实际业务中。（我们最容易犯的错误就是过于停留在产品的功能上，而不是业务场景中。）
比如：调研发现用户需要频繁的打印那些有规划地点、线路的订单，如果只是去设计一个高效的打印、排版的订单处理和调研界面，显然不是更好的解决方案。
对产品而言，不能提供关于“用户态度和行为特性”的人物角色只是一个“鸡肋”般的存在。因为无法真正理解用户的痛点，无法真正解决用户的“绩效问题”，也就根本不能设计一款真正符合用户预期的产品。
“当用户使用某个产品的时候，他们是为了完成某个特定的工作(到达某种结果)”，这是一句产品名言。
在设计产品时，真正值得高度关注的是用户的目标、产品的使用场景以及用户与产品的关键交互阶段，而不是把焦点集中在用户的任务是什么以及如何完成任务。
所以，在设计用户角色模型时，应该分成两个步骤来完成：
建立对人物角色的同理心，包括用户的履历和年龄、收入等人口学属性。
关注人物角色的动机，包括用户的态度和行为，使用产品的目的和动机，以及在使用产品时的行为细节、偏向和心理感受。
<本文完>
