APIs 正在吃掉價值鏈

APIs are eating the value chain: Why we’re transitioning to API-first | Segment Blog

要先搞懂什麼是「價值鏈(value chain)」，直接看Wiki是看不懂的。但《決策分析與制定：Value Chain價值鏈》這篇倒是有不錯的範例。

好市多的範例算是很容易理解，但價值鏈本就跟我們的生活息息相關。我們最近常聽到「產地直銷」的農產品，會比較物美價廉，物有沒有比較"美"這比較難說(因為是農產品)，但**「價廉」的原因，就是因為我們繞過了「價值鏈」附加上去的價值**(對我們來說就是成本)。

企業在哪裡產生價值？

在80年代，再怎麼大的企業，都無法負擔「直接面對消費者」的所有成本，包裝，運送，保存，行銷…每一層都是「公司」級的成本。所以當時的市場比較算是水平整合的，大家各司其職，不管是專門包裝產品的公司，專門運送的公司，專門行銷的公司…都能在「為產品增加價值」的鏈上獲利及生存。但過去30年，軟體科技對所有產業都造成了巨大的衝擊。因為這讓任何一家公司，不但有能力直接面對消費者，甚至能以極高的成效擴展自己的服務品質及範圍，獲得整個價值鏈的所有價值，這個「能力」就是API。

企業都有「主要(Primary)活動」及「支援(Support)活動」，主要活動當然就是銷售產品或提供服務，而支援這些主要活動的，就是廠房，物流，研發，人資管理等這些。這些活動上的節點，串連起來為「原物料」加值成為最終的「產品」，就是企業內的價值鏈。每個企業也是唯一能成為整個「價值系統(value system)」的節點的單位，它們連結不同的價值鏈，為最終消費者提供產品。在網路科技普及之前，這些企業因為是水平整合的，所以只會關注價值系統中不同的鏈，鮮少真正關心過最終的顧客體驗。

價值鏈中的「關鍵路徑」

在價值鏈中，以三大類的「加值流程」，最能讓各單位有明顯的差異化，基本上也就是它們的護城河。這些流程就是「原物料輸入」，「處理流程」及「產品分銷」，可視為是價值鏈中的「關鍵路徑(Critical Path)」：

僅管Porter(價值鏈模型提出者)上是將銷售，市場行銷，售後服務等直接面對顧客的活動，視為是主要活動的範圍內，但實際上只有一些像是Nordstrom(百貨公司)，賓士(Mercedes)，四季(Four Seasons)飯店或美國運通(American Express)等的高級品牌的大公司，才有在這些面向做出差異。其他的大公司，會將這些直接面對顧客的活動，視為是價值鏈中的次要活動。而這些公司普遍認為，他們需要將這些活動外包出去，給更專業的公司處理，以最大化他們的獲利。

但隨著網路科技的普及，這條關鍵路徑的形狀，就變得不同了。

數位轉型：軟體正式進入價值鏈

當軟體技術開始以輔助者的角度進入價值鏈後，大多數企業都認為這是一個"不錯"的技術，可以讓他們的次要活動變得更有效率。隨著這類工具的供應商不斷的出現，產品越來越多，這些軟體進入價值鏈的程度越來越深。不過不管是使用這些工具，還是開發這些工具，基本上還是被企業定位為是價值鏈中的次要活動。本來這些工具的開發商，都是要企業適應他們工具的使用方式的，但隨著企業的要求越來越多，開發商漸漸意識到開放API來滿足企業用戶需求，從本來是"最好要有"的程度，已提升到"必須要有"的程度了。因此，開發商開始從開放出來的API來收取費用，以便讓他們能爭取更多做這件事的預算。

「平台」比「流程」更重要：軟體吃掉價值鏈

時至今日，軟體已不再"只"是加速流程的工具而已。隨著與顧客互動的成本趨近於0，公司已有能力大規模的直接接觸顧客。在全網路化的現代世界，軟體已經滲透到每個流程，不論是哪個流程的優勢，都無法再成為競爭優勢，「顧客體驗」才是這個世界唯一的競爭優勢。

企業之間的差異化，本來是體現在「流程」的，但現在已移轉成為體現在「平台」上。因為「要求-回應」的需求模型，比傳統的價值鏈更好用。以B2C的例子來說，「要求-回應」需求模型的具像化，就是像Uber或Instacart這種基於「移動裝置-滿足需求」模式的公司。以B2B的例子來說，就是像AWS, Stripe, Plaid或Twilio這種基於「API優先」模式的公司。尤其是這些訊息流為主的公司，它們都是全數位，完全整合價值鏈中的每一個環節。它們不但都有流暢的網站和App，而且是在全平台，從輸入，處理到輸出端，都是完全數位垂直整合，造就了極佳的顧客體驗的競爭優勢。

App越來越像各種需求情境的輕薄介面，而不是不同品牌的厚重外殼。

以訊息流為主的"物流"，已變成一種極度透薄的體驗，手機，平板，桌機，甚至是伺服器上的App或服務，越來越多是轉向使用HTTP為主的通訊協定。這一切就是因為API的開放，讓整個體驗變得十分有效，通用，也非常具有價值。「需求-回應」模式變成是企業的新「流程」。

新關鍵路徑

演變至此，顧客體驗已變成新的"物流"，而快速學習，迭代及整合，則成為新的"營運"。

在Excel做迴歸分析，來支援庫存估計？現在是支援活動了。

顧客體驗的每一個面向的資料科學分析？現在是主要活動了。

傳統被動的"商業智慧"？現在是支援活動了。

基於機器學習的預測即時的市場供需？現在是主要活動了。

