אוטומציה עסקית על Make, n8n ו-Google Sheets מגיעה לגבול כשמופיעות כפילויות, תקלות שקטות שאף אחד לא רואה, הרשאות שלא ברור למי הן שייכות ותלות באדם אחד שמבין את השרשרת. אז כדאי לבחור: לחזק את השרשרת הקיימת, או לעבור בהדרגה למערכת מותאמת שעובדת לצד הקיימת עד שהיא מוכנה.
מה זה אוטומציה עסקית ואיך נראית שרשרת טיפוסית
לפי הגדרה מקובלת, אוטומציה עסקית היא שימוש במחשוב לביצוע אוטומטי של תהליכי עבודה שאחרת היו נעשים בידי עובדים. כל תהליך כזה בנוי מ-3 שלבים: טריגר, פעולות ותנאים. הטריגר הוא האירוע שמפעיל את התהליך, למשל טופס שנשלח באתר. הפעולות הן מה שקורה אחריו. התנאים מנתבים את התהליך למסלול כזה או אחר.
Make ו-n8n הם כלים לחיבור בין מערכות בלי לכתוב קוד מלא. בכל אחד מהם בונים רצף צעדים שמעביר מידע ממערכת אחת לאחרת. ב-Make הוא נקרא תרחיש. ב-n8n הוא נקרא workflow. Google Sheets, הגיליון האלקטרוני של גוגל, משמש בהרבה שרשראות כמאגר מידע. הוא נוח, כולם מכירים אותו ואפשר לראות בו כל שורה.
באוטומציות אנחנו עובדים עם Make, n8n ו-Google Sheets. אלה כלים טובים לתהליכים רבים. השאלה היא לא אם הם טובים, אלא עד איפה הם מחזיקים בתהליך מסוים.
למה שרשרת טובה מתחילה להיסדק עם הזמן
שרשרת אוטומציה נולדת בדרך כלל מצורך אחד. ליד נכנס מטופס, נרשם בגיליון ונשלח במייל לאיש המכירות. אחר כך מוסיפים עוד צעד, עוד מערכת ועוד תנאי. אחרי זמן מה יש תהליך שלם שאיש לא תכנן מראש.
Google Sheets לא נבנה להיות מסד נתונים. אין בו מפתח ייחודי שמונע שורה כפולה. כל מי שיש לו הרשאת עריכה יכול להזיז עמודה, ותרחיש שמחפש את העמודה הזו נשבר. כמה תרחישים שכותבים לאותו גיליון באותו זמן עלולים גם לדרוס זה את זה.
חלק נוסף מהבעיה הוא חיבורי API. ה-API הוא הממשק שדרכו מערכות מעבירות מידע זו לזו. למערכות רבות יש מגבלה על מספר הבקשות בפרק זמן נתון. כשהנפח עולה, בקשות נדחות, ולא כל תרחיש יודע לנסות שוב.
דוגמה לתהליך רב-שלבי היא קליטת חשבוניות מכמה תיבות מייל לתיקייה משותפת, לצד הכנת טיוטות של דוחות חודשיים. בתהליך שעובר בין כמה מערכות, כל חיבור הוא נקודת כשל נפרדת שצריכה בקרה משלה.
4 סימנים שהשרשרת הגיעה לגבול
יש 4 סימנים שכדאי לחפש בשרשרת שגדלה מעבר ליכולת שלה. סימן אחד לבד אפשר לפעמים לתקן. כמה סימנים יחד הם תמונה אחרת.
כפילויות
ליד אחד מופיע פעמיים ב-CRM, מערכת ניהול הלקוחות. הזמנה נרשמת פעמיים בגיליון. חשבונית יוצאת פעמיים. הסיבה בדרך כלל פשוטה: התרחיש רץ שוב אחרי תקלה, או ששני טריגרים תופסים את אותו אירוע. כשאין מזהה ייחודי לכל רשומה, אין דרך לדעת שהיא כבר טופלה. כפילות אחת היא מטרד. כפילויות קבועות פוגעות באמון בנתונים, והצוות חוזר לבדוק הכול ידנית.
תקלות שקטות
תקלה רועשת עוצרת את התהליך ושולחת התראה. תקלה שקטה לא עוצרת כלום. התרחיש מסתיים בהצלחה, אבל שדה ריק עובר הלאה, או שתנאי מסנן שורה שלא היה צריך לסנן. מגלים את זה אחרי שבועות, כשמישהו שואל למה לקוח לא קיבל מענה. אם הבדיקה היחידה היא שהתרחיש סיים לרוץ, הבקרה לא מספיקה.
הרשאות שאף אחד לא מנהל
שרשראות נבנות לעיתים קרובות על חשבון אישי של עובד. החיבור לתיבת המייל, לגיליון ולמערכת הכספים עובר דרך הסיסמה שלו. כשהעובד עוזב או מאבד הרשאה, חלק מהתהליכים נעצרים. בצד השני, גיליון שמשותף עם הרבה אנשים חושף פרטי לקוחות למי שלא צריך לראות אותם. כדאי לדעת בכל רגע מי יכול לקרוא, מי יכול לערוך ובאיזה חשבון רץ כל חיבור.
תלות באדם אחד
לעיתים קרובות יש אדם אחד שמבין את כל השרשרת. הוא זה שבונה, מתקן ויודע איזה תרחיש תלוי באיזה גיליון. כשהוא בחופשה, אף אחד לא נוגע. זה לא כשל של האדם. זה כשל של תהליך שאין לו תיעוד, אין לו בעלים מוגדר ואין לו סביבת בדיקה.
מתי מחזקים את השרשרת הקיימת
לא כל סימן מחייב מעבר. חיזוק מתאים כשהתהליך פשוט יחסית, הנפח יציב והבעיות נקודתיות. אלה הצעדים שבודקים קודם:
- מזהה ייחודי לכל רשומה, ובדיקה לפני כל כתיבה אם הרשומה כבר קיימת.
- נתיב שגיאה בכל תרחיש, עם התראה למייל או לערוץ של הצוות.
- יומן ריצות שמראה מה נכנס ומה יצא בכל שלב.
- העברת החיבורים מחשבון אישי לחשבון ארגוני.
- מסמך קצר לכל תרחיש: מה מפעיל אותו, לאן הוא כותב ומי אחראי עליו.
- הפרדה בין גיליון שמזינים בו ידנית לבין גיליון שהאוטומציה כותבת אליו.
את n8n אפשר להריץ גם על שרת של החברה. זה נותן שליטה על הנתונים, אבל מוסיף אחריות לעדכונים, לגיבויים ולאבטחה. אם אחרי החיזוק התקלות נעלמות, אין סיבה למהר להחליף כלי.
מתי עוברים למערכת מותאמת
מערכת מותאמת היא תוכנה שנבנית סביב התהליך של החברה. יש לה מסד נתונים אמיתי, הרשאות לפי תפקיד ולוגיקה שנבדקת לפני שהיא עולה. היא לא מחליפה את Make או n8n בכל מקום. היא מחליפה את החלק שבו Sheets משמש מאגר מרכזי, ואת הלוגיקה שכבר מסובכת מדי לתרחיש.
המעבר כדאי כשהתהליך נוגע בכסף, בחשבוניות או בהתחייבות ללקוח, וטעות בו פוגעת ישירות בלקוח או בתזרים. הוא כדאי גם כשאותה רשומה עוברת ידיים כמה פעמים לאורך התהליך, כשצריך היסטוריה מלאה של כל שינוי, או כשכמה משתמשים עורכים את אותה רשומה במקביל. סימן נוסף הוא שרשרת שמתחברת ל-ERP, מערכת לניהול משאבי הארגון, ומנסה לגשר בינו לבין עוד כמה מערכות.
עוד סימן הוא חיזוק שלא מחזיק: מוסיפים בדיקה, ותקלה חדשה מופיעה במקום אחר. פירוט על מה שנכלל בבנייה כזו יש בעמוד פיתוח מערכות מותאמות אישית.
איך מחליטים: לחזק או לעבור
הטבלה מסכמת כל סימן לפי שתי האפשרויות. אין צורך שכל השורות יצביעו לאותו כיוון.
| סימן | כדאי לחזק את השרשרת | כדאי לעבור למערכת מותאמת |
|---|---|---|
| כפילויות | מופיעות מדי פעם והמקור ברור | חוזרות גם אחרי הוספת מזהה ובדיקה |
| תקלות שקטות | בדיקות תקינות על הנתונים תופסות אותן | הלוגיקה מסובכת מכדי לבדוק אותה בתרחיש |
| הרשאות | מספיק להעביר חיבורים לחשבון ארגוני | נדרשות הרשאות לפי תפקיד והיסטוריית שינויים |
| תלות באדם אחד | תיעוד ואדם נוסף שמכיר את השרשרת מספיקים | רק מי שבנה את השרשרת יכול לתחזק אותה |
| נפח וקצב | הנפח יציב ובתוך מגבלות ה-API | בקשות נדחות או ממתינות כשהנפח עולה |
| סוג המידע | מידע תפעולי שאפשר לתקן בקלות | תשלומים, חשבוניות או נתונים רגישים על לקוחות |
כשהסימנים שנוגעים בכסף ובהרשאות נופלים בעמודה האחרונה, כדאי להתחיל לתכנן מעבר. כשהם בעמודה האמצעית, החיזוק הוא הצעד הנכון כרגע.
מה הסיכון בכל אחת מהדרכים
בחיזוק, הסיכון הוא שכל תיקון הופך לעוד שכבה שאיש לא מבין. כל תנאי חדש מוסיף מקום לטעות. בנקודה מסוימת המאמץ לתחזק את השרשרת גדול מהמאמץ לבנות אותה מחדש. קשה לזהות את הרגע הזה מבפנים.
במעבר, הסיכון הגדול הוא מעבר חד. מכבים את השרשרת ביום אחד ומגלים שהיא מבצעת עוד פעולות שאף אחד לא תיעד. יש גם סיכון של אפיון חסר. מערכת שנבנית לפי מה שאנשים זוכרים, ולא לפי מה שהשרשרת עושה בפועל, משחזרת את אותן בעיות בכלי אחר.
שני הסיכונים קטנים כשמתחילים במיפוי ולא בקוד.
מה בודקים לפני שמתחילים
לפני כל החלטה כדאי לאסוף תמונה מלאה של מה שקיים:
- רשימת כל התרחישים, בכל הכלים ובכל החשבונות.
- מה מפעיל כל תרחיש, לאן הוא כותב ומי מקבל ממנו מידע.
- אילו גיליונות משמשים מאגר, ומי עורך אותם ידנית.
- באיזה חשבון רץ כל חיבור, ומה קורה אם החשבון נסגר.
- אילו נתונים רגישים עוברים בשרשרת, כמו פרטי לקוחות ומסמכים.
- מה קורה כשתרחיש נכשל, ומי שומע על זה.
הבדיקה של נתונים רגישים חשובה במיוחד. היא עוזרת להחליט איפה יישמר המידע, מי ניגש אליו ואיך מגבים אותו. מידע על אחסון אתרים ועל התחזוקה שלהם יש בעמוד אחסון ותחזוקת אתרים.
איך עוברים בלי לעצור את העבודה
המעבר נעשה בשלבים, תהליך אחד בכל פעם. השרשרת הקיימת ממשיכה לרוץ עד שהחלופה נבדקה.
בוחרים תהליך אחד
בוחרים את התהליך שכואב יותר, או את זה שנוגע בכסף. לא מעבירים הכול יחד. תהליך אחד מאפשר ללמוד איך הנתונים מתנהגים בפועל, לפני שמרחיבים.
מריצים במקביל ומשווים
המערכת החדשה מקבלת את אותם אירועים כמו השרשרת הקיימת, אבל עדיין לא שולחת דבר החוצה. משווים בין שתי התוצאות לאורך זמן. כשיש פער, מבינים מה גרם לו לפני שממשיכים.
מעבירים ומשאירים דרך חזרה
כשההשוואה נקייה, מעבירים את התהליך למערכת החדשה. את התרחיש הישן לא מוחקים מיד. משביתים אותו ומשאירים אותו זמין, כדי שאפשר יהיה לחזור אליו אם משהו לא עובד כמו שצריך.
משאירים לכלים הקיימים את מה שהם טובים בו
לא כל תרחיש צריך לעבור. חיבורים פשוטים, כמו התראה לערוץ של הצוות או העתקת קובץ, יכולים להמשיך לרוץ ב-Make או ב-n8n. המערכת המותאמת מחזיקה את הנתונים ואת הלוגיקה, והכלים הקיימים מחברים אותה למערכות אחרות.
בבחירת שותף למעבר כדאי לשאול כל ספק איך הוא מריץ תהליך במקביל ואיך נראית הדרך חזרה.
איך מתחילים בקטן
הצעד הראשון לא דורש החלטה גדולה. כדאי להתחיל במיפוי התרחישים הקיימים ובבחירת תהליך אחד לבדיקה. המיפוי עצמו כבר חושף כפילויות, חיבורים יתומים וחשבונות שאיש לא זוכר.
לה-רין נותנת לחברות מעטפת דיגיטלית מלאה: קמפיינים ב-Meta וב-Google, אתרים וחנויות WooCommerce, SEO ו-GEO ותוכן, אוטומציה ו-AI, מערכות מותאמות אישית, אחסון ואבטחה. רשימה של כל התחומים מופיעה בעמוד השירותים של לה-רין.
כשהתמונה ברורה, אפשר להחליט אם מחזקים או עוברים, ובאיזה קצב. אפשר לתאם שיחת היכרות עם לה-רין דרך עמוד יצירת קשר.
שאלות נפוצות
מה זה אוטומציה עסקית?
אוטומציה עסקית היא ביצוע אוטומטי של תהליכי עבודה שאחרת היו נעשים בידי עובדים. למשל, ליד שנכנס מטופס נרשם במערכת ניהול הלקוחות ואיש המכירות מקבל עליו הודעה, בלי הקלדה ידנית.
איך יודעים שהאוטומציה הגיעה לגבול?
הסימנים העיקריים הם כפילויות שחוזרות, תקלות שקטות שמתגלות באיחור, הרשאות שעוברות דרך חשבונות אישיים ואדם אחד שרק הוא יודע לתקן. כשכמה מהם מופיעים יחד, כדאי לעצור ולמפות את השרשרת.
האם Google Sheets יכול לשמש מסד נתונים?
לתהליך קטן ויציב הוא יכול לשמש מאגר זמני. אין בו מפתח ייחודי ונעילת רשומות, ולכן בתהליכים שנוגעים בכסף או בכמה תפקידים מומלץ להעביר את הנתונים למסד נתונים אמיתי.
מה ההבדל בין Make ל-n8n?
שניהם כלים לחיבור מערכות ולבניית תרחישים בלי קוד מלא. Make פועל כשירות בענן. את n8n אפשר להריץ גם על שרת של החברה, וזה נותן שליטה על הנתונים ומוסיף אחריות לעדכונים ולגיבויים.
מתי עדיף לחזק את השרשרת הקיימת?
כשהתהליך פשוט, הנפח יציב והבעיות נקודתיות. מזהה ייחודי, נתיב שגיאה, התראות, תיעוד והעברה לחשבון ארגוני הם הצעדים הראשונים לפני שבונים משהו חדש.
איך עוברים למערכת מותאמת בלי לעצור את העבודה?
מעבירים תהליך אחד בכל פעם. המערכת החדשה רצה במקביל לשרשרת הקיימת, משווים בין התוצאות, ורק כשאין פערים מעבירים את התהליך. התרחיש הישן נשאר מושבת וזמין כדרך חזרה.
האם צריך לוותר על Make ו-n8n אחרי המעבר?
לא בהכרח. חיבורים פשוטים, כמו התראות או העתקת קבצים, יכולים להמשיך לרוץ בהם. המערכת המותאמת מחזיקה את הנתונים והלוגיקה, והכלים הקיימים מחברים אותה למערכות אחרות.
מה בודקים לפני שמתחילים?
מומלץ לרשום את כל התרחישים, מה מפעיל כל אחד ולאן הוא כותב, באיזה חשבון רץ כל חיבור ואילו נתונים רגישים עוברים בשרשרת. המיפוי הזה הוא הבסיס לכל החלטה.
