Latest / M365.FM – подкаст о Microsoft 365, Copilot и ИИ на русском / Система согласований с ИИ в Microsoft Copilot Studio: многоэтапные Agent Flows и проверка чеков (ИИ-дубляж)

Transcript

Система согласований с ИИ в Microsoft Copilot Studio: многоэтапные Agent Flows и проверка чеков (ИИ-дубляж) · M365.FM – подкаст о Microsoft 365, Copilot и ИИ на русском

• 0:00
  Вы тратите полдня на ожидание согласований. Кто-то в отпуске, кто-то не увидел письмо,
• 0:04
  и к тому моменту, когда решение наконец принято, контекст, оправдывавший запрос, уже утрачен.
• 0:09
  Корпоративное чистилище, где прогресс замирает из-за людей, которые уверяют, что они заняты.
• 0:12
  А теперь представьте систему, которая просто не ждет. Рабочий процесс, который движется вперед,
• 0:17
  как только выполнены условия. Встречайте агент Флауса в Microsoft Copilot Studio,
• 0:20
  убийцу бюрократии под маской автоматизации. Здесь и становится вашим первым согласующим лицом.
• 0:25
  Он считывает данные, сверяет их с политикой и выдает обоснованное решение об одобрении или
• 0:29
  отказе, прежде чем человек успеет моргнуть. Только пограничные случаи попадают в почтовый
• 0:33
  ящик менеджера, что обеспечивает скорость без ущерба для контроля. И в отличие от устаревших
• 0:37
  процессов согласования, которые рушатся под грузом сложных условий, эти системы на базе и
• 0:41
  масштабируются, самостоятельно разветвляясь, проверяя и контролируя себя.
• 0:45
  В этом руководстве я покажу, как создать многоэтапную систему условного согласования,
• 0:49
  которая принимает решение быстрее, чем ваши коллеги находят кнопку «Ответить всем».
• 0:52
  Вы узнаете, как настроить этап и использовательской логикой согласования,
• 0:56
  добавить целевые проверки людьми, разработать динамические условия для интеллектуальной
• 1:00
  маршрутизации и интегрировать проверку документов для соблюдения требований.
• 1:04
  К концу вы получите автоматизированный процесс, который знает, когда нужно мыслить как машина,
• 1:08
  а когда довериться человеческому суждению. Хватит стоять в очереди. Позвольте логике управлять
• 1:12
  процессом. Проблема традиционных согласований.
• 1:15
  Традиционные цепочки согласований — это трагический ремикс одной и той же неэффективности.
• 1:19
  Кто-то подает форму, письма летят, таблицы теряют синхронизацию,
• 1:22
  и в круговороте пересылок никто не помнит, какая версия была финальной. Каждый участник
• 1:26
  добавляет задержку, а не ценность. Процесс не управляет работой, он создает задержки.
• 1:31
  Типичные потоки согласования Power Automate пытаются решить эту проблему,
• 1:35
  но они буксуют, как только появляются нюансы. Одиночный путь согласования работает нормально,
• 1:39
  если вам нужно только «да» или «нет». В тот момент, когда вы добавляете уровни управления,
• 1:43
  лимиты затрат или специальные правила, дизайн начинает трещать по швам. Вы заканчиваете тем,
• 1:47
  что вкладываете условия друг в друга, как матрешки, неигантно, хрупко и невозможно
• 1:50
  отладить полгода спустя. Один сломанный коннектор, и вся система тихо выходит из строя.
• 1:55
  Люди становятся бутылочным горлышком или, если быть предельно точным, узлами задержки.
• 1:59
  Каждое сообщение, которое они получают, превращается в еще один асинхронный цикл ожидания.
• 2:02
  Использовать почту для согласований – это как использовать почтовых голубей в мире
• 2:05
  автоволоконных сетей. Технически это работает, но так быть не должно.
• 2:08
  Встречайте Microsoft Copilot Studio. Это не просто обновленная версия Power Automate. Она внедряет
• 2:14
  агентные потоки системы согласования на базе и полностью интегрированные
• 2:18
  в источнике данных, роли и логические структуры вашей организации. Она объединяет
• 2:22
  строгое соблюдение политик с адаптивным принятием решений. Гениальность заключается в том,
• 2:27
  как система разделяет этапы. Автоматизация там, где нужна скорость, и участие человека там,
• 2:32
  где важна проверка. Представьте это как переосмысленную иерархию.
• 2:35
  Этап и оценивает фиксированные правила, лимиты сумм, категории и диапазоны дат с хирургической
• 2:40
  точностью. Затем, если решение вызывает сомнения, процесс переходит к человеку,
• 2:44
  избавляя от необходимости ставить в очередь каждое мелкое дело. Это само по себе
• 2:48
  исключает экспоненциальные задержки. Вместо того, чтобы 10 человек проверяли все по порядку,
• 2:52
  им мгновенно обрабатывает 80%, направляя на ручную проверку только исключение.
• 2:56
  И да, Капайлот Студия отшлеживает все через базу Dataverse, создавая проверяемые логи без
• 3:01
  необходимости копаться в почтовых архивах. Предыдущие рабочие процессы создавались для людей.
• 3:06
  Потоки агентов строятся вокруг них, вовлекая людей только тогда, когда требуется интерпретация,
• 3:10
  а не повторение. Как только вы увидите, как работает эта архитектура, традиционные согласования
• 3:14
  покажутся примитивными, как ведение бухгалтерии при свечах. Ставки просты, соответствие требованиям,
• 3:18
  последовательность и масштабируемость. Современные операции утонут без автоматизированной
• 3:23
  проверки, а логика и теперь стандарт надежности. Переходя от статических процессов к проверяемым
• 3:28
  агентским потоком, вы перестаете реагировать на согласование и начинаете управлять ими как живыми
• 3:33
  системами. Разница не только в скорости, но и в структурном порядке. Создание этапа и обучение первого
• 3:39
  проверяющего. А теперь самое интересное – обучение вашего первого цифрового бюрократа.
• 3:44
  Этап И – это логический превратник вашего процесса согласования. Его задача – не мыслить как
• 3:49
  человек, а выполнять структурированный анализ со сверхчеловеческой стабильностью. Он читает
• 3:53
  инструкции, сверяет их с входными данными и выносит один из двух вердиктов – одобрено или отклонено.
• 3:57
  Никакой политики, никаких перерывов на кофе. Вы начинаете с определения нового потока агента.
• 4:02
  При создании этап И занимает центральное место, как чистый экзаменационный лист,
• 4:05
  ожидающий ключей к вопросам. Триггером обычно служит датаверс – добавление или
• 4:09
  изменение записи в таблице заявок или расходов. Как только заявка создана, этот этап активируется,
• 4:14
  оценивает данные и принимает решения. Внутри этапа самое важное поле – это инструкция
• 4:18
  промп, мозг, всей операции. Здесь вы описываете логику согласования простым, но строгим языком.
• 4:24
  Пишите так, будто инструктируете юриста, который никогда не импровизирует. Например,
• 4:28
  одобрить заявку, если сумма меньше 500, описание связано со здоровьем, а дата покупки не превышает 30 дней
• 4:34
  с момента подачи. Отклонить, если не соблюдено хотя бы одно правило. Вот и все,
• 4:38
  бинарная ясность. Затем определите динамические входные данные. Считайте их переменными,
• 4:43
  подающими реальные данные в вашу логику. Скорее всего, вы включите сумму, описание и дату
• 4:48
  покупки. Каждый элемент добавляется как текстовый, числовой ввод или контент, который и будет
• 4:53
  использовать при принятии решения. Капайлот Студия классифицирует эти вводные данные по типу
• 4:57
  «текст», «число» или «графический документ». Выбирайте правильно, так как смешивание типов,
• 5:02
  например, числа в текстовом формате путает и людей, и машины. Под каждым полем ввода укажите примеры данных
• 5:07
  для тестирования. Это послужит каркасом, пока вы настраиваете логику. Например,
