הגדרת לוח חופשות ב-Bitrix24: תהליכים חכמים ואישור

לוח חופשות ב-Bitrix24: היכן נשבר אישור ידני

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

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

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

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

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

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

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

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

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

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

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

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

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

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

סדר ההגדרה ב-Bitrix24: מביקורת ועד מסירה

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

1. ביקורת פורטל — ספירת מלאי של מחלקות, תפקידים ומנהלים, ייצוא ספרי עזר, איתור כפילויות ורשומות ללא אחראי. מתעדים שדות לתהליך החכם ומקומות שבהם יהיה צורך לנרמל נתונים.
2. מסלול אישור — שרשרת תפקידים «עובד → מנהל → משאבי אנוש» ונקודות שבהן האישור מתבצע במקביל. בנפרד מגדירים החזרה לתיקון והסלמה אם האחראי אינו זמין.
3. הרשאות גישה — מטריצת נראות לפי תפקידים, לא לפי אנשים: העובד רואה את הבקשות שלו, המנהל — את המחלקה, משאבי אנוש — את הסיכום בחברה. הסכימה שורדת העברות וסיומים ללא עריכה ידנית.
4. העברת נתונים — יתרות חופשות, תקופות קודמות, ספרי עזר; התאמה שורה-שורה מול המקור ודוח פערים.
5. סביבת בדיקות — הרצת מחזור שנתי: הגשה, אישור, דחייה, שינוי תאריכים, סגירת תקופה. בכוונה בודקים עזיבת עובד, החלפת מנהל, בקשה חוזרת.
6. מסירה — מדריכים למשאבי אנוש ולמנהלים, תיאור המסלול ונקודות הבקרה, הדרכה על בקשות אמיתיות.

לאחר המסירה ניתן להרחיב את הסכימה: להוסיף סוגי היעדרות, לשנות את סדר האישור, לחבר דיווח בלי לבנות הכול מחדש.

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

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

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

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

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

צוות של 40+ אנשים בש�ישה ערים וארבעה אזורי זמן ניהל מעקב היעדרויות בטבלת Excel ובהתכתבות. את הבקשה כתבו בצ'אט, המנהל אישר במילה, ומשאבי אנוש השוו תאריכים ידנית והעבירו אותם לקובץ משותף. לקראת סוף הרבעון היו בשימוש שלוש גרסאות של הטבלה, ואף אחד לא יכול היה לומר איזו מהן מעודכנת.

מה היה לפני ההטמעה

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

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

מה שינו

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

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

התוצאה

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

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

במה תהליך חכם שונה מרשימת משימות וקטלוג

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

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

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

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

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

ספקות טכניים: הרשאות, אינטגרציות, העברת נתונים

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

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

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

מה עם מעקב שעות עבודה ודוח נוכחות?

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

האם יש מגבלות בסנכרון עם 1C?

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

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

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

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

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