Меню

Процесс принятия решения и описание текущих бизнес процессов

|

Всю прошедшую неделю мы «ставили задачу» и сейчас расскажем, что получилось. Но сначала пара слов о выборе софта.

Всю прошедшую неделю мы «ставили задачу» и сейчас расскажем, что получилось. Но сначала пара слов о выборе софта.

Начиная процесс, мы понимали, что лишних людей у нас нет. Поэтому формирование отчетов будет задачей тех, кому эти отчеты нужны, невзирая на чины и звания. К счастью все директора и руководители направлений  знают, как работать с обычными офисными приложениями и понимают, какая информация им нужна для достижения целей. Единственное что нужно - это вменяемый инструмент, который оградит их от сложности физической структуры SQL-базы и поможет реализовать все «хотелки». Посмотрев на то, что есть на рынке и пообщавшись с народом, решили действовать по принципу – выбрать тех, кто будет более всего клиентоориентированным. И не важно маленький или большой продукт. В расчет включили все: функционал,  удобство использования и конечно цены. При этом в цене нужна полная ясность по всем параметрам: стоимость лицензии, обучения, сопровождения и консультаций. В итоге отметя много шлака оставили QlikViewи SAP BO. Взвесив все – выбрали SAP, а в качестве внедренца/консультанта – BI Partner. У них было правильное понимание наших пожеланий и возможностей относительно небольшой компании. Помимо всего прочего – важно, что партнер по внедрению имеет репутацию отвечать за свои слова и доводить даже самые безнадежные  проекты до светлого будущего.

По существу о результатах работы. Ребята из BI Partner приходили к нам в офис и проводили интервью. Сначала с бизнесом. Мы отталкивались от общих проблем в «пользовательской»

Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland

У вас уже есть учетная запись?

Войти

Обсуждения Количество комментариев28

Комментарий от  

Юрий Марьинский

  |  29 ноября 2011, 10:28

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

Комментарий от  

Евгений Литвиненко

  |  29 ноября 2011, 17:54

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

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

Комментарий от  

Юрий Марьинский

  |  29 ноября 2011, 20:54

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

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

Комментарий от  

Евгений Литвиненко

  |  30 ноября 2011, 09:16

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

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

Комментарий от  

Юрий Марьинский

  |  30 ноября 2011, 15:19

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

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

Комментарий от  

Александр Дублин

  |  30 ноября 2011, 17:25

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

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

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

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

Комментарий от  

Александр Дублин

  |  30 ноября 2011, 17:30

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

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

Комментарий от  

Юрий Марьинский

  |  30 ноября 2011, 17:58

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

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

Комментарий от  

Евгений Литвиненко

  |  30 ноября 2011, 18:07

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

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

Комментарий от  

Евгений Литвиненко

  |  30 ноября 2011, 18:34

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

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

Комментарий от  

Евгений Литвиненко

  |  30 ноября 2011, 18:38

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

С документами за такой срок не внедрить?

Комментарий от  

Юрий Марьинский

  |  30 ноября 2011, 21:45

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

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

Комментарий от  

Александр Дублин

  |  01 декабря 2011, 09:05

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

Юрий,
давайте называть вещи своими именами.
Ну какой это проект?! Нам не известен ни объем проекта, ни бюджет, срок проекта заявлен, но плана проекта также нет. Т.е. данное действо назвать проектом нельзя по определению.
 
На любые конкретные вопросы даются замутненные (туманные) ответы.
Грамотность текстов соответствует речам выступающих в программах Андрея Малахова на Первом :-)
....
 
Считаю, что правильнее было бы назвать "Под мутным стеклом: имитационное бла-бла шоу".
 
P.S. Компания захотела провести пиар-акцию для привлечения новых клиентов, но пиар - это не реклама, и при неправильном использовании этого инструмента результаты могут отрицательные. Самому очень жаль этих прекрасных ребят, но называть белое черным,  а черное белым даже по субъективным причинам не стоит.

Комментарий от  

Филипп Домитеев

  |  01 декабря 2011, 14:09

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

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

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

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

Ну что же давайте по порядку:
 
