WEBVTT

00:00:00.000 --> 00:00:02.880
צוות המנהיגות שלכם חושב שזו שאלת פריסה

00:00:02.880 --> 00:00:05.560
היא לא, זוהי החלטת ממשל עם מסלול תנועה קצר מאוד

00:00:05.560 --> 00:00:08.820
והלחץ גובר מכיוון שקופילות לא מחכה לניקוי המדיניות שלכם

00:00:08.820 --> 00:00:10.940
או לאישור הפנימי שלכם כדי להדביק את הפער

00:00:10.940 --> 00:00:13.120
ברגע שהוא מתחיל לפעול בסביבה שלכם

00:00:13.120 --> 00:00:15.320
הוא משתמש במערכת בדיוק כפי שהוא מוצא אותה

00:00:15.320 --> 00:00:16.180
וכאן זה נשבר

00:00:16.180 --> 00:00:19.200
רוב הארגונים עם מספר דיירים של Microsoft 365

00:00:19.200 --> 00:00:22.220
מניחים שיש להם סיפור בקרה אחד של בינה מלאכותית

00:00:22.220 --> 00:00:25.140
בעיקר משום שהם קונים מספק אחד ומנהלים נכס זהות אחד

00:00:25.140 --> 00:00:27.540
הם שומעים נרטיב אסטרטגי אחד ממייקרוסופט

00:00:27.540 --> 00:00:29.480
ומניחים שהמציאות תואמת את המצגת

00:00:29.480 --> 00:00:31.220
אבל תנאי ההפעלה שונים מאוד

00:00:31.220 --> 00:00:32.940
בינה מלאכותית פועלת בגבולות הדיירים

00:00:32.940 --> 00:00:34.840
בעוד שהסיכון נע ממש על פני כל אחד מהם

00:00:34.840 --> 00:00:37.680
אז השאלה היא לא האם נוכל להפעיל את קופיילוט בכל מקום

00:00:37.680 --> 00:00:39.580
השאלה האמיתית היא איזה מודל ממשל

00:00:39.580 --> 00:00:42.740
מאפשר לנו להתרחב בביטחה בין דיירים שמתנהגים באופן עצמאי

00:00:42.740 --> 00:00:44.220
לפני שנגיע למודל הזה

00:00:44.220 --> 00:00:45.740
עלינו להגדיר את המלכודת

00:00:45.740 --> 00:00:49.200
המלכודת יהיה בינה מלאכותית ריבוניים בתוך ארגון אחד

00:00:49.200 --> 00:00:51.840
ברוב הארגונים האשליה מתחילה בהיכרות

00:00:51.840 --> 00:00:53.600
אתם פותחים את מייקרוסופט 365

00:00:53.600 --> 00:00:54.980
אתם פותחים את פורוו

00:00:54.980 --> 00:00:55.960
אתם פותחים את אינטרה

00:00:55.960 --> 00:00:57.400
אתם פותחים את פאוור פלטפורם

00:00:57.400 --> 00:00:58.240
המיתוג זהה

00:00:58.240 --> 00:01:00.060
שפת הניהול מרגישה מחוברת

00:01:00.060 --> 00:01:02.700
והתנועה המסחרית מספרת סיפור נקי מאוד

00:01:02.700 --> 00:01:04.080
מערכת אקולוגית אחת

00:01:04.080 --> 00:01:05.060
אסטרטגיה אחת

00:01:05.060 --> 00:01:05.740
כיוון אחד

00:01:05.740 --> 00:01:08.100
אבל מודל הבקרה שמתחת אינו דבר אחד

00:01:08.100 --> 00:01:09.540
וזה חשוב יותר מהמיתוג

00:01:09.540 --> 00:01:10.860
בהתבסס על המחקר כאן

00:01:10.860 --> 00:01:12.240
אין מרכז ניהול גלובלי אחד

00:01:12.240 --> 00:01:13.160
של בינה מלאכותית

00:01:13.160 --> 00:01:14.160
עם שוויון תכונות מלא

00:01:14.160 --> 00:01:15.960
שנותן לכם מקום אחד לשלוט בקופילות

00:01:15.960 --> 00:01:17.460
בצורה נקייה על פני כל הדיירים

00:01:17.460 --> 00:01:18.680
מה שיש לכם בפועל

00:01:18.680 --> 00:01:20.040
הוא מחסנית בקרה מקוטעת

00:01:20.040 --> 00:01:21.680
חלקים מהממשל נמצאים בפרוויו

00:01:21.680 --> 00:01:23.740
חלקים אחרים נמצאים במרכזי ניהול

00:01:23.740 --> 00:01:26.180
והשאר מפוזרים על פני אינטרה ופאוור פלטפורם

00:01:26.180 --> 00:01:28.740
חלק מהתכונות צצות בשכבות הבקרה החדשות יותר

00:01:28.740 --> 00:01:29.740
של מייקרוסופט

00:01:29.740 --> 00:01:31.440
אך הן עדיין לא יוצרות מישור גלובלי

00:01:31.440 --> 00:01:33.540
בוגר אחד שלם על פני כל גבול דיירים

00:01:33.540 --> 00:01:35.400
פער זה יוצר ביטחון כוזב

00:01:35.400 --> 00:01:37.540
מנהיגים בוחנים את המערכת האקולוגית

00:01:37.540 --> 00:01:38.580
ומניחים ריכוזיות

00:01:38.580 --> 00:01:40.680
בעוד שצוותים בוחנים זהות משותפת

00:01:40.680 --> 00:01:41.500
ומניחים עקביות

00:01:41.500 --> 00:01:42.900
רכש רואה הסכם אחד

00:01:42.900 --> 00:01:44.380
ומניח מודל תפעולי אחד

00:01:44.380 --> 00:01:46.880
אך כל דייר עדיין נושא גבול מדיניות משלו

00:01:46.880 --> 00:01:48.020
וגבול נתונים משלו

00:01:48.020 --> 00:01:49.600
מה שאומר שבפועל כל אחד

00:01:49.600 --> 00:01:50.860
נושא גרסה משלו לאמת

00:01:50.860 --> 00:01:52.620
אז מה שקורה בפועל הוא פשוט

00:01:52.620 --> 00:01:55.020
אין לכם סביבת בינה מלאכותית ארגונית אחת

00:01:55.020 --> 00:01:56.920
יש לכם מספר סביבות בינה מלאכותית

00:01:56.920 --> 00:01:58.240
ששייכות במקרה לאותו ארגון

00:01:58.240 --> 00:01:59.900
זוהי תמונת סיכון שונה מאוד

00:01:59.900 --> 00:02:02.580
לדייר אחד עשויה להיות כיסוי תחום עיסוק חזק יותר

00:02:02.580 --> 00:02:04.600
בעוד שלאחר יש אימוץ תוויות חלש יותר

