起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識構建共享服務消息中心，避免資源浪費
效率是企業的命門，當企業效率趕不上市場發展，企業就必定會被淘汰。在業務眾多的公司里，因為缺乏有效的溝通渠道，很容易就導致重復創造導致資源的浪費。所以，構建一個共享服務消息中心十分重要，它能將所有的產出和資源利用透明共享，有效避免上述情況發生。
我們直奔主題。
一、說需求
先后接到兩個需求：
- 客戶經理離職后，需要以短信等方式通知客戶此事，盡量避免發生離職客戶經理卷款跑路事件。
- 客戶還款逾期超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 協議
“部分客戶為簡單省事，對還款事項會直接讓其客戶經理代勞，將款項轉賬給客戶經理幫其代還。因此類客戶大部分是由于不太會使用APP”這個問題解決了第一個需求不攻自破了。
為什么不從源頭解決問題呢，規范業務流程，優化APP支付。而是要做這個需求呢？
客戶的層次參差不齊，在當前狀態下，很難一刀切的杜絕這種問題。