WEBVTT

00:00:00.000 --> 00:00:04.300
Вы тратите полдня на ожидание согласований. Кто-то в отпуске, кто-то не увидел письмо,

00:00:04.480 --> 00:00:09.020
и к тому моменту, когда решение наконец принято, контекст, оправдывавший запрос, уже утрачен.

00:00:09.180 --> 00:00:12.880
Корпоративное чистилище, где прогресс замирает из-за людей, которые уверяют, что они заняты.

00:00:12.980 --> 00:00:17.040
А теперь представьте систему, которая просто не ждет. Рабочий процесс, который движется вперед,

00:00:17.180 --> 00:00:20.620
как только выполнены условия. Встречайте агент Флауса в Microsoft Copilot Studio,

00:00:20.840 --> 00:00:25.020
убийцу бюрократии под маской автоматизации. Здесь и становится вашим первым согласующим лицом.

00:00:25.140 --> 00:00:29.200
Он считывает данные, сверяет их с политикой и выдает обоснованное решение об одобрении или

00:00:29.200 --> 00:00:33.380
отказе, прежде чем человек успеет моргнуть. Только пограничные случаи попадают в почтовый

00:00:33.380 --> 00:00:37.540
ящик менеджера, что обеспечивает скорость без ущерба для контроля. И в отличие от устаревших

00:00:37.540 --> 00:00:41.820
процессов согласования, которые рушатся под грузом сложных условий, эти системы на базе и

00:00:41.820 --> 00:00:45.180
масштабируются, самостоятельно разветвляясь, проверяя и контролируя себя.

00:00:45.340 --> 00:00:49.100
В этом руководстве я покажу, как создать многоэтапную систему условного согласования,

00:00:49.260 --> 00:00:52.980
которая принимает решение быстрее, чем ваши коллеги находят кнопку «Ответить всем».

00:00:52.980 --> 00:00:56.660
Вы узнаете, как настроить этап и использовательской логикой согласования,

00:00:56.660 --> 00:01:00.840
добавить целевые проверки людьми, разработать динамические условия для интеллектуальной

00:01:00.840 --> 00:01:04.400
маршрутизации и интегрировать проверку документов для соблюдения требований.

00:01:04.580 --> 00:01:08.120
К концу вы получите автоматизированный процесс, который знает, когда нужно мыслить как машина,

00:01:08.240 --> 00:01:12.500
а когда довериться человеческому суждению. Хватит стоять в очереди. Позвольте логике управлять

00:01:12.500 --> 00:01:14.920
процессом. Проблема традиционных согласований.

00:01:15.100 --> 00:01:19.160
Традиционные цепочки согласований — это трагический ремикс одной и той же неэффективности.

00:01:19.320 --> 00:01:22.620
Кто-то подает форму, письма летят, таблицы теряют синхронизацию,

00:01:22.620 --> 00:01:26.900
и в круговороте пересылок никто не помнит, какая версия была финальной. Каждый участник

00:01:26.900 --> 00:01:31.600
добавляет задержку, а не ценность. Процесс не управляет работой, он создает задержки.

00:01:31.760 --> 00:01:35.040
Типичные потоки согласования Power Automate пытаются решить эту проблему,

00:01:35.300 --> 00:01:39.400
но они буксуют, как только появляются нюансы. Одиночный путь согласования работает нормально,

00:01:39.620 --> 00:01:43.440
если вам нужно только «да» или «нет». В тот момент, когда вы добавляете уровни управления,

00:01:43.680 --> 00:01:47.460
лимиты затрат или специальные правила, дизайн начинает трещать по швам. Вы заканчиваете тем,

00:01:47.600 --> 00:01:50.840
что вкладываете условия друг в друга, как матрешки, неигантно, хрупко и невозможно

00:01:50.840 --> 00:01:54.880
отладить полгода спустя. Один сломанный коннектор, и вся система тихо выходит из строя.

00:01:55.040 --> 00:01:58.940
Люди становятся бутылочным горлышком или, если быть предельно точным, узлами задержки.

00:01:59.080 --> 00:02:02.620
Каждое сообщение, которое они получают, превращается в еще один асинхронный цикл ожидания.

00:02:02.800 --> 00:02:05.760
Использовать почту для согласований – это как использовать почтовых голубей в мире

00:02:05.760 --> 00:02:08.680
автоволоконных сетей. Технически это работает, но так быть не должно.

00:02:08.880 --> 00:02:14.320
Встречайте Microsoft Copilot Studio. Это не просто обновленная версия Power Automate. Она внедряет

00:02:14.320 --> 00:02:18.400
агентные потоки системы согласования на базе и полностью интегрированные

00:02:18.400 --> 00:02:22.820
в источнике данных, роли и логические структуры вашей организации. Она объединяет

00:02:22.820 --> 00:02:27.240
строгое соблюдение политик с адаптивным принятием решений. Гениальность заключается в том,

00:02:27.420 --> 00:02:31.960
как система разделяет этапы. Автоматизация там, где нужна скорость, и участие человека там,

00:02:32.160 --> 00:02:35.260
где важна проверка. Представьте это как переосмысленную иерархию.

