Arkusze kalkulacyjne w transporcie - skąd biorą się błędy i koszty pracy

Arkusze kalkulacyjne w transporcie i punkt, w którym przestają wystarczać

Arkusz kalkulacyjny jest naturalnym pierwszym narzędziem firmy transportowej. Nie wymaga wdrożenia, każdy spedytor potrafi z niego korzystać, a rejestr zleceń powstaje w jedno popołudnie. Problem pojawia się nie w samym Excelu, tylko w chwili, gdy ten sam plik zaczyna pełnić rolę bazy danych dla kilku osób jednocześnie.

Limity techniczne programu rzadko są pierwszą przeszkodą. Arkusz mieści ponad milion wierszy, co opisuje specyfikacja i limity programu Excel. Wcześniej ujawniają się ograniczenia procesu: brak wymuszonych reguł, brak kontroli równoległej pracy i brak historii decyzji.

Koszt, którego nie widać w budżecie

Arkusz nie generuje faktury od dostawcy, więc jego koszt nie pojawia się w żadnej pozycji budżetu. Składa się z godzin pracy spedytorów poświęconych na przepisywanie i szukanie aktualnej wersji oraz z pomyłek, które wychodzą dopiero przy rozliczeniu. Dopóki nikt tych godzin nie mierzy, rozwiązanie wydaje się bezpłatne.

Wersje pliku i praca wielu osób

Najczęstszy mechanizm strat to rozjazd wersji. Spedytor otwiera plik, a jego kolega zapisuje zmianę kilka minut wcześniej w innej kopii. Zapis późniejszy nadpisuje wcześniejszy albo tworzy plik z dopiskiem w nazwie, a po kilku tygodniach nikt nie wie, która wersja jest obowiązująca.

Współtworzenie dokumentu w chmurze ogranicza część tych problemów, bo łączy zmiany w różnych komórkach. Nie rozwiązuje jednak konfliktów logicznych. Dwóch spedytorów może w tym samym czasie przypisać ten sam pojazd do dwóch kursów, a arkusz przyjmie oba wpisy bez ostrzeżenia, ponieważ dla niego są to po prostu dwie różne komórki.

Reguła: arkusz łączy zmiany w komórkach, a nie znaczenie biznesowe tych zmian, więc konflikt dwóch decyzji wychodzi na jaw dopiero na trasie.

Baza danych rozwiązuje ten problem przez kontrolę współbieżności. W SQL Server do wykrycia równoległej zmiany służy kolumna typu rowversion, której wartość zmienia się przy każdej modyfikacji wiersza. Aktualizacja powiedzie się tylko wtedy, gdy wartość odczytana wcześniej nadal jest aktualna.

-- przykładowe nazwy, nie schemat konkretnego produktu
UPDATE dbo.Zlecenie
SET    PojazdId = @PojazdId
WHERE  ZlecenieId = @ZlecenieId
  AND  RowVer     = @RowVerOdczytany;   -- zmiana jest odrzucana, jeśli ktoś zmienił wiersz wcześniej

IF @@ROWCOUNT = 0
    THROW 50001, 'Zlecenie zostało zmienione przez innego użytkownika.', 1;

Drugi spedytor dostaje komunikat zamiast cichego nadpisania. Kolejność działań jest w ten sposób jednoznaczna, a spór o to, kto pierwszy przypisał pojazd, rozstrzyga zapis w bazie.

Ręczne przepisywanie danych i typowe błędy

Dane o zleceniu trafiają do arkusza z maila lub z systemu klienta, a czasem po rozmowie telefonicznej. Każdy taki transfer jest przepisaniem. Błąd przy przepisywaniu rzadko jest spektakularny. Zwykle jest to cyfra w numerze zlecenia, zła data albo stawka skopiowana z poprzedniego wiersza, a skutek pojawia się dopiero przy fakturowaniu.

Ostatni przypadek jest szczególnie podstępny, bo wynik wygląda wiarygodnie. Wywołanie z domyślnym trybem przybliżonym zwraca wartość nawet wtedy, gdy nie ma dokładnego dopasowania, i nie zgłasza błędu.

=WYSZUKAJ.PIONOWO(A2; Stawki!A:C; 3; PRAWDA)
=WYSZUKAJ.PIONOWO(A2; Stawki!A:C; 3; FAŁSZ)

Pierwsza formuła szuka dopasowania przybliżonego i wymaga posortowanej tabeli stawek. Druga szuka dopasowania dokładnego i zwraca błąd #N/D, gdy przewoźnika nie ma na liście. W rejestrze stawek błąd widoczny od razu jest lepszy niż wynik, który wygląda poprawnie.

