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

編輯導語：面對產品化程度高的金融項目，不知道從何入手？作者為我們分享了自己在做貸前流程全解耦時的經驗，讓我們一起來看一下。

其實這是我第一次參與產品化程度這么高的項目——貸前流程全解耦。其實稍有遺憾，我正式參與的時候，項目的雛形都已經有了，不過這完全不影響我抱著學習的心態(tài)去深度參與進去。

筆者平時喜歡將事情邏輯化，適當整理后反復復盤，前事不忘，后事之師。

坦白講，這篇文章涉及內容是我2年前的工作內容，但是這段工作經歷帶給我的產品思維能力，方案決策能力是讓我獲益的。

在我后續(xù)的工作中每每遇到困難，我最經常問自己的是，如果是TA遇到這個問題，TA會怎么分析，怎么解決這個問題？TA就是我在工作中遇到的每一位優(yōu)秀的老師，這個方法也一直讓我獲益。

結合現(xiàn)在做總賬的賬務經驗，再回首之前工作中的貸款交易、形態(tài)轉移、貸后管理等等，對業(yè)務流程的理解更加深刻，很多道理也是觸類旁通。

書歸正傳，本文重點是介紹的是貸前解決方案。首先定義一下我理解的貸前流程：從進件到放款，在此基礎上，可再細化為：授信流程、用信流程。

為了便于理解，我畫了個圖，下圖是一個信用貸款貸前流程示意圖，一些信息在圖中說清楚的，也就不在文中贅述。區(qū)分開授信流程和用信流程，也是現(xiàn)在有很多信貸產品是在同一個授信有效期內循環(huán)用信，按天計息，也就是常說的隨借隨還。

考慮到觸達客戶，我們用“個人中心”的模塊作為一個總入口，在和宿主APP的打通用戶體系下，我們可以在個人中心查詢并展示該userid的所有訂單、所有訂單的訂單狀態(tài)、訂單詳情信息。

這里為什么特意強調“訂單狀態(tài)”，因為訂單狀態(tài)將是推動這個作業(yè)流程前進的唯一關鍵！

一、訂單管理系統(tǒng)

用戶看到的是什么？用戶如何知道當前申請的進展？如何觸發(fā)下一步流程？這里，我引用“狀態(tài)機”的概念進行解釋，這因為需求分析中比較實用的一個方法。

狀態(tài)機，即描述狀態(tài)轉移。由4個要素構成：觸發(fā)條件，當前狀態(tài)，執(zhí)行動作，未來狀態(tài)。（按百度百科的說法是狀態(tài)機可歸納為4個要素，即現(xiàn)態(tài)、條件、動作、次態(tài)，其實一個意思）。

因為是長作業(yè)流程，所以訂單狀態(tài)的管理尤為重要。

根據(jù)下圖中所示意的，系統(tǒng)可根據(jù)初始化配置的未來狀態(tài)，直接展示給用戶明確的操作指向。

途中只是舉例示意了部分狀態(tài)，實際業(yè)務流程中，多則會出現(xiàn)幾十個中間狀態(tài)，但通過這個狀態(tài)轉移的四要素進行梳理，邏輯上還是很清晰的。

訂單管理系統(tǒng)的定位就是對所有的狀態(tài)進行管理，說白了就是一個數(shù)據(jù)庫，對外提供訂單查詢接口和訂單更新接口的服務。

理論上，我們根據(jù)業(yè)務需求對每一個作業(yè)節(jié)點拆分，各子系統(tǒng)按照約定去獲取特定的訂單狀態(tài)的訂單即可。

這里還有一個重要補充，比如在多個產品，授信和用信流程并行的相關場景下，實踐下來，僅僅靠訂單狀態(tài)的篩選還是不夠的，因為訂單狀態(tài)會重復，所以產品設計引入了“場景”的概念。

場景是各個系統(tǒng)最高層級的配置，比如，進件場景JJ001，簽章場景QZ001，風控工作流場景FK001，審批場景SP001，在工作流引擎中按照各個場景編號進行設置，通過設置判斷條件及對應的執(zhí)行邏輯。

例如：工作流判斷訂單狀態(tài)為資信初篩失敗，就不會調起風控工作流的服務，如果訂單狀態(tài)為資信初篩成功，就調永風控工作流服務，風控工作流就會查詢相關訂單狀態(tài)的訂單進行變量加工及決策判斷。

另外，通過場景的概念，標準化各模塊之間的通用接口，各系統(tǒng)之間也可以直接相互調用，進件需要調用簽章完全不需要通過工作流，也可以直接調用，通過喚起SDK的方法，傳入場景編號QZ001即可，簽章處理完成后返回狀態(tài)給進件即可。

至此，通過工作流引擎和訂單管理，完成了系統(tǒng)間運轉。下文對各個模塊做介紹。希望大家不要糾結模塊or系統(tǒng)，職能沒有區(qū)別，只是是否獨立部署而已。

二、進件模塊（系統(tǒng)）

先談談系統(tǒng)定位，進件系統(tǒng)的定位是進件流程中采集字段，這些字段是進行后續(xù)流程的重要依據(jù)。

比如說人工審批，自動化風控，還款計劃生成需要這些重要的信息錄入，另外還需要兼顧監(jiān)管合規(guī)要求，如：客戶影像存儲，客戶信息脫敏等。

在實踐過程中，進件面對的第一個問題就是創(chuàng)建訂單的時點，理論上應該是必要信息完成填寫后，才會去創(chuàng)建訂單請求。

