Прежде всего нужно отметить, что ERP – это не класс систем управления (хотя иногда складывается именно такое мнение), а методология организации бизнес-процессов предприятия. Поэтому для российских условий внедрение подобной технологии подразумевает коренные изменения вcей деятельности компании. Важной особенностью проектирования систем управления предприятием на принципах ERP является направленность на планирование ресурсов производства. Вот почему большинство функций учета, реализованных в этих системах, служат лишь дополнением к основной задаче — составлению планов поставок материалов, производства и пр.
Вообще ERP (Enterprise Resource Planning) означает планирование ресурсов предприятия. Чтобы понять, для чего предназначены системы автоматизации, построенные по этому принципу, надо вспомнить историю их развития. В 60—70-х годах ХХ в. был разработан стандарт управления предприятием, получивший название MRP (Material Requirements Planning) — планирование потребностей в материалах для производства. Дальнейшая его эволюция и привела к появлению стандарта ERP. Системы MRP создавались для производственных предприятий и очень редко использовались при планировании материальных потребностей организаций, оказывающих различные услуги Довольно часто составляющей MRP-систем являлась система планирования производственных мощностей CRP (Capacity Requirements Planning) Очевидно, что данный стандарт разрабатывался только как средство оптимизации и учета движения материалов на производстве. При последующем развитии системы был сформирован стандарт MRPII (Manufacturing Resource Planning) — планирование ресурсов предприятия.
Но на этом развитие информационных систем управления предприятием не закончилось. На смену MRPII пришел новый стандарт – тот самый ERP. Однако он ориентирован уже на работу с сетью удаленных производственных и непроизводственных объектов. Обладая всеми перечисленными в MRPII возможностями, ERP-системы включают еще и механизм планирования потребностей при распределенных запасах (DRP-I/DRP-II — Distribution Requirements Planning), позволяющий определить потребность в пополнении запасов в случае территориально распределенных автономных складов. И кроме того, эти системы допускают обновление аппаратной и программной платформы (в отличие от MRP/MRPII).
|
|
Последним словом в развитии систем управления предприятием является стандарт CSRP (Customer Synchronized Resource Planning) — планирование ресурсов во взаимодействии с покупателем. Иногда в литературе этот стандарт называют ERPII. Его отличает направленность на потребителя: если раньше построение системы было связано с необходимостью оптимизации внутренних процессов компании, то теперь эта проблема решена, и на первый план выходит структуризация процессов взаимосвязей с внешними субъектами. Подобные системы имеют такие функциональные блоки, как CRM (Customer Relationship Management) — управление взаимодействием с покупателями; SCM (Supply Chain Management) — управление цепочками поставок, логистика; BI (Business Intelligence) — поддержка принятия решений и KM (Knowledge Management) — управление знаниями.
Нельзя не сказать несколько слов о САПР (Системах автоматизированного проектирования), без которых не могло обойтись ни одно промышленное предприятие, чья продукция требует конструкторской документации. Современные технологии САПР для предприятий представлены системами CAD/CAM/CAE/PDM (Сomputer Aided Design, Manufacturing, Engineering, Product Data Management). Эти системы позволяют обойтись без "бумажной" документации, осуществляя прямую связь между процессами разработки изделия и его производства, что позволяет повысить качество продукции и сократить период разработки.
|
|
Постепенно между MRP II и ERP образовалась промежуточная группа систем, называемая MES (Manufacturing Execution Systems). Она возникла вследствие обособления задач, не относящихся ни к одной из ранее определенных групп. К системам MES принято относить приложения, отвечающие:
- за управление производственными и людскими ресурсами в рамках технологического процесса,
- планирование и контроль последовательности операций технологического процесса,
- управление качеством продукции,
- хранение исходных материалов и произведенной продукции по технологическим подразделениям,
- техническое обслуживание производственного оборудования,
- связь систем ERP и SCADA/DCS.
Одна из причин возникновения таких систем — попытка выделить задачи управления производством на уровне технологического подразделения. Но очень быстро выявились недостатки разделения задач планирования и управления производством на два уровня. Опыт показал, что информационная база этих задач должна быть единой. Клиент-серверная технология позволяет разделить клиентские части задач управления и планирования производства на два уровня: предприятия и цеха. Теперь можно использовать общие серверы базы данных и приложений, а клиентские места распределить по цехам и заводоуправлению.
|
|
Второй путь возникновения систем MES — снизу, от АСУТ П. Так произошло отделение тактических задач оперативного управления технологическими процессами от стратегических задач ведения процесса в целом. В частности, в химической, металлургической, пищевой и некоторых других отраслях промышленности можно выделить задачи управления технологическими последовательностями (batch control). Их суть — в обеспечении выпуска продукции в нужном объеме с заданными технологическими характеристиками при наличии возможности перехода на новый вид продукции. Отделились и задачи ведения архива значений технологических переменных с возможностью восстановления производственных ситуаций прошедших периодов и анализа нештатных ситуаций. Появились программы обучения технологического персонала и оптимизации ведения технологических процессов.
На пути к интеграции
Рассмотрим подходы к решению задачи объединения промышленных приложений, предлагаемые современными производителями программных продуктов.
Прежде всего напомним, что задачу объединения АСУТП и АСУП условно относят к системам уровня MES. Стремление связать системы типа SCADA/DCS с системами верхнего уровня ERP/MRP II существовало всегда. Каковы же условия этой задачи? Если проанализировать все требования, выдвигаемые пользователями и разработчиками систем управления предприятием, то можно выделить два основных:
- Единое информационное пространство. Ситуация взаимного обмена данными для приложений должна стать обыденной. Необходимо, чтобы данные одного приложения были доступны другому в реальном времени.
- Гибкость (в смысле способности к быстрому перестроению). Возможность безболезненного добавления новых приложений и технологий, которое не требует изменения существующей структуры. Одновременно с этим удаление (замена) рабочих компонентов не должно разрушать систему.
Пожалуй, сегодня можно говорить о трех ключевых направлениях решения задачи: стандартизация, использование связующего ПО (middleware), внедрение глобальных промышленных серверов.
Стандартизация
Поговорим о стандартизации. В офисных приложениях ее преимущества неоспоримы. Это и уменьшение цены на приложение, и повышение его эффективности и удобный пользовательский интерфейс. Промышленные приложения совсем другое поле деятельности. И если образно сравнивать возможности освоения этих двух "пространств", то в первом случае мы имеем дело с равниной, а во втором — с сильно пересеченной местностью. Кроме того что промышленные приложения делятся на группы по типам систем, внутри каждой группы тоже нет функциональной однородности. Многие отрасли промышленности предъявляют к системам управления свои, уникальные требования, связанные с конкретными технологиями производств.
Еще один нюанс — период обновления программных продуктов в промышленности намного больше. Здесь пока нет своего аналога Microsoft, который диктовал бы такой стремительный темп развития. Однако, несмотря на очевидные подводные камни, положительный опыт стандартизации офисных пакетов неизбежно открывает путь введения стандартов на разработку промышленных приложений. Под этим не следует понимать переход к использованию одной операционной системы, базы данных или сетевого протокола, например TCP/IP, поскольку все это никоим образом не гарантирует возможности обмена данными между промышленными приложениями.
Первым шагом в направлении стандартизации была попытка создать однородные протоколы для связи с производственным оборудованием. Современные решения в области стандартизации связаны прежде всего с фирмой Microsoft. Это в первую очередь технология OPC (OLE for Process Control), т. е. OLE (Object Linking and Embedding) для технологического управления. Она представляет собой стандартный метод для доступа к периферийным устройствам, системам SCADA/MMI или другим промышленным приложениям, основанным на технологиях OLE, COM (Component Object Model) и DCOM (Distributed COM). В общих словах OPC представлена набором стандартных объектов, методов и свойств, отвечающих требованиям промышленных приложений реального времени. Эти требования включают в себя синтаксис для доступа к объектам, эффективную передачу данных от оборудования к приложениям, способность клиента работать с несколькими серверами одновременно и поддержку конфигурации сервера. Программные пакеты на основе OPC легко интегрировать в бизнес-приложения, поддерживающие OLE.
Первая версия OPC вышла в 1995 г. Она не претендовала на стандарт, но была призвана сыгратьроль пробного камня для всех заинтересованных сторон. Основной упор был сделан на сбор данных. Более сложные задачи: сигнализация (оповещение о наступлении технологических событий), отслеживание трендов (последовательностей значений параметров, отражающих поведение технологического процесса), моделирование — отложены на будущее. К сожалению, набор продуктов, разработанных по новому стандарту, весьма и весьма ограничен. Сегодня судьба OPC — в руках производителей промышленных приложений. Последний "хит" от Microsoft в этой области анонсирован в сентябре 1997 г. Имя ему — Windows DNA (Windows Distributed interNet Applications Architecture). Эта архитектура также основана на объектно-ориентированной COM-технологии создания функциональных пользовательских компонентов. Новая идея — разработка спецификаций по отдельным отраслям и сегментам промышленности (Vertical Industry Specifications) — не лишена логики и позволит сконцентрироваться на нескольких областях производства, где наиболее популярны программные продукты, поддерживающие COM. Это можно расценивать как признание поражения всех попыток выработать общий промышленный стандарт.
Таким образом, похоже, что будущее стандартизации — в руках Microsoft.
Связующее ПО
После неудачи General Motors на пути стандартизации для решения задачи интеграции был создан консорциум, в который вошли крупные автомобильные производители (Renault, Mercedes-Benz и др.), представители авиационной промышленности и некоторые фирмы бытовой электроники (Bosch, Siemens Automation и др.). Он получил название AIT (Advanced Information Technology). С его помощью была разработана интеграционная платформа CCE (Common Computing Environment). Данная среда позволяет приложениям независимо от протоколов, операционных систем, баз данных и методов доступа общаться друг с другом. Развитие этой идеи привело к возникновению архитектуры CORBA (Common Object Request Broker Architecture), также одобренной консорциумом AIT.
Если говорить о технологии CORBA, то это связующее ПО, "расположенное" между операционной системой и приложениями. Использование данного программного "слоя" облегчает процесс создания приложений, так как дает возможность разработчику абстрагироваться от особенностей операционной системы, сетевых протоколов и конкретных технических решений.
Но не все так хорошо, как кажется. Отметим некоторые недостатки внедрения связующего ПО:
- ускользают возможности использования в приложениях преимуществ конкретной операционной системы, сетевого протокола и т. п.;
- идея всеобщей открытости сомнительна в условиях конкурентной борьбы. Не все фирмы-производители встретят ее на ура;
- идея стандартизации будет погребена, и вряд ли впоследствии удастся вернуться к столь заманчивой концепции;
- очевидны технические трудности такого решения. В промышленности существуют сотни протоколов, с которыми надо научиться работать.
В процессе исследования вопроса выяснилось, что для многих фирм — поставщиков промышленного оборудования и программных пакетов идея использования связующего ПО все же ближе, чем идея стандартизации. Отделение современного программирования от реалий операционных систем и протоколов, как видимо, неизбежно и очень быстро происходит во всех областях. Трудности реализации успешно преодолеваются с помощью среды межобъектных запросов (Object Request Broker — ORB).
ORB — это связующее ПО, которое позволяет устанавливать клиент-серверные отношения между объектами. Используя ORB, клиент может легко вызывать сервис на объект-сервере, при этом аппаратно клиент и сервер могут быть как на одной машине, так и на разных и общаться между собой по сети. ORB перехватывает запрос и отвечает за его доставку, передачу параметров, вызов сервиса, а также за доставку результатов. При этом клиенту совершенно не нужно "знать", где объект-сервер находится, какова его операционная система и на каком языке программирования он написан. Все это — вне интерфейса взаимодействия самих объектов. Таким образом, ORB обеспечивает обмен информацией между приложениями на различных устройствах в неоднородной распределенной среде, создавая связную объектно-ориентированную систему.
Консорциум OMG (Object Management Group), основанный в 1989 г., взял на себя труд разработать теорию объектно-ориентированной технологии для развития распределенных компьютерных систем. Основное направление деятельности консорциума можно сформулировать так: развитие общей архитектурной платформы для объектно-ориентированных приложений на основе открытых спецификаций. Его девиз звучал бы, наверное, более патетически: "Архитектура для объединения мира".
Их усилия увенчались появлением архитектуры CORBA, позволившей решить проблему "информационного Вавилона" в мире промышленных компьютерных технологий. Она дает возможность приложениям обмениваться данными вне зависимости от того, где они находятся и кто их разработал. CORBA — это не набор директив, а только спецификации, которые свели воедино идеи членов OMG.
Версия 1.1 спецификации CORBA была выпущена OMG в 1991 г. В ней были определены язык описания интерфейса (Interface Definition Language — IDL) и интерфейсы прикладного программирования (Application Programming Interfaces — API), сделавшие доступным взаимодействие клиент—объект в среде ORB. Суть модели в следующем. Клиент запрашивает сервисы у объекта (который выступает в качестве сервера) через хорошо определенный интерфейс (последний специфицирован в IDL). Для доступа к объекту клиент создает запрос, т. е. сообщение, содержащее информацию о действии, ссылку на сервис, параметры.
Спецификация CORBA 2.0, "родившаяся" в декабре 1994 г., определила информационный обмен между приложениями различных фирм. Она добавила к уже освоенным высотам возможность обмениваться данными через Интернет по протоколу IIOP (Internet Inter-ORB Protocol) и платформенную независимость. Ее внедрение позволяет пользоваться преимуществами Интернет без перестройки промышленной системы.
И все-таки архитектура OMG/CORBA более зрелая, чем OPC и тем более Windows DNA. Уже существуют многочисленные ее реализации, применение которых в промышленности делает приложения независимыми от используемых устройств, сетей, операционных систем и компьютеров. Возникают заманчивые перспективы свободного развития приложений, с одной стороны, и общей инфраструктуры — с другой. Правда, если наступит эра всеобщей стандартизации по версии Microsoft, то CORBA останется не у дел. Но, пока она не наступила, CORBA, пожалуй, лучшее решение для объединения в единый комплекс автоматических систем управления различных уровней с учетом того, что некоторые из них устарели, а другие не подчиняются никаким стандартам и предлагают уникальные решения.