резюме
Има много проекти за Business Intelligence или Data Warehouse, които завършват с неуспех. Това се разбира като "неизпълнение на очакванията": цена, срокове за доставка, полезност, качество на данните, използваемост от потребителите, участие на компанията, принос към резултатите и т.н….
Тук се опитваме да обясним някои ключове, базирани на в реални преживявания, които ни позволяват успешно да се справим с подобна имплантация.
1. Какво е Business Intelligence?
За да се постигне тази цел, първо е необходимо да се знае какво е Business Intelligence:
За съжаление, този термин няма нищо общо със средния коефициент на интелигентност на хората, които работят в определен бизнес. Всъщност бизнес интелигентността (BI) има общо с данните и приложенията на бизнеса, за да го разбере по-добре. Подобно на военното разузнаване, което се стреми да разбере врага, бизнес разузнаването е преди всичко за себе си. По-специално системите за бизнес разузнаване се основават на създаване на компютърни бизнес модели, така че да могат да функционират по-ефективно.
Съхраняването на данни е в основата на процесите на бизнес разузнаване. В света на ETL бизнес интелигентността обикновено се отнася до цялото пространство на системи от бази данни, софтуер, анализ и оценка на потребителите, които са предназначени за разбиране и оценка на бизнес.
По принцип има едно или повече аналитични приложения на софтуера (например Business Objects, Cognos или Microstrategy).
BI системите се различават от операционните системи по това, че са оптимизирани за заявки и отчитане на данни. Това обикновено означава, че в Datawarehouse данните се денормализират, за да поддържат въпроси с висока производителност, докато операционните системи обикновено са напълно нормализирани, за да поддържат референтната цялост и непрекъснато да вмъкват данни. ETL процесите, зареждащи BI системи, трябва да се превеждат от нормализирана към денормализирана операционна система. И обикновено те имат тежки неизправности, тъй като не трябва да влошават работата на операционните системи и не трябва да забраняват достъпа до склада.
Ето защо възниква Business Intelligence, базиран на нови структури за анализ, основно многоизмерни, за разлика от релационните.
2. Как да изберем приложение за Business Intelligence?
Първото нещо, което мога да кажа е, че трябва да определим какви са нуждите и вида на инструмента, който търсим: анализ, отчитане, база данни, OLAP и т.н….
В момента ще ви оставя няколко кратки удара, според моите критерии, на основните фактори (по ред на важност), които трябва да вземете предвид при избора на инструмент за бизнес анализ:
1) Платформата: Не е същото да бъдете обвързани с Microsoft или да можете да работите върху Unix или да имате стратегия с отворен код Linux. Същото важи и за хардуера. Някои производители са ограничителни.
2) Автобиографията на продавача: Много полезно е да се знае какъв тип реализации са направени, ако са извършени навреме, ако се използват, удовлетвореност на потребителите и т.н….
3) Размерът на куба: Важно е да се направи предварително анализ на ширината на информацията, която трябва да се съхранява. Някои приложения могат да "избухнат" на определено ниво.
4) Скорост на запитване: Потребителите винаги искат скорост в своите заявки. И ако 20 секунди чакане е твърде дълго, може да се наложи да намерите друг инструмент.
5) Поддръжка и помощни услуги по целия свят: Трябва да сме сигурни, че ако нещо не успее в приложението (и то ще се провали, това е сигурно), можем да го разрешим в най-кратки срокове.
6) Оценки на анализаторите: Gartner, IDC знаят за какво говорят… и обикновено са обективни. Струва си да разгледаме техните „квадранти“.
7) Екосистемата на продавача (консултанти, партньори, споразумения, общност на разработчици…).
8) Инсталирана потребителска база. Ако има много по-добре в моя сектор. Ако мога да говоря с тях и да видя инструмента на живо, още по-добре.
9) Графичен потребителски интерфейс (GUI). Не забравяйте, че говорим за инструмент за крайни потребители и ако те не ги харесат, те няма да го използват и ще бъдат пропилени пари.
10) Цената: Не е необходимо да е най-важното… но… важно е !!!
11) Интеграция с други инструменти: Нито един инструмент не работи като остров, изолиран от останалите. Същото като компания, ако създадете острови, ще създадете изолация.
3. Защо много проекти на Business Intelligence се провалят?
Понякога се учудваме, че с развитието, до което са стигнали много инструменти, използването на контрастирани методологии и по-високото ниво на познания на техниците и потребителите, възникват толкова много бедствия при внедряването на решенията на Business Intelligence по отношение на излишните разходи над планираното, неизползване от потребителите, което не отговаря на очакванията, грешна информация и т.н….
Въз основа на моя опит, ще ви разкажа за някои от основните недостатъци:
1) Много хранилища за данни нарастват в размер непропорционално, тъй като техниците не успяват да кажат „не“ на „прекомерни“ потребителски изисквания.
2) Предпочита се проектът да се изпълнява с хора от самата компания, когато те нямат нито време, нито знания, за да могат да го покрият.
3) Определят се нереалистични дати за влизане в производството, което
води до нови дати и повече закъснения.
4) Бюджетът, отделен за проекта, е нисък в сравнение със степента на сложност, която предстои да бъде разработена.
5) Изборът на софтуер и хардуер понякога се извършва по критерии на общи споразумения или ангажименти, а не чисто технически.
6) Преди проекта не се извършват сравнителни показатели или „доказателства за концепцията“ за определяне на осъществимостта.
7) Изходните данни не са чисти. Копиране, грешки, грешни знаци… предполагат по-скъп процес на ETL, по-голям размер на базата данни и по-лоша производителност.
8) Спонсорът на проекта не действа като такъв по време на него. Тя не „слиза на земята“.
9) Лош избор на консултанти и прекомерна ротация сред тях.
10) Малко участие на крайните потребители, което ги кара да изпитват някакво неудовлетворение от получените резултати.
11) Попадайте на грешката „всичко може да се направи в изчисленията“ и започнете с персонализиране, напишете код извън стандартните функционалности.
12) Не хармонизиране на проекта с бизнес стратегия.
Има още много фактори, които могат да направят проектът на Business Intelligence да се провали, но те могат буквално да го „съборят“, без да получават повече проекти за консултантите, лош имидж на продукта и вътрешни рискове за CIO и други спонсори.
4. OLAP системи. Съвети за правилното му използване.
Предполагаме, че сме извършили подробен анализ на нуждите на компанията, говорили сме с всички събеседници и потребители, идентифицирали сме нуждите от отчитане и достъп и накрая сме наясно с модела (какви променливи, формули, размери…) ще включим.
В този момент ние си задаваме ключовия въпрос: Какъв метод за съхранение ще използваме? Ние можем да разполагаме с всички данни в нашата транзакционна система, което ни позволява да го монтираме по-бързо, но може да бъде по-малко ефективна. Или можем предварително да изчислим информацията, така че да бъде получена бързо и точно. Това е много важно решение, защото може да предполага по-високи разходи за поддръжка и лицензи.
Тук е удобно да се изяснят тези съкращения:
OLAP е онлайн аналитична обработка. Това е начин за съхраняване на информацията в база данни, която позволява по-ефективно извършване на заявки. Това е съкратено определение, разбира се, реалността е по-сложна.
MOLAP: Многоизмерен OLAP. Както изходните данни, така и агрегираните или прекалкулирани данни пребивават в един и същ многоизмерен формат. Оптимизирайте заявките, но изисква повече дисково пространство и различен софтуер. Първата точка е оставяне на проблем: дисковото пространство става все по-евтино.
ROLAP: Релационен OLAP. Както предварително изчислените и обобщени данни, така и изходните данни се намират в една и съща релационна база данни. Ако DataWarehouse е много голям или е необходима скорост от потребителите, това може да е проблем.
HOLAP: Hybrid OLAP: Това е комбинация от предишните две. Обобщените и предварително изчислени данни се съхраняват в многоизмерни структури и такива с по-ниско ниво на детайлност в релационната. Това изисква добра работа на анализа, за да се идентифицират всеки тип данни.
От практическа гледна точка бих искал да добавя някои други характеристики на OLAP система:
- Трябва да е бързо. Той не трябва да бъде дълъг между необходимостта от информация и резултата.Тя трябва да има функционален и делови език. Трябва да е лесен за използване, с магьосници и шаблони. Трябва да може да интегрира API-та. Трябва да има мощни графични възможности. Обичайно.Възможност за съхраняване и споделяне на отчети и изчисления, създадени от потребителите.Администрацията трябва да се носи от потребители, а не от ИТ. Времето за изпълнение (проект) трябва да е много кратко. Трябва да генерира измерими отговори за вземане на решения. отколкото да можете да получите ROI с OLAP приложения.
Като окончателно обобщение можем да кажем, че трите основни аспекта, за които трябва да се погрижим, са изборът на хората, които ще използват инструментите, на тези, които отговарят за проекта и на външните консултанти. В допълнение към всичко това системата трябва да бъде в рамките на ясна средносрочна и дългосрочна бизнес стратегия, за да се избегнат пластирните решения и ненужните разходи.
