Сверхновая. Синхронное и оптимизационное планирование «Звезды» // Intelligent Enterprise/RE Корпоративные системы №19 (175), 10 декабря 2007 года
Необходимость усовершенствования управления и поддерживающих его информационных систем была вызвана ростом общего уровня развития предприятия. Как сказал финансовый директор ОАО «Звезда» Петр Гнеденко: «Особенно остро стояли задачи синхронизации планирования продаж с учетом производственных возможностей, разработки четких процедур взаимодействия подразделений продаж, производства и снабжения при изменении заказов, построения оптимальной сбалансированной производственной программы, минимизации запасов сырья, материалов, покупных полуфабрикатов и комплектующих и сокращения длительности производственного цикла».
ИТ-ландшафт перед началом проекта
По словам ИТ-директора компании Александра Назарова, информационная инфраструктура предприятия на момент начала проекта в 2003 году представляла собой набор из множества разрозненных информационных систем. Данные между ними передавались вручную с помощью записок на бумаге и телефонных звонков, автоматическая же интеграция предусмотрена не была. Самое старое из этих решений, ERP-система BPCS, к тому времени давно уже не работала по своему прямому назначению, а использовалась сотрудниками предприятия как источник информации о составе изделия. Вторая система, разработанная на базе Microsoft Excel, Access и FoxPro, отвечала за планирование производства и учет выполнения нарядов для расчета заработной платы. В третьей существовала программа управления продажами, которая автоматизировала склад готовой продукции, ограничиваясь при этом по сути учетом документов на отгрузку. В четвертой, системе расчета цен, проводилась калькуляция предконтрактных работ. Наконец, управление закупками и запасами до внедрения новой системы было реализовано на базе «1С:Предприятия». Еще одним элементом лоскутной автоматизации завода была система планирования расходования денег на обеспечение основного производства.
Проблемы планирования производства
Из всей перечисленной выше функциональности нас больше всего будет интересовать планирование производства. По словам начальника производственно-диспетчерского отдела (ПДО) Василия Гребнева, система планирования на предприятии изначально была построена по картотечному принципу. В карточке изделия содержалась информация о его применяемости в узле верхнего уровня и в конечном узле, о длительности цикла изготовления и указывался остаток деталей этого типа на момент начала цикла. На основе этой информации и велось планирование производства. Данные о сдаче готовых деталей получались из накладных и суточных рапортов, а об остатках — из отчетов о движении товарно-материальных ценностей.
Такой метод планирования предприятие вполне устраивал, но тем не менее он имел серьезные недостатки. «Во-первых, в этом случае было очень тяжело проводить какие-либо изменения в конструкторской документации, — объясняет Василий Гребнев. — Во-вторых, подобный метод требовал от предприятия продолжительного периода фиксированного планирования продаж, на срок не менее одного квартала. А в-третьих, любое перепланирование по такой номенклатуре занимало пять рабочих дней шести сотрудников ПДО».
Когда в 2003-м стало понятно, что горизонт фиксированного планирования продаж стремительно сокращается и перепланирование теперь придется проводить значительно чаще, производственно-диспетчерский отдел «Звезды» был вынужден перейти на другую модель. «Ею стало планирование по машинокомплектам, — рассказывает Василий Гребнев. — Реализующая алгоритм программа была написана на Microsoft Access, в ней формировались планы на основе данных о движении деталей по заводу, попадавших в систему из цеховых накладных и рапортов. Метод планирования по машинокомплектам существенно сократил время перепланирования, однако тоже оставлял желать лучшего по этому параметру. Снова, как и в случае карточного метода, возникали сложности с внесением изменений в конструкторскую документацию. Кроме того, планируя верхний узел изделия, сотрудник был обязан одновременно вручную запланировать и производство всех входящих в него узлов, что было крайне неудобно. К тому же не была предусмотрена даже минимальная синхронизация подразделений, и за счет этого могло быть произведено значительно больше экземпляров детали, чем требовалось изначально». Таким образом, по словам Василия Гребнева, предприятие пришло к тому, что необходима система, поддерживающая динамическое планирование.
Цели проекта и выбор системы
В ходе предпроектного обсуждения с руководством предприятия были сформулированы основные цели проекта:
- увеличение свободных оборотных средств за счет минимизации всех видов запасов и материалов в результате точного и реалистичного планирования;
- увеличение объема продаж за счет повышения уровня обслуживания клиентов;
- уменьшение себестоимости готовой продукции за счет повышения эффективности управления затратами;
- обеспечение полной информационной прозрачности работы предприятия и повышение его капитализации.
Познакомившись с достижениями коллег, специалисты «Звезды» очертили круг программных продуктов, подходящих заводу по качеству, срокам и стоимости проекта внедрения. «На этом этапе три года назад мы отказались рассматривать SAP R/3 в качестве варианта, — рассказал Петр Гнеденко. — Дело в том, что по мнению наших специалистов это более масштабное, рассчитанное на структуры большего размера решение, и его внедрение вылилось бы в неприемлемо более длительные сроки, большие затраты материальных и трудовых ресурсов. Но если бы точно такой же выбор стоял перед предприятием сейчас, то моя точка зрения, возможно, и изменилась бы».
Уже на финальном этапе, когда консультанты провели обследование предприятия, была сделана итоговая презентация для руководителей завода. Кроме того, необходимый объем финансирования проекта обязывал предприятие вынести решение на совет директоров. Проведя такой процесс выбора, в конечном итоге предприятие остановилось на решении Infor ERP SyteLine и компании «Фронтстеп» в качестве интегратора.
Организация команды и мотивация персонала
Когда решение о внедрении новой ERP-системы было утверждено, сразу встал вопрос об основной организационной единице проекта — проектной команде. Петр Гнеденко рассказал, как она создавалась: «Первым шагом при формировании группы был выпущен приказ, регламентировавший уровень вовлечения сотрудников в проект, процент их занятости в нем. В данном случае цифры варьировались от 60 до 80%. В группу подготовки нормативно-справочной информации, после неудачного опыта привлечения в нее стажеров-студентов, были включены только опытные сотрудники предприятия. Вариант практически бесплатной, но неопытной рабочей силы больше не рассматривался, поскольку качество их работы оказалось чрезвычайно сложно проконтролировать, и порученные студентам задачи пришлось переделывать заново».
При формировании команды проекта руководство постаралось включить в нее сотрудников с гибким мышлением. По мнению Александра Назарова, с этой точки зрения можно даже принести в жертву какую-то часть профессионализма команды, ведь если набраться опыта люди могут в ходе проекта, то изменить способ мышления — уже вряд ли. Гибкость здесь так важна потому, что при внедрении ERP-системы многие устоявшиеся механизмы взаимодействия как внутри подразделений, так и между ними очень сильно изменяются, а проектная команда — это как раз те люди, которые в первую очередь должны адекватно воспринять такие изменения.
Петр Гнеденко отметил также, что специалисты и руководители рабочей группы были направлены на трехдневный семинар по управлению производством. После этого проектная команда прошла обучение уже по курсу самой системы Infor ERP SyteLine. О подробностях этих занятий рассказал руководитель проектов службы информационных технологий Олег Апанасик: «Отдельно проходило обучение по таким направлениям, как продажи, закупки, производство, планирование и управление себестоимостью.
Тренинги проходили непосредственно на “боевых” данных нашего завода, модель которых была предварительно подготовлена, передана консультантам и загружена в учебную систему. По окончании обучения был проведен экзамен, причем чистой формальностью он не был — с первого раза его прошли не все».
Рассказывая о денежной составляющей системы мотивации сотрудников, финансовый директор завода разделил ее на несколько видов. В проектной команде поощрение группы информационных технологий выражалось в увеличении заработной платы составляющих ее сотрудников, а с руководителями подразделений вопрос премирования решался индивидуально. Не состоящие в группе внедрения сотрудники, привлекавшиеся к разовой работе по проекту, получали премиальный бонус по достижении конкретного результата. По словам Петра Гнеденко, в самой команде специалистов заработная плата на время работ была увеличена примерно на 10 — 30%, конкретные суммы по каждому сотруднику обсуждались отдельно. Кроме того, была выполнена большая работа по переносу данных с бумажных и устаревших электронных носителей, не позволявших провести эту процедуру автоматически, и поскольку для сотрудников это была нагрузка к их основной работе, то и здесь предусматривались разовые премии каждые два-три месяца в размере 20 — 30 % от оклада.
Конечные же пользователи системы, не имевшие никакого отношения к ее внедрению, но начинавшие работать в программе, получали оговоренную премию в случае перехода со старого ПО управления предприятием на Infor ERP SyteLine. Если же сотрудник вообще не пользовался системой-предшественницей, то ему полагался новый уровень заработной платы.
Сопротивление пользователей
Александр Назаров говорит о том, что привычки десятилетиями работающих в компании людей становятся причиной их крайне серьезного сопротивления по отношению к проектам автоматизации управления производством. Происходят конфликты с руководителями подразделений, то и дело возникают внеплановые ситуации, нарушающие установленный ход работы. Цитируя Макиавелли: «…у каждого нововведения есть ярые враги, которым хорошо жилось по-старому, и вялые сторонники, которые не уверены, смогут ли они жить по-новому», — ИТ-директор «Звезды» приводит соотношение числа сотрудников первого и второго типов на своем заводе: 10 к 90.
«Важно во время запуска втянуть в процесс как руководителей, так и их подчиненных, — говорит Александр Назаров. — Нужно, чтобы люди начали по-новому работать и с коллегами внутри собственных подразделений, и при любых взаимоотношениях с соседними подразделениями. Для того чтобы так и произошло, за основу был взят описанный в теории проведения изменений метод размещения людей на “горящих платформах”. Его суть состоит в том, что сотрудники должны быть поставлены в такую ситуацию, выход из которой остается всего один: сделать то, что нужно проектной команде. А поскольку каждое действие по выполнению своей обычной работы исполнитель фиксирует в соответствующих документах и отчетах, то построив систему, где все первичные документы должны будут получаться только из нее, тем самым мы создадим и требуемую “горящую платформу”».
Василий Гребнев уточняет меры, предпринятые при запуске системы: «Сразу было запрещено перемещение продукции между цехами по старым нормативным документам и накладным. Отныне оно возможно только по новым накладным, сформированным в системе. Причем ответственность за соответствие документов новым требованиям нес не человек в отправляющем цехе, а, напротив, сотрудник в принимающем документ подразделении. Люди поняли, к чему приводит саботирование перехода, после того как некоторые цеха были наказаны. Тут же мгновенно прекратилось любое движение изделий по старым накладным».
Производственный учет
Когда проектная команда закончила свою работу, на заводе «Звезда» были сформированы группы учета хода производства, в которых инженеры планово-диспетчерского бюро (ПДБ) отслеживают и заносят в систему информацию о движении деталей и выполнении плановых заданий.
Любое движение материальных ценностей на производстве проходит таким образом: когда изготовление какой-либо детали завершается, мастер ставит об этом отметку в плане. Инженер ПДБ фиксирует выполнение задания в системе и формирует накладную, с которой деталь перемещается в следующий цех. Там либо мастер, либо кладовщик (в зависимости от того, приходит ли деталь на участок или в кладовую) подтверждает поступление изделия своей визой на накладной и передает эту накладную своему инженеру ПДБ, который отмечает поступление в системе. Крупногабаритные детали либо материалы, которые невозможно разместить в кладовых, поступают непосредственно на участки, но тоже с соответствующими визами. Таким образом фиксируются входы и выходы материальных ценностей в цехах и их переходы из кладовых в производство. Раз в месяц проводится выборочная инвентаризация, призванная нивелировать результаты нормативных списаний. Итог в конце запланированного периода подводится по нарядам, просчитывается процент выполнения плана и производятся выплаты бригадам по премиальной системе, завязанной на этот показатель.
Внесением всех поступающих заказов в систему и их оформлением занимаются менеджеры управления материально-технического снабжения. Кладовщики отражают в системе факт закупок. Вся информация от менеджеров и кладовщиков о партиях закупок и перемещениях изделий по складам фиксируется в системе. Группа, занимающаяся отгрузкой и выполнением заказов клиентов, т. е. коммерческая служба, вносит в систему заказы и отражает в ней факт отгрузки. Так замыкается цепочка поставок и производства.
Особенности планирования
Перед каждым этапом планирования руководитель ПДО проверяет корректность входных данных, поступающих от клиентов через коммерческую службу предприятия. В первую очередь проверяется, все ли поступившие заказы внесены в систему. Кроме того, контролируется, есть ли в программе структура изделий этих заказов. В системе «Лоцман», отвечающей на предприятии за состав изделия, деталь представлена в древовидной структуре, где с каждым объектом связывается маршрут его движения по цехам, нормы расхода материалов и времени на его изготовление.
За проверку правильности структуризации и состава изделия в системе, объединенной с Infor ERP SyteLine через отдельный модуль интеграции, отвечают конструкторы и технологи, нормировщики отдела труда, а верность норм расхода материалов отслеживает бюро материальных нормативов (БМН). Сформированная древовидная структура передается в Infor ERP SyteLine, и любое изменение в структуре изделия должно проходить всю описанную цепочку: проверки конструкторов, технологов, нормировщиков и контроль БМН. Как правило, по всем производимым изделиям такая структура в Infor ERP SyteLine есть, но при появлении нового продукта на этапе проверки от руководителя ПДО может потребоваться корректировка данных в заказе клиента.
«После проверки данных проводится собственно сама процедура планирования, ее корректность руководитель ПДО проверяет по заранее известным ему ключевым точкам, которых на самом деле не так много, — говорит Олег Апанасик. — По результатам проведенного планирования руководитель отдела отвечает для себя на вопрос, насколько выполняются заказы клиентов, где завод не может выдержать запрошенные сроки и из-за чего это происходит. Если ошибка допущена при планировании, то она должна быть исправлена силами отдела, а вот если график невыполним в принципе, то начинаются переговоры с коммерческой службой о перенесении сроков заказов. После утверждения плана он передается в цеха». На сегодня в принятой на предприятии модели планирования предусмотрена последовательная детализация работ до уровня цехов, откуда план работ спускается на уровень отдельных бригад, которые являются нижним уровнем формирующегося плана. За корректную работу этого процесса в первую очередь отвечает группа планирования, состоящая из сотрудников ПДО. Что же содержится в спустившемся в цех плане? В нём указаны наименование цеха и номер бригады, плановая трудоемкость задания, номенклатурные номера, названия и уровень остатков требуемых деталей. В базовых заданиях для бригад прописывается количество требуемой продукции, трудоемкость, сроки запуска и выпуска. А непосредственное планирование производственных мощностей проходит уже в цехах, руководители которых самостоятельно определяют, как они распорядятся своими ресурсами, чтобы выдержать сроки.
По словам Василия Гребнева, частота планирования сейчас — три раза в месяц. Однако учет ограничения по ресурсам при планировании реализован не для всех участков. Олег Апанасик упоминает, что есть отдельные подразделения, для автоматизации которых достаточно и алгоритмов расчета с предположением о неограниченности ресурсов, но для остальных по ним постепенно были введены ограничения. Например, с такими ограничениями планируется механосборочное производство.
Насколько опыт синхронного планирования на заводе «Звезда» возможно использовать в других компаниях? Исполнительный директор «Фронтстеп СНГ» Сергей Питеркин считает, что прежде всего стоит отталкиваться от типа производства и его проблем. «Хотя похожий проект может быть реализован на позаказном производстве, номенклатура изделий которого близка к серийной, однако на более тяжелые варианты, когда создаются единичные изделия и длиннее производственный цикл, этот опыт напрямую не переносим, — говорит он. — При другом типе производства и планирования не стоит пытаться повторять опыт соседей».
Оценка успеха
Петр Гнеденко считает вопрос окупаемости проекта одним из самых сложных моментов и, не называя конкретных цифр, предлагает оценивать успех по избавлению от накопленных запасов: «Это произошло не в одночасье, но сейчас уровень остатков значительно снизился за счет того, что стали видны реальные потребности и при расчетах на их основе объемы закупок начали существенно сокращаться. При этом завод теперь может видеть, по каким материалам нет движения, запасы каких деталей превысили норму и почему это произошло. Такой порядок на складах очень важен для промышленного предприятия вроде «Звезды», с большим числом переделов и серьезным уровнем запасов. Кроме того, если у вас на местах ответственные исполнительные люди, то вы и им даете мощный инструмент учета и контроля, который они могут применить для снижения остатков на складах, в результате чего у предприятия оптимизируется объем оборотных средств». Ведь если раньше 70% производимых заводом деталей требовалось в дальнейшем производстве не в самое ближайшее время, а лишь в отдаленной перспективе, занимая до тех пор место на складах, то теперь подобной ситуации уже нет.
Вторая причина, по которой Петр Гнеденко считает этот проект успешным, — повышение точности прогнозирования сроков выполнения заказов. «Сейчас система оперативно выдает ответ на вопрос о возможных сроках производства, а незадолго до ее запуска, например, предприятием был заключен контракт на отгрузку продукции через три месяца, — говорит он. — Проверив свои возможности через какое-то время в уже работающей программе, предприятие понимает, что в сегодняшних условиях задержит отгрузку месяцев на пять. При этом запоздалом расчете было учтено и то, что производство перегружено на отдельных участках, и каков будет цикл поставки. Система оказалась права, и уже заключенный контракт через три месяца был нарушен, хотя этого можно было избежать еще при заключении, сразу обговорив с клиентом реальный срок в восемь месяцев. Существовавшие до Infor ERP SyteLine методы анализа привели к штрафным санкциям в отношении завода».
По мнению Сергея Питеркина, данный проект решил отнюдь не все актуальные для предприятия задачи и в этом как раз и есть один из залогов успеха: «Не браться сразу за многое, не ставить перед собой гигантских планов, а синхронизировать сначала внутреннюю цепочку поставок, обеспечить быстрое движение информации и материалов от клиента к поставщику, добиться, чтобы сотрудники освоили систему, это и было верным решением».
Планы развития
В ходе дальнейшей автоматизации завод собирается продолжать подключение имеющихся в самой ERP-системе возможностей, которые сейчас используются лишь в небольшой своей части. В перспективе планируется и работа с новыми модулями Infor ERP SyteLine, и переход на более обширное использование алгоритмов расчета деятельности с предположением ограниченности ресурсов. Это позволит лучше находить и устранять узкие места на производстве и увеличивать его объемы при сохранении ресурсов на том же уровне.
Говоря о планах дальнейшей автоматизации «Звезды», Петр Гнеденко упоминает состоявшийся почти сразу по окончании проекта новый тендер поставщиков программного обеспечения для управления эффективностью предприятия. Три основных блока, автоматизацией которых завод планирует заняться в ближайшем будущем и которые должны завершить контур его информационной системы, — это стратегическое, бюджетное и проектное управление. Под стратегическим управлением имеется в виду выстраивание стратегии предприятия на основе определенной методики и её детализация вплоть до плановых действий. Блок планирования проектов также необходим, потому что их много и все они нуждаются в контроле как за расходом ресурсов, так и за сроками выполнения и достигнутыми результатами.
© 1997—2007 Intelligent Enterprise/RE Корпоративные системы.