Особенности работы аналитика в интеграционных проектах

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

Специфика формирования требований

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

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

Внимание на анализ потоков При проектировании интеграционного решения прежде всего необходимо учитывать разнообразие информационных потоков в компании – акцент в подобных проектах идет именно на движение данных. Среди потоков могут встречаться:

 

• линейные: один источник данных (ИД) и один приемник данных (ПД);
• разветвленные: один ИД и более одного ПД;
• консолидируемые: более одного ИД и один ПД;
• сложные: более одного ИД и более одного ПД;
• трансформируемые – простые, разветвленные, консолидируемые и сложные информационные потоки, подразумевающие трансформацию данных в процессе транспортировки.

 

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

 

В процессе исследования и описания информационных потоков незаменимым подспорьем являются реально передаваемые данные. Учет всех важных аспектов, таких как логические связи между транспортируемыми информационными сущностями, конкретный состав данных и структура БД, позволяет избежать логических разрывов – в процессе формирования последовательности в потоке не передать «потомков после предков».

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

• скорости информационного обмена;
• контролируемости процесса транспортировки данных;
• ролям/правам доступа администраторов и операторов интеграционной платформы;
• шифрованию как всех, так и отдельных информационных потоков;
• шифрованию всей интеграционной БД и отдельных массивов данных;
• отказоустойчивости интеграционного решения и восстановлению данных при сбоях.

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

Что выбрать?

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

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

Вопросы коммуникации

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

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

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

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

Любой успешный ИТ-проект предполагает плотное взаимодействие аналитика со специалистами компании, поскольку без этого условия сформулировать качественные требования практически невозможно

Уходя – регламентируй

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

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