W bazie danych te same błędy są odcinane na poziomie definicji tabeli. Typ kolumny wyklucza tekst w polu liczbowym, ograniczenie CHECK nie przepuszcza stawki ujemnej, a klucz obcy nie pozwala przypisać zlecenia do nieistniejącego przewoźnika.

CREATE TABLE dbo.Zlecenie (
    ZlecenieId     INT IDENTITY PRIMARY KEY,
    NumerZlecenia  VARCHAR(30)   NOT NULL UNIQUE,
    PrzewoznikId   INT           NOT NULL REFERENCES dbo.Przewoznik (PrzewoznikId),
    DataRozladunku DATE          NOT NULL,
    StawkaPln      DECIMAL(10,2) NOT NULL CHECK (StawkaPln > 0),
    RowVer         ROWVERSION
);

Brak historii zmian i odpowiedzialności

Kiedy klient kwestionuje stawkę albo termin, firma musi odtworzyć treść zlecenia z chwili jego przyjęcia. Historia wersji pliku pokazuje kolejne zapisy całego skoroszytu, a nie decyzje dotyczące pojedynczego zlecenia. Odtworzenie, kto zmienił jedną komórkę, wymaga porównania kilku wersji obok siebie, i to tylko wtedy, gdy nikt ich nie skasował.

W systemie z bazą danych każda zmiana ma autora i czas. SQL Server oferuje do tego tabele czasowe, które zachowują poprzednie wersje wierszy i pozwalają zapytać o stan zlecenia z wybranego dnia. Producent oprogramowania może też prowadzić własny dziennik zmian, jeśli logika biznesowa tego wymaga.

CREATE TABLE dbo.StawkaPrzewoznika (
    StawkaId     INT IDENTITY PRIMARY KEY CLUSTERED,
    PrzewoznikId INT           NOT NULL,
    StawkaPln    DECIMAL(10,2) NOT NULL,
    ValidFrom    DATETIME2 GENERATED ALWAYS AS ROW START NOT NULL,
    ValidTo      DATETIME2 GENERATED ALWAYS AS ROW END   NOT NULL,
    PERIOD FOR SYSTEM_TIME (ValidFrom, ValidTo)
) WITH (SYSTEM_VERSIONING = ON);

SELECT StawkaPln
FROM   dbo.StawkaPrzewoznika FOR SYSTEM_TIME AS OF '2026-08-01T00:00:00'
WHERE  PrzewoznikId = 12;

Drugie zapytanie zwraca stawkę przewoźnika sprzed kilku tygodni, a więc taką, jaka obowiązywała w dniu zlecenia, a nie taką, jaka jest wpisana dzisiaj. W arkuszu to samo wymaga zachowania osobnej kopii pliku z każdego miesiąca.

Co wynika z braku historii

Brak śladu zmian osłabia pozycję firmy w sporze i utrudnia wewnętrzne wyjaśnianie błędów. Spedytor, który poprawił stawkę, nie zawsze pamięta o tym po kilku tygodniach. Dyrektor, który pyta o powody spadku marży, dostaje zestawienie bez wskazania, od którego dnia zmieniły się dane wejściowe.

Z tego samego powodu trudniej obsługiwać zgłoszenia dotyczące uszkodzonych lub opóźnionych przesyłek. Firmy, które równolegle prowadzą obsługę reklamacji związanych z przewożonym towarem, potrzebują danych o zleceniu, a także o trasie i kierowcy, dostępnych od razu, bez przeszukiwania kolejnych plików.

Poufność danych i kontrola dostępu

Arkusz zawierający stawki i marże oraz dane klientów krąży po firmie jako załącznik maila, kopia na dysku sieciowym albo plik na prywatnym telefonie. Każda kopia jest osobnym zbiorem danych, którego nikt nie kontroluje. Odejście pracownika oznacza, że część tych kopii zostaje poza firmą.

Ochrona arkusza hasłem zapobiega przypadkowej edycji komórek, ale nie działa jak system uprawnień. Nie rozróżnia ról ani nie zapisuje, kto odczytał dane, i nie pozwala odebrać dostępu do pliku, który już został skopiowany. W systemie z bazą danych zakres widoczny dla każdej roli wynika z konta użytkownika, a wszystkie zmiany trafiają do jednego, kontrolowanego miejsca.

Jak policzyć koszt pracy w arkuszu

Decyzję o zmianie narzędzia łatwiej uzasadnić liczbami z własnej firmy niż ogólnymi stwierdzeniami. Pomiar zajmuje kilka tygodni i nie wymaga żadnego oprogramowania. Wystarczy, że spedytorzy zapisują, ile czasu poświęcają na wybrane czynności.

