You are on page 1of 22

Best Practices in Procure to Pay

Introduction Part 1
Written by: Rob Handfield, SCRC Kevin McCormack, and Wolfgang Steininger
As more companies are seeking to move beyond procurement into fully deployed supply chain systems, a key challenge for many companies is in the area of improving efficiency in their procure to pay cycle for many of their contracted services, especially in the area of facilities maintenance and on-site contract management. There exist multiple challenges in environments where field associates are working from manual or electronic systems, requisitioning on-site services for maintenance or other activities, and ensuring that this information is captured effectively. In addition, there exist significant challenges to ensure that the proper service level agreement is fulfilled, the correct price is charged, the purchase order is transmitted correctly, the invoice matches, and finally, that the supplier is paid the correct amount for the actual services delivered. While many enterprise systems claim that these elements are simply defined within their structural logic, the truth is that there are many opportunities for error, and that without a planned process for managing the procure to pay cycle, your organization may be bearing significant costs due to non-compliance to system or process requirements. A qualitative study of the Procure to Pay process was undertaken by the research team in order to determine the symptoms, root causes, and recommended approaches to identifying and solving the problems associated with the P2P process. Moreover, the team was interested in seeking answers to the following questions: What the symptoms of the problem that are being experienced by internal buyers, vendors, and subject matter experts? What do these groups of respondents believe are the underlying root cause for these problems? What are the recommended solutions and potential benefits associated with the solutions suggested by respondents? This benchmarking study sought to define and understand the best practices currently being employed by companies in the procure to pay cycle for services. Specifically, the research team focused in learning and sharing best practices in the following areas shown in Figure 1.

Forecasting and Planning of Requirements Need Clarification / Specification Sourcing Decisions in Emergency / Non-emergency situations Contract P/O Generation for Structured or Unstructured requirements Receiving of Services, Materials, and Documents Settlement and Payment in Accounts Payable.

Figure 1. The Procure to Pay High Level Process In order to explore how an organization should approach improvements to the P2P cycle, we adopted a grounded case-based research approach to identify the issues and develop a framework for analysis. Case research requires that a set of detailed interviews with a small sample of firms involved in the phenomenon of interest be studied in detail to determine qualitative insights into the linkages (1). Before beginning a case study, however, it is necessary to have a conceptual model for crafting research instruments and protocol (2). The conceptual model for studying the research questions was therefore derived, based on existing literature as well as a kick-off meeting held in early June. A comprehensive literature survey was carried out in order to develop a model describing best practices in P2P, which resulted in a five-stage maturity model shared with the core team. This framework is based on the notion that the P2P must be an integrated approach that includes all of the functions throughout the process to be effective, and is described in the next section. Some of the initial hypotheses regarding the problems surrounding the P2P process were developed around discussions at an executive workshop and developed into specific questions for the interviews.

Figure 2 Next, an interview protocol was developed based on a general understanding of issues facing the organization and the hypotheses developed. (See Figure 1.) Questions focused around the workflow associated with the movement and management of materials and services to the companys facilities, and included vendors and subject matter experts from a number of external companies. Key respondents were identified in each of these areas, and interviews were carried out using the structured interview protocol. Hypothesis H1 H2 H3 H4 H5 The root cause for problems is associated with a lack of process design and poor communication The root cause for problems is a lack of a central point of contact - designated relationship manager The root cause for problems is a lack of standard single input point from suppliers/ field buyers into SAP. The root cause for problems is the lack of a forecast and planning process. The root cause for problems is a proliferation of catalog items, suppliers and line items causing increased complexity.

H6

The root cause for problems is a lack of executive support that drives compliance to the process

We interviewed a number of suppliers who had experienced problems associated with the P2P process, and interviewed a number of subject matter experts. The research identified six key findings that can lead to improvement in the P2P cycle:

Robust processes and training On-site relationship managers to allow field maintenance to focus on doing their job Robust technology using single point of contact - supplier portal Improve forecasting for maintenance and planning for emergencies that can flex with different situations that arise Reduce complexity in catalogs and buying channels to streamline procurement Top management support

