WEBVTT

00:00:00.000 --> 00:00:02.500
Ви витрачаєте півдня на очікування погоджень.

00:00:02.640 --> 00:00:04.680
Хтось у відпустці, хтось інший не бачив листа,

00:00:04.840 --> 00:00:06.960
і до того моменту, коли рішення нарешті приходить,

00:00:07.080 --> 00:00:09.040
контекст запиту вже втрачає актуальність.

00:00:09.220 --> 00:00:11.180
Корпоративне чистилище, де прогрес гальмують люди,

00:00:11.300 --> 00:00:12.860
які запевняють, що вони дуже зайняті.

00:00:13.000 --> 00:00:15.120
Тепер уявіть систему, яка просто не чекає.

00:00:15.280 --> 00:00:18.220
Робочий процес, що рухається вперед, як тільки виконано умови.

00:00:18.340 --> 00:00:20.540
Зустрічайте Agent Flows у Microsoft Co-Pilot Studio,

00:00:20.740 --> 00:00:22.780
вбивцю бюрократії, замаскованого під автоматизацію.

00:00:22.780 --> 00:00:24.920
Тут ще стає вашим першим погоджувачем.

00:00:25.060 --> 00:00:27.540
Він зчитує дані, оцінює їх відповідно до політики

00:00:27.540 --> 00:00:29.900
та дає обґрунтоване схвалення чи відмову раніше,

00:00:30.040 --> 00:00:31.280
ніж будь-то встигне кліпнути.

00:00:31.440 --> 00:00:34.020
Лише складні випадки потрапляють до скриньки менеджера,

00:00:34.180 --> 00:00:36.260
що означає швидкість без втрати контролю.

00:00:36.400 --> 00:00:38.660
І на відміну від застарілих ланцюжків погодження,

00:00:38.820 --> 00:00:40.380
що руйнуються від складності умов,

00:00:40.500 --> 00:00:43.180
ці системи на базі ще й масштабуються, розгалужуються,

00:00:43.300 --> 00:00:45.080
перевіряють та аудитують самі себе.

00:00:45.080 --> 00:00:46.520
У цьому посібнику я покажу,

00:00:46.680 --> 00:00:49.060
як побудувати багаторівневу систему умовних погоджень,

00:00:49.160 --> 00:00:50.480
яка ухвалює рішення швидше,

00:00:50.600 --> 00:00:52.980
ніж ваші колеги знайдуть кнопку «Відповісти всім».

00:00:52.980 --> 00:00:54.920
Ви дізнаєтеся, як налаштувати етап

00:00:54.920 --> 00:00:56.560
ще з власною логікою погодження,

00:00:56.680 --> 00:00:58.140
додати цільові перевірки людьми,

00:00:58.300 --> 00:01:01.320
розробити динамічні умови для інтелектуальної маршрутизації

00:01:01.320 --> 00:01:03.120
та інтегрувати перевірку документів

00:01:03.120 --> 00:01:04.400
для відповідності вимогам.

00:01:04.560 --> 00:01:06.540
Наприкінці ви отримаєте автоматизований процес,

00:01:06.540 --> 00:01:08.060
який знає, коли думати як машина,

00:01:08.060 --> 00:01:09.600
а коли довіритися людському судженню.

00:01:09.760 --> 00:01:11.020
Досить стояти в черзі.

00:01:11.140 --> 00:01:13.180
Почніть дозволяти логіці вести процес.

00:01:13.320 --> 00:01:14.980
Проблема традиційних погоджень.

00:01:15.100 --> 00:01:16.520
Традиційні ланцюжки погоджень –

00:01:16.520 --> 00:01:19.100
це трагічний ремікс однієї і тієї ж неефективності.

00:01:19.260 --> 00:01:20.980
Хтось надсилає форму, листи літають,

00:01:21.120 --> 00:01:23.040
електронні таблиці втрачають синхронізацію

00:01:23.040 --> 00:01:24.680
і через пересилки ніхто не пам'ятає,

00:01:24.860 --> 00:01:26.040
яка версія була фінальною.

00:01:26.180 --> 00:01:28.780
Кожен учасник лише додає затримку, а не цінність.

00:01:28.780 --> 00:01:31.620
Процес не керує роботою, він створює затримки.

00:01:31.760 --> 00:01:33.700
Типові потоки погодження Pava Otamate

00:01:33.700 --> 00:01:34.900
намагаються це вирішити,

00:01:35.000 --> 00:01:37.420
але зупиняються, як тільки з'являються нюанси.

00:01:37.540 --> 00:01:39.200
Один шлях погодження працює добре,

00:01:39.300 --> 00:01:41.220
якщо потрібне лише одне, так чи ні.

00:01:41.380 --> 00:01:43.060
Як тільки додаються рівні управління,

00:01:43.200 --> 00:01:44.840
ліміти витрат або спеціальні правила,

00:01:44.960 --> 00:01:46.580
конструкція починає розпадатися.

00:01:46.740 --> 00:01:48.240
Ви в результаті вкладаєте умови,

00:01:48.240 --> 00:01:49.960
як у матришку – незграбно, крихко

00:01:49.960 --> 00:01:51.700
і неможливо виправити через півроку.

00:01:51.700 --> 00:01:52.980
Один зламаний конектор,

00:01:53.140 --> 00:01:54.980
і вся система мовчки виходить з ладу.

00:01:55.140 --> 00:01:56.480
Люди стають вузьким місцем

00:01:56.480 --> 00:01:58.760
або, якщо бути відвертим, вузлами затримки.

00:01:58.920 --> 00:02:00.580
Кожне повідомлення, яке вони отримують,

00:02:00.680 --> 00:02:02.600
стає ще одним асинхронним циклом очікування.

00:02:02.860 --> 00:02:04.600
Використовувати електронну пошту для погоджень

00:02:04.600 --> 00:02:06.420
– це як поштові голуби у світі оптоволокна.

00:02:06.580 --> 00:02:08.520
Технічно це працює, але так не має бути.

00:02:08.680 --> 00:02:10.720
Зустрічайте Microsoft Coopilot Studio.

00:02:10.720 --> 00:02:13.620
Це не просто інкрементальне оновлення Pava Otamate.

00:02:13.820 --> 00:02:15.440
Вона впроваджує агентні потоки

00:02:15.440 --> 00:02:17.080
системи погодження на базі ЩІ

00:02:17.080 --> 00:02:19.080
повністю інтегровані з джерелами даних,

00:02:19.200 --> 00:02:21.900
ролями та логічними структурами вашої організації.

00:02:22.140 --> 00:02:24.380
Вона поєднує детерміноване дотримання політик

00:02:24.380 --> 00:02:25.840
з адаптивним прийняттям рішень.

00:02:26.040 --> 00:02:27.380
Геніальність полягає в тому,

00:02:27.540 --> 00:02:28.900
як вона розділяє етапи.

00:02:29.240 --> 00:02:31.040
Автоматизація, де потрібна швидкість,

00:02:31.120 --> 00:02:32.780
і люди, де ще потрібна перевірка.

00:02:32.940 --> 00:02:35.160
Уявіть це як переосмислену ієрархію.

00:02:35.160 --> 00:02:37.200
Етап ЩІ оцінює фіксовані правила,

00:02:37.380 --> 00:02:38.920
ліміти сум, типи категорій,

00:02:38.920 --> 00:02:41.260
діапазони дат з клінічною ефективністю.

00:02:41.420 --> 00:02:43.200
Потім, якщо рішення неоднозначне,

00:02:43.280 --> 00:02:44.560
процес переходить до людини,

00:02:44.680 --> 00:02:47.200
не змушуючи кожен дрібний випадок ставати в чергу.

00:02:47.360 --> 00:02:49.840
Це саме по собі усуває експоненціальну затримку.

00:02:50.040 --> 00:02:51.180
Замість того, щоб 10 людей

00:02:51.180 --> 00:02:52.580
виконували послідовні перевірки,

00:02:52.680 --> 00:02:54.480
ще миттєво обробляє 80%,

00:02:54.480 --> 00:02:55.760
спрямовуючи лише винятки.

00:02:55.760 --> 00:02:59.200
І так, Co-Pilot Studio відстежує все через основу Dataverse,

00:02:59.360 --> 00:03:02.160
створюючи перевірювані журнали без потреби вашої команди

00:03:02.160 --> 00:03:03.420
ритися в архівах пошти.

00:03:03.420 --> 00:03:05.940
Попередні робочі процеси були створені для людей.

00:03:06.100 --> 00:03:07.760
Потоки агентів побудовані навколо них,

00:03:07.900 --> 00:03:09.120
залучаючи людей лише тоді,

00:03:09.240 --> 00:03:11.220
коли потрібна інтерпретація, а не повторення.

00:03:11.440 --> 00:03:13.480
Щойно ви побачите, як працює ця архітектура,

00:03:13.600 --> 00:03:15.560
традиційні погодження здаватимуться примітивними,

00:03:15.680 --> 00:03:17.000
як підрахунок чеків при свічках.

00:03:17.200 --> 00:03:20.080
Ставки прості, відповідність, послідовність і масштаб.

00:03:20.260 --> 00:03:23.060
Сучасні операції тонуть без автоматизованої перевірки,

00:03:23.140 --> 00:03:25.860
а логіка за допомогою ЩІ тепер є основою надійності.

00:03:26.020 --> 00:03:27.660
Коли ви переходите від статичних потоків

00:03:27.660 --> 00:03:29.980
до умовних потоків агентів, що підлягають аудиту,

00:03:30.080 --> 00:03:31.980
ви припиняєте керувати погодженнями реактивно

00:03:31.980 --> 00:03:34.040
і починаєте ставитися до них, як до живих систем.

00:03:34.220 --> 00:03:35.780
Різниця не лише у швидкості,

00:03:35.880 --> 00:03:37.460
це структурний здоровий глузд.

00:03:37.540 --> 00:03:40.480
Створення етапу ЩІ – навчання першого погоджувача.

00:03:40.620 --> 00:03:42.080
Тепер найцікавіша частина –

00:03:42.080 --> 00:03:44.400
навчання вашого першого цифрового бюрократа.

00:03:44.540 --> 00:03:46.220
Етап ЩІ – це логічний контролер

00:03:46.220 --> 00:03:47.660
вашого процесу погодження.

00:03:47.660 --> 00:03:49.540
Його завдання – не думати як людина,

00:03:49.640 --> 00:03:51.240
а виконувати структуровані міркування

00:03:51.240 --> 00:03:52.620
з надлюдською послідовністю.

00:03:52.800 --> 00:03:55.160
Він читає інструкції, звіряє їх із вхідними даними

00:03:55.160 --> 00:03:56.720
та видає один із двох вердиктів –

00:03:56.720 --> 00:03:57.660
схвалено чи відхилено.

00:03:57.840 --> 00:03:59.780
Жодної політики, жодних перерв на каву.

00:03:59.940 --> 00:04:02.120
Ви починаєте з визначення нового потоку агента.

00:04:02.300 --> 00:04:04.260
Під час створення етап ЩІ займає центральне місце,

00:04:04.400 --> 00:04:05.580
як чистий екзаменаційний лист,

00:04:05.700 --> 00:04:06.960
що чекає на ключ до відповідей.

00:04:07.100 --> 00:04:08.640
Тригер зазвичай надходить із Dataverse,

00:04:08.640 --> 00:04:11.660
як запис, доданий або змінений у вашій таблиці претензій чи витрат.

00:04:11.660 --> 00:04:14.100
Після створення претензії цей етап активується,

00:04:14.220 --> 00:04:16.360
оцінює дані та приймає рішення відповідно.

00:04:16.560 --> 00:04:19.440
В середині етапу найважливішим полем є інструкція –

00:04:19.440 --> 00:04:20.400
мозок операції.

00:04:20.600 --> 00:04:22.900
Тут ви описуєте логіку погодження простою,

00:04:23.040 --> 00:04:24.000
але суворою мовою.

00:04:24.180 --> 00:04:26.300
Пишіть так, ніби даєте інструкції юристу,

00:04:26.380 --> 00:04:27.620
який ніколи не імпровізує.

00:04:27.780 --> 00:04:29.400
Наприклад, схвалюйте претензію,

00:04:29.400 --> 00:04:30.700
якщо сума менша за 500,

00:04:30.860 --> 00:04:33.140
опис стосується фізичного чи психічного здоров'я,

00:04:33.220 --> 00:04:35.740
а дата покупки – протягом 30 днів після подання.

00:04:35.740 --> 00:04:38.180
Відхиляйте, якщо будь-яке правило не виконується.

00:04:38.340 --> 00:04:39.900
Ось і все – бінарна ясність.

00:04:40.100 --> 00:04:42.160
Далі визначте свої динамічні вхідні дані.

00:04:42.300 --> 00:04:43.340
Уявіть їх як змінні,

00:04:43.480 --> 00:04:45.320
що подають реальні дані у вашу логіку.

00:04:45.820 --> 00:04:47.340
Найімовірніше ви включите суму,

00:04:47.440 --> 00:04:48.580
опис і дату покупки.

00:04:48.760 --> 00:04:50.760
Кожен із них додається як контент, текст

00:04:50.760 --> 00:04:52.160
або числові вхідні дані,

00:04:52.160 --> 00:04:54.640
які ще опрацьовуватиме при прийнятті рішення.

00:04:54.780 --> 00:04:57.100
Co-Pilot Studio класифікує ці вхідні дані

00:04:57.100 --> 00:04:59.780
за типом «текст», «число» або «зображення документа».

00:04:59.780 --> 00:05:01.640
Вибирайте правильно, бо змішування типів,

00:05:01.760 --> 00:05:03.720
наприклад, «число», «збережене як текст»,

00:05:03.720 --> 00:05:05.600
збиває з пантелику і людей, і машини.

00:05:05.740 --> 00:05:08.520
Під кожним вхідним даним надайте зразок даних для тестування.

00:05:08.700 --> 00:05:11.220
Це слугує каркасом, поки ви калібруєте логіку.

00:05:11.420 --> 00:05:14.440
Наприклад, введіть приклад заявки «Килимок для йоги»,

00:05:14.440 --> 00:05:17.180
«Сума 300», «Дата покупки» 22 серпня.

00:05:17.180 --> 00:05:18.720
Коли ви натискаєте «Тест»,

00:05:18.720 --> 00:05:21.080
Co-Pilot Studio запускає модель міркувань,

00:05:21.220 --> 00:05:24.620
що базується на GPT і видає рішення разом із поясненням.

00:05:24.620 --> 00:05:27.620
Якщо результат відповідає вашим очікуванням, чудово.

00:05:27.760 --> 00:05:30.460
Якщо ні, вашим інструкціям бракує визначеності.

00:05:30.600 --> 00:05:32.980
І саме тут більшість новачків припускаються помилок.

00:05:33.160 --> 00:05:34.780
Широкі або двозначні формулювання,

00:05:34.960 --> 00:05:37.980
як от «розумні витрати» чи «недавня покупка» – це отрута для щі.

00:05:38.120 --> 00:05:39.980
Система не вміє читати корпоративний настрій,

00:05:40.140 --> 00:05:41.620
їй потрібні математичні визначення.

00:05:41.620 --> 00:05:43.500
Тож невпинно вдосконалюйте свої інструкції,

00:05:43.620 --> 00:05:45.340
доки результати тестів не стануть узгодженими.

00:05:45.460 --> 00:05:46.940
Кожного разу, коли ви перефразовуєте,

00:05:46.940 --> 00:05:49.120
ви налаштовуєте механізм оцінки на відтворюваність.

00:05:49.240 --> 00:05:50.340
Вам потрібна закономірність,

00:05:50.440 --> 00:05:53.100
за якої ідентичні вхідні дані щоразу дають ідентичний результат.

00:05:53.300 --> 00:05:55.180
Машинна логіка, а не офісні плітки.

00:05:55.420 --> 00:05:57.560
Як тільки ваш запит почне давати надійні рішення

00:05:57.560 --> 00:05:58.900
для різних тестових випадків,

00:05:58.980 --> 00:06:00.780
ви фактично навчите свійші схвалювач.

00:06:00.900 --> 00:06:02.560
Тепер вставте реальні динамічні дані,

00:06:02.860 --> 00:06:04.200
використовуючи токени з Dataverse,

00:06:04.340 --> 00:06:06.760
деталі суми заявки, дату покупки або подання.

00:06:06.940 --> 00:06:08.620
Вони замінять ваші тестові значення

00:06:08.620 --> 00:06:09.880
під час реальної роботи.

00:06:09.880 --> 00:06:12.700
З цього моменту ЩІ оцінює кожну заявку в контексті,

00:06:12.800 --> 00:06:14.180
видаючи вердикт про схвалення,

00:06:14.280 --> 00:06:15.620
щойно з'являються нові дані.

00:06:15.740 --> 00:06:17.160
Перш ніж святкувати перемогу,

00:06:17.240 --> 00:06:18.520
проведіть ітераційні тести.

00:06:18.760 --> 00:06:20.660
Змініть суму на 600, чи буде відхилення.

00:06:20.840 --> 00:06:22.020
Змініть дату на 3 місяці тому,

00:06:22.140 --> 00:06:23.500
чи позначить він її як недійсно.

00:06:23.660 --> 00:06:25.740
Додайте абсурдну заявку, наприклад, купівлю iPad,

00:06:25.880 --> 00:06:27.000
чи виявить він невідповідність.

00:06:27.120 --> 00:06:28.360
Кожен прохід має демонструвати

00:06:28.360 --> 00:06:30.180
послідовну причинову наслідкову залежність.

00:06:30.180 --> 00:06:31.560
Якщо відповіді коливаються,

00:06:31.560 --> 00:06:33.120
проблема в чіткості вашого запиту,

00:06:33.260 --> 00:06:33.920
а не в моделі ЩІ.

00:06:34.060 --> 00:06:35.800
Коли з'являться стабільні закономірності,

00:06:35.940 --> 00:06:37.180
встановіть правила іменування

00:06:37.180 --> 00:06:38.480
для ваших змінних контенту.

00:06:38.600 --> 00:06:39.940
Префікси, як от «стрит»,

00:06:39.940 --> 00:06:41.360
для суми заявки або «нам»,

00:06:41.360 --> 00:06:43.180
для дати покупки, для числових значень.

00:06:43.340 --> 00:06:45.460
Ця невелика дисципліна запобігає хаосу,

00:06:45.520 --> 00:06:47.080
коли ви пізніше розширите логіку

00:06:47.080 --> 00:06:48.020
до багато рівневої.

00:06:48.180 --> 00:06:50.300
На цьому етапі ваш автоматизований схвалювач

00:06:50.300 --> 00:06:51.820
може приймати незалежні рішення

00:06:51.820 --> 00:06:53.400
згідно з політикою без нагляду.

00:06:53.400 --> 00:06:55.380
Але автоматизація – це не диктатура,

00:06:55.480 --> 00:06:56.200
це делегування.

00:06:56.360 --> 00:06:58.320
Машина відповідає за швидкість і точність,

00:06:58.400 --> 00:06:59.080
а не за судження.

00:06:59.260 --> 00:07:00.400
Для прикордонних сценаріїв

00:07:00.400 --> 00:07:01.760
вам знадобиться ескалація –

00:07:01.760 --> 00:07:03.240
участь людини, яка перегляне те,

00:07:03.380 --> 00:07:05.180
що ЩІ відхиляє або вважає сумнівним.

00:07:05.360 --> 00:07:07.160
Саме тут вступає в дію наступний етап,

00:07:07.240 --> 00:07:09.040
і саме так повноваження розподіляються

00:07:09.040 --> 00:07:10.120
між Кремнієм і людьми.

00:07:10.280 --> 00:07:11.640
Додавання людського нагляду,

00:07:11.800 --> 00:07:13.600
багаторівневої та умовної логіки.

00:07:13.780 --> 00:07:15.580
Коли ваш ЩІ впевнено оцінює заявки,

00:07:15.580 --> 00:07:16.560
ви можете додати те,

00:07:16.720 --> 00:07:18.420
що в бюрократії іронічно називають

00:07:18.420 --> 00:07:19.280
людським дотиком.

00:07:19.440 --> 00:07:21.100
У Co-Pilot Studio це означає

00:07:21.100 --> 00:07:22.180
етап ручної обробки,

00:07:22.300 --> 00:07:23.040
контрольну точку,

00:07:23.120 --> 00:07:25.040
де реальна людина може проявити розсудливість.

00:07:25.200 --> 00:07:27.280
Вважайте це своїм запобіжним клапаном.

00:07:27.460 --> 00:07:29.620
Усе передбачуване проходить автоматично.

00:07:29.860 --> 00:07:31.160
Будь-яка нюансна ситуація

00:07:31.160 --> 00:07:32.480
потрапляє на стіл керівника.

00:07:32.700 --> 00:07:34.200
Ви починаєте в конструкторі погоджень,

00:07:34.300 --> 00:07:36.300
додаючи ручний етап відразу після етапу ЩІ.

00:07:36.440 --> 00:07:37.560
Це створює другий бар'єр

00:07:37.560 --> 00:07:38.760
у вашому потоці агента.

00:07:38.760 --> 00:07:40.540
Передача керування є умовною.

00:07:40.700 --> 00:07:42.200
Лише якщо вердикт ЩІ схвалено,

00:07:42.300 --> 00:07:44.200
ми переходимо до етапу за участю людини.

00:07:44.340 --> 00:07:45.620
Якщо ЩІ каже «відхилено»,

00:07:45.620 --> 00:07:46.940
процес на цьому завершується.

00:07:47.100 --> 00:07:47.960
Навіщо гаяти час,

00:07:48.080 --> 00:07:49.480
просячи менеджерів підтверджувати те,

00:07:49.600 --> 00:07:50.640
що політика вже відхилила?

00:07:50.800 --> 00:07:52.260
Ефективність – це вибіркова увага,

00:07:52.360 --> 00:07:53.660
замаскована під автоматизацію.

00:07:53.840 --> 00:07:55.520
Давайте розглянемо приклад сценарію.

00:07:55.640 --> 00:07:57.040
Припустимо, працівник подає заявку

00:07:57.040 --> 00:07:58.820
на відшкодування витрат за абонемент у спортзал.

00:07:58.960 --> 00:07:59.800
ЩІ схвалює її,

00:07:59.800 --> 00:08:01.920
оскільки всі критерії відповідають політиці.

00:08:02.040 --> 00:08:04.640
Тепер це рішення ініціює ручний етап рівня менеджера

00:08:04.640 --> 00:08:06.560
під назвою «Погодження керівником».

00:08:06.560 --> 00:08:07.880
Налаштовуючи цей етап,

00:08:08.020 --> 00:08:09.760
ви задаєте заголовок, наприклад,

00:08:09.940 --> 00:08:12.200
«Запит на погодження витрат від заявника».

00:08:12.200 --> 00:08:14.900
Ці змінні динамічно підтягують дані з Dataverse.

00:08:15.060 --> 00:08:16.300
У полі «Призначено для»

00:08:16.300 --> 00:08:17.140
ви визначаєте,

00:08:17.280 --> 00:08:18.340
хто отримує завдання,

00:08:18.500 --> 00:08:20.060
зазвичай це керівник заявника.

00:08:20.260 --> 00:08:21.600
Щоб автоматизувати цей маршрут,

00:08:21.740 --> 00:08:23.600
Co-Pilot Studio дозволяє інтегрувати

00:08:23.600 --> 00:08:25.540
конектор Office 365 Users.

00:08:25.540 --> 00:08:27.280
Спочатку отримайте запис користувача,

00:08:27.340 --> 00:08:28.160
який створив заявку,

00:08:28.240 --> 00:08:30.420
використовуючи дію отримання рядка за ідентифікатором

00:08:30.420 --> 00:08:31.740
у таблиці користувачів Dataverse.

00:08:31.860 --> 00:08:33.280
Це витягує інформацію про того,

00:08:33.440 --> 00:08:34.100
хто подав запит.

00:08:34.260 --> 00:08:35.280
Далі дія отримання менеджера

00:08:35.280 --> 00:08:36.600
знаходить керівника цього користувача

00:08:36.600 --> 00:08:38.100
за його основною електронною адресою.

00:08:38.260 --> 00:08:39.660
Передайте цей результат назад у ваш ручний етап,

00:08:39.740 --> 00:08:40.360
як змінну, наприклад,

00:08:40.440 --> 00:08:41.520
STR нижні підкреслення менеджа,

00:08:41.580 --> 00:08:42.340
нижні підкреслення e-mail.

00:08:42.480 --> 00:08:44.040
Результат – жодного жорсткого кодування,

00:08:44.040 --> 00:08:45.260
жодних застарілих ієрархій.

00:08:45.400 --> 00:08:46.340
Менеджери змінюються,

00:08:46.480 --> 00:08:47.880
і ієрархія оновлюється сама.

00:08:48.020 --> 00:08:49.620
Тепер переходимо до умовного розгалуження

00:08:49.620 --> 00:08:50.900
справжньої причини існування

00:08:50.900 --> 00:08:51.900
багаторівневих погоджень.

00:08:52.040 --> 00:08:53.140
Ви можете впровадити логіку

00:08:53.140 --> 00:08:54.800
безпосередньо всередину потоку агента.

00:08:54.980 --> 00:08:56.160
Якщо сума заявки дорівнює

00:08:56.160 --> 00:08:57.120
або перевищує 150,

00:08:57.480 --> 00:08:58.440
додайте додатковий етап

00:08:58.440 --> 00:08:59.720
для погодження адміністратором.

00:08:59.860 --> 00:09:01.560
В іншому випадку завершить процес.

00:09:01.720 --> 00:09:03.620
Це перетворює простудвоєтапну процедуру

00:09:03.620 --> 00:09:04.980
на багаторівневе дерево рішень,

00:09:04.980 --> 00:09:06.440
що адаптується до контексту.

00:09:06.620 --> 00:09:07.680
Заявки на невеликі суми

00:09:07.680 --> 00:09:08.800
розглядає одна людина.

00:09:09.000 --> 00:09:09.840
Заявки на великі суми

00:09:09.840 --> 00:09:10.840
або ризиковані операції

00:09:10.840 --> 00:09:12.160
передаються на додатковий контроль.

00:09:12.260 --> 00:09:13.460
У конструкторів ставте дію

00:09:13.460 --> 00:09:14.940
умови перед завершенням потоку.

00:09:15.060 --> 00:09:16.440
Зверніться до своєї числової змінної,

00:09:16.520 --> 00:09:17.700
наприклад, нам нижні підкреслення

00:09:17.700 --> 00:09:18.920
клейм нижні підкреслення АМАМ.

00:09:19.100 --> 00:09:20.000
Оберіть оператор

00:09:20.000 --> 00:09:21.080
більше або дорівнює

00:09:21.080 --> 00:09:22.140
та встановіть поріг,

00:09:22.260 --> 00:09:23.180
наприклад, 150.

00:09:23.660 --> 00:09:24.640
У гілці, якщо істина,

00:09:24.720 --> 00:09:25.840
додайте ще один ручний етап

00:09:25.840 --> 00:09:27.560
під назвою «Погодження адміністратором».

00:09:27.560 --> 00:09:29.000
Призначте його на фіксованого відповідального,

00:09:29.140 --> 00:09:29.960
наприклад, адміністратора

00:09:29.960 --> 00:09:30.740
з питань комплеєнсу.

00:09:30.860 --> 00:09:31.840
У гілці, якщо хиба,

00:09:31.960 --> 00:09:33.380
завершіть процес як «Схвалено».

00:09:33.380 --> 00:09:34.480
Ефект – робочий процес

00:09:34.480 --> 00:09:36.260
поводиться як раціональна організація,

00:09:36.380 --> 00:09:37.900
а не як універсальне вузьке місце.

00:09:38.060 --> 00:09:38.940
Тут доречно додати

00:09:38.940 --> 00:09:40.200
трохи практичного гумору.

00:09:40.320 --> 00:09:41.420
Так, делегування все одно

00:09:41.420 --> 00:09:42.260
потребує довіри,

00:09:42.340 --> 00:09:43.180
а не сліпої надії.

00:09:43.360 --> 00:09:44.900
Не призначайте широкі ролі безпеки,

00:09:44.980 --> 00:09:46.320
які можуть схвалювати все підряд.

00:09:46.320 --> 00:09:48.100
Обмежте дозволи для відповідних користувачів

00:09:48.100 --> 00:09:49.740
або груп за допомогою керування доступом

00:09:49.740 --> 00:09:50.820
на основі ролей у Dataverse.

00:09:50.960 --> 00:09:52.620
Інакше ви автоматизуєте хаос.

00:09:52.740 --> 00:09:54.040
Тестування структури показує,

00:09:54.160 --> 00:09:55.960
наскільки злагоджено працює кожен елемент.

00:09:56.100 --> 00:09:57.940
Якщо запит на суму до 150 доларів

00:09:57.940 --> 00:09:58.880
проходить перевірку ЩІ,

00:09:58.980 --> 00:10:00.860
процес завершується після схвалення менеджером.

00:10:01.040 --> 00:10:02.700
Якщо сума перевищує 150 доларів,

00:10:02.820 --> 00:10:04.200
система автоматично ставить його в чергу

00:10:04.200 --> 00:10:06.100
на перевірку адміністратором перед фіналізацією.

00:10:06.240 --> 00:10:07.600
Кожен шлях залишає контрольний слід,

00:10:07.600 --> 00:10:08.600
журнал обґрунтуванші,

00:10:08.680 --> 00:10:09.680
схвалення з мітками часу

00:10:09.680 --> 00:10:10.680
та зафіксовані результати,

00:10:10.780 --> 00:10:11.800
що зберігаються в Dataverse.

00:10:11.940 --> 00:10:13.300
Ніхто не зможе потім заявити,

00:10:13.440 --> 00:10:14.240
я цього не бачив.

00:10:14.380 --> 00:10:15.880
База даних свідчить про інше.

00:10:16.040 --> 00:10:16.920
Під час вдосконалення

00:10:16.920 --> 00:10:18.740
дотримуйтеся чітких правил іменування.

00:10:18.920 --> 00:10:20.280
Додавайте до етапів з людським втручанням

00:10:20.280 --> 00:10:20.980
зрозумілі префікси,

00:10:21.060 --> 00:10:22.100
наприклад, схвалено менеджером

00:10:22.100 --> 00:10:23.260
чи схвалено адміністратором,

00:10:23.260 --> 00:10:24.520
щоб візуально відстежувати гілки.

00:10:24.660 --> 00:10:26.060
Блок-схема має читатися як логіка,

00:10:26.060 --> 00:10:27.480
а не як загадковий витвір мистецтва.

00:10:27.640 --> 00:10:28.560
Отримавши бажаний результат,

00:10:28.700 --> 00:10:29.260
опублікуйте його

00:10:29.260 --> 00:10:30.540
та протистуйте на реальних сценаріях.

00:10:30.700 --> 00:10:31.480
Спостерігайте за тим,

00:10:31.580 --> 00:10:32.620
як розгортається ланцюжок.

00:10:32.780 --> 00:10:34.100
Ще оцінює все миттєво.

00:10:34.280 --> 00:10:35.820
Менеджер отримує цільове завдання

00:10:35.820 --> 00:10:36.420
на схвалення.

00:10:36.660 --> 00:10:37.840
Адміністратор долучається

00:10:37.840 --> 00:10:39.140
лише за необхідних умов.

00:10:39.300 --> 00:10:40.220
Результат виглядає

00:10:40.220 --> 00:10:42.060
не як автоматизація всього підряд,

00:10:42.060 --> 00:10:43.500
а як прозора ієрархія,

00:10:43.700 --> 00:10:45.100
що самостійно функціонує.

00:10:45.260 --> 00:10:46.860
Ця багаторівнева організація

00:10:46.860 --> 00:10:48.000
відкриває нову сферу

00:10:48.000 --> 00:10:49.300
перевірку документів.

00:10:49.480 --> 00:10:50.600
Адже іноді поля форми

00:10:50.600 --> 00:10:51.540
можуть помилятися,

00:10:51.660 --> 00:10:52.260
а чек – ні.

00:10:52.440 --> 00:10:53.200
Наступний крок –

00:10:53.200 --> 00:10:54.060
змусити ще й вивчати

00:10:54.060 --> 00:10:55.360
фізичні докази ще до того,

00:10:55.520 --> 00:10:57.080
як вони потраплять у вашу скриньку.

00:10:57.300 --> 00:10:59.040
Саме тут з'являється перевірка чеків,

00:10:59.160 --> 00:11:00.380
що перетворює бюрократію

00:11:00.380 --> 00:11:01.220
на точну науку.

00:11:01.420 --> 00:11:02.540
Динамічні вхідні дані

00:11:02.540 --> 00:11:03.760
та перевірка документів.

00:11:03.880 --> 00:11:04.960
Поговорімо про чеки –

00:11:04.960 --> 00:11:06.160
маленькі зім'яті папірці,

00:11:06.280 --> 00:11:07.260
які таємничим чином

00:11:07.260 --> 00:11:08.820
стають критично важливим доказом,

00:11:08.820 --> 00:11:10.200
коли хтось хоче відшкодування.

00:11:10.340 --> 00:11:11.860
У процесі ручного схвалення

00:11:11.860 --> 00:11:13.520
люди перевіряють їх візуально.

00:11:13.700 --> 00:11:15.140
Так, це виглядає як килимок

00:11:15.140 --> 00:11:16.360
для йоги, а не як яхта.

00:11:16.500 --> 00:11:17.700
В автоматизованому процесі

00:11:17.700 --> 00:11:18.820
ми змушуємо щі виконувати

00:11:18.820 --> 00:11:19.660
ту саму перевірку

00:11:19.660 --> 00:11:21.020
без утоми відприйняття рішень.

00:11:21.180 --> 00:11:22.960
У потоках агентів Co-Pilot Studio

00:11:22.960 --> 00:11:24.000
перевірка документів

00:11:24.000 --> 00:11:25.300
реалізується через динамічне

00:11:25.300 --> 00:11:26.180
введення контенту,

00:11:26.240 --> 00:11:26.980
зокрема, можливість

00:11:26.980 --> 00:11:27.980
передавати зображення

00:11:27.980 --> 00:11:29.640
або файл у вашу логіку схвалення.

00:11:29.820 --> 00:11:31.480
Це додає вашому щі-погоджувачу

00:11:31.480 --> 00:11:32.520
третє чуття – зір.

00:11:32.660 --> 00:11:33.960
Замість того, щоб покладатися

00:11:33.960 --> 00:11:34.940
лише на текстові поля,

00:11:35.080 --> 00:11:36.080
модель зчитує документ

00:11:36.080 --> 00:11:37.240
і порівнює написане з тим,

00:11:37.380 --> 00:11:38.260
що було завантажено.

00:11:38.400 --> 00:11:39.280
Ось структура.

00:11:39.460 --> 00:11:40.480
На етапі роботи ЩІ

00:11:40.480 --> 00:11:41.500
ви додаєте новий тип

00:11:41.500 --> 00:11:42.280
вхідних даних,

00:11:42.400 --> 00:11:43.700
зображення або документ.

00:11:43.880 --> 00:11:44.840
Назвіть його чітко,

00:11:44.960 --> 00:11:46.200
наприклад, файл чека.

00:11:46.440 --> 00:11:47.660
Завантажте зразок чека

00:11:47.660 --> 00:11:48.360
для тестування.

00:11:48.540 --> 00:11:49.780
Це не вплине на реальну роботу,

00:11:49.920 --> 00:11:51.180
лише налаштує макет логіки.

00:11:51.320 --> 00:11:52.900
Тепер налаштуйте свій запит інструкцій,

00:11:52.900 --> 00:11:54.860
щоб включити перехресну перевірку документів.

00:11:54.980 --> 00:11:56.820
Ви розширюєте свою попередню логіку.

00:11:57.020 --> 00:11:57.740
Схвалюйте запит,

00:11:57.820 --> 00:11:59.080
якщо виконуються всі умови.

00:11:59.200 --> 00:11:59.640
Сума 500,

00:11:59.820 --> 00:12:00.800
деталі запиту стосуються

00:12:00.800 --> 00:12:02.200
фізичного чи психічного здоров'я,

00:12:02.340 --> 00:12:03.760
дата покупки в межах 30 днів,

00:12:03.860 --> 00:12:05.340
а чек відповідає заявленому товару,

00:12:05.440 --> 00:12:05.960
сумій даті.

00:12:06.080 --> 00:12:06.980
Ця четверта умова

00:12:06.980 --> 00:12:08.420
перетворює вашій погоджувач

00:12:08.420 --> 00:12:09.640
із контролера політики

00:12:09.640 --> 00:12:11.380
на судово-бухгалтерського експерта.

00:12:11.520 --> 00:12:12.580
Коли тест запущено,

00:12:12.720 --> 00:12:14.640
модель видобуває текст із документа

00:12:14.640 --> 00:12:16.200
і перевіляє його відповідність

00:12:16.200 --> 00:12:17.640
вашим структурованим даним.

00:12:17.820 --> 00:12:18.740
Якщо в чеку вказано

00:12:18.740 --> 00:12:19.740
килимок для фітнесу

00:12:19.740 --> 00:12:20.640
300 доларів США

00:12:20.640 --> 00:12:21.760
22 серпня,

00:12:21.880 --> 00:12:23.180
а у вашій заявці щось інше,

00:12:23.300 --> 00:12:24.780
вердикт змінюється на відхилено.

00:12:24.940 --> 00:12:26.000
Тепер для впровадження

00:12:26.000 --> 00:12:27.140
перед початком погодження

00:12:27.140 --> 00:12:28.680
вам потрібно отримати цей документ.

00:12:28.840 --> 00:12:29.620
Використайте дію

00:12:29.620 --> 00:12:31.200
«Завантажити файл або зображення»

00:12:31.200 --> 00:12:31.720
з Dataverse.

00:12:31.900 --> 00:12:32.860
Вкажіть ту саму таблицю,

00:12:32.940 --> 00:12:34.040
де зберігається запис заявки,

00:12:34.140 --> 00:12:34.500
імовірно,

00:12:34.600 --> 00:12:35.340
«Claims» заявки.

00:12:35.480 --> 00:12:36.420
У полі «File column»

00:12:36.420 --> 00:12:37.060
стовпець файлу

00:12:37.060 --> 00:12:38.040
оберіть поле вкладення,

00:12:38.200 --> 00:12:39.060
яке часто називається,

00:12:39.160 --> 00:12:39.520
наприклад,

00:12:39.620 --> 00:12:40.200
«Расіт-Чек».

00:12:40.200 --> 00:12:41.480
Потім динамічно вкажіть

00:12:41.480 --> 00:12:42.680
ID-рядка з тригера

00:12:42.680 --> 00:12:44.740
унікальний ідентифікатор заявки.

00:12:44.920 --> 00:12:46.340
Ця дія повертає метадані

00:12:46.340 --> 00:12:47.160
та вміст файлу,

00:12:47.300 --> 00:12:48.780
але тут є прихована пастка.

00:12:48.980 --> 00:12:49.920
Вихідні дані вмісту

00:12:49.920 --> 00:12:51.580
потребують невеликого коригування,

00:12:51.740 --> 00:12:53.360
щоб ще правильно їх інтерпретував.

00:12:53.480 --> 00:12:55.080
Під час відображення вмісту файлу

00:12:55.080 --> 00:12:56.180
у полі «Введення чека»

00:12:56.180 --> 00:12:57.500
відкрите редактор виразів

00:12:57.500 --> 00:12:58.780
і додайте «Content»

00:12:58.780 --> 00:13:00.140
до посилання на «Body».

00:13:00.140 --> 00:13:01.300
Це останнє налаштування

00:13:01.300 --> 00:13:03.080
передає безпосередньо байти файлу,

00:13:03.220 --> 00:13:04.360
а не обгортку метаданих.

00:13:04.460 --> 00:13:05.340
Пропустіть цей крок

00:13:05.340 --> 00:13:06.480
і ваш чі з ентузіазмом

00:13:06.480 --> 00:13:07.840
схвалюватиме порожні чеки.

00:13:08.020 --> 00:13:08.980
Давайте розглянемо

00:13:08.980 --> 00:13:09.820
синхронізацію

00:13:09.820 --> 00:13:11.640
Ахілесову п'яту документообігу.

00:13:11.820 --> 00:13:12.860
Більшість таблиц Dataverse

00:13:12.860 --> 00:13:13.900
не зберігають вкладення

00:13:13.900 --> 00:13:15.700
до моменту першого збереження запису,

00:13:15.780 --> 00:13:16.680
тому якщо ваш потік

00:13:16.680 --> 00:13:18.160
спрацьовує при створенні запису,

00:13:18.260 --> 00:13:19.520
він може запуститися до того,

00:13:19.520 --> 00:13:20.540
як файл з'явиться.

00:13:20.540 --> 00:13:22.460
Симптом «Потік» видає помилку

00:13:22.460 --> 00:13:23.920
або вміст чека порожній.

00:13:24.080 --> 00:13:25.260
Рішення елегантне.

00:13:25.460 --> 00:13:26.480
Змініть умову тригера

00:13:26.480 --> 00:13:27.720
на під час зміни елемента,

00:13:27.920 --> 00:13:28.840
але обмежте його так,

00:13:28.980 --> 00:13:29.800
щоб він спрацював

00:13:29.800 --> 00:13:31.200
лише при зміні стовпця чека.

00:13:31.400 --> 00:13:32.400
Таким чином, у момент,

00:13:32.620 --> 00:13:33.600
коли хтось завантажує

00:13:33.600 --> 00:13:34.660
або замінює файл,

00:13:34.740 --> 00:13:35.840
починається перевірка.

00:13:36.060 --> 00:13:36.880
Щоб налаштувати це,

00:13:37.000 --> 00:13:38.100
відкрійте параметри тригера,

00:13:38.240 --> 00:13:39.480
виберіть «Modified columns»,

00:13:39.480 --> 00:13:40.220
змінені стовпці

00:13:40.220 --> 00:13:41.380
і вставте логічну назву

00:13:41.380 --> 00:13:42.260
вашого стовпця чека,

00:13:42.260 --> 00:13:43.140
яку можна отримати

00:13:43.140 --> 00:13:44.300
в деталях стовпця Dataverse

00:13:44.300 --> 00:13:45.800
у розділі додаткових інструментів.

00:13:45.900 --> 00:13:47.600
Після налаштування опублікуйте.

00:13:47.720 --> 00:13:49.040
Тепер ваша автоматизація

00:13:49.040 --> 00:13:50.020
поводиться коректно.

00:13:50.220 --> 00:13:51.680
Вона чекає, поки з'явиться те,

00:13:51.800 --> 00:13:52.800
що потрібно перевірити.

00:13:52.960 --> 00:13:54.800
Коли заявка оновлюється новим чеком,

00:13:54.880 --> 00:13:56.100
потік перезапускається.

00:13:56.300 --> 00:13:57.500
Він завантажує файл,

00:13:57.580 --> 00:13:59.340
пропускає його через етап «Щ»

00:13:59.340 --> 00:14:00.560
та порівнює всі дані.

00:14:00.960 --> 00:14:02.460
Якщо виявлено розбіжності

00:14:02.460 --> 00:14:03.620
невідповідність суми,

00:14:03.740 --> 00:14:04.500
застаріла дата,

00:14:04.660 --> 00:14:06.100
суперечливі описи «Щ»

00:14:06.100 --> 00:14:07.860
відхиляє заявку з поясненням.

00:14:07.980 --> 00:14:09.320
Журнал обґрунтування може виглядати так.

00:14:09.420 --> 00:14:10.760
Заявлена сума 305 доларів США

00:14:10.760 --> 00:14:11.840
відрізняється від загальної суми

00:14:11.840 --> 00:14:12.980
в документі 300 доларів США.

00:14:13.140 --> 00:14:14.660
Це відповідність вимогам без скар.

00:14:14.880 --> 00:14:16.100
Який практичний результат?

00:14:16.320 --> 00:14:17.320
Кожна подана заявка

00:14:17.320 --> 00:14:18.480
проходить самоперевірку.

00:14:18.740 --> 00:14:20.040
Співробітники більше не зможуть

00:14:20.040 --> 00:14:21.220
подавати сумнівні чеки

00:14:21.220 --> 00:14:22.300
або розмиті описи.

00:14:22.480 --> 00:14:23.540
Щи виносять рішення,

00:14:23.700 --> 00:14:24.980
Dataverse надає докази

00:14:24.980 --> 00:14:27.100
і жоден із них не бере перерви на каву.

00:14:27.240 --> 00:14:29.080
Отже, ні, перевірка документів

00:14:29.080 --> 00:14:30.040
це не надмірність.

00:14:30.040 --> 00:14:31.080
Це імунна пам'ять

00:14:31.080 --> 00:14:32.580
для ваших робочих процесів.

00:14:32.740 --> 00:14:33.720
Відхилення виявляються

00:14:33.720 --> 00:14:34.660
на молекулярному рівні,

00:14:34.780 --> 00:14:35.520
на рівні символів,

00:14:35.620 --> 00:14:36.920
надрукованих на реальних чеках,

00:14:36.980 --> 00:14:37.760
а людина-рецензент

00:14:37.760 --> 00:14:38.600
підвищується з ролі

00:14:38.600 --> 00:14:39.560
ручного перевір'яльника

00:14:39.560 --> 00:14:40.600
до обробника винятків.

00:14:40.720 --> 00:14:41.280
Вітаємо!

00:14:41.460 --> 00:14:43.400
Ви автоматизували саму чесність.

00:14:43.620 --> 00:14:44.720
Розробка надійності,

00:14:44.800 --> 00:14:47.160
тестування, версіоновання та публікація.

00:14:47.360 --> 00:14:48.460
Будь-яка автоматизація

00:14:48.460 --> 00:14:49.500
виглядає бездоганною,

00:14:49.580 --> 00:14:50.660
доки не почнеться робота.

00:14:50.820 --> 00:14:51.720
Ось чому надійність

00:14:51.720 --> 00:14:53.080
це не етап, а дисципліна.

00:14:53.220 --> 00:14:53.980
Co-Pilot Studio

00:14:53.980 --> 00:14:54.840
робить цю дисципліну

00:14:54.840 --> 00:14:55.580
дивовижно простою

00:14:55.580 --> 00:14:56.700
завдяки керуванню версіями,

00:14:56.840 --> 00:14:57.820
тестуванню та публікації,

00:14:57.960 --> 00:14:58.860
вбудованим безпосередньо

00:14:58.860 --> 00:14:59.660
в потоки агентів.

00:14:59.780 --> 00:15:01.460
Почніть з ітеративного тестування.

00:15:01.640 --> 00:15:02.680
Кожен потік погодження

00:15:02.680 --> 00:15:04.200
– це мініатюрна екосистема.

00:15:04.340 --> 00:15:05.300
Навіть одна випадкова

00:15:05.300 --> 00:15:05.940
назва змінної

00:15:05.940 --> 00:15:07.020
може спричинити хаос.

00:15:07.140 --> 00:15:08.400
Тому ставтеся до тестування

00:15:08.400 --> 00:15:09.780
як до наукового процесу.

00:15:09.940 --> 00:15:10.680
Ізолюйте зміни,

00:15:10.820 --> 00:15:11.620
застосуйте дані,

00:15:11.620 --> 00:15:13.100
спостерігайте за результатом.

00:15:13.220 --> 00:15:14.140
У редакторі потоків

00:15:14.140 --> 00:15:15.080
Co-Pilot Studio

00:15:15.080 --> 00:15:16.180
дозволяє моделювати

00:15:16.180 --> 00:15:16.840
зразки даних

00:15:16.840 --> 00:15:18.420
без розгортання робочих тригерів.

00:15:18.620 --> 00:15:19.980
Використовуйте різні сценарії

00:15:19.980 --> 00:15:20.900
за велику суму,

00:15:21.020 --> 00:15:21.740
за старілу дату,

00:15:21.880 --> 00:15:22.800
нерелевантні назви

