"formulate clear problem statements" (parte VI)

Parte I, parte II, parte III e parte IV.

Em "The Most Underrated Skill in Management" propõe-se o uso do A3 como forma de sistematizar o desenvolvimento de uma acção de melhoria:

"To track problem-solving projects, we have modified the A3, a famous form developed by Toyota, to better enable its use for tracking problem- solving in settings other than manufacturing. The A3 form divides the structured problem-solving process into four main steps, represented by the big quadrants, and each big step has smaller subphases, captured by the portions below the dotted lines.

...
Though the form may often have supporting documentation, restricting the project summary to a single page forces the user to be very clear in his or her thinking. The A3 divides the structured problem-solving process into four main steps, represented by the big quadrants, and each big step has smaller subphases, captured by the portions below the dotted lines. The first step (represented by the box at the upper left) is to formulate a clear problem statement. [Moi ici: 1.1 Qual é o problema que temos de resolver] In the Background section (in the bottom part of the Problem Statement box), you should provide enough information to clearly link the problem statement to the organization’s larger mission and objectives. [Moi ici: 1.2 Porque temos de trabalhar neste projecto? Qual o contexto. Qual a importância deste projecto. Que objectivo queremos atingir?] The Background section gives you the opportunity to articulate the why for your problem-solving effort."

2.1 - Como é que que funciona o processo actual? Qual o fluxograma? Que resultados temos? Que segmentação é possível fazer? Pareto(s)? Histograma(s)?

2.1 - Que suspeitas? Que hipóteses de causas mais prováveis? Que análises/testes devem ser feitos para despistar hipóteses irrelevantes? Espinha-de-peixe? Diagramas de correlação? 5 Porquês

"asking the “5 whys,” meaning that for each observed problem, the investigator should ask “why” five times in the hope that five levels of inquiry will reveal a problem’s true cause. Later, Kaoru Ishikawa developed the “fishbone” diagram to provide a visual representation of the multiple chains of inquiry that might be required to dig into the fundamental cause of a problem.
...
The purpose of all root-cause approaches is to help the user understand how the observed problem is rooted in the existing design of the work system. Unfortunately, this type of systems thinking does not come naturally. When we see a problem (again, thanks to pattern matching) we have a strong tendency to attribute it to an easily identifiable, proximate cause. This might be the person closest to the problem or the most obvious technical cause, such as a broken bracket. Our brains are far less likely to see that there is an underlying system that generated that poorly trained individual or the broken bracket. Solving the immediate problem will do nothing to prevent future manifestations unless we address the system-level cause.
A good root-cause analysis should build on your investigation to show how the work system you are analyzing generates the problem you are studying as a part of normal operations."

3.1 - Que acções vão ser implementadas? Que processo futuro vai ser implementado?

"to propose an updated system to address the problem. Often the necessary changes will be simple. In the Target Design section, you should map out the structure of an updated work system that will function more effectively. ... The needed changes will rarely be an entirely new program or initiative. Instead, they should be specific, targeted modifications emerging from the root-cause analysis. Don’t try to solve everything at once; propose the minimum set of changes that will help you make rapid progress toward your goal.

3.2 - Que resultados pretendemos atingir?

"First, create an improvement goal — a prediction about how much improvement your proposed changes will generate. A good goal statement builds directly from the problem statement by predicting both how much of the gap you are going to close and how long it will take you to do it. If your problem is “24% of our service interactions do not generate a positive response from our customers, greatly exceeding our target of 5% or less,” then an improvement goal might be “reduce the number of negative service interactions by 50% in 60 days.” Clear goals are highly motivating, and articulating a prediction facilitates effective learning.
.
Finally, set the leadership guidelines. Guidelines are the “guardrails” for executing the project; they represent boundaries or constraints that cannot be violated. For example, the leadership guidelines for a project focused on cost reduction might specify that the project should identify an innovation that reduces cost without making trade-offs in quality."

4.1 - Qual o plano de implementação?

"lay out a plan for implementing your proposed design. Be sure that the plan is broken into a set of clear and distinct activities (for example, have the invoice form reprinted with the general ledger code or hold a daily meeting to review quality issues) and that each activity has both an owner and a delivery date.
Now execute your plan and meet your target. But, even as you start executing, you are not done engaging in conscious learning."

4.2 - Resultados atingidos? Projecto eficaz? O que se aprendeu? Qual o próximo desafio?