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