W CW 42 z 14 listopada br. przedstawiliśmy początkowe stadia projektu wdrożenia Systemu Informacji Geograficznej GIS. Dziś dokończenie tego tematu.

Ostateczna wersja projektu

W tym etapie tworzona jest dokumentacja ostatecznej wersji projektu, która zostanie załączona do zapytań ofertowych. Konieczne działania obejmują:

- finalizację specyfikacji bazy danych;

- finalizację wymagań funkcjonalnych;

- finalizację wymagań wydajności;

- wyszczególnienie ograniczeń;

- wyszczególnienie ogólnych wymagań systemowych.

Finalizacja wymagań funkcjonalnych i wydajnościowych polega na połączeniu rezultatów studium pilotażowego ze wstępnym projektem. Specyfikacja bazy danych jest potrzebna dostawcom do zaprojektowania ofert. Wymagania funkcjonalne muszą być odpowiednio szczegółowe i sklasyfikowane jako konieczne (niezbędne), pożądane (wskazane) i opcjonalne. Tylko wymagania o znaczeniu podstawowym dla działania systemu powinny być zaliczone do pierwszej z tych grup. Nadmierna ilość wymagań koniecznych może spowodować trudności w wyborze systemu i doprowadzić do odrzucenia zbyt nowatorskich rozwiązań. Wymagania wydajnościowe powinny zostać sprecyzowane w postaci minimalnych możliwych do zaakceptowania wyników (co najmniej...) oraz wartości optymalnych.

Muszą być także jasno określone ograniczenia projektu. Należą do nich zwykle wcześniej zakupione zasoby: sprzętu i oprogramowania, komunikacyjne, wymagania dotyczące interfejsu użytkownika, polityka firmy w zakresie standardów i zgodności z nimi. Ogólne wymagania systemowe obejmują: prowadzenie (administrowanie) systemu, doradztwo, szkolenia, dokumentację techniczną i użytkową, narzędzia programistyczne, kierunki rozwoju systemu, zabezpieczenia i ergonomiczność.

Zapytania ofertowe

Dokument tworzący zapytanie ofertowe powinien łączyć w sobie ostatecznie sformułowany projekt systemu i wymagania dotyczące umowy z wykonawcą. Czynności tego etapu to:

- określenie wymagań dotyczących umowy;

- określenie metodologii wyboru systemu;

- rozesłanie zapytań ofertowych.

Problemy, jakie należy uwzględnić w zapytaniu ofertowym, obejmują: dopuszczalność rozwiązania opartego na produktach i usługach więcej niż jednej firmy, wymagany stopień "dojrzałości" systemu, ewentualną zgodę na dodatkowe prace programistyczne (przygotowanie specjalnych aplikacji), sposób uwzględnienia istniejących ograniczeń, ogólne warunki składania ofert i szkic umowy.

Optymalne rozwiązanie w przypadku tworzenia kompleksowego systemu może nieść ze sobą konieczność wykorzystania sprzętu i oprogramowania więcej niż jednego producenta. W takim wypadku należy zadecydować czy główny wykonawca ma przyjąć rolę koordynatora i pełną odpowiedzialność za projekt, czy też poszczególni wykonawcy będą zajmować się wdrażaniem odpowiednich fragmentów systemu pod okiem pracowników naszej firmy. Głównym wykonawcą może być albo dostawca (producent) lub firma specjalizująca się w integracji systemów. Zapytanie ofertowe musi również precyzować czy oferty mają dotyczyć całości systemu, czy też odrębnych jego fragmentów (np. sprzęt, gromadzenie danych itp.).

Należy też zadecydować czy wymagana jest pełna "dojrzałość" systemów, czy systemy będące obecnie w fazie rozwoju także będą brane pod uwagę. Oba te podejścia niosą ze sobą pewne ryzyko. W pierwszym wypadku może się okazać, że odrzucimy system bardziej opłacalny w perspektywie dłuższego czasu. W drugim - może okazać się, że system wyglądający obiecująco w końcu nie spełni stawianych przez nas wymagań. Rozwiązanie kompromisowe to np. przyjęcie daty testów użytkowych jako ostatecznej i uwzględnianie tylko funkcji obecnych w systemie do tej daty.

Dodatkowe prace programistyczne mogą obejmować dostosowanie interfejsu użytkownika, dostosowanie oprogramowania do istniejących danych, dodatkowe funkcje analityczne lub narzędzia wymiany danych z innymi istniejącymi systemami. Należy sprecyzować procedury tworzenia, weryfikacji i implementacji tych narzędzi.

