Что такое канбан и чем он полезен?

Жизнь МДФ истории на Канбан доске

Этот рассказ начинается с очереди МДФ историй, терпеливо ждущих на левой стороне Канбан доски. Они расположены рядом с целями так, что каждый может видеть, что эти МДФ помогают в достижении целей. Дизайнер пользовательского взаимодействия и бизнес аналитик, работая в паре, берут верхнюю историю из очереди и сдвигают все остальные вверх. Вытянутая история помещается в колонку «проработка в процессе». Они определяют необходимых для проработки стейкхолдеров и обсуждают с ними критерии приема готовности истории. Они встречаются с разработчиками, чтобы убедиться, что определенные ранее критерии понятны и достаточны для начала разработки. Все выражают свое согласие. Бизнес аналитик говорит «Значит я помещаю эту историю в буфер». «Нет нужды, мои активные слоты пусты — я сразу помещу историю в них и начну ей заниматься» — говорит разработчик. Использование системы Канбан вовсе не означает, что мы разрабатываем по модели водопада. Поскольку на доске все истории упорядочены слева направо, многие ошибочно считают, что Канбан исключает совместную работу над историей. Заметьте как бизнес аналитики и дизайнеры поработали вместе со стейкхолдерами и разработчиками. Они были ответственны за выполнение взятой истории, но это вовсе не означало, что они должны сделать все сами и не помогать никому с другими историями. В здоровом Канбан процессе есть множество мест, когда члены команды работают вместе. Продолжая работу над историей, мы видим, что она движется по доске слева направо, как только все, от кого зависит работа над историей на определенной стадии, делают все возможное, чтобы история вышла из этой стадии и пошла дальше. Они никогда не перебрасывают историю на следующую стадию, не выполнив своих обязательств. Они знают, что если перенести незавершенную историю в буфер, ответственные за следующую стадию просто не возьмут эту историю и отправят ее на доработку. Такой подход делает взаимодействие между членами команды и полноценное общение критически важными. Передвижение истории в обратном направлении – слева направо – вполне обычная ситуация. Чаще всего такое происходит, когда кто-то из следующей стадии считает, что качество работы предыдущих стадий можно немного улучшить. Проходит время, истории прорабатываются, перемещаются в разработку, а потом и в тестирование. Но вдруг случается маленький затык. Разработчики только что закончили свою историю и, подойдя к Канбан доске, чтобы перенести выполненную историю в буфер своей колонки, они видят, что в их буфере нет мест и колонка тестировщиков тоже забита под завязку. И что теперь? Разработчики идут к тестировщикам. — «Ребят, мы тут реально на всех фронтах загружены со своими историями. Свободные слоты появятся не раньше завтрашнего утра.» — «Хммммм», – говорят разработчики, – «А мы можем помочь тестировать?» — «Конечно вы можете!», – говорит тестировщик. — «С вашей помощью мы разгребемся уже к сегодняшнему вечеру». – Тестировщик улыбается, – «Только я не дам вам проверять сделанную вами же историю.»

Ограничения выявляют узкие места

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

Запуск изменений

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

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

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

Успехов!

По материалам статьи автора Канбан-метода Девида Андерсона https://www.linkedin.com/pulse/statik-systems-thinking-approach-implementing-kanban-david-anderson/

Кому вообще нужна оценка?

Когда вы фокусируетесь на том, насколько быстро вы можете реализовать историю, и у вас есть возможность измерить лишь этот параметр, оценки теряют свой прежний вес. На самом деле, многие практики Канбан полностью отказались от оценивания. Кто-то до сих пор оценивает истории, а потом использует полученные оценки вместе со временем полного цикла. Электронные таблицы в таком случае могут помочь вам рассчитать среднее время полного цикла для всех историй из прошлого, которые получали такую же оценку. Если вы придерживаетесь подобной практики, разместите справа от вашей Канбан доски табличку с соответствиями эстимейтов и времен полного цикла. Эта табличка будет отличным ответом на вопрос о реальной продолжительности разработки, который наверняка зададут стейкхолдеры сразу после получения эстимейтов: «А когда мы увидим это в версии на продакшне?». Если ваши стейкхолдеры похожи на моих, им не хочется знать, когда они получат эту конкретную функциональность, нет. Они хотят знать, когда получат все это. Я обнаружил, что если я помещаю каждую историю в электронную таблицу, задам каждой истории время начала и время конца, то я смогу получить интересную временную статистику. Например, я могу сказать, сколько в среднем историй выполняет команда за определенный отрезок времени. Если я вижу что в прошлом команда справилась с 22 историями за 3 неделями, то в среднем она выполняет 7.3 историй за неделю. Если у меня в беклоге висят около 100 историй, я смогу обоснованно полагать, что общее время разработки будет около 13/14 недель (100/7.3). Это «вчерашняя погода» для системы Канбан — по крайней мере, я рассчитываю ее так. Если я знаю, что за трехнедельный период было 15 рабочих дней и 5 разработчиков работали по 8 часов в день, то мы получаем 75 человеко-дней. Знание этого позволяет мне рассчитать среднее количество человеко-дней на одну историю: около 3.4 (75/22). Это число достаточно близко к Пи, что дает мне полагать, что оно верно ;). Это число, 3.4, называется фактором загрузки в экстремальном программировании.

