In English

Корпоративный портал или мечта о красной кнопке

15.02.2002, Шагурина Нина
Издание: Сетевой
Полтора года назад мы говорили на страницах нашего журнала, что корпоративный портал - это решение, которое способно изменить лицо ИТ. Однако в России рынок порталов находится, пожалуй, на весьма ранней стадии развития. Ряд экспертов считает, что рынка как такового у нас нет, другие - более оптимистичны: поскольку спрос на портальные решения существует, существует и предложение, доказательством чего может служить присутствие на нашем "круглом столе" представителей шести компаний, имеющих опыт внедрения портальных решений на российском рынке. О том, что представляет собой российский рынок портальных решений для корпоративных клиентов, рассказывают гости нашего традиционного "круглого стола".

Владислав Шершульский, директор по развитию бизнеса EPAM Systems

Сергей Щербина, директор по маркетинггу ”Город Инфо”

Владимир Сизых, руководитель отдела маркетинга"Весть-Метатехнология"

Георгий Потифоров, менеджер проекта "Сервокомп”

Андрей Есенков, эксперт "АйТи”

Алексей Савельев, консультант IBM Business Consulting Services

ОПРЕДЕЛЕНИЕ

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

В. Шершульский: Когда мы говорим о рынке корпоративных информационных порталов, мы понимаем, что есть рынок продуктов, представленных соответствующими брендами, и есть рынок услуг по внедрению этих продуктов. Соответственно, собравшиеся играют на двух этих рынках. Если говорить о EIP (Enterprise Information Portal) как о продукте, то, хотя есть официальное определение, данное консалтинговыми компаниями, на мой взгляд, это в первую очередь - специализированный сервер приложений или расширение сервера приложений для поддержки спецификаций и набора методов (framework), позволяющих запускать компоненты, отображающие информацию конечным пользователям. Существует стандартная схема, которая описывает источник, способ употребления, правила доступа, способ показа, схему размещения каждого компонента. Чтобы портал был действительно "уровня корпорации", необходимо, чтобы он обеспечивал взаимодействие со стандартным мощным сервисом каталогов (Directory), для того чтобы обеспечить развитые средства администрирования и унифицированный контроль прав доступа на основе ролей. Желательно наличие предопределенного набора компонентов для связи с различными информационными подсистемами. В это определение часто добавляют мощный поиск, категоризацию, data mining и другие вещи, но сейчас я бы не стал относить их непосредственно к порталам. Это уже специфические решения, которые либо выделились в отдельные продукты, либо вошли в состав Enterprise Information Suite. Именно за такими комбинированными "сюитами", включающими сервер приложений, портальную инфраструктуру, сервер интеграции (Application Integration Server), сервер каталогов, СУБД, инструменты разработки и пр., а также за порталами, интегрированными с мощными ERP, на мой взгляд, будущее.

В. Сизых: Действительно, есть стандартное определение корпоративного портала, сформулированное Gardner Group и другими аналитическими компаниями. Если же встать на более жизненные позиции, то, наверное, корпоративный информационный портал - это прежде всего средство визуализации для сотрудников компании текущих задач. Корпоративный информационный портал призван помочь сотрудникам решать текущие проблемы. Функциональное его наполнение: поиск контента, поиск внутренних документов, CRM и управленческий анализ - это уже некий дополнительный функционал, наличие которого позволяет более узко классифицировать портальное решение.

К. Зимин: Но под это определение подпадает любое бизнес-приложение, визуализирующее информацию и помогающее решить некий набор задач.

В. Сизых: В портале есть модули, которые решают определенные задачи, будь то корпоративная почта, средства групповой работы или моментального оповещения. Все они сами по себе могут являться отдельными системами, но портал объединяет их в рамках единого окна. Получается, что мы уже работаем не в каком-то одном определенном приложении, а в среде, ориентированной на конкретную задачу. Это позволяет в одном окне просматривать финансовую отчетность, в другом -список текущих договоров, а в третьем - информацию из ERP-системы. Таким образом, портал позволяет интегрировать разные приложения корпоративной системы.

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

К. Зимин: Но ведь эту задачу традиционно решает система каталогов.

