Подписаться
Читать в телеграм
Для начала отметим, что целью интеграционных проектов является не организация передачи данных между несколькими системами, как иногда полагают. На самом деле нужно достичь оптимальной автоматизации бизнес-процессов, в ходе которых требуется осуществлять передачу данных. И это концептуальное расхождение может привести не только к увеличению сроков интеграционного проекта, но и к его полному краху. Заказчик, думая, что стоящая перед ним задача локальна, сам, без обследования определяет потоки для интеграции, а интегратору остается связать их, никак не привлекая для этого специалистов компании. Но в подходе «вот список потоков – интегрируйте» есть огромный риск: после интеграции могут быть выявлены недостающие потоки, которые блокируют автоматизацию бизнес-процессов. В этой статье мы описываем возможные проблемы, возникающие в ходе проектов, вместе с рецептами их решения.
Проблема № 1. Я не я и корова не моя, или Проблемы взаимодействия
Интеграционные проекты далеко не всегда включают в себя интеграцию 2 систем, как зачастую предполагается изначально, чаще всего «подружить» необходимо от 3 до 5 систем. В этом случае 90% риска смещения сроков обусловлены просрочкой согласования необходимых работ. Растет количество участников проекта со стороны заказчика, при этом не все из них понимают важность взаимодействия с интеграционной командой, ответственно подходят к процессу и т.д.;
Проблема № 2. «Тише едешь – дальше будешь» не всегда работает
Еще один фактор, который с течением времени может сильно «раздуть» сроки проекта, – рассинхронизация действий всех его участников, в первую очередь компаний-исполнителей. Например, система, которую требуется «подружить» со смежным приложением, на начало работ по интеграции еще не внедрена и не окончательно задокументирована в части требований и процессов.
Интеграционный поток – это набор данных, передаваемых от системы-источника в систему-приемник с использованием интерфейса интеграционной шины. В рамках интеграционного потока возможно несколько взаимодействий между системой-источником, шиной и системой-приемником.
Сложность потока определяется атрибутным составом передаваемых данных и числом смежных вызовов:
- средняя сложность – один сервис на выходе, не более 50 атрибутов данных;
- сложный – 1–3 сервиса на выходе, более 50 атрибутов данных;
- повышенная сложность – более 3 сервисов на выходе.
Решение
У этих 2 проблем общее решение. Необходимо прописать хотя бы высокоуровневый регламент взаимодействий, где будет четко определена последовательность действий на всех этапах проекта, подготовить выходные документы, согласующие число участников и сроки согласования/выдачи замечаний. Это позволит снизить риски ошибок и вероятность дальнейших разбирательств по поводу того, на чьей же стороне мяч, кто именно несет ответственность в случае неактуальности документов, описывающих системы, или неразработанных требований.
Далее мы рассмотрим «собирательный образ» интеграционного проекта в российском банке средней величины, созданный на основе нашего опыта. Предположим, что нам нужно «подружить» фронт- и бэк-офисную системы.
Проблема № 3. Цыплят по осени считают
Изначально банк «заявляет» в проекте около 3 десятков интеграционных потоков. Основные процессы, которые необходимо автоматизировать, – создание и ведение клиента, создание кредитного договора и последующее обслуживание заемщика.
После обследования бизнес-процессов число потоков возрастает более чем в полтора раза. Они «размножились» в том числе за счет того, что фронтовая система не «считает» ряд потоков общими для части банковских продуктов (кредитный договор, кредитная линия и т.д.), как предполагалось изначально. Для нее на каждый подобный продукт идет один, отдельный поток.
При этом 5 из указанных банком потоков – создание кредитной заявки в бэк-офисе, перевод кредитной заявки в кредитный договор и т.д. – исключаются из проекта, так как заявки в бэк-офисной системе не хранятся, в ней сразу после утверждения заявки во фронтовой системе создается кредитный договор.
Решение
Без предварительного обследования и описания бизнес-процессов точно не обойтись, даже если банк уверен в том, что «знает, что интегрирует». При обследовании определяется скоуп интеграционных потоков, выявляются их последовательность, приоритетность реализации, может быть установлена необходимость доработки систем.
Проблема № 4. Тили-тили тесто, или Несовместимость систем
Даже подробное описание бизнес-процессов не может гарантировать отсутствие ошибок в логике реализации интеграционных потоков. При определении потоков и их атрибутов можно столкнуться с несовместимостью смежных систем в части логики их работы. Возвращаемся к нашему примеру с фронт- и бэк-офисной системой.
В рамках процесса «создание кредитного договора» мы определяем 2 интеграционных потока для создания дополнительного договора страхования: 1-й – создание страхового договора, 2-й – его привязка к кредитному договору. Соответственно, для этих потоков во фронтовой системе реализованы 2 разных метода: 1-й – для запуска создания договора в бэк-офисной системе, 2-й – для его привязки к кредитному договору.
Но выясняется, что логика работы бэк-офисной системы не допускает создание договора страхования без одновременного определения кредитного договора, дополнительно кредитный договор может относиться к общему договору страхования.
Таким образом, поток для создания договора страхования должен быть один, а метод его создания должен включать в себя «подтягивание» данных по кредитному договору, к которому выполняется привязка. Понятно, что существующими во фронтовой системе методами реализовать данный поток не получится.
Решение
Для того чтобы выявить эту ситуацию до начала разработки и не сорвать сроки проекта, для каждого интеграционного потока необходимо смоделировать схемы потоков данных. Это позволит выявить альтернативные сценарии при различном поведении смежных систем, а также необходимые доработки интегрируемых бизнес-приложений. Для разработки схем потоков данных можно использовать диаграммы последовательности нотации UML.
Проблема № 5. У разбитого корыта?
За время проведения обследования и описания всех схем потоков могут измениться требования заказчика как к интеграционному процессу, так и к смежным системам. Не исключено, что нужно будет пересмотреть скоуп потоков.
Решение
В этом случае нужно выполнить сопоставление всех, в том числе появившихся по ходу проекта, интеграционных потоков и требований к доработкам в первоначально указанных бизнес-процессах для выявления возможных несоответствий и пробелов. После их устранения возможно изменение приоритета доработок.
Проблема № 6. Бонни и Клайд, или Несовместимость систем 2
Логично, что у совершенно разных систем могут не совпадать сущности и атрибутный состав. Так, в нашем гипотетическом проекте при создании кредитного договора требуется передача данных об ответственном лице, а также о способе привлечения клиента, которая не поддерживается в системе-источнике.
Если в банке отсутствует единая система для централизованного ведения нормативно-справочной информации (НСИ), ее роль зачастую берет на себя интеграционное решение.
Решение
Такие проблемы можно выявить только при определении передаваемых сущностей, их типов и преобразований. Целесообразно на ранней стадии проекта разработать полноценные спецификации для каждого интеграционного потока, выявить логику и зависимость атрибутов, отдельно описать сервисы, используемые в потоках для интеграции. Тогда информация о том, что покрытие требуемых атрибутов неполное и необходима дополнительная доработка смежных систем, не станет серьезным камнем преткновения на проекте.
Проблема № 7. Делу время, а потехе час, или Календарный план
Итак, у нас есть полное описание бизнес-процессов, спецификации всех потоков и масса другой очень важной информации, пришло время непосредственной реализации интеграционного решения. Но перед тем как приступать к разработке, важно не упустить все изменения, внесенные в первоначальный скоуп.
Возвращаемся к нашему проекту: при обследовании бизнес-процессов были выявлены 5 интеграционных потоков, инициаторами которых являлась бэк-офисная система. Первый относился к процессу «создание кредитного договора», а остальные – к «обслуживанию заемщика». Реализация потоков требовала доработки бэк-офисного приложения, таким образом, на начальных стадиях проекта было определено, что у первого потока приоритет выше, чем у остальных. После описания спецификаций всех 5 потоков выяснилось, что они имеют общую структуру и могут быть реализованы как единый сервис на стороне бэк-офиса. Это привело к объединению этих доработок и повышению их приоритетности.
Кроме проблемы, связанной с отсутствием общей картины, нельзя забывать о вопросе тестирования интеграционных решений. Поскольку на тестирование «завязаны» все участники проекта, их действия должны быть четко синхронизированы.
Решение
Для того чтобы реализация проекта соответствовала всем ожиданиям, необходимо выполнить итоговое review всех выявленных потоков, таким образом сформировав общую картину. Это позволит подготовить календарный план разработки и тестирования. В нем необходимо зафиксировать конкретные даты выполнения доработок, разработки потоков и тестирования, а также всех участников процесса. В дальнейшем в плане будет отмечаться статус разработки и тестирования.
Совершенно очевидно, что проблемы могут возникнуть на любом этапе реализации интеграционного проекта. Надеемся, что описанные нами «рецепты» проведения интеграции помогут вам их избежать.
