W małej firmie produkcyjnej codzienna praca z dostawcami wygląda zwykle tak: zaopatrzeniowiec wysyła PDF-a z zamówieniem, ktoś dzwoni potwierdzić, potem drugi telefon w sprawie terminu, potem mail „a dorzućcie jeszcze 200 sztuk", potem sms „dostawca opóźnia o dwa dni, pilne". Codziennie od nowa, dla 30-50 dostawców. To nie skaluje się w prosty sposób.
Portal dostawcy to najczęściej pierwsza aplikacja custom, która realnie oszczędza kilka godzin tygodniowo w dziale zaopatrzenia i jednocześnie porządkuje resztę procesu — bez wielkiego wdrożenia i bez zmiany ERP-a.
W tym tekście trzeźwo: co robi taki portal, kiedy warto go budować, a kiedy szkoda pieniędzy, jakie warunki musi spełnić ERP i ile to naprawdę zajmuje.
Co to jest i co realnie robi
Portal dostawcy to prosta aplikacja webowa, do której loguje się każdy stały dostawca, żeby zobaczyć swoją część procesu zakupowego. Nic więcej. Nie zastępuje ERP-a. Nie robi rewolucji w zaopatrzeniu. Prostuje jeden wąski, ale bolesny fragment.
Typowy zakres funkcji, który sprawdza się w MŚP:
- Lista otwartych zamówień — dostawca widzi tylko swoje PO, z ilościami, cenami, oczekiwanym terminem.
- Potwierdzenie lub kontrpropozycja — jednym kliknięciem: „przyjmuję termin", „przesuwam na X", „nie mam towaru, proponuję zamiennik".
- Zapowiedź wysyłki (ASN) — dostawca wpisuje datę wysyłki, numer listu przewozowego, ewentualnie zdjęcie palety.
- Dokumenty dostawy — WZ, CMR, certyfikat jakości, atest — wszystko w jednym miejscu, powiązane z PO.
- Historia rozliczeń — dostawca widzi faktury i statusy płatności bez potrzeby pisania do księgowej.
Wszystko inne — ceny, negocjacje, umowy ramowe, aneksy — dalej robi się poza portalem. To jest cecha, nie brak. Portal ma być prosty do wdrożenia po stronie dostawcy, bo inaczej mniejsi dostawcy z niego nie skorzystają, a wtedy proces jest wciąż podwójny.
Przykład z życia
Jeden z naszych klientów, 32-osobowy przetwórca mięsny na Podkarpaciu, pracował z około 40 stałymi dostawcami (mięso, opakowania, przyprawy, chemia sanitarna). Dwie osoby w zaopatrzeniu spędzały łącznie około 9 godzin tygodniowo na telefonach i mailach z potwierdzeniami dostaw. Do tego regularnie były spory: dostawca twierdził, że nikt nie prosił o zmianę terminu, my twierdziliśmy, że zmienialiśmy. Wszystko żyło w skrzynkach mailowych trzech różnych osób.
Zbudowaliśmy portal zintegrowany z ich Comarch Optima (PO leciały z ERP-a do portalu, potwierdzenia wracały do Optimy jako aktualizacja daty realizacji). Wdrożenie po naszej stronie zajęło 6 tygodni, dodatkowo 2 tygodnie na wprowadzenie dostawców i pierwsze poprawki.
Po trzech miesiącach:
- Czas na telefony i maile z potwierdzeniami dostaw spadł z ~9 do ~2 godzin tygodniowo (odzyskane ~7 godzin).
- Liczba sporów o „kto co zmienił" spadła praktycznie do zera — wszystko jest znaczone czasem w portalu.
- 34 z 40 dostawców używa portalu regularnie. 6 najmniejszych dalej dzwoni, i to jest w porządku — nie ma sensu przymuszać dostawcy, u którego robisz 3 zamówienia rocznie.
Koszt projektu zwrócił się w niecały rok samym czasem zaopatrzeniowców. Realny zysk był większy — mniej sporów oznacza mniej awaryjnych zakupów u droższych dostawców, kiedy plan produkcyjny się sypie.
Kiedy warto, a kiedy odpuścić
Portal dostawcy nie jest dla każdego. Warto się w to angażować, jeśli spełniasz co najmniej dwa z trzech warunków:
- Masz co najmniej 15-20 stałych dostawców, z którymi pracujesz w rytmie tygodniowym lub gęstszym. Poniżej tego progu telefon jest po prostu szybszy niż logowanie do czegokolwiek.
- Zaopatrzenie zajmuje realnie ludziom co najmniej pół etatu tygodniowo na samą komunikację z dostawcami. Poniżej tego progu ROI wygląda słabo.
- Masz powtarzalne spory o daty, ilości albo dokumenty — takie, które kończą się szperaniem w mailach, żeby udowodnić, kto miał rację.
Odpuść, jeśli twoje zaopatrzenie to głównie zakupy jednorazowe (projekt po projekcie, nowi dostawcy co miesiąc), jeśli twoi dostawcy sami mają swoje portale, na których wymuszają logowanie (wtedy problemem jest twój portal, nie ich), albo jeśli masz mniej niż 10 osób i zaopatrzenie robi właściciel po godzinach. W tych sytuacjach lepsza jest solidna wspólna skrzynka mailowa i szablony w Outlooku.
Co musi być gotowe w ERP
Portal dostawcy nie działa w próżni. Żeby miał sens, twój ERP musi:
- Trzymać czyste dane dostawców — jeden kontrahent, jeden NIP, jedno konto w portalu. Jeśli masz w Comarch Optima „Mięso Kowalski", „Kowalski Mięso Sp. z o.o." i „P.P.H.U. Kowalski" jako trzy różne rekordy z tym samym NIP-em, portal to obnaży w pierwszym tygodniu.
- Wystawiać PO z jasnym numerem, ilością i ceną — portal odczytuje to, a nie tworzy. Jeśli PO żyje głównie w Excelu handlowca, najpierw uporządkuj proces w ERP.
- Umożliwiać zwrotny zapis dat realizacji — API lub przynajmniej sensowny mechanizm importu. Jeśli twój ERP tego nie umie (zdarza się w starych instalacjach Microsoft Dynamics AX albo Subiekta), potrzebna jest warstwa pośrednia i to jest pierwszy realny koszt projektu.
To są nudne wymagania, ale ich niedopełnienie kończy się portalem, który technicznie działa, a operacyjnie nikt mu nie ufa, bo dane w ERP i w portalu się rozjeżdżają.
Co dalej
Jeśli rozpoznajesz w swoim zaopatrzeniu ten wzorzec — 9 godzin tygodniowo na dopytywanie i regularne spory o daty — warto zrobić dwie rzeczy przed rozmową z dostawcą oprogramowania.
Po pierwsze, przez tydzień policz uczciwie: ile telefonów, ile maili, ile wątków „a co z tą dostawą", ile godzin. Bez tej liczby nikt nie oceni sensownie, czy portal się zwróci.
Po drugie, sprawdź stan bazy dostawców w ERP. Duplikaty, brak NIP-ów, kilka rekordów tego samego kontrahenta — jeśli to widzisz, to jest twój projekt zero. Portal wdrożony na krzywych danych po prostu przełoży bałagan na inny ekran.
Jeśli chcesz rozmawiać o tym, jak taki portal wygląda konkretnie w warunkach twojej firmy, umów niezobowiązującą rozmowę. Pół godziny wystarczy, żeby ocenić, czy w ogóle warto to rozważać.
Portal dostawcy nie zastąpi zaopatrzeniowca. Ale przestanie palić mu tygodniowo dnia roboczego na telefonach o „czy potwierdzacie termin".