The workshop gives you the version people can defend
Ask a room of people how their process works and you will get the version they can defend. It matches the procedure document, the training deck and whatever the auditor saw last year. It has very little to do with what happens on a Thursday afternoon when a truck is at the dock and the approval has not come through, which is the process your ERP programme actually has to support.
Nobody is lying in those sessions. People describe the path they are supposed to take, in front of their manager, to a consultant they met an hour ago. Under those conditions the documented answer is the only safe answer, and you will get it every time unless you change the question.
The real process lives in the exceptions. The spreadsheet holding the twelve customers on different payment terms. The phone call to the plant scheduler that appears in no flow diagram. Discovery succeeds or fails on whether those things reach your notes.
Ask for the last one they handled
Stop asking how requisitions get approved. Ask the buyer to open the last requisition she handled and walk you through it, from the moment it arrived to the moment it closed. A general question returns the documented path. A specific record returns what happened.
The gap shows up inside a minute. Asked in general, she describes three approval levels and a delegation rule. Asked about the one she handled on Tuesday, she mentions that she rang the cost centre owner because the queue was four days deep, then recorded his approval herself once he agreed on the phone. No document describes that step, and it happens on most orders above a certain value.
Take the awkward transactions if you get a choice. People remember the ones that went wrong in real detail, down to who they rang and what time. The smooth ones blur back into the training they had three years ago.
Ask what breaks and who they call
Two questions do most of the work. The first is what you do when the normal path does not work. The second is who you call when something goes wrong.
The first one produces the workaround inventory, and every long-running process has one. A payroll administrator once told me she keeps a spreadsheet of about thirty employees whose hours are corrected by hand every fortnight, because their shift pattern was never configured properly. That spreadsheet was a live requirement for the new SuccessFactors build, and it had never appeared on any requirements list.
The second question finds the dependency nobody documented. The name you get back is rarely on the project org chart. It is the finance analyst who knows how to unstick a posting, or the supervisor who can tell you which batch actually shipped when the system says two different things. If your design removes their intervention point without replacing it, you have built in a failure that surfaces in week one.
Sit next to the work instead of asking about it
An interview gives you a description of the work. Sitting beside someone while they do it gives you the work. Half a day at a goods receipt desk taught me more about an S/4HANA design than the six hours of workshops that preceded it.
You see the second system immediately. The printed sheet on the desk with handwritten notes down the margin. Two windows open at once because one of them holds a number the other does not show. None of it comes up in a workshop, because it is too ordinary for anyone to think of mentioning.
Say clearly that you are not assessing anybody, then stay quiet and let them work. When something surprises you, wait until the transaction is finished before you ask. Interrupting turns the observation back into an interview.
Who is in the room decides what you hear
The most expensive structural mistake in discovery is putting a manager and the people who do the work in the same session. The manager describes the process as designed, honestly, and nobody who reports to them will contradict that in front of a stranger holding a marker pen. Run those sessions separately and compare the accounts. The same goes for two functions with a live argument between them, since finance and operations in one room will spend the time negotiating instead of describing.
Every workshop has someone who fills every silence, usually senior, usually articulate, usually the furthest from the keyboard of anyone present. Give them a task. Ask them to capture the exception list on the whiteboard while someone else talks, and put your questions to named people rather than to the room. The quietest person is very often the one who does the work, and an open floor guarantees you never hear from them.
Near the end of every session I go round the table by name and ask each person what happens in their part of this that we have not covered. The answers from the quiet ones are regularly the most useful thing in the two hours.
Contradictions are findings, not problems
When two people describe the same step differently, the instinct is to settle it in the room and write down the agreed version. Resist it. A contradiction means the process runs two ways, or somebody has been doing it wrong for a year without anyone noticing, or the step depends on a condition neither of them has mentioned. All three beat the tidy answer you would otherwise write down.
Write both versions down verbatim with names attached and carry them into design. Some resolve once you find the missing condition. Others turn out to be two genuine variants the configuration has to support, and catching that in discovery rather than build is the difference between a design decision and a change order. The same discipline belongs in how you scope the statement of work, where an unresolved contradiction becomes a priced assumption.
Record who disagreed as well. The disagreement usually maps to an ownership question that governance has to settle before go-live, and naming it in week three gives the programme months to work on it instead of days.
The requirement that arrived after the session closed
The clearest example I have came out of a two-hour session on goods receipt at a food distributor. Eight people, a process model on the wall, and a warehouse manager who ran more of it than I did. We finished with a clean flow, four decision points, and a model I was quietly pleased with.
Then the room emptied and one of the supervisors stayed behind to stack chairs. He asked whether the new system would still let him receive a pallet against a delivery note that did not match the order, because the bakery they buy from short-ships most Fridays and makes up the difference on the following delivery. The arrangement had been running for eleven years. It appeared in no document, it had not come up once in two hours, and it touched around a fifth of inbound volume.
He had never raised it in the session because his manager was sitting opposite him and the arrangement sits outside the receiving policy as written. The requirement most likely to break your design is the one the person cannot say out loud in a room with their reporting line in it.
So plan for the after. Leave twenty minutes at the end of every session with nothing scheduled, stay while people pack up, and offer to walk back to someone's desk with them. Most of what I have learned doing consulting work on ERP and HR programmes arrived in that twenty minutes, from the person who would never have said it with the whiteboard still up.
