Business Intelligence

01.08.2021

Klasa średnia

Oprócz zaawansowanych użytkowników i użytkowników biznesowych istnieje średnia klasa pracowników wiedzy, którzy (w normalnych okolicznościach) zachowują się jak użytkownicy biznesowi, korzystając ze standardowych raportów i wykorzystując tylko standardowe funkcje narzędzi front-end. Jeśli na przykład korzystają ze sparametryzowanych raportów, rzadko wykraczają poza dodanie podstawowych danych wejściowych w celu dostosowania ostatecznych wyników. Czasami jednak typy klasy średniej mogą cię zaskoczyć, projektując zapytania i raporty lub wykonując analizy poza ich strefą komfortu. W tym miejscu dobry, elastyczny projekt może wywrzeć ogromny wpływ. Dla klasy średniej najtrudniej jest zaprojektować, ponieważ zwykle nie wykraczają poza umiejętności użytkowników biznesowych. Ale ten tłum ma ukryte umiejętności użytkowników BI, które można wydobyć na powierzchnię, stosując dobre zasady gromadzenia wymagań aplikacji i projektowania. Gdy zaawansowane funkcje są bardziej dostępne i przyjazne dla użytkownika, mieszczą się w strefie komfortu szerszego grona użytkowników - na korzyść firmy. W czasie projektowania uruchom "Co by Ci zajęło, aby użyć tego … ? rodzaje pytań od przedstawicieli użytkowników, aby uzyskać informacje o tym, jak ułatwiają opanowanie funkcji eksperckich osobom niebędącym ekspertami. Jeśli sprytny projekt i opakowanie mogą zmienić konsumenta podstawowego raportu w użytkownika, który czuje się komfortowo dzięki złożonym ścieżkom analizy kierowanej i szczegółowej eksploracji danych, stworzyłeś silniejszego użytkownika.
Powrót

02.08.2021

Najlepsze praktyki w zakresie projektowania BI

Nie ma potrzeby wymyślania koła na nowo w fazie projektowania projektu BI. Chociaż BI jest stosunkowo nową dyscypliną, zasady dobrego, solidnego projektowania IT pozostają takie same. Najważniejszymi krokami będzie zaprojektowanie i zbudowanie docelowego środowiska danych o odpowiedniej strukturze, mocy i kontroli jakości. Jednym brudnym sekretem projektowania środowiska BI jest to, że nie zawsze można postępować zgodnie z ustaloną metodologią. Kupiona książka może zawierać wskazówki, aby zacząć od potrzeb biznesowych, a następnie przeprowadzić ocenę technologii, a następnie modelowanie danych - ale ta książka nie działa w Twojej firmie. Często jedyną opcją jest rozpoczęcie od tego, co już wiesz, a następnie opracowanie planu. Łatwiej powiedzieć niż zrobić. Przy tak wielu niezdefiniowanych zmiennych projekt BI ma bardzo mało solidnych podstaw na wczesnych etapach. To naturalne, że skupiasz się na tych kilku elementach, które są przybijane i budowane od tego miejsca, nawet jeśli planowałeś zacząć gdzie indziej. Na przykład, jeśli Twoja firma jest zaangażowana w określonego dostawcę oprogramowania, co powoduje, że zespół ds. zakupów nie chce kupować konkurencyjne oprogramowanie BI, które chcesz, to twój punkt wyjścia (tak jak jest). Hej, przynajmniej wiesz coś o tym, jak będzie wyglądało Twoje środowisko. Jasne, narzędzie, z którym utknąłeś, będzie miało pewne funkcje i ograniczenia, na które nie liczyłeś, ale musisz iść do przodu. Twoja droga przez labirynt zależy od tego, gdzie znajdują się ściany.
Powrót

03.08.2021

Projektowanie środowiska danych

System front-end Business Intelligence musi żywić się zebranymi, zagregowanymi danymi operacyjnymi, które dla niego przygotowujesz i gromadzisz. W przypadku większości środowisk BI ten zbiór danych, który ma być używany przez narzędzia frontonu, to hurtownia danych lub data mart. Analiza biznesowa to dostarczanie aktualnych, dokładnych, wartościowych i praktycznych spostrzeżeń. Dopóki te rewelacje biznesowe mają te cechy, masz środowisko BI, niezależnie od tego, czy działa ono w oparciu o hurtownię danych, hurtownię danych, czy coś zupełnie innego. Docelowa baza danych Na potrzeby tej dyskusji środowisko danych nazwiemy po prostu docelową bazą danych, a jej koncepcja i projekt będzie w dużej mierze funkcją kilku czynników:

•  Źródła danych: jakie informacje zawierają i w jakim stanie są te dane? Jak bardzo jest dostępny dla systemu BI?
•  Wymagania dotyczące zapytań: jakiego rodzaju pytania użytkownicy spodziewają się zacząć, aby rozpocząć analizę? Czy istnieją określone wzorce raportowania, które należy wziąć pod uwagę?
•  Wymagania dotyczące wydajności: jak szybko będą oczekiwać Twoi użytkownicy odpowiedzi?

Odpowiedzi na te pytania określą, w jaki sposób analitycy danych w Twoim zespole wybiorą środowisko danych, które najlepiej odpowiada potrzebom narzędzi BI.
Powrót

04.08.2021

Kompromisy w bazie danych

Dotarcie do środowiska danych przyjaznego BI oznacza zrównoważenie potrzeb dwóch odrębnych, ale powiązanych ze sobą funkcji: projektu ETL (który określa, w jaki sposób i kiedy dane źródłowe są przenoszone) oraz w jaki sposób użytkownicy docelowej bazy danych faktycznie wchodzą w interakcję z tymi danymi.

Projekt ETL

Procesy ETL (wyodrębnianie, przekształcanie i ładowanie) to kroki, które system podejmuje w celu przeniesienia informacji ze źródłowych systemów danych do docelowej bazy danych. To może wydawać się gruntowną pracą; może nie jest to efektowne, ale projekt procesu ETL jest jednym z najważniejszych czynników (jeśli nie najważniejszym) w pomyślnym funkcjonowaniu środowiska BI. Projekt bazy danych ma dłuższą historię (i wokół niego zbudowano obszerną literaturę), ale wraz ze wzrostem znaczenia BI, ETL zyskał na znaczeniu. Jego wyzwania przyciągnęły niektóre z najbardziej utalentowanych umysłów w branży w ciągu ostatnich 10 lat. Wyodrębnianie i ładowanie to po prostu przenoszenie danych, ale przekształcanie ich to podstawa złożoności - i gdzie dzieje się magia. Przekształcanie w tym sensie oznacza dokonywanie wszelkich zmian na poszczególnych elementach danych wymaganych do stworzenia jednego, użytecznego, poprawnego korpusu danych, który ma być używany przez aplikacje front-endowe BI. Na przykład: oprogramowanie ETL może być wymagane do konwersji kilku tabel z jednostek miary avoirdupois (wiesz: stopy, funty lub galony) na pomiary metryczne (metry, gramy lub litry). Oprogramowanie ETL będzie odpowiedzialne za odczytanie oryginalnego elementu danych avoirdupois ze źródłowej bazy danych, wykonanie obliczeń zmiany liczby na jednostkę metryczną, a na koniec zapisanie liczby konwersji metryki we właściwej lokalizacji docelowej bazy danych. Bazy źródłowe to Dziki Zachód Twojej firmy; nie wiadomo, w jaki sposób każdy lokalny szeryf przechowuje i przetwarza dane operacyjne, których potrzebujesz dla swojego systemu BI. Wiele może być nie tak z danymi i wiele może się nie udać w procesie transformacji. Część "Transformacja" ETL sprawia, że te dane są użyteczne. Jeśli pola danych muszą zostać zweryfikowane pod kątem złożonej logiki biznesowej, a następnie zmienione lub usunięte, to oprogramowanie ETL to umożliwia. A jeśli wiele źródeł danych zasila tę samą docelową bazę danych, produkt ETL musi rozpoznać nakładające się dane i wybrać prawidłową wartość, jeśli są różne. Twoje spostrzeżenia biznesowe są funkcją tego, jak wiarygodne i przydatne są informacje w docelowej bazie danych BI. Twoja docelowa baza danych jest funkcją tego, jak dobrze pakiet ETL poradził sobie ze źródłami danych. Jeśli dane zostaną załadowane w nierozpoznanym formacie lub jeśli same wartości są niedokładne, dane te są bezwartościowe dla użytkownika. Rysunek przedstawia uproszczoną wersję tego, co może zrobić proces ETL.



Listy telefonów w systemowych źródłach danych zostały utrzymane bez uniwersalnych standardów formatowania i informacji. Aby listy mogły być łączone i używane razem, bezużyteczne dane muszą zostać usunięte, zduplikowane wpisy muszą zostać usunięte, a informacje umieszczone we wspólnym formacie. Łatwo jest myśleć o ETL jako o magicznej różdżce transformacji, która leczy dane ze wszystkich jej bolączek, gdy przechodzi przez cudowne drzwi oczyszczające. W rzeczywistości jest to wielowarstwowy, skomplikowany proces, który obejmuje kilka kroków:

1. Pozyskiwanie danych z systemów źródłowych. Narzędzia muszą być w stanie działać według określonego harmonogramu i być przygotowane do interakcji z wieloma różnymi typami źródłowych baz danych i protokołów komunikacyjnych. Ekstrakcja czasami wiąże się również z gigantycznymi pasmami danych przemieszczającymi się po sieci firmowej, więc narzędzie ETL powinno być w stanie efektywnie radzić sobie z dużymi wolumenami.
2. Przeniesienie danych do obszaru pomostowego, gdzie można je oczyścić i uporządkować zgodnie z regułami biznesowymi procesu ETL.
3. Porządkowanie i odbudowywanie danych, powoli i ostrożnie, tak aby ich nowy kształt pasował do modelu docelowej bazy danych BI.

Stan źródeł danych ostatecznie określi projekt procesu ETL (wyodrębnianie, przekształcanie i ładowanie), który zbiera dane zgodnie z ustalonym harmonogramem, czyści je, przekształca do jednego formatu, którego mogą używać systemy front-end, oraz ładuje go do końcowego środowiska danych. Obecnie na rynku dostępnych jest wiele narzędzi ETL, które pomagają twórcom danych w stworzeniu procesu, który zaspokoi docelową bazę danych w to, czego potrzebuje. Zaangażuj największe talenty swojego zespołu w zadanie zaprojektowania solidnych procesów ETL - na teraz i na przyszłość. Zbyt ważne jest pozostawienie osobom, które nie wiedzą lub nie są pewne, jak podejść do problemu, jak radzić sobie z typowymi pułapkami i jak przetestować swoją pracę.

