Ford, Toyota and Guinea Pigs

    - What does the guinea pig have to do with the sea?
    “About the same as the platypus for designing airships.”


    Introduction


    I tend to scroll through information from several sources while walking, matching pieces. One of the interesting findings is the almost complete correspondence of the statistical observations of Demarco and Lister in Peopleware and Goldratt's theoretical calculations in the Critical Chain.

    In the fall of 2011, I turned in my head:
    [1] “Standing on the shoulders of giants” Eli M. Goldratt © Eliyahu M. Goldratt, 2008
    [2] “Production management: flow control” Oded Cowen, Elena Fedurko
    [3] “The history of one board” (http://cartmendum.livejournal.com/tag/theboard).

    Further I would like to write: “Suddenly ...” - but this will not be true. This did not happen all of a sudden. It took me a couple of weeks, but, in the end, a fairly complete picture formed in my head.

    What exactly did I catch on:
    • Taichi Ono (Öno Taiichi) did not understand why his system worked.
    • There are several different types of production flows - V, A, T, I. Each type of flow poses special tasks.
    • Failures of Maxim Dorofeev board implementation in some units
    • A number of companies could not implement the Toyota system, despite all the efforts made.
    • The Toyota system and the Ford system are based on the same principles, but applied solutions are limited to certain types of production.

    Theory. Stream types


    Flow types are commonly classified from the dominant pattern. In a pure (degenerate) form, the types of flows can be represented as follows:

    If more detailed information is needed, then it is better to refer to the articles by Oded-Cohen and Elena Fedurko.

    In the world of software production, an analogy can be drawn:

    The main difference is that software production often lacks materials. It is not clear what to use as an analogy to materials in the world of software production. Orders are both there and there. As a rule, production at the plant also does not start without an order. Probably, the input ideas can be considered as materials. During the development process, these ideas are transformed into requirements specifications, then into architectural solutions and, finally, into the final product.
    Disclaimer I’m not sure that the problems of the same type of production chain are the same for the worlds of material production and the world of software development. This is a hypothesis that has many supporting examples. But even one exception may cast doubt on this hypothesis.

    Maybe someone wants to change the classification. For example, I wanted to. I would prefer to add two more types:


    But this deviation from the standard, and it is better to adhere to the standard, even the bad.
    There is a suspicion that the Zh-type is a more correct name for the T-type, just the Americans are out of luck with the alphabet. ;-)

    I type


    The easiest I-type stream to manage.

    But even for this type, there are a number of common mistakes. The most common mistake is the use of “pushing” control models.

    Consider a classic example typical of the IT industry. Let's take a simple, even trivial chain “Sales Department” -> programming department -> testing department.

    Process diagram:

    Let the departments process accordingly:
    • Sales Department - 20 orders per week
    • Programming Department - 10 orders per week
    • Testing Department - 5 orders per week

    To this we add a bonus system, depending on the number of orders processed by the department. It is logical that the sales department will take all the orders that they can process. It is also logical that most top managers will order all orders. Here is an example of a discussion about a year ago:

    > beat programmers hands and stop them from recruiting projects more than programmers have time to do. Naturally, there should be a small project buffer in front of the programming department.

    The first thing that at least the smallest head of the company can do, after reading this, will hit the author’s head, then he will give him the Napoleonic cocked hat and send him to fool. This is to what extent should programmers go to decide how much a firm needs to sell? I understand that it is difficult for them to increase production to the requested sales, but the availability of sales opportunities is an occasion not to beat sales, but to work on the possibilities of satisfying their requests.

    In Russian: they bring money to the company, and some intend to send it.


    The result is quite obvious. The production chain will quickly become clogged with executed orders and the average lead time will increase to indecent values. For this case, in just six months, the average time for fulfilling orders will increase to two years. Which is not too competitive, but it happens all the time.

    Balancing performance areas also does not bring happiness. There are “beats” in the system and the average lead time again increases to indecent values.

    Max Kramarenko has a blog on modeling a balanced production chain:
    • http://maximkr.livejournal.com/18940.html
    • http://maximkr.livejournal.com/18971.html

    Modeling shows that as a result of beating, the production chain is quickly clogged. At the end of the experiment, for a short chain of only 4 sites, one and a half hundred tasks were in production. Translating into a “modern managerial”, this means that the task with a labor intensity of four man-days will be realized in six months. To the manager’s question: “Why so long ?!”, the answer is simple: “Because you manage it like that.”

    It is important. The blame for the enormous length of order execution almost always lies with the workflow management system (management), and not with the executors.
    Well, whoever doesn’t believe can try to write a simulator and experiment.

    In fairness, it should be mentioned that a balanced chain can be used if you follow the rule: "The average employee downtime should be at least 20-25%." But again, which of the managers would do this?

    Ford A-Type and Solution


    The problem with this type of flow is the missing components in assembly operations.

    The I-type production chain is primitive like a rake and unpretentious like a young radish. I believe that the best way to manage such chains was known a long time ago, but unfortunately I have not yet found information in which century this technique was first described. However, at some point, childhood ends and the managers face truly complex tasks. A similar challenge, along with others, was faced by Henry Ford. At that time, Ford's automobile production was A-type production. Complex, with many branches, but having one vertex. One single car brand, one single color. Lack of stock of any part in any assembly area leads to an increase in the time of car production. But an excessive supply of parts also leads to an increase in the time it takes, to get a finished car out of iron. Time increases, because each part spends a substantial part of the time in the waiting queue.

    In 1913, Henry Ford introduced the conveyor assembly method of cars at his factory. And by 1926, the production cycle from mining iron ore to receiving a finished car (consisting of more than 5000 parts) located on a railway platform and ready for shipment reached 81 hours! .. [1] An outstanding achievement. Imagine the complexity of setting up a software production process that consists of at least 50 production sites. I believe that most modern managers would request a complex ACS (automated accounting system) to manage the work flow. But at the beginning of the century there were no computers ...

    Contrary to popular belief, the Henry Ford production line is not a familiar conveyor belt for us to collect cars in sync. These are separate work centers, with manual transfer of parts. “To improve workflow, Ford has limited the space available for storing work-in-progress stocks between every two work centers. This is the essence of production lines, which is confirmed by the fact that the first production lines did not have any mechanical devices, such as conveyors, for moving stocks (work in progress) from one work center to another. ”[1]. For want of computers, Ford created a visual work management system. Extremely easy to use.

    Yes, of course, this system would not work if the additional rule were not introduced: "when the allocated space is full, the workers who fill it must stop production . " To go for a walk, take a nap, sit on VKontakte, ...

    Ford refused one of the main provisions of his modern management. However, now, 99 years later, little has changed. I think, come Ford to a typical Russian company for an interview and say that part-time work is a prerequisite for increasing the company's income , he would be told that he does not know how to manage real production.

    More complex types and Toyota system


    V-type flow problems - “material theft”;
    T-type flow problems - “theft” and missing components;

    Ford's visual model works great for the A-type. But as soon as there is no merging, but branching (one work center supplies parts for several centers), problems begin. It was these problems that eliminated the advantage of Ford production lines at a time when General Motors entered the market with a wide range. Company managers were again challenged.

    The glove was raised by Taichi Ono, who began work at Toyota Motor Corporation in 1943. In the mid-1950s, he began to build a special production organization system, later called the Toyota Production System (also mistakenly referred to as Kanban, Lean, Just-In-Time).

    Ono, like Ford, did not have an automated control system, and he developed a visual workflow management system based on kanban (translation option: visual card). However, this system would not bring such an effect without additional requirements. At each point in time, in areas with a power reserve, one of two improvements must be made: either reduce the batch size (increase the number of switching and associated losses), or reduce the readjustment time.

    “At that time and until TPS gained worldwide fame, increasing the size of the lot was considered the traditional way to reduce the changeover time -“ economically sound lot size ”was a very popular term to which thousands of articles were devoted. It rejected all this traditional experience. ”[1]

    It challenged the modern management system. It is logical that they did not forgive him. From the late 40s to the early 60s, his system was called the “disgusting Ono system."

    However, now, after six decades, among people who call themselves Lean supporters, eliminating switching is considered one of the most powerful methods to increase the passage. It didn’t think so. I suppose if Taichi Ono came to the lean manufacturing conference and articulate your position, he would be told that he simply does not know how to manage real production.

    Addition rules


    And then the fun begins. If the work center is involved in more than one of the chains, then these chains need to be folded: The

    left and right A-type flows could be controlled by the Ford visual model, but due to the joint use of work centers “3” and “4”, the scheme becomes more complicated and we need to move on to the Ono model. If you do not want to use such a complex model, then you should divide the work centers “3”, “4” into “3 '”, “3” ”,“ 4' ”,“ 4 ”.

    Understanding the applicability of management models and their complexity should have a significant impact on the decision to change the organizational structure of the enterprise and development regulations.
    Example. Let it historically be that the company has four different development centers responsible for supporting four different internal products. At some point, a test group was created at the first center. This innovation turned out to be quite effective and the issue of separating the testing group into a separate service that provides testing services to all four development centers is being considered. Pros and cons?
    Cons: there will be a change in the type of stream and there will be manageability problems. Instead of 4 I-type chains, there will be one complex chain:

    If the power reserve is provided in the testing work center, the conversion will not lead to negative consequences. But something tells me (all my previous experience) that testing will become a limitation of the system with all the ensuing sad consequences.
    Let it historically be that the company has one department responsible for supporting internal products and carrying out improvements for several customers. Take the fairly common structure of “programming -> testing”. The simplest, trivial I-stream, easily controllable. At some point in time, the quality of supply ceased to satisfy customers and the company is considering the introduction of the acceptance stage. Pros and cons?
    Cons: there will be a change in the type of stream, and there will be manageability problems. Instead of one I-type chain, there will be one complex chain.

    If the delivery of improvements is organized in packages common to all customers, then one single customer can block both the current and subsequent deliveries to everyone else.

    The matrix system also leads to negative effects when an employee has two managers at once: the head of the functional unit and the project manager. Even Truffaldino did a poor job of serving two masters. And in real firms on real projects, this leads to a fantastic mess and a monstrous increase in the time of ALL projects.
    Retreat. In Liker's book about Toyota's product development system, it says that Toyota's research centers are just matrix control. Moreover, they came to this meaningfully and do not want to change this. In fact, they have all sorts of other tricks that make the matrix workable. One of them is that the project manager is a specialist with great authority among colleagues. As a rule, he must work in the company 10-25 years. In this case, he is a leader and formal levers of control are not necessary for him. The matrix is ​​not evil, just making it difficult

    Sometimes in large firms go on a tough suppression of cases of manifestations of the "Servant of two masters." One of the options that I heard about is the internal labor exchange. The engineer of the corresponding specialization is located in the structural unit (the programmer in the pool of programmers) and reports to the pool manager. Submits until transferred to the project. After that, it reports only to the project manager. Giving a direct order to an engineer engaged in a project, by someone other than the project manager, is an attack that may well result in personnel shifts. The company sags a bit due to underemployment of employees, but the benefits of ease of management are so huge that they outweigh these losses. In addition to this, the principle “The vassal of my vassal is not my vassal” is used - the platoon commander cannot give the order directly to the soldier. And if he gives, then he will look for new sergeants. Or sergeants will look for a new platoon commander.

    Kanban board and guinea pig


    MSProject, popular in the Russian Federation, is not bad for project planning. It is slightly worse for planning processes. For planning processes, a commonplace tracker is often better. But this is not important. Both the tracker and Project are “Information Refrigerators” (a term coined by Alistair Coburn in one of the best books on Quick Software Development methodologies). To increase the development efficiency, an “Information Radiator” is needed. And naturally, we need work management rules.

    This may give the impression that the board is an information radiator. In fact, fashionable boards are the same trackers, that is, the same refrigerators. To turn a board into a radiator, you need to hang it in a public place. And as soon as they start using a web tool under the board, it immediately becomes a refrigerator. Well, if you don’t bring it to the plasma in the corridor or under the ceiling.

    A few years ago it was proposed to use a board on which stickers with a description of tasks are placed. Now this is a pretty fashionable hobby. At the request "Kanban board" the search engine gives a lot of links to something like this:
    The figure clearly shows the visual control system for I-type streams. Not related to the Taichi Ono system. Moreover, this system is more primitive than even the Henry Ford system. This "progressive" model lags behind the theory and practice of the science of managing the workflow of "only" 99 years.

    What do kanban board and guinea pig have in common? A kanban board has roughly the same relation to kanban as a guinea pig to the sea.

    It would seem, well, they called it wrong, so what? And the fact that the wrong term gives the illusion of the universal applicability of the tool. Too often, consultants try to apply this board to inappropriate stream types. Naturally, the attempt fails, but for some reason the consultants blame the performers. “You simply misused XP / SCRUM / Kanban / ...” Gentlemen, if screwing a nail with a Phillips screwdriver failed, then you should not blame the artist for holding the screwdriver incorrectly. You just need to give him a hammer.

    I recommend to be cautious and wary of the “consultants” for “XP / SCRUM / Kanban” who do not know the theory of production flows. It’s not that they could not be used at all, but the inability to apply the theory of flows, Shekhart’s cards, the inability to add up the probabilities of performance with significant deviations in the deadline and so on and so forth should alert you.

    In the future I will call such a board an I-board.

    As for the management rules, at the seminar Suren Samarchan (video cast: http://spmguild.org/news/618/) said that a task can be taken into production only if one of the programmers is freed. It is easy enough to understand that this will work only if the system restriction (often mistakenly referred to as the “bottleneck”) is at the beginning of the production chain (see the management of the tourist column in Goldratt’s book “The Goal”).

    Quite often, in isolated small cross-functional development teams, this is exactly what happens. The limitation is at the beginning of the production chain. And everything is going well. But as soon as the restriction of the system goes somewhere else ... All finita la comedia. We need a system "a little podshamanit." Maxim Dorofeev found the rule of thumb "The number of tasks in production should not exceed the number of programmers by more than 2." This is a normal shamanic rule.
    A more interesting tuning of the board was suggested by Oleg (did not indicate his last name) in the article “Kanban in IT (Kanban Development)” (http://habrahabr.ru/blogs/development/64997/).And now the most important thing. See the numbers under each column? This is the number of tasks that can be simultaneously in these columns. Figures are selected experimentally, but it is believed that they should depend on the number of developers in the team.

    It resembles a Ford production line, but applied to an I-type stream. Actually, this is a visualization of Henry Ford's rule: "The volume of work in progress between two work centers should be limited."

    Oddly enough, but often the limitation of the system is the site of acceptance of the task by the customer. I know at least three firms where this effect was observed.

    There is another limitation on the use of I-boards. This limitation is associated with the efficiency of the cycle at one production site (for one contractor). If the cycle efficiency is less than 50%, then the rule “one artist has only one job” starts to fail.

    Note. The efficiency of the cycle is the ratio of processing time to the total time spent at the production site. If in the morning you got a task, and you did it just before leaving, then the total time is 8 hours. If you worked on the task for 2 hours, then the efficiency of the cycle is 25%.

    I will give examples where the restriction of one task for an executor per unit time will be ineffective:
    • Police projects (www.toc-center.ru/politseiskie_proekty.html)
    • Writing TK and PMI (GOST 34.602 and 34.603). Documents strongly influence each other and sometimes it is easier to write two documents at the same time.
    • Cooking a gala dinner. The broth set to boil requires the participation of a person during cooking from strength for a couple of minutes. At this time, it is quite possible to do cooking salads. If the hostess was preparing a festive Christmas dinner according to the Suren Samarchan system, then the guests would remain hungry. It’s just that the system is not applicable there.
    • Often applications sent to the technical support service fall into this category. For example, procurement requests often have a long suspension period during which an employee can do something else.
    If this happens, tighten the terms of use. Allow the contractor to work on several tasks simultaneously.

    And one more limitation. I-board poorly visualizes the relationship between tasks. It is well suited for maintenance processes with independent tasks and worse for projects. Although for short projects with loosely coupled tasks it may be suitable.

    Nevertheless, such a board is very easy to use and if the unit is suitable for implementation, then this is one of the most effective ways to manage flows. All the same, both the Ford system and the system. It is quite difficult to visualize.

    Just before introducing such a board you need to go through the checklist:
    • I-type stream? If not, then most likely you will have to abandon attempts to introduce a simple board.
    • Is the restriction at the beginning of the chain? If not, take care of the supply buffer. Come up with a sub-rule.
    • Is the cycle efficiency at one production site more than 50%? If not, remove the restriction on processing only one task at a time.
    • Are incoming orders interconnected or can be executed in isolation? If connected, then you need something else to visualize. You may have to switch to drawing a network diagram. Maybe something else.

    Often a stumbling block is a stream of complex type. To simplify the type of flow, an effective medicine is the isolation and isolation of individual project teams and functional units.

    But, too often, we hear phrases: “We cannot help but pull him. No one can do this except him. And you cannot completely transfer it to us. We need it only four hours a week. ”

    The solution lies in eliminating the irreplaceability effect. XP-shny co-ownership of the code, and the introduction of coding standards and training in related specialties (one of the exotic combinations that helped us greatly in one of the projects are “system administrator” and “computer artist” in one person) will do.

    The separation of the company into isolated groups can benefit the greater, the more cross-functional specialists.

    In one of the companies, you seriously discussed the advisability of admitting a system administrator to the development group and a programmer to the system administration group. Colleagues say that this rule, implemented as an experiment, showed a good result.

    Andrei Orlov, in Notes by an Automator, proposed a simple rule of thumb: "If a programmer has become indispensable, immediately fire him."
    The proposal makes perfect sense. An irreplaceable employee may well have the highest local productivity, but his indispensability destabilizes the flow too much.

    Another option is to reduce the length of the stream. Reducing the number of work centers can dramatically change the picture.

    A curious task based on observations of real processes in real firms.
    Возьмем два потенциально интересных проекта. Оба они будучи выполненными прямо сейчас приносили бы по $2 000 каждый месяц в течении полутора лет (от момента сейчас). Потом рынок изменится и прибыль исчезнет. Соответственно, чем позднее окажется дата завершения проекта, тем меньше денег удастся получить.Будем считать, что человеконеделя трудозатрат стоит фирме $2 000Первый проект может быть реализован в рамках одного департамента по единым руководством по схеме:Двухнедельный цикл разработки в группе программирования + двухнедельный цикл тестирования и отладки совместно группами тестирования и программирования.Циклы жестко связаны, временного зазора нет. Чистое время реализации – 4 недели, трудозатраты – 6 человеконедель, расходы - $12 000Второй проект предполагает участие сотрудников 4 разных отделов, по неделе каждый. Параллельно запускать нельзя, только последовательно. Чистое время реализации – 4 недели, трудозатраты – 4 человеконедели, расходы - $8 000.Вопрос: «Каковы ROI проектов?»Совершенно неправильный ответ:Для первого проекта доход: 18*2000 = $36000…Дальше можно не продолжать, потому как вменяемому менеджеру, который знает теорию, известно, что проекты мгновенно не делаются.Просто неправильный ответ:Первый проект будет закончен через 1 месяц, итого доход (18-1)*…Дальше можно не продолжать, потому как вменяемому менеджеру, который знает не только теорию, но и жизнь, известно, что проекты мгновенно не начинаются.…Правильный ответ:Первый проект не может быть выполнен за месяц. Разве что прилетят инопланетяне и «соберут урожай». И невозможно это потому что очередь на реализацию длинная и забита «Задачами, которые давно обещали», «Задачами, которые поставил Сам» и «Просто важными задачами». Реальное время до финиша - месяца четыре. Вот теперь можно считать. Доход – (18-4)*2 000 = 28 000, прибыль – 28 000-12 000=16 000, ROI=133%.Второй проект продлится год. Еще раз. Год. И это в лучшем случае. Если за это время ничего не изменится и проект не заморозят. Большую часть времени проект проведет в очередях ожидания. Да, это реальные наблюдения за реальными проектами в реальной фирме. Доход (18-12)*2000 = 12 000. Прибыль – 4 000, ROI – 50%У второго проекта меньшее ROI, и несравненно более высокие риски. От второго проекта я рекомендовал бы отказаться, в пользу первого.
    From observations: Chains of five to six work centers that are not connected by strict general management often make it meaningless to launch a project into production. It will become unnecessary before it is completed. Relatively stable chains with two work centers. Three are already having problems. The chain 1-> 2-> 1 is supposedly more stable than 1-> 2-> 3.

    Reduce the number of work centers in the value stream. Go even to increase direct costs. Stabilizing the flow and reducing the average lead time will more than cover these costs.

    You can refuse the selected analyst - refuse. You can refuse the selected tester - refuse. If you can’t refuse either dedicated testing or dedicated analysis, try combining the roles of a tester and a system analyst in one person.

    And if the system is not applicable?


    Then you need to switch to a full TOC. And as a visualization of the work management system, I want to try the priority change system proposed by Goldratt in the article “Standing on the shoulders of giants”. Only here is how to implement it in the "metal"? An interesting task for a system analyst: "Understand an idea, choose an engine and write a statement for customization." My instinct tells us that it’s quite possible to take a middle level tracking system as an engine. TrackStudio may come up.

    Instead of an afterword

    And try not to confuse the type of work flow of your group. Treating diarrhea or constipation is quite simple. But if you mix up the drugs, then the result may surprise you somewhat.

    If you mix up the type of flow and try to use an I-board for a T-type flow, then the result may surprise you less, but the consequences for the company will be significantly worse than if you mixed up the medicine for diarrhea.

    Also popular now: