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

　　效率是企业的命门，当企业效率赶不上市场发展，企业就必定会被淘汰。在业务众多的公司里，因为缺乏有效的沟通渠道，很容易就导致重复创造导致资源的浪费。所以，构建一个共享服务消息中心十分重要，它能将所有的产出和资源利用透明共享，有效避免上述情况发生。
　　我们直奔主题。
　　一、说需求
　　先后接到两个需求：
　　客户经理离职后，需要以短信等方式通知客户此事，尽量避免发生离职客户经理卷款跑路事件。
　　客户还款逾期超15天后，短信提醒客户经理，让其做好逾期回访相关工作。
　　先说一下背景：我们是互联网金融公司，为借款人和出借人提供撮合服务。针对资产端，需要给相关的服务商提供相应的数据服务支持，以便业务能更好地开展。
　　简要做一下需求分析，经过沟通了解到：
　　需求1：部分客户为简单省事，对还款事项会直接让其客户经理代劳，将款项转账给客户经理帮其代还。因此类客户大部分是由于不太会使用APP，如要到银行或终端机上进行还款操作则过于麻烦，于是直接通过微信或支付宝方式转给客户经理，让其代还款。
　　对于这需求，目前比较难从源头上解决掉。而且在业务流程环节上，公司有义务给予客户相应的提醒。且当离职客户经理卷款跑路事件发生后追责时，能在一定程度上规避法律风险。
　　需求2：借款人逾期30天以上即计提坏账，为降低计提坏账对单月服务商利润的影响，需要提醒服务商的客户经理进行回访。通过短信提醒的方式，能让客户经理及时知晓并做出相应的工作安排。
　　二、出方案
　　对于这类消息通知类的需求，其实在现有的各个系统中已经存在类似的功能。
　　但因前期没有做好统一的产品规划，或必要性不足，所以，只是各系统自己针对所承接的需求进行特定实现，并未做通用化考虑。
　　所以，已有的功能并不具备可复用性。
　　后面又进一步了解到：在CRM系统中已经有了一个较为完整的“短信通知”功能，原本是用于针对客户的营销短信发送功能支持短信服务商选择、短信模板管理和调用、发送时间设置等等。
　　但这个功能皆为手动操作完成，并不具备系统自动发送和对外服务能力。
　　简单来说：这个短信通知功能仅仅是CRM系统用于客户营销的一个工具。
　　基于当前系统条件，我们可以很快提出以下3套方案：
　　方案一：划定需求的系统归属，各自单独实现。
　　从合理性和责任归属方面考虑，将这两个需求划分到相应的系统中单独实现；保持对此类需求的当前产品状态。
　　此方案的优点是：可以快速落地，缺点是功能无法复用。
　　方案二：扩展“短信通知”功能，对接当前需求。
　　将CRM中此功能进行扩展，实现系统自动发送能力，同时支持外部系统接入；通过API方式提供短信服务。
　　此方案的优点是：功能具有一定的复用性。
　　缺点是：对于CRM系统的定位和职责造成混乱，不利用系统本身的维护和开发团队职责划分。
　　方案三：建设独立于业务系统的通用消息服务中心，实现消息能力复用。
　　将此功能独立于当前的任何业务系统，建设一个中台服务即共享服务。用于支持各业务系统对此类需求的服务的统一调用。
　　此方案的优点是：可实现功能复用，且能实现数据存储的集中和统一。
　　缺点是：当下需要投入的资源较多，开发周期较长。
　　从长远来看，最合理的方案无疑是第3个。特别是对于业务环节长，平台系统多而杂的公司，更是需要考虑业务功能的重用，尽量避免重复发明轮子。
　　针对这个方案，我们具体来分析一下。
　　三、讲方案
　　共享服务中心，是由阿里公司提出来的，是为了解决烟囱式的项目开发，造成的重复开发问题而提出并实践的项目。
　　在业务众多的公司里，不可避免地在多项业务中存在类似或完全相同的需求。但在由于不同业务开发团队相互独立，为了避免协调沟通这种不可预估的成本，各业务开发团队都采取了“自主”开发的方式解决此类问题。
　　这样造成的结果就是：各业务团队不断地重复发明轮子，而且这轮子不可复用，造成了资源和时间成本的大量浪费。
　　更为关键的是：无法重用的功能，持续迭代也无法沉淀。当面对一个新业务提出时，即便公司当前支撑已有业务的系统都趋于成熟，但仍然无法有效地缩短业务创新和推进的时间。
　　对于企业发展而言，效率就是生命，当企业的效率赶不上市场发展时，一定会被市场及竞争者所抛弃。
　　为了尽可能地避免这种问题，阿里提出的共享服务中心方案便于解决路径之一。
　　顺应这个思路，我们对最开始提出的两个需求进行合并处理，抽取通用和稳定的部分划归到共享服务中心来实现，我们称这个部分为：消息中心。
　　简单画一下产品结构图：
　　业务系统A中维护了客户经理的员工状态，当客户经理离职时，需要在这个系统中操作状态变更。
　　业务系统B负责贷后管理，当客户逾期时，需要进行相应的处理。
　　消息中心负责通用能力建设即消息的发送及管理，基本的数据统计分析服务。
　　具体来说，消息中心需要做好如下几项工作：
　　通道接入：
　　要负责手机短信、APPPush、公众号模板消息、小程序模板消息等各种客户渠道的消息通知功能的发送即要实现这几块消息形式的系统支持。
　　要实现这些能力，则消息中心首先要跟各端进行对接，比如：接入各APP的Push功能的API，实现对各APP进行消息推送。还要接入各公众号、小程序，实现模板消息的发送。
　　总的来说，就是对所有消息通道的接入管理。
　　消息发送：
　　通常以API形式开放消息发送功能，由各业务系统调用此API接口实现业务消息的便捷发送。
　　更近一步，则需要支持消息模板的创建、选用，同时支持通过选用消息模板的方式发送消息等等。
　　消息管理：
　　针对待发送和已发送的消息，支持查询和管理，比如：对定时发送类消息，可以支持取消发送；对已发送消息，可以支持查询送达情况。
　　数据分析：
　　包括两方面：一是对各业务系统端自己消息发送情况的独立分析；二是对所有业务系统端的整体数据分析。
　　对于整体的数据分析，因跨越了多个业务系统及各种业务场景，数据更为丰富。经过对比分析，可以得出更有价值的分析结果，对于各业务系统及整个公司的业务发展而言，都是有益的。
　　对于消息中心服务的设计，再着重说两点：
　　业务系统对接：针对各种消息类需求，仍由各自业务系统进行对接实现，通过调用消息中心的开放服务实现业务流程的触发。
　　消息中心并不负责业务逻辑实现，仅负责通用的抽象服务提供。通过API甚至是界面功能调用的方式，提供便捷的公共服务。
　　有了一个个的服务，对新业务的快速创新就有了良好的系统能力基础。
　　数据的统一存储：因消息中心对于服务能力的集成，那相应的，其数据存储也由消息中心统一定义及集中存储。
　　这对于后续的数据分析有了绝对的裨益。因为数据规范标准统一，对业务数据的理解也就更为简单，不存在对不同业务系统数据的定制化处理。因存储集中，则数据提取也非常便捷。
　　四、谈落地
　　在企业的发展过程中，业务线会逐步扩展，而产研部门对业务部门的支持很可能无法满足现实的需要。
　　产研部门对于业务的支持，通常有两种做法：
　　1。统一的产研团队
　　以临时项目组的形式应对来自各业务线的需求。
　　在项目多的情况下，很可能会出现项目排队，研发资源争抢的问题。最终的结果就是创新发展受阻，业务发展牵制。如果因此而扩充研发资源，也会受到管理能力的制约，很可能出现混乱不堪的局面。
　　2。独立的产研团队
　　划分事业部，同时将部分产品研发资源纳入其中，形成独立的事业部进行业务运作。
　　这种方案，因资源可控，在一定程度上可以促进业务快速发展。但同时也因职责细分，不可避免地产生资源无法重用而造成浪费的问题。
　　另外，由于各事业部间的产研团队各自为阵，没有了沟通和协同，则产出的结果必然无法重用，甚至连系统对接都困难重重。
　　以上两种情况大到多对应企业发展的两种阶段创业初期和稳定发展期。
　　在企业业务规模到了一定阶段时，这两种组织形式都无法满足现实的业务发展需要。而共享服务方案的提出，则提供了一种现实可行路径。
　　共享服务中心的这种产品架构，因需要介入到各业务系统，协同各方完成通用能力的抽取、建设和替代，这样一个过程下来，前期需要投入的成本必然较高，带来的风险也必然加大。
　　但一旦完成，产研对业务的发展助力将完全是另一番景象。
　　那么，具体如何落地呢？
　　主要有两个关键点：
　　组织先行，发掘有团队合作及服务意识的产品研发人才。
　　作为共享服务团队，其成员必然要求具有高度的服务意识，善于合作，能积极主动的解决问题。
　　而不能是封装自我，守着自己一亩三分地的人，这类人也许能力不差，但与其合作则非常困难。最后也会挫败与之对接的业务产研团队的支持之心。
　　这点非常重要，决定着项目成败的关键。
　　渐进式推进，从非核心服务入手。
　　对于建设跨业务跨系统的共享服务，必然会是重构式的重大的系统更新。而面对业务创新发展不可停滞的前提，则需要重构工作与业务支持并行。
　　因此，对于共享服务的建设，则建议从非核心业务环节入手，逐步推进，步步为营。在一个个成果的基础，最终完成整个系统的革新。
　　当一个企业发展到一定规模，形成一定的业务复杂度时，就需要考虑产品架构问题。选取更为合理和适用的产品架构，能极大地助力企业业务发展，而不是成为业务发展的绊脚石。
　　而这一点，需要从上到下形成统一的思想去贯彻执行，一步步地实现系统重构，最终实现对业务的良好支撑。