А. Есенков: Не совсем так - система каталогов не решает задачу аутентификации, а лишь поддерживает этот процесс. Если бы какой-нибудь продвинутый веб-сервер, например Netscape года 1996-го, содержал в себе функции поиска и каталогизации (а он содержал), то тогда это и был бы портал, по-вашему? Одна из задач портала - организация доступа к существующим информационным ресурсам. То есть портал должен интегрироваться с существующими системами, а поисковые системы и системы управления контентом должны уметь конвертировать эти документы в унифицированный формат.

С. Щербина: Мне наиболее близко определение, данное Владиславом, но я хотел бы добавить пару комментариев. Во-первых, портал - это прежде всего инфраструктурный продукт. Это не Application Server, хотя Application Server может быть одним из компонентов этого портала или портал может с ним взаимодействовать. Во-вторых, сегодня пока ни разу не прозвучало слово Web. Но портал - это инфраструктурный продукт, который обеспечивает работу веб-приложений, которые реализуются в порталах. Это среда для запуска Интернет-приложений - с одной стороны, и для организации унифицированного, управляемого, администрируемого доступа к различным информационным ресурсам и сервисам - с другой.

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

Г. Потифоров: С позволения собравшихся я введу некий образ - образ "Большой красной кнопки". Была у руководителей и топ-менеджеров такая мечта лет пять назад, на пике развития ERP-систем, - управлять с одного экрана сразу всем бизнесом: продажами, финансами, планами, бюджетами, ресурсами и персоналом. Упрощая, можно сказать, что именно для этого и предназначены новые портальные технологии.

А. Савельев: Я согласен с определением портала как средства доступа к корпоративным приложениям, информации и процессам. Можно сказать, что портал - это виртуальный рабочий стол, настроенный в соответствии с требованиями каждого сотрудника и доступный из любой точки. Если говорить об основных составляющих портала, то тут можно выделить инфраструктурные компоненты: сервер приложений и средства интеграции, а также функциональные блоки: средства Business Intelligence, поиск, каталоги, персонализация и др. Соответственно можно разделить на три группы и основных поставщиков решений. Первая группа - это средства интеграции. К ним относятся, например, продукты ВЕА Systems. Вторая группа - решения Vignette, Plumtree и Hummingbird, которые стоят выше в технологическом стеке и предоставляют пользователям расширенный набор функций. Третья группа - продукты, объединяющие инфраструктурные и функциональные компоненты. К ним можно отнести в первую очередь решения IBM, SAP, Oracle и Sybase.

ПРОБЛЕМА ВЫБОРА

Н. Шагурина: Рынок предлагает множество портальных решений. Перед руководителем предприятия проблема выбора встает очень остро. Как выбрать оптимальное решение? Какие критерии при этом руководитель должен рассматривать?

В. Шершульский: Руководители компании в последнее время иногда сознательно ставят проблему необходимости портала. Видимо, идея достаточно овладела массами корпоративных потребителей. Но чаще задача формулируется в терминах бизнеса - нужно обеспечить доведение поручений и контроль исполнения до сотрудников во всех подразделениях компании; нужно сократить время принятия решения менеджером, не упрощая регламент процесса; нужно сократить процент ошибок при оформлении налоговых документов в филиалах; нужно добиться, чтобы сотрудники постоянно имели перед глазами все необходимые им средства работы и информационные источники; нужно повысить управляемость компании и добиться ее сфокусированности на стратегии. Последнее требование часто формулируется как конкретная задача построения систем ключевых показателей эффективности (KPI - Key performance Indicators) и обеспечения к ним доступа заданных категорий потребителей (менеджеров, акционеров и других). Типичная российская ситуация, в которой часто происходит внедрение портала, - объединение группы разрозненных компаний в холдинг новыми собственниками.

Таким образом, выбор конкретного портального решения, как правило, остается на совести ИТ-консалтинговой, или бизнес-консалтинговой, или интеграторской компании.

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

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

Все остальные решения, которые исторически поддерживались независимыми компаниями, скорее всего обречены. Не случайно аналитические агентства, изучающие рынок порталов, попеременно отдают пальму первенства двум самым ярким представителям указанных категорий - IBM и SAP. Их сопровождает небольшая группа лидеров, включающая (список, конечно, может слегка меняться) ВЕЛ, Fujitsu, Novell, Oracle и Sun.

