כחשבת שכר, אכתוב מזווית אישית, כנה ומעשית על ההחלטה להחליף מערכת שכר, מתוך מה שלמדתי לאורך התהליך במציאות:
הכאבים, הסיכונים, האתגרים שעולים בדרך, התזמון, והצעדים הפרקטיים שיכולים להציל אתכם מטעויות כואבות, ולסיים את התהליך עם מינימום סיכון.
אם אתם, כמוני, חשבי שכר בחברה עם למעלה מ 100 עובדים בישראל, הישארו איתי.
עבדתי במשך שנים ארוכות עם מערכות שכר, מהפשוטות ועד הכבדות. על ענן ועל "שרת פנימי". כל מערכת הביאה איתה הבטחות.
והמשימה שלנו, לבצע את כל החישובים, עם כל המורכבויות של חוזי העבודה, ותחת כל הרגולציה, היא ממש לא סלחנית.
וכשאני אומרת "להחליף מערכת", אני ממש לא מדברת על עניין טכני בלבד. מדובר בפרויקט שמשנה תהליכים, היקפי משימות,
משפיע על רמת הלחץ בעבודה והכי משפיע על קבלת החלטות תקציביות וארגוניות משמעותיות. זה משהו שלא עושים אותו לבד,
וצריך לגייס עבורו מספר גורמי מפתח בארגון שלך.
הכאב היומיומי שכל אחד מאיתנו בטוח יזדהה איתו מורכב מכמה אספקטים, זה מתחיל באותן שגיאות שחוזרות כל חודש,
כמו: שעות נוספות שלא נספרו, טעויות בפיצויי פיטורין, יישום שגוי של נקודות זיכוי/הטבות מס.
כל שגיאה כזו מייצרת לא רק כאב ראש, זמן תפעולי, עלויות כספיות, אלא גם חשיפה מול העובד.
זה ממשיך עם הזנת הנתונים והעברות ידניות מה- HR והנוכחות ל- Payroll, ייצוא קבצי הבנק באופן ידני,
סינון ובדיקת ריג'קטים, כל זה לא רק גוזל זמן יקר (שאין לנו בימי הפקות השכר), אלא גם יוצר פתח לעוד ועוד טעויות.
אני חייבת לקבל מערכת שהאינטגרציה בה חלקה. שמדברת בשפה אחת.
בנוסף, אם לא השכלנו לתת את פעילות הפקת השכר ליותר מאדם אחד, יוצא שאנחנו תלויים רק באותו אדם
וזה בעייתי ביותר, כשרק אדם אחד יודע להפעיל כבר שנים מערכת ישנה, ומה עושים כשהוא נעדר?
וכשאני צריכה להפיק דוחות, לעצמי ועבור ההנהלה, הכי קשה זה לאסוף את הנתונים מכל המקורות במקום להסתמך על מקור אחד, מרכזי.
ברור לכולנו שיש על כתפנו גם את עול הרגולציה שאנחנו נדרשים להיות הכי מעודכנים בה,
ועם יכולת והבנה איך ליישם אותה הכי טוב. זה לא פשוט בלשון המעטה.
כל שינוי חקיקה מביא איתו את החשש לפערים, והכי לא נחמד להסביר קנס או תיקון פסול מול ההנהלה.
הקשיים בדרך להחלפה היו לא מעטים, זה התחיל אחרי שכבר קיבלנו החלטה לצאת לפרויקט ולאתר את המערכת
שהכי טובה לנו, היו מספר גורמים שהעלו חששות, חלקם פחדו ללמוד מערכת חדשה,
וחלקם פחדו מהמורכבות, ומההפרעה לשגרה. מבחינתם "מה שעובד, שימשיך לעבוד"…
וזה ממשיך לעוד מיליון שאלות יותר טכניות ופרקטיות שיש חשש שלא יקבלו פתרון ישים עבורנו.
כשהגיע שלב האפיון, מה שאני עשיתי זה לכתוב במסודר את כל התרחישים (הסכמים קיבוציים, חוזים של שכירים,
קבלנים, עובדים זרים, ועובדי חו"ל, מנגנון של שעות נוספות, פיצויים, בונוסים, פורשים וכו').
אני ביקשתי גם הדגמה על תרחישים אמיתיים ולא דמו גנרי. בנוסף אפיינתי את הדוחות שאני רוצה עבור
השוטף שלי וגם עבור שאר הגורמים בארגון (המנכ"ל, CFO, HR), את כל הפורמטים שאנחנו עובדים איתם
(יצוא של API, BI, Excel וכו'), ווידאתי שכל הדשבורדים יהיו באמת ידידותיים ולא נראים כמו איזה "סלט גדול".
מאחר ואנחנו ארגון של כמה מאות עובדים, עם פוטנציאל צמיחה ראלי, חשוב היה לי לקבל מענה
ותוכנית לתמיכת המערכת בצמיחה במצבת כוח האדם.
גם כל נושא אבטחת המידע הוא סופר קריטי בימנו, כולל ניהול הרשאות, כך שלא כל עובד במחלקת השכר יהיה
חשוף לכל הנתונים, שתהיה חומת מגן הכי רצינית שיש על הנתונים (בתאימות לתקנות וחוקי הפרטיות בישראל),
עם יכולת לזהות ולהתריע מיידית על כל ניסיון חדירה, וכמובן גיבוי ושימוש ההיסטוריה.
ומאחר בדיני עבודה בעולם השכר אנחנו עוסקים, והם מרובים ומשתנים, דרשתי התחייבות לעדכוני חקיקה
במסגרת SLA וזמני תגובה ברורים. אגב, ישנם ספקים שדורשים עלות עבור עדכוני חקיקה, וישנם שלא.
צריך לקחת בחשבון גם את שלב המעבר מהמערכת הישנה שלכם. הגדירו מהם הנתונים שחייבים לעבור,
ודרשו בדיקות התאמה לאחר ההמרה: השוו תוצאות מול המערכת הישנה, על דגימת אמת.
בשלב ההטמעה אני דרשתי POC (Proof of Concept) על נתונים אמיתיים, רק כך עליתי על בעיות אמיתיות.
הגדרתי מראש מדדי הצלחה (KPI): אחוז סטיות מקובל, זמן עיבוד, לו"ז לכל שלב, וקבעתי מה מותר ומה אסור
לשנות בנתונים המקוריים. ולא פחות חשוב, ביקשתי התחייבות חוזית לטיפול בתקלות שנחשפו במהלך ה- POC.
הגדרתי תרחישי בדיקה לעיבודים קריטיים ולדוחות שנתיים. ודרשתי ריצות מקבילות למשך תקופה סבירה.
שימו לב לדגלים אדומים במהלך ה- POC: אם הספק שלכם מסרב לעבוד על נתונים אמיתיים, אם הוא לא מספק
דוח מסודר של תקלות ודרכי תיקון, ואם אין יכולת מוכחת של סימולציה חלקה מול שאר המערכות.
בשלב החוזה, קבעתי בהתייעצות עם גורמים מקצועיים פנימיים אצלנו,SLA ברורים: זמני תגובה לתקלות
קריטיות/ לא קריטיות, זמני תיקון, עדכוני חקיקה (על חשבון מי?), וכל הנושא הסופר קריטי של Availability.
הכוונה כאן למדד של זמינות המערכת, שמודד כמה זמן המערכת פעילה ונגישה למשתמשים בזמן נתון
(בדרך כלל באחוז זמן פעיל בחודש או בשנה (Uptime). יש להגדיר יעד זמינות מפורש (לדוגמה 99.9% או 99.95%)
ומה נחשב "השבתה"? כולל דיווח ותמיכה 24-7, (וכולל פיצוי/ קנסות במקרה של חריגה מהיעדים).
אל תשכחו גם את כל הנושא היותר טכני של רזיליאנס: גיבוי, שכפול נתונים (Redundancy),
DR (Disaster Recovery) וזמני RTO/RPO מוגדרים.
וכשתגיעו לנושא התמחור, הגדירו מה הכי מתאים לכם: פר עובד/ פר מודול/ תשלום חודשי ומהן ההשלכות על צמיחה.
בשלב ההטמעה, אתם חייבים להגדיר תוכנית הכשרה מפורטת למשתמשי מערכת (חשבי השכר, HR, הנהלה,
כספים, כולם ביחד לצד אנשי התפעול וה- IT).
אני ביקשתי כמובן ממליצים, לקוחות דומים באתגרים, בגודל ובענף, ועדיין זה לא מנע ממני להכין תרחיש חזרה (Rollback),
למקרה של כישלון חמור בעת Go‑live, ווידאתי שיש דרך לייצא את כל הנתונים במבנה ברור ומלא במידה ונצטרך לעבור לספק אחר בעתיד.
בשורה התחתונה, אם אתם מבינים שהגיע הזמן לקדם את הארגון שלכם לטובת מערכת שכר מתקדמת, אל תדחו את זה,
משום שמדובר בדר"כ בתהליך ארוך, כפוף בוודאי לתקציב לוחץ, שדורש זמן ומשאבים מכמה גורמים בארגון, שלא תמיד משתפים פעולה…
התחלה מוקדמת תאפשר לכם להפעיל POC אמיתי, לבדוק אינטגרציות בלי לחץ, ולהימנע מ‑Go‑live בתקופות סגירה או חגים.
בנוסף, אני ממליצה לכם לא להתאהב במוצר השיווקי שאתם בוחנים.
תדרשו POC אמיתי, הבטחות בכתב (SLA), בדיקות אבטחה והמרת נתונים מבוקרת. קבלו המלצות
והקימו צוות פנימי שילווה את הפרויקט. אל תעשו זאת לבד!
בהצלחה!
