На предприятии использовались система, разработанная на Clipper (для ввода данных производства), «1С: Бухгалтерия 7.7» (для ведения регламентированного учета) и «1С.8 ЗУП» (для расчета заработной платы). Руководство рассматривало переход на комплексное прикладное решение «1С:Управление производственным предприятием 8» (либо «1C: ERP 2.0»).
Согласно требований Заказчика было предложено 2 варианта внедрения:
1) Автоматизация на базе программных продуктов «1С: УПП 8» + «ПитерСофт: Управление процессами»
2) Автоматизация на базе программных продуктов «1С: ERP 2.0».
Сравнительная характеристика решений предложена в Табл.1.
Табл.1. Сравнительная характеристика соотнесения целей Заказчика и возможностей функционала программных продуктов 1С
Заказчиком было принято решение об автоматизации на базе «1С: ERP 2.0».
1. Учет производства продукция выпускаемой по индивидуальным заказам покупателей со своей тех. документацией
2. Контроль исполнения спецификации покупателя на всех этапах (производство - количество, продажа - количество, цена), в том числе по срокам исполнения
3. Автоматическое формирование производственного задания
Запущены блоки «Казначейство» (планирование доходов и расходов), «БДДС» (план-фактный анализ денежных потоков предприятия). Блок «БДР» (план-фактный анализ доходов и расходов предприятия) запущен частично (проект был приостановлен в связи с отсутствием финансирования со стороны Заказчика)
1. Запущено ведение регламентированного (как бухгалтерского, так и налогового учета в системе)
2. Реализовано ведение серийного (партионного) учета материалов и готовой продукции
3. Организовано получение производственной себестоимости в разрезе заказов
4. Настроено получение необходимой регламентированной Бухгалтерской и Налоговой отчетности (в том числе и консолидированной)
1. Автоматизирован учет спецификаций покупателей, расчет плановых калькуляций по спецификации
2. Реализован контроль исполнения спецификации покупателя на всех этапах (производство - количество, продажа - количество, цена), в том числе по срокам исполнения
3. Взаиморасчеты с покупателями в разрезе спецификация/строка спецификации.
4. Настроен механизм автоматического формирования документов и расчета цены между собственными юридическими лицами.
В ходе реализации проекта были автоматизированы следующие направления производственной деятельности.
Увеличение гособоронзаказа и ужесточение контроля за расходованием средств, выделенных на его реализацию, потребовали от предприятий машиностроительного комплекса совершенствования систем управленческого учёта. В рамках реализации программы по перевооружению и модернизации Российской армии выросли объёмы заказов, вследствие чего предприятиям стало сложнее своевременно и по адекватным ценам выпускать оборонную продукцию. Кроме того, в отрасли явно наметилась тенденция укрупнения. 60% оборонной продукции в настоящее время выпускается крупными машиностроительными холдингами. Для отслеживания ситуации на производстве в режиме реального времени и эффективного ведения управленческого учёта в соответствии с требованиями современного законодательства на таких предприятиях необходимо активно использовать новые технологии.
В связи с масштабным техническим перевооружением предприятия оборонно-промышленного комплекса закупают станки с ЧПУ и создают автоматизированные системы управления. Как правило, такие АСУ выстраиваются на базе целого комплекса специализированных программных продуктов: ERP, HRM, САПР, СЭД, CPM, EAM, PLM, CAD, CAM, PDM и т. д. Информационные системы различных классов органично интегрируются между собой, вследствие чего выстраивается современное смарт-производство. АСУ полного жизненного цикла изделий позволяют предприятиям выпускать более конкурентоспособную и высокотехнологичную продукцию.
Наиболее востребованным IT-решением на объектах ОПК на протяжении последних 5 лет остаются системы класса ERP. Их доля среди всех составляющих IT-инфраструктуры достигает 35% .
За счёт использования «1С:ERP Управление предприятием 2» на заводах и объектах ОПК, ведущих научно-исследовательскую работу, обеспечивается:
На сегодняшний день в плане задач управления производством мы имеем две парадигмы. Одна из них заключается в составлении оптимальных расписаний работы технологического оборудования в цехах . Эта задача решается с помощью соответствующих инструментов - на цеховом уровне с помощью MES-систем (Manufacturing Execution Systems) и на уровне предприятия - с помощью APS-систем (Advanced Planning & Scheduling Systems). В основе исходных данных для планирования продукции лежат технологические процессы выпускаемых изделий (ТП) и сроки их выпуска.
Вторая парадигма управления предприятием заключается в управлении бизнес-процессами (БП). К бизнес-процессам обычно причисляют все процессы на предприятии, которые не относятся к ТП. К ним относятся процессы конструирования, разработки технологических процессов, подготовки производства, вся операционная деятельность складских, материально-технических и других служб предприятия. Выбор инструментария для процесса управления БП достаточно широк - от отдельных программных оболочек, поддерживающих либо нотации IDEF, либо универсальный язык UML (Unified Modeling Language), до соответствующих модулей ERP-систем (Enterprise resource planning).
Если управление производством как составление расписаний работы технологического оборудования является задачей хорошо изученной и поддающейся автоматизации и управлению во времени, то задачи управления БП в настоящий момент пока еще находятся на стадии развития, на стадии формализации описания и регламентации . Объясняется это достаточно просто. Процессы регламентации и формализации ТП прошли испытание временем, образ формального представления ТП отрабатывался практически на протяжении целого столетия. Благодаря этому ТП, описанный в одной стране, без проблем понимается специалистами другой страны. Такие понятия, как операция, переходы, обрабатываемые поверхности, режущий и мерительный инструмент, станочная оснастка, порядок и режимы обработки, операционная и маршрутная карта, - все, что составляет суть и форму ТП, давно является понимаемым однозначно всеми специалистами в области машиностроения. И этот факт позволяет легко планировать ТП, поскольку известны все необходимые параметры - количество операций каждого ТП, состав, длительность, требуемые ресурсы и прочие параметры.
В отношении БП попытки управлении и планирования только еще предпринимаются, как уже было сказано, на уровне регламентации процессов. Используемые для описания БП конструкции в нотациях IDEF0, IDEF3 и др. служат для описания единичных процессов. С помощью этих конструкций можно понять логику лишь одного рассматриваемого процесса, - состав, порядок, условия предшествования, требуемые ресурсы, но с помощью этих конструкций невозможно составить модель управления n процессами во времени. А таких процессов, даже если исключить все ТП, на крупном предприятии может оказаться до нескольких тысяч. При этом один и тот же ресурс может быть задействован в нескольких операциях различных процессов. Какой из этих процессов надо выполнить в первую очередь? Что будет, если мы допустим некоторую задержку в исполнении того или иного БП? Как учесть ресурсы при планировании БП?
Вопросов возникает много и мы видим, что для того, чтобы управлять БП, необходимо не только их найти на предприятии и регламентировать, например, в процессе внедрения ERP-системы. Необходимо их учитывать в общей модели планирования производством и получать расписание для БП во времени. Управление БП должно подчиняться той же парадигме управления, что и управление ТП - планированию во времени.
Управление любыми процессами на предприятии заключается в последовательном решении трех задач:
1) Составление полного перечня процессов на предприятии.
2) Регламентация процессов.
3) Планирование процессов во времени.
С точки зрения планирования все процессы, включая технологические (производство изделий в цехах предприятия) равнозначны между собой, поскольку любой процесс можно представить в виде множества операций (стадий), каждой операции можно сопоставить тот или иной ресурс для выполнения.
Поскольку задачи определения множества ТП и их регламентация являются решенными, то на первом этапе необходимо решать аналогичные задачи для БП. Задача составления полного перечня БП должна решаться путем анализа всех заказов предприятия на его структурно-функциональной схеме (рис.1).
При этом анализу подлежит жизненный цикл заказа. Отслеживается весь путь, который проходит заказ, от заявки со стороны заказчика, до отгрузки готовой продукции и на каждом этапе для каждого подразделения, через которое проходит заказ, определяется состав БП, связанный именно с этим заказом. Проанализировав все входящие заявки, можно определить состав и мощность всего множества БП.
По сути дела большинство БП возникает как следствие необходимости выполнения ТП, т.е. выполнение большинства БП можно отнести к комплектации ТП.
Под задачей комплектации ТП и соответствующих им единиц планирования (ЕП) в задачах составления расписаний работы предприятия будем понимать процедуру, которая отвечает за то, что для изготовления данной ЕП имеются в наличии: все необходимые материалы, все технологические и вспомогательные ресурсы, все комплектующие, вся оснастка, весь инструмент, все нормы и вся документация. Если все это имеется в наличии, то изготовление данной ЕП можно смело планировать во времени. Эта процедура должна выполняться по отношению ко всему составу номенклатуры запуска, которой в дальнейшем будет оперировать система APS.
Рис.1. Анализ жизненного цикла заказа
Несмотря на очевидность этой, на вид, простой процедуры комплектации, общая задача планирования для систем APS очень часто превращается в некий снежный ком, который растет по мере анализа номенклатуры изделий, предназначенных к запуску. Рассмотрим детально эти проблемы.
Допустим, что у нас есть некая ЕП e i (рис.2), представленная технологическим процессом в виде множества операций { e ij , j=1,...,p i } . Для каждой операции известны необходимые для выполнения: ресурсы, оборудование, инструмент, оснастка, комплектующие, документация и пр. В процессе комплектации при проверке какой-либо j-й операции может оказаться, что для нее требуется специальный инструмент, который не может быть приобретен в силу уникальности, а следовательно, должен быть изготовлен раньше, чем начнется по плану j-я операция. На j+1-й операции может оказаться, что для нее требуется специальное приспособление и этого приспособления не только не в наличии, но оно даже не спроектировано. И, наконец, на какой-либо k-й операции анализ покажет, что, во-первых, необходимо приобретение стандартных комплектующих, которых нет на складе предприятия, и нет специального мерительного инструмента, который еще предстоит разработать и изготовить. Все то, что мы указали в качестве недостающих ресурсов для выполнения технологических операций, - наших ЕП, необходимо обеспечить к моменту их начала.
Рис.2. Процессы комплектации единицы планирования
Мы видим, что даже один ТП изготовления ЕП может породить множество других процессов - бизнес-процессов, вспомогательных производственных процессов. Самый простой способ достижения цели своевременного обеспечения ресурсами какой-либо ЕП - спланировать во времени только ТП рассматриваемой ЕП и отложить длительности всех остальных процессов на временной оси влево так, чтобы моменты окончания всех вспомогательных процессов не превышали моменты начала выполнения соответствующих технологических операций ЕП. Но, к сожалению, это можно сделать только на бумаге. Поскольку все вспомогательные, по отношению к ТП, единицы планирования, процессы выполняются людьми, специалистами, станками, которые на текущий момент времени также являются занятыми. Это означает, что планировать надо не только множество номенклатуры изделий портфеля заказов. Планированию во времени в системах APS подлежат все процессы, как основные, относящиеся к ЕП из портфеля заказов, так и вспомогательные, без которых изготовить эти ЕП не представляется возможным.
Следовательно, множество ЕП, после процедуры комплектации будет состоять из ЕП, полученных как от детале-сборочных единиц (ДСЕ), так и от всех других работ, перечень которых был определен на этапе комплектации, т.е.
Где М - множество ЕП из портфеля заказов для APS, М К , М T , М б , М В , - множества ЕП, связанных, соответственно, с такими вспомогательными процессами, как: конструкторские, технологические, различные бизнес-процессы, вспомогательные производственные процессы.
Соответствующим образом можно отразить и все множество ОУ для процесса планирования в APS с учетом комплектации:
Где - множество рабочих центров (РЦ) предприятия, используемых для выпуска продукции портфеля заказов, N К , N T , N б , N В , - множество таких обслуживающих устройств (ОУ), как: конструкторов, технологов, специалистов, задействованных в бизнес-процессах, РЦ, задействованных только во вспомогательном производстве, соответственно.
При этом надо учесть, что кроме указанных выше БП, связанных с выпуском продукции, существует ряд БП, которые напрямую с производством и с выпуском портфеля заказа предприятия не связаны.
Кроме БП, относящихся к производству, существует ряд БП, относящихся к функционированию и жизнеобеспечению предприятия. К таким процессам относятся:
- предупредительно-плановые ремонты оборудования (ППР);
- процессы обеспечение предприятия электроэнергией и ремонт энергосетей и средств электроавтоматики;
- процессы теплоснабжения, водоснабжения и аналогичные процессы;
- процессы строительства и ремонта зданий и коммуникаций предприятия;
- и другие процессы.
Эти процессы, на первый взгляд, не всегда относящиеся к основному производству, также необходимо планировать в общей массе работ, т.е. учитывать во множестве на определенном горизонте планирования, поскольку может оказаться, что в связи с ремонтом тот или иной производственный участок может иметь в определенные сроки сокращенный фонд времени. Или может оказаться, что в мероприятиях по ППР задействуются цеховые наладчики, т.е. может возникнуть случай, когда те или иные ресурсы будут задействованы как в группе БП, относящихся к производству, так и в БП жизнеобеспечения предприятия. Таким образом, с учетом этих БП наши множества (1) и (2) перепишутся соответственно
Где М y - множество БП, не связанных непосредственно с производством продукции и вспомогательными БП, а N y - множество ОУ, на которые планируется выполнение множества М y .
Все множество процессов укрупнено можно представить на рис.3, где видно, что наравне с ТП, которые могут являться инициаторами нескольких различных бизнес-процессов - от проектирования конструкции и заказа материалов до производственных процессов изготовления инструмента или оснастки, существуют БП, не пересекающиеся с другими. При этом генерация БП может происходить иерархически, - когда БП, необходимые для изготовления основной продукции порождают новые БП, т.е. может появиться несколько уровней соподчиненных БП.
Все БП, относящиеся к одному и тому же i-му заказу из общего портфеля заказов, объединяет одно - момент сдачи заказа . Это значительно облегчает задачу в том плане, что становится ясно, что порядок выполнения любых БП, порожденных заказами, зависит, прежде всего, от срока сдачи самого заказа. Единственное, что необходимо добавить в модель планирования - это отношения предшествования между отдельными БП (на рис.3 это показано стрелками, соединяющими отдельные БП), например, для нашего случая (см. рис.2) будут справедливы записи вида 
и . Чтобы обеспечить в такой сложной структуре процессов их своевременность относительно сроков изготовления основных ДСЕ, нет необходимости устанавливать директивные сроки на остальные вспомогательные процессы. Достаточно того, что в модели планирования будет присутствовать директивный срок выпуска для самой ДСЕ.
Необходимо отметить, что появление всех БП на предприятии обусловлено теми или иными заказами.
После того, как мы получим полное множество процессов (3) и ОУ - (4), и все эти процессы прошли этап регламентации, можно приступать к их планированию. Для планирования всех процессов на уровне предприятия наиболее удобным инструментом могут являться APS-системы.
Рис.3. Иерархия бизнес-процессов предприятия
Задача планирования в APS-системах с учетом представленного способа комплектации в определенной мере усложняется, когда по результатам анализа ТП те или иные ДСЕ требуют такого предварительного обеспечения, как разработка и проектирование уникальной оснастки и инструмента, как это было представлено на нашем примере (см. рис.2).
Дело в том, что пока не будет разработана конструкция, не будет разработан ТП, пока не будет разработан ТП с указанием точных норм времени на операции, невозможно запустить планирование операций.
Еще большая проблема возникает при поступлении на предприятие сторонних заказов, которые требуют разработки конструкции и технологического процесса самого изделия. При этом от APS-системы требуется за непродолжительный период определить возможность выполнения заказа в определенные заказчиком сроки, либо определить возможные сроки выдачи готового заказа. В этих случаях рекомендуется использовать укрупненные процессы и нормы времени для всех этапов - конструкторского, технологического и производственных, опираясь на процессы аналогичных изделий, которые уже выпускались предприятием ранее. При этом желательно заложить в нормы времени некий страховой запас. Если это не представляется возможным, то прежде чем начать планирование подобных заказов, необходимо сначала разработать конструкцию и ТП изделия, а уж потом начинать его планирование. При этом общий заказ, по сути, разбивается на два заказа, где первый заказ - это разработка конструкции и ТП, а второй заказ - изготовление изделия.
Диаграмма такого комплексного плана будет включать в себя все ОУ, как основные - РЦ на множестве N , так и вспомогательные (рис.4).
Рис.4. Общая диаграмма Гантта для систем APS
В дальнейшем это большое расписание необходимо разделить на отдельные расписания - для основного производства, для вспомогательного производства, для конструкторского и технологического отделов, для остальных служб предприятия, участвующих в общем плане выпуска продукции на множествах (3 - 4).
Все частные расписания будут составлены с одинаковой точностью, поскольку являются частью общего расписания. Каждое подразделение будет работать в соответствии со своим расписанием, но точность выполнения этого расписания будет сказываться непосредственно на общем расписании работы предприятия. Эти особенности повышают требования как к алгоритмам планирования систем APS в плане их точности, так и к процессам нормирования всех работ, дисциплине выполнения частных графиков работы. Кроме того, основным требованием для полноценного планирования с помощью систем класса APS является научная обоснованность и достоверность всех норм времени, как на технологические, так и на все операции, связанные со вспомогательными процессами.
Таким образом, можно сказать, что любые БП появляются либо как следствие необходимости выполнения производственных процессов, связанных с изготовлением продукции, либо как следствие необходимости поддержания жизнедеятельности предприятия.
В результате планирования мы получим полную картину выполнения всех процессов предприятия во времени. При этом каждое подразделение предприятия получает свое расписание (см. рис.4), которое связано с расписаниями других подразделений, хотя на первый взгляд может показаться и независимым. При этом выполнение плана каждым подразделением предприятия должно подчинено общему критерию планирования, например, критерию максимизации прибыли предприятия. В случае наличия различных частных критериев для каждого подразделения задача планирования решается как задача составления расписания для нескольких цехов с разнородным составом критериев, входящих в общий функционал модели планирования.
2010 Загидуллин Равиль Рустэм-бекович,
докт. техн. наук, проф. кафедры АТП Уфимского Государственного Авиационного Технического Университета
Литература:
1. Загидуллин Р.Р. Оперативно-календарное планирование в гибких производственных системах. - М.: Издательство МАИ. - 2004, - 208с.
2. Загидуллин Р.Р., Зориктуев В.Ц. Вопросы оперативно-календарного планирования и управления в машиностроении. Мехатроника, Автоматизация, Управление, - 2005, - № 8, - С.49 - 55.
3. Елиферов В.Г., Репин В.В. Бизнес-процессы: Регламентация и управление. М.: ИНФРА-М. - 2009, - 319 с.
4. Загидуллин Р.Р. Построение моделей межцеховых расписаний в подсистемах оперативно-календарного планирования автоматизированных производств. СТИН, - 2004, - №8, - С.3 - 8.
Для начала о самом проекте: внедрение 1С:ERP на промышленном предприятии. Когда мы пришли к клиенту (в 2015г), численность завода составляла 5 тысяч человек. За время проекта завод существенно вырос и нарастил объемы производства, сейчас на нем работает порядка 6,5 тысяч сотрудников. 1С установлена на 1,2 тыс. рабочих мест. Активно работающих пользователей сейчас (июнь 2017г) порядка 350, планируется увеличение до 450ти.
Предприятие входит в военно-промышленный комплекс России, и, следовательно, имеет свою специфику.
До этого проекта я запускала средние предприятия (1000-1500 сотрудников, 50-150 рабочих мест). Делать их мы уже научились, выработав четкую методологию (сейчас у меня с командой среднее время перевода проекта в промышленную эксплуатацию 7-10 месяцев, в зависимости от его сложности.)
Но, как оказалось, на численности предприятия больше 2,5х тысяч сотрудников происходит качественный скачок сложности проекта, который требует пересмотра технологии.
Итак, по порядку. На завод мы пришли в конце 2015г. Изначально стояла задача запуска регламентированного учета. По ходу функционального моделирования руководство Заказчика (с подачи главного бухгалтера) приняло решение о передачи функции ввода первичных документов «на места». Границы проекта были пересмотрены, включив в себя центральные склады, кладовые, цеховую бухгалтерию, управление договорами и БДДС. Сроки внедрения регламентированного учета были сдвинуты на 2017г, а в течение 2016г автоматизировалась «первичка».
Решение о том, что функциональные блоки будут запускаться в опытно-промышленную эксплуатацию (далее по тексту – «ОПЭ») поэтапно, хоть и принесло нам много головной боли, глобально оказалось правильным: запустив всех сразу, мы бы просто утонули в вале проблем, о которых я расскажу позже.
Если честно, то я думала, что главной сложностью будет саботаж со стороны пользователей. До внедрения 1С те ничего никуда централизованно не вводили: кто-то работал в Excel, кто-то - в самописных системах. Основой документооборота были «бумажки», которые потом сдавались в АСУП для ввода операторами в бухгалтерскую программу. Здесь проектная команда со стороны Заказчика грамотно подошла к вопросу – был выпущен ряд приказов, подписанных генеральным директором, которые закрыли проблему. Приказы оформлялись не в привычном стиле «на нашем предприятии запускается система…», а были вполне конкретными «с такого-то числа бухгалтерия принимает от складов только документы, выписанные из 1С». Для снятия возможного недопонимания мы сразу включили штриховое кодирование документов и раздали бухгалтерии сканеры (реально были попытки сдать документы, «нарисованные» людьми в Word).
Последовательность запуска определили следующим образом: центральные склады, договора, БДДС, цеховые кладовые, цеховая бухгалтерия, а по итогам – уже регламентированный учет, который тоже разбили на отдельные функциональные участки.
Первая (хотя и не основная) проблема была вполне предсказуема – это объемы данных. Однако масштабы ее я изначально недооценила. Для примера – просто загрузка (безо всякой обработки) остатков по «малоценке» занимает около 4х суток. А если по итогам вдруг обнаруживаются расхождения, то еще четверо суток, а потом еще.… То есть этот этап работ надо при планировании очень тщательно прорабатывать вместе с заказчиком, буквально по дням. Например, здесь мы пошли по обычному пути: загрузили только справочники и посадили пользователей бить «первичку», чтобы после окончания загрузки остатков, все провести, проверить и выйти на оперативный учет. В итоге мы физически не успели до конца месяца свести учет и начислить погашение стоимости, и чтобы сдать управленческую отчетность, пришлось руками переносить из старой системы суммы затрат, а потом их корректировать из-за разных методик учета.
Так же многих нужных данных в нормальном виде у заказчика нет, и соответственно просить их подготовить надо сильно заранее: например, список открытых заказов нам начали собирать за три (!!!) месяца. Казалось бы, чего уж проще? Предприятие должно владеть информацией, что кому и когда оно должно произвести и отгрузить. Но, как оказалось, в формализованном виде у них были только номера заказов (требование по организации раздельного учета по Гособоронзаказу), а наименование продукции, количество, сроки и т.д. хранились либо где-то в Excel, либо в бумажных договорах.
В последующих проектах мы с клиентами начинаем подготовку к переносу данных сразу же после первого этапа проекта - функционального моделирования.
И масштабы ручной работы надо всегда держать в голове при проектировании: например, изначально при проектировании взаиморасчетов клиент хотел разбить задолженность по этапам договоров, но проанализировав вместе с нами трудозатраты подготовительной работы, от этой идеи отказались.
Также большое количество «первички» повышает стоимость ошибок: если ты вдруг забыл о заполнении какого-то реквизита или научил заполнять его неправильно (что, к сожалению, случается), то никак не получится «быстренько все прошерстить руками». В лучшем случае правильно заполненные данные ты получишь со следующего месяца. То есть на таких проектах можно использовать только очень опытную проектную команду – «косяки» новичков можно просто не суметь исправить.
В добавок подобные масштабы предъявляют специфичные требования к опытно-промышленной эксплуатации: обычно на простые участки (например, центральные склады) я закладываю полтора-два месяца поддержки, этого вполне достаточно, чтобы отработать блок. А здесь некоторые кладовщики начали всерьез анализировать данные в программе только через 3 месяца. То есть до этого они просто учились вносить документы в систему. Получилось, что в ходе работ по запуску уже других участков приходилось отвлекать ресурсы на поддержку закрытых функциональных блоков. Это надо учитывать при планировании людей и бюджета.
Отдельно стоит упомянуть организацию информирования пользователей программы. Надо заранее встраивать в конфигурацию модули для вывода обязательных сообщений: обзвонить 350 человек и сказать, что обновилась инструкция или что сегодня будет запускаться расчет себестоимости, нереально. Здесь нам сильно помогла заплатка из БСП (библиотека стандартных подсистем).
Помимо описанной выше проблемы масштаба, второй и основной проблемой проекта стало то, что на предприятии не оказалось людей, которые полностью владеют работой какого-то учетного участка. Сначала я думала, что это особенности только данного завода, но сейчас понимаю, что для крупных организаций такая ситуация скорее норма. Есть несколько ключевых пользователей, которые ведут какой-то свой «кусочек» и есть руководитель отдела, который имеет свое представление о том, как они работают. И между ними – пропасть.
Как я работала до этого: по каждому процессу определялся его Владелец, который формировал по нему требования, мы разрабатывали схему работы, проходились по ней с ключевыми пользователями, после чего утверждали у владельца. Обычно такая методика хорошо закрывает 80% операций, а оставшиеся 20 «подрихтовываются» на этапе опытно-промышленной эксплуатации. По этому пути мы пошли и здесь. Разница между реальностью и представлениями руководителей отделов проявилась практически сразу же. Но начальники говорили «не может быть!», а подчиненные в силу корпоративной культуры им не возражали. В итоге утвержденная схема работы содержала часть слишком трудоемких операций, много избыточных контролей и не содержала определенного количества того, «чего у них точно не бывает». Все это пришлось переделывать в ходе опытно-промышленной эксплуатации. Уже реализованные и сданные доработки в итоге были кардинально переписаны, а сама ОПЭ потребовала постоянного присутствия программистов.
К проблеме «размазанности» знаний о каждом процессе между десятками людей, добавилось большое количество, вроде бы, однотипных отделов (только центральных складов у них порядка 30), которые при схожести функций, имели свою специфику и свои особенности учета – а это значит, что даже одинаковые операции могут выполняться несколькими способами. Лозунг «унификация процессов», заявленный на старте проекта, умер в ходе первого боевого запуска.
Анализируя, по итогам, проект, я пока не вижу способа особо снизить риск значительного расхождения между описанными процессами и реальностью: чтобы подробно проработать схему с каждым подразделением, а потом еще – с их руководителями, бюджет Функционального моделирования придется увеличивать в 5-7 раз, а заказчикам обычно сложно понять ценность данного этапа и заплатить 25% от стоимости проекта просто за «бумажку». Была мысль о тестовом прогоне системы на нескольких подразделениях, которую я попробовала на другом проекте, но в полной мере она себя не оправдала.
На текущий момент я определила для себя, что на подобных по масштабу проектах придется смириться с итерационной доработкой – просто правильно ее организовать, и сразу заложить в оценку работу программистов на всю опытно-промышленную эксплуатацию, и увеличить сроки поддержки пользователей минимум в два раза.
Третья проблема проекта вытекает из первых двух: большое количество пользователей (для которых нужно много консультантов) и большое количество проектных решений, которые принимаются прямо на этапе ОПЭ. А так как в ERP одну и ту же задачу можно решить различными способами, то разные консультанты используют разные методы, и в итоге система начинает «расползаться». Никакие «совещания по итогам дня» здесь не помогают, потому что из-за объема разных вопросов консультанты многое к вечеру уже просто забывают.
На будущее я буду вводить в такие проекты отдельного архитектора, который на время ОПЭ будет изолирован от пользователей, и через которого будут приниматься все проектные решения. Он же будет ежедневно актуализировать пользовательские инструкции (на большом количестве пользователей они реально нужны).
Что в итоге? Несмотря на шишки, слезы и седые волосы, управленческий блок у клиента запустили. Сейчас перешли к регламентированному. Надеюсь, что опыт, полученный на первых этапах, поможет в его запуске.
Внедрение системы SSA ERP (Baan) на современном машиностроительном предприятии: «Уфимском моторостроительном производственном объединении» Ольга Александровна Третьякова, Руководитель направления SSA ERP (Baan) в Северо- Западном филиале компании GMCS GMCS «Искусство управления большими проектами сродни таланту дирижера, каждый взмах рук которого соединяет многообразие звуков в великие симфонии».
General Management Consulting Services О компании GMCS GMCS – General Management Consulting Services – основана в 1997 году, входит в группу компаний «Компьюлинк» с 2005 года Почему клиенты выбирают GMCS? GMCS – мульти продуктовая компания, партнер 4-х лидирующих мировых поставщиков ERP-систем Более 200 успешно реализованных проектов в России и за рубежом /Греция, Италия, Казахстан, Молдова, Эстония, Румыния, Польша/ Более 270 высококлассных специалистов Опыт сотрудников в ИТ-консалтинге от 5 до 8 лет Экспертиза в более чем 15 отраслях
Услуги GMCS О компании GMCS Ключевые аспекты управления на базе ИТ: Управленческий и ИТ-консалтинг Выбор программного решения для управления предприятием Поставки лицензий информационных систем Внедрение ведущих ERP/CRM-систем Аудит проектов внедрения информационных систем Обучение пользователей систем Адаптация ПО к требованиям предприятий, разработка решений Техническая поддержка информационных систем
Microsoft: Microsoft Dynamics AX (Microsoft Axapta), Microsoft Dynamics CRM, Microsoft Office Accelerator for Sarbanes-Oxley (MOSASO) Oracle: Oracle E-Business Suite, Oracle Financial Analyzer/Oracle Enterprise Planning & Budgeting, Oracle CRM SAP CIS: mySAP Business Suite, mySAP All-in-One, SAP NetWeaver, SAP Business One SSA Global: SSA ERP (Baan), SSA ERP LN (Baan 6.1) «Босс. Кадровые системы»: «БОСС-Кадровик» О компании GMCS Продуктовая линейка
Клиенты Атомная промышленность Дистрибуция Логистика и транспорт Машиностроение и производство оборудования Нефтегазовая промышленность Пищевая промышленность и с/х Полиграфическая промышленность и упаковка Потребительские товары FMCG Связь и телекоммуникации Строительная индустрия Розничная торговля и общественное питание Фармацевтическая промышленность Химическая промышленность и др. О компании GMCS
Год образования г. Численность персонала - более 19 тыс.чел. Количество самостоятельных подразделений в объединении Отрасль - машиностроение Виды выпускаемой продукции: авиационные двигателя и узлы газо энергетические установки снегоходы мотоблоки и др. гражданская продукция Уфимское Моторостроительное Производственное Объединение
Объединение имеет лицензию на производство авиационной техники Система качества отвечает требованиям ISO-9001 УМПО имеет сертификат качества, выданный органом сертификации TUV CERT (1997 г Германия), а также сертификат соответствия в системе Оборонсертифика, выданный органом Союзсерт Применяются такие уникальные технологии, как «Вакуумное литье сложно- профильных лопаток», «Ионная имплантация, точное литье титановых сплавов с газостатированием отливок», «Штамповка заготовок в режиме сверхпластичности» и др. Имеет в наличии все типы производства Уфимское Моторостроительное Производственное Объединение Освоен выпуск 51 модели авиационных моторов, которые устанавливались на 168 типах и модификациях военных и гражданских самолетов серии МиГ, Су и Ту Двигатели марки УМПО эксплуатируются в 49 странах мира Более 50-и крупных заказчиков в России и за рубежом – в Индии, Китае, Вьетнаме, Южной Корее
2. Проектирование и инженерный анализ изделий – CAD/CAE САПР конструкций основных изделий 5. Разработка технологических процессов изделий и УП на станки с ЧПУ - CAM САПР ТП 7. Испытание изделий АСУТП - испытание 8. Эксплуатация изделий Мониторинг эксплуатации 6. Производство изделий SSA ERP (Baan) Реализация CALS-технологии на ОАО УМПО САПР CAD/CAM CAE Baan ERP PDM Сопровождение жизненного цикла изделия 1. Маркетинговые исследования и стратегическое планирование Техническое задание на изделие 3. Материально- техническое снабжение SSA ERP (Baan) 4. Проектирование и инженерный анализ тех. оснастки САПР конструкций технологической оснастки и НСО
Причины выбора системы SSA ERP (Baan) Опыт внедрения на других предприятиях ВПК в России и за рубежом Наличие у системы SSA ERP (Baan) референтной модели, описывающей бизнес-процессы предприятия Использование в SSA ERP (Baan) методологии плавного реинжиниринга, не требующей одномоментного изменения бизнес- процессов предприятия
Менеджеры функциональных направлений ТПП Снабжение Производство Сбыт Бюджетирование и контроллинг Финансовые расчеты Бухгалтерский учет Начальник планово- экономического отдела Заместитель директора основного производства Руководитель службы снабжения Начальник финансового отдела Главный бухгалтер Директор по сбыту Главный технолог
Ход работ Период Содержание работ 2001 июнь-декабрь Подготовка проектного решения, тестирование 2002 январь-июнь Управление закупками, учет движения запасов, учет производства 2002 июль-декабрь Переход c Baan IV на Baan V 2003 январь-декабрь Управление продажами, Управление расчетами с контрагентами, Материальный учет 2004 январь-декабрь Управление проектами по подготовке новых изделий, учет инструмента 2005 январь-декабрь январь-декабрь Управление затратами, Планирование
Связь SSA ERP (Baan) и АСУ УМПО Планирование производства Ведение НСИ УМПО Планирование производства Ведение НСИ SSA ERP (Baan) ERP Управление закупками Движение запасов Цеховое управление SSA ERP (Baan) ERP Управление закупками Движение запасов Цеховое управление
Проблемы внедрения, решенные в гг. Несоответствие части бизнес-процессов предприятия типовым процессам «западной» авиационно-космической отрасли. Низкая производительность компьютерной сети объединения (скорость порядка 2 мегабит/сек). Предельная загрузка и нехватка вычислительной мощности рабочего сервера «БААН» (одновременно не более 170 сеансов).
Результаты на начало 2005 Контроль выполнения контрактов Контроль поставок по номенклатуре, срокам с учетом разрешенных замен Планирование цен закупок Автоматическая сверка счетов-фактур с поставкой Контроль сроков погашения задолженности с учетом условий и графиков платежа Автоматическое формирование проводок Закупки, Финансы
Результаты на начало 2005 Нормативная калькуляция ДСЕ Учет запуска производственных партий, формирование сопроводительных документов Учет списаний под производственные заказы Пооперационный учет выполнения заказов Учет выпуска, формирование сопроводительных документов Учет брака Учет технологических отходов и излишков Контроль незавершенного производства Производство
Результаты на начало 2005 Контроль выполнения контрактов Контроль отгрузки с учетом условий оплаты и задолженности клиента Контроль отгрузки по номенклатуре контрактов Контроль сроков погашения задолженности с учетом условий и графиков платежа Автоматическое формирование счетов-фактур и отгрузочных документов Продажи, Финансы
Результаты на начало 2005 Контроль качества поставок Контроль хранения Контроль нормативных запасов, переоценка Контроль движения запасов в разрезе партий качества Контроль неликвидов Автоматическое формирование проводок Проведение инвентаризаций Запасы, Финансы
Результаты на начало 2005 Бухгалтерский, налоговый, управленческий учет основных средств Расчеты с банками Расчеты через кассу, ведение подотчетников Интеграция с подсистемой ведения НСИ Интеграция с подсистемой планирования Интеграция с подсистемой расчета зарплаты Прочие результаты
Партия запуска в SSA ERP (Baan) = партии выпуска. Планирование происходит на основе времен операций в технологическом маршруте Планируется дата запуска и дата выпуска, контролируются они же. Нет дефицита оперативных совещаний. Из возможных вариантов выбора размеров партии предлагается выбрать планирование от потребности Наличие меж участковых и межцеховых сдвигов – в SSA ERP (Baan) определяется в маршруте исходя из технологии или в параметрах перемещения –для готовых деталей. Различия в планировании SSA ERP (Baan) и ОАСУП
Наши координаты GMCS , Москва, Мичуринский пр., д URL: Тел./Факс: : +7 (495) , Cанкт-Петербург Большой пр. В.О., д. 80 Бизнес-центр «Сенатор» Тел.: + 7 (812) , Факс: +7 (812) Спасибо за внимание!
