BPMON

BPMON – Business Process and Interface Monitoring הוא מודול בSOLMAN  העוסק בניטור ובקרה של ממשקים ותהליכים עסקיים ומטרתו קודם לאתר ולאחר מכן לנטר תהליכים רגישים עם בעיות , תקלות ופערים, לייצב ולשפר אותם. ה Solution Manager המקושר לכל מערכות הסאפ (ECC, CRM, SRM  וכו') ומנטר גם את הממשקים, נמצא בלב הענינים ולכן יכול בקלות למלא את התפקיד.

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

מדדים  KPIs – המערכת מכילה כ 1000 מדדים של תהליכים עסקיים וממשקים העובדים OUT OF THE BOX בצורה קלה וישירה. הם לרוב מודדים תקלות ונפילות בממשקים ופערים ועיכובים קלסיים בתהליכים עסקיים. המדדים הללו באים למדוד חריגים תפעוליים כדי למצא את הסיבות והשורשים לחריגים ולשפר אותם. לעומתם המדדים שלרוב נמצאים בדוחות BW הם מדדים עסקיים , אסטרטגיים ותקופתיים הבאים למדוד יעילות עסקית ולהשליך על התפעול.

Key Figure Overview for BP Monitoring & BP Analytics

הKPI מופיעים באתר הבא המתעדכן תדירות

https://go.support.sap.com/kpicatalog

BPAI – Business Process Analytics and Improvement. זהו החלק הראשון של BPMON שתפקידו לאתר את הבעיות והפערים לרוחב הארגון כדי להמשיך ולנטר בחלק השני ה BPMON. בוחרים מספר מדדים, מפעילים אותם לאורך תקופת מבחן ובוחנים את התוצאות בחתכים של יחידה ארגונית, סוג מסמך וכו'. כך ניתן להגיע למקומות בארגון החורגים מהנורמות הרצויות. יש גם שירות הנקרא Business Process Analysis שניתן לקבל מסאפ דרך ה Enterprise Support המפיק דוח מקיף כזה דרך ה OSS ויכול גם הוא להוות התחלה של היישום. מכאן ניתן לעבור ל BPMON.

Business Process Improvement Wiki

 

 

BPMON – גם כאן משתמשים במדדים (בדיוק אותם מדדים שהיו ב BPAI !) אלא שהשימוש בהם הוא לניטור ומעקב קבועים ולכן הם מוקמים בחתך הספצפי הרצוי (למשל סוג מסמך בארגון רכש מסוים) ועם ערכי סף מסוימים של החריגים (Threshholds) שמעבר להם אנו רוצים לקבל התרעות.

Business Process Monitoring Wiki

התרעות – ALERTS

במשיכה ובצפיה

• במרכז ההתרעות ב SOLMAN של BPMON. דרך ההתרעות ניתן לבצע DRILL DOWN כדי להתחקות אחר המקורות והסיבות לחריגים.
• בדוחות ה BUSINESS PROCESSES- ב BPMON המדווחים על המדד כולו, גם כשהוא בסדר
• בדוחות BW למדד (עפ"י קוביות BW הנמצאות ב SOLMAN לצורך זה)
• דוחות גרפיים של מגמות (המטרה היא לצמצם את ממדי החריגים במשך הזמן)
• DASHBOARDS

בדחיפה

• שליחת התרעות בצורה של מיילים או הודעות SMS

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

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

 

בברכה,

עודד

סנכרון קסטומיזציה – Customizing Synchronization

הפעם ידידי עופר קוסקאס מפרסם רשומה על מודול שימושי ב SOLMAN העוסק בהשוואה והפצה של קסטומיזציה.

הצורך:

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

בשלב שדרוג מערכת – השוואת קסטומיזציה בין שתי מערכת SAP ECC מקורית למערכת משודרגת

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

הפצה של אובייקט קסטומיזציה משותפים בין שתי מערכות פיתוחSAP ERP ו SAP ECC למטרה אחרת (ביטוח, HR, בילינג וכו') או בין ECC ל CRM

הפתרון:

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

Customizing Scout – השוואת קסטומיזציה בין קליינטים/מערכות SAP/ רכיבי SAP. ה SCOUT מבוסס על אותו מנוע של ה SCU0- Customizing Cross System Viewer (ראה השוואת קיסטום ) בהבדל שהוא יכול לנתח מערכת שלמה ברקע בקלות.

Customizing Distribution – הפצת אוטומטית ראשונית ("Initial distribution") או עדכון שוטף ("Delta distribution") של אובייקט קסטומיזציה ממערכת פיתוח אחת למערכת פיתוח אחת או יותר. בכל פעם שאובייקט קסטומיזציה משתנה במערכת פיתוח מקורית מועבר השינוי באמצעות טרנספורט למערכת היעד.

תרשים של הפצה אוטומטי של קסטומיזציה

תוצרי הפתרון:

להפצה ראשונית של קונפיגורציה של טבלאות במהירות בין מערכות test באמצעות ("Initial distribution").

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

סנכרון קסטומיזציה בין מערכות SAP E/3, כבסיס להפצה של נתוני אב באמצעות ALE.

מימוש הפתרון:

הגדרת דרישות טכניות כולל:

הגדרת System Landscape של הלקוח

הגדרת פרויקט. פרויקט IMG וטרנספורטים במערכת המקור ובמערכות היעד.

הגדרת קסטומיזציה להפצה כולל:

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

מיפוי אובייקטי קסטומיזציה במערכת היעד במידת הצורך.

טעינת אובייקטי קסטומיזציה לסנכרון ממערכת היעד ל SAP Solution Manager

הגדרת קבוצת אובייקטי קסטומיזציה.

הגדרת תהליךהפצת קסטומיזציה.

מקורות:

Help – Customizing Synchronization 

עופר קוסקאס

Okoskas@gmail.com

050-5665867

CBTA – בדיקות אוטומטיות

Component Based Test Automation – CBTA הינו מודול הבדיקות האוטומטיות החדש ב SOLMAN. הכלי הוא מאוד שימושי ומאפשר הרצת בדיקות רגרסיה אוטומטיות על התהליכים העיקריים של הארגון ובכך להבטיח איתור תקלות יומיומי מלא. כזכור בדיקות יחידה הן בדיקת הפיתוח והתהליך החדש שאותו פיתחנו והוא קל יחסית וידוע (ראה בדיקות יחידה בשוטף ). האתגר הוא בבדיקת מה שקלקלנו – שהן בדיקות הרגרסיה  (ראה מה התקלקל? – בדיקות רגרסיה.) ה BPCA ימליץ על הבדיקות הללו שכוללות בדיקות ידניות ובדיקות אוטומטיות (CBTA) כאשר הוא כמובן יתעדף תמיד את האוטומטי.

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

גם ה QTP, כלי הבדיקות האוטומטיות של HP (מרקורי) אמנם עושה את העבודה אך יש לו את אותם חולשות של ה ECATT ודורש מומחיות ותחזוקה רבה. הוא גם עולה לא מעט בשעה שה CBTA הוא חינמי (עבור לקוחות Enterprise Support).

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

תכונות עיקריות

WIZARD  להקלטה המאפשר הקלטה פשוטה על ידי משתמש או מיישם.

GUI נתמכים: SAP GUI, SAP CRM Web Client, ABAP Web Dynpro (SP10), Java Web Dynpro (SP10), SAP NetWeaver Portal (SP10), SAP GUI for HTML (SP10), BSP (SP10), HTMLB (SP10)

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

LOG של הרצת הבדיקה כוללת צילומי מסך של כל קלט חדש.

system data container – SDC – מכוון את הכלי למערכת המוקלטת או הנבדקת , כלומר ניתן להפעיל את הבדיקה המוקלטת על מספר מערכות שונות.

test data container – TDC  – מכיל את הפרמטרים המוזנים לשדות בבדיקה. כאן אפשר לתחזק מספר רב של תרחישי בדיקה באמצעות גליון אקסל המכיל את כל נתוני הקלט עבור כל תרחיש.

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

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

הקלטת TBOM – במקביל לביצוע הבדיקה האוטומטית ניתן לקבוע שיוקלט ה TBOM . כך ניתן לחדש ולרענן את כל מערך ה TBOMS לטובת BPCA  מעודכן – ראה מה התקלקל? – בדיקות רגרסיה.

DEBUGGER – ניתן להריץ את הבדיקה באמצעות DEBUGGER מיוחד של ה CBTA ולאתר את מקור התקלות.

טיפים

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

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

מומלץ להכשיר מומחה להקלטות שיתן שירותים לכל יתר המיישמים ולאנשי הבדיקות.

התקנת ה CBTA , ההקלטות וביצוע הבדיקות אינם פשוטים כל כך אך המאמץ מאוד משתלם!

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

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

זהו להפעם,

עודד

 

EPM-PPM

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

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 עם קצת מאמץ. כלומר הקמתי מספר פרויקטים, משימות, משאבים. מקבלים גאנטים וניהול זמן והממשק נח וחביב. אז למה לא להשתמש בו – ובחינם?

שלכם,

עודד

 

 

פרויקט אג'ילי או מסורתי?

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

 ASAP

ASAP היא שיטת מפל המים (WATERFALL) מסורתית, כלומר לא מתחילים שלב חדש ללא סיום מוחלט ונקי של השלב הקודם.  המתודולוגיה קיימת משנת 1996 והיה אפילו כלי מבוסס PC  בשם הזה שבשנת 2003 הוחלף ב Solution Manager. עכשיו כדאי שלא נתבלבל – SOLMAN  הוא הכלי של סאפ לניהול יישומים ובקרה על המערכות בשעה ש ASAP היא המתודולוגיה ואיננה תלויה בכלי.

למרות שרבים מאיתנו עבדו בפרויקטי הקמה בשיטת ה ASAP , אחרי הפרויקט לרוב זונחים אותו ושוכחים. אבל ASAP  חי ונושם ומתעדכן כל הזמן. ישנן מהדורות ל HANA  ולכל הכלים החדשים. הוא נמצא ב SAPNET  בקישור הבא: ASAP     . הוא גם מתועד ב SOLMAN  בטרנזקציה של ROADMAP.

להזכירכם השלבים העיקריים הם: PREPARATION , BLUEPRINT , REALIZATION , GOLIVE PREPARATION , GOLIVE.

AGILE

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

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

להלן מאמר התומך בעמדה זו:

http://www.r3now.com/agile-software-development-for-sap-erp-projects/

AGILE ASAP

יש מושג כזה ולהלן הקישור אל התיעוד שלו.

https://websmp102.sap-ag.de/~sapidb/011000358700000661052013E/Index.htm

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

התפיסה האג'ילית מתאימה גם לשיטת הצגת פיילוטים עובדים – שיטת ה CRP .

CRP – Conference Room Pilot

מדובר בהדגמת תהליכים עובדים ללקוח בשלבים קריטיים בפרויקט. לרוב אחרי מעט מאוד קיסטום , אפילו כשבועיים שלושה, ניתן להדגים תהליכי סאפ עובדים. ללקוח שאיננו מכיר סאפ או להדגמת ישימות של מודול חדש הדגמה של תהליכים עובדים לפי דרישותיו ועם נתונים שלו היא הוכחה חזקה מאוד ואבן דרך משמעותית בפרויקט. ה CRP  הפך להיות פופולרי מאוד אצל האינטגרטורים בישראל בשנים האחרונות ויש המבצעים CRP1, CRP2 ולעיתים גם CRP3 במהלך חיי הפרויקט. CRP1 הוא המקבילה החדשה של מושג ה BASELINE  שהיה קיים בASAP  המקורי.

להלן מאמר מענין על יעלות CRP בפרויקטי סאפ. גם בחו"ל.

http://www.r3now.com/achieve-business-benefit-through-sap-prototype-demonstrations/

BEST PRACTICE

כולם ודאי מכירים את המושג ויודעים לפיכך שפרויקטי BEST PRACTICE  מבוססים על תהליכים עסקיים מקונפגים מראש הנטענים במערכת של הלקוח. לכן זה גם סוג של פרויקט אג'ילי שמדלגים על שלב האפיון המפורט, ה BLUEPRINT, ובמקומו מבצעים SCOPE VALIDATION בעזרת ה BP המותקן ונכנסים לשלב מימוש קצר ומרוכז. השאיפה היא שלא לפתח בכלל ולהצמד לתהליכים המקוריים. היו בישראל כבר כמה פרויקטים כאלה מאוד קצרים כאשר תוך 4 חודשים עלו לאוויר עם היישום. המפתח להצלחה כאן הוא הצמדות מלאה לתכולה המוסכמת המקורית ולתהליכים שבחבילת ה BP. הסכנה היא בפרויקטים שלוקחים BP  כבסיס לפרויקט גדול יותר. הטעות הנפוצה היא שגם אז מדלגים על שלב האפיון המפורט ומאבדים שליטה על התכולה ועל יתר הפיתוחים והתהליכים.

RDS – RAPID DEPLOYMENT SOLUTIONS

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

אז בהצלחה לכולם גם בשיטות אג'יליות וגם בשיטות המסורתיות!

עודד

ה CHARM של הטרנספורטים

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

נראה עתידני אך בהחלט אפשרי! מה דעתכם?

עודד

מה התקלקל ? – בדיקות רגרסיה

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

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

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

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

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

השאלה המרכזית בבדיקות רגרסיה היא מה לבדוק?

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

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

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

Service/Support Pack – שהוא אוסף צבור של מאות Notes, ולרוב משפיע ויכול לקלקל הרבה תהליכים יציבים, אך גם לתקן הרבה, נושא איתו סיכון רב בגלל חוסר הידיעה על איזורי ההשפעה. מסיבה זו ארגונים רבים נמנעים מהתקנה תקופתית של SP, ובכך נאלצים לחפש ולהתקין Notes בודדים בכל פעם שיש תקלת סאפ – דבר שניתן למנוע ע"י התקנת SP  תקופתית. סאפ ממליצה להתקין בכל רבעון SP.

Enhancement Package – שדרוג גירסה, שינויים ותוספות רבות. דורש בדיקות רגרסיה רחבות.

Business Package – שהוא חלק מ ENHP- אקטיבציה שלו גם עשויה לקלקל תהליכים קיימים.

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

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

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

CDMC – Custom Development Management Cockpit– מבצע מיפוי וניתוח אובייקטי פיתוח של הלקוח במערכות הקיימות (פיתוחי Z+Y). המיפוי מבוסס על השימוש בפועל במערכת לפי הסטטיסטיקה הנאספת ב ST03N בייצור. יש לו שתי צורות הפעלה:

• Clearing Analysis – לבחינה שוטפת של קוד מיותר, טבלאות שלא בשימוש ועוד – כדי למחוק אותם שלא יפריעו בשוטף ובשדרוגים.
• Upgrade Change Impact Analysis–  בפרויקט שדרוג המערכת משווה את האובייקטים שהשתנו בשדרוג מול האובייקטים המושפעים מהפיתוחים בארגון וממליצה אילו אובייקטים לבחון לתיקון (תוכניות, טבלאות וכו') ובאילו טרנזקציות.

BPCA – Business Process Change Analyzer– ניתוח תהליכים עסקיים / טרנסקציות עיקריות שהושפעו משינויים במערכות סאפ (ENHP, SP, BP, Notes, Transports). הבסיס לניתוח נוצר ע"י הקלטה מראש של הטרנזקציות / תוכניות הקריטיות לתוך TBOM –  Technical BOM המכיל את כל האובייקטים הטכניים של הטרנזקציה. המודול משווה בין ה TBOMS שהוקלטו לבין האובייקטים שהשתנו במערכת ונותנת המלצה והצבעה על התהליכים והטרנזקציות שיש לבדוק. כדי לבצע ניהול סיכונים סביר ולא לבדוק יותר מדי מופעל כלי אופטימיזציה שבעזרתו ניתן להתמקד ב 30%-40% מכלל הטרנזקציות הקריטיות.

מי בודק בדיקות רגרסיה?

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

מיישמים/מפתחים – בודקים כמובן בדיקות יחידה אך ברוב הארגונים גם בודקים בדיקות קבלה עיקריות, מלבד בדיקות משתמשים (UAT – User Acceptance Tests) ייעודיות .

משתמשי מפתח / רכזי מיחשוב – יש ארגונים בהם משתמשי המפתח הם הבודקים העיקריים.

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

ב 4 ביוני , סאפ ישראל מארחת את מנהל המוצר ,BPCA מר Rajeev Gollapudi, לכנס הסברה על חידושי ה BPCA כולל הקלטות אוטומטיות עם QTP. להלן הקישור להרשמה:

http://www.eventbrite.com/event/6238953879#

יש כבר נסיון מצטבר בארץ בשימוש במודולים אלה. לקוחות שנעזרו במודולים האלה – רכבת ישראל, עיריית תל אביב, מקורות, שטראוס, שסטוביץ, חברת חשמל ועוד. לדוגמה בפרויקט התקנת 4 SP שטראוס בדקה 60 תהליכים במקום 200, בפרויקט שדרוג נרחב, שסטוביץ בדקה 230 טרנזקציות במקום  600.

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

עודד