תגית: S4HANA

FIORI EXTENSIONS

נספר הפעם על האפשרויות להרחיב יישומי FIORI ללא שימוש נרחב בקוד UI5. כולם כבר יודעים על יישומי FIORI שהם הממשק למשתמש החדש והעיקרי של מוצרי סאפ למיניהם. גם כולם יודעים שהשפה בה הם כתובים היא UI5 או SAPUI5  שהיא ווריאנט של שפת javascript. אך מעטים מכירים את היכולות הרבות שסאפ משחררת ומכניסה למוצר כדי לאפשר הרחבות ל FIORI במיוחד ב S4HANA אבל בהחלט גם ל ECC!

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

Extensions

ECC on ANYDB

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

 UI Adaptation at Runtime – שינוי והתאמת הממשק למשתמש על ידי המשתמש

זוהי בעצם תכונה של SAPUI5 flexibility Services הדומה במקצת ליכולות של CRM WEB GUI. נדגיש כי לא מדובר בשינויים אישיים בממשק הנשארים רק למשתמש הספציפי ונקראים PERSONALIZATION. מדובר בשינויים מהותיים כגון הזזת שדות, שינוי תוויות, העלמת שדות והוספת שדות שישארו בממשק באופן קבוע עבור כל המשתמשים.

UI Adaptation at Runtime

צריך לאתר את גרסת ה FIORI LAUNCHPAD המותקנת אצלכם . כאן:

https://help.sap.com/viewer/product/SAP_FIORI_LAUNCHPAD/EXTERNAL/en-US

ולחפש עמוד של

Adapting SAP Fiori UIs at Runtime – Key User Adaptation

כדי למצא את תנאי הקדם.

כלומר אפשר לכתוב UI5 עם התכונה הזו או לאתר יישומי FIORI  כאלה כפי שמתואר בקישורים הבאים.

https://blogs.sap.com/2020/03/24/sap-fiori-for-sap-s-4hana-adapting-sap-fiori-uis-at-runtime/

https://blogs.sap.com/2018/05/12/fiori-for-s4hana-adapting-terminology-in-sap-fiori-apps-via-key-user-tools/

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

https://blogs.sap.com/2020/04/24/sap-fiori-for-sap-s-4hana-adaptation-transport-organizer/

ECC with CDS on HANA/AnyDB

עם תשתית של CDS מתאפשר פיתוח על בסיס REST שהוא שילוב של ה CDS ברמת ה DB, ODATA להעברה ל FRONTEND ו FIORI / UI5  לעיצוב הממשק למשתמש. תצורה זו גם די מוכרת כבר. ישנם הרבה קורסים / בלוגים וחומר על כך ברשת. ניתן לכתוב VIEWS של CDS עם כל בסיס נתונים (AnyDB)  ובמיוחד עם היכולות המוגברות של HANA.

הרחבות של ה FIORI במסגרת REST ניתנות ב 3 צורות ראשיות:

  1. UI5 Freestyle – כאן אפשר להתחיל לכתוב יישום FIORI מאפס ב UI5, עפ"י הקווים המנחים ליישומי FIORI או להעתיק יישום סטנדרטי ולהרחיב אותו ב UI5.
  2. UI5 Web Components – זהו אמצעי חדש הזמין ב SCP – פלטפורמת הפיתוח בענן של סאפ שהמטרה העיקרית שלו היא ליצור קישורים , API, עם תוכנות וחבילות אחרות במספר שפות.
  3. Fiori Elements – תבניות לבניית FIORI חדש, מפורט בהמשך.

FIORI ELEMENTS

התבניות של FIORI ELEMENTS זמינים גם ל S4HANA וגם ל ECC on HANA . העקרון הוא שעל כל אוביקט במערכת , למשל טבלה Z ית שנבנתה, יכולים לבנות עליה FIORI ELEMENTS ולקבל ישירות 5 סוגי מסכים עפ"י תבניות לשימוש מיידי:

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

Overview Page – מסך להצגת מספר אוביקטים, דוחות, גרפים ממספר מקורות.

List Report View – מסך לרשימה של המופעים המרובים של אובייקט מסויים או הרשומות שלו.

Worklist Page – דומה ל List Report Page אך עם תוספת של Checkbox שעם בחירתו מעביר ישירות ל Object Page של הרשומה

Analytical list Page – מסך אנליטי המציג גרפים, דוחות וניתוחים ממגוון מקורות.

ל FIORI ELEMENTS ישנן הנחיות לבניה על פי FLORPLANS, LAYOUTS וכן סטנדרטים לגבי כל אלמנט בתבניות הללו.

להלן מספר קישורים:

ה WIKI  הראשי:

https://wiki.scn.sap.com/wiki/display/Fiori/Fiori+elements

https://blogs.sap.com/2019/07/30/fiori-elements-is-for-designers-and-product-managers-not-just-developers/

https://blogs.sap.com/2019/07/31/getting-started-with-sap-fiori-elements-video-series-introducing-list-report-and-object-pages-is-now-available/

https://experience.sap.com/fiori-design-web/smart-templates/

https://blogs.sap.com/2020/01/09/fiori-elements-vs-fiori-freestyle-fare-comparison/

קיים אפילו קורס שלם ב OPENSAP הכולל אפשרויות הרחבה אלה

Intelligent Enterprise User Experience with SAP Fiori 3

