CodziennikiMagazyn ZSF24



Business Intelligence



01.10.2021

Dostawcy BI Pure-Play

W królestwie business intelligence firmy specjalistyczne, które budowały tylko produkty BI, były przez długi czas suwerenne. Chociaż ich rządy ustępują głównym potęgom, prawdą jest również, że dostawcy czystej gry nadal mają do odegrania ważną rolę w ewolucji BI. Nadal są na krawędzi innowacji, są bardziej zwinni i mniej boją się ryzyka. Jeśli chodzi o ochronę inwestycji, pójście z czystym sprzedawcą może zapewnić pewien komfort, pod warunkiem, że firma jest w dobrej kondycji finansowej. Jeśli tak nie jest, ryzykujesz, że Twój dostawca zbankrutuje. Z drugiej strony, jeśli firma jest marginalnie zdrowa, a produkt dobrze pasuje do Twoich potrzeb, prawdopodobnie jesteś bezpieczny. Jeśli firma zostanie przejęta przez konkurenta lub dostawcę platformy, prawdopodobnie Twoja ulubiona aplikacja przetrwa w jakiejś formie.
Powrót

02.10.2021

Niezbędne cechy

Celem integracji dostawcy czystej gry jest sprawienie, aby zachowywał się tak, jakby był idealnie uformowaną częścią twojego systemu; tak potężny, jak to konieczne, aby obsłużyć dowolną ilość danych, ale dający bogactwo funkcji, które często nie są dostępne w większych pakietach oprogramowania. Oto lista kontrolna na początek:

•  Kompatybilność z głównymi bazami danych: To przede wszystkim: aby twoja baza danych była prawdziwa. A jeśli o to chodzi, aplikacja pure-play powinna być w stanie komunikować się z usługami OLAP, głównymi aplikacjami i usługami sieciowymi.
•  Elastyczność platformy: czy działa w środowisku Windows, Linux lub Unix?
•  Opcje wyjściowe: czy ich produkty korzystają z popularnych przeglądarek? A może najlepiej sprawdzają się jako aplikacje komputerowe, oferując bogate w dane, interaktywne środowisko?
•  Skalowalność aplikacji: aby grać na rynku średniej wielkości i przedsiębiorstw, gracze niszowi muszą być w stanie obsłużyć ryzy danych i robić to szybko i z gracją.
•  Wsparcie: Dostawca powinien być przygotowany do wsparcia aplikacji godzinami szkoleń, godzinami konsultacji, zajęciami, certyfikatami i/lub literaturą, jeśli to konieczne. Jeśli nie, lepiej, żeby instalacja i konserwacja były bardzo łatwe.

Więc przed zakupem zadaj sobie te pytania:

•  Zacznij od produktu przede wszystkim - czy jest lepszy od konkurencji?

Nie ograniczaj się do dużych chłopców.

•  Co branża o tym szepcze w magazynach branżowych i na konferencjach?
•  Czy produkt jest istotną częścią ich stosu technologicznego? A może jest gdzieś po drodze duplikowany, przez co jest potencjalnie niepotrzebny?
•  Czy zespół sprzedaży sprzedawcy długo rozmawia o produkcie? Czy są kompetentni i chętni do odpowiedzi na Twoje pytania? A może skłaniają cię do innego tematu?
•  Czy sprzedawca ma dobrą kondycję finansową?
•  Czy czujesz się komfortowo z planem BI dostawcy w ciągu najbliższych 18 miesięcy do dwóch lat?

To ważna decyzja. Uzyskaj pomoc w razie potrzeby, zarówno w zespole, jak i poza nim. Zła decyzja może teraz płynąć kaskadą latami… jak wodospad wstydu.
Powrót

03.10.2021

Sprzedawcy według silnego garnituru

Następujący dostawcy rozwiązań BI typu pure-play są opisani zgodnie z najsilniejszą grą każdego z nich w trzech głównych obszarach tematycznych przechodzących od tyłu do przodu: baza danych, ETL i wszystkie odtwarzacze front-end połączone razem.

Inne odtwarzacze baz danych i hurtowni danych

Niektórzy z mniejszych dostawców wymyślili imponujące produkty bazodanowe i hurtownie danych. Oto przedsmak tego, co oferują.

Teradane NCR

NCR Teradat - Teradata faktycznie ma dość obszerny stos BI i można go zmieścić w dowolnym miejscu, ale znajduje się na liście graczy bazodanowych ze względu na swoją reputację podmiotu zajmującego się obsługą gigantycznych ilości - terabajtów, petabajtów i femtobajtów (nie… to nieprawda). t brzmi dobrze) - danych. Jest to oferowane za pośrednictwem produktu Enterprise Data Warehouse i jest używane głównie przez firmy, które codziennie mają ogromny przepływ danych transakcyjnych przez swoje sieci - takie jak duże banki, firmy telekomunikacyjne czy firmy świadczące usługi turystyczne. Przewaga konkurencyjna Teradata polega na tym, że może oferować magazynowanie, zapytania, raportowanie, analizy i eksplorację danych in-situ, a także analizy predykcyjne na dużą skalę. Teradata współpracuje z wszelkiego rodzaju dostawcami DBMS i BI.

Netezza

Dostawcy oprogramowania bazodanowego podejmują kolejną próbę przeforsowania koncepcji "urządzenia" - zasadniczo oprogramowanie bazodanowe jest wstępnie skonfigurowane na uproszczonym systemie operacyjnym i innym oprogramowaniu pomocniczym, a całość jest ładowana na specjalnie zbudowany serwer. Pomysł polega na tym, że możesz podłączyć swoje urządzenie analityczne lub urządzenie raportujące do swojej sieci przy minimalnym wysiłku. Oracle wypróbowało to w 2000 roku z urządzeniem bazodanowym 9i, ale produkt nigdy nie sprzedawał się dobrze. Wciąż pomysł żyje; jedną z nowych nazw, które pojawią się na tym rynku, jest Netezza. Firma ta oferuje wysokiej klasy urządzenia danych: dedykowane serwery hurtowni danych, które wykorzystują gotowe komponenty sprzętowe i programowe dostrojone i przeskalowane do instalacji w systemie korporacyjnym. Nawet IBM pracuje teraz w urządzeniu hurtowni danych BI pod pseudonimem Balanced Configuration Unit - niemała walidacja tego modelu biznesowego. IBM konkuruje również bezpośrednio z Teradata w rozwiązaniach dostosowanych do transakcyjnych hurtowni danych o dużej objętości - rynku, który rósł w tempie zdrowego klipu w zeszłym roku, pomimo pewnego sceptycyzmu, że nie ma w nim zbyt wiele miejsca dla większej liczby graczy.

MySQL

Jasne, jest to produkt, a nie sprzedawca, ale nie ma nic złego w wyborze produktu, który lubisz, zamiast zaczynać od zera ze sprzedawcą. Bezpłatna lub nie, MySQL jest potężną i solidną platformą bazodanową, a ponieważ spełnia większość standardów danych, jest graczem na rynku BI.
Powrót

04.10.2021

Rosnący ruch open-source BI

Podobnie jak w przypadku systemów operacyjnych (takich jak Linux i Unix) oraz infrastruktury oprogramowania (baza danych MySQL), zjawisko open-source zagościło również w świecie BI. Pentaho (powinno być wymawiane tak, jakbyś umieścił pinezkę na mapie północno-zachodniej Nevady: "Pin Tahoe") łączy kilka różnych projektów BI o otwartym kodzie źródłowym - w szczególności narzędzie ETL i narzędzie do raportowania. Jaspersoft to kolejny odtwarzacz BI typu open source, specjalizujący się w raportowaniu. I nie są jedynymi. Modele, z których korzystają te dwie firmy, podążają śladami Red Hat Linux, zanim stał się potęgą na rynku systemów operacyjnych. Wartością firmy w tym równaniu jest pakowanie oprogramowania z innymi kluczowymi komponentami i wszelkiego rodzaju wsparcie - od pomocy w instalacji, przez rozwiązywanie problemów, po szkolenia. Podejście polega na dostarczeniu wydajnego produktu przy niskim koszcie posiadania, co jest możliwe ze względu na znikomy koszt opracowania oprogramowania. To, za co płacą kupujący - i za co sprzedawcy chcą sprzedawać więcej - są tak zwane usługi "wartości dodanej" (takie jak godziny szkoleń i konsultacji).

Produkty ETL

Narzędzia Extract, Transform i Load (ETL) są sercem każdego systemu BI. Są coraz bardziej zaangażowani w inne zadania związane z transformacją danych, niezależnie od tego, gdzie istnieje i jest wykonywany rzeczywisty kod. Pomyśl o module ETL jako o systemie pobierania i zarządzania danymi. Jego zadaniem jest komunikowanie się z każdym źródłem danych operacyjnych, wyodrębnianie odpowiednich informacji, przekształcanie wszystkich danych do odpowiedniego formatu, a następnie ładowanie ich do systemu docelowego. Na przykład możesz budować hurtownię danych zawierającą pole, w którym chcesz, aby wszystkie wpisy były pisane wielkimi literami bez spacji. Twoi programiści ETL stworzyliby skrypty, które będą komunikować się z różnymi źródłowymi bazami danych w sposób, który rozumieją. Następnie skrypty uruchomią proces transformacji, który usunie wszystkie spacje i zamieni wszystkie litery na wielkie. Proces ten zapewniłby pewien poziom jednolitości danych przed załadowaniem ich do centralnego repozytorium danych, takiego jak hurtownia danych. Oczywiście w prawdziwym świecie ekstrakcje i przekształcenia mogą być dość złożone i mogą obejmować miliardy wierszy danych. Pod koniec lat 90. i na początku 2000 r. rynek ETL był podobny do Związku Radzieckiego pod koniec lat 80.: duży i rozdrobniony. Wielu wyspecjalizowanych dostawców ETL obsługiwało rynek BI; dostawcy oferujący produkty bazodanowe (takie jak Microsoft, Oracle i IBM) miały wersje ETL - o różnych możliwościach. W ostatnich latach rynek ETL skonsolidował się, oddziałując z obu stron strumienia informacji BI:

•  Główni dostawcy baz danych wkroczyli na rynek, łącząc produkt ETL ze swoją ofertą DBMS, tak jak miało to miejsce w przypadku, gdy Sybase zakupiła czysty produkt ETL o nazwie Solande.
•  W niektórych przypadkach twórcy narzędzi BI dla użytkowników końcowych wkroczyli również na rynek ETL, aby stać się bardziej "pionowo zintegrowani" z rynkiem BI. Poniżej znajduje się lista głównych dostawców ETL wraz z kilkoma słowami o oferowanym przez nich produkcie.
Wielu kierowników projektów BI skupia się na ETL, ale traci z oczu jakość danych. Chociaż z pewnością musisz wprowadzić dane na miejsce i znormalizować je, jeśli nie zostaną wyczyszczone, nie uzyskasz dobrej jakości wglądu. Dobrym pytaniem, które należy zadać każdemu dostawcy ETL, jest to, czy jego produkt zawiera moduł jakości danych, który zawiera narzędzia do rozpoznawania "nieczystych" danych i nadawania im kształtu.
Powrót

05.10.2021

Informatica

Wzmianka ETL i Informatica to nazwa, która nieuchronnie jako pierwsza spłynie z języków ekspertów BI. Są wiodącym dostawcą ETL na rynku i od kilku lat pozostają neutralni w wojnach oprogramowania. Narzędzie do integracji danych Informatica nazywa się Power Center; jego sukces można przypisać jego jakości i interoperacyjności z każdym rodzajem platformy. To klucz do udanego ETL, z oczywistych powodów: dane transakcyjne mogą pochodzić z dowolnego typu systemu - aplikacji łańcucha dostaw SAP, pakietu Oracle HR, kilku baz danych SQL Server lub DB2 i kto wie, co jeszcze. Informatica może rozmawiać z nimi wszystkimi i nie polega tylko na otwartych standardach, aby to zrobić.

IBM

IBM zrobił duży plusk na rynku ETL, kupując Ascential, wiodącego dostawcę ETL i jednego z głównych konkurentów Informatica. Pojawiają się pytania o to, jak dobrze Ascential można zintegrować z ekosystemem oprogramowania IBM, ale ruch ten był popularny wśród wielu analityków, którzy postrzegali to jako wzmocnienie możliwości integracji danych IBM.

Oracle

Podobnie jak w przypadku IBM, Oracle oferuje kompleksowy pakiet produktów BI. Podobnie jak IBM, Oracle nie trzymało się własnego produktu integracyjnego; pod koniec 2006 r. Oracle ogłosiło, że kupuje Sunopsis, kolejny wiodący produkt typu pure-play w przestrzeni ETL. Dopóki ten produkt nie zostanie w pełni zintegrowany, narzędzia ETL Oracle znajdują się w pakiecie Warehouse Builder; istnieją również wbudowane funkcje ETL w podstawowej bazie danych Oracle. Problem z Warehouse Builderem polega na tym, że może on umieszczać tylko zintegrowane dane w hurtowni danych Oracle.

BO

Firma BO wyrobiła sobie markę pierwotnie dzięki zestawowi narzędzi do analizy i raportowania. Ale firma wkroczyła na rynek ETL z produktem o nazwie DataIntegrator.

Microsoft

Wcześniej oferowane w pakiecie z bazą danych SQL Server jako DTS (Data Transformation Services), narzędzie ETL firmy Microsoft zmieniło nazwę na Integration Services w 2005 r. (znane również jako SSIS). To narzędzie jest bardziej niezawodne i wydajne niż stara aplikacja DTS i jest dostarczane z większością wersji SQL Server 2005.

Inni gracze

Dotychczasowi dostawcy posiadają lwią część rynku ETL, ale warto wspomnieć o kilku innych godnych uwagi graczach, w tym SAS, liderze narzędzi analitycznych. SAS posiada ofertę ETL odpowiednią dla firm, które potrzebują skomplikowanych przekształceń.

