METODYKA DOKUMENTOWANIA ANALIZ BIZNESOWYCH I PROJEKTOWANIA SYSTEMÓW

Transkrypt

1 METODYKA DOKUMENTOWANIA ANALIZ BIZNESOWYCH I PROJEKTOWANIA SYSTEMÓW Wszystko to co nas otacza, samo w sobie jest naturalnie proste. Złożone są, nie poszczególne rzeczy, a to, że jest ich wiele i mają na siebie wzajemny wpływ. Celem analizy jest zidentyfikowanie w naszym otoczeniu tych prostych elementarnych rzeczy i zrozumienie ich wzajemnego na siebie wpływu. Pamiętajmy, że jedna z najtrudniejszych gier na świecie szachy to tylko kilkanaście figur i skończony zbiór reguł ich przemieszczania. Nawet największa organizacja to tylko skończona liczba ról i reguł postępowania. (żr. Jarosław Żeliński, referat na konferencji). Ideałem są, w moich oczach, rozwiązania, które dostarczone w krótkim terminie, doskonale wspierają realizację strategii organizacji. Moim zdaniem dobry analityk to taki, który przy minimalnych wymaganych nakładach pracy, potrafi odkryć i opisać mechanizm (model) działania organizacji oraz opracować dla niej możliwie najlepsze rozwiązanie w postaci opisu wymagań na to, co i jak dostawca tego rozwiązania ma wdrożyć. Dobra analiza biznesowa do dokument stanowiący sam dla siebie dowód swojej poprawności"

