У каждого свои потребности. Вот почему отделы ИС все шире ведут поиск творческих путей построения интегрированных наборов приложений масштаба предприятия
Когда дело доходит до ввода в строй приложения масштаба предприятия фирмы Schlumberger (Хьюстон), Майк Капеллас не знает ни сна, ни покоя. Жизнь у директора отдела ИС была бы полегче, если бы какой-то один интегрированный набор приложений вроде R/3 фирмы SAP подошел бы для всех бизнес-отделов фирмы Schlumberger. К несчастью, это не так.
Большое подразделение компании в Хьюстоне Oil Field Service, находящееся в поисках универсального способа представления своей компании клиентам в любой точке земного шара, обратилось к услугам фирмы SAP, заменив свои громоздкие центральные системы материально-технического снабжения и работы с клиентами одной клиент-серверной системой R/3. В то же время в течение прошлого года остальные отделы фирмы Schlumberger отвергали интегрированные решения фирмы SAP и других фирм, поставляющих интегрированные решения. Вместо этого некоторые производственные отделы фирмы Schlumberger, в том числе группа Measurement Systems, предпочли действовать по методу “чемпион породы”, выбирая лучшие пакеты из наборов, предлагаемых поставщиками, и затем пытаясь объединить все это в одну систему.
Группа Measurement Systems, также находящаяся в Хьюстоне, - одно из тех предприятий (с каждым днем их становится все больше), которые считают, что готовые приложения “одного размера” не всем подойдут. Разные компании, от производителя лекарств American Cyanamid (Уэйн, шт. Нью-Джерси) до производителя микросхем Texas Instruments, пришли к выводу, что даже популярные пакеты масштаба предприятия вроде SAP или Oracle не могут обеспечить в каждом модуле наилучшую функциональность, производительность и соответствие требованиям бизнеса. Именно из-за этого они повели охоту за лучшими в своем классе модулями масштаба предприятия - даже если из-за этого на менеджеров отделов ИС, таких, как Капеллас, ложилось бремя создания и поддержки интерфейсов между различными системами.
Поставщики приложений масштаба предприятия вкладывают в этот процесс свою лепту, пытаясь сделать интеграцию “чемпионов породы” более простой и надежной. Однако до интеграции “plug-and-play” остаются еще годы. “Наблюдается рост интереса к подходу “чемпион породы”, поскольку и поставщики, и пользователи согласны, что один поставщик не может удовлетворить всем требованиям, - прокомментировал ситуацию Эрик Келлер, вице-президент Gartner Group (Стэмфорд, шт. Коннектикут). - Но впереди еще много работы”.
Лучший подбор
Подход “чемпион породы” предлагает менеджерам отделов ИС некоторые потенциальные преимущества, в том числе возможность подыскивать пакеты, наиболее удобные для их бизнес-процессов. Интегрированные системы типа SAP почти всегда легко конфигурируются, но способ обмена данными и информацией о процессах между модулями иногда неудобен для той или иной фирмы. Некоторые организации в этом случае стараются подогнать свои бизнес-процессы под стандарты SAP. Но кто-то этого сделать просто не может. Например, компания American Cyanamid пыталась внедрить SAP повсюду, пока не выяснилось, что это ПО не поддерживает метод, принятый в компании для выставления счетов-фактур клиентам и ведения счетов дебиторов по расчетам. После неудачных попыток добиться от фирмы SAP модификации модуля дебиторов по расчетам ее пакета R/3 компания American Cyanamid решила взять аналогичный пакет фирмы Computron Software (Рутфорд, шт. Нью-Джерси) и интегрировать его с R/3. Объединение прошло не без издержек: проект затянулся на три года.
По сравнению с одномоментной реализацией набора пакетов от одного поставщика подход “чемпион породы” снижает риск неудачи и уменьшает сроки выполнения проекта, создавая возможность более модульного развития возможности подхода к созданию новых клиент-серверных систем.
Именно это и требуется производственным подразделениям фирмы Schlumberger. Эти производители счетчиков и другого оборудования для коммунальных служб хотят заменить системы управления оборудованием и производством на базе AS/400 общими интегрированными приложениями, которые позволили бы их заводам во всем мире пользоваться одной и той же информацией. И при всем том эти производственные подразделения не хотят тратить время и деньги, необходимые для полной реализации SAP.
Вместо этого они решили интегрировать клиент-серверное приложение управления производством от фирмы QAD (Карпинтерия, шт. Калифорния) с программным обеспечением управления данными о продукции от корпорации Sherpa (Сан-Хосе, шт. Калифорния). Группа Капелласа может выпустить готовые приложения (вместе с двунаправленным интерфейсом QAD - Sherpa) за полтора года. Для сравнения: полная реализация SAP в производственном подразделении Oil Service должна занять три с половиной года, но уже сейчас наблюдается отставание от графика на шесть месяцев.
Бесконечный бизнес
Есть, конечно, и издержки. Самое плохое - то, что в настоящее время слишком мало готовых интерфейсов для продуктов разных поставщиков, предлагающих хотя бы минимально устойчивую интеграцию пакетов этих поставщиков. У различных модулей пакетов вроде R/3 используются одни и те же модели данных и процесса, что позволяет модулям беспрепятственно получать информацию без стыков практически в реальном времени.
И до недавнего времени поставщики, подобные SAP, не заботились о том, чтобы работники отделов ИС или другие поставщики могли без особого труда осуществлять интеграцию с их пакетами. Обычно они не публикуют сведения о моделях процессов и данных и не предлагают доступных и надежных интерфейсов высокого уровня. И разработкой, и поддержкой этих интерфейсов приходится заниматься самим сотрудникам отделов ИС. А это далеко не сахар. Из-за отсутствия надежных API построенные интерфейсы часто оказываются просто подпрограммами Кобола или Си, выполняющими обновление в пакетном режиме. “Поддержка таких интерфейсов - это полный кошмар”, - жалуется Капеллас, который пытался (но пока безуспешно) добиться того, чтобы QAD или Sherpa взяли на себя поддержку интерфейса, разработанного в фирме Schlumberger.
Помощи можно ждать только в том случае, если усилия по интеграции “чемпионов породы” поддержаны поставщиком. И даже SAP, компания, которой сейчас, быть может, наиболее выгодно исповедовать идею “единого поставщика”, начинает, по крайней мере, говорить о необходимости развивать среду для интеграции “чемпионов породы”.
Сейчас поставщики проявляют инициативу трех типов. На самом базовом уровне поставщики, такие, как SAP, Oracle, Computron и Baan, начали публиковать множество более надежных API и предлагают поставщикам дополнительных приложений использовать эти API для интеграции. Однако у этих API есть некоторые ограничения. Прежде всего поставщики (SAP, Oracle и др.) видят в них лишь средства для интеграции дополнительных приложений, которых нет в их основной системе. И поэтому они не только настроены на изготовителя, но часто поддерживают передачу пакетов данных только в одном направлении.
Второй, более масштабный подход к интеграции, подразумевает более серьезные отношения между поставщиками, договорившимися об интеграции своих приложений. Такой тип интеграции потенциально более полезен, поскольку поставщики часто согласовывают позиции и строят интеграцию на общих моделях данных и процессов. Такая интеграция “одного с одним” может обеспечить более тесные связи между системами, но она имеет свои проблемы. В частности, работники ИС вынуждены ограничиться интеграцией приложений тех поставщиков, которые между собой договорились.
Третий подход к интеграции приложений масштаба предприятия, основанный на промышленных стандартах, может дать менеджерам ИС истинную свободу выбора при подборе и соединении “чемпионов породы”. Наиболее многообещающий из этих стандартов предложен появившейся год назад группой Open Application Group (см. заметку ниже).
К великому сожалению Майка Капелласа из фирмы Schlumberger и других менеджеров ИС, пытающихся осуществить интеграцию “чемпионов породы”, им не приходится в ближайшее время рассчитывать на облегчение своей жизни.
Джефф Моуд
Возьмите оба! Капеллас, сотрудник фирмы Schlumberger, при проектировании системы масштаба предприятия применяет два подхода
ПРИВЯЗКА
Вот как поставщики приложений масштаба предприятия интегрируют свои продукты:
Связи между приложениями на уровне 3GL. Эти связи, написанные обычно на Коболе или на Си, часто плохо масштабируются.
Стандартные API. Хорошо работают с однонаправленным потоком пакетов данных, но рассчитаны на конкретного поставщика; кроме того, их обычно трудно поддерживать.
Возможности СУБД, такие, как хранимые процедуры и триггеры. Их трудно поддерживать, они обычно сложно организованы из-за различий между разными СУБД.
Стандарты RPC или внутренние вызовы. См. выше “Стандартные API”.
Связи с помощью технологий встраивания и связывания объектов (OLE) и динамического обмена данными (DDE). Полезны для приложений, ориентированных на клиента, но не масштабируются.
Интеграция в документообороте. Удобно для документоориентированной интеграции. Не масштабируется, и к системам, управляемым транзакциями, неприменима.
Обмен сообщениями между объектами. Многообещающее направление, но пока недостаточно разработанное.
Источник: фирма Gartner Group.
ЛУЧШЕ ПОДСТРАХОВАТЬСЯ, ЧЕМ СОЖАЛЕТЬ
Эти вопросы помогут вам определить, стоит ли вам рассчитывать на преимущество в конкурентной борьбе за интеграцию по методу “чемпионов породы”:
- Кто будет отвечать за поддержку интерфейса? Оговорена ли эта поддержка формальным соглашением о партнерстве?
- Будет ли интеграция связывать системы на уровне бизнес-процессов и моделей данных?
- Есть ли план перевода этого интерфейса в объектную технологию? Есть ли план перехода на стандарты типа того, который разрабатывается группой Open Application Group? Являются ли ваши поставщики членами OAG?
- В какой степени дополняют друг друга рыночные стратегии двух поставщиков? Возникнет ли в ближайшем будущем конкуренция между ними?
- Синхронизируют ли ваши поставщики свои графики выпуска новых продуктов? Если нет, то поддержка интерфейса может отставать от выхода новых версий