但是考慮到用戶操作，需要有個草稿的訂單狀態(tài)，以便于幫助用戶保留一些曾經錄入的信息，增加一些用戶體驗。

進件字段類型種類較多，部分也是和用戶體驗息息相關。比如：

• 字符型，如姓名，地址；
• 碼表型，如戶籍所在省市。

需要集成一些服務，前面提到的影像上傳，因為有合規(guī)性要求，需要對接專業(yè)的影像系統(tǒng)。

如客戶證件的正反面，在人工審批或者貸后有影像調用查看需求，我們這么解決，進件調影像系統(tǒng)的上傳服務，將返回的fileid作為Value和文件類型：授權書（authorization）、借款合同（contract）等作為key,update到訂單系統(tǒng)中該筆訂單號下，后續(xù)系統(tǒng)根據(jù)約定好的文件類型直接查回fileid直接調影像系統(tǒng)的下載接口即可。

考慮到不同渠道，也考慮了SDK和H5兩種方案。

SDK的好處是，直接集成在手機銀行APP中，native的還有一個好處是用戶體驗更佳，但是一旦改動換包需要提交應用商店，應用商店都有審核流程，實時性沒有那么好。

也鑒于此，后來越來越多的設計直接在H5實現(xiàn)，視覺效果幾乎一致，但是因為資源都是從服務器加載，非常依賴網絡質量，弱網環(huán)境下用戶體驗極差。

基于以上設計，面對不同進件渠道，無論是線上合作導流模式，線上自營模式，還是線下傳統(tǒng)模式，無非是不同的接口，大同小異的字段集。

至于是用戶還是客戶經理，其實本質還是一致的，通過標記區(qū)分，在個人中心查詢訂單的時候，通過標記篩選。

三、風控平臺

之所以稱之為風控平臺，其實是由三個系統(tǒng)組成：

1. 變量加工系統(tǒng)
2. 風控引擎
3. 風控工作流

還是要談系統(tǒng)定位，在這個環(huán)節(jié)需要配置各種決策規(guī)則，在訂單推進來的時候，得到審批結果。

決策規(guī)則引擎的輸入集合其實說白了是一堆{key:value}的結構化數(shù)據(jù)，數(shù)據(jù)來源根據(jù)規(guī)則需要。

• 有內部的，如：財務數(shù)據(jù)，行內黑白灰名單；
• 還有外部的數(shù)據(jù)，如：前海，企查查，同盾等數(shù)據(jù)源。

對接內外部數(shù)據(jù)，使用訂單的三要素或五要素，按配置接口，查詢返回對應的數(shù)據(jù)源數(shù)據(jù)，作為原始變量，系統(tǒng)支持函數(shù)運算的衍生變量，形成一堆的key-value值集。例：

• 借款人手機在網時長（cust_mobile_status）=6
• 借款人配偶手機在網時長（custcouple_mobile_status）=12
• 借款人逾期期數(shù)（over_delay）=3
• 借款人近6個月申請貸款次數(shù)（loanapply_amount）=5

把變量加工的這些值集送給風控引擎，規(guī)則流、決策樹、評分表的配置，使用這些變量根據(jù)配置的規(guī)則得到決策結果。

• ifcust_mobile_status >=6
• 執(zhí)行得分+5
• else執(zhí)行得分+0
• if 得分in （0,100）拒絕
• if 得分in （101,200）轉人工
• if 得分in （200,250）通過

四、審批系統(tǒng)

根據(jù)風控結果，在工作流配置是否需要進行人工審批。這并不是一個必要環(huán)節(jié)，或者更準確的說任何一個環(huán)節(jié)都是可以配置的，業(yè)務流程上不需要就可以不配置。舉個簡單的例子示意：

• if risk_rult = ‘拒絕’，訂單狀態(tài)update為審批拒絕
• if risk_rult =’通過’，訂單直接審批通過
• if risk_rult =‘轉人工’，訂單推入審批系統(tǒng)

審批系統(tǒng)為人工坐席崗位，信審人員會有各種的權限，系統(tǒng)自動分配，或者主動從公海取件，完成資料審批，電話審批后，輸入人工審批結果，提交后系統(tǒng)會到訂單系統(tǒng)中update 最新的結果。

五、結語

當系統(tǒng)模塊解耦之后，通用解決方案如何去覆蓋各類業(yè)務場景是實施過程中重要課題了。

信用貸基本上還是純線上的，但是諸如房抵貸，車抵貸等會涉及房管所，車管所等缺乏成熟IT系統(tǒng)建設的線下部門，系統(tǒng)直接對接存在難度；還有就是線上流程中諸如電子簽章和線下章樣式不一致，合法性也不同于傳統(tǒng)公章效力驗證，這條路也還是有待持續(xù)探索。

這些復雜的作業(yè)模式涉及到線上線下融合，也不是完全走不通，在本文介紹的解決方案下，系統(tǒng)上新增具體的每一個場景的訂單狀態(tài)，然后線下靠客戶經理，渠道經理人工干預進行信息補錄，增加集中作業(yè)進行復核。

做這套系統(tǒng)曾經最大的樂趣，是用我們的通用解決方案去匹配實現(xiàn)業(yè)務的個性化需求，避免定制化開發(fā)。這不僅需要對業(yè)務的深刻理解，一定的前瞻性，更是驗證我們的系統(tǒng)設計的靈活度，參數(shù)化程度。每次評估下來可以支持的時候，其實很有成就感！

本文由 @青雨輕尋 原創(chuàng)發(fā)布于人人都是產品經理，未經許可，禁止轉載。

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