Virtually all of the hypotheses we posited at the beginning of the research project were validated by the suppliers and subject matter experts interviewed in the study. A confluence of respondents each arrived at much the same conclusion: the P2P cycle truly needs to be re-designed if improvement is to occur. A suggested approach for improvement of the P2P was documented: 1. Secure top management support for the initiative and budgeting for the project. Develop a list of key benefits and deliverables that will occur as a result of the improvements. Document the cost of leaving the system broken in its current state. 2. Map existing processes and problems with the P2P cycle. Identify where the breakdowns are occurring, and why they are occurring. 3. Understand the needs and requirements of the user groups. Many of the people involved maintenance, planning, project management, suppliers accounts payable, buyers, etc. have specific issues that prevent them from using the existing system. Also, many of the specific sites may have issues that need to be considered in designing the new system. 4. Team Redesign Workshops should be used to bring together key subject matters experts from each of the business units. Suppliers should also be invited to attend and participate, as they may have solutions they have adopted with other customers that may prove to be efficient and simple to use (e.g. why re-invent the wheel?) 5. Explore existing technology solutions with SAP, as well as bolt-on applications. Map out the business requirements, and ensure they are aligned with the technology solutions that are available. Begin to estimate cost of deployment, and ensure that adequate planning and due diligence is taken at this step.

6. Following the workshops, define the new process and begin to pilot using a planned technology. Ensure that it takes place in a real environment, with actual non-trained users involved in the pilot before cutting over to the next process. 7. Train and deploy other users based on the new processes and systems. Be sure to make the training appropriate to the specific functional unit and user groups. 8. Monitor, update and improve the system, ensuring that catalogs are kept up to date. Hold periodic meetings with suppliers and user groups to solicit input and identify problems with the systems. As technology and business requirements evolve, the P2P cycle will probably need to be re-visited from time to time to ensure it is meeting the needs of internal customers, and that suppliers are satisfied with the system. In the next series of articles, we will document the specific best practices advocated by subject matter experts we interviewed as part of this research project. References: (1) K. Eisenhart, Building Theories from Case Studies, Academy of Management Review, 14, p. 532-550, 1989. (2) M. Miles, and A. Huberman, Qualitative Data Analysis (Second Edition). Thousand Oaks, CA: Sage Publications, 1994.

Part 2:
We first interviewed eight suppliers who were known to have experienced many of the typical problems associated with the P2P cycle (e.g. late payments, etc.).

Figure 3 Symptoms Identified by Suppliers As shown in Figure 3, the most common symptoms experienced by vendors involve high manual workarounds required to address problems, long cycle times for payment, no central point of contact, and a problem with matching the PO and invoice. Some of the typical responses we heard from vendors in these categories included the following: We have had a lot of money tied up with this customer. This is not good for this customer because they do not recognize their cost until it is approved in their system. We dont invoice until we receive a service entry number back. If a service entry is not created in their system for an amount equal to or greater than our timesheet and we process our invoice, the invoice will be parked or blocked, and will not get paid. Usually these parked or blocked invoices will stay in those statuses until they go into the 60 days column of our aging. At that point I contact their payables person or my contact in their services department to set a meeting to determine why these invoices are not paid. No notification is done to let us know that the invoice is not going to be paid. It is important to note that all of these examples are symptoms of a set of underlying problems with the P2P process. These examples are also not uncommon. Many of the suppliers we spoke with noted that they had also experienced these problems with other customers, although in this case the company noted was exceptionally bad. Root Causes Identified by Suppliers Vendors interviewed also noted a number of root causes associated with the P2P problems. As shown in Figure 4, the most common root causes were associated with the lack of a formally designed P2P process, the lack of a central relationship management, or problems associated with supplier interfaces with SAP. Other reasons included the increased complexity associated with SAP catalog and line items, and the lack of a forecasting process. Some of the common root causes mentioned by vendors included the following:

Figure 4 Root Causes Identified by Suppliers As can be seen from these examples the fundamental root causes are that a lack of a process with designated roles and specific processes associated with different internal and external functions are not defined. Maintenance people, buyers, planners, schedulers, accounts payable, project planners, and others are not in synch. Further, the system is not designed to be able to withstand the various approaches in which people are entering data and requesting information. When too many people are not using the system in a unified manner, it is no wonder that the system rejects the input and causes problems! Thispoints to the fact that either the tolerances of such systems must be changed, or the manner in which the system is used is changed. Recommended Solutions These same set of issues were identified in recommended solutions suggested by vendors. The vendors recommended that the company explore the following possible actions.