00:02:35.480 --> 00:02:40.580
Этап и оценивает фиксированные правила, лимиты сумм, категории и диапазоны дат с хирургической

00:02:40.580 --> 00:02:44.620
точностью. Затем, если решение вызывает сомнения, процесс переходит к человеку,

00:02:44.620 --> 00:02:48.160
избавляя от необходимости ставить в очередь каждое мелкое дело. Это само по себе

00:02:48.160 --> 00:02:52.180
исключает экспоненциальные задержки. Вместо того, чтобы 10 человек проверяли все по порядку,

00:02:52.340 --> 00:02:55.980
им мгновенно обрабатывает 80%, направляя на ручную проверку только исключение.

00:02:56.100 --> 00:03:01.160
И да, Капайлот Студия отшлеживает все через базу Dataverse, создавая проверяемые логи без

00:03:01.160 --> 00:03:05.920
необходимости копаться в почтовых архивах. Предыдущие рабочие процессы создавались для людей.

00:03:06.080 --> 00:03:10.400
Потоки агентов строятся вокруг них, вовлекая людей только тогда, когда требуется интерпретация,

00:03:10.400 --> 00:03:14.360
а не повторение. Как только вы увидите, как работает эта архитектура, традиционные согласования

00:03:14.360 --> 00:03:18.880
покажутся примитивными, как ведение бухгалтерии при свечах. Ставки просты, соответствие требованиям,

00:03:18.940 --> 00:03:23.060
последовательность и масштабируемость. Современные операции утонут без автоматизированной

00:03:23.060 --> 00:03:28.460
проверки, а логика и теперь стандарт надежности. Переходя от статических процессов к проверяемым

00:03:28.460 --> 00:03:33.480
агентским потоком, вы перестаете реагировать на согласование и начинаете управлять ими как живыми

00:03:33.480 --> 00:03:39.760
системами. Разница не только в скорости, но и в структурном порядке. Создание этапа и обучение первого

00:03:39.760 --> 00:03:44.340
проверяющего. А теперь самое интересное – обучение вашего первого цифрового бюрократа.

00:03:44.480 --> 00:03:49.240
Этап И – это логический превратник вашего процесса согласования. Его задача – не мыслить как

00:03:49.240 --> 00:03:53.260
человек, а выполнять структурированный анализ со сверхчеловеческой стабильностью. Он читает

00:03:53.260 --> 00:03:57.620
инструкции, сверяет их с входными данными и выносит один из двух вердиктов – одобрено или отклонено.

00:03:57.620 --> 00:04:02.120
Никакой политики, никаких перерывов на кофе. Вы начинаете с определения нового потока агента.

00:04:02.260 --> 00:04:05.720
При создании этап И занимает центральное место, как чистый экзаменационный лист,

00:04:05.880 --> 00:04:09.440
ожидающий ключей к вопросам. Триггером обычно служит датаверс – добавление или

00:04:09.440 --> 00:04:14.220
изменение записи в таблице заявок или расходов. Как только заявка создана, этот этап активируется,

00:04:14.420 --> 00:04:18.940
оценивает данные и принимает решения. Внутри этапа самое важное поле – это инструкция

00:04:18.940 --> 00:04:24.120
промп, мозг, всей операции. Здесь вы описываете логику согласования простым, но строгим языком.

00:04:24.120 --> 00:04:28.220
Пишите так, будто инструктируете юриста, который никогда не импровизирует. Например,

00:04:28.460 --> 00:04:34.820
одобрить заявку, если сумма меньше 500, описание связано со здоровьем, а дата покупки не превышает 30 дней

00:04:34.820 --> 00:04:38.720
с момента подачи. Отклонить, если не соблюдено хотя бы одно правило. Вот и все,

00:04:38.720 --> 00:04:43.340
бинарная ясность. Затем определите динамические входные данные. Считайте их переменными,

00:04:43.500 --> 00:04:48.240
подающими реальные данные в вашу логику. Скорее всего, вы включите сумму, описание и дату

00:04:48.240 --> 00:04:53.120
покупки. Каждый элемент добавляется как текстовый, числовой ввод или контент, который и будет

00:04:53.120 --> 00:04:57.680
использовать при принятии решения. Капайлот Студия классифицирует эти вводные данные по типу

00:04:57.680 --> 00:05:02.180
«текст», «число» или «графический документ». Выбирайте правильно, так как смешивание типов,

00:05:02.340 --> 00:05:07.800
например, числа в текстовом формате путает и людей, и машины. Под каждым полем ввода укажите примеры данных

00:05:07.800 --> 00:05:11.740
для тестирования. Это послужит каркасом, пока вы настраиваете логику. Например,

00:05:12.040 --> 00:05:17.540
введите пробную заявку «Коврик для йоги», «Сумма 300», «Дата покупки 22 августа».

00:05:17.540 --> 00:05:23.400
При нажатии кнопки «Тест» Капайлот Студия запускает модель рассуждений на базе GPT и выдает

00:05:23.400 --> 00:05:29.420
решение с пояснением. Если результат соответствует ожиданиям, отлично. Если нет, вашим инструкциям не

00:05:29.420 --> 00:05:34.040
хватает детерминизма. И именно здесь ошибается большинство новичков. Общие или двусмысленные

