Как работает канбан. Канбан-метод и Канбан Тойоты – это одно и то же? Как использовать, чтобы быть аджайл

При помощи системы канбан регулируется количество выпускаемой на заводе продукции. Канбан называют сигнальной системой бережливого производства, поскольку канбан управляет производством так же искусно, как мозг и нервная система (первая сигнальная система) - телом человека. Главное преимущество системы канбан заключается в предотвращении перепроизводства. Цель системы канбан - производить только необходимую продукцию в требуемом количестве и в нужное время.

В японском языке слово «канбан» обозначает «бирка» или «знак». Канбаном называется контрольная карточка, используемая при вытягивающем производстве . Это наряд-заказ на выполнение работы, который сопровождает любое изделие. Каждая такая карточка прикрепляется к детали или узлу, информируя о том, откуда поступила та или иная деталь и куда она должна быть перемещена дальше. Таким образом, канбан является информационной системой, которая объединяет завод в единое целое, устанавливает связи между различными процессами и координирует поток создания ценности в соответствии с потребительским спросом.

Вытягивающее производство и устранение потерь

В системе канбан на предыдущих этапах производства выпускается ровно столько деталей, сколько было изъято последующим процессом. Закончив один процесс, рабочие изымают детали у предыдущего процесса. Они берут столько, сколько нужно, и тогда, когда нужно. Сигналом для изъятия служит заказ потребителя. Такая система производства называется вытягивающей .

В основу вытягивающей системы положена идея супермаркета В супермаркете покупатели приобретают, что выставлено на полках. Полки пополняются по мере того, как продукты и товары раскупаются. Применительно к бережливому производству метод «вытягивания» противопоставляется методу «выталкивания», при котором количество произведенной продукции зависит от прогнозируемых продаж.

Вытягивающая система обеспечивает более гибкий подход к производству, с тем чтобы производить только необходимую продукцию в требуемом количестве и в нужное время. Такой подход позволяет избежать перепроизводства - основного источника потерь. Конечной целью в вытягивающей системе является достижение нуля канбанов, когда устраняется незавершенное производство. Другими словами, именно заказ покупателя запускает непрерывный производственный поток. В идеале в вытягивающей системе производственный процесс всегда совершенствуется.

Как повысить эффективность системы канбан?

Канбан лучше всего внедрять тогда, когда в компании уже применяют вытягивающую систему и практикуют мелкосерийное производство, а именно поток единичных изделий и ячеечное производство . Если эти методы работают, канбан превращается в информационную систему, при помощи которой ячейки образуют единое целое, а процессы становятся более согласованными. Если канбан применяют только в отдельных цехах, может возникнуть определенная дезориентация из-за смешения «вытягивающего» и «выталкивающего» аспектов производственной системы. Применение системы канбан позволяет выявить причины, порождающие потери, а именно - перепроизводство. В том случае, когда внедрение вытягивающей системы не является особой целью завода, решение этих проблем может быть весьма затруднено. Если спрос на продукцию компании непостоянен (это в особенности касается сезонных продуктов) и производственный процесс вряд ли выиграет от внедрения мелкосерийного производства, применение системы канбан может быть неэффективным, а порой и ненужным.

Так как количество канбанов в вытягивающей системе постепенно снижается, на поверхности в первую очередь оказываются проблемы, связанные с длительностью переналадки. Чтобы сократить время переналадки, следует сразу же применять методы улучшения, тогда время такта будет восстановлено, а смешанный мелкосерийный производственный поток можно будет регулировать при помощи канбанов. Если не внедрить методы, способствующие сокращению времени переналадки, то завод не сможет реагировать на изменения потребительского спроса, а главной целью внедрения системы канбан и вытягивающего производства является как раз адекватное реагирование на колебания спроса.

Автономное обслуживание - это еще один важный элемент вытягивающего производства. Поддержание работоспособного состояния станков, выполнение планового технического обслуживания, равно как и остальные элементы всеобщего ухода за оборудованием, весьма существенны для успешного функционирования системы канбан.

Канбан - это передовой метод визуального управления, успех которого во многом зависит от дисциплины рабочих и понимания важности начинаний, заложенных системой 5S. Надежным фундаментом, обеспечивающим прочность системы вытягивающего производства, является визуальное рабочее место. Правильно организованное рабочее место начинается с внедрения основ 5S и содержания рабочего места в порядке, установки подвесных знаков, постоянных улучшений, инициируемых всеми рабочими.

Интеграция системы канбан с MRP II

Проблемы интеграции системы канбан с MRP II (системой планирования материальных потребностей) рассматриваются во многих книгах, поэтому мы не будем останавливаться на этом вопросе. MRP II - это компьютеризованная система, применяемая не столько для реагирования на изменения потребительского спроса, сколько для оценки ресурсов, которые требуются для производства. Другими словами, сфера применения MRP II - выталкивающее производство. Хотя некоторые компании пытаются перейти к вытягивающему производству путем интеграции системы MRP И с системой канбан, в этой книге канбан рассматривается сам по себе как механизм внедрения истинно вытягивающего производства.

«Пилотное» или повсеместное внедрение системы канбан

Очень важно решить, как канбан будет внедряться - повсеместно или в нескольких цехах. Помните, что канбан - это система, которая организует в единое целое все процессы на заводе, привязывая их к потребностям потребителей. Если вы предпочтете внедрять канбан только в нескольких цехах, это может снизить общий эффект и нивелировать идею системы канбан как таковую.