הרחבות של FIORI ELEMENTS

ניתן תמיד להרחיב בעזרת UI5 FREESTYLE

מומלץ לגעת רק באותם מקומות שמיועדים להרחבה ונקראים EXTENSION POINTS ומתוארים כאן:

https://blogs.sap.com/2019/08/15/extending-sap-fiori-elements-apps/

https://blogs.sap.com/2019/03/04/fiori-elements-extension-and-customization-step-by-step/

https://blogs.sap.com/2021/02/11/best-practices-for-extending-sap-fiori-elements-apps-with-custom-controls-and-logic/

FIORI TOOLS

לאחרונה יצא גם כלי חזק מאור הנקרא FIORI TOOLS שהוא APPLICATION GENERATOR   שמרחיב את מה שהוקם על ידי FIORI ELEMENTS הבסיסי עם כלים יעודיים ותבניות של UI5.

הוא נועד למפתחי UI5  (נראה שקיים גם עבור ECC ב RAP ודרך הSAP Business Application Studio )

https://blogs.sap.com/2020/06/22/sap-fiori-tools-is-generally-available.-increase-the-efficiency-of-developing-sap-fiori-elements-apps/

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

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

S4HANA Extensibility

בנוסף ליכולות של FIORI ELEMENTS במערכות S4HANA ישנן שתי צורות של הרחבות יישומים קיימים:

  1. Side-By-Side Extendibility with SCP – ישנן אפשרויות רבות להרחבה על ידי התחברות לענן של סאפ – ה SCP, SAP CLOUD PLATFORM. הן מיועדות גם ל S4HANA CLOUD אבל גם ל S4 on Premise על ידי התחברות ופיתוח ההרחבות ב SCP. לא נרחיב על כך כאן.
  2. In-APP Extensibility – מיועד בעיקר ל S4 on Premise. יש כאן כמה רמות של אפשרויות הרחבה:

UI Adaptation at Runtime –  כבר הוסבר קודם

מעבר לכך ניתן גם

להוסיף שדות – CUSTOM FIELDS

להוסיף טפסים, VIEWS, ושאילתות – CUSTOM Analytics/Forms

להוסיף לוגיקה עסקית – Custom Business Logic

להוסיף אוביקטים וטבלאות – Custom Business Objects

לכל אלה ניתן לקרא בקישורים הבאים:

זה ה WIKI הראשי לכל נושאי ההרחבות:

https://wiki.scn.sap.com/wiki/display/Fiori/Extensibility

https://help.sap.com/viewer/1e30a6dbe1084049b914baf8f0348bbb/1809.latest/en-US/3ccb50e724b045508fea8b2cf1774b2b.html

https://blogs.sap.com/2020/02/01/adding-field-in-standard-fiori-apps-of-s-4hana-with-custom-fields-and-logic/

https://blogs.sap.com/2018/01/10/leading-s4hana-ux-how-to-extend-a-sap-fiori-app-in-sap-s4hana/

https://blogs.sap.com/2020/05/12/sap-s4-hana-extensibilty/

זהו מדריך על איך לאתר את סוגי ההרחבות בכל יישום FIORI

https://ga.support.sap.com/dtp/viewer/index.html – /tree/1910/actions/24709:34441

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

בברכה,

עודד דגן

SOLMAN4S4

SOLMAN for S4 Conversion

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

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

CCLM –  Custom Code Lifecycle Management

זהו המודול העוסק ברישום וניהול פיתוחי הלקוח. כפי שפירטתי ב S4 Assessment המאמץ הרב שיושקע בתיקון קוד הלקוח הקיים לגירסת S4HANA צריך להתמקד רק בקוד שהארגון באמת משתמש בו בפועל. כדי לבצע את הניתוח הזה (Customer Code Analysis) ישנן שתי אפשרויות:

1. ליישם לפחות את מודול ה UPL/ SCMON מתוך CCLM   כאשר תוכנית ה ATC הממליצה ומאתרת את השינויים קוראת ישירות מתוך ה UPL ומסננת את הפיתוחים המיותרים. לפי המלצת סאפ יש לצבור לפחות 13 חודשים של נתוני  שימוש בקוד הכוללים מעבר שנה פיננסית. לכן כדאי מאוד להתחיל בזאת בהקדם והרבה לפני הפרויקט.

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

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

עץ תהליכים, תיעוד

מאחר ורוב התהליכים הפיננסיים עוברים שינוי משמעותי במהלך פרויקט ה S4HANA יש לתעד את התהליכים החדשים, את אפיוני הפיתוחים המותאמים והחדשים וכל הכרוך בכך. המקום המתאים לכך הוא בעץ התהליכים של SOLMAN 7.2 במודול ה Process Management – Solution Documentation.

ניתן גם להיעזר ביישום של תהליכי S4HANA החדשים עם תהליכי ה Best Practice של S4HANA  שניתן להוריד ל SOLMAN והכוללים תרשימי תהליך, הסברים, תיעוד קיסטום ותסריטי בדיקה.

wiki.scn.sap.com/wiki/display/SM/SAP+Solution+Manager+WIKI+-+Process+Management

DVM – Data Volume Management

