聊聊SAP系统架构有多牛逼?(2)

简介: 聊聊SAP系统架构有多牛逼?

二、SAP架构的特点(PartI)


下文中,对SAP的架构(应用和技术架构)的特点做简要的描述,由于特点较多,因此分为二个章节来介绍,本文是第一部分,后面择机补充完整第二部分的内容。



特点1:对商业世界的高度抽象

企业管理软件本质是对企业(商业世界)的业务活动、业务逻辑进行抽象,通过IT系统实现,SAP在这方面做到了高度的抽象。


给大家介绍一个在SAP中的高度抽象的例子,离散制造领域用的生产订单、流程行业的流程订单、设备维修领域的维修工单、售后服务领域的订单、项目管理中的网络工单,这些单据看上去属于完全不同的领域,但从高度抽象的角度,都属于订单(工单),都有各种日期(计划日期与实际日期),都需要用到BOM、都需要发料、报工,也都需要与财务进行结算,因此这些不同类型的工单在SAP中共享了相同的数据表、很多功能都是共享(类似)的,只是在局部进行了区分。


这种模式,我将其称之为稳健功能强大的后台模型+灵活应对各种场景的前中台应用。


备注:分与合(灵活前台与稳定后台)是这个世界最主要的永恒话题之一,历史上分久必合,合久必分,企业领域有各种兼并、拆分,企业内部管理领域有各种部门的重组,互联网领域的中台、微服务等等本质都是关于分与合。分可以更好让某个业务更独立,让特定场景(业务)运作更好,合可以达到共享、协同、复用的目的。如何很好的处理分与和的问题,是企业管理、产品管理的难点。以SAP咨询行业为例,1家公司有1000个顾问,这1000个顾问应该是整体一个资源池,最大化共享资源,还是说很多顾问直接归属于行业线,更好地服务特定行业。




特点2:SAP是高度参数化设计的软件


在IT系统中要实现一个业务功能,有三种实现方式:

1)、主要在程序中写死

2)、在程序中写死+部分参数

3)、高度参数化,然后在程序中根据参数写业务逻辑,如果业务有变化,通过参数调整,实现更多(不同)功能。


SAP选择了第三种实现方式,高度参数化,这种方式对架构的要求最高,但显然是最能适应各种业务场景、最能满足各行各业的业务需求,这种参数在SAP中称之为配置。


以销售订单为例,典型的配置(参数)包括订单是否需要发货、是否需要定价(如何定价)、是否需要开票(如何开票,如是否可以部分开票)、库存类型是常规库存、还是特殊库存(销售订单库存、寄售库存等),当销售套件时是否需要成套发货,成套发货支持几层成套等各种各样的参数,这些参数之间互相组合,就形成了企业的各种销售业务,这些参数与企业的生产、采购、财务领域的参数组合,就形成了企业各种各样的业务(端到端流程)。


如下图所示,SAP系统中一共近10万个配置表(参数表),这些配置表又分为二大类:完全由SAP控制和由用户(客户)配置的表,绝大部分的配置(参数)可由客户(用户)自己配置。


对于企业来说,新增一个公司、业务类型(采购模式、销售模式、生产模式、质量控制模式等等),在SAP系统中主要是通过配置(参数)的方式来实现的,并且这种参数不是孤立的参数,是可以做到闭环的参数,能够保证端到端的流程跑通。





特点3:SAP可能是提供预配置最多的软件


一方面参数与参数之间存在关系,另外一方面需要给客户(企业)标准化,因此SAP中预配置了大量的参数(配置),并且这些参数大部分是以组合的形式呈现。


以物料为例,在SAP中,预配置了十几种物料类型(成品、半成品、包装、贸易物料、服务、替代物料组、可配置物料、可退回包装等)、十几种生产计划策略、十几种批量方式、十种物料获得的方式(采购、自制、跨工厂调拨、委外、寄售等等)。


对于企业来说,在实施项目时,根据业务特点,选择使用哪一种计划策略、哪一种物料获得方式。


当预配置的标准配置不能满足业务需要时,可以进一步对具体的参数进行微调。


这一点相当于SAP提供了精装修房子、以及样板房,同时还支持对精装修房子自己再去做调整。






特点4:可能是函数量最多、对外接口最多的软件

作为一个高度抽象的系统,系统中必不可少的有很多函数,这些函数代表着封装好的一个功能,比如创建物料、对物料进行库存检查、创建销售订单、根据日期查询工厂日历。


SAP系统中一共拥有54万个函数(API),这些函数可以在SAP系统内部被调用。


