本文从传统企业工作协同过程当中的痛点入手，介绍了如何打造一款企业级的工作协同门户平台产品；列举出了产品的核心特性，给出了产品功能的应用架构，并给出了产品成功的评价方法。

为什么要打造这样一款产品

在传统企业尤其是政府和大中型企业的信息化建设过程中，因顶层设计时并未兼顾或者是说当信息管理系统数量较少时，并无必要考虑各系统之间协同的问题，导致当企业所使用的信息系统的数量随着时间的推移越来越多时（以本人曾经在某江工作的经历为例，各业务系统的数量加起来会有37个之多），问题也随之暴露：

各系统业务之间不能互相调用或协同工作，导致形成“信息孤岛”（注1）；数据的复用性和业务的连续性大打折扣。

因信息管理系统太多造成网站Portal、账号、密码的存储和管理对于个人的记忆能力形成挑战；如果记于便签纸上则存在着较大安全风险。

因系统过多导致的信息爆炸造成了“需要”我处理的信息和“不需要”我处理的信息混杂在一起，如何甄别和筛选出对“我”有用的信息、以及使信息不遗漏以免造成业务损失，是一件技术含量相对较低、但重复性较高的搜索和查询类型的工作；需要耗费较多额外的“盯系统”的精力。

除以上可以直接感受得到的问题之外，打造这样一款产品还会有以下三点好处：

1. 节省空间：当信息系统较多时对于B/S架构的系统无明显影响，但对于C/S架构的产品尤其是移动端上的应用来讲，将形成挑战。“移动办公”（BYOD，注2）早已成为现代社会职场人士流行的工作方式，但手机上安装多个系统的APP将会占用巨量的存储空间，且拖慢系统的运行速度，严重影响到软件的使用体验。
2. 安全性的需求：在办公移动化之后，应该设计一种方法将生活数据和工作数据分开，以避免“误操作”将加密的工作内容误发到私人聊天群，造成泄密事件；或者是将个人信息误发到工作空间，给他人造成轻率、马虎的负面影响。
3. 破除沟通壁垒：在同一组织的上下级之间、部门之间，以及在各组织之间搭建沟通平台（部门群、临时群、外部群、业务群等），信息及时分享，以提升沟通效率和业务效率；同时避免因“屁股决定脑袋”，和自己业绩相关的事务积极应对，和自己业绩无关的事务敷衍了事，造成业务协同和办事效率低下。

各信息管理系统之间因系统提供方不同、解决的具体业务问题不同，这就使各系统界面交互各异、同一事物的命名各异、流程各异，各角色你方唱罢我登场，缤纷繁杂，积重难返；迫切需要一个统一的“门户”类产品将各系统做横向间的有效连接，以解决广泛的工作协同问题；同时采用统一的UI，提升品牌认知度，并降低系统的学习成本。

基于以上，一个统一的“工作协同门户平台”产品已呼之欲出。

工作协同门户平台产品相关定义

1. 工作协同

是指由人或系统发起协调两个或两个以上的行为主体共同完成同一流程或业务的过程。在协同的过程中，各行为主体目标一致，并在流程或业务的不同阶段担当不同的职责。以一个“学员退费工单”流程为例，涉及以下步骤：

1. 由“一线客服”在客服平台承接学员的退费请求并连接工单系统创建“退费”工单，工单保存后自动流转至“学员督导”；
2. 由“学员督导”在学员服务平台审核学员的退费申请，并通过学员信息管理系统和订单系统查询学员信息、课程信息和订单信息是否符合班级退费制度；若不符合，则填写原因，并流转至“一线客服”，由一线客服负责回访以说明情况；若符合，则备注符合条款，计算退费抵扣及可退数额，流转至“财务专员”；当数额超出设定数值时，流程抄送“督导主管”；
3. “督导主管”在收到“大额”退费工单后，决定是否进行挽留干预；
4. “一线客服”在客服平台收到不符合退费规定的退费工单，组织话术，回访客户；
5. “财务专员”在财务系统请款，将费用退至学员账户（这里为节省流程，省却更高一级的审核环节）；
6. 工单关闭并存档。

可用以下泳道图来描述以上步骤：

（学员退费流程泳道图）

可以看到，以上退费流程经历了客服平台、工单系统、学员服务平台、订单系统、学员信息管理系统、财务系统6个系统，涉及的角色包含一线客服、学员督导、督导主管、财务专员4个角色，业务流程在做跨系统流转的过程中，各角色在此退费处理的业务上目标一致，工作之间相互协同。

以上各角色在完成各自所属业务时产生了跨系统的情形，如上述案例中的一线客服，除涉及客服平台外，还至少需要用到工单系统和学员信息管理系统。

