Daily Archives: July 12, 2010

Good Supplier Performance Management Starts With Performance Analysis

As per a recent article over on ChainLink Research, a diversified international manufacturer discovered that real improvements happened once it made performance information available quickly and easily to both buyers and suppliers, and then based buying decisions on that data. This was accomplished through a centralized tool that supported real data analysis. Every week the tool pulls all of the relevant data from the manufacturer’s various systems (ERP, MRP, factory management, etc.) into a single repository where it is mapped against a common data structure that can be sliced and diced as required by a commodity manager that needs to see productivity, quality, delivery performance, and spend data for the supplier by site, part number, or business unit, etc. This allows the commodity managers to see if they have been rewarding suppliers who were easy to work with but performed below par, or not rewarding suppliers who were perceived as not being easy to work with, but performing above par. As a result, behaviour changed quickly.

And once you have all of the relevant data available in an analysis tool, you can find unconventional uses that can benefit the organization. One example given in the article is when the CEO of the diversified manufacturer was negotiating with a senator. The tool allowed the CEO to quickly find out how much business was being done in the senator’s state and put together an argument regarding the firm’s contribution to the economy and local business. This is powerful information when lobbying for loans, tax breaks, or other economic incentives, which are often necessary when trying to expand the business in a rough economy.

A Hitchhiker’s Guide to e-Procurement: Requisitions, Part I

Mostly Harmless, Part II

Previous Post

A requisition is a request for a product or service in a written form. With respect to e-Procurement, it is generally an electronic request for a product or service in a standard form, which may or may not use standard product or service codes from either the organization’s ERP/MRP systems or the supplier’s (e-)catalog.

While the concept is simple, the reality can be quite complex, especially if the requisition is for a large BOM (Bill of Materials) that requires multiple products and services from multiple suppliers, as different types of identifying information and specifications can be required for each line item.

The requisition needs to be able to capture a significant amount of information. In addition to the following core information:

  • requisitioner
  • department, division, and/or organization
  • request date
  • requested delivery date
  • delivery location
  • line items, each of which requires:
    • organizational product/service code
    • supplier product/service code
    • quantity
    • price (from the contract, schedule, or catalog)
  • etc.

The requisition may also need to capture:

  • supervisor
  • budget manager(s)
  • AP contact
  • delivery contact
  • product description(s)
  • itemized Statements of Work (for services)
  • etc.

As a result, the requisition needs to be very flexible and capable of being augmented by the buying organization as needed. Furthermore, it needs to be able to extract information from the organization’s ERP/MRP system, vendor master, contract system, and catalog(s), punch-out(s), and/or marketplace(s). As a result, it must either support easy integration with these systems, or (one or more) standard XML input and output streams (and cache commonly used codes if the updates aren’t near real-time).

In addition, it has to be integrated into the workflow management system that handles approvals, m-way matching (against goods receipts, invoices, etc.) during reconciliation, and the data store(s) used by the analysis and BI tools.

When evaluating the requisition capability of an e-Procurement system, one should keep in mind the associated challenges of the requisitioning process, keep an eye out for best practice support, and insure that the solution will deliver the intended benefits, which is the subject of the next post.

Next Post: Requisitions, Part II

Share This on Linked In