Kiedy projekt automatyzacji utknął w martwym punkcie lub przynosi nierzetelne wyniki, rozmowa zazwyczaj kieruje się w stronę dostawcy, stosu technologicznego lub złożoności przepływu pracy. Rzadko kiedy kieruje się ku temu, co najczęściej jest rzeczywiście odpowiedzialne: jakości i spójności danych, na których działa bot.
TrueFocus Automation, firma z Dallas zajmująca się automatyzacją RPA i AI, specjalizująca się w ubezpieczeniach tytułów własności i operacjach hipotecznych, zetknęła się z tym bezpośrednio. Po zbudowaniu bota dla zastrzeżonego systemu tytułów własności klienta, automatyzacja działała – do czasu, gdy przestała. Proces wydawał się działać poprawnie. Zespół klienta nie zgłaszał zastrzeżeń. Następnie pojawił się nowy zespół operacyjny i zaczął pytać, dlaczego pewne dokumenty nie pojawiają się w wynikach wyszukiwania.
Odpowiedź nie leżała w błędzie bota. Tkwiła w dziesięcioleciach niespójnego indeksowania danych.
Ukryty problem w systemach dziedzicznych
Niespójne dane historyczne to jeden z najczęstszych trybów awarii w projektach automatyzacji obejmujących platformy dziedziczne, zastrzeżone bazy danych lub długo działające wewnętrzne systemy ewidencji – i jeden z najmniej omawianych.
Wspomniany klient przez około trzydzieści lat ręcznie indeksował rekordy systemu tytułów własności. W tym czasie sposób wprowadzania tych rekordów ulegał zmianie. Konwencje nazewnictwa dokumentów nie były spójne i zawierały różne odniesienia do aktu własności, takie jak DEED22W/1774, a inne były indeksowane jako 22/1774, D22-1774, D22W-1774. Kiedy TrueFocus zbudował bota wyszukującego według numeru dokumentu, zwracał on tylko rekordy zaindeksowane w określony sposób i pomijał wszystko wprowadzone według innego schematu lata wcześniej.
Sridhar Loganathan, dyrektor operacyjny TrueFocus Automation, opisał ten schemat: „Dane leżące u podstaw nie są spójne. Przez te trzydzieści lat zmieniali sposób indeksowania dokumentów. Kiedy zbudowaliśmy bota wyszukującego według numeru dokumentu, pojawiały się tylko te dokumenty, a nie pozostałe."
Bot robił dokładnie to, do czego został zbudowany. Dane leżące u jego podstaw nigdy nie były spójne od samego początku.
Co naprawdę oznacza gotowość danych przed automatyzacją
Gotowość danych nie polega na tym, czy Twoje dane są cyfrowe. Chodzi o to, czy Twoje dane są wystarczająco spójne, aby system oparty na regułach mógł je niezawodnie odpytywać. Bot nie może podejmować ocennych decyzji. Jeśli dokument jest indeksowany w jeden sposób w 2003 roku, a w inny przez kolejne lata, bot za każdym razem znajdzie jeden i pominie drugi – na dużą skalę.
Pytania warte zadania przed rozpoczęciem jakiegokolwiek projektu automatyzacji obejmują: Jak długo te dane znajdują się w tym systemie? Czy podejście do indeksowania zmieniało się z czasem? Czy różne zespoły były odpowiedzialne za wprowadzanie danych w różnych momentach i czy pracowały według tych samych standardów? Czy istnieje jakiś proces weryfikujący spójność w całym zbiorze danych?
To nie są wygodne pytania, a odpowiedzi są często gorsze niż oczekiwano. Jednak wydobycie ich na etapie analizy kosztuje znacznie mniej niż odkrycie ich po sześciu miesiącach prac deweloperskich.
TrueFocus traktuje teraz tego rodzaju przegląd danych jako standardową część procesu analizy wstępnej, szczególnie w przypadku klientów pracujących z zastrzeżonymi lub długo działającymi platformami wewnętrznymi. Logika jest prosta: automatyzacja amplifikuje to, co już istnieje w Twoich danych. Jeśli dane są niespójne, automatyzacja ujawnia tę niespójność w tempie i na dużą skalę.
Problem zaangażowania klienta, który pogarsza sytuację
Przypadek TrueFocus niesie ze sobą drugą lekcję. Automatyzacja działała na żywo przez pewien czas, zanim problem jakości danych wyszedł na jaw. Pierwotny zespół korzystający z systemu nie zgłaszał brakujących dokumentów – niezależnie od tego, czy nie zauważył braków, nie powiązał luk z automatyzacją, czy też nie eskalował problemu, wynik był ten sam: problem narastał po cichu.
Kiedy pojawił się nowy zespół i zaczął zadawać pytania, luki stały się widoczne. Do tego czasu TrueFocus działał w oparciu o założenia dotyczące wydajności systemu, których klient nigdy nie skorygował.
Loganathan wskazał bezpośrednio na główną przyczynę: klientowi brakowało jednego punktu kontaktowego z głębokim zrozumieniem sposobu działania własnej platformy, a między osobami korzystającymi z wyników a zespołem zarządzającym systemem nie było regularnej pętli informacji zwrotnej. Zespół korzystał z rozwiązania, ale nigdy nie zgłaszał, że czegoś brakuje. Bez tej iteracyjnej komunikacji problemy narastały, aż stały się kosztowne do naprawienia.
Automatyzacja wymaga ciągłego nadzoru. Boty muszą być monitorowane, wyjątki przeglądane, a osoby polegające na wynikach muszą pozostawać w regularnym kontakcie z tym, kto zarządza systemem.
Jak wygląda uczciwy proces analizy wstępnej
Dla firm oceniających dostawców automatyzacji gotowość do ujawniania problemów przed rozpoczęciem projektu, a nie po dostawie, jest jedną z najbardziej wartościowych rzeczy, jakie dostawca może zaoferować.
TrueFocus stoi na stanowisku, że zidentyfikowanie problemu jakości danych w pierwszym tygodniu jest lepsze niż dostarczenie automatyzacji, która działa nieregularnie i podważa zaufanie do technologii. Oznacza to sesje obserwacyjne, podczas których zespół wykonujący rzeczywistą pracę przechodzi przez proces na żywo. Oznacza pytanie nie tylko o to, jak przepływ pracy funkcjonuje dziś, ale jak zmieniał się z czasem i czy dane źródłowe odzwierciedlają te zmiany w sposób spójny. I oznacza gotowość do poinformowania potencjalnego klienta, że jego dane nie są gotowe – nawet gdy to nie jest to, co chce usłyszeć.
W przypadku, który ostatecznie zakończył współpracę TrueFocus z tym klientem, współzałożyciel Jimmy Lewis podjął decyzję bezpośrednio: „Jeśli nie możemy tego zrobić, powiedzmy im teraz. Nie chcę tego przeciągać." Ta rozmowa odbyła się później niż powinna, ale zasada jest słuszna. Dostawca gotowy powiedzieć Ci, że projekt nie jest gotowy, jest cenniejszy niż ten, który przyjmuje zlecenie i dostarcza coś zawodnego.
Jimmy Lewis jest współzałożycielem TrueFocus Automation, specjalisty w zakresie automatyzacji przepływów pracy opartej na RPA i AI dla branży ubezpieczeń tytułów własności, hipotecznej i nieruchomości. TrueFocus opracował ponad 840 botów automatyzacji wspierających ponad 2 500 przepływów pracy i zwrócił klientom ponad 1,3 miliona godzin produkcyjnych.
Niniejszy artykuł opiera się na informacjach dostarczonych przez wymienione powyżej źródło eksperckie. Jest przeznaczony wyłącznie do ogólnych celów informacyjnych i nie stanowi porady prawnej, finansowej ani dotyczącej nieruchomości. Czytelnicy powinni przeprowadzić własne badania i skonsultować się z wykwalifikowanymi specjalistami przed podjęciem jakichkolwiek decyzji dotyczących nieruchomości lub finansów.
