Przymiarki do analizy

Druga strategia (iteracyjna) zakłada, że na początek jest wybierany jeden obszar biznesowy (może być kilka, ale nie wszystkie), dla którego zostały określone istotne do podejmowania decyzji potrzeby analityczne. Najlepiej wybrać taki obszar, który jest atrakcyjny dla użytkowników, a jednocześnie jest możliwie łatwy do wykonania. Zwykle są to sprzedaż, inwestycje lub aktywność klientów. Dzięki temu, po szybkim dostarczeniu działającego rozwiązania, zyskuje się przychylność odbiorców (poparcie dla kontynuacji projektu), a jednocześnie nabiera cennych doświadczeń, przydatnych przy realizacji dalszych etapów budowy systemu analitycznego. Niewątpliwe zalety takiego podejścia to szybkie efekty, rozłożenie nakładów w czasie, niskie początkowe nakłady, relatywnie niewielki koszt porażki, która w tym przypadku jest zresztą znacznie mniej prawdopodobna. Większość udanych projektów prowadzono właśnie w ten sposób.

Istnieje trzecie podejście, będące wariantem metody iteracyjnej. Chodzi o kontynuację budowy systemu analitycznego z wykorzystaniem rozwiązania, które powstało spontanicznie jako rozwiązanie lokalnego problemu. Taki system jest zwykle wynikiem pracy jednego człowieka. Wydaje się naturalne, że skoro rozwiązanie działa lokalnie, to - jeżeli dołożyć do niego to i owo - powinno też zadziałać w skali całej firmy. Rozbudowa tego typu "niszowego" rozwiązania wydaje się atrakcyjna i czasowo, i finansowo, z reguły jednak wraz ze wzrostem skali ujawniają się jego często poważne wady. Pierwszym symptomem jest zwykle znaczny spadek wydajności spowodowany ilością danych, a tak naprawdę niedostosowaniem algorytmów do ich skali lub kresem możliwości zastosowanego narzędzia. Drugi ważny powód to brak możliwości spełnienia przez "niszowego" autora oczekiwań użytkowników z innych obszarów. Mankamentem "metody chałupniczej" jest także niemożność podjęcia szybkiej reakcji na zmiany przepisów (o zmianach w biznesie nie wspominając), co jest wymaganiem nie do uniknięcia, gdy rozwiązanie dotyka wielu aspektów działalności firmy, zwłaszcza w Polsce. Gdy to, co nieuniknione, w końcu nastąpi, całą pracę trzeba właściwie rozpocząć od początku.

Z praktyki, jak również z lektury raportów na temat sukcesów i porażek, wynika, iż metoda iteracyjna daje największą szansę na sukces, pod warunkiem że jest przeprowadzona zgodnie z zasadami realizacji (dużych) projektów informatycznych i poprzedzona solidną analizą. Bez analizy potrzeb trudno mówić o przyszłej funkcjonalności, co pociąga kłopot w wyborze odpowiednich narzędzi, a to z kolei znacząco utrudnia wybór platformy itd.

Samodzielność ograniczona

Projekt analityczny można zrealizować na kilka sposobów. Samodzielny rozwój systemu może wydawać się atrakcyjny, ponieważ wtedy produkt będzie w maksymalnym stopniu dopasowany do oczekiwań i potrzeb przyszłych użytkowników. Jednak jednocześnie, a właściwie przede wszystkim, bank powinien zajmować się rachunkami klientów, fabryka - produkcją, zakład ubezpieczeniowy - pozyskiwaniem i obsługą klientów itd. Czy jednak oznacza to, że budową systemów analitycznych powinni zajmować się specjaliści dziedzinowi, a nie informatycy? Niekoniecznie. Analityk biznesowy nie ma, nie chce mieć i nie będzie miał zaawansowanych umiejętności informatycznych i trudno oczekiwać, że będzie inaczej.

Zlecenie budowy systemu analitycznego zewnętrznej firmie z dużą dozą pewności zakończy się pomyślnym stworzeniem i wdrożeniem systemu, ponieważ projekt wykonają specjaliści z odpowiednim doświadczeniem. Wadą tej metody jest to, iż wiedza o wewnętrznej budowie systemu analitycznego pozostaje w firmie zewnętrznej. O ile dla systemów klasycznych dostosowywanie systemów do zmieniających się przepisów jest wpisane w umowy serwisowe, ich koszt utrzymania zgodności jest relatywnie niewysoki, o tyle dla systemu analitycznego realizowanego "na miarę" wszelkie zmiany wymagają dodatkowych usług analitycznych, programistycznych i wdrożeniowych.

Praktyka pokazuje, że najlepsze

rezultaty przynosi budowa systemu analitycznego przez klienta wspólnie z firmą zewnętrzną. Oczywiście, pod warunkiem rzeczywistego zaangażowania pracowników klienta w proces powstawania systemu. Po realizacji przedsięwzięcia wiedza o systemie pozostaje w firmie, dzięki czemu pracownicy sami mogą go rozwijać, sporadycznie korzystając z pomocy zewnętrznej. Ten model oparty na transferze wiedzy jest skuteczny, ponieważ firma może uniknąć popełnienia wszystkich kosztownych błędów, które zespół bez doświadczenia popełnić po prostu musi.

Pytania o fakty, nie opinie

Każdy producent oprogramowania będzie twierdził, że jego rozwiązanie jest dla pytającego najlepsze. Co ciekawe, opinia ta nie zależy od tego, do czego służy to oprogramowanie oraz jakie było pytanie potencjalnego klienta. Czy warto zatem pytać producenta o cokolwiek? Owszem. To najlepsze źródło informacji o produkcie, ale nie o jego zastosowaniach dla konkretnego klienta. Oto przykładowy zestaw zagadnień, które warto zbadać:

  • Zakres funkcjonalności oferowanej przez narzędzia

  • Liczba wdrożeń proponowanych narzędzi w ogóle

  • Liczba wdrożeń proponowanych narzędzi w Polsce

  • Stabilność zespołu rozwijającego produkt

  • Wsparcie techniczne w Polsce. Specjaliści przebywający na stałe w odległym kraju mogą być mało przydatni. Wprawdzie 95% przypadków można załatwić na odległość, ale jeśli żaden specjalista nie będzie w odległości mniejszej niż 500 km, to na pewno zdarzy się jeden z przypadków z pozostałych 5%

  • Planowany rozwój proponowanego rozwiązania

  • Elastyczność narzędzi rozumiana jako możliwość swobodnej zmiany definicji pojęć, algorytmów i relacji między nimi, a także możliwość rozszerzenia o nowe źródła danych, formaty, wzory przekształceń, aplikacje pomocnicze itd.

Wojciech Sypko jest menedżerem w firmie Andersen Business Consulting.


TOP 200