מדריך מעשי

ממשימות מפוזרות לתמונה ברורה: בניית מערכת קליטת עובדים עם Lovable

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

Operator AI9 דק׳ קריאה

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

מה תדעו לעשות בסוף

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

לפני שמתחילים

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

1לפני שמתחילים: מגדירים תוצר שאפשר לבדוק

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

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

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

2שלב 1: מתרגמים את תהליך הקליטה למפרט קצר

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

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

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

3שלב 2: מגדירים את הנתונים ואת אופן השמירה

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

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

החליטו היכן יישמרו נתוני הדמה לפני יצירתם. לפי התיעוד שסופק, Lovable מציע backend מובנה, ואפשר גם לחבר פרויקט Supabase בבעלותכם; אין מעבר אוטומטי בלחיצה בין האפשרויות [1]. למדריך בחרו ב-backend המובנה והשאירו את החיבור החיצוני מחוץ להיקף.

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

4שלב 3: יוצרים מסלולים לפי תפקיד

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

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

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

5שלב 4: משייכים אחריות וקובעים כללי יעד

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

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

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

6שלב 5: בונים תצוגת עובד ממוקדת

בתצוגת העובד הציגו את משימות הקליטה שלו, כולל משימות שמישהו אחר מבצע עבורו. הבדילו בין יכולת לראות משימה לבין יכולת לעדכן אותה. לצורך התרגיל, העובד יוכל לעדכן רק משימות שהוא האחראי עליהן; שאר המשימות יוצגו לקריאה בלבד.

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

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

7שלב 6: בונים תמונת התקדמות למנהלים

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

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

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

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

8שלב 7: מריצים תרחישי בדיקה עם תוצאה צפויה

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

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

9שלב 8: משפרים נקודתית וסוגרים את האב־טיפוס

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

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

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

10טעויות נפוצות שכדאי לעצור בזמן

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

11צ'קליסט לסיום והגבול לפני שימוש ארגוני

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

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

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

מקורות וקישורים רשמיים

  1. 1. Connect to Supabase - Lovable Documentation — Lovable Documentation
  2. 2. Prompting best practices - Lovable Documentation — Lovable Documentation

שאלות נפוצות

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

לא לפי התיעוד שסופק: Lovable מציע backend מובנה ואינו מחייב חשבון Supabase נפרד [1]. המדריך מציע להשתמש במובנה ולהשאיר חיבור חיצוני לשלב אחר.

איך מזהים משימה שלא נוצרה, ולא רק משימה שלא הושלמה?

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

מה צריך לקרות כשמחליפים אחראי באמצע הקליטה?

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

האם בורר בין עובד למנהל מוכיח שהמידע מוגן?

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

מה מציגים כשאין משימות חובה במסלול?

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

רשימת בדיקה

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

להמשך קריאה

פתרונות וכלים חדשיםO-SPACE · מעניין במיוחד לפרודוקטיביות בעבודה

בניית אתר עם Lovable: מעמוד שירות ראשון לאתר עסקי שאפשר להציג לאישור

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

9 דק׳ קריאה

פיתוח ואפליקציותO-SPACE · מעניין במיוחד לפרודוקטיביות בעבודה

מי לקח את המקרן? בונים עם Lovable מערכת להזמנת ציוד, מבקשה ועד החזרה

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

8 דק׳ קריאה

פתרונות וכלים חדשיםO-SPACE · מעניין במיוחד לפרודוקטיביות בעבודה

בניית CRM עם Lovable: מתהליך מכירה לאב־טיפוס שאפשר לבדוק

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

9 דק׳ קריאה