אוטומציה שנשברת בשקט גרועה מעבודה ידנית. מי אחראי, אילו התראות חייבות להיות, ואיך בודקים שמשהו באמת רץ ולא רק מדווח הצלחה.
עיקרי הדברים
- כשל שקט הוא הסיכון המרכזי, ולא כשל רועש.
- לכל אוטומציה צריך בעלים בשם, גם כשהיא נבנתה על ידי מישהו חיצוני.
- התראה על שגיאה אינה מספיקה; צריך גם התראה על שקט.
- ההצלחה לא נמדדת בכך שהיא רצה אלא בכך שהתוצאה קרתה.
עבודה ידנית שנעצרת מורגשת מיד; אוטומציה שנעצרת נראית בדיוק כמו אוטומציה שעובדת. זה ההבדל היחיד שחשוב באמת, והוא הסיבה שכל אוטומציה צריכה שני דברים שאינם חלק ממנה: אדם אחראי, והתראה שמגיעה כשהיא לא עשתה את עבודתה.
שלושת סוגי הכשל
| הסוג | איך הוא נראה | איך מגלים |
|---|---|---|
| שגיאה גלויה | הריצה נכשלה | התראה מהכלי |
| כשל שקט | רצה בהצלחה, לא עשתה כלום | רק בבדיקה יזומה |
| כשל חלקי | חלק מהרשומות עברו | השוואת מספרים |
השורה השנייה היא המסוכנת, מפני שכל מדד רגיל מציג "תקין". אוטומציה שמושכת נתונים ממקור ששינה מבנה יכולה לרוץ יפה ולהעביר אפס רשומות - וזה נראה בדיוק כמו הצלחה.
מה חייב להיות לכל אוטומציה
- בעלים בשם - מי אחראי שהיא עובדת, לא מי בנה אותה.
- תיאור בשורה אחת - מה היא עושה, בשפה שגם מי שלא בנה אותה מבין.
- התראה על שגיאה - למי היא מגיעה, ובאיזה ערוץ.
- התראה על שקט - כשהיא לא רצה בזמן שבו היא אמורה.
- בדיקת תוצאה - לא רק שהיא רצה אלא שהמספרים תואמים.
- מה עושים ידנית כשהיא לא עובדת.
הפריט האחרון נשכח וחשוב במיוחד: כשאוטומציה נופלת ביום עמוס, מישהו צריך לדעת איך לבצע את התהליך ידנית - אחרת התקלה עוצרת עבודה עד שמי שבנה אותה זמין.
למה התראה על שגיאה לא מספיקה
מפני שהיא מכסה רק את הסוג הראשון. אוטומציה שלא רצה בכלל - כי מישהו כיבה אותה, כי המנוי פג, כי השתנתה סיסמה - לא תשלח שגיאה, פשוט מפני שהיא לא פעלה.
הפתרון הוא התראה הפוכה: אם לא התקבל אישור ריצה עד שעה מסוימת, שולחים הודעה. זה נשמע טריוויאלי ורוב העסקים לא עושים את זה - וזו בדיוק הסיבה שכשלים מתגלים אחרי שבוע. ההיבט הטכני של הכשלים השקטים מפורט בניטור כשלים שקטים ב-Zapier ו-Make.
בדיקת התוצאה - מה באמת מודדים
הבדיקה הנכונה אינה "האם רצה" אלא "האם המספרים מסתדרים". שתי דוגמאות פשוטות: כמה הזמנות נוצרו במערכת מול כמה הגיעו מהחנות; כמה מסמכים הופקו מול כמה תשלומים התקבלו.
פער קבוע בין השניים אומר שמשהו מסונן בדרך, וזה בדרך כלל מקרה קצה שלא נלקח בחשבון - למשל הזמנה עם שני פריטים מסוגים שונים, או לקוח בלי שדה חובה. הפער הזה לא יופיע בשום התראה, והוא נמצא רק כשמישהו משווה.
מי צריך להיות הבעלים
לא בהכרח מי שבנה. הבעלים צריך להיות מי שהתוצאה חשובה לו - בדרך כלל בעל התהליך שהאוטומציה משרתת. הוא לא חייב לדעת לתקן; הוא חייב לדעת שמשהו לא קרה ולמי לפנות.
כשהאוטומציה נבנתה על ידי גורם חיצוני, זה חשוב במיוחד: ספק חיצוני לא יידע שמשהו לא קרה, מפני שהוא לא רואה את התוצאה העסקית. הוא יראה רק ריצה מוצלחת. ההיגיון של בעלות על תוצאה מתואר במי אחראי על תהליך.
מה בודקים פעם ברבעון
- אילו אוטומציות קיימות - הרשימה תמיד ארוכה ממה שזוכרים.
- מי הבעלים של כל אחת, והאם הוא עדיין בתפקיד.
- מתי רצה לאחרונה בהצלחה אמיתית.
- האם עדיין נחוצה - חלק מהן נבנו לתהליך שהשתנה.
- מה קורה כשהיא נופלת - האם מישהו יודע.
סעיף 4 מוחק בדרך כלל אחת-שתיים מהרשימה, וזה חיסכון כפול: פחות תחזוקה ופחות מקומות שיכולים להישבר.
מה קורה כשאין ניטור בכלל?
התרחיש חוזר על עצמו כמעט באותה צורה בכל עסק. האוטומציה נבנית, עובדת חודשיים, ומשהו משתנה - ספק מעדכן, שדה מוסיף, סיסמה פגה. היא מפסיקה, ואיש לא יודע. שבועיים אחר כך לקוח שואל למה לא קיבל אישור, ואז מגלים.
מה שקורה אז יקר יותר מהתקלה עצמה: צריך לאתר אילו רשומות לא עברו, להשלים אותן ידנית, ולהחליט מה אומרים ללקוחות שנפגעו. בעסקים שזה קרה להם פעם אחת, הניטור נבנה מיד - וזה בדיוק הלקח שאפשר ללמוד בלי לשלם עליו.
עלות הניטור לעומת זאת קטנה: התראה אחת על שגיאה, אחת על שקט, ובדיקה חודשית של מספרים. זה פחות מחצי שעה בהקמה ודקות בחודש.
איך בודקים אוטומציה שקיבלתם מספק
- לבקש רשימה של מה נבנה, ומה כל אחת עושה בשורה.
- לוודא שהיא רצה בחשבון של העסק ולא בחשבון פרטי.
- לבדוק למי מגיעות התראות - ולשנות לכתובת שלכם.
- לבקש הסבר מה עושים ידנית כשזה לא עובד.
- לשאול מה קורה אם תפסיקו לעבוד עם הספק.
הסעיף האחרון הוא זה שמפתיע בעיתוי הגרוע. אוטומציה שרצה בחשבון של ספק חיצוני נעצרת ביום שההתקשרות מסתיימת, וזה בדרך כלל נזכר בדיוק אז - ולכן שווה לברר את זה בתחילת ההתקשרות ולא בסופה. אותו דבר תקף לחשבונות שהאוטומציה מתחברת אליהם: הם צריכים להיות של העסק, ולא של מי שהקים אותם.
הבדיקה החודשית שמספיקה
חמש דקות בחודש, ולא יותר. פותחים את רשימת האוטומציות, ולכל אחת בודקים שני דברים: מתי היא רצה בהצלחה בפעם האחרונה, והאם המספרים בצד השני נראים סבירים. זה לא מחליף ניטור אוטומטי - הוא נשאר ההגנה הראשונה - אבל הוא תופס בדיוק את מה שניטור לא תופס: הצלחות ריקות.
מה שהופך את הבדיקה הזו לאפשרית הוא שהרשימה קיימת. בעסקים שבהם איש לא יודע כמה אוטומציות רצות, גם הבדיקה הזו לא תתבצע - ולכן הצעד הראשון הוא תמיד לרשום, לא לנטר. רשימה של חמש שורות בגיליון מספיקה לחלוטין, והיא גם מה שיאפשר למישהו אחר להיכנס לתמונה אם מי שאחראי לא זמין.
מקורות
שאלות נפוצות
כמה זמן לוקח לתחזק אוטומציה?
מעט, כשהיא פשוטה ומנוטרת - בדרך כלל דקות בחודש ובדיקה רבעונית. מה שצורך זמן הוא שינויים: כל פעם שמשהו בסביבה משתנה, מישהו צריך להתאים. לכן אוטומציה שנוגעת בפחות מערכות מחזיקה זמן רב יותר.
מה עושים כשמי שבנה אותה עזב?
בודקים שלושה דברים לפי הסדר: האם יש תיעוד בשורה אחת מה היא עושה; האם יש גישה לחשבון שבו היא רצה; והאם יש דרך לבצע את התהליך ידנית. השני הוא הקריטי - אוטומציה שרצה בחשבון אישי של מי שעזב היא פצצת זמן.
עדיף התראה במייל או בהודעה?
בערוץ שנקרא. התראה שמגיעה למייל שאיש לא פותח שווה כמו היעדר התראה. מה שחשוב יותר מהערוץ הוא שיהיה לה נמען בשם ולא כתובת כללית - התראה ל-info@ נקראת בממוצע אף פעם.
כמה אוטומציות זה יותר מדי?
כשאי אפשר לרשום את כולן מהזיכרון. זה לא מספר קבוע אלא סימן: כשיש יותר ממה שאפשר להחזיק בראש ואין רשימה, אף אחד לא שם לב כשאחת מהן מפסיקה - וזו בדיוק הנקודה שבה אוטומציה מפסיקה לחסוך ומתחילה לעלות.
להמשך קריאה
שירות רלוונטי
פיתוח MVP
להפוך רעיון למוצר מאומת תוך שבועות, לא חודשים.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה מנסה להפוך לאוטומטי או לבנות, ואומר לך מהי הדרך המהירה והאמינה ביותר ליישם את זה.