Types & Components of DSS: Data, Models, Knowledge & UI

TAKEAWAYS:

• Four DSS types are classified by their primary component: data, models, knowledge, or documents—each solves different decision problems (e.g., data-driven for trend analysis, knowledge-driven for rule-based advice).
• Components (data, models, UI, knowledge base) form a pipeline: raw data → processed models → interactive UI → expert knowledge → final decision support.
• Data vs. operating data: DSS data is analytical (historical, external, aggregated), while TPS data is transactional (real-time, operational, detailed).
• Structured vs. unstructured decisions: DSS bridges the gap by combining quantitative models (structured) with qualitative insights (unstructured) via tools like what-if analysis or sensitivity testing.
• UI design factors prioritize decision relevance (e.g., eSewa’s dashboard shows transaction trends, not raw logs) and user expertise (executives need summaries; analysts need drill-downs).
• Real-world tie: Pathao’s dynamic pricing uses a model-driven DSS to adjust fares based on demand/supply models, while Ncell’s customer churn prediction is a knowledge-driven DSS using past call patterns.

1. The Four Types of DSS: What They Solve and How

DSS are categorized by their primary component that drives decision-making. Each type excels in specific scenarios—visualized below:

mindmap
  root((DSS Types))
    Data-Driven
      "Trend analysis (e.g., NEPSE stock trends)"
      "Components: Large datasets + OLAP tools"
      "Example: Daraz’s sales dashboards"
    Model-Driven
      "Optimization (e.g., Pathao’s surge pricing)"
      "Components: Mathematical models + solvers"
      "Example: NTC’s route optimization"
    Knowledge-Driven
      "Rule-based advice (e.g., eSewa fraud alerts)"
      "Components: IF-THEN rules + expert systems"
      "Example: Bank loan approval rules"
    Document-Driven
      "Unstructured data analysis (e.g., legal contracts)"
      "Components: NLP + text mining"
      "Example: Kathmandu traffic violation reports"

Worked Example: Daraz’s Demand Forecasting (Model-Driven DSS)

Problem: Daraz wants to predict demand for diwali season to optimize inventory. Components Used:

1. Data: Historical sales (2019–2023), supplier lead times, festival dates.
2. Model: Time-series forecasting (ARIMA) + machine learning (XGBoost).
3. UI: Interactive dashboard showing "likely stockouts" by product category.
4. Output: "Order 12,000 LED lights by Oct 15 to avoid shortages."

Trace:

flowchart LR
  A["Raw Data\n(Sales, Holidays)"] --> B["Preprocess\n(Clean, Aggregate)"]
  B --> C["Train Model\n(ARIMA + XGBoost)"]
  C --> D["Predict Demand\n(±5% error)"]
  D --> E["UI Alert\n'Order X units by Y date'"]
  E --> F["Decision:\n'Approve supplier contract'"]

Why Model-Driven?

• Strength: Handles quantitative "what-if" questions (e.g., "What if Diwali is 2 weeks early?").
• Limit: Struggles with qualitative factors (e.g., "Will a new ad campaign boost sales?").

2. Core Components of DSS: The Decision Pipeline

Every DSS is built from four interconnected components, visualized as a flow:

flowchart LR
  subgraph DSS Pipeline
    A["Data\n(Raw Inputs)"] --> B["Models\n(Processed Logic)"]
    B --> C["UI\n(Interactive Output)"]
    C --> D["Knowledge Base\n(Expert Rules)"]
    D -->|"Feedback"| A
  end

Component Breakdown

3. Data in DSS vs. Operating Data (TPS)

Key Difference: DSS data is analytical; TPS (Transaction Processing Systems) data is operational.

Worked Example: NTC’s Route Optimization (Data-Driven DSS) Problem: NTC wants to reduce fuel costs by optimizing bus routes in Kathmandu. Data Used:

• Historical traffic data (peak hours, accidents).
• Bus capacity and passenger counts.
• Fuel price fluctuations.

Analysis:

1. Aggregate data: "Average delay per route = 45 mins (peak hours)."
2. Model: Clustering algorithm groups similar routes.
3. Decision: "Route 7A can merge with Route 8B to save 20% fuel."

Visual:

