С ростом числа приложений SaaS, сформировавших огромный рынок, охватывающий практически все виды бизнес-задач, растут и проблемы их интеграции, сообщают опрошенные порталом ComputerWeekly эксперты.
В 1999 г. компания Salesforce создала первый настоящий пакет «ПО как сервис» (SaaS). Сейчас существует более 10 тыс. облачных приложений, предназначенных для предприятий всех размеров и охватывающих все сферы деятельности — от основных бизнес-функций, таких как финансы или ERP, до узкоспециализированных задач.
Столь широкое распространение SaaS-технологий помогло организациям модернизировать, цифровизировать и автоматизировать бизнес-процессы. Эти приложения также позволили ИТ-отделам сократить накладные расходы, включая расходы на аппаратное обеспечение, инфраструктуру и лицензирование.
Такие компании, как Salesforce и NetSuite (ныне принадлежащая Oracle), стали пионерами в создании модели корпоративного ПО, основанной на подписке или оплате по факту использования. Уже трудно представить, насколько революционной была модель простой оплаты за пользователя в месяц. А сегодня есть компании, причем не только стартапы, которые вообще не имеют корпоративной ИТ-инфраструктуры и работают только на облачных технологиях.
Однако сейчас компании часто работают с несколькими SaaS-приложениями, поэтому им необходимы способы объединения рабочих процессов и обеспечения согласованности и точности общих данных. Они также могут сталкиваться с целым рядом других проблем, отчасти из-за особенностей разработки и функционирования SaaS-приложений, а отчасти из-за того, что выбирают их, ориентируясь на лучшие функциональные возможности.
Пакеты SaaS — это, в основном, «функциональные», или фундаментальные приложения, предназначенные для удовлетворения потребностей конкретной области бизнеса. К ним относятся управление взаимоотношениями с клиентами (CRM) и автоматизация продаж — именно здесь Salesforce сделала себе имя, — а также такие сферы, как управление персоналом (HR).
Однако эти приложения, по крайней мере изначально, были рассчитаны на самостоятельную работу. Отчасти привлекательность SaaS заключалась в том, что отделы или функции могли самостоятельно, независимо от ИТ-службы, применять собственные технологии, причем зачастую в тех областях, которые ИТ-служба упускала из виду или не имела достаточных ресурсов.
«Большинство уже использует SaaS-приложения, лишь немногие крупные организации не имеют таковых, — говорит Эндрю Ларссен, специалист PA Consulting Group по корпоративным ИТ. — Мы видим много таких приложений в HR, поскольку это внутренняя функция, о которой можно немного забыть, так как она не приносит дохода».
По его словам, другая область, где видно большое присутствие SaaS, — это управление продажами и CRM: «У многих компаний есть что-то в этой области для управления контактами и лидами... Но даже если вы покупаете у одного поставщика, часто возникает задача заставить все это работать вместе». И эта задача становится все более сложной, поскольку количество отдельных, «изолированных» приложений увеличивается, а организации пытаются автоматизировать больше рабочих процессов.
Разрастание SaaS
Современные предприятия, скорее всего, используют десятки, а то и сотни отдельных SaaS-приложений.
Простота приобретения и настройки пакетов SaaS, их природа самообслуживания (часто без привлечения ИТ-специалистов) и понятное желание подразделений приобрести лучшую технологию привели к «разрастанию» SaaS. И хотя отделы могут воспринимать себя отдельно от других — со своими специфическими потребностями в ИТ, бизнесу в целом необходимы общие рабочие процессы и согласованные данные.
«SaaS-приложения часто специализируются только в одной области, например, ERP, CRM или HR, — отмечает Стив Денг, старший директор-аналитик Gartner. — Но они работают не в изоляции. Общими задачами интеграции являются синхронизация данных и оркестровка бизнес-процессов между этими приложениями».
По его словам, компаниям необходимо обеспечить согласованность данных всех своих SaaS-приложений. Это легче сказать, чем сделать, поскольку приложения, как правило, хранят данные в собственных хранилищах и на собственной облачной инфраструктуре.
Предприятиям нужно обеспечить использование согласованных форматов данных для обмена данными между SaaS-приложениями и приложениями поставщиков и заказчиков. Им необходимы «видимость и понимание данных, которые распределены между этими SaaS-приложениями», — добавляет Денг.
Однако «SaaS-приложения и локальные приложения могут представлять или хранить свои данные в различных моделях и форматах, — предупреждает он. — Многие организации испытывают трудности с обеспечением своевременного согласования данных в разных приложениях».
Некачественные или противоречивые данные могут свести на нет все преимущества приобретения лучшего SaaS-приложения, а неэффективные или неработающие рабочие процессы только усугубляют проблемы.
«Предприятиям действительно необходимо интегрировать различные системы, чтобы иметь возможность составлять управленческую отчетность или передавать данные между системами, — говорит Ларссен. — Если у вас есть система продаж или производственная система, вам необходимо передавать данные между ними. Если этого не делать, то в итоге можно получить разрозненные системы или повторный ввод данных. Данные — это жизненно важная составляющая бизнеса, и они должны передаваться по кругу». Альтернативой является подход «вращающегося кресла», когда пользователи повторно вводят информацию в разные системы. Это отнимает много времени и еще более чревато ошибками, предупреждает он.
И интеграция SaaS-приложений потенциально становится еще более важной, когда организации хотят автоматизировать свои процессы или использовать передовую аналитику, машинное обучение или искусственный интеллект.
Варианты интеграции
К счастью, возможности интеграции SaaS-приложений расширяются. Поставщики прикладного ПО упрощают интеграцию своих продуктов. По мере роста рынка SaaS новые участники конкурируют, в частности, за счет возможности работы с продуктами других поставщиков ПО, их наборами данных и рабочими процессами. Это также позволяет небольшим компаниям предлагать более специализированные, нишевые приложения, которые могут взаимодействовать с более крупными корпоративными приложениями и пакетами.
«Дальновидные поставщики предпочитают иметь меньший кусок пирога, чем вообще ничего, поэтому они с удовольствием интегрируются со всеми видами продуктов», — говорит Ларссен.
Кроме того, существуют технические достижения в области интеграции приложений и данных. SaaS-приложения прошли путь от поддержки экспорта данных (часто довольно ограниченного) до глубокой поддержки API, позволяющих компаниям создавать связи между инструментами.
В то же время расширение выбора SaaS-приложений и необходимость интеграции с онпремисными приложениями, унаследованными рабочими процессами и внешними источниками данных привели к появлению собственного рынка инструментов интеграции.
Ряд поставщиков ПО предлагает сегодня методы интеграции low-code, no-code или со встроенным «drag and drop». Эти «интеграционные платформы как сервис» (iPaaS) стали самостоятельной отраслью, и компании могут либо напрямую использовать их для создания собственных рабочих процессов, либо привлекать консультантов, имеющих опыт построения подобных процессов, часто в аналогичной сфере.
Некоторые компании, производящие программные инструменты, специализируются на добавлении событийных механизмов и потоковой передачи данных, которые обеспечивают более тесную связь между приложениями, чем API. Это может быть полезно в тех случаях, когда задержка или нарушение работы одного приложения приводит к нарушению работы другого или даже к потере данных в тесно взаимосвязанной среде, основанной на API. Еще одним вариантом является использование самого облака в качестве основы для интеграции с помощью таких инструментов, как Lamda от AWS.
Так же как редко можно найти универсальное SaaS-приложение, охватывающее все сферы бизнеса, так и не существует единого оптимального способа интеграции различных приложений.
Для одних, например, если приложения часто обмениваются данными и являются частью тесно связанного рабочего процесса, оптимальным вариантом может быть API-интеграция. Для других, когда приложения более независимы, а рабочие процессы требуют устойчивости, чтобы отказ или нарушение работы одного SaaS-приложения не приводил к сбоям в работе других, лучше использовать соединение на основе событий или потоков.
В некоторых случаях, когда обмен данными менее чувствителен ко времени, более подходящим может оказаться обычный пакетный процесс или процесс извлечения, преобразования и загрузки (ETL). Для рабочего процесса, который должен выполняться только раз в неделю, затраты и усилия на API-подключение могут оказаться неоправданными.
Однако, как отмечает Ларссен, CIO, возможно, придется выбирать оптимальный метод интеграции для удовлетворения различных требований, поскольку нет смысла использовать несколько форм интеграции между одними и теми же приложениями. «Если у вас есть два продукта, которые вы пытаетесь интегрировать, то работы будет меньше, если вы интегрируете их все одним и тем же способом», — говорит он.
Приводя в качестве примера интеграцию между HR- и IT-системами, Ларссен отмечает, что, хотя для добавления новых сотрудников вполне подойдет пакетный процесс, а для блокировки и разблокировки учетных записей — API, более разумным вариантом будет использование только одного метода. «С одинаковым успехом можно использовать API для всего», — говорит он.
Выбор также будет определяться временем, навыками и ресурсами, которыми располагают организации для интеграции SaaS-приложений. Высокоценный, критически важный или очень индивидуальный рабочий процесс заслуживает индивидуального кодирования; обычный, утилитарный рабочий процесс может быть лучше реализован с помощью готового инструмента или приложения iPaaS.
«Если вы не берете все свои приложения у одного поставщика, рано или поздно вам придется интегрировать приложения и данные», — говорит Денг. Но какой бы вариант ни выбрали CIO, он должен быть более надежным, точным и эффективным, чем «вращающееся кресло» и повторный ввод данных.
