Дети

Применение erp системы на машиностроительном предприятии. ERP для машиностроительных предприятий. Исходная проблема и задачи

Для начала о самом проекте: внедрение 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 одну и ту же задачу можно решить различными способами, то разные консультанты используют разные методы, и в итоге система начинает «расползаться». Никакие «совещания по итогам дня» здесь не помогают, потому что из-за объема разных вопросов консультанты многое к вечеру уже просто забывают.

На будущее я буду вводить в такие проекты отдельного архитектора, который на время ОПЭ будет изолирован от пользователей, и через которого будут приниматься все проектные решения. Он же будет ежедневно актуализировать пользовательские инструкции (на большом количестве пользователей они реально нужны).

Что в итоге? Несмотря на шишки, слезы и седые волосы, управленческий блок у клиента запустили. Сейчас перешли к регламентированному. Надеюсь, что опыт, полученный на первых этапах, поможет в его запуске.

Система экспертизы при внедрении ERP на машиностроительных предприятиях Тихонов А. Н. Директор Государственного научноисследовательского института информационных технологий и телекоммуникаций ГНИИ ИТТ «Информика» Слайд № 1

Внедрение достижений фундаментальной и прикладной науки: обеспечивает экономическое развитие; укрепляет национальную безопасность; позволяет интегрироваться в мировую экономику. ИПИ-технологии обеспечивают: качество сложной машиностроительной продукции; соответствие такой продукции международным стандартам. Слайд № 2

Внедрение ИПИ-технологий промышленности США: прямое уменьшение затрат на проектирование – от 10 до 30%; сокращение времени разработки изделий – в 1, 5 -2 раза; сокращение времени вывода новых изделий на рынок – от 25 до 75%; уменьшение доли брака и объема конструктивных изменений – от 23 до 73%; сокращение затрат на подготовку технической документации – до 40%; сокращение затрат на разработку эксплуатационной документации – до 30%. По сведениям зарубежных источников потери от несовершенства информационного взаимодействия с поставщиками только в автомобильной промышленности США оцениваются в сумме порядка 1 млрд. долларов в год. Слайд № 3

Для внедрения ИПИ-технологий необходима линейка программных продуктов, сопровождающая изделие через все стадии жизненного цикла: Научные исследования Проектноконструкторские работы Технологическая подготовка производства Производство Эксплуатация Утилизация Слайд № 4

Основные компоненты ИПИ -технологий Юридическая независимость Технологическая независимость Информационная безопасность ИПИ-технологии Стандарты, нормативные документы, каталоги PDM ERP CAD / CAE / CAM Проектирование ILS Производство Эксплуатация Слайд № 5

Сложности внедрения ERP-систем в России (%) Основная причина неудач внедрения ERP-систем в России – руководители предприятий не участвуют в проекте, как следствие проект затягивается, дорожает и в конце концов остается невостребованным. Слайд № 6

Способы продвижения ERP-систем на предприятиях: через собственные отделы АСУ, ИТ и т. п. , которые заинтересованы увеличить собственную влиятельность на предприятии оправдывая свое существование; это приводит к удорожанию и усложнению технологической инфраструктуры предприятия; через продавцов ERP-систем, любым образом выходящих на руководителей предприятия с единственной целью – продать и получить прибыль, не заботясь при этом, нужно это предприятию или нет; по рекомендации независимых консультантов; преимущество этого способа состоит в возможности избежать необдуманного приобретения системы за счет анализа проблемы, сложившейся ситуации на данном предприятии; консультанты предлагают варианты, окончательное решение должны принимать руководители предприятия. Слайд № 7

ГНИИ ИТТ «Информика» р а с п о л а г а е т: научно обоснованной методикой анализа и выбора ИПИтехнологий; базой данных независимых экспертов в данной области; опытом решения аналогичных задач в ряде международных проектов и федеральных целевых программ по заданиям Минпромнауки России и Минобразования России; как пример - экспертиза соответствия российской версии ERP-системы Baan. ERP требованиям создания на ее основе базовой системы для предприятий ОПК в сравнении с конкурирующими решениями. Слайд № 8

Экспертиза выбора базовой ERP-системы для предприятий ОПК Учтены: специфика объектов внедрения; их значение для обеспечения экономической и военной безопасности государства. Рассмотрены программные продукты: Baan; R 3 SAP; Oracle e. Business Suite; Галактика; ряд других ERP-систем. Слайд № 9

