• Home
  • About Us
  • Contact Us
  • Privacy Policy
  • Special Offers
Business Intelligence Info
  • Business Intelligence
    • BI News and Info
    • Big Data
    • Mobile and Cloud
    • Self-Service BI
  • CRM
    • CRM News and Info
    • InfusionSoft
    • Microsoft Dynamics CRM
    • NetSuite
    • OnContact
    • Salesforce
    • Workbooks
  • Data Mining
    • Pentaho
    • Sisense
    • Tableau
    • TIBCO Spotfire
  • Data Warehousing
    • DWH News and Info
    • IBM DB2
    • Microsoft SQL Server
    • Oracle
    • Teradata
  • Predictive Analytics
    • FICO
    • KNIME
    • Mathematica
    • Matlab
    • Minitab
    • RapidMiner
    • Revolution
    • SAP
    • SAS/SPSS
  • Humor

Tag Archives: Interoperability

Calling My ERP Friends: Seamless Network Interoperability As The Next Evolution Of B2B Networks

March 17, 2020   SAP

Imagine you meet a new friend who you want to communicate with regularly. That sounds easy, right? But, instead of just selecting her name on your phone and contacting her, your telco provider says you first have to create a “flight plan” – a list of all your new friends sorted by 1) their value (meaning what’s in for you and your friend), and 2) the technical effort it takes to connect. Unfortunately, your new friend is No. 21 on the list. That makes her part of the third wave to be “onboarded.” But, even before the first wave, there has to be a pilot to test the best way(s) to get in touch with your friends. And, once wave three starts, a communication consultant will get in touch with her on your behalf to tell her she will have to contract with your telco provider before the two of you can communicate.

In private life, this scenario sounds crazy. In the world of B2B communication, this is how it often works.

In a B2B scenario, regular communication between trading partners is a key success factor. Sharing forecasts, commitments, production plans, stock-on-hand details, and end-to-end procure-to-pay communication avoids surprises and disruptions and ensures a high level of transparency, agility, and process efficiency.

For many years, one-to-one Electronic Data Exchange (EDI) for integrated electronic B2B communication as well as on-premises supplier portals was the state-of-the-art technology. However, technical setup, maintenance, and support costs were fairly high and, depending on the industry, prevented the technology from adding significant value for users.

Traditional one to one networks 1024x314 Calling My ERP Friends: Seamless Network Interoperability As The Next Evolution Of B2B Networks

Figure 1: Traditional, one-to-one connections between companies have reached a level of complexity that is difficult and expensive to handle. As a result, suppliers hesitate to introduce new connections.

In the past 10 years, multiple B2B collaboration networks have evolved. B2B collaboration networks are cloud platforms that offer multiple ways to connect and also support manual or electronic communication with the cloud platform. The key advantage of those networks is the ability to connect just once to communicate with multiple trading partners. Most of those networks have a focus area (either a specific business area, such as procurement or logistics, or a specific industry), and trading partners are fairly distributed across those networks.

cloud collaboration platforms 1024x428 Calling My ERP Friends: Seamless Network Interoperability As The Next Evolution Of B2B NetworksFigure 2: Cloud collaboration platforms allow a company to connect once and communicate with all trading partners on the network.

In order to drive value for the companies collaborating via such a network, the number of connected trading partners is the key success criteria. Unfortunately, convincing trading partners to join a new network takes months, if not years, because they have to connect to multiple communication channels, which drives process complexity and costs.

multiple collaboration platforms 1024x428 Calling My ERP Friends: Seamless Network Interoperability As The Next Evolution Of B2B NetworksFigure 3: Suppliers still must connect to multiple collaboration platforms (e.g., in case supplier C and D would like to collaborate with company A and B).

Consequently, suppliers and customers are heavily pushing network operators to connect their networks, enabling interoperability between the networks so the trading partners can stay on the network of their choice and still transact with all their customers. As a result, network providers can establish things like value-added network (VAN) tunnels and field maps between the networks so every message can be transmitted and translated easily from one network to another.

This approach shows incredible results in terms of supplier adoption and onboarding time. Furthermore, the rate of electronically integrated processes (driving process efficiency and compliance) is much higher compared to net new onboardings, which often start with web graphical user interface-driven, manual processes.

