איך להפוך חריגים חוזרים לכללי אוטומציה מבוקרים

קטגוריה: AI & אוטומציה | תאריך: ספטמבר 2026

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

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

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

למה חריג חוזר הוא הזדמנות לאוטומציה?

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

לדוגמה:

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

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

מתי לא כדאי לאוטומט חריג?

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

כדאי להיזהר במיוחד כאשר:

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

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

איך מזהים שהחריג בשל לכלל?

חריג מתאים לאוטומציה כאשר אפשר לענות בצורה ברורה על ארבע שאלות:

1. מה בדיוק התנאי שמפעיל את הכלל? לדוגמה, שדה חסר, סטטוס לא תואם, תשובת API מסוימת או קובץ במבנה מוכר.
2. מה הפעולה המותרת? השלמת נתון, פתיחת משימה, retry, שינוי סטטוס, או עדכון מערכת דרך API.
3. מתי לא מפעילים את הכלל? כללים טובים יודעים לעצור כאשר יש מידע חסר, סתירה או סיכון.
4. איך יודעים מה קרה? חייב להיות לוג עסקי שמראה את הקלט, הכלל, הפעולה והתוצאה.

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

איך נראה כלל אוטומציה מבוקר?

כלל מבוקר הוא לא רק תנאי ופעולה. הוא חלק מתהליך שיש בו גבולות.

כלל כזה צריך לכלול:

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

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

דוגמה: חריג בקובץ ספק

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

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

בשלב הבא אפשר להגדיר כלל:

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

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

דוגמה: retry לכשלון API

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

כלל מבוקר יכול להגדיר:

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

כך התהליך מטפל לבד במה שבאמת זמני, אבל לא מסתיר כשלון מתמשך ולא ממשיך לנסות בלי גבול.

איפה נכנס אישור אנושי?

אישור אנושי לא חייב להישאר לנצח בכל תהליך. לפעמים הוא שלב ביניים חשוב לפני אוטומציה.

אפשר לעבוד בשלושה שלבים:

1. המלצה: המערכת מזהה חריג ומציעה פעולה, המשתמש מאשר.
2. אוטומציה עם בקרה: המערכת מבצעת את הפעולה רק כאשר התנאים ברורים, ומעבירה חריגים לאדם.
3. הרחבה מדודה: מוסיפים עוד תנאים וכללים רק אחרי שמודדים תוצאות.

הגישה הזאת מתאימה במיוחד לארגונים עם SAP, BI, APIs ומערכות פנימיות שבהן עדכון לא נכון יכול להשפיע על תהליך רחב יותר.

מה חשוב למדוד?

כדי לדעת אם הכלל באמת עוזר, צריך למדוד יותר מאשר "האם הוא רץ".

מדדים שימושיים:

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

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

איך להתחיל ב-POC קטן?

POC טוב לכללי חריגים לא צריך להתחיל מכל התהליך. הוא צריך לבחור חריג אחד שחוזר הרבה וקל יחסית להגדיר.

אפשר להתחיל כך:

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

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

שאלות שכדאי לשאול לפני בניית הכלל

לפני שמפתחים כלל אוטומציה לחריג חוזר, כדאי לענות על כמה שאלות:

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

השאלות האלה עוזרות להפוך "חריג מעצבן" לתהליך קטן שאפשר לשלוט בו.

סיכום

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

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

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

הצעד הבא

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