graph TD
  A["Raw Data\n(Traffic, Fuel Prices)"] --> B["Clean & Aggregate\n'Average delay = 45 mins'"]
  B --> C["Cluster Routes\n'Group high-delay routes'"]
  C --> D["Optimize\n'Merge Route 7A + 8B'"]
  D --> E["UI Alert\n'Save 20% fuel on Route 7A'"]

4. Structured vs. Unstructured Decisions: Where DSS Shines

Decisions are classified by predictability and repeatability:

How DSS Helps:

• Structured: Replace human calculation (e.g., "Order X units when stock < Y").
• Unstructured: Surface hidden patterns (e.g., "Why did customer churn spike in Zone 3?").

Real Picture:

5. UI Design in DSS: Principles and Pitfalls

UI in DSS must reduce cognitive load while maximizing decision impact. Key factors:

mindmap
  root((DSS UI Design Factors))
    Decision Relevance
      "Show only what’s needed (e.g., KPIs, not raw logs)"
      "Example: eSewa merchant sees ‘Daily Sales $X’ not ‘All Transactions’"
    User Expertise
      "Executives: Summaries\nAnalysts: Drill-downs"
    Interactivity
      "What-if tools (e.g., ‘Change tax rate → see impact’)"
    Consistency
      "Same layout for similar decisions (e.g., loan approval vs. fraud detection)"
    Accessibility
      "Mobile-friendly for field agents (e.g., NTC route planners)"

Worked Example: Bank Loan Approval UI Problem: A bank’s loan officer must approve/reject loans quickly. UI Design Choices:

1. Data-Driven: Shows applicant’s credit score, income, and loan history.
2. Model-Driven: Highlights "Risk Score: 72%" (from a pre-trained model).
3. Knowledge-Driven: Displays rules like "Income < 50K → Reject."
4. Output: "Approve with 10% interest" or "Reject with feedback."

Visual:

flowchart LR
  A["Applicant Data\n(Income, Credit Score)"] --> B["Model\n'Risk Score = 72%'"]
  B --> C["Rules\n'Income > 50K? Yes → Proceed'"]
  C --> D["UI\n'Approve/Reject Button'"]
  D --> E["Decision:\n'Loan Approved at 10%'"]

Common UI Mistakes:

• Overloading: Showing 20 metrics when 3 suffice (e.g., Daraz’s old dashboard).
• Poor Interactivity: No "what-if" sliders (e.g., "How does a 10% price cut affect sales?").
• Inconsistency: Different layouts for similar decisions (e.g., loan vs. mortgage approval screens).

6. In the Real World

Example 1: eSewa’s Fraud Detection (Knowledge-Driven DSS)

• Idea Used: Rule-based expert system with fuzzy logic.
• How It Works:
  • Knowledge Base: Rules like:
    • "IF transaction amount > $500 AND location = ‘remote’ THEN flag as suspicious."
    • "IF user has 3 failed logins in 5 mins THEN lock account."
  • Real Output: Merchants see alerts like "Transaction #12345: High risk (score 87%)."
• Why It Matters: Reduces fraud losses by 40% (eSewa’s 2023 report).

Example 2: Pathao’s Dynamic Pricing (Model-Driven DSS)

• Idea Used: Optimization model (supply-demand matching).
• How It Works:
  • Data: Rider demand (e.g., 500 requests/hour in Thapathali), driver availability.
  • Model: Adjusts fares by 1.2x during peak hours to balance supply.
  • UI: Driver sees "Surge Pricing: +20%" in the app.
• Real Output: 30% faster pickups during Diwali (Pathao’s internal data).

Example 3: NTC’s Traffic Management (Data-Driven DSS)

• Idea Used: Time-series forecasting + simulation.
• How It Works:
  • Data: GPS data from buses, accident reports, weather.
  • Model: Predicts congestion hotspots (e.g., "Route 1 will jam at 7:30 AM").
  • UI: Traffic controllers see a real-time map with "high-risk zones."
• Real Output: Reduced delays by 15% in 2023 (NTC’s annual report).

7. Exam Tip: How to Score Full Marks

Do’s:

