软体系统开发顾问： https://consult.revtel.tech/

技术爆发的今天，系统开发很难从头到尾都自己完成。在自家系统中整合第三方是蛮常见的情况。但如果不小心误解了任务范围，悲剧也就常常随之而来(参见功能的厚度？ — 从社群登入及推播说起)。

一个有趣的问题是，所谓的系统整合跟介接到底是什么？又应该要怎么做呢？

爆单造成的悲剧— ERP 系统瘫痪造成的营运困难

首先先分享个身边的例子。

电商接单跳脱了实体贩售的一些限制，并能很好的跟线上行销做结合。在疫情加速其发展的情况下，在我们的生活中越来越普及。

出来做生意总是希望接单接到手抽筋，但订单越多真的是好事吗？

最近有个伙伴与我们合作开发了其专属的电商，在高度客制的情况下确实解决以往营运有上班时间限制及无法累积会员的困境，且在不断累积订单量的情况下也很好的将数据沉淀为更细致的服务打下基础。

前些日子他们发起了一个档期活动，在前端获客及接单开出红盘的同时，后端的ERP 却因瞬间大流量而出问题。雪上加霜的是由于档期刚好在礼拜五，出事的ERP 在整个周末都停摆，这使得预备要接单的工厂也因而停止生产。

其实ERP 在活动前已经进行软硬体升级，但可能因为架构缘故而并没有收效。作为前端的我们能做的十分有限，大概也就是协助整理清单以待后续处理。

这个案例的后面有个好玩的问题，看似单纯的抛单介接真的有那么简单吗？

系统介接其实包含了风险交接

返回本质来思考，系统介接的目的就在于分工分责。

分工分责可能来自以下几种原因：

1. 专业考量：藉由串接将不擅长或无法执行的部分外发出去，如金流服务
2. 成本考量：藉由串接以低成本取得高品质服务，如云端资料库
3. 资讯获取：藉由串接取得系统不具备之资讯，如第三方登入
4. 资源配置考量：藉由串接使降低开发风险，如使用一些套装之SDK

但凡事总有两面，除了得到一些益处之外，其实我们也将可控性交了出去并且引入了不确定的风险。

举例来说，如果您的系统支援FB login，就会发现在维运时常常需要在后台因应条款改变，否则系统就会在没有改动的情况下无法使用。这就是典型将外在变动纳入原生系统内的一个案例。

仔细做好风险排查才是真正的任务核心

所以我们该怎么办？我想重点在于建构起一个认知体系来封装这些被引入的不确定性。

1. 系统串接的范围不只是机械性的结合，还必须包含风险排除
2. 规划如何串接任务时，不要只拘泥在既有文件及范例，应该要一并将商务逻辑、错误扩散范围等纳入需要理解的清单。

妥善的计画永远是避免失败的第一步，要切记

• 针对需求订定合理的时程，这其中应该包含测试及部分导入验证
• 规划本身需要思考资源配置，要小心短板效应带来的可能差错
• 理解目前系统现况，尽可能准备备案以免过度聚焦而忽略大局

而对于整体的风险评估也要完整，尽量避免低估的情形发生

• 确实理解业务风险：对于任务失败的成本能确实掌握
• 确实理解工程风险：要注意预期调动的资源（如工程师素质）及接入系统的稳定性
• 确实理解营运风险：对于结合完毕之后的后续规划要有完整的评估

最后提一个很常被忽视但却往往是决定成败的关键点— 人。比如在前面举的例子中，说到底是否能够掌握ERP 厂商的配合积极度大概决定了善后及后续改善的绝大部分。

系统整合时请把以下三种角色纳入考虑：

1. 终端用户：如果出问题了，对于用户的冲击到底是什么？
2. 内部关系：整体任务在我们组织内部是什么？是否存在政治因素？
3. 外部关系：串接对口的整体状况是什么？他们是否愿意协助配合？

结语：不要把本质问题误当成技术问题

人月神话一书中提到软体工程的任务有两种性质：本质性与附属性。后者可能会随着工具改良(如更好的程式语言及IDE)而逐步改善，但前者才是真正复杂且难以攻克的困难点。

而系统串接亦然，其本身很常同时参杂着这两种问题。或许在我们一切任务开展之前都顺着这两个大类对子分项做规划会是个不错的思路方向。说到底所有事情在最一开始时就不要掉以轻心才是最适当的心态。

真实世界的问题总是比我们想像的更复杂啊！