Istnieją również inni dostawcy czystej gry, tacy jak Ab Initio, iWAY i Kalindo, z których każdy ma własną niszę w świecie ETL. Jeśli masz silnych programistów, wystarczającą ilość czasu i odpowiednie potrzeby projektowe, możesz skończyć na tym, co wiele firm zdecydowało się zrobić, budując własne oprogramowanie ETL. Pozwala to na dokładniejsze dostosowanie procedur integracji danych do środowiska. Potencjalną korzyścią jest natychmiastowa oszczędność kosztów wynikająca z braku konieczności rezygnacji z dużej części zmian w licencjach na oprogramowanie innych firm. Tylko upewnij się, że obliczysz koszt zasobów związanych z utrzymaniem tego domowego pakietu ETL w czasie.

Analitycy i inni dostawcy front-end

Granica między zapytaniami, raportowaniem i analizą staje się coraz trudniejsza, ponieważ zapytania stają się podstawowymi raportami, które są następnie przekształcane w raporty zarządzane i rozproszone, które można następnie analizować w narzędziach OLAP i innych programach analitycznych.
Powrót

06.10.2021

SAS

SAS jest dobrze znanym graczem w zakresie zaawansowanych narzędzi analitycznych, które dołącza do swojej hurtowni danych klasy korporacyjnej, zbudowanej na jednej lub kilku popularnych platformach DBMS. Z konkurencyjnego punktu widzenia żaden inny dostawca nie oferuje doświadczenia i rodowodu SAS w przesyłaniu danych poprzez gimnastykę złożonej analizy statystycznej. SAS umożliwia swoim użytkownikom generowanie konsolidacji i raportów na dużych ilościach danych z bardzo złożonymi funkcjami statystycznymi. SAS jest jednym z wiodących dostawców front-end, ponieważ jego produkty obejmują tak wiele nieruchomości - w tym raportowanie, karty wyników, metryki i eksplorację danych, które dostarczają narzędzi do modelowania predykcyjnego i wspomagania decyzji.

Cognos

Ten kluczowy dostawca rozwiązań typu pure-play oferuje duży, solidny zestaw produktów BI. Cognos zawsze był znany z Impromptu i Powerplay, narzędzi do wysyłania zapytań i raportowania. Ale w dzisiejszych czasach Cognos kładzie nacisk na architekturę opartą na usługach sieciowych.

Business Objects

Według niektórych standardów Business Objects jest numerem jeden wśród dostawców rozwiązań BI, ale w takim przypadku musiałbyś uwzględnić strasznie wiele zastrzeżeń dotyczących firmy Microsoft. Aby mieć pewność, BO jest sprzedawcą czystej gry, który wciąż stoi po tylu latach - nie lada wyczyn. BO ma siedzibę we Francji i oferuje swoje produkty i usługi pod parasolowym narzędziem BI o nazwie Web Intelligence. Firma niedawno podpisała umowę partnerską z IBM. Business Objects umocniło swoją pozycję na lub w pobliżu szczytu rynku BI, przejmując Crystal Decisions, już rentowną firmę z dużą populacją istniejących klientów, korzystającą z produktów do raportowania BI. W 2007 roku firma BO ponownie wprowadziła Crystal Reports jako usługę sieciową - gorący trend na wszystkich rynkach oprogramowania.

Mikrostrategy

Microstrategy to spółka publiczna, która kiedyś była większym graczem w świecie BI. Obecnie firma polega na swoich usługach konsultingowych tak samo jak na licencjach na oprogramowanie; wydaje się, że konkurencja powoli wypiera je z rynku. Microstrategy jest tradycyjnie znany jako dostawca hurtowni danych i hurtowni danych, ale w ostatnich latach położył większy nacisk na wyrafinowaną platformę pulpitu nawigacyjnego i wizualizacji.

SPSS

Ten specjalistyczny sklep stał się ważnym graczem na scenie BI, oferując zaawansowane pakiety do analizy statystycznej wraz z rozwiązaniami raportowania. SPSS nadrabia zaległości z SAS w dziedzinie łamania liczb, częściowo dlatego, że spóźnił się na grę w użyteczność, niechętnie odchodząc od formatowania mainframe.

BI stało się proste: dostęp

Możliwe jest stworzenie środowiska BI z najbardziej podstawowymi narzędziami technologicznymi. Microsoft Access okazał się niezwykle wszechstronnym i potężnym narzędziem bazodanowym. Microsoft Excel może działać jako potężna alternatywa dla garści drogich narzędzi do wysyłania zapytań, raportowania i analiz - zwłaszcza z nową funkcjonalnością BI wbudowaną w MS Excel 2007. W rzeczywistości można stworzyć całe środowisko BI, używając wyłącznie narzędzi pakietu Office. Korzystanie z VBA i skryptów, możesz pisać własne narzędzia ETL, które wykorzystują ODBC i inne popularne protokoły do konwersacji ze źródłami danych w całej firmie. Następnie program Access może przechowywać same dane, działając jako "magazyn". Access ma wbudowane narzędzie do raportowania lub może przesyłać dane do programu Excel, który obsługuje coraz bardziej złożone tabele przestawne. Oczywiście takie podejście ma swoje ograniczenia. Dostęp jest ograniczony między innymi pod względem ilości danych, które może obsłużyć i szybkości, z jaką może przetwarzać zapytania. Ale lekcja jest jasna: wartościowy, aktualny i praktyczny wgląd nie obchodzi, kim są jego matka i ojciec. Jego wartość jest nieodłączna, bez względu na to, czy pochodzi z wymyślnego systemu za milion dolarów, czy z domowego programu skleconego razem z gumkami do żucia i gumą do żucia. Nie zakładaj, że BI musi być firmową wersją programu Apollo. Zacznij od małych rzeczy i zobacz, jak to idzie, zanim wycelujesz w księżyc
Powrót

07.10.2021

Prezentacja sprzedaży

Celem prawie każdego dostawcy BI jest olśnienie działu marketingu Twojej firmy lub innego obszaru, który nie jest w stanie dostrzec wad i pułapek technicznych w zgrabnej prezentacji sprzedażowej. Rozwiązania dostawców są nieuchronnie proste: kup to jedno narzędzie, zainstaluj je, włącz i obserwuj przepływ informacji. Rzeczywistość znacznie różni się od tego, co obiecuje boisko. Zazwyczaj dostawcy BI mają narzędzie wejściowe, które uzależnia Twoją firmę od linii produktów, ale aby uzyskać z niej jak najwięcej, musisz kupić kolejne dodatki, w tym inne moduły i platformy. Nie tylko to, ale instalacja nigdy nie jest tak łatwa, jak w reklamie. Zawsze dobrze jest mieć centralną radę nadzorczą do sprawdzania propozycji nabycia oprogramowania przez różne działy i zespoły w firmie. Jest to szczególnie prawdziwe, gdy zespoły te zwrócą się do zespołu IT o zainstalowanie - a następnie wsparcie - aplikacji BI.
Powrót

08.10.2021

Dziesięć kluczy do sukcesu BI

Wybór dobrych kluczowych wskaźników wydajności (KPI)

Jak Twoja organizacja mierzy sukces? Wydaje się to nieszkodliwe pytanie, ale zdumiewająca liczba dyrektorów nie potrafi na nie odpowiedzieć. Mierzenie kluczowych wskaźników wydajności (KPI) i zarządzanie nimi jest ostatecznym celem każdego rozwiązania analizy biznesowej. KPI to mierniki i pomiary, które na pierwszy rzut oka wskazują, czy firma żyje, czy umiera. Spostrzeżenia uzyskane dzięki BI powinny prowadzić do lepszych decyzji - a następnie (przypuszczalnie) lepszej wydajności, która pojawi się później w KPI. Chodzi o to, że jeśli mądrze wybierzesz swoje KPI, firma będzie prosperować w dłuższej perspektywie. Wybierz KPI, które pasują do Twoich celów biznesowych. Jeśli prowadzisz centrum obsługi telefonicznej (na przykład), Twoje rozwiązanie BI powinno opierać się na wskaźnikach KPI, takich jak średni czas utrzymywania i średni czas obsługi. Jeśli jesteś dyrektorem ds. operacyjnych (COO) linii lotniczej, wiesz, że Twoje kluczowe wskaźniki wydajności będą miarami specjalistycznymi, takimi jak przychodowe mile pasażerskie, dostępne mile miejscowe, dostępne mile miejscowe na pracownika i inne wskaźniki branżowe. Te wskaźniki mogą niewiele znaczyć dla nikogo spoza Twojej branży, ale dla kadry kierowniczej w Twojej firmie sprawiają, że świat się kręci.

Dostosowywanie przepisu

Istnieje wiele dobrych rad, od najlepszych praktyk po pełne rozwiązania. Każdy element podstawy technologii i praktyk biznesowych, na których budujesz swoje rozwiązanie, jest gdzieś opisany w podręczniku. Ale (oto znana mantra) nie ma czegoś takiego jak uniwersalne rozwiązanie. Firmy są na to zbyt złożone; dwa pozornie podobne problemy technologiczne i biznesowe rzadko wyglądają tak samo z bliska. Spójrz na wiele opcji i wybierz kombinację najlepszych pomysłów i odpowiedzi, które pasują do Twojej firmy. Podsumowując, użyj tego, co działa dla Ciebie.

Pogodzenie się ze złożonością

Sprzedawcy i konsultanci sprawiają, że wszystko wydaje się takie proste: zainstaluj to, skonfiguruj i już masz rozwiązanie BI, które poprowadzi Twój biznes przez stratosferę. Gdyby to było takie proste. Choć diagram może wyglądać na papierze, kiedy faktycznie zaczniesz zagłębiać się w szczegóły, znajdziesz szczurzy labirynt o złożoności. Planowanie złożoności to najlepszy sposób, aby uchronić się przed jej negatywnymi skutkami. Załóżmy, że rozwiązywanie problemów w projekcie BI zajmie więcej czasu. Daj sobie więcej czasu niż w przypadku bardziej znanych. A przede wszystkim przyjmuj i egzekwuj podstawowe procesy, które można dostosować do wszelkiego rodzaju problemów. W ten sposób, jeśli okaże się, że dane wyzwanie różni się od sposobu, w jaki je początkowo zdiagnozowałeś, Twój zespół będzie wystarczająco elastyczny, aby zmienić biegi bez całkowitego zatrzymania.

Myślenie (i praca) nieszablonowe

To rozdzierający banał, ale ważny punkt. Aby odnieść sukces w swoim projekcie BI, są chwile, kiedy trzeba wyrzucić książkę (mówiąc metaforycznie oczywiście - a nie tę) i pomyśleć o rzeczach w innym świetle. Musisz uwolnić swoje pomysły z ich tekturowego więzienia. Złożoność technologii nie zawsze jest czymś złym; daje alternatywy, gdy trafisz na widoczną przeszkodę. Nie zakładaj, że musisz podążać każdym krokiem ścieżki wyznaczonej przez dostawcę lub konsultanta; jeśli zdołasz nakłonić swój zespół do myślenia poza… cóż wiesz … jeśli możesz to zrobić, prawdopodobnie zbudujesz rozwiązanie, które najlepiej wykorzysta unikalne mocne strony Twojej firmy i zespołu.

Wybór zwycięskiej drużyny

Twoja implementacja BI będzie tak dobra, jak zespół ludzi, którzy ją projektują, budują i wspierają. A ponieważ systemy analizy biznesowej są wplecione w strukturę firmy, potrzebni są członkowie projektu, którzy rozumieją zarówno technologię, jak i aspekty biznesowe wykonywanego zadania. I wykracza to poza zwykłe znajdowanie ekspertów w swoich dziedzinach; chcesz znaleźć ludzi z odpowiednim nastawieniem. W projekcie BI sprawy nie zawsze układają się idealnie; może to być kolejka górska. Czy twoi programiści, analitycy biznesowi i architekci danych będą krzyczeć z rękami w powietrzu i wielkimi uśmiechami na twarzach? A może z każdym zanurzeniem i zakrętem będą zielone?

Odrabianie lekcji

Business Intelligence to szybko rozwijająca się dyscyplina (podobnie jak prawie wszystko inne w świecie technologii) i jest tam mnóstwo wiedzy - w książkach, białych księgach, blogach, materiałach marketingowych i wielu innych formatach. Nigdy nie zakładaj, że wiesz wystarczająco dużo. Może to zadziałać na Twoją korzyść tylko wtedy, gdy zostaniesz ekspertem merytorycznym w obszarach BI najbardziej istotnych dla Twojego wdrożenia - i zachęcisz swój zespół, aby zrobił to samo. Profesjonalne organizacje, takie jak The Data Warehousing Institute (TDWI) i specjalistyczne publikacje branżowe, takie jak DMReview, to świetne miejsca na początek.

Pamięć rzeczy przeszłych (szczególnie błędów)

Na drodze są pułapki i wyboje, których po prostu nie da się uniknąć. Sztuczka polega na tym, aby pamiętać, co zrobiłeś, zanotować, w jaki sposób można było uniknąć błędu i znaleźć najlepszy sposób na złagodzenie sytuacji, gdyby się powtórzył. Niepoprawni optymiści powiedzieliby, że każdy błąd jest okazją do nauczenia się czegoś małego. Zespoły projektowe BI odnoszą sukcesy, ponieważ w pełni wykorzystują swoje doświadczenie. I nie mówimy tylko o know-how w zakresie analizy biznesowej; chodzi o inne podstawowe umiejętności, takie jak zarządzanie projektami i kodowanie. Doświadczenie specyficzne dla firmy pomaga również doświadczonym pracownikom poruszać się po zagmatwanych schematach organizacyjnych, identyfikować przydatne zasoby i potencjalne problemy oraz w pełni wykorzystywać kulturę korporacyjną.

Całkowite uwzględnienie kultury korporacyjnej

