В настоящее время вопросы интеграции приложений в корпоративной информационной системе становятся все более и более актуальны. К сожалению, уйти от "кусочного" подхода к созданию информационной системы не удается не одной компании с развитой структурой приложений. Автоматизировать одновременно все участки бизнеса не возможно, это приводит к тому, что системы развивается эволюционно от решения отдельных, первоочередных с точки зрения экономической эффективности проблем, ко все более сложным и комплексным задачам. Движение это происходит достаточно медленно, так как требует не только существенных финансовых вливаний, но и структурных преобразования бизнеса.
Но по мере внедрения информационных технологий в компаниях рынок программного обеспечения тоже не стоит на месте, появляются все новые и новые программы и даже классы программного обеспечения, параллельно с этим происходят изменения в кадровом составе "автоматизаторов", все это приводит к изменениям в архитектуре информационной системы и структуре приложений компании.
Эти и другие факторы приводят к тому, что информационные системы компаний представляют собой комплекс разрозненных приложений, использующих различных способы хранения данных, дублирующих справочную информацию, отличающихся по пользовательскому интерфейсу и системам обеспечения безопасности и даже подчас функционирующих на различных программно аппаратных платформах.
Все это приводит к существенному повышению стоимости владения подобной информационной системы, снижает эффективность использования накапливаемых в них информации и знаний, а также делает крайне трудным развитие подобной системы. Понимание данной проблемы привело к тому, что требования к "возможности интеграции", в настоящее время, являются одним из ключевых при внедрении любого приложения в корпоративной информационной системе. Не случайно анализ IDC выделяет сегмент услуг по "интеграции" корпоративных приложений в качестве одного из наиболее емких сегментов IT индустрии на ближайшее десятилетие. В задаче интеграции приложений можно выделить несколько аспектов по степени фундаментальности преобразований, проводимых в системе.
Интеграция инфраструктуры
Данный аспект подразумевает унификацию базовых инфраструктурных элементов информационной системы - аппаратной платформы, операционной системы, службы каталогов и средств аутентификации, средств хранения данных и резервного копирования, WEB технологий и пр. Подобная интеграция требует существенных инфраструктурных модификаций в информационной системе и, как правило, приводит к радикальным модификациям в структуре приложений, используемых в компании.
Интеграция данных
Второй сценарий интеграции не затрагивает основных инфраструктурных аспектов, за исключением средств хранения данных, основными целями подобной интеграции является организация общего пространства данных, включая организацию общего пространства справочной информации, максимальной нормализации данных, организации общего интерфейса доступа к данным, интегрированных средств поиска и пр. Реализация данного сценария дает огромный выигрыш в плане минимизации издержек на поддержание системы, возможностей извлечения различной информации и создания инфраструктуры управления знаниями. Однако реализация данного сценария требует внесения серьезных, изменения в наработанные в компании приложения.
Интеграция процессов
Данный способ интеграции является наиболее просто реализуемым и, тем самым, более практически приемлемым (данная простота является относительной, и тоже требует существенных усилий при реализации). Данный сценарий не подразумевает существенного изменения отдельных приложений, целью его реализации является организация сквозных процессов, в которых на отдельных этапах реализации процесса задействованы те или иные приложения. При этом обработка данных на отдельных этапах может производиться в различных приложениях, а функции организации процесса и связи различных подсистем реализует специализированная подсистема. Оптимальным средством для реализации последнего сценария интеграции приложений являются WorkFlow системы.
Прежде чем проанализировать функции WorkFlow системы, потребные для реализации подобных задач проанализируем элементарные действия, из которых состоят сценарии интеграции процессов. К ним относятся:
-
Мониторинг и обработка событий в прикладный системе.
Для инициализации процесса обработки информации порождаемой (модифицированной) в том или ином приложении, необходимы средства наблюдения за появлением или изменением состояния объекта прикладной системы в соответствии с определенными критериями и формирование события в подсистеме управления процессами. Например, при заполнении регистрационной формы на корпоративном WEB сайте может быть запущен процесс обработки в подсистемах управления взаимодействиями с заказчиками, подсистеме технической поддержки и пр.
-
Обмен данными между прикладной системой и подсистеме управления процессами.
Для возможности передачи значимой информации между отдельными этапами процесса, как в приведенном выше примере, передачи координат заполнившего заявку и ее содержимое в соответствующие подсистемы для дальнейшей обработки, необходимы соответствующие механизмы. Передаваться между подсистемами могут как обычный текст, так и файлы, а также различная структурированная информация, например информация, привязанная к записям справочников, как в случае информации о контрагенте в рассматриваемом примере.
-
Маршрутизация объекта вне прикладной системы
Очень часто возникает необходимость маршрутизации того или иного объекта прикладнойсистемы (документа, электронной формы, файла, отчета, записи справочника и пр.) Приэтом, доступ к данному объекту должен осуществляться не в рамках специализированного АРМ"а и из общей очереди заданий подсистемы управления процессами. Например, из почтового ящика Microsoft Outlook. Примером подобной задачи может быть внесение согласовательной визирующей подписи на договор, созданный в специализированной системе согласующими лицами. Для обеспечения данной возможности объект прикладной системы должен обладать возможностью быть переданным системой маршрутизации (например, постпредством электронной почты) на рабочее место пользователя. Можно выделить два типа маршрутизации On-line при которой сам объект физически не перемещается а маршрутизируется ссылка на объект и Off-line при которой объект изымается из системы и физически перемещается на клиентское рабочее место для обработки.
-
Специализированная обработка прикладного объекта в рамках подсистемы управления процессами
Более сложный сценарий маршрутизации объекта прикладной системы может включать возможность его специализированной обработки в рамках бизнес процесса. Например, если в зависимости от специфики действий пользователя при обработке объекта будет меняться логика обработки бизнес процесса или его структуры (документ завизирован и может быть передан в дельнейшую обработку или в него внесены изменения, и он должен быть передан на повторный цикл согласования), то необходимы механизмы дополнительной интеграции прикладной системы и подсистемы управления процессом.
-
Совместное использование справочной информации
К сожалению, не всегда удается инкапсулировать всю обработку справочной информации в функции прикладной системы, примерами когда необходимо использовать содержимое справочников в подсистеме управления процессом могут быть следующие сценарии - пересылка документа внешнему контрагенту, адрес которого содержится в справочнике контрагентов, определение приоритета и соответственно скорости обработки запроса системой из справочника типов клиентов и пр. Данные сценарии требуют непосредственного обращения подсистемы управления процессам к справочным данным прикладных систем. Практическая реализация данных функций может быть различной. В качестве примера cистемы, поддерживающей вышеописанные сценарии интеграции можно привести систему управления бизнес процессами, разработанную на базе платформы DocsVision 3.1.
Учитывая означенную выше разнородность прикладных систем, с которыми может потребоваться интеграция, в системе DocsVision 3.1 WorkFlow реализован интерфейс программного шлюза прикладной системы. Система обеспечивает возможность подключение различных шлюзов обеспечивающих следующие возможности:
-
При подключении шлюза прикладной системы к контуру автоматизации бизнес процессов, отдельные объекты прикладной системы (указатели на объекты и данные справочников) становится доступны в качестве переменных процесса для обработки в рамках подсистемы Workflow.
Рис.1. Программный шлюз WorkFlow системы, обеспечивающий возможность оперировать объектами прикладной системы в качестве переменных процесса, и параметризовать ими исполняемые в процессе функции
-
Шлюз реализует собственный набор функций (элементов описания процесса), обеспечивающих стандартные функции взаимодействия с прикладной системой - мониторинг событий и обмен данными. В частности данные функции обеспечивают следующие возможности:
-
Определение появления нового объекта в прикладной системе согласно критериям фильтрации объектов возможных для прикладной системы, и передача его для обработки в рамках процесса
-
Определение внесения изменений в содержимое конкретного объекта прикладной системы
-
Обмен данными между содержимым объектов прикладной системы и переменными процесса
-
Доступ к различным объектам прикладной системы в рамках бизнес процессов, для использования их в качестве переменных процесса и для параметризации отдельных функций процесса.
-
Возможность извлечения ссылки на объект прикладной системы (для on-line маршрутизации) или экспорта объекта (off-line маршрутизации) и их передачи на этапы ручной обработки, в рамках системы маршрутизации.
Рис.2. Программный шлюз WorkFlow системы, обеспечивающий взаимодействие с файловой системой, реализует функции для мониторинга событий и обмена данными с файловой системой
-
Помимо этого шлюз может "поставлять" специализированные функции обработки "внешних" объектов в рамках процесса. Так, например, для реализации упомянутого выше примера может понадобиться дополнительная функция визирования документа, хранящегося в прикладной системе. При этом данная функция имеет несколько контекстов использования - в рамках дизайнера процесса (позволяет ввести основные параметры функции, в частности связанные с данными прикладной системы и связать их с окружением процесса), в рамках сервера исполнения процесса (реализовывает серверную часть обработки функции), в рамках клиентского рабочего места (обеспечивает клиенту системы доступ к данным обрабатываемого прикладного объекта).
В настоящее время реализованы два стандартных шлюза WorkFlow DocsVision 3.1 - для работы с приложениями, разработанными собственно на базе платформы DocsVision и для работы с файловой системой. Помимо этого в настоящее время ведется разработка программных шлюзов для взаимодействия с системой электронной почты и приложениями разработанными на базе Microsoft Outlook. Также в стадии проектирования находится программный шлюз для взаимодействия с приложениями на базе Microsoft Business Solutions-Navision.