00:02:04.600 --> 00:02:05.800
או קליטת ביקורת לא שלמה

00:02:05.800 --> 00:02:06.880
מרמת הדירקטוריון

00:02:06.880 --> 00:02:08.940
זה עדיין עשוי להיראות כמו תוכנית אחת

00:02:08.940 --> 00:02:10.720
אבל מנקודת מבט של ביקורת או אירוע

00:02:10.720 --> 00:02:11.920
זו בכלל לא תוכנית אחת

00:02:11.920 --> 00:02:13.960
זוהי אוסף של תנאי הפעלה נפרדים

00:02:13.960 --> 00:02:15.760
וברגע שהתנאים האלה משתנים

00:02:15.760 --> 00:02:17.120
הדיווח מתחיל לשקר

00:02:17.120 --> 00:02:18.900
לא במכוון מבחינה מבנית

00:02:18.900 --> 00:02:21.460
הצוות החיוני שואל האם אנחנו נשלטים

00:02:21.460 --> 00:02:23.820
דייר אחד אומר כן כי הביקורת בעיצומה

00:02:23.820 --> 00:02:26.820
אחר אומר כן כי התוויות קיימות גם אם הכיסוי חלש

00:02:26.820 --> 00:02:29.080
שלישי אומר כן כי הזהות מחוברת

00:02:29.080 --> 00:02:31.660
רביעי אומר כן כי קופה אילות פרוס טכנית

00:02:31.660 --> 00:02:33.600
כל תשובה נשמעת הגיונית בפני עצמה

00:02:33.600 --> 00:02:35.640
אבל אף אחת מהן לא אומרת את אותו הדבר

00:02:35.640 --> 00:02:36.640
זו המלכודת

00:02:36.640 --> 00:02:38.940
אתם חושבים שאתם מסתכלים על מישור בקרה גלובלי

00:02:38.940 --> 00:02:40.520
שלמעשה מה שאתם מסתכלים עליו

00:02:40.520 --> 00:02:43.120
הוא קבוצה של איי בינה מלאכותית ריבוניים בתוך חברה אחת

00:02:43.120 --> 00:02:45.180
הם מחוברים במותג ולפעמים בזהות

00:02:45.180 --> 00:02:47.240
אבל הם לא נשלטים כמערכת אחת

00:02:47.240 --> 00:02:49.720
ואם אתם לא זוכרים שום דבר אחר מהסעיף הזה

00:02:49.720 --> 00:02:51.000
זכרו את השורה הזו

00:02:51.000 --> 00:02:53.140
אין מרכז ניהול בינה מלאכותית גלובלי

00:02:53.140 --> 00:02:54.480
רק אשליה של אחד

00:02:54.480 --> 00:02:56.340
ברגע שהאשליה הזו נשברת

00:02:56.340 --> 00:02:58.020
הבעיה הבאה מופיעה במהירות

00:02:58.020 --> 00:03:01.640
רוב הארגונים מגיבים על ידי ביצוע ממשל ידני של דייר אחר דייר

00:03:01.640 --> 00:03:02.880
והם קוראים לזה בקרה

00:03:02.880 --> 00:03:05.820
מדוע ממשל ידני לכל דייר קורס בקנה מידה גדול?

00:03:05.820 --> 00:03:07.780
ברגע שמנהיגים רואים את בעיית הגבולות

00:03:07.780 --> 00:03:09.380
התגובה הרגילה נשמעת הגיונית

00:03:09.380 --> 00:03:10.280
הם אומרים בסדר

00:03:10.280 --> 00:03:11.660
ננהל כל דייר כראוי

00:03:11.660 --> 00:03:13.460
צוות ניהול אחד בודק הגדרות כאן

00:03:13.460 --> 00:03:14.900
צוות אחר חוזר עליהן שם

00:03:14.900 --> 00:03:16.400
מי שהוא שומר גיליון אלקטרוני

00:03:16.400 --> 00:03:18.020
מי שהוא אחר בונה רשימת תיוג

00:03:18.020 --> 00:03:19.880
קבוצת היגוי נפגשת פעם בחודש

00:03:19.880 --> 00:03:22.060
ושואלת האם הפריסה מתקדמת במסלול

00:03:22.060 --> 00:03:23.760
על הנייר זה נראה ממושמע

00:03:23.760 --> 00:03:26.840
בפועל זו חזרה ידנית במסווה של ממשל

00:03:26.840 --> 00:03:28.860
והסיבה שזה נכשל היא פשוטה

00:03:28.860 --> 00:03:30.460
חזרה לא מייצרת בקרה

00:03:30.460 --> 00:03:32.400
היא מייצרת שונות לאורך זמן

00:03:32.400 --> 00:03:34.900
זה קורה מכיוון שכל דייר נע במהירות שונה

00:03:34.900 --> 00:03:37.220
כל מנהל קורא סטנדרטים קצת אחרת

00:03:37.220 --> 00:03:39.600
וחריגים מקומיים מתחילים להרגיש מוצדקים

00:03:39.600 --> 00:03:41.520
מכיוון שהעסק רוצה התקדמות עכשיו

00:03:41.520 --> 00:03:43.320
לא אחרי סקירה מרכזית נוספת

00:03:43.320 --> 00:03:45.860
המודל הישן הזה שורד כי הוא מרגיש גלוי

00:03:45.860 --> 00:03:48.040
אנשים יכולים להצביע על כרטיסים שנסגרו

00:03:48.040 --> 00:03:49.900
מדיניות שנוצרה והגדרות שהשתנו

00:03:49.900 --> 00:03:51.300
הם יכולים להראות פעילות

00:03:51.300 --> 00:03:54.080
אבל מאמץ גלוי אינו זהה למודל תפעולי יציב

00:03:54.080 --> 00:03:55.400
ועם קופ העילות בתמונה

00:03:55.400 --> 00:03:57.380
הפער הזה הופך ליקר מהר מאוד

00:03:57.380 --> 00:03:59.600
המערכת מתחילה להשתמש בהרשאות קיימות

00:03:59.600 --> 00:04:00.800
בחשיפת תוכן קיימת

00:04:00.800 --> 00:04:03.580
ובפערים קיימים בטביות ברגע שהמשתמשים מתחילים לבקש

00:04:03.580 --> 00:04:05.500
זה הדבר שרוב האנשים מפספסים

00:04:05.500 --> 00:04:07.580
קופ העילות לא מחכה לבשלות הממשל

00:04:07.580 --> 00:04:09.820
היא פועלת על סמך ההרשאות שכבר יש לכם

00:04:09.820 --> 00:04:11.640
הגיינת התוכן שאתם כבר סובלים

00:04:11.640 --> 00:04:14.040
ותנוחת הביקורת שכבר לא הצלחתם לתקנן

00:04:14.040 --> 00:04:16.380
אם דייר אחד ניקה את הגישה ואחר מחק

00:04:16.380 --> 00:04:18.840
או אם דייר אחד זורם נתוני ביקורת שימושיים

00:04:18.840 --> 00:04:20.940
בעוד שאחר בקושי לוחד מספיק לחקירה

00:04:20.940 --> 00:04:23.600
קופ העילות יחשוף את ההבדלים הללו באופן מיידי

00:04:23.600 --> 00:04:24.740
זה לא קורה בתיאוריה

00:04:24.740 --> 00:04:26.160
זה קורה באמצעות שימוש

00:04:26.160 --> 00:04:28.840
אם דייר אחד סוקר את הגישה הרחבה של שירפוינט

00:04:28.840 --> 00:04:30.300
ואחר הניח שהיא מספיק טובה

00:04:30.300 --> 00:04:32.000
הבינה המלאכותית תמצא את הפערים

00:04:32.000 --> 00:04:33.340
ורמה אחת עמוקה יותר

00:04:33.340 --> 00:04:35.160
כל דייר חדש מכפיל את הבעיה

00:04:35.160 --> 00:04:36.720
לא בגלל שהדיירים גרועים

00:04:36.720 --> 00:04:38.660
אלא בגלל שהבדלים לא מנוהלים מצטברים

00:04:38.660 --> 00:04:41.220
צוות פיילוט חדש אחד מוסיף חריג מקומי

00:04:41.220 --> 00:04:43.560
מזוג מביא דייר אחר עם תוויות שונות

00:04:43.560 --> 00:04:45.620
ומנהל הזורי מעתיק בסיס ישן

00:04:45.620 --> 00:04:47.720
יחידה עסקית מבקשת גישה מהירה יותר

00:04:47.720 --> 00:04:50.540
ואף אחת מהאפשרויות הללו לא נראית דרמטית בווידוד

00:04:50.540 --> 00:04:52.100
חברו אותן יחד לאורך חודשים

00:04:58.840 --> 00:05:00.860
כאן הבקרה הידנית נשברת

00:05:00.860 --> 00:05:03.300
זה מרגיש בטוח יותר מכיוון שבני אדם נוגעים בהגדרות

00:05:03.300 --> 00:05:05.020
אבל זה למעשה מגדיל את חוסר העקביות

00:05:05.020 --> 00:05:06.880
מכיוון שכל נקודת מגע היא הזדמנות נוספת

00:05:06.880 --> 00:05:07.600
עבור דיירים לסתות

00:05:07.600 --> 00:05:08.780
התוצאה היא פריסה איטית יותר

00:05:08.780 --> 00:05:09.900
במקומות שבהם רוצים מהירות

00:05:09.900 --> 00:05:11.780
יותר מאמץ ביקורת במקומות שבהם רוצים ראיות

00:05:11.780 --> 00:05:13.860
ויותר עיבוד מחדש במקומות שבהם רוצים סטנדרטים

00:05:13.860 --> 00:05:15.980
גרוע מכל זה יוצר חשיפה נסתרת

00:05:15.980 --> 00:05:17.540
שבה ההנהגה מצפה לביטחון

00:05:17.540 --> 00:05:21.020
זה הקליק לי כשאני הפסקתי להתייחס לממשל כאל משימת הגדרה

00:05:21.020 --> 00:05:21.540
זה לא

00:05:21.540 --> 00:05:23.180
זה מתנהג יותר כמו דאיכה

00:05:23.180 --> 00:05:24.700
אם מנקים הרשאות פעם אחת

00:05:24.700 --> 00:05:26.640
אבל אף בקרה לא מונעת מהן לסתות שוב

00:05:26.640 --> 00:05:27.500
החשיפה חוזרת

00:05:27.500 --> 00:05:29.680
אם מגדירים טקסונומיה של תוויות פעם אחת

00:05:29.680 --> 00:05:31.640
אבל דיירים מיישמים אותה בצורה לא אחידה

00:05:31.640 --> 00:05:32.540
קו הבסיס נשחק

00:05:32.540 --> 00:05:34.480
אם מאשרים את קופ הילות בגלים מבלי לבדוק

00:05:34.480 --> 00:05:36.160
אם הבקרה הבסיסית עדיין בתוקף

00:05:36.160 --> 00:05:37.820
לא מגדילים את הקצב בצורה בטוחה

00:05:37.820 --> 00:05:39.240
אתם פשוט מתרחבים מהר יותר

00:05:39.240 --> 00:05:41.240
ממה שהממשל שלכם יכול לעמוד בקצב

00:05:41.240 --> 00:05:43.820
לכן, המדד שחשוב כאן הוא סחיפת גישה

00:05:43.820 --> 00:05:45.200
לא רק אם תיקנתם משהו

00:05:45.200 --> 00:05:48.060
אלא כמה מהר ההרשאות מתפשטות שוב לאחר התיקון

00:05:48.060 --> 00:05:50.960
זה אומר לך אם המודל שלך מחזיק, מעמד או מחליק

00:05:50.960 --> 00:05:53.080
מכיוון שמשילות אינה פרויקט שאתה מסיים

00:05:53.080 --> 00:05:55.580
זוהי בעיית דעיכה שאתה מנהל באופן רציף

00:05:55.580 --> 00:05:57.660
וכאשר קנה המידה שובר את המודל הישן

00:05:57.660 --> 00:05:59.780
רוב המנהיגים פונים לתשובה המוכרת ביותר

00:05:59.780 --> 00:06:00.140
זהות

00:06:00.140 --> 00:06:03.100
הם מניחים שאם משתמשים יכולים לנוע בצורה נקייה בין דיירים

00:06:03.100 --> 00:06:04.620
משילות תעבור איך שהוא איתם

00:06:04.620 --> 00:06:05.680
היא לא תעבור איתם

00:06:05.680 --> 00:06:07.560
מדוע זהות לא פותרת משילות?

00:06:07.560 --> 00:06:10.040
כאן תוכניות רבות לוקחות תפנית לא נכונה

00:06:10.040 --> 00:06:12.380
מכיוון שזהות מרגישה כמו התשובה הנקייה

00:06:12.380 --> 00:06:14.420
אם משתמשים יכולים לאמץ בין דיירים

00:06:14.420 --> 00:06:15.560
עם ENTRAN מחובר

00:06:15.560 --> 00:06:17.460
ועם הגדרות בין דיירים קיימות

00:06:17.460 --> 00:06:19.640
מנהיגים מניחים שהחלק הקשה נפטר

00:06:19.640 --> 00:06:21.060
הגישה נראית מאוחדת

00:06:21.060 --> 00:06:22.520
הכניסה נראית מאוחדת

00:06:22.520 --> 00:06:28.360
דיאגרמת הארכיטקטורה נראית מסודרת, אבל משילות Copilot לא הופכת למאוחדת רק בגלל שזהות יכולה לנוע.