Kompromisy docelowe


Kiedy dane dotrą do docelowego środowiska, Twój system BI staje w obliczu kolejnego działania równoważącego: to, co baza użytkowników robi z Twoimi danymi, ostatecznie określi rodzaj środowiska danych, które zostanie zbudowane. Zgodnie z najlepszymi praktykami potrzeby użytkowników muszą mieć wpływ na projekt środowiska danych co najmniej tak samo, jak ma to miejsce w przypadku technologii ETL. Oto dwa typowe scenariusze:

•  Jeśli Twoi użytkownicy szukają elastyczności w tworzeniu zapytań na dowolnym fragmencie danych w dowolny sposób, kształt lub formę, docelowa baza danych będzie musiała być stosunkowo znormalizowanym środowiskiem. Oznacza to mniejszą redundancję i tylko ograniczone dane podsumowujące. Zapytanie w takim środowisku zajmuje dużo czasu, ale Twoi użytkownicy dostaną to, czego chcą.
•  Jeśli użytkownicy postępują zgodnie ze standardowymi wzorcami przeglądania danych - na przykład przeglądają raporty wzdłuż linii tematycznych, takich jak informacje o sprzedaży lub produktach - wtedy docelowa baza danych prawdopodobnie będzie projektem wielowymiarowym. Ten typ bazy danych jest idealny do działań typu "plaster and dice", które podkreślają różne aspekty danych, ale zapewnia również większą nadmiarowość i mniej efektywne wykorzystanie przestrzeni.
Powrót

05.08.2021

Projektowanie środowiska frontendowego

Nie ma odpoczynku dla znużonych po zakończeniu podstawowych prac projektowych w środowisku zaplecza. Proces ETL zapewnia przepływ danych źródłowych do docelowego środowiska danych, ale gdy już tam dotrze, będziesz musiał zaprojektować sposoby dostępu użytkowników do przechowywanych danych. W większości środowisk BI systemy front-end obejmują raportowanie, zapytania i wszystkie poziomy ogólnych i niestandardowych pakietów analitycznych
Powrót

06.08.2021

Raporty

W przypadku każdego rozwiązania analizy biznesowej rdzeniem frontendu jest środowisko raportowania.

Standardowy projekt raportu

Twoi programiści zaprojektują i opracują rodzinę standardowych, prefabrykowanych raportów dla interfejsu BI. Raporty te stanowią podstawę środowiska Business Intelligence. Zwykle składają się z podstawowych informacji biznesowych, podzielonych na linie biznesowe (lub obszary tematyczne) i przedstawionych w formie tabelarycznej. Chodzi o to, aby pomóc czytelnikowi zrozumieć, co dzieje się w firmie - tak szybko, jak to możliwe. Raporty wymagają danych, a wypełnienie raportu danymi wymaga co najmniej jednego zapytania. Tak więc pierwszym krokiem w tworzeniu dowolnego standardowego raportu jest zdefiniowanie zestawu zapytań, które żądają odpowiednich danych z docelowej bazy danych. W niektórych przypadkach raport może wymagać wielu zestawów danych. Na przykład możesz mieć dane o przychodach w jednej tabeli faktów, a koszty w innej. Aby pokazać wkład produktu, możesz potrzebować dwóch oddzielnych zapytań, aby połączyć te dwa źródła. Twoje narzędzie front-endowe będzie musiało połączyć dwa zestawy wyników, które pochodzą z zapytań, aby można było obliczyć przychody minus koszty. Proces opracowywania tego raportu będzie obejmował kodowanie zapytań w celu pobrania dwóch zestawów danych, manipulowanie informacjami w celu utworzenia danych dotyczących wkładu produktu oraz kod, który składa się z widocznego raportu. Oznacza to decydowanie o tym, co trafia do wierszy i kolumn, jakie obliczenia mają miejsce w raporcie i jak raport powinien być sformatowany. Ponadto zespół programistów może być zmuszony do opracowania innych szczegółów dotyczących tego raportu, takich jak ustalenie najlepszego źródła danych i zarządzanie szczegółami administracyjnymi (takimi jak sposób uzyskiwania dostępu do raportu i jego zmiany). Kluczem do stworzenia efektywnego formatowania raportów jest idea, aby były one możliwie jak najłatwiejsze do zrozumienia, bez potrzeby zewnętrznego wyjaśnienia lub dokumentacji referencyjnej. Zespoły BI często stają przed wyzwaniem znalezienia właściwej równowagi między przejrzystością raportu a względną użytecznością wyświetlania danych w bardziej złożonych wzorcach. Chociaż wiele osób jest kompetentnych w tworzeniu raportów, robienie tego dobrze wymaga połączenia talentów dobrze ugruntowanych w architekturze informacji, zrozumieniu biznesu, a nawet projektowaniu graficznym. Autorzy raportów są specjalistami; dobry może dodać dużą wartość do procesu BI. Jest to szczególnie ważne, gdy tworzysz podstawowe szablony, na których będą oparte wszystkie przyszłe raporty standardowe. Jeśli teraz zmienisz ten wysiłek, wróci, by cię prześladować.

Warstwa metadanych

Deweloperzy baz danych i architekci BI prawdopodobnie spędzą dużo czasu na opracowywaniu metadanych: zestawu definicji i relacji opisujących informacje przechowywane w każdym komponencie systemu. Metadane to informacje na poziomie pola i tabeli, które umożliwiają wszystkim aplikacjom do obsługi danych interakcję ze sobą, w tym systemami źródłowych i docelowych baz danych, zestawem narzędzi ETL, aplikacjami do przetwarzania analitycznego online (OLAP), a nawet narzędziami do administrowania danymi. W dawnych czasach metadane nazywano słownikiem danych, zasobem używanym zarówno przez programistów, jak i użytkowników, gdy podejmowali jakiekolwiek działania, które miały wpływ na dane. Zamiast pozostawiać właściwości i skojarzenia danych otwartymi do interpretacji, metadane zapewniają pojedynczy punkt odniesienia dla wszystkich: użytkowników, analityków, programistów i administratorów. Ponieważ rzeczywisty schemat docelowej bazy danych może być bardzo zagmatwany (i mało prawdopodobne, aby dostarczał użytecznego kontekstu danych), użytkownicy zwracają się do metadanych. Sposób przechowywania i uzyskiwania dostępu do metadanych jest obecnie gorącym tematem wśród projektantów. Metadane są często gromadzone w scentralizowanym repozytorium, zbudowanym na zamówienie lub zakupionym od sprzedawcy. To repozytorium może być pojedynczym obiektem, który dostarcza uniwersalne metadane do wszystkich aplikacji w firmie, lub może być zdecentralizowane, aby służyć unikalnym potrzebom poszczególnych aplikacji. Każde podejście ma swoje zalety i wady, ale podejście scentralizowane jest bardziej powszechne. Skuteczna komunikacja poprzez raportowanie wymaga stworzenia solidnego zestawu standardowych szablonów do przechowywania informacji. Ponadto szablony te powinny być zgodne z zestawem standardów informacyjnych, dzięki którym raporty są bardziej wartościowe i przyjazne dla użytkownika. Raporty standardowe mają stały (lub w większości stały) format, oparty na dobrze rozumianych standardowych parametrach (takich jak okresy czasu lub linie produktów). Niezależnie od tego, czy jest oparty na szablonie, czy nie, każdy raport powinien zawierać standardowe dane, takie jak następujące elementy:

•  Nazwa raportu
•  Zgłoś kategorię lub rodzinę
•  Data i godzina utworzenia raportu
•  Nazwa systemu źródłowego
• * Źródło referencyjne lub help desk

Ponadto we wszystkich raportach należy ustawić i przestrzegać następujących standardowych funkcji:

•  Zastrzeżenia prawne i polityka prywatności
•  Typ i rozmiar czcionki dla nagłówków i pól danych
•  Szczegóły uzasadnienia kolumn
•  Informacje o kolorze i logo firmy
•  Formatowanie liczb dla waluty, dat itd., w tym poziom dokładności
•  Włączenie lub wyłączenie źródeł danych i nazw zapytań (lub całych ciągów zapytań) w raporcie

Najprawdopodobniej Twój zespół przyjrzy się najczęściej tworzonym raportom i utworzy rodzinę szablonów raportów, które będą udostępniane przez społeczność. Ponadto zostaną również zbudowane i zaplanowane do regularnego uruchamiania lub zgodnie z potrzebami społeczności użytkowników podstawowe raporty. Standardowy system raportowania składa się z kilku elementów technologicznych:

•  Narzędzie do definiowania i budowania raportów, z którego korzysta projektant raportów (albo ktoś z branży IT, albo doświadczony użytkownik biznesowy).
•  Usługi zarządzania przechowywaniem, wykonywaniem i bezpieczeństwem raportów.
•  Portal, za pośrednictwem którego użytkownicy końcowi mogą wybierać i przeglądać raporty (często system oparty na przeglądarce).

Oto pytanie, które warto zadać: Zanim pojawił się twój nowomodny system BI, w jaki sposób firma przetrwała bez raportów? Odpowiedź jest oczywiście taka, że nie; istnieje wiele istniejących raportów krążących po starym środowisku. Dostarczając raporty, nie wkroczysz na nowe tereny, ale dostarczysz nowy rodzaj raportu - w oparciu o szerszy zakres danych, które będziesz gromadzić. Narzędzia BI dają również możliwość kontrolowania dystrybucji i obsługi raportów z dużo większą precyzją. Może być kuszące, aby skopiować zestaw tych starych raportów i po prostu używać ich w nowym środowisku, ale uważaj na ryzyko związane z takim postępowaniem. Może istnieć wbudowana logika biznesowa lub dane, które nie przełożą się na nowe środowisko. Dane mogą nie mieć sensu w nowym kontekście lub mogą w ogóle nie być wyświetlane. Jak najbardziej, weź najlepsze elementy starego systemu - ale aby jak najlepiej wykorzystać nowy system, będziesz chciał zaprojektować nowe środowisko raportowania od zera. Zespół projektujący raporty zapewnia również dostęp do raportów; ci, którzy korzystają z raportów, używają kontrolowanego portalu do przeglądania i korzystania z tych, których potrzebują, zgodnie z ich poziomami bezpieczeństwa. Zgodnie z najlepszymi praktykami wdrażania BI, twórcy raportów są odpowiedzialni za wykorzystanie wymagań biznesowych zebranych od użytkowników i interesariuszy w celu stworzenia listy raportów z priorytetami. Raporty z tej listy zostaną opublikowane przy pierwszym uruchomieniu systemu. Najlepszym sposobem na utworzenie listy raportów według priorytetów jest rozpoczęcie od pełnej listy kandydatów utworzonej w trakcie pozyskiwania wymagań. Każdy raport powinien być oceniany pod kątem jego wartości biznesowej i trudności w zbudowaniu. Wtedy Twój zespół będzie musiał zdecydować, które raporty można zbudować dla tej wersji, a które będą musiały poczekać do późniejszego okresu. Wiele środowisk raportowania ma kilka składników - w tym narzędzia deweloperskie, przeglądarki raportów, narzędzie administratora i serwer raportów. Instalacja i konfiguracja frontowego narzędzia do raportowania może zająć więcej pracy, niż można by się spodziewać.
Powrót

