UNIT 4 – BPM

PROCESS DISCOVERY

Process Discovery Overview

Process discovery involves gathering and organizing information about an
existing process to create an as-is process model. It is a broader activity than
process modeling, requiring significant effort in understanding and structuring
information before modeling can begin.

Four Tasks of Process Discovery

1. Defining the Setting:
o Assemble a dedicated team responsible for the process discovery.

o Establish a collaborative environment and clarify objectives.

2. Gathering Information:
o Build an understanding of the process by collecting data.

o Use discovery methods such as interviews, observations, or

document analysis.
3. Conducting the Modeling Task:
o Create a process model using a systematic modeling method.

o Map out the process clearly to represent activities, roles, and

interactions.
4. Assuring Process Model Quality:
o Ensure the model meets quality criteria, including accuracy,
consistency, and completeness.
o Establish trust in the process model by validating it with
stakeholders.

Iterative Approach
 After defining the setting, the other tasks (information gathering,
modeling, and quality assurance) are performed iteratively:
o Iterative refinement: Gather information, create a draft model,
and evaluate its quality before repeating the cycle to improve the
model further.
Key Takeaways
 Defining the setting is the foundation for effective process discovery.
 Iteration ensures continuous improvement and alignment of the process
model with the real-world process.
 Quality assurance builds stakeholder trust and ensures the process
model is a reliable representation of the actual process.

Process Analyst vs. Domain Expert

1. Process Analyst
 Role:
o Gathers process-related information and drives the modeling task.

o Works under the leadership of the process owner.

 Key Skills:
o Proficiency in process modeling languages (e.g., BPMN).

o Expertise in organizing and structuring process-related information.

 Limitations:
o Lacks deep, operational knowledge of specific processes.

 Responsibilities:
o Collaborates with domain experts to bridge the gap between
conceptual modeling and real-world process execution.

2. Domain Expert
 Role:
o Provides intimate, detailed knowledge of how processes or tasks are
performed.
o Often includes process participants, process owners, operational
managers, or external roles (e.g., suppliers or customers).
 Key Skills:
o Expertise in the practical execution of the process.

o A nuanced understanding of daily operations and workflows.

 Limitations:
o Typically lacks proficiency in process modeling.

o May resist engaging with technical process models due to

discomfort or lack of familiarity.
  Collaboration:
o Relies on process analysts to translate their knowledge into process
models.

Example (Illustrating Differences):

 Task 1: Modeling the process of ordering books from a customer's
perspective:
o Easily accomplished by process analysts with personal experience
as customers.
 Task 2: Modeling the process from the bookstore's perspective:
o Requires insights from domain experts (e.g., bookstore employees)
who are intimately familiar with backend operations.

Challenges and Collaboration

 Modeling Gaps:
o Process analysts must consult with domain experts to gain an
internal view of the process.
 Bridging the Skill Gap:
o Training programs can enhance domain experts' modeling abilities.

o BPM consultants with domain-specific expertise can add value to

projects.
 Process Owner's Role:
o Ensures the commitment and collaboration of both analysts and
domain experts.
o Tailors the team composition based on process complexity.

Three Process Discovery Challenges

1. Fragmented Process Knowledge
 Nature of the Challenge:
o Business processes are divided among specialized tasks and
resources, resulting in fragmented knowledge.
o No single domain expert possesses a comprehensive understanding
of the entire process.
o Domain experts often provide conflicting information or incomplete
details.
 o Process rules are often undocumented, leading to diverging
assumptions.
 Implications:
o The process analyst must collect and reconcile inputs from multiple
domain experts.
o Iterative feedback loops are essential to resolve inconsistencies and
gain consensus.
o Final approval must come from the process owner after reconciling
conflicts.

2. Thinking in Cases
 Nature of the Challenge:
o Domain experts often think in terms of specific instances or cases
rather than generalized processes.
o Responses like “every case is different” or “we never do things
exactly the same way” are common.
o Special conditions and exceptions dominate their perspective.

 Implications:
o The process analyst must abstract and systematize case-specific
knowledge into generalizable process rules.
o Effective questioning techniques are needed to uncover underlying
conditions, routing decisions, and process rules.
o Reverse-engineering processes from individual cases into structured
models is a critical skill.

3. Lack of Familiarity with Process Modeling Languages

 Nature of the Challenge:
o Domain experts typically lack training in reading or creating process
models (e.g., BPMN).
o They struggle to understand technical elements like routing
constructs and activity flows.
o Asking domain experts to review models directly often leads to
confusion or incomplete feedback.
 Implications:
o Process analysts must translate models into natural language or
simpler visual representations for feedback.
 o Domain experts are more comfortable discussing natural-language
descriptions or contextual clarifications.
o Training programs for domain experts can help improve their ability
to engage with models, but this requires time and investment.

Process Discovery Methods

1. Evidence-Based Discovery
This method relies on analyzing existing artifacts and records to understand a
process. It includes three sub-methods:
a. Document Analysis
 Description: Reviews documentation like process descriptions, policies,
organization charts, work instructions, and quality reports.
 Advantages:
o Provides a baseline understanding of the process environment.

o Helps formulate initial hypotheses before engaging domain experts.

 Challenges:
o Process Orientation: Documents are often not structured in a
process-oriented way (e.g., organization charts focus on roles, not
workflows).
o Granularity Issues: Information may be too high-level or overly
detailed for modeling purposes.
o Trustworthiness: Documents might be outdated, idealistic
(normative), or not reflective of actual operations.
 Key Use: Prepares process analysts for discussions and complements
other discovery methods.

b. Observation
 Description: Directly observes processes in action, either by:
o Active Role: Acting as a customer to trigger and track process
execution.
o Passive Role: Monitoring the process as it unfolds end-to-end.

 Advantages:
o Captures how processes operate in real-time, revealing current
practices.
o Provides insight into execution flow and milestones.
  Challenges:
o Limited visibility in active roles (e.g., backend tasks may remain
unseen).
o Passive observation requires access to sites and teams, which may
be restricted.
o The Hawthorne Effect: People may alter behavior under
observation (e.g., work faster or avoid exceptions).
 Key Use: Complements document analysis by showing how processes are
conducted in reality.

c. Automated Process Discovery

 Description: Utilizes event logs from enterprise systems to generate
process models automatically.
 Advantages:
o Objectivity: Event logs reflect actual process execution, avoiding
biases from human interpretation.
o Rich Data: Logs often include timestamps, task frequencies,
resource interactions, and performance data.
o End-to-End Visibility: Can integrate data from multiple systems to
model comprehensive workflows.
 Challenges:
o Event logs may be unavailable, incomplete, or noisy.

o The granularity of logs might result in overly detailed or low-level

models that are difficult to interpret.
 Key Use: Effective for organizations with robust logging systems,
providing detailed and accurate models.

Interview-Based Discovery
Phases of Interview-Based Discovery:
1. Initial Interviews:
o Engage domain experts involved in the process.

o Conduct interviews iteratively to address fragmented knowledge

due to specialization.
2. Process Modeling:
 o Use interview notes or recordings to create an initial process model
offline.
o Abstract individual case details into a generalized process model.

3. Model Validation:
o Validate the model with domain experts to ensure accuracy.

o Simplify technical models into natural language for better

understanding.
o Iterate interviews to refine and finalize the process model.

Interview Strategies:
 Downstream Approach: Start from process outcomes and work
backward to triggers (e.g., understanding prerequisites for fulfilling an
order).
 Upstream Approach: Start from triggers and proceed forward to
outcomes (e.g., mapping steps from receiving an order to fulfilling it).

Interview Techniques:
 Balanced Approach: Combine structured and free-form methods:
o Structured: Validate predefined hypotheses (e.g., checklist of
questions).
o Free-Form: Allow experts to share additional insights freely.

 Handling Exceptions:
o Ask "rainy-day" scenario questions to uncover exceptions or
variants (e.g., "What happens if items are out of stock?").
o Identify internal (business or technical) and external exceptions.

Strengths:
 Provides detailed insights into process execution and variations.
 Unveils inconsistencies in perceptions among different stakeholders.
 Captures both “sunny-day” and “rainy-day” scenarios.

Challenges:
1. Fragmented Knowledge:
o Process knowledge may be scattered among specialists.
 2. Case-Level Thinking:
o Experts often describe processes at an individual case level.

3. Validation Difficulty:
o Domain experts may lack familiarity with process modeling
languages.
4. Time-Intensive:
o Requires significant effort from both the analyst and the
interviewees.

Best Practices:
 Conduct interviews with multiple experts, even for the same role, to
address inconsistencies.
 Iterate interviews and validation steps as needed for complex processes.
 Encourage experts to discuss exceptions and atypical cases for a
comprehensive understanding.

Workshop-Based Discovery
Workshop-based discovery is an effective approach to understanding business
processes collaboratively with multiple stakeholders. It addresses the challenges
of fragmented knowledge and inconsistent views while ensuring a collective
understanding of the process.

Key Features and Advantages:

 1. Collaborative Approach:
o Involves multiple domain experts simultaneously.

o Enables quick resolution of inconsistencies in views among participants.

2. Facilitated Interaction:
o May include a facilitator to guide discussions and a process modeler
to document findings in real-time.
o The business analyst observes and notes unresolved issues for further
clarification.
3. Efficient Discovery Process:
o Allows for faster identification of process details compared to individual
interviews.
o Ensures diverse perspectives are captured.

4. Structured Sessions:
o Typically requires 3–5 sessions, each lasting no more than 3 hours.

o Consolidation of findings occurs between sessions.

Preparation and Organization:

1. Scheduling:
o Schedule well in advance to accommodate domain experts.

o Include representatives from all relevant roles (e.g., managers,

operational staff, technical personnel).
o Limit participants to 10–12 per session for effective discussion.

2. Setting Expectations:
o Clearly define workshop objectives, scope, and importance at the outset.

o Ensure participants understand their role and the value of their

contributions.
3. Cultural Considerations:
o Be mindful of organizational hierarchy and culture.

o Foster an open atmosphere to encourage participation and creativity.

Workshop Activities:
1. Initial Sketching:
o Begin with a participative modeling exercise using sticky notes.
 o Document tasks and events in the process sequentially without
overanalyzing details.
o Focus on maintaining consistent granularity and abstraction.

2. Validation and Iteration:

o Present the initial model (e.g., BPMN) in subsequent sessions.

o Use the model to validate and refine understanding of the process.

3. Balancing Participation:
o Ensure all voices are heard by encouraging quieter participants and
moderating dominant ones.
o Maintain a neutral and constructive environment.

Challenges and Mitigation:

1. Dominance of Hierarchical Culture:
o Exclude hierarchical influences when possible or create separate
sessions for certain roles.
2. Negative Criticism:
o Minimize negative comments to maintain a collaborative
atmosphere.
3. Diverging Opinions:
o Address differences constructively and challenge viewpoints to
reach a consensus.
4. Modeling Notation:
o Avoid overwhelming participants with complex notations; keep
focus on the discovery process.

Outcome:
 A consolidated, validated, and detailed process model reflecting collective
input from all participants.
 A shared understanding of the process across roles, enabling better
alignment and future process improvements.
Process Modeling Method
Modeling a business process during process discovery is a complex task. Thus, it
is good to follow a predefined procedure in order to approach this task in a
systematic way.
One way to do so is to work in five steps as follows:
1. Identify the process boundaries
2. Identify activities and events
3. Identify resources and their handoffs
4. Identify the control flow
5. Identify additional elements.

Process Modeling Steps

Step 1: Identify the Process Boundaries

 Objective: Define the start and end points of the process.
 Key Considerations:
 o Perspective Matters: Focus on the perspective of the party being
analyzed (e.g., seller, customer, supplier).
o Start Event: Identify the event that triggers the process (e.g.,
receipt of a purchase order from a customer).
o End Event: Determine what signals the process's completion (e.g.,
fulfillment of the order with an invoice and product delivery).
o Negative Outcomes: Include terminate end events for processes
with possible negative outcomes.
 Example: In the order-to-cash process:
o Start Event: "Purchase order received" (input object is the purchase
order).
o End Event: "Order fulfilled" (output objects are an invoice and the
delivered product).

Step 2: Identify Activities and Events

 Objective: Capture the main tasks (activities) and intermediate
occurrences (events) within the process.
 Process:
o Start with Activities: Focus on what domain experts do, even if
they aren't fully aware of the overall process.
o Add Events: Identify intermediate events (e.g., approval steps,
delays) in the process flow.
o Iterative Refinement: Start with a high-level view and add
detailed activities later.
 Example: For the order-to-cash process:
o Activities: Twelve main tasks like "Verify order" or "Ship product."

