Setting the Boundary of an Administrative Process with Makigami
In one sentence
Makigami follows the path of information, decisions and responsibility for a request in office and administrative processes; the boundary of the map is set by the accepted result, not by department names.
By the end of this lesson
- Define the common start event and the accepted output condition for 24 requests.
- Separate role, activity, information and handoff events on the same map.
- Reconcile the numbers of opened and closed requests with the change in open work.
- Detect a wait pushed outside the process or a request that was never closed.
Why it matters
Makigami is an approach used for flow analysis of office and administrative processes. What is examined is not the order of desks or departments but which information and decisions produce the requested result. A request may wait with different people, return because of missing information, or be forwarded elsewhere without any work being done. Department boxes do not describe these events by themselves. A map is useful when it ties the path of the request to traceable records. Detailed arrows drawn without agreement on the start, the end and the acceptance condition can hide different readings of the same process.
The process boundary determines which question the measurement answers. For example, in an internal service request the start may be the moment the request reaches the common record point. If the moment after the completeness check is chosen, the time to complete missing information falls outside the scope. This choice is not wrong in every case; but it is not the same as the time promised to the user. The work left out of scope is stated separately at the beginning of the map. This prevents it from looking as if waiting had been reduced by moving the start forward. For the end as well, completion of the internal operation is separated from acceptance of the output by the requester.
Roles must be defined more concretely than the titles on an organization chart. The roles that take the record, verify the information, make the authorized decision and notify the result can be carried out by the same person. Conversely, one department may contain several roles. When the owner of each event and the information it uses are visible on the map, it becomes clear what a handoff really changes. Merely sending the message to another address does not prove that the output has been accepted. The role that takes responsibility must be able to explain which information it found sufficient and under which condition. This explanation serves understanding the process rather than evaluating the person.
In this lesson an examination scope will be built on 24 requests. The number of requests, the number of events and the number of employees are different quantities. Not every message about the same request is a new request; the return of the same request does not change its identity either. Work that is still unclosed at the end of the period is not deleted from the map. It is kept both in the open work calculation and in the waiting review. The aim is not to fit the whole office on a single map but to show the real path of a request family that shares a start and an acceptance condition. The later time and quality calculations are comparable only if this boundary is preserved.
Formula
Open work at period end (requests) = Open work at period start + Incoming requests − Closed requests
Acceptance rate (%) = Accepted requests ÷ Examined requests × 100
Average handoffs (handoffs/request) = Total responsibility handoffs ÷ Tracked requests
Unlock the rest of this lesson with an Academy account
Create a free Academy account with your work email address; it can be used once it is approved.
- Step-by-step instructions
- Worked example with real numbers
- Where the method misleads
- Common mistakes