מודול תשתיתי זה מספק ניתוח מפורט של גודל הקבצים והתהליכים ב ECC/ CRM ואת האפשרויות הטכניות השונות לצמצם את נפח הנתונים  וגם התיחסות לטבלאות שהם Obsolete. כידוע הכלי העיקרי הוא לנהל נפחים גדולים עם הארכוב – Archiving, אך לא רק. צמצום כזה שינוהל כפרויקט מקדים ל מעבר ל S4HANA ישפיע משמעתית על ה Sizing של החומרה הנדרשת ועל עלותה.

בתחום זה ישנם גם המלצות לגבי Data Aging (למשל לגבי נתוני GDPR הפיננסיים) והאפשרויות ליישם טכנולוגיה זו ב HANA ולחסוך במקום בזכרון.

wiki.scn.sap.com/wiki/display/TechOps/Data+Volume+Management

Focus Areas pre S/4 HANA Conversion

https://launchpad.support.sap.com/#/notes/2818267

BPMON – Business Process Management

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

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

מודולים שניתן ליישם לקראת הפרויקט עצמו:

CBTA

מאחר וצפויים בין 5 ל 8 סבבים של שדרוג ל S4HANA  על מערכת ה SANDBOX , DEV , QA + PROD יהיו הרבה מאוד בדיקות תהליכיות. רובן בדיקות חוזרות. לפיכך בדיקות אוטומטיות (מוקלטות) יכולות להוזיל מאוד מאמץ זה במיוחד לארגונים שאין להם צוות QA מיוחד. זוהי גם אחת מהמסקנות העיקריות של ארגונים בחו"ל שבצעו את ההעברה.

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

TEST SUITE

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

CHARM  – RETROFIT

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

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

Retrofit Support for Migration to SAP S/4HANA

ITSM

ITSM הוא מודול ניהול התקלות הפרויקטלי. מאחר וה ITSM מתממשק למודולים TEST SUITE ול CHARM ניתן לפתוח תקלה מתוך הבדיקה ולאחר מכן באמצעות Normal Change  להעביר  את השינוי לסביבה הרלוונטית. כדאי להיעזר ב ITSM ולו רק עבור הפרויקט.

 

קישורים כללים על תמיכת SOLMAN בפרויקט המעבר:

https://www.techedgegroup.com/blog/sap-s4-hana-conversion-solution-manager

SAP Solution Manager and SAP S/4HANA

4 חלקים של בלוג על המעבר:

blogs.sap.com/2018/02/07/manage-your-transition-to-sap-s4hana-with-solution-manager/

blogs.sap.com/2018/03/01/effective-preparation-for-migrating-to-sap-s4hana-with-solution-manager/

blogs.sap.com/2018/05/07/phase-3-of-migrating-to-s4hana-with-sap-solution-manager/

blogs.sap.com/2018/05/07/phase-4-of-sap-s4hana-migration-with-sap-solution-manager/

בברכה,

עודד דגן

Maintenance 2040

אתמול סאפ הכריזה על הארכת התמיכה הרגילה ב ECC עד סוף 2027 ועל אופציה לתמיכת extended עד סוף 2030. כמו כן הודיעה על תמיכה ב S4HANA  לפחות עד סוף 2040.

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

משמעויות

במקום התאריך של סוף 2025 למעבר מ ECC (וגם CRM 7.0 ו SRM 7.0) ל S4HANA (ראה S4 CONVERSION) סאפ הכירה בקושי של הארגונים לבצע מהלך כל כך גדול בפרק זמן הזה והאריכה את חלון הזמן בשנתיים נוספות עד סוף 2027.

בנוסף אם ארגון לא יספיק לעבור ב 7 שנים הקרובות הוא יוכל להאריך את חוזה התמיכה ל ECC במסגרת Extended Maintenance  בעלות נוספת של 2% לשנה. זאת עד סוף שנת 2030.

להלן ההודעות המקוריות של סאפ:

support.sap.com/en/release-upgrade-maintenance/maintenance-information/maintenance-strategy/s4hana-business-suite7

news.sap.com/2020/02/sap-s4hana-maintenance-2040-clarity-choice-sap-business-suite-7

news.sap.com/2020/02/interview-extending-maintenance-for-sap-s4hana

בברכה,

עודד דגן

S4 ASSESSMENT

בהמשך לפוסט הקודם על ה S4/HANA Conversion נרחיב על הערכת העלות של הפרויקט ושיטות הביצוע השונות האפשרויות כולל ההתקשרות לספקים.

 שיטת התקשרות לפרויקט

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

אם הפרויקט יהיה בסוף בעלות קבועה ככל שהערכת העלות תהיה יותר מדויקת – כך יוכלו לכתוב מכרזים יותר מדויקים לטובת יציאה לפרויקט FIXED.

הערכת עלות – Assessment

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

חומרה

אם הארגון עוד לא עבר ל HANA (מהדורה 2) אז יש להעריך את עלות החלפת החומרה בכל נוף מערכות הסאפ.

רשיונות תוכנה

המעבר לDB HANA משנה את מבנה רישיונות ה DB והמעבר ל S4/HANA יצריך שינוי המודולים שבשימוש ומבנה הרישיונות. צפויה גם כניסה לסוג רישיונות INDIRECT שמשנה לגמרי את התמונה.

תשתיות, BASIS

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

יישום

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

הסבות נתונים

