Organizing your B2B Function for Success
Often when speaking with clients, the question comes up, “how do the most successful companies using a Supply Chain Operating Network (SCON) organize their B2B integration group? What’s the best-practice organization for my company?”
In this 4-part series of blogs, we will explore this topic and communicate what we at Elemica believe is the most successful way to organize the B2B function.
First and foremost, it is NOT about IT. Successful B2B organizations can be IT-savvy, but they are considered “part of the business” instead of “part of IT”. It’s an important distinction since in many companies IT is where programming happens, in an ivory tower somewhere, without much knowledge of the customer’s requirements or the customer’s challenges. The B2B group ,on the other hand, must work hand-in-hand with the customer and must understand the customer’s requirements very thoroughly in order to design, build, and test the company-to-company integration. They must also be held accountable to business-type goals such as increasing the volume of automated orders, rather than IT-type goals such as increasing the number of lines of code.
Quite often, the staff in the B2B group has previous knowledge of IT or even training and work experience directly in the IT function. That can be very helpful since it means they know the right questions to ask, the ins and outs of their ERP system, who does what in IT, they can troubleshoot issues in the mapping, and so on. That knowledge can be useful at times, although as we will see, a well-run B2B operation doesn’t necessarily need a lot of support from IT.
Many successful organizations place the B2B group in the Supply Chain organization, calling it the Supply Chain Center or the Supply Chain Center of Excellence. They work alongside the Customer Order Management team, often literally next door in the office to the Customer Support Rep (CSR) team, or with office cubes intermingled with the CSRs. That’s critical since most of their interaction will be with the CSRs.
The most common method that new B2B integration requests come into the B2B group is via the CSRs. The customer may send the request via their Sales person, but more often the customer will be used to dealing with their CSR on a daily basis, so they will send the request to the CSR. And even if the request goes first to Sales, Sales will often simply pass the request along to the customer’s CSR.
Once the B2B request is received, a best practice is for the B2B manager to determine whether the request originated from the business / Buying part of the customer, or rather simply from the customer’s IT department. In some cases, the customer’s IT may want to engage in a B2B project, but it turns out that the business is not really that interested, and time can be wasted working on an integration that the customer doesn’t really want. The B2B manager can often tell from the email chain associated with the request whether it originated in the customer’s IT, but if in doubt, the B2B manager can engage with Sales to track down the origin of the request.
Once the B2B request has been validated as having the support of the customer’s business team, best practice would be to log the new project request with the supplier’s Project Management Office (PMO) or other 'central project repository'. That action allows a PMO person to track all of the ongoing projects, and ensure that they will get the appropriate IT resources when needed. If any interaction with a service provider is needed, such as getting a B2B vendor’s Statement of Work signed, or requesting a purchase order to be cut, the PMO person would shepherd those activities through the supplier’s Procurement organization.
Okay, so now the B2B integration request has been received from the customer, validated as being a business-related request, registered with the supplier’s PMO, and appropriate B2B vendor paperwork has been taken care of. In the next installment in this blog series, we will explore what happens with the integration request after that point, entering into the design and implementation phases.