業務系統如何對接第三方服務?

4 評論 28512 瀏覽 167 收藏 23 分鐘

在產品工作中,我們時常要對接第三方服務。本文作者從過往的對接項目經歷中,提煉的關于業務系統,如何對接第三方服務的方法論,希望能對你有所幫助。

隨著公司業務的發展,我們有時會遇到,需要在自身業務系統中加入新服務,但不能純自主開發的情況。

比如會有以下三種:

  1. 沒有資質:有些業務需要有相應的行業資質才能開展,如第三方支付業務,就要求有支付牌照才具有研發資質;
  2. 能力不足:相比頭部互聯網公司,中小型公司的自研能力相對不強,難以實現需求。如人臉識別,就需要基于AI的識別算法提取人臉特征,沒有一定的技術積累則可能無法實現;
  3. 能做但投入產出比不高:要投入大量的資源和精力,且開發難度大,周期長,很容易得不償失。如搭建客服系統,光是保證消息的收發穩定,都要不短的開發周期,更別說智能分配客服和智能機器人這樣的高級功能了。

而這時如果恰好市面上有成熟的解決方案,我們便可以把專業的活,交給有一定資質且專業的人,接入他們的能力來解決自己的問題。

比如,我們要在電商系統中,接入物流軌跡查詢的能力,自研的話,需要對接多家物流公司的單號系統,費時費力還可能對接不成功。此時若有第三方服務商,已經整合了多家物流公司的物流軌跡查詢,我們便可以直接通過與其進行對接合作,來實現自己的物流查詢功能。

通過接入合適的第三方服務,既不用讓公司在新領域自研試錯,投入過高的開發成本,又能縮短開發周期,讓我們的業務產品快速獲得更加專業穩定的服務,變得更加成熟、強大。

以上對公司的好處我們了解了,但了解并接入三方服務,這工作對產品經理來說往往不是件易事。

做產品沒有標準答案,我們做的每一個產品方案,都是在一個特別具體的環境下產生的。每一次都是定制,對接第三方更為如此。既要快速了解另一個領域的基本知識和行業產品,又要結合選定的第三方服務與公司新提出的業務需求,設計出一期最適合的產品方案,每一次都像是在摸著石頭過河,有著說不上來的困難。

在對過往的多個對接項目經歷,進行反思后,我將整個對接過程劃分為三個階段,并試圖提煉出各個階段應遵循的共性要點,讓我們在對接時能夠有章可依,降低事情難度,希望能對你有所幫助。

階段一:設計前

產品經理在進行具體的方案設計之前,應做哪些事情呢?

1. 對自身業務系統有整體的理解

只有對我們的業務系統,先有全局的理解和把握,才能在知曉業務需求和三方的解決方案后,剖析出要改動的所有部位,做到纖悉無遺。

如若不然,對自身系統結構和業務都還一知半解,就貿然開始著手三方調研和方案設計,很容易因為前期考慮不全,而造成難以預見的危險后果。

舉個例子,有一個后臺管理系統,管理著線上商城和線下門店的零售業務,你要在整套系統中接入新的第三方聚合支付,逐步替換掉原有的三方支付服務。

若你對業務系統的了解還不足,就直接分析如何使用三方服務能力,并產出方案,推動項目上線。運氣好的話,你可能只犯了點小錯誤。比如在前端商城中,對某個業務頁面改了些字段,而后臺的一個統計頁面,你遺漏了對其進行同步更改,導致無法正常顯示。這影響范圍還較小,你還能在上線后進行及時補救。

但若嚴重的話,你的考慮不全,甚至可能會直接影響到系統關聯業務的正常運行。比如,之前一直都是負責線上產品的迭代,在這次項目中,由于你沒有去加強對線下業務的理解,導致在設計過程中,你直接疏忽了門店的重要設備——POS機,在里面軟件的自建訂單頁面中,也需要更換新的支付方式。由于沒有在這次項目中同步更改,將直接影響線下刷卡、掃碼等場景的業務的正常開展。

那么需要對業務系統了解到什么程度呢?我們可以通過對風險進行分類,然后倒推得出前期的準備。

可以跟我一樣,將這些可能的風險,用二分法,簡單劃分為直接影響業務與間接影響業務。