00:15:22.800 --> 00:15:23.660
і переконайтеся,

00:15:23.800 --> 00:15:25.280
що кожен дає правильний висновок.

00:15:25.440 --> 00:15:26.180
Потім перейдіть

00:15:26.180 --> 00:15:27.260
до правил іменування.

00:15:27.460 --> 00:15:27.820
Нудно?

00:15:28.080 --> 00:15:28.640
Абсолютно?

00:15:28.820 --> 00:15:29.240
Важливо?

00:15:29.480 --> 00:15:30.500
Більше, ніж повітря.

00:15:30.640 --> 00:15:31.560
Систематично додавайте

00:15:31.560 --> 00:15:32.740
префікси до кожної змінної.

00:15:32.880 --> 00:15:33.680
STR для рядків,

00:15:33.780 --> 00:15:34.560
NUM для чисел,

00:15:34.560 --> 00:15:35.480
DOS для файлів.

00:15:35.580 --> 00:15:37.180
Так само чітко позначайте дії.

00:15:37.440 --> 00:15:38.480
Завантаження файлу чека,

00:15:38.600 --> 00:15:39.640
перевірка згоди менеджера,

00:15:39.760 --> 00:15:40.940
оновлення статусу заявки.

00:15:41.060 --> 00:15:41.920
Бо через три місяці,

00:15:42.040 --> 00:15:42.680
коли хтось запитає,

00:15:42.820 --> 00:15:43.980
чому DIA-7 зламалася,

00:15:44.100 --> 00:15:44.560
ви оціните,

00:15:44.740 --> 00:15:45.540
що підказки кращі

00:15:45.540 --> 00:15:46.680
за археологічні розкопки.

00:15:46.820 --> 00:15:48.300
Коли індивідуальні тести пройдено,

00:15:48.420 --> 00:15:49.360
переходьте до перевірки

00:15:49.360 --> 00:15:50.380
граничних сценаріїв.

00:15:50.500 --> 00:15:52.700
Уявіть, що ви некомпетентний користувач.

00:15:52.860 --> 00:15:53.840
Не завантажте чек,

00:15:54.000 --> 00:15:55.440
змініть дату на наступний рік,

00:15:55.580 --> 00:15:57.020
введіть 500 замість 500.

00:15:57.020 --> 00:15:57.900
Переконайтеся,

00:15:58.060 --> 00:15:58.960
що щі пояснює

00:15:58.960 --> 00:15:59.600
і відхиляє,

00:15:59.740 --> 00:16:00.440
не вилітаючи.

00:16:00.600 --> 00:16:01.960
Це не гіпотетичні помилки,

00:16:02.100 --> 00:16:03.420
це репетиції реальності.

00:16:03.580 --> 00:16:04.760
Чим більше потенційних збоїв

00:16:04.760 --> 00:16:05.820
ви усунете заздалегідь,

00:16:05.880 --> 00:16:07.060
тим менше повідомлень у Teams

00:16:07.060 --> 00:16:07.720
о другій ночі

00:16:07.720 --> 00:16:08.640
ви отримаєте про те,

00:16:08.740 --> 00:16:09.920
що потік знову зупинився.

00:16:10.220 --> 00:16:11.880
Публікація впроваджує керування.

00:16:12.080 --> 00:16:13.780
Щоразу, коли ви зберігаєте важливу зміну,

00:16:13.900 --> 00:16:14.640
Coopilot Studio

00:16:14.640 --> 00:16:16.240
автоматично створює нову версію.

00:16:16.400 --> 00:16:17.320
Ви можете відкотитися

00:16:17.320 --> 00:16:18.060
в будь-який момент.

00:16:18.060 --> 00:16:19.640
Жодного страху перезапису.

00:16:19.800 --> 00:16:20.440
Використовуйте це,

00:16:20.560 --> 00:16:22.280
щоб тримати пісочниці експериментальної логіки

00:16:22.280 --> 00:16:23.380
окремо від робочої версії.

00:16:23.540 --> 00:16:24.340
Один потік на звіть,

00:16:24.460 --> 00:16:25.380
погодження заявок ДЕВ,

00:16:25.500 --> 00:16:26.880
інший – погодження заявок прод.

00:16:26.980 --> 00:16:27.740
Тестуйте в ДЕВ,

00:16:27.840 --> 00:16:29.640
публікуйте лише після стабілізації.

00:16:29.840 --> 00:16:31.360
Пам'ятайте, надійність –

00:16:31.360 --> 00:16:32.460
це не лише правильність,

00:16:32.560 --> 00:16:33.880
це контроль під час змін.

00:16:34.400 --> 00:16:35.340
Після публікації

00:16:35.340 --> 00:16:37.340
використовуйте журнали активності.

00:16:37.520 --> 00:16:38.400
Вони не для краси,

00:16:38.500 --> 00:16:40.020
це юридично значущі записи

00:16:40.020 --> 00:16:41.320
взаємодії щі та людини.

00:16:41.320 --> 00:16:42.740
Мітки часу – особи того,

00:16:42.960 --> 00:16:44.360
хто погоджує резюме логіки.

00:16:44.480 --> 00:16:46.240
Періодично переглядайте ці журнали.

00:16:46.580 --> 00:16:48.140
Закономірності стануть очевидними.

00:16:48.300 --> 00:16:50.020
Які правила викликають найбільше відмов,

00:16:50.120 --> 00:16:51.720
які менеджери скасували рішення щі,

00:16:51.840 --> 00:16:53.700
як часто спрацьовують кроки комплеєнсу.

00:16:53.840 --> 00:16:55.100
Ці інсайти вдосконалюють

00:16:55.100 --> 00:16:56.500
як політику, так і дизайн.

00:16:56.680 --> 00:16:57.960
Ще одна тонка порада –

00:16:57.960 --> 00:16:59.580
автоматизуйте оновлення статусу

00:16:59.580 --> 00:17:00.540
в записах Dataverse

00:17:00.540 --> 00:17:01.860
у кінці кожної гілки.

00:17:02.080 --> 00:17:03.200
Дія «Оновлення рядка»

00:17:03.200 --> 00:17:04.580
має встановлювати чітке поле,

00:17:04.580 --> 00:17:05.940
наприклад, статус заявки

00:17:05.940 --> 00:17:07.340
«Схвалено» або «Відхилено».

00:17:07.340 --> 00:17:09.220
Цей видимий фінал підкріплює довіру.

00:17:09.400 --> 00:17:10.580
Користувачі бачать рішення

00:17:10.580 --> 00:17:12.080
безпосередньо у своїх таблицях.

00:17:12.240 --> 00:17:13.740
Жодних окремих таблиць для відстеження,

00:17:13.880 --> 00:17:14.940
жодних примарних погоджень.

00:17:15.080 --> 00:17:16.400
Коли ваша система пройде всі тести,

00:17:16.520 --> 00:17:17.660
натискайте «Опублікувати»

00:17:17.660 --> 00:17:18.720
зі спокійною впевненістю.

00:17:18.860 --> 00:17:20.620
На відміну від попередніх поколінь потоків

00:17:20.620 --> 00:17:21.360
Pava Automate,

00:17:21.460 --> 00:17:22.640
потоки агентів зберігають

00:17:22.640 --> 00:17:23.600
контекстні метадані,

00:17:23.600 --> 00:17:24.920
схему прийняття рішенщі,

00:17:25.060 --> 00:17:26.320
динамічні прив'язки в місто

00:17:26.320 --> 00:17:27.060
та теги-версій.

00:17:27.220 --> 00:17:29.060
Результатом є не просто запущений процес,

00:17:29.160 --> 00:17:30.280
а відтворюваний артефакт,

00:17:30.340 --> 00:17:32.180
автоматизація, що піддається аудиту.

00:17:32.360 --> 00:17:33.840
Остання перевірка на надійність –

00:17:33.840 --> 00:17:34.580
це ментальний тест.

00:17:34.720 --> 00:17:36.360
Опирайтеся надмірному ускладненню.

00:17:36.500 --> 00:17:37.640
Іноді збій у роботі потоку

00:17:37.640 --> 00:17:38.860
виявляє надто складні правила,

00:17:38.980 --> 00:17:39.840
а не технічні помилки.

