编辑导语：产品经理在工作中经常会遇到系统对接的问题，系统对接并不是个简单的事情，要涉及到技术方面的问题，处理不好可能会导致项目延迟；本文作者用自身经验详细分析了系统对接的流程和经验。

做过B端业务的同学都知道，我们在工作中难免会遇到系统之间的对接问题。为此，我们不仅需要了解对方系统所能提供的内容，还需要知道双方之间可以交互的节点。

对接的顺畅，可以大大提升自己系统的扩展性；对接的不畅，步步是坑事倍功半。

最近自己刚好正在对接一个ERP系统，规模在国内算是比较大的那种。切记，请不要相信对方提供的所谓开发文档，关键时刻还是要靠人对人的沟通。

如果你也准备做系统间的对接，那么我希望下面这些内容能够对你所有帮助。

一、了解对接目的是什么

有些是公司规划需求，有些是客户定制需求，无论哪种类型，我们都需要明确具体的需求是什么。

1. 目前迫切的痛点

如果将需求按优先级来划分，那目前最迫切的痛点问题，自然是我们需要优先关心的。

你可能会说，做目前最迫切的痛点，这是句正确的废话，谁都知道。为什么还要特别说明呢？

因为关于系统对接，为此所涉及到的功能和可能要动用的资源，实在是太多太多。

如果我们不提前规划好需求的优先级，最后的结果往往是什么都做不了。

以我们目前的情况来说，自己系统里的功能就将近10个，要对接的系统中的功能则更多。

在这样的情况下，你要对接哪些功能？具体要怎么对接？这些都是产品经理需要考虑的。

• 首先，我们需要和需求方明确当前阶段最紧急、最迫切的功能。你可以这样考虑，为了保证业务能够走下去，我们至少需要做哪些工作；尽量聚焦在核心业务流程上。
• 其次，在了解到需求方的要求之后，我们自己需要梳理一遍这流程中可能涉及到的关键和数据对接节点；要确保不遗漏、不多余。

举个例子：我们的客户要求首先将订单流程对接跑通，即用户能够下单，然后发货、库存这些信息能够做到同步。

针对上面的情况，如果你仅仅只做订单这一块，那肯定是不行的。

经过仔细的梳理，至少有下面这三大块内容需要考虑：

1. 商品信息：包括商品基本信息、库存信息；
2. 订单信息：包括下单流程、发货流程；
3. 售后信息：包括退款流程、退货流程；

有的放矢，抓大放小，一步一个脚印。

2. 未来可能的需求

所谓的脚踏实地，心向远方，就是这样的状态。我们不仅需要知道当下最重要的事情，还需要知道未来可能的方向。

可能你会问，我们将当下的事情做好、满足需求了，就已经不容易了，哪还有时间和精力去考虑其他。

话是这样说没错，但如果真的这样，那以后产品的升级，也许将难上加难。

了解需求方未来可能的潜在需求，无论是对自己产品的规划和功能的迭代，都有着重要的指导作用。

首先，通过对潜在需求的了解和分析，来判断未来的发展趋势和我们自己的规划是否相符。

如果相符，我们可以考虑怎样更好的进行融合；如果不相符，我们可以考虑是调整自己的方向还是放弃未来的可能。

其次，通过对需求的深挖和抽象，对我们自己的产品规划有参考价值；多种选择、多种方向，也许能为我们提供新的视野和方向。

以我们这次的对接来说，通过这次实践，对于我们自己以后的微服务有着很好的借鉴意义，也为我们以后的方向找到了一个可能的机会点。

未来的不可知，需要我们多思路、多角度思考问题。

二、明确对方能提供什么

俗话说，知己知彼才能百战百胜，放在我们这里，那就是知己知彼才能更好的对接融合。在开始对接前，首先要做的，就是要了解对方能够提供什么。

1. 自己先了解概况

想了解对方能提供什么，最直接也是最有效的方式就是自己去体验、去了解。

在这里，我们要感谢这个时代。现在大部分的互联网产品，都会有官网介绍和产品体验，有些产品还可以进行试用甚至免费使用。

这就为我们了解第一手资料提供了很多便利，尽可能多的获取对方的资料。

当然，也是需要有重点的：

1. 搞清楚对方主要提供哪些功能；
2. 搞清楚对方是否能够提供标准的API接口；
3. 搞清楚对方能否进行针对性开发等等。

如果对方有API接口和文档，那将能够大大的提升我们对接的效率。毕竟能够提供标准接口的，大部分都是经过验证可行的。

如果我们的需求，超出了对方的标准范围，能够针对性的提供功能开发，具体费用如何，这些我们最好也要提前了解和准备，为后续的方案沟通做准备。

以上，是我们自己作为需求方，需要去了解的内容。

如果需求来源是我们的客户，那我们就可以通过与客户的沟通，深入了解对方系统的功能。

而且，在这种情况下，我们还可以进入客户的账号，亲自体验对方产品的操作流程和逻辑，梳理页面字段和内容，针对性整理汇总。

