TEST STEPS

נספר הפעם על מודול בדיקות חדשני בשם Test Steps המשולב ב Test Suite , זאת במסגרת ה Focused Build שהוא תוסף פרויקטלי ל SOLMAN. המודול מאפשר תיעוד ובדיקות מקוונות של תסריטים בתהליך במקום תסריטים המתועדים במסמכי וורד או אקסל ב Test Suite  הרגיל. הוא פועל בצורה דומה מאוד למערכת ה QC הוותיקה ויכול להחליף אותה לגמרי.

Test Step Designer – הוא כלי התכנון המאפשר לרשום צעדים קטנים בתהליך כגון בדיקת שדה, ערך מסוים, פלט מסוים או כל צעד או הוראה שהיינו כותבים בתסריט. כלי ה Designer מספרר את הצעדים ומאפשר לתאר אותם בפירוט רב ולרשום את הטרנזקציה הנבדקת  שתופעל כדי שבבדיקה נוכל לבדוק גם באופן מקוון. ניתן לרשום תוצאה צפויה  וכמו כן את מספר ושם הבודק הספציפי למקרה של צעד כלשהו שרק בודק מסוים יודע לבדוק. ניתן לצרף מסמך אם רוצים להרחיב עוד את ההוראות וכמו כן יש Checkbox בשם Evidence המחייב את הבודק להכניס את התוצאות שהתקבלו. ניתן גם לקבוע מראש סוגי מסמכים שצפויים להתקבל כגון הזמנות רכש או פקודות יומן (Result Attributes).

כמו כל Test Case אחר עליו להשתייך לתהליך בעץ התהליכים. לכן ניתן ליצור אותו ישירות מתוך עץ התהליכים או ליצור אותו עצמאית (מתוך ה Fiori Launchpad) ולאחר מכן לשייך אותו לתהליך שלו. אם יוצרים אותו ברמת ה Process אז הוא יוצר אוטומטית שורות עם טרנזקציות בהתאם ל Process Steps שמתחת ל Process.

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

שפה – ניתן לכתוב בעברית או שפה אחרת בכל שלב.

לאחר יצירת ה Test Case  מסוג Test Steps ניתן ליצור ממנו חבילת בדיקות ולשייך אותו לבודקים.

My Test Executions – זה החלק התפעולי בו הבודק מפעיל את הבדיקות ורושם את התוצאות באופן מקוון לגמרי.

בדומה ל Tester Worklist גם כאן הבודק מנווט לתוכנית הבדיקות, חבילת הבדיקות וה Test Cases המיועדים לו ובסוף מגיע לאותם בדיקות שטרם נבדקו ומחכים לו.

בכל שורה הבודק רואה ישירות את הוראות ההפעלה שנרשמו ב Designer. הוא מפעיל את הטרנזקציה ישירות מתוך מסך ה Steps ומבצע את הבדיקה. הוא יכול לתעד את הבדיקה בצילום מסך ולשמור אותו ב steps כ attachment וגם לרשום במלל את התוצאה ולרשום את מספר המסמך באם נדרש לכך. כמובן עליו לבחור בסטאטוס. אם התגלתה בעיה הוא יכול מהמסך הזה לפתוח תקלה,   Defect, במערכת ניהול התקלות – ITSM. רק לאחר סיום הטיפול ובדיקה חוזרת מוצלחת הוא יוכל לסמן סטאטוס תקין. הסטאטוס הכללי של כל ה Test Case נקבע לפי תוצאת ה step החמורה ביותר.

ניתן גם להגדיר צעדי משנה, sub steps, לכל צעד.

החל מ 01.01.20 ניתן יהיה להוריד, להתקין ולהפעיל את המודול בחינם, זאת במסגרת ה Focused Build שהוא תוסף פרויקטלי ל SOLMAN. כדי להפעיל את ה Test Steps לא צריך להפעיל את כל תכולת ה Focused Build כי הוא חלק חיצוני הכלול ב Standalone Extension  של ה FB.