1. По процессу : выбор и внедрение, а также тестирование и использование у нас как не странно находится в одном процессе. Видимо для некоторых это неожиданно,но BigBuzzy это не госструктура и не коммерция , где менеджеры "пилят " бюджет и пытаются закрыться бумажками типа Устав проекта, Концептуальный проект, Дизайн проект и т.п. Мы живем только своей инициативой и драйвом. Поэтому нам нужен РЕЗУЛЬТАТ, а это в данном случае точные и удобно представленные цифры в нужное время. Все остальное от лукавого.
2. По людям - мы не вменяли ничего им в обязанность , эта обязанность у них с первого дня работы компании, потому что в этом бизнесе мы не можем позволить себе тратить время на освоение какого то бюджета.  Мы имеем только то, что сами заработали своим трудом, на основании интуиции, которую теперь необходимо подкрепить точными цифрами.  Правда в том, что многие из нас действительно в прошлой жизни поработали плотно в сфере ИТ и знают , что почем.
3. Касательно целей и информации , которая нужна.  На наше счастье мы не многопрофильный холдинг и цель компании в организации Акций, которые были бы интересны максимальному количеству пользователей. Подчеркиваю - не максимально прибыльных Акций, это тоже важно, но вторично, а именно тех, которые вызовут позитив у ее участников. А анализировать при подготовке Акции нужно массу информации: розничную цену, время покупки, количество просмотров на сайте, конвертацию посетителей в покупателей, профиль покупателей, историю их покупок, регионы покупок, количество возвратов и т.д.
4. Про "клиентоориентированность софта" оставлю без комментариев, я не очень понимаю, что это такое.  По мне  есть софт, который либо решает твою задачу, либо нет, остальное это также как "осетрина второй свежести". Мы такую не берем. Касательно "клиентоориентированности" компании, то тут все просто: компанию определяют сотрудники, которые в ней работают. Одни хотят просто продать, другие даже продавать не хотят (видно так все хорошо, что не очень надо), а третьи готовы и продать и сделать. Таких и выбираем.
5. Понятно, что в крупной матричной компании невозможно заставить офисный планктон работать не имея правильных бумажек, но даже там наиболее интересные идеи реализуются как раз вопреки этим бумажкам.  К сожалению пока в большинстве случаев у нас страна "динозавров", сидящих на газовой или нефтяной трубе или рядом с ней. У них все хорошо пока... Но и первые динозавры так наверное думали, пока не прилетел метеорит. И что же - нет динозавров, одни скелеты в музеях.  Это история не про нас.  Наша стеклышко как раз прозрачнее  некуда: заходи на сайт, смотри что тебе нужно и покупай если нравится. А дальше иди и пользуйся и если не понравилось, пиши на сайт в открытую и  получай деньги обратно.  Мы свою клиентоориентированность понимаем именно так, собственным рублем отвечаем.  А вы на такое готовы?

Комментарий от  

Евгений Литвиненко

  |  01 декабря 2011, 16:32

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

Юрий, названия отчетов ничего не скажут непосвященной публике. Потом вопрос - что называть отчетом? В SA BO отчет - это составная часть документа, так вот у нас есть варианты, когда в одном документе содержится до 10 отчетов (таких как в Cognos Query Studio). Пример названий документов Web Intelligence:
- Менеджеры, Все про продажи;
- Как работают менеджеры;
- Еще про менеджеров.
 
Это простые отчеты, в которых расчитываются основные показатели эффективности работы менеджеров (Да простит меня Александр Дублин, но руководители компании уделяют этому пристальное внимание) в разрезе акций, категорий сайта, типа акций, регионов, времени, иерархии подчинения. Там есть пара показателей ,которые вычисляются ну даже не по сложной, а очень длинной формуле.
 
Другая часть отчетов - отчеты по продажам, в которых анализируется различная информация о продажах, маркетинговых акциях. В этом блоке отчетности есть интересные запросы пользователей, допустим пресловутый показатель Сustomer lifetime value, который можно выцепить только только путем создания подзапросов к подзапросам к запросам и попутным наложением различных фильтров.
 
