מצאי האוטומציות שלכם: מי יודע מה מזין את מה כשאתם לא בחדר?

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

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

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

זו לא בעיה של ביצועים, זו בעיה של בעלות

חשוב לי להפריד בין שתי בעיות שנשמעות דומה אבל דורשות טיפול שונה לגמרי.

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

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

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

שלב 1: רשימה אחת שבה הכל מופיע

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

קחו גיליון אחד, ועברו מקור-מקור על כל מקום שבו יכולה להיות אוטומציה:

• החשבונות בכלי האוטומציה (Make, Zapier, n8n) - כל התרחישים, כולל כאלה שמסומנים כפעילים ואתם לא זוכרים מה הם עושים.
• האוטומציות המובנות בתוך המערכות עצמן - כללים ב-CRM, טריגרים במערכת החשבוניות, מענה אוטומטי בוואטסאפ, חוקים בתיבת המייל.
• וובהוקים וסקריפטים - כל דבר שרץ על שרת, בענן, או בתזמון קבוע.
• קבצים וגיליונות עם לוגיקה - גוגל שיטס עם סקריפט או נוסחה שמזינה משהו הלאה.

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

שלב 2: לכל שורה - שלוש עמודות שאף אחד לא ממלא

עכשיו מתחילה העבודה האמיתית. ליד כל אוטומציה ברשימה, מלאו שלוש עמודות שלדעתי חשובות יותר מכל תיעוד טכני:

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

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

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

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

שלב 3: מפת התלויות - מה מזין את מה

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

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

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

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

שלב 4: לזהות את נקודות הכשל היחידות

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

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

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

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

מתי הפתרון הוא לא עוד אוטומציה

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

מהניסיון שלי, יש שלושה מצבים שבהם התשובה היא לא אוטומציה נוספת:

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

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

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

איך זה נראה בפועל - גיליון המצאי

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

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

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

סיכום

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

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

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

בואו נדבר על זה >