SAP新API政策惹眾怒：用戶 Innovation 被"白名單"卡死

「每一個(gè)功能模塊都是API，但現(xiàn)在沒人知道哪些能用。」德國用戶組織DSAG董事會主席Jens Hungershausen這句話，道出了歐洲制造業(yè)巨頭們的集體焦慮。

SAP上周發(fā)布的新API政策，把「設(shè)計(jì)意圖」變成了懸在開發(fā)者頭上的達(dá)摩克利斯之劍。用戶只能在「SAP認(rèn)可的架構(gòu)、數(shù)據(jù)服務(wù)或服務(wù)特定路徑的限制范圍內(nèi)」使用API——而那個(gè)所謂的API Hub白名單，被吐槽管理混亂、更新滯后。

這不是技術(shù)文檔的措辭之爭。DSAG代表的德奧瑞三國用戶，涵蓋了歐洲制造業(yè)的相當(dāng)體量。當(dāng)API調(diào)用權(quán)限從「默認(rèn)可用」變成「申請制」，創(chuàng)新成本被重新定價(jià)了。

一、政策核心：從「開放調(diào)用」到「白名單準(zhǔn)入」

SAP的新政策PDF文件明確劃定了邊界：開發(fā)者必須依賴API Hub里列出的「批準(zhǔn)接口」。過去，用戶基于SAP系統(tǒng)自建方案時(shí)，可以調(diào)用內(nèi)部功能模塊自由組合——Hungershausen說的「你自己的開發(fā)、你自己的程序、你自己的寫法」，現(xiàn)在需要逐一對照白名單。

關(guān)鍵變化在于權(quán)限的反轉(zhuǎn)。以前是「未被禁止即可用」，現(xiàn)在是「未被列入即不可用」。SAP保留了兩項(xiàng)權(quán)力：隨時(shí)在API Hub發(fā)布新接口，也隨時(shí)撤銷已有接口的白名單資格。

這種單向控制權(quán)讓用戶側(cè)的不確定性急劇上升。Hungershausen的批評很直接：「不清楚哪些API允許使用、哪些不允許，給客戶和合作伙伴制造了巨大的不確定性。」

二、DSAG的三層擔(dān)憂：創(chuàng)新凍結(jié)、AI受阻、合規(guī)風(fēng)險(xiǎn)

德國用戶組織的聲明（本周以德語發(fā)布）梳理了具體痛點(diǎn)。第一層是項(xiàng)目啟動 paralysis——當(dāng)API權(quán)限處于灰色地帶，企業(yè)IT部門傾向于「先不動」，而非「先試錯(cuò)」。Hungershausen的判斷是：「如果你不確定，很可能什么都不做，這是創(chuàng)新無法推進(jìn)的風(fēng)險(xiǎn)。」

第二層沖擊指向AI集成。越來越多企業(yè)嘗試將AI工具接入ERP系統(tǒng)做數(shù)據(jù)分析或流程自動化，而這些連接往往依賴非標(biāo)準(zhǔn)化的API調(diào)用。政策模糊地帶讓這類實(shí)驗(yàn)性項(xiàng)目直接面臨合規(guī)質(zhì)疑。

第三層是合作伙伴生態(tài)的連鎖反應(yīng)。SAP的實(shí)施伙伴、ISV（獨(dú)立軟件開發(fā)商）需要為客戶承諾交付周期，但API白名單的變動權(quán)完全在SAP手中，合同風(fēng)險(xiǎn)難以評估。

DSAG的應(yīng)對動作很務(wù)實(shí)：除了發(fā)布批評聲明，還承諾制作自己的FAQ文檔，與SAP的官方版本并列——這相當(dāng)于用戶組織被迫承擔(dān)「政策翻譯」的額外成本。

三、SAP的回應(yīng)：安全敘事 vs. 用戶體感

面對第三方合作伙伴的批評，SAP發(fā)言人的聲明給出了另一套框架：「SAP已宣布更新數(shù)據(jù)訪問和API政策，以支持共享企業(yè)平臺的安全、可靠和公平使用，因?yàn)樽詣踊虯I驅(qū)動的訪問持續(xù)增長。」

回應(yīng)中的四個(gè)關(guān)鍵詞——安全、可靠、公平、行業(yè)標(biāo)準(zhǔn)云實(shí)踐——試圖把爭議重新定義為「技術(shù)治理升級」。SAP強(qiáng)調(diào)「未改變客戶數(shù)據(jù)所有權(quán)」，并聲稱更新「澄清了SAP接口的設(shè)計(jì)意圖使用」。

