Category Archives: Procurement Innovation

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

Mostly Harmless, Part VI

Previous Post

Formally, a purchase order is a commercial document issued by a buyer to a seller that indicates the type, quantity, and agreed upon prices for one or more products or services that the buyer is offering to buy from the seller. Once the seller accepts the purchase order, it forms a (one-off) contract between the buyer and seller, who will deliver goods and services at the agreed upon prices, in the agreed upon timeframes, to the buyer who must then, upon receipt of the agreed upon goods, in the agreed upon condition, make payment to the seller for the agreed upon amount.

A purchase order is the result of an approved requisition, but the relationship is not necessarily one to one. One requisition can generate multiple purchase orders, and this will commonly happen when a purchase order contains requisitions for goods and services from multiple suppliers. And while normally there will be one purchase order per supplier, if the goods and/or services are coming from multiple locations, there might be multiple purchase orders per supplier. In addition, a purchase order might be associated with more than one requisition, as requisitions from multiple buyers for similar goods to a similar location may be bundled into a single Purchase Order to save delivery and processing costs. As a result, the e-Procurement system must be capable of handling the many-to-many relationship between requisitions and purchase orders (and suppliers).

In addition to all of the information tracked on the requisition, the purchase order must also track approval information, delivery information, payment terms, and any other specific information required by the supplier. It must support attachments and include any attachments, schedules, or statements of work that are specified as necessary in any contracts that are in effect.

Furthermore, since the delivery of goods and services will generally result in the production of goods receipts and invoices, the e-Procurement system must support the association of purchase orders with the corresponding goods receipts and invoices, which, like the purchase order and requisition relationship, can be many to many. If the order is large, or if some items are not immediately available, a supplier may ship the order in multiple shipments, which would result in multiple goods receipts and which may be accompanied by multiple invoices.

In addition to tracking all of the relevant information, the system must be capable of translating the purchase orders in the standard EDI and XML formats that are used by the primary suppliers and electronically delivering them to those suppliers who have networks, marketplaces, or another on-line presence capable of automatically receiving an electronic purchase order.

When evaluating the purchase order capability of an e-Procurement system, which should support tight integration with the invoicing module, one should keep in mind the associated challenges of purchase order management, 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: Purchase Orders, Part I

Share This on Linked In

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