sap开发语言_企业SAP盲目上云的巨大风险和挑战

今天的SAP是相对封闭的，然而他又是开放的。

40年前，五位德国技术硬核工程师，看到了依附于硬件上的应用层软件的巨大商业价值，并一手创立了SAP。

在ToB这个相对封闭的领域，面对不同的产业链条和细分行业，SAP推出了自己独特而又领先市场的解决方案，帮助这些企业管理业务流程。

拥有独特而又领先的行业解决方案，以及特别的ABAP语言。

而开放的是合作生态。无论是硬件厂商，还是实施伙伴，在这个相对封闭的生态下，大家关系处理的和谐又开放。

战略的变化从收购Sybase数据库开始，接下来SAP有了自己的HANA数据库技术，现在他又迈向了“云”的征程。

无论是“七朵云”的悉数亮相，还是收购Qualtrics并大打“体验经济”牌，市场的表现和云模式收入的大幅提升，则已经表明SAP彻底完成了“云转型”。

1.

SAP之前立下了巨大的Flag，而距离2025年的日子也不再多。

详见《倒计时：距离SAP停止老产品服务还有2469天》

面对2025年SAP为所有用户设定的最后期限，越来越多的企业自己或者借助MSP，正积极努力向HANA迁移。

而很多客户也借助这个机会，开始将SAP向云迁移。

“上云”是一件非常潮流的事情，当然“上云”带来企业价值实现的加快和客户服务的创新，也是能够帮助企业获得额外回报的。

虽然IaaS平台提供了比本地基础架构更具动态性和扩展性的潜在能力，但许多SAP的用户也正在慢慢意识到，在云上运行和监控SAP以及云业务管理与改善的缺失，也会带来了一系列严峻的挑战。

企业如果您的企业，没有意识到并解决SAP迁移上云的一系列挑战，那么很可能会付出昂贵的代价。

到那个时候，别怪我们没有提醒你！

2.

从OP时代走过来的人，都知道流畅和稳定的SAP系统访问，对有着庞大业务流转的大型企业，意味着什么。

因此，对于企业SAP生产环境的持续性的指标监控，尤为重要。

就像之前提到的，无论是开发语言，还是特别的数据库，SAP是相对封闭的体系，获得对系统的洞察，是需要专属的SAP性能及业务流监控解决方案的。

但是，无论是Microsoft Azure，Google Cloud Platform (GCP)，Amazon Web Services (AWS)，还是阿里云，这些IaaS云厂商目前无法深入了解SAP系统。

而这些云供应商，只能提供基于操作系统的底层指标的监控工具，比如CPU和内存使用量以及文件系统占用空间展示等。

对于系统工作业务流、用户活动、后台批处理作业和事务、更新记录等，明显一概不知。

无法深入理解SAP系统的逻辑，从伸缩性的角度考虑，这些云平台上的监控最多只能指导计算资源的上下伸缩，保持系统硬件资源与实时终端用户访问需求的简单同步。

要知道，SAP系统终端用户经历的等待时间，可能是因为互相依赖的业务流程队列，而非系统资源瓶颈问题。

而在云上的业务应该如何构建和优化，迁移升级和整合上新，在云上又该如何操作，或许对很多企业来说，还是未知数。

组织是无法承担巨大的业务流程延迟和流程停摆带来的巨大损失的，这些问题需要提前扼杀在萌芽状态。

就像OP时代一样，SAP系统跑得慢，并不一定加两根内存条就能解决，企业业务调整带来的系统扩充或升级，也不是多买两台服务器就能搞定的。

3.

很多企业觉得迁移到云就能节省IT支出了，殊不知如果不根据实际情况，智能及时的调整云资源占用量，企业将会花出去很多冤枉钱。

而这些云计算供应商，没有专门为SAP系统构建专属监控工具，是无法正确判断系统的真正性能及运行情况的，因此云平台的自带的那些自动伸缩功能，也将无法准确运行调整资源分配，真正为客户提供降低成本。

云计算供应商是无法直接给企业带来系统效率提升工作的，企业必须自己思考如何来处理。

