{"id":14284,"url":"\/distributions\/14284\/click?bit=1&hash=82a231c769d1e10ea56c30ae286f090fbb4a445600cfa9e05037db7a74b1dda9","title":"\u041f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u0444\u0438\u043d\u0430\u043d\u0441\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u043d\u0430 \u0442\u0430\u043d\u0446\u044b \u0441 \u0441\u043e\u0431\u0430\u043a\u0430\u043c\u0438","buttonText":"","imageUuid":""}

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

Это было в далёком 2010 году. Я только начала работать в приборостроительной компании, в которой уже началось изучение и внедрение ТОС. Одним из первых пилотов для внедрения ТОС решений стал участок механообработки. Участок выполнял как серийные повторяющиеся заказы, так и разовые заказы для разработки.

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

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

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

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

Единственная найденная картинка из того времени - скрин слайда с конференции практиков ТОС

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

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

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

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

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

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

Если вы тоже внедряли у себя такой механизм и получили классный результат — расскажите) Если ничего не вышло — тем более расскажите) Если вам интересны какие-то конкретные подробности — буду рада вашим вопросам. Если вы хотите внедрить такое решение у себя — почитайте Голдратт Цель, Основы ТОС, Handbook TOC или запишитесь на консультацию (первая экспресс консультация — бесплатно).

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

P.P.S Мой YouTube канал про Теорию Ограничений и не только. Там есть пару стримов с Максимом Дорофеевым, скоро появятся новые)

P.P.P.S Я люблю сердечки, сердечки — это красиво, и они повышают настроение🥰

0
1 комментарий
Наталья Анисимова

Привет. Я очень долго шла прочитать твою статью, но дошла :) Интересный прием с бумагой - простой в реализации. Возьму в копилку идей! Но его можно применять там, где производственные буферы по всем заказам примерно одинаковы

Ответить
Развернуть ветку
-2 комментариев
Раскрывать всегда