How to Onboard Vendors to a B2B Business Network

What is the best way to onboard vendors to a Business Network? (ie. Ariba Network, Coupa Supplier Network, Basware Supplier Portal, etc)?

Before saying anything else, it is important to highlight that supplier enablement (network onboarding) is not a science but an art.  It involves relationships with vendors, is often dependent upon competing business imperatives and involves intentionally enabling the collision of many schools of thought on transactional sales and procurement processes.  These differing schools of thought between vendor and buyer are often hidden away in the depths of your Accounts Payable department who manually deal with exceptions when entering invoices.  Supplier enablement brings these exceptions to the forefront because it involves standardization, harmonization and automation.  Therefore, there is no one right way to go about it.  Here are a few guiding principles I believe should be considered when crafting a business network (ie. Ariba Network, Coupa Supplier Network, etc.) supplier enablement strategy, in order of importance.

0. Pilot Wave
As with any system implementation, you should start with a small subset of vendors to pilot your solution.  In this instance, you want to target 4-5 trusted vendors where good working relationships are in place, where there is a good mix of transaction types (services, materials, consignment, subcontracting, etc.) and there is a mutual benefit to setting up an integrated relationship.  With this subset of vendors, you will work through the initial bugs and problems to stabilize and strengthen your solution before ramping up the number of vendors enabled in each subsequent wave.  Having a good mix of transaction types is critical to ensure wide coverage of your current solution (business process hierarchy).

1. Transaction Volume
The value of supplier enablement lies in the elimination and automation of work; liberating resources to focus on strategic work or reducing your Full-Time Equivalent (FTE) instead of answering supplier queries on invoices or dealing with exception scenarios. Therefore, the main criterion that should be privileged when building an enablement wave plan is PO/Invoice transaction volume.  However, for vendors that have high transaction amounts (usually around 500 POs/year and above), suppliers will request direct integration with your business network (EDI/cXML Invoices sent directly from a supplier back-end system to the network) instead of having to log into the network and manually key in invoices. If your vendors pass this threshold and are willing to onboard regardless of this key point, you can forge ahead.  Just know that these suppliers will eventually come to the realization that they would like to integrate directly with the network to eliminate the manual work on their end.  If you haven’t managed this correctly, you can end up with a large backlog of angry vendors waiting to be fully integrated to your network.  This is covered more in-depth below.

2. Supplier Maturity
How mature is the targeted vendor from a process, system usage and back-end system perspective? Are you attempting to enable a vendor who is still sending manual or fax invoices or does your supplier have an EDI/cXML integration team ready to go already?  I usually try to put suppliers into four buckets: High Maturity, Average Maturity, Low Maturity, No Maturity

High Maturity – These suppliers are usually big players with fairly big volume.  They will want direct integration or nothing.  They are already billing you in an automated fashion so they will not settle for manual entry of invoices into the Network.  These suppliers should not be targeted first as your solution is not yet stable enough and you are therefore not ready for integration (and automation).

Average Maturity – These suppliers usually have medium to high transaction volumes but are still invoicing you “manually” meaning there is a manual intervention (keying in invoices, faxing you documents, etc) needed on their end and that joining a business network simply represents a process change as the amount of work remains about the same.  These suppliers will jump at the chance to win more of your business by integrating and are your prime candidates for the first enablement waves as they have important volume.

Low Maturity – These suppliers have low transaction volumes but are also excited at the prospect of integrating with you.  Depending on your process/system maturity after having conquered the “Average Maturity” suppliers, this could be the next tranche to attack.  If your process/system is very mature, then you would favor “Highly Mature” suppliers as you can support supplier integration activities and the day-to-day volume this entails without a problem.  If you still have lots of open issues at this fork in the road, focus on the low maturity suppliers.  They usually tend to have simple processes.  If not, you should find a new supplier with whom to do business with for these categories…

No Maturity/Very Low Volume These are your technologically challenged, never going to get better, suppliers that you must absolutely deal with because they are the only people that do what they do.  Either that, or they are a supplier with whom you transact a few times a year (ie. once a month).  In this case, you shouldn’t even attempt to enable them.  Most business networks have a “Light Enablement” functionality where an interactive e-mail is sent and the supplier can simply convert the PO into an invoice.

As you can see, supplier maturity comes after transaction volume in terms of importance but has a big impact on if a supplier is chosen for enablement at any point in time.  It is also often the criteria on which we have the least information at the outset.  Therefore, use judgement and gather information from your buyers to craft your initial supplier enablement lists but don’t be averse to changing them with new information.

Other Considerations

1. Supplier Enablement Wave Size
Waves sizes should consistently grow over time.  The principal risk with enabling multiple suppliers at once is that if there are generalized (or even many different local) issues, you must deal with a large swath of suppliers who all want their problem dealt with, right away.  If your Business Process Hierarchy (BPH) is well known and you can quantify your solution coverage with suppliers currently enabled (ie. 95% of my business process variations are covered by existing enabled suppliers), then there is little risk to enabling a very large number of suppliers at once.  However, most organizations have a hard time quantifying coverage.  The decision therefore becomes a “general consensus” type decision.  Rule of thumb is start small after your pilot wave (20-25 suppliers), and ramp up from there based on experience.  No two companies are the same and your targets will largely depend on how many total suppliers you have.

2. Solution Defects
Obviously, if you have open issues that prevent suppliers from being enabled efficiently, they should be differed to a subsequent wave, when the problem is resolved.  You should only automate a process once it is working perfectly when executed manually.  If you are automating a process where there is currently chaos, all you will end up with is automated chaos.