К этому можно добавить, что происходит быстрый процесс стандартизации портлетов на основе всего нескольких стандартов -Microsoft Digital Dashboard (и его аналог в .NET) для мира Microsoft, JSR168 для мира Java, где еще недавно господствовали плюрализм и несовместимость, и iView для SAP Portals. При этом SAP тоже склоняется к JSR168. Процесс стандартизации, вероятно, завершится менее чем за год.

В. Сизых: Проблема выбора систем решается в ИТ-департаменте на основании того, что уже внедрено. При этом главный критерий выбора - стоимость внедрения. Возможно, ЗАРовское решение очень хорошее, но если компания работает на технологиях Oracle, дешевле будет внедрение портала, сделанного на Oracle. С другой стороны, системный интегратор или поставщик портальных решений смотрит через свою призму: а что он может здесь сделать? Рынок портального ПО довольно дорогостоящий, и заказчики, как правило, крупные компании - никто не хочет их от себя отпускать. Поставщики решений стремятся внедрить то, что умеют, может быть, взяв на субподряд сторонних разработчиков, но необходимо учесть при этом требования клиента. Сбалансировать эти интересы - задача, которую всем нам приходится решать.

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

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

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

С. Щербина: Мы в основном предлагаем свое собственное решение - Axiom.Portal, хотя есть опыт успешной работы и с IBM, и с Oracle, и с Microsoft. Когда мы говорим с заказчиком, мы говорим с ним не только о портальных решениях. Мы предлагаем бизнес-функциональность и стараемся обрисовать круг задач, которые будут решаться с помощью наших портальных технологий. Как я уже сказал, портал - это платформа, на которой разрабатываются, устанавливаются различные веб-приложения. Это могут быть самые разные вещи, начиная с документооборота и заканчивая CRM-системами.

Внедрение портального решения выгодно прежде всего компаниям, пусть даже не очень крупным, но тем, которые территориально разнесены и в которых используются какие-то общие ресурсы или данные. Например, если у компании есть головной офис, несколько торговых представительств и 3-5 поставщиков, то портальное решение становится единственно возможным, если ее сотрудники хотят иметь единый доступ к документам, обмениваться заявками на куплю-продажу, вести общую клиентскую базу, смотреть ключевые параметры. Конечно, SAP это предполагает, но в России вопрос экономии очень важен. Большинство компаний, особенно средних, не готовы приобретать дорогие решения. Между тем, например, 1C у них уже стоит, и когда заказчикам объясняешь, что портальные технологии позволят им из всех территориально разбросанных 1C получать и структурировать информацию, визуализировать ее особым образом, то это, конечно, вызывает у них большой интерес.

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

Г. Потифоров: Вы имеете в виду OLAP-кубы?

С. Щербина: Это не OLAP-куб, в том-то все и дело. OLAP-куб требует времени выгрузки, это дорогостоящее аналитическое решение. А у нас все реализовано достаточно просто. Информация передается по выделенному каналу, мы используем веб-архитектуру. Если нужна серьезная аналитика с выяснением непараметрических зависимостей между различными факторами, то, конечно, нужен OLAP-куб, специализированные статистические пакеты. OLAP-кубы, Data Mining - это все выходит за рамки корпоративного портала.

На мой взгляд, корпоративный портал не должен дублировать функциональность прикладных программ, особенно прикладных программ специализированного назначения: бухгалтерии, САПР и т.д. Портал эффективен и нужен тогда, когда есть некий общий информационный ресурс и общие информационные задачи, которые решают большое количество людей.

ЦЕНА ВОПРОСА

К. Зимин: У меня вопрос о деньгах: по данным Forrester, стоимость внедрения портала колеблется от $20 тыс. до $5 млн. - цифры совершенно абстрактные! Вы можете как-то конкретизировать цифры по России?

А. Савельев: Но это только подтверждает мысль о том, что и само понятие портала размытое.

В. Шершульский: Можно обсуждать как структуру стоимости лицензии, так и структуру стоимости работ по внедрению.