Każda organizacja ma swój własny charakter, a przed wyruszeniem na wielką przygodę z BI, powinieneś dać swój szybki test osobowości, składający się z jednego pytania. Sposób, w jaki firma działa, jak jest zorganizowana, gdzie znajduje się władza i jak podejmowane są decyzje, powinny być częścią procesu planowania. Udane projekty Business Intelligence zawsze obejmują kulturę korporacyjną we wczesnych fazach gromadzenia informacji i projektowania. Sednem kwestii kultury korporacyjnej jest pytanie, gdzie w firmie spoczywa władza:

•  Scentralizowany: W scentralizowanych przedsiębiorstwach spółki zależne i zewnętrzne zespoły są operacyjnie podporządkowane centralnemu rdzeniowi kadry kierowniczej.
•  Zdecentralizowana: Zdecentralizowana kultura oznacza, że decyzje podejmowane na szczycie organizacji są jedynie punktem wyjścia do negocjacji. Zaprojektuj swój zespół BI, plan projektu i sam system tak, aby zasługiwały na aprobatę osób sprawujących władzę, niezależnie od tego, gdzie się znajdują w firmie (tam lub dookoła). W ten sposób Twój projekt jest zgodny z kulturą; otrzymasz wpisowe i współpracę od ludzi, którzy mają władzę.

Po prostu przechodzimy przez fazę

Możliwości Twojego projektu BI są praktycznie nieograniczone. Możesz połączyć każde operacyjne źródło danych w firmie przez hurtownie danych, a następnie skierować je do departamentowych baz danych, które zasilałyby szereg narzędzi do wysyłania zapytań, raportowania i analizy - dostosowanych do każdego działu, z dodatkową technologią wizualizacji. A kiedy będzie gotowy do uruchomienia (jakoś w ciągu następnej dekady), Rolling Stones mogą zagrać na imprezie z okazji premiery na stadionie. Dobrze. Wspaniale, że marzysz o wielkich rzeczach i kolorach, ale kierownictwo wykonawcze rzadko ma cierpliwość do tak ogromnych projektów. Większość firm woli działać ostrożnie, gdy wydawane są pieniądze; lubią, gdy projekty mogą odnosić sukcesy na małą skalę, w przeciwieństwie do robienia wielkiego plusku. A projekty technologiczne są notorycznie ściśle badane przez boondoggle policję, więc nie rezerwuj jeszcze Stones. Weź swoją wizję BI i podziel ją na łatwe do opanowania fazy. Każda faza powinna mieć

•  Dobrze zdefiniowany zakres
•  Namacalne rezultaty
•  Korzyści, które można wykazać wszystkim
•  Skromne horyzonty czasowe

Jeśli przed planowanym dostarczeniem czegokolwiek zaplanowano więcej niż jedną olimpiadę, naprawdę musisz rozważyć rozbicie swojego planu na mniejsze części.

Przyjęcie Bigwiga

Każdy projekt potrzebuje sponsora projektu na wysokim szczeblu, który jest mądry, lubiany, bezstronny i gotowy zakasać rękawy i załatwić sprawy. (Kiedy nie są one dostępne, kierownik wyższego szczebla również poradzi sobie). Projekty z zakresu analizy biznesowej są szczególnie podatne na wewnętrzny sceptycyzm, ponieważ często nie są dobrze rozumiane. A ponieważ projekty mogą dotykać tak wielu elementów organizacji - taka jest natura BI - ważne jest, abyś miał przyjaciół na wysokich stanowiskach. To, czy są bezpośrednio zaangażowani w projekt, nie jest tak ważne, jak posiadanie ich prawdziwego moralnego wsparcia. Osoba zatrudniająca i dysponująca siłą ognia dla ogromnych połaci firmy ma niesamowitą zdolność ewangelizowania i nawracania sceptyków, a także jest całkiem niezła w obalaniu przeszkód na drodze.
Powrót

09.10.2021

Dziesięć zagrożeń BI (i jak je przezwyciężyć)

Ruch oporu

Inicjatywa BI może wprowadzić Twoją organizację w stan nieustannej zmiany - i nic nie daje ludziom tak strasznych zmian, jak zmiany. Bez względu na zakres zmian, zawsze istnieje prawdopodobieństwo, że napotkasz pewien poziom oporów wobec procedur instalacji, dezinstalacji lub aktualizacji, które próbujesz wykonać. Niezależnie od tego, gdzie i kiedy się pojawi, opór przed zmianą musi być zarządzany przez zespół projektu BI i współpracujących z nim pracowników, którzy śpiewają tę samą piosenkę. To, co zaczyna się jako drobne tarcia, może szybko przekształcić się w pełnowymiarową negatywność, pozostawiając Twój ruch w kierunku BI pozbawiony legitymizacji i w strzępach. Przestrzeganie programu kontroli zmian to dobry początek, ale prawdziwym kluczem jest komunikacja. Budowanie trwałych, zinstytucjonalizowanych relacji z osobami zajmującymi się IT i zarządzaniem danymi w całej firmie to świetny sposób na rozszerzenie sieci sojuszników. Utworzenie centralnego komitetu BI lub Centrum Doskonałości (COE) zapewnia idealny organ firmy do wymiany pomysłów i tworzy parasol ekspertyz nad realizowanymi projektami BI. Zanim zmienisz ogólnofirmowe standardy raportowania, przedyskutuj to na comiesięcznym spotkaniu COE. Nie tylko uzyskasz bezcenny wkład, ale także krok w kierunku wpisowego .

Ruchome cele

Jedno jest pewne w dużej implementacji BI: źródło danych, aplikacja lub proces, nad którym pracujesz, zmieni się w pewnym momencie od momentu sfinalizowania wymagań projektu do czasu jego wdrożenia. Firmy są w ciągłym stanie zmian; podobnie jak ich jednostki danych. To może powodować duże bóle głowy. Na przykład, jeśli zaktualizujesz narzędzie do raportowania, aby działało z najnowszą definicją danych klientów, co się stanie, gdy będziesz musiał poszukać w historycznych zapisach zgodnych ze starym modelem danych? Nic nie może szybciej zniszczyć procesu BI niż nieuwzględnienie zmienności danych. Planowanie i utrzymywanie widoczności w głównym zestawie hierarchii danych i relacji może pomóc w złagodzeniu tego problemu. Rozsądne jest również zintegrowanie planu projektu z innymi planami w toku w firmie. Czy jest (powiedzmy) planowana aktualizacja do nowej wersji oprogramowania pomocniczego? Czy zmiany w pracach, aby metadane ERP odzwierciedlały ostatnią akwizycję firmy? Planowanie takich zmian z wyprzedzeniem jest lepsze niż sprzątanie bałaganu po fakcie.

Wypuszczanie narzędzi

Jest wystarczająco dużo gorącego powietrza pochodzącego od dostawców BI, aby umieścić na niebie flotę sterowców. Wielu kierowników projektów zostało spalonych przez aplikację, która nie jest w stanie sprostać wymaganiom. Wdrożenie odpowiednich narzędzi ma kluczowe znaczenie dla powodzenia większości wdrożeń BI. Nawet w przypadku znanych dostawców cykl oceny oprogramowania nie oznacza działalności pro forma, więc nie oszczędzaj na tym. Obowiązują tu dwie zasady:

•  Powinieneś ustanowić podstawowy proces, aby móc uczciwie wstrząsnąć stronami trzecimi podczas ich dnia w sądzie.
•  Poziom kontroli nad narzędziem (lub dostawcą świadczącym usługi) powinien wzrastać wraz z jego znaczeniem w Twoim systemie.

Po określeniu zakresu i architektury swojego systemu BI wykonaj następujące kroki:

1. Zbadaj i opracuj listę kandydatów, którzy przynajmniej twierdzą, że oferują rozwiązanie dla danej funkcji. Polecenia od organizacji zawodowych to dobry początek.
2. Zwróć szczególną uwagę na wysiłki sprzedażowe sprzedawcy. Czy dzwonią do ciebie, kiedy mówią, że to zrobią? Czy są gotowi przekazać Ci złe wieści o ograniczeniach ich produktu? Uczciwy i szczery wysiłek sprzedażowy jest dobrym wyznacznikiem zdrowej firmy.
3. Zażądaj kompleksowego demo.
4. Obejrzyj obszerne demo. Ale nie dajcie się uśpić migającym światełkom i ładnej grafice. Zadawać dużo pytań. Na przykład możesz zapytać, czy każdy demonstrowany produkt jest objęty standardowym systemem licencji. Poproś zespół sprzedaży o wyjaśnienie typowych problemów, z jakimi spotykają się klienci. Demonstracja nie jest prezentacją, powinna być początkiem długiego dialogu między Twoim zespołem a zespołem sprzedaży dostawcy.

Nie oszczędzaj na cyklu oceny oprogramowania. Użyj wielu kryteriów, aby ocenić oprogramowanie; nie zadowalaj się tłumem z najmilszymi sprzedawcami lub najbardziej zgrabną demonstracją. Kop głęboko; to opłaci się później w pikach.

Bycie użytkownikiem przegranym

Co jeśli zbudowałeś system i nikt nie pojawił się, aby go użyć? Użytkownicy są tym, co sprawi, że Twój system odniesie sukces lub porażkę. Istnieje wiele powodów, dla których użytkownicy mogą nie gromadzić się przed narzędziami, które wprowadzasz. Przede wszystkim, jeśli środowisko BI nie dodaje wartości do ich misji, nie będą z niej korzystać; to takie proste. Upewnij się, że dodaje tę wartość, włączając użytkowników końcowych na wczesnym etapie procesu. Zbyt wielu techników uważa, że wie, czego chcą użytkownicy, więc pozostawiają przeciętnego użytkownika poza procesem tworzenia koncepcji i projektowania. Zaangażuj użytkowników końcowych na wczesnym etapie procesu zbierania wymagań; upewnij się, że zajmujesz się tymi problemami i starasz się jak najlepiej zaspokoić ich potrzeby. Następnie, po uruchomieniu programu BI, dobrze wspieraj społeczność użytkowników. Oferuj szkolenia i usługi pomocy technicznej, aby przyciągnąć więcej osób. A jeśli zdarzy się najgorszy przypadek, gdzie go zbudujesz, a on nie nadejdzie, szybko dowiedz się dlaczego. Nie siedź wygodnie i nie czekaj na skargi i informacje zwrotne. Aby wykryć problemy z dużym wyprzedzeniem, monitoruj trendy użytkowania w swoich domenach BI jako standardową zasadę. Niezależnie od tego, czy problem jest prosty, czy złożony, im szybciej go zrozumiesz i rozwiążesz, tym większe masz szanse na naprawienie statku, zanim zatonie.

Pan Data potrzebuje kąpieli

Jeśli kiedykolwiek pojawiło się dziecko z plakatu dla systemu Garbage-In-Garbage-Out, to jest to królestwo narzędzi do analizy biznesowej. Jeśli masz wątpliwe dane źródłowe wprowadzane do raportów, pulpitów nawigacyjnych, analiz i innych aplikacji przeznaczonych dla użytkowników, ich wyniki nie będą warte ryzy papieru do drukarki igłowej. Wątpliwe informacje mogą zmienić się w złe informacje i mieć negatywny wpływ na każdego z konsumentów na dalszych etapach. Jakość danych to ciągły problem w BI, zwłaszcza gdy istnieje hurtownia danych zaangażowana. Różne systemy źródłowe mają różne warstwy kontroli i spójność reguł biznesowych. Uwzględnij czas na audyt, analizę i (jeśli to konieczne) naprawienie danych u źródła, jeśli to w ogóle możliwe. Dane źródłowe nie są elementem typu "napraw i zapomnij". Zastanów się: Czy potrafisz rozpoznać, kiedy osiągasz złe wyniki? A jeśli rozpoznasz problem, czy możesz prześledzić jego źródło? Wyobraź sobie, co mogłoby się stać, gdyby jedno z operacyjnych źródeł danych zasilających Twoją hurtownię danych właśnie przeszło zmianę reguły biznesowej (o której oczywiście nikt Ci nie powiedział), która pozwala użytkownikom zmieniać aktywne numery kont - pole, którego Twój proces ETL używa jako klucz podstawowy. (Hej.) Nagle istnieje szansa, że historyczne informacje o transakcjach mogą nie mieć nic wspólnego z przyszłymi transakcjami dla kont, które zmieniono. Nie będziesz wiedział, że ten problem się czai . . . chyba że wprowadziłeś w swoim systemie pewne staranne procedury audytu i zarządzania zmianami danych.

Ciasto nie do przejścia?

Jeśli Twój projekt doznaje pewnego rodzaju redukcji budżetu, nie czuj się źle, nie jesteś pierwszy i nie będziesz ostatnim. To, czy kontynuacja jakiegokolwiek projektu ma sens, zależy od okoliczności. Ale jedno jest pewne: jeśli alokacja zasobów finansowych nie zostanie wykonana uczciwie, projekt jest skazany na porażkę. Nie pozwól, aby entuzjazm do projektu stanął na drodze do podjęcia racjonalnej decyzji o tym, co można realistycznie dostarczyć. Istnieje naturalna tendencja do mówienia: "Cóż, wiem, że połowa budżetu została wymazana, więc możemy dostarczyć następujący ograniczony zakres … " Łał. Zwolnij - zastanów się długo i intensywnie, zanim to zrobisz. W przypadku otwieraczy spróbuj odpowiedzieć na te pytania:

•  Czy bierzesz pod uwagę wszystkie koszty przejścia związane z dostosowaniem kierunku zespołu projektowego do mniejszego zakresu?
•  Czy limitowana wersja nadal zapewnia wystarczającą wartość biznesową, aby była tego warta?
•  Czy kilka miesięcy dalej czai się kolejna obniżka budżetu?

Bądź szczery, jeśli chodzi o realia finansowe, z którymi się zmagasz. Wdrożenia BI mogą zapewnić ogromną wartość, ale są drogie. A jeśli firma nie chce zainwestować w odpowiednią implementację, być może nadszedł czas, aby całkowicie przemyśleć projekt.

Pełzanie zakresu