00:05:34.040 --> 00:05:38.100
формулировки, вроде «Разумные расходы» или «Недавняя покупка – это яд для ИИ»,

00:05:38.100 --> 00:05:41.660
система не может уловить корпоративное настроение, ей нужны математические определения.

00:05:41.780 --> 00:05:45.320
Поэтому безжалостно уточняйте свои инструкции, пока результаты тестов не станут стабильными.

00:05:45.460 --> 00:05:48.580
Каждый раз, когда вы переформулируете задачу, вы настраиваете механизм суждений на

00:05:48.580 --> 00:05:52.260
воспроизводимость. Вам нужно добиться того, чтобы идентичные входные данные всегда давали

00:05:52.260 --> 00:05:56.920
идентичный результат. Машинная логика, а не офисные сплетни. Как только ваш промп начнет выдавать

00:05:56.920 --> 00:06:01.860
надежные решения в разных тестах, вы фактически обучили своего и одобрителя. Теперь внедрите реальные

00:06:01.860 --> 00:06:06.980
динамические данные, используя токены из датаверс, детали суммы заявки, дату покупки или подачи.

00:06:07.080 --> 00:06:12.260
Они заменят тестовые значения во время реальной работы. С этого момента и оценивает каждую заявку

00:06:12.260 --> 00:06:17.100
в контексте, вынося вердикт сразу после появления новых данных. Прежде чем объявлять о победе,

00:06:17.280 --> 00:06:21.920
проведите итеративные тесты. Измените сумму на 600, отклонит ли он ее. Измените дату на 3 месяца

00:06:21.920 --> 00:06:25.780
назад, пометит ли он ее как недействительную. Добавьте нелепую заявку, например, покупку iPad,

00:06:26.020 --> 00:06:29.120
обнаружит ли он несоответствие. Каждый прогон должен демонстрировать последовательную

00:06:29.120 --> 00:06:33.000
причинно-следственную связь. Если ответы колеблются, проблема в четкости вашего промпта,

00:06:33.200 --> 00:06:37.640
а не в модели И. Когда появятся устойчивые закономерности, установите соглашение об именовании

00:06:37.640 --> 00:06:42.800
переменных контента. Используйте префиксы, такие как STR для суммы заявки или NUM для даты

00:06:42.800 --> 00:06:47.560
покупки. Эта небольшая дисциплина предотвратит хаос при дальнейшем расширении до многоветвистой

00:06:47.560 --> 00:06:51.860
логики. На этом этапе ваш автоматизированный одобритель может принимать независимые решения

00:06:51.860 --> 00:06:57.180
согласно политике без контроля. Но автоматизация – это не диктатура, а делегирование. Машина отвечает

00:06:57.180 --> 00:07:01.660
за скорость и точность, а не за суждение. Для пограничных сценариев потребуется эскалация и

00:07:01.660 --> 00:07:06.080
участие человека, чтобы проверить то, что и отклонил или счел сомнительным. Здесь вступает в

00:07:06.080 --> 00:07:10.060
силу следующий этап, и так полномочия распределяются между кремнием и сотрудниками.

00:07:10.260 --> 00:07:14.980
Добавление человеческого контроля, многоэтапной и условной логики. Когда ваш И начнет уверенно

00:07:14.980 --> 00:07:19.020
оценивать заявки, вы сможете добавить то, что в бюрократии иронично называют человеческим

00:07:19.020 --> 00:07:23.800
подходом. В CoPilot Studio это означает ручной этап, контрольную точку, где реальный человек может

00:07:23.800 --> 00:07:27.560
проявить осмотрительность. Думайте об этом как о своем предохранительном клапане. Все

00:07:27.560 --> 00:07:32.120
предсказуемые процессы проходят автоматически. Все, что требует нюансов, попадает на стол

00:07:32.120 --> 00:07:36.480
менеджеру. Начните в конструкторе утверждений, добавив ручной этап сразу после этапа И. Это

00:07:36.480 --> 00:07:40.420
создает второй барьер в потоке работы вашего агента. Передача управления происходит на определенных

00:07:40.420 --> 00:07:45.100
условиях. Только если вердикт И одобрено, мы переходим к этапу с участием человека. Если И говорит

00:07:45.100 --> 00:07:49.260
«отклонено», процесс на этом завершается. Зачем тратить время менеджеров на подтверждение того,

00:07:49.260 --> 00:07:52.300
что политика уже исключила? Эффективность – это избирательное внимание,

00:07:52.300 --> 00:07:55.940
замаскированное под автоматизацию. Давайте разберем пример сценария. Допустим,

00:07:56.100 --> 00:07:59.740
сотрудник подает заявку на возмещение расходов за абонемент в спортзал. И одобряет ее,

00:07:59.940 --> 00:08:04.220
так как все критерии соответствуют политике. Теперь это решение запускает ручной этап уровня

00:08:04.220 --> 00:08:09.100
менеджера под названием «Одобрение менеджером». В настройках вы задаете этому этапу заголовок,

00:08:09.320 --> 00:08:14.580
например, запрос на утверждение от автора заявки. Эти переменные динамически извлекают данные из

00:08:14.580 --> 00:08:19.600
датаверс. В поле «Кому назначено» вы определяете получателя задачи, обычно это руководитель

