The most common answer is the first one, and it is rarely right.
\nBusiness problem solving is the structured process that separates the analysis of a problem from its solution, using codified methods — PDCA, the A3 report, 8D, the 5 whys, the Ishikawa diagram — that were born in industry and can be adapted to any scale [1][2][3].
\nThe method, however, is the last thing to come into play.
\nA late quote in a professional's practice, a defect that returns every month in a department of a family business, a complaint that bounces between three offices in a hundred-person company: three different scales, the same story.
\nThey were solved in a hurry, without anyone having really found them.
\nIn Italy, according to ISTAT, the national statistics institute, nearly eight in ten companies with at least three employees have fewer than ten (78.9%, 2022 data) [10].
\nAt that size a quality department is the exception: whoever finds the problem is also the one who will have to choose how to tackle it.
\n\n\nSolving is the last of three moves: first the problem has to be found and named, then the way to tackle it has to be chosen with explicit criteria. The right method is the one that serves the move you are in.
\n
The sections that follow go through the three moves in the order in which they happen: finding the problem before it costs you, matching the method to the problem, choosing between alternatives with written criteria, and avoiding the mistakes that send you back to the start.
\nHow many of the \"solved problems\" in your company over the last year came back in a different form? If the number is high, the problem was not solved: it was moved — and the cost is measured in the business owner's time.
\nThe term \"problem solving\" is used so loosely that it often just means \"stopping to discuss a problem.\" An operational definition is needed precisely to separate the structured practice — with phases, tools and verifiable outputs — from the improvised meeting that produces good intentions and no lasting solution. The distinction matters: in 2023 the value added per employee of Italian companies with fewer than ten employees stopped at €38,800, against €42,100 for the EU-27 average, while from the 10-19 employee class upward Italian companies sit above the European average [7]. In Italy, then, the gap is concentrated in the segment where work is least organized, and part of that gap is played out on problems that keep coming back because they are never analyzed in depth.
\nOperational definition. Structured business problem solving is a phased process that includes: (1) a clear and measurable definition of the problem, (2) collecting data on the actual situation, (3) root cause analysis, (4) identifying and selecting solutions, (5) implementing on a pilot scale, (6) verifying the effect, (7) standardizing if the solution works. It is the discipline of \"not jumping to conclusions\" applied to operational problems [1][2].
\nClearing up four terms that get confused.
\nProblem solving vs decision making. Problem solving analyzes a problem until its causes are defined; decision making chooses between alternatives that are already defined. The first comes before the second. People often think that \"solving a problem\" is the same as \"making a decision.\" In reality, the decision comes at the end of the problem-solving process — not at the beginning.
\nProblem solving vs root cause analysis (RCA). Problem solving is the whole process (definition → analysis → solution → verification); root cause analysis is one phase of that process (the analysis of causes). The two are often used as synonyms, but RCA without the subsequent phases leaves the problem unsolved: you know the cause, but you don't know what to do.
\nProblem solving vs brainstorming. Problem solving is a structured process with phases and tools; brainstorming is a creative technique for generating ideas freely. When someone says \"let's do some problem solving,\" they almost always mean \"let's brainstorm\" — skipping the analysis of causes. Brainstorming is a tool within problem solving, not problem solving itself.
\nProblem solving vs troubleshooting. Problem solving applies to organizational and process problems (how and why we work); troubleshooting applies to technical malfunctions (why this machine isn't working). They use similar analytical logic (troubleshooting uses the 5 whys too), but they cover different ground.
\nFor the broader organizational framework in which problem solving fits as a systemic skill, the pillar article on business systemization provides the overall reference.
\nWho in your company is responsible for noticing that a problem exists before a customer points it out?
\nISO 9001:2015 requires organizations to identify risks before they produce undesired effects [8], but in many companies the real answer is \"the business owner, when they walk through the shop floor\" — a method that works as long as the business owner walks through the shop floor.
\nWithout a way to find problems, a company receives them: from the customer who complains, the supplier who chases, the team member who resigns.
\nProblem finding is the move that comes before any method and that, in practice, rarely has anyone in charge of it.
\nThis section distinguishes finding, framing and solving a problem, shows how to read weak signals before they turn into complaints, and introduces gap analysis as a measure of the distance between how work is done and how it should be done.
\nThose three channels deliver the problem when it is already expensive, after months of signals that had no one to receive them.
\nUntil then, the only sensor is the round of a business owner who splits their time between the desk and the shop floor.
\nEveryday language confuses three moves: problem finding is noticing that a problem exists before it shows up as damage; problem setting is giving it shape — scope, measure, who suffers from it — before analyzing it; problem solving is the structured process that follows.
\nThe sequence does not reverse: find, frame, solve.
\nThe Treccani dictionary traces the word \"problem\" back to the Greek próblēma, from a verb meaning \"to put forward, to propose\" [11]: a problem exists when someone puts it forward, and problem finding is the act of putting it forward.
\nWeak signals are small, repeated anomalies below the complaint threshold: the level at which clause 6.1 of ISO 9001:2015 asks organizations to act [8].
\nIn a fifteen-person family business they have familiar faces to the people on the shop floor, not to those who read the reports at the end of the month: the long-serving team member who redoes a check by hand \"just to be safe,\" the same excuse on two deliveries in a row, a customer who stops asking for quotes without complaining.
\nThree channels are enough to collect them: a standing question during the round of the shop floor (\"what had to be redone this week?\"), a one-line log (date, what, who noticed it), and a monthly review to see what keeps repeating.
\nWhen a signal repeats, gap analysis measures the distance between how work is done (as-is) and how it should be done (to-be): orders fulfilled in five days against the three promised are a two-day gap, and the problem is framed, not yet analyzed.
\nThe boundary, in one sentence: problem finding notices that the problem is there, gap analysis measures how big it is, root cause analysis digs into why it is there.
\nIn common business usage, an assessment evaluates people (selection, assessment centers) or risks (risk assessment); an organizational diagnosis examines the way work is done, and problem finding is its first step.
\nThe complementary point of view, which starts from the real disorder of problems, is in the editorial on how to bring order to business problems.
\nThe answer to the opening question is a name and a channel: those who work in the process collect the signals, those who lead review them.
\nOnce found and named, a problem still has to earn its analysis: not every problem deserves one.
\nHow many problems come up every week — and how many really deserve a cause analysis? Treating every anomaly as a problem to analyze paralyzes the company; ignoring too many dooms it to repeat them.
\nNot every problem that comes up in a company deserves a structured analysis: some are symptoms of a bigger problem, others are isolated events that will not happen again. The difference between companies that use problem solving well and those that use it badly lies not in the tool but in the entry filter: what goes into the process and what doesn't. A study of 317 manufacturing plants in about ten countries (Bortolotti et al., 2015 [6]) shows that implementations of structured methods succeed above all where there is a widespread practice of selecting the problems to focus on. Rother [4] describes this selection as part of the \"kata\" — the repeatable habit, not the exceptional event.
\nThe four selection criteria (problem triage).
\nRecurrence. Has the problem occurred more than twice in the last three months? Recurrence is the most reliable signal that there is a structural cause, not an isolated event. A problem that occurs only once can be handled with a direct response; one that keeps coming back deserves analysis.
\nEconomic or quality impact. Does the problem have a measurable cost (in time, in yield, in quality as perceived by the customer)? If the impact cannot be quantified even roughly, the priority of the analysis is low.
\nRisk of spreading. If left unsolved, does the problem tend to spread to other processes or other customers? An error that stays contained and does not spread has a different priority from one that can contaminate the entire chain.
\nCost of not acting. Is the cost of tolerating the problem for another quarter higher than the cost of the analysis? This question is often the most illuminating: in many cases the problem is tolerated because it \"costs less\" to fix it as you go — but that calculation does not include the cost of it coming back.
\nThe three operational questions to ask when facing a problem.
\nIf the answers point to recurrence + impact + spreading, the problem enters the structured process. Otherwise it is handled with a direct response and kept under observation.
\nWhen there are many candidates and the filter is not enough to put them in order, ranking by weight is done with the Pareto chart, which arranges the categories already counted and shows which few items make up most of the total.
\nRead next: how to write a problem statement, the line the selected problem must have before it enters analysis.
\nPDCA, A3 or 8D: which method is right for the problem on your desk today? Choosing wrong does not mean \"any of them will do\": using 8D for a small recurring defect is a waste; using PDCA for a product recall is negligence.
\nThree different methods, three different logics, three situations in which each works best: PDCA (Plan-Do-Check-Act, codified by W. E. Deming in the 1950s) for the iterative improvement of processes that already exist; the A3 report (Toyota, 1960s) for problems that require condensed communication and visual sharing; the 8 disciplines (8D) introduced by Ford in 1987 for serious problems that require immediate containment before the analysis of causes [3][5][9]. Choosing the method is not a matter of ideology: it depends on the severity of the problem, the time available and the number of people involved. The ISO 9001:2015 standard [8] also requires, in clause 10.2, a formal process of cause analysis and corrective action — so for certified organizations, choosing a structured method is not optional.
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n| Method | When to use it | Typical output | Average time to apply |
|---|---|---|---|
| PDCA | Iterative improvement of an existing process; recurring problems of medium impact | Action plan with a monthly verification cycle | 2-4 weeks per cycle |
| A3 report | Problems that require shared analysis and cross-functional communication | A single A3 sheet with problem, analysis, solution, verification | 1-3 weeks |
| 8D | Serious problems with an impact on customers or safety; they require immediate containment | 8D report with containment action + cause analysis + corrective action | 2-8 weeks |
scroll the table →
\nPDCA in practice in a small organization. Applied to a recurring process (e.g., handling customer complaints), PDCA starts by defining a measurable goal (Plan), launches a change on a small scale (Do), checks the result on a set date (Check) and adopts or discards the change (Act). The cycle lasts 2-4 weeks for simple problems; it can extend to 2-3 months for more complex process problems.
\nA3 in practice in a small organization. The A3 report is a single sheet structured in 8 sections: background, current situation, goal, cause analysis, countermeasures, implementation plan, verification of results, standardization [3][5]. The strength of the A3 is forced synthesis: if you can't describe the problem on one page, the problem has not yet been understood well enough to solve it.
\n8D in practice in a small organization. The 8 disciplines follow a sequence: forming the team, describing the problem, immediate containment, root cause analysis, choosing corrective actions, implementation, verifying effectiveness, recognizing the team [9]. Immediate containment (discipline 3) is the critical phase that sets 8D apart from the other methods: the damage is stopped before the cause is even understood. For business process mapping, which is the foundation on which to apply these methods, the dedicated cluster is the starting point.
\nHow many times has the \"obvious solution\" turned out to fix the symptom and not the cause? Asking \"why?\" five times in a row is not a school exercise: it is what separates a fix that lasts from one that resurfaces six months later.
\nWhen facing a problem, the most common reflex is to propose a solution right away — usually the one that worked last time in a seemingly similar situation. The 5 whys (formalized by Taiichi Ohno at Toyota and described by Masaaki Imai [1]) and the Ishikawa diagram (developed by Kaoru Ishikawa at the Kawasaki shipyard in 1943, codified in [2]) are two techniques designed to prevent this short circuit: they force the team to stop and question the cause down to a level where the solution becomes different from the initial one. They are analysis tools within the PDCA or A3 phases, not alternatives to the process.
\nThe 5 whys — an example from a service business.
\nProblem: \"The customer received the quote 3 days later than the agreed deadline.\"
\nRoot cause identified: no procedure for urgent quotes with a quick cost update. The solution is not \"pay attention to deadlines\": it is to create the missing procedure.
\nThe Ishikawa diagram (fishbone).\nThe fishbone is a structured brainstorming tool for collecting the possible causes of a problem into categories. The 6 classic categories (6M) are: Manpower (people), Methods (processes), Materials (inputs), Machines (equipment), Measurements (data), Milieu/Environment (context). In an analysis meeting of 30-45 minutes, the team lists the possible causes for each category, then ranks them by probability and impact to select the ones to dig into with the 5 whys.
\nIn practical use in a service business, the 6M are adapted: \"Machines\" becomes \"Tools/Software,\" \"Materials\" becomes \"Inputs/Data.\" The structure remains valid because it forces the team to explore different categories of cause instead of converging immediately on the first plausible hypothesis.
\nWhen was the last problem tackled with a method chosen on purpose, and not with the one used the time before?
\nIn many companies the method is not chosen: it is inherited.
\nA study of 317 manufacturing plants [6] indicates that what makes the difference is the practices with which methods are used, not the tools themselves — and an inherited method answers a problem that no longer exists.
\nPDCA, the A3 report and 8D are complete processes; the 5 whys and the Ishikawa diagram are analysis techniques that live inside those processes; root cause analysis is the family that groups them.
\nPutting them in the same table is not meant to crown the best one, but to read across three columns — when to use it, what it produces, how long it takes — which one answers the problem in front of you.
\nThe section closes with DMAIC, the more formal relative, and with the selection matrix that makes the choice repeatable.
\n\n\nThe method is chosen by move and by problem, not by habit.
\n
Compared with the three-row table above, this one adds the Ishikawa diagram, the 5 whys and root cause analysis.
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n| Method | When to use it | Typical output | Average time to apply |
|---|---|---|---|
| PDCA (Plan-Do-Check-Act) | Iterative improvement of a process that already exists; recurring problems of medium impact, confined to one function; it is the cycle that continuous improvement hosts on a permanent basis [1] | Action plan with a measurable goal, a pilot and a verification date; updated standard if the change holds | 2-4 weeks per cycle (2-3 months for complex processes) |
| A3 report | Problems that cut across several functions, requiring shared analysis and condensed communication to decision-makers [5] | A single A3 sheet: problem, current situation, goal, causes, countermeasures, plan, verification, standardization | 1-3 weeks |
| 8D (8 disciplines) | Serious problems with an impact on customers or safety; immediate containment comes before analysis [9] | 8D report with containment action, root cause, verified corrective action and team closure | 2-8 weeks |
| Ishikawa diagram (analysis technique) | In the analysis phase of PDCA, A3 or 8D, when the possible causes are many, disordered and seen by different people [2] | Map of causes by category (6M adapted to small organizations), with the 2-3 causes to dig into | 30-45 minutes of meeting, plus checking the data |
| 5 whys (analysis technique) | In the analysis phase, when the problem is well bounded, the causal chain is linear and the data are at hand [1] | Root cause written in one sentence and a targeted action on the cause, not the symptom | 20-60 minutes per problem |
| Root cause analysis (family of techniques) | When you choose to dig down to the cause instead of just containing; it groups the 5 whys, Ishikawa and the other cause analysis techniques | Documented and verified root cause, the basis of the corrective action required by ISO 9001 (clause 10.2) [8] | Varies with the technique chosen: from one hour to a few weeks |
scroll the table →
\nDMAIC (Define, Measure, Analyze, Improve, Control) is the Six Sigma cycle: a PDCA with an additional formal measurement phase, suited to processes with lots of data and variability to reduce; for a company with fewer than 50 employees it is rarely the first choice.
\nThe table is read in three moves: an impact on customers or safety leads to 8D regardless.
\nWithout it, scope decides: several functions involved lead to the A3 report, a single one to PDCA.
\nWithin the chosen process, Ishikawa when the causes are many and disordered, the 5 whys when the chain is linear.
\nIn a fifteen-person family business, the rule changes habits: a defect that returns every month on the shop floor is a case for PDCA, the cycle of continuous improvement, not for 8D; a complaint that involves customer safety calls for 8D even if the company is small.
\nThe fill-in version of the table is the Problem-Solving Method Selection Matrix: the same six rows, and the three variables — severity, time, people involved — on which the choice is marked.
\nTo the opening question the table gives a verifiable answer — the method is chosen on purpose when you can say which row pointed to it — and leaves open the step common to every method: deciding what to do, and actually doing it.
\nCan a solution that is decided but not implemented do more damage than a problem that is recognized and tolerated? It can — because it creates the illusion that the problem has been handled, while the effect keeps spreading.
\nCause analysis, even when done well, solves nothing if the solution is not implemented and verified. The study of 317 plants in about ten countries (Bortolotti et al., 2015 [6]) shows that the most decisive factor between problem solving that works and problem solving that fails is not the quality of the analysis, but the presence of soft practices — involving the people who will carry out the solution, training, structured follow-up. Deciding and implementing are two distinct phases: the first chooses between alternatives, the second puts them into practice and measures their effect.
\nThe four operational elements of implementation.
\nCriteria for choosing between alternative solutions. When there are several plausible solutions, evaluate them on three dimensions: expected impact (how much of the problem does it solve?), implementation cost (time, resources, training), reversibility (can you go back if it doesn't work?). Prefer reversible solutions in the early phase: they let you experiment without risk.
\nA small-scale pilot before rollout. The solution is tested on one process, one customer, one team — not introduced across the whole organization at once. The pilot lasts 2-4 weeks and produces real data before the solution is extended.
\nA verification metric defined before implementation. Before launching the solution, you establish: how is success measured? Which indicators should you watch? Over what time frame? Without a predefined metric, verifying effectiveness becomes subjective. Liker [3] describes this principle as \"go and see\": checking in person that the solution produces the expected effect, not relying only on reports.
\nFollow-up with dates and owners. Every action has a named owner and a verification date on the calendar. Follow-up happens in the next meeting: you check whether the solution produced the expected result. If yes, it is standardized. If not, you go back to the analysis. For the change management implicit in implementing a new solution, the cluster on organizational change management covers the dynamics of adoption.
\nWhen the business owner's proposal wins out over another, is it because it was the best one or because it was the business owner's?
\nPrinciple 13 of the Toyota Way calls for making decisions slowly, thoroughly considering the options, and then implementing them rapidly [3]: without criteria written down before the discussion, the question cannot be answered — and whoever lost knows it.
\nThe three criteria seen above — impact, cost, reversibility — are enough when there are two alternatives.
\nWhen there are three or more, and the criteria do not carry the same weight, you need a decision matrix: the alternatives in rows, the criteria in columns, a weight for each criterion, filled in before the discussion.
\nThis section shows how to build one in fifteen minutes, how to bring in the proposals of those who do the work, and where problem solving ends and decision-making begins.
\nThe matrix is built in four steps.
\nA weighted criterion is a criterion that openly counts more than the others: the weight written in the column makes explicit what remains implicit in the meeting.
\nA hypothetical example, in a family business where complaints are handled late: three alternatives — hire a person, change the management software, rewrite the procedure — the second proposed by the business owner, the third by the long-serving department head who actually runs the process.
\nWith the weights set beforehand, the rewritten procedure scores highest: less impact than the software, but reversible, quick to put in place and accepted by those who will use it.
\nThe row reserved for the proposal of those who work in the process is not a courtesy: the research [6] indicates that the involvement and training of those who will carry out the work distinguish successful implementations from failed ones.
\nFor that row not to remain empty you need an ordinary channel, such as the Improvement Suggestions Board.
\nFive glossary concepts hold the matrix and the meeting together.
\nOnce the alternative has been chosen, implementing the solution goes through the pilot, metric and follow-up already covered, and problem solving stops there: putting the things to do in order is a different skill, covered in priority management.
\nThe opening question can now be answered: with the matrix filled in beforehand, the business owner's proposal wins when it scores highest, and whoever lost can read why in the columns.
\nA choice made this way holds up at the next meeting; what brings it down are recurring mistakes, which are worth recognizing in advance.
\nWhich of these five mistakes comes up most often in analysis meetings? The most honest answer is usually: \"all five, in different proportions depending on the week.\"
\nThe recurring mistakes in business problem solving are not about the tools, but about how they are used. The research [6] and Rother's observations on Toyota Kata [4] converge on one point: problem solving fails when it is treated as an exceptional event rather than a repeatable habit. The five most frequent mistakes are predictable — and therefore avoidable.
\nMistake 1 — Jumping to solutions without defining the problem.\nDescription: the \"problem-solving\" meeting starts directly with proposed solutions, without having defined the problem in a measurable way.\nOperational fix: the first output of the meeting is a sentence that defines the problem in observable terms: \"The average response time to complaints is 7 days against the 3 promised\" — not \"complaints are handled badly.\"
\nMistake 2 — Confusing the symptom with the cause.\nDescription: the solution is applied to the first visible cause, which is almost always a symptom of the root cause.\nOperational fix: apply the 5 whys before proposing any solution. If the process takes less than 20 minutes without tools, you have probably stopped too early.
\nMistake 3 — Deciding without involving those who do the work.\nDescription: the solution is decided by management and communicated to team members as an instruction. The adoption rate is low [6].\nOperational fix: include at least one person who carries out the process in the analysis phase and in selecting the solution. A solution that the people doing the work helped define is implemented with more care.
\nMistake 4 — Implementing without defining the verification metric.\nDescription: the solution is launched, but it is not clear how success is measured. After 4-6 weeks, nobody knows whether it worked.\nOperational fix: before implementing, define which indicator to watch, over what time frame, with what success threshold.
\nMistake 5 — Treating problem solving as an event rather than a habit.\nDescription: the team gets together to do problem solving only when the problem is already serious. There is no recurring ritual for analyzing problems [4].\nOperational fix: set aside a monthly slot (30-45 minutes) dedicated to reviewing recurring problems, before they become emergencies. The kata [4] is the practice that turns problem solving from an event into a skill.
\nEmergency contexts. Structured methods require time for analysis. In acute emergencies (a problem causing immediate damage to customers or to safety), immediate containment comes before analysis. 8D explicitly provides for this sequence: first you contain the damage, then you analyze the cause.
\nSources [1], [2], [3], [4], [5], [9]. These are management books and industrial manuals, not peer-reviewed studies. The methodological claims rely on [6] (peer-reviewed) for the empirical part. The descriptions of the methods (PDCA, A3, 8D, 5 whys, Ishikawa) come from the original sources of the respective methods.
\nSource [7] Eurostat. The figure measures gross value added per person employed at current prices, by employee size class: it is a comparison of levels, not causal proof of a link between reactive problem management and the productivity gap. The link is plausible and consistent with the literature, but it is not demonstrated by the source. It should also be noted that the Italian gap does not affect companies of every size: above ten employees, the comparison with the EU-27 average favors Italian companies.
\nTeam size. Methods such as A3 and 8D are more effective in contexts with more people involved in the process being analyzed. For independent professionals, the PDCA cycle and the 5 whys are sufficient in most cases.
\nSources [10] and [11]. The ISTAT figure [10] describes the size structure of Italian companies with at least three employees (2022) and does not measure problem management practices: the inference about the absence of a quality function is the editors'. The Treccani entry [11] is a linguistic anchor, not empirical evidence.
\nWhich method is best to start with?\nFor a business that has never formalized a problem-solving process, PDCA is the most accessible starting point: it requires no specific training, applies at any scale and produces observable results in 2-4 weeks.
\nHow long does a cause analysis session last?\nFor a problem of medium complexity, a 45-60 minute session with the 5 whys or the fishbone produces enough analysis to identify the main root causes. Longer sessions produce more in-depth analysis, but the marginal return decreases beyond 90 minutes.
\nDo lean methods only apply to manufacturing companies?\nNo. The principles of cause analysis are independent of the industry. A communications agency, a professional practice and a logistics company use the same tools on different problems. The adaptation concerns the examples and the language, not the structure of the method.
\nStructured business problem solving is a phased process that separates analysis from solution: define the problem in a measurable way, collect data, analyze the root causes (with the 5 whys or the fishbone), choose the solution, implement it as a pilot, verify it with a predefined metric, standardize it if it works. The method is chosen based on severity (PDCA for recurring problems of medium impact, A3 for cross-functional problems, 8D for serious problems with external impact). Two moves come before the method: finding the problem while it is still a weak signal, and choosing between alternatives with written criteria; solving is the third, and the six-row comparison table matches the method to the type of problem.
\nThe most decisive factor between problem solving that works and problem solving that fails is not the quality of the tools, but the presence of three elements: a recurring habit (not an exceptional event), involvement of those who carry out the process, and a verification metric defined before implementation.
\nBusiness problem solving is not a method to apply: it is a sequence of three moves, and the method only serves the third.
\nFinding the problem while it is still a weak signal, choosing between the possible paths with stated criteria, solving with the technique suited to the type of problem: companies that recycle the same problems rarely get the third move wrong — they skip the first two.
\nThe methods remain valid, provided you match them to the right problem and don't ask a single one to cover every case.
\nFrom here the thread continues in three directions.
\nIf you want to turn problem analysis into a habit for the whole company, continuous improvement offers the framework in which PDCA and Kaizen become an everyday culture.
\nIf you realize that the sticking point is not the problem but the decision that follows it, you can continue with priority management.
\nIf you prefer to start from the disorder in which problems actually show up, you will find a different point of view in the editorial on how to bring order to business problems.
\nIf you want to follow the in-depth articles on the individual methods and on the decision matrix as they come out, you can subscribe to the newsletter.
\nA company that has learned the three moves can be recognized by a few concrete signs.
\nThe business owner is no longer the only person who notices that something is off, because team members have a place to write it down.
\nAnalysis meetings start from a problem described in one measurable sentence, not from a solution that has already been decided.
\nBetween two proposals, the choice is made with a table of criteria that anyone can reread, and those who will carry out the choice saw it before it was approved.
\nIf even a share of Italian micro-businesses reduced the proportion of problems that keep coming back, the gap in value added per employee that separates them from the European average [7] could narrow somewhat: without sudden breakthroughs, with a sober method — find first, choose with criteria, and only then solve.
\n\n[1] Imai, M., \"Kaizen: The Key to Japan's Competitive Success\", McGraw-Hill, 1986 (2nd ed. 2012).
\n[2] Ishikawa, K., \"What is Total Quality Control? The Japanese Way\", Prentice-Hall, 1985.
\n[3] Liker, J. K., \"The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer\", McGraw-Hill, 2004.
\n[4] Rother, M., \"Toyota Kata: Managing People for Improvement, Adaptability, and Superior Results\", McGraw-Hill, 2010.
\n[5] Sobek, D. K. and Smalley, A., \"Understanding A3 Thinking: A Critical Component of Toyota's PDCA Management System\", Productivity Press, 2008.
\n[6] Bortolotti, T., Boscari, S. and Danese, P., \"Successful lean implementation: Organizational culture and soft lean practices\", International Journal of Production Economics, 160, 182–201, 2015.
\n[7] Eurostat, \"Enterprise statistics by size class and NACE Rev. 2 activity (from 2021 onwards)\" — dataset sbs_sc_ovw, indicator Apparent labour productivity (gross value added per person employed, thousands of euros), industry, construction and market services (NACE B-S excluding O and S94), year 2023. Available at: https://ec.europa.eu/eurostat/databrowser/view/sbs_sc_ovw/default/table
[8] ISO, \"ISO 9001:2015 Quality management systems — Requirements\", International Organization for Standardization, 2015. Available at: https://www.iso.org/standard/62085.html
\n[9] Ford Motor Company, \"Team Oriented Problem Solving (TOPS-8D) Manual\", Ford Motor Company, 1987 (updated 2018).
\n[10] ISTAT, \"Censimento permanente delle imprese 2023: primi risultati\", press release, ISTAT, November 14, 2023 (data for 2022; sample of about 280,000 companies with 3 or more employees, out of a population of 1,021,618 units). Available at: https://www.istat.it/comunicato-stampa/censimento-permanente-delle-imprese-2023-primi-risultati/
\n[11] Treccani, \"Problèma\", Vocabolario on line, Istituto della Enciclopedia Italiana. Available at: https://www.treccani.it/vocabolario/problema/
","headings":[{"level":2,"text":"Understanding what structured problem solving is (and why it is not \"holding a meeting\")","id":"understanding-what-structured-problem-solving-is-and-why-it-is-not-holding-a-meeting"},{"level":2,"text":"Finding the problem before it costs you: problem finding, weak signals and gap analysis","id":"finding-the-problem-before-it-costs-you-problem-finding-weak-signals-and-gap-analysis"},{"level":2,"text":"Recognizing which problems deserve analysis (and which are only symptoms)","id":"recognizing-which-problems-deserve-analysis-and-which-are-only-symptoms"},{"level":2,"text":"The phased process: PDCA, Toyota A3, 8D — when to use them","id":"the-phased-process-pdca-toyota-a3-8d--when-to-use-them"},{"level":2,"text":"Techniques to avoid jumping to solutions: the 5 whys and the Ishikawa diagram","id":"techniques-to-avoid-jumping-to-solutions-the-5-whys-and-the-ishikawa-diagram"},{"level":2,"text":"Which method for which problem: the comparison table from PDCA to root cause analysis","id":"which-method-for-which-problem-the-comparison-table-from-pdca-to-root-cause-analysis"},{"level":2,"text":"Deciding and implementing the solution: the most delicate step","id":"deciding-and-implementing-the-solution-the-most-delicate-step"},{"level":2,"text":"Choosing between several alternatives with explicit criteria: the decision matrix in 4 steps","id":"choosing-between-several-alternatives-with-explicit-criteria-the-decision-matrix-in-4-steps"},{"level":2,"text":"Common mistakes in business problem solving (and how to avoid them)","id":"common-mistakes-in-business-problem-solving-and-how-to-avoid-them"},{"level":2,"text":"Limits and conditions of applicability","id":"limits-and-conditions-of-applicability"},{"level":2,"text":"FAQ — Frequently asked questions about business problem solving","id":"faq--frequently-asked-questions-about-business-problem-solving"},{"level":2,"text":"Operational summary","id":"operational-summary"},{"level":2,"text":"Conclusion","id":"conclusion"},{"level":2,"text":"Sources and references","id":"sources-and-references"}],"tldr":"When a problem keeps coming back, should you change the method you use to tackle it, or the moment you tackle it?","tldrItems":null}