צוות המנהיגות שלכם חושב שזו שאלת פריסה היא לא, זוהי החלטת ממשל עם מסלול תנועה קצר מאוד והלחץ גובר מכיוון שקופילות לא מחכה לניקוי המדיניות שלכם או לאישור הפנימי שלכם כדי להדביק את הפער ברגע שהוא מתחיל לפעול בסביבה שלכם הוא משתמש במערכת בדיוק כפי שהוא מוצא אותה וכאן זה נשבר רוב הארגונים עם מספר דיירים של Microsoft 365 מניחים שיש להם סיפור בקרה אחד של בינה מלאכותית בעיקר משום שהם קונים מספק אחד ומנהלים נכס זהות אחד הם שומעים נרטיב אסטרטגי אחד ממייקרוסופט ומניחים שהמציאות תואמת את המצגת אבל תנאי ההפעלה שונים מאוד בינה מלאכותית פועלת בגבולות הדיירים בעוד שהסיכון נע ממש על פני כל אחד מהם אז השאלה היא לא האם נוכל להפעיל את קופיילוט בכל מקום השאלה האמיתית היא איזה מודל ממשל מאפשר לנו להתרחב בביטחה בין דיירים שמתנהגים באופן עצמאי לפני שנגיע למודל הזה עלינו להגדיר את המלכודת המלכודת יהיה בינה מלאכותית ריבוניים בתוך ארגון אחד ברוב הארגונים האשליה מתחילה בהיכרות אתם פותחים את מייקרוסופט 365 אתם פותחים את פורוו אתם פותחים את אינטרה אתם פותחים את פאוור פלטפורם המיתוג זהה שפת הניהול מרגישה מחוברת והתנועה המסחרית מספרת סיפור נקי מאוד מערכת אקולוגית אחת אסטרטגיה אחת כיוון אחד אבל מודל הבקרה שמתחת אינו דבר אחד וזה חשוב יותר מהמיתוג בהתבסס על המחקר כאן אין מרכז ניהול גלובלי אחד של בינה מלאכותית עם שוויון תכונות מלא שנותן לכם מקום אחד לשלוט בקופילות בצורה נקייה על פני כל הדיירים מה שיש לכם בפועל הוא מחסנית בקרה מקוטעת חלקים מהממשל נמצאים בפרוויו חלקים אחרים נמצאים במרכזי ניהול והשאר מפוזרים על פני אינטרה ופאוור פלטפורם חלק מהתכונות צצות בשכבות הבקרה החדשות יותר של מייקרוסופט אך הן עדיין לא יוצרות מישור גלובלי בוגר אחד שלם על פני כל גבול דיירים פער זה יוצר ביטחון כוזב מנהיגים בוחנים את המערכת האקולוגית ומניחים ריכוזיות בעוד שצוותים בוחנים זהות משותפת ומניחים עקביות רכש רואה הסכם אחד ומניח מודל תפעולי אחד אך כל דייר עדיין נושא גבול מדיניות משלו וגבול נתונים משלו מה שאומר שבפועל כל אחד נושא גרסה משלו לאמת אז מה שקורה בפועל הוא פשוט אין לכם סביבת בינה מלאכותית ארגונית אחת יש לכם מספר סביבות בינה מלאכותית ששייכות במקרה לאותו ארגון זוהי תמונת סיכון שונה מאוד לדייר אחד עשויה להיות כיסוי תחום עיסוק חזק יותר בעוד שלאחר יש אימוץ תוויות חלש יותר או קליטת ביקורת לא שלמה מרמת הדירקטוריון זה עדיין עשוי להיראות כמו תוכנית אחת אבל מנקודת מבט של ביקורת או אירוע זו בכלל לא תוכנית אחת זוהי אוסף של תנאי הפעלה נפרדים וברגע שהתנאים האלה משתנים הדיווח מתחיל לשקר לא במכוון מבחינה מבנית הצוות החיוני שואל האם אנחנו נשלטים דייר אחד אומר כן כי הביקורת בעיצומה אחר אומר כן כי התוויות קיימות גם אם הכיסוי חלש שלישי אומר כן כי הזהות מחוברת רביעי אומר כן כי קופה אילות פרוס טכנית כל תשובה נשמעת הגיונית בפני עצמה אבל אף אחת מהן לא אומרת את אותו הדבר זו המלכודת אתם חושבים שאתם מסתכלים על מישור בקרה גלובלי שלמעשה מה שאתם מסתכלים עליו הוא קבוצה של איי בינה מלאכותית ריבוניים בתוך חברה אחת הם מחוברים במותג ולפעמים בזהות אבל הם לא נשלטים כמערכת אחת ואם אתם לא זוכרים שום דבר אחר מהסעיף הזה זכרו את השורה הזו אין מרכז ניהול בינה מלאכותית גלובלי רק אשליה של אחד ברגע שהאשליה הזו נשברת הבעיה הבאה מופיעה במהירות רוב הארגונים מגיבים על ידי ביצוע ממשל ידני של דייר אחר דייר והם קוראים לזה בקרה מדוע ממשל ידני לכל דייר קורס בקנה מידה גדול?

