複雜多變業務場景中的系統配置化——券商零售活動管理平台搭建有感

編輯導語：當面臨複雜多變的業務場景時，産品應該如何配置才能更靈活地适應實際，幫助處理效率提升？本篇文章裡，作者就結合實際案例，對上述問題做了探讨，一起來看一下吧。

在企業做軟體産品有兩種目的：一是用于軟體出售、二是用于支援主營業務。

前者以系統産品為核心，标準化程度較高；後者以業務為核心，系統隻是工具，業務需求常常是淩駕于系統之上的。業務形式複雜多變，且未來難以預測，配置化是提高了效率還是淪為業務發展的阻礙？怎樣設計功能才能在變化多端的環境下達到最佳的靈活性和可擴充性？

筆者以在券商搭建活動系統的實際經曆，與大家共同探讨這個話題~

一、零售活動平台搭建背景

不知道你們公司有沒有這種情況：

業務種類繁多，依靠着各種活動投入進行推廣，但活動的布署、獎勵計算等要麼靠手工計算、要麼靠一次性開發。久而久之，活動資料便淩亂地分布在業務同僚的excel表中以及技術人員的代碼裡。

一方面，要是想對活動資料進行投産效果分析、挖掘客戶特征之類的話，資料品質就非常堪憂；另一方面，活動布署及獎勵計算等環節也因為沒有系統化的沉澱而拉低了營運效率。

不巧的是，我們公司就遇到了這些問題。

證券公司作為傳統金融行業的三大劍客之一，即有傳統線下業務的地推模式，近年來也受移動網際網路的影響大力發展線上營銷。随着券商業務發展趨于成熟，總部作為中背景大腦的支撐作用越來越明顯，雖線下活動依賴各地營業部的營銷團隊地推，但整體方案都是由總部進行策劃、督導、營運，為一線員工提供營銷工具支撐。

而線上模式主要針對網際網路大衆客戶，與線下模式互為補充。業務種類繁雜，活動形式多樣，在野蠻發展的過程中，資料品質和營運效率的問題都愈漸凸顯。

在這種背景下，随着業務已成熟發展，自然而然便有了搭建活動管理平台的想法。

從去年6月開始做内部調研，到現在系統一期即将上線，已經過了大半年時間。這中間有感到特别難推進的時候，甚至懷疑這項目到底有多大做的必要，當然也經曆過豁然開朗、跟意見不一的同僚達成共識的時刻。過程中也有很多感悟，在此與各位産品同行們共享~

二、基于需求的任務拆解

在明确了平台是為了提升營運效率和提高資料品質的前提下，就要着手對任務進行拆解了。

首先是資料品質。為了避免活動資料孤島，需要将原先由excel和各業務活動系統生産的資料都集中在這個平台作為唯一的活動結果資料出口。這塊就是統一接口的問題，并不難。

其次是營運效率。要減少手工計算和技術重複開發，同時顯化業務管理功能，就是要讓業務同僚可以根據活動方案自行在系統界面中進行參數配置，進而形成背景獎勵邏輯，自動進行獎勵計算。這算是整個項目中最難的點。

三、系統配置化的邊界思考

我們知道軟體是“對現實世界模組化”：是将一系列具有共性的業務流程提煉出來，展現為系統界面功能，并起到支援這一系列的業務的作用。是以，對于标準的業務流程，是最适合做系統配置化的，因為共性足夠明顯。

那麼，非标準的呢？

開展活動的目的就是用不斷推陳出新的花樣來刺激員工或客戶以推廣業務，似乎它天然就是“非标”模式，且不說從中提煉共性并不是一件容易的事，即便花費大力氣對曆史已開展活動提煉出來了一套系統化功能，但這對未來也同樣适用嗎？

抱着這個懷疑我跟業務和技術同僚讨論，因為習慣了手工核算或者每次由技術寫代碼開發，大家都紛紛表示很難做到配置化，做了一些市場調研後，也沒找到同類産品，不禁問自己：這個項目還有開展的必要嗎？

頂着上司給的壓力，哦不，是打破砂鍋問到底的探索研究精神，我再次思考這個問題：系統配置化的邊界在哪？

系統配置化的本質是提煉共性，那麼理論上，隻要共性足夠多，就可以系統配置化。

仔細研究了曆史活動方案發現，線下活動和線上活動在“是否有足夠多共性”這一點上還是有很大差別的。

線下活動規則形式挺多，但因為所有邏輯行為都是基于數倉名額進行加工計算，雖然計算方式有不同，但其基礎資料都在數倉的固化名額範圍内，即“萬變不離其宗”；而線上活動則因為有客戶的實時互動行為參與，進而産生了更多的不确定性。

