Stara aplikacja często nadal trzyma ważny proces. Zamiast obiecywać natychmiastową wymianę, mogę najpierw udokumentować zależności, zabezpieczyć dane i wydzielić jeden potrzebny krok.
Firma pracuje na programie, który powstał lata temu: baza Access z makrami VBA, aplikacja czytająca pliki DBF, eksport do Płatnika, raport działający na jednym komputerze. Nikt tego nie chce ruszać, bo działa, i wszyscy się boją, bo nie ma dokumentacji ani kontaktu do autora. Zaczynam od kopii i opisania zależności, a nie od wymiany systemu.
Ważny raport działa tylko na komputerze jednej osoby i nikt nie zna całej procedury.
Plik Access, arkusz VBA albo baza DBF jest potrzebna, ale nie ma już wygodnego wsparcia.
Firma chce wyciągnąć dane do SQL lub raportu, lecz boi się naruszyć działającą aplikację.
Nowy system ma powstać później, ale dziś trzeba bezpiecznie obsłużyć jeden konkretny proces.
Pliki DBF (dawne FoxPro, Clipper, stare programy magazynowe) da się przenieść do SQL Servera lub PostgreSQL etapami: najpierw kopia i inwentaryzacja tabel, potem mapowanie pól i typów, potem migracja próbna z porównaniem liczności i sum kontrolnych. Stare źródło zostaje do czasu, aż wynik przejdzie test.
Po przejściu z Office 32-bit na 64-bit przestają działać deklaracje API, sterowniki ODBC i część makr. Podobnie bywa z eksportem do Płatnika, gdy zmieni się format pliku. Naprawiam jeden krytyczny raport albo jeden eksport, zamiast przepisywać całą aplikację.
Aplikacja legacy nie musi zniknąć, żeby dane trafiły do sklepu, portalu B2B albo panelu raportowego. Ograniczam zakres do jednego modelu danych, ustalam bezpieczny sposób odczytu i buduję na tym warstwę, którą można rozwijać dalej.
Najpierw zabezpieczam kopię i ustalam, co naprawdę jest potrzebne. Czasem wystarczy raport albo eksport, a czasem warto przygotować migrację.
Sprawdzam deklaracje, sterowniki, połączenia i makra, które przestały działać po zmianie Office. Celem może być przywrócenie jednego krytycznego raportu, nie przebudowa całego systemu.
Przy migracji starej bazy ustalam tabele, klucze i pola używane w procesie, a potem porównuję liczność oraz wartości w kopii testowej. Nie zaczynam od usuwania starego źródła.
Jeśli program działa tylko na jednym komputerze albo zależy od starego sterownika, mogę zacząć od inwentaryzacji, odczytu danych i opisania zależności.
Wydzielam potrzebne pola i reguły z istniejącej aplikacji, żeby przygotować raport lub eksport bez naruszania reszty procesu.
Stary program może zostać źródłem danych dla portalu B2B, ERP albo własnego API. Najpierw ograniczam zakres do jednego modelu danych i sprawdzam sposób odczytu.
Dobieram narzędzia do konkretnego przepływu. Nie zakładam z góry wymiany systemu ani budowy dużej platformy.
Zaczynam od tego, co istnieje: plików, baz, wersji, zależności i sposobu wykonywania procesu.
Opisuję struktury i reguły w uzgodnionym zakresie, żeby można było rozmawiać o danych bez zgadywania.
Jeśli wystarcza odczyt, zaczynam od raportu, eksportu albo małego panelu zamiast pełnej wymiany systemu.
Gdy modernizacja ma sens, dzielę ją na dane, procesy i testy, z warunkiem akceptacji przed kolejnym etapem.
Pierwsza rozmowa jest bezpłatna. Cenę podaję po zobaczeniu procesu, nie z cennika. Jeśli da się to rozwiązać prościej albo gotowym narzędziem, mówię o tym na początku.
Najpierw zapisujemy najważniejszy proces i sytuacje, których nie wolno przerwać w trakcie analizy.
Zakres dostępu ustalamy pod cel. Nie modyfikuję produkcyjnych danych bez osobnego uzgodnienia.
Raport lub eksport ma mieć sprawdzalną liczbę rekordów, pola kontrolne i listę wyjątków.
Może nim być kolejny raport, adapter, migracja jednego modułu albo decyzja o pozostawieniu systemu bez zmian.
Najpierw jeden przepływ, potem reszta. Zakres, kolejność prac i jedna cena na piśmie, zanim zacznę.
Logi, raport odrzuconych rekordów i dokumentacja. Przy aktualizacji ERP wiadomo, co się stało i gdzie szukać.
Po wdrożeniu zostaję do obsługi i rozwoju. Płatna miesięcznie, bez umowy rocznej. Rozmawiasz ze mną, nie z działem.
Przejmuję też rozwiązania, które zrobił ktoś inny: najpierw diagnoza cudzego kodu i logów, potem możliwie mała poprawka, na końcu dokumentacja przepływów i sposobu restartu.
Wystarczy krótki opis: jakie systemy są zaangażowane, co robisz ręcznie i jaki wynik chcesz sprawdzać. Odpowiadam w 24 h. Rozmawiasz bezpośrednio ze mną.