2 Treść opracowania stanowi także opis zakresu szkoleń i warsztatów praktycznych prowadzonych przez autora. Niniejszy dokument stanowi w całości opracowanie własne firmy Jarosław Żeliński IT-Consulting zwanej dalej Analitykiem. Wszystkie opisane narzędzia i metody są publicznymi standardami (źr. Celem stworzenia tego dokumentu jest zapoznanie Partnerów i Zleceniodawców, a także innych zainteresowanych, z metodą pracy i produktami Analityka oraz standardami jakich używa. Wersja: :56:00 Strona 2

3 O AUTORZE Jarosław Żeliński, ekspert niezależny. Ukończył Wydział Elektroniki Wojskowej Akademii Technicznej. Od 1991 roku pracuje w branży IT uczestnicząc w projektach z zakresu analiz systemowych, doradztwa organizacyjnego a także wdrożeń systemów IT. Od 1998 roku prowadzi niezależną działalność doradczą, publikuje eseje, autorskie prace analityczne i opracowania branżowe w prasie specjalistycznej i gospodarczej oraz w uruchomionym w tym samym roku własnym portalu Od roku 2003 Członek Stowarzyszenia Doradców Gospodarczych. W latach współpracownik, wykładowca Katedry Systemów Informacyjnych na Wydziale Przedsiębiorczości i Towaroznawstwa Akademii Morskiej w Gdyni. W latach roku także na Politechnice Warszawskiej. Od roku 2014 jest wykładowcą w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk. Członek International Institute of Business Analysis oraz INCOSE. Jako analityk, w swojej karierze, pomagał wielu firmom od małych do dużych, w tym także spółkom giełdowym, bankom i urzędom centralnym. Dla utrzymania wysokiej jakości efektów pracy stosuje sprawdzone na rynku, oparte na standardach i najlepszych praktykach, metody analizy, w 100% zgodne ze uznanymi na świecie standardami Object Management Group. Jako narzędzie pracy wykorzystuje profesjonalne oprogramowanie CASE 1 wspomagające dokumentowanie wyników analiz i projektów a także sam proces analizy. Modelowanie przedsiębiorstwa stwarza dobrą możliwość analizy oraz kształtowania procesów działania. Dzięki temu można uniknąć problemów przy wprowadzaniu zmian. (Hubert H. Zimmermann). Analiza i projektowanie systemów (ang. systems analysis and design). Podstawową rolą analityka systemów jest zrozumienie i opisanie badanego stanu rzeczy. Rolą analityka, w odpowiedzi na postawiony problem, jest wskazanie możliwych rozwiązań oraz ich przewidywanych skutków. Jeżeli rozwiązaniem problemu jest wprowadzenie zmian w systemie, rolą analityka jest ich zaprojektowanie. Dlatego analityk systemowy to także projektant systemów. 1 CASE (Computer-Aided Software Engineering, Computer-Aided Systems Engineering) - oprogramowanie używane do komputerowego wspomagania projektowania oprogramowania. Funkcje CASE-a to analiza, projektowanie i programowanie. Narzędzia CASE automatyzują metody projektowania, dokumentacji oraz tworzenia struktury kodu programu w wybranym języku programowania, najczęściej w programowaniu obiektowym. Typowymi narzędziami CASE są: narzędzia do modelowania w języku UML i podobnych, narzędzia do zarządzania konfiguracją zawierające system kontroli wersji, narzędzia do refactoringu (źr. WIKI). Wersja: :56:00 Strona 3

4 ZAWARTOŚĆ O autorze... 3 Jak czytać ten dokument... 6 Wartość dodana opisanej metodyki... 7 Wprowadzenie... 9 Jakie modele powstają w projekcie... 9 Proces wyboru i wdrożenia oprogramowania Analiza biznesowa Nadzór autorski nad realizacją Product Owner Obszary dziedzinowe metodyki Komunikacja Analiza i modelowanie biznesowe Wymagania Projektowanie Implementacja, testowanie, utrzymanie i rozwój Uwagi dotyczące wyboru gotowych systemów klasy ERP Komunikacja i metoda pozyskiwania danych źródłowych Analiza biznesowa Analiza kontekstu Motywacja biznesowa Wartość dodana Analiza i formalizacja struktury organizacyjnej Wartość dodana Analiza i specyfikacja reguł biznesowych i biznesowego słownika pojęć Wartość dodana Wersja: :56:00 Strona 4

5 Analiza i modelowanie procesów biznesowych Wartość dodana Metoda specyfikowania wymagań Model kontekstowy Wymagania na oprogramowanie Wymagania dziedzinowe system pojęć Wartość dodana Systemy dedykowane oraz brakujące funkcjonalności Przypadki użycia jako metoda określania wymagań funkcjonalnych (usługi aplikacji) Metoda specyfikowania logiki biznesowej - model Dziedziny systemu Abstrakcja dziedziny systemu - model BCE Model sekwencji test logiki biznesowej systemu Szczegółowy model czyli gdzie i jakie dane Inne produkty analizy i projektowania Wymagania w stosunku do Zamawiającego Biuro projektu Tryb zgłaszania uwag do treści dokumentów Wymagania w stosunku do dostawcy oprogramowania Wymagania na zawartość oferty wykonawcy Wykorzystane standardy i dobre praktyki Literatura Wersja: :56:00 Strona 5

6 JAK CZYTAĆ TEN DOKUMENT Niniejsze opracowanie adresowane jest do podmiotów zawierających umowy z Analitykiem, a także dla każdego, kto chce poznać dominujące na świecie standardy, dobre praktyki i standardy de facto, będące metodami pracy firmy Jarosław Żeliński IT-Consulting. Wkładem własnym autora jest opisana w tym dokumencie pragmatyka i konwencja modelowania dokumentowania oraz systemy pojęciowe uzupełniające standardowe notacje (tak zwane profile). Dla sponsorów projektu i kadr zarządczych przeznaczone jest Wprowadzenie. Opisuje ono tok przebiegu projektu, jego cele i korzyści. Uczestnicy biznesowi projektu (zespół projektowy ekspertów dziedzinowych Zamawiającego), dla zrozumienia jego przebiegu, powinni zapoznać się z treścią kolejnego rozdziału: Analiza Biznesowa. Uczestnicy projektu i osoby zainteresowane metodą i produktem specyfikowania wymagań (np. Opis Przedmiotu Zamówienia) powinny poznać także rozdział Analiza Wymagań. Osoby zainteresowane opisem metody specyfikowania i projektowania oprogramowania (systemów dedykowanych) powinny zapoznać się z rozdziałem Systemy dedykowane i brakujące funkcjonalności. Każdy powinien przeczytać sekcję: wymagania w stosunku do Zamawiającego i do Dostawcy oprogramowania umieszczoną na końcu dokumentu. UWAGA! W przypadku zawarcia umowy z Analitykiem, niniejszy dokument stanowi element formalnej oferty, na podstawie której doszło do zawarcia umowy. Zamawiający w umowie deklaruje, że zapoznał się z treścią tego dokumentu, i że akceptuje metody pracy Analityka w nim opisane. Dokument ten może stanowić załącznik do takiej umowy. Wersja: :56:00 Strona 6

7 WARTOŚĆ DODANA OPISANEJ METODYKI Opisany tu sposób przeprowadzenia analizy i specyfikowania wymagań pozwala: 1. Przeprowadzić audyt zarządzania i funkcjonowania organizacji, wskazać miejsca ryzykowne dla jej działania i możliwe do usprawnienia, 2. Zapanować wprowadzenie zmian i przeprowadzenie reorganizacji, 3. Przeprowadzić testy potencjalnych skutków wdrożenia zmian, już na etapie analizy, 4. Zapisać (udokumentować) logikę biznesową funkcjonowania organizacji w sposób pozwalający na jej ochronę prawną (prawo autorskie i tajemnica przedsiębiorstwa patrz nagłówek tego dokumentu), tak by prawa do opisanej logiki (i ona sama) pozostały przy Zamawiającym, 5. Opisać przedmiot zamówienia (np. usługi związane z reorganizacja, wymagania na oprogramowanie) jako Dzieło, czyli mierzalny produkt w umowie cywilnoprawnej z dostawcą usług lub wykonawcą oprogramowania, zminimalizować ryzyko zmian zakresu w trakcie trwania projektu. Dokumentacja wykonana według niniejszego opisu daje możliwości zaplanowana zakresu projektu (opis dzieła w umowie o dzieło) czyli podstawowego elementu zarządzania projektami biznesowymi. Po zakończeniu projektu lub w przypadku zaistnienia sporu z dostawcą, daje możliwość stwierdzenia, czy dostawca dostarczył to, do czego się zobowiązał. Wszystkie wykorzystane techniki i narzędzia (notacje, standardy) są wolne od opłat licencyjnych (nie dotyczy to opłat za szkolenia i podręczniki). Wersja: :56:00 Strona 7

8 PROSTOTA JEST SZCZYTEM WYRAFINOWANIA (LEONARDO DA VINCI) NIE NALEŻY MNOŻYĆ BYTÓW PONAD MIARĘ (DAWID OCKHAM) Wersja: :56:00 Strona 8

9 WPROWADZENIE Przedwczesny wybór rozwiązania praktycznie zawsze prowadzi do działania jak wdrożyć to rozwiązanie zamiast jak ulepszyć działanie firmy, gdyż każde rozwiązanie (w szczególności oprogramowanie) ma swoje specyficzne ograniczenia. Brak zaś śledzenia ustaleń i zmian w zakresie wymagań prowadzi do wielokrotnego ich powielania i utraty panowania nad tym zakresem. Opisana tu metodyka to efekt zdobywanych od 1991 roku doświadczeń, prowadzonych badań, studiów literaturowych, prac badawczych i udziału w wielu projektach. Metodyka ta bazuje na klasycznej analizie systemowej i stanowi podejście do analizy i projektowania zorientowane na tworzenie modeli i ich testowanie. Jest zgodna z zaleceniami międzynarodowych organizacji standaryzujących i naukowymi metodami prowadzenia badań, także zaleceniami firm badawczych i uznanych autorytetów 2. Jest nastawiona na wykonywanie wyłącznie tych prac, które przyczyniają się do rozwiązania konkretnego problemu w konkretnej sytuacji. Prace analityczne prowadzone są metoda top-down (od ogółu do szczegółu) a prace projektowe metodą iteracyjno-przyrostową. JAKIE MODELE POWSTAJĄ W PROJEKCIE Dzięki orientacji na modele oraz przyrostowe metody analizy i projektowania, opisana tu metodyka unika wad tak zwanych metodyk ciężkich, wymagających znacznych nakładów pracy na dokumenty nie wnoszące w danym projekcie wartości (sztywny proces projektowy). Dobór treści dokumentów jest każdorazowo ustalany. Powstają wyłącznie te dokumenty (analizy i modele), które w danym przypadku prowadzą do obniżenia ryzyka projektu i dokumentują oczekiwane efekty. Podstawową cechą projektu prowadzonego zgodnie z zaleceniami IIBA (International Institute of Business Analysis 3 ) jest tak zwane śladowanie, to jest wywodzenie każdego elementu modelu z jego nadrzędnego uogólnienia (każdy kolejny etap analizy i projektowania to uszczegółowienie wyników poprzedniego etapu). Pozwala to na stałą kontrolę celu i zakresu projektu oraz biznesowe uzasadnienie każdego jego elementu. Orientacja na procesy biznesowe, jako metoda analizy a także zarządzania organizacjami i ich opisu, stanowi kontynuację śladowania: procesy biznesowe wynikają ze strategii, wymagania na oprogramowanie wynikają z procesów (lub ich scenariuszy). Jako pierwsze powstają produkty analizy systemowej (opisuje mechanizm działa organizacji) organizacji, na jej podstawie mogą powstać rekomendacje zmian oraz sugerowane rozwiązanie do wdrożenia, jeżeli tym rozwiązaniem jest oprogramowanie, powstaje model tego oprogramowania. Jeżeli ma to być oprogramowanie gotowe, specyfikowane są wyłącznie usługi jakich oczekujemy od tego oprogramowania. 2 Lista standardów na końcu dokumentu. 3 Wersja: :56:00 Strona 9

10 W przypadku braku na rynku wymaganego oprogramowania, projektowana jest jego struktura i mechanizm działania (logika biznesowa). PROCES WYBORU I WDROŻENIA OPROGRAMOWANIA Kluczową rolą analityka biznesowego jest minimalizacja ryzyka porażki projektu. Najczęściej podawanymi przyczynami porażek wdrożeń są: źle określone wymagania, opór pracowników przed zmianami i przedwczesny wybór dostawcy rozwiązania. Dlatego sprawdzona praktyka to następujący proces: (źr. opracowanie własne autora) ANALIZA BIZNESOWA W pierwszym etapie projektu analizowane są: strategia firmy, struktura działań, przepływ informacji oraz zasoby organizacji. Produktem są modele opisujące funkcjonowanie organizacji. Na bazie wyników analizy rekomendowane mogą być: zmiany organizacyjne, wdrożenie nowych metod zarządzania i norm postępowania, wdrożenie narzędzi wspomagających zarządzanie, w szczególności oprogramowanie. Kolejny etap to zaplanowanie i przygotowanie ewentualnych zmian organizacyjnych. Po zakończeniu tego etapu zbierane są wymagania biznesowe. Na ich podstawie powstaje specyfikacja wymagań na rozwiązanie. Specyfikacja ta służy jako materiał do przeprowadzenia wyboru rozwiązania i jego dostawcy (konkurs ofert, przetarg). Rozwiązanie i jego dostawca jest wybierane dopiero na tym etapie. Po dokonaniu wyboru rozwiązania, jego dostawca musi opracować Koncepcję wdrożenia, która jest dokumentem opisującym (deklaracja) jakie działania i prace wykona dostawca, żeby spełnić wymagania. To jest moment weryfikacji i ostatecznej wyceny projektu wdrożeniowego. Od momentu zaakceptowania koncepcji wdrożenia, prowadzone jest wdrożenie. Na tym etapie Analityk nadzoruje zgodność prac Dostawcy z wymaganiami i zarządza zmianami w dokumentacji modelu biznesowego i specyfikacji wymagań (oraz projektu dla rozwiązań dedykowanych). W zależności od wielkości i specyfiki projektu, ostatnie trzy etapy (Opracowanie wymagań, koncepcji wdrożenia i wdrożenie), mogą być prowadzone metodą iteracyjno-przyrostową zorientowaną na usługi i komponenty systemu. Wersja: :56:00 Strona 10

11 Projekt wdrożenia nowego oprogramowania to określenie tego, do czego zostanie ono użyte i jak ma to użycie wyglądać. Specyfikowane są usługi, które oprogramowanie ma świadczyć (jego przypadki użycia) oraz jakość tych usług (jakość i ograniczenia: wymagania poza-funkcjonalne). Jeżeli audyt wykaże, że istnieją obszary niestandardowe w organizacji, dla tych obszarów prowadzi się szczegółową analizę, gdyż tam najprawdopodobniej (w przypadku projektów związanych z wyborem oprogramowania) będzie tworzone i wdrażane rozwiązanie dedykowane. NADZÓR AUTORSKI NAD REALIZACJĄ PRODUCT OWNER Po wyborze dostawcy, Analityk (autor projektu) nadzoruje zgodność dostarczonego produktu ze specyfikacją (nadzór autorski). Komunikacja w projekcie, w warstwie formalnej, bazuje na przekazywaniu dokumentacji i na notatkach projektowych. Poniżej scenariusze dla dwóch kluczowych zdarzeń: Wymagana dodatkowa wiedza o Zamawiającym u Dostawcy oraz Incydent u Zamawiającego. Rozwinięte zwinne metodyki zarządzania projektami, związanymi z dostarczaniem produktów takich jak oprogramowanie, przewidują rolę osoby pośredniczącej w komunikacji pomiędzy Zamawiającym a Wykonawcą (Dostawcą). Rola ta najczęściej nosi nazwę Product Owner (lub Client Proxy). Rolę tę pełni osoba mająca wiedzę o Zamawiającym, z reguły jest to Analityk Biznesowy, autor analizy i dokumentacji wymagań, który w toku projektu ją aktualizuje i zarządza jej zmianą. Wersja: :56:00 Strona 11

12 OBSZARY DZIEDZINOWE METODYKI KOMUNIKACJA Komunikacja to kluczowy element w każdym projekcie, w projektach związanych z analizą i projektowaniem szczególnie, gdyż wszelkie niejednoznaczności w treści powstających dokumentów niszczą efekty tego typu projektów, prowadzą do nieporozumień a w efekcie mogą doprowadzić nawet do krachu projektu. Komunikacja to także ustalenie ról w projekcie i ich rygorystyczne przestrzeganie gdyż rozmyta odpowiedzialność także prowadzi do nieporozumień. Dlatego w toku projektu obowiązuje ustalony plan i metody komunikacji. ANALIZA I MODELOWANIE BIZNESOWE Pierwszy etap analizy to udokumentowanie strategii firmy, jej architektury, celu biznesowego, metod realizacji celu (taktyka). Tu powstaje ogólny model biznesowy firmy. Kluczowymi źródłami informacji są sponsor projektu i zarząd organizacji (jeżeli nie jest sponsorem). Drugi etap to modelowanie procesów biznesowych. Podstawową metodą pracy na tym etapie jest audyt dokumentów operacyjnych oraz uzupełniające wywiady z kadrą kierowniczą. Produktem tego etapu jest model biznesowy zawierający opis celu biznesowego projektu, strukturę organizacji, model procesów biznesowych, słowniki pojęć i reguł biznesowych, odwołania do dokumentów operacyjnych takich jak procedury, zarządzenia, zakresy obowiązków, wzory dokumentów. Na tym etapie może być konieczny opis powiązań procesów biznesowych z posiadaną infrastrukturą IT. Metodyka ta bazuje na trójwarstwowym modelu organizacji: (źr. Wersja: :56:00 Strona 12

13 W warstwie najwyższej, strategicznej, definiowany jest model biznesowy i strategia jego realizacji. Z nich wynika ogólna architektura procesów, mierniki efektywności, polityki i reguły biznesowe. Odpowiada na pytanie Co jest naszym celem? Kolejna warstwa to procesy biznesowe oraz wewnętrzne ustalenia reguły biznesowe: model wewnętrznego łańcucha wartości. Model procesów odpowiada na pytanie Co i w jakim celu należy zrobić? Warstwa najniższa. Postać wewnętrzna procesów biznesowych to skutek istnienia ograniczeń i wymagań, którymi są model biznesowy i strategia jego realizacji oraz ograniczenia narzucane przez prawo, posiadane zasoby (w tym ludzi i ich umiejętności). Ta warstwa to warstwa wykonawcza. Opisuje szczegóły realizacji procesów: jakich kompetencji, umiejętności, procedur i narzędzi wymaga realizacja procesów i jakimi dysponujemy. Odpowiada na pytanie Jak realizujemy procesy biznesowe, jak (i czym) należy to zrobić? Optymalizacja procesów to podnoszenie ich efektywności, w tym jakości ich produktów. Formalizacja to element porządkowania (spisywanie procedur i wymaganych umiejętności ich wykonawców) warstwy wykonawczej. WYMAGANIA Specyfikowanie wymagań to proces analizy i specyfikowania oczekiwanych cech rozwiązani postawionego problemu. Specyfikacja wymagań (także na oprogramowanie) jest rekomendacją, będąca produktem analizy biznesowej i celu projektu. Wymagania to specyfikacja cech jakimi powinien się charakteryzować produkt np. oprogramowanie (ale także nowy np. zestaw zarządzeń wewnętrznych). Wymagania są uzupełniane ograniczeniami (czyli np. oczekiwaną jakością procesów w organizacji lub niedoborem kadr w projektach z poza IT). Wymagania są mapowane (śladowanie wstecz) na cele biznesowe w celu ich weryfikacji (uzasadnienie biznesowe każdego wymagania). PROJEKTOWANIE Jeżeli analiza (lub jej fragment) dotyczy dedykowanego systemu informacyjnego (może to być część większej całości), jest opracowywany tak zwany projekt (model) architektury wysokiego poziomu (bardzo ogólny projekt systemu) oraz specyfikacje (projekty) tych elementów systemu (oprogramowania), które muszą zostać opracowane i wykonane jako oprogramowanie dedykowane (brak produktów na rynku spełniających wymagania). W ramach tego etapu powstają szczegółowe opisy logiki biznesowej jaka, w ramach realizacji wymagań, ma zostać odwzorowana w oprogramowaniu (systemie IT). Jeżeli jest to projekt organizacyjny, produktem projektowania może być np. specyfikacja reguł biznesowych jako materiał wejściowy do weryfikacji zarządzeń wewnętrznych i procedur i potem projekty tych procedur i zarządzeń. Wersja: :56:00 Strona 13

14 IMPLEMENTACJA, TESTOWANIE, UTRZYMANIE I ROZWÓJ Te fazy, to dalszy ciąg cyklu życia produktu jakim jest nowy system. Na tym etapie rola autora dokumentacji z roli Analityka Biznesowego (projektanta systemu) przechodzi do roli Właściciela (tego) Produktu (Product Owner wg. metodyki SCRUM zarządzania projektami). Polega ona na prowadzeniu nadzoru autorskiego i zarządzanie zmianą w dokumentacji opisującej produkt. Jest to etap wdrożenia rozwiązania i jego utrzymania realizowany przez dostawcę rozwiązania lub samodzielnie. Poniższy schemat obrazuje rolę Właściciela Produktu w projekcie, który pośredniczy w komunikacji pomiędzy dostawcą rozwiązania (po lewej) a jego odbiorcą (po prawej). UWAGI DOTYCZĄCE WYBORU GOTOWYCH SYSTEMÓW KLASY ERP Systemy klasy ERP to szeroka gama oprogramowania wspomagającego zarządzanie przedsiębiorstwami i organizacjami. Skrót ERP oznacza Enterprise Resource Management (Zarządzanie Zasobami Organizacji). Systemy tego typu wywodzą się ewolucyjnie z systemów MRP (ang. Material Requirement Planning, Planowanie Potrzeb Materiałowych) i MRP II (ang. Manufacturing Resource Planning, Planowanie Zasobów Produkcyjnych). Od kilku lat obecne jest na rynku pojęcie ERP II. Podstawową cechą odróżniającą systemy ERP II od poprzedników jest to, że oprócz funkcjonalności umożliwiającej planowanie zasobów rzeczowych i finansowych przedsiębiorstwa, zawierają oprogramowanie pozwalające na zarządzanie kontaktami z klientem (tzw. CRM - Customer Relationship Management), prowadzenia kontrolingu, mają funkcjonalności zaawansowanego raportowania (podsystem wspomagania podejmowania decyzji, Business Intelligence). Cechą tych systemów, obecnie już wymaganą, jest także możliwość korzystania z nich poprzez sieć WWW. UWAGA! Nie jest jednak konieczne by cały ten zestaw funkcjonalności stanowił jeden pakiet oprogramowania od jednego producenta! Jak widać są to bardzo złożone systemy. Lista detaliczna cech takiego pakietu ERP II może obejmować nawet ponad 6 tys. pozycji! Planowanie ich całościowego wdrożenia a wcześniej specyfikowanie wymagań, wybór konkretnego produktu i jego dostawcy, nie może więc być typowym procesem specyfikowania wymagań funkcjonalnych: nikt nie jest w stanie skutecznie zarządzać taką liczbą wymagań w jednym projekcie! Wersja: :56:00 Strona 14

15 W ramach zakresu systemów ERP II pojawiają się też moduły bilingowe, call center, workflow, business inteligence (system wspomagania podejmowania decyzji). Opisana tu metodyka, bazuje na uznaniu, że standardowe obszary działania, powinny być obsługiwane standardowymi narzędziami (spełniającymi pewne normy, standardy, zgodne z ustalonymi przepisami prawa). Ich definiowanie nie polega na specyfikowaniu wszystkich ich cech, których są setki, a powoływaniem się na te normy i przepisy, z którymi produkty te (oprogramowanie) muszą być zgodne. Wymagania takie wystarczy uzupełnić o kluczowe parametry naszych procesów i cechy dokumentów (najwyżej kilkadziesiąt!) oraz testy (procedury testowe) czy konkretne oprogramowanie je spełnia. Wystarczające powinno być opisanie procesów jakie mają być wspierane tym oprogramowaniem (Co chcemy uzyskać a nie Jak). Projekty, których celem jest wdrożenie gotowego standardowego oprogramowania, w opisanej tu metodyce, są prowadzone w sposób pozwalający na jak najszybsze zdefiniowanie obszaru stanowiącego kluczowy obszar przewagi konkurencyjnej beneficjenta wdrożenia, stanowiący specyfikę danej organizacji, to co odróżnia ją od reszty (praktyka pokazuje, że jest to kilka do kilkunastu procent działań). To założenie pozwala prowadzić projekt w następujący sposób: 1. analiza biznesowa, 2. analiza przewagi konkurencyjnej, 3. wyłonienie obszaru budującego przewagę na rynku, 4. zdefiniowanie wymagań na tak określony obszar, 5. wskazanie standardów, które opisują pozostałe działania w organizacji. Najlepsze praktyki wdrożeń dużych i złożonych systemów, zalecają traktowanie ich modułów jako zespołu odrębnych dziedzinowo podsystemów, wdrażanych niezależnie (nawet jako osobne produkty pochodzące od różnych producentów). Obecny poziom standaryzacji oprogramowania pozwala na relatywnie łatwą integrację produktów różnych dostawców. Praktyka pokazuje także, że wybór i wdrożenie kilku dobrze dobranych podsystemów osobno, jest tańsze niż wybór jednego uniwersalnego i dostosowywanie go do swoich potrzeb (tak zwana kastomizacja). Takie też podejście jest tu rekomendowane. Wersja: :56:00 Strona 15

16 KOMUNIKACJA I METODA POZYSKIWANIA DANYCH ŹRÓDŁOWYCH Zarzadzanie projektem ma dwa aspekty: 1. Stawianie zadań. 2. Przekazywanie informacji. Pierwszy to oczekiwania wobec dostawcy informacji, drugi to zagwarantowanie pewności przekazania i spójności tych informacji. Wymiana informacji pomiędzy stronami (analityk, organizacja analizowana, dostawca rozwiązania) wymaga więc nadzoru a nie raz poufności (która na tym etapie prac staje się już standardem). Wiele lat doświadczeń doprowadziło do uznania, że obiektywne informacje o sposobie pracy organizacji niosą dokumenty jakie w niej powstają w myśl zasady: jeżeli coś jest na prawdę istotne, to jest to dokumentowane. Wywiady są prowadzone wyłącznie w celu wyjaśniania braków, nie stanową podstawowego narzędzia pozyskiwania informacji o analizowanej organizacji. Praktyka pokazuje, że jest to metoda pewniejsza i mniej kosztowna, a dająca znacznie wyższej jakości produkt. Podobne postępowania zalecane jest w metodach prowadzenia analiz opisywanych przez organizację IIBA. Metoda ta pozwala na systematyczny przegląd pracy organizacji, jej modelowanie w takt postępu analizy dokumentów, pozwala na identyfikowanie wszelkich niejednoznaczności i luk w wiedzy o działaniach organizacji. Pozwala szybko zidentyfikować metody pracy zwyczajowe, nieformalne i podjąć decyzje o ich formalizacji lub odrzuceniu. Analiza odbywa się metodą od ogółu do szczegółu, zbierane i analizowane są kolejne dokumenty operacyjne, powstają wstępne modele które są konsultowane z dostawcami tych danych, nanoszone są ewentualne korekty, i proces powtarza się aż do uzyskania opisu organizacji w ustalona wcześniej dokładnością (wynikającą z celu projektu). Poniższy diagram obrazuje proces prowadzenia analizy ta metodą: Wersja: :56:00 Strona 16

17 Komunikacja w tak prowadzonym projekcie to stała współpraca pomiędzy analitykiem a ekspertami dziedzinowymi klienta. Analityk inicjuje kolejne etapy projektu, informując określonych ekspertów dziedzinowych analizowanej organizacji, jakich danych potrzebuje. Eksperci Ci udzielają informacji (przekazują dokumenty) oraz jako recenzenci powstających kolejnych elementów dokumentacji, przekazują swoje uwagi (zapisy są zgodne lub niezgodne z prawdą, brakuje jeszcze.. itp.). Metodą komunikacji jest elektroniczna wymiana informacji i dokumentów, w sposób pozwalający śledzić cały proces i zagwarantować jego poufność: (w ramach prowadzenia projektu dostarczam wszelkie narzędzia do zdalnej pracy). Wersja: :56:00 Strona 17

18 ANALIZA BIZNESOWA Etap Analizy Biznesowej obejmuje weryfikację (audyt) posiadanych informacji na temat celu biznesowego, metod jego mierzenia, etapów osiągania celu a także inwentaryzację kluczowych zasobów do jego realizacji i strategii. Może zawierać analizę ryzyk, analizę SWOT oraz innych parametrów mogących mieć wpływ na realizację projektu. Etap ten stanowi inwentaryzację wiedzy o organizacji i otoczeniu projektu. ANALIZA KONTEKSTU MOTYWACJA BIZNESOWA Podstawą (szkieletem) analizy biznesowej jest tak zwany Model Motywacji Biznesowej (ang BMM, Business Motivation Model, spec. Model BMM ujmuje kontekst projektu biznesowo w różnych wymiarach, w celu uzasadnienia dlaczego Zarząd organizacji chce coś robić, do czego dąży, jak zamierza to osiągnąć oraz jak oceni rezultaty. Główne elementy modelu BMM: Stan końcowy - Cele: Co (w odróżnieniu od jak) organizacja chce osiągnąć, Metody - Środki : Jak i z pomocą czego organizacja zamierza osiągnąć swoje cele, o Strategia osiągnięcia celu: jak planujemy osiągnąć cel, o Taktyka: co będziemy w związku z tym robić. Organizacja: Reguły biznesowe oraz Polityki, są to części modelu biznesowego Organizacji, zawierają wewnętrzne zasady funkcjonowania, Czynniki wpływu, Ograniczenia: mają wpływ na organizacje i sposób jaki osiąga ona swoje cele albo korzysta ze swoich środków, Ocena sytuacji, ryzyka, oczekiwane zyski itp.: w jaki sposób Ograniczenia wpływają na sposób w jaki organizacja z pomocą posiadanych środki osiąga cele, Podstawowym celem opracowania tego modelu jest usystematyzowanie posiadanej projektu, jego środowisku i jej ewentualne uzupełnienie. wiedzy o celu Ustalenia te pomagają uniknąć problemów podczas ustalania priorytetów dla poszczególnych wymagań oraz zabezpieczają przez brakiem możliwości stwierdzenia czy wdrożenie odniosło zamierzony skutek. W trakcie całej analizy biznesowej na etapie specyfikowania wymagań powinny być te wymagania weryfikowane, czy przyczyniają się do osiągnięcia celu projektu. Brak jasno zdefiniowanego celu oraz powiązanych z nim elementów takich jak czynniki wpływu, działania pozwalające na osiągnięcie celu, procesy biznesowe realizujące strategie osiągania celu, prowadzi do sytuacji, w której nie ma możliwości sprawdzenia czy dane wymaganie przyczynia się do osiągnięcia celu projektu. Brak kryterium oceny prowadzi do zjawiska zwanego puchnięciem zakresu projektu: pojawiają się nowe oczekiwania i nie ma narzędzia do ich akceptacji lub odrzucania. Przykładowy model motywacji wyrażony graficzne wygląda jak poniżej: Wersja: :56:00 Strona 18

19 Uzupełnieniem, wsparciem tego modelu jest biznesowy słownik pojęć i reguł biznesowych (spec. WARTOŚĆ DODANA Audyt wiedzy o celu i środowisku projektu pozwala zweryfikować to, czy posiadane są niezbędne dane do zrozumienia i oceny zasadności biznesowej projektu i jego ryzyka. Daje podstawowe dane do ewentualnej oceny jego rentowności. Jasno określony i mierzalny cel projektu to jedyne narzędzie oceny czy zgłaszane np. przez pracowników wymagania służą osiągnięciu celu czy nie, i jakim kosztem. ANALIZA I FORMALIZACJA STRUKTURY ORGANIZACYJNEJ Jednym z najczęściej zaniedbywanych obszarów organizacji podczas analiz jest struktura organizacyjna. Sformalizowana struktura organizacyjna porządkuje wiedze o: 1. Powiązaniach pomiędzy komórkami organizacyjnymi, 2. Rolach (kompetencje i umiejętności) pracowników, 3. Podległości pracowników (zakresy uprawnień). Model struktury organizacyjnej to hierarchiczna struktura obrazująca poszczególne komórki organizacyjne, podległość osób oraz ich przynależność do komórek organizacyjnych. Cechą poprawnie sformalizowanego Wersja: :56:00 Strona 19

20 modelu struktury organizacyjnej jest jego drzewiasta 4, hierarchiczna struktura. Spotykane przypadki osób mających poszerzone kompetencje (osoby pełniące kilka ról) należy obrazować podając niezależnie dane tej osoby przy kilku rolach. Tworząc strukturę (jej model) organizacyjną stosowane są następujące pojęcia: 1. Organizacja - nazwana grupa ludzi mających ustaloną strukturę i działających razem, aby osiągnąć wspólne cele (podmiot gospodarczy, urząd, itp.). 2. Jednostka (komórka) organizacyjna jedno- lub wieloosobowy zespół (organ) powołany do wykonywania określonych zadań, mający ustalone miejsce w strukturze organizacyjnej. 3. Stanowisko miejsce w hierarchii organizacji lub komórki organizacyjnej. 4. Osoba pracujący na rzecz organizacji człowiek. 5. Rola zakres obowiązków i kompetencji. Przykład modelu struktury (diagram) organizacyjnej zawierającej zarówno podległość komórek jak i ról: Z uwagi na czytelność oraz specyfikę wielu firm, w praktyce często rozdziela się diagramy modelujące strukturę komórek organizacyjnych i modelujące przynależność do nich pracowników. 4 Drzewo oznacza w teorii grafów graf, który jest acykliczny i spójny. Mówiąc językiem obrazowym, z każdego wierzchołka drzewa można dotrzeć do każdego innego wierzchołka (spójność) i tylko jednym sposobem (acykliczność, czyli brak możliwości chodzenia w "kółko"). Wersja: :56:00 Strona 20