Как избежать многочисленных ловушек при покупке OLAP продуктов

OLAP продукты отличаются от друг друга гораздо больше чем, например, реляционные базы данных, языки программирования или текстовые редакторы, что весьма увеличивает возможность ошибки при выборе OLAP-продукта. Проблема еще и в том, что, как правило, и профессионалы по ИТ (информационным технологиям) и конечные пользователи оказываются недостаточно подготовленными и информированными для выбора OLAP. Часто случается, что выбор того или иного продукта осуществляется одной группой специалистов без консультаций с другой. Отсюда первый вывод: в отличие от большинства иного программного обеспечения оценку OLAP должны производить обе категории специалистов. Но в многих организациях специалисты по ИТ и конечные пользователи испытывают трудности общения уже только потому, что манипулируют при разговоре разными понятиями и терминами. Мы встречаем компании, которые сделали странный выбор продукта из-за того, что исходили из причудливо составленного списка требований, отражающего противоречивые предпочтения технических и деловых групп специалистов.

Последствия неправильного выбора инструмента могут быть весьма серьезны:

	В худшем случае, проект будет полнорстью непригодным, со всем программным обеспечением и произведенными затратами, с потерей ожидаемой прибыли. Суммарные потери могут выражаться в миллионах.
	Более типичный случай, когда некоторая часть проекта оказывается работоспособной, так что виновники могут представить результат "успехом" и спокойно переходить к другим вещам. Однако успехи будут весьма занижены, развитие минимально и деловые выгоды иллюзорны. Такие проекты - обычная вещь, однако они могут оказаться хуже, чем в первом случае, потому они дают меньше стимулов для замены неудавшейся системы, так что потенциальные деловые выгоды будут потеряны на больший срок.
	Некоторые проекты имеют большие амбиции на этапе развертывания, но при этом исходят лишь из первого ведомственного приложения. Они могут дать некоторую выгоду начальной группе пользователей, но не следующим приложениям, для которых потребуются другие решения. Тем временем компания приобретает избыточные лицензии для первого проекта, которые затем ложатся "на полку".
	Группа, осуществляющая выбор (или сама администрация), может быть увлечена грандиозными представлениями поставщика и вложить капитал в грабительски дорогое решение в общем-то простой проблемы. Это решение может работать достаточно хорошо, но стоить во много раз больше чем другое, одинаково приемлемое.

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

Оценка потребностей

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

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

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

	Попытаться предсказать то, в чем пользователи действительно нуждаются не только с их слов; это означает, что Вы должны понять, как они делают свою работу, какие навыки имеют, какая информация и исследования помогли бы им быть более производительными
	Включить конечных пользователей во все стадии проекта, включая проектное задание, выбор инструментария и исполнение
	Не ждать, что конечные пользователи будут способны заранее перечислить точные требования - и не пытайтесь заставить их сформулировать каждую возможную потребность (иначе вы получите невозможный список)
	Никогда не пытайтесь выбирать архитектуру хранения и обработки до понимания потребностей бизнеса
	Не используйте ранее купленные OLAP продукты, которые уже легли "на полку"

Если OLAP является новой технологией для организации, выполнение некоторых из этих условий может быть затруднено.Тогда возможно стоит начать с проекта небольшого масштаба, с использованием простого, ориентированного на конечного пользователя инструмента, главным образом для получения опыта. Обычно пользователям намного проще определить потребности, если они использовали по крайней мере основные возможности инструмента, нежели на пустом месте.

