Warehouse Management System (WMS) Project Introduction The WMS project emulates a microcosmic supply chain with three entities: Purchaser, Supplier and Warehouse, that comprise a Super Team. The class is asked to assume that the existing mode of working uses an archaic system that is ridden with issues arising from manual errors, outdated technology, and lack of organization. The charge is to develop an information system that would support the three areas of supply chain functionality. Each Super team would therefore be comprised of three sub-teams, each of which assigned one of these supply chain functions. The purpose of the project is to modernize, increase efficiency, and reduce errors that take place as orders and their related information flow through a microcosmic Supply Chain. Currently the company’s warehouse management system is using a fax based system to send and receive orders for parts that are required in their automobiles. While this paper trail works, it is cumbersome and often leads to manual errors, lack of standardization, loss in processing speed, error control, and detection of delays of parts. Moreover, there is so much paper involved that it is becoming harder to store and track. The project challenges the student in not just application development, but all the phases of the System Development Life Cycle (SDLC). For instance, to simulate a consulting experience, the objectives are described in very much the same manner as they would be from clients – with very little specific design guidelines. They must therefore ask appropriate question of the client to design the requirements in accordance to the desired functionality. The instructor and teaching assistants play the role of the clients. Given design guidelines include: Each supply chain is represented by a single super team that is comprised of three sub-teams of four to five students each: Purchaser, Supplier, and a Warehouse. Super teams are mostly evaluated as a single team during the final presentation, and must support each in order to successfully pull off the project. The sub-teams are made up of four to five students. o Purchasers (aka Order Placement or OP) generate new orders and reconcile received ones. o Suppliers (aka Order Fulfillment or OF) fulfill the orders received from OP and send to the purchaser’s warehouse. o Warehouse (aka Order Receiving or OR) receive orders and send notification to OP. Each of the three teams must use an independent database, with the products table being the only common element between the databases. This products table will be supplied to the class. OP takes the stage twice: once to demonstrate order creation, and once to show receipt of order status OR is responsible for integrating the RFID scanner with the instructor’s computer for the final presentation. Business Process The WMS project must represent information about the order as it travels and is modified between the supply chain entities. This full circle is represented in Figure 1 below. Independent Warehouse Management System – Fulfillment Application Order Receiving Order Placement Create Order & Reorder Missing Send Missing Orders Send Order Order Fulfillment RFID Order Verification Ship product & ASN Order Receipt & ASN Generation Figure 1. WMS diagram Details of functionality required by each sub-team representing a supply chain entity are explained in the next pages. They are broken down by core functions (Agile Modules). Each core function must be well understood, designed, developed and presented to the class, before the next Agile Module is completed. This form of breaking down and developing functions is called Agile Computing and is contemporary practice in the Information Systems Industry today. You are expected to research and design a robust login functionality for security. Good sources are in the ISMS Wiki, on Google and on MSDN. Each team must develop web interfaces to accommodate the Agile Modules listed below. They will be graded first on functionality, and then on user interface design. All functionality must be presented in a context of serving the business functions in the supply chain industry. The final presentation begins with an introduction made by an elected speaker for the super team, who is the Master of Ceremonies for the 30 minute presentation made by this team. Each sub-team is introduced by this speaker and gets ten minutes to present their charge, functionality, and handles the questions and answers. The speaker is charged with “selling” the project to a panel of judges made up of faculty and industry specialists who may not be at all familiar with the project whatsoever. This poses two challenges: to be able to explain the project from the basics, and to keep the judge from getting lost or confused during the presentation. Lastly, and most importantly, please review the rubric that will be used for judging. Order Placement (OP) As mentioned before, OP is the purchasing department of an automobile manufacturer. They have an assembly plant that is used to build vehicles from parts that are acquired from their supplier. In general, OP is charged with order generation, and verification of previous orders. More specifically, the following discrete functions must be addressed. CF1. CF2. CF3. Ability to select multiple products in multiple quantities as a single order. Also, ability to list previously ordered items that did not get fulfilled (e.g. missing/damaged), and re-order them along with other new items being ordered for the first time. During any demonstration, OP must send more than one lineitem to OF so that OF can proceed in accordance with their directives. Review order totals, and edit (change quantities, or complete delete) lineitems of an order. The submit button must input the order into OPs database, but not send it onward to OF. The submit button developed in Agile Module 2 must also send order data to OF. A Search interface must be developed to review data about previous orders (e.g. completed, missing, orders that are built but not yet sent on to OF, etc.), using at least three variables (e.g. order #, date, order total, etc.). Use of conjunctions (AND, OR as a part of SQL) are not necessary, but nice to have. During the final demonstration, OP begins, followed by OF and OR. OP takes the stage once again to show that the (order status) data sent to them from OR has been received in their database. Note: OP must send three orders in their final demonstration. Order Fulfillment (OF) OF is assumed to be the exclusive supplier of parts to the above automobile parts purchaser (OP). The order information sent by OP is received in OF’s database. Suppliers can expect to receive orders from only one automobile purchaser, i.e. only one OP team. Where OF gets their parts to fulfill OP’s orders is not a part of this project’s consideration. Pallets are identified using RFIDs. RFID tags will be supplied towards the end of the quarter. In general, OF packages lineitems into pallets which are then packed into a shipment. A notice of this shipment, known as an Advance Shipping Notice (ASN) and its details, is sent to the third supply chain entity. There are a few rules described in the Agile Module lists below. CF1. Ability to view received orders and pack multiple (e.g. three) lineitems from multiple (e.g. two) orders into a single pallet. OF does not necessarily fulfill every lineitem of an order into a corresponding pallet. Rather OF follows a business rule such as FIFO (First In First out), most expensive first, or even like items together. For instance, OF may package tires from three different orders into a single pallet. Pallets that have shipped must not show up as available in this Agile Module. The quantities in which products have been ordered need not be changed or broken up. For instance, if 12 tires were ordered, then it is fine to pack and ship all 12. It is not necessary to break that lineitem into multiple shipments (e.g. eight tires and four tires). Shipping all 12 tires together is fine. CF2. Ability to review costs and details of products and their quantities. Ability to display multiple (e.g. three) pallets and display that they have been packed with lineitems from different orders. It should be possible to remove a lineitem from a pallet, or remove the pallet altogether. Also it should be possible to ship only selected pallets. The submit button must insert the pallets that are being shipped into OFs database. A shipment must have three or more pallets at all times. A shipment must be identified using the ASN number for simplicity. CF3. The submit button in Agile Module 2 must now also send data to OR, in addition to inserting data into their own database. Also, a search interface must be developed to review data about previous shipments that have been sent on to OR. OF must follow the Pack Three rule: i.e. pack at least three lineitems into a pallet and at least three pallets to a shipment. Order Receiving (OR) OR is the receiving warehouse for the automobile manufacturer. In general, this team simulates a delivery using a real RFID scanner, reconciles the information which was sent earlier into their database, and updates OP on the status of the order they had generated. OR must also integrate an RFID scanner to a computer and scan RFID tags to simulate deliveries. CF1. CF2. CF3. Ability to enter one of the pallet numbers (RFID) as having arrived at their shipping dock. This RFID must be matched with the data in the database. At this time, the truck and all other pallets are identified and all its details including current status (e.g. scanned or not scanned) must be displayed. The page must allow subsequent RFIDs to be scanned as well. This team must demonstrate at least one pallet (RFID) as missing/damaged (i.e. not scanned). Ability to review shipment, its contents, and confirm status of lineitems (or pallets). One pallet must be marked as missing, lost, or damaged. Status of all products must be appropriately saved to ORs database on submit. The submit button in Agile Module 2 must now also send all status updates to OP in addition to inserting the data in their own database. This update sent to OP must not include RFID or ASN information, since OP only deals with orders, products, and their quantities. This Agile Module also requires the ability to browse previously received shipments and the statuses using Search functionality.