Arkusze kalkulacyjne są w polskich firmach najpopularniejszą bazą danych — i jednocześnie najczęstszym źródłem błędów. Ktoś eksportuje raport z systemu magazynowego, ktoś inny ręcznie przepisuje dane z programu księgowego, trzecia osoba dokleja kolumnę i wysyła plik mailem. Automatyzacja tego obiegu bywa jednym z najszybciej opłacających się wdrożeń w firmie, ale tylko wtedy, gdy najpierw uporządkujemy strukturę danych. W tym artykule opisujemy, jak łączymy arkusze i bazy danych w działający obieg informacji, jakie problemy napotykamy najczęściej i w których sytuacjach automatyzacja arkuszy jest złym pomysłem.
Zanim zaproponujemy jakiekolwiek narzędzie, oglądamy pliki, na których firma faktycznie pracuje. Powtarzalny zestaw problemów wygląda tak:
Automatyzacja nałożona na taki bałagan po prostu przyspiesza powstawanie błędów. Dlatego pierwszym etapem prawie zawsze jest uporządkowanie danych, a nie podłączanie narzędzi.
Arkusz nadający się do automatyzacji ma prostą budowę: jeden wiersz nagłówka, poniżej wyłącznie dane, jeden wiersz to jeden obiekt (zamówienie, faktura, zgłoszenie), jedna kolumna to jedna cecha. Bez scalonych komórek, bez pustych wierszy rozdzielających sekcje, bez podsumowań w środku tabeli. Podsumowania i wykresy przenosimy do osobnej zakładki, która pobiera dane z tabeli źródłowej.
Aby połączyć dane z dwóch systemów, potrzebny jest wspólny identyfikator. Najczęściej używamy numeru NIP dla kontrahentów, kodu produktu dla asortymentu i numeru dokumentu dla transakcji. Jeżeli takich kluczy nie ma, trzeba je nadać — to praca jednorazowa, ale nie do pominięcia. Dla pól, które przyjmują ograniczony zbiór wartości (status, kategoria, magazyn), tworzymy słowniki i wymuszamy wybór z listy zamiast wpisywania tekstu.
Daty zapisane jako tekst, liczby z ręcznie wpisaną spacją jako separatorem tysięcy, kwoty ze znakiem waluty w komórce — to klasyczne przyczyny błędów przy imporcie. Ustalamy jeden format daty, liczby przechowujemy jako liczby, a jednostkę i walutę trzymamy w osobnej kolumnie albo w nagłówku.
Arkusz jest dobrym narzędziem do analizy i do niewielkich zbiorów. Przestaje wystarczać, gdy pojawia się przynajmniej jeden z tych warunków: kilka osób edytuje dane jednocześnie, liczba wierszy rośnie do dziesiątek tysięcy, potrzebna jest kontrola uprawnień na poziomie pojedynczych rekordów albo wymagana jest pełna historia zmian.
W takich sytuacjach proponujemy przeniesienie danych do bazy — może to być baza relacyjna na serwerze firmy, baza w usłudze chmurowej albo narzędzie typu baza z interfejsem tabelarycznym, wyglądające dla użytkownika podobnie do arkusza, ale działające jak baza danych. Wybór zależy od liczby użytkowników, wymogów dotyczących lokalizacji danych i tego, czy firma ma kogoś, kto to utrzyma.
Migracja z arkusza do bazy to osobny projekt. Obejmuje zaprojektowanie tabel i relacji, czyszczenie danych historycznych, przeniesienie ich z zachowaniem powiązań, przygotowanie widoków i formularzy dla użytkowników oraz okres równoległej pracy na obu rozwiązaniach. Nie zalecamy przełączania z dnia na dzień.
Automatyzacja na styku arkuszy i baz sprawdza się przede wszystkim w zadaniach powtarzalnych i opartych na jasnych regułach:
Nie automatyzujemy czynności, które wymagają oceny sytuacji: decyzji o przyjęciu reklamacji, ustalenia warunków handlowych, korekty danych, gdy dwa źródła się nie zgadzają. Automat może przygotować zestawienie rozbieżności, ale rozstrzygnięcie zostaje przy człowieku. Nie automatyzujemy też procesów, które zmieniają się co miesiąc — koszt ciągłego przerabiania reguł przewyższa oszczędność.
Kolejność preferencji jest u nas stała. Najpierw sprawdzamy, czy system udostępnia interfejs programistyczny — to najbardziej stabilne rozwiązanie. Jeśli nie, szukamy możliwości zaplanowanego eksportu do pliku w ustalonym formacie i katalogu. Dopiero na końcu rozważamy odczytywanie danych z interfejsu użytkownika, bo takie rozwiązania psują się przy każdej aktualizacji programu i wymagają stałej opieki.
Rzadko łączymy systemy bezpośrednio ze sobą. Zwykle budujemy warstwę pośrednią: dane są pobierane, sprawdzane, przekształcane do wspólnego formatu i dopiero potem zapisywane w miejscu docelowym. Dzięki temu zmiana jednego z systemów nie wymaga przebudowy całości, a błędne rekordy można zatrzymać przed zapisaniem.
Każda integracja kiedyś się zatrzyma — system będzie niedostępny, zmieni się układ kolumn, ktoś wpisze tekst w polu liczbowym. Projektujemy więc automatyzację tak, żeby błąd był widoczny: powiadomienie do wskazanej osoby, dziennik zdarzeń z informacją, co się nie udało, i mechanizm ponowienia. Cicha awaria, po której dane po prostu przestają się aktualizować, jest znacznie groźniejsza niż awaria głośna.
Ustalamy, czy dane mają być aktualizowane w czasie rzeczywistym, czy wystarczy cykl godzinowy lub nocny. W większości przypadków cykl nocny jest w zupełności wystarczający, tańszy i mniej obciąża systemy źródłowe. Aktualizacja natychmiastowa ma sens tam, gdzie ktoś podejmuje decyzje na bieżąco — na przykład przy rezerwacji towaru.
Integracje zwykle wymagają dostępu do danych finansowych i osobowych, dlatego traktujemy je jak element infrastruktury, a nie jak dodatek.
Do połączeń tworzymy osobne konta techniczne z minimalnym zakresem uprawnień — konto pobierające dane sprzedażowe nie potrzebuje prawa do usuwania rekordów. Klucze dostępowe przechowujemy w menedżerze haseł lub w magazynie sekretów, nigdy w treści arkusza ani w skrypcie. Połączenia szyfrujemy. Pliki wymiany danych trzymamy w katalogu z ograniczonym dostępem i ustalamy, po jakim czasie są kasowane.
Osobno konfigurujemy kopie zapasowe. Automatyzacja potrafi w kilka sekund nadpisać tysiące wierszy błędnymi danymi — bez kopii z poprzedniego dnia odtworzenie stanu bywa niemożliwe. Kopie muszą być przechowywane poza systemem, który jest kopiowany, i okresowo testowane pod kątem odtwarzalności.
Na koszt składa się analiza i uporządkowanie danych, budowa integracji, testy oraz późniejsze utrzymanie. Zwykle pierwszy element jest największy, a przy zaniedbanych arkuszach potrafi przekroczyć koszt samej automatyzacji.
Zwrot szacujemy dwutorowo. Pierwszy tor to czas: ile godzin miesięcznie zajmuje dziś ręczne przenoszenie i uzgadnianie danych. Drugi, często ważniejszy, to koszt błędów: pomyłki w stanach magazynowych, błędne zamówienia, korekty dokumentów. Ten drugi trudniej policzyć, ale w firmach handlowych i produkcyjnych bywa dominujący.
Praktyczna zasada: automatyzacja zadania wykonywanego raz w miesiącu przez piętnaście minut rzadko się opłaca. Automatyzacja zadania wykonywanego codziennie przez pół godziny — prawie zawsze.
Integracje nie są bezobsługowe. Systemy źródłowe są aktualizowane, zmieniają się formaty eksportu, wygasają klucze dostępowe, ktoś dodaje kolumnę do arkusza. Umawiamy się na przegląd co kwartał: sprawdzamy dzienniki zdarzeń, liczbę błędów, czas wykonania, aktualność uprawnień.
Prowadzimy też krótką dokumentację: co skąd jest pobierane, jak często, kto jest właścicielem procesu i co zrobić, gdy integracja się zatrzyma. Bez tego po roku nikt w firmie nie wie, dlaczego dane pojawiają się w danym arkuszu ani kogo pytać, gdy przestaną.
Odradzamy, gdy proces nie jest ustabilizowany. Jeśli firma dopiero zmienia sposób pracy albo planuje wymianę systemu magazynowego w najbliższych miesiącach, budowanie integracji z rozwiązaniem, które zniknie, jest marnowaniem środków.
Odradzamy też automatyzację opartą wyłącznie na odczytywaniu ekranu programu, jeśli firma nie godzi się na regularne poprawki. Takie rozwiązania są kruche i wymagają opieki po każdej aktualizacji.
Trzeci przypadek to sytuacja, gdy dane wejściowe pochodzą z formularzy wypełnianych swobodnym tekstem i nikt nie chce ich ustandaryzować. Automat będzie wtedy generował więcej wyjątków do ręcznej obsługi, niż zaoszczędzi pracy.
Czwarty to procesy wykonywane rzadko i przy okazji podlegające ocenie człowieka. Tam lepiej sprawdzi się dobrze przygotowany szablon i krótka instrukcja niż automat, którego nikt nie pamięta, jak obsłużyć.
Nie. Bardzo często arkusz zostaje jako wygodny interfejs do przeglądania i analizy, a zmienia się tylko sposób, w jaki trafiają do niego dane — zamiast ręcznego wklejania pojawia się automatyczne zasilanie. Przeniesienie do bazy proponujemy dopiero wtedy, gdy arkusz przestaje radzić sobie z liczbą użytkowników lub rekordów.
Sprawdzamy, czy pozwala na zaplanowany eksport do pliku — to zwykle wystarcza. Jeśli i tego nie ma, można sięgnąć po odczyt bezpośrednio z bazy danych programu, o ile dostawca na to pozwala, albo po automatyzację obsługi interfejsu. Ostatni wariant traktujemy jako rozwiązanie tymczasowe, bo wymaga stałych poprawek.
Proste połączenie dwóch źródeł z cyklicznym odświeżaniem uruchamiamy zwykle w kilka dni roboczych. Projekt obejmujący uporządkowanie danych historycznych i migrację do bazy to kwestia tygodni, w zależności od stanu danych i liczby wyjątków w procesie.
Powinna zgłosić awarię, a nie zniknąć po cichu. Konfigurujemy powiadomienie do wskazanej osoby, dziennik zdarzeń i ponowienie próby. Dodatkowo zostawiamy opisaną procedurę ręcznego wykonania procesu, żeby firma nie stanęła, zanim usterka zostanie usunięta.
Zależy od konfiguracji. Sprawdzamy lokalizację przetwarzania danych, zakres uprawnień konta technicznego, sposób logowania i zasady przechowywania kopii. Dla danych, które nie mogą opuścić firmy, budujemy rozwiązanie działające wyłącznie w sieci lokalnej — kosztem wygody dostępu spoza biura.
Ustalamy to na starcie. Albo przejmujemy utrzymanie w ramach stałej opieki, albo przekazujemy dokumentację i szkolimy osobę po stronie firmy. Nie zostawiamy integracji bez wskazanego właściciela, bo taka konfiguracja prędzej czy później przestanie działać i nikt nie będzie wiedział dlaczego.
Kontakt: 22 390 56 49 — telefon czynny całą dobę, siedem dni w tygodniu. Obsługujemy Grodzisk Mazowiecki i okolice.
Arrived compass prepare an on as. Reasonable particular on my it in sympathize. Size now easy eat hand how. Unwilling he departure elsewhere dejection at. Heart large seems may purse means few blind.