虽然我们少一点资格写应用程序和平台相比,一些真正的极客技术人员我们知道,重要的是一般花重要的读者(采购和供应方面)的大规模应用和网络市场是如何改变了未来十年。这将发生在公司做出购买决定应用程序在他们的网络和平台构建——和/或结合的功能提供者提供特别定制的工具(例如,eProcurement)。
这是一个平台的出现或堆栈中心舞台——即使对于业务用户。从历史上看,大多数人在采购不关心底层平台解决方案是建立在。但有一个例外:一个解决方案可能会在某种程度上损害了被建立在微软技术和Java、Ruby或别的东西(我们都得到了,谢天谢地)。除了有偏见的软件公司,没有一个人——我重复没有一个人曾经买了一个采购技术基础上开发的。相反,功能、可用性、规模、经验、声誉、互操作性,以及许多其他因素在过去的技术购买决策发挥了作用。和微软的问题不再重要,谢天谢地。
然而展望未来,恰恰相反的是会发生。“应用程序”——而不是应用程序——将购买的平台(一种不同于过去的开发平台),和最好的平台(或达到最规模和范围)会出现的胜利者。这已经发生在B2C商务和成就感与亚马逊成为更广泛的平台商业游戏的赢家(现在延伸到融资、仓储、实现和其他增值服务),甚至不要提到它的亚马逊网络服务(AWS)云托管,和虚拟化功能。也是发生在移动世界,与苹果公司作为最重要的看门人开发者通过其应用程序商店界面(Android也因素这个论点和方程,虽然从不同的角度来看)。
然而,到目前为止,我们还没有看到公司在b2b或采购/供应链环境把平台决定提前购买应用程序,尽管不同的优势。这将改变比你想象的更快,我们相信,因为有了正确的“看门人”模式,平台可以确保所有的数据模型之间的互操作性,工作流和流程与应用(包括第三方和公司本身建造的平台。想象,例如,即插即用e-invoicing连接性,eProcurement、供应链融资、合同管理和相关应用程序的平台,不管哪个提供者建立单独的应用程序。
有些技术一分钟,这个需要一个外部化的面向服务的体系结构(SOA)的方法。就像我们写过去,以这种方式建立的一个平台有许多优点:
- 外部系统集成()——外部系统集成(例如,ERP)可以简化一个数量级在一套或一组应用程序,鉴于公共基础数据模型和简化的API / web服务集成的环境。集成也可以更好的与外部系统由于能够让第三方系统数据在应用程序
- SOA和Web服务通常是设计原则而不是被打了之后。这本身带来简单和简单的集成方法的套件。看到传统复杂的集成套件提供者一两个星期,而不是几个月
- 在平台套件集成(本身)。不要折扣开箱即用的好处,例如,集成的供应商管理和采购功能,是建立在相同的底层数据模型和体系结构,或那些本土特定平台生态系统
- 产品/模块之间降低集成成本。例如,项目或供应商主联系供应商门户集成,供应商管理工具集、供应商主(s)和物品的主人。这些集成成本非常重要对于multi-suite /工具集环境甚至procurement-related应用程序
- 以外的第三方应用程序和开发能力,使个人和组织(甚至客户)快速开发定制的“应用程序”,是完全集成在平台环境;包括应用程序开发的内部IT部门!
真正的平台方法通过网络将允许最适合供应商(为特定客户)在每个应用领域为顾客服务的平台上与一起工作的所有数据(例如,工作流,权限,匹配,验证,归档和同步发生在app-level以及网络中)。
作为一个例子,这样一个模型将允许一个公司的选择Coupa或Ariba eProcurement,Basware或ReadSoft e-invoicing CombineNet或BravoSolution采购,Aravo或Hiperos合作伙伴/供应商管理和SciQuest(上行)或Novatus合同管理和所有这些未来“应用程序”的互操作。它还将允许更小的解决方案与网络以及这些更广泛的功能的应用程序(如打折/付款,总成本建模、转让定价优化,风险提醒,等等)。
在这篇文章的第2部分中,我们将探索如何连接和多层组件这一愿景开始进入网络/平台工作方程,证明我们的企业变革的过程。
采购和供应链的领导人应该如何看待系统架构?花重要的专业用户也可以读:
讨论: