תכנון אוטומציה בעסק: אילו תהליכים להפוך לאוטומטיים ומחשבון כדאיות
אוטומציה עסקית מחברת בין מערכות ופעולות שחוזרות על עצמן: קבלת פנייה, פתיחת משימה, עדכון רשומה או הכנת דוח. הערך שלה נמדד בזמן ובטעויות שהיא חוסכת, וגם ביכולת לזהות כשל ולטפל בו. תהליך לא ברור צריך קודם להגדיר, ורק אחר כך להפוך לאוטומטי. מחפשים מי שיתכנן, יבנה ויתחזק את החיבורים בשבילכם? ראו את שירות אוטומציה עסקית של ברנדיני.
מה תמצאו במדריך?
איזה תהליך כדאי לאוטומט ראשון?
בחרו פעולה שחוזרת לעיתים קרובות, עם קלט מוכר ותוצאה שאפשר לבדוק. העברת פנייה מטופס ל־CRM היא דוגמה טובה: אפשר להגדיר מהו אירוע ההתחלה, אילו שדות חייבים להגיע ומי מקבל את הפנייה. תהליך שמחייב משא ומתן או שיקול דעת מקצועי מתאים יותר לשילוב של אוטומציה ובדיקה אנושית.
- כמה פעמים הפעולה מתבצעת בחודש?
- כמה זמן היא דורשת בכל פעם, כולל תיקון טעויות?
- מה הנזק האפשרי אם פעולה תבוצע פעמיים או לא תבוצע כלל?
- האם קיימת הרשאת חיבור מתאימה בכל מערכת?
- מי אחראי לטיפול כשמגיעה התראה?
דוגמה: מהטופס באתר לטיפול בפנייה
- קבלת טופס: בודקים שהשדות הנדרשים מלאים ושהפנייה כוללת פרטי קשר שימושיים.
- מניעת כפילות: מחפשים רשומה קיימת לפי כלל שהוגדר מראש, במקום לפתוח לקוח חדש בכל אירוע.
- שמירה ושיוך: יוצרים או מעדכנים רשומה ומוסיפים מקור פנייה ומועד.
- העברה לאחראי: פותחים משימה עם מידע מספיק להמשך טיפול, בלי להפיץ נתונים אישיים בערוצים מיותרים.
- בדיקת הצלחה: מוודאים שהרשומה נשמרה. אם החיבור נכשל, מתעדים ומתריעים במקום לסמן את הפעולה כהושלמה.
זהו תכנון לדוגמה, ולא תהליך שחייב להיראות כך בכל עסק. כללי השיוך, המידע שנשמר והודעות ההמשך צריכים להתאים לשירות ולדרך שבה הצוות עובד.
איך בוחרים בין Make, Zapier וחיבור ישיר?
אפשר לגלול בטבלה לרוחב ←
| שיקול | מה לבדוק לפני הבחירה |
|---|---|
| התאמה למערכות | האם החיבור תומך בפעולה המדויקת שנדרשת, ולא רק בשם המוצר? |
| נפח פעילות | כמה פעולות יבוצעו בכל אירוע, כולל ניסיונות חוזרים ובדיקות? |
| טיפול בכשל | האם אפשר לשחזר, להפעיל מחדש ולעצור בלי ליצור כפילויות? |
| תחזוקה | מי יוכל להבין את התהליך ולעדכן אותו כששדה או הרשאה משתנים? |
| עלות כוללת | מנוי, הקמה, תחזוקה וחיובים במערכות המחוברות |
המסלולים ושיטות החיוב משתנים. לפני התחייבות בדקו את מחירון Make ואת מחירון Zapier מול התרחיש שלכם. חיבור ישיר באמצעות API עשוי להתאים לדרישות מיוחדות, אך דורש פיתוח ותחזוקה.
איך מחשבים אם ההשקעה מוצדקת?
אפשר להתחיל מחישוב פשוט: מספר הפעולות בחודש כפול הזמן לפעולה, פחות הזמן שנדרש לבקרה ולטיפול בתקלות אחרי האוטומציה. השוו את הזמן שנחסך לעלויות ההקמה והתפעול. הוסיפו בנפרד ערך שקשה למדוד בשעות, כמו אחידות בתיעוד או טיפול מהיר יותר בפניות.
לדוגמה בלבד: 200 פעולות בחודש, שכל אחת אורכת 3 דקות, הן 10 שעות עבודה ידנית. אם לאחר השינוי נדרשות שעתיים לבקרה, החיסכון התיאורטי הוא 8 שעות. זו הנחת תכנון שצריך לבדוק בפיילוט, ולא הבטחה לתוצאה.
בדיקות לפני הפעלה
- פנייה תקינה, שדה חסר ונתון בפורמט שגוי.
- אותה פנייה שנשלחת פעמיים.
- מערכת יעד שאינה זמינה או הרשאה שפגה.
- עצירה יזומה והמשך טיפול ידני.
- הוכחה שהמידע נשמר במקום הנכון, ולא רק שהפעולה הופיעה ביומן.
האוטומציה צריכה להשתלב בטפסים ובאתר העסק ובתהליך הטיפול של הצוות. כשמטרת השינוי היא שיווקית, מתחילים בהגדרת התהליך העסקי ומחליטים איזה מידע באמת נחוץ לכל שלב.
מחשבון כדאיות אוטומציה: כמה זמן עשוי להתפנות?
הזינו נתונים של תהליך אחד. הערכים הראשוניים הם דוגמה בלבד, ולא מחירון או תחזית. החישוב מתבצע בדפדפן ומשווה זמן עבודה, זמן בקרה ועלויות שהזנתם.
לחישוב אינטראקטיבי יש להפעיל JavaScript. אפשר לחשב ידנית לפי הנוסחאות הבאות.
איך מחשבים ומה המשמעות של התוצאה?
שעות ידניות = מספר פעולות כפול דקות לפעולה, חלקי 60. שעות פנויות משוערות = שעות ידניות פחות דקות הבקרה חלקי 60. ערך חודשי נטו לתכנון = שעות פנויות כפול ערך שעה, פחות עלות תפעול נוספת. כשערך זה חיובי, תקופת איזון תיאורטית בחודשים = עלות ההקמה חלקי הערך החודשי נטו.
זמן שמתפנה אינו בהכרח הוצאה כספית שנחסכת בפועל. התוצאה מניחה שהזמן מקבל את הערך שהזנתם, ושהנפח והעלויות נשארים דומים. כללו בזמן הבקרה גם טיפול בחריגים; כללו בעלות ההקמה גם את עבודת הצוות. אם הערך נטו אינו חיובי, אין תקופת איזון חיובית לפי הנתונים האלה.
לפני שמרחיבים: בודקים תהליך קטן
בחרו סוג פעולה אחד, תעדו את זמן העבודה הידנית והפעילו פיילוט עם דרך חזרה. בדקו גם פנייה כפולה, שדה חסר ומערכת יעד שאינה זמינה. המטרה היא לדעת מה קרה למידע והאם הצוות יכול להמשיך לטפל גם כשהחיבור נכשל.
בנו יומן שמציג מזהה פעולה, תוצאה, זמן ועילה לכשל — בלי להעתיק מידע רגיש שאין בו צורך. לתכנון טיפול בשגיאות בתוך Make אפשר להתחיל מתיעוד הטיפול בשגיאות. ההתנהגות המדויקת תלויה במודול ובתרחיש ויש לבדוק אותה לפני הפעלה.
אחרי הפיילוט חוזרים למחשבון עם נתונים שנמדדו בפועל. אם זמן הבקרה גדול מההערכה, מעדכנים את התכנון לפני שמחברים עוד מערכות. להמשך אפשר לבחון את שירות האוטומציה העסקית.
איך בוחרים תהליך ראשון לאוטומציה?
רשמו שלושה תהליכים שחוזרים בעסק ובדקו בכל אחד מה מתחיל אותו, אילו נתונים דרושים ואיך מזהים סיום מוצלח. מועמד טוב לפיילוט הוא תהליך עם גבולות ברורים, חזרתיות ומספר חריגים שאפשר לנהל. פעולה ארוכה שמצריכה שיקול דעת בכל פעם אינה בהכרח נקודת פתיחה טובה.
| שיקול | מה מחפשים | סימן שצריך הכנה |
|---|---|---|
| בהירות | כללים שאפשר להסביר | כל עובד מבצע אחרת בלי סיבה מתועדת |
| נתונים | מקור זמין ושדות מובנים | מידע חשוב נמצא רק בשיחה או בקובץ לא עקבי |
| חריגים | אפשר לזהות ולהעביר לאדם | טעות קשה לתיקון או אינה נראית בזמן |
| ערך | זמן טיפול או טעויות שניתן למדוד | התועלת מתוארת רק כ״חדשנות״ |
דף החלטה לפיילוט
מלאו עבור כל מועמד: שם התהליך, מספר פעולות, זמן טיפול ידני, עלות הקמה משוערת, בקרה נדרשת, תקלות אפשריות ובעל אחריות.
- בחרו תהליך אחד והגדירו מה נשאר מחוץ לפיילוט.
- הריצו מקרים תקינים ומקרי כשל עם נתוני בדיקה.
- השוו את התוצאה לעבודה הידנית, ולא רק לדיווח שהריצה הסתיימה.
- קבעו איך עוצרים ואיך חוזרים לטיפול ידני.
דוגמה להמחשה: העברת בקשה פנימית מסודרת לתור משימות יכולה להיות התחלה פשוטה יותר מתמחור אוטומטי של עסקה מורכבת. אין כאן דירוג של כלים; ההחלטה נובעת מהתהליך ומההשלכות של טעות.
האם לבחור קודם מערכת?
עדיף להתחיל בדרישות, ואז לבדוק מה המערכות הקיימות יכולות לבצע. כך מצמצמים רכישה של כלי שאינו פותר את הבעיה שהוגדרה.
מה עושים אם הפיילוט אינו חוסך זמן?
בודקים אם זמן הבקרה והטיפול בחריגים גדול מהזמן שהתפנה. אפשר לשנות את ההיקף או להפסיק; עצם ההפעלה אינה הוכחה לכדאיות.
מפת תקלה קטנה לפני אוטומציה גדולה
תהליך טוב מתחיל בפנייה אחת ברורה: מאין הגיעה, אילו פרטים התקבלו, מי אחראי לה ומה אמור לקרות אם איש הצוות אינו זמין. ציירו את המעבר מטופס לאדם לפני שבוחרים פלטפורמה. אם שתי מערכות יכולות ליצור את אותה רשומת לקוח, החליטו איזו מהן היא מקור האמת ואיזה מזהה מונע כפילות. הודעה אוטומטית ללקוח צריכה לומר מה באמת קרה: ״הפנייה התקבלה״ אינה ״נקבעה פגישה״. כך גם במקרה תקלה, הלקוח אינו מקבל הבטחה שגויה.
בחישוב כדאיות מפרידים זמן הקמה, תחזוקה ותיקון משעות טיפול שאכן נחסכות. דוגמה: אם הצוות משקיע דקות ספורות במיון כל פנייה אך רוב הפניות דורשות שיקול דעת, מערכת מורכבת עלולה ליצור יותר עבודה משהיא חוסכת. המחשבון המצורף מסייע להציב הנחות ולבדוק רגישות, לא להבטיח חיסכון. רצוי לרשום טווחי זמן אמיתיים במשך שבוע עבודה רגיל ולהשוות לנתוני פיילוט קטן.
בוחרים פיילוט עם אפשרות חזרה ידנית. יוצרים פניות מבחן תקינות וחסרות, בודקים שיוך, הסכמה לשליחת הודעות, אזור זמן ועדכון סטטוס. בודקים גם מה קורה כששירות חיצוני אינו זמין: האם מתקבלת התראה, האם אפשר להשלים טיפול בלי ליצור כפילות, והאם הנתונים נשמרים במקום הנכון. לאחר הפעלה, בעל תהליך אחד עובר על חריגות וקובע מתי לעצור אוטומציה שהפסיקה להתאים לעסק.
הצלחה אינה רק מספר פעולות שרצו ללא שגיאה טכנית. מדד שימושי הוא זמן תגובה לפנייה מתאימה, שיעור פניות שלא נשכחו וכמות תיקונים ידניים. אם הזמן מתקצר אך הפונים מקבלים תשובה לא נכונה, התהליך דורש שינוי. אם צוות המכירות אינו יודע למה נשלחה הודעה, יש לשפר תיעוד לפני הוספת שלב נוסף. אוטומציה שניתן להסביר, למדוד ולכבות בטוחה יותר ממסלול ארוך שאיש אינו בעליו.
אפשר להכין כרטיס תהליך בן עמוד אחד לפני פתיחת כלי אוטומציה: אירוע שמתחיל את העבודה, נתונים שנכנסים, מי מאשר, מה יוצא החוצה ואיך מזהים כישלון. הכרטיס מאפשר לאיש שירות שאינו מפתח להבין אם המערכת פעלה כראוי. אם התהליך תלוי באדם שמכיר סיסמה או תוסף אחד, מתעדים החלפה אפשרית לפני שמרחיבים אותו.
תהליך בעל כמה שלבים צריך אפשרות חזרה ידנית. תעדו מה העובד רואה כשחיבור חיצוני אינו זמין, האם אפשר להמשיך טיפול, ומתי שולחים הודעה ללקוח. בלי מסלול כזה, מהירות אוטומטית עלולה להפוך תקלה קטנה לפניות אבודות.
להמשך החלטה: לשירות הרלוונטי באתר ולמקור רשמי לבדיקת מידע משתנה.