00:08:19.600 --> 00:08:23.660
заявителя. Для автоматизации этой маршрутизации Copilot Studio позволяет интегрировать

00:08:23.660 --> 00:08:28.860
коннектор Office 365 users. Сначала получите запись пользователя, создавшего заявку, с помощью

00:08:28.860 --> 00:08:33.420
действия «Получить строку по ID» в таблице пользователей датаверс. Это извлекает информацию о

00:08:33.420 --> 00:08:37.480
заявителе. Затем действие «Получить менеджера» находит руководителя этого пользователя через его

00:08:37.480 --> 00:08:39.960
основной email. Передайте этот результат в ваш ручной этап в качестве переменной,

00:08:40.120 --> 00:08:44.860
например, str-менеджер-меджер-меджер. Результат – никакой жесткой кодировки и устаревших

00:08:44.860 --> 00:08:49.060
иерархий. Менеджеры меняются, иерархия обновляется сама. Теперь переходим к условным

00:08:49.060 --> 00:08:53.320
ветвлениям – истинной причине существования многоэтапных утверждений. Вы можете внедрить логику

00:08:53.320 --> 00:08:58.140
непосредственно в поток агента. Если сумма заявки больше или равна 150, добавьте дополнительный

00:08:58.140 --> 00:09:02.340
этап для административного утверждения. В противном случае завершите процесс. Это превращает

00:09:02.340 --> 00:09:06.540
простую двухшаговую рутину в многоуровневое дерево решений, адаптирующееся к контексту.

00:09:06.700 --> 00:09:11.040
Заявки с низкой стоимостью проверяет один человек. Более дорогие или рискованные заявки передаются

00:09:11.040 --> 00:09:14.920
на дополнительную проверку. В дизайнере вставьте действие условия перед завершением потока.

00:09:15.120 --> 00:09:17.600
Сошлитесь на свою числовую переменную, например, num, нижнее подчеркивание,

00:09:17.680 --> 00:09:22.000
клэм, нижнее подчеркивание, амаунт. Выберите оператор, больше или равно, и установите пороговое

00:09:22.000 --> 00:09:26.380
значение, например, 150. В ветке, если истина, добавьте еще один ручной этап под названием

00:09:26.380 --> 00:09:29.300
административное утверждение. Назначьте его на фиксированного утверждающего, например,

00:09:29.480 --> 00:09:32.900
администратора по соответствию требованиям. В ветке, если ложь, завершите процесс со статусом

00:09:32.900 --> 00:09:36.100
одобрено. Эффект «Рабочий процесс» ведет себя как рациональная организация,

00:09:36.260 --> 00:09:40.340
а не как универсальная бутылочная горлышко. Здесь уместна доля практического юмора. Да,

00:09:40.580 --> 00:09:44.920
делегирование все еще требует доверия, а не слепой надежды. Не назначайте широкие роли безопасности,

00:09:45.060 --> 00:09:48.400
которые позволяют одобрять все подряд. Ограничьте права доступа для соответствующих пользователей

00:09:48.400 --> 00:09:51.580
или групп с помощью управления доступом на основе ролей в датаверс. В противном случае вы

00:09:51.580 --> 00:09:55.260
просто автоматизируете хаос. Тестирование структуры показывает, насколько гармонично все элементы

00:09:55.260 --> 00:09:59.380
сочетаются друг с другом. Если заявка на сумму менее 150 долларов проходит проверку и…

00:09:59.380 --> 00:10:02.800
Процесс завершается после одобрения менеджером. Если сумма превышает 150 долларов,

00:10:03.040 --> 00:10:06.040
система корректно ставит ее в очередь на проверку администраторам перед финализацией.

00:10:06.200 --> 00:10:09.480
Каждый путь оставляет аудиторский след, журнал рассуждений и… Одобрение с отметками

00:10:09.480 --> 00:10:13.360
времени и зафиксированные результаты, хранящиеся в датаверс. Никто не сможет потом заявить,

00:10:13.480 --> 00:10:17.560
«Я этого не видел». База данных говорит об обратном. В процессе доработки придерживайтесь

00:10:17.560 --> 00:10:21.800
строгих правил именования. Четко обозначайте этапы участия человека, например, одобрено менеджером,

00:10:21.960 --> 00:10:25.560
одобрено администратором, чтобы визуально отслеживать ветки процесса. Блок-схема должна читаться

00:10:25.560 --> 00:10:29.200
как логическая цепочка, а не как загадочное искусство. Достигнув желаемого, опубликуйте и

00:10:29.200 --> 00:10:33.200
протестируйте решение на реальных сценариях. Наблюдайте за развитием цепочки событий и проводят

00:10:33.200 --> 00:10:37.580
оценку мгновенно. Менеджер получает целевую задачу на одобрение. Администратор подключается

00:10:37.580 --> 00:10:42.040
только при выполнении определенных условий. Результат выглядит не как автоматизация всего подряд,

00:10:42.280 --> 00:10:46.920
а как прозрачная иерархия, которая работает сама по себе. Эта многоуровневая оркестрация также

00:10:46.920 --> 00:10:51.520
открывает новые горизонты, проверку документов. Ведь иногда поля формы могут содержать ошибку,

