WEBVTT

00:00:00.000 --> 00:00:09.460
Компанії купують ліцензії на ЩІ, впроваджують навчання, святкують високі показники завершення, а потім спостерігають, як ті ж команди вручно копіюють дані, шукають оновлення статусів у пошті та щомісяця переробляють звіти.

00:00:09.640 --> 00:00:10.880
Це модель марнотратства.

00:00:11.080 --> 00:00:16.080
Інструмент є, витрати реальні, але робота майже не просувається, бо стара модель відстежує охоплення, а не зміни.

00:00:16.260 --> 00:00:19.360
Бейдж не підкаже вам, чи почав фінансовий аналітик закривати звіти швидше.

00:00:19.360 --> 00:00:23.860
Відвідуваність не скаже, чи вдалося менеджеру проєкту прискорити ухвалення заблокованого рішення вдвічі.

00:00:24.000 --> 00:00:29.400
І якщо ви не можете показати зекономлений час, меншу кількість помилок або швидші дії, ЩІ залишається просто статтею витрат.

00:00:29.560 --> 00:00:32.200
Тому в цьому відео я хочу спростити модель вимірювання.

00:00:32.380 --> 00:00:36.520
Зекономлений час, вища швидкість, менше помилок не в теорії, а в реальних завданнях.

00:00:36.520 --> 00:00:38.680
Саме там починає з'являтися ROI.

00:00:38.940 --> 00:00:40.320
Стара модель не працює.

00:00:40.460 --> 00:00:42.980
Чому метрики сертифікації не показують ROI?

00:00:42.980 --> 00:00:46.760
Більшість програм навчання ЩІ все ще дотримуються моделі відповідності вимогам.

00:00:46.900 --> 00:00:52.160
Люди відвідують сесію, завершують модуль, можливо, складають тест, а потім керівництво отримує дашборд із гарними цифрами.

00:00:52.340 --> 00:00:55.260
Відсоток завершення, участь, самооцінка в певненості.

00:00:55.420 --> 00:01:00.660
Це виглядає акуратно, і саме в цьому проблема, бо охені метрики можуть приховувати хаотичну реальність,

00:01:00.660 --> 00:01:03.720
особливо коли сама робота зовсім не змінилася після навчання.

00:01:03.880 --> 00:01:05.900
Те, що зазвичай відбувається, просто.

00:01:05.900 --> 00:01:12.980
Команда дізнається, що таке промп, бачить кілька загальних демо, а потім повертається до Outlook, Excel, Teams і звітних процесів, які все ще працюють по-старому.

00:01:13.140 --> 00:01:17.040
Людина може знати про ще більше, ніж раніше, але щомісячний звіт все одно займає надто багато часу.

00:01:17.180 --> 00:01:18.700
Передача справ все ще дає збої.

00:01:18.820 --> 00:01:21.380
Подальші дії все ще залежать від того, чи не забуде хтось надіслати нагадування.

00:01:21.380 --> 00:01:24.280
Отже, розрив полягає не лише в знаннях, а в поведінці під час виконання завдань.

00:01:24.380 --> 00:01:26.940
І на рівень глибше – це те, де більшість фірм втрачають суть.

00:01:26.940 --> 00:01:30.020
Вони вимірюють шум від використання замість стиснення обсягу роботи.

00:01:30.180 --> 00:01:35.700
Дослідження вказують на величезний розрив між звичайними та просунутими користувачами приблизно в 4-5 разів у продуктивності.

00:01:35.840 --> 00:01:38.700
Це означає, що середні показники впровадження не кажуть вам майже нічого.

00:01:38.860 --> 00:01:41.160
Компанія може стверджувати, люди використовують щі.

00:01:41.160 --> 00:01:44.760
І при цьому не помічати, що лише невелика група перетворює це використання на швидший результат.

00:01:44.940 --> 00:01:47.860
Ось чому показники завершення здаються безпечними, але не доводять цінності.

00:01:47.860 --> 00:01:50.260
Вони кажуть вам лише те, що хтось завершив навчання.

00:01:50.440 --> 00:01:54.960
Вони не кажуть, чи скоротився час на підготовку частини звітності з 20 хвилин до 45 секунд,

00:01:55.080 --> 00:01:57.300
що є одним із фінансових бенчмарків у дослідженні.

00:01:57.420 --> 00:02:01.400
Вони не кажуть, чи заощаджують співробітники в середньому близько 9 годин на місяць,

00:02:01.400 --> 00:02:03.940
що підтверджується численними дослідженнями Co-Pilot.

00:02:04.060 --> 00:02:06.840
І вони точно не кажуть, чи рішення тепер приймаються у 8 разів швидше,

00:02:06.940 --> 00:02:10.820
або чи час до отримання інсейтів скоротився на 88% у вимірюваному впровадженні.

00:02:10.960 --> 00:02:12.400
Це сигнали результативності.

00:02:12.400 --> 00:02:14.000
Все інше – лише підготовка.

00:02:14.160 --> 00:02:15.420
У моделі є ще одна вада.

00:02:15.620 --> 00:02:18.140
Багато пілотних проєктів ніколи не встановлюють реальних базових показників,

00:02:18.220 --> 00:02:19.320
тому згодом не можуть довести зміни.

00:02:19.500 --> 00:02:23.200
Дослідження у ваших матеріалах показує, що 95% корпоративних щі пілотів

00:02:23.200 --> 00:02:24.980
не дали вимірного впливу на прибутки та збитки.

00:02:24.980 --> 00:02:27.120
Не тому, що інструменти самі по собі були невдалими,

00:02:27.220 --> 00:02:29.480
а тому, що організації оминули найскладніші етапи.

00:02:29.760 --> 00:02:33.120
Перепроєктування робочих процесів, відповідальність та вимірювання показників до і після.

00:02:33.120 --> 00:02:35.880
Якщо ви не знаєте, скільки часу займало завдання до підвищення кваліфікації,

00:02:35.980 --> 00:02:37.900
ви не зможете підтвердити жодні результати після впровадження.

00:02:38.040 --> 00:02:41.000
Це стало зрозуміло мені, коли я поглянув на те, як керівники говорять про впровадження.

00:02:41.160 --> 00:02:44.100
Вони часто запитують, скільки людей користувалися коопайлат цього місяця.

00:02:44.220 --> 00:02:46.420
Це звучить розумно, але це неправильне запитання.

00:02:46.600 --> 00:02:50.320
Краще запитання – яке завдання стало коротшим, чистішим або швидшим для прийняття рішення.

00:02:50.480 --> 00:02:53.380
Бо частіше використання щі – це не те саме, що оптимізація роботи.

00:02:53.380 --> 00:02:56.180
Людина може цілий день створювати промпти, але все одно спричиняти переробки,

00:02:56.280 --> 00:02:58.480
затримки та слабкі результати, які хтось інший має виправляти.

00:02:58.600 --> 00:03:02.580
Тому навчання має вийти за межі загальної грамотності та перейти до формування навичок за ролями.

00:03:02.740 --> 00:03:03.620
Не вивчати щі.

00:03:03.780 --> 00:03:06.200
Вчитися, як швидше готувати пояснення відхилень.

00:03:06.340 --> 00:03:09.180
Вчитися, як перетворювати шум на нарадах на готові до виконання завдання.

00:03:09.340 --> 00:03:12.120
Вчитися, як скоротити час обробки тікетів без шкоди для якості.

00:03:12.120 --> 00:03:15.240
Як тільки ви відмовитеся від логіки значків на користь логіки робочих процесів,

00:03:15.340 --> 00:03:16.900
ROI стане набагато легше побачити.

00:03:17.060 --> 00:03:19.540
Модель вимірювання – це фреймворк повернутих хвилин.

00:03:19.640 --> 00:03:21.960
Отже, коли ви припините вимірювати навчання через відвідуваність,

00:03:22.040 --> 00:03:24.140
вам потрібна модель, що пов'язує поведінку з грошима.

00:03:24.300 --> 00:03:25.260
Будьте простішими.

00:03:25.420 --> 00:03:29.880
ROI дорівнює з економленому часу, помноженому на погодинну вартість і рівень впровадження,

00:03:29.880 --> 00:03:34.080
плюс цінність меншої кількості помилок та швидших рішень, мінус інвестиції у навчання.

00:03:34.080 --> 00:03:37.020
Це вся структура. Не ідеально, але працює.

00:03:37.180 --> 00:03:40.380
І це важливіше, бо більшість дискусій про ROI відші руйнуються,

00:03:40.500 --> 00:03:43.080
коли математика стає надто абстрактною для менеджерів.

00:03:43.200 --> 00:03:46.880
Простіше кажучи, ви купуєте нещі, ви викупуєте робочі години,

00:03:47.040 --> 00:03:49.240
щоб перенаправити їх на важливішу роботу.

00:03:49.440 --> 00:03:53.700
Аналіз, планування, ескалація, робота з клієнтами, кращі судження.

00:03:53.700 --> 00:03:56.880
Якщо години зникають у простоях, цінність зменшується.

00:03:57.040 --> 00:04:00.500
Якщо ці години повертаються бізнесу через швидші результати чи кращі рішення,

00:04:00.620 --> 00:04:01.800
цінність стає очевидною.

00:04:01.800 --> 00:04:04.580
Почніть із повернення часу, бо це найчіткіший сигнал.

00:04:04.740 --> 00:04:07.680
Вимірюйте години, зекономлені на одного штатного працівника на місяць,

00:04:07.780 --> 00:04:10.640
але тільки в межах конкретних робочих процесів, а не ще трохи допоміг.

00:04:10.760 --> 00:04:11.460
Це марно.

00:04:11.640 --> 00:04:14.080
Відстежте одне завдання, наприклад, очищення даних в Excel,

00:04:14.240 --> 00:04:17.840
складання щомісячної довідки про відхилення або створення протоколу зустрічі та списку дій,

00:04:17.920 --> 00:04:21.080
а потім порівняйте час виконання вручну та з підтримкою щі за однакових умов.

00:04:21.080 --> 00:04:23.660
Та сама роль, те саме завдання, той самий рівень складності.

00:04:23.660 --> 00:04:25.580
Ось як уникнути математичних фантазій.

00:04:25.740 --> 00:04:29.080
Більшість людей не враховує, що усереднені показники швидко викривляють картину.

00:04:29.220 --> 00:04:32.260
Одна людина може зекономити 15 хвилин, інша – 2 години.

00:04:32.380 --> 00:04:35.120
Тому не починайте з широких припущень для всієї компанії.

00:04:35.260 --> 00:04:37.920
Починайте з рівня робочих процесів, а потім переходьте вище.

00:04:38.100 --> 00:04:40.460
Якщо фінансовий аналітик економить навіть трохи часу на завданні,

00:04:40.560 --> 00:04:43.660
що повторюється багато разів на місяць, загальна кількість зекономлених годин зростає.

00:04:43.660 --> 00:04:46.720
Дослідження у вашій базі даних показують, що навіть скромна щомісячна економія

00:04:46.720 --> 00:04:50.100
швидко виправдовує вартість ліцензії, якщо погоди на цінність працівника достатньо висока.

00:04:50.240 --> 00:04:52.020
Потім додайте швидкість прийняття рішень.

00:04:52.160 --> 00:04:55.680
Це важливо, оскільки значна частина цінності щі полягає не лише у скороченні витрат праці.

00:04:55.840 --> 00:04:58.700
Вона проявляється у зменшенні часу очікування між проблемою та дією.

00:04:58.860 --> 00:05:01.980
Вимірюйте цикл часу від виявлення проблеми до прийняття наступного рішення.

00:05:01.980 --> 00:05:04.860
У деяких командах це час від наради до виконання подальших кроків.

00:05:05.040 --> 00:05:07.680
В інших – від фіксації відхилення до реакції керівництва.

00:05:07.800 --> 00:05:12.200
А оскільки це легко прикрасити розплив частими історіями, використовуйте заміри до і після навчання.