Ключевые требования ОПК: соответствие особенностям производственного процесса на предприятиях ОПК; соответствие международным стандартам MRPII/ERP систем; реализация наиболее эффективных методов управления предприятиями ОПК; функциональные требования общего характера (для управления производственной деятельностью и предприятием в целом); функциональные требования, учитывающие специфику предприятий ОПК; требования к функциональностям со стороны информационного обеспечения; требования к качеству (соответствие стандартам качества ISO – 9000 версии 2000; апробированность системы; поддержка межверсионной совместимости); средства внедрения, адаптации и расширения функциональностей; технологические и системные требования; требования к локализации и поддержке в соответствии с требованиями эксплуатации на предприятиях ОПК. Слайд № 10

Свойства продукции ОПК: сложные наукоёмкие изделия, агрегаты, сервисы и документация; длительные жизненные циклы; уникальность конфигурации экземпляров готовой продукции; большое число компонентов и уровней входимости; большая номенклатура покупных изделий и материалов; большой поток конструкторских и технологических изменений. Слайд № 11

Особенности производства продукции ОПК: разработка и/или производство на заказ; сочетание единичного и серийного типов; многообразие форм и организации производства; многономенклатурность; длительные производственные циклы; большой удельный вес технической подготовки производства; многообразие технологических процессов – заготовительные, сварочные, литейные, механообрабатывающие, сборочные. Слайд № 12

Особенности процесса управления ОПК: многотемность; сочетание подходов; программно-целевого и линейно-функциональных многоуровневость (стратегическое, текущее, оперативное); сквозной характер (поставщики, производители, заказчики); множественность направлений планирования, учёта и плановоучётных единиц (контракты, проекты, изделия, комплекты, партии, работы, операции и т. п.); широкий спектр способов организации и методов управления; такие специфические приёмы, как группы опережения, серийный счёт, комплектность; специфика планирования и учёта затрат. Слайд № 13

Трудности сравнительного анализа: различия в понимании стандартов ERP-систем в России и за рубежом; различия в функциональной структуре ERP-систем у разных фирм-разработчиков; обнаружение существенных отличий систем лишь на глубоких уровнях их структур; различия в структуре и перечне разумных и достаточных функциональностей, с точки зрения фирм-разработчиков; динамичность представлений о критериях оценки и свойствах систем. Слайд № 14

Необходимые требования к базовой ERP-системе BAAN Oracle e. Business Suite R 3 Галактика Наличие исходных кодов системы у российской компании + - - + Адаптация системы к действующему законодательству со стороны российской компании* + - - + Поддержка и сопровождение системы со стороны российской компании* + - - + Российская собственность российской версии системы + - - + * Учредителями компании являются только российские физические и юридические лица Слайд № 15

Достаточные требования к базовой ERP-системе Oracle e. Business Suite R 3 Галактика Соответствие международным стандартам MRPII/ERP систем + + + - Реализация наиболее эффективных методов управления предприятиями ОПК + + + - Функциональность, учитывающая специфику предприятий ОПК + частично - Архитектура 3 -х уровневая 2 -х уровневая Работа клиентов через Интернет + + + – Web-клиент + + + – Oracle, Informix, Oracle Технологичность и архитектура системы BAAN Поддерживаемые базы данных Слайд № 16

Характеристики качества ERP-систем Трудности получения объективной информации о системах, легко объяснимые конкуренцией на рынке программных продуктов Baan Oracle e. Business Suite R 3 Галактика + + + - Длительность присутствия компании на рынке ERPсистем 25 лет 10 лет Длительность присутствия продукта на российском рынке 9 лет 7 лет 13 лет 10 лет Более 16000 Около 10000 Более 25000 - Более 50 Около 10 Более 100 Около 50002 Наличие внедрений на ведущих предприятиях ОПК России + - - Нет данных Наличие партнёрской сети + + 12 -24 мес. 24 -36 мес. 36 -48 мес. 9 -24 мес. Соответствие стандартам ISO 9000 Общее количество внедрений в мире Число внедрений в России Средняя продолжительность Слайд № 17

