采购技术
SAP和Ariba云的震动- CPOs需要知道什么

SAP正在重组其云业务。或者云技术正在动摇SAP。在执行董事会层面支持HANA的Vishal Sikka和在SAP云业务部门仅任职数月的总统Shawn Price都已离职(见新闻报道)在这里而且在这里).虽然与我们交谈过的许多SAP内部人士对Vishal的离开有不同的看法——尽管他的离开显然代表着ERP巨头的重大损失——但Price迅速离开背后的理由引发的问题比它解决的问题要多得多。这也让人们对网络和云应用程序在SAP内部的基本作用产生了疑问。

有了新的结构,将真正分为三组:技术、数据库和应用程序。云现在是应用业务——或者是应用业务的一部分。这是有道理的——SAP的云顶层领导不再需要,因为云已经隐含在SAP的整体战略中。当你有一个“金童”群体时,它会在内部产生怨恨。回顾一下CSC,我们中的一员(皮埃尔)在他职业生涯的早期工作过。CSC Consulting是在CSC母船内工作的混合IT/业务咨询集团,努力弥合大型IT交易和较小的以业务为重点的转型项目之间的差距。然后,CSC收购了Index Group,该集团由管理大规模业务流程再造项目的精英mba组成礼节当时。CSC指数成为了那个金童,但被宠坏了,最终的结果是文化冲突和灾难。有许多类似的故障(如EDS和A.T. Kearney)。回到SAP。

RIP:独立云

随着普莱斯的离开,独立的云业务将不复存在——至少作为一个独立的运营部门是这样。这就提出了一个问题:Shawn云计算员工中的其他人会发生什么?他的首席营销官蒂姆•米纳汉(Tim Minahan)是Ariba扭转局面的幕后推手之一,他专注于从战术上构建应用和网络业务的交叉点。失去蒂姆将是SAP的一大损失(至少在我们看来是这样)。

至于SAP客户的处境,我们有本地客户(是的,他们仍然存在)和云计算现在处于同一业务线上。但是客户仍然需要选择他们的应用程序套件(例如,Ariba应用程序套件vs. SAP遗留应用程序套件),正如我们所写的,它们是“松散耦合的”在这里

不幸的是,这个决定基本上仍然是基于您的技术应用程序部署偏好而强加于您的——而不是您的功能需求(正如我们所写的那样)在这里).通过收购和有机开发,应用程序的数量激增,而不是集中在一个真正的平台上,如Workday或Coupa或者更广泛地说,在真正集成平台中的任何公共基础设施组件堆栈上。

HANA数据库显然是SAP HANA云平台这是一种香草PaaS不仅允许客户端HTML5(SAPUI5)应用程序,也是最近发布的[测试版]基于云的HTML5环境.您可以更广泛地查看该平台在这里.现在,我们对采购PaaS的定义要宽泛一些。它不仅应该包括一个应用程序市场,还应该包括部署这些应用程序并将其集成到核心云应用程序的基础设施(如果有api,甚至还包括内部应用程序)。

SAP实际上有一个HANA云应用市场在这里有些是“与采购相关”的(在市场搜索框中输入“采购”),大部分是由SAP编写的,而另一些则是无关紧要的。我们最喜欢的是SAP落地成本应用程序。你可以“现在就买”67.5万美元(我们希望有一些优惠券代码!)

严肃地说,我们希望看到的不仅仅是市场,还有第三方开发者生态系统的附加应用程序。这可能会从SuccessFactors生态系统开始,因为它的代码比Ariba遗留代码更现代、更开放,而且您已经在其中看到了一些变化SAP HANA云平台支持SuccessFactors扩展还有一些技术讨论让它真正起作用。

至于Ariba,它的应用程序只是SAP的另一个“应用程序”套件——与SAP的其他采购产品相比,客户可以使用或放弃它(尽管销售代表说,考虑到他们推动Ariba的动机,至少直到最近)。

两个应用程序进入,一个云离开

有人可能会愤世嫉俗地说,SAP目前真正拥有的东西更像是有限公司.我们有共同基金——控股公司。我们不要诋毁Infor,因为他们的一些基础设施产品实际上做得很酷。也许将共同基金进行比较并不完全公平,因为这些基金最终都会持有同样的股票——HANA DB。但在表面之下,它仍然是一个碎片化的数据模型,无论应用程序移植到它的速度有多快。这就像给奔驰的每一辆车(不管底盘、轮胎、悬挂、刹车等)安装一个AMG涡轮增压器一样。毫无疑问,这是很好的营销,但要注意它的衍生产品!

当然,除了前云团队会发生什么之外,这还会引发更多的问题。对客户来说,更重要的是应用程序组中的SaaS/云应用程序与基础设施团队在何处以及如何结合。对于采购来说,最重要的是,除了将Ariba网络移植到HANA之外,Ariba网络还会发生什么,就像Ariba花费可见度(Spend Visibility)所做的那样(写得不错)在这里在星座公司)。

基本上有两种可能的结果:

1) SAP(和Ariba)网络变成了应用程序(也许会内置更多的业务逻辑)。如果是,网络应该驻留在应用程序组中。如果是这种情况,希望应用程序(和网络)团队将在HANA hip与基础设施人员连接起来,因为在这种模型下,网络将成为构建应用程序的平台。想想看:如果这能实现,类似paas的服务将会统治世界。但是,这对从业者和SAP都有一些潜在的严重影响。

2)网络成为共享的基础设施.但如果有,它提供什么服务呢?目录服务(例如,UDDI)?MDM服务?贸易伙伴/供应链网络建模服务?内容服务?BPM服务?分析服务?集成服务吗?PaaS在这里也很重要——更不用说应用程序开发服务的作用了(可能以一种方式插入从应用程序公开的api,同时也公开到应用程序)。 This is somewhat the old Ariba Network model (but more sophisticated and open). Dust it off? Perhaps. Or maybe tune it a little differently.

选择哪个选项?你不能两者兼得。但我们会挑选并提出建议。专业会员们:本周请查看我们起草的SAP剧本,因为B2B游戏正式开始了。

第一个声音

  1. Sabusa 说:

    非常感谢分享SAP Cloud系统的细节。

讨论:

您的电邮地址将不会公布。必填项已标记

这个网站使用Akismet来减少垃圾邮件。了解如何处理您的评论数据