Как уже было верно отмечено, предпроектное обследование и бизнес-анализ составляют достаточно большую долю в стоимости проекта - порядка половины цены контракта и более. Это нормально. А если говорить о лицензиях, то следует различать лицензии на серверы (а кроме собственно портала могут потребоваться и лицензии на другие серверные продукты - СУБД, поиск и категоризацию, интеграцию) и лицензии на рабочие места. Отдельно по разным схемам могут лицензироваться и компоненты. Существует уже, пусть и не очень большой, рынок портлетов независимых производителей, лидерами на котором являются деловые информационные агентства.

Чтобы получить общую оценку стоимости проекта, сюда нужно добавить расходы на кастомизацию и, возможно, программирование недостающих компонентов.

Для некоторых категорий проектов (например, для университетов или муниципалитетов) принципиально интересны решения с нулевой стоимостью клиентских лицензий. Существуют два наиболее распространенных бесплатных портальных framework'a. Один совершенно неожиданно придумала Microsoft, которую мало кто подозревал в альтруизме. Это - Digital Dashboard. У него есть и "платные" реализации, в первую Microsoft SharePoint Portal Server. Второй такой framework - JetSpeed. В его основе JSR168-coвмecтимый код, подаренный IBM сообществу OSF (Open Software Foundation). У него, конечно, есть платный аналог в виде портала IBM и некоторых других совместимых порталов. У этих двух решений хотя бы в принципе и серверная и клиентская части являются бесплатными. Есть еще ряд продуктов, например Novell/SilverStreame exteNd, у которых серверы платные, а клиентские лицензии - нет.

Соответственно понятно, что есть возможность на некоторых внедрениях использовать решения, которые либо вы разработали в соответствии с неким стандартом, либо подобрали у третьего поставщика, имеющего нулевую стоимость клиентской лицензии для большого количества клиентов. Но это означает, что возрастают затраты на собственно разработку недостающих компонентов. В корпоративном проекте со сложной функциональностью рабочих мест и высокими требованиями к надежности, масштабированию и интеграции с "унаследованными" подсистемами обычно оказывается выгоднее покупать решения, имеющие высокую степень исходной готовности, хотя и высокую стоимость серверных и клиентских лицензий. Здесь хорошим будет решение от IBM, SAP или Oracle. Наконец, в компаниях с холдинговой структурой среднего или большого размера, в которых очень часто происходят изменения, может быть использован framework быстрой разработки - Novell/SilverStream, или тот же IBM, или другие, упомянутые мной выше, решения. И так далее. Спектр широк, и это усложняет задачу выбора оптимального решения для конкретного заказчика.

Вообще, стоимость серверной лицензии колеблется от нескольких тысяч долларов до нескольких сот тысяч, а стоимость клиентских лицензий - примерно от 20 долларов до тысячи. Конечно, для "оптовых" покупателей предусмотрены скидки и цена "на неограниченное число пользователей".

С. Щербина: Стоимость решения с высокой степенью готовности, безусловно, всегда выше. Разработка и доработка таких решений сама по себе гораздо более трудоемка, потому что такие продукты не предусматривают серьезную доработку вообще. Там инструментарий гораздо уже и возможности его доработать меньше, и стоит это, соответственно, дороже. Чем хорош IBM WebSphere? Это отличный продукт, с которым можно делать все, что угодно, используя исходную структуру и базовые сервисы и компоненты. Большинство портлетов здесь рассчитано не на конечного пользователя, а на разработчиков.

Г. Потифоров: Средняя стоимость внедрения Oracle 9IAS Portal составляет от $5 тыс. до $100 тыс. и занимает от трех недель до полугода. Такой разброс вызван прежде всего тем, что в отличие от процесса внедрения ERP-системы часть работ по реализации портального решения представляется возможным сделать силами рабочей группы заказчика. Мы в нашей практике даже ввели специальный термин - девелопер портала. Имеется в виду именно не администратор, а обученный специалист, который будет продолжать развивать структуру и наполнять портал содержимым уже после окончания работ исполнителя.

А. Савельев: Я согласен, что IBM предлагает партнерам мощную среду разработки, однако решения IBM не следует воспринимать как чисто инфраструктурные: в них входят и сервисы каталогов, персонализации, управления контентом, групповой работы, поиска, анализа данных и многое другое. Также доступно множество компонентов, разработанных компаниями-партнерам, такими как, например, SAP и i2. Gartner Group называет решение IBM лидирующим на рынке, отмечая именно функциональность продукта. В группу лидеров также попали компании SAP, Sun Microsystems, BEA Systems, Plumtree и Sybase.

