Category Archives: Procurement Innovation

A Hitchhiker’s Guide to e-Procurement: Approvals, Part II

Mostly Harmless, Part V

Previous Post 

An introduction to approvals.

The last post addressed the approvals process and its link to the budget process and business workflows. This post will address the associated challenges of the approval process, some associated best practices, and the benefits that could be expected from an appropriate e-Procurement solution.

Common Challenges

  • Who Has to Sign Off?

    The supervisor, yes. But does it have to go to the department manager? The budget manager? The CPO? All good questions that lead to:

  • Long Approval Times

    While trying to figure out whether or not she can sign off and/or who else has to sign off, the requisition gets stuck in limbo on a supervisor’s desk(top).

  • Identification of Off-Contract Spending

    Chances are, to insure that the requisitioner can keep working, anything that looks reasonable will be approved, even though it might not be the contracted workstation or the preferred vendor. And even if the pricing looks good, this can lead to cost overruns since Procurement may have calculated TCO based upon end-of-year rebates for hitting volume targets.

Best Practices

  • Automated Approvals

    If the requisition is within the buyer’s spending limits, for approved products, from approved vendors, that are needed in the performance of day-to-day company operations, the requisition should be automatically approved. Manual approval should only be required if it exceeds an approval limit, budget limit, or is off-contract spend.

  • Budget Charting

    Not only should the e-Procurement application track the budget, but it should also track what’s been spent against the budget YTD and what’s been approved, but not yet spent, YTD and whether or not it’s inline with the quarterly/monthly forecast.

  • Visual BPM Workflows for Rule Definitions

    This makes it easy to see the approval chains and insure that not only are there rules account for all of the normal requests, but unexpected requests as well. The last thing anyone wants is for an approval to be redirected to an unchecked mailbox.

Potential Benefits

  • Faster Processing

    Decreasing the time it takes to get a requisition to the right approver decreases the time for an approval, rejection or a conditional approval dependent upon a requested modification.

  • Better Budget Management

    Getting the right requisitions to the right budget managers helps to insure that budgets are spent appropriately.

  • Reduced Maverick Spend

    Similarly, the budget managers can deny any off-budget or off-contract spending that is not essential to the business.

Once the requisition is approved, a purchase order is generated, which is the subject of the next post.

Next Post: Purchase Orders, Part I

Share This on Linked In

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

Mostly Harmless, Part IV

Previous Post 

Requisition challenges and best practices.

The approval process needs to vary depending on what is being ordered, who is doing the ordering, the budget(s) the order is being made against, and the approval limits of the requisitioner, her supervisor, and/or the budget managers. It can be as simple as an automatic approval if the requisition is for approved items from approved suppliers at contracted rates within the purchase limits of the requisitioner, to a multi-level approval process where the supervisor has to sign off because it’s above the spending limits of the buyer, where the budget manager has to sign off because it’s for IT equipment, where the department manager has to sign off because it’s an off-contract purchase, and where the CPO has to sign off because it’s over $10,000.

As a result, the e-Procurement system needs to not only allow for the creation, management, and tracking of spend against budgets, but also needs to support the definition of very flexible routing rules of varying priority that will not only insure that all parties sign off on a requisition before it is approved (and used to generate a purchase order that is sent off to a supplier), but that it is routed to the approvers in an appropriate order. In the example above, it should not reach the department manager until the supervisor and budget manager have signed off, and should definitely not reach the CPO until the department manager has signed off. The routing should be generated automatically upon creation based upon the appropriately ranked approval rules defined in the system (which will include an automatic routing to the supervisor for definition of the approval chain for any purchase order that is not appropriately covered by other rules).

The e-Procurement system will need to either maintain an up-to-date organizational chart, or integrate with the HR system that does. This way, general rules can be written in terms of supervisors, budget managers, and other organization roles. Otherwise, rules would have to be defined using individual users, which would make maintenance a nightmare.

When evaluating the approvals capability of an e-Procurement system, which might include budgeting support and rules management, one should keep in mind the associated challenges of the approvals process, keep an eye out for best practice support, and insure that the solution will deliver the intended benefits. These topics will be addressed in the next post.

