Наверное, не будет слишком уж сильным невежеством утверждать, что максимально возможный эффект для бизнеса от ИТ-решения, отнесенный к стоимости его разработки/внедрения — величина примерно одинаковая для решений разных вендоров, технологий, парадигм и т.п. Есть лишь только одна маленькая деталь – реальный эффект от ИТ-решения, как правило, существенно меньше максимального (часто иногда он меньше нуля) и стремится к максимальному в том случае, если это правильное решение для конкретной компании и внедряется оно правильными людьми. Попытки внедрить 1С в компаниях, где нужен SAP приводят к печальным последствиям. Равно как и внедрение SAP в компаниях, где вполне подойдет 1С приводит к неадекватным расходам на внедрение и дальнейшее сопровождение и, в конечном счете, к тем же печальным последствиям (для ИТ-руководства). Ну, собственно, это философия ИТ.

В силу наличия в голове описанных выше установок, я был настроен весьма скептически, когда впервые столкнулся с BPM-системами. Обещания разработчиков систем выглядели фантастически: комплексная автоматизация целых бизнес-процессов практически без программирования и с копеечной стоимостью лицензий. Здесь и далее я привожу в качестве примера систему BizAgi BPM Suite, хотя существует целый класс подобных систем под общим названием BPMS (Business Process Management System). Сразу возникали закономерные вопросы: для чего тогда существуют ИТ-подразделения, занимающиеся внедрением и стыковкой между собой систем разных классов и вендоров? Для чего существуют команды разработчиков почти на каждом предприятии, пишущие свои собственные системы «с нуля»? Для чего пользователям приходится ежедневно работать с десятком разных приложений? Ведь можно поставить одну BPM-систему «из коробки», посадить за нее продвинутого пользователя, который настроит в ней все бизнес-процессы компании, а другие менее продвинутые пользователи будут исполнять их в этой системе в соответствии со сделанными настройками! Конечно же, тогда я не поверил в то, что это возможно и был прав, но лишь отчасти…

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

В этой статье я приведу в качестве примера бизнес-кейс по внедрению BPM-системы и рассмотрю, для каких еще задач оправданно применение BPM-системы.

От общего к частному: бизнес-кейс по внедрению BPM-системы

Что за бизнес?

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

Какие есть проблемы?

«Единицей» услуг, оказываемых компанией, является «заказ» — печать, упаковка и отправка определенного тиража для определенного клиента и здесь есть два важных обстоятельства:

1. Выполнение каждого заказа должно происходить в определенной технологической последовательности (по большей части стандартной), причем, в этот процесс на разных этапах вовлечено большое количество разных людей, разнесенных территориально (технологический офис, цеха, отдел продаж и т.п.).
2. Одновременно в компании выполняется множество заказов, находящихся на разных стадиях исполнения.

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

Этим обуславливаются следующие проблемы:

1. Высокие ручные трудозатраты на ведение сводной информации по выполняемым заказам, их статусам, плановым датам отдельных операций и т.п.
2. Недостаточное качество и актуальность подобной информации. В целом, невозможно быстро и точно сказать какой заказ на какой стадии находится в данный момент, в чьей зоне ответственности и т.п.
3. Дополнительные издержки, связанные с недостаточно эффективным использованием оборудования и трудовых ресурсов.
4. Отдельные виды проблем с качеством.
5. Прочие стандартные проблемы, связанные с недостаточной автоматизацией основных бизнес-процессов и процессов управления.

Какое предложено решение?

Внедрение BPM-системы BizAgi BPM Suite, в частности:

1. Описание бизнес-процесса выполнения типового заказа (и вариаций нетиповых заказов в качестве дальнейших направлений развития).
2. Настройка данного бизнес-процесса в системе: сама схема процесса, схема данных и формы ввода данных, правила автоматического назначения исполнителей операций.
3. Интеграция с системой 1С: получение из 1С исходных параметров заказа и передача в 1С информации о текущем статусе его выполнения.
4. Интеграция с системой учета брака собственной разработки для передачи информации о браке между участниками бизнес-процесса.
5. Выполнение заказов в рамках BPM-системы, накопление статистики по фактическим параметрам выполнения заказазов.
6. Анализ и совершенствование выполнения бизнес-процессов (внесение соответствующих изменений в BPM-систему, в качестве дальнейших направлений развития).

Как это выглядит?

Описанный выше бизнес-процесс выполнения типового заказа, прорисованный в деталях в нотации BPMN, являющейся в настоящее время де-факто стандартом описания бизнес-процессов и поддерживаемой BizAgi BPM Suite:

Для работы в BPM-системе конечные пользователя (менеджеры и исполнители в настроенных бизнес-процессах) используют вэб-портал, с которым они взаимодействуют через браузер. В нем они непосредственно исполняют бизнес-процессы, получают сводную оперативную и аналитическую информацию в соответствии с правами доступа:

Пользовательский интерфейс BPM-системы представляет из себя набор настраиваемых форм, которые привязываются к операциям бизнес-процесса и отображаются для получение и ввода данных при выполнении соответствующей операции:

Формы в свою очередь получают и сохраняют информацию в базе данных BPM-системы. Информационная модель данных в BizAgi BPM Suite настраивается при помощи визуального редактора в соответствии с требованиями предметной области:

Также можно увидеть как это функционирует «в живую» на моем демонстрационном стенде: demo.kholodkov.ru

Какова стоимость данного решения?

1. Стоимость лицензий BizAgi Xpress – 20 лицензий – 70.000 рублей.
2. Стоимость работ по внедрению – 150.000 рублей.
3. Стоимость оборудования (1 виртуальный сервер на платформе VMware vSphere) – 20.000 рублей.
4. Стоимость системного ПО (Microsoft Windows Web Server 2008 R2) – 20.000 рублей

Итого: 260.000 рублей.

От частного к общему: области применения BPM-систем

У BPM-систем много «конкурентов» среди информационных систем других классов, при помощи которых те же самые бизнес-процессы могут быть автоматизированы иначе. В частности: учетные и интегрированные ERP-системы, системы электронного документооборота, корпоративные порталы взаимодействия, системы управления проектами и собственные разработки.

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

• Деятельность организации имеет выраженный процессный характер в противоположность функциональному или проектному. Например, для конструкторского бюро, разрабатывающего новые виды ракетной техники, BPM-система будет малополезна в отличие, например, от хорошей комплексной системы управления проектами. А вот для кредитного агентства, рассматривающего заявки на получения кредитов, BPM-система может очень подходить в качестве средства автоматизации процессов рассмотрения заявок различных типов.
• В организации существуют процессы, растянутые во времени. Например, процесс приготовления блюда в ресторане занимается несколько десятков минут и вряд ли требует учета выполнения отдельных операций (нарезка картошки, жарка мяса и т.п.). Напротив, процесс поставки товаров из-за рубежа (заказ, оплата, транспорт, таможня и т.п.), длящийся дни и недели, — кандидат на исполнение в BPM-системе.
• В выполнение процессов вовлечено много людей, разнесенных географически. Очевидно, что если в процессе участвуют всего два человека, сидящих за соседними столами, то они смогут договориться и координировать совместную деятельность и без BPM-системы. Если же исполнителей много, то BPM-система реально облегчит управление, взяв на себя передачу «потока» и сопутствующей информации от процесса к процессу, от операции к операции, от человека к человеку.
• При выполнении процессов происходит обмен информацией между несколькими информационными системами. С точки зрения пользователя удобнее работать с одной информационной системой, однако на практике пользователям часто приходится получать и вводить информацию в различные системы: ERP-система, система электронного документооборота, CRM-система, корпоративный портал и т.п. В этом случае BPM-система может стать «единой точкой ввода и получения информации» пользователями при выполнении процессов. Сопутствующим извлечением и внесением данных в другие системы занимается «интегрирующая» BPM-система без участия пользователя.

Процессы, соответствующие перечисленный выше характеристикам («процессы для BPM-системы»), можно встретить во многих даже относительно небольших компаниях. Доля их в бизнесе может быть велика или мала. Также может быть высока или низка их важность для успеха организации.

Исходя из этих двух факторов, можно сделать вывод о целесообразности внедрения BPM-системы в конкретной организации. Если «процессов для BPM-системы» в компании много и/или они являются ключевыми, то имеет смысл рассмотреть возможность внедрения BPM-системы. В остальных случаях лучше посмотреть в сторону систем из других классов.

Наконец, приведем некоторые примеры отраслей и «процессов для BPM-системы» в них.

Заключение

Если Вы видите в своей организации «процессы для BPM-системы» и написанное выше для Вас интересно – предлагаю Вам рассмотреть возможность внедрения BizAgi BPM Suite. Это не потребует от Вашей организации никаких материальных затрат в том случае, если вы все же решите, что BPM-система Вам не нужна. Почему? Потому что, сотрудничая с нами, Вы платите только за результат, который Вас устраивает. Более подробную информацию Вы можете найти здесь

Для начала мы опишем термин «системная интеграция», приведем различные определения. Затем рассмотрим его структуру с точки зрения видов работ, выполняемых в рамках системной интеграции: технический аспект, управленческий аспект и др. И, наконец, подробно остановимся на техническом аспекте – опишем виды, технологии системной интеграции, специализированные программные продукты.

Определение системной интеграции

Понятия «системная интеграция» и «системный интегратор» весьма емкие, под которые часто попадают виды деятельности и компании, которые не являются таковыми в классическом определении этих терминов.

Например:

• Системный интегратор <> Крупная многопрофильная ИТ-компания
  
• Системная интеграция <> Поставка и внедрение технологических решений определенного вендора (например, Cisco или Microsoft)
  
• Системная интеграция <> Комплексные проекты по созданию сетевой инфраструктуры компании (для этого существует термин «сетевая интеграция»)
  

При этом суть понятия «системная интеграция», в принципе, очевидна из самого термина – интеграция систем, т.е. выстраивание единого решения (системы) из отдельных компонентов (подсистем), увязывание между собой этих компонентов с целью придачи этой единой системе эмерджентных свойств – дополнительных преимуществ, получаемых за счет совместного использования подсистем, отсутствующих у каждой из подсистем в отдельности.

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

Общим случаем системы, в рамках которой происходит интеграция подсистем, является единая информационная система компании (КИС, корпоративная информационная система). Подсистемами при этом являются:

• Сетевая инфраструктура, которая в свою очередь состоит из более мелких подсистем, также интегрированных друг с другом: телекоммуникационное оборудование, серверное оборудование, рабочие станции и др.
  
• Информационные системы, используемые в компании: ERP, CRM, BPM и др. Очевидно, что они должны быть также интегрированы между собой и подсистемами сетевой инфраструктуры. Например, можно существенно сократить трудозатраты оператора Call-центра, интегрировав телекоммуникационное оборудование Call-центра с CRM-системой путем передачи в CRM номера вызывающего абонента и автоматического отображения на экране оператора карточки этого абонента по сравнению с приемом вызова на обычный телефон и поиск карточки абонента вручную.
  
• Системы управления технологическими процессами.
  
• Прочие ИТ-компоненты.
  

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

Полноценная системная интеграция является существенно более сложной деятельностью, чем внедрение отдельных систем и решений, т.к. отдельное решение направлено на решение ограниченного числа конкретных бизнес-задач. Например, внедрение CRM-системы обычно направлено на повышение лояльности клиентов компании. В то время как в рамках системной интеграции создается единая КИС, направленная на решение всего спектра бизнес-задач компании.

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

Не менее сложной задачей является технико-экономическое обоснование предлагаемых вариантов создания единой КИС.

Общее определение термина «системная интеграция».