קישורים:

blogs.sap.com/2018/09/26/focused-build-test-steps-manual-testing-with-sap-solution-manager

Test Steps Designer

בהצלחה!

עודד

מודעות פרסומת

TEST SUITE

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

תסריטים / תרחישי בדיקות

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

הם נקראים Test Cases ומשלבים אותם בתוך עץ התהליכים (Solution Documentation) במקומות המתאימים שיש לבדוק כך שעץ התהליכים מכיל את כל התסריטים עבור כל התהליכים. (ראה התייחסות למהדורה מתקדמת בסוף הפוסט)

בדיקות פרויקטליות

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

בדיקות פונקציונליות

בדיקות UAT – User Acceptance Tests

בדיקות אינטגרציה

ה TEST SUITE מאפשר לבצע כל זאת באמצעות ה Test Planning:

תוכניות בדיקה – Test Plans.    מוקמים מתוך בחירה של Test Cases  + Executables מתוך עץ התהליכים. למשל אם רוצים להקים תוכנית בדיקה למודול ה SD בוחרים מתוך העץ את התסריטים והטרנזקציות המתאימות לכך.

חבילות בדיקה – Test Packages. אילו הן תת קבוצות מתוך תוכנית הבדיקה לצורך התאמה לבודקים. גם הוא מכיל Test Cases  + Executables.

שיוך לבודקים – Assign Testers. משייכים את חבילת הבדיקות לבודק אחד או יותר.

Test Sequence– סדרת בדיקות, זוהי ישות חדשה במודול המאפשר למספר את ה Test Cases  + Executables ולבצע אותם לפי סדר מסוים. ה Test Sequence יוצר חבילת בדיקות. היא גם יכולה לאפשר הקמת תסריטי End to End ותסריטי אינטגרציה כאשר ה Steps המקוריים ממוקמים במקומות שונים מאוד בעץ.

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

 Defect Management – בכל שלב במהלך הבדיקה ניתן לפתוח תקלה במודול התקלות (ראה ITSM) ולעקוב אחריה עד לסיומה. רק אז ניתן לסמן את סיום הבדיקה.

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

בדיקות שוטפות

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

CHARM – (ראה NEW CHARM) במהלך הפיתוח השוטף, כל שינוי שנוצר צריך להיבדק במערכת ה QA , לקבל אישור בדיקה ולהמשיך לייצור, אם על ידי המיישם או על ידי הבודק. אם רוצים להפעיל תסריט קודם או תסריט ייעודי – ניתן לצרף את ה Test Case ל Normal Change או לחילופין לשייך את ה NC לחבילת בדיקות המתאימה לתהליך.

בדיקות רגרסיה – לאחר בדיקת השינוי עצמו רצוי מאוד לבדוק שהשינוי לא קלקל תהליך קיים במערכת. זה נקרא בדיקת רגרסיה. אבל כמה לבצע, היכן ומתי? לשם כך נועד מודול ה Change Analyzer BPCA (ראה BPCA) המזהה את ה Test Cases שיש לבדוק ואפילו יוצר תוכניות בדיקה לשם כך. מפעילים אותו לרוב עם העברת מחזור שינויים וטרנספורטים תקופתי.

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

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

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

במסגרת ה Focused Build  (שיהיה חינמי ב 01.01.2020 – ראה Focused Build) – סאפ פיתחו גם כמה תוספות מיוחדות ל Test Suite. אחת מהן בשם Test Steps מהווה תחליף מקוון לתסריטים בוורד ואקסל, ממש דומה ל QC! על כך בפעם הבאה….

להתראות,

עודד

Demo Systems

רוצים להתנסות ולבדוק תהליכים בסאפ החדש? זוכרים את מערכת ה IDES של R3 / ECC? אז איפה עושים את זה היום עבור S/4HANA? נציג אפשרויות אלה הפעם. גם ל SOLMAN.

