When people define processes, they usually start from the beginning. They ask "What do I have? What should I do with it?" If you're lucky, they also ask "Who needs it?" but that usually comes last.

The trouble is that when you string a bunch of processes like this together in a company, you find "gaps" between them. That's where one person delivers a spreadsheet that someone else has to manipulate more before they can use it. Or where one group delivers GUI mockups without dynamics to another group who is supposed to implement it. It leads to waste.

I often find processes with no consumers. Pure waste! Literally nobody uses the output, but the producer doesn't realize it.

When defining a process, I think you should start at the end. Define it from the perspective of the consumer.

I like to ask the questions in this order:

1. Who is the consumer?
2. What do they need?
3. How do you deliver it to them?
4. How do you know when they're ready for it?
5. How do you produce it?
6. What inputs do you need to produce it?

By doing it this way, you naturally create a process that includes signaling, delivers good (i.e., usable) outputs, and doesn't have any gaps.