Как устроен Kanban в проектах

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

Что такое канбан и чем он полезен?

Имена столбцов меняются в зависимости от проекта, но важно сохранять их последовательность ― это ключевая ценность Kanban, которую называют потоком

Что такое канбан и чем он полезен?

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

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

Что такое канбан и чем он полезен?

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

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

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

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

Шаг 8. Социализация системного мышления

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

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

Тем не менее, нереалистично полагать, что каждое вовлеченное лицо сможет поучаствовать в семинарах STATIK. 

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

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

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

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

Канбан доска — слева направо

1. Goals — цели

С самого левого края Канбан доски расположена колонка целей. Здесь мы найдем глобальные цели – крупные вещи, к которым мы стремимся и под которые поднастраиваем наше программное обеспечение. Оставляя цели на самом краю доски, мы фокусируем всех членов команды на одном: на достижении этих целей. Эта идея была взята у Арло Белши, который опытным путем определил, что размещение целей на левой стороне доски Канбан существенно снижает объем «мусора» на доске. Под «мусором» здесь понимается частое изменение приоритетов отдельных Канбан карточек.

2. Stories queue — очередь историй

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

3. Стадии разработки истории

Справа от очереди историй расположены колонки со стадиями разработки, через которые должна пройти история, чтобы считаться выполненной. Первая колонка часто используется для стадии прорабатывания истории. В командах разработки Yahoo она помечается как UED — user experience design. История должна находиться в этой колонке, если в данный момент осуществляется прототипирование UI или описание истории расширяется до необходимого для разработки уровня. У вас же может быть отдельная колонка для стадии, когда бизнес аналитики аккумулируют необходимые для разработки доменные знания. Следующая колонка часто используется для собственно разработки, а следующая за ней — для тестирования. Эти колонки не фиксированы. Вы должны обсудить с вашей командой те стадии, через которые проходит история, прежде чем помечаться как «выполненная». В некоторых компаниях отдельные колонки могут выделяться под написание документации или под подготовку инженеров поддержки для выпускаемой функциональности. Колонки — не роли в команде. Пускай часто и совпадает, что в отдельной колонке работают люди одной роли в команде, фокус должен делаться не на этом, а на выполнении истории и на том, что ей необходимо для выполнения. Например, если в вашей компании не используются бизнес-аналитики или дизайнеры пользовательского взаимодействия, используйте первую колонку для совместной проработки историй разработчиками и представителями бизнеса. Здесь же стоит определить критерии «готовности» истории. Просто взять и начать писать код (следующая стадия) — плохой ход, особенно если у вас нет критериев, по которым вы сможете оценивать готовность вашей работы. Каждая стадия разделена на две части: верх используется для историй, находящихся в разработке, а низ — для буфера историй. Когда работа над определенной стадией определенной истории заканчивается, историю перемещают из блока «в процессе» в буфер, где она будет дожидаться перевода на следующую стадию. У последней стадии нет буфера, поскольку эта стадия истории завершается при завершении истории. Когда мы ограничиваем количество невыполненной работы, мы устанавливаем рамки для общего количества историй в стадии, которое включает в себя как текущие истории, так и истории в буфере.

Сервисная модель

