金融科技實踐之路——產品思維看金融產品

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

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

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

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

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

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

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

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

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

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

一、訂單管理系統

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

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

因為是長作業流程，所以訂單狀態的管理尤為重要。

根據下圖中所示意的，系統可根據初始化配置的未來狀態，直接展示給用戶明確的操作指向。

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

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

理論上，我們根據業務需求對每一個作業節點拆分，各子系統按照約定去獲取特定的訂單狀態的訂單即可。

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

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

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

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

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

二、進件模塊（系統）

先談談系統定位，進件系統的定位是進件流程中采集字段，這些字段是進行后續流程的重要依據。

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

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

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

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

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

需要集成一些服務，前面提到的影像上傳，因為有合規性要求，需要對接專業的影像系統。

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

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

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

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

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

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

三、風控平臺

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

1. 變量加工系統
2. 風控引擎
3. 風控工作流

還是要談系統定位，在這個環節需要配置各種決策規則，在訂單推進來的時候，得到審批結果。

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

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

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

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

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

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

四、審批系統

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

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

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

五、結語

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

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

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

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

 

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

題圖來自 Unsplash，基于CC0協議