שדרוג ועדכוני גרסה ב־SAP: המדריך המעשי לתכנון וביצוע בדיקות

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

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

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

במאמר זה נציג מתודולוגיה מעשית לבניית תוכנית בדיקות לשדרוג SAP, כולל סוגי הבדיקות, סדרי עדיפויות, ניהול תקלות, קריטריוני Go/No-Go והפעולות החשובות לאחר העלייה לאוויר.

למה שדרוג SAP דורש תוכנית בדיקות מיוחדת?

במערכת SAP קיימת תלות גבוהה בין רכיבים ותהליכים.

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

לכן, בדיקה נקודתית של הפונקציה ששונתה אינה מספיקה.

המטרה של בדיקות שדרוג היא לענות על מספר שאלות:

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

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

---

שדרוג SAP לעומת עדכון SAP

לפני בניית תוכנית הבדיקות חשוב להגדיר מה בדיוק משתנה.

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

עדכון גרסה

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

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

שדרוג משמעותי

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

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

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

לכן, השלב הראשון הוא לבצע Impact Analysis.

---

שלב ראשון: Impact Analysis לפני תחילת הבדיקות

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

במקום זאת, יש לבצע ניתוח השפעה.

יש למפות לפחות את הרכיבים הבאים:

1. מודולי SAP

לדוגמה:

• FI
• CO
• MM
• SD
• HR
• PM
• WM
• PP
• CRM
• רכיבים ייעודיים לארגון

2. פיתוחים מותאמים

יש לזהות:

• תוכניות ABAP.
• User Exits.
• BAdIs.
• Enhancements.
• Reports.
• Forms.
• Workflows.
• פונקציות ייעודיות.
• הרחבות של SAP.

3. ממשקים

יש למפות את כל המערכות שמקבלות מידע מ־SAP או מעבירות אליו מידע.

לדוגמה:

• בנקים.
• מערכות CRM.
• מערכות ביטוח.
• מערכות שכר.
• מערכות BI.
• מחסנים.
• אתרי אינטרנט.
• מערכות ממשלתיות.
• ספקים חיצוניים.

4. עבודות רקע

חשוב לבדוק גם:

• Jobs.
• Scheduling.
• Batch processing.
• ממשקים ליליים.
• תהליכים אוטומטיים.
• משימות מתוזמנות.

תהליך שאינו מופעל באופן ידני על ידי משתמש עדיין חייב להיבדק.

---

בניית תוכנית בדיקות לשדרוג SAP

תוכנית הבדיקות צריכה להגדיר מראש:

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

מומלץ לבנות את תוכנית הבדיקות במספר שכבות.

שכבה ראשונה – בדיקות טכניות

בדיקות שמטרתן לוודא שהמערכת עצמה תקינה.

לדוגמה:

• Login.
• זמינות שרתים.
• זמינות שירותים.
• חיבורי Database.
• Batch Jobs.
• Queues.
• Dumps.
• Logs.
• הרשאות בסיסיות.
• זמינות ממשקים.

שכבה שנייה – בדיקות פונקציונליות

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

שכבה שלישית – בדיקות End-to-End

בדיקות של תהליך מלא מתחילתו ועד סופו.

לדוגמה:

לקוח → הזמנה → אספקה → חשבונית → הנהלת חשבונות → גבייה.

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

למי שרוצה להעמיק בנושא, ניתן לקרוא גם את המדריך באתר על בדיקות E2E ובדיקות מקצה לקצה.

---

בדיקות רגרסיה ב־SAP

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

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

זו נקודה קריטית:

לא צריך לבדוק רק את מה ששונה. צריך לבדוק גם את מה שעלול להיפגע בגלל השינוי.

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

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

לרקע נוסף ניתן לעיין ב־המדריך המלא לבדיקות מערכות SAP מקצה לקצה.

---

איך בוחרים מה להכניס לרגרסיה?

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

לכן מומלץ לבצע דירוג סיכונים.

לדוגמה:

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

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

---

בדיקות ממשקים לאחר שדרוג SAP

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