00:06:28.500 --> 00:06:31.560
הנחה זו נכשלת בנקודה שבה בינה מלאכותית באמת עובדת.

00:06:31.680 --> 00:06:37.220
Copilot מבסס תגובות בתוך הקשר הדייר שבו הבקשה פועלת, וההנחיות של מייקרוסופט עצמה ברורות בנקודה זו.

00:06:37.360 --> 00:06:44.900
מייקרוסופט 365 Copilot פועל במסגרת גבולות ההבטחה והתאימות של הדייר, והוא מכבד את הרשאות המשתמש בהקשר הדייר הספציפי הזה.

00:06:44.900 --> 00:06:49.580
משתמש יכול להחליף הקשר כאורח, כן, אבל קופ העילות עדיין מוגבל לדייר אחד בכל פעם.

00:06:49.720 --> 00:06:53.320
הוא לא ממזג דיירים מרובים לסביבת עבודה חכמה אחת עבור תשובה אחת.

00:06:53.400 --> 00:06:55.600
לכן, זהות יכולה לעבור, ממשל לא.

00:06:55.760 --> 00:07:00.820
וברגע שמפרידים בין השניים האלה, הרבה שפה ניהולית מתחילה להישמע מעורפלת באופן מסוכן.

00:07:01.020 --> 00:07:04.500
דיירים מחוברים, זהות משותפת, חוויה מאוחדת.

00:07:05.640 --> 00:07:08.940
ביטויים אלה עשויים להיות נכונים מבחינה כיוונית לשיתוף פעולה,

00:07:08.940 --> 00:07:14.680
אך הם אינם זהים לאמירה שאכיפת מדיניות, בסיס נתונים, רישום ואימות בקרה פועלים כעת כמערכת אחת.

00:07:14.760 --> 00:07:18.740
פער זה הופך להיות בולט עוד יותר כשמסתכלים על מצב מרובי דיירים של Copilot Studio,

00:07:18.920 --> 00:07:21.340
מכיוון שהתצוגה המקדימה מספרת סיפור ספציפי מאוד.

00:07:21.500 --> 00:07:25.980
כן, קיים שימוש מרובי דיירים, וסוכן שמתארח בדייר אחד יכול לשמש מדייר אחר,

00:07:26.200 --> 00:07:29.880
אך אימות משתמש קצה במצב מרובי דיירים עדיין אינו נתמך בתצוגה המקדימה.

00:07:29.980 --> 00:07:31.540
משתמשי אורחים אינם נתמכים.

00:07:31.540 --> 00:07:33.480
מחברים מותאמים אישית אינם נתמכים.

00:07:33.620 --> 00:07:37.220
מחברים סטנדרטיים של גראפ ומיקרוסופט 365 אינם נתמכים.

00:07:37.360 --> 00:07:39.000
ריבוי גיאוגרפי אינו נתמך.

00:07:39.140 --> 00:07:41.260
מספר יכולות ניתוח אינן זמינות.

00:07:41.460 --> 00:07:43.620
תמלילי שיחות קבועים גם במצב זה.

00:07:43.820 --> 00:07:46.040
זהו אינו מערג ממשל בוגר בין דיירים.

00:07:46.260 --> 00:07:48.500
זוהי תצוגה מקדימה מוגבלת עם מגבלות ברורות.

00:07:48.620 --> 00:07:52.400
והמגבלות הללו חשובות משום שהן שוברות את הסיפור שרבים מצוותי ההנהלה מספרים לעצמם.

00:07:52.400 --> 00:07:55.060
הם שומעים מלטאי טננט ומניחים בגרות תפעולית.

00:07:55.160 --> 00:07:58.600
הארכיטקטים שלהם שומעים קרוס טננט ומניחים סימטריה של מדיניות.

00:07:58.780 --> 00:08:02.260
צוותי הבקרה שלהם שומעים אותו ספק ומניחים עקביות בביקורת.

00:08:02.380 --> 00:08:05.620
לאחר מכן, הפרסה מתחילה ואנשים מגלים התנהגויות שונות,

00:08:05.780 --> 00:08:08.440
אותות חסרים ופערים מביכים סביב אימות ואנליטיקה.

00:08:08.580 --> 00:08:09.860
דמיינו את המקרה השני.

00:08:10.040 --> 00:08:12.980
חברה גלובלית מקימה כשרי גומלין תוך ארגוניים בין דיינים

00:08:12.980 --> 00:08:16.240
ומניחה שחוויית המשתמש תתארך באופן טבעי לשימוש בקופילות.

00:08:16.420 --> 00:08:19.240
הציפייה נשמעת סבירה הכוללת אמון בספריות משותפות,

00:08:19.400 --> 00:08:21.440
גישה חלקה יותר ודפוסי זהות משותפים.

00:08:21.560 --> 00:08:24.680
אבל כאשר צוותים בודקים תרחישים אמיתיים של קופיילות וסוכנים,

00:08:24.820 --> 00:08:25.800
ההתנהגות אינה אחידה.

00:08:25.940 --> 00:08:28.080
חלק מהנתונים מופיעים רק בהקשרים מוחלפים.

00:08:28.300 --> 00:08:30.160
חלק מהמחברים הצפויים אינם זמינים.

00:08:30.380 --> 00:08:34.240
חלק מציפיות הביקורת אינן תואמות את מה שתכונות התצוגה המקדימה חושפות בפועל.

00:08:34.240 --> 00:08:38.040
ההנהלה עדיין שומעת, מחובר, בעוד שצוות הבקרה מתחיל למצוא חריגים.

00:08:38.160 --> 00:08:39.540
זה לא מקרה של קצה טכני.

00:08:39.720 --> 00:08:40.940
זוהי קריאת ממשל שגויה.

00:08:41.080 --> 00:08:44.240
מכיוון שמבקרים לא בודקים את סיפור הארכיטקטורה שלך, הם בודקים ראיות.

00:08:44.360 --> 00:08:47.440
הם שואלים היכן רצו הנחיות, איזו מדיניות נאכפת על ידי דיירים,

00:08:47.660 --> 00:08:48.700
אילו יומני רישום קיימים,

00:08:48.880 --> 00:08:52.020
והאם הבקרות שלך היו באמת דומות בין הסביבות שתיארת כמקושרות.

00:08:52.020 --> 00:08:56.080
אם מודל ההפעלה שלך התייחס לזהות כממשל, לא תהיה לך התשובה ברורה.

00:08:56.220 --> 00:08:58.880
אז, אם אתה זוכר שורה אחת כאן, כתוב אותה כך.

00:08:59.060 --> 00:09:01.340
זהות בין דיירים אינה בינה בין דיירים.

00:09:01.580 --> 00:09:03.340
זהות עוזרת למשתמשים להיכנס.

