The actual process, or the one on paper?
The diagram sends an enquiry straight to the person preparing the quote. A conversation with the team reveals that someone first checks the information in a separate spreadsheet. This is an illustrative example of a difference worth investigating. A document may be accurate, outdated or incomplete. Find out how work runs today before deciding what to change.
Two different distinctions
Documented and observed describe where information about the process comes from. Current and future describe which state it represents. A map on paper can accurately show today's work. Another may explicitly propose a future change. Being documented does not mean a process depicts the desired future.
As-is means the actual current state; to-be means the future state you want to reach. Include the usual steps, important exceptions and workarounds in the current-state map. Keep proposed changes separate so readers do not mistake them for a way of working already introduced.
When someone's account differs from the document, you do not yet know which source is accurate. They may be describing an exception, an old practice or only their part. Record the difference and check specific cases instead of immediately turning it into a new rule.
Why start with current work?
Before removing a check, find out why it was added. It may duplicate another step, or cover a risk the diagram does not show. Designing a future process from an old document alone risks changing the wrong part or missing the cause of waiting and rework.
This does not require discarding all existing instructions. Use them to start the check: which participants, tools, decisions and handoffs do they describe, and which cases are missing? Then compare them with actual execution. A map helps bring observations together, but does not replace checking them.
What does a difference look like in practice?
In the illustrative enquiry example, the spreadsheet check may have been introduced because necessary information was missing. One colleague checks it, another asks a question and a third waits for confirmation for the quote. A single arrow from enquiry to quote will not show who holds the task during that wait.
The difference may concern the order of work, the actual owner, the tool or the condition for the next step. Record what passes between people and how the recipient knows to act. Do not assume every deviation is waste: some exceptions are necessary and need documenting.
How can you check the account against the work?
Talk to people doing the different parts, including during the usual owner's absence. Ask them to walk through a recent case from beginning to end. Compare their account with available traces: sending and receiving times, edit history, status changes or file handoffs.
Check what each trace actually shows. A file's last-modified time does not prove when work on it began. A missing system event does not prove that an action outside that system never happened. Agreement between an account and a record strengthens that particular observation, but does not automatically validate the entire process.
Where sources differ, state which cases you examined and what you still do not know. A map can carry a note about an unverified exception instead of an apparently certain arrow. The person making a decision can then see the evidence's limits.
When does the document need checking?
A new tool, a change of owner or a recurring exception are reasons to check the affected part. So are an incident or a change in an applicable requirement. If there is no record of when the map was checked, that is missing traceability, rather than proof of exactly when it became outdated.
Name the document's owner, the state it describes and the cases used to check it. After a change, check whether participants follow the new version too. A recent date alone does not show that the change has been introduced.
Questions
Should we update the old diagram or start again?
That depends on its accuracy and scope. If the main flow remains intact, check and correct the affected parts. If participants and important exceptions are missing, trace the workflow from the beginning and compare it with the old document. You do not always need to redraw everything.
Which source is better: the person or the system?
Use them together. A participant explains meaning and exceptions; a system can provide records of particular events. Check the coverage of both sources. A difference needs investigation, rather than automatically choosing one side.
How often should you check the map?
WorkFlawless suggests 6–12 months for core procedures, quarterly checks for high-risk or fast-changing work, and 1–2 years for stable administration. These are vendor guidelines, not a universal compliance timetable.
Choose the frequency for your risks and changes. An incident, new tool or changed requirement may call for a check before the scheduled date.
Sources
Related reading
Next step
Check the actual process before changing it.
An Expert Review works with the participants in the agreed scope and records the actual process, not the drawing from the last slide deck. The result is a map and report you can check line by line.
or write to contact@ergostrat.com