而识别出导致问题的原因，哪些是硬件性能的制约，哪些又是特殊时段的流程队列或者周期性后台批处理，显得尤为重要。

这个时候，就需要一套智慧的监控体系来动态的调整云系统资源的分配占用。

更重要的是，对于复杂基础IT架构的大型企业，只有使用优秀的SAP系统性能管理与监控服务工具，才能在一个应用或者视图中，统一管理SAP的混合云或多云的系统架构，而不是通过每个云供应商的自身平台，或OP系统后台，满足监控需求。

另一个问题就比较要命了。

即使使用了云供应商提供的自动云扩展伸缩功能，在闲暇时系统会自动调节或关停一些应用服务器资源的分配，这也可能会破坏系统甚至导致数据库信息的丢失。

因为，SAP需要优雅而且有条理的进行关闭，简单的“shut down”只能给复杂的企业级应用解决方案带来灾难性后果。

而从错误的关机中恢复数据，也可能要了你的老命。

4.

众所周知，将SAP从OP迁移到可信的云平台上，在现代企业竞争中借助云的力量保证企业优势，被认为是一种值得冒险的必要举措。

通过SAP和云管理，能够有效改善企业的业务成果，但带来的风险也让CIO等承受了巨大压力。

要知道，核心上云的不止是一套系统，不只是去掉了底层的硬件，更重要的是包括服务管理流程、业务运作体系的全面适配云。

供应链管理、运输管理、客户关系管理、费用报销管理、人力资源管理，应该怎么搬上云？上云后怎么理顺？交叉数据如何集成？新的跨国分公司或者BU拆分合并，应该怎么做？

如果引入了IoT设备和工业4.0，变得更加复杂的IT基础架构，能不能在云上吃的开？

而一些基础的内部IT业务和流程，也将面对巨大的不确定性。

比如混合云模式下的多个系统，版本与升级管理流程的问题，系统配置调整或者开发发布，该怎么系统化管理。

因此，很多企业决策层，对于上云有巨大的顾虑和恐慌，云迁移的焦虑来源于企业“安全感”与“控制感”的严重缺失。

因此，应用厂商在怂恿企业用户上云的时候，也要考虑这些具备“控制感”工具的提供或者第三方的集成，并培育或引入更多从业务流程或方法论角度，来“辅助企业上云”的合作伙伴们。

在这些伙伴的帮助指导下，企业才能构建上云的基础业务能力，树立上云的全面信心。

5.

综上，如果您的企业将SAP操作迁移到云上，而没有专门适用于SAP进行性能与业务监控的工具，那么很可能会为未使用的云计算资源花额外的冤枉钱，甚至埋下业务流程延迟甚至停摆的隐患。

另一方面，面对上云后可能会给企业带来的业务上的焦虑和不安，方法论和实操上有效协助，才能帮助企业克服困难，通过SAP和上云，实现真正的业务改善。

而两者缺一不可。

在《企业全面上云，MSP的营收即将爆发》一文中，我们提到了，在云的时代，越来越多的企业客户，将会选择并更加依赖托管服务供应商（MSP）。

而云服务托管MSP厂商，面对巨大的SAP客户上云的潜在市场，应该立即着手推出，针对SAP生态系统的CMP (Cloud Management Platform)和云性能监控解决方案，以及相关的配套服务，来帮助企业面对SAP迁移上云过程中的各种挑战。

国外已经有这方面的成熟企业出现，比如从OP时代就开始专注SAP系统监控管理，并陆续推出了对应云上监控解决方案的Syslink Xandria，以及他的Cloud Automation运维解决方案。

而国内，很遗憾，目前貌似还是空白。

就像《SAP运维生意的肉香味儿》一文中提到的那样，OP时代的生态闭环，在云的时代将必然会被颠覆替代，而新的市场机遇和合作模式也在慢慢形成！

- End -

往期精选 ｜ Editors' Choice

企业全面上云，MSP的营收即将爆发

SAP运维生意的肉香味儿

新世纪的SAP，在科技洪流中乘风破浪

在SAP标准实施中不起眼的“小”功能，居然融了3个亿

一家基于SAP的安全公司，做了6款实用的产品