o Events: Intermediate occurrences to capture transitions or triggers.

Step 3: Identify Resources and Their Handoffs

 Objective: Assign tasks to resources and map handoff points where
responsibility shifts.
 Process:
o Define Resource Assignments: Assign each activity to a specific
resource (e.g., department, team, or individual).
o Identify Handoffs: Mark points where work moves between
resources (e.g., from sales to shipping).
 o Use Pools and Lanes:

 Pools: Represent external entities (e.g., customers, suppliers).

 Lanes: Represent internal roles or departments (e.g., finance,
logistics).
o Message Flows: Depict interactions between external parties and
internal roles.
 Insights: Handoff points are critical for identifying potential inefficiencies
or areas for refinement.
 Example: In the order-to-cash process:
o Handoff: From "Order confirmation" (sales team) to "Dispatch
goods" (logistics team).

Step 4: Identify the Control Flow

 Objective: Define the sequence and dependencies between activities and
events within the process.
 Key Aspects:
o Order Dependencies: Determine the logical flow of tasks and
events (e.g., Task A must precede Task B).
o Decision Points: Model points where choices are made:

 Use (X)OR-Splits for exclusive decisions with one outcome

path.
 Add conditions to sequence flows emerging from these splits.
o Concurrent Execution: Identify activities/events that can occur
simultaneously and connect them with AND Gateways.
o Rework and Repetition: Include loops for tasks that might need
repetition or rework.
o Event-Based Splits: Model reactions to external decisions
impacting the process.
 Example:
o In the order-to-cash process, refine handoffs (e.g., "Verify payment"
must happen before "Ship product").
o Use gateways for branching conditions, such as "Payment
received?" (yes → ship product; no → halt process).
 Outcome: A refined flow that captures dependencies and allows
stakeholders to understand process execution in detail.
Step 5: Identify Additional Elements
 Objective: Enhance the process model with supplementary details like
business objects, exception handlers, and specific annotations.
 Key Elements:
o Business Objects:

 Add data objects (e.g., "Purchase Order," "Invoice") and

data stores (e.g., databases or archives).
 Use data associations to link these objects to relevant tasks
and events.
o Exception Handlers:

 Include boundary events to manage exceptions (e.g.,

"Order cancelled").
 Define compensation handlers for corrective actions (e.g.,
"Issue refund").
 Add exception flows to depict alternative paths.
o Annotations: Provide context-specific details like:

 Risk Information: Highlight potential risks associated with

activities.
 Cost Information: Annotate activities with cost data for cost
analysis.
 Purpose-Based Modeling:
o Automation Focus: Include explicit data and exception details.

o Risk or Cost Analysis: Add annotations relevant to these scenarios.

 Example:
o For order-to-cash:

 Add a data store for "Customer Database."

 Include an exception handler for "Payment Failed."

When to Stop Modeling a Process

 Guidelines:
o Purpose-Oriented: Stop when the model meets the intended
purpose (e.g., process understanding or automation).
o Avoid Over-Detailing: Excessive detail can increase costs, delay
process improvement, and overwhelm stakeholders.
 Best Practices:
 o Focus on achieving a functional understanding of the process.

o Leave room for further detail refinement in later stages if needed.

Process Model Quality Assurance

To ensure the quality of process models, three key aspects must be considered:
syntactic, semantic, and pragmatic quality. Each of these is evaluated
through verification, validation, and certification, respectively. Here's a
breakdown of the main concepts and procedures:

Syntactic Quality and Verification

1. Definition:
o Syntactic quality ensures adherence to the rules of the modeling
language (e.g., BPMN).
o Verification checks the structural and behavioral correctness of a process
model.
2. Types of Syntactic Rules:
o Structural Rules:

 Govern the connections between model elements.

 Element-level rules:
 Activities: Must have at least one incoming and outgoing
sequence flow.
 Events:
 Start events: No incoming sequence flows.
 End events: No outgoing sequence flows.
 Intermediate events: At least one incoming and outgoing
sequence flow.
 Gateways:
 Split gateways: One incoming, at least two outgoing flows.
 Join gateways: At least two incoming, one outgoing flow.
 XOR-split gateways: Outgoing flows must have conditions.
 Flows:
 Sequence flows: Connect flow nodes within the same pool.
 Message flows: Connect activities/events in different pools.
 Data associations: Connect data objects/stores with
