Недостающее звено

Из статьи вы узнаете:

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

Но несмотря на повышенное внимание и сверхурочные часы работы, которых требует е-коммерция от руководителей и персонала ИТ-подразделений, бизнес-процессы компании контролирует другая «е-система» — ERP, система внутрифирменного ресурсного планирования. Действительно, как в больших, так и в малых компаниях это ПО обеспечивает своевременную отгрузку готовой продукции, ведет учет поступающих доходов и начисляет зарплату сотрудникам компании.

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

Расцвет электронных торговых площадок усиливает необходимость взаимного увязывания внутренних и внешних систем. Многие «видные» электронные рынки — такие, например, как торговая площадка, организованная группой ведущих компаний по автоматизации бизнес-процессов (возглавляется корпорациями Oracle и Commerce One), — столкнутся с беспрецедентными интеграционными проблемами. Если не удастся согласовать внутри- и межфирменные системы, то электронные рынки окажутся неэффективными — они не смогут выполнить своего предназначения (сокращения снабженческих издержек).

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

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

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

Барри Уэбер, вице-президент по вопросам технической инфраструктуры в онлайновом книжном магазине Barnesandnoble. com (Нью-Йорк), считает, что до появления электронной коммерции прикладные программы не нуждались в использовании общей информации. «Системы, по своей глубинной сущности, вырастают из необходимости решения определенной проблемы, а не из необходимости пользоваться общей информацией с другими системами, — говорит он. — Изначально они предназначались лишь для того, чтобы использовать хранящуюся внутри них информацию для решения стоящих перед ними задач».

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

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

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

«Чтобы сделать обе наши системы эффективными, нам нужно было добиться возможности их подключения к любой внешней системе», — указывает Дэннис Беннер, вице-президент и главный директор по информационным технологиям инженерно-строительной компании Fluor Corp. (шт. Калифорния). Он советует сначала определить, что именно система должна делать, а затем строить ее на основе этих требований.

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

Самостоятельное исполнение

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

Дэвид Рэмси, главный директор по информационным технологиям в компании PSS World Medical Inc. (шт. Флорида) — дистрибьюторе медицинских товаров, рассказывает о своем опыте следующее. Перед его ИТ-подразделением была поставлена задача соединить автоматизированную систему продаж и приложения для межфирменной электронной коммерции с системой внутрифирменного ресурсного планирования и сделать интегрированную систему доступной для торговых представителей компании, использующих портативные компьютеры. Целью проекта было создание системы, которая действует в офлайновом режиме, при этом периодически через Интернет проводится синхронизация с базой данных по товарной номенклатуре компании. Прежде всего привели в порядок несогласованные между собой базы данных и компьютерное оборудование компании — их стандартизировали на основе базы данных Oracle 8 и платформы HPUX. Затем клиентские интерфейсы из системы ресурсного планирования (это была ERP-система OneWorld B73.3 производства компании J.D.Edwards) встроили в приложения для е-коммерции и автоматизированной системы продаж.

Сотрудники PSS World Medical Inc. (PSSI) столкнулись с классической проблемой несовпадающих форматов данных и вынуждены были пригласить экспертов для установления взаимосвязи между различными форматами. Структуры таблиц в трех интегрируемых системах компании оказались различными; это означало, что файлы с большим количеством данных часто не могли быть корректно переданы из одной системы в другую. Более того, сотрудникам PSSI приходилось дважды создавать каждый интерфейс, поскольку в некоторых зарубежных подразделениях корпорации использовались сильно устаревшие системы.

Чтобы найти решение растущих проблем, PSSI «взяла в аренду» двух консультантов из фирмы J.D.Edwards, которые имели большой опыт в соединении форматов программного обеспечения своей компании с форматами других систем и в построении интерфейсов. В конечном счете совместными усилиями было создано программное обеспечение особого «промежуточного слоя» между ERP-системой OneWorld B73.3 и приложениями для электронной коммерции, доставляющее информацию из системы внутрифирменного ресурсного планирования в базу данных системы «бизнес — бизнес» (В2В).