כידוע מבנה הטבלאות הפיננסיות השתנה משמעותית (Simplification) וגם התהליכים. לכן ישנם תנאי קדם מאוד נוקשים להסבת הנתונים כולל טיוב נתונים פיננסיים, סגירת תקופות, Reconciliation וכו'. גם הקמת BP – Business Partners במקום לקוחות וספקים היא חלק מההסבה. סאפ מספקת כלי מרכזי לכך – ה Migration Cockpit אך ניתן להיעזר בכלים נוספים.

הסבת קוד לקוח

כאן יהיה מאמץ גדול להסב את הפיתוחים הקיימים של הארגון כדי שיתאימו לטבלאות ולתהליכים החדשים. ה Simplification List וריצת ה ACT אמנם מסייעים למקד את תשומת הלב למספר נושאים ידועים מראש אך אינו יכול להקיף את כל השינויים הנדרשים. המאמץ הוא לאתר את כל קטעי הקוד הרלוונטים להתאמה ולא לבצע אותה על קוד שאינו בשימוש בארגון. לפי הערכות סאפ בין 20% – 80% מהקוד הקיים אינו בשימוש, תלוי בוותק של הארגון בסאפ.

אז איך יודעים במה להתמקד? רק בעזרת המודולים המצביעים על כך במדויק ב Solution Manager. (רק ה SOLMAN צובר ומודד אילו PROGRAMS, INCLUDES, METHODS, CLASSES, FUNCTION GROUPS,FUNCTIONS,USER EXITS, משתמשים בפועל)

