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

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

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

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

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

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

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

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

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

3. משתמשים בחישוב שקוף

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

בהנחת עלות עבודה מלאה של 100 ש״ח לשעה, לזמן שמתפנה יש ערך מחושב של כ־2,670 ש״ח. אם תוכנה ותחזוקה עולות 600 ש״ח בחודש, הערך החודשי נטו הוא כ־2,070 ש״ח. בהנחת עלות הקמה של 8,000 ש״ח, תקופת ההחזר הפשוטה על בסיס זה היא כ־3.9 חודשים.

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

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

4. מתכננים מה קורה כשמשהו משתבש

אוטומציה אמינה צריכה מסלול חריגים גלוי:

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

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

5. מתחילים בניסוי לפני שמרחיבים

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

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

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

לקריאה נוספת

McKinsey: What is digital transformation? מספק הקשר על ערך עסקי, מודל עבודה והטמעה. החישובים ורשימת הבדיקות כאן הם עיבוד מעשי מקורי שלנו; המקור אינו מאמת את ההחזר שבדוגמה.