ברגע שמנהיגים רואים את בעיית הגבולות התגובה הרגילה נשמעת הגיונית הם אומרים בסדר ננהל כל דייר כראוי צוות ניהול אחד בודק הגדרות כאן צוות אחר חוזר עליהן שם מי שהוא שומר גיליון אלקטרוני מי שהוא אחר בונה רשימת תיוג קבוצת היגוי נפגשת פעם בחודש ושואלת האם הפריסה מתקדמת במסלול על הנייר זה נראה ממושמע בפועל זו חזרה ידנית במסווה של ממשל והסיבה שזה נכשל היא פשוטה חזרה לא מייצרת בקרה היא מייצרת שונות לאורך זמן זה קורה מכיוון שכל דייר נע במהירות שונה כל מנהל קורא סטנדרטים קצת אחרת וחריגים מקומיים מתחילים להרגיש מוצדקים מכיוון שהעסק רוצה התקדמות עכשיו לא אחרי סקירה מרכזית נוספת המודל הישן הזה שורד כי הוא מרגיש גלוי אנשים יכולים להצביע על כרטיסים שנסגרו מדיניות שנוצרה והגדרות שהשתנו הם יכולים להראות פעילות אבל מאמץ גלוי אינו זהה למודל תפעולי יציב ועם קופ העילות בתמונה הפער הזה הופך ליקר מהר מאוד המערכת מתחילה להשתמש בהרשאות קיימות בחשיפת תוכן קיימת ובפערים קיימים בטביות ברגע שהמשתמשים מתחילים לבקש זה הדבר שרוב האנשים מפספסים קופ העילות לא מחכה לבשלות הממשל היא פועלת על סמך ההרשאות שכבר יש לכם הגיינת התוכן שאתם כבר סובלים ותנוחת הביקורת שכבר לא הצלחתם לתקנן אם דייר אחד ניקה את הגישה ואחר מחק או אם דייר אחד זורם נתוני ביקורת שימושיים בעוד שאחר בקושי לוחד מספיק לחקירה קופ העילות יחשוף את ההבדלים הללו באופן מיידי זה לא קורה בתיאוריה זה קורה באמצעות שימוש אם דייר אחד סוקר את הגישה הרחבה של שירפוינט ואחר הניח שהיא מספיק טובה הבינה המלאכותית תמצא את הפערים ורמה אחת עמוקה יותר כל דייר חדש מכפיל את הבעיה לא בגלל שהדיירים גרועים אלא בגלל שהבדלים לא מנוהלים מצטברים צוות פיילוט חדש אחד מוסיף חריג מקומי מזוג מביא דייר אחר עם תוויות שונות ומנהל הזורי מעתיק בסיס ישן יחידה עסקית מבקשת גישה מהירה יותר ואף אחת מהאפשרויות הללו לא נראית דרמטית בווידוד חברו אותן יחד לאורך חודשים