• 5:12
  введите пробную заявку «Коврик для йоги», «Сумма 300», «Дата покупки 22 августа».
• 5:17
  При нажатии кнопки «Тест» Капайлот Студия запускает модель рассуждений на базе GPT и выдает
• 5:23
  решение с пояснением. Если результат соответствует ожиданиям, отлично. Если нет, вашим инструкциям не
• 5:29
  хватает детерминизма. И именно здесь ошибается большинство новичков. Общие или двусмысленные
• 5:34
  формулировки, вроде «Разумные расходы» или «Недавняя покупка – это яд для ИИ»,
• 5:38
  система не может уловить корпоративное настроение, ей нужны математические определения.
• 5:41
  Поэтому безжалостно уточняйте свои инструкции, пока результаты тестов не станут стабильными.
• 5:45
  Каждый раз, когда вы переформулируете задачу, вы настраиваете механизм суждений на
• 5:48
  воспроизводимость. Вам нужно добиться того, чтобы идентичные входные данные всегда давали
• 5:52
  идентичный результат. Машинная логика, а не офисные сплетни. Как только ваш промп начнет выдавать
• 5:56
  надежные решения в разных тестах, вы фактически обучили своего и одобрителя. Теперь внедрите реальные
• 6:01
  динамические данные, используя токены из датаверс, детали суммы заявки, дату покупки или подачи.
• 6:07
  Они заменят тестовые значения во время реальной работы. С этого момента и оценивает каждую заявку
• 6:12
  в контексте, вынося вердикт сразу после появления новых данных. Прежде чем объявлять о победе,
• 6:17
  проведите итеративные тесты. Измените сумму на 600, отклонит ли он ее. Измените дату на 3 месяца
• 6:21
  назад, пометит ли он ее как недействительную. Добавьте нелепую заявку, например, покупку iPad,
• 6:26
  обнаружит ли он несоответствие. Каждый прогон должен демонстрировать последовательную
• 6:29
  причинно-следственную связь. Если ответы колеблются, проблема в четкости вашего промпта,
• 6:33
  а не в модели И. Когда появятся устойчивые закономерности, установите соглашение об именовании
• 6:37
  переменных контента. Используйте префиксы, такие как STR для суммы заявки или NUM для даты
• 6:42
  покупки. Эта небольшая дисциплина предотвратит хаос при дальнейшем расширении до многоветвистой
• 6:47
  логики. На этом этапе ваш автоматизированный одобритель может принимать независимые решения
• 6:51
  согласно политике без контроля. Но автоматизация – это не диктатура, а делегирование. Машина отвечает
• 6:57
  за скорость и точность, а не за суждение. Для пограничных сценариев потребуется эскалация и
• 7:01
  участие человека, чтобы проверить то, что и отклонил или счел сомнительным. Здесь вступает в
• 7:06
  силу следующий этап, и так полномочия распределяются между кремнием и сотрудниками.
• 7:10
  Добавление человеческого контроля, многоэтапной и условной логики. Когда ваш И начнет уверенно
• 7:14
  оценивать заявки, вы сможете добавить то, что в бюрократии иронично называют человеческим
• 7:19
  подходом. В CoPilot Studio это означает ручной этап, контрольную точку, где реальный человек может
• 7:23
  проявить осмотрительность. Думайте об этом как о своем предохранительном клапане. Все
• 7:27
  предсказуемые процессы проходят автоматически. Все, что требует нюансов, попадает на стол
• 7:32
  менеджеру. Начните в конструкторе утверждений, добавив ручной этап сразу после этапа И. Это
• 7:36
  создает второй барьер в потоке работы вашего агента. Передача управления происходит на определенных
• 7:40
  условиях. Только если вердикт И одобрено, мы переходим к этапу с участием человека. Если И говорит
• 7:45
  «отклонено», процесс на этом завершается. Зачем тратить время менеджеров на подтверждение того,
• 7:49
  что политика уже исключила? Эффективность – это избирательное внимание,
• 7:52
  замаскированное под автоматизацию. Давайте разберем пример сценария. Допустим,
