Problem structuring refers to the process of organizing complex or ambiguous problems and clarifying their components and relationships so that investigation, analysis, decision-making, and problem-solving can proceed more effectively. It encompasses a variety of approaches, including breaking problems into smaller elements, visualizing business processes, organizing possible causes and effects, and translating objectives into measurable indicators.
For example, suppose a company faces the problem of stagnant sales. One approach is to break sales down into customer numbers, purchase frequency, and average transaction value. Another is to examine the sales process from initial inquiry to purchase and investigate where potential customers are lost.
However, defining the problem as “increasing sales” may not be appropriate in the first place. The more important issue might be low profitability or excessive dependence on existing customers.
Problem structuring therefore involves more than decomposing a given problem. It also requires examining what should be considered the problem, where its boundaries should be drawn, and which relationships deserve attention.
Is Problem Structuring a Single Thinking Method?
Problem structuring is not one specific technique. It is a broad concept encompassing multiple methods.
In business practice, Logic Trees, Issue Trees, KPI Trees, and Process Maps are commonly used to break down problems hierarchically or visualize relationships between their components.
Meanwhile, operations research (OR) and management science have developed a specialized field known as Problem Structuring Methods (PSMs). This field focuses particularly on complex situations in which stakeholders have different perceptions, objectives, or interests, and where the definition of the problem itself requires examination.
These two usages are related but do not refer to exactly the same range of activities.
For practical purposes, problem structuring can be understood through four major activities.
| Activity | Main Question | Representative Methods |
|---|---|---|
| Reframing the problem | What is actually the problem? | Problem Definition, Reframing, Soft Systems Methodology |
| Decomposing the problem | What elements make up the problem? | Logic Trees, Issue Trees |
| Identifying relationships | How are the elements connected? | Process Maps, Cause-and-Effect Diagrams, Causal Loop Diagrams |
| Making problems measurable and testable | What should be measured, and where should improvements be made? | KPI Trees, Statistical Analysis, Design of Experiments |
In actual problem-solving, these activities are often performed iteratively rather than in a fixed sequence.
1. Logic Trees — Breaking Problems Down Hierarchically
A Logic Tree is a method for decomposing a problem or subject into smaller components and organizing them hierarchically.
For example, stagnant sales can be examined by dividing total sales into the number of transactions and average transaction value. The number of transactions can then be examined in relation to the number of purchasing customers and their purchase frequency.
Logic Trees can be used in several ways depending on the analytical objective.
What Trees (Decomposition Trees) organize the components of a subject. For example, manufacturing costs can be divided into material costs, labor costs, equipment costs, and other categories.
Why Trees (Cause Trees) organize possible explanations for a problem. For example, delivery delays might be investigated in terms of procurement difficulties, insufficient production capacity, or scheduling problems.
How Trees (Solution Trees) organize potential means of achieving an objective. For example, shortening delivery times might involve improving production processes, revising inventory management, or standardizing product designs.
MECE and Its Limitations
Logic Trees are often associated with the principle of MECE: Mutually Exclusive, Collectively Exhaustive.
This means that categories should not overlap and should collectively cover the entire subject.
For example, customers might be divided into domestic and international customers. If geographic definitions are sufficiently clear, the categories can be constructed without overlap.
However, achieving perfect MECE classification is not always possible when analyzing the causes of problems.
For example, delivery delays may involve interactions between equipment conditions and production scheduling. Assigning each cause to only one category may conceal important relationships.
Furthermore, organizing all the factors currently known to the analyst does not guarantee that all relevant factors have been identified.
A Logic Tree is useful for organizing problems, but the resulting hierarchy should not automatically be treated as a complete representation of reality.
2. Issue Trees — Organizing the Questions That Need Answers
An Issue Tree is a method for breaking a problem into questions or issues that must be addressed before a conclusion can be reached.
For example, when considering whether to enter a new market, a company might examine the following questions:
- Is there sufficient market demand?
- What unmet customer needs exist?
- How can the company differentiate itself from established competitors?
- Does the company possess the necessary technological and organizational capabilities?
- What revenues, costs, and investments can reasonably be expected?
Each question can then be divided into more specific issues requiring investigation.
Logic Trees and Issue Trees are not always strictly distinguished in business practice, and the terms are sometimes used interchangeably.
However, an Issue Tree places particular emphasis on identifying the questions that must be answered, rather than simply dividing a subject into components.
What If the Original Question Is Wrong?
When constructing an Issue Tree, it is important to examine whether the highest-level question is appropriate.
For example, before asking “Should we enter a new market?”, the company might need to consider whether expanding the applications of existing products would be preferable to developing entirely new products.
If the original question is poorly formulated, even a detailed and logically organized Issue Tree may exclude important alternatives.
An Issue Tree can therefore be used not only to organize questions but also to reconsider the questions themselves.
3. KPI Trees — Translating Objectives into Measurable Indicators
A KPI Tree organizes a high-level objective, such as sales, profit, or productivity, into related lower-level performance indicators.
For example, in a business where revenue is generated through individual transactions, sales over a defined period can be represented as:
Revenue = Number of Transactions × Average Transaction Value
The number of transactions can be further decomposed:
Number of Transactions = Number of Purchasing Customers × Average Purchases per Customer
These relationships allow analysts to investigate whether changes in revenue are primarily associated with customer numbers, purchasing frequency, or transaction value.
An important advantage of KPI Trees is that they connect high-level objectives to measurable operational indicators.
However, not all KPI relationships can be represented through simple multiplication or addition.
For example, the proposition that higher employee satisfaction leads to increased productivity is not a mathematical identity. It is a causal hypothesis that requires investigation.
Distinguishing Mathematical Relationships from Causal Relationships
When constructing KPI Trees, it is useful to distinguish two types of relationships.
The first consists of definitional or mathematical relationships, such as revenue being calculated from transaction count and average transaction value.
The second consists of hypothesized causal relationships, such as increased advertising investment leading to more customers or employee training improving productivity.
Mathematical relationships can be verified through their definitions and calculations.
Causal relationships require empirical evidence, appropriate comparisons, or experiments.
Creating a KPI Tree does not establish which intervention will produce the desired improvement.
It is also important to examine whether the selected KPIs genuinely represent the intended objective.
For example, reducing the number of customer support inquiries might appear to indicate improved service. However, if customers simply stop contacting support because obtaining assistance has become too difficult, the lower inquiry count would not represent a genuine improvement.
4. Process Maps — Visualizing Workflows and Business Operations
A Process Map represents the sequence of activities, decisions, and information transfers within a business or operational process.
Flowcharts are among the most familiar forms of process mapping.
For example, an order fulfillment process might be represented as:
Customer Order → Order Verification → Inventory Check → Production or Shipping Instructions → Delivery
Actual processes are usually more complicated.
They may include procurement when inventory is insufficient, clarification of product specifications, repeated approvals, information transfers between departments, and various exceptional procedures.
Visualizing these activities makes it easier to identify where work is delayed, where rework occurs, and where unnecessary steps may exist.
Process Maps can represent not only the sequence of activities but also the responsible departments, required information, processing times, and waiting times.
As-Is and To-Be Processes
Business process improvement often distinguishes between an As-Is model representing current operations and a To-Be model representing the desired future process.
For example, an existing process may require several approvals for every customer order.
An improved process might simplify the approval procedure for orders meeting predefined conditions.
However, interviewing employees about current procedures may not provide a complete picture of how work actually takes place.
Exceptional cases, informal workarounds, and undocumented decisions may not appear in official procedure manuals.
Therefore, direct observation and operational records can be important for verifying actual processes.
The Relationship with Process Mining
When event logs are available from information systems, Process Mining can be used to investigate actual execution patterns.
While conventional Process Maps are often created from interviews, observation, and documented procedures, Process Mining analyzes recorded events to reconstruct workflows and examine their frequency and variation.
However, Process Mining cannot automatically reveal activities or judgments that are absent from the event logs.
Combining field observations, Process Maps, and event-log analysis may provide a more complete understanding of operational structures.
5. Structuring Causes and Interactions
Logic Trees and KPI Trees are particularly useful for representing hierarchical structures.
However, real-world problems often involve relationships that cannot be adequately represented as simple hierarchies.
For example, a manufacturing defect rate may be influenced by equipment conditions, operating procedures, materials, and environmental factors.
These factors may also interact with one another.
Cause-and-Effect Diagrams systematically organize possible causes associated with an observed outcome. They help analysts consider a range of factors, but the relationships shown in the diagram must still be verified.
Causal Loop Diagrams represent feedback relationships among multiple variables. For example, increased equipment failures may create more emergency maintenance work, leaving less time for preventive maintenance and potentially leading to further failures.
Concept Maps can represent many different relationships, including causation, dependency, classification, objectives, and constraints.
These methods are useful when a problem must be understood as a network of interconnected elements rather than a simple hierarchy.
However, producing a complicated diagram does not necessarily contribute to problem-solving.
The types of relationships should be identified clearly, and analysts should distinguish observed facts from unverified hypotheses.
Comparing Representative Problem Structuring Methods
| Method | Structure Represented | Typical Output | Main Limitation |
|---|---|---|---|
| Logic Tree | Hierarchy and decomposition | Lists of components, possible causes, or solutions | Missing factors and overlooked interactions |
| Issue Tree | Hierarchy of questions | Issues requiring investigation and decisions | The original question may be inappropriate |
| KPI Tree | Hierarchy and relationships among indicators | Performance indicators and potential improvement areas | Confusion between mathematical relationships and causal hypotheses |
| Process Map | Sequences, branches, and workflows | Process steps, delays, and rework points | Informal or undocumented operations may be missed |
| Cause-and-Effect Diagram | Outcomes and possible causes | Organized causal hypotheses | Causal relationships require verification |
| Causal Loop Diagram | Interactions and feedback | Hypothesized feedback structures | Quantitative effects cannot be determined from the diagram alone |
| Concept Map | Various relationships among concepts | Conceptual structure of a problem | The correctness of relationships is not automatically established |
| SSM, SODA, and Related Methods | Perceptions, objectives, and stakeholder perspectives | Reframed problems and possible courses of action | Depend on participation and interpretation |
The important task is not to determine which method is universally superior.
The choice should depend on what aspect of the problem needs to be structured.
Reconsidering the Problem Definition — Problem Structuring Methods
Many of the techniques introduced above can be applied when the problem is already defined to some extent.
However, the initial definition of the problem may itself be inappropriate.
Suppose a company wants to improve the efficiency of its sales operations.
A detailed Process Map might reveal opportunities to reduce time spent preparing quotations or processing customer inquiries.
These improvements could be valuable.
However, if the fundamental problem is that the company is selling products customers do not actually need, making the sales process more efficient will not necessarily solve it.
In such cases, the problem definition itself must be reconsidered.
Operations research and management science have developed Problem Structuring Methods (PSMs) for addressing complex and ambiguous situations of this kind.
Representative approaches include Soft Systems Methodology (SSM), Strategic Options Development and Analysis (SODA), and the Strategic Choice Approach (SCA).
Soft Systems Methodology, developed by Peter Checkland and others, examines problem situations while considering differences in stakeholders’ perspectives, purposes, and worldviews.
SODA, developed by Colin Eden and colleagues, uses techniques such as Cognitive Mapping to represent stakeholders’ perceptions and examine relationships among issues, objectives, and possible actions.
SCA, associated with John Friend and colleagues, organizes interconnected decisions, alternatives, and uncertainties to support the development of practical courses of action.
These approaches do not assume that there is always a single, objectively correct problem definition available at the outset.
Instead, they emphasize developing a better understanding of the situation by examining different perspectives.
The specialized field of PSMs can therefore be distinguished from the more general business practice of organizing problems using Logic Trees and similar techniques.
Nevertheless, the two perspectives can be combined in practical applications.
Practical Example — Difficulty Finding New R&D Themes
Suppose the R&D department of a company faces the problem:
“We cannot find promising new research and development themes.”
How might different problem structuring methods help investigate this situation?
Using an Issue Tree to Clarify the Questions
The first task is to determine what is actually lacking.
Are there too few candidate research themes?
Are many themes proposed, but few satisfy the evaluation criteria?
Are themes approved but subsequently abandoned before practical application or commercialization?
These are different problems requiring different investigations.
Using a KPI Tree to Understand the Results Quantitatively
The company might organize indicators such as the number of proposed themes, approval rate, development continuation rate, and commercialization rate.
For example, if the number of proposals is sufficiently high but the approval rate is low, generating more ideas may not be the most appropriate response.
However, the KPI data alone cannot explain why the approval rate is low.
The evaluation criteria might be excessively restrictive, the proposals might lack quality, or the available development budget might be insufficient.
Further investigation is necessary.
Using a Process Map to Examine How Research Themes Are Developed
The company can visualize the process from collecting technological information through theme proposal, evaluation, approval, prototyping, and decisions about continued development.
This can reveal which stages require substantial time, where candidates are rejected, and what kinds of judgments are made.
For example, the evaluation of proposed themes by business divisions may repeatedly be delayed because the criteria for evaluating commercial potential are unclear.
Reconsidering the Problem Definition
The company can also reconsider the assumption that insufficient technological information is the main problem.
Perhaps theme exploration is restricted to established areas of technological expertise.
Alternatively, promising technologies may already have been identified, but the organization may lack methods for evaluating their relationship to future markets and customer needs.
In such cases, increasing the volume of collected information may not solve the underlying problem.
The company might instead consider exploring technologies from other industries, investigating new applications for existing technological capabilities, or beginning with customer problems and searching for technologies that could address them.
By combining different problem structuring methods, the company can move beyond decomposing the original problem and consider whether the problem itself needs to be redefined.
Problem Structuring and the Integration of Qualitative and Quantitative Analysis
Problem structuring also provides opportunities to connect qualitative and quantitative approaches.
For example, using a Logic Tree to organize the components of a problem is primarily a qualitative activity.
However, when measurable indicators are associated with those components, the analysis can become quantitative.
A KPI Tree systematically organizes numerical indicators, but selecting the appropriate indicators requires a qualitative understanding of business objectives and customer value.
After constructing a Process Map, analysts can measure actual processing times, waiting times, and rework frequency to identify bottlenecks quantitatively.
Conversely, unexpected relationships discovered through statistical analysis may indicate that the original problem structure needs to be reconsidered.
Problem structuring is therefore not necessarily an activity performed only once at the beginning of an investigation.
Understanding may develop through a repeated cycle:
Problem Structuring → Measurement and Analysis → New Findings → Revision of the Problem Structure
This movement between qualitative interpretation and quantitative analysis can help reveal aspects of a problem that would remain hidden through either approach alone.
Limitations of Problem Structuring
Problem structuring is valuable for understanding complex situations, but producing diagrams or hierarchical representations does not guarantee that a problem has been solved.
First, classifications and decompositions depend on what the analyst considers important.
Even a well-organized Logic Tree may exclude factors that were not considered during its construction.
Second, hierarchical decomposition may fail to represent interactions or feedback relationships among components.
Third, drawing a relationship in a KPI Tree or Causal Loop Diagram does not establish that the relationship is causal.
Fourth, excessive structural detail may increase the amount of information without clarifying which decisions the analysis is intended to support.
Furthermore, agreement among stakeholders about a problem definition does not necessarily mean that the definition is objectively appropriate.
The resulting structure should therefore be treated as a representation that may need revision as new evidence becomes available, rather than as a final and complete description of reality.
AI-Assisted Problem Structuring
Large language models can assist with decomposing problems expressed in natural language and organizing relationships among their components.
For example, when a user enters “Sales of our new product are not growing,” an AI system could propose possible decompositions, suggest potential causes, and generate an initial Logic Tree.
It could also support the development of KPI Trees by suggesting relevant indicators and mathematical relationships.
For Process Maps, users might describe operational procedures in natural language, allowing an AI system to organize activities, decisions, and possible branches.
AI could also apply different structuring methods to the same problem and help compare the resulting perspectives.
However, AI-generated problem structures are not necessarily correct.
An LLM can propose plausible explanations and indicators based on general business knowledge without verifying the circumstances of the specific organization.
It is therefore important to distinguish observed facts, stakeholder statements, AI-generated hypotheses, and verified relationships.
AI-assisted problem structuring should also support alternative decompositions and problem definitions rather than merely filling predefined categories.
A particularly useful capability would be to help users recognize when their initial framing may have excluded important possibilities.
Problem Structuring in ThinkNavi
ThinkNavi treats problem structuring as a collection of methods connecting problem discovery with practical problem-solving.
Rather than requiring users to select a specific method immediately, ThinkNavi aims to help them identify an appropriate approach according to what they need to understand.
For example, a Logic Tree may be useful for decomposing a problem into components, while an Issue Tree can clarify the questions requiring investigation.
A KPI Tree can help analyze changes in business performance, and a Process Map can reveal how work proceeds through an organization.
Cause-and-Effect Diagrams can organize possible causes, while Causal Loop Diagrams can help examine interactions and feedback.
When the problem definition itself requires reconsideration, concepts from Soft Systems Methodology and other Problem Structuring Methods may be useful.
Some of these methods could be implemented as manually operated tools in ThinkNavi Free.
Potential LLM-assisted functions include automatic problem decomposition, generation of alternative structures, connections between problem components and measurable indicators, and revisions of problem structures based on new analytical findings.
These are possible directions for future development and do not imply that all such functions are currently available.
The purpose of problem structuring is not necessarily to produce a polished diagram.
Nor is it merely to divide a given problem into smaller components.
How we frame a problem determines what information we investigate, which analytical methods we select, and what kinds of solutions we consider. Problem structuring is the activity of clarifying what should be treated as the problem—before attempting to solve it and throughout the problem-solving process.
Related Topics
- Logic Trees and Issue Trees — Breaking Down Problems and Identifying the Questions That Need Answers
- KPI Trees — Decomposing Performance Goals and Identifying Levers for Improvement
- Process Maps
- Cause-and-Effect Diagram (Fishbone Diagram) — Systematically Organizing Factors That May Contribute to a Problem
- Five Whys | Exploring Root Causes by Repeatedly Asking “Why?”
- The KJ Method | Building Meaningful Structures from Fragmented Information
- Concept Maps | Expressing Relations Between Concepts
- Systems Thinking | Interdependence and Change Over Time
- Causal Loop Diagrams | Understanding Feedback
- Soft Systems Methodology
- Qualitative and Quantitative Thinking — Two Perspectives on Understanding the World and Their Integration
- The Scientific Method and Falsifiability — Generating Hypotheses and Testing Them Critically
- What Is Statistics? — Discovering Patterns in Data and Understanding an Uncertain World
- Design of Experiments (DOE) — Investigating Multiple Factors and Their Interactions Through Systematic Experimentation
- Decision Matrices
- AHP | Pairwise Comparisons & Consistency
- Concept Exploration
References and Further Reading
- Jonathan Rosenhead, “What’s the Problem? An Introduction to Problem Structuring Methods,” Interfaces, 26(6), 1996, pp. 117–131.
- Jonathan Rosenhead and John Mingers (eds.), Rational Analysis for a Problematic World Revisited: Problem Structuring Methods for Complexity, Uncertainty and Conflict, 2nd ed., Wiley, 2001.
- Peter Checkland, Systems Thinking, Systems Practice, Wiley, 1981.
- Colin Eden and Fran Ackermann, Making Strategy: The Journey of Strategic Management, SAGE, 1998.
- Horst W. J. Rittel and Melvin M. Webber, “Dilemmas in a General Theory of Planning,” Policy Sciences, 4, 1973, pp. 155–169.
- American Society for Quality — Flowchart
- American Society for Quality — Process Analysis Tools
- Institute for Healthcare Improvement — Flowchart