Work Understanding: Applications and systems
Objective. Read the applications-and-systems view to see which systems the process touches and where swivel-chair switching happens, so a reader can flag a systems-fragmentation hypothesis without labelling any application as unproductive.
This view answers 'which systems does this work flow through, and where does switching between them cost time?' It surfaces swivel-chair friction - the tax of moving between applications.
See it in the demo
What this screen answers
The customer question is: which applications and systems does this process rely on, and where does moving between them add time? A Sales person uses it to make systems fragmentation visible. A CSM uses it to spot where switching between systems is a candidate source of delay worth investigating.
The task
Scope to the process and period, then read which systems the work touches and where switching between them clusters. The move is to surface a swivel-chair pattern - repeated hopping between two systems at a particular step - as a candidate friction to validate, linked to the step time and friction screens that quantify its cost.
How to read it
System usage is observed from captured signal, and time in an application is not a judgement about that application. The classic misread is labelling a system as the problem or an application as 'unproductive' - a non-productive label is not proof that no useful work happened there. Read a high switching pattern as a hypothesis about fragmentation to validate, not a verdict on a tool or a person.
Honest limits
The view does not prove that switching causes the delay or that consolidating systems would remove it, and coverage bounds what it sees. It does not establish that an application is wasteful. Confirm with the customer whether the switching is avoidable and validate the cost with a measured before/after before proposing a systems change.
Interpretation check
Time in an application is not proof the application is wasteful, and a switching pattern is a fragmentation hypothesis to validate, not a verdict on a tool or person.
Practical task
On the applications/systems view for one process, name the switching pattern that looks costly, state it as a fragmentation hypothesis, and name the screen you would use to quantify its time cost before validating.
Self-check
The view shows heavy time in one application. Is that the problem?
Not necessarily. A non-productive label is not proof no useful work happened there. Treat heavy usage or switching as a hypothesis to investigate, not a verdict on the tool.
What is swivel-chair friction and why does it matter?
Repeated switching between systems at a step, which can add time. It is a candidate friction to quantify at step time and friction screens, then validate - not an assumed cost.
Before proposing the customer consolidate systems, what do you confirm?
That the switching is avoidable and that removing it actually releases time, validated with a measured before/after rather than assumed.
Verified vs demo. Screen is live in the demo at /#/apps; exact controls, system list and figures are SME-validation-pending.