Когда проект автоматизации застревает или даёт ненадёжные результаты, разговор обычно переходит к поставщику, технологическому стеку или сложности рабочего процесса. Редко он касается того, что чаще всего действительно виновато: качества и согласованности данных, с которыми работает бот.
TrueFocus Automation, базирующаяся в Далласе RPA и ИИ-компания по автоматизации, специализирующаяся на страховании титула и ипотечных операциях, столкнулась с этим напрямую. После создания бота для проприетарного реестра прав собственности клиента автоматизация работала — до тех пор, пока не перестала. Процесс, казалось, выполнялся правильно. Команда клиента не выражала опасений. Затем пришла новая операционная команда и начала задавать вопросы: почему определённые документы не появляются в результатах поиска.
Причина была не в изъяне бота. Всё дело в десятилетиях непоследовательной индексации данных.
Скрытая проблема устаревших систем
Непоследовательные исторические данные — одна из наиболее распространённых причин сбоев в проектах автоматизации, связанных с устаревшими платформами, проприетарными базами данных или долгосрочными внутренними системами учёта записей, и одна из наименее обсуждаемых.
Клиент вручную индексировал записи реестра прав собственности на протяжении примерно тридцати лет. За это время способ ввода этих записей менялся. Соглашения об именовании документов не были последовательными: одни записи содержали разные ссылки на Deed, например DEED22W/1774, другие индексировались как 22/1774, D22-1774, D22W-1774. Когда TrueFocus создала бота, осуществляющего поиск по номеру документа, он возвращал только записи, проиндексированные определённым образом, и пропускал всё, что было введено по другой схеме годами ранее.
Sridhar Loganathan, операционный директор TrueFocus Automation, описал эту закономерность: «Данные, лежащие в основе, непоследовательны. На протяжении тех тридцати лет они меняли способ индексирования документов. Когда мы создали бота, выполняющего поиск по номеру документа, в результатах появлялись только эти документы, но не остальные».
Бот делал именно то, для чего был создан. Данные под ним никогда и не были последовательными.
Что на самом деле означает готовность данных перед автоматизацией
Готовность данных — это не вопрос того, являются ли ваши данные цифровыми. Речь идёт о том, достаточно ли они последовательны для того, чтобы система на основе правил могла надёжно их запрашивать. Бот не способен принимать взвешенные решения. Если документ проиндексирован одним способом в 2003 году и другим — в последующие годы, бот каждый раз найдёт один и пропустит другой — в масштабе.
Вопросы, которые стоит задать перед началом любого проекта автоматизации: как долго эти данные находятся в системе? Менялся ли подход к индексированию со временем? Были ли разные команды ответственны за ввод данных на разных этапах, и работали ли они по единым стандартам? Существует ли какой-либо процесс проверки согласованности набора данных?
Это не удобные вопросы, и ответы на них нередко оказываются хуже, чем ожидалось. Однако выявление этих проблем на этапе исследования обходится значительно дешевле, чем их обнаружение после шести месяцев разработки.
TrueFocus теперь рассматривает подобную проверку данных как стандартную часть процесса исследования — особенно для клиентов, работающих с проприетарными или давно функционирующими внутренними платформами. Логика проста: автоматизация усиливает всё, что уже присутствует в ваших данных. Если данные непоследовательны, автоматизация выводит эту непоследовательность на поверхность с высокой скоростью и в большом объёме.
Проблема взаимодействия с клиентом, которая всё усугубляет
Случай TrueFocus несёт в себе второй урок. Автоматизация работала в рабочем режиме некоторое время, прежде чем проблема качества данных проявилась. Исходная команда, использовавшая систему, не сообщала об отсутствующих документах — не замечала ли она этого, не связывала ли пробелы с автоматизацией или не эскалировала проблему — результат был одинаков: проблема накапливалась незаметно.
Когда пришла новая команда и начала задавать вопросы, пробелы стали очевидны. К тому моменту TrueFocus работала на основе допущений о производительности системы, которые клиент так и не исправил.
Loganathan прямо назвал первопричину: у клиента отсутствовало единое контактное лицо с глубоким пониманием работы собственной платформы, и не было регулярной обратной связи между людьми, использующими результаты, и командой, управляющей системой. Команда пользовалась решением, но никогда не сообщала об отсутствии чего-либо. Без такой итеративной коммуникации проблемы накапливались до тех пор, пока их устранение не стало дорогостоящим.
Автоматизация требует постоянного контроля. Боты необходимо отслеживать, исключения — проверять, а люди, полагающиеся на результаты, должны поддерживать регулярный контакт с теми, кто управляет системой.
Как выглядит честный процесс исследования
Для компаний, оценивающих поставщиков решений по автоматизации, готовность выявлять проблемы до начала проекта, а не после сдачи, — одно из наиболее ценных качеств поставщика.
TrueFocus придерживается позиции, что выявить проблему качества данных на первой неделе лучше, чем поставить автоматизацию, работающую с перебоями и подрывающую доверие к технологии. Это означает теневые сессии, где команда, выполняющая реальную работу, проходит через процесс в прямом режиме. Это означает вопросы не только о том, как рабочий процесс функционирует сегодня, но и о том, как он менялся со временем и отражают ли базовые данные эти изменения последовательно. И это означает готовность сообщить потенциальному клиенту, что его данные не готовы, — даже если это не то, что он хочет услышать.
В случае, который в итоге завершил сотрудничество TrueFocus с этим клиентом, сооснователь Jimmy Lewis принял решение напрямую: «Если мы не можем этого сделать, давайте скажем им сейчас. Я не хочу затягивать». Этот разговор состоялся позже, чем следовало, но принцип верен. Поставщик, готовый сообщить, что проект не готов, ценнее того, кто берётся за работу и сдаёт ненадёжный результат.
Jimmy Lewis — сооснователь TrueFocus Automation, специалиста в области RPA и управляемой ИИ автоматизации рабочих процессов для отраслей страхования титула, ипотеки и недвижимости. TrueFocus разработала более 840 автоматизированных ботов, обеспечивающих поддержку более 2 500 рабочих процессов, и вернула клиентам более 1,3 миллиона производственных часов.
Эта статья основана на информации, предоставленной упомянутым выше экспертным источником. Она предназначена исключительно для общих информационных целей и не является юридической, финансовой или консультацией по недвижимости. Читателям рекомендуется проводить собственное исследование и обращаться к квалифицированным специалистам перед принятием каких-либо решений в сфере недвижимости или финансов.
