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