אוטומציה של פיטורי עובדים ב-Bitrix24

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

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

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

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

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

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

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

מה משתנה בעבודת השירות לאחר האוטומציה

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

זמן סגירת ההרשאות

מהגשת הבקשה ועד לחסימת החשבון ושלילת ההרשאות חולפות 15–30 דקות במקום יממה. התרחיש נבנה על תהליכים עסקיים ב-Bitrix24 ואינו תלוי במי מהמנהלים שנמצא במשמרת — צוואר הבקבוק "ממתינים לאדם הנכון" נעלם.

שיעור הפעולות הידניות

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

סוג התקלות שנחסם

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

קבלת התיקים בידי העובד החדש

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

מצבי טיפול במשימות בעת פיטורים: השוואת גישות

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

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

שלבי ההטמעה: מביקורת החשבונות ועד למסירה

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

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

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

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

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

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

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

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

חבילת המסמכים וההגדרות בסיום

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

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

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

מקרה בוחן: כיצד קוצר זמן סגירת ההרשאות

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

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

בנינו את התהליך מחדש סביב סטטוס כרטיס העובד ב-Bitrix24: עובד משאבי האנוש מעביר אותו ל"מפוטר", ומכאן מופעל תרחיש אחד בלי מכתבים ידניים.

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

מדדים לפני ואחרי

• אישורים לפיטור אחד: 6 → 1.
• זמן ניתוק מלא: 3 ימי עבודה → 40 דקות, כולל שירות הגיבוי.
• משימות שאבדו במסירת התיקים: 11 מתוך 20 → 0.
• שיעור הפיטורים שנסגרו בלי תזכורות ידניות: 68% → 100%.

אם שירות לא אישר את הניתוק בתוך 15 דקות, התרחיש מסלים את המשימה למהנדס תורן — ההרשאה אינה נשארת "תלויה" בשקט.

דיווח על הרשאות

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

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

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

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

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

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

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

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

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

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

כיצד קובעים הפעלה לתאריך יום העבודה האחרון?

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

כיצד מטופלת חופשה שלאחריה פיטורים?

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

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

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

מה עושים עם מערכות שאין להן חיבור רגיל ל-Bitrix24?

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

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

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

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

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