מ״שוק״ ל״ממשק״

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

הצורך ביצירת ממשק בין מערכת ה HR הארגונית לבין מערכת השכר הינו אחד הנושאים החמים כיום בעולם ה HR, על רקע מעבר הולך וגדל של ארגונים גלובליים לתצורת ניהול שכר גלובלית ( Global Payroll Management). מערכות HR גלובליות בתצורת ענן כגון Workday, Oracle HCM Success Factors, ודומיהן, מספקות לארגונים יכולת ניהול של נתוני עובדים של הארגון בכל העולם באופן יעיל יותר מבעבר מחד, תוך יצירת סטנדרט אחיד, סקליביליות וגמישות נדרשת מאידך. בנוסף מערכות HR גלובליות מספקות לחברות גלובליות כלים לצרוך גיבוש תמונת מצב ״מנורמלת״ ביחס לעובדי הארגון ומכשיר רב עוצמה לתהליכי קבלת החלטות הנוגעות להון האנושי של הארגון.
אך בעוד שמערכות HR ניתנות כיום להטמעה ברמה גלובלית (אותה המערכת יכולה לשמש לניהול נתוני העובדים בכל העולם), עדיין לא נוצרו (ספק אם אי פעם ייווצרו) התנאים המאפשרים הטמעה של מערכות שכר המאפשרת חישוב שכר של העובדים במדינות שונות על פלטפורמה אחת מרכזית (מטעמים ברורים של שונות ברגולציה והיבטים מקצועיים שונים הנדרשים ממערכות שכר בין מדינות שונות).
כך שממשק בין מערכת HR למערכת שכר חיוני לצורך הטמעה של מערכת HR גלובלית ולמעשה פרויקט של הטמעת מערכת HR גלובלית אינו שלם ללא פיתוח הממשקים הנדרשים למערכות השכר המקומיות בכל מדינה.

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

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

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

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

בארגונים גלובליים הסוגיה אף מורכבת מכך. ארגונים רבים מעדיפים לנהל את נתוני העובדים בהיבט ה HR במערכת HR גלובלית. העדפה זו נובעת מסיבות רבות אך עקרונית ניתן לקבוע שלניהול פרטי עובדים של הארגון בכל העולם במערכת אחת יתרונות רבים ובראש ובראשונה היכולת ליצור סטנדרטיזציה ולנהל תשתית המאפשרת קבלת תמונה אחידה ורחבה על כוח האדם של הארגון עם יכולת לביצוע drill down עד לרמת מדינה ועובד וככלי מרכזי לתהליכי קבלת החלטות עסקיות ברמה הגלובלית. כך לדוגמה, ארגון המנהל את נתוני עובדיו במערכת גלובלית אחת, יכול להחליט באופן יחסית מהיר על מרכז הפיתוח הבא שלו או על הצוות/מדינה שבה פיתוח של מוצר מסוים יהיה כדאי או נכון יותר עבורו. יכולת זו קיבלה תנופה משמעותית בשנים האחרונות עם כניסתם של מערכות HR גלובליות בתצורת ענן (Cloud base) דוגמת Workday, Oracle HCM ו Success Factors אשר הסירו באחת את החסמים הטכנולוגיים בניהול יעיל של פרטי עובדים במערכת אחת מבוזרת, מכל מקום ובכל זמן.

עם הסרת החסמים הטכנולוגיים (כפי שתואר לעיל) החלו ארגונים לעצב את תצורת התפעול של משאבי האנוש שלהם בהתאם: מערכות HR החלו להתעצב בתצורות גנריות באופן שהמידע הנאגר על העובדים יעשה באופן אחיד, ללא קשר למדינה בה נמצא העובד, וכלים לניהול עצמאי של מידע על ידי העובדים (Employee Self Service) החלו להופיע כחלק מהפתרונות (אפשרות לעדכן שינויים בפרטים אישיים, נתוני היעדרויות, נתונים פנסיוניים ועוד). יתרה מכך גם מרכזי ה HR עוברים שינוי ויותר ויותר ארגונים גלובליים מקימים מרכזי Shared Services המספקים שירותי HR ליחידות עסקיות של הארגון המבוזרות במדינות שונות כולל עדכון פרטי עובדים במערכת ה HR הגלובלית, מרכז תמיכה לפניות עובדים בנושאי מדיניות וכיו“ב.
כעת, מהרגע שנתוני ה HR של העובדים מנוהלים במערכת ה HR הגלובלית, הצורך בהעברת הנתונים למערכת השכר ללא מגע יד אדם, בתהליך אוטומטי ובתדירות גבוהה הופך להיות צורך קריטי; גם בשל הצורך לנהל מערך נתונים ארגוני יעיל, גם בשל הצורך ל Data Integrity, וגם כחלק מדרישות ה Compliance הארגוניות (הפרדת רשויות בין הגורמים הפותחים את פרטי העובד ב HR, לגורמים האחראים על השלמת הנתונים בשכר, היבטים של הרשאות ואבטחת מידע, היבטים של מניעת מעילות וכיו“ב).

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

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

