Technologia, która orzeźwia jak napoje. Jak system ERP przyspieszył w ON LEMON produkcję o 35%?

„Nie poprawiają natury – wyciskają z niej to, co najlepsze” – tak brzmi motto pracowników ON LEMON, katowickiego producenta i dystrybutora naturalnych lemoniad, soków i herbaty. Problem pojawia się wtedy, gdy dynamiczny wzrost uniemożliwia wyciskanie kolejnych owoców pracy i hamuje rozwój. Odpowiedzią na te wyzwania stało się wdrożenie nowoczesnego oprogramowania ERP, które w zaledwie trzy miesiące odmieniło środowisko pracy w organizacji.

ON LEMON Sp. z o.o. obsługuje w ON trade ponad 2 tys. klientów rocznie, a ich produkty – naturalne napoje – trafiają do przeszło 800 punktów sprzedaży. Choć historia marki zaczęła się w Katowicach, ich napoje podbijają dziś Europę. Orzeźwiające smaki można znaleźć na półkach restauracji czy sklepów ponad 20 krajów, m.in. w Niemczech, Belgii, Francji, Hiszpanii, Wielkiej  Brytanii, Czechach, Bułgarii czy nawet Islandii.

Excel na “off”, technologia na “ON”

Tak intensywna ekspansja wymaga zaawansowanego planowania, ale też nowoczesnej technologii. Zwłaszcza że firma na skutek rozwoju zaczęła zmagać się z kilkoma wyzwaniami. Głównym hamulcem były rozproszone dane – ON LEMON brakowało jednej, zcentralizowanej bazy klientów i kontrahentów, co wymuszało ręczne zakładanie kart i nierzadko powodowało niespójności. Podobnie sytuacja wyglądała z analityką i raportowaniem – raporty sprzedaży czy te związane z wydanymi towarami były tworzone ręcznie lub częściowo w Excelu.

Kolejnym obszarem wymagającym usprawnienia stała się praca w terenie: brand managerowie pracujący z klientami nie mieli mobilnego dostępu do aktualnych danych o stanach magazynowych, płatnościach czy historii współpracy. Problem powodowała też utrudniona obsługa zamówień i procesów magazynowych (np. brak zintegrowanego systemu do składania zamówień w imieniu klientów oraz mechanizmu do obsługi zamówień z przeliczeniami). Co więcej, przedstawiciele handlowi nie dostawali aktualnych informacji o przeterminowanych płatnościach, co uniemożliwiało szybką reakcję na zaległości.

Wystarczyły trzy miesiące

Tak szeroki wachlarz potrzeb wymagał holistycznego spojrzenia. Z pomocą przyszła technologia w postaci systemu Comarch ERP XL, który w organizacji wdrożył Partner, firma Kotrak. Oprogramowanie krakowskiej spółki informatycznej gwarantowało nie tylko pełną integrację różnych procesów biznesowych i skalowalność, ale też pełną zgodność z przepisami polskiego prawa czy bogaty zestaw modułów do konkretnych zadań.

Po zdiagnozowaniu problemów przystąpiono do wdrażania narzędzi. System wraz z pakietem aplikacji zintegrowanych (obejmującym moduły od produkcji, księgowości, aż po Business Intelligence) uruchomiono w firmie w zaledwie trzy miesiące. Dzięki temu środowisko operacyjne ruszyło pełną parą tuż przed startem sezonu wysokiej sprzedaży napojów.

Implementacja objęła szereg nowoczesnych rozwiązań, takich jak automatyczny import faktur z rozlewni do systemu ERP czy pełna integracja aplikacji z systemami zewnętrznymi firmy (m.in. z e-sklepem i narzędziami do zarządzania obiegiem dokumentów).

Na tym nie koniec

Efekty wdrożenia widać w twardych liczbach: 35-procentowe przyspieszenie realizacji zleceń produkcyjnych. Co ważne, nowy system zapewnił cyfryzację pracy w terenie, uproszczenie sprzedaży (poprzez automatyczne przesyłanie dokumentów do klientów) oraz integrację procesów w rozlewni (dokumenty są generowane na podstawie pliku i automatycznie przetwarzane przez Comarch ERP XL).