СЕГМЕНТЫ И ПОЗИЦИОНИРОВАНИЕ

H. Шагурина: Таким образом, мы выяснили, что спектр решений и ценовой диапазон чрезвычайно широки, предложений на рынке много. Я предлагаю перейти к сегментированию рынка по отраслям, по масштабу предприятий.

Г. Потифоров: Если говорить о средних и крупных предприятиях, то отраслевая специфика, безусловно, существует, но готовых тиражируемых портальных решений я не встречал. Как правило, отраслевая специфика перекрывается ERP-системами. Несколько слов о позиционировании решений компании "Сервокомп". Мы уже 10 лет занимаемся продуктами корпорации Oracle. Отличие наших решений в том, что корпорация Oracle исторически является одним из крупнейших игроков на рынке СУБД, кроме того, в составе ее продуктов есть и Интернет-приложения. Изюминка в том, что это единая система, вышедшая из рук одного производителя и работающая на базе Oracle. Хотя, безусловно, сопряжение с другими базами данных возможно и работоспособно. А будет ли это CRM-peшение, решение по управлению проектами или же система корпоративного документооборота, зависит от потребностей конкретного заказчика.

А. Савельев: Полезный эффект от внедрения портала может получить даже малое или среднее предприятие. Если компания имеет несколько удаленных филиалов и разрозненных информационных систем, то портал может оказаться эффективным средством консолидации информации, отображения ключевых показателей деятельности и обмена документами.

С. Щербина: И малому, и среднему бизнесу портальные решения нужны. Я сейчас говорю не о портале как таковом, а о неком классе интранет/интернет-решений. Для нас это прежде всего - тонкий клиент, выполнение приложений на сервере, некая база данных - классическая трехзвенка. Первое, что приходит в голову, когда мы говорим о "среднем" рынке, - это CRM-системы, на них сейчас есть очевидный растущий спрос. Когда мы начали этим заниматься, оказалось, что это очень просто ложится на нашу платформу. У нас есть хранилище документов, интеграционные возможности уже присутствуют, остается только сделать специфические портлеты, связки и интерфейсы для работы с клиентами. В такую систему ложится любой процесс - как процесс телефонных продаж, так и процесс работы с дилерами.

К. Зимин: С точки зрения руководителя среднего бизнеса, задача CRM - единственная бизнес-задача, которую он рассматривает в отношении порталов?

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

А. Есенков: Я еще раз хочу высказаться в пользу малого бизнеса. Ведь портал - это одно из решений проблем малого, скорее даже, виртуального бизнеса. В "АйТи" он нашел свое отражение в модели бизнес-центров, которые фактически предоставляют своим арендаторам услуги хостинга. Заключив с "АйТи" договор о создании корпоративного бизнес-центра, арендаторы пользуются не только услугами электронной почты, телефонии, сервера FTP, Web, но и собственным порталом. Фактически речь идет о портале как об услуге аутсорсинга. С этой точки зрения интерес представляет любой портальный программный пакет, позволяющий организовывать хостинг порталов, например линейка продуктов iPlanet (ныне SunONE), по использованию которой уже накоплен некоторый опыт.

Кроме того, "АйТи" успешно внедряет продукт MIO - разработку своей дочерней компании Mobico, который изначально был создан как интернет-портал. По мере появления сервисов - централизации доступа к документам, совместной работы рабочих групп, администрирования через Интернет-MIO стал использоваться и для виртуальных предприятий.

Еще один путь внедрения порталов, который практикует "АйТи", основан на развитии собственных брендов компании, таких, как "Босс-Референт". И тут однозначное решение - это WebSphere, так как в этом пакете предусмотрено взаимодействие с Lotus, на основании которого сделан "Босс-Референт".

В. Сизых: Позиционировать решения по сегментам рынка довольно трудно, все идет от прецедента. Тут важны ценовые параметры решения, минимальная цена вхождения. У нас эта цена вхождения по лицензионному ПО компании ATG Hummingbird, WebSphere -минимум $60-100 тыс. Это цена портала на один сервер. Есть исключения - у Hummingbird лицензирование не на сервер, а на клиента.