Figure 5 Recommended Actions Suggested by Suppliers The top four elements that were identified as possible solutions included redesigning the P2P process, developing a dedicated relationship manager to work with suppliers on key areas of interface, exploring the use of a vendor portal using the CATS interface in SAP, and reducing catalog items through a spend analysis to reduce the inherent complexity of entering information into the SAP system. Specific recommendations were as follows: There needs to be a relationship manager, to make the whole purchase to pay situation completely process driven. This is difficult, as there is not a lot of decision-making that can be automated. Another thing that would really help we can receive orders electronically. If they use their catalog number we can receive it automatically and it crosses into our system and there is no question as to what the price, description is. All of the people in the trenches financial guy, biller, their cost person, their upload person all of these people have to understand their function and what the handoffs are. If there is a problem, they all have to understand how to resolve it. We generate an invoice online we already have the billable rates, we know the hours and can send them for approval on a weekly basis.I could easily add a column with the dollars. That number could be used to make the payment and then we can follow through with an official invoice, and get the is dotted and ts crossed which would also help with the cash flow position!

You CANNOT plan for the unexpected on turnarounds but they should have a history of their turnarounds to look at their paid process. They could come back and audit it and take exception but to hold our dollars is killing us on a low margin business. 50% exceeding the initial estimate is not a large number on a turnaround. If they could pay us and then and audit the figures or even if they were able to check part of it we would be willing to credit them later!

Part 3:
The supplier responses to P2P problems by and large provide significant insights into the problems and complexities associated with improving the P2P cycle from a suppliers perspective. Unfortunately, these issues also translate into significant problems for the purchasing company, which is often lost in translation when the need for P2P improvement is communicated to a senior management team. An important component to consider in making an argument for improvement to the P2P process is the Cost to Serve of different customers from a suppliers perspective shown in Figure 6. As shown in the figure below, Cost to Serve is an important component of developing aligned strategies between customers and suppliers.

Figure 6: Cost to Serve Model Suppliers will seek to align with customers that may have a high cost to serve, but are willing to pay for the service provided through improved responsiveness. In addition, customers that have lower requirements may not require the same level of demand attention, when there is a good match with general capabilities. However, teams should re-examine strategies for low margin customers that are

aggressive and low margin, and question whether these customers are a good match. Late payment and excessive workaround to obtain payment in a timely manner will definitely increase the cost to serve for companies with a broken P2P process. Some of the typical problems that can occur when a malfunctioning P2P process is not fixed include one or more of the following events:

Deteriorating response time from suppliers, who have no motivation to improve performance and respond quickly to a customer who fails to pay them for 90 days or more. Lower service levels from suppliers, who may choose to service their more profitable customers first in their Cost to Serve Model Deterioration as the Customer of Choice in the mind of suppliers senior management, which further breaks down trust and strategic alignment Delivery delays Higher pricing due to the cost of money that is attributed to late payment and excessive manpower allocated to the account Increased manpower on non-value added activities (e.g. chasing payments) to the detriment of other value-added activities that can improve customer service Loss of the supplier as a critical link in the supply chain Higher costs internally for the purchasing company, who must also dedicate AP people and buyers to non-value-added activities

Additional validation of these insights were also required to understand if best practices form other industries were relevant as well.

Part 4:
A number of senior executives from a variety of different industries were also interviewed to understand their responses to the same problems associated with the P2P cycle. These included the following: Director Energy Company VP Procurement ContractedPharmaceutical Services Provider CPO Consumer Packaged Goods Manufacturer CPO Pharmaceutical Company IT Process Energy Company Owner Director of Electronics Manufacturer

EProcurement Consultant VP SCM CPO

Big Three Consulting Company Composites Manufacturer Chemical Company

Each of these individuals provided a different perspective on how to improve the P2P process, but when combined resulted in some common themes that validated many of the vendors suggested recommendations as well. These responses are organized around the six hypotheses initially identified in our model, and validate that problems associated with the P2P process is indeed a function of multiple sources. Common Themes