直接影響,即影響業務的閉環運行。一旦沒有兼顧到里面的任一環節,都會干擾到業務的正常進行。所以你需要做到,對該業務需求所涉及的主線業務流程,和其中的邏輯都有清晰的認識,哪怕對里面的任一個字段規則抱有疑問,你都應該剖根問底。分析其如若是個錯誤,是否應在這次項目中一同解決,避免其對新老業務產生影響。

間接影響,即不影響項目主流程正常進行的其他影響。如統計、設置等地方的關聯改動,這種屬于支線流程的需求最容易被我們忽略,但只有都顧及到,才能讓方案更加完整。在開發評審時,我們的方案很少能一次通過,都會有或多或少的修改。你可以跟我一樣,將在每次評審時所發現的,設計時被遺漏的功能或業務,都記在備忘錄中,用于在后續每次設計方案產出后進行自查,以提高初次方案的完整度。

為了更好地降低風險,還可以邀請公司中對該業務熟悉的相關人員,來參與你的設計方案評審,一同檢查是否有設計遺漏,多一道保險,避免自己顧此失彼。

2. 完成第三方產品的調研

我們在購物時,為了選到最心儀的商品,通常會貨比三家。同樣的,為實現業務需求而接入的第三方,將會在很長的時間內伴隨著自身產品,這就更需要我們去仔細的篩選。

商品不喜歡,我們可以選擇退貨或者重新選購,但接入的三方服務不合適,即使我們去重新找新的服務商合作,卻也已經在之前的對接過程中,讓企業付出了成本,這是無法挽回的。

所以在具體對接前,我們應對三方服務商做仔細地調研與篩選。

這過程我劃分為兩個小階段,調研初篩和名單提交。

1)調研初篩
剛開始去了解一個新的領域,你需要做的是,快速研究清楚里面的一些核心概念,然后盡可能多地收集行業產品的信息,并簡要分析其服務能力與我們業務需求的匹配度如何。

而考察其服務能力,最為關鍵的點,無疑就是對我們基礎需求的滿足度,和其產品的拓展性了。

1.基礎需求

基礎需求,即本期要實現的業務需求能否滿足,這一點還是相對容易判斷的。

比如,你要在業務系統中,實現在線下單發貨的功能。在訂單發貨時,通過接口傳送面單信息后,接收物流公司返回的快遞單號信息,并且能獲取物流軌跡更新。

這種只需將核心需求梳理后,與其官網的業務描述進行比對,或者直接詢問客服或銷售,就可以快速知道能否實現。

2.產品拓展性

業務需求極少能一次性滿足,往往會隨著業務的發展而變化。所以僅考慮現階段需求的滿足,是不夠的,你還需要進一步了解。這次為滿足基礎需求,所用到的三方產品和服務,能否滿足未來定制化的需求。判斷其拓展性如何,即二次開發的能力。

比如,在對新業務需求進行分析梳理后,我們通常會有多期項目規劃。一期滿足核心需求,后續就要考慮,如何實現重要但非一期優先的附加需求了。如果屆時的迭代方案,需要對已經使用到的三方產品頁面或者系統,進行調整設計,而對方并不支持對其二次開發或者改動難度大,周期長,那就需要更加慎重的考量了。

在平常工作中,我們也要不斷去鍛煉思考問題本質的能力,不讓產品設計停留在表面,只能解決當前問題,而要考慮到是否能承接業務未來更多變化的需求。

2)名單提交
在初步調研后,你需要對初篩合格的三方服務商進行縱向研究,完成調研對比產出,并附上綜合分析后的建議,給到對應的決策者進行選擇。

其中的分析至少包括以下三個維度:

1.成本

在使用第三方服務時,往往會伴隨著各種費用的產生,這也是公司最為關注的點之一,需要我們做仔細地調研。

常見的費用類型有:

  • 服務費用:在使用服務商的某款產品或服務的過程中,產生的服務資費,一般按實際使用量或使用時長付費。如,調用人臉識別的次數,按次收費,使用即時通訊服務的期限,按每月固定的費用收取。
  • 授權費用:我們所選擇的服務,需要通過使用對方的SDK去對接時,就有可能要收取對應的費用,即該SDK在固定期限內的使用授權費。 不過也不是固定收取的,有時也會結合服務費用里的套餐包免費贈送,如騰訊云直播購買特定流量包后,就會贈送一年的直播SDK使用權限。
  • 對接費用:在初次對接對方產品時,需要一次性收取的接入費用。一般只在系統級的定制對接,即業務對接復雜度較高時,才有可能要支付這項費用。類似于平臺接入銀行的存管系統這種,才會收取對接費用。