00:09:03.500 --> 00:09:06.080
היא לא אומרת לך אם התנהגות קופיילוט נשלטת באופן עקבי,

00:09:06.220 --> 00:09:10.420
מנותרת כראוי, או בטוחה להרחבה על פני כל המקומות שהארגון שלך מחנה כעת סביבה אחת.

00:09:10.500 --> 00:09:13.580
וברגע שזה מתבהר, התשובה לא יכולה להיות יותר חיבורי דיירים.

00:09:13.580 --> 00:09:15.200
זו חייבת להיות ארכיטקטורה.

00:09:22.020 --> 00:09:24.920
היא רק חלקית, וגבולות הדיירים עדיין באמת חשובים.

00:09:25.100 --> 00:09:27.080
זה נראה כמו מערכת רכזת וספירה.

00:09:27.200 --> 00:09:30.040
אני לא מציע את זה בגלל שהדיאגרמה נראית נקייה בשקופית,

00:09:30.260 --> 00:09:33.840
אלא בגלל שהיא באמת תואמת את תנאי ההפעלה המבולגנים שאתה מתמודד איתם כרגע.

00:09:33.980 --> 00:09:38.800
אתה צריך מקום מרכזי אחד שבו החלטות ממשל מתוכננות, נמדדות ונאחפות כמערכת אחת,

00:09:39.000 --> 00:09:42.080
ואז אתה צריך צוותי דיירים מקומיים כדי לבצע את ההחלטות האלה.

00:09:42.080 --> 00:09:48.740
צוותים מקומיים אלה צריכים לעבוד בתוך הגבולות שלהם מבלי להמציא גרסה משלהם של הכללים בכל פעם שהם מרגישים קצת לחץ.

00:09:48.860 --> 00:09:50.640
אנחנו צריכים להתחיל עם המרכז.

00:09:50.780 --> 00:09:53.600
המרכז אינו פורטל ניהול, הוא אינו לוח מכוונים מבריק,

00:09:53.840 --> 00:09:58.360
והוא בהחלט אינו צוות מרכזי הרועי שקופץ לכל דייר יחיד כדי לנקות קבצים באופן ידני.

00:09:58.500 --> 00:10:01.080
במקום זאת, המרכז משמש כסמכות הממשל האולטימטיבית.

00:10:01.080 --> 00:10:07.320
קבוצה זו מחזיקה בעיצוב המדיניות, קווי הבסיס של הביקורת, תקני הטוויות וקריטריוני הפריסה.

00:10:07.420 --> 00:10:14.400
הם אלה שמחליטים מה המשמעות של מוכן לקופילות, אילו ראיות נחשבות כהוכחה, וכמה מהר יש לסגור פער הבטחה.

00:10:14.820 --> 00:10:16.600
שינוי זה משנה את כל השיחה.

00:10:16.940 --> 00:10:23.480
בגלל מבנה זה, גלובלי, מפסיק להיות מילה למסך קסום אחד ומתחיל להתייחס למערכת ממשל מאוחדת אחת.

00:10:23.480 --> 00:10:29.720
אתה מקבל תקן אחד לבקרות תחום אחריות, תקן אחד לאופן שבו אתה בולע ביקורות, וסטנדרט אחד לטוויות הרגישות שלך.

00:10:29.840 --> 00:10:35.100
יש רף ברור אחד למה שחייב להיות נכון לפני שכל דייר ספציפי רשאי להרחיב את גישת קופה אילות למשתמשים נוספים.

00:10:35.220 --> 00:10:36.760
אחר כך אתה צריך את החישורים.

00:10:36.920 --> 00:10:42.140
הסיפוקים הם צוותי ביצוע הדיירים המקומיים שלכם, שלוקחים את קו הבסיס הזה ומיישמים אותו בסביבה הספציפית שלהם.

00:10:42.140 --> 00:10:46.460
הם אלה שמפעילים את התיקון, מעמתים את הלוגים ובודקים הרשאות גישה רחבות.

00:10:46.540 --> 00:10:51.940
עם זאת, הם עושים את כל העבודה הזו בתוך מרחב עיצוב צר מאוד ולא בתוך מרחב של חופש לכולם.

00:10:52.120 --> 00:10:55.900
אם צוות מקומי צריך לסתות מהתוכנית, יש נתיב רשמי לחריגים.

00:10:56.060 --> 00:11:00.220
ואם הם רוצים להתקדם מהר יותר, הם עדיין צריכים לעמוד תחילה בבקרות המשותפות.

00:11:00.220 --> 00:11:07.980
כאשר צצים הבדלים אזוריים או משפטיים, בעיות אלו מתועדות ומאושרות במקום להיספק בשקט בפתרון מקומי כלשהו שאף אחד אחר לא יודע עליו.

00:11:08.120 --> 00:11:12.380
מבנה זה חיוני מכיוון שמודלים מרכזיים לחלוטין בדרך כלל נחנקים בפרטים מקומיים,

00:11:12.380 --> 00:11:15.980
בעוד שמודלים מקומיים לחלוטין נסחפים לחוסר עקביות מוחלט כמעט מיד.

00:11:16.120 --> 00:11:18.940
רכזת וסיפוקים נמנעים משני דפוסי הקשל הללו.

00:11:18.940 --> 00:11:21.140
הרכזת נותנת לכם את העקביות שאתם צריכים,

00:11:21.200 --> 00:11:24.560
בעוד שהסיפוקים נותנים לכם את מהירות הביצוע במקום שבו העבודה מתרחשת בפועל.

00:11:24.680 --> 00:11:26.080
בואו נהפוך את זה למוחשי.

00:11:26.240 --> 00:11:31.540
ברכזת, אתם מגדירים את מערך בקרות המינימום שכל דייר חייב להפעיל לפני שקופילות יורשה לגדול.

00:11:31.540 --> 00:11:36.300
אתם מגדירים בדיוק אילו אירועי ביקורת אתם מצפים לראות ובאיזו תדירות תבדקו אותם.

00:11:36.420 --> 00:11:39.980
אתם גם יוצרים טקסונומיה משותפת של תוויות עבור תוכן רגיש,

00:11:39.980 --> 00:11:43.960
כך שתגיד סודית לא אומרת חמישה דברים שונים על פני חמישה דיירים שונים.

00:11:44.160 --> 00:11:48.540
אתם קובעים את הקצב לזכירות, אולי חודשיות עבור מצב ההבטחה הכולל שלכם,

00:11:48.740 --> 00:11:51.560
ובהתדירות גבוהה יותר באזורים שבהם הפרסה פעילה כאה.

00:11:51.560 --> 00:11:56.600
בנקודת ההתחלה, הצוות שלכם ממפה את הסטנדרטים ברמה גבוהה למציאות של הדייר הספציפי הזה.