07.08.2021

Projekt dostępu do informacji ad hoc

Jeśli Twoje środowisko ma wspierać użytkowników, którzy chcą więcej niż standardowe raporty, musisz stworzyć solidne środowisko raportowania ad hoc. Raporty ad hoc są niezwykle cenne dla konsumentów informacji; pozwalają pracownikom działać poza informacjami zawartymi w standardowych, puszkach raportach. Środowisko raportowania ad hoc udostępnia kluczowe elementy bazy danych użytkownikowi, który może następnie wybrać spośród nich, aby utworzyć raport niestandardowy. Aby być efektywnym twórcą raportów, użytkownik musi zrozumieć bazowy model danych w docelowej bazie danych BI. Dlatego firma, która polega na narzędziach raportowania ad-hoc, musi zaprojektować logiczny model danych, który ma sens dla jej odbiorców informacji. Oznacza to, że podmioty powinny pasować do rzeczywistych elementów biznesowych; hierarchie stosowane do opisu danych powinny się sumować, zarówno w przenośni, jak i dosłownie. Na przykład użytkownik powinien być w stanie napisać jedno zapytanie dotyczące łącznej sprzedaży za październik, listopad i grudzień i uzyskać taką samą sumę, jak gdyby raport został wygenerowany za czwarty kwartał tego samego roku. Istnieje wiele narzędzi front-end BI, które specjalizują się w raportowaniu ad-hoc - na przykład produkt Microsoft Report Builder (który jest dostarczany z SQL Server). Dla użytkowników, którzy lubią standardowe raporty, ale potrzebują elastyczności, aby wprowadzać zmiany, niektóre narzędzia do raportowania ad hoc oferują rozwiązanie "pomiędzy". Użytkownik zaczyna od standardowego szablonu raportu, a następnie wpisuje zmienne danych, które musi zobaczyć. W bardziej elastycznych i abstrakcyjnych środowiskach użytkownik zaczyna od czystej karty, dosłownie jest w stanie zaprojektować raport od podstaw.
Powrót

08.08.2021

Projekt OLAP

Przetwarzanie analityczne online (OLAP) to wysoce wyspecjalizowana implementacja środowiska raportowania ad-hoc. Zamiast raportów statycznych, front-endowe narzędzie OLAP daje użytkownikom wielowymiarowy widok danych źródłowych, w którym informacje można zmieniać w locie, aby zaspokoić szybko zmieniające się potrzeby biznesowe. W środowisku OLAP dane są przechowywane według faktów centralnych, takich jak pojedyncze transakcje sprzedaży, i można je odpytywać według dowolnej kombinacji wymiarów powiązanych z tymi faktami. Zamiast przepisywać złożone zapytania i czekać, aż system zwróci zestaw danych, użytkownicy mogą natychmiast manipulować zestawem danych, zmieniając kolejność, nawigując po różnych wymiarach i stosując metody "drążenia" (drążenie, drążenie, drążenie). przez), aby znaleźć tylko ten kąt informacji, którego szukają . Narzędzia front-endowe OLAP oferują elastyczną analizę i raportowanie, które mogą zasilać wiele różnych obszarów działalności - od strategii w biurze narożnym po taktyczne wsparcie decyzji. Na rynku dostępnych jest wiele narzędzi OLAP, a konkretne wdrożenia mogą się różnić w zależności od produktu. Ogólnie rzecz biorąc, projektowanie rozwiązania front-endowego OLAP obejmuje cztery główne kroki:

1. Zidentyfikuj zmienne, które mają być śledzone, mierzone lub opisane.
2. Pogrupuj zmienne w logiczne domeny powiązania.
3. Zdefiniuj relacje między głównymi podmiotami. Skonsultowanie się z ekspertem OLAP może pomóc Twojemu zespołowi w zdefiniowaniu członków wymiaru, hierarchii, miar i atrybutów.
4. Zdefiniuj wzory i wyprowadzenia, które służą do agregowania i łączenia miar w sposób użyteczny dla użytkowników końcowych.

Czasami dane wymiarów mogą być ukryte. Jeśli konwertujesz dane tabelaryczne na model wymiarowy i nie masz pewności, co jest faktem, a co wymiarem, dobrym punktem wyjścia jest założenie, że atrybuty z kluczem są wymiarami, a atrybuty, które nie są kluczowane, są faktami. W przypadku danych arkusza kalkulacyjnego poszukaj sposobu podziału danych na grupy. Jeśli (na przykład) główny arkusz kalkulacyjny wyników sprzedaży produktów zawiera 15 różnych arkuszy roboczych reprezentujących 15 działów firmy, wówczas podział jest ważnym wymiarem, który użytkownicy będą chcieli rozróżnić podczas analizowania raportów.

Diagramy relacji encji

Diagram relacji encji (ER) jest powszechnym narzędziem w projektowaniu baz danych. Modeluje zarówno jednostki w bazie danych, jak i relacje między nimi, pokazując migawki dokładnie tego, jak dane są zorganizowane logicznie w bazie danych. Podstawowe symbole reprezentują główne składniki informacji. Pomyśl o jednostce jako o logicznej klasie danych - w efekcie każdy ważny element informacji, na dowolnym poziomie, jest ważny dla reprezentowanych danych. Tabela w bazie danych (na przykład) może zwykle być reprezentowana jako jednostka. Z drugiej strony atrybuty opisują byty. Na przykład, jeśli śledzisz elementy informacji, takie jak właściciel pojazdu, producent pojazdu, numer identyfikacyjny pojazdu i tablica rejestracyjna pojazdu, w tym przypadku podmiotem będzie pojazd, ponieważ wydaje się to opisywać każde z tych pól. Atrybuty związane z pojazdem to właściciel, producent, numer identyfikacyjny i tablica rejestracyjna. Ten typ modelu jest niezbędny w projektowaniu wszelkiego rodzaju baz danych; jest to szczególnie przydatne w projektowaniu systemów BI, gdzie wiele środowisk danych ma te same koncepcje i pomysły. Prawdziwą wartością diagramu ER jest to, że zmusza projektanta bazy danych do całkowitego zdekonstruowania przechowywanych informacji. Jeśli dobrze rozumiesz, w jaki sposób encje danych i relacje mapują się na siebie, możesz użyć ich do złożenia modelu danych niskiego poziomu, który może pomóc w kształtowaniu rzeczywistego tworzenia bazy danych, jej struktury tabel i pól. Budowanie diagramu ER może być wyzwaniem, szczególnie w środowisku korporacyjnym, które ma dużą, złożoną strukturę tabel. Środowisko hurtowni danych staje się jeszcze bardziej skomplikowane, ponieważ dwa różne źródła danych mogą przechowywać nakładające się informacje. Na przykład dwa systemy w szpitalu mogą mieć jedną tabelę o nazwie Klienci, a drugą o nazwie Pacjenci. Traktowanie tych dwóch podmiotów przez ich odpowiednie nadrzędne źródła danych jest istotną różnicą do zbadania; modelowanie może pomóc temu procesowi, a także procesowi, który łączy te dwa w jednolitą całość.

Aplikacje analityczne i do eksploracji danych

Te aplikacje znajdują się na szczycie drabiny złożoności - ale zasadniczo służą temu samemu celowi, co każdy inny system front-end BI: dostarczaniu użytkownikom informacji biznesowych w dowolnej formie, która jest dla nich najbardziej użyteczna. Niektóre z najbardziej zaawansowanych aplikacji analitycznych mają na celu przewidywanie, a nie tylko opisywanie, budowanie modelu przeszłości, który można wykorzystać do przewidywania przyszłych wydarzeń, przewidywania dostępnych wyborów i umożliwiania analitykom gry (jak w "teorii gier", a nie jak w Monopoly) możliwości. Aplikacje analityczne koncentrują się na określonym aspekcie procesu biznesowego - takim jak sprzedaż, zapasy lub produkcja - i próbują wykryć przydatne trendy za pomocą wstępnie załadowanych algorytmów. Oprogramowanie analityczne zostało stworzone nie tylko do wykrywania trendów z przeszłości, ale także do prognozowania przyszłości. Na przykład, jeśli zbierasz ogromną ilość danych dotyczących sprzedaży klientów dla dużej sieci detalicznej, aplikacja analityczna może stworzyć złożony model zachowań zakupowych na Twoim rynku. Aplikacja wychwytuje trendy, których rozpoznanie zajęłoby ludzkim oczom całe wieki. Co najważniejsze, możesz użyć tego modelu klienta do przewidywania, jak klienci mogą zareagować na zmiany cen lub promocje. Pod względem projektowania i rozwoju podejście jest w dużej mierze takie samo. Zaczynając od ogólnych celów biznesowych, analitycy i projektanci powinni wyprowadzić scenariusze "co, jeśli" i pytania, na które nie można odpowiedzieć, po prostu patrząc na podsumowanie wczorajszych danych. Poszukiwane wzorce są skodyfikowane w szersze cele analityczne. Jednak w dążeniu do tych celów aplikacje analityczne cierpią z powodu typowych pułapek wszystkich aplikacji front-end BI:

•  Programy analityczne są tak dobre, jak dane, które je zasilają. Oznacza to, że źródła danych muszą być sprawdzane i monitorowane pod kątem jakości i spójności danych. Nie jest niczym niezwykłym, że firmy wydają fortunę na wysokiej klasy narzędzia analityczne tylko po to, by odkryć, że opracowane wnioski i prognozy są bezwartościowe z tego prostego powodu, że podstawowe dane są nierzetelne lub niedostępne.
•  Zaawansowane oprogramowanie do raportowania i prognozowania jest tylko tak dobre, jak model danych używany do wypełniania mechanizmów analitycznych. Jeśli świat rzeczywisty nie pasuje do tego, co oprogramowanie uważa za świat rzeczywisty, prognoza i analiza zostaną wyłączone. Aplikacje analityczne tworzone przez największe firmy programistyczne zwykle korzystają z tej samej docelowej bazy danych, z której korzystają inne aplikacje BI. Zakładając, że model jest solidny, spostrzeżenia uzyskane z aplikacji analitycznych powinny być przynajmniej pod względem ilościowym poprawne. To, czy masz odpowiednich ludzi do interpretacji tych informacji, to inna sprawa.
•  Aby analityka działała, raporty muszą być użyteczne i odpowiednie dla firmy. Oznacza to, że potrzebujesz indywidualnych współpracowników, którzy mogą w pełni wykorzystać aplikacje analityczne, aby regularnie uzyskiwać informacje. Ale co więcej, firma musi być gotowa do reagowania na to, co mają do powiedzenia aplikacje do eksploracji danych i analiz. Jest to bardziej prawdopodobne, jeśli aplikacja jest poprawnie połączona z innymi systemami w środowisku BI. Silnik analizy musi być zsynchronizowany z modelem danych i musi w pełni wykorzystywać środowisko raportowania do prezentacji i dystrybucji wyników.
Powrót

09.08.2021

Pozyskiwanie użytkowników na pokładzie

Najlepszym sposobem na upewnienie się, że społeczność użytkowników jest zadowolona z wykonywanej pracy, jest zaangażowanie jej w proces projektowania. Łatwiej to powiedzieć niż zrobić w przypadku zupełnie nowych aplikacji, dla których użytkownicy mają niewiele lub nie mają żadnego punktu odniesienia.
Powrót

10.08.2021

Raportowanie przeglądu

Ale w przypadku środowiska raportowania masz do czynienia ze znajomym gruntem dla użytkowników. Są przyzwyczajeni do oglądania informacji w określonym formacie o określonych porach. Nowe środowisko raportowania powinno zostać udostępnione wyselekcjonowanej grupie doświadczonych użytkowników, którzy są otwarci na nowy system, ale także chętnie udzielają uczciwych informacji zwrotnych. Poproś grupę użytkowników o sprawdzenie i zatwierdzenie następujących informacji:

•  Przejrzyj listę standardowych raportów o wysokim priorytecie; upewnij się, że wszelkie luki można wypełnić w środowisku ad hoc lub dostosowując jeden z istniejących szablonów.
•  Przejrzyj raporty, aby upewnić się, że prawidłowo wyświetlają dane.
•  Upewnij się, że raporty są czytelne, a tytuły, nagłówki i dodatkowe informacje (takie jak instrukcje) są prawidłowe.
•  Współpracuj z twórcami raportów nad kalendarzem "run-and-release"; harmonogram powinien zapewniać, że dane docierają do niezbędnych celów na czas.
•  Pokaż społeczności użytkowników, jak poruszać się po narzędziu do raportowania. Sposób, w jaki zorganizowałeś standardowe raporty i informacje wyjaśniające, powinien mieć sens dla codziennych konsumentów tych informacji.
•  Przeprowadź demonstrację możliwości nowego środowiska - w szczególności nowych funkcji, które odróżniają je od starszego systemu (powiedzmy, zgrabny nowy interfejs oparty na przeglądarce lub zaawansowane narzędzia, które są dostępne po raz pierwszy).
•  Wypróbuj wszystkie raporty drążenia lub drążenia wszerz, aby upewnić się, że informacje są połączone prawidłowo, a łącza drążenia są logicznie rozmieszczone i widoczne.
•  Rozpowszechniaj bibliotekę szablonów raportów i upewnij się, że informacje wyświetlane w każdym raporcie są zgodne ze standardami firmy i projektu.
Powrót

11.08.2021

Testowanie, 1-2-3 …

Proces zapewniania jakości w środowisku BI będzie prawdopodobnie przypominał inne duże projekty technologiczne: niestety oznacza to, że często jest to wykonywane w sposób przypadkowy, bez żadnego realnego planu, jeśli w ogóle się to robi. Nie możesz sobie pozwolić na zwykły testowy chaos w projekcie BI. Testowanie jest istotną częścią procesu projektowania i wdrażania dla BI, ponieważ błędy wykryte w tym momencie są znacznie tańsze i łatwiejsze do naprawienia niż byłyby po uruchomieniu systemów. Testowanie odbywa się w kilku różnych fazach i smakach:

•  Testowanie jednostkowe: jest to najniższy poziom testowania, jaki wykonują programiści. Czy biblioteki kodu kompilują się w pliki binarne? Czy aplikacje ładują się pomyślnie?
•  Testowanie integracji: na tym etapie testujesz, czy komponenty rozmawiają ze sobą. Czy aplikacja ETL może komunikować się ze źródłowymi systemami danych? Czy aplikacje front-end współpracują ze sobą zgodnie z założeniami?
•  Testowanie zapewniania jakości (QA): jest to punkt, w który angażują się profesjonalni testerzy. Jeśli wszystko pójdzie zgodnie z planem, analitycy QA piszą skrypty testowe, które sprawdzają działanie każdego komponentu w systemie w stosunku do oryginalnych specyfikacji. Oznacza to testowanie wszystkiego, od jakości danych w raportach po wygląd samych raportów - wraz z wszelkimi jakościowymi miarami wydajności, takimi jak czas zwrotu, wskaźniki błędów lub opóźnienia.
•  Testy akceptacji przez użytkowników: tutaj grupa użytkowników końcowych w końcu dostaje swoje ręce do aplikacji, poddaje ją testom i zgłasza problemy.

Utrzymuj ścisłą kontrolę nad testami akceptacyjnymi użytkownika lub szybko wymknie się spod kontroli. Zaplanuj proces testowania dla użytkowników świnek morskich, dostarczając im skrypty testowe, oczekiwane wyniki i stały harmonogram zgłaszania problemów i komentarzy. Często zdarza się, że użytkownicy zmieniają zdanie w związku ze specyfikacją aplikacji (lub po prostu nie pamiętają, o co prosili) i zgłaszają to jako problem. Możliwe, że niektórzy testerzy nie byli zaangażowani w proces tworzenia wymagań na początku i poproszą o dodanie dodatkowych funkcji do projektu w tak późnym terminie. Dokumentuj swoje testy w taki sam sposób, jak dokumentujesz specyfikacje systemu. Niech specjaliści ds. kontroli jakości stworzą plan testów i przypadki testowe, podczas gdy programiści wciąż budują i kodują system. Dokumentuj wynik każdego testu i zapisuj wyniki do wykorzystania w przyszłości. Powód tego jest prosty: kiedy później uaktualnisz system, będziesz musiał przeprowadzić testy regresji, aby upewnić się, że ulepszenie lub uaktualnienie niczego nie zepsuło. Bez dokumentacji z początkowej fazy testów będziesz musiał ponownie wymyślić coś, co może być dość złożonym kołem.
Powrót

12.08.2021

Testowanie ETL

Testowanie procesu wydobycia-przekształcenia-ładowania jest jednym z najważniejszych działań QA projektu BI, ponieważ błędy mogą być ukryte jak igły w stogu siana. W procesie transformacji może wystąpić błąd, który objawia się tylko raz na tysiąc przetworzonych rekordów. Testowanie procesu ETL polega na dekonstrukcji każdego etapu przepływu przez system. Gdy dane przechodzą z jednego stanu do drugiego, testerzy są po to, aby upewnić się, że każdy etap walidacji i manipulacja działa poprawnie. Gdy masz pewność, że każdy krok działa sam, nadszedł czas na testy integracji z procesem ETL; upewniając się, że każdy krok płynnie prowadzi do następnego. Nie jest konieczne zatrudnianie użytkowników końcowych do testowania całego procesu ETL, ale trzeba znaleźć ekspertów w odpowiedniej tematyce biznesowej, aby zweryfikować procesy czyszczenia i transformacji danych. Użytkownicy biznesowi i interesariusze będą brali udział w określaniu wymagań podczas projektowania procesu ETL i muszą również odegrać tutaj rolę: zapewnienie, że dane wychodzące z łańcucha ETL są poprawne.
Powrót

13.08.2021

Testowanie front-end

Po tym, jak proces ETL przejdzie przez pełny cykl kontroli jakości, musisz skupić się na frontendzie. Upewnij się, że zapytania wypełniają raporty zgodnie z oczekiwaniami, a narzędzia analityczne otrzymują odpowiednie dane. Aby przetestować swoje raporty i narzędzia front-endowe, zacznij od prezentacji samego raportu. Czy wydaje się prawidłowe? Czy obliczenia dają dokładne wyniki? Następnie testerzy QA zwracają uwagę na sparametryzowane dane w raportach. Prawdopodobnie będą rzucać różne permutacje i kombinacje parametrów - legalnych i nielegalnych - w narzędziu raportowania, aby upewnić się, że odpowiada ono prawidłowo.
Powrót

14.08.2021

Teraz w limitowanej wersji

Pełne wydanie bez żadnych kroków pośrednich wiąże się ze znacznym ryzykiem. Po pierwsze, jesteś zaangażowany w określony kierunek, nie wiedząc, czy technologia, którą chcesz wykorzystać, jest w ogóle wykonalna, lub czy obszar możliwości ma sens dla zastosowania koncepcji BI.
Powrót

15.08.2021

Projekty pilotażowe

W przypadku aplikacji Business Intelligence projekt pilotażowy to coś więcej niż próba; jest to w zasadzie demonstracja na małą skalę zaprojektowana, aby pokazać, że BI może dodać wartość w określonej dziedzinie działalności. Pilotaż skupia się na jednym funkcjonalnym silosie, takim jak zarządzanie łańcuchem dostaw lub zasobami ludzkimi, i buduje system o ograniczonych możliwościach, który obejmuje tylko podstawowe funkcje wszystkich głównych komponentów BI. Niektóre cechy projektu pilotażowego:

