כלים

אוטומציה באמצעות Make: כלי העבודה החזק ביותר

מה Make באמת עושה, בלי שפת שיווק

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

איפה זה באמת משתלם

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

המלכודת של הניסיון לאוטומט הכל

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

מה נשבר בשקט, ולמה זה חשוב יותר ממה שנשבר ברעש

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

עלות ומורכבות שמצטברות עם הזמן

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

לדעת איפה עובר הגבול

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

איך נראים תרחיש שהתנפח ותרחיש רזה זה לצד זה

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

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

קריאה נוספת