Андрей,

Как ни странно, по всем пунктам с 1 по 11 у Cognos превосходные показатели... Видимо не зря Gartner считает, что Cognos - это N1 в мире (см. ссылку на обзор на моем сайте http://cognos.narod.ru ). У конкурентов Cognos обычно явные проблемы либо с пунктом 1, либо с пунктом 5, либо с пунктами 8 & 2.

Действительно, я могу кому интересно показать Cognos.
Могу также помочь раскрутить направление по продвижению OLAP/BI-продуктов Cognos в ваших компаниях :)

А почему именно Cognos и MS AS? А не Business Objects и Oracle, например?

Видимо потому что эксперты по BO и Oracle проявляют на форуме низкую активность. Если они будут рассказывать о своих продуктах, и дадут понять - что эти продукты достаточно крутые - тогда их тоже будут рассматривать.

У меня есть опыт работы с MS AS, BO, Oracle Discoverer and Express, SAP BW
Настойчивость Юрия меня, честно говоря, удивляет. Он предлагает его для всех возможных задач анализа и отчетности

SAP BW трогать не буду - это дорогая игрушка для крупных проектов.
Что касается других продуктов, которые Вы перечислили - то у каждого из них что-то есть, а чего-то нет (то есть либо OLAP, либо Query & Reporting). А у Cognos есть и то и другое (одно дополняет и усиливает другое). Поэтому Cognos и подходит для всех задач.

To Birkhoff:

нельзя рассматривать продукт или линейку в отрыве от решаемой задачи и окружения.

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

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

Лучше все таки делать это используя помощь эксперта - иначе можно в чем-то по неопытности не разобраться и принять это за недостаток продукта.

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

Теоретически Вы правы. Есть продукты класса OLAP, которые не умеют решать задачи Query & Reporting. И наоборот, есть продукты класса Query & Reporting, которые не умеют создавать кубы. И те и другие покрывают примерно по 50% решаемых задач.
Но вот Cognos - это похоже исключение. Я бы сказал что он покрывает порядка 95% (или другими словами - львиную долю) потенциально возможных задач. В оставшиеся 5% видимо нужно включить запросы к терабайтным базам, где стандартные SQL-запросы, созданные в Impromptu выполняются в РСУБД недостаточно быстро, а в куб закачивать миллиарды записей не хочется. Однако даже в сложных случаях, Cognos, обладая широким спектром функциональности, позволяет найти обходные пути.

Зато чаще встречаются случаи, когда эксперт в силу своих знаний показывает свой продукт с выгодной стороны, а недостатки вскрываются потом.

Разумный эксперт не будет этого делать, поскольку дорожит своей репутацией.

Я бы сказал что он покрывает порядка 95%
Если бы он покрывал 95%, то была бы ситуация как с MS Word и выбор чаще всего был бы очевиден. Но ее нет, значит все таки не 95%.

Рынок BI - это один из растущих и перспективных рынков, многие компании хотят на этом заработать. Поскольку доля рынка, занимаемая продуктом зависит не только от того, насколько он хорош, но и от того, насколько профессионально его продвигают, то понятно, что компании Cognos предстоит выполнить большой объем маркетинговых работ.

Юра, Вы же прекрасно знаете долю рынка Cognos. Примерно столько же процентов задач удобней решать продуктами Cognos. Потребителя вцелом не обманешь. Это нам здесь можно пудрить мозги. :-)

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

Но посмотреть продукты Cognos Вы меня убедили. Возможно идея о продаже Cognos вместе с BI от Microsoft имеет какой-то смысл. Где раздают триалы?

Ознакомительную версию или бесплатную демонстрацию ПО Cognos можно заказать, либо послав запрос на адрес Cognos@narod.ru , либо отправив запрос эксперту Cognos с сайта http://cognos.narod.ru

Я видел PowerPlay, правда давно, не произвел он на меня впечатление лучшего что я видел в жизни. Да, наверное, что-то в нем сделано удачнее чем у других, но например я не увидел в нем работы с parent-child. И со временами как то все было неочевидно. Так что у меня осталось впечатление, что это продукт того же класса что и Business Objects или Discoverer.

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

To Ginness:

