WMS_Project

advertisement
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.
Download