ФлеймерМожет. В 90% случаев, по мойму, обычного ОЛАП более чем достаточно.
Для того, чтобы навести порядок с данными - нет. Молоток нужно использовать именно для закалачивания гвоздей, а отвертку - для заворачивания шурупов.
andbaryЧто бы иметь нужную аналитику, необходимо данные (корректные).
Можно огласить более полный списочек требования к данным:
1.Полнота и достаточность;
2.Актуальность;
3.Согласованность и непротиворечивость;
4.Корректность (синтаксическая).
Для того, чтобы это обеспечить (по хорошему), нужны надёжные источники данных. Обрабатывать всё это на лету в асинхронном режиме - ПМСМ невозможно. Здесь я вижу два выхода:
-Либо мы содержим их в этом соответствии в учётной системе, выставив все ограничения, наладив синхронизацию и пр. пр.;
-Собираем всё до кучи в одном месте (можно с дублированием). Это кому как.
В итоге, чтобы получить качественные данные (нам же не нужен фиктивный анализ? Мы ведь для себя стараемся...;)) нужно приложить массу усилий и средств.
На сколько я понял, вы хотите в процесе анализа данных, пусть даже "почти" качественных, найти неточности в них неточности? Интересно, каким же образом вы собираетесь "деагригировав!!!:)" данные, найти, какой же бухгалтер вколотил циферку на два порядка больше нужной?
ФлеймерВ каждом конкретном сучаее свое решение. Только что вы хотели этим сказать?
То, что от типа хранилища напрямую зависит инфрастуктура данных. Если мы выбираем многомерное (ну мы же не дураки, нам скорость подавай!!! Что это ещё за ОЛАП, когда ждать до минуты нужно?!?!?!;)). Строим эту "легендарную" многомерную БД и радуемся. Вдруг оказывается, что забыли учесть один разрез аналитики. Ну небыло его, а при наведении порядка появилась возможность добавить. Отлично.., проектировщиков за гриву и вперёд перепроектировать базу, переписывать все процедуры загрузки и проч...
Вибираем реляционное - замечательно! Опять "снимаем снимок" со всех имеющихся данных предприятия, и принимаемся проектировать хранилище... (здесь уже ньюансов по организации взаимодействия имеющегося учёта и хранилища поболе будет, соответственно и изменения вносить гораздо сложнее). Сваяли. Обнаружилось, что не учли пару показателей. Где там наши проектировщики..... (а если они не наши!?).
Если принять во внимание, что процесс проектирования хранилища процесс достаточно длительный (0,5 - 1,5г.), то на внесение каждого изменения Вы потратите настолько побльше сил и средств, что Вам будет не до аналитики...

Если мы не используем ОЛАП, здесь уже совсем другая песня начинается...:) Здесь уже всё зависит от существующей инфрастуктуры данных предприятия.

Я это к тому, что выявлять ошибки в первичке намного проще без ОЛАПА, чем с ним. Возможно применение BI технологий здесь и приемлемо, сами пытаемся это выяснить:)
_____________________
С уважением , Андрей.

ФлеймерА теперь пожалуста в студию, что вы понимете под молотком и отверткой.
Молоток - система управленческого учёта. Здесь определяются что нам надо учитывать, что у нас есть возможность учитывать (некоторые данные, которые нам "хотелось бы" увидеть в анализе могут быть просто недоступны), в каких разрезах нам это интересно будет смотреть, какие конкретно показатели между собой сравнивать..., ВСЁ , ЧТО МЫ БУДЕМ АНАЛИЗИРОВАТЬ, МЫ ДОЛЖНЫ СНАЧАЛА УЧЕСТЬ! Расписать нужные аналитические разрезы, определить документы, в которых мы будем это учитывать, вставить поле для заполнения этого атрибута, посадить человека и сказать ему, что "вот сюда надо заносить такие-то и такие-то данные"... А уж потом вертеть в кубике с разных сторон. Не говоря уже о том, что всё это должно быть доступно и в отчётах (менее наглядно/удобно, но это основа) Более того, это основа не только для анализа, а для управления всем предприятием в целом.
Отвертка - система анализа. Здесь данные, учтённые нами ранее, анализируются с разных сторон с применением разных методик анализа, отыскиваются различного рода закономерности, выясняются причины конкретных событий, почему случилось так, а не иначе и пр.
ФлеймерМожет конкретную ошибку удобнее икать и обычными отчетами, дело привычки. Но сам факт наличия ошибки и место, где искать хорошо видно в ОЛАП.
Это напоминает мне процесс поиска ошибок в программе по откликам клиентов, а не на стадии тестирования:-) Самое главное оставить побольше комментариев!!!:)
ФлеймерС внедрением ОЛАП появляется заинтересованность в качестве данных у руководства. А заинтересованность руководства - это половина успеха проекта по приведению данных в нормальный вид.
Сначало бы разобраться с их полнотой и наличием вообще:)