כאן הבקרה הידנית נשברת זה מרגיש בטוח יותר מכיוון שבני אדם נוגעים בהגדרות אבל זה למעשה מגדיל את חוסר העקביות מכיוון שכל נקודת מגע היא הזדמנות נוספת עבור דיירים לסתות התוצאה היא פריסה איטית יותר במקומות שבהם רוצים מהירות יותר מאמץ ביקורת במקומות שבהם רוצים ראיות ויותר עיבוד מחדש במקומות שבהם רוצים סטנדרטים גרוע מכל זה יוצר חשיפה נסתרת שבה ההנהגה מצפה לביטחון זה הקליק לי כשאני הפסקתי להתייחס לממשל כאל משימת הגדרה זה לא זה מתנהג יותר כמו דאיכה אם מנקים הרשאות פעם אחת אבל אף בקרה לא מונעת מהן לסתות שוב החשיפה חוזרת אם מגדירים טקסונומיה של תוויות פעם אחת אבל דיירים מיישמים אותה בצורה לא אחידה קו הבסיס נשחק אם מאשרים את קופ הילות בגלים מבלי לבדוק אם הבקרה הבסיסית עדיין בתוקף לא מגדילים את הקצב בצורה בטוחה אתם פשוט מתרחבים מהר יותר ממה שהממשל שלכם יכול לעמוד בקצב לכן, המדד שחשוב כאן הוא סחיפת גישה לא רק אם תיקנתם משהו אלא כמה מהר ההרשאות מתפשטות שוב לאחר התיקון זה אומר לך אם המודל שלך מחזיק, מעמד או מחליק מכיוון שמשילות אינה פרויקט שאתה מסיים זוהי בעיית דעיכה שאתה מנהל באופן רציף וכאשר קנה המידה שובר את המודל הישן רוב המנהיגים פונים לתשובה המוכרת ביותר זהות הם מניחים שאם משתמשים יכולים לנוע בצורה נקייה בין דיירים משילות תעבור איך שהוא איתם היא לא תעבור איתם מדוע זהות לא פותרת משילות?

כאן תוכניות רבות לוקחות תפנית לא נכונה מכיוון שזהות מרגישה כמו התשובה הנקייה אם משתמשים יכולים לאמץ בין דיירים עם ENTRAN מחובר ועם הגדרות בין דיירים קיימות מנהיגים מניחים שהחלק הקשה נפטר הגישה נראית מאוחדת הכניסה נראית מאוחדת דיאגרמת הארכיטקטורה נראית מסודרת, אבל משילות Copilot לא הופכת למאוחדת רק בגלל שזהות יכולה לנוע. הנחה זו נכשלת בנקודה שבה בינה מלאכותית באמת עובדת. Copilot מבסס תגובות בתוך הקשר הדייר שבו הבקשה פועלת, וההנחיות של מייקרוסופט עצמה ברורות בנקודה זו. מייקרוסופט 365 Copilot פועל במסגרת גבולות ההבטחה והתאימות של הדייר, והוא מכבד את הרשאות המשתמש בהקשר הדייר הספציפי הזה. משתמש יכול להחליף הקשר כאורח, כן, אבל קופ העילות עדיין מוגבל לדייר אחד בכל פעם. הוא לא ממזג דיירים מרובים לסביבת עבודה חכמה אחת עבור תשובה אחת. לכן, זהות יכולה לעבור, ממשל לא. וברגע שמפרידים בין השניים האלה, הרבה שפה ניהולית מתחילה להישמע מעורפלת באופן מסוכן. דיירים מחוברים, זהות משותפת, חוויה מאוחדת. ביטויים אלה עשויים להיות נכונים מבחינה כיוונית לשיתוף פעולה, אך הם אינם זהים לאמירה שאכיפת מדיניות, בסיס נתונים, רישום ואימות בקרה פועלים כעת כמערכת אחת.

פער זה הופך להיות בולט עוד יותר כשמסתכלים על מצב מרובי דיירים של Copilot Studio, מכיוון שהתצוגה המקדימה מספרת סיפור ספציפי מאוד. כן, קיים שימוש מרובי דיירים, וסוכן שמתארח בדייר אחד יכול לשמש מדייר אחר, אך אימות משתמש קצה במצב מרובי דיירים עדיין אינו נתמך בתצוגה המקדימה. משתמשי אורחים אינם נתמכים. מחברים מותאמים אישית אינם נתמכים. מחברים סטנדרטיים של גראפ ומיקרוסופט 365 אינם נתמכים. ריבוי גיאוגרפי אינו נתמך. מספר יכולות ניתוח אינן זמינות. תמלילי שיחות קבועים גם במצב זה. זהו אינו מערג ממשל בוגר בין דיירים. זוהי תצוגה מקדימה מוגבלת עם מגבלות ברורות. והמגבלות הללו חשובות משום שהן שוברות את הסיפור שרבים מצוותי ההנהלה מספרים לעצמם. הם שומעים מלטאי טננט ומניחים בגרות תפעולית. הארכיטקטים שלהם שומעים קרוס טננט ומניחים סימטריה של מדיניות. צוותי הבקרה שלהם שומעים אותו ספק ומניחים עקביות בביקורת. לאחר מכן, הפרסה מתחילה ואנשים מגלים התנהגויות שונות, אותות חסרים ופערים מביכים סביב אימות ואנליטיקה. דמיינו את המקרה השני.

