Portal klienta B2B łatwo opisać listą ekranów: logowanie, zamówienia, dokumenty i profil. Taka lista nie wystarcza do wyceny ani bezpiecznego wdrożenia. Specyfikacja musi wyjaśniać, kto wykonuje operację, na jakich danych, według jakiej reguły i co ma się wydarzyć przy błędzie.
Poniższa checklista pomaga przygotować rozmowę z zespołem sprzedaży, obsługi, IT i dostawcą ERP. Nie zastępuje analizy systemów, ale pozwala szybciej odkryć rozbieżności, które zwykle wpływają na koszt i harmonogram.
1. Cel i granice pierwszej wersji
Najpierw nazwij problem w języku procesu, nie technologii. Przykładowy cel brzmi: „klient sam sprawdza status i pobiera dokument, a obsługa interweniuje tylko przy wyjątku”. Jest bardziej użyteczny niż „chcemy nowoczesny panel”.
Ustal:
- które pytania klientów powtarzają się najczęściej,
- jaki proces ma zostać przeniesiony do samoobsługi,
- która grupa kontrahentów wejdzie do pilota,
- których funkcji świadomie nie będzie w MVP,
- po czym poznacie, że pilot można rozszerzyć.
Dobrą granicą MVP jest jeden spójny scenariusz, na przykład: logowanie → lista zamówień → szczegóły → status → pobranie dokumentu. Dodawanie katalogu, nowych zamówień, reklamacji i płatności w tym samym etapie zwiększa liczbę zależności oraz scenariuszy testowych.
2. Użytkownicy, organizacje i oddziały
Konto B2B zwykle reprezentuje firmę, a nie pojedynczą osobę. Jedna organizacja może mieć wielu użytkowników i kilka oddziałów. Dlatego specyfikacja powinna odpowiadać na pytania:
- kto zakłada konto i zatwierdza użytkownika,
- jak użytkownik jest powiązany z kontrahentem w ERP,
- czy jedna osoba może działać dla kilku spółek,
- czy oddziały widzą wspólną historię,
- kto może dodawać i odbierać dostęp,
- co dzieje się po odejściu pracownika klienta.
Zapisz role jako zestawy operacji. „Administrator” to za mało. Trzeba wskazać, czy może zapraszać użytkowników, nadawać role, zmieniać adresy i pobierać dokumenty finansowe.
3. Historia zamówień i statusy
Dla każdego pola na liście i szczegółach zamówienia określ źródło. Numer, data, pozycje i status mogą pochodzić z różnych tabel lub systemów. Ustal także:
- od jakiej daty udostępniacie historię,
- jak identyfikujecie dokumenty jednego kontrahenta,
- które statusy wewnętrzne można pokazać klientowi,
- jak prezentować częściową realizację,
- jak często dane są aktualizowane,
- co zobaczy użytkownik podczas przerwy integracji.
Status powinien być zrozumiały dla klienta. Wewnętrzne kody ERP często wymagają mapowania na mniejszy zestaw etapów wraz z krótkim objaśnieniem.
4. Dokumenty i zasady udostępniania
Lista „faktury i WZ” nie opisuje jeszcze procesu. Sprawdź, gdzie przechowywany jest plik, kiedy staje się dostępny i czy dokument może zostać zastąpiony korektą.
W specyfikacji wskaż:
- typy udostępnianych dokumentów,
- system źródłowy pliku i metadanych,
- regułę powiązania dokumentu z organizacją,
- okres dostępności,
- uprawnione role,
- wymagane rejestrowanie pobrań,
- zachowanie przy braku lub błędzie pliku.
Bezpośredni adres dokumentu także musi podlegać autoryzacji. Ukrycie linku w interfejsie nie chroni zasobu przed próbą ręcznej zmiany identyfikatora.
5. Ponawianie i składanie zamówienia
Ponowienie nie powinno kopiować starego zamówienia bez weryfikacji. Między zakupami mogą zmienić się ceny, dostępność, jednostki, indeksy i warunki handlowe.
Opisz:
- które pozycje można skopiować,
- kiedy następuje ponowna wycena,
- jak pokazać pozycje wycofane lub niedostępne,
- kto może zatwierdzić koszyk,
- kiedy powstaje dokument w ERP,
- jaki status otrzymuje portal po odrzuceniu danych.
6. Integracja i źródła prawdy
Dla każdego obiektu wskaż system nadrzędny: kontrahent, użytkownik, produkt, cena, zamówienie, status i dokument. Następnie opisz kierunek wymiany, identyfikator, częstotliwość oraz sposób ponowienia błędu.
Warto uwzględnić:
- dostępne API, pliki lub kolejki,
- limity i okna serwisowe,
- środowisko testowe oraz dane przykładowe,
- idempotencję, czyli odporność na ponowne przetworzenie,
- monitoring opóźnień i błędów,
- właściciela reakcji na wyjątek.
Zobacz, jak projektować portal B2B z integracją ERP →
7. Bezpieczeństwo i dane osobowe
Określ wymagania dla logowania, MFA, sesji, haseł lub zewnętrznego dostawcy tożsamości. Zaplanuj testy separacji danych między organizacjami i oddziałami. Zdefiniuj także rejestrowanie logowań, zmian uprawnień, pobrań dokumentów i operacji zamówieniowych.
Zakres danych osobowych, retencję i podstawę przetwarzania należy uzgodnić z osobą odpowiedzialną za ochronę danych w organizacji. Zespół wdrożeniowy powinien wiedzieć, które dane są niezbędne dla procesu i jak realizowane są żądania dotyczące konta użytkownika.
8. Kryteria odbioru
Kryterium „historia działa” jest nieweryfikowalne. Zastąp je scenariuszem z danymi wejściowymi i oczekiwanym wynikiem, na przykład:
Użytkownik oddziału A widzi zamówienia przypisane do oddziału A z ostatnich 24 miesięcy i nie uzyska dostępu do zamówienia oddziału B przez bezpośredni adres.
Przygotuj scenariusze pozytywne, negatywne i awaryjne. Obejmij nimi logowanie, role, statusy, dokumenty, przerwę ERP, duplikat żądania i odebranie dostępu.
Checklista na spotkanie zakresowe
- Cel biznesowy i grupa pilotażowa są nazwane.
- MVP ma jasno zapisane granice.
- Role opisują konkretne operacje.
- Każde pole i dokument mają źródło danych.
- Znane są identyfikatory organizacji i oddziałów.
- Opisano zachowanie podczas niedostępności ERP.
- Ustalono reguły ponowienia zamówienia.
- Zapisano testy separacji danych.
- Wskazano właścicieli błędów i danych.
- Kryteria odbioru dają się jednoznacznie sprawdzić.
Gotowa checklista nie przesądza o technologii. Pozwala natomiast porównać zakresy ofert, ograniczyć nieporozumienia i zbudować pierwszy etap, który można sprawdzić z rzeczywistymi użytkownikami.
