精細化運營的核心支持工具：決策引擎

編輯導語：決策引擎是一個工具，利用決策引擎可以支撐企業在客戶管理(CRM)的各種決策，在決策引擎之上可以開發出各種不同的解決方案。運營要講求精細化，要根據產品、用戶、市場的具體情況制定具體的運營措施。文章主要分享了決策引擎在用戶分層精細化運營領域的應用方法，希望對你有用。

我個人是不太喜歡“道法術器”之類的描述的，所謂強國之策無奇計，結硬寨打呆仗一直是我所篤信的策略和指導意見，但不得不說，前述的幾個短文簡單的描述了精細化運營的“道法術”，也就是為什么要做、到底怎么做、如何控制其不偏離整體目標的問題。拋開這些，個人覺得智能化商業化的決策引擎，算是改變了重人力職場作業模式的最重要的“器”。

在前東家時，有段時間，因項目和工作調整，負責了部門決策引擎的更新換代，或者叫救死扶傷。近期依稀想起來記得剛剛接手該項目時，囿于前人留下的SHIT MOUNTAIN CODE、無說明、無PRD等，作為一個接手一件事務，習慣性了解其全貌的鐵頭娃，著實有一段時間天天撓頭。可以說無從下手，并不理解從怎么樣的角度去切入。

基于后來的理解，大部分的決策引擎，或者說在市面上能買到的決策引擎，大都是基于Drools的二次封裝，其基于JAVA語言。可能是理解過于粗淺，但在我理解上來說，其無外乎做到了兩點：①（理論上的）業務及策略人員可無代碼使用；②賦值效率明顯提升；

一個成熟可用的【決策引擎】，與其說是一個單獨的系統，不如稍微擴展一下視野。其應該是包括Drools在內，包含KYC用戶畫像，KYE經辦人畫像，一個良好的配置中心，一個良好的展示頁面（如穩定的電銷系統/電催系統），以及一個穩定且健壯的策略/運營團隊等。

在之后的業務需求中，任何一個環節和問題，都會引起最終的結果的偏差。

依稀記得當時遍尋適宜的教程而不得。要么流于形式，很顯然是不知從哪里拾得的只鱗片爪的牙慧，要么就是偉光正但不解決實際問題的PPT，要么囿于一隅，很容易將自己的眼光局限在一小塊。并不滿足一個策略部門決策引擎產品經理的需求。

本文基于，DroolsWorkBench6.2/6.4版本。僅對SQL/IMPALA/HIVE/PYTHON有過了解，對決策引擎、Drools毫無了解的視角去展開。希望能為因為種種原因，在策略實施階段，仍需要通過WorkBench編寫偽代碼的策略人員/數據產品人員提供一丟丟幫助，日行一善。如果有人看到了之后能少掉幾根頭發，希望少掉的頭發能長在我的頭上。

CSDN上’在風中的意志’大佬救了我不少頭發，遙遠感謝下。

一、什么是決策引擎及使用范圍

決策引擎，對于業務人員來講，在大部分語境和語義下，都是指在業務線中，可根據復雜的決策規則，起到路由作用，可以支持復雜決策流，決策樹規則的，將案件/客戶分發的一個工具。

最常見的使用范圍有：

電銷業務場景，尤其是‘熱名單’分配；
電催業務場景，巨量案件分配及案件滾動撥打的實現；
風險管理場景，模型規則應用的配置等。

至少在我淺薄的認知中，決策引擎主要起到的就是【客戶】這一核心資源的自動分配任務。