Результаты анализа ERP-систем для ОПК: SAP R/3. Лидер на рынке автоматизированных систем управления предприятиями. Однако эти решения используются лишь для управления финансово-бухгалтерскими задачами на уровне управляющих компаний крупных корпораций. Опыт работы в производственных компаниях не столь велик. У SAP R/3 высокая стоимость владения. Исходные коды системы российским партнерам не переданы. Гостехкомиссией сертифицированы лишь средства разграничения прав доступа в систему. Oracle e. Business Suite. Традиционно прикладные решения Oracle (кроме СУБД) используются исключительно для управления финансовой деятельностью компаний. Как и в случае SAP, компания практически не имеет опыта в работе с промышленностью. Локализация и поддержка системы ведется представительством Компании. Исходные коды системы российским партнерам не переданы. Baan. Продукт корпорации SSA Global – лидера среди производителей ПО (до 40 % контроля) для промышленных предприятий. Решения Baan считаются лучшими в мире для предприятий ОПК. Исходные коды системы находятся у российской компании «Альфа. Интегратор» , дорабатывающей систему с учетом требований национального законодательства и обеспечивающей корректный переход пользователей на новые версии системы. Корпорация «Галактика» продолжает попытки создать в своей системе модули управления производством. При разработке системы использованы существующие на российских предприятиях бизнес-процессы без их оптимизации. Предлагаемая модель управления производством отображает подходы времен централизованного планирования, а внедрение подобных решений ведет к отставанию российских предприятий в области управления бизнесом. Слайд № 18

Результаты экспертизы: необходимость в ориентации на применение мощных интегрированных адаптивных базовых ERP-систем; взятие на вооружение российскими компаниями самых передовых подходов к решению задач управления ресурсами, прелагаемых мировыми лидерами ERP-решений; эффективность существенно меньших затрат на информационные технологии (по сравнению с капитальными вложениями в техническое перевооружение предприятий) при сопоставимом влиянии на рост производительности труда. Исходя из вышеизложенного, считаем необходимым и целесообразным рекомендовать российскую версию ERPсистемы Baan, принадлежащую компании «Альфа Интегратор» , в качестве базовой системы для предприятий ОПК России. Слайд № 19

Предложения по структуре системы экспертизы Минобрнауки Минпромэнерго Департамент международных связей и информационных технологий Департамент ОПК Федеральное агентство промышленности Межведомственный совет Федеральное агентство по науке и инновациям ГНИИ ИТТ «Информика» Межведомственный центр по развитию ИПИ-технологий Утверждение Независимые эксперты Результат экспертизы Фирмы разработчики ERP и поставщики оборудования Предприятия Университеты Слайд № 20

Приказ Минпромнауки России № 277 от 23. 12. 2003 «О создании межведомственного центра по развитию ИПИ-технологий» В соответствии с приказом Минпромнауки России от 28 ноября 2003 г. № 264 «Об организации работ по реализации комплексной межведомственной программы повышения качества продукции обороннопромышленного комплекса» и для координации выполнения предусмотренных в указанной программе научноисследовательских работ и пилотных проектов в сфере ИПИ-технологий ПРИКАЗЫВАЮ: 1. Возложить на государственное учреждение «Государственный институт информационных технологий и телекоммуникаций» (Тихонов А. Н.) функции межведомственного центра по развитию ИПИ-технологий (далее Центр), поручив ему организацию и координацию выполнения на предприятиях оборонной промышленности следующего комплекса работ: научных исследований в области ИПИ-технологий; создания и системной интеграции комплекта отечественных программных продуктов в области ИПИ-технологий, обеспечивающих их эффективное внедрение на предприятиях различных отраслей промышленности; анализа и экспертизы зарубежных программных продуктов с целью обеспечения безопасности их внедрения на промышленных предприятиях; обеспечения реализации пилотных проектов внедрения ИПИ-технологий, выполняемых в рамках соглашений с Минобразованием России и российскими агентствами по оборонным отраслям промышленности; создания и обеспечения эффективного функционирования системы переподготовки и повышения квалификации специалистов в области ИПИ-технологий с применением перспективных образовательных процессов, включая дистанционное обучение; организации региональных центров развития ИПИ-технологий; оказания консалтинговых услуг по направлениям деятельности Центра. 2. … Исполняющий обязанности Министра А. Фурсенко Слайд № 21

Перед промышленными предприятиями стоят задачи повышения интенсификации труда, производства. Решение этих задач невозможно без применения современных систем управления предприятием. Для сравнения рассмотрим программные продукты, которые представляют интерес для предприятий авиационного и машиностроительного комплекса: «1С: Предприятие 8», «Парус-Предприятие 8», «SAP R/3», «Microsoft Dynamics Navision» или другое её название «Microsoft Business Solutions Axapta» (прим. автораов: в дальнейшем по тексту «Axapta»).

