您的位置: 首页 > 常识 >

业务系统如何对接第三方服务?

100次浏览     发布时间:2024-08-25 09:49:30    

在产品工作中,我们时常要对接第三方服务。本文作者从过往的对接项目经历中,提炼的关于业务系统,如何对接第三方服务的方法论,希望能对你有所帮助。

随着公司业务的发展,我们有时会遇到,需要在自身业务系统中加入新服务,但不能纯自主开发的情况。

比如会有以下三种:

  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. 项目复盘

项目复盘,即反思从项目开始到正式上线,自己做了什么事情,产品方案的落地效果如何,对已达成的结果和预期成果之间所产生偏差进行评估,是否优于预期,有做错了什么。通过在反思中获得进步,进而提高自身的生产效率。

特别是,我们做的产品方案,在评审时如果不是一次过,更要多反思那时修改了什么,在哪方面思考不足,并检查是否有遗漏的异常流,对其他模块的影响是否有照顾到,将在复盘过程中发现的待完善内容,列入到接下来的迭代规划当中。

结语

每次对接新的第三方类型时,我们经常会像面对一个全新的困难一样,充满着太多的未知,容易一头雾水。

但作为一个研究型的职业,产品就是这样经常要做探索。既然选择了产品这条路,便只能风雨兼程,让我们知难而不畏难,在一个又一个的项目中,继续不断深入思考、磨炼自己。


相关文章