面對終端消費者的公司，想要在顧客體驗做出差異化，它們就必須整合自身的銷售，營銷，及售後服務，這些過去被視為是支援性活動的功能。而且這些部門，必須將與顧客互動過程中取得的經驗及洞見匯流在一起後，以優化顧客體驗的目標去做適度的調整。

對於在這些方面已經做得很好的公司，從內容到產品的推薦，都是基於顧客體驗的即時調整。而這些調整都需要大量的數據，做為「基礎設施」，來迭代優化。

對經營平台，數位聚合內容，原生數位內容營銷，或是API為主的B2B公司來說，上圖的架構一點都不陌生，而且一些傳統的中堅產業也在跟上腳步。這些產業越來越像「需求-回應」的運作模式，因此一些企業用軟體工具也在改變，才能滿足這種模式的需求。

"串流"關鍵路徑：API優先才能適應「需求-回應」的世界

時間來到2000年，隨著網路基礎建設的普及化，軟體的網路化也變得越來越普及。價值鏈中那些支援活動的單位，在使用軟體工具有效的優化作業流程後，公司意識到這些主要領域以外的活動，都可以透過外包來改善流程及利潤率。

這就是第一批「API優先」公司出現的地方，他們透過API顛覆了傳統價值鏈的「管道」概念，將關鍵路徑中所有磨擦降到最低。他們透過軟體技術優化這個體驗，最終他們的軟體技術(也就是API)變成了產品。因此，他們的產品常被用於協助B2C公司，外包價值鏈中非主要領域的活動元件(像是銷售，營銷，售後服務等)的實作，讓這些公司能讓主要的精力能投入焦點領域。

API優先的公司，價值是基於用戶的HTTP需求和回應建構起來的。如果需要一個支付服務的話，只要呼叫Stripe的API，發送需求後等待幾百個微秒，Stripe會處理掉支付的超多複雜實作細節，然後回應服務的結果及所需的服務費用。呼叫API的概念大致上就像這樣：

curl -X POST https://api.twilio.com/2010-04-01/Accounts/ACXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/Messages.json \--data-urlencode "From=+15017122661" \
--data-urlencode "Body=Body" \
--data-urlencode "To=+15017122661" \
-u ACXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:your_auth_token

使用Stripe或Twilio的公司之所以喜歡這樣的產品，除了因為它們處理掉隱藏在API後面那些複雜的實作，也是因為API的設計讓開發者能讓功能區塊切割乾淨，而且非常易於使用。某種程度來說，這似乎給了這些開發者一種超能力。

這些API公司很稱職的解決了這些"操作型"的業務需求，也讓他們從一開始只是滿足「需求-回應」的小公司，聚集許多用戶後演變成為一個巨無霸平台，擴大了他們的任務及服務範圍。像是「支付管理」就變成了「為全球商務賦能」，而「傳送簡訊」就變成了「更好的通訊基礎建設」。透過使用這些API公司的產品，減少了整合功能的巨額成本，也幫助了許多新創公司，降低了進入相關產業的技術門檻。

在「需求-回應」的世界中建立B2B軟體

在「需求-回應」越來越具像化的世界中，要銷售軟體工具給公司企業，認知自己只是整個互聯的體系的一部分，提供模組化的功能是重要關鍵。因為軟體技術不斷的在嵌入各項環節，不斷的驅動「互聯」及「整合」的需求，大家都是基於共同的基礎建設(像是AWS或GCP)，共同的廣告平台(像是Facebook及Google Ads)，在SaaS領域的聰明玩家都是擁抱這些共同性(基礎建設或API)，也交互投資。

現在，企業使用軟體服務是一種「建造及購入」的思維，而安全和隱私性的問題，是一個必然的共同責任。它們使用這些服務網路是由企業內部，個人，或是第三方共同組成的，資料的可移植性就變得非常重要，因為這關係著這些資料及工具，是否能納入他們的管理政策及程序。一般來說，人們會希望是這些軟體工具來適應用戶的使用程序，而不是要求用戶去適應這些軟體工具的使用方式。

最差的使用體驗就是，用戶需要徵求你的同意，才能決定怎麼使用產品

即便你精心打造了最美麗的用戶體驗，你也無法保證你能料想到所有用戶的使用情境。在極端的需求下，若沒有提供足夠的API，用戶就沒有客製的空間。如果有API，用戶就可以自己解決自己的需求，這等於是在"投資"你的生態圈。我曾經參加過一些企業需求的開發會議，當提出一些我們的計劃時，我最常聽到的反饋是：「給我API就是了」。

為什麼會是這樣的反饋？因為*「基礎設施即程式(Infrastructure as Code, IaC)」的觀念早以深植開發者及服務維運者的思維中*。這代表提供基礎設施的一切動作，包括參數設定，甚至是部署App，都是寫程式去控制的。這和過去不同，開發者部署App不只是到實體伺服器或是虛擬機器(Virtual Machine)，現在的部署更包括了以容器(Container)技術為主，和各家服務都相容的雲機器。而這些App不論是部署，或是使用不同的服務來完成支付，通訊，遞送，身份認證等關鍵功能，全都是透過API來完成的。

結語

這篇有一些關於Segment如何透過API優化他們服務的內容，已和觀念無關，因此我沒再特別寫出來。在看完這一切，回到標題「API正在吃掉價值鏈」後，我們可以理解為什麼這一切會發生：

「價值」是用戶體驗決定的，而不是產品的生成過程決定的。

透過API優化及整合了所有流程及服務，滿足了最終的用戶體驗，

「價值鏈」的本身就沒有存在價值了。