Вставлю свои "5 копеек"...
Насколько я себе представляю, существуют системы следующих классов, функции и возможности которых (особенно, расположенных в соседних уровнях иерархии) в существенной степени пересекаются (в порядке уменьшения глобальности решаемых задач и повышения степени их детализации, качества решения):
1. ERP-система
2. APS-система (Advanced Planning and Shedulling)
3. MES-система
4. SCADA-система

ERP
В ERP-системах преимущественно применяются алгоритмы MRP-II, которые имеют ограничения по скорости вычислений (Closed Loop MRP замыкает в цикл многократный последовательный расчет MRP и CRP) и по видам планирования. В частности, MRP-II ориентирован на объемно-календарное планирование, пооперационное планирование в нем, не реализуется. По этой причине в классических ERP-системах степень детализации планов доходит только до так называемых "рабочих центров", под которыми чаще всего подразумеваются целые цеха или крупные производственные участки. Горизонт планирования в ERP-системе редко бывает меньше 1 недели. А уж чтобы он был меньше суток, о таком мне вообще слышать не приходилось. Отсюда следует, что на низовом уровне определение моментов передачи партий и установки конкретных болванок на конкретный станок производится "от балды" и на основе "ощущений" мастерами участков, бригадирами, производственными диспетчерами.

APS
APS использует иные алгоритмы и вычислительную математику. В отличие от алгоритмов MRP-II, которые требуют множества рекурсий, APS находит решение за минимальное количество итераций. По этой причине скорость расчета получается на многие порядки выше, чем по алгоритмам Closed Loop MRP и в несколько раз выше, чем по алгоритмам MES. Рекордно высокая скорость расчета - одна из главных "фич" APS, она позволяет вносить изменения в план "на лету", буквально не отрывая телефонной трубки от уха. При этом степень детализации планирования оказывается более высокой, чем достижимые алгоритмами Closed Loop MRP, но не такой детальной, как достижимые MES. По степени оптимальности находимого APS решения он, как правило, уступает алгоритмам Closed Loop MRP (если производится планирование на одинаковых горизонтах и с одинаковой степенью детализации), и в существенной степени уступает MES.
Тем не менее, более высокая степень детализации планирования (нежели достижимые MRP), позволяющая если не во всех производствах и не на всех участках, то для их большинства применять подходы пооперационного планирования. При низкой оптимальности APS-планирования за счет существенно более высокой его детализации и решения задач планирования на низовых уровнях, которые MRP-планированием не решаются вообще, APS позволяет во многих случаях достичь существенно более качественного планирования, нежели MRP-планирование. В APS имеются возможности учета некоторой специфики технологических операций (хотя и не до такой степени, как у MES-систем). В частности, можно задать правила покраски в красильной камере на протяжении рабочей смены от светлых тонов к темным, которые невозможно задать для большинства систем MRP-планирования.
APS существуют в природе и как автономные системы, и как модули, поставляемые по запросу к ERP-системе, а в некоторых ERP-системах они включены непосредственно в ядро, и при ее настройке под конкретное предприятие есть возможность выбрать методы планирования, которые следует применять в данном конкретном случае.
Один из самых существенных плюсов APS-систем остается на текущий момент не воспринятым ни IT-специалистами, ни представителями бизнеса. Это высокая скорость планирования, которая позволяет резко увеличить оптимальность планов множества взаимодействующих предприятий в цепочке поставок. В одном из последних номеров журнала "Директор информационной службы" (навскидку не помню, в каком именно) имеется статья Сергея Питеркина, в которой по полочкам разложено, какую колоссальную роль имеет скорость планирования в каждом звене цепочки поставок для ее глобальной оптимизации. Задержка всего на 1 сутки на каждом звене цепочки приводит к резкому возрастанию (на порядок!) буферных запасов между соседними звеньями цепочки поставок и многократной аккумуляции ошибок планирования вследствие вариаций условий внешней среды, информация о которых, проходя с задержками по цепочке, приводит к ошибкам планирования сразу на множестве предприятий, причем эти ошибки приводят к волнообразному "раскачиванию" системы всей цепочки поставок (Питеркин называет это "эффектом кнута").
Таким образом, при не самом оптимальном планировании отдельных предприятий в цепочке, можно резко увеличить оптимальность за счет высокой оперативности и устранения "эффекта кнута" - то есть, за счет повышения глобальной оптимальности цепочки поставок резко (на порядки) снизить запасы материалов и готовой продукции, вплоть до полной ликвидации соответствующих складов.

MES
MES "заряжена" на получение самого детального плана с учетом всех возможных нюансов технологических операций. Например, с возможностью задания параметров оптимальной группировкой деталей по их размерам и по температуре обжига для формирования партий (из различных деталей!) для одновременного их обжига в печи. Для MES можно задать множество различных критериев оптимизации и их совокупностей - чего как правило нет в системах MRP-планирования и APS-планирования. MES получает наиболее оптимальные планы для целей пооперационного планирования на низовом уровне. При этом, у многих MES-систем может быть не развит до такой степени как в ERP функционал, связанный со стратегическим планированием и тактическим укрупненным планированием, а также взаимодействие с финансовым контуром, отделом снабжения, маркетингом и т.д. и т.п. По этой причине пооперационное MES-планирование обычно используют как вторая фаза планирования после укрупненного планирования в ERP-системе, которое детализирует и оптимизирует планированирование низового уровня. По этой причине самое логичное использование MES-систем - в паре с ERP-системой, выполняющей объемно-календарное MRP-планирование.