Next Post: Approvals, Part II

Share This on Linked In

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

Mostly Harmless, Part III

Previous Post

An introduction to requisitioning.

In the last post, the requisition was defined as well as the information requirements that were associated with the requisition. This post will address some of the associated challenges of the requisitioning process, some associated best practices, and the benefits that could be expected from an appropriate e-Procurement solution.

Common Challenges

  • Creation Time

    It can take a considerable amount of time to create a multiple line item requisition when a user has to manually look up vendor codes, ERP/MRP codes, product codes, prices, etc.

  • Statement(s) of Work

    If the requisition is for temporary / contract labor, it can be a time-consuming and challenging process to construct the right SOW that will enable the vendor to identify the right resource.

  • Routing

    If the correct department / budget / product codes aren’t used, it can be difficult to route the requisition to the appropriate approvers.

Best Practices

  • Integration with core data systems

    ERP, Vendor Master, Catalogs, Punch-Outs, Marketplaces, and Networks.

  • Templates

    For standard BOMs, SOWs, and other regular purchases that can be quickly completed simply by filling in quantities, hours, and the few bits of information that vary from order to order.

  • Budget-Based Approval Process

    Requisitions are automatically routed to the appropriate budget manager if the request is beyond or outside of the budget.

Potential Benefits

  • Reduced Man-Hours

    Which frees up buyers to focus on more strategic cost-reduction tasks.

  • Faster Processing

    The right information not only gets the requisition to the right approver faster, but provides the approver with all of the information she needs to make a decision the first time.

  • Better Specifications and Statements of Work

    The use of templates written by experts will standardize and improve the requisitioning process.

Once the requisition is finalized, it begins the approval process, which is the subject of the next post.

Next Post: Approvals, Part I

Share This on Linked In

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

A Hitchhiker’s Guide to e-Procurement: An Introduction

Mostly Harmless, Part I

e-Procurement, while commonly used, is often misunderstood and confused with e-Purchasing, EIPP (Electronic Invoice Presentation and Payment), P2P (Procure-to-Pay), and even e-Sourcing. Thus, this brief guide will define what e-Procurement is, isn’t, and how it relates, or fails to relate, to e-Purchasing, EIPP, P2P, and e-Sourcing.

This guide will start with a definition of e-Procurement and then go on to cover the basic cycle. Along the way, it will discuss some benefits, challenges, and best practices while differentiating between the procurement of goods and services in the public and private sector when required. Finally, it will end with some advice on how to accurately cost a solution and determine the potential value such a solution offers.

Simply put, as per the e-Procurement Primer, eProcurement is the counterpart to eSourcing, starting where eSourcing ends and ending where eSourcing begins. It is the “e” implementation of the procurement cycle which is concerned with the requisitioning, receiving, and reconciliation of the received goods and services as opposed to the analysis, auction, and award that takes place in the (e-)sourcing cycle. It is essentially the automation of the non-strategic and transactional activities that consume the majority of a buyer’s time (that should be spent on more strategic value-generating activities), but one that comes with increased enterprise level visibility of all purchases.

The e-Procurement cycle, which can consist of up to nine steps (as defined in the doctor wants to remind you it’s sourcing and procurement), starts where there sourcing cycle ends and ends where the sourcing cycle begins. At a bare minimum, it will generally consist of an order, an invoice, and a payment. However, the process can also include authorization, goods receipt generation, reconciliation, tax reclamation, and analysis. Depending on the purchase in question, the (e-)Procurement cycle will generally contain three or more of the following nine steps:

  1. Requisition (& SOW)
  2. Approval
  3. Purchase Order
  4. Goods Receipt
  5. Invoice
  6. Reconciliation
  7. Payment
  8. Tax Reclamation
  9. Analysis

In addition, the e-Procurement process may also involve some regular catalog or contract management to keep catalogs and pricing schedules up to date between sourcing cycles.

The next set of posts in this series will explore each stage of the procurement cycle and the requirements that are placed upon any solution that claims to be e-Procurement.

Next Post: Requisitions, Part I

Share This on Linked In