W odpowiedzi na potrzeby

Projekt informatyzacji ma szanse powodzenia tylko wtedy, gdy jest odpowiedzią na realne, dobrze wyartykułowane potrzeby.

Projekt informatyzacji ma szanse powodzenia tylko wtedy, gdy jest odpowiedzią na realne, dobrze wyartykułowane potrzeby.

Przedsiębiorstwa rozpoczynają projekty informatyczne, wtedy gdy dostrzegają, że stare sposoby działania są już nieefektywne. Sygnałem ostrzegawczym potrzeby zmian są np. gorsze wyniki finansowe, wyparcie z określonych rynków albo niska jakość produktów w porównaniu z konkurencją. Rozpoznawanie i nazywanie potrzeb wcale nie jest taką naturalną i oczywistą umiejętnością, jakby się na pozór wydawało. Firmy mają skłonność do niezgłębiania dostrzeżonego problemu, np. niską jakość wiążą z niedostateczną liczbą kontrolerów, a nie z brakiem odpowiednich procedur, natomiast nadmiar dokumentów "przygniatający" firmę na ogół wynika nie z małej liczby komputerów - jak się to mówi powszechnie - lecz ze złego zarządzania informacją. Zarządzanie informacją oczywiście z komputerami ma sporo wspólnego, ale same komputery niczego nie porządkują, lecz system informacyjny, wsparty systemem komputerowym.

Oczami klienta

Dostawcy rozwiązań informatycznych mają zawsze kłopot z ustaleniem wymagań dla projektowanego systemu, ponieważ klient rzadko kiedy potrafi powiedzieć, czego tak naprawdę potrzebuje. Dotyczy to także projektów wdrożenia gotowych pakietów oprogramowania, ponieważ je również trzeba "przykroić" stosownie do potrzeb klienta. Klienci najczęś-ciej mówią tak, choć zawsze w bardziej dyplomatyczny sposób: "Nie jestem pewny, czego chcę, ale będę wiedział, gdy to zobaczę". Na dostawcę systemu spada obowiązek dociekania, czego też ten klient może naprawdę potrzebować. W tym pierwszym etapie ustalania wymagań klient na ogół ma raczej przeczucie swoich potrzeb niż konkretne żądania. Konsultanci informatyczni dostawcy muszą zatem nie tylko zadać wiele pytań, aby uzyskać ów konkret, ale także wczuć się w sytuację klienta, w jego ambicje i zamierzenia, zrozumieć, kim ten klient chce być. Po tym wstępnym okresie prac klientowi trzeba przedstawić zarys rozwiązania, ale tak, aby je zrozumiał, czyli w nietechnicznym języku, najlepiej graficznie i tylko jeden fragment, ale dokładniej. Klient musi się zorientować, czy o to właś-nie mu chodziło.

Bez względu na to, czy klient zobaczy coś przybliżonego do jego wyobrażeń, czy zupełnie nie to, czego się spodziewał, następuje drugi etap formułowania wymagań. Jest to etap przyspieszonej edukacji klienta. Projekt jest zwykle dla niego inspiracją: nagle dostrzega swój biznes inaczej niż przez poprzednie lata, odkrywa nowe możliwości, zauważa, że coś można robić zupełnie inaczej. Jego wymagania lawinowo rosną i ciągle się zmieniają. Jeśli wcześniej - na podstawie wstępnych analiz - ustalono zakres i budżet projektu, to teraz zaczną się kłopoty. Te dwie sprawy powinny być ustalane kontraktowo dopiero, gdy klient jest świadomym partnerem dostawcy rozwiązania informatycznego.

Dla asekuracji

Choć każdy projekt jest inny, to kilka zasad postępowania przy ustalaniu wymagań dla systemu informatycznego jest uniwersalnych. Po pierwsze, bez względu na wielkość projektu i stosunki między partnerami, wymagania zawsze powinny być dokładnie spisane. Po drugie, jeśli istnieje zagrożenie, że zostaną one źle zinterpretowane, to na pewno tak się stanie. Jest to jedno z praw Murphy'ego: jeśli coś może pójść źle, to pójdzie. Trzeba więc dokonać dokładnej analizy wymagań dla systemu pod kątem możliwości reinterpretacji poszczególnych zapisów. Dla uzmysłowienia, jak ważna, a zarazem ulotna jest to materia, warto zastanowić się, na ile sposobów można zrozumieć proste polecenie: pomalować pokój na zielono. Czy tylko ściany? Czy ściany i sufit? Czy wszystkie powierzchnie? A co z otworami okiennymi i drzwiami? Taka banalna sprawa, a ile możliwości interpretacji.

Po trzecie, wymaganiom trzeba się przyjrzeć również pod kątem możliwości zmian i wypracować procedury ich nanoszenia i rozliczania. Zmiany bowiem nastąpią nieuchronnie. Muszą one być pisemnie dokumentowane.

Po czwarte wreszcie, personel dostawcy systemu i jego klienta powinien być przeszkolony w dziedzinie sporządzania dokumentacji. Dokumentacji nie zastąpią ani nieformalne porozumienia, ani dobra wola, ani profesjonalizm w innych aspektach prowadzenia projektu. Dokumentacja jest zapisem wszystkich wydarzeń w projekcie: bazą wiedzy o nim. Profesjonalnie prowadzona dokumentacja jest dowodem, że strony są świadome zadań i odpowiedzialne za swoje działania.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200