ФлеймерТут вы описали технические проблемы самого ОЛАП. Они есть ну и что? Не внедрять?
Почему же? Внедрять. Только когда возмёшся разгребаться, откуда куда какие потоки данных идут, доберёшся до (хотябы) синхронизации систем, потом только и спохватишся: "Ээээ..., да тут надо бы...". И это хорошо, коли системы хоть как-то между собой были связаны... А если НЕТ!
А если систем не две-три а больше? Всем этим Вы будете заниматься во время проектирования хранилища данных?
ФлеймерЯ счас работаю с ROLAP инструментом. У меня половины ваших проблем нет.
Вы действительно думаете, что знаете мои проблемы?:)
Я считаю, что здесь вопрос уходит в сторну состояния системы учёта на конкретном предприятии перед началом внедрения BI. Если у Вас все системы согласованы, данные корректны и актуальны - то это ещё не говорит о том, что это везде так. Можете считать, что Вам повезло:)
_____________________
С уважением , Андрей.

ФлеймерЯ лично 4 раза прикручивал ОЛАП к ERP(или учетным) проектам.
Т.е. Вы имели дело непосредственно с синхронизированными учётными системами, и разногласия здесь возникают несколько другого характера, нежели при их стыковке с нуля. В том то вся и разница! Синхронизировав, дело доходит до интеграции, а далее - прямая дорога на BI и ОЛАП в частности. Вполне может быть, что шаг интеграции можно связать с внедрением BI, но только не шаг синхронизации!
Васильев АндрейМолоток -... Отвертка - ...
Несколько неудачная аналогия:( Возможно более подходящей может выступить простой отчет по первичке и агрегированный отчёт в BI. Здравие учёта надо проверять по первому, IT инфрастуктуры - по второму.
ФлеймерПри чем в двух случаях. ОЛАП просто спасал ЕRP проекты.
Это его прямое назначение:-))
Васильев АндрейВы действительно думаете, что знаете мои проблемы?:)
На это можно было не отвечать;) Идиотское высказывание, и как только у меня руки понялись напечатать это!?:)
ФлеймерВ этом случае надо запускать цепочку ООС.
Можете подробнее рассказать? Что-то я не нашёл в тексте:(
_____________________
С уважением , Андрей.

А вот мой прикуп:) Конечно не столь масштабный, по сравнению с Вашим, но тем не менее он показателен.
У промышленной компании имелось технологическое оборудование, продукция которого являлась её основным ремеслом. Особенность заключалась в большом количестве этого оборудования (с десяток цехов). Притом все они были как территориально, так и организационно распределены. Для автоматизации производства ещё при царе Горохе были закуплены комплексы телемеханики со своими базами, которые учитывали лишь основные их характеристики. Паралельно, в другой базе, вёлся реестр всех основных фондов и информация по ремонтам, состояниям и пр. При том как это у нас часто делается, автоматизировали (телемеханикой) большую чать оборудования, а на оставшуюся толи денег не хватило, толи не успели до того, как вдруг решили провести реорганизацию (притом как организационной, так и территориальной (перегруппировали цеха)). Тут подошли новые технологии телеметрии, и решили они оставшуюся часть оборудования автоматизировать по последнему слову техники (в, соответственно, новой базе). Продукция из каждого цеха поставлялась уже не на конкретный цеховой склад, а до которого было ближе ехать. Чтобы хоть как-то что-то учитывать, за каждой группой станков закрепили человека, который ходил с тетрадкой по местным блокам автоматизации, смотрел на плановые значения показателей, на реальные цифры, брал на ум что не сходилось, и колотил "факт":) Уж не знаю как всё до этого работало, но после таких изменений, последний источник правды просто умер! Где? какой станок? К какому цеху относится? На каком участке стоит? К какой розетке подключен? Сколько наработал? Притом один и тот же станок мог в разных (3х!) систамах фигурировать как разные объекты, мог иметь разную привязку, мог в любой из них отсутствовать, а мог и вообще оказаться не автоматизированным! А сами системы не имели о сушествовании дург друга никакого понятия (некоторые вещи я, конечно, немного утрирую, но это для красоты ситуации:)).