W środowisku BI działają pewne siły elementarne; zawsze będzie presja na budżet spowodowana nieoczekiwanymi kosztami lub przekroczeniami i oczywiście zawsze będzie presja, aby zrobić trochę więcej, niż pierwotnie zamierzałeś zrobić. Zjawisko to nazywane jest pieszczotliwie pełzaniem zakresu. Projekty BI mają notorycznie wysoką częstotliwość pełzania zakresu, ponieważ BI przenika do tak wielu działów i często dotyka wielu różnych wcześniej istniejących systemów. Zanim się zorientujesz, otrzymujesz prośby od menedżerów średniego szczebla, o których nigdy wcześniej nie słyszałeś, i czyścisz dane, których nie planowałeś dotknąć. Unikanie pełzania zasięgu to aktywna odpowiedzialność dla Ciebie i reszty Twojego zespołu. Na początek pamiętaj o tych podstawowych zasadach:

•  Nie spiesz się z oryginalnym zakresem; upewnij się, że wszystko jest zaadresowane.
•  Przewiduj zmiany; wbuduj elastyczność w swój plan projektu. Załóżmy, że dyrektor finansowy (lub ktoś inny, komu nie możesz odmówić) dokona w ostatniej chwili poprawek.
•  Zatrudnij świetnych analityków biznesowych, aby dostarczali doskonałe wymagania biznesowe, umieszczali je w bezbłędnej dokumentacji i zarządzali nimi przez cały okres wdrożenia.
•  Szanuj swoje procesy; pamiętasz ten szczegółowy proces zarządzania zmianą, który tak dokładnie opracowałeś na etapie planowania swojego projektu? To nie było tylko na pokaz. Użyj tego.

Zakresy naturalnie pełzają. To właśnie robią. Czujność to hasło przewodnie.

Sztywność

OK, właśnie skończyłem pouczać cię o tym, że jesteś zbyt sztywny, jeśli chodzi o zakres - ale tak jak w przypadku wszystkich rzeczy, jest druga strona: czasami elastyczność jest korzystna. Podczas procesu tworzenia pojawia się tendencja do myślenia oddolnego - podejmowania decyzji dotyczących konkretnych szczegółów (takich jak układ raportów) bez uwzględniania szerszego kontekstu środowiska BI. To może zablokować kluczowe decyzje zbyt wcześnie w procesie. Nie zakładaj, że wiesz, czego będą chcieli i potrzebować użytkownicy. Oto kilka sposobów na przygotowanie się na ich zmieniające się potrzeby:

•  Wbuduj w swój plan projektu pewną elastyczność, która umożliwia łatwe dostosowywanie elementów frontonu.
•  Zainstaluj narzędzia samoobsługowe, które pozwalają użytkownikom (po odrobinie szkolenia) kontrolować własne doświadczenia z narzędziem - uruchamianie zapytań, budowanie i formatowanie raportów, niezależnie od tego, co pasuje do ich pracy i projektu projektu.

Kryzys środowiskowy

Początkowa inicjatywa BI może wymagać różnych narzędzi front-end, aby zaspokoić różnorodne potrzeby różnych zespołów w całej firmie. Ponadto firmy często z czasem instalują i rozbudowują swoją podstawową infrastrukturę BI, tworząc wiele środowisk danych, które zasilają różnych klientów w całej firmie. Ta fragmentacja środowisk może prowadzić do zamieszania w kwestii dostępu do pewnych informacji. Nic dziwnego, że niektórzy dostawcy oferują portale (lub podobne pakiety integracyjne), które łączą wiele poddomen informacji w konstelacji BI firmy. Portale działają, prezentując użytkownikowi pojedynczy interfejs, który ma dostęp do kilku różnych środowisk BI, takich jak narzędzia do raportowania lub analizy. Zwykle w grę wchodzą dwa kroki:

1. Użytkownik wprowadza zapytanie o dane.
2. Portal wyszukuje system, który może mówić tym samym językiem, a następnie wykonuje jedną z dwóch rzeczy:

•  Zwraca żądanie
•  Przenosi użytkownika bezpośrednio do konkretnego narzędzia BI
Powrót

10.10.2021

Dziesięć kluczy do zebrania dobrych wymagań BI

Wszyscy właściwi ludzie

Skonstruowanie dobrego dokumentu wymagań początkowych jest możliwe tylko wtedy, gdy są do pomocy odpowiednie osoby. I nie chodzi tylko o zaproszenie; ludzie, którzy zjawiają się na spotkaniach, muszą być gotowi do udziału. Ułatwienie sesji wymagań to tyleż sztuka, co nauka. Niektóre z najmądrzejszych, najlepiej zorganizowanych mózgów technologii na świecie nie są w stanie stanąć w pokoju pełnym ludzi i wskazać kierunek spotkania. Tak więc pierwsza osoba na twojej liście uczestników powinna być wykwalifikowanym moderatorem spotkań. Może to być doświadczony analityk biznesowy w Twoim zespole lub wynajęty pistolet spoza zespołu projektowego. Kogokolwiek wybierzesz, dobry facylitator zamieni te meandrujące, nieskoncentrowane spotkania, których wszyscy się boimy, w sesje dotyczące produktywnych wymagań. Planując sesje wymagań, upewnij się, że bardzo dokładnie zaplanowałeś dwie rzeczy: program i listę uczestników. Po ustaleniu tematów do omówienia na każdą sesję lub rozmowę kwalifikacyjną - z dużym wyprzedzeniem - nie zostawiaj tego przedstawicielom każdego działu, aby obsadzili spotkanie. Zapytaj dokładnie, dlaczego każda osoba musi tam być. W przypadku rozwiązania BI rozważ zaproszenie uczestników z tymi trzema różnymi perspektywami:

•  Przedstawiciele bazy użytkowników dla obszaru biznesowego, który obejmujesz.
•  Eksperci merytoryczni (osoby, które znają obszar biznesowy, ale w rzeczywistości mogą nie być potencjalnymi użytkownikami końcowymi aplikacji BI).
•  Przedstawiciele technologii, którzy mogą udzielić wskazówek do rozmowy w zakresie tego, co jest wykonalne, a co nie, w przypadku omawianego rozwiązania.

Technicy czerpią również korzyści ze spotkań wymagań, zbierając kluczowe fakty z negocjacji, które mogą nie być poruszane jako punkty porządku obrad, a nawet wypowiedziane na głos. Zespół ds. interfejsu użytkownika (w szczególności) może szybko rozpocząć pracę, przyswajając to, co zostało powiedziane o gustach użyteczności społeczności użytkowników. Dodatkową korzyścią jest to, że spotkania uzmysłowią analitykom danych znaczenie pewnych elementów danych, prawdopodobnie generując wczesne pomysły dotyczące logicznego projektu bazy danych. Nie oczekuj, że wszystkie najistotniejsze punkty spotkania zostaną wchłonięte przez osmozę do głów wszystkich uczestników. Potrzebujesz tam kogoś, kto potrafi (i będzie) robić doskonałe notatki. Brzmi to przyziemnie, ale dobry skryba może pomóc w uzyskaniu doskonałych wyników ze spotkania w celu ustalenia wymagań - podążając za łukiem rozważań, rejestrując, dlaczego wybrano jedną alternatywę zamiast innej, i śledząc działania, które wychodzą ze spotkania.

Sprawa wizji

Przed przeprowadzeniem sesji dotyczącej wymagań, aby zagłębić się w specyfikę projektu, dobry kierownik projektu BI umieszcza wszystkich interesariuszy na tej samej stronie pod względem ogólnego kierunku, wizji i kalendarza produktu. Takie postępowanie umieszcza szczegóły projektu w odpowiednim kontekście - coś, co często jest pomijane. Jak możesz podjąć decyzję o (powiedzmy), które narzędzia graficzne będą wyświetlać Twoje dane, jeśli nie znasz większego celu biznesowego aplikacji? Jasne, możesz zagłębić się w takie szczegóły, ale zwykle rozwiązanie, które otrzymasz, nie będzie zgodne z wielką strategią wdrożenia BI. Nie tylko szczerze rozmawiaj z interesariuszami na temat ogólnych celów i wizji projektu. Powiąż go bezpośrednio z procesem zbierania wymagań. Wyjaśnij, że działania podejmowane podczas dyskusji o wymaganiach to nie tylko bezczynna paplanina; dosłownie wypełniają puste pola na projekt aplikacji. Kiedy nadejdzie czas na zorganizowanie sesji projektowej z klientami wewnętrznymi, przypomnij im, dokąd zmierza aplikacja BI, jakie problemy musi rozwiązać i jakie są ważne ograniczenia. Utrzymuj tę wizję na pierwszym planie przez całą fazę zbierania wymagań - i przez cały projekt.

Łączenie BI z motywami biznesowymi

Każda firma ma motywy: Co firma próbuje zrobić? Jak jego ludzie próbują wykonać tę pracę? Takie tematy reprezentują główne imperatywy organizacji. Oto kilka typowych przykładów:

•  Zapewnij doskonałą obsługę klienta!
•  Zwiększaj przychody bez rezygnacji z zysku
•  Oferuj produkty idealne na rynek
•  Poszukuj innowacyjnych sposobów obniżenia kosztów przy jednoczesnym utrzymaniu poziomu usług

Najczęściej motywy te napędzają każdą większą inicjatywę podejmowaną przez firmę, bezpośrednio lub pośrednio - w tym projekty BI. We wczesnych fazach pozyskiwania wymagań upewnij się, że mówisz nie tylko o ogólnej strategii BI dla firmy, ale także o powiązaniu tej strategii z tymi samymi tematami; Twoi interesariusze powinni już je znać.

Upewnij się, że spostrzeżenia są w zasięgu wzroku

W przypadku projektu analizy biznesowej należy zdefiniować wszystkie wymagania w kontekście konkretnego wglądu, który próbujesz osiągnąć lub odkryć. Każdy spostrzeżenie powinno pasować do jednego z głównych tematów firmy. Jako przykład tego, jak to działa, wyobraź sobie dużego producenta sprzętu sieciowego, który oferuje kilka różnych linii produktów. Ich konsultanci sprzedają rozwiązania, które obejmują mieszankę komponentów, wszystkie wyprodukowane przez ich różne działy. Niektóre komponenty są nawet budowane przez byłych konkurentów, którzy zostali nabyci i obecnie działają jako spółki zależne. Ponieważ systemy sprzedaży i księgowości różnią się w wielu organizacjach, a negocjowane warunki różnią się w zależności od klienta, trudno jest uzyskać obraz rentowności pojedynczego klienta lub rozwiązania. Znajomość wkładu w rentowność każdego działu byłaby wglądem o ogromnej wartości dla firmy. Umożliwiłoby to zespołowi zarządzającemu sprzedażą poprawę wyników firmy poprzez ścisłe zarządzanie asortymentem produktów dla wszystkich przyszłych transakcji. Zespół projektowy BI powinien podejść do zbierania wymagań z tym spostrzeżeniem mocno zakorzenionym w ich umyśle. Jakie dane muszą zebrać, aby osiągnąć ten wgląd? Jak trzeba nim manipulować? Jakich narzędzi będzie potrzebował zespół zarządzający sprzedażą, aby jak najlepiej wykorzystać tę konkretną wiedzę? Możesz nie znać wszystkich problemów, które próbujesz rozwiązać, ale zawsze warto zacząć od garstki wyzwań biznesowych, co do których wszyscy zgadzają się, że rozpaczliwie potrzebują rozwiązań - ta lista staje się centralnym punktem zbiorczym dla procesu wymagań. Analitycy biznesowi często ulegają pokusie gromadzenia wymagań w próżni, skupiając się na agendzie, a tym samym na procesach biznesowych, które należy zdefiniować. Chociaż odfiltrowanie hałasu z większych dyskusji pozwala zespołowi skoncentrować się na każdym etapie procesu, nie filtruj wszystkiego. Dopóki spostrzeżenia, których szukasz, są dobrze zdefiniowane, a interesariusze postrzegają je jako niezmienne, mogą one katalizować proces tworzenia wymagań i utrzymuj to w zgodzie z szerszymi celami biznesowymi.

Największe hity z wczoraj i dziś

Częścią pozyskiwania wymagań jest zrozumienie terenu, na którym obecnie stoi firma. W ten sposób, kiedy zdecydujesz, dokąd się udać, pomoże ci narysować linię na mapie, aby się tam dostać. Faza pozyskiwania wymagań to dobra okazja, aby porozmawiać z interesariuszami i potencjalnymi użytkownikami aplikacji o tym, jak zmagają się teraz z problemami biznesowymi - zanim pierwszy element rozwiązania BI zostanie uruchomiony. Możliwe, że dzisiejsze podejście do problemów może dostarczyć wskazówek, jak programiści powinni podejść do rozwiązania BI. Przejrzenie krok po kroku przykładów tego, w jaki sposób zespół obecnie wykorzystuje informacje w celu uzyskania określonego wglądu, jest często bardziej przydatne niż zwykłe katalogowanie potrzeb informacyjnych bez kontekstu. W wielu przypadkach grupy użytkowników i interesariusze domagają się zmiany (lub przynajmniej jakiegoś ulepszenia) - ale nie zawsze. Przeglądając sposoby, w jakie działy przetwarzają dane i zbierają informacje, możesz zdecydować, że niektóre z tych kroków - a nawet cały proces - powinny zostać zachowane. To może się zdarzyć. Mimo że oprogramowanie na rynku jest teraz potężniejsze i bardziej elastyczne niż kiedykolwiek wcześniej, nie powinieneś czuć się zobowiązany do wprowadzania zmian tam, gdzie żadna nie jest potrzebna. Pomyśl długo i ciężko, zanim zakołyszesz łodzią.

Konsekwencje chodzenia bez

