שבע טעויות נפוצות בבניית אוטומציות ואיך להימנע מהן
רוב האוטומציות שנשברות לא נשברות בגלל באג. הן נשברות כי מישהו אוטמט תהליך שאף אחד לא סגר, בנה לזרימה המושלמת, ולא הגדיר מה קורה כשמשהו נופל. הנה שבע הטעויות שאנחנו רואים הכי הרבה, כולל כאלה שעשינו בעצמנו.
כשאנחנו נכנסים לעסק שכבר יש בו אוטומציות, אנחנו כמעט לא פוגשים קוד גרוע. מה שאנחנו פוגשים זה החלטות שנראו הגיוניות ברגע שהן התקבלו, ושהתברר אחרי חצי שנה שהן היו יקרות. הרשימה כאן היא של הטעויות שחוזרות הכי הרבה, כל אחת עם איך היא נראית מבפנים, למה היא קורית, מה היא עולה ואיך מתקנים.
הערה לפני שמתחילים: חלק מהטעויות האלה עשינו בעצמנו. בעיקר את השלישית והרביעית, ואת הרביעית יותר מפעם אחת. זו לא רשימה של דברים שאנשים אחרים עושים.
טעות 1: אוטומציה של תהליך שבור
איך זה נראה: העסק מבקש לאוטמט את מה שהוא עושה היום, בלי לשאול אם מה שהוא עושה היום הגיוני. תהליך אישור שעובר דרך ארבעה אנשים כי פעם היה משבר אמון בין שתי מחלקות הופך לתהליך אוטומטי שעובר דרך ארבעה אנשים, רק מהר יותר.
למה זה קורה: כי לשאול ״למה זה ככה״ זה לפתוח דיון פוליטי, ולבנות זה נעים יותר. גם הספק לא תמיד רוצה לפתוח את זה, כי זה מאריך את הפרויקט ומכניס אותו לשיחות שאין לו בהן סמכות.
מה זה עולה: אתם משלמים על בנייה שמנציחה בזבוז. גרוע מכך, אחרי שהתהליך מוטמע במערכת קשה פי כמה לשנות אותו, כי עכשיו לשינוי יש גם עלות טכנית.
התיקון: לפני כל פרויקט, לעבור על התהליך שלב שלב ולשאול על כל שלב שתי שאלות. מה קורה אם מוחקים אותו, ומי יתנגד. אם אף אחד לא יודע למה שלב קיים, הוא מועמד למחיקה ולא לאוטומציה. הרבה פעמים מגלים ששליש מהשלבים מיותרים, ואז הפרויקט מצטמצם.
טעות 2: לבנות הכל בבת אחת
איך זה נראה: מיפוי של אחד עשר תהליכים, תוכנית לשלושה חודשים, ואחרי חודשיים עדיין אין דבר אחד שרץ בייצור. כולם עייפים והתקציב חצי נגמר.
למה זה קורה: כי אחרי שממפים את העסק רואים פתאום את כל ההזדמנויות ביחד, וזה מפתה. גם ספקים מעודדים את זה, כי פרויקט גדול נוח יותר למכור מפרויקט אחד קטן.
מה זה עולה: אין למידה. הערך של האוטומציה הראשונה הוא לא רק חיסכון בזמן, אלא מה שאתם לומדים ממנה על ההנחות שלכם. מי שבונה אחת עשרה במקביל מגלה את אותה טעות אחת עשרה פעמים.
התיקון: תהליך אחד, מקצה לקצה, בייצור, עם אנשים אמיתיים שמשתמשים בו לפחות שבועיים. רק אחרי זה השני. הקריטריון לבחירת הראשון הוא לא ההשפעה הגדולה ביותר אלא השילוב של השפעה סבירה עם סיכון נמוך, כדי שהניסיון הראשון של הצוות עם אוטומציה לא יהיה כישלון פומבי.
טעות 3: התעלמות ממקרי הקצה
איך זה נראה: האוטומציה נבנתה לזרימה שקורה ברוב המקרים. הזמנה תקינה, לקוח קיים, תשלום שעבר. ואז מגיעה הזמנה עם שתי כתובות משלוח, לקוח שהוא גם ספק, החזר חלקי, או שורה בלי מחיר, ואף אחד לא החליט מה עושים.
למה זה קורה: כי בפגישת האפיון מתארים את המקרה הרגיל. את החריגים אף אחד לא זוכר בעל פה, הם חיים בראש של שני עובדים ותיקים שיודעים לטפל בהם אינטואיטיבית ולא חושבים עליהם כעל חלק מהתהליך.
מה זה עולה: בדרך כלל לא קריסה אלא שקט. הרשומות החריגות פשוט לא מטופלות, ומגלים אותן חודשיים אחר כך כשמישהו משווה מספרים ורואה פער.
התיקון: לשבת עם מי שעושה את העבודה בפועל, לא עם המנהל, ולבקש דוגמאות של הפעמים האחרונות שמשהו היה חריג. אחר כך להגדיר לכל חריג אחת משלוש התנהגויות: לטפל אוטומטית, לעצור ולהעביר לאדם, או להתעלם במודע ולתעד את ההחלטה. מה שאסור זה שהחריג ייפול לחור.
רוב האוטומציות לא קורסות ברעש, הן פשוט מפסיקות לטפל בחלק מהמקרים ואף אחד לא שם לב.
טעות 4: אין טיפול בשגיאות ואין התראה
איך זה נראה: מערכת חיצונית מחזירה שגיאה, ההרצה נעצרת, ואף אחד לא יודע. שבועיים אחר כך לקוח שואל למה לא קיבל אישור הזמנה, ומתברר שהתהליך לא רץ מאז השלישי בחודש.
למה זה קורה: כי בזמן הבנייה הכל עובד, וקשה להשקיע אנרגיה בתרחיש שעוד לא קרה. גם כי טיפול בשגיאות הוא החלק הכי משעמם בפרויקט והוא נדחק לסוף, ובסוף התקציב כבר לחוץ.
מה זה עולה: זה החלק היקר ביותר ברשימה, כי הנזק מצטבר בשקט ומגיע ללקוחות. תהליך שנפל שבועיים אינו רק עבודה שצריך להשלים, אלא גם שיחות התנצלות.
התיקון: שלוש שכבות פשוטות שאנחנו מיישמים כמעט תמיד:
- ניסיון חוזר אוטומטי לשגיאות זמניות, עם השהיה גדלה. הרבה כשלים הם רק תקלת רשת רגעית.
- התראה לאדם בשם, בערוץ שהוא באמת קורא, עם מספיק פרטים כדי להבין איזו רשומה נפלה.
- סימן חיים תקופתי: הודעה יומית או שבועית שאומרת כמה הרצות היו וכמה נכשלו. שקט מוחלט הוא לא מידע.
טעות 5: תלות באדם אחד, בלי תיעוד
איך זה נראה: יש בעסק מישהו אחד, לפעמים עובד ולפעמים ספק, שבנה את הכל ויודע איפה כל דבר. אין תרשים, אין הסבר, והחשבונות של הכלים רשומים על המייל הפרטי שלו.
למה זה קורה: כי בהתחלה זה מהיר יותר. כשבונים לבד ומכירים את הכל, תיעוד מרגיש כמו בירוקרטיה. בעסק קטן זה גם נראה סביר, עד שהאדם הזה עוזב, יוצא לחופשה ארוכה או פשוט שוכח.
מה זה עולה: כשהידע יוצא מהדלת, שינוי קטן הופך לפרויקט של שחזור. ראינו לא מעט מקרים שבהם קל היה יותר לבנות מחדש מאשר להבין מה קיים, וזה בזבוז מוחלט של מה שכבר שולם עליו.
התיקון: מסמך אחד לכל תהליך, ולא יותר מעמוד. מה הוא עושה, מה מפעיל אותו, לאילו מערכות הוא נוגע, מי הבעלים העסקי, ומה עושים כשהוא נופל. בנוסף, כל החשבונות והחיבורים על מיילים ארגוניים בבעלות העסק, לא על חשבונות פרטיים. זה נשמע טריוויאלי, וזה הפרט שהכי הרבה עסקים מגלים מאוחר.
טעות 6: אין אדם באמצע איפה שצריך שיקול דעת
איך זה נראה: המערכת שולחת הודעת גבייה ללקוח ששילם אתמול, מוציאה חשבונית שגויה, או עונה תשובה אוטומטית ללקוח כועס. כל אחד מאלה טכנית תקין ועסקית הרסני.
למה זה קורה: כי אישור אנושי מרגיש כמו פשרה על הרעיון. אם בכל מקרה מישהו צריך ללחוץ, למה בנינו את זה. זו מחשבה מובנת וגם שגויה, כי ההבדל בין להכין החלטה לבין לקבל אותה הוא עצום מבחינת הזמן שנחסך.
מה זה עולה: אמון. טעות אוטומטית מול לקוח נתפסת גרוע יותר מטעות אנושית, כי היא משדרת שאף אחד לא הסתכל. בנושאי כסף זה מוכפל.
התיקון: לסמן במפת התהליך את הנקודות שבהן מעורב כסף, מידע רגיש, או לקוח שכבר הביע חוסר שביעות רצון, ולשים שם אישור אנושי. האישור צריך להיות זול מבחינת זמן: הודעה עם כל ההקשר ושני כפתורים, לא משימה שדורשת להיכנס למערכת ולחפש. אוטומציה טובה מכינה את ההחלטה ומשאירה את הלחיצה לאדם.
טעות 7: לבנות סביב כלי במקום סביב התהליך
איך זה נראה: העסק בחר פלטפורמה, ומאותו רגע כל החלטה נגזרת ממה שנוח בפלטפורמה. תהליכים מתעקמים כדי להתאים למגבלות הכלי. ואז הכלי משנה תמחור, מפסיק לתמוך בחיבור מסוים או נרכש, ומתברר שאין דרך זולה לצאת.
למה זה קורה: כי הכלי הוא הדבר הקונקרטי בחדר. קל יותר לדבר על מסך מאשר על תהליך מופשט, ובחירת כלי מרגישה כמו התקדמות.
מה זה עולה: כשהתמחור משתנה, וזה קורה, אתם בוחרים בין לשלם יותר לבין לבנות מחדש. ראינו עסקים שנתקעו עם עלייה משמעותית במחיר החודשי בלי אלטרנטיבה מעשית, פשוט כי כל הלוגיקה העסקית ישבה בתוך כלי אחד ולא הייתה כתובה בשום מקום אחר.
התיקון: לתעד את התהליך בשפה עסקית לפני שבוחרים כלי, ולשמור את התיעוד הזה מעודכן. להעדיף מבנה שבו הנתונים יושבים במקום שאתם שולטים בו והכלי רק מזיז אותם. ולשאול על כל פלטפורמה שאלה אחת פשוטה: אם המחיר יוכפל בשנה הבאה, מה נעשה. אם אין תשובה, זו חשיפה.
מלכודות שקשורות לעברית ולעבודה מימין לשמאל
החלק הזה לא מופיע בשום מדריך אוטומציה שנכתב באנגלית, ובישראל הוא אחראי לחלק לא קטן מהתקלות. ארבע חוזרות אצלנו כמעט בכל פרויקט.
שמות בעברית שוברים התאמה וזיהוי כפילויות
לוגיקה שמזהה לקוח לפי שם עובדת עד שהיא פוגשת גרשיים, רווח כפול, ״בע״מ״ שלפעמים מופיע ולפעמים לא, או אותו אדם שנרשם פעם בעברית ופעם באנגלית. התוצאה היא כפילויות או, גרוע יותר, מיזוג שגוי של שני לקוחות שונים. הפתרון הוא לזהות לפי מזהה יציב כמו ח.פ., טלפון מנורמל או מייל, ולעולם לא לפי שם חופשי.
תאריכים ואזורי זמן
רוב הכלים עובדים ב-UTC כברירת מחדל. אוטומציה שאמורה לרוץ בסוף יום עסקים רצה בשעה הלא נכונה, ומעבר לשעון קיץ מזיז אותה בשעה נוספת. בנוסף, פורמט התאריך הישראלי של יום לפני חודש מתפרש הפוך בכלים שמניחים את הסדר האמריקאי, וזה שקט ומסוכן כי בשנים עשר הימים הראשונים של כל חודש שתי הפרשנויות תקינות. אזור זמן צריך להיקבע במפורש, ותאריכים כדאי להעביר בפורמט תקני.
עברית במסמכים ובקבצים שנוצרים אוטומטית
יצירת PDF היא המקום הקלאסי. גופנים שלא תומכים בעברית, טקסט שיוצא הפוך, מספרים שנדחפים לצד הלא נכון, שורות שנשברות באמצע מילה. אותו דבר קורה בקבצי CSV שנפתחים באקסל וכל העברית הופכת לג׳יבריש בגלל קידוד. שתי המלצות: לבדוק על מסמך אמיתי עם שם ארוך בעברית ועם ספרות באותה שורה, ולשמור CSV בקידוד שאקסל בעברית פותח נכון.
איכות פלט של מודלי שפה בעברית
מודלים כותבים עברית פחות טוב מאנגלית. בפועל זה נראה כמו ניסוח שנשמע מתורגם, שגיאות התאמה בין מין למספר, ולפעמים המצאה של פרטים כשהמודל מנסה למלא חסר. לכן אנחנו נוטים להשתמש בהם למשימות סגורות כמו סיווג פנייה, חילוץ שדות מטקסט חופשי או סיכום פנימי, ופחות לניסוח שיוצא ללקוח בלי שאדם עבר עליו. כשבכל זאת מייצרים טקסט ללקוח, שווה לתת למודל דוגמאות אמיתיות מהכתיבה שלכם ולא הנחיות מופשטות.
טבלת זיהוי מהיר
אם אתם מנסים להבין מה קורה אצלכם עכשיו, הטבלה הזאת עוזרת לחבר תסמין לטעות:
| טעות | איך מזהים אותה | התיקון |
|---|---|---|
| אוטומציה של תהליך שבור | אף אחד לא יודע להסביר למה שלב מסוים קיים | למחוק שלבים לפני שמאטמים אותם |
| בנייה של הכל בבת אחת | חודשיים לתוך הפרויקט ואין דבר אחד בייצור | תהליך אחד מקצה לקצה, שבועיים בשטח, ואז הבא |
| התעלמות ממקרי קצה | יש רשומות שאף אחד לא נגע בהן והפערים בדוחות גדלים | לאסוף חריגים ממי שעושה את העבודה ולהחליט על כל אחד |
| אין טיפול בשגיאות | התשובה לשאלה איך יודעים שזה עובד היא ״אין תלונות״ | ניסיון חוזר, התראה לאדם בשם, וסימן חיים תקופתי |
| תלות באדם אחד | שינוי קטן מחכה שבוע כי רק אחד יודע לגעת | עמוד תיעוד לכל תהליך וחשבונות בבעלות העסק |
| אין אדם באמצע | לקוחות מקבלים הודעות שגויות בנושאי כסף | אישור אנושי בנקודות של כסף, מידע רגיש ולקוח לא מרוצה |
| בנייה סביב כלי | אין תשובה לשאלה מה עושים אם המחיר יוכפל | לתעד את התהליך בשפה עסקית ולשמור נתונים אצלכם |
| תקלות עברית ו-RTL | כפילויות לקוחות, PDF הפוך, ריצות בשעה מוזרה | זיהוי לפי מזהה יציב, אזור זמן מפורש, בדיקה על תוכן עברי אמיתי |
איך לבדוק את עצמכם בעשר דקות
קחו אוטומציה אחת שרצה אצלכם היום ותענו עליה בכתב:
- 1מתי היא רצה בפעם האחרונה, ואיך אתם יודעים.
- 2מי מקבל התראה כשהיא נכשלת, בשם.
- 3מה קורה כשמגיעה רשומה חריגה. יש התנהגות מוגדרת או שהיא נעלמת.
- 4מי יכול לשנות אותה חוץ מהאדם שבנה אותה.
- 5איפה כתוב מה היא עושה, במשפט שמנהל בעסק מבין.
- 6מה קורה אם הכלי שהיא רצה עליו יעלה משמעותית במחיר.
שאלה שאין לה תשובה היא לא סימן שמשהו שבור עכשיו, אלא מקום שבו לא החלטתם ולכן ההחלטה תתקבל במקומכם ברגע לא נוח. ברוב העסקים אפשר לסגור את הפערים האלה בכמה שעות עבודה, בלי לבנות שום דבר חדש. זה פחות מרשים לספר עליו בפגישה, וזה מה שמחזיק לאורך זמן.
שאלות שחוזרות
- איך יודעים אם אוטומציה עובדת או שהיא מתה בשקט?
- אם התשובה היחידה שלכם היא ״לא קיבלנו תלונות״, היא כנראה מתה. אוטומציה תקינה צריכה לייצר סימן חיים יזום: הודעה יומית או שבועית עם מספר ההרצות המוצלחות והכושלות, והתראה מיידית לאדם כשמשהו נופל. בלי זה מגלים את הבעיה מלקוח, ואז כבר יש גם נזק וגם מבוכה.
- האם עדיף לבנות אוטומציה אחת גדולה או כמה קטנות?
- כמה קטנות, כמעט תמיד. תהליך אחד ארוך שמכסה עשרה שלבים נשבר במקום אחד ומפיל את הכל, וקשה מאוד לדבג אותו. פיצול לחלקים עם נקודות מסירה ברורות ביניהם מאפשר לתקן חלק בלי לגעת בשאר, וגם מאפשר לעלות לאוויר בהדרגה.
- כמה תחזוקה אוטומציה באמת דורשת?
- יותר ממה שרוב הספקים אומרים בפגישת המכירה. מערכות משנות ממשקים, כלים משנים תמחור, אנשים בעסק משנים את הדרך שבה הם עובדים, ולכל אחד מאלה יש השפעה. אצלנו זה מתבטא בדרך כלל בכמה שעות בחודש לכל מערך פעיל, וזה מספר שכדאי לשאול עליו כל ספק לפני שחותמים.
- האם כדאי לבנות אוטומציה בעצמי בלי ספק חיצוני?
- לפעמים כן, וזה לא נוח לנו לומר. תהליך אחד פשוט בין שתי מערכות שיש להן חיבור מוכן ב-Make או ב-Zapier הוא בהחלט משהו שאדם סקרן בעסק יכול לבנות בשבוע. ההבדל מתחיל כשיש לוגיקה עסקית, מקרי קצה, ומישהו שצריך לתחזק את זה גם אחרי שהאדם הסקרן יעזוב.
- למה LLM שעובד מצוין באנגלית עושה שטויות בעברית?
- איכות המודלים בעברית עדיין נמוכה יותר מאשר באנגלית, במיוחד בניסוח חופשי ובהבנת ניואנסים. בפועל זה מתבטא בעברית שנשמעת מתורגמת, בשגיאות התאמה של מין ומספר, ולפעמים בהמצאת פרטים. לכן אנחנו משתמשים במודלים בעיקר לסיווג, חילוץ שדות וסיכום פנימי, ולא לניסוח טקסט שהולך ללקוח בלי שאדם קרא אותו.