הסיבה פשוטה: מערכת SAP אינה פועלת בבידוד.

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

יש לבדוק:

• שליחת מידע.
• קבלת מידע.
• מבנה הודעות.
• שדות חובה.
• קידוד.
• פורמטים.
• קבצים.
• API.
• IDoc.
• RFC.
• Web Services.
• תורי מידע.
• זמני עיבוד.
• טיפול בשגיאות.

חשוב לבצע גם בדיקת Negative Testing.

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

---

בדיקות נתונים לאחר שדרוג

אחת הבדיקות החשובות ביותר היא Data Validation.

מערכת יכולה לעלות ללא שגיאה טכנית, אך הנתונים שבתוכה עלולים להיות שגויים.

יש להשוות נתונים לפני ואחרי השדרוג.

לדוגמה:

• מספר לקוחות.
• מספר ספקים.
• יתרות חשבונאיות.
• יתרות מלאי.
• מסמכים פתוחים.
• הזמנות פתוחות.
• חשבוניות.
• נתוני עובדים.
• נתוני Master Data.

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

ניתן להגדיר שאילתות, דוחות וספירות אוטומטיות שמאפשרות לבצע Validation בצורה יעילה.

---

בדיקות הרשאות ואבטחה

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

לכן יש לבדוק:

• משתמשים.
• Roles.
• Authorization Objects.
• גישה לטרנזקציות.
• גישה לדוחות.
• הפרדת תפקידים.
• גישה לנתונים רגישים.
• משתמשים טכניים.
• ממשקים המשתמשים בחשבונות שירות.

חשוב לבצע בדיקה בשני הכיוונים:

מה המשתמש צריך להיות מסוגל לעשות?

וגם:

מה המשתמש לא צריך להיות מסוגל לעשות?

---

בדיקות ביצועים לאחר השדרוג

שיפור גרסה אינו בהכרח שיפור ביצועים.

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

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

לדוגמה:

• זמן פתיחת מסך.
• זמן הרצת דוח.
• זמן יצירת מסמך.
• זמן עיבוד Batch.
• זמן העברת ממשק.
• זמני Response.
• עומס על Database.

במערכות גדולות מומלץ לשמור Baseline לפני השדרוג כדי שיהיה ניתן להשוות את התוצאות לאחריו.

---

בדיקות משתמשים – UAT

גם אם צוות ה־QA השלים את הבדיקות, אין משמעות הדבר שהמערכת מוכנה בהכרח לייצור.

משתמשים עסקיים צריכים לבצע UAT – User Acceptance Testing.

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

מומלץ לבחור משתמשים מרכזיים מכל תחום עסקי.

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

לדוגמה:

יצירת לקוח → יצירת הזמנה → אספקה → הפקת חשבונית → רישום חשבונאי → הפקת דוח.

ה־UAT צריך להסתיים באישור עסקי מתועד.

---

בדיקות שדרוג SAP לפי שלבי הפרויקט

תהליך מסודר יכול להיראות כך:

שלב 1 – לפני השדרוג

• ניתוח השינויים.
• Impact Analysis.
• מיפוי תהליכים.
• מיפוי ממשקים.
• זיהוי פיתוחים.
• זיהוי תהליכים קריטיים.
• בניית תוכנית בדיקות.
• הגדרת קריטריוני הצלחה.
• הכנת נתוני בדיקה.

שלב 2 – לאחר התקנת הגרסה בסביבת בדיקות

• Smoke Test.
• בדיקות טכניות.
• בדיקת Login.
• בדיקת הרשאות.
• בדיקת Jobs.
• בדיקת ממשקים בסיסית.

ניתן לקרוא גם את המדריך לבדיקות SAP לפני עלייה לאוויר – צ'קליסט מלא ל־Go Live.

שלב 3 – בדיקות פונקציונליות

• תהליכים עסקיים.
• מודולים.
• פיתוחים.
• דוחות.
• Forms.
• Workflows.

שלב 4 – בדיקות אינטגרציה

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

שלב 5 – רגרסיה