Говорить, что в порталах есть решения для телекоммуникационных компаний, для нефтегазовой отрасли, наверное, не совсем верно. Эта задача может быть актуальна от мала до велика, в различных компаниях. Но имеет ли возможность компания позволить себе внедрить подобное средство - это скорее определяется не сектором рынка, а тем бюджетом, которым она располагает. В России 3-5 отраслей, в которых есть деньги. Я думаю, у каждого из здесь сидящих есть клиенты из этих сегментов рынка.

Что касается деятельности компании "Весть-Метатехнология" по продвижению западных продуктов, то мы представляем широкий спектр вендоров порталов. Наиболее привычно ассоциируется с компанией "Весть-Метатехнология" продукт Hummingbird, но кроме этого сейчас идет развитие и ВЕА, и АТС - это относительно новое для российского рынка имя. Не забываем мы и IBM с ее WebSphere. Как мы позиционируем эти решения для клиентов? Задача системного интегратора в том, что он предоставляет некий обзор решений, направляя клиента. Если мы решаем какую-то основную задачу интеграции, это может быть WebSphere или АТС. Там, где есть необходимость поиска, больше подходит Hummingbird за счет того, что у него есть встроенный поисковик.

В. Шершульский: У нас есть клиенты в разных странах, есть клиенты и в России. Хотя у нас имеются собственные портальные решения, совместимые с MSDDB и JSR168, но в большинстве случаев мы внедряем решения на платформах SAP, Novell, IBM, Microsoft, Brio и Oracle. Более того, мы являемся аутсорсерами для ряда ведущих мировых разработчиков порталов, например для SAP и Brio, и по мере сил помогаем им в создании этих продуктов. Для некоторых продуктов, например для портальной линейки Microsoft и для SAP Portals, у нас накоплен огромный опыт разработки самых различных, в том числе сложных компонентов. Это - большое разнообразие. Поэтому я попытаюсь дать сегментацию не продуктов, а проектов. Когда в процессе общения с заказчиком выясняется, что он мыслит в терминах портального решения, за этим должно стоять или бизнес-приложение, или бизнес-задача, требующая решения.

По большей части задачи внедрения порталов возникают в тех ситуациях, когда речь идет о задачах стратегического менеджмента. И, пожалуй, таких задач очень много на сегодняшний день. Поэтому портал почти всегда оказывается частью такого правильного решения. С технической точки зрения это означает, что должны также внедряться программные продукты, которые обеспечивают процесс стратегического менеджмента, включая сбалансированные счетные карты (Balanced Scorecards). Это, пожалуй, наиболее модное из того, что существует в современном управлении бизнесом. Самое мощное из известных мне приложений, к тому же тесно интегрированное с портальной инфраструктурой, SAP SEM (Strategic Enterprise Management).

Следующая большая задача, которая одинаково часто встречается в западных и российских проектах, - создание проектного офиса. Речь, как правило, идет об инвестиционных проектах в достаточно правильно построенной компании. В такой ситуации, когда важно "выжать максимум" из высокооплачиваемых профессионалов, для них создается портальный framework, в который "погружаются" все средства проектного управления и доступа к корпоративным информационным ресурсам. Такая задача регулярно решается ИТ-интеграторами исходя из продуктов общего назначения либо с использованием специально предназначенного для этого продукта. Могу указать на компанию SAP, у которой есть мощная система управления проектами, и которая только что создала новое интегрированное решение на базе своей перспективной платформы xApps. Я горжусь, что компания ЕРАМ Systems приняла в создании этого решения самое активное участие и только что показывала его вместе с SAP на SAP TechEd в Новом Орлеане.

Следующая категория задач - это организация широко понимаемого "делопроизводства" workflow. Это больная проблема для современной энергичной компании, особенно в России, потому что: а) веление времени - переход от функциональной структуры к бизнес-процессам; 6) и та, и другая структура подвергаются мгновенным изменениям в ответ на вызовы конкурентов. И структура компании, и функциональные обязанности сотрудников, и структурные подразделения изменяются быстрее, чем можно внедрить какую-либо традиционную информационную систему. Поэтому частью проекта является создание инструментария, желательно визуального, для учета и внесения изменений, которые постоянно происходят в компании.

