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:02
  Хтось у відпустці, хтось інший не бачив листа,
• 0:04
  і до того моменту, коли рішення нарешті приходить,
• 0:07
  контекст запиту вже втрачає актуальність.
• 0:09
  Корпоративне чистилище, де прогрес гальмують люди,
• 0:11
  які запевняють, що вони дуже зайняті.
• 0:13
  Тепер уявіть систему, яка просто не чекає.
• 0:15
  Робочий процес, що рухається вперед, як тільки виконано умови.
• 0:18
  Зустрічайте Agent Flows у Microsoft Co-Pilot Studio,
• 0:20
  вбивцю бюрократії, замаскованого під автоматизацію.
• 0:22
  Тут ще стає вашим першим погоджувачем.
• 0:25
  Він зчитує дані, оцінює їх відповідно до політики
• 0:27
  та дає обґрунтоване схвалення чи відмову раніше,
• 0:30
  ніж будь-то встигне кліпнути.
• 0:31
  Лише складні випадки потрапляють до скриньки менеджера,
• 0:34
  що означає швидкість без втрати контролю.
• 0:36
  І на відміну від застарілих ланцюжків погодження,
• 0:38
  що руйнуються від складності умов,
• 0:40
  ці системи на базі ще й масштабуються, розгалужуються,
• 0:43
  перевіряють та аудитують самі себе.
• 0:45
  У цьому посібнику я покажу,
• 0:46
  як побудувати багаторівневу систему умовних погоджень,
• 0:49
  яка ухвалює рішення швидше,
• 0:50
  ніж ваші колеги знайдуть кнопку «Відповісти всім».
• 0:52
  Ви дізнаєтеся, як налаштувати етап
• 0:54
  ще з власною логікою погодження,
• 0:56
  додати цільові перевірки людьми,
• 0:58
  розробити динамічні умови для інтелектуальної маршрутизації
• 1:01
  та інтегрувати перевірку документів
• 1:03
  для відповідності вимогам.
• 1:04
  Наприкінці ви отримаєте автоматизований процес,
• 1:06
  який знає, коли думати як машина,
• 1:08
  а коли довіритися людському судженню.
• 1:09
  Досить стояти в черзі.
• 1:11
  Почніть дозволяти логіці вести процес.
• 1:13
  Проблема традиційних погоджень.
• 1:15
  Традиційні ланцюжки погоджень –
• 1:16
  це трагічний ремікс однієї і тієї ж неефективності.
• 1:19
  Хтось надсилає форму, листи літають,
• 1:21
  електронні таблиці втрачають синхронізацію
• 1:23
  і через пересилки ніхто не пам'ятає,
• 1:24
  яка версія була фінальною.
• 1:26
  Кожен учасник лише додає затримку, а не цінність.
• 1:28
  Процес не керує роботою, він створює затримки.
• 1:31
  Типові потоки погодження Pava Otamate
• 1:33
  намагаються це вирішити,
• 1:35
  але зупиняються, як тільки з'являються нюанси.
• 1:37
  Один шлях погодження працює добре,
• 1:39
  якщо потрібне лише одне, так чи ні.
• 1:41
  Як тільки додаються рівні управління,
• 1:43
  ліміти витрат або спеціальні правила,
• 1:44
  конструкція починає розпадатися.
• 1:46
  Ви в результаті вкладаєте умови,
• 1:48
  як у матришку – незграбно, крихко
• 1:49
  і неможливо виправити через півроку.
• 1:51
  Один зламаний конектор,
• 1:53
  і вся система мовчки виходить з ладу.
• 1:55
  Люди стають вузьким місцем
• 1:56
  або, якщо бути відвертим, вузлами затримки.
• 1:58
  Кожне повідомлення, яке вони отримують,
• 2:00
  стає ще одним асинхронним циклом очікування.
• 2:02
  Використовувати електронну пошту для погоджень
• 2:04
  – це як поштові голуби у світі оптоволокна.
• 2:06
  Технічно це працює, але так не має бути.
• 2:08
  Зустрічайте Microsoft Coopilot Studio.
• 2:10
  Це не просто інкрементальне оновлення Pava Otamate.
• 2:13
  Вона впроваджує агентні потоки
• 2:15
  системи погодження на базі ЩІ
• 2:17
  повністю інтегровані з джерелами даних,
• 2:19
  ролями та логічними структурами вашої організації.
• 2:22
  Вона поєднує детерміноване дотримання політик
• 2:24
  з адаптивним прийняттям рішень.
• 2:26
  Геніальність полягає в тому,
• 2:27
  як вона розділяє етапи.
• 2:29
  Автоматизація, де потрібна швидкість,
• 2:31
  і люди, де ще потрібна перевірка.
• 2:32
  Уявіть це як переосмислену ієрархію.
• 2:35
  Етап ЩІ оцінює фіксовані правила,
• 2:37
  ліміти сум, типи категорій,
• 2:38
  діапазони дат з клінічною ефективністю.
• 2:41
  Потім, якщо рішення неоднозначне,
• 2:43
  процес переходить до людини,
• 2:44
  не змушуючи кожен дрібний випадок ставати в чергу.
• 2:47
  Це саме по собі усуває експоненціальну затримку.
• 2:50
  Замість того, щоб 10 людей
