למה פיילוטים של AI נתקעים - וארבעה תנאים שמוציאים מהם

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

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

דפוס 1: הפיילוט נבחר לפי מה שקל להדגים

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

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

דפוס 2: אין מדד לפני

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

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

דפוס 3: המערכת בנויה בצד, לא בתוך התהליך

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

התנאי: האוטומציה יושבת בתוך הכלי שבו הצוות כבר עובד - ה-CRM, מערכת הכרטיסים, תיבת המייל - או שהיא לא תשמש אף אחד.

דפוס 4: אין בעלות אחרי ההשקה

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

התנאי: בעלות מוגדרת, תקציב תחזוקה, ומדידה רבעונית שמוצגת להנהלה.

מה שאנחנו עושים אחרת

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

זה מייצר פחות התלהבות בישיבת ההנהלה הראשונה, ויותר תוצאות ברבעון השני. בסוף זה מה שנמדד.