在我之前的微信公眾號文章?SAP的這三款CRM解決方案，您能區分清楚麽我曾經提到過我作為成都SAP研究院CRM產品開發團隊的一員工作過一段時間。

我向在SAP德國總部工作的德國老前輩們請教SAP CRM最早的版本是何時問世的，得到的答復是上世紀末本世紀初。

作為一個PC遊戲迷，我聯想到了供我領略眾多國內外遊戲大作的微軟操作系統DOS, Windows 95, 98, 2000, Me和XP,? 20年轉瞬即逝，如今它們已經遠離我們的視線了。

再回到我曾經工作的SAP CRM。每當Jerry在SAPGUI裏調試著SAP CRM那些Created字段顯示為本世紀初的ABAP代碼時，腦子裏情不自禁地浮現出曹老板和他神作裏的千裏馬形象:

同樣,?SAP的這三款CRM解決方案，您能區分清楚麽?裏也提到了另一款SAP成都研究院的開發團隊參與開發的產品：S/4HANA for Customer Management 1.0

今天(2018年2月28日)，這款產品終於揭開了TA的神秘面紗 : 在SAP成都研究院開發團隊和SAP全球其他部門同事們的共同努力下，S/4HANA for Customer Management 1.0問世了！

SAP CRM On-Premises(下文簡稱為SAP CRM)的部分銷售和服務功能已經成功集成到了S/4HANA裏, 成為了S/4HANA的一部分。對於SAP的旗艦級產品S/4HANA來說，可以用"如虎添翼"四個字來形容這一融合。作者本人也是這個產品開發團隊的一份子，貢獻了部分代碼和一些技術難題的攻關和原型開發，為此我感到自豪。

在傳統的SAP系統集成部署架構下，SAP ERP和SAP CRM通過中間件進行數據同步，其間若是配置不當，數據同步可能會出現形形×××的問題。好在SAP CRM中間件在全球有著眾多用戶，這個產品本身又非常成熟，因此SAP生態圈內有著眾多中間件相關文檔，讓您在遇到問題時不會一籌莫展。

一個好消息是，在S/4HANA for Customer Management裏，原本CRM和ERP數據同步過程中種種令人頭痛的問題已經從設計層面上得以避免了，因為在這款產品裏運行的CRM銷售和服務業務，使用和生成的業務數據當然是直接存儲在S/4HANA系統裏的，根本就不再需要使用中間件進行數據同步了。

關於S/4HANA for Customer Management 1.0 支持的銷售和服務功能細節，請參閱SAP官方幫助文檔。

先看看這個產品顏值如何。點擊Fiori Launchpad裏下圖所示的tile開啟S/4HANA for Customer Management的旅程：

對於使用過SAP CRM的朋友來說，接下來都是熟悉的味道。如果後臺用戶profile裏將參數CRM_UI_PROFILE的值維護為*，就能夠在下圖的登錄界面裏看到所有可供選擇的業務角色:

現在我用角色S4C_SRV_ICAG登入系統, 跑一個呼叫中心相關的場景。

假設一位名叫Jerry的客戶打電話到呼叫中心，就他購買的一款ID為11的產品提出了服務請求。

座席接到電話，首先確認Jerry的身份：可以根據Jerry提供的在系統中的Account ID或是其他的聯系方式，比如手機號碼，郵箱地址等等(支持的所有方式如下圖Identify Account區域內的字段所示)。這裏座席采用的方式是根據Account ID來確認身份。

座席輸入Jerry提供的Account ID，點擊Search Account按鈕:

選中搜索結果，點擊Confirm按鈕。

然後根據Jerry提供的產品ID 11, 將這個產品搜索出來，點擊工具欄的創建按鈕，基於該產品創建一個服務訂單。

這是最終生成的訂單一覽：

我的公眾號後臺收到很多朋友的留言，詢問關於這個產品的種種細節。這裏就我能夠回答的問題一一解答。

1. S/4HANA for Customer Management的UI是用什麽技術開發的？

答：用的仍然是SAP CRM WebClient UI，而不是SAP UI5。對於熟悉CRM WebClient UI開發技術的朋友們來說，這是一個好消息，意味著大家以前在這項開發技能上投入的時間沒有白費，可以繼續在S/4HANA上發光發熱。而對那些想學習新的UI開發技術的朋友們來說，S/4HANA的CDS View+Smart Template這一組合，也給大家充分提供了使用新技術的機會。大家如果想嘗試Smart Template，可以參考我的微信公眾號文章:?Jerry的通過CDS view + Smart Template 開發Fiori應用的blog合集, 裏面包含了一些具體的例子。

