Portal dostawców: jak zebrać dane i uzgodnić zmiany bez wymiany arkuszy

Dane dostawcy to początek współpracy

Dział zakupów prosi nowego dostawcę o dane firmy. Odpowiedź przychodzi w arkuszu, numer rachunku w osobnym pliku, a poprawiony adres w kolejnej wiadomości. Kilka tygodni później ktoś pyta, która wersja jest aktualna i czy zmianę rachunku w ogóle zatwierdzono. Portal dostawców może uporządkować tę wymianę, o ile pokaże nie tylko formularz, lecz także decyzje podejmowane po jego wysłaniu.

Wyobraźmy sobie producenta części współpracującego z kilkoma firmami dostarczającymi materiały. To fikcyjny przykład, który pomaga prześledzić proces. Kupujący potrzebuje kontaktu, zakresu dostaw i informacji rozliczeniowych. Dostawca chce wiedzieć, jakie dane są wymagane oraz kiedy może spodziewać się odpowiedzi. Obie strony potrzebują jednego obrazu tego, co zostało zgłoszone, sprawdzone i przyjęte.

Portal nie musi zastępować systemu zakupowego ani księgowego. Może być miejscem zbierania informacji i przekazywania decyzji do istniejących narzędzi. Przed wyborem rozwiązania trzeba jednak ustalić, gdzie znajduje się obowiązujący zapis i kto może go zmienić. Inaczej nowy ekran dołoży kolejną wersję danych do już istniejących.

Zaproszenie ma trafić do właściwej osoby

Zacznijcie od tego, kto może zaprosić dostawcę i na jakiej podstawie. Osoba odpowiedzialna za zakupy może wskazać nazwę firmy, adres osoby kontaktowej oraz powód rozpoczęcia współpracy. Portal powinien pokazać, czy zaproszenie wysłano, przyjęto lub odrzucono, a także kto odpowiada za kolejny krok. Nie każda wiadomość musi prowadzić do pełnej rejestracji: czasem wystarczy najpierw uzgodnić zakres potencjalnej dostawy.

Ustalcie sposób potwierdzenia, że osoba przyjmująca zaproszenie rzeczywiście może reprezentować dostawcę. Sam dostęp do skrzynki kontaktowej nie musi odpowiadać wszystkim potrzebom procesu. Dobór kontroli zależy od rodzaju danych i skutków późniejszych zmian. Jeżeli wymagana jest dodatkowa weryfikacja, wpiszcie ją do procesu wraz z osobą odpowiedzialną, zamiast zakładać, że wykona ją sam formularz.

W przypadku kilku osób po stronie dostawcy potrzebne są osobne konta i zakresy dostępu. Osoba aktualizująca dane handlowe nie musi widzieć wszystkich informacji rozliczeniowych. Podobne pytania pojawiają się w portalu B2B dla hurtowni, choć tam głównym odbiorcą jest kupujący, a nie dostawca. W obu sytuacjach ważne jest ustalenie, do jakiej firmy i jakich danych należy konkretne konto.

Jakich danych naprawdę potrzebują zakupy

Zanim powstanie formularz, prześledźcie jedną planowaną współpracę. Które informacje są potrzebne, żeby ocenić ofertę? Które dopiero przed złożeniem zamówienia? Kto wykorzystuje dane do rozliczenia? Nazwa firmy, adres, osoby kontaktowe i zakres dostaw mogą mieć różnych właścicieli. Nie proście na pierwszym ekranie o wszystko tylko dlatego, że w istniejącym arkuszu znajdują się kolumny.

Dla każdej informacji zapiszcie cel, źródło i osobę podejmującą decyzję. Przykładowo kontakt do osoby obsługującej zamówienia może wprowadzić dostawca, ale osoba prowadząca zakupy powinna wiedzieć, do jakich spraw ma go używać. Informacje rozliczeniowe mogą wymagać odrębnej ścieżki potwierdzenia. Jej przebieg ustala organizacja z osobami odpowiedzialnymi za płatności i bezpieczeństwo.

W portalu warto rozdzielić informacje obowiązkowe na danym etapie od tych, które można uzupełnić później. Dostawca powinien wiedzieć, dlaczego pole jest wymagane i co ma zrobić, jeśli nie zna odpowiedzi. Formularz, który odmawia przyjęcia wszystkich danych z powodu jednej niejasnej rubryki, zwykle produkuje kolejny telefon zamiast porządku.

Zadbajcie o czytelne nazwy oraz możliwość poprawienia błędu bez zaczynania od początku. Przy dłuższej rejestracji przyda się uzgodniony zapis wersji roboczej i informacja, co pozostaje do uzupełnienia. Przed użyciem prawdziwych danych przetestujcie zadanie z osobą, która nie brała udziału w projektowaniu formularza. Wskazówki dotyczące obserwowania pracy znajdziecie w artykule o testach prototypu z pracownikami.