Прежде чем сформировать официальную спецификацию для большого проекта, Вы должны рассмотреть следующие факторы:

	Объемы входной информации, которые имеются и которые появятся в будущем
	Изменчивость данных (некоторые продукты не могут обрабатывать данные и метаданные, отличающиеся большим непостоянством)
	Сферу приложения: анализ продаж/маркетинга, составление бюджета/планирование, анализ показателей деятельности, анализ бухгалтерских отчетов, качественный анализ, финансовое состояние, формирование аналитических материалов (отчетов)
	Ключевые особенности: потребность в обратной записи данных, распределенные вычисления, сложные валютные преобразования, качество печатной продукции, интерфейс электронной таблицы, сложность логики приложения, необходимая размерность, статистический анализ, планирование и прогнозирование (включая алгоритмы "что, если?")
	:Интегрирование: связь с другими системами, типа электронной почты, информационных хранилищ (data warehouses), систем "добычи данных" (data mining)и т.д.
	Число пользователей и их размещение: воздействие архитектуры, секретность, расходы
	Вид пользователя: высшее руководство, финансы, маркетинг, HR, продажи, производство и т.д
	Опыт подразделений внедрения и разработки: Excel, VB, JavaScript, Java, SQL, ETL, EIS, Web, проектирование многомерных баз данных и т.д
	Кто будет заниматься внедрением и эксплуатацией: внешние консультанты, внутренняя служба ИТ или конечные пользователи
	Платформа сервера: NT, Unix, AS/400, Linux - но не следует настаивать, чтобы заданные спецификацией OLAP продукты выполнялись на сомнительных или умирающих платформах, которые Вы все еще используете
	Стандарты клиентской части и браузера
	Разворачиваемая архитектура: локальная сеть и модемная связь PC, высокоскоростной клиент/сервер, intranet, extranet, Internet
	Международные особенности: многовалютная поддержка, многоязычные операции, коллективное использование данных, локализация, лицензирование, обновление Windows
	Бюджет: программное обеспечение, аппаратные средства, услуги, передача данных.

Избегайте предвзятых рекомендаций

Вы можете найти множество "бесплатных" советов относительно OLAP-продуктов, но большинство из них исходят из весьма предвзятых тенденциозных источников:

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

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

Не слишком беспокойтесь, если ваш выбор упадет на некоторые относительно маленькие компании, появляющиеся на списке. В самом деле, если список состоит только из "самых больших и лучших" компаний, то он вероятно несбалансирован, потому что эти компании вероятно доминируют над весьма различными секторами рынка OLAP, и не продают продукты, которые должны сравниваться непосредственно.

Другой совет: обратите внимание поставщика на основные требования вашей спецификации, особенно, если старались сократить список требований. Пригласите лучших специалистов поставщика и попросите их описать подробно, как бы они решили специфические проблемы. Естественно, что покупатели должны быть достаточно подготовленными сами (или иметь квалифицированных консультантов) чтобы суметь сфокусировать основные моменты, на которые нужно получить ясные ответы и выявить их возможные недостатки. Эта методика часто позволяет прополоть неподходящих поставщиков намного раньше, чем при использовании традиционных систем отбора.

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

Является ли стандарт OLAP хорошей идеей?

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

Несмотря на кажущееся подобие (особенно при знакомстве в Internet), OLAP-продукты все же весьма различаются по своей архитектуре и функциональным возможностям. Никакое изделие не хорошо во всем. Большинство может подходить лишь к ограниченному диапазону приложений. Например, некоторые могут обрабатывать очень большие объемы данных, но неконкурентоспособны на маленьких объемах, где они медленны, громоздки и менее удобны по сравнению с продуктами, которые изначально нацелены на небольшие приложения. Другие ориентированы на коллективное использование большим числом пользователей, но - не идеал для небольших групп. Некоторые имеют хорошие средства для работы в Web, но не подходят для локального использования. Одни имеют возможности реализовать многопользовательскую актуализацию данных, но при этом не идеальны как системы, предназначенные для формирования отчетов. Но есть один момент, который, кажется, имеют все продукты - это то, что их поставщики являются "лидерами" и что их продукты "масштабируемы" (по крайней мере все это утверждают).

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

Поэтому невозможно удовлетворить потребности большой совокупности пользователей только одним продуктом.

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

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

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

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

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

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

Вместо стандарта в виде отдельного продукта намного лучше для группы ИТ поддерживать узкий диапазон различных OLAP продуктов, которые охватывали бы широкий диапазон приложений.

Как избежать тендеров

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

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