«Как только в ERP-системе проводится трансакция, система-посредник отправляет параметры данной трансакции в В2В-систему и пополняет базу данных электронной коммерции, — отмечает Рэмси. — Это был стратегический шаг — мы приняли решение не настраивать свои приложения для е-коммерции на прямой доступ к базам данных ресурсного планирования». Отсутствие постоянной жесткой связи между двумя системами дает компании возможность проводить работы по поддержке ERP-системы, требующие ее периодической остановки, не прерывая круглосуточного функционирования В2В-приложений.

ИТ-менеджеров привлекает в самостоятельной реализации интеграционных проектов и то, что таким образом сохраняется полный контроль над процессом. Компания Barnesandnoble.com столкнулась с особенно тяжелой проблемой. Стоявшая перед ней цель — найти способ сцепления внутрифирменной Web-разработки с системой ресурсного планирования SAP R/3 — сама по себе была сложной, но к ней добавлялась необходимость иметь дело с огромным количеством данных по множеству товаров. Интеграция двух систем требовала организовать использование общей информации по 15 млн товарных наименований, включая финансовые данные и сведения о наличии товаров, поступающие в режиме реального времени.

Сотрудники ИТ-подразделения под руководством Барри Уэбера создали архитектуру типа «публикация и подписка» с применением электронного шлюза — специального интеграционного инструмента для внутрифирменных приложений, разработанного компанией Software Technologies. Этот шлюз является промежуточной системой, извлекающей данные из одной системы и преобразующей их в формат, совместимый с множеством других систем. Кроме того, е-шлюз был использован для построения интерфейсов, соединенных непосредственно с системой SAP R/3 в целях обеспечения контроля над потоками финансовой информации. Эту информацию Уэбер счел слишком важной для того, чтобы доверить ее методу «публикации и подписки»: «Иногда нужно иметь абсолютную гарантию того, что данные, выйдя из одной системы, будут доставлены в другую. «Публикация и подписка» все-таки разбивает этот процесс посередине». Если на карту поставлена полнота данных, советует Уэбер, необходимо построить интерфейсы с прямым доступом к ERP-системе, что позволит ИТ-сотрудникам контролировать поток данных.

Как и Рэмси, Уэбер предпочел свободу эксперимента, которую дало ему выполнение проекта силами самой компании. В то же время Рэмси пришлось пережить период напряженного ожидания того момента, когда выгоды интеграции проявились в полной мере, — на это ушло 18 месяцев, и перерасход составил 500 тыс. долл. К счастью, проект кардинально улучшил финансовые результаты компании — годовой оборот PSSI вырос на 75 млн долл. и достиг двух миллиардов. Кроме того, интеграция автоматизированной системы продаж в единую систему способствовала активизации деятельности торговых представителей — они получили возможность размещать и обслуживать те заказы, которые ранее шли через клиентский телефонный центр. Эти сдвиги, а также улучшение онлайнового обслуживания клиентов позволили компании сократить численность персонала телефонного центра почти наполовину.

Привлечение помощи

Несмотря на преимущества самостоятельного исполнения интеграционного проекта, многие небольшие фирмы или компании, не имеющие мощного ИТ-подразделения, предпочитают переложить основную часть работы на своего поставщика ERP-системы. Этот путь особенно характерен для тех фирм, чьи ИТ-подразделения не имеют ни опыта реализации крупных проектов интеграции своими силами, ни достаточных для привлечения внешних консультантов средств. Существующий в настоящее время дефицит специалистов по информационным технологиям может расстроить даже самые лучшие планы по внутрифирменному проведению проекта. Для многих компаний спасительным решением является передача исполнения на сторону (outsourcing), а именно поставщику прикладных программ, т. е. приобретение у поставщика системы ресурсного планирования совместимого приложения для е-коммерции. Именно этот случай имел место у Рика Да Прато, менеджера по внутрифирменным информационным системам в компании Alpha Industries Inc. (шт. Массачусетс). По его оценке, интеграционный процесс прошел совершенно гладко главным образом потому, что несколько лет назад, когда электронная коммерция только начинала развиваться, был сделан правильный выбор.

В мае 1995 г. компания произвела замену своей устаревшей ERP-системы на систему Point.Man компании PivotPoint (недавно, в декабре 1999 г., эта фирма была поглощена корпорацией Mapics). Да Прато сначала рассматривал возможность обращения к более известным поставщикам — SAP или J.D.Edwards, но выяснилось, что они заинтересованы в работе главным образом с клиентами из списка 500 ведущих корпораций, публикуемого в журнале Fortune, а не с такими небольшими фирмами, как Alpha (поставщик полупроводников и интегрированных микросхем для крупных корпораций, например Motorola).

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

