Por: Rodrigo Aquino     5368 visualizações     Tempo leitura: 6 min

Every time you developed a software for your company or client, did you know exactly what was the purpose of its launch and how it fits in your company's business strategy? To know whether we are doing the right thing or we not only need the correct requirements, but the requirements validated according to the company's strategy, and this leads us to Hoshin Kanri.

The term Hoshin Kanri, which comes from the Japanese being a metaphorical language, has several meanings, among them "compass". In English it is known for strategy deployment. Hoshin is a system of planning and executing the Toyota and it aims to focus and align the activities of the company and each employee, allowing it to respond quickly to opportunities and market threats. According to James Morgan, in his book Toyota Product Development System: "The planning process Hoshin determines goals at the corporate level, each employee has objectives that are developed along with their immediate superior, and these goals, in turn, fit perfectly with the next level up."

Make sure that everyone in the company is working for the "True North" which is not something easy to do. First the company, specifically the senior management must define its strategy in one or a few business requirements. These requirements must be broken down into indicators, which in turn must be broken into other indicators in the operational level. The more we descend, more specific organizational level indicators there should be. Each indicator should have a goal, a value that represents the amount done and a formula (ensuring the relationship between them). If the value of an indicator changes, the other that relates to it at a higher level will be modified automatically. Importantly, the measurement of these indicators should be done daily so that you can take countermeasures, if something is not going according to plan (target). This practice, known as daily management, helps to avoid surprises increases the organizational learning and creates engagement to solve problems.

Figure 1 below shows an example of the deployment indicators in the second level. Note that if the "machine availability" indicator is below target, the "Delivery" will be affected and consequently other goals such as "Revenue", "EBIT", "Cash-flow Increase" and "No layoffs". The way to identify a problem and to know how much effort the company must make to solve it, otherwise the consequences could be catastrophic, is another feature of Hoshin. We conclude that the the strategy deployment must go hand in hand with the methods for solving problems such as A3, Ishikawa diagram, etc. These methods, which I will explain better in the next articles are crucial to ensure that problems do not recur and that we can have basic stability in the daily operations of an organization.

Figure 1. Second level of the tree with the current and Needed metrics Source: Dennis, P. (2010), Getting The Right Things Done (p. 55). Lean Enterprise Institute, Inc.

How to relate Hoshin to a company that uses Lean IT? Imagine an organization that uses User Story (U.S.) or hypotheses to guide their development of software. At the end of the day they may have created some User Stories and if the company did not have the resources to implement all parallely, the following question will arise: "What should we need to develop and launch first?" - One that originated from a major customer? The one that we consider most important to the company? The answer is: none of them. First we must establish a direct relationship between the User Story (US) and an indicator that are at the board of the company. Knowing exactly how and how much this User Story (US) finalized will benefit the indicator and how these numbers will change the structure of the company would be the first step. To clarify we will take, as an example, two User Stories. The first one is about an error in the Web Site and the second indicating a new feature to be developed. Assuming the "Customer Satisfaction Indicator" is composed of several indicators among them "Web Site Bugs". The greater the number of errors on the Web Site, the greater will be the chances of higher indicator not reaching the goal. Now imagine the "Innovation Index" indicator which in turn is formed by several others, eg, "New features launched" monthly. The indicator that has a higher ratio (which will bring more benefits to the main indicator of the company) with the "Operating Profit" is that which relates to User Story (US) should be done first. But what if the User Story (US) that represents Web Site Bugs is linked to a serious problem, causing the company to lose X customers per week and thousands of dollars? In that case the User Story (US) should be related to another indicator, which in turn will be summarized in, for example, "Loss Index". That way it will be easier to define what should be done first before there is a large amount of User Story (US) arising every moment in the company. For this reason, we emphasize the importance of establishing a correct relationship between indicators. This relationship should always start from the top down, ie, goals (with the main goals of the organization) to the operational level. This work is for the top management of a company, such as: president, vice president, CEO, directors, etc.

In this article I explained briefly what Hoshin is and how it can be related to a company that adopts the Lean Thinking in IT. User Stories were cited as an example to drive software development, in addition to clarifying that define the best sequence of activities (which adds greater value to the customer) is not enough, you must make sure that this sequence is aligned to Hoshin of the company - this is a task to be done daily by everyone in the organization. To conclude I quote the words of Pascal Dennis in his book - Getting The Right Things Done: "At Toyota Motor Manufacturing Canada plant in Cambridge, Ontario, strategy deployment steered us through the chaos and stress of continual expansion. In 10 years we grew from a cornfield to a 3,000-person company making 230,000 cars per year."

Bibliography

Data da publicação: 08/10/2013

Gostou do artigo? Para receber nossos informativos click here.