• 7:56
  сотрудник подает заявку на возмещение расходов за абонемент в спортзал. И одобряет ее,
• 7:59
  так как все критерии соответствуют политике. Теперь это решение запускает ручной этап уровня
• 8:04
  менеджера под названием «Одобрение менеджером». В настройках вы задаете этому этапу заголовок,
• 8:09
  например, запрос на утверждение от автора заявки. Эти переменные динамически извлекают данные из
• 8:14
  датаверс. В поле «Кому назначено» вы определяете получателя задачи, обычно это руководитель
• 8:19
  заявителя. Для автоматизации этой маршрутизации Copilot Studio позволяет интегрировать
• 8:23
  коннектор Office 365 users. Сначала получите запись пользователя, создавшего заявку, с помощью
• 8:28
  действия «Получить строку по ID» в таблице пользователей датаверс. Это извлекает информацию о
• 8:33
  заявителе. Затем действие «Получить менеджера» находит руководителя этого пользователя через его
• 8:37
  основной email. Передайте этот результат в ваш ручной этап в качестве переменной,
• 8:40
  например, str-менеджер-меджер-меджер. Результат – никакой жесткой кодировки и устаревших
• 8:44
  иерархий. Менеджеры меняются, иерархия обновляется сама. Теперь переходим к условным
• 8:49
  ветвлениям – истинной причине существования многоэтапных утверждений. Вы можете внедрить логику
• 8:53
  непосредственно в поток агента. Если сумма заявки больше или равна 150, добавьте дополнительный
• 8:58
  этап для административного утверждения. В противном случае завершите процесс. Это превращает
• 9:02
  простую двухшаговую рутину в многоуровневое дерево решений, адаптирующееся к контексту.
• 9:06
  Заявки с низкой стоимостью проверяет один человек. Более дорогие или рискованные заявки передаются
• 9:11
  на дополнительную проверку. В дизайнере вставьте действие условия перед завершением потока.
• 9:15
  Сошлитесь на свою числовую переменную, например, num, нижнее подчеркивание,
• 9:17
  клэм, нижнее подчеркивание, амаунт. Выберите оператор, больше или равно, и установите пороговое
• 9:22
  значение, например, 150. В ветке, если истина, добавьте еще один ручной этап под названием
• 9:26
  административное утверждение. Назначьте его на фиксированного утверждающего, например,
• 9:29
  администратора по соответствию требованиям. В ветке, если ложь, завершите процесс со статусом
• 9:32
  одобрено. Эффект «Рабочий процесс» ведет себя как рациональная организация,
• 9:36
  а не как универсальная бутылочная горлышко. Здесь уместна доля практического юмора. Да,
• 9:40
  делегирование все еще требует доверия, а не слепой надежды. Не назначайте широкие роли безопасности,
• 9:45
  которые позволяют одобрять все подряд. Ограничьте права доступа для соответствующих пользователей
• 9:48
  или групп с помощью управления доступом на основе ролей в датаверс. В противном случае вы
• 9:51
  просто автоматизируете хаос. Тестирование структуры показывает, насколько гармонично все элементы
• 9:55
  сочетаются друг с другом. Если заявка на сумму менее 150 долларов проходит проверку и…
• 9:59
  Процесс завершается после одобрения менеджером. Если сумма превышает 150 долларов,
• 10:03
  система корректно ставит ее в очередь на проверку администраторам перед финализацией.
• 10:06
  Каждый путь оставляет аудиторский след, журнал рассуждений и… Одобрение с отметками
• 10:09
  времени и зафиксированные результаты, хранящиеся в датаверс. Никто не сможет потом заявить,
• 10:13
  «Я этого не видел». База данных говорит об обратном. В процессе доработки придерживайтесь
• 10:17
  строгих правил именования. Четко обозначайте этапы участия человека, например, одобрено менеджером,
• 10:21
  одобрено администратором, чтобы визуально отслеживать ветки процесса. Блок-схема должна читаться
• 10:25
  как логическая цепочка, а не как загадочное искусство. Достигнув желаемого, опубликуйте и
