Чтобы проект систем планирования ресурсов предприятия (ПРП) оказался удачным, необходимо начинать его реализацию с изучения бизнес-процессов и определения необходимых функциональных возможностей. При этом нельзя игнорировать и ключевые вопросы инфраструктуры. В этой статье сравниваются системы компаний Baan, Oracle и SAP.
Оценка компаниями пакетов уровня предприятия в архитектуре клиент-сервер, таких как R/3 компании SAP, комплект Applications компании Oracle или Triton компании Baan (называемый Baan V4) представляет собой задачу удвоенной сложности. В первую очередь необходимо понять, насколько полно приложения соответствуют либо могут быть адаптированы к производственным или организационным функциям предприятия. Это значит, что необходимо оценить, каким образом программное обеспечение управляет специфическими производственными и финансовыми процессами и можно ли настроить эти функциональные возможности в соответствии с требованиями предприятия, что само по себе весьма непросто.
В рассматриваемых комплектах многие функции совпадают, но все же эти комплекты отличаются друг от друга. К примеру, функции управления человеческими ресурсами имеются в R/3 и Oracle, но отсутствуют в Baan. Управление производством - ключевая функция для всех трех пакетов - в R/3 разнесена по нескольким модулям с широким диапазоном возможностей, в то время как Oracle и Baan группируют ее в одном модуле. Необходимо отметить, что некоторые функции существенно различаются даже в перекрывающихся областях. Если перечисленные вопросы рассматриваются на раннем этапе принятия решения, то другие проблемы можно отложить до самого последнего момента. Они связаны с технологической инфраструктурой: промежуточное программное обеспечение, обмен данными, инструментальная стратегия и тому подобное. Выбор R/3, Baan или Oracle часто означает адаптацию технологической инфраструктуры, присущей приложению в масштабах всего предприятия. Это может, например, повлечь за собой изменение корпоративной базы данных или стандартов промежуточного ПО в соответствии с требованиями пакета приложений. В других случаях это приведет к адаптации средств разработки приложений силами всего предприятия. В основном изменения технологической инфраструктуры в организации пользователей вызваны одним из этих пакетов приложений.
Организациям, предпочитающим постепенное изменение технологии или нуждающимся во включении в новую среду существующих приложений для систем клиент-сервер, а также наследуемых приложений, следует рассмотреть круг проблем, связанных с инфраструктурой, прежде чем окончательно выбрать пакет. Это может иметь решающее значение при рассмотрении дилеммы: плодотворные изменения либо коренной радикальный технологический переворот.
Мы исследовали три наиболее важных вопроса: связь с базами данных, промежуточное программное обеспечение и "родную" инструментальную среду.
Связь с базами данных
Понять, каким образом пакет организует поддержку базы данных и ее функционирование, крайне важно организациям, собирающимся работать с несколькими базами данных, что подразумевает доступ к более чем одному серверу реляционных баз данных.
Методы поддержки баз данных в SAP, Baan и Oracle существенно различаются. Каждый пакет имеет открытую стратегию в отношении работы с несколькими базами данных. Продукт Oracle, однако, в обычном режиме может взаимодействовать только со своей собственной базой данных. Baan и SAP обеспечивают связь с базами данных двух лидеров рынка в этой области: Oracle и Informix. R/3 и Baan не поддерживают архитектуру компании Sybase, поскольку эта база данных не обеспечивает блокировки на уровне записей, а оба пакета изначально ориентированы на наличие этой функции. С другой стороны, SAP и Baan недавно сообщили о поддержке SQL Server компании Microsoft, хотя вряд ли SQL Server сможет работать с крупными реализациями R/3 и Baan из-за предполагаемых ограничений на число пользователей, имеющих возможность одновременно обращаться к этой базе данных.
Важным критерием оценки пакета является поддержка нескольких баз данных, которую каждый пакет осуществляет по-разному. Baan V.4 - наиболее открытый из всех трех пакетов: один модуль в Baan может непосредственно обращаться к нескольким базам данных. (Реальных технических ограничений на действительное количество одновременно доступных баз данных нет, хотя практика показывает, что если их больше трех, то значительно возрастают накладные расходы на управление.) SAP R/3 предоставляет доступ к нескольким базам данных, но не из одного модуля. В случае с Oracle обращение к сторонним базам данных должно осуществляться через шлюз. Это обременительно и ограничивает скорость доступа к нескольким базам данных из пакета Oracle.
Некоторая зависимость от базы данных не всегда оказывается обременительной: независимость означает выбор, а выбор, в свою очередь, влечет за собой дополнительные сложности. Пользователи должны решить, что для них важнее: сохранить независимость и, возможно, пожертвовать простотой разработки и реализации (SAP или Baan), или предпочесть независимости тесную интеграцию и простоту применения (Oracle).
Магия промежуточного ПО
Промежуточное программное обеспечение становится важным стратегическим элементом, особенно в гетерогенных средах. В системах клиент-сервер большинства предприятий уже реализовано множество технологий, и для того, чтобы учесть все это разнообразие, три производителя, предоставляющие собственное промежуточное ПО, обещают пользователям определенную независимость в выборе аппаратного обеспечения, операционной системы, пользовательского интерфейса и сети. SAP назвала свое промежуточное программное обеспечение Basis, Baan предлагает свою версию B-Shell, а у Oracle есть SQLNet.
Basis выгодно отличается тем, что представляет собой одну из наиболее широко используемых технологий промежуточного ПО масштаба предприятия в сегодняшнем мире архитектур клиент-сервер: все 4000 инсталляций SAP R/3 являются инсталляциями Basis.
Basis - это сугубо внутренняя разработка SAP, поскольку в этой компании было решено, что существующие технологии промежуточного ПО не обладают достаточной функциональностью для того, чтобы соответствовать нуждам компании. Но так как Basis является собственным продуктом SAP, организациям, уже реализовавшим какую-либо другую коммерчески доступную технологию промежуточного ПО - Tuxedo, Encina, Distributed Computing Environment (DCE) или брокеры объектных запросов, - придется уделять должное внимание созданию корпоративного окружения, которое будет связывать промежуточное ПО этого класса с Basis. Накопленные знания и опыт пока не позволяют понять, как достичь такой интероперабельности, а SAP не создает другим производителям промежуточного ПО условий для работы с Basis.
Продукты SAP и, в меньшей степени, Oracle, в отличие от разработок Baan, не страдают отсутствием поддержки промежуточного ПО. Orbix функционирует на основе B-Shell и работает с Tuxedo и Encina.
Oracle занимает промежуточное положение среди пакетов. Компания не поддерживает какое-либо промежуточное ПО, монитор транзакций или брокер объектных запросов, разработанные независимой компанией, однако Oracle Applications может работать с Tuxedo и Encina. Это делает теоретически возможным объединение SQLNet с технологией монитора транзакций. Но компания, пытающаяся связать существующие приложения, базирующиеся на стороннем промежуточном ПО с Oracle Applications, должна тщательно изучить возможность такого взаимодействия.
"Родная" инструментальная среда
Хотя SAP, Oracle и Baan обеспечивают широкие функциональные возможности в своих пакетах, им почти всегда требуется некоторая настройка. Каждая из трех компаний предлагает свою собственную инструментальную среду. Ни один из производителей не считает важным поддерживать инструментальные средства сторонних производителей, имеющиеся на рынке, хотя некоторые накопили опыт использования своих инструментальных средств в этих окружениях. Часть трудностей, связанных с инструментальными средствами, состоит в том, что все три приложения разрабатываются с использованием их собственных языковых инструментальных средств 4-го поколения (4GL), и два, имеющие справочник данных - SAP R/3 и Baan, обеспечивают мощную связь между 4GL-средой и справочником данных. Недостаток любого стороннего инструментария в том, что он не может похвастаться такой прямой связью.
Использование "родных" инструментальных средств оказывает большое влияние на компанию-пользователя. В компаниях, где уже сложились внутренние стандарты на некоторые средства разработки, инвестиции в такого рода инструментарий не поднимут уровня разработки никаких других приложений. Для организаций, которые только выбирают стандарты для инструментальных средств, потенциально серьезным аргументом станет возможность применения инструментария этих производителей для разработки любого приложения, которому необходим доступ к данным или модулям приложения. Это значит, что большинству пользователей придется инвестировать значительные средства в обучение, и, таким образом, у них есть стимул использовать полученные знания в масштабах всего предприятия.
В этой ситуации Oracle имеет преимущества: он оперирует одними и теми же инструментальными средствами и для Applications, и для базы данных Oracle, а опыт разработки в Developer/2000 компании Oracle можно будет распространить в масштабах всего предприятия.
Заключение
Организациям, стремящимся осуществить в практике и технологии бизнеса широкомасштабные изменения, обеспечиваемые этими пакетами приложений, в процессе выбора необходимо как можно раньше понять важность вопросов инфраструктуры. Другой вариант - это передать управление корпоративной информационной технологической средой поставщику приложений.
Поиск компромисса
При выборе нужного пакета приложений возможно большое число альтернативных решений. Здесь перечислены некоторые советы, как учесть требования реальности в широкомасштабном мире приложений клиент-сервер.
Требование
Связь с базами данных
Вариант
Гетерогенность против простоты
Если вам важна простота или же продукция Oracle уже принята в качестве корпоративного стандарта, то Oracle Applications имеет значительное преимущество перед другими пакетами. Для создания более надежных систем, даже при использовании базы данных Oracle, рассмотрите R/3 или Baan. Если необходимо учитывать гетерогенность системы, то в первую очередь обратите внимание на Baan.
Требование
Промежуточное программное обеспечение
Вариант
Невысокая интероперабельность промежуточного ПО
Рассчитывайте на то, что придется поддерживать собственную технологию промежуточного ПО, от которой будет немного пользы для разработки распределенных приложений вне среды SAP или Baan.
Требования
Инструментальные средства разработки
Вариант
Вам нужно будет выполнять все разработки в "родной" языковой среде 4-го поколения
В отношении R/3 или Baan не ждите, что вам удастся использовать опыт работы с инструментальными средствами для разработки приложений вне пакетов. Опыт работы с инструментарием автономного Developer/2000 может пригодиться в других областях деятельности.
Требование
Открытость и строгое соблюдение стандартов
Вариант
План для компромисса
Что касается основных системных стандартов (например Unix, SQL), то здесь продукты R/3, Oracle и Baan более-менее одинаковы. Однако они сильно отличаются в области более специальных стандартов, таких как базы данных и пользовательский интерфейс. Для связи между модулями в пакете приложений стандартов не существует. Приготовьтесь к тому, что в некоторых случаях придется приспосабливать внутренние или корпоративные стандарты к пакету приложений.
Требование
Поддержка наследуемых систем
Вариант
Не рассчитывайте на интерактивный доступ
Если не принимать в расчет связь между SAP R/3 и SAP R/2, основанную на мэйнфреймах, о поддержке наследуемых систем не стоит и говорить. Пользователям, работающим с данными на мэйнфреймах, которые должны стать частью интерактивной среды приложений, придется рассмотреть возможность переноса или копирования этой информации в базу данных. К базе данных, в свою очередь, можно будет обращаться непосредственно из приложений.