Сравнительный анализ некоторых программных комплексов по
планированию производства
Ю.И. Долгова,
инд. предпр.,
juna@telecomdubna.ru, Московской
обл.. г. Дубна
Сравнение
базы данных «ЮНА-АСУП» с системой MRP II и с
некоторыми другими программными комплексами.
Comparison of database «ЮНА-АСУП» with MRP II system and some other software systems.
Сравнительный анализ
возможностей БД «ЮНА-АСУП» и системы
MRP II
В настоящее время
огромное количество программных продуктов предлагают свои услуги по вопросам
планирования и управления самыми различными объектами. Имеются предложения для
управления всеми ресурсами предприятия, всей организацией, цепочками поставок
и закупок, управления персоналом и финансами,
инвестициями и проектами, логистикой и производством, управления жизненным циклом изделия, а также предлагается
управление бизнес-процессами,
бизнес-стратегиями и просто
стратегиями и т.д. и т.п. Причем предлагаются методы
управления многофункциональные, эффективные, оптимальные, глобальные, оперативные, сервисные и, конечно,
соответствующие мировым трендам.
При такой широте и разнообразии предложений потребителям нелегко разобраться в
реальной пользе и применимости тех или иных программных комплексов.
Так как автору данной
статьи не один год пришлось работать на предприятиях машиностроения по вопросам
проектирования экономических задач, то полученный опыт заставляет рассматривать
все программные продукты как бы «снизу», с точки зрения их удобства в
применении на практике, с точки зрения их пользы и выгоды для предприятия, с
точки зрения, наконец, облегчения трудов
производственников в вопросах планирования и управления.
Исходя из предыдущего
опыта работы автором была разработана и представлена в ряде статей [3 - 6]
«Универсальная база данных «ЮНА-АСУП»
для планирования машиностроительного производства»,
где реализован вариант
автоматизации планирования машиностроительного производства, включая
планирование норм расхода материалов, оборудования и других ресурсов,
необходимых для этого производства.
Предложенная база
данных (БД) «ЮНА-АСУП» реализована на основе СУБД Microsoft ACCESS
2007. Это небольшая отечественная БД, в которой выполнена единственная производственная функция - функция собственно
планирования, т.е. рассчитаны даты начала и окончания каждой технологической
работы, выполняемой при изготовлении изделия. Зато эта функция выполнена точно
и надежно.
В БД «ЮНА-АСУП» нет управления
жизненным циклом изделия, а также нет управления бизнес-процессами, бизнес-стратегиями
или просто различными стратегиями и т.п. Однако
вопрос со «стратегиями» решен вполне однозначно: бизнес-стратегии относятся к зоне ответственности
руководства, к высшему управляющему звену предприятия. Постановка задачи такова
- руководство предприятия определяет
всего три параметра:
какие изделия, на какую дату и в каком количестве нужно произвести. От
этой директивы и будет выполнен расчет на основе созданной базы данных.
Здесь дано абсолютно
точное представление в БД конструкторских
и технологических документов по изделиям, которое позволяет так же точно
рассчитывать планы производства. Работают сетевые методы – применена система
PERT. Решена задача полной применяемости деталей и узлов на изделие и задача
упорядочения конструкторско-технологической сети по уровням иерархии,
обычно называемая на практике задачей разузлования изделий. БД
создана как единый комплекс по всем изделиям для всего предприятия в
целом.
В соответствии с
постановкой задачи вместе с работами в базу вводятся и нормы использования
материальных ресурсов (материалов, оборудования и др.), необходимых для
выполнения этих работ. Поэтому одновременно вместе с задачей планирования работ
решена и задача планирования всех материальных ресурсов, необходимых для
изготовления изделия. На выходе после очередного расчета плана получаются два
основных документа - «Перечень плановых
работ по изделиям» и «Перечень
материальных ресурсов, необходимых для выполнения плана».
Структура БД предельно проста – содержит около 6-ти основных таблиц. Конструкция изделий представлена в виде двух
основных таблиц - таблицы номенклатуры и состава, технология представлена в
виде 4-х таблиц - таблицы технологических операций, рабочих мест, а также
таблицы операций для конкретных работ и норм расхода материальных ресурсов,
применяемых на этих операциях. Параллельно с созданием БД «ЮНА-АСУП»
автору было интересно и полезно сравнить постановку аналогичных вопросов в других программных комплексах.
Прежде
всего необходимо обратить внимание на одну из наиболее широко распространенных
в нашей стране аббревиатур ЕRP-MRP и MRP II, MRP-3 и другие MRP. Ссылки на ЕRP столь часты и употребительны, что напоминают обращение к
некоторой иконе, которая настолько абсолютна и непререкаема, что говорить о ее
свойствах вроде бы просто излишне и
неуместно.
Тем
не менее предпринята попытка разобраться в идеологии
систем ERP,
MRP II и MRP на основе книги [1] , где весьма
полно и обстоятельно описаны основные принципы разработки этих систем. О
глубокой взаимосвязи систем ERP
и MRP II авторы книги [2]
говорят так:
«В разрез с устоявшимся мнением компьютерные системы MRP II и ЕRP -
это практически
одно и то же, хотя в настоящее
время, ссылаясь на компьютерные системы,
чаще употребляют название ЕRP». [2, с. 35]. И еще:
«ЕRP не является компьютерной программой в привычном
понимании, так как основу таких
систем составляет MRP II, т. е. концепция управления предприятием,
реализация которой стала возможной благодаря компьютеру.» [2, с. 272]. Или еще:
«Не может быть ЕRP-системы, не поддерживающей стандартных функций MRP II». [2, с. 283].
Как
видим, интересуясь возможностями системы ЕRP, нужно
прежде всего внимательно изучить возможности MRP II.
В результате анализа идеологии
планирования системы MRP II на основе [1] можно сделать некоторые выводы с
точки зрения удобства и эффективности
применения их при внедрении на предприятии.
Как ни странно, тут
выясняется ряд несогласий автора настоящей статьи с некоторыми принципиальными
моментами в системе MRP II при их решении
проблем планирования машиностроительного производства.
1.
Главное
несогласие автора состоит в том, что практически в этих программных комплексах
нет точного и цельного описания той входной информационной базы, которая
заложена в компьютер для реализации поставленной задачи. Входная база описана
либо отрывочно и частично, либо вообще нарушает адекватное представление
исходной конструкции изделия, что в принципе недопустимо для серьезного
предложения промышленным, в частности, машиностроительным предприятиям. Более
конкретно можно сказать о таких особенностях системы MRP II:
·
Предлагаемое
системой MRP II заполнение «уровней
структуры» вручную и вытекающую отсюда переработку всех конструкторских спецификаций
нельзя считать удобным и приемлемым для предприятий со сложной техникой.
·
Расчет
любых «применяемостей» должен
выполняться системой автоматически. Требование
заполнять спецификации «применяемости» равноценно с требованием
выполнять их вручную вместо применения автоматизированных процедур.
·
Требование создавать
группировки различных предметов номенклатуры изделий является сложным и не
всегда обоснованным условием при внедрении на предприятиях. Применение
естественных обозначений конструкторских элементов (узлов и деталей) вполне решает эту проблему.
Неадекватная и неточная формализация
описания конструкторско-технологических данных по изделиям приводит к тому, что
система приводит иногда к прямым
противоречиям с процессом производства «как он есть».
«С одной стороны, следует стремиться к
сокращению количества уровней в многоуровневых спецификациях, упрощая тем самым
процедуру планирования и сокращая количество объектов, которые надо держать под
контролем. С другой стороны, следует стремиться к описанию процесса
производства продукции «как он есть»,
с тем, чтобы модель процесса производства, описываемая информационной системой,
была близка к жизни. Эти требования могут
противоречить друг другу, и приходится искать компромиссное решение.» [1, с. 89 ].
Отсюда логично следует вывод: любой
программный комплекс только тогда имеет право говорить о планировании продукции
машиностроения, если он может точно отобразить конструкцию изделия вплоть до
любого винтика, а так же и технологию изготовления изделия вплоть до каждой
операции. Иначе систему нельзя считать работоспособной. Система MRP II содержит
недопустимое противоречие - она
позволяет произвольно определять, «какие
номенклатурные позиции» можно включать
или не включать в план. Только стопроцентное включение всех
конструкторских спецификаций в план можно считать правильным подходом!
Для сравнения – в БД «ЮНА-АСУП» исходным документом для создания информационной
базы является конструкторская спецификация (ЕСКД ГОСТ 2.
108-68). Поэтому заполнять при вводе никакие «уровни структуры» не нужно, т.к.
их обрабатывает программа. Также все
«применяемости» на всех уровнях считает программа. В БД поступают все без
исключения конструкторские элементы, которые присутствуют в исходных данных.
2. Следующее разногласие
состоит в том, что предлагаемое
количество этапов планирования в системе фактически ничем не ограничено.
В системе MRP II можно насчитать от 5 до 7 этапов планирования, в зависимости
от различных требований производства. Краткий
перечень основных этапов
планирования и программных модулей
выглядит так:
1) Укрупненное планирование.
2) Планирование продаж и операций.
3) Главный календарный план производства
(модуль MPS).
4) Укрупненное планирование
потребности в мощностях (модуль RCCP).
5) Планирование потребности в материалах
(модуль MRP).
Планирование ресурсов распределения (модуль DRP).
6) Планирование потребности в мощностях
(модуль CRP).
7) Оперативное управление производством
(модули SFC или PAC).
Причем на двух этапах среди этого списка система может дать результат «не реально», Тогда здесь предлагается работать с
так называемым «замкнутым
циклом». Замкнутый цикл может вернуть все этапы планирования на начало процесса
как на этапе главного календарного плана (MPS), так и на этапе планирования потребности в мощностях (CRP), - по сигналу системы «не
реально». Причем количество замкнутых циклов ничем не ограничено. И нет никаких
критериев, сколько раз придется
повторить этот замкнутый цикл, чтобы добиться когда-нибудь положительного
результата. Вывод: недопустимо
предлагать пользователям выполнять на практике такие бесконечные повторы в работе, Здесь, очевидно, система не
может адекватно описать реальный процесс производства.
Для сравнения - в БД «ЮНА-АСУП» расчет плана происходит за один прогон базы. Причем
особенно ценно получать общую картину в тех случаях, когда одновременно
выполняются работы по нескольким различным изделиям или по одному типу изделий,
но запущенному в производство с разными сроками. Тогда все необходимые работы
могут «накладываться» друг на друга как на различных
рабочих местах, так и на определённых отрезках времени. В таких случаях
компьютер покажет реальное состояние дел, а «расшивать» различные узкие
места и принимать управляющие действия будут ответственные плановики, производственники и прочие управленцы всех
уровней.
3.
Большое
несогласие вызывает постоянное смешивание роли прогнозов спроса и фактических
единиц продукции при планировании. На
первых трех этапах системы MRP II в основу планирования положен прогноз,
причудливо смешанный с реальностью, т.е. предлагается принудительное смешивание
прогнозов спроса и фактических, натуральных показателей продукции. Даже на этапе главного
календарного плана имеем недопустимое противоречие - хотя главный календарный
план формируется в «типоразмерах
номенклатурных позиций» и «не в стоимостном, а в натуральном выражении»
[1,с.131], но он по-прежнему «должен
принимать во внимание прогноз». Однако где прогноз, там заложены и различные
ошибки.
В итоге при неудачных
результатах расчета разработчики системы признают, что прогноз, как известно,
«имеет один крупный недостаток, прогноз
никогда не бывает точным»
[1, с. 322]. Действительно, ошибочный
прогноз может давать и ошибочные
результаты – это очевидная истина. Смешивание
производства «прогнозов» и конкретных фактических изделий недопустимо для
реального производства – это может привести к большим просчетам и убыткам.
Вывод - не профессионально со стороны системы предлагать производству такие
ненадежные средства планирования.
Для сравнения: в БД «ЮНА-АСУП» выполняется планирование продукции только в
естественных, натуральных единицах, традиционно принятых в промышленности.
4.
Следующее
разногласие: планирование продукции на первых двух этапах – на укрупнённом
планировании и планировании продаж и операций,
- идет в стоимостном виде, в виде «бюджета», что потом создает проблемы
с пересчетом «бюджета» в натуральные единицы продукции. Нет формул для такого
пересчета при планировании, что может привести к большим ошибкам (да и могут ли
быть формулы на годы вперед?), Картина почти та же самая, что и с прогнозами -
ведь завод в конечном итоге все-таки должен выпускать натуральные «штуки»,
узлы, изделия, а не печатать деньги.
В БД «ЮНА-АСУП»
планирование выполняется только в натуральных единицах продукции, т.е. в «количестве изделий», а не в
стоимостных или каких-то других единицах. Следовательно, никакие прогнозы здесь
не участвуют. Впрочем, любые прогнозы можно считать сколько угодно, но это
будет всего лишь информация «для размышления», прогнозы лягут на стол
руководителей, а не пойдут в рабочий план.
5.
Об алгоритмах расчетов.
После изучения различных функций, обеспечивающих планирование ресурсов в
системе MRP II, пользователям хотелось бы познакомиться и с теми алгоритмами, которые
призваны выполнить объявленные расчеты. К сожалению, здесь потребителей ждет
определенное разочарование: авторы системы MRP II очень
последовательно умалчивают об алгоритмах, задействованных при решении тех или
иных частичных задач, хотя это и не слишком корректно по отношению к
потенциальным потребителям системы. Это говорит об определенном недоверии
разработчиков к потребителям их систем или о нежелании открывать не слишком
убедительные стороны своих алгоритмов и разработок.
Для сравнения - в БД «ЮНА-АСУП» используются
сетевые методы [7] (система PERT), что позволяет
выполнять следующие необходимые расчеты:
·
Упорядочение
сети по уровням иерархии, т.е. решение так называемой задачи «разузлования» изделий. Это значит, что не нужно требовать
при вводе конструкторских данных указания
«уровней иерархии» - их определит компьютер.
·
Не
нужно кодировать конструкторские элементы какими-то кодами, тут вполне работают
их уникальные буквенно-цифровые обозначения.
·
Можно
слить все сети-изделия в общую сеть, создав тем самым единую информационную
базу по всему предприятию. Сетевые методы обрабатывают сети любой сложности.
·
Пользуясь
свойством связности сети, можно выбрать из общего состава в базе любое
подмножество, т.е. любое конкретное изделие или узел.
·
Можно
рассчитать полное количество всех предметов (деталей и узлов) на изделие.
·
Можно
рассчитать опережение всех предметов (деталей и узлов) по отношению к выпуску
готового изделия (например, в днях).
·
Можно
определить, в какие вышестоящие узлы входит та или иная деталь.
·
Можно
определить ряд разрывов в сети, например, узлы, которые никуда не вошли или
узлы, не имеющие своего состава, так как исходная сеть по своему смыслу всегда
должна быть связной. Разрывы – это чьи-то ошибки.
·
Можно
определить неприятную логическую ошибку в сети – так называемую ситуацию
«замкнутого контура», которая помешает выполнению основных расчётов «количеств»
и «опережений». И ряд других полезных функций.
6.
Красной
нитью при описании возможностей системы MRP II проходят рассуждения об «оптимальном» планировании производства. Однако план не может быть оптимальным, так как
есть только один вариант – та конструкция и та технология изготовления изделий,
которая существует на заводе в данный момент. Именно такая
конструкторско-технологическая сеть является основой информационной базы для планированию производства.
Выбирать оптимальный план просто не из
чего.
Для сравнения - в БД «ЮНА-АСУП» никакой оптимизации плановых расчетов не
предусмотрено. В данном комплексе расчетные результаты однозначно определяются
той информацией, которая представлена в базе данных. Если руководству
результаты не понравятся либо по срокам изготовления, либо по объемам ресурсов,
потребным для производства, то, значит, надо менять те или иные параметры в
реальном производстве, затем отражать их в созданной базе данных и производить
новые расчеты.
В итоге лучше сделать
вывод, что оптимизация должна немного подождать – сначала нужно поставить на
ноги один хорошо отработанный вариант планирования производства, а уже на его
основе можно говорить и о различных модификациях или о возможном разнообразии
вариантов.
7.
Кроме того, важно
отметить существенное «территориальное ограничение» у системы MRP
«Планирование потребности в материалах».
Основной блок MRP работает только
«на одной «территориальной площадке», т.е. в переводе на российские понятия, MRP работает только в одном цехе.
«Например, если у предприятия две производственные
площадки, на каждой из них работает свой
MRP, координация же работы площадок с точки зрения планирования потребности в
материалах возлагается уже на отдельный модуль систем MRP II: планирование
потребности в распределении - (DRP)… Можно сказать,
что в этом случае есть несколько MRP–систем, связанных
в сеть посредством DRP-модулей» [1, с.
196].
Какая же невероятно сложная система комбинаций MRP – DRP должна быть у большого
современного предприятия, если количество цехов у него может быть не один-два,
а гораздо больше! Такие «территориальные ограничения» не могут быть приемлемы
для средних или больших предприятий,
т.к. эти ограничения не отражают реальных функций производства. В итоге
напрашивается очередной вывод – охват
планирования предприятия как единого
целого модуль MRP не решает, а
вместе с ним и вся система MRP II.
Для сравнения - в БД «ЮНА-АСУП» движение продукции
из цеха в цех оформляется одной простой операцией – типа «передача» или
«переход». Здесь нет никаких проблем.
8.
Вызывает
несогласие с системой смешивание функции производства с функциями снабжения и
сбыта, что усложняет и утяжеляет весь
комплекс планирования, так как задачи, информационные базы и алгоритмы расчетов
у этих служб совершенно
различны. Если разделить
автоматизацию функций производства, снабжения и сбыта, тогда система станет
легкой, прозрачной и логичной.
Для сравнения - в БД
«ЮНА-АСУП» задачи планирования производства четко
отделены от функций
снабжения и сбыта. Связь между производством и снабжением
очень проста: производство рассчитывает заявку на материалы
как по количеству, так и по срокам потребности, а служба снабжения должна
выполнить ее вовремя. А службе сбыта от производства важно лишь одно сообщение,
что та или иная продукция уже готова к реализации, дальше эта служба должна
работать своими средствами со своими потребителями.
И если эти связи и обязанности служб будут выполнены, то
предприятие может функционировать вполне успешно.
Заключение от сравнения БД «ЮНА-АСУП»
и системы MRP II
В БД «ЮНА-АСУП»
фактически создана единая, формализованная, непротиворечивая
подсистема спецификаций в виде
построенной сети-изделия, со стопроцентной точностью отражающей
конструкторско-технологическое содержание сети в информационной базе, чего
нельзя сказать, к сожалению, о системе MRP II. Но самое
главное значение построенной здесь конструкторско-технологической сети состоит
ещё в том, что она носит универсальный
характер. Действительно, такая сеть объективно присутствует на любом предприятии машиностроения. А
предложенное описание этой сети может быть также применимо на любом
машиностроительном предприятии для любых видов продукции (от ведра до
самолета). И что особенно важно, что данная БД охватывает соответствующую
информацию по изделиям всего предприятия в целом, что является залогом её
применимости для создания АСУ предприятия.
Беглый взгляд на
некоторые другие программные комплексы и их эффективность для планирования
машиностроительного производства
После подробного
анализа систем MRP II и MRP нужно бросить хотя бы беглый взгляд и на некоторые другие
программные комплексы, предлагающие свои услуги по части управления и
планирования производства. Некоторые из них вообще не занимаются проблемами
конкретных предприятий, выпускающих какую-то промышленную продукцию. К таким
можно отнести, например, "Системы
управления" (Primavera), которые
ориентированы на заказчиков, обеспечивающих реализацию крупных
инвестиционных проектов в крупных отраслях хозяйства страны, таких, как нефтегазовое строительство,
трубопроводный транспорт и др.
Большинство
современных программных комплексов на рынке в первую очередь предлагают громко
и настойчиво такие традиционные, хорошо отработанные учетные функции, как
«Управление персоналом», «Расчет заработной платы», "Основные фонды",
"Управление финансами", «Бухгалтерский учет», «Документооборот",«Автохозяйство», и
др. А управление производством предлагается как-то в конце списка, как некое
«бесплатное приложение» к основному набору.
К таким
системам можно отнести систему «КОМПАС»,
в значительной степени систему «ПАРУС», где под управлением
производством предлагают в первую очередь «учет затрат и
калькуляцию себестоимости», что является всего лишь учетной задачей некоторого
процесса. Хотя сначала правильнее было
бы описать сам процесс планирования производства, а тогда уже можно было бы
говорить и о его учете.
Или еще пример. «В
основе международной системы управления предприятием Microsoft
Dynamics NAV заложены мощные инструменты для управленческого, бухгалтерского и налогового
учета, управления товарно-материальными потоками и производством». Как видим, скромное замечание, – «и
производством». На самом деле именно производство является первичным на предприятии и именно оно определяет смысл существования
остальных указанных функций.
Программные комплексы
Microsoft по управлению проектами, такие, как MS Project от 2002
- 2010 предлагают при вводе информации о проекте применяют так называемую
структурную декомпозицию работ - СДР.
Фактически здесь предлагают пользователю самостоятельно выполнить
кодирование всей исходной информации, обозначив «уровни» и сложив «иерархическую диаграмму проекта»
вручную – этот случай совсем не пригоден для практики машиностроительных
предприятий.
Такие
системы, как «ПАРУС», «Галактика», «1-с-Предприятие» не дают описаний конструкторских и технологических
данных, необходимых для планирования производства, поэтому вопрос об их
компетентности в этих задачах остается открытым и неопределенным.
Особенно интересно остановиться на возможностях программного комплекса SAP R/3. Из подробного описания его функций видно, что система SAP очень многое заимствует из системы MRP II. Если при этом SAP, кроме заимствования названий модулей, будет заимствовать также и все ошибки, свойственные модулям BOM, MPS, MRP и др. системы MRP II, то ждать больших успехов от внедрения SAP маловероятно. Тогда отрицательные результаты при внедрении системы SAP будут также закономерны.
Впечатляет,
что в книге [1] в качестве итога упомянут еще один из известных результатов
внедрения систем MRP II в виде так
называемого принципа GIGO:
«GIGO - garbage in, garbage out» т. е. «мусор
внутри, мусор снаружи». На практике
это выглядит таким образом, что система «будет
генерировать больше недостоверной и бесполезной информации, чем было до ее
применения.»
Учитывая
такие серьезные неудачи при внедрении систем MRP II, приходится сформулировать достаточно простой критерий,
по которому можно оценить работоспособность и успешность очередной
экономической системы по управлению какой либо человеческой функцией:
1.
Входная информационная база должна быть
открыта.
2.
Внутреннее устройство системы может быть скрыто: здесь могут быть любые «ноу – хау».
3.
Выходные документы системы должны быть
открыты.
Если уважаемые
разработчики систем управления уберут неопределенную составляющую в программном
комплексе «garbage in»
(«мусор на входе») и откроют свои информационные базы, то большинство вопросов
отпадут сами собой. Системы вместо «черных ящиков» будут прозрачными и
понятными.
Литература
1. Гаврилов Д.А. Управление производством
на базе стандартов MRP II. 2-е издание. Питер. Москва, 2005.
2.
Питеркин С. В., Оладов
Н. А., Исаев Д. В.
Точно вовремя для
России. Практика применения ЕRP – систем. Москва
// АЛЬПИНА паблишер, 2003. 365 стр.
3. Долгова Ю. И.
Автоматизированная система управления производством. Журнал
«Машиностроитель» № 9 стр. 40-43, № 10 стр. 21-26, № 11 стр. 2-7 и № 12 стр.
12-19,
4. Долгова Ю.И. База данных «ЮНА-АСУП» по планированию машиностроительного
производства //Труды международной конференции «Системы проектирования,
технологической подготовки производства и управления этапами жизненного цикла
промышленного продукта (CAD/CAM/PDM-2013)» М.: ООО "Аналитик", 2013., С. 287-289
5. Долгова Ю.И. База данных «ЮНА-АСУП» по планированию машиностроительного
производства // Информационные технологии в
проектировании и производстве. – 2013. №4. С. 50-53.
6.
Долгова Ю.И. База данных по планированию
машиностроительного производства // Промышленные АСУ и контроллеры.
- 2014 г. № 2. С.44-48
7.
Долгова
Ю.И. Алгоритмы сетевых методов, применяемые для планирования производства в базе данных «ЮНА-АСУП //Труды международной конференции «Системы
проектирования, технологической подготовки производства и управления этапами
жизненного цикла промышленного продукта (CAD/CAM/PDM-2013)» М.: ООО "Аналитик", 2013., С. 290-293
8. Свидетельство о
государственной регистрации базы данных //«База данных «ЮНА-АСУП»
- Планирование машиностроительного производства» № 2012621039 от 5 октября 2012
г. Правообладатель: Долгова Юнона Ивановна (RU).
Автор: Долгова Юнона Ивановна (RU).