TO-BE Workflow Design

Draw TO-BE as a "picture"

Write TO-BE in prose and it gets vague. In the same role × timeline format as AS-IS, mark the steps that change with "changed," "new," or "abolished." This lets the field, management, and the vendor all look at the same thing and debate it.

The 3 layers of solutions

Think of solutions in the following three layers. A template for avoiding the failure pattern of trying to solve everything with the system alone.

• ─① Rule change — change the operating rules themselves (most effective, but requires agreement)
• ─② Operational change — rearranging procedures or roles
• ─③ Systematization — systematize the routine work left after ① and ②

Using the "marks attached to steps"

TO-BE adds the following marks to the same format as AS-IS. The differences become visible at a glance.

Drawing the scope line (do / don't do)

The moment you draw TO-BE, you'll want to do everything. It's not enough to decide only the "do" side of scope — make the "don't do" side explicit on the business workflow. Note the reasons for not doing it (cost / difficulty of agreement / priority) too, and you won't have to repeat the same debate when someone says "do that as well" during Ph.6 requirements definition.

Criteria for selecting a solution

"Systematization" isn't always the answer. There are four criteria.

• ─Frequency: high frequency → systematize; once a month → a rule change is enough
• ─Repeatability: routine → systematize; requires judgment → AI + human confirmation
• ─Difficulty of agreement: a rule change is heavy on agreement; systematization depends on the vendor
• ─ROI: work it backward from development cost × operating cost × effort saved

Surface the risks lurking at role boundaries

A trap that appears the moment you draw a TO-BE workflow is overlooking the risk at "role boundaries" (where an arrow crosses into a different lane). Line segments where the medium or owner changes — handheld terminal → system import, supplier EDI → warehouse — must always be risk-analyzed separately.

• ─Boundary: which role → which role (or which medium → which medium)
• ─Failure: concretely write the failures that could occur there (comms drop / read error / format mismatch, etc.)
• ─Impact: how that failure ripples into operations (inventory mismatch / shipping halt / customer complaint)

Design the fallback flow on failure with 4 elements

A TO-BE that draws only the "happy path" always gets stuck in the field. For the single highest-impact boundary, design the fallback flow on failure with four elements. This turns operational design from "armchair theory" into "working in the field."

• ─Detection: who detects the failure, and how (automatic alert / daily review / someone noticing on-site)
• ─Action: after detection, who acts, and within how many minutes
• ─Fallback: what alternative means keeps operations going (manual entry / prior-day close value / a different role covering)
• ─Decision criteria: the criteria for switching to the fallback (switch if recovery is impossible for 30+ minutes, etc.)

Compare options with the "4 questions"

When comparing improvement options A and B, debating by "preference for features" won't reach agreement. Line them up mechanically with the following four questions and the judgment axis aligns to "comparing boundary risks."

• ─① What new risks arise?
• ─② What new requirements are imposed? (what is asked of the field / partners)
• ─③ What happens if it fails?
• ─④ How does the fallback flow run on failure?