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