W fazie definiowania wymagań warto porozmawiać o rzeczywistej wartości biznesowej spostrzeżeń, których poszukujesz. Nie zawsze jest to łatwe do zdefiniowania, ale dobrym punktem wyjścia jest zadanie społeczności użytkowników prostego pytania: gdyby projekt nie posunął się do przodu, a Ty nie byłeś w stanie uzyskać tych spostrzeżeń, jak wpłynie to na firmę? To ważna droga do podróżowania; pomaga zespołowi projektowemu ustalić priorytety wymagań w sposób, którego nie zawsze można uzyskać, po prostu pytając: "Jaki priorytet powinien mieć ten wysiłek?" Pytanie, co by się stało bez rozwiązania, sprawia, że grupa mówi również o cechach rozwiązania - takich jak czas odpowiedzi, użyteczność, skalowalność i inne podobne specyficzne czynniki, które dają zespołowi projektowemu wgląd w to, czego brakuje w obecnym rozwiązaniu. Ponadto, czy pogoń za wieloma spostrzeżeniami biznesowymi skutkuje tym, że jeden proces działa w różnych celach? W takich sytuacjach musisz zrobić coś więcej niż tylko zdecydować, który z nich wygrywa; równie ważne jest zastanowienie się, dlaczego. Cała ta dyskusja i odkrycia pomagają określić priorytety projektu i sprawiają, że zbieranie wymagań jest bardziej owocne.

Jaki jest wielki pomysł?

Zbieranie wymagań to ćwiczenie w zrozumieniu potrzeb informacyjnych Twojej firmy na poziomie koncepcyjnym. Najlepszym podejściem jest odłożenie wszystkich tych szczegółowych dyskusji, takich jak formatowanie tabel, pola danych wymagane dla każdego interfejsu i inne szczegóły. Przejrzyj główne tematy swojej firmy i najpierw odpowiedz na pytania ogólne - na przykład:

•  Jakich informacji potrzebujesz i dlaczego ich potrzebujesz?
•  Co (ogólnie) zamierzasz zrobić z informacjami, gdy już je zdobędziesz?
•  W jaki sposób informacje będą przetwarzane lub przekształcane?
•  Jakie spostrzeżenia będą z tego wynikać?
•  Jakie wstępne kroki są potrzebne, aby uzyskać spostrzeżenia, których szukasz?
•  Jakie domeny informacyjne należy uwzględnić?

Takie szerokie przesłuchanie pomaga również w dyskusjach o wymaganiach. Łatwo jest zagłębić się w szczegóły i doprowadzić sesję do piskliwego zatrzymania, gdy dwie lub trzy strony kłócą się o to, której czcionki użyć w standardowym raporcie, lub czy wyświetlacz powinien zawierać wykres kołowy lub wykres słupkowy. Takie szczegóły można później wyhaszować. Najpierw zdobądź wielkie pomysły.

Idąc prosto do źródła

Po określeniu ogólnych potrzeb informacyjnych należy zagłębić się w dane źródłowe. To zadanie może wymagać spotkań z zupełnie innym zestawem ekspertów, ale nadal jest częścią szerszego procesu wymagań. Pierwsze pytania na tym etapie obejmują:

•  Gdzie są przechowywane dane?
•  Jak dostać się do danych?
•  W jakim stanie są dane?
•  Jakie są konsekwencje manipulowania danymi?

Rzeczy nie zawsze są takie, jakimi się wydają. Różne działy mogą mieć różne definicje i progi jakości danych. Standardy i definicje różnią się w zależności od zespołu; użyj procesu pozyskiwania wymagań, aby usunąć wszelkie różnice. Na tym etapie analitycy mogą zlokalizować wiele potencjalnych źródeł informacji, które próbujesz zebrać. Na przykład te same dane o dziennej sprzedaży mogą być przechowywane w różnych systemach. Podstawowe informacje są takie same, ale mogą występować subtelne różnice w dostępności lub formacie. Podczas oceny źródeł danych zdecyduj, które z nich jest najlepsze dla potrzeb Twojego projektu BI. Zrozumienie kwestii regulacyjnych i zgodności jest częścią tego, o co chodzi w tej fazie. Na przykład, jeśli Twój system przejmuje dane kontaktowe, może być konieczne przestrzeganie pewnych zasad przechowywania i dostępu, spełnienie standardów bezpieczeństwa określonych przez centralny organ zarządzania danymi w Twojej firmie, a nawet podporządkowanie się zewnętrzna agencja regulacyjna.

Dodatkowe korzyści

Równie ważne, jak skupienie, może być widzenie peryferyjne. Zbudowanie aplikacji, która wykorzystuje i wykorzystuje tak wiele informacji, otwiera nowe możliwości. Z tymi wszystkimi danymi, co jeszcze mogą zrobić użytkownicy? Czy aplikacja wnosi nieprzewidzianą wartość do innych wcześniej istniejących procesów? Sesje wymagań muszą spełniać swoje zamierzone cele, polegające na wypłukiwaniu reguł i wymagań biznesowych, ale należy ich również używać jako sesji odkrywania, aby interesariusze zastanowili się nad możliwościami, które przed nimi stoją. Ryzykiem jest oczywiście pełzanie zakresu - gdzie Twój projekt jest obciążony przez dodatkowe wymagania. Dobry proces zbierania wymagań - prowadzony przez dobrze wyszkolonych i doświadczonych analityków biznesowych - będzie najlepszą ochroną przed plagą pełzania zakresu. . Idealnie możesz chronić granice swojego projektu bez tłumienia pomysłów i dyskusji. Trzymaj się celu, ale zwróć uwagę na możliwości, które otwierają się dzięki wprowadzeniu aplikacji BI. Sesja wymagań BI różni się nieco od sesji bardziej powszechnych aplikacji IT: rozwiązania często przekraczają granice organizacyjne, łącząc wiele różnych zespołów, które zwykle komunikują się ze sobą tylko wtedy, gdy jest to konieczne do wykonywania określonych zadań. Aplikacja BI musi obsługiwać potrzeby kilku grup jednocześnie. Zespoły nie mogą być przyzwyczajone do robienia rzeczy dla wspólnego dobra. Jeśli masz dane i łączysz je ze sobą, bądź świadomy wszystkich możliwości. Możesz po prostu odkryć ścieżkę do spostrzeżeń, o których nigdy nie myślałeś, że są możliwe.

Co jest pierwsze i dlaczego

Priorytetyzacja wymagań jest tak samo ważna, jak ich pełna lista i dołączanie do nich pełnych definicji. Ale może to być bolesny proces dla interesariuszy, którzy mogą czuć, że są zmuszeni do wyboru między funkcjami. Niemniej jednak dobra sesja wymagań obejmuje określenie, jak ważna jest każda główna funkcja aplikacji. Z kolei dobra dokumentacja wymagań zawiera pewnego rodzaju wyjaśnienie, gdzie leżą priorytety użytkownika i interesariuszy biznesowych. Masz wiele możliwych sposobów ustalenia priorytetów funkcji i funkcjonalności; doświadczony analityk biznesowy może przeprowadzić sesję wymagań za pomocą szeregu ćwiczeń (takich jak głosowanie ważone i analiza spójności), aby otworzyć dyskusję. Podczas gdy Twój projekt BI jest nadal w procesie planowania, zdefiniuj z wyprzedzeniem, w jaki sposób będą rozwiązywane spory dotyczące priorytetów. Wymyślanie metody w locie może wydawać się stronnicze w taki czy inny sposób. Opracuj więc schemat, który będzie pasował zarówno do projektu, jak i klienta, uzyskaj błogosławieństwo sponsora projektu, a następnie - co najważniejsze - powiedz o tym interesariuszom przed rozpoczęciem sesji wymagań.
Powrót

11.10.2021

Dziesięć sekretów udanego wdrożenia BI

Zacząć wcześnie!

Projekt BI jest jak duży problem zarządzania operacjami, w którym czas i ilość dostaw surowców wpływa na to, jak szybko i wydajnie fabryka może wytwarzać swoje produkty. BI wymaga podjęcia konkretnych decyzji na wczesnym etapie, które wpływają na cały proces w dalszej kolejności. Wśród pierwszych list, które menedżer projektu BI powinien sporządzić, znajdują się wszelkie krytyczne produkty dostarczane (to projektowe elementy dyskretne, które ktoś musi wypełnić lub przedstawić zespołowi projektowemu, takie jak dokument, zadanie projektowe lub fragment kodu aplikacji. ) Ważne jest, aby trzymać się wszystkich terminów dostaw - zwłaszcza tych, w których czas realizacji może wymknąć się spod kontroli. Na przykład, jeśli proces zakupu i instalacji dodatkowego sprzętu sieciowego w centrum danych Twojej firmy jest długi i skomplikowany, zacznij już teraz. Jeśli Twoja firma wymaga długiego procesu oceny dostawców przed wystawieniem zamówienia zakupu podstawowego oprogramowania analitycznego, zacznij już teraz. Jeśli brakuje specjalistów z konkretną umiejętnością, której będziesz potrzebować, rozpocznij proces rekrutacji raczej wcześniej niż później. Im więcej potencjalnych dławików można zidentyfikować na początku montażu rozwiązania BI, tym mniej prawdopodobne jest, że zdławią one Twój projekt.

Zdobądź to, za co zapłaciłeś

Po wypisaniu dużego czeku do swoich dostawców, powinni być gotowi, aby wspierać Cię przez cały proces. (Wynegocjowałeś to z góry, prawda?) Ponieważ rozwiązanie BI często wymaga bezproblemowej współpracy wielu aplikacji, będziesz potrzebować pełnego wsparcia od swoich dostawców. Dobrzy kierownicy projektów wiedzą, co zostało wynegocjowane w umowie, dzięki czemu mogą zażądać obiecanych usług i wsparcia. Oznacza to znajomość i egzekwowanie umowy dotyczącej poziomu usług (SLA) dostawcy - poziom obsługi, czas reakcji, i wydajność, którą zgodzili się (na piśmie) dostarczyć. Jeśli kupione oprogramowanie nie działa zgodnie z obietnicą - lub jeśli coś, za co zapłaciłeś, nie pasuje do tabaki - zadzwoń do sprzedawcy i zażądaj naprawy. Większość wdrożeń BI nie ma luksusu czasu, więc jeśli masz jakiekolwiek wątpliwości co do umowy SLA, rozwiąż problem jak najszybciej. Umowy na oprogramowanie czasami zawierają taką wartość dodaną, jak szkolenia i godziny wsparcia wbudowane w standardowe licencje na stanowiska. Skorzystaj z nich na wczesnym etapie procesu kompilacji. Żądaj dokładnie takiej usługi i wsparcia, jakie obiecałeś. Trzymaj dostawców do ich umów SLA. Nie oszczędzaj dobrej woli dostawców do wydania 2.0; może nie być wydania 2.0, jeśli twoja wersja 1.0 zawiedzie.

Tylko przegrani ignorują użytkowników

Użytkownicy nadają kontekst projektowi; pomagają dopasować narzędzia i procesy do konkretnej sytuacji biznesowej. Pomagają zdefiniować problemy, które rozwiązujesz, i dostarczają podstawowych wskazówek, jak te problemy zostaną rozwiązane. Więc zaangażuj społeczność użytkowników na wczesnym etapie. Zdobądź ich szacunek, poproś o pomoc i uzyskaj ich wsparcie przez całe życie projektu BI. Użytkownicy pomogą kierować procesem wymagań, ale przedstawiciele użytkowników powinni zapewnić konsultacje na każdym kroku - w tym podczas oceny narzędzia, testowania, analizy danych i zarządzania. Na przykład podczas procesu kodowania niejednoznaczne wymaganie może skłonić zespół programistów do przyjęcia założeń dotyczących tego, jak system powinien działać. Zatrzymaj się. Twój zespół w rzeczywistości nie zna wymagań lepiej niż użytkownicy, więc nie powinni zachowywać się tak, jakby znali. Zdrowy zespół projektowy ma regularną interakcję z użytkownikami i może w razie potrzeby zwracać się do nich o wkład ze świata rzeczywistego.

Zrzucanie nazw

Można by pomyśleć, że wszyscy zrozumieją, jak wspaniała i ważna dla firmy jest inicjatywa BI, prawda? Cóż, nawet jeśli nie, to nadal na nich wpływa. Twoje rozwiązanie BI prawdopodobnie rozprzestrzeni się na kilka zespołów, a nawet jednostek biznesowych, wpływając na wiele różnych osób. Ciężko jest trzymać je wszystkie na tej samej stronie, bo jest ich całe stado, mają inne potrzeby i priorytety. Nawet członkowie Twojego zespołu mogą stracić z oczu celu projektu. Dlatego dobrym pomysłem jest okresowe wysyłanie notatek do wszystkich, informowanie ich o aktualnym statusie projektu, podkreślanie znaczenia inicjatywy i przeglądanie korzyści płynących z ukończenia misji na czas. Organizuj spotkania rah-rah, jeśli musisz. A kiedy komunikujesz się z odległymi jednostkami korporacyjnymi, jeśli wymienisz nazwiska sponsorów wykonawczych, masz prawie gwarancję, że utrzymasz uwagę odbiorców. Ludzie mogą zignorować pragnienia i potrzeby kierownika projektu lub administratora bazy danych, ale w e-mailu wstawiają nazwisko dyrektora generalnego jako kogoś, kto uważnie obserwuje wynik projektu i zwykle zwracają na to uwagę.

Testowanie 1-2-3 … 4-5-6 … i tak dalej

Nie żałuj testów. Nieważne co.

Proces zapewniania jakości zawsze był krótki w projektach IT; Czasy testowania są skracane, aby dostosować się do daty uruchomienia w obliczu zmian lub opóźnień w projekcie. Niestety to samo zjawisko występuje w sferze BI; testy są cięte tam, gdzie projekty mogą sobie na to najmniej pozwolić. Zanim dojdziesz do fazy testowania, odpowiedzi na ogólne pytania. Powinieneś dobrze wiedzieć, czy zestaw aplikacji, które zaprojektowałeś, odpowiada ogólnym potrzebom użytkowników. Ale dobrze zaprojektowane systemy mogą nadal zawieść, jeśli zostały źle wykonane. Jeśli system zajmie wieczność, aby odpowiedzieć na proste żądania, lub jeśli hurtownia danych będzie niestabilna, użytkownicy będą unikać Twojego systemu jak ruchomych piasków. I dopiero w trakcie procesu zapewniania jakości można zidentyfikować problemy z wdrożeniem. Testowanie rzuca światło na wszelkie problemy z oryginalnym projektem. Mogą to być problemy ze schematem bazy danych, łącznością, a nawet sprzętem. Lub może to być kwestia użyteczności. Im bardziej kompleksowa jest faza testowania, tym większe prawdopodobieństwo, że pierwsze wdrożenie zakończy się sukcesem.