00:11:56.740 --> 00:12:01.700
הם מוצאים אילו אתרים עדיין חשופים לגישה רחבה ואילו יחידות עסקיות מפגרות מאחור בתוויות שלהן.

00:12:01.840 --> 00:12:05.940
הם בודקים אם הביקורת אכן מופעלת ועם הרשומות הנכונות גלויות לצוות ההבטחה.

00:12:06.060 --> 00:12:10.040
הם מחפשים מנהלים מקומיים שאולי הציגו חריגים שמעולם לא נבדקו רשמית.

00:12:10.280 --> 00:12:15.020
והם מחליטים אם קבוצת פיילוט יכולה להתרחב בביטחה או אם עליהם לעצור ולתקן דברים קודם.

00:12:15.020 --> 00:12:20.000
והנה הכלל הקשה כי בלי כלל, מודל זה הוא רק הצעה במקום ממשל בפועל.

00:12:20.160 --> 00:12:23.560
פריסת קו פיילוט לא מתרחשת באף דייר ללא רישום ביקורת,

00:12:23.560 --> 00:12:27.860
מעומת, שריקת שיתוף יתר הושלמה וקו בסיס מינימלי לחיסוי תוויות.

00:12:27.960 --> 00:12:31.020
אני לא מדבר על דברים אלה שמתוכננים או נדונים חלקית.

00:12:31.200 --> 00:12:32.060
יש לאמת אותם.

00:12:32.180 --> 00:12:35.920
אם דייר לא יכול להוכיח ששלושת התנאים הללו מתקיימים, הפריסה מושהה.

00:12:35.920 --> 00:12:39.300
זה אולי נשמע מחמיר עד שמשווים את זה לעלות העצומה של ניקוי בלגן

00:12:39.300 --> 00:12:43.380
אחרי שמשתמשים מתחילים למצוא תוכן רגיש שמעולם לא התכוונתם לחשוף באמצעות בינה מלאכותית.

00:12:43.380 --> 00:12:46.680
כשמסתכלים על זה ככה, הכללים האלה הם פשוט היגיון בריא בסיסי.

00:12:46.840 --> 00:12:49.780
סיבה נוספת לכך שהמודל הזה עובד כל כך טוב היא התזמון.

00:12:49.900 --> 00:12:53.800
ככל שמחכים יותר זמן להגדיר את זה, כך יוצרים לעצמכם יותר חוב ניקוי בהמשך.

00:12:53.800 --> 00:13:01.060
כל דייר שמפורס לפני קו הבסיס הופך לצבר עצום נוסף של חריגים וראיות חסרות שהצוות שלכם יצטרך בסופו של דבר להיפטר ממנו.

00:13:01.200 --> 00:13:05.160
מנהיגים מתייחסים לעיתים קרובות לממשל כמשהו שיכול להבשיל לאחר סיום האימוץ.

00:13:05.160 --> 00:13:08.580
אבל בעולם של קופ איילוט מרובד דיירים, הרצף הזה הפוך לחלוטין.

00:13:08.700 --> 00:13:13.540
הממשל צריך להוביל את הפריסה או שהפריסה תיצור יותר חוב ממה שהצוותים שלכם יוכלו אי פעם לקוות לספוג.

00:13:13.540 --> 00:13:16.800
אם אתם מובילים את זה ברמת הארגון, הצעד הבא שלכם ברור מאוד.

00:13:16.920 --> 00:13:19.920
עציבו את המרכז עכשיו והגדירו את קו הבסיס הזה עוד היום.

00:13:20.080 --> 00:13:24.220
הקצו את החישורים שלכם וחתבו את תהליך הטיפול בחריגים שלכם בכתב באופן מיידי.

00:13:24.220 --> 00:13:31.540
עליכם להפוך את המשמעות הגלובלית לכך שההחלטות שלכם ושערי הפריסה שלכם יעבדו כמערכת אחת, גם כאשר הדיירים עצמם לא עושים זאת.

00:13:31.660 --> 00:13:35.040
מודל חשוב רק אם הוא באמת משנה את מה שנאחף מחר בבוקר.

00:13:35.200 --> 00:13:37.660
מה מנהיגים צריכים למדוד לפני שהם מתרחבים?

00:13:37.860 --> 00:13:41.500
מודל ממשל מחזיק מעמד רק אם הוא מייצר מדידות שכולם חולקים.

00:13:41.700 --> 00:13:48.160
אחרת, כל דייר יטען שהוא מתקדם בשפה שלו, וההנהגה תקבל עדכוני סטטוס מבלי שתהיה לה שליטה אמיתית.

00:13:48.160 --> 00:13:54.880
לפני שאתם מרחיבים את קופ אילוט עוד יותר, אתם צריכים קבוצה קטנה של מדדים שיגידו לכם אם הארכיטקטורה מתנהגת כפי שאתם חושבים שהיא.

00:13:55.000 --> 00:13:59.200
רמות הפעילות לא יגידו לכם את האמת, ומספרי אימוץ בהחלט לא יראו לכם את הסיכונים.

00:13:59.400 --> 00:14:01.380
כדאי להתחיל עם צמצום שיתוף יתר.

00:14:01.520 --> 00:14:06.320
זהו עדיין אחד הסימנים הברורים ביותר לכך שהסביבה שלכם הופכת לבטוחה יותר עבור בינה מלאכותית.

00:14:06.320 --> 00:14:13.060
אתם צריכים לבחון קבוצות גישה רחבות, אתרי שירפוינט כתוכים והרשאות ישנות שמעניקות גישה רבה יותר ממה שהעסק באמת צריך.

00:14:13.180 --> 00:14:18.860
המטרה כאן אינה להגיע למספר מושלם, אלא להוכיח שהחשיפה שלכם יורדת לפני שהטווח של קופ אילוט שלכם עולה.

00:14:18.960 --> 00:14:24.640
אם שני הקווים הללו נעים בכיוונים מנוגדים, אתם מתרחבים הרבה יותר מהר ממה שאתם מתקנים את הבעיות הבסיסיות.

00:14:24.780 --> 00:14:27.100
המדד השני שאתם צריכים הוא כיסוי תצפית.

00:14:27.100 --> 00:14:32.180
האם אתם באמת יכולים לראות מה קופ אילוט עושה בכל הדיירים שלכם באופן שתומך בחקירה אמיתית?

00:14:32.240 --> 00:14:38.080
רוב המחקרים מצביעים על Microsoft Purview כמקום העיקרי שבו מאוחסנות רשומות ליבה כמו אינטראקציה עם קופ אילוט,

00:14:38.280 --> 00:14:40.100
אך זה מניח שביקורת מופעלת בכל מקום.

00:14:40.260 --> 00:14:42.980
כיסוי אינו משהו שאתם יכולים פשוט להניח שהוא עובד.

