Part 3 of a ten-part series that examines key operational aspects
of the so-called “Purchase to Pay” value chain
by Independent Contributor, Peter Alkema – Head: Purchase to Pay at ABSA
The request usually takes the form of a shopping
cart or requisition that allows the user to navigate catalogues (see
part 2 of this series) from which they can select items. The shopping
cart will then be routed through an approval workflow, which is then
converted to a Purchase Order once that approval is completed. “Usually
it is possibly to attach documentation to a shopping cart to provide
further information to the approver when evaluating the request. This
could be in the form of minutes, spreadsheets, scanned documents,
signature pages, etc. Any supporting documentation should be relevant
and supportive to the nature and content of the request”, Peter Alkema,
Head: Purchase to Pay, ABSA, told SmartProcurement.
In this article special consideration will be given to a number of different scenarios that give rise to requests for goods and services, and how these are handled in most procure to pay processes:
- Request for uncatalogued services
- Project related requests and approvals
- Electronic Purchase Orders
- Non-financial approval
Request for Uncatalogued Services
A significant portion of spend in large organisations usually goes to suppliers which offer services that cannot be catalogued on a purchasing system. Usually these are in the spend categories of legal and advisory, consulting and auditing. In SAP SRM, these are handled by way of a limit order which is an unspecified Purchase Order for a preferred supplier that has a maximum amount. When companies deal with suppliers in the above spend categories, often there will be a high level quote for the engagement, during which professionals from the supplier will be on site and usually working with a business team, which from the supplier’s point of view is known as “the client”.
In all cases, such an engagement will be preceded by an agreement on what the scope of work is, and the estimate from the supplier for how much it will cost, relative to an estimate for the number of man days required. This maximum amount can be used when completing the limit order for that supplier. The limit order goes through the same approval process as above, ensuring the governance of the proposal and agreement to scope of work is referred to on the purchasing system. It does not matter that the services are not pre-configured in the catalogue, what is more important is that the approval process has been followed in the normal way. With the Purchase Order number of the limit order, the supplier can then invoice the organisation any number of times up to the agreed limit amount, and the full purchase is both channel and supplier compliant (see part 1 of this series).
Project Related Requests & Approvals
Project related spend is significant in most organisations, and may also include professional services such as indicated in the above section. However, project budgets differ from line budgets in that this is funds which are set aside, usually approved centrally and for the specific purpose of achieving the project outcomes. In SAP SRM, the projects module can be used to create Work Breakdown System (WBS) elements, against which funds can be allocated for specific spend such as “Professional Fees,” “Hardware” and even internal charging mechanisms such as IT resources that are drawn from centres of excellence within the organisation. SAP SRM allows for the requesting of goods and services to be done either against a cost centre, or a WBS number that would link that request to a specific work package of a project. The pre-approved funds will already have been allocated to the project for use at the discretion of the project manager, but the approval process of that request on the purchasing system still ensures that the right supplier has been used and that the selected catalogue items, or limit order request fits the project needs.
Electronic Purchase Orders
An Electronic Purchase Order (EPO) will be discussed in more detail later in this series, but there are certain important aspects to consider for the request and approval stage of such a purchase order. Usually a pre-selected group of preferred suppliers will have been configured to receive EPOs, simply meaning that the exchange of invoices and Purchase Orders will be done electronically and by means of a daily batch process. This should be remembered during the request and approval process, since there is less control over EPOs as these types of vendors typically deliver very high volumes (often low value Purchase Orders) to the organisation and too much control will thus be inefficient. In the banking environment, branch stationery is a good example, as well as the logistics provider of branch commodities. Hundreds of EPOs are created every day by requests in the branches and once approved, these are batched and automatically submitted to the supplier every day.
The addition of a non-financial approver to the approver workflow is typical for the procurement of IT hardware either for use by employees (e.g. laptops, Blackberries) or as part of the technology infrastructure of an organisation. While a cost centre manager will have control over available funds in his department, and needs to approve the use of such funds, often there is the need for a technical approval that the right equipment is being purchased. This may be with reference to a pre-agreed “Technical Architecture”, as part of which some large servers are being purchased, which require confirmation that the specifications match the design. The cost centre manager will not have this knowledge, so the inclusion of an appropriate non-financial approver means that both the cost control and design approval is included in the Procure-to-Pay process.
Usually the agreement to purchase certain goods and services is, in principle, reached by an organisation through cost centre planning, project budgeting and other executive decision making processes. Too often, there is a very tiny auditable trail available on these decisions after the fact and it can be a lengthy and difficult process to unwind the decision making process when a lot of expense has been incurred and things have gone wrong. A purchasing system such as SAP SRM allows for electronic tracking of requests and approvals, which can reference such business decisions, but ensures that independently of attrition in an organisation, the governance and control evidence is retained for much longer. The operational procurement manager will need to think carefully about how to balance the need for efficiency with control in a spend environment, and how this is designed and implemented in the Procure-to-Pay process. Importantly, the design and usage of the requests and approvals process at the beginning of the chain will have an impact on the steps later down the line. These will de dealt with in subsequent articles.