Robust processes and training On-site relationship managers to allow field maintenance to focus on doing their job Robust technology using single point of contact - supplier portal Improve forecasting for maintenance and planning for emergencies that can flex with different situations that arise Reduce complexity in catalogs and buying channels to streamline procurement Top management support

Each of these themes will be the focus of subsequent articles in the series. Robust Processes and Training Another critical element identified by all of the subject matter experts was the need to develop standardized processes and training around the P2P process. Specifically, roles and duties of the different people involved in the process must be clearly defined, and training should emphasize how invoices and requests should be processed, and the reasons why deviation from the process is unacceptable and the consequences involved with deviating from the process. This ensures that everyone is not only compliant, but understands the need and rationale behind the compliance. Part of the process redesign effort should also focus on simplifying processes to reduce complexity. If there is no need for a specific channel for purchasing, then eliminate it. Some of the comments are shared below: One of the most important discoveries we made is that we did NOT have a technology problem; we had a people and process problem. The technology wasnt working the way it was supposed do, because we did not have a robust process to use it. We did not want to invest in a customized Graphical User Interface, but decided then that the simplest way for us to get maximum ROI for what we had was. Once we started down that path, we recognized that the

design of the interface that we had was not user friendly, and users didnt really have training. They had a LOT of training on SAP that was not useful in terms of what they did in their jobs! So we asked the question if a requisitioner only needs to know 3 things about SAP in this function, do people really need a weeklong class? Instead we re-tailored the training to the function that the people had and we also used our website portal to put in help screens on HOW to input a requisition. We provided step by step instructions for material or for services that utilized a decision tree that was very straightforward. We actually put in the actual screen looks and feel so that when they clicked on the link it would look like their PC! It was a very common sense approach, but very practical! Good data analysis and firm processes will greatly reduce the number of frustrated invoices. This begins by negotiating contracts/PO's with a firm NTE price for the job. A best way to treat these buys is to analyze the yearly spend in the commodity and then find supplier solutions that will enhance the suppliers services and reduce the extra administration to a companies internal processes. Most likely the suppliers have ideas and systems that will reduce the paperwork side of things. A second task is to reduce PO's being input internal legacy systems: Do we need to put PO's in the system for low dollar commitments? If we leverage the commodity with a supplier then we should let the end user either call in for services or get on line with the supplier to request services based on a master agreement. Of course the process would be to get a name, department number and charge number from the end user prior to any work being done. At our company we had problems getting the requisitioner to put in a proper requisition according to the standard we had in the system, and getting it routed to the right person within SAP so that it matched all the key elements, and going to accounts payable. The problems were multiple: whether it had an appropriate requisition in SAP, that procurement had done the right thing with it, that the supplier had put in the right invoice, and that AP was able to match it properly, and that the whole activity was done correctly and the supplier could be paid. One of the things we did was to work with the different business people to look at the AS IS process, and work to a Should Be. This helped us understand what you think is happening, what is really happening and mapping it out. Then we asked questions such as what culture is there, what kinds of things DO they want to have happen, and how detailed is their SAP system? What does the system design look like and does it match users expectations! What we discovered of course is that our design did NOT match our expectations! We thought we had spent money that would do req to pay simply but we found instead that it doesnt work that way. We had a problem getting work paid because work wasnt getting requisitioned appropriately, and invoices werent being put in properly. One practical solution we used upfront was to have the user groups send out their expectation in writing this is what we want to have happen and we responded that we respect you and your organization to work with your team to make it happen.

Part 5:
An important point that many respondents noted was the need to establish dedicated roles around on-site relationship managers from procurement who were on-site to manage invoices, service entries, and the like. The simple fact is that many maintenance and project managers do not think in terms of procurement, but rather are focused on people, equipment, and schedules and do not have the time or patience required to ensure that the correct entries are put into a P2P system. The relationship manager can also act as the liaison between the supplier and the maintenance organization, to ensure prompt payment, resolution of issues, and improvement of processes. Some of the sample responses included the following: It is important to establish a logistics person on site in the field to help facilitate and work the system. Field people are focused on executing the work, not supporting it. Construction people are focused on execution of work they are not good systems thinkers and are sloppy about the logistics side of the work. A logistics person is turned on by excellent logistics and not focused on work execution. If they plan their jobs better, logistics people can set up good bill of materials and planning templates and they can pull them down and they dont have to pick form a catalog. Even the break-in work and emergency work can be converted into BOM templates. So you can classify work into some standard categories. If it is a break in emergency, pull down this job plan, attach it to the work plan, and the standard BOMS drives the order. The field people have to focus on getting people in, scheduling people, getting the work done, so choosing from a catalog is the lowest priority for them. Our focus is on how to position SCM resources to make their work a lot easier and make the planners life a lot easier so they can add maximum value the supply chain function. Initially you dont know 100% what the material will be used on that job. At the end of the job the SCM person goes in and looks at returns and adjusts the requirement accordingly. You do three iterations and you will get the BOM right for that job type! Having that SCM person in the field who can talk their lingo is key to success

