Loading
Because the process outlives its purpose. A weekly board approves everything on the list because refusing means explaining, and the record becomes evidence that a meeting happened.
A change is a planned modification with a scope, a risk assessment, an approval and a record of what happened.
Changes carry their affected assets and services, route for the approval their risk class requires, and stay linked to what follows. Standard low-risk changes are pre-approved rather than queued behind a board.
An incident spikes four hours after a change to the same service. The link is visible on both records, so the post-incident review starts from a fact rather than a suspicion.
It will not prevent a bad change. It makes the decision attributable and the consequence traceable, which is what makes the next assessment better informed.
Affected assets, the incidents that follow it, the Loop task that implemented it, and the approvals that let it proceed.
Yes, by class, so the process is not a queue for everything.
Yes, showing collisions and freeze periods.
Suggested by service and time window; a person confirms.
Fourteen days, every module, no card. Or half an hour with someone who will run it on your own records and tell you where it does not help.