00:10:51.520 --> 00:10:55.120
а чек – нет. Следующий шаг – заставить и изучать физические доказательства

00:10:55.120 --> 00:10:59.060
еще до того, как они попадут в ваш почтовый ящик. Здесь на помощь приходит проверка чеков,

00:10:59.260 --> 00:11:03.760
превращающая бурократию в проверяемую науку, динамические входные данные и проверка документов.

00:11:03.920 --> 00:11:07.440
Давайте поговорим о чеках, этих крошечных помятых бумажках, которые загадочным образом

00:11:07.440 --> 00:11:10.420
становятся важнейшими уликами, как только кто-то хочет получить возмещение.

00:11:10.540 --> 00:11:15.460
В ручном процессе одобрения люди проверяют их на глаз. Да, это похоже на коврик для йоги,

00:11:15.640 --> 00:11:19.280
а не на яхту. В автоматизированном процессе мы поручаем и выполнить ту же проверку,

00:11:19.280 --> 00:11:23.620
не опасаясь усталости от принятия решений. В агентных потоках Капайлот Студия проверка документов

00:11:23.620 --> 00:11:27.340
реализуется с помощью динамических входных данных, в частности, возможности передавать

00:11:27.340 --> 00:11:32.100
изображение или файл в логику вашего одобрения. Это добавляет вашему и верификатору третье чувство

00:11:32.100 --> 00:11:36.400
зрения. Вместо того, чтобы полагаться только на текстовые поля, модель считывает документ и сравнивает

00:11:36.400 --> 00:11:41.080
написанное в нем с тем, что было загружено. Вот структура процесса. На этапе работы и вы добавляете

00:11:41.080 --> 00:11:46.280
новый тип входных данных, изображение или документ. Назовите его понятно, например, файл чека.

00:11:46.400 --> 00:11:51.300
Загрузите образец чека для тестирования. Это не запускается в рабочую среду, а лишь обучает логическую схему.

00:11:51.300 --> 00:11:54.880
Теперь скорректируйте промп с инструкциями, включив в него перекрестную проверку документа.

00:11:55.020 --> 00:11:59.260
Вы расширяете свою предыдущую логику. Одобряйте заявку, если выполняются все следующие условия.

00:11:59.480 --> 00:12:03.160
Сумма до 500. Детали заявки связаны с физическим или ментальным здоровьем. Дата покупки в пределах

00:12:03.160 --> 00:12:06.080
30 дней. А документ чека соответствует заявленному товару, сумме и дате.

00:12:06.220 --> 00:12:11.200
Это четвертое условие превращает ваш и верификатор из контролера-политик в эксперта-криминалиста.

00:12:11.380 --> 00:12:16.360
Во время выполнения теста модель извлекает читаемый текст из документа и проверяет его соответствие

00:12:16.360 --> 00:12:21.620
вашим структурированным данным. Если в чеке указан коврик для фитнеса за 300 долларов от 22 августа,

00:12:21.780 --> 00:12:24.760
а в вашей заявке что-то другое, решение меняется на «Отклонено».

00:12:24.760 --> 00:12:28.720
Теперь перейдем к реализации. До начала процесса утверждения вам нужно будет получить этот документ.

00:12:28.880 --> 00:12:31.940
Используйте действие «Загрузить файл или изображение из датаверс».

00:12:31.940 --> 00:12:35.520
Укажите ту же таблицу, в которой находится запись заявки, скорее всего, заявки.

00:12:35.640 --> 00:12:39.780
В поле файла выберите поле вложения, которое часто называется, например, «Чек».

00:12:39.780 --> 00:12:44.720
Затем укажите идентификатор строки «Динамически из триггера». Это уникальный идентификатор заявки.

00:12:44.860 --> 00:12:48.960
Это действие возвращает метадонные и содержимое файла, но здесь кроется скрытая ловушка.

00:12:49.200 --> 00:12:53.400
Выходные данные содержимого требуют небольшой доработки, чтобы и мог интерпретировать их правильно.

00:12:53.560 --> 00:12:58.480
При сопоставлении содержимого файла с входным файлом чека откройте редактор выражений и добавьте

00:12:58.480 --> 00:13:04.300
«Контент» с ссылки на «Боди». Эта последняя настройка передает сами байты файла, а не обертку с метадонными.

00:13:04.440 --> 00:13:07.780
Пропустите это, и ваш и будет с энтузиазмом одобрять пустые чеки.

00:13:07.780 --> 00:13:11.700
Давайте обсудим синхронизацию Ахиллесову пяту рабочих процессов с документами.

00:13:11.860 --> 00:13:15.860
Большинство таблиц Датаверс не хранят вложения до тех пор, пока запись не будет сохранена впервые,

00:13:16.100 --> 00:13:20.460
а значит, если ваш поток запускается при создании записи, он может сработать до того, как файл появится.

00:13:20.660 --> 00:13:24.080
Симптом. Поток завершается с ошибкой или содержимое чека равно налым.

00:13:24.240 --> 00:13:27.820
Решение элегантно. Измените условия триггера на при изменении элемента,

00:13:28.020 --> 00:13:31.320
но ограничьте его срабатывание только моментом изменения столбца с чеком.