通过以上两种方式，先形成自己的初步印象。

2. 有针对性的进行沟通

当我们自己首先了解到对方系统大致的内容后，我们就需要结合自己前期了解到的需求，有针对性的整理出可能存在的问题，切勿漫无目的的去了解。

当我们有了自己的初步判断后，紧接着就需要进行进一步的确认核实。毕竟，我们所体验到的，未必就是正确的。

这时候，我们就可以直接联系对方，而且尽可能联系到相关部门，有时候400电话客服，并不能解决我们的对接需求，打过电话的人都懂。

联系到关键人之后，针对之前我们整理的问题，进行有效沟通，尽量避免谈一些大而空的内容，这是我个人的建议，毕竟大家的时间都很宝贵，直奔主题比较好。

也千万不要问百度能搜索到答案的问题，将时间留给最有用、最核心的关键点。

以我们自己为例，在明确了客户需要对接的需求后，我们初步整理出需要的商品、订单、售后三大模块；然后针对这三大模块的对接问题，进行深入的沟通。

在此基础上，我们还了解到如果想进行这三方面的对接，第一步则是需要我们拿到客户的授权，而获得授权的方式和资料，也需要额外准备。

通过上面的例子你会发现，看似简单的对接流程，其实背后的相关操作逻辑有很多。

有时候，我们仅仅通过产品是无法感知的，必须在此基础上，进行针对性沟通。

查缺补漏，才能万无一失。

三、知道自己能对接什么

明确了对方能提供什么，接下来要做的就是知道自己能做什么、不能做什么；为了完成有效对接，我们又需要额外准备些什么。

1. 自己需要做哪些准备

通过前面两步，现在我们不仅了解到需求是什么，而且还了解到对方能提供什么，那么接下来要做的就是我们自己要准备些什么。

我们不仅要梳理出双方整体的框架流程，还需要明确两个系统之间的数据交互。

在什么时间节点，我们需要将信息推送给对方；对方进行了什么操作，会将信息推送给我们，这是我们必须要搞清楚的。

数据传递过程中的API接口、消息推送机制，作为产品经理，我们需要提前做好预判，否则在后续开发过程中，会遇到各种问题。

与此同时，我们还需要知道，为了满足这些需求，我们自己的平台是否需要做相应的调整。

如果调整，会涉及哪些模块，会影响哪些功能，对现有功能是否造成影响，是做成公共模块还是定制模块。

如果不调整，能否快速的满足现有这些需求，能否顺利的完成对接。

以上这些，我们都需要事先定义好。

以我们为例，为了完成这次对接，需要在创建商品、创建订单、取消订单、申请售后等相关地方，都需要做开发判断。涉及到的相关接口，都需要进行数据推送和消息反馈读取。

不打无准备之仗，将问题提前暴露。

2. 整体到细节一个都不能少

我们不仅要从宏观层面了解整体流程，紧接着具体到每个功能，我们也需要尽可能的细分。

• 宏观层面：帮助我们概括思路和梳理流程；
• 细节落地：推进开发具体执行。

很多时候，我们看大流程、大思路都没有问题，可一旦深入到细节，才会发现步步是坑，寸步难行。

作为产品经理，我们不能让问题在开发阶段暴露，我们需要提前告知并梳理。

这样做，不仅是为了帮助我们自己理清思路，也是帮助整个对接过程更好的开展。

我们要做的，就是耐下心来，一个流程、一个页面、一个字段的梳理，最好是对照着API文档来看，尽量做到不遗漏。

以我们目前遇到的情况来举例，在做整体规划的时候，关于售后流程，只简单的提了一嘴，流程上也只是轻描淡写的画了。

可谁曾想，就是因为这个疏忽，导致了开发在评估时轻视了，造成实际开发周期延长了1天左右，因为这其中涉及到的点实在太多了。

简单的售后流程，双方的数据交互就有如此之多。

所以，在力所能及的范围内，尽量细化每一个关键节点和内容。

四、看到未来能产生什么

最后我还想说一下此次系统对接，对于我们自己产品的一些启发。

很长时间内，我们自己关于不同系统之间的数据交互，都是通过所谓的后端代码写死来实现的；这样的好处是开发简单、快速上线。

可随着系统功能越来越多、数据量越来越大、流程越来越复杂，导致了现在改动任意一个小点，都极其繁琐。

要么是这里不支持，要么就是那里耦合太强，以至于现在想加新功能越来越难。而且如果一个系统出问题，其他系统也都无法正常使用。

正当技术部门为此头疼的时候，通过此次对接，为我们自己提供了另一种思路。

不同系统之间，其实可以通过接口的方式进行调用，每个系统保持相对独立。

这样一来，即能够实现各自运行，又能够保证互联互通。

正所谓，山穷水尽疑无路，柳暗花明又一村。

作者：明天上线  微信公众号：明天上线

本文由 @明天上线 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议