In this post, I’ll discuss what B2B trading partner onboarding is and then why I consider it to be as much a human process as a technical one.
Creating the Processes
I’m going to define a B2B process as what happens to a message once it’s been accepted by the supplier of the service.
The image above attempts to show the bare bones of B2B interactions. The processing of the partner’s request (e.g., Purchase Order) is done in the process and then sent through to a back-end system. There is a level of security to ensure that the partner is allowed to send their request through to that process.
Now, the ability for a specific partner’s document to be processed is not what I would describe as part of the onboarding process because the process that the partner is using is hopefully as generic as possible.
In the real world, this is not always so easy, and some of the partner onboarding pain is in the process too; which I’ll show in a minute.
Connecting the Partner
There is certain information that must be exchanged when connecting the partner to the process. This information changes depending on how big the provider of the service is. If the provider of the service is a large company like a Walmart, then Walmart can dictate to all of its partners the connection details of the service (Walmart is the kingpin in this case). However, if the provider of the service can’t dictate the terms of the partner communication, then they have to be more accommodating about what types of communication types they will accept from their partners.
In real terms, communication between partners and process includes such things as:
Network Communication Protocols
This is the physical process of connecting. So, things like whether the communication is over FTP, HTTP, SOAP, REST etc. come into play here and what those details are (e.g. IP addresses). In an ideal world; we’d all use the same protocol, but the reality is that documents are often transported using FTP and HTTP.
Security
Once the specifics of the network have been worked out the partner is enabled for security (e.g. perhaps share public and private keys) or perhaps set up an area on an FTP server that only they can access.
Document Type
Once all that has been figured out and agreed then the actual document type has to be considered. Again, if you’re a Walmart you might be able to dictate that all your partners communicate with you using ANSI X12 only. Whereas if you are a smaller provider of a service, then you may not be able to narrow down the formats so much and you may need to conform to whatever your partners use today with their other suppliers.
Partner Portals
Quite often, in B2B systems, the partner wants to have insight into how their request is progressing. In such cases, a partner portal is enabled which fronts the process so that the partner has access to that information. Such portals need to be configured so that each partner sees their own specific data.
Mapping
Previously, I said that the process at the backend sometimes needs to change depending on who the partner is. Often, in B2B systems, this is loosely termed as “Mapping.” However, there are other elements too.
Mapping refers to the transformation of the incoming document format so that they can be processed by the backend system. For instance: Incoming EDI to outgoing SAP IDoc. As I highlighted above, ideally we’d like all partners to use the same incoming document formats, but that simply doesn’t happen very often. Usually, partners will have slightly different documents that they are sending in, and these have to be mapped so that the fields they are specifying map to the fields that the process needs. This is why, in B2B, mapping is a big issue!
In addition to literally, mapping document formats, what can also happen is that different partners send in subsets of the document set. In these cases, it needs to be ensured that the process understands which partner sends in what type of document and handle any special cases.