•  Czas uruchomienia mierzony jest w miesiącach.
•  Oprogramowanie nie jest licencjonowane do stałego użytkowania.
•  Budżet jest znacznie niższy niż w przypadku pełnej iteracji projektu.
•  Funkcjonalność BI jest ograniczona.

Z pewnością projekty pilotażowe mają ograniczenia. Ale poddali testowi główne koncepcje inicjatywy BI, tylko z ograniczoną złożonością i skalą. Projekt pilotażowy obejmowałby identyfikację danych źródłowych, konstruowanie procesu ETL (w tym rozwijanie możliwości standaryzacji i czyszczenia danych) oraz opracowanie docelowego środowiska bazy danych. Połączysz narzędzia front-endowe z docelowym środowiskiem danych, ale zaawansowana funkcjonalność zostanie ograniczona do minimum. Celem tutaj nie jest natychmiastowe uzyskanie szczegółowych informacji o dużym wpływie, ale raczej pokazanie, że wszystkie ruchome części mogą ze sobą współpracować. Wnioski wyciągnięte z udanego programu pilotażowego (i, potencjalnie, wewnętrznych sojuszników) można przełożyć na pełny cykl projektu z trwałym uwolnieniem.
Powrót

16.08.2021

Dowód koncepcji

Proof of concept różni się od projektu pilotażowego pod względem celu: zastosowania konkretnego rozwiązania problemu biznesowego, aby zobaczyć, jak dobrze proponowany system może wytrzymać towarzyszące mu wymagania. Częstym zastosowaniem projektu proof-of-concept jest zbudowanie prototypu przy użyciu nieprzetestowanego komponentu BI (takiego jak front-endowe narzędzie do analizy i raportowania lub silnik OLAP). Wyniki testu (który może trwać zaledwie kilka tygodni) określają, w jakim kierunku pójdzie zespół projektowy w sprawie konkretnej technologii.
Powrót

17.08.2021

Dzień po: konserwacja i ulepszanie

Dane z badań wskazują, że większość projektów z zakresu Business Intelligence nie spełnia ich oczekiwań. Oznacza to, że nie osiągają swoich celów w zakresie zwrotu z inwestycji (ROI) - a użytkownicy też nie uważają, że są dużo warci. Unikanie tego losu jest łatwiejsze do powiedzenia niż do zrobienia. Mamy nadzieję, że przeszedłeś przez proces starannego planowania i zachowałeś cele biznesowe na pierwszym miejscu podczas tworzenia platformy BI. A jeśli wszystko poszło dobrze, wysłuchałeś społeczności użytkowników, zebrałeś dobre wymagania i zaprojektowałeś system dźwiękowy. Po udanym uruchomieniu przez zespół pierwszej iteracji platformy rozpoczyna się prawdziwa praca. Zanim jednak zaczniesz kłaść się na laurach, aby odpocząć, nadszedł czas, aby zacząć myśleć o tym, jak utrzymać płynne działanie tego środowiska - i jak możesz je jeszcze ulepszyć. To powszechne nieporozumienie, które mówi, że firmy muszą tylko zainstalować oprogramowanie BI, a następnie "kończą" pracę; mogą to zaznaczyć na liście i przejść do kolejnego projektu informatycznego. Rzeczywistość jest taka, że BI to nie projekt - to proces, który jest napędzany przez biznes i wspierany przez specjalistów technologicznych. BI to sposób myślenia i wykorzystywania informacji w codziennych i rocznych procesach, które kierują organizacjami.
Powrót

18.08.2021

BI = Stała poprawa

Proces BI przejawia się w dwóch głównych formach: projektów wdrożeniowych oprogramowania i towarzyszących im zmian w procesach biznesowych, które współgrają z oprogramowaniem. Pokazuje to rozszerzony przykład: wyobraź sobie, że firma instaluje kompleksowe rozwiązanie BI, łączące szczegółowe informacje finansowe z aktywnością sprzedażową. System zapewnia niespotykany dotąd poziom wglądu w proces sprzedaży. Dzięki nowemu systemowi kierownicy sprzedaży mogą dołączać precyzyjne dane marżowe do poszczególnych transakcji sprzedaży i przedstawicieli handlowych. Nagle zespół zarządzający sprzedażą może pociągać do odpowiedzialności zarówno terenowe, jak i wewnętrzne zespoły sprzedażowe za zawierane transakcje - i żądać, aby każda transakcja spełniała określone wymagania dotyczące marży. Aby upewnić się, że zespoły sprzedaży mogą osiągnąć nowe progi marż, firma może wprowadzić zmianę w procesie sprzedaży; dodanie procesu zatwierdzania opartego na systemie BI podczas tworzenia ofert dla transakcji. Bez nowego systemu nie byłoby dostępnego mechanizmu dodawania tego kroku, pozostawiając zespoły sprzedażowe w niewiedzy o marżach. Ale w tym przypadku BI steruje procesem biznesowym - umożliwiając zespołowi sprzedaży poprawę sposobu obsługi podstawowych funkcji. BI tworzy kaskadowy ewolucyjny proces w organizacjach, w którym technologia nie tylko wymaga zmian w procesach, ale pozwala na nowe sposoby myślenia i zachęca do lepszych, bardziej innowacyjnych metod rozwiązywania problemów. Dlatego praktycy BI muszą być przygotowani na myślenie o ulepszeniach systemu. System Business Intelligence powinien być zbudowany tak, aby rozwiązywać problemy i oferować wgląd, ale powinien również wiązać się z pewnym planowaniem na przyszłość.
Powrót

19.08.2021

Oceny powdrożeniowe

Pierwsze rzeczy po uruchomieniu: musisz zrozumieć, jak to zrobiłeś. Często pomijana - ale niezwykle ważna - część każdego projektu analizy biznesowej pojawia się po tym, jak aplikacje zostały wprowadzone do produkcji i nadszedł czas, aby zatrzymać się i spojrzeć wstecz na to, jak dobrze projekt został wykonany. Jednocześnie powinieneś zbadać krajobraz, aby zobaczyć, jaki wpływ na biznes mają nowe narzędzia. Upewnij się, że Twoja ocena nie jest postrzegana jako kolejny okres testowy, w którym użytkownicy oczekują, że ich opinie zostaną zarejestrowane i zastosowane - od tego momentu będą musieli trochę się dostosować. Użytkownicy nie zawsze wiedzą, czego chcą, aż do drugiego dnia (czyli następnego dnia po dostarczeniu nowej aplikacji do raportowania i analiz). są. Po to jest faza 2.
Powrót

20.08.2021

Ogólny przegląd projektu

Po przejściu do środowiska produkcyjnego i pełnym wykorzystaniu go przez użytkowników końcowych (zgodnie z projektem), nadszedł czas na przegląd powdrożeniowy. Nazwij to sekcją, badaniem stanu zdrowia lub cokolwiek chcesz, ale cel jest zawsze ten sam:

Przypomnienie: przejrzyj najważniejsze elementy całej narracji rozwoju, od etapu pomysłu do uruchomienia.
•  Analiza jakościowa: określ, które cele biznesowe zostały osiągnięte lub przekroczone, a także których, jeśli w ogóle, nie udało się osiągnąć.
•  Analiza ilościowa: Oceń projekt pod kątem standardowych wskaźników wydajności: Czy spełniliśmy wymagania dotyczące budżetu i harmonogramu?
•  Wyciągnięte wnioski: Powinny one obejmować zarówno dobre, jak i złe. Co poszło dobrze? Jakie obszary procesu rozwoju wymagały wygładzenia?
Powrót

21.08.2021

Przegląd technologii

Ogólny przegląd projektu wyraźnie pokazuje, które elementy środowiska BI działają zgodnie z oczekiwaniami - i te, które nie działają. Podczas przeglądu technologii Twój zespół powinien przyjrzeć się bliżej przyczynom niektórych sukcesów i porażek. Badanie nie powinno kończyć się na poziomie aplikacji; powinien być tak szczegółowy, jak to konieczne: Dlaczego niektóre funkcje aplikacji nie działają zgodnie z oczekiwaniami? W większości przypadków problem można skorelować z głównymi etapami procesu wdrożenia:

•  Czy oprogramowanie zostało poprawnie zainstalowane i skonfigurowane?
•  Jeśli działa zgodnie z planem, czy wystąpił błąd w procesie wymagań? Czy wystąpił nieprzewidziany problem, który należało zidentyfikować na etapie projektowania?
•  Jeśli aplikacja została poprawnie określona, może problem jest szerszy: Czy kwestionowana funkcja, element lub raport były zgodne z celami biznesowymi programu BI?

Te pytania są cenne nie tylko przy usuwaniu bieżących niedociągnięć w obecnym systemie BI, ale także przy planowaniu ulepszeń i następnej wersji. Przegląd technologii powinien zawierać odniesienie do wymagań lub konkretnych kwestii dotyczących funkcjonalności, które należy uwzględnić w kolejnej wersji. Dokumentuj to, co znajdziesz; wyciągnięte wnioski dotyczące technologii są warte zachodu tylko wtedy, gdy je pamiętasz. Częstym problemem w projektach BI jest powtarzanie błędów. Źle pomyślany interfejs użytkownika lub źle zaprojektowany raport nie powinny służyć jako model dla kolejnych wydań i ulepszeń
Powrót

22.08.2021

Przegląd wpływu na biznes