חברה גלובלית מקימה כשרי גומלין תוך ארגוניים בין דיינים ומניחה שחוויית המשתמש תתארך באופן טבעי לשימוש בקופילות. הציפייה נשמעת סבירה הכוללת אמון בספריות משותפות, גישה חלקה יותר ודפוסי זהות משותפים. אבל כאשר צוותים בודקים תרחישים אמיתיים של קופיילות וסוכנים, ההתנהגות אינה אחידה. חלק מהנתונים מופיעים רק בהקשרים מוחלפים. חלק מהמחברים הצפויים אינם זמינים. חלק מציפיות הביקורת אינן תואמות את מה שתכונות התצוגה המקדימה חושפות בפועל. ההנהלה עדיין שומעת, מחובר, בעוד שצוות הבקרה מתחיל למצוא חריגים. זה לא מקרה של קצה טכני. זוהי קריאת ממשל שגויה. מכיוון שמבקרים לא בודקים את סיפור הארכיטקטורה שלך, הם בודקים ראיות. הם שואלים היכן רצו הנחיות, איזו מדיניות נאכפת על ידי דיירים, אילו יומני רישום קיימים, והאם הבקרות שלך היו באמת דומות בין הסביבות שתיארת כמקושרות. אם מודל ההפעלה שלך התייחס לזהות כממשל, לא תהיה לך התשובה ברורה. אז, אם אתה זוכר שורה אחת כאן, כתוב אותה כך. זהות בין דיירים אינה בינה בין דיירים. זהות עוזרת למשתמשים להיכנס.

היא לא אומרת לך אם התנהגות קופיילוט נשלטת באופן עקבי, מנותרת כראוי, או בטוחה להרחבה על פני כל המקומות שהארגון שלך מחנה כעת סביבה אחת. וברגע שזה מתבהר, התשובה לא יכולה להיות יותר חיבורי דיירים. זו חייבת להיות ארכיטקטורה.

היא רק חלקית, וגבולות הדיירים עדיין באמת חשובים. זה נראה כמו מערכת רכזת וספירה. אני לא מציע את זה בגלל שהדיאגרמה נראית נקייה בשקופית, אלא בגלל שהיא באמת תואמת את תנאי ההפעלה המבולגנים שאתה מתמודד איתם כרגע. אתה צריך מקום מרכזי אחד שבו החלטות ממשל מתוכננות, נמדדות ונאחפות כמערכת אחת, ואז אתה צריך צוותי דיירים מקומיים כדי לבצע את ההחלטות האלה. צוותים מקומיים אלה צריכים לעבוד בתוך הגבולות שלהם מבלי להמציא גרסה משלהם של הכללים בכל פעם שהם מרגישים קצת לחץ. אנחנו צריכים להתחיל עם המרכז. המרכז אינו פורטל ניהול, הוא אינו לוח מכוונים מבריק, והוא בהחלט אינו צוות מרכזי הרועי שקופץ לכל דייר יחיד כדי לנקות קבצים באופן ידני. במקום זאת, המרכז משמש כסמכות הממשל האולטימטיבית. קבוצה זו מחזיקה בעיצוב המדיניות, קווי הבסיס של הביקורת, תקני הטוויות וקריטריוני הפריסה. הם אלה שמחליטים מה המשמעות של מוכן לקופילות, אילו ראיות נחשבות כהוכחה, וכמה מהר יש לסגור פער הבטחה. שינוי זה משנה את כל השיחה. בגלל מבנה זה, גלובלי, מפסיק להיות מילה למסך קסום אחד ומתחיל להתייחס למערכת ממשל מאוחדת אחת.

