איך לבנות תהליך escalations לחריגים שאוטומציה לא צריכה לפתור לבד

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

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

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

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

מה ההבדל בין התראה, העברת משימה והסלמה?

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

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

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

להגדיר טריגר לפי ההשפעה העסקית

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

לכל סוג חריג הגדירו:

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

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

להפריד בין זמן תגובה לזמן פתרון

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

לפני שמגדירים את השעונים, החליטו עם בעלי התהליך:

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

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

לבנות העברת אחריות שלא משאירה חלל

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

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

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

דוגמה להמחשה: עדכון שאושר אך תוצאתו אינה ידועה

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

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

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

איזה מידע צריך להגיע עם ההסלמה?

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

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

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

למנוע התראות כפולות והסלמות אחרי סגירה

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

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

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

לסגור חריג רק אחרי אימות עסקי

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

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

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

איך לבדוק את המסלול ב-POC?

בחרו חריג אחד ובדקו לא רק אם הודעה נשלחת, אלא אם המסלול נשאר ניתן לניהול בתנאים הבאים:

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

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

שאלות נפוצות

האם כל חריג צריך להגיע למנהל?

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

האם AI יכול לבחור למי להסלים?

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

האם צריך מערכת חדשה לניהול ההסלמות?

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

הצעד הבא: למפות מסלול אחד מקצה לקצה

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

אם התהליך חוצה SAP, APIs ומערכת משימות, אפשר להתחיל מ[שיחת התאמה עם Adaptico](/#contact) ולבחון POC ממוקד שמחבר בין פריט החריג, ההחלטה העסקית והעדכון המבוקר. ניתן לקרוא גם על [שירותי האוטומציה והאינטגרציה](/#services) כדי למקם את הצורך בתוך התהליך הקיים.