Сопоставление организации планирования в машиностроении с подходами при планировании разработки программного обеспечения
Приветствую всех читателей Хабра!
Меня зовут Константин, занимаюсь разработкой ПО в компании «Автомакон». На данный момент работаю на проекте для «ВкусВилл».
Продолжаем рассмотрение опыта автоматизации планирования и учета в машиностроении и сопоставляем с подходами в ИТ. С предыдущими частями статьи можете ознакомиться по ссылкам: Часть 1 и Часть 2
Рано или поздно рост предприятия вызывает организационные проблемы, пример которых я привел в предыдущих статьях. Руководитель, который ранее очень успешно справлялся с управлением небольшим коллективом, при постоянном росте количества заказов со временем расходует свой лимит возможностей. В дальнейшем, согласно наблюдениям, последовательно предпринимаются следующие шаги:
Смена руководителя (без увеличения численности).
Очередная смена руководителя с кратным увеличением управленческого персонала.
Мероприятия по “борьбе за экономику”, которые подсмотрели на соседних предприятиях: (например, организация видеонаблюдения, электронная проходная –- учет рабочего времени, автоматизация складского учета, 5S …).
Автоматизация учета выработки, анализ трудозатрат.
Нормирование, планирование и учет трудозатрат.
Планирование загрузки мощностей.
Данный опыт связан с единичным и мелкосерийным производством, когда трудозатраты на технологическую подготовку производства сравнимы с трудозатратами на непосредственное изготовление. Были времена, когда на накладные расходы закладывалось до 700%. И, возможно, это даже считалось нормой, но времена меняются.
Если первые 3 пункта (кроме складского учета) к автоматизации никакого отношения не имеют, то со складского учета и далее начинается работа для автоматизатора. На первых этапах автоматизации особо запомнилось то, что практически у каждого опытного программиста была “своя” программа складского учета. С появлением 1С закрылись практически все потребности “ширпотреба”, особенно бухгалтерского учета. Отмечу, что было время, когда услышав, что надо автоматизировать бухгалтерию, где работает 100+ бухгалтеров, представители 1С честно признавались, что решения 1С предназначаются для автоматизации относительно малых предприятий. С тех пор количество бухгалтеров значительно уменьшилось, при этом и сейчас большинство вопросов бухгалтерии 1С закрывает достаточно уверенно. А по части автоматизации производства есть варианты.
Когда автоматизация начинается с бухгалтерии, то по сути вся автоматизация превращается в обслуживании бухгалтерии/склада. Такой подход тоже имеет право на жизнь, но как я уже говорил, мне в свое время повезло попасть в отдел, который имел многолетний опыт организации производственного планирования. Если планировать и учитывать жизненный цикл разработки РКД тогда не было физической возможности, то начиная с момента появления технологической подготовки производства, большинство проблем планирования с учетом производственных мощностей были решены (как минимум проработана теория). Более того, я много лет проработал с людьми, которые реализовывали алгоритмы Календарно-плановых нормативов еще на ЕС ЭВМ.
Принципиальные моменты, которые считаю стоит выделить:
В качестве основы планирования использовался структурный состав и директивная маршрутная карта (ДМК) — последовательность операций с указанием норм, но без детального описания техпроцесса.
Разработка ДМК была выделена в отдельный этап технологической подготовки производства и выполнялась в приоритетном порядке сразу после назначения материалов и видов заготовок. Как правило, этим занимались выделенные специалисты, обладающие соответствующим опытом.
Составление директивной маршрутной технологии в обязательном порядке сопровождалось нормированием. Для этого существовал отдел нормирования.
При расчете длительности производственного цикла учитывались межоперационные и межцеховые пролеживания.
Как только мы получали ДМК с нормами, все остальное планирование превращалось в увлекательную игру с исходными данными, настройками алгоритмов и постоянным совершенствованием программ с постепенным добавлением все новых и новых учитываемых факторов.
К сожалению, это работает только в теории. На практике возможности автоматизатора ограничены подходом руководства.
Первое, с чего начинается автоматизация руководства — это подсчет фактического времени, потраченного непосредственным рабочим на изготовление той или иной детали. Следующий этап — долгое ожидание, пока заказ отгружается. После томительное ожидание выгрузки большого количества заказов. Чем больше, тем нагляднее. Как итог — “посчитали-прослезились”. Превышение факта над планом доходило до 200-300%. Технологи пишут то, что нужно для сдачи в соответствующую инспекцию, нормировщики нормируют сами по себе, производство работает само по себе. У каждого отдела разные задачи. Придраться не к чему, они их выполняют. Разумеется, до планирования еще далеко. В лучшем случае планирование осуществляется на уровне: “на данное изделие в этом месяце мы планируем потратить N часов из ХХХ, заложенных в договоре”.
Далее начинается стыковка норм с фактом. Работа выдается в соответствии с нормами и закрытие времени свыше норм возможно только при оформлении соответствующего документа. Если не брать во внимание конфликтную сторону вопроса, то при правильном подходе относительно быстро (в течение нескольких месяцев/кварталов), технологи начинают добавлять в ТП те мелочи, которые они считали не принципиальными. Нормировщики начинают меньше ошибаться, а исполнители при появлении адекватных норм вполне с ними справляются.
На практике в результате внедрения п.п. 3 и 4 нормы практически совпадают с фактом, что приводит экономика заказов в адекватное состояние.
Остается только одна проблема, которая на фоне проделанной работы кажется не такой уж и существенной. Но это очень принципиальная проблема:
Мы до сих пор не умеем соблюдать СРОКИ изготовления.
В теории с момента появления ДМК современные аппаратные возможности в ИТ позволяют построить любые модели производственного цикла. При этом относительно легко можно просчитать как загрузку оборудования, так и любые другие критические ресурсы. Отклонение от утвержденного графика можно контролировать абсолютно на всех этапах. При возникновении отклонений можно сразу просчитывать влияние на сроки отгрузки, что позволяет заранее начинать либо исправлять график, либо заранее согласовывать новые сроки.
Сейчас, работая в коллективе разработчиков, сталкиваюсь с большим количеством слов, заимствованных из английского языка, например, спринт, дедлайн и т.п. При этом у меня всплывают ассоциации с очень старыми и уже частично забытыми понятиями:
DeadLine — Критический путь (на графике изготовления изделия)
Store point — Плановая трудоемкость
Спринт — Сменно-суточное задание (с той лишь разницей, что спринт, как правило, длится немного дольше)
Стоп-фактор — Ожидание изготовления другой детали
Project — Изделие
Unit — Сборочная единица
Form — Деталь из листа
Table — Деталь из круга
Project tree — Структурный состав изделия
Этот список можно продолжить, при переходе от IT- понятий к производственным я нахожу много схожестей. При этом, когда пытаюсь сопоставлять некоторые понятия из производства, которые необходимы для построения плановой модели, появляются пробелы. Один из основных примеров — “Директивная маршрутная карта”.
Что касается структурного состава изделия (дерево проекта), то при написании проекта в большинстве ЯП он формируется автоматом. Формально он есть, но для полноценного планирования структурный состав изделия должен быть готов еще на начальном этапе планирования. К тому же, сложные сервисы редко реализуются в рамках проекта. Так и получается, что изделие — это несколько разных проектов.
Отдельно стоит отметить то, что в производственном цикле изготовления огромное время/внимание уделяется разработке конструкторской документации.
Из относительно принципиальных мелочей отмечу, что при заполнении большинства документов ЕСКД/ЕСТД предусмотрены следующие поля:
Разработал
Проверил
Утвердил
Т.Контр
Н.Контр
Работая в ИТ, наблюдаю постепенное появление стандартов. Увеличивается объем контроля. В какой-то момент приходит мысль, что где-то я это уже видел. Создается ощущение, что это лишь вопрос времени — когда на очередном витке развития проект потребует сделать то, что в других сферах деятельности сделали уже давно. Остается только понять, как в этот раз в ИТ будет называться давно забытая революция.
Попробую перечислить вехи, которые постепенно приводили к росту производительности труда в свое время:
Переход от мануфактуры к фабричному способу производства.
Появление специализированного оборудования/станков.
Стандартизация оформления документации (метрическая система).
Стандартизация (крепежа, инструмента …).
Унификация узлов и агрегатов.
Автоматизация обработки (ЧПУ).
Дополнительно на каждом из этих этапов увеличивается разделение труда (количество профессий). Когда более узкая специализация приводит к тому, что специалист постепенно совершенствуя свои навыки, со временем начинает делать одну и ту же работу быстрее и/или качественнее.