Ograniczenia określone w ostatecznej wersji projektu (poprzedni etap) powinny zostać zawarte w zapytaniu ofertowym jako wymagania konieczne lub, jeszcze lepiej, jako problemy, których propozycję rozwiązania dostawcy mają zawrzeć w ofertach. To drugie podejście umożliwi zaproponowanie w ofertach mniej kosztownych lub bardziej

efektywnych rozwiązań.

Ogólne warunki obejmują datę zamknięcia konkursu ofert, minimalne wymagania wobec formalnego zgłoszenia, warunki wprowadzania zmian do ofert w fazie testów oraz ramy cenowe. Tak sformułowane zapytanie ofertowe wymaga, aby oferenci wzięli pod uwagę wiele szczegółów technicznych i związanych z samą umową. Powinni oni wyjaśnić, jak zamierzają wypełnić każde z koniecznych, pożądanych i opcjonalnych wymagań funkcjonalnych i wydajnościowych. Muszą też odnieść się do wszelkich ograniczeń i ogólnych wymagań systemowych oraz do ramowych warunków umowy. W zapytaniu ofertowym należy podkreślić, iż wszelkie trywialne odpowiedzi na

skomplikowane wymagania techniczne, typu: "spełnione" czy "zrozumiałe" dyskwalifikują ofertę. Przydatne może być załączenie kwestionariusza, w którym oferenci będą mogli odpowiedzieć na najważniejsze dla nas pytania.

Zapytanie ofertowe powinno zawierać też szkic umowy oraz opis metodologii, jaka będzie stosowana podczas wyboru systemu spośród zgłoszonych ofert - krótkie omówienie wstępnego doboru, testów wydajności oraz analizy kosztów i zysków (zob. następne etapy), a także kryteria stosowane podczas każdego z etapów.

Zapytanie ofertowe może być rozpowszechniane przy pomocy ogłoszenia, listów do dostawców (producentów) lub w obu tych formach na raz. W wypadku skomplikowanych projektów realny czas przygotowania oferty wynosi ok. 2-3 miesięcy. Podczas tego okresu zainteresowani oferenci powinni mieć możliwość uzyskania potrzebnych im dodatkowych informacji.

Kolejna grupa etapów zawiera trzy następujące po sobie analizy, zmierzające do ustalenia który z oferowanych systemów najlepiej spełnia nasze wymagania. Wstępny wybór ofert dokonywany jest na podstawie zawartych w nich opisów realizacji koniecznych wymagań funkcjonalnych i wydajnościowych. Analiza efektywności nakładów może zostać przeprowadzona dzięki testom użytkowym, którym podlegają wstępnie wyselekcjonowane systemy.

Wstępny wybór ofert

Celem tego etapu jest sporządzenie wstępnego zestawienia możliwych do zaakceptowania systemów przez zbadanie i ocenę informacji dostarczonych przez oferentów. Działania tego etapu obejmują:

- wstępną analizę ofert;

- skonstruowanie skali ocen wymagań funkcjonalnych;

- sporządzenie wstępnej listy systemów.

Podczas analizy szczegółowych ofert należy zdecydować czy którakolwiek z nich powinna być odrzucone bez dalszego rozpatrywania. Powody tej decyzji mogą być różne: oczywiste niespełnienie niezbędnych wymagań funkcjonalnych, zbytnia ogólnikowość oferty, uniemożliwiająca dostosowanie do naszych potrzeb "dojrzałość" systemu, nieprzystawanie rozwiązania cząstkowego do całościowej koncepcji czy wreszcie koszty znacznie przekraczające plan.

Należy też sklasyfikować pod względem ważności (możliwie nadając im wagi numeryczne) pożądane i opcjonalne wymagania funkcjonalne, aby móc na tej podstawie ocenić złożone oferty. Klasyfikacja powinna zostać przygotowana przed nadejściem ofert, we współpracy z przyszłymi użytkownikami systemu. Doświadczenia zebrane podczas studium pilotażowego są dobrym punktem wyjścia dla tych klasyfikacji. Niepewne czy trudne do ustalenia rezultaty powinny zostać zweryfikowane podczas testów użytkowych.

Wynikiem tego etapu jest sporządzenie listy wstępnie zaakceptowanych ofert. W dalszych działaniach należy skoncentrować się na najwyżej pięciu najlepszych, aby testy użytkowe i następujące potem fazy nie wymknęły się nam spod kontroli.

Testy użytkowe ("benchmark")

Celem tego etapu jest potwierdzenie rezultatów wstępnej analizy ofert oraz realistyczne oszacowanie wydajności systemu w zależności od obciążenia. Umożliwia on też nieformalne poznanie firm stojących za ofertami. Testy użytkowe obejmują:

- zaprojektowanie testów;

- zgromadzenie danych i dokumentacji testów;

- przeprowadzenie testów;

- analizę rezultatów.

Projekt testów musi być oparty na wymaganiach funkcjonalnych i wydajnościowych określonych w zapytaniach ofertowych. Należy sprecyzować zadania do wykonania, potrzebne dane i sposób prezentacji wyników. Fachowa literatura może dostarczyć pewnych wskazówek w tym względzie. Użyte dane powinny obejmować mapy numeryczne oraz dane opisowe (bazy tekstowe). Rezultaty testów mogą obejmować czas ich trwania, obciążenie procesora, czas pracy operatora oraz produkty końcowe takie jak grafika czy tabele statystyczne. Inne czynniki, jakie należy wziąć pod uwagę to interfejs użytkownika i dokumentacja techniczna. Niektórzy producenci mogą podchodzić do tych testów z rezerwą, gdyż często wymagania są ogólnikowe, koszt jest nieproporcjonalny do wartości kontraktu, a na przygotowanie i wykonanie testów jest zbyt mało czasu. Projektując testy użytkowe należy więc o tym pamiętać.

Dokumentacja testów powinna zawierać ogólny opis zadań do wykonania oraz zestaw danych, które mają być użyte. Oferenci muszą być przygotowani do testu oraz zapewnić udział odpowiednio kwalifikowanego personelu w jego przeprowadzeniu, jednak nie jest ani wskazane, ani potrzebne zbyt szczegółowe opisywanie wszystkich czynności z wyprzedzeniem.

Należy dokładnie dokumentować przebieg testów. Oprócz rezultatów należy odnotować konfigurację sprzętu, instalację i użyte w testach wersje oprogramowania. Osoby przeprowadzające testy powinny upewnić się, że rozumieją wszystkie wykonywane czynności oraz że wszystko odbywa się w czasie rzeczywistym. Ich rezultaty umożliwią ponowne przeanalizowanie wstępnie zaakceptowanych ofert i ewentualne odrzucenie systemów nie spełniających podanych w nich specyfikacji.

Analiza efektywności nakładów

Oferty zaakceptowane podczas wstępnego doboru i testów użytkowych powinny zostać zanalizowane pod kątem efektywności ewentualnych nakładów. W ramach tego etapu należy:

- stworzyć teoretyczne konfiguracje;

- przeanalizować koszty konfiguracji;

- wyliczyć współczynniki efektywności nakładów;

- przeanalizować rezultaty.

Teoretyczne konfiguracje tworzymy określając wymagane zestawy sprzętu i oprogramowania. Może tu być konieczna pewna normalizacja sprzętu, jak np. określenie przestrzeni dyskowej czy liczby stacji roboczych.

Koszty kapitałowe i amortyzacja powinny być rozważane dla okresu co najmniej pięcioletniej pracy systemu. Podczas gdy dla dokonania wyboru liczą się jedynie różnice kosztów między systemami, to ogólne wyliczone sumy pozwalają zweryfikować wyniki analizy kosztów i zysków. Należy też rozważyć preliminarze wydatków w każdym roku.

Współczynnik efektywności nakładów możemy wyliczyć dzieląc całkowite koszty instalacji i funkcjonowania systemów przez rezultat testów funkcjonalnych i wydajności. Otrzymamy w ten sposób koszt jednej jednostki przetwarzania. Ponieważ systemy, które nie spełniają minimalnych wymagań funkcjonalnych i wydajnościowych zostały wcześniej odrzucone, współczynniki obrazują marginalne różnice efektywności, które uzyskujemy dla wstępnie zaakceptowanych konfiguracji.

Podczas gdy oferta o najlepszym współczynniku efektywności (najniższym koszcie jednostki przetwarzania) jest teoretycznie najlepsza, mogą jednak istnieć inne czynniki, nie włączone do analizy ilościowej, które należy także uwzględnić (np. niemierzalne przy pomocy kosztów różnice w oddziaływaniu na firmę i pracowników czy możliwości finansowe oferentów). Przygotowana w rezultacie dokumentacja musi więc obejmować dla każdej z ofert: preliminarze kosztów, rezultaty testów dodatkowych funkcji (określanych jako pożądane), wydajność i proponowaną konfigurację, wykaz dodatkowych czynników (nie objętych ilościową analizą efektywności nakładów) oraz weryfikację analizy kosztów i zysków.

