這個星期，我在柏林參加了SAP TechEd大會。

這是一場面向企業(yè)級應用的開發(fā)者活動，但AI毫無疑問是"最靚的仔"，無論是SAP發(fā)言人的主題演講、產(chǎn)品演示，還是交流互動環(huán)節(jié)，均圍繞這一主題展開。畢竟主講人不講，臺下聽眾也會問。

Day 1主題演講結束后，SAP執(zhí)行董事會成員Muhammad Alam、SAP業(yè)務技術云總裁Michael Ameling和SAP CTO Philipp Herzig接受了全球媒體的提問。

我借這個機會，提出了企業(yè)AI落地中一個頗為常見的問題：許多企業(yè)CEO對AI轉型高度關注，希望快速見到成效，但技術團隊在實施過程中往往面臨諸多挑戰(zhàn)，難以達成目標，SAP如何看待這一問題。

Alam說，他們觀察到一種非常常見的現(xiàn)象是，很多組織為了應對AI變革，會建立專門的AI團隊，設專職人員推動AI項目。然而這一角色往往與負責數(shù)據(jù)戰(zhàn)略的人員相分離，在大多數(shù)情況下，也與負責應用戰(zhàn)略的團隊各自獨立。

這種組織架構看似美好，卻會導致孤島效應。

我想了一下，確實有道理。因為如果AI團隊、數(shù)據(jù)團隊、應用團隊各自為戰(zhàn)，企業(yè)就要持續(xù)在內(nèi)部 "數(shù)據(jù)搬運"，這一定會導致效率瓶頸。類比一下，GPU集群在訓練模型的時候，也要避免"數(shù)據(jù)搬運"啊。

當然，SAP不僅提出問題，也負責解決問題。

針對企業(yè)AI落地，SAP CEO Christian Klein在今年Sapphire大會上提出了一個 "App（應用） + Data（數(shù)據(jù)） + AI"的業(yè)務飛輪。其中，應用，數(shù)據(jù)，AI，這三者如果在統(tǒng)一架構內(nèi)協(xié)同運作，就會形成一個自我強化的循環(huán)。

用Alam的話說：在AI時代，真正的差異化在于如何為組織創(chuàng)造端到端的業(yè)務價值。這只有在你簡化和創(chuàng)新核心，而不是在IT環(huán)境中增加另一層復雜性時才能實現(xiàn)。

而根據(jù)我在柏林兩天時間里在TechEd上觀察到的SAP技術發(fā)布，核心似乎正是圍繞這一飛輪的構建。從HANA Cloud到Business Data Cloud，從SAP-RPT-1到Joule，所有產(chǎn)品發(fā)布均指向同一目標：消除數(shù)據(jù)、AI、應用之間的割裂。

但在深入細節(jié)之前，有一個概念，值得我們提前探討，那就是ERP。

1、ERP的新角色

因為說到SAP的應用，必然繞不開ERP。所以，當我有機會采訪SAP Business Suite總裁兼首席產(chǎn)品官Manoj Swaminathan時，馬上問了他，ERP是否會有新角色？

他給了一個肯定的答案。具體而言：傳統(tǒng)ERP遵循的是"記錄-發(fā)布-報告"的邏輯，記錄交易、發(fā)布憑證、生成報表。這個模式運轉了幾十年，但本質上是被動的。

但在飛輪的驅動下，ERP的工作方式正在發(fā)生轉變。Manoj用三個詞描述了這種轉變：感知、推理、行動。

系統(tǒng)首先要能感知內(nèi)外部變化，比如匯率波動、利率調(diào)整、通脹趨勢等。然后基于數(shù)據(jù)推理并生成建議。最后在可信的人機協(xié)同中實現(xiàn)自動化行動。

而這恰恰需要飛輪的完整循環(huán)：感知需要數(shù)據(jù)不只是"存在"，還要"可理解"；推理需要AI能真正理解業(yè)務語義；行動需要智能體能跨系統(tǒng)協(xié)調(diào)，但人類始終保持控制。