00:05:12.360 --> 00:05:15.320
Та сама команда – той самий тип рішень, той самий шлях погодження.

00:05:15.500 --> 00:05:17.480
Ви маєте підтвердження цього в дослідженнях.

00:05:17.580 --> 00:05:20.220
Деякі організації повідомили про прийняття рішень у вісім разів швидше,

00:05:20.280 --> 00:05:23.420
а час отримання інсейтів скоротився на 88% після впровадження щі.

00:05:23.420 --> 00:05:26.120
Звісно, не варто сприймати ці цифри як універсальну обіцянку,

00:05:26.220 --> 00:05:28.520
оскільки вони залежать від робочого процесу та налаштувань,

00:05:28.620 --> 00:05:32.680
але вони демонструють, що відбувається, коли ще зменшує терття між збором інформації та дією.

00:05:32.800 --> 00:05:36.600
І це саме те, що хвилює керівників, адже повільні рішення зазвичай коштують дорожче,

00:05:36.720 --> 00:05:38.100
ніж повільне створення документів.

00:05:38.220 --> 00:05:40.760
Після цього оберіть ще один показник відповідно до ролі.

00:05:40.860 --> 00:05:43.140
Зменшення кількості помилок добре підходить для фінансів або процесів

00:05:43.140 --> 00:05:44.260
із суворим дотриманням нормативів.

00:05:44.260 --> 00:05:46.780
Пропускна здатність ефективна у сфері сервісних операцій.

00:05:46.880 --> 00:05:49.160
Вартість одного рішення може спрацювати для управлінських процесів,

00:05:49.240 --> 00:05:51.720
де одна й та сама проблема постійно залучає до обговорення багатьох людей.

00:05:51.880 --> 00:05:53.680
Справа не в створенні величезної панелі моніторингу, а в тому,

00:05:53.780 --> 00:05:56.220
щоб підібрати один показник якості або продуктивності для робочого процесу,

00:05:56.300 --> 00:05:57.560
щоб швидкість не маскувала погану роботу.

00:05:57.680 --> 00:05:59.100
Тепер про базову дисципліну.

00:05:59.240 --> 00:06:02.280
Це частина, яку майже всі хочуть пропустити, бо вона здається нудною,

00:06:02.280 --> 00:06:05.180
і саме тому так багато розрахунків, а ROI згодом розвалюється.

00:06:05.320 --> 00:06:07.200
Перед навчанням зафіксуйте час виконання завдання,

00:06:07.300 --> 00:06:09.300
порахуйте доопрацювання та час на передачу роботи.

00:06:09.420 --> 00:06:11.760
Потім проведіть той самий тест після цільового підвищення кваліфікації.

00:06:11.960 --> 00:06:13.480
Якщо завдання змінилося, занотуйте це.

00:06:13.640 --> 00:06:15.120
Якщо обсяг змінився, занотуйте це.

00:06:15.260 --> 00:06:17.020
Якщо якість даних покращилася, занотуйте це.

00:06:17.160 --> 00:06:19.020
Чисті порівняння захищають усю справу.

00:06:19.240 --> 00:06:21.960
Впровадження все ще має значення, але як множник, а не як трофей.

00:06:22.240 --> 00:06:24.400
Ліцензія, що простоює, тягне модель на дно.

00:06:24.540 --> 00:06:27.580
Дослідження ваших джерел показують, що активне використання робочих місць у великих підприємствах

00:06:27.580 --> 00:06:30.960
становить у середньому 55%, а це означає, що значна частина оплачених потужностей

00:06:30.960 --> 00:06:32.140
ніколи не потрапляє в робочий процес.

00:06:32.260 --> 00:06:34.340
Тож не питайте лише про те, чи увійшли користувачі в систему,

00:06:34.440 --> 00:06:37.620
питайте, чи проявилася навчана поведінка неодноразово під час виконання цільового завдання.

00:06:37.780 --> 00:06:40.140
Це саме той сигнал впровадження, який варто відстежувати.

00:06:40.140 --> 00:06:44.460
І ще одна важлива відмінність – валовий зекономлений час – це не те саме, що створена цінність.

00:06:44.580 --> 00:06:47.640
Якщо аналітик економить годину, ця година має значення лише тоді,

00:06:47.740 --> 00:06:50.520
коли вона спрямовується на глибший аналіз, швидшу ескалацію,

00:06:50.640 --> 00:06:52.760
краще планування або більше роботи з клієнтами.

00:06:52.900 --> 00:06:56.920
Тож повна модель насправді така – повернути хвилину, а потім перерозподілити її.

00:06:57.080 --> 00:07:01.460
Ось як щі перестає виглядати як витрати на ПЗ і починає виглядати як операційний важіль.

00:07:01.460 --> 00:07:05.540
Але де ROI з'являється найперше – це три ролі з високою щільністю ROI.

00:07:05.780 --> 00:07:08.920
Коли модель стає зрозумілою, наступне питання – з чого почати?

00:07:09.100 --> 00:07:11.300
Не з усіх підряд, не з найгучнішого відділу.

00:07:11.420 --> 00:07:14.620
Почніть там, де робота повторювана, насичена документами та сповнена дрібних рішень,

00:07:14.720 --> 00:07:15.880
що сповільнюють усе навколо.

00:07:16.000 --> 00:07:18.720
Ось де підвищення кваліфікації за допомогою щі дає кумулятивний ефект.

00:07:18.860 --> 00:07:22.100
Ви навчаєте одній навичці, вона проявляється десятки разів щотижня,

00:07:22.160 --> 00:07:24.400
і прибуток продовжує зростати без збільшення штату.

00:07:24.400 --> 00:07:27.100
Фінансові аналітики знаходяться майже на вершині цього списку,

00:07:27.180 --> 00:07:29.960
оскільки більша частина їхнього тижня минає за структурованими даними,

00:07:30.060 --> 00:07:33.900
періодичними коментарями, звірками та звітними циклами, що виснажують ручною працею.

