如何高效对接外围系统?

0 评论 4361 浏览 28 收藏 14 分钟

无论是C端还是B端,产品一般都不是孤立存在,而是整个业务流中的一环,所以也少不了和外部系统对接。那么,如何高效对接外围系统呢?本文作者结合自身经验,总结了一些措施,希望能给你带来帮助。

一、每个产品都不是孤立存在

无论是C端还是B端,某一产品一般都不是孤立存在,而是整个业务流中的一环。如果某产品属于起始产品,产生数据后,也会连接下游产品,承接相应业务数据,完成整个业务流转。比如获客系统沉淀的客户信息、来源渠道等,都会流转到下游交易系统,即客户购买商品产生交易单,交易系统的交易信息也会流转到更下游的财务系统,负责单据的核算做账等业务。

当然,理论上也没有严格意义的起始产品,上述案例的获客系统,其上游也会又获客前的广告系统、推广运营活动系统,但某个公司的业务聚焦点是获客后的交易,所以会以此公司主营业务范围作为信息产品的边界。

另外,每个产品的上游和下游系统也不仅仅只有一个,主要是因为业务不是单线流程,而是网状结构,不同业务流交叉形成复杂的业务生态。例如上述案例中的获客系统,除了下游会有交易系统以外,可能还会有专门的会员系统、积分系统等作为下游系统,主要是因为为满足用户需求,背后会有一系列产品为其服务。

既然大多数产品是业务流程中的某一环,那就少不了和外部系统对接,这里包括外部公司系统,如外部银行、微信、支付宝支付渠道接口等,也包括内部公司其他系统。合作项目是否能成功上线、成功推广,除了自己产品开发好,外围系统是否能对接好也是非常重要。那么如何高效对接外围系统呢?笔者通过实践总结以下事半功倍的措施,希望有帮助。

二、防止出错,提前预判

合作类项目跨部门协调沟通,需要有明确的目标、各自负责的范围、互通数据的流程。但很多时候,以上流程是不清晰的,会导致项目进度受阻,或是项目上线后出现问题互相扯皮的情况,所以在项目开始前明确出来就非常重要。

整体流程包括:明确产品目标、梳理业务流程图、明确各自产品负责的范围及产品方案、督促双方开发按进度完成上线、共同建立清晰的运维机制。根据实际工作经验,以下分为两类合作项目介绍,以及容易踩坑点。

第一类:主动找其他部门配合

如果是产品经理自己负责的产品需要其他部门配合,则更像大产品经理,除了负责自己产品以外,更多的是站在整体角度,明确项目目标,带着各方系统一起做。对个人的压力会大一些,因为要对内对外协调很多资源,涉及具体要做什么事儿、需要谁来配合、如果对方不配合怎么办、配合后双方系统的产品范围有重复交叉或是三不管地带怎么办、上线后用户投诉互相甩锅怎么办等等问题。

笔者负责的项目中就有以上类似问题,经过反思后,发现有些经验总结后,大脑就会对下次项目启动风险预判提醒。

1)产品上线前

重点给外围系统对接人阐述项目背景、明确项目目标,督促对方出具产品方案和上线时间。当然,对方是否配合取决于钱和开发资源排期,钱上面就是对方报价是否合理,内部好解决些报工时打卡即可(项目制管理的公司,会将每个开发人员打卡项目来衡量资源配比是否合理),外部则需找采购进行评估。

如果对方报价太高,则积极找相关利益方进行协调,比如换供应商、采购进行沟通调价等。如果对方报价合理,则进入方案确认,开发排期环节。此处需重点注意,尽量细化方案细节,比如正向流程、逆向流程,大概率场景、小概率场景,包括上线后容错机制如何设定,产品设计、开发设计尽量面向未来等,这样多考虑的目的就是避免上线后发现需要重新大改的风险。

2)产品上线后

建立双方运维机制,上线不代表着结束,外围系统人员必须配合一起试点推广、全面推广、日常运维等事宜。比如上线时需要准备什么配置项,遇到问题外围系统人员需找产品、开发还是运维来解决?尤其是异常场景,比如外围系统停机发版时,如何保证双方系统数据准确等事宜。

比如,业务系统某付款单,需推送资金系统进行付款,但因资金系统停机,业务系统并未提前准备,则导致付款单推送失败,用户未在规定时间进行付款,造成客户投诉。此类问题,有几种解决方案,根据大家实际情况可自行选择或延伸思考。

第一种需开发,如果单据量较大,并且系统自动识别报错原因,衡量开发投入产出比较高,则可开发报错提醒功能,如遇到付款单推送失败报错,则邮件提醒技术或产品人员。技术人员看到提醒邮件,则可手工再重推,也可再开发自动重推功能,针对失败单据,如判断是因为停机推送失败则重推。