Bardzo ciekawym rozwiązaniem stała się też dedykowana aplikacja dla klientów, dzięki której mogą oni składać zamówienia, kontrolować swoje salda czy sprawdzać historię zamówień. Zmienił się też komfort pracy załogi – dzięki panelowi magazyniera pracownicy zawsze wiedzą, co dokładnie mają przygotować do wysyłki. Technologia wsparła też wiedzę Zarządu, który zyskał dostęp do aktualnych danych i raportów o stanach magazynowych, co pozwala mu podejmować decyzje oparte na twardych liczbach.

Polecamy system Comarch ERP XL, który skutecznie automatyzuje pracę oraz integratora i wdrożeniowca aplikacji, firmę Kotrak S.A., dzięki której pracujemy na stabilnym oprogramowaniu i mamy nieustanne wsparcie powdrożeniowe – mówi Robert Orszulak, założyciel ON LEMON. – Nie poprzestajemy na dotychczas zrealizowanych zadaniach. Mamy plany dotyczące dalszego rozwoju wdrożonych systemów. Oprogramowanie dorównuje kroku rozwojowi naszej firmy i wraz ze wzrostem potrzeb, będziemy je dynamicznie dostosowywać do naszych bieżących wymagań – dodaje.

—–

O Comarch

Comarch został założony w 1993 roku w Krakowie. Jest jedną z największych firm informatycznych w Europie, prowadzi projekty dla czołowych marek z Polski i świata w najważniejszych sektorach gospodarki, m.in.: telekomunikacji, finansach, bankowości i ubezpieczeniach, handlu i usług, infrastruktury IT, przemyśle, ochronie zdrowia oraz w sektorze małych i średnich przedsiębiorstw. Z usług Comarch skorzystało kilkadziesiąt tysięcy światowych marek w ponad 100 krajach na 6 kontynentach m.in.: Allianz, Auchan, BNP Paribas Fortis, BP, Carrefour, Heathrow Airport, Heineken, ING czy LG U+, Orange, Telefónica, T-Mobile, Vodafone.

Firma zajmuje wysokie pozycje w rankingach analityków IT m.in.: Gartnera, Truffle 100, TOP 200 „Computerworld”, IDC, Polskiej Akademii Nauk, EU Industrial R&D Investment Scoreboard. Obecnie zatrudnia 5000 ekspertów.

www.comarch.pl

Twoja firma nie potrzebuje programistów, żeby naprawić procesy biznesowe

Low-code i no-code brzmią jak kolejne modne hasła z konferencji IT – ale za nimi kryje się coś bardzo praktycznego: możliwość budowania i zmieniania procesów bez udziału programistów i IT. Brzmi jak niemożliwa obietnica ze slajdu handlowca? Być może, ale rozwiązania low-code i no-code dają naprawdę duże możliwości, a procesy biznesowe – w tym zarządzanie dokumentacją, są tego najlepszym dowodem.

Low-code, no-code… Co to właściwie jest?

Low-code i no-code to platformy do tworzenia procesów biznesowych, np. obiegu dokumentów, akceptacji, formularzy, powiadomień – bez pisania kodu (no-code) lub z minimalnym udziałem programisty (low-code). Zamiast opisywać wymagania, wysyłać ticket, czekać w kolejce do developerów i angażować na kilka miesięcy zespół IT, sam projektujesz proces lub jego zmianę: definiujesz etapy, przypisujesz role, ustawiasz reguły.

No-code sprawdza się przy prostych, powtarzalnych procesach, natomiast low-code daje więcej możliwości: integracje z ERP, CRM czy systemem kadrowym, złożone reguły, wielopoziomowe akceptacje. Wspólnym mianownikiem jest to, że biznes nie musi czekać na IT, żeby coś zmienić, bo można to zrobić „tu i teraz” nie będąc programistą.

Gdzie warto zastosować no-code i low-code?

Tam, gdzie procesy są powtarzalne i angażują wielu ludzi: obieg faktur, wnioski zakupowe, akceptacje umów, archiwizacja dokumentów.