00:17:40.040 --> 00:17:41.800
Спрощуйте логіку, де це можливо.

00:17:42.000 --> 00:17:42.760
Менше етапів,

00:17:42.900 --> 00:17:43.960
чіткіші інструкції,

00:17:44.160 --> 00:17:45.260
мінімум двозначності.

00:17:45.740 --> 00:17:47.300
Автоматизація – це не випадковість,

00:17:47.420 --> 00:17:49.060
це відмова від зайвого мудрування.

00:17:49.240 --> 00:17:50.460
Коли ви завершуєте цей етап,

00:17:50.580 --> 00:17:51.600
ваша система затвердження

00:17:51.600 --> 00:17:53.100
досягає операційної зрілості,

00:17:53.200 --> 00:17:54.400
протестованої, версійної,

00:17:54.540 --> 00:17:55.900
готової до відкату та перевірки.

00:17:56.060 --> 00:17:57.220
Кожен результат від рішення

00:17:57.220 --> 00:17:58.640
щі до схвалення адміністратором

00:17:58.640 --> 00:17:59.720
залишає цифровий слід,

00:17:59.840 --> 00:18:01.180
що витримує будь-яку перевірку.

00:18:01.340 --> 00:18:02.560
Це і є надійність у цифрах

00:18:02.560 --> 00:18:03.860
не відчуття, не везіння,

00:18:03.960 --> 00:18:05.060
а структуроване мислення,

00:18:05.220 --> 00:18:06.420
зафіксоване інструментами,

00:18:06.520 --> 00:18:07.220
які ви створили,

00:18:07.220 --> 00:18:08.760
щоб працювати, поки ви спите.

00:18:08.940 --> 00:18:10.440
Результати та реальна вигода.

00:18:10.680 --> 00:18:12.040
Що станеться, якщо довірити

00:18:12.040 --> 00:18:13.240
бюрократію математиці?

00:18:13.480 --> 00:18:15.000
Затвердження більше не чекають.

00:18:15.260 --> 00:18:16.580
Багатоетапний агентський потік

00:18:16.580 --> 00:18:17.820
на базі ще скорочує час

00:18:17.820 --> 00:18:19.000
обробки з днів до хвилин,

00:18:19.100 --> 00:18:20.320
бо рішення більше не залежить

00:18:20.320 --> 00:18:21.660
від вільного місця в календарі.

00:18:21.780 --> 00:18:23.240
Кожна заявка, що відповідає

00:18:23.240 --> 00:18:24.300
об'єктивній політиці,

00:18:24.420 --> 00:18:25.400
схвалюється миттєво.

00:18:25.540 --> 00:18:26.720
Кожен нестандартний випадок

00:18:26.720 --> 00:18:28.420
акуратно потрапляє в чергу менеджера

00:18:28.420 --> 00:18:29.580
вже з доданим контекстом.

00:18:29.580 --> 00:18:31.120
Люди ухвалюють ціннісні рішення,

00:18:31.240 --> 00:18:33.020
а не займаються канцелярськими підтвердженнями.

00:18:33.140 --> 00:18:34.480
Вплив спочатку проявляється

00:18:34.480 --> 00:18:35.520
як стиснення часу.

00:18:35.660 --> 00:18:37.260
Відшкодування, що раніше потребувало

00:18:37.260 --> 00:18:38.780
чотирьох листів і двох нагадувань,

00:18:38.900 --> 00:18:40.060
тепер вирішується до обіду.

00:18:40.220 --> 00:18:42.460
Підрозділи отримують коротші цикли обробки,

00:18:42.600 --> 00:18:44.820
менше простоїв і досконало задокументовані

00:18:44.820 --> 00:18:45.880
сліди обґрунтувань.

00:18:46.020 --> 00:18:48.760
Механізм затвердження перестає бути перешкодою.

00:18:48.980 --> 00:18:50.480
Він стає інфраструктурою.

00:18:50.720 --> 00:18:52.560
Далі йде зменшення кількості помилок.

00:18:59.580 --> 00:19:24.880
Він вбудований у систему.

00:19:25.060 --> 00:19:26.420
Журнали Dataverse показують,

00:19:26.420 --> 00:19:27.800
хто затвердив, коли і чому.

00:19:27.800 --> 00:19:29.700
Ця прозорість відбиває бажання шукати

00:19:29.700 --> 00:19:31.580
обхідні шляхи, оскільки кожне рішення

00:19:31.580 --> 00:19:32.920
тепер зафіксоване назавжди.

00:19:33.080 --> 00:19:34.940
І філософський робочий процес змінюється

00:19:34.940 --> 00:19:36.620
від людина-перша за допомогою ЩІ

00:19:36.620 --> 00:19:38.380
до ЩІ-першій з виправленням людини.

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

00:19:40.960 --> 00:19:42.360
ЩІ займається дотриманням правил,

00:19:42.480 --> 00:19:43.620
люди винесенням суджень.

00:19:43.760 --> 00:19:45.660
Такий гібрид створює справедливіші, швидші

00:19:45.660 --> 00:19:47.180
та, зрештою, надійніші системи.

00:19:47.320 --> 00:19:49.260
Уявіть, як ви пояснюєте це аудитору.

00:19:49.260 --> 00:19:50.720
Посмішка, яка після цього з'явиться,

00:19:50.880 --> 00:19:52.340
варта однієї лише автоматизації.

00:19:52.500 --> 00:19:53.260
Отже, це все.

00:19:53.440 --> 00:19:55.120
Microsoft Coopilot Studio – це не просто

00:19:55.120 --> 00:19:56.540
черговий інструмент автоматизації.

00:19:56.700 --> 00:19:58.700
Це місце, де нерішучість вашої організації

00:19:58.700 --> 00:19:59.840
нарешті йде у відставку.

00:20:00.020 --> 00:20:01.380
Ви створюєте механізм затвердження,

00:20:01.540 --> 00:20:02.660
який здатен мислити умовами,

00:20:02.760 --> 00:20:04.200
відповідально делегувати повноваження,

00:20:04.300 --> 00:20:05.340
звіряти чеки з реальністю

00:20:05.340 --> 00:20:06.620
та документувати кожен свій крок.

00:20:06.780 --> 00:20:07.980
Це не просто робочий процес,

00:20:08.100 --> 00:20:09.000
це модель управління.

00:20:09.140 --> 00:20:10.920
Якщо ви нічого іншого не запам'ятаєте,

00:20:10.920 --> 00:20:11.800
запам'ятайте це.

00:20:11.960 --> 00:20:13.820
Щі має робити рішення перед бачуваними,

00:20:13.920 --> 00:20:15.000
а людей – винятковими.

00:20:15.160 --> 00:20:17.560
Припиніть спрямовувати все через людей зазвичкою.

00:20:17.740 --> 00:20:19.200
Дозвольте логіці обробляти рутину,

00:20:19.320 --> 00:20:21.440
щоб менеджери могли вирішувати виняткові ситуації.

00:20:21.640 --> 00:20:23.040
Якщо цей огляд врятував вас

00:20:23.040 --> 00:20:24.600
від чергового тижня очікування

00:20:24.600 --> 00:20:26.380
на розгляд керівника – підпишіться.

00:20:26.560 --> 00:20:27.820
Наступний урок заглиблюється

00:20:27.820 --> 00:20:30.040
в розширену автоматизацію Coopilot Studio,

00:20:30.260 --> 00:20:31.680
де ці агентні потоки з'єднуються

00:20:31.680 --> 00:20:32.920
з аналітикою Pava Platform

00:20:32.920 --> 00:20:34.180
та адаптивними політиками.

00:20:34.180 --> 00:20:35.600
Закріпіть свій шлях до оновлень,

00:20:35.700 --> 00:20:37.160
підпишіться, увімкніть сповіщення

00:20:37.160 --> 00:20:39.160
і нехай нові епізоди з'являються автоматично.

00:20:39.380 --> 00:20:40.380
Жодних ручних перевірок,

00:20:40.500 --> 00:20:41.640
жодних пропущених релізів,

00:20:41.780 --> 00:20:43.460
лише постійне постачання корисних знань.

00:20:43.660 --> 00:20:44.020
Дійте!