Zacznijmy od elementarza

Prawidłową ocenę jakiegokolwiek oprogramowania dla konkretnego odbiorcy należy bezwzględnie zacząć od precyzyjnego zdefiniowania modelu systemu informacyjnego przyszłego użytkownika. W uproszczeniu chodzi o określenie rodzaju informacji, jakie kreuje i z jakich korzysta oraz sposobu ich przepływu. Mimo, że stwierdzenie wydaje się banalne, zasada ta często jest w praktyce pomijana bądź niedoceniana.

Prawidłową ocenę jakiegokolwiek oprogramowania dla konkretnego odbiorcy należy bezwzględnie zacząć od precyzyjnego zdefiniowania modelu systemu informacyjnego przyszłego użytkownika. W uproszczeniu chodzi o określenie rodzaju informacji, jakie kreuje i z jakich korzysta oraz sposobu ich przepływu. Mimo, że stwierdzenie wydaje się banalne, zasada ta często jest w praktyce pomijana bądź niedoceniana.

Uwaga potencjalnych odbiorców, a zwłaszcza dostawców, z reguły od początku koncentruje się na samym, oferowanym produkcie software'owym.

Obserwując przebieg negocjacji, poprzedzających zawieranie kontraktów informatycznych, widzimy często, że klient nie ma opracowanego modelu informacyjnego lub choćby jego wizji. Stąd też już na starcie, przyszły system informatyczny obciążony zostaje poważną wadą genetyczną. Możemy bowiem z dużym prawdopodobieństwem założyć, że nie spełni on oczekiwań, a jego implementacja stanie w jaskrawej sprzeczności z zasadami rachunku ekonomicznego.

Zdarza się więc niemal nagminnie, że dopiero po wdrożeniu oprogramowania próbujemy nagiąć je do naszych, wcześniej nie do końca sprecyzowanych, potrzeb.

Gdzie skierować pierwszy krok?

Opracowanie modelu musi więc stanowić pierwszy etap profesjonalnie prowadzonych prac projektowo-wdrożeniowych. Model ten bowiem daje użytkownikowi podstawowe narzędzie, określa ramy jego potrzeb. Tworzy więc pewien ich wzorzec. Sporządzenie tak zdefinowanego modelu informacyjnego nie jest jednak ani łatwe ani tanie, choć w ostatecznym rachunku zawsze się opłaca.

Często wszakże uznajemy za model dokumentację, której daleko jeszcze do zasłużenia na to miano. Do typowych błędów takich pseudomodeli informacyjnych można zaliczyć zbyt ogólny lub wręcz ogólnikowy ich charakter, brak prób usprawnienia modelu (sposobu przygotowania informacji, ich zakresu, eliminacji informacji zbędnych lub niepotrzebnie powielanych, nie mówiąc już o udrożnieniu ich przepływu). Konsekwencją jest brak wizji nowego modelu, który ma wspierać informatyka. Co gorsza nie rozróżniamy często, co poprawić ma zastosowanie technologii informatycznych, a co daje się usprawnić bez ich stosowania. Jest to tymczasem rzecz z gruntu podstawowa. Usprawnienie modelu informacyjnego bowiem z reguły obniża koszty implementacji systemu komputerowego, a z zasady je optymalizuje.

Stąd też często informatykę stosuje się jedynie po to, aby "wyasfaltować" stary, nieefektywny model przepływu informacji, zwiększając tylko szybkość tego przepływu i tworząc techniczne warunki dla bujnego rozwoju "prawa Parkinsona".

Co musimy wiedzieć zanim...

Wniosek stąd, że wszystkie przedsięwzięcia, związane z informatyzacją, musi poprzedzać uzyskanie konkretnych (wymiernych w sensie inżynierskim) danych o systemie ewidencyjnym, kanałach informacyjnych, bazach indeksowo-kodowych oraz możliwych do określenia parametrach systemów informatycznych otoczenia, z którego dana organizacja czerpie lub z którym wymienia informacje. Dane te powinny dotyczyć zarówno stanu obecnego jak i planowanego. Celem jest uzyskanie dokumentacji obejmującej:

  • opis aktualnego stanu modelu informacyjnego;

  • obszary proponowane do informatyzacji;

  • opis docelowego, zinformatyzowanego już modelu;

  • szczegółowy opis procedur informacyjnych przewidywanych do informatyzacji, wraz z wynikającymi zmianami organizacji i technologii pracy;

  • wykaz przepisów prawnych, zasad obligatoryjnych i zwyczajowo przyjętych, jakie muszą spełniać zinformatyzowane procedury informacyjne (np. szyfrowanie danych w systemach bankowych);

  • wykaz norm i standardów informatycznych, które musi spełniać oprogramowanie;

  • opis najbardziej odpowiadających wymogom typów sprzętu i oprogramowania;

  • dodatkowe wymagania, wynikające ze specyfiki modelu informacyjnego oraz żądań nabywcy oprogramowania;

  • maksymalne koszty zakupu zasadniczych elementów systemu oraz prac towarzyszących jego wdrażaniu (szkolenia, nadzór);

  • harmonogram prac projektowo-wdrożeniowych oraz terminy zakończenia poszczególnych etapów;

  • wykaz parametrów oprogramowania oraz sposobu ich sprawdzania podczas odbioru;

  • zasady współpracy między dostawcą a nabywcą oraz nadzorowania prac.
Dopiero sformułowane w takim zakresie i układzie wymagania nabywcy, w postaci często obszernych i szczegółowych działów, mogą być podstawą oceny przydatności konkretnego oprogramowania do potrzeb klienta. Dają one równocześnie dostawcy szanse precyzyjnej odpowiedzi na pytanie: czy jego produkt odpowiada tym potrzebom lub jakie kroki musi on podjąć, aby tak się stało?


TOP 200