全栈工程师?
嗯.....目前并不是!

後台產品經理必知:多系統間業務對接的4個原則

對於多系統對接,我們除了要信息及業務連通之外,更需要注意科學合理性。

一、需求描述

公司在做的車抵貸業務,需要引入一家新的資金機構,我們稱之為Z機構。它與目前所接入的資金機構所不同的是,Z機構對抵押車的借款成數有限制。比如:某車的評估價為10萬,公司核批的最大借款金額為8成,也就是8萬,但Z機構的最大批核成數卻只有7.5成。最終使得公司核批的成數無法適用於所有機構。

為了儘可能地滿足客戶對資金的需求,解決Z公司的借款成數問題,公司決定引入信貸產品,用於補償這個價差。

二、方案分析

針對Z機構的成數限制問題,需要考慮具體的實現方案。公司的車貸和信貸產品是獨立運營的,要實現車貸和信貸的組合借款,則需要在這兩個系統間進行業務銜接和數據對接。

主要有如下幾點:

  1. 車貸系統根據匹配的資金機構進行處理,當匹配為Z機構時,則判斷用戶借款金額是否超出了成數限制。如是,則自動降低借款金額,並記錄下相關數據,以便提供給信貸系統。
  2. 考慮到組合借款業務邏輯的生效,是需要在車貸訂單放款之後,因此建議由財務系統放款后,通知信貸系統進行相關業務處理。
  3. 信貸系統目前有白名單機制。白名單用戶可直接繞過用戶授信額度評估環節,直接分配一定的額度用於快速借款。有了這個基礎,針對組合借款需求,則可以通過系統改造,根據給定的規則實現白名單的自動生成,最終完成用戶信貸部分借款的順利達成。

三、產品流程

根據以上的分析,可以畫出初步的流程圖(核心流程)。

如下圖所示:

系統間交互的幾個關鍵點如下:

  1. 車貸系統在完成組合邏輯運算后,將調用已有財務系統的申請放款接口,同時增加信貸授信額度等關鍵傳參給到財務系統;
  2. 財務系統判斷當前訂單的資金機構為Z機構時,調用信貸接口傳入信貸額度等參數,通知其啟動白名單生成邏輯;
  3. 信貸系統根據請求,進一步調用車貸接口獲取完整的所需信息後生成相應的白名單。

順着思路再走一遍,也沒發現什麼問題,流程是通的,可以實現本需求。

四、對接復盤

流程是通的,但不代表是合理的。

對於多系統對接,我們除了要信息及業務連通之外,更需要注意科學合理性。因為多個系統,通常會涉及到多個開發團隊。面對系統對接,我們除了要實現當下需求之外,還要儘可能地考慮后後續的需求擴展及功能維護。否則,隨着時間的推移,系統交互會變得越來越混亂,最終變得不可維護。

根據我所總結的系統對接原則,我們進一步來審視分析這個流程。

原則一:盡量簡單,避免因信息傳遞而失真。

在車貸系統調用財務系統接口時,增加了信貸授信額度參數。對於這個參數,顯示是需要通過財務系統最終傳遞到信貸系統的。這很明顯是屬於數據傳遞,而這也是需要避免的。因為信號在傳過程中不可避免地會產生衰減問題,而層層傳遞則會加大這種可能性。為此,我們需要避免這種做法。

那可以不傳這個參數嗎?完全可以。在第3步時,信貸系統在調用車貸接口獲取信息時,完全可以直接通過這個接口可以拿到這個信息。

原則二:保持穩定,盡量避免基礎業務接口的頻繁調整。

同樣還是針對上述對接——放款申請接口,這是作為借款服務最基本的業務接口,需要盡量保持穩定可用,避免因需求的跌代而產生不必要的擴展及調整。從這個角度來看,原本要增加的信貸授信額度等參數也是要避免的。而通過上面的分析已經有解決的方法,這裡不再贅述。

原則三:考慮通用性,不要只解決當下需求。

財務系統判斷為Z機構時,調用信貸系統接口通知其生成白名單,此為新增接口。但其實在財務系統放款后原本就會發出一MQ消息,通知各系統訂單放款這一消息。而這一消息,信貸系統同樣可以監聽並消費。如果是通過放款MQ消息來實現與信貸系統的業務對接,那麼這一過程就變得更為通用了。

同時,讓財務系統作判斷來決定是否通知信貸系統,從通用性上考慮,這也是不合理的。因為如果後續不只是Z機構,還有別的機構也同樣有此需求呢?是否讓財務系統再作一次調整?另外,從業務職責上考慮也不應由財務系統來實現這個邏輯。

綜上分析,從通用性上考慮,採用現有的放款MQ消息實現系統對接,同時在MQ中增加資金機構信息,便於信貸系統作業務邏輯預處理。

原則四:獨立自主性,內部業務邏輯不應由外部系統控制。

針對原本讓財務系統作出判斷來決定是否通知信貸系統生成白名單的邏輯,在這個原則下也是不合適的。因為生成白名單邏輯,是信貸系統的自有的內部業務邏輯,是不應該由外部系統來決定的。相對獨立的業務系統對內部邏輯應該要有絕對的自主性。

因此,對於後續要擴展新的機構實現此類需求或是要關閉這個功能時,則應由信貸系統來負責管控,如設計一配置功能,實現業務的開關及增減。

通過這樣的分析和調整最終我們發現,原本挺特殊的需求,在系統對接實現層面竟然也可以做到如此簡單和通用。複雜的核心業務邏輯都被鎖定在各系統內部,而系統對接部分則基本可以保持穩定和簡單。

最後,我們把調整后的業務流程圖畫下來:

#專欄作家#

星思維,微信公眾號:成長星思維,人人都是產品經理專欄作家。活躍於互聯網金融行業的資深產品經理。喜歡思考,總結,輸出。

本文原創發佈於人人都是產品經理。未經許可,禁止轉載

題圖來自 Unsplash,基於 CC0 協議

版权声明:本文采用知识共享 署名4.0国际许可协议 [BY-NC-SA] 进行授权
文章名称:《後台產品經理必知:多系統間業務對接的4個原則》
文章链接:https://www.pmbear.com/%e5%be%8c%e5%8f%b0%e7%94%a2%e5%93%81%e7%b6%93%e7%90%86%e5%bf%85%e7%9f%a5%ef%bc%9a%e5%a4%9a%e7%b3%bb%e7%b5%b1%e9%96%93%e6%a5%ad%e5%8b%99%e5%b0%8d%e6%8e%a5%e7%9a%844%e5%80%8b%e5%8e%9f%e5%89%87/
本站资源仅供个人学习交流,请于下载后24小时内删除,不允许用于商业用途,否则法律问题自行承担。

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

大前端WP主题 更专业 更方便

联系我们联系我们