FIORI EXTENSIONS

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

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

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 ללא קידוד. מן הראוי שמיישמים ומקבלי ההחלטות ילמדו אותן כדי להוריד זמנים ועלויות פיתוח.

בברכה,

עודד דגן

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!

עודד דגן

SOLMAN 7.2

בקרוב משתחררת מהדורה ראשית 7.2 של ה Solution Manager. היא נמצאת מינואר 2016 בבדיקות Ramp-Up ומשתחררת לציבור הרחב בקיץ 2016 (GA-Q3). סאפ תפסיק לתמוך ב SOLMAN 7.1  בסוף 2017 כלומר יש חלון זמן של שנה וחצי לעבור למהדורה זו.

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

שינויים ושיפורים ב ALM ובחלקים היישומיים

• שיפור ניכר בממשק למשתמש: במקום שיטת ה workcenters יש מעבר גדול ל FIORI , ל UI5 ול WEBDYNPRO.
• שיפור ניכר בעץ התהליכים. במקום SOLAR01+02 התשתית משתנה לשיטה של ספריות תהליכים הנבנים על EXECUTABLES הנמצאים בשימוש. הרחבה בפוסטים הבאים.
• ניתן להוסיף רמות בעץ התהליכים.
• פישוט של הקשר לנוף הטכני. איחוד של יישויות ה SOLUTION ,LOGICAL COMPONENTS ופרויקטים.
• ניהול בדיקות – מעבר מוחלט ל WEB DYNPRO ושיפורים הקשורים לתהליכים. דוחות חדשים.
• כלי משוכלל לציור תהליכים עסקיים מבוססי תהליכי SOLMAN מבוסס על שיטת BPMN.
• מודול חדש לניהול גרסאות היישום – Release Management המשולב במודול הפרויקטים.
• שיפורים וחידושים אופציונליים ב ITSM וב CHARM.
• ניהול פרויקטים – ה IT-PPM מקבל גיבוי ושילוב מוחלט במערכת. ניתן לנהל את כל הפרויקטים של ה IT עם קשר הדוק ל CHARM, לתקציב, לזמנים ולתיעוד.
• תומך במתודולוגיית הפרויקטים , ACTIVATE, עבור S4HANA. כולל BEST PRACTICES.

שינויים ושיפורים ב Operations ותמיכה הטכנית

• תומך בכל מגוון פתרונות הענן של סאפ, Ariba ,Successfactors וכו'.
• ניהול ה LANDSCAPE – יהיה דרך ה Maintenance Planner שמחליף את ה MOPZ ומומלץ ליישם אותו כבר ב SOLMAN1!!
• BPMON- שיפור ניכר עקב השינויים בתהליכים העסקיים. ניתן בקלות ליישם כבר שם.
• איחוד כל יישומי הניטור וההתרעות.
• שילוב ניהול ה ג'ובים לתהליכים החדשים.
• DASHBOARDS– כלי חדש ליצירה, תחזוקה והצגה של כולם.
• יכול לרוץ על פלטפורמת HANA – ללא צורך ברשיונות ANYDB.
• תומך בכל פתרונות HANA במערכות הנתמכות

 

מעבר ל 7.2- התקנה או שדרוג?

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

להלן שני קישורים למידע על 7.2:

http://sapsupport.info/experience/it-operational-excellence/sap-solution-manager-7-2/

http://scn.sap.com/community/it-management/alm/blog/2015/12/03/solution-manager-update–three-reasons-for-going-to-solman-72

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

בברכה,

עודד

 

 

 

 

 

NEW-OSS

למי שעוד לא שם לב – יוצאת בימים אלה מהדורה חדשה של אתר התמיכה, OSS , בשם  ONE SUPPORT LAUNCHPAD. הוא חדיש, הוא נחמד והוא תומך רק ב IE10 ומעלה!

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

כדי לנסות אותו לוחצים על האזור הזה בכניסה הרגילה OSS

 

ניתן לקרא את ה FAQ וכדי להכנס ללחוץ על

הממשק למשתמש בנוי באמצעות טכנולוגיית Fiori Launchpad . מאוד נח ואינטואיטיבי.

לו"ז

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

 

תמיכה בדפדפנים

ממשק ה ONE תומך ב CHROME וב Internet Explorer ממהדורה 10 ומעלה.

