Faza 16. Wybór docelowego systemu

Ostateczna decyzja nie należy raczej do zadań grupy projektowej, będącej ciałem opiniodawczym, lecz do decydentów dysponujących środkami finansowymi i odpowiedzialnymi za całościową politykę instytucji. Oni też na podstawie dokumentu końcowego będącego efektem prac grupy projektowej, muszą dokonać ostatecznego wyboru. Oprócz przedstawienia pisemnego sprawozdania z wykonanych prac wraz z wnioskami, pożądane jest także przeprowadzenie dyskusji, prezentując szerzej opinie grupy projektowej. Zdawać sobie trzeba sprawę, że osoby decydujące o ostatecznym wyborze nie mają pojęcia o merytorycznej stronie zagadnienia. Znają pewne fakty hasłowo, tak zresztą jak nazwy firm i produktów przez nie oferowanych. Decyzja ostateczna także nie jest podejmowana jednoosobowo ze względu na wielkość inwestycji. Wybór końcowy najlepiej przeprowadzić poprzez głosowanie, decydując się na jedną z metod:

jawną - efekt w dużej mierze zależy od pierwszego głosu i od tego, do kogo on należy. Jeśli jest to osoba znajdująca się na szczcie hierarchii (kurtuazja nakazuje oddanie pierwszeństwa), wówczas należy być prawie pewnym, że następne głosy pójdą w ślad za pierwszym, o ile nie jest prowadzona "wojna na górze";

tajną - głosy oddawane anonimowo na kartkach pozwalają wszystkim wyrazić to, co myślą, a co więcej nikt nie podlega sugestii pierwszego głosu. W przypadku bardzo zróżnicowanych wyników głosowania można drogą kolejnych eliminacji wybrać ostateczny system.

Faza 17. Opracowanie wstępnego projektu instalacji

Po dokonaniu wyboru systemu należy właściwie przygotować się do jego instalacji. Grupa projektowa na podstawie wcześniejszych opracowań jest zorientowana w stanie aktualnym i przyszłym. Na kanwie tego należy opracować szkic sytuacyjny rozmieszczenia docelowego całej sieci komputerowej z wyodrębnieniem sprzętu, który będzie zakupiony oraz istniejącego, który może pracować w nowym systemie. Plan taki jest konieczny z dwóch względów:

- systematyzujemy i jednocześnie sprawdzamy nasze koncepcje funkcjonowania całości;

- tworzymy podstawę dla firmy, która będzie projektowała oraz instalowała naszą sieć komputerową.

Zależności czasowe przy tworzeniu projektu

Czas wykonania poszczególnych etapów musi być umieszczony w sensownych ramach. Niektóre z nich mogą być realizowane niemal równolegle, inne natomiast muszą oczekiwać na zakończenie poprzednich. Synchronizacja poszczególnych faz do złudzenia przypomina programowanie współbieżne.

W celu optymalizacji czasu trwania projektu, należy przyjąć, że liczba rozpatrywanych docelowo systemów pozostaje w stosunku 1:2 do liczby uczestników grupy projektowej, tak aby fazy 9, 10 i 11 były przygotowywane niezależnie przez nie większe niż dwuosobowe zespoły. Każde posiedzenie grupy trwające nie dłużej niż 3 godziny, oprócz dyskusji nad bieżącym tematem, jest zakończone sformułowaniem zadań do wykonania do czasu następnego spotkania.

Dłuższe posiedzenia są nieefektywne, gdyż z reguły nie wnoszą do sprawy nic nowego i przeradzają się w jałową dyskusję. Jako minimalną jednostkę czasu trwania etapu przyjęto 1 tydzień (5 dni roboczych), co nie jest dużo zważywszy, że należy w tym okresie wykonać szereg czasochłonnych czynności przygotowawczych.

Poniższa tabela przedstawia orientacyjny przebieg czasowy poszczególnych etapów przy założeniu, że po wstępnej selekcji pozostało 5 systemów.

Z tabeli wynika, że orientacyjna ilość czasu poświęcona na doprowadzenie projektu do końca wynosi 24 tygodnie, czyli 6 miesięcy. Jest to czas bardzo prawdopodobny, gdyż pewnych procesów nie da się przyspieszyć. Nie jest też powiedziane, że wszyscy uczestnicy grupy projektowej są przez cały ten okres pochłonięci tylko i wyłącznie tworzeniem projektu. Przynajmniej 60% czasu to oczekiwanie na synchronizację zakończenia prac danego etapu.

Podsumowanie, czyli o czym trzeba pamiętać

O warunkach zakupu i późniejszej eksploatacji zakupowanego systemu decyduje oficjalna umowa (kontrakt), która musi być autoryzowana przez prawników. Wszelkie niedopatrzenia w precyzowaniu warunków mogą kosztować w późniejszym czasie zbyt wiele.

Szczególnie należy zwrócić uwagę na następujące aspekty:

- jeżeli dotychczas eksploatowany w naszej firmie system informacyjny ma być zastąpiony nowym, musimy okreslić warunki konwersji istniejących danych;

- należy przeanalizować formę udzielanej licencji - czy oprogramowanie może być używane na określonej liczbie terminali w ogóle, czy jednocześnie, czy oprogramowanie części serwerowej może być dublowane (nawet w ramach jednego serwera), np. w razie konieczności obsługi podobnych baz danych, które nie mogą tworzyć logicznej całości;

- określenie sposobu wykonywania serwisu gwarancyjnego i pogwarancyjnego;

- możliwości dostępu do nowszych wersji oprogramowania (są one udostępniane zazwyczaj w przypadku opłacania tzw. utrzymania rocznego);

- określenie rodzaju odpowiedzialności za ewentualną utratę danych lub innych strat w przypadku awarii systemu wynikłych z jego błędnego działania;

- określenie warunków wykonania ewentualnych modyfikacji systemu niezbędnych z punktu widzenia odbiorcy, już w momencie początkowym.

Istnieją też pewne sytuacje, których nie jesteśmy w stanie przewidzieć w momencie zakupu. Dopiero w czasie eksploatacji mogą wyniknąć potrzeby narzucające konieczność dokonania zmian w oprogramowaniu. Jeżeli takie zmiany nie są specyficzne dla innych użytkowników tego systemu, wówczas nie mamy co liczyć na to, że pojawią się w którejś z nowszych jego wersji. Pozostaje więc albo zrezygnować z modyfikacji, albo złożyć wniosek do producenta o realizację naszych postulatów. W tym drugim wypadku koszty są zazwyczaj bardzo duże, gdyż producenci oprogramowania nawet jeżeli obniżają pierwotną cenę sprzedaży, to później zechcą wykorzystać każdą sytuację dla poprawienia swojego bilansu. Zakupując zatem gotowe systemy musimy liczyć się z niebagatelnymi wydatkami także w przyszłości, nie tylko na bieżącą eksploatację, ale na rozwój i modernizację, czego wielu decydentów wydaje się nie dostrzegać.