אוטומציה של הדברים הלא נכונים רק מגדילה את הבלגן מהר יותר. הנה למה טעויות האוטומציה הגדולות מתחילות עוד לפני הקוד, ואיך לבחור את האוטומציה הראשונה שבאמת משתלמת.
לרוב פרויקטי האוטומציה הכושלים שאני נקרא לתקן יש אותו שורש, וכמעט אף פעם זו לא הטכנולוגיה. מישהו לקח תהליך שהיה איטי, בזבזני או פשוט שבור, ואיטמט אותו בדיוק כפי שהיה. עכשיו הוא מריץ את אותה טעות אלף פעמים בשעה במקום עשר פעמים ביום. העסק הוציא כסף אמיתי כדי להפוך תהליך גרוע למהיר יותר, וזה בדיוק ההפך ממה שרצה. זו התבנית היקרה ביותר שאני רואה, והיא לחלוטין נמנעת.
אני בונה אוטומציה למחייתי, ואשמח לשכנע כל אחד לוותר על אוטומציה שלא צריכה להתקיים. זה לא אומר שאני משאיר כסף על השולחן. זה אומר שאני מוודא שהעבודה שלי באמת מחזירה את עצמה, כי לקוח שנכווה מאוטומציה של הדבר הלא נכון בדרך כלל לא מנסה שוב. אז הרשו לי להיות ישיר לגבי הטעויות, ואז לתת לכם את סדר הפעולות שבאמת עובד.
למה אוטומציה של הדברים הלא נכונים מחמירה הכל
אוטומציה היא מכפיל. זו כל המטרה שלה, וזו גם המלכודת. מכפיל לא מתעניין אם הדבר שהוא מכפיל טוב או רע. אם תהליך המעקב אחרי לידים שלכם מאבד לידים כי אף אחד לא בטוח מי אחראי על תשובה, אוטומציה לא תפתור את בעיית האחריות. היא פשוט תאבד לידים לפי לוח זמנים, עם תיעוד נקי, מהר יותר ממה שאדם אי פעם יכול.
גרוע מכך, אוטומציה מסתירה את הבעיה. כשאדם עושה משימה מסורבלת ביד, הוא מרגיש את החיכוך ומתלונן עליו. התלונה הזו היא מידע. כשעוטפים את אותה משימה מסורבלת בסקריפט, החיכוך נעלם מהעין אבל הבזבוז לא. שילמתם כדי להפוך תהליך גרוע לבלתי נראה. חצי שנה אחר כך אף אחד לא זוכר למה המערכת עושה מה שהיא עושה, והפרימה של זה עולה יותר מהבנייה המקורית.
יש גם מס תחזוקה. כל אוטומציה היא פיסת תוכנה קטנה שצריך להחזיק בחיים: ממשקי API משתנים, התחברויות פגות, מקרי קצה צצים. אם איטמטתם תהליך שמספק מעט ערך, אתם משלמים את המס הזה לנצח כמעט בלי שום תמורה. השאלה הנכונה לעולם אינה ״האם אפשר לעשות לזה אוטומציה?״ כמעט הכל אפשר. השאלה היא ״האם זה צריך להתקיים בכלל, ואם כן, באיזו צורה?״
לבטל, לפשט, ורק אז לאטמט (בסדר הזה)
זה הכלל שאני מביא לכל פרויקט, וזה החלק שאנשים מדלגים עליו כי הוא פחות כיף מבנייה. לפני שמאטמטים משהו, העבירו את התהליך דרך שלושה שערים בסדר מחמיר.
- לבטל. האם השלב הזה או כל התהליך הזה פשוט יכול להפסיק להתקיים? מספר מדהים של משימות חוזרות הן הרגלים, לא דרישות. דוחות שאף אחד לא קורא. אישורים שתמיד מאושרים. נתונים שמועתקים בין שתי מערכות שאפשר לחבר פעם אחת. אם אפשר למחוק שלב, מחיקה זולה אינסופית מאוטומציה.
- לפשט. אם התהליך חייב להישאר, קלפו אותו למהות שלו קודם. הסירו את המקרים המיוחדים שחלים על שני אחוז מהמצבים. תקננו את הקלטים. צמצמו את מספר האישורים והעברות הידיים. תהליך פשוט זול יותר לאוטומציה, זול יותר לתחזוקה, והרבה פחות סביר שיישבר.
- לאטמט. רק עכשיו, על תהליך רזה ומאומת, כותבים קוד. אתם מאטמטים משהו שמצדיק את קיומו, בצורתו הפשוטה ביותר, כך שהאוטומציה קטנה, יציבה ובבירור שווה את מס התחזוקה.
דילוג על שני השערים הראשונים הוא החטא הקדמון. ראיתי חברה מבקשת ממני לאטמט דוח חודשי בן 14 שלבים. מחקנו שישה שלבים שכבר לא היו רלוונטיים, מיזגנו שלושה נוספים, וה״אוטומציה״ התבררה כשאילתה מתוזמנת בת חמש שורות. אם היו מאטמטים את כל 14 השלבים, הם היו משלמים פי חמישה על מערכת שברירית ששימרה עבודה שאף אחד לא היה צריך.
דוגמאות אמיתיות לאוטומציות גרועות
אלה תבניות שנתקלתי בהן יותר מפעם אחת, בתחפושת קלה.
- הדוח שאף אחד לא קורא. PDF יומי שנשלח לשנים עשר אנשים, מאוטמט להפליא. בדקנו את שיעורי הפתיחה: שני אנשים פתחו אותו, מדי פעם. המהלך הנכון היה קישור יחיד לדשבורד, לפי דרישה, לשניים שאכפת להם.
- אוטומציה של בלגן בהזנת נתונים. צוות העתיק פרטי הזמנה ממייל לגיליון, ואז ל-ERP. הם רצו בוט שיעשה את ההעתקה. התיקון האמיתי היה לחבר את מקור ההזמנה ישירות ל-ERP, כך שהנתונים לעולם לא יוקלדו מחדש. הבוט היה מאטמט שלב שלא צריך להתקיים.
- המייל הקר המותאם-יתר. יזם רצה לאטמט גריפה של עשר נקודות מידע על כל ליד כדי להתאים פנייה. נתוני ההמרה הראו שההתאמה כמעט לא הזיזה תשובות. שתי נקודות מידע עשו כמעט את כל העבודה. איטמטנו את השתיים וחתכנו את הבנייה ב-80 אחוז.
- אוטומציה מסביב לשרשרת אישורים שבורה. במקום לתקן למה אישורים לקחו ארבעה ימים, לקוח רצה תזכורות אוטומטיות שירדפו אחרי המאשרים. הסרנו שני מאשרים מיותרים, וצוואר הבקבוק נעלם בלי שורת קוד אחת.
החוט המקשר: בכל מקרה הבקשה הייתה לאטמט את התסמין. התיקון היה לשנות את התהליך. אם אתם לא בטוחים לאיזה מחנה הרעיון שלכם שייך, המדריך שלי על סימנים שהעסק שלכם בשל לאוטומציה הוא בדיקת בטן שימושית לפני שתוציאו שקל.
איך לבחור את האוטומציה הראשונה הנכונה
אם החלטתם שתהליך באמת צריך להתקיים ופישטתם אותו, הנה איך אני מדרג מועמדים. האוטומציה הראשונה הטובה ביותר היא המשעממת: תדירות גבוהה, מעט שיקול דעת, חזרתית עד כאב, ויציבה.
| סימן | מועמד טוב | מועמד גרוע |
|---|---|---|
| תדירות | רץ יומי או הרבה פעמים ביום | רץ כמה פעמים בשנה |
| שיקול דעת נדרש | הכללים ברורים ועקביים | צריך ניואנס אנושי כל פעם |
| יציבות | התהליך לא השתנה חודשים | עדיין משתנה כל שבוע |
| עלות טעות | הגרסה הידנית גורמת לטעויות אמיתיות | טעויות כאן לא מזיקות |
| בזבוז זמן | אוכל שעות של זמן צוות בשבוע | לוקח כמה דקות בסך הכל |
התחילו במשימה שמקבלת ציון טוב בכל חמש השורות. היא לא זוהרת בכוונה. אוטומציות זוהרות, אלה שצריכות שיקול דעת ומשתנות כל הזמן, הן בדיוק המקום שבו אוטומציה נכשלת. לעוד על אילו משימות עוברות את הרף הזה, ראו את הרשימה שלי של משימות עסקיות ששווה לאטמט.
חשיבה של ROI קודם, לא טכנולוגיה קודם
המספר היחיד שחשוב הוא ההחזר. לפני שאני בונה, אני רוצה תשובה גסה ל: כמה שעות בחודש זה חוסך, כמה שווה שעה כאן, וכמה תעלה הבנייה בתוספת התחזוקה השוטפת. אם משימה אוכלת 20 שעות בחודש בעלות אפקטיבית של 40$ לשעה (בערך 150 שקל), זה 800$ בחודש, או קרוב ל-10,000$ בשנה, שנשרפים. אוטומציה שעולה כמה אלפי דולרים לבנות ומעט לתחזק מחזירה את עצמה תוך שבועות ומדפיסה ערך אחרי כן.
עכשיו הפכו את זה. משימה שלוקחת 30 דקות בחודש שווה אולי 20$ בחודש לאטמט. שום אוטומציה לא מצדיקה בנייה ומס תחזוקה קבוע עבור 240$ בשנה. העובדה שהטכנולוגיה קלה לא רלוונטית. קל וחסר ערך עדיין חסר ערך. אני מעמיק בחישוב בכמה עולה אוטומציה עסקית, כי לקלוע להערכת ה-ROI בערך נכון מראש הוא מה שמבדיל אוטומציה שמצטברת מאוטומציה שמרוקנת אתכם בשקט.
זו גם הסיבה שאני דוחף לקוחות לכיוון פחות אוטומציות עמוקות יותר במקום פיזור של סקריפטים קטנים וחכמים. עשר אוטומציות שבריריות שכל אחת חוסכת שעה בשבוע יוצרות עשרה נטלי תחזוקה וסבך של תלויות. אוטומציה אחת מוצקה שמסירה צוואר בקבוק שבועי אמיתי שווה יותר ועולה פחות להחזיק. אם המטרה שלכם רחבה יותר, המאמר שלי על איך לשפר יעילות עסקית מכסה את המנופים שאינם אוטומציה שלרוב באים קודם.
הסיכום הכן
אוטומציה היא אחד הכלים בעלי המינוף הגבוה ביותר שיש לעסק קטן, ראיתי אותה משנה תפעול. אבל מינוף חותך לשני הכיוונים. כוונו אותו לתהליך שבור ותגדילו את השבירות. כוונו אותו למשימה מפושטת, בעלת ערך גבוה ויציבה, ותצברו חיסכון אמיתי חודש אחר חודש. המשמעת אינה טכנית. היא הנכונות לשאול אם משימה צריכה להתקיים לפני שאתם שואלים אם אפשר לאטמט אותה, ולבטל ולפשט לפני שאתם בכלל כותבים קוד.
אם יש לכם תהליך בראש ואתם לא בטוחים אם כדאי לאטמט אותו, לעצב אותו מחדש או פשוט למחוק אותו, זו בדיוק השיחה שאני נהנה ממנה. קבעו שיחה והעבירו אותי דרכו. אגיד לכם בכנות איפה ה-ROI האמיתי, גם אם התשובה היא ״אל תאטמטו את זה עדיין״. אפשר גם להגיע אליי דרך טופס יצירת הקשר.
שאלות נפוצות
מה זה בעצם אוטומציה של הדברים הלא נכונים?
זה אומר לקחת תהליך איטי, בזבזני או שבור ולאטמט אותו כמו שהוא. כיוון שאוטומציה היא מכפיל, בסוף מריצים את אותו תהליך פגום מהר יותר ויותר תכוף, ומגדילים את הבזבוז במקום להסיר אותו. התיקון הוא לבטל או לפשט את התהליך לפני שכותבים קוד.
מהו הכלל של לבטל, לפשט ואז לאטמט?
זה סדר הפעולות שאני מיישם על כל תהליך. קודם שואלים אם אפשר לבטל את השלב לחלוטין. אם הוא חייב להישאר, מפשטים אותו למהות על ידי הסרת מקרים מיוחדים והעברות ידיים. רק אז מאטמטים את התהליך הרזה והמאומת. דילוג על שני השלבים הראשונים הוא טעות האוטומציה הנפוצה והיקרה ביותר.
איך בוחרים את האוטומציה הראשונה?
בחרו את המשעממת: תדירות גבוהה, כללים ברורים ועקביים, תהליך יציב שלא השתנה חודשים, עלות טעות אמיתית כשעושים אותו ביד, וכמה שעות של זמן צוות שנחסכות בשבוע. משימות שצריכות שיקול דעת אנושי כל פעם וממשיכות להשתנות הן בדיוק המקום שבו אוטומציה נוטה להיכשל.
איך מחשבים את ה-ROI של אוטומציה?
העריכו כמה שעות נחסכות בחודש, הכפילו בעלות האמיתית של שעה, והשוו מול עלות הבנייה בתוספת תחזוקה שוטפת. משימה שאוכלת 20 שעות בחודש ב-40$ לשעה שורפת כ-10,000$ בשנה, אז בנייה של כמה אלפי דולרים מחזירה את עצמה תוך שבועות. משימה שלוקחת 30 דקות בחודש כמעט אף פעם לא מצדיקה אוטומציה.
האם לאטמט משימה רק כי קל לאטמט אותה?
לא. קל וחסר ערך עדיין חסר ערך. כל אוטומציה נושאת מס תחזוקה קבוע כשממשקי API משתנים ומקרי קצה צצים. אם המשימה מספקת מעט ערך, אתם משלמים את המס הזה לנצח כמעט בלי כלום. אטמטו רק תהליכים שבאמת מצדיקים את קיומם בצורתם הפשוטה ביותר.
להמשך קריאה
על הכותב
יהונתן סעדיה
מהנדס פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מהנדס בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה מנסה להפוך לאוטומטי או לבנות, ואומר לך מהי הדרך המהירה והאמינה ביותר ליישם את זה.
