Мой бизнес - Франшизы. Рейтинги. Истории успеха. Идеи. Работа и образование
Поиск по сайту

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

Метод создал инженер концерна Toyota. Звали его Тайити Оно (Taiichi Ono). Изначально термин звучал как «камбан», что с японского переводится как рекламный щит или доска. В латиницу слово пришло с ошибкой (kanban). В середине 1950-х годов Тайити начал формировать специфическую схему , которая исключала явные непроизводственные потери. Создатель был вдохновлен системой управления в супермаркетах – на полках находились только те товары, которые нужны покупателям. Без лишних складов и запасов. Первые эксперименты с системой организации труда начались в 1959 году. В 1962 году компания полностью перешла на новую методологию. Концерн придерживается ее до сих пор.

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

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

Как выглядит процесс

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

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

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

  • Ведение карточек для каждой отдельной задачи. Это главное нововведение системы помогает визуализировать прогресс и иметь всегда информацию о проекте под рукой.
  • Ограничение задач на одной ступени производства. Внедрение системы подразумевает строгое определение максимального количества задач на одном этапе. В этом случае можно будет четко определить, на каком участке появляется «затор». При разработке программного обеспечения, если задачу нельзя решить на определенном этапе, она возвращается в начало (backlog). Выбирается задача с максимальным приоритетом.
  • Непрерывное производство. Задачи появляются непрерывно, что обеспечивает постоянное производство без пауз и простоя.
  • Постоянная модернизация. Все карточки постоянно анализируются экономической службой, и ищутся пути оптимизации процесса.

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

Сферы применения

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

  • Группы поддержки по эксплуатации программ, где важнее не производственный план, а скорость реагирования на задачу.
  • При тестировании ПО.
  • Группы по разработке программ.

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

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

Плюсы и минусы системы

Как и любая другая система управления проектами, kanban имеет свои преимущества и недостатки.

Начнем с сильных сторон:

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

Слабые стороны:

  • Внедрение программы возможно только в команды с численностью от 5 человек.
  • Не подходит для матричных структур организации предприятия. Работает исключительно на прямом производстве.
  • Не подходит для долгосрочных стратегий.
  • Система вряд ли сможет прижиться в команде, где сотрудники не ознакомлены с функциями друг друга. Только при таком условии можно легко найти заминки в производстве и быстро их исправить.
  • Отсутствие жестких дедлайнов также может быть и минусом. Если продукция должна быть готова строго к определенному времени, система «канбан» может не сработать.

Управление проектами – сложный процесс. Поэтому, выбирая методологию, адаптируйте ее под себя. Прямое следование постулатам, основанным более 60 лет назад на машинном производстве, может в определенный момент привести в тупик. Обдумайте основные правила и усовершенствуйте свою версию управления – и вперед, к покорению новых вершин!

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

Наверное, всё это очень сложно?

Нет. В системе канбан всего два главных правила:

  1. Нужно визуализировать свой рабочий процесс. Это помогает увидеть вашу реальную загрузку и, если нужно, изменить её.
  2. Необходимо ограничить количество задач, над которыми вы работаете активно. Часто для иллюстрации этого правила приводят в пример жонглёра: чем больше предметов он берёт в руки, тем выше шанс что-то разбить.

Визуализировать - значит повесить доску со стикерами?

Не обязательно. Вы можете использовать любой удобный для вас вариант: доску, холодильник с магнитами, блокнот, специальные приложения и так далее. Главное, чтобы вы расчертили минимум три столбца: «Сделать» (To do), «Делаю» (Doing), «Сделано» (Done). Их нужно заполнить стикерами или надписями, чтобы в любой момент увидеть, какая у вас в данный момент загруженность.

Также можно добавить колонку «Ожидание» для несрочных задач. Либо любые другие колонки, например «Отдых» (с задачами «заказать пиццу», «покататься на лыжах» и так далее).

Работает это просто: вы переносите стикеры (или записи) из одной колонки в другую по мере выполнения задач.

И что это мне даст?

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

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

Как определить, сколько задач я могу выполнить?

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

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

Чем персональный канбан отличается от обычного списка дел?

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

Обычный список дел не интерактивен, не даёт обратной связи, не снимает стресс, так как не структурирует рабочий день.

Какие приложения заменяют доску со стикерами?

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

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

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

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

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

  • На рабочее место вовремя;
  • В необходимом количестве;
  • С нужным качеством;
  • В соответствующей упаковке.

Цель метода канбан

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

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

Правила эффективной системы канбан

На опыте компании Toyota сформированы следующие правила использования – канбан:

  • Количество товара, которое изымается с каждого предшествующего этапа, должно быть равно указанному в карточке;
  • На этапе непосредственного изготовления изделий производится столько, сколько указано в сопровождающем их информационном носителе;
  • Без карточек изделия не должны производиться, ведь именно карточная система позволяет проконтролировать и выявить издержки производства, избыточное перемещение товаров;
  • Продукция всегда связана с карточкой. Есть карточка – есть заказ на изготовление продукции;
  • Бракованные, дефектные изделия при установлении, что они не соответствуют уровню качества, тут же изымаются из производственного процесса;
  • Чем меньше карточек используется на производстве, тем они становятся более чувствительными, что позволяет вскрыть существующие проблемы и проконтролировать объемы используемых запасов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. Исполнители из нижнего потока изымают ровно столько деталей из склада, сколько указано в канбане
  2. Представители верхнего потока тоже поставляют запчасти строго в соответствии с карточками
  3. Ничто не производится или не перемещается без канбана
  4. Канбан должен быть всегда прикреплен к деталям
  5. Бракованные запчасти не используются в системе
  6. Уменьшение количества карточек канбан делает управление более чувствительным к переменам. Но без крайней необходимости менять устоявшееся количество карточек не стоит.
Канбан — это «вытягивающая» система. В ней создается баланс между постоянным потоком, который устраняет затраты на ожидание, и минимальным количеством работы в процессе (РВП), что снижает риски перепроизводства. РВП регулируется с помощью карточек: их количество зафиксировано, а инструкции в них направляют исполнителей нижнего потока.

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

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


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

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

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

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

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

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


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

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


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

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

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

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

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

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

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

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

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

Скрам, как и 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

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

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