Постоянное совершенствование технологий и трансформация бизнес-задач непрерывно меняют картину практической деятельности в сфере информационной интеграции. О том, как именно данные процессы происходят, мы и беседовали за круглым столом.
Участники круглого стола:
Василий Анфиногентов
директор отделения автоматизации деловых процессов, компания ФОРС
Ольга Кузнецова
менеджер по продажам, компания Tieto
Павел Романченко
заместитель начальника отдела разработки, компания «Инфосистемы Джет»
Михаил Заборов
заместитель генерального директора по стратегическим проектам, группа компаний Custis
Антон Левиков
ИТ-директор, группа компаний «Новард»
Андрей Давыдов
руководитель департамента информационных технологий, AIG
Intelligent Enterprise: Какие основные предпосылки сегодня оказывают наибольшее влияние на интеграцию информационных систем заказчика и какие тенденции сопутствуют развитию интеграционных процессов на практике? Насколько все это связано с сервисным подходом?
Василий Анфиногентов: Управление бизнесом в принципе требует интеграции. По крайней мере если используется более чем одно приложение. Драйвером интеграционных проектов часто выступает желание получать дополнительную отчетность. Это легко решается интеграцией данных. Такая задача возникает и в том случае, когда компания начинает стремиться к эффективности и борьба идет уже за считанные проценты. Отдельная тема, если возникает задача объединить данные из MES- и ERP‑систем. Сервисный подход является стандартом. Не далее как вчера мы обсуждали с коллегами один проект, и было решено использовать сервисный подход, хотя можно было бы обойтись простым решением класса «точка — точка». Такой выбор объясняется тем, что в дальнейшем это позволит предотвратить многие другие проблемы. Но сервисный подход следует применять с умом. Мне не раз приходилось слышать вопрос: «Мы написали тысячу сервисов, и что нам теперь с ними делать?» — и это не преувеличение. Помимо сервисного подхода существует множество других, и каждый из них хорош для решения определенного класса задач и совершенно не годится для других.
Павел Романченко: Проблема состоит в том, что делать что‑то с нуля приходится редко. А у реальных заказчиков все красиво бывает только на бумаге, а на практике состыковать разные системы крайне сложно. И при этом задача интеграции возникает, когда системы перестают справляться с нагрузкой.
Вот поэтому в интеграционных проектах сервисная архитектура является абсолютным добром. Наши заказчики сталкиваются с тем, что различных процессов, связанных с предоставлением той или иной услуги, множество и они не слишком прозрачны. Тогда их требуется упорядочить. Для решения этой задачи можно использовать средства анализа бизнес-процессов. И уже после этого можно перекомпоновать их с использованием известных сервисов и выделением общих данных. Без сервисно-ориентированной архитектуры при создании процессов не обойтись. Но если мы интегрируем данные, то картина будет уже совсем другой. Особенно если приходится иметь дело с большими потоками данных.
Михаил Заборов: Что касается сервисного подхода, то он используется и при создании самих систем. Многие крупные приложения можно представить в виде наборов сервисов, которые определенным образом между собой взаимодействуют. Это позволяет выстроить более четкую картину при интеграции таких систем между собой, поскольку понятно, какую информацию используют данные сервисы и как правильно организовать их взаимодействие. Все это серьезно облегчает работу по интеграции.
Ольга Кузнецова: Даже системы «всё в одном» часто внедряются модулями, один за другим. И дальнейшей интеграцией этих модулей тоже приходится заниматься. Сложность лишь в том, что клиент обычно хочет сразу и дешево, и качественно, и быстро, чего не бывает. С нуля что‑то приходится внедрять очень и очень редко. Хотя и такие примеры встречаются — не так давно мы внедряли системы автоматизации в крупном холдинге, где долгое время все ограничивалось использованием электронных таблиц. Но чаще приходится объединять разные системы, в том числе и самописные, сделанные неизвестно кем и неизвестно когда.
А насчет сервисного подхода хотелось бы согласиться со всем ранее услышанным. Не зря такие вендоры, как SAP и Microsoft, совместно разработали интеграционную платформу на базе сервисов, описывающих организацию процессов и их взаимодействие. За сервисным подходом будущее.
Антон Левиков: Так складывается, что все рабочие вопросы, которыми я занимаюсь, в той или иной степени относятся к интеграции. Было время, когда сохранялась иллюзия, будто бы все данные можно держать в одной системе, но сейчас понятно, что это сложно и не очень целесообразно. «Технологически» можно обеспечить работу с данными в рамках одной системы, но придется тратить существенные силы и средства на ее поддержку. И даже в этом случае не обойтись без интеграции отдельных модулей (например, клиент-банков).
Если говорить в целом, то основные сложности интеграции, на мой взгляд, связаны не с технологиями, а с людьми. Довольно сложно бывает обеспечить для разных групп пользователей работу с общими справочниками. И когда это получается, то остается уже «техника». Да и сами системы подбираются так, чтобы иметь возможность интеграции.
Андрей Давыдов: Для нас интеграция является жизненно необходимой: большинство новых проектов проходят определённый этап, задачами которого как раз и являются не просто оценка и реализация внедрения одной новой технологии, но рассмотрение и изучение всего ИТ-ландшафта в целом. А необходимость интеграции обусловлена сложными бизнес-процессами компании; интегрированные ИТ‑системы позволяют принимать оперативные решения на основе массива данных из различных блоков и зачастую опережать конкурентов на рынке. В наших внутренних процедурах есть стадия, которая называется Integration testing, в ходе которой разработчики проводят тестирование с учетом возможности дальнейшей интеграции.
Intelligent Enterprise: Как современные технологии и подходы (аутсорсинг, облака, удаленная работа), являющиеся своего рода центробежными тенденциями в ИТ, соотносятся с потребностью в интеграции приложений? Нет ли тут противоречий, а если есть, то как они снимаются?
Михаил Заборов: На самом деле указанные технологии только кажутся центробежными. В большинстве случаев их применение не только не повышает требования к интеграции, но даже и снижает их. Информационные ресурсы под воздействием новых технологий централизуются. В частности, во многих случаях компании отказываются от региональных ЦОДов и переносят их в централизованное облачное хранение. При этом усиливаются требования к каналам связи, которые стали гораздо лучше, но по‑прежнему в некоторых местах еще далеки от идеала. Например, в военных городках, где хорошо, если есть хотя бы мобильная связь.
Павел Романченко: И при этом нет гарантии того, что информация достигнет точки назначения. А это не всегда удается донести до заказчика.
Василий Анфиногентов: Некоторые путают консолидацию и интеграцию. В итоге приходится доказывать, что если всё свезли в единый ЦОД и даже обеспечили единое управление данными, то это вовсе не означает, что системы уже интегрированы. А что касается проблем со связью, то они решаемы. Еще не так давно во многих областях Центральной России ситуация была ничуть не лучше, чем на Крайнем Севере. Проблему решали тем, что раз в месяц свозили системные блоки в райцентр, где и извлекались данные. Сейчас такого уже нет, и прогресс налицо.
Антон Левиков: Я скажу про удаленную работу — желание получить доступ к информации из любого места в том же функционале и с таким же удобством, как и в офисе. Обеспечение доступа к бизнес-приложениям с мобильных устройств — целиком интеграционная задача. Ведь приходится работать как минимум с тремя разными платформами — iOS, Android, Windows. Что касается аутсорсинга, то проблема интеграции может возникнуть, когда вовне передаются бизнес-процессы целиком, например бухгалтерский учет. Это связано с вопросом о том, как «двигаются» данные. В случае передачи бухгалтерского учета все данные будут формироваться и находиться у «аутсорсера». Если компания должна получать от него данные в электронном виде, а не только отчеты, то это определит необходимость интеграции.
Ольга Кузнецова: Да, вопрос канала связи стоит, и остро. Мы сейчас сами работаем над проектом организации передачи данных в крупном лесопромышленном холдинге, где встала задача отследить путь леса от делянки до завода. И на этих самых делянках единственным способом связи оказалась спутниковая. В итоге возникает проблема обслуживания этого оборудования, которое к тому же будет работать в экстремальных условиях. Аутсорсинг ИТ-проектов здесь ни на что не влияет. Хотя иногда бывает и так, что проект по интеграции сопровождается передачей на аутсорсинг, но это параллельные процессы, которые никак друг на друге не сказываются. Интересно в этой связи посмотреть на взаимодействие интеграции и аутсорсинга бизнес-процессов. Данный подход может вылиться для проекта в форменный кошмар. Причина — низкое качество данных.
Павел Романченко: А тут возникает вопрос, как определить качество данных. Аутсорсинг часто сравнивают с электроснабжением, качество которого легко можно измерить. А вот с качеством данных вопросов много. И не все можно отдать на аутсорсинг.
Михаил Заборов: Мы сталкивались с ситуациями, когда на аутсорсинг отдавали не только разработку и обслуживание программного обеспечения для интеграции, но и процессы сбора и обработки данных.
Василий Анфиногентов: Аутсорсинг бизнес-процессов усложняет задачу интеграции данных. Ведь основной бизнес-процесс, который отличает твою компанию от всех остальных, нельзя передать на внешнее управление. Плюс высказанная коллегами проблема качества данных. Она решается логическим контролем, но это сложная и часто дорогая процедура. Так работают средства контроля фрода в телекоммуникациях или страховом бизнесе.
Ольга Кузнецова: Эти задачи решаются с помощью аналитических систем, в том числе путём анализа больших данных. А тема эта сейчас на пике популярности.
Андрей Давыдов: На мой взгляд потребность в интеграции изначально не сильно связана с известными тенденциями централизации информационной поддержки бизнеса. Но что интересно: например, после организации общего ЦОДа в компаниях осознают, какой набор разнородных систем собран воедино, и уже закономерным выводом является общий вектор движения в сторону интеграции или скорее даже уменьшения количества разнородных приложений.
Intelligent Enterprise: Какие проблемы приходится решать в ходе проектов, технологические или организационные? Какова роль ИТ‑стандартизации, в том числе внутрикорпоративной, в интеграционных проектах?
Василий Анфиногентов: Технические проблемы решаются, вопрос лишь в стоимости. А вот проблемы организационные могут быть настолько серьезными, что проект будет буксовать исключительно из‑за них. Поэтому стоит задача сначала договориться с владельцами приложений, которые мы интегрируем. Для этого следует создать специальную группу. Особенно остро данная проблема стоит в государственных учреждениях, поскольку такого рода деятельность не является базовой. Могу сказать, что проект по созданию системы межведомственного электронного взаимодействия на региональном уровне тормозится в значительной степени именно из‑за организационных неувязок.
Но если организационные проблемы решены, то все остальное легко удастся преодолеть. Ведь решение задач интеграции нужно собственнику, так как в результате повысится эффективность контроля, в том числе и за сотрудниками. Выявляются всяческого рода «серые» зоны. А это определённо может встретить сопротивление.
Стандартизация, конечно, нужна — хотя бы для того, чтобы облегчить поддержку решения. Особенно с прицелом на его развитие. Мне приходилось сталкиваться с ситуацией, когда за 48 систем отвечало 48 человек. И если один из них заболевал или уходил в отпуск, то эта система оказывалась бесхозной. Это, конечно, тоже вариант, но долго такая ситуация просуществовать не может. Стандартизация как любая формализация позволяет оторвать знания от их носителей. В итоге любая часть интегрированной системы может развиваться самостоятельно. Кроме того, благодаря стандартизации не нужно каждый раз что‑то создавать заново, а значит, достигается существенная экономия ресурсов при повторном использовании принятых шаблонов.
Павел Романченко: Нередкий пример — банки, где за интернет-банкинг отвечает одно подразделение, за бэк-офис — другое. Скорее всего они используют разные технологии, которые слабо связаны между собой или не связаны вообще. И у каждого свои представления о том, что является правильным. У каждого свои KPI и свои сроки, и всё это может пострадать при смене модели работы. Дело тут может дойти до серьезных разбирательств.
Со стандартами не все гладко. Многие из них, в том числе известный протокол SOAP, являются неполными и противоречивыми. Его имплементации у разных вендоров (а иногда и у одного в решениях для разных платформ) различны, что в итоге приводит к проблемам с совместимостью. И это необходимо учитывать.
Ольга Кузнецова: Да, в таких проектах человеческий фактор является самой сложной проблемой, с какой только можно столкнуться. Причем бизнес может быть стопроцентно заинтересован в проекте и ИТ‑служба может его поддерживать, но появляются Марья Ивановна или Василий Петрович, от которых вдруг требуется совсем не то, к чему они привыкли. Это вызывает отторжение. В моей практике были случаи, когда систему внедряли, но она так и не приживалась у пользователей и оказывалась заброшенной.
Что касается стандартизации, то этот вопрос более характерен для аутсорсинговых проектов. Приходит клиент, вроде бы готовый к аутсорсингу. Но готовность эта моральная, а не с точки зрения ИТ, и приходится иметь дело с зоопарком ИТ‑систем, причем часть из них разработана давно, и как они поддерживаются, непонятно. Тут все зависит все от той же политической воли руководства. И просто стандартизация нужна для того, чтобы иметь саму возможность интегрировать системы.
Антон Левиков: Проблемы скорее организационные, в частности, увеличение сроков проектов, вызванное изменением рамок, что называется, на ходу. Легче, если работы реализуются своими силами. Но если привлечен сторонний исполнитель, возникают и проблемы, связанные с превышением бюджета проекта. Роль ИТ‑стандартизации считаю крайне важной. Например, в автоматизации строительства сейчас разворачивается перспективный тренд в области информационного моделирования зданий (термин BIM — Building Information Modeling). На рынке представлены две конкурирующие системы под решение данной задачи и значительное количество «вспомогательных» продуктов (например, сметы, программы для расчета конструкций из различных материалов и т. д.). Одной системой в реальной жизни никак не обойтись, даже конкуренты это признают. Но стандарты разрабатывать никому не интересно, а задачи интеграции решаются только под крупных заказчиков, которые готовы их финансировать. Из-за этого всего полезная технология внедряется медленно.
Андрей Давыдов: Стандартизация очень помогает нам организовать единое коммуникационное пространство между бизнесом и ИТ-отделом. Когда ИТ-документацию по проекту, разработанную по определенным стандартам, известным бизнесу, этот же бизнес может однозначно понять, это очень способствует разрешению организационных моментов, про которые упоминал мой коллега. Я бы еще добавил, что помимо отраслевых стандартов весьма эффективным является наличие стандартов корпоративных, основанных на общих принципах, но адаптированных под специфику компании в целом.
Михаил Заборов: Я не согласился бы с тем, что технические проблемы совсем отсутствуют. Мне встречались ситуации, когда задачи, достаточно просто сформулированные с точки зрения бизнеса, не имели адекватного технического решения — в смысле полноты исполнения, производительности, скорости реакции и т. д. Конечно, выход всегда находился, и какое‑то приемлемое решение предлагалось, но зачастую это был результат непростого компромисса. Что касается организационных вопросов, то тут всё зависит от того, насколько насущны те проблемы, которые стоят за поставленной задачей. Если есть действительно серьезная заинтересованность, то организационные проблемы обычно решаются. Непреодолимыми они становятся лишь тогда, когда проект оказывается никому не нужен.
Стандартизация должна быть там, где для нее есть фундаментальные причины. Если у вас розничная сеть магазинов одного формата, то понятно, что они должны быть одинаковыми. Но если у вас одно подразделение продает автомобили в Москве, а другое — муку в Киеве, то скорее всего стандартизация не имеет смысла. Основания для стандартизации появляются не потому, что мы этого хотим, а с тем, чтобы, например, соответствовать нормам какого‑то законодательного акта или регламента. Однако нужно помнить, что стандарт дает экономию только тогда, когда им уже пользуешься. При этом он может быть весьма дорог, когда его только создаешь и поддерживаешь.
Intelligent Enterprise: Как упорядочить работу по контролю изменений? Какие методические приемы применять? Насколько актуальными становятся известные методики, стандарты, лучшие практики?
Антон Левиков: Приятно, когда приходят знающие люди и говорят, что они все сделают в соответствии с лучшими практиками. Но потом они достают бумагу, а точнее, толстую книгу, и не одну. Причем 70 % из того, что написано в толстой книге, в реальной жизни не очень востребовано. И на реализацию этого еще нужно потратить силы. Умом я понимаю, что эффект будет. Но, честно говоря, на это жаль тратить свое время.
Ольга Кузнецова: Надо отметить, что обладание документом о той или иной сертификации ничего не означает, важно, чему полезному для заказчиков обучены специалисты. Люди должны понимать, что конкретное, реально применимое к жизни за этим стоит.
Василий Анфиногентов: Среди тех стандартов и лучших практик, которые обозначены в вопросе применительно к обсуждаемой нами проблеме интеграции, особенным образом выделяется ITIL. Он описывает процессы, относящиеся к работе ИТ. Все остальное — это по большому счету некие опросники для самоконтроля. Это тоже полезно, не у каждого специалиста настолько широкий взгляд, позволяющий охватить всю «поляну». Но еще больше мне нравятся подходы некоторых вендоров. В Oracle Unified Method очень детально проработано несколько десятков стадий, которые необходимо пройти при разработке приложений или внедрении продуктов этой компании. Причем не за все из них должен отвечать заказчик. Да и вообще иметь план работ всегда полезно. Хотя действительно, как при подготовке к экзаменам, будут возникать вопросы, с которыми вы не столкнетесь никогда в жизни. Но это расширяет горизонт познаний и значит, все равно полезно. Тем не менее всему должна быть мера. Попытка загнать всех в какие‑то шаблоны без учета особенностей текущей ситуации ни к чему хорошему не приведет.
Михаил Заборов: Но наличие плана все равно не гарантирует того, что проект будет успешным. К тому же, как в любом деле, не нужно перегибать палку. Нередки такие явления, как кризис перепроектирования.
Андрей Давыдов: Считаю важным добавить, что механизм контроля изменений должен быть в первую очередь очевидным для всех участников проекта, а уже затем привязанным к каким‑либо отраслевым стандартам. В моей практике встречались случаи, когда управление изменениями было настолько тяжеловесно реализовано по сравнению с масштабом проекта, что управление этими изменениями было совершенно неэффективно и осложняло ведение проекта.
Intelligent Enterprise: Каковы типичные схемы интеграции на практике? Какие системы чаще всего интегрируют и от чего можно получить больший практический эффект?
Павел Романченко: В своей практике мы стараемся разорвать схему «точка — точка» и вообще убрать знания подсистем друг о друге, чтобы создать единое пространство для работы.
Василий Анфиногентов. Мы стремимся к тому, чтобы количество интеграционных узлов было минимальным — хорошо, если только один, либо совсем небольшое их количество в случае высокой нагрузки. Но и здесь этот узел должен быть легко управляемым. И данные должны быть сведены к каноническому виду, с тем чтобы избежать дополнительных преобразований. Можно допустить возможность преобразования данных вне интеграционного узла. В противном случае речь будет идти не об интеграции, а о создании новой системы. И нужна заявка от бизнеса или государственных органов — от владельца процесса. Иначе возникает ситуация со множеством сервисов, с которыми никто не знает что делать. Тут хорошим примером будет внедрение сервиса «Одно окно» в Москве. Первые четыре услуги, внедренные на первом этапе, охватывали 85 % обращений.
Ольга Кузнецова: И такая система не должна быть сложнее предыдущей. А то будут трудности с поддержкой.
Михаил Заборов: Мы обычно практикуем такой подход: выделяются кластеры систем таким образом, чтобы внутри кластера взаимодействие было сильное и частое, а между кластерами — редкое и слабое. Внутри кластера лучше всего использовать прямую интеграцию, потому что системы много друг про друга знают. Между кластерами можно использовать централизованные решения (например, интеграционные шины), так как в этом случае специфики взаимодействия существенно меньше.
Антон Левиков: Мне хотелось бы видеть системы, которые могли бы работать с совершенно разными данными (например, обрабатывать видео из торгового зала, идентифицируя товары, взятые покупателями с полок, в системе товародвижения, а самих покупателей — в CRM‑системе). Представляете, какие возможности для анализа и повышения эффективности продаж даст такая система! Сейчас сложно сообразить насчет технической реализации, но я думаю, что в течение пяти лет подобные решения появятся.
Андрей Давыдов: Все‑таки добавлю небольшую ложку дегтя. Интеграция нужна не во всех абсолютно случаях. Например, для разнесения контуров оперативного и финансового учета мы намеренно используем разные системы и не планируем непосредственно их интегрировать из соображений разделения информационных потоков. А вот для получения целостной картины отчетности по нескольким странам или регионам в международной компании интеграция разных систем по одному виду учета деятельности приносит очень весомые результаты.
Intelligent Enterprise: На какой стадии организационной зрелости компании и кому конкретно стоит думать об интеграции приложений? Является ли эта проблема актуальной для стартапов или совсем небольших предприятий?
Ольга Кузнецова: Оптимальный путь — решать задачу интеграции или совсем с нуля, или тогда, когда все процессы более или менее устоялись на предприятии.
Василий Анфиногентов: Есть успешные примеры проектов, когда бизнес-процессы заказчика еще не были до конца сформированы. Так что уровень зрелости не является принципиальным. На это должен быть запрос. А он возникает, когда есть процесс, связывающий людей и данные.
Михаил Заборов: Задача интеграции актуальна для любой компании, где эксплуатируются как минимум две системы. На самом деле потребность в интеграции является зеркальным отображением взаимоотношений между подразделениями компании. Если подразделения, которые пользуются разными системами, в ежедневной работе активно взаимодействуют между собой, то обычно их системы требуют интеграции. Если подразделения не взаимодействуют, то и интеграция скорее всего преждевременна.
Павел Романченко: ИТ-подразделение, которое отвечает за работу конкретных систем, обычно стремится к «точечной» интеграции, к максимальной независимости от других ИТ-подразделений в компании. Более полная и глубокая интеграция нужна ИТ-руководству как ответ на потребности бизнеса.
Антон Левиков: Я считаю, что ИТ‑специалистам интеграция тоже выгодна. Чем меньше проблем с тем же обменом данными между разными системами, тем больше времени остается для решения других задач, более «интересных». Но все же для интеграционных проектов необходима определенная организационная зрелость. Только тогда возможна ситуация, которую обрисовал Василий. В противном случае всё живет некими кусочками.
Андрей Давыдов: На мой взгляд очень важно не упустить момент, когда необходимо поднять вопрос об интеграции различных систем, иначе разнородность программ становится настолько большой, что стоимость интеграции будет уже в разы выше и усилий на разбор зоопарка приложений потребуется гораздо больше.
Intelligent Enterprise: Потеря производительности и снижение надежности — весьма распространенные жалобы у тех, кто внедрил решения для интеграции приложений. Насколько эти слухи правдивы и насколько преувеличены?
Василий Анфиногентов: Интеграционные проекты порождают новые точки отказа. Однако есть хорошо известные способы борьбы за надежность: резервирование, кластеризация. Могут возникать проблемы с производительностью, но выигрывая в стоимости, теряешь в производительности и наоборот. Плюс ко всему может восприниматься как потеря производительности то, что при интеграции систем одна не будет работать до тех пор, пока не получит все необходимые данные от других. Раньше, когда они работали сами по себе, с подобными задержками связываться не приходилось. Но данная проблема также решаема. В этом отношении у всех крупных вендоров общий подход, хотя реализация может быть различной. Всё сводится к тому, чтобы снизить системную сложность, например, за счет деления на слои. Одним словом, нерешаемых проблем нет. Просто во всем нужна мера.
Михаил Заборов: Мой опыт использования интеграционных платформ показывает, что тут нередки большие проблемы как с надежностью, так и с производительностью. Хотя главная трудность связана с системной сложностью. Интеграционная платформа начинает в самом буквальном смысле слишком много знать о системах, которые интегрирует, и в итоге становится сложнее этих систем.
Довольно распространённой ошибкой является попытка с помощью интеграционных платформ решить проблему управления мастер-данными (в самых плохих случаях шина хранит идентификаторы всех справочных объектов из всех систем и таблицы их перекодировки). Лучше для этих целей использовать специализированные решения.
Ольга Кузнецова: Интеграция призвана как раз увеличивать надежность, упрощать дальнейшую поддержку единой, унифицированной системы. Но когда мы вводим понятие интеграционной шины, то увеличиваем зависимость от каналов связи. И если раньше возникали проблемы, но мы могли продолжать работать в отдельно взятых системах, то при внедрении интеграции эта возможность рискует потеряться.
А что касается сложности, то интеграция как раз и заключается в том, чтобы не менять текущие бизнес-процессы. Если же нужно что‑то изменить, то такие изменения должны вноситься в систему, где они необходимы. Саму шину изменения затрагивать не должны. И вопрос с мастер-данными также сложен, это тема отдельного обсуждения.
Павел Романченко: Но системам часто нужно знать друг про друга всё. Или по крайней мере приводить данные к единому виду. Как раз интеграционная шина может взять это на себя и предоставить сервисы, которые не только не уменьшат, но и увеличат производительность, например, за счет кэширования часто используемых данных.
Андрей Давыдов: Хочу добавить, что одной из проблем интеграции является размывание зоны ответственности за конкретные приложения. Были ситуации, когда всё происходило как у Райкина: к пуговицам претензии есть? Претензий нет. То есть сами программы работают, а ответственного за общий результат нет. Очень важно зафиксировать ожидания от интеграции определенных программ, а также заранее определить зоны ответственности за возможные новые «тонкие» места интеграции, и тогда общим результатом будет повышение скорости бизнес-процессов компании без потери качества.
Схемы интеграции зависят от зрелости ИТ
Денис Андриков,
заместитель технического директора компании «Открытые технологии»В ходе реально выполняемых интеграционных проектов безусловно встают как технологические, так и организационные проблемы. Выделить тот или иной преобладающий фактор сложно. Если бы все унаследованные информационные системы имели чёткую документацию по разработке, осуществлялся бы правильный версионный контроль, а эксплуатация проводилась по правилам, то, вероятно, проблем с технологической частью не было бы вообще. Вопрос интеграции был бы просто делом времени. Отсюда же вытекает важность стандартизации управления ИТ-процессами и ресурсами компании. Часто этим пренебрегают, воспринимая регламенты работы как что‑то ненужное. Очевидно, что начиная с определённого коэффициента отношения глубины проникновения ИТ в бизнес к объёму ресурсов, использующих ИТ для решения бизнес-задач, пренебрегать стандартами нельзя, ибо это чревато увеличением накладных расходов. В связи с вопросом о проблемах хочется обратить внимание на другой аспект, возникающий в ходе реализации интеграционных проектов: размытое понимание бизнес-заказчиком границ проекта по интеграции, что затягивает сроки старта проекта, а при слабой проработке вопроса — сроки ввода в эксплуатацию.
Технологически схемы интеграции очень зависят от степени зрелости текущего ИТ-ландшафта. Классическая схема интеграции крупного бизнеса — это взаимоувязывание информационных и управляющих потоков через единую шину данных. Подключение к шине проектируется исходя из наличия или разработки соответствующих коннекторов. Подобный подход тянет за собой необходимость внедрения единой системы нормативно‑справочной информации. Базируясь на идеалах SOA, подобный подход позволяет обеспечить работоспособность сервисов, хотя и не без серьёзных расходов как с точки зрения стоимости проекта, так и по трудозатратам на внедрение. Чаще всего приходится интегрировать вспомогательную информационную систему в ключевой ИТ-процесс (например, систему противодействия мошенничеству в систему биллинга или систему расчёта вознаграждений агентам в систему продаж страховых услуг).
Что касается востребованности технологий информационной интеграции предприятий разного типа, то, как ни странно, для СМБ, а тем более стартапов этот вопрос важен как ни для кого другого. Эти сегменты просто не смогут выдержать те высокие накладные расходы, которые возникают из‑за недостатка интегрированности различных ИТ‑сегментов в общий бизнес-процесс. Эффект слабой заинтересованности в интеграции стартапов в том, что они либо выбирают изначально интегрированные продукты для обслуживания ИТ, либо вся интеграция у них может быть выполнена в ручном режиме. Критерием необходимости старта проекта по интеграции, на мой взгляд, является переход за границу приемлемого уровня значения накладных расходов на ручной привод информационного обмена. Например, компания сама определяет, что она готова содержать пять финансовых аналитиков, которые занимаются скрещиванием отчётов из различных учётных систем, вместо того чтобы один раз интегрировать «1С», CRM и внедрить систему управления данными.
В целом же можно сказать, что сегодня важность и сложность интеграционного проекта банально недооценены. Типична ситуация, когда проект инициируют ИТ‑специалисты, стремясь достичь красоты в архитектуре ИТ-решения. А бизнес не понимает, зачем нужно единое информационное пространство, MDM‑системы, шины информационного обмена и интеграция вообще. Ведь они уже купили две или три системы, которые работают, — почему надо платить за то, что уже и так работает? И интеграционный проект воспринимают как вторичный, далее следует урезание бюджета, что приводит к снижению качества реализации. Для того, чтобы избежать подобной ситуации, необходимо «продать» идею бизнесу, развернуть систему в непрофильном бизнес-подразделении (чтобы отработать все аспекты интеграции), а потом расширять внедрение, показывая эффективность по заранее согласованным критериям. В любом случае производительность и надёжность — вторичные показатели. Любая интеграция необходима для снижения накладных расходов подразделений, работающих с интегрируемыми ИТ‑системами.