Chociaż z pewnością ważne jest, aby zbadać, jak dobrze poszło wdrożenie, jeśli BI ma zostać wplecione w tkankę firmy, będziesz musiał zwrócić uwagę nie tylko na wydajność swojego zespołu projektowego. Będziesz musiał zrozumieć - i, jeśli to możliwe, określić ilościowo - rzeczywistą wartość biznesową nowych narzędzi BI oraz wkład, jaki nowe aplikacje wnoszą w funkcjonowanie przedsiębiorstwa. Oczywiście łatwiej to powiedzieć niż zrobić. Przeprowadzenie znaczącej oceny jest nie tylko czasochłonnym procesem, ale nie może się nawet rozpocząć, dopóki nie zakorzenią się nowe procesy i narzędzia. Zacznij szukać wyników zbyt wcześnie i możesz nie otrzymać reprezentatywnej próbki danych. Aby przeprowadzić przegląd wpływu na biznes, wróć do artefaktów planowania utworzonych na początku projektu (rozdziały 10 i 11 obejmują wczesne etapy projektu). Najprawdopodobniej ty i twój zespół przeprowadziliście szeroko zakrojone badania - stworzyliście mapy drogowe, raporty strategiczne i dokumenty, a także oceny zdolności i analizy luk. Ta dokumentacja składa się na podstawowy przypadek biznesowy - pierwotne uzasadnienie utworzenia (lub późniejszego rozszerzenia) programu BI. W niektórych przypadkach metryki mogły zostać utworzone na wczesnym etapie programu. Nie tylko ogólne cele dotyczące tego, co organizacja miała nadzieję osiągnąć, ale konkretne pomiary wskazujące na usprawnienia organizacji, wraz z precyzyjnymi metodami dokonywania tych odczytów. Dobrym pomysłem jest pozostanie przy oryginalnych metrykach wbudowanych w program - powiedzmy, skróceniu czasu przetwarzania raportów lub poprawie dostępu do informacji. Wypełnianie pustych miejsc w takich pomiarach jest dobrym sposobem na zamknięcie pętli w projekcie BI. Następnie konieczne jest zbadanie wpływu na użytkowników. Będziesz chciał zbierać i analizować informacje od pracowników wiedzy, którzy przychodzą na kontakt z nowymi narzędziami BI. Zazwyczaj ulepszenia będą należeć do jednej z kilku standardowych kategorii, które opisują kolejne podrozdziały.

Skrócenie czasu na zadanie

Pomiar ten może dotyczyć czasu potrzebnego na sporządzenie danego raportu, opracowanie określonej analizy lub wykonanie innej czynności przypisanej pracownikom wiedzy. Zmniejszenie ilości czasu ponoszonego przez firmę można zmierzyć mnożąc ilość zaoszczędzonego czasu przez ustandaryzowaną stawkę godzinową dla zaangażowanego personelu. Innym sposobem podejścia do tego pomiaru jest przypisanie określonej wartości do wykonania danego zadania, a następnie przemnożenie przez tę stawkę dodatkowych zadań, które można wykonać dzięki wdrożeniu BI.

Obniżenie kosztu na zadanie

Narzędzie użytkownika końcowego BI prawdopodobnie zmniejszy liczbę osób zaangażowanych w proces badań i analiz - a to oznacza dla firmy oszczędności kosztów. Te redukcje niekoniecznie oznaczają zwolnienie wszystkich osób, które nie są już potrzebne do wykonania zadania; oznacza to po prostu, że ich czas zostaje zwolniony na różne, potencjalnie bardziej wartościowe zadania.

Doskonalenie kluczowych kompetencji

Podstawowym celem wielu systemów BI jest coś więcej niż tylko usprawnienie procesu raportowania. Chodzi o spostrzeżenia, które pochodzą z tych raportów - pomysły i informacje, które we właściwych rękach faktycznie mają pozytywny wpływ na sposób prowadzenia firmy. Środowisko BI może umożliwić firmie identyfikację wydajności w całej podstawowej działalności biznesowej, niezależnie od tego, czy jest to łańcuch dostaw, proces produkcyjny, działania marketingowe i sprzedażowe, czy jakiekolwiek inne główne zadanie wykonywane przez firmę w celu zarabiania pieniędzy. Na przykład BI może umożliwić lepsze i wydajniejsze wykorzystanie direct mail poprzez identyfikację wzorców zakupów klientów i połączenie tych wzorców z regionami geograficznymi. To połączenie może pozwolić na wykorzystanie tego samego budżetu na pocztę bezpośrednią, aby osiągnąć bardziej otwartych odbiorców i popraw ROI dla każdej kampanii.

Udoskonalanie kierunku biznesowego

W ostatecznym rozrachunku spostrzeżenia uzyskane z integracji środowiska BI i całego sposobu myślenia o analizie biznesowej w proces planowania strategicznego mogą przynieść korzyści w dłuższej perspektywie, prowadząc firmę na nowe, bardziej owocne rynki i działania.
Powrót

23.08.2021

Utrzymanie środowiska BI

Żaden system tak naprawdę nie może działać sam. W zamian za korzyści, jakie niesie ze sobą BI, organizacja musi znosić bieżące utrzymanie - w szczególności te trzy czynności:

•  Ocena stanu Twojego systemu BI (jak dobrze wykonuje zaprojektowane funkcje).
•  Ocena stopnia dopasowania systemu do zmieniających się potrzeb biznesowych.
•  Sprawdzenie, w jakim stopniu system usprawnia komunikację w organizacji.
Powrót

24.08.2021

Stan systemu

Najbardziej podstawowe (choć wcale nie proste) zadania konserwacji BI koncentrują się na utrzymywaniu działania podstawowych systemów dla użytkowników.

Stan danych

Teoretycznie, jeśli przeprowadzisz odpowiednie testy, Twoje dane powinny pozostać w dobrym stanie podczas przenoszenia między systemami źródłowymi, przez proces ETL i do docelowej bazy danych. Zakłócenie w łańcuchu zdarzeń, które dostarczają informacje użytkownikom, może być katastrofalne dla organizacji. Jeśli ludzie używają informacji, które w rzeczywistości nie odzwierciedlają rzeczywistości, raporty będą niedokładne, decyzje będą błędne, a prognozy nie będą miały związku z rzeczywistą przyszłością. To dlaczego ciągłe monitorowanie danych napływających do Twojego środowiska BI ma ogromne znaczenie. Jednym ze sposobów na zapewnienie dobrych danych jest proces odkrywania i profilowania: zespół projektowy uzyskuje dostęp do analiz statystycznych informacji przepływających przez system. Może to być proces ręczny - eksperci ds. danych w zespole mogą tworzyć własne zapytania, aby sprawdzić charakterystykę danych przed i po załadowaniu ich do systemu docelowego. Jeszcze lepiej jest zautomatyzowane narzędzie, które analizuje zakres i dystrybucję wartości pól, relacje między tabelami i inne fakty, które mogą zapewnić pełny profil informacji w Twoim środowisku BI. Nie czekaj, aż usłyszysz skargi od użytkowników, aby sprawdzić, czy Twoje dane są w dobrym stanie. Zewnętrzne objawy tej choroby nie pojawią się, dopóki pacjent nie jest już na podtrzymywaniu życia. Miej oko na niekompletne lub uszkodzone dane w ramach normalnego procesu konserwacji.

Czas odpowiedzi

Monitorowanie ładowania danych i czasów odpowiedzi na zapytania jest niezbędne do utrzymania użytecznego i użytecznego środowiska BI. A sukces ma swoją cenę za system BI: bardziej użyteczne narzędzie oznacza, że więcej użytkowników będzie chciało uzyskać dostęp do danych; w dłuższej perspektywie do systemu BI zostanie włączonych więcej domen biznesowych. Wraz ze wzrostem liczby użytkowników obciążenie systemu będzie naturalnie wzrastać. Równie prawdziwe jest to, że docelowe systemy danych z czasem zapełnią się większą ilością danych, a charakter zapytań i wzorce użycia będą ewoluować (często w kierunku większej złożoności), powoli, ale zdecydowanie obniżając wydajność. Dodaj do tego możliwość, że czasami rzeczy po prostu się psują i masz zadatki na kłopoty właśnie tutaj, w River City. Konieczne jest, aby przez cały czas mieć jedno oko na wydajność systemu BI. Większość aplikacji bazodanowych ma wbudowane narzędzia diagnostyczne do monitorowania wydajności, a dostawcy BI często oferują dodatkowe narzędzia, które zapewniają lepszy wgląd w sposób, w jaki system obsługuje złożone zapytania i obciążenia szczytowe. Zaawansowane narzędzia do monitorowania mogą nawet wykrywać spowolnienia, wykrywając wydłużenie czasu odpowiedzi, a następnie uruchamiając procesy diagnostyczne w celu wyizolowania źródła problemu. W środowisku BI rozpoznanie i naprawienie problemu z wydajnością to zwykle dwa stosunkowo proste zadania, które są połączone z o wiele trudniejszym: identyfikacją pierwotnej przyczyny. Przy tak wielu systemach splecionych w cyfrowe tango, które mogą rozciągać się na całą firmę, wyizolowanie słabego ogniwa w łańcuchu może być prawdziwym wyzwaniem. To właśnie sprawia, że aktywne monitorowanie wydajności jest tak ważne; to daje więcej czasu na zlokalizowanie i rozwiązanie problemu. Czekanie, aż użytkownicy narzekają na czasy odpowiedzi, to recepta na kłopoty. Są szanse, że zanim wiadomość wróci do zespołu projektowego, wielu ludzi zostało dotkniętych obniżoną wydajnością. Mierząc czasy, które upłynął dla zwykłych procesów i żądań, a następnie obserwując linie trendu dla tych czasów odpowiedzi, możesz przewidzieć, kiedy nadejdzie czas na modernizację systemu, aby obsłużyć większą pojemność. Będziesz w stanie wykryć kłopoty, zanim nadejdą. Podczas procesu projektowania zdefiniuj czas odpowiedzi potrzebny dla każdej części danych - pamiętając, że nie wszystkie muszą być odświeżane w czasie rzeczywistym. Na przykład, jeśli monitorujesz wyniki sprzedaży dla rosnącej sieci kawiarni, będziesz chciał odświeżać rzeczywiste dane sprzedaży tak często, jak to możliwe. Ale informacje referencyjne (takie jak lokalizacje sklepów i dane pracowników) nie zmieniają się tak często; wystarczy go odświeżyć raz w tygodniu lub raz w miesiącu. Ponowne ładowanie tych stosunkowo statycznych danych raz na godzinę tylko niepotrzebnie ugrzęzłoby w systemie.

Dostrajanie docelowej bazy danych

Wszystkie bazy danych wymagają regularnego dostrajania w celu utrzymania wydajności, a docelowe systemy danych BI nie różnią się od siebie. Administrator bazy danych będzie musiał przeprowadzać regularne procedury diagnostyczne i dostrajające, aby upewnić się, że system zarządzania bazami danych (DBMS) pozostaje zoptymalizowany pod kątem rodzajów zapytań, które są wymagane, że najlepiej wykorzystuje pamięć i czy baza danych jest zgodna z obsługiwane aplikacje.

Aktualizacja aplikacji

Podobnie jak w przypadku każdej złożonej aplikacji, dostawcy stale publikują poprawki błędów i aktualizacje, aby odpowiedzieć na skargi użytkowników i żądania ulepszeń. Dobry zespół BI będzie miał systematyczny sposób śledzenia tych uaktualnień i skutecznego stosowania ich w środowisku przy minimalnych zakłóceniach
Powrót