現(xiàn)在業(yè)內(nèi)有一種觀點，有了模型和數(shù)據(jù)，可能不再需要產(chǎn)品。但Manoj特別強調(diào)：應用依然是企業(yè)的基礎。AI無法在沒有業(yè)務語境的情況下提供真正的智能。

而且他強調(diào)了統(tǒng)一"套件"的價值。企業(yè)若使用不同的系統(tǒng)，整合數(shù)據(jù)時就會丟失業(yè)務語義(Business Semantics)，AI也無法提供有意義的建議。

這句話很關鍵。它也順帶解釋了為什么SAP要強調(diào)"飛輪必須在同一個架構里轉"。不是為了技術上的整潔，是為了保留上下文。

所以，接下來，我們談談SAP的數(shù)據(jù)觀。

2、讓數(shù)據(jù)"活"起來

眾所周知，AI有算法、算力、數(shù)據(jù)三要素。但對企業(yè)落地AI而言，其實在算力、算法方面能做的有限。因為算力由負載決定（當然，有優(yōu)化空間），算法更多由模型公司決定，但數(shù)據(jù)是企業(yè)自己能掌握的。

因此，要讓飛輪轉起來，第一步就要解決數(shù)據(jù)問題。SAP 業(yè)務數(shù)據(jù)云總裁Michael Ameling在主題演講中也開宗明義：幾十年來，數(shù)據(jù)一直在推動創(chuàng)新。但隨著AI的出現(xiàn)，數(shù)據(jù)比以往任何時候都更加重要。問題在于，數(shù)據(jù)往往是沉默的，缺乏所需的上下文。因此，AI無法充分發(fā)揮其潛力。

SAP的答案是HANA Cloud：一個"AI一直在尋找的數(shù)據(jù)庫"。

這個2009年就開始研發(fā)的內(nèi)存數(shù)據(jù)庫，現(xiàn)在已經(jīng)是數(shù)萬家企業(yè)的IT基礎設施。但它的價值不在于速度，而在于多模型能力。Ameling解釋說：如果沒有HANA Cloud，你將需要為每一種數(shù)據(jù)表示形式配備一個獨立的數(shù)據(jù)庫。比如：一個用于列式存儲，一個用于向量，一個用于知識圖譜。這就會導致數(shù)據(jù)科學的分散化。有了HANA Cloud，就能將所有這些強大的引擎整合在一個多模型數(shù)據(jù)庫中。

反之，實現(xiàn)了數(shù)據(jù)組合，就讓HANA Cloud不只是一個"存儲數(shù)據(jù)"的地方，而是一個"理解數(shù)據(jù)"的引擎。

會上有一個實際的案例：某上游供應商的外勤銷售人員過去很難獲取定價信息。但現(xiàn)在使用HANA Cloud的向量引擎開發(fā)了一個AI定價助手，結果銷售訂單錄入的自動化率大幅提升，訂單錯誤率反而下降幾成。

但更重要的新能力是"發(fā)現(xiàn)智能體"(Discovery Agent)。Ameling說：過去使用HANA的高級功能需要深厚的專業(yè)知識，大家都知道要寫SPARQL查詢有多難。現(xiàn)在，發(fā)現(xiàn)智能體可以幫助用戶即時找到數(shù)據(jù)庫中正確的數(shù)據(jù)對象。過去需要進行大量專家訪談和深入挖掘，現(xiàn)在幾秒鐘就能完成。

在大會第二天的技術演示中（順便說，Day 2 的主題演講全是Demo，下邊我附了演示團隊結束的合影），一位工程師展示了這個能力。他激活了HANA中的Triple Store功能，創(chuàng)建了一個關于TechEd演講者的知識圖譜，然后用自然語言提問："哪個演示將展示應用編程模型，誰能展示它?"

