Практически в каждом предприятии, с которым я общаюсь, существует одна и та же проблема: разрыв между пониманием того, что процесс нуждается в изменениях, и их реальным внедрением. Страховая компания обновляет медицинский полис или регулятор пересматривает порог проверки, и сотрудники, отвечающие за этот процесс, уже через день знают, что именно нужно изменить. Затем они оформляют заявку. Изменение внедряется через три недели или три квартала, либо, если ваша команда администраторов приложений не справляется, задача попадает в дорожную карту вендора и не реализуется вовсе. Для процесса, который меняется редко, это терпимое неудобство. Для жестко регулируемых процессов с большим количеством исключений, для которых моя команда создает решения, это тяжелое бремя для людей, которые лучше всего понимают суть работы, но имеют меньше всего возможностей изменить порядок ее выполнения.
Это разочарование звучало практически на каждой встрече с клиентами на мероприятии UiPath FUSION в прошлом месяце. Вместо того чтобы расспрашивать об агентах или моделях, клиенты хотели знать, кто решает, какая версия политики применяется, где обрабатываются исключения и как система может учиться на этих исключениях. Это не вопросы об искусственном интеллекте. Это практические вопросы о том, сможет ли программное обеспечение успевать за непрерывно развивающимся бизнесом.
Чем решение отличается от обычного программного обеспечения?
Возьмем промышленное предприятие. Существуют определенные процессы, которые уникальны только для него: несколько команд, дюжина систем, исключения, разветвляющиеся в зависимости от спорного покрытия, и экспертные оценки, которые никто за пределами компании не поймет. Ни один вендор не мог упаковать это заранее, поэтому карту такого процесса приходится создавать совместно с клиентом. Их процесс «от закупки до оплаты» устроен иначе. Производственные компании обычно следуют одним и тем же шагам для закупок и расчетов, даже если у каждой компании есть свои политики и правила. Поскольку процесс стандартизирован, большую часть его карты можно построить заранее. Одной и той же компании для одного процесса может потребоваться пользовательская карта, а для другого — готовое решение.
Второй случай — это решение от UiPath, и оно не является шаблоном или стартовым набором. Вся карта работы (Map of Work) поставляется в готовом виде и состоит из трех уровней:
- Структурированные знания: онтология, правила и политики, таксономия исключений для данного процесса
Структурированные знания: онтология, правила и политики, таксономия исключений для данного процесса
- Операционные знания: прецеденты, примеры из практики и экспертные оценки ваших опытных сотрудников — то есть именно то, что обычно уходит вместе с ними при увольнении
Операционные знания: прецеденты, примеры из практики и экспертные оценки ваших опытных сотрудников — то есть именно то, что обычно уходит вместе с ними при увольнении
- Журнал решений (Decision Ledger), представленный на FUSION, который будет фиксировать логику каждого решения по мере выполнения работы
Журнал решений (Decision Ledger), представленный на FUSION, который будет фиксировать логику каждого решения по мере выполнения работы
Поверх этой карты поставляется всё, что управляет работой. Всё это уже создано, поддерживается и улучшается нами, без фазы разработки и с ценообразованием, привязанным к результату, а не к затраченным усилиям.
Почему SaaS не успевает за изменениями
Статичное приложение настраивается один раз, а затем просто ждет ваших действий. Решение, построенное на основе Карты Работы, работает иначе, и для этого требуется слаженное взаимодействие четырех компонентов. Бизнес-онтология предоставляет каждому агенту, роботу и человеку единое описание ваших бизнес-объектов и их взаимосвязей. UiPath Policy Engine преобразует письменные правила в структурированные версии: модель считывает вашу политику, а Policy Engine принимает решение. Maestro организует работу от начала до конца и сохраняет состояние кейса в течение дней или недель. А журнал решений фиксирует логику каждого решения и каждой корректировки по мере выполнения работы.
Policy Engine — это то, что заставляет всю систему работать. Он показывает, какие критерии были выполнены, не выполнены или требуют дополнительной документации. Один и тот же кейс при одной и той же версии политики всегда дает одинаковый результат, причем обоснование можно предоставить в день принятия решения, а не восстанавливать его задним числом. Затраты остаются предсказуемыми, поскольку вам не нужно платить модели за анализ каждой транзакции.
Вот для чего предназначен этот цикл обратной связи. Журнал по своей природе сохраняет всё: каждое решение, каждое переопределение, каждый отзыв, высказанный мимоходом. Агенты постоянно считывают эту историю и предлагают улучшения, каждое из которых оценивается на тестовых данных до того, как его увидит человек. Бизнес-команда получает рекомендацию с приложенными доказательствами и либо принимает ее, либо отклоняет. Никаких заявок не создается. Никому не нужно ждать администратора.
Улучшения бывают самыми разными, и это кажется мне самым интересным. Некоторые из них переводят неформальные знания — суждения опытного сотрудника в сложной нестандартной ситуации — в структурированное правило, доступное каждому. Другие уточняют инструкции для агента. А третьи меняют саму структуру процесса, обходя узкое место, которое стало заметно только после запуска работы. И всё это происходит во время работы процесса, а не в рамках окна релиза. В этом и заключается реальная разница между динамической системой и статичной. Не в том, что ее можно настроить, ведь настроить можно любое SaaS-приложение, а в том, что она оценивает сама себя в production и предлагает людям, отвечающим за процесс, готовое решение, а не очередь, в которой нужно стоять.
Здесь может возникнуть вполне справедливое возражение. Если заявки исчезнут, что придет им на смену? Этот процесс был медленным, но он также служил средством контроля, а в регулируемой сфере нельзя просто убрать контроль и надеяться на лучшее. Поэтому контроль переносится внутрь системы. Каждое изменение проходит через ответственного владельца, для одобрения вопросов, затрагивающих политику, может потребоваться второй рецензент, а уровни разрешений дифференцируются в зависимости от критичности правила, поэтому допуски по ценообразованию и регулятивные пороги регулируются по-разному. Каждая версия сохраняется, поэтому, когда аудитор попросит вас объяснить решение восьмимесячной давности, вы сможете это сделать.
Это также ответ на возражение, которое никто не озвучивает до завершения сделки: что готовое решение не может по-настоящему принадлежать вам. Иерархия согласований в любой компании имеет одинаковую структуру — уровни, эскалация, делегирование, — и единственное, что всегда принадлежало вам, — это цифры в ней и стоящие за ними решения. Поэтому вы задаете собственные уровни, загружаете документ с политикой, на выходе получаете правила и сами решаете, в какой степени машина принимает решения — границу, которую можно сдвигать по мере роста уверенности. Полдень на настройку. А не квартал на кодирование. Всё стандартное уже создано. Всё, что принадлежит вам, остается вашим.
Создать решение теперь легко, а вот доверять ему — нет
В апреле я писал о том, когда стоит создавать агентское решение, а когда — покупать готовое. С тех пор один из аргументов изменился: в прошлом месяце решение UiPath для агентов-разработчиков (UiPath for Coding Agents) стало общедоступным. Теперь ваша команда может быстро развернуть агента, который читает претензию и составляет проект апелляции. Создание агента больше не является сложной задачей. Гораздо более сложный вопрос заключается в том, как запустить его в production и сохранять к нему доверие по мере изменения рабочих процессов.
Теперь основное внимание должно быть сосредоточено на доверии. Доверие к производственной системе зависит от семи факторов: агентов, автоматизации, интеграций, приложений, в которых работают люди, управления, оценки и обучения.
Ваша команда может создать первые пять элементов, но на это требуется время. В регулируемых сферах деятельности нельзя останавливаться на 80%, а затраты на достижение более высоких показателей растут экспоненциально. Тем не менее, при достаточных времени и усилиях все это можно построить, а инструменты продолжают совершенствоваться.
Однако последние два пункта отличаются тем, что они являются результатом прецедента, а не затраченных усилий. Оценка и обучение эффективны ровно настолько, насколько хороши данные, стоящие за ними. В собственной системе ваша выборка начинается с нуля, в то время как наша поступает уже настроенной на работу в различных развертываниях и улучшается с каждым запуском. Это маховик, который вращается уже некоторое время и получает новый импульс при каждом нашем развертывании. Другая проблема заключается в том, что доверие со временем снижается: каждое изменение системы, каждая пересмотр политик и каждая новая модель частично сбрасывают его. Так что вопрос заключается не в том, сможет ли ваша команда построить это. Вопрос в том, кто будет поддерживать доверие к системе через восемь месяцев.
Подтверждение в рабочей среде
Решение должно доказать свою эффективность в реальной работе. Эти развертывания показывают результаты, которые клиенты UiPath получают в рабочей среде:
- Здравоохранение: поставщик услуг по управлению циклом доходов в США сократил расходы на обработку отклоненных претензий на 76%
Здравоохранение: поставщик услуг по управлению циклом доходов в США сократил расходы на обработку отклоненных претензий на 76%
- Финансовые услуги: латиноамериканский розничный банк сократил время разрешения споров с 97 часов до менее чем пяти
Финансовые услуги: латиноамериканский розничный банк сократил время разрешения споров с 97 часов до менее чем пяти
- Производство: мировой производитель бытовой техники увеличил долю автоматизации обработки счетов с 10% до диапазона от 80% до 90%
Производство: мировой производитель бытовой техники увеличил долю автоматизацию обработки счетов с 10% до диапазона от 80% до 90%
- Финансы и бухучет: глобальный производитель потребительских товаров запустил своего агента по цепочке «закупка-оплата» с показателем успешности 91%
Финансы и бухучет: глобальный производитель потребительских товаров запустил своего агента по цепочке «закупка-оплата» с показателем успешности 91%
Что будет дальше
Полученные результаты указывают на возможность перенести больший объем этой работы в готовые решения.
Когда один и тот же процесс повторяется в разных компаниях с одними и теми же шагами и тем же с трудом завоеванным опытом, он становится кандидатом на создание комплексного решения. На мероприятии FUSION один из банков предложил стать первым клиентом для решения, которое мы еще не построили: создайте его вместе с нами, а затем масштабируйте. Каждая карта — это готовое к созданию решение, а лежащий в основе каждой из них реестр подскажет нам, какое из них создавать следующим.
Это также меняет расстановку ролей. Директор по претензиям, медсестра по управлению медицинским обслуживанием и менеджер по кредиторской задолженности перестают подавать тикеты на чужое программное обеспечение и начинают сами устанавливать правила, по которым работают их процессы. Об этом снова и снова говорили на FUSION, и так будет продолжаться везде, где статичные SaaS-решения определяют бизнес-процессы.
В следующем квартале ваш бизнес снова изменится. Стоит задаться вопросом, узнает ли об этом ваше программное обеспечение из тикета.
Углубите свои знания
- Прочитайте мой предыдущий блог-пост: Создавать или не создавать? Решения на базе агентов открывают иной путь к трансформации.
Прочитайте мой предыдущий блог-пост: Создавать или не создавать? Решения на базе агентов открывают иной путь к трансформации.
- Ознакомьтесь с доступными вам решениями UiPath.
Ознакомьтесь с доступными вам решениями UiPath.
- Не знакомы с картой работы (Map of Work)? Начните отсюда.
Не знакомы с картой работы (Map of Work)? Начните отсюда.
- Посмотрите, как это работает для вашего собственного процесса. Запросите демоверсию, и мы покажем вам, какая часть вашей карты уже нарисована.
Посмотрите, как это работает для вашего собственного процесса. Запросите демоверсию, и мы покажем вам, какая часть вашей карты уже нарисована.
.webp)