每家服務商都有自己的收費模式,我們需要了解清楚后,結合自己的需求,去思考最適合公司現階段的選項或組合。

2.風險

若是接入的三方服務不穩定,那么在上線后,對自身產品所帶來的影響將是災難級的。

服務不穩定帶來的卡頓,或者數據錯誤與丟失等問題,將會直接影響用戶對產品的體驗和印象,甚至直接棄用產品。

所以穩定,便是對三方服務能力要求的重中之重了,但這也是我們在初次對接時,往往很難判斷的一項。

如果直接問服務商其接口的穩定性如何,對方一定會說很穩定,因為沒有人會想在初次合作時,暴露自身問題,讓客戶動搖導致合作失敗。所以我們需要,多從其他途徑去了解真實情況。

比如可以通過以下幾個小點去評估和減小風險:

  • 了解對方業務的沉淀程度:新業務代表著不成熟與高風險,業務的發展需要一定時間的摸爬滾打才能趨于完善。新業務的性能不足和異常流程處理機制的不完善,都會讓我們在使用時具有極大的不確定性。所以業務沉淀越久越好,個人建議直接找頭部的服務商,或者該業務至少開展了2年的服務商。
  • 先接入支線業務:確定服務商后,最低風險的對接方法,就是先拿自身業務流程中的邊緣業務去試手。在對三方服務能力不夠確定的情況下,先不要對接核心業務。在熟悉對接流程與其服務能力后,再逐步進行核心業務的全面對接。比如,之前在對接某銀行的聚合支付時,我們就先挑選了業務系統中的一個簡單業務進行對接驗證,即后臺系統中的短信付費,有個掃碼支付的場景,可以直接接入這項新支付方式進行測試。然后該支線業務的流程跑通后,我們再在所有的支付場景中,接入該聚合支付。
  • 要有備選的服務商:項目上線后,才能驗證當時方案的可行性和三方的服務能力。沒上線前,我們也不能確信,初次合作的三方服務商,其服務能力能否很好實現業務要求。所以你需要在接入效果不好時,有可以緊急更換的選項,才能做到有備無患。

3.產品配套

初篩時我們所關注的是,要使用到的單個產品的拓展性,這里還需了解對應的產品配套如何,即思考其他的產品資源,能否為我們后期業務的發展而服務。

如接入視頻直播服務時,關注美顏、轉碼、連麥聊天等配套功能,考慮在未來的發展中是否有可能應用上。這既能幫助我們在對未來的規劃思考上,拓寬思維,又能進一步判斷對方的服務能力和業務成熟度。

3. 初步方案

確定好對接哪家第三方后,我們需要給出初步的方案與服務商進行溝通,確認可以實現后,再進行具體的設計。

這就需要我們先了解,本次需求背后的核心問題是什么,通過識別業務核心,找到簡單快速的解法,了解優先級和緊急程度后,給出自己的最小方案。并結合自身系統的簡單介紹和業務背景說明,讓服務商更好的判斷自身產品或服務能否滿足。

方案中為了更好的闡述需要實現的業務需求,可配合簡要流程圖進行說明,同時確認會在哪些環節用到什么接口。這一步因為涉及到雙方系統的實現,我們需要邀請本司技術人員,共同參與前期的調研評審,探討接入方式與可行性。

1)注意事項

1.關于第三方服務商

我們需要確定對方的業務對接人和技術對接人,以便在產生對接疑問時,可以快速找到負責人,溝通并解決問題。

在具體設計之前,一定要先通過電話或者QQ等方式,對話確認自身的業務需求能否滿足,避免在開發人員進行對接的過程中,才發現無法很好實現,那么一切的努力都將成為白費。

進行業務方案的可行性確認前,你還可以先問下對方的典型案例和場景是什么樣的,通過了解不同的業務需求,還能幫助你拓展思維,思考后期的需求。

在對接較為復雜,或者溝通不清楚時,可聯系上門演示,縮短溝通周期。

2.關于業務定制方

