Strona główna

Kierunek informatyka I ekonometria


Pobieranie 310.82 Kb.
Strona12/12
Data18.06.2016
Rozmiar310.82 Kb.
1   ...   4   5   6   7   8   9   10   11   12

6.6. Przekazanie systemu do eksploatacji


Rysunek 11 Krok 6 – Przekazanie systemu do eksploatacji


W E J Ś C I E


  • System produktywny

  • Bieżące dane operacyjne





Przekazanie systemu do eksploatacji



W Y J Ś C I E



źródło: opracowanie własne


Ze względu na generalne doświadczenie w obsłudze systemu, zaufanie do niego oraz inne uwarunkowania wyróżnia się trzy metody przejścia na nowy system.

  • Eksploatacja równoległa. Zwolennicy metody równoległej eksploatacji systemu wykorzystywanego do tej pory i nowego argumentują, że pomimo wysiłku włożonego w fazy prototypowania, modelowania i testowania zdarza się, że przeoczono coś istotnego. Dzięki równoczesnemu wykorzystaniu dotychczasowych metod pracy ciągłość funkcjonowania przedsiębiorstwa zostaje zachowana.



Rysunek 12 Eksploatacja równoległa


źródło: MCS (Manufacturing Control Systems Ltd.) Implementation methodology MAXIM



  • „Big Bang”. Najbardziej radykalna metoda przejścia polegająca na nagłym porzuceniu starych sposobów pracy i przejście na nowy system. Jedną z największych zalet tej metody jest presja psychologiczna wywierana na wszystkich przyszłych użytkowników uruchamianego modułu, którzy mając na uwadze brak „okresu ochronnego” realizowania czynności równocześnie na stary i nowy sposób z większą odpowiedzialnością podchodzą do procesu projektowania, weryfikacji i zatwierdzenia wprowadzonych rozwiązań. Kolejną zaletą jest również oszczędność czasu i uwagi której wymagałaby realizacja tych samych zadań w dwóch systemach.

Rysunek 13 „Big Bang”

źródło:MCS (Manufacturing Control Systems Ltd.) Implementation methodology MAXIM



  • Metoda wybranego produktu lub funkcji. Polega na wyznaczeniu produktu, czy funkcji biznesowej której rejestracja odbywa się tylko w nowym systemie.

Rysunek 14 Eksploatacja pilotowa




źródło:MCS (Manufacturing Control Systems Ltd.) Implementation methodology MAXIM


Znane są przypadki zarówno pomyślnych jak i niepomyślnych przekazań systemu do eksploatacji z wykorzystaniem wyżej wymienionych metod. Oczywiście kluczową rolę mają tutaj wcześniejsze fazy procesu wdrożenia.

Ze względów bezpieczeństwa należy również przygotować plany powrotu do starego systemu.




6.7. Eksploatacja systemu

Rysunek 15 Krok 7 – Eksploatacja systemu






Eksploatacja systemu



W Y J Ś C I E




  • Zmierzone korzyści

  • Zaplanowane przeglądy

  • Ciągłe ulepszenia

  • Rozwiązanie zespołu wdrożeniowego

źródło: opracowanie własne

Ocena poziomu wdrożenia

W sektorze przemysłowym powszechnie przyjęto klasyfikację ABCD9, gdzie:



  • Grupa A – system jest efektywnie używany w całej firmie, zarówno przez zarząd jako narzędzie dostarczające danych analitycznych, przez kierowników średniego szczebla jako narzędzie operacyjne oraz przez użytkowników końcowych w codziennej pracy. Powoduje znaczący postęp w zakresie obsługi klienta, produktywności, poziomie zapasów i kosztach. Wykorzystywany jest kalkulator MRP do planowania zdolności produkcyjnych i potrzeb materiałowych.

  • Grupa B – system zasadniczo służy wspomaganiu zarządu firmy, efektywnie wykorzystywany przez średni szczebel kierowniczy i użytkowników końcowych.

  • Grupa C – efektywnie korzysta się tylko z pojedynczych modułów.

  • Grupa D – korzysta się tylko z pojedynczych modułów, system jest słabo rozumiany przez użytkowników.


7. Zagrożenia dla projektu




Zaangażowanie kierownictwa


Brak zaangażowania zarządu owocuje niechęcią do brania odpowiedzialności za przebieg projektu oraz niemożnością przeprowadzenia koniecznych zmian czy bieżącego podejmowania decyzji.