25.08.2021

Znaczenie systemu - nadążanie za zmianami biznesowymi

Skuteczny system BI będzie stale pozyskiwał więcej danych. Jest to nieodłączne w środowisku hurtowni danych, w którym przechowywane informacje są oparte na operacjach historycznych. Ale prawdą jest również, że ponieważ przechowywane są bardziej szczegółowe dane biznesowe, a więcej obszarów tematycznych jest śledzonych niż wcześniej; wymagania dotyczące systemu rosną i stają się bardziej złożone. System BI musi być stale ulepszany, aby mieć pewność, że przechwytuje istotne informacje we właściwych ramach czasowych i na odpowiednim poziomie szczegółowości. Na kondycję systemu Business Intelligence może mieć wpływ wiele czynników. Poniższe zadania podkreślają wyzwanie utrzymania systemu BI w dynamicznym środowisku biznesowym:

•  Nowe informacje: niezależnie od tego, czy jest to nowa kategoria danych, nowa jednostka biznesowa, czy nowy system źródłowy, środowisko musi być wystarczająco elastyczne, aby móc przyjmować i przetwarzać nowe dane.
•  Dane źródłowe zmieniają się lub znikają: przeciwieństwo poprzedniego problemu jest również prawdziwe: systemy danych źródłowych nie pozostaną takie same na zawsze. Będą aktualizować, zostaną połączone w skonsolidowane systemy, a czasem całkowicie znikną.
•  Nowe kierownictwo i zmiany sponsorów: Strategiczne znaczenie systemu jest funkcją tego, jak postrzega go kierownictwo. Należy mieć świadomość, że zmiany w biurach narożnych lub zmiany w organizacji firmy mogą wpłynąć na sposób korzystania z systemu, zarówno na poziomie codziennym, jak i jako narzędzie długoterminowej strategii.
Powrót

26.08.2021

Utrzymanie linii komunikacji

Komunikacja jest kluczem do wsparcia środowiska business intelligence. Przeszkolenie użytkowników, poinformowanie ich i kontakt z pomocnymi zasobami to długa droga do utrzymania zdrowego systemu i szczęśliwej społeczności użytkowników. Rysunek 15-1 przedstawia powiązania komunikacyjne, zarówno bezpośrednie, jak i pośrednie, które muszą istnieć między zespołem projektowym a różnymi interesariuszami w firmie. Zadaniem zespołu projektowego jest utrzymanie otwartych kilku różnych kanałów komunikacji po uruchomieniu systemu, z których każdy ma własne, predefiniowane potrzeby:

•  Zapewnienie natychmiastowego wsparcia: jest to pomoc techniczna, która zapewnia podstawową pomoc użytkownikom, którzy mają problemy z obsługą aplikacji lub wykonywaniem podstawowych zadań. Większe firmy często tworzą wspólne centrum pomocy; w mniejszych organizacjach za wsparcie na poziomie 1 odpowiada zespół projektowy.
•  Zapewnienie mechanizmu informacji zwrotnej: nie chodzi tylko o naprawianie błędów i przyciąganie użytkowników do Internetu. Będziesz także chciał zapewnić zainteresowanym stronom i użytkownikom aplikacji możliwość zgłaszania skarg, komentarzy i krytyki. A jeśli myślisz o wyrzuceniu tych kart z komentarzami prosto do kosza, poświęć chwilę i zastanów się, czy użytkownik jest złoty w środowisku BI. Podobnie jak w przypadku BI jako całości, informacje zawarte w komentarzach użytkowników stanowią podstawę do racjonalnych decyzji dotyczących przyszłości systemu. (Kto wie? Ktoś może nawet powiedzieć coś miłego.)
•  Stałe szkolenia dla użytkowników: to nie tylko pomaganie użytkownikom w przejściu przez podstawowe zadania przez telefon za pośrednictwem czatu na żywo; ta ścieżka komunikacji ma na celu podniesienie umiejętności użytkownika. Jednym z największych problemów w systemach BI jest to, że aplikacje są często złożone, a zespół projektowy zakłada, że użytkownicy mogą od razu zrozumieć, jak z nich korzystać. Ustanowienie programu szkoleniowego to świetny sposób na zapewnienie, że użytkownicy otrzymają od systemu to, czego potrzebują.
•  Udział w komitetach ds. standardów i zarządzania: Zespół projektowy BI powinien pozostawać bezpośrednio zaangażowany we wszelkie komitety nadzorcze obejmujące całą korporację. Gdy zarządcy danych działają, zespół BI musi o tym wiedzieć od razu, aby zastosować odpowiednie aktualizacje systemu. Nie tylko to, ale także dzięki obecności w komitetach zarządzających, zespół projektu BI ma możliwość popularyzowania właściwej roli wywiadu biznesowego w firmie takiej jak Twoja.
•  Regularny kontakt ze sponsorami wykonawczymi: Ci ludzie wyszli za ciebie, więc możesz przynajmniej na bieżąco informować ludzi o statusie systemu. Dziel się dobrymi i złymi wiadomościami i wszystkim pomiędzy. I tak to wszystko usłyszą.
Powrót

27.08.2021

Rozszerzanie swoich możliwości

W dzisiejszych czasach analizy biznesowe dotykają coraz większej liczby obszarów przedsiębiorstwa, więc wszędzie istnieją możliwości ekspansji. Utrzymanie systemu jest ważne, ale chwała polega na jego rozszerzaniu - udostępnianiu społeczności użytkowników nowych funkcji i aplikacji, aby system działał lepiej niż wcześniej. Jak zawsze użytkownicy biznesowi i interesariusze powinni kierować projektem BI. Zespół projektowy musi zawsze mieć na uwadze podstawowe cele biznesowe, aby były one zgodne z działaniami technologicznymi. Postępuj zgodnie z tymi samymi podstawowymi procedurami, co przy oryginalnej instalacji - z wyjątkiem miniatury i z nieco innej perspektywy. Mając na uwadze konkretną potrzebę biznesową, wybierz najlepszą ścieżkę technologiczną, która będzie ją wspierać.
Powrót

28.08.2021

Rozszerzanie istniejących aplikacji

Pierwsze - i najłatwiejsze - ulepszenia to takie, w których bierzesz to, co już masz, i nieznacznie je ulepszasz. Często zdarza się, że dostawcy BI dostarczają narzędzia BI z włączonym ograniczonym zestawem funkcji (często w ramach określonego schematu licencjonowania). A ponieważ te funkcje są już dostępne w Twoim systemie, ich włączenie w minimalnym stopniu zakłóca środowisko. Zacznij prosto. Podczas kilku pierwszych faz ulepszania i rozbudowy nie odgryzaj więcej, niż możesz przeżuć, dopóki nie poczujesz strategicznych i operacyjnych wyzwań związanych z aktualizacją systemu.

Zbieranie resztek

W tym miejscu ponownie przyjrzysz się ćwiczeniu ustalania priorytetów używanemu podczas etapu pozyskiwania wymagań w projekcie. To ćwiczenie odzwierciedla rzeczywistość, w której rzadko masz czas na zrobienie wszystkiego, co planujesz zrobić podczas wstępnego wdrożenia systemu BI. Tak więc elementy o wysokim priorytecie zostały zainstalowane, a elementy o niższym priorytecie musiały poczekać. Pierwsze ulepszenie systemu to doskonała okazja do ponownego zapoznania się z początkowymi szkicami planu projektu i dokumentacji wymagań. Sprawdź, czy masz jakieś resztki starych priorytetów, z którymi możesz sobie od razu poradzić. Wymagania, których nie spełniłeś w swojej ostatniej implementacji BI, często są najprostsze do spełnienia. Piękno pierwszych odrzuconych wdrożeń polega na tym, że ich specyfikacje są zwykle już zdefiniowane i sprawdzone pod kątem ważności biznesowej. Już omówiłeś je z użytkownikami i ustaliłeś, że są ważne w sensie absolutnym. Po prostu nie dokonali cięcia.

Posuwanie się w górę łańcucha złożoności

Czasami sensowne jest uaktualnienie użytkowników z prostszego oprogramowania do bardziej złożonych aplikacji. Jeśli użytkownicy opanowali podstawowe funkcje interfejsu, mogą stać się bardziej wydajni, jeśli udostępnisz im zaawansowaną funkcjonalność lub zainstalujesz nowe aplikacje, które w naturalny sposób bazują na istniejących funkcjach. Typowy system BI ewoluuje w pewien przewidywalny sposób ze względu na sposób, w jaki funkcje jednej aplikacji są podobne do funkcji innej aplikacji lub są budowane w kierunku funkcji innej aplikacji. Rysunek 15-2 przedstawia wstępną instalację BI po lewej stronie, połączoną z kilkoma potencjalnymi ścieżkami ewolucyjnymi po prawej stronie. Na przykład eksperci w zarządzanych narzędziach raportowania mogą chcieć rozszerzyć swoje możliwości i przejść do tworzenia raportów i tworzenia własnych zapytań ad hoc. Inni z tej grupy użytkowników mogą poprosić o oprogramowanie do wizualizacji, aby przekształcić swoje raporty w arcydzieła z grafiką. Wraz ze wzrostem możliwości i zasięgu systemu, prawdopodobnie będziesz podążać za tymi typowymi wzorcami wzrostu

•  Zadbaj o zaawansowanych użytkowników: stwórz dla zaawansowanych użytkowników możliwości wykonywania jeszcze bardziej szczegółowych i dogłębnych analiz niż wcześniej.
•  Przenieś BI w kierunku wspomagania decyzji w czasie rzeczywistym: Twoje początkowe wdrożenie BI miało na celu pomoc w przeprowadzeniu analizy problemów biznesowych w zwolnionym tempie. Przy pierwszym projekcie ulepszeń rozważ aplikacje, które mogą wspierać użytkowników w podejmowaniu codziennych decyzji na podstawie przeprowadzanych przez nich analiz.
•  Przenieś BI do sfery strategicznej: Aplikacje obsługujące szerokie planowanie strategiczne znajdują się na końcu długiego kontinuum oprogramowania BI. Twoje ulepszenia powinny iść w tym ogólnym kierunku - aby BI stało się częścią funkcji prognozowania i planowania.
•  Rozwiń ze środowisk ad hoc do środowisk zarządzanych i z powrotem: oba te typy środowisk raportowania mogą być niezwykle cenne, jeśli zostaną wdrożone u odpowiednich osób po odpowiednim przeszkoleniu. Przejdź do środowiska zarządzanego, jeśli masz więcej użytkowników o ograniczonych możliwościach i istnieje potrzeba tworzenia niestandardowych raportów. Wprowadź środowisko ad hoc, jeśli ludzie proszą o większą elastyczność w uruchamianiu zapytań.