Среди отечественных систем, следует отметить необходимые для промышленного предприятия решения «1С: Предприятие 8»: «1С:Управление производственным предприятием 8»; «1С:Консолидация 8»; «1С:Управление корпоративными финансами 8»; «1С:Бухгалтерия 8»; «1С:Комплексная автоматизация 8»; «1С:Зарплата и управление персоналом 8»; «1С:Управление торговлей 8»; «1С:Web-расширение 8» .

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

Функциональный состав «ПАРУС-Предприятие 8»: Управление финансами; Управление логистикой; Управление производственными процессами; Управление персоналом; Управление взаимоотношениями с клиентами; Управление деловыми процессами; PARUS-ON-Line.

Всеобъемлющая функциональность решения «Microsoft Business Solutions Axapta», охватывающая абсолютно все аспекты ведения бизнеса, позволяет внедрить современные западные управленческие технологии, оптимизировать ключевые бизнес-процессы и в целом повысить эффективность управления предприятием . В рамках локализации системы для российского рынка реализованы задачи ведения бухгалтерского и налогового учета в соответствии с требованиями российского законодательства, разработаны модули основных средств, налогового учета, расчета заработной платы и кадрового учета.

«MBS Axapta» охватывает бизнес предприятия в целом, как с точки зрения внутренних бизнес-процессов, так и в плане взаимодействия с партнерами и клиентами, а в частности, такие его аспекты, как: анализ и стратегическое управление; управление производством; торговля и логистика; управление финансами; управление проектами; взаимоотношения с клиентами.

«SAP R/3» поддерживает большинство операционных систем. Серверные и клиентские места могут работать под разными операционными системами. Однако порядка 50% ПО SAP инсталляций выполняется на платформе Windows.

Система «SAP R/3» состоит из набора прикладных модулей, которые поддерживают различные бизнес-процессы компании и интегрированы между собой в масштабе реального времени . Состав модулей разнообразен: «Финансы», «Контроллинг», «Управление основными средствами», «Управление проектами», «Производственное планирование», «Управление материальными потоками», «Сбыт», «Управление качеством», «Техобслуживание и ремонт оборудования», «Управление персоналом», «Управление информационными потоками», «Отраслевые решения».

Аппаратные требования для рассматриваемых систем представлены в таблице 1.

Таблица 1 - Аппаратные требования систем.

Вид системы				Клиентское место
Вид системы	Процессор	Оперативная память		Процессор	Оперативная память	Объем свободного места на жестком диске
«1С: Предприятие 8»	Pentium IV, 2,4 ГГц	не менее 512 Мбайт		Pentium III, 1,2 ГГц	128 Мбайт и выше
«ПАРУС-Предприятие 8»	Pentium IV, 2,4 ГГц или выше	516 Mбайт и выше	250Мбайт и выше	Pentium III, 1,2 ГГц	128 Мбайт и выше	250 Мбайт и выше
	Pentium IV, 2,4 ГГц	1024 Mбайт и выше	520Мбайт и выше	Pentium III, 1,2 ГГц или выше	516 Мбайт и выше	520 Мбайт и выше
	Pentium IV, 2,4 ГГц или выше			Pentium III, 1,2 ГГц или выше	128 Мбайт и выше	500 Мбайт и выше

Стоимость и сроки внедрения представленных программных продуктов приведены в таблице 2.

Таблица 2 - Стоимость и сроки внедрения ERP-систем

ERP-система	Срок внедрения	Стоимость внедрения
«1С:Предприятие 8»	3-9 мес. и более	Лицензия на одно рабочее место USD150-600.Стоимотсь внедрения на одно рабочее место USD200-1000
«ПАРУС-Предприятие 8»	4мес. – 1 год и более	Стоимость лицензии на одно рабочее место USD1-2 тыс. Стоимость внедрения 100-200% цены решения
«Microsoft Dynamics Ax 4.0»	6 мес. – 2 года и более	В среднем стоимость решения на одно рабочее место - USD2 тыс. Стоимость внедрения составляет 100-250% стоимости решения
	1-5 лет и более	Лицензия на 50 рабочих мест стоит около USD350 тыс. Стоимость внедрения может в несколько раз превышать стоимость решения

