A capability describes what the business must be able to do. It stays meaningful when departments, processes, or software change. “Resource Scheduling” is an ability; the scheduling platform is one possible way to support it.
A focused view of Northstar
A dependable customer promise needs dependable inputs.
- Parts Availability Management
- Can the required part actually be reserved? An allocation on a screen may not establish that it is held.
- Resource Scheduling
- Can a qualified technician reach the customer in the promised window?
- Customer Promise Management
- Uses those signals to govern the customer commitment. It does not reserve parts or schedule technicians itself.
The customer outcome: restored equipment availability. A promise is useful when it supports that outcome.
Source: Northstar Episode A architecture fragments and E-003. The packet calls C-110 “Service Promise Management”; the Atlas uses the normalized name “Customer Promise Management.” These are decision-relevant dependencies to investigate, not proof of what causes every missed promise.
Keep the boundaries clear.
Giving the customer a commitment is different from reserving a part or assigning a technician. Those abilities need to cooperate, but merging them into one box would hide the dependencies we need to examine.
The information matters too. Northstar distinguishes an allocation from a reservation, and a customer promise from an estimated arrival time. If people use those words differently, connecting systems may move inconsistent information faster.
Follow value to the customer.
A value stream follows how a stakeholder receives value. Northstar calls this one “Restore Equipment Availability.” Defining a feasible service promise contributes to that value; a better scheduling screen alone does not demonstrate it.
Explore these connections in the Atlas
The Atlas is the larger interactive map of this same case. Open it when you want to inspect more relationships, then return here to continue the lesson.