Я бы добавил еще, что существует горизонтальная специализация порталов по преимущественной ориентации на Business Intelligence (анализ структурированных данных), на Knowledge Management (управление знаниями), Content Management (управление контентом - содержательной информацией), Collaboration (сотрудничество) и др. Это те дополнительные сервисы, которые "навешаны" на портальный framework. А вертикальная интеграция, на мой взгляд, все-таки связана с ERP и близкими к ним приложениями -CRM,SCM.

ПРОБЛЕМЫ ВНЕДРЕНИЯ

Н. Шагурина: Давайте поговорим о процессе внедрения. В случае ERP, CRM - основные проблемы связаны со сложностью диагностики, консалтинга, сроками внедрения, обучением, сопротивлением пользователей, которые получают дополнительную нагрузку. Какие проблемы возникают при внедрении порталов?

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

Н. Шагурина: Насколько быстро клиент на своем рабочем месте ощущает пользу от внедрения портала? Если, скажем, в случае внедрения CRM пользователям приходится вводить дополнительную информацию, чего они категорически не согласны делать, то в случае портала они получают дополнительную информацию. Есть какая-то разница?

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

А. Савельев: Можно привести такой пример: компания создала новый информационный портал, большинство сотрудников зашли несколько раз, посмотрели и больше не возвращаются. Для этого случая Gartner Group даже придумала специальное название - "тефлоновый портал", т.е. портал, содержимое которого "не прилипает" к пользователям. Так вот, количество тефлоновых порталов составляет, по оценкам Gartner, до 35%. Еще 25% приходится на shelfware - так и не завершенные проекты с лицензиями, пылящимися в шкафу. Таким образом, можно говорить о том, что более чем в 50% случаев проекты по внедрению порталов нельзя считать успешными. Среди причин подобных провалов следует выделить плохо поставленное задание в части функциональности портала и невовлечение в проект ключевых бизнес-пользователей, что характерно для проектов, выполняющихся изолированно силами ИТ-департамента. Полезный эффект от внедрения портала также может снизить нежелание пользователей делиться знаниями и информацией из страха потерять часть своей "ценности" как сотрудников.

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

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

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

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

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

И еще... При внедрении портала мы сталкиваемся с тем, что пользователей у портала гораздо больше, чем у любой другой ИС, и в этом тоже заключается проблема. Остальные здесь уже прозвучали. Можно спорить о том, стоит или не стоит делать предпроектный консалтинг и стоит ли детально прописывать ТЗ. На мой взгляд, это необходимо для того, чтобы минимизировать риски, которые могут возникнуть потом. Что касается нежелания людей работать с системой, дело в том, что портал ставится уже на что-то существующее. Это значит, что люди уже умеют работать с компьютером, умеют работать с этим специализированным ПО, а портал в некоторой степени облегчает работу пользователей. Важно не распыляться, а взять сначала какую-то группу людей и сделать некоторый пилот, пусть на 30-50 мест. Как правило, этого уже достаточно, чтобы понять, насколько это удобно или неудобно, а затем распространить это на всю компанию. Сегментирование, выделение первоначальной области внедрения портала и процессно-ориентированный подход с аналитикой - я думаю, это те вещи, которые помогут при внедрении портала и повысят его эффективность и полезность.

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

Я хочу вернуться к частному вопросу о knowledge management'e и "экстракции" знаний из сотрудников. Я раньше тоже всегда подозревал, что это - неразрешимая задача. Но недавно, наконец, увидел, что это работает в нашей компании, и, что еще более удивительно, в некоторых очень крупных компаниях. Ну и прочитал пару хороших концептуальных заметок на эту тему. Системы knowledge management'a или "биржи идей" позиционируются как новое средство организации корпоративной структуры и корпоративного управления, позволяющее сделать компанию менее иерархической и более горизонтальной или демократичной. Оттого, насколько человек эффективно делится своими знаниями, очень существенно зависит его оценка коллективом и руководством. В правильно построенной компании это очень мощный фактор.

Центральный федеральный округ