Нельзя сказать, что «1С: Предприятие 8» – полноценная программа для учета на производстве. Недостатком данного программного продукта является то, что производственный учет ориентирован на то, чтобы посчитать себестоимость готовой продукции и прибыль от ее реализации, т.е. в данном продукте нет блока планирования производства, планирования закупок, отслеживания технологических циклов. Работа в системе затрудняется, если производство относится к многономенклатурному (с числом позиций номенклатуры более тысячи), сложной структурой изделия и большим числом промышленно – производственного персонала (более 5 тыс. человек).

К недостаткам «корпорации Парус» относятся слабо развитая партнерская сеть, отсутствие решений по производственному планированию для предприятий авиа – машиностроения.

Обзор функций системы «SAP R3» показывает ее способность решать основные задачи, стоящие перед крупными организациями. «SAP R/3» – это самая обширная система на сегодняшний день. Многие лидеры мировой экономики выбрали именно ее в качестве основной корпоративной системы.

«SAP R/3» – конфигурируемая система, поэтому купив ее, предприятие будет работать с индивидуальной версией, настроенной именно под его параметры. Чем шире возможности конфигурирования и настройки системы, без необходимости ее переписывания, тем выше технический уровень данной системы. По этому показателю «SAP/R3» занимает лидирующее положение в мире. Система обладает открытым и стандартным пользовательским интерфейсом, обеспечивает графическое моделирование бизнес-процессов и может работать в диалоговом режиме. Кроме того, комплекс решений «SAP R/3» включает отраслевые решения для аэрокосмической отрасли.

Отличительные особенности системы «MBS-Axapta» – масштабируемость и широкий спектр возможностей по ее индивидуальной настройке. Они делают данный программный продукт оптимальным решением для средних и крупных предприятий со специфическими и сложными бизнес-процессами, штат сотрудников которых не превышает 10000 человек .

Выделим основные преимущества «Axapta»: исключительная масштабируемость; оптимальное соотношение цены и качества (для её уровня функциональности); легкость обновления приложений; всесторонний анализ и удобство контроля бизнеса; наличие модулей планирования; возможность управлять финансами для международного бизнеса; соответствие требованиям российского законодательства; баланс избыточной информации.

Из представленных программных продуктов, таким образом, наиболее подходящими для промышленных предприятий машиностроения и авиационной отрасли являются системы «Axapta» и «SAP R3».

Для оценки размера инвестиций в ERP-систему, необходимо представить схему инвестиций. Она состоит из обособленных блоков, представляющих собой законченный этап финансово-экономических затрат :

1 Стоимость работ по внедрению –ERP системы;

2 Стоимость аппаратного и программного обеспечения комплекса;

3 Совокупная стоимость владения ERP-комплексом (ежегодные затраты).

Указанная схема разделения затрат применяется в известной методике TCO (total cost of ownership) - это методика расчета, созданная для того, чтобы помочь потребителям и руководителям предприятий определить прямые и косвенные затраты, связанные с любым компонентом компьютерных систем. Цель ее применения - получить итоговую картину, которая отражала бы реальные затраты, связанные с приобретением определенных средств и технологий, и учитывала все аспекты их последующего использования.

Статья затрат «стоимость работ по внедрению ERP-системы», как правило, подробно оговаривается в смете работ по внедрению системы в договоре, заключенном с фирмой, осуществляющей процесс интеграции ERP-пространства на предприятии. Прогнозные значения затрат на внедрение рассматриваемых систем приняты следующие:

- «SAP R3» - порядка 0,8 млн. руб. в год. Сроки внедрения около двух лет.

- «Axapta» – порядка 1,0 млн. в год. Срок внедрения около года.

Стоимость аппаратного и программного обеспечения комплекса включает затраты, связанные с закупкой лицензий всего комплекса программных продуктов, таких как операционная система (OS), сервисное программное обеспечение (ПО) и непосредственно сам ERP-продукт. Также в эту статью включается стоимость всего парка машин как персональных, так и серверных станций и сопутствующего коммуникационного оборудования. Совокупная стоимость всех персональных компьютеров (ПК) в ERP-комплексе рассчитывается на основе данных об их количестве и усредненной стоимости одного ПК, задействованного в ERP-комплексе (таблица 3).

В сравнительном анализе принято, что расчет ведется на 50 компьютеров или клиентских мест, на которые распространяется одна лицензия.

Оценка стоимости владения ERP-комплекса включает в себя два вида затрат: непрямые затраты, прямые затраты.

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