Однако внедрять канбан в отдельных цехах действительно возможно, даже при отсутствии непрерывного производственного потока. В этом случае канбан позволит выявить проблемы в производственном потоке. Когда количество используемых канбанов уменьшается, требуется больше времени на переналадку, возникают задержки с доставкой продукции, оборудование простаивает, растут запасы незавершенного производства, и все это мешает выпуску продукции. В подобных случаях следует обратиться к другим методам бережливого производства: системе 5S, SMED, автономному обслуживанию и оптимальному расположению оборудования для того, чтобы применить ячеечное производство и наладить поток единичных изделий. Это необходимо, чтобы канбан стал тем, чем он на самом деле является: механизмом коммуникации, необходимым для поддержания вытягивающего производства .

С другой стороны, если вы уже внедрили систему 5S, быструю переналадку и автономное обслуживание и стремитесь перейти к вытягивающему производству, мы настоятельно рекомендуем распространить систему канбан по всему заводу. В этом случае система канбан синхронизирует все производственные процессы, соединив их в одну цепочку, и задает общий темп всему производству в соответствии со временем такта - «пульса» потребительского спроса. Канбан поможет выявить проблемные места в цехах, которые могли бы остаться незамеченными. С системой канбан бережливое производство становится реальностью.

Как канбан может улучшить вашу деятельность?

Нас всех учили работать эффективно: чем больше выпускаем продукции, тем лучше трудимся. Так нам всегда говорили. Мы приняли это утверждение как руководство к действию: «больше» значит «лучше». Однако при бережливом способе производства в вытягивающей системе, использующей канбан, это высказывание неактуально.

В системе канбан принцип «больше, еще больше», как и выпуск продукции только по той причине, что ее есть из чего выпускать, ведет к возникновению самых громадных потерь, то есть перепроизводству. В системе канбан рабочие производят продукцию только тогда, когда получат сигнал. Канбан - это сигнальная система, и требование об изготовлении продукции поступает от предшествующего процесса начиная с заказа потребителя.

Мария Денисенко, эксперт по финансам и закупкам, руководитель направления по развитию приоритетных проектов компании ScrumTrek , рассказывает о своем опыте внедрения метода в финансовом подразделении одного из российских министерств. Эту колонку стоит прочитать и представителям бизнеса, которые намерены внедрить методологию в свои проекты.

Что мне предстояло сделать?

Заступив на службу в подразделение закупок Министерства цифрового развития, связи и массовых коммуникаций РФ в далеком 2013 году, я встала перед выбором процесса организации деятельности целого структурного подразделения. Организовать работу необходимо было «с нуля» в соответствии с новыми требованиями законодательства. На смену Закону № 94-ФЗ приходил новый закон о контрактной системе – Закон № 44-ФЗ.

Передо мной стояли две задачи. С одной стороны, необходимо было четко выстроить систему организации осуществления закупок в соответствии с новыми нормами. А это значит: новые процессы, новые документы, новые электронные системы, новые люди. С другой стороны, необходимо было наложить все эти нововведения на текущие реалии организации. Ведь некие процессы в организации уже существовали и даже работали. В наличии была гора локальных актов (более двадцати пяти).

Работал штат специалистов – целый отдел. Но не было структуры. Не было эффективного процесса улучшений. Отсутствовало понимание цели деятельности. Специалисты были перегружены.

После достаточно длительного изучения всех имеющихся документов, регулирующих деятельность закупочного подразделения (должностных регламентов сотрудников и положений о структурных подразделениях, приказов о создании закупочных и приемочных комиссий, приказов о закупках и о заключении контрактов) и опросов работников министерства я пришла к выводу, что для начала весь процесс необходимо визуализировать. Понять и разобраться в том, что есть сейчас.

Какие были проблемы?

В итоге оказалось, что, с одной стороны, есть множество важных процессов, которые не зарегламентированы. Например, передача контракта на подписание, сроки рассмотрения документов по жалобе, процесс обоснования и планирования закупки. А каждому специалисту в сфере государственного и муниципального заказа известно, что ошибка в любом из этих значимых действий может привести к наложению на конкретного сотрудника административной ответственности.

С другой стороны, существует множество процессов, которые совершенно не относятся к деятельности закупочного структурного подразделения, но исполняются его работниками. Например, формирование первичных требований к техническому заданию, участие в исполнении контракта.

С функциональными заказчиками (заказывающими структурными подразделениями министерства) работники закупочного подразделения практически не общались. И этот факт приводил к существенному увеличению и усложнению любых совместных или последовательных процессов. Руководство было нагружено массой микроменеджерских функций, напрочь закрывающих возможность стратегического развития направления. Постоянное подписание приказов, проверка контрактов, разруливание проблем при взаимодействии закупочного подразделения и иных, участвующих в закупках подразделений.

Поток задач был настолько бессистемным и большим, что каждый из сотрудников «с успехом» оправдывал пункт трудового контракта, где было указано, что государственный гражданский служащий работает «в рамках ненормированного рабочего дня».

Что я сделала?

Еще не зная, что в продвинутом мире существует канбан-метод, я интуитивно уже следовала его принципам и использовала практики.

Визуализировала процессы

Это было сложно и достаточно долго. Некоторые процессы необходимо было насилу вытаскивать из сотрудников смежных подразделений. Некоторые стали явными уже в процессе работы. Для этого мне приходилось общаться с работниками от уровня топ-1 до уровня рядового специалиста, визуально отсеивать лишний функционал, структурировать систему. Стали явно видны узкие места, лишние документы, потребности в новых сотрудниках.