Где там наше BI!!!?? Сейчас мы запроектируем хранилище и всё в порядок придёт!;)
Какак здесь аналтика, какие разрезы!? Здаеь надо сначало найти источник правды (коим хранилище не может являтся в силу транзакционности данных), наладить синхронизацию между системами, а уже потом собирать все данные в одну кучу и анализировать.
ФлеймерЧто понимать под синхронизированными системами.
Не претендую на истину в последней инстанции, но я понимаю это так.
Синхронизация - организация обмена данными между системами. Т.е. отдельное точечное (на уровне бизнес-процессов) взаимодействие.
Интеграция (в идеале) - стандартизация хранения данных в системах (форматы дат, общих реквизитов), процедур обмена данными, их обработки и использования в рамках одной единой модели данных (на уровне приложений и бизнеса).
ФлеймерИ на превых порах качество работы подразделения только ушудшалось. При этом руководство не видело реальной немедленной пользы от внедрения. В целом создавалось впечатление, что не смотря на возню становится только хуже.
А кто говорил, что внедрять учётные системы легко?:) Внедрение учёта - самая тяжёлая и затрантная часть автоматизации предприятия. А самописных - вдвойне.
ФлеймерВидно в аналитике - работа сделана, не видно - нет. Как следствие, у руководства резко повысился интерес к проекту. Владельцы лично стремились скорее охватить весь холдинг
Менеджменту наконец-то дали в руки инструмент, который обеспечивает обратную связь с объектом управления. Хорошо отлаженый учёт с набором необходимых отчетов может дать те же результаты (обратную связь). Пусть менее наглядную, менее удобную, но для отладки учёта - в самый раз.
ФлеймерТакие товары объединили в наборы и дали скидку. Эффект был очень резким.
Вот это уже удел BI:)
ФлеймерВ этом случае надо запускать цепочку ООС.
ПМСМ, этого можно также достичь и в учёте, при наличии хорошей обратной связи (уже сказал). Про применимость обоих инструментов - тоже. Другое дело, что количество отчётов, необходимое для составления полной картинки может действительно оказаться чрезмерно большим:( Опять-же здесь можно сослаться на то, что сколько менеджера отчётами не корми, больше своей "нормы" он не переварит, и тут уже надо исходить из их информативности и полезности для конкретного менеджера конкретного предприятия.
_____________________
С уважением , Андрей.

MainframeОтчеты (в том числе агрегированные, в том числе OLAP), BI хорошее средство повышения качества данных. Но еще лучшим средством являются создание автоматического управления на основании данных.
Мне кажется Вы слегка недооцениваете потенциал BI. ПМСМ под это "загадочное" словосочетание вскоре объеденится не только новые технологии анализа, но и оперативного контроля и оперативного принятия решений в полуавтоматическом и автоматическом режиме. Другое дело, на каком уровне управления (оператор, менеджер или директор) принимается решение.
В частности под крыло BI некоторые поставщики уже поставляют функционал BAM (О их связи к примеру здесь: http://old.osp.ru/os/2005/10/024.htm). Осталось только помозговать над опаретивным анализом событий, и всем будет счастье:)
MainframeПока данные просто учетные, их нужность постоянно под вопросом и соответственно их качсетво там же.
Ну, допустим просто учётных данных наверное и в помине-то нет. Етсь хоть один отчет по ним - уже какая-то аналитика;)
Mainframeданные должны работать. Другое дело, что доверие к результатам обработки данных придется долго завоевывать ..
Полностью согласен!:)
_____________________
С уважением , Андрей.