Ostatnia faza pozyskiwania GIS obejmuje zaplanowanie uruchomienia systemu, podpisanie umów z wybranym dostawcą lub dostawcami, testy dostarczonego systemu oraz ostateczne uruchomienie.

Plan uruchomienia systemu

W tej fazie mamy przygotować jak najlepiej uruchomienie systemu oraz zapewnić sobie jak najwcześniejsze uzyskanie przewidywanych korzyści. Przygotowanie szczegółowego planu obejmuje:

- określenie priorytetów;

- określenie i rozplanowanie poszczególnych zadań;

- przygotowanie planu zarządzania i budżetu uruchomienia.

Priorytety dotyczące danych i produktów należy ustalać przy współpracy końcowych użytkowników systemu. Pozwoli to ustalić, w jaki sposób uzyskać szybkie korzyści po jego uruchomieniu. Nawet niewielkie pozytywne rezultaty otrzymane szybko mają duży wpływ na ostateczny sukces naszego wdrożenia.

Następnie należy rozplanować czynności związane z uruchomieniem systemu. Możliwe działania to: dostosowanie interfejsu użytkownika, szkolenie operatorów i personelu pomocniczego, przygotowanie danych i produktów końcowych. Z planem tym powinno łączyć się zestawienie bieżących wydatków i pensji dla nowych lub pracujących na nowych stanowiskach pracowników. Ważne jest również jasne określenie kompetencji personelu kierowniczego w ramach projektu.

Umowa

Etap ten obejmuje połączenie wstępnych ram kontraktu (określonych w zapytaniach ofertowych) z ofertą i planem uruchomienia systemu. W wyniku tych działań powinniśmy otrzymać umowę - dokument prawny wiążący obie strony.

W negocjacjach powinny zostać określone:

- ogólne warunki umowy;

- szczegółowe warunki umowy.

Warunki ogólne obejmują czas na jaki zawieramy umowę, schemat i zasady płatności, odpowiedzialność stron, zabezpieczenia, gwarancje, rekompensaty, arbitraż, kary za zwłokę i zasady rozwiązania umowy.

Warunki szczegółowe wiążą się z tym, co konkretnie chcemy osiągnąć. Dobrze jest odnieść się tu do funkcjonalności i wydajności, jaką powinien zapewniać system. Inne aspekty to czynności i plany przygotowania pomieszczeń, przebieg dostarczania systemu (sprzęt i oprogramowanie), instalacji, testów uruchomieniowych, szkoleń, wsparcia użytkowników. Należy też określić procedury zarządzania wszelkimi dodatkowymi czynnościami programistycznymi oraz prawa stron do powstałych w ich wyniku aplikacji.

Testy uruchomieniowe

Celem tego etapu jest upewnienie się, iż dostarczony system GIS spełnia określone w umowie wymagania. Ostateczne płatności nie powinny być dokonywane przed uzyskaniem zadowalających rezultatów wszystkich testów. Po instalacji systemu testy te powinny obejmować:

- funkcjonalność;

- wydajność;

- niezawodność.

Instalacja może wiązać się z przygotowaniem pomieszczeń, zbudowaniem połączeń komunikacyjnych oraz stworzeniem specjalizowanego oprogramowania czy dostosowaniem do naszych wymagań interfejsu użytkownika. Testy funkcjonalności i wydajności powinny być tak przeprowadzone, aby upewnić się, iż wymagania zawarte w umowie są spełnione w normalnych warunkach pracy systemu.

Niezawodność odnosi się do dostępności systemu i możliwości jego odtwarzania zarówno podczas normalnej pracy, jak i pod zwiększonym obciążeniem. W umowie można zawrzeć wymagania dotyczące przeciętnego czasu przestojów systemu np. w ciągu tygodnia, związanych z rutynową i awaryjną jego obsługą. Podczas testów uruchomieniowych należy ściśle monitorować czasy przestojów. Odbudowa systemu po awarii powinna być testowana w różnych kombinacjach symulowanego częściowego i całkowitego załamania się sprzętu i oprogramowania.

Uruchomienie

Jest to ostatni etap naszego schematu, kończący okres pozyskiwania systemu i rozpoczynający okres jego normalnej pracy. Konieczne czynności to:

- szkolenia użytkowników i administratorów;

- rozpoczęcie gromadzenia danych i przygotowywania produktów;

- ciągłe śledzenie wydajności.

Szkolenie najlepiej przeprowadzać etapami, aby wykorzystywać w nim doświadczenia zdobyte podczas normalnej pracy z systemem. Wskazane jest formalne kontrolowanie rezultatów każdej fazy szkolenia i konsultowanie ich z dostawcą systemu. Gromadzenie danych i tworzenie produktów końcowych systemu powinno również być przeanalizowane i konsultowane z użytkownikami i w razie problemów - z dostawcą.