Разъясняла руководству принципы «вытягивающей системы»

И параллельно строила процессы таким образом, чтобы заказывающие подразделения министерства, по заявкам которых осуществлялись закупки, четко понимали разницу между принятыми и отложенными обязательствами. С каждым днем WIP-лимит «выделенной полосы» становился все более вменяемым, пока не пришел к стандарту в одну единицу. От «срочно все» мы не сразу перешли к приоритизации и вытягиванию. Далеко не сразу.

Руководству сложно объяснить, почему его задача до сих пор не взята в работу. Для большинства руководителей висящие в «in progress» неделями задачи – это лучше, чем реально выполняемая на текущий момент работа и стоящие в очереди для принятия обязательств другие задачи.

Приоритизация и ограничение потока, на мой взгляд, оказались самыми сложными задачами. Это министерство, говорили мне, здесь важно все. Здесь все срочно. И каждый руководитель заказывающего структурного подразделения, а их на тот момент было около двенадцати, имеет право ставить задачу для подразделения закупок. После года масштабной информационно-разъяснительной работы мы пришли к тому, что приоритеты закупочного подразделения выстраивались мной. И редкие звонки руководителей уровня топ-1 (заместителей министра) приводили к изменению приоритетности или добавлению задач в выделенную полосу.

Работала с руководством и командой в части «устаканивания» понимания того, что значит для нашего сервиса «соответствие предназначению»

Это была ломка системы. Люди, работающие на небольшом участке «технической», как они считали, работы большого министерства, трудно приходили к пониманию цели и качества. Почти всю команду пришлось сменить. Более того, отбор специалистов являлся залогом успеха дальнейшего развития направления. Поэтому я подходила к нему очень серьезно, учитывая, в том числе и особенности отбора, стандартизированные в Законе 79-ФЗ.

Смена сотрудников – достаточно частое явление при изменении подходов к организации деятельности. Новые задачи, новые особенности работы – все это не каждый работник готов выдержать. Около года после смены ряда сотрудников мы перешли к новой системе работы: от закрытого кабинета – к опенспейсу с постоянным обсуждением и встречами, от неотвеченных звонков – к клиентоориентированности, от оправданий за совершенные ошибки при подготовке документов – к командной работе над ними. И всех последующих сотрудников в закупочное подразделение я уже подбирала в соответствии с новой процессной парадигмой.

Работала с источниками неудовлетворенности в текущей системе и с внедрением циклов обратной связи

С ними я призываю работать постоянно и плотно. Это основной двигатель прогресса, на мой взгляд. Реализация принципа эволюционного развития. До этого собирать «обратную связь» от стейкхолдеров в данной организации было просто не принято. Кроме как «жалобами» обратную связь никто не называл. И все эти жалобы тонули в кулуарах руководства навсегда, выливаясь лишь в личные выговоры сотрудникам.

Фидбэк мы получали регулярно по организованным каналам (служебные запросы на уровень руководства, полуформальные встречи, звонки контроля качества). Мы превратили это в систему. И в результате такой совместной работы структурировали процессы контрактной службы министерства, в которую по последним данным входило около 80 работников.

Взращивание проявлений лидерства также было непростой задачей

Ситуация осложнялась тем, что с учетом специфики работы на каждом из сотрудников лежала не просто ответственность, а ответственность, подкрепленная административной ответственностью (любые нарушения в сфере закупок квалифицируются в соответствии с соответствующей статьей КоАП). В системе, где из «бонусов» есть только благодарность министра, а из ответственности от 3 до 50 тысяч рублей за каждое нарушение быть «лидером» никто не горел желанием.

Сначала я давала небольшие задания в малых группах. Позже коллеги стихийно увеличивали задействованных в решении вопроса работников. Мы проводили семинары и мозговые штурмы. Организовывали внутренние проекты обучения сотрудников. Взращивали институт наставничества, когда закупочное подразделение пополнилось новыми сотрудниками.

Вскоре совместная работа стала привычной. Теперь почти любая задача выполнялась (подстраховывалась или контролировалась) несколькими сотрудниками. Снизилось количество ошибок (почти в пять раз), повысилась скорость работы на каждом из участков. Мы стали уходить домой вовремя, исключая сезонные периоды формирования бюджета и планирования.

При формировании правил для улучшения показателей мы также сталкивались с определенными трудностями

После визуализации процесса и обкатки работы с учетом WIP-лимитов руководством было принято решение зарегламентировать процессы (ну, куда же без этого в госоргане). И любые последующие изменения необходимо было проводить через согласования. Но, следуя общей парадигме гибкого подхода, такие согласования проходили достаточно безболезненно. И частично решались на моем уровне.

Нами был сформирован регламент контрактной службы. Это процессный документ, который был создан после визуализации процессов и их увязки с законодательными нормами, а также после перераспределения функционала. Он был живой, подвергался постоянным изменениям по итогам отладки процессов, а также в случае изменения законодательных норм.

Принцип вытягивания задач значительно осложнялся на первоначальном этапе законодательными особенностями осуществления закупок

