איך מזהים Use Case טוב ל-AI (ומתי לא לגעת בזה בכלל)

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

זו בדיוק הנקודה שהכי הרבה עסקים מפספסים: השאלה החשובה היא לא "איך משתמשים ב-AI", אלא "האם יש לנו בכלל בעיה שה-AI פותר טוב יותר ובזול יותר ממה שקורה היום". רוב הפרויקטים שנכשלים לא נכשלים כי הטכנולוגיה לא עבדה – הם נכשלים כי מעולם לא היה שם Use Case אמיתי מלכתחילה.

שלוש השאלות שאני שואלת בכל שיחת אפיון

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

שאלה 1: זה קורה מספיק פעמים שזה משנה?

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

שאלה 2: יש לנו כבר דרך לעשות את זה, גם אם היא איטית?

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

שאלה 3: אנחנו יודעים להגדיר מה נחשב "נכון"?

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

דוגמה אמיתית: ה-Use Case שדחיתי

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

דוגמה אמיתית: ה-Use Case שהומלץ ועבד

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

מה קורה כשמדלגים על הבדיקה הזו

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

שתי טעויות נפוצות בזיהוי Use Case, גם אצל אנשים חכמים

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

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

מסגרת עבודה: מרעיון לפתרון

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

1. מיפוי תהליכים חוזרים – רשימה של כל מה שקורה בעסק בתדירות גבוהה ולוקח זמן אנושי.
2. דירוג לפי תדירות ועלות זמן – לא לפי "כמה זה נשמע מגניב", אלא לפי שעות בפועל.
3. בדיקת קיום דוגמאות אמת – האם יש כבר איך התהליך נעשה היום, שאפשר ללמוד ממנו?
4. הגדרת קריטריון הצלחה אחד, ברור וניתן למדידה, לפני שכותבים שורת קוד.
5. רק אז – בחירת הארכיטקטורה המתאימה (בוט, Assistant או סוכן).

מתי בכלל לא כדאי לגעת ב-AI כרגע

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

מה קורה אחרי שמצאתם Use Case טוב

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

סיכום

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

רוצים לעבור על התהליכים שלכם ולבדוק יחד אילו מהם באמת מוכנים ל-AI?

קבעו איתי שיחת אפיון אסטרטגית >