老闆須知的數位發展觀念：企業資源的數位化整合
API 不只是 API！
本篇談 API（Application Programming Interface）是以常用的 HTTP / HTTPS 為協定的 API 為說明範圍，然而實際上定義不只於此，本篇不多贅述。
大多在數位領域的從事者，對 API 這個詞彙不會陌生，然而其中包括軟體工程師在內的多數人，對 API 的理解僅於：
「某方所完成的功能模塊。透過介面針對特定資源請求送出後，會完成相應任務並回應結果。通常這些介面會實作特定資源的新增、讀取、修改、刪除等功能。」
從工程師的角度來看，上述完全正確。但若我們切換視角，把自己當作組織決策者；從整體產品策略、企業營運，甚至是數位發展規劃等角度來切入時，設計 API 將不再單純只是從需求功能面上，就可以把規劃安排妥善的。為了好好談 API 在數位發展上各層面所能展現的模樣，我們得先談談企業資源。
#1 ERP 到底在做什麼？
ERP 全稱 Enterprise Resource Planning，企業資源規劃，旨在服務三件事：
- 企業資源的數位化整合：歸納企業內部各種資料，透過特定介面整合為企業資源群。目的為使企業資源一體可視，便於調用、規劃企業資源發展策略與評估營運成本。
- 最佳化營運流程：設計各種業務的最佳營運流程，並對相應的企業資源群依序進行操作。目的為提高營運效率，降低風險。
- 提供市場洞見協助因應變化：目的為使企業得以透過營運數據察覺市場變化，以便做出相應的快速應對。
#2 常見的 ERP 迷思
- 誤以為 ERP 就是一套得把內部所有報表、業務管理功能塞在一起的整合管理系統。
- 誤以為可以直接拿套裝軟體系統來處理 ERP 議題。
- 誤以為 ERP 是常態穩定的，而忽略動態地整合企業發展而產生的新資源。
先說明什麼是企業資源。舉凡營運上需要被管理者：具有成本、發展價值、能夠反映市場等，就該被視為資源。舉例：
比較直覺的像是：員工、合作夥伴、服務廠商、商品、門市。
比較容易忽略的像是：部落格文章、社群行銷文案、圖片與影片、以及第三方服務上所建立的資源，比方網站流量數據、第三方 CRM 服務所建立的資料。
而過去常見的各種大型 ERP 系統，純粹是開發 ERP 的廠商認為企業普遍都以什麼方式看待資源，以及應如何管理最有效。而在應用服務的發展越趨多元、疊代快速、高度相互串連、微服務設計模式興起的當下，使得傳統 ERP 系統的設計面臨到許多困難。
#3 何謂企業資源的數位化整合？
一個常被忽略的觀念：資料本身，除了理解資料產生方式的人以外，擺在其他人的眼前都毫無意義。資料若要有意義，是設計者透過一系列的研究方法、呈現方法或演算法，來賦予資料被詮釋、表述意涵與以正確方式改變資料自身狀態的能力。
舉例來說：大家都有去過那種菜單品項多、又設計得很複雜的餐廳，我們得要將整份菜單翻來覆去看錯個幾次，才慢慢開始有辦法用「菜單設計者的邏輯」來理解菜單，並順利完成點餐。
軟體領域的設計習慣，會將「資料本身」及「對資料進行操作而生的相應行為」，透過撰寫演算法將兩者封裝，藉此確保資料狀態的穩定一致；更為完整的設計，會將此封裝進一步實現成「資源」：將演算法打包進 API，透過訪問權限管理機制 (常見為 OAuth) 使其成為獨立應用，讓外部、第三方服務得以調用。
而 ERP 的 ER 若以 API 來實現，將線上線下的 ER 逐一落地設計、封裝，建立出以統一介面表述的企業資源應用服務群後，才算是真正達到了數位化整合，更準確說，是「企業資源的數位化整合」：因為當實現了企業資源的 API，只完成了資料及其行為的整合，尚未於應用前端，針對企業各種業務設計出最佳的企業資源調用流程。
簡單的例子：員工因故需要請假。登入系統，設定請假時間送出後，會觸發一系列的企業資源行為與步驟。可能包括：
- 調用「該員工年度請假列表」，依據員工假別額度作檢查；
- 員工新增「請假申請單」，狀態為申請中；
- 主管新增「訊息通知」，狀態為尚未閱讀，提示主管有一請假申請單被提交。
上述三者分開來看，都是各別企業資源的調用，而整個行為串起來就是「員工請假」的最佳化營運流程。
傳統 ERP 系統的架構方式，大多專注於處理「最佳化營運流程」。而無心或有意地跳過「企業資源數位化整合」，透過以使用資料庫存取介面的方式，直接調用操作資料。跳過的原因大多是：開發 ERP 的廠商在成本考量、沒有授權、或者單純就是忽視了，沒引導客戶架設企業資源應用基礎架構。雖然有些客戶有工程師負責開發應用服務，也在開發應用服務時，順帶撰寫了資料行為封裝演算法；但它只運行在公司自己的應用服務上，ERP 無法直接使用。而為了讓這些應用服務營運資料也能在 ERP 上呈現與操作，超級危險的便宜行事就發生了：繞過封裝演算法對資料行為的約束，直接存取資料庫。輕則，解讀資料的邏輯與封裝演算法不一致，資料呈現異常導致錯讀；重則，操作資料的行為與封裝演算法不同，導致營運資料損毀。
正確的做法，得將所有線上線下的企業資源操作，透過唯一發佈的封裝演算法管理，並把它實現為 API 將其應用服務化，發佈於一整合介面上使其一體可視，便於調用、規劃企業資源發展策略與評估營運成本。做完這些，才稱為完成「企業資源的數位化整合」。
在應用服務高度相互串連的現在，具有開發團隊、經營應用服務的企業，或多或少都會串接第三方提供的 API。如果能做到：
- 符合企業的服務價值論述；
- 加快階段性應用開發完成的速度、更早投入市場；
- 服務提供的品質更好、更安全，沒有資源管理上的疑慮；
整體付出的成本更少。
那麼為什麼不用別人的？無論是企業內部管理系統、還是給市場的應用服務，開發團隊得以把所有精力專注在開發應用所要提供的價值論述，其餘需要的局部功能，已經有更完整、更安全穩定、更低廉成本的解決方案時，就不需要請自己的工程師花時間開發。或者：
“Do what you do best, outsource the rest.”
– Peter Ferdinand Drucker
這是以 API 服務使用者所描述的情境。然而聰明的業主同時會想到：「如果我也有辦法把我提供的服務包裝成 API 產品，提供給其他的客戶進行串接，這樣除了在我自己平台上的既有用戶可以使用之外，我還有辦法讓其他合作夥伴、潛在客戶所擁有的平台也串接我的服務。」
當完成了「企業資源的數位化整合」，除了得以透過 API 發展自己的應用服務之外，與合作夥伴業務相關、或具備產品化潛力的企業資源，也能在這樣的開發模式下，得以經過適當的包裝發佈為新的對外服務或 API 產品。若省略了企業資源整合階段，就直接包裝 API 產品供外部使用，相當於在資源策略模糊、營運成本未知的情況下就將資源產品化了。這樣會有什麼風險就不必多講了吧？