• Czas przepisywania - minuty na wprowadzenie jednego zlecenia z maila lub telefonu do arkusza, pomnożone przez liczbę zleceń w miesiącu.
• Czas szukania - minuty na ustalenie aktualnego statusu oraz stawki, a także wersji pliku przed odpowiedzią klientowi.
• Liczba korekt - faktury poprawiane po wykryciu błędu w danych źródłowych w danym miesiącu.
• Czas zestawień - godziny potrzebne na przygotowanie rozliczenia z przewoźnikiem lub raportu rentowności.

Sumę czasu zamienia się na koszt, mnożąc ją przez koszt godziny pracy spedytora. Wynik jest liczbą własną firmy, którą można porównać z kosztem wdrożenia systemu. Nie ma sensu przyjmować wartości z innych firm, bo zależą od liczby zleceń, od rozmiaru zespołu i od struktury klientów.

Uzupełnieniem jest zestawienie kosztu błędów: zdublowanych zleceń, nieaktualnych stawek za kilometr oraz przeoczonych terminów płatności faktur od przewoźników. Trudniej je zmierzyć, ale zwykle łatwo wskazać przykłady z ostatniego kwartału. Ogólne porównanie obu podejść zawiera osobny artykuł o Excelu w transporcie a systemie TMS.

Jak zacząć wdrożenie systemu TMS w firmie transportowej

Rezygnacja z arkuszy nie wymaga przełączenia całej firmy w jeden dzień. Dobrą praktyką jest wdrożenie etapami, od jednego obszaru, na przykład ewidencji zleceń i rozliczeń z przewoźnikami. Planowanie tras i monitoring floty dołącza się dopiero po ustabilizowaniu pierwszego procesu. Taka kolejność ogranicza ryzyko i pozwala zespołowi oswoić się z narzędziem.

System TMS, taki jak Linkway.TMS, zbiera dane o klientach i pojazdach oraz o kierowcach i ładunkach w jednym miejscu. Kolejność prac przy takim wdrożeniu opisuje artykuł o czterech etapach wdrożenia Linkway.TMS, a przykład z małej firmy zawiera tekst o programie TMS w małej firmie transportowej.

Migracja danych z arkuszy

Import z Excela zaczyna się od tabeli pośredniej, do której trafiają surowe wiersze bez żadnych reguł. Dopiero z niej dane trafiają do tabel docelowych po sprawdzeniu, czy spełniają warunki. Najprostsza kontrola wykrywa numery zleceń, które w arkuszu wystąpiły dwa razy.

-- przykładowa tabela pośrednia z surowym importem z arkusza
SELECT  NumerZlecenia, COUNT(*) AS Wystapien
FROM    stg.ZleceniaExcel
GROUP BY NumerZlecenia
HAVING  COUNT(*) > 1;

Wynik tego zapytania jest pierwszym raportem jakości danych. Każdy zdublowany numer trzeba rozstrzygnąć ręcznie: albo to ten sam kurs wpisany dwa razy, albo błąd w numerze. Doświadczenie z podobnych migracji opisuje tekst o migracji z Excela do programu magazynowego, a do ewidencji palet odnosi się porównanie ewidencji palet w Excelu i w dedykowanym programie.

Po przeniesieniu danych arkusz przestaje być źródłem prawdy. Zostawia się go w trybie tylko do odczytu jako archiwum, żeby nikt nie wprowadzał zleceń w dwóch miejscach naraz. Równoległe prowadzenie obu rejestrów przez dłuższy czas odtwarza problem rozjazdu wersji, tyle że między arkuszem a systemem.

Telematyka i integrator obok TMS

Po ustabilizowaniu rozliczeń dołącza się dane z pojazdów. Producent opisuje, jak łączy śledzenie i telematykę z zarządzaniem flotą, na stronie o łączeniu telematyki z flotą. Integrator zbiera dane z różnych systemów GPS w jednym miejscu i może działać jako uzupełnienie systemu TMS, a nie jego zamiennik. Więcej o tym mechanizmie znajdzie się w opisie linkway.INTEGRATOR.

Kierowców wciąga się do procesu na końcu, gdy zlecenia są już rzetelnie wprowadzone do systemu. Aplikacja mobilna zbiera wtedy statusy i dokumenty bezpośrednio, co opisuje artykuł o aplikacji dla kierowcy. Rezerwację terminów rozładunku, która w wielu firmach również żyje w arkuszu, omawia tekst o kalendarzu rezerwacji jako alternatywie dla Excela.