Best Practices in Procure to Pay Cycle: Reduce Complexity in Catalogs and Buying Channels – Part 8

PART 1 PART 2 PART 3
PART 4 PART 5 PART 6
PART 7 PART 8 PART 9
PART 10

Many of the experts also emphasized the need to reduce complexity both in the interface systems through pre-defined procurement buying channels is critical to improving the entire P2P cycle. There is no need for users to have multiple channels for procurement. However, establishing the credibility for users to only be able to use these channels also requires significant management support.

Three and a half years ago – there were a limited number of catalogs that could be accessed. We decided to host a bunch of catalogs on SAP, running from office supplies to MRO parts, in a catalog system. When I left – many were up and operational on the system. The order entry catalog controlled by Gillette makes it easy to track, and shortens the loop.

The end user does the requisition when there is a scope of work on the requisition. The requestor works with sourcing people to ensure that there are requirements. Once it is approved, the PO gets generated, they perform the work, and when the invoice comes into AP – notification goes back to the end user that there is an invoice against the PO – and they have to cut a receipt. All of this is done online. There are still glitches, however. Every once in a while when somebody leaves the company, then the email has to go to the next person in charge, and you are tracking back. For example on copier leases, it is a nightmare! People would lease machines, with blanket PO’s for 3-4 years, and you would lose control. You would be invoicing against blanket PO’s for years, and you might be paying for a copier that they took out 6-9 months before. I have told the copier company they are the next thing to organized crime!

_If we receive an invoice with no PO – we kick it back to purchasing, who contacts the requisitioner. There is no excuse for this to happen. Even on emergency services, we delegate an approval level for a specific individual who we know will be on the night shift, to ensure that they do not miss out on the requisition. The individual is able to generate an electronic requisition with electronic approval – and the PO is generated automatically. If the service comes in and the service is not approved – that individual is “yellow carded”, and if it happens again, they are sacked. There are no exceptions. The reason this works well is that management fully supports procurement. No one in the company can usurp that authority – and if so – it is very rare and we can pre-empt it from happening. _

Companies should also consider using more blanket orders. Let the end users get on the system and do the releases. There is no need for Buyers to be involved any more. Buyers monitor the weekly and monthly buy patterns and renegotiate a particular item on the blanket if they see higher usage. Finally, seek to reduce complexity of Procure to Pay Process. Accounting wants 3 or 4 ways to match to pay, but you can reduce it to 2. The most common would be 1) PO and Delivery of goods or service, then pay. (No Invoice Needed), or 2) Pay everything on a Charge Card. The company will obtain a rebate on the spend dollars from the Credit Card Company and have more days outstanding to pay and thus have the cash longer. Do the research or analysis after the fact. This is done with reports being generated by internal legacy systems and Credit Card Company systems. In redesigning the process. When you encounter inaccuracies, track the data and find out who, what, when, where and why the issues are happening. Correct the issues at the point of the problem. Finally, it is important to make buyers part of the review and repair team. Have them spend one hour a week to meet with AP and Vendor on a conference call. The Buyer should facilitate the call. This makes them learn the entire process and be in charge of processes reengineering and the internal consultant that you want them to be.

_We have structured things a lot for an end user to get their requirements. We have a lot fewer AP issues to deal with because we are more structured. We use a lot of catalogs, and clean them regularly. We also do a lot of market intelligence to identify what is changing in our user markets, and ensure that catalogs are kept up to date. _

A second and much more complex external services scenario involves Maintenance, Repair, and Overhaul projects. I was team lead for a project that implemented MRO services for an electric utility company. Every project has a project plan, WBS, and activities on that plan – if you need to track labor hours against your project plan you would consider a bolt on system. For example, consider when you are performing maintenance on a shop floor or refurbishing a manufacturing line. It has less to do with getting the bill paid, and everything to do with project management. In addition, you may need to track your internal employees’ labor and external contractor labor using the same system. You frequently need to track labor cost as a component of the overall cost of the project or the machine being rebuilt. Some companies offer external services – time entry systems. This can help with complex time entry, project management, and project accounting. Although they claim to bolt seamlessly to SAP, my experience is that you need considerable programming effort to get the two systems to work together. All these “bolt-on” packages should work with SAP’s external services module – specifically SAP’s services master data housed within the external services module. With SAP’s external services module, you identify the catalog of external services and apply rates for each service. These rates need not be $ per hour. At the electric utility company, they hire a contractor to dig the trenches – and their rate is based on cubic meter of trench dug.