Коллеги, а не отстаете ли вы от графика? В свое время Евгений озвучил примерный план проекта (см. ниже), и по этому плану в конце второй недели модель метаданных должна была быть почти закончена...
 
1. Сбор и анализ требований пользователей к отчетности - 4 дня.
2. Анализ источников информации - 1 день.
3. Разработка модели метаданных (Universes) - 6 дней.
4. Разработка и тестирование отчетов и дэшбордов - 10 дней.
5. Обучение пользователей - 3 дня

Туда же отправил и замечания и предложения по улучшению сервиса.
Ошибки в анкете типичные, снижают не только конверсию и лояльность.

Себе, конечно-же )))))))))

Кому высылать счет за услуги?

А можете рассказать более подробно про эти методы оптимизации производительности в SAP BO? Чтобы от общих слов перейти к интересному техническому обсуждению... Или может об этом стоит рассказать экспертам из BI Partner и/или SAP, которые, к сожалению, пока не проявляют активности в этом блоге...

По поводу BI за 2 часа - это был (и есть до сих пор) тест-драйв, а не внедрение. На выходе тест-драйва создавались не 2 отчета - а многомерное хранилище данных (OLAP-куб Cognos), которое для очень многих аналитических задач не нуждается в традиционном хранилище (поскольку OLAP-куб умеет объединять в себе данные из разных источников, и обеспечивает предсказуемо высокую производительность). OLAP-куб позволяет мышкой накидать множество разных отчетов из своих измерений/показателей.
Полноценный проект от тест-драйва отличается проработанностью структуры кубов (в них больше показателей, разрезов, больше источников данных, разработаны отчеты, и т.п.).
В вашем случае - у SAP BO нет кубов, и вы не делаете кубы в подсистемах других разработчиков (таких как Microsoft OLAP - SSAS), с которыми SAP BO может работать. Поэтому в вашем проекте есть риск, что некоторые продвинутые пожелания пользователей не смогут быть выполнены по причине низкой производительности сложных SQL запросов, выполняемых налету. Когда SQL-запросы - сложные, то такие данные без кубов крутить сложно...

Жаль что нельзя посмотреть на ваше ТЗ - проект получается за несколько мутноватым стеклом ;)
 
Хочу уточнить по поводу витрины данных. Это набор вьюшек, которые ссылаются на оперативную систему? Или это физические таблицы, которые обновляются периодическими загрузками данных или путем репликации?
 
И правильно ли я понимаю, что OLAP-кубы вы делать не будете (отчеты будут создаваться на основе SQL-запросов SAP BO)?

Александр, попробуйте сервис, заодно выскажете критические замечания: http://bigbuzzy.ru/catalog/ipad2-piter/

Юрий, спасибо за информацию про OLAP.  Риск есть, поэтому мы уже работаем над его снижением - SAP позволяет с этим поработать и оптимизировать производительность отчетов.

По поводу BI за 2 часа - это был (и есть до сих пор) тест-драйв, а не внедрение. На выходе тест-драйва создавались не 2 отчета - а многомерное хранилище данных (OLAP-куб Cognos), которое для очень многих аналитических задач не нуждается в традиционном хранилище (поскольку OLAP-куб умеет объединять в себе данные из разных источников, и обеспечивает предсказуемо высокую производительность). OLAP-куб позволяет мышкой накидать множество разных отчетов из своих измерений/показателей.
Полноценный проект от тест-драйва отличается проработанностью структуры кубов (в них больше показателей, разрезов, больше источников данных, разработаны отчеты, и т.п.).
В вашем случае - у SAP BO нет кубов, и вы не делаете кубы в подсистемах других разработчиков (таких как Microsoft OLAP - SSAS), с которыми SAP BO может работать. Поэтому в вашем проекте есть риск, что некоторые продвинутые пожелания пользователей не смогут быть выполнены по причине низкой производительности сложных SQL запросов, выполняемых налету. Когда SQL-запросы - сложные, то такие данные без кубов крутить сложно...

