לפני שמכניסים סוכן AI, מוחקים שלב אחד
# לפני שמכניסים סוכן AI, מוחקים שלב אחד
העמדה שלי פשוטה: לפני שמלמדים סוכן AI לבצע תהליך, צריך לנסות למחוק ממנו שלב אחד.
זה נשמע כמעט קטן מדי. הרי אם כבר משקיעים בחיבור מערכות, הרשאות, בדיקות ומדידה, טבעי לרצות שהסוכן יטפל בכל המסלול. אבל תהליך עסקי אינו חוק טבע. הוא אוסף של החלטות שהצטברו: טופס שנוסף אחרי טעות, אישור שנולד בגלל עובד שכבר עזב, גיליון שנועד לגשר בין שתי מערכות, והעתקה ידנית שאיש אינו זוכר מי ביקש.
סוכן AI מסוגל לבצע גם שלבים מיותרים במהירות מרשימה. זו בדיוק הבעיה. מהירות יכולה להסתיר בזבוז במקום לפתור אותו.
השאלה המרכזית במאמר הזה היא לא מה אפשר להעביר לסוכן. השאלה היא איזה שלב בתהליך לא היה נבנה אילו היינו מתכננים אותו היום.
## אוטומציה טובה יכולה לקבע החלטה גרועה
ניקח תהליך מוכר: בקשת רכש פנימית עוברת מהעובד לראש הצוות, משם למנהלת תפעול, אחר כך לכספים, ואז בחזרה לעובד כדי שיזין את אותם פרטים במערכת אחרת. כל תחנה נראית הגיונית כשמסתכלים עליה לבד. יחד מתקבל מסלול שאיש אינו מחזיק.
עכשיו מחברים סוכן AI. הוא קורא את הבקשה, בודק אם חסר מידע, מכין הודעה לכל מאשר ומעתיק את התוצאה למערכת היעד. זמן הטיפול מתקצר. עדיין נשארת שאלה מטרידה: למה מנהלת התפעול מאשרת רכישה שכבר אושרה בתקציב המחלקה? אם היא רק מוודאת שקוד העלות קיים, אולי אין כאן החלטה אנושית. יש בדיקת שדה.
אפשר להפוך את הבדיקה לאוטומטית. אפשר גם לבטל את התחנה ולהכריח את הבקשה להגיע מראש עם קוד עלות תקין. האפשרות השנייה משנה את התהליך. הראשונה רק מפעילה אותו מהר יותר.
אני בעד סוכנים אוטונומיים, מן הסתם. זה מה שאנחנו בונים ב־AI BUDDY. אבל סוכן אינו הצדקה להשאיר כל תחנה בחיים. לפעמים הערך הכי טוב שלו הוא לחשוף עד כמה התחנה הייתה מיותרת מלכתחילה.
## חפשו שלב שאין לו החלטה משלו
לכל שלב מוצדק צריך להיות פלט שאי אפשר לקבל בלעדיו: החלטה, מידע חדש, שינוי מחייב או בקרה שנדרשת מסיבה ברורה. אם שלב רק מעביר משהו שכבר קיים, משנה פורמט או מבקש מאדם לאשר כלל קבוע, הוא מועמד לבדיקה.
הדרך הכי נקייה למצוא אותו היא לקחת מקרה אחד שהושלם ולכתוב ליד כל תחנה שני משפטים:
* מה נכנס לתחנה הזאת?
* מה חדש כשהעבודה יוצאת ממנה?
אם התשובה השנייה היא "אותו מידע, רק במייל אחר", מצאתם העתקה. אם התשובה היא "מישהו ראה", מצאתם אישור שאולי אינו מחזיק החלטה. אם התשובה היא "הפרטים סודרו לפי תבנית", מצאתם עבודת המרה. כל אלה עשויים להיות נחוצים, אבל הם צריכים להוכיח את עצמם.
נניח שהצעת מחיר עוברת לנציג בכיר לפני שליחה. אם הבכיר בודק חריגת הנחה, תנאי תשלום או התחייבות לא שגרתית, יש לו החלטה מוגדרת. אם הוא קורא כל הצעה כי "ככה עושים", השלב רחב מדי. אפשר להעביר אליו רק חריגים ולהשאיר את המסלול הרגיל בלי תחנת המתנה.
זו אינה סמנטיקה. ברגע שמגדירים מהי ההחלטה, אפשר לכתוב לה כלל, לבדוק אותה ולתעד מי נושא באחריות. בלי הגדרה, גם הסוכן וגם האדם נאלצים לנחש מה האישור אמור להשיג.
## שלושה סימנים שהשלב שרד במקרה
הסימן הראשון הוא נתונים כפולים. עובד ממלא שם חברה, סכום ותאריך בטופס, ואז מקליד אותם שוב ב־CRM או במערכת הנהלת חשבונות. ההקלדה השנייה אינה מוסיפה ידע. היא מפצה על חיבור חסר או על בחירה לא ברורה של מקור המידע.
הסימן השני הוא אישור שמתקבל תמיד. שיעור אישור גבוה אינו בהכרח הוכחה שהבקשות מצוינות. לפעמים המאשר יודע שאין טעם להתעמק, לוחץ "מאושר" ומחזיר לעסק תחושת בקרה. כדי לבדוק זאת, פותחים כמה מקרים ושואלים מה השתנה בעקבות הבדיקה. אם איש אינו זוכר דחייה, תיקון או תנאי שנוסף, ייתכן שהשלב מספק טקס במקום הגנה.
הסימן השלישי הוא תחנת ביניים שנוצרה בגלל מגבלה ישנה. פעם המערכת לא תמכה בשדה מסוים, לכן הצוות פתח גיליון. מאז המערכת הוחלפה, אבל הגיליון נשאר. הוא כבר אינו פותר מגבלה. הוא פשוט קיבל מעמד של מסורת ארגונית, מהסוג שאף אחד לא אוהב אבל כולם מאכילים.
שימו לב למה שאין ברשימה: זמן ארוך. שלב יכול לקחת שתי דקות ולהיות מיותר. שלב אחר יכול לקחת יום ולהיות חיוני, למשל בדיקת סיכון לפני התחייבות כספית. השאלה אינה כמה זמן הוא צורך. השאלה היא מה הוא משנה.
## המחיקה צריכה לעבור מבחן, לא ישיבת שכנוע
לא מוחקים שלב כי הוא מעצבן. בודקים מה יקרה בלעדיו.
בחרו עשרים מקרים שהושלמו לאחרונה, או מדגם קטן יותר אם התהליך נדיר. עברו על התוצאה של השלב החשוד: אילו מקרים השתנו בזכותו, איזה נזק נמנע, ומה היה קורה אילו הבקשה הייתה ממשיכה בלעדיו. אין צורך להמציא אחוזי הצלחה. צריך לראות את המקרים עצמם.
אחר כך מריצים מסלול צל. השלב נשאר פעיל, אבל במקביל מתעדים מה הייתה עושה גרסה בלעדיו. אם מדובר באישור, בודקים אילו בקשות היו עוברות אוטומטית לפי הכלל ואילו היו נעצרות כחריגות. אם מדובר בהעתקה, שולחים את הנתונים ישירות למערכת היעד בסביבת בדיקה ומשווים את הרשומות.
המבחן צריך להגדיר מראש מה ייחשב כישלון. לדוגמה: שדה חובה חסר, התחייבות שחורגת מהסמכות, שיוך ללקוח הלא נכון או מצב שבו אין אדם שמקבל בעלות. כשיש כשל, לא מחזירים אוטומטית את כל השלב. בודקים אם חסרה תחנה שלמה או רק כלל צר.
יש הבדל גדול בין "כל הצעה חייבת אישור" לבין "הצעה עם הנחה חריגה חייבת אישור של בעל סמכות". המשפט השני נותן לעסק גבול שאפשר להפעיל, למדוד ולהסביר.
## ומה אם השלב הוא שכבת ההגנה היחידה?
זאת ההתנגדות הנכונה. תהליכים מסוימים נראים מסורבלים מפני שהם מגינים על כסף, פרטיות, בטיחות או התחייבות חוזית. מחיקה עיוורת יכולה להפוך שיפור תפעולי לנזק יקר.
לכן לא שואלים רק אם השלב מוסיף מידע. שואלים גם איזה סיכון הוא מחזיק. אדם שמאשר שינוי חשבון בנק של ספק עשוי לא להוסיף פרט חדש, ובכל זאת ההפרדה בינו לבין מי שהזין את הבקשה היא בקרה חשובה. במקרה כזה לא מוחקים את האישור. מחדדים אותו, מציגים למאשר את הראיות הנכונות ומונעים מהסוכן לבצע את הפעולה בלי הסכמה.
גם כאן הגדרה מדויקת עוזרת. "מנהלת בודקת את הבקשה" הוא תיאור חלש. "מנהלת מאמתת ששינוי פרטי התשלום הגיע מערוץ מאושר וששני המזהים תואמים" הוא שלב עם תפקיד.
הכלל שלי הוא למחוק תנועה, לא אחריות. אם שלב נושא אחריות אמיתית, היא צריכה להישאר אצל בעל תפקיד מוגדר. אפשר לצמצם את ההקלדה, להכין עבורו את החומר או להפנות אליו רק חריגים. אי אפשר להעלים את האחריות בתוך תיבה שחורה ולקרוא לזה יעילות.
## רק עכשיו מחליטים מה הסוכן מקבל
אחרי שמסירים תחנה מיותרת, התפקיד של הסוכן נעשה קטן וברור יותר. במקום לרדוף אחרי ארבעה אישורים, הוא עשוי לבדוק תנאים, להכין רשומה, להעביר חריג אחד לאדם המתאים ולתעד את ההחלטה. פחות צעדים, פחות הרשאות ופחות מקומות שבהם ההקשר יכול להתפצל.
זה גם משנה את שאלת הרכישה. כבר לא מבקשים "סוכן שינהל את כל תהליך הרכש". מבקשים יכולת מוגדרת: לקבל בקשה מלאה, לאמת אותה מול מקור תקציבי, להעביר חריגה לאישור ולרשום את התוצאה. קל יותר להשוות פתרונות כשהתהליך אינו מסתיר בתוכו עבודת העתקה וטקסים.
לפעמים נגלה שאין צורך בסוכן AI בכלל. אם כל העבודה שנותרה היא העברת שדות קבועה בין שתי מערכות, אוטומציה רגילה עשויה להספיק. זאת אינה אכזבה. זאת החלטה טובה שחוסכת מערכת מורכבת במקום שבו חיבור פשוט עושה את העבודה.
ובמקרים שבהם נשארת קריאת טקסט, הבנת הקשר, טיפול בחריגים או הכנת החלטה, סוכן יכול לקבל תפקיד אמיתי. הוא כבר לא מציג הצגה של התהליך הישן. הוא עובד בתוך תהליך שתוכנן מחדש.
## השאלה שאיתמר מלול שואל בחדר
כשאנחנו ממפים תהליך ב־AI BUDDY, אני אוהב לשאול: אם העסק היה נפתח הבוקר, האם היינו בונים את השלב הזה?
זו שאלה מעט לא מנומסת. היא עוקפת הסברים כמו "תמיד עשינו כך" ו"המערכת דורשת". היא מחזירה את הדיון לתוצאה. לפעמים התשובה היא כן, מפני שהשלב מחזיק החלטה או סיכון. לפעמים התשובה היא לא, ואז אין סיבה לשלם כדי ללמד מכונה לשמר אותו.
בחרו השבוע תהליך אחד וסמנו את התחנה שאין לה החלטה משלה. אל תבטלו אותה מיד. קחו מקרים אמיתיים, הגדירו מה עלול להישבר והריצו מסלול צל. אם יתברר שהשלב רק מעביר, מעתיק או מאשר אוטומטית, מחקו אותו לפני שאתם כותבים שורת פרומפט אחת.
אם תרצו לעשות את הבדיקה על תהליך אמיתי, הביאו ל[פגישת גילוי אוטומציה](/automation-discovery) צילום של המסלול ומקרה אחד שהושלם. ננסה למחוק תחנה אחת לפני שנציע מה לחבר לסוכן.