• 2:51
  виконували послідовні перевірки,
• 2:52
  ще миттєво обробляє 80%,
• 2:54
  спрямовуючи лише винятки.
• 2:55
  І так, Co-Pilot Studio відстежує все через основу Dataverse,
• 2:59
  створюючи перевірювані журнали без потреби вашої команди
• 3:02
  ритися в архівах пошти.
• 3:03
  Попередні робочі процеси були створені для людей.
• 3:06
  Потоки агентів побудовані навколо них,
• 3:07
  залучаючи людей лише тоді,
• 3:09
  коли потрібна інтерпретація, а не повторення.
• 3:11
  Щойно ви побачите, як працює ця архітектура,
• 3:13
  традиційні погодження здаватимуться примітивними,
• 3:15
  як підрахунок чеків при свічках.
• 3:17
  Ставки прості, відповідність, послідовність і масштаб.
• 3:20
  Сучасні операції тонуть без автоматизованої перевірки,
• 3:23
  а логіка за допомогою ЩІ тепер є основою надійності.
• 3:26
  Коли ви переходите від статичних потоків
• 3:27
  до умовних потоків агентів, що підлягають аудиту,
• 3:30
  ви припиняєте керувати погодженнями реактивно
• 3:31
  і починаєте ставитися до них, як до живих систем.
• 3:34
  Різниця не лише у швидкості,
• 3:35
  це структурний здоровий глузд.
• 3:37
  Створення етапу ЩІ – навчання першого погоджувача.
• 3:40
  Тепер найцікавіша частина –
• 3:42
  навчання вашого першого цифрового бюрократа.
• 3:44
  Етап ЩІ – це логічний контролер
• 3:46
  вашого процесу погодження.
• 3:47
  Його завдання – не думати як людина,
• 3:49
  а виконувати структуровані міркування
• 3:51
  з надлюдською послідовністю.
• 3:52
  Він читає інструкції, звіряє їх із вхідними даними
• 3:55
  та видає один із двох вердиктів –
• 3:56
  схвалено чи відхилено.
• 3:57
  Жодної політики, жодних перерв на каву.
• 3:59
  Ви починаєте з визначення нового потоку агента.
• 4:02
  Під час створення етап ЩІ займає центральне місце,
• 4:04
  як чистий екзаменаційний лист,
• 4:05
  що чекає на ключ до відповідей.
• 4:07
  Тригер зазвичай надходить із Dataverse,
• 4:08
  як запис, доданий або змінений у вашій таблиці претензій чи витрат.
• 4:11
  Після створення претензії цей етап активується,
• 4:14
  оцінює дані та приймає рішення відповідно.
• 4:16
  В середині етапу найважливішим полем є інструкція –
• 4:19
  мозок операції.
• 4:20
  Тут ви описуєте логіку погодження простою,
• 4:23
  але суворою мовою.
• 4:24
  Пишіть так, ніби даєте інструкції юристу,
• 4:26
  який ніколи не імпровізує.
• 4:27
  Наприклад, схвалюйте претензію,
• 4:29
  якщо сума менша за 500,
• 4:30
  опис стосується фізичного чи психічного здоров'я,
• 4:33
  а дата покупки – протягом 30 днів після подання.
• 4:35
  Відхиляйте, якщо будь-яке правило не виконується.
• 4:38
  Ось і все – бінарна ясність.
• 4:40
  Далі визначте свої динамічні вхідні дані.
• 4:42
  Уявіть їх як змінні,
• 4:43
  що подають реальні дані у вашу логіку.
• 4:45
  Найімовірніше ви включите суму,
• 4:47
  опис і дату покупки.
• 4:48
  Кожен із них додається як контент, текст
• 4:50
  або числові вхідні дані,
• 4:52
  які ще опрацьовуватиме при прийнятті рішення.
• 4:54
  Co-Pilot Studio класифікує ці вхідні дані
• 4:57
  за типом «текст», «число» або «зображення документа».
• 4:59
  Вибирайте правильно, бо змішування типів,
• 5:01
  наприклад, «число», «збережене як текст»,
• 5:03
  збиває з пантелику і людей, і машини.
• 5:05
  Під кожним вхідним даним надайте зразок даних для тестування.
• 5:08
  Це слугує каркасом, поки ви калібруєте логіку.
• 5:11
  Наприклад, введіть приклад заявки «Килимок для йоги»,
• 5:14
  «Сума 300», «Дата покупки» 22 серпня.
• 5:17
  Коли ви натискаєте «Тест»,
• 5:18
  Co-Pilot Studio запускає модель міркувань,
• 5:21
  що базується на GPT і видає рішення разом із поясненням.
• 5:24
  Якщо результат відповідає вашим очікуванням, чудово.
• 5:27
  Якщо ні, вашим інструкціям бракує визначеності.
• 5:30
  І саме тут більшість новачків припускаються помилок.
• 5:33
  Широкі або двозначні формулювання,
• 5:34
  як от «розумні витрати» чи «недавня покупка» – це отрута для щі.
• 5:38
  Система не вміє читати корпоративний настрій,
• 5:40
  їй потрібні математичні визначення.
• 5:41
  Тож невпинно вдосконалюйте свої інструкції,
• 5:43
  доки результати тестів не стануть узгодженими.