В прямые затраты включаются затраты, связанные с затратами на оборудование, программное обеспечение, обслуживающий ERP-систему персонал, связь и т.д.

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

Оценка прямых затрат совокупной стоимости владения ERP-комплексом приведена в таблице 4. Данная оценка является ежегодной статьей расходов на содержание и обслуживание всего ERP-комплекса, она также поможет обосновать бюджет компании на развитие информационных технологий на предприятие.

По скромным расчетам значение совокупной стоимости владения одним компьютером значительно отличатся от заявленных значений фирм – производителей систем ERP. Так, например, у фирмы Microsoft Business Solutions Navision это значение составляет 1500–2500 евро или по текущему курсу (41 руб./евро) 61 500 – 102 500 руб., в то время как расчетная величина - 221 765,78 руб.

Данная оценка дает довольно точное значение затратной части, проекта внедрения, а также позволит сделать прогноз эффективности инвестиций в ERP технологии.

Основная трудность определения дохода от внедрения ERP – системы и расчета эффективности заключается в выявлении экономических выгод для компании. Считается, что если компания не внедряет новшество, значит, она упускает возможность получения прибыли и теряет «упущенную выгоду». Она может быть найдена из анализа проблем, недостатков работы, которые можно было бы исправить, внедрив системы управления предприятием.

На основе анализа данных финансового отчета компании была сформирована «упущенная выгода» от неиспользования возможности устранения недостатков по следующим показателям:

Среднегодовой показатель за 10-летний период недостачи товаров материальных ценностей (ТМЦ) и основных средств (ОС), которая была получена по причине плохого учета, руб.

Среднегодовой показатель за 10-летний период излишек ТМЦ, которые были накоплены по причине плохого учета, руб.

Аренда ОС в размере 5% их стоимости, по причине нерационального планирования производственной мощности, (ежегодно), руб.

На основе статистических данных предприятия величина среднегодовой «упущенной выгоды» по вышеназванным показателям составила 155944738,878 руб., что превышает сумму разовых и ежегодных затрат систем «SAP/R3» и «Axapta» в 5,89 и 7,85 раз соответственно и доказывает эффективность их использования. Такой подход не может быть точным, но он показывает меру серьезного отношения к вопросу об эффективности использования ресурсов предприятия.

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1 Официальный сайт фирмы «1С» http://www.1c.ru

2 Axapta. Работа на результат http://axapta.mazzy.ru

3 Отраслевые решения ЦМД СОФТ. Что такое Microsoft Dynamics NAV (Microsoft Navision)? http://www.cmdsoft.ru/products/microsoft_dynamics/nav

4 Независимый ERP-портал http://www.erp-online.ru

5 Абрамова, И.Г Основы организации и управления подготовкой производства машиностроительного предприятия [Электронный ресурс]: электрон. учеб. пособие /И.Г. Абрамова; Самар. гос. аэрокосм. ун-т им. С.П. Королёва (нац. исслед. ун-т); – Электрон. текстовые дан. – Самара, 2011. – 1 эл. опт. диск (CD-ROM).

На сегодняшний день в плане задач управления производством мы имеем две парадигмы. Одна из них заключается в составлении оптимальных расписаний работы технологического оборудования в цехах . Эта задача решается с помощью соответствующих инструментов - на цеховом уровне с помощью 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.

Внедрение ERP-системы на машиностроительном предприятии: цели, стратегия, опыт

Like Share Report 469 Views

Внедрение ERP-системы на машиностроительном предприятии: цели, стратегия, опыт. ПромИТ ’13 Минск 21 мая 2013. Содержание. 1. О компании EPAM Systems. 2. Цели проекта внедрения ERP- системы. 3. Стратегия внедрения ERP- системы. 4 . Опыт реализации проектов внедрения SAP ERP.

Download Presentation

Внедрение ERP-системы на машиностроительном предприятии: цели, стратегия, опыт

E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -

No related presentations.

Presentation Transcript

Предприятия Влияние системы ERP Воздействие Показатели Производить то, что нужно рынку Соблюдать и сокращать сроки заказов Производить качественную продукцию Предоставлять качественный сервис Своевременно выпускать новые продукты Выручка Оптимизировать запасы готовой продукции Оптимизировать незавершенное производство Оптимизировать запасы материалов Сократить производственный цикл (уменьшить задержки в производстве) Потребность в оборотных средствах Оптимизировать затраты на закупку Оптимизировать затраты на производство Снизить затраты на хранение запасов Затраты

