На ММК создается корпоративная система управления единым информационным пространством на основе SOA

К концу 2007 г. на Магнитогорском металлургическом комбинате (ММК) совместными усилиями ИТ-дирекции ММК и компании “Ай-Теко” реализован первый этап проекта по созданию корпоративной системы управления единым информационным пространством предприятия. Рассказом о пройденном пути и опыте реализации и внедрения этого программного решения с нами поделились директор департамента программной интеграции “Ай-Теко” Дмитрий Грязнов и начальник отдела интеграции и архитектуры взаимодействия систем ММК Николай Королев.

Начало пути

К концу 2005-го ИТ-дирекция комбината завершила внедрение серии успешных проектов, в частности КИС на базе Oracle E-Business Suite (OEBS) и центрального диспетчерского комплекса, обеспечивающего оперативный мониторинг работы производственных агрегатов и ММК в целом. Основой систем корпоративного уровня стали цеховые автоматизированные системы, объединение которых с верхним уровнем обеспечивалось интеграционной платформой собственной разработки. В ходе эксплуатации корпоративной информационной системы как комплекса взаимосвязанных между собой множества систем стало очевидным, что для успешного функционирования и развития этого сложного организма требуется качественно новый уровень интеграции элементов системы. Речь шла уже не о перекачке и загрузке описанных и структурированных блоков данных из системы в систему, а о создании унифицированного интеграционного слоя, который должен был стать стандартом и полноценной платформой единого информационного пространства ММК. Столь пристальное внимание к данному направлению было вызвано тем, что на комбинате возник целый ряд проблем и задач, связанных со взаимодействием имевшихся ИТ-систем и сокращением затрат на внедрение новых, а также с разработкой процессных подходов к управлению бизнесом, со стандартизацией и повышением требований к безопасности (см. таблицу).

В середине 2006-го руководство дирекции по информационным технологиям ММК приняло решение создавать систему управления единым информационным пространством предприятия. А уже в конце года совместными усилиями была разработана “Концепция создания и развития корпоративной системы управления единым информационным пространством ОАО ММК на основе сервисно-ориентированной архитектуры” — документ, который определял пути построения системы и основные направления ее развития. В результате исследований методология SOA была принята за основу при создании интеграционной платформы. Дальнейшие шаги были связаны с выбором пилотной зоны, проектной методики и базовой интеграционной платформы.

Предпроектный анализ

Выбор пилотной зоны был обусловлен тем, что на ММК функционирует более 200 ИС, разнородных по составу и назначению, но увязанных в единое информационное пространство корпоративной информационной системой.

Верхним уровнем КИС является ERP-система на базе OEBS, которая осуществляет активный обмен информацией о технологических процессах с цеховыми MES-системами, отвечающими за непрерывное производство.

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

Интеграционные решения по передаче портфеля заказов функционируют на уровне обмена информацией между базой данных OEBS и базами данных локальных информационных систем (OEBS, Sybase ASE, Sybase SQL Anywhere).

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

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

В случае успешного завершения пилотный проект мог бы рассматриваться как первый этап работы по созданию корпоративной системы управления единым информационным пространством.

Следующим шагом предпроектного анализа был выбор методики реализации пилотного проекта. Компания “Ай-Теко” разработала проектную методику, предусматривающую несколько подходов к реализации интеграционных систем. Например, подход, основанный на сквозном проектировании, исключает деление проекта на пилотную стадию и стадию полномасштабного проекта. Другой подход — по требованию — подразумевает развертывание системы на стенде “Ай-Теко” с предварительной симуляцией процессов. Наконец, третий подход, так называемый классический, включает реализацию пилотного проекта на оборудовании “Ай-Теко” или заказчика, а затем -- его расширение до необходимого уровня. После обсуждения был выбран классический подход: поскольку на комбинате была разработана и согласована “Концепция взаимодействия цеховых MES-систем и системы верхнего уровня на платформе OEBS в рамках КИС ОАО ММК”, то решили начать с пилотного проекта по организации эффективного взаимодействия цеховых MES-систем и OEBS

Третьим важным шагом предпроектного анализа стал выбор платформы, на которой должно базироваться решение. Специалисты “Ай-Теко” предложили рассмотреть интеграционные платформы компаний Oracle, IBM и Tibco. По результатам анализа и тестирования ИТ-руководство комбината остановилось на решении Tibco как наиболее полно удовлетворяющем предъявляемым требованиям.

