סוכני AI ב-SAP: פתיחות למתחרים לא מבטלת את התלות בספק
המשמעות העסקית של פלטפורמת הסוכנים של SAP היא האפשרות לחבר AI לתהליכי הליבה, ולא רק להוסיף ממשק שיחה למערכת. הפתיחות המוצהרת לסוכנים של ספקים אחרים חשובה, אבל היא אינה מבטיחה עצמאות טכנולוגית. לארגונים בישראל כדאי לבחון את המהלך דרך שלוש שאלות: מה הסוכן רשאי לבצע, מי אחראי לתוצאה, וכמה יעלה להעביר את התהליך לפלטפורמה אחרת.
העמדה שלנו ברורה: ארגון שנשען על SAP צריך לבחון ברצינות את היכולות החדשות, אך לא למסור לספק אחד את כל הידע, התזמור והבקרה של מערך הסוכנים שלו רק משום שהחיבור הראשוני נוח.
מה SAP מציעה, ומה באמת משתנה
בכנס SAP TechEd הציגה החברה הרחבה של SAP Business AI Platform, לצד Joule Studio, סביבת העבודה Joule Work, שכבת SAP Knowledge Graph וענן הנתונים SAP Business Data Cloud. לפי הודעת החברה, הפלטפורמה ורכיביה המרכזיים זמינים כעת באופן כללי; בכל התקשרות עדיין צריך לבדוק זמינות אזורית, רישוי ותמיכה בתרחיש המסוים.
ההיגיון מאחורי המהלך נכון: סוכן עסקי זקוק ליותר ממודל שפה מוצלח. הוא צריך להבין מהי הזמנת רכש, כיצד ספק קשור לחשבונית, איזו הרשאה נדרשת לשינוי תנאי תשלום ואילו מגבלות חלות על הפעולה.
Joule Work מיועד להיות נקודת הכניסה של העובד, בעוד Joule Studio ויכולות התזמור מאפשרים לבנות ולחבר את העבודה שמתרחשת מאחוריו. שכבת הידע נועדה לספק הקשר עסקי וקשרים בין נתונים. זו הבחנה חשובה: מודל יכול לנסח תשובה משכנעת גם כשהוא אינו מבין נכון את המשמעות הארגונית של הנתון.
ל-SAP יש נקודת פתיחה חזקה בארגונים שבהם תהליכי הכספים, הרכש והאספקה כבר מנוהלים במערכותיה. עם זאת, יתרון בגישה לנתונים אינו תחליף לבדיקת איכותם, להסדרת הרשאות או להגדרת בעל תפקיד שאחראי לתוצאה.
פלטפורמה פתוחה אינה תהליך נייד
SAP מצהירה ששער הסוכנים שלה יאפשר פעולה הדדית עם סוכנים חיצוניים, ושמרכז הסוכנים יאפשר לאתר, לתעד ולנהל גם סוכנים שאינם מתוצרתה. זו התפתחות חיובית: ארגון לא צריך לבחור ספק יחיד לכל משימה.
אבל צריך להפריד בין היכולת לחבר סוכן חיצוני לבין היכולת להחליף את התשתית שמפעילה אותו. אפשר להחליף מודל ועדיין להישאר תלויים בשכבת הידע, במחברים, במנגנוני ההרשאות ובכלי הניטור של ספק אחד.
גם SAP מכירה בכך שהתאמה עמוקה לתרחיש עסקי יוצרת מידה של נעילה. לכן שאלת הרכש החשובה אינה רק אילו מודלים נתמכים, אלא אילו נכסים הארגון יכול לקחת איתו אם יחליט לעזוב.
| שכבה | מה לבדוק לפני התחייבות |
|---|---|
| מודל | החלפה ללא שינוי מהותי בתהליך |
| ידע עסקי | ייצוא הגדרות וקשרים סמנטיים |
| תזמור | ניידות לוגיקת התהליך |
| הרשאות | שליטה בזהות ובהיקף הגישה |
| בקרה | גישה ליומנים ולנתוני הערכה |
הטבלה מציגה מבחני רכש, לא קביעה שהפלטפורמה עומדת בהם או נכשלת בהם. את התשובות צריך לקבל בהדגמה ובחוזה. הבטחת פתיחות במצגת אינה מספיקה כאשר רוצים לייצא תיעוד, להחליף רכיב או לשחזר החלטה לצורך ביקורת.
אדם בלולאה, אבל לא בכל לחיצה
נניח שחברה ישראלית מבקשת לטפל בפערים בין הזמנות רכש לחשבוניות ספקים. סוכן יכול לאסוף מסמכים, לזהות את מקור הפער, לפנות לגורם המתאים ולהציע טיפול. מכאן לא נובע שעליו לקבל הרשאה לשנות פרטי בנק או לאשר תשלום.
החלוקה הנכונה היא בין פרשנות והמלצה, שבהן AI יכול להתמודד עם מידע לא אחיד, לבין ביצוע פעולות רגישות, שצריך להגביל באמצעות כללים קשיחים. סכום, סוג ספק, חריגה ממדיניות ושינוי בפרטי תשלום יכולים לשמש תנאים להעברה לבדיקה אנושית.
אדם בלולאה אינו עובד שמאשר אוטומטית כל הצעה. הוא בעל סמכות שמפקח על התהליך, מתערב בחריגים ויכול לעצור את הסוכן.
אם כל חשבונית תדרוש אותה עבודת בדיקה כמו קודם, הארגון הוסיף מערכת בלי לשנות את כלכלת התהליך. המטרה היא שמנהל יוכל לפקח על תיק מקרים רחב באמצעות תעדוף חריגים, דגימות ובקרה, במקום לבצע ידנית כל טיפול.
חשוב גם לא להפוך את ציון הביטחון של המודל למנגנון האישור היחיד. ההחלטה אם לפעול צריכה להתבסס על מדיניות עסקית, בדיקות נתונים והשלכות אפשריות של טעות.
את התשואה מודדים אחרי עלות הפיקוח
הפער בין כלי שעוזר לעובד לבין מערכת שמשפרת ביצועים ארגוניים נמצא לעיתים קרובות בתפעול. קיצור זמן ניסוח של הודעה אינו מבטיח קיצור של מחזור הרכש, במיוחד אם ההודעה יוצרת בדיקות נוספות בהמשך.
לכן כדאי למדוד זמן סגירה מקצה לקצה, שיעור טיפול חוזר, עלות למקרה, היקף התערבות אנושית ושגיאות בעלות משמעות עסקית. מול התועלת צריך להציב גם את עלויות הרישוי, השימוש במודלים, האינטגרציה, התחזוקה והבקרה.
בוחרים תהליך מדיד
מגדירים בעיה תפעולית עם בעל תפקיד אחראי ותוצאה עסקית ברורה.
קובעים קו בסיס
מודדים זמני טיפול, עלויות ושגיאות לפני הכנסת הסוכן.
תוחמים סמכויות
מגדירים אילו פעולות מותר לבצע ואילו מחייבות אישור או עצירה.
בודקים בתנאי אמת מבוקרים
מתחילים בהרשאות מצומצמות ובוחנים גם חריגים וכשלים.
מרחיבים לפי תוצאה
מגדילים את היקף הפעילות רק כשהתועלת נשמרת לאחר עלויות הפיקוח.
זהו מסלול שמחייב שיתוף פעולה בין תפעול, כספים, מערכות מידע ואבטחת מידע. הוא גם מסביר מדוע הטמעת AI אינה פרויקט טכני בלבד: מי שלא מכיר את התהליך המקצועי עלול לבצע אוטומציה של הנחה עסקית שגויה.
לא כל בעיה עסקית צריכה מודל שפה
לצד הסוכנים הציגה SAP את SAP-RPT-2.0, מודל לעבודה עם נתונים טבלאיים. לפי החברה, הוא מרחיב את היכולות גם לזיהוי חריגות ולניתוח המבוסס על ייצוגים וקטוריים, עם תמיכה בעבודה על פני כמה טבלאות.
ההכרזה הזאת חשובה דווקא משום שהיא מזכירה ש-AI ארגוני אינו מסתכם בשיחה. חיזוי תקלה, איתור עסקה חריגה והערכת סיכון עשויים לדרוש מודל ייעודי לנתונים מובנים. סוכן יכול לתזמר את העבודה ולהסביר את הממצאים, אך אינו חייב להיות הרכיב שמחשב את התחזית.
בארגון ישראלי שמנהל מלאי, אשראי או ייצור, בחירת סוג המודל צריכה לנבוע מהבעיה ומהבדיקות המקצועיות, לא מהפופולריות של ממשק מסוים.
היכולת שצריכה להישאר בתוך הארגון
פלטפורמה טובה יכולה לקצר את הדרך להקמת סוכנים. היא לא פוטרת את הארגון מבניית יכולת פנימית להגדיר, לבדוק ולנהל אותם. מחלקת מערכות המידע תידרש בהדרגה לנהל גם מחזור חיים של כוח עבודה דיגיטלי: הקצאת סמכויות, הערכת ביצועים, שינוי תפקיד והוצאה משימוש.
במקביל נדרשת אוריינות AI לעובדים. אלה שני מסלולים משלימים: כלי אישי דורש הרגלי עבודה חדשים ויכולת לתקשר עם מודלים; סוכן המשולב בתהליך קיים יכול לפעול מאחורי הקלעים ולדרוש פחות שינוי מהמשתמש, אך יותר משמעת הנדסית וניהולית.
המבחן הזה דורש צוות עם ידע מעמיק ב-AI, הכשרה רלוונטית וניסיון בתהליכים עסקיים. היכרות עם כלי בנייה אינה שקולה להבנת בקרות פיננסיות, שרשרת אספקה או ניהול סיכונים.
ההזדמנות במהלך של SAP היא לחבר סוכנים לעבודה האמיתית של הארגון. האחריות של ההנהלה היא לוודא שהחיבור הזה נשאר מדיד, נשלט וניתן לשינוי. לפני הרחבה ארגונית, בקשו לראות תהליך אחד שעובד, כשל אחד שמטופל כראוי, ודרך יציאה שאינה נשארת הבטחה.
