一个真正的单端到端平台或套件的好处是什么?

本周早些时候,我的一位同事提出了这个问题:构建在公共数据模型上的真正的单端到端平台/套件(这是一个真正意义上的平台,允许第三方通过开放api进行开发,甚至可能是一个已定义的配置/开发环境,允许第三方在其上创建自己的应用程序)的最终好处是什么?您需要开发人员吗,还是需要技术业务分析师?尽管我们之前已经讨论过这个主题,但我认为有必要列出端到端平台的所有好处。

Spend Matters的读者应该意识到这个列表可以扩展到几乎任何类型的业务应用程序或技术领域。它并不特定于采购或供应链领域。然而,在这个领域,端到端的平台很少。SAP、甲骨文例如,Emptoris和Ariba都出售一套解决方案,这些解决方案可能(也可能不是)紧密集成,但肯定不是在单一平台环境中构建或交付的。事实上,在SAP的情况下,平台的扩散(包括内部和合作伙伴)已经导致了至少五个独立的平台,甚至在Ariba在交易完成后将带来多个独立平台之前。

在今天的采购部门,我们所知道的端到端单平台/套件模型包括b-pack,IvaluaIntenda解决方案套件(所有领域都包括支出、采购、合同、电子采购、电子发票、供应商管理等)Coupa正沿着这条路前进,但在P2P之外的功能空间有限。的情况也是如此Zycus.trade移可能最接近于建立一个真正的平台商业模式的愿景,其他人可以在此基础上在更广泛的采购领域中构建额外的功能,但他们的功能范围目前非常有限,仅局限于电子发票、买方/供应商P2P连接和文档交换。

无需进一步分析,以下是单端到端平台/套件环境的集成好处:

  • 集成(外部系统)——外部系统集成(例如ERP)可以在一个套件中简化一个数量级,给定一个公共的底层数据模型和简化的API/web服务集成环境。整合也可以是更好的因为能够在应用程序的任何地方公开第三方系统数据
  • SOA和Web服务通常是一个设计原则,而不是在之后强加于人。这本身就为套件带来了简单的集成方法。套件提供商认为传统的复杂集成只需要一两个星期,而不是几个月
  • 内部分析师在配置解决方案方面拥有更大的权力,而不需要开发资源来进行配置、定制和集成(即使在集成了多个套件的SaaS功能的情况下,当需要第三方系统集成和链接时,也更可能需要开发和集成资源)
  • 集成(在应用程序套件本身内)——这就足够了。不要低估开箱即用的好处,例如,集成的供应商管理和采购功能是建立在相同的底层数据模型和体系结构上的
  • 减少采购模块之间的集成成本——例如,连接供应商门户、供应商管理工具集、供应商主和项目主的项目或供应商主集成。在多套件/工具集环境的情况下,即使只是在与采购相关的应用程序中,这些集成成本也会非常大
  • 单一数据模型和单一供应商主组合——当降到项目级别进行支出分析时,这是一种神圣的支出圣杯。只是不要在不知道自己要面对什么情况的情况下就牺牲自己
  • 跨模块的开发速度——通常是更快的发布时间表,以及每个版本更强大的功能增强(集成)
  • 一种灵活的配置方法是可能的——让用户全程参与。新的产品功能需要几个小时或几天,而不是几周或几个月,为客户带来灵活性,并适应快速变化的世界经济场景
  • bug消失——通常是在单个套件环境中升级过程中的bug减少(并且更快地消灭)
  • 升级速度和升级到未来集成套件版本的便捷性
  • UI一致性和导航超越了单点登录——这在集成工具的情况下可能发生巨大的变化,这些工具看起来是一个套件,但实际上是构建在多个平台上的,特别是在工作流和数据模型/映射方面
  • 在模块之间的拼装(特别是流程或工作流拼装)上不浪费时间
  • 网络宽度和基准测试智能(在基于云的端到端平台的情况下)跨套件
  • 第三方应用程序和开发能力——使外部个人和组织(甚至客户端)能够快速开发跨平台环境完全集成的定制“应用程序”。如前所述,《贸易转移》便是这种模式的理想原型
  • 部署不可知论者。在云中部署,在您自己的云中服务器上部署,在防火墙后面部署,或者以混合方式部署。真正的端到端套件和平台提供者并不规定部署模型,它们遵循您的业务和IT策略。请注意,很少有端到端套件也采用真正灵活的以平台为中心的部署方法。大多数人痴迷于云部署,因为这是估值所在
  • 您并不完全依赖于您的套件提供者的路线图和bug修复版本。它可以在现场快速有效地进行。真正的单一平台提供商为您提供保持版本、站点特定更改和升级一致的工具。您不会丢失升级路径

我确信我们错过了真正的端到端集成套件和平台的一些好处。如果你有什么要补充的,请插进来!

——杰森·布希

在Procurious分享

的声音(2)

  1. Jay Merenda:

    我看到的套房供应商的问题是,“最好的套房”从来不意味着“最好的品种”。据我所知,供应商在SIM、SPM、风险管理、支出分析和真正的类别管理等关键领域缺乏良好的功能。在我的圈子里,我看到更多的是在关键数据(例如干净的供应商数据)之间同步的情况下转向最佳繁殖。我不认为一个普通的UI是一个驱动程序,因为Best In Breed通常非常直观,用户基础通常不同。

  2. 约翰·肖

    我想补充一点:

    通用命名法便于采用:每个软件应用程序都使用不同的逻辑概念为业务思想建模,并遵循自己的标准。当UI、关键术语和通用功能在各个模块之间是相同的,你就降低了用户必须接受培训的内容数量(例如:搜索在任何地方都是一样的),并且你最终减少了你试图在组织中引入的更改数量,因为模块之间的差距要小得多。

    约翰

讨论:

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

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