There are several reasons for success:

  • The network of networks (NEON) approach truly fulfills the connect-once promise. Besides some additional potential legal and commercial agreements, the supplier can continue to use its network of choice.
  • Companies have almost immediate access to all trading partners connected on the networks and can run robust B2B collaboration processes within a matter of days.
  • There’s no need to convince and educate suppliers in regards to how to connect to and maintain a new network.
  • Issues can be resolved quickly, as the network providers speak to each other directly.
  • There’s no need to build up additional backend integration for orders, forecasts, track and trace, etc., as a supplier’s backend systems (ERP, planning, engineering, etc.) typically would already be well integrated into its network of choice.

The flipside is related to the fact that there’s no standard method of interoperability. These network-to-network connections will always look different in terms of:

  • Technical connectivity protocols and formats
  • Business rules: Many networks will send out a reminder in case of an overdue order response or an alert in case a goods receipt does not match the original order. Those rules need to be aligned between the networks, so it’s clear who informs who in case of a disruption.
  • Electronic invoice compliance: In the event that both networks can create legal electronic invoices, one network would have to step back.
  • Support models: Support workflows could be different for a network A and B combination compared to a network C and B combination.
  • SLAs (e.g., response times, uptimes, etc.) and security aspects (e.g., support of International Traffic in Arms Regulations, or ITAR, compliance)
  • Commercial and legal aspects: For example, some networks charge suppliers, some charge customers, some are transaction-based, some are spend-based.

Last, but not least, while the technical aspects of the NEON approach can be solved quite easily, misalignments in terms of processes are harder to solve. Think about a supplier-managed inventory (SMI) process: It is fairly easy to technically share forecasts and stock levels, but it is more difficult to come to an agreement about process workflows, responsibilities, and liabilities.

Still, what we see in the market is that the benefits of connecting once overlay the potential negative aspects. There are more and more success stories of where a procurement and supply chain collaboration network interoperates with industry networks.

Making it as easy as possible for trading partners to communicate with their customers is the key success criteria to drive value in terms of process efficiency and working capital at minimal IT costs. Interoperability between networks is the next evolutionary step to enable companies to interoperate seamlessly, in just the way you would get in touch with a friend.

The Ariba Network is supporting the approach of network interoperability and established network connections to multiple industry and solution-specific networks so that customers not only have access to more than 4 million suppliers directly connected to the Ariba Network, but also to suppliers connected to other networks.

Let’s block ads! (Why?)

Digitalist Magazine

Read More

OpenStack’s next challenge: interoperability

October 27, 2016   DWH News and Info

Since its inception, OpenStack – the open source platform for cloud computing – has been out to prove that it is capable of hosting mission-critical enterprise workloads.

Earlier this year at the OpenStack Summit in Austin, it received just such validation, with analysts and customers agreeing that the platform is ready for prime time, as more than half of the OpenStack projects moved from proof of concept to production.

So what’s the next major goal for OpenStack?

The answer came at the OpenStack Summit in Barcelona, during the Wednesday keynote by Jonathan Bryce, executive director of the OpenStack Foundation.

According to Bryce, the next hurdle is application portability, not just between various distributions of OpenStack – there are easily three dozen of those already – but also, somewhat surprisingly, between OpenStack and third-party services like AWS, Azure, SoftLayer and Google Cloud.

“To me, it’s very clear that the future is multi-cloud,” Bryce said.

18339 IMG 20161026 094606 OpenStack’s next challenge: interoperability

Source: Max Smolaks, DCD

Interop Challenge at OpenStack Summit 2016, Barcelona

A rising tide

Six months ago in Austin, Don Rippert, IBM’s general manager for Cloud Strategy, Business Development and Technology, issued an interesting challenge – he asked community members to try and run the same applications and automation tools across as many different OpenStack distributions as possible.

The challenge involved deploying the LAMP stack – traditional foundation of countless online services – using Ansible and Shade, as well as running a Docker Swarm cluster.

In Barcelona, the challenge culminated in a live demo in front of 5,000 attendees of the summit. It featured representatives of 16 organizations, each running their own flavor of OpenStack or their own type of cloud service, and yet achieving the same result. This marked the first time someone has demonstrated the proof of interoperablebility among various OpenStack environments at such a grand scale.

