Make ו Zapier מול אוטומציה בקוד: מה נכון לעסק?

Make ו Zapier הפכו בשנים האחרונות לכלים נפוצים מאוד לבניית אוטומציות בין מערכות.

הם מאפשרים לחבר טפסים, מערכות CRM, מערכות ERP, הנהלת חשבונות, מערכות דיוור, שירות לקוחות, מערכות תפעול ושירותים רבים נוספים, לעיתים בתוך שעות וללא פיתוח משמעותי.

על הנייר זה נשמע מצוין.

בפועל, אחרי שעובדים עם אוטומציות לאורך זמן, מתעוררת שאלה הרבה יותר חשובה:

האם עסק יכול להרשות לעצמו לבסס תהליך עסקי חשוב על אוטומציה שעלולה להפסיק לעבוד מבלי שאף אחד ישים לב?

הבעיה היא לא רק אם Make או Zapier יציבים

קל להפוך את הדיון לוויכוח על השאלה האם Make או Zapier הם כלים יציבים.

בעיניי זאת לא השאלה המרכזית.

אוטומציה יכולה להפסיק לעבוד מסיבות רבות.

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

מבחינת העסק, הסיבה הטכנית פחות מעניינת.

השאלה החשובה היא:

מה קרה למידע שהיה אמור לעבור בזמן שהאוטומציה לא עבדה?

גם אובדן של ליד אחד יכול להיות קריטי

ניקח אוטומציה שנראית פשוטה מאוד:

טופס באתר → פתיחת ליד ב CRM → העברה לאיש מכירות

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

ייתכן שהוא אפילו רואה הודעה שהפנייה התקבלה.

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

אבל מה קורה אם האוטומציה הפסיקה לעבוד?

הליד לא נפתח.

איש המכירות לא יודע שהוא קיים.

הלקוח ממתין.

ובינתיים העסק ממשיך לעבוד כרגיל.

זו בדיוק אחת הבעיות הגדולות בתהליכים אוטומטיים:

תקלה יכולה להיות שקטה.

כאשר האתר נופל, בדרך כלל מגלים.

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

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

מישהו פתאום שואל:

“למה לא נכנסו לידים כבר יומיים?”

רק אז מתחילה הבדיקה.

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

לכן גם העברת ליד מטופס ל CRM יכולה להיות תהליך עסקי קריטי.

אין דבר כזה “זו רק אוטומציה”

אותו עיקרון נכון כמעט לכל תחום.

פנייה לשירות שלא נפתחה.

משימה שלא נוצרה.

חשבונית שלא עברה למערכת אחרת.

עסקה שלא נקלטה.

תשלום שלא עודכן.

הזמנה שלא הועברה לטיפול.

לקוח שלא קיבל הודעה חשובה.

מסמך שלא נשמר.

נתון שלא הסתנכרן בין מערכות.

כל אחד מאלה יכול להתחיל באוטומציה שנראית קטנה ופשוטה.

לכן השאלה הנכונה היא לא אם האוטומציה פשוטה או מורכבת.

השאלה היא:

מה המשמעות העסקית אם הפעולה לא תתבצע?

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

הבעיה הגדולה היא לא התקלה, אלא שלא ידענו עליה

כל מערכת יכולה ליפול.

גם מערכת שפותחה בקוד יכולה להיכשל.

גם API יכול להיות לא זמין.

גם שרת יכול ליפול.

לכן הטענה אינה שקוד לעולם לא מתקלקל.

השאלה היא כיצד המערכת תוכננה להתמודד עם התקלה.

בתהליך עסקי חשוב צריך לדעת:

האם הפעולה התקבלה?

האם היא בוצעה?

אם היא נכשלה, למה?

האם המערכת ניסתה שוב?

האם המידע נשמר כדי שאפשר יהיה לנסות שוב מאוחר יותר?

האם מישהו קיבל התראה?

האם אפשר לראות את כל הפעולות שנכשלו?

והכי חשוב:

האם פעולה יכולה פשוט להיעלם מבלי שאף אחד יידע?

אוטומציה טובה צריכה להיות מתוכננת גם לרגע שבו משהו לא עובד

נניח שמערכת אחת צריכה להעביר 500 רשומות למערכת אחרת.