00:07:34.040 --> 00:07:36.660
Вони живуть в Excel, очищують вхідні дані, порівнюють версії,

00:07:36.780 --> 00:07:40.880
пояснюють зміни та перетворюють серій, цифри на щось, на основі чого керівництво може діяти.

00:07:41.040 --> 00:07:44.480
Це саме той вид роботи, де рольові навички ще можуть швидко зменшити затримки,

00:07:44.480 --> 00:07:46.840
оскільки проблема зазвичай не в складних судженнях.

00:07:46.840 --> 00:07:50.920
Це робота до винесення судження, збирання, формування, написання черниток, перевірка, переписування.

00:07:51.080 --> 00:07:53.760
У дослідженні фінансові команди повідомляють про значну щомісячну економію,

00:07:53.820 --> 00:07:56.300
а деякі пілетні проєкти показують, що робота зі звітністю скорочується

00:07:56.300 --> 00:07:58.420
з довгих ручних циклів до набагато швидших перших черниток.

00:07:58.520 --> 00:08:00.800
Ця тенденція важливіша за будь-яку гучну цифру.

00:08:00.980 --> 00:08:04.300
Аналітики не перестають бути аналітиками, вони перестають витрачати стільки часу

00:08:04.300 --> 00:08:05.920
на створення першої версії результату.

00:08:05.920 --> 00:08:08.840
Коли цей суд вдається, ви бачите реальне повернення потужностей,

00:08:08.940 --> 00:08:12.520
часто в діапазоні від 30% до 50% для цільових завдань,

00:08:12.620 --> 00:08:15.660
а завершальні цикли починають проходити з меншою метушнею наприкінці.

00:08:15.840 --> 00:08:19.880
Менеджери проєктів – ще одна зона з високою щільністю ROI, але з іншої причини.

00:08:20.080 --> 00:08:22.900
Їхня робота похована під тягарем координації, збором статусів,

00:08:23.020 --> 00:08:25.480
нотатками з нарад, відстеженням завдань, логами ризиків,

00:08:25.480 --> 00:08:27.540
фоллоу-апами, оновленнями для стейкхолдерів.

00:08:27.540 --> 00:08:29.640
Ніщо з цього не є тривіальним, і все це створює затримки,

00:08:29.760 --> 00:08:32.640
коли інформація залишається в чатах, презентаціях або напівготових нотатках,

00:08:32.760 --> 00:08:34.480
замість того, щоб переходити до прийняття рішень.

00:08:34.620 --> 00:08:37.700
Отже, коли піеми вчаться використовувати ще всередині робочого процесу,

00:08:37.780 --> 00:08:40.520
а не як побічний експеримент, це відчутно впливає на продуктивність.

00:08:40.740 --> 00:08:43.340
Щотижневий цикл підготовки, який раніше займав 6 годин,

00:08:43.440 --> 00:08:46.480
може скоротитися до 2, коли підсумки, виділення завдань та чернетки

00:08:46.480 --> 00:08:48.340
з'являються всередині звичних інструментів.

00:08:48.340 --> 00:08:51.760
Ще важливіше те, що результат стає набагато зручнішим для подальшої роботи.

00:08:51.880 --> 00:08:54.380
Людям більше не потрібно відновлювати в пам'яті хід зустрічі.

00:08:54.520 --> 00:08:57.540
Вони відразу бачать ризики, відповідальних, дедлайни та наступні кроки.

00:08:57.780 --> 00:09:01.820
Саме тому цикли прийняття рішень у таких середовищах можуть прискоритися на від 25 до 40%.

00:09:01.820 --> 00:09:03.920
Швидкість досягається не за рахунок швидкого друку,

00:09:04.000 --> 00:09:06.440
а завдяки скороченню затримки між обговоренням та виконанням.

00:09:06.600 --> 00:09:10.540
Далі йдуть оперативні служби та підтримка, де обсяг роботи визначає економічний результат.

00:09:10.540 --> 00:09:17.280
Ці команди працюють із типовими питаннями, повторюваними повідомленнями, пошуком знань, резюме кейсів та постійним перемиканням між системами.

00:09:17.400 --> 00:09:20.200
Тут важлива кожна дрібниця, бо це відбувається цілий день.

00:09:20.340 --> 00:09:23.920
Якщо час на підтримку одного запиту скорочується з 12 до 7 хвилин,

00:09:24.000 --> 00:09:26.580
цей розрив накопичується на сотнях або тисячах взаємодій,

00:09:26.660 --> 00:09:29.340
і пропускна здатність зростає без потреби наймати нових людей.

00:09:29.500 --> 00:09:32.320
Це також те місце, де тиск щодо якості стає справжнім викликом.

00:09:32.320 --> 00:09:35.220
Команда не може просто рухатися швидше, вона повинна триматися в межах цілей,

00:09:35.320 --> 00:09:37.640
залишатися точною та підтримувати стабільну якість відповідей.

00:09:37.760 --> 00:09:42.180
Ось чому на початкових етапах ці ролі отримують більше користі від чіткіших шаблонів промптів та вущих сценаріїв використання.

00:09:42.340 --> 00:09:48.240
Створити чернитку відповіді, знайти потрібну інформацію, підсумувати кейс і залишити за людиною перевірку нестандартних ситуацій.

00:09:48.360 --> 00:09:54.940
Коли встановлена така дисципліна, зростання продуктивності на від 20 до 40% починає виглядати цілком реалістично, а не завищено.

00:09:54.940 --> 00:10:00.320
Отже, правило вибору просте. Не розподіляйте навчання рівномірно по всій організації лише тому, що це здається справедливим.

00:10:00.460 --> 00:10:04.560
Впроваджуйте щитам, де він збільшує віддачу через повторення, документацію та обсяг прийнятих рішень.

00:10:04.700 --> 00:10:07.620
Фінанси забезпечують вимірне скорочення часу на підготовку аналітики.

00:10:07.760 --> 00:10:10.820
Управління проєктами дає змогу швидше рухатися завдяки кращій координації.

00:10:11.000 --> 00:10:14.180
Операції та підтримка дають вам зростання обсягів з чіткими сервісними метриками.

00:10:14.340 --> 00:10:16.140
Різні ролі, але один і той самий паттерн.

00:10:16.140 --> 00:10:20.100
Робота рухається з меншим тертям, тому що інформація надходить уже готовою до прийняття рішення.

00:10:20.240 --> 00:10:22.020
І саме через цю призму варто дивитися на приклади.

00:10:22.120 --> 00:10:27.620
Сигнал стає чіткішим, якщо ви перестаєте питати, хто користувався інструментом, а починаєте питати, який робочий процес став коротшим.

00:10:27.760 --> 00:10:30.860
Докази в робочому процесі – три конкретні приклади, док та після.

00:10:30.980 --> 00:10:36.400
Тож перейдімо до конкретики, адже саме тут окупність ще стає або аргументованою, або перетворюється на абстрактні обіцянки.

00:10:36.640 --> 00:10:37.700
Почнімо з фінансів.

00:10:37.700 --> 00:10:44.760
До цілеспрямованого підвищення кваліфікації цикл щомісячної звітності може розтягуватися на п'ять днів не тому, що сам аналіз займає п'ять днів,

00:10:44.880 --> 00:10:53.280
а тому, що аналітики витрачають надто багато часу на збір цифр, перевірку форматування, підготовку коментарів та написання одних і тих самих пояснень, відхилень знову і знову.

00:10:53.440 --> 00:10:55.620
Набуті навички змінюють цю послідовність.

00:10:55.620 --> 00:11:03.720
Замість того, щоб починати з чистого аркуша, аналітик використовує щі для створення чернетки коментарів, підсумовування змін за категоріями та структурування пояснень для перевірки.

00:11:03.840 --> 00:11:05.820
Процес закриття періоду нікуди не зникає.

00:11:05.980 --> 00:11:10.680
Аналітик, як і раніше, перевіряє цифри, але рутинна робота зменшується і цикл може скоротитися з п'ятьох днів до двох.

00:11:10.820 --> 00:11:12.920
Справжній прибуток – це те, що відбувається далі.

00:11:13.060 --> 00:11:15.420
Ці вивільнені години не витрачаються на прикрашання звітів.

00:11:15.420 --> 00:11:19.460
Вони спрямовуються на планування сценаріїв, розгляд винятків та швидшу комунікацію з особами, що приймають рішення.

00:11:19.580 --> 00:11:21.220
Тепер погляньмо на управління проектами.

00:11:21.340 --> 00:11:23.580
Основна проблема зазвичай полягає не у відсутності зусиль.

00:11:23.720 --> 00:11:24.760
Вона у фрагментації.

00:11:24.960 --> 00:11:28.900
Нотатки в одному місці, дії в іншому, ризики, заховані в записі зустрічі, які нікому ніколи переглядати.

00:11:29.040 --> 00:11:32.940
Менеджер проектів може легко витрачати 6 годин на тиждень лише на те, щоб привести статус проекту до зручного вигляду.

00:11:32.940 --> 00:11:35.500
Після спеціалізованого навчання робочий процес змінюється.

00:11:35.640 --> 00:11:37.920
Нотатки із зустрічей узагальнюються за єдиним шаблоном.

00:11:38.120 --> 00:11:40.700
Завдання виокремлюються з чіткими відповідальними особами та дедлайнами.

00:11:40.860 --> 00:11:44.940
Ризики та перешкоди виявляються раніше, оскільки менеджеру не потрібно реконструювати їх вручно постфактом.

00:11:45.080 --> 00:11:48.800
Цей час на підготовку може скоротитися з 6 годин до 2, і головний виграш чекає попереду.

00:11:48.980 --> 00:11:50.480
Ескалації відбуваються раніше.

00:11:50.660 --> 00:11:53.180
Зацікавлені сторони отримують оновлення, готові до реагування.

00:11:53.180 --> 00:11:57.140
Менше рішень відкладається через те, що інформація приходить запізно, неповною або нечіткою.

00:11:57.280 --> 00:11:58.980
Змінилася не назва посади менеджера.

00:11:59.120 --> 00:12:01.860
Змінилася швидкість, з якою інформація стала придатною для використання.

00:12:02.040 --> 00:12:05.640
Далі – підтримка та операційна діяльність, де математика стає дуже помітною дуже швидко.

00:12:05.780 --> 00:12:07.360
Почнімо зі звичайного кейсу.

00:12:07.520 --> 00:12:11.400
Середній час обробки становить 12 хвилин, тому що люди шукають правильну відповідь,

00:12:11.480 --> 00:12:16.000
пишуть її з нуля, узагальнюють справу, а потім переходять до наступної, вже відстаючи від графіка.

00:12:16.000 --> 00:12:19.760
Після цілеспрямованого навчання агент, використовує щі для черниток відповідей,

00:12:19.880 --> 00:12:24.320
швидкого пошуку в затвердженій базі знань та структурованих резюме, що зменшує повторні пошуки.

00:12:24.500 --> 00:12:27.540
Час обробки може скоротитися з 12 хвилин до 7-ох.

00:12:27.660 --> 00:12:30.760
Це важливо саме по собі, але більш суттєвим є фактор стабільності.

00:12:30.960 --> 00:12:33.160
Більше справ вирішується в межах встановлених цілей.

00:12:33.360 --> 00:12:36.580
Якість першої відповіді покращується, оскільки вона базується на підготовленій черниці,

00:12:36.680 --> 00:12:37.960
а не на поспішному написанні вручну.

00:12:37.960 --> 00:12:40.600
І команда отримує простір для дихання без збільшення штату.

00:12:40.740 --> 00:12:43.140
Для всіх трьох випадків структура залишається незмінною.

00:12:43.280 --> 00:12:44.740
Ви починаєте з базового завдання.

00:12:44.920 --> 00:12:46.800
Ви навчаєте методам роботи всередині цього завдання.

00:12:46.940 --> 00:12:48.280
Робочий процес стає коротшим.

00:12:48.400 --> 00:12:50.360
Потім вивільнений ресурс спрямовується на корисні речі.

