שלום!
גם את הפוסט הזה פירסמתי באנגלית באתר הבלוגים של סאפ :
Lite Task Management for SAP Projects with CHARM
מדובר כאן על ניהול משימות אפיון ופיתוה מפורטות מקושרות למסמכי שינוי ב CHARM. זה יכול לסייע רבות לארגונים שכבר יש להם CHARM או שעומדים לפני פרויקט פיתוח חדש.
בהצלחה!
עודד
שלום!
הפעם הפוסט מופיע בשני חלקים באתר הבלוגים של סאפ באנגלית והנושא – איך להקים עץ תהליכים ב SOLMAN.
חלק 1 – איך לתכנן ולבנות את התהליכים העסקיים בעץ.
blogs.sap.com/2020/04/09/how-to-design-and-build-the-solution-manager-process-tree-part-1
חלק 2 – איך לייבא תכנון העץ מאקסל ל SOLMAN.
blogs.sap.com/2020/04/11/how-to-design-and-build-the-solution-manager-process-tree-part-2
בברכה,
עודד
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/
בברכה,
עודד דגן
בהמשך לפוסט הקודם על ה 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 להקלטה ושימוש בבדיקות אוטומטיות חוזרות.
ניהול השינוי, הדרכות
כדאי לתקצב פעילות ניהול השינוי לארגון ויש לתכנן ולהיערך להדרכות נרחבות למשתמשים לשינויים התהליכיים הצפויים.
כלים ממוכנים
ישנם מספר כלים של סאפ היכולים לתת תובנות חלקיות לתכנון כגון
יש לסאפ גם מספר תוכניות שירות במסגרת ההעברה שניתן להפעיל כדי לגלות ולטייב נתונים.
חברות בחו"ל פיתחו כלים נוספים לסייע להעברה, חלקם טובים וחלקם מיותרים (רובם נמצאים כבר ברשות הארגון ב SOLMAN ובחינם). צריכים מאוד להיזהר מהבטחות שווא עם הכלים האלה.
יתכן שבמהלך ביצוע ה Assessment כדאי להעמיד שרת Sandbox לצורך הרצת בדיקות והערכות.
חלופות לביצוע ה Assessment
בפוסט הבא ארחיב על כל הפעילויות שניתן לבצע ב SOLMAN כדי להתכונן לפרויקט המעבר ולסייע לו.
בברכה,
עודד דגן
Focused Build הוא הכלי לניהול פרויקטי IT העדכני והמוביל של סאפ. הוא מבוסס על Solution Manager 7.2 ומהווה פתרון מושלם, אינטגרטיבי ומוכן לעבודה מיידית ,כלומר לא נדרשת עבודת התאמה או קיסטום נוספת. נדרש רק ללמוד אותו היטב, להתאים את נהלי הפרויקט לכלי, להטמיע ולתמוך במהלך הפרויקט. הוא מותקן ב SOLMAN כ ADD-ON במקביל לטרנזקציות הקיימות של ITSM + CHARM ואיננו מפריע להן.
החדשות הטובות הן שהחל מ Q4 של 2019 הוא ניתן בחינם (ועד אז בהנחות גדולות לפי רבעונים). עד היום הרישיונות עלו 250 יורו לאחד. למי שעומד להתחיל פרויקט גדול מומלץ להתעניין!
ה FB איננו מתאים לניהול פעילות שוטפת – רק לפרויקט אך ישנן בתוכו גם תוספות ייחודיות המיועדות לשוטף – STANDALONE EXTENSIONS (על כך בפעם אחרת).
ה FB מבוסס על מתודולוגית ACTIVATE של סאפ (ראה ACTIVATE שלי ) ותומך בשלבים של ACTIVATE.
ה FB מחולק לשלבים עם שמות הלקוחים מתחום הפרויקטים האג'יליים:
צריך להדגיש שהמתודולוגיה הזו איננה אג'ילית לגמרי אלא בנויה על BLUEPRINT ברור עם חבילות עבודה, מצגות אמצע ובדיקות קבלה לכל חבילה. (ראה פרויקט אג'ילי או מסורתי?). למעשה היא דומה מאוד לשיטות העבודה הנהוגות בישראל.
.
הכלים של ניהול הפרויקט מבוססים על ה ITPPM (ראה EPM-PPM) אך ב SP02 של ה BP סאפ פיתחו מסכים מיוחדים ומאוד ידידותיים מבוססי UI5 לניהול הגאנט וחבילות העבודה שמחליפים את מסכי ה ITPPM הרגילים.
תוספות ייחודיות לניהול הפרויקט ב FB מעבר ל SOLMAN הרגיל
במקביל לניהול הזמנים שב WAVE וה SPRINT, היישויות הביצועיות של הפרויקט הן:
ה WORK ITEM וה WORK PACKAGE מתעדים ומבצעים את העבודה בפועל כאשר הם מקושרים לגאנט הפרויקט באמצעות ה SPRINT וה WAVE. ישנם מסכים ואפליצקציות UI5 מיוחדים המטפלים בהם , מעבר ל UI של ה CRM.
תוספות ייחודיות לבדיקות ב FB מעבר ל SOLMAN הרגיל
קישורים ל Focused Build:
https://wiki.scn.sap.com/wiki/display/SM/WIKI+Focused+Build
Focused Build in SAP Solution Manager – Insights from an agile SAP S/4HANA project
בהצלחה!
עודד
שלום !
נעדכן הפעם על כמה שינויים מהותיים בהיערכות המערכות של סאפ מול הארגון שצריך להתחיל להיערך לקראתם:
סאפ הודיעה לאחרונה שבתאריך 1.1.2020 היא תשנה לגמרי את התשתיות המפעילות את התמיכה בלקוחות :
ה SAP Support Backbone שכוללות את השירותים :
Maintenance Planner – להורדת עדכוני תוכנה ועדכון סאפ במצב המערכות בארגון.
SAP Earlywatch Alert– שירות בדיקות המערכות לפני ואחרי שדרוגים ושינויים.
Maintenance Certificate Distribution – שירות קבלת הרשיונות למערכות מסאפ.
https://blogs.sap.com/2018/07/05/call-for-action-sap-support-backbone-update/
https://support.sap.com/en/alm/solution-manager/sap-support-backbone-update.html
השירותים הללו יתמכו מאותו תאריך רק עם מערכת Solution Manager 7.2 הנמצאת לפחות ב SP07 .
כלומר למי שרוצה לשמור על התמיכה של סאפ ישנן 3 אפשרויות:
א. לשדרג את מערכת ה Solution Manager שלו למהדורה 7.2 לפחות SP07 עד ה 31.12.2019.
ב. להקים מערכת Solution Manager מאפס במהדורה 7.2 לפחות SP07 במקום לשדרג. זה מתאים לארגונים שלא השקיעו ולא נהנים מהיישומים של SOLMAN ויכולים להתקין מאפס עד ה 31.12.2019.
ג. לוותר לגמרי על SOLMAN ולעבוד מול סאפ רק עם השירותים המקוונים שלה. זו אפשרות עבור ארגונים קטנים עם מעט מערכות סאפ, יציבים, המשתמשים רק בשירותי סאפ הבסיסיים – Service & Support Delivery.
המשמעות – ניתן להשתמש בפונקציונליות ובמודולים השונים של SOLMAN עבור כל סוגי המשתמשים בארגון ועבור כולם – בחינם! היתרון והדוגמא הבולטת ביותר לכך היא האפשרות להשתמש במודול ה ITSM שהוא HELP DESK כלל ארגוני – עבור כל המשתמשים בארגון ולא רק של מערכות ה סאפ. ה ITSM הינו מודול מבוסס CRM והוא עשיר מאוד בפונקציונליות , יציב, עובד במספר ארגונים בישראל וכדאי לכל ארגון להתעניין בו.
בברכה,
עודד
נרחיב הפעם על עולם הניטור בסאפ עם דגש על הניטור הטכני. SOLMAN מרכזת וקשורה לכל נוף המערכות ולכן מהווה את ה HUB המרכזי ובה נמצאים כל כלי הניטור. קיימים גם ניטורים יישומיים (Business Process Operations ) אותם סקרנו בפוסטים קודמים על BPMON, JOBS .
כלי הניטור הטכניים (System & Application Operations) כוללים את
דף ה WIKI המרכז את כל נושאי ה Technical Operations:
https://wiki.scn.sap.com/wiki/display/TechOps/
MAI– Monitoring & Alerting Infrastructure
MAI היא התשתית החדשה של הניטורים למערכות סאפ והחליפה את ה CCMS המיושנת שמופעלת על כל מערכת בנפרד. MAI מספקת שורה סטנדרטית של סוכנים בכל מערכת, agents, המספקים מידע ובעיקר שורה של מטריקות, תבניות ומדדים סטנדרטיים הקובעים כיצד יראו תוצאות הניטור בצורה אחידה וברורה. היתרון העיקרי מול CCMS היא השליטה המלאה על כמות ואיכות ההתראות שנקבל כדי למנוע הצפה בהתראות מיותרות.
wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=464701227
מטרות הניטור
System Monitoring
מודול זה הוא הבסיסי ביותר ומשרת את צוות ה BASIS בעיקר. היתרון העיקרי הוא שסאפ מספקת כאן אלפי התראות OUT OF THE BOX בצורה של תבניות, סטנדרטיים לגמרי הבנויים לפי ההמלצות והנסיון של סאפ ויכולים לפעול מיידית. הצוות נדרש להכנס לכל אחד, להבין אותו לעומק ולהתאים אותו לתנאים הספציפיים של הארגון. ניתן גם להקים התראות ומטריקות חדשות לגמרי אך לרוב אין צורך. המודול מתלבש ישירות על תשתית ה LMDB + SLD הקיימות כבר ששם הגדירו את המערכות המנוהלות.
בתצוגה זו יש ריכוז ההתראות בקוביות למעלה, פריסה לפי סוג ולפי מערכת וDRILLDOWN בכל מקום.
,
בתצוגה זו מוצגים כל סוגי ההתראות למערכת מסויימת בצורה הירארכית. בנוסף ל DRILLDOWN בכל מקום ניתן להציג את ההתראות לאורך זמן וללמוד על ההתנהגות בתקופה.
PI Monitoring
רוב הארגונים המפעילים PI (או PO כפי שהוא נקרא גם) מפעילים PI Monitoring כבר מתוך ה PI עצמו. כאן ה SOLMAN מתלבש על הניטור הקיים ומביא אותו אליו. היתרון הוא בצורה המשותפת, האחידה והברורה יחד עם כל יתר ההתראות וכן שני המודולים הבאים.
https://wiki.scn.sap.com/wiki/display/TechOps/Process+Integration+Monitoring
Message Monitoring
ניטור קצה לקצה של מסרים העוברים ב PI כולל מקורות ויעדים שאינם סאפ. נותן התראות על בעיות וניתוקים בעומק אחר מאשר הPI Monitoring כולל חיפוש בטקסט של המסרים עצמם. להלן דוגמא של מסך ניטור.
Interface Monitoring
מודול זה מכסה את ניטור כל הממשקים שאינם עוברים דרך ה PI מסוגים שונים כולל:
RFC, IDOCS, WEB SERVICES, ODATA, FILES, WF. גם הוא מספק תבניות מוכנות מראש למספר רב של תרחישים. למשל מקרים מיוחדים של טעויות ובקרות IDOCS, קבצים שלא הגיעו ממשקי FTP או כספות. המערכת מספקת גם תצוגה גרפית של הממשק ושל ההתראות על גביו, DRILLDOWN ותצוגה עיתית של הזמנים.
User Experience Monitoring
מודול זה מפעיל סקריפטים של סימולציות של עבודת משתמשים אופיינית במקומות שונים בארגון. באם קיימים חריגים בביצועים הוא מתריע וכך יכול לתפוס מבעוד מועד בעיות תקשורת בארגון. הנושא יישים בעיקר לארגונים עם פריסה בינלאומית כך שאם המודול תופס זמן תגובה איטי בלילה של אוסטרליה שהוא יום בישראל , אתה עדיין יכול לתקן את התקלה לפני יום העבודה של המשתמשים שם.
HANA &BI Monitoring
המודול הוא בעצם סוג נוסף של System Monitoring ונראה דומה מאוד ומספק מספר כלים ומטריקות נוספות של ייחודיות ל HANA כגון Dynamic Tiering, Smart Data Streaming, Smart Data Provisioning.
DASHBOARDS
ראשית ישנו ריכוז של כל ההתראות מכל הסוגים במסך תצוגה אחד שבו ניתן למיין ולמצא בדיוק את סוג ההתראות בהם מעוניינים ובאיזו מערכת :
כל ההתראות מוצגות גם על ידי כלי מרכזי הנקרא DASHBOARD BUILDER המציג מספר מסוים של Dashboards הניתנים להתאמה.
לדוגמא הצגת Availablity של מערכות:
או למשל ריכוז של ביצועי המערכות :
לסיכום – מומלץ מאוד ליישם את יכולות הניטור של ה SOLMAN שיכולים למנוע הרבה תקלות וגם לטפל בהם במהירות וביעילות. מספר ארגונים המיישמים בישראל – הפניקס, אלעל, קוקה קולה, פלרם.
בהצלחה!
עודד
התקנת HANA עבור ECC הוא הפעלת מערכת ה ECC עם בסיס הנתונים החדש HANA. כבר נכתב רבות על היתרונות של HANA עבור מערכות BW וישנם לא מעט ארגונים בארץ שכבר עברו אליו. אבל המעבר לHANA עבור ECC או עבור ה Business Suite רק מתחיל והפעם נרחיב עליו.
סיבות ומטרה למעבר
בנוסף למהירות הישירה ניתן גם לרכוש כלי אנליטי לדוחות תפעוליים מאוד מהירים על המערכת הנקרא HANA LIVE.
https://blogs.saphana.com/2014/08/29/the-benefits-of-the-business-suite-on-hana/
תנאי קדם
UNICODE – המשוכה העיקרית להתקנת HANA היא שמערכת ה ECC חייבת להיות UNICODE. רוב הארגונים בארץ כבר עשו זאת, אך לא כולם. מומלץ לבצע פרויקט מעבר ל UNICODE במנותק מהמעבר לHANA אך אפשר גם לאחד (כך אנו עושים במשטרה). הבדיקות הן אחרות ומתמקדות על ממשקים וטפסים.
EHP7 – 8 – אפשר לעבור ל HANA מ EHP7 או EHP7. EHP8 שוחרר לפני שנתיים וחצי ו EHP8 שוחרר בתחילת השנה כך שקיימים הבדלים גדולים בגירסאות ובחידושים. אך EHP7 איננה דורשת UNICODE לעומת EHP8 שכן דורשת.
הכנות
חומרה – צריך כמובן להצטייד בחומרה המתאימה ובאיכסון מקביל מספיק גדול. קיים הרבה ידע אצל יצרני החומרה ונציגי סאפ בנושאים הללו. חשוב גם להתעניין בטכנולוגייה של Dynamic Tiering המבוססת על אלגוריתמים של "טמפרטורת" מידע כך שלא כל המידע חייב לשכון פיזית בזכרון ה DB המהיר וחלקו יושב על דיסק. ניתן לקבל חסכון ניכר ובוודאי במערכות שאינן ייצור.
הכנת קוד הלקוח
ישנם שלושה סוגי התיחסות לקוד לקוח כחלק מההכנות למעבר:
כדי שלא לבצע תיקונים על קוד שאיננו בשימוש כדאי להעזר בדוחות ובקוביות של UPL (ראה פוסט CCLM) המצביע על תוכניות הנמצאות בשימוש ברמה יומית ורמת תוכניות מפורטת. רק על האוכלוסיה הזאת יש להריץ את ה code inspector
ABAP Test Cockpit and Code Inspector in Context of HANA Migration
בנוסף ניתן לבחון גם הכנסת שיפורים לפיתוחים הקיימים כדי שישתמשו ביכולות של HANA ויביאו לשיפורביצועים משמעותי. את מדידות הזמנים ברמת ה SQL יש לבצע באמצעות כלי בקרה חדש בשם SQL MONITOR.
המעבר ל HANA
המעבר עצמו הוא למעשה פעולת הגירה של בסיס נתונים. ( DB MIGRATION) שהוא פעולה שאיננה משפיעה על היישום או על הנתונים ומבוצעת בידי צוות ה BASIS ברקע. הכלים בהם משתמשים הם : SUM – Software Update Manager המנהל את כל המעבר ובתוכו אופציה מיוחדת ל HANA שנקרא DMO – Database Migration Option המנהל את הההגירה מה DB הקיים ל HANA.
הפרויקט יתנהל בהתאם לשלבים הקלאסיים אך חשוב ביותר לבצע את ההגירה הראשונה על עותק של מערכת הייצור! זאת כדי לקבל את המשמעויות של מלוא הגודל של ה DB של הייצור על HANA.
בדיקות
בפרויקט המעבר יש לשים לב לבדיקות הבאות:
בדיקות פונקציונליות – לוודא שכל הקוד שתוקן מתפקד כראוי. כדאי גם לבצע בדיקות רגרסיה סטנדרטיות עם BPCA (ראה בלוג מה התקלקל ? – בדיקות רגרסיה) .
בדיקות ביצועים – כדאי לוודא שאין ירידה בביצועים. לצורך כך ניתן לבצע מדידות זמנים בטרנזקציות/דוחות כבדים לפני ואחרי המעבר.
ארגונים שעברו או שנמצאים במעבר ל BS על HANA , הם לפי הידוע לי, כתר פלסטיק, בי"ח הדסה ומשטרת ישראל.
להלן דוגמא של מעבר כזה שבוצע ב accenture.
https://www.accenture.com/ma-en/success-digital-sap-business-hana-finance
בברכה,
עודד
בקרוב משתחררת מהדורה ראשית 7.2 של ה Solution Manager. היא נמצאת מינואר 2016 בבדיקות Ramp-Up ומשתחררת לציבור הרחב בקיץ 2016 (GA-Q3). סאפ תפסיק לתמוך ב SOLMAN 7.1 בסוף 2017 כלומר יש חלון זמן של שנה וחצי לעבור למהדורה זו.
ל SOLMAN 7.2 שיפורים ויתרונות רבים אותם אציג כאן בקצרה וביתר הרחבה בפוסטים הבאים. למעשה כל ארגון יהיה חייב לעבור למהדורה זו ולו רק בגלל הצרכים של ה BASIS בשימוש ב SOLMAN. רצוי לנצל את היכולות של 7.2 לטובת ניהול יותר כוללני ואינטגרטיבי של פעילות ה IT בעולם הסאפ ולוותר על רשיונות של פתרונות אחרים קיימים.
שינויים ושיפורים ב ALM ובחלקים היישומיים
שינויים ושיפורים ב Operations ותמיכה הטכנית
מעבר ל 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/
אני כבר עובד על SOLMAN 7.2 בענן , בודק את כל התכונות החדשות ואת שיטת המעבר למהדורה החדשה.
בברכה,
עודד
נרחיב הפעם על מושגי יסוד בפרויקטי Rollout וההופכי שלהם –פרויקטי Rollin.
בכל פעם שהארגון מרחיב את השימוש ב ERP שלו, במקרה שלנו סאפ, ליחידה ארגונית חדשה שלא כוסתה עד כה – זהו בעצם פרויקט Rollout. לרוב מדובר על מפעל או חברה שעדיין עובדת בתוכנה קודמת (Legacy) וטרם הועברה לסאפ. הסיבה יכולה להיות שזה חלק מתוכנית היישום המקורית המדורגת שכוללת מספר רב של יחידות שלא ניתן ליישם את כולם בבת אחת או כתוצאה מרכישה וממיזוג חדש.
פרויקט ה Rollout אינו כולל רק יישום תוכנה ארגונית אלא גם את הטמעת התרבות הארגונית, התהליכים הארגוניים ונהלי העבודה (Best Practices) תוך כדי שילוב היחידה בארגון. להלן המתודולוגיה המקובלת והמומלצת על ידי סאפ. היא מתחלקת לשלב בניית התבנית – Global Template ושלב היישום ביחידות הקצה – Local Implementation
שלב בניית התבנית – Template. זהו החלק הראשון והתשתיתי שבו מכינים את כל התהליכים העסקיים של יחידה לדוגמא שאותה ישכפלו בכל היחידות. לעיתים ישנם ווריאנטים שונים: יחידה שהיא רק משרד מכירות, יחידה הכוללת מפעל ייצור וכו'. התבנית תכלול בנוסף על תוכן גם תבניות ונהלי עבודה להסבת נתונים, בדיקות, ניהול הפרויקט, לוחות זמנים, סטנדרטים, תפקידים, שאלונים ועוד.
שלב פרויקטי ה Rollout – השלב הראשון החשוב נקרא לעיתים Fit–In או שם אחר והוא שונה מהותית מ Blueprint וגם קצר יותר! כאן מציגים את תהליכי התבנית ליחידה החדשה, מקבלים היזון חוזר ומנתחים את הפערים. אותם פערים הנוצרים מהבדלים משפטיים, או שהם בגלל חוקי המדינה – יפתרו בחבילות הלוקליזציה של סאפ או עם פיתוח. ישנם גם פערים הנוצרים עקב הבדלי נוהג עסקי או תרבותי בארץ היעד וכאן צריך להחליט אם מתחשבים בזה או מיישמים את תהליכי התבנית כמות שהם. כלומר תמיד נוצר מתח בין הצרכים המקומיים והתבנית הגלובלית – וצוות הפרויקט צריך לגשר על פניהם.
שלב המימוש (Realization) דומה מאוד לשלב מימוש רגיל בפרויקט הקמה. החלק של הקיסטום קצר ביותר כי הידע הקיסטומי קיים כבר ומתועד בתבנית (או ב BCSETS כפי שנסביר בהמשך) וצריכים להיות מעט מאוד פיתוחים. בעיקר טפסיים יחודיים למדינה או לאזור, שינויי לוגו וכדומה.
שלב ההכנה לייצור – הוא מאוד משמעותי בפרויקט Rollout בעיקר בגלל ניהול השינוי וההטמעה. תהליכי העבודה של התבנית הגלובלית הם לרוב נוקשים וביורוקרטיים יותר ממה שהיה נהוג ומהתוכנה המקומית שנתפרה בדיוק על פי המידות – ולכן גם ההתנגדויות הן רבות. זה גם הזמן לתפוס טרמפ ולהנחיל את התרבות הארגונית הכללית, פורטל ארגוני, נהלים וכו' כך שיש להקפיד על כל הנושאים הללו כדי להצליח.
עליה לאוויר – בפרויקט גלובלי יש לתאם את העליה לאוויר של היחידה עם הפעלת גרסת תוכנה של התבנית וכמו כן לפעמים עם עוד מפעלים / חברות שעולים לאוויר באותו מועד. כך שהעליה לאוויר יכולה להיות מורכבת.
מתודולוגיה וכלים
המתודולוגיה הסטנדרטית של סאפ היא ה Global ASAP Roadmap שהוא ענף ייחודי של ASAP ומפרט את כל הכלים והשלבים שתיארתי.
כל השלבים נתמכים היטב ב Solution Manager החל מפרויקטי התבנית וכלה בפרויקטי ה Local Rollout המועתקים במלואם או בחלקיות מהתבנית.
לעיתים קרובות לחברות יישום בינלאומיות (יבמ, HP וכו') ישנם תוספות ייחודיות שלהם וכלים נוספים.
BCSETS – ניתן להיעזר ב BCSETS בפרויקטי Rollout לצורך הפצת הקיסטומים. זה משמעותי במיוחד כאשר מערכת היעד נפרדת ממערכת המקור. הייחודיות של ה BCSETS כאן היא כפולה:
בפרויקט הממשלתי "מרכבה" המבצע Rollouts בכמאה משרדי ממשלה ויחידות סמך משתמשים רק במנגנון הזה כדי להעביר קיסטומים. חלק מההטמעות בוצעו על שרתים נפרדים.
ראה את הפוסט שלי – השוואת קיסטום
דוגמאות לפרויקטי Rollout ישנם רבים בארץ. אציין את הבולטים: פרויקט המרכבה המופץ בכ 100 משרדי ממשלה ויחידות סמך, פרויקט כי"ל גם הוא ב 100 חברות, צים – בכ 120 סוכנויות ברחבי העולם, כתר פלסטיק, נטפים וכעת גם טבע ועוד רבים אחרים.
פרויקטי Rollin – הם ההסתכלות של פרויקט ה Rollout מהכיוון של היחידה המקבלת. לדוגמא חברות בארץ שנרכשו על ידי תאגידים מחו"ל והותקן בהם סאפ תאגידי. לעיתים מתמנה מנהל פרויקט מקומי כדי לנהל ולגשר על הפערים עם התאגיד ולרוב גם איש לוקליזציה המכיר היטב את יישום הלוקליזציה הישראלית בסאפ. לדוגמא – אופיר אופטרוניקס שנרכש על ידי NEWPORT, רדימיקס שנרכש על ידי CEMEX ועוד רבים אחרים.
פרויקטי פיצול – בהם יחידה ארגונית נמכרת וצריך לפצל את הפעילות העסקית ואת מערכת המידע – מאוד דומה לפרויקט Rollout ומתמודד עם אתגרים דומים. דוגמאות לכך הם בתי הזיקוק באשדוד שהתפצלו מבז"ן ונמכרו לפז וגלידות שטראוס שנמכרו ליונילבר.
לסיכום – כל עוד ימשיכו לרכוש ולמכור מפעלים וחברות יצטרכו למזג ולפצל את מערכות המידע ולבצע פרויקטי Rollout ו Rollin. לכן כדאי להתמקצע בכך ולהכיר היטב את כל ההיבטים של פרויקטים אלה.
בברכה,
עודד
הבלוג של עודד לקהילת הסאפ בישראל 