Participants included AT&T, Canonical, Cisco, DreamHost, Deutsche Telekom, Fujitsu, HPE, Huawei, IBM, Intel, Linaro, Mirantis, OSIC, OVH, Rackspace, Red Hat, SUSE and VMware. And the instance deployed by Linaro was based on a 64-bit ARM server.

“When I talk to customers that are looking at OpenStack, or using OpenStack, or are really using any major open source project, they want three things that they think distinguish the open source approach from proprietary approach,” Rippert said.

“They seek additional innovation based on the community, and looking at the problem from a different direction. They expect better integration, since we each know what the code does and we can handle the code itself. And they expect interoperability – they expect that three vendors, five vendors, 16 vendors are all offering an OpenStack platform, and their workloads will run across all of those platforms.

“The one area of doubt, for our customers and some industry analysts, is interoperability. Will the vendors allow interoperability? Or is it in their best interests to make anyone on their distribution stay on that distribution?

“It is really not in our best interest. Because the way we gather momentum around cloud in general and OpenStack in particular, is by being interoperable. Yes, we compete with each other, all 16 of those companies up there, and we will continue to compete with each other. But you know, a rising tide gives us more surface area to compete in. We have all the reasons at IBM to think we can win more than we are going to lose, and I’m sure everyone on that stage thought the same way.”

In Barcelona, the OpenStack Foundation also announced continued progress of the ‘OpenStack Powered’ program, which requires relevant products and services to run interoperability tests in order to carry the OpenStack brand. There are now 46 products and services meeting such standards.

But the real interoperability work is yet to begin– the long-term objective for the community is to achieve a situation where customers can easily move their OpenStack workloads into proprietary clouds and back again. The key here is standard APIs. Of course, the OpenStack Foundation can’t force a company like Amazon to adopt its APIs, but if there’s a will, there’s a way – like the exotic solution recently developed by Platform 9 and described as “stretching imagination” by Bryce.

“Multi-cloud is not just about OpenStack clouds – it’s really about all of these cloud technologies providing the resources and capacity that users need to get what they want done,” he said.

“So I want you to think about APIs, think about multi-cloud, think about AWS and the different ways to tie those together. That could be a very interesting thought exercise, right?”

Let’s block ads! (Why?)

Colbran South Africa

Read More
  • Recent Posts

    • C’mon hooman
    • Build and Release Pipelines for Azure Resources (Logic Apps and Azure Functions)
    • Database version control: Getting started with Flyway
    • Support CRM with New Dynamics 365 Field Service Mobile App
    • 6 Strategies for Achieving Your Business Goals in the New Year
  • Categories

  • Archives

    • January 2021
    • December 2020
    • November 2020
    • October 2020
    • September 2020
    • August 2020
    • July 2020
    • June 2020
    • May 2020
    • April 2020
    • March 2020
    • February 2020
    • January 2020
    • December 2019
    • November 2019
    • October 2019
    • September 2019
    • August 2019
    • July 2019
    • June 2019
    • May 2019
    • April 2019
    • March 2019
    • February 2019
    • January 2019
    • December 2018
    • November 2018
    • October 2018
    • September 2018
    • August 2018
    • July 2018
    • June 2018
    • May 2018
    • April 2018
    • March 2018
    • February 2018
    • January 2018
    • December 2017
    • November 2017
    • October 2017
    • September 2017
    • August 2017
    • July 2017
    • June 2017
    • May 2017
    • April 2017
    • March 2017
    • February 2017
    • January 2017
    • December 2016
    • November 2016
    • October 2016
    • September 2016
    • August 2016
    • July 2016
    • June 2016
    • May 2016
    • April 2016
    • March 2016
    • February 2016
    • January 2016
    • December 2015
    • November 2015
    • October 2015
    • September 2015
    • August 2015
    • July 2015
    • June 2015
    • May 2015
    • April 2015
    • March 2015
    • February 2015
    • January 2015
    • December 2014
    • November 2014
© 2021 Business Intelligence Info
Power BI Training | G Com Solutions Limited