SAP Implementation Strategies for Purchasing
Benjamin T. Wilson, CPM
Benjamin T. Wilson, CPM, Senior Consultant, Ernst & Young LLP, St. Louis, MO 63101, 314/259-1863.
Scott Vanlandingham, CPIM
Scott Vanlandingham, CPIM, Senior Manager, Ernst & Young LLP, Irvine, CA 92612, 714/252-2435.
82nd Annual International Conference Proceedings - 1997
Abstract. Many companies are implementing SAP'S R/3 Product today and the ramifications of these implementations on purchasing organizations will continue for years to come. This paper highlights what types of reengineering is required for R/3, what the critical success factors are, which configuration options are most important and key integration points for purchasing.
Current issues Facing R/3 Implementations - Purchasing. As has often been the case with R/3 financial modules, no one goes to SAP and requests to buy just their purchasing module. Why? Because in reality the module is only adequate when it comes to the complex relationships that are developed through the Purchasing function. Additionally, it would be difficult to have any meaningful information come from the module without implementing at least a few of the other MM pieces of the module (Inventory Management, Warehouse Management, Physical Inventory, MRP and Invoice Verification), or the Financial and Controlling modules. If the organization's existing purchasing application does not meet all of management's expectations they may find R/3's solution very exciting to implement. If, on the other hand, the organization has developed a custom application to handle many of the company's unique transactions R/3 may be less than optimal. However, these unique types of transactions are typically high dollar, strategic relationships that require a large amount of oversight. R/3's ability to cleanly and efficiently conduct the simple, high-volume transactions with minimal human intervention gives purchasing agents time to concentrate on the more complex and strategic relationships.
From an organizational perspective an R/3 implementation is typically a strategic move made by the top echelon of executives at a company. The reasons for the move are usually numerous but the top three seem to be:
- Desire for real-time data at the enterprise level
- Need to integrate business processes such as accounts payable and purchasing throughout a multi-national organization
- Need to have common processes across business units
Key Factors To Consider When Implementing SAP'S R/3 Product - There are some critical factors that should be considered when implementing R/3. Although the following is not meant to be a comprehensive list it does encompass those factors that are often overlooked and are at fault when an implementation fails. Some of these factors are explained further in the sections following the list.
- Executive management commitment
- Clear vision of your desired "end-state"
- Project Management
- Project scope control
- Full-time project resources for the full duration of the implementation
- Resources knowledgeable of R/3 and your current business processes
- Competing projects put "on hold"
- Your company's track record of completing complex projects on time and within budget
- A partnering relationship with your consultant
- Reengineering for SAP'S R/3 Product
Executive Management's Commitment Of Their Time And Resources - When implementing an application that encompasses so many areas of an organization there must be cohesion and unwavering support at the top of the ladder in words and actions. Without this support the project manager will be saddled with the responsibility of obtaining resources and consensus from all levels of the organization. This will take priority over project management responsibilities and lessen the ability to deliver what has been promised. If executive management is already on board and ready to support the implementation, the project manager will be able to focus on implementing R/3 and not the politics of each decision. At Oki Telecom there was no buy-in from top management and it took three years to implement R/3. The implementation only took place after a rigorous six month deadline was imposed by their executives in Japan who were aggravated by delays. This is just one example of where top management was not on board.
Project Management - Project Management is always a difficult task when implementing R/3. This is because there will is a requirement for multiple cross-functional teams. As with all cross-functional teams there will be competing priorities and the best interests of the project and the company will not always be looked after by all team members. There are some simple steps that can be taken to ensure this does not happen. First is to have a fully empowered senior executive oversight committee with one member selected as the final decision maker. This committee's responsibility will be to ensure that the project is on time, in scope and within budget. Additionally, the committee will assist project management in making some of the most difficult decisions and breaking deadlocks between groups when appropriate.
One deadlock that that occurred at a Fortune 500 corporation was over the base unit of measure; should the base unit of measure of a particular material be the unit it is purchased in or consumed in? Or in this situation, since the organization also sold the material, should it be measured in the unit that it is sold in? Everyone had their own idea on what the correct unit of measure should be. Two VPs argued over this for three months! They made other key decisions during these months and ultimately they came to an agreement but this decision wasted time and resources unnecessarily because both sides had their own agenda. In this particular case there were no clear decision makers to break the deadlock.
It is imperative that there is a final decision maker whom everyone respects and will listen to. With out this person your implementation could run in to the situation described above.
Project Scope Control - Scope control is major issue that needs to be sorted out continually. More than one company has found that the complexity of R/3 is enormous and therefore, managing scope is a problem. This is a factor that has caused many implementations to surpass their completion dates and budgets. Strong project management and top management commitment can help to prevent this. Strong, knowledgeable team leaders are the best first line of defense.
Competing Projects Should Be Put On Hold - Another consideration when implementing R/3 is what other key strategic projects will be underway during the R/3 implementation. Because SAP'S R/3 Product will ultimately be the lifeblood of a company when completely implemented it's success is of paramount importance. This is especially true when there is significant reengineering in conjunction with the implementation. To enhance the projects ability to be successful it is important to put all other strategic project's on hold. This will allow the project to obtain the best resources and also get the executive management attention that is required for a complex implementation to be successful.
Your Company's Track Record Of Completing Complex Projects On Time And With-In Budget - Another consideration should be your company's track record of completing projects on time and within budget. This is usually a difficult thing to assess objectively but it must be done. An easy way to do this is look at the budget that is planned for the R/3 implementation. Then review five or six other completed projects of similar size and complexity. Were all of them successful and with in budget? If they were, get the project managers from those projects on your team. If it turns out that your company has not been as successful as it could have been, then you should look for outside help.
A Partnering Relationship With Your Consultant - Implementing R/3 is a complex task and one where most companies do not have all of the internal skills needed to execute it effectively. When choosing your partner look for the following attributes:
- Successfully completed R/3 implementations in your company's industry or a closely related one
- R/3 specialists that will be on your project with deep background in your company's industry or a closely related one
- Formal networks internal to the implementation partner that support their SAP R/3 specialists
- A knowledge base of pervious R/3 implementation experiences that can be used on your implementation
Implementing R/3 is a huge task and an implementation partner must have a successful track record in order to support an implementation. A good way to determine this is to go see one of their clients that are in production. Talk to their client and find out what went right and what didn't.
Reengineering For SAP'S R/3 Product - One of the most asked questions about implementing SAP'S R/3 Product is whether reengineering is always required. To a certain extent, whenever a new system is implemented in any organization a certain amount of reengineering is required. This is typically because efficiencies are being gained and some tasks are eliminated through automation. This then allows the company to deploy the resources to work on more critical tasks.
Because of the integrated nature of R/3, frequent changes are necessary for the purchasing organization. The first one is usually the cost assignment process. This is because cost assignments are performed up-front in R/3, at the time of requisitioning, wherever possible. Today many companies determine where a material or service is to be charged after it is requisitioned or purchased.
A second change applies only to U.S. companies; primarily ones that implement a tax software package, in conjunction with R/3.. When this is the case, the appropriate use tax must be determined when the P.O. is released. This usually requires the requisitioner or buyer to enter a "usage" code which can subsequently be passed on to the tax software package. Performing these tasks early in the procurement process eliminates a lot of research and guess-work on the part of the accounting department later on and streamlines the process.
From a purchasing perspective many companies undertake a complete reengineering effort. How do you decide what is needed for your purchasing organization? For the answer, base it on a few simple measurable factors. Here are a few suggestions:
- Is your entire organization consistently executing to the requirements of volume based contracts?
- Does your organization have documented processes to execute simple transactions in less than a day?
- Is there a clear and documented process for executing high dollar strategic contracts?
- Does your purchasing organization execute transactions the same way across all divisions and companies?
- Does your company evaluate vendor performance consistently across the entire organization?
If the answer is yes to all of these questions, congratulations you are ahead of the game. If the answer is no to some or all of the above questions then you may want to consider a moderate to complete reengineering effort in conjunction with implementing SAP'S R/3 Product.
To give you an example of why reengineering may be required consider the following scenario. Your organization has a total yearly requirement for critical raw material of 100,000 lb., and you choose to have multiple contracts for that raw material in order to ensure a stable supply. To fulfill the requirement of all the contracts a quota arrangement is set up for each vendor. This ensures that each contract for the raw material would be met. In order to meet these requirements R/3 has a very rigorous process that each purchasing agent must follow in order for the execution to take place properly. This process includes configuring R/3 on how to decide to issue each purchase order. In order to configure this option your organization must have a documented process that can then be configured into R/3. An example of this would be to issue all purchase orders to the highest volume vendor until the volume requirements are met then issue all purchase orders to the next highest volume vendor and so on. All processes, from purchase requisition creation to goods receipt must follow similar structured steps in order to be executed properly in R/3.
How SAP's R/3 Product Will Reengineer Your Reporting Process - Reporting in R/3 has been criticized as being weak. This is not necessarily the case. If companies who implement R/3 are successful in changing the way managers and others think about reporting, then R/3 provides virtually all the information anyone would need.
The change that must take place is that people must get used to the idea of information being both on-line and real-time. As for data being on-line, gone are the days of computer printouts six inches thick. Those managers who made their careers by analyzing large volumes of data and coming to reasonable conclusions may feel somewhat threatened by R/3. A good example of this is the Vendor Evaluation System within Purchasing. If Vendor Evaluation is implemented, it can track all suppliers' performance to quotes, commit dates, invoice accuracy, price trends and defective material, among other criteria. All these statistics are gathered by the system through the normal course of business. Additionally, other criteria can be developed and tracked using input from external systems or manually input. Any of the vendor evaluation criteria can be weighted: on-time deliveries may be more important than price accuracy. Vendors can be compared and ranked in many ways using the various criteria, all on-line.
The other reality that organizations must come to terms with is that the data within R/3 is real-time, and as such changes very quickly. In a production system environment, it can be difficult to run a report twice and get the same result. This constant changing of data has been known to make some users feel that the system is unstable when the reality is that the system is stable but being used constantly.
Although the reporting in R/3 is on-line and real-time, you may still find a need for some traditional reporting. Most organizations find that the need for traditional reporting is virtually eliminated. One corporate purchasing organization that has recently moved to SAP went from over 150 "batch" reports to three in R/3. The three on-demand batch programs provide a total of 19 reports. This type of traditional reporting can be accomplished a number of ways in R/3. Generally, companies use a combination of three approaches to meet these requirements, depending on the specifics of each report. The three approaches are: 1) using ABAP/4 (SAP's proprietary 4th generation language) to program the report, 2) using ABAP/4 Query (an on-line "wizard" that walks the user through building the report and generates ABAP/4 code behind the scenes), or 3) using a third-party report writer package. A fourth approach is the use of what R/3 calls "Flexible Analyses."
Integration Points - One of SAP R/3's primary strengths is data integration. However, the tightly integrated nature of the system is also a complicating factor, and a primary reason why most companies choose to partner with a third party to assist with the implementation.
This tight integration is important to purchasing. For example the purchasing module is integrated with goods receipt portion of the inventory management module. This integration includes the ability to have R/3 propose the remaining quantities when an initial receipt is made. When the goods receipt is made, it triggers a completion indicator in the purchasing module, posts additional inventory to inventory management, updates the stock requirements list for production planning and the moving average price of the product. This integration also extends to the Plant Maintenance and Project Systems modules when it's appropriate.
Configuration, What To, How To - There are numerous options when configuring the Purchasing Module of SAP'S R/3 Product. The first task for purchasing will be determining what your Purchasing Organization will look like. There are many different options for this but the four most used seem to be:
- One central Purchasing Organization
- Several central Purchasing Organizations responsible for product groups
- Several division-specific Purchasing Organizations
- A combination of central and division-specific Purchasing Organizations
There are advantages and disadvantages to each. For example, option 1 is usually used when there needs to be tight control over purchasing activities in order to group purchases together for higher volume and a better negotiation position. Option 2 is used when the Purchasing Organization needs to be centralized by product groups to clarify responsibility and to provide quicker replenishment and service levels to that product group. Option 3 is typically used when it's important to divide purchasing responsibility by division. This helps to clarify responsibility and provide better service however, if the divisional structure changes, considerable purchasing master data maintenance is required. Option 4 is used when central purchasing of products which are required by divisions combine the advantages of a central purchasing organization with the advantages of divisional purchasing organizations for the purchasing of division specific products. This option does not provide for clarified responsibilities which is important when attempting to route requirements automatically to your purchasing agent.
Other configuration tasks are centered around your company's business processes and the reengineering that has been performed. Configuration options include automatic creation and release of P.O.'s, the use of workflow to route electronic documents, creation of source lists, use of quota arrangements, and so on. Effective use of R/3's configuration options to meet your organizations' needs will greatly increase the likelihood of a successful implementation.
Hayden, Kevin, "The Weight Of The Matter." Manufacturing Systems, Vol. 14, 66-68.
Vowler, Julia, SAP's Honeymoon Comes To An End; Its R3 Client/Server Accounting And Manufacturing Software Is Criticized." Computer Weekly, April 6, 1995, 14.
We would like to acknowledge the use of the tool "On Track to SAP" which was developed by Jennifer Ironside. This tool helped us to focus the configuration portion of this paper and saved us from many hours of debate.