Эти процессы имеют жесткие сроки и четкий процесс осуществления, изложенный в Законе № 44-ФЗ. Все зарегламентировано: формирование и публикация плана закупок и плана-графика закупок, сроки публикации извещения об осуществлении закупки и сроки размещения документации, сроки рассмотрения заявок участников и сроки подписания контракта. Соотнести все это с WIP-лимитами и выработать идеальную скорость поставки – задача не из легких. А с учетом постоянного изменения законодательства без постоянного эволюционного развития подобная система вообще работать не будет.

Что в итоге?

Спустя время всю целостность знаний и наработанный опыт мне удалось систематизировать, углубить и расширить в процессе обучения канбан-методу. Открылась важность применения некоторых, ранее не учтенных процессов. Существенно пополнилась линейка метрик. Пришло понимание широты применимости метода. До конца выстроилась система основных принципов (теперь я их не просто понимала, я с легкостью могла сделать их явными для других).

Исходя из более чем пятилетней практики работы могу сделать однозначный вывод о том, что в финансовом блоке канбан может эффективно работать. Более того, он существенно облегчает работу при взаимодействии финансового блока со смежными структурными подразделениями.

Представленный выше набор принципов и практик вполне возможно использовать как краткое руководство по внедрению канбан в финансовом блоке. При этом хочу обратить внимание, что в этой статье мы не затрагивали подробные аспекты системного подхода к внедрению канбан (S.T.A.T.I.K.). Эту тему мы разберем в отдельной статье.

К сожалению, мне не удалось масштабировать процессы на более широкий круг сервисов. Но в блоках, смежных финансовым подразделениям, применение канбан-метода также возможно и эффективно, даже с учетом особенностей госсектора. И в скором времени мы поделимся с вами результатами подобного кейса.

Вы когда-нибудь пытались собрать вместе группу людей, чтобы создать продукт или запустить проект? В качестве бонусов: жесткий дедлайн, объемное техзадание и несговорчивый заказчик. Получилось? Если да, то дальше можете не читать.

Управлять командой нелегко. Особенно в digital. Нужно организовать работу так, чтобы качество продукта было на высоте, дедлайны соблюдались, команде было комфортно, а заказчик остался доволен. Важно не допускать конфликтов и постоянно развивать команду.

Волшебной таблетки, чтобы разом решить все проблемы, не существует. Но есть методы и системы, которые помогут упростить процесс. Один из них ― Kanban.

Что такое Kanban

Kanban ― это метод улучшения процессов разработки и часть agile-философии. В его основе ― «Манифест гибкой разработки программного обеспечения».

Манифест гибкой разработки ПО

Цель Kanban ― получать готовый качественный продукт вовремя. Давайте разбираться, как этого добиться.

Kanban начинается с визуализации, чтобы процесс работы был на виду у команды. Для этого используют специальную доску и набор карточек или стикеров.

Доска ― это обязательный элемент для гибкой методологии. Она есть в Scrum, есть и в Kanban. Каждый член команды получает к ней доступ в любое время и может видеть, на каком этапе находится задача.

Доска может быть реальной или виртуальной: можно использовать простую пробковую или программы вроде Trello.

Kanban-доска ― универсальный инструмент, который можно подстроить под любой процесс и применить в любой области. Например, составить список дел.

Сначала нужно проанализировать процесс работы и разделить доску на столбцы, которые отражают этапы создания продукта. Например, для процесса создания IT-проекта этапы могут быть такими:

Названия столбцов можно менять в зависимости от проекта, но важно сохранять их последовательность. Доска должна полностью отражать процесс создания ценности, который в Kanban называют потоком.

Kanban-карточки ― это задачи, которые команда перемещает по доске в зависимости от их состояния. Количество карточек можно менять. На карточке или стикере пишут название задачи и прикрепляют в начало доски.

C помощью kanban-доски команда может вести несколько проектов одновременно, использовать карточки разных цветов: один цвет ― один проект.

Как помогает визуализация

Получить результат точно в срок возможно, если контролировать нагрузку. Для этого нужно ограничить количество задач.

В одном столбце kanban-доски одновременно находится столько задач, сколько команда реально выполняет в установленные сроки. Например, в состоянии «Проектирование» одновременно ― не больше двух задач, а в графе «Тестирование» ― только одна. Количество команда выбирает в зависимости от своих возможностей.

Пример

Разработчик еще не закончил с текущей задачей, а ему уже поступила следующая. Он не успевает и тормозит всю работу.

Решение: прекратить передавать задачи в разработку и дать программисту время закончить работу.

Важно найти баланс: выбрать темп работы, который удобен команде и не вредит срокам проекта. Для этого в Kanban учитывают время выполнения каждой задачи. Так команда понимает, что занимает больше времени, а что ― меньше, и может правильно организовать работу.

Пример

На этапе тестирования продукта возникли трудности и нужно больше времени.

Решение: выяснить, какую часть работы можно сделать быстрее, не потеряв в качестве. Или сотрудника, который свободен и поможет тестировщику.

На доске отражаются все процессы, а команда их анализирует и устраняет слабые места. В Kanban это называется управление потоком .

Чтобы использовать Kanban, мало просто повесить доску с карточками. Команда должна знать правила, по которым работает.

Это еще и про прозрачность процесса: когда работа - на виду и всем понятен результат.

Важна сплоченность, постоянное совершенствование продукта и развитие сотрудников. Команда в Kanban ― единый механизм. Если кто-то не справляется, то страдает общее дело. Работу планируют на доске, весь процесс на виду, поэтому каждый может увидеть свой вклад и ценность для проекта.

