Nowa moda w świecie AI dla firm: „zapytaj ERP-a po polsku". Właściciel wpisuje w okno czatu „ile zarobiliśmy na kliencie X w sierpniu", model tłumaczy to na SQL, uderza w bazę, zwraca liczbę. Na demie wygląda jak magia. W produkcji potrafi zwrócić liczbę, której po prostu nie ma.
To nie jest tekst o tym, że AI „nie działa". Text-to-SQL działa i w konkretnych zastosowaniach jest bardzo użyteczne. Chodzi o coś innego: o warunek, bez którego cała ta magia zamienia się w bardzo drogi generator wiarygodnie wyglądających bzdur. A warunek ten prawie nikt w MŚP nie spełnia od razu — i o tym najczęściej ofertujący nie mówi.
Gdzie pryska magia
Text-to-SQL zawodzi w polskich MŚP nie dlatego, że model języka jest za słaby. Zawodzi z trzech powodów, które są zawsze te same.
Po pierwsze — tabele w Twoim ERP są kryptyczne. Comarch Optima, enova365, Subiekt czy Microsoft Dynamics AX trzymają dane w tabelach o nazwach typu CDN.TraNag, K_KLIENT, TWG_ID. Kolumny nazywają się Kwo, TrN_TrNId, Typ_dokumentu. Model nie ma pojęcia, że Kwo to kwota netto, a TrN_TrNId to identyfikator nagłówka transakcji. Zgadnie — czasem trafnie, czasem nie. Nikt tego nie sprawdza, bo odpowiedź brzmi wiarygodnie.
Po drugie — definicja „przychodu" w Twojej firmie nie istnieje jednoznacznie. Zapytaj trzech osób w 30-osobowej firmie „ile sprzedaliśmy w sierpniu" i dostaniesz cztery odpowiedzi. Bo „sprzedaliśmy" oznacza: kwota z faktur (a co z korektami?), z zamówień (a co z niezrealizowanymi?), z wydań magazynowych (a co z reklamacjami?), po dacie sprzedaży czy dacie wystawienia (a co z fakturami wystawionymi z opóźnieniem?). Model tego nie wie. Zapyta bazę o pierwsze pole, które wygląda sensownie — i pokaże Ci liczbę.
Po trzecie — model halucynuje relacje między tabelami. Klasyczny przypadek: pytanie „ile zarobiliśmy na kliencie X" wymaga połączenia faktur z ceną zakupu (żeby policzyć marżę). W większości ERP-ów cena zakupu leży w zupełnie innej tabeli niż sprzedaż, a klucz łączący nie jest oczywisty (kod produktu z sufiksem, wariant, jednostka miary). Model klei to po podobieństwie nazw kolumn. Wyjdzie liczba, która wygląda jak marża, ale nie jest marżą.
Konkretny przykład z tego roku
U jednego z naszych klientów — 40-osobowej hurtowni części meblowych spod Wrocławia, pracującej na Comarch Optima — właściciel kupił od zewnętrznego dostawcy „inteligentnego asystenta do raportów". Pilotaż trwał trzy tygodnie i kosztował 28 000 zł.
Przez pierwsze dwa tygodnie wszyscy byli zachwyceni. „Ile sprzedaliśmy X-a w lipcu" — działało. „Kto z handlowców miał najwięcej zamówień w zeszłym miesiącu" — działało. „Pokaż top 10 klientów po obrocie" — działało. W trzecim tygodniu właściciel zadał pytanie o marżę na konkretnej grupie produktów. Model odpowiedział: „24,3%". Piękna, konkretna liczba.
Trzy dni później księgowa policzyła to samo ręcznie, na potrzeby raportu do banku. Wyszło 11,8%. Różnica bierze się stąd, że model połączył sprzedaż z ostatnią ceną zakupu z kartoteki produktu — a ceny zakupu w tej firmie rosły w ciągu roku o kilkanaście procent. Faktyczna marża liczy się z ceny zakupu konkretnej dostawy, z której zszedł towar. Model tego nie wiedział, bo nikt mu nie powiedział. Zgadł. Trafił źle.
Gdyby decyzja o cenniku na wrzesień poszła na podstawie tej liczby, firma dopłacałaby do połowy asortymentu przez cały kwartał.
Kiedy text-to-SQL naprawdę działa
Po tej lekcji tę samą firmę udało się doprowadzić do sensownego pilotażu. Zajęło to sześć tygodni i wymagało trzech rzeczy.
Warstwa raportowa, nie surowe tabele ERP. Zamiast pokazywać modelowi 400 tabel Comarch Optimy, zbudowaliśmy sześć „widoków raportowych" (SQL views) z jasno nazwanymi kolumnami: sprzedaz_netto_dokument, cena_zakupu_z_dostawy, marza_kwotowa, data_wystawienia, data_sprzedazy. Model widzi tylko te widoki. Nie ma jak zapytać złej tabeli, bo złych tabel dla niego nie ma.
Słowniczek pojęć biznesowych na piśmie. Do pilotażu dołączyliśmy jednostronicowy dokument: co dokładnie oznacza „sprzedaż", „marża", „obrót", „klient aktywny". Bez tego dokumentu nawet wersja z widokami zwraca różne liczby na to samo pytanie, bo model interpretuje słowa po swojemu. Ten słowniczek powstał na czterogodzinnym spotkaniu właściciela z księgową — i był najtrudniejszą częścią projektu, bo przy okazji wyszło, że oni sami się dotąd nie zgadzali.
Człowiek pomiędzy modelem a decyzją. Wszystkie liczby, na podstawie których firma zmienia cennik, negocjuje z dostawcą albo wchodzi w umowę powyżej 20 000 zł, przechodzą przez oczy księgowej. Model przyspiesza pracę — nie zastępuje odpowiedzialności. To banalne, ale zdziwiłbyś się, jak wiele wdrożeń o tym „zapomina".
Po tym pilotażu właściciel dostaje w minutę odpowiedź na 80% typowych pytań, które wcześniej wymagały 2–3 godzin pracy księgowej z Excelem. Pozostałe 20% (skomplikowane analizy wielookresowe, korekty, dokumenty specyficzne) nadal robi księgowa — i to jest w porządku.
Co zrobić przed pilotażem
Jeśli ktoś proponuje Ci text-to-SQL do Twojego ERP-a, zanim podpiszesz umowę, zapytaj o cztery rzeczy.
- Jak wygląda warstwa danych, na której będzie działać model? Czy to surowe tabele ERP (uciekaj), czy przygotowane widoki i modele semantyczne (rozmawiaj dalej)?
- Kto i kiedy przygotuje słowniczek pojęć biznesowych? Jeśli odpowiedź brzmi „model sam zrozumie z kontekstu" — nie zrozumie. To jest robota, którą musi wykonać ktoś, kto zna Twoją firmę.
- Jak walidowane są liczby zwracane przez model? Czy przez pierwszy miesiąc każda odpowiedź jest porównywana z ręcznym wyliczeniem? Czy jest audyt, który wychwyci „24,3% zamiast 11,8%"?
- Co się dzieje, gdy model odpowie źle? Czy w interfejsie widać wygenerowany SQL, żeby księgowa mogła zweryfikować, jakie tabele zostały użyte? Czy jest przycisk „to jest błąd, popraw definicję"?
Jeśli sprzedawca zbywa te pytania „AI to załatwi", masz do czynienia z demem, nie z produktem. W polskich MŚP demo działa trzy tygodnie. Potem ktoś podejmuje na tej podstawie decyzję i zaczyna się problem.
Co dalej
Text-to-SQL nie jest bzdurą. Jest narzędziem, które w odpowiednim ustawieniu naprawdę oszczędza kilkanaście godzin miesięcznie właścicielowi i zespołowi księgowemu. Ale „odpowiednie ustawienie" to nie licencja i logowanie do ERP-a. To warstwa raportowa, słowniczek pojęć i człowiek pilnujący, że liczby na koniec dnia się zgadzają.
Jeśli ktoś już Ci coś takiego oferuje albo sam rozważasz taki pilotaż — warto pół godziny porozmawiać z kimś, kto stawiał to w innych MŚP i widział, gdzie takie projekty się wykładają. Pierwsza rozmowa jest bezpłatna.
Model języka nie zna Twojej firmy. Zna nazwy kolumn — i zgaduje, co znaczą. Bez słowniczka pojęć i warstwy raportowej zgadnie źle.