大語言模型自動生成SPARQL查詢，從知識圖譜中檢索出答案：演示標題是"SAP CAP、MCP和AI智能體"。整個過程行云流水，沒有手寫代碼。

更進一步，HANA Cloud將能夠自動掃描所有元數(shù)據(jù)，實時生成知識圖譜，并且"隨著數(shù)據(jù)模型的演進而保持同步"。Ameling強調(diào)：它還將允許通過MCP(Model Context Protocol)將數(shù)據(jù)庫對象"表、視圖、數(shù)據(jù)圖"作為工具來使用。這使得智能體能夠在端到端應用程序中無縫地與HANA的高級功能進行交互。

最后是"智能體記憶"功能。因為智能體需要記住任務、對話和決策作為上下文實現(xiàn)長期記憶，變得更加智能。

HANA Cloud的這些能力，解決的是飛輪的第一個問題：讓數(shù)據(jù)不只是"存在"，而是"可用"、"可理解"、"可記憶"。

3、內(nèi)聯(lián)外通：讓語義不再丟失

不過，顯然企業(yè)光有一個強大的數(shù)據(jù)庫還不夠。因為企業(yè)的數(shù)據(jù)可能分散在各個系統(tǒng)。有SAP自己的應用，有Snowflake的數(shù)據(jù)倉庫，也有Databricks的數(shù)據(jù)湖等等。

所以，如何把這些數(shù)據(jù)統(tǒng)一起來，同時保留業(yè)務語義?

這正是Manoj所說的關鍵挑戰(zhàn)。他在采訪中特別強調(diào)："企業(yè)若使用不同廠商的系統(tǒng)，整合數(shù)據(jù)時就會丟失業(yè)務語義，AI也無法提供有意義的建議。"

SAP的答案是Business Data Cloud(業(yè)務數(shù)據(jù)云，BDC)。

大會上的一個重磅消息是SAP宣布和Snowflake合作。這看起來是一個常規(guī)的生態(tài)合作，但實際上暗含了SAP戰(zhàn)略的一個信號：不要求客戶把數(shù)據(jù)都搬到SAP的平臺上，而是讓SAP的數(shù)據(jù)能力可以"接入"到客戶已有的數(shù)據(jù)平臺。

在大會Q&A環(huán)節(jié)，有人問Alam是否會繼續(xù)擴大BDC的合作伙伴。他的回答也很明確：這是SAP從生態(tài)系統(tǒng)角度保持開放性的承諾。我們有一長串的合作伙伴都很高興能夠參與BDC的發(fā)展，無論是從數(shù)據(jù)共享的角度，還是在其基礎上構建應用程序。

BDC的核心價值在于統(tǒng)一語義層。Ameling解釋：BDC能通過協(xié)議實現(xiàn)零復制數(shù)據(jù)訪問。這意味著數(shù)據(jù)可以留在原地，無論是在S/4HANA、Snowflake還是Databricks等。但是，所有系統(tǒng)都能理解這些數(shù)據(jù)的業(yè)務含義。

更重要的創(chuàng)新是Data Products Studio。這個新工具讓開發(fā)者可以把原始數(shù)據(jù)"打包"成帶有業(yè)務語義的"數(shù)據(jù)產(chǎn)品"。

什么是數(shù)據(jù)產(chǎn)品?簡單說，就是把數(shù)據(jù)從"表格"變成"API"。一個數(shù)據(jù)產(chǎn)品不只包含數(shù)據(jù)本身，還可能包含：

業(yè)務語義：如這個字段是"客戶滿意度"，不只是一個數(shù)字

數(shù)據(jù)血緣：這個數(shù)據(jù)來自哪里，經(jīng)過了什么處理

訪問權限：誰能用，怎么用

版本控制：數(shù)據(jù)定義變化時的向后兼容

