hello world

Onboarding new B2B trading partners – how complicated can it be?

One of the main challenges when it comes to B2B projects is the notion of onboarding new trading partners. I will not touch here on the technical mappingchallenges but on the management challenges of the onboarding process.

Who are the stakeholders and what do they entail?

Let’s have a quick look at the different internal and external stakeholders that are part of an onboarding process.

• The integration team responsible for implementing the technical integration,
• The operations team responsible for opening the enterprise firewalls to establish connectivity to/from the trading partner
• The business users responsible for defining and testing the implemented B2B integration
• A number of other backend application owners to which the B2B integration links with the trading partner (for example, the ERP team)

 

This has to be multiplied by two since the same stake holders must be involved from the side of the trading partner, as well.  In addition, for every new trading partner, there are a bunch of documents (mappings specifications, certificates and more) related to the onboarding process.

Although it can be simple technically, the onboarding process can be a lengthy project if not managed in the right way, because of the number of stakeholders and the alignment effort between them.

 

OK, so then what? How should we address onboarding?

Examining the above points, it is clear that there should be a clear methodology and practice vis-à-vis onboarding new trading partners.

From our experience at A.B Link Consulting, there are few do’s and don’ts when it comes to onboarding.

• Set clear timelines with your trading partners – All stakeholders, especially your trading partners must be aligned with clear timelines and milestones related to the onboarding process (testing, production rollout, and more).

• Parallelize your onboarding processes – You do not want to get stuck with an on boarding process that lasts forever, just because your trading partner has different priorities. What you would want to do is to parallelize the onboarding process and have a few processes (at least three) executed at the same time. Of course, the onboarding process that you define has to enable running parallel processes.

• Set an organizational process to support onboarding –  The process must have clear steps and responsibilities of the different onboarding tasks. One of the most recommended approaches is to create a virtual team with representatives from all different departments that will work together on the onboarding process. This will allow simple collaboration and alignment.

• Engage business users in the onboarding – Business users are a crucial part of the onboarding process. They should be engaged in different parts of the process. For example, in the supply chain, the retailer’s buyers should decide on the business aspects of the exchange with its suppliers. Questions such as can the supplier cancel an order or can the supplier split an order line (and so on) need to be addressed by business users.

In addition, very often, business users are responsible for conducting end-to-end testing, once the implementation is done.

 

• Don’t manage onboarding through emails –Onboarding should be handled like a mini project. I do not advise to use an overkill project management application (like MS Project), but there should be light-weight project management tools to streamline your onboarding processes. Informatica B2B Data Exchange has an Onboarding checklist module that facilitates light weight onboarding management functionalities that are needed.

“Managing” the onboarding via emails only will not allow you to scale, parallelize, or store related documents, etc.

To summarize, onboarding is definitely not only about technical challenges. A quick and efficient onboarding process requires a defined organizational process with clear responsibilities and milestones. A B2B Onboarding Project can be viewed as a series of small-scale subprojects where every partner is a subproject that needs to be executed in parallel. Each subproject has its unique flavors. The process at a high level, however, remains the same and is duplicated throughout. As a result, an onboarding checklist module as offered by Informatica B2B Data Exchange can be sufficient for managing the onboarding.

How do enterprise architects view B2B integration?

 

We have been talking lately to several enterprise architects in different organizations about how they view B2B integration. We have heard several interesting and completely different approaches to B2B.

Sentence #1: “ B2B Integration ? It’s just another interface.“

In this approach, to solve a B2B integration problem, all we need is to use our existing internal integration platform to implement the interface and add a robust-managed file transfer tool to handle technical connectivity beyond the firewall in protocols such as AS2, SFTP, etc.

This approach regards B2B as a technical problem, and, indeed, the only difference between this and standard A2A integration is the external connectivity.

We believe that this approach makes sense when there are limited B2B requirements or a limited number of trading partners. Investing in a solution that would do it all  may be overkill. However, when the B2B space is not limited to  a given organization, then this approach might present some challenges:

Usually, in this approach, the managed file transfer tool is not tightly integrated into the standard integration tool (if at all). Thus, both monitoring and management can be a nightmare. The most common, “I didn’t get the file, where is it?” problem would usually require searching through different tools in order to track down the problem.

In addition, internal integration tools are usually monitored in a very technical manner; that is,  a technical expert would be required to even understand the problem, not to mention fixing it. This can be a difficulty in B2B, as the person, getting the angry phone call or email from the partner that the file did not arrive, might understand the process and the data, but does not understand the technical implementation.

Sentence #2: “B2B integration? We need a dedicated solution for that?!“

In this approach, we acknowledge that in B2B there are specific requirements that make it not just another interface.

Things like trading partner management, quick onboarding, flexible change management, and   business level monitoring must be taken into consideration, and standard integration tools usually do not have built-in support. When looking into different dedicated B2B solutions, they are usually very good at “traditional” B2B standards, such as EDI and SWIFT. These tools were built to support those standards, and, indeed, they do it very well. For example, to create an EDI map from EDI to ERP format is probably very simple and straightforward.

This solution seems to make sense when the specific B2B requirements of an organization are only(or mainly) around these “traditional” standards.

The challenges start to appear when dealing with B2B exchange topologies that do not conform to “traditional” standards.

Sometimes, it is just not possible to exchange information using standards like EDI. In other cases, it is not the best approach to take.

To give a real example of a recent B2B implementation for a large retailer in Europe that needed to communicate with many of its small suppliers and exchange packaging information, as part of the supply chain process. These small suppliers had very small or no IT; thus, we could not use EDI. There was a need to design a user-readable exchange format that these suppliers could consume.

The solution was based on MS Excel. All the orders from the retailer to the suppliers and the packaging information from the suppliers to the retailer were communicated using Excel spreadsheets. From the B2B solution perspective , it required very strong translation capabilities to convert ERP data (where the orders initially came from) to/from Excel.

In addition, in this approach, we can easily develop an enterprise architecture where our B2B dedicated tool will perform numerous, similar integration flows as our internal A2A integration tool, as both tools would eventually need to interface with different back-end systems.

Sentence #3: “We need a holistic approach for B2B.“

The third statement tries to combine the two approaches above.

Here, the preferred solution would be one that would enable leveraging the strong integration capabilities of a pure integration tool, while adding to it the specific capabilities required when it comes to B2B integration. A true holistic solution should take the best from each of the above approaches and package it as one solution.

This approach should make sense for large organizations that are looking to leverage in-house knowledge and resources they have already gained from internal integration projects for B2B integration as well.

To be more specific, the “core” integration capabilities that are mostly needed in B2B are:

• Flexible Data Transformation – To  deal with non-standard data exchange and the emerging new standard that is XML based.
• Strong data quality functionality – This is significant in B2B (even more than in internal integration), because we cannot assume anything about the data being sent from the trading partners; thus, there is a need to carefully validate it.
• Reach backend connectivity – Data received from trading partners usually goes to various backend systems. Thus, there is a need to integrate with them in a simple and straight forward manner.

The specific “B2B Only” capabilities that are required:

• Managed file transfer – Ability to connect via different protocols with trading partners.
• Partner management a quick onboarding.
• End-to-end business level monitoring of the B2B exchange – In a simplified explanation, it knowing at every point in time what data had been sent and received from each trading partner is crucial when it comes to B2B exchange. The best solution in this regard is one  interface for a real end-to-end monitoring , including managed file transfer issues.
• Industry standards support – We cannot neglect traditional B2B standard support that will simplify B2B exchange in different industry standards.