• 10:29
  протестируйте решение на реальных сценариях. Наблюдайте за развитием цепочки событий и проводят
• 10:33
  оценку мгновенно. Менеджер получает целевую задачу на одобрение. Администратор подключается
• 10:37
  только при выполнении определенных условий. Результат выглядит не как автоматизация всего подряд,
• 10:42
  а как прозрачная иерархия, которая работает сама по себе. Эта многоуровневая оркестрация также
• 10:46
  открывает новые горизонты, проверку документов. Ведь иногда поля формы могут содержать ошибку,
• 10:51
  а чек – нет. Следующий шаг – заставить и изучать физические доказательства
• 10:55
  еще до того, как они попадут в ваш почтовый ящик. Здесь на помощь приходит проверка чеков,
• 10:59
  превращающая бурократию в проверяемую науку, динамические входные данные и проверка документов.
• 11:03
  Давайте поговорим о чеках, этих крошечных помятых бумажках, которые загадочным образом
• 11:07
  становятся важнейшими уликами, как только кто-то хочет получить возмещение.
• 11:10
  В ручном процессе одобрения люди проверяют их на глаз. Да, это похоже на коврик для йоги,
• 11:15
  а не на яхту. В автоматизированном процессе мы поручаем и выполнить ту же проверку,
• 11:19
  не опасаясь усталости от принятия решений. В агентных потоках Капайлот Студия проверка документов
• 11:23
  реализуется с помощью динамических входных данных, в частности, возможности передавать
• 11:27
  изображение или файл в логику вашего одобрения. Это добавляет вашему и верификатору третье чувство
• 11:32
  зрения. Вместо того, чтобы полагаться только на текстовые поля, модель считывает документ и сравнивает
• 11:36
  написанное в нем с тем, что было загружено. Вот структура процесса. На этапе работы и вы добавляете
• 11:41
  новый тип входных данных, изображение или документ. Назовите его понятно, например, файл чека.
• 11:46
  Загрузите образец чека для тестирования. Это не запускается в рабочую среду, а лишь обучает логическую схему.
• 11:51
  Теперь скорректируйте промп с инструкциями, включив в него перекрестную проверку документа.
• 11:55
  Вы расширяете свою предыдущую логику. Одобряйте заявку, если выполняются все следующие условия.
• 11:59
  Сумма до 500. Детали заявки связаны с физическим или ментальным здоровьем. Дата покупки в пределах
• 12:03
  30 дней. А документ чека соответствует заявленному товару, сумме и дате.
• 12:06
  Это четвертое условие превращает ваш и верификатор из контролера-политик в эксперта-криминалиста.
• 12:11
  Во время выполнения теста модель извлекает читаемый текст из документа и проверяет его соответствие
• 12:16
  вашим структурированным данным. Если в чеке указан коврик для фитнеса за 300 долларов от 22 августа,
• 12:21
  а в вашей заявке что-то другое, решение меняется на «Отклонено».
• 12:24
  Теперь перейдем к реализации. До начала процесса утверждения вам нужно будет получить этот документ.
• 12:28
  Используйте действие «Загрузить файл или изображение из датаверс».
• 12:31
  Укажите ту же таблицу, в которой находится запись заявки, скорее всего, заявки.
• 12:35
  В поле файла выберите поле вложения, которое часто называется, например, «Чек».
• 12:39
  Затем укажите идентификатор строки «Динамически из триггера». Это уникальный идентификатор заявки.
• 12:44
  Это действие возвращает метадонные и содержимое файла, но здесь кроется скрытая ловушка.
• 12:49
  Выходные данные содержимого требуют небольшой доработки, чтобы и мог интерпретировать их правильно.
• 12:53
  При сопоставлении содержимого файла с входным файлом чека откройте редактор выражений и добавьте
• 12:58
  «Контент» с ссылки на «Боди». Эта последняя настройка передает сами байты файла, а не обертку с метадонными.
• 13:04
  Пропустите это, и ваш и будет с энтузиазмом одобрять пустые чеки.