在演示環(huán)節(jié)，SAP工程師在幾分鐘內(nèi)就把來自S/4HANA的銷售數(shù)據(jù)和來自Snowflake的市場數(shù)據(jù)融合成了一個"客戶洞察數(shù)據(jù)產(chǎn)品"，設置了版本和權限。這個數(shù)據(jù)產(chǎn)品可以被不同的應用、AI模型直接調(diào)用，不需要重復做數(shù)據(jù)準備。

這種做法的好處是顯而易見的：數(shù)據(jù)團隊不再是"服務臺"，被動響應各種需求，而是可以主動構建可復用的數(shù)據(jù)資產(chǎn)。對AI團隊來說，他們不需要每次都從零開始，直接調(diào)用現(xiàn)成的"數(shù)據(jù)產(chǎn)品"就行。

Ameling總結：SAP業(yè)務數(shù)據(jù)的一個關鍵組成部分是智能應用。這些應用具有自適應性和AI驅動能力，它們從數(shù)據(jù)中學習，在分析和協(xié)同工作中實現(xiàn)自動化。而在幕后，智能應用是由數(shù)據(jù)產(chǎn)品驅動的。

4、為什么表格需要自己的AI

飛輪已經(jīng)有了數(shù)據(jù)層和語義層，接下來需要的是AI的分析能力。

這里有一個沒有被忽視，但是一直存在的悖論。說到AI，就會說到大語言模型，它們很擅長處理文本，但企業(yè)的關鍵數(shù)據(jù)大多在表格里，有訂單、庫存、財務報表等。

于是，我們看到了SAP的SAP-RPT-1（讀音：RapidOne）。

SAP CTO Philipp Herzig在介紹這個模型時，先問了臺下一個問題：如果老板要你用機器學習解決10個業(yè)務預測任務，分別針對公司的10個不同業(yè)務實體，需要訓練多少個模型?

他停頓了一下，然后說答案可能是上百個，每個任務要針對每個實體單獨訓練。但你訓練完兩個之前，老板就會來問ROI了。

講到這，臺下一片笑聲。

這就是傳統(tǒng)機器學習在企業(yè)場景的困境：每個預測任務都要單獨訓練模型，成本高、周期長、難以擴展。

SAP-RPT-1要解決的也就是這個問題。它是一個專門為表格數(shù)據(jù)設計的關系型基礎模型。它不預測"下一個詞"，而是預測"業(yè)務結果"，包括訂單會不會延遲、客戶會不會流失、庫存應該補多少。

Philipp在另一場采訪中說，兩年前SAP經(jīng)內(nèi)部討論，做出了不會自建大型語言模型的決定，而是專注于SAP獨有的結構化數(shù)據(jù)。

而SAP-RPT-1是一個針對表格數(shù)據(jù)的基礎模型，用于預測付款延遲、供應商風險、銷售機會等典型業(yè)務任務。

他說，這個模型在德國和帕洛阿爾托的研究團隊開發(fā)，論文已與斯坦福大學合作發(fā)表。模型采用"跨表圖變換器(Cross-table Graph Transformer)"架構，能在多表關聯(lián)中進行預測。

在Q&A環(huán)節(jié)，有記者追問性能。Herzig給出了更多細節(jié)：實驗結果顯示，它不僅優(yōu)于通用大模型，也超過一般機器學習模型，在公開基準測試上的表現(xiàn)已經(jīng)超過了一些傳統(tǒng)方法。

不過他也很坦誠：我們也期待看到它在不同企業(yè)場景中的實際表現(xiàn)。這就是為什么SAP提供了免費試用環(huán)境。

這就是飛輪AI層的核心能力：除了SAP已經(jīng)集成連接的LLM，還有專門為企業(yè)結構化數(shù)據(jù)設計的預測模型。

5、從助手到執(zhí)行者

飛輪有了數(shù)據(jù)基礎，有了AI的分析能力，接下來需要的是執(zhí)行層——讓AI的洞察真正轉化為行動。SAP的Joule就是做這件事情的。它是一款嵌入 SAP 各類云產(chǎn)品的生成式 AI 助理，將大模型能力與企業(yè)業(yè)務流程深度融合，讓用戶能以自然語言完成數(shù)據(jù)分析、任務執(zhí)行與決策支持。

