Подписаться
Читать в телеграм
Не так страшен черт, как его малюют, а вот эдак...
Современная народная мудрость
Во-первых, не все потоки могут быть учтены при сборе требований. Если количество интегрируемых систем и, соответственно, потоков достаточно велико, не удивительно, что некоторые из них могут выпасть из рассмотрения. Это особенно актуально, если интеграция проходит одновременно с внедрением новых систем. В данном случае возникает дополнительный риск: этапы внедрения могут не совпадать со стадиями интеграции. Другими словами, вероятна ситуация, когда к плановому сроку реализации определенного интеграционного потока его система-источник (или приемник) не будет готова к интеграции, и наоборот. Во-вторых, данные в интегрируемых потоках могут оказаться не синхронизированными. Наиболее частыми проблемами, по нашему опыту, являются несовпадение состава атрибутов и коллизии на уровне справочных данных.
Всех этих проблем и рисков можно избежать, если в основу проектирования интеграционного решения закладывать не информационные потоки, а бизнес-процессы, в рамках которых эти потоки существуют. В своих проектах мы используем разработанную нашими аналитиками и архитекторами методику, основанную на процессном подходе. Согласно ей проектирование интеграционного решения можно разбить на 6 основных шагов.
Распространенное мнение о том, что главная задача интегратора – «подружить» интегрируемые системы, к сожалению, ошибочно
Шаг 1. Описание бизнес-процессов
Это, без преувеличения, насущная необходимость, без которой проект не состоится – пазл не сложится. Допустим, мы строим интеграционное решение для автоматизации процесса оформления договора добровольного страхования. Процесс состоит из последовательности бизнес-операций, которые зачастую выполняются в различных информационных системах. Если рассматривать интеграционное решение как реализацию набора взаимодействий между приложениями, проект может оказаться неуспешным, даже если все взаимодействия будут отрабатывать корректно. Дело в том, что для подобного розничного бизнеса очень важным является время обслуживания клиента. Конкуренция достаточно велика, и если клиенту приходится долго ждать, пока менеджер в своих системах справится с оформлением договора, он может просто встать и уйти к другому страховщику. А учесть общее время оформления договора можно, только рассматривая процесс целиком, а не в рамках отдельных интеграционных взаимодействий.
Итак, первый шаг предполагает выделение бизнес-процессов, существующих в компании и подлежащих автоматизации. Затем выполняется описание процессов с точки зрения «to-be»: не так, как они организованы сейчас, а как они должны быть выстроены и, соответственно, автоматизированы. При этом мы учитываем не только пожелания компании, но и собственную экспертизу, а также известный отечественный и мировой опыт. В результате появляются схемы бизнес-процессов, а также их характеристики и метрики, формируется оптимальный порядок реализации проекта. Важность последнего пункта мы поясним на примере.
Мы выполняли проект в кредитной организации, его целью был перенос всех интеграционных взаимодействий между основными бизнес-системами на новую платформу. Было принято решение разбить весь объем работ на 4 итерации, к каждой были отнесены определенные интеграционные потоки. Изначально приоритетность реализации потоков определял сам заказчик. В первую итерацию были отнесены те из них, которые отвечают за процесс выдачи кредитов новым клиентам. Срочность реализации обусловливалась желанием бизнеса успеть завершить внедрение к «горячему сезону», когда ожидался всплеск активности клиентов. Но в результате выполненного нами экспресс-обследования выяснилось, что до 70% прибыли составляют кредиты, выданные лояльным клиентам, имеющим хорошую кредитную историю и уже имеющим договоры с компанией. В то же время функциональности, отвечающей за формирование предложений именно им, не было уделено достаточно внимания. Этот функционал был отнесен на 4-ю, заключительную итерацию, и не мог быть реализован к началу «горячего сезона». Совместно с компанией мы внесли корректировки в план реализации проекта.
Рис. 1. Пример схемы функциональной архитектуры
Шаг 2. Описание функциональной архитектуры
Задача этого этапа – описать автоматизируемую деятельность компании в терминах функциональности используемых систем: распределение бизнес-операций по приложениям, выявление информационных потоков. В результате формируется архитектурная схема потоков данных, пока без детализации до типов информации и методов информационного обмена.
Шаг 3. Проверка полноты покрытия
Далее идет сопоставление описания бизнес-процессов, сформированного на шаге 1, и функциональной структуры, подготовленной на шаге 2. Основная задача – выявить несоответствия, которые в дальнейшем не позволят построить корректное и эффективное решение. Они могут быть самыми разными. Например, может быть упущен какой-либо поток, что означает наличие «дыры» между бизнес-операциями. Другой наиболее частый тип несоответствия – это различия в составе данных, передаваемых системой-источником и принимаемых системой-приемником.
Здесь стоит вспомнить наш проект по автоматизации процессов розничного кредитования. В кредитной компании была принята достаточно стандартная схема организации данных: клиентская информация велась в CRM, а данные кредитного договора – в АБС, при этом в структуре данных договора была предусмотрена ссылка на данные клиента в CRM. Схема выглядит логичной, если не принимать во внимание тот факт, что клиентская информация может меняться. Поскольку отдельное хранение «слепка договора» не было предусмотрено ни в одной системе, при изменении клиентских данных бизнес-пользователи теряли возможность просматривать договор на момент его создания.
Для фиксирования результатов проверки полноты покрытия мы обычно используем матрицу покрытия (ее пример – табл. 1). В результате уточняются требования к организации интеграционного обмена, а также формируются рекомендации по доработке систем-источников и приемников данных.
Табл. 1. Матрица покрытия бизнес-процессов функциональной архитектурой
Шаг 4. Детализация потоков данных
По каждому выделенному и описанному ранее потоку определяются передаваемые сущности и атрибуты. Их совокупность определяет модель данных интеграционного решения. На этом же шаге формируются требования к ведению нормативно-справочной информации (НСИ). В зависимости от наличия в компании системы управления НСИ уровень сложности этой работы может меняться. В любом случае проектирование всех потоков, в рамках которых выполняется обмен справочными данными, должно выполняться в соответствии с существующей в компании концепцией внедрения единой системы НСИ. К сожалению, далеко не во всех организациях, с которыми мы работаем, такая система в принципе существует. В таком случае построение системы управления НСИ может являться частью интеграционного проекта (подробнее об этом мы говорим в статье «Когда НСИ становится проблемой» на стр. 20).
Шаг 5. Формирование требований к информационному обмену
На этом этапе описываются требования к интеграционным компонентам системы, формируются и согласуются регламенты и форматы взаимодействия с каждым бизнес-приложением. Если интегрируются системы, поставляемые разными компаниями, такое согласование может быть достаточно трудоемким. Поскольку зачастую возможны несколько вариантов реализации того или иного потока, это может вызвать споры и разногласия между «поставщиками». Здесь интегратор берет на себя роль рефери, определяющего оптимальный вариант и координирующего процесс согласования.
Необходимо осознавать всю важность этого шага – совместно с рекомендациями, определенными на шаге 3, эти требования определяют трудоемкость доработки систем. «Поставщики» систем оценивают сроки и стоимость доработок, необходимых для реализации интеграционных потоков, полученные выкладки используются для работы на заключительном, 6-м, шаге проектирования.
Шаг 6. Формирование календарного плана интеграции
Очень важным источником информации для формирования плана являются данные о приоритетности интеграционных потоков, определенных совместно с бизнес-заказчиками на шаге 1.
На основании оценок реализации собственно интеграционных компонент, а также сроков доработок систем-источников и приемников формируются и согласуются требования к срокам внедрения доработанных систем. Составляется календарный план проекта, включающий все стадии, в том числе общее тестирование интеграционного решения.
Бизнес может полагать, что основная задача интеграции – это реализовать корректную передачу данных из одной системы в другую и обратно, а сложность проекта зависит от количества интегрируемых систем и интеграционных потоков. Но, к сожалению, такой подход зачастую влечет за собой множество проблем и рисков и может даже привести к провалу проекта
Итак, распространенное мнение о том, что главная задача интегратора – «подружить» интегрируемые системы, к сожалению, ошибочно. На самом деле правильный посыл проекта – автоматизировать бизнес-процессы, отдельные функции которых выполняются в разных системах. Проблемы возникают, если на начальной стадии проекта упустить из виду процессы, фокусируясь на единичных потоках. В результате такого подхода к внедрению сквозные процессы просто не заработают. Кроме того, ошибки в проектировании интеграционных потоков приведут к необходимости незапланированных доработок систем-источников и/или приемников, а также к срыву сроков внедрения. Совершенно очевидно, что в любом случае бизнес потеряет деньги. Описанная нами методика позволяет избежать всех этих проблем: интеграционные проекты будут завершаться в срок и с ожидаемыми результатами.