В Kanban смешались принципы agile-методологий и lean-мышления. Здесь нет жестких правил и кардинальных перемен, но есть принципы, на которые можно опираться.

Как не путать Kanban и Scrum

Kanban часто путают или объединяют с гибкой методологией Scrum. Чтобы с вами такого не произошло, давайте посмотрим, в чем основные различия.

Scrum ― это гибкая методология управления проектами, а Kanban ― метод улучшения любой методологии.

Нет совещаний

Нужна отправная точка

Могут работать узкопрофильные команды

Последовательные и плавные перемены

В команде нет разделения на роли

Есть совещания

Не нужна отправная точка

Команда, уже внедрила Scrum, но хочет продолжать совершенствовать процесс. Тут снова поможет Kanban.

Совсем не важно, какую методологию разработки использует команда, но чтобы внедрить Kanban, нужна отправная точка.

Как внедрить Kanban

Если вы решили использовать Kanban, то придется запастись терпением и научиться самодисциплине. Не стоит настраиваться на радикальные перемены и внедрять все практики сразу. Kanban ― это про последовательные и плавные улучшения. Возможно, вам не понадобится использовать все инструменты, чтобы добиться нужного результата.

Подведем итоги

Теперь вы знаете, что такое система Kanban, чем отличается от Scrum и как ее можно использовать. И уже готовы проверять все в деле. Теория ― это хорошо, но нужна практика. И лучше практиковаться без опасений, что одно неверное движение может навредить делу. Поэтому , который прокачает вас в управлении проектами. Вы сможете внедрять в свою работу любые agile-системы и будете уверены в результате.

Система канбан начала свой путь в 1950-х годах на производственных линиях корпорации Toyota, после чего перекочевала в офисы и стала важным инструментом для проектных менеджеров.

Бескрайняя гибкость практики и ее возможности для самоорганизации персонала позволили добиваться эффективности там, где другие подходы не работали. Это тот случай, когда визитной карточкой системы стала сама карточка — она утвердилась как внутренняя валюта в организациях, которые внедрили канбан.

Происхождение

Как и концепция бережливого производства (Lean), система канбан была разработана менеджерами Toyota. Автора системы, японского инженера Тайити Оно, вдохновил принцип работы американских супермаркетов, где покупатель сам выбирал нужные себе товары. Роль «супермаркета» в корпорации Toyota выполнил склад.

Там сигнальными карточками — а именно так дословно с японского языка переводится «канбан» — обменивались работники, собственноручно регулируя производственный процесс.

Карточки крепились к таре с деталями. На таких бирках указывалась информация о номере и количестве деталей, какой отдел их отправляет и куда они должны прибыть.

Работник, который непосредственно занимался монтажом и сборкой машин — нижний поток — забирал детали из тары, на которой был прикреплен «канбан» с запросом для склада. Карточка снималась и вместе с пустым ящиком передавалась транспортировщиком на склад. Там другой работник уже подготовил новую тару с запчастями, на которой крепился производственный «канбан» — бирка с информацией о произведенных запчастях.

Производственный «канбан» заменялся на «канбан» с запросом для склада и отправлялся на производственную линию запчастей — верхний поток. Поэтому производилось именно то количество деталей, которое указывалось в карточке. Тара с новыми запчастями относилась транспортировщикам на монтажную линию.

Принципы канбана

Менеджеры Toyota сформулировали 6 системообразующих правил:

Исполнители из нижнего потока изымают ровно столько деталей из склада, сколько указано в канбане
Представители верхнего потока тоже поставляют запчасти строго в соответствии с карточками
Ничто не производится или не перемещается без канбана
Канбан должен быть всегда прикреплен к деталям
Бракованные запчасти не используются в системе
Уменьшение количества карточек канбан делает управление более чувствительным к переменам. Но без крайней необходимости менять устоявшееся количество карточек не стоит.

Канбан — это «вытягивающая» система. В ней создается баланс между постоянным потоком, который устраняет затраты на ожидание, и минимальным количеством работы в процессе (РВП), что снижает риски перепроизводства. РВП регулируется с помощью карточек: их количество зафиксировано, а инструкции в них направляют исполнителей нижнего потока.

Правило обязательно прикрепленной бирки работает как закон сохранения энергии.

Лимит РВП составляется в пропорции к количеству канбан-карточек, которое рассчитывается в зависимости от уровня продаж и статистической вариантности в текущих процессах. Максимальное количество бирок — та самая «энергия» в системе — закрепляет верхний уровень РВП в любое заданное время. РВП также ограничивается принципом вытягивания: скорость производства верхнего потока зависит от скорости работы нижнего.

На графике видно, что одним из базовых элементов системы является культура Кайзен. Автономный процесс и стандартная вариантность освобождает менеджмент от постоянного управления, поэтому он может сосредоточиться на улучшении работы сотрудников.

Применение канбан в IT

Система канбан, продолжая приносить пользу на производственных конвейерах, проникла в сферу программного обеспечения.

Только карточки, на которых указаны информация о сроках выполнения, описание или номер процесса и имя исполнителя, теперь прикрепляются не к таре с запчастями, а к доске с расчерченными колонками:

Бэклог — задачи, которые надо выполнить
Задачи, которые в данный момент разрабатываются
Задачи, которые выполнены, но еще не переданные тестировщикам
Задачи, готовы к передаче отделу тестирования
Задачи, которые проходят проверку проект-менеджером (ПМ)
Выполненные задачи