但這里需要澄清一個容易混淆的概念：我們不應該把Joule看作"應用"，而是AI的交互界面和智能體編排平臺。

SAP CEO Christian Klein此前講過：Joule是成為SAP新的前端，新的用戶體驗。它坐在所有應用之上，是人與AI系統(tǒng)交互的界面。

過去一年，SAP已經(jīng)發(fā)布了多個Joule智能體，覆蓋財務、供應鏈、人力資源等領域。

但對我來說，更有說服力的是SAP CTO Philipp告訴我的另一組數(shù)字。在一場QA環(huán)節(jié)中，他在回答我"SAP內(nèi)部是如何使用AI的"的問題時就用Joule舉了例：

"Joule在SAP內(nèi)部的月活用戶已超過3萬"，"系統(tǒng)中存儲了超過10萬份多語言政策和文檔。員工無論在巴西、非洲還是德國，Joule都能自動匹配適用的人事或差旅政策。"

他還講了一件很有趣的事，在SAP內(nèi)部， Joule的"殺手級應用"第一名是采購流程，但第二名不是復雜的報表分析，而是"查午飯菜單"。SAP IT部門為此開發(fā)了一個定制技能，員工每天可以直接問Joule：今天午餐吃什么?（看來中午吃啥這件事兒，是一個世界難題?。?/p>

不過，我想這聽起來很輕松，但也體現(xiàn)了AI真正融入工作流的意義：當人們每天自然使用它，AI才算落地。

Philipp說，根據(jù)SAP內(nèi)部統(tǒng)計，Joule的差評率(Thumbs Down Rate)僅為1%。這說明在真實的企業(yè)使用環(huán)境下，它已經(jīng)足夠可靠。

這些內(nèi)部數(shù)字，自然比任何demo還有力量。

雖然SAP提供了現(xiàn)成智能體，但是也在推動客戶自己構建智能體。SAP的Joule Studio，就是為這個目的設計的。

6、讓飛輪轉起來需要什么

但飛輪再好，如果開發(fā)者用不起來，也只是空中樓閣。SAP在柏林做的另一件重要的事，是統(tǒng)一開發(fā)者體驗。

第二天的開發(fā)者主題演講，讓人印象深刻的是：在VS Code里無縫開發(fā)SAP應用。

過去，開發(fā)不同類型的SAP應用要用不同的IDE：ABAP要用ABAP Development Tools，UI5要用SAP WebE，低代碼要用SAP Build。開發(fā)者要在多個工具之間切換，學習成本高，效率也低。

現(xiàn)在，SAP把這些能力都整合到了VS Code里。更重要的是，通過MCP服務器，開發(fā)者可以用Cursor、Claude Code這些AI編碼工具來寫SAP應用——AI助手能理解SAP的開發(fā)框架、數(shù)據(jù)模型、業(yè)務邏輯。

演示中，一位工程師展示了整個流程。他打開VS Code，在終端里敲了一行命令創(chuàng)建了一個項目，然后用自然語言對Claude說："我需要一個應用，當SuccessFactors里新增員工時，自動觸發(fā)一個審批流程。"

Claude AI通過SAP的MCP服務器理解了需求，生成了完整的代碼，包括事件訂閱、工作流定義、UI界面。工程師稍微調(diào)整了一下UI的顏色，整個過程只有數(shù)分鐘。

當然，這個demo經(jīng)過了精心準備，實際開發(fā)肯定還需一番功夫。但它傳遞的信號很明確：SAP希望開發(fā)者用自己熟悉的工具、自己喜歡的方式來開發(fā)，而不用鎖定在SAP的工具組合中。

Manoj在接受我的采訪時也提到，有了AI的助力，開發(fā)人員的角色也更加豐富。

