ИТ-интеграция – миссия выполнима

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

Кроме того, на решение задачи интеграции оказывают влияние следующие факторы:

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

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

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

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

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

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

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

MDM

Практически в любой компании, независимо от рода ее деятельности, ведется учет информации о контрагентах, с которыми она взаимодействует, о товарах или услугах, которые она реализует, о контрактах, в рамках которых эти товары или услуги поставляются или закупаются. Представим, что это большая и территориально распределенная организация. Как правило, это означает наличие «зоопарка» ИТ-систем, различающихся в головном офисе и территориальных отделениях. В эти различные ИС сотрудники добросовестно заносят данные о клиентах компании. Однако одного и того же клиента могут внести в CRM, ERP и прочие учетные системы столько раз, сколько этих бизнес-приложений, собственно, насчитывается в организации. При этом оператор, вносящий информацию о новом клиенте, например, об «ООО Розмарин», в свою систему, зачастую может даже не знать о том, что его сосед по кабинету сделал то же самое, но в своем приложении. С одной оговоркой – у него новый клиент называется «Торговый дом Розмарин» или даже «Rozmarin Trade». Введенная таким образом информация будет успешно храниться в системах, обрабатываться и дополняться до тех пор, пока руководство не захочет получить консолидированную отчетность по клиенту «Розмарин». Похожая ситуация возникает, когда в разных филиалах торговой организации, имеющих один и тот же ассортимент продукции, номенклатура ведется в локальных системах и, разумеется, по-разному. Представьте себе, сколько возможных вариантов названий может быть, к примеру, у товара «кашпо декоративное керамическое “Весна”». А теперь представьте, как будет выглядеть ответ на запрос от коммерческого отдела: «Каков объем поставки кашпо “Весна” клиенту «Розмарин»?».

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

Описанная задача является всего лишь одним из частных случаев применения систем класса MDM (Master Data Management) (подробнее – в статье «Мастерское управление данными», стр. 24). В действительности такие решения отвечают за огромный спектр задач, связанных с управлением основными данными, которые также часто называют эталонными данными или нормативно-справочной информацией (НСИ). Внедрение таких систем позволяет не только эффективно организовать процессы управления ими, обеспечив их актуальность и непротиворечивость, но и повысить качество данных, например, используя технологии их очистки (так называемое Data Quality). Используя определенные модели данных и алгоритмы их обработки, такие решения позволяют автоматически устранять определенные некорректности в данных, образовавшиеся, например, вследствие ошибок оператора. Вернемся к примеру с «Розмарином» и кашпо: возможным решением здесь могла бы стать так называемая дедупликация, которая также относится к классу задач Data Quality.

ETL

На сегодняшний день практически в любой организации возникает задача получения различного рода консолидированной отчетности, на основе которой умудренные опытом бизнес-аналитики делают выводы о текущих тенденциях бизнеса и принимают те или иные стратегические решения. Как правило, для получения подобного рода отчетности строятся громадные хранилища, в которые собираются данные из всех основных корпоративных ИС, будь то ERP, CRM или автоматизированная банковская система. Основой же для построения хранилищ практически всегда является система, которая, получая на вход данные в самых разных форматах, преобразовывает их в нужную форму и загружает в хранилище. И когда необходимо серьезное преобразование данных на их пути из одной системы в другую, на помощь приходит технология ETL (Extract, Transform, Load).

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

Пример: абонентам одного из телеком-операторов, являющимся обладателями карт лояльности, полагаются бонусные баллы за оплату тех или иных услуг, например, минут разговора, отправленных SMS и MMS, интернет-трафика и т.п. Количество типов таких услуг и соответствующих алгоритмов начисления баллов – несколько десятков. Количество абонентов, имеющих карты лояльности, – десятки, а то и сотни тысяч. Совершенно очевидна необходимость системы, которая в автоматическом режиме выгружала бы данные об абонентах и предоставленных им услугах, рассчитывала бы баллы, полагающиеся каждому, и передавала бы их в учетную систему программы лояльности.

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

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

ECM

Как уже говорилось ранее, интеграционные задачи возникают практически при любом внедрении бизнес-приложений, но есть классы систем, в основе которых изначально лежит интеграционное решение. Примером здесь могут быть платформы класса ECM (Enterprise Content Management), ориентированные на обработку большого количества документов и любой неструктурированной информации, вплоть до аудио- и видеофайлов, а также данных из интернет-источников (более подробно – во второй части, в 1 1, 2013). В основе такого решения лежит хранилище, в которое посредством интеграции помещается информация любого требуемого типа. Перечислим некоторые виды такой интеграции. Во-первых, это сбор электронных документов из бизнес-приложений – контрактов, приказов и распоряжений, ордеров и т.п. К этому же типу задач можно отнести сбор в единое корпоративное хранилище электронных писем, отправляемых или получаемых сотрудниками. Во-вторых, это помещение в хранилище оцифрованных бумажных документов. В этом случае необходима интеграция со средствами сканирования и распознавания. И третий пример – это сбор информации из открытых источников, например, интернета. Представим себе сотрудника отдела маркетинга, ответственного за процесс формирования имиджа компании в СМИ. Одной из его задач является сбор данных об упоминаемости компании в различных источниках, в первую очередь в интернете. Ее решение может быть построено на основе автоматического сбора, структурирования информации по различным признакам (темам, авторам, источникам и т.п.) и ее помещения в единое хранилище. Совершенно очевидно, что такое решение требует интеграции с интернет-источниками.

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

ESB

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

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

Итак, жизнь подтолкнула к появлению интеграционных шин, или ESB – Enterprise Service Bus. Теперь приложения получили возможность интегрироваться только с шиной и «не знать» о других системах. Как образно выразился один из наших заказчиков, «у нас появится шина, ощетинившаяся интерфейсами». Подробнее об интеграционных шинах и технических деталях их реализации читайте в статье «Дирижер в оркестре сервисов».

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

BPM

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

Технологии BPM (Business Process Management) позволяют сократить время выполнения бизнес-процессов за счёт регламентации и автоматизации шагов, введения временных ограничений и действий «по умолчанию». Соблюдение всех предусмотренных правил и повышение эффективности бизнес-процессов обеспечиваются за счет увеличения прозрачности этих процессов для всех их участников, регламентации и средств мониторинга.

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

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