Klasyczny scenariusz: zmiana przepisów wymusza aktualizację ścieżki akceptacji. Tradycyjnie wyglądałoby tak: zgłoszenie do IT, analiza, wycena, kilkutygodniowa realizacja. A na platformie low-code – zmiana w konfiguracji, test, wdrożenie. Całość zamknie się w dniach, czasem nawet w godzinach.

Firmy, które potrafią szybciej dostosować procesy do zmieniających się warunków, lepiej reagują na zmiany na rynku, które z roku na rok są coraz częstsze. Te, które czekają miesiącami na każdą zmianę, tracą czas i pieniądze w miejscach, o których często nawet nie wiedzą. Często nie dlatego, że proces jest zły, tylko nikt go nie ruszył, bo zmiana kosztowała za dużo wysiłku.

Ale zanim zaczniesz wszystko automatyzować…

Trzeba powiedzieć wprost o ryzykach, bo entuzjazm wobec low-code potrafi przysłonić zdrowy rozsądek.

Automatyzacja źle zaprojektowanego procesu nie rozwiązuje problemu, tylko go skaluje. Jeśli obieg faktur jest chaotyczny, przeniesienie go do systemu da jedynie większy chaos. Tak samo, gdy każdy dział buduje własne procesy bez koordynacji z resztą firmy, to firma traci kontrolę nad tym, co w niej działa i jak – a przeniesienie tego stanu do systemu jedynie utrwali problem.

Żadne z tych ryzyk nie przekreśla low-code – ale one dobrze pokazują, dlaczego nie warto wchodzić w ten temat na własną rękę i po omacku, bez partnera technologicznego, który pomoże wybrać platformę, zaprojektować pierwszy proces i ustawić governance od początku.

Jeśli zastanawiasz się, od którego procesu zacząć i czy low-code sprawdzi się w Twojej firmie – umów się na bezpłatną konsultację z zespołem LOGITO . Sprawdzimy, co warto usprawnić i jak powinien przebiegać proces, aby uniknąć błędów.

E-faktura ląduje w systemie. I co dalej? 4 sytuacje, w których pobrana faktura sprawia problem

KSeF ustandaryzował wymianę faktur między firmami a administracją skarbową. Teraz każdy przedsiębiorca dostaje e-fakturę w ujednoliconym formacie XML i pobiera ją z jednego miejsca. To duży krok w stronę cyfrowej dokumentacji. Ale ten sam dokument, który właśnie trafił do systemu, musi jeszcze przejść przez firmę – zostać przypisany do działu, zweryfikowany, zaakceptowany i zaksięgowany. I tutaj zaczyna się prawdziwa praca.

Przez ostatnie miesiące rozmawiałam z wieloma organizacjami integrującymi swoje systemy z KSeF. Część z nich borykała się z tym samym problemem: „faktura jest w systemie, ale nie ma jasnej ścieżki, co z nią dalej zrobić”. Nie dlatego, że brakuje ludzi ani chęci. Dlatego, że KSeF kończy swoją pracę na progu systemu. Dokument jako nośnik danych i zdarzeń procesowych to często tylko teoria – w praktyce musi zapaść decyzja odnośnie do tego, kto dokument widzi, kto akceptuje i kiedy można go zaksięgować.

Poniżej opisuję cztery sytuacje, które powtarzają się w przypadku faktur pobieranych z KSeF, i pokazuję, jak radzi sobie z nimi system elektronicznego obiegu dokumentów w postaci ANEGIS Document Flow (ADF).

Problem 1: Faktura bez właściciela to początek chaosu

Zacznijmy od tzw. problemu kotleta. Dwudziestu handlowców, jedno miasto, jeden oddział. Sprzedawca wychodzi na obiad z klientem, prosi kelnera o fakturę na firmę. Dokument pojawia się w KSeF, stamtąd trafia do księgowości. Kto go zamówił? Po co? Z jakiego budżetu? Odpowiedzi nie ma, bo nikt nie poinformował działu finansów o spotkaniu w restauracji. Przy dziesięciu takich fakturach dziennie to drobna niedogodność. Przy stu – codzienne śledztwo.