Качественного планирования Принципы планирования Задачи Соблюдать и сокращать сроки заказов График выпуска ГП должен соответство-вать графику отгрузки, сократить интервалы между поставками (разбивать большие поставки на несколько меньших). График изготовления партий ДСЕ должен соответствовать графику выпуска ГП (не допускать преждевременного изготовле-ния ДСЕ), изготавливать более мелкими партиями. График отпуска материалов в производ-ство должен соответствовать графику изготовления ДСЕ (не допускать прежде-временного отпуска материалов), отпускать более мелкими партиями. График закупок материалов должен соответствовать графику отпуска их в производство (не допускать преждевре-менных закупок), закупать более мелкими партиями. Оптимизировать запасы готовой продукции Оптимизировать объемы НЗП Оптимизировать запасы материалов Сократить производственный цикл (уменьшить задержки в производстве) Оптимизировать затраты на закупку Оптимизировать затраты на производство Снизить затраты на хранение запасов

Потока Сбыт Снабжение Производство Склады ГП Склады МТО Поставщики Покупатели Механо-обрабатывающее производство Сборочное производство Заготовительное производство Выполнять график отгрузки при минимальных запасах ГП. Выполнять график выпуска ГП (равномерно) при минимальных объемах НЗП и запасов материалов. Не допускать формирования преждевременных запасов – не отвлекать ресурсы, не работать на создание «тромбов».

Качественного планирования Управление предприятием с помощью ERP-системы – Эффективное управление на основе планированияресурсов Увязав планирование сбыта, производства, закупок и финансовых потоков, вы сможете увеличить объем производства при том же или даже меньшем объеме оборотных средств. Качественное оперативное календарное планирование производственных заданий, мощностей и МТО,позволит вам сократить сроки выполнения заказов клиентов, при одновременном сокращении складских запасов иНЗП, а в итоге сократить затраты в производстве, закупках, складах. Результат Увеличение прибыли Повышение рыночной стоимости предприятия

1. О компании EPAM Systems 2. Цели проекта внедрения ERP-системы 3. Стратегия внедрения ERP-системы 4. Опыт реализации проектов внедрения SAP ERP 5. Решение RDS-EPAM

Руководство предприятия желает повысить жизнеспособность бизнеса и понимает, что необходимо совершенствовать бизнес-процессы. Изменение процессов бизнес выполняет на основе прогрессивных методологий и потенциале возможностейIT-систем, реализующих эти методологии. Вариант 1 Вариант 2 Предприятие имеет стратегию повышения эффективности. Разрабатывается новая методология пла-нирования и управления производством, выполняется реинжиниринг бизнес-процес-сов с максимальным использованием лучших мировых практик. Автоматизация выполняется на базе стандартного функционала ERP-системы, реализующего эти практики. У предприятия нет четкой стратегии повышения эффективности. Автоматизируется существующая методология планирования и управления производством, и текущая организация бизнес-процессов. Стандартный функционал ERP-системы существенно изменяетсяи/или разраба-тывается нестандартный функционал. Успешное завершение Бизнес-проект ИТ-проект Возврат инвестиций

Реорганизации бизнеса в рамках внедрения ERP Проектирование Разработка Внедрение Эксплуатация Корпоративная стратегия Функциональная стратегия ИТ-стратегия Анализ текущей эффективности бизнеса Бизнес-консалтинг Оценка экономической эффективности от внедрения Целевая модель бизнес-процессов Организационная структура Система показателей эффективности Функционирование Центра компетенции Формирование ЦК Концептуальный проект ИТ-системы Разработка НСИ Создание прототипа ИТ-консалтинг Интеграция прототипа Развитие решения Тестирование и стабилизация Тиражирование Интеграция и другие ИТ-инициативы Проведение изменений бизнес-процессов, организационной структуры и обучение пользователей Управление программой Управление рисками и Контроль качества Центр управления программой