其作用是：查看工单系统以便于及时获取工单进度，作为流程的发起人及所有者，掌控流程进度以便在利益相关者询问项目进度时可以及时回复；查看学员信息管理系统以便在处理退费业务时依据学员的课程信息辅助决策。除业务系统外，作为公司普通成员还需要用到OA系统处理考勤业务以及使用财务系统处理报销事宜等等。

随着公司业务规模的不断扩大，一线客服在处理以上业务的过程中还可能会用到仓储管理系统，以查看是否可及时为学员寄送实物资料以及查看物流进度、需要IM工具的即时通讯能力以便当业务遇到问题需要沟通时，可及时联系到业务相关人员（用QQ或微信也能解决问题，但在品牌建设、“归属感”以及信息安全上会有所顾虑）。面对众多系统平台，无疑降低了一线客服的工作效率，浪费了企业资源，给各角色之间的工作协同带来了挑战。

2. 工作协同门户平台

是一个汇聚了待办中心、消息中心的工作门户平台，存在的目标是最大化地减少对各系统的访问，使用户在统一的工作门户平台上解决所有工作协同的问题，最终降低协同成本，增加办事效率。

仍以上述案例为例：在工作协同门户平台上连接所有的信息和业务系统，各角色均在工作协同门户平台上相互协作；使用待办中心处理所有的待办业务，使用消息中心发起即时通讯，而无须再去分别访问其他业务系统或使用其它IM工具发起沟通。

修改后的泳道图如下所示：

（改进后的学员退费流程泳道图）

可看到，系统改进后，所有的角色均在工作协同门户平台上处理退费工单业务，由工作协同门户平台自行处理与其它系统的接口对接问题，由消息引擎（Msg Center）驱动待办中心的运作；工作入口高度集中化，用户不再需要访问其它系统平台，极大地简化了用户业务操作体验。

工作协同门户平台产品所应包含的特性

1. 核心特性

（1）可连接性

以工作协同门户平台为核心，连接用户日常工作所涉及到的所有系统和系统业务，如邮件系统、OA、HRM、工单系统、公文系统、采办系统、ERP系统、财务系统等等，使各系统业务均可以通过工作协同门户平台感知并处理。

（2）可扩展性

遵循MVP原则（Minimum Viable Product，最小化可行产品），鉴于所要连接的系统数量众多，在产品的第一阶段可优先连接核心系统和关键业务，并保证可用性、易用性和产品价值；后续跟随产品迭代再加入更多的系统和业务，以相同的方法实现业务系统和业务流程的有序扩展，最终达成所有系统和所有业务流程的全面覆盖。

（3）待办中心

在工作协同门户平台上建立待办中心，其关键能力是侦听和感知所有与当前用户关联的业务流程的流程节点、流程状态变更、会话消息和系统消息、业务通知等等，使当前用户只需要在工作协同门户平台上就可以完成业务的完整生命周期的跟踪和处理（创建、审核、会审、关闭等，依业务不同节点名称会有所不同），并可查看业务处理的统计报表。

（4）消息中心

消息中心的作用是实现系统与人、人与人之间的及时连接，解决的是及时性（Instant）和发散性（Divergent）的问题，以直观的、聊天会话（Conversation）的方式沟通和解决流程之外的随机问题，以文字、语音、图片等类型的消息以及消息上所附加的情感建立人与人之间的情感连接，在沟通中消弭理解偏差、澄清问题本质，促成业务最终达成。

2. 其他特性

（1）应用中心

包含应用和工具的创建和管理，如项目管理、日程管理、任务、投票助手、会议室管理、考勤等等，用辅助工具涵盖用户工作日常，提升用户业务效率和管理效率。

（2）易用性

各类型客户端设计遵循面向C端产品设计的原则，注重用户体验。各客户端的设计使符合Windows、Mac、Android以及iOS通用产品设计规范，以降低用户学习成本，使用户更容易上手。管理平台的设计使用成熟方案如基于Ant Design设计的React UI组件库，兼顾易用性、低成本、规范化和高效率。

（3）移动化

在机场、餐厅、酒店或者是车站、大巴等非公司环境下的移动办公场景，在收到协同请求时，为了可以做到即时响应，要求在移动设备上可即时处理业务请求，使不受时间、地点、人员、设备和网络环境的影响。试想一个场景：员工请求正在外出的领导及时审核一个合同，合同金额千万级别，如果未及时批复的话就有可能被竞争对手抢得先机。

领导说：“等我一下啊，我找一个有wifi信号、并可以使用笔记本电脑的地方登录后再给你批复….”

——上不上火、刺不刺激？

设计思路