Типичные тендерные документы включают длинные списки желательных характеристик, хотя никто, возможно, фактически не проверил, являются ли такие характеристики соответствующими деловым требованиям. Часто представительный продавец может весьма эффективно склонять к запросам на особенности, которые их изделие обеспечивает, а ожидаемые конкуренты - нет. Другие характеристики из списка часто продуцируются старыми продуктами, из желания преодолеть их слабости, но которые не существуют в современных продуктах и, соответственно не нуждаются в таких характеристиках. Более того присутствие таких особенностей для современного изделия, должно быть расценено как подозрительное. Например, требование, чтобы изделие поддерживало Lotus 1-2-3 или Windows 3.1 в организации, которое перешло в Excel и в Windows 2000, бессмысленно, и в более современных продуктах исключено. Точно так же неблагоразумно диктовать функциональные особенности или архитектуру, если более новые продукты могут обеспечивать деловые потребности другим, возможно более лучшим способом.

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

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

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

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

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

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

Мы думаем, что традиционные документы проведения тендера просто не годятся для OLAP-продуктов. Намного более подходящий процесс:

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

Не нужно никакого академического тендерного документа; вместо этого, предварительно отобранная документация должна быть сконцентрирована на деловых потребностях, которые продукт должен удовлетворить.

Отвлечения

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

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

Имеется много отвлекающих обстоятельств, на которые Вы должны обратить внимание, чтобы быть способными к сопротивлению.

Размеры поставщика

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

Более того, длительное здоровье OLAP изделия фактически менее гарантировано в большой компании, нежели в компании, чье будущее всецело зависит от успеха ее OLAP бизнеса. Довольно легко можно пренебречь или отказаться от проектов OLAP, доходы от которых составляют крохотную часть полного бизнеса продавца. Руководство больших компаний вероятно не касается аналитических приложений, так что их OLAP cтратегии могут казаться весьма нескоординированными, зависимыми от прихотей администрации, временами проявляющей внимание к проектам. Почти невозможно найти старшего исполнительного директора, руководителей служб маркетинга, технической поддержки, сбыта, которые имели бы глубокие знания относительно OLAP, в компаниях подобных Oracle(со своим Express), IBM (DB2 OLAP Server ), Microsoft (OLAP Services), Informix (MetaCube), SAS Институт (MDDB и CFO CFO Vision), SAP (BW) и CA (InfoBeacon).

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

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

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

Многие поставщики OLAP утверждают, часто на второстепенных или выдуманных основаниях, что они являются техническими лидерами. Многие также делают сомнительные заявления о лидерстве на рынке OLAP, включая некоторых, кто пребывает весьма низко в нашей таблице распределения доли на рынке. Но даже те, кто действительно имеет большие достижения, на самом деле хвастаются прошлыми достижениями (когда конкуренция была возможно очень низкой), а не своим будущим потенциалом.

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

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

Вопросы технологии

Большим отвлекающим моментом может стать выбор платформы. Часто предпочтение отдается продуктам, которые способны функционировать на старых, умирающих платформах, но которые все еще используются, а не продуктам, которые более всего соответствуют потребностям. Например, несмотря на технические возможности, компании могут иметь OS/400, OS/2, мэйнфреймы и непопулярные версии Unix (это любые версии, отличные от Solaris, AIX или HP-UX), которые теперь обеспечивается минимальной поддержкой OLAP-серверов (хотя поддержка Linux кажется обеспечивается). Остается небольшая поддержка для Macintosh, OS/2, Unix или 16-разрядных версий настольных Windows. OLAP поставщики чаще поддерживают Microsoft Internet Explorer, нежели Netscape, в то же время интеграция с Excel весьма превосходит встраивание 1-2-3. Вообще говоря, не стоит требовать поддержки умирающих платформ, так как гораздо легче и дешевле использовать удобные NT-сервера (который почти все OLAP-продукты поддерживают). Замена платформы клиента для развертывания OLAP тяжелое мероприятие, но оно может быть использовано как толчок для перехода в другое состояние и давно требующегося обновления.

