起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識復雜多變業務場景中的系統配置化——券商零售活動管理平臺搭建有感
編輯導語：當面臨復雜多變的業務場景時，產品應該如何配置才能更靈活地適應實際，幫助處理效率提升？本篇文章里，作者就結合實際案例，對上述問題做了探討，一起來看一下吧。
在企業做軟件產品有兩種目的：一是用于軟件出售、二是用于支持主營業務。
前者以系統產品為核心，標準化程度較高；后者以業務為核心，系統只是工具，業務需求常常是凌駕于系統之上的。業務形式復雜多變，且未來難以預測，配置化是提高了效率還是淪為業務發展的阻礙？怎樣設計功能才能在變化多端的環境下達到最佳的靈活性和可擴展性？
筆者以在券商搭建活動系統的實際經歷，與大家共同探討這個話題~
一、零售活動平臺搭建背景
不知道你們公司有沒有這種情況：
業務種類繁多，依靠著各種活動投入進行推廣，但活動的布署、獎勵計算等要么靠手工計算、要么靠一次性開發。久而久之，活動數據便凌亂地分布在業務同事的excel表中以及技術人員的代碼里。
一方面，要是想對活動數據進行投產效果分析、挖掘客戶特征之類的話，數據質量就非?？皯n；另一方面，活動布署及獎勵計算等環節也因為沒有系統化的功能沉淀而拉低了運營效率。
不巧的是，我們公司就遇到了這些問題。
證券公司作為傳統金融行業的三大劍客之一，即有傳統線下業務的地推模式，近年來也受移動互聯網的影響大力發展線上營銷。隨著券商業務發展趨于成熟，總部作為中后臺大腦的支撐作用越來越明顯，雖線下活動依賴各地營業部的營銷團隊地推，但整體方案都是由總部進行策劃、督導、運營，為一線員工提供營銷工具支撐。
而線上模式主要針對互聯網大眾客戶，與線下模式互為補充。業務種類繁雜，活動形式多樣，在野蠻發展的過程中，數據質量和運營效率的問題都愈漸凸顯。
在這種背景下，隨著業務已成熟發展，自然而然便有了搭建活動管理平臺的想法。
從去年6月開始做內部調研，到現在系統一期即將上線，已經過了大半年時間。這中間有感到特別難推進的時候，甚至懷疑這項目到底有多大做的必要，當然也經歷過豁然開朗、跟意見不一的同事達成共識的時刻。過程中也有很多感悟，在此與各位產品同行們共享~
二、基于需求的任務拆解
在明確了平臺是為了提升運營效率和提高數據質量的前提下，就要著手對任務進行拆解了。
首先是數據質量。為了避免活動數據孤島，需要將原先由excel和各業務活動系統生產的數據都集中在這個平臺作為唯一的活動結果數據出口。這塊就是統一接口的問題，并不難。
其次是運營效率。要減少手工計算和技術重復開發，同時顯化業務管理功能，就是要讓業務同事可以根據活動方案自行在系統界面中進行參數配置，從而形成后臺獎勵邏輯，自動進行獎勵計算。這算是整個項目中最難的點。
三、系統配置化的邊界思考
我們知道軟件是“對現實世界建?！?/strong>：是將一系列具有共性的業務流程提煉出來，體現為系統界面功能，并起到支持這一系列的業務的作用。因此，對于標準的業務流程，是最適合做系統配置化的，因為共性足夠明顯。
那么，非標準的呢？
開展活動的目的就是用不斷推陳出新的花樣來刺激員工或客戶以推廣業務，似乎它天然就是“非標”模式，且不說從中提煉共性并不是一件容易的事，即便花費大力氣對歷史已開展活動提煉出來了一套系統化功能，但這對未來也同樣適用嗎？
抱著這個懷疑我跟業務和技術同事討論，因為習慣了手工核算或者每次由技術寫代碼開發，大家都紛紛表示很難做到配置化，做了一些市場調研后，也沒找到同類產品，不禁問自己：這個項目還有開展的必要嗎？
頂著領導給的壓力，哦不，是打破砂鍋問到底的探索研究精神，我再次思考這個問題：系統配置化的邊界在哪？
系統配置化的本質是提煉共性，那么理論上，只要共性足夠多，就可以做。
仔細研究了歷史活動方案發現，線下活動和線上活動在“是否有足夠多共性”這一點上還是有很大區別的。
線下活動規則形式挺多，但因為所有邏輯行為都是基于數倉指標進行加工計算，雖然計算方式有不同，但其基礎數據都在數倉的固化指標范圍內，即“萬變不離其宗”；而線上活動則因為有客戶的實時交互行為參與，而產生了更多不確定性。
對于個性化極強、規則變化非常快的業務來說，如果共性較少，強行為了界面可配置去搭建一套標準的邏輯規則框架，完全就是在做無用功了。這種情況下，還不如把更多的靈活性放在代碼中，系統只做數據的歸集和展示。
四、如何在多變的業務場景中提煉共性
通過以上分析，筆者認為線下活動雖然看似非標，但是是有足夠多共性的。抱著試一試的態度，我著手開始對業務場景進行提煉。
我想到哲學中有個很重要的特點：高度抽象。因為只有高度抽象的東西才能適用更廣的場景。系統配置也是一樣，要能靈活運用于各類業務場景，配置功能必須是足夠抽象的。
什么東西是高度抽象的？就是最基礎最本質的事物。放眼于宇宙，原子的種類并不算多，但卻能組合成世間萬物。
先“解構”再“重組”。
第一步解構：基于業務邏輯的過程拆分
將活動獎勵計算拆分成幾個基本過程：
- ① 什么對象
- ② 在滿足什么條件的情況下
- ③ 獲得多少數額的獎勵
- ④ 獎品是什么
- ⑤ 什么時候發放
任何活動在①④⑤項的可配置參數都是能窮舉的，因此很好設計。關鍵在于②③，也就是活動規則最核心、變化度最高的部分。
研究了大量活動規則后，發現各類線下活動方案即有共通之處，也有特別之處，如果全部用固化幾類規則模板的方式太死板，肯定是不適用的。需要更高維度的提煉。
第二步解構：“給你積木塊，自己去搭建”
對于第②點”滿足什么樣的條件“，即達標對象的篩選，是整個環節中變化最多靈活度需求最大的一環。但不管活動規則再怎么變化，線下活動的獎勵總是能通過業務同事們手工計算出來。那試著還原下手工過程。
業務同事從報表平臺上導出需要的報表，對各類報表進行關聯、篩選查詢出想要的達標對象范圍。
本質上，這些報表中的字段都是數倉里面的指標，那只要形成指標庫，把指標展示出來以供選取，再提供邏輯加工工具（例如選取指標、選擇邏輯判斷符號、錄入判斷值，形成單個條件，再對單條件進行組合形成最后篩選范圍），就能自行加工出想要的數據了不是嗎。
這跟利用動態SQL的無代碼自助取數平臺的原理類似，在數據產品領域其實已經有技術經驗了，因此技術實現層面也不是大問題。
指標在這里就是我們拆分出來的“最基礎“的元素，是高度抽象的。對這些元素的組合能形成任何我們想要的數據范圍，整套體系是非常靈活的。此外，活動指標庫的沉淀也提升了數據的復用程度。
第三步解構：權衡靈活需求度與可操作性，并對不確定性留有余地
已經解決了獲獎對象的范圍后，就剩第④項多少獎勵數額了。這塊怎么拆？
跟第③項不一樣的是，獎勵數額的算法邏輯更加復雜，如果要通過非常靈活的配置自行組合生成算法，且不說能不能實現，對于使用者的操作難度來說也是非常大的。
考慮到第④項的變化程度沒有那么高，基本能通過歷史方案提煉出幾類算法，并且算法過程中如果需要用到不同指標，前面的指標庫便再次派上用場。因此采用了固定幾類算法模板+選擇指標的方式形成了一套配置框架。
但畢竟這些算法并不是窮舉，雖然能覆蓋歷史所有的算法類型，可不能保證未來的活動沒有新的算法出現。
于是我在配置框架里面留了一個口子，加入自定義腳本的上傳，以應對未來小概率的不確定性。提高了系統擴展性的同時，還能隨著后續系統投入運行業務種類豐富清晰之后，再逐漸提煉這塊非標部分并完善到標準框架中。
至此，就完成了整個業務過程的配置功能設計。
五、總結
其實做這種業務支持類系統常常都會遇到這樣的問題，說到底，是既想要通過實現配置化解放人力提高效率，又想要最大程度擬合業務發展中變化莫測。
這種情況下，不能簡單粗暴地說“魚與熊掌不能兼得”，而是應該具體情況具體分析，判斷系統配置化的邊界究竟在哪，值不值得做配置化。
其次，在覺得能做的情況下，“解構、重組”也許是在看似非標的變化業務場景中提煉出其本質共性的最好方式。當然解構到多大的顆粒度要根據對靈活度的需求來定，顆粒度越小，靈活度越高，但重組的操作難度也越大，這是需要權衡的地方。
最后，對于完全無法預測的未來業務場景，留有非配置的余地，并隨著業務發展將這部分逐漸提煉到標準配置框架中，動態完善配置框架。
本文由 @離子燙電臺頭 原創發布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
文章里面應該有錯誤吧，第三步解構里面應該說的是第3??項，而不是第4??項，希望能檢查一下
不錯！有學到
謝謝，互相學習！