אחרי 217 רשומות, המערכת המקבלת מפסיקה להגיב.

מה עכשיו?

מערכת אמינה צריכה לדעת אילו 217 רשומות כבר עברו.

היא צריכה לדעת אילו עדיין ממתינות.

היא צריכה לשמור את המידע.

היא צריכה לנסות שוב בהתאם לכללים שהוגדרו.

ואם התקלה נמשכת, היא צריכה להתריע.

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

אלה כבר לא רק שאלות של אוטומציה.

אלה שאלות של ארכיטקטורת מערכת.

Queue: הפעולה לא נעלמת

אחד הכלים החשובים בתהליכים כאלה הוא Queue, כלומר תור פעולות.

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

לדוגמה, נכנס ליד חדש.

הליד נרשם בתור.

שירות אחר לוקח אותו ומנסה להעביר אותו ל CRM.

אם ה CRM לא זמין כרגע, הליד עדיין קיים.

הוא לא נעלם.

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

זה הבדל מהותי בתפיסה.

המטרה היא לא רק להעביר מידע ממערכת אחת לשנייה.

המטרה היא:

להבטיח שהמידע יגיע ליעדו, או שנדע שהוא לא הגיע.

Retry: אם לא הצליח, מנסים שוב

מערכות חיצוניות לא תמיד זמינות.

Timeout חד פעמי לא צריך לגרום לאובדן פעולה.

לכן אפשר לבנות מנגנון Retry.

הפעולה נכשלה?

מנסים שוב.

נכשלה שוב?

ממתינים ומנסים פעם נוספת.

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

כך תקלה זמנית במערכת אחת לא חייבת להפוך לתקלה עסקית.

מניעת כפילויות

Retry יוצר אתגר נוסף.

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

אם ננסה שוב, אולי ניצור את אותה פעולה פעמיים.

אותו ליד יכול להיפתח פעמיים.

אותה הזמנה יכולה להיווצר פעמיים.

אותו מסמך יכול להיות מופק פעמיים.

ובמקרים רגישים יותר, גם פעולה כספית עלולה להתבצע פעמיים.

לכן מערכת טובה צריכה לדעת לזהות פעולה שכבר בוצעה ולמנוע כפילות.

בעולם הפיתוח משתמשים בין היתר בעקרון שנקרא Idempotency.

מבחינת העסק המשמעות פשוטה:

אפשר לנסות שוב בלי שאותה פעולה תתבצע פעמיים.

Logs: לדעת בדיוק מה קרה

בתהליך עסקי חשוב צריך להיות תיעוד.

לא מספיק לדעת ש”האוטומציה נכשלה”.

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

וכמובן צריך לדעת מה נעשה לאחר הכישלון.

כאשר קיימים Logs מסודרים, אפשר לחקור תקלה.

כאשר הם לא קיימים, מתחילים לנחש.

התראות: לא לחכות שמישהו ישים לב

זה אולי אחד הדברים החשובים ביותר.

אם תהליך שאמור לקבל עשרות לידים ביום לא קיבל אף ליד במשך שעות, ייתכן שמשהו לא תקין.

אם עשר פעולות ברצף נכשלו, צריך להתריע.

אם נוצר פער בין שתי מערכות, צריך להתריע.

אם Queue מתחיל להצטבר, צריך להתריע.

עסק לא צריך לגלות במקרה שהאוטומציה שלו הפסיקה לעבוד.

מערכת עסקית צריכה לספר לנו בעצמה שמשהו לא בסדר.

ומה קורה אחרי שמתקנים את התקלה?

נניח שגילינו שהאינטגרציה לא עבדה במשך יום שלם.

תיקנו אותה.

האם סיימנו?

לא.

עכשיו צריך לדעת מה קרה במהלך אותו יום.

אילו פעולות חסרות?

אילו הצליחו?

אילו נכשלו?

האם חלק מהן בוצעו פעמיים?

האם המידע בשתי המערכות עדיין תואם?

לשם כך אפשר לבנות תהליכי Reconciliation, כלומר מנגנוני התאמה ובקרה.

לדוגמה:

במערכת אחת קיימות 1,000 רשומות שאמורות היו לעבור היום.

במערכת השנייה קיימות 997.

