Jak podłączyć AI do starego programu bez API: Access, FoxPro, DOS i inne stare systemy firmowe

Stary program bez API nie jest przeszkodą dla AI, o ile potrafi wyeksportować dane albo zapisać raport do pliku. Access, FoxPro, dBase i własne aplikacje DOS-owe zwykle to umieją. AI czyta te pliki: tabele w formacie .dbf, eksporty do CSV, wydruki zapisane jako TXT, i odpowiada na pytania o dane tak, jakby miało dostęp do systemu na żywo. Stary program przez cały czas stoi i działa, my tylko czytamy jego eksporty.

Które stare systemy nadają się do takiej integracji

Zanim odpiszemy stary program jako "nie do podłączenia", warto sprawdzić co potrafi. Większość firm, z którymi rozmawiamy, ma co najmniej jeden z tych systemów:

• Microsoft Access (.mdb, .accdb): baza z tabelami i kwerendami. Eksport do CSV przez menu "Dane zewnętrzne > Eksportuj" albo bezpośredni odczyt przez ODBC. Daje się zautomatyzować makrem.
• FoxPro, dBase III/IV, Clipper, xBase: dane trzymane w plikach .dbf, często z towarzyszącymi .fpt (pola notatek) i .cdx (indeksy). Pliki .dbf to otwarty format: czyta je Python, LibreOffice Calc i dziesiątki innych narzędzi bez instalowania starego oprogramowania.
• Aplikacje DOS: wiele z nich obsługuje wydruk do pliku. Zamiast wysyłać raport na drukarkę, przekierowujemy go do pliku TXT. Efekt: czytelny plik tekstowy z danymi, gotowy do analizy.
• Stare systemy handlowe i kadrowe: Ramzes, R2Płatnik, Rewizor GT, starsze wersje Sage Symfonii. Większość ma opcję eksportu do pliku, nawet jeśli to tylko "zestawienie do Excela" z menu Raporty.

Co konkretnie wyciągamy? Nie ogólnie "dane", tylko konkretne tabele. Z systemu handlowego opartego na FoxPro typowo dostajemy pliki takie jak: KONTRAH.dbf z polami KOD, NAZWA, NIP, MIASTO, SALDO albo FAKTURA.dbf z polami NR_DOK, DATA_WYS, KWOTA_NET, KWOTA_VAT, TERMIN, CZY_ZAP. Z tabeli TOWAR.dbf wyciągamy pola KOD_TOW, NAZWA, CENA_ZAK, CENA_SPRZ, STAN_MAG. Nazwy różnią się między systemami, ale zazwyczaj są na tyle czytelne, że godzina z osobą znającą stary program wystarczy, żeby zrozumieć strukturę.

Jak wygląda eksport w praktyce

W przypadku Accessa: otwieramy bazę, klikamy prawym przyciskiem na tabelę "Klienci" i wybieramy "Eksportuj > Plik tekstowy". Dostajemy plik CSV. Jeśli firma chce mieć świeże dane każdego ranka, ustawiamy makro w Accessie, które odpala się o 6:00 i zapisuje eksport do wskazanego folderu sieciowego. Bez żadnego programisty po stronie firmy.

W przypadku FoxPro i dBase jest jeszcze prościej, bo pliki .dbf są po prostu na dysku serwera. Skrypt kopiuje je co noc do folderu roboczego. Nie trzeba nawet uruchamiać starego programu: czytamy pliki bezpośrednio.

Aplikacje DOS to osobny przypadek. U jednego z naszych klientów działał DOS-owy program magazynowy, który generował raport stanów na koniec dnia. Pracownik naciskał F9 "drukuj zestawienie", a my przekierowaliśmy wyjście drukowania na plik. Każdego wieczoru w folderze lądował plik STANY_20250131.TXT z tabelą w formacie ASCII. AI to czyta bez problemu.

Jedna zasada jest twarda: pracujemy wyłącznie w trybie odczytu. Niczego nie zapisujemy do bazy. Stary program działa dokładnie tak jak przed integracją.

Co AI robi z tymi danymi, czego stary program nie umie

Stary program odpowiada na pytania, które ktoś zaprogramował wiele lat temu. Nowych raportów nie doda bez programisty, a często tamten programista już nie jest dostępny albo kod jest utracony. AI czyta eksport i odpowiada na pytania ad hoc.

Firma handlowa w Łodzi używa FoxPro z lat 90. Plik FAKTURA.dbf ma ponad 180 000 wierszy. Handlowiec pyta: "Ile mamy niezapłaconych faktur od firmy ABC starszych niż 60 dni?". Stary program takiego raportu nie ma. AI patrzy na pole TERMIN i CZY_ZAP, liczy różnicę dat, filtruje po kontrahencie i odpowiada w kilka sekund.

