Chapter 20 — Issue management
Lesson map
Lesson 20 published. Map, example, EX058.
flowchart TD
N0["Learning outcomes"]
N1["20.1 Recording issues"]
N2["20.2 Root causes"]
N3["20.3 Closing issues"]
N4["20.4 Learning from the log"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX058"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["20.1 Recording issues"]
N2["20.2 Root causes"]
N3["20.3 Closing issues"]
N4["20.4 Learning from the log"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX058"]
[Learning outcomes]
|
v
[20.1 Recording issues]
|
v
[20.2 Root causes]
|
v
[20.3 Closing issues]
|
v
[20.4 Learning from the log]
|
v
[Worked example] --> [Exercise EX058]
Learning outcomes
You will (1) record and track data issues; (2) find root causes; (3) close issues with evidence.
20.1 Recording issues
Data problems at Harbourline used to be reported by email and forgotten. Amara sets up an issue log with fields for description, reporter, date, affected data, impact, owner, status and resolution. Anyone can report issues through a simple form. Stewards triage new issues weekly, assigning priority based on impact. She notes that a log makes problems visible and countable, which allows the governance group to see patterns and judge whether things are improving. The log is visible to all staff on the intranet.
20.2 Root causes
Amara practises root cause analysis on an issue where loyalty points were missing for some purchases. Asking why repeatedly, she finds that points failed when tills were offline, that offline transactions were uploaded later without card details and that the till software had a known setting to keep card details, which was switched off. Turning the setting on fixes the cause. Correcting points manually would have treated only the symptom. The till supplier confirms the setting and applies it to all stores within a week.
20.3 Closing issues
Issues close only with evidence that the fix worked. For the points issue, Amara checks that offline purchases in the following two weeks received points. She records the evidence in the log. She also asks the steward to confirm with the reporter that the problem is solved. She explains that closing issues on the promise of a fix, without checking, leads to problems returning unnoticed and damages trust in the process. Amara adds a closing checklist to the log so stewards follow the same steps.
20.4 Learning from the log
After six months, Amara analyses the log. Most issues relate to store codes and member duplicates, and many come from manual processes. She presents these patterns to the governance group, which funds automation of a manual export and the duplicate matching work. Dr. Lindqvist notes that an issue log is not only a to-do list but a source of evidence for governance priorities and investment decisions. Amara repeats the analysis every six months, and the share of issues from manual processes falls after the first automation.
Worked example
Amara creates an issue log with weekly triage, traces missing points to a till setting, closes issues only with evidence and analyses six months of issues to guide investment.
Synthetic case. Issues are synthetic.
Errors and limits
Closing issues without verifying fixes lets problems return.
Exercises
- EX058 — Points cause. What caused missing loyalty points? Rubric: 3 = a till setting to keep card details offline was off;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX059 — Closing evidence. What evidence closed the points issue? Rubric: 3 = offline purchases over two weeks received points;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX060 — Log patterns. What did the log show most issues related to? Rubric: 3 = store codes and member duplicates;; 2 = both;; 1 = one;; 0 = none.
Continue studying — lesson 20 (chapter 20 of 40)
← Chapter 19 · Course chapter index · Chapter 21 →
Continue to the next authored lesson.