Над колонками обычно пишется число — лимит , указывающий на максимальное количество процессов в ней. Лимит бэклога высчитывается в зависимости от ведущего времени. Если в системе 5 работ в процессе, и завершение каждой из них в среднем занимает 1 день, то и бэклог можно ограничить лимитом 5.

Структура выше не является строгой — в зависимости от специфики проекта могут быть добавлены импровизированные колонки. Нередко встречается канбан система, в которой требуется определить критерии готовности задачи перед ее выполнением. Тогда появляются две колонки, которые в английском языке называются specify (уточнить параметры) и execute (взяться за работу).

Еще может добавляться колонка с приоритетной очередью. Когда исполнитель освобождается, то он должен опустошить именно эту колонку с задачами, а затем браться за другие.
Задачи, которые не были выполнены, либо возвращаются в бэклог, либо вычеркиваются из схемы.

Канбан не поощряет многозадачность, поэтому устанавливается лимит процессов для одного исполнителя.

Выполненная работа предпочтительнее нескольким начатым.

Браться за вторую работу можно, если первая была заблокирована.
Время для выполнения задачи должно быть сбалансировано. Слишком короткий срок отразится на качестве. Чересчур растянутый лимит растрачивает ресурсы команды и повышает стоимость процесса.

Почему повсеместно используется канбан-доска, а не, например, планшеты или огромный монитор? Как отвечают на этот вопрос поклонники системы, обычная доска имеет два преимущества: она проста и обеспечивает визуальный контроль. На ней легко вносить изменения, и она обеспечивает тактильное и социальное взаимодействие между участниками команды.

Преимущества и недостатки канбан

Kanban имеет такие достоинства:

Гибкость планирования. Команда концентрируется только на текущей работе, приоритет задачи выставляется менеджером.
Высокое вовлечение команды в процесс разработки. Благодаря постоянным собраниям, прозрачности процессов и возможностям самоорганизации работники сплачиваются и проявляют искренний интерес.
Меньшая продолжительность цикла. Если несколько человек обладает схожими навыками, продолжительность сокращается, если же только один — появляется узкое место. Поэтому сотрудники должны делиться знаниями и тем самым оптимизировать продолжительность цикла. Тогда вся команда сможет взяться за работу, которую забуксовала,и восстановить плавный поток.
Меньше узких мест. Лимиты РВП позволяют быстро находить узкие и проблемные места, которые появились из-за дефицита внимания, людей или навыков.
Наглядность. Когда все исполнители имеют доступ к данным, то узкие места легче заметить. Kanban-команды, помимо самих карточек, обычно используют два общих отчета: графики управления и совокупного потока.

На практике система отлично себя показывает в сферах неосновного производства:

группы поддержки программного обеспечения или службы поддержки.
Канбан хорошо работает при управлении стартапами без четкого плана, но где активно продвигается разработка.

Канбан имеет и недостатки:

система плохо работает с командами численностью более 5 человек
он не предназначен для долгосрочного планирования.

Отличия от Скрама

Скрам, как и agile kanban, является гибкой методикой и тоже часто применяется в IT-сфере. Различия между ними не очевидны на первый взгляд. Существует много схожестей, например, наличие бэклога в обоих подходах.

	Скрам	Канбан
Темп	Повторяемые спринты фиксированной продолжительности	Непрерывный процесс
Выпуск релиза	В конце каждого спринта после одобрения проектным менеджером (владельцем продукта)	Поток продолжается без перерывов или на усмотрение команды
Роли	Владелец продукта, Scrum-мастер, команда разработчиков	Команда под руководством ПМ, в некоторых случаях привлекаются тренеры по agile kanban
Главные показатели	Скорость команды	Ведущее время
Приемлемость изменений	В ходе спринта изменения нежелательны, так как могут привести к неверной оценке задач	Изменение могут случиться в любой момент

Примеры применения в IT

Сразу с Microsoft: Дебют Канбан в сфере программных разработок

Использование принципов канбана в сфере информационных технологий началось чуть более 10 лет назад. Дэвид Андерсон, один из главных популяризаторов канбана для программных разработчиков, консультировал в 2005 году компанию Microsoft. Там были недовольны работой своего отдела — XIT Sustained Engineering, который устранял ошибки во внутренних приложениях. К началу отчетного года этот отдел был худшим в своем департаменте. Бэклог превысил допустимый размер в 5 раз, а время на обработку одного запроса — ведущее время — обычно занимало 5 месяцев.

Новый ПМ с помощью консультаций Андерсона за 9 месяцев повысил продуктивность проблемного отдела на 155%. Ведущее время теперь составляло 5 недель, бэклог вернулся к нормальному размеру, а своевременное выполнение задач утвердилось на уровне 90%. Все эти результаты были достигнуты с минимальным привлечением новых работников, персонал продолжал теми же методами исправлять программные ошибки — поменялись лишь подходы к организации работы.

Интересный факт: программный менеджер Драгос Думитриу, который взялся переломить ситуацию в XIT, как раз был увлечен книгой Андерсона. К своему удивлению, он встретил идеолога программного канбана в самой компании Microsoft, куда тот накануне устроился. Думитриу попросил Андерсона помочь со своей задачей, и последний согласился применить принципы своей книги на практике.