Idź do bitwy z pokoju wojennego

Każda armia potrzebuje kwatery głównej. A najlepsze kwatery główne znajdują się na tyle daleko od pola bitwy, że nadchodzące ruchy można planować i przypisywać cele bez przerwy - ale na tyle blisko akcji, że komunikacja z dowódcami polowymi jest łatwa, a to, co dzieje się na froncie, jest wyraźnie widoczne. Wielu menedżerów BI opowiada się za "pokojem wojennym" w pierwszym wydaniu BI. To jest świetnym sposobem na skupienie wszystkich funkcji i działań związanych z dowodzeniem i kontrolą projektu na końcowych ważnych fazach prowadzących do wydania. "Pokój wojenny" brzmi mniej więcej tak: umieszczenie wszystkich kluczowych menedżerów i architektów w tym samym pomieszczeniu podczas końcowych etapów kodowania i testowania. Oszczędza czas i ból serca, upraszczając przekazywanie zmian, rozwiązywanie problemów i testowanie. Pokój wojenny oznacza, że problemy nie są rozwiązywane w izolacji (zjawisko, które może wywołać inne problemy, takie jak powielanie wysiłków lub niejasność co do terminów). Zapewnia również rajd ,punkt dla zespołu, tworząc atmosferę więzi i jednocząc poczucie celu w grupie. Zgrany zespół to zazwyczaj zespół skuteczny. A ponieważ inicjatywy BI zwykle wiążą się ze skomplikowanym środowiskiem technologicznym, zbliżenie do siebie talentów IT i biznesowych może zwiększyć wydajność w końcowych, krytycznych fazach każdego projektu.

Zarządzanie projektami

Zarządzanie projektem często obejmuje wiele czynności administracyjnych, takich jak utrzymywanie i komunikowanie planu projektu. W przypadku większych projektów często sensowne jest wyznaczenie kontrolera projektu lub administratora projektu, który zajmuje się wyłącznie zarządzaniem planem projektu i wykonywaniem zadań administracyjnych w pokoju wojennym. Jeśli dobrze znasz implementację BI, którą nadzorujesz, najnowsza iteracja planu projektu może w niewielkim stopniu przypominać oryginalną wersję. To nie jest oznaka złego planowania; to rzeczywistość budowania złożonego rozwiązania technologicznego. Kiedy po raz pierwszy tworzysz plan projektu, najlepiej domyślasz się, jak wszystko pójdzie i co będzie ważne dla powodzenia projektu; jednak po zabraniu się do pracy projekt szybko ewoluuje od pierwotnej formy. Niektóre zadania, które uważałeś za łatwe, okazują się zajmować znacznie więcej czasu i energii; niektóre zadania, które prawdopodobnie pochłaniają mnóstwo zasobów, są wykonywane w mgnieniu oka lub okazują się całkowicie niepotrzebne. To naturalny proces; nie pozwól, aby złamał twój krok.

Rozpraw się z każdym przeciąganiem stóp natychmiast!

Środowisko - do licha, sama budowa - to ogromny amalgamat ruchomych części, z których wiele ma kluczowe znaczenie dla funkcjonowania całego programu. Dlatego absolutnie, pozytywnie, nie możesz niczego brać za pewnik, jeśli chodzi o współpracę ze źródeł zewnętrznych - niezależnie od tego, czy jest to zespół w Twojej firmie, konsultant, dostawca, czy ktoś pomiędzy. Jeśli ktoś ma to, czego potrzebujesz, aby Twój projekt odniósł sukces, lepiej pozostań z nim, dopóki nie dostarczy. Źródłem numer jeden opóźnień w inicjatywach BI jest pozyskanie współpracy od właścicieli źródeł danych, które będą zasilać Twój system. Środowiska BI zazwyczaj pobierają dane operacyjne z wielu różnych źródeł w całej organizacji. Uzyskanie przepływu tych danych po raz pierwszy może być poważnym problemem. W końcu to Ty czerpiesz natychmiastowe korzyści z przenoszenia danych - dzięki temu Twoja aplikacja (y) działa! - więc ludzie, którzy są właścicielami danych, nie zawsze mają ogromną motywację do współpracy z Tobą. Jeśli wyczuwasz jakiekolwiek wahanie dotyczące dostępu do danych, stąp ostrożnie, ale zdecydowanie. W pierwszym niedotrzymanym terminie natychmiast udaj się do źródła i upewnij się, że wszystkie luźne końce są zawiązane. Upewnij się, że nie ma obaw dotyczących bezpieczeństwa ani innych ukrytych powodów, dla których przepływ się nie rozpoczął. Czy coś się zmieniło od czasu, gdy po raz pierwszy negocjowałeś transfer plików? Czy zmienił się krajobraz polityczny? Czy zmieniło się kierownictwo? Nigdy nie możesz być pewien dokładnej struktury i jakości danych, dopóki ich nie zobaczysz. Oczywiście, możesz zaprojektować proces ETL w oparciu o zestaw specyfikacji, ale jeśli coś jest pewne na świecie, to to, że przechowywanie danych może być niepewne. Dla otwieraczy różne grupy mają różne definicje i różne standardy. Po prostu nie będziesz wiedział, z czym masz do czynienia, dopóki po raz pierwszy nie zdobędziesz tych plików.

Udowodnij tę koncepcję!

Nie ma nic gorszego niż podniesienie kurtyny w wielki dzień i stwierdzenie, że twoja obsada i ekipa potrzebują jeszcze jednej próby generalnej. Weryfikacja koncepcji (POC) to świetny sposób na modelowanie trudności związanych z wdrożeniem na pełną skalę, aby usunąć niejasności i przygotować zespół na to, co nas czeka. POC to podzbiór kompletnego rozwiązania, o którym myślisz. Zakres zawężony jest do kilku najważniejszych elementów i funkcji. W swej istocie POC Business Intelligence zwykle składa się z ograniczonego rozwiązania do zbierania danych w połączeniu z uproszczoną wersją jednego lub więcej narzędzi użytkownika. W większości przypadków POC odkłada na bok szczegółową pracę polegającą na dostarczeniu interfejsów użytkownika na samym początku i może nawet używać bardziej podstawowych narzędzi i protokołów, niż byłoby to użyte w pełnym rozwiązaniu. Interesuje Cię tutaj, czy to działa. System POC nie ma być rdzeniem tego, co stanie się pełnym systemem. Zwykle składa się z kawałków, które można szybko ze sobą połączyć, aby zademonstrować, że podstawowe założenia inicjatywy BI są słuszne - na przykład, że jest możliwość pobierania danych o transakcjach sprzedaży z oddziałów regionalnych, możliwość zbudowania procesu ETL w celu normalizacji informacji, ich magazynowania i wykorzystania w aplikacjach użytkowników końcowych w celu uzyskania wglądu biznesowego. Celem tutaj nie jest zaznaczenie każdego celu systemu na liście, ale po prostu przepracowanie wystarczającej liczby głównych przeszkód, aby ułatwić podjęcie decyzji.

Diabeł tkwi w szczegółach

A może ukrywa się w tym pudełku, o którym zawsze starasz się myśleć poza nim. Oczywiście, chwała polega na znalezieniu oszałamiających spostrzeżeń biznesowych lub wprowadzeniu renderów graficznych, ale nie zapominaj o codziennych elementach, które sprawiają, że Twój system jest naprawdę wartościowy dla Twojego przedsiębiorstwa. Twoje pierwsze wdrożenie powinno być łatwe i szybkie. Powinien być dostępny, intuicyjny i niezawodny. Kiedy użytkownicy mieszają system BI z innymi aplikacjami, z których już korzystają, powinno to odbywać się bezproblemowo. Te cechy są podstawą dobrego całościowego rozwiązania. Niezależnie więc od zakresu początkowego wdrożenia, system powinien być nasycony jakością; powinien dobrze wykonywać swoją pracę. Jeśli uważasz, że nie będziesz miał na to czasu, rozważ zmniejszenie zakresu projektu. Rozwiązanie Business Intelligence to często mozaika różnych aplikacji i palimpsest (zapamiętaj to słowo dla następnej gry w Scrabble) rozwiązań IT zbudowanych w minionych epokach. Niektóre komponenty będą działać lepiej niż inne. Niektóre kawałki zostaną uwolnione, zanim zostaną w pełni upieczone. Poinformuj o tych niedociągnięciach - nawet drobnych - społeczności użytkowników i interesariuszom, zanim pojawią się one w raporcie o błędach lub wiadomości e-mail od zirytowanego analityka. Ci ludzie są bardziej skłonni do cierpliwości ze słabością tu i tam, jeśli wiedzą, że zdajesz sobie sprawę z potrzeby ulepszeń.

Mamy żywego

W przypadku aplikacji BI przepływ danych powoduje nawadnianie aplikacji, umożliwiając ich ożywienie. Podczas tworzenia frontendu prawdopodobnie użyjesz fikcyjnych danych, aby upewnić się, że oprogramowanie działa poprawnie. Ale chociaż interfejs może się zmienić, zarówno pod względem wyglądu, jak i funkcjonalności, przepływ danych musi być solidny. Jeśli to nie zadziała, nic nie zadziała. Ze względu na jego znaczenie, dobrym pomysłem jest jak najszybsze przejście od makietowych danych do rzeczywistych. "Uruchomienie na żywo" nie dotyczy tego, czy aplikacje skierowane do użytkowników działają (po tych wszystkich testach byłoby lepiej); to naprawdę oznacza uzyskanie rzeczywistych danych operacyjnych ze wszystkich oddalonych systemów zasilających. Pełne uruchomienie źródeł danych to ogromny kamień milowy; urządzić przyjęcie i świętować. Zawsze musisz być ostrożny w projekcie, w którym modyfikujesz dane źródłowe. Na szczęście systemy BI zwykle odczytują dane tylko ze źródeł zewnętrznych; oznacza to, że ryzyko uszkodzenia danych źródłowych jest niewielkie. To dobra wiadomość dla Twojego zespołu projektowego, ponieważ oznacza to, że powinieneś być w stanie rozpocząć dostarczanie danych niezależnie od tego, czy Twój system działa już poprawnie. Wdrożenie na żywo oznacza również otrzymywanie tych danych operacyjnych w czasie, dla którego zaprojektowałeś system BI - w tym samym formacie, którego oczekujesz, gdy aplikacje będą działać. Jasne, zaczniesz od dostarczania go w partiach podczas testowania. Ale im szybciej przerzucisz się na pełną prędkość, tym łatwiej będziesz mógł ocenić, czy Twój zestaw narzędzi jest gotowy do zaciągnięcia. Pracuj od tyłu do przodu; jak najwcześniej włącz źródła danych, a następnie udoskonal interfejs. Gdy podstawowe komponenty aplikacji obsługujące dane będą już funkcjonalne, możesz włączyć kurek danych dla końcowych etapów rozwoju. To zasymuluje sposób, w jaki system będzie faktycznie działać po uruchomieniu, umożliwiając programistom ukończenie pełnego systemu przy użyciu rzeczywistych warunków danych. Jeśli będziesz zmuszony czekać do samego końca z włączeniem pełnego przepływu danych, Twoja aplikacja może zachowywać się w zaskakujący sposób.
Powrót

12.10.2021

Dziesięć sekretów zdrowego środowiska BI

TLC danych

Kompleksowe środowisko analizy biznesowej często obejmuje dane, które przechodzą przez rozległy i mylący łańcuch wirtualnej kontroli i transformacji. Zwróć szczególną uwagę na każde ogniwo w tym łańcuchu. Nigdy nie wiadomo, kiedy w innym miejscu w firmie może nastąpić zmiana, która sprawi, że wcześniej wiarygodny strumień informacji będzie zupełnie nierozpoznawalny. Dane są siłą napędową BI. Gdy zostanie zgubiony, transponowany lub przekształcony do punktu, w którym nie odzwierciedla już odpowiednio rzeczywistości operacyjnej firmy, system nie może już dostarczać cennych informacji. Pomyśl o danych w następujący sposób:

•  Jakość danych: czy dane są użyteczne i kompletne? Wyobraź sobie, że próbujesz przeprowadzić analizę geograficzną klientów i okazuje się, że w dużej części rekordów klientów brakuje kodów pocztowych. W podobnej sytuacji przedstawiciele obsługi klienta w Twojej firmie może wprowadzać numery telefonów do systemu CRM w różnych formatach - niektóre z nawiasami, niektóre z myślnikami, a niektóre tylko cyfry. Częścią troski o Twoje dane jest przygotowanie się do ich oczyszczenia i upewnienia się, że są one w jednolitym, użytecznym formacie.
•  Integralność danych: czy informacje są prawidłowe? Czy reprezentuje to, w co wszyscy wierzą, że robi? Na przykład jakość danych spada, gdy jedna jednostka firmy mierzy rzeczy w jeden sposób, a inna jednostka mierzy je w inny sposób. Dwa działy mogą przesyłać Ci dane o sprzedaży, ale jeśli jeden przesyła Ci podsumowanie dzienne, a drugi wysyła Ci masę pojedynczych transakcji, lepiej przygotuj się na wykonanie pewnych prac na tych danych, zanim je połączysz.

Osiąganie celów budżetowych