SAP S/4HANA 1809 FPS01, Fully-Activated Appliance

זוהי מערכת S4/HANA  שלמה שבה מקוסטמים כל התהליכים הבסיסיים של ה BEST PACKAGES של S4, CRM, MDG,TM,PPM,Analytics  ועוד. הם כוללים תרחישים עם נתונים ומדריכים למשתמש (GUIDES).

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

ישנן שתי אופציות להפעלה:

  • דרך התקנה פיזית On Premise . כמו כל התקנה ה BASIS צריך להוריד ולהתקין.
  • התקנה דרך הענן של סאפ – CAL. תוך שעתיים ניתן להתקין ולהשתמש. CAL ניתנת לשימוש לאחר שרכשתם מנוי ב AWS של אמזון, AZURE של מיקרוסופט או GCP של גוגל.

sap.com/cmp/oth/crm-s4hana/s4hana-on-premise-trial

sap-s4hana-fully-activated-appliance

 

CALCloud Appliance Library

cal.sap.com

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

אני ניסיתי את המערכת לפני שנתיים עם Solution Manager 7.2 על ה CAL וחוויית המשתמש הייתה טובה מאוד. בקלות מעלים את המערכת ומתחברים והמערכת עצמה נשמרת לך ואתה יכול לשחק איתה ולהתנסות.

MODEL COMPANY

זוהי כבר גירסה מתקדמת יותר של S4/HANA עם חברה לדוגמא עובדת עם נתונים ודוגמאות. ישנם כ 8 מודלים כאלה המתאימים ל LOB שונים שדומים ל Industry Solutions  הידועים כמו UTILITIES או INSURANCE. היא כבר עולה כסף- ראה לקישורים הבאים.

sapstore.com/solutions/99072/SAP-Model-Company-Discovery

sap.com/services/implementation/preconfigured-industry-solutions

blogs.sap.com/2019/06/03/what-is-the-difference-between-sap-best-practices-and-sap-model-companies

SOLUTION MANAGER DEMO SYSTEM

ב  SOLMAN החיים שלנו הרבה יותר קלים. ה DEMO SYSTEM היא מערכת 7.2 מלאה , ב SP האחרון, ומקוסטמת עם נתונים ותהליכים פעילים. בקישור הבא ניתן להכנס עם LOGIN לפי התפקידים הרשומים. והכל בחינם. טיפ – התפקיד האחרון , של BAUERA, כולל הכל.

support.sap.com/en/alm/solution-manager/demo-systems/internet-demo-system

תיהנו!

עודד

NEW CHARM

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

CHARM – Change Request Management הוא מודול ניהול השינויים ובקרת התצורה ב SOLMAN.

יתרונותיו:

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

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

תהליך ניהול השינויים מתחלק ל 3 חלקים כפי שמתואר בתרשים הבא.

  1. Request for Change – בקשה לשינוי הוא החלק המנהלי וכולל את בקשת המשתמש, השו"ש או גם יכול לנבוע מתקלה הדורשת פתרון. פותחים אותו משתמשי מפתח שגם מקבלים חיווי על התקדמות הפתרון והפיתוח ועל סיומו.
  2. Change Document – מסמך שינוי. זה החלק הביצועי של השינוי המלווה את תהליך ה קיסטום / פיתוח, בדיקות והעברות טרנספורטים בין הסביבות. הסוגים הנפוצים של מסמכים הם Normal Change ו Urgent Change. ניתן לשייך מסמך שינוי אחד או יותר ל  Request for Change.
  3. Change Cycle – מחזור העברות. כולל בתוכו את כל השינויים העוברים למערכת הייצור ביחד , לדוגמא במחזור יומי או שבועי. המחזור מייבא את כל התכולה בבת אחת ודואג לסדר, כלומר אין יותר צורך לדאוג לסדר העברת הטרנספורטים.

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

