軟體系統開發顧問：https://consult.revtel.tech/

技術爆發的今天，系統開發很難從頭到尾都自己完成。在自家系統中整合第三方是蠻常見的情況。但如果不小心誤解了任務範圍，悲劇也就常常隨之而來(參見功能的厚度？ — 從社群登入及推播說起)。

一個有趣的問題是，所謂的系統整合跟介接到底是什麼？又應該要怎麼做呢？

爆單造成的悲劇 — ERP 系統癱瘓造成的營運困難

首先先分享個身邊的例子。

電商接單跳脫了實體販售的一些限制，並能很好的跟線上行銷做結合。在疫情加速其發展的情況下，在我們的生活中越來越普及。

出來做生意總是希望接單接到手抽筋，但訂單越多真的是好事嗎？

最近有個夥伴與我們合作開發了其專屬的電商，在高度客製的情況下確實解決以往營運有上班時間限制及無法累積會員的困境，且在不斷累積訂單量的情況下也很好的將數據沈澱為更細緻的服務打下基礎。

前些日子他們發起了一個檔期活動，在前端獲客及接單開出紅盤的同時，後端的 ERP 卻因瞬間大流量而出問題。雪上加霜的是由於檔期剛好在禮拜五，出事的 ERP 在整個週末都停擺，這使得預備要接單的工廠也因而停止生產。

其實 ERP 在活動前已經進行軟硬體升級，但可能因為架構緣故而並沒有收效。作為前端的我們能做的十分有限，大概也就是協助整理清單以待後續處理。

這個案例的後面有個好玩的問題，看似單純的拋單介接真的有那麼簡單嗎？

系統介接其實包含了風險交接

返回本質來思考，系統介接的目的就在於分工分責。

分工分責可能來自以下幾種原因：

1. 專業考量：藉由串接將不擅長或無法執行的部分外發出去，如金流服務
2. 成本考量：藉由串接以低成本取得高品質服務，如雲端資料庫
3. 資訊獲取：藉由串接取得系統不具備之資訊，如第三方登入
4. 資源配置考量：藉由串接使降低開發風險，如使用一些套裝之 SDK

但凡事總有兩面，除了得到一些益處之外，其實我們也將可控性交了出去並且引入了不確定的風險。

舉例來說，如果您的系統支援 FB login，就會發現在維運時常常需要在後台因應條款改變，否則系統就會在沒有改動的情況下無法使用。這就是典型將外在變動納入原生系統內的一個案例。

仔細做好風險排查才是真正的任務核心

所以我們該怎麼辦？我想重點在於建構起一個認知體系來封裝這些被引入的不確定性。

1. 系統串接的範圍不只是機械性的結合，還必須包含風險排除
2. 規劃如何串接任務時，不要只拘泥在既有文件及範例，應該要一併將商務邏輯、錯誤擴散範圍等納入需要理解的清單。

妥善的計畫永遠是避免失敗的第一步，要切記

• 針對需求訂定合理的時程，這其中應該包含測試及部分導入驗證
• 規劃本身需要思考資源配置，要小心短板效應帶來的可能差錯
• 理解目前系統現況，盡可能準備備案以免過度聚焦而忽略大局

而對於整體的風險評估也要完整，盡量避免低估的情形發生

• 確實理解業務風險：對於任務失敗的成本能確實掌握
• 確實理解工程風險：要注意預期調動的資源（如工程師素質）及接入系統的穩定性
• 確實理解營運風險：對於結合完畢之後的後續規劃要有完整的評估

最後提一個很常被忽視但卻往往是決定成敗的關鍵點 — 人。比如在前面舉的例子中，說到底是否能夠掌握 ERP 廠商的配合積極度大概決定了善後及後續改善的絕大部分。

系統整合時請把以下三種角色納入考慮：

1. 終端用戶：如果出問題了，對於用戶的衝擊到底是什麼？
2. 內部關係：整體任務在我們組織內部是什麼？是否存在政治因素？
3. 外部關係：串接對口的整體狀況是什麼？他們是否願意協助配合？

結語：不要把本質問題誤當成技術問題

人月神話一書中提到軟體工程的任務有兩種性質：本質性與附屬性。後者可能會隨著工具改良(如更好的程式語言及 IDE)而逐步改善，但前者才是真正複雜且難以攻克的困難點。

而系統串接亦然，其本身很常同時參雜著這兩種問題。或許在我們一切任務開展之前都順著這兩個大類對子分項做規劃會是個不錯的思路方向。說到底所有事情在最一開始時就不要掉以輕心才是最適當的心態。

真實世界的問題總是比我們想像的更複雜啊！