Ну что же попробуем еще раз . Во-первых пишу о том, что знаю и лично проходил в течении последних 15 лет когда был и консультантом и ПМ-ом и продавцом различных бизнес систем от Champion, SunSystems до IBM Cognos и MBS Axapta.  Вследствие этого могу тоже привести массу "правильных" советов по мытью рук. В крупных  и не очень компаниях проработал предостаточно и честно ВЕЗДЕ видел только одну картину успешного проекта: небольшая, но очень упорная группа с лидером, которым это действительно НАДО, собственно и делает проект благодаря или вопреки правилам корпорации. В своем большинстве остальным это редко бывает надо, так как получаемые блага информатизации как правило вызывают необходимость тратить больше времени на освоение системы, менять устоявшиеся привычки и что самое главное попадать под больший контроль СИСТЕМЫ, что по разным причинам делать не хочется.  Если такой группы нет, то хоть оппишитесь "правильных" бумажек по "правильным" системам , результат будет только в потере времени и денег.  В крупной компании работает много людей и у каждого свои интересы, поэтому и "выбор" системы это отдельный процесс подковерных интриг, "внедрение" тоже процесс тот еще, а бизнес результат как правило уже никого не интересует. Поэтому оплачивая бензин и услуги  ЖКХ, мы как потребители оплачиваем еще и такие "проектные методологии" и высокоплачиваемых "консультантов". И за это нам никто не вернет не только деньги, но не подарит даже кривой улыбки.
Кстати вопрос к Юрия: я очень хорошо помню историю про "Внедрения BI за 2 часа". Там создавался коннект с БД и 2 отчета. И ведь работало же! А сколько проектов, которые тянулись месяцами приводили все к тем же 2-м отчетам :-)

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

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

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

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

" ... осмотрев на то, что есть на рынке и пообщавшись с народом, решили действовать по принципу – выбрать тех, кто будет более всего клиентоориентированным. И не важно маленький или большой продукт. В расчет включили все: функционал,  удобство использования и конечно цены."
Большое спасибо, Вы раскрыли нам понятие "клиентоориентированности"  теперь мы знаем, что в это понятие "включат всё".
Но догадаться о том, нужна вам была клиентоориентированность компании поставщика или клиентоориентированность софта в Вашем тексте я не смог, ответьте, пожалуйста.
 
Из ответом на прошлый пост я догадался, что всякие бумажки и документирование выбора - не для вас, а слово "расчет" - это просто "фигура речи", и ждать нам формальной аргументации не стоит. Пацаны всегда выбирают правильно, особенно, когда в расчет берут всё! :-)
 
"Взвесив все – выбрали SAP, а в качестве внедренца/консультанта – BI Partner. У них было правильное понимание наших пожеланий и возможностей относительно небольшой компании. Помимо всего прочего – важно, что партнер по внедрению имеет репутацию отвечать за свои слова и доводить даже самые безнадежные  проекты до светлого будущего."
 
Как красиво переведена фраза: это конкретные пацаны, за базар перед другими пацанами отвечают, на бабки не разводят, ведь мы-  пацаны бумаг то не пишем, а работаем по понятиям.
 
Ребята из BI Partner приходили к нам в офис и проводили интервью.
А можно увидеть отчеты об интервью? или пацаны вообще бумаг не пишут?
 

!!! Стекло уж больно мутное у вас. Может проект переименовать "Под мутным стеклом: пацаны внедряют аналитику!"?

Я бы не относился так строго к этому проекту (возможно, по субъективным причинам). Если бы он был на высочайшем профессиональном уровне - это не было бы таким интересным шоу, да и компании BigBuzzy некуда было бы потом совершенствовать свою аналитическую систему.
 
И как известно, "...впервые изделия из стекла появились в Древнем Египте и Месопотамии ок. 4 тыс. лет до н. э. Первые стёкла были цветными и непрозрачными. Из них делали украшения, амулеты" ;) Так что факт мутности стекла меня не сильно смущает - всему свое время ;)

Юрий, как правило документы вызывают много ненужных и не относящихся к предмету обсуждения дискуссий. К тому же есть ряд живых примеров, когда документ как бы есть, но полезной нагрузки в нем нет.
 
Что интересует из ТЗ конкретно? Количество аналитических разрезов (измерений)? Более 15- ти на модель, Архитектура? Описывали. Количество пользователей? Описывали. Быстродействие? Максимально возможное при описанной архитектуре (зависит от сети). Количество отчетов? От 20-ти.
 
Основной источник данных - база данных MySQL (не боевая).
 
С OLAP пока не заморачиваемся.

Юрий,
призываю Вас подписаться под изменением названия проекта на "Под мутным стеклом: реальные пацаны внедряют без документов".