Gdy system rozpocznie normalną pracę, ciągłe śledzenie wydajności powinno stać się jednym z zadań jego administratorów. Dane tu zebrane umożliwią wskazanie słabych punktów i powinny być wykorzystane podczas przygotowania nowych wersji (upgrade) systemu czy nowych procedur.

Problemy organizacyjne

Opisany powyżej proces może być przeprowadzany całkowicie przez pracowników przedsiębiorstwa, można go też zlecić wyspecjalizowanym zewnętrznym konsultantom lub połączyć działania pracowników i konsultantów. Zawsze trzeba jednak zwracać uwagę na takie zagadnienia, jak: dostępność, doświadczenie i koszty, zarówno własnych pracowników, jak i zewnętrznych konsultantów, "polityczne" zalety zatrudnienia zewnętrznych firm do realizacji wybranych etapów wdrożenia. Odpowiednio wykwalifikowani konsultanci mogą w przeciwieństwie do własnego personelu firmy pozwolić sobie na pozbawione emocji podejście do realizowanego projektu, gdyż nie będą bezpośrednio dotknięci jego rezultatami.

Technologię GIS cechuje interdyscyplinarność i dlatego wprowadzenie systemu będzie wywierać wpływ na wielu pracowników firmy, zajmujących się różnymi zagadnieniami. Będziemy mieć do czynienia z wieloma różnymi uczestnikami wdrożenia. Stworzenie interdyscyplinarnego zespołu do prac nad projektem, mającego w składzie specjalistów z odpowiednich dziedzin lub nakaz i możliwość odpowiednich konsultacji jest jedną z możliwości rozwiązania tego problemu. Optymalnie zespół ten powinien zawierać specjalistów z dziedziny wdrażanej aplikacji oraz wykwalifikowanych informatyków. Taki zespół może samodzielnie przeprowadzać pewne etapy wdrożenia lub służyć pomocą zewnętrznym konsultantom.

Co decyduje o sukcesie?

Porażkę wdrożenia systemu informacyjnego możemy określić jako jego niezdolność do spełnienia oczekiwań jakiejkolwiek grupy jego użytkowników. Oczekiwania te mogą dotyczyć wymagań wymiernych, takich jak specyfikacja techniczna czy budżet. Mogą też odnosić się do opinii, wartości czy percepcji użytkowników, w takim wypadku miarą porażki jest niechęć do korzystania z systemu. Skąd więc biorą się te porażki?

Możemy wymienić takie przyczyny, jak: przerost ambicji producenta (intergatora), lekceważenie potrzeb i wymagań końcowych użytkowników, niejasne lub niedokładne określenie wymagań, brak lub zbyt mała ilość konsultacji, brak motywacji ze strony użytkowników nie zaangażowanych we wdrożenie, konserwatyzm użytkowników, zbyt optymistyczne przewidywania kosztów konwersji danych i tworzenia systemu, próby tworzenia systemów przez instytucje dysponujące zbyt małymi możliwościami.

Jak widać z powyższego wyliczenia największym problemem jest czynnik ludzki. Wprowadzanie nowej technologii wymaga nie tylko nowego podejścia do dotychczasowych działań, ale też podjęcia działań zupełnie nowych, często niedostatecznie rozumianych.

6 przykazań na powodzenie wdrożenia GIS

W raporcie Komitetu Chorleya dotyczącym brytyjskich doświadczeń w dziedzinie GIS mowa jest o sześciu czynnikach umożliwiających wdrożenia systemu z powodzeniem. Oto one:

1. Informacja geograficzna jest niezbędna dla efektywnego działania instytucji.

2. Istnieje możliwość eksperymentowania i prób.

3. Wspólne dla wszystkich podejście do informacji geograficznej i tradycja jej współużytkowania i wymiany.

4. Tradycja multidyscyplinarnego rozwiązywania problemów.

5. Silne i entuzjastyczne kierownictwo wraz z grupą oddanych pracowników.

6. Pewne doświadczenia i odpowiednie nastawienie w odniesieniu do zagadnień informatyki i użycia istniejących

baz danych w postaci skomputeryzowanej.

Pierwszy i ostatni z powyższych punktów odnoszą się głównie do kierunków i zakresu działań instytucji, pozostałe cztery dotyczą raczej jej kultury informacyjnej. Jeśli odpowiednie cechy tej kultury nie istnieją, muszą zostać w trakcie wdrożenia ukształtowane tak aby zapewnić mu ostateczny sukces.