2. S/4HANA for Customer Management裏的銷售和服務流程，和SAP CRM的對應流程相比有何區別？

答: 至少在目前已經發布的1.0版本裏，前者是後者的一個子集。後續版本會在S/4HANA裏引入更多在SAP CRM裏支持的銷售和服務功能。

3. 接問題2: 同樣的業務流程，S/4HANA for Customer Management裏的技術實現，和SAP CRM相比有何區別？

答: 同一個功能，比如物料主數據的搜索，雖然從最終用戶眼中看起來都是在同樣的UI上點擊搜索按鈕而已，但技術上的實現在這兩個產品裏是不同的。差異主要體現在下圖中綠色區域的Generic Interaction層和更底層的數據模型，以及圍繞這些數據模型進行CRUD(增刪讀改)操作的API。

數據庫表的更改最易理解，在這兩個產品裏有很多從業務上說實際上描述的是同一概念的模型，比如SAP CRM的Product(產品)和S/4HANA裏的Material(物料)。在CRM裏我們用事務碼COMMPR01創建產品, 其相關數據存儲在以COMM_開頭的一系列表裏。而S/4HANA則是在事務碼MM01裏創建物料, 數據存儲在主表MARA和一系列從表裏。

上述描述反映了這樣一種情況：在SAP CRM和S/4HANA分別用不同的技術模式描述業務上同一個概念。針對這種情況，在將SAP CRM的銷售和服務流程引入S/4HANA的過程中，我們面臨著模型的取舍問題。我們采用的準則是：使用S/4HANA的模型。

這就意味著在S/4HANA for Customer Management裏，之前SAP CRM裏使用的API也需要做相應的調整，這些API裏對SAP CRM數據模型的操作需要重定向到S/4HANA對應的數據模型。

舉一個具體的例子：

以存儲物料的數據庫表為例。本文前部在介紹S/4HANA for Customer Management的外觀部分提到了ID為11的產品，在SAP CRM裏我們是去表COMM_PRODUCT裏根據PRODUCT_ID來找到該產品。而在S/4HANA裏則需要去表MARA裏找。

值得一提的是，在這款新產品的開發過程中，我們並不是簡單地將代碼裏所有使用到SAP CRM數據模型的地方都找出來，替換成S/4HANA的數據模型而已。我們做了很多基於S/4HANA架構的優化，目的是充分發揮S/4HANA系統底層提供的強大功能和各種創新技術。

一個具體例子就是本文開頭提到的產品搜索功能。這個功能是SAP成都研究院開發團隊負責實現的。SAP CRM產品搜索的底層實現是基於數據庫表COMM_PRODUCT的。而在S/4HANA for Customer Management裏，我的同事們並沒有簡單照搬思路直接去查S/4HANA物料數據庫表MARA，而是采用了S/4HANA的新的建模方式，設計了一個CDS view。當用戶點擊了搜索按鈕後，底層的執行會搜索下圖這個CDS view。

借助CDS view，我們遵循了S/4HANA建模領域裏耳熟能詳的準則"Code Push Down", 確保了盡可能多的邏輯直接在數據庫層面執行, 充分發揮SAP HANA強大的數據處理能力。

如果大家對S/4HANA裏CDS view這一重要的建模方式感興趣的話，可以閱讀這篇SAP Community上訪問量過2萬的CDS View概述文章：

ABAP Core Data Services – Introduction (ABAP CDS view)

https://blogs.sap.com/2017/09/09/abap-core-data-services-introduction-abap-cds-view/

如果想深入了解CDS view的一些技術細節，請參考我的微信公眾號文章：Jerry的CDS view自學系列，裏面包含了14篇文章，全是我自己通過閱讀CDS框架源代碼和調試的方式了解到的一些技術實現細節,以及我做過的一些例子和工具。

4. S/4HANA for Customer Management裏的One Order模型，和SAP CRM裏的模型相比有何改進？

答：有很多改進，Jerry去年在德國SAP總部吃了3個月的土豆+面包，就是在做這件事情。