同时这50万个函数中有5万个被认为可能会与外围系统发生数据交互的,因此设置为可以被外部系统调用的RFC函数。这5万个RFC函数根据需要也可以转换为Webservice(Web服务)的方式供其他系统调用。最新的系统在接口方面也进一步拓展了Restful的服务能力。


其他45万个函数,假如其他系统真的也需要调用,那么也可以复制出来一个新函数,略作修改,然后设置为RFC函数。


函数(API)的最大的优势在于外围系统只需要输入参数就能实现特定的功能,不需要管具体的表结构和逻辑。


函数的内在逻辑是实现业务的端到端流程,另外一方面给企业的业务流程、给项目实施带来给了极大的自由度,比如用户对SAP中创建物料的界面不满意,完全可以在SAP系统中写代码、设计新界面,然后调用函数,当然企业也可以选择在外围系统写UI界面,然后调用创建物料的函数,最重要的一点是调用函数的方式和直接在SAP中用标准功能创建物料是相同的业务逻辑,执行相同的权限检查。



特点5:可能是最开放、最灵活的系统(增强机制)


这种开放性、灵活性体现在很多个方面,首先SAP的960万个程序99.9%都是源代码开放的,同时SAP已经提供了无数个配置(参数)。


但每个行业、客户还会有特殊的需求,sap的标准功能无法满足,比如需要对订单的特定字段进行额外的逻辑检查,此时一定需要在项目中进行二次开发,但二次开发的难点是如何与标准程序和谐发展,以及当系统升级后,如何保留这些代码,并且还继续生效。


SAP系统中,通过在在程序中预留了很多增强(用户出口)来实现这样的灵活需求,在增强中,客户(项目组)写自己的代码逻辑从而实现特定的功能,包括检查、赋值、调用其他事务等各种功能。SAP增强最大的特点在于他会和SAP标准的程序一起生效,增强与核心逻辑是融入在一起的,同时非常关键的一点在于在增强中写的自定义代码,不会影响SAP系统的升级,系统升级后,这些增强代码仍然存在,也仍然在继续生效。


在增强上,SAP花了很多心思经历在这方面,在过去的几十年内设计了四代的增强。这四代增强今天都仍然继续生效。


1代和2代增强都是上个世纪推出的,其中第一代增强是在程序中预留了空代码的子过程(Form),第二代增强是基于函数的增强,在程序中预留了很多空代码的函数,在这些函数中有输入和输出参数,可以根据输入参数,然后写一些逻辑,改变输出参数。


第三代增强是基于面向对象的增强BusinessAdd-in,2000年左右推出,SAP预留了10000个增强点。第四代的增长是隐式增强,这是一个终极Boss,理论上所有760万个程序都可以写隐式增强。



增强是SAP项目中必不可少的部分,每个项目都会使用到其中的几十个增强,多的项目可能会用到上百上千个增强。在增强中实现特定的检查逻辑和赋值逻辑,如按照特定规则生成批次,实现自定义的信用控制规则。



特点6:成熟的补丁(优化)以及文档的体系


企业在实施/使用系统的过程中,经常碰到如下但不限于的场景:

1)、正在使用的(SAP)系统存在Bug,需要打补丁。

2)、(SAP)系统新推出的功能,企业希望应用这些新的功能,此时需要在系统中引入新的功能增强。

3)、对于(SAP)系统的一些原理有不清晰的地方,此时需要查看一些文档。


对于这些场景(问题)的管理不是一件容易的事情,SAP建立了一套Note系统,每个Note解决一个具体的问题(补丁、新功能、问题解释等),通过几十年的积累,SAP积累了300多万个这样的Note


Note对于产品的生命周期非常关键,比如对于SAP顾问来说,通过查找Note解决问题时是必备的技能,对于SAP公司来说,其会每年更新(发货)其软件的新功能(补丁),这些新发布补丁包,其本质就是几千、几万个Note的组合。对于客户来说,也可以提出自己的问题(想法),SAP最终会以Note的形式来回应。


如下图所示,是今天刚刚发布的一个Note,这个Note是对SAPMDG模块供应商删除功能的一个说明(Clarificationon Mark for Deletion of Supplier)。

Note还有一个重要的特点,很多Note是不断更新的,非常有生命力的。比如如下的Note18163信用管理的检查清单,最新版本是16,代表这个Note从发布后,被更新了15次。


对于Note的管理是一件非常重要的事情,也是一件不简单的事情,软件公司都会有很多个产品,每个产品都有很多个版本,只有通过一个好的机制,才能够保证产品在迭代,始终在进步,而不是有时在开倒车。