00:14:43.140 --> 00:14:49.060
אתם צריכים לדעת בדיוק אילו דיירים פעילים את תהליך בליאת הביקורת ואילו עדיין משאירים אתכם עם נירות חלקית.

00:14:49.060 --> 00:14:52.500
אם אין לכם יומני רישום, אין לכם שליטה ואין לכם אחריות.

00:14:52.660 --> 00:14:54.300
זה נשמע בוטה כי זה חייב להיות.

00:14:54.500 --> 00:14:59.340
אם דייר לא יכול לספק ראיות שמישות למה שקורה, הדייר הזה לא מוכן להתרחב בצורה בטוחה.

00:14:59.460 --> 00:15:04.820
אינכם יכולים לשלוט במה שאתם לא רשאים לבדוק, ובוודאי שלא תוכלו להגן על פעולותיכם עם מה שהוא ישתבש מאוחר יותר.

00:15:05.020 --> 00:15:08.020
המדד השלישי הוא הזמן שלכם למדיניות בכל הדיירים.

00:15:08.020 --> 00:15:12.720
כאן ההנהגה מגלה אם מודל ה-Hub and Spock הוא אכן אמיתי או סתם דקורטיבי.

00:15:12.720 --> 00:15:18.340
החלטה מרכזית לא אומרת כלום אם דייר אחד אוכף אותה השבוע, בעוד שאחר ממתין חודש לחשוב עליה.

00:15:18.500 --> 00:15:23.820
עליכם למדוד את הזמן שלוקח מאישור מדיניות ועד להכיפה יעילה של מדיניות זו בכל דייר בודד.

00:15:23.960 --> 00:15:28.380
אני לא מדבר על הזמן שלוקח להכריז על זה או לתעד את זה, אלא על הזמן עד שזה באמת פעיל.

00:15:28.380 --> 00:15:32.740
עבור תוכנית בינה מלאכותית שמתקדמת כל כך מהר, עיכוב כזה הוא פשוט מילה אחרת לסיכון.

00:15:32.880 --> 00:15:36.880
יעד מעשי עבור רוב הארגונים הוא פחות מממינוס 72 שעות לשינויים סטנדרטיים.

00:15:37.040 --> 00:15:40.720
אם זמן המחזור שלכם ארוך בהרבה מזה, עדיין אין לכם מודל ניתן להרחבה.

00:15:40.880 --> 00:15:42.980
יש לכם פשוט בעיית תאום שצריך לפתור.

00:15:43.160 --> 00:15:45.980
בשלב הבא, עליכם לבחון את יחס כיסוי התביעות שלכם.

00:15:46.120 --> 00:15:50.280
אל תתנו לזה להפוך למדד יהירות שבו דייר אחד מגיע למספרים גבוהים בעוד שאחרים מפגרים.

00:15:50.280 --> 00:15:54.080
מה שבאמת חשוב הוא האם התוכן הרגיש שלכם מתויג באופן עקבי מספיק,

00:15:54.160 --> 00:15:57.180
כדי שהתנהגות קופה אילות לא תתבסס רק על ניחושים של משתמשים.

00:15:57.320 --> 00:16:02.100
אתם לא מחפשים שלמות כאן, אלא אתם מחפשים רמת שליטה דומה בכל דייר בארגון.

00:16:02.280 --> 00:16:05.300
לבסוף, עליכם לעקוב אחר קצב סך הפגישה שלכם.

00:16:05.460 --> 00:16:08.900
מדד זה אומר לכם האם מאמצי הניקוי שלכם באמת נשארים לאורך זמן.

00:16:08.900 --> 00:16:12.940
לאחר שתסיימו פרויקט תיקון, באיזו מהירות ההרשאות הללו מתחילות להתפשט שוב?

00:16:13.080 --> 00:16:15.960
באיזו תדירות הקבוצות הרחבות הללו זוכלות חזרה למערכת?

00:16:15.960 --> 00:16:20.380
צוותים רבים מבינים זאת מאוחר מדי, משום שמדדו את התיקון פעם אחת והניחו שהבעיה נעלמה לתמיד.

00:16:20.560 --> 00:16:21.080
זה לא קרה.

00:16:21.240 --> 00:16:25.400
המדד היחיד שחשוב הוא כמה מהר המערכת מתחילה להחליק ברגע שמפסיקים להסתכל עליה.

00:16:25.600 --> 00:16:27.440
זהו לוח המכוונים התפעולי שלכם.

00:16:27.440 --> 00:16:33.200
עליכם לעקוב אחר צמצום שיתוף יתר, כיסוי תצפיות, זמן עד למדיניות, כיסוי תוויות וסחיפת גישה.

00:16:33.300 --> 00:16:36.380
קצב הדיווח שלכם חשוב בדיוק כמו המספרים עצמם.

00:16:36.500 --> 00:16:41.840
המרכז צריך להיות הבעלים של לוח המכוונים הניהולי, משום שההנהגה זקוקה לי תצוגה אחת ויחידה של המצב כולו.

00:16:41.960 --> 00:16:47.320
בינתיים, הדוברים צריכים להיות הבעלים של התיקון, משום שהעבודה בפועל צריכה להתרחש במקום בו נמצא גבול הדיירים.

00:16:47.320 --> 00:16:50.100
צוות אחד קורא את המערכת והצוות השני מתקן אותה.

00:16:50.160 --> 00:16:53.300
עליכם לעקוב אחר המספרים הללו לפני שאתם מרחיבים, לא לאחר מעשה.

00:16:53.440 --> 00:16:56.340
הסיכון אינו בהמתנה לפגישה הבאה או לסדנת הממשל שלכם.

00:16:56.340 --> 00:17:01.620
הוא כבר פעיל בכל דייר, שם קופיילוט יכול למצוא בדיוק את מה שהבקרות הנוכחיות שלכם עדיין מאפשרות לו לראות.

00:17:01.780 --> 00:17:03.900
שני הדפוסים שמנהיגים ממשיכים להחמיץ.

00:17:03.900 --> 00:17:11.160
אני ממשיך לראות שני דפוסים ספציפיים בשטח, ושניהם קורים משום שמנהיגים מתייחסים לקופילוט כמו להשקת תוכנה במקום לאירוע בקרה גדול.

00:17:11.300 --> 00:17:17.760
הדפוס הראשון מתחיל כאשר ארגון פורס את קופיילוט לפני קביעת קו בסיס אמיתי של תחום פעילות או סקירת גישת שרפוינט שלו.

00:17:17.760 --> 00:17:20.100
ביום הראשון, הפריסה נראית מושלמת.

00:17:20.260 --> 00:17:24.760
רישיונות מוקצים, משתמשים נרגשים, והמסרים הפנימיים עוסקים כולו בפריון.

00:17:24.760 --> 00:17:31.760
אבל אז, הנחיות רגילות מתחילות לשלוף חומר שהיה נגיש מבחינה טכנית כל הזמן, אך כמעט בלתי נראה לעובד הממוצע.

