Интеграционные проекты требуют больших затрат и усилий. При каких условиях имеет смысл начинать полномасштабные проекты по интеграции бизнес-процессов и поддерживающих их приложений?

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

Бизнес подскажет

Единственное условие для начала масштабного интеграционного проекта — требование бизнеса предприятия. Это время наступает тогда, когда без интеграции приложений бизнес «пробуксовывает» или транзакционные издержки становятся слишком велики, что не дает бизнесу развиваться и даже приводит к убыткам.

Если предприятию выгоднее, чтобы пять операторов, получающих по 700 долл. в месяц, вручную переносили данные из одного бизнес-приложения в другое, то пусть переносят. Но руководству следует помнить, что в этом случае резко возрастает вероятность ошибок и усиливаются риски, определяющиеся человеческим фактором. Рано или поздно потери, вызванные этими причинами, начнут негативно влиять на бизнес. Этот критический момент всегда настает в процессе роста компании: проблемы проявляются то в одном подразделении, то в другом… Медленная синхронизация данных, ошибки, потери времени при дублировании ввода информации — все сказывается на скорости принятия управленческих решений и в конце концов лишает компанию конкурентных преимуществ.

На рынке не так много интеграционных платформ и их выбирают, как правило, исключительно по техническим параметрам. Прямой зависимости между выбором продукта, отраслью, в которой работает предприятие, и его размером (как при выборе ERP) нет. Многое зависит от того, какие бизнес-приложения уже используются в компании. Например, если ваша ERP-система реализована на основе Oracle E-Business Suite, то и интеграционные продукты логичнее брать от Oracle — в этом случае не придется дополнительно платить за лицензии. Если в инфраструктуре бизнес-приложений наблюдается разнобой, то можно взять, например, продукты IBM. Если организация активно использует технологии Microsoft — следует применять продукты Microsoft SharePoint Portal Server и BizTalk Server.

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

Александр Буйдов, директор по ИТ компании КРОК, Buydov@croc.ru

Должен появиться заказчик

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

Как показывает опыт, потребность внедрений интеграционных решений начинает проявлятся в определенных ситуациях. В первой из них отчеты, выгружаемые руководству из различных систем, используемых разными подразделениями компании, расходятся друг с другом. Возникает вопрос: на основе какого из них руководителю строить свои управленческие решения? Самый простой выход — осуществить сверку и исправление данных в одной или нескольких системах. Но если такую сверку проводят в «-цатый» раз, приходит понимание необходимости интеграции. Иногда предприятию достаточно одной сверки, чтобы осознать эту потребность.

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

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

Четвертая ситуация связана с реализацией интеграционных проектов по внедрению комплексных интегрированных систем класса ERP, CRM, EAM и т. д. Эта необходимость вызвана прежде всего тем, что данные системы, как правило, приходится интегрировать с другими корпоративными системами, которые уже используются в компании и вполне устраивают по своей функциональности. Кроме того, комплексные информационные системы обладают сложной бизнес-логикой и требуют для стыковки с другими системами разработки сложных интерфейсов, написание которых с нуля (например, для выгрузки тех же файлов обмена) может стать чрезвычайно трудоемкой задачей. В итоге становится целесообразным использование готовых адаптеров, предоставляемых производителями интеграционных платформ или производителями самих комплексных систем.

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

Во-вторых, оказывается, что нормативно-справочная информация (НСИ), несмотря все на попытки ее регламентировать и стандартизовать в рамках компании, во всех системах ведется по-своему.

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

Средства интеграции следует выбирать, исходя из следующих соображений:

  1. функциональных и нефункциональных требований к проекту (таких как частота и объем передаваемых данных, технология их переноса, особенности интеграции процессов и т. п.);
  2. существующего ИТ-ландшафта;
  3. наличия в интеграционной платформе адаптеров к бизнес-приложениям, используемым в компании;
  4. опыта работы исполнителя с решениями поставщика интеграционной платформы.

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

Екатерина Волощенко, директор департамента электронного бизнеса и заказных разработок компании TopS Business Integrator, KVolochtchenko@topsbi.ru