起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識金融科技實踐之路——產品思維看金融產品
編輯導語：面對產品化程度高的金融項目，不知道從何入手？作者為我們分享了自己在做貸前流程全解耦時的經驗，讓我們一起來看一下。
其實這是我第一次參與產品化程度這么高的項目——貸前流程全解耦。其實稍有遺憾，我正式參與的時候，項目的雛形都已經有了，不過這完全不影響我抱著學習的心態去深度參與進去。
筆者平時喜歡將事情邏輯化，適當整理后反復復盤，前事不忘，后事之師。
坦白講，這篇文章涉及內容是我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實現，視覺效果幾乎一致，但是因為資源都是從服務器加載，非常依賴網絡質量，弱網環境下用戶體驗極差。
基于以上設計，面對不同進件渠道，無論是線上合作導流模式，線上自營模式，還是線下傳統模式，無非是不同的接口，大同小異的字段集。
至于是用戶還是客戶經理，其實本質還是一致的，通過標記區分，在個人中心查詢訂單的時候，通過標記篩選。
三、風控平臺
之所以稱之為風控平臺，其實是由三個系統組成：
- 變量加工系統
- 風控引擎
- 風控工作流
還是要談系統定位，在這個環節需要配置各種決策規則，在訂單推進來的時候，得到審批結果。
決策規則引擎的輸入集合其實說白了是一堆{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協議
看完了引發了我的一些思考，感謝作者！
不過我還有兩個疑問：
（1）訂單管理系統中，為什么引入場景，沒有看懂，可以展開說說嗎
（2）以及為什么引入場景之后，就可以實現不需要工作流直接調用簽章呢
受益，感謝作者。