// panel klienta w przetargu

Specyfikacja techniczna panelu klienta do przetargu: co zwykle pomija dokumentacja przetargowa

Panel klienta kupuje się w przetargu zazwyczaj po to, by klient mógł sam sprawdzić swoje umowy, faktury, zgłoszenia i historię kontaktów, bez dzwonienia do biura. Zamawiającym jest organizacja z dużą liczbą klientów i wieloma napływającymi zapytaniami: organ publiczny, operator usług, duża firma. W dokumentacji taki zakup wygląda prosto: lista sekcji i kilka ogólnych zdań o wygodzie i bezpieczeństwie. Dlatego właśnie specyfikacja techniczna panelu klienta do przetargu wymaga szczególnej staranności.

Problem polega na tym, że sam panel prawie niczego nie przechowuje. To witryna nad systemami ewidencyjnymi zamawiającego, a od sposobu połączenia z nimi zależy, czy klient zobaczy aktualną fakturę, czy wczorajszą. Jeśli w specyfikacji tego nie ma, każdy wykonawca rozumie zadanie po swojemu. Oferty stają się nieporównywalne, a cena i terminy są oszacowane pod różne systemy.

Dlatego o losie projektu decyduje się już na etapie specyfikacji. Wszystko, czego nie zapisano w dokumencie, później albo jest płatne jako dodatkowe prace, albo staje się przedmiotem sporu przy odbiorze. Poniżej typowe miejsca, w których specyfikacja panelu klienta najczęściej zawodzi, oraz sposoby ich zabezpieczenia.

Co zwykle pomija się w specyfikacji

Nie wskazano, skąd panel pobiera dane i jak często są odświeżane

Czym to grozi. Wykonawca zakłada jeden sposób pobierania danych, zamawiający oczekuje innego. Wychodzi to dopiero w trakcie realizacji: potrzebna jest integracja, której nikt nie wycenił. Klient tymczasem widzi nieaktualne faktury i statusy zgłoszeń i mimo to dzwoni do operatora, czyli panel nie spełnia swojego zadania.

Jak napisać to dobrze. Dodaj do specyfikacji sekcję o źródłach danych. Dla każdego rodzaju informacji (umowy, faktury, zgłoszenia, kontakty) wskaż system źródłowy, sposób przekazywania i dopuszczalne opóźnienie aktualizacji. Osobno opisz, co pokazuje panel, gdy źródło jest czasowo niedostępne.

Brak opisu rejestracji i odzyskiwania dostępu

Czym to grozi. To najczęstszy punkt awarii w rzeczywistej eksploatacji. Jeśli nie określono, jak klient po raz pierwszy trafia do panelu i jak jest przypisywany do swojej umowy, wykonawca sam wymyśla ten proces. Zamawiający przy odbiorze stwierdza, że taki proces nie pasuje do jego klientów. Utracone hasło bez zrozumiałego scenariusza zamienia się w falę zgłoszeń do wsparcia.

Jak napisać to dobrze. Opisz scenariusze osobno: pierwsza rejestracja i potwierdzenie tożsamości klienta, powiązanie z umową, zmiana i odzyskiwanie hasła, postępowanie w razie utraty dostępu do telefonu lub poczty. Dla osób prawnych wskaż osobno, kto i w jaki sposób uzyskuje dostęp w imieniu organizacji.

Brak wymagań dotyczących zabezpieczenia logowania

Czym to grozi. W panelu znajdują się umowy i dane finansowe klientów. Sformułowania w rodzaju „system powinien być bezpieczny” nie da się zweryfikować, a więc nie można ani ich odebrać, ani zakwestionować. Wykonawcy zakładają różny poziom ochrony i oferty przestają być porównywalne. Skutki słabej ochrony docierają do zamawiającego dopiero po uruchomieniu.

