The term Kentou (study phase) is part of the Toyota Product Development System (TPDS), a refined and powerful model as the Toyota Production System. With the TPDS the time required to develop a new vehicle fell from 24 months (the average time among other automakers is currently 24-30 months) to 15 months regular and extraordinary 10 months in special cases. Obviously Toyota got those numbers after long years of study and continuous improvement of internal processes. When we develop something new, we deal with processes, people and tools (technology) and the appropriate integration between them is what will make the difference in the final product with respect to delivery time, quality and cost. The Kentou marks the beginning of TPDS with meetings on the project for, which the rule is: "Plan carefully and execute with precision." Using Kentou we intend to concentrate our efforts to better control the variability inherent in the product development process. The study phase has various characteristics, eg, set based concurrent engineering, undo misunderstandings, align involved people, participation of senior employees from all areas of the company through which the product will pass, etc. The themes are very comprehensive to address in a single article so only set based concurrent engineering and the importance of the participation of the most experienced people in the early development of a product will be best explained.
When the team from the University of Michigan conducted an interview with the engineers of the auto industries of the U.S. and Japan, they noted a similarity in the responses of all of them about how they developed cars (with the exception of those who work at Toyota). All engineers who used punctual iterative model didn't consider many initial alternatives before selecting a clay model. Subsequently several problems arose with the aerodynamics demanding change (iteration). They also did numerous settings to modify some aspect regarding the style of the vehicle for the project "to work." When work of the instrumentalization began, other problems arose generating more iteration. It is not difficult to identify that this model consumed time, resources and resulted in a suboptimal design. By relating this type of work with IT would be to develop something without knowing the purpose of the project, the target audience, potential changes, risks, etc, the final result, so that the system meets the customer's expectations, is a disconnection of business rules and a database with a lot of patch work. With a different model, Toyota uses the set based concurrent engineering. These possibilities are raised during Kentou, shaped Kentouzu (study designs) in order to ensure that no drastic adjustment needs to be done in the middle of the project. We can understand a Kentouzu as a possible solution that may or may not be expressed by means of a prototype, aiming to help in decision making. Each solution is deeply studied to predict future situations, using less resources and time, avoiding the risk of developing something that will not be use. Figure 1 shows how engineers and other automakers of Toyota work. The first one uses ponctual iterative model, whereas the Toyota uses set based concurrent engineering in which each point indicates a Kentouzu.
Figure 1. Models used to develop a product. Source: Morgan, M. J and Liker, J. K. (2008),Toyota Product Development System.
From the point of view of Lean IT, Kentou should represent the meetings held at the beginning of a project considering various alternatives related to software and hardware solutions, eg architecture to be used, language, platform, server, bandwidth, number of concurrent accesses, type of database, critical points to be considered, size and team level, time available, etc. All possibilities should be collected and disposed of in order to have the best solution, ie, the one that provides greater value to the client on the scope, timing and payment. All senior members of the company areas should be called for these meetings, through which the project will pass, for example, marketing, infrastructure, financial, IT, judicial, etc. In other words, the experienced participants of areas must be present even if they are actively developing other projects. The idea at this stage is to use the vast experience of each one to predict future problems that may delay the development, eg, scope changes, market conditions, turnover, etc. Importantly, the development of the project will begin only after the solution has been defined and discussed deeply. The Kentou does not have a specific deadline to finish because it depends heavily on the experience of those involved in anticipating and making the solution as simple as possible for future problems in a project. After completing this phase, people return to their activities, and some of them with a set schedule of development, of those who will participate. In the study phase is defined not just one, but several related development schedules for each part of the project. Several project activities occur parallelly, while others are predecessors (the result of one is used to start the other). For example: As soon as the person responsible for the database has created the necessary tables for the X module which would be passed to and developed by the staff responsible.
Just as the development of a vehicle, building an IT project can present many initial problems. In the case of a vehicle, for example, if the solution X was selected, the coefficient of friction would not be acceptable when the block was embedded in the front suspension due to the angle resulting from the process. In relation to IT it is like a graphic component, which would be purchased and used in the middle of the project which did not work so well in the language of choice (and this was noticed after much coding). To avoid this problem the study phase should be planned carefully. The Kentou can be identified as the predecessor activity to any software development process and to ensure its benefits, it must be adjusted to each type of company. It serves as a guide, in order to avoid deadlocks during any adjustments requested by customers throughout the development. It is important to clarify that the study phase has no relationship with the daily meetings adopted, for example, at Scrum. With Kentou we intend to eliminate the problems of late changes, ie, emergency solutions which cannot be called continuous improvement (Kaizen), but one of the worst kinds of waste.
Bibliography
- Morgan, J. M. e Liker, J. K. (2008), Toyota Product Development System - Portuguese Version (p. 322). São Paulo: bookman
- Bell, C. S., Orzen, A. M. (2013), Lean IT - Enabling and Sustaining Your Lean Transformation. New York: CRC Press