Nie rób tego tylko dlatego, że możesz. Może być technicznie możliwe dostarczenie danych z kasy fiskalnej w czasie rzeczywistym do aplikacji do analizy sprzedaży, ale daj spokój, czy naprawdę potrzebujesz tego rodzaju przeciążenia informacjami? Jeśli cała analiza jest wykonywana na podstawie raportów z tygodnia na dzień, nie musisz inwestować czasu i kłopotów w tworzenie strumienia danych w czasie rzeczywistym. To częsta pułapka w BI; jest tak wiele małych sposobów na poprawę na marginesach, że lepiej wybrać i wybrać, gdzie poświęcić wysiłek - ostrożnie - albo skończysz z funkcjami, których tak naprawdę nie potrzebujesz.

Bardziej zaawansowana praca w ramach istniejących wersji

Ten rodzaj rozbudowy BI nie wymaga żadnych nowych licencji. Ulepszenia nie muszą obejmować aplikacji i niekoniecznie oznaczają zwiększenie pojemności obliczeniowej lub pamięci masowej. Czasami chodzi o wstrzymanie, aby ulepszyć raport lub poprawić użyteczność składnika. Użyteczność jest ważnym aspektem Twojego środowiska BI - podobnie jak wygląd i styl codziennych narzędzi. Weź te czynniki pod uwagę, gdy rozważasz ulepszenia systemu. Aplikacje, które są trudne w użyciu lub nieprzyjemne w obsłudze, w końcu przestaną być używane. A wizualne, estetyczne walory oprogramowania są często pierwszymi rzeczami, które zauważa użytkownik - i na które narzeka.

Dodawanie nowych użytkowników do środowiska BI

Czasami ulepszenie polega w mniejszym stopniu na dodaniu nowej funkcjonalności, a bardziej na dodaniu nowej grupy użytkowników. Dostosuj system do obsługi większej liczby użytkowników, zwiększając pojemność. Celem jest umożliwienie nowym użytkownikom dostępu do danych bez narażania się na zauważalne opóźnienia w wydajności aplikacji, opóźnieniach zapytań i tym podobnych. Jeśli nowa grupa użytkowników ma inny poziom umiejętności (lub pochodzi z innej części firmy), może być konieczne wdrożenie innej aplikacji dla nowej, szerszej grupy docelowej. Na przykład przyznanie zespołowi zarządzającemu sprzedażą dostępu do systemu BI może oznaczać zapewnienie ściśle kontrolowanego, zarządzanego środowiska raportowania w miejsce środowiska ad hoc, które kiedyś działało dobrze dla mniejszej, bardziej wykwalifikowanych grup użytkowników.
Powrót

29.08.2021

Instalowanie zaawansowanych aktualizacji

W niektórych przypadkach naprawdę nie możesz już więcej zrobić z tym, co masz. Nie możesz rozszerzać ani ulepszać istniejących narzędzi BI. Wszystkie nisko wiszące owoce zostały zjedzone. Teraz nadszedł czas na rozgałęzienie i rozszerzenie na narzędzia, których jeszcze nie ma. Czy nowe akcesorium może w jakikolwiek sposób zagrozić istniejącemu systemowi? Czy to utrudni korzystanie? Czy będzie wolniej? Upewnij się, że niczego nie zepsujesz. Aby chronić swój system przed potencjalnymi błędami, jakie może przynieść uaktualnienie, każdy dobry specjalista ds. kontroli jakości powie Ci, abyś w miarę dodawania nowych ulepszeń angażował się w pełne testy regresji systemu. Oto krótka lista kluczowych pytań, które należy zadać w przypadku aktualizacji systemu:

•  Kto wdroży ulepszenia? Czy to ten sam zespół, który wykonał pierwszy projekt, czy zupełnie nowy zespół?
•  Czy masz wsparcie wykonawcze dla uaktualnienia?
•  Czy w pełni określiłeś wymagania dla nowego systemu - według tej samej metodologii co poprzednio?
•  Którzy obecni użytkownicy BI będą korzystać z tej aplikacji? Jakie szkolenie będzie potrzebne?
•  Czy nowa funkcjonalność odwraca uwagę lub zakłóca istniejącą funkcjonalność?

W szczególności projekty Business Intelligence budzą szczególne obawy, które zespół projektowy powinien wziąć pod uwagę. Ponieważ BI to transformacyjne podejście do biznesu i technologii, zawsze istnieje obawa, że procesy biznesowe nie miały szansy dogonić technologii. Innymi słowy, narzędzia technologiczne rzeczywiście dostarczają użytkownikom spostrzeżenia - ale nie są odpowiednio wykorzystywane. Układanie błyszczących nowych aplikacji na istniejących aplikacjach może prowadzić do problemów. Jeśli użytkownicy nie wykorzystują w pełni prostszej instalacji BI, co sprawia, że myślisz, że w pełni wykorzystają nowe oprogramowanie? Mogą, ale nie ma gwarancji. Ponadto, ponieważ istnieje tak wiele elementów puzzli, które muszą do siebie pasować, kompatybilność jest zawsze problemem. Większość dostawców oferuje obecnie podejście oparte na standardach. Ale czasami dwa programy po prostu nie działają (lub przynajmniej nie działają dobrze) razem. Przy każdym ulepszeniu lub rozszerzeniu bardzo ważne jest, aby oczekiwania były zgodne. Czy coś naprawiamy? Jeśli tak, co się zepsuło i skąd mamy pewność? Czy to nowe narzędzie z nową funkcjonalnością? Jeśli tak, jaki jest jego cel i gdzie jest udokumentowany?
Powrót

30.08.2021

Podejście olimpijskie

Co 18 do 24 miesięcy przejrzyj cały system Business Intelligence, od zupy po orzechy, od góry do dołu. Odłóż święte krowy na bok. Przeanalizuj każdy element swojego otoczenia, tak jakbyś kupował używany samochód. Najbardziej piszczące koło jako pierwsze dostaje smar. Dlatego konieczna jest pełna recenzja. Daje szansę krytycznego spojrzenia na elementy otoczenia, które może nie powodują ostrych bólów głowy, ale działają jak cichy hamulec dla systemu. W swojej ocenie zastanów się, co działa dobrze dla użytkowników wszystkich pasów - od skimerów kierowniczych przez zaawansowanych użytkowników po konsumentów informacji, którzy utknęli w korporacyjnych lochach. Wykonaj ten sam rodzaj analizy, który omawialiśmy przy opracowywaniu początkowego podejścia do BI. Pomyśl o tych pięciu poziomach pytań:

1. Czy ludzie używają narzędzi, których powinni używać?
2. Czy prawidłowo używają narzędzi?
3. Czy narzędzia działają zgodnie z oczekiwaniami?
4. Czy użytkownicy dostrzegają, że narzędzia dodają wartości do ich procesu?
5. Czy użytkownicy mają jakieś potrzeby, które nie są zaspokajane?

Odpowiedzi, które otrzymasz, mogą, ale nie muszą, kierować Cię w kierunku remontu. Możliwe, że po prostu potrzebujesz rundy przekwalifikowania lub przeorientujesz kulturę firmy na proces BI. Ale nie ignoruj uzasadnionych skarg ze strony społeczności użytkowników i nie interpretuj ich komentarzy jako niszczenia początkowego projektu. Pamiętaj, zmiana jest nieunikniona. To znak zdrowego, dynamicznego systemu. Nie zatrzymuj się na użytkownikach. Poproś administratorów i personel wsparcia BI o udział w subiektywnej ocenie środowiska. Nie jest niczym niezwykłym posiadanie systemu, który brzęczy dla społeczności użytkowników, ale jest głównym drenażem zasobów za kulisami. Aktualizacja lub remont może nie mieć większego znaczenia dla użytkowników, ale może być darem niebios dla zespołu BI.
Powrót

31.08.2021

Myślenie długoterminowe z mapą drogową

Podejście olimpijskie, czyli planowanie dużych modernizacji co kilka lat, oznacza rozwijanie dobrego wyczucia, dokąd zmierza środowisko BI. Wizja produktu i kalendarz powinny być skodyfikowane, udokumentowane i aktualizowane. Wizja produktu powinna zawierać przybliżone daty wydania oraz grupy funkcjonalności lub typy aplikacji. Na przykład Twoim celem może być dostarczenie zespołowi sprzedaży narzędzia do dataminingu i prognozowania za rok. Cel ten powinien zostać odnotowany wraz z konkretną potrzebą, jaką ma zaspokoić. Zespół projektowy może następnie wykorzystać wizję produktu do kierowania procesem planowania. Nie wiesz, od czego zacząć swoją wizję produktu? W przypadku projektów BI najlepszą praktyką jest dostarczanie podstawowych funkcji w pierwszej wersji, a następnie w drugiej wersji łączenie luźnych końców pierwszej wersji. Dopiero później, gdy docelowy system danych jest stabilny, a załamania dawno zniknęły, można wrócić i dodać nowe grupy użytkowników oraz ekscytujące ulepszenia i nowe narzędzia. Pamiętaj, rzeczy się zmieniają. Wykonaj podstawowe planowanie awaryjne, nawet w przypadku mało prawdopodobnych przyszłych zdarzeń, pod warunkiem, że mogą one mieć duży wpływ na środowisko BI. Załóżmy na przykład, że mówi się o reorganizacji firmy z modelu usług wspólnych na model oddziałowy - jak to wpłynie na twoje plany? W razie potrzeby przygotuj dwie różne gałęzie długoterminowej mapy drogowej. Jaka jest różnica między ulepszeniem a planowanym wydaniem? Tak naprawdę nic poza nazwą - za każdym razem, gdy zmieniasz konfigurację swojego środowiska BI, jest to ulepszenie. Pamiętaj tylko, że ulepszenia to nie to samo, co konserwacja. Nie musisz robić ulepszeń, aby Twój system brzęczał. Jednak czynności konserwacyjne, sprzęt, oprogramowanie, sieć, pamięć masowa, a nawet aktualizacje procesów zapewnią sprawność systemu niezależnie od harmonogramu ulepszeń.
Powrót