💻 computer science

From Business Problems to AI Solutions: Where Does Transformation Support Fail

This paper identifies a critical gap in existing methodologies for translating business problems into machine learning solutions, termed the "Analytics Translation Problem," by reviewing 18 approaches and proposing five research recommendations to establish systematic guidance for this transformation process.

Original authors: Abir Trabelsi, Imen Benzarti, Hafedh Mili, Darine Ameyed

Published 2026-04-22

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Abir Trabelsi, Imen Benzarti, Hafedh Mili, Darine Ameyed

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are the CEO of a company. You have a big, important goal: "We need to stop losing customers!" (This is your Business Problem).

You hire a team of brilliant data scientists (the AI Experts) to solve it. You hand them your goal and say, "Fix this."

The problem? You speak "Business," and they speak "Math."

You say: "Stop losing customers."
They hear: "Do we need to predict who will leave? Do we need to predict when they will leave? Do we need to find groups of similar customers? Do we need to guess why they left?"

If the data scientists guess wrong, they might build a super-smart machine that predicts exactly when a customer leaves, but your business actually needed to know which customers are unhappy so you can call them. The math is perfect, but the solution is useless.

This paper is about the missing link between your big business goal and the specific math problem the scientists need to solve. The authors call this the "Analytics Translation Problem."

The Big Discovery: The "Lost in Translation" Gap

The researchers looked at 18 different rulebooks and methods that companies use to bridge this gap. They found a shocking truth: Almost none of them actually teach you how to translate.

Think of it like this:

The Business Side is like a customer ordering a meal: "I want something spicy and healthy."
The AI Side is the chef.
The Rulebooks are the cookbooks.

The researchers found that most cookbooks are great at telling the chef:

How to chop the vegetables (Data Collection).
How to cook the steak (Building the Model).
How to plate the dish (Deployment).

But none of the cookbooks explain how to turn "I want something spicy" into "Make a Thai Green Curry with tofu."

Instead, the chef is expected to just "know" what to do based on their own gut feeling. Sometimes they get it right; often, they make a dish nobody ordered.

The 4 Types of "Cookbooks" They Reviewed

The authors grouped the 18 methods they studied into four families, like different types of chefs:

The "Requirements" Chefs (RE4AI): They are great at writing down what the customer wants (e.g., "The food must be gluten-free"). But they don't tell you how to pick the recipe.
The "Data-First" Chefs (Data-Centric): They look at the ingredients in the fridge first. "We have a lot of tomatoes, so let's make sauce!" They forget to ask if the customer actually wanted sauce.
The "Project Managers" (Process): They have a great schedule. "First we shop, then we cook, then we serve." But they don't tell you what to cook.
The "Automation" Chefs (AutoML): They are robots that can cook any recipe perfectly, but only if you tell them exactly which recipe to make. They can't decide the recipe for you.

The "S2 to S3" Cliff

The authors created a 7-step map of how a project should go. They found a massive cliff between Step 2 (Turning the business goal into a specific question) and Step 3 (Picking the math task).

Step 2: "We need to know which customers are likely to leave."
Step 3: "Therefore, we will build a Classification model."

The study found that 0% of the methods they reviewed gave strong, clear instructions on how to make that jump. It's a black box where intuition rules, and mistakes happen.

The 5 Fixes (The New Recipe)

Since the current cookbooks are broken, the authors propose 5 new rules to fix the translation process:

Don't Pick One Recipe Yet (Multi-Formulation): Don't just guess one way to solve the problem. Write down 3 or 4 different ways (e.g., "Predict who leaves," "Predict when they leave," "Find groups"). Compare them like a menu before ordering.
The "If-Then" Rulebook (Task Derivation): Create a simple cheat sheet.
- If the question is "Which group does this belong to?" → Then use Clustering.
- If the question is "What number will this be?" → Then use Regression.
- This stops people from guessing.
The "Constraint Filter" (Constraint-Algorithm Filtering): Before picking a recipe, check the rules.
- "We need the answer in 1 second." → Filter out slow, complex recipes.
- "We need to explain why the AI made a decision." → Filter out "black box" recipes.
The "Maybe" Map (Probabilistic Traceability): Don't promise perfection. Instead of saying "This will save us $1M," say "This might save us $1M, but there's a 20% chance it only saves $500k." This keeps everyone honest about the risks.
The "Oops, Let's Restart" Button (Data-Triggered Revision): In normal cooking, if you burn the toast, you just throw it away. In AI, if you find out the ingredients (data) are bad, you have to go back and change the recipe (the business question). The new rules say: "If the data looks weird, stop and rethink the whole plan immediately."

The Bottom Line

This paper argues that building AI isn't just about writing code or finding data. The hardest part is translating a human business problem into a math problem.

Right now, companies rely on "practitioner intuition" (guessing). The authors want to replace that guessing game with a clear, step-by-step translation guide. If we can fix this "translation gap," we can stop building fancy AI systems that solve the wrong problems.

In short: We need to stop asking chefs to guess the menu. We need to give them a translator who speaks both "Business" and "Math" so they can cook exactly what the customer ordered.

1. Problem Statement

The paper addresses a critical bottleneck in AI project lifecycles: the upstream translation of Business Problems (BP) into Machine Learning Solution Specifications (MLS).

The Core Issue: AI projects fail at rates twice that of conventional IT projects, often due to a misalignment between the business intent (e.g., "reduce customer churn") and the technical formulation delivered to data science teams.
The Gap: Current methodologies (Requirements Engineering, CRISP-DM, MLOps) largely treat the transition from business goals to ML tasks (e.g., classification vs. clustering) as an ad hoc process reliant on practitioner intuition.
The Specific Challenge: Unlike traditional Requirements Engineering (which refines goals into functional requirements), BP→MLS requires cross-domain derivation. It involves translating semantic business concepts (goals, constraints) into statistical and algorithmic constructs (paradigms, task types, metrics) that have no direct semantic correspondence in the original problem statement.
The Consequence: Teams often build technically sound models that fail to solve the actual business problem, or they waste significant time iterating on problem formulation before modeling begins.

2. Methodology

The authors conducted a structured narrative literature review to analyze the state of the art in BP→MLS transformation.

Corpus: 18 distinct approaches were selected from a pool of 129 initial articles. These approaches span three domains: Requirements Engineering (RE), Data Science Project Management, and Automation.
Selection Criteria: Papers had to propose a concrete methodology for transforming business needs into AI/ML specifications, provide sufficient methodological detail, and be peer-reviewed.
Analytical Framework:
- Taxonomy: Approaches were classified into four families based on methodological orientation.
- Artifact Analysis: Inputs (Problem Space) and Outputs (Solution Space) were categorized into six distinct artifact types each.
- Stage Coverage: A 7-stage transformation framework was defined to assess how well each approach supports the process:
  1. S1: Problem Framing (Goals, stakeholders).
  2. S2: Decision/Question Formulation.
  3. S3: ML Task Formulation (The critical translation point).
  4. S4: Data Requirements.
  5. S5: Constraints Integration (NFRs, ethics).
  6. S6: Evaluation Criteria.
  7. S7: Deployment Assumptions.
Reliability: Inter-rater reliability was assessed (Cohen's $\kappa = 0.83$ ), indicating excellent agreement on the classification and coverage ratings.

3. Key Contributions

A. Taxonomy of Transformation Approaches

The paper organizes the 18 reviewed approaches into four families:

RE4AI (Requirements Engineering for AI): Focuses on organizing AI-specific requirements (e.g., GR4ML, RE4HCAI). Limitation: Lacks mechanisms to derive ML tasks from business goals.
Data-Centric RE: Prioritizes data requirements as the bridge (e.g., Extended AMDiRE). Limitation: Often assumes the task is known and focuses on data specification.
Project Management Processes: Lifecycle models like CRISP-DM and CRISP-ML. Limitation: Defines when activities occur but not how to execute the decision logic for task selection.
Automation-Oriented: Tools for algorithm selection (e.g., SmartML, MLOps). Limitation: Assumes the ML task is already fixed; they optimize within a task but do not determine the task itself.

B. The Analytics Translation Problem (ATP)

The authors define the Analytics Translation Problem (ATP) as the absence of explicit, traceable, and operationalizable mappings between business characterizations and ML formulations.

Input Space: Strategic Objectives (O), Constraints (C), Data Availability (D), User Requirements (R).
Output Space: ML Paradigm (P), Task Type (T), Algorithm Constraints (A), Evaluation Criteria (E).
The Gap: No existing approach provides a function $f_{ATP}$ that systematically maps $(O, C, D, R) \rightarrow (P, T, A, E)$ .

C. Five Research Recommendations (R1–R5)

To address the ATP, the paper proposes a research agenda for future frameworks:

R1: Support Multi-Formulation Exploration: Move away from linear refinement. Frameworks should maintain parallel alternative formulations (e.g., classification vs. regression) with structured comparison criteria (data needs, feasibility, cost).
R2: Provide Task Derivation Guidance: Establish explicit rules linking question types to task types (e.g., "Which category?" $\rightarrow$ Classification) and data characteristics to task feasibility (e.g., "No labels" $\rightarrow$ Exclude supervised tasks).
R3: Enable Constraint-Algorithm Filtering: Use eliminative reasoning where constraints (e.g., latency <100ms, fairness) actively filter out incompatible algorithm families before selection, rather than post-hoc verification.
R4: Implement Probabilistic Traceability: Replace binary traceability with probabilistic annotations. Link business goals to expected performance ranges (e.g., "Goal: Reduce fraud by 20%" $\rightarrow$ "Expected: 12–25% reduction, confidence: medium") to manage uncertainty.
R5: Define Data-Triggered Revision Paths: Create explicit triggers where empirical data findings (e.g., label scarcity, weak signal) mandate revisiting upstream decisions (R1, R2, or R3), treating iteration as a feature rather than a failure.

4. Key Results

Systemic Failure at S3: The analysis revealed a "discontinuity" at Stage 3 (ML Task Formulation). While 28% of approaches strongly cover S1 (Problem Framing), 0% provide strong guidance for S3. Only 4 out of 18 approaches offer partial support, and none provide systematic derivation rules.
Fragmented Support:
- RE4AI approaches are strong on S1 and S4 but weak on S3.
- Project Management approaches define the process flow but lack the "how-to" logic for decision making.
- Automation approaches start only after the formulation is complete.
Input/Output Mismatch: While 94% of approaches model Data Requirements (Output), only 50% model Stakeholder Specifications (Input) explicitly. Furthermore, 83% list Algorithm/Task Specification as an output, but few explain the derivation process.
Validation Gap: Most approaches rely on academic case studies or expert interviews; very few have been validated in real-world industrial settings, and those that have (e.g., GR4ML) still report that the business-to-analytics transition remains underspecified.

5. Significance and Implications

For Research: The paper reframes the BP→MLS transition as a distinct Requirements Engineering problem requiring cross-domain refinement. It establishes a conceptual foundation (the ATP) and a 7-stage framework to guide future tool development.
For Practice: It argues that ML task formulation must be treated as an explicit requirements activity, not an implicit data science decision. Practitioners are urged to use the identified artifact categories as a checklist to avoid blind spots and to adopt iterative, data-triggered revision paths.
For AI Tooling: As organizations integrate Generative AI assistants, formalizing the ATP is a prerequisite. Current AI tools cannot effectively assist in this translation because the mapping logic (the "function") does not yet exist in a structured, traceable form.

In conclusion, the paper identifies that while the components of a solution (goal decomposition, constraint taxonomies, quality checkpoints) exist in scattered literature, they have not been assembled into a cohesive pipeline. The proposed recommendations (R1–R5) outline the necessary steps to move AI project translation from practitioner intuition to principled, traceable engineering.