第二种人为要求,要求外围系统每次停机前必须通知上下游系统进行准备,获取到停机通知后,再通过邮件或工作群通知用户避免停机期间操作系统数据。

第三种技术手工处理,针对单据量不大且不紧急情况,则技术人员获取停机通知的第二天则手工处理,并且要求外围系统避免业务单据量高峰期进行停机发版。

以上案例中只是抛砖引玉,目的是需要大家有意识的考虑多一些,完整流程跑一遍,无论是大概率的业务场景,还是小概率的停机场景,都保证和外围系统对接完整,提前演练就避免生产环境大批量数据错误。

第二类:被动配合其他部门

笔者今年的两个项目就是属于此类,这类项目,其实坑更大。原因是服务的用户不属于自己产品范围,对产品的目标、产品范围边界、产品方案、推广上线等环节,都拿不准,因为服务的用户是财务人员,而我并没有专业的财务知识,则只能依赖财务系统人员。

相信很多业务型产品经理应该理解这种痛,自己产品作为上游业务系统,需要为下游财务做账系统提供业务数据,自己无法针对间接系统的财务用户做调研。如果遇到能力强、好沟通的外围系统对接人还好,自己还能趁此项目多学习多考虑,悲催的就是遇到不好沟通,但是喜欢甩锅的人,这个也在职场上很常见,毕竟每个人都没有帮助别人的义务。

对,我今年的两个项目,其中一个就遇到了类似情况。

外围系统找到我需要我做相应的功能改造,并按照他们要求出方案时,我还是比较懵的。因为我主业是负责好我的业务系统,服务好我的目标业务用户,而非外围的财务用户。所以我就不断问项目目标、项目具体背景、目前现状、需要解决哪些问题、用户需要什么时,这些基础调研的问题,我都没用从外围系统对接人找到答案,即使上线了,也没给我明确的回复。果不其然,上线后遭到财务用户的投诉,究其原因有两方面,一个是业务系统堆积几年的历史数据未处理,另一个是业务系统的细分场景并未被财务提出如何做账,导致方案不完善,数据错乱。

遇到这种问题,根本原因,还是人的原因。如果想不清楚就下手,肯定会有错误风险,开始上线没问题,只是说明业务量不大,后续业务量上来,就会报错。

今年经历了这次事故后,我反思职场中确实会有各种各样的磕磕绊绊,如果只抱怨别人没做好,就停滞不前,确实也对不起自己投入的时间。于是我化被动为主动,想办法绕过外围系统对接人,直接找到外围系统使用的用户、外围系统所在业务的专家、相类似岗位的其他人员、此对接人的领导等等,侧面或正面的反复了解业务背景、明确项目目标,主动和外围系统用户进行沟通确认方案范围、方案细节,涉及历史数据、主流程场景方案、逆向场景或小概率场景方案等,不断迭代优化,而不只是因为自己不熟悉外围系统业务就不再向前。

所以,即使被动配合其他部门的项目,内心也要化被动为主动,积极促进项目进展。

三、避免麻木大意、建立运维响应机制

项目好不容易上线了,此时就皆大欢喜,不再盯着了吗?万万不可,殊不知,项目挺过从0到1,却因为1到N 时栽了大跟头。

就像笔者遇到了一个项目,开发上线推广迭代经历了一年,后面需求逐渐变少,开发维护投入逐渐减少,就不太在意此项目。谁知道,日常运维类项目突然出现了大批量数据问题,究其原因,此类合作方项目,因为上游变动,未衡量变动点对下游的影响,就自行变动,导致下游出错。所以无论是合作方项目对接外围系统,还是自有项目,都需以不变的运维机制对应变化的部分。

那么运维机制是什么呢?如何管理运维人员识别风险呢?

首先,需统一一个官方的项目群,尤其是合作方项目,会拉入上下游系统人员、对应业务人员入群,一有问题就拉小群,导致信息分散,运维人员也抱怨问题太多不集中,无法快速处理。还有的用户除了拉群,还有邮件、报障系统等,问题分散多方,无法集中处理和分析。建立一个唯一的官方项目群,就是目的大家信息拉通,不在鸡同鸭讲。

其次,共享文档非常重要,翻群消息大家都比较头疼,尤其是多业务系统人员和不同公司的不同业务人员的大群,大家只关心自己的那一部分,如果看群消息很难找。所以统一官方群里的官方共享文档就非常重要,统一的问题内容、登记时间、方案回复、截图格式等,都让人快速找到问题和解决方案,也有利于后续产品和运维进行问题分析,有助于产品优化。

然后,定期的培训也非常有必要,如有业务系统变更,运维人员需警惕,快速识别对上下游系统的影响,评估是否需要优化各自系统等等,如优化后,要及时培训用户,提升用户使用系统的效率。

以上就是自己产品对接外围系统的经验,供大家参考。

本文由@元方 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!