TOC  – Transport of Copies – היא תכונה של ה Normal Change המשתמש בטרנספורטים מסוג Transport of Copies  (שהם העתקים אוטומטיים של ה TASKS של הטרנספורט המקורי) ומשרתים את ההעברה למערכת הבדיקה, QA, תיקון שלה ב DEV ובדיקה חוזרת בQA, וחוזר חלילה עד שהכל תקין. לכן נפתח טרנספורט אב אחד ב  DEV הנמצא במצב  Modifiable עד שהוא תקין  ומאושר סופית, רק אז טרנספורט האב מאושר, נסגר ומועבר ל QA . זוהי תכונה בלעדית ל  CHARM. השימוש ב TOC מוריד משמעותית את כמות הטרנספורטים המועברים לייצור עד לפחות מחצי. זה גם משפר מאוד את האמינות ואת השרידות.

Urgent Change – שינוי דחוף, ללא TOC, ועם מסלול מקוצר. נועד לתיקון תקלות ייצור.

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

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

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

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

קשר לבדיקות – בתוך מסמך השינוי ניתן לקשור מסמכי בדיקות בעץ וגם קישור לחבילת בדיקות במודול הבדיקות.

הפעלת CODE INSPECTOR  – בתוך מסמך השינוי ניתן להפעיל  ATC או CODE INSPECTOR על פיתוחים וגם להתנות את ההעברות בתקינות הקוד.

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

שילוב BPCA – ניתן להפעיל את מודול בדיקות הרגרסיה על מסמך שינוי מסוים או על גרסה או מחזור שלם. (ראה BPCA)