對于個性化極強，規則變化非常快的業務來說，如果找不出其中的共性，強行為了界面可配置去搭建一套标準的邏輯規則架構，完全就是在做無用功了。這種情況下，還不如把更多的靈活性放在代碼中，系統隻做資料的歸集和展示。

四、如何在多變的業務場景中提煉共性

通過以上分析，我覺得線下活動雖然看似非标，但是是有足夠多共性可以做系統化的。抱着試一試的态度，我着手開始對業務場景進行提煉。

我想到哲學中有個很重要的特點：高度抽象。因為隻有高度抽象的東西才能适用更廣的場景。系統配置也是一樣，要能靈活運用于各類業務場景，配置功能必須是足夠抽象的。

什麼東西是高度抽象的？就是最基礎最本質的事物。放眼于宇宙，原子的種類并不算多，但卻能組合成世間萬物。

先“解構”再“重組”。

第一步解構：基于業務邏輯的過程拆分

将活動獎勵計算拆分成幾個基本過程：

• ① 什麼對象
• ② 在滿足什麼條件的情況下
• ③ 獲得多少數額的獎勵
• ④ 獎品是什麼
• ⑤ 什麼時候發放

任何活動在①④⑤項的可配置參數都是能窮舉的，是以很好設計。關鍵在于②③，也就是活動規則的核心部分，也是變化度最高的部分。

研究了大量活動規則後，發現各類線下活動方案即有共通之處，也有特别之處，如果全部用固化幾類規則模闆的方式太死闆，肯定是不适用的。需要更高次元的提煉。

第二步解構：“給你積木塊，自己去搭建”

對于第②點”滿足什麼樣的條件“即達标對象的篩選，是整個環節中變化最多靈活度需求最大的一環。但不管活動規則再怎麼變化，線下活動的獎勵總是通過業務同僚們手工計算出來。那試着還原下手工過程。

業務同僚從報表平台上導出需要的報表，對各類報表進行關聯、篩選查詢出想要的達标對象範圍。

本質上，這些報表中的字段都是數倉裡面的名額，那隻要形成名額庫，把名額展示出來以供選取，再提供邏輯加工工具（例如選取名額、選擇邏輯判斷符号、錄入判斷值，形成單個條件，再對單條件進行組合形成最後篩選範圍），就能自行加工出想要的資料了不是嗎。

這跟利用動态SQL的無代碼自助取數平台的原理類似，在資料産品領域其實已經有技術經驗了，是以技術實作層面也不是大問題。

名額在這裡就是我們拆分出來的“最基礎“的元素，是高度抽象的。對這些元素的組合能形成任何我們想要的資料範圍，整套體系是非常靈活的。

第三步解構：權衡靈活需求度與可操作性，并對不确定性留有餘地

已經解決了獲獎對象的範圍資料之後，就是第④項多少獎勵數額了。這塊怎麼拆？

跟第③項不一樣的是，獎勵數額的算法邏輯更加複雜，如果要實作非常靈活的配置自行組合生成算法，且不說能不能實作，對于使用者的操作難度來說也是非常大的。

考慮到第④項的變化程度沒有那麼高，基本能通過曆史方案提煉出幾類算法，并且算法過程中如果需要用到不同名額，前面的名額庫便再次派上用場。是以采用了固定幾類算法模闆+選擇名額的方式形成了一套配置架構。

但畢竟這些算法并不是窮舉，雖然能覆寫曆史所有的算法類型，可不能保證未來的活動沒有新的算法出現。

于是我在配置架構裡面留了一個口子，加入自定義腳本的上傳，以應對未來小機率的不确定性。提高了系統擴充性的同時，還能随着後續系統投入運作業務種類豐富清晰之後，再逐漸提煉這塊非标部分并完善到标準架構中。

至此，就完成了整個業務過程的配置功能設計。

五、總結

其實做這種業務支援類系統常常都會遇到這樣的問題，說到底，是既想要通過實作配置化解放人力提高效率，又想要最大程度拟合業務發展中變化莫測。

這種情況下，不能簡單粗暴地說“魚與熊掌不能兼得”，而是應該具體情況具體分析，判斷系統配置化的邊界究竟在哪，值不值得做配置化。

其次，在覺得能做的情況下，“解構、重組”也許是在看似非标的變化業務場景中提煉出其本質共性的最好方式。當然解構到多大的顆粒度要根據對靈活度的需求來定，顆粒度越小，靈活度越高，但重組的操作難度也越大，這是需要權衡的地方。

最後，對于完全無法預測的未來業務場景，留有非配置的餘地，并随着業務發展将這部分逐漸提煉到标準配置架構中，動态完善配置架構。

本文由 @離子燙電台頭 原創釋出于人人都是産品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協定