Start with one piece of work that actually got finished

A lot of replacement projects start with a list of what the current system has: screens, reports, integrations. That list is useful, but it describes the software much better than it describes the work, and you can see the gap as soon as you follow one finished request through the organisation.

Pick a request that's recent enough for people to remember and ordinary enough to show the normal process. An unusual complaint or a huge order drags the conversation towards special handling. A perfect example can mislead you too, because nobody had to sort out an error along the way. What you want is something with a clear beginning, a result somebody accepted, and enough records left behind to show how it moved.

If you can, collect the material before the walkthrough: the original request, system records, clarifying messages, approvals, exported files and the final confirmation. Mask anything private. You're trying to see which records carried the work along, and nobody's case needs to become a show for the workshop.

During the walkthrough, ask whoever did each step to show you what they received and what they produced. "Operations checks it" is too broad to be useful. What does the checker open? Which fields do they compare? Where do they go when the values don't match? How do they know they're done? Once you've got answers to those, a named stage turns into work you can actually see.

Write down the edges of the example as well: the request type, the channel it came in on, the team responsible, where it started and what counted as finished. If the process changes by region, customer type or contract, note which branch this one followed. Otherwise one particular path quietly becomes everyone's assumed process.

One case won't give you every requirement. It does give the team a concrete path to test the next case against, and at this stage that's a lot more use than a tour through every menu in software that's been around for years.