Jedyną rzeczą gorszą niż wydawanie dużych pieniędzy na inicjatywę BI jest wydawanie o wiele więcej niż obiecałeś sponsorom wykonawczym projektu, których wydasz. Znaczące nakłady pieniężne nie ograniczają się do początku projektu; będą też koszty utrzymania systemów BI. Musisz więc bardzo uważać na ich szacowanie na początku. Dane mogą być siłą napędową BI, ale pieniądze są paliwem napędzającym projekt. A Twoja zdolność do zabezpieczenia finansowania w przyszłości będzie w dużej mierze zależeć od Twojej zdolności do bycia odpowiedzialnym zarządcą zielonych pieniędzy firmy za pierwszym razem i po włączeniu systemu. Produkt końcowy może różnić się od oryginalnego projektu. Tak więc koszty utrzymania mogą się znacznie różnić od pierwotnie szacowanych. Najlepszym zabezpieczeniem przed rozdmuchanymi budżetami jest kompleksowy i dokładny proces ustalania zakresu. Musisz zrozumieć wszystkie główne komponenty systemu (to znaczy pozycje budżetowe), zanim obiecasz grubiańcom, że będzie to kosztować określoną kwotę. Rozważ następujące możliwe domeny w fazie zakresu:

•  Liczba i charakter funkcji wykonywanych przez system. Wdrożyłeś więcej funkcji niż planowałeś?
•  Liczba zaangażowanych dostawców oprogramowania innych firm. Jeśli jest to więcej, niż się spodziewałeś, możesz mieć inne struktury płatności licencyjnych niż pierwotnie planowałeś. A jeśli sam zbudowałeś jakieś narzędzia, nie myśl, że to wszystko jest bezpłatne, jeśli chodzi o konserwację. Trzeba będzie wziąć pod uwagę czas Twojego zespołu, aby Twoje domowe narzędzia pracowały.
•  Liczba różnych źródeł danych oraz ilość danych do przetworzenia w danym okresie. Czy masz do czynienia z pierwotnie oszacowaną ilością danych? Jeśli jest ich więcej, możesz być na haczyku, aby uzyskać więcej pamięci masowej, łączności i opłat za bezpieczeństwo.

Twój budżet może być tylko tak dokładny, jak początkowe szacunki zakresu. Czasami, oprócz brakujących celów budżetowych, otrzymujesz zbyt częstą niespodziankę budżetową. Jeśli w projekcie grozi katastrofa, poważnie zastanów się nad wysłaniem czerwonej flagi z dużym wyprzedzeniem. Hej, zdarza się to czasami: dostawcy nie dostarczają, jeden aspekt środowiska okazuje się o wiele bardziej skomplikowany, niż się spodziewałeś, lub rozwiązanie - z wielu powodów - po prostu nie pasuje tak, jak oczekiwałeś. Możesz kupić sobie trochę czasu, opóźniając złe wieści, ale to źle odbija się na twoim podejściu do projektu; wskazuje - słusznie lub nie - na zasadniczy brak troski o inwestycje firmy.

Trafianie do celów harmonogramu

Harmonogram projektu to kolejne ograniczenie, którym należy zarządzać ostrożnie. Ponieważ projekty BI są często układanką wydarzeń i zasobów, jeśli przegapisz jeden termin, efekt może kaskadowo rozprzestrzenić się na inne kamienie milowe i trwale wyrzucić Twój projekt z torów. Osiągnij cele harmonogramu dotyczące ulepszeń i ulepszeń. Po uruchomieniu środowiska BI i ewangelizacji jego zastosowań przekonasz się, że ludzie zaczną na Ciebie liczyć. Ale to nie tylko kalendarz oprogramowania, którego powinieneś przestrzegać. Zapewnij odpowiednie miejsce w swoim planerze na szkolenia, przeglądy, spotkania zarządcze i proste zadania konserwacyjne.

Wypłukać i powtórzyć

Wstaw tutaj jeden lub dwa z tych standardowych frazesów: nie wymyślaj na nowo koła, ponieważ budujesz lepszą pułapkę na myszy. Jeśli masz proces lub technologię, która działała znakomicie za pierwszym razem, użyj jej ponownie. Prawdopodobnie wiele się nauczyłeś od początkowej implementacji na dowolny zakres tematów. Może jest to tak proste, jak sposób ustrukturyzowania zespołu projektowego lub osoba, która prowadziła szkolenie pracowników. A może to jakiś duży aspekt działania tej technologii. Niezależnie od zakresu historii sukcesu z pierwszej rundy, spróbuj przeżyć ją na nowo, dbając o środowisko. W świecie BI nie ma punktów za oryginalność, tylko za sukces. Więc idź z tym, co wiesz, że działa dobrze… dopóki nie będzie już działać dobrze. Wtedy i tylko wtedy powinieneś znaleźć alternatywny plan.

Opłucz i nie powtarzaj

Bez wątpienia zebrałeś kilka stłuczeń i siniaków po drodze podczas tworzenia środowiska BI. Przy odrobinie szczęścia nie ma trwałych uszkodzeń. Ale możesz przekształcić wszystkie te błędy w cenne lekcje, które pomogą udoskonalić Twój proces w przyszłości. W końcu życie służy do nauki, prawda? Business Intelligence zapewni wgląd w krytyczne procesy i funkcje w Twojej organizacji, a rezultatem netto będzie zmiana sposobu działania firmy. Tak samo jest z samym zespołem wdrożeniowym BI. Doświadczenie w budowaniu systemu dostarczy wielu cennych lekcji, które można wykorzystać w kolejnej rundzie. Kluczem do uczenia się na błędach jest posiadanie procesu śledzenia i rozpowszechnianie lekcji. Może to tak proste, jak robienie regularnych przeglądów i sekcji zwłok, a może potrzebujesz bardziej formalnego systemu śledzenia. Bez względu na to, co zdecydujesz, po prostu upewnij się, że wykraczasz poza identyfikowanie błędów i pomyłek w tworzeniu rozwiązań. "Wyciągnięte wnioski" niewiele się liczą, chyba że następnym razem odpowiednio dostosujesz swój proces.

Utrzymuj wiedzę zespołu

Powtarzanie tego, co działa i unikanie błędów z przeszłości, jest częścią ogólnego wysiłku w zakresie zachowania wiedzy w Twoim zespole. Aby analiza biznesowa stała się częścią długoterminowego ruchu w firmie, im więcej wiedzy możesz zachować w zespole projektowym, tym lepiej możesz służyć organizacji. Oto niektóre ze sposobów przechwytywania i utrzymywania kontinuum wiedzy zespołu:

•  Zapisz, co robisz. Twórz kompleksową dokumentację procesu, w tym opisy i diagramy przepływu dla każdego aspektu systemu, w tym wszystkich źródeł danych, całego procesu ETL, repozytorium danych i wszystkich aplikacji użytkownika.
•  Udokumentuj swój kod. Niech programiści skomentują ich kod, aby jeśli jeden programista odszedł, inni mogli zrozumieć pracę, którą pozostawił.
•  Opracuj i egzekwuj system mentoringu. Dopilnuj, aby młodsi członkowie zespołu pracowali ręka w rękę ze starymi solami, aby wszystkie sekrety zostały przekazane.

Pamiętaj, o czym zapomniałeś za pierwszym razem

Nieuniknione jest, że początkowe wdrożenie obejmie tylko podzbiór wszystkich tych funkcji i elementów, które faktycznie chciałeś wprowadzić. Ponadto pojawią się sugestie i potrzeby społeczności użytkowników i grup interesariuszy; mogą to być nowe funkcje, a może poprawki w interfejsie użytkownika lub inny aspekt środowiska BI. To, że nie możesz zrobić ich wszystkich naraz, nie oznacza, że nie powinieneś próbować robić ich wszystkich w końcu. Śledź te elementy, które zostały wyciśnięte z początkowej implementacji, aby można dodać podczas procesu konserwacji i aktualizacji. Daje użytkownikom to, czego chcą i potrzebują w bardzo prosty sposób, i pomaga zespołowi BI przedstawiać się w pozytywnym świetle, wyglądając na responsywne i zorganizowane.

Regularne aktualizacje

Środowisko Business Intelligence jest jak niemowlę: nie może działać bez nadzoru przez bardzo długi czas, nie zaczynając śmiesznie pachnieć. Jeśli pozwolisz swojemu systemowi działać zbyt długo bez monitorowania i aktualizacji jego komponentów, wymknie się spod kontroli. Twoi technicy jako pierwsi powiedzą ci, że systemy w środowisku BI wymagają regularnych poprawek, uaktualnień, łat i wszelkiego rodzaju ogólnej uwagi, aby utrzymać wszystko w dobrym stanie. Uwierz im; wiedzą, o czym mówią. To normalne, że producenci oprogramowania wydają uaktualnienia swoich aplikacji; twórcy aplikacji dla użytkowników końcowych w środowisku BI nie są wyjątkiem. Uaktualnienia i poprawki rozwiązują drobne problemy, nieefektywność i problemy z bezpieczeństwem, z których niektóre mogą mieć bezpośredni wpływ na Ciebie, a niektóre mogą nie. Te same regularne poprawki istnieją dla całej infrastruktury pomocniczej, takiej jak narzędzia baz danych, aplikacje ETL i inne oprogramowanie pośredniczące w systemie. Oprócz reagowania na aktualizacje od dostawców mogą wystąpić zmiany w Twojej firmie (na przykład na poziomie danych źródłowych), które wymagają uwagi zespołu technicznego. Przy tak wielu ruchomych częściach dobre środowisko BI planuje czas i zasoby na prostą czynność utrzymania systemów.

Pozostań w kontakcie i na bieżąco

Monitorowanie zachowania pakietu aplikacji pomoże zidentyfikować problematyczne góry, gdy wciąż są tylko kretowiskami. Aby utrzymać zdrowe środowisko, musisz zainwestować w dobre aplikacje diagnostyczne i opracować proces monitorowania stanu aplikacji i szybkiego reagowania na pojawiające się problemy. Oznacza to więcej niż tylko śledzenie, czy oprogramowanie jest uruchomione. Musisz monitorować wydajność - jak dobrze działa - aby naprawdę zmierzyć kondycję systemu. Statystyki użytkowania informują o tym, czy docelowa społeczność użytkowników przyjmuje programy BI. W swoich badaniach powinieneś mieć podstawowe pojęcie o tym, jak mogą wyglądać statystyki użytkowania. Porównaj je na przestrzeni czasu i podążaj za trendami.

Komunikowanie zmian

Twój system odniesie sukces tylko wtedy, gdy ludzie faktycznie używają go do osiągania celów biznesowych oraz wyszukiwania i lokalizowania informacji biznesowych. Mogą to zrobić tylko wtedy, gdy wiedzą, jakie funkcje są dostępne i jak z nich korzystać. W ramach praktyki Twój zespół powinien informować użytkowników o wprowadzeniu aktualizacji i zmian, które mogą wpłynąć na sposób, w jaki korzystają z systemu. Czy dodałeś serwer, który skróci czas odpowiedzi na zapytania o połowę? Wyślij notatkę do społeczności użytkowników i poinformuj ich o aktualizacji. Jeśli dostępna jest nowa aplikacja lub funkcja, będziesz chciał, aby ludzie używali jej tak szybko, jak to możliwe. Komunikacja ogólnie pozwala organizacji wiedzieć, że Twój zespół jest aktywny i że system ewoluuje, aby sprostać ich potrzebom. Pobudza również informacje zwrotne od firmy, które nigdy nie mogą zaszkodzić. Nie tylko rozmawiaj ze swoją bazą użytkowników; Twój zasięg komunikacji powinien rozciągać się na całą organizację. Kompleksowy plan komunikacji oznacza informowanie zespołu wykonawczego o najnowszych ulepszeniach systemu. Im szerszy zasięg komunikacji, tym lepiej.

Zostań w pociągu

Kupując licencje na oprogramowanie, zwykle są one dostarczane z pakietem szkoleniowym lub określoną liczbą zajęć, w których mogą uczestniczyć twoi programiści i inne zasoby, aby dowiedzieć się, jak najlepiej zainstalować i korzystać z oprogramowania. Ale to, co znajduje się w pakiecie, rzadko wystarcza na szkolenie na poziomie wiedzy, którego naprawdę potrzebujesz. Dostawcy rozwiązań BI zazwyczaj zaniżają liczbę szkoleń wymaganych do skutecznego korzystania z ich produktów. Chcą, abyś uwierzył, że po prostu podłączasz nową aplikację, przełączasz przełącznik i patrzysz, jak działa. Ale to nigdy nie działa w ten sposób; musisz utrzymywać odpowiedni poziom wiedzy w swoim zespole, aby jak najlepiej wykorzystać zakupione i zbudowane systemy. Uczyń ciągłe szkolenie stałym elementem procesu konserwacji, aby utrzymać doświadczenie i wiedzę zespołu na zdrowym poziomie. Dodatkową korzyścią jest rozwój zawodowy, który sprawia, że zespół BI jest zadowolony i zmniejsza prawdopodobieństwo wyjazdu na bardziej zielone pastwiska.

Konserwacja jako proces

W typowym wdrożeniu aplikacji faza utrzymania rozpoczyna się po pomyślnym uruchomieniu oprogramowania. Niestety środowisko BI różni się od tradycyjnej implementacji IT z wielu powodów. Jasne, istnieją standardowe aktualizacje oprogramowania i strojenie, które muszą odbywać się regularnie. Nowe osoby muszą zostać przeszkolone w zakresie obsługi i administrowania systemem. Jednak większa różnica polega na tym, że sama natura projektów analizy biznesowej wymaga, aby system nie był tak naprawdę stabilny. W rzeczywistości ma ewoluować z czasem. Twój zespół powinien być skonfigurowany i przygotowany do radzenia sobie z ewoluującym systemem. BI dotyczy transformacji. Zastanów się, czym tak naprawdę jest business intelligence oznacza dla firmy: środowisko BI, po zainstalowaniu i aktywacji, powinno zacząć dostarczać użytkownikom informacji o firmie. Te spostrzeżenia będą (powoli, ale pewnie) przedostać się do procesu planowania strategicznego. Będą wywierać presję na te pierwotne procesy, aby się zmieniły, co z kolei doprowadzi do nowych i rozszerzonych potrzeb systemu BI. Na przykład, jeśli społeczność użytkowników nagle uzyska dostęp do szczegółowych danych dotyczących rentowności klientów, może zidentyfikować lepsze procesy biznesowe dla (powiedzmy) strukturyzacji kontraktów. Ale jest też prawdopodobne, że zidentyfikują nowe wymiary informacji o klientach i zyskach, które można wykorzystać do odkrycia jeszcze większej liczby informacji biznesowych. W tym przypadku BI nie jest jedynie katalizatorem zmian biznesowych; system Business Intelligence faktycznie zaspokaja zapotrzebowanie na własną ewolucję. Gdy użytkownicy uzyskają dostęp do informacji BI, zasmakują w mocy informacji i będą wymagać większej ilości danych i większej liczby wymiarów tych danych. To cykl zmian, który tak naprawdę nigdy się nie kończy. Utrzymanie zdrowego środowiska BI oznacza gotowość do jak najlepszego reagowania na zmiany wprowadzane przez BI w biznesie. Nie zawsze łatwo jest przewidzieć te zmiany, ale jeśli zespół i filozofia utrzymania są odpowiednio ustrukturyzowane, przynajmniej możliwe jest odpowiednie zareagowanie.
Powrót

