B2B onboarding - A technical or process problem?

When I first joined Lightwell I was struck by how everyone discusses "on-boarding". What was this magical and mystical thing? Why was it discussed in such reverential tones? Having analysed 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 on-boarding to consist of and why it's as much a human process as a technical challenge.

It's clear that on-boarding of partners is where a lot of time is spent in a B2B system - that's why business people major on it as a large factor of their projects. Not only that, but I've found that the more technical people discuss on-boarding in relation to the technical aspect only (not that business folks aren't techie - but you get my gist I hope ;-). Whereas, in my opinion, most of  on-boarding is actually a human-interaction process. I'll discuss what on-boarding 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 basics of B2B 

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 partners document to be processed is not what I would describe as part of the on-boarding 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 on-boarding pain is in the process too; which I'll show in a minute.

Connecting the partner

There is certain information that has to 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 e.g. a Walmart, then Walmart can dictate to all of its partners the connection details of the service i.e. Walmart is the king pin. 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 Business to Business 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 back-end 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 in order that they can be processed by the back-end 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.

B2B onboarding pain points

Time spent

Amalgamating all those elements together we have the following list that on-boarding encompasses:

Exchange of information

• What network protocols does the process support and network details e.g. IP addr,
• 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.

Changes required

• 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 Portal to allow customer access.
• Configure 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 to work. What we also find is that the customer does not "speak the same language" throughout their organisation. So, the technical people may well know a lot about the IP settings but they may not understand the process that e.g. the Purchase order is taking part in and so has to go into their organisation to help us extract the information we need to configure the portal.

This is where 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 partner on-boarding is at least as much a communication problem as a technical one. Essentially, a good B2B platform needs a good on-boarding solution. It needs to speak the right language when dealing with the customer and then translate those back into the language that the B2B solution understands. It also needs to be clear as to where each partner is in the flow of getting connected to ensure that  each partner is managed through the process and not lost in it.

If your partner on-boarding solution provider doesn't have this process in place then think about looking elsewhere.