כל שיטה אחרת לוקה בחסר ומובילה להערכה מופרזת של Worst Case או להערכת חסר.  (יש חברה ידועה בחו"ל המציעה פתרון ל Customer Code Analysis המבוסס על ניתוח הטרנספורטים שעברו לייצור – ניתוח מגוחך שאינו מצביע כלל על מידת השימוש בקוד) ההבדל בהערכה יכול להיות מספר שנות אדם!

UI / UX – פיורי

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

בדיקות

מאחר ובפרויקט יהיו מספר סבבי בדיקות (5-8) והן יכללו כנראה את כל תהליכי הארגון בסאפ מאמץ הבדיקות יהיה משמעותי. לכן יש יתרון רב בשימוש ב Test Suite של הSOLMAN לבדיקות חוזרות. כמו כן יש גם צידוק ו ROI לשימוש ב CBTA להקלטה ושימוש בבדיקות אוטומטיות חוזרות.

ניהול השינוי, הדרכות

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

כלים ממוכנים

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

Readiness Check

Transformation Navigator

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

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

יתכן שבמהלך ביצוע ה Assessment כדאי להעמיד שרת  Sandbox לצורך הרצת בדיקות והערכות.

חלופות לביצוע ה Assessment

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

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

בברכה,

עודד דגן

S4 Conversion

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

סאפ הכריזה על EOL (End of Life) של מוצר הדגל שלה , ה ECC או SAP Business Suite שיהיה בסוף שנת 2025 ועל היורש S4HANA. פירושו המעשי הוא סיום הפצת תוספות ועדכונים פונקציונליים (למעשה ENHP8 היה האחרון) ומה שיותר חשוב סיום התמיכה. חרושת השמועות אומרת שהצהרה זו לא תחזיק מעמד ושהתאריך יוארך עד ל 2030 לפחות. כרגע הידיעות / שמועות האחרונות אומרות כי התמיכה תוארך אמנם עד ל 2030 אבל בצורה של Extended Maintenance (כמו שהיה עם 4.6C). המשמעות היא תוספת 2-3%  לדמי התמיכה.

ההערכות הפנימיות בסאפ (עפ"י מקורות זרים…) אומרים שכ 75% מהשוק יעבור למערכת S4HANA.

פרויקט המעבר ל S4HANA (S4 Conversion) איננו דומה לפרויקטי שדרוג שהיו בעבר למהדורה עיקרית, כמו ECC6 או לפרויקטי מעבר ל ENHP. הוא משמעותי וגדול יותר ועיקר ההשפעה היא על המערכת הפיננסית (שהיה חסר בשני הארגונים שעברו).

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

להלן מספר נושאי יסוד העוסקים בפרויקט.

אסטרטגיה ומטרות פרויקט המעבר

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

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

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

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

סוגי פרויקטים

GREENFIELD – פרויקט מעבר המבוסס על הקמת מערכת חדשה לגמרי, ללא שדרוג, הסבת נתוני העבר מ ECC ל S4HANA והטמעת התהליכים החדשים מאפס. הפרויקט דומה יותר לפרויקט הקמה ומתאים לארגון שמעונין להשתחרר מפיתוחי העבר, נתוני העבר ותהליכי העבר וגמיש מספיק כדי לאמץ תהליכים וכלים חדשניים.

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

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

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

הכנות ומספר שלבי הפרויקט

שלב אחד – ניתן לעבור ישירות מ ECC 6 ומכל ENHP ל S4HANA ובתנאי שהמערכת ב UNICODE. זה יחסוך מחזורי בדיקות נפרדים, ייצור עליה לאוויר אחת ובהיבט כולל – יהיה זול יותר משני שלבים. אך כאן מרכזים את כל הסיכונים והעלויות ביחד.

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

מועד ביצוע הפרויקט

בהנחה שרוצים לבצע את הפרויקט בארגון עד 2025 או 2030 – מתי כדאי לבצע, מוקדם א מאוחר?

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

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

https://www.sap.com/uk/products/s4hana-movement.html

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

הישארו בהאזנה! Stay Tuned!

עודד דגן

Decommissioning Cockpit

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

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

אז היכן אנו פוגשים את האובייקטים של קוד הישן?

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

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

סאפ מעריכה שבממוצע כ 65% מהקוד שנכתב בארגונים איננו בשימוש.

ה Decommissioning Cockpit נותן לנו מערכת ותהליך עבודה מובנים לטיפול בקוד הישן. הוא חלק ממודול ה CCLM- Custom Code Lifecycle Management  שב SOLMAN. (ראה CCLM)

איך יודעים איזה קוד מיושן או לא בשימוש ואיך מחליטים עליו? ה Decommissioning Cockpit מאפשר קיום מחזור חיים שלם לתהליך עם סטאטוסים כגון – Phased Out, Backed Up, Recommended for Decommissioning ,Deleted, Identified and Waiting לכל אובייקט שאותר. התהליך מתחלק ל 4 שלבים:

  1. ANALYSE – שלב האיתור והניתוח –

מריצים ניתוח שימושיות בתקופה האחרונה. הניתוח בנוי על המידע הנשמר בקוביה של מודול ה UPL / SCMON שכדאי להפעיל בכל מקרה ( (ראה CCLM) . סאפ ממליצה להריץ על תקופה של 1 חודשים כדי ללכוד מעבר שנה כספית בתוכה. יתכן שרוצים גם לדעת על אובייקטים שהשתמשו בהם פעם או פעמיים – למשל כאלה שהמיישם עצמו בדק בייצור אך הלקוח לא השתמש.

סוגי אובייקטים שמנותחים ובטיפול הם  TRAN, PROG ,METH , CLAS ,FUGR , FUNC ,DEVC. נכון שאילו אינם כל סוגי האובייקטים שיוצרים. אך הם מהווים את המסה הקריטית והפעילה של השימוש.

  1. IDENTIFY שלב הזיהוי – מחליטים על האובייקטים המתקבלים ברשימה האם ישנם אובייקטים שבוודאות לא צריך ועל השאר להמשיך בתהליך הבחינה.

  1. MONITOR שלב הניטור – בשלב הזה בעיקר מחכים כדי לוודא אם מתעורר שימוש לאובייקט ובמקביל מבררים את הצורך עם גורמים נוספים בביזנס וב IT. סאפ ממליצה שסך כל הזמן שעבר מתחילת שמירת מידע השימושיות ב UPL ועד סוף תקופת הניטור – לא יפחת מ 13 חודשים.
  2. DECOMMISSION שלב המחיקה – כאן מבצעים את המחיקה על ידי יצירת טרנספורט לגיבוי, העברתו למערכת הגיבוי, יצירת טרנספורט מחיקה ושחרורו. כמובן שהמערכת מבצעת את כל זה עבורך.

SAP Blacklist Monitor

במקרה שעדיין לא מחקנו את האובייקט אבל אנחנו רוצים למנוע בכל מחיר את השימוש בו – כי אולי הוא מסוכן או מכל סיבה אחרת – ניתן להיעזר בתוכנית הזו של "רשימה שחורה"

התוכנית מטפלת באובייקטים מסוג TRAN, FUNC, METH  PROG

מכינים רשימה שחורה דרך הכלים שפורטו קודם ומחליטים על שתי חלופות לחסימה:

  • התראה בלבד על מי משתמש (בטרנספורט) באובייקט מתוך הרשימה
  • DUMP וחסימת הניסיון להקים טרנספורט של אובייקט מתוך הרשימה עם שם המשתמש שניסה.

ניתן ללמוד עוד על ה Decommissioning Cockpit בקישורים הבאים:

https://wiki.scn.sap.com/wiki/display/SM/SAP+Solution+Manager+WIKI+-+Custom+Code+Management

Decommissioning

בהצלחה!

עודד

VALUEMAP

נסביר איך להכנס ולהיעזר בשירותים של ה VALUEMAP שהוא פורום סיוע וייעוץ של סאפ לנושאים "חמים" ומאוד מומלץ!

ה VALUEMAP בנוי על טכנולוגיית JAM שהיא סוג של רשת חברתית פנימית הכוללת מידע קבוע, פורומים ועוד. כל משתמש עם S-User יכול להרשם והכניסה היא דרך –

SAP Enterprise Support Value Maps

פעילות ב VALUEMAP

  1. מידע קבוע – המצגות , בלוגים, wiki, והסברים הם ברמה גבוהה מאוד – ורובם ייחודיים לכאן, כלומר לא ניתן להגיע אליהם ממקום אחר.
  2. פורומים – ישנם בכל VALUEMAP מספר פורומים לפי נושאים שונים וניתן לנהל בהם שאלות ותשובות. כל חברי הפורום יכולים לשאול ולענות וכך נהנים מניסיונם של עמיתים לנושא.
  3. ייעוץ –עיקר הסיוע הוא תשובתם המקצועית של מומחי סאפ עצמם בפורום. הם מחוייבים לענות על כל שאלה שלא נענתה עד כה בפורום!! מניסיוני, מקבלים את תשובת הקו הראשון מיידית או תוך שעות ספורות. כלומר ממומחי סיוע לאותו תחום. אם הם לא יודעים את התשובה או אם אתם דורשים תשובה יותר מעמיקה, מביאים לפורום את האנשים הכי מומחים בתחום בסאפ לענות. מכאן שתוך יום יומיים ניתן לקבל תשובה / ייעוץ של מנהל המוצר בסאפ בעצמו! זהו סיוע גדול בהרבה מהתמיכה ב OSS ובעל ערך רב.

רשימת הנושאים

ישנם הרבה נושאים הקשורים בעקיפין ל ECC ובעיקר נושאים חדשים :

Business Process Improvement – מטפל במודול ה Business Process Analytics שב Solution Manager העוסק בייעול התהליכים העיסקיים בתוך ה ECC .(ראה פוסט  BPMON)  בגדול הוא עוסק בניטור של החריגות מנהלים עסקיים (כמו למשל פריטי דרישה שלא מומשו או אושרו) ואיך ,לאורך הזמן, מפחיתים את החריגה.

SAP Analytics Solutions – מטפל בהקמה ותחזוקת SAP BO (Business Objects), Data Services, ונושאים חדשים יותר כגון AnalyticsCloud, S/4HANA embedded analytics , SAP Predictive Analytics.

Lifecycle Management – מטפל ברוב המודולים של ה Solution Manager ומחליף מספר פורומים קודמים של Valuemap שקדמו לו. פורום פעיל ויעיל מאוד!

Data Volume Management – מטפל במודול של ניטור גודל הקבצים לצורך החלטה אם להכנס ל Archiving. מיועד לאנשי BASIS.

Security – מטפל בנושאי בטיחות התשתיות והקשחות. מיועד לאנשי BASIS.

SAP S/4HANA On Premise – מטפל בפרויקט ההקמה, ההגירה והתחזוקה של S4. בעיקר סביב הכלים והמתודולוגיות של Activate    (ראה פוסט על ACTIVATE) פעיל מאוד!

SAP S/4HANA Cloud – כנ"ל לגבי S4 בענן.

Digital Innovation – מטפל בכל הנושאים ה"חמים" של סאפ : Fiori Cloud, mobile, IOT, Machine Learning, Blockchain.

SAP SuccessFactors – מטפל בהקמה ותחזוקת יישומי SF. (ראה פוסט HCM לאן?)

בקיצור – הרשמו תיהנו!

עודד

S/4HANA HCM upgrade

ב 09.01.18 סאפ הכריזה על מוצר חדש ל HCM) On Premise) שיעלה לאוויר בשנת 2023 ויאפשר להגר ממודול משאבי אנוש (HCM) הקיים על ECC למוצר החדש שיפעל במשולב עם S4HANA ועל אותה פלטפורמה. היום קיימים כ 14,000 לקוחות SAP HR) On Premise) ועד עכשיו מסלול ההגירה שלהם ל S4HANA כפי שסאפ קבעה היה אחד- לעבור להשתמש בפתרון הענן SF- SuccessFactors.

הגירה ל SF

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

מוצר ה HCM החדש

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

  • המוצר יהיה מבוסס ABAP ועל יישום ה HCM הקיים.
  • בסיס הנתונים יהיה HANA.
  • לא יכלול מודולים של E-Recruiting  ושל SAP Learning Solution
  • הוא יתקיים בצד של S4HANA וישתלב איתו.
  • יסופקו כלי הגירה מ HCM הקיים אל המוצר החדש.
  • המוצר ישוחרר בשנת 2023.
  • תהיה תוכנית להעברת רשיונות קיימים למוצר החדש.
  • תחזוקת המוצר מובטחת לפחות עד שנת 2030.

https://news.sap.com/hcm-on-premise-s4hana

משמעות ההכרזה

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

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

יש להכרזה זו גם השלכה על כל מבחר מוצרי הענן של סאפ כאשר כאן יש הודעה שמוצר ה on-premise הוא חשוב יותר וישאר עמנו לעוד הרבה זמן!

בברכה,

עודד

עוד כמה תגובות להכרזה :

https://www.theregister.co.uk/2018/01/09/sap_develops_new_onprem_hcm_solution/

https://diginomica.com/2018/01/09/sap-extends-hcm-premise-support-2030-smart-move-massive-error/

https://searchsap.techtarget.com/definition/SAP-S-4HANA-HCM

 

Reimplementation

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

סיבות למעבר ל S4

