es i 5 - 2 o
■ ■ ■ ■ K B B B B B B B
B B B B B B
Polskie
Towarzystwo Informatyczne
W d r a ż a n ie i e k s p l o a t a c j a
SYSTEMÓW INFORMATYCZNYCH
W y b r a n e p r o b l e m y
s \
Redakcja:
Marek Miłosz
Polskie Towarzystwo Informatyczne
Lublin 2002
Wdrażanie i eksploatacja systemów informatycznych
Wybrane problem y
Redakcja:
M arek Miłosz
Lublin 2002
prof, dr hab. Włodzimierz Sitko, Wyższa Szkoła Przedsiębiorczości i Adm inistracji w Lublinie
prof, dr hab. Zdzisław Szyjewski, Uniwersytet Szczeciński
W ydaw cy:
Lubelskie Ceni rum M arketingu sp. z o.o.
Polskie Towarzystwo Informatyczne
IS B N 83-915027-7-5
Druk:
LCM sp. z o. o.
Lublin 2002
Spis treści
W s tę p ... 5 1. Realizacja przedsięw zięć inform atycznych - fakty i m ity ... 7
(M iłosz Marek)
2. Zarządzanie ryzykiem w przedsięwzięciu in fo rm a tyczn ym ... 17 (M iśkiew icz Monika, Szyjew ski Zdzisław)
3,. O rganizacja szkoleń w procesach w d ro że n io w ych ... 29 (Łukasik-M akow ska Barbara)
4. Rola użytkownika w procesie wdrażania system ów in fo rm a ty c z n y c h ... 39 (M iłosz Elżbieta)
5. Problem y wdrażania aplikacji do obsługi procesów p ra c y ...45 (Kulik W ojciech)
6. Zarządzanie wersjam i z w ykorzystaniem system u C V S ... 53 (W ojciechow ski Adam )
7. Przedsięw zięcia p o rta lo w e ... 65 (M iłosz Marek)
8. E ksploatacja system ów inform atycznych w praktyce polskich
m ałych i średnich p rz e d s ię b io rs tw ... 73 (M iłosz Elżbieta, M iłosz Marek)
9. ebXDI - technologia EDI za rozsądne p ie n ią d z e ...85 (M uryjas Piotr, B o b e r Dariusz)
10. W ybrane zagadnienia z projektow ania system ów inform atycznych
w zakładach e n e rg e tyczn ych ... 97 (Kaczorow ska Anna, Pam uła Anna, Z ieliński Je rzy Stanisław)
11. Problem y wdrażania i eksploatacji Systemu21 w firm ie Lubella S .A ... 115 (B ober Dariusz, P iasecki Tomasz)
12. Zarządzanie procesem w drożenia systemu klasy ERP na przykładzie
m etodyki opracow anej przez BPSC S .A ... 127 (Boryka Andrzej)
13. Przewidzieć nieprzew idyw alne - tajem nica udanego w d ro ż e n ia ... 137 (Faszyński Ryszard)
14. W drożenie i eksploatacja system u inform atycznego rejestru długów
K A C Z M A R S K I.P L ... 147 (G ryniew icz M ichalina)
15. Telefonia kom órkowa jako nowe medium m a rk e tin g u ... 167 (Szym oniuk Barbara, M ichalak Pawei)
16. M onitorowanie pracy kom puterowych stanow isk roboczych... 179 (W ójcicki Marcin, P aw łow ski Jacek)
17. Analiza procesów produkcyjnych pod kątem pow staw ania kosztów.
W drożenie systemu klasy ERP w SGL A n graph ...187 (Boryka Andrzej)
18. Internetowa hurtownia m ateriałów elektrycznych w Elektro-Spark sp. z o.o. .. 193 (W aleszczak Adam )
19. Integracja, integracja, in te g ra c ja ... 199 (W iśniow ski Piotr)
W ykaz a u to ró w ... 209
M ateriały reklam ow e sponsorów:
Biuro Projektowania System ów Cyfrowych S.A. (BPSC S .A .) ... 213 M ATRIX.PL S .A ... 215
W stęp
Procesy wyboru, zakupu, w drażania i późniejszej eksploatacji system ów inform atycznych s ą najistotniejszym i, bo najbliżej zw iązanym i z użytkownikiem , fazam i cyklu życia system u inform atycznego. Procesy te stanowią, ja k do tej pory, piętę a chillesow ą wielu przedsięw zięć inform atycznych. Duża liczba porażek w obszarze wdrożeń system ów inform atycznych wynika z niedostatecznego wysiłku badaw czego oraz z nikłej w iedzy i braku um iejętności zespołów w drażających system y inform atyczne. Celem książki jest prezentacja rezultatów prac badawczych w obszarze wdrożeń i eksploatacji system ów inform atycznych oraz upow szechnienie najnowszych m etod doboru oprogram ow ania, przygotow ania firm y do jego przyjęcia i zarządzania procesem w drożeniow ym oraz eksploata cją system ów inform atycznych zarządzania.
Książka dotyczy szerokiego zakresu zagadnień zw iązanych z końcow ym i fazami cyklu życia system ów inform atycznych: wdrażania i eksploatacji. Problem y te zostały przedstaw ione przez pracowników naukowych szeregu polskich uczelni, a także przez praktyków - inform atyków firm dostaw ców i użytkow ników system ów inform atycznych. Szczególnie szeroko, i to zarów no z teoretycznego jak i praktycznego punktu widzenia, zostały potraktow ane problem y w drażania systemów.
Książka je st adresow ana do wszystkich, którzy ch c ą pogłębić s w o ją wiedzę z zakresu w drożeń i eksploatacji system ów inform atycznych. Powinna szczególnie zainteresow ać studentów kierunków inform atycznych oraz kadrę kierownicza^
przedsiębiorstw. Studenci znajdą w niej inform acje o teoretycznych i praktycznych aspektach zastosow ań inform atyki w różnych przedsiębiorstw ach, m etodyce wdrożeń
oraz elem entach eksploatacji system ów. Kadra kierow nicza zaspokoi niedosyt inform acji w zakresie zastosowań inform atyki, organizacji prac w drożeniow ych oraz m ożliwości jakie niosą ze sobą w spółczesne technologie inform atyczne. Szczególnie cennym elem entem występującym w książce s ą inform acje o w drożeniach różnych system ów inform atycznych w wielu firmach.
Dzięki wielostronnem u, a jednocześnie syntetycznem u ujęciu, przedstaw ione w książce problem y w drożeniow e oraz przykłady przedsięw zięć zakończonych sukcesem m ogą przyczynić się do sprawniejszej realizacji projektów inform atycznych.
Praca powstała dzięki zaangażow aniu jej współautorów , którzy zechcieli się podzielić w łasną wiedzą, um iejętnościam i i dośw iadczeniem w zakresie wdrażania system ów inform atycznych. Niemały wkład m erytoryczny i finansow y w nieśli także sponsorzy publikacji.
W szystkim : autorom, recenzentom i sponsorom , którzy przyczynili się do powstania książki, wyrażam swoje podziękowania.
dr inż. M arek Miłosz (Redaktor)
1
Realizacja przed sięw zięć in fo rm atycznych - fakty i mity
P rzystępując do realizacji przedsięwzięcia polegającego na np. budowie dom u, drogi czy mostu (a w ięc budowli trochę większej niż psia buda czy też szopa) należy w ykonać caty szereg czynności, zw iązanych z zarządzaniem przedsięw zięciem - projektem (ang. Project M anagem ent). Przez wiele lat ludzkość dopracow ała się standardow ych procedur I działań, które maja, zapew nić sukces budowie, rozum ianej jako stw orzenie budowli bezpiecznej dla ludzi. W związku z czym inżynierowie budownictwa m uszą zaprojektow ać rezultat swoich działań, poddać go w szechstronnej ocenie i sprawdzeniu przez innych specjalistów , ocenić koszty, zaplanow ać proces realizacji i w reszcie prowadzić całe przedsięw zięcie zgodnie ze sztuka, i pod nadzorem inspektora i stosow nego urzędu. Nikt nie w yobraża sobie budowy bez jej kierownika, harm onogram u czy też kosztorysu. Nikt nie wyobraża sobie budowy bez ściśle określonych zakresów odpow iedzialności i gwarancji m ożliwości spełnienia wym agań inwestora, udzielonych przed rozpoczęciem inwestycji. Nikt też nie w yobraża sobie tylko częściow ego spełnienia tychże wym agań. Nikt w reszcie nie dopuszcza nawet myśli, że okna się nie b ędą zam ykać a drzwi nie zm ieszczą się w futrynie.
A przedsięw zięcia inform atyczne? Czy s ą w analogiczny sposób identyfikow ane, planowane i realizowane?
1 . 1 . Pr o b l e m y r e a l i z a c j i p r z e d s i ę w z i ę ć i n f o r m a t y c z n y c h
Praktycznie każde przedsięw zięcie inform atyczne je st unikalne dla zespołu realizującego. Stw ierdzenie to dotyczy zarów no projektu w ytw orzenia system u -
oprogram ow ania (np. nowego program u, um ożliw iającego hurtowni zbieranie i obsługę zam ówień przez Internet) ja k i w drożenia jakiegoko lw ie k gotow ego produktu inform atycznego (np. nowy system bilingow y czy też system klasy MRP ll/ERP). Do takich unikalnych projektów dla pojedynczego inform atyka należy naw et okablowanie budynku, jego w ym iana lub dołączenie firm y do Internetu.
Na unikalność, a w ięc jednostkow ość, przedsięw zięć inform atycznych nakłada się cały szereg różnych dodatkowych uwarunkow ań realizacyjnych i cech charakterystycznych projektów inform atycznych. W arto tutaj w spom nieć o tych, które najbardziej utrudniają realizację przedsięw zięć inform atycznych:
• „wybuch technologiczny” - cecha ta zw iązana je st z bardzo szybkim (w stosunku do czasu realizacji przedsięw zięć np. budow lanych) rozwojem technologii inform atycznej; w takiej sytuacji praw dziw ym jest stwierdzenie, że „zbudow any i w drożony system je s t system em przestarzałym "; stanowi to w yjątkow o dyskom fortow ą sytuację dla inform atyków: natychm iast po ukończeniu prac trzeba zaczynać m odyfikację i rozwój (jest to zw iązane z szyb ką zm ianą bazy technicznej i oprogram ow ania system ow o-narzędziow ego, typowym i praktykam i producentów, którzy zaprzestają w sparcia dla produktów 2-3 letnich, m oralnym i ekonom icznym zestarzeniem się różnych elem entów SI);
• abstrakcyjność i duża złożoność systemów informatycznych (SI) - cecha ta powoduje, że trudno jest zdefiniow ać param etry charakteryzujące sam system i jeszcze trudniej je zm ierzyć; param etry te pow inny bowiem odw zorow yw ać wiele różnych aspektów SI, w w iększości abstrakcyjnych, je s t ich dużo i bardzo często ich zachowanie ma przeciw staw ne tendencje;
• niewidzialność systemów informatycznych - cecha ta wynika z abstrakcyjności SI; związana je st też z szerszym problem em , w tym i nieujawnianiem przed dostaw ców szczegółów architektury system ów czy też kodu źródłow ego program ów; dostaw cy SI postępują tak z różnych powodów - przew ażnie jest to elem ent ochrony praw autorskich lub też wynika on ze złożoności danego elem entu SI; często klient nie ma m ożliw ości (brakuje mu w iedzy, znajom ości technologii, czasu czy też finansów ) skontrolow ania zakupionego produktu, nawet w sytuacji gdy otrzym a p e łn ą je g o dokum entację;
• wielowarstwowość SI - cecha ta prowadzi do „rozm ycia odpow iedzialności” za produkt; SI je st bowiem system em składającym się z różnych elem entów,
Realizacja przedsięwzięć informatycznych - fakty i mity 9
pochodzących od różnych dostawców; użytkownik nie wie kogo obarczyć odpow ie dzialnością za błędne działanie SI; w sytuacji wielu różnych dostaw ców elem entów składowych SI stwarza to m ożliwości różnych nadużyć w stosunku do klienta: trudno jest bowiem zdefiniow ać obszar odpow iedzialności poszczególnego dostawcy; pewnym w yjściem z tej sytuacji jest korzystanie ze specjalnego typu dostaw ców SI - integratorów, którzy przyjm ują odpow iedzialność za połączenie w jednat całość wielu w arstw SI;
• brak jednoznacznych miar jakości SI - nie je st m ożliwe stworzenie jednolitego system u pomiaru jakości SI opartego o w ielkości kw antyfikow alne i jednoznacznie m ierzalne; problem em je st różnorodność (i słaba definiow alność) wym agań użytkow ników (również tych sam ych ale w różnym czasie), różnorodność cech jakości i ich wag (subiektywizm ); w iększość system ów bazuje na ocenach ekspertów i/lub ankietach, a zatem na subiektyw nych ocenach ludzi;
• brak możliwości praktycznej weryfikacji konkretnego SI a priori - cecha ta jest zw iązana z unikalnością, jednostkow ością, a jednocześnie d u żą złożonością^
i niewidzialnościa^ SI; można się posiłkow ać w izytam i referencyjnym i, porów naniam i, wersjam i dem onstracyjnym i ale nie ma m ożliwości sprawdzenia SI tak ja k np. sprawdza się sam ochód w trakcie ja zd y próbnej przed jego zakupem ;
• pozorna łatwość wprowadzania zmian - wrażenie takie je st skutkiem działań inform atyków, którzy bez zbędnych ceregieli i projektów w prow a d za ją zm iany do SI ad hoc; w w iększości przypadków to się zwykle udaje, bez zauw ażalnej na pierwszy rzut oka utraty jakości rezultatu; wszystko jednak do czasu - niezauw ażalne zm iany zwykle doprow adzają do załam ania całego SI.
Poza tym SI je st czę ścią system u inform acyjnego każdego przedsiębiorstw a, który z kolei zależy w dużej m ierze od otoczenia m akroekonom icznego. Taki bezpośredni związek im plikuje olbrzymia^ zależność procesów realizacji przedsięw zięć inform atycznych od czynników zew nętrznych, takich jak:
• kultura i styl zarządzania przedsiębiorstwem ; typow ym przykładem oddziaływania tego czynnika jest powiedzenie: „inform atyzacja bałaganu daje bałagan do kw adratu” ;
• zakres organizacyjny przedsięwzięcia inform atycznego (np. w drożenie systemu klasy M RP ll/ER P dotyczy praktycznie każdego działu firmy); różni użytkow nicy
SI generują różne, częstokroć przeciw staw ne w ym agania w stosunku do systemu;
• niepew ność i strach przed zm ianą, w prow adzan ą w trakcie przedsięw zięcia inform atycznego;
• różnorodność punktów spojrzenia na rezultat przedsięw zięcia inform atycznego:
biznesowy, prestiżowy, techniczny itp.;
• złożona rola użytkownika SI (z jednej strony powinien specyfikow ać wym agania, a z drugiej będzie w ostateczności w ykorzystyw ać system ) i brak jego dostępności w trakcie realizacji przedsięwzięcia inform atycznego (lub po prostu brak wiedzy);
• niechęć decydentów do w ykorzystyw ania zew nętrznych firm konsultingowych;
je st ona zw ykle powodowana próbą zaoszczędzenia środków finansowych i bardzo często przykrywana stw ierdzeniam i typu: „tajem nica m arketingow a” czy też „my też mamy własnych specjalistów ” ; niechęć taka niejednokrotnie doprow adza do pom yłek i zwiększenia kosztów przedsięwzięcia;
• legislacja;
• polityka, zależność ta jest szczególnie obserw ow alna w przypadku dużych, ogólnokrajow ych system ów;
• konkurencja, moda czy nawet pogoda (w niektórych przypadkach m oże w istotny sposób zaburzyć realizację przedsięwzięcia inform atycznego).
Przedsięwzięcia inform atyczne s ą zatem z definicji trudne do planow ania i realizacji.
1 .2 . PRZEDSIĘWZIĘCIA INFORMATYCZNE - FAKTY
Realizacja przedsięw zięć inform atycznych jest przyrów nyw ana do m arszu śmierci [11] - marszu ku klęsce. Klęsce, czyli braku sukcesu projektu pom im o olbrzym ich, w ręcz nadludzkich w ysiłków ponoszonych przez jego realizatorów. Jak pokazują liczne badania (min. takich instytucji ja k Standish czy G artner G roup) przeważająca w iększość przedsięw zięć inform atycznych jest skazana na klęskę. Średnie opóźnienie czasu realizacji projektu kom puterow ego wynosi 6 do 12 miesięcy, a budżet je s t przekraczany o 50 do 100%. Pom im o tego, w iększość projektów nie osiąga zakładanych celów. Szczególnie źle wygląda sytuacja dla średnich i dużych przedsięw zięć inform atycznych (tab. 1.1 i rys. 1.1).
Realizacja przedsięwzięć informatycznych - fakty i mity 11
Tablica. 1.1. Efektywność realizacji przedsięwzięć informatycznych (% projektów) [2]
Na czas O późniony Przerwany W ielkość
system u
Przed term inem
1 FP 14,67 83,16 1,92 0,25
10 FP 11,08 81,25 5,67 2,00
100 FP 6,06 74,78 11,83 7,33
1 000 FP 1,24 60,76 17,67 20,33
10 000 FP 0,14 28,03 23,83 48,00
100 000 FP 5,53 56,94 13,71 23,82
70%
60%
s?
° 50%
1
to 40%_QO
O 3 0 %--- CL0
1 20%
Ol
10%
0% - : |
1 10 100 1 0 0 0 10000 100000
W ie lk o ś ć s y s te m u , FP
Rys. 1.1. Prawdopodobieństwo przerwania przedsięwzięcia informatycznego bez osiągnięcia celów [2]
W pracach [2, 10, 11] sklasyfikow ane zostały najw ażniejsze przyczyny niepowodzeń przedsięw zięć inform atycznych:
• niejasne cele przedsięwzięcia,
• nieodpow iednie planow anie i estym acja zużycia zasobów (zbyt optym istyczna, życzeniow a, brak doświadczenia),
• brak kontroli jakości realizacji przedsięw zięcia (od w czesnych faz specyfikacji po w drożenie),
♦ brak m iar potrzeb i stopnia ich realizacji,
♦ brak (lub niepopraw nie stosowany) system u zarządzania projektam i,
♦ niepopraw na współpraca pom iędzy klientem a zespołem realizacyjnym .
W w arunkach polskich do pow yższego zbioru przyczyn niepowodzeń można z powodzeniem dołączyć inne, nie mniej istotne [6]:
♦ brak definicji celów organizacji, w której jest realizow any projekt inform atyczny - m ierzalnych celów biznesowych (w tym i w ynikających zeń celów biznesowych inform atyzacji),
♦ brak dokładnego określenia (i w yraźnego rozgraniczenia) zadań w zakresie organizacji pracy i inform atyki,
♦ nie zaw sze racjonalna motywacja zarządu przedsiębiorstw a i w ynikająca z niej postawa w stosunku do przedsięwzięcia.
1 . 3 . Ty p o w e z a g r o ż e n i a n a e t a p i e w y b o r u iz a k u p u S I
Na etapie wyboru i zakupu SI popełniana s ą często kardynalne błędy, których skutki i konsekwencje są długotrw ałe i dotkliwe finansowo. Do takich zagrożeń przedsięw zięć inform atycznych należą:
♦ w ybór system u bez sprecyzow ania wym agań (a w ięc bez szczegółow ej analizy) w danym konkretnym przedsiębiorstw ie (w ybór na zasadzie: oni maja to my też);
♦ w ybór SI na podstawie powierzchow nej analizy m ożliwości lub też w ręcz pod wpływem sprzedaw ców system ów; w efekcie końcowym jest to w ybór tego co jest najw ym ow niej oferowane (czytaj: reklam owane), a nie tego co jest potrzebne;
♦ w ybór SI na podstawie opinii kolegów z innych przedsiębiorstw , którzy s ą z kolei przekonani, że m ają najlepszy z m ożliwych system;
♦ w ybór rozwiązania tanio oferowanego, które potem dopiero okazuje się bardzo drogie; nie ma system u: taniego, dobrego i szybko wdrażanego;
♦ nadm ierna wiara we własne siły i siły paru inform atyków z przedsiębiorstwa (którzy zre sztą zwykle nie są zw alniani na czas przedsięw zięcia ze swoich codziennych obow iązków ); brak zaangażow ania konsultantów zew nętrznych (wstyd lub też źle rozum iane oszczędności);
Realizacja przedsięwzięć informatycznych - fakty i mity 13
♦ spraw y polityczne (na różnych poziom ach: od poszczególnych grup osób, poprzez działy, zarząd firm y i na tzw. rozw iązaniach korporacyjnych skończywszy).
W wyniku przedsięwzięcia pt. wybór system u inform atycznego (powinno to być przedsięwzięcie, a w ięc powinno mieć: zakres, czas realizacji i budżet, nie m ówiąc już o w yraźnej strukturze realizacyjnej) negocjow any i podpisyw any jest kontrakt, w którym to procesie również kryją się określone pułapki [6]:
♦ zw ykle kontrakty pozw alają dostawcy na „w ygodne” życie - klient jest zobow iązany do regularnego płacenia faktur, najlepiej z góry;
♦ klient je st zachęcony (i zwykle poddaje się temu - nie ma w szak szczegółowej analizy w ym agań, a więc i argum entów ) do „przew ym iarow anego” (tj. na wyrost czy też najgorszy w ypadek) nabycia licencji na oprogram ow anie; płaci więc więcej niż potrzeba;
♦ w harm onogram y wpisyw ane są rozkładu płatności nieproporcjonalne do dostarczonych usług; zwykle duże płatności na początku, kiedy front prac jest niewielki a znacznie mniejsze na końcu, tj. w trakcie wdrożenia;
♦ zbyt m ały zakres szkolenia, podobnie ja k zakres konsultacji (dostawca nie jest w zasadzie zainteresow any konsultacjam i dla klienta, stara się w ięc wyłączyć zapisy o nich z kontraktu, np. poprzez zawyżanie ceny konsultacji);
♦ zbyt ogólne (a w ięc niejednoznaczne w późniejszej interpretacji) zakresy i harm onogram y prac (po części je st to skutek om ów ionych ju ż problemów, zw iązanych z projektam i inform atycznym i: niewidzialności, unikalności i braku miar);
♦ płatności za usługi zdefiniow ane w sposób „otw arty” , tzn. wg formuły:
„tim e& m aterial” , bez należytej kontroli ze strony klienta realności potrzeb i wkładu pracy.
1 .4 . Za g r o ż e n i a n a e t a p i e r e a l i z a c j i p r o j e k t u
Na etapie realizacji przedsięwzięcia w drożeniow ego na zespół klienta (a także i dostawcy SI) czyha cały szereg zagrożeń.
Zagrożenia te pochodzą z zew nątrz zespołu realizującego projekt, ja k też są skutkiem niew łaściw ego nim zarządzania. O lbrzym im problem na tym etapie jest zbyt
mate zaangażow anie kierownictwa przedsiębiorstwa, brak um ocow ania projektu na wysokim poziom ie (sprowadza się to do braku zaangażow anego sponsora projektu, pochodzącego z kierownictwa). Poważnym zew nętrznym zagrożeniem dla przedsięw zięć inform atycznych jest też zbyt m ały zakres zm ian organizacyjnych, dokonyw anych bezpośrednio przed w drożeniem SI. Do problem ów o m ieszanym źródle pochodzenia zaliczyć można:
♦ przyjęcie tzw. „szybkich ścieżek” wdrożenia, oferowanych przez firm y-dostaw cy system ów;
♦ nierealistyczne harm onogram y (zwykle narzucone przez kierow nictw o firmy, które po bardzo długim procesie decyzyjnym „czy i co kupić” , chce mieć natychm iastow e efekty);
♦ zbyt mały budżet (oszczędności!!!) lub jego brak („zrobicie to w ramach obow iązków służbowych).
Jeśli do powyższych problem ów dołączą się te typowe, zw iązane z zarządzanie projektem:
♦ brak energicznego (tj. zaangażow anego) kierownika projektu,
♦ brak dośw iadczenia konsultantów lub zbyt słabe ich kwalifikacje,
♦ brak audytu procesu w drożenia (w tym i pom iarów w yników prac),
♦ niedostateczne dokum entow anie prac, ustaleń i uzgodnień,
♦ brak system u w prow adzania zmian i popraw ek do system u,
to realizacja takiego przedsięwzięcia je st silnie zagrożona i projekt potwierdzi ju ż przytaczane statystyki.
W łaściwa organizacja przedsięwzięcia w drożeniow ego w ym aga zatem wysiłku z obu stron. W ysiłek ze strony odbiorcy sytemu je st zwykle w iększy - to on bowiem de facto ma w ykonać w iększość pracochłonnych i odpow iedzialnych prac: od zdefiniow ania celów przedsięwzięcia, poprzez analizę własnej organizacji i określenie w ym agań szczegółowych w stosunku do procesów, przetw arzań i dokum entów a w końcu to on wprowadza, w eryfikuje dane do system u inform atycznego. Dostawca system u jedynie w spom aga swojego klienta w iedzą o system ie i dośw iadczeniem z innych w drożeń, dostarcza konsultantów i czuwa nad te chniczną (a w ięc zwykle najprostszą stroną przedsięwzięcia). Projekt w drożeniow y to projekt obu stron.
Powinno to znaleźć odwzorowanie w strukturze organizacyjnej przedsięw zięcia (rys.
1.2).
Realizacja przedsięwzięć informatycznych - fakty i mity 15
K om ite t ste ru ją cy
J
K ie row n ik K om ite t w yko na w czy K ie ro w n ik
r “N
Z e s p ó ł klienta Z espó ł
d o s ta w c y
Rys. 1.2. Klasyczny schemat organizacyjny przedsięwzięcia wdrożeniowego
1 .5 . Mi t y w r e a l i z a c j i p r z e d s i ę w z i ę ć i n f o r m a t y c z n y c h
Zagrożeniem dla procesu wyboru i zakupu system u inform atycznego je st szereg mitów, pokutujących wśród inform atyków [6]:
♦ należy analizow ać maksymalna^ ilość SI i ich cech (skutek: rozciągnięcie do nieskończoności procesu wyboru systemu),
♦ kupiony SI od razu nadaje się do eksploatacji (skutek: brak zaplanow anych zasobów na prace dostosowawcze),
♦ im więcej funkcji tym lepiej (skutek: płacim y za w szystkie, a w ykorzystujem y 10%),
♦ najnowsza wersja jest najlepsza (skutek: jesteśm y „królikiem dośw iadczalnym ” testującym nowe wersje),
♦ standardow e um ow y s ą nienegocjow alne (skutek: przepłacam y, m am y gorsze w arunki serwisu itp.),
♦ zawsze m ożna w prow adzić „drobne” poprawki do system u (skutek: poprawki dużo kosztują i długo trwają),
♦ lepiej zaw rzeć kontrakt tylko z je d n ą firm ą (tzw. integratorem SI) (skutek:
przepłacam y - integrator nie w ynegocjuje cen lepiej od nas).
Inform atyk realizuje przedsięwzięcia w bardzo trudnych w arunkach. S ą to bardzo często projekty wewnętrzne, których organizacja często odbiega od m odelowego sposobu realizacji przedsięwzięć. Cele są mętne, zakres prac niedookreślony, zespól płynny, zdem otyw ow any, o rozm ywających się zakresach odpow iedzialności, kierownik projektu ubezw łasnow olniony decyzjam i szefów, bez budżetu, pod presją czasu. Jest za to w ym agający użytkownik, który nie zaw sze chce w drażanego system u, często ma nastawienie negatywne i roszczeniowe.
W tych warunkach pozostaje jedno. Trzeba za w sze lką cenę zorganizow ać przedsięw zięcie ściśle wg zasad zarządzania projektam i i starać się je realizować w praktyce. Zm niejszym y tym samym praw dopodobieństw o porażki.
Li t e r a t u r a
1. A dam czew ski P.: Zintegrow ane system y inform atyczne. MIKOM, W arszawa, 1998.
2. Capers J.: A pp lie d Software M easurem ent: A ssuring P roductivity an d Quality.
2nd ed., McGraw-Hill, 1996.
3. Cegieła R., Zalewski A.: R acjonalne zarządzanie p rzedsięw zięcia m i inform atycznym i i system am i kom puterowym i. Nakom, Poznań, 2000.
4. Inżynieria oprogram ow ania w projekcie inform atycznym . Pod red. G órskiego J., MIKOM, W arszawa, 1999.
5. Kisielnicki J., Sroka H.: S ystem y inform acyjne biznesu. Inform atyka dla zarządzania. Placet, W arszawa, 1999.
6. M aciejec L.: U warunkow ania organizacyjne w drażania system ów inform atycznych klasy M R P II w polskich przedsiębiorstw ach. W : Zintegrowane system y inform atyczne. IV Konferencja z cyklu: Kom puterow e system y w ielodostępne. Bydgoszcz, 17-19.09.1998. str. 227- 239.
7. M iłosz M., M iłosz E.: Rola inform atyka zakładowego. I K onferencja Inform atyk Zakładow y, Inform atyka Stosowana, nr S3/98, Kazim ierz Dolny, 28-29.05.1998, str. 63-70.
8. M iłosz M.: Ocena działań projakościow ych w firm ach inform atycznych.
Inform atyka, nr 3, 2000, str. 24-29.
9. Redmill F.: Software Projects: E volutionary vs. B ig-bang Delivery. John W iley
& Sons Ltd., 1997.
10. Szyjewski Zd.: Zarządzanie projektam i inform atycznym i. M etodyka tworzenia S ystem ów inform atycznych. Placet, W arszawa, 2001.
11. Yourdon E.: M arsz ku klęsce. P oradnik dla projektanta system ów. WNT, W arszaw a, 2000.
2
Z arząd zan ie ryzykiem w przedsięw zięciu ___________ inform atycznym
Jedną z w łaściw ości przedsięw zięć inform atycznych jest niepewność, która wynika z now atorskiego charakteru realizowanych system ów. Synergia zjawisk w ystępujących w procesie tw orzenia system u, stwarza duże zagrożenie niepowodzenia całego przedsięwzięcia. W literaturze podaje się różne określenia ryzyka, m.in.:
• ryzyko - jako zobiektyw izow ana niepew ność w ystąpienia niepożądanego zdarzenia;
• ryzyko - jako m ożliw ość w ystąpienia niechcianej sytuacji, której urzeczyw istnienie może w płynąć na obniżenie poziomu sukcesu (łącznie z całkowitym brakiem sukcesu);
• ryzyko - jako miara praw dopodobieństw a zaistnienia niezadow alającego rezultatu, w pływ ającego na projekt, proces lub produkt (Software Engineering Institute);
• ryzyko - jako szansa jakiegoś wydarzenia, którego urzeczyw istnienie będzie miało negatyw ny w pływ na realizację zam ierzonego celu.
Ryzyko je st w ięc niepożądanym zdarzeniem , które może negatywnie w płynąć na realizację przedsięwzięcia. W celu zm inim alizow ania negatywnych- skutków oddziaływ ania lub wyelim inow ania potencjalnego zagrożenia należy zarządzać ryzykiem w projekcie. Zarządzanie może być w ielokierunkow e a efekty jego bardzo różne w skutkach dla działań projektowych.
2 . 1 . Ok r e ś l e n i e r y z y k a
Niezależnie od przyjętego określenia ryzyka w ramach pełnego opisu zagrożeń pow inny zostać uwzględnione następujące elementy:
• zakres - określenie przedsięwzięcia, w kontekście którego definiujem y elem ent ryzyka;
• zagrożenie - opis niechcianej sytuacji w kontekście zakresu;
• skutki - opis skutków m aterializacji zagrożenia, uzasadniający dlaczego jest ono niechciane;
• czynniki ryzyka - opis (w ramach przyjętego zakresu) sytuacji wyjściowej, w zględem której oceniana je st szansa w ystąpienia zagrożenia, z jaw nym w skazaniem obecnych w niej oraz potencjalnych czynników ryzyka;
• szansa w ystąpienia - oszacowanie szansy m aterializacji zagrożenia, przy założeniu określonej sytuacji w yjściowej i jej kontynuacji;
• ekspozycja w czasie - określanie czasu, zw iązanego z e kspozycją na ryzyko;
• powiązania - określenie efektu, jaki będzie miało w ystąpienia danego zagrożenia na inne zagrożenia.
Podejm owanie ryzykownych decyzji może doprow adzić do katastrofalnych skutków, ale z drugiej strony zawsze idzie w parze z zyskiem (rys. 2.1).
► Ryzyko
Rys. 2.1. Relacja między zyskiem a ROI (Return on Investment) [1]
Zarządzanie ryzykiem w przedsięwzięciu informatycznym 1 9
Zwrot z inwestycji inform atycznych nie daje się łatw o policzyć i do kierow nika projektu należy znalezienie takiego punktu na krzywej, obrazującej relacje m iędzy ryzykiem a ROI (Return on lnvestem ent), aby pogodzić podejm owane ryzyko z osiąganym i zyskami. Dodatkowym utrudnieniem w prawidłowym szacow aniu ryzyka jest perspektywa czasowa, gdyż działania podejm owane w oczekiw aniu szybkich zysków będą różnić się od działań zakładających długi okres zwrotu.
Można w yróżnić następujące źródła ryzyka:
• w ew nętrzne - spow odow ane w łaściw ościam i projektu, który jako przedsięw zięcie nowatorskie obarczone je st m niejszym lub w iększym ryzykiem;
• narzucone - uwarunkow ania realizacyjne projektu, do których zaliczyć m ożem y uwarunkow ania technologiczne, kosztowe czy term iny realizacji;
• w prow adzone - będące w ynikiem niedostatecznej w iedzy czy zaniedbań w działaniu kierownika projektu oraz zespołu wykonaw czego.
Niezależnie od tego, jakie je st źródło ryzyka należy dążyć do jego ograniczenia, poprzez analizę czynników ryzyka i podejm ow anie odpow iednich działań zapobiegawczych.
Do najczęściej wym ienianych czynników ryzyka zaliczyć m ożemy:
• nieodpowiednia^ ocenę sytuacji początkowej (m.in. um iejętności w ykonaw ców czy uwarunkowań realizacyjnych);
• niedośw iadczenie i brak odpow iednich kwalifikacji członków zespołu wykonawczego;
• brak ekspertów, którzy mogliby służyć radą w sytuacjach kryzysowych;
• czynniki zew nętrzne realizacji projektu (sytuacja prawna, gospodarcza, polityczna itd.);
• szybkie zm iany w otoczeniu projektu i technologii inform atycznej - zwłaszcza przy projektach z długim harm onogram em działania;
• duże rozm iary projektów inform atycznych, które m ogą stać się przyczyną przekroczenia dopuszczalnych granic czasu realizacji, budżetu lub stopnia spełnienia oczekiw ań odbiorców;
• szybki rozrost zespołu projektowego, który m oże prow adzić do w ielu problem ów organizacyjnych i kom unikacyjnych w zespole;
• korzystanie z usług podw ykonaw ców w części zadań projektowych, co uniem ożliw ia spraw ow anie bezpośredniego nadzoru nad realizacją powierzonych zadań;
• rozproszenie geograficzne w ykonaw ców i odbiorców, co m oże doprow adzić np.
do opóźnień dostaw;
• w ysokie wym agania dotyczące efektywności obliczeniowej czy niezawodności działania system u inform atycznego, które jednak s ą trudno m ierzalne przed ukończeniem prac;
• duża zm ienność wym agań w trakcie realizacji projektu;
• brak wsparcia projektu ze strony wyższych szczebli zarządzania, utrudniające lub uniem ożliw iające w drożenie w łaściwych rozwiązań organizacyjnych oraz egzekw ow ania podjętych zobowiązań;
• niew łaściw e przygotow anie w arunków do realizacji produktu (tzw. zbudowanie infrastruktury projektu, obejm ującej zasady organizacji pracy, dokum entow ania prac, przechow yw ania i uaktualniania wyników prac, przypisanie odpow iedzialności i praw dostępu, zasady spraw ozdaw czości na temat postępów projektu i pojawiających się problem ów);
• nie zagw arantow anie odpowiedniej struktury finansow ania projektu, zgodnej z jego potrzebam i, co może doprow adzić do opóźnień w skutek chwilowych braków środków finansowych;
• tzw. "siła wyższa" czyli zdarzenia, na które nikt nie ma wpływu, związane z katastrofam i lub innymi nieprzew idyw alnym i zjawiskam i.
Czynniki ryzyka ulegają zm ianie w raz z postępem prac projektowych. Inne czynniki są. istotne w początkowej fazie realizacji, a inne zaś na dalszym etapie prac.
Szczególnie ważne jest prawidłowe przygotowanie działań zarów no od strony m erytorycznej, jak i organizacyjno - prawnej. Analiza czynników ryzyka służy sform ułowaniu prognoz i ocenie praw dopodobieństw a sukcesu projektu w przew idyw anych w arunkach realizacji. Ma ona na celu przygotow anie działań zapobiegaw czych, ukierunkow anych na m inim alizację ryzyka realizacji projektu.
Nadrzędnym celem zarządzania ryzykiem jest utrzym anie odpowiedniego stopnia gw arancji odnośnie sukcesu interesującego nas przedsięwzięcia.
Proces zarządzania ryzykiem obejm uje 4 pow tarzające się fazy [4]:
Zarządzanie ryzykiem w przedsięwzięciu informatycznym 2 1
• identyfikow anie ryzyka - polega na określeniu i dokum entow aniu, jakie zdarzenia m ogą być niepom yślne dla realizowanego projektu;
• ocena zidentyfikow anego zagrożenia - polega na szacowaniu praw dopodobieństw a w ystąpienia negatywnego zdarzenia i jego negatywnych skutków dla projektu;
• zapobieganie - działania te zmierzają^ do przygotow ania odpow iedniego planu zapobiegaw czego;
• m onitorow anie - polega na odnoszeniu w szystkich działań do dokonanych ocen i kontrolow aniu zm ienności poczynionych szacunków.
Janusz Górski w pracy [2] wyodrębnia 6 obszarów działań objętych zarządzaniem ryzykiem:
• ocena ryzyka:
•2 identyfikacja - obejm uje wykryw anie zagrożeń, które mogat m ieć w pływ na sukces projektu;
S - analiza - polega na ocenianiu praw dopodobieństw a ryzyka oraz zw iązanych z nim rozm iarów strat;
• obniżanie ryzyka:
^ - planowanie - obejm uje w ykorzystanie inform acji o ryzyku w decyzjach określających działania łagodzące skutki zagrożeń, elim inowanie zw iązanych z nimi czynników ryzyka, a także ustalanie priorytetów planow anych działań oraz ich integrację w ramach planu zarządzania ryzykiem;
s nadzorow anie - obejm uje śledzenie postępu projektu pod kątem oceny znaczenia poszczególnych zagrożeń oraz - w miarę konieczności - inicjowanie akcji naprawczych;
s sterow anie - obejm uje korygowanie odchyleń od planowanych działań elim inujących lub obniżających ryzyko przy użyciu procedur zarządzania projektem ;
s kom unikacja - obejm uje w ym ianę inform acji o ryzyku na różnych poziom ach organizacji.
Działania te należy pow tarzać cyklicznie w całym cyklu życia projektu, gdyż zm ieniają się warunki, a w raz z nimi praw dopodobieństw o wystąpienia negatywnych zdarzeń i w ysokość szacow anych strat. Niektóre zagrożenia m ogą przestać być aktualne, ale
również m ogą pojawić się nowe czynniki ryzyka. Stałe kontrolow anie ryzyka w projekcie należy do kierownika projektu.
2 . 2 . Id e n t y f i k a c j a r y z y k a
Pierwszym etapem zarządzania ryzykiem jest rozpoznanie zagrożeń, które m ogą mieć negatywny w pływ na realizację projektu. Po określeniu zauw ażonych zagrożeń należy w yznaczyć priorytety obow iązujące przy dalszych pracach, które jednak m ogą być m odyfikow ane w trakcie analizy zdarzeń. Identyfikacja ryzyka w projekcie powinna być w ykonyw ana cyklicznie, ale najistotniejsze je st w stępne określenie zagrożeń. Bardzo ważne je st zdobycie w iedzy na tem at celów projektowych, która pozwoli na przyjęcie odpowiednich rozwiązań technicznych, term inów realizacji oraz w yznaczenie strategii w spółpracy uczestników procesu projektowego. W fazie wstępnej podstaw ą analiz powinny być zagrożenia celów biznesowych, związane:
• z powodzeniem projektu inform atycznego,
• ze spodziew anym zyskiem,
• z uzyskaniem satysfakcji klienta.
Podstawowym sposobem identyfikacji zagrożeń w projekcie s ą specjalnie organizow ane sesje identyfikacji ryzyka czyli form alne spotkania, warsztaty, na których uczestnicy określają potencjalne zagrożenia za pom ocą różnych technik i narzędzi identyfikacji.
Przy identyfikacji zagrożeń zalecane s ą dwa w zajem nie uzupełniające się podejścia:
• analiza zstępująca, polegająca na przeglądaniu list kontrolnych, zaw ierających spis potencjalnych zagrożeń i odnoszenie tych zagrożeń do obecnej sytuacji;
• analiza wstępująca, która polega na ocenie obecnej sytuacji i w skazaniu jej (m ożliw ych) negatywnych skutków w przyszłości.
Proces identyfikacji je st szczególnie ważny, poniew aż pozwala poddać analizie w szystkie aspekty i obszary oddziaływania. N iedokładne analizy mogat mieć poważne konsekw encje w trakcie realizacji projektu.
Zarządzanie ryzykiem w przedsięwzięciu informatycznym 2 3
2 .3 . Oc e n a (a n a l i z a) r y z y k a
Po identyfikacji ryzyka należy ocenić praw dopodobieństw o jego w ystąpienia oraz oszacować w ysokość potencjalnych strat. Analizę tę należy prowadzić, badając łącznie oddziaływ anie różnych czynników ryzyka, a nie w ystąpienie jednego niepożądanego zdarzenia, poniew aż zidentyfikow ane zagrożenia m ogą się wzajem nie w ykluczać, bądź też w pływ ać na siebie wzajem nie. Zagrożenia m ogą mieć różny zasięg oddziaływ ania. Niektóre mogat m ieć w pływ na cały projekt, natom iast inne oddziałują tylko na konkretne zadania z listy prac projektowych. W zw iązku z tym ocena ryzyka powinna być w ięc w ielow ariantow a i powinna być prow adzona zarówno dla całego projektu, jak i indywidualnie, dla poszczególnych obszarów i zadań projektowych. P odstaw ą oceny ryzyka je st typ realizow anego projektu i tolerancja klienta.
P odstaw ą szacow ania ryzyka s ą plany projektu, harm onogram y czasowo- zasobowe oraz inne dokum enty i w yliczenia w ykonane na potrzeby przeprow adzania prac projektowych, a także w iedza i dośw iadczenia kierownika projektu oraz zgrom adzone dane historyczne.
Istotnym problem em w ocenie ryzyka jest jego szacowanie. W zależności od wagi danego zagrożenia dla całego projektu stosowane są różne m iary ryzyka, od bardzo prostych ocen (czy ryzyko jest wysokie, średnie czy niskie), do dokładnych w skaźników w yrażonych jako praw dopodobieństw o w ystąpienia danego zdarzenia.
Tablica 2.1. Miary ryzyka
Bardzo wysokie Pewne
WYSOKIE Bardzo
R Wysokie Prawdopodobne
Y
Z ŚREDNIE Średnie Prawdopodobne
Y
K Niskie
O Mało prawdopodobne
NISKIE
Bardzo niskie
Nieprawdopodobne
Drugim w ażnym param etrem w ocenie ryzyka je s t w ysokość potencjalnych strat zw iązanych z w ystąpieniem niepożądanego zdarzenia. Do oceny poziom u ryzyka dla projektu może być w ykorzystana m acierz poziomu ryzyka.
Tablica 2.2. Macierz poziomu ryzyka
Straty
Wysokie Średnie Niskie
Prawdopodobieństwowystąpienia
Bardzo wysokie
Bardzo wysokie Wysokie Średnie
Wysokie Wysokie Wysokie Średnie
Średnie Wysokie Średnie Średnie
Niskie Średnie Średnie Niskie
Bardzo niskie
Średnie Średnie Niskie
W praktyce w ykorzystać m ożna również miarę kosztow ego szacow ania ryzyka, w edług wzoru:
S = p * K gdzie:
S - w artość potencjalnych strat,
p - praw dopodobieństw o w ystąpienia zdarzenia,
K - szacow any koszt poniesionych strat w przypadku zaistnienia zdarzenia.
Model ten ma zastosow anie do szacowania poziomu ryzyka dla określonego zdarzenia. Pozostaje problem szacowania ryzyka łącznego dla całego projektu, który w praktyce jest rozw iązyw any za pomocą^ następujących metod:
• analizy sieciowe,
• drzewa zdarzeń,
• listy kontrolne,
• m etody punktow e w analizie ilościowej,
• m etody eksperckie.
Zarządzanie ryzykiem w przedsięwzięciu informatycznym 2 5
Stosowanie tych metod w ym aga odpow iedniego dośw iadczenia i dobrze przygotowanych procedur postępowania. Z aletą tych m etod je st próba ujęcia danych z wielu dziedzin w spójną całość, stanow iącą podstawę oceny wpływu poszczególnych zagrożeń na inne działania projektowe.
2 .4 . Za p o b i e g a n i e r y z y k u
Dokonanie oceny ryzyka um ożliwia jedynie odpow iednie uszeregowanie zidentyfikowanych zagrożeń w sensie ich w ażności i wpływu na projekt. Kolejnym krokiem je st natom iast zaplanow anie działań zapobiegaw czych, m ających na celu wyelim inow anie zagrożeń lub znaczące zm niejszenie ich w pływu na projekt. W szelkie działania zapobiegaw cze łą czą się z dodatkowym nakładem pracy, dlatego też należy ocenić także ich koszty i przeprow adzić analizę potencjalnych strat w zestawieniu z kosztami. Ponoszenie zbyt wysokich kosztów na m inim alizację ryzyka jest ekonom icznie nieuzasadnione, gdyż w pewnym mom encie moga„ one przekroczyć w artość potencjalnych strat.
W stosunku do zidentyfikow anych zagrożeń można rozpatryw ać następujące strategie postępowania:
• obniżenie ryzyka polega na zm niejszeniu praw dopodobieństw a i/lub skutków zagrożenia;
• uniknięcie ryzyka polega na wyelim inow aniu m ożliwości m aterializacji danego zagrożenia poprzez w ybór drogi alternatywnej:
• transfer ryzyka oznacza spowodowanie, że ktoś inny w spółuczestniczy lub przejm uje ryzyko na siebie (np. firma ubezpieczeniowa);
• zaakceptow anie ryzyka polega na zaplanowaniu działań aw aryjnych oraz śledzeniu ryzyka i w drożeniu planu awaryjnego w sytuacji, gdy ryzyko przerodzi się w problem.
W praktyce stosow ane są różne metody zm niejszania lub unikania ryzyka projektu.
Do najczęściej stosow anych zaliczam y:
• rezygnację z najbardziej ryzykownych działań;
• podział projektu na części i rozdzielenie odpow iedzialności za bardziej ryzykow ne zadania m iędzy różne osoby;
• próby poszukiw ania innego rozwiązania, które ograniczy lub wyelim inuje zidentyfikow ane ryzyko, np. zakup gotowego oprogram ow ania zamiast opracow ania nowego produktu;
• odpow iednie przygotowanie w arunków um owy i zam ieszczenie w niej klauzul dotyczących identyfikacji obszarów ryzyka;
• stosow anie w zorców i spraw dzonych rozwiązań;
• bardzo precyzyjne zdefiniowanie kontraktu na realizację projektu.
Mimo zastosow anych metod zm niejszania ryzyka, w artość zagrożeń może przekroczyć pew ną zdefiniow aną w artość graniczną, po przekroczeniu której należy podjąć akcje naprawcze. Z tego powodu istotne jest w cześniejsze przygotowanie planu aw aryjnego, który powinien obejm ować:
• określenie istoty potencjalnego problemu,
• rozważenie alternatywnych sposobów rozw iązania problemu,
• określenie ograniczeń, w ramach których problem będzie rozw iązywany,
• analizę alternatyw nych rozwiązań,
• w ybór jednej z alternatyw.
Plan postępow ania awaryjnego powinien zawierać:
• identyfikację zagrożeń, których plan dotyczy,
• m etodę śledzenia ryzyka zw iązanego z tymi zagrożeniam i,
• przypisanie odpow iedzialności za śledzenie ryzyka i realizację planu,
• warunki uruchom ienia planu,
• przydział zasobów do wykonania planu,
• ograniczenia związane z opracow aniem planu.
2 . 5 . Mo n i t o r o w a n i e r y z y k a
W związku ze zmiana^ w arunków w trakcie realizacji projektu, ryzyko w ym aga stałego m onitorowania. Proces ten powinien rozpocza„ć się bezpośrednio po podpisaniu kontraktu m ieć charakter ciągły, realizowany zgodnie z planem zarzatdzania ryzykiem.
Zarządzanie ryzykiem w przedsięwzięciu informatycznym 2 7
M onitorowanie ryzyka można realizow ać na dwa sposoby:
• reaktywnie - polega na identyfikowaniu problem ów po jego w ystąpieniu i ustaleniu sposobu reagowania; dopiero gdy zaistnieje negatyw ne zjawisko, podejm owane s ą działania, które m ają na celu zm inim alizow anie jego skutków;
• aktywnie - polega na przewidywaniu, jakie negatywne zdarzenia m ogą w ystąpić i przeciwdziałaniu im, zanim wystąpią; podejście to zakłada regularne opracow anie prognoz i kontrolow anie ich poprawności, co pozwala na bieżąca^
ocenę ryzyka i analizę dotychczasow ych działań.
Skuteczność zarządzania ryzykiem w zasadniczy sposób zależy od efektywnej komunikacji pom iędzy zainteresow anym i stronam i. Kom unikacja m iędzy kierownikiem projektu a klientem czy kom itetem sterującym powinna m ieć charakter form alny.
W przypadku rozpoznania nowego zagrożenia i po dokonaniu jego oceny, kierownik powinien form alnie poinform ow ać o tym fakcie i przedstaw ić plan działań zapobiegawczych. Efektywna kom unikacja na tem at ryzyka w znacznym stopniu zależna jest od ludzi i ich zachowań.
W celu ich opisania rozróżnia się w literaturze zachowania:
• utrudniające kom unikację (czyli zachow ania niepożądane z punku widzenia kom unikacji o ryzyku),
• sprzyjające kom unikacji na tem at ryzyka.
Stała obserw acja projektu i jego otoczenia, grom adzenia doświadczeń, poprawne przewidywania, ciągłe w yszukiw anie zagrożeń, aktywna w spółpraca z zespołem i efektywna kom unikacja gw arantują sukces projektu i sprzyjają m inim alizacji ryzyka projektu.
2 .6 . Zn a c z e n i e r y z y k a w z a r z ą d z a n i u p r o j e k t e m i n f o r m a t y c z n y m
Zarządzanie ryzykiem powinno w chodzić w zakres zarządzania projektem i stanowić jego istotną część. Polega to na śledzeniu tych czynników ryzyka, które uznam y za najważniejsze. W zależności od przyjętej metodyki realizacji projektu i zarządzania nim, są różne sposoby podejścia do zarządzania ryzykiem. Każda m etodyka problem ten wym ienia jako jedno z istotnych działań realizacji projektu inform atycznego.
Należy skupić się na kilku głównych czynnikach, zw iązanych z najw iększym ryzykiem i takich, na które m ożem y stosunkow o łatw o wpływać.
Podejście to obejm uje następujące działania:
• w yselekcjonow anie głównych zagrożeń w projekcie,
• identyfikacja najważniejszych czynników ryzyka,
• ustanow ienie planu regularnych przeglądów postępu projektu,
• dokonyw anie przeglądów, w trakcie których koncentruje się na planowaniu działań oraz rozwiązywaniu problem ów i usuwaniu trudności w działaniach zw iązanych z usuwaniem lub obniżaniem wpływu poszczególnych czynników ryzyka oraz ustaleniu nowej listy najw ażniejszych czynników ryzyka.
Ryzyko je s t nieodzownym elem entem realizacji każdego projektu inform atycznego, dlatego też istotnym problem em staje się usuwanie lub obniżaniu wpływu czynników ryzyka na przedsięwzięcie. Skuteczne zarządzanie ryzykiem je st w dużej mierze działalnością^ grupowa^, w ym agającą stałych kontaktów, silnie uzależnioną od relacji m iędzyludzkich w ramach danej organizacji. Duże znaczenie odgryw a odpowiednia identyfikacja i ocena ryzyka, która um ożliwia następnie podjęcie z wyprzedzeniem odpow iednich działań oraz opracow yw ania planów awaryjnych.
Li t e r a t u r a
1. Hayes R., A bernathy W. J.: M anaging O ur W ay to E conom ic Decline, Harvard Business Review, July-Aug., 1980
2. Inżynieria oprogram ow ania w projekcie inform atycznym . Pod red. J. Górskiego, MIKOM, W arszawa, 1997.
3. M achała W.: M etodyka oceny ryzyka w przedsięw zięciach inform atycznych.
Instytut System ów Inform atycznych WAT.
4. Szyjew ski Z.: Zarządzanie projektam i inform atycznym i. M etodyka tworzenia system ów inform atycznych. Agencja W ydaw nicza Placet, W arszaw a, 2001.
3
O rganizacja szkoleń w procesach w d rożenio w ych
Działania szkoleniow e dia przyszłych użytkow ników system u przew iduje się zazwyczaj jako rutynowy elem ent procesów w drożeniow ych, dow olnych system ów inform atycznych. W okół tych szkoleń narasta jednak w iele nieporozum ień. Firmy będące odbiorcam i w drożeń w ym agają w prawdzie od dostaw ców (system ów lub usługi w drożeniow ej) realizacji szkoleń, jednak nie we w szystkich przypadkach szkolenia te s ą pozytywnie oceniane przez osoby, które w nich uczestniczą, a ponadto nie zaw sze efektem szkoleń je st odpow iednie przygotowanie użytkowników do pracy z systemem. W śród praktyków (użytkow ników ) m ożna nawet usłyszeć opinie, że szkolenia w drożeniow e to strata czasu, bo i tak pracownicy będą uczyć się korzystania z system u ju ż podczas jego bieżącej eksploatacji. Firmy wdrażaja^ce także nie akcentują istotności szkoleń w całym ciągu działań w drożeniowych uznając, iż w łaściw e przygotowanie użytkow ników leży w interesie odbiorcy usługi, a m obilizacja do szkolenia własnych pracowników je st łatwiejsza dla pracodawcy, niż firm y zewnętrznej.
Szkolenia są zatem form alnie odbywane, działania s ą dopełnione w zgodzie z podpisanym i um owam i, ale efekty często istotnie odbiegają od oczekiwań.
Uczestnictwo w szkoleniach bywa traktow ane jako form alność, nierzadko szkolenia
"przeszkadzają" pracow nikom w realizacji bieżących zadań, a kierownicy bez oporów odwołujat swych pracowników ze szkoleń, gdy tylko pojaw ią się jakieś bieżące problemy. Szkolenia tow arzyszące w drożeniom często nie s ą pozycją odrębnie kalkulow aną i opłacaną, stanow ią bowiem kom ponent usługi w drożeniow ej. Firmy wdrażające często deklarują, że szkolenia to dodatkowa usługa, za którą klient nie ponosi dodatkow ych kosztów. Słowem klienci m ogliby korzystać ze szkoleń w oczekiw anym przez siebie zakresie. Paradoksalne jest jednak to, iż zazwyczaj
klienci wcale nie nadużywaja^ tego "przywileju", w ręcz przeciw nie uczestniczą w szkoleniach niejako dla form alności.
Zarazem jednak, obserw ując wdrożenia w wielu firm ach, m ożna postaw ić tezę, że częstą przyczyną nieudanych lub nadm iernie w ydłużających się wdrożeń są źle przeprow adzone szkolenia. Jak zatem należy podejść do organizacji szkoleń, aby pośw ięcony na nie czas i nakłady (bo jednak szkolenia kosztują), przysparzał firmom oczekiwanych korzyści, a szkolenia były kreatywnym , a nie form alnym kom ponentem wdrożeń.
3 . 1 . Sp e c y f i k a p r o c e s ó w w d r o ż e n i o w y c h
W arto zauważyć, że w spółczesne w drożenia o d bieg ają znacznie od wdrożeń realizowanych na początku epoki pow szechnej kom puteryzacji m ikrokom puterowej, czyli w dekadzie lat 85-95. W ów czas w drożenia dotyczyły prawie w yłącznie prostych system ów ew idencyjnych. Podstawowym problem em z jakim borykali się ówcześni użytkow nicy komputerów, to opanow anie podstaw pracy na klawiaturze oraz um iejętność w ybrania i wskazania w łaściwych funkcji system u. Dziedzinowe podejście do budowy system ów powodowało ponadto, iż określony pracow nik (grupa pracow ników ) miała do swej dyspozycji system funkcjonalnie dedykow any do zadań, jakie każdy z tych pracowników w ykonyw ał uprzednio, korzystając z klasycznych (nie kom puterow ych) narzędzi przetwarzania danych. Szkolenia wdrożeniow e koncentrow ały się zatem na przekazaniu użytkownikom podstaw obsługi stanowiska kom puterow ego oraz na w yszkoleniu um iejętności sprawnej realizacji typowych zadań zw iązanych z w prow adzaniem i przeglądaniem danych oraz wyboru i w ykonania rutynowych zestawień. Bardziej złożone zadania obsługow e oraz definiowanie raportów "na żądanie" realizowane były ju ż przez inform atyków.
Pow odow ało to z jednej strony ograniczenie sam odzielności użytkowników, a z drugiej uzależnienie ich od służb inform atycznych.
Trzeba także podkreślić, że w praktyce gospodarczej jako "użytkow ników "
postrzegano w yłącznie pracowników poszczególnych działów lub komórek organizacyjnych, dla których przygotow yw ana była określona aplikacja inform atyczna.
Im plikacją takiego w ąskiego rozum ienie pojęcia "użytkow nik" powodowało, iż z w drożeniem związana była wyłącznie owa docelow a grupa pracowników,
Organizacja szkoleń w procesach wdrożeniowych 3 1
bezpośrednio zw iązanych z obszarem działania realizow anego system u informatycznego, a potrzeby inform atyzacyjne w yznaczane były poprzez fragm entaryczne analizow anie segm entu system u inform acyjnego. Zrozum iałe zatem było uczestnictwo w szkoleniach w yłącznie tej w ąskiej grupy pracowników.
W bieżącej praktyce liczba jednodziedzinow ych system ów dedykow anych system atycznie ulega zm niejszeniu, a ich m iejsce zajmujaŁ złożone system y powielarne, cechujące się m odularnością budowy i znaczną elastycznością użytkową.
Informatyka w coraz m niejszym zakresie służy biernem u odw zorow aniu stanu istniejącego, a w coraz w iększym zakresie je st narzędziem m odelowania i realizacji procesów biznesowych. Rola użytkownika w takich system ach ulega istotnej transformacji. Należy zatem zwrócić uwagę, iż obecnie pojęcie "użytkow nicy" musi być rozum iane znacznie szerzej i obejm ow ać faktycznie w ielu różnych pracowników (wiele grup pracowników), których praca w mniejszym lub w iększym zakresie wiąże się z obszarem objętym kom puteryzacją. M ożem y zatem w yraźnie w skazyw ać
"użytkowników bezpośrednich", czyli użytkow ników w dotychczasow ym rozum ieniu tego pojęcia i "użytkow ników pośrednich", którymi mogą. stać się faktycznie wszyscy pozostali pracow nicy danej firmy.
System y w drażane obecnie s ą całkow icie odmiennat g eneracją aplikacji.
Funkcjonalnie w ielodziedzinow e lub kom pleksowe, o znacznym poziom ie elastyczności, działające na zintegrow anych bazach danych, posiadają wiele poziomów agregacji informacji, kom unikują się z innymi system am i, w ym agają od użytkowników znacznie szerszej w iedzy inform atycznej, niż tylko um iejętność obsługi procedur w ejścia/w yjścia. U żytkownicy nie m ogą już być w yłącznie biernymi odtwórcami zadań ale m uszą w spółtw orzyć i rozwijać aplikacje inform atyczne.
W drożenie w firm ie nowej aplikacji SI, to konieczność zm ian organizacyjnych, proceduralnych i operacyjnych na różnych stanowiskach pracy. Tym czasem szkolenia tradycyjnie nadal koncentrują się zazw yczaj w yłącznie w okół zmian operacyjnych.
Dla wielu firm inform atyka staje się zarów no w ew nętrznym "system em nerwowym", jak i podstaw ow ym narzędziem kom unikacji z otoczeniem gospodarczym (klientam i, partneram i, konkurencją). W raz z rozwojem technologii inform atycznych następuje w prow adzanie aplikacji inform atycznych do kolejnych obszarów działalności firmy. A w podejm owaniu kolejnych przedsięw zięć
inform atycznych w yróżnić m ożna etapy sw oistego dorastania firm y do w łaściw ego w ykorzystania technologii inform atycznych (obrazuje to tab. 3.1). C hociaż R.Nolan zwrócił uwagę na tę praw idłow ość już w 1973 roku [5, s. 52], to nadal w iele firm (nie tylko krajow ych) znajduje się w tej skali rozwojowej pom iędzy etapam i czwartym - integracja, a piątym - orientacja na dane.
Owo dorastanie można ostatnio wyraźnie obserw ow ać w w ielu firm ach, co jest w ynikiem istotnego postępu w technologiach ICT's ( Inform ation an d C om m unication Technologies). To nowe technologie kom unikacji firm z klientam i i otoczeniem gospodarczym w ym usiły standaryzację procedur firm owych, czy tworzenie zintegrow anych baz danych.
Tablica 3.1. Etapy wzrostu poziomu komputeryzacji wg. R.Nolana
Lp- Etap Specyfika etapu
1. Inicjacja Wdrażane pojedyncze systemy cząstkowe. Wdrożenia realizowane są przez zespoły zewnętrzne. Użytkownik pozostaje bierny wobec zdefiniowanych funkcji systemu.
2. Popularyzacja Istnieje w firmie więcej niezależnych aplikacji. Obserwuje się ograniczony udział użytkowników w procesach wdrożeniowych.
3. Sterowanie / kontrola Podejmuje się planowanie informatyzacji firmy. Następuje standaryzacja stosowanej technologii.
4. Integracja Firma użytkuje wspólne bazy danych. Zostają uzgodnione międzysystemowe struktury danych. Pracownicy firmy podejmują zadania współtworzenia systemów.
5. Orientacja na dane Systemy informowania kierownictwa. Następuje integracja organizacji przez informatykę. Użytkownik inwentaryzuje i kontroluje posiadane zasoby informatyki.
6. Nasycenie Wspomaganie zarządzania strategicznego. SI funkcjonuje jako
„system nerwowy” organizacji.
Źródło: Opracowanie własne na podstawie [5, s. 52],
Należy jednocześnie podkreślić, że przejście w dorastaniu firm y do etapu szóstego - nasycenia sfery gospodarczej technologiam i inform acyjnym i - je s t zw iązane z istotnie odm iennym podejściem do procesów inform atyzacyjnych. Przykładem takiego podejścia je st model ITIM ( Inform ation Technology Investm ent M anagem ent) opracow any przez am erykański Główny Urząd Rachunkow ości (GAO - General A ccounting O rganisation) definiujący pięć poziom ów dojrzałości firm y do inw estow ania w technologie inform acyjne - por. rys. 3.1, przedstaw iony przez G.R.
Prochow skiego [4] na podstawie G A O /A IM D -10.1.23 (2000). Ten pięciopoziom ow y
Organizacja szkoleń w procesach wdrożeniowych 3 3
model obrazuje kolejne stadia uznawania inwestycji w technologie inform atyczne, jako coraz bardziej znaczące z punktu widzenia zarządzania strategicznego firmą.
Kolejne poziom y dojrzałości związane są zarazem z coraz dojrzalszą realizacją tych inwestycji.
P O Z IO M 5
K o n c e n tra c ja na ^ P e łn e s p r z ę ż e n ie b iz n e s u z IT c e la c h s tra te g ic z n y c h
1
i 1
i
P O Z IO M 4
U le p s z a n ie p r o c e s u in w e s t y c ji
P O Z IO M 3
K o m p le tn y p o r t f e l in w e s t y c ji
P O Z IO M 2
P o d s t a w y d o z a r z ą d z a n ia in w e s t y c ja m i
P O Z IO M 1 T w o rz e n ie ś w ia d o m o ś c i Ś w ia d o m o ś ć p ro je k to w a i in w e s t y c y jn e j
Rys. 3.1. Poziomy dojrzałości organizacji do inwestowania w technologie informacyjne Źródło: Opracowanie własne na podstawie [4, s. 17]
Przygotowanie użytkow ników do takiej aktywnej roli w procesach inform atyzacyjnych wymaga istotnie innego podejścia do szkoleń. Problem y decyzyjne w okół organizacji szkoleń w drożeniow ych dotykają następujących kwestii:
• Kogo należy szkolić?
• W jakim zakresie należy szkolić poszczególne grupy pracowników?
• Kiedy i ja k należy prowadzić szkolenia?
• Jak zapew nić efektyw ność szkoleń?
• Jakie sat najczęstsze błędy w organizacji szkoleń?
Musimy także uzm ysłow ić sobie, iż świadom e uczestnictw o pracowników w transform acji procesów biznesowych prowadzi, do stw ierdzenia, że adaptacyjność
staje się najw iększą w artością pracownika. Uznanie adaptacyjności, jako istotnego waloru osobistego m ożna w dynam icznych firm ach obserw ow ać ju ż obecnie, a należy oczekiwać, że potrzeba takich predyspozycji nasilać się będzie w najbliższych latach.
W ynika to z faktu iż:
• Rozwój nowych technologii powoduje potrzebę uzupełniania w iedzy co 3-5 lat;
• Z badań rynku pracy wynika, że co 7 lat w iększość osób musi zm ienić pracę;
• Średnio co 10 lat następuje zasadniczy zw rot w organizacji pracy;
• W iele firm przez wiele lat poddawanych jest kolejnym reorganizacjom i transform acjom .
W ym ienione czynniki stanow ią bez w ątpienia dodatko w ą m otyw ację do zwrócenia szczególnej uwagi na procesy szkoleniowe związane z w drożeniam i technologii inform acyjnych.
3 . 2 . Ad r e s a c i s z k o l e ń w p r o c e s a c h w d r o ż e n i o w y c h
Jeśli, ja k pow iedzieliśm y wdrożenie system u skutkuje zm ianam i w działaniach ogółu zatrudnionych, to ich wszystkich m ożem y postrzegać jako bezpośrednich lub pośrednich użytkowników. W drożenie (zwłaszcza system u zintegrow anego) dotyka faktycznie w szystkich pracow ników firmy. Nawet jeśli nie wiąże się to z bezpośrednim obsługiw aniem stanow iska kom puterowego, to w iększość z dotychczasow ych zadań realizowanych będzie nieco inaczej (np. zmienia^ się form ularze dokum entów, ustalone zostanaŁ inne zasady ich obiegu, zm ieni się tryb podejm ow ania decyzji lub zakres kom petencji poszczególnych pracowników).
Dla dalszych rozważań może być jednak pom ocne w yróżnienie (w dowolnej firmie) następujących kategorii użytkow ników system u inform atycznego:
A - kadra m enedżerska firm y (zarząd, dyrekcja itp.);
B - kadra zarządzająca średniego szczebla (np. kierownicy działów, departam entów, komórek);
C - bezpośredni użytkownicy system u, a w tym:
C1 - nie korzystający dotychczas z komputera;
C2 - dotychczas korzystający z komputera;
D - adm inistratorzy systemu.