SCADA
Следующий, еще более детальный уровень управления, связанный уже не только с моментами формирования партий и установки деталей для обработки на конкретном станке, но и с траекториями перемещения кареток, синхронного движения манипуляторов промышленных роботов, автоматизированной регистрации самых элементарных операций - SCADA (или, по-русски, АСУТП). Мне представляется вполне логичной интеграция SCADA-системы с MES-системой.

*** Примерно так. Теперь по поводу высказанного GGE недовольства... ПМСМ, оно одновременно и обоснованно, и нет... :) Вот стороны этого видения:

1) Вполне логичное желание иметь в единой автоматизированной системе управления сразу все уровни детализации. Еще более логичным мне кажется желание получить более оптимальную оптимизацию, нежели позволяет производить ступенчатая оптимизация ERP -> MES, поскольку MES не имеет влияния на оптимальность MRP-планирования (обратной связи), на переходе с одного уровня планирования на другой неизбежно происходят потери. Потому что оптимальность MES-планирования оказывается заключенной в рамки неоптимальности MRP-планирования.

2) Желание, хотя и логичное, трудно выполнимое на практике. Ни одному софтверному гиганту еще не ударось разработать супер-пупер интегральную систему автоматизированного управления, в которой одновременно бы присутствовали CAD+CAM+PDM+ERP+MES+SCADA. Хотя, мечтать не вредно (а вдруг какому-нибудь гению и удастся... :) ). Тем не менее, многие анализы IT-рынка показывают, что решение подобной задачи, скорее всего вообще не выполнимо. И эта невыполнимость определяется не ленью и не низким качеством работы IT-вендоров, а законами природы, в соответствии с которыми комбинация сложности систем, их надежности и готовности оказываются несовместимыми с их жизнью. Точнее, с жизненным циклом разработки монолитного софта, доступность и степень готовности которого поддается закону Пуассона. Приведение сверхсложной монолитной системы в состояние готовности, при котором устранение достаточного количества багов, глюков и недочетов, достаточное для вывода ее на уровень комфортной эксплуатации, оказывается соизмеримым (по самым оптимистическим оценкам) и даже на порядки превышающим (по пессимистическим оценкам) период жизненного цикла программного продукта - супер-пупер-мегасистемы (любой, не только автоматизированного управления).

Эта проблема уже осознана подавляющей частью IT-специалистов и научно обоснована. По этой причине попытки создания мега-систем уже остались в прошлом. Сейчас IT-сообщество сконцентрировало свои усилия на решениях качественной информационной интеграции - с помощью EAI, SOA и т.п. Научно доказано, что концепция SOA впервые позволяет нанести проблеме надежности ПО, базирующейся на законах Пуассона, сокрушительный удар - впервые за всю историю развития IT-отрасли. Набор взаимодействующих автономных служб, каждая из которых является "малой системой" и требует минимального времени на отладку, оказывается на порядки более надежной системой, нежели система монолитного мега-ПО. Установка взамодействия между службами SOA может производиться НЕ IT-СПЕЦИАЛИСТОМ (есть ПО, которое позволяет делать это специалистам прикладной области). Конфигурирование системы масштаба предприятия оказывается прозрачным и доступным для широкой категории пользователей. Проблемы с глюками в одной службе гораздо режже приводят к проблемам всей системы - теперь есть возможность оперативно переустановить связи между сервисами, пустить какие-то действия "в обход". Не говоря уже о том, что устранение проблем "малой системы" - сервиса на многие порядки более простая и быстро выполнимая задача.

Принолшу извинения за многословность, было мало времени... :)

FE Garya , в целом согласен с Вами. Пожалуй, внесу только одну поправку - в APS есть критерии оптимизации и их совокупности, это не прерогатива MES.Спасибо за поправку. Я видел только APS, в которых таких критериев не было.

Юрий КудрявцевНе надо переоценивать значимость SOA-архитектуры, Corba и пр так и не преуспели в заданном направлении.
Советую прочитать http://www.addsimplicity.com/adding_simplicity_an_engi/2006/11/omnipotent_infe.html
и весь этот блог. Архитектор ebay -- яркий представитель "продвинутой части" IT-сообщества.Спасибо, почитаю. Только попозже (сейчас убегаю). В свою очередь попытаюсь найти ссылку на статью, в которой я вычитал о законе Пуассона.

Приношу извинения за то, что увел аудиторию в оффтоп упоминанием о SOA. Создал новую ветку для обсуждения SOA.

GGeНо тока я не понимаю, если в ERP в карточку сотрудника внесли данные, зачем их тащить еще куда то, таблицы то 2 получается... Создать счета бюджета, а потом чтобы их посчитать, тащить еще в другую систему?Нет, конечно же, было бы здорово, если бы все жили вечно и никогда не умирали. Просто не получается жить вечно... :)
Точно так же и тут - "просто не получается" иметь одну супер-пупер-мега-систему. Считаете, что кто-то недоработал? Сделайте ее сами. :)