Два слова о себе: бизнес-тренер, бизнес-консультант, занимаюсь консалтингом в сфере управления проектами и выстраивании бизнес-процессов на различных предприятиях. Консультировала и обучала 1С-франчайзи, выстраивала рабочие процессы производства на 1С:УПП и 1С:ERP, ну и много еще чего интересного. PMP, выпускник Таллиннской школы менеджеров Владимира Тарасова.
Лирическое отступление
… Японское обладает для россиян каким-то труднообъяснимым притяжением… Суши-рестораны стоят на каждом углу, поклонники уточняют в Ботаническом саду даты цветения сакуры, разнообразные выставки и мероприятия по японской культуре набирают популярность. Еще писатель-фантаст Сергей Лукьяненко описывал альтернативную реальность, в которой Россия решила войти в состав Японии. И, заметим, с лёту неплохо интегрировалась. А Герман Греф вдохновился идеей обучения топ-менеджеров Сбербанка японской методологии управления проектами P2M (Project and Program Management), которая считает управление проектами сочетанием науки и искусства - сродни каллиграфии или восточным единоборствам…
Вот и японская идея “Канбан-системы” в управлении предприятиями, придуманная на заводе “Тойота”, существенное время назад тоже пришла в нашу страну. И, естественно, при практическом применении претерпела изменения. В ходе своего преподавания в производственных и IT-компаниях я столкнулась с различными сложностями при внедрении Канбан-системы на российском рынке и хотела бы описать их здесь. Попробую поделиться историями успехов, провалов и трудностей, с которыми мне и моим коллегам приходилось столкнуться, занимаясь внедрением систем Канбан. Названия компаний-героев, по очевидным причинам, упоминать не буду.
2 слова про Канбан
Итак. Что такое Канбан-система в современном понимании? В двух словах - это метод управления, реализующий принцип «точно в срок» и способствующий равномерному распределению нагрузки между работниками.
Практика показывает, что в случае успешного внедрения системы и перестройки бизнес-процессов, продуктивность и эффективность работы возрастает в разы. Производственные предприятия у которых “получилось” - прямо не нарадуются, что эффективность и прибыльность возросла. Компании-внедренцы отмечают, что их работа оказывается более предсказуемой для руководства и заказчиков, и как результат улучшаются взаимоотношения и появляются новые контракты. В-общем, практически идиллия.
Чем меня радует идея Канбан-системы? В отличие от какого-нибудь Скрама и многих других фреймворков, предполагающих логику "весь мир насилья мы разрушим до основанья, а затем...", канбан - это подход эволюционный. Вы можете вообще ничего не менять в своих бизнес-процессах, просто добавить к ним доску, на которой наглядно видны задачи. Потом - минимизировать число незавершенных задач. Затем - договориться со смежниками, чтобы они не накидывали вам больше задач, чем вы можете переварить (все равно ведь вы не сделаете)... Далее - добавить обсуждения. что можно сделать лучше. Таким образом, относясь с уважением к тем ролям и процессам, которые уже есть в компании, вы сможете постепенно добиться тех целей, которые поставите перед собой - большая эффективность, большая прозрачность процессов, большая предсказуемость скорости работы и т. п.
Почитать на эту тему я рекомендую Дэвида Андерсона. “Канбан: Альтернативный путь в Agile”, ну а вкратце про идею попробую рассказать ниже.
Принципы Канбан
Так вот, очень многие компании с разным успехом пытались внедрить подобные системы в свою работу. Давайте разберемся, какими принципами эта самая канбан-система призывает руководствоваться. Ниже я попробую перечислить эти принципы от популяризатора современного Канбан-подхода Дэвида Андерсона. А дальше раскрою подробнее, что под каждым принципом имеется в виду, и на какие основные грабли наступают компании, пытаясь внедрить их на практике.
- Поток работ визуализирован. То есть, упрощенно говоря, все задачи, входящие в систему, наглядно видны на доске (а в идеале - на нескольких досках разных уровней - от предприятия, до отдела и сотрудника)
- Максимальное число задач, находящихся в системе, жестко лимитируется (при помощи WIP - work in progress limits). Канбан - это система вытягивающая. То есть новые задачи берутся в работу только когда на следующем этапе готовы их принять (а не когда поступили запросы от заказчиков).
- Управление потоком работ, измерение потока работ. Важно фиксировать и отслеживать время выполнения каждой задачи, это позволит в дальнейшем анализировать эффективность.
- Канбан - это система договоренностей. Возможность для самой команды гибко настраивать правила игры, ориентируясь на реальность, а не на теорию.
- Постоянное улучшение - как и в любом фреймворке Agile
Итак, а теперь подробнее. Принцип первый. Поток работ визуализирован.
То есть, упрощенно говоря, все задачи, входящие в систему наглядно видны на доске (а в идеале - на нескольких досках разных уровней - от предприятия, до отдела и сотрудника)
Канбан-доска - главный элемент канбан-системы. Доска бывает разной. Лучше всего - если это прямо физическая доска, на которой наклеены стикеры. Один стикер - это одна задача. И дальше стикеры гуляют по столбикам. Есть, допустим, столбик “очередь”, столбик “в работе”, столбик “тестирование”, столбик “готово” и т. п. Самые разные могут быть столбики - зависит от специфики проекта, выбора команды. Например, одна из команд посчитала, что для рабочих задач необходим отдельный статус “продолбана”. Причем попасть в него задача может откуда угодно - хоть из “очереди”, хоть из “в работе”, хоть из “тестирования”. Ну да, хотели как лучше, но - не получилось, и теперь делай-не делай - “продолбано”. Сурово, зато честно.
Стикеры могут содержать разнообразную уточняющую информацию: ответственного сотрудника, предполагаемую сложность задачи, наличие “блокираторов”, препятствующих выполнению задачи и т. п.
Доска не обязательно будет физической (хотя физическая по моему опыту работает лучше) - может быть и электронной.
Не буду здесь рекламировать те или иные программные продукты для Канбан-системы - их есть великое множество. Мобильное приложение Trello на телефоне, списки канбан в Pyrus, канбан-доска в Jira, даже к MS Project 2016 прикрутили надстройку Канбан - от тренда никуда не денешься. На сайте Инфостарта, кстати, есть вполне себе работающая конфигурация Канбан на 1С для платформы от 8.3.7. Знаю несколько 1С-франчайзи создавших канбан-доску на базе Битрикс-24 - список можно продолжать бесконечно. Но важно помнить, что сама по себе канбан-доска - это еще не Канбан-система! Это всего-навсего инструмент, который можно применять разными способами и с различной эффективностью. Чтобы мы могли с гордостью ощущать преемственность с “Тойотой”, требуется соблюдение еще целого ряда условий (о них в следующих статьях).
Дьявол в деталях или что может пойти не так?
Нам сказали, что глинтвейн - это горячее вино с фруктами и специями.
Мы решили его сварить, но из вина у нас была только водка,
из фруктов только лук, а из специй - черный перец…
(народный фольклор)
Кейс про слишком большую доску. Компания разработчик попыталась применять канбан-доску. Так как ИТ-компания, баг-трэкинг велся в Jira, то и канбан-доску там же реализовали. Все сделали “по учебнику” - все задачи включены, проводятся регулярные совещания… Но получился пшик. В чем оказалась проблема? Когда ко мне обратились за консультацией, выяснилось, что доска получилась слишком громоздкой. В команде было около 16 специалистов, каждый зачастую работал над несколькими задачами одновременно, колонок со статусами придумали так много, что доска не умещалась на экране… В итоге канбан-доска никак не помогала ответить на вопрос “Что у нас в работе и что нам нужно доделать?”, что никак не способствовало качественному ее заполнению. Решение оказалось вполне логичным - разделить большую команду на несколько маленьких, пересмотреть число столбцов в колонках, уменьшить число задач до разумного (но об этом подробнее поговорю уже в следующих частях)... Главное - обеспечить наглядность и удобство использования.
Кейс про слишком занятого руководителя. В производственной компании решили внедрить канбан-доску, выбрали программный продукт (Pyrus), описали бизнес-процесс, распределили задачи. Начали работать - на старт, внимание, марш! Все побежали, а исполнительный директор - нет. Не сложилось у него с использованием доски - слишком занят оказался другими, более срочными задачами. Все остальные тоже замедлили темп бега. Какой смысл заносить задачи на доску, если, как только потребуется участие руководства - задача подвиснет, и вопрос будет решен за пределами доски. Решение, очевидно - включенность руководства в процесс внедрения Канбан (в описанной ситуации оказалось проще передать руководство процессом другому руководителю, более готовому к регулярному менеджменту).
Кейс про разбегающиеся глаза. Компания-внедренец 1С никак не могла определиться, какой именно инструмент для контроля задач по проектом использовать: сложные задачи жили в Битрикс, простые - в Trello. Для ответа на вопросы “Какие задачи перед сотрудником стоят?”, “Что нам осталось сделать по этому проекту?”, “Что нужно делать в первую очередь?” нужно обратиться к нескольким местам сразу и соотнести их в уме. Как результат - глаза разбегались, и система оказалась неудобна при использовании на практике. Решение очевидно - все задачи, входящие в систему, должны быть доступны в одном месте, и видны наглядно. Критерий успеха - должно быть можно одним взглядом оценить оставшиеся работы, а не вникать в сложные графики и цифры.
Принцип второй. Максимальное число задач, находящихся в системе, жестко лимитируется (при помощи WIP - work in progress limits). Канбан - это система вытягивающая
Представьте себе плохо организованную школьную столовую, куда одновременно сбежалась толпа детей. Все хотят взять обед поскорее, поэтому возле повара, раздающего суп, толпится и толкается локтями кучка народу. Следующая кучка толпится около повара, раздающего второе и гарнир, и последняя - около взмыленного кассира. Вся эта толпа ужасно мешает друг другу, отвлекает раздающих. Сколько времени пройдет перед входом в столовую и получением обеда - предсказать невозможно - как повезет. В любом случае, много. Примерно так выглядит ситуация, к примеру, в ИТ-компании, когда на аналитиков, программистов и тестировщиков наваливают одновременно существенно большее количество задач, чем они могут проглотить за один раз. Заказчики требуют решить все как можно скорее, разработчики дергаются от менее срочной задачи к более срочной, попутно забывая, что было сделано по предыдущей… Опять же, когда будет выполнена та или другая задача, выданная в работу, - предсказать невозможно, ибо наверняка набежит что-то более срочное, и ваш запрос окажется отложенным в долгий ящик.
А теперь давайте добавим в нашу школьную столовую лимиты на количество одновременных работ. Work in progress limits. Одновременно к повару может подходить не более одного школьника, ну и еще одному разрешается смиренно ждать своей очереди. Толкотня около раздачи и кассы сразу прекратится - остальным детям придется ждать за пределами столовой (ну, или хотя бы за пределами зоны раздачи). Аналогично будет выглядеть ситуация и с организацией разработки.Для того, чтобы понять, что такое вытягивающая система, давайте попробуем танцевать от противного. Представим себе автомобильный завод, работающий по классическому “выталкивающему” принципу: задачи выполняются и “выталкиваются” дальше. Все сотрудники стараются выполнять свои работы как можно лучше. Поэтому цех, ответственный за производство колёс, уже выпустил 148 колёс, цех, ответственный за производство дверей - 27 дверей, а кузовной цех - 6 кузовов. За это же время цех сборки успел собрать только 3 автомобиля, а отдел продаж заключил контракт на продажу только 1 авто…
Что мы получим на выходе? Склады завалены избыточными полуфабрикатами и невостребованной продукцией, расходуется время и сырье, амортизируется оборудование, а прибыль, увы, несопоставима с затратами (и совсем не в ту сторону, куда хотелось бы)... А если в итоге окажется, что из-за недостаточного спроса нужно перейти на выпуск другой модели автомобилей, то полуфабрикаты, вполне возможно, окажутся на свалке. Это, еще раз повторюсь, система “выталкивающая” - задача выталкивается на следующий этап по мере готовности, от начала к концу производственной цепочки.
А теперь - как будет работать система “вытягивающая”. Здесь мы будем двигаться обратно, от конца к началу. Заключив контракт на новый автомобиль, отдел продаж сигнализирует на предыдущий этап, в сборочный цех - на складе осталась только 1 машина, приступайте к сборке следующего авто (но только одного - согласно установленному WIP-лимиту). Сборочный цех, в свою очередь командует в предыдущие цеха - забираю у вас 4 колеса, 4 двери и 1 кузов - можете выпускать следующую партию (опять же, не слишком много - строго согласно WIP-лимитам).
Похожая логика описана у Элияху Голдратта под именем “барабан-буфер-веревка”. Что мы получаем на выходе? Нет лишних работ, нет завала на складе, нет перепроизводства. И сразу понятно, где у системы “слабое звено” - и есть возможность бросить дополнительные силы, чтобы его усилить.
Кейс про “здесь пишем, здесь не пишем, здесь рыбу заворачиваем”. Довольно грустная история на производственном предприятии, но - увы, бывает. При попытках реализации на производственном предприятии Канбан-системы на базе конфигурации 1С, я столкнулась со следующей проблемой: некоторые по факту выполняемые проекты по документам значились как давно выполненные и поставленные, и финансовый директор категорически запрещал упоминать их в 1С со словами “при первой же аудиторской проверке нас всех посадят”. В результате получалось, что в системе учитывались не все задачи - часть была в системе, часть держали в уме. Ну и эффективность работы подобной системы легко можно предсказать. Решение - правильнее всего сказать, что не нужно допускать такой ситуации, когда реальность расходится с документами. Но, к сожалению, в тот момент такая рекомендация меня как консультанта прозвучал бы как совет “мышки, станьте ёжиками” из известного анекдота. Поэтому промежуточным решением на время устранения проблемы стало использование независимого от базы 1С программного обеспечения, в котором была указана вся полнота информации.
Кейс про “Зачем нам WIP-лимиты, мы сами с усами”. Типичная ошибка, когда WIP-лимиты устанавливаются слишком большими. Я сталкивалась с ситуацией, когда в подразделении из 7 человек “в работе” одновременно могло быть до 80 задач. Это то же самое, что отсутствие ограничений. Решение: Смысл WIP-лимитов как раз и заключается в том, что они должны быть заметными и чувствительными. Именно в этой ситуации можно избежать “завала работ”, обеспечить максимальную заметность “бутылочного горлышка”.
Кейс про “Хватай мешки, вокзал отходит”. Мне приходилось присутствовать на стэндап-совещаниях в командах, работающих по Канбан, где по несколько разработчиков в ответ на вопрос “Как я продвинулся в выполнении своих задач?” отвечали “Никак не продвинулся, так как весь день занимался срочными обращениями от клиентов, не зафиксированными на доске”. Срочные задачи решать, несомненно надо, но при такой организации процесса ни о какой предсказуемости и ни о каком контроле времени выполнения не может идти и речи. Решение: “пожарные” внеочередные задачи предусмотреть, несомненно надо. Но если мы хотим иметь какую-то предсказуемость, то число “пожарных” задач должно быть жестко лимитировано - например, не больше одной задачи в один момент времени. Например, в описанной ситуации решением стало выделение отдельного сотрудника в качестве первой линии техподдержки и освобождение остальных от необходимости решать задачи вне доски.
Принцип третий. Управление потоком работ, измерение потока работ.
Отражать задачи на доске, видеть, что происходит, видеть, какова ситуация у смежников, и какова судьба той задачи, которую мы выпустили в жизнь - это прекрасно, и это очень удобно.
Но кроме того, что это наглядно и удобно, главная ценность заключается в том, что мы все-таки хотим этим процессом управлять. Оценивать нашу продуктивность, понимать, как различные факторы влияют на производительность, ограничивать работы, если мы не можем справиться с ними и т. п.
Подробное описание логики работы Канбан-доски я оставлю за кадром, упомяну только самый информативный, по моему опыту, инструмент - кумулятивную диаграмму потока (накопительный график, показывающий, сколько задач перешло на какой этап в какой момент времени). По этому графику мы можем наглядно увидеть, как изменялась работоспособность команды со временем:
Принцип четвертый. Канбан - это прозрачная система договоренностей
Кейс про мифическую перегруженность.
Компания-разработчик оборудования, несколько проектов для разных заказчиков идут параллельно, на конструкторское бюро сыпется куча срочных задач одновременно. Все понимают, что конструктора не успеют в срок, потому что задач слишком много, а людей (особенно квалифицированных) категорически не хватает. Главный конструктор на предложение расставить приоритеты, только пожимает плечами - все задачи срочные, все заказчики важные. Что мы получаем в результате? Конструктора на любое возмущение “а почему эта задача еще не решена”, пожимают плечами и отвечают - “не можем же мы делать все одновременно”... И никакие вопросы и претензии к ним, очевидно, неуместны - ведь они действительно перегружены. И ответа на вопрос “когда что-то будет готово” от них добиться тоже невозможно - ведь задач слишком много!..
В данном случае решением стала четкая система договоренностей.
В работу может быть взято фиксированное количество задач, определяется логика, по которой берутся задачи по разным проектам (например: по 1 задаче из каждого проекта по-очереди, или FIFO – first in first out – первый пришел, первый ушел).
После успешного внедрения Канбан-системы коммуникации, как правило, происходит следующее:
- Ход работы наглядно виден всем участникам процесса. Нет отмазок в формате «мы ничего не делаем, потому что очень заняты другими проектами».
- Бизнес-подразделения получают лучшую предсказуемость, когда именно их задачи будут выполнены, и общее взаимодействие улучшается.
(Для приближения к истине, уточню, что внедрение канбан-системы в описанном случае стало не единственным условием изменений – для начала понадобились существенные кадровые перестановки).
Принцип пятый. Постоянное улучшение
Как известно, действительность далека от наших представлений о ней.
Я наблюдала, как работают с канбан-доской самые разные команды, и чем больше команд я наблюдаю, тем в меньшей степени я готова давать универсальные советы. Кто-то выносит все задачи на одну доску, кто-то размещает несколько независимых на одном экране. Кто-то подробно считает плановую трудоемкость каждой задачи, кто-то просто фиксирует число выписанных задач. Кто-то использует физическую доску с кнопками и стикерами (ее можно еще, например, применять и как деталь интерьера - перегораживать помещения посередине), кто-то обходится компьютерными приложениями. Все практики использования объединяет одно: изначальные предположения о том, какими будут WIP-лимиты, пропускная способность, системы договоренностей о выполнении задач и т. п. на практике приходится через некоторое время пересматривать.
Вот примеры изменений, решения о которых были приняты по итогам эксплуатации в разных компаниях
(я не призываю брать с них пример, у каждого - своя история!):
- В доску внесли различные доработки - расставлять приоритеты, раскрашивать цветами, визуализировать оценку трудоемкости и т. п.
- Через некоторое время работы, SCRUM решили заменить на Канбан (см. видео Олега Фогеля о гибких методах управления в компании 1С)
- По итогам анализа выполненных задач и их реальной трудоемкости, франчайзи решил отказаться от взятия небольших заказов по доработкам, сконцентрировавшись только на больших проектах.
- Электронную доску, реализованную в конфигурации 1С решили заменить на доску физическую (как выразился мой коллега, внедрявший Канбан в софтверной компании: "Мышечная память" при переклеивании стикера с задачей, в зависимости от колонки на доске стимулирует ответственность за взятую в работу задачу или вызывает удовлетворение от выполненной задачи". )
Список можно продолжать практически бесконечно...
Удачи в применении принципов Канбан!
Подробнее об управлении ИТ-проектами вы можете узнать на моих онлайн-курсах
