מלם Payroll: חיבור בין שכר, נוכחות ו-BI

מלם שכר פלוס מוכרת שכר, נוכחות ומשאבי אנוש כחבילה אחת על בסיס נתונים משותף - הספק מציין את Malam Payroll, את NeoPay, את SAP Payroll, את מערכת הנוכחות TRM, את Synerion Enterprise ואת HR-M - ומשווקת את זה כמקור אמת אחד. דיווח בתוך החבילה פשוט. דיווח מחוצה לה הוא בעיית מודל, לא בעיית חיבור.

שלוש שכבות, שלוש רזולוציות שונות

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

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

איזו שאלה אתם בעצם שואלים?

כמעט כל בקשה לדשבורד שכר היא אחת מארבע שאלות, והן דורשות מדידות שונות:

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

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

למה מספרי השכר משתנים אחרי סגירת החודש?

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

להתנהגות הזאת שלוש השלכות על המודל, וכולן מבניות ולא קוסמטיות:

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

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

מודל מינימלי ששורד מפגש עם המציאות

ארבע טבלאות נושאות כמעט הכול, ואף אחת מהן לא דורשת API:

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

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

איפה שכר עידוד ושעות פרויקט מסבכים את התמונה

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

בכל פעם שזה קורה, שלושה דברים צריכים בעלים:

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

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

מה מלם מפרסמת ומה צריך לבקש

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

לכן שיחת ההוצאה זהה לזו שתנהלו מול כל ספק שכר ישראלי:

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

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

מקורות

• מלם שכר פלוס - דיווחי נוכחות
• מלם שכר פלוס - דף הבית
• מבנה אחיד להעברת מידע ונתונים בשוק החיסכון הפנסיוני - רשות שוק ההון