אתה מקבל תקן אחד לבקרות תחום אחריות, תקן אחד לאופן שבו אתה בולע ביקורות, וסטנדרט אחד לטוויות הרגישות שלך. יש רף ברור אחד למה שחייב להיות נכון לפני שכל דייר ספציפי רשאי להרחיב את גישת קופה אילות למשתמשים נוספים. אחר כך אתה צריך את החישורים. הסיפוקים הם צוותי ביצוע הדיירים המקומיים שלכם, שלוקחים את קו הבסיס הזה ומיישמים אותו בסביבה הספציפית שלהם. הם אלה שמפעילים את התיקון, מעמתים את הלוגים ובודקים הרשאות גישה רחבות. עם זאת, הם עושים את כל העבודה הזו בתוך מרחב עיצוב צר מאוד ולא בתוך מרחב של חופש לכולם. אם צוות מקומי צריך לסתות מהתוכנית, יש נתיב רשמי לחריגים. ואם הם רוצים להתקדם מהר יותר, הם עדיין צריכים לעמוד תחילה בבקרות המשותפות. כאשר צצים הבדלים אזוריים או משפטיים, בעיות אלו מתועדות ומאושרות במקום להיספק בשקט בפתרון מקומי כלשהו שאף אחד אחר לא יודע עליו. מבנה זה חיוני מכיוון שמודלים מרכזיים לחלוטין בדרך כלל נחנקים בפרטים מקומיים, בעוד שמודלים מקומיים לחלוטין נסחפים לחוסר עקביות מוחלט כמעט מיד.

רכזת וסיפוקים נמנעים משני דפוסי הקשל הללו. הרכזת נותנת לכם את העקביות שאתם צריכים, בעוד שהסיפוקים נותנים לכם את מהירות הביצוע במקום שבו העבודה מתרחשת בפועל. בואו נהפוך את זה למוחשי. ברכזת, אתם מגדירים את מערך בקרות המינימום שכל דייר חייב להפעיל לפני שקופילות יורשה לגדול. אתם מגדירים בדיוק אילו אירועי ביקורת אתם מצפים לראות ובאיזו תדירות תבדקו אותם. אתם גם יוצרים טקסונומיה משותפת של תוויות עבור תוכן רגיש, כך שתגיד סודית לא אומרת חמישה דברים שונים על פני חמישה דיירים שונים. אתם קובעים את הקצב לזכירות, אולי חודשיות עבור מצב ההבטחה הכולל שלכם, ובהתדירות גבוהה יותר באזורים שבהם הפרסה פעילה כאה. בנקודת ההתחלה, הצוות שלכם ממפה את הסטנדרטים ברמה גבוהה למציאות של הדייר הספציפי הזה. הם מוצאים אילו אתרים עדיין חשופים לגישה רחבה ואילו יחידות עסקיות מפגרות מאחור בתוויות שלהן. הם בודקים אם הביקורת אכן מופעלת ועם הרשומות הנכונות גלויות לצוות ההבטחה. הם מחפשים מנהלים מקומיים שאולי הציגו חריגים שמעולם לא נבדקו רשמית.

והם מחליטים אם קבוצת פיילוט יכולה להתרחב בביטחה או אם עליהם לעצור ולתקן דברים קודם. והנה הכלל הקשה כי בלי כלל, מודל זה הוא רק הצעה במקום ממשל בפועל. פריסת קו פיילוט לא מתרחשת באף דייר ללא רישום ביקורת, מעומת, שריקת שיתוף יתר הושלמה וקו בסיס מינימלי לחיסוי תוויות. אני לא מדבר על דברים אלה שמתוכננים או נדונים חלקית. יש לאמת אותם. אם דייר לא יכול להוכיח ששלושת התנאים הללו מתקיימים, הפריסה מושהה. זה אולי נשמע מחמיר עד שמשווים את זה לעלות העצומה של ניקוי בלגן אחרי שמשתמשים מתחילים למצוא תוכן רגיש שמעולם לא התכוונתם לחשוף באמצעות בינה מלאכותית. כשמסתכלים על זה ככה, הכללים האלה הם פשוט היגיון בריא בסיסי. סיבה נוספת לכך שהמודל הזה עובד כל כך טוב היא התזמון. ככל שמחכים יותר זמן להגדיר את זה, כך יוצרים לעצמכם יותר חוב ניקוי בהמשך. כל דייר שמפורס לפני קו הבסיס הופך לצבר עצום נוסף של חריגים וראיות חסרות שהצוות שלכם יצטרך בסופו של דבר להיפטר ממנו. מנהיגים מתייחסים לעיתים קרובות לממשל כמשהו שיכול להבשיל לאחר סיום האימוץ.