Blin , MSOLAP na svalku mogno vmeste s Cognos
takoi serjesnoi kompanii kak Mikrotest zachem nugem MSAS & Cognos? ILi tema tak modna? chto nichego drugogo i putei drugi[ ne vidjat?

Между прочим, Cognos и MS OLAP - это лидеры среди аналитических систем, так что непонятно, чем они Вам не нравятся...
Если не нравится reporting Services - то Вам должен понравиться продукт ReportNet (это совместная разработка компаний Cognos и Microsoft - функциональность от Cognos, название от Microsoft :)

Привет, Василий!

Похоже раздел твоего сайта, посвященный OLAP-серверу Cognos PowerPlay, пользуется такой популярностью, что туда проблематично зайти (всем желающим места на сайте не хватает :)

Обязан заметить: ПП мы, поставили лицензионный:)) Даже с поддержкой хотя она как выяснилось нам и не нужна!

Судя по крайне малому количеству вопросов, которые твои специалисты задают экспертам по Cognos через сайт http://cognos.narod.ru и по ICQ, вам действительно тех. поддержка не так уж нужна. Хотя стоит отметить, что ее полезность заключается в бесплатном получении новых версий продуктов Cognos.

To Guest:

То Jurii: а где же линк на раздел сайта?

Я скинул Вам его по мылу :)

2 Pi:

В Киеве распространяются слухи, что вот приезжали спецы от Cognos в одну украинскую торговую сеть где-то летом 2004 г. , попытались открыть проект - и неудача! Продукт не прошел предложенное тестирование:

Мне приятно слышать о таких слухах - значит политическое напряжение на Украине спало, и спектр интересов переместился в область экономики и информационных технологий ;)

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

Как сервер кубов он не справился - не смог за сутки постоить куб на базе заказчика. Заказчик собственными силами на MS AS успевает построить куб за ночь на том же железе и той же базе.

Это ни о чем не говорит, эксперимент не чистый. MS AS по архитектуре более тесно интегрирован с реляционной БД MS SQL Server, время полного перепроцессинга - не так критично. Я думаю что тот кто проводил это тестирование - был не самым крутым экспертом по Cognos, и наверное использовал технологию виртуальных вьюшек Cognos - при которой закачка данных делается медленнее, но аналитическая модель получается интереснее и содержательнее.

Как клиент продукт тоже не подошел - не получился доступ к виртуальным кубам MS AS (см. выше)
Сможете прокомментировать этот слух?

Насчет виртуальных кубов - не знаю, не проверял. Но мне кажется, что имеют место политические тонкости - кто-то просто хотел наехать на крутизну Cognos, сделав акцент на некоторых технических вопросах, и не рассмотрев ситуацию в целом (все плюсы и минусы MS AS и Cognos). Я говорю это исходя из опыта общения с киевскими специалистами по OLAP, которые восхищаются продвинутостью и удобствои интерфейса OLAP-клиентов Cognos.

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

2 Pi:

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

ОК, тогда я сам наведу справки на эту тему, пообщаюсь с моимо знакомыми из киевских торговых компаний :)

И я продолжаю ждать реплик от того, кто действительно приезжал в Киев.

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

2 Pi and Mosha:

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

Самописная база или коробочная учетная система - для Cognos это не принципиально.

Эксперимент не чистый по следующей причине - слишком разная архитектура OLAP-модели была у Cognos и MS AS (хотя я не видел эти архитектуры, но уверенность у меня 100%). В MS AS были надерганы таблица фактов и справочники, и все они были увязаны друг с другом по связи поле к полю.
OLAP-куб Cognos проектировался на основе избыточной виртуальной вьюшки - в которой включены и факты, и измерения - соответственно велик трафик и снижается скорость перекачки данных с реляционного сервера на OLAP-сервер. На объеме данных в 200 миллионов записей это привело к существенной разнице в скорости процессинга. Чтобы эксперимент был чистым, нужно было модель Cognos проектировать по аналогии с MS AS - сделать отдельно таблицу фактов и справочники.

Вы можете спросить - зачем нужны виртуальные вьюшки, если они медленнее работают, чем таблицы фактов + справочники? Ответ прост - виртуальная вьюшка позволяет создавать измерения в кубе, уровни иерархии у которых принадлежат разным справочникам и даже разным источникам данных (например характеристика клиента взята из Excel, а название клиента - из учетной системы на MS SQL Server). Также виртуальная вьюшка позволяет создавать вычисляемые измерения, уровни иерархии, мемберы, и показатели на основе формул, в которые входят бизнес-объекты из разных справочников - например это удобно, когда хочется задать алгоритм расчета показателя для элементов одного измерения в зависимости от значений в другом измерении.

