Trasy akceptacji opisane jako „zgodnie z przyjętym porządkiem organizacji”
Czym to grozi. Wykonawca nie ma dokumentu, z którego widać, kto i w jakiej kolejności akceptuje dokument, co się dzieje przy odmowie akceptującego, czy potrzebny jest schemat sekwencyjny czy równoległy. System konfiguruje się na podstawie domysłów, a przy odbiorze okazuje się, że rzeczywisty proces akceptacji jest bardziej złożony — z warunkowymi rozgałęzieniami, delegowaniem uprawnień na czas urlopu, różnymi trasami dla różnych typów dokumentów.
Jak napisać to dobrze. Dołączyć do specyfikacji regulamin obiegu dokumentów albo przynajmniej schematy tras akceptacji dla podstawowych typów dokumentów — zarządzeń, umów, pism. Określić, co się dzieje przy nieobecności akceptującego: automatyczne delegowanie, eskalację, akceptację równoległą z kworum.
Nie powiedziano, co zrobić z archiwum papierowych dokumentów zgromadzonym przez lata
Czym to grozi. Jeśli w specyfikacji nie ma ani słowa o istniejącym archiwum papierowym, wykonawca zakłada pracę tylko z nowymi dokumentami. Kilka miesięcy po uruchomieniu okazuje się, że pracownicy nadal trzymają w rękach stare akta, bo znaleźć je można tylko w szafie, a nie w systemie — i system obiegu dokumentów jest wykorzystywany tylko częściowo.
Jak napisać to dobrze. Określić objętość i skład archiwum podlegającego przeniesieniu do postaci elektronicznej: skanowanie, indeksację, powiązanie z kartami dokumentów. Jeśli pełne przeniesienie archiwum nie jest wymagane — wyraźnie napisać, że w zakres prac wchodzi tylko bieżący obieg dokumentów od określonej daty.
Wymagania dotyczące podpisu elektronicznego nie są określone albo ograniczone do frazy „obsługa podpisu elektronicznego”
Czym to grozi. Podpisywanie dokumentów podpisem elektronicznym to nie opcja, lecz osobny moduł integracji z centrum certyfikacji, z własną logiką przechowywania certyfikatów, weryfikacji autentyczności i mocy prawnej podpisanego dokumentu. Jeśli w specyfikacji nie wskazano, z jakim centrum certyfikacji się integrować i jakie typy dokumentów wymagają podpisu, ten moduł albo w ogóle nie powstaje, albo robi się go w ostatniej chwili bez testów.
Jak napisać to dobrze. Opisać osobnym rozdziałem: jakie typy dokumentów podpisuje się podpisem elektronicznym, z jakim centrum certyfikacji system ma się integrować, jak przechowuje się i weryfikuje certyfikaty, co się dzieje po wygaśnięciu ważności podpisu.
Role i prawa dostępu opisane ogólnymi słowami w rodzaju „administrator”, „użytkownik”, „kierownik”
Czym to grozi. W organizacji z kilkoma działami i dokumentami o różnym poziomie poufności ogólne role nie wystarczą. W praktyce okazuje się, że pracownik jednego działu widzi dokumenty innego albo że kierownik nie może delegować prawa podpisu na czas nieobecności — i wychodzi to na jaw nie podczas testów, lecz w codziennej eksploatacji.
Jak napisać to dobrze. Opracować macierz ról i uprawnień: kto tworzy dokumenty, kto je akceptuje, kto podpisuje, kto widzi dokumenty o ograniczonym dostępie, jak konfiguruje się dostęp według działów i poziomów poufności. Macierz dołączyć jako załącznik do specyfikacji.
Szkolenie pracowników i okres przejściowy nie są uwzględnione w harmonogramie projektu
Czym to grozi. Termin zakończenia projektu w specyfikacji często pokrywa się z terminem gotowości technicznej systemu. Ale masowe przejście setek pracowników z papieru na nowy system wymaga szkolenia, równoległej pracy starego i nowego procesu, wsparcia technicznego w pierwszych tygodniach. Jeśli nie zostało to uwzględnione w harmonogramie, system oddaje się formalnie na czas, ale zaczyna się go używać z opóźnieniem i oporem personelu.
Jak napisać to dobrze. Wydzielić w harmonogramie projektu osobny etap wdrożenia: szkolenie kluczowych użytkowników i administratorów, okres równoległej pracy z obiegiem papierowym, wsparcie techniczne na ten okres ze wskazaniem terminu jego zakończenia.
Kontrola terminów realizacji zleceń opisana jako funkcja, ale bez konkretnych scenariuszy eskalacji
Czym to grozi. Sformułowanie „system ma kontrolować terminy realizacji zleceń” nic nie mówi o tym, co się dzieje przy zbliżaniu się terminu, przy przekroczeniu terminu, do kogo trafia powiadomienie — do wykonawcy, jego kierownika czy autora zlecenia. Bez tych scenariuszy kontrola terminów w praktyce sprowadza się do statusu w karcie, którego nikt nie sprawdza.
Jak napisać to dobrze. Opisać scenariusze powiadomień: ile dni przed terminem ostrzegać wykonawcę, co się dzieje przy przekroczeniu terminu, do kogo i w jakiej formie trafia eskalacja — e-mail, powiadomienie systemowe, raport dla kierownika.