Хотя системы NT4 не как устойчивы или масштабируемы как универсальные ЭВМ, Unix или AS/400, они обычно весьма адекватны для приложений OLAP, немногие из которых имеют технические решения для чего-то более сложного или более надежного. В любом случае, новый Windows 2000 очень близко подходит к возможностям Unix и AS/400. Таким образом, дорогие решения по использованию серверов Unix или AS/400 должны быть дополнены другими соображениями типа необходимости использования имеющихся мощностей, требований интегрирования или резервирования производственных мощностей, но не увлекаться в общем случае ненужной масштабируемостью и помехоустойчивостью, которую они предлагают.

Многие попадают под влияние мнения о том, что более предпочтительным является открытое ROLAP решение, вместо "частных" MOLAP или HOLAP. Это может быть большой ошибкой, так как, хотя ROLAP-продукты хранят данные в стандарте RDBMSS, каждый ROLAP имеет собственную сложную и уникальную схему, и никакой ROLAP не будет работать со схемой другого продукта. В действительности, каждый имеет собственные частные структуры данных, которые только сохранены в RDBMS. Таким образом, единственная полезная форма открытости OLAP - это хороший программный нтерфейс (API). ROLAP-продукты здесь слабы: ни один из них не имеет хорошо обустроенного, открытого API (хотя WhiteLight теперь поддерживает OLE DB для OLAP).

И хотя ROLAPS может действительно обрабатывать большее количество данных, чем большинство (но не все) MOLAPS, это слишком большая цена для оплаты снижения функциональных возможностей, больших затрат на внедрение и решительно худших эксплуатационных показателей. Таким образом, любое решение предпочтения ROLAP должно быть основано на должным образом оцененном бизнесе и технических потребностях приложения, но не на почти религиозных, но ошибочных основаниях "открытости".

Справочники клиентов

Справочники клиентов важны. Они позволят Вам пробиться сквозь технический туман и сконцентрироваться на том, как программа работает на деле:

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

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

Все поставщики утверждают, что их продукт быстрее, чем у конкурентов. Чтобы выяснить правду, Вы должны или проводить испытания продукта в полном масштабе (тяжелые, медленные и дорогие) или посещать другие места его эксплуатации, где объемы данных, мощность сервера, количество пользователей и сложность приложения подобны вашим. Будьте готовы услышать от специалистов ИТ, что "сегодня большая загрузка, обычно это не так медленно". Удостоверитесь в тех эксплуатационных показателях, какие Вам представляют.

Относительно открытости следует заметить, что на сегодня нет никаких формальных стандартов на способности OLAP к взаимодействию, так что бессмысленны требования к поставщикам на их соблюдении. Microsoft OLE DB становится стандартом для OLAP API "де факто", но два главных поставщика серверов OLAP (Hyperion и Oracle) оппозиционно настроены в отношении этого, несколько поставщиков среднего размера не делают ничего, чтобы поддержать его, несмотря на заявления, что такие планы существуют. Essbase единственный, кто имеет хорошую поддержку OLAP API, отличную от OLE DB для OLAP. Наоборот, MDAPI 2.0 потерпел неудачу, так же как и Express API, имеющий частичную поддержку.

Даже если поставщики утверждают, что поддерживают OLE DB, то степень реализации может быть совершенно различной. Поэтому Вы должны прояснить себе многие вопросы (и возможно выполнить некоторые испытания), если Вы планируете положиться на продукты от различных поставщиков, работающих посредством этого API. Например, Cognos NovaView имеет намного более глубокую поддержку OLE DB для OLAP, чем Cognos PowerPlay. OLAP@Work обеспечивает Excel гораздо лучше для работы с Microsoft OLAP Services, чем это делает собственный PivotTables в Excel 2000.

Другая область, которая может смутить - это Web. Наверное каждый поставщик имеет сегодня по крайней мере одно Web-ориентированное решение, и многие имеют грандиозные cтратегии на будущее. Но это быстро меняющаяся область, и если ваши приоритеты сегодняшнего дня заключаются в развертывании работы в Web, Вы не должны слишком озадачиваться этой темой. Здесь среди поставщиков наблюдается настоящая чехарда, сегодняшний лидер может завтра стать аутсайдером.