Аналитические же разрезы в основном мы не вычисляем по формулам, а берем те, которые живут в системе либо в виде отдельных справочников, либо в виде значений полей.
 
Живая витрина - это отдельностоящая база, которая инкрементально обновляется по мере изменения боевой базы. Технологию наши разработчики держат в секрете от нас, но, думаю, это не слишком сложная задача.

Комментарий от  

Евгений Литвиненко

  |  01 декабря 2011, 17:20

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

Комментарий от  

Филипп Домитеев

  |  01 декабря 2011, 17:40

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

Комментарий от  

Евгений Литвиненко

  |  01 декабря 2011, 17:57

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

Был недавно на конверенции SAP по ритейлу, слушал доклад представителя компании, большой компании. Так вот там именно так и происходило внедрение: сначала пользователи формировали требования, потом группа внедрения требовала от пользователей создать то, что они затребовали, в Excel . Затем пользователей заставляли месяц пользоваться этими отчетами Excel, чтобы они (пользователи) вносили изменения. А вот через месяц внедренцы начинали внедрять. И так по каждому отчету. Ну, за 2 года они внедрились и, вроде как, довольны.
 
Иы делаем то же самое за месяц. Экономия существенная :-).

Комментарий от  

Юрий Марьинский

  |  01 декабря 2011, 21:08

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

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

Комментарий от  

Евгений Литвиненко

  |  01 декабря 2011, 21:27

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

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

Комментарий от  

Юрий Марьинский

  |  01 декабря 2011, 22:41

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

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

Комментарий от  

Александр Дублин

  |  02 декабря 2011, 08:53

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

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

Комментарий от  

Алексей Чуканцев

  |  02 декабря 2011, 09:32

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

Юрий, SAP BO устроен немного по другому. Создание кубов не требуется, т.к. на основе БД создается семантический слой - юниверс, благодаря которому пользователь легко могут строить отчеты. Построение отчетов на основе юниверса, похоже на работу со сводными таблицами в Excel, только гораздо удобнее. Каждый запрос в документе, это своего рода микро-куб, и рассчитанные данные хранятся в кэше.

Комментарий от  

Сергей Шургин

  |  02 декабря 2011, 09:36

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

Юрий, приветствую! Все верно, Cognos MOLAP требует создания кубика(ков). Отсюда - что положим, то и получим. BO, как и Cognos BI ориентирован на работу с реляционной БД. Проект не предполагает создания витрины, работаем с тем, что есть. Поэтому, некоторые "продвинутые пожелания" просто остаются за рамками проекта. Алексей Чуканцев, я надеюсь, в самое ближайшее время даст ответ поподробнее.

Комментарий от  

Алексей Чуканцев

  |  02 декабря 2011, 10:07

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

Юрий, добрый день. Частично на ваш вопрос я ответил выше.
Один из способов оптимизации BO - это денормализация БД при построения юниверса. Второй способ – создание документов, которые сожержат в себе предагрегированные данные, которые являются источником данных для последующих документов BusinessObjects.
Третий способ - создание нескольких экземпляров WebIntelligenceProcessingServer для равномерной загрузки сервера.
Четвертый способ - в юниверсе применять преимущества индексов на ключевые поля для более быстрого получения данных.
Вообще, смысл построения юниверса и других объектов BusinessObjects заключается в том, чтобы с одной стороны бизнес-пользователь при построении отчетов не вникал в техническую реализацию решения аналитической системы, а использовал бизес-терминологию, принятую в Компании. С другой стороны, администратор/консультант BusinessObjects должен учитывать структуру представления/хранения данных источников. При необходимости, в источниках данных могут быть созданы дополнительные объекты, направленные на снижение нагрузки системы в целом (источников данных и системы BusinessObejcts).

Комментарий от  

Евгений Литвиненко

  |  02 декабря 2011, 11:33

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

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

Комментарий от  

Александр Дублин

  |  02 декабря 2011, 13:01

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

Комментарий от  

Евгений Литвиненко

  |  02 декабря 2011, 18:09

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

Спасибо, я попрошу наших ребят проанализировать и учесть на будущее