История о том, как за 6 месяцев мы сократили время выполнения заказов в два раза (на самом деле быстрее)

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

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

В итоге, мы получили очень простую систему приоритетов. Цвета буфера определяли срочность выполнения заказа. Самые срочные — чёрные, потом красные, потом жёлтые, зелёные и белые. Белые — это те заказы, которые мы ещё не планировали начинать.

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

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

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

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

Через какое-то время у нас появилось достаточное количество статистики, и мы смогли сравнить, какую часть времени выполнения заказа занимает реальная трудоёмкость, а какую часть занимает «пролёживание» и ожидание в очереди. Оказалось, что в начале внедрения пропорция составляла 1:14. То есть при времени выполнения заказа в две недели, только один день занимала трудоёмкость. Какой важный вывод мы сделали — при таком соотношении бессмысленно заниматься сокращением трудоёмкости. Даже если бы мы чудом сократили её в ноль, ожидание в очередях всё ещё занимало бы 13 дней. И это ещё неплохое соотношение. За шесть месяцев эксперимента соотношение сократилось до 1:7. Не меняя трудоёмкость и технологии, не увеличивая ресурсы (а даже немного сократив), мы стали выполнять заказы в два раза быстрее.

За счёт чего это произошло? Просто мы стали работать над заказами последовательно, сократилось количество «незавершёнки» (работа в работе), мы стали быстрее видеть и устранять причины вынужденных условных простоев. Количество сорванных заказов также упало до приемлемых 2-3 заказов в месяц.

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

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

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

01/ Что такое эффективность? [почитать] [посмотреть]

02/ У вас нет выбора. Либо вы управляете ограничением, либо оно управляет вами [почитать]

03/ Теория ограничений — это серебряная пуля? [почитать]

04/ Теория ограничений и проектное управление. Что за диагональный буфер? [почитать]

05/ Если это решение, то в чем проблема? Шесть слоев сопротивления изменениям [почитать]

06/ Теория ограничений. Голдратт. Одна история применения [почитать]

07/ Почему ваши очевидно эффективные идеи отвергаются (вероятно, дело в вас) [почитать] [посмотреть]

08/ Премия от KPI синхронизирует цели компании и сотрудника? Нет! [почитать]

09/ Парадоксы финансовой мотивации [посмотреть]

10/ Почему «KPI+деньги» не работает [посмотреть]

Мой телеграм-канал, где я оповещаю о новых заметках и делюсь короткими инсайтами и мыслями, которые не попадают сюда. Ещё там можно обсуждать идеи и смотреть на ТОС с разных сторон вместе с другими