本文阅读目录:
物料主数据系统设计的难点
SAP CRM 产品主数据系统的设计概述
SAP CRM 产品主数据设计的抽象层
SAP CRM 产品主数据的读写引擎
基于元数据驱动的 SAP CRM 产品主数据 UI
本文关于 SAP CRM 产品主数据设计的内容,来源于 SAP 官方帮助文档,链接如下。
物料主数据(Material Master Data)是企业业务流程中的一个关键组成部分。物料主数据是物料关键信息的集合,包含物料的编号、描述、规格、类别、单位、仓库位置、成本、以及其他相关数据,为生产计划、物料管理、库存控制和销售等核心业务功能提供支持。
物料主数据不仅贯穿于整个供应链和生产过程的各个环节,同时也广泛参与到企业内部多个部门的业务流程。
物料主数据系统(或者模块)的模型设计,犹如移动摩天大楼的地基,在任何一个 ERP 软件中都是设计和开发的重头戏。
一个健壮,完善,可用性好,可扩展性强的物料主数据系统,可以帮助企业提高运营效率、减少错误并增强供应链及相关业务流程的透明度。
物料主数据系统设计的难点
数据模型的复杂性:由于物料的类别和用途多样,物料主数据系统需要能够处理各种不同类型的信息,包括普通的成品、半成品、原材料、辅助材料等等。
每种类型的物料都可能有独特的属性和数据需求。例如,化学品需要记录其化学成分和安全处理信息,而机械零件可能需要记录其尺寸、公差和材料等具体信息。
有些 ERP 系统把服务(Service)也当成一种特殊的物料主数据进行处理,又称为 Service Product.
对于服务而言,其关键属性比如服务等级协议(Service Level Agreement)、响应时间、服务费用、服务可用时间、所需资源、成本定价、计算策略等,都与有形的传统物料大相径庭。这也进一步增加了物料模型设计的复杂度。
数据集成和接口:物料主数据系统通常需要与其他企业系统进行集成,比如采购系统、库存管理系统、生产计划系统和财务系统等。不同系统之间的数据接口设计是一个复杂的过程,需要确保数据能正确传递,并保持一致性。
此外,这些接口还需要具有足够的灵活性,以便系统升级或业务流程调整时,能够进行相应的修改。
多部门协作和权限管理:物料主数据系统涉及多个部门,如采购、生产、销售、物流和财务等。因此不同部门对数据的需求和权限也不同。设计一个健全的权限管理系统,确保合理的数据访问控制,同时避免数据孤岛现象,也是系统设计的一个重要挑战。
扩展性和灵活性:企业的业务需求可能随时间变化而不断扩大或调整,物料主数据系统需要具备足够的扩展性和灵活性,以应对这些变化。例如,企业可能引入新的产品线,或者需要满足新的合规要求等等。
SAP CRM 产品主数据系统的设计概述
笔者先后在 SAP Business By Design,SAP Business Suite CRM,SAP Cloud for Customer 和 SAP S/4HANA 开发团队都工作过。这么多年的工作经历,我能感觉到,SAP 在复杂系统设计这个领域,确实积累了很多一脉相承的设计理念和准则。
给我印象最深的有两点:
- 按需引入抽象层来应对业务需求的高复杂度
- 把稳定的逻辑实现成引擎,易变的需求,通过配置和增强出口去承载
在 SAP 系统里,Material 和 Product 这两个概念紧密相关却又有所区别。
Material(物料)主要应用于生产、采购、库存管理等后台(Back Office)业务,强调物理属性和存储管理,例如重量、尺寸、仓库位置等。在制造企业中,物料是生产流程的核心,是投入品和产出品的管理对象。
Product(产品)主要应用于前端销售、市场营销、客户关系管理等领域,更加关注市场和客户视角,例如产品特性、市场定位、定价策略等。在服务型企业中,产品更多是指服务包或解决方案,而不仅仅是物理商品。
SAP CRM 产品主数据设计的抽象层
SAP CRM 产品主数据抬头级别的数据库表,只有寥寥几个字段,产品 ID,GUID,产品类型,创建者,创建时间。
为了用一套模型描述现实业务中千差万别的产品特征,CRM 产品主数据背后是一系列层层相扣的抽象层:Product Hierarchy,Product Category, Settype 和 Relationship.
Product Hierarchy
这是 SAP CRM 主数据模型最高层次的抽象。
帮助文档地址:
https://help.sap.com/docs/SAP_CUSTOMER_RELATIONSHIP_MANAGEMENT/b90203d3616f482ebd9776775ac722d8/465754c601a208e7e10000000a114a6b.html
Product Hierarchy 是一个树形结构,定义了系统里 Product Category 之间的继承从属关系,每个叶节点就是一个 Product Category. 在树形结构里,叶节点代表的 Product Category,继承其父节点 Product Category 的模型属性。
SAP CRM 支持从头新建 Product Hierarchy, 也支持使用中间件,从 SAP ERP 下载 Product Hierarchy 到 CRM 使用。
Product Category
Product Category 即业务流程中描述产品类别的概念,是 Product Hierarchy 树形结构模型中的一个个节点。注意 Product Category 并不直接描述产品属性,它只是产品属性的一个容器。
帮助文档:https://help.sap.com/docs/SAP_CUSTOMER_RELATIONSHIP_MANAGEMENT/b90203d3616f482ebd9776775ac722d8/4657246601a208e7e10000000a114a6b.html
上图最顶层的 Stationery 代表文具这类产品的 Hierarchy. Hole punches,Pens 和 Paper 就是一个个 Product Category.
Product SetType
Product SetType 是真正用来描述产品信息的属性组。每一个维度的产品信息,都对应一个 SetType 模型。一个 Product Category 可以分配多个 SetType 模型。
例如某些产品在生产和销售时采取不同的计量单位,比如针剂生产时单位为“支”,销售时为“盒”。那么使用一个 Unit 转换的 SetType 进行维护,在 SAP CRM 里通过 SetType COMM_PR_UNIT 实现如下:
再比如一个全球化医药公司,在不同国家销售药品时,必须按照当地法规用当地语言提供药品的成分、用法、注意事项等详细描述。这些描述的多语言版本信息,通过 SetType COMM_PR_SHTEXT 实现。
Product Hierarchy,Product Category,Product SetType 和其容纳的属性,用下面这张图说明。
下图出自 SAP 官网:
https://help.sap.com/docs/SAP_CUSTOMER_RELATIONSHIP_MANAGEMENT/b90203d3616f482ebd9776775ac722d8/4657672501a208e7e10000000a114a6b.html
SetType 里的每个属性,根据实际业务,又具有是否允许多个产品主数据重用(Multiple use),以及是否和组织单元相关(Organizational Dependency)的元属性。
Product Relationships
有些产品主数据的属性,彼此之间具有关联关系,或者同其他类型的主数据,比如 Business Partner 主数据具有关联关系。这种主数据记录,是一个二元组数据结构:(Source, Target).
这种二元组数据结构,通过 Product Relationships 维护。
常见的例子有 Accessories 配件,Services 服务,Service Parts 维修零件,Qualification Requirements 资质要求,Warranties 保修等等。
SAP CRM 产品主数据的读写引擎
一个产品主数据,通过其所属的 Product Category,最后承载了二三十个 SetTypes 和 Relationships, 在笔者经历的 SAP CRM 国内项目的实施中,这种场景毫不为奇。
那么面对如此复杂属性的产品主数据,其数据读写逻辑应该如何完成?
如果查看 CRM 产品主数据的数据修改门面(Facade 设计模式)的入口函数,会发现输入参数如此简单,最主要参数的就两个:待修改的产品编号,以及被分配的 Product Category 集合。
这是因为,SAP CRM 产品主数据每一个 SetType,都有自己的元数据集合,如下图所示。
这些元数据集合,包含了 SetType 数据的持久化数据库表,数据读写和持久化函数等等。
当 SAP CRM 产品主数据的读写引擎接收到数据读写请求时,只需要从输入的 Product Category 参数值,解析出这些 Category 指派的 SetType,然后将读写请求,转交到对应的 SetType 元数据里维护的数据读写逻辑即可。
这就体现了笔者之前提到的设计理念:「将稳定不变的逻辑,实现到引擎层面」。
将和业务有强依赖,紧耦合的逻辑,做成可配置的模块(Configurable Module),比如上图展示的每个 SetType 可配置的持久化数据库表和读写逻辑,从而将变化与具体实现解除耦合关系。
采取这种设计之后,如果因为业务调整,需要给某类型的产品主数据增添新的属性,典型的流程就是,新建一个 SetType,为其维护持久化数据库表和数据读写逻辑。
将这个新的 SetType 分配到某个 Product Category,或者新建 Product Category 即可。整个过程中,无需修改本身已经非常稳定的产品主数据读写引擎。
基于元数据驱动的 SAP CRM 产品主数据 UI
SAP CRM 产品主数据的 UI 也是具备高度 Composability,其内容渲染,完全基于 SetType 和 Relationship 的元数据驱动。
下图是 SAP CRM 产品主数据的明细页面。图中红色矩形框区域为产品抬头级别的通用字段集合。任何不同类型的产品主数据,都会显示这些字段。该区域为静态页面。
该区域之外的其他所有页面,都是应用运行时根据当前显示的产品主数据分配的 SetType 和 Relationship,在系统后台动态生成的。这是一种服务器端渲染机制。
SetType 和 Relationship 允许客户自定义创建。这些客户定制出的模型,在产品主数据 UI 上享有和 SAP 原装模型一样的待遇,通过同样的渲染逻辑进行显示。
本文结合笔者工作经验和 SAP 官方帮助文档上的内容,对 SAP CRM 产品主数据模型的设计做了基本的介绍。欢迎各位同行阅读和指教。