但「澄清」恰恰是爭議焦點(diǎn)。用戶組織的核心抱怨不是政策太嚴(yán)，而是邊界不清。SAP說「提供支持的集成模式指導(dǎo)」，DSAG的反饋是「不知道哪些模式真的被支持」。同一套話術(shù)，兩邊解讀出完全不同的執(zhí)行風(fēng)險(xiǎn)。

四、制造業(yè)的特殊困境：ERP深度綁定下的議價(jià)弱勢

DSAG的地理覆蓋（德國、奧地利、瑞士）不是偶然。這三個(gè)國家的制造業(yè)密度極高，而SAP的ERP系統(tǒng)在這些企業(yè)中往往經(jīng)歷了20-30年的深度定制積累。

這種歷史包袱造就了特殊的鎖定效應(yīng)。Hungershausen提到的「過去你自己的開發(fā)」——大量基于內(nèi)部API的遺留系統(tǒng)——現(xiàn)在突然被重新定義為「可能不合規(guī)」。遷移成本極高，但繼續(xù)維護(hù)又面臨政策風(fēng)險(xiǎn)。

制造業(yè)的IT預(yù)算特征加劇了矛盾。相比互聯(lián)網(wǎng)公司的敏捷迭代，傳統(tǒng)制造企業(yè)的ERP項(xiàng)目周期以年為單位，API政策的模糊性直接放大長期投資的不確定性。一個(gè)可能被撤銷白名單的接口，足以讓CFO否決整個(gè)數(shù)字化轉(zhuǎn)型預(yù)算。

五、行業(yè)參照：云廠商的API治理邊界在哪

SAP的「API Hub」模式并非孤例。AWS、Azure、Google Cloud都有服務(wù)目錄和推薦集成路徑，但差異在于默認(rèn)權(quán)限的設(shè)定。主流云廠商的API策略通常是「全量開放+分級支持」——所有接口可用，但非推薦路徑不承諾SLA、不提供技術(shù)支持。

SAP的新政策更接近「許可制」：未列入Hub的接口，使用本身即構(gòu)成違規(guī)風(fēng)險(xiǎn)。這種設(shè)計(jì)在企業(yè)軟件領(lǐng)域相對少見，通常只出現(xiàn)在高度監(jiān)管行業(yè)（如金融核心系統(tǒng)）或SaaS產(chǎn)品的嚴(yán)格多租戶隔離場景。

用戶組織的抗議本質(zhì)上是對「企業(yè)軟件云化」過程中權(quán)力再分配的抵抗。當(dāng)本地部署時(shí)代的「買斷+定制」模式轉(zhuǎn)向云訂閱，SAP試圖通過API治理重新掌握系統(tǒng)擴(kuò)展的定義權(quán)——而用戶希望保留的是「我的系統(tǒng)我做主」的慣性。

六、待解的張力：平臺控制與生態(tài)活力的平衡

DSAG承諾發(fā)布的FAQ文檔，暴露了當(dāng)前溝通機(jī)制的失效。用戶組織需要自行「翻譯」廠商政策，說明官方文檔的解釋力不足。這種信息不對稱在B2B軟件領(lǐng)域并不罕見，但SAP作為歐洲市值最高的科技公司之一，其政策溝通質(zhì)量受到更高期待。

Hungershausen的警告指向一個(gè)長期風(fēng)險(xiǎn)：如果不確定性持續(xù)，用戶可能系統(tǒng)性回避與SAP系統(tǒng)的深度集成創(chuàng)新。這對SAP自身的AI戰(zhàn)略也是反噬——其推出的AI助手Joule等新產(chǎn)品，恰恰需要廣泛的第三方數(shù)據(jù)連接才能體現(xiàn)價(jià)值。

平臺控制與生態(tài)活力之間的張力，在此刻變得具體而尖銳。SAP需要證明，API白名單不是收縮生態(tài)的前奏，而是有序擴(kuò)展的基礎(chǔ)設(shè)施。目前用戶端的體感，顯然與此敘事存在落差。

SAP尚未對DSAG的最新批評作出直接回應(yīng)。The Register的置評請求處于待回復(fù)狀態(tài)。用戶組織與廠商之間的這輪博弈，會如何重塑企業(yè)軟件的API治理慣例？當(dāng)「設(shè)計(jì)意圖」成為法律文本中的關(guān)鍵詞，開發(fā)者的創(chuàng)新空間是被保護(hù)還是被壓縮——你的團(tuán)隊(duì)遇到過類似的平臺政策困境嗎？