Problem ten spotykany jest głównie w firmach w których inicjatorem wdrożenia jest osoba spoza zarządu, np. informatyk któremu udaje się przekonać zarząd do podjęcia projektu. Jednak po pierwszych niepowodzeniach czy znaczniejszych trudnościach wymagających radykalnej zmiany zarząd nie chce dalej brać odpowiedzialności za wdrożenie.



Czas


Wdrożenie każdego skomplikowanego systemu wymaga czasu. Nierealnie zaplanowany harmonogram, zbyt mało czasu na analizę przedwdrożeniową czy testowanie systemu przynosi nieoczekiwane rezultaty. Możliwości skrócenia czasu wdrożenia są ograniczone a przyrost korzyści jakie daje zaangażowanie kolejnych osób funkcją malejącą.

Koszty


Próby ograniczania wydatków w trakcie wdrożenia są praktycznie pewną recepta na klęskę. Zdarzają się opinie, że obcinając wydatki o 10% zrezygnujemy z 10% funkcjonalności systemu. Niestety praktyka wskazuje, że przyrost funkcjonalności następuje tutaj zgodnie z zasadą Pareto. Pierwsze 80% kosztów zapewnia 20% planowanej funkcjonalności systemu.

Odpowiedzialność


Generalnie uważa się za błąd powierzanie stanowiska Kierownika Projektu zatrudnionym w firmie informatykom. Może to prowadzić to do powstania systemu wygodnego w administracji lecz niewygodnego dla użytkowników. Ponieważ proces wdrożeniowy należy rozumieć jako przedsięwzięcie organizacyjne a nie informatyczne to osoba ta musi wykazywać duże umiejętności natury socjologicznej, organizacji pracy w grupach oraz interpersonalne. Pamiętajmy, że system tworzony jest dla użytkowników i osoba głównego kierownika wdrożenia musi umieć z tymi użytkownikami rozmawiać.

Dotychczasowy dorobek, sytuacje interpersonalne


Należy liczyć się z tym, że informatycy o dużym osobistym dorobku oprogramowania wykorzystywanym w firmie będą odbierali decyzję o wdrożeniu „obcego” systemu jako ich osobistą porażkę. Podobną sytuacją jest opór użytkowników dotychczasowych systemów dziedzinowych, którzy uważają je za spełniające ich potrzeby, są do nich przyzwyczajeni i nie widzą potrzeby zmian. Ważne jest, żeby nie próbować kwestionować bezpośrednio takich opinii. W wielu przypadkach są to zapewne świetne rozwiązania jednak nigdy nie osiągną one poziomu integracji i jakości jaką oferują systemy zintegrowane.

W stosunkach międzyludzkich bardzo łatwo o antagonizm co w skrajnych przypadkach doprowadza to powstania dwóch przeciwnych sobie obozów „my”, którzy chcemy pracować tak jak do tej pory i „oni” którzy na siłę chcą coś zmieniać. Nie wpływa to dobrze na powodzenie projektu.

System budowany jest dla użytkownika i użytkownik ten musi go współtworzyć. Dlatego tak ważną są umiejętności interpersonalne osób kierujących projektem. Podczas sesji projektowania koncepcyjnego czy prototypowania pojawiają się różne pomysły ze strony podzespołów wykonawczych. Część z nich najprościej mogłaby zostać uznana jako bezwartościowe jednak nie jest to właściwa metoda „rozmowy” z użytkownikami.

Jeżeli jest na to czas i istnieją perspektywy na zmianę punktu widzenia to należy użytkownikowi pozwolić na popełnienie błędu i stworzyć taką sytuację aby później ten błąd zauważył i sam zechciał go zmienić. Po takiej „zabawie” psychologicznej użytkownik traktuje system jako coś osobistego i znacznie bardziej świadomie zaczyna z nim pracować. Ucina się wtedy często spotykany „koncert życzeń” w którym użytkownicy wygłaszają swoje pomysły niewiele się nad nimi zastanawiając i często całkowicie je zmieniają. Użytkownik świadomy takiego błędu nie popełnia. Każda zmiana czy pomysł zaimplementowany w systemie ma swoje dalekie konsekwencje i tylko postawa „To jest system dla mnie i przeze mnie tworzony i ja będę na nim pracować przez następne długie lata” pozwala efektywnie z nim pracować.

