Chapter 3 — Data in organisations
Lesson map
Lesson 03 published. Map, example, EX007.
flowchart TD
N0["Learning outcomes"]
N1["3.1 Following a sale"]
N2["3.2 Creators and users"]
N3["3.3 Distant effects"]
N4["3.4 Data as a shared resource"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX007"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["3.1 Following a sale"]
N2["3.2 Creators and users"]
N3["3.3 Distant effects"]
N4["3.4 Data as a shared resource"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX007"]
[Learning outcomes]
|
v
[3.1 Following a sale]
|
v
[3.2 Creators and users]
|
v
[3.3 Distant effects]
|
v
[3.4 Data as a shared resource]
|
v
[Worked example] --> [Exercise EX007]
Learning outcomes
You will (1) trace how data move through an organisation; (2) identify who creates and uses data; (3) explain why problems appear far from their causes.
3.1 Following a sale
Amara follows one sale through Harbourline. The till records items, prices and the loyalty card. The store system sends totals to finance each night. The loyalty system adds points. The stock system reduces inventory. Marketing later analyses purchases to send offers. One action at a till creates data used by five systems and several teams. She draws the path on a diagram and realises that an error at the till spreads into finance, stock and marketing. Store staff confirm her diagram is accurate in a short meeting.
3.2 Creators and users
Store staff create most data but rarely use reports. Head office teams use reports but rarely see how data are created. Amara interviews a store supervisor who says staff often key a generic product code when a barcode fails, to keep queues moving. Head office then sees odd sales of the generic product. Neither side knows the other's situation. She concludes that governance must connect creators and users so each understands the effect of their actions on the other. Amara arranges a joint visit.
3.3 Distant effects
A wrong price set in the product system shows up weeks later as a stock discrepancy at stores, then as a margin problem in finance. By the time finance notices, the cause is hard to trace. Amara compares data problems to pollution in a river: the effect appears downstream, far from the source. Governance needs ways to trace effects back to causes, which is why later chapters cover lineage, ownership and issue management in detail. Amara writes the river comparison in her journal for later use.
3.4 Data as a shared resource
Dr. Lindqvist explains that data at Harbourline are shared resources, used by many teams but owned clearly by few. Without rules, each team optimises for its own needs, as store staff do with generic codes. The result resembles overuse of a common pasture, where everyone suffers. Amara notes that governance creates the rules and roles that let a shared resource stay useful for everyone, balancing local convenience against wider needs across the whole co-operative. The comparison helps her explain governance to friends who study economics.
Worked example
Amara traces one sale through five systems, finds that generic product codes keyed at tills distort head office reports and compares data problems to downstream pollution.
Synthetic case. Systems and interviews are synthetic.
Errors and limits
Blaming the team that notices a problem ignores its source.
Exercises
- EX007 — Systems touched. How many systems use data from one sale? Rubric: 3 = five;; 2 = partly correct;; 1 = wrong;; 0 = none.
- EX008 — Generic codes. Why do staff key generic product codes? Rubric: 3 = to keep queues moving when barcodes fail;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX009 — Shared resource. What do governance rules balance? Rubric: 3 = local convenience against wider needs;; 2 = partly correct;; 1 = vague;; 0 = none.
Continue studying — lesson 03 (chapter 03 of 40)
← Chapter 02 · Course chapter index · Chapter 04 →
Continue to the next authored lesson.