- Email: [email protected]
Enterprise resource planning software: a solution to the return material authorization problem
Computers in Industry 45 (2001) 99±109
Enterprise resource planning software: a solution to the return material authorization problem Raymond F. Boykin* California State University, Chico, College of Business, Chico, CA 95929-0011, USA
Abstract One of the critical processes of an organizations supply chain is the return material process. Ineffective management of this process can result in ®nancial loss, poor customer service and negative quality impacts. However, often this process is given little, if any, attention even though the ®nancial and operational impacts of a poorly designed and managed returned material process are signi®cant. Because this process crosses several functional areas (materials, accounting, manufacturing, sales, and service), an integrated information system solution is required. Enterprise resource planning (ERP) systems provide a potential solution. This paper will focus on the design of a return material authorization (RMA) process and the ERP information system solution required in supporting this process. # 2001 Elsevier Science B.V. All rights reserved. Keywords: ERP; Returned materials; SAP R/3
1. Introduction The control and tracking of returned materials plays a signi®cant role in the high-tech manufacturing industry. In an industry where products costs several dollars to hundreds of thousands of dollars, the ability to manage the return materials process is critical. The lack of tracking and control can result in the loss of millions of dollars. Besides the direct ®nancial loss to the company from repairing non-warranty items for free and replacing items never returned or misplaced, there are also the issues of quality and customer satisfaction. In addition, a poorly designed and implemented return material process can create substantial negative impacts on an organizations ®nancial performance and future. The key to managing and controlling this situation is the return material authorization (RMA) process. In * Tel.: 1-530-898-5895; fax: 1-530-898-7970. E-mail address: [email protected] (R.F. Boykin).
the high-tech manufacturing industry, where product performance and reliability are critical factors in the ®nancial success of an organization, customers need a process by which to return defective products for immediate attention. This paper presents the analysis and design of a RMA process for the high-tech manufacturing industry utilizing ERP software, speci®cally SAP R/3. 2. Overview of the RMA process The RMA process involves both the physical ¯ow of material and the ¯ow of information concerning the material. The physical ¯ow of the material includes inbound logistics (customer return), the repair/refurbishment cycle (including required materials to repair and/or refurbish the item), and outbound logistics (repaired item). The information portion of the RMA process consists of the status of all RMAs including, customer contact date, transportation
0166-3615/01/$ ± see front matter # 2001 Elsevier Science B.V. All rights reserved. PII: S 0 1 6 6 - 3 6 1 5 ( 0 1 ) 0 0 0 8 3 - 5
100
R.F. Boykin / Computers in Industry 45 (2001) 99±109
information, goods receipt, repair history, scrapped items, replacement products, quality data, etc. The RMA process begins when a customer contacts the manufacturer concerning a defect or failure of a piece of equipment. Normally during this initial contact, the supplier will attempt to perform some preliminary troubleshooting to determine if the situation can be handled immediately. In some cases the pro-
blem is the result of a software issue. These can often be diagnosed and resolved over the phone or Internet. If the problem is a hardware issue, the customer will be instructed on how to return the equipment. The RMA process is often tracked and controlled through the use of a unique number assigned to each request. The customer uses this RMA number as a reference in all future communications concerning the
Fig. 1. Simpli®ed RMA process ¯ow.
R.F. Boykin / Computers in Industry 45 (2001) 99±109
equipment. The company uses this number internally to collect information on the speci®c piece of equipment. Once disposition of the returned equipment is made and repair is completed or a replacement is issued the RMA is closed. Fig. 1 presents a simpli®ed view of this process. 3. ERP and SAP R/3 Enterprise resource planning (ERP) systems are de®ned as integrated sets of comprehensive software. These sets usually include a set of mature business applications and tools for ®nancial and cost accounting, sales and distribution, materials management, human resource, production planning and computerintegrated manufacturing [1]. With combinations of these fundamental software modules, companies are able to model a wide variety of business processes [2]. Major corporations to automate and to manage their complete organization are installing ERPs. A wide variety of companies, such as Coach Manufacturing, Hewlett-Packard, Elmers products, Bristol±Meyer, Philips Automotive and Baylor College of Medicine [3] are counting on their ERP systems to coordinate order management, high volume manufacturing, patient care, customer service, product inventories, cash ¯ows, ®nancial management, etc. In addition, by interfacing ERP systems between companies, organizations are partnering to create ``business-to-business'' electronic commerce. Obviously, these systems are large and complex and by their nature require the understanding of both a focused, functional perspective and a business-wide perspective at the same time. The software companies offering this type of software include PeopleSoft, Oracle, Baan, and SAP. In this paper we focus on the current market leader in ERP systems SAP, and its product R/3. SAP R/3 is a client/server ERP system, which contains an integrated set of comprehensive software modules. These include modules for ®nancial and cost accounting, sales and distribution, materials management, human resource, production planning and computer-integrated manufacturing. The system is available in many languages and has the capability to work across the myriad of different currencies, accounting procedures and tax laws encountered by todays global organization [4].
101
The SAP has taken the ERP systems market by storm. PricewaterhouseCoopers reports the ERP market (license and maintenance revenues) at US$ 14.4 Billion in 1997 and growing at an annual rate of 20% [5]. SAP has over 15% of the market and according to Price-Waterhouse, ``its (SAPs) position in the market has boosted SAP R/3 to the defacto industry standard'' [6]. 4. RMA and SAP R/3 Software that focused on one functional area was bene®cial as long as the decision remained within that functional area. However, most decisions have crossfunctional input and impact which limits the effectiveness of the traditional software systems. Bigger problems arose when organizations attempted to have two or more function-based software systems (often called legacy systems) communicate. The results from this approach have been slow transactions, corrupted data, and a large software support organization. Business enterprise software, or ERP software as it is often called, takes a totally different approach. There is a single repository of data, with all the applications using this same database. The software is designed for integration rather than unlimited functionality. This approach may reduce the level of functionality of existing stand-alone systems. However, this reduction in functionality is trivial compared to the ability of having all applications working together. The major bene®t of an ERP system is that a transaction can be uniformly managed from the point of inception to it ®nal disposition. Having the software control the transaction work¯ow is a powerful force, however, processes must be reengineered so that unnecessary or redundant operations can be eliminated. In the implementation of ERP systems, one can either reengineer the process to match the functionality of the software or customize the software to match the existing process. While the former approach has proven more logical and effective, historically ERP implementations have had to deal with the critical issue of changing the business process or modifying the software. In the past, one of the most common reasons why ERP implementations failed was the companies
102
R.F. Boykin / Computers in Industry 45 (2001) 99±109
discovered during the implementation that the ERP system did not support one of their important business processes [7]. The solution to this problem is changing the business process to match the ERP systems process or customize the ERP software to ®t the companys process. Each alternative has drawbacks. Changing the business process creates turmoil within an organization and modifying the software can delay the project and make software upgrades much more dif®cult in the future. The solution can be a compromise between complete process redesign and massive software modi®cation. However, many companies tend to take the advice of their ERP software vendor and focus more on process changes. In a study by Deloitte Consulting LLC, one in four companies implementing an ERP system indicated that company performance dropped when the ERP system went live [8]. The study revealed that this initial performance problem was most often the result of business processes being changed. Organizations often took 3±9 months to recover from this performance dip. This provides some evidence to the impact of modifying business processes without fully understanding all consequences. It also supports the position that not all business processes should be drastically modi®ed in line with the ERP software. In his book Mission Critical, Thomas Davenport documents some successful ERP implementations that used the software as a driving force behind process reengineering [9]. Davenport [9] states that companies ``. . . recognized that transaction data could'' create opportunities for redesigning fundamental business processes that create entirely new sets of decisions. This research points to the potential improvements realized through the implementation of an ERP system and the accompanying business process modi®cations. For example, in a traditional system a customer contacting the manufacturer concerning a defect or failure of a product they want to return, would often only be able to get information within the boundaries of the information system of the individual they contacted. If this individual was in customer service, they may be limited to taking the information from the customer and promising to have a service person return the call. Even when the service person returns the call, they often have limited information about the customer, what the current installed base is for that
customer, or the original notes taken by the customer service person. At this point both the customer and the manufacturer have to provide and enter the same information twice. Companies solved this problem by allowing employees to have access to multiple systems in order to assist the customer. However, this places the burden on the employee to switch from one information system to another attempting to track down the required data. Another solution to this situation created even more frustration for the customer. This solution involved separating data access and control and requiring the customer request to pass through multiple hands before the process was complete. Some of the employees involved in resolving a problem could be in sales, product engineering, manufacturing, materials management, accounting, quality management, software development, etc. Because of the large number of potential steps of the RMA process, some organizations have established departments whose sole responsibility is this process. Another problem surfaces when the customer wants to know the status of their RMA. This requires an individual to spend a signi®cant amount of time tracking the current status of the RMA in question. With the use of ERP software, such as SAP R/3 where the data is stored centrally, one person can now answer most questions without regard to the physical progress of the transaction. However, this is not the complete solution to the RMA process problem, in view of the fact that one does not want to automate a poor process. In the next section of the paper, a RMA process is proposed using SAP R/3 that will provide both a central information source and establish the management and control structure necessary for an ef®cient and responsive process. 5. Analysis and design issues of the RMA process The initial phase in the development of any information system requires several tasks. These include understanding the process, collecting background information and requirements, and identifying any current process issues. The requirements information needs to be collected from the stakeholders providing input into the process, the process owners and users, and customers of the process.
R.F. Boykin / Computers in Industry 45 (2001) 99±109
5.1. Analysis and design issues 1. Material tracking (batch or serial numbers) Ð in order to maintain control of return material the use of serial numbers is required. This serial number usage policy must also be enforced in all areas of the organization. Customers returning material without reference to a serial number impacts the ability to determine the source and age of the material. 2. Unplanned goods receipts Ð returns of material from customers with no RMA reference provided in the shipping documents results in the material being received as an unplanned goods receipt. In the past this material would be transferred to the ``bone pile'' and closure of the RMA was done without material documentation. 3. Warranty information Ð the lack of material tracking (®rst issue) can result in time-consuming attempts to identify when the material was sold so that a sales order could be referenced to determine warranty eligibility. This lack of material tracking creates a situation where customers could provide sales order number for material under warranty, but return non-warranty material. And, with no material tracking capability this practice would be dif®cult to detect. 4. Replacements Ð customer priority levels dictate who should receive immediate shipments of replacement material. The issue here is tracking the returned material to close out the RMA. 5. Material revision level Ð this issue is related to the warranty issue where customers could return out of warranty material under the sales order number of a material in warranty. During the repair process the material would be brought up to the current revision level at no cost. The design of an information system to support the RMA process must address these issues. In addition, the system needs to also incorporate the following capabilities: 1. Collection of inspection and test results for a quality management database. The information system needs to contain the functionality to allow for collection of the inspection and test results of the returned materials. This data would then be transferred to a quality management database.
103
Material returned due to ®eld failures and the causes of those failures in critical information in accessing product quality. 2. Ability to determine the installed product base for key customers. This information is needed to accurately calculate the failure rate by product by customer. With this information an organization could identify situations where individual customers are experiencing higher the normal defect rates with certain products or product lines. 3. Customer returns assessment. This information would be used to evaluate potential return abuses. The data for this requirement needed to be collected by both channel and ®nal customer. 6. The SAP R/3 solution for the RMA process The SAP R/3 system supports the RMA process through functionality in the Sales and Distribution module called returns processing. In addition, the system supports the recording of customer complaints through functionality in the Quality Management module that can be referenced in the returns processing and the Service Management module which handles repair orders that can reference a RMA. The returns processing in SAP R/3 addresses many of the analysis and design issues identi®ed in the initial phase of the development. The creation of a RMA requires certain information that provides the management and control necessary for an effective RMA process. This information includes sales order number, customer number, batch or serial number, and material ID (model identi®cation). Through the gathering of this required information in the RMA process warranty, revision, and material replacement procedures issues are addressed. The RMA process begins at the creation of a RMA. However, there is a process that initiates the creation of the RMA. This process is the receiving and recording of customer problems and issues. The RMA is created when the customer service personnel have determined that the material is defective and ®eld repair is not an option, so then the material needs to be returned for repair. One information system that can be used for this process is ClearSupport by Clarify [10]. The RMA number is referenced in this system.
104
R.F. Boykin / Computers in Industry 45 (2001) 99±109
Fig. 2. RMA creation process.
Fig. 2 illustrates the RMA creation process. The key elements of this process are determining the serial number (a required input) and determining if the material is under warranty or not. At the completion of the process the RMA is saved and a document number is internally assigned by the SAP R/3 system. This number is then used both internally and externally to track the status of the RMA and associated activities. This number can also transferred to an
external customer relationship management (CRM) system, if one is being used. This allows individuals outside of the SAP R/3 system to have RMA status visibility. In addition, the systems (SAP R/3 and CRM) can be interfaced and information pushed to a web site for customer utilization without system queries. After the creation of the RMA, the next step in the macro process is the receipt of the material. The
R.F. Boykin / Computers in Industry 45 (2001) 99±109
105
Fig. 3. RMA material receipt process.
receipt of the material referenced in the RMA is handled through the shipping function in the Sales and Distribution module, which is integrated with the goods movement function in the Materials Management module. The speci®c process is identi®ed as ``goods receipt processing for returns.'' Fig. 3 provides a process ¯ow view of this functionality as con®gured for this case. In this process the RMA and repair order are updated to re¯ect the receipt of the material. Since the material receipt is a goods movement, a document number is determined internally and attached to the document ¯ow of the RMA. This information is also used is maintaining installed base information for key customers. The other process that occurs in the integration of the Sales and Distribution module with the Material Management module is the goods issue of the replacement material if the material is under warranty/
replacement (see Fig. 2). This process involves sending the customer a replacement material free of charge. The process ¯ow for this function is presented in Fig. 4. This process involves the creation of a free of charge sales order in the Sales and Distribution module. SAP R/3 creates a document history for this order type (free of charge). As this order is being processed documents at each set (pick, pack, ship) are attached to the order that is attached to the RMA. The drill-down capabilities of SAP R/3 allow the user to view all of this information at different levels of detail. The complete processing of the RMA involves connecting the four processes represented in Figs. 1±4 and the repair order process (Fig. 5). The repair order process involves the inspection and testing of the returned material, ordering parts to repair the material, performing the repair (including any material upgrades due to revision level), collecting costs for the repair, and transferring the material to the
106
R.F. Boykin / Computers in Industry 45 (2001) 99±109
Fig. 4. RMA material issue process.
refurbished material inventory. This process involves both the Service Management module and the Materials Management module. In addition, the process also integrates with the Controlling module (cost accounting). Fig. 5 provides a summary description of the process ¯ow for the repair operation. If the organization is outsourcing the repair operation, then a data feed from the contract repair depot will be required to update the
RMA or the contractor will need to have access to the SAP R/3 system. 7. Discussion The proposed approach for a solution to the RMA process could result in the elimination of multiple (over ®ve) legacy systems that are not integrated. Each
R.F. Boykin / Computers in Industry 45 (2001) 99±109
107
Fig. 5. Repair process.
of these systems requires a business systems analyst to maintain and update the system. While several of the systems could be maintained by one individual, often systems require a full time analyst. The integration of the entire process into a single ERP system solution would eliminate the need for at least two analysts, with one or two analyst being trained to support the process using the SAP R/3 system. Further validation of this approach is supported by the development of an RMA integrated solution by SAP in the most recent version (4.6B) of the R/3
softwares service management module [4]. This expanded functionality indicates customer desires for an improved RMA business process within the R/3 software. These customer requests are often tied to signi®cant process reengineering of the business process in question. 8. Conclusions The development of an ERP solution for the RMA process has demonstrated the need for an integrated
108
R.F. Boykin / Computers in Industry 45 (2001) 99±109
software package to effectively address customer requirements. The existing functionality in SAP R/3 provided the necessary elements to support the RMA process for the high-tech manufacturing industry. Through the integration of several different modules within SAP R/3 (Sales and Distribution, Materials Management, Service Management, Quality Management, Financial Accounting, and Controlling), a solution for the problems with an existing RMA process were addressed. The con®gured SAP R/3 solution for the RMA process addresses the issues and requirements of a return materials process. 1. Material tracking is accomplished through the requirement of a serial number before the RMA can be saved. Therefor, providing closed-loop tracking of all products. 2. The material tracking requirements of the system will also reduce the number of warranty-related issues and the material revision problem. This will result in a signi®cant cost reduction in no charge repairs for out of warranty items and free up revs of products. 3. To eliminate unplanned goods receipts for RMA material, the system requires the entering of the RMA number. This should eliminate the nonvalue-added activity of tracking down returned materials not assigned to a RMA. 4. The issue of replacements is handled through required tracking of all RMA returned materials. The free of charge sales order is linked to the RMA. This will provide the ability to track from both document chains. 5. The requirement for complete serial number tracking will facilitate the estimation of a more accurate customer installed base. In addition, through the linking of returns, repair, and replacements the installed base estimate will be automatically updated. 6. The repair order functionality of the Service Management module and the inspection functionality of the Quality Management module will improve the collection of defect data for the quality management database. 7. Finally, with the customer being linked to all documents created as a part of the RMA process, a variety of assessments can be generated using the
SAP R/3 reporting functionality. This will help in identifying potential problems and abuses of the RMA process. The current functionality of the SAP R/3 system will allow for the complete tracking of the RMA process and all of its related documents. This solution should create cost savings from a variety of areas including warranty expenses, lost returned materials, improved quality data, and better customer information. The implementation of the SAP R/3 solution for the RMA process will create a more ef®cient and cost effective method of handling returned materials. Even though the implementation of an ERP system, such as SAP R/3 is often costly and can cover a large time frame, the bene®ts can be tremendous. But, application of the ERP approach for a solution to the RMA process issue may not be suitable for all organizations. In fact, the implementation of an ERP system should not be driven by the need to improve the RMA process. However, if an organization has implemented or is planning to implement an ERP system (SAP R/3), the functionality of the software provides the organization an opportunity to improve the RMA process. Future research should include an assessment of actual post implementation results. This should include ®nancial savings, improvements in customer service, and process cycle time reductions. In addition, an examination of other ERP software packages and their RMA functionality would be interesting. References [1] N. Bancroft, H. Seip, A. Sprengel, Implementing SAP R/3, 2nd Edition, Manning Publications, Greenwich, CT, 1997. [2] ASAP World Consultancy, 1996, Special Edition: Using Sap R/3, Que, Indianapolis, IN. [3] American SAP User's Group (ASUG), http://www.asug.org/ Members/journal, accessed on 31 May 2000. [4] SAP AG, http://www.sap-ag.de/, accessed on 31 May 2000. [5] PricewaterhouseCoopers, Technology Forecast: 1999, 10th Edition, PricewaterhouseCoopers, Menlo Park, CA, 1998. [6] Price-Waterhouse, Technology Forecast: 1997, 8th Edition, Price-Waterhouse, Menlo Park, CA, 1996. [7] C. Koch, D. Slater, E. Baatz, The ABCs of ERP, CIO.com, 22 December 1999. [8] C. Koch, The Most Important Team in History, CIO Magazine, 15 October 1999.
R.F. Boykin / Computers in Industry 45 (2001) 99±109 [9] T. Davenport, Mission Critical: Realizing the Promise of Enterprise Systems, Harvard Business School Publishing, Boston, MA, 2000. [10] Clarify Inc., http://www.clarify.com/, accessed on 31 May 2000. Raymond F. Boykin is a professor of Operations Management in the College of Business at California State University, Chico (CSUC). In addition to his duties as a professor, he is also the Director of the SAP Program and coordinator of the Production and Operations Management option. Ray has published many articles in the areas of operations management, risk assessment and management, and quality related issues. His current research interests are ERP (SAP R/3), supply chain management, and business process analysis and reengineering. Ray has
109
received numerous teaching and faculty awards at CSUC; they include ®ve Outstanding Faculty awards and seven Outstanding Teacher awards, including the Chico Chamber of Commerce Teacher of the Year Ð 1997. Prior to joining the faculty at CSUC in 1986 Ray held positions at PLG, Monsanto, and Rockwell International. In addition, he remains an active consultant to numerous organizations. His industry experiences have included: SAP R/3 (MM and QM modules) implementation and con®guration, quality data warehouse, production planning models for manufacturing operations, warehouse management, material quality control, and outbound logistics. Ray was also responsible for and involved in some of the early applications of probabilistic risk assessment methodologies in chemical plant operations. Ray received his PhD in Business Administration (Management Science) at St. Louis University, his MS in Business Administration (Management Science) at San Diego State University, and his BA in Business Administration (Quantitative Methods) at California State University, Fullerton.
Enterprise resource planning software: a solution to the return material authorization problem Raymond F. Boykin* California State University, Chico, College of Business, Chico, CA 95929-0011, USA
Abstract One of the critical processes of an organizations supply chain is the return material process. Ineffective management of this process can result in ®nancial loss, poor customer service and negative quality impacts. However, often this process is given little, if any, attention even though the ®nancial and operational impacts of a poorly designed and managed returned material process are signi®cant. Because this process crosses several functional areas (materials, accounting, manufacturing, sales, and service), an integrated information system solution is required. Enterprise resource planning (ERP) systems provide a potential solution. This paper will focus on the design of a return material authorization (RMA) process and the ERP information system solution required in supporting this process. # 2001 Elsevier Science B.V. All rights reserved. Keywords: ERP; Returned materials; SAP R/3
1. Introduction The control and tracking of returned materials plays a signi®cant role in the high-tech manufacturing industry. In an industry where products costs several dollars to hundreds of thousands of dollars, the ability to manage the return materials process is critical. The lack of tracking and control can result in the loss of millions of dollars. Besides the direct ®nancial loss to the company from repairing non-warranty items for free and replacing items never returned or misplaced, there are also the issues of quality and customer satisfaction. In addition, a poorly designed and implemented return material process can create substantial negative impacts on an organizations ®nancial performance and future. The key to managing and controlling this situation is the return material authorization (RMA) process. In * Tel.: 1-530-898-5895; fax: 1-530-898-7970. E-mail address: [email protected] (R.F. Boykin).
the high-tech manufacturing industry, where product performance and reliability are critical factors in the ®nancial success of an organization, customers need a process by which to return defective products for immediate attention. This paper presents the analysis and design of a RMA process for the high-tech manufacturing industry utilizing ERP software, speci®cally SAP R/3. 2. Overview of the RMA process The RMA process involves both the physical ¯ow of material and the ¯ow of information concerning the material. The physical ¯ow of the material includes inbound logistics (customer return), the repair/refurbishment cycle (including required materials to repair and/or refurbish the item), and outbound logistics (repaired item). The information portion of the RMA process consists of the status of all RMAs including, customer contact date, transportation
0166-3615/01/$ ± see front matter # 2001 Elsevier Science B.V. All rights reserved. PII: S 0 1 6 6 - 3 6 1 5 ( 0 1 ) 0 0 0 8 3 - 5
100
R.F. Boykin / Computers in Industry 45 (2001) 99±109
information, goods receipt, repair history, scrapped items, replacement products, quality data, etc. The RMA process begins when a customer contacts the manufacturer concerning a defect or failure of a piece of equipment. Normally during this initial contact, the supplier will attempt to perform some preliminary troubleshooting to determine if the situation can be handled immediately. In some cases the pro-
blem is the result of a software issue. These can often be diagnosed and resolved over the phone or Internet. If the problem is a hardware issue, the customer will be instructed on how to return the equipment. The RMA process is often tracked and controlled through the use of a unique number assigned to each request. The customer uses this RMA number as a reference in all future communications concerning the
Fig. 1. Simpli®ed RMA process ¯ow.
R.F. Boykin / Computers in Industry 45 (2001) 99±109
equipment. The company uses this number internally to collect information on the speci®c piece of equipment. Once disposition of the returned equipment is made and repair is completed or a replacement is issued the RMA is closed. Fig. 1 presents a simpli®ed view of this process. 3. ERP and SAP R/3 Enterprise resource planning (ERP) systems are de®ned as integrated sets of comprehensive software. These sets usually include a set of mature business applications and tools for ®nancial and cost accounting, sales and distribution, materials management, human resource, production planning and computerintegrated manufacturing [1]. With combinations of these fundamental software modules, companies are able to model a wide variety of business processes [2]. Major corporations to automate and to manage their complete organization are installing ERPs. A wide variety of companies, such as Coach Manufacturing, Hewlett-Packard, Elmers products, Bristol±Meyer, Philips Automotive and Baylor College of Medicine [3] are counting on their ERP systems to coordinate order management, high volume manufacturing, patient care, customer service, product inventories, cash ¯ows, ®nancial management, etc. In addition, by interfacing ERP systems between companies, organizations are partnering to create ``business-to-business'' electronic commerce. Obviously, these systems are large and complex and by their nature require the understanding of both a focused, functional perspective and a business-wide perspective at the same time. The software companies offering this type of software include PeopleSoft, Oracle, Baan, and SAP. In this paper we focus on the current market leader in ERP systems SAP, and its product R/3. SAP R/3 is a client/server ERP system, which contains an integrated set of comprehensive software modules. These include modules for ®nancial and cost accounting, sales and distribution, materials management, human resource, production planning and computer-integrated manufacturing. The system is available in many languages and has the capability to work across the myriad of different currencies, accounting procedures and tax laws encountered by todays global organization [4].
101
The SAP has taken the ERP systems market by storm. PricewaterhouseCoopers reports the ERP market (license and maintenance revenues) at US$ 14.4 Billion in 1997 and growing at an annual rate of 20% [5]. SAP has over 15% of the market and according to Price-Waterhouse, ``its (SAPs) position in the market has boosted SAP R/3 to the defacto industry standard'' [6]. 4. RMA and SAP R/3 Software that focused on one functional area was bene®cial as long as the decision remained within that functional area. However, most decisions have crossfunctional input and impact which limits the effectiveness of the traditional software systems. Bigger problems arose when organizations attempted to have two or more function-based software systems (often called legacy systems) communicate. The results from this approach have been slow transactions, corrupted data, and a large software support organization. Business enterprise software, or ERP software as it is often called, takes a totally different approach. There is a single repository of data, with all the applications using this same database. The software is designed for integration rather than unlimited functionality. This approach may reduce the level of functionality of existing stand-alone systems. However, this reduction in functionality is trivial compared to the ability of having all applications working together. The major bene®t of an ERP system is that a transaction can be uniformly managed from the point of inception to it ®nal disposition. Having the software control the transaction work¯ow is a powerful force, however, processes must be reengineered so that unnecessary or redundant operations can be eliminated. In the implementation of ERP systems, one can either reengineer the process to match the functionality of the software or customize the software to match the existing process. While the former approach has proven more logical and effective, historically ERP implementations have had to deal with the critical issue of changing the business process or modifying the software. In the past, one of the most common reasons why ERP implementations failed was the companies
102
R.F. Boykin / Computers in Industry 45 (2001) 99±109
discovered during the implementation that the ERP system did not support one of their important business processes [7]. The solution to this problem is changing the business process to match the ERP systems process or customize the ERP software to ®t the companys process. Each alternative has drawbacks. Changing the business process creates turmoil within an organization and modifying the software can delay the project and make software upgrades much more dif®cult in the future. The solution can be a compromise between complete process redesign and massive software modi®cation. However, many companies tend to take the advice of their ERP software vendor and focus more on process changes. In a study by Deloitte Consulting LLC, one in four companies implementing an ERP system indicated that company performance dropped when the ERP system went live [8]. The study revealed that this initial performance problem was most often the result of business processes being changed. Organizations often took 3±9 months to recover from this performance dip. This provides some evidence to the impact of modifying business processes without fully understanding all consequences. It also supports the position that not all business processes should be drastically modi®ed in line with the ERP software. In his book Mission Critical, Thomas Davenport documents some successful ERP implementations that used the software as a driving force behind process reengineering [9]. Davenport [9] states that companies ``. . . recognized that transaction data could'' create opportunities for redesigning fundamental business processes that create entirely new sets of decisions. This research points to the potential improvements realized through the implementation of an ERP system and the accompanying business process modi®cations. For example, in a traditional system a customer contacting the manufacturer concerning a defect or failure of a product they want to return, would often only be able to get information within the boundaries of the information system of the individual they contacted. If this individual was in customer service, they may be limited to taking the information from the customer and promising to have a service person return the call. Even when the service person returns the call, they often have limited information about the customer, what the current installed base is for that
customer, or the original notes taken by the customer service person. At this point both the customer and the manufacturer have to provide and enter the same information twice. Companies solved this problem by allowing employees to have access to multiple systems in order to assist the customer. However, this places the burden on the employee to switch from one information system to another attempting to track down the required data. Another solution to this situation created even more frustration for the customer. This solution involved separating data access and control and requiring the customer request to pass through multiple hands before the process was complete. Some of the employees involved in resolving a problem could be in sales, product engineering, manufacturing, materials management, accounting, quality management, software development, etc. Because of the large number of potential steps of the RMA process, some organizations have established departments whose sole responsibility is this process. Another problem surfaces when the customer wants to know the status of their RMA. This requires an individual to spend a signi®cant amount of time tracking the current status of the RMA in question. With the use of ERP software, such as SAP R/3 where the data is stored centrally, one person can now answer most questions without regard to the physical progress of the transaction. However, this is not the complete solution to the RMA process problem, in view of the fact that one does not want to automate a poor process. In the next section of the paper, a RMA process is proposed using SAP R/3 that will provide both a central information source and establish the management and control structure necessary for an ef®cient and responsive process. 5. Analysis and design issues of the RMA process The initial phase in the development of any information system requires several tasks. These include understanding the process, collecting background information and requirements, and identifying any current process issues. The requirements information needs to be collected from the stakeholders providing input into the process, the process owners and users, and customers of the process.
R.F. Boykin / Computers in Industry 45 (2001) 99±109
5.1. Analysis and design issues 1. Material tracking (batch or serial numbers) Ð in order to maintain control of return material the use of serial numbers is required. This serial number usage policy must also be enforced in all areas of the organization. Customers returning material without reference to a serial number impacts the ability to determine the source and age of the material. 2. Unplanned goods receipts Ð returns of material from customers with no RMA reference provided in the shipping documents results in the material being received as an unplanned goods receipt. In the past this material would be transferred to the ``bone pile'' and closure of the RMA was done without material documentation. 3. Warranty information Ð the lack of material tracking (®rst issue) can result in time-consuming attempts to identify when the material was sold so that a sales order could be referenced to determine warranty eligibility. This lack of material tracking creates a situation where customers could provide sales order number for material under warranty, but return non-warranty material. And, with no material tracking capability this practice would be dif®cult to detect. 4. Replacements Ð customer priority levels dictate who should receive immediate shipments of replacement material. The issue here is tracking the returned material to close out the RMA. 5. Material revision level Ð this issue is related to the warranty issue where customers could return out of warranty material under the sales order number of a material in warranty. During the repair process the material would be brought up to the current revision level at no cost. The design of an information system to support the RMA process must address these issues. In addition, the system needs to also incorporate the following capabilities: 1. Collection of inspection and test results for a quality management database. The information system needs to contain the functionality to allow for collection of the inspection and test results of the returned materials. This data would then be transferred to a quality management database.
103
Material returned due to ®eld failures and the causes of those failures in critical information in accessing product quality. 2. Ability to determine the installed product base for key customers. This information is needed to accurately calculate the failure rate by product by customer. With this information an organization could identify situations where individual customers are experiencing higher the normal defect rates with certain products or product lines. 3. Customer returns assessment. This information would be used to evaluate potential return abuses. The data for this requirement needed to be collected by both channel and ®nal customer. 6. The SAP R/3 solution for the RMA process The SAP R/3 system supports the RMA process through functionality in the Sales and Distribution module called returns processing. In addition, the system supports the recording of customer complaints through functionality in the Quality Management module that can be referenced in the returns processing and the Service Management module which handles repair orders that can reference a RMA. The returns processing in SAP R/3 addresses many of the analysis and design issues identi®ed in the initial phase of the development. The creation of a RMA requires certain information that provides the management and control necessary for an effective RMA process. This information includes sales order number, customer number, batch or serial number, and material ID (model identi®cation). Through the gathering of this required information in the RMA process warranty, revision, and material replacement procedures issues are addressed. The RMA process begins at the creation of a RMA. However, there is a process that initiates the creation of the RMA. This process is the receiving and recording of customer problems and issues. The RMA is created when the customer service personnel have determined that the material is defective and ®eld repair is not an option, so then the material needs to be returned for repair. One information system that can be used for this process is ClearSupport by Clarify [10]. The RMA number is referenced in this system.
104
R.F. Boykin / Computers in Industry 45 (2001) 99±109
Fig. 2. RMA creation process.
Fig. 2 illustrates the RMA creation process. The key elements of this process are determining the serial number (a required input) and determining if the material is under warranty or not. At the completion of the process the RMA is saved and a document number is internally assigned by the SAP R/3 system. This number is then used both internally and externally to track the status of the RMA and associated activities. This number can also transferred to an
external customer relationship management (CRM) system, if one is being used. This allows individuals outside of the SAP R/3 system to have RMA status visibility. In addition, the systems (SAP R/3 and CRM) can be interfaced and information pushed to a web site for customer utilization without system queries. After the creation of the RMA, the next step in the macro process is the receipt of the material. The
R.F. Boykin / Computers in Industry 45 (2001) 99±109
105
Fig. 3. RMA material receipt process.
receipt of the material referenced in the RMA is handled through the shipping function in the Sales and Distribution module, which is integrated with the goods movement function in the Materials Management module. The speci®c process is identi®ed as ``goods receipt processing for returns.'' Fig. 3 provides a process ¯ow view of this functionality as con®gured for this case. In this process the RMA and repair order are updated to re¯ect the receipt of the material. Since the material receipt is a goods movement, a document number is determined internally and attached to the document ¯ow of the RMA. This information is also used is maintaining installed base information for key customers. The other process that occurs in the integration of the Sales and Distribution module with the Material Management module is the goods issue of the replacement material if the material is under warranty/
replacement (see Fig. 2). This process involves sending the customer a replacement material free of charge. The process ¯ow for this function is presented in Fig. 4. This process involves the creation of a free of charge sales order in the Sales and Distribution module. SAP R/3 creates a document history for this order type (free of charge). As this order is being processed documents at each set (pick, pack, ship) are attached to the order that is attached to the RMA. The drill-down capabilities of SAP R/3 allow the user to view all of this information at different levels of detail. The complete processing of the RMA involves connecting the four processes represented in Figs. 1±4 and the repair order process (Fig. 5). The repair order process involves the inspection and testing of the returned material, ordering parts to repair the material, performing the repair (including any material upgrades due to revision level), collecting costs for the repair, and transferring the material to the
106
R.F. Boykin / Computers in Industry 45 (2001) 99±109
Fig. 4. RMA material issue process.
refurbished material inventory. This process involves both the Service Management module and the Materials Management module. In addition, the process also integrates with the Controlling module (cost accounting). Fig. 5 provides a summary description of the process ¯ow for the repair operation. If the organization is outsourcing the repair operation, then a data feed from the contract repair depot will be required to update the
RMA or the contractor will need to have access to the SAP R/3 system. 7. Discussion The proposed approach for a solution to the RMA process could result in the elimination of multiple (over ®ve) legacy systems that are not integrated. Each
R.F. Boykin / Computers in Industry 45 (2001) 99±109
107
Fig. 5. Repair process.
of these systems requires a business systems analyst to maintain and update the system. While several of the systems could be maintained by one individual, often systems require a full time analyst. The integration of the entire process into a single ERP system solution would eliminate the need for at least two analysts, with one or two analyst being trained to support the process using the SAP R/3 system. Further validation of this approach is supported by the development of an RMA integrated solution by SAP in the most recent version (4.6B) of the R/3
softwares service management module [4]. This expanded functionality indicates customer desires for an improved RMA business process within the R/3 software. These customer requests are often tied to signi®cant process reengineering of the business process in question. 8. Conclusions The development of an ERP solution for the RMA process has demonstrated the need for an integrated
108
R.F. Boykin / Computers in Industry 45 (2001) 99±109
software package to effectively address customer requirements. The existing functionality in SAP R/3 provided the necessary elements to support the RMA process for the high-tech manufacturing industry. Through the integration of several different modules within SAP R/3 (Sales and Distribution, Materials Management, Service Management, Quality Management, Financial Accounting, and Controlling), a solution for the problems with an existing RMA process were addressed. The con®gured SAP R/3 solution for the RMA process addresses the issues and requirements of a return materials process. 1. Material tracking is accomplished through the requirement of a serial number before the RMA can be saved. Therefor, providing closed-loop tracking of all products. 2. The material tracking requirements of the system will also reduce the number of warranty-related issues and the material revision problem. This will result in a signi®cant cost reduction in no charge repairs for out of warranty items and free up revs of products. 3. To eliminate unplanned goods receipts for RMA material, the system requires the entering of the RMA number. This should eliminate the nonvalue-added activity of tracking down returned materials not assigned to a RMA. 4. The issue of replacements is handled through required tracking of all RMA returned materials. The free of charge sales order is linked to the RMA. This will provide the ability to track from both document chains. 5. The requirement for complete serial number tracking will facilitate the estimation of a more accurate customer installed base. In addition, through the linking of returns, repair, and replacements the installed base estimate will be automatically updated. 6. The repair order functionality of the Service Management module and the inspection functionality of the Quality Management module will improve the collection of defect data for the quality management database. 7. Finally, with the customer being linked to all documents created as a part of the RMA process, a variety of assessments can be generated using the
SAP R/3 reporting functionality. This will help in identifying potential problems and abuses of the RMA process. The current functionality of the SAP R/3 system will allow for the complete tracking of the RMA process and all of its related documents. This solution should create cost savings from a variety of areas including warranty expenses, lost returned materials, improved quality data, and better customer information. The implementation of the SAP R/3 solution for the RMA process will create a more ef®cient and cost effective method of handling returned materials. Even though the implementation of an ERP system, such as SAP R/3 is often costly and can cover a large time frame, the bene®ts can be tremendous. But, application of the ERP approach for a solution to the RMA process issue may not be suitable for all organizations. In fact, the implementation of an ERP system should not be driven by the need to improve the RMA process. However, if an organization has implemented or is planning to implement an ERP system (SAP R/3), the functionality of the software provides the organization an opportunity to improve the RMA process. Future research should include an assessment of actual post implementation results. This should include ®nancial savings, improvements in customer service, and process cycle time reductions. In addition, an examination of other ERP software packages and their RMA functionality would be interesting. References [1] N. Bancroft, H. Seip, A. Sprengel, Implementing SAP R/3, 2nd Edition, Manning Publications, Greenwich, CT, 1997. [2] ASAP World Consultancy, 1996, Special Edition: Using Sap R/3, Que, Indianapolis, IN. [3] American SAP User's Group (ASUG), http://www.asug.org/ Members/journal, accessed on 31 May 2000. [4] SAP AG, http://www.sap-ag.de/, accessed on 31 May 2000. [5] PricewaterhouseCoopers, Technology Forecast: 1999, 10th Edition, PricewaterhouseCoopers, Menlo Park, CA, 1998. [6] Price-Waterhouse, Technology Forecast: 1997, 8th Edition, Price-Waterhouse, Menlo Park, CA, 1996. [7] C. Koch, D. Slater, E. Baatz, The ABCs of ERP, CIO.com, 22 December 1999. [8] C. Koch, The Most Important Team in History, CIO Magazine, 15 October 1999.
R.F. Boykin / Computers in Industry 45 (2001) 99±109 [9] T. Davenport, Mission Critical: Realizing the Promise of Enterprise Systems, Harvard Business School Publishing, Boston, MA, 2000. [10] Clarify Inc., http://www.clarify.com/, accessed on 31 May 2000. Raymond F. Boykin is a professor of Operations Management in the College of Business at California State University, Chico (CSUC). In addition to his duties as a professor, he is also the Director of the SAP Program and coordinator of the Production and Operations Management option. Ray has published many articles in the areas of operations management, risk assessment and management, and quality related issues. His current research interests are ERP (SAP R/3), supply chain management, and business process analysis and reengineering. Ray has
109
received numerous teaching and faculty awards at CSUC; they include ®ve Outstanding Faculty awards and seven Outstanding Teacher awards, including the Chico Chamber of Commerce Teacher of the Year Ð 1997. Prior to joining the faculty at CSUC in 1986 Ray held positions at PLG, Monsanto, and Rockwell International. In addition, he remains an active consultant to numerous organizations. His industry experiences have included: SAP R/3 (MM and QM modules) implementation and con®guration, quality data warehouse, production planning models for manufacturing operations, warehouse management, material quality control, and outbound logistics. Ray was also responsible for and involved in some of the early applications of probabilistic risk assessment methodologies in chemical plant operations. Ray received his PhD in Business Administration (Management Science) at St. Louis University, his MS in Business Administration (Management Science) at San Diego State University, and his BA in Business Administration (Quantitative Methods) at California State University, Fullerton.