top of page
Search

Defining The Problem

  • Writer: Niyi Ogunbiyi
    Niyi Ogunbiyi
  • Feb 8
  • 3 min read

Updated: Feb 9

In our previous discussion on diagnostic process mining, we emphasized the critical importance of causal analysis. Without identifying the true causes of problems revealed by descriptive process mining, organizations risk misallocating resources on ineffective solutions, potentially exacerbating the issues. We also introduced a six-step methodology:

  1. Define the problem

  2. Identify potential causes

  3. Validate the causes

  4. Develop appropriate solutions

  5. Validate the solutions

  6. Implement the solutions

In this post, we will delve into the first step: defining the problem.

Understanding 'Problem' in This Context

A problem, in our framework, is defined as a discrepancy between expected and actual performance. For instance, consider an online retailer that promises next-day delivery to its customers. The internal target is a 99% on-time delivery rate, but currently, only 50% of orders meet this criterion. This 49% shortfall represents the problem.

A problem is a gap between expected and actual performance
A problem is a gap between expected and actual performance

Operational problems typically fall into one of three categories:

  1. Non-timely delivery: Deliveries not meeting the promised timeframe.

  2. Defects: Outputs that fail to meet specified standards.

  3. Extended processing times: Processes taking longer than anticipated.

However, other categories of problems can also exist.


Throughout this series of blg posts, we'll reference a real-life event log from the 2017 Business Process Intelligence Challenge. This log pertains to a loan application process at a Dutch financial services company.

Our focus is on the 'offer' sub-process, which is described below:

  • An offer is created and sent to the customer.

  • The customer is subsequently contacted.

  • The offer is either accepted or declined.

The identified problem is a lower-than-expected acceptance rate of these offers.

Steps to Define the Problem

To effectively define the problem, we seek answers to the following questions:

  1. What is the actual performance?

  2. What is the expected performance?

  3. What is the impact of the problem?

  4. During which time period did the problem occur?

  5. What was your data source?

Applying the Steps

  1. Actual Performance: After analyzing the event log and filtering for cases with a single offer per application, we found an acceptance rate of 72.5%.

  2. Expected Performance: While direct input from the project owner would be ideal, in this scenario, we'll assume an expected acceptance rate of 90%. This assumption is reasonable, given that customers have initiated applications, and the company has extended offers after assessment.

  3. Impact of the Problem: Assuming that for every euro lent, the lender earns 1% interest, we can calculate the projected interest income for both accepted and declined offers. Achieving the target acceptance rate of 90% would result in approximately two-thirds of the interest income from declined offers. Therefore, missing the target equates to a lost interest income of €637,000 (two-thirds of €955,000). It's crucial to recognize that problems often have multiple impacts. For instance, delays might lead to customer complaints and churn, while quality issues could result in regulatory scrutiny or reputational damage. Documenting the full impact comprehensively is essential.

  4. Time Period: The event log timestamps range from early January 2016 to the end of January 2017.

  5. Data Source: The data is sourced from a fictitious system named XYZ.

    Problem Definition Steps Applied to Event Log Data
    Problem Definition Steps Applied to Event Log Data

Formulating the Problem Statement

A well-crafted problem statement should be:

  • Clear and concise: Ideally 2-3 sentences.

  • Quantified with metrics: Avoid vague descriptions.

  • Identifies performance gaps: Clearly states the discrepancy.

  • References a specific period and data source: Provides context.

  • Focuses on a single problem metric: Maintains clarity.

  • Includes the impact of the problem: Highlights significance.


Bringing the steps above together, we derive a problem statement that reads as follows:

"Between January 2016 and January 2017, the loan application process at [Company Name] exhibited an offer acceptance rate of 72.5%, falling short of the anticipated 90%. This 17.5% gap resulted in an estimated loss of €637,000 in potential interest income, based on a 1% interest rate per euro lent. Data was sourced from the XYZ system."


Having precisely defined our problem, the next step involves identifying the various causes and determining their contributions. We'll explore this in the next blog post. We hope you'll continue this journey with us.

 
 
 

Comments


bottom of page