כלומר איננו תומך ב IE8 – IE9! תתפלאו אבל אני מכיר כמה ארגונים בארץ שנמצאים עדיין ב IE8!

לכן הם צריכים לשדרג את ה IE או לעבור לCHROME.

על הפרטים בוודאי תקראו ותסתדרו.

בהצלחה!

עודד

 

S4HANA

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

ההכרזה על S4HANA

S4HANA היא חבילת ה ERP החדשה של סאפ המכילה את כל התכולה של ECC הקיים – על הפלטפורמה ובסיס הנתונים של HANA. הקוד והתוכנה הם אותה תוכנה כמו ה ECC מלבד המודולים הפיננסיים שהוחלפו לקוד המיוחד לHANA ונקראים : SIMPLE FINANCE. במשך השנים הקרובות סאפ מתכוונת להחליף את כל יתר הקוד המקורי  ( כ 400 מליון שורות קוד!) לקוד מיוחד ל HANA. כנראה שכבר השנה תשוחרר גירסה ל SIMPLE LOGISTICS.

בסיס הנתונים החדש הוא כאמור HANA בלבד (אני מניח שכולם כבר יודעים מה זה) וזה אומר שכל בסיסי הנתונים הקיימים של ECC לא יתמכו יותר ! כלומר סוף לכל רשיונות האורקל ומיקורוסופט סרבר וכו'. אחת הסיבות המרכזיות למהלך הזה הוא לתת מכה גדולה לאורקל בדמות ירידה ברשיונות.

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

תמיכה וחידושים – ב 2014 סאפ הכריזה על המשך התמיכה ב SAP BUSINESS SUITE עד לשנת 2025. כלומר מסלול של תיקוני בגים (SP + NOTES) ומסלול פונקציונלי – ENHP. אך לפי ההכרזה הזו – סאפ עכשיו תספק את החידושים רק למסלול של S4HANA. ל ECC הקיים ינתנו פתרונות לשינויי רגולציה – אך לא יותר. להלן הציטוט:

SAP will certainly provide security and regulatory fixes for what they call AnyDB customers (Oracle/Microsoft/IBM) but innovation will be focused on HANA.

This already happened in the SAP BW data warehouse software: in the latest SAP BW 7.4 release, almost all the innovations for customers are only available for the HANA DB.

אבל האם זה יחזיק מים? מה עם ההכרזות הקודמות של כל הקוד הקיים ב ECC יעבור לממשק FIORI? מה עם הלחץ והצורך של הארגונים הקיימים שלא כל כך מהר עוברים ל S4HANA ?

HANA בענן

ניתן לרכוש ולעבוד עם S4HANA  לגמרי בענן או בהתקנה מקומית  ( On Premise ) . זה גם אומר שסאפ זונחת את שרשרת המוצרים הקיימים שלה של ECC בענן – מוצרי ByDesign. אבל ישנם ארגונים שלא יהיו בענן לעולם (כמו בתי חולים וארגוני בטחון) ויש גם Industry Solutions כמו IS-H שלא יהיו בענן לעולם. כך שחייב להיות פתרון מקומי.

SIMPLE

סאפ טוענת לעבודה הרבה יותר פשוטה באמצעות המערכת החדשה. אך הכוונה האמיתית, כפי שמסביר זאת יפה מייסד סאפ HASSO PLATTNER היא ירידה מסיבית במספר הטבלאות הנדרשות בבסיס הנתונים. ב SIMPLE FINANCE  למשל יש עשירית ממספר הטבלאות שיש ב ECC. זאת כי בבסיס נתונים יחסי ,כמו אורקל, צריך להתחשב ביעילות ומהירות הגישה לטבלה ולכן גם  צריך לפזר את המידע בין מספר טבלאות, לנרמל ולתחזק מפתחות וכו'. בגלל המהירות העצומה של HANA והמבנה של עמודות בתוך הזכרון – הורדה מסיבית של מספר הטבלאות כנראה מפשטת מאוד את התוכנה עצמה.

אך האם זה מפשט את היישום ואת תהליך העבודה בפיננסים – לא !

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

אך ההכרזה שזה מפשט לארגון את היישום – איננה במקומה!

מעבר ל S4HANA

