Administrative Future State and Service Design
In one sentence
A future state is more than a drawing with fewer signatures; it designs together the accepted service, the necessary decision authority, error control and the rule for starting work.
By the end of this lesson
- Test a decision to remove an approval by identifying which information and authority function it provides.
- Calculate active time, waiting and weighted total time for two request paths.
- Reject a fast design that exceeds the authority limit.
- Define quality, time and stopping criteria for a future-state trial.
Why it matters
The current-state map shows where time passes; the future state describes which service will be produced under which rules. A drop in the number of signatures is not good design by itself. One approval may be a repeated information check; another approval may provide decision authority, the suitability of a resource or the finding of a different error. If only the time of the activity to be removed is taken out without explaining its function, a new flow that looks fast can lose a necessary check. For this reason each proposal must show, besides the work that disappears, the acceptance condition that is preserved.
Service design starts from the need of the requester. With what information they will apply, when it will be taken into processing, which decision will be given by whom and how they will accept the result must be clear. Besides the standard path, paths for missing information, exceeding the authority limit and scope change are also designed. Forcing every request onto the same fast path makes exceptions invisible. If different paths are needed, the condition separating them must be verifiable from the record. A distinction that depends on an employee's memory or goodwill does not make a shared and sustainable process rule.
Future-state times must separate measured results from estimates. If the queue of the removed approval really disappears, that waiting can be subtracted in the target calculation. But if the work moved to another role has a new queue, it cannot be deleted from the total. A faster path pulling in more work can also change capacity conditions. First the two options are compared with the same request mix and the same acceptance boundary; then the estimate is verified with trial data. If error rate, rework and open work are not tracked together, a time gain may have been obtained at the price of a new quality loss.
In this lesson, an option that removes an approval from all requests is compared with an option that removes it only from the standard path whose authority is sufficient. The speed difference is calculated numerically, but the decision depends on preserving the necessary authority. The authority limits are internal rules defined for the example; they are not a requirement of a real business or of legislation. The success of the design is that it reliably produces the same accepted result with fewer steps. The pilot trial also covers what to do when an error occurs and under which condition to return to the old flow; uncertainty is not closed only with a fast average.
Formula
Path total time (min/request) = Active time + Waiting
Weighted average time (min/request) = Sum over paths of (Path time × Number of requests) ÷ Total number of requests
Time reduction (%) = (Old average − New average) ÷ Old average × 100
Control conditions: Information accuracy, necessary authority and acceptance evidence are preserved together
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