None Provided19, Business, College Term Papers.com


		Data Bases
		• Custom Term Papers • Free Term Papers • Free Research Papers • Free Essays • Free Book Reports • Plagiarism?

		Links
		• Top 100 Term Paper Sites • Top 25 Essay Sites • Top 50 Essay Sites • Search 97,000 Papers @ DirectEssays.com • Search 101,000 Papers @ ExampleEssays.com • Search 90,000 Papers @ MegaEssays.com

		Free Essays
		• Term Paper Sites • Chuck III's Free Essays • Free College Essays • TermPaperSites.com • My Term Papers • Get Free Essays • Essay World • Planet Papers

Search Lots of Essays

Back to Subjects - Business

None Provided19

None Provided19 Warehouse Management System Implementation Analysis A review of the Belvidere, NJ. Site WMS Warehouse Management System Implementation Analysis A review of the Belvidere, NJ. Site WMS Introduction………………………………...................................................... 1 Background Information………………………………................................... 1 Developing Design Specifications………………………………................... 2 Programming and Testing………………………………................................ 4 Employee Training………………………………............................................ 5 Implementation………………………………................................................. 6 Post Implementation………………………………......................................... 6 Conclusion………………………………..........................................................8 A management team that has been through the pain and aggravation of implementing a warehouse management system (WMS) understands the pressures involved in the installation. There are numerous deadlines that must be met and potential show stoppers are encountered almost daily. These must be resolved before proceeding to the next step. In June of this year, our primary warehouse in the United States implemented an SAP Warehouse Management System (WMS) in the finished goods storage area. This report addresses the successes and failures encountered during the course of the implementation and for the first three months afterwards. Though operating with the SAP R/3 system, the current process of order fulfillment was paper based; After a customer order had been entered into our operating system and transmitted by our national call center, warehouse office personnel would print out a pick ticket and hand over to the warehouse order picker for picking and shipment processing. Once the order had been prepared for shipment, the paperwork was returned to the office personnel who would then complete the Bill of Lading and arrange transportation. This was a process that had been in place since computers were introduced in the early 1980’s. And though functional, major problems were occurring on a daily basis. Picking errors were a primary concern as order accuracy averaged between 60% and 90% on a monthly basis. Inventory accuracy was also a concern. The act of conducting a physical inventory occurs once per year and the results of their last count in 2000 was less than 20% accuracy. And as a result of prior project, the warehouse had also reduced head count from 26 in 1999 to 19 as of January of this year. All of these factors contributed to customer dissatisfaction. Customer orders were routinely delayed during periods of high order activity and when they did arrive, most likely either be incomplete or contain the wrong item. In fact, there were several customers within this warehouse’s service territory that had requested to have their orders shipped from our other warehouses. In December of 2000, site management, to address the problems of customer dissatisfaction and general warehouse inefficiency, obtained the approval to purchase and install the WMS module. Although in my opinion, implementing a WMS is a great step forward, I also believe automating the warehouse in an attempt to fix a broken process is a mistake and doomed to failure. Years of official and unofficial policy results in a lengthy series of inefficient procedures. This "Band-Aid" approach to addressing issues creates exception processes that hinder productivity and increase costs. Unless these problems are corrected, they become part of the design documentation. The result is a system that helps the organization do all the things it has been doing wrong – faster. A WMS is designed to improve the flow of information within a warehouse only. By itself, it will not improve inventory accuracy, order accuracy or compensate for insufficient staffing. One of the greatest misconceptions I heard was that the WMS would allow for the site to reduce headcount further. While it is true that a WMS will improve true warehouse task efficiencies by managing and allowing for complex tasks, the cost for this is that it usually requires additional manpower to monitor the system. A reduction in warehouse worker headcount is offset by administrative department headcount, in effect. From our initial meeting with the WMS project manager, we began to examine every process step to determine the intent and efficiency. This included the movement of products as well and the movement of information. By carefully documenting our true core requirements and then seeking a solution that will address these needs, our goal was to efficiently implement a solution that will provide benefits beyond the initial project charter. As I expected, many inefficiencies emerged across all areas of our operation. In these cases, proposed changes were made, tested, and if successful, included in the documentation. Since we planned to use radio frequency scanners, we also had an RF survey taken. This survey establishes where the receivers and transmitters are to be placed within the warehouse and ensures there will be no dead areas. Concurrent with this project, we also had to implement a bar code label project so that the RF scanners had information they could read. We had purchased and installed the label printers and software the prior year, we now had to review each of our labels to determine if they were compatible with the RF scanners and contained all the required information. In addition to labels containing product information, we would also need to assign bar codes labels to each rack location. When picking and moving stock to and from a location, warehouse personnel must verify the location they are working in. We needed to ensure this was a simple and easily understandable process to gain employee acceptance. The RF survey and our process documentation were returned to the WMS project manager to develop program and warehouse strategy documents. In this process, the project manager evaluates and matches our requirements to the RF and WMS systems capabilities. Several documents are generated. One document identifies the settings required within each software program, and what if any, customization is required. A second document outlines the warehouse process flows from an informational perspective. Our next step was to review the documentation to ensure all processes were detailed. One of the biggest uncertainties when using an off-the-shelf program is that the operation is more complex than what the system was originally designed to handle. No doubt the operation is complex and unique, but that is not necessarily good way. There are pros and cons associated with choosing an off-the-shelf program over a custom built program. Specifically, the implementation time is considerably shorter with an off-the-shelf program. It also guarantees there will be support available if and when problems are encountered. The down side is that adaptability, though typically robust, still has limitations that prohibit customization. Upon our review, we did discover several processes that had been changed due to the standard software configuration. In these cases, after lengthy discussions, we determined what we could accept and what needed to be re-programmed. Another step we had to complete was the configuration of the warehouse. That is, determining where product would be situated, to develop the general flow of the warehouse, and select picking strategies. The makeup of a typical customer order consists of mixed products on the same pallet. When building a pallet, we try to put the larger, heavier products on the bottom and smaller, lighter products on top. We also completed an ABC analysis to determine the products that are picked most often. We ended up with a compromise of the two philosophies by moving the heavier, faster moving items closest to the dock doors and then lighter, slower moving product towards the back of the warehouse. Picking slots would be at the floor level of each bay of rack with overstock in the 2nd, 3rd and 4th tiers of the bays. We also labeled each location with a bar code in a way that allowed picking on both sides of the aisles. This guaranteed only one pass down each aisle. We also developed a picking strategy in case the picking location was stocked out, that the system would search and direct the order picker to the next closest pallet of product. After the design specifications had been agreed upon and approved by all parties, work rapidly began to implement the design. Interfaces were built and linked between the RF scanning software and SAP R/3 and the SAP WMS module. As work progressed, completed pieces of the system were loaded into a beta test region. Concurrent to this activity, training programs were being developed detailing each step in a particular process. Each training program included written documentation, power point presentations and actual exercises to be used with the RF scanners. It was clearly understood that success or failure depended upon employee buy in of the system. Once the design was incorporated into a working model, the system undergoes extensive testing by the project manager. In this phase, we are trying to break the system, to detect and repair any defects. Once tested, the system was ready to be used for training purposes. Training classes were then offered for administrative and warehouse personnel. Employees should be given system exposure and training to build both a comfort level and a functional understanding of the changes that wait them. As I critique this portion of the project, in my opinion we failed miserably. After the initial introduction, it was left up to the employee to schedule time to conduct training. In addition, I am sure that we didn’t have the buy in of these employees as we later found out that a few employees were purposely trying to sabotage the system. A few felt their job was threatened and thought they would be eliminated. Others felt the new system was too cumbersome and if it failed, then we would go back to the old way of processing orders. Some did take the time and tried to learn the system. Site management should have set aside time and mandated employees to attend on a regular basis. Employee buy in should have been at the forefront of everyone. After implementation, I also learned that management had only concentrated on defining the order fulfillment process. Several processes had not been documented. This led to much confusion in each of the receiving processes. Once all the planning had been completed, we found the actual implementation date fast approaching. I had made several trips to this warehouse at periodic intervals to monitor the progress and was told they were all set. It appeared that all bases had been covered. A physical inventory was conducted the day prior to the implementation. This was to ensure that accurate data was transferred over to the new system. This went smoothly and we felt confident in the inventory accuracy. The implementation was scheduled over a weekend and is a full of activities. The project manager pulled all inventory information out of SAP R/3. He then turned on the new system by moving the beta version into the live region. After that, a few tests were ran to determine if the program had transitioned correctly. So far so good. We then reloaded the inventory into the new system. The remainder of the day was spent validating the inventory to ensure it had been transferred without any discrepancies. Once this had been verified, selected orders were issued to warehouse personnel to pick, pack and stage and then processed as being shipped. The purpose was to actually test to ensure the system was working properly. Overall this stage was very successful and appeared to have gone smoothly with minimal problems. On Monday, the first live day with the new system, we began to notice that the time required to process orders was very slow. Orders to be shipped began stacking up as we were able to process around 20 orders, though we usually see around 80 orders per day. This didn’t cause too much alarm as we expected a deterioration due to the learning curve of our employees. Most of the managers time was devoted to working with the order pickers making sure they understood the process. As the week went on, the number of orders waiting to be processed grew. We became more and more alarmed as we noticed that the number of orders processed each day was not increasing. We realized this was going to take a lot longer getting up to speed than we had anticipated. Our project manager was able to identify several minor issues and worked on correcting them and management continued to work with the order pickers. As the weeks went on, very little improvement was seen regarding the number of orders shipped each day. In addition, from the lack of having fully documented receiving processes, our receiving area was backing up and contributing to stock outs. By the third week, I decided to reallocate customer order volume from this facility. In all about 20% of this warehouse’s volume was transferred to another warehouse to help relieve some pressure. The warehouse had implemented mandatory overtime and employees were working almost 60 hours per week. In August, two major changes were made to the system. One involved an adjustment to the bin replenishment strategy. Up to this point, the WMS was directing replenishments as they were needed. By changing the setting to only allow replenishments at specified times of the day, this freed up valuable manpower to be allocated to order processing. The second change was actually a fix to the software. Sporadically, an order picker would get a system error which occurred when there was a slowdown in the interface exchange of information. Basically, one system would create a log jamb preventing additional transactions to be processed real time. When this happened, the order picker would have to log out of the scanner and log back in. By installing a faster server, we were able to eliminate this from happening. I was also called back to the warehouse during this time to document two separate receiving processes. By the end of August, significant gains had been made as we were able to process around 50 to 60 orders per day. Still not back up to full speed though. During the month of September, we began analyzing the data provided by the WMS system. We were able to determine by employee, how long it was taking them to process and order. Surprisingly at the time, we noticed two or three individuals who were not performing at the same standard as the rest of our employees. Picking errors were also high. It was during employee interviews, we found out that these individuals were trying to sabotage the system in the hopes it would fail. Overall employee morale was severely low due to the increased workload and mandatory overtime. Corrective actions were immediately taken including the dismissal of one employee. Overall, for the month, we were making significant progress in order processing. In October, we were able to transition the additional order volume back to the primary warehouse. The site is now at or above the goals of orders shipped complete. However, there are still some problems associated with the staffing levels. In any warehouse operation it is important to consider the impact the project will have on the overall facility. A significant benefit of a WMS is the discipline it instills within the warehouse. The process dictates a specific work flow and accountability through real-time data capture and directed task management. Without a doubt, the facility’s culture and employee morale will be affected by the system. It should be understood by all that a WMS system will not correct a warehouse that is experiencing operational problems. When designing the system, build it with the idea of how to improve processes. Another important point to note is that employee training and buy in is critical. Employees at every level directly affected by the new system need to be involved in the development of the processes. You should also be realistic that there is going to be a learning curve. Expect and plan for several weeks or months of below par performance. The implementation team should extensively test the system. Try to crash it! And be aware of how the system reacts when changes are implemented. Overall, I was impressed by our implementation. There were a few stumbling blocks encountered but by putting our heads together, we were able to overcome them. Arnold, J.R. Tony, Materials Management, 2nd Edition Upper Saddle River, NJ., Authors not listed, Do You Need a WMS? 1996 http://www.isit.com/st/documents/document2471.htm Hudock, Brian, Implementing Warehouse Management? 10 Mistakes to Avoid Tompkins Associates, July 1997 Accessed on 25 Nov, 2001 http://www-us-tech.com/july97/biz/mgmnt06.htm Singer, Tom, Tompkins Associates - Competitive Edge Volume 6, Issue3, Page 13-14 Tompkins, James A & Harmelink, Dale. The Distribution Management Handbook Lexington, McGraw-Hill, 1994 Warehouse Management System Implementation Analysis A review of the Belvidere, NJ. Site WMS Warehouse Management System Implementation Analysis A review of the Belvidere, NJ. Site WMS Introduction………………………………...................................................... 1 Background Information………………………………................................... 1 Developing Design Specifications………………………………................... 2 Programming and Testing………………………………................................ 4 Employee Training………………………………............................................ 5 Implementation………………………………................................................. 6 Post Implementation………………………………......................................... 6 Conclusion………………………………..........................................................8 A management team that has been through the pain and aggravation of implementing a warehouse management system (WMS) understands the pressures involved in the installation. There are numerous deadlines that must be met and potential show stoppers are encountered almost daily. These must be resolved before proceeding to the next step. In June of this year, our primary warehouse in the United States implemented an SAP Warehouse Management System (WMS) in the finished goods storage area. This report addresses the successes and failures encountered during the course of the implementation and for the first three months afterwards. Though operating with the SAP R/3 system, the current process of order fulfillment was paper based; After a customer order had been entered into our operating system and transmitted by our national call center, warehouse office personnel would print out a pick ticket and hand over to the warehouse order picker for picking and shipment processing. Once the order had been prepared for shipment, the paperwork was returned to the office personnel who would then complete the Bill of Lading and arrange transportation. This was a process that had been in place since computers were introduced in the early 1980’s. And though functional, major problems were occurring on a daily basis. Picking errors were a primary concern as order accuracy averaged between 60% and 90% on a monthly basis. Inventory accuracy was also a concern. The act of conducting a physical inventory occurs once per year and the results of their last count in 2000 was less than 20% accuracy. And as a result of prior project, the warehouse had also reduced head count from 26 in 1999 to 19 as of January of this year. All of these factors contributed to customer dissatisfaction. Customer orders were routinely delayed during periods of high order activity and when they did arrive, most likely either be incomplete or contain the wrong item. In fact, there were several customers within this warehouse’s service territory that had requested to have their orders shipped from our other warehouses. In December of 2000, site management, to address the problems of customer dissatisfaction and general warehouse inefficiency, obtained the approval to purchase and install the WMS module. Although in my opinion, implementing a WMS is a great step forward, I also believe automating the warehouse in an attempt to fix a broken process is a mistake and doomed to failure. Years of official and unofficial policy results in a lengthy series of inefficient procedures. This "Band-Aid" approach to addressing issues creates exception processes that hinder productivity and increase costs. Unless these problems are corrected, they become part of the design documentation. The result is a system that helps the organization do all the things it has been doing wrong – faster. A WMS is designed to improve the flow of information within a warehouse only. By itself, it will not improve inventory accuracy, order accuracy or compensate for insufficient staffing. One of the greatest misconceptions I heard was that the WMS would allow for the site to reduce headcount further. While it is true that a WMS will improve true warehouse task efficiencies by managing and allowing for complex tasks, the cost for this is that it usually requires additional manpower to monitor the system. A reduction in warehouse worker headcount is offset by administrative department headcount, in effect. From our initial meeting with the WMS project manager, we began to examine every process step to determine the intent and efficiency. This included the movement of products as well and the movement of information. By carefully documenting our true core requirements and then seeking a solution that will address these needs, our goal was to efficiently implement a solution that will provide benefits beyond the initial project charter. As I expected, many inefficiencies emerged across all areas of our operation. In these cases, proposed changes were made, tested, and if successful, included in the documentation. Since we planned to use radio frequency scanners, we also had an RF survey taken. This survey establishes where the receivers and transmitters are to be placed within the warehouse and ensures there will be no dead areas. Concurrent with this project, we also had to implement a bar code label project so that the RF scanners had information they could read. We had purchased and installed the label printers and software the prior year, we now had to review each of our labels to determine if they were compatible with the RF scanners and contained all the required information. In addition to labels containing product information, we would also need to assign bar codes labels to each rack location. When picking and moving stock to and from a location, warehouse personnel must verify the location they are working in. We needed to ensure this was a simple and easily understandable process to gain employee acceptance. The RF survey and our process documentation were returned to the WMS project manager to develop program and warehouse strategy documents. In this process, the project manager evaluates and matches our requirements to the RF and WMS systems capabilities. Several documents are generated. One document identifies the settings required within each software program, and what if any, customization is required. A second document outlines the warehouse process flows from an informational perspective. Our next step was to review the documentation to ensure all processes were detailed. One of the biggest uncertainties when using an off-the-shelf program is that the operation is more complex than what the system was originally designed to handle. No doubt the operation is complex and unique, but that is not necessarily good way. There are pros and cons associated with choosing an off-the-shelf program over a custom built program. Specifically, the implementation time is considerably shorter with an off-the-shelf program. It also guarantees there will be support available if and when problems are encountered. The down side is that adaptability, though typically robust, still has limitations that prohibit customization. Upon our review, we did discover several processes that had been changed due to the standard software configuration. In these cases, after lengthy discussions, we determined what we could accept and what needed to be re-programmed. Another step we had to complete was the configuration of the warehouse. That is, determining where product would be situated, to develop the general flow of the warehouse, and select picking strategies. The makeup of a typical customer order consists of mixed products on the same pallet. When building a pallet, we try to put the larger, heavier products on the bottom and smaller, lighter products on top. We also completed an ABC analysis to determine the products that are picked most often. We ended up with a compromise of the two philosophies by moving the heavier, faster moving items closest to the dock doors and then lighter, slower moving product towards the back of the warehouse. Picking slots would be at the floor level of each bay of rack with overstock in the 2nd, 3rd and 4th tiers of the bays. We also labeled each location with a bar code in a way that allowed picking on both sides of the aisles. This guaranteed only one pass down each aisle. We also developed a picking strategy in case the picking location was stocked out, that the system would search and direct the order picker to the next closest pallet of product. After the design specifications had been agreed upon and approved by all parties, work rapidly began to implement the design. Interfaces were built and linked between the RF scanning software and SAP R/3 and the SAP WMS module. As work progressed, completed pieces of the system were loaded into a beta test region. Concurrent to this activity, training programs were being developed detailing each step in a particular process. Each training program included written documentation, power point presentations and actual exercises to be used with the RF scanners. It was clearly understood that success or failure depended upon employee buy in of the system. Once the design was incorporated into a working model, the system undergoes extensive testing by the project manager. In this phase, we are trying to break the system, to detect and repair any defects. Once tested, the system was ready to be used for training purposes. Training classes were then offered for administrative and warehouse personnel. Employees should be given system exposure and training to build both a comfort level and a functional understanding of the changes that wait them. As I critique this portion of the project, in my opinion we failed miserably. After the initial introduction, it was left up to the employee to schedule time to conduct training. In addition, I am sure that we didn’t have the buy in of these employees as we later found out that a few employees were purposely trying to sabotage the system. A few felt their job was threatened and thought they would be eliminated. Others felt the new system was too cumbersome and if it failed, then we would go back to the old way of processing orders. Some did take the time and tried to learn the system. Site management should have set aside time and mandated employees to attend on a regular basis. Employee buy in should have been at the forefront of everyone. After implementation, I also learned that management had only concentrated on defining the order fulfillment process. Several processes had not been documented. This led to much confusion in each of the receiving processes. Once all the planning had been completed, we found the actual implementation date fast approaching. I had made several trips to this warehouse at periodic intervals to monitor the progress and was told they were all set. It appeared that all bases had been covered. A physical inventory was conducted the day prior to the implementation. This was to ensure that accurate data was transferred over to the new system. This went smoothly and we felt confident in the inventory accuracy. The implementation was scheduled over a weekend and is a full of activities. The project manager pulled all inventory information out of SAP R/3. He then turned on the new system by moving the beta version into the live region. After that, a few tests were ran to determine if the program had transitioned correctly. So far so good. We then reloaded the inventory into the new system. The remainder of the day was spent validating the inventory to ensure it had been transferred without any discrepancies. Once this had been verified, selected orders were issued to warehouse personnel to pick, pack and stage and then processed as being shipped. The purpose was to actually test to ensure the system was working properly. Overall this stage was very successful and appeared to have gone smoothly with minimal problems. On Monday, the first live day with the new system, we began to notice that the time required to process orders was very slow. Orders to be shipped began stacking up as we were able to process around 20 orders, though we usually see around 80 orders per day. This didn’t cause too much alarm as we expected a deterioration due to the learning curve of our employees. Most of the managers time was devoted to working with the order pickers making sure they understood the process. As the week went on, the number of orders waiting to be processed grew. We became more and more alarmed as we noticed that the number of orders processed each day was not increasing. We realized this was going to take a lot longer getting up to speed than we had anticipated. Our project manager was able to identify several minor issues and worked on correcting them and management continued to work with the order pickers. As the weeks went on, very little improvement was seen regarding the number of orders shipped each day. In addition, from the lack of having fully documented receiving processes, our receiving area was backing up and contributing to stock outs. By the third week, I decided to reallocate customer order volume from this facility. In all about 20% of this warehouse’s volume was transferred to another warehouse to help relieve some pressure. The warehouse had implemented mandatory overtime and employees were working almost 60 hours per week. In August, two major changes were made to the system. One involved an adjustment to the bin replenishment strategy. Up to this point, the WMS was directing replenishments as they were needed. By changing the setting to only allow replenishments at specified times of the day, this freed up valuable manpower to be allocated to order processing. The second change was actually a fix to the software. Sporadically, an order picker would get a system error which occurred when there was a slowdown in the interface exchange of information. Basically, one system would create a log jamb preventing additional transactions to be processed real time. When this happened, the order picker would have to log out of the scanner and log back in. By installing a faster server, we were able to eliminate this from happening. I was also called back to the warehouse during this time to document two separate receiving processes. By the end of August, significant gains had been made as we were able to process around 50 to 60 orders per day. Still not back up to full speed though. During the month of September, we began analyzing the data provided by the WMS system. We were able to determine by employee, how long it was taking them to process and order. Surprisingly at the time, we noticed two or three individuals who were not performing at the same standard as the rest of our employees. Picking errors were also high. It was during employee interviews, we found out that these individuals were trying to sabotage the system in the hopes it would fail. Overall employee morale was severely low due to the increased workload and mandatory overtime. Corrective actions were immediately taken including the dismissal of one employee. Overall, for the month, we were making significant progress in order processing. In October, we were able to transition the additional order volume back to the primary warehouse. The site is now at or above the goals of orders shipped complete. However, there are still some problems associated with the staffing levels. In any warehouse operation it is important to consider the impact the project will have on the overall facility. A significant benefit of a WMS is the discipline it instills within the warehouse. The process dictates a specific work flow and accountability through real-time data capture and directed task management. Without a doubt, the facility’s culture and employee morale will be affected by the system. It should be understood by all that a WMS system will not correct a warehouse that is experiencing operational problems. When designing the system, build it with the idea of how to improve processes. Another important point to note is that employee training and buy in is critical. Employees at every level directly affected by the new system need to be involved in the development of the processes. You should also be realistic that there is going to be a learning curve. Expect and plan for several weeks or months of below par performance. The implementation team should extensively test the system. Try to crash it! And be aware of how the system reacts when changes are implemented. Overall, I was impressed by our implementation. There were a few stumbling blocks encountered but by putting our heads together, we were able to overcome them. Arnold, J.R. Tony, Materials Management, 2nd Edition Upper Saddle River, NJ., Authors not listed, Do You Need a WMS? 1996 http://www.isit.com/st/documents/document2471.htm Hudock, Brian, Implementing Warehouse Management? 10 Mistakes to Avoid Tompkins Associates, July 1997 Accessed on 25 Nov, 2001 http://www-us-tech.com/july97/biz/mgmnt06.htm Singer, Tom, Tompkins Associates - Competitive Edge Volume 6, Issue3, Page 13-14 Tompkins, James A & Harmelink, Dale. The Distribution Management Handbook Lexington, McGraw-Hill, 1994 Bibliography:

Word Count: 5531