這里說的業務定制方,指的是定制項目或SaaS軟件的業務方。當幫他們實現新服務需求時,請務必提前了解并確定對方想要實現的業務范圍,同時每次的溝通結果都做留檔確認,避免在前期的業務需求確認上,出現不必要的異議。

階段二:設計中

初步方案通過后,我們就要做具體的產品設計了,這里簡單聊下,設計時應該注意的4個小點:

1. 接入第三方的業務流程梳理

為了避免復雜的開發,并降低溝通成本,可在流程圖中注明與三方的接口動作,在哪些環節做什么判斷。同時還有異常情況的處理方式,比如在對接第三方支付中,支付失敗有哪些原因,拿到不同的結果該怎么處理,等等。

2. 新業務對原業務的影響

新服務接入到業務系統后,需確定并說明是否為默認開通,且不開通時,是否要對原業務做設計調整,和對舊數據進行處理。

3. 設計上對C端用戶的無差異感知

如無必要,無需讓用戶直接感受到產品加入的第三方。

依舊以上述的三方支付項目為例,當時我們有個環節是,個人分銷商要進行傭金提現,需要在成為分銷商前,就在三方賬戶體系中進行賬戶新建,即會要求個人提前在前端產品進行認證簽約。

此時,我們無需讓用戶在簽約過程中,直接感知第三方的賬戶資料建立(簽約協議中會有說明),只需在后臺直接讓三方的虛擬賬戶體系,映射平臺賬戶,一一對應,用戶無感,也減少認知負擔。

4. 接口文檔上的數據項是否有遺漏

接口文檔的作用,就是讓我們知道,在哪個環節需要提供哪些內容給對方,對方才可以有效的處理并返回給我們需要的結果。

比如在后臺實現在線下單的功能,就只需要我們傳給對方,收寄件人的姓名手機和地址信息即可,然后對方再返回快遞單號。

仔細看接口文檔,除了避免遺漏必填項外,還要留意各個環節的選填項是否要在本次設計中加入。比如,在后臺在線下單時,可考慮是否讓用戶可以選擇通知快遞員上門攬件。

5. 注意事項

在完全實現業務需求之前,我們往往先采取最小可行性方案,即先跑通核心業務為主。在第一次對接時,最好邏輯不要過于復雜,如果開發評審后,評估的研發周期較長,你就需要反思下,自己是不是一次性做的需求太多了。

同時,完整的設計方案產出后,在進行開發之前,還應與業務方再次溝通,并輸出最終業務流程圖進行確認。

階段三:上線后

測試完成,上線之后,我們還要做兩件事:

1. 風控與三方能力評估

上線后對三方服務的風控依舊不能松懈,由于第三方是我們無法把控的部分,因此我們不能確定上線后是否會出現什么問題,所以在必要時,要能做到即時關閉該服務。

同時,還需要在運行一段時間后,對三方的穩定性和拓展性兩方面進行評估,若沒達到要求,則需要考慮后期是否更換服務商。

2. 項目復盤

項目復盤,即反思從項目開始到正式上線,自己做了什么事情,產品方案的落地效果如何,對已達成的結果和預期成果之間所產生偏差進行評估,是否優于預期,有做錯了什么。通過在反思中獲得進步,進而提高自身的生產效率。

特別是,我們做的產品方案,在評審時如果不是一次過,更要多反思那時修改了什么,在哪方面思考不足,并檢查是否有遺漏的異常流,對其他模塊的影響是否有照顧到,將在復盤過程中發現的待完善內容,列入到接下來的迭代規劃當中。

結語

每次對接新的第三方類型時,我們經常會像面對一個全新的困難一樣,充滿著太多的未知,容易一頭霧水。

但作為一個研究型的職業,產品就是這樣經常要做探索。既然選擇了產品這條路,便只能風雨兼程,讓我們知難而不畏難,在一個又一個的項目中,繼續不斷深入思考、磨煉自己。

 

本文由 @陳星 原創發布于人人都是產品經理,未經作者許可,禁止轉載。

題圖來自Unsplash,基于CC0協議。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 哇!好棒,剛好最近也在接觸對接聚合支付的項目,受益匪淺!感覺作者跟我工作內容和做的產品都好相似啊,不知道能不能加VX再向你取取經~

    回復
  2. 不錯

    回復
  3. 好文章

    回復
  4. 剛剛 v

    回復