Jak formułować wymagania do systemu?

Proces formułowania wymagań jest jednym z kluczowym etapów każdego wdrożenia. To wtedy klient odpowiada sobie na pytanie „po co jest mi potrzebny system informatyczny?”, na które odpowiedź definiuje kolejne kroki i etapy pracy. Jak zatem podejść do tego tematu i uniknąć najczęściej popełnianych w tej fazie błędów?

Ostateczną decyzję podejmuje człowiek

Podczas definiowania wymagań wykorzystuje się szereg metod, które mają ten proces uporządkować i ułatwić (jedną z nich jest technika MoSCoW, o której pisaliśmy tutaj). Należy jednak pamiętać, że niezależnie od wybranej metodyki ostateczna weryfikacja i decyzja o umieszczeniu wymagań w dokumentacji i nadaniu im takiego, a nie innego priorytetu należy do człowieka. Pokładanie zbyt dużego zaufania w technikach  może doprowadzić do skrajnych sytuacji, w których albo wszystkie wymagania uznawane są za kluczowe albo okazuje się, że system tak naprawdę jest nieoptymalny, ponieważ nie jest w stanie zautomatyzować kluczowych funkcji. Czynnik ludzki jest więc potrzebny i niepomijalny w procesie definiowania wymagań.

Kto powinien definiować wymagania?

Właściwy wybór osoby (lub osób) odpowiedzialnej za zdefiniowanie wymagań to klucz do sukcesu. Z naszego doświadczenia wynika, że taką osobę powinny charakteryzować:

1. Znajomość wizji i strategii rozwoju firmy – system ma odpowiadać nie tylko na obecne, ale także na przyszłe potrzeby organizacji. Żeby móc dopasować go do tych przyszłych wymagań niezbędna jest nie tylko świadomość „gdzie jesteśmy” ale również „dokąd zmierzamy”.
2. Znajomość logiki systemu – bardzo ważne jest zrozumienie, że systemy informatyczne nie zawsze działają w taki sam sposób. Zdarza się, że ten sam proces można zamodelować inaczej i z wykorzystaniem innych funkcji. Podstawą jest więc jest zrozumienie jak działa wybrany system i w jaki sposób może być wykorzystany do spełnienia potrzeb organizacji.
3. Gotowość na zmiany – zbytnie przywiązanie do starego systemu może być niebezpieczeństwem, które stopuje chęć wprowadzania zmian. Celem wdrożenia nie jest przepisywanie starego systemu, odwzorowywanie go, tylko zaproponowanie innych, efektywnych sposobów na realizację procesów biznesowych.
4. Umiejętność zbilansowania zysków i strat – trzeba sobie uświadomić, że system informatyczny nie jest magiczną pigułką, która rozwiąże wszystkie problemy organizacji. Osoba decyzyjna musi mieć umiejętność sporządzenia „bilansu zysków i strat” i racjonalnej oceny, które elementy są najważniejsze z punktu widzenia długofalowego rozwoju firmy, np. obsługa procesu w modelu zaprojektowanym przez klienta wymaga szeregu modyfikacji standardowej wersji systemu co przełoży się na dużo wyższe koszty utrzymania go w przyszłości. Alternatywą jest przemodelowanie procesu i jego realizacja z wykorzystaniem standardowych funkcjonalności. Decydent musi umieć określić co w perspektywie długofalowej jest bardziej efektywnym rozwiązaniem.

Tą osobą zdecydowanie nie powinni być użytkownicy końcowi systemu, którzy często nie mają wiedzy o planach i strategii rozwoju firmy oraz nie są decyzyjni w zakresie kosztów. Niejednokrotnie ich interesy są też sprzeczne z interesem firmy, ponieważ wdrożenie optymalnie zaprojektowanego systemu informatycznego może spowodować utratę pozycji w organizacji.

Wymagania krytyczne

Standardową praktyką jest podział wymagań ze względu na ich istotność, która definiuje na czym powinniśmy się skupić podczas realizacji projektu. Często spotykamy się z sytuacja, gdy znacząca większość wymagań zostaje określona jako „krytyczne”, czyli takie bez których wdrożenie nie ma szans się udać lub jego podstawowe cele nie zostaną spełnione. O ile większość z nich spełniana jest przez standardową wersję systemu, to niebezpieczeństwo z tym związane jest znikome. Problem pojawia się, gdy do spełnienia dużej ilości wymagań krytycznych (więcej niż 10% rzeczywistej pracochłonności projektu) wymagane są kastomizacje.

Należy sobie uświadomić, że taka skala zmian wymaga olbrzymiej ilości nowego oprogramowania, który trzeba napisać, przetestować, udokumentować, i w którym zawsze może znaleźć się błąd narażający na dodatkowe koszty naprawy. Duża liczba kastomizacji utrudnia również proces utrzymania, rozwoju i upgradu systemu. Z naszych doświadczeń wynika, że w przypadku wdrożeń z dużą ilością kastomizacji 60% z nich jest zupełnie nieużywane po 2-3 latach użytkowania systemu. Odsetek ten maleje do 20% w przypadku wdrożeń z małą ilością kastomizacji.

Zmiany polegające na dostosowaniach ergonomicznych i mających na celu poprawę wydajności systemu warto wprowadzać po 6-9 miesiącach od startu produkcyjnego. Użytkownicy mają czas na przyzwyczajenie się do pracy w nowym systemie i na podstawie własnych doświadczeń są w stanie wyselekcjonować zmiany niezbędne do wdrożenia.

Trzeba również pamiętać, że ergonomia to nie funkcjonalność. Podczas klasyfikacji wymagań często zadajemy klientowi pytanie, czy dana kastomizacja naprawdę jest krytyczna, czy system nie realizuje danej funkcji, czy sposób realizacji danego procesu w nowym systemie jest po prostu niewygodny i wywołuje u użytkowników reakcję „nie da się tak pracować”. Należy zrozumieć, że nowy system to często nowa logika biznesowa. Nie gorsza, a inna i wymagająca od użytkowników adaptacji i zmiany dotychczasowych przyzwyczajeń. Zrozumienie tego pozwala na wprowadzenie podejścia do modelowania procesów bazującego na nowym, a nie starym systemie i otwiera klienta na nowe rozwiązania, które mogą lepiej sprawdzić się w praktyce.