Inne pytania, które zaczyna zadawać firma po takiej integracji:

• Zestawienie klientów według salda z zaznaczeniem, którzy przekroczyli limit kupiecki
• Historia zamówień dla konkretnego NIP-u, kiedy klient dzwoni z reklamacją
• Faktury bez numeru zamówienia (pole ZAMOW puste) pogrupowane według handlowca
• Towary z tabeli TOWAR, które nie mają ani jednej sprzedaży w ostatnich 12 miesiącach
• Klienci z polem MIASTO = "Warszawa" i saldem powyżej określonego poziomu

To pytania, na które firma czekała latami albo odpowiadała ręcznie w Excelu przez kilka godzin.

Zestawianie starych danych z nowym systemem

Bardzo typowa sytuacja w polskiej firmie: nowy ERP wdrożono w tym roku, ale stary system działa równolegle, bo tam jest cała historia sprzedaży z poprzednich lat. Klient dzwoni i pyta o zamówienia z ostatnich trzech lat. Nowy system ma tylko dziewięć miesięcy historii.

AI może zestawiać eksporty z obu systemów jednocześnie. Kluczem łączącym jest zwykle NIP albo kod kontrahenta. Zapytanie brzmi: "Ile łącznie kupił od nas klient ABC od 2022 roku?" AI sięga do starego eksportu i do nowego, sumuje i odpowiada.

Albo sytuacja z kontrolą jakości danych przed nowym wdrożeniem: nowy CRM ma pole NIP klienta, stara baza FoxPro też ma NIP w polu NIP_KONT. AI porównuje oba zbiory i wyciąga listę klientów, którzy mają w jednym systemie inny NIP niż w drugim. Takich rozbieżności w każdej bazie znajdzie się kilkanaście. Ręcznie nikt by ich nie szukał.

Jak AI pomaga przygotować migrację, zanim się ją zacznie

Migracja ze starego systemu do nowego ERP to jeden z kosztowniejszych projektów IT. Spora część kosztu bierze się z analizy: co jest w bazie, jak wygląda jakość danych, które tabele są aktywne, a które to historia sprzed dekady, której nikt już nie potrzebuje.

AI robi tę analizę szybciej niż konsultant przeglądający tabele ręcznie. Przykładowe pytania do bazy przed migracją:

• "Ile rekordów w tabeli KONTRAH ma puste pole NIP?"
• "Jakie formaty dat pojawiają się w polu DATA_WYS: czy są tam jednocześnie zapisy '31-01-2025', '20250131' i '01/31/25'?"
• "Ile jest zduplikowanych NIP-ów w tabeli KONTRAH pod różnymi nazwami?"
• "Które kody towarów z TOWAR nie mają ani jednego wpisu w FAKTURA z ostatnich dwóch lat?"
• "Które pola są prawie zawsze puste, bo nikt ich nie wypełniał?"

Zamiast tygodnia pracy konsultanta na wstępnej analizie danych, dostajemy raport w kilka godzin. Konsultant przychodzi już z gotowym obrazem problemów, a nie zaczyna od zera. Skraca to projekt i zmniejsza ryzyko, że po migracji odkryjemy, że coś ważnego zostało źle przeniesione.

Od czego zaczyna się taka integracja

Pierwsze spotkanie z tym tematem najczęściej wygląda tak: właściciel firmy wie, że gdzieś na dysku serwera jest folder z plikami .dbf albo kopia bazy Access, ale nikt od lat na to nie zaglądał. Punkt startowy jest prostszy niż się wydaje.

Cztery kroki:

• Identyfikacja: które pliki lub tabele mają interesujące dane. Zwykle wystarczy godzina z osobą, która zna stary program.
• Jednorazowy eksport: ręczny CSV albo skopiowane pliki .dbf. Na tym etapie nie potrzeba programisty.
• Pierwsze pytania do AI: sprawdzamy czy dane są czytelne, czy polskie znaki się wyświetlają, czy daty mają sensowny format.
• Automatyzacja: jeśli potrzebne są świeże dane co dzień, ustawiamy prosty skrypt eksportujący albo makro w Accessie. To jednorazowa praca.

Na pierwszych dwóch krokach można się zatrzymać i sprawdzić czy to w ogóle ma sens dla konkretnego systemu. Bez zobowiązań, bez ruszania starego programu. Wiele firm robi właśnie tak: eksportuje dane, zadaje kilka pytań i dopiero wtedy decyduje o kolejnym kroku.

Jeśli chcesz sprawdzić, co realnie można wyciągnąć z Twojego starego systemu, zacznij od bezpłatnego audytu. Patrzymy na konkretne pliki i mówimy wprost, co się da zrobić. A jeśli interesują Cię przykłady firm, które przeszły już przez taki proces, zajrzyj do realnych wdrożeń.