SAP同時支持專業(yè)代碼與低代碼/無代碼。業(yè)務人員可以直接在UI中使用SAP Build擴展功能，比如在采購訂單界面添加字段，無需復雜編程。這讓業(yè)務團隊能獨立完成輕量開發(fā)，IT團隊則聚焦核心系統(tǒng)。

再補充一個細節(jié)，SAP在會上展示兩個看似小的功能，可能在企業(yè)內(nèi)部會有大用：

Prompt Optimizer（提示優(yōu)化）：自動把為某個模型寫的提示詞轉換成適配其他模型的版本。

Eval Service（評估服務）：跨模型測試和比較AI用例的效果。

早期客戶的測試顯示，通過提示詞優(yōu)化，在相同成本下可以獲得30%的性能提升。

這些工具的核心思路都是一樣的：把AI的使用從"玩票"變成"工程實踐"。有評估、有版本管理、有自動化優(yōu)化，而不是憑感覺調(diào)參數(shù)。

7、一體化還是最佳組合？以及SAP的護城河

回到最開始我提的問題：CEO們很焦慮，技術團隊很迷茫，怎么辦？SAP給出了自己的答案。

同樣，整個產(chǎn)業(yè)都在重構，SAP的護城河在哪里？

我理解，SAP給出的就是一種架構級的方案：不要把AI當成一個獨立的項目，而要把數(shù)據(jù)、AI、應用作為一個整體來思考。HANA Cloud提供AI-native的數(shù)據(jù)基礎，BDC構建開放的數(shù)據(jù)生態(tài)，RapidOne處理結構化數(shù)據(jù)的預測任務，Joule執(zhí)行智能體編排，開發(fā)者工具讓這一切易于使用。

這個方案是否成功，取決于一個更根本的判斷：企業(yè)AI的未來，到底是"最佳工具組合"還是"一體化平臺"?

如果是前者，那么企業(yè)會繼續(xù)在不同場景下選擇不同的最佳工具。這種情況下，集成和互操作性就是最大的挑戰(zhàn)。

如果是后者，那么像SAP這樣能提供端到端解決方案的平臺就有巨大優(yōu)勢，數(shù)據(jù)、AI、應用都在一個架構里，不需要做復雜的集成工作。

SAP的戰(zhàn)略布局，就是押注企業(yè)會在核心業(yè)務場景里選擇一體化方案。我與一位SAP同事交流時，對方給了我一個頗有說服力的比喻，"早年間，大家身上會帶不同的數(shù)碼設備，隨身聽，照相機，PDA等等，但是iPhone這樣的產(chǎn)品一出來，大家很快選擇了All In One。"

而對于現(xiàn)在市場上隨LLM出現(xiàn)了很多原生企業(yè)應用的景象。Manoj在采訪中談及SAP優(yōu)勢時也給出了一個很有意思的論證：SAP有50年的企業(yè)軟件經(jīng)驗和龐大的客戶群。AI原生公司缺乏最關鍵的東西就是真實的業(yè)務數(shù)據(jù)。以Concur為例，SAP在差旅和費用管理領域積累了豐富的數(shù)據(jù)網(wǎng)絡，能提供其他公司難以企及的洞察。

這種數(shù)據(jù)廣度與業(yè)務上下文的結合，讓SAP能構建出開箱即用、語義完整的AI應用。這正是SAP的護城河。

在TechEd大會上，SAP沒有回避關于當前AI是否一種炒作的疑問。但Philipp講了一句話讓人印象深刻：就像互聯(lián)網(wǎng)早期發(fā)展一樣，人們往往高估一年內(nèi)，新技術能做的事，但是低估十年內(nèi)它們能改變的事。AI的確有炒作的成分，但這次基礎設施成熟得多，迭代速度也更快。真正的價值不會停留在硬件層，而會體現(xiàn)在最終用戶體驗上，那些人人可用、可持續(xù)付費的服務。