00:12:50.480 --> 00:12:53.380
Ця повторювана структура важлива, бо вона забезпечує обґрунтованість бізнес-кейсу.

00:12:53.500 --> 00:12:54.940
Ви не стверджуєте, що це магія.

00:12:54.940 --> 00:12:58.560
Ви показуєте, куди пішов час, що змінилося і що команда зробила з отриманим виграшем.

00:12:58.700 --> 00:13:02.800
Зовнішні показники у ваших дослідженнях підтверджують цю модель, не замінюючи внутрішні докази.

00:13:02.940 --> 00:13:07.220
Згідно з дослідженнями Microsoft Co-Pilot, користувачі повідомляють про щомісячну економію часу,

00:13:07.280 --> 00:13:09.700
а значна частина – про швидше створення якісних черниток.

00:13:09.800 --> 00:13:13.400
У вимірюваних впровадженнях команди також повідомляють про швидше отримання аналітичних даних

00:13:13.400 --> 00:13:16.700
і кращу швидкість прийняття рішень, коли ще інтегрований у реальний робочий процес,

00:13:24.940 --> 00:13:28.140
Не питайте, чи торкнувся ще процесу.

00:13:28.260 --> 00:13:32.220
Запитайте, чи просувається процес тепер із меншими затримками, меншою кількістю переробок

00:13:32.220 --> 00:13:34.360
і кращим використанням кваліфікованих фахівців.

00:13:34.480 --> 00:13:36.740
У кожному з цих випадків ще не замінив роль.

00:13:36.920 --> 00:13:40.040
Він усунув затримку між надходженням інформації та початком дій.

00:13:40.180 --> 00:13:41.380
Ось у чому перевага.

00:13:41.460 --> 00:13:43.900
Але це діє лише тоді, коли система навколо контрольована,

00:13:43.900 --> 00:13:47.300
оскільки як тільки результати починають відхилятися, джерела стають неточними

00:13:47.300 --> 00:13:49.820
або люди починають імпровізувати у ризикованих процесах,

00:13:49.820 --> 00:13:53.020
видимий виграш може зникнути через приховану роботу з виправлення помилок.

00:13:53.480 --> 00:13:55.820
Жорстка лінія управління, що захищає рентабельність.

00:13:56.500 --> 00:13:58.860
Тепер частина, яку багато хто пропускає в контенті про щі,

00:13:58.960 --> 00:14:01.380
бо це звучить менш захопливо, ніж продуктивність управління.

00:14:01.500 --> 00:14:04.400
Але якщо опустити це, ваша модель рентабельності швидко втратить сенс,

00:14:04.500 --> 00:14:07.180
оскільки неякісні результати створюють приховану роботу з перевірки,

00:14:07.180 --> 00:14:09.800
слабкі рішення та ризики, які ніхто не врахував на старті.

00:14:09.900 --> 00:14:11.320
Почніть із межі даних.

00:14:11.320 --> 00:14:15.320
Щі має працювати лише з перевіреними джерелами даних за чіткими правилами доступу

00:14:15.320 --> 00:14:17.420
та з вхідними даними, яким можна довіряти.

00:14:17.640 --> 00:14:20.280
Якщо джерело застаріле, неточне або взяти не з того місця,

00:14:20.440 --> 00:14:24.000
результат може виглядати професійно, але все одно штовхати команду в хибному напрямку.

00:14:24.180 --> 00:14:25.260
Це дорого коштує.

00:14:25.440 --> 00:14:27.560
Не завжди очевидно, але у вигляді повторних перевірок,

00:14:27.560 --> 00:14:30.040
переробок, затримок із погодженнями та втрати впевненості.

00:14:30.160 --> 00:14:32.460
Отже, операційне правило має залишатися простим.

00:14:32.600 --> 00:14:35.320
Контрольовані дані на вході, перевірений результат на вигоді.

00:14:35.320 --> 00:14:38.480
І залишти людину в циклі там, де насправді лежить відповідальність.

00:14:38.640 --> 00:14:41.580
Щі може складати чернетки, резюмувати, пропонувати шаблони,

00:14:41.720 --> 00:14:44.980
але затвердження, винятки та остаточні рішення залишаються за людьми.

00:14:45.120 --> 00:14:46.900
Це не просто обережність заради обережності,

00:14:47.000 --> 00:14:50.060
це спосіб захистити якість рішень, отримуючи при цьому перевагу в швидкості.

00:14:50.060 --> 00:14:52.820
Особливо у фінансах, проектних ризиках, роботі з клієнтами

00:14:52.820 --> 00:14:54.340
чи будь-чому з регуляторними наслідками,

00:14:54.440 --> 00:14:56.840
хтось має нести відповідальність за висновок, а не лише за запит.

00:14:56.840 --> 00:14:59.280
Ось де допомагає розподіл за сценаріями використання.

00:14:59.460 --> 00:15:01.300
Спочатку масштабується робота з низьким ризиком,

00:15:01.460 --> 00:15:04.400
резюме, чернетки листів, протоколи зустрічей, попередні коментарі.

00:15:04.540 --> 00:15:06.240
Це хороші сфери для формування звичок,

00:15:06.320 --> 00:15:08.780
бо вигоду легко побачити, а недоліки легко помітити.

00:15:09.000 --> 00:15:11.340
Далі ви переходите до моніторингу аналітичної підтримки,

00:15:11.340 --> 00:15:14.560
де ще допомагає структурувати мислення, але не замикає процес самотужки.

00:15:14.900 --> 00:15:17.660
Високоризикована автоматизація залишається вузькою та контрольованою,

00:15:17.660 --> 00:15:20.840
адже як тільки робочий процес несе фінансові, юридичні чи сервісні ризики,

00:15:20.960 --> 00:15:22.200
ціна помилки швидко зростає.

00:15:22.340 --> 00:15:24.980
Без такого розмежування компанії змішують усе докупи.

00:15:25.100 --> 00:15:27.720
Вони ставляться до резюме зустрічі та шляху прийняття важливого рішення так,