结合以上产品特性，我们来构建工作协同门户产品所需要包含的产品能力，产品的应用架构如下图所示：

（工作门户协同平台应用架构）

1. 产品前台

（1）工作看板（Dashboard）

工作看板是用户登录客户端后默认显示的第一个界面，含义等同于HOME、First Page。工作看板承载了待办中心、通知、数据看板、新闻推送以及其它系统访问入口的功能。在消息引擎（Msg Center）的支撑下，要求具有承接待办、通知、数据卡片消息推送并显示的能力。

对于从工作看板访问其他业务系统的情形，要求工作看板具有SSO一键登录的能力，避免用户重复输入登录账号和密码。

（2）待办中心（Todo Center）

待办中心集成在工作看板中，用于显示用户所有待办和已办的事项。要求在处理待办事项时具有不跳转至其它系统页面而实现接收和处理所有业务流程、项目、日程、任务和工单的能力。

1. 业务表单发起/查看/处理的能力：在收到业务信息时对业务表单解构，业务处理完毕后重构表单并回传至原系统。还应具有表单自定义的能力，以便根据业务不同自定义不同的表单；以及预置通用的表单模板。
2. 可视化工作流：流程可以自定义，人员可选择、可加签、可转签；审批可撤回、可退审；节点时效可定义。
3. 业务信息调用的能力：除调用主数据（MDM）之外，还需要能够调用业务信息比如工单处理时需要查看位于学员信息管理系统的学员信息、课程信息和位于订单系统的订单信息，以及位于学员服务平台的服务轨迹信息，以便辅助决策。

在流程进度查看和业务信息调用时可自动登录并做业务访问权限判断。

（3）消息中心（Message Center）

会话管理：管理所有单人会话和群会话。

会话交互：基于消息引擎，支持单人聊天和群聊天，具有文字消息、语音消息、表情符号、视频会议、截图、文件共享等业界通用的IM的能力。

除通用IM能力外，还应具有体现职场场景的特有的IM的特性，比如消息转任务、已读/未读标识、消息回执等。

（4）组织架构（Organization）

以分层结构显示组织和部门的组织架构；在组织查看和人员管理方面提供全局视图。

（5）应用中心（App Center）

展示企业邮箱、项目计划、日程、任务、投票助手、会议室、考勤等应用，在管理后台进行应用的生命周期管理（创建、启用、删除，以及权限设定），在客户端上使用应用，覆盖用户工作日常。

（6）个人中心（Personal Center）

个人资料设置、系统设置、关于信息等。

（7）管理平台（Management Backend）

账号管理：对成员账号的增、删、改、查、停用、启用全生命周期管理；

应用管理：应用的创建、删除、启用管理和接收、发送、显示权限的配置；

安全设置：包括水印功能、密码管理等；

数据统计：数据指标的显示如上线数、上线率、应用访问统计等；

设备管理：对PC客户端和移动客户端进行登录管理和本地数据管理等。

2. 支持中台

（1）消息引擎（Msg Center）

消息队列管理，支持点对点模型和发布/订阅模型以满足不同系统的消息对接能力需求。连接待办中心和各业务系统接口，在系统之间实现语义准确的异步数据传递，并为消息中心接收方和发送方提供中间件支持。

（2）统一登录（Passport）

用户只需要登录工作协同平台，就可以直接访问工作看板中所有已对接过的信任的系统，无须再次输入账号和密码访问。

（3）权限和认证（Auth）

权限管理和账号统一身份认证；提供账号在各业务系统的基于角色权限的访问控制（RBAC：Role Based Access Ctrol）；提供功能权限和数据权限的权限管理和配置能力；在用户访问各业务系统时拉取权限配置Profile以决定能否访问或仅访问哪些功能和数据。

（4）组织架构（Org）

组织架构管理；供各业务系统调用统一的组织架构的能力。具有与账号中心的组织架构保持单向或双向同步的能力。

（5）账号管理（Account）

对组织中所有账号进行统一管理，包含账号的创建、删除、启用、禁用等，账号信息记录于主数据（MDM）中，并依各系统的具体详情，提供单向或双向账号同步的能力。

（6）邮件服务（Mail）

提供给各业务系统邮件配置和邮件收发的能力。

3. 数据底层

（1）BI

工作看板中当需要展示特定业务系统的数据图表，如展示工单处理结果报表时，需要建立特定系统的数据仓库（DW：Data Warehouse），并提供BI（Business Intelligence）能力，以便对工单数据和客户资料进行全面分析。

（2）Data Mart

提供数据集市DM（Data Mart）能力，以便根据各业务系统数据需求的不同封装出各数据子集：DM1/DM2/DM3……以满足不同业务系统数据指标的需求，同时减少即时计算量，提升数据呈现的性能。