אבל בעולם של קופ איילוט מרובד דיירים, הרצף הזה הפוך לחלוטין. הממשל צריך להוביל את הפריסה או שהפריסה תיצור יותר חוב ממה שהצוותים שלכם יוכלו אי פעם לקוות לספוג. אם אתם מובילים את זה ברמת הארגון, הצעד הבא שלכם ברור מאוד. עציבו את המרכז עכשיו והגדירו את קו הבסיס הזה עוד היום. הקצו את החישורים שלכם וחתבו את תהליך הטיפול בחריגים שלכם בכתב באופן מיידי. עליכם להפוך את המשמעות הגלובלית לכך שההחלטות שלכם ושערי הפריסה שלכם יעבדו כמערכת אחת, גם כאשר הדיירים עצמם לא עושים זאת. מודל חשוב רק אם הוא באמת משנה את מה שנאחף מחר בבוקר. מה מנהיגים צריכים למדוד לפני שהם מתרחבים? מודל ממשל מחזיק מעמד רק אם הוא מייצר מדידות שכולם חולקים. אחרת, כל דייר יטען שהוא מתקדם בשפה שלו, וההנהגה תקבל עדכוני סטטוס מבלי שתהיה לה שליטה אמיתית. לפני שאתם מרחיבים את קופ אילוט עוד יותר, אתם צריכים קבוצה קטנה של מדדים שיגידו לכם אם הארכיטקטורה מתנהגת כפי שאתם חושבים שהיא. רמות הפעילות לא יגידו לכם את האמת, ומספרי אימוץ בהחלט לא יראו לכם את הסיכונים.

כדאי להתחיל עם צמצום שיתוף יתר. זהו עדיין אחד הסימנים הברורים ביותר לכך שהסביבה שלכם הופכת לבטוחה יותר עבור בינה מלאכותית. אתם צריכים לבחון קבוצות גישה רחבות, אתרי שירפוינט כתוכים והרשאות ישנות שמעניקות גישה רבה יותר ממה שהעסק באמת צריך. המטרה כאן אינה להגיע למספר מושלם, אלא להוכיח שהחשיפה שלכם יורדת לפני שהטווח של קופ אילוט שלכם עולה. אם שני הקווים הללו נעים בכיוונים מנוגדים, אתם מתרחבים הרבה יותר מהר ממה שאתם מתקנים את הבעיות הבסיסיות. המדד השני שאתם צריכים הוא כיסוי תצפית. האם אתם באמת יכולים לראות מה קופ אילוט עושה בכל הדיירים שלכם באופן שתומך בחקירה אמיתית? רוב המחקרים מצביעים על Microsoft Purview כמקום העיקרי שבו מאוחסנות רשומות ליבה כמו אינטראקציה עם קופ אילוט, אך זה מניח שביקורת מופעלת בכל מקום. כיסוי אינו משהו שאתם יכולים פשוט להניח שהוא עובד. אתם צריכים לדעת בדיוק אילו דיירים פעילים את תהליך בליאת הביקורת ואילו עדיין משאירים אתכם עם נירות חלקית. אם אין לכם יומני רישום, אין לכם שליטה ואין לכם אחריות.

זה נשמע בוטה כי זה חייב להיות. אם דייר לא יכול לספק ראיות שמישות למה שקורה, הדייר הזה לא מוכן להתרחב בצורה בטוחה. אינכם יכולים לשלוט במה שאתם לא רשאים לבדוק, ובוודאי שלא תוכלו להגן על פעולותיכם עם מה שהוא ישתבש מאוחר יותר. המדד השלישי הוא הזמן שלכם למדיניות בכל הדיירים. כאן ההנהגה מגלה אם מודל ה-Hub and Spock הוא אכן אמיתי או סתם דקורטיבי. החלטה מרכזית לא אומרת כלום אם דייר אחד אוכף אותה השבוע, בעוד שאחר ממתין חודש לחשוב עליה. עליכם למדוד את הזמן שלוקח מאישור מדיניות ועד להכיפה יעילה של מדיניות זו בכל דייר בודד. אני לא מדבר על הזמן שלוקח להכריז על זה או לתעד את זה, אלא על הזמן עד שזה באמת פעיל. עבור תוכנית בינה מלאכותית שמתקדמת כל כך מהר, עיכוב כזה הוא פשוט מילה אחרת לסיכון. יעד מעשי עבור רוב הארגונים הוא פחות מממינוס 72 שעות לשינויים סטנדרטיים. אם זמן המחזור שלכם ארוך בהרבה מזה, עדיין אין לכם מודל ניתן להרחבה. יש לכם פשוט בעיית תאום שצריך לפתור. בשלב הבא, עליכם לבחון את יחס כיסוי התביעות שלכם.

