Eliciting Processes: How to Capture Business Workflows for EPC Modeling

Every accurate EPC diagram begins not with a symbol, but with a question: “What actually happens?” Eliciting the real business workflow is the foundation of any meaningful EPC model. Without this, even the most beautiful diagram can misrepresent reality.

My rule of thumb: never assume. Always verify. The most common error I see in early-stage EPC modeling is jumping to symbols before understanding the actual flow. Too many teams begin with “Let’s draw the process” — but without first understanding the triggers, decisions, and responsibilities involved.

That’s where EPC process elicitation comes in. This chapter walks you through the structured techniques to uncover workflows from day-to-day operations. You’ll learn how to gather accurate, detailed input using stakeholder interviews and direct observation — and how to translate those insights into precise EPC elements.

By the end, you’ll know how to extract business logic from informal conversations, avoid common misinterpretations, and build models that reflect real operations — not assumptions.

Why EPC Process Elicitation Is the First True Step

It’s tempting to skip the discovery phase and dive straight into diagramming. But EPC is not a diagramming exercise — it’s a logic exercise. Every function and event must reflect an actual business action or state change.

Good elicitation ensures you’re not modeling an idealized process. It’s about capturing how things actually work — even if they’re inefficient. That’s where real value lies: identifying bottlenecks, redundancies, and misaligned handoffs.

For example, I once worked with a logistics team who believed their order fulfillment process was automated. After a single EPC stakeholder interview, we discovered that three manual approvals still existed. The EPC model revealed what the system hadn’t — and led to a 40% reduction in processing time after automation.

Establish Your EPC Elicitation Framework

Begin with a simple three-part framework: observe, interview, map.

1. Observe the process as it happens. Pay attention to where delays occur, who touches the workflow, and what tools are used.
2. Interview key stakeholders — not just the process owner, but the people executing tasks.
3. Map the workflow using EPC logic, translating observations and answers into events and functions.

Use this framework consistently, and you’ll avoid the most common pitfall: creating a model that’s technically correct but operationally irrelevant.

Conducting Effective EPC Stakeholder Interviews

Interviews are where much of the depth comes from. They’re not about confirming assumptions — they’re about uncovering the unspoken.

Prep: Prepare Questions, Not Just a Script

Don’t ask “How does the process work?” That invites vague answers. Instead, ask:

• “What triggers the start of this task?”
• “What happens if the approval is delayed by more than 24 hours?”
• “Who is responsible for the next step, and how do they get notified?”
• “What tools or systems do you use to complete this?”

These questions force specificity. They uncover dependencies, handoff points, and actual responsibilities — all crucial for accurate EPC modeling.

Use the “Why?” Question Strategically

When someone says “The system sends an email,” follow up with “Why?”

That could lead to:

• “Because the manager must approve before shipment.”
• “Because the warehouse needs to verify stock availability.”
• “Because the finance team requires a purchase order number.”

Each “why” reveals a logical dependency or decision point. These are the roots of EPC events and functions.

Record and Validate

Always record interviews (with permission). Then, within 24 hours, send a summary to stakeholders for validation. Include your EPC diagram draft.

One stakeholder once corrected me: “The email isn’t a trigger — it’s a notification.” That small distinction changed the entire event chain. The real trigger was the completion of the purchase order — not the email.

Observation: See the Process in Action

Observation is the antidote to interpretation. You can’t model what you don’t see.

Go to the floor. Watch the workflow. Note:

• Who initiates the task?
• How long does each step take?
• Do people use workarounds?
• Are there handoffs between departments?

One team I worked with had a “simple” invoice approval process. Observation revealed that three people handled the same invoice — each adding notes, re-reading it, and forwarding it. There was no single ownership. This was a red flag for EPC modeling — it signaled a need for reorganization.

Best Practices for Business Workflow Capture

Follow these guidelines to improve accuracy and efficiency:

• Observe during peak times — Avoid quiet periods where the process looks streamlined but isn’t representative.
• Focus on actions, not artifacts — Don’t record “the form” — record “the form is submitted” or “the form is reviewed.”
• Document exceptions — Most processes are smooth 80% of the time. Capture the 20% where things go wrong.
• Use timestamps — Track actual durations. This helps identify bottlenecks.

From Insights to EPC Elements

Now that you’ve gathered data, it’s time to map it. The key is to distinguish clearly between events and functions.

Events: What Triggers or Marks State Changes

Events are **state changes** — they’re triggered by actions, decisions, or time. They answer: “What happened?”

Examples:

• “Purchase order approved”
• “Invoice received from supplier”
• “Customer service inquiry logged”
• “Monthly report generated”

Each event must be specific and measurable. Avoid vague terms like “done” or “processed.”

Functions: What Actions Are Taken

Functions are **executable actions** — they have a clear actor and outcome.

Examples:

• “Create purchase order in ERP system”
• “Verify invoice against PO”
• “Notify customer of shipment dispatch”
• “Archive completed order in database”

Functions should start with a verb. Avoid passive voice. “Invoice is verified” is less precise than “Verify invoice against PO.”

Mapping Workflow to EPC Logic

Use this decision tree to classify each activity:

1. Is it a **trigger** or **state change**? → Mark as an event.
2. Is it a **task or action**? → Mark as a function.
3. Does it depend on a decision? → Use an XOR or AND gateway.
4. Does it loop back? → Use a loop structure or feedback path.

This ensures you’re not just labeling — you’re modeling logic.

Common Pitfalls and How to Avoid Them

Even experienced teams fall into traps. Here are the most frequent errors in EPC process elicitation:

Pitfall	Cause	Solution
Confusing events with functions	Using vague or passive language	Start all functions with a verb; ensure events are state changes
Missing exceptions or alternate paths	Focusing only on the standard workflow	Ask stakeholder: “What happens if X fails?”
Overloading functions	Combining multiple actions into one	Break down complex tasks into atomic functions
Ignoring responsibilities	Not asking who does what	Assign each function to a role or unit

These aren’t just mistakes — they’re symptoms of poor elicitation. Address the root cause, and the model will follow.

Validating Your EPC Model

After mapping, validate the model with stakeholders. Don’t just ask “Does this look right?” Instead, ask:

• “Does this match what you do every day?”
• “Are all key decisions represented?”
• “Is every handoff clear?”
• “What would happen if the system failed here?”

Use visual diagrams. Show the flow. Walk through a real example. The goal isn’t perfection — it’s alignment.

Remember: a model is only as good as the trust behind it. If stakeholders don’t believe it, it fails.

Frequently Asked Questions

How do I start EPC process elicitation for a new business area?

Begin by identifying the process owner and key participants. Schedule observation sessions and conduct EPC stakeholder interviews using targeted questions. Focus on triggers and handoffs.

Can I use EPC process mapping for agile teams?

Absolutely. EPC mapping works well in agile environments when used to document workflow logic before automation or sprint planning. It clarifies dependencies that agile teams often overlook.

What if stakeholders disagree on a step?

Document both views. Use the EPC stakeholder interview to explore the reasons. Then, clarify with the process owner. If still unresolved, flag it in the model with a note.

How do I handle processes with no clear owner?

Trace the workflow backward from the outcome. Identify who performs the last function before completion. Often, the gap reveals a responsibility gap — a key insight for process improvement.

Should I elicit every single step in the process?

No. Focus on meaningful events and functions. Skip redundant or trivial steps. Use the “value-driven” filter: “Does this step affect the outcome?” If not, consider omitting it.

What tools help with EPC process elicitation?

Use Visual Paradigm for real-time diagramming during interviews. Use sticky notes and whiteboards for collaborative modeling. Document observations in a shared log to track discrepancies and decisions.