ОСОБЕННОСТИ ВНЕДРЕНИЯ ИННОВАЦИОННЫХ (СЕРВИС

Джичко О.Б., Бушмелева К.И.
ОСОБЕННОСТИ ВНЕДРЕНИЯ ИННОВАЦИОННЫХ (СЕРВИС - ОРИЕНТИРОВАННЫХ) ТЕХНОЛОГИЙ НА ПРОИЗВОДСТВЕ
Рассматриваются проблемы и базовые принципы перевода имеющейся информационной системы предприятия
на
сервис
–
ориентированную
архитектуру,
призванную,
разбить
монолитные
приложения
автоматизированных систем для построения из их элементов сквозных бизнес-процессов.
Сервис - ориентированная архитектура (SOA) на предприятии
В последнее время идея построения информационных систем на предприятии с использованием сервис
ориентированной архитектуры активно продвигается такими крупными производителями программного
обеспечения как Oracle, SAP, IBM. Данная идея дает предприятиям возможность внедрения инновационных
технологий (сервис – ориентированных) в нескольких плоскостях:
1. Любая информационная система, построенная на SOA архитектуре, поставляет набор сервисов –
функций, реализующих один из шагов бизнес-процессов. Отсюда следует, что в процессе проектирования,
можно комбинировать сервисы различных производителей, выбирая у каждого из них лучшее для
автоматизации определенных бизнес-процессов;
2. Композитные приложения, позволяют реализовать логику бизнес-процессов, предоставляют
пользователям единую точку входа и имеют один WEB интерфейс для всех охваченных на предприятии SOA
систем;
3. Гибкость внесения изменений.
С архитектурной точки зрения эти инновации несут одно лишь благо в рамках целой организации. Но
«ломка» существующих информационных систем в целях внедрения новой концепции встречает как явное,
так и не явное противодействие.
Разделение систем на АСУ ТП, АСУ ПП, АСУ РП
Исторически сложилось разделение автоматизированных систем управления (АСУ) используемые на
производстве на следующие: АСУ ТП (Технологических Процессов), АСУ ПП (Производственными Процессами)
и АСУ РП (Ресурсами Предприятия) (рис.1). Критерием разделения являлась область автоматизации во
времена расцвета АРМ (Автоматизированных Рабочих Мест).
Так, например, АСУТП решали вопросы по опросу/управлению контроллерами, установленными на
производственных объектах и представления информации в виде «Облака» - моментального снимка
состояния базы данных (БД), с возможностью передачи информации в другие системы.
АСУ ПП – системы класса MES – предназначались для оперативного управления производством, т.е.
сбора, обработки, хранения и визуализации информации о производственных процессах.
АСУ РП – системы класса ERP, изначально, позиционировались как системы учета, то есть в первую
очередь бухгалтерского.
Рис. 1. Схема разделения автоматизированных систем управления
Со временем, пришло понимание, что системы АСУ ТП, АСУ ПП и АСУ РП описывают одни и те же
процессы, только с разных точек зрения и с различной детализацией. Например, сигналы датчика об
объеме передаваемой жидкости в скважине для АСУ ТП дает динамику для определения функционирует ли
оборудование, а при падении или резком увеличении значений - сигнализирует об авариях. Для АСУ ПП –
информация необходима для принятия решения о том, насколько текущая ситуация соответствует
технологическому процессу и какие мероприятия необходимо дополнительно выполнить. Для систем учета
АСУ РП - этот показатель востребован для расчета себестоимости, расчета затрат, налогов и техникоэкономических показателей.
Разделение интересов и сфер ответственности. Смещение акцентов при интеграции учета
Искусственное, создание границы в областях автоматизации требует закрепления конкретных
исполнителей за определенным направлением, наделение их обязанностями и полномочиями, принимать
участие в определении направления развития информационных технологий в своей области.
В результате проявилась следующая проблема: искусственные границы стали нарушаться все чаще и
чаще, так:
в процессе развития систем АСУ ТП появилась потребность в получении отчетности, хотя «правильнее»
было бы реализовывать ее в области АСУ ПП;
активная эксплуатация на предприятии АСУ ПП, вызывает «привыкание» пользователей к данной
системе, что в свою очередь расширяет ее функциональность, как в сторону АСУ ТП – это предоставление
оперативной информации о состоянии тех процессов, так и в сторону АСУ РП – это расчеты экономической
эффективности мероприятий и учет перемещения оборудования и материалов;
внедрение систем АСУ РП требует интеграции бухгалтерского и производственного учетов. А это
значит – что в системе класса ERP должны родиться документы, отражающие производственную
деятельность, то есть фактически системы АСУ РП начинают приобретать функции производственных систем
(АСУ ПП).
С одной стороны, наличие стандартных решений дает возможность выбора лучшего из них. С другой
стороны, в силу исторических особенностей, в крупных компаниях АСУ ТП, АСУ ПП и АСУ РП обычно
распределяются между различными службами и, возможно, различными производителями систем (так как
потребность в автоматизации по каждой из областей возникает по мере становления организации и
совершенствования системы управления), то есть выбор, где и как автоматизировать рассматривается как
вопрос о влиянии и о сохранении наработанного потенциала (опыта, программного обеспечения,
аппаратных средств). В итоге возникает:
дублирование функциональности и все связанные с этим недостатки: затраты на разработку,
внедрение, аппаратное обеспечение, временные затраты пользователей, потребность в стыковке систем;
снижение эффективности работы, заключающееся в «перетягивание одеяла» по областям АСУ ПП, АСУ ТП
и АСУ РП, которое может перерасти в борьбу продуктов/производителей/служб.
И, самое главное, с развитием системы управления производства зреет необходимость в
интегрированной информации, сквозных бизнес-процессов.
Вот тут-то и появляется возможность внедрения на производстве новой SOA архитектуры, призванной,
соединять и проводить через различные системы сквозные бизнес-процессы. При этом идея использования
композитных приложений выглядит достаточно убедительной: нет приоритета выбора какой-либо из систем
(будь то АСУ ТП, АСУ РП или АСУ ПП), так как пользователь будет работать в WEB интерфейсом,
используя при этом лучшие сервисы различных систем.
Однако при этом может возникнуть следующая проблема, практически все поставщики программного
обеспечения (IBM, SAP, Oracle, …) «тяжеловесы» и имеют свои средства проектирования логики
исполнения и построения интерфейсов. Естественно, если программный продукт хоть одного из
производителей используется на любом из уровней, то применение его набора средств для развертывания
ландшафта SOA целесообразнее. Более того, в будущем вероятнее всего для повышения привлекательности
своих продуктов производители будут создавать их уже на платформе SOA. А что делать, если на
предприятии решений разных производителей присутствует несколько? Ведь теперь различные службы
должны решить для себя, какое направление развивать.
Заключение
Одним из решений при начале внедрения сервис - ориентированной архитектуры должно стать создание
«совета», в задачи которого включено развитие единой информационной системы и координация всех
разработок.
Развитие информационной системы необходимо начинать с базовых принципов построения единого
информационного пространства (единства нормативно-справочной информации, однократный ввод информации
– широкое использование, и др.).
Необходимо отказываться от создания границ/зон действия имеющихся программно-аппаратных средств и
создания, жестких правил их взаимодействия между собой. А также учитывать неопределенность в сроках
жизни продуктов и расширения их номенклатуры. Создание строгих правил служит не началу интеграции и
взаимодействия, а ведет к обратному – ограничивает вариантность и, следовательно, приводит к
неэффективному использованию.
Каждое отдельное решение при организации обмена информацией и реализации сервисов должно
приниматься исходя из наличия ресурсов (технических, программных, человеческих). Важно при этом
придерживаться установки проектирования сверху вниз: от бизнес-процессов до систем и их технической
реализации. Иначе гибкость будет недостижима, а ресурсы будут истощены в борьбе за автоматизацию
какой-либо части в угоду внедрения определенного программного обеспечения.