Teaching Method
Case Study Roles
There are two case study roles, which are the Head of Information Technology Department and the Chief Operations Manager. Each character will be played by a teaching staff member, who will assume that specific role for all students, irrespective of group, for the whole case study module.
When students elicit requirements for the proposed system (i.e. input designs, output designs, file/database designs, security and controls, etc.), only the staff member playing the role can give approval for matters relating specifically to that role.
The Head of Information Technology Department is a very busy man and difficult to reach. Information about the current operations and the requirements for the proposed system should be obtained from the Chief Operations Manager.
Supervisory Roles
Students are divided into groups. Each group of students has a supervisor who monitors the ongoing project work of that case study group.
The role of the supervisors in classes is two-fold. Firstly, the supervisors monitor the progress of students against the student groups’ plans by means of weekly progress meetings. Secondly, they are to help students by offering advice and suggestions. There is no model answer to the project; students will not be told what to do but to find out themselves what and how to do. They will, however, be guided so that they remain within the given terms of reference to enable them to follow reasonable or practical methods of solution.
Supervisors will, in addition to their supervisory role, also give technical advice. During class contact hours, supervisors will, to some extent, “wear two hats”. Supervisors will be expected to give opinions or suggestions to students. It is up to the students to decide which opinions, if any are most useful to them. When offering suggestions, supervisors must bear in mind that only the staff member playing the respective case study role can give approval to the proposed solution, which is specifically the responsibility of that role.
Assessment
There is a business-oriented project in the System Development Project module. The assessment of the project is continuous, with weighting of 7:3 in favor of the individual contribution (i.e. 70% for individual mark and 30% for group mark).
Each student will be assessed in the following four components, plus presentation of their work in progress and supervisor-student meetings.
The four components for individual assessment in the business-oriented project are:
• a feasibility study report and a system development proposal (after investigation and requirements elicitation) – Requirement Specification;
• an analysis report, an architectural and database design and an implementation plan (after initial design) – Design Specification; a software product with user documentation and a technical documentation (after development).
Normally, there are 4 students in a project group. Each student member of a group acts as the coordinator for one of the four components and its associated submission of work. However, each group member will be individually assessed in every component.
The group mark for a project is derived from the final product which is comprised of a software product, a full set of technical documentation and an oral presentation. The assessment factors and mark allocations are detailed in Teaching Plan. The breakdown of the individual and group marks will be distributed to students in due course.
Project Work Structure
The business-oriented project work is a group exercise which lasts for around 20 weeks across semester 2 and 3. However, for assessment purposes and formal progress monitoring, of both group and individual, it is divided into four major stages that are:
Stage One: Feasibility study and project proposal;
Stage Two: System analysis and System design;
Stage Three: First Prototype
Stage Four: Second Prototype and Technical Documentation.
The deliverable(s) of each stage are as below:
Stage
Deliverable(s)
One
A feasibility study report and a system development proposal
Two
Design Specification
Three
A software prototype
Four
A software product and a technical documentation
Case Study Scenario
Profile of the ABC Restaurant Group Limited
The ABC restaurant Group Limited is a public limited liability company. It has grown into one of the largest catering company in Hong Kong. The Group is operating diversified services including Chinese Restaurants, Western Restaurants, Japanese Restaurants, Conveyor-belt Sushi Restaurants, Fast Food Restaurants and etc. It has over 10 brands and around 100 restaurants in 2018.
The Group is founded in 1980. In the early years, it operates Cantonese Restaurants and has been very successful. It had already opened 12 Restaurants in late 80’s. After a few years, the Group started to build other brands with different services. In the first ten years since the Group is founded, it deployed simple POS in some of the large Restaurants. In early 90’s, the Group has formed an Information Technology Department to support different Departments in computerizing daily workflow, data processing, report generation…etc with Third-Party software. Since 1998, I.T. Department starts to develop proprietary system to suit other departments’ special needs. Since then, many programs and systems have been developed for different departments or even a specific role.
In early 2018, the Head of Information Technology Department observed that lacking communication between sub-systems leads to large overheads and suffering from data inconsistency. He suggests to deploying the concept of Enterprise Resource Planning (ERP) which integrates systems across the whole company including tangible assets, financial resources, materials, and human resources. All data will be centralized to reduce overhead and risk of data inconsistency. Since the scale of the system is very large, he suggests to dividing the whole development into different phrases and Supply Chain Management will be the first phrase.
Supply Chain Management includes many components, such as Planning and Control, Work and Organization Structure, Product Flow Facility Structure…etc. After a detail discussion in the management team, the first component that will put on pilot run is Procurement.
Overview of Procurement Procedure
After System Integration, the procurement procedure will be centralized, therefore all Restaurants, including Chinese Restaurants, Western Restaurants, Japanese Restaurants, Conveyor-belt Sushi Restaurants, Fast Food Restaurants and etc, will send their request to the centralized system by the Restaurant Manager. Requests sent to the system will be queued up and a Request Mapping procedure will be process three times a day either manually by Purchase Manager (or known as Buyer in some ERP Systems) or automatically by System (according to rules set by Purchase Manager).
Request may be mapped to a Despatch Instruction (only if warehouse has stock) or an appropriate and valid Blanket Purchase Agreement (BPA) depends on Purchase Manager’s choice. If the request is mapped to a BPA, a Blanket Purchase Release will be generated based on the BPA and send to Supplier. If there is no appropriate and valid BPA, Purchase Manager will check if the coming Planned Purchase Order suits Restaurant’s request or create a Standard Purchase Order. If stock is available in warehouse, he/she may asks warehouse to deliver items to Restaurant instead of generate a Purchases Order.
A purchase is not necessarily be initiated by a request from restaurant. Purchase Manager can have a Planned Purchase Agreement with Supplier. In this case, items from Supplier are usually delivered to warehouse, but for some special case or urgent needs, the shipping address can still be changed to Restaurant in the Schedule Release.
All Purchase Order (Blanket Purchase, Planned Purchase and Standard Purchase) will be sent to Supplier for purchase and Accounting Department for further process.
After the mapping is made, the Restaurants Manager in Restaurant can check the status of the request and obtained references, such as Delivery Note Number (from warehouse) or Purchase Order numbers (which supposed to be printed in Supplier’s Delivery Note). For Planned Purchase Order, Warehouse Clerk in warehouse can also check the status of the Purchase Order issued to supplier. When items are received, he/she can match the delivery note with the request easily, he/she can then sign on the delivery note, keep a copy of it and mark the received quantity in the System.
Signed Delivery Note (from Supplier) will be sent to Accounting Department daily. Accounting Clerk will check the Delivery Note and Invoice received from Supplier, if they are matched, Accounting Manager will complete the payment and update the status of the Purchase order.
Purchase Agreement
In our system, there are two kinds of Purchase Agreements, Blanket Purchase Agreement and Contract Purchase Agreement. A Blanket Purchase Agreement is an agreement made by a Seller (Supplier) to a Purchaser (Purchase Manager or Buyer), reporting that on a specific date, terms, for a particular sum of money or other value received, and a specific item of personal, or parcel of real, property that Supplier sold to the Purchase Manager which he had lawful possession. A Contract Purchase Agreement is an agreement with Suppliers to agree on specific terms and condition without indicating the detail of goods that you will be purchasing, such as quantity, price…etc. Purchase Manager can later issue Standard Purchase Orders referencing your contracts.
Detail of these Purchase Agreements will be explained below.
Blanket Purchase Agreement
Blanket Purchase Agreement (BPA) is made when Purchase Manager know the detail of the goods that you plan to buy from a specific supplier in a period, but do not know the detail of delivery schedules yet. BPA is used to specify negotiated prices for items before actually purchase them. Sometimes it specifies also Price Breaks information.
The items in BPA usually have discount compare to the one in Standard Order and Purchase Agreement is a legal document that should be fulfilled. Therefore, most Purchase Manager may map request to BPA before Standard Purchase or use stock in warehouse.
The Header of a BPA includes the Purchase Order Revision, Created Date, Effective Dates, Supplier Information (such as name, address, contact person…etc), Buyer’s Information (such as name, billing address…etc), Amount Agreed, Currency, Terms and Condition…etc.
The Lines of a BPA includes the details of goods such as Supplier’s Item ID, Item Description (Buyer’s Item ID maybe included here), Promised Quantity (for Contract, Quotation may leave this blank), Unit of Measurement (UOM), Minimum Order Quantity (MoQ), Price, Amount, Category, Reference…etc.
The Price Breaks includes the quantity, price break, discount, effective date.
A Blanket Release against a BPA can be issued to place the actual order as long as the release is within the blanket agreement affectivity dates. Blanket Release can be created manually or automatically by system according to rules preset by Purchase Manager.
A Blanket Release contains all the information stated in the BPA, in addition, it provides also Release Number, Blanket Release Created Date, Shipment Information (note: Supplier delivers items to Restaurants directly), Expected Delivery Date, Account, Actual Amount, Actual Quantity of Items.
In some cases, if the BPA cannot be completed (fulfilled) in the specified period, Purchase Manager may negotiate with supplier to extend the period or reduce the amount or quantity.
Contract Purchase Agreement
A Contract Purchase Agreement is an agreement with Suppliers to agree on specific terms and conditions without indicating the detail of goods that to be purchase. Purchase Manager can later issue Standard Purchases Order referencing the contracts. Therefore, a Contract Purchase Agreement only includes Contract Number, Created Date, Effective Dates, Supplier Information (such as name, address, contact person…etc), Buyer’s Information (such as name, billing address…etc), Terms and Condition, Item information (without purchase detail such as quantity, price…etc). Note that Contract Purchase Agreements are directly referenced on Standard Purchase Order Lines.
Planned Purchase Order
Items in Planned Purchase Order are usually consumables such as chopsticks in Japanese Restaurants, Table Paper in Fast Food Restaurants…etc. Besides, items are usually General Items and some F&B (Food and Beverage) items, which can be kept in a longer period. To save storage space in Restaurants, items are usually delivered to warehouse.
A Planned Purchase Order is a long-term agreement committing to buy items from Supplier. Purchase Manager must specify tentative delivery schedules and all details for goods that want to buy including charge account, quantities and cost. Shipments Information is optional in Planned Purchase Order. In our systems, we set the shipment address to warehouse by default in Planned Purchase Order, but for some special case or urgent needs, the shipping address can still be changed to Restaurant in the Schedule Release.
The Header of a Planned Purchase Order includes the Purchase Order Revision, Created Date, Effective Dates, Supplier Information (such as name, address, contact person…etc), Buyer’s Information (such as name, billing address, account…etc), Tentative Schedules (such as weekly, monthly), Amount, Currency, Terms and Condition…etc.
The Lines of a Planned Purchase Order includes the details of goods such as Supplier’s Item ID, Item Description (Buyer’s Item ID maybe included here), Quantity, Unit of Measurement (UOM), Price, Amount, Category, Reference…etc.
Shipment Information such as Delivery Address is set the warehouse by default, but can be modified in Schedule Release.
A Schedule Release against a Planned Purchase Order can be issued to place the actual order according to the tentative schedule. The actually delivery schedule can be a few days different from the tentative schedules, but usually not more than three days. A Schedule Release contains all the information stated in the Planned Purchase Order, in addition, it provides also Release Number, Schedule Release Created Date, Expected Delivery Date.
Standard Purchase Order
Purchase Manager generally creates a Standard Purchase Order for one-time purchase of various items, such as decorations in Restaurants. If the items are delivered to Restaurant, Restaurant Manager can also check the items that he/she is going receive. It contains details of the goods that the Purchase Manager required, quantities, amount, account, delivery schedules and shipment information.
The Header of a Standard Purchase Order includes the Purchase Order Number, Created
Date, Effective Dates, Supplier Information (such as name, address, contact person…etc),
Buyer’s Information (such as name, billing address, account…etc), Shipment Information (note: Supplier delivers items to Restaurants directly), Expected Delivery Date, Terms and Condition.
The Lines of a Standard Purchase Order includes the details of goods such as Supplier’s Item ID, Item Description (Buyer’s Item ID maybe included here), Quantity, Unit of Measurement (UOM), Price, Amount, Category, Quotation No., Contract No. (if it is generated from Contract Purchase Agreement), Reference…etc.
General Requisitions
General Items are items that are not F&B (Food and Beverage), such as Chopsticks, Table Paper, Plates, Bowl…etc. Item ID is unique for different items, for example the Item ID of 12” Plain Plate and 12” Plate with Logo is different. Category Manager manages the category hierarchy by create and modifying categories. The category hierarchy organizes products offered by different Restaurants, for example Plain Plate may share across different Restaurant, but Plate with Logo can only be used in a Restaurant with that brand. The Category Manager also manages products, expected inventory records, supplier information, inventory, return reasons…etc.
In a Restaurant, only the Restaurant Manager can login to the system to send request to the system (in future, after other components developed, other staff can also login to the system to do different tasks, but for procurement that we now considering, only Restaurant Manager can login to the system).
• Since there are many items associated with Restaurant, the system must provide a user friendly interface to work with. The Chief Operation Manager suggests the following:
• A search function must be provided to search an item by different attributes, such as Category, Item Name, Item ID…etc.
• The system can show Recent Requested Items when entering a request. The period can be customized by the Category Manager for different Restaurants.
• Restaurant Manager may input the Item ID manually and the system should check if the Item is valid to the Restaurant to prevent incorrect request.
A request should at least included Restaurant Information, Staff Information, Request Creation Date and Item Information such as Item ID, Quantity, Expected Delivery Date and remark.
When a request is sent, it will be put in a queue for Request Mapping (See Section 5.8). The Restaurant Manager can view recent request and request history anytime. He/she is also allowed to edit the request before the mapping process take place or the request cannot be handled (failed request). The status of the request will be shown to Restaurant Manager clearly, such as waiting for process, delivering, completed…etc. Besides, after Request Mapping is done, P.O. Numbers or Delivery Note Numbers will be assigned to the request line with other shipment information. P.O. Numbers are assigned when the request is handled by Purchase Orders, such as Blanket Purchase Order, Standard Purchase Order and sometime Planned Purchase Order. Delivery Note Numbers are assigned when the request can be handled by warehouse. Therefore, when items are received from Supplier or Warehouse, the Restaurant Manager can check the request with the corresponding delivery note easily (Delivery Note from Supplier is expected to have P.O. Numbers printed on it). Depends on Supplier’s system, one Delivery may serve more than one request and one request may also divided into a few delivery. After verification, he/she will mark down the number of items received in the system and corresponding stock count will be updated. He/she can also check and update the stock count anytime.
Chief Operation Manager suggests that all transactions are better to be logged in order to trace the workflow easier. Besides, he also suggests having notification service to remind Restaurant Manager for some events, such as expected delivery date has passed but no item received yet.
Food and Beverage Requisitions
Food and Beverage (F&B) Requisitions is similar to General Requisitions, however the Item ID entered by Restaurant Manager is virtual. The virtual Item ID will mapped to a real ID in the system according to Category Manager’s setting, then the real ID will be used for Request Mapping. Note that, on the P.O. or delivery note send to restaurant, it still shows the virtual Item ID, so the Restaurant Manager can check the inwards item easier.
The purpose of using virtual Item ID are two-folds. Since the F&B items and its supplier may change more often from time to time, by use of virtual Item ID, it is not necessary to inform all Restaurants to make the change frequently. For example, if the Category Manager wants to change the brand and supplier of potato for all Fast Food Restaurants, he does not required to inform all the Restaurant to change to Item number for potato, but just modify the virtual Item ID mapping. This also makes the work of Restaurant Manager easier. Secondly, Restaurant Manager may shift to different Restaurant brand within the group, but the code of the same item remains unchanged, for example, rice used in Western Restaurants is different from Sushi Restaurant or Japanese Restaurant, but the Item number are the same across these Restaurants, so he/she can pick up the duty easier.
Purchase Orders Generation (Request Mapping)
When a request is sent from Restaurant, it will be put in a process queue for Request Mapping, this process executed by Purchase Clerk three times a day (09:00, 13:30 & 17:00) and can be done automatically or manually depends on system setting. The purpose is to generate Purchase Order to supplier (items are delivered to Restaurant directly) or schedule a delivery to deliver requested item from warehouse.
In general, the aim of Request Mapping is to fulfill BPA first. When a request is matched with the BPA, a Blanket Release will be generated. When there are more than one BPA related to the same Item, Purchase Manager will choose the one, which is incomplete and is going to expire soon. If the expiry date of BPA are the same or near (for example, in one month), Purchase Manager will choose the one has lower price. In some cases, a request may associate with more than one Blanket Release. For example, a BPA has a line of Item A, which can be completed with 20 more order and another BPA has a line of the same Item, which can be completed with 80 more order. The Purchase Manager may serve a request with 100 Item A by the two BPAs above in order to complete the BPAs faster.
If there is no BPA matched, Purchase Manager will check with the warehouse. If warehouse has stock, a Dispatch Instruction will be issued to warehouse for them to generate a Delivery Note and deliver requested item to Restaurant. In general, priority of BPA is higher than deliver items from warehouse, however for some F&B items which has expiry date, Purchase Manager / Category Manager may override the mapping and serve request by warehouse first.
If a request cannot be served by both BPA and warehouse, it is considered as a failed request. Purchase Manager has to handle this manually; there are several possible solutions:
• To check if a Planned Purchase Order can serve the request later and may ask Restaurant Manager if it is possible to postpone the expected delivery date. If so, the request can be served by warehouse after the item delivered to warehouse from supplier.
• To issue a Standard Purchase Order from Contract Purchase Agreement. For this case, the price is usually higher than the one in BPA. Purchase Manager will review the orders to see if it is possible to create a new BPA in future.
• In some urgent cases of F&B request, it maybe served by manually create a Blanket Release to supplier to deliver different brand of similar items by ignoring the virtual Item ID mapping temporary.
• Wait for the next batch if the Restaurant Manager is agreed.
Since there are some manual processes that required longer time for decision making for failed request, it may not be able to complete in current batch.
When the Blanket Releases, Purchase Orders and Despatch Instructions are prepared, they will be issued to supplier or warehouse. Then Restaurants Manager in Restaurant can check the status of the request and obtained references, such as Delivery Note Number (from warehouse) or Purchase Order numbers (which supposed to be printed in Supplier’s Delivery Note). Warehouse clerk in the warehouse can see the Despatch Instruction and start to prepare items to be delivered to Restaurants.
Warehouse
Warehouse Clerk can see the Planned Purchases Order after it is sent to the supplier. He/she can see the item information in the order, but no pricing information will be shown. Depends on Supplier’s system, one Delivery may handle more than one Purchase Order and one Purchase Order may also divided into a few delivery. When items are received, he/she can match the delivery note with the Purchase Order, sign on the delivery note, keep a copy of it and mark the received quantity in the system. Signed Delivery Note (from Supplier) will be sent to Accounting Department daily. Accounting Clerk will check the Delivery Note and Invoice received from Supplier, if they are matched, Accounting Manager will complete the payment and update the status of the Purchase order.
When Despatch Instruction is sent to warehouse, Warehouse Clerk will prepare the items, update stock count and generate a Delivery Note when items are ready (Restaurant Manager can check the Delivery Note number if the delivery serves his/her request). He/she can also check and update stock count anytime. Chief Operation Manager
suggests that all transactions are better to be logged in order to trace the workflow easier. Besides, he also suggests having notification service to remind Purchase Manager and Category Manager for some events, such as stock level too low.
End.