Zmiana danych wymaga decyzji, nie tylko edycji

Załóżmy, że dostawca zgłasza zmianę numeru rachunku. System powinien wyraźnie oddzielić propozycję od danych już obowiązujących. Osoba odpowiedzialna musi wiedzieć, kto zgłosił zmianę, czego dotyczy i jakie czynności są wymagane przed jej przyjęciem. Dopóki decyzja nie zapadnie, sam fakt wpisania nowej wartości nie powinien udawać zatwierdzenia.

Sposób potwierdzania takich zmian trzeba dopasować do ryzyka i przyjętych procedur. Można przewidzieć niezależną weryfikację uzgodnionym kanałem, rozdzielenie osoby zgłaszającej od zatwierdzającej oraz zapis wyniku. Nie opisujemy jednej obowiązkowej procedury dla wszystkich firm. Ważne, by każda organizacja potrafiła wyjaśnić, kto zdecydował o przyjęciu nowej wartości i kiedy stała się ona obowiązująca.

Przy zmianie osoby kontaktowej zasady mogą być prostsze, ale również tutaj warto zapisać, co dzieje się z wcześniejszym dostępem. Jeśli pracownik dostawcy odszedł z firmy, samo wpisanie nowego nazwiska nie odbiera mu automatycznie konta, chyba że proces został tak zaprojektowany. Rejestr uprawnień i dane kontaktowe to powiązane, lecz odrębne elementy.

Historia zmian powinna pomagać w wyjaśnieniu konkretnej sprawy. Ustalcie, czy odbiorca widzi datę, autora zgłoszenia, status i osobę podejmującą decyzję. Nie każda osoba musi widzieć każdą poprzednią wartość. Zasady widoczności powinny wynikać z obowiązków oraz rodzaju danych, a nie z wygody pierwszego wdrożenia.

Przy dokumentach uzgodnijcie, kto może je przesłać, jakie typy plików są potrzebne i co stanie się po ich zastąpieniu nową wersją. Osoba zatwierdzająca powinna wiedzieć, którą wersję widzi i czy wcześniejsza decyzja nadal dotyczy aktualnej treści. Jeśli dokument stracił ważność albo wymaga ponownego sprawdzenia, portal może wskazać zadanie odpowiedzialnej osobie. Sam termin w tabeli nie wykona jednak kontroli.

Który system przechowuje obowiązujące dane

Jeśli firma ma system zakupowy lub ERP, przed integracją ustalcie, gdzie powstaje wiążący zapis dostawcy. Portal może zebrać propozycję zmiany, ale inny system może odpowiadać za jej ostateczną akceptację. Przykład takiej zależności opisuje dokumentacja SAP dotycząca integracji SAP Ariba z zarządzaniem danymi dostawców: w opisanej konfiguracji zmiana czeka na zatwierdzenie w systemie zewnętrznym. Nie oznacza to, że każdy system zakupowy działa tak samo. Jeśli portal ma przyjmować już zatwierdzone potrzeby zakupowe, osobno trzeba zaplanować wniosek zakupowy i akceptację wewnątrz firmy.

Spiszcie pola, kierunki wymiany oraz statusy. Co stanie się, gdy portal przyjmie formularz, a system docelowy odrzuci zapis? Kto zobaczy powód i jak dostawca dowie się, czy powinien coś poprawić? Odpowiedzi nie mieszczą się w zdaniu „systemy będą zintegrowane”. Potrzebny jest również sposób uzgodnienia rekordu, który zmienił się w obu miejscach.

Więcej o wyborze źródła informacji piszemy w artykule o integracji systemów i źródle danych. Jeśli wymiana korzysta z interfejsu programistycznego, przyda się też omówienie API i webhooków. Potwierdzenie przyjęcia żądania przez jeden system nie musi oznaczać, że aktualizacja została już zaakceptowana w drugim.

Warto przewidzieć sytuację, w której istnieje już kilka rekordów tej samej firmy. Przed automatycznym połączeniem sprawdźcie identyfikatory i ustalcie osobę, która rozstrzyga niepewne przypadki. Podobna nazwa lub ten sam adres nie zawsze wystarcza do stwierdzenia, że dwa wpisy opisują tę samą organizację. Zachowanie historii i powiązań bywa równie ważne jak usunięcie pozornego duplikatu.

Przy wymianie informacji uwzględnijcie opóźnienie. Wysłana zmiana może oczekiwać na przetworzenie albo decyzję w innym systemie. Portal powinien pokazać ten stan zgodnie z dostępnymi potwierdzeniami, zamiast oznaczać całą sprawę jako zakończoną po samym naciśnięciu przycisku. Zespół zakupów potrzebuje też sposobu ponownego sprawdzenia problemu, gdy odpowiedź nie nadejdzie.