00:17:31.880 --> 00:17:38.780
לפני הבינה המלאכותית, אף אחד לא בילה את יומו בלחיצה על אתרים ישנים, תיקיות ישנות או הרשאות בירושה כדי למצוא דברים שלא אמורים לראות.

00:17:38.920 --> 00:17:40.420
אבל עכשיו, הם לא צריכים.

00:17:40.420 --> 00:17:44.120
משתמש שואל שאלה בסיסית, סיכום חוזר וקובץ מופיע.

00:17:44.240 --> 00:17:50.160
אולי זה תוכן רגיש של משאבי אנוש או חומר פיננסי או מידע על עסקה שהיה אמור להישאר במעגל צר מאוד.

00:17:50.340 --> 00:17:54.300
לא הייתה פרצה, לא תוכנות סדוניות ולא גבול אבטחה שבור במובן המסורתי.

00:17:54.440 --> 00:17:58.320
המערכת פשוט השתמשה בהרשאות ובמצב התוכן שהדייר כבר אפשר.

00:17:58.520 --> 00:18:01.200
זה הרגע שבו צוותים רבים סוף סוף מבינים את הבעיה.

00:18:01.360 --> 00:18:03.340
הבינה המלאכותית לא יצרה את החשיפה.

00:18:03.340 --> 00:18:05.660
היא פשוט הסירה את החיכוך שנהג להסתיר אותה.

00:18:05.740 --> 00:18:09.760
ברגע שזה קורה אצל דייר אחד, אמון ההנהלה בדרך כלל יורד בכל הארגון.

00:18:09.980 --> 00:18:13.540
משום שאף אחד לא יכול לומר בוודאות היכן אותו דפוס עשוי להופיע בהמשך.

00:18:13.680 --> 00:18:17.040
האירוע אולי נראה מקומי, אך הנזק לאמון הוא כלל ארגוני.

00:18:17.200 --> 00:18:20.020
הדפוס השני שקט יותר, אך מסוכן באותה מידה.

00:18:20.160 --> 00:18:24.620
חברה מקימה כשרי זהות בין דיירים, שומעת שתרחישים מרובי דיירים אפשריים,

00:18:24.620 --> 00:18:27.980
ומניחה שמודל התפעול שלה הבוגר מספיק לפריסה רחבה.

00:18:28.140 --> 00:18:30.400
במצגת, זה נשמע כמו תוכנית מוצקה.

00:18:30.520 --> 00:18:32.700
במציאות, הפעילות הופכת למבולגנת.

00:18:32.860 --> 00:18:36.360
צוות אחד מצפה לחוויית קופיילות חלקה בכל סביבה מחוברת.

00:18:36.580 --> 00:18:41.420
בעוד שאחר מצפה לנירות דומה, ושלישי מניח שאותן בקרות יעקבו אחר המשתמש לכל מקום.

00:18:41.600 --> 00:18:44.700
לאחר מכן, השימוש בפועל מתחיל לחשוף התנהגות לא אחידה,

00:18:44.700 --> 00:18:47.400
פערים בעימות ונקודות טורפה במה שניתן למדוד בפועל.

00:18:47.400 --> 00:18:50.020
הבעיה אינה שהצוותים הללו היו רשלניים.

00:18:50.160 --> 00:18:53.040
הבעיה האמיתית היא שהם תרגמו קישוריות להבטחה.

00:18:53.180 --> 00:18:55.860
הנחה זו יוצרת סיפור כוזב לגבי תאימות.

00:18:56.000 --> 00:18:59.460
ההנהגה שומעת את המילה מחובר, ומניחה שהארגון מוכן.

00:18:59.620 --> 00:19:06.300
חודשים לאחר מכן, סקירות בקרה מגלות שההתנהגות, הראיות והאכיפה היו מגוונות הרבה יותר ממה שמי שהוא רצה להודות בהתחלה.

00:19:06.300 --> 00:19:08.460
עכשיו, השבו את זה לדפוס טוב יותר.

00:19:08.640 --> 00:19:11.020
ארגון אחר בוחר להעט לפני שהוא מתרחב.

00:19:11.020 --> 00:19:17.400
הם קובעים תחילה קו בסיס לתוית, הם סוקרים תחילה גישה רחבה, והם מעמתים את נראות הביקורת שלהם לפני שהם עושים משהו אחר.

00:19:17.540 --> 00:19:24.620
הם מרחיבים את קופ העילות בגלים, לא בגלל שהם חוששים מאימוץ, אלא בגלל שהם רוצים שכל גל ייצר ראיות שמישות לפני שהבא מתחיל.

00:19:24.620 --> 00:19:34.120
ארגון זה בדרך כלל נה מהר יותר בטווח הארוך מכיוון שהוא לא עוצר כל הזמן כדי להסביר הפתעות, לנקות תוכן חשוף, או להתווכח על מה שהממשל אמור היה להביע בפועל.

00:19:34.120 --> 00:19:36.380
זהו היתרון שרוב המנהיגים מפספסים.

00:19:36.540 --> 00:19:38.780
ממשל טוב לא חושם את הפריסה שלכם.

00:19:38.920 --> 00:19:42.080
הוא מסיר את הגרירה מהפריסה לאחר סיום הגל הראשון.

00:19:42.240 --> 00:19:43.860
המלכודת אינה האימוץ עצמו.

00:19:44.000 --> 00:19:50.020
המלכודת היא אימוץ לא מנוהל על פני דיירים שנראים מחוברים מרחוק, אך מתנהגים בצורה שונה מאוד כשמתקרבים.

00:19:50.200 --> 00:19:52.940
ההחלטה שאתם צריכים לקבל היא למעשה פשוטה מאוד.

00:19:52.940 --> 00:20:00.300
אתם צריכים לעבור למודל ממשל בינה מלאכותית מאוחד של רכזת וסופר עכשיו, ואתם צריכים להפסיק לטעות בין החלפת אפשרויות בין דיירים לדיירים לבין שליטה בפועל.

00:20:00.420 --> 00:20:07.060
עליך להשהות את הרחבת קופיילות שלך בכל דייר שלא יכול להוכיח את הרישום שלו, את ביקורות השיתוף יתר שלו ואת כיסוי הבסיס של התוויות שלו.

00:20:07.180 --> 00:20:11.420
בינה מלאכותית תעקוב אחר המערכת שאתה בונה בפועל, לא אחר תרשים הארגון שאתה מדווח אליו.

00:20:11.420 --> 00:20:19.620
אם זה שינה את האופן שבו אתה חושב על ניהול קופיילות מרובי דיירים, עקוב אחריי, מרקו פיטרס, בלינקטין, ושתפו זאת עם הצוות שלך אם אתם מתמודדים עם בעיות אלה כרגע.