• 5:45
  Кожного разу, коли ви перефразовуєте,
• 5:46
  ви налаштовуєте механізм оцінки на відтворюваність.
• 5:49
  Вам потрібна закономірність,
• 5:50
  за якої ідентичні вхідні дані щоразу дають ідентичний результат.
• 5:53
  Машинна логіка, а не офісні плітки.
• 5:55
  Як тільки ваш запит почне давати надійні рішення
• 5:57
  для різних тестових випадків,
• 5:58
  ви фактично навчите свійші схвалювач.
• 6:00
  Тепер вставте реальні динамічні дані,
• 6:02
  використовуючи токени з Dataverse,
• 6:04
  деталі суми заявки, дату покупки або подання.
• 6:06
  Вони замінять ваші тестові значення
• 6:08
  під час реальної роботи.
• 6:09
  З цього моменту ЩІ оцінює кожну заявку в контексті,
• 6:12
  видаючи вердикт про схвалення,
• 6:14
  щойно з'являються нові дані.
• 6:15
  Перш ніж святкувати перемогу,
• 6:17
  проведіть ітераційні тести.
• 6:18
  Змініть суму на 600, чи буде відхилення.
• 6:20
  Змініть дату на 3 місяці тому,
• 6:22
  чи позначить він її як недійсно.
• 6:23
  Додайте абсурдну заявку, наприклад, купівлю iPad,
• 6:25
  чи виявить він невідповідність.
• 6:27
  Кожен прохід має демонструвати
• 6:28
  послідовну причинову наслідкову залежність.
• 6:30
  Якщо відповіді коливаються,
• 6:31
  проблема в чіткості вашого запиту,
• 6:33
  а не в моделі ЩІ.
• 6:34
  Коли з'являться стабільні закономірності,
• 6:35
  встановіть правила іменування
• 6:37
  для ваших змінних контенту.
• 6:38
  Префікси, як от «стрит»,
• 6:39
  для суми заявки або «нам»,
• 6:41
  для дати покупки, для числових значень.
• 6:43
  Ця невелика дисципліна запобігає хаосу,
• 6:45
  коли ви пізніше розширите логіку
• 6:47
  до багато рівневої.
• 6:48
  На цьому етапі ваш автоматизований схвалювач
• 6:50
  може приймати незалежні рішення
• 6:51
  згідно з політикою без нагляду.
• 6:53
  Але автоматизація – це не диктатура,
• 6:55
  це делегування.
• 6:56
  Машина відповідає за швидкість і точність,
• 6:58
  а не за судження.
• 6:59
  Для прикордонних сценаріїв
• 7:00
  вам знадобиться ескалація –
• 7:01
  участь людини, яка перегляне те,
• 7:03
  що ЩІ відхиляє або вважає сумнівним.
• 7:05
  Саме тут вступає в дію наступний етап,
• 7:07
  і саме так повноваження розподіляються
• 7:09
  між Кремнієм і людьми.
• 7:10
  Додавання людського нагляду,
• 7:11
  багаторівневої та умовної логіки.
• 7:13
  Коли ваш ЩІ впевнено оцінює заявки,
• 7:15
  ви можете додати те,
• 7:16
  що в бюрократії іронічно називають
• 7:18
  людським дотиком.
• 7:19
  У Co-Pilot Studio це означає
• 7:21
  етап ручної обробки,
• 7:22
  контрольну точку,
• 7:23
  де реальна людина може проявити розсудливість.
• 7:25
  Вважайте це своїм запобіжним клапаном.
• 7:27
  Усе передбачуване проходить автоматично.
• 7:29
  Будь-яка нюансна ситуація
• 7:31
  потрапляє на стіл керівника.
• 7:32
  Ви починаєте в конструкторі погоджень,
• 7:34
  додаючи ручний етап відразу після етапу ЩІ.
• 7:36
  Це створює другий бар'єр
• 7:37
  у вашому потоці агента.
• 7:38
  Передача керування є умовною.
• 7:40
  Лише якщо вердикт ЩІ схвалено,
• 7:42
  ми переходимо до етапу за участю людини.
• 7:44
  Якщо ЩІ каже «відхилено»,
• 7:45
  процес на цьому завершується.
• 7:47
  Навіщо гаяти час,
• 7:48
  просячи менеджерів підтверджувати те,
• 7:49
  що політика вже відхилила?
• 7:50
  Ефективність – це вибіркова увага,
• 7:52
  замаскована під автоматизацію.
• 7:53
  Давайте розглянемо приклад сценарію.
• 7:55
  Припустимо, працівник подає заявку
• 7:57
  на відшкодування витрат за абонемент у спортзал.
• 7:58
  ЩІ схвалює її,
• 7:59
  оскільки всі критерії відповідають політиці.
• 8:02
  Тепер це рішення ініціює ручний етап рівня менеджера
• 8:04
  під назвою «Погодження керівником».
• 8:06
  Налаштовуючи цей етап,
• 8:08
  ви задаєте заголовок, наприклад,
• 8:09
  «Запит на погодження витрат від заявника».
• 8:12
  Ці змінні динамічно підтягують дані з Dataverse.
• 8:15
  У полі «Призначено для»
• 8:16
  ви визначаєте,
• 8:17
  хто отримує завдання,
• 8:18
  зазвичай це керівник заявника.
• 8:20
  Щоб автоматизувати цей маршрут,
• 8:21
  Co-Pilot Studio дозволяє інтегрувати
• 8:23
  конектор Office 365 Users.
• 8:25
  Спочатку отримайте запис користувача,
• 8:27
  який створив заявку,
• 8:28
  використовуючи дію отримання рядка за ідентифікатором
• 8:30
  у таблиці користувачів Dataverse.
• 8:31
  Це витягує інформацію про того,
• 8:33
  хто подав запит.
• 8:34
  Далі дія отримання менеджера
• 8:35
  знаходить керівника цього користувача
• 8:36
  за його основною електронною адресою.
• 8:38
  Передайте цей результат назад у ваш ручний етап,
• 8:39
  як змінну, наприклад,
• 8:40
  STR нижні підкреслення менеджа,
• 8:41
  нижні підкреслення e-mail.
• 8:42
  Результат – жодного жорсткого кодування,
• 8:44
  жодних застарілих ієрархій.
• 8:45
  Менеджери змінюються,
• 8:46
  і ієрархія оновлюється сама.
• 8:48
  Тепер переходимо до умовного розгалуження
• 8:49
  справжньої причини існування
• 8:50
  багаторівневих погоджень.
• 8:52
  Ви можете впровадити логіку
• 8:53
  безпосередньо всередину потоку агента.
• 8:54
  Якщо сума заявки дорівнює
• 8:56
  або перевищує 150,
• 8:57
  додайте додатковий етап
• 8:58
  для погодження адміністратором.
• 8:59
  В іншому випадку завершить процес.
• 9:01
  Це перетворює простудвоєтапну процедуру
• 9:03
  на багаторівневе дерево рішень,
• 9:04
  що адаптується до контексту.
• 9:06
  Заявки на невеликі суми
• 9:07
  розглядає одна людина.
• 9:09
  Заявки на великі суми
• 9:09
  або ризиковані операції
• 9:10
  передаються на додатковий контроль.
• 9:12
  У конструкторів ставте дію
• 9:13
  умови перед завершенням потоку.
• 9:15
  Зверніться до своєї числової змінної,
• 9:16
  наприклад, нам нижні підкреслення
• 9:17
  клейм нижні підкреслення АМАМ.
• 9:19
  Оберіть оператор
• 9:20
  більше або дорівнює
• 9:21
  та встановіть поріг,
• 9:22
  наприклад, 150.
• 9:23
  У гілці, якщо істина,
• 9:24
  додайте ще один ручний етап
• 9:25
  під назвою «Погодження адміністратором».
• 9:27
  Призначте його на фіксованого відповідального,
• 9:29
  наприклад, адміністратора
• 9:29
  з питань комплеєнсу.
• 9:30
  У гілці, якщо хиба,
• 9:31
  завершіть процес як «Схвалено».
• 9:33
  Ефект – робочий процес
• 9:34
  поводиться як раціональна організація,
• 9:36
  а не як універсальне вузьке місце.
• 9:38
  Тут доречно додати
• 9:38
  трохи практичного гумору.
• 9:40
  Так, делегування все одно
• 9:41
  потребує довіри,
• 9:42
  а не сліпої надії.
• 9:43
  Не призначайте широкі ролі безпеки,
• 9:44
  які можуть схвалювати все підряд.
• 9:46
  Обмежте дозволи для відповідних користувачів
• 9:48
  або груп за допомогою керування доступом
• 9:49
  на основі ролей у Dataverse.
• 9:50
  Інакше ви автоматизуєте хаос.
• 9:52
  Тестування структури показує,
• 9:54
  наскільки злагоджено працює кожен елемент.
• 9:56
  Якщо запит на суму до 150 доларів
• 9:57
  проходить перевірку ЩІ,
• 9:58
  процес завершується після схвалення менеджером.
• 10:01
  Якщо сума перевищує 150 доларів,
• 10:02
  система автоматично ставить його в чергу
• 10:04
  на перевірку адміністратором перед фіналізацією.
• 10:06
  Кожен шлях залишає контрольний слід,
• 10:07
  журнал обґрунтуванші,
• 10:08
  схвалення з мітками часу
• 10:09
  та зафіксовані результати,
• 10:10
  що зберігаються в Dataverse.
• 10:11
  Ніхто не зможе потім заявити,
• 10:13
  я цього не бачив.
• 10:14
  База даних свідчить про інше.
• 10:16
  Під час вдосконалення
• 10:16
  дотримуйтеся чітких правил іменування.
• 10:18
  Додавайте до етапів з людським втручанням
• 10:20
  зрозумілі префікси,
• 10:21
  наприклад, схвалено менеджером
• 10:22
  чи схвалено адміністратором,
• 10:23
  щоб візуально відстежувати гілки.
• 10:24
  Блок-схема має читатися як логіка,
• 10:26
  а не як загадковий витвір мистецтва.
• 10:27
  Отримавши бажаний результат,
• 10:28
  опублікуйте його
• 10:29
  та протистуйте на реальних сценаріях.
• 10:30
  Спостерігайте за тим,
• 10:31
  як розгортається ланцюжок.
• 10:32
  Ще оцінює все миттєво.
• 10:34
  Менеджер отримує цільове завдання
• 10:35
  на схвалення.
• 10:36
  Адміністратор долучається
• 10:37
  лише за необхідних умов.
• 10:39
  Результат виглядає
• 10:40
  не як автоматизація всього підряд,
• 10:42
  а як прозора ієрархія,
• 10:43
  що самостійно функціонує.
• 10:45
  Ця багаторівнева організація
• 10:46
  відкриває нову сферу
• 10:48
  перевірку документів.
• 10:49
  Адже іноді поля форми
• 10:50
  можуть помилятися,
• 10:51
  а чек – ні.
• 10:52
  Наступний крок –
• 10:53
  змусити ще й вивчати
• 10:54
  фізичні докази ще до того,
• 10:55
  як вони потраплять у вашу скриньку.
• 10:57
  Саме тут з'являється перевірка чеків,
• 10:59
  що перетворює бюрократію
• 11:00
  на точну науку.
• 11:01
  Динамічні вхідні дані
• 11:02
  та перевірка документів.
• 11:03
  Поговорімо про чеки –
• 11:04
  маленькі зім'яті папірці,
• 11:06
  які таємничим чином
• 11:07
  стають критично важливим доказом,
• 11:08
  коли хтось хоче відшкодування.
• 11:10
  У процесі ручного схвалення
• 11:11
  люди перевіряють їх візуально.
• 11:13
  Так, це виглядає як килимок
• 11:15
  для йоги, а не як яхта.
• 11:16
  В автоматизованому процесі
• 11:17
  ми змушуємо щі виконувати
• 11:18
  ту саму перевірку
• 11:19
  без утоми відприйняття рішень.
• 11:21
  У потоках агентів Co-Pilot Studio
• 11:22
  перевірка документів
• 11:24
  реалізується через динамічне
• 11:25
  введення контенту,
• 11:26
  зокрема, можливість
• 11:26
  передавати зображення
• 11:27
  або файл у вашу логіку схвалення.
• 11:29
  Це додає вашому щі-погоджувачу
• 11:31
  третє чуття – зір.
• 11:32
  Замість того, щоб покладатися
• 11:33
  лише на текстові поля,
• 11:35
  модель зчитує документ
• 11:36
  і порівнює написане з тим,
• 11:37
  що було завантажено.
• 11:38
  Ось структура.
• 11:39
  На етапі роботи ЩІ
• 11:40
  ви додаєте новий тип
• 11:41
  вхідних даних,
• 11:42
  зображення або документ.
• 11:43
  Назвіть його чітко,
• 11:44
  наприклад, файл чека.
• 11:46
  Завантажте зразок чека
• 11:47
  для тестування.
• 11:48
  Це не вплине на реальну роботу,
• 11:49
  лише налаштує макет логіки.
• 11:51
  Тепер налаштуйте свій запит інструкцій,
• 11:52
  щоб включити перехресну перевірку документів.
• 11:54
  Ви розширюєте свою попередню логіку.
• 11:57
  Схвалюйте запит,
• 11:57
  якщо виконуються всі умови.
• 11:59
  Сума 500,
• 11:59
  деталі запиту стосуються
• 12:00
  фізичного чи психічного здоров'я,
• 12:02
  дата покупки в межах 30 днів,
• 12:03
  а чек відповідає заявленому товару,
• 12:05
  сумій даті.
• 12:06
  Ця четверта умова
• 12:06
  перетворює вашій погоджувач
• 12:08
  із контролера політики
• 12:09
  на судово-бухгалтерського експерта.
• 12:11
  Коли тест запущено,
• 12:12
  модель видобуває текст із документа
• 12:14
  і перевіляє його відповідність
• 12:16
  вашим структурованим даним.
• 12:17
  Якщо в чеку вказано
• 12:18
  килимок для фітнесу
• 12:19
  300 доларів США
• 12:20
  22 серпня,
• 12:21
  а у вашій заявці щось інше,
• 12:23
  вердикт змінюється на відхилено.
• 12:24
  Тепер для впровадження
• 12:26
  перед початком погодження
• 12:27
  вам потрібно отримати цей документ.
• 12:28
  Використайте дію
• 12:29
  «Завантажити файл або зображення»
• 12:31
  з Dataverse.
• 12:31
  Вкажіть ту саму таблицю,
• 12:32
  де зберігається запис заявки,
• 12:34
  імовірно,
• 12:34
  «Claims» заявки.
• 12:35
  У полі «File column»
• 12:36
  стовпець файлу
• 12:37
  оберіть поле вкладення,
• 12:38
  яке часто називається,
• 12:39
  наприклад,
• 12:39
  «Расіт-Чек».
• 12:40
  Потім динамічно вкажіть
• 12:41
  ID-рядка з тригера
• 12:42
  унікальний ідентифікатор заявки.
• 12:44
  Ця дія повертає метадані
• 12:46
  та вміст файлу,
• 12:47
  але тут є прихована пастка.
• 12:48
  Вихідні дані вмісту
• 12:49
  потребують невеликого коригування,
• 12:51
  щоб ще правильно їх інтерпретував.
• 12:53
  Під час відображення вмісту файлу
• 12:55
  у полі «Введення чека»
• 12:56
  відкрите редактор виразів
• 12:57
  і додайте «Content»
• 12:58
  до посилання на «Body».
• 13:00
  Це останнє налаштування
• 13:01
  передає безпосередньо байти файлу,
• 13:03
  а не обгортку метаданих.
• 13:04
  Пропустіть цей крок
• 13:05
  і ваш чі з ентузіазмом
• 13:06
  схвалюватиме порожні чеки.
• 13:08
  Давайте розглянемо
• 13:08
  синхронізацію
• 13:09
  Ахілесову п'яту документообігу.
• 13:11
  Більшість таблиц Dataverse
• 13:12
  не зберігають вкладення
• 13:13
  до моменту першого збереження запису,
• 13:15
  тому якщо ваш потік
• 13:16
  спрацьовує при створенні запису,
• 13:18
  він може запуститися до того,
• 13:19
  як файл з'явиться.
• 13:20
  Симптом «Потік» видає помилку
• 13:22
  або вміст чека порожній.
• 13:24
  Рішення елегантне.
• 13:25
  Змініть умову тригера
• 13:26
  на під час зміни елемента,
• 13:27
  але обмежте його так,
• 13:28
  щоб він спрацював
• 13:29
  лише при зміні стовпця чека.
• 13:31
  Таким чином, у момент,
• 13:32
  коли хтось завантажує
• 13:33
  або замінює файл,
• 13:34
  починається перевірка.
• 13:36
  Щоб налаштувати це,
• 13:37
  відкрійте параметри тригера,
• 13:38
  виберіть «Modified columns»,
• 13:39
  змінені стовпці
• 13:40
  і вставте логічну назву
• 13:41
  вашого стовпця чека,
• 13:42
  яку можна отримати
• 13:43
  в деталях стовпця Dataverse
• 13:44
  у розділі додаткових інструментів.
• 13:45
  Після налаштування опублікуйте.
• 13:47
  Тепер ваша автоматизація
• 13:49
  поводиться коректно.
• 13:50
  Вона чекає, поки з'явиться те,
• 13:51
  що потрібно перевірити.
• 13:52
  Коли заявка оновлюється новим чеком,
• 13:54
  потік перезапускається.
• 13:56
  Він завантажує файл,
• 13:57
  пропускає його через етап «Щ»
• 13:59
  та порівнює всі дані.
• 14:00
  Якщо виявлено розбіжності
• 14:02
  невідповідність суми,
• 14:03
  застаріла дата,
• 14:04
  суперечливі описи «Щ»
• 14:06
  відхиляє заявку з поясненням.
• 14:07
  Журнал обґрунтування може виглядати так.
• 14:09
  Заявлена сума 305 доларів США
• 14:10
  відрізняється від загальної суми
• 14:11
  в документі 300 доларів США.
• 14:13
  Це відповідність вимогам без скар.
• 14:14
  Який практичний результат?
• 14:16
  Кожна подана заявка
• 14:17
  проходить самоперевірку.
• 14:18
  Співробітники більше не зможуть
• 14:20
  подавати сумнівні чеки
• 14:21
  або розмиті описи.
• 14:22
  Щи виносять рішення,
• 14:23
  Dataverse надає докази
• 14:24
  і жоден із них не бере перерви на каву.
• 14:27
  Отже, ні, перевірка документів
• 14:29
  це не надмірність.
• 14:30
  Це імунна пам'ять
• 14:31
  для ваших робочих процесів.
• 14:32
  Відхилення виявляються
• 14:33
  на молекулярному рівні,
• 14:34
  на рівні символів,
• 14:35
  надрукованих на реальних чеках,
• 14:36
  а людина-рецензент
• 14:37
  підвищується з ролі
• 14:38
  ручного перевір'яльника
• 14:39
  до обробника винятків.
• 14:40
  Вітаємо!
• 14:41
  Ви автоматизували саму чесність.
• 14:43
  Розробка надійності,
• 14:44
  тестування, версіоновання та публікація.
• 14:47
  Будь-яка автоматизація
• 14:48
  виглядає бездоганною,
• 14:49
  доки не почнеться робота.
• 14:50
  Ось чому надійність
• 14:51
  це не етап, а дисципліна.
• 14:53
  Co-Pilot Studio
• 14:53
  робить цю дисципліну
• 14:54
  дивовижно простою
• 14:55
  завдяки керуванню версіями,
• 14:56
  тестуванню та публікації,
• 14:57
  вбудованим безпосередньо
• 14:58
  в потоки агентів.
• 14:59
  Почніть з ітеративного тестування.
• 15:01
  Кожен потік погодження
• 15:02
  – це мініатюрна екосистема.
• 15:04
  Навіть одна випадкова
• 15:05
  назва змінної
• 15:05
  може спричинити хаос.
• 15:07
  Тому ставтеся до тестування
• 15:08
  як до наукового процесу.
• 15:09
  Ізолюйте зміни,
• 15:10
  застосуйте дані,
• 15:11
  спостерігайте за результатом.
• 15:13
  У редакторі потоків
• 15:14
  Co-Pilot Studio
• 15:15
  дозволяє моделювати
• 15:16
  зразки даних
• 15:16
  без розгортання робочих тригерів.
• 15:18
  Використовуйте різні сценарії
• 15:19
  за велику суму,