Думитриу застал отдел, состоявший из трех разработчиков и трех тестировщиков, у которых в бэклоге накопилось 80 запросов. Сам ПМ был назначен временно, так как требования к вакансии включали умение работы с технологией ASP, администрирование с помощью SQL Server и знание MS Project Server. Начальство видело на этой должности «технаря», который умеет программировать, должен составлять отчеты и прогнозировать загрузку бэклога. Как считалось тогда, проблема отдела будет выявлена, если собрать внушительный массив данных. Думитриу же таким «технарем» не был.

Однако начав вместе с Андерсоном анализировать работу XIT, он быстро выявил ключевые факторы, которые негативно влияли на скорость отдела:

На прогнозирование последствий (ROM), к которым приведет исполнение запроса, уходило слишком много времени. И разработчику, и тестировщику приходилось тратить полный рабочий день, чтобы провести необходимые вычисления, проверку кода и заполнить документацию. В среднем ежедневно приходил один запрос. По подсчетам ПМ, на ROM уходило 40% от производительности отдела;
Приоритет отдавался запросам с большей стоимостью. XIT получал финансирование за счет стоимости заказа. Приоритетность запросов обсуждалась каждый месяц на встрече менеджеров отдела с заказчиками — менеджерами других отделов. При распирающем бэклоге при текущий скорости, когда за месяц обрабатывались лишь 6-7 запросов, постоянно менялись приоритеты других заявок из-за проходящего времени. Многие из них были отложены на внушительное «потом», не равное даже следующему месяцу.
На стадии ROM отсеивалась половина запросов. Часть из них были слишком большие и переквалифицировались в проекты с передачей другим отделам, другие являлись слишком дорогими и попросту отменялись. Некоторые запросы не брались в разработку из-за того, что их внедрение оказалось бы слишком долгим. Таким образом, 40% производительности отдела уходило на анализ запросов, 50% из которых были забракованы. Около 15-20% рабочих ресурсов тратилось впустую.
Подготовительная работа по запросу могла длиться месяцами, прежде чем начиналось внедрение. Вычисления на стадии ROM могли за это время затеряться или забыться. Особенно, если внедрением занимался не тот разработчик, который начинал анализ.

Канбан-решения для проблемного отдела Microsoft

Думитриу и Андерсон настояли в беседе с руководством и менеджерами-заказчиками на отказе от стадии ROM. Расчеты производились непосредственно перед внедрением и тем же исполнителем, то есть оставались «свежими».
Приоритизация запросов проводилась не в ходе ежемесячных совещаний, а по ситуации, посредством телефонных звонков или электронных писем. 80 задач в бэклоге рассортировали в зависимости от заказчиков. Последних попросили выделить главные запросы, которые нужно выполнить в первую очередь.
Финансирование XIT стало фиксированным.
Стоимость запросов перестала браться в расчет.
ПМ ввел буферы на канбан-доске. Разработчики брали работу из двух зон: одобренные и выполненные задачи. В буфере находились 6 запросов, 5 брались в работу. Тестировщики выбирали из буфера «ожидает тестирования». Некоторые задачи, которые не требовали изменений в коде, попадали туда, минуя разработчиков. Разбив запросы на однозадачные процессы, ПМ мог лучше контролировать ситуацию, а также обеспечить прозрачность для заказчиков. Введение буферов уменьшило ведущее время. Заказчики в условиях предсказуемой системы стали лучше определять, чей запрос должен попасть в буфер следующим.
По слишком большим или дорогим запросам решение принималось сразу. Если разработчик подтверждал, что он готов выполнить задачу в течение 15 дней или изменения стоят того, то запрос брался в работу вне зависимости от размера или стоимости.
Понаблюдав за потоком в отделе, ПМ пришел к выводу, что структуру штата стоит изменить в пользу разработчиков, которые были больше загружены работой. Изменения проводились в соотношении 2:1: в XIT стали работать 4 разработчика и 2 тестировщика.

По итогу 2005 года производительность отдела выросла на 155%. Чтобы еще улучшить работу XIT, туда привлекли двух сотрудников: одного разработчика и одного тестировщика. Количество запросов в бэклоге снизилось до 10, а один разработчик стал стабильно обрабатывать 11 заявок за квартал. В среднем за квартал завершались 56 запросов против 11 ранее. Стоимость запросов упала с $7500 до $2900.

Применение в компании Corbis

Добившись успеха в Microsoft, Андерсон в 2006 году приступил к решению новой сложной задачи. Теперь он работал в Corbis — другой компании Билла Гейтса, который тогда еще не покинул MS. Одним из видов деятельности Corbis было лицензирование фотографий. На тот момент это был второй крупнейший в мире фотосток с базой около 3,5 тыс. снимков.

Задачей Андерсона было ускорить главные релизы от компании. Интервал между их выходами составлял три месяца и мог вырасти еще больше. Только обсуждение плана релиза отнимало у менеджмента две недели. Требовалось наладить выпуск второстепенных релизов или обновлений каждые две недели. При этом ключевые ресурсы должны были быть направлены на работу над главным проектом.

В офисе Corbis появилась канбан-доска, у которой Андерсон ежедневно беседовал с коллективом. Целью ПМ было улучшить визуальный контроль над процессами, способствовать самоорганизации и большей персональной ответственности исполнителей. Также система канбан была направлена на уменьшение надзора со стороны менеджеров и увеличение производительности.

Кроме разноцветных карточек и графиков, на доске появилась «мусорная корзина» — в нее отправлялись задачи слишком большого размера.

Фото из официальной

A Kanban System for Sustaining Engineering on Software Systems by David J Anderson

