本文从传统企业工作协同过程当中的痛点入手，介绍了如何打造一款企业级的工作协同门户平台产品；列举出了产品的核心特性，给出了产品功能的应用架构，并给出了产品成功的评价方法。
为什么要打造这样一款产品
各系统业务之间不能互相调用或协同工作，导致形成“信息孤岛”（注1）；数据的复用性和业务的连续性大打折扣。
因信息管理系统太多造成网站Portal、账号、密码的存储和管理对于个人的记忆能力形成挑战；如果记于便签纸上则存在着较大安全风险。
因系统过多导致的信息爆炸造成了“需要”我处理的信息和“不需要”我处理的信息混杂在一起，如何甄别和筛选出对“我”有用的信息、以及使信息不遗漏以免造成业务损失，是一件技术含量相对较低、但重复性较高的搜索和查询类型的工作；需要耗费较多额外的“盯系统”的精力。
除以上可以直接感受得到的问题之外，打造这样一款产品还会有以下三点好处：
各信息管理系统之间因系统提供方不同、解决的具体业务问题不同，这就使各系统界面交互各异、同一事物的命名各异、流程各异，各角色你方唱罢我登场，缤纷繁杂，积重难返；迫切需要一个统一的“门户”类产品将各系统做横向间的有效连接，以解决广泛的工作协同问题；同时采用统一的UI，提升品牌认知度，并降低系统的学习成本。
基于以上，一个统一的“工作协同门户平台”产品已呼之欲出。
是指由人或系统发起协调两个或两个以上的行为主体共同完成同一流程或业务的过程。在协同的过程中，各行为主体目标一致，并在流程或业务的不同阶段担当不同的职责。以一个“学员退费工单”流程为例，涉及以下步骤：
可用以下泳道图来描述以上步骤：
（学员退费流程泳道图）
可以看到，以上退费流程经历了客服平台、工单系统、学员服务平台、订单系统、学员信息管理系统、财务系统6个系统，涉及的角色包含一线客服、学员督导、督导主管、财务专员4个角色，业务流程在做跨系统流转的过程中，各角色在此退费处理的业务上目标一致，工作之间相互协同。
以上各角色在完成各自所属业务时产生了跨系统的情形，如上述案例中的一线客服，除涉及客服平台外，还至少需要用到工单系统和学员信息管理系统。
2.工作协同门户平台
是一个汇聚了待办中心、消息中心的工作门户平台，存在的目标是最大化地减少对各系统的访问，使用户在统一的工作门户平台上解决所有工作协同的问题，最终降低协同成本，增加办事效率。
仍以上述案例为例：在工作协同门户平台上连接所有的信息和业务系统，各角色均在工作协同门户平台上相互协作；使用待办中心处理所有的待办业务，使用消息中心发起即时通讯，而无须再去分别访问其他业务系统或使用其它IM工具发起沟通。
修改后的泳道图如下所示：
（改进后的学员退费流程泳道图）
可看到，系统改进后，所有的角色均在工作协同门户平台上处理退费工单业务，由工作协同门户平台自行处理与其它系统的接口对接问题，由消息引擎（MsgCenter）驱动待办中心的运作；工作入口高度集中化，用户不再需要访问其它系统平台，极大地简化了用户业务操作体验。
工作协同门户平台产品所应包含的特性1.核心特性
（1）可连接性
以工作协同门户平台为核心，连接用户日常工作所涉及到的所有系统和系统业务，如邮件系统、OA、HRM、工单系统、公文系统、采办系统、ERP系统、财务系统等等，使各系统业务均可以通过工作协同门户平台感知并处理。
（2）可扩展性
遵循MVP原则（MinimumViableProduct，最小化可行产品），鉴于所要连接的系统数量众多，在产品的第一阶段可优先连接核心系统和关键业务，并保证可用性、易用性和产品价值；后续跟随产品迭代再加入更多的系统和业务，以相同的方法实现业务系统和业务流程的有序扩展，最终达成所有系统和所有业务流程的全面覆盖。
（3）待办中心
在工作协同门户平台上建立待办中心，其关键能力是侦听和感知所有与当前用户关联的业务流程的流程节点、流程状态变更、会话消息和系统消息、业务通知等等，使当前用户只需要在工作协同门户平台上就可以完成业务的完整生命周期的跟踪和处理（创建、审核、会审、关闭等，依业务不同节点名称会有所不同），并可查看业务处理的统计报表。
（4）消息中心
消息中心的作用是实现系统与人、人与人之间的及时连接，解决的是及时性（Instant）和发散性（Divergent）的问题，以直观的、聊天会话（Conversation）的方式沟通和解决流程之外的随机问题，以文字、语音、图片等类型的消息以及消息上所附加的情感建立人与人之间的情感连接，在沟通中消弭理解偏差、澄清问题本质，促成业务最终达成。
2.其他特性
（1）应用中心
包含应用和工具的创建和管理，如项目管理、日程管理、任务、投票助手、会议室管理、考勤等等，用辅助工具涵盖用户工作日常，提升用户业务效率和管理效率。
（2）易用性
各类型客户端设计遵循面向C端产品设计的原则，注重用户体验。各客户端的设计使符合Windows、Mac、Android以及iOS通用产品设计规范，以降低用户学习成本，使用户更容易上手。管理平台的设计使用成熟方案如基于AntDesign设计的ReactUI组件库，兼顾易用性、低成本、规范化和高效率。
（3）移动化
——上不上火、刺不刺激？
设计思路
结合以上产品特性，我们来构建工作协同门户产品所需要包含的产品能力，产品的应用架构如下图所示：
（工作门户协同平台应用架构）
1.产品前台
（1）工作看板（Dashboard）
（2）待办中心（TodoCenter）
待办中心集成在工作看板中，用于显示用户所有待办和已办的事项。要求在处理待办事项时具有不跳转至其它系统页面而实现接收和处理所有业务流程、项目、日程、任务和工单的能力。
（3）消息中心（MessageCenter）
会话管理：管理所有单人会话和群会话。
会话交互：基于消息引擎，支持单人聊天和群聊天，具有文字消息、语音消息、表情符号、视频会议、截图、文件共享等业界通用的IM的能力。
除通用IM能力外，还应具有体现职场场景的特有的IM的特性，比如消息转任务、已读/未读标识、消息回执等。
（4）组织架构（Organization）
以分层结构显示组织和部门的组织架构；在组织查看和人员管理方面提供全局视图。
（5）应用中心（AppCenter）
（6）个人中心（PersonalCenter）
个人资料设置、系统设置、关于信息等。
（7）管理平台（ManagementBackend）
账号管理：对成员账号的增、删、改、查、停用、启用全生命周期管理；
应用管理：应用的创建、删除、启用管理和接收、发送、显示权限的配置；
安全设置：包括水印功能、密码管理等；
数据统计：数据指标的显示如上线数、上线率、应用访问统计等；
2.支持中台
（1）消息引擎（MsgCenter）
消息队列管理，支持点对点模型和发布/订阅模型以满足不同系统的消息对接能力需求。连接待办中心和各业务系统接口，在系统之间实现语义准确的异步数据传递，并为消息中心接收方和发送方提供中间件支持。
（3）权限和认证（Auth）
权限管理和账号统一身份认证；提供账号在各业务系统的基于角色权限的访问控制（RBAC：RoleBasedAccessCtrol）；提供功能权限和数据权限的权限管理和配置能力；在用户访问各业务系统时拉取权限配置Profile以决定能否访问或仅访问哪些功能和数据。
（4）组织架构（Org）
组织架构管理；供各业务系统调用统一的组织架构的能力。具有与账号中心的组织架构保持单向或双向同步的能力。
（5）账号管理（Account）
对组织中所有账号进行统一管理，包含账号的创建、删除、启用、禁用等，账号信息记录于主数据（MDM）中，并依各系统的具体详情，提供单向或双向账号同步的能力。
（6）邮件服务（Mail）
提供给各业务系统邮件配置和邮件收发的能力。
3.数据底层
（1）BI
工作看板中当需要展示特定业务系统的数据图表，如展示工单处理结果报表时，需要建立特定系统的数据仓库（DW：DataWarehouse），并提供BI（BusinessIntelligence）能力，以便对工单数据和客户资料进行全面分析。
（2）DataMart
提供数据集市DM（DataMart）能力，以便根据各业务系统数据需求的不同封装出各数据子集：DM1/DM2/DM3……以满足不同业务系统数据指标的需求，同时减少即时计算量，提升数据呈现的性能。
（3）MDM
解决信息孤岛问题的经典策略就是建立主数据管理（MDM）。通过应用架构的拓扑设计，帮助各系统存储和识别唯一关键数据，避免关键数据的冗余和非一致性的问题。
和主数据无关的各业务系统的业务数据可分别保留在各业务系统中，无须和MDM同步。各业务系统在做账号管理时，账号信息按照主数据域和业务数据域分别建设。
功能界面
以下我们来展示功能界面，大概的功能界面如以下草图所示：
（1）Dashboard-工作看板
工作看板中放置Banner、新闻中心、待办中心、数据报表、各系统入口卡片；并可根据个人喜好进行卡片排序。待办中心汇聚了各业务系统需要我处理的待办事务，包含应用下发的消息、业务流程消息、任务、日程、项目进度、新邮件等等。所有待办事务均可点击查看业务详细，涉及流程进度的可点击查看流程进展。
（2）MessageCenter-消息中心
（3）Organization-组织架构
以分层结构展示组织的组织架构树。焦点选中账号时，展示个人名片。
（4）AppCenter－应用中心
展示个人权限范围内可见的各应用。APPSTORE准许个人将更多的应用添加到应用中心以满足个人工作需求。
（5）Individualcenter-个人中心
包含个人资料、系统设置和关于模块。
（6）ManagementBackend－管理后台
含数据首页、设备管理、账号管理、应用管理和安全设置模块。
如何评价产品的成功
我们可以定义以下指标的增长来考察B端产品的价值，在制定指标时偏向于“结果性指标”以使指标结果可衡量：
要注意：
因此建议做整体考量，以免以偏盖全。
产品成熟度曲线如下图所示：
（产品成熟度曲线）
在新产品引入之前，旧产品的易用度处于一个较低水平。在新产品引入伊始，因采用MVP策略以及初期产品可能只是集成了部分系统和部分业务，仍然会有跨系统处理业务的情形发生，甚至原系统中相类似的业务反而要在两个系统中分别处理的情形，这个时候新产品的易用度反而是下降的。随着产品的不断更新迭代，易用度会呈现出一个上升曲线，直至产品进入稳定的成熟期。
所以，看到低谷时也不要灰心，寻找rootcause，保持产品初心，坚持迭代的目标不动摇，就一定会成功。
总结
如何做数字化转型是每个传统企业在数字化和信息化过程中所必须考虑的问题。转型不仅仅是引入一两个“表面光鲜”的系统，而是应该在业务流程、业务模式、工作协同、组织架构、人员管理、公司战略等方方面面进行深入思索和重新定义，才能够引领企业走向辉煌。
注：
本文由@神马B端原创发布于人人都是产品经理。未经许可，禁止转载