נוכח התאריך המתקרב והשיווק לטובת המעבר למערכת S4HANA רוב הארגונים כבר שוקלים וחושבים על מעבר זה. יש לכך כמה סיבות:

  • כדאיות שימושית – זו כמובן הסיבה העיקרית המקדמת את S4HANA. הטענה העיקרית היא פישוט, SIMPLIFICATION, של בסיס הנתונים, של תחזוקת המערכת ושל התהליכים העיסקיים. המערכת מהירה יותר בגלל ה HANA ובעלת פונקציונליות משופרת ברוב המקרים. כדאי לבחון את זה לעומק ורצוי עם גורמים בלתי תלויים.
  • כדאיות כספית – ישנה הוצאה לא גדולה לרכישת רשיונות S4HANA וכמו כן חומרה חדשה עם זכרון מוגדל שיכול לסחוב את ה HANA אך מאידך ישנם גם חסכונות בגודל בסיס הנתונים ובפישוט מורכבות ושכבות במערכת. על זה יש להוסיף את עלות הפרויקט שהיא ההוצאה הגדולה ביותר אך קשה מאוד להערכה.
  • תאריך יעד – התאריך המוכרז של סוף החיים של מערכת ה ECC (דצמבר 2024) מכניס אותנו למסלול החלטה של איתור המועד הכי כדאי לעבור למערכת החדשה. כי למרות הזמן הרב- לא רוצים להכנס ללחץ זמן כי ההתארגנות והפרויקט יערכו זמן רב. אבל האם התאריך הזה הוא ממשי? חל כרסום באמינות של התאריך בעיקר נוכח הקצב האיטי מאוד של מעבר לקוחות ECC ל S4HANA. (בארץ עוד אין ובחול מספר קטן ביותר). ישנן שמועות האומרות כי התאריך ידחה ל 2030. ישנם ארגונים שאין להם הרבה פיתוחים והם אומרים לעצמם שיוכלו לוותר על התמיכה של סאפ לאחר 2025 ולהשאר ב ECC. אך עדיין רוב הארגונים מתייחסים לתאריך ברצינות וחושבים על המעבר.

חלופות המעבר ל S4

לקוח חדש

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

לקוח קיים

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

  1. הקמת מערכת חדשה

מקימים מערכת S4HANA וונילה וחדשה לגמרי , בוחנים ומנתחים את התהליכים החדשים שהיא מציעה , מקסטמים, מבצעים פיתוחים חדשים שיכסו את רוב הפיתוחים והפנוקציונליות שהיו ב ECC ומבצעים הגירת נתונים כללית. זהו למעשה פרויקט הקמה חדש כאשר S4 היא מערכת ה ERP ו ה ECC היא מערכת ה LEGACY. כמו כל פרויקט ERP עדיף בשיטת BIG BANG  כי המעבר בשלבים כרוך בממשקי ביניים רבים, מסובכים ויקרים. זהו בעצם פרויקט REIMPLEMENTATION  שנפרט עליו בהמשך.

2.  הגירה מ system conversion – ECC

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

simplification list blog – מסביר איך להתיחס לרשימה ולעבוד איתה.

השינויים הכי גדולים וידועים הם איחוד הקבצים של מודול FI ו CO וביטול לקוחות וספקים ושימוש ב BP – Business Partners. מודול ה HCM אמנם נתמך אך לא יתפתח מאחר וה Success Factors הוא הפתרון הנתמך ל משאבי אנוש . וישנם עוד עשרות.

  1. קונסולידציה – Landscape Transformation

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

התאמת קוד הלקוח

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

ישנם כמה פעולות הכנה שיש לבצע המתוארים בבלוג הבא:

custom code adoption process blog

כדי לחדד יותר סאפ יצאו לאחרונה עם תוכנית ייעודית שנקראת Readiness Check :

2290622 – SAP Readiness Check for SAP S/4HANA

ניתן להריץ את התוכנית ב ECC או דרך SOLMAN וכאשר מסתכלים על תוצאות הריצה בהיבט של ה Custom Code, מקבלים ספירה של אובייקטי הפיתוח הקיימים והמלצות כלליות בלבד על איך לבצע Simplification. יש הבהרות על שינויים ב SYNTAX ובחוקיות הקוד אך הניתוח הפונקציונלי הוא באחריותינו.

להלן דוגמא לתוצאות:

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

REIMPLEMENTATION

כאן נכנס השיקול והכדאיות של יישום מחדש של תהליכים – ReImplementation.

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

הערה – לארגון עם תיעוד מסודר של הפיתוחים / אפיונים ועץ תהליכים מסודר יש יתרון מובהק בהערכת עלות היישום מחדש. סאפ ממליצה על שימוש מוגבר בסט הכלים שב Solution Manager  להערכת עלות המעבר ולניהול הפרויקט. החל מ 1.1.17 כל הפרויקטים שהתחילו בהובלת סאפ משתמשים ב SOLMAN 7.2 בעצמם.

בברכה,

עודד דגן

 

HCM לאן?

ארגונים המיישמים את מודול ה HCM בסאפ עומדים בפני פרשת דרכים – האם לעבור לגרסת הענן , Successfactors, או להשאר בגרסת ה ECC הוותיקה ולקוות לטוב? נרחיב על כך בהמשך.

HCM הינו אחד המודולים המרכזיים האחרונים שכתבה סאפ, הרבה לאחר צאת המודולים הפיננסיים והלוגיסטיים שהתבססו על טכנוליות מיינפריים, R2. כאשר יצא מודול ה HR הוא נחשב למבנה מודרני וגמיש הבנוי על ה INFOTYPES המפורסמים המאפשרים גמישות בהוספת שדות וסידור מסכים. בהמשך הוסיפו למודול יכולות רבות בתחומי ניהול הזמן , הדרכה, מבנה ארגוני, הטבות, חישוב שכר, ESS,MSS ועוד.

HR RENEWAL

בשנים האחרונות סאפ השקיעה הרבה ופיתחה שכבה נוספת של UI ושל יכולות נוספות למספר תת מודולים תחת הכותרת HR RENEWAL. הוא כולל בעיקר מסכים חדישים למשתמש בטכנולוגיית UI5 (לא FIORI!) , הרשאות גמישות ומראה צעיר ורענן. ישנם מסכים חדשים לתיק האישי, ESS, MSS, TIME ועוד. מהתרשמות שלי מדובר במהפכה של ממש המביאה למודול אפשרויות רבות אך בעיקר ממשק משתמש העונה לתהליכי משאבי אנוש האמיתיים. הוא מיושם בהצלחה בארץ בצה"ל ובחברת צים.

