שלום!
גם את הפוסט הזה פירסמתי באנגלית באתר הבלוגים של סאפ :
Lite Task Management for SAP Projects with CHARM
מדובר כאן על ניהול משימות אפיון ופיתוה מפורטות מקושרות למסמכי שינוי ב CHARM. זה יכול לסייע רבות לארגונים שכבר יש להם CHARM או שעומדים לפני פרויקט פיתוח חדש.
בהצלחה!
עודד
נרחיב הפעם על מושגי יסוד בפרויקטי 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. לכן כדאי להתמקצע בכך ולהכיר היטב את כל ההיבטים של פרויקטים אלה.
בברכה,
עודד
הפעם ידידי עופר קוסקאס מפרסם רשומה על מודול שימושי ב 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
עופר קוסקאס
050-5665867
לעיתים אנו נדרשים להשוות קיסטום קיים בין שתי סביבות ולעיתים צריכים להעביר ערכים, טבלאות ותהליכים שלמים בין סביבות. נציג הפעם מספר כלים לבצע זאת. צורך זה מתעורר בפרויקטים של מיזוג או פירוק חברות שיש להן סאפ או כשמקימים סביבות חדשות . לכל ארגון כדאי להשוות את הקיסטום בין מערכות ה DEV, QA ו PRD כי למרות שהן אמורות להיות זהות, קורה לעיתים שקיימים הבדלים העלולים להשפיע לרעה על הפיתוח והבדיקות.
COMPARE & ADJUST
הכלי הפשוט והזמין ביותר נמצא כמעט בכל טבלת קיסטום ב IMG. הוא קיים בטבלאות פשוטות ובטבלאות מקוננות ומסובכות – רק ברמה התחתונה ביותר.
פותחים את הטבלה ב IMG ובוחרים בתפריט Utilities ואח"כ Adjustment. יפתח חלון כדי להכניס את שם ה RFC. יש להכין מראש RFC תקין ופועל לסביבת העבודה ( Client ) שאליה רוצים להשוות.
נפתח חלון המשווה את הרשומות בין שתי הטבלאות, L מייצג את סביבת המקור Logon, ו R מייצג את הסביבה הרחוקה Remote. כשלוחצים על הסמליל האחרון מימין נפתח Legend המסביר את תצוגת השורות. R מסמל שורות הנמצאות רק בטבלה המרוחקת, L – שורות רק במקור. MR ,ML מסמלים שורות עם מפתח זהה בשתי הסביבות וערכים שונים ב R וב L.
כאשר רוצים ממש להעביר ערכים ושורות מסביבה לסביבה ניתן לבצע Adjustment. מסמנים את השורה ולוחצים על Adjust בתפריט. מופיע חלון שבו נתן לבחור האם להעביר שורה – Entry, שדה – Field, או את כל הרשומות שסומנו – All.
פעולה זו מביאה את השורות שסומנו מהמערכת המרוחקת ושותלת אותם בטבלה בסביבה המקומית. בזמן השמירה נוצר כמובן טרנספורט.
יש לציין שפעולה זו מאוד מסוכנת שכן ניתן להעביר כמות גדולה של ערכי קיסטום ולכן יש לתת אותה רק למיישמים שיודעים היטב מה קורה בטבלאות הללו!
Customizing Cross System Viewer
מדובר בטרנזקציה SCU0 הנמצאת בתפריט הראשי של סאפ תחת Tools + Customizing והוא כלי מקיף להשוואת קיסטום.
ברמה התחתונה ביותר ניתן להשוות טבלה בודדת או מספר טבלאות, אם מכירים אותם, על ידי שימוש ב Radio Button של Customizing piece list/transport . נותנים שם למהלך ההשוואה ובוחרים את ה RFC הקיים לסביבה השניה. מקבלים חלון דומה לחלון של ה Adjust שתואר בסעיף הקודם.
לחילופין ניתן לבחור בכל הטבלאות של רכיב יישומי על ידי שימוש ב Radio Button של Chose Components. המערכת מקימה רשימה של כל הטבלאות הרלוונטיים, משווה אותם מול הסביבה המרוחקת ומפיקה את המסך הבא שבו ניתן לבחור טבלה ספציפית ולערוך השוואה פרטנית.
BCSETS
Business Configuration Sets הם יישות לאריזה והעברת תוכן טבלאות קיסטום ותהליכים שלמים שסאפ פיתחה במקור עבור פרויקטים גלובליים. לפרויקטים כאלה ה BCSETS מאפשרים להעתיק תהליכים עסקיים ומדיניות של חברת האם אל חברות בנות כולל חברות עם מערכות מבוזרות כלומר על שרתים אחרים. כך ניתן להעתיק ערכי קיסטום נעולים כך שלא ניתן לשנות אותם בחברות הבנות. כמו כן ניתן להחליף בהעברה ערכים של מבנים ארגוניים כגון קודי חברה, אתרים ומרכזי עלות.
ניתן לבנות BCSET מתוך ערכים של טבלת קיסטום אחת או יותר. ניתן לבנות אותה מערכים שבטרנספורטים. ניתן לבנות הירארכיה של BCSETS. כך ניתן למשל לארוז תהליך רכש שלם של ערכי טבלאות קיסטום של מק"טים, דרישות רכש והזמנות.
ניתן להעביר את ה BCSET מסביבה לסביבה על ידי יצוא ויבוא קובץ או על ידי טרנספורט מרוכז.
לאחר ההעברה יש לבצע אקטיבציה של ה BCSET ואז הערכים נכנסים לטבלאות בסביבת היעד. אם רוצים להחליף ערכי אתר , למשל, קופץ חלון ומכניסים את האתר החדש.
BCSETS נמצאים בשימוש נרחב בהטמעת פרויקטי BEST PRACTICES , INDUSTRY SOLUTIONS ובהעברת תהליכי SAP שלמים.
קורס SMI300 – BCSETS
שלכם,
עודד
טרנספורטים – כולם מכירים אותם ומשתמשים בהם להעברת קיסטומים ופיתוחים בין הסביבות השונות. משתמשים ב 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.
אשמח לסייע לכל מי שמעונין להכנס לנושא.
שלכם,
עודד
הבלוג של עודד לקהילת הסאפ בישראל 