13.10.2021

Dziesięć oznak, że Twoje środowisko BI jest zagrożone

Arkusze kalkulacyjne po prostu nie umrą

Jeśli raport zostanie wygenerowany automatycznie, ale nikt go nie widzi, czy naprawdę istnieje? Twoja inicjatywa BI mogła przybrać dokładnie taki kształt, jak określiłeś; mógłby być doskonały w swojej koncepcji i realizacji. Ale jeśli ludzie go nie używają, wszystko to liczy się dla nada. Jednym z najłatwiejszych sposobów sprawdzenia, czy ludzie czerpią najwięcej z Twojego systemu BI, jest monitorowanie przejścia między starymi narzędziami do raportowania i analizy a nowym podejściem BI do tego samego problemu. Jeśli ludzie nadal pojawiają się na spotkaniach z tymi samymi starymi arkuszami kalkulacyjnymi i tymi samymi starymi raportami, których używali przed wdrożeniem BI, może to oznaczać, że nadal masz sposoby na uczynienie swojego produktu bardziej użytecznym i przyjaznym dla użytkownika. Nie bierz tego do siebie. Zapytaj, dlaczego ludzie nie migrują, i wysłuchaj powodów. Możliwe, że nie zostali odpowiednio przeszkoleni lub czasami menedżer nie zlecił zmiany. Te przeszkody można łatwo pokonać. Ale jeśli prawda jest taka, że arkusz kalkulacyjny jest po prostu lepszy, być może będziesz musiał ponownie odwiedzić swój projekt i znaleźć miejsce, w którym zboczyłeś z kursu.

Każdy prosi o pomoc

Zaraz po pierwszym wdrożeniu powinieneś otrzymać potok próśb o pomoc w korzystaniu z aplikacji. Ale po początkowym przejściu ludzie powinni zacząć przyzwyczajać się do nowych systemów; telefony do helpdesku powinny zacząć się kończyć. Oczywiście istnieje duża różnica w rodzaju połączeń, które otrzymujesz, więc zawsze powinieneś monitorować napotykane problemy. Jeśli systemy się psują lub jeśli czasy odpowiedzi są nie do przyjęcia, to są problemy, które musisz naprawić samodzielnie. Ale jeśli wszystko działa zgodnie z oczekiwaniami, rozmowy będą dotyczyć pytań o to, jak coś zrobić lub o to, gdzie można teraz znaleźć funkcję. Pierwsze wrażenia mogą być cenne. Śledź skargi dotyczące użyteczności od użytkowników końcowych i uwzględniaj poprawki głównych błędów w kolejnych wydaniach. Nikt nie prosi o pomoc . Jak zażartował Oscar Wilde, "jedyną rzeczą gorszą od tego, o czym mówi się, jest nierozmawianie". I tak jest z Twoim środowiskiem BI. Jedyną gorszą rzeczą niż otrzymywanie wielu telefonów do pomocy technicznej jest prawie brak telefonów do pomocy technicznej. Jeśli uruchamiasz swój program i słyszysz tylko świerszcze w swoim banku telefonicznym helpdesku, wejdź do społeczności użytkowników i dowiedz się, co się dzieje. Być może stworzyłeś szczęśliwą aplikację, która daje milion na milion, bez żadnych wad, ale najprawdopodobniej działa bardziej złowroga siła. Pierwsze pytanie, które należy zadać, to czy ludzie wiedzą o nowym środowisku BI? A jeśli tak, to czy go używają? Jeśli go używają i nie napotykają żadnych problemów, czy korzystają ze wszystkich jego funkcji i czy wykorzystują każdą funkcję w pełni? Z drugiej strony, jeśli nie otrzymujesz zbyt wielu informacji zwrotnych, być może użytkownicy nie są pewni, gdzie szukać pomocy.

Water-Cooler narzeka na użyteczność

Najlepsze oprogramowanie na świecie istnieje na skrzyżowaniu ulic Przydatne i Użyteczne. Jeśli znajdziesz jedno bez drugiego, nie jesteś nigdzie. Te dwie cechy są równie ważne, a jednak o wiele więcej wysiłku wkłada się w pierwszą cechę w porównaniu z drugą. Najczęściej programiści i architekci skupiają całą swoją energię na tym, aby produkty były funkcjonalne, nie martwiąc się o to, czy użytkownik może z łatwością wykonać to, czego potrzebuje. W przypadku tych problemów niekoniecznie otrzymasz telefony do działu pomocy. Zamanifestują się w przekomarzaniu się przy dystrybutorze wody, na pikniku firmowym i na spotkaniach zespołów niskiego szczebla. Nigdy nie lekceważ roli użyteczności w oprogramowaniu. Użyteczność powinna być priorytetem podczas procesu projektowania. I nie mówimy tylko o interfejsach użytkownika. Oczywiście ważne jest, aby kolejność tabulatorów była prawidłowa, aby przyciski były wystarczająco duże, a czcionka była czytelna. Ale proces musi być również użyteczny. Świetny interfejs jest bezwartościowy, jeśli obsługa bazy danych w obie strony zajmuje 5 minut. Użyteczność obejmuje wiele obszarów; i musi o tym pamiętać podczas projektowania każdego elementu środowiska BI.

Zespół starego dobrego dnia

Krewnym narzekania na wodę, która narzeka na użyteczność, jest rozmowa, którą od czasu do czasu słyszysz o tym, jak rzeczy były kiedyś w firmie. Może dotyczy to dyskomfortu związanego z nowym procesem, a może jest to konkretna aplikacja, o której czule wspominamy. Ale jeśli ludzie o tym mówią, oznacza to, że obecny pakiet BI nie wykonuje swojej pracy tak, jak powinien. Oddziel dyskusję o przejściu od konstruktywnej opinii na temat jakości i użyteczności środowiska BI. Wprowadzenie nowej aplikacji powoduje natychmiastowy syndrom starych dobrych czasów. Wskazanie problemu pojawia się, gdy ten syndrom wydaje się nigdy nie znikać.

Numery użycia maleją z czasem

Twoje statystyki użytkowania powinny stale rosnąć, w miarę jak coraz więcej osób zwraca uwagę na użyteczność pakietu aplikacji BI. Nie martw się o sporadyczne spadki liczby użytkowania; będzie nieuniknione fluktuacje, gdy zespoły użytkowników nabierają tempa. Ale jeśli zauważysz stały spadek statystyk użytkowania, uważaj na pewne podstawowe problemy w swoim środowisku:

•  Najbardziej oczywistym źródłem problemu jest to, że ludzie nie czują się jeszcze komfortowo z nowym narzędziem do raportowania lub analizy. Trudno to zdiagnozować, ponieważ te skargi często pozostają ukryte. Ale łatwo to naprawić; daj jakieś ulepszone zajęcia szkoleniowe lub poproś swojego kierownika, sponsorzy przypominają zespołowi o nowych standardach.
•  Może Twoja aplikacja po prostu nie zapewnia wartości społeczności użytkowników. Spostrzeżenia, które obiecałeś, nie są tworzone.

Ten problem jest łatwiejszy do zdiagnozowania, ale trudniejszy do naprawienia. Musisz ponownie skontaktować się ze wszystkimi zainteresowanymi stronami i ocenić, gdzie są niedociągnięcia, a następnie dokonać trudnych wyborów, czy poprawić środowisko, czy (w najgorszym przypadku) całkowicie odłączyć wtyczkę.

Narzędzia BI nie są częścią dyskusji na temat strategii

W zdrowym środowisku BI, zwłaszcza jeśli chodzi o IT, narzędzia do gromadzenia i agregacji danych powinny stać się częścią strategicznego krajobrazu firmy. Business Intelligence to zarówno stała filozofia zarządzania, jak i zestaw narzędzi i procesów. BI, jeśli zostanie zrobione dobrze, powinno spowodować zmiany w sposobie, w jaki robi się rzeczy w Twojej firmie. Jeśli odniesie sukces w dostarczaniu wglądu w marże zysku każdej linii produktów, korporacyjne bigwigi będą chciały przenieść skuteczne podejście do innych obszarów działalności, w których gromadzą się duże ilości danych. Jeśli okaże się, że tak się nie dzieje, może być problem z tym, co dostarczyłeś. Podejście do strategii zorientowane na BI rozprzestrzeni się tylko wtedy, gdy Twoje istniejące środowisko będzie skuteczne. To samo dotyczy bez względu na wielkość środowiska BI. Jeśli masz wdrożenie niskopoziomowe, które obsługuje tylko jeden lub dwa działy, proces planowania dla tego ograniczonego obszaru powinien obejmować BI. Idąc w górę drabiny, jeśli BI jest używane w jednym funkcjonalnym silosie firmy, BI powinno zacząć wkradać się do długofalowej dyskusji na temat strategii biznesowej dla tego obszaru.

Sponsorzy wykonawczy tracą entuzjazm

W biznesie nic nie pozostaje takie samo. Kiedy czytasz to zdanie, prawdopodobnie jakiś czynnik zmienił się dramatycznie, nawet o tym nie wiedząc. Więc uważaj na swój krok na arenie BI; Wielki Kahuna, który dzisiaj broni twojego projektu, jutro może go oczernić. Nie bierz wsparcia sponsorów wykonawczych za pewnik. Ich sytuacja może się zmienić lub okoliczności związane z biznesem mogą łatwo wyłonić się spod Ciebie. Bądź w ścisłym kontakcie z potrzebami sponsora; reagować tak szybko, jak to możliwe, na jego obawy. Jednym z Twoich priorytetów jest zadbanie o dobry wygląd sponsorów. Może się wydawać, że to twój projekt, ale widnieje na nim ich nazwa. Musisz więc stworzyć działający produkt w sposób, który odpowiada życzeniom twojego sponsora wykonawczego.

Sponsorzy wykonawczy tracą pracę

Zawsze istnieje możliwość, że twoi mistrzowie z narożnych biur zmienią pracę lub odejdą z firmy. To pozostawia wszelkie projekty dla zwierząt, które pozostawili, zagrożone; często zastępca dyrektora zaczyna od oceny swojego portfolio pod kątem słabych ogniw. Nawet jeśli projekt jest solidny, a użyteczność biznesowa wysoka, zawsze jest możliwe, że nowy dyrektor tego nie zobaczy ani nie zrozumie. Przygotuj się więc na wcześniejsze zgłoszenie sprawy. Nie czekaj, aż on lub ona się z Tobą skontaktuje; wykonaj uderzenie wyprzedzające, zanim jakakolwiek negatywność zdąży się zakorzenić. Promocja sprzedaży, którą przedstawiłeś pierwotnemu sponsorowi, okazała się sukcesem, więc dlaczego nie dać występu na bis? Po prostu upewnij się, że wiesz, jakie czynniki miały wpływ na odejście twojego pierwotnego sponsora; jeśli mieli coś wspólnego z twoim projektem lub ogólnie z BI, bądź przygotowany, by zająć się nimi bezpośrednio. Świetnym sposobem na to jest zademonstrowanie przykładów swoich wczesnych sukcesów. A jeśli są jacyś ludzie na poziomie menedżera, którzy skorzystali z twojego projektu, poproś ich również o dobre słowo. Z politycznego punktu widzenia ważne jest, aby zdawać sobie sprawę z okoliczności towarzyszących odejściu dobroczyńcy projektu. Jeśli ten dyrektor odszedł pod chmurą kontrowersji, możesz zmienić swoje podejście w sposób, który zminimalizuje twoje powiązanie z poprzednim reżimem. Jeśli twoja prezentacja się nie powiedzie, a nowy dyrektor nie połknie przynęty, poszukaj mistrza gdzie indziej. Być może postęp, który poczyniłeś, zmienił zdanie niektórych w innych obszarach firmy lub w innych narożnych biurach.

Odporność na ulepszenia i rozbudowę

Pieniądze mówią, jeśli chodzi o projekty IT. Projekty, które cieszą się wiarą firmy i zaufaniem kadry zarządzającej, pojawiają się w przyszłorocznym budżecie. Po początkowym wdrożeniu prawdopodobnie masz wiele planów dotyczących aktualizacji i funkcji rozbudowy. Możesz chcieć wykorzystać obecne aplikacje lub dodać zupełnie nowe - powiedzmy, zwiększyć pojemność bazy danych lub wdrożyć najnowocześniejsze protokoły. Ale jeśli masz problemy z zatwierdzeniem budżetu na takie przedsięwzięcia, prawdopodobnie powinieneś dokładnie przyjrzeć się środowisku, w którym obecnie działasz. Czy robi to, co obiecałeś? Przed ponownym pójściem do studni będziesz musiał ugruntować swoje doświadczenie - a jeśli nie jest to możliwe dzięki technologii i narzędziom, które masz teraz, lepiej znajdź sposób, aby uzasadnić przeznaczenie większej ilości pieniędzy na projekt.
Powrót