הרצת תהליכים מרכזיים שהוגדרו מראש.

שלב 6 – UAT

אישור המשתמשים העסקיים.

שלב 7 – בדיקות Pre-Go Live

הרצת צ'קליסט מלא לפני המעבר.

שלב 8 – Production Validation

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

---

Smoke Test לאחר השדרוג

אחת הטעויות היא להתחיל מיד בבדיקות מורכבות.

קודם צריך לבצע Smoke Test.

המטרה היא לענות על השאלה:

האם המערכת מספיק יציבה כדי להתחיל את הבדיקות?

Smoke Test יכול לכלול:

• התחברות.
• פתיחת מסכים מרכזיים.
• יצירת מסמך בסיסי.
• חיפוש נתונים.
• הרצת דוח מרכזי.
• בדיקת הרשאה.
• בדיקת ממשק מרכזי.

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

---

ניהול תקלות בפרויקט שדרוג

בפרויקט שדרוג SAP עלולות להיפתח מאות תקלות.

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

מומלץ להגדיר Severity ברור.

Severity 1 – קריטי

התהליך העסקי המרכזי אינו יכול להתבצע.

Severity 2 – גבוה

קיימת פגיעה משמעותית, אך קיים פתרון חלופי או שהפגיעה מוגבלת.

Severity 3 – בינוני

תקלה שאינה מונעת את העבודה המרכזית.

Severity 4 – נמוך

בעיה קוסמטית או שיפור שאינו חיוני ל־Go Live.

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

---

קריטריוני Go / No-Go

אסור לקבל החלטה על עלייה לייצור רק על בסיס המשפט:

"סיימנו את כל הבדיקות."

צריך להגדיר קריטריונים ברורים.

לדוגמה:

Go

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

No-Go

יש לשקול עצירת העלייה כאשר:

• תהליך עסקי קריטי אינו עובד.
• נתונים אינם אמינים.
• ממשק קריטי נכשל.
• קיימת תקלה ללא Workaround.
• אין אפשרות לבצע Rollback במקרה הצורך.
• צוותי התמיכה אינם מוכנים.

---

בדיקות לאחר Go Live

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

להפך.

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

יש לבצע Production Validation.

לדוגמה:

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

בנוסף, כדאי לעקוב אחר:

• Dumps.
• Logs.
• Failed Jobs.
• Queues.
• שגיאות ממשקים.
• פניות משתמשים.
• זמני תגובה.

---

Hypercare לאחר השדרוג

מומלץ להגדיר תקופת Hypercare.

במהלך תקופה זו צוותי SAP, תשתיות, QA, פיתוח ונציגים עסקיים זמינים לטיפול מהיר בתקלות.

כדאי להגדיר מראש:

• שעות פעילות.
• אנשי קשר.
• SLA.
• ערוץ דיווח.
• סדר עדיפויות.
• תהליך Escalation.
• גורם שמקבל החלטות.

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

---

האם כדאי לבצע אוטומציה בבדיקות SAP?

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

אבל לא נכון להפוך כל תרחיש לאוטומטי.

כדאי להתחיל מתהליכים:

• קריטיים.
• חוזרים על עצמם.
• יציבים.
• בעלי ערך עסקי גבוה.
• בעלי מספר רב של שלבים.

במקביל, תרחישים שמשתנים לעיתים קרובות או דורשים שיקול דעת אנושי עשויים להתאים יותר לבדיקה ידנית.

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

---

שימוש ב־E2E בבדיקות SAP

בדיקות E2E חשובות במיוחד במערכות ERP.

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

לדוגמה:

Order to Cash

הזמנה → אספקה → חשבונית → הנהלת חשבונות → גבייה.

או:

Procure to Pay

דרישת רכש → הזמנה → קבלת סחורה → חשבונית ספק → תשלום.

בדיקת כל שלב בנפרד אינה מספיקה.

צריך לוודא שהמידע עובר נכון בין כל שלבי התהליך.

---

צ'קליסט מעשי לשדרוג SAP

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

תכנון

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

הכנת בדיקות