Пример: Функциональная область – Управление производством и МТО Предпосылки Стратегия предприятия содержит задачу по развитию управления производством Руководителем программы по развитию управления производства назначен производственный топ-менеджер Мероприятия Определите показатели эффективности, значение которых не устраивает руководство компании Определите для этих показателей целевые значения. Идентифицируйте негативные ситуации в текущих процессах планирования и управления производством и снабжением, которые необходимо устранить. Разработайте целевую методологию планирования и управления производством и снабжением, основанную на «лучших мировых практиках» (международном опыте) Разработайте комплекс показателей эффективности для новой методологии. Разработайте стратегию развития ИТ-системы для обеспечения информационной поддержки целевой методологии планирования и управления производством. Утвердите на совете директоров решение о переходе на новую методологию. Выполните обучение руководителей и специалистов по новой методологии. Разработайте целевые модели бизнес-процессов. Разработайте и утвердите план перехода на новые модели бизнес-процессов, включая внедрение соответствующей функциональности SAP ERP для данных бизнес-процессов.

ERP-системы НСИ Регистрация договоров закупки Регистрация договоров сбыта Планирование производства и снабжения Сбытовые заказы Заказы на закупку Складские запасы План выпуска ГП Производственные заказы Развертывание по цехам/заводам? Заявки на перемещение Заявки на закупку Плановые заказы на производство

Решения Сервисное обслуживание Производство КТПП Снабжение Сбыт Непрерывное производство Дискретное производство Производство на склад Сборка под заказ Производство под заказ Единичное позаказное производство Проектное производство …

Организационный масштаб Контроллинговая единица - 1 Балансовые единицы - 24 Заводы - 27 Склады>500 Цеха, участвующие в основном производстве (области ППМ) >50

Затраты Расчеты с поставщиками Расчеты с покупателями Финансовые средства Доходы Расходы Результаты Вспомогательные процессы: Управление качеством Управление персоналом Управление ТОРО Управление проектами Внедрение SAP на ПО «Гомсельмаш» Функциональный масштаб Входит в масштаб проекта ПРЕДПРИЯТИЕ Развитие проекта Стратегическое планирование и анализ деятельности предприятия Техническая подготовка производства Долгосрочное (на год) планирование производства, закупок и затрат Закупки (выполнение и учет) Сбыт (выполнение и учет) Запасы матер. Запасы ГП Оперативное планирование производства и снабжения Поставки материалов (сырья, услуг) Поставки продукции (изделий, услуг) ПОСТАВЩИКИ Производство (выполнение и учет) ПОТРЕБИТЕЛИ НЗП полуфабрикаты

Калькуляция затрат на изделие Сбыт – Производство – Затраты – Результаты Старт процедуры планирования Анализ плановых расходов и доходов Планирование результатов Планирование сбыта Плановая себестоимость производства и продаж План сбыта продукции Вариант изготовления Техкарта Специфи-кация Планирование производства План производства Плановый объем работ Плановый объем закупок Плановые тарифы работ Планирование затрат (МВЗ, виды работ)

Проблем производственных предприятий Преимущества SAP RDS для бизнеса Эффективное использование типовых бизнес-процессов, преднастроенных для производственного предприятия Обеспечение прозрачности и оперативности бизнес-процессов Унификация бизнес-процессов Управление и контроль за производственными процессами Ведение бизнеса в единой гибкой корпоративной информационной системе Быстрая адаптация пользователей иповышение продуктивности их работы, минимизация затрат на обучение персонала Уменьшение общих инвестиционных рисков, связанных с проектом RDS - Rapid Deployment Solutions -Быстрое Развертывание Решения

Решение RDS Быстрый результат,благодаря типовым бизнес-процессам с преднастроенным функционалом системы, содержащим все, что необходимо для управления производственным предприятием Авторитет SAP Стабильная технология Мощное решение Беспрепятственная интеграция Развитая система поддержки Быстро и экономично Четко определенный объем Преднастроенные бизнес-процессы и документы для передачи знаний Предопределенная методология внедрения с инструментамии акселераторами Запуск в промышленную эксплуатацию в срок до 19 недель Рентабельно Доступная ценовая модель Привлекательные услуги по фиксированным ценам Снижение сроков, затрат и рисков на внедрение Сокращение потребности в ресурсах бизнес- и IT-подразделений

SAP объединяет программное обеспечение и услуги в новое предложение, которое дает Вам необходимую бизнес-функциональность быстро и доступно Программное обеспечение SAP ПО для внедрения RDS: SAP Solution Manager 7.0 EHP1 SPS03 ПО для эксплуатации RDS: SAP ERP 6.0 EHP5 SPS04 Стандартная методология SAP по внедрению RDS Преднастроенные бизнес-процессы SAP Best Practices (Лучшие практики) Пакет документов, инструкций, акселераторов