Klasycznym przykładem na naukę na własnych błędach jest tworzenie w firmie indeksu identyfikującego surowce, wyroby gotowe, półprodukty i inne. Zwykle użytkownicy chcą zawrzeć maksimum informacji np. o wyrobie rozbudowując go do rozmiarów 10-15 znaków. Podczas teoretycznych dyskusji na nic zdają się sugestie, że może za dużo informacji zawieramy w indeksie, który ma spełniać tylko rolę jednoznacznego identyfikatora wyrobu. Dopiero podczas pierwszych warsztatów po założeniu kilkudziesięciu pozycji i próbach przeszukiwania bazy sami użytkownicy stwierdzają, że mają kłopoty pamięciowe z 15 znakami oraz że wpisywanie tak długich łańcuchów jest uciążliwe. Ku obustronnemu zadowoleniu następuje zmiana zasad tworzenia indeksu. Użytkownicy odbierają tę zmianę jako własny pomysł a nie narzucone zdanie. Główny kierownik projektu poprzez odpowiednio zaplanowane i w odpowiednim czasie przeprowadzone ćwiczenia również odniósł sukces w postaci indeksu z którym można dalej pracować.


Zmiany organizacyjne, restrukturyzacja


Wszelkie zmiany organizacyjne lub restrukturyzacja powinny zakończyć się przed rozpoczęciem lub też rozpocząć po zakończeniu wdrożenia systemu informatycznego. Dotyczy to zarówno Reengineringu procesów biznesowych, wdrażania systemów zarządzania jakością (np. w celu dostosowania do norm ISO) jak i każdego większego projektu organizacyjnego w przedsiębiorstwie.

Konsultanci


Istnieje takie powiedzenie: „Dobrego konsultanta można poznać po tym, ilu firmom odradził natychmiastowe wdrażanie zintegrowanego systemu ze względu na brak przygotowania firmy do tak poważnego przedsięwzięcia.” Dlatego za wszelką cenę należy podczas fazy wyboru ZSI unikać radzenia się jaki system wybrać sprzedawców oprogramowania. Prezentacje takie prowadzą do dwóch wniosków: po pierwsze „system jest absolutną koniecznością”, po drugie „najlepiej wasze potrzeby zaspokoją narzędzia, które my sprzedajemy”.

Wiedza na temat systemów zintegrowanych powinna pochodzić od konsultantów, którzy nie reprezentują żadnej konkretnej firmy wdrożeniowej. Pomogą sformułować zestaw pytań zadawanych formom wdrożeniowym co pozwoli na szybką eliminację niewłaściwych oferentów.



Szkolenia, Edukacja


Powszechnie popełnianym błędem są oszczędności w szkoleniach dla użytkowników końcowych. Są oni oczywiście szkoleni jak wykonywać swoją pracę lecz rzadko kiedy rozumieją oni jak działa system zintegrowany oraz jak ważne są informacje które oni wprowadzają do systemu.

Szkolenia powinny zostać podzielone na część edukacyjną – „Dlaczego” i część treningową – „Jak”. Część pierwsza edukacyjna ma tutaj krytyczne znaczenie. Jeżeli ludzie zrozumieją istotę systemu zintegrowanego i tego jaką rolę odgrywa ich praca dla poprawnego funkcjonowania całego przedsiębiorstwa to znacznie chętniej i z większą odpowiedzialnością podejdą do swojej pracy w fazie prototypowania określającej przyszły kształt systemu.

Szkolenie można nazwać ukończonym jeżeli każdy użytkownik w swoim obszarze zainteresować wie jak daną czynność wykonać w systemie, dlaczego ją wykonuje w taki a nie inny sposób oraz jaki to będzie miało wpływ na pracę innych ludzi.

Zmiana systemu jest jak nauka nowego języka. Na początku może okazać się konieczne jest stworzenie słowników przejściowych tłumaczących stare operacje na nowe. Nie wystarczy powiedzieć jak coś zrobić, należy również przekazań kiedy to zrobić i dlaczego tak a nie inaczej.

Każdy dostawca systemów zintegrowanych podkreśla wagę szkoleń dla pomyślnie zakończonej implementacji systemu. Jednak paradoksalnie zwykle właśnie wydatki na programy szkoleniowe są zmniejszane podczas negocjacji o cenę usług wdrożeniowych.

Dokumentacja wdrożeniowa


Dokumentacja wdrożeniowa wszystkich procesów realizowanych przez system stanowi podstawę do samodzielnej pracy użytkowników z systemem. Jest również niezastąpionym materiałem dydaktycznym dla nowo zatrudnionych pracowników. Niedostatecznie dokładna lub sprzeczna z rzeczywistością dokumentacja powoduje, że użytkownicy nie będą w stanie rozwiązać podstawowych problemów pojawiających się podczas użytkowania systemu co wymusi zakup dodatkowych konsultacji zewnętrznych.

Porozumienie między zleceniodawcą a wykonawcą


