国外亚洲成av人片在线观看,热99re久久精品这里都是精品,天堂网在线最新版www,国产成人av区一区二区三,51久久成人国产精品麻豆

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

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

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

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

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

在之后的業(yè)務需求中，任何一個環(huán)節(jié)和問題，都會引起最終的結(jié)果的偏差。

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

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

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

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

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

最常見的使用范圍有：

1. 電銷業(yè)務場景，尤其是‘熱名單’分配；
2. 電催業(yè)務場景，巨量案件分配及案件滾動撥打的實現(xiàn)；
3. 風險管理場景，模型規(guī)則應用的配置等。

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

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

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

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

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

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

二、決策引擎的組成

一個常規(guī)的決策引擎的組成有：

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

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

技術(shù)及組件相關(guān)的，在此我只想就個人經(jīng)歷著重提醒注意幾個點：

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

三、一個策略方的產(chǎn)品經(jīng)理，日常應該更關(guān)心什么

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

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

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

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

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

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

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

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

2. 注意與其他系統(tǒng)之間的交互和協(xié)同

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

根據(jù)經(jīng)驗，會與決策引擎會產(chǎn)生交互的系統(tǒng)有：

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

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

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

3. 成本、效率

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

四、我所建議的學習路徑

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

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

五、最后的碎碎念

不得不說，決策引擎的產(chǎn)品運營，相對于其他系統(tǒng)來說，考慮到其對生產(chǎn)的巨大影響，及與其他諸多系統(tǒng)的交互，及產(chǎn)品經(jīng)理與諸多組別的交互，是非?？简炄四托募凹毿牡南到y(tǒng)。另外，不論是運維的問題或者是系統(tǒng)的宕機，又或者是策略的翻來覆去，甚至是前人留下的屎山代碼都會造成可能的生產(chǎn)事故。不了解情況的人，會認為均是你的問題。因此，建議有選擇的時候，慎重選擇決策引擎的產(chǎn)品運營角色。

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

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

本文由 @肥柴周 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議