00:15:27.820 --> 00:15:29.200
ніби вони мають однаковий рівень ризику.

00:15:29.360 --> 00:15:29.960
Це не так.

00:15:30.100 --> 00:15:32.620
І коли люди не бачать межі, вони або занадто довіряють інструменту,

00:15:32.620 --> 00:15:33.760
або повністю його уникають.

00:15:33.880 --> 00:15:35.380
Обидва підходи нівелюють цінність.

00:15:35.500 --> 00:15:36.920
Стандарти також мають значення.

00:15:37.080 --> 00:15:39.000
Випадкові запити дають випадковий результат.

00:15:39.000 --> 00:15:42.180
Якщо кожен співробітник вигадує власний спосіб створення резюме,

00:15:42.320 --> 00:15:44.900
черниток чи аналітики, якість стає непередбачуваною,

00:15:44.980 --> 00:15:48.060
а менеджери замість бізнес-результатів перевіряють відмінності у стилі.

00:15:48.200 --> 00:15:50.900
Спільні шаблони запитів, інструкції для ролей та прості приклади

00:15:50.900 --> 00:15:52.100
зменшують цю невідповідність.

00:15:52.100 --> 00:15:53.720
Не тому, що запити – це і є стратегія,

00:15:53.800 --> 00:15:55.980
а тому, що повторювані дії мінімізують потребу в переробках.

00:15:56.120 --> 00:15:58.600
Вимірювання ефективності не повинно закінчуватися після впровадження.

00:15:58.740 --> 00:16:00.520
Вам потрібна актуальна інформація про завщаджений час,

00:16:00.520 --> 00:16:02.420
глибину впровадження, частоту помилок, обсяг переробок

00:16:02.420 --> 00:16:03.700
та будь-яке зниження якості результату.

00:16:03.820 --> 00:16:06.120
Інакше початкові здобутки можуть приховати майбутній спад.

00:16:06.240 --> 00:16:07.680
Команда може виглядати швидшою на папері,

00:16:07.760 --> 00:16:09.620
тоді як обсяг виправлень накопичується в іншому місці.

00:16:09.760 --> 00:16:10.480
Це не ROI.

00:16:10.800 --> 00:16:13.240
Це просто переміщення витрат в іншу частину системи.

00:16:13.240 --> 00:16:15.060
І це головний висновок для керівництва.

00:16:15.220 --> 00:16:16.860
Управління не сповільнює створення цінності,

00:16:16.940 --> 00:16:18.380
воно захищає її від перебільшення.

00:16:18.380 --> 00:16:20.360
Лідери фінансують не те, що здається розумним,

00:16:20.440 --> 00:16:22.580
а те, що вони можуть перевірити, порівняти та захистити,

00:16:22.680 --> 00:16:24.100
коли виникають питання до результатів.

00:16:24.200 --> 00:16:26.620
Отже, якщо ваша щі-програма має чіткі вхідні дані,

00:16:26.760 --> 00:16:29.700
визначену відповідальність, розумні рівні та вимірювані результати,

00:16:29.700 --> 00:16:32.880
це перестає бути експериментом і стає операційною дисципліною.

00:16:33.020 --> 00:16:35.240
Як тільки ці елементи контролю вбудовані,

00:16:35.360 --> 00:16:38.260
масштабування щі перестає бути ставкою на ентузіазм

00:16:38.260 --> 00:16:40.260
і стає зваженим бізнес-рішенням.

00:16:40.260 --> 00:16:42.080
Масштабування без зайвих витрат

00:16:42.080 --> 00:16:44.960
Як перейти від пілотної версії до операційної моделі?

00:16:45.100 --> 00:16:47.840
Після цього наступна помилка – надто раннє масштабування.

00:16:48.000 --> 00:16:50.240
Пілот демонструє успіх, керівництво надихається

00:16:50.240 --> 00:16:52.440
і ліцензії розповсюджуються компанією до того,

00:16:52.440 --> 00:16:55.040
як хтось зафіксував модель, що реально принесла результат.

00:16:55.200 --> 00:16:56.700
Саме тут втрачаються кошти.

00:16:56.880 --> 00:16:58.560
Не тому, що інструмент перестав працювати,

00:16:58.660 --> 00:17:00.980
а тому, що навколо нього не сформувалася операційна модель.

00:17:01.120 --> 00:17:03.220
Кращий шлях – почати з малого і конкретного.

00:17:03.220 --> 00:17:06.240
Оберіть від трьох до п'яти робочих процесів для кожної цільової ролі.

00:17:06.340 --> 00:17:07.800
Не десять – не кожен можливий варіант,

00:17:07.900 --> 00:17:09.460
а лише процеси з регулярними обсягами,

00:17:09.580 --> 00:17:11.580
видимими труднощами та чітким бізнес-значенням.

00:17:11.700 --> 00:17:14.460
Зафіксуйте базові показники до того, як щось почне змінюватися.

00:17:14.460 --> 00:17:17.740
Потім навчайте людей самій роботі, а не загальному огляду функцій.

00:17:17.860 --> 00:17:20.800
Фінансовому аналітику не потрібен загальний урок про можливості «Щ».

00:17:20.800 --> 00:17:22.980
Йому треба знати, як швидше готувати коментарі,

00:17:23.080 --> 00:17:25.060
оперативніше очищувати регулярні таблиці

00:17:25.060 --> 00:17:27.880
та структурувати перевірку відхилень із меншою кількістю правок.

00:17:28.000 --> 00:17:30.760
Тоді запускайте короткі пілотні цикли з жорсткими критеріями успіху.

00:17:30.880 --> 00:17:32.380
Чи вдалося вивільнити робочі години?

00:17:32.500 --> 00:17:33.700
Чи скоротився час циклу?

00:17:33.820 --> 00:17:35.200
Чи залишилася якість незмінною?

00:17:35.340 --> 00:17:37.920
Чи продовжували навчені користувачі використовувати цей підхід після першого тижня?

00:17:37.920 --> 00:17:39.640
Це і є сигнали, що мають значення.

