Интегрировали, интегрировали, да не…

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

Распространенное мнение о том, что главная задача интегратора – «подружить» интегрируемые системы, к сожалению, ошибочно

Шаг 1. Описание бизнес-процессов

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

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

Мы выполняли проект в кредитной организации, его целью был перенос всех интеграционных взаимодействий между основными бизнес-системами на новую платформу. Было принято решение разбить весь объем работ на 4 итерации, к каждой были отнесены определенные интеграционные потоки. Изначально приоритетность реализации потоков определял сам заказчик. В первую итерацию были отнесены те из них, которые отвечают за процесс выдачи кредитов новым клиентам. Срочность реализации обусловливалась желанием бизнеса успеть завершить внедрение к «горячему сезону», когда ожидался всплеск активности клиентов. Но в результате выполненного нами экспресс-обследования выяснилось, что до 70% прибыли составляют кредиты, выданные лояльным клиентам, имеющим хорошую кредитную историю и уже имеющим договоры с компанией. В то же время функциональности, отвечающей за формирование предложений именно им, не было уделено достаточно внимания. Этот функционал был отнесен на 4-ю, заключительную итерацию, и не мог быть реализован к началу «горячего сезона». Совместно с компанией мы внесли корректировки в план реализации проекта.

Рис. 1. Пример схемы функциональной архитектуры

Шаг 2. Описание функциональной архитектуры

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

Шаг 3. Проверка полноты покрытия

Далее идет сопоставление описания бизнес-процессов, сформированного на шаге 1, и функциональной структуры, подготовленной на шаге 2. Основная задача – выявить несоответствия, которые в дальнейшем не позволят построить корректное и эффективное решение. Они могут быть самыми разными. Например, может быть упущен какой-либо поток, что означает наличие «дыры» между бизнес-операциями. Другой наиболее частый тип несоответствия – это различия в составе данных, передаваемых системой-источником и принимаемых системой-приемником.

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

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

Табл. 1. Матрица покрытия бизнес-процессов функциональной архитектурой

Шаг 4. Детализация потоков данных

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

Шаг 5. Формирование требований к информационному обмену

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

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

Шаг 6. Формирование календарного плана интеграции

Очень важным источником информации для формирования плана являются данные о приоритетности интеграционных потоков, определенных совместно с бизнес-заказчиками на шаге 1.

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

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

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