• נבנתה תוכנית בדיקות.
• נכתבו תרחישים.
• הוכנו נתוני בדיקה.
• הוגדרו קריטריוני הצלחה.
• הוגדרו Severity ו־Priority.

ביצוע

• Smoke Test.
• בדיקות פונקציונליות.
• בדיקות אינטגרציה.
• בדיקות רגרסיה.
• בדיקות הרשאות.
• בדיקות נתונים.
• בדיקות ביצועים.
• UAT.

Go Live

• אין תקלות קריטיות פתוחות.
• הממשקים הקריטיים תקינים.
• הנתונים אומתו.
• המשתמשים אישרו.
• קיימת תוכנית Rollback.
• צוות התמיכה זמין.

לאחר העלייה

• Production Validation.
• ניטור Jobs.
• ניטור ממשקים.
• בדיקת Logs.
• מעקב אחר תקלות משתמשים.
• Hypercare.
• סיכום Lessons Learned.

---

הטעויות הנפוצות ביותר בבדיקות שדרוג SAP

טעות 1: בודקים רק את מה ששונה

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

טעות 2: מתמקדים במסכים

מערכת SAP היא מערכת של תהליכים, לא רק אוסף מסכים.

טעות 3: לא בודקים ממשקים

ממשק יכול להפסיק לעבוד גם כאשר SAP עצמה עולה ללא בעיה.

טעות 4: מתחילים בדיקות לפני Smoke Test

אם הסביבה אינה יציבה, תוצאות הבדיקות עלולות להיות מטעות.

טעות 5: לא מבצעים Data Validation

מערכת יכולה להיות זמינה ועדיין להכיל נתונים שגויים.

טעות 6: UAT מאוחר מדי

אם המשתמשים העסקיים מתחילים לבדוק רק ערב Go Live, אין מספיק זמן לטיפול בתקלות.

טעות 7: אין קריטריוני No-Go

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

טעות 8: לא בודקים לאחר Go Live

הצלחה בסביבת QA אינה מבטיחה שהכול יעבוד בייצור.

---

איך להפוך את תהליך הבדיקות ליעיל יותר?

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

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

במקום לשאול:

"כמה בדיקות ביצענו?"

עדיף לשאול:

"האם בדקנו את הדברים שהכשל שלהם יפגע הכי הרבה בארגון?"

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

ניתן להשתמש במודל פשוט:

סיכון = הסתברות לכשל × השפעה עסקית

תהליך עם השפעה עסקית גבוהה והסתברות גבוהה לכשל צריך לקבל עדיפות עליונה.

---

שילוב QA, צוות SAP והמשתמשים העסקיים

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

QA

אחראי על המתודולוגיה, תכנון הבדיקות, תיעוד, ניהול תקלות ומעקב אחר איכות.

צוות SAP

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

הגורם העסקי

יודע האם המערכת באמת מאפשרת לארגון לבצע את העבודה.

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

---

סיכום

שדרוג SAP אינו מסתיים בהתקנת גרסה חדשה.

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

לכן תוכנית בדיקות טובה צריכה להתחיל עוד לפני השדרוג ולכלול:

Impact Analysis → תכנון → Smoke Test → בדיקות פונקציונליות → אינטגרציה → רגרסיה → Data Validation → הרשאות → ביצועים → UAT → Go/No-Go → Production Validation → Hypercare.

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

כאשר משלבים תכנון מוקדם, בדיקות מבוססות סיכון, בדיקות End-to-End, רגרסיה, בדיקות ממשקים ואימות נתונים – ניתן להפחית משמעותית את הסיכון הכרוך בשדרוג ולהגיע ל־Go Live עם רמת ביטחון גבוהה יותר.

למאמרים משלימים מומלץ לקרוא גם את בדיקות תוכנה במהלך שדרוג ועדכוני גרסה ב־SAP ול־המדריך המעשי לבדיקת מערכות SAP.

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

קורס לבדיקות תוכנה מדויק

לעבוד מהבית כבודק תוכנה עם FIVERR >> לחץ כאן