3. Supplier  Integration (EDI / Cxml)
To add to the discussion in the volume and maturity sections, don’t be surprised if your top 20% of suppliers by transaction volume refuse to be enabled until they can be fully integrated.  The workload of switching from automatically invoicing you to having to log into a portal is simply unrealistic for them.  Once you feel your business network solution is stable, these suppliers should become your top priority.  To ensure this process goes well, you want to have a standard, documentation supported, process to test your integration scenarios with suppliers to make this process as seamless and quick as possible for suppliers.  You should also aim to have your business rules documented and validated by suppliers at the outset (ie. what types of charges do you accept at the header level? Line item level?).  This prevents starting integration only to realize that there are irreconcilable differences with supplier processes that will significantly delay integration because of required design changes.  Depending on your architecture (ie. if you or your supplier have middleware software in the equation), this may be less of a concern.

Conclusion
All in all, just remember that the overall goal is automation and that automating a chaotic process will ultimately result in automated chaos.  You are better to add process optimization and measurements to the scope of your supplier onboarding initiative rather than simply measuring your team by number of suppliers enabled.  This will ultimately lead to a concrete bottom line impact vs. trying to blindly enable all your suppliers as fast as possible.

Your initial supplier enablement lists will change. Continuously.  This is a normal part of the process as you learn more and more about your vendors, their capabilities and your own.  Supplier Enablement is a journey and needs to be viewed as such by your project and management team to be successful. By considering the above points in your approach, you will ensure better results.

– Joël
———————————

What have your experiences with business network supplier onboarding?  Would you add any criteria that I’ve missed?  Have you been able to get to 100% of vendors enabled?

If you liked this post, why not Subscribe

A Perspective on ERP/Procurement System Commodity Codes

I was recently asked about my take on how to configure material/system commodity codes in ERP/Procurement systems.  Here are my main takeaways from multiple implementations of a set of commodity codes.

When implementing a new Source-to-Pay solution, you can usually either put in your own hierarchy or use a standard nomenclature such as the United Nations Standard Products and Services Codes (UNSPSC). For companies that have refined their own nomenclature in legacy systems over time to have a really good, industry/business specific list that is fine tuned for their context, I advise against trying to convert to UNSPSC because the benefit is marginal in comparison with the change management impacts this will inevitably bring on. The principal benefit to using a standard like UNSPSC is that you are using a common language with the outside world.  This may make your Business Network Vendor Onboarding process a bit easier as you won’t have to maintain UNSPSC to custom commodity code mappings but the majority of your vendors are not maintaining this data for their products.  The real value of commodity codes is use within the company’s walls therefore you always have to consider how the data will be used later in the process to determine the best way forward.

To illustrate, here is what I view as the most important points to consider when selecting your commodity code nomenclature – the underlying assumption being that the commodity code is a set of data which should serve and be owned by procurement:

1. How are your Sourcing teams and Category Managers organized?
At the very least, you want to be able to segregate purchasing and invoicing data by responsibility.  This enables reporting by category manager / procurement stream for performance tracking and RFP/go to market planning.  In addition, if you can get to a granularity level where you can filter within a category to sub-categories of products which you can convert to lists with which to go to RFP, than a further granularity level adds value.  But beware, complexity is the enemy of efficiency if not mastered by your team.

2. How detailed do you want to get in your spend analysis?
How fragmented is the current spend environment in the company?  Other than satisfying borderline OCD analysts like myself with more data, what are the tangible/intangible benefits attached to going down into further levels of granularity than, for example, “writing instruments” for everything you can write with that is purchased?  I am much more of the opinion that if your maturity is low, you should start out with a simple, effective nomenclature to address your big buckets of potential savings and that you can elaborate more detailed commodity code levels for areas of spend that require it when your sourcing organization gets to higher maturity levels.

3. What else will the commodity code be used for? (ie. Search, Process behavior, accounting)
If you are leveraging a commodity for for things like search (which is often done for MRO), then this can sway your nomenclature towards being much more complicated and precise so as to enable maintenance technicians and planners to find the right parts for example.  Personally, I think this is a perversion of the commodity code and that the data to enable search should be captured in the material number nomenclature or in a classification mechanism (such as in SAP ECC where you assign classes and characteristics to material masters).

If you are using commodity codes to drive different processes (in solution enhancements or configurations), then you may get your hands tied later on when you want to make changes to this commodity code structure as configuration or blocks of code will require modifications before you can change your commodity codes.  Therefore, be weary of mapping to these.  However, that being said, it is sometimes the only valid discriminator to route a process.

If you are using commodity codes to default accounting for non-stock purchases, then you may want to bring the chart of accounts into the fold when designing your nomenclature.  Usually, you will only be able to map a single General Ledger (GL) account to each commodity code so this has to be considered in the design.  Usually the business will opt for adding complexity to the commodity code structure instead of simplifying the GL structure but it’s always a valid fight to fight!

In short, it doesn’t really matter which nomenclature you use… As long as you have a single, common one in your organization and that it serves your purposes while being as simple as possible, you have a good commodity code nomenclature policy.  People will stop spending time arguing about which codes should be included/excluded, which codes new materials should be mapped to and which configurations/developments need to be changed and will spend more time doing what you need them to be doing which is cultivating potential savings with sourcing activities.

– Joël
———————————

What has been your experience with commodity code nomenclatures?  How does your view differ from mine?  Have you seen any organizations benefit from tremendously granular commodity code structures?

If you liked this post, why not Subscribe