WEBVTT 00:00:00.000 --> 00:00:02.760 Ваша керівна команда вважає, що це питання впровадження. 00:00:02.920 --> 00:00:03.600 Це не так. 00:00:03.720 --> 00:00:06.640 Це управлінське рішення з дуже обмеженим часом, і тиск зростає, 00:00:06.760 --> 00:00:10.620 бо Coopilot не чекатиме, поки ви наведіть лад у політиках чи внутрішніх процесах. 00:00:10.780 --> 00:00:12.900 Як тільки він починає працювати у вашому середовищі, 00:00:12.980 --> 00:00:16.280 він використовує систему такою, якою її бачить, і саме тут усе ламається. 00:00:16.440 --> 00:00:19.500 Більшість організацій з кількома орендарями Microsoft 365 вважають, 00:00:19.620 --> 00:00:21.600 що мають єдину стратегію контролю щі, переважно тому, 00:00:21.600 --> 00:00:24.960 що купують продукти в одного постачальника та керують однією структурою ідентифікації. 00:00:25.100 --> 00:00:27.100 Вони чують єдиний стратегічний наратив від Microsoft 00:00:27.100 --> 00:00:29.300 і припускають, що реальність відповідає обіцянкам. 00:00:29.460 --> 00:00:31.500 Але фактичні умови роботи зовсім інші. 00:00:31.660 --> 00:00:34.680 Щі працює в межах орендаря, тоді як ризики вільно переміщуються між ними. 00:00:34.820 --> 00:00:37.540 Тож питання не в тому, чи можемо ми ввімкнути Coopilot всюди. 00:00:37.700 --> 00:00:40.380 Справжнє питання в тому, яка модель управління дозволить нам безпечно 00:00:40.380 --> 00:00:42.540 масштабуватися між орендарями, що діють незалежно. 00:00:42.540 --> 00:00:45.660 Перш ніж перейти до цієї моделі, нам потрібно окреслити пастку. 00:00:45.760 --> 00:00:48.960 Пастка «Суверенні острови» щі всередині одного підприємства. 00:00:49.140 --> 00:00:52.160 У більшості організацій ілюзія починається з відчуття знаємості. 00:00:52.280 --> 00:00:54.860 Ви відкриваєте Microsoft 365, ви відкриваєте Perview, 00:00:54.980 --> 00:00:56.880 ви відкриваєте Entra, ви відкриваєте Pava Platform. 00:00:57.060 --> 00:00:58.120 Брендинг однаковий. 00:00:58.280 --> 00:01:00.300 Мова адміністрування здається цілісною, 00:01:00.420 --> 00:01:02.860 а комерційна пропозиція виглядає дуже привабливо. 00:01:03.040 --> 00:01:05.700 Одна екосистема, одна стратегія, один напрямок. 00:01:05.700 --> 00:01:09.280 Але модель контролю під капотом не єдина, і це важливіше за брендинг. 00:01:09.460 --> 00:01:12.920 Згідно з нашими дослідженнями, не існує єдиного глобального центру адміністрування 00:01:12.920 --> 00:01:16.200 ще з повною функціональністю, який дав би вам одне місце для зручного керування 00:01:16.200 --> 00:01:17.520 Co-Pilot в усіх орендарях. 00:01:17.680 --> 00:01:19.980 Насправді у вас фрагментований стек контролю. 00:01:20.120 --> 00:01:23.600 Частини управління знаходяться в Perview, інші – в центрах адміністрування, 00:01:23.740 --> 00:01:25.880 а решта розкидані між Entra та Pava Platform. 00:01:26.100 --> 00:01:28.900 Деякі функції з'являються в нових рівнях контролю Microsoft, 00:01:28.900 --> 00:01:33.120 але вони ще не утворюють єдину повноглобальну площину через межі всіх орендарів. 00:01:33.240 --> 00:01:35.540 Цей розрив створює хибне почуття впевненості. 00:01:35.700 --> 00:01:38.320 Керівники дивляться на екосистему і припускають централізацію, 00:01:38.440 --> 00:01:41.540 тоді як команди дивляться на спільну ідентифікацію і припускають послідовність. 00:01:41.700 --> 00:01:44.480 Закупівлі бачать одну угоду і припускають одну модель роботи, 00:01:44.580 --> 00:01:47.160 але кожен орендар все одно має власні межі політик і даних, 00:01:47.240 --> 00:01:50.440 а це означає, що на практиці кожен має свою власну версію істини. 00:01:50.580 --> 00:01:52.760 Отже, те, що відбувається насправді, дуже просто. 00:01:52.760 --> 00:01:55.100 У вас немає одного корпоративного середовища щі. 00:01:55.220 --> 00:01:58.200 У вас є кілька середовищ щі, які просто належать до одного підприємства. 00:01:58.360 --> 00:01:59.980 Це зовсім інша картина ризиків. 00:02:00.100 --> 00:02:02.180 Один орендар може мати краще покриття перв'ю, 00:02:02.300 --> 00:02:05.680 тоді як інший, слабше впровадження міток або неповне збирання аудиту. 00:02:05.880 --> 00:02:08.660 На рівні ради директорів це все ще може виглядати як одна програма, 00:02:08.760 --> 00:02:11.760 але з точки зору аудиту чи інцидентів це зовсім не одна програма. 00:02:11.900 --> 00:02:13.880 Це набір окремих операційних умов. 00:02:14.020 --> 00:02:17.060 І як тільки ці умови змінюються, звітність починає брехати. 00:02:17.060 --> 00:02:18.680 Не навмисно, а структурно. 00:02:18.820 --> 00:02:21.580 Керівна команда запитує, чи ми здійснюємо управління. 00:02:21.700 --> 00:02:26.400 Один орендар каже, так, бо ввімкнено аудит, інший, бо є мітки, навіть якщо охоплення слабке. 00:02:26.540 --> 00:02:28.960 Третій каже, так, бо підключена ідентифікація. 00:02:29.180 --> 00:02:31.900 Четвертий каже, так, бо Coopilot технічно розгорнуто. 00:02:32.040 --> 00:02:35.620 Кожна відповідь звучить слушно сама по собі, але жодна з них не означає одне й те саме. 00:02:35.740 --> 00:02:36.760 Ось у чому пастка. 00:02:36.920 --> 00:02:39.220 Ви думаєте, що дивитеся на глобальну панель управління, 00:02:39.220 --> 00:02:42.700 а насправді бачите набір суверенних щі-островів усередині однієї компанії. 00:02:42.860 --> 00:02:47.160 Вони пов'язані брендом і іноді ідентифікацією, але ними не керують як єдиною системою. 00:02:47.320 --> 00:02:50.880 І якщо ви нічого більше не запам'ятаєте з цього розділу, запам'ятайте цей рядок. 00:02:51.040 --> 00:02:54.340 Немає глобального центру адміністрування щі, є лише ілюзія такого. 00:02:54.580 --> 00:02:57.940 Як тільки ця ілюзія розбивається, наступна проблема з'являється швидко. 00:02:58.120 --> 00:03:02.860 Більшість організацій реагують на це ручним управлінням для кожного орендаря окремо і називають це контролем. 00:03:02.860 --> 00:03:05.900 Чому ручне управління для кожного орендаря не працює в масштабах? 00:03:06.000 --> 00:03:09.000 Як тільки лідери бачать проблему меж, зазвичай відповідь звучить розсудливо. 00:03:09.160 --> 00:03:11.720 Вони кажуть, добре, ми будемо керувати кожним орендарем належним чином. 00:03:11.860 --> 00:03:15.020 Одна команда адміністраторів перевіряє налаштування тут, інша команда повторює їх там. 00:03:15.200 --> 00:03:17.920 Хтось веде електронну таблицю, хтось інший створює чек-лист. 00:03:18.020 --> 00:03:21.600 Керівна група збирається раз на місяць і запитує, чи йде впровадження за планом. 00:03:21.720 --> 00:03:23.580 На папері це виглядає дисципліновано. 00:03:23.580 --> 00:03:26.800 На практиці це ручне повторення, замасковане під управління. 00:03:26.920 --> 00:03:28.880 І причина, чому це не працює, проста. 00:03:29.040 --> 00:03:32.640 Повторення не забезпечує контроль, воно породжує варіативність з часом. 00:03:32.780 --> 00:03:35.480 Це стається тому, що кожен орендар рухається з різною швидкістю, 00:03:35.600 --> 00:03:37.760 кожен адміністратор трактує стандарти трохи по-різному, 00:03:37.860 --> 00:03:39.940 а локальні винятки починають здаватися виправданими, 00:03:40.040 --> 00:03:43.160 бо бізнесу потрібен прогрес зараз, а не після чергового центрального огляду. 00:03:43.300 --> 00:03:45.900 Ця стара модель виживає, бо вона виглядає помітною. 00:03:45.900 --> 00:03:49.700 Люди можуть вказати на закриті тікети, створені політики та змінені налаштування. 00:03:49.840 --> 00:03:54.060 Вони можуть показати активність, але видимі зусилля – це не те саме, що стабільна операційна модель. 00:03:54.180 --> 00:03:57.320 А з появою Coopilot цей розрив стає дуже дорогим за лічені миті. 00:03:57.480 --> 00:04:00.540 Система починає використовувати існуючі дозволи, існуючий доступ до контенту 00:04:00.540 --> 00:04:03.460 та існуючі прогалини в мітках, щойно користувачі починають надсилати запити. 00:04:03.620 --> 00:04:05.480 Ось що більшість людей випускає з уваги. 00:04:05.600 --> 00:04:07.620 Coopilot не чекає на зрілість управління. 00:04:07.620 --> 00:04:11.480 Він працює на дозволах, які ви вже маєте, гігієні контенту, яку ви вже толеруєте, 00:04:11.580 --> 00:04:13.920 і стані аудиту, який ви вже не змогли стандартизувати. 00:04:14.120 --> 00:04:16.780 Якщо один орендар упорядкував доступ, а інший видалив його, 00:04:16.920 --> 00:04:21.300 або якщо один орендар передає корисні дані аудиту, а інший ледве збирає достатньо для розслідування, 00:04:21.460 --> 00:04:23.300 Coopilot негайно виявить ці відмінності. 00:04:23.440 --> 00:04:26.400 Це відбувається не в теорії, це відбувається в процесі використання. 00:04:26.580 --> 00:04:29.940 Якщо один орендар переглянув широкий доступ до SharePoint, а інший вирішив, 00:04:29.940 --> 00:04:31.920 що цього достатньо, ще знайде прогалини. 00:04:32.060 --> 00:04:36.140 І на рівень глибше, кожен новий орендар примножує проблему не тому, що орендарі погані, 00:04:36.200 --> 00:04:38.480 а тому, що не керовані відмінності накопичуються. 00:04:38.640 --> 00:04:40.920 Одна нова пілотна команда додає локальний виняток, 00:04:41.020 --> 00:04:43.380 злиття привносить іншого орендаря з іншими мітками, 00:04:43.520 --> 00:04:45.820 а регіональний адміністратор копіює стару базу. 00:04:45.980 --> 00:04:47.960 Бізнес-підрозділ просить швидшого доступу, 00:04:48.020 --> 00:04:50.420 і жодне з цих рішень не виглядає критичним окремо. 00:04:50.420 --> 00:04:54.660 Зберіть їх разом протягом місяців, і ви отримаєте відхилення політик, доступу та впровадження. 00:04:54.800 --> 00:04:58.020 Результат – команда з управління, яка витрачає більше часу на узгодження відмінностей, 00:04:58.120 --> 00:04:59.140 ніж на запобігання ризикам. 00:04:59.320 --> 00:05:00.960 Саме тут ручний контроль, де є збій. 00:05:01.120 --> 00:05:03.340 Це здається безпечнішим, бо люди змінюють налаштування, 00:05:03.460 --> 00:05:05.040 але насправді це масштабує неузгодженість, 00:05:05.120 --> 00:05:07.540 бо кожна точка втручання – це шанс для орендарів розійтися. 00:05:07.680 --> 00:05:09.960 Результат – повільніше впровадження там, де потрібна швидкість, 00:05:09.960 --> 00:05:11.920 більше аудиторських перевірок, де потрібні докази, 00:05:11.980 --> 00:05:13.560 і більше переробки, де потрібні стандарти. 00:05:13.680 --> 00:05:15.760 Найгірше те, що це створює приховану вразливість там, 00:05:15.880 --> 00:05:17.520 де керівництво очікує гарантій безпеки. 00:05:17.640 --> 00:05:20.880 Я зрозумів це, коли перестав сприймати управління як одноразове налаштування. 00:05:21.040 --> 00:05:23.080 Це не так. Це більше схоже на розпад. 00:05:23.220 --> 00:05:25.740 Якщо ви очистили дозволи один раз, але ніякий контроль не стримує їх 00:05:25.740 --> 00:05:27.540 від повторного відхилення, вразливість повертається. 00:05:27.700 --> 00:05:29.520 Якщо ви визначили таксономію міток один раз, 00:05:29.520 --> 00:05:32.440 але орендарі застосовують її нерівномірно, базова лінія руйнується. 00:05:32.580 --> 00:05:35.000 Якщо ви схвалюєте коопайлот хвилями, не перевіряючи, 00:05:35.100 --> 00:05:37.720 чи діють базові засоби контролю, ви не масштабуєтеся безпечно. 00:05:37.880 --> 00:05:41.060 Ви просто розширюєтеся швидше, ніж ваше управління може за цим встигати. 00:05:41.220 --> 00:05:43.920 Отже, показник, який тут важливий, це відхилення доступу. 00:05:44.060 --> 00:05:46.360 Не просто, чи виправили ви щось, а як швидко дозволи, 00:05:46.420 --> 00:05:47.980 знову поширюється після виправлення. 00:05:48.140 --> 00:05:50.840 Це показує, чи тримається ваша модель, чи вона слабша є. 00:05:50.840 --> 00:05:53.140 Бо управління – це не проєкт, який можна завершити. 00:05:53.300 --> 00:05:55.600 Це проблема деградації, якою ви керуєте постійно. 00:05:55.700 --> 00:05:57.120 І коли масштабування ламає стару модель, 00:05:57.240 --> 00:05:59.920 більшість лідерів звертаються до найбільш знайомої відповіді ідентичності. 00:06:00.060 --> 00:06:02.880 Вони припускають, що якщо користувачі можуть легко переміщатися між орендарями, 00:06:02.980 --> 00:06:04.540 управління якось переміщатиметься разом з ними. 00:06:04.700 --> 00:06:07.880 Це не так. Чому ідентичність не вирішує питання управління? 00:06:08.060 --> 00:06:10.080 Саме тут багато програм роблять хибний крок, 00:06:10.200 --> 00:06:12.280 бо ідентичність здається простою відповіддю. 00:06:12.280 --> 00:06:14.960 Якщо користувачі можуть автентифікуватися між орендарями, 00:06:15.080 --> 00:06:17.940 якщо Entra підключена, а налаштування між орендарями встановлені, 00:06:18.040 --> 00:06:19.720 лідери вважають, що найважче вирішено. 00:06:19.880 --> 00:06:22.180 Доступ виглядає єдиним, вхід виглядає єдиним, 00:06:22.280 --> 00:06:24.220 архітектурна діаграма виглядає охайною, 00:06:24.340 --> 00:06:26.680 але управління Coopilot не стає єдиним лише тому, 00:06:26.820 --> 00:06:28.420 що ідентичність може переміщатися. 00:06:28.580 --> 00:06:31.360 Це припущення зазнає краху там, де ще реально працює. 00:06:31.500 --> 00:06:34.000 Coopilot обґрунтовує відповіді в межах контексту орендаря, 00:06:34.000 --> 00:06:37.160 де виконується запит, і власні настанови Microsoft чітко вказують на це. 00:06:37.300 --> 00:06:40.400 Microsoft 365 Coopilot працює в межах кордонів безпеки 00:06:40.400 --> 00:06:41.780 та відповідності орендаря Tenant 00:06:41.780 --> 00:06:44.880 і дотримується прав доступу користувача в контексті цього конкретного орендаря. 00:06:45.000 --> 00:06:46.780 Користувач може змінити контекст як гість, так, 00:06:46.880 --> 00:06:49.320 але Coopilot все одно обмежений одним орендарем одночасно. 00:06:49.460 --> 00:06:51.940 Він не об'єднує кілька орендарів в один інтелектуальний робочий простір 00:06:51.940 --> 00:06:53.180 для отримання єдиної відповіді. 00:06:53.300 --> 00:06:55.880 Отже, ідентичність може переміщуватися, а управління – ні. 00:06:55.880 --> 00:06:57.720 І як тільки ви розділяєте ці дві речі, 00:06:57.840 --> 00:07:00.720 багато мови керівників починає звучати небезпечно розмито. 00:07:00.840 --> 00:07:04.560 Підключені орендарі, спільна ідентичність, уніфікований досвід. 00:07:05.460 --> 00:07:08.160 Ці фрази можуть бути вірними в загальному напрямку для співпраці, 00:07:08.280 --> 00:07:10.380 але вони не означають, що застосування політик, 00:07:10.460 --> 00:07:13.080 обґрунтування даних, ведення журналів і перевірка контролю 00:07:13.080 --> 00:07:14.620 тепер працюють як єдина система. 00:07:14.800 --> 00:07:18.480 Цей розрив стає ще очевиднішим, коли ви дивитесь на багатоорендарний режим Coopilot Studio, 00:07:18.480 --> 00:07:21.180 оскільки попередня версія розповідає дуже конкретну історію. 00:07:21.280 --> 00:07:22.820 Так, багатоорендарне використання існує, 00:07:22.900 --> 00:07:25.600 і агент, розміщений в одному орендарі, може використовуватися з іншого, 00:07:25.680 --> 00:07:28.120 але автентифікація кінцевого користувача в багатоорендарному режимі 00:07:28.120 --> 00:07:29.740 поки що не підтримується у попередній версії. 00:07:29.880 --> 00:07:31.580 Гостьові користувачі не підтримуються. 00:07:31.740 --> 00:07:33.520 Користувацькі конектори не підтримуються. 00:07:33.720 --> 00:07:37.020 Стандартні конектори Graph та Microsoft 365 не підтримуються. 00:07:37.200 --> 00:07:38.720 Multi-Geo не підтримуються. 00:07:38.960 --> 00:07:41.220 Декілька аналітичних можливостей недоступні. 00:07:41.220 --> 00:07:43.780 Стенограми розмов також вимкнені в цьому режимі. 00:07:43.900 --> 00:07:46.180 Це незріла структура управління між орендарями. 00:07:46.340 --> 00:07:48.500 Це обмежена попередня версія з чіткими межами. 00:07:48.640 --> 00:07:50.400 І ці межі важливі, тому що вони руйнують історію, 00:07:50.520 --> 00:07:52.300 яку багато керівних команд розповідають самі собі. 00:07:52.440 --> 00:07:55.140 Вони чують багатоорендарний і припускають операційну зрілість. 00:07:55.320 --> 00:07:58.460 Їхні архітектори чують між орендарями і припускають симметрію політик. 00:07:58.640 --> 00:08:00.660 Їхні команди контролю чують той самий постачальник 00:08:00.660 --> 00:08:02.160 і припускають узгодженість аудиту. 00:08:02.160 --> 00:08:05.120 Потім починається впровадження і люди виявляють іншу поведінку, 00:08:05.240 --> 00:08:08.360 відсутні сигнали та незрочні прогалини в автентифікації та аналітиці. 00:08:08.500 --> 00:08:09.800 Уявіть, другий випадок. 00:08:09.960 --> 00:08:12.820 Глобальна компанія встановлює міжкорпоративні відносини між орендарями 00:08:12.820 --> 00:08:16.320 і припускає, що користувацький досвід природно пошириться на використання Co-Pilot. 00:08:16.500 --> 00:08:19.060 Очікування звучить розумно, спільна довіра до каталогів, 00:08:19.200 --> 00:08:21.360 легший доступ і загальні моделі ідентифікації. 00:08:21.540 --> 00:08:24.320 Але коли команди тестують реальні сценарії Co-Pilot та агентів, 00:08:24.400 --> 00:08:25.560 поведінка є нерівномірною. 00:08:25.560 --> 00:08:28.140 Деякі дані з'являються лише при перемиканні контекстів. 00:08:28.260 --> 00:08:30.120 Деякі очікувані коннектори недоступні. 00:08:30.260 --> 00:08:32.160 Деякі очікування щодо аудиту не збігаються з тим, 00:08:32.260 --> 00:08:34.200 що насправді пропонують функції попереднього перегляду. 00:08:34.340 --> 00:08:35.700 Керівництво все ще чує, як підключено, 00:08:35.840 --> 00:08:37.800 тоді як команда контролю починає знаходити винятки. 00:08:37.960 --> 00:08:39.520 Це не технічний граничний випадок. 00:08:39.640 --> 00:08:41.080 Це хибне розуміння управління. 00:08:41.200 --> 00:08:43.300 Тому що аудитори не перевіряють вашу історію архітектури, 00:08:43.380 --> 00:08:44.280 вони перевіряють докази. 00:08:44.280 --> 00:08:45.760 Вони запитують, де виконувалися запити, 00:08:45.880 --> 00:08:47.480 який орендар забезпечував виконання політики, 00:08:47.580 --> 00:08:48.260 які існують журнали, 00:08:48.340 --> 00:08:50.500 і чи були ваші елементи контролю дійсно порівняними в середовищах, 00:08:50.600 --> 00:08:51.700 які ви описували як пов'язані. 00:08:51.820 --> 00:08:54.540 Якщо ваша операційна модель трактувала ідентичність як управління, 00:08:54.620 --> 00:08:55.940 ви не матимете чіткої відповіді. 00:08:56.060 --> 00:08:58.000 Отже, якщо ви запам'ятаєте лише один рядок тут, 00:08:58.120 --> 00:08:58.740 хай це буде цей. 00:08:59.040 --> 00:09:00.040 Ідентичність між орендарями. 00:09:00.140 --> 00:09:01.420 Це не інтелект між орендарями. 00:09:01.860 --> 00:09:03.600 Ідентифікація допомагає користувачам увійти. 00:09:03.600 --> 00:09:06.180 Вона не скаже вам, чи поведінка CowPilot контролюється належним чином, 00:09:06.240 --> 00:09:07.100 чи вона правильно моніториться, 00:09:07.200 --> 00:09:08.380 і чи безпечно її масштабувати там, 00:09:08.500 --> 00:09:10.240 де ваше підприємство тепер має єдине середовище. 00:09:10.380 --> 00:09:11.360 І коли це стає зрозумілим, 00:09:11.440 --> 00:09:13.580 відповіддю не можуть бути нові підключення клієнтів Tenant. 00:09:13.720 --> 00:09:15.080 Це має бути архітектура. 00:09:15.260 --> 00:09:18.060 Модель управління, яка справді працює, хаб і спиці. 00:09:18.240 --> 00:09:20.140 Отже, як виглядає реальна модель управління, 00:09:20.260 --> 00:09:21.640 коли ваша платформа фрагментована, 00:09:21.800 --> 00:09:23.060 ідентифікація лише часткова, 00:09:23.060 --> 00:09:24.820 а межі клієнтів все ще мають значення. 00:09:24.980 --> 00:09:27.100 Вона виглядає як система, хаб і спиці. 00:09:27.280 --> 00:09:30.000 Я пропоную це не тому, що діаграма має гарний вигляд на слайді, 00:09:30.060 --> 00:09:32.420 а тому, що вона відповідає складним операційним умовам, 00:09:32.500 --> 00:09:33.820 з якими ви стикаєтеся зараз. 00:09:33.940 --> 00:09:35.500 Вам потрібне одне центральне місце, 00:09:35.600 --> 00:09:37.400 де рішення щодо управління розробляються, 00:09:37.540 --> 00:09:39.580 вимірюється та впроваджується як єдина система, 00:09:39.720 --> 00:09:42.280 а потім потрібні локальні команди для виконання цих рішень. 00:09:42.420 --> 00:09:45.240 Ці локальні команди повинні працювати у своїх межах, 00:09:45.240 --> 00:09:48.740 не вигадуючи власні правила щоразу, коли відчувають тиск. 00:09:48.820 --> 00:09:50.280 Ми повинні почати з хабу. 00:09:50.420 --> 00:09:52.020 Хаб – це не портал адміністратора, 00:09:52.160 --> 00:09:53.400 неприваблива панель керування 00:09:53.400 --> 00:09:55.360 і точно не героїчна центральна команда, 00:09:55.500 --> 00:09:57.520 що власноруч втручається в кожного клієнта, 00:09:57.660 --> 00:09:58.600 щоб очистити файли. 00:09:58.760 --> 00:10:01.340 Натомість хаб діє як вищий орган управління. 00:10:01.500 --> 00:10:03.400 Ця група відповідає за розробку політик, 00:10:03.500 --> 00:10:06.980 базові показники аудиту, стандарти міток і критерії впровадження. 00:10:07.200 --> 00:10:10.480 Саме вони вирішують, що насправді означає готовність до Co-Pilot, 00:10:10.480 --> 00:10:12.300 які докази вважаються підтвердженням 00:10:12.300 --> 00:10:14.600 і як швидко потрібно закрити прогалину в безпеці. 00:10:14.740 --> 00:10:16.620 Цей сув змінює всю розмову. 00:10:16.800 --> 00:10:19.540 Завдяки цій структурі «глобальний» перестає бути словом 00:10:19.540 --> 00:10:20.980 для одного чарівного екрана 00:10:20.980 --> 00:10:23.520 і починає означати єдину систему управління. 00:10:23.660 --> 00:10:25.940 Ви отримуєте один стандарт для засобів контролю Perview, 00:10:26.060 --> 00:10:27.780 один стандарт для збору аудиторських даних 00:10:27.780 --> 00:10:29.640 і один стандарт для міток конфіденційності. 00:10:29.760 --> 00:10:31.460 Існує чіткий поріг того, що має бути виконано, 00:10:31.460 --> 00:10:32.740 перш ніж будь-якому окремому клієнту 00:10:32.740 --> 00:10:34.040 дозволять розширити доступ до Co-Pilot 00:10:34.040 --> 00:10:35.280 для більшої кількості користувачів. 00:10:35.380 --> 00:10:36.660 Потім вам потрібні спиці. 00:10:36.840 --> 00:10:38.820 Спиці – це ваші локальні виконавчі команди, 00:10:38.900 --> 00:10:40.080 які беруть ці базові вимоги 00:10:40.080 --> 00:10:41.940 та застосовують їх до свого середовища. 00:10:42.120 --> 00:10:43.600 Саме вони проводять виправлення, 00:10:43.740 --> 00:10:44.700 перевіряють журнали 00:10:44.700 --> 00:10:46.760 та переглядають дозволи на широкий доступ. 00:10:46.940 --> 00:10:48.760 Однак вони виконують всю цю роботу 00:10:48.760 --> 00:10:50.440 в межах дуже вузького простору, 00:10:50.540 --> 00:10:51.400 а не як завгодно. 00:10:51.600 --> 00:10:53.960 Якщо локальна команда має відхилитися від плану, 00:10:53.960 --> 00:10:55.840 існує офіційний шлях для винятків. 00:10:55.960 --> 00:10:57.420 І якщо вони хочуть рухатися швидше, 00:10:57.500 --> 00:10:59.140 вони все одно повинні спочатку відповідати 00:10:59.140 --> 00:11:00.220 спільним вимогам контролю. 00:11:00.360 --> 00:11:02.540 Коли виникають регіональні або юридичні розбіжності, 00:11:02.620 --> 00:11:04.340 ці питання документуються та затверджуються, 00:11:04.480 --> 00:11:05.800 замість того, щоб тихо поглинатися 00:11:05.800 --> 00:11:07.020 локальними обхідними шляхами, 00:11:07.120 --> 00:11:08.060 про які ніхто не знає. 00:11:08.180 --> 00:11:09.300 Ця структура є важливою, 00:11:09.360 --> 00:11:10.980 оскільки повністю централізовані моделі 00:11:10.980 --> 00:11:12.820 зазвичай не справляються з локальними деталями, 00:11:12.820 --> 00:11:14.080 тоді як суто локальні моделі 00:11:14.080 --> 00:11:15.700 майже одразу стають непослідовними. 00:11:15.840 --> 00:11:17.300 Модель «Концентратор і спиці» 00:11:17.300 --> 00:11:19.020 дозволяє уникнути обох цих невдач. 00:11:19.140 --> 00:11:21.220 Концентратор забезпечує потрібну послідовність, 00:11:21.300 --> 00:11:22.820 а спиці – швидкість виконання там, 00:11:22.940 --> 00:11:24.320 де безпосередньо ведеться робота. 00:11:24.460 --> 00:11:25.760 Перейдемо до конкретики. 00:11:25.920 --> 00:11:28.240 У центрі ви визначаєте мінімальний набір засобів контролю, 00:11:28.320 --> 00:11:29.840 які кожен орендар повинен запустити, 00:11:29.960 --> 00:11:31.600 перш ніж коупайлат зможе розширюватися. 00:11:31.600 --> 00:11:34.620 Ви чітко визначаєте, які події аудиту очікуєте бачити 00:11:34.620 --> 00:11:36.300 і як часто ви їх переглядатимете. 00:11:36.300 --> 00:11:38.660 Ви також створюєте спільну таксономію міток 00:11:38.660 --> 00:11:40.200 для конфіденційного контенту, 00:11:40.320 --> 00:11:42.780 щоб одна мітка не означала п'ять різних речей 00:11:42.780 --> 00:11:44.180 у п'яти різних орендарів. 00:11:44.320 --> 00:11:45.900 Ви встановлюєте ритм перевірок, 00:11:46.040 --> 00:11:48.660 можливо, щомісяця для загального стану безпеки 00:11:48.660 --> 00:11:51.500 та частіше там, де розгортання відбувається зараз. 00:11:51.640 --> 00:11:53.560 На рівні спиць ваша команда адаптує 00:11:53.560 --> 00:11:56.560 ці високорівневі стандарти до реалій конкретного орендаря. 00:11:56.720 --> 00:11:59.100 Вони виявляють сайти з відкритим широким доступом 00:11:59.100 --> 00:12:01.460 і підрозділи, які відстають із маркуванням. 00:12:01.460 --> 00:12:03.580 Вони перевіряють, чи активовано аудит 00:12:03.580 --> 00:12:05.900 і чи бачить служба безпеки відповідні записи. 00:12:06.020 --> 00:12:07.840 Вони шукають локальних адміністраторів, 00:12:07.920 --> 00:12:10.260 які могли ввести винятки без офіційного погодження 00:12:10.260 --> 00:12:12.680 і вирішують, чи може пілотна група розширюватися, 00:12:12.780 --> 00:12:15.040 чи потрібно зупинитися і спочатку все виправити. 00:12:15.200 --> 00:12:17.700 І ось головне правило, адже без нього ця модель 00:12:17.700 --> 00:12:19.900 лише порада, а не реальне управління. 00:12:20.080 --> 00:12:22.040 Жодне розгортання Coopilot не проводиться 00:12:22.040 --> 00:12:23.740 без підтвердженого журналу аудиту, 00:12:23.880 --> 00:12:25.740 завершеного сканування на надмірний доступ 00:12:25.740 --> 00:12:27.440 та базового рівня покриття мітками. 00:12:27.620 --> 00:12:29.680 Я не кажу про те, що це має бути лише в планах 00:12:29.680 --> 00:12:30.820 чи на стадії обговорення. 00:12:30.980 --> 00:12:32.260 Це має бути підтверджено. 00:12:32.440 --> 00:12:34.720 Якщо орендар не може довести виконання цих трьох умов, 00:12:34.820 --> 00:12:36.020 розгортання призупиняється. 00:12:36.200 --> 00:12:37.980 Це може здатися суворим, доки ви не порівняєте 00:12:37.980 --> 00:12:39.920 це з величезними витратами на виправлення наслідків, 00:12:40.020 --> 00:12:41.620 коли користувачі знайдуть конфіденційні дані, 00:12:41.700 --> 00:12:43.240 які ви не планували відкривати через щі. 00:12:43.360 --> 00:12:45.200 Якщо поглянути на це так, то ці правила – 00:12:45.200 --> 00:12:46.800 просто елементарний здоровий глузд. 00:12:46.800 --> 00:12:49.000 Ще одна причина ефективності цієї моделі – 00:12:49.000 --> 00:12:49.680 своєчасність. 00:12:49.820 --> 00:12:51.580 Чим довше ви чекаєте, щоб це налаштувати, 00:12:51.700 --> 00:12:53.820 тим більше технічного боргу накопичуєте на майбутнє. 00:12:53.940 --> 00:12:56.580 Кожен орендар, що впроваджує систему безбазового рівня, 00:12:56.720 --> 00:12:59.240 створює величезний список винятків і відсутніх доказів, 00:12:59.320 --> 00:13:01.120 які вашій команді доведеться розгрібати. 00:13:01.280 --> 00:13:03.680 Керівники часто вважають, що управління дозріє 00:13:03.680 --> 00:13:05.860 після впровадження, але у світі Co-Pilot 00:13:05.860 --> 00:13:08.400 з багатьма орендарями ця послідовність є хибною. 00:13:08.400 --> 00:13:10.120 Управління має випереджати розгортання, 00:13:10.280 --> 00:13:11.820 інакше впровадження створить більше боргу, 00:13:11.940 --> 00:13:13.420 ніж ваші команди зможуть опрацювати. 00:13:13.600 --> 00:13:15.440 Якщо ви керуєте цим на рівні підприємства, 00:13:15.600 --> 00:13:16.820 ваш наступний крок очевидний. 00:13:17.020 --> 00:13:19.860 Створіть хаб прямо зараз і визначте цей базовий рівень сьогодні. 00:13:20.000 --> 00:13:21.920 Призначте свої споки та негайно зафіксуйте 00:13:21.920 --> 00:13:24.120 процес обробки винятків у письмовому вигляді. 00:13:24.260 --> 00:13:26.440 Ви маєте зробити так, щоб глобальний означав, 00:13:26.440 --> 00:13:29.480 що ваші рішення та етапи впровадження працюють як єдина система, 00:13:29.480 --> 00:13:31.020 навіть якщо самі орендарі – ні. 00:13:31.180 --> 00:13:33.600 Модель має значення лише тоді, коли вона дійсно змінює те, 00:13:33.720 --> 00:13:35.100 що буде застосовано завтра вранці, 00:13:35.300 --> 00:13:37.620 що керівникам слід вимірювати перед масштабуванням. 00:13:37.760 --> 00:13:39.640 Модель управління тримається купи лише тоді, 00:13:39.740 --> 00:13:41.660 коли вона надає показники, зрозумілі всім. 00:13:41.820 --> 00:13:43.440 Інакше кожен орендар буде стверджувати, 00:13:43.620 --> 00:13:45.560 що досягає прогресу своєю власною мовою, 00:13:45.560 --> 00:13:48.400 а керівництво отримуватиме звіти, не маючи реального контролю. 00:13:48.520 --> 00:13:50.220 Перш ніж масштабувати Coopilot далі, 00:13:50.220 --> 00:13:51.820 вам потрібен невеликий набір метрик, 00:13:51.900 --> 00:13:54.740 які покажуть, чи працює архітектура так, як ви очікуєте. 00:13:54.880 --> 00:13:56.600 Рівні активності не скажуть вам правди, 00:13:56.680 --> 00:13:58.960 а показники впровадження точно не покажуть ризиків. 00:13:59.080 --> 00:14:01.660 Вам варто почати зі зменшення надмірного надання доступу. 00:14:01.780 --> 00:14:03.800 Це все ще одна з найбільш очевидних ознак того, 00:14:03.980 --> 00:14:06.160 що ваше середовище стає безпечнішим для щі. 00:14:06.160 --> 00:14:08.360 Вам потрібно переглянути широкі групи доступу, 00:14:08.460 --> 00:14:10.400 відкриті сайти SharePoint і старі дозволи, 00:14:10.500 --> 00:14:12.940 що надають значно більше доступу, ніж потрібно бізнесу. 00:14:12.940 --> 00:14:15.020 Мета тут не в тому, щоб досягти ідеальної цифри, 00:14:15.080 --> 00:14:16.740 а в тому, щоб довести, що ваша вразливість 00:14:16.740 --> 00:14:18.780 знижується до того, як зросте охоплення Coopilot. 00:14:18.960 --> 00:14:21.160 Якщо ці дві лінії рухаються в протилежних напрямках, 00:14:21.300 --> 00:14:22.680 ви розширюєтеся набагато швидше, 00:14:22.780 --> 00:14:24.240 ніж виправляєте основні проблеми. 00:14:24.400 --> 00:14:25.820 Друга метрика, яка вам потрібна, 00:14:25.900 --> 00:14:27.320 це охоплення з постережуваністю. 00:14:27.320 --> 00:14:28.520 Чи можете ви насправді бачити, 00:14:28.660 --> 00:14:30.400 що робить Coopilot у всіх ваших орендарях так, 00:14:30.520 --> 00:14:32.220 щоб це дозволяло провести реальне розслідування? 00:14:32.220 --> 00:14:34.280 Більшість досліджень вказують на Microsoft Перв'ю 00:14:34.280 --> 00:14:36.260 як на основне місце зберігання ключових записів, 00:14:36.380 --> 00:14:37.660 таких як взаємодія з Coopilot, 00:14:37.820 --> 00:14:39.860 але це припускає, що аудиту увімкнено всюди. 00:14:40.020 --> 00:14:41.900 Охоплення – це не те, що можна вважати таким, 00:14:42.040 --> 00:14:43.100 що працює саме по собі. 00:14:43.220 --> 00:14:45.120 Вам потрібно точно знати, у яких орендарях 00:14:45.120 --> 00:14:46.500 активовано збір даних аудиту, 00:14:46.500 --> 00:14:48.840 а які все ще залишають вам лише часткову видимість. 00:14:48.980 --> 00:14:50.260 Якщо у вас немає логів, 00:14:50.360 --> 00:14:52.320 у вас немає управління та підзвітності. 00:14:52.460 --> 00:14:54.520 Це звучить різко, тому що так і має бути. 00:14:54.520 --> 00:14:56.560 Якщо орендар не може надати корисні докази того, 00:14:56.720 --> 00:14:58.360 що відбувається, такий орендар не готовий 00:14:58.360 --> 00:14:59.420 до безпечного масштабування. 00:14:59.580 --> 00:15:01.580 Ви не можете керувати тим, що не можете перевірити, 00:15:01.680 --> 00:15:03.320 і ви точно не зможете захистити свої дії, 00:15:03.460 --> 00:15:04.740 якщо щось піде не так пізніше. 00:15:04.900 --> 00:15:07.020 Третя метрика – це час впровадження політики 00:15:07.020 --> 00:15:07.960 для всіх орендарів. 00:15:07.960 --> 00:15:09.400 Тут керівництво дізнається, 00:15:09.520 --> 00:15:12.440 чи є модель HubSpock реальною чи лише декоративною. 00:15:12.560 --> 00:15:14.620 Центральне рішення не означає абсолютно нічого, 00:15:14.720 --> 00:15:16.680 якщо один орендар впроваджує його цього тижня, 00:15:16.680 --> 00:15:18.600 а інший чекає місяць, щоб подумати про це. 00:15:18.760 --> 00:15:20.940 Вам слід вимірювати час від затвердження політики 00:15:20.940 --> 00:15:22.460 до її ефективного застосування 00:15:22.460 --> 00:15:23.840 в кожному окремому орендарі. 00:15:24.000 --> 00:15:26.400 Я говорю не про час на оголошення чи документування, 00:15:26.480 --> 00:15:28.340 а про час до моменту реального запуску. 00:15:28.500 --> 00:15:30.400 Для щі програми, що розвивається так швидко, 00:15:30.400 --> 00:15:32.600 така затримка є просто іншим словом для ризику. 00:15:32.760 --> 00:15:34.600 Практична ціль для більшості організацій 00:15:34.600 --> 00:15:36.860 менше 72 годин для стандартних змін. 00:15:37.020 --> 00:15:38.440 Якщо ваш цикл значно довший, 00:15:38.540 --> 00:15:40.320 у вас ще немає масштабованої моделі. 00:15:40.440 --> 00:15:42.140 У вас просто є проблема з координацією, 00:15:42.140 --> 00:15:43.140 яку потрібно вирішити. 00:15:43.340 --> 00:15:45.940 Далі вам потрібно звернути увагу на коефіцієнт охоплення мітками. 00:15:46.120 --> 00:15:48.140 Не дозволяйте цьому перетворитися на показник для галочки, 00:15:48.260 --> 00:15:50.460 де один орендар має високі результати, а інші відстають. 00:15:50.660 --> 00:15:52.500 Важливо те, чи ваш конфіденційний контент 00:15:52.500 --> 00:15:53.960 позначений достатньо послідовно, 00:15:53.960 --> 00:15:56.860 щоб робота Co-Pilot не залежала від здогадок користувачів. 00:15:56.980 --> 00:15:58.400 Ви не шукаєте досконалості, 00:15:58.480 --> 00:16:00.420 але шукаєте порівнянні рівень контролю 00:16:00.420 --> 00:16:02.240 для кожного орендаря в організації. 00:16:02.240 --> 00:16:05.260 Нарешті, вам потрібно відстежувати рівень відхилення доступу. 00:16:05.420 --> 00:16:06.460 Цей показник демонструє, 00:16:06.560 --> 00:16:08.860 чи дають результати ваші заходи з очищення з часом. 00:16:09.020 --> 00:16:10.520 Після завершення проєкту з виправлення, 00:16:10.640 --> 00:16:13.020 як швидко ці права доступу починають поширюватися знову. 00:16:13.120 --> 00:16:14.680 Як часто широкі групи користувачів 00:16:14.680 --> 00:16:15.880 знову проникають у систему. 00:16:16.060 --> 00:16:17.480 Багато команд усвідомлюють це запізно, 00:16:17.560 --> 00:16:18.600 бо виміряли результат один раз 00:16:18.600 --> 00:16:20.260 і вирішили, що проблему вирішено назавжди. 00:16:20.400 --> 00:16:21.020 Це не так. 00:16:21.200 --> 00:16:22.140 Єдиний важливий показник, 00:16:22.280 --> 00:16:23.800 як швидко система починає сповзати, 00:16:23.800 --> 00:16:25.340 коли ви перестаєте за нею стежити. 00:16:25.500 --> 00:16:27.220 Це і є ваша робоча панель керування. 00:16:27.400 --> 00:16:29.500 Вам потрібно відстежувати зменшення надмірного доступу, 00:16:29.600 --> 00:16:30.400 рівень спостережності, 00:16:30.520 --> 00:16:31.640 швидкість впровадження політик, 00:16:31.720 --> 00:16:33.300 охоплення мітками та відхилення доступу. 00:16:33.460 --> 00:16:35.460 Ритм вашої звітності має таке ж значення, 00:16:35.660 --> 00:16:36.440 як і самі цифри. 00:16:36.580 --> 00:16:39.260 Центральний офіс має відповідати за звітність для керівництва, 00:16:39.380 --> 00:16:41.840 оскільки йому потрібен єдиний огляд загального стану. 00:16:41.980 --> 00:16:44.480 Тим часом підрозділи мають відповідати за виправлення, 00:16:44.580 --> 00:16:47.120 бо реальна робота має відбуватися на рівні орендарів. 00:16:53.800 --> 00:16:56.300 Він чекає на вашу наступну нараду чи семінар із управління. 00:16:56.420 --> 00:16:57.840 Він уже діє в кожному орендарі, 00:16:57.940 --> 00:16:59.160 де Coopilot бачить саме те, 00:16:59.280 --> 00:17:01.440 що дозволяють ваші поточні налаштування контролю. 00:17:01.580 --> 00:17:03.820 Дві моделі поведінки, які ігнорують лідери. 00:17:03.980 --> 00:17:05.740 Я постійно бачу два спеціфічні підходи, 00:17:05.800 --> 00:17:06.900 і обидва виникають через те, 00:17:07.020 --> 00:17:09.480 що керівники ставляться до Coopilot як до запуску софту, 00:17:09.560 --> 00:17:11.180 а не як до серйозного заходу з контролю. 00:17:11.300 --> 00:17:14.140 Перша модель виникає, коли організація впроваджує Coopilot, 00:17:14.140 --> 00:17:15.880 не встановивши базових рівнів контролю 00:17:15.880 --> 00:17:17.540 або не перевіривши доступ до SharePoint. 00:17:17.700 --> 00:17:19.900 У перший день впровадження виглядає ідеально. 00:17:20.120 --> 00:17:22.140 Ліцензії призначені, користувачі в захваті, 00:17:22.220 --> 00:17:24.820 а внутрішні комунікації зосереджені лише на продуктивності. 00:17:24.940 --> 00:17:27.280 Але потім звичайні запити починають видавати матеріали, 00:17:27.380 --> 00:17:29.000 які технічно були доступні весь цей час, 00:17:29.120 --> 00:17:31.840 проте фактично залишалися непомітними для пересічного працівника. 00:17:32.060 --> 00:17:33.680 До появищі ніхто не витрачав свій день, 00:17:33.780 --> 00:17:35.720 переглядаючи старі сайти, застарілі папки 00:17:35.720 --> 00:17:37.460 чи успадковані дозволи, щоб знайти те, 00:17:37.600 --> 00:17:38.680 чого вони не повинні бачити. 00:17:38.680 --> 00:17:40.280 Але тепер їм і не потрібно. 00:17:40.420 --> 00:17:42.100 Користувач ставить просте запитання, 00:17:42.220 --> 00:17:44.120 отримує резюме і з'являється файл. 00:17:44.220 --> 00:17:46.040 Можливо, це конфіденційний контент HR, 00:17:46.200 --> 00:17:48.220 фінансові матеріали або інформація про угоди, 00:17:48.280 --> 00:17:50.100 які мали залишатися у дуже вузькому колі. 00:17:50.220 --> 00:17:52.040 Це не було зломом, не було шкідливого пези 00:17:52.040 --> 00:17:54.220 чи порушенням меж безпеки у традиційному розумінні. 00:17:54.400 --> 00:17:56.820 Система просто використала ті дозволи та стан контенту, 00:17:56.880 --> 00:17:58.380 які вже були налаштовані в орендарі. 00:17:58.520 --> 00:18:01.380 Це той момент, коли багато команд нарешті розуміють проблему. 00:18:01.380 --> 00:18:02.980 Ще не створив цю вразливість. 00:18:03.140 --> 00:18:05.540 Він просто прибрав перешкоди, які її приховували. 00:18:05.700 --> 00:18:07.100 Коли це стається в одному орендарі, 00:18:07.200 --> 00:18:09.500 довіра керівництва зазвичай падає в усій організації, 00:18:09.620 --> 00:18:11.180 оскільки ніхто не може впевнено сказати, 00:18:11.280 --> 00:18:13.200 де наступного разу виникне такий самий сценарій. 00:18:13.340 --> 00:18:14.660 Інцидент може виглядати локальним, 00:18:14.760 --> 00:18:17.180 але шкода для довіри завдається в масштабах усієї компанії. 00:18:17.380 --> 00:18:19.860 Другий шаблон тихіший, але він так само небезпечний. 00:18:20.000 --> 00:18:22.480 Компанія налаштовує ідентифікаційні зв'язки між орендарями, 00:18:22.480 --> 00:18:24.440 чує, що багато орендарні сценарії можливі 00:18:24.440 --> 00:18:26.200 і припускає, що їхня операційна модель 00:18:26.200 --> 00:18:27.840 достатньо зріла для широкого впровадження. 00:18:27.980 --> 00:18:30.360 На слайдах презентації це виглядає як надійний план. 00:18:30.540 --> 00:18:32.780 Насправді ж операційна діяльність стає безладною. 00:18:32.940 --> 00:18:35.100 Одна команда очікує безперебійної роботи Coopilot 00:18:35.100 --> 00:18:37.880 у кожному підключеному середовищі, інша – порівнянної видимості, 00:18:37.960 --> 00:18:39.940 а третя припускає, що ті самі елементи керування 00:18:39.940 --> 00:18:41.460 будуть слідувати за користувачем всюди. 00:18:41.460 --> 00:18:43.220 Потім реальне використання починає виявляти 00:18:43.220 --> 00:18:45.220 нерівномірну поведінку, прогалений в автентифікації 00:18:45.220 --> 00:18:47.220 та слабкі місця в тому, що насправді можна виміряти. 00:18:47.360 --> 00:18:49.500 Проблема не в тому, що ці команди були недбалими. 00:18:49.680 --> 00:18:51.080 Справжня проблема полягає в тому, що вони 00:18:51.080 --> 00:18:53.100 ототожнили можливість підключення з гарантією безпеки. 00:18:53.220 --> 00:18:54.980 Це припущення створює фальшиву історію 00:18:54.980 --> 00:18:55.980 про відповідність вимогам. 00:18:56.120 --> 00:18:59.660 Керівництво чує слово «підключено» і вважає, що організація готова. 00:18:59.660 --> 00:19:01.540 Через місяці перевірки контролю виявляють, 00:19:01.540 --> 00:19:03.420 що поведінка, докази та виконання правил 00:19:03.420 --> 00:19:06.140 відрізнялися набагато більше, ніж хтось хотів визнати на початку. 00:19:06.300 --> 00:19:08.140 Тепер порівняйте це з кращим шаблоном. 00:19:08.340 --> 00:19:10.180 Інша організація вирішує сповільнитися, 00:19:10.320 --> 00:19:11.340 перш ніж масштабуватися. 00:19:11.500 --> 00:19:13.440 Вони спочатку встановлюють базовий рівень міток, 00:19:13.540 --> 00:19:16.040 перевіряють широкий доступ і підтверджують видимість аудиту, 00:19:16.160 --> 00:19:17.320 перш ніж робити щось інше. 00:19:17.480 --> 00:19:19.420 Вони розширюють Coopilot хвилями не тому, 00:19:19.420 --> 00:19:21.560 що бояться впровадження, а тому, що хочуть, 00:19:21.700 --> 00:19:23.440 щоб кожна хвиля надавала корисні докази 00:19:23.440 --> 00:19:24.480 до початку наступної. 00:19:24.600 --> 00:19:27.400 Така організація зазвичай рухається швидше в довгостроковій перспективі, 00:19:27.460 --> 00:19:29.060 тому що їм не потрібно постійно зупинятися, 00:19:29.180 --> 00:19:31.320 щоб пояснювати сюрпризи, очищати розкритий контент 00:19:31.320 --> 00:19:34.060 або сперечатися про те, що насправді мало означати «керований». 00:19:34.060 --> 00:19:36.260 Це перевага, яку більшість лідерів ігнорують. 00:19:36.400 --> 00:19:38.580 Належне управління не блокує ваше впровадження. 00:19:38.760 --> 00:19:40.560 Це усуває гальмування процесу впровадження 00:19:40.560 --> 00:19:41.960 після завершення першої хвилі. 00:19:42.060 --> 00:19:44.160 Пастка полягає не в самому прийнятті технології. 00:19:44.160 --> 00:19:46.180 Пастка – це некероване впровадження в орендарях, 00:19:46.280 --> 00:19:47.680 які здаються пов'язаними здалеку, 00:19:47.740 --> 00:19:50.100 але поводяться зовсім інакше, якщо придивитися ближче. 00:19:50.240 --> 00:19:51.920 Рішення, яке вам потрібно прийняти, 00:19:52.020 --> 00:19:53.080 насправді дуже просте. 00:19:53.240 --> 00:19:55.080 Вам слід негайно перейти до федеративної моделі 00:19:55.080 --> 00:19:57.020 управління ЩІ за принципом «Хаб» і «Споки» 00:19:57.020 --> 00:19:59.240 і перестати плутати поокреме налаштування орендарів 00:19:59.240 --> 00:20:00.160 із реальним контролем. 00:20:00.280 --> 00:20:02.000 Вам варто призупинити розширення Coopilot 00:20:02.000 --> 00:20:03.960 у будь-якому орендарі, який не може підтвердити 00:20:03.960 --> 00:20:05.800 ведення логів, перевірку надмірного доступу 00:20:14.160 --> 00:20:16.020 середовищі, підписуйтесь на мене, Мірко Петерса, 00:20:16.100 --> 00:20:17.860 у LinkedIn і поділіться цим зі своєю командою, 00:20:17.980 --> 00:20:19.580 якщо ви зараз стикаєтесь із цими проблемами.