(Downgrade Protection +   cross-system object lock (CSOL – תוסף תוכנה שיכול למנוע ובעיקר מתריע על אובייקטים משותפים הנמצאים או מגיעים ממערכות אחרות וכן מתופעת דריסת שינוי חדש בשינוי ישן (downgrade)

CTS CENTRAL – תוסף תוכנה המאפשר להעביר דרך ה CHARM בוזמנית מספר שינויים קשורים מסוגי מערכות סאפ שונות למשל מ ECC יחד עם BW, SRM, CRM, פורטל ועוד.

LANDSCAPE REDEFINITION – תכונה המגדירה מחדש, עבור ה CHARM, את הקשרים בין המערכות לאחר ביצוע שינוי מערכתי כגון רענון QA או DEV.

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

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

ניתן גם להפיק ממנו גרפים:

תכונות חדשים שנוספו ב SP6 – SP8

התרעות במייל  – ניתן להוסיף למיילים הנשלחים גם התרעות על errors שנוצרו ב Import

עיצוב המייל – ניתן להוסיף למייל מידע ושדות מתוך השינויים.

קישור TR ל NC – ניתן לקשור טרנספורט שהוקם ישירות ב DEV אל מסמך שינוי , NC, ישירות מ DEV.

Transport Risks– בתוך הבלוק של ה Landscape ניתן לטפל בטרנספורטים בעייתיים ולמחוק אותם מרשימת הסיכונים.

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

סימון השינוי בעץ בתהליך – בתהליך המתאים בעץ התהליכים ניתן לקשור ולסמן את מסמך השינוי המתאים.

Cross-Reference Check – במקרה שאובייקטים חסרים בטרנספורט וגורמים לכך שנוצר error 8 מסוג Code Generation Error ב Import ניתן למנוע זאת ולבדוק מראש ולקבל התראה דרך ה CHARM.

בברכה,

עודד דגן + השותף שלי לכתיבת הפוסט ול CHARM  – עופר קוסקאס

 

 

 

 

 

 

 

 

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

בהצלחה!

עודד

Focused Build

Focused Build הוא הכלי לניהול פרויקטי IT העדכני והמוביל של סאפ. הוא מבוסס על Solution Manager 7.2  ומהווה פתרון מושלם, אינטגרטיבי ומוכן לעבודה מיידית ,כלומר לא נדרשת עבודת התאמה או קיסטום נוספת. נדרש רק ללמוד אותו היטב, להתאים את נהלי הפרויקט לכלי, להטמיע ולתמוך במהלך הפרויקט. הוא מותקן ב SOLMAN כ ADD-ON במקביל לטרנזקציות הקיימות של ITSM + CHARM ואיננו מפריע להן.

החדשות הטובות הן שהחל מ Q4 של 2019 הוא ניתן בחינם (ועד אז בהנחות גדולות לפי רבעונים). עד היום הרישיונות עלו 250 יורו לאחד.  למי שעומד להתחיל פרויקט גדול מומלץ להתעניין!

https://blogs.sap.com/2019/01/27/sap-is-making-it-easier-for-you-to-leverage-focused-build-and-focused-insights-for-sap-solution-manager-in-2020/

ה FB איננו מתאים לניהול פעילות שוטפת – רק לפרויקט אך ישנן בתוכו גם תוספות ייחודיות המיועדות לשוטף – STANDALONE EXTENSIONS (על כך בפעם אחרת).

ה FB מבוסס על מתודולוגית ACTIVATE של סאפ (ראה ACTIVATE שלי ) ותומך בשלבים של ACTIVATE.

ה FB מחולק לשלבים עם שמות הלקוחים מתחום הפרויקטים האג'יליים:

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

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

.

הכלים של ניהול הפרויקט מבוססים על ה ITPPM (ראה EPM-PPM) אך ב SP02 של ה BP סאפ פיתחו מסכים מיוחדים ומאוד ידידותיים מבוססי UI5 לניהול הגאנט וחבילות העבודה שמחליפים את מסכי ה ITPPM הרגילים.

תוספות ייחודיות לניהול הפרויקט ב FB מעבר ל SOLMAN הרגיל

  • תבניות לניהול פרויקט עפ"י שיטת ה RELEASE, WAVE, SPRINT
  • קשר ישיר לעץ התהליכים, לתיעוד ולתהליכי הפרויקט- Solution Documentation
  • קישוריות גבוהה לכל המודולים של SOLMAN כגון ה TEST SUITE.
  • תבניות מסמכי פרויקט מוכנים
  • קישוריות לJIRA אם רוצים ניהול אג'ילי לגמרי כולל SCRUM
  • ניהול סיכונים וניהול משאבים והצבות של כח אדם.
  • solution readiness dashboard– כאן מרוכזים הנתונים העיקריים של הפרויקט עם קישורים להכנס ולבצע DRILL DOWN לכל מקום. (ראה להלן)

במקביל לניהול הזמנים שב WAVE וה SPRINT, היישויות הביצועיות של הפרויקט הן:

  • WORK PACKAGE– זוהי יישות תכנונית של היקף עבודה המקבילה ל RFC– Request for Change ב CHARM. יש לה אורך חיים, סטאטוסים, והיא מקושרת ל WORK ITEM
  • WORK ITEM– יישות ביצועית המכילה טרנספורטים ומעבירה אותם בין המערכות. מקבילה ל Normal Change של ה CHARM. כך מפרידים ומטפלים רק בטרנספורטים של התהליך הספציפי ומקדמים לשלבי הבדיקות והייצור.

ה WORK ITEM וה WORK PACKAGE מתעדים ומבצעים את העבודה בפועל כאשר הם מקושרים לגאנט הפרויקט באמצעות ה SPRINT וה WAVE. ישנם מסכים ואפליצקציות UI5 מיוחדים המטפלים בהם , מעבר ל UI של ה CRM.

תוספות ייחודיות לבדיקות ב FB מעבר ל SOLMAN הרגיל

  • דוחות התקדמות וביצוע הבדיקות ברמת פרויקט
  • ניהול תקלות לפי עדיפות וסטאטוס
  • Dashboard מיוחד לבדיקות בפרויקט
  • ניהול צוותי בודקים ומעקב אחרי ההתקדמות שלהם.

 

קישורים ל Focused Build:

https://wiki.scn.sap.com/wiki/display/SM/WIKI+Focused+Build

Focused Build Media Center

Focused Build in SAP Solution Manager – Insights from an agile SAP S/4HANA project

בהצלחה!

עודד

ITSM

ITSM – IT Service Management הוא מודול ניהול השירות (Help Desk / Service Desk) של סאפ הנמצא בשימוש במספר ארגונים גדולים בארץ (חברת החשמל, בתי חולים ממשלתיים, שירותי בריאות כללית ועוד). הוא משמש לניהול תקלות, ניהול בקשות שירות ולו מספר יתרונות ייחודיים על פני המתחרים:

  1. מאחר שהוא יושב על פלטפורמת SOLMAN + CRM של סאפ ומחובר לכל מערכות הסאפ הוא שואב בקלות את כל המידע על תקלות, מערכות, הרשאות ישירות מהמערכות אל תוך התקלה אוטומטית ובכך חוסך הרבה טלפונים, התכתבויות, צילומי מסך בדרך. פתיחת תקלה היא ישירות מתוך ה SAPGUI או FIORI או כל UI אחר של סאפ.
  2. השימוש ב ITSM הוא חינם לכל משתמשי סאפ. בנוסף הוא חינם גם לכל המשתמשים בארגון שאינם -משתמשי סאפ. המשמעות היא שניתן להשתמש בו כפתרון לכל מערכות ה IT, תוכנות, ומתן שירות כללי בארגון – בחינם! חסכון בעלויות רשיונות מוצר ה HD הנוכחי.
  3. ה ITSM מחובר ישירות ל CHARM (ניהול השינויים והטרנספורטים), עץ התהליכים, ניהול הבדיקות וכל יתר המודולים ב SOLMAN .
  4. ITSM הוא כלי משוכלל, מודרני עם יכולות גבוהות כפי שנתאר בהמשך.
  5. ל ITSM יש הסמכה של ITIL ומהווה נדבך מרכזי בניהול מערך ה IT. 

תרחיש בסיסי –ניהול תקלה

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

זהו גם התרחיש הבסיסי לניהול תקלות של משתמשי קצה ובו אפשרויות רבות. ניתן להעביר את התקלה ישירות לשירות  (first level support – HELP DESK ). שם ה Dispatcher  ממיין, עונה בעצמו אם הוא יכול ואם לא הוא מעביר הלאה למומחים (second level support).

תכונות נוספות

  • ניהול PROBLEMS – כאשר מתברר שהתקלה חוזרת על עצמה ושזו בעצם תקלה מערכתית ורוחבית, פותחים יישות בשם PROBLEM המאגדת את כל התקלות הקשורות ופותרת את כולם ביחד.
  • ניהול KBA – Knowledge Base Article – כשיש פתרון ידוע וקבוע לבעיה קבועה (איפוס סיסמא למשל) מתעדים ב KBA ושולחים או מבצעים כפתרון קבוע לפניה.
  • שיוך אוטומטי לצוות מטפל – מבוצע ב ITSM עם מנוע החוקים של סאפ, BRF+. כלומר ניתן להעביר ישירות לצוות מטפל לפי חוקים קבועים מראש. הצוותים מנוהלים דרך ה PPOME – ה Organizational Management  של ה HR.
  • תקלות הרשאות – שהן נפוצות מאוד, המידע של SU53 (הרשאות חסרות) מועבר אוטומטית לתקלה ללא התערבות של המשתמש.
  • מעקב סטאטוסים ו WF – מתבצע מעקב ולוג אחר כל שינוי בסטאטוס. ה WF מתבצע עם משלוח מיילים לכל מטפל בדרך.
  • צילומי מסך – ניתן להדביק לטקסט של התקלה צילומי מסך של התקלה. (ב CRM UI).
  • SLA – Service Level Agreement – ניתן לנהל הסכם וחוזה SLA ולעקוב אחריו כולל חישוב פרמטרים כגון IRT – Initial Response Time , MRT – Maximum Response Time. ניהול זמנים אחרים ודוחות.
  • חיפוש – קיימת יכולת חיפוש ברמה של FULL TEXT RETRIEVAL, בעזרת TREX או תשתיות HANA. המשמעות היא שניתן לחפש ולאחזר כל תקלה על פי כל מילה בתקלה, כולל הקבצים המצורפים לה.
  • יכולות קיסטום רבות – ליישום ה ITSM מבצעים קיסטום בלבד! אין צורך בפיתוח כלל! העושר הפונקציונלי הרב , מעל שכבת ה CRM, מיתר את הצורך הזה. ארגונים שיישמו HD דרך CRM בלבד השקיעו רבות בפיתוחים.
  • קישור לHD אחר – במקרה שבארגון קיימת תוכנת HELP DESK אחרת ורוצים לקשר ביניהם קיים API לקישוריות והעברת הנתונים מה ITSM לתוכנה אחרת. כך ניתן ליהנות משני העולמות: מהיתרונות של ITSM במערכות הסאפ יחד עם שילוב בתוכנת ה HD של כל הארגון.
  • דוחות ואנליטיקה – קיימים שאילתות תפעוליות המציגות את החתך המתאים לכל בעל תפקיד בתרחיש. בנוסף ישנם קוביות BW ואנליטיקה תואמת המוצגים ב DASHBOARD מיוחד עבור ה ITSM.
  • ממשק למשתמש – ה UI הרגיל הוא של CRM Web UI (דומה מאוד ל CHARM) אך במהדורה 7.2 קיים גם UI של FIORI כולל LAUNCHPAD ותמיכה בהפעלה מניידים:

ניהול השירות

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

קישורים עיקריים :

ITSM WIKI

ITSM Overview

נשמח לספק סיוע נוסף על פי דרישה.

בברכה,

עודד

 

Backbone Update

שלום !

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

  1. שינוי תשתיות התמיכה של סאפ מול הלקוחות

סאפ הודיעה לאחרונה שבתאריך 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.

  1. הפסקת חיוב וספירת הרשיונות ב SOLMAN החל מ 01.01.2018

המשמעות – ניתן להשתמש בפונקציונליות ובמודולים השונים של SOLMAN עבור כל סוגי המשתמשים בארגון ועבור כולם – בחינם! היתרון והדוגמא הבולטת ביותר לכך היא האפשרות להשתמש במודול ה ITSM שהוא HELP DESK כלל ארגוני – עבור כל המשתמשים בארגון ולא רק של מערכות ה סאפ. ה ITSM הינו מודול מבוסס CRM והוא עשיר מאוד בפונקציונליות , יציב, עובד במספר ארגונים בישראל וכדאי לכל ארגון להתעניין בו.

בברכה,

עודד

ANST2

אני מפנה אתכם לאחד הפוסטים הראשונים שלי על כלי ה DEBUGGING המצוין בשם ANST-Automated Note Search:

ANST.

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

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

  1. כיסוי ליישומי פיורי + UI5.

עד היום התוכנית כיסתה בעיות בסוגים הבאים של תוכניות :

Transactions, Programs, BSP Application, Web Dynpro Application, Web Application Configuration, CRM BSP Frame, CRM Web client, CRM UI Frame

הכיסוי המלא של יישומי פיורי מורכב מאוחר ולא תמיד הפיורי מותקן בשרת ה ECC או ה S4. הוא יכול להיות מותקן ומופעל מGATEWAY   ולכן ה TRACE המלא נותן תמונה מלאה על כל תחנות הביניים.

  1. נוספו כלים לזיהוי קוד לקוח. אמנם המטרה המקורית של ANST היתה לאתר NOTES לתיקון הקוד של סאפ אבל יתכן שהתקלה או ה DUMP בעצם נובע מהקוד לקוח. שימו לב שגם לשם של היישום נוסף התיאור –                  “ Customer Code Detection Tool”

לשם כך נוסף CHECKBOX המציף את קוד הלקוח שמתגלה לאורך ה TRACE ואמצעי סינון אחרים.

ניתן גם להוסיף BREAKPOINTS דרך ה ANST לסייע ב DEBUGGING.

בקיצור הכלי מאוד השתכלל.

כאן הקישור של ההודעה

https://blogs.sap.com/2018/09/24/anst-support-sap-fiori-applications-and-other-enhancements/

בהצלחה,

עודד

 

 

 

Customizing Cookbook

נרחיב הפעם על הסוגיה של תיעוד הקיסטומים, נספר על 3 פתרונות וההמלצה שלי!

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

האפשרות של ציון הטבלה ב IMG שבו בוצע הקיסטום והכנסה שלו לעץ התהליכים ב SOLMAN איננה נותנת מידע רלוונטי שהרי לא מצוין שם מה היה התוכן. שמירה של הטרנספורט עצמו בעץ התהליכים אמנם יכולה לתת את התוכן הטכני (לאחר חפירה קצרה למי שיודע) אבל לא מעבר לכך.

IMG LOGGING

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

כדי להציג לוחצים על עכבר ימני בטבלת ה IMG ובוחרים Display change log.

אז אם זה כל כך טוב למה זה לא נפוץ ומקובל?

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

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

אני ממליץ לכולם לנסות!

להלן שני קישורים ל HELP של הנושא:

IMG Logging

Logging Customizing Objects

SAP Customizing Documentation Generation Tool

https://blogs.sap.com/2017/11/30/sap-customizing-documentation-generation-tool/

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

Customizing Cookbook

זוהי צורת התיעוד שאני ממליץ עליה , ללא קיצורי דרך.

הרעיון בא מצורת התיעוד של פעילות צוותי ה BASIS. למי שלא יודע הם מתעדים כמעט כל שדרוג או התקנה או פעולה מסובכת וטכנית עם הרבה שלבים באמצעות מסמך וורד או אקסל. פשוט כותבים במילים מה שמבצעים וגם משלבים צילומי מסך. נוצר מסמך טכני מפורט המסביר בדיוק איך פעלנו. עבור צוותי ה BASIS זה חשוב במיוחד כי הרי הם פועלים על פי מסמכי How to Guides והנחיות אחרות של סאפ, אבל תמיד תמיד ישנם מקרים מיוחדים לכל ארגון ואתר. ישנם טעויות, צריך ליישם NOTES, ישנם תיקונים וריצות מיוחדות שצריך לעשות ועוד ועוד. כך שה COOKBOOK של ה BASIS איננו מסמך כללי, הוא מסמך פרטני עבור הארגון הספציפי איך לבצע את השדרוג שוב.

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

להלן קטע מתוך אחד ה COOKBOOKS שלי.

תנסו ותצליחו!

עודד דגן

 

דוגמא וקטע מ COOKBOOK:

Added actions to be performed while saving to "In Mesira " E0016 status

IMG – "make settings for Change Transaction Types"

Erase actions not needed from E0004

COPY_ALL_ENH changed to COPY_ALL (no automatic imports)

Assign consistency checks to new status E0016 (copied from E0004)

Mail

Step 3.5 performed in SOLMAN_SETUP (activation of 2 CRM business function switches)

Mail Form –TEMPLATE created.

UI config

Added entries in table AGS_WORK_CUSTOM, used parameter UIC_PROC_TYPE_SPECIFIC

And added entries/indexes for

 UIC_PROC_TYPE_SPECIFIC_01 = AIC_CMCD_H/AICCMCDOverview_ZMMJ

UIC_PROC_TYPE_SPECIFIC_02 = AIC_CMCD_H/AICCMCDHeaderEF_ZMMJ