«Мы передали им сервер и сказали: «Вот вам оборудование, нужно установить конфигурацию», — вспоминает Да Прато. — Они вернули его полностью сконфигурированным».

И к удивлению Да Прато, система заработала. Клиенты в Европе и Азии, которые раньше ждали ответов на свои запросы два дня, теперь получили немедленный доступ к информации о наличии товаров. По оценке Да Прато, стоимость проекта — включая расходы на компьютерное оборудование и программное обеспечение — составила менее 30 тыс. долл. Передача проекта на сторону высвободила силы ИТ-подразделения, насчитывающего всего 16 человек, для поддержки 700 пользователей, работающих в компании.

У Рона Полларда, главного директора по информационным технологиям в компании Specialized Bicycle (шт. Калифорния), такие же приятные впечатления от интеграционного процесса, проведенного силами компании-поставщика. В 1995 г. Specialized приобрела ERP-систему у корпорации Oracle. Сейчас компания использует производственный и финансовый блоки системы Oracle 10.7 и планирует модернизацию — установку Oracle 11i. Совсем недавно Specialized с тревогой обнаружила, что ее клиенты уходят к онлайновым конкурентам. В целях борьбы с этой неприятной тенденцией компания решила создать электронный магазин; предполагалось, что доля независимых партнеров компании в его капитале составит 51%.

Разработка такого магазина означала, однако, что нужно будет интегрировать приложение для е-коммерции с системой ресурсного планирования Oracle. Когда разосланные различным поставщикам предложения дать оценку стоимости интеграционного проекта вернулись со словом «миллион» на ценнике, компания (чей ИТ-персонал менее 10 человек) решила обратиться к Oracle. В итоге Specialized приобрела у Oracle приложение для электронной коммерции iStore, обеспечивающее как функционирование Web-витрины, так и отсылку информации в Oracle 10.7, а та, в свою очередь, направляет информацию о запасах готовой продукции в iStore — таким образом, клиенты имеют возможность контролировать прохождение своих заказов в режиме реального времени. Поллард также заручился поддержкой компании-партнера Future Next (шт. Виргиния), которая в сотрудничестве с Oracle осуществила внедрение программы iStore за 40 дней. Поскольку интерфейсы этого приложения совместимы с компонентами системы ресурсного планирования, построение клиентских интерфейсов оказалось ненужным. Не следует забывать, однако, что попытка интеграции iStore с другими ERP-системами, помимо Oracle, вряд ли была бы такой легкой.

Хотя компании с обеими «е-системами» от одного и того же поставщика жертвуют такими качествами, как развернутая функциональность и свобода создания своей собственной архитектуры, все же этот путь может стать спасительным для небольших ИТ-подразделений. Поллард подчеркивает, что его компания не смогла бы создать электронный магазин, не приобрети она у Oracle приложение для е-коммерции, которое относительно легко присоединялось к уже работавшей в компании системе планирования ресурсов. Однако и Поллард, и Да Прато признают, что они не заглядывали далеко вперед и не имели в виду электронной коммерции, когда выбирали поставщиков ERP-систем.

«В 1995 г. никто не мог догадаться, что мы получим столько выгод, — указывает Поллард. — Весь шум был вокруг внутрифирменного ресурсного планирования. Никто не предвидел развития е-коммерции».

Поллард и Да Прато также признают, что когда они выбирали ERP-системы, то и не предполагали возвращения к тому же самому поставщику для осуществления интеграционного проекта. Большинство крупных компаний уже определились с выбором ERP-поставщика (не имея привилегии избрать имеющего значительный опыт в разработке приложений для электронной коммерции), и у многих внедрение приобретенных систем уже закончено или процесс зашел так далеко, что возвращаться поздно.

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

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

«Все это перешло из области черной магии в область обычной напряженной работы», — подытоживает Беннер.

ОБ АВТОРЕ

Ли Пендер — старший обозреватель журнала CIO Magazine; e-mail: lpender@cio.com