构建共享服务消息中心，避免资源浪费

效率是企业的命门，当企业效率赶不上市场发展，企业就必定会被淘汰。在业务众多的公司里，因为缺乏有效的沟通渠道，很容易就导致重复创造导致资源的浪费。所以，构建一个共享服务消息中心十分重要，它能将所有的产出和资源利用透明共享，有效避免上述情况发生。

我们直奔主题。

一、说需求

先后接到两个需求：

1. 客户经理离职后，需要以短信等方式通知客户此事，尽量避免发生离职客户经理卷款跑路事件。
2. 客户还款逾期超15天后，短信提醒客户经理，让其做好逾期回访相关工作。

先说一下背景： 我们是互联网金融公司，为借款人和出借人提供撮合服务。针对资产端，需要给相关的服务商提供相应的数据服务支持，以便业务能更好地开展。

简要做一下需求分析，经过沟通了解到：

需求1：部分客户为简单省事，对还款事项会直接让其客户经理代劳，将款项转账给客户经理帮其代还。因此类客户大部分是由于不太会使用APP，如要到银行或终端机上进行还款操作则过于麻烦，于是直接通过微信或支付宝方式转给客户经理，让其代还款。

对于这需求，目前比较难从源头上解决掉。而且在业务流程环节上，公司有义务给予客户相应的提醒。且当离职客户经理卷款跑路事件发生后追责时，能在一定程度上规避法律风险。

需求2：借款人逾期30天以上即计提坏账，为降低计提坏账对单月服务商利润的影响，需要提醒服务商的客户经理进行回访。通过短信提醒的方式，能让客户经理及时知晓并做出相应的工作安排。

二、出方案

对于这类消息通知类的需求，其实在现有的各个系统中已经存在类似的功能。

但因前期没有做好统一的产品规划，或必要性不足，所以，只是各系统自己针对所承接的需求进行特定实现，并未做通用化考虑。

所以，已有的功能并不具备可复用性。

后面又进一步了解到：在CRM系统中已经有了一个较为完整的“短信通知”功能，原本是用于针对客户的营销短信发送功能——支持短信服务商选择、短信模板管理和调用、发送时间设置等等。

但这个功能皆为手动操作完成，并不具备系统自动发送和对外服务能力。

简单来说：这个短信通知功能仅仅是CRM系统用于客户营销的一个工具。

基于当前系统条件，我们可以很快提出以下3套方案：

方案一：划定需求的系统归属，各自单独实现。

从合理性和责任归属方面考虑，将这两个需求划分到相应的系统中单独实现；保持对此类需求的当前产品状态。

此方案的优点是：可以快速落地，缺点是功能无法复用。

方案二：扩展“短信通知”功能，对接当前需求。

将CRM中此功能进行扩展，实现系统自动发送能力，同时支持外部系统接入；通过API方式提供短信服务。

此方案的优点是：功能具有一定的复用性。

缺点是：对于CRM系统的定位和职责造成混乱，不利用系统本身的维护和开发团队职责划分。

方案三：建设独立于业务系统的通用消息服务中心，实现消息能力复用。

将此功能独立于当前的任何业务系统，建设一个中台服务——即共享服务。用于支持各业务系统对此类需求的服务的统一调用。

此方案的优点是：可实现功能复用，且能实现数据存储的集中和统一。

缺点是：当下需要投入的资源较多，开发周期较长。

从长远来看，最合理的方案无疑是第3个。特别是对于业务环节长，平台系统多而杂的公司，更是需要考虑业务功能的重用，尽量避免重复发明轮子。

针对这个方案，我们具体来分析一下。

三、讲方案

共享服务中心，是由阿里公司提出来的，是为了解决烟囱式的项目开发，造成的重复开发问题而提出并实践的项目。

在业务众多的公司里，不可避免地在多项业务中存在类似或完全相同的需求。但在由于不同业务开发团队相互独立，为了避免协调沟通这种不可预估的成本，各业务开发团队都采取了“自主”开发的方式解决此类问题。

这样造成的结果就是：各业务团队不断地重复发明轮子，而且这轮子不可复用，造成了资源和时间成本的大量浪费。

更为关键的是：无法重用的功能，持续迭代也无法沉淀。当面对一个新业务提出时，即便公司当前支撑已有业务的系统都趋于成熟，但仍然无法有效地缩短业务创新和推进的时间。

对于企业发展而言，效率就是生命，当企业的效率赶不上市场发展时，一定会被市场及竞争者所抛弃。

为了尽可能地避免这种问题，阿里提出的共享服务中心方案便于解决路径之一。

顺应这个思路，我们对最开始提出的两个需求进行合并处理，抽取通用和稳定的部分划归到共享服务中心来实现，我们称这个部分为： 消息中心 。

简单画一下产品结构图：

业务系统A中维护了客户经理的员工状态，当客户经理离职时，需要在这个系统中操作状态变更。

