Краткое резюме
Проверка готовности к внедрению Agentforce занимает несколько недель; неудачный пилотный проект обходится в месяцы и подрывает внутреннее доверие. Поэтому стоит заранее ответить на пять вопросов: существует ли определенный процесс с назначенным владельцем; надежны ли данные, на которые будет опираться агент; поддерживается ли база знаний; понятна ли модель разрешений; и есть ли тот, кто будет управлять агентом после запуска.
Проверка не является вопросом «да» или «нет». Она формирует оценку по каждой оси и карту пробелов, что позволяет принять более точное решение: начать, сократить объем или отложить и сначала устранить конкретный пробел.
Рамки принятия решения о применимости сценария использования (Use Case) представлены в статье Agentforce для предприятий.
Пять осей готовности
| Ось | Решающий вопрос | Признак слабости | Минимальный порог для пилота |
|---|---|---|---|
| Процесс | Определен ли процесс и есть ли у него именной владелец? | Каждая команда выполняет по-разному, документации нет | Один документированный процесс с владельцем и известным объемом |
| Данные | Надежны ли поля, которые будет считывать агент? | Пустые поля или заполненные свободным текстом | 90% полноты критически важных полей для процесса |
| Знания | Существует ли утвержденный источник ответов? | Старые или противоречивые статьи | 20 актуальных статей для типовых сценариев |
| Разрешения | Понятно ли, что каждый пользователь может видеть и делать? | Широкие и неконтролируемые разрешения | Сопоставление профилей и наборов разрешений (Permission Sets) для процесса |
| Эксплуатация | Кто мониторит, исправляет и утверждает изменения? | Нет владельца после запуска | Владелец эксплуатации и еженедельный график обзора |
Ось 1: Процесс
Наиболее распространенная ошибка не является технологической. Организации выбирают процесс без владельца, и тогда некому принимать решения по вопросам, возникающим в ходе разработки: что происходит в исключительных случаях, когда нужна эскалация, что считается правильным ответом. Без таких решений техническая команда придумывает правила, а бизнес проверяет по другим ожиданиям.
Практическая проверка: попросить четырех сотрудников, выполняющих процесс, описать его в письменном виде. Если получены четыре существенно различающиеся версии, процесс не готов к автоматизации с помощью агента – он готов к документированию и согласованию.
Также важен объем. Процесс, выполняющийся десять раз в месяц, не оправдает затрат на разработку и поддержку, даже если он проблематичен. Хороший кандидат – это процесс со значительным объемом, высокой повторяемостью и изменчивостью формулировок запросов – именно там, где жесткие правила нарушаются.
Ось 2: Данные
Не требуется идеальное качество данных во всей Salesforce Org. Требуется качество полей, которые агент будет считывать или обновлять в выбранном процессе. Проверка узкая и измеримая: берется список релевантных полей и измеряется полнота, согласованность значений и дубликаты в связанных записях.
Три теста, дающие быстрый ответ: процент заполненных критически важных полей, количество дублирующих записей в основном объекте и процент случаев, когда необходимая информация поступает из внешней системы, а не из Salesforce. Третий тест часто удивляет, выявляя зависимость от интеграции, которая не была бюджетирована.
Свободный текст – особый красный флаг. Когда существенная информация хранится в поле для примечаний, агенту придется ее выводить, и именно здесь возникают труднообнаружимые ошибки.
Рекомендуемый порядок устранения пробелов в данных подробно описан в статье Показатели качества данных в Salesforce.
Ось 3: Знания
Знания оцениваются не по количеству, а по охвату и актуальности. Берутся двадцать наиболее частых запросов и для каждого проверяется: есть ли утвержденная статья, когда она обновлялась и кто является ее владельцем. Охват половины сценариев актуальными статьями предпочтительнее полного охвата устаревшими статьями.
Легко упускаемый признак слабости: статьи, написанные только для внутреннего пользования, но одновременно используемые для ответов клиентам. Они могут содержать формулировки, цены или исключения, которые нельзя раскрывать внешне, и разделение должно быть сделано до подключения.
Ось 4: Разрешения
Агент действует от имени пользователя, поэтому существующая модель разрешений становится моделью безопасности ИИ. Если разрешения сегодня широкие и неконтролируемые, агент увеличит потенциальные риски, а не создаст их. Проверка анализирует три аспекта: кто имеет право читать данные в процессе, какие операции записи необходимы и кто утверждает конфиденциальную операцию.
Для каждой операции, которую будет выполнять агент, необходимо определить, является ли она обратимой. Необратимая операция – кредитование средств, закрытие дела, отправка сообщения клиенту – требует точки подтверждения человеком на начальном этапе, поэтому она влияет на планирование процесса, а не только на настройки.
Планирование точек утверждения по риску подробно изложено в статье Human-in-the-Loop в Agentforce.
Ось 5: Эксплуатация
Агент — это не проект с датой завершения. Это компонент, требующий мониторинга трассировок, обработки сбоев, обновления контента и контроля затрат. Организация, у которой нет того, кто будет это делать — хотя бы на частичную занятость, — увидит постепенное снижение качества в течение квартала.
Минимум: именной владелец эксплуатации, еженедельный график обзора неудачных взаимодействий, согласованный процесс изменения для обновления инструкций и контролируемый ежемесячный бюджет. Если ни один из этих четырех элементов отсутствует, пробел по этой оси больше, чем кажется на первый взгляд.
Преобразование оценки в решение
| Состояние | Интерпретация | Рекомендуемое действие |
|---|---|---|
| Все оси выше порогового значения | Полная готовность | Пилотный проект по одному процессу с критериями Go/No-Go |
| Слабость только в эксплуатации | Можно компенсировать поддержкой | Пилотный проект с внешней поддержкой и параллельным развитием внутренних компетенций |
| Слабость только в знаниях | Целенаправленный пробел в контенте | Четыре-шесть недель обучения знаниям, затем пилотный проект |
| Слабость в данных или разрешениях | Существенный риск | Не начинать с агента; устранить пробел как отдельный проект |
| Слабость в трех и более осях | Организация не готова | Выбрать более узкий подпроцесс и перепроверить |
Сценарий: Финансовая организация, обнаружившая, что выбран неверный процесс
Финансовая организация запросила агента для обработки запросов на изменение данных клиента. В ходе проверки готовности выяснилось, что процесс проходит через две внешние системы, каждое изменение требует регуляторного одобрения, а ежемесячный объем скромен. Оси разрешений и данных получили низкую оценку.
В ходе той же проверки обнаружился другой процесс, о котором никто не задумывался: ответы на запросы о статусе существующих заявок. Он опирался на одно надежное поле в Salesforce, не включал операции записи, а его объем был в восемь раз выше. Пилотный проект был переведен на этот процесс.
Практическим результатом проверки было не «готовы или не готовы», а замена кандидата. Это главное преимущество проверки готовности – она достаточно дешева, чтобы провести ее для трех кандидатов и выбрать того, у кого наименьшее количество зависимостей.
Чек-лист готовности
- ☐ Выбран один процесс-кандидат с назначенным владельцем
- ☐ Измерены ежемесячный объем и частота повторений
- ☐ Проверена полнота критически важных полей для процесса
- ☐ Проверены дубликаты в основном объекте
- ☐ Выявлены зависимости от внешних систем
- ☐ Составлено покрытие базы знаний для двадцати наиболее частых запросов
- ☐ Разделен внутренний контент от контента, разрешенного для клиента
- ☐ Составлены разрешения на чтение и запись для процесса
- ☐ Классифицированы обратимые и необратимые операции
- ☐ Определен владелец эксплуатации и график обзора после запуска
В случае необходимости внешней экспертизы для проведения проверки и разработки Roadmap, услуга Agentforce и ИИ является практическим путем для дальнейших действий.