דילוג לתוכן
בחזרה לבלוג

איזה תהליך עסקי כדאי להפוך לאוטומטי קודם?

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

בחירת אוטומציהכ־5 דקות קריאה
המחשה של ארבע קוביות עץ אדומות עומדות ברצף קצר, וקוביות אפורות נפרדות מונחות מאחוריהן
איור להמחשה

מגדירים עבודה שיש לה התחלה וסוף

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

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

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

לפני שמשווים כדאיות, בודקים מוכנות

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

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

דוגמה היפותטית: שלושה תהליכים אצל מפיץ

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

מחשבים גם את העבודה שתישאר

נמשיך בדוגמה ההיפותטית של ההזמנות. נניח שהצוות מטפל ב־240 הזמנות מתאימות בחודש, וכל אחת דורשת ארבע דקות עבודה פעילה: 960 דקות בסך הכול. לצורך תכנון הפיילוט, נניח ש־192 הזמנות רגילות ידרשו דקת בדיקה אחת כל אחת, ו־48 הזמנות חריגות עדיין ידרשו ארבע דקות כל אחת. נוסיף 120 דקות בחודש לניטור ולניהול התהליך.

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

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

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

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

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

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

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

מגדירים לפי מה מרחיבים, משנים או עוצרים

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

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

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

מקורות וקריאה נוספת

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

הביאו שניים או שלושה תהליכים, את המערכות שמעורבות בהם ואת המקומות שבהם העבודה נתקעת. נעזור להגדיר היקף ממוקד ואת הבדיקות הדרושות לו.

נדבר על התהליך שלכם
Nexo