activities/events.
 Model-level rule:
 All flow nodes must lie on a path from a start event to an end
event.
o Behavioral Rules:

 Prevent anomalies like:

 Deadlocks: Process halts at a certain state.
 Livelocks: Endless loops in the process.
 Lack of synchronization: Multiple tokens on the same flow due to
improper joining.
 Dead activities: Activities that are never executed.
3. Examples of Anomalies:
o Deadlocks: E.g., a token stuck at an AND-join without sufficient inputs.

o Livelocks: A loop condition always evaluates to true.

o Lack of synchronization: Results in multiple tokens on the same sequence

flow.
4. Ensuring Syntactic Quality:
o Use structured models with matching gateways in block structures.

o Tools enforcing correctness by design can help avoid anomalies.

Key Practices for High-Quality Models

 Follow modeling guidelines from the start to reduce errors.
 Iteratively refine the model through domain expert feedback.
 Focus on the purpose of the model to determine the appropriate level of
detail.

Semantic Quality and Validation

Semantic quality focuses on how well a process model aligns with its real-world
business process. Unlike syntactic quality, which can be verified through formal
rules, validating semantic quality is more subjective. This is because it requires
ensuring the model accurately represents the actual business process, which is
something that can only be assessed through domain expertise and consultation
with stakeholders.
Key Aspects of Semantic Quality:
1. Validity:
o Definition: The model must accurately represent the real-world
process. All statements derived from the model should be correct
and applicable in the real world.
 o Assessment: Validity is checked by discussing the model with
domain experts. The experts verify whether the model correctly
reflects reality, pointing out discrepancies or inaccuracies.
o Example: If a process model suggests that any financial officer can
check an applicant's credit history, but in reality, only a specific
authorized officer can do so, the model is invalid.
2. Completeness:
o Definition: The model must include all relevant aspects of the real-
world process. It should not omit any essential activities,
exceptions, or alternative paths that occur during the process.
o Assessment: Completeness is harder to assess, as it involves
ensuring that all scenarios and variations of the business process
are captured. This requires the process analyst to probe different
stages of the process, asking questions about exceptional cases and
ensuring that all possibilities are covered.
o Example: A loan processing model might be incomplete if it fails to
account for exceptional paths, such as how to handle an order
cancellation. Omitting such paths would create gaps in the model’s
representation.
Validation Methods:
 Interviews or Workshops: Engaging with domain experts through
interviews or workshops allows for a detailed discussion about the model's
accuracy and completeness.
 Truthfulness by Design: Some tools automatically generate process
models based on event logs, ensuring the model is based on actual data
and thus truthfully represents the process. This method can also help
identify any missing steps or deviations from the real process.
Process Owner Approval:
 Once a process model is validated for its validity and completeness, it
typically requires approval from the process owner. This approval
signifies that the model is correct and complete from a business
perspective, and it establishes the model as the official and normative
version.
 Following the approval, the process model can be used for various
purposes, including process analysis, redesign, or archiving.
By focusing on both validity and completeness, process models can be
ensured to represent a true and comprehensive reflection of the business
process.
Pragmatic Quality and Certification
Pragmatic quality refers to the usability of a process model, focusing on how
well the model can be used and understood by its intended audience. The
challenge in assessing pragmatic quality lies in anticipating how the model will
be used in practice and ensuring it aligns with users’ needs.
Key Aspects of Pragmatic Quality:
1. Understandability:
o Definition: This aspect refers to how easily a process model can be
read and comprehended by its users.
o Importance: A model with high understandability ensures that
stakeholders, such as process owners and analysts, can interpret
the model correctly without confusion.
o Example: A model with a clear, logical structure, proper labeling,
and well-organized elements makes it easier for users to follow and
understand.
2. Maintainability:
o Definition: Maintainability refers to how easily modifications can be
applied to the process model. A model that is easy to maintain
allows users to update it as processes evolve without significant
effort.
o Example: If a model is built with a clear structure and standardized
elements, it will be easier to update or modify as the business
process changes.
3. Learning:
o Definition: This checks how effectively the model helps users
understand how the corresponding real-world business process
works.
o Importance: A well-designed model provides insights into the
process and helps users learn how things function in practice, aiding
in decision-making or process improvements.
Influencing Factors for Usability:
 Size: Larger models may become more difficult to understand and use