אל תתנו לזה להפוך למדד יהירות שבו דייר אחד מגיע למספרים גבוהים בעוד שאחרים מפגרים. מה שבאמת חשוב הוא האם התוכן הרגיש שלכם מתויג באופן עקבי מספיק, כדי שהתנהגות קופה אילות לא תתבסס רק על ניחושים של משתמשים. אתם לא מחפשים שלמות כאן, אלא אתם מחפשים רמת שליטה דומה בכל דייר בארגון. לבסוף, עליכם לעקוב אחר קצב סך הפגישה שלכם. מדד זה אומר לכם האם מאמצי הניקוי שלכם באמת נשארים לאורך זמן. לאחר שתסיימו פרויקט תיקון, באיזו מהירות ההרשאות הללו מתחילות להתפשט שוב? באיזו תדירות הקבוצות הרחבות הללו זוכלות חזרה למערכת? צוותים רבים מבינים זאת מאוחר מדי, משום שמדדו את התיקון פעם אחת והניחו שהבעיה נעלמה לתמיד. זה לא קרה. המדד היחיד שחשוב הוא כמה מהר המערכת מתחילה להחליק ברגע שמפסיקים להסתכל עליה. זהו לוח המכוונים התפעולי שלכם. עליכם לעקוב אחר צמצום שיתוף יתר, כיסוי תצפיות, זמן עד למדיניות, כיסוי תוויות וסחיפת גישה. קצב הדיווח שלכם חשוב בדיוק כמו המספרים עצמם. המרכז צריך להיות הבעלים של לוח המכוונים הניהולי, משום שההנהגה זקוקה לי תצוגה אחת ויחידה של המצב כולו.

בינתיים, הדוברים צריכים להיות הבעלים של התיקון, משום שהעבודה בפועל צריכה להתרחש במקום בו נמצא גבול הדיירים. צוות אחד קורא את המערכת והצוות השני מתקן אותה. עליכם לעקוב אחר המספרים הללו לפני שאתם מרחיבים, לא לאחר מעשה. הסיכון אינו בהמתנה לפגישה הבאה או לסדנת הממשל שלכם. הוא כבר פעיל בכל דייר, שם קופיילוט יכול למצוא בדיוק את מה שהבקרות הנוכחיות שלכם עדיין מאפשרות לו לראות. שני הדפוסים שמנהיגים ממשיכים להחמיץ. אני ממשיך לראות שני דפוסים ספציפיים בשטח, ושניהם קורים משום שמנהיגים מתייחסים לקופילוט כמו להשקת תוכנה במקום לאירוע בקרה גדול. הדפוס הראשון מתחיל כאשר ארגון פורס את קופיילוט לפני קביעת קו בסיס אמיתי של תחום פעילות או סקירת גישת שרפוינט שלו. ביום הראשון, הפריסה נראית מושלמת. רישיונות מוקצים, משתמשים נרגשים, והמסרים הפנימיים עוסקים כולו בפריון. אבל אז, הנחיות רגילות מתחילות לשלוף חומר שהיה נגיש מבחינה טכנית כל הזמן, אך כמעט בלתי נראה לעובד הממוצע. לפני הבינה המלאכותית, אף אחד לא בילה את יומו בלחיצה על אתרים ישנים, תיקיות ישנות או הרשאות בירושה כדי למצוא דברים שלא אמורים לראות.