Имеются несколько различных вариантов браузеров Web, и ни один не совершенен для всех случаев. Поставщики OLAP между тем используют каждый возможный подход, существующий в Web, таким образом косвенно доказывая, что нет никакой одиночной идеальной архитектуры. Если развертывание Web - ваш приоритет, Вы должны предпочесть продукт, который предлагает подход, совместимый с вашими планами.

Многие поставщики заправляют свои презентации большим количеством жаргонных словечек, типа "объектно-ориентированный", "портал", Java, DHTML, XML, "plug-ins", "картридж", "апплет", ERP, OLE DB, MDX, COM, ADO MD, MDAPI, APB-1, CORBA, SMP, MPP, ActiveX и тому подобное. Вообще, чрезмерное использование такого жаргона не коррелирует с хорошим изделием, чьи достоинства не нуждаются таких подпорках.

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

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

Финансовые проблемы

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

При прикидке общих затрат не забудьте выяснить следующие вопросы:

	Насколько широк выбор источников для внедрения, обучения, и поддержки?
	Является ли потенциальный общий фонд (служащих, подрядчиков, консультантов) склонным к росту или сокращению?
	Насколько широко может быть использован свой производственный профессиональный опыт?

Никогда не выбирайте программу только потому, что она более дешевая, имеет слишком большие скидки, или даже бесплатная (даже "бесплатные" продукты должны быть оценены, если рассматривается серьезное развертывание). Но, с другой стороны, если два продукта представляются подобными, и оба соответствуют вашим потребностям, то естественно следует выбрать менее дорогой. В равной степени Вы не должны предполагать, что выше оцененное изделие обязательно лучше. OLAP поставщики оценивают так, как хотят, и продавец с хорошим маркетингом и коммерческими способностями будет избегать неприятностей с оценкой продукта выше, чем он действительно ‘стоит’. Действительно, мы видели много примеров, когда более дешевое изделие оказывается намного лучше для некоторых приложений чем более дорогое. Вероятно лучше всего отложить рассмотрение стоимости на ранних стадиях оценки продукта, если Вы не знаете, что некоторые продукты - определенно вне вашего бюджета (все обзоры продуктов в "THE OLAP REPORT" содержат информацию о ценах).

Проверка работоспособности

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

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

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

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

Мы думаем, что широко используемый подход "прогона на контрольном примере" является наименее полезным, потому что он неизбежно концентрируется на наиболее тривиальных аспектах продуктов. Нужно принять во внимание, что те особенности, которые обеспечат длительный успех проекта OLAP, являются более тонкими. Например, небольшие OLAP-продукты класса desktop (рабочий стол) позволят создать простые приложения намного быстрее, чем их соперники в тяжелом весе, и это вероятно проявится в коротких недельных испытаниях на контрольном примере. Но они могут оказаться неподходящими для реальной системы, которая является несомненно более сложной, чем упрощенный пример в контрольном прогоне. Однако, "контрольный пример" психологически удобен для пользователей, и может стать препятствием на пути успеха проекта в целом.

Заключение

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

Хотя имеется множество свободных источников с советами относительно OLAP продуктов, многие из них являются "смещенными", и должны рассматриваться с подозрением. Остерегайтесь перепечатанных аналитических обзоров, которые могут быть спонсированы непосредственно поставщиком. Квалифицированные продавцы могут заставить Вас думать, что Вам нужно то, что они должны продать.

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

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

Найгель Пендс, OLAP Report
Перевод Шамиля Абушаева, Социо Прогресс

Знаете ли Вы, что любой разумный человек скажет, что не может быть улыбки без кота и дыма без огня, что-то там, в космосе, должно быть, теплое, излучающее ЭМ-волны, соответствующее температуре 2.7ºК. Действительно, наблюдаемое космическое микроволновое излучение (CMB) есть тепловое излучение частиц эфира, имеющих температуру 2.7ºK. Еще в начале ХХ века великие химики и физики Д. И. Менделеев и Вальтер Нернст предсказали, что такое излучение (температура) должно обнаруживаться в космосе. В 1933 году проф. Эрих Регенер из Штуттгарта с помощью стратосферных зондов измерил эту температуру. Его измерения дали 2.8ºK - практически точное современное значение. Подробнее читайте в FAQ по эфирной физике.