אגב כך, קיימת דרך ידנית נוספת להעברת הנתונים ממערכת HR למערכת השכר והיא באמצעות ייצוא הנתונים ממערכת הHR לקובץ אקסל או קובץ במבנה אחר (דוגמת TXT) ולאחר מכן קליטת הנתונים במערכת השכר על ידי שימוש בפונקציית ייבוא. אך למרות החיסרון של הקלדה ידנית של הנתונים במערכת השכר, גם לשיטה זו חסרונות רבים; לא כל מערכות הHR יכולות לבצע ייצוא של נתונים לפורמט אקסל ובהצלחה ולא כל מערכת שכר בעלת יכולת לבצע ייבוא מוצלח של הנתונים. במקרים רבים גם אם פעולת הייצוא והייבוא אפשריות, מבנה הקובץ המתקבל ממערכת הHR (ראה להלן) אינו תואם את מבנה הקובץ שמערכת השכר מסוגלת לקלוט ונדרשות מניפולציות ידניות רבות על מנת לאפשר קליטה של הנתונים במערכת השכר באופן תקין. (בנוסף, התדירות האפשרית של פעולה כזו היא נמוכה וכך מערכת השכר "מפגרת" אחרי מערכת ה-HR)

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

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

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

• יש צורך במנגנון אמין אשר בתדירות הניתנת לתזמון יעביר את הקובץ הנוצר על ידי מערכת הHR מהשרת בו נשמר קובץ הממשק אל הכספת האלקטרונית ממנה מושכת מערכת השכר את הקובץ. פשוט ככל שזה נשמע, מנגנון זה הוא לעיתים אחד המורכבים להגדרה במיוחד כאשר שני השרתים יושבים פיזית במדינות שונות, ברשתות מידע שונות הפועלות תחת מדיניות ומנגנוני אבטחת מידע שונים. המנגנון עצמו צריך להיות בעל אפשרות הגדרת תזמון העברת המידע וכן לכלול מנגנוני ניטור היודעים להתריע לצד השולח ולצד המקבל במקרה והקובץ האמור להיות משודר או לעבור לקליטה אינו נמצא באחד השרתים במועדים שהוגדרו. עקב כך, דורשת ההגדרה פעמים רבות מעורבות של גורמי IT ואבטחת מידע לצורך אישור והגדרת תצורת התקשורת, פרוטוקול העברת המידע ומנגנוני הניטור.
• מבנה הקובץ הנוצר על ידי מערכת הHR צריך להיות מבוסס על מבנה הקלט של מערכת השכר הקולטת את הנתונים - כך לדוגמה תהליך קליטת עובד חדש במערכת שכר אחת עשויה להיות שונה באופן משמעותי ממערכת שכר אחרת: באופן קיבוץ הנתונים, הגדרת השדות המנדטוריים, מס‘ הפוזיציות הנדרשות לכל נתון, סדר העברת הנתונים וכיו“ב. במקרים שבהם מערכת הHR הגלובלית אינה מסוגלת לייצר קובץ במבנה הנתונים הנדרש על ידי מערכת השכר, מערכת השכר צריכה להיות בעלת יכולת לקרוא את הקובץ ולהמיר בעצמה את הנתונים למבנה הנתונים הנדרש לקליטה במערכת השכר. זה אולי אחד המרכיבים המורכבים יותר בתהליך פיתוח הממשק, בהנחה שמערכת הHR אינה מסוגלת להעביר את המידע במבנה המבוקש על ידי מערכת השכר.
• הנתונים בממשק צריכים לכלול גם את המידע הייעודי והייחודי הנדרש למערכת השכר (לדוגמה בישראל יש צורך בפרטי ילדים ובן זוג לצורכי חישוב מס בעוד שבמערכות שכר במדינות אחרות מידע זה הוא פחות חשוב לצורך חישוב השכר החודשי של העובד)
• הממשק צריך לתמוך בתכונות מערכת ייחודיות של מערכת השכר הקולטת - לדוגמה: אם מערכת השכר תומכת בדיווחים רטרואקטיביים או בניהול תאריכי תוקף של רשומות עובד, אזי מערכת הHR צריכה להעביר את המידע באופן שבו מערכת השכר יכולה לזהות דיווח כדיווח רטרואקטיבי ולשמור תאריכי תוקף לכל רשומת עובד כך שחישובים רטרואקטיביים יבוצעו באופן תקין. דוגמה נוספת היא עניין השפה - בישראל נתונים כגון שם, שם משפחה, כתובת ונתונים נוספים חייבים לעבור בעברית בעוד שחלק ממערכות הHR הגלובליות אינן תומכות בכך, מגבלה משמעותית ביצירת ממשק אפקטיבי.
• יש צורך להגדיר את תצורת המידע המועבר בכל איטרציה (ריצה/הפעלה) של ממשק - האם בכל איטרציה יעברו כל רשומות המידע או רק השינויים שנעשו ברשומות מהאיטרציה הקודמת (ממשק נתונים מלא בכל איטרציה אל מול ממשק דלתאות).
• תדירות הממשק צריכה להתאים לתהליך העבודה שהוגדר בין מחלקת HR למחלקת השכר או בינה לבין ספק השכר של אותה מדינה. ממשקים אוטומטיים מועברים בדרך כלל ברמה יומית ומנגנון התדירות מגדיר למעשה את תהליך העבודה שבין הHR למחלקת השכר. כחלק ממנגנון תדירות הממשק יש להגדיר גם את אופן ומועד עצירת הממשק כחלק ממחזור השכר החודשי. כך לדוגמה, חיוני לעצור את הממשק בתאריך ה Cut-Off של השכר ולחדשו מיד עם סגירת מחזור השכר החודשי.
• מערכת השכר צריכה להיות מסוגלת להפיק פלט (בדרך כלל בתצורת דוח) המציג את תוצאות קליטת הממשק: אילו נתונים נקלטו ובהצלחה, אילו יש לבחון את תקינותם (נקלטו אך המערכת מתריעה על תקינותם) ואילו נתונים קליטתם במערכת השכר נכשלה. הגדרת ההתרעות והשגויים הינו חלק ממנגנון הממשק המפותח במערכת השכר. דוח הקליטה והשגויים המצוינים בו, צריך להיווצר לאחר כל מחזור של קליטת ממשק, והשגויים המצוינים בו צריכים לעבור לאחראי על מערכת הHR, לצורך תיקון הנתונים במערכת הHR וקליטת המחודשת במערכת השכר בממשק המתוזמן הבא (עוד על דוח שגויים - ראה בהמשך)

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