Rozwiązaniem jest powiązanie faktury z zamówieniem wewnętrznym jeszcze zanim dokument trafi do KSeF. W ADF sprzedawca tworzy zamówienie wewnętrzne z telefonu: wpisuje datę, przybliżoną kwotę i cel wydatku. Numer zamówienia trafia na fakturę (w polu notatki lub dedykowanym polu zamówień), a system automatycznie łączy oba dokumenty, gdy e-faktura pojawi się w KSeF.

A jeśli ktoś przypomniał sobie o zamówieniu dopiero w drodze powrotnej? Może je utworzyć po fakcie, wpisując dokładną kwotę i datę. Osoba weryfikująca widzi listę aktywnych zamówień i przypisuje właściwe po kwocie i dacie. Kilkanaście sekund zamiast kilkunastu minut. I od razu wiadomo, kto odpowiada za ten wydatek – ścieżka akceptacji wyznacza się automatycznie, bez maili i telefonów. Cały mechanizm działa bez pisania kodu: zamówienia wewnętrzne i reguły akceptacji konfiguruje się przez interfejs użytkownika.

Problem 2: Faktura od dostawcy, którego nikt nie zna

Nie każdy dokument wystawiony na NIP firmy jest dokumentem uprawnionym do rozliczenia. Kontrahent mógł pomylić numer albo ktoś celowo wystawił fakturę na cudze dane. W 2024 roku Krajowa Administracja Skarbowa wykryła w Polsce ponad 290 tys. fikcyjnych faktur VAT. To nie są abstrakcyjne liczby – to dokumenty, które przez jakiś czas krążyły po obiegach różnych firm, zanim ktoś je zatrzymał.

Problem nie w tym, żeby taką fakturę odrzucić. Problem w tym, żeby ją w ogóle zauważyć, zanim przejdzie dalej w procesie i zostanie opłacona.

ADF stosuje prostą regułę: jeśli NIP dostawcy nie pasuje do żadnego podmiotu w bazie, faktura stoi. Na ekranie pojawia się komunikat. Nawet jeśli osoba weryfikująca kliknie „dalej”, system faktury nie przepuści. Dopóki dostawca nie zostanie zidentyfikowany i zaakceptowany przez właściwą osobę, dokument czeka w kolejce. To pierwsza linia obrony, zanim sprawa trafi do compliance.

Problem 3: Drobne błędy, które blokują automatyczne księgowanie

KSeF waliduje strukturę XML, więc formalnie każda e-faktura powinna być poprawna. W teorii tak to działa. W praktyce, po rozmowach z firmami integrującymi się przez API, okazuje się, że rozbieżności zdarzają się regularnie – nieprawidłowo zmapowana stawka VAT przy usłudze mieszanej, brakujące pole przy fakturze za usługę objętą odwrotnym obciążeniem. Błędy niszowe, ale wystarczające, żeby automatyczne księgowanie stanęło, a ktoś musiał szukać problemu w pliku XML.

ADF podchodzi do tego dwutorowo. Po pierwsze zakładka „Informacje o dokumencie” zbiera najważniejsze dane faktury na jednym ekranie – osoba weryfikująca nie musi przeskakiwać między plikiem XML, systemem ERP i arkuszem kalkulacyjnym. Wszystko widać w jednym miejscu. Po drugie – jeśli pojawiają się poważne niezgodności (brak dostawcy, nieprawidłowy numer, różnica w kwotach), system wymusza korektę przed przejściem do akceptacji. Faktura z nierozwiązanym błędem po prostu nie przejdzie dalej.

Ręczna weryfikacja na jednym widoku zajmuje ułamek czasu w porównaniu z sytuacją, gdzie trzeba otworzyć plik XML, zestawić z danymi w ERP, znaleźć rozbieżność i ręcznie poprawić rekord. Reguły walidacji można też rozszerzać samemu, bez angażowania programistów.

Problem 4: Jedna faktura, dwa źródła, jedno ryzyko

Dostawca wysyła fakturę mailem jako PDF. Równolegle ten sam dokument trafia do KSeF. Dział finansów zadaje sobie pytanie: przetwarzać wersję z maila od razu, czy czekać na KSeF?

