הגדרת תכנון משאבים ב-Bitrix24

מדוע תכנון משאבים ב-Bitrix24 אינו מתיישב עם הביצוע

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

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

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

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

מה נותן מעגל עומס אחיד: אפקט בגדלים מדידים

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

התפוסה שקופה באופק של מספר שבועות

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

התכנון יוצא מהביצוע, לא מהציפיות

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

רישום עומס לפי פרויקטים — בתמונה אחת

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

בדיקת טבלאות ידנית נעלמת

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

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

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

השוואת מצבים

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

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

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

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

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

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

סכמות עומס, תפקידי גישה ודוחות תפוסה

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

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

מקרה בוחן: איך אגף של 40 איש הפסיק לתכנן בטבלאות

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

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

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

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

במה תכנון משאבים שונה מרישום עומס עובדים

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

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

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

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

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

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

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

האם התכנון קשור למשימות ולפרויקטים?

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

מה יקרה אם עובד עסוק בכמה פרויקטים?

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

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

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

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

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

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

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