Wyobraźmy sobie firmę, która prowadzi jednocześnie kilkanaście projektów. Project Manager potrzebuje dodatkowych materiałów do jednej z realizacji. Dostaje wycenę od dostawcy, uzgadnia wydatek z przełożonym i składa zamówienie. Wszystko odbywa się w kilku mailach i może jednej wiadomości na Teamsie.
Dwa tygodnie później do księgowości trafia faktura. Trzeba ustalić, kto zrobił zakup, czy materiały dotarły, jakiego projektu dotyczyły i czy kwota zgadza się z wcześniejszymi ustaleniami. Księgowa pyta Project Managera, on szuka korespondencji, a później ktoś jeszcze dopisuje wydatek do arkusza z kosztami realizacji.
Każdy wykonał swoją część pracy, ale informacje o jednym zakupie znalazły się w kilku różnych miejscach. Obieg wniosku zakupowego ma połączyć tę historię od zgłoszenia potrzeby po dostawę, fakturę i rozliczenie projektu. Bez odtwarzania ustaleń za każdym razem, gdy zakup przechodzi do kolejnej osoby.
Wniosek zakupowy powinien znać projekt, zanim pracownik go wyśle
W firmie projektowej większość potrzeb zakupowych wynika z konkretnej realizacji. Materiał, usługa podwykonawcy, dodatkowy wydruk czy wynajęty sprzęt są potrzebne dlatego, że trzeba wykonać określone zamówienie klienta.
Skoro Project Manager zgłasza zakup z poziomu projektu, system ma już jego numer, klienta, osobę odpowiedzialną i terminy. W jednym z naszych wdrożeń zakupy przypisujemy nawet do konkretnych pozycji wyposażenia. Dzięki temu później można sprawdzić nie tylko koszt całego projektu, ale również to, ile kosztowało wykonanie danego elementu.
Pracownik powinien więc uzupełnić przede wszystkim to, czego system jeszcze nie zna: co chce kupić, w jakiej ilości, od jakiego dostawcy, za ile i na kiedy jest to potrzebne. Jeżeli otrzymał już ofertę lub proformę, może dołączyć dokument zamiast przepisywać całą jego zawartość.
Nie każda z tych informacji musi być obowiązkowa w każdej firmie. Jeżeli dostawca zostanie wybrany dopiero po akceptacji potrzeby, wymaganie jego nazwy na pierwszym formularzu tylko opóźni pracę. Wniosek ma zebrać dane potrzebne do decyzji, a nie zmuszać pracownika do zgadywania informacji, których jeszcze nie ma.
Kto akceptuje zakup? To zależy od tego, jak pracuje firma
W jednej firmie Project Manager sam decyduje o drobnych materiałach, a większe zakupy zatwierdza właściciel. W innej wszystkie zamówienia przechodzą przez zakupy, bo dział potrafi wynegocjować lepsze warunki. Jeszcze gdzie indziej najważniejsze jest to, czy wydatek mieści się w zaakceptowanym budżecie projektu.
Zanim zaprojektujemy obieg akceptacji, ustalamy właśnie te zasady. Kto ma prawo podjąć decyzję? Jakich danych potrzebuje? Kiedy zakup może przejść dalej bez dodatkowej zgody, a kiedy trzeba go zatrzymać?
System może kierować wnioski według wartości, typu kosztu, projektu lub uprawnień. To przykłady reguł, które da się zaprojektować - nie gotowy schemat, który narzucamy każdej firmie. Najważniejsze, żeby osoba zatwierdzająca od razu widziała, czego dotyczy zakup i jakie ma znaczenie dla realizacji.
Jeżeli wniosek wraca do poprawy, historia decyzji również powinna zostać przy tej samej sprawie. Pracownik nie musi wtedy od nowa tłumaczyć, dlaczego chciał kupić dany materiał.
Akceptacja wniosku nie oznacza, że zakup został zrealizowany
Załóżmy, że kierownik zatwierdził zakup materiałów do projektu za 8 000 zł. W raporcie warto już widzieć, że firma planuje taki wydatek. Ale nie oznacza to jeszcze, że materiały zostały zamówione, dostarczone albo że powstał koszt księgowy w tej kwocie.
Ostateczna cena może wynieść 7 600 zł. Dostawca może doliczyć transport. Część zamówienia może nie zostać dostarczona, a reszta przyjechać dopiero po kilku dniach.
Dlatego rozdzieliłbym w systemie co najmniej kwotę planowaną, zatwierdzoną wartość zakupu i rzeczywiste dane wynikające z zamówienia oraz otrzymanych dokumentów. Nie mieszamy zgody na poniesienie wydatku z fakturą, która pojawia się później.
To szczególnie ważne dla osoby prowadzącej projekt. Może ona zobaczyć przewidywane obciążenie budżetu, zanim wszystkie faktury trafią do księgowości. A gdy pojawią się faktyczne kwoty, porównać je z tym, co było wcześniej zaakceptowane.
Po zatwierdzeniu wniosek powinien przejść w zakup
W wielu firmach właśnie tutaj urywa się automatyzacja. Pracownik złożył formularz, przełożony go zaakceptował, ale osoba odpowiedzialna za zamówienie musi przepisać wszystkie informacje do kolejnego programu lub arkusza.
Skoro mamy już projekt, opis pozycji, ilość i ustaloną wartość, wykorzystajmy te dane dalej. Zakup otrzymuje status, osobę odpowiedzialną, dostawcę i planowany termin dostawy. Jeżeli zamówienie zostało złożone, Project Manager powinien móc to sprawdzić bez pisania kolejnego maila.
W naszym rozwiązaniu dla firmy projektowo-produkcyjnej zakupy są połączone z projektami i pozycjami wyposażenia. Możemy także odnotować planowaną dostawę i późniejsze przyjęcie towaru, w tym przyjęcie częściowe. To ma znaczenie, kiedy z dwudziestu zamówionych elementów dotarło na razie dwanaście, a realizacja zaczyna się za trzy dni.
Pracownika interesuje wtedy konkretna informacja: czy potrzebny materiał jest już dostępny, czy nadal czekamy na dostawcę. Osobny rejestr wniosków i osobny rejestr dostaw niewiele dadzą, jeżeli nikt nie zadba o połączenie tych danych.
Faktura trafia do księgowości. Skąd wiadomo, czego dotyczy?
To dla mnie najważniejszy fragment całego procesu.
Faktura zawiera dane dostawcy, pozycje i kwoty. Zwykle nie zawiera jednak informacji, który pracownik zamówił towar, kto zaakceptował zakup i do jakiego projektu należy przypisać koszt. Tę wiedzę firma miała już wcześniej - podczas składania wniosku i zamówienia.
Gdy faktura pojawia się w KSeF albo trafia do firmy inną drogą, księgowość powinna mieć możliwość powiązania jej z istniejącym zakupem. Wtedy może porównać dostawcę, zakres i kwoty oraz wychwycić różnice wymagające wyjaśnienia.
W naszym systemie faktury kosztowe są łączone z zakupami i projektami. Integracja z KSeF pomaga pozyskać dokumenty, ale sama faktura nie odtworzy informacji o tym, kto i po co coś zamówił. KSeF dostarcza dokument. Kontekst zakupu musi powstać wcześniej w firmie.
Z tego powodu nie traktuję elektronicznego obiegu faktur jako osobnej wyspy. Najwięcej pracy oszczędza wtedy, gdy dokument dołącza do zakupu, którego historia jest już zapisana.
Więcej o samym obiegu dokumentów piszemy w artykule o przygotowaniu firmy do KSeF.
A jeżeli jedna faktura dotyczy kilku projektów?
To w firmach projektowych zupełnie normalne. Jedno zamówienie od dostawcy może obejmować materiały do trzech realizacji. Bywa też, że część dostawy idzie bezpośrednio na projekt, a pozostała część trafia na magazyn.
W takim przypadku nie ma sensu przypisywać całej faktury do jednego zlecenia tylko dlatego, że system obsługuje jeden numer projektu na dokument. W naszym wdrożeniu pojedyncze pozycje faktury można rozdzielić ilościowo i kosztowo pomiędzy projekty oraz koszty ogólne firmy.
Dzięki temu Project Manager widzi koszt związany z własną realizacją, a zarząd otrzymuje bardziej użyteczny obraz jej rentowności. To także dobry przykład, dlaczego sam formularz wniosku zakupowego jest tylko początkiem. Największą wartość daje powiązanie zakupów, dokumentów i rozliczeń.
Taki przepływ może być częścią dedykowanego systemu ERP, szczególnie gdy firma prowadzi wiele projektów, zamówień i dostaw równolegle.
AI może odczytać proformę. Decyzję nadal podejmuje człowiek
Jeżeli dostawca przysłał wycenę w PDF-ie albo pracownik ma zrzut ekranu z informacjami o zakupie, nie ma większego sensu wymagać ręcznego przepisywania każdego pola.
W jednym z naszych wdrożeń pracownik może wkleić tekst, załączyć plik lub zrzut ekranu, a AI przygotowuje dane do formularza zakupu. Człowiek sprawdza wynik, uzupełnia braki i dopiero wtedy przekazuje sprawę dalej.
To jest dobre miejsce na wykorzystanie AI: odczytanie informacji, które już zostały zapisane w dokumencie. Model nie powinien sam zatwierdzać wydatku ani rozstrzygać, czy dana cena jest uzasadniona. Decyzja należy do osoby odpowiedzialnej za zakup.
Nie każdy zakup potrzebuje formalnego wniosku
Przy projektowaniu takich rozwiązań łatwo przesadzić w drugą stronę. Zakup drobnych materiałów za 20 zł nie powinien wymagać trzech zgód i wypełnienia formularza, którego obsługa kosztuje więcej niż sam materiał.
Dlatego poznajemy najpierw zasady, według których firma faktycznie kupuje. Czasami wystarczą limity wydatków i powiązanie z budżetem projektu. Czasami potrzebna jest pełna ścieżka zatwierdzania, bo zamówienia są duże, a za realizację odpowiada kilka działów.
Przy niewielkiej liczbie zakupów prosty formularz i dobrze prowadzony arkusz mogą wystarczyć. Dedykowany obieg zaczyna mieć sens, gdy firma regularnie odtwarza ustalenia z maili, szuka osób odpowiedzialnych za zakup, śledzi dostawy w osobnych miejscach i dopiero po otrzymaniu faktury ustala, ile naprawdę kosztował projekt.
Jak wygląda obieg zakupowy w Twojej firmie?
Zaczynam od przejścia przez kilka rzeczywistych zakupów. Jeden może dotyczyć zwykłego materiału, drugi kosztownej usługi podwykonawcy, a trzeci zamówienia, które trzeba było zmienić już po akceptacji.
Sprawdzamy, skąd wzięła się potrzeba, kto podjął decyzję, jak zamówiono towar i skąd księgowość dowiedziała się, do czego należy przypisać fakturę. Wtedy najczęściej widać, że wiele potrzebnych danych już istnieje. Tylko pracownicy muszą ich później szukać albo wprowadzać je ponownie.
Na tej podstawie projektujemy spójny obieg. W jednej firmie będzie to prosty wniosek z akceptacją. W innej trzeba od razu połączyć zakupy, dostawy, faktury i budżety projektów, bo te obszary korzystają z tych samych informacji. Przykład szerszego systemu opisujemy w artykule CRM dla firmy projektowej i produkcji na wymiar.
Dedykowane systemy tworzymy dla firm z centralnej Polski. Przyjeżdżamy na miejsce, rozmawiamy z zespołem i sprawdzamy proces na rzeczywistych dokumentach.
Pokaż nam jeden zakup - od zgłoszenia potrzeby do faktury przypisanej do projektu. Na takim przykładzie możemy ustalić, co warto uprościć i zautomatyzować.