По поводу 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 пока не заморачиваемся.

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

Третьей системой вероятно будет упоминаемая ранее 1С, где структура БД, к счастью, документирована ;)
 
На какой же СУБД у вас сделаны витрины данных? Я раньше думал, что на MS SQL Server, но теперь (после слов Linux и MySql) я в этом не уверен...
 
То, что из SAP BO прописываете связи на текстовые файлы - это действительно не очень технологично. Но наверное файлы эти - небольшие, и производительность от них не пострадает. Только писать SQL-запросы к файлам наверное не особенно удобно.

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

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

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

1С будет, но не на этом проекте.
 
Витрина на MySQL. Для наших нужд пока хватает, перестанет удовлетворять переедем на Oracle.
 
С текстовыми файлами страшного ничего нет, еще на Cognos этим баловались, НО... 2 шага, которые могут сбоить, не гуд.

Третьей системой вероятно будет упоминаемая ранее 1С, где структура БД, к счастью, документирована ;)
 
На какой же СУБД у вас сделаны витрины данных? Я раньше думал, что на MS SQL Server, но теперь (после слов Linux и MySql) я в этом не уверен...
 
То, что из SAP BO прописываете связи на текстовые файлы - это действительно не очень технологично. Но наверное файлы эти - небольшие, и производительность от них не пострадает. Только писать SQL-запросы к файлам наверное не особенно удобно.

как-то заумно написали ))).
 
Все несколько проще. Есть (пока) 2 системы:
- Админка (самописка на MySQL),
- СRM (SalesForce.com).
 
С Админкой все понятно поля, таблицы, связи. В конце концов через стенку сидят разработчики, которые могут подсказать, что они имели в виду.
 
С SalesForce все оказалось печальней. Можно, конечно извращаться, строить в нем отчеты, экспортировать по расписанию в текстовые файлы, а потом к этим файлам прописать связи из SAP. НО в 21-м веке как-то несолидно. Однако другого варианта мы пока не нашли. ODBC драйверы к SalesForce, которые мы смогли найти, не распознаются SAP. Сам SAP CIS по этому поводу хранит гордое молчание, предложив нам приобрести Data Integrator, хотя в самом BO SalesForce в качестве источника прописан. Есть правда на совсем крайний случай способ вытаскивания данных из  SalesForce помимо экспорта в csv, но им можно пользоваться, если есть хранилище.
 
По поводу задачи тоже все просто, нужно считать Сustomer lifetime value. Первое обращение - это фактически регистрация на сайте, а дальше - что его (ее) побуждает к покупкам, что он (она) приобретает чаще и, наконец, приносит ли этот пользователь компании что-то еще, кроме хлопот.

Приятно видеть прогресс в вашем проекте ;)
 
Не совсем понял по поводу системы SalesForce.com - вы нашли какое-то решение по извлечению из нее данных, или пока ищете решение? В моем текущем проекте я использую эту систему как один из нескольких источников данных для OLAP-кубов и отчетов, создаваемых в одном из "шлаковых" программных продуктов ;) Пока мне приходится делать периодические выгрузки из этой системы в плоские файлы с дальнейшей их закачкой в витрины данных. Но западные внедренцы этой системы обещают познакомить меня с более технологичным способом доступа к этой системе...
 
Является ли секретным ваш документ ТЗ? Было бы интересно на него взглянуть.
 
И не совсем понятно по последней задаче - что такое первое обращение клиента в результате акции? Это когда он кликнул по вашему банеру, зашел на ваш сайт, но пока не зарегистрировался (а через 2 дня решил зарегистрироваться и купить данный купон)? Или акции у вас направлены на существующих зарегистрированных клиентов? Другими словами, первое обращение клиента не отловить из-за отсутствия данных в ваших базах, или данные есть, но SQL-запросы получаются очень сложными?