Изучение системы "Канбан"

Размещено на http://www.allbest.ru/

Содержание

Введение

1. Понятие системы «Канбан»

2. Примеры применения системы «Канбан» в IT-компаниях

3. Приложения и программы для системы «Канбан»

Заключение

Введение

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

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

Цель контрольной работы - изучить систему «Канбан».

Для достижения цели поставлены следующие задачи:

- изучить сущность и понятие системы «Канбан;

- рассмотреть примеры применения системы «Канбан» в IT-компаниях.

- рассмотреть приложения и программы для системы «Канбан».

1. Понятие системы «Канбан»

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

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

1. обозначение типоразмера детали или сборочной единицы;

2. номер производящего их участка или линии;

3. номер потребляющего их участка или линии (этот реквизит у карточек заказа отсутствует);

4. тип и вместимость тары в потоке деталей (сборочных единиц) данного типоразмера;

5. номер склада, где хранятся данные детали или сборочные единицы;

6. номера и расположение стеллажа и позиций для хранения;

7. номер карточки;

8. общее количество карточек в обороте.

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

Рисунок 1 --Виды карточек «Канбан»

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

Правила движения карточек «Канбан»

1. Любое перемещение изделий без карточек запрещено.

2. Для перемещения используются только стандартные контейнеры фиксированной емкости.

3. Бракованная продукция не должна поступать на следующую операцию (находиться в контейнере).

4. На каждый контейнер приходится только одна карточка заказа и одна карточка отбора.

5. Любой отбор, превышающий указанное в карточке количество, запрещен.

6. Производство в больших количествах, чем указано в карточке, запрещено.

7. Число карточек, находящихся в обороте, должно быть минимальным.

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

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

- карточку отбора - при движении от буфера к потребляющему звену, когда он заполнен, и от потребляющего звена к буферу, когда он пуст;

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

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

Работа механизма «вытягивания» включает три фазы:

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

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

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

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

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

Z=DT(1 + K)/Q,

где Z -- общее число карточек (контейнеров), находящихся в обороте; D -- среднедневное потребление предметов труда, шт.;

Т-- ожидаемое время пополнения запаса, дн.;

Q -- емкость контейнера, шт.;

К -- коэффициент страхового запаса.

Рисунок 2 -- Схема движения материального потока изделий и оборота сопровождающих из карточек в системе JIT

Пути минимизации заделов показаны на рисунке 3.

Рисунок 3 -- Пути минимизации запасов и заделов незавершенного производства в системе JIT

Пример карточки представлен на рисунке 4.

Рисунок 4 --Пример карточки с применяемыми обозначениями

Правила эффективного применения системы «Канбан»

Президентом корпорацию Toyota Motor Corporation Тайити Oно предложены следующие правила эффективного применения карточек Канбан:

1. Каждый последующий рабочий процесс изымает указанное карточкой канбан количество деталей от предшествующего рабочего процесса.

2. Расположенный впереди рабочий процесс производит детали в количестве и последовательности в соответствии с указанной карточкой.

3. Ни одна деталь не должна быть произведена без карточки. Этим самым обеспечивается сокращение перепроизводства и избыточные перемещения товаров. Находящееся в обороте количество карточек канбан представляет собой объем максимальных запасов.

4. Товар всегда пристраивается к карточке. Карточка является своеобразным заказом на изготовление товара.

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

6. Уменьшение количества карточек повышает их чувствительность. Они вскрывают существующие проблемы и делают возможным контроль запасов.

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

Рисунок 5 -- Пример карточки с применяемыми обозначениями

2. Примеры применения системы «Канбан» в IT-компаниях

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

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

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

Думитриу застал отдел, состоявший из трех разработчиков и трех тестировщиков, у которых в бэклоге накопилось 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 появилась канбан-доска, у которой Андерсон ежедневно беседовал с коллективом. Целью ПМ было улучшить визуальный контроль над процессами, способствовать самоорганизации и большей персональной ответственности исполнителей. Также система канбан была направлена на уменьшение надзора со стороны менеджеров и увеличение производительности.

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

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

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

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

3. Приложения и программы для системы «Канбан»

Trello

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

Kanbantool

Бесплатная доска для двух пользователей. Поддержка API и touch-интерфейсов.

Lean Kit Kanban

Бесплатная доска для пяти пользователей с хорошей реализацией совместной работы. Поддержка API и возможность импорта/экспорта, широкая статистика

Kanbanize

Полностью бесплатный сервис с достойной функциональностью. Его владельцы гарантируют прирост в производительности на 300% при использовании их приложения.

Worksection

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

Заключение

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

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

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

Размещено на Allbest.ru