שלום!
גם את הפוסט הזה פירסמתי באנגלית באתר הבלוגים של סאפ :
Lite Task Management for SAP Projects with CHARM
מדובר כאן על ניהול משימות אפיון ופיתוה מפורטות מקושרות למסמכי שינוי ב CHARM. זה יכול לסייע רבות לארגונים שכבר יש להם CHARM או שעומדים לפני פרויקט פיתוח חדש.
בהצלחה!
עודד
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/
בברכה,
עודד דגן
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
בהצלחה!
עודד
בקרוב משתחררת מהדורה ראשית 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 בענן , בודק את כל התכונות החדשות ואת שיטת המעבר למהדורה החדשה.
בברכה,
עודד
הפעם נעסוק במשפחה של פתרונות תוכנה לתכנון וניהול הפרויקטים באגף מערכות המידע וניהול המשימות. בארגונים מוטי סאפ מקובל לשאול האם ישנם פתרונות לכך בתוך הסאפ ואם כן מדוע בכל זאת מקובל בישראל להשתמש בפתרונות חיצוניים. נגדיר את המושגים עצמם:
EPM – Enterprise Project Management עוסק בניהול הפרויקטים בארגון הגדול, מעקב משימות ותשומות.
PPM – Project Portfolio Management הינו הרחבה של ה EPM ועוסק גם בתכנון ובעיקר בתיעדוף ובחירת פרויקטים, משימות והערכה שלהם.
הארגונים הגדולים חייבים לנהל את הפרויקטים הרבים והגדולים המתרחשים אצלם הן מבחינה תקציבית ולוגיסטית והן תפעולית. המודול הבסיסי של סאפ לניהול פרויקטים , PS, הוא אמנם כבד ומסורבל לשימוש אך מתאים מאוד לארגונים הללו. ובאמת התעשיה האווירית, מע"ץ, הרכבת וחברת החשמל כולם משתמשים ב PS לניהול פרויקטי התשתית והפיתוח הגדולים שלהם. מדובר לפעמים על פרויקטים של מליארדי שקלים. לכן הפתרון של סאפ הנותן מענה מושלם לניהול הכספי (WBS ים) אך משלב את הניהול הלוגיסטי ואפילו תזמון הפעילויות וניהול גאנטים – עדיף. יש לו גם ממשק ל MS- Project שלפעמים משתמשים בו.
אך גם בארגונים הללו גופי ה IT לרוב אינם משתמשים ב PS למעט פתיחת WBS תקציבי כולל לכל פרויקט. מדוע ? כי הפרויקטים של IT הם לרוב קטנים יותר ונדרשים לגמישות רבה ושינויים תכופים ולכן ה PS גדול עליו.
בשוק הישראל ישנם כמה פתרונות החל מפיתוח מקומי וכלה בחבילות קטנות לניהול משימות ותקציבים. אבל ישנם גם חבילות שלמות העוסקות ב PPM ובראשם MSP (חבילה ישראלית), CLARITY ו MS- Project. הן נוחות יותר מה PS, הממשק למשתמש נחמד וגמיש ותומכות בעברית. אחת מהפונקציות העיקריות היא דיווחי שעות עבודה לפעילות. מאחר ומדובר על ארגונים עם יישם ופיתוח של סאפ – לרוב מקשרים בממשק את כלי ה PPM החיצוני עם ה CR ים (טרנספורטים) כדי לקבל עלויות בפועל של פיתוחים ופרויקטים.
מה עשתה סאפ בינתיים? היא אמנם הכירה בכך שה PS אינו עונה על דרישות השוק ל PPM ולכן בשנות ה 2000 קנתה פתרון מבוסס WEB והפכה אותו למוצר בשם xRPM אותו היא צירפה לפתרון ניהול פרויקטלי גמיש שהיה גם ב WEB בשם cProjects. המוצרים השלימו זה את זה ולבסוף חיברו אותם והיום קוראים לפתרון הכולל בשם PPM. בישראל משתמשים בו חברת החשמל וחברת מקורות והוא מאפשר להם לנהל את פורטפוליו הפרויקטים, לתעדף אותם ולקבל מבט ניהולי על כולם. ושוב – ללא גופי ה IT.
ועכשיו לעיקר. סאפ חשבה עלה צרכים הייחודיים של גופי ה IT והוסיפה את הPPM, בחינם , ל Solution Manager כבר בהשקת גירסה 7.1 שלו. אך זה היה מוחבא ולא נעשה בו שימוש. הוא גם לא היה מחובר לאף מודול אחר.
החל מ SP10 של SOLMAN הוקדשה מחשבה ייחודית לפרויקטי IT והפתרון נקרא ITPPM. ישנו חיבור עיקרי אחד למודולים של SOLMAN :
חיבור ה PPM ל CHARM – מאפשר חיבור כל דרישה ו CR במערכת (ב CHARM) למשימה ב PPM שניתן לתקצב , לדווח שעות ופעילות עליו ולקבל מידע ניהולי. דיווח השעות נעשה ב SOLMAN כך שלא צריך אפילו את ה CATS .
ITPPM
האם זה ישים ונח לשימוש? אני עצמי הפעלתי את ה PPM ב SOLMAN עם קצת מאמץ. כלומר הקמתי מספר פרויקטים, משימות, משאבים. מקבלים גאנטים וניהול זמן והממשק נח וחביב. אז למה לא להשתמש בו – ובחינם?
שלכם,
עודד
טרנספורטים – כולם מכירים אותם ומשתמשים בהם להעברת קיסטומים ופיתוחים בין הסביבות השונות. משתמשים ב SE10 וב STMS ומודעים לחשיבות סדר ההעברה ולסכנות של העברה לא מלאה, לא מסודרת ובעיות של תקלות שבדרך. בסה"כ הכלים הבסיסיים של בקרת התצורה של סאפ CTS – Change and Transport System הם די טובים ומספקים למקרים הפשוטים ולשימוש נמוך ובינוני.
אבל מה קורה כשיש כמות גדולה של טרנספורטים , למשל בפרויקט, או שישנם מספר גורמים מעורבים ונוצרים פקקים , קונפליקטים וטעויות? וודאי קרה לכם שהטרנספורט נוצר ריק, עבר שגוי, לא העביר מה שרצינו ולאן שרצינו וכו'. נעסוק הפעם בכלים להתמודד ולהקל על כך.
מתי להעביר לייצור? –ההעברה לייצור בזמן שמשתמשים מחוברים מהווה סיכון כי במקרה שהאובייקט המועבר מתנגש עם פעילות המשתמש – הוא יעוף באמצע הטרנזקציה (DUMP ) ויתכן גם שיאבד את הנתונים שהקליד. כמו כן תמיד ישנו סיכון של בג שלא התגלה בבדיקות ויתגלה רק בייצור.
ישנם מספר שיטות להעברה הנהוגות בארץ:
בסוף היום או בסוף השבוע – ההנחה כאן היא שנעביר כשיש כמה שפחות משתמשים כדי שלא יהיו התנגשויות ושיהיה זמן למיישמים לבדוק בייצור בשקט.
בתחילת יום או בתחילת השבוע – ההנחה כאן היא שבגלל הסיכוי הקטן של תעופה עדיף להעביר כשיש יותר משתמשים ואז אם מתגלה בג בייצור המיישמים והמפתחים זמינים ויוכלו לפתור. זה מתאים לארגונים שפחות בודקים ב QA. ישנם גם ארגונים המתאמים את ההעברה ליום ספציפי שהמיישם נמצא בו.
מי מעביר לייצור? – ישנה שונות גדולה בין הארגונים. הקו המנחה הוא שלאחר בדיקה ואישור המשתמש – אז המיישם האחראי יכול להעביר לייצור. לפעמים נותנים גם למפתחים או ל BASIS. אבל לאחרונה מקפידים בישראל לקיים את הנחיות ועדת גושן (הגרסה הישראלית לתקנות Sarbanes-Oxley האמריקאיות) ולבצע הפרדת תפקידים. כלומר האדם המבצע את השינוי צריך להיות שונה מהאדם המעביר את השינוי לייצור והמהלך הזה צריך להיות מתועד ובר הוכחה.
באופן טבעי הפתרונות הראשוניים היו פיתוחים עצמאיים ליצירת כלי בקרה וניטור משופרים. אני עצמי יישמתי פיתוח בשם ZSTMS בחח"י ובשטראוס שמעביר את הטרנספורט לעוד סביבות נוספות מעבר לנוף הסטנדרטי (transport domain). זה חשוב בפרויקט ובארגון עם מספר סביבות לצורך סינכרון הקיסטום. היום ישנם מספר ארגונים בישראל עם כלים מפיתוח עצמי : כלמוביל, חברת חשמל, יפאורה ועוד.
ישנם גם מספר כלי תוכנה שניתן לרכוש המסייעים בכך:
ה Object Manager– היה המוצר הוותיק ביותר שנתמך בארץ (ע"י נס בזמנו) של חברת IWAVE שנרכשה השנה ע"י EMC. המוצר מספק WF עם מספר תחנות להעברת הטרנספורטים בין הסביבות, הוא נוח וניתן בקלות להתאמה ללקוח. בנוסף יש לו תכונה של Rollback. כלומר לאחר העברת טרנספורט ניתן להתחרט ולמחוק אותו מהיעד. תכונה זו עובדת היטב אך מאוד מסוכנת! כי אתה עלול גם למחוק אוביקטים קשורים שהועברו בסמוך. סאפ בזמנו לא המליצה על Rollback אבל היום תומכת בגרסה מסוימת של זה דרך ה SOLMAN התומך ב Retrofit (על כך בפוסט אחר). מספר ארגונים בארץ משתמשים במוצר בשוטף.
ומה סאפ עושה בנידון? סאפ פיתחה וממשיכה לפתח את הפתרון לכל הנושאים הללו במסגרת המודול המיועד לכך ב Solution Manager שהוא :
CHARM – Change Request Management
המודול קיים מאז גרסה 7.0, פותח משמעותית ב 7.1 ונמצא בשימוש שוטף בטכניון, רכבת ישראל, מקורות, בזק, פז, נס (IT פנימי) ובבנק הבינלאומי הראשון.
המודול מלווה את כל מחזור החיים של בקשת השינוי (change request) שיכולה להיות בקשה לתהליך חדש, דוח או פיתוח או לנבוע מדיווח על תקלה . התקלה יכולה להגיעה ממערכת ה ITSM המחוברת ומסונכרנת עם ה CHARM. כפי שמתואר בשקף הבא יכולים להיות מספר תפקידים ותחנות אישור 
בדרך כאשר כל התהליך מלווה ב WF סטנדרטי של סאפ. לאחר אישור ה CR נוצר מסמך שינוי (change transaction) ולבסוף, עם ההחלטה לקסטם או לפתח נוצר טרנספורט אחד או יותר, הקשור לבקשת הלקוח. עם התקדמות הפיתוח, בדיקות והעברה לייצור, הלקוח מקבל דיווח שוטף והמעגל נסגר בסוף אצלו עם אישור שלו להעברה לייצור (שמתועד כמובן).
מסמך השינוי עובר מספר שלבים במחזור החיים שלו (פיתוח , בדיקות , העבר לייצור) וישנם מספר סוגים של מסמכים :
Normal Change – המטפל בשינוי סטנדרטי ומנוהל עם מחזור חיים מלא.
Urgent Change – המטפל בתקלות ייצור ולו מחזור חיים מקוצר.
לבקשות מנהליות ואחרות ישנם הסוגים – Administrative Change, General Change.
המודול תומך גם בנוף מערכות מורכב כגון Retrofit וגם ב CTS+ ועל כך בפוסט אחר.
ניתן לצרף למסמך השינוי מסמכים (אפיונים למשל), לקשור את התהליך העסקי המתאים מתוך עץ התהליכים ב SOLMAN וכן הפניה לבדיקות במודול הבדיקות והקמת תוכנית בדיקות מתאימה דרך ה BPCA. (ראו מה התקלקל? בדיקות רגרסיה )
לבסוף , ב CHARM ישנה תכונה מאוד שימושית להורדה דרסטית של כמות הטרנספורטים העוברים לייצור. כל מסמך שינוי פותח טרנספורט אב אחד ב DEV, הנמצא במצב Modifiable במשך כל מחזור החיים. תחתיו נפתחים עוד טרנספורטים מסוג Transport of Copies המשרתים את ההעברה ל QA, בדיקה, תיקון ב DEV ובדיקה חוזרת. רק כאשר השינוי נבדק כהלכה ומאושר סופית, רק אז טרנספורט האב מאושר, נסגר ומועבר ל QA ול PROD. תכונה זו בלעדית ל CHARM.
אשמח לסייע לכל מי שמעונין להכנס לנושא.
שלכם,
עודד
נמשיך לעסוק בבדיקות שאנו עורכים בארגון. והפעם בבדיקות יחידה. למעשה סדר הפוסטים היה צריך להיות הפוך אך הקדמתי לפרסם על רגרסיה לקראת הכנס על הנושא בסאפ ישראל ב 04.06.
בדיקות יחידה – בעולם פיתוח התוכנה הכוונה לבדיקת רכיב תוכנה בדיד וקטן. בתחום ה ERP הכוונה לבדיקה שמבצע המפתח והמיישם עצמו לפני בדיקות הקבלה של המשתמש ולפני בדיקות האינטגרציה של תהליכי רוחב.
ברור לכולנו שבודקים כל דבר שאנו משנים ומפתחים ואני בטוח שכמעט כולם היו בפרויקט הקמה או בפרויקט הוספה משמעותי שבו התקיימו בדיקות מערכת מסודרות. במסגרת זו מעורבת לרוב חברת בדיקות או לפחות קיימת מתודולוגיה סדורה של בדיקות, עם כלים , עם STP,STD, STR וכו'. על כך לא נפרט. אני רוצה להתיחס כאן בעיקר לבדיקות שאנו אמורים לבצע עבור העבודה השוטפת שלנו, תוספות, שינויים ועדכונים לסאפ.
כמה מאיתנו באמת מקפידים לבדוק כהלכה את כל הפיתוחים השוטפים ולהביא ללקוחות שלנו תוצרים איכותיים ונטולי תקלות?
מחזור תהליך השינוי והעדכון של תהליך מתחיל מהיוזמה והדרישה לשינוי ועובר דרך מסמך אפיון התהליך (Blueprint או CSD- Customer Specification Document) . אם יש פיתוח אז צריך להיות מסמך אפיון מפורט לפיתוח (המחולק לחלק פונקציונלי עבור הלקוח הדורש וחלק טכני עבור המפתח). בנוסף ובצמוד לשני אלה יש את מסמך תרחיש הבדיקות הקיים לצורך בדיקת התהליך כולו והפיתוח החדש בפרט. (אפרט על המסמכים בפוסט נפרד)
ועכשיו לאתגר העידכון והתחזוקה – נניח שיש לנו תהליך קיים שאנו רק משפרים ומעדכנים. מכאן שהמסמכים הללו כבר קיימים ואנחנו צריכים בעצם רק להוסיף את פירוט השינוי והתוספת לשלושת המסמכים. אחת השיטות הבדוקות לכך היא לעדכן את הטקסט הראשי, לשמור גירסה למסמך ובסוף המסמך לכתוב פרק של תוספות קלנדרי עם רצף השינויים בתהליך או בתרחיש בדיקה. העידכון של תרחיש הבדיקה בסמוך לעדכון מסמך האפיון יכול להבטיח בדיקה איכותית!
תרחיש הבדיקה – צריך לכלול את הצעדים המפורטים בבדיקה (מסכים , שדות קלט וכו'), את נתוני האב שיש להשתמש בהם – והתוצאות הצפויות. הוא צריך לכלול בדיקות חיוביות – מה צריך להתבצע, ובדיקות שליליות – מה צריך להכשל ולהוציא הודעות שגיאה. התרחיש צריך לקחת בחשבון את כלל האפשרויות לביצוע התהליך הנבדק ולכלול מספר תסריטים שונים ואת הנתונים המזינים אותם, למשל סוגי הזמנות שונים , סוגי מסמך וכו'.
ביצוע הבדיקה – הדרך הפשוטה היא כמובן להכנס למערכת ה QA, להריץ את הטרנזקציה עפ"י הנחיות תרחיש הבדיקה ולרשום את התוצאות במסמך אחר של התוצאות. מסמך התוצאות יכול להיות עותק של תרחיש הבדיקה עם מקום לרישום התוצאות, שם הבודק, תאריך וכו'. במקרה של תקלה יש לרשום את התקלה ולהעביר לפיתוח – עד לתיקון התקלה ולבדיקה החוזרת התקינה. לאחר בדיקת המפתח והמיישם יש את שלב בדיקות האינטגרציה – באם התהליך משלב מספר צוותים או מודולים. ולבסוף נרצה שהמשתמש שלנו יבדוק גם הוא , ייתן לבדיקה את הנופך המעשי שלו ויאשר.
מעבר לבדיקה ידנית ושימוש במסמכי וורד ואקסל הדרך היותר יעילה ומתוחכמת היא להשתמש בכלי בדיקה ייעודיים. שני הכלי הנפוצים העיקריים עבור סאפ בישראל הם:
HP Quality Center – נחשב לכלי הטוב מסוגו וגם עולה כך. במקור פותח על ידי חברת מרקורי הישראלית שנרכשה ע"י HP. ניתן לפרט בו את צעדי הבדיקות, תרחישים מפורטים, לבצע דרכו את הבדיקה עצמה ולחולל את דוח התוצאות – SPR. ניתן לרכוש ל QC אדפטור מיוחד הקושר אותו לעץ התהליכים ב SOLMAN ומסנכרן בין שני הכלים. בנוסף יש את ה QTP להקלטה ולביצוע בדיקות אוטומטיות. הרבה גופים גדולים בישראל עובדים עם QC , בין היתר מהסיבה שבודקים מערכות אחרות באמצעותו.
מודול הבדיקות ב Solution Manager – הוא גם כלי מצויין ושימושי (חינם). נטען עליו בעבר שהוא פחות שימושי מה QC אך מסתבר שגם לו יש יכולת לפרט צעדים בבדיקה , לשמור את התרחישים ולהוציא STR. ישנם מספר ארגונים המשתמשים בו בשוטף. ניתן לחבר אותו למודול שליחת ההודעות – Incident Management לצורך מעקב התיקונים והבדיקות החוזרות. שלבי בניית תוכניות הבדיקה וצירוף התרחישים נראים ככה:
ה Worklist לבודק נראה כך כאשר ישנה גם גרסה וובית.
.
.
.
.
.
שילוב כל תהליך בדיקות היחידה ב CHARM
בסוף נציג את הדובדבן שבקצפת. סאפ מציעה לכל ארגון לעבוד עם מודול ה CHARM (Change Request Management ) הממכן את כל תהליך דרישות הלקוח,
אישורים, יצירת טרנספורטים בדיקות והעברה בין הסביבות . ממש WF של תהליך הפיתוח. לכך ניתן להוסיף את שילוב חבילות הבדיקה המתאימות ממודול הבדיקות ב
SOLMAN וכמו כן הפעלת BPCA לצורך הכנת תוכנית בדיקות רגרסיה (ראה פוסט קודם). משמאל נראה תהלך פיתוח המשלב את בדיקות היחידה וגם את בדיקות הרגרסיה, עדכון המסמכים – והכל ב WF אחד רציף.
נראה עתידני אך בהחלט אפשרי! מה דעתכם?
עודד
הבלוג של עודד לקהילת הסאפ בישראל 