很多产品都有开倒车的经历,如果一个产品一代比一代好,那么迭代几十年,产品都不会差,比如小米手机如果能够一代比一代好,今天的小米可能也能占领手机的高端市场了。



特点7:即使有大量二次开发也能实现系统升级的机制

SAP系统支持一代又一代的升级,并且在升级的时候可以保留客户系统的二次开发以及历史的数据,因此SAP的客户理论上,即使在几十年前上线了SAP系统,可以逐步的迭代升级到最新的系统。这背后意味着很强的产品架构能力,这种架构能力给客户带来很大的价值,客户可以相信SAP系统可以长久使用几十年,同时通过升级的方式保证有机的生命力。


对于软件企业来说,自身的软件系统升级时,如何不覆盖掉客户的自定义的配置和二次开发,这是一个难点问题。


SAP通过各种方式,如配置的命名规则、以及在程序中预留增强,来确保用户自定义的配置和程序不会在升级时被覆盖,并且即使数据结构发生了变化,也可以带历史的数据升级。


本质上哪怕一个SAP系统有上万个二次开发(客开)都不会影响SAP系统的升级,你可以始终在SAP的船上,不会被迫下船,就像《海上钢琴师》一样,并且这艘船自身还在不停的升级,从蒸汽船变成电力的,再到智能的。




三、特别注意点

上文中的很多数字,(如几万个配置点/表)看上去比较夸张,这是因为SAP中大概有40个模块,减掉系统必须、一般都不会使用到的基础架构性质的内容,每个模块算下来不会超过1000个表,也不会超过1000个配置项,给用户操作的事务也不超过200个。


取决于客户的复杂性以及应用的深入情况,平均下来,项目中每个模块实际用到的是其中的20~30%,数量级一般是小于100个表、小于200个配置、小于50个给用户操作的事务。



四、小结

如上的特点让SAP可以同时在保持稳健的基础上做到高度的标准化、灵活性(定制化)。


特点1代表SAP对现实世界的的理解,体现了SAP的应用架构的高明之处,体现了抽象能力,这是应用架构层面的基础性工作。

特点2本质是通过配置(5万个)实现各种功能,且配置管理方便,这一点带来了标准化以及灵活性


特点3本质是预留了大量的标准配置供参考,提供了“最佳”的业务实践,这一点带来了管理软件最需要的最佳实践参考,也是标准化的一部分。

特点4内部有大概50万个函数,高度抽象、重用,这一点带来了标准化+灵活性


特点5本质是增强机制,预留了大量的增强(上万个),同时源代码开放,这一特点带来了基于标准化下的高度灵活性

特点6是Note体系,使得产品在持续迭代,使得产品有生命力,方便了SAP、咨询公司、以及客户,确保产品在持续进步


特点7是解决大型客户的忧虑,大型客户并不希望经常换系统,SAP通过良好的架构,使得企业即使有大量二次开发也能实现系统的持续升级

相关文章
|
运维 安全 前端开发
聊聊SAP系统架构有多牛逼?(1)
聊聊SAP系统架构有多牛逼?
739 0
|
运维 安全 前端开发
聊聊SAP系统架构有多牛逼?(1)
聊聊SAP系统架构有多牛逼?
173 0
SAP MM/FI_运费处理方式
常见的采购运费处理方式
SAP MM 途损处理方式
通常客户采购业务需求提到货物运输有损耗,需要针对此业务给出合理方案输出,下面笔者针对此类业务分析下各种实现方案的可行性!
SAP MM初阶之事务代码MIGO界面批次拆分最多输入15行?
SAP MM初阶之事务代码MIGO界面批次拆分最多输入15行?
SAP MM初阶之事务代码MIGO界面批次拆分最多输入15行?
SAP MM不常用移动类型之325
SAP MM不常用移动类型之325
SAP MM不常用移动类型之325
SAP MM初阶之采购信息记录里的Prior Supplier栏位
SAP MM初阶之采购信息记录里的Prior Supplier栏位
SAP MM初阶之采购信息记录里的Prior Supplier栏位
SAP MM初阶之ME12里为啥只能维护少量条件类型的价格?
SAP MM初阶之ME12里为啥只能维护少量条件类型的价格?
SAP MM初阶之ME12里为啥只能维护少量条件类型的价格?
SAP MM 采购信息记录里的Automatic Sourcing 之二
SAP MM 采购信息记录里的Automatic Sourcing 之二
SAP MM 采购信息记录里的Automatic Sourcing 之二