00:17:39.780 --> 00:17:42.280
Якщо активне використання зменшується або обсяг переробок зростає,

00:17:42.360 --> 00:17:43.300
не поспішайте масштабувати.

00:17:43.300 --> 00:17:46.160
Спершу виправте робочий процес, інструкції чи підтримку.

00:17:46.300 --> 00:17:48.760
Ріст без такої дисципліни лише масштабує плутанину.

00:17:48.900 --> 00:17:50.660
Тут допомагає створення наборів доказів,

00:17:50.780 --> 00:17:52.800
що відповідають мові кожного зі стейкхолдерів.

00:17:52.900 --> 00:17:55.580
Фінансовий директор хоче бачити оцінку вартості вивільненої праці

00:17:55.580 --> 00:17:56.380
та уникнених втрат.

00:17:56.520 --> 00:17:58.660
Операційний директор очікує змін у часі циклу,

00:17:58.740 --> 00:18:00.380
продуктивності та надійності сервісу.

00:18:00.500 --> 00:18:01.660
Лінійні менеджери хочуть знати,

00:18:01.740 --> 00:18:03.240
чи може команда взяти на себе більше роботи,

00:18:03.240 --> 00:18:05.700
швидше реагувати або зменшити рутинно-адміністративну роботу.

00:18:05.820 --> 00:18:07.300
Тож, коли просите про наступний етап,

00:18:07.420 --> 00:18:08.860
ненавидьте загальні заяви вендорів.

00:18:08.980 --> 00:18:10.700
Показуйте дані по ролях зі свого середовища,

00:18:10.760 --> 00:18:12.560
прив'язані до одного робочого процесу зараз.

00:18:12.680 --> 00:18:14.320
Бюджет також потребує перегляду.

00:18:14.480 --> 00:18:16.760
За багато витрат наші досі йде на загальну сертифікацію

00:18:16.760 --> 00:18:18.880
та разові тренінги, які виглядають організовано,

00:18:19.000 --> 00:18:19.980
але не дають результату.

00:18:20.120 --> 00:18:21.620
Більше ефективна модель вкладає кошти

00:18:21.620 --> 00:18:23.320
у вбудований у робочі процеси коучинг,

00:18:23.320 --> 00:18:25.600
спільні бібліотеки промктів та підтримку керівників,

00:18:25.680 --> 00:18:27.880
бо саме ці механізми перетворюють корисну демо-версію

00:18:27.880 --> 00:18:28.700
на сталу поведінку.

00:18:28.900 --> 00:18:31.700
Дослідження у ваших джерелах також вказують на цей напрямок.

00:18:32.040 --> 00:18:34.040
Високоефективні організації витрачають більше

00:18:34.040 --> 00:18:36.200
на дизайн внутрішніх програм та підтримку менеджерів,

00:18:36.300 --> 00:18:38.500
а не на зовнішню сертифікацію як основне рішення.

00:18:38.660 --> 00:18:40.780
Масштабування має відбуватися за кластерами ролей

00:18:40.780 --> 00:18:41.800
та рівнями використання.

00:18:41.960 --> 00:18:43.960
Якщо одна фінансова команда підтверджує цінність

00:18:43.960 --> 00:18:45.140
у звітності та звірці даних,

00:18:45.220 --> 00:18:46.980
переходьте до суміжних фінансових процесів.

00:18:47.120 --> 00:18:48.700
Якщо менеджери проєктів демонструють успіхи

00:18:48.700 --> 00:18:50.200
у звітуванні про стан та відстеженні завдань,

00:18:50.280 --> 00:18:51.880
переходьте до пов'язаних моделей координації.

00:18:52.020 --> 00:18:53.720
Такий вид масштабування є стійким.

00:18:53.900 --> 00:18:55.220
Загальне ліцензування рідко,

00:18:55.320 --> 00:18:57.440
бо використання поширюється швидше, ніж навички.

00:18:57.580 --> 00:18:59.900
І тримайте одне запитання перед кожним рішенням

00:18:59.900 --> 00:19:00.640
про розгортання.

00:19:00.780 --> 00:19:02.300
Чи змінило це хід роботи?

00:19:02.460 --> 00:19:03.980
Якщо відповідь ні, зупиніться,

00:19:03.980 --> 00:19:06.400
бо прибуток приходить не від надання доступу до щі,

00:19:06.400 --> 00:19:08.360
а від зміни шляху відведення даних до дії

00:19:08.360 --> 00:19:10.280
у спосіб, який бізнес може виміряти.

00:19:10.460 --> 00:19:11.660
Отже, зміна проста.

00:19:11.840 --> 00:19:13.980
ROI не виникає від обсягів навчання.

00:19:14.220 --> 00:19:15.860
Він виникає від коротших завдань,

00:19:15.980 --> 00:19:18.420
швидших рішень та чіткішого виконання роботи,

00:19:18.500 --> 00:19:19.540
яку люди вже роблять.

00:19:19.700 --> 00:19:21.840
Оберіть один процес цього тижня у фінансах,

00:19:21.920 --> 00:19:23.520
управлінні проєктами чи підтримці,

00:19:23.640 --> 00:19:25.320
порівняйте ручну версію з версією

00:19:25.320 --> 00:19:26.660
ще післяцільового навчання

00:19:26.660 --> 00:19:28.480
і спостерігайте, куди спрямовується

00:19:28.480 --> 00:19:29.460
вивільнений ресурс.

00:19:29.460 --> 00:19:31.820
Якщо це змінило ваше уявлення про Microsoft AI,

00:19:32.000 --> 00:19:34.360
підписуйтеся на подкаст M365FM,

00:19:34.500 --> 00:19:35.280
залишайте відгуки,

00:19:35.400 --> 00:19:37.000
додавайтеся до мене, Мірко Петерса,

00:19:37.100 --> 00:19:38.840
у LinkedIn і надсилайте наступну проблему

00:19:38.840 --> 00:19:40.060
у вашому робочому процесі,

00:19:40.140 --> 00:19:41.040
яку варто розібрати.