Częstym problemem wdrożeń w średniej wielkości przedsiębiorstwach jest stopień identyfikacji z projektem. Wiąże się to najczęściej z brakiem czasu przedstawicieli klienta na współpracę z wykonawcą. Przyczyną tego nie jest niechęć czy lenistwo pracowników lecz fizyczna niemożność pogodzenia obowiązków służbowych i tych związanych z projektem.

Podstawą wdrożenia zakończonego sukcesem jest świadomość odpowiedzialności za projekt spoczywającej na firmie, która będzie w przyszłości dany system eksploatować. To pracownicy klienta mają się czuć odpowiedzialni za tworzony system, posiadać „wizję” tego systemu i odpowiednio twórczo zaangażować się w budowę takiego systemu.

Absolutnie nie jest możliwe (pomimo, że takie próby były podejmowane w przeszłości i są nadal) zbudowanie systemu użytecznego z punktu widzenia użytkownika bez współpracy z nim.

Zakończenie

Na zakończenie niniejszej pracy wypada zadać pytanie: Dlaczego wciąż tak wiele wdrożeń systemów zintegrowanych kończy się tylko częściowym sukcesem lub całkowitym niepowodzeniem? Zagraniczne i krajowe doświadczenia pokazują, że około 70% przedsięwzięć informatycznych nie zostaje zrealizowanych w określonym czasie, przekracza przewidziany budżet lub nie spełnia oczekiwań w nich pokładanych. Ponad 50% realizacji zakończyło się w czasie dwukrotnie dłuższym od pierwotnie zakładanego w harmonogramie i pochłonęły nakłady dwukrotnie wyższe w porównaniu z przyjętymi budżetami.10

Generalnie przyczyny niepowodzeń można podzielić na dwie kategorie – przyczyny przewidywalne i nieoczekiwane.

Do przewidywalnych przyczyn zaliczamy zaniedbania we wszystkich kluczowych etapach wdrożenia wymienionych w niniejszej pracy. Pomimo, iż są to powszechnie znane podstawowe składowe poprawnego projektu wdrożeniowego to często zdarza się, że są one ignorowane w naiwnej nadziei, że „może jakoś się uda” z góry skazujące przedsięwzięcie na niepowodzenie. Błędnie zaplanowane budżety, nierealne ramy czasowe, brak określonej odpowiedzialności i nieprzestrzeganie sprawdzonych metodyk wdrożeniowych cały czas jest główną przyczyną klęski wielu projektów.

Ponieważ każde wdrożenie systemu zintegrowanego klasy ERP jest niepowtarzalne to zaplanować i przewidzieć można je tylko do pewnego momentu. Jest to, można powiedzieć, „warunek konieczny niewystarczający” dla sukcesu wdrożenia. Pozostałe problemy muszą zostać rozwiązane w sposób autorski, dlatego krytyczne znaczenie ma tutaj wybór kierownika projektu. Dla jednego takie problemy będą najbardziej interesującą częścią wdrożenia i bodźcem do wytężonego działania, dla innego pułapką nie do przejścia.

Ze względu na różnorodne przyczyny problemów i niezwykłą wręcz zdolność ludzi do popełniania tych samych błędów nie widzę w najbliższym czasie dużych szans na poprawę statystyk projektów zakończonych sukcesem.



Spis tabel i rysunków

Spis tabel



Tabela 1 Przykładowe koszty wdrożenia systemów zintegrowanych 10

Tabela 2 Przykładowy arkusz ocen stosowany podczas oceny ZSI 30

Tabela 3 Przykładowy schemat rozkładu odpowiedzialności 39

Tabela 4 Czynności wdrożeniowe 40


Spis rysunków



Rysunek 1 Struktura systemu MRP 21

Rysunek 2 Funkcje i sprzężenia zwrotne w systemie MRP II 25

Rysunek 3 Struktura zespołu wdrożeniowego 34

Rysunek 4 Struktura członków zespołu wdrożeniowego 35

Rysunek 5 Nastawienie pracowników do zmian 36

Rysunek 6 Krok 1 – Przygotowanie projektu 41

Rysunek 7 Krok 2 – Edukacja, szkolenia 43

Rysunek 8 Krok 3 – Projektowanie koncepcyjne 46

Rysunek 9 Krok 4 – Prototypowanie 48

Rysunek 10 Krok 5 – Modyfikacje, Przeniesienie danych i Eksploatacja próbna 50

Rysunek 11 Krok 6 – Przekazanie systemu do eksploatacji 51

Rysunek 12 Eksploatacja równoległa 51

