Keep people, states and evidence apart

Process diagrams get hard to use when people, system states and documents all end up in the same set of boxes. I'd keep them separate, even if the first version is just a working note.

Actors are the people or services responsible for doing something. Use roles rather than names: requester, coordinator, approver, finance operator, scheduled job, external service. A role can move between people during the day, and one person can wear several roles. That matters because the replacement should give authority to the role, and you don't want to carry over an accidental dependency on whoever happens to do it now.

States describe what the work currently means. "Submitted", "waiting for information", "approved", "rejected" and "completed" are fine if everyone reads them the same way. Status labels in the old application often hide several different situations, though. A record marked "open" might be untouched, being investigated, waiting on the requester or stuck behind another system. If those situations lead to different actions, you need to pull them apart before anyone designs a status field.

Evidence is whatever lets another person confirm the state or the decision. It could be a submitted form, an approval message, a generated receipt, a source document, a timestamped event or a reconciliation record. Attach it to the step where it mattered. A folder at the end with every file in it doesn't help much when nobody can tell which item justified an approval or a change.

For each step, I'd capture a small set of facts:

• who starts it
• what state the work has to be in first
• what information they read
• what they decide or do
• what state it's in afterwards
• what evidence gets kept
• who's expected to act next

That shows you the gaps without turning discovery into a full technical spec, and it keeps the proposed product organised around changes in the work instead of the old application's pages.

Watch out for vague verbs as you go. "Process", "handle", "review" and "manage" usually squash several decisions into one word. In the notes, swap them for what actually happens. Someone might validate an identifier, compare an amount, ask for missing information and then assign a category. Each of those needs different data and can go wrong in a different way.