effectively.
 Structural Complexity: Complex models with too many interconnected
elements can be harder to maintain and comprehend.
 Graphical Layout: A clean and organized layout improves the readability
and usability of the model.
Certification of Pragmatic Quality:
Certification involves checking the pragmatic quality by investigating how well
the model performs in its intended usage. This can be done via:
 Interviews or Experiments: Direct feedback from users who will work
with the model in their roles (e.g., process owners, analysts) can help
assess its usability.
 Usability by Design: Some models are designed with usability principles
in mind, such as block-structuredness (ensuring that the model has a
clear and logical structure) to enhance understanding.
Usability Enhancements:
 Block-Structuredness: A structured model (as opposed to an
unstructured one) is easier to understand and maintain. This can be seen
in how a process model is organized into blocks, which simplifies its logical
flow. An example of block structuring is shown in Figure 5.15a
(unstructured) and Figure 5.15b (structured), where the latter avoids
crossing arcs and ensures matching splits and joins, making the model
easier to interpret.

Key Checks for Understandability and Learning:

 1. Consistency Between Visual and Logical Structure:
o The model’s layout should align with its logical structure. For
example, positioning elements consistently in a top-left to bottom-
right orientation without crossing arcs improves visual clarity and
comprehension.
o Example: In Figures 5.16a and 5.16b, the layout was adjusted to
reduce confusion by following a clear orientation, improving the
consistency between the visual and logical structure.
2. Meaningful Labels:
o Proper labeling of elements (activities, events, etc.) is essential for
clarity. Labels should follow a consistent and meaningful naming
convention. Ambiguous labels can reduce the model's
understandability.
o Example of Bad Labeling: In Figure 5.17, inconsistent labeling
styles (e.g., “Get approval for expenses” vs. “Cost planning”) lead
to confusion. Mixing verb-object and noun-based labels can create
ambiguity. Proper labels like "Expenses approved" and avoiding
ambiguous gateway labels like "Acceptable?" can improve clarity.
Best Practices for Effective Labeling:
 Action-Object Style: Use a consistent action-object (verb + business
object) style for labeling activities, such as "Get approval for expenses," to
ensure clarity.
 Object-Verb Style for Events: Use a business object + past participle
verb format (e.g., "Expenses approved") for events to maintain clarity and
consistency.
 Explicit Conditions for Gateways: Avoid vague labels like "yes" or "no"
for XOR-split gateways. Use more descriptive conditions like "Plan
acceptable" or "Plan unacceptable" to make the model's logic more
understandable.
In conclusion, pragmatic quality is about ensuring that the process model is
usable, understandable, maintainable, and effective in teaching users about the
real-world process it represents. By focusing on structural clarity, meaningful
labeling, and usability tests, a process model can achieve high pragmatic quality.

Modeling Guidelines and Conventions:

 Purpose of Guidelines and Conventions:
o Improve model consistency and standardization, especially in large
initiatives.
o Reduce dependency on individual process analysts.
 o Make models accessible to non-modeling experts (e.g., in large
organizations with multiple business lines).
 Difference Between Guidelines and Conventions:
o Guidelines: Suggested practices (e.g., how to structure a model or
label activities).
o Conventions: Mandatory rules that must be followed (e.g., size
limits, specific labeling styles).
Aspects of Modeling Guidelines and Conventions:
1. Vocabulary:
o Avoid using certain elements (e.g., event sub-processes).

2. Structure:
o Limit model size, number of hierarchical layers, or only use block-
structured models.
3. Semantics:
o Avoid ambiguous meanings of elements (e.g., using boundary
events only for business faults, not technology faults).
4. Appearance:
o Labeling styles should be consistent (e.g., verb-noun style).

o Follow a top-left to bottom-right orientation in layout.

Seven Process Modeling Guidelines (7PMG):

Modeling Tool Support:
 Tools like Apromore, ARIS, and Signavio allow for the automated
checking of predefined guidelines and custom rules.
 Automated checking for BPMN syntactic rules is more common in terms
of structural rules (e.g., ensuring block structure) rather than semantic or
appearance-related guidelines.
By following these guidelines, process models can achieve better consistency,
usability, and comprehension, leading to a more effective and error-resistant
modeling process.