למה 80% מפרויקטי AI נכשלים, ואיך להימנע מזה

מאת ארד פנחס7 דק׳ קריאהפורסם עודכן

בקצרה

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

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

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

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

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

האם באמת 80% מפרויקטי ה-AI נכשלים?

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

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

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

למה פרויקטי AI נכשלים?

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

מתחת לסיבה הכללית הזאת יש כמה סיבות מעשיות שחוזרות שוב ושוב.

1. מתחילים מהטכנולוגיה ולא מהבעיה

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

2. הנתונים לא מוכנים

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

3. אין בעלים מצד העסק

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

4. לא הוגדר מראש מה נחשב הצלחה

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

5. מתעלמים מהאנשים

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

6. הפער בין פיילוט לשימוש אמיתי

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

מה ההבדל בין פרויקט AI לפרויקט תוכנה רגיל?

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

בפועל זה אומר כמה דברים:

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

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

איך בוחרים את פרויקט ה-AI הראשון?

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

הטבלה הבאה עוזרת לסנן רעיונות:

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

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

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

איך מגדירים הצלחה לפני שמתחילים?

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

מדד טוב הוא כזה שגם ההנהלה וגם הצד הטכני מבינים ומסכימים עליו. כמה דוגמאות:

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

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

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

אילו סימנים מראים שפרויקט AI בדרך לכישלון?

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

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

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

איך מגדילים את סיכויי ההצלחה של פרויקט AI?

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

תוכנית עבודה בשבעה צעדים

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

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

בשורה התחתונה

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

שאלות נפוצות

כמה זמן לוקח לראות תוצאות מפרויקט AI?

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

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

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

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

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

עדיף לפתח פתרון AI ייעודי או לקנות כלי מוכן?

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