При помощи системы канбан регулируется количество выпускаемой на заводе продукции. Канбан называют сигнальной системой бережливого производства, поскольку канбан управляет производством так же искусно, как мозг и нервная система (первая сигнальная система) - телом человека. Главное преимущество системы канбан заключается в предотвращении перепроизводства. Цель системы канбан - производить только необходимую продукцию в требуемом количестве и в нужное время.
В японском языке слово «канбан» обозначает «бирка» или «знак». Канбаном называется контрольная карточка, используемая при вытягивающем производстве . Это наряд-заказ на выполнение работы, который сопровождает любое изделие. Каждая такая карточка прикрепляется к детали или узлу, информируя о том, откуда поступила та или иная деталь и куда она должна быть перемещена дальше. Таким образом, канбан является информационной системой, которая объединяет завод в единое целое, устанавливает связи между различными процессами и координирует поток создания ценности в соответствии с потребительским спросом.
Вытягивающее производство и устранение потерь
В системе канбан на предыдущих этапах производства выпускается ровно столько деталей, сколько было изъято последующим процессом. Закончив один процесс, рабочие изымают детали у предыдущего процесса. Они берут столько, сколько нужно, и тогда, когда нужно. Сигналом для изъятия служит заказ потребителя. Такая система производства называется вытягивающей .
В основу вытягивающей системы положена идея супермаркета В супермаркете покупатели приобретают, что выставлено на полках. Полки пополняются по мере того, как продукты и товары раскупаются. Применительно к бережливому производству метод «вытягивания» противопоставляется методу «выталкивания», при котором количество произведенной продукции зависит от прогнозируемых продаж.
Вытягивающая система обеспечивает более гибкий подход к производству, с тем чтобы производить только необходимую продукцию в требуемом количестве и в нужное время. Такой подход позволяет избежать перепроизводства - основного источника потерь. Конечной целью в вытягивающей системе является достижение нуля канбанов, когда устраняется незавершенное производство. Другими словами, именно заказ покупателя запускает непрерывный производственный поток. В идеале в вытягивающей системе производственный процесс всегда совершенствуется.
Как повысить эффективность системы канбан?
Канбан лучше всего внедрять тогда, когда в компании уже применяют вытягивающую систему и практикуют мелкосерийное производство, а именно поток единичных изделий и ячеечное производство . Если эти методы работают, канбан превращается в информационную систему, при помощи которой ячейки образуют единое целое, а процессы становятся более согласованными. Если канбан применяют только в отдельных цехах, может возникнуть определенная дезориентация из-за смешения «вытягивающего» и «выталкивающего» аспектов производственной системы. Применение системы канбан позволяет выявить причины, порождающие потери, а именно - перепроизводство. В том случае, когда внедрение вытягивающей системы не является особой целью завода, решение этих проблем может быть весьма затруднено. Если спрос на продукцию компании непостоянен (это в особенности касается сезонных продуктов) и производственный процесс вряд ли выиграет от внедрения мелкосерийного производства, применение системы канбан может быть неэффективным, а порой и ненужным.
Так как количество канбанов в вытягивающей системе постепенно снижается, на поверхности в первую очередь оказываются проблемы, связанные с длительностью переналадки. Чтобы сократить время переналадки, следует сразу же применять методы улучшения, тогда время такта будет восстановлено, а смешанный мелкосерийный производственный поток можно будет регулировать при помощи канбанов. Если не внедрить методы, способствующие сокращению времени переналадки, то завод не сможет реагировать на изменения потребительского спроса, а главной целью внедрения системы канбан и вытягивающего производства является как раз адекватное реагирование на колебания спроса.
Автономное обслуживание - это еще один важный элемент вытягивающего производства. Поддержание работоспособного состояния станков, выполнение планового технического обслуживания, равно как и остальные элементы всеобщего ухода за оборудованием, весьма существенны для успешного функционирования системы канбан.
Канбан - это передовой метод визуального управления, успех которого во многом зависит от дисциплины рабочих и понимания важности начинаний, заложенных системой 5S. Надежным фундаментом, обеспечивающим прочность системы вытягивающего производства, является визуальное рабочее место. Правильно организованное рабочее место начинается с внедрения основ 5S и содержания рабочего места в порядке, установки подвесных знаков, постоянных улучшений, инициируемых всеми рабочими.
Интеграция системы канбан с MRP II
Проблемы интеграции системы канбан с MRP II (системой планирования материальных потребностей) рассматриваются во многих книгах, поэтому мы не будем останавливаться на этом вопросе. MRP II - это компьютеризованная система, применяемая не столько для реагирования на изменения потребительского спроса, сколько для оценки ресурсов, которые требуются для производства. Другими словами, сфера применения MRP II - выталкивающее производство. Хотя некоторые компании пытаются перейти к вытягивающему производству путем интеграции системы MRP И с системой канбан, в этой книге канбан рассматривается сам по себе как механизм внедрения истинно вытягивающего производства.
«Пилотное» или повсеместное внедрение системы канбан
Очень важно решить, как канбан будет внедряться - повсеместно или в нескольких цехах. Помните, что канбан - это система, которая организует в единое целое все процессы на заводе, привязывая их к потребностям потребителей. Если вы предпочтете внедрять канбан только в нескольких цехах, это может снизить общий эффект и нивелировать идею системы канбан как таковую.
Однако внедрять канбан в отдельных цехах действительно возможно, даже при отсутствии непрерывного производственного потока. В этом случае канбан позволит выявить проблемы в производственном потоке. Когда количество используемых канбанов уменьшается, требуется больше времени на переналадку, возникают задержки с доставкой продукции, оборудование простаивает, растут запасы незавершенного производства, и все это мешает выпуску продукции. В подобных случаях следует обратиться к другим методам бережливого производства: системе 5S, SMED, автономному обслуживанию и оптимальному расположению оборудования для того, чтобы применить ячеечное производство и наладить поток единичных изделий. Это необходимо, чтобы канбан стал тем, чем он на самом деле является: механизмом коммуникации, необходимым для поддержания вытягивающего производства .
С другой стороны, если вы уже внедрили систему 5S, быструю переналадку и автономное обслуживание и стремитесь перейти к вытягивающему производству, мы настоятельно рекомендуем распространить систему канбан по всему заводу. В этом случае система канбан синхронизирует все производственные процессы, соединив их в одну цепочку, и задает общий темп всему производству в соответствии со временем такта - «пульса» потребительского спроса. Канбан поможет выявить проблемные места в цехах, которые могли бы остаться незамеченными. С системой канбан бережливое производство становится реальностью.
Как канбан может улучшить вашу деятельность?
Нас всех учили работать эффективно: чем больше выпускаем продукции, тем лучше трудимся. Так нам всегда говорили. Мы приняли это утверждение как руководство к действию: «больше» значит «лучше». Однако при бережливом способе производства в вытягивающей системе, использующей канбан, это высказывание неактуально.
В системе канбан принцип «больше, еще больше», как и выпуск продукции только по той причине, что ее есть из чего выпускать, ведет к возникновению самых громадных потерь, то есть перепроизводству. В системе канбан рабочие производят продукцию только тогда, когда получат сигнал. Канбан - это сигнальная система, и требование об изготовлении продукции поступает от предшествующего процесса начиная с заказа потребителя.
Что такое методология kanban и как она позволяет выполнять задачи в поставленные сроки?
В условиях постоянной многозадачности и и большого количества заказчиков у любой системы рано или поздно случается перегруз. Сроки начинают срываться, ожидания не оправдываются, а система превращается в хаос. Сегодня я предлагаю познакомиться с такой методологией, как kanban. Данный подход обещает эффективно распределить ресурсы и решить все наши проблемы. Проверим.
Минутка истории kanban
Основа идеи kaban была придумана компанией Toyoyta Motors. Производитель автомобилей нес большие потери из-за неправильного распределения запасов и мощностей на производственной линии. Часть этапов производства могла простаивать, а часть была перегружена.
В 1959 году была предложена система управления производством, которая позволяла уравновесить все участки линии. Основной принцип заключался в том, что на каждом этапе рабочие вывешивали карточки с необходимым количеством деталей, которые передавались дальше по линии. Каждый следующий по производственной линии работник, брал себе именно столько деталей от предыдущего, сколько положено ему в карточке.
Таким образом у каждой детали была карточка, а излишков просто не могло быть. В итоге запасы не росли на участках, а каждый следующий рабочий получал ровно то количество деталей, которое ему было необходимо.
Давайте сформулируем что же такое kanban и перенесем его на разработку интернет продуктов.
Kanban, это система управления бережливыми производством (перевод с японского: «сигнал»/«карточка»), которая использует информационные карточки для передачи заказа на всех этапах изготовления. Простыми словами, мы отслеживаем весь путь продукта, от идеи до выхода “на полку магазина”.
Выше изображена kanban доска. Это основной инструмент отображения статуса по задачам. Главный принцип: мы видим на каком этапе производственного процесса находится та или иная задача. Плюс, отслеживается время на всех участках, то есть всегда можно обнаружить “ ” в системе и поработать с ними.
Количество столбцов вы определяете сами исходя из особенностей своего проекта. Важно, чтобы это были основные этапы, которые проходит ваш продукт. Пример выше, это плюс-минус основные этапы, которые проходит интернет продукт.
Применение методологии весьма широкое. Kanban используют для реализации проектов, управления службой продаж, производственных линий, it-разработки и даже для организации собственной жизни.
Простите, что прерываю чтение. Присоединяйтесь к моему telegram канал . Свежие анонсы статей, развитие digital продуктов и growth hack, там все. Жду вас! Продолжаем…
Принципы kanban
- Визуальное отображение задач. Все задачи должны быть представлены в виде карточек и отражены на доске. Очень важно обновлять статус задач. Например, если разработчики подготовили код и передали в тестирование, то карточка с задачей должна перейти в соответствующий столбец. Таким образом, любой участник команды в любой момент времени может посмотреть на каком этапе находится задача.
- Ограничение по столбцам WIP (work in progress или работу, выполняемую одновременно) на каждом этапе производства. Чтобы система рано или поздно не “захлебнулась” от потока задач, необходимо устанавливать ограничения. К примеру, на kanban доске выше в столбце Analisis (аналитика) у нас работают 2 человека и они могут обрабатывать не более 2 задач, нет смысла нагружать их больше, так как последующие этапы системы будут простаивать. Ограничение по столбцам подбираются опытным путем.
- Фокус на невыполненных задачах. Смотря на доску с задачами в первую очередь уделяйте внимание тем задачам, которые “подвисают” в том или ином столбце. Если у вас какой-то из этапов занимает больше всего времени, то попробуйте перераспределить ресурсы или же добавить людей, если есть такая возможность.
- Постоянное улучшение. Как только вы уравновесите нагрузку в системе, вам будет проще наблюдать за всем процессом в целом. Измеряйте время цикла (сколько задача висит в отдельном столбце, а сколько от момента попадания в To do, до релиза Done). Меняйте нагрузки в системе и сокращайте время на прохождение всех стадий.
- Уделяйте внимание мелочам. К примеру, если код, который пишут разработчики периодически не проходит тестирование и возвращается на доработку, то возможно, есть варианты улучшить качество разработки, чтобы в тест попадал более качественный продукт?
Подход kanban может показаться идеалистичным, но уверяю вас его принципы приносят результаты. В первую очередь необходимо адаптировать методологию под свою ситуацию, а после шлифовать систему.
Инструменты kanban
Или где вести kanban доску.
- Excel таблицы
- Доска со стикерами
- Еще фантазия…
На самом деле вариантов масса, можно погуглить и набраться вдохновения. Главное, чтобы у вас была эта доска и все участники процесса могли видеть, что происходит с задачами в данный момент.
Примеры kanban досок
Вот доска, которая висит на стене, где каждая задача отражена на стикерах.
Или же это может быть облачный сервис, типа Trello.
Есть ряд мнений по-поводу того, какие же инструменты и варианты использовать в работе, но это по-большей части вкусовщина. Просто попробуйте разные решения и остановитесь на том, которое больше понравится. Суть в том, чтобы начать использовать kanban, а не стопориться на использовании максимально красивой доски.
Мое мнение такое: для мозгового штурма или проработки кейсов в оффлайне хорошо работает обычная доска со стикерами. Но для повседневной работы само собой нужно использовать облачное решение типа Jira, Kanbantool, Trello и прочее. В них вся команда может добавлять комментарии к задачам, двигать их по столбцам и многое другое.
Нюансы/мыли
Если говорить об интернет продуктах, то kanban работает, помогает и улучшает, но есть ряд опасений или же нюансов, которые необходимо учитывать.
- Скорее всего введение лимитов WIP на столбец может немного напугать управленческий состав проекта. Ведь как определить сколько разработчик или, например тестировщик могут параллельно решать задач? А вдруг мы введем ограничения и они будут попросту прохлаждаться?
Понимаете, если человек не загружен на все сто, это не есть плохо. Он может обучаться и анализировать проделанную работу, находить недочеты и исправлять их, да пусть даже и отдыхать. Плюс, можно помочь товарищам с других частей процесса (столбцов), подробнее далее.
- Как утверждают гуру kanaban, система идеально работает в кросс-функциональных командах. Ну что-то вроде того, если тебе нечего делать, иди помоги товарищу по цеху. Правда, чтобы сколотить себе команду, где разработчики могут быть тестировщиками и наоборот, а архитектор системы поможет дизайнеру, нужно будет выложить немалые деньги, да и стоит ли?
Конечно, прекрасно, когда участники команды учатся у друг друга и в случае чего могут где-то помочь. Но, чтобы такое условие соблюдалось, необходимо иметь небольшие команды, которые желательно сидят где-то рядом и постоянно общаются. На больших проектах тяжело воспроизвести такой обмен опыта.
Поэтому, я больше склоняюсь к оттачиванию своего скила, если уж выдалась спокойная минута. Посмотри, что сделал, подумай, как можно улучшить, почитай полезные статьи. Человек, это живой организм, а не шестеренка в конвеере.
Итого
Мы разобрали методологию kanban и теперь, надеюсь, вы понимаете как ее применить в своем проекте. Попробуйте разделить свои процессы на основные этапы и оптимизировать систему с учетом полученных знаний.
Система канбан начала свой путь в 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, была отброшена в пользу продуктивности. Приоритет задачам расставлялся согласно «стоимости задержек» или готовности ресурсов.
Канбан система не только помогла добиться Андерсону поставленной цели, но и улучшила настроения в коллективе. Благодаря совместным обсуждениям и наглядности процессов у сотрудников утвердилось доверие друг к другу. Также персонал приобщился к кайзену, то есть практике постоянного улучшения.
КАНБАН
Cистема Канбан (Kanban) - тянущая система организации производства и снабжения, позволяющая реализовать принцип точно вовремя (Just-In-Time).
Разработана и впервые в мире реализована фирмой "Тойота". В 1959 г. эта фирма начала эксперименты с системой Канбан и в 1962 г. начала процесс перевода всего производства на принципы Канбан. В основе Канбан - теоретические построения Ф. Тейлора (1856-1915); Г. Форда (1863-1947), а также некоторые положения философии дзэн-буддизма и конфуцианства.
В основе организации производства фирмы "Тойота" лежит годовой план производства и сбыта автомобилей, на базе которого составляются месячные и оперативные планы среднесуточного выпуска на каждом участке, основанные на прогнозировании покупательского спроса (период упреждения - 1 и 3 мес.). Суточные графики производства составляются только для главного сборочного конвейера. Для цехов и участков, обслуживающих главный конвейер, графики производства не составляются (им устанавливаются лишь ориентировочные месячные объемы производства).
Постоянное использование философии «точно-во-время» позволяет раскрыть не обнаруженные до сих пор дефекты. Запасы очень хорошо приспособлены для сокрытия дефектов. Только при уменьшении запасов можно разглядеть проблемы. Это очень похоже на то, как высокий уровень воды скрывает подводные рифы.
«Канбан» - на японском языке означает карточка.
Существует два вида системы «Канбан»:
- тарный «Канбан»;
- карточный «Канбан».
Тарный «Канбан» представляет из себя единицу тары, на которой находится бирка «Канбан». Бирка «Канбан» на контейнере закреплена жестко и имеет следующие содержание:
Наименование детали;
Номер детали;
Количество деталей;
Адрес получателя детали;
Адрес отправителя детали.
Система заказа деталей и узлов по тарному «Канбану» осуществляется следующим образом: по мере окончания деталей в первом тарном «Канбане» оператор убирает его с рабочего места на нижний ярус стеллажа (нижний ярус стеллажа является местом для складирования заказов оператора и получением заказов транспортировщиком) и работает из второго. Транспортировщик забирает порожнею тару и поскольку к таре прикреплен «Канбан» осуществляется обратная связь между оператором и кладовщиком через транспортировщика для заказа материалов.
Тарный «Канбан» имеет недостаток - требуется дополнительное количество тары на каждую единицу детали или КИ при создании склада.
Карточный «Канбан» представляет из себя карточку, разделённую на четыре раздела:
Цвет карточки;
Адрес отправителя детали;
Наименование детали, номер детали, количество деталей или узлов, необходимое для поставки по адресу получателя;
Адрес получателя детали.
Один из вариантов цветовой гаммы:
Синий - производственный «Канбан» (между производственной линией и зоной выдачи);
Красный - складской «Канбан» (между складом и зоной выдачи);
Зелёный - межцеховой «Канбан»(между цехами, производствами заводами и.т.д.).
Доставка деталей должна осуществляться на транспортировочных тележках. Внутри цеховой электротранспорт, должен быть исключён, так как это требует дополнительных затрат на обслуживание, ремонт, дополнительную численность работающих и влияет на безопасность окружающих. Транспортная тележка содержит четыре отделения: для крупных деталей; для средних деталей; для мелких деталей; для порожней тары.
Крупные детали, как на складе, так и на рабочем месте оператора должны перекладываться в ручную, они должны перекатываться с транспортировочной телеги на рабочее место, либо наоборот. Транспортировка деталей на рабочие места должна производиться таким образом, чтобы транспортировщик не заходил в рабочею зону оператора. Для этого необходимо на рабочих местах операторов указать все адреса деталей согласно планировке, с обратной стороны рабочего стола оператора.
Первый принцип системы «Канбан» - бирка «Канбан» должна находиться в таре с деталями или прикреплена к ним.
Второй принцип системы «Канбан» - два «Канбана» на рабочем месте, т.е. на одном рабочем месте допускается иметь две нормы деталей. Этот принцип распространяется только на мелкие и средние детали, транспортировка которых осуществляется в специальной таре - данный принцип устанавливает время на транспортировку деталей.
Третий принцип системы «Канбан» - отсутствие бракованных деталей на производственной линии (конвейере), так как если бракованные детали будут попадать на конвейер, будет отсутствовать стабильная работа транспортировщика и работа конвейера.
Четвертый принцип системы «Канбан» - формирование новой схемы складского хозяйства:
Склад должен быть один, максимально приближённый к конвейеру;
Склад формируется по принципу магазина самообслуживания - транспортировщик движется по складу и сам собирает в тележку необходимые детали и сборочных единиц;
Детали и КИ в нужном количестве должны быть подготовленные для транспортировщика работниками склада, одним из самых важных факторов является отсутствие пересчёта, либо скорый пересчёт (мерная, ячеистая тара). Передача ТМЦ от транспортировщика оператору, также должна осуществляться без пересчёта - на первый план выходит доверие людей друг другу.
Для рационального использования рабочего времени кладовщика, транспортировщика и т.д., необходимо применить - упростить систему документооборота (применить штрих-кодирование).
Wikimedia Foundation . 2010 .
Синонимы :Книги
- Канбан и "точно вовремя" на Toyota. Менеджмент начинается на рабочем месте , . О писках совершенствования, восходящих к самурайской традиции, согласно которой воин никогда не перестает повышать свое мастерство и оттачивать свой меч. О системе канбан и "точно вовремя",…