（3）MDM

解决信息孤岛问题的经典策略就是建立主数据管理（MDM）。通过应用架构的拓扑设计，帮助各系统存储和识别唯一关键数据，避免关键数据的冗余和非一致性的问题。

和主数据无关的各业务系统的业务数据可分别保留在各业务系统中，无须和MDM同步。各业务系统在做账号管理时，账号信息按照主数据域和业务数据域分别建设。

功能界面

以下我们来展示功能界面，大概的功能界面如以下草图所示：

（1）Dashboard-工作看板

工作看板中放置Banner、新闻中心、待办中心、数据报表、各系统入口卡片；并可根据个人喜好进行卡片排序。待办中心汇聚了各业务系统需要我处理的待办事务，包含应用下发的消息、业务流程消息、任务、日程、项目进度、新邮件等等。所有待办事务均可点击查看业务详细，涉及流程进度的可点击查看流程进展。

（2）Message Center-消息中心

包含会话列表管理和会话交互界面，采用类似于微信和QQ等通用的会话交互界面设计，以降低用户学习使用成本。

（3）Organization-组织架构

以分层结构展示组织的组织架构树。焦点选中账号时，展示个人名片。

（4）App Center－应用中心

展示个人权限范围内可见的各应用。APP STORE准许个人将更多的应用添加到应用中心以满足个人工作需求。

（5）Individual center-个人中心

包含个人资料、系统设置和关于模块。

（6）Management Backend－管理后台

含数据首页、设备管理、账号管理、应用管理和安全设置模块。

如何评价产品的成功

与C端产品关注用户数、注册数、活跃度等指标不同，作为B端产品解决方案，产品关注的是业务效率的提升、管理成本的降低以及信息和数据是否安全。B端产品往往为自上而下式或者以行政命令的方式进行推广，因此代表C端产品成功的标志“用户数量超过百万”等并不意味着B端产品也是成功的。我们需要寻找其它代表B端产品成功的方法。

我们可以定义以下指标的增长来考察B端产品的价值，在制定指标时偏向于“结果性指标”以使指标结果可衡量：

• 业务系统覆盖度（=已接入系统数/信息系统总数*100%）

覆盖度越高，代表着系统的统一度越高、作为“门户”的作用越明显；随着指标数值增加用户访问其它系统的数量也会减少，增加了业务处理的便捷度，节省了系统间的互操作时间。

• 核心业务覆盖度（=已接入业务数/所有系统业务总数*100%）

最终的目标是要将所有系统的所有业务都通过工作协同门户平台来处理；与业务系统覆盖度指标相同，体现了的是产品作为“门户”的作用，通过业务处理的“汇聚”来提高体验度和节约用户的互操作时间。

• 业务响应效率

在产品部署之前及之后进行数据埋点。计算产品部署前后业务总体响应效率是否有所提升：从创建开始，到审核、批准、完结每一个环节的响应和执行时间是否有所提升。

要注意：

1. 数据量比较小时是没有意义的；
2. 业务执行效率可能会受到其它因素影响（例如流程的优化和升级）。

因此建议做整体考量，以免以偏盖全。

产品成熟度曲线如下图所示：

（产品成熟度曲线）

在新产品引入之前，旧产品的易用度处于一个较低水平。在新产品引入伊始，因采用MVP策略以及初期产品可能只是集成了部分系统和部分业务，仍然会有跨系统处理业务的情形发生，甚至原系统中相类似的业务反而要在两个系统中分别处理的情形，这个时候新产品的易用度反而是下降的。随着产品的不断更新迭代，易用度会呈现出一个上升曲线，直至产品进入稳定的成熟期。

所以，看到低谷时也不要灰心，寻找rootcause，保持产品初心，坚持迭代的目标不动摇，就一定会成功。

总结

如何做数字化转型是每个传统企业在数字化和信息化过程中所必须考虑的问题。转型不仅仅是引入一两个“表面光鲜”的系统，而是应该在业务流程、业务模式、工作协同、组织架构、人员管理、公司战略等方方面面进行深入思索和重新定义，才能够引领企业走向辉煌。

注：

• “信息烟囱（information silo）”： 又称为“信息孤岛（information island）”，是指一个“孤立”的计算机应用系统，与其他计算机系统在功能上不能关联互动、信息不能共享以及业务流程之间相互独立。
• “BYOD（Bring Your Own Device）”：指携带自己的设备办公，这些设备包括个人电脑、手机、平板等，在机场、酒店、咖啡厅等非公司环境登录公司邮箱和办公系统，不受时间、地点、设备、人员和网络环境的限制。

本文由 @神马B端 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议