Dostawca powinien widzieć, co dzieje się dalej

Po wysłaniu formularza pokażcie zrozumiały stan: dane przyjęto do sprawdzenia, potrzebne jest uzupełnienie albo rejestracja została zakończona. Każdy status powinien mieć właściciela i oznaczać rzeczywistą sytuację w procesie. „W trakcie” bez informacji o kolejnym kroku szybko staje się inną nazwą milczenia.

Jeżeli osoba sprawdzająca odrzuca część informacji, powinna móc wskazać konkretny brak i bezpieczny sposób odpowiedzi. Nie trzeba odsłaniać wewnętrznych notatek całego działu zakupów. Dostawcy potrzebna jest informacja, co ma poprawić, dokąd wrócić i czy dotychczasowe dane zostały zachowane. W niektórych projektach przydatne będzie również wskazanie osoby kontaktowej po stronie kupującego.

Po stronie firmy potrzebna jest lista spraw oczekujących na decyzję, zastępstwo oraz sposób wyjaśniania opóźnień. Alert wysłany do nieaktywnej skrzynki nie rozwiąże problemu. O przypisywaniu odpowiedzialności za błędy piszemy przy monitorowaniu automatyzacji. Te same pytania pomagają zaprojektować obsługę formularzy, których nikt jeszcze nie zatwierdził.

Zastanówcie się też, co zobaczy dostawca po ponownym zalogowaniu. Informacja o wcześniejszym zgłoszeniu pozwala uniknąć ponownego przesyłania tych samych dokumentów. Jeśli system prosi o poprawkę, dobrze wskazać konkretną sekcję i zachować pozostałe dane, które nadal są potrzebne. Wspólna historia nie musi oznaczać wspólnego dostępu do wszystkich szczegółów.

Ustalcie, jak obsłużyć zmianę osoby odpowiedzialnej za współpracę w firmie kupującej. Nierozpatrzona prośba nie powinna pozostać bez właściciela tylko dlatego, że dotychczasowy opiekun odszedł lub jest nieobecny. Lista zadań powinna umożliwiać wyznaczenie zastępstwa i zachować kontekst poprzednich ustaleń. Warto przetestować taki scenariusz jeszcze przed otwarciem portalu dla dostawców.

Jak sprawdzić pierwszy zakres

Przygotujcie fikcyjną firmę, zaproście przedstawiciela i przeprowadźcie go od pierwszej wiadomości do decyzji. Sprawdźcie brak wymaganego pola, korektę osoby kontaktowej, zmianę wymagającą dodatkowego potwierdzenia oraz odrzucenie aktualizacji przez system docelowy. Dla każdego scenariusza zapiszcie, kto widzi status i jakie działanie może wykonać.

Ważna jest również próba uprawnień. Użytkownik jednej firmy nie powinien zobaczyć danych innego dostawcy, także w wyszukiwarce i powiadomieniach. Konto wewnętrzne powinno mieć zakres odpowiadający jego zadaniu. Wyniki testów opiszcie jako konkretne zachowania, a nie ogólne zapewnienie, że portal jest bezpieczny. O przygotowaniu takich prób przeczytacie przy kryteriach odbioru aplikacji.

Na koniec porównajcie wynik z codzienną pracą. Czy osoba kupująca potrafi znaleźć sprawy wymagające decyzji? Czy dostawca rozumie prośbę o poprawkę? Czy przyjęta zmiana trafiła do właściwego systemu? Jeżeli test korzystał z symulowanej integracji, zapiszcie to jako ograniczenie. Zachowanie rzeczywistego połączenia wymaga osobnego sprawdzenia z właściwym dostawcą systemu.

Jeżeli chcesz uporządkować współpracę z dostawcami, zobacz zakres oprogramowania na zamówienie i skontaktuj się z Archifutura. W krótkim briefie opisz, jakie informacje zbieracie, kto je zatwierdza i z jakimi systemami mają się łączyć. Wystarczy jeden przykładowy przebieg przygotowany bez poufnych danych.

Po uruchomieniu zbierajcie pytania o miejsca, w których dostawcy potrzebują pomocy. Powtarzające się prośby o wyjaśnienie pola mogą oznaczać problem z opisem, a nie brak staranności po drugiej stronie. Wybierzcie sposób przekazania uwag do właściciela formularza i termin przeglądu. Zmiana pól powinna następnie zostać sprawdzona razem z integracją oraz istniejącymi danymi. Zapiszcie również osobę odpowiedzialną za odpowiedź na zgłoszenia.