מסמך אפיון ויישום Salesforce פרויקט גמר
ניהול תהליכי השמה חברת WeJobs
מסמך אפיון ויישום Salesforce
מסמך אפיון ויישום Salesforce פרויקט גמר CRM-Period
ניהול משרות וגיוס עובדים – : WeJobs
פרטי הפרויקט
|
שם הפרויקט |
מערכת ניהול משרות וגיוס עובדים |
|
מסלול |
יישום Salesforce – CRM-Period |
|
שם הסטודנט: |
עדי דורון |
|
מרצים |
מיכל חביב | אורן מורן | גיל הוד | הודיה שלו |
|
תאריך הגשה |
חלק א – עדכון | חלק ב הגשה |
|
גרסת מסמך |
v1.73 |
תוכן עניינים
תקציר מנהלים (Executive Summary)
מטרת הפרויקט היא יישום מערכת Salesforce לניהול מקצה-לקצה של תהליכי השמה:
פתיחת משרות, ניהול מועמדים, ראיונות, התאמה, השמה ומעקב לאחר קליטה.
המערכת תספק מקור אמת אחד, אוטומציות ודוחות ניהוליים בזמן אמת.
הפרויקט מתאר אפיון ויישום מערכת Salesforce לניהול תהליכי השמה מקצה לקצה:
איסוף מועמדים, ניהול לקוחות (מעסיקים), פתיחת משרות, תיאום ראיונות,
ביצוע השמות, ומעקב KPI תפעולי וניהולי. המטרה היא סטנדרטיזציה של התהליך,
שיפור איכות הנתונים, הפחתת עבודה ידנית, ושקיפות מלאה באמצעות דוחות ודשבורד
תוצרים עיקריים:
- מודל נתונים מותאם (אובייקטים ושדות) לתהליך השמה
- אוטומציות (Flows) לניהול סטטוסים, התראות, ומשימות
- מסכי Lightning מותאמים לפרופילי משתמש (Recruiter / Manager)
- דוחות ודשבורד לניהול משפך השמה ומדדי ביצוע
- תוכנית בדיקות UAT ומסמך הדרכה למשתמשים
המצב הקיים (AS-IS)
תיאור החברה
WeJobs היא חברת השמה שלי לשעבר הפועלת בישראל ומלווה ארגונים בתהליכי גיוס. החברה מנהלת מאגר מועמדים, לקוחות עסקיים, ומשרות פתוחות – באמצעות שילוב של Excel, מיילים, ו WhatsApp. מצב זה מייצר כפילויות, חוסר עקביות בסטטוסים, ואובדן מידע לאורך התהליך.
תהליכים קיימים
המצב היום התהליך מנוהל באמצעות Excel, מיילים ו-WhatsApp ללא מערכת מרכזית
- קליטת מועמד: קבלת קורות חיים, הזנה ידנית לקובץ, והמשך תקשורת במייל.
- פתיחת משרה: בקשה ממעסיק, תיעוד באקסל, ושיתוף במייל למגייסים.
- שידוך: התאמה ידנית בין מועמד למשרה, תיאום ראיונות, ומעקב בוואטסאפ
- השמה: סיכום בעל פה, ללא תיעוד אחיד של תנאים, דמי הצלחה, ומועד התחלה.
בעיות ואתגרים (Pain Points)
| # | בעיה | השפעה |
|---|---|---|
| 1 | סטטוסים לא אחידים (ראיון/הצעה/השמה) בין מגייסים | עיכובים בהשמה, ניהול משפך לא מדויק וקושי בניהול עומסים |
| 2 | מידע מבוזר | איבוד נתונים |
| 3 | אין דוחות או מדדים (Time to Fill, Conversion) | קושי ניהולי, קבלת החלטות ללא נתונים |
| 4 | אין SLA | פגיעה בלקוחות |
| 5 | כפילויות במועמדים ובמשרות, ללא מנגנון דה-דופליקציה אחיד | בזבוז זמן, טעויות בתקשורת מול לקוחות |
מטרות הפרויקט (TO-BE) ו- (KPIs)
מטרות עסקיות
שקיפות, אוטומציה של תהליכים, מדידה.
- אחידות תהליך ומדיניות סטטוסים בכל הארגון
- שיפור איכות נתונים והפחתת כפילויות
- קיצור זמן איוש (Time to Fill) באמצעות אוטומציות ומשימות
- שקיפות מלאה למשפך גיוס והחלטות מבוססות נתונים
מדדים להצגה בדף הבית (KPIs)
- רשימת משרות פתוחות
- רשימת מועמדים בתהליך
- רשימת מועמדים שממתינים להחלטה
Scope הפרויקט
In Scope
אובייקטים, Flows, דוחות, הרשאות, דשבורד, Lightning Pages
- הקמת אפליקציה ייעודית: WeJobs Recruiting
- הגדרת אובייקטים: מועמד, משרה, מועמדות (קישור), ראיון, מטלה, המלצה (ממליץ)
- אוטומציות Flow: TBD
- הרשאות: Profiles/Permission Sets, Role Hierarchy, Sharing בסיסי
- דוחות ודשבורד: רשימת משרות פתוחות, מועמדים בתהליך, מועמדים שממתינים להחלטה
- בדיקות UAT והדרכת משתמשים
Out of Scope
אינטגרציות חיצוניות, מיגרציה
- אינטגרציה דו-כיוונית עם מערכות ATS חיצוניות
- מיגרציה מלאה של היסטוריה מאקסלים ישנים (בוצע רק סט נתונים מדגם)
אפיון תהליכים עסקיים (Use Cases)
| ID | Use Case | Actor | Trigger | תוצאה |
|---|---|---|---|---|
| UC-01 | קליטת מועמד חדש | TBD | קליטת קו"ח או ליד חדש | קורות חיים במערכת |
| UC-02 | פתיחת משרה ללקוח | TBD | בקשה ממעסיק | משרה פתוחה ממעסיק |
| UC-03 | שיוך מועמד למשרה (מועמדות) | TBD | מועמד מתאים למשרה פתוחה | זימון וסטטוס מעודכן |
| UC-04 | תיאום ראיון ועדכון תוצאות | TBD | הוגדר ראיון עם המעסיק | Application |
| UC-05 | השמה וסגירה עסקית | TBD | קבלת המועמד לעבודה והסכמה על תנאים | Application |
אפיון מבנה נתונים (Data Model)
אובייקטים סטנדרטיים
| Object API | תיאור |
|---|---|
| Reports | דוחות להצגת המקורות הטובים ביותר |
| Dashboards | מאגד דוחות ונתונים על משרות פתוחות מועמדים חזקים |
אובייקטים מותאמים אישית
| Object API | תיאור |
|---|---|
| Candidate | מועמד (פרטי מועמד, כישורים, סטטוס במאגר) |
| Jobs | משרה/דרישת לקוח (תפקיד, אזור, שכר, סטטוס) |
| Applications | מועמדות: קישור N:N בין מועמד למשרה + סטטוס תהליך |
| Interviews | ראיון: תאריך, סוג, תוצאה, הערות |
| Recommendations | המלצות / המלצה - ממליץ |
| Assignments | מטלת בית |
קשרים בין אובייקטים
תרשים קשרים (ברמה לוגית)
Job (משרה) 1 ——< Application (מועמדות) >—— 1 Candidate (מועמד)
ומתחת ל־Application (כהורה תהליך):
- Application ——< Interview
- Application ——< Assignment
- Application ——< Recommendation
ובנוסף:
- Recommendation ——(Lookup)→ Candidate (לנוחות דיווח/שליפה)
- Interview ——(Lookup)→ User (Interviewer)
קישור: Application ⬅ Job (Master-Detail)
סיבת הבחירה:
- במסמך מופיע: “מועמדות למשרה” היא ישות תלוית משרה ומקשרת בין מועמד למשרה
- עסקית: כשמשרה נסגרת/נמחקת (בדגש על מחיקה חריגה), כל המועמדויות אליה מאבדות הקשר העסקי שלהן.
- נדרש לתמיכה בדוח “רשימת משרות פתוחות” + יכולת למדוד עומס/כמות מועמדויות לכל משרה.
ההשפעה על הדוחות:
- מאפשר Roll-Up Summary על Job:
- Count של (Application) מועמדויות
- פילוחים לפי שלב מועמדות (בדוחות דרך Summary/Grouping,ו- Roll-Up דרך שדות עזר אם נרצה בעתיד)
- הדוחות “משרות פתוחות + כמה מועמדויות” נהייה טבעי יותר.
משמעות למחיקה
- מחיקה מדורגת: מחיקת Job תמחק את כל ה־Applications (ואיתם גם Interviews/Assignments/Recommendations אם הם תלויים ב־Application).
- זה “חד” אבל עקבי לוגית.
- בפועל: ברוב הארגונים לא מוחקים משרות — משנים סטטוס ל“סגורה”.
משמעות לביצועים
- Roll-up native ב־Salesforce → יעיל מהיר "וזול" יחסית לפתרונות Flow.
האם אפשר לבחור אחרת ?
כן: Lookup מ- Application ל- Jobs
השלכות בחירה זו:
- אין Roll-Up native על Job (נדרש פתרון Flow כדי לספור מועמדויות).
- Application היה יכול “לחיות” בלי משרה (פחות הגיוני עסקית).
- שיתוף/בעלות לא יורשים אוטומטית מהמשרה.
קישור Application ⬅ Candidate (Lookup)
סיבת הבחירה:
- מועמד יכול להגיש מועמדויות למספר משרות.
- בחרתי Lookup (ולא Master-Detail) כדי:
- לא להחיל מחיקה אוטומטית של מועמדויות כשמוחקים מועמד (לא נכון עסקית).
- Lookup שומר על היסטוריית מועמדויות גם אם מועמד נמחק.
משמעות לדוחות
- מאפשר דוחות “מועמדים בתהליך/ממתינים להחלטה” על בסיס Application
- אין Roll-Up Summary על Candidate כי ( Lookup)
משמעות לביצועים
- גמישות גבוהה, פחות Cascade
האם אפשר היה לבחור אחרת?
כן: Master-Detail מ- Applications ל – Candidate
השלכות בחירה זו:
- היה Roll-Up native על Candidate + אכיפת “אין Application בלי Candidate” ברמת קשר
תובנה מקצועית
- אם חשובים KPI/ דשבורדים על Candidate בצורה קלאסית ⬅ Master-Detail
- אם חשוב “שימור היסטוריה גם אם מועמד נמחק/מנוקה” ⬅ Lookup
קישור Recommendation ⬅ Application (Master-Detail)
סיבת הבחירה:
- המלצה היא תיעוד בתוך מועמדות ספציפית. אין לה משמעות בלי Application
- מופיע במפורש במסמך: “קשר אב-בן”
משמעות לדוחות
- Roll-Up על Application:
- Count להמלצות
- מאפשר לבנות לוגיקה עתידית: “יש/אין המלצה” או מספר המלצות לפני החלטה.
משמעות למחיקה
- מחיקת Application תמחק את ההמלצות שלה ⬅ נכון לתהליך.
משמעות לביצועים
- מבנה היררכי עקבי ו Native relationship + roll-ups
האם היה אפשר לבחור אחרת ?
- Lookup – לא מומלץ כאן כי זה סותר דרישת “אב-בן” לפי המסמך, ויפגע בעקביות תהליך.
קישור Interview ⬅ Application (Master-Detail)
סיבת הבחירה
- לפי המסמךInterview הוא אירוע בתוך תהליך המועמדות (Application)
- במציאות אין ראיון בלי מועמדות ספציפית
משמעות לדוחות
- Roll-Up על Application:
- מספר ראיונות (ניתוח ראיונות כחלק מהתהליך)
- ממוצע התרשמות טכנולוגית/יחסי אנוש/מוטיבציה (בעתיד אם נייצג מספרית או באמצעות שדות עזר)
- מאפשר דשבורדים: “מועמדויות עם X ראיונות” או “ממתינות לראיון HR”.
ביצועים
- יעיל יותר מאוטומציות לספירה.
- אין "ראיון יתום", אכיפת שיוך
האם היה אפשר לבחור אחרת ?
- Lookup – יאפשר ראיון “יתום” בלי מועמדות, פחות נכון עסקית, וגם יפגע ב־RollUps
קישור Assignment ⬅ Application (Master-Detail)
סיבת הבחירה
- לפי המסמך Assignment נשלח “במסגרת המועמדות”
- הוא חלק מובנה בתהליך
משמעות לדוחות
- Roll-Up על Application:
- מספר מטלות
- ממוצע ציון מספרי
- סטטוס מטלות (נשלח/הושלם/נבדק)
משמעות למחיקה
- Application נמחק ⬅ מטלות נמחקות.
ביצועים
- מאפשר ביצוע של אוטומציה באופן אגרגטיבי (Flow aggregations)
- RollUps – טבעי (Native Rollups)
האם היה אפשר לבחור אחרת ?
- Lookup – פחות מתאים, יצריך אוטומציות לשמירת מדדים
- ויאפשר מטלות יתומות.
קישור Recommendation ⬅ Candidate (Lookup)
סיבת הבחירה
- לפי המסמך נוסף לצורך “קשר למועמד”
- מאפשר חיפוש ודוחות על המלצות לפי מועמד, בלי לסבך היררכיה
למה Lookup ולא Master-Detail ?
- האובייקט Recommendation כבר Detail של Application (Master-Detail).
לא נרצה להפוך אותה לעוד Detail של Candidate כי:
-
- זו “תלות כפולה” מיותרת (Recommendation כבר מגיעה ל־Candidate דרך Application).
- Lookup נותן לנו גמישות (למשל: אם בעתיד נרצה לשייך המלצה למועמד גם מחוץ למועמדות, או להעביר המלצה בין מועמדויות בצורה מבוקרת).
משמעות לדוחות
- מקל על דוחות שמתחילים מאובייקט Recommendation ומקובצים לפי Candidate.
- לא חובה טכנית (כי אפשר Report Type דרך Application→Candidate)
- שימושי מכיוון שמפחית מורכבות Report Types.
משמעות למחיקה
- אם Candidate נמחק, ה־Lookup יתאפס/יחסם לפי הגדרות (ולא יפיל את ההמלצה מיד),
אך בפועל Candidate לא אמור להימחק.
- ב- LookUp אין מחיקה מדורגת בניגוד ל־Master-Detail
האם היה אפשר לבחור אחרת ?
- לא לשים קשר ישיר או ליצור קשר בכלל ולהסתמך על Application→Candidate בלבד.זה אפשרי, נראה שפחות נוח לדוחות מסוימים.
קישור Interview ➡ User (Interviewer) (Lookup)
סיבת הבחירה
- המסמך מגדיר “User מראיין”
- User הוא סטנדרטי, ולכן Lookup הוא הבחירה הנכונה.
משמעות לדוחות
- דוחות: כמה ראיונות לכל מראיין, איכות התרשמות ממוצעת לפי מראיין, עומסים
משמעות למחיקה
- אם משתמש יוצא מהארגון/מנוטרל, הרשומה עדיין קיימת ,לרוב Salesforce לא “מוחק” משתמשים.
אלטרנטיבה ?
- Text field לשם המראיין — לא מומלץ (אין עקביות, אין דוחות לפי משתמש אמיתי).
תרשים ERD של הפרויקט
אפיון שדות אובייקט Candidates (Fields Specification)
| DateType | Filed Name | Filed LABEL |
|---|---|---|
| Text (80) | Name | Candidate Name |
| Long Text Area (32768) | Candidate_Notes__c | Candidate Notes |
| Picklist | Candidate_Status__c | Candidate Status |
| Picklist | City__c | City |
| Picklist | Candidate _Gender__c | Candidate Gender |
| Date | Consent_Date__c | Consent Date |
| Checkbox | Consent_to_Contact__c | Consent to Contact |
| Lookup (User) | CreatedById | Created By |
| Picklist | Current_Process_Step__c | Current Process Step |
| Picklist | Education_Level__c | Education Level |
| Email__c | ||
| Lookup (User) | LastModifiedById | Last Modified By |
| URL (255) | LinkedIn_URL__c | LinkedIn URL |
| Picklist | Main_Tech__c | Main Tech |
| Phone | Mobile_Phone__c | Mobile Phone |
| Lookup (User,Group) | OwnerId | Owner |
| Picklist | Source__c | Source |
| Number (2, 0) | Years_Of_Experience__c | Years Of Experience |
אפיון שדות אובייקט Jobs (Fields Specification)
| DateType | Filed Name | Filed LABEL |
|---|---|---|
| Date | Close_Date__c | Close Date |
| Lookup (User) | CreatedById | Created By |
| Long Text Area (32768) | Description__c | Description |
| Text(8) (External ID) | External_ID__c | External ID |
| Checkbox | Hybrid__c | Hybrid |
| Formula (Text) | Job_Flag__c | Job Flag |
| Formula (Text) | Job_Requirements1__c | Job Requirements |
| Text (80) | Name | Jobs Name |
| Lookup (User) | LastModifiedById | Last Modified By |
| Picklist | Management_Level__c | Management Level |
| Date | Open_Date__c | Open Date |
| Lookup (User,Group) | OwnerId | Owner |
| Checkbox | Requires_Degree__c | Requires Degree |
| Checkbox | Requires_Dev_Background__c | Requires Dev Background |
| Checkbox | Requires_Over_1_Year_Experience__c | Requires Over 1 Year Experience |
| Picklist | Salary_Range__c | Salary Range |
| Picklist | Status__c | Status |
| Formula (Text) | Job_requirements__c | דרישות התפקיד |
אפיון שדות אובייקט Application (Fields Specification)
| DateType | Filed Name | Filed LABEL |
|---|---|---|
| Auto Number | Name | Application Name |
| Picklist | Application_Process__c | Application Process |
| Lookup (Candidate) | Candidate__c | Candidate |
| Formula (Number) | Candidate_Score__c | Candidate Score |
| Picklist | Candidate_Source__c | Candidate Source |
| Lookup (User) | CreatedById | Created By |
| Picklist | Fit_Level__c | Fit Level |
| Long Text Area (32768) | General_Notes__c | General Notes |
| Checkbox | Has_Recommendation__c | Has Recommendation |
| Master-Detail (Jobs) | Jobs__c | Jobs |
| Lookup (User) | LastModifiedById | Last Modified By |
| Picklist | Motivation_Level__c | Motivation Level |
| Formula (Text) | Motivation_And_Flag__c | Motivation Level |
| Formula (Text) | Motivation_Level_Flag__c | Motivation Level Flag |
אפיון שדות אובייקט Interviews (Fields Specification)
| Data Type | API Name (Field Name) | Field Label |
|---|---|---|
| Master-Detail (Application) | Application__c | Application |
| Lookup (User) | CreatedById | Created By |
| Picklist | Interpersonal_Impression__c | Interpersonal Impression |
| Date | Interview_Date__c | Interview Date |
| Text Area (255) | Interview_Location__c | Interview Location |
| Auto Number | Name | Interview Name |
| Picklist | Interview_Type__c | Interview Type |
| Text (80) | Interviewer__c | Interviewer Name |
| Lookup (User) | LastModifiedById | Last Modified By |
| Picklist | Motivation_Impression__c | Motivation Impression |
| Picklist | Tech_Impression__c | Tech Impression |
אפיון שדות אובייקט Assignments (Fields Specification)
| Data Type | API Name (Field Name) | Field Label |
|---|---|---|
| Master-Detail (Application) | Application__c | Application |
| Auto Number | Name | Assignment Name |
| Lookup (User) | CreatedById | Created By |
| Long Text Area (32768) | General_Notes__c | General Notes |
| Lookup (User) | LastModifiedById | Last Modified By |
| Number (3, 0) | Score_Numeric__c | Score Numeric |
| Text (80) | Score_Text__c | Score Text |
| Picklist | Status__c | Status |
| Picklist | Type__c | Type |
אפיון שדות אובייקט Recommendations (Fields Specification)
| Data Type | API Name (Field Name) | Field Label |
|---|---|---|
| Master-Detail (Application) | Application__c | Application |
| Lookup (Candidate) | Candidate__c | Candidate |
| Long Text Area (32768) | Cons__c | Cons |
| Lookup (User) | CreatedById | Created By |
| Checkbox | Enforce_Candidate_Sync__c | Enforce Candidate Sync |
| Long Text Area (32768) | General_Notes__c | General Notes |
| Lookup (User) | LastModifiedById | Last Modified By |
| Long Text Area (32768) | Pros__c | Pros |
| Auto Number | Name | Recommendation Name |
| Recommender_Email__c | Recommender Email | |
| Text (80) | Recommender_Name__c | Recommender Name |
| Phone | Recommender_Phone__c | Recommender Phone |
כללים ואוטומציות (Flows)
TBD
ממשק משתמש (UI)
Pages ו-Layouts מותאמים.
WeJobs Recruiting ייעודית עם ניווט:
Candidates, Jobs, Candidates, Applications, Interviews, Recommendations, Assignments, Reports, Dashboards
הרשאות ואבטחת מידע
TBD
דוחות דשבורדים ותזמונים
תזמון לשליחת אנליזה
בדיקות (UAT)
TBD
הדרכה והטמעה
כתיבת תוכנית הדרכת למשתמשים.
- User Guide קצר (10–15 עמודים): ניווט, יצירת רשומות, עבודה עם הסטטוסים, דוחות.
- הדרכה למגייסים (60 דק'): תהליך End-to-End + תרגול.
- הדרכה למנהלים (45 דק'): דשבורד, KPI, והפקת דוחות.
Deliverables להגשה (CRM-Period)
| Deliverable | שם | היקף/תכולה |
|---|---|---|
| D-01 | מסמך אפיון (מסמך זה) | כולל AS-IS/TO-BE, Use Cases, Data Model, UI, Security, Testing |
| D-02 | Salesforce Org/Project | אובייקטים, שדות, קשרים, Flows, Validation Rules, Layouts, Pages |
| D-03 | Reports & Dashboard | לפחות 4 דוחות + דשבורד אחד עם 4–6 רכיבים |
| D-04 | UAT + הדרכה | טבלת תסריטי בדיקות + User Guide/מצגת קצרה |
| D-05 | מצגת (אופציונלי) | תסריט דמו: תהליך השמה מקצה לקצה |
סיכום
המערכת מספקת פתרון מלא, מדיד ואוטומטי לניהול תהליכי השמה,
יישום Salesforce לתהליכי השמה מאפשר שליטה מלאה במשפך הגיוס, סטטוסים אחידים, אוטומציה של משימות והתרעות, ושיפור משמעותי ביכולת הניהול והדיווח. השלב הבא (לאחר פרויקט הגמר) מומלץ להתמקד בהרחבת יכולות חיפוש/Matching, העשרת נתוני מועמדים, ושילוב אינטגרציות (למשל אימייל/Calendars).
נספח א' – הגשה חלק א'
צילומי מסך של דפי הרשומות
נספח ב' – הגשה חלק ב' - שלב א'
ייבוא נתונים:
תנאים מקדימים לייבוא נתונים:
- הסרת כפילויות
- בדיקת קיום השדות הרלוונטיים באובייקט (בדגש על שדות חובה)
- בדיקה שהקובץ נותן מענה לוולידציות באובייקטים
לדוגמא: Applications (חייב להיות Candidate)
תוצאות ייבוא Candidate
תוצאות ייבוא Jobs
תוצאות ייבוא Applications
רשימות צפייה
נספח ב' – הגשה חלק ב' - שלב ב'
דשבורד: סה״כ מספר משרות פתוחות
הדוח המוצג בדשבורד מציג KPI מרכזי – מספר המשרות הפתוחות במערכת הגיוס של הארגון.
בדוח הנוכחי ניתן לראות כי קיימות 21 משרות פתוחות נכון למועד העדכון המוצג בדשבורד.
הנתון מבוסס על אובייקט Job במערכת, שבו מנוהלות כל המשרות בארגון.
הדוח מסנן את הרשומות כך שיוצגו רק משרות שהסטטוס שלהן הוא "Open", ובכך מספק תמונת מצב עדכנית של היקף הגיוס בחברה.
המידע מוצג כ-Metric / KPI Widget בדשבורד כדי לאפשר למנהלת משאבי האנוש לראות במהירות את היקף הגיוס הכולל מבלי להיכנס לדוחות מפורטים.
מה נעשה ?
- יצרתי Report על אובייקט Job.
- הוגדר Filter:
- Status = Open
- בדוח בוצע חישוב Row Count (ספירת רשומות).
- הדוח הוסף לדשבורד כ-Metric Component המציג מספר יחיד גדול וברור.
למה נבחר לבצע זאת בדרך זו?
- הצגת KPI מרכזי למנהלת הגיוס לפי דרישות הפרויקט, אושרת צריכה לנהל משרות פתוחות ותהליך גיוס עובדים.
הצגת מספר המשרות הפתוחות מאפשרת לה להבין מיד:- מה היקף הגיוס הנוכחי
- האם נדרש להגדיל מאמצי גיוס
- האם יש עומס בגיוס לעומת משאבי HR הקיימים
- שימוש ב-Metric בדשבורד, בחרתי להציג את הנתון כ-Metric מכיוון ש:
a. זהו מדד אחד מרכזי
b. המידע צריך להיות ברור במבט ראשון
c. אין צורך בפירוט או גרף
זו שיטת הצגה מקובלת בלוחות מחוונים ניהוליים.
3. שימוש ב-Filter על Status
a. השימוש בפילטר על השדה Status מאפשר:
b. להציג רק משרות רלוונטיות לתהליך הגיוס
c. להוציא מהחישוב משרות סגורות או שהתקבלה החלטה לגביהן
כך מתקבל נתון מדויק עסקית.
הערך העסקי של הדוח, הדוח מאפשר למנהלת משאבי האנוש:
- להבין את עומס הגיוס הנוכחי
- להחליט האם צריך להוסיף תקני גיוס
- לזהות האם יש יותר מדי משרות פתוחות לאורך זמן
- לעקוב אחרי התקדמות סגירת משרות
דשבורד: מועמדויות לפי שלב בתהליך
הדוח מציג ניתוח של מועמדויות לפי שלב בתהליך הגיוס באמצעות תרשים משפך (Funnel). התרשים מבוסס על אובייקט Application ומקבץ את הרשומות לפי השדה Application Process, כך שניתן לראות כמה מועמדים נמצאים בכל שלב בתהליך – החל מסינון קורות חיים ועד קבלת החלטה. נדרש מסמך: פרויקט סיום – חלק א'
מה נעשה?
נוצר דוח שמחשב את Record Count של מועמדויות ומקבץ אותן לפי שלבי התהליך, ולאחר מכן הוצג בדשבורד כתרשים Funnel.
למה נבחר לבצע בדרך זו?
תרשים משפך מאפשר לזהות במהירות באיזה שלב בתהליך הגיוס מועמדים “נתקעים” או נושרים, וכך לסייע למנהלת משאבי האנוש לייעל את התהליך ולקבל החלטות מבוססות נתונים לגבי שיפור שלבי הגיוס.
דוח עם מועמדים לפי מידת התאמה ומוטיבציה
הדוח מציג משרות עם מועמדים לפי מידת התאמה ומוטיבציה, ומטרתו לזהות מועמדים חזקים בתהליך הגיוס. הדוח מבוסס על נתוני המועמדויות באובייקט Application, ומשלב מידע על המועמד, המשרה והציון הכולל (Candidate Score) המחושב לפי מדדי התאמה ומוטיבציה. נדרש במסמך: פרויקט סיום – חלק א'
לצורך קביעת מדדי ההתאמה והמוטיבציה הוספתי שדה מסוג Formula ובוא הגדרתי לכל סטטוס ערך:
שדה Fit Level -High = 3 | Medium = 2 | Low = 1 והכפלתי ב 10 לקבל תוצאה בעשרות (ראיה עתידית ל 100)
שדה Motivation Level -High = 3 | Medium = 2 | Low = 1 והשארתי ביחידות לדיוק גבוהה
להלן הנוסחה בשדה:
( CASE(TEXT( Fit_Level__c ), "High", 3, "Medium", 2, "Low", 1, 0) * 10)
+
CASE(TEXT(Motivation_Level__c), "High", 3, "Medium", 2, "Low", 1, 0)
מה נעשה?
נבנה דוח המציג מועמדים שלא נדחו, הכולל את שם המועמד, המשרה אליה הגיש מועמדות ואת ציון ההתאמה הכולל. הנתונים ממוינים לפי Candidate Score ומודגשים באמצעות Conditional Formatting כדי לזהות במהירות מועמדים חזקים.
למה נבחר לבצע בדרך זו?
הצגת הנתונים בטבלה עם דירוג וצביעה מאפשרת למנהלת משאבי האנוש לאתר במהירות מועמדים בעלי התאמה גבוהה
בצבע ירוק | התאמה בינונית בצבע כתום | והתאמה נמוכה בצבע אדום, לקבל החלטות גיוס יעילות יותר ולהימנע מפספוס מועמדים איכותיים בתהליך. נדרש: במסמך: פרויקט סיום משאבי אנוש ב
דוח מקורות הגיוס והשוואה בין מספר המועמדויות למספר המועמדים שהתקבלו לעבודה (Hired)
הדוח מציג ניתוח של מקורות הגיוס של מועמדים והשוואה בין מספר המועמדויות לבין מספר המועמדים שהתקבלו לעבודה (Hired). הנתונים מקובצים לפי השדה Candidate Source, וכך ניתן לראות אילו מקורות אמינים (איכותיים) מביאים יותר מועמדים ואילו מקורות מובילים בפועל לגיוס עובדים. – נדרש במסמך: פרויקט סיום משאבי אנוש ב
מה נעשה ?
נבנה דוח על אובייקט Application שבו בוצעה קיבוץ לפי מקור המועמד, ונוספה השוואה בין Record Count של כל המועמדויות לבין Record Count של מועמדים שהתקבלו. הדוח הוצג בדשבורד כתרשים עמודות להשוואה בין הנתונים.
למה נבחר לבצע בדרך זו ?
הצגה השוואתית מאפשרת לזהות אילו מקורות גיוס הם היעילים ביותר, כלומר לא רק מביאים הרבה מועמדים אלא גם מובילים לגיוס בפועל. מידע זה מסייע למנהלת משאבי האנוש לקבל החלטות מושכלות לגבי השקעה בערוצי גיוס אפקטיביים יותר בעתיד.
מקורות הגיוס לפי שלבי תהליך המועמדות
הדוח מציג ניתוח של מקורות הגיוס לפי שלבי תהליך המועמדות. הנתונים מקובצים תחילה לפי
Candidate Source ולאחר מכן לפי Application Process, וכך ניתן לראות באיזה שלב בתהליך נמצאים המועמדים מכל מקור גיוס.
מה נעשה ?
נבנה דוח על אובייקט Application, שבו בוצע Grouping כפול – תחילה לפי מקור המועמד ולאחר מכן לפי שלב בתהליך הגיוס, תוך הצגת Record Count לכל שלב.
למה נבחר לבצע בדרך זו ?
מבנה הדוח מאפשר להבין לא רק מאיזה מקור מגיעים מועמדים, אלא גם **כיצד הם מתקדמים בתהליך הגיוס**.
כך ניתן לזהות מקורות שמביאים מועמדים איכותיים שמתקדמים לשלבים מתקדמים, לעומת מקורות שבהם רוב המועמדים נפסלים בשלבים מוקדמים.
דוח משרות עם הכי הרבה מועמדים איכותיים
מה נעשה ?
נבנה דוח המבוסס על אובייקט Application המציג לכל משרה את מספר המועמדים האיכותיים שהגישו מועמדות. הדוח מסנן מועמדים בעלי מידת התאמה גבוהה ומוטיבציה גבוהה, מקבץ אותם לפי משרה ומחשב את מספרם באמצעות Record Count.
למה נבחר לבצע בדרך זו ?
מאחר שכל הערכת מועמד נשמרת באובייקט Application, זהו המקום המדויק ביותר לנתח את איכות המועמדים. קיבוץ לפי משרה מאפשר לזהות במהירות אילו משרות מושכות מועמדים איכותיים יותר ולסייע למנהלת הגיוס להבין היכן תהליך הגיוס יעיל יותר והיכן יש צורך בשיפור.
מועמדים שנתקעו בתהליך מעל 14 יום
לצורך הדוח הוספתי שדה מסוג Formula באובייקט Application שמודד כמה זמן בתהליך
עם הנוסחה: TODAY() – DATEVALUE(CreatedDate)
מה נעשה ?
נוצר שדה נוסחה באובייקט Application המחושב את מספר הימים שעברו מאז יצירת המועמדות. באמצעות שדה זה נבנה דוח המסנן מועמדים שנמצאים בתהליך הגיוס מעל 14 יום ועדיין לא התקבלה לגביהם החלטה.
למה נבחר לבצע בדרך זו ?
החישוב מאפשר לזהות מועמדים ש"נתקעו" בתהליך הגיוס ולחשוף צווארי בקבוק בשלבי המיון. כך מנהלת משאבי האנוש יכולה לזהות במהירות מועמדים הדורשים טיפול או החלטה ולייעל את תהליך הגיוס.
דוח זמן ממוצע לגיוס לפי משרה - TBD
יצירת דוח על בסיס Jobs with Applications שבו צריך למדוד את משך הזמן בין:
תאריך פתיחת המשרה (Job Open Date)
לבין
השלב שבו מועמד התקבל (Application Process = Hired)
הדוח יחשב:
- מספר ימים לגיוס
- ממוצע זמן גיוס לכל משרה
הצגה באמצעות: Bar Chart – קיבוץ לפי Job Name
למה בחרתי לבצע כך:
הדוח מאפשר להבין איזה תפקידים לוקח זמן רב לגייס.
זה נותן למנהלת הגיוס יכולת להסיק מסקנות כגון:
- האם הדרישות למשרה גבוהות מדי
- האם תהליך הגיוס ארוך מדי
- האם יש מחסור במועמדים מתאימים
זה מדד מקובל בעולם HR בשם Time to Hire והוא אחד המדדים החשובים בניהול גיוס עובדים.
איכות ראיונות לפי מראיין - TBD
(Interview Evaluation by Interviewer)
יצירת דוח מסוג Interviews with Applications.
ניתוח הדוח לפי:
- User (המראיין) – ממוצע הציונים:
- התרשמות טכנולוגית
- יחסי אנוש
- מוטיבציה
- באמצעות דוח זה יהיה ניתן להציג
- Average Score per Interviewer
- Stacked Bar Chart
- בחרתי את הדוח הזה כיוון שהוא מאפשר לזהות:
- האם יש מראיינים שמדרגים באופן מחמיר או מקל מדי
- האם יש קשר בין ציונים בראיון לבין קבלה לעבודה
- האם צריך להדריך מראיינים כדי לייצר הערכה אחידה
כך ניתן לשפר את איכות קבלת ההחלטות בתהליך הגיוס.