在SAP CRM裏，一個訂單的數據散落在不同的數據庫表裏，大家最熟知的，就是存放擡頭信息的CRMD_ORDERADM_H和存放行項目信息的CRMD_ORDERADM_I這兩張表。其名稱中的ADM(Administration)是一個提示：訂單的絕大部分業務數據並沒有存儲在這兩張表裏，而是位於其他的專屬表裏。

如下圖所示，圖中不同顏色的矩形框代表One Order模型裏不同類型的節點，每個節點擁有一個專屬的數據庫表，這些節點之間可能包含從屬關系，這些從屬關系又維護在下圖正中的數據庫表CRMD_LINK裏。

所有這些數據庫表加起來有200多個。這套數據模型在傳統的Transaction應用領域裏被證明是非常成功的：SAP CRM廣泛應用於全球眾多客戶群的事實說明了一切。而在Analytics使用場景下，上述數據模型需要和另一個模型，就是CRM顧問們熟知的索引表CRMD_ORDER_INDEX協同工作。

顧名思義，這張表的引入是一個以空間換時間的策略——索引表存放了部分來自業務數據表裏的數據，以部分冗余的存儲空間為代價來減少進行Analytics計算所花費的時間。

而在S/4HANA for Customer Management裏，One Order的底層存儲模型得到了大幅簡化。一個訂單所有的擡頭級別的數據，例如訂單編號，描述信息，類型，創建者，創建時間，發貨方，收貨方等等都存儲在一個新的數據庫表CRMS4D_SERV_H裏。

而對應的行項目信息，則存放於表CRMS4D_SERV_I裏。

基於這種扁平結構的數據表上構造出來的CDS view，能夠最大程度上減少為了抽取數據用於Analytics場景所需要進行的數據庫表之間的連接操作，充分發揮出S/4HANA強勁的數據處理能力，也從根本上避免了索引表的引入造成的存儲空間浪費。

• 從用戶的角度上說，S/4HANA加上CDS view這對組合，就是Analytics場景下最好的性能保證。

• 從架構的角度上說，S/4HANA的銷售和服務這塊業務的Transaction和Analytics應用，使用了同一套新的數據模型，相比SAP CRM On Premise的眾多業務專屬表+CRMD_LINK+CRMD_ORDER_INDEX的設計有了大幅簡化。更重要的是，CDS view的引入，使得S/4HANA for Customer Management能夠受益於SAP在CDS view這一領域內的持續創新。

• 從Partner的角度上說，底層模型的簡化，也降低了Partner排錯的復雜度。同時，感謝之前SAP CRM裏One Order API優雅的分層設計——上文描述的底層存儲模型的改動，沒有影響到One Order API的接口。這意味著如果之前您已經能夠在SAP CRM裏熟練運行CRM_ORDER_MAINTAIN和CRM_ORDER_SAVE這些API進行二次開發，那麽您在S/4HANA for Customer Management從事和One Order相關的二次開發也沒有任何問題——這些API的用法沒有任何改變。

5. 我是一位SAP CRM開發顧問。我將來會失業麽？

答：如果您有耐心讀到這裏，相信您心中已經有了答案。

一方面，在S/4HANA for Customer Management裏，二次開發使用到的技術, 前臺仍然是CRM WebClient UI，加上後臺的One Order系列的API，這使得大家之前在這一領域多年的技術積累沒有白費。另一方面，這個新的產品因為是運行在S/4HANA這一SAP旗艦級產品上，這就給每一位希望學習S/4HANA的CRM顧問打開了一扇門。

我自己有一個感受，學習一項新技術，或是一個新產品，在工作和實戰中學習，其效率和知識掌握的深度都要超過在業余時間看看資料這種學習方式。S/4HANA for Customer Management的問世，給每一位CRM顧問提供了更大的舞臺，讓大家不僅能繼續在銷售和服務領域深耕，同時也能在工作中學習S/4HANA，我個人認為這是一個很好的發展機會。

因為Jerry還在S/4HANA for Customer Management的項目裏繼續進行後續版本的開發，所以將來這個公眾號會帶來更多關於這個產品的介紹文章。

如果大家還有關於這個產品的其他問題，請在這篇文章做出評論或者直接在後臺給我留言。如果大家想成為SAP成都開發團隊的一份子，和我們一起努力讓S/4HANA for Customer Management變得更好，請發送消息到這個公眾號的後臺通知我。我會和您聯系。

Hello World, S/4HANA for Customer Management 1.0