Part 6:
A number of SMEs described the need to eliminate the manual intervention of multiple untrained individuals in entering information into systems such as SAP. Many ERP systems have modules for purchasing and plant maintenance, but they all require significant configuration. On the other hand, a number of bolt-on

packages are also available, but our SMEs advise against these due to the high probability of interface issues associated with deployment. For example, some of the comments that came back include: The CATS interface on SAP does need configuration. The beauty of it is that it puts the service entry sheet on the person using it, and puts the burden on people who know. So when it arrives at SAP it is already matched. When the invoice arrives it is easy to check if it matches what the requisitioner required. It is important first to ensure that the business process is very good and can adopt to changing buying requirements. There are one time services like legal for something like that a blanket PO with some sort of a manual receipt process and invoice process is the only way to go. Project oriented monthly billing is important. When you get into temporary services where you may have 300 or 400 administrative staff that work for an outplacement company, the situation is different. This is high volume, with people inputting time on a weekly basis and cost center owners need to understand what their exposure is cost center by cost center. If I am hiring ten temps for a full year, and each is getting 20,000 per year I need to accrue for that amount of money and draw that down.but you need to guess at things like overtime, weekend work at time and a half. It can be done, but it is difficult. The problem is that with many of the laws regarding contractors versus employees it is necessary to set these people up as a pseudo employee. You have a purchase order that has line items that equate to each one of these people for external services and a range of hourly rates, and how long you expect them to be employed, etc. So we now have two extremes high value manual processes, and low value but lots of them. When it comes to the payment and invoicing part of this purchasing is out of the loop. You want to decentralize this process as much as possible and push it as close to the people who are doing the work as you can.a web-based timeentry system. Some type of identification (we used the PO number and line number as the ID) is required and vendors need a secure environment to include this with us. The other challenge is that frequently you dont have people working in one geographic area so it becomes difficult to track temps at sales offices. So a web-based solution is the way to go on this. Once a week, the work flow can be configured to route that time sheet to the sponsor. That sponsor reviews all of the time sheets they are responsible for, and that gets entered into SAP as a service entry sheet. Now, all of your accounting and PO are now updated so when the invoice comes in there shouldnt be discrepancies. If you trust your supplier, I would recommend going to evaluated receipts settlement. As the service entry sheets are entered, AP creates a batch program and they simply run this batch program and it creates the invoice and the check goes out. You need to audit from time to time, but it is always cheaper to do a

