סקילים של AI בארגון: ההימור שחוסך שעות ומתעד

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

מה זה סקיל, ולמה הוא לא סתם פרומפט?

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

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

למה סקילים של AI בארגון הם ההימור המרכזי?

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

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

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

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

למה תיעוד הוא תנאי לכל מה שבא אחר כך?

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

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

ההבדל נראה כך:

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

איך מגיעים לשני סקילים לכל אדם?

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

הדרך שעובדת נראית בערך כך:

1. מתחילים מהכאב. מבקשים מכל אדם להביא תהליך שהוא שונא בשקט. משהו חוזר ומעייף, שלוקח זמן ולא דורש שיקול דעת מיוחד. הכאב הוא הקלט הטוב ביותר.
2. מתארים את התהליך בקול. לפני שכותבים מילה, האדם מסביר מה הוא עושה, צעד אחרי צעד. כאן מתגלים הכללים הלא כתובים: החריגים, הבדיקות שעושים ״תמיד קודם״, הדברים שעושים על אוטומט.
3. כותבים את הסקיל. קלט, צעדים, כללים, ודוגמה לתוצר טוב. בשפה פשוטה. בלי קוד.
4. מריצים על מקרים אמיתיים. לא על דוגמה מומצאת, אלא על העבודה של השבוע. בודקים איפה התוצאה סטתה, ומחדדים.
5. משתפים. סקיל שעובד עובר לחברים בצוות. כל שיפור שלהם משפר גם את התיעוד.
6. בונים את השני לבד. את הסקיל השני האדם בונה בלי ליווי צמוד. זה המבחן האמיתי.

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

איך נראית הכשרה שמייצרת סקילים?

הדרכה כללית על איך משתמשים בכלי לא מייצרת סקילים. היא מייצרת אנשים שיודעים איפה הכפתורים. מה שעובד הוא הכשרה עמוקה: לשבת עם הצוותים ולבנות יחד על התהליכים האמיתיים שלהם.

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

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

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

מה הסימן שהגישה עובדת, ולמה הוא גם סימן אזהרה?

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

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

המנגנון יכול להיות פשוט מאוד:

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

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

איך מודדים התקדמות בסקילים?

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

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

רוצים שכל אחד בצוות שלכם יצא עם שני סקילים עובדים? לסדנאות שלנו.