HRR

בינואר השנה סאפ יצאה עם 9 יישומי FIORI ל HR שאמורים להתמזג עם ה HR RENEWAL. כנראה שזה הכיוון.

למי שרוצה להתחיל ליישם , מומלץ להתקדם ל ENHP7  לפחות , רצוי ENHP8 הכוללים את גרסת RENEWAL 2 שהיא היחידה שאפשר לעבוד איתה.

https://wiki.scn.sap.com/wiki/display/ERPHCM/SAP+HR+Renewal+Overview

SUCCESSFACTORS

לפני 5 שנים סאפ רכשה את SUCCESSFACTORS שהיתה כבר אז חברה מצליחה ליישומי HR בענן (מתחרה של  WORKDAY). נכון להיום SF נחשבת ליישום ה HCM המוביל והעתידי של סאפ. כל גרסאות הענן של סאפ עובדים על SF כולל S4HANA הכולל בתוכו את SF כפתרון המוביל למשאבי אנוש. כבר עכשיו סאפ מכריזה שלאחר שנת 2025, סיום התחזוקה הצפוי ל ECC, סאפ לא תתחזק יותר את HCM הקיים. במונחי S4HANA לא תהיה גרסת SIMPLE עבור HCM.

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

SF

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

SuccessFactors – Useful Resources and Documents

היתרונות העיקריים שסאפ מציינת של SF ויישום בענן

  • פחות תחזוקה מצד הלקוח – חומרה ותוכנה בענן!
  • העדכונים ושדרוג התוכנה מבוצעים מרכזית ולכן מחזור החידושים איננו תלוי ביכולת הלקוח.
  • מראה חדיש ומודרני. מתקשר לכל המדיה הדיגיטלית החדישה.
  • קיים ממשק טוב למערכת ה ECC. בגלל שאין הרבה קשר בין הHCM לבין שאר המודולים ב ECC הוא מועמד מצוין לחיות בענן.

חסרונות

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

4 Q

המסקנה המתבקשת היא שככל שחברה תהיה מוכנה להתיישר עם התוכנה בענן (VANILLA) ולעבוד ללא פיתוחים היא תתאים יותר למודל התוכנה בענן, ככל שיש לה יותר פיתוחים והתאמות – המודל פחות מתאים.

מה צופן העתיד?

ארגונים חדשים לסאפ או ללא HR בכלל יישמו כמובן SF.

צופים שארגונים ינקטו אסטרטגיה של יישום היברידי  הכולל רכיבי מערכת ECC בשילוב עם רכיבים מתקדמים של SF. הרכיבים בהם נדרשת פונקציונליות מורכבת והארגונים מושקעים רבות  בהתאמת המערכת לצרכי הלקוח יישארו עם מערכת ECC. אולם ברכיבים בהם עדיין הארגון לא יישם יבחרו רכיבים של ה SF .
הרכיבים האטרקטיביים של SF הם בתחום של Talent solutions שארגונים מתעניינים בהם וכמו כן הערכת עובדים וניהול יעדים, ניהול גיוס, ניהול תגמולים , ניהול למידה.
בנושא של ניהול למידה למרות שקיימת נדידה ממערכת LS0 הקיימת לפתרונות ב CLOUD – SF , עדיין קיימים לקוחות רבים בעולם שהשקיעו רבות בהתאמת מערכת LSO on-premise ואין להם כוונה לעבור לענן.
בכנס ASUG ב2015 התארגן לובי רציני של לקוחות ושותפים עסקיים והצליח לגרום לסאפ להשקיע בפתוח יכולות נוספות ושיפורים במערכת הקיימת וגם תוספות פונקציונליות של LSO ב HR RENEWAL.

ככל שנתקרב לשנת 2025 נדע כמה ארגונים נשארים במודל ה On Premise HCM  וכמה באמת עברו ל SF בענן. ישנם גופים שאין להם בכלל אופציות בענן חיצוני כגון גופים בטחוניים. נזכור שבשל הרגישות הגבוהה של המידע של משאבי אנוש, צנעת הפרט וכמו כן חשאיות מידע השכר וההטבות- ארגונים רבים חוששים מאוד ממעבר זה.

יתכנו שני סוגים של תרחישים:

  • סאפ תחזור בה ותיתן תמיכה מסוימת ב ECC On Premise. יתכן שמודל התמחור ישתנה.
  • אם סאפ תצא משוק זה יבואו אחרים במקומה כדי לתת תחזוקה ל ECC HCM. חברות כמו RIMINI STREET וגם חברות האינטגרציה הגדולות ירצו לתת תמיכה כי הרי הן הנפגעות העיקריות מהמעבר לענן.

יהיה מעניין לעקוב ולראות לאן כל זה יתפתח.

בברכה,

עודד דגן

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

עוד קישורים מעניינים :

בלוג על העתיד המקצועי של מיישמים HCM:

(Future of SAP and SuccessFactors Consulting 2016 – SAP HCM (Part 1

Where’s my SAP HR? SuccessFactors and the Cloud HR Roadmap