SAPCRM的前世今生在我之前微信的公众号文章里，你能分清这三种CRM方案和SAP的区别吗？我提到我是成都SAP研究院CRM产品开发组的一员，工作过一段时间。我问过在SAP德国总部工作的德国前辈，最早的SAPCRM版本是什么时候出来的，得到的答案是上世纪末本世纪初。作为一个PC游戏迷，我想到了微软的操作系统DOS、Windows95、98、2000、Me和XP让我享受了很多国内外的游戏大作。20年转瞬即逝，如今已远离我们的视线。回到我以前工作的SAPCRM。每当Jerry在SAPGUI中调试SAPCRM的Created字段，这些字段显示为本世纪初的ABAP代码时，脑子里就会不由自主地浮现出曹老板和他的杰作中他的千里马的形象：*同样，这些SAPSolution的三个CRM解决方案，你能分辨清楚吗？还提到了SAP成都研究院开发团队开发的另一款产品：S/4HANAforCustomerManagement1.0今天（2018年2月28日），这款产品终于揭开了TA的神秘面纱：在SAP开发团队的共同努力下成都研究院和SAP全球其他部门的同事们，S/4HANAforCustomerManagement1.0已经面世了！SAPCRMOn-Premises（以下简称SAPCRM）的部分销售和服务功能已经成功集成到S/4HANA中，成为S/4HANA的一部分。对于SAP的旗舰产品S/4HANA来说，此次整合可谓“如虎添翼”。作者本人也是这个产品开发团队的一员，贡献了部分代码和一些技术问题以及原型开发，为此我感到自豪。在传统的SAP系统集成部署架构下，SAPERP和SAPCRM通过中间件进行数据同步。如果配置不当，数据同步会出现各种问题。幸运的是，SAPCRM中间件在全球拥有众多用户，产品本身也非常成熟。所以SAP生态中有很多中间件相关的文档，让你在遇到问题的时候不会手足无措。好消息是，在S/4HANAforCustomerManagement中，从设计层面就避免了原有CRM和ERP数据同步过程中的各种令人头疼的问题，因为在这个产品中运行的CRM销售和服务业务，所使用的业务数据而生成的当然是直接存储在S/4HANA系统中，完全不需要使用中间件进行数据同步。S/4HANAforCustomerManagement1.0支持的销售服务功能详见SAP官方帮助文档。让我们来看看这款产品的外观。在FioriLaunchpad中点击下图所示的磁贴，开启S/4HANAforCustomerManagement之旅：对于用过SAPCRM的朋友来说，以下都是熟悉的味道。如果在后台用户配置文件中维护参数CRM_UI_PROFILE的值为*，则可以在登录界面看到所有可选的业务角色如下图：现在我使用角色S4C_SRV_ICAG登录系统，运行与呼叫中心相关的场景。假设一个叫Jerry的客户打电话给呼叫中心，请求服务他购买的ID为11的产品。座席接到电话后，首先确认Jerry的身份：可以根据Jerry提供的AccountID在系统或其他联系信息，例如手机号码、电子邮件地址等（所有支持的方法都显示在显示的识别帐户区域的字段中）。这里代理使用的方法是根据AccountID来确认身份。代理输入Jerry提供的帐户ID，然后单击“搜索帐户”按钮：选择搜索结果并单击“确认”按钮。然后根据Jerry提供的产品ID11搜索该产品，点击工具栏上的创建按钮，创建一个基于该产品的服务订单。这是最后的订单列表：我的公众号后台收到了很多朋友的留言询问这个产品的详情。以下是我可以一一回答的问题。1.S/4HANAforCustomerManagement的UI是用什么技术开发的？回答：仍然使用SAPCRMWebClientUI而不是SAPUI5。对于熟悉CRMWebClientUI开发技术的朋友来说，这是一个好消息，意味着你在这项开发技能上投入的时间没有白费，你可以在S/4HANA上继续大放异彩。对于想学习新的UI开发技术的人来说，S/4HANA的CDSView+SmartTemplate的组合也为大家提供了使用新技术的机会。如果想尝试SmartTemplate，可以参考我的微信公众号文章：Jerry的通过CDS视图+SmartTemplate开发Fiori应用的博客合集，里面有一些具体的例子。2.S/4HANAforCustomerManagement中的销售和服务流程与SAPCRM中的相应流程有什么区别？答：至少在目前已经发布的1.0版本中，前者是后者的一个子集。后续版本将引入更多SAPCRMinS/4HANA支持的销售和服务功能。3、转问题2：对于相同的业务流程，S/4HANAforCustomerManagement和SAPCRM在技术实现上有什么区别？答：同样的功能，比如物料主数据的搜索，虽然在最终用户看来是在同一个UI上点击搜索按钮，但是在两个产品的技术实现上是不一样的。差异主要体现在下图中绿色区域的GenericInteraction层和更底层的数据模型，以及围绕这些数据模型进行CRUD（增删改查）操作的API。数据库表的变化是最容易理解的。在这两个产品中，有很多模型实际上是从业务角度描述同一个概念，比如SAPCRM中的Product（产品）和S/4HANA中的Material（材料）。在CRM中我们使用交易代码COMMPR01来创建一个产品，它的相关数据存储在一系列以COMM_开头的表中。在S/4HANA中，物料在事务码MM01中创建，数据存储在主表MARA和一系列从表中。上面的描述反映了这样一种情况：SAPCRM和S/4HANA使用不同的技术模型来描述相同的业务概念。针对这种情况，在将SAPCRM的销售和服务流程引入S/4HANA的过程中，我们面临着模型选择的问题。我们采用的标准是：使用S/4HANA模型。这意味着在S/4HANAforCustomerManagement中，之前在SAPCRM中使用的API也需要做相应的调整。这些API中对SAPCRM数据模型的操作需要重定向到S/4HANA对应的数据模型。举个具体的例子：以存储物料的数据库表为例。ID为11的产品在本文开头的S/4HANAforCustomerManagement外观介绍中有提到。在SAPCRM中，我们到表COMM_PRODUCT中根据PRODUCT_ID查找产品。在S/4HANA中，您需要在表MARA中找到它。值得一提的是，在这款新产品的开发过程中，我们并没有简单地找出代码中所有使用SAPCRM数据模型的地方，并替换为S/4HANA数据模型。我们基于S/4HANA架构做了很多优化，以充分发挥S/4HANA系统底层提供的强大功能和各种创新技术。一个具体的例子就是本文开头提到的产品搜索功能。该功能由SAP成都研究院开发团队实现。SAPCRM产品搜索的底层实现基于数据库表COMM_PRODUCT。在S/4HANAforCustomerManagement中，同事们并没有简单照搬思路，直接查看S/4HANA物料数据库表MARA，而是采用了S/4HANA新的建模方式，设计了CDS视图。当用户点击搜索按钮时，底层执行会搜索下图所示的CDS视图。借助CDS视图，我们遵循S/4HANA建模领域众所周知的“CodePushDown”原则，保证尽可能多的逻辑直接在数据库层面执行，充分发挥数据的强大功能SAPHANA的处理能力。如果您对S/4HANA中CDS视图的重要建模方法感兴趣，可以阅读这篇访问量超过20,000的SAP社区CDS视图概述文章：ABAP核心数据服务-简介（ABAPCDS视图）https://blogs。sap.com/2017/09...想了解更多CDS视图的一些技术细节，可以参考我的微信公众号文章：Jerry的CDS视图自学系列，共14篇，全是我通过阅读CDS框架源码和调试了解到的一些技术实现细节，以及我做过的一些例子和工具。4.S/4HANAforCustomerManagement中的OneOrder模型与SAPCRM中的模型相比有何改进？答：有很多改进。Jerry去年在德国SAP总部吃了3个月的土豆+面包，就是他在做的事情。在SAPCRM中，一个订单的数据分散在不同的数据库表中。最熟悉的就是存储表头信息的CRMD_ORDERADM_H和存储行项信息的CRMD_ORDERADM_I这两个表。名字中的ADM（Administration）就是一个暗示：订单的大部分业务数据并不存储在这两个表中，而是存储在其他专用表中。如下图所示，图中不同颜色的矩形框代表OneOrder模型中不同类型的节点。每个节点都有一个专用的数据库表。这些节点可能包含从属关系，这些关系在下图的中心维护。在数据库表CRMD_LINK中。所有这些数据库表加起来有200多张。这套数据模型在传统的Transaction应用领域被证明是非常成功的：SAPCRM在全球众多客户群体中的广泛应用就说明了一切。在Analytics使用场景中，上述数据模型需要配合另外一个模型，就是CRM顾问熟悉的索引表CRMD_ORDER_INDEX。顾名思义，这个表的引入是一种以空间换取时间的策略——索引表存储了一些业务数据表的数据，以一些冗余的存储空间为代价，减少了分析计算所花费的时间。在S/4HANAforCustomerManagement中，OneOrder的底层存储模型得到了极大的简化。订单的所有表头级数据，如订单号、描述、类型、创建者、创建时间、发送者、接收者等，都存储在一个新的数据库表CRMS4D_SERV_H中。对应的行项目信息存储在表CRMS4D_SERV_I中。基于这种扁平结构在数据表上构建的CDS视图，可以最大限度减少Analytics场景提取数据所需的数据库表之间的连接操作，充分发挥S/4HANA强大的数据处理能力，从根本上避免浪费引入索引表造成的存储空间占用。从用户的角度来看，S/4HANA与CDS视图的结合是Analytics场景下最好的性能保障。从架构的角度来看，S/4HANA的销售和服务业务的Transaction和Analytics应用程序使用相同的新数据模型，这与SAPCRMOnPremise中许多业务特定表+CRMD_LINK+CRMD_ORDER_INDEX的设计大大简化.更重要的是，CDS视图的引入使得S/4HANAforCustomerManagement受益于SAP在CDS视图领域的不断创新。从合作伙伴的角度来看，底层模型的简化也降低了合作伙伴故障排除的复杂度。同时，得益于SAPCRM中OneOrderAPI优雅的层级设计——上述底层存储模型的变化并未影响OneOrderAPI的接口。这意味着，如果你之前已经能够在SAPCRM中熟练运行CRM_ORDER_MAINTAIN、CRM_ORDER_SAVE等API进行二次开发，那么你在S/4HANA中进行客户管理中OneOrder相关的二次开发就没有问题了——这些API的用法没有任何改变。5.我是SAPCRM开发顾问。我将来会失业吗？答：如果你有耐心看完到这里，相信你心里已经有了答案。一方面，在S/4HANAforCustomerManagement中，二次开发使用的技术依然是前台的CRMWebClientUI，加上后台的OneOrder系列API，使得大家在这方面的技术积累对于多年不可靠。徒然。另一方面，由于这款新产品运行在SAP旗舰产品S/4HANA上，为每一位想学习S/4HANA的CRM顾问打开了一扇大门。我个人有一种感觉，在学习一项新技术或者一个新产品的时候，在工作中、在实战中学习，比业余时间看资料更高效、更深入。S/4HANAforCustomerManagement的问世，为每一位CRM顾问提供了更大的舞台，让大家不仅可以在销售和服务领域继续深耕，更可以在工作中学习S/4HANA。我个人认为这是一个很好的发展机会。
