התשובה הקצרה
בדיקת מוכנות ל-Agentforce עולה שבועות ספורים; פיילוט שנכשל עולה חודשים ואמון פנימי. לכן שווה לענות מראש על חמש שאלות: האם קיים תהליך מוגדר עם בעלים, האם הנתונים שהסוכן יסתמך עליהם אמינים, האם קיים מאגר ידע מתוחזק, האם מודל ההרשאות ברור, והאם יש מי שיתפעל את הסוכן אחרי ההשקה.
הבדיקה אינה שאלה של כן או לא. היא מייצרת ציון לכל ציר ומפה של פערים, ומאפשרת החלטה מדויקת יותר: להתחיל, לצמצם Scope, או לדחות ולסגור פער ספציפי קודם.
מסגרת ההחלטה על התאמת Use Case מופיעה בAgentforce לארגונים.
חמשת צירי המוכנות
| ציר | השאלה המכרעת | סימן חולשה | סף מינימלי לפיילוט |
|---|---|---|---|
| תהליך | האם התהליך מוגדר ויש לו בעלים בשם? | כל צוות מבצע אחרת ואין מסמך | תהליך אחד מתועד עם Owner ונפח ידוע |
| נתונים | האם השדות שהסוכן יקרא מהימנים? | שדות ריקים או ממולאים בטקסט חופשי | 90% שלמות בשדות הקריטיים לתהליך |
| ידע | האם קיים מקור מאושר לתשובות? | מאמרים ישנים או סותרים | 20 מאמרים מעודכנים לתרחישים הנפוצים |
| הרשאות | האם ברור מה כל משתמש רשאי לראות ולעשות? | הרשאות רחבות ולא מבוקרות | מיפוי Profiles ו-Permission Sets לתהליך |
| תפעול | מי מנטר, מתקן ומאשר שינויים? | אין בעלים אחרי ההשקה | Owner תפעולי ושגרת סקירה שבועית |
ציר 1: התהליך
הכשל הנפוץ ביותר אינו טכנולוגי. ארגונים בוחרים תהליך שאין לו בעלים, ואז אין מי שיכריע בשאלות שעולות תוך כדי בנייה: מה קורה בחריג, מתי מסלימים, מה נחשב תשובה נכונה. בלי הכרעה, הצוות הטכני ממציא כללים והעסק בודק לפי ציפייה אחרת.
בדיקה מעשית: לבקש את התיאור של התהליך בכתב מארבעה אנשים שמבצעים אותו. אם מתקבלות ארבע גרסאות שונות מהותית, התהליך אינו בשל לאוטומציה של סוכן - הוא בשל לתיעוד ולהסכמה קודם.
צריך גם נפח. תהליך שקורה עשר פעמים בחודש לא יצדיק את עלות הבנייה והתחזוקה, גם אם הוא מרגיז. מועמד טוב הוא תהליך בעל נפח משמעותי, חזרתיות גבוהה, ושונות בניסוח הפנייה - בדיוק המקום שבו כללים נוקשים נשברים.
ציר 2: הנתונים
לא נדרשת איכות נתונים מושלמת בכל ה-Org. נדרשת איכות בשדות שהסוכן יקרא או יעדכן בתהליך שנבחר. הבדיקה היא צרה ומדידה: לוקחים את רשימת השדות הרלוונטיים ומודדים שלמות, עקביות ערכים וכפילויות ברשומות הקשורות.
שלוש בדיקות שמניבות תשובה מהירה: אחוז השדות הקריטיים המלאים, מספר הרשומות הכפולות באובייקט המרכזי, ואחוז המקרים שבהם המידע הדרוש מגיע ממערכת חיצונית ולא מ-Salesforce. הבדיקה השלישית היא זו שמפתיעה - היא חושפת תלות באינטגרציה שלא תוקצבה.
טקסט חופשי הוא דגל אדום מיוחד. כשמידע מהותי חי בשדה הערות, הסוכן יצטרך להסיק אותו, וזה בדיוק המקום שבו נוצרות טעויות שקשה לאתר.
הסדר המומלץ לטיפול בפערי נתונים מפורט במדדי איכות נתונים ב-Salesforce.
ציר 3: הידע
הידע נבדק לא לפי כמות אלא לפי כיסוי ותוקף. לוקחים את עשרים הפניות הנפוצות ביותר ובודקים לכל אחת: האם יש מאמר מאושר, מתי עודכן, ומי הבעלים. כיסוי של חצי מהתרחישים עם מאמרים עדכניים עדיף על כיסוי מלא במאמרים ישנים.
סימן חולשה שקל לפספס: מאמרים שנכתבו לקהל פנימי בלבד ומשמשים במקביל לתשובות ללקוח. הם מכילים ניסוחים, מחירים או חריגים שאסור לחשוף החוצה, וההפרדה חייבת להיעשות לפני החיבור.
ציר 4: ההרשאות
הסוכן פועל בשם משתמש, ולכן מודל ההרשאות הקיים הופך למודל האבטחה של ה-AI. אם ההרשאות רחבות ולא מבוקרות היום, הסוכן יגדיל את החשיפה ולא ייצור אותה. הבדיקה בוחנת שלושה דברים: מי רשאי לקרוא את הנתונים בתהליך, אילו פעולות כתיבה נדרשות, ומי מאשר פעולה רגישה.
לכל פעולה שהסוכן יבצע צריך להגדיר האם היא הפיכה. פעולה בלתי הפיכה - זיכוי כספי, סגירת תיק, שליחת מסר ללקוח - מחייבת נקודת אישור אנושית בשלב הראשון, ולכן היא משפיעה על תכנון התהליך ולא רק על ההגדרות.
תכנון נקודות האישור לפי סיכון מפורט בHuman-in-the-Loop ב-Agentforce.
ציר 5: התפעול
סוכן אינו פרויקט עם תאריך סיום. הוא רכיב שדורש ניטור Traces, טיפול בכשלים, עדכון תוכן ובקרת עלות. ארגון שאין לו מי שיעשה זאת - ולו במשרה חלקית - יראה ירידה הדרגתית באיכות בתוך רבעון.
המינימום: בעלים תפעולי בשם, שגרת סקירה שבועית של שיחות שנכשלו, תהליך שינוי מוסכם לעדכון Instructions, ותקציב חודשי מנוטר. אם אף אחד מהארבעה אינו קיים, הפער בציר הזה גדול מכפי שנראה בתחילת הדרך.
תרגום הציון להחלטה
| מצב | פירוש | פעולה מומלצת |
|---|---|---|
| כל הצירים בסף ומעלה | מוכנות מלאה | פיילוט על תהליך אחד עם קריטריוני Go/No-Go |
| חולשה בתפעול בלבד | ניתן לפצות בליווי | פיילוט עם ליווי חיצוני ובניית יכולת פנימית במקביל |
| חולשה בידע בלבד | פער תוכן ממוקד | ארבעה עד שישה שבועות של הכשרת Knowledge, ואז פיילוט |
| חולשה בנתונים או בהרשאות | סיכון מהותי | לא להתחיל בסוכן; לסגור את הפער כפרויקט נפרד |
| חולשה בשלושה צירים ומעלה | הארגון אינו בשל | לבחור תת-תהליך צר יותר ולבדוק מחדש |
תרחיש: ארגון פיננסי שגילה שהתהליך הלא נכון נבחר
ארגון פיננסי ביקש סוכן לטיפול בבקשות שינוי פרטי לקוח. בבדיקת המוכנות התברר שהתהליך עובר דרך שתי מערכות חיצוניות, שכל שינוי מחייב אישור רגולטורי, ושהנפח החודשי צנוע. הציר של ההרשאות והציר של הנתונים קיבלו ציון נמוך.
באותה בדיקה עלה תהליך אחר שאיש לא חשב עליו: מענה על שאלות סטטוס לגבי בקשות קיימות. הוא נשען על שדה אחד אמין ב-Salesforce, אינו כולל פעולת כתיבה, והנפח שלו גבוה פי שמונה. הפיילוט הועבר לתהליך הזה.
התוצאה המעשית של הבדיקה לא הייתה "מוכנים או לא מוכנים", אלא החלפת המועמד. זו התרומה העיקרית של בדיקת מוכנות - היא זולה מספיק כדי להריץ אותה על שלושה מועמדים ולבחור את זה עם התלויות הקטנות ביותר.
Checklist מוכנות
- ☐ נבחר תהליך מועמד יחיד עם בעלים בשם
- ☐ נמדד הנפח החודשי ושיעור החזרתיות
- ☐ נבדקה שלמות השדות הקריטיים לתהליך
- ☐ נבדקו כפילויות באובייקט המרכזי
- ☐ זוהו תלויות במערכות חיצוניות
- ☐ מופה כיסוי Knowledge לעשרים הפניות הנפוצות
- ☐ הופרד תוכן פנימי מתוכן שמותר ללקוח
- ☐ מופו הרשאות קריאה וכתיבה לתהליך
- ☐ סווגו פעולות הפיכות מול בלתי הפיכות
- ☐ הוגדר בעלים תפעולי ושגרת סקירה אחרי ההשקה
כאשר נדרש גורם חיצוני שיריץ את הבדיקה ויתרגם אותה ל-Roadmap, שירות Agentforce ו-AI הוא המסלול המעשי להמשך.