ירידת הפרודוקטיביות אחרי אוטומציה: מה היא אומרת וכמה זמן היא אמורה להימשך

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

מה הנתונים מראים

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

הכלכלנים אריק ברינג'ולפסון, דניאל רוק וצ'אד סיברסון נתנו לדפוס הזה שם במחקרם על טכנולוגיות תשתית כלליות, שפורסם כ-NBER Working Paper מספר 25148 ובהמשך בכתב העת American Economic Journal: Macroeconomics. הם קוראים לזה עקומת ה-J של הפרודוקטיביות. הטענה שלהם היא שטכנולוגיה חדשה, בין אם זה CRM, פלטפורמת BI, או תהליך עבודה אוטומטי, דורשת סדרת השקעות בלתי מוחשיות לפני שהיא משתלמת: תהליכים מעוצבים מחדש, הרגלים שנלמדים מחדש, וניקוי נתונים. ההשקעות האלה מופיעות כעלות מיידית וכתועלת רק בהמשך, וזו הסיבה שהתפוקה הנמדדת יכולה לרדת מתחת לנקודת ההתחלה לפני שהיא עולה מעליה.

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

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

למה הירידה לא אומרת בהכרח כישלון

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

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

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

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

מה הופך ירידה תקינה לפרויקט שנכשל

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

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

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

שלוש דרכים לנהל את הירידה במקום להגיב אליה

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

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

מה שווה לעשות קודם

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

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

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

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