Jak napisać to dobrze. Zapisz wymagania, które da się sprawdzić: metody uwierzytelniania i konieczność drugiego składnika, zasady dotyczące haseł, zachowanie przy powtarzających się nieudanych logowaniach, czas życia sesji, rejestrowanie logowań. Odwołaj się do obowiązujących przepisów i standardów, które rzeczywiście są wiążące dla zamawiającego, i opisz, jak będzie weryfikowane ich spełnienie.

Nie rozpisano, co klient zmienia sam, a co tylko przez operatora

Czym to grozi. Bez podziału uprawnień każdy rozumie „panel klienta” po swojemu. Jedni oczekują, że klient sam składa zgłoszenia i poprawia dane kontaktowe, inni uważają, że panel służy tylko do odczytu. Rozbieżność wychodzi przy odbiorze i kończy się dodatkowymi pracami za dodatkową opłatą albo sporem o to, co wchodziło w zakres zadania.

Jak napisać to dobrze. Przygotuj tabelę uprawnień: dla każdego obiektu (dane kontaktowe, zgłoszenia, kontakty, dokumenty) wskaż, co klient może tworzyć, edytować, jedynie przeglądać oraz co jest możliwe wyłącznie przez operatora. Dodaj opis ról operatora i trybu potwierdzania zmian.

Zapomniano o raportach dla kierownictwa

Czym to grozi. Specyfikację napisano w całości z perspektywy klienta, a zamawiający ma własne pytania: ilu klientów korzysta z panelu, jakie zgłoszenia są najczęstsze, gdzie gromadzą się zaległe sprawy. Jeśli raportów nie ma w dokumencie, trzeba je zamawiać osobno po uruchomieniu. Kierownictwo nie widzi przy tym, czy system się zwraca i czy ktoś z niego korzysta.

Jak napisać to dobrze. Wydziel w specyfikacji sekcję analityki i raportowania. Wymień, jakie wskaźniki są potrzebne kierownictwu, w jakiej formie i z jaką częstotliwością, kto ma do nich dostęp i czy można eksportować dane. Nawet krótka lista wskaźników jest lepsza niż jej brak.

Odbiór nie jest powiązany ze scenariuszami użycia

Czym to grozi. Gdy kryteria odbioru sformułowano ogólnikowo („panel działa poprawnie”), każda ze stron może je interpretować na swoją korzyść. Skutek: przeciągający się odbiór, zwroty do poprawki i wzajemne niezadowolenie, choć formalnie praca została wykonana.

Jak napisać to dobrze. Opisz odbiór przez konkretne scenariusze: klient rejestruje się, znajduje umowę, płaci lub zamawia fakturę, składa zgłoszenie, widzi historię kontaktów, odzyskuje dostęp. Dla każdego scenariusza zapisz oczekiwany wynik i dane do weryfikacji, aby odbiór był sprawdzeniem, a nie dyskusją.

Co daje dobra specyfikacja

Zamawiający otrzymuje dokument, na którego podstawie można porównać oferty na jednej podstawie i odebrać pracę według z góry znanych scenariuszy.

Wykonawca widzi granice zadania przed złożeniem oferty, wycenia integracje i bezpieczeństwo zamiast je zgadywać i nie bierze na siebie ukrytego zakresu.

Klienci otrzymują panel, w którym dane są aktualne, logowanie jest zrozumiałe, a uprawnienia określone, dlatego nie muszą wracać do dzwonienia do operatora.

Kierownictwo zamawiającego otrzymuje raporty, z których widać, czy system jest używany i czy przynosi korzyść.

Cena i czas realizacji

Specyfikacja techniczna: od $400, 1-4 tygodnie; cena zależy od złożoności systemu, architektury, stosu technologicznego i integracji. Realizacja w podwykonawstwie: wycena według zakresu kontraktu, przed złożeniem oferty.

Specyfikacja do przetargu lub podwykonawstwo: szczegóły →

Nie podajemy zamawiających ani przetargów: analizujemy typową specyfikację, a nie czyjeś zamówienie.

Przygotowujesz zamówienie albo już wygrałeś przetarg?

Omów przetarg