המבחן האמיתי של הטמעת AI בארגון נמצא בשורת הרווח

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

נגה מילוסלבסקי הנדלר VP Product & AI ב-Commit

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

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

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

הערך נמצא בתהליך ולא במודל

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

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

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

הדרך למדידה מתחילה בשאלה עסקית

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

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

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

מקרה בוחן שמציג תוצאה בתוך שבועיים

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

בשלב הזה, עבודה במודל של Forward Deployed Engineer יכולה לקצר משמעותית את הדרך מתכנון לבחינה בפועל. ה- FDEעובד בצמוד לצוות העסקי, מבין את התהליך ואת המערכות הקיימות ומחבר ביניהם לבין יכולות  ה-AI. כך ניתן לבצע התאמות תוך כדי תנועה, לבחון במהירות מה עובד ולמקד את הפיתוח במקומות שמשפיעים בפועל על המדד העסקי שנבחר.

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

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

התרחבות דורשת Orchestration וGuardrails

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

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

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

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

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