אנחנו צריכים להיות מסוגלים לזהות את שלוש הרשומות החסרות.

לא לחכות שמישהו ייתקל בהן במקרה.

אז למה בכלל משתמשים ב Make וב Zapier?

כי יש להם יתרון משמעותי מאוד:

מהירות.

אפשר להקים תהליך במהירות יחסית, בלי לפתח מערכת שלמה.

אפשר לבדוק רעיון.

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

אפשר לבצע Proof of Concept.

אפשר לתת מענה לצורך נקודתי.

ובמקרים מסוימים זה בדיוק מה שהעסק צריך.

אבל למהירות הזאת יש מחיר שצריך להבין.

אנחנו מוסיפים עוד שכבה בין המערכות.

במקום:

מערכת A → מערכת B

אנחנו מקבלים:

מערכת A → פלטפורמת אוטומציה → Connector → מערכת B

ובתהליך מורכב יכולים להיות עוד הרבה שלבים בדרך.

כל שכבה כזאת היא עוד רכיב שאנחנו תלויים בו.

ומה היתרון בפיתוח אוטומציה בקוד?

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

אפשר לבנות Queue.

אפשר להגדיר Retry.

אפשר למנוע כפילויות.

אפשר לנהל Logs מפורטים.

אפשר לבנות התראות.

אפשר ליצור מסך בקרה.

אפשר לשמור פעולות שנכשלו.

אפשר לבצע Reconciliation.

ואפשר להגדיר בדיוק מה יקרה בכל תרחיש חריג.

כמובן שגם מערכת כזאת דורשת תחזוקה.

גם קוד צריך לעדכן.

גם שרתים צריכים ניטור.

גם APIs משתנים.

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

ומה לגבי המחיר?

אוטומציה בקוד בדרך כלל תהיה יקרה יותר להקמה.

צריך לאפיין, לפתח, לבדוק, להעלות לסביבת Production, לנטר ולתחזק.

Make ו Zapier יכולים לאפשר להקים את התהליך הראשוני הרבה יותר מהר.

אבל זאת רק עלות ההקמה.

צריך לשאול גם:

כמה עולה אובדן של ליד אחד?

כמה עולה יום שבו פניות שירות לא נכנסו?

כמה עולה עסקה שלא נקלטה?

כמה עולה עובד שמבלה שעות בבדיקת פערים בין מערכות?

כמה עולה לגלות אחרי שבוע שתהליך מסוים הפסיק לעבוד?

ולכן כשבוחנים את העלות, השאלה לא צריכה להיות רק:

כמה עולה לבנות את האוטומציה?

צריך לשאול:

כמה עולה לעסק כשהאוטומציה לא עובדת?

לא לבחור כלי לפני שמאפיינים את הסיכון

אחת הטעויות הנפוצות בפרויקטים היא להתחיל מהפתרון.

“נעשה את זה ב Make.”

“נחבר את זה ב Zapier.”

או לחלופין:

“צריך לפתח.”

עדיף להתחיל במקום אחר.

מהו התהליך?

מה צריך לעבור בין המערכות?

מה יקרה אם הפעולה לא תתבצע?

האם מותר לאבד אפילו פעולה אחת?

האם מותר לבצע אותה פעמיים?

כמה זמן מותר לתהליך להיות מושבת?

איך נדע שהוא מושבת?

איך נטפל בפעולות שנכשלו?

איך נוודא לאחר התקלה שלא חסר מידע?

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

אוטומציה היא מערכת עסקית

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

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

לכן השאלה אינה אם מדובר באוטומציה קטנה או גדולה.

גם פעולה אחת יכולה להיות קריטית.

ליד אחד שלא הגיע הוא ליד שאולי איבדנו.

בקשת שירות אחת שלא נפתחה היא לקוח שלא קיבל טיפול.

עסקה אחת שלא נקלטה היא עסקה שהעסק עלול לאבד.

Make ו Zapier הם כלים חזקים ונוחים, ויש מצבים שבהם הם יכולים לתת מענה.

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

כי השאלה החשובה באמת אינה:

האם האוטומציה עובדת היום?

אלא:

איך נדע מחר בבוקר שהיא הפסיקה לעבוד, ומה יקרה לכל הפעולות בזמן התקלה?