И как же он действует? – спросите вы. На деле всё очень просто. Канбан использует сервисную модель. Он ложится на сервис, который вы, как компания, оказываете клиентам. Например, разработка сайтов или проведение SMM-кампаний, или же прием платежей (если вы банк). Или же он может лечь на внутренний сервис. Например, на IT-отдел, обеспечивающий жизнеспособность организации. Или на отдел Маркетинга, обеспечивающий позиционирование и продвижение (и много чего еще) товаров и услуг компании. Он выискивает, подсвечивает сервисы внутри организации и вне ее, и дальше улучшает их. 

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

Что такое канбан и чем он полезен?
Рис. 2. Мем со странички Дэвида Дж. Андерсона.

Почему сервисная модель – это хорошо? Почему сервисный подход лучше, чем сильная и гибкая организационная структура?

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

Канбан – карточка

В переводе с японского канбан означает “сигнальная карта” (か ん ば ん на Хирагане) или “знак” или “большой визуальный щит” (看板 на Канджи). 

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

Рис. 1. Фото канбана у японского магазина.

В переводе с китайского канбан – это глагол «смотреть на доску» (или буквально «интерпретировать карикатуру на обложке книги»).

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

Что такое канбан и чем он полезен?
Рис. 2. Фото канбана для входа в сад.

Вам наверняка хорошо знаком этот подход. Он используется на парковках в торговых центрах и вокзалах. 

И еще пример. Канбаном в IT часто называют карточки или стикеры на досках, используемые для обозначения работ команды.

С точки зрения строгой терминологии это неправильно: канбан – это свободный слот (ёмкость), куда можно вытащить карточку, а не сама карточка. Но для тех, кто только начинает осваивать метод, определение “канбан = карточка” проще для понимания.

Что такое канбан и чем он полезен?
Рис. 3. Фото командной доски для управления потоком задач.
Что такое канбан и чем он полезен?
Рис. 4. Фото карточки с командной доски. 

Вы наверняка видели что-то подобное у себя в офисе, если работаете в большом банке или телекоме или другой большой компании. 

Чем отличаются Kanban и Scrum

Kanban часто путают или объединяют с гибкой методологией Scrum. Но это не совсем так.

KANBAN SCRUM
Нет совещаний Есть совещания
Нужна отправная точка Не нужна отправная точка
Могут работать узкопрофильные команды Только кроссфункциональная команда
Последовательные и плавные перемены Кардинальные перемены
В команде нет разделения на роли В команде есть разделение на роли

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

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

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

3 простых шага для командной эффективности

Шаг 1

Напишите все шаги предстоящего проекта. Под проектом (условимся понимать) любую цель. Это  может быть любая рабочая задача – скажем, выполнить план продаж своего отдела/магазина. Или масштабировать бизнес. Предположим,  увеличить эффективность бизнеса. Возможно, например, личная задача – подготовить ребенка к школе.

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

Например: Увеличить эффективность бизнеса.

  1. Определить текущее состояние:
  2. Собрать статистику
  3. Оцифровать цель и сроки
  4. Выделить ресурсы

И т.д. пишите, все, что приходит в голову. Можно пока просто в ежедневнике. Выбирайте тот формат, который удобен.

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

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

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

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

Я всегда пишу в 2 вариантах – в таблице Excel и на стикерах (кратко). Так же и мы будем делать. Если кому-то удобно, можно и на бумаге, конечно, но я советую в Excel. Это просто, всегда под рукой, не надо искать бумагу, где записать, и формат поддерживается всеми устройствами.

Шаг 2

Расположите задачи по приоритетам

Для того чтобы определить приоритет задайте себе вопросы:

  • Что приведет быстрее к цели?
  • Без каких шагов цель не будет достигнута?
  • Какая задача даст максимальный эффект для достижения цели 

Шаг 3

Составьте пошаговый план, если задачи сложные. Вот теперь начинаем работать непосредственно с доской Канбан.

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

Всё.

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

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

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

Что такое канбан

Канбан (с японского — «бирка», «карточка», «знак») — японская система оптимизации и управления проектами и производством. Её придумали и впервые внедрили на заводах Toyota в начале 1960-хх годов. Постепенно преимущества системы оценили и в других странах. Сейчас она применяется для управления проектами по всему миру.

Основа канбана — использование специальных карточек, на которых отражается вся информация о процессе работы. Работники Toyota на этих карточках отмечают каждый этап производства: сколько сырья выдано, сколько деталей сделано, кто отвечает за проверку деталей на брак, куда деталь будет передана дальше и так далее.

