חילן מנהלת שכר, נוכחות ומשאבי אנוש על בסיס נתונים אחד. מה זה אומר כשצריך את הנתונים ב-BI, ב-ERP או במחסן נתונים, ואילו ארבע דרכי יציאה קיימות בפועל.
עיקרי הדברים
- חילן כותבת בעמודי הנוכחות שלה שנתוני הנוכחות, השכר ומשאבי האנוש מנוהלים במערכת אינטגרטיבית מלאה על בסיס נתונים אחד, שהעובד מוזן פעם אחת וללא ממשקים.
- זה מבטל ממשקים פנימיים. זה לא יוצר ממשק חיצוני, ובין שני הדברים האלה מתבלבלים כמעט בכל שיחת אפיון.
- לא נמצא תיעוד API ציבורי, רשימת endpoints או מבנה רשומה של חילן. כל אמירה של ספק על "ה-API של חילן" צריכה להגיע כמסמך לפני שמתמחרים לפיה.
- חילן משווקת מוצר BI משלה ומתארת את מערכת הנוכחות כמחוברת אליו הדוק, ולכן השאלה הראשונה היא אם בכלל צריך להוציא נתונים או שצריך דוח בפנים.
- בכל מסלול שנבחר, מפתח הקישור הוא מה שקובע אם הייצוא שמיש: ת"ז, מספר עובד פנימי וקוד יחידה ארגונית לא נוסעים יחד מעצמם.
חילן מנהלת שכר, נוכחות ומשאבי אנוש על בסיס נתונים אחד, ובדיוק בגלל זה ייצוא החוצה הוא פרויקט ולא הגדרה. לא נמצא מפרט API ציבורי של חילן, ולכן בפועל הנתונים יוצאים דרך ייצוא מתוך המסך, דוח מתוזמן, שכבת ה-BI של חילן עצמה, או ממשק שהספק בונה בהתקשרות נפרדת.
מה חילן היא בעצם, ולמה זה משנה את שאלת הייצוא
חילן היא ספקית SaaS ולשכת שירות בתחום השכר וההון האנושי, נסחרת בבורסה בתל אביב, ומוכרת גם שירותי BPO שבהם העובדים שלה מפעילים חשבות שכר ונוכחות עבור הלקוח. הנקודה האחרונה חשובה יותר מכל עובדה טכנית: בהרבה ארגונים אף אחד בפנים מעולם לא נזקק לנתון הגולמי, כי התוצר תמיד היה הרצת תלושים וסט דוחות.
עמודי הנוכחות של חילן מתארים איסוף משעוני נוכחות, מטלפון נייח, מטלפון נייד ומשעון אינטרנטי, ודוחות בקרה וניהול המשלבים נתוני נוכחות, שכר ומשאבי אנוש. הם מתארים גם ניתוח ברמת הארגון, האוכלוסייה והעובד הבודד, וחיבור הדוק למערכת חילן BI.
כשמנהל כספים או תפעול מבקש "לחבר את חילן למערכת שלנו", בדרך כלל מתכוונים לאחד משלושה דברים שונים לגמרי:
- צריך שמספר יופיע בדשבורד שכבר קיים במקום אחר.
- צריך לשייך עלות לפרויקט או לאתר בתוך ERP שחילן לא מחזיקה.
- תהליך במורד הזרם - חיוב קבלן משנה, דיווח למענק, חשבונית ללקוח - צריך שעות ברזולוציה שהתלוש לא נושא.
רק השני והשלישי הם בעיית אינטגרציה. הראשון נענה לא פעם בתוך שכבת הדוחות וה-BI של חילן, בשבריר מהעלות.
האם חילן מפרסמת API ציבורי?
לא. לא אותר מפרט API ציבורי, פורטל מפתחים, רשימת endpoints או מדריך הזדהות של חילן. האתר הציבורי הוא חומר מוצר ושיווק, והפירוט הטכני יושב מאחורי מערכת היחסים עם הלקוח.
זו אמירה על מה שמפורסם, לא טענה שלא קיים ממשק. ספקיות שכר גדולות בישראל בונות באופן שגרתי ממשקים ייעודיים ללקוח במסגרת שירותים מקצועיים. מה שחשוב הוא ההשלכות המעשיות:
- אי אפשר לתכנן מול מפרט שלא קיבלתם. כל הערכה שנעשית לפני שהמבנה בידיים היא ניחוש.
- בקשו את הגדרת הממשק כמסמך עם גרסה, לא כקובץ דוגמה. קובץ דוגמה נודד ואף אחד לא שם לב עד ששדה זז.
- הגדירו מראש למי שייך שינוי: אם הספק מוסיף עמודה, של מי הקריאה.
- הפרידו בין מנגנון ההעברה לתוכן. מבנה מושלם שמגיע לתיבת דואר שאף אחד לא מנטר הוא ממשק שבור.
אותה משמעת נכונה לכל ספק ישראלי בלי תיעוד ציבורי, והגרסה הכללית שלה נמצאת במה עושים כשלספק אין API.
ארבע הדרכים שבהן נתונים יוצאים מחילן
| מסלול | מי בונה | תדירות אופיינית | מה שובר אותו |
|---|---|---|---|
| ייצוא ידני מהמסך | חשב או פקידת שכר | מתי שמישהו נזכר | אדם עוזב, מסנן משתנה, חודש נשכח |
| דוח שמור בהעברה מתוזמנת | הספק, פעם אחת, ואז זה רץ | חודשי או שבועי | הוספת עמודה לדוח מזיזה כל מיקום במורד הזרם |
| חילן BI וניתוח בתוך המוצר | הספק, כמודול ברישוי | רציף | כלום, אבל הנתונים נשארים בתוך חילן |
| ממשק בהתקשרות למערכת שלכם | שירותים מקצועיים של הספק | לפי הסכם | סטיית גרסאות ושינוי לא מתועד בכל אחד מהצדדים |
השורה שנבחרת מהסיבה הלא נכונה היא הראשונה. היא חינם להתחיל והיא היקרה ביותר להפעלה, כי המחיר מתפרס על שתים עשרה התאמות בשנה במקום להופיע כחשבונית.
לפי איזה מזהה מחברים?
לא לפי ת"ז לבד ולא לפי מספר העובד בשכר לבד. ייצוא שנושא רק אחד מהם ייכשל בחיבור בסופו של דבר, והכישלון שקט.
הסיבה היא שאותו אדם ממש ממופתח אחרת בכל מערכת בשרשרת:
- השכר ממופתח לפי מספר עובד פנימי, ייחודי לישות המעסיקה ולא לאדם.
- הנוכחות והחומרה ממופתחות לפי מספר תג או מספר שעון, שמונפק מחדש כשמחליפים תג.
- משאבי אנוש ומערכות מדריך ממופתחים לפי ת"ז, שהיא יציבה אבל היא מידע אישי ואין סיבה לפזר אותה למערכות שלא צריכות אותה.
- ה-ERP או מערכת הפרויקטים ממופתחת לפי קוד משאב משלה, שאף אחד בשכר לא ראה מעולם.
הדפוס שעובד הוא לשאת צמד יציב - ישות מעסיקה ומספר עובד בשכר - כמפתח הטכני, להחזיק ת"ז רק היכן שהתהליך באמת דורש, ולתחזק את המיפוי לקוד המשאב ב-ERP במקום אחד עם בעלים מוגדר. נתוני שכר הם מידע אישי, וככל שפחות מערכות מחזיקות את שדות הזיהוי, כך המשטח שצריך לנהל קטן יותר.
מה עולה ייצוא שנראה כמו דוח
דוח נבנה עבור קורא אנושי, וזה מתגלה ברגע שמכונה קוראת אותו:
- שורות ביניים וסיכום יושבות בתוך הנתונים, וסכימה תמימה סופרת פעמיים.
- כותרות ממוזגות ובלוק כותרת דוחפים את שורת הכותרות האמיתית למטה, והיא זזה כשתיאור המסנן מתארך.
- מספרים מגיעים מפורמטים - מפרידי אלפים, מינוס אחרי הספרות, שעות כ-7:30 ולא 7.5.
- כותרות עמודה בעברית משנות ניסוח בין גרסאות ומתכוונות לאותו דבר.
- חודש בלי נתונים מייצר קובץ עם כותרות ובלי שורות, וזה לא נבדל מייצוא שנכשל אלא אם בודקים.
אם דוח הוא המסלול היחיד, התייחסו לשלב הפענוח כרכיב אמיתי עם בדיקות משלו, לא כנוסחה בגיליון. אותו דפוס כשל במערכת אחרת מתואר בייצוא דוחות מוויזקלאוד וויזקאונט.
מה לסגור מול הספק לפני שכותבים שורת קוד
- התוכן המדויק: אילו שדות ובאיזו רזולוציה - עובד לחודש, עובד ליום, או עובד לרכיב.
- האם תיקונים רטרואקטיביים מופיעים כהתאמות בתקופה הנוכחית או כהיסטוריה שנכתבת מחדש. התשובה הזאת לבדה קובעת אם המאגר שלכם יכול להיות מוסף בלבד.
- מנגנון הקובץ או ההעברה, לוח הזמנים, ומה קורה בהרצה שנכשלה.
- כלל הגרסאות וזמן ההתראה לשינוי.
- מי בארגון שלכם רשאי לקבל את הקובץ, בהינתן שהוא נושא נתוני שכר וזיהוי.
- נתיב בדיקות בנפחים אמיתיים, לא שלוש שורות.
שישה אלה בכתב, והבנייה היא עבודה רגילה. בלעדיהם תגלו כל אחד מהם בתוך סגירת חודש. הגרסה הרחבה של הרשימה נמצאת ברשימת הבדיקות שלפני אינטגרציה: גישה לנתונים ובעלות על כשלים.
מקורות
שאלות נפוצות
האם לחילן יש REST API שאפשר לפתח מולו?
לא אותר מפרט REST API ציבורי, פורטל מפתחים או תיעוד endpoints של חילן. אין בכך הוכחה שלא קיים ממשק ללקוחות בהתקשרות. בקשו מהספק ישירות הגדרת ממשק כתובה עם מספר גרסה לפני שמאפיינים עבודה שתלויה בה.
אפשר לקרוא ישירות ממסד הנתונים של חילן?
חילן מסופקת כשירות ענן, כך שמסד הנתונים אינו שלכם לתשאול ואין להניח גישה ישירה. התייחסו לקובץ המיוצא, לדוח המתוזמן או לממשק שהספק בנה כגבול, ותכננו את הצד שלכם כך שישרוד שינוי במה שיושב מאחוריו.
האם חילן BI מחליפה ייצוא נתונים?
היא מחליפה כשהשאלה נענית כולה מנתוני שכר, נוכחות ומשאבי אנוש. היא לא מחליפה כשהתשובה דורשת הכנסות, עלויות פרויקט או נפחי ייצור שיושבים במערכות אחרות, כי אלה לא נכנסים לכלי של ספק השכר.
כל כמה זמן להריץ ייצוא נוכחות?
לצורכי שכר, פעם אחת בסגירת תקופה ועוד הרצה חוזרת אחרי תיקונים. לדשבורד תפעולי, יומי בדרך כלל מספיק, כי נתוני נוכחות לפני אישור התקופה הם זמניים והזנה חיה בעיקר מציגה לאנשים מספרים שעוד ישתנו.
להמשך קריאה
שירות רלוונטי
אוטומציה לעסקים
אני בונה אוטומציות מותאמות שמורידות עבודה חוזרת מקצה לקצה.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.