00:13:31.460 --> 00:13:35.860
Таким образом, как только кто-то загружает или заменяет файл, запускается проверка.

00:13:35.860 --> 00:13:39.800
Чтобы настроить это, откройте параметры триггера, выберите «Измененные столбцы»

00:13:39.800 --> 00:13:41.880
и вставьте логическое имя вашего столбца чека,

00:13:42.080 --> 00:13:45.740
которое можно найти в сведениях о столбце Датаверс в разделе «Дополнительных инструментов».

00:13:45.740 --> 00:13:47.660
После настройки опубликуйте изменения.

00:13:47.840 --> 00:13:49.960
Теперь ваша автоматизация ведет себя корректно.

00:13:50.120 --> 00:13:52.920
Она ждет, пока появится что-то, что действительно нужно проверить.

00:13:53.040 --> 00:13:56.060
Когда заявка обновляется новым чеком, поток перезапускается.

00:13:56.240 --> 00:14:00.640
Он скачивает файл, пропускает его через этап и перепроверяет все данные.

00:14:00.640 --> 00:14:04.660
Если обнаружены несоответствия, несовпадения суммы, устаревшая дата,

00:14:04.900 --> 00:14:07.920
нечеткие описания и отклоняет заявку с пояснением.

00:14:08.100 --> 00:14:10.960
Журнал обоснований может гласить, заявленная сумма 305 долларов

00:14:10.960 --> 00:14:13.140
отличается от итоговой суммы в документе 300 долларов.

00:14:13.300 --> 00:14:14.900
Это соблюдение правил без жалоб.

00:14:15.000 --> 00:14:16.000
Практический результат.

00:14:16.260 --> 00:14:18.300
Каждая заявка становится самопроверяемой.

00:14:18.460 --> 00:14:22.140
Сотрудники больше не могут протащить сомнительные чеки или расплывчатые описания.

00:14:22.320 --> 00:14:23.400
И выносят суждения.

00:14:23.660 --> 00:14:27.180
Датаверс предоставляет доказательства, и никто из них не уходит на перерыв.

00:14:27.180 --> 00:14:29.940
Так что нет, проверка документов – это не излишество.

00:14:30.100 --> 00:14:32.860
Это своего рода иммунная память для ваших рабочих процессов.

00:14:32.980 --> 00:14:36.880
Отклонения выявляются на молекулярном уровне, в символах, напечатанных на реальных чеках,

00:14:37.060 --> 00:14:40.380
а человек-проверяющий переходит от ручной проверки к работе с исключениями.

00:14:40.540 --> 00:14:43.420
Поздравляю, вы только что автоматизировали саму честность.

00:14:43.620 --> 00:14:47.420
Обеспечение надежности, тестирование, версионирование и публикация.

00:14:47.620 --> 00:14:50.580
Любая автоматизация кажется идеальной, пока ее не запустят.

00:14:50.720 --> 00:14:53.180
Вот почему надежность – это не этап, а дисциплина.

00:14:53.180 --> 00:14:56.820
Капайлот Студия делает эту дисциплину удивительно простой благодаря контролю версий,

00:14:57.020 --> 00:14:59.620
тестированию и публикации, встроенным прямо в потоке агента.

00:14:59.800 --> 00:15:01.420
Начните с атеративного тестирования.

00:15:01.640 --> 00:15:04.400
Каждый процесс согласования – это миниатюрная экосистема.

00:15:04.520 --> 00:15:06.940
Даже одно неверное имя переменной может вызвать хаос.

00:15:07.060 --> 00:15:09.840
Поэтому относитесь к тестированию как к научному процессу.

00:15:10.000 --> 00:15:12.920
Изолируйте изменения, вводите данные, наблюдайте результат.

00:15:13.160 --> 00:15:16.500
В редакторе потоков Капайлот Студия позволяет имитировать пробные данные

00:15:16.500 --> 00:15:18.360
без развертывания производственных триггеров.

00:15:18.360 --> 00:15:22.840
Проверяйте различные сценарии, слишком большую сумму, устаревшую дату, неверные названия

00:15:22.840 --> 00:15:25.260
и убедитесь, что каждый выдает правильный вердикт.

00:15:25.380 --> 00:15:27.360
Затем переходите к соглашениям об именовании.

00:15:27.580 --> 00:15:28.780
Скучно? Безусловно.

00:15:28.960 --> 00:15:30.260
Важно? Жизненно необходимо.

00:15:30.560 --> 00:15:32.620
Систематически добавляйте префиксы ко всем переменным.

00:15:32.780 --> 00:15:35.280
str для строк, num для чисел, doc для файлов.

00:15:35.420 --> 00:15:37.480
Точно так же давайте четкие названия действиям.

00:15:37.600 --> 00:15:40.900
Загрузить файл чека, проверить одобрение менеджера, обновить статус заявки.

00:15:41.000 --> 00:15:44.120
Потому что через три месяца, когда кто-то спросит, почему действие номер 7 сломалось,

00:15:44.120 --> 00:15:46.720
вы оцените, что подсказки лучше, чем археологические раскопки.

00:15:46.820 --> 00:15:50.400
Как только индивидуальные тесты пройдены, переходите к проверке граничных сценариев.