Система канбан позволяет:

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

Подготовка задач для очереди

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

Напри­мер, заказ­чи­ку нужен сайт. Для его созда­ния нуж­но сде­лать несколь­ко после­до­ва­тель­ных вещей: при­ду­мать дизайн, свер­стать, натя­нуть на систе­му управ­ле­ния кон­тен­том, под­го­то­вить кон­тент и всё про­те­сти­ро­вать. Каж­дая из задач тре­бу­ет каких-то ввод­ных. Эти ввод­ные нуж­но собрать, согла­со­вать с кли­ен­том, сфор­му­ли­ро­вать чёт­кое зада­ние:

  • Каким дол­жен быть дизайн? На что похож? Какие тех­ни­че­ские огра­ни­че­ния?
  • Для каких стра­ниц нужен кон­тент? О чём он дол­жен сооб­щать?
  • Какие воз­мож­но­сти нуж­ны в систе­ме управ­ле­ния кон­тен­том?
  • Кто и как будет под­дер­жи­вать этот сайт?

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

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

В реаль­но­сти ред­ко быва­ет, что зада­ние сфор­му­ли­ро­ва­но пря­мо иде­аль­но, поэто­му коман­де всё-таки при­хо­дит­ся уточ­нять. Чем боль­ше такой рабо­ты на них выпа­да­ет, тем мед­лен­нее дви­га­ет­ся раз­ра­бот­ка.

Виды

Тарный канбан

Представляет собой единицу тары с жёстко закреплённой канбан-биркой, со следующей информацией о содержимых деталях:

  • наименование;
  • артикул;
  • количество;
  • адрес получателя;
  • адрес отправителя.

Система заказа деталей и узлов по тарному канбану осуществляется следующим образом: по мере окончания деталей в первом тарном канбане оператор убирает его с рабочего места на нижний ярус стеллажа (нижний ярус стеллажа является местом для складирования заказов оператора и получением заказов транспортировщиком) и работает из второго. Транспортировщик забирает порожнюю тару и, поскольку к таре прикреплён канбан, осуществляется обратная связь между оператором и кладовщиком через транспортировщика для заказа материалов.

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

Карточный канбан

Представляет собой карточку, имеющую:

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

Один из вариантов цветовой гаммы:

  • Синий — производственный канбан (между производственной линией и зоной выдачи);
  • Красный — складской канбан (между складом и зоной выдачи);
  • Зелёный — межцеховой канбан (между цехами, производствами, заводами и так далее).

Программный канбан

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

Рабочий процесс

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

На этом эта­пе за каж­дой зада­чей закреп­ля­ет­ся испол­ни­тель и могут вво­дить­ся лими­ты на коли­че­ство выпол­ня­е­мых задач — если на ста­дии «Дизай­на» сто­ит лимит «2», то толь­ко два маке­та могут нахо­дить­ся на руках у дизай­не­ров.

Выпол­нен­ную зада­чу испол­ни­тель дол­жен отправ­лять на про­вер­ку и толь­ко в слу­чае отсут­ствия заме­ча­ний она может перей­ти на сле­ду­ю­щую ста­дию.

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

Что такое канбан и чем он полезен? Коли­че­ство рабо­чих ста­дий и лими­ты задач коман­да опре­де­ля­ет само­сто­я­тель­но. Глав­ное пра­ви­ло: не брать новую зада­чу, пока не выпол­не­на теку­щая, и не отка­зы­вать­ся от теку­щей, пока она не пере­ве­де­на на новую ста­дию. Как имен­но опре­де­лять сте­пень готов­но­сти зада­чи — решай­те сами

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

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

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

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

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

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

Что такое канбан и чем он полезен?

Стратегия внедрения системы

Стратегия внедрения предполагает осуществления 6 шагов:

  1. Обеспечение следующих процессов от поставок предыдущих процессов.
  2. Изготовление на предыдущих стадиях только того, что изъято для последующих.
  3. Обеспечение перемещения только качественных изделий без дефектов.
  4. Создание выровненного производства.
  5. Закрепление за каждой деталью канбана.
  6. Снижение со временем числа канбанов.

Все этапы внедрения можно разделить на 3 фазы:

№ 1. Планирование в рамках системы

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

№ 2. Циркуляция канбанов

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

№ 3. Усовершенствование производства

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

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