הגדרת אוטומציה low-code ב-Bitrix24 מקצה לקצה

הגדרת Bitrix24: היכן תהליכים נשברים בפועל

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

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

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

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

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

אפקט מדיד: זמן, נפח וסוג כשלים

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

מהירות טיפול בפניות

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

שקיפות שלבי העסקה

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

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

אפשרויות הגדרה של Bitrix24: השוואת גישות

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

תבניות מוכנות של הפלטפורמה

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

הרכבה לתהליך ספציפי

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

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

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

ניתוח תהליכים וסכמה

1. ניתוח תהליכים ותפקידים. ראיונות עם מבצעים בכל קטע, מיפוי מסלולים נוכחיים: היכן הפנייה נשארת הכי הרבה זמן, אילו אישורים מתנהלים במסנג'רים, מי בפועל מקבל את ההחלטה. בפלט — רשימת צווארי בקבוק ורשימת תפקידים עם הרשאות אמיתיות, ולא לפי תפקידים מלוח התקנים.
2. סכמת אוטומציה. ישויות והקשרים ביניהן: עסקאות, תהליכים חכמים, משימות, חוזים; שלבים עם תנאי מעבר, שדות חובה, רובוטים וטריגרים. את הסכמה מתאמים לפני ההגדרה — תיקון על הנייר לוקח דקות, תיקון במערכת העובדת שובר סטטיסטיקה שכבר נאספה.
3. הגדרה. משפכים, תהליכים חכמים, תהליכים עסקיים לאישור, הרשאות לפי מחלקות, החלפה עם מערכת חשבונאית ודואר. כל רכיב נבדק על נתוני בדיקה עם תפקידים שונים.

הפעלה ניסיונית ומסירה

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

מה נשאר אצלכם: קונפיגורציות, סכמות, תקנונים

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

תיעוד ותקנונים

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

גישות והרשאות תפקידים

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

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

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

מחלקת מכירות של 14 איש עבדה בלי תקנון אישורים אחיד: כל בקשה להנחה או תנאים אישיים עברה בדואר ובמסנג'רים. העברנו אישורים והקצאת פניות למערך אחד ב-Bitrix24 והסרנו שלבים ידניים — להלן מדדים לפני ואחרי.

מה היה לפני

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

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

מה קרה אחרי

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

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

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

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

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

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

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

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

שאלות טכניות נפוצות לפני תחילת הפרויקט

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

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

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

איך להפריד הרשאות גישה לפי תפקידים?

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

האם המחלקה תוכל לעבוד בזמן היישום?

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

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

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

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

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