Rysunek 13 „Big Bang” 52

Rysunek 14 Eksploatacja pilotowa 52



Rysunek 15 Krok 7 – Eksploatacja systemu 53



Literatura:





  1. ABCD Checklist for Operational Excellence, http://www.mrpii.com

  2. Adamczewski P.: Wdrożeniowe uwarunkowania zintegrowanych systemów informatycznych. Akademicka Oficyna Wydawnicza PLJ Warszawa 1998

  3. Adamczewski P.: Zintegrowane systemy informatyczne w praktyce. Mikom wydanie II, Warszawa 2000

  4. Adamczewski P.: Zintegrowane systemy informatyczne. Mikom Warszawa 1998

  5. Artykuły Stowarzyszenia Project Management Polska, http://www.spmp.org.pl

  6. Beynon-Davies P.: Inżynieria systemów informacyjnych. WNT Warszawa 1999

  7. Beynon-Davies P.: Systemy baz danych WNT Warszawa 1998

  8. Bielecki W.: Informatyzacja zarządzania PWE Warszawa 2001

  9. Durlik I.: Inżynieria zarządzania, Strategia i projektowanie systemów produkcyjnych, cz.1 Placet Warszawa 1998,

  10. Durlik I.: Inżynieria zarządzania, Strategia i projektowanie systemów produkcyjnych, cz.1I Placet Warszawa 1996

  11. Durlik I.: Restrukturyzacja procesów gospodarczych. Reengineering teoria i praktyka w warunkach high-technology. Placet Warszawa 1998

  12. Greniewski M.: MRP II a planowanie strategiczne, mat. z konferencji. „Human Computer Interaction”, Gdańsk 1997

  13. Greniewski M.: Wprowadzenie do MRP II + JIT Vogel Publishing, Wrocław 1997

  14. Grudzewski W., Hejduk I.: Projektowanie systemów zarządzania Difin Warszawa 2001

  15. Jaszkiewicz A.: Inżynieria oprogramowania CASE. Helion Gliwice1997

  16. Kisielnicki J., Sroka H.: Systemy informacyjne biznesu, metody projektowania i wdrażania systemów. AW Placet, Warszawa 1999

  17. Knosala R. (pod redakcją): Komputerowo zintegrowane zarządzanie, Tom I WNT Warszawa 2000

  18. Knosala R. (pod redakcją): Komputerowo zintegrowane zarządzanie, Tom II WNT Warszawa 2000

  19. Kwartalnik Dobry Biznes BCC

  20. Materiały z działu ERP Resources, http://www.erpassist.com

  21. MCS (Manufacturing Control Systems Ltd.) Implementation methodology MAXIM

  22. Peppard J., Rowland P.: Re-engineering. Gebethner I Ska Warszawa 1997

  23. Steinbeck H.: Total Quality Management Kompleksowe zarządzanie jakością Placet Warszawa 1998





1 Borys Stokalski, Być mądrym przed szkodą, Enter 8/96

2 Peppard J., Rowland P.: Re-engineering. Gebethner I Ska Warszawa 1997

3 M.Greniewski Wprowadzenie do MRP II + JIT Vogel Publishing, Wrocław 1997

4 Wg Piotra Adamczewskiego, autora Zintegrowane Systemy Informatyczne, odpowiedzi od „przypadkowych” oferentów stanowią niekiedy do 60% nadesłanych ofert

5 Prof. dr Tomasz R. Wielicki, Katalog pomyłek, Computer World, 47/1998

6 DeMarco, Listerm za Beynon-Davies P.: Inżynieria systemów informacyjnych. WNT Warszawa 1999 str. 321

7 Porównaj Adamczewski P.: Zintegrowane systemy informatyczne. Mikom Warszawa 1998str. 141 Aneks 1 Wybrane metodyki realizacji ZSI stosowane w Polsce

8 Grudzewski W., Hejduk I.: Projektowanie systemów zarządzania Difin Warszawa 2001

9 Wight O.: ABCD Checklist for Operational Excellence, John Wiley & Sons Inc. 1993, na podstawie Knosala R. (pod redakcją): Komputerowo zintegrowane zarządzanie, Tom II WNT Warszawa 2000, Referat Andrzeja Nowaczyka Praktyczne aspekty wyboru i wdrożenia systemu klasy ERP

10 Adamczewski P.: Zintegrowane systemy informatyczne w praktyce. Mikom wydanie II, Warszawa 2000

1   ...   4   5   6   7   8   9   10   11   12


©snauka.pl 2016
wyślij wiadomość