תגית: ACTIVATE

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

בהצלחה!

עודד

Reimplementation

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

סיבות למעבר ל S4

נוכח התאריך המתקרב והשיווק לטובת המעבר למערכת S4HANA רוב הארגונים כבר שוקלים וחושבים על מעבר זה. יש לכך כמה סיבות:

  • כדאיות שימושית – זו כמובן הסיבה העיקרית המקדמת את S4HANA. הטענה העיקרית היא פישוט, SIMPLIFICATION, של בסיס הנתונים, של תחזוקת המערכת ושל התהליכים העיסקיים. המערכת מהירה יותר בגלל ה HANA ובעלת פונקציונליות משופרת ברוב המקרים. כדאי לבחון את זה לעומק ורצוי עם גורמים בלתי תלויים.
  • כדאיות כספית – ישנה הוצאה לא גדולה לרכישת רשיונות S4HANA וכמו כן חומרה חדשה עם זכרון מוגדל שיכול לסחוב את ה HANA אך מאידך ישנם גם חסכונות בגודל בסיס הנתונים ובפישוט מורכבות ושכבות במערכת. על זה יש להוסיף את עלות הפרויקט שהיא ההוצאה הגדולה ביותר אך קשה מאוד להערכה.
  • תאריך יעד – התאריך המוכרז של סוף החיים של מערכת ה ECC (דצמבר 2024) מכניס אותנו למסלול החלטה של איתור המועד הכי כדאי לעבור למערכת החדשה. כי למרות הזמן הרב- לא רוצים להכנס ללחץ זמן כי ההתארגנות והפרויקט יערכו זמן רב. אבל האם התאריך הזה הוא ממשי? חל כרסום באמינות של התאריך בעיקר נוכח הקצב האיטי מאוד של מעבר לקוחות ECC ל S4HANA. (בארץ עוד אין ובחול מספר קטן ביותר). ישנן שמועות האומרות כי התאריך ידחה ל 2030. ישנם ארגונים שאין להם הרבה פיתוחים והם אומרים לעצמם שיוכלו לוותר על התמיכה של סאפ לאחר 2025 ולהשאר ב ECC. אך עדיין רוב הארגונים מתייחסים לתאריך ברצינות וחושבים על המעבר.

חלופות המעבר ל S4

לקוח חדש

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

לקוח קיים

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

  1. הקמת מערכת חדשה

מקימים מערכת S4HANA וונילה וחדשה לגמרי , בוחנים ומנתחים את התהליכים החדשים שהיא מציעה , מקסטמים, מבצעים פיתוחים חדשים שיכסו את רוב הפיתוחים והפנוקציונליות שהיו ב ECC ומבצעים הגירת נתונים כללית. זהו למעשה פרויקט הקמה חדש כאשר S4 היא מערכת ה ERP ו ה ECC היא מערכת ה LEGACY. כמו כל פרויקט ERP עדיף בשיטת BIG BANG  כי המעבר בשלבים כרוך בממשקי ביניים רבים, מסובכים ויקרים. זהו בעצם פרויקט REIMPLEMENTATION  שנפרט עליו בהמשך.

2.  הגירה מ system conversion – ECC

קיימת תורה סדורה של מתודולוגית הפרויקט שסקרתי בפוסט ACTIVATE. סאפ השקיעו הרבה בכלים להגירה מ ECC ל S4HANA. אחרי שמבצעים את כל התקנות החומרה והתוכנה , האתגר הכי גדול הוא העברת כל הפיתוחים הקיימים למערכת החדשה או מציאת חלופות במערכת. לצורך כך יש לסאפ קובץ בו רשומים כל ההבדלים בין ECC ל S4HANA וניתן להתרשם מכמות השינויים וגודלם: Simplification List.

simplification list blog – מסביר איך להתיחס לרשימה ולעבוד איתה.

השינויים הכי גדולים וידועים הם איחוד הקבצים של מודול FI ו CO וביטול לקוחות וספקים ושימוש ב BP – Business Partners. מודול ה HCM אמנם נתמך אך לא יתפתח מאחר וה Success Factors הוא הפתרון הנתמך ל משאבי אנוש . וישנם עוד עשרות.

  1. קונסולידציה – Landscape Transformation

זהו גם פרויקט הגירה אך מיועד לאיחוד וקונסולידציה של כל מערכות ה ECC (ואחרות) שהיו במקביל בארגון. ה S4 כולל בתוכו פונקציונליות שקיימת במערכות SRM, APO, EWM  ואחרות.

התאמת קוד הלקוח

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

ישנם כמה פעולות הכנה שיש לבצע המתוארים בבלוג הבא:

custom code adoption process blog

כדי לחדד יותר סאפ יצאו לאחרונה עם תוכנית ייעודית שנקראת Readiness Check :

2290622 – SAP Readiness Check for SAP S/4HANA

ניתן להריץ את התוכנית ב ECC או דרך SOLMAN וכאשר מסתכלים על תוצאות הריצה בהיבט של ה Custom Code, מקבלים ספירה של אובייקטי הפיתוח הקיימים והמלצות כלליות בלבד על איך לבצע Simplification. יש הבהרות על שינויים ב SYNTAX ובחוקיות הקוד אך הניתוח הפונקציונלי הוא באחריותינו.

להלן דוגמא לתוצאות:

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

REIMPLEMENTATION

כאן נכנס השיקול והכדאיות של יישום מחדש של תהליכים – ReImplementation.

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

הערה – לארגון עם תיעוד מסודר של הפיתוחים / אפיונים ועץ תהליכים מסודר יש יתרון מובהק בהערכת עלות היישום מחדש. סאפ ממליצה על שימוש מוגבר בסט הכלים שב Solution Manager  להערכת עלות המעבר ולניהול הפרויקט. החל מ 1.1.17 כל הפרויקטים שהתחילו בהובלת סאפ משתמשים ב SOLMAN 7.2 בעצמם.

בברכה,

עודד דגן