אבל עכשיו, הם לא צריכים. משתמש שואל שאלה בסיסית, סיכום חוזר וקובץ מופיע. אולי זה תוכן רגיש של משאבי אנוש או חומר פיננסי או מידע על עסקה שהיה אמור להישאר במעגל צר מאוד. לא הייתה פרצה, לא תוכנות סדוניות ולא גבול אבטחה שבור במובן המסורתי. המערכת פשוט השתמשה בהרשאות ובמצב התוכן שהדייר כבר אפשר. זה הרגע שבו צוותים רבים סוף סוף מבינים את הבעיה. הבינה המלאכותית לא יצרה את החשיפה. היא פשוט הסירה את החיכוך שנהג להסתיר אותה. ברגע שזה קורה אצל דייר אחד, אמון ההנהלה בדרך כלל יורד בכל הארגון. משום שאף אחד לא יכול לומר בוודאות היכן אותו דפוס עשוי להופיע בהמשך. האירוע אולי נראה מקומי, אך הנזק לאמון הוא כלל ארגוני. הדפוס השני שקט יותר, אך מסוכן באותה מידה. חברה מקימה כשרי זהות בין דיירים, שומעת שתרחישים מרובי דיירים אפשריים, ומניחה שמודל התפעול שלה הבוגר מספיק לפריסה רחבה. במצגת, זה נשמע כמו תוכנית מוצקה. במציאות, הפעילות הופכת למבולגנת. צוות אחד מצפה לחוויית קופיילות חלקה בכל סביבה מחוברת. בעוד שאחר מצפה לנירות דומה, ושלישי מניח שאותן בקרות יעקבו אחר המשתמש לכל מקום.

לאחר מכן, השימוש בפועל מתחיל לחשוף התנהגות לא אחידה, פערים בעימות ונקודות טורפה במה שניתן למדוד בפועל. הבעיה אינה שהצוותים הללו היו רשלניים. הבעיה האמיתית היא שהם תרגמו קישוריות להבטחה. הנחה זו יוצרת סיפור כוזב לגבי תאימות. ההנהגה שומעת את המילה מחובר, ומניחה שהארגון מוכן. חודשים לאחר מכן, סקירות בקרה מגלות שההתנהגות, הראיות והאכיפה היו מגוונות הרבה יותר ממה שמי שהוא רצה להודות בהתחלה. עכשיו, השבו את זה לדפוס טוב יותר. ארגון אחר בוחר להעט לפני שהוא מתרחב. הם קובעים תחילה קו בסיס לתוית, הם סוקרים תחילה גישה רחבה, והם מעמתים את נראות הביקורת שלהם לפני שהם עושים משהו אחר. הם מרחיבים את קופ העילות בגלים, לא בגלל שהם חוששים מאימוץ, אלא בגלל שהם רוצים שכל גל ייצר ראיות שמישות לפני שהבא מתחיל. ארגון זה בדרך כלל נה מהר יותר בטווח הארוך מכיוון שהוא לא עוצר כל הזמן כדי להסביר הפתעות, לנקות תוכן חשוף, או להתווכח על מה שהממשל אמור היה להביע בפועל. זהו היתרון שרוב המנהיגים מפספסים. ממשל טוב לא חושם את הפריסה שלכם.

הוא מסיר את הגרירה מהפריסה לאחר סיום הגל הראשון. המלכודת אינה האימוץ עצמו. המלכודת היא אימוץ לא מנוהל על פני דיירים שנראים מחוברים מרחוק, אך מתנהגים בצורה שונה מאוד כשמתקרבים. ההחלטה שאתם צריכים לקבל היא למעשה פשוטה מאוד. אתם צריכים לעבור למודל ממשל בינה מלאכותית מאוחד של רכזת וסופר עכשיו, ואתם צריכים להפסיק לטעות בין החלפת אפשרויות בין דיירים לדיירים לבין שליטה בפועל. עליך להשהות את הרחבת קופיילות שלך בכל דייר שלא יכול להוכיח את הרישום שלו, את ביקורות השיתוף יתר שלו ואת כיסוי הבסיס של התוויות שלו. בינה מלאכותית תעקוב אחר המערכת שאתה בונה בפועל, לא אחר תרשים הארגון שאתה מדווח אליו. אם זה שינה את האופן שבו אתה חושב על ניהול קופיילות מרובי דיירים, עקוב אחריי, מרקו פיטרס, בלינקטין, ושתפו זאת עם הצוות שלך אם אתם מתמודדים עם בעיות אלה כרגע.