המעבר של לקוחות ECC ל S4HANA הוא למעשה הגירה ולא שדרוג. זה אומר שכל הנתונים הקיימים יעברו לבסיס נתונים החדש. כמו כן כל התוכנה שקודדה אצל הלקוח (הפיתוחים, כן הפיתוחים!) תעבור למערכת ולקוד החדש. סאפ מספקת כלים להגירה והלקוח מבצע. עבור הפיננסים הקוד יותאם למהדורה החדשה ועבור כל היתר הקוד אמור לעבור בלי הרבה בעיות. סאפ איננה מתחייבת להעביר REPAIRS / MODIFICATIONS !!!!! מעניין יהיה לראות את הפרויקטים הראשונים של ההגירה ומי מוביל אותן. כמובן שללקוחות חדשים סאפ מציעה בעיקר S4HANA .

שילוב מוצרים

עדיין לא ברורה מידת השילוב עם מוצרי סאפ הלווינים: CRM,SRM, APO, GRC וכו' וכמו כן עם הרכישות האחרונות שלה בענן: ARIBA, SUCCES FACTORS וכו'. האם ישולבו במוצר או רק יקושרו?

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

בברכה,

עודד

 

UX – ממשק למשתמש 1

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

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

האתר המרכזי למושגי UX הוא SAP UX EXPLORER .

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

 

כל היישמוים החדשים יוצאים עם UX מהמשפחות החדשות (NEW) ובראש וראשונה עם ממשק מותאם MOBILE. בכל יישום. בנוסף מתקיים פרויקט של ייעול וחידוש המסכים והיישומים הקיימים. הפרויקט הזה נקרא RENEW ובכל ENHP משתחררים מספר מסכי RENEW המעוצבים מחדש בטכנולוגיות שונות. מעבר לכך סאפ מספקת כלים ללקוחות (ENABLE) כדי שיוכלו לשפר את המסכים החשובים להם ולהתאים אותם לצרכים שלהם.

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

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

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

 

 

 

שכבת ה UI Technologies מייצגת את משפחות כלי הפיתוח הקיימים.

שכבת ה UI Tools מייצגת את כלי התיווך העיצוב והסינון שבתווך. (כלי ה ENABLE).

שכבת ה UI Clients מייצגת את כלי החשיפה וה GUI שבתחנת הקצה.

שכבת ה UI Technologies

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

DYNPRO – הוא ה ABAP DYNPRO הטוב והוותיק. נתמך על ידי ה SAPGUI, NWBC.

ABAP WEB DYNPRO – מהווה בן ממשיך ל ABAP אך גם ל JAVA WEB DYNPRO. כאשר סאפ עודדה את השימוש בפורטל עם יישומי ה JAVA החדישים יותר התחיל השימוש ב JAVA WEB DYNPRO. אך די מהר הגיעו למסקנה שצריך כלי ליישומי WEB עבור קהיליית מפתחי הABAP הקיימת. היום ה WDA הוא הכלי הסטנדרטי של סאפ ליישומי WEB וניתן לחשוף ולהשתמש ביישום גם בפורטל וגם ב NWBC. מפתחי חברת צים (ועוד רבים אחרים) משתמשים בכלי הזה בהצלחה רבה.

SAPUI5 – הוא סביבת פיתוח בכלי HTML5 , קוד פתוח, וגם הוא משתלב בפורטל וגם ב NWBC.

מפתחי קוקה קולה בישראל משתמשים בכלי הזה בהצלחה רבה. סאפ עצמה משתמשת היום בכלים הללו בהרבה מחידושי היישומים ב HR, MM ואחרים. בנוסף כל יישומי FIORI בנויים על בסיס SAPUI5. ישנם קווים מנחים לפיתוח עצמי דומה ל FIORI.

OPENUI5

UI Development Toolkit for HTML5 Developer Center

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

• RESPONSIVE –העיצוב משתנה בהתאם למכשיר עליו מוצג היישום. כלומר המראה התאים גם למכשירים ניידים, MOBILE, גם לטאבלט וגם למחשב PC. (כמו הבלוג הזה !!!)
• המראה הוא נקי וקליל.
• Role base – לכל פונקציה ארגונית תהיה אפליקציה שמתאימה לדרישות שלה – למשל למנהל יותאמו אפליקציות מתאימות לעומת לעובד שיעבוד עם אפליקציות אחרות
• 1:1:3 מקסימום 3 מסכים לביצוע E2E של התהליך העסקי.

SAP Fiori User Experience

Simplify the user experience on any device – with SAP Fiori UX

המשך יבוא בפרק הבא בעוד כשבועיים.

עודד דגן