Co właściwie mierzy gotowość
Gotowość do automatyzacji ma niewiele wspólnego z zaawansowaniem technicznym, a prawie wszystko ma związek z możliwością opisania procesu. Zespół, który potrafi określić, co uruchamia daną pracę, jakich informacji potrzebuje, jakie są zasady i do kogo należy wynik, jest gotowy, niezależnie od oprogramowania, na którym działa. Zespół, który nie może, nie jest jeszcze gotowy i nie ma żadnych zamienników narzędzi — automatyzacja zbudowana na nieudokumentowanym procesie automatyzuje wszystko, co zrobiła ostatnia osoba, łącznie z częściami, które były wadliwe.
Cztery rzeczy, na które zwraca uwagę ta kontrola
Pytania dotyczą przejrzystości procesu, tego, czy dane potrzebne do automatyzacji są dostępne za pośrednictwem interfejsu API, a nie zablokowane w czyimś arkuszu kalkulacyjnym, czy istnieje wyznaczony właściciel, który nadal będzie właścicielem przepływu pracy po sześciu miesiącach od uruchomienia oraz czy istnieje miernik, według którego można to ocenić. Słabość któregokolwiek z nich można naprawić w ciągu kilku tygodni i warto ją naprawić przed kompilacją, a nie w jej trakcie, ponieważ każda z nich staje się przeróbką, gdy kod już istnieje.
Co zrobić z niskim wynikiem
Niski wynik jest wynikiem określania zakresu, a nie odrzuceniem. Zwykle oznacza to, że pierwszy projekt powinien być mniejszy i nudniejszy niż planowano: skonsolidować kanały, którymi może dotrzeć zapytanie, zapisać z pamięci zasady, które ktoś aktualnie stosuje, lub zapewnić dostępność danych jednego systemu. Każdy z nich ma wartość sam w sobie i każdy usuwa przyczynę niepowodzenia ewentualnej automatyzacji. Audyt ma na celu określenie, który to jest, i jest to ta sama rozmowa, niezależnie od tego, czy wynik jest wysoki, czy niski.