Procurement Function Overview

To understand the context of my procurement posts, which can often get very detailed, you need to have a basic understanding of procurement to build upon. Let’s take the tour.

The first place I like to start is the world famous Porter Value Chain as it is a good framework to use as a lens; I’ve drawn parallels from this model when examining the procurement function. Around since 1985, this thing has stood the test of time. A beautiful example that a good idea need not be complicated, this model aims to explain how companies generate a profit. The following figure illustrates this in the context of a manufacturing firm:

Quite simply, a company has primary activities which are directly connected to the creation of value for the eventual customer through warehousing, production, shipment, sale and maintenance of a good or service.  These primary activities are supported by secondary activities which, while not directly related to the product/service sold, also help create value for the end customer by optimizing the company’s activities.  This total creation of value is captured in the profit margin at the sale of the product/service to the end customer. Much could, and has, been written on Porter’s value chain but the important point is that without generating value for the customer, there is no way to generate profits. If I personally met Michael Porter, I’d want to debate the fact that he sees procurement as a support activity and not a primary one but that’s a topic for another post…

If we apply this same thinking independently to the procurement function, we should get something like this:

Before I get into the explanation of this model, let’s first define the parts:

  1. Sourcing

I define sourcing as the act of attempting to find a supplier that best fits a procurement need.  The need could be the lowest price possible, but it could also be to have the good/service for a certain date or which respects a specification (quality, size, etc). I divide sourcing into three parts strategic sourcing, tactical buying and ad-hoc sourcing.

Strategic sourcing involves deliberate procurement planning for a defined set of spend. It is usually driven as a project which includes multiple dependent steps and culminate in one or many RFx events (ie. RFI – Request for Information, RFP – Request for Proposal, etc). In very complex procurements where one supplier cannot supply all parts (ie. government ships, aeroplanes, etc.), this may be a huge undertaking. The goal of strategic sourcing is to lock in the largest, recurring, forecastable portions of the company’s spend according to the company’s priorities (quality, price, etc).  This creates the conditions needed for accurate financial planning of purchases.

Tactical buying involves running a quick supplier query process (usually something like a “3 bids and a buy” RFQ (request for quotations) for any spend over a certain threshold which isn’t covered by agreements negotiated under the strategic sourcing process. This activity is usually executed by a dedicated, expert team and captures value simply because of the rigor it provides (ie. call three suppliers and get the best price vs. buying from the first supplier you find).

Ad-hoc sourcing is usually done in organizations where the business units (ie. plants) can find their own suppliers.  This activity is simply the ungoverned connection of a supplier with a purchasing need, however this is done.

  1. Contract Management

This set of activities aims to formalize the value captured during the sourcing process in a legal contract and a back-end system compatible price list. Once the business is awarded to supplier(s) during the sourcing process, we then start the contract management process which cover the initial authoring of the contract, the creation of a machine actionable price list (ie. outline agreement in SAP which can be read by MRP – Materials Requirements Planning), the management of the contract lifecycle and repository & the contract amendment or renewal processes.

  1. Operational Purchasing

This stream contains the nuts and bolts of the purchasing process; meaning the creation of purchase requisitions by employees in different business units, the approval of these requisitions by approvers in the business units, the creation of purchase orders by a central procurement department (which ensures the purchases adhere to corporate policies and are compliant with the contracts negotiated above), the approval of purchase orders from a treasury (cash flow) perspective, the back-and-forth communications with suppliers and the receipt of goods.  Alternatively, if you don’t want to use a central procurement department organizational model, you can do away with the requisitioning process (ie. units can procure for themselves).  This is usually where processes get messy, complicated and complex. I include the subcontracting, vendor consignment processes as well as integration with inventory management processes in this stream.  Vendor business networks are also covered in this stream and the accounts payable stream as they serve as automation systems for these processes.

  1. Accounts Payable

This stream is home to the vendor invoice receipt and the payment processes. These could easily be inserted into the operational procurement stream of activities however, as it usually lies in the finance function’s operational scope, I separate it out for clarity.

  1. Firm Infrastructure & Human Resources

This stream represents the organizational structures that are privileged by the company to carry out procurement activities. There are integration points with the HR function in this stream.

  1. Spend Reporting & Procurement Analytics

This stream is present and permeates all streams in the procurement value chain. It represents the activities associated with the access to and enhancement of the entirety of the company’s procurement data regardless of the stream where the data is generated.

  1. Procurement Technology

This stream represents the governance and architecture of systems that support all procurement activities. This most likely involves integration points with systems used by other functions such as Enterprise Resource Planning (ERP) systems.

  1. Procurement Master Data Management

This stream encompasses all the data governance and creation/modification activities around procurement master data. Who requests, approves and executes the requests affecting procurement data within the company? In an SAP ERP system this would represent the governance and execution activities around vendor masters, purchasing info-record, outline agreements, source lists, quota arrangements, material masters, etc. I also include vendor risk and performance management processes in this stream. I separate this stream from technology because data needs a special, dedicated consideration. If your data is of poor quality, it will paralyze the function’s ability to generate value.

Now that you understand the different parts of the procurement function, primary activities are the ones that directly contribute to the ability of the procurement function to create value for the business (whether that means lower Cost of Goods Sold (COGS) & prices, certain quality levels, deal terms and conditions or precise delivery dates, etc.). Support activities are the ones that support the primary, or “core” procurement activities. The business (or rest of the company) is the procurement function’s primary client and value needs to be the primary output of the procurement function. Value also needs to be defined in the business’ terms – A procurement function is of little value if the business values quality of product, but delivers cost savings instead. Suppliers can also be viewed as clients of the procurement function depending on the type of relationship the function has with them.

There you have it. In a nutshell, that’s procurement. Of course, I’m over-simplifying here but that’s what the rest of this blog is for! There are also many other ways to model the procurement function, but this is the most complete (and satisfying) I’ve come up with during my time in the industry.

Happy reading,

– Joël

What other ways have you seen the procurement function modeled? Do you believe pieces are missing or should be removed? Do you agree with my segregation of primary and support activities?

If you liked this post, why not Subscribe

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.

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