post-audit to do one upfront. I would not recommend starting that way and you need a long-term strategic relationship with that supplier. In the end however, what value does an invoice add? If there is a problem such as if we havent paid enough, then let the vendor come to me and well fix the problem. We are working to develop a contractor charge collection product that is webbased. We will require contractors who execute the work at the end of the day to fill in a labor equipment materials sheet (WEM) and the supervisor to generate a WEM for that day which indicates how much labor we utilized. If you have negotiated those rates in the contract, then it becomes relatively easy for the supervisor to enter it into the system. Now you have a statement of WEM delivered and you can put it in front of someone who can validate that it was done. It also lets you track earned value against a PO value- and you know you are getting to upper end of work (e.g. we have spent 80% of budget but only 50% of work executed) the supervisor knows there is an issue, which he can resolve in real time. But if John Smith is collecting his WEMS for the work and sending it weekly to the main office and collecting it in the system at the end of the month, you are in for a surprise when AP kicks in and generates a massive invoice to the client. You are getting the overrun signal a long time after the work period. Construction people are like dogs they need to be punished close to the event, or they dont understand! If you have all of those lags it doesnt let the control signals act. Contractor Charge Collection (CCC) systems allow tradesman to enter WEMS on a daily basis and sent to contract coordinator or work supervisor to acknowledge that work was delivered and can let you know total commitment of dollar spent versus overall scope of the contract. If the ratio of dollar spent is out of whack with work complete then they have a signal, and management can hold that person accountable. Otherwise mgmt has not way to hold the person accountable. SAP has something called CAPS it is just a grungy interface tool to do whatever you want it to do. We are configuring CAPs to do whatever WE want it to do. Time Industrial is another company that has a system that supports the entry of WEMS a web-based system and you pay them a fee. It is very comparable to what we are developing. They charge a fee to every WEM entered and a fee to the contractor for every WEM entered collect money from both parties. When we looked at it Rita said it was a good tool we should look at but some bells and whistles we wanted as found as repaired requirements. Maintenance need to know how we found it and how we left it for reliability engineering. Time Industrial just collects WEMs, and did not address the as found as repaired requirements. That is why we went with our own. Anyone can go with it. For us it was not a trivial figure in terms of price but if you look at the comparative analysis on cost overruns, lack of ability to audit, lack of dual charges through using a consistent system that we would have paid for the fees within the first year of use.

Part 7:
The need to improve forecasting processes is a critical element in ensuring that maintenance needs are met in the P2P cycle. While maintenance is often an emergency, there are many scheduled maintenance activities that can be planned and communicated to suppliers. Even in emergency situations, having a plan in place with a designated supplier can avoid many of the problems that occur downstream in the P2P cycle. Too often, data, invoices, service entries, and other key elements are entered incorrectly due to a fundamental lack of planning and forecasting. These elements need to be incorporated into the design of new P2P systems. Some of the comments include the following: You need to convince maintenance that planning is a wonderful thing. They need to get into a maintenance culture of planning. The plan needs to be linked to resources. If they dont plan like that the supply chain people will be challenged on how to predict demand. By putting supply chain people closer to the customer, you can become better in managing that demand. You can move those goods requested into the right channels to position them properly. The people in the field should not be buyers, so you need to place buyers that can understand the maintenance people and translate their requirements into the system. We had one lady working at our facility in this role who knew the maintenance work better than the maintenance people! When they said we are taking the equipment down, she knew the library of materials and services required, and she was on the ball talking to the buyers and suppliers required to support that before the maintenance people even put in the orders! The maintenance people came to trust her, and she was able to improve the predictability of demand which made it so much easier to work with our suppliers, rather than jerking them around at the last minute. Even for emergency maintenance the maintenance manager on duty HAS to know about it, and HAS to send in an email and write the requisition for PO generation. Another important best practice is that we have already prenegotiated terms and conditions for all emergency services and we have 3 vendors for EHS and boiler emergencies. When maintenance requires emergency work, the contract is already signed sealed and delivered at prenegotiated rates. We treat emergencies as natural purchases. We pre-select the vendor, execute a PO with terms and conditions, and when the emergency occurs, costs are issued at the time of the work and the PO is issued at that time. If no emergency occurs, the PO is not used, and the vendor is not used. In effect we know that emergencies will occur but not when. So we do not treat them as an emergency, but as a known, predictable event that will inevitably occur. In routine maintenance you know when you will need to be available. In emergency work your JOB is to be available! The environmental

piece of this is the biggest element that we need to be prepared for. As an example at one facility we have to keep water effluents at regulated levels and the lakes that purify the waste water at certain water tables determine this. We regulate how much we pump on a regular basis and measure tolerances. When a tornado raises the level of water in the lake we cannot use the lake. So we have to have an emergency tanker service at the ready to take it to a holding pond. We know this will happen but now when, and pre-negotiate the business. It could happen zero times in a year, or 20! We dont know

Part 8:
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 POs for 3-4 years, and you would lose control. You would be invoicing against blanket POs 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 SAPs external services module specifically SAPs services master data housed within the external services module. With SAPs 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.