Системная интеграция – объединение отдельных компонентов (подсистем) в одну систему и гарантия того, что подсистемы функционируют совместно как единая система. В информационных технологиях системная интеграция – процесс связывание между собой различных компьютерных систем и программных приложений физически или функционально при помощи специальных техник, таких как компьютерные сети, интеграция корпоративных приложений, управление бизнес-процессами, программирование и др. [http://en.wikipedia.org/wiki/System_integration]

Интересными являются определения этого термина самими компаниями системными интеграторами [http://www.miks.ru/search/25838.html]:

• СОЗДАНИЕ комплексных решений в области информационных технологий для корпоративных заказчиков (IBM);
  
• СОЗДАНИЕ сложных, взаимоувязанных законченных систем функционирования автоматизированных бизнес-процессов предприятия или организации, интегрирующих разнородные технологии и оборудование разных производителей («Ай-Теко»);
  
• Прежде всего ТВОРЧЕСТВО. Только компания, состоящая из передовых, высокообразованных технически, творческих людей, способных быстро и четко понять потребности заказчика и предложить ему наиболее выгодный вариант решения проблемы, достойна называться интегратором. С точки зрения специалистов, под интеграцией систем понимается проектирование и разработка некой информационной системы, объединяющей в функционально полное решение программные и аппаратные средства, позволяющие заказчику добиться максимально возможного взаимодействия и эффективности различных бизнес-процессов (UAFI-T);
  
• ВЫБОР экономически оправданного, интегрированного информационно-телекоммуникационного решения для реализации конкретных задач заказчика, его комплексная реализация и сопровождение в течение жизненного цикла системы («Информационная Индустрия»);
  
• РАБОТЫ по созданию и запуску в эксплуатацию необходимых клиенту систем (ПО или программно аппаратных комплексов), формируемых, как правило, из независимо разработанных компонентов, либо включаемых в состав уже функционирующих систем (ЛАНИТ);
  
• КОМПЛЕКС РАБОТ, предоставляющих заказчику системные (взаимосвязанные и законченные) решения в части технологий, транспортной среды и оборудования, обеспечивающие эффективный бизнес-процесс оператора («Контур-М»);
  
• РАЗРАБОТКА специализированных решений, включающих поставку аппаратной платформы и разработку ПО, а также интеграцию разработанного решения с другими бизнес-приложениями заказчика (Siemens);
  
• ИНТЕГРАЦИЯ различных аппаратных и программных средств в единые подсистемы, а также разработка, производство, монтаж, поддержка и обслуживание программно-аппаратных комплексов, предназначенных для решения определенных заказчиком задач (Computer Mechanics);
  
• ИСКУССТВО И НАУКА ИНТЕГРАЦИИ процессов, функций, людей и информационных технологий, позволяющей создать IT-систему, удовлетворяющую бизнес-требованиям конкретного предприятия; это умение объединить разрозненные системы заказчика («Энвижн Груп»);
  
• ДЕЯТЕЛЬНОСТЬ по решению бизнес- и/или технических задач заказчика с привлечением информационных технологий, направленная на повышение эффективности бизнеса заказчика, где результатом является изменение информационной и/или коммуникационной систем заказчика («Открытые Технологии»);
  
• ОДНО ИЗ НАПРАВЛЕНИЙ, наиболее востребованных в IT-бизнесе, когда интегратор готов взять на себя головную боль заказчика по интеграции в единое целое всех его систем, а также по расширению его сети, т.е. работы, которые из-за нехватки специфических инженерных ресурсов заказчик не в состоянии выполнить своими силами, в необходимые сроки и с гарантированным качеством («Эквант»);
  
• СПОСОБНОСТЬ обеспечить заказчиков всеми необходимыми механизмами для эффективного управления бизнесом. Сегодня большинство клиентов приходят со своей стратегией и просят помочь ее реализовать. Какими средствами – вопрос вторичный. (IBS).
  

Виды работ при системной интеграции

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

«Правильная» КИС, реально решающая бизнес-задачи заказчика, может быть построена только в том случае, если системный интегратор, реализующий данный проект:

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

Достаточно крупный интеграционный проект, как правило, включает в себя следующие аспекты (уровни работ) и требует наличия следующих компетенций:

• Технический аспект. В конечном счете системная интеграция – это создание или внедрение конкретных аппаратных и программных систем. Поэтому у интегратора должны быть следующие компетенции: Дифференциальные компетенции – экспертные знания в каждом из внедряемых в рамках интеграционного проекта продуктов. Например, конкретных ERP-систем, линеек серверного и телекоммуникационного оборудования. Интегральные компетенции – наличие экспертов понимающих работу и взаимодействие между различными классами систем, а также владеющими технологиями их связывания между собой.
  
• Управленческий аспект. В интеграционные проекты обычно вовлечены десятки сотрудников интегратора самого различного профиля. Для того, чтобы эта группа людей действовала эффективно в направлении достижений целей и задач проекта, как единая команда, а не как бесформенная масса, руководить ею должен квалифицированный менеджер проектов или несколько менеджеров, каждый из которых отвечает за определенную часть проекта (например, разработку ПО, создание центра обработки данных и т.п.), но все они подчиняются главному менеджеру всего проекта в целом. Кроме того, осложняющим моментом является то, что высококвалифицированные технические эксперты могут одновременно участвовать в нескольких проектах, поэтому их выделение должно также координироваться «надпроектной» частью руководства компании. Таким образом, системный интегратор должен обладать сильными компетенциями в области управления проектами.
  
• Консалтинговый аспект. Для успеха интеграционного проекта необходимо в самом начале правильно сформулировать его цели и задачи на основании бизнес-стратегии и текущей ситуации заказчика, а также предложить архитектуру создаваемой КИС и обосновать ее экономическую эффективность. Для этого недостаточно интегральных технических компетенций. Необходимо наличие у интегратора специалистов обладающих уникальным «сплавом» экономических и технических компетенций, способных построить «мостик» от бизнес-задач заказчика к конкретных технологическим решениям для их достижения.
  
• Коммерческий и политический аспекты. Естественно, интеграционный проект начнется и успешно завершится только в том случае, если он будет экономически целесообразен для самого интегратора. Поэтому в составе команды проекта должны быть участники, работающие с высшим руководством заказчика, обеспечивающие согласование и выделение бюджетов, урегулирование финансовых разногласий. Кроме того, крупные интеграционные проекты часто сталкиваются с «политическими» проблемами. Например, противодействием или лоббированием собственных интересов в ущерб целям проекта со стороны отдельных групп влияния заказчика. У интегратора должны быть компетенции в решении подобных проблем.
  

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

Общие подходы к интеграции систем

Интеграция систем в большинстве случаев – мера вынужденная, направленная на повышение эффективности бизнес-процессов компании, в которых используются информационные систем [http://citcity.ru/16663/]. Для того, чтобы продемонстрировать ценность интеграции информационных систем и наиболее распространенные подходы к интеграции рассмотрим последовательно несколько ситуаций.

Ситуация 1. Нет интеграции между системами

На схеме выше в компании используются три независимые информационные системы: «Складская система» (учет и анализ товародвижений на складе), «CRM-система» (учет и анализ продаж и других взаимоотношений с клиентами) и «Бухгалтерская система» (бухгалтерский учет и финансовый анализ). Между ними нет информационного обмена. Это приводит к тому, что менеджеры по продажам после выставления счетов клиентам вынуждены печатать их копии и нести в бухгалтерию. В бухгалтерии они регистрируются в бухгалтерской системе. Бухгалтерия регистрирует поступление денег на счет. Менеджеры по продажам, не имея возможность получить оплаты автоматически в CRM-систему вынуждены ежедневно осведомляться в бухгалтерии о поступлении денег от клиентов. Не лучше ситуация в работе склада. Здесь есть обширный документооборот с бухгалтерией, двойная регистрация действий (один раз в складской системе, второй раз в бухгалтерской) и менеджерами по продажам (получение от них распоряжений на отгрузку товара клиентам и информирование их о фактах отгрузки).

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

Ситуация 2. Вертикальная интеграция

На следующей схеме изображен подход, называемый «вертикальной интеграцией». В соответствии с этим подходом системы интегрируются по принципу функциональных экспертиз [2]. Например, в данном случае выделены две экспертизы: оперативный учет и бухгалтерской учет. При этом бухгалтерский учет находится по вертикали выше оперативного учета. В нашем примере подсистемы оперативного учета поставляют данные подсистеме бухгалтерского учета. Это позволяет существенно сократить трудозатраты на дублирующиеся и бумажные операции, однако, есть два отягчающих момента.

Во-первых, такую систему крайне трудно расширять функционально. Например, компания может захотеть создать подсистему-экспертизу «Аналитика», которая по вертикали будет расположена над экспертизой «Бухгалтерский учет». Эта экспертиза в значительной степени основана на данных «Оперативного учета». Поэтому, помимо собственно разработки подсистемы «Аналитика» придется дорабатывать подсистему «Бухгалтерский учет» для того, чтобы она получала и хранила для нее из «Оперативного учета» дополнительную информацию.

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

Ситуация 3. Интеграция «многие ко многим» (звезда, спагетти)

Интеграция «многие ко многим» не предполагает выделение слоев функциональных экспертиз. При этом подходе каждая из используемых в компании подсистем может при необходимости обращаться к функционалу любой другой подсистемы. С другой стороны каждая из подсистем может использоваться любой другой подсистемой. Такой тип отношений между элементами называется «многие ко многим». Также если подсистем немного, то схема отражающая связи между ними похожа на «звезду». А если систем много, то бесконечные их переплетения образуют «спагетти» [2].

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

Но, с другой стороны, затраты на поддержку такой интеграционной схемы экспоненциально растут при увеличении числа интегрированных подсистем. Например, если в нашем случае потребуется изменить что-то в бухгалтерской подсистеме (допустим, изменить ее объектную модель), то это может привести к необходимости переработки все остальных подсистем использующих ее, т.к. вызовы старой объектной модели перестанут работать. Для трех взаимодействующих систем это может быт не так критично, а вот для тридцати весьма и весьма.

Ситуация 4. Горизонтальная интеграция

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

Например, CRM-система при подключении к шине публикует свои функции по работе с клиентской базой данных. Шина обеспечивает возможность их использования бухгалтерской и складской системами. В свою очередь CRM-система получает возможность с бухгалтерскими и складскими данными.

Преимуществом данного подхода является то, что сами системы могут произвольно меняться в рамках существующей спецификации опубликованных функций. При этом никаких изменений в других системах не требуется. Кроме того, подключение новой системы в достаточной степени стандартизировано и упрощено. Например, имеется возможность подключить новую систему «Аналитика», которая сразу получит доступ ко всем остальным подсистемам.

Ситуация 5. Отсутствие необходимости в интеграции

Безусловно, самая лучшая интеграция – это отсутствие необходимости в ней. Например, все представленные выше подсистемы могут быть реализованы в виде функциональных модулей одной ERP-системы какого-либо вендора. В этом случае необходимость в интеграции отпадает, т.к. система уже изначально единая, обеспечивающая гораздо большую связность между функциональными модулями чем любой из приведенных выше вариантов интеграции между различными системами.

Объекты и методы интеграции систем

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

Обычно, информационная система содержит в себе следующие компоненты:

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

Поэтому, интеграция информационных систем заключается в интеграции одного или нескольких компонентов интегрируемых информационных систем (объектов интеграции):

• Интеграция платформ
  
• Интеграция данных
  
• Интеграция приложений
  
• Интеграция бизнес-процессов
  

Рассмотрим подробнее процесс и технологии интеграции на каждом из этих уровней.

Интеграция платформ

Целями интеграции платформ являются:

• Обеспечение возможности взаимодействия между приложениями, работающими на различных программно-аппаратных платформах (например, между приложениями, работающими на серверах Windows, Solaris, Linux и др.).
  
• Обеспечение возможности работы приложений, разработанных для одной программно-аппаратной платформы, на других программно-аппаратных платформах (например, приложений Windows на платформах Linux, Solaris и др.).
  

Существует несколько подходов, направленных на достижение этих целей. В рамках каждого из подходов существуют различные технологии [http://citcity.ru/10881/]:

• Удаленный вызов процедур (RPC, CORBA, DCOM, Web-сервисы)
  
• ПО промежуточного слоя (Microsoft.Net, Java Runtime)
  
• Виртуализация
  

Технологии удаленного вызова процедур (в широком смысле под процедурой понимается некоторая функциональность приложения) позволяют опубликовать процедуру и обеспечить возможность ее вызова (передачи входящих параметров и получения выходных результатов) для приложений, работающих на других платформах. Элементами таких технологий обычно являются: общий для всех платформ язык описания интерфейсов процедур (IDL, WSDL), «адаптер» (переходник) процедуры, который транслирует внешние вызовы во внутренние и передает результаты обратно (стабы) и менеджеры, отвечающие за доставку запросов и результатов между платформами в сети (брокеры). Примерами технологий удаленного вызова процедур являются: RPC, CORBA, DCOM, Web-сервисы.

Концепция программного обеспечения промежуточного слоя (framework, среда исполнения, виртуальная машина) состоит в разработке прикладного ПО не с использованием сервисов конкретной операционной системы (например, Windows API), а с использованием сервисов ПО промежуточного слоя. Разработчиками ПО промежуточного слоя создаются ее реализации под различные операционные системы, которые транслируют вызовы соответствующих функций фрэйворка в вызовы соответствующей операционной системы. Типичным примером является технология Java Runtime Environment. Приложения, разработанные для этой технологии работают на любых программно-аппаратных платформах (Windows, Linux и др.) без каких-либо доработок самих приложений. Аналогичные возможности предоставляет среда Microsoft .Net Framework.

Интересной и современной концепцией является «виртуализация». К интеграции платформ она имеет отношение постольку, поскольку позволяет существенно упростить использования различных платформ и, соответственно, использование систем, требующих для своего функционирования наличия конкретных платформ. Если без виртуализации возможно одновременное функционирование N операционных сред на N серверов, то применение технологий виртуализации позволяет обеспечить функционирование N операционных сред на M серверов. Если N > M – это позволяет сократить расходы на аппаратное обеспечение путем его более эффективного использования. Если N < M – это простой путь увеличения производительности систем. Например, виртуализация позволяет развернуть и одновременно использовать на одном физическом сервере несколько операционных систем: Windows, Linux и др. На каждом из таких «виртуальных» серверов могут быть развернуты соответствующие системы, которые будут доступны одновременно. Примеры технологий виртуализации: Microsoft Hyper-V, Virtuozzo.

Интеграция данных

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

Подходы к интеграции данных:

• Универсальный доступ к данным
  
• Хранилища данных
  

Технологии универсального доступа к данным позволяют обеспечить единообразный доступ к данным различных СУБД. Посредником для работы с конкретной СУБД в данном случае является драйвер для соответствующей СУБД. Например, один и тот же SQL-запрос на выборку данных «SELECT * FROM TTABLE» может быть использован на выборку данных из таблицы TTABLE, хранящейся в СУБД MS SQL Server, Oracle, IBM DB2 и др. Это позволяет абстрагироваться от специфики конкретных СУБД и легко осуществлять интеграцию данных, хранящихся в различных СУБД. Наиболее распространенные технологии этого класса: ODBC, JDBC.

Концепция хранилищ данных состоит в создании корпоративного хранилища данных. Хранилище данных – база данных, хранящая в себе данные, собираемые из баз данных различных информационных систем, для целей их дальнейшего анализа. Например, может быть создано единое хранилище данных компании, в которое собрана информация из бухгалтерской, оперативной системы, внешних систем партнеров компаний. Для создания хранилищ данных используются технологии (OLAP), отличные от технологий создания оперативных БД (OLTP). В основном это делается для повышения производительности выполнения сложных аналитических запросов по многим параметрам (многомерные запросы). Подходы к созданию и наполнению хранилищ данных отражены в парадигме ETL (extraction, transformation, loading = извлечение, преобразование и загрузка). Технологии и инструментальные средства анализа больших массивов данных с целью выявления закономерностей предметной области объединяются понятием «Data Mining». Термин для совокупности технологий хранилищ данных и инструментальных средств и – «Business Intelligence».

Интеграция приложений

Интеграция на уровне приложений подразумевает использование готовых функций приложений другими приложениями. Например, разрабатывая систему электронного документооборота, существует возможность использовать в рамках этой системы в качестве текстового редактора MS Word вместо того, чтобы разрабатывать свой собственный текстовый редактор. Или, например, ПО Call-центра, получив входящий звонок от клиента, имеет возможность обратиться к функции биллинговой системы по проверке баланса (на входе – номер телефона абонента, на выходе – его текущий баланс) и, в зависимости от состояния баланса соединить его с оператором или автоматически проинформировать о необходимости пополнить свой счет. При этом структура база данных биллинговой системы является ее внутренней информацией, публикуются конкретные функции, позволяющие другим системам работать с конкретными данными.

Стоит упомянуть следующие подходы к интеграции приложений:

• Интерфейсы прикладного программирования
  
• Обмен сообщениями (Корпоративная шина сервисов)
  
• Сервис-ориентированная архитектура
  
• Интеграция пользовательских интерфейсов
  

Интерфейс прикладного программирования конкретной системы представляет из себя «опубликованный» функционал этой системы, который может быть использован извне. Функционал может публиковаться в виде набора функций (пример – Windows API) или в виде объектной модели (объекты со свойствами и методами, пример – объектные модели приложений Microsoft Office) [4].

В большинстве случае интеграция нескольких систем заключается в передаче информации между ними, например, в форме запрос-ответ. Если системы функционируют в гетерогенных распределенных средах, то принципиальное значение имеет обеспечение гарантированности, безопасности, управляемости доставки информации между приложениями. Эти и другие принципы реализуются в корпоративных системах обмена сообщениями. В данном случае речь идет об обмене сообщениями между приложениями, а не людьми, как, например, в случае E-mail или ICQ. Функциональность этих систем достаточно прозрачна – прием сообщения от одного приложения, транспортировка по заданным правилам и передача этого сообщения другому приложению. При этом может производиться шифрование сообщений (для невозможности прочтения данных в процессе транспортировки), цифровая подпись (для защиты от умышленного изменения данных во время пути сообщения), настройка подписки (для отправки одного сообщения сразу нескольким приложениям), определение метаданных для сообщений (для облегчения использования сообщений со сложной структурой содержимого) и др [http://en.wikipedia.org/wiki/Enterprise_service_bus].

Сервис-ориентированная архитектура (SOA) является современной и модной парадигмой. Она является логическим продолжением концепции Web-сервисов, которая состоит в публикации функциональных блоков какого-либо приложения в виде, позволяющем получить к ним доступ другим приложением через Web. Web (протокол HTTP) в данном случае привлекателен ввиду возможности его использования и, соответственно, использования опубликованных в Web приложений на любых программно-аппаратных платформах. Web-сервис – небольшая программная надстройка над функционалом приложения, преобразующая вызовы, получаемы через Web во внутренние вызовы функций приложения и возвращающая результаты обратно. Основными идеями SOA являются [http://en.wikipedia.org/wiki/Service-oriented_architecture]:

• Публикация функционала корпоративных приложений в виде Web-сервисов. Упорядочивание опубликованных сервисов в виде каталога.
  
• Построение на основе Web-сервисов новых приложений путем их комбинации.
  

Понятно, что в данном случае создания новых приложений на основе существующих Web-сервисов будет существенно ниже, чем разработка приложений «с нуля» или обширная интеграция с другими системами.

Например, в компании (оператор связи) существует система Service Desk (техническая поддержка абонентов) и биллинговая система (тарификация услуг). Перед компанией стоит задача сделать новую систему «Личный кабинет абонента», в которой абонент мог бы через Интернет просмотреть состояние своего счета и сообщить о неисправности. Для этого компания вместо того, чтобы создавать «Личный кабинет» с собственной базой данных, синхронизируемой с БД биллинговой системы и системы Service Desk, использует готовые Web-сервисы «Карточка абонента» (опубликованный функционал биллинговой системы) и «Создать заявку в техподдержку» (опубликованный функционал системы Service Desk). Очевидно, что вся работа по новому приложению «Личный кабинет» состоит лишь в создании Web-интерфейса пользователя на сайте компании.

Также часто используется следующий подход – интеграция пользовательских интерфейсов. Например, для создания приложений «одного окна». Простейший пример – фреймы в вэб-странице. Внутри каждого фрэйма при этом содержится отдельное вэб-приложение. Благодаря фрэймам, все эти приложения отображаются на экране одновременно. Пользовательские интерфейсы вэб-приложений очень легко интегрируются, однако, существуют возможности интегрировать и «классические» пользовательские интерфейсы и их фрагменты (ActiveX).

Интеграция бизнес-процессов

Наиболее целостным подходом к интеграции систем является интеграции на уровне бизнес-процессов. В рамках интеграции бизнес-процессов происходит и интеграция приложений, и интеграция данных и, что не менее важно, людей, вовлеченных в этот бизнес-процесс. Интеграция на уровне бизнес-процессов является наиболее «естественной» для организаций, т.к. их деятельность состоит, прежде всего, именно из бизнес-процессов, а не приложений, баз данных и платформ.

Идеи, лежащие в основе интеграции бизнес-процессов, достаточно просты:

• Составить сценарий некоторого бизнес-процесса, происходящего в организации, описать в нем операции взаимодействия пользователей с различными системами и систем между собой. Таким образом, бизнес-процесс является элементом, логически интегрирующим различные системы. Сценарий создается при помощи специализированного программного продукта, который далее будет управлять ходом этого бизнес-процесса согласно сценарию.
  
• Операции взаимодействия с системами в рамках бизнес-процесса детально описываются в терминах информационного обмена: форматы обмена, используемые сервисы, приложения, события, правила, политики и т.п.
  
• К интегрирующему программному обеспечению, при помощи которого описан сценарий бизнес-процесса, подключаются посредством адаптеров интегрируемые системы, вовлеченные в бизнес-процесс. Таким образом, становится возможным автоматизированный информационный обмен между системами.
  
• Готовый к выполнению бизнес-процесс выводится на «пульт управления» менеджера, при помощи которого, он может запускать и останавливать бизнес-процессы, отслеживать их состояние, вводить данные и принимать решения на отдельных операциях бизнес-процессов, требующих участия человека и др. Взаимодействия между системами, не требующее участия человека осуществляется автоматически интегрирующим ПО.
  

Некоторые примеры интегрирующего ПО рассмотрены ниже.

Программные продукты для интеграции систем

Существует большое количество программных продуктов для интеграции систем: коммерческий и бесплатных, с закрытыми исходниками и Open Source, дорогих и дешевых, с различной функциональностью, рассчитанных на различный масштаб бизнеса пользователей.

Можно выделить следующие классы продуктов для интеграции систем:

• Реализующие идеологию SOA
  
• Реализующие идеологию Messaging (промежуточное ПО)
  
• Корпоративные шины сервисов
  
• Средства интеграции на уровне бизнес-процессов (BPEL, Business Process Execution Language)
  
• Средства интеграции данных
  
• Прочие…
  

Серьезные продукты для интеграции корпоративных приложений от солидных вендоров включают в себя компоненты сразу нескольких классов из перечисленных выше. В настоящей работе мы ограничимся продуктами от трех вендоров: Microsoft, Oracle и IBM.

Microsoft BizTalk Server

BizTalk Server представляет собой программный продукт для интеграции приложений и бизнес-процессов. На схеме ниже показана архитектура BizTalk Server, основанная на идеологии обмена сообщениями между приложениями.

Центральной частью системы является механизм обмена сообщениями (Engine), который состоит из двух частей:

• Messaging – транспортный уровень (прием, хранение и отправка сообщений между приложениями), подключение к обмену различных систем, функционирующих на различных платформах, использование учетных записей для подключения к системам и др.
  
• Orchestration – правила (логика) обработки сообщений. Например, при помощи визуального дизайнера можно определить алгоритм, в соответствии с которым, получив сообщение от POS-терминала о продаже конкретному клиенту необходимо создать сообщение для CRM-системы и бухгалтерской системы с целью дальнейшей обработки факта продажи.
  

«Надстройки» над BizTalk Server Engine (Business Activity Monitoring и Services) предоставляют возможности управления бизнес-процессами в организации на основании информации, собираемой в процессе «общения» интегрированных приложений.

Реализованная в продукте идея заключается в регистрации некоторой необходимой информации (Tracking, задается при настройке правил обработки сообщений в Engine) для целей дальнейшего мониторинга бизнес-процессов. Например, можно описать бизнес-процесс продажи, включающий несколько стадий (заказ, оплата, отгрузка и т.п.). Далее при получении сообщения от соответствующей системы (POS, бухгалтерия, склад и т.п.), отражающего факт изменения стадии конкретной продажи, это регистрируется и становится доступным для просмотра текущего состояния и анализа исторических данных.

Также следует отметить, что Microsoft BizTalk Server позиционируется вендором как продукт для B2B-интеграции. Это означает, что интегрируемые бизнес-процессы и приложения не обязательно должны находиться в рамках одной компании, а могут затрагивать несколько взаимодействующих компании, например, в цепочке поставок. В этом случае каждая такая компания использует Microsoft BizTalk Server для интеграции внутренних процессов и приложений и взаимодействует с BizTalk-серверами других компаний для внешнего обмена [http://www.microsoft.com/rus/biztalk/].

Microsoft SQL Server

Общеизвестная СУБД Microsoft SQL Server является также примером платформы для интеграции данных. Функции интеграции реализуются в MS SQL Server следующими компонентами: Integration Services и Analysis Services.

Integration Services является ETL-инструментом, позволяющим [http://www.microsoft.com/sqlserver/2008/ru/ru/default.aspx]:

• Собрать данные из различных источников (например, реляционных БД, текстовых файлов, RSS-каналов в Интернете, вэб-сервисов и др.).
  
• Преобразовать их из исходных форматов в необходимые с использованием промежуточных хранилищ или без них. Правила преобразование и консолидации задаются разработчиками хранилища.
  
• Поместить результат в информационное хранилище, в котором они становятся доступными потребителям интегрированной информации.
  

Analysis Services поддерживает процесс интеграции данных на следующих этапах, а именно [8]:

• Создание OLAP-хранилищ, в которое стекаются данные из различных источников в процессе интеграции, и хранение многомерных данных.
  
• Обеспечение доступа к OLAP-данным, выполнения многомерных запросов. Типичный пример – работа с данными при помощи Pivot Table.
  
• Интеллектуальный автоматизированный анализ данных (Data Mining). Простейший пример – имея таблицу с данными наблюдений за пациентами со следующими полями: диагноз, симптом 1 (температура), симптом 2 (головная боль), … существует возможность построить «дерево решений», при помощи которого врач по наблюдаемым симптомам у больного сможет с определенной вероятностью поставить ему диагноз.
  

Oracle SOA Suite

Данный продукт от Oracle похож по своей функциональности на BizTalk сервер от Microsoft. Он разработан на технологиях Java, поэтому может работать на различных платформах (Windows, Solaris, HP-UX, Linux).

Также, в отличие от BizTalk Server Oracle SOA Suite представляет из себя не один программный продукт, а набор относительно программных компонентов, некоторые из которых могут использоваться по отдельности [http://www.oracle.com/global/ru/ip/10g/as/bpel.html]:

• Oracle BPEL Process Manager – средство создания (при помощи визуального дизайнера), «хостинга» и управления бизнес-процессами, включающими в себя взаимодействие между людьми и интегрируемыми ИТ-приложениями.
  
• Oracle Business Activity Monitoring – панель управления (dashboard) интегрированными бизнес-процесами. Позволяет просматривать различные показатели бизнес-процессов (например, KPI), сервисов и их компонентов в «одном окне».
  
• Oracle Business Rules – средство описания бизнес-правил и политик, используемых в интегрированных бизнес-процессах.
  
• Oracle Service Bus – «транспортный уровень», корпоративная шина сервисов (ESB), обеспечивает взаимодействия между различными приложениями в организации.
  
• Oracle Web Services Manager – инструмент централизованного доступа к вэб-сервисам, существующим в организации, обеспечивающий создание учетных записей и политик для приложений, использующих администруемые вэб-сервисы.
  
• Oracle JDeveloper – среда разработки на Java от Oracle.
  
• Connectivity – набор адаптеров (более 300) для подключения к различным программным продуктам и технологиям, используемым в организации.
  

Oracle SOA Suite входит в состав продуктов middleware, для которых вендор использует обобщающее название Oracle Fusion.

IBM WebSphere

IBM WebSphere – это middleware от IBM, аналог Oracle Fusion. В составе IBM WebSphere есть продукты, обеспечивающие интеграцию систем в парадигме SOA (по аналогии с Oracle SOA Suite). Состав и функционал продуктов похож на аналогичное ПО других вендоров [http://www.ibm.com/products/ru/ru/]:

• WebSphere Business Modeler – средство визуального описания интегрирующих бизнес-процессов.
  
• WebSphere Process Server – хостинг и исполнение бизнес-процессов.
  
• WebSphere Integration Developer – среда разработки сервисных компонентов.
  
• WebSphere Business Monitor – инструмент мониторинга бизнес-процессов
  
• WebSphere Enterprise Service Bus – система, обеспечивающая взаимодействие между сервисами, реализованным в компании в рамках SOA.
  
• WebSphere MQ – система обмена сообщениями между приложениями, в т.ч. в рамках SOA.
  
• Другие продукты…