Nie każda powtarzalna czynność zasługuje na skrypt. Rozstrzyga rachunek: ile czasu zajmuje, jak często wraca i co się dzieje przy pomyłce.
Prosty rachunek
Czynność zajmująca dziesięć minut dziennie to około czterdziestu godzin rocznie. Skrypt pisany pół dnia zwraca się w drugim tygodniu.
Rachunek jest uczciwy dopiero wtedy, gdy po obu stronach wpiszemy to samo. Po stronie pracy ręcznej liczy się nie tylko samo wykonanie, ale też przerwanie innego zadania, szukanie pliku, czekanie na eksport i poprawianie tego, co poszło nie tak. Po stronie skryptu — nie tylko napisanie, ale też rozpoznanie procesu, testy i poprawki w pierwszych tygodniach.
Częstotliwość waży więcej niż jednorazowy czas. Czynność godzinna wykonywana raz na kwartał rzadko wygrywa z pięciominutową powtarzaną każdego ranka.
Ryzyko pomyłki ważniejsze od czasu
Czynność krótka, ale wykonywana ręcznie na danych produkcyjnych, bywa warta automatyzacji nawet przy zerowej oszczędności czasu. Skrypt robi to samo za każdym razem. Człowiek robi to samo do dnia, w którym w połowie operacji zadzwoni telefon.
Jest jeszcze drugi powód, żeby automatyzować mimo braku oszczędności: czynność wykonuje jedna osoba i nikt poza nią nie wie jak. Urlop albo zmiana pracy zatrzymuje wtedy proces. Skrypt z opisem w nagłówku jest formą przekazania tej wiedzy dalej — szerzej opisuje to tekst o dokumentacji i ewidencji skryptów.
Kiedy nie warto
- czynność jednorazowa i prosta,
- reguły zmieniają się przy każdym wykonaniu,
- wymagana jest ocena człowieka,
- skrypt byłby dłuższy do napisania niż suma wszystkich przyszłych wykonań,
- proces ma się wkrótce zmienić — automatyzujemy wtedy coś, czego zaraz nie będzie.
Osobny przypadek to czynność, którą da się usunąć ustawieniem w programie, który firma już ma. Zanim powstanie nowe narzędzie, warto sprawdzić, czy system nie robi tego sam po włączeniu jednej opcji.
Koszt utrzymania
Skrypt też się psuje: zmienia się format pliku, struktura bazy, wersja środowiska. Do rachunku wchodzi nie tylko napisanie, ale i pilnowanie.
Narzędzie uruchamiane bez nadzoru potrzebuje dziennika i powiadomienia o błędzie. Bez nich jego awaria wychodzi na jaw dopiero wtedy, gdy ktoś zauważy brak wyniku — zwykle długo po fakcie. Różnicę w wymaganiach wobec kodu użytego raz i uruchamianego codziennie opisuje tekst o skrypcie jednorazowym i narzędziu stałym.
Najpierw opis
Spisanie czynności krok po kroku często ujawnia, że da się ją uprościć albo w ogóle wyeliminować. To tańsze niż automatyzowanie bałaganu.
Ten sam opis jest podstawą wyceny. Przy zadaniach prostych i powtarzalnych wiele rozwiązań jest gotowych, więc wdrożenie zamyka się w kilka dni i rozliczenie stawką godzinową wystarcza. Zadanie z wieloma wyjątkami wymaga najpierw audytu procesu. Audyt jest płatny, ale to on rozstrzyga, czy skrypt ma sens, i chroni przed napisaniem narzędzia do czynności, która powinna zniknąć.