Выработка решения

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

Подготовка к пилотному проекту завершилась в марте 2007 г. подписанием между ММК и “Ай-Теко” соответствующего договора. Одновременно специалисты “Ай-Теко” совместно с представительством компании Tibco в России решали вопросы организации логистического процесса и обучения специалистов комбината.

О сложности реализуемой задачи можно судить, взглянув на рис. 1, где приведена общая схема взаимодействия информационных систем и оборота информации о заказе продукции в производственных подразделениях.

Первые результаты

Работы по проекту стартовали в марте 2007 г. и были разбиты на три этапа.

  • Этап 1 — логическое проектирование. На этом этапе на основании утвержденного технического задания исполнитель совместно с заказчиком разработали проект создания КСУ ОЭП.
  • Этап 2 — физическое проектирование. В его ходе разрабатывались программные модули КСУ ОЭП, проводились испытания, опытная эксплуатация, документирование и сдача-приемка программных модулей.
  • Этап 3 — завершение работ. Этот этап включал анализ опытной эксплуатации системы и ее доработку.

Все перечисленные этапы были выполнены точно и в срок, и в августе 2007 г. КСУ ОЭП была сдана в промышленную эксплуатацию. Архитектура внедренной системы приведена на рис. 2, из которого можно видеть, насколько упорядочилась организация информационных потоков, реализованных на базе ESB.

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

В 2008 г. планируется провести второй этап проекта по созданию и развитию корпоративной системы управления единым информационным пространством ММК. А на основе созданной интеграционной платформы ММК намерен заняться вопросами создания систем управления бизнес-процессами и разработкой сервисной модели функционирования ИТ-подразделения.

Проблемы обеспечения работоспособности корпоративной информационной системы комбината
Решаемая задача/проблемаОписание задачи/проблемыПредлагаемое решение
Оперативность доставки данных, снижение накладных расходов на доставкуСуществующие системы информационного обмена основаны на периодическом опросе источника данных. При этом возникает проблема несвоевременной доставки информации, а также значительно увеличиваются накладные расходы на ее передачу, поскольку она включает множество временных таблиц и всевозможные логи изменения данных. При этом возникает большая нагрузка на источники данных из-за периодических опросов, а также большие объемы информации, передаваемой вхолостуюПереход на модель передачи информации, управляемой по событию.

Использование многопоточности в каналах передачи данных позволяет значительно ускорить доставку

Снижение расходов на адаптацию информационных систем под меняющиеся требования бизнесаИспользуется жесткое кодирование алгоритмов при разработке информационных систем, затрудняющее их последующую модификацию и повторное использование. В результате имеем несколько реализаций одного и того же бизнес-процесса в нескольких, а иногда и внутри одной системыСоздание сервисов по обработке информации. Слабая связанность сервисов существенно повышает их мобильность и возможность многосторонней интеграции. Благодаря этому сервисы можно перемещать с одного сервера на другой, менять параметры связи и объединять сервисы в единое приложение не на этапе разработки, а на этапе исполнения
Нормализация форматов обмена информациейВ эксплуатации находятся системы, разработанные в различных средах и использующие СУБД разных производителей, версий и т. п. При взаимодействии систем возникает проблема унификации форматов данных, ограничения использования драйверов различных версийИспользование общепринятых стандартов SOA: XML, SOAP, WSDL. Поддерживаются всеми ведущими производителями ПО
Увеличение управляемости процессов интеграции.

Снижение накладных расходов на сопровождение

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

Развитая система диагностики.

Средства обеспечения отказоустойчивости (поддерживаются кластерные технологии).

Единый интерфейс администрирования и управления

БезопасностьКлиентскому ПО и разработчикам предоставлен доступ к БД, что ведет к потенциальным рискам несанкционированного доступа к данным, приводит к непрогнозируемой нагрузке на сервер БД. Отсутствие протоколов обращений к источнику данных затрудняет разбор спорных ситуацийПредоставление данных через сервисы обеспечивает эффективное ограничение доступа.

Авторизация доступа к сервисам возможна как на транспортном уровне (с помощью паролей или SSL-сертификатов), так и путем поддержки стандартов WS-Security.

Обращения к сервисам протоколируются