Library / Systems Engineering Principles Framework
Jump to passage
In this reading

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 05:29:54 UTC · snapshot created 2026-10-03 05:30:57 UTC · last check 2026-10-03 05:40:05 UTC

SYSE.39:4 - Solution

SYSE.39:4.1 - Recover the recurring activity and its result

Name the trigger, user, intended result and recurring operations. Observe representative ordinary and exceptional attempts. Separate effort that is necessary to produce the result from effort caused by missing information, a broken interface, repeated repair or unnecessary coordination.

Count occurrence over a meaningful interval. Recover user and provider active effort, waiting, interruptions, rework and errors with enough consistency for the intended comparison. Do not add elapsed waiting to active labor as though they were the same quantity.

Include the people who actually do the work. Determine whether the activity requires unfamiliar diagnosis or necessary professional judgment, and whether a missing capability contributes to the difficulty. Return these distinctions before deciding whether the activity should be automated.

SYSE.39:4.2 - Find what makes the activity recur

Ask what condition recreates the work. Is a resource leaking, a result undiscoverable, an interface ambiguous, an input repeatedly incomplete, or a provider obligation missing? Compare plausible causes using the actual task evidence.

Distinguish repair of a defect from automation of its symptom. A cleanup script may be a justified temporary mitigation, but its maintenance and risk remain part of the intervention. Do not erase required evidence or disable an independent control merely to reduce operator effort.

If the activity no longer serves an accepted need, consider ending it with the appropriate holder. Stopping necessary work without resolving the user result is not burden reduction.

SYSE.39:4.3 - Compare whole-task alternatives

Compare retaining the current method, simplifying the task, removing the cause, improving the supported interaction, and automating the qualified operation. Use SYSE.25 when this intervention competes with other platform improvements; use SYSE.24 only when the question concerns whole ways of obtaining the result.

Keep the user result and conditions comparable. Include construction, maintenance, exceptions, support, failure handling and work transferred to users or other providers over a stated horizon. If the evidence does not discriminate the options, retain the unresolved comparison. Choose a bounded probe when its attainable result can improve the choice enough to justify its full cost and delay; use C.11.DUA when that judgement is unresolved. Otherwise give the present bounded answer and continue only work whose conditions are already supplied.

Use effort arithmetic where the units are comparable, but keep reliability, risk, waiting and lost opportunities visible rather than forcing every consequence into one score. A low-frequency task can reasonably remain manual when automation would add more total burden.

SYSE.39:4.4 - Construct one bounded intervention

When an intervention is selected, construct the smallest change that can test the proposed gain without losing the required result. Retaining the current method or an unresolved comparison creates no intervention or trial requirement. For an interface change, SYSE.26 or SYSE.27 supplies the supported-use and compatibility work. For automation, define the actual input, permitted operation, result and failure/exception behavior.

Retain necessary judgment and authority. Retrieving an already authorized result is different from granting new access or accepting a nonconforming product. An automated wrapper cannot supply a missing decision Method or appointment.

Provide a qualified stop or return for unsupported cases and uncertain effects. Use actual maintenance and support capability, not a generic statement that “the team will own it.” Keep any temporary workaround’s limits and removal condition visible.

SYSE.39:4.5 - Compare burden after actual use

Exercise ordinary, exceptional and failed attempts. Check that the same intended result is obtained and that the work has not simply moved to someone less visible.

Observe comparable use after the intervention, including maintenance and newly created tasks. Compare the proposed mechanism with what actually changed. A shorter ticket queue can result from users abandoning the path; that is not evidence of reduced task burden.

Return the bounded result and remaining uncertainty. Continue, revise or retire the intervention according to that evidence. If only a desk calculation or pilot exists, say so; it cannot establish lasting production benefit.