• 15:21
  за старілу дату,
• 15:21
  нерелевантні назви
• 15:22
  і переконайтеся,
• 15:23
  що кожен дає правильний висновок.
• 15:25
  Потім перейдіть
• 15:26
  до правил іменування.
• 15:27
  Нудно?
• 15:28
  Абсолютно?
• 15:28
  Важливо?
• 15:29
  Більше, ніж повітря.
• 15:30
  Систематично додавайте
• 15:31
  префікси до кожної змінної.
• 15:32
  STR для рядків,
• 15:33
  NUM для чисел,
• 15:34
  DOS для файлів.
• 15:35
  Так само чітко позначайте дії.
• 15:37
  Завантаження файлу чека,
• 15:38
  перевірка згоди менеджера,
• 15:39
  оновлення статусу заявки.
• 15:41
  Бо через три місяці,
• 15:42
  коли хтось запитає,
• 15:42
  чому DIA-7 зламалася,
• 15:44
  ви оціните,
• 15:44
  що підказки кращі
• 15:45
  за археологічні розкопки.
• 15:46
  Коли індивідуальні тести пройдено,
• 15:48
  переходьте до перевірки
• 15:49
  граничних сценаріїв.
• 15:50
  Уявіть, що ви некомпетентний користувач.
• 15:52
  Не завантажте чек,
• 15:54
  змініть дату на наступний рік,
• 15:55
  введіть 500 замість 500.
• 15:57
  Переконайтеся,
• 15:58
  що щі пояснює
• 15:58
  і відхиляє,
• 15:59
  не вилітаючи.
• 16:00
  Це не гіпотетичні помилки,
• 16:02
  це репетиції реальності.
• 16:03
  Чим більше потенційних збоїв
• 16:04
  ви усунете заздалегідь,
• 16:05
  тим менше повідомлень у Teams
• 16:07
  о другій ночі
• 16:07
  ви отримаєте про те,
• 16:08
  що потік знову зупинився.
• 16:10
  Публікація впроваджує керування.
• 16:12
  Щоразу, коли ви зберігаєте важливу зміну,
• 16:13
  Coopilot Studio
• 16:14
  автоматично створює нову версію.
• 16:16
  Ви можете відкотитися
• 16:17
  в будь-який момент.
• 16:18
  Жодного страху перезапису.
• 16:19
  Використовуйте це,
• 16:20
  щоб тримати пісочниці експериментальної логіки
• 16:22
  окремо від робочої версії.
• 16:23
  Один потік на звіть,
• 16:24
  погодження заявок ДЕВ,
• 16:25
  інший – погодження заявок прод.
• 16:26
  Тестуйте в ДЕВ,
• 16:27
  публікуйте лише після стабілізації.
• 16:29
  Пам'ятайте, надійність –
• 16:31
  це не лише правильність,
• 16:32
  це контроль під час змін.
• 16:34
  Після публікації
• 16:35
  використовуйте журнали активності.
• 16:37
  Вони не для краси,
• 16:38
  це юридично значущі записи
• 16:40
  взаємодії щі та людини.
• 16:41
  Мітки часу – особи того,
• 16:42
  хто погоджує резюме логіки.
• 16:44
  Періодично переглядайте ці журнали.
• 16:46
  Закономірності стануть очевидними.
• 16:48
  Які правила викликають найбільше відмов,
• 16:50
  які менеджери скасували рішення щі,
• 16:51
  як часто спрацьовують кроки комплеєнсу.
• 16:53
  Ці інсайти вдосконалюють
• 16:55
  як політику, так і дизайн.
• 16:56
  Ще одна тонка порада –
• 16:57
  автоматизуйте оновлення статусу
• 16:59
  в записах Dataverse
• 17:00
  у кінці кожної гілки.
• 17:02
  Дія «Оновлення рядка»
• 17:03
  має встановлювати чітке поле,
• 17:04
  наприклад, статус заявки
• 17:05
  «Схвалено» або «Відхилено».
• 17:07
  Цей видимий фінал підкріплює довіру.
• 17:09
  Користувачі бачать рішення
• 17:10
  безпосередньо у своїх таблицях.
• 17:12
  Жодних окремих таблиць для відстеження,
• 17:13
  жодних примарних погоджень.
• 17:15
  Коли ваша система пройде всі тести,
• 17:16
  натискайте «Опублікувати»
• 17:17
  зі спокійною впевненістю.
• 17:18
  На відміну від попередніх поколінь потоків
• 17:20
  Pava Automate,
• 17:21
  потоки агентів зберігають
• 17:22
  контекстні метадані,
• 17:23
  схему прийняття рішенщі,
• 17:25
  динамічні прив'язки в місто
• 17:26
  та теги-версій.
• 17:27
  Результатом є не просто запущений процес,
• 17:29
  а відтворюваний артефакт,
• 17:30
  автоматизація, що піддається аудиту.
• 17:32
  Остання перевірка на надійність –
• 17:33
  це ментальний тест.
• 17:34
  Опирайтеся надмірному ускладненню.
• 17:36
  Іноді збій у роботі потоку
• 17:37
  виявляє надто складні правила,
• 17:38
  а не технічні помилки.
• 17:40
  Спрощуйте логіку, де це можливо.