Jeśli przetworzymy za wcześnie – istnieje ryzyko podwójnego zaksięgowania. Jeśli wstrzymamy wszystko – blokujemy też faktury od zagranicznych dostawców, których KSeF nie obowiązuje.

ADF rozwiązuje to przez konfigurowalne oczekiwanie. Faktura odebrana mailem automatycznie dostaje status „Czeka na KSeF” i przez zdefiniowany czas (np. 24 godziny) system wstrzymuje dalsze procesowanie. Gdy e-faktura z KSeF dotrze, ADF porównuje dane obu wersji. Jeśli się różnią, nadrzędna jest wersja KSeF jako dokument urzędowy – system aktualizuje rekord automatycznie.

Dostawcy zagraniczni? Na karcie kontrahenta wystarczy jedno oznaczenie. Od tego momentu ich faktury z maila trafiają do przetwarzania bez czekania na KSeF, którego i tak nie będzie.

Routing: od pobrania faktury do przekazania właściwej osobie

Wszystkie cztery opisane sytuacje sprowadzają się do jednego pytania: co właściwie zrobić z tym dokumentem i kto powinien się nim zająć?

ADF odpowiada na to przez routing – konfigurowalny zestaw reguł, który klasyfikuje każdą fakturę automatycznie. System pobiera dokumenty z KSeF w ustalonych odstępach czasowych, odczytuje dane (NIP dostawcy, kwoty, pozycje), sprawdza warunki i przypisuje fakturę do właściwego działu, właściciela dokumentu oraz osoby odpowiedzialnej za budżet. Akceptacja trafia do wyznaczonych osób przez Teams lub e-mail.

Reguły można łączyć dowolnie i definiować oddzielnie dla każdej firmy w organizacji wielofirmowej. Jeśli na fakturze od konkretnego dostawcy pojawia się słowo „kawa” – dokument ląduje w administracji. Jeśli kwota przekracza próg – akceptacja trafia do dyrektora finansowego, a przy niskich kwotach może przebiegać automatycznie, bez angażowania kogokolwiek. Routing kontroluje też uprawnienia: faktura przeznaczona wyłącznie dla zarządu nie trafi przypadkiem do asystenta działu sprzedaży. Klasyfikacja odbywa się zanim ktokolwiek otworzy dokument.

Jeśli chcesz zobaczyć, jak konfigurowalna jest kolejka i ekran routingu w ADF – nagrałam demonstrację na webinar „Pobierasz fakturę z KSeF. Co potem?”.

Tu obejrzysz nagranie: https://www.anegis.com/pl/wydarzenia/pobierasz-fakture-z-ksef-co-potem-zautomatyzuj-przeplyw-dokumentow-z-anegis-document-flow

Różne źródła, jeden uporządkowany obieg

KSeF to jedno ze źródeł faktur, nie jedyne. ADF obsługuje też załączniki PDF z poczty (przez OCR) i skany dokumentów papierowych. Niezależnie od tego, skąd pochodzi dokument – ścieżka jest identyczna: klasyfikacja, akceptacja, eksport do ERP. System integruje się z aplikacjami klasy Microsoft Dynamics 365 i kończy pracę na zaakceptowanej, poprawnej fakturze gotowej do zaksięgowania. Żadnego ręcznego przepisywania danych między systemami.

Co istotne z perspektywy wdrożeń: ADF nie zastępuje istniejącego ERP. Działa obok niego – przejmuje fakturę przy wejściu, prowadzi ją przez obieg, a na końcu eksportuje gotowy rekord. Dotychczasowe narzędzia zostają na swoim miejscu. Konfiguracja routingu i reguł odbywa się przez interfejs, bez pisania kodu, więc zmiany w procesie można wprowadzać samodzielnie, bez angażowania działu IT przy każdej korekcie.

E-faktura to dane, obieg to decyzje

KSeF standaryzuje format dokumentu i porządkuje przepływ między firmami. ADF decyduje, co dzieje się z fakturą wewnątrz organizacji – tam, gdzie KSeF już nie sięga, a ręczna praca kosztuje więcej czasu i błędów, niż się wydaje na pierwszy rzut oka.

Natalia Górnikowska, Power Platform Specialist, ANEGIS