Reef TRHבכל רבעון חוזרת על עצמה אותה סצנה מוכרת בארגונים רבים. צוות פיתוח מציג אב-טיפוס של AI שנראה כאילו הוא עובד כמו קסם. ההנהלה מתלהבת, התקציב מאושר והציפיות בשמיים. חצי שנה לאחר מכן, אותו פיילוט נגנז בשקט על המדף, עוד מצבה בבית הקברות ההולך וגדל של אבות-טיפוס שמעולם לא הגיעו לאף משתמש קצה.
הנתון הבא כבר מוכר, והוא כואב: בערך 80% מפיילוטי ה-AI בארגונים אינם מגיעים לפרודקשן. האמת הלא נוחה היא שהכישלון כמעט אף פעם אינו קשור למודל עצמו, אלא לפער העצום שבין הדגמה סטרילית בארגז חול לבין המציאות המורכבת של היומיום העסקי.
אב-טיפוס מוכיח שהרעיון ישים. הוא לא מוכיח שאפשר להעלות אותו לפרודקשן. אלו שני אתגרי פיתוח שונים לחלוטין, ורוב הצוותים מתקצבים רק את הראשון.
שלושה מכשולים שכל פיילוט נתקע בהם בדרך לפרודקשן
כשהדגמה מבטיחה נתקעת, זה קורה כמעט תמיד בגלל שלושה מכשולים קבועים. אף אחד מהם לא צץ בסביבה מבוקרת, וזו בדיוק הסיבה שההדגמה נראתה כל כך טוב בהתחלה.
- איכות הדאטה קורסת במעבר לסקייל. בשלב ההדגמה הדאטה נקי, מסודר ונבחר בקפידה. בפרודקשן, הדאטה הארגוני האמיתי מפוזר בין מערכות CRM מבוזרות, מערכות ERP מיושנות וגיליונות אקסל מבודדים. כשהקלט משובש, הפלט יהיה לא אמין, ואף מודל, מתקדם ככל שיהיה, לא יוכל לפצות על תשתית דאטה שבורה.
- מקרי קצה משבשים את הכל. משתמשים אמיתיים מאתגרים את גבולות המערכת בדרכים שהדגמה מתוסרטת מראש לא יכולה לצפות. הם שואלים שאלות לא צפויות, מזינים קלט משובש ומותחים את גבולות התהליך. בנקודה הזו מערכות AI מתחילות להזות, להמציא נהלים שלא היו מעולם, או פשוט לקרוס.
- האינטגרציה מורכבת יותר מה-AI עצמו. חיבור המודל למערכות legacy דורש התמודדות עם מגבלות קצב של API, מנגנוני אימות ופרוטוקולי אבטחת מידע קשוחים. בפועל, בניית תשתיות הדאטה האלה דורשת לעיתים קרובות הרבה יותר מאמצי פיתוח מאשר בניית המודל עצמו.
ארבעה מהלכים שיביאו את ה-AI שלכם לקו הסיום
כדי להימנע מבית הקברות הזה, לא צריך מודל טוב יותר, אלא גישה נכונה יותר. ארבעה עקרונות פשוטים מפרידים בין הפיילוטים שמגיעים לאוויר לבין אלה שנשארים מאחור.
1. תעדפו את התהליך על פני הטכנולוגיה
התחילו מהבעיה העסקית ומהתהליך האנושי שאתם רוצים לשפר, ולא מהמודל שבו אתם רוצים להשתמש. בחירת הטכנולוגיה צריכה להיות ההחלטה האחרונה בתהליך, כזו שנובעת מהבנה עמוקה של נקודות החיכוך האמיתיות בארגון.
2. בחנו קודם את ארכיטקטורת הדאטה
עוד לפני שכותבים שורת קוד אחת, מפו היכן הדאטה שלכם באמת נמצא, עד כמה הוא נקי ואיך הוא זורם בארגון. הבדיקה הזו אולי אינה זוהרת, אך היא הצעד המשמעותי ביותר שתוכלו לעשות כדי להפחית את הסיכונים בפרויקט.
3. הגדירו guardrails למה שה-AI לא יכול לעשות
תכננו מראש מענה למקרי הקצה שנוטים להכשיל הדגמות. הגדירו מראש לוגיקת גיבוי, מגבלות ברורות ומנגנוני כשל בטוחים. guardrails הם לא פיצ'ר שמוסיפים ברגע האחרון, הם ההבדל בין מערכת יציבה שאפשר להציג ללקוחות לבין מערכת שלא ניתן לסמוך עליה.
4. קנו מוצרי מדף כשאפשר
לא כל רכיב חייבים לפתח מאפס. במקומות שבהם מוצר מדף בשל נותן מענה מצוין, השתמשו בו, ושמרו את הפיתוח הייעודי לחלקים שמייצרים עבורכם יתרון תחרותי אמיתי.
העיקרון שמוביל אותנו פשוט אך קל לפספס אותו: הטמעת AI מוצלחת היא אתגר של ניהול מוצר, לא רק של פיתוח. היא דורשת גורם מקשר שיכול לשבת עם ההנהלה, להגדיר מה נכון לבנות, ואז להוביל את הפיתוח והעלייה לפרודקשן בלי שדברים ילכו לאיבוד בדרך.
שלב העברת המקל, בין האנשים שמבינים את הביזנס לבין אלו שיודעים להעלות את הקוד לאוויר, הוא המקום שבו רוב פרויקטי ה-AI קורסים. אם תבטלו את הנתק הזה, תבטיחו שהפרויקט שלכם לא יסיים בבית הקברות.