TUTORIAL 2 – TOPIC SELECTION AND PROPOSAL APPROVAL
ACTIVITY 1 – Topic Feasibility Scorecard
Candidate topics:
- Topic A: Inventory & Demand Decision Support System (Topic 2)
- Topic B: Customer Relationship Management System (CRM) (Topic 1)
- Topic C: Sales Analytics Dashboard (Sales BI) (Topic 3)
Topic Comparison Matrix
Topic Topic Topic
Criterion Evidence/notes
A B C
All three are common MIS problem types. Inventory DSS is
directly tied to daily operational decisions (reorder, stock),
Business
5 4 4 making the "decision" element stronger than CRM
relevance
(relationship management) and Sales BI (descriptive
reporting).
Inventory DSS has concrete, directly measurable
operational KPIs (stock-out rate, turnover, forecast error).
CRM impact takes longer to observe (retention,
Measurable
5 3 3 conversion).
impact
Sales BI is measurable but the dashboard itself is
descriptive – impact depends on whether users act on the
insight.
Operational roles (store staff/manager) are typically easier
User access 4 3 3 to observe directly than customer-relationship behavior or
reporting habits.
Inventory/sales data is usually available via POS. CRM data
Data
4 3 4 (interaction history, leads, follow-ups) is often scattered
availability
across channels and harder to collect fully.
Per the guide's Indicative difficulty: Inventory DSS = High
MVP
3 4 4 (requires reorder rules/forecasting), CRM/Sales BI =
feasibility
Medium.
TOTAL
21 17 18
21/25
So we decided to select Topic A: Inventory & Demand Decision Support System.
Why were other options not chosen?
Because with Topic B - CRM: convenience stores have instant, anonymous transactions with
no long-term follow-up cycle typical of CRM use cases (education, hospitality, B2B).
Customer loyalty data is usually scattered and hard to collect fully within one term.
And with Topic C - Sales BI: fundamentally a descriptive tool (looking backward – "what
was sold"), whereas the direction the team wants to pursue is a decision-support tool (looking
forward – "what needs to be replenished next"), requiring business rules that a pure reporting
dashboard doesn't provide.
ACTIVITY 2 – Empathize, Define, and Find the Root Cause
User and Root-Cause Evidence Table
Underlying
User/role Observed task Pain point Evidence
need/cause
[Rework/Duplicate POS report, Need a single,
entry] System records inventory count reliable
Check inventory
Store don't match actual report, and GS25 inventory data
via POS + manual
Staff shelf stock, requiring staff reviews on source instead of
shelf counting
manual employment cross-checking
verification/re-entry forums two places
[Missing
Identify low-stock data/Control gaps] Staff manual notes, Need an
Store products No dashboard interviews with automated
Staff (beverages, instant automatically GS25 Hanoi shift threshold-based
noodles, snacks) prioritizes low-stock leaders alert mechanism
alerts
[Delays] If the
Receive goods, quantity ordered is Purchase orders,
Need accurate
Store verify quantities, wrong, popular goods receipt notes,
purchase orders
Staff update inventory products are delayed and supply chain
from the start
records until the next delivery logs
cycle
Sales history
Review sales and [Decision bottleneck] Need a real-time
(invoices),
Store current inventory Decisions rely mainly combined sales
inventory reports,
Manager before deciding on + inventory
CVS industry case
what to replenish intuition/experience overview
studies in Vietnam
[Control gaps] No
rule suggests an
optimal reorder Sales history, Need a reorder-
Estimate quantity based on inventory reports, quantity
Store replenishment trends, and no order history, and business rule
Manager quantity, prepare distinction is made records of that
purchase requests between product overstock/emergen differentiates by
categories with cy restock incidents product category
different
characteristics
Monitor inventory [Control gaps] Inventory count
Need a proactive
Store status after Shortages are usually reports, Google
early-detection
Manager replenishment, detected only after Maps reviews,
mechanism
handle shortages customer complaints customer feedback
5 Whys Analysis
Problem: No rule suggests an optimal reorder quantity based on trends, and no distinction is
made between product categories with different characteristics.
1. Why 1 - Why is there no rule suggesting optimal reorder quantities that differentiate
between product categories?
=> Because store managers currently estimate all replenishment quantities manually,
relying solely on general intuition and personal experience.
2. Why 2 - Why do they rely on intuition and general experience to estimate quantities?
=> Because the current system only provides raw operational records without
analyzing trends or category-specific needs.
3. Why 3 - Why isn't there an analysis of trends and category-specific needs?
=> Because recent inventory and sales information isn't integrated into a system
capable of calculating distinct reorder points.
4. Why 4 - Why isn't the information integrated to calculate distinct reorder points?
=> Because no one at the store level owns the task of translating product differences
(shelf life, lead time) into concrete reorder parameters – inventory data exists, but
converting it into category-specific rules has never been assigned as a process
responsibility.
5. (Root cause) Why 5 - Why does the store lack these predefined, category-specific
business rules?
=> Because inventory decisions have historically been managed reactively at the store
level, using whatever tool was available (POS system, spreadsheets, manual notes)
rather than being designed around the business's actual product diversity – there was
no dedicated system or process step whose explicit purpose was to define and maintain
these category-based rules.
Fishbone Analysis (6 categories)
Main pain point: No rule suggests an optimal reorder quantity based on trends, and no
distinction is made between product categories with different characteristics.
Category Identified causes
Staff/managers rely on personal experience; they are not trained to read
People
sales-trend data.
The inventory-checking process is applied uniformly across all product
Process
types, with no differentiated handling by product characteristics.
Inventory/sales data exists but is fragmented (separate POS, separate
Data
handwritten notes) and not tagged by category.
No consolidated dashboard; no automated reorder-point calculation; no
Technology
capability to apply different rules per product group.
No formally issued low-stock threshold/reorder point; even less a distinct
Policy
policy for short-shelf-life vs. imported goods.
24/7 store operation, shift-based staffing, limited time per shift for deeper
Environment
manual analysis.
Cause Classification – In/Out of Project Scope
Cause In scope? Note
Lack of a consolidated
In scope Core feature required per Scope Warning
inventory + sales dashboard
Lack of reorder rules
In scope Main root cause, central to the system
differentiated by category
Fragmented data, not tagged Addressed via Product.category_type schema
In scope
by category design
Lack of early low-stock Falls under "Reorder rules, suggested order
In scope
alerts quantities and alerts"
Out of
Staff not trained to read data Internal training issue
scope
24/7 operational pressure, Out of
Resourcing/organizational issue
staffing shortage scope
The system provides the tool to configure
The company hasn't formally
Partial thresholds, but formal policy issuance is a
issued inventory thresholds
management decision, outside the technical scope
ACTIVITY 3 – Proposal Approval Gate
One-Page Proposal Review
Proposal Reviewer decision/
Team response
element comment
Project Inventory & Demand Decision Support System for GS25
title (Hanoi Branch)
Problem Problem: Daily replenishment decisions at GS25 (Hanoi
and branch) rely on historical sales data in the POS system, but
evidence lack automated business rules – an internal staff survey
found 0% of respondents had trend-based reorder
suggestions or category-specific ordering rules in their
current system. This is worsened by fragmented data across
POS, delivery slips, and manual/Excel tracking, and by a
product catalog spanning categories with different handling
needs (FMCG, short-shelf-life prepared food like Gimbap,
and imported goods) with no distinct replenishment logic
per category. A small survey indicated an estimated stock-
out rate of under 5 – 10% and overstock/write-off rate of
under 10 – 30% for fast-moving items, plus 30 – 60
minutes spent daily on manual inventory checks.
Evidence: 6-step current-process map, 5 Whys, manual
inventory-check Excel screenshots, real delivery notes, staff
interview and survey
Users: 2 roles
- Store Staff: checks inventory, identifies low-stock
items, receives and verifies deliveries.
Users and - Manager: reviews sales/inventory, estimates and
workflow approves replenishment quantities, monitors post-
replenishment status.
AS-IS workflow: the 6-step process mapped in Tutorials 1
and 2.
1. Reduce the stock-out rate for fast-moving products from
the current estimated range (5 – 10%) to a measurably
lower level.
Objectives
2. Reduce time spent on manual inventory checks compared
and
to the current 30 – 60 minutes/day baseline.
success
criteria 3. Provide category-differentiated reorder suggestions
covering 100% of tracked SKUs (a process-completeness
target, not a forecast-accuracy target, since forecast
accuracy requires a working AI model not yet built).
In scope: master data (product/supplier, with
category_type), stock in/out, low-stock dashboard and
alerts, category-based reorder rules, purchase order creation
MVP & approval, 2-role RBAC (Store staff, manager), at least
scope and one integrated API (rule-based low-stock alert required;
exclusions AI/Python demand-forecast API as a stretch goal if time
permits).
Out of scope: payroll, customer loyalty CRM, multi-branch
support.
Data/user The team has secured access to authentic operational data
access from a GS25 branch in Hanoi, including POS reports,
inventory count logs, purchase orders, and delivery notes,
all of which are managed within a shared Google Drive
repository. Primary requirements were elicited through
structured digital interviews and quantitative surveys via
Google Forms conducted with GS25 store staff to validate
critical pain points, specifically fragmented data and
inventory discrepancies. For the prototype demonstration,
transaction data is simulated based on observed operational
patterns rather than official financial figures to ensure
academic integrity and data privacy. This multi-method
approach (surveys, interviews, and document reviews) was
employed to minimize information bias and ground the
system requirements in real-world complexity.
- Tight 5-week timeline => Trim non-core sections
per the condensed outline.
- Third-party API failure/timeout during demo =>
Risks and rule-based reorder fallback.
mitigation - Insufficient quantitative evidence => continue
collecting data in parallel during week 2.
- Limited access to real POS data => use well-
grounded simulated data with sources clearly noted.
Weekly plan:
- Week 1: Discovery + Proposal + Requirements
- Week 2: DB + System Design
- Week 3, 4: Implementation + Testing
Weekly - Weeks 4, 5: Evaluation + Report + Presentation.
plan and Team roles (Main):
team roles
- Le Ha Bao Tran: Coordination, Requirements /
Users, support in Design / Data
- Do Thi Phuong: Design / Data, support in
Requirements / Users
- Both: Implementation, Testing / Documentation
Detailed Risk List
Risk Level Mitigation Related milestone
Clear deliverable at
Trim non-core sections per the
5-week timeline too tight High the end of each
condensed outline
week
AI forecast API was Rule-based reorder fallback Week 3 – API
Medium
unstable during the demo operates independently integration testing
Missing real quantitative Parallel data collection; use
Medium Week 1 – 2
data simulated data if needed
2-role RBAC may need Already confirmed via real
Confirmed in
adjustment if additional real Low current-process map (6 steps,
Tutorial 1
roles emerge only 2 actors)
Quality Gate
Check Criterion
[✓] Topic supported by real user/data access, not preference alone
[✓] Problem statement specific, measurable, and free of solution wording
[✓] MVP realistic for the capstone timeline (adjusted to 5 weeks)
[✓] Scope exclusions and risks are explicit
[ Not yet ] Approval feedback has an owner and a due date.
Reflection and Next Action
23. Which feasibility criterion created the greatest risk for the selected topic?
=> The greatest risk is MVP feasibility rated as great difficulty, requiring category -
differentiated reorder logic, with real risk of over-scoping if not tightly controlled within 5
weeks.
24. What did the empathy/root-cause analysis change in the proposal?
=> Shifted the root cause from "lack of an integrated data system" (generic) to "lack of
reorder rules differentiated by product category" (specific) – directly affecting design.
25. What evidence must be collected before requirements can be finalized?
=> Actual stock-out frequency from POS data, average time spent processing replenishment,
and specific ordered quantities by product group (to confirm the assumed pattern differences
across the 3 categories).
Addition
Link accessed to our Drive (for monitoring):
[Link]
usp=sharing