Лицо современного бизнеса определяют информационные технологии. Они не только позволяют быстрее и проще реализовывать сложные алгоритмы, но и изменяют бизнес-модели и бизнес-процессы. Преемственность и целостность постоянно меняющихся бизнес-конструкций обеспечивают средства интеграции приложений >
Тот, кто думает, что его бизнес
"может функционировать по старым правилам, опирающимся на представления о массовом производстве, сегментном ценообразовании и стабильных организациях, заблуждается, - предупреждают консультанты центра бизнес-инноваций Сар Gemini Earnst & Young. - В новой экономике скорости столь стремительны, что вся она представляется размытым пятном, где четкие границы, разделяющие продавца и покупателя, продукт и услугу, работодателя и рабочего, исчезают. Чтобы быть прибыльным в этих непривычных условиях, бизнес должен вооружиться динамичным путеводителем".
Желание бизнесменов обеспечить себе более комфортное существование в нынешнем изменчивом, неопределенном и взаимозависимом мире и послужило основным стимулом поиска новых подходов к разработке ИТ. Мировой рынок бизнес-приложений и средств для их разработки переживает переходный период. Из "питательного бульона", содержащего незаконченные конструкции концепций, стандартов, платформ, вот-вот должно появиться нечто структурированное, надежное и всеобъемлющее. "Поиск пути" привел гигантов ИТ-индустрии к формированию новой информационной парадигмы
- интеграционной - и к борьбе за платформы для приложений: ведь тот, кто определяет платформы, будет определять и часть архитектуры приложений. Неудивительно, что основные поставщики прикладного и технологического ПО - IBM, Oracle, SAP и Microsoft
- активно вступили в борьбу за рынок будущего, вовлекая в технологическую трансформацию и более мелких игроков
Оказалось, что новая парадигма требует глубокого знания базовых бизнес-процессов (для правильной интеграции и конфигурирования софтверных платформ и программных компонентов). В результате усилилась бизнес-ориентация информационных технологий. "Бизнес-процессы, определяемые независимо от приложений, точно описывают необходимое взаимодействие между программными компонентами и потому могут выступать в роли концептуального проекта при сборке программных элементов, - утверждает в своих статьях профессор Август-Вильгельм Шеер, основоположник методологии проектирования бизнес-процессов ARIS. - Теперь ценность ИТ будет измеряться не только технологическим совершенством, но и качеством бизнес-процессов. На смену эпохе аппаратных, программных и сетевых средств идет эпоха управления процессами".
Действительно, гибкость бизнеса, его восприимчивость к инновациям не в последнюю очередь зависят от гибкости ИТ-фундамента, на котором он стоит. Неслучайно в последние три года в фокусе внимания технологов и архитекторов бизнеса оказались промышленные платформы интеграции приложений - Enterprise Application Integration (EAI). В мире, по оценкам IDC, объем этого сегмента рынка еще в 2002 году достиг $4 млрд. В России, по прогнозам экспертов, в ближайшей перспективе он составит десятки миллионов долларов.
КОМУ И ЗАЧЕМ
Средства EAI для корпоративной информационной системы выполняют ту же роль, что коммуникации в жилищно-коммунальном хозяйстве. Каждое программное приложение - это своего рода отдельная квартира или дом. Он и сам по себе, конечно, обладает ценностью, но если в жилом доме, допустим, нет телефона или центрального отопления, то возникает масса неудобств. Если в процессе работы сотрудники компании используют различные, не интегрированные между собой, программные приложения, это, как правило, приводит к непродуктивным тратам рабочего времени на операции по извлечению данных из одной системы в другую и их возвращению обратно, на проверку согласованности информации и т. д. Применяя EAI, предприятие использует еще один резерв, позволяющий поднять производительность труда, снизить издержки и обеспечить живучесть своей информационной системы в будущем.
В первую очередь потребность в методах и средствах EAI ощутили крупные растущие компании, охваченные процессом холдингообразования (банки, телекоммуникационные фирмы, торговые и нефтяные холдинги). "Для небольшой фирмы, потребность в автоматизации которой покрывается двумя-тремя учетными программами, промышленные средства EAI не актуальны ни по цене, ни по срокам реализации проектов, - говорит Артак Оганесян, менеджер по развитию бизнеса компании Vested Development, Inc., осуществившей три десятка интеграционных проектов в России, Европе и США. - Куда эффективней и дешевле напрямую соединить две программы или даже переносить данные в полуручном режиме. Для средних и крупных предприятий, где необходимо интегрировать десятки приложений, проблема так просто не решается. Здесь нужно обеспечить согласованную работу унаследованных систем собственной разработки и тиражных продуктов от разных поставщиков, а также взаимодействие с системами смежников и партнеров. Большинство из них, в свою очередь, могут быть комплексными решениями, состоящими из множества модулей, не всегда интегрированных между собой до нужного уровня. Территориальная распределенность филиалов компании, большое число разных приложений и большие объемы данных, а также тенденция бизнеса к росту и диверсификации - вот перечень серьезных предпосылок для использования промышленных интеграционных платформ. В этих случаях затраты на развертывание систем EAI окупаются однозначно".
Основное назначение средств EAI - стыковка эксплуатируемых приложений с новыми решениями без остановки или нарушения работоспособности действующей ИТ-инфраструктуры. Современные методики построения так называемой интеграционной шины позволяют проводить "без отрыва от производства" обновление и оптимизацию не только технологических составляющих корпоративной информационной системы (КИС), но и бизнес-процессов предприятия (см. справку).ПРАКТИЧЕСКАЯ ИНТЕГРАЦИЯ
Наиболее распространенной (и не очень сложной) является задача согласованной передачи данных, решаемая на уровне автоматизации экспорта/импорта данных из одной системы в другую за счет создания специализированных интерфейсов. Этот подход иллюстрируют первые два из приведенных ниже примеров. Еще две ситуации описывают более глубокую, реальную интеграцию, обеспечивающую возможность онлайновой работы связанных приложений.
Кейс 1. В проекте по автоматизации деятельности украинской корпорации "Агро-Союз" - многопрофильной организации, в числе прочего занимающейся розничной и оптовой торговлей запчастями к сельхозтехнике и грузовикам, - консалтинговая компания Columbus IT Partner Russia внедряла решение на базе ЕRР-системы Microsoft Business Solutions-Axapta в распределительном центре корпорации. Заказчик потребовал, чтобы оно было интегрировано с действующей на предприятии складской системой собственной разработки. Ручной перенос данных по приходным и расходным накладным из старой системы в MBS-Axapta потребовал бы дополнительных сотрудников и сопровождался бы большим количеством ошибок. Поэтому консультанты разработали двухсторонний интерфейс. Обмен данными по накладным осуществляется в автоматическом офлайновом режиме (по нажатию кнопки оператором) и занимает от нескольких секунд до нескольких минут. Передаваемая информация включает: изменения в справочнике номенклатуры, заголовки и строки накладных, реквизиты отправителя и получателя, цены и информацию по налогам для печати в формах накладных.
Все работы по проведению необходимых модификаций в обеих системах потребовали участия двух программистов и одного консультанта. При этом были использованы только заложенные в системах средства - других инструментов не потребовалось. Трудоемкость работ, включая согласование, разработку и тестирование интерфейса, оценивается в 9 человеко-недель. Сейчас обе системы ежедневно обрабатывают данные из накладных на товары, доставляемые и отправляемые 10-15 фурами.
Кейс 2. Разработчики приложений, которым приходится часто сталкиваться с задачами корректной передачи данных, стараются унифицировать и ускорить этот процесс. Так, специалисты компании "АйТи" предусмотрели в своей системе управления персоналом "БОСС-Кадровик" "универсальный интерфейс", в котором, по словам разработчиков, реализованы интерфейсы практически для всех групп данных, необходимых при стыковке с финансовыми и производственными системами.
"Самой востребованной стыковкой, конечно, является интеграция с финансовыми, бухгалтерскими и ЕRР-системами, - говорит Владимир Авсеев, главный конструктор системы „БОСС-Кадровик". - Как правило, она заключается в синхронизации ряда справочников (подразделения, работники, аналитические статьи затрат, план счетов) и в передаче финансовых результатов расчета заработной платы во внешнюю систему (платежные ведомости, проводки, депонент, доходы работников для учета в расчете зарплаты). Следующая по важности - стыковка с системами контроля доступа и учета рабочего времени, установленными у клиента. Основной результат такой стыковки - формирование на основании данных из этих систем табелей ежедневного учета и сведений для начисления заработной платы работникам".
Включив интерфейс в серийную версию своей системы, разработчики обязуются поддерживать форматы данных, регламент работы с ним и т. п. Поэтому сторонние разработчики (партнеры, внедренцы внешней системы, информационные службы заказчика) могут рассматривать интерфейс как "черный ящик", поведение которого подробно документировано и не должно вызывать неожиданных эффектов. "По нашей статистике, наличие унифицированного интерфейса ускоряет интеграционные работы более чем в два раза", - утверждает Владимир Авсеев.
Кейс 3. При развертывании корпоративной информационной системы на пивоваренных заводах часто приходится заниматься ее стыковкой со специализированными системами управления складом готовой продукции, которые автоматизируют процедуры приема, размещения, хранения, обработки и отгрузки товаров на складе. С этим столкнулись и специалисты петербургской компании "Монолит-Инфо" в проекте по автоматизации деятельности пивзавода "Вена". Им пришлось разрабатывать интерфейс между своим программным комплексом "Монолит SQL" и складской системой WMS. Эта разработка компании Solvo в автоматическом режиме осуществляет оперативное управление материальными потоками предприятия в пределах складского комплекса с использованием технологии штрихового кодирования, принципа адресного хранения и радиосвязи для передачи команд кладовщикам.
На этапе ввода в эксплуатацию комплекс "Монолит" должен был передать в систему WMS информацию о содержании всех общих для обеих систем классификаторов (складов, единиц измерения продукции, допустимых состояний товарно-материальных ценностей на складе, организаций-контрагентов). А в процессе эксплуатации - информировать WMS обо всех изменениях классифицируемых элементов. Кроме того, в процессе работы системы постоянно обмениваются документами. "Монолит" инициирует создание документов по отгрузке продукции покупателям, приему товаров от поставщика, возврату продукции от покупателя, возврату товаров поставщику, инвентаризации склада. В свою очередь складская система генерирует документы о приходе продукции из производства, о блокировке выписки со склада определенного количества товаров в связи с временной его недоступностью или обнаружением брака, о необходимости переупаковки и др.
Взаимодействие систем осуществляется в режиме on-line (системы обмениваются пакетами данных в формате XML по запросам от WMS). В месяц через интерфейс пересылается примерно 1500 - 2000 документов. Работы по интеграции, выполненные группой из пяти сотрудников "Монолит-Инфо", заняли около трех месяцев. Еще месяц ушел на тестирование и устранение замечаний. Стоимость проекта - около $20 тыс.
Аналогичный интеграционный проект "Монолит-Инфо" сейчас реализует на предприятии "Львовская пивоварня", в ближайших планах - интеграция с WMS для фармацевтической компании "РОСТА". Для ОАО "Ярпиво" была выполнена интеграция со складской системой SYSKRON (Германия), реализующей те же функции, что и WMS.
Кейс 4. В проекте по созданию корпоративной системы поддержки нормативно-справочной информации (НСИ) для одного из ведущих российских нефтяных холдингов компании IBS пришлось интегрировать системы почти от десятка разных производителей, работающих на разных платформах (от простых унаследованных систем на базе Clipper и DBase до современных решений на базе SAP R/3, MS SQL Server и Oracle). В холдинг входит более 100 территориально распределенных офисов, в каждом из которых функционирует несколько информационных систем.
Интеграторам нужно было решить две главные задачи - устранить дублирование справочных данных (обеспечить единый ввод данных, повысив их достоверность) и оптимизировать регламенты ведения НСИ. Интеграция осуществлялась на основе так называемых серверов интеграции, которые позволяют совмещать различные приложения, переформатировать данные и упорядочивать информационные потоки, обслуживающие бизнес-процессы организации (передача и обработка заявок, экспорт-импорт данных из различных систем с преобразованием их в формат, понятный этим системам). Выбирая из трех промышленных интеграционных платформ (Microsoft, IBM, Tibco), заказчик отдал предпочтение решению Microsoft - ввиду самого привлекательного соотношения цена/качество. Наиболее технологически сложной, по словам внедренцев, оказалась интеграция с SAP R/3.
Созданная на основе интеграционной платформы универсальная система ведения и распространения НСИ в рамках всей группы компаний изменила многие процессы. Пользователи получили возможность работать с корпоративной НСИ через обычный Wеb-браузер (в соответствии со своими правами доступа), что значительно упростило ведение и распространение справочных данных. Существенно повысилась достоверность используемой информации, облегчился процесс сбора и обработки корпоративной отчетности в рамках группы компаний, поскольку она пересылается теперь в единых терминах. Намного меньше стало рутинных операций за счет сокращения времени, требуемого для заведения новой записи и модификации существующей, что в целом привело к повышению производительности труда.
ПОВЫШАЯ ЖИВУЧЕСТЬ, СОХРАНЯЯ ВЛОЖЕНИЯ
Статистика показывает, что кардинальная смена технологической базы в компьютерном мире происходит примерно раз в семь лет, но переход от одного поколения систем к другому не случается мгновенно. Поэтому зачастую на предприятиях одновременно функционируют системы трех-четырех поколений, основанные на MS DOS, EC ЭВМ, Unix, Windows 2000 и т. п. Не менее важно и то, что в них "зашита" разная философия построения ИС: одни базируются на Wеb-технологиях, другие - ПК-ориентированные (как, например, средства автоматизации бухгалтерии), а в третьих заложена жесткая клиент-серверная модель.
Перевод взаимосвязей корпоративных систем на общую интеграционную платформу позволяет управлять изменениями одного из приложений с минимальным влиянием на другие (независимо от их природы). В идеальном случае, когда все информационные подсистемы предприятия "насажены" на общую интеграционную шину, менять любой программный блок можно по принципу "черного ящика". Не имеет значения, как он устроен внутри, интеграционная шина сама общается с ним по интерфейсам входа и выхода. Очевидно, что жизнеспособность и гибкость корпоративного ИТ-фундамента при этом значительно повышаются. Интеграционная идеология ИТ порождает даже искушение объединить в своей КИС (хотя бы на время!) приложения, лучшие в своем классе (best of breed). И в последние годы такой подход составляет серьезную конкуренцию призывам ЕRР-вендоров отдать предпочтение интегрированной системе управления от одного поставщика (тем более что даже самый "полнофункциональный" e-business suite никогда не покрывает всех потребностей предприятия).
Интеграционная платформа, выступая в роли своеобразного демпфера и связующей прослойки, снижает риски и делает КИС реально управляемой, поскольку при ее использовании всегда известно, когда, где и как можно вносить изменения, и легко оценить их воздействие на смежные приложения. А главное - интеграционная платформа позволяет сохранить инвестиции, уже вложенные в корпоративную информационную систему <
***
Слово ИТ-ДИРЕКТОРУ
Вам часто приходится интегрировать?
Николай Петухов, начальник отдела информационных технологий Кировского шинного завода:
- Интеграцией мы занимаемся постоянно. У нас еще остаются задачи, решаемые с помощью Clipper и FoxPro, есть Оrасlе-приложения, теперь вот добавились решения от 1C. Нам приходится обеспечивать перенос данных между всеми этими системами. Проблема интеграции возникает тогда, когда нет единой корпоративной системы. Но стремиться к ее созданию, на мой взгляд, и не надо. Гораздо удобнее и проще (при разработке и использовании) распределенная система, в которой продумана интеграция данных между разными приложениями. Способ связи между ними в каждом случае мы выбираем индивидуально, специальной стратегии в области интеграции у нас нет - на ее разработку нужны деньги. Как ИТ-директору мне хотелось бы, чтобы разработчики ПО больше взаимодействовали друг с другом, делились информацией. Тогда и интегрировать будет проще.
*
Алексой Рубцов, главный технолог авиакомпании East Line:
- Интеграция приложений - одна из наиболее важных и трудоемких задач ИТ-службы авиакомпании. Комплексного решения под нашу специфику на рынке нет, отраслевые требования к ИС и формируемым в ней документам жесткие, поэтому приходится использовать большое количество разнородных информационных систем и платформ.Системно решить задачу интеграции пока не получается, создаем локальные интерфейсы между отдельными системами, используя стандартные средства - обмен файлами, формирование межсистемных запросов и сообщений. Рассматриваем возможность и целесообразность применения CRM как интегрирующего ПО промежуточного слоя. Неразрешимой остается задача интеграции унаследованных систем, контакт с разработчиками которых утрачен. Таких систем, к сожалению, много. Наверное, будем постепенно от них избавляться. Однако сделать это непросто, так как зачастую от функционирования ИС зависит безопасность полетов, и прерывать их работу недопустимо ни на минуту.
*
Виктор Живов,
ИТ-директор сети "Аптеки 36, 6":
- Вопросы интеграции приходится решать каждому ИТ-директору, хочет он того или нет. Я не знаю ни одной крупной и средней фирмы или банка, где эта проблема не стояла бы достаточно остро. Она возникает вследствие развития бизнеса, когда нужно выбирать оптимальные технологии работы компании. Обычно для интеграции разных информационных систем используются "шлюзы", через которые происходит обмен данными. Это может быть как простой экспорт/импорт файлов, так и специально написанные программы. Мне больше подходит первый вариант - в этом случае всегда можно "откатиться" назад с минимальными потерями. Стратегия же интеграции состоит в том, чтобы искать новые приложения на той же технической платформе, на которой работают другие прикладные программы. Если, конечно, на предприятии не решаются на замену всего старого ПО на новый интегрированный пакет. Впрочем, полная замена получается не всегда. В этой связи у меня одно пожелание к разработчикам ИТ-решений - предусматривать шлюзы для обмена данными с другими приложениями. У большинства их нет. Все готовы поставить комплексное решение для автоматизации, но у одних вендоров лучше реализована бухгалтерия, у других - товарный контур, у третьих - производственный и т. д.
*
Владимир Ануфриев, заместитель директора департамента ИБГ "НИКойл":
- Интеграция разнородных приложений - одна из основных задач ИТ-директора, особенно в крупной и быстрорастущей компании. И зачастую неразрешимые проблемы подстерегают его не на техническом, а на организационном и политическом уровне. Даже если на предприятии разработан детальный проект глобальной информационной системы, постоянно адаптирующийся к внешним условия, бизнес порождает частные неотложные задачи, которые могут не укладываться в общую концепцию. Приходится быстро создавать приложения и стыковать их интерфейсами, что способствует порождению неповоротливого "информационного монстра", пожирающего огромные ресурсы. Без стратегического плана строить корпоративные ИТ нельзя, а при проектировании приложений нужно учитывать возможность их последующей совместной работы в сложном комплексе (отсюда, кстати, исходит концепция открытых систем). В нашей группе прямые и косвенные затраты на интеграцию составляют не менее 10% всего ИТ-бюджета.
*
Сергей Долотов, начальник службы ИТ мебельной компании "Шатура":
- Конечно, интеграцией прикладных приложений заниматься приходилось, и не раз. Проблема эта связана прежде всего с традиционной "лоскутной" автоматизацией российских компаний, неготовностью высшего руководства менять все устаревшие системы в рамках единого проекта и динамикой развития бизнеса за последние пять-семь лет. В области стандартизации мы придерживаемся определенной стратегии. Для прикладного ПО - единая СУБД, обязательно мультиплатформенная. Клиентская часть должна поддерживать как минимум Windows и Linux и иметь "тонкого" Wеb-клиента. Максимальное использование инвариантных к операционной среде технологий (XML, Java). Для интеграции бизнес-приложений очень интересен продукт IBM WebSphere, но для нас это пока перспектива. Вообще, чем больше будет использоваться приложений с открытым кодом, тем проще решать задачи по интеграции. Правда, в последние годы наметился явный прогресс среди разработчиков программного обеспечения: оборудование и системное ПО стали понимать друг друга значительно лучше. Но остается много претензий к качеству и оперативности служб сервиса и технической поддержки поставщиков.
***
Даже самый "полнофункциональный" программный пакет никогда не покрывает всех потребностей предприятия
***
У предприятий появляется искушение объединить в своей КИС лучшие в классе решения
***
ВИДЫ ИНТЕГРАЦИИ И СПОСОБЫ ИХ РЕАЛИЗАЦИИ
Наиболее часто используются три подхода: интеграция при помощи систем обмена сообщениями, интеграция на уровне бизнес-процессов и на уровне пользовательского интерфейса.
Самый простой вариант - интеграция на уровне пользовательского интерфейса, обеспечиваемая корпоративными порталами. На персонализированной страничке портала размещаются рабочие интерфейсы разных приложений - пользователю не нужно переключаться с одного на другое в поисках задачи, необходимой для выполнения его бизнес-функции. Поскольку используется Wеb-интерфейс, отпадает необходимость разворачивать клиентский компонент на каждой машине и появляется возможность дистанционного доступа к приложениям. Еще одно удобство в том, что пользователю для доступа ко всей совокупности приложений нужно помнить всего один пароль (портальный) - пароли всех остальных программ "помнит" за него портал и применяет их автоматически. Однако порталы не обеспечивают реальной интеграции данных: информация в приложениях остается разобщенной. За обеспечение ее целостности отвечает другой элемент - межплатформенное ПО, именуемое системами обмена сообщениями (Message Oriented Middleware, MOM). Оно обеспечивает гарантированную доставку сообщений о событиях, происходящих в одних приложениях, в другие. В результате данные во всех приложениях, подключенных к системе MOM, оказываются всегда согласованными и актуальными. Однако в классических системах MOM трудно программировать бизнес-процессы. За решение этой задачи отвечают средства, обеспечивающие интеграцию на уровне бизнес-процессов. В самом простом варианте это комбинация систем управления потоками работ (workflow) и средств MOM, отвечающих за взаимодействие приложений. События, регистрируемые MOM, могут инициировать как обработку данных и документов внутри самой MOM, так и исполнение сложных контуров согласований, включающих в том числе работу с неструктурированными данными (например, служебными записками). В более сложных случаях вместо workflow используются системы управления бизнес-процессами (ВРМ), которые позволяют вести библиотеки версий процессов и описывать точки их стыковки с приложениями (на российском рынке из систем этой категории присутствует Ultlmus ВРМ Suite).
Одной из наиболее современных интеграционных концепций считается Enterprise Service Bus. В ней предполагается, что все приложения экспортируют свой функционал в виде Wеb-сервисов, а интеграционная шина хранит описание бизнес-процесса (последовательность вызова сервисов) и "дирижирует" обращениями к соответствующим системам. В качестве интеграционной платформы также часто используются серверы приложений, которые, помимо подключения имеющихся прикладных программ, позволяют создавать и новые Wеb-ориентированные приложения.
***
Интегрировать лучшее или Интегрировать лучше
Нина Новикова
Директор Департамента SАР-систем
TopS Business Integrator
Вопросы интеграции различных информационных систем давно и очень активно обсуждаются в специализированной прессе. Однако сегодня появился новый аспект этой проблемы. Еще относительно недавно необходимость интеграции рассматривалась в аспекте соединения старых систем, работающих на предприятии, с новым, более современным программным обеспечением, например с ЕRР-системами. Это актуально и сегодня: во-первых, внедрение системы путем "большого взрыва", с отключением всех старых систем, - это всегда большой риск, во-вторых, далеко не каждая ЕRР-система обеспечивает оперативный контур производства, оперативное цеховое управление так полно и удобно, как системы среднего уровня, МЕS-системы. Наконец, всегда остается необходимость интеграции ERP и АСУТП.
Но в настоящее время появилось еще одно направление интеграции, связанное с попытками объединения "лучшего опыта" различных систем. Возникло мнение, что при соединении отдельных блоков систем, лучших в своей области, можно получить более совершенный результат. Сам по себе этот тезис, по-видимому, справедлив. Действительно, каждая из имеющихся сегодня ЕRР-систем состоит из большого количества модулей (подсистем), качество которых с точки зрения глубины и удобства реализации соответствующих бизнес-процессов неравномерно: в одних более совершенен блок производства, в других - техобслуживания и ремонта оборудования, третьи отличаются хорошо организованным финансовым учетом, вопросами логистического обеспечения производства и т.д. Однако, на наш взгляд, внедрение системы, состоящей из блоков разных систем одного уровня, сопровождается высокими рисками, которые изначально предприятиями упускаются из виду.
Представляются очевидными несколько важных особенностей внедрения системы такого типа. Зачастую время, потраченное на разработку интерфейсов обмена данными между блоками различных систем, даже превышает время на настройку и адаптацию стандартной ЕRР-системы (хотя все производители декларируют наличие стандартных интерфейсов, их приходится адаптировать под конкретные проектные решения, конкретные виды документов и т.д.). Поэтому такой проект внедрения должен быть существенно более длительным на этапе осознания задачи и концептуального определения архитектуры будущей системы. Кроме того, любые будущие изменения бизнес-процессов или совершенствование отдельных подсистем обязательно приведут к необходимости изменения интерфейсов. То есть потребуются средства на поддержание интерфейсов в актуальном состоянии. А поскольку эти интерфейсы разработаны под конкретное предприятие, и решение в этом смысле эксклюзивное, возникает зависимость от специалистов, знающих данное решение. Поэтому при внедрении системы, построенной из блоков разных систем, должны быть гораздо более подробно документированы все проектные решения, результаты внедрения, разработанные программы, интерфейсы и пр.
Необходимо также увеличить время на проектирование системы. При таком подходе придется решать, в какую из подсистем целесообразно вводить данные в первую очередь. Соответственно, важным становится вопрос местонахождения единых справочников, обмена данными между подсистемами. Гораздо больше времени займет и интеграционное тестирование.
Наконец, для снижения рисков потребуется более длительная опытная эксплуатация системы. Значит, работать параллельно в старой и новой системах придется дольше, что увеличивает нагрузку на персонал и приводит к росту расходов на оплату сверхурочной работы. Таким образом, несмотря на умозрительную красоту идеи, внедрение такой системы - это, безусловно, тяжелейший труд, зачастую неоправданный для предприятия. В заключение хочется отметить: безусловно, существуют ситуации, когда интеграция необходима. Например, на многих предприятиях работают очень специализированные системы, обеспечивающие оперативный контур деятельности (фронт-офис). И в то же время необходима бэк-офисная система, в качестве которой может быть использовано стандартное, хорошо апробированное решение. Вот в этом случае интеграция обоснована. Но если необходимость интеграции обуславливается причинами политического характера или желанием создать идеальное в техническом плане решение, с точки зрения бизнеса это обычно не оправдано и ведет к потере времени, средств и значительному увеличению рисков при внедрении.
Графика:
