SAP S4CRM (SAP Customer Management for S/4HANA) 1.0 介绍

SAP CRM 的前世今生

在我之前的微信公众号文章 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 的项目里继续进行后续版本的开发，所以将来这个公众号会带来更多关于这个产品的介绍文章。