在我之前的微信公衆号文章 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，我個人認為這是一個很好的發展機會。