• 13:07
  Давайте обсудим синхронизацию Ахиллесову пяту рабочих процессов с документами.
• 13:11
  Большинство таблиц Датаверс не хранят вложения до тех пор, пока запись не будет сохранена впервые,
• 13:16
  а значит, если ваш поток запускается при создании записи, он может сработать до того, как файл появится.
• 13:20
  Симптом. Поток завершается с ошибкой или содержимое чека равно налым.
• 13:24
  Решение элегантно. Измените условия триггера на при изменении элемента,
• 13:28
  но ограничьте его срабатывание только моментом изменения столбца с чеком.
• 13:31
  Таким образом, как только кто-то загружает или заменяет файл, запускается проверка.
• 13:35
  Чтобы настроить это, откройте параметры триггера, выберите «Измененные столбцы»
• 13:39
  и вставьте логическое имя вашего столбца чека,
• 13:42
  которое можно найти в сведениях о столбце Датаверс в разделе «Дополнительных инструментов».
• 13:45
  После настройки опубликуйте изменения.
• 13:47
  Теперь ваша автоматизация ведет себя корректно.
• 13:50
  Она ждет, пока появится что-то, что действительно нужно проверить.
• 13:53
  Когда заявка обновляется новым чеком, поток перезапускается.
• 13:56
  Он скачивает файл, пропускает его через этап и перепроверяет все данные.
• 14:00
  Если обнаружены несоответствия, несовпадения суммы, устаревшая дата,
• 14:04
  нечеткие описания и отклоняет заявку с пояснением.
• 14:08
  Журнал обоснований может гласить, заявленная сумма 305 долларов
• 14:10
  отличается от итоговой суммы в документе 300 долларов.
• 14:13
  Это соблюдение правил без жалоб.
• 14:15
  Практический результат.
• 14:16
  Каждая заявка становится самопроверяемой.
• 14:18
  Сотрудники больше не могут протащить сомнительные чеки или расплывчатые описания.
• 14:22
  И выносят суждения.
• 14:23
  Датаверс предоставляет доказательства, и никто из них не уходит на перерыв.
• 14:27
  Так что нет, проверка документов – это не излишество.
• 14:30
  Это своего рода иммунная память для ваших рабочих процессов.
• 14:32
  Отклонения выявляются на молекулярном уровне, в символах, напечатанных на реальных чеках,
• 14:37
  а человек-проверяющий переходит от ручной проверки к работе с исключениями.
• 14:40
  Поздравляю, вы только что автоматизировали саму честность.
• 14:43
  Обеспечение надежности, тестирование, версионирование и публикация.
• 14:47
  Любая автоматизация кажется идеальной, пока ее не запустят.
• 14:50
  Вот почему надежность – это не этап, а дисциплина.
• 14:53
  Капайлот Студия делает эту дисциплину удивительно простой благодаря контролю версий,
• 14:57
  тестированию и публикации, встроенным прямо в потоке агента.
• 14:59
  Начните с атеративного тестирования.
• 15:01
  Каждый процесс согласования – это миниатюрная экосистема.
• 15:04
  Даже одно неверное имя переменной может вызвать хаос.
• 15:07
  Поэтому относитесь к тестированию как к научному процессу.
• 15:10
  Изолируйте изменения, вводите данные, наблюдайте результат.
• 15:13
  В редакторе потоков Капайлот Студия позволяет имитировать пробные данные
• 15:16
  без развертывания производственных триггеров.
• 15:18
  Проверяйте различные сценарии, слишком большую сумму, устаревшую дату, неверные названия
• 15:22
  и убедитесь, что каждый выдает правильный вердикт.
• 15:25
  Затем переходите к соглашениям об именовании.
• 15:27
  Скучно? Безусловно.
• 15:28
  Важно? Жизненно необходимо.
• 15:30
  Систематически добавляйте префиксы ко всем переменным.
• 15:32
  str для строк, num для чисел, doc для файлов.
• 15:35
  Точно так же давайте четкие названия действиям.
• 15:37
  Загрузить файл чека, проверить одобрение менеджера, обновить статус заявки.
• 15:41
  Потому что через три месяца, когда кто-то спросит, почему действие номер 7 сломалось,
• 15:44
  вы оцените, что подсказки лучше, чем археологические раскопки.
• 15:46
  Как только индивидуальные тесты пройдены, переходите к проверке граничных сценариев.
• 15:50
  Представьте себя некомпетентным пользователем.
• 15:52
  Не загрузите чек, измените дату на следующий год, введите 500 вместо 500.
• 15:57
  Убедитесь, что и объясняет ошибку и отклоняет запрос, не зависая.
• 16:00
  Это не гипотетические провалы, это репетиция реальности.
• 16:03
  Чем больше ошибок вы устраните заранее, тем меньше сообщений в Teams,
• 16:06
  в 2 часа ночи вы получите позже о том, что поток снова остановился.
• 16:10
  Публикация обеспечивает управление.
• 16:11
  Каждый раз, когда вы сохраняете важные изменения, Капайлот Студия незаметно создает новую версию.
• 16:16
  Вы можете вернуться к предыдущей в любое время.
• 16:18
  Никакого беспокойства о перезаписи.
• 16:20
  Используйте это, чтобы отделить экспериментальную логику от рабочей среды.
• 16:23
  Один поток – для разработки согласований, другой – для рабочих процессов.
• 16:26
  Тестируйте в среде разработки, публикуйте только после стабилизации.
• 16:29
  Помните, надежность – это не только корректность, это контроль в условиях изменений.
• 16:34
  После публикации используйте журналы активности.
• 16:37
  Они не для галочки, это юридически значимые записи взаимодействий и и людей.
• 16:41
  Временные метки, личности согласующих, краткое описание обоснований.
• 16:44
  Периодически просматривайте эти журналы.
• 16:46
  Закономерности проявят себя сами.
• 16:48
  Какие правила вызывают больше всего отказов, какие менеджеры переопределяли и, как часто срабатывают шаги контроля.
• 16:53
  Эти данные помогают совершенствовать политику и проектирование.
• 16:56
  Еще одна тонкая рекомендация – автоматизируйте обновление статусов в записях Dataverse в конце каждой ветки.
• 17:02
  Действие по обновлению строки должно задавать четкое поле, например, статус заявки «одобрено» или «отклонено».
• 17:07
  Эта наглядность укрепляет доверие.
• 17:09
  Пользователи видят решение прямо в своих таблицах.
• 17:12
  Никаких отдельных таблиц для отслеживания и призрачных согласований.
• 17:15
  Когда система пройдет все тесты, нажимайте «Опубликовать» со спокойной уверенностью.
• 17:18
  В отличие от прошлых поколений потоков Power Automate, потоки агентов сохраняют контекстные метадонные,
• 17:23
  схему принятия решений и привязки динамического контента и теги версий.
• 17:27
  Результат – это не просто запущенный процесс, а воспроизводимый артефакт, автоматизация, доступная для аудита.
• 17:32
  Финальная проверка надежности – это проверка логики.
• 17:34
  Не допускайте избыточного проектирования.
• 17:36
  Иногда сбой в потоке выявляет слишком сложные правила, а не технические ошибки.
• 17:39
  Упрощайте логику везде, где это возможно.
• 17:42
  Меньше этапов, яснее инструкции, минимум двусмысленности.
• 17:45
  Автоматизация – это не случайность, это излишняя мудренность.
• 17:49
  Завершив этот этап, ваша система утверждений достигает операционной зрелости, протестированной, версионной, отказоустойчивой и проверяемой.
• 17:56
  Каждый результат от решения и до подписи администратора оставляет цифровой след, выдерживающий любую проверку.
• 18:01
  Это надежность в цифрах, а не догадки или удача.
• 18:04
  Это структурированное мышление, точно записанное инструментами, которые работают, пока вы спите.
• 18:09
  Результаты и реальная отдача.
• 18:10
  Что произойдет, если доверить бурократию математике?
• 18:13
  Утверждения перестанут простаивать.
• 18:15
  Многоэтапный агентский поток на базе и сокращает время обработки с дней до минут, поскольку решения больше не зависят от занятости в календаре.
• 18:21
  Каждая заявка, соответствующая объективной политике, одобряется мгновенно.
• 18:25
  Каждый нестандартный случай аккуратно попадает в очередь к менеджеру с уже приложенным контекстом.
• 18:29
  Люди выносят ценностные суждения, а не занимаются канцелярским подтверждением.
• 18:33
  Эффект проявляется прежде всего в сжатии времени.
• 18:35
  Возмещение расходов, на которые раньше требовалось 4 письма и 2 напоминания, теперь решается до обеда.
• 18:40
  Отделы переходят к сокращенным циклам обработки, меньшему времени простое и идеально задокументированным цепочкам рассуждений.
• 18:46
  Механизм утверждения перестает быть помехой.
• 18:48
  Он становится инфраструктурой.
• 18:50
  Затем следует снижение количества ошибок.
• 18:52
  Применяя детерминированные правила через И, вы устраняете субъективные отклонения, проклятие ручных согласований.
• 18:58
  Больше никаких «я думал», это относится к здоровью и благополучию.
• 19:01
  ИИ интерпретирует критерии одинаково каждый раз.
• 19:03
  В административной логике последовательность масштабируется лучше, чем сострадание.
• 19:07
  Менеджеры работают только с аномалиями, и даже они сопровождаются аудиторским следом.
• 19:11
  Входные данные, история решений, объяснение модели.
• 19:14
  Аудиты превращаются из панических мероприятий в спокойные проверки.
• 19:17
  На уровне организации это не просто быстрее, это безопаснее.
• 19:20
  Соблюдение нормативов больше не зависит от памяти или настроения.
• 19:23
  Оно встроено в систему.
• 19:25
  Журналы Dataverse показывают, кто утвердил, когда и почему.
• 19:28
  Такая прозрачность препятствует культуре срезания углов, ведь каждое решение теперь сохраняется навсегда.
• 19:33
  И философский рабочий процесс меняется от «человек с помощью ИИ» и с коррекцией человека.
• 19:38
  Практическое управление, а не научная фантастика.
• 19:40
  И занимается соблюдением правил, люди, принятием решений.
• 19:43
  Этот гибрид создает более справедливые, быстрые и, в конечном итоге, более надежные системы.
• 19:47
  Представьте, как вы объясняете это аудитору.
• 19:49
  Та улыбка, которая последует за этим, стоит всей автоматизации.
• 19:52
  Итак, вот оно.
• 19:53
  Microsoft K-Pilot Studio — это не просто очередной инструмент автоматизации.
• 19:56
  Это место, где нерешительность вашей организации, наконец, уходит в отставку.
• 20:00
  Вы создаете механизм согласования, который умеет мыслить условиями, ответственно эскалировать,
• 20:04
  сверять чеки с реальностью и документировать каждый свой шаг.
• 20:06
  Это не просто поток, это модель управления.
• 20:09
  Если вы запомните лишь одно, пусть это будет следующее.
• 20:11
  ИИ должен делать решения предсказуемыми, а людей — незаменимыми.
• 20:15
  Перестаньте по привычке пропускать все через людей.
• 20:17
  Пусть логика занимается рутиной, чтобы менеджеры могли заниматься исключениями.
• 20:21
  Если это руководство избавило вас от очередной недели ожидания проверки менеджерам, подпишитесь.
• 20:26
  В следующем уроке мы углубимся в продвинутую автоматизацию K-Pilot Studio,
• 20:30
  где потоки агентов связываются с аналитикой Power Platform и адаптивными политиками.
• 20:34
  Зафиксируйте свой путь развития, подпишитесь, включите уведомления
• 20:37
  и позвольте новым выпускам приходить автоматически.
• 20:39
  Никаких ручных проверок, никаких пропущенных релизов,
• 20:41
  только непрерывная доставка полезных знаний.
• 20:43
  Приступайте!