Система kanban прояснила, когда поток перестает быть плавными и где возникают задержки, так называемое бутылочное горлышко. Быстрые обсуждения с командой помогали выявить текущие проблемы. Например, тестирование длилось 3 дня, что негативно отражалось на сроке релиза. Трое сотрудников объединились и нашли способ, как уменьшить время до одних суток.

Бутылочное горлышко — участок схемы или алгоритма работы компании, где ограничение ресурсов или продуктивности людей резко сокращает проходимость потока задач. Нехватка рабочих рук, плохой интернет или директор в отпуске блокирует или замедляет выполнение задач.

Лимиты для канбан-карточек дважды устанавливались эмпирическим путем. В колонке «готово для разработки» лимиты были увеличены. Также появилась новая колонка — «готово для тестирования». Многие запросы для нижнего потока были некорректно сформулированы, вызывая лишние затраты времени. Поэтому ПМ исследовал работу верхнего потока и нашел ошибки.

Обработка запросов могла занимать 100 дней, но релизы все равно стали выходить раз в две недели, как и планировалось. Решение по содержимому выпуска принималось за 5 дней до публикации. Практика подсчетов, как и в случае с отделом XIT Microsoft, была отброшена в пользу продуктивности. Приоритет задачам расставлялся согласно «стоимости задержек» или готовности ресурсов.

Канбан система не только помогла добиться Андерсону поставленной цели, но и улучшила настроения в коллективе. Благодаря совместным обсуждениям и наглядности процессов у сотрудников утвердилось доверие друг к другу. Также персонал приобщился к кайзену, то есть практике постоянного улучшения.

Или TPM, кажется, что канбан больше прижился в среде информационных технологий, нежели на производстве. Неужели микроклимат офиса благотворнее производственной среды?

Широкое распространение в непроизводственной сфере деятельности человека позволило открыть массу способов применения этого инструмента. Однако внесло также немало неразберихи в понимание его основ. Кто-то подразумевает карточку, кто-то – доску, а кто-то – проектный менеджмент… Давайте попробуем разобраться в том, что такое канбан, как он работает и какие типы канбанов существуют.

Иллюстрированный глоссарий по бережливому производству Чета Марчвински и Джона Шука дает следующе определение:

Из этого определения следует, что канбан используется исключительно в вытягивающей системе и служит для:

Передачи сигнала (или указания) на производство продукции.
Передачи сигнала (или указания) на перемещение продукции.

Первый называют канбаном производства или изготовления, второй – перемещения или изъятия. Есть еще и третий тип, о котором авторы не упомянули в глоссарии – сигнальный канбан. В отличие от первых двух, сигнальный канбан не дает указания на производство или перемещение, пока количество канбанов в системе не достигнет определенного уровня.

Давайте посмотрим, как это работает.

Канбан перемещения или изъятия

программное обеспечение

Типичный канбан изъятия может содержать:

Информацию о поставщике или предыдущем процессе:

название процесса или поставщика;
место размещения (локация на производстве или полка на складе).

Информацию о детали:

наименование детали;
артикул (номер, код):

Информацию о следующем процессе – заказчике:

название следующего процесса (заказчика);
место размещения (локации на производстве или полка на складе);

Используется на участке между супермаркетом и процессом, который из него потребляет продукты. Чаще всего используется там, где в процесс вступает большое количество SKU (артикулов). Является сигналом для того, чтобы переместить определенный артикул на производственную операцию:

Канбан производства или изготовления

На карте потока создания ценности отражается следующим символом:

Типичный канбан производства может содержать:

Информацию о месте хранения:

название склада или супермаркета;
место размещения (локация на производстве или полка на складе);
тип упаковки/контейнера/тары.

Информацию о продукте:

наименование детали;
артикул (номер, код);
количество деталей в партии/упаковке/таре.

Информацию о процессе-поставщике:

название процесса;
производственный цех или линия;
название/номер участка, ячейки или машины.

Используется на участке между супермаркетом и пополняющим его процессом. Является сигналом для запуска производства определенного артикула и пополнения супермаркета.

Сигнальный канбан (еще называют треугольным)

На карте потока создания ценности отражается следующим символом:

Такой канбан чаще всего используется для управления потоком партий (перемещением нескольких упаковок/тар/контейнеров с деталями) в процессах с небольшим количеством SKU (артикулов). По той же причине на табличках не указывают информацию, различая их по цвету. С другой стороны, содержание карточки можно определить по своему усмотрению:

Типичный сигнальный канбан используется в комбинации с доской:

Главным отличием сигнального канбана от предыдущих типов является то, что потребление детали А и Б не является сигналом для производства или поставки следующего контейнера. Вместо этого треугольные карточки перемещается на специальную доску, где накапливаются до определенной отметки. Сигналом для производства или поставки каждой детали является, когда количество соответствующих карточек достигает отметки – триггера:

Сигнальный канбан используется вместо производственного в процессах с коротким временем цикла и длительной переналадкой. Таким образом, производство получает сигнал только тогда, когда минимальный уровень запаса достигнут, а сам канбан контролирует поток материала партиями.

Вот как выглядит коммуникация в вытягивающей системе с помощью различных типов канбана:

Как видите, канбан позволяет управлять и производством, и перемещением материалов в малых и больших партиях. При этом нет необходимости или обстоятельств, ограничивающих использование только одного типа канбанов. Вы всегда можете приспособить любой тип так, чтобы максимально легко управлять информационными и материальными потоками.