CC BY
62
вознаграждения по результатам работы корпорации, не оставляя без внимания аргумент зависимости величины дохода учредителей от эффективности работы всех подразделений корпорации.
Список литературы
1. Абалкин, Л. И. Экономическая энциклопедия / Л. И. Абалкин / науч.-ред. совет изд-ва «Экономика»; Ин-т экономики РАН. М : Экономика, 1999. 1055 с.
2. Турков, И. Б. Стратегический менеджмент организации: учеб. пособие / И. Б. Турков. 2-е изд., испр. и доп. М.: ТЕИС, 2004.239 с.
3. Некипелов, А. Д. Популярная экономическая энциклопедия / А. Д. Некипелов [и др.]. М.: Большая рос. энцикл., 2001.367 с.
4. Цуглевич, В. Н. Корпоративный менеджмент в условиях нестабильного рынка / В. Н. Цуглевич / под общ. ред. Н. П. Тихомирова. М.: Экзамен, 2003.320 с.
Л. Л, Решетников
ПРОБЛЕМЫ ПОСТРОЕНИЯ И ПОВЫШЕНИЯ ЭФФЕКТИВНОСТИ ВНЕДРЕНИЯ КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ В ЭКОНОМИКЕ
Рассмотрены вопросы использования информационных технологий, особое внимание уделено программным продуктам, каждый из которых рассматривается как самостоятельная управленческая система. Исследуются принципиальные основы построения ЕКР-систем. Изучен механизм построения информационного пространства предприятия и основные вопросы, с которыми сталкиваются предприятия при его реализации: проблемы интеграции и взаимосвязи интерфейсов между системами, использование новых технологических решений, недостатки готового тирсююного программного обеспечения, выбор прикладной платформы.
Современный бизнес, в том числе и бизнес, основанный на высоких технологиях, трудно представить без всестороннего присутствия в нем решений с ключевым использованием информационных технологий (ИТ). Согласно исследованиям известной консалтинговой фирмы МсКшзеу, главной причиной низкой производительности труда (19 ^ от уровня западной), низкой конкурентоспособности и прибыльности отечественных компаний является прежде всего неудовлетворительное качество управления, которое во многом обусловлено отсутствием целостной корпоративной системы управления (или корпоративной информационной системы — КИС), объединяющей все информационные ресурсы компании. С одной стороны, современная система управления является эффективным механизмом функционирования хозяйствующего субъекта, а с другой, выступает еще и своеобразным гарантом для инвесторов, демонстрируя минимум возможных управленческих ошибок при эффективном вложении средств. Наряду С несомненной позитивной составляющей этого процесса присутствует обратная сторона явления, вместе со стремлением как можно больше «информатизировать» все вокруг демонстрируется безоглядная преданность прогрессу 176
Наипервейший вопрос, чаще всего присутствующий в дискуссиях заинтересованных лиц на тему КИС, является ли тот или иной продукт корпоративной информационной системой?
Действительно, может ли программный продукт быть системой управления? Вопрос риторический. Очевидно, что, в крайнем случае, ответ на него может быть основой решения для создания системы. Однако этот вопрос возник не сегодня. Появление понятия
КИС связано с осознанием того, что корпоративное информационное пространство_______
нечто достаточно сложное, а не просто совокупность нескольких программ.
Первоначально пришло осознание того, что это некая интегрированная среда обработки данных (отсюда другой термин, более частный, но в целом столь же размытый — интегрированная информационная система). Затем постепенно сформировалось понимание того, что это не просто среда обработки данных, а прежде всего совокупность методов и подходов к управлению разнородными и разноформатными данными, извлечению информации из имеющейся в фирме информационной системы в формах, необходимых для обеспечения деятельности по управлению предприятием. При этом достаточно долго существовало (и присутствует по сей день) стремление объединить эти методы и подходы в едином программном продукте. Исторически, вначале это не были продукты типа систем управления ресурсами предприятия, как это пытаются представить сейчас, а это были системы управления базами данных (СУБД). В наибольшей степени обозначенный подход нашел свое логическое завершение в спектре продуктов и решений, предлагаемых компанией ORACLE.
Основная масса приближенных и заинтересованных лиц ассоциировала (многие продолжают делать это и по сей день) КИС с Enterprise Resource Planning (ERF)—системой управления и планирования ресурсов.
Первые принпиття ттьшле основы построения ERP-систем были выдвинуты еще в 1950-е гг., однако, по ряду объективных причин, эти системы не получили развития. Они существовали как теории, красивые модели, которые не могли быть воплощены в жизнь не столько из-за недостаточного уровня развития информационных технологий, сколько в силу принципиальных отличий в подходах к организации бизнеса в середине прошлого века и сегодня. Появление первых коммерческих образцов ERP-систем приходится на 1980-е гг., чему способствовало несколько факторов (причем трудно определить, какой из них является причиной, а какой следствием). Прежде всего уровень развития информационных технологий был уже достаточно высок для построения распределенных систем управления бизнес-процессами. Во-вторых, огромную, если не решающую роль, сыграли всё усиливающиеся процессы глобализации, вывод произ водств ведущих компаний из развитых стран в Азию. Европа становилась финансовым И управленческим центром, который должен был осуществлять оперативный контроль над своими производственными мощностями, расположенными на другом континенте.
Своего наибольшего развития ERP-системы достигли в 1990-е гг. Именно тогда они перестали бьиъ просто бизнес-инструментами и превратились в объекты моды. Считается, что любая уважающая себя компания обязательно должна иметь *
по крайней мере, CRM-систему (Customer Relationship Management "
нйя продажами). Ведь эффект от ее внедрения обещается просто пор^ бизнес де-
^ть значительная доля правды, так как ERP-система полностью «о аудита
его прозрачным, что высоко ценится в наше время. Так, при Д
деятельности компании отсутствие брендовой ERP-системы, мягк Р > ^
в плюс. Тогда же выявились и ведущие компании отрасли — БАР и Огасіе, которые вступили в непримиримую борьбу между собой. Именно решениям на базе этих компаний принадлежит две трети всего рынка ЕИР. Отдельно стоят решения на платформе ВААЫ и т. д. (см. табл. 1),
Таблица 1
Рейтинг разработчиков ЕКР-систем по объемам проводимых работ (по данным сайта NASDAQ)
Рейтинг Система Разработчик
1 R/3 SAP
2 Oracle Applications Oracle
3 J. D. Edwards ID. Edwards
4 Baan Baan
5 Vantage, Platinum SQL Epicor Software
6 IFS IFS
7 MFG/PRO QAD
8 Exact Exact Software
9 SyteLine Symix
10 iRenaissance.ERP Ross Systems
И Navision Financials Navision
Следует отметить, что стремление получить всё в одном продукте было вызвано поныне существующей проблемой высокой стоимости поддержки разнородной информационной среды (теперь получившая расширенное определение в виде проблемы «совокупной стоимости владения»; ТСО — Total Cost of Ownership). Особенно это проявляется на стадии «заказных» продуктов, стоимость поддержки которых возрастает существенно нелинейно при необходимости поддерживать одновременно несколько разнородных, к тому же взаимосвязанных продуктов (тем более — сред разработки).
На сегодняшний день с достаточной долей достоверности можно сказать, что в состав инструментов управления и обеспечения деятельности серьезного бизнес-объекта (фирмы или предприятия) могут входить решения для создания информационного пространства со следующими компонентами;
• система управления и планирования ресурсов предприятия (часто используемое, но также не вполне корректное определение: ERF—Enterprise Resource Planning);
• система управления распределенной логистикой (как вариант; SCM-система — Supply Chain Management);
• система управления планово-предупредительным ремонтом (ППР) и послепродажным обслуживанием;
• система информационной безопасности;
• система управления данными об изделиях на производственных предприятиях (PDM — Product Data/ Definition Management);
• CAD (Computer-Aided Design) — конструкторская система;
• CAM (Computer-Aided Engineering) — расчетная система;
• CAE (Computer-Aided Engineering) — система проектирования обработки изделий на станках с числовым программным управлением;
• система документооборота (docflow);
• система организации рабочего пространства (workflow);
• система электронной коммерции (e-commerce); *
178
• система управления информационными ресурсами;
• система data warehouse (хранилища данных);
• система извлечения данных (data mining);
. система оперативной аналитической обработки данных (OLAP—Online Analytical Processing*);
• система представления данных для анализа руководством (MIS);
• специализированные рабочие места автономных пользователей;
• системы моделирования и представления бизнес-процессов;
• системы математического и имитационного моделирования процессов;
• системы математического (в том числе статистического) анализа данных;
• специализированные продукты или системы для реализации частных задач.
За каждым из компонентов может скрываться целый список программных продуктов и методов управления ими. Причем список не может считаться окончательным и может быть дополнен в любой момент времени.
В такой ситуации ни один продукт не может претендовать на возможность единоличной реализации каких-либо задач, относящихся к ведению КИС, включая SAP R/3.
Затраты на интеграцию связаны с разработкой интерфейсов между системами и их дальнейшей поддержкой. Затраты на разработку могут составить 20-30 % стоимости решения, а ежегодные затраты на сопровождение составят 10-20 % от общих затрат на интеграцию. Эти затраты зависят от количества бизнес-единиц, бизнес-процессов и интегрируемых систем, каждая из которых имеет (и будет иметь) собственную поддержку и план смены версий. Согласно исследованиям Gartner Group, 2000 самых больших компаний в мире используют в среднем 49 различных приложений программного обеспечения (ПО) и тратят около 24 млрд долл., чтобы обеспечить взаимосвязь различных систем.
1. Корпоративные информационные системы: новые решения в технологиях.
В области ИТ существует еще ряд постоянно дискутируемых вопросов. И один из них такой: «Покупать ли готовое или разрабатывать свое?» Довольно часто ответы на вечные вопросы сменяют друг друга с определенной последовательностью. Если в 1980-е гг. всё разрабатывали сами, то в 1990-х возможность покупать готовое ПО казалась решением многих проблем: не надо писать техническое задание, тестировать и т. д. Однако вскоре поняли, что с приобретенной готовой системой, даже самой замечательной и грамотно выбранной, с хорошими консультантами, далеко не всё получается так, как хотелось бы. На очередном новом витке старый ответ основывается на новых доводах—новых стандартах, технологиях и опыте. Вот и сейчас в вопросе «покупаем готовое или разрабатываем свое» наблюдается переход на новый уровень. Традиционную дилемму можно сформулировать следующим образом: «Покупать ли ширпотреб или приобретать готовое базовое ПО, из которого можно бистро и качественно получить индивидуальное решение?»
2. Недостатки готового тиражного ПО,
Если еще совсем недавно крупнейшие поставщики рынка ПО обещали предложить чюй набор программных компонентов, из которого любой заказчик мог бы со°Р^ Для себя комплект, покрывающий все его потребности, то се ас стало п
кяцне:
• разнообразие стоящих перед различными компаниями
* позволяет реализовать унификацию программных систем > было ран ^
• гибкость программных решений приобретает всё большее >
Инфицированные решения практически не бывают гибким; ^
* настройка бизнес-процессов компаний на бизнес-процессы, заложенные в готовом программном решении, затратна, дорогостояща и редко заканчивается успехом, удовлетворяющим заказчика;
* потребности бизнеса всё чаще вынуждают предприятия отстаивать индивидуальность своих программных решений;
* готовые решения позволяют предприятию создать «кусочную автоматизацию», но не дают построить полноценную архитектуру программных систем, закрывающую потребности в управлении ресурсами.
Один из сложных вопросов — как построить такое программное обеспечение, которое можно было бы менять параллельно с изменениями в компании? Всего за несколько месяцев (незначительный временной промежуток в деле разработки серьезной системы) с момента составления технического задания работа настолько может измениться, что к ее ИТ-поддержке предъявляются совсем иные требования.
Заказчики всё больше ощущают необходимость в гибком и масштабируемом ПО и ждут от поставщиков таких корпоративных информационных систем, которые могли бы достаточно быстро подстраиваться под их изменяющиеся требования.
3. Прикладная платформа.
Качественные события в мире программного обеспечения уже начались. От трехуровневой распределенной архитектуры наметился постепенный переход к так называемым прикладным платформенным архитектурам. В ИТ утверждается новое понятие— прикладная платформа. Прикладная платформа не является открытием последних лет. Во всем известной модели OSI (Open System Interconnection) понятие «платформа» активно используется. Мало того, там присутствует несколько типов платформ, в том числе и прикладная, определяемая как иерархия функциональных блоков сеансового, представительского и прикладного уровня, то есть трех верхних уровней модели OSI.
Текущее понимание прикладной платформы предполагает, что это ПО, предназначенное для проектирования, разработки, выполнения и модернизации программных компоненту автоматизирующих деятельность конкретных предприятий. Иными словами, прикладная платформа — это то, из чего собирается программная система «под себя». Причем с помощью прикладных платформ должны создаваться такие системы, которые потом могут изменяться в соответствии с переменами в конкретном случае существования бизнеса (в контексте идеологии «открытых систем»). Прикладная платформа неразрывно связана со всем жизненным циклом построенного на ней ПО и сама состоит из разнообразных взаимосвязанных компонентов.
Основные отличия таких прикладных платформ от настраиваемых программных систем заключаются в следующем. Прикладная платформа позволяет предприятию создать ПО «под себя», а настраиваемая система только выбрать один из нескольких предопределенных вариантов. Конкретные параметры у каждого предприятия свои, и когда мы говорим о готовом приложении, то по сути дела настройка на них — это выбор варианта. Если речь идет о внедрении крупной корпоративной системы, то предприятию обязательно приходится подстраивать под неё свои бизнес-процессы. Конечно, каждая уважающая себя тиражируемая система имеет API (Application Programming Interface), на котором можно разрабатывать дополнительные компоненты. Однако в рассматриваемом случае уже можно говорить о настраиваемой системе, которая выступает именно как прикладная платформа. Кроме того, в этом случае заказчик вынужден платить за готовое решение, хотя практически приобретает платформу.
180
Прикладная платформа предполагает широкие возможности по развитию созданного на ее основе ПО. Она позволяет добавлять программные компоненты, переписывать и развивать их. Это обеспечивает эффективную структуру совокупной стоимости владения, когда на первом этапе мы можем ограничиться относительно небольшими затратами на закупку собственно прикладной платформы, разработку и внедрение ядра системы, а потом — развивать базовое решение. Если же компания внедрила готовое монолитное решение, то проводить изменения и перестраивать параметры крайне трудно.
Преимуществ у такого подхода несколько. Прикладная платформа позволяет, с одной стороны, существенно сократить сроки разработки ПО, а с другой—повысить его индивидуальность, уровень соответствия потребностям компании, ее стратегическим и оперативным задачам, запросам сотрудников и других заинтересованных лиц. Появляется возможность увеличить гибкость ПО, управляя отдельными сервисами;
• техническими, общими для многих программных систем, такими как обеспечение безопасности, поддержка транзакционной целостности, обработка событий, управление сообщениями;
• прикладными, определяемыми конкретной функциональной областью предлагаемой платформы.
Необходимо отметить, что прикладные платформы всё чаще разрабатываются для отдельных функциональных областей, например для управления ресурсами предприятия, телекоммуникационных процессов или поддержки клиентов и пр. Обычно они включают в себя также средства мониторинга программных компонентов и управления их выполнением. Это особенно существенно с учетом непрерывного усложнения программных приложений, свою лепту в которое вносит добавление в корпоративную архитектуру слоя прикладных платформ.
Таким образом, всё более популярной становится новая идеология создания программных систем: покупаем полуфабрикат (прикладную платформу), на основании которого проектируем и собираем собственное программное решение, а в дальнейшем по мере необходимости развиваем и расширяем его. Всё это сильно отличается от ситуации, когда решаются краткосрочные задачи с наименьшей затратой усилий или покупается готовый дорогостоящий продукт, очень тяжело внедряется, а потом все нововведения обязательно проверяются на возможность их поддержки во внедренной системе.
4, Типы и характеристики прикладных платформ.
Прикладные платформы можно разделить на два вида: технические и функциональные. Первые в простейшем варианте представляют собой развитые средства разработки (например, на Java, и тогда сюда же следует отнести виртуальную машину Java, необходимую для выполнения разработанных программ). Подобные платформы годятся Для создания прикладного решения в любой функциональной области, на них можно построить что угодно. В некотором смысле это просто развитые средства разра отки. Вторые обычно включают функциональные компоненты, автоматизирующие отдельные функции бизнес-процессов в определенной предметной области. В этой о ласти функци овальная платформа предлагает программные компоненты, которые можно использовать
в программном решении с простейшими настройками. -„„«л
В свою очередь, технические прикладные платформы молено разделить на нес
■капов:
• по поддерживаемым операционным системам и программным языкам;
• возможностям расширения и добавления новых компонентов.
Функциональные прикладные платформы также можно разделить на несколько типов:
• по охватываемой функциональной области (чем уже область, тем более «готовые» программные компоненты могут в нее входить и, значит, тем проще создание ПО на такой платформе);
• объему и качеству предоставляемых технических и функциональных сервисов;
• уровню предоставляемых средств построения ПО (от высокоуровневого моделирования до написания кода на языке программирования).
В качестве основных специфических характеристик прикладных платформ упомянутых типов надо назвать следующие:
• зрелость платформы (насколько быстро и просто можно разработать на ее основе готовое ПО);
• функциональные границы (какого типа ПО можно на ее основе создавать);
• простота (насколько быстро и просто можно ее освоить).
Уже сформировались стандарты прикладных платформ: В качестве наиболее популярного стандарта необходимо назвать Java 2 Platform Enterprise Edition—стандарт, объединяющий J2EE Application Server, J2SE и средства разработки и построения программных систем в стандарте J2EE и веб-сервисов.
Другим стандартом, к которому часто обращаются разработчики прикладных платформ технического вида, является технология CORBA (Common Object Request Broker Architecture — общая архитектура брокера объектных запросов), в частности протокол ПОР и объектные сервисы. Прикладные платформы функционального вида всё чаще строятся на основе стандартов бизнес-процессов, относящихся к области ВРМ (Business Process Management). К наиболее популярным стандартам этого типа относятся BPEL (Business Process Execution Language), BPML (Business Process Modelling Language) и BPMN (Business Process Management Notation). В списке стандартов, лежащих в основе прикладных платформ, необходимо упомянуть также SOA (Service-oriented Architecture) как идеологическую основу построения многих прикладных платформ.
Основными участниками рынка универсальных прикладных платформ, а именно платформ, не привязанных к отдельной функциональной области, являются IBM (Web Sphere), BEA (Web Logic), Oracle (Application Server). К числу других следует отнести Cordys, InterSystems, Novell, SAP и Sun Microsystems (данные взяты из отчетов Gartner Group). В отдельных функциональных областях имеются свои разработчики; например SAP является лидером в области прикладных платформ для управления ресурсами предприятия. Кроме того, можно назвать Oracle и Microsoft. Однако надо сказать, что в целом рынок прикладных платформ всё еще довольно беден, и при выборе конкретного решения предприятие оказывается перед лицом существенных рисков и проблем.
При этом выбрать прикладную платформу оказывается еще труднее, чем определиться с тиражируемым программным решением. Дело в том, что здесь появляется еще одна степень свободы, связанная со специфическими свойствами прикладных платформ, описанными выше, и прежде всего с их зрелостью.
5. Прогноз развития моделей создания прикладных систем.
Рост популярности прикладных платформ вовсе не означает, что всё программное обеспечение будет строиться на их основе. Заказные или собственные разработки вовсе не собираются уходить со сцены. Существуют определенные, обычно узкоспециальные задачи, которые выгоднее и рациональнее разрабатывать на языках программирования, получая мобильные, легко обслуживаемые модули, Настраиваемые 182
программные системы также весьма привлекательны, конечно, в тех случаях, когда точно соответствуют потребностям предприятия, причем не только на момент внедрения, но и на некоторый период времени, в течение которого хотя бы окупятся затраченные на них средства.
Остановимся на развитии моделей создания прикладных систем (табл. 2), Существует несколько наиболее популярных и перспективных вариантов. Наблюдается тенденция активного развития и завоевания рынка прикладными платформами. Индивидуальная разработка при этом никуда не исчезнет. Однако не следует забывать, что для разработки бизнес-приложений собственными силами компания должна обладать очень высокой культурой в области информационных технологий.
Следующая модель создания прикладных систем — автоматическая генерация кода на основе построенных, решений. В России к идее автоматической генерации кода относятся прохладно, однако в других странах мира у нее есть много приверженцев. Такая модель, несомненно, имеет право на существование в силу высокой скорости и удешевления процесса разработки, и она будет развиваться дальше, особенно для тех задач, где не требуется очень высокое качество программного кода. Ситуации, когда время важнее качества, встречаются нередко.
Третья модель — низкоуровневая или техническая платформа. Она уже сейчас широко применяется для создания критически важных для бизнеса приложений, например биллинговых систем. Несомненно, что для такой модели уровень развития ИТ в компании должен быть также достаточно высок, поскольку ее поддержка предполагает высокую квалификацию персонала. В ближайшие годы эта модель будет основой для большей части программных систем, однако в дальнейшем она уступит позиции двум следующим моделям. ■
Четвертая модель—функциональная платформа с набором готовых прикладных сервисов и инструментарием прикладной разработки. Часть приложений уже сегодня делается на таких платформах, например многие популярные системы документооборота. Уровень ИТ в компании дня этой модели также должен быть высоким, потому что создание программного решения на такой платформе обычно сопровождается разработкой Дополнительных специфических компонентов.
Пятая модель — функциональная прикладная платформа с набором готовых модулей и шаблонов пользовательских интерфейсов, позволяющая собрать программное ре-тение без программирования,— в будущем может стать основной моделью для создания приложений в средних и крупных компаниях, не имеющих своих сильных ИТ~
подразделений, „
Наконец, шестая модель — тиражируемая программная система — также уйдет с рынка. Такие системы будут использоваться мелкими и средними компаниями для относительно быстрой автоматизации отдельных стандартных задач. Однако к ним удут предъявляться строгие требования по гибкости и интеграционным возможностям.
Грамотная архитектура слоя программных приложений должна нредставлята с гармоничное сочетание трех основных типов программных решени . настраив
-«дачи ИЦ методика поитрисиил ......✓ -
поящих перед ИТ, выделяются те, которые покрываются готовым
Жайшие годы не потребуют существенных изменений, остальных ПОДХОдят
кРУпные функциональные «подвижные» части, для которых наилу
Модели создания прикладных систем
Тип ПО Тип приложений Бизнес-требования к ПО ТОО Тип компаний Уровень развития ИТ в компании Перспективы
Индивидуальная разработка с использованием библиотек классов различных типов Отдельные узкоспециализированные функции, приложения реального времени, драйверы устройств Реализация специальных требований и уникальной функциональности Высокая Разработчики прикладных программных систем Высокая культура разработки Область использования будет постепенно сужаться, но не исчезнет
Автоматическая генерация кода на основе построенных моделей Некритические приложения; по мере развития и совершенствования инструментов автоматической генерации расширение области использования Время важнее качества Высокая Мелкие компании-разработчики, выходящие на рынок; подразделения ИТ с высокой квалификацией Высокий Будет активно использоваться для нестандартных задач
Низкоуровневая платформа, сервер приложений с основными «системными» сервисами Критические для бизнеса приложения Необходимо высокое качество системных функций, устойчивая и надежная работа приложения Средняя Крупные и средние Высокий Станет основной для высокотехнологичных малых н средних компаний с уникальными бизнес-задачами
Функциональная прикладная платформа с набором готовых прикладных сервисов и инструментами прикладного конструирования—сборки, конфигурирования, описания процессов, а также пользовательских интерфейсов Интеграционные решения, веб-приложения, порталы, системы типа workflow Уникальность и сложность объекта автоматизации Средняя Крупные и средние Очень высокий Станет основной для развитых средних и ' крупных компаний
Функциональная прикладная платформа с набором готовых модулей и шаблонов пользовательских интерфейсов, позволяющая собрать программное решение без программирования Корпоративные приложения, сочетающие как стандартные (например, выполнение требований законодательства), так и уникальные бизнес-процессы Сложный и большой функционал при ограниченном времени на создание и внедрение системы Средняя Крупные и средние Средний Станет основной для средних и крупных компаний, не имеющих сильных ИТ-подразделений
Тиражируемое программное решение с настройками . Стандартный функционал (веб-сайты, системы дистанционного обучения, бухгалтерия, налогообложение) Простота использования и поддержки, скорость внедрения Низкая Средние и малые Низкий Станет основной для мелких компаний или компаний с низким уровнем ИТ
прикладные платформы. Оставшиеся отдельные задачи реализуются на выбранных платформах, а если это неэффективно, то путем разработки в программных кодах.
Не стоит вести споры о том, какой путь лучше — заказная разработка, готовое тиражируемое решение или нечто промежуточное. Корпоративная архитектура современного предприятия объединяет различные подходы, а современные стандарты и технологии умеют сочетать разные программные решения для построения единой прикладной среды предприятия.
Строительство этой информационной единой прикладной среды предприятия становится сложным процессом создания решений из программных продуктов и их горизонтальной и вертикальной интеграции в единое решение. В крупных компаниях процесс «информационного строительства» столь тесно завязан с важнейшими управленческими процессами компании, что для руководства им нужен менеджер соответствующего уровня из категории высшего менеджмента.
Обобщая, можно определить, что современная иерархия «системного строительства» упрощенно выглядит так:
• Продукты (компоненты).
• Интеграция компонентная.
• Решения (отраслевые или специализированные).
• Интеграция системная (интеграция частных решений). .
• Корпоративная система.
Поставщики интегрированных систем, как правило, дотягивают только до третьего Уровня данной иерархии, да и то очень очень редко.
Обратим внимание, что ведущие поставщики (не исключая SAP и BAAN) уже давно говорят о «переходе к компонентной архитектуре», пытаясь поднять свои решения до второго уровня «стандартно». Также интересно, что Gartner Group ставит условие компонентной интеграции (прежде всего с компонентами независимых поставщиков) как условие выживания «продукта XXI века», по крайней мере на рынке средних промышленных предприятий.
Третий и четвертый уровни — это удел независимых консультантов, причем именно независимых, так как часто приходится интегрировать продукты стратегических партнеров конкурентов или даже чисто конкурирующие продукты.
Что же касается интеграции пятого уровня, то более или менее универсальные услуги по созданию такого рода систем в состоянии предоставить только несколько компани во всем мире.
