פיתוח מערכת AI לחיזוי עזיבת עובדים

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

תחומי פיתוח AI

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1359
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

מדוע חיזוי עזיבה נשבר על נתונים היסטוריים

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

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

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

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

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

מה נותנת מערכת חיזוי עזיבה לעסק

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

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

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

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

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

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

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

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

גישות לבניית מודל: השוואת אפשרויות

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

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

גישה מתי מתאימה מגבלות
כללי סף מעט נתונים, נדרש התחלה מהירה ולוגיקה שקופה דיוק נמוך, אינה מתחשבת בשילובי גורמים
רגרסיה לוגיסטית נדרשת יכולת פרשנות והסבר לכל החלטה מתקשה לתפוס תלויות לא-לינאריות
עץ החלטה כללים לא-לינאריים פשוטים, ויזואליזציה נוחה נוטה ל-overfitting, לא יציב במדגמים קטנים
Gradient Boosting יש מספיק היסטוריה, חשוב דיוק דירוג הסיכון דורש הסבר באמצעות SHAP, רגיש לדליפות מאפיינים
אנסמבל מודלים סוגי אותות שונים, נדרשת יציבות מורכב יותר לתחזוקה ולוולידציה

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

שלבי יישום מערכת חיזוי עזיבת עובדים

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

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

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

ארטיפקטים ותיעוד שנשארים אצל הלקוח

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

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

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

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

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

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

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

מה עשו

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

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

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

מדד לפני אחרי
שיעור העזיבות שעליהן ניתנה התראה מראש כ-15% מעל 60%
זמן התראה ממוצע 3-5 ימים 3-4 שבועות
זמן HR על ניתוח סיכונים ידני שעות בשבוע דקות לבדיקת נקודות בעדיפות
סגירת משמרת ללא ירידה בהכנסות לא נמדד נשלט בכל נקודה

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

מה זה נתן לעסק

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

במה שונה חיזוי עזיבה מניתוח תחלופה?

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

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

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

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

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

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

ספקות טכניים נפוצים לפני ההתחלה

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

האם יש מספיק נתונים אם רישום כוח האדם נוהל "איך שיצא"?

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

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

האם יהיה צורך להחליף את מערכת ה-HR או להקים מסד נתונים שני?

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

מי יקבל גישה לתובנות האישיות?

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

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

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

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

תארו אילו נתונים ומערכות כבר קיימים אצלכם — נחזור עם הערכת ריאליות התחזית ותוכנית עבודה.

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

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

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

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

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

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