金融創新産品必要性在哪裡?編輯導語：面對産品化程度高的金融項目，不知道從何入手？作者為我們分享了自己在做貸前流程全解耦時的經驗，讓我們一起來看一下，我來為大家科普一下關于金融創新産品必要性在哪裡?以下内容希望對你有幫助!

金融創新産品必要性在哪裡

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

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

筆者平時喜歡将事情邏輯化，适當整理後反複複盤，前事不忘，後事之師。

坦白講，這篇文章涉及内容是我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協議

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!