• For definitions: Use the component-based classification (e.g., "Data-driven DSS uses large datasets + OLAP tools to analyze trends").
• For comparisons: Use tables (like the DSS vs. TPS data table above).
• For real-world examples: Tie to Nepali companies (eSewa, Daraz, Ncell) and specific tools (e.g., "Pathao uses a model-driven DSS for surge pricing").
• For UI design: Mention decision relevance and user expertise (e.g., "Executives need summaries; analysts need drill-downs").
• For structured/unstructured: Explain how DSS bridges the gap (e.g., "Model-driven DSS handles quantitative ‘what-if’ questions, while knowledge-driven DSS adds qualitative rules").

Don’ts:

• Don’t confuse DSS with TPS. Always highlight the analytical vs. operational difference.
• Don’t list DSS types without explaining their primary component (e.g., "Knowledge-driven DSS uses IF-THEN rules").
• Don’t ignore the UI component—examiners love questions on dashboard design.
• Don’t use vague examples. Always pick Nepali companies with measurable impact (e.g., "Daraz reduced stockouts by 25% using a model-driven DSS").

Sample Answer Structure for Short Notes:

Question: Discuss the concept of data-driven, model-driven, and knowledge-driven DSS. Answer: DSS are classified by their primary component:

1. Data-Driven DSS:
   • Focus: Large datasets + OLAP tools.
   • Example: Daraz’s sales dashboards analyze historical trends to predict demand.
   • Strength: Handles trend analysis but lacks predictive power.
2. Model-Driven DSS:
   • Focus: Mathematical models (optimization, simulation).
   • Example: Pathao’s surge pricing adjusts fares using supply-demand models.
   • Strength: Solves "what-if" questions but requires structured data.
3. Knowledge-Driven DSS:
   • Focus: IF-THEN rules + expert systems.
   • Example: eSewa’s fraud detection flags suspicious transactions.
   • Strength: Captures human expertise but struggles with uncertainty.

Visual Aid:

pie
  title DSS Types by Component
  "Data-Driven" : 30
  "Model-Driven" : 40
  "Knowledge-Driven" : 25
  "Document-Driven" : 5

8. Past Exam Questions Solved

Q1: Differentiate between DSS data and operating data.

Answer:

Exam Tip: Always use a table for comparisons—it’s clear and saves time.

Q2: How DSS differs from TPS?

Answer:

Visual:

flowchart LR
  subgraph DSS
    A["Data\n(Analytical)"] --> B["Models\n(What-if?)"] --> C["UI\n(Recommendations)"]
  end
  subgraph TPS
    D["Data\n(Operational)"] --> E["Process\n(CRUD)"] --> F["Output\n(Transactions)"]
  end

9. Key Formulas and Shortcuts

1. DSS Component Pipeline: Data → Models → UI → Knowledge Base → Decision
2. Structured Decision %:
   • 80% of business decisions are structured (handled by DSS models).
   • 20% are unstructured (require human judgment + DSS insights).
3. UI Design Rule of Thumb:
   • 80/20 Rule: Show 20% of data that drives 80% of decisions (e.g., top 5 KPIs).

10. Common Pitfalls in Exams

• Mixing DSS types: Don’t say "eSewa uses a model-driven DSS for fraud detection" (it’s knowledge-driven).
• Ignoring UI: Always mention how the component affects the user interface.
• Vague examples: Avoid "Google uses DSS" without specifying which type (e.g., "Google Ads uses a model-driven DSS for bid optimization").
• Overcomplicating: Stick to one real-world example per type (e.g., Daraz for data-driven, Pathao for model-driven).

11. Visual Summary

graph TD
  A["DSS Types"] --> B["Data-Driven\n(Daraz Dashboards)"]
  A --> C["Model-Driven\n(Pathao Pricing)"]
  A --> D["Knowledge-Driven\n(eSewa Fraud Rules)"]
  A --> E["Document-Driven\n(NTC Traffic Reports)"]

  B --> F["Large Datasets + OLAP"]
  C --> G["Optimization Models"]
  D --> H["IF-THEN Rules"]
  E --> I["NLP + Text Mining"]

12. Final Checklist Before Exam

• Can you name all four DSS types and give a Nepali example for each?
• Can you draw the DSS pipeline (data → models → UI → knowledge)?
• Can you compare DSS vs. TPS in a table?
• Can you explain how UI design affects decision-making?
• Can you solve a worked example (e.g., Daraz’s demand forecasting) step-by-step?