Implementation note · 2026
A Designed System Is Not Yet a Working System
A document can be completed in a week. A mechanism becomes real only where someone makes a decision and either passes through it or works around it.
- Reading time
- 3 minutes
- Published through
- Astana Hub
- Topic
- Systems and Implementation
- Series
- The system around the product
About this edition. Originally published in Russian on Astana Hub. This English site edition preserves the implementation method and removes local publication scaffolding.
A mechanism has been designed, documented and approved. The team's work remains exactly as it was.
This is one of the most underestimated parts of governance. A good document does not change behaviour by itself. The rule has to appear at the right moment, survive the first urgent case and leave a trace.
Look for the gap in a real decision
Take one decision from the previous week: a new vendor, contractor access, an AI feature, an exception for a release or another field in a registration form.
Did it pass through the designed mechanism? Did the person know the route existed? Could the mechanism answer before the decision had already been made?
The gap rarely proves that people are undisciplined. More often, the mechanism was designed away from the place where work happens.
Put the mechanism where the decision already happens
Decisions happen in a tracker, pull request, vendor form, procurement request, team chat, meeting or payment flow. A rule stored only in a document participates through a person's memory.
Implementation can be as practical as a required field in a vendor form, one question in a release template, a data boundary in an approved tool or a record without which the request cannot progress.
Not every step needs a hard gate. Use gates where error is costly and difficult to reverse. Elsewhere, make the right question visible at the right time.
Give the exception a designed route
Every rule meets a case it did not anticipate. If there is no route for an urgent or unusual case, the work does not disappear. It becomes invisible.
Name who may approve an exception, how quickly they must answer, which conditions still apply, what is recorded and when the decision returns for review.
A repeating exception is often not misconduct. It is evidence that the rule describes the work inaccurately.
Match the speed of work and leave a trace
If a decision is needed today and the review takes two weeks, the mechanism loses on time. A slow process does not protect the company. It pushes itself out of the workflow.
After the decision, keep a proportionate record: what was decided, by whom, on which facts, under which conditions, what remains open and when it will be reviewed. Without that trace, a deliberate exception and an accidental habit look identical six months later.
Treat implementation as a period, not a launch date
The first real cases will expose missing situations, unclear language and unrealistic timing. That is normal implementation work.
Give the process an owner who sees changes in the work and a curator who maintains the mechanism. Review it after incidents, repeated exceptions, vendor or tool changes, new data, a new market or the departure of a person on whom the route depended.
Every rule needs a place and a moment where it changes a decision. If that moment does not exist, the document may be excellent. The system still does not.