When I first joined Lightwell, I was struck by how everyone discusses "onboarding." What was this magical and mystical thing? Why was it discussed in such reverential tones? Having analyzed this further, I'm still a little mystified as to why the hush tones but I'll put a few words down here about what I consider onboarding to consist of and why it's as much a human process as a technical challenge.
It's clear that onboarding of partners is where much time is spent in a B2B system. That's why business people consider it a large factor in their projects. Not only that, but I've found that the more technical people discuss onboarding related to the technical aspect only. Whereas, in my opinion, a lot of the onboarding process is actually about human interaction.
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.
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.
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.
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.
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.
Amalgamating all those elements together, we have the following list that onboarding encompasses:
Exchange of information
- What network protocols does the process support and network details (e.g. IP address)
- What document types does the partner support and any partner specific use cases
- What progress information and alerts does the partner expect about files they have sent
- Set up specific partner areas (e.g. FTP sites)
- Exchange public and private keys
- Expose credentials and partner specific areas to partner
- Alter process to handle partner specific document types or deviations from the norm
- Alter process to handle partner specific process use cases
- Configure partner portal to allow customer access
- Configure partner portal back-end to allow customer access
Communication, communication, communication
Although this may not sound like a lot of work for a single partner; the sorts of customers which I deal with have thousands of partners. So, just managing the sheer quantity of data being exchanged is a headache; never mind actually doing the work. What we also find is that the customer does not "speak the same language" throughout their organization.
So, the technical people may well know a lot about the IP settings but they may not understand the process that the Purchase Order is taking part in and so has to go into their organization to help us extract the information we need to configure the portal.
This is where B2B onboarding process automation comes in. A real problem here is more to do with handling the quantity of data and the people involved than the actual technical problem of e.g. sharing keys.
This is why I believe B2B partner onboarding is at least as much a communication problem as a technical one. Essentially, a good B2B platform needs a good B2B onboarding solution. It needs to speak the right language when dealing with the different partner employees and then translate those back into the language that the B2B solution understands. The onboarding process also must be clear as to where each partner is in the flow of getting connected to ensure that each partner is managed through the onboarding process and not lost in it.
If your partner onboarding solution provider doesn't have this process in place then think about looking elsewhere because you’re technical solution may well end up in trouble without the human process elements factored in.
Learn more about the B2B trading partner onboarding process and the value of improving it in the report below.
About John Hawkins
John Hawkins is the CTO for Lightwell.
He has extensive experience in the middleware and integration stack having worked at IBM, IBM Business Partners and WSO2.
During his time as an IBM MQ architect he led IBM's Cloud strategy and architecture for next generation, Cloud Centric, Messaging.
John is an innovator and naturally "sees the big picture" which he has demonstrated not only through his work at Lightwell and previous roles, but also his large patent portfolio.