常規的決策引擎，不論是否支持“拖拉拽”的Fancy方式制定決策樹/決策流，無論宣傳語上提到自己支持多少種業務場景。絕大部分的決策引擎，都是基于Drools(基于Java的BRMS解決方案）優化、迭代、融合自己的一些業務經驗，打包而成的東西。

相對于某些同業，仍然使用手工的方式去分配案件，算不清楚營收平衡需要多少客戶，做不到新增登陸APP的客戶及時問詢購買產品意向來說，決策引擎已經算是較為高科技的工具了。

What’s more .決策引擎，個人感覺是通過常規的業務管理方式，已經很難再挖掘業務潛力之后，所自然而然的，基于精細化運營之后所需的一個產品，主要用于策略的頻繁修改及客戶資源的令行禁止，而不是一個常規管理手段都沒有做好的BU，通過引入決策引擎，就可以翻身了。

一個良好的決策引擎，隱含所需的 KYC客戶畫像水平，KYE 員工管理水平，坦而言之，兩者間能做到一個長處已經可以算作優秀，兩個長處可以算作極品了。

KPI靠分解、分層、分類、分級，執行的時候靠定價、定級、定量、定責。做到這些決策引擎才能發揮最大作用。當然這個就不在文章討論范圍內了。

二、決策引擎的組成

一個常規的決策引擎的組成有：

kmodule.xml：定義好的流程文件；
*.drl:由策略人員修改的策略集文件；
KIE結構：’通過KieServices對象得到一個KieContainer，然后KieContainer根據session name來新建一個KieSession，最后通過KieSession來運行規則’。
（可能有）前段展示界面；

對于產品或者策略來說是不是看不懂。沒事，我到現在也看不懂。這部分問題還是交給技術人員去考慮。

技術及組件相關的，在此我只想就個人經歷著重提醒注意幾個點：

還請稍微注意一下*.drl語法：如經典的no-loop 、static 是否循環判斷等，對計算效率及最后結果是否是自己想要的有極大影響；
還請稍微注意一下'<groupid>/<artifactId>/kbasename’等：編寫DRL規則文件時，如果使用的不是拖拉拽版本的決策引擎，針對此類字眼名稱，煩請多次檢查，否則打包時，會導致各種各樣的報錯頻頻；
標簽少點、少點、少點：不論是風控決策引擎，或者是電銷、電催相關的決策引擎；不論是從外部引入第三方的數據標簽，或者是在自己的KYC/KYE中形成自己客戶、坐席的標簽；標簽是有悄無聲息地突然增多的傾向的。標簽應用到決策引擎上，應當是有詳盡完善的測試之后再進行的。此外，標簽應當多一些類別，少一些數量。否則標簽的不及時清理，又會堆積成新的屎山。
新的策略包上線時，不論有多困難，還請做一次上線測試，一次灰度測試：按之前的經驗，假如說待判斷案件有200萬左右時，一次策略回滾，可能導致近12個小時無法生產，在這個時候，鍋是甩不到運維那邊計算效率低的。還請在上線前做一次上線測試。如果條件允許，配按量的灰度測試是極佳的；
版本管理、版本管理、版本管理：現在大部分封裝好的決策引擎已經可以提供版本管理和回滾的功能。但如果你使用的是裸露在外的DROOLS，還請自行做好版本管理的工作，以免之后領導突發奇想想回滾時找不到；
隊列管理、隊列管理、隊列管理：不論是電銷或催收、或者是風控決策引擎，合理的學習交行卡中心所做的隊列管理思路是不會錯的。在編寫策略包時，要清晰的知道這一個策略，是將案件從案件池分到隊列（隊列可以包含虛擬隊列或者所謂的’場景’），還是從隊列分到個人；要做到金字塔原理中的MECE規則，即全覆蓋和不交叉。如果你所編寫的策略，隊列混亂且交叉。只能祝你之后查錯的時候好運，希望接手你工作的人不是200斤帶金鏈子的我。

三、一個策略方的產品經理，日常應該更關心什么

拋開DRL文件，拋開測試類，拋開標簽，拋開賦值語句。竊以為，對一個策略部門的決策引擎產品經理來說，以下的內容才是更應該花時間去考慮的：

1. 清晰、流暢、兼顧各方、高內聚低耦合的決策流

作為一個BRMS工具，某種意義而言，整個系統，都是為了更好地實現業務的決策流。但常規存在的問題是，對于業務而言，每一個部門、小組，對于客戶資源分配，都有自己的一些考慮，任何系統方面的偏差幾乎必然成為業務與產品之間齟齬的理由。

第二個方面，畫在XIMND上的決策樹，在DroolsWorkBench中，因為性能、規則編輯方式、甚至因為其他組件不全、甚至因為技術提供的Drools版本太老的問題，難以實現。甚至需要人肉去劃分兩個進程、決策表來處理同一個問題。此操作是反奧卡姆剃刀原則的。每多一個環節，就會多一分出錯的可能性。

因此，策略部門的決策引擎產品經理，在編寫DRL文件之前，最需要做的，是了解并排查當前決策流中的問題。大概率，當新增一個決策引擎，或者更換一個決策引擎時，當前日常決策流程中，是存在各種各樣的問題的。在梳理過程中發現的各個組之間的客戶沖突，請直接暴露給決策層，避免造成后續的問題。

再具體梳理決策流時，請注意各個層級之間的內聚及不同層級之間的耦合，盡管產品經理并沒有在具體寫實施代碼（其實決策引擎除了初期開發外，DRL文件修改也主要是產品運營去寫。），但是這個原則一定會在之后方便復盤、修改等等。

應當尊重現有工作流，并嘗試改變不合理的工作流，而不是一味服從：在編寫DRL文件，或者調整決策引擎時，決策引擎的產品經理，是比其他任何人更能發現現有的決策流、工作流的問題的。可能是重復判斷、可能是隊列交叉，可能就是兩個判斷流之間有空隙等等。

可以尊重現有的工作流，但也請在有余力的時候，進一步清晰化決策流；否則屎山代碼的積累，會變成一個擊鼓傳花的游戲，問題總會在一個人手上爆炸，你無法知道自己不是那個倒霉蛋。

2. 注意與其他系統之間的交互和協同

拋開機械化地看待系統、看待工作；深覺得任何一個策略人員、數據分析人員、或者產品經理，都應該確實的理解一個問題，任何業務，尤其是一線作業人員較多的業務，系統之間的銜接和補充，甚至是比有多少個系統更重要的問題。重復造輪子拓展自己權限邊界當我沒說。

根據經驗，會與決策引擎會產生交互的系統有：

前端展示即作業系統、標簽集市或數據管理系統、配置管理系統、（有可能）大數據平臺、（有可能）智能外呼機器人等，當然，還有最主要的系統，人。

因此，出于解決生產問題考慮，會有如下一些問題需要考慮：

決策引擎的日志需要保留到怎么樣的一種程度，或者日常作業的數據可以僅保留在作業系統的數據庫中；如何減少代碼的使用量地，可擴展地與標簽集市發生交互；當計算資源不足時，如何妥善的分解決策流，更高效地使用計算資源等等。甚至，需要考慮，如何編寫完善的文檔，當一線作業人員對自己手里的案件有疑問時，可以妥善的處理疑問。

3. 成本、效率

當所使用的數據有外部引入的數據時，或在整個體系中需要使用收費的外部服務時，就會明確牽扯到成本的管控問題。即使是僅出于自己安全考慮，也應當注意到每一筆調用的費用帶來了什么。成本是否可控，是否有足夠的性價比。

四、我所建議的學習路徑

基于之前的不堪回首的經歷，如果你是一個新人的策略部門的決策引擎管理員，建議采用以下的流程去學習熟悉（僅針對非可視化非商業化的產品）:

LESSON1：JAVA基礎了解。如果之前對于代碼，僅有譚浩強C語言級別的了解。甚至C語言課程都沒有看過，建議花1天時間，稍微了解一下類、變量、繼承的概念。
LESSON2: DROOLS基礎了解。DROOLS WORKBENCH盡管是基于JAVA的產品，但其核心概念KIE結構畢竟是單獨的一個內容。建議花1天時間，了解KIE結構，了解SESSION、容器、類的感念。
LESSON3：決策流梳理。類似于上述的內容，請酌情花一段時間，去了解各個組之間的決策流，了解不同組別對客戶的需求、或者隊列的差異。并根據實際情況，生成自己的構想。
LESSON4：自己動手去做測試。不論DRL構想有多優秀，除非使用ECLIPSE或者其他IDLE，在本地對自己的DRL文件進行測試，不然很難認知到自己的設想的錯誤。請在任何版本更迭之前，做好測試及確認工作。

五、最后的碎碎念

不得不說，決策引擎的產品運營，相對于其他系統來說，考慮到其對生產的巨大影響，及與其他諸多系統的交互，及產品經理與諸多組別的交互，是非常考驗人耐心及細心的系統。另外，不論是運維的問題或者是系統的宕機，又或者是策略的翻來覆去，甚至是前人留下的屎山代碼都會造成可能的生產事故。不了解情況的人，會認為均是你的問題。因此，建議有選擇的時候，慎重選擇決策引擎的產品運營角色。

此外，不得不說，決策引擎運營的久了，整個思路確實也更加相信控制論，這可能是管理決策引擎帶來的思路上面的改變。

祝愿所有管理決策引擎的倒霉蛋少掉點頭發。

本文為@運營喵原創，運營喵專欄作者。