• 17:42
  Менше етапів,
• 17:42
  чіткіші інструкції,
• 17:44
  мінімум двозначності.
• 17:45
  Автоматизація – це не випадковість,
• 17:47
  це відмова від зайвого мудрування.
• 17:49
  Коли ви завершуєте цей етап,
• 17:50
  ваша система затвердження
• 17:51
  досягає операційної зрілості,
• 17:53
  протестованої, версійної,
• 17:54
  готової до відкату та перевірки.
• 17:56
  Кожен результат від рішення
• 17:57
  щі до схвалення адміністратором
• 17:58
  залишає цифровий слід,
• 17:59
  що витримує будь-яку перевірку.
• 18:01
  Це і є надійність у цифрах
• 18:02
  не відчуття, не везіння,
• 18:03
  а структуроване мислення,
• 18:05
  зафіксоване інструментами,
• 18:06
  які ви створили,
• 18:07
  щоб працювати, поки ви спите.
• 18:08
  Результати та реальна вигода.
• 18:10
  Що станеться, якщо довірити
• 18:12
  бюрократію математиці?
• 18:13
  Затвердження більше не чекають.
• 18:15
  Багатоетапний агентський потік
• 18:16
  на базі ще скорочує час
• 18:17
  обробки з днів до хвилин,
• 18:19
  бо рішення більше не залежить
• 18:20
  від вільного місця в календарі.
• 18:21
  Кожна заявка, що відповідає
• 18:23
  об'єктивній політиці,
• 18:24
  схвалюється миттєво.
• 18:25
  Кожен нестандартний випадок
• 18:26
  акуратно потрапляє в чергу менеджера
• 18:28
  вже з доданим контекстом.
• 18:29
  Люди ухвалюють ціннісні рішення,
• 18:31
  а не займаються канцелярськими підтвердженнями.
• 18:33
  Вплив спочатку проявляється
• 18:34
  як стиснення часу.
• 18:35
  Відшкодування, що раніше потребувало
• 18:37
  чотирьох листів і двох нагадувань,
• 18:38
  тепер вирішується до обіду.
• 18:40
  Підрозділи отримують коротші цикли обробки,
• 18:42
  менше простоїв і досконало задокументовані
• 18:44
  сліди обґрунтувань.
• 18:46
  Механізм затвердження перестає бути перешкодою.
• 18:48
  Він стає інфраструктурою.
• 18:50
  Далі йде зменшення кількості помилок.
• 18:59
  Він вбудований у систему.
• 19:25
  Журнали Dataverse показують,
• 19:26
  хто затвердив, коли і чому.
• 19:27
  Ця прозорість відбиває бажання шукати
• 19:29
  обхідні шляхи, оскільки кожне рішення
• 19:31
  тепер зафіксоване назавжди.
• 19:33
  І філософський робочий процес змінюється
• 19:34
  від людина-перша за допомогою ЩІ
• 19:36
  до ЩІ-першій з виправленням людини.
• 19:38
  Практичне управління, а не наукова фантастика.
• 19:40
  ЩІ займається дотриманням правил,
• 19:42
  люди винесенням суджень.
• 19:43
  Такий гібрид створює справедливіші, швидші
• 19:45
  та, зрештою, надійніші системи.
• 19:47
  Уявіть, як ви пояснюєте це аудитору.
• 19:49
  Посмішка, яка після цього з'явиться,
• 19:50
  варта однієї лише автоматизації.
• 19:52
  Отже, це все.
• 19:53
  Microsoft Coopilot Studio – це не просто
• 19:55
  черговий інструмент автоматизації.
• 19:56
  Це місце, де нерішучість вашої організації
• 19:58
  нарешті йде у відставку.
• 20:00
  Ви створюєте механізм затвердження,
• 20:01
  який здатен мислити умовами,
• 20:02
  відповідально делегувати повноваження,
• 20:04
  звіряти чеки з реальністю
• 20:05
  та документувати кожен свій крок.
• 20:06
  Це не просто робочий процес,
• 20:08
  це модель управління.
• 20:09
  Якщо ви нічого іншого не запам'ятаєте,
• 20:10
  запам'ятайте це.
• 20:11
  Щі має робити рішення перед бачуваними,
• 20:13
  а людей – винятковими.
• 20:15
  Припиніть спрямовувати все через людей зазвичкою.
• 20:17
  Дозвольте логіці обробляти рутину,
• 20:19
  щоб менеджери могли вирішувати виняткові ситуації.
• 20:21
  Якщо цей огляд врятував вас
• 20:23
  від чергового тижня очікування
• 20:24
  на розгляд керівника – підпишіться.
• 20:26
  Наступний урок заглиблюється
• 20:27
  в розширену автоматизацію Coopilot Studio,
• 20:30
  де ці агентні потоки з'єднуються
• 20:31
  з аналітикою Pava Platform
• 20:32
  та адаптивними політиками.
• 20:34
  Закріпіть свій шлях до оновлень,
• 20:35
  підпишіться, увімкніть сповіщення
• 20:37
  і нехай нові епізоди з'являються автоматично.
• 20:39
  Жодних ручних перевірок,
• 20:40
  жодних пропущених релізів,
• 20:41
  лише постійне постачання корисних знань.
• 20:43
  Дійте!