להלן ריכוז קבוצות המידע המומלץ לניהול במערכת HR לצורך העברתו בממשק למערכת שכר:

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

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

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

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

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

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

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

באופן כללי ניתן לסווג תקלות בממשק לשלושה סוגים:

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

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

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

הדוח מתריע על שגויים ושגיאות בנתונים עם קליטתם במערכת השכר בשני אופנים עיקריים:

• ״התראה״ - הנתון נקלט במערכת השכר אך במועד הקליטה הפיקה המערכת התראה לתשומת ליבו של חשב השכר (לדוגמה: "תוקף האירוע מוקדם מתאריך התחלת עבודה")
• ״שגיאה״ - הנתון שהועבר ממערכת הHR שגוי ולא נקלט במערכת השכר (לדוגמה: "לעובד יומי דווח שכר חודשי).
  
  

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

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

1. הסרת האחריות מצוותי HR להזנה תקינה של הנתונים במערכת הHR ברמת התהליך וניהול האיכות
2. פגיעה במהימנות הנתונים במערכת הHR שכן נוצרים פערי מידע בין הנתונים במערכת השכר (הנתונים התקינים) לבין הנתונים במערכת הHR.
3. פגיעה בעיקרון הפרדת הרשויות (Segregation of Duties) שהינו חלק מהותי מהתקינה הגלובלית (Compliance) ומדרישות ה SOC.
   
   

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

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

על מנת לוודא מהימנות וזהות נתונים מלאה, ארגונים רבים מקיימים מנגנון בקרה חודשי הכולל השוואה בין בסיס הנתונים של מערכת השכר לבסיס הנתונים של מערכת הHR. הדבר מתבצע בד״כ על ידי שימוש באקסל, מערכת BI או מערכת Data Warehouse, אליה מועברים בתום כל חודש שכר שני קבצים: קובץ ממערכת השכר וקובץ ממערכת הHR, הכוללים כל אחד את שדות הנתונים המועברים ממערכת הHR למערכת השכר. במערכת ה DW מתבצעת אז השוואה בין שדות הנתונים שבין שני הקבצים, ונתונים המוצפים כשגויים מעידים כי המידע באחת המערכות אינו מהימן. בתום תחקור ובדיקה של החריגה, יש לעדכן את הנתון התקין במערכת הHR כך שהוא ישוקף במערכת השכר באופן תקין במסגרת הממשק הבא.

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

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

עוד בחילן: מערכת שכר | שכר בדיגיטל | טופס 101 מקוון

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