Профессор,

Из исходного поста Pi не очевидно, что схема хранилища была иной для Cognos и MS AS.

Я не с потолка пытался угадывать. Я знаком с рядом кивевских розничных компаний, знаком со специалистами по Когносу которые могли делать тот тестовый пример... Думаю я знаю о какой компании идет речь :)

2 олапист:

А можно поподробнее об этом подходе? Не совсем понятно как PowerPlay Transformer связывает несколько data sources. Единственное предположение - по совпадению имен колонок

Вы совершенно правы - связь происходит по совпадению имен колонок (логических имен). То есть если в разных истониках есть одинаковые по смыслу колонки, но названия у них разные - их можно переименовать внутри ОЛАП-сервера Когнос.

2 НЕТ РЕКЛАМЕ:

Кстате, я продолжаю ждать Вашего ответа как професионала о недостатках Cognos. Если надо то я и три года подожду пока у Вас будет время ответить

ОК, подождем, может к тому времени в России появятся внедрения Юкона - тогда легче будет сформулировать слабые стороны Когноса :) Главное чтобы Когнос не выпустил новую версию с еще более навороенной функциональностью, а то придется отложить этот вопрос еще на 3 года

2 DmitryS:

А Юра, как я понимаю из его поста полагает, что при использовании Cognos хранилища не нужны. Так? :-)))
Это для новеньких разъяснение:-)

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

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

2 backfire:

Что вы подрозумеваете под "неуместно делаемым хранилищем"?

На конференции по Business Intelligence задавался примерно следующий вопрос - нужно ли городить проект по созданию хранилища данных, если источник данных - единая учетная система с количеством записей в таболице фактов не более миллиона? Мой ответ на этот вопрос - что не нужно (если аналитический инструментарий не нагружает реляционный сервер, на котором крутится учетная система (например - Cognos PowerPlay).

Кстати, какому термину Cognos соотв. ваше жаргонное "виртуальная вьюшка".

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

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

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

2 Константин Лисянский:

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

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

Но этот доклад достаточно грубо прервал ведущий.

Это было понятно еще до начала конференции - после доклада по регламенту был фуршет, и ведущий понимал, что посетители конференции будут недовольны, если их будут морить голодом :)

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

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

2 Профессор Нах:

2 Jurii
Судя по реакции зала, зажечь докладом про внедрение аналитической системы за 5 дней не удалось :)

Пусть это будет Вашим личным мнением. Я же, в ходе фуршета, набирая себе еду, в разных концах зала слышал, как посетители конференции обсуждали вопрос создания аналитической системы за 5 дней :)

Там все делается визульно при помощи мышки и вьюшек :)
Юрий, не обижайтесь :)

Зачем же обижаться, это чистая правда, и это меня радует :)

2 олапист:

то есть правильно ли я понимаю что в молели кубов PowerPlay вообще отсутствуют такие понятия как схема звезда, таблица фактов, таблица измерения, а есть ER-модель, с информацией о связях между колонками, и работа и источником данных ведется путем одного большого select-а (ну или виртуального select'a если источников несколько) который join-ит все таблицы?
информация об уникальных ключах в этой модели тоже отсутствует?
а как же при этом powerplay сможет оптимизировать запросы при процессинге?

В модели кубов PowerPlay используется понятие Источника Данных - это может быть запрос к физической таблице, вьюшке, плоскому файлу, или виртуальная вьюшка. При использовании виртуальной вьюшки оптимизация запроса при процессинге происходит на реляционном сервере. Если же например имеется несколько гетерогенных источников (виртуальные вьюшки на оснвое разных РСУБД, файлы Excel и т.п.) - то PowerPlay читает их во временные файлы на OLAP-сервере, присваивая каждому мемберу короткий указатель, далее временные файлы сортируются и объединяются - думаю этот процесс аналогичен тому, что происходит на реляционном сервере при связывании таблиц, которые не проиндексированы.

также не понятно как работает incremental update. опять только лишь предположения: либо в источниках данных должны находится только данные для "доливки", либо pp сам вычисляет различия между текущим кубом и данными из источников?

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