Part 9:
Having a champion in senior management to send the signal that compliance to the redesigned P2P process is critical. Ideally, a policy of zero tolerance should be established, with consequences for those who do not pay attention to the guidelines. This will buttress the argument, and ensure that people are committed to the change. Re-organization of some departments to establish lines of authority and responsibility, including merging purchasing and accounts payable, is another form of change that would require senior management support to drive change. Some of the comments in this category included the following: Purchasing and AP are also probably fighting and pointing fingers. You should consider merging AP people handling these issues into the purchasing department. Then you have shared goals and objectives. The goal is no longer to throw the invoices over to purchasing but to establish a common objective to solve the problem. We moved people responsible for MRO invoices and put them into purchasing to have shared goals and objectives, then evaluated them on how well they did to solve the problem. The finger pointing goes away because it becomes OUR problem that we have to fix. In the past, they could push a button and it became purchasings problem! One needs to consider culturally how are they set up and what is their coordination. One way to stop it from becoming an individual department problem, and then it becomes a company problem. One of the first things we did is establish the case for action! Why is it important, and who is driving it? My boss was the CFO and sat on the exec committee and he was able to get stakeholders to agree that it was their problem not finances problem and that they owned it. We made sure we got it at the right level and got clarity around what the exec committee wanted! Who is paying the bill on this? The executive committee footed the $40M bill for SAP and we emphasized the need for clarity and matching of the system to different functional responsibilities. We emphasized that it was important to have the right resource to work thisand they supported us from the beginning. We took a pragmatic view. Lets not solve world hunger, but address key pain points and address what practical solutions can we come up with to help this along. The executive committee came out with a statement that said We WILL fix this and we WILL be successful! They understood that is not going to happen if you dont have the right type of people owning it. When we came up with the solutions

around the training, website, proper use of procurement cards, etc., top management was there to support us in deployment. The last piece that is the most important is that the only people at our company that have authority on payment terms is purchasing. Invoices are due on receipt we go do it, and abide by their terms and conditions in the contract. If you go outside of this system, you have no authority and you will be sacked. ONLY purchasing is responsible for terms of payment NOT AP! We control it, based on a check date. Once the receipt hits the system the clock starts ticking. We are a $XXB business and every transaction requires settlement in two business days due to the nature of the business! If we dont pay suppliers, our credit rating is hurt, and this precludes us from working in this business. Cash flow is king.

Part 10:
Virtually all of the hypotheses identified at the beginning of the research project were validated by the suppliers and subject matter experts interviewed in the study. A confluence of respondents each arrived at much the same conclusion: the P2P cycle truly needs to be re-designed if improvement is to occur. A suggested approach that is evident is shown in Figure 7. The rollout for improvement includes the following: 1. Secure top management support for the initiative and budgeting for the project. Develop a list of key benefits and deliverables that will occur as a result of the improvements. Document the cost of leaving the system broken in its current state. 2. Map existing processes and problems with the P2P cycle. Identify where the breakdowns are occurring, and why they are occurring. 3. Understand the needs and requirements of the user groups. Many of the people involved maintenance, planning, project management, suppliers accounts payable, buyers, etc. have specific issues that prevent them from using the existing system. Also, many of the specific sites may have issues that need to be considered in designing the new system. 4. Team Redesign Workshops should be used to bring together key subject matters experts from each of the business units. Suppliers should also be invited to attend and participate, as they may have solutions they have adopted with other customers that may prove to be efficient and simple to use (e.g. why re-invent the wheel?) 5. Explore existing technology solutions with SAP, as well as bolt-on applications. Map out the business requirements, and ensure they are aligned with the technology solutions that are available. Begin to estimate cost of deployment, and ensure that adequate planning and due diligence is taken at this step.

6. Following the workshops, define the new process and begin to pilot using a planned technology. Ensure that it takes place in a real environment, with actual non-trained users involved in the pilot before cutting over to the next process. 7. Train and deploy other users based on the new processes and systems. Be sure to make the training appropriate to the specific functional unit and user groups. 8. Monitor, update and improve the system, ensuring that catalogs are kept up to date. Hold periodic meetings with suppliers and user groups to solicit input and identify problems with the systems.

Figure 7 Improving the P2P Cycle The primary differences between basic and advanced levels of process maturity for the P2P Cycle are shown below.

As technology and business requirements evolve, the P2P cycle will probably need to be re-visited from time to time to ensure it is meeting the needs of internal customers, and that suppliers are satisfied with the system.

You might also like