业务系统B负责贷后管理，当客户逾期时，需要进行相应的处理。

消息中心负责通用能力建设——即消息的发送及管理，基本的数据统计分析服务。

具体来说，消息中心需要做好如下几项工作：

通道接入：

要负责手机短信、APP Push、公众号模板消息、小程序模板消息等各种客户渠道的消息通知功能的发送——即要实现这几块消息形式的系统支持。

要实现这些能力，则消息中心首先要跟各端进行对接，比如：接入各APP的Push功能的API，实现对各APP进行消息推送。还要接入各公众号、小程序，实现模板消息的发送。

总的来说，就是对所有消息通道的接入管理。

消息发送：

通常以API形式开放消息发送功能，由各业务系统调用此API接口实现业务消息的便捷发送。

更近一步，则需要支持消息模板的创建、选用，同时支持通过选用消息模板的方式发送消息等等。

消息管理：

针对待发送和已发送的消息，支持查询和管理，比如：对定时发送类消息，可以支持取消发送；对已发送消息，可以支持查询送达情况。

数据分析：

包括两方面：一是对各业务系统端自己消息发送情况的独立分析；二是对所有业务系统端的整体数据分析。

对于整体的数据分析，因跨越了多个业务系统及各种业务场景，数据更为丰富。经过对比分析，可以得出更有价值的分析结果，对于各业务系统及整个公司的业务发展而言，都是有益的。

对于消息中心服务的设计，再着重说两点：

业务系统对接：针对各种消息类需求，仍由各自业务系统进行对接实现，通过调用消息中心的开放服务实现业务流程的触发。

消息中心并不负责业务逻辑实现，仅负责通用的抽象服务提供。通过API甚至是界面功能调用的方式，提供便捷的公共服务。

有了一个个的服务，对新业务的快速创新就有了良好的系统能力基础。

数据的统一存储：因消息中心对于服务能力的集成，那相应的，其数据存储也由消息中心统一定义及集中存储。

这对于后续的数据分析有了绝对的裨益。因为数据规范标准统一，对业务数据的理解也就更为简单，不存在对不同业务系统数据的定制化处理。因存储集中，则数据提取也非常便捷。

四、谈落地

在企业的发展过程中，业务线会逐步扩展，而产研部门对业务部门的支持很可能无法满足现实的需要。

产研部门对于业务的支持，通常有两种做法：

1. 统一的产研团队

以临时项目组的形式应对来自各业务线的需求。

在项目多的情况下，很可能会出现项目排队，研发资源争抢的问题。最终的结果就是创新发展受阻，业务发展牵制。如果因此而扩充研发资源，也会受到管理能力的制约，很可能出现混乱不堪的局面。

2. 独立的产研团队

划分事业部，同时将部分产品研发资源纳入其中，形成独立的事业部进行业务运作。

这种方案，因资源可控，在一定程度上可以促进业务快速发展。但同时也因职责细分，不可避免地产生资源无法重用而造成浪费的问题。

另外，由于各事业部间的产研团队各自为阵，没有了沟通和协同，则产出的结果必然无法重用，甚至连系统对接都困难重重。

以上两种情况大到多对应企业发展的两种阶段——创业初期和稳定发展期。

在企业业务规模到了一定阶段时，这两种组织形式都无法满足现实的业务发展需要。而共享服务方案的提出，则提供了一种现实可行路径。

共享服务中心的这种产品架构，因需要介入到各业务系统，协同各方完成通用能力的抽取、建设和替代，这样一个过程下来，前期需要投入的成本必然较高，带来的风险也必然加大。

但一旦完成，产研对业务的发展助力将完全是另一番景象。

那么，具体如何落地呢？

主要有两个关键点：

组织先行，发掘有团队合作及服务意识的产品研发人才。

作为共享服务团队，其成员必然要求具有高度的服务意识，善于合作，能积极主动的解决问题。

而不能是封装自我，守着自己一亩三分地的人，这类人也许能力不差，但与其合作则非常困难。最后也会挫败与之对接的业务产研团队的支持之心。

这点非常重要，决定着项目成败的关键。

渐进式推进，从非核心服务入手。

对于建设跨业务跨系统的共享服务，必然会是重构式的重大的系统更新。而面对业务创新发展不可停滞的前提，则需要重构工作与业务支持并行。

因此，对于共享服务的建设，则建议从非核心业务环节入手，逐步推进，步步为营。在一个个成果的基础，最终完成整个系统的革新。

当一个企业发展到一定规模，形成一定的业务复杂度时，就需要考虑产品架构问题。选取更为合理和适用的产品架构，能极大地助力企业业务发展，而不是成为业务发展的绊脚石。

而这一点，需要从上到下形成统一的思想去贯彻执行，一步步地实现系统重构，最终实现对业务的良好支撑。

作者：星思维，微信公众号：成长星思维

本文由 @星思维 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议