כדאיות אוטומציה עסקית: איזו עבודה נשארת אחרי הפיתוח?

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

מה אפשר ללמוד מצמצום קופות השירות העצמי?

במאי 2024 דיווח Retail Dive על צמצום השירות העצמי ב־Dollar General. לפי דברי המנכ״ל שצוטטו, הרשת הסירה קופות שירות עצמי מ־12 אלף חנויות ותכננה לצמצם אותן ברוב החנויות. המהלך הוצג כחלק ממאמץ רחב להפחתת אובדן מלאי, לצד צעדים נוספים. זהו דיווח היסטורי, ולא הוכחה לכך שכל אובדן המלאי נגרם מהקופות או לכך שהסריקה עצמה תמיד עבדה היטב.

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

צופים בעבודה לפני שמפרקים אותה לפיצ׳רים

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

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

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

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

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

מחשבים עלות כוללת עם הנחות גלויות

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

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

דוגמה מתועדת מתהליך הפרסום של Julius

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

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

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

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

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