00:15:50.540 --> 00:15:52.620
Представьте себя некомпетентным пользователем.

00:15:52.800 --> 00:15:56.940
Не загрузите чек, измените дату на следующий год, введите 500 вместо 500.

00:15:57.200 --> 00:16:00.540
Убедитесь, что и объясняет ошибку и отклоняет запрос, не зависая.

00:16:00.680 --> 00:16:03.540
Это не гипотетические провалы, это репетиция реальности.

00:16:03.720 --> 00:16:06.640
Чем больше ошибок вы устраните заранее, тем меньше сообщений в Teams,

00:16:06.780 --> 00:16:09.900
в 2 часа ночи вы получите позже о том, что поток снова остановился.

00:16:10.140 --> 00:16:11.820
Публикация обеспечивает управление.

00:16:11.820 --> 00:16:16.220
Каждый раз, когда вы сохраняете важные изменения, Капайлот Студия незаметно создает новую версию.

00:16:16.400 --> 00:16:18.100
Вы можете вернуться к предыдущей в любое время.

00:16:18.300 --> 00:16:19.880
Никакого беспокойства о перезаписи.

00:16:20.040 --> 00:16:23.220
Используйте это, чтобы отделить экспериментальную логику от рабочей среды.

00:16:23.360 --> 00:16:26.720
Один поток – для разработки согласований, другой – для рабочих процессов.

00:16:26.820 --> 00:16:29.780
Тестируйте в среде разработки, публикуйте только после стабилизации.

00:16:29.940 --> 00:16:34.220
Помните, надежность – это не только корректность, это контроль в условиях изменений.

00:16:34.560 --> 00:16:37.140
После публикации используйте журналы активности.

00:16:37.320 --> 00:16:41.200
Они не для галочки, это юридически значимые записи взаимодействий и и людей.

00:16:41.200 --> 00:16:44.500
Временные метки, личности согласующих, краткое описание обоснований.

00:16:44.640 --> 00:16:46.440
Периодически просматривайте эти журналы.

00:16:46.620 --> 00:16:48.120
Закономерности проявят себя сами.

00:16:48.300 --> 00:16:53.580
Какие правила вызывают больше всего отказов, какие менеджеры переопределяли и, как часто срабатывают шаги контроля.

00:16:53.700 --> 00:16:56.540
Эти данные помогают совершенствовать политику и проектирование.

00:16:56.780 --> 00:17:02.040
Еще одна тонкая рекомендация – автоматизируйте обновление статусов в записях Dataverse в конце каждой ветки.

00:17:02.240 --> 00:17:07.540
Действие по обновлению строки должно задавать четкое поле, например, статус заявки «одобрено» или «отклонено».

00:17:07.540 --> 00:17:09.260
Эта наглядность укрепляет доверие.

00:17:09.420 --> 00:17:11.880
Пользователи видят решение прямо в своих таблицах.

00:17:12.000 --> 00:17:15.000
Никаких отдельных таблиц для отслеживания и призрачных согласований.

00:17:15.140 --> 00:17:18.660
Когда система пройдет все тесты, нажимайте «Опубликовать» со спокойной уверенностью.

00:17:18.780 --> 00:17:23.420
В отличие от прошлых поколений потоков Power Automate, потоки агентов сохраняют контекстные метадонные,

00:17:23.580 --> 00:17:27.120
схему принятия решений и привязки динамического контента и теги версий.

00:17:27.300 --> 00:17:32.180
Результат – это не просто запущенный процесс, а воспроизводимый артефакт, автоматизация, доступная для аудита.

00:17:32.180 --> 00:17:34.600
Финальная проверка надежности – это проверка логики.

00:17:34.760 --> 00:17:36.360
Не допускайте избыточного проектирования.

00:17:36.560 --> 00:17:39.760
Иногда сбой в потоке выявляет слишком сложные правила, а не технические ошибки.

00:17:39.920 --> 00:17:41.900
Упрощайте логику везде, где это возможно.

00:17:42.160 --> 00:17:45.380
Меньше этапов, яснее инструкции, минимум двусмысленности.

00:17:45.820 --> 00:17:49.080
Автоматизация – это не случайность, это излишняя мудренность.

00:17:49.260 --> 00:17:55.900
Завершив этот этап, ваша система утверждений достигает операционной зрелости, протестированной, версионной, отказоустойчивой и проверяемой.

00:17:56.020 --> 00:18:01.260
Каждый результат от решения и до подписи администратора оставляет цифровой след, выдерживающий любую проверку.

00:18:01.260 --> 00:18:03.920
Это надежность в цифрах, а не догадки или удача.

00:18:04.100 --> 00:18:08.780
Это структурированное мышление, точно записанное инструментами, которые работают, пока вы спите.

00:18:09.000 --> 00:18:10.500
Результаты и реальная отдача.

00:18:10.680 --> 00:18:13.180
Что произойдет, если доверить бурократию математике?

00:18:13.400 --> 00:18:15.020
Утверждения перестанут простаивать.

00:18:15.240 --> 00:18:21.620
Многоэтапный агентский поток на базе и сокращает время обработки с дней до минут, поскольку решения больше не зависят от занятости в календаре.

00:18:21.760 --> 00:18:25.400
Каждая заявка, соответствующая объективной политике, одобряется мгновенно.

00:18:25.580 --> 00:18:29.640
Каждый нестандартный случай аккуратно попадает в очередь к менеджеру с уже приложенным контекстом.

00:18:29.640 --> 00:18:33.040
Люди выносят ценностные суждения, а не занимаются канцелярским подтверждением.

00:18:33.180 --> 00:18:35.320
Эффект проявляется прежде всего в сжатии времени.

00:18:35.520 --> 00:18:40.140
Возмещение расходов, на которые раньше требовалось 4 письма и 2 напоминания, теперь решается до обеда.

00:18:40.240 --> 00:18:46.160
Отделы переходят к сокращенным циклам обработки, меньшему времени простое и идеально задокументированным цепочкам рассуждений.

00:18:46.340 --> 00:18:48.720
Механизм утверждения перестает быть помехой.

00:18:48.860 --> 00:18:49.640
Он становится инфраструктурой.

00:18:50.560 --> 00:18:52.620
Затем следует снижение количества ошибок.

00:18:52.620 --> 00:18:57.840
Применяя детерминированные правила через И, вы устраняете субъективные отклонения, проклятие ручных согласований.

00:18:58.000 --> 00:19:01.080
Больше никаких «я думал», это относится к здоровью и благополучию.

00:19:01.240 --> 00:19:03.560
ИИ интерпретирует критерии одинаково каждый раз.

00:19:03.720 --> 00:19:07.260
В административной логике последовательность масштабируется лучше, чем сострадание.

00:19:07.460 --> 00:19:11.160
Менеджеры работают только с аномалиями, и даже они сопровождаются аудиторским следом.

00:19:11.280 --> 00:19:14.000
Входные данные, история решений, объяснение модели.

00:19:14.200 --> 00:19:17.500
Аудиты превращаются из панических мероприятий в спокойные проверки.

00:19:17.500 --> 00:19:20.660
На уровне организации это не просто быстрее, это безопаснее.

00:19:20.860 --> 00:19:23.580
Соблюдение нормативов больше не зависит от памяти или настроения.

00:19:23.780 --> 00:19:24.820
Оно встроено в систему.

00:19:25.020 --> 00:19:27.840
Журналы Dataverse показывают, кто утвердил, когда и почему.

00:19:28.060 --> 00:19:33.000
Такая прозрачность препятствует культуре срезания углов, ведь каждое решение теперь сохраняется навсегда.

00:19:33.200 --> 00:19:38.220
И философский рабочий процесс меняется от «человек с помощью ИИ» и с коррекцией человека.

00:19:38.380 --> 00:19:40.780
Практическое управление, а не научная фантастика.

00:19:40.900 --> 00:19:43.560
И занимается соблюдением правил, люди, принятием решений.

00:19:43.560 --> 00:19:47.380
Этот гибрид создает более справедливые, быстрые и, в конечном итоге, более надежные системы.

00:19:47.460 --> 00:19:49.380
Представьте, как вы объясняете это аудитору.

00:19:49.440 --> 00:19:52.300
Та улыбка, которая последует за этим, стоит всей автоматизации.

00:19:52.460 --> 00:19:53.300
Итак, вот оно.

00:19:53.520 --> 00:19:56.480
Microsoft K-Pilot Studio — это не просто очередной инструмент автоматизации.

00:19:56.620 --> 00:19:59.920
Это место, где нерешительность вашей организации, наконец, уходит в отставку.

00:20:00.060 --> 00:20:04.220
Вы создаете механизм согласования, который умеет мыслить условиями, ответственно эскалировать,

00:20:04.380 --> 00:20:06.800
сверять чеки с реальностью и документировать каждый свой шаг.

00:20:06.920 --> 00:20:08.920
Это не просто поток, это модель управления.

00:20:09.120 --> 00:20:11.600
Если вы запомните лишь одно, пусть это будет следующее.

00:20:11.600 --> 00:20:15.180
ИИ должен делать решения предсказуемыми, а людей — незаменимыми.

00:20:15.180 --> 00:20:17.600
Перестаньте по привычке пропускать все через людей.

00:20:17.760 --> 00:20:21.400
Пусть логика занимается рутиной, чтобы менеджеры могли заниматься исключениями.

00:20:21.560 --> 00:20:26.360
Если это руководство избавило вас от очередной недели ожидания проверки менеджерам, подпишитесь.

00:20:26.520 --> 00:20:30.020
В следующем уроке мы углубимся в продвинутую автоматизацию K-Pilot Studio,

00:20:30.300 --> 00:20:34.200
где потоки агентов связываются с аналитикой Power Platform и адаптивными политиками.

00:20:34.380 --> 00:20:37.140
Зафиксируйте свой путь развития, подпишитесь, включите уведомления

00:20:37.140 --> 00:20:39.100
и позвольте новым выпускам приходить автоматически.

00:20:39.260 --> 00:20:41.520
Никаких ручных проверок, никаких пропущенных релизов,

00:20:41.520 --> 00:20:43.300
только непрерывная доставка полезных знаний.

00:20:43.440 --> 00:20:44.040
Приступайте!