בדיקות S/4HANA: המדריך לבדיקות לפני ואחרי מעבר למערכת

מה זה S/4HANA ולמה הבדיקות במעבר אליו מורכבות?

SAP S/4HANA היא הדור החדש של מערכת ה-ERP של SAP, המבוססת על בסיס הנתונים SAP HANA ומביאה איתה שינויים משמעותיים בארכיטקטורה, במודל הנתונים, בממשק המשתמש ובחלק מהתהליכים העסקיים.

כאשר ארגון עובר ממערכת SAP קיימת ל-S/4HANA, צוות ה-QA אינו יכול להסתפק בבדיקה שהמערכת "עולה". צריך לוודא שהתהליכים העסקיים החשובים ממשיכים לעבוד, שהנתונים עברו בצורה תקינה, שהממשקים ממשיכים להעביר מידע, שהרשאות המשתמשים נשמרו וששינויים שבוצעו במהלך המיגרציה לא יצרו תקלות נסתרות.

לכן, בדיקות S/4HANA צריכות להתחיל הרבה לפני יום ה-Go Live ולהמשיך גם לאחר שהמערכת החדשה כבר נמצאת בשימוש.

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

העיקרון החשוב ביותר: לא בודקים רק את S/4HANA, בודקים את העסק

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

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

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

מתי מתחילות בדיקות S/4HANA?

בדיקות איכותיות צריכות להתחיל כבר בשלבי התכנון וההכנה של הפרויקט. ככל שמחכים לשלב ה-UAT או לימים שלפני ה-Go Live, האפשרויות לתקן בעיות מורכבות מצטמצמות.

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

שלב	מטרת הבדיקה
הכנה	זיהוי תהליכים, מערכות, ממשקים, נתונים וסיכונים
בדיקות טכניות	וידוא שהמערכת והרכיבים המרכזיים פועלים
בדיקות פונקציונליות	בדיקת תהליכים עסקיים ומודולים
אינטגרציה	בדיקת זרימת מידע בין S/4HANA למערכות אחרות
רגרסיה	וידוא שתהליכים קיימים לא נפגעו
UAT	אישור התהליכים על ידי המשתמשים העסקיים
Post Go Live	בדיקת המערכת והעסק לאחר המעבר

1. בדיקות Baseline לפני המעבר

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

בשלב זה יש לתעד תהליכים קריטיים ולבצע עליהם בדיקות במערכת הקיימת. לדוגמה:

• Order to Cash
• Procure to Pay
• Record to Report
• Plan to Produce
• ניהול מלאי
• רכש
• מכירות
• חשבוניות
• תשלומים
• דוחות פיננסיים
• ממשקים למערכות חיצוניות

התוצאות משמשות לאחר מכן כנקודת השוואה למערכת S/4HANA.

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

2. בדיקות התאמה בין ECC ל-S/4HANA

במעבר ל-S/4HANA לא נכון להניח שכל מה שהיה קיים ב-ECC יפעל בדיוק באותה צורה.

יש לבדוק מה השתנה ברמת:

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

לכל תהליך קריטי מומלץ להגדיר מראש מה מצופה לקבל ב-S/4HANA ומה מותר להשתנות כתוצאה מהמעבר.

3. בדיקות הסבת נתונים

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

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

מה לבדוק?

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

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

4. בדיקות פונקציונליות

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

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

לדוגמה – תהליך מכירה:

1. יצירת לקוח
2. יצירת הזמנה
3. בדיקת זמינות
4. אספקה
5. תנועת מלאי
6. הפקת חשבונית
7. רישום חשבונאי
8. קליטת התשלום

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

5. בדיקות אינטגרציה ב-S/4HANA

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

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

יש לבדוק בין היתר:

• API
• Web Services
• קבצים
• מערכות CRM
• מערכות BI
• מערכות בנקאיות
• מערכות שכר
• מערכות לוגיסטיות
• מערכות מסחר
• מערכות צד שלישי

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

6. בדיקות רגרסיה

בדיקות רגרסיה הן קריטיות במיוחד במעבר ל-S/4HANA. שינוי טכנולוגי משמעותי עלול להשפיע על תהליכים שלא השתנו לכאורה.

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

לכן יש לבנות Regression Pack הכולל את התהליכים העסקיים החשובים ביותר.

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

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

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

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

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

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

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

8. בדיקות ביצועים

אחד היתרונות המרכזיים של S/4HANA הוא הארכיטקטורה המבוססת על SAP HANA, אך אין להסיק מכך שכל תהליך יהיה אוטומטית מהיר יותר בסביבה החדשה.

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

בין היתר:

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

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

9. בדיקות End-to-End

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

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

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

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

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

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

תרחישי UAT צריכים להתבסס על מצבים אמיתיים, כולל:

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

11. בדיקות לפני Go Live

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

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

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

12. Smoke Test מיד לאחר Go Live

לאחר העלייה לאוויר אין להתחיל מיד בבדיקות מקיפות. מומלץ לבצע תחילה Smoke Test קצר שמוודא שהמערכת והפונקציות הקריטיות זמינות.

לדוגמה:

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

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

13. בדיקות Post Go Live

העבודה של QA אינה מסתיימת ביום ה-Go Live.

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

לכן יש להמשיך לעקוב אחר:

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

חשוב להגדיר תקופת Hypercare ברורה שבה צוותי ה-QA, הפיתוח, התשתיות והעסק עובדים בתיאום הדוק יותר.

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

גם לאחר המעבר הראשוני ל-S/4HANA, המערכת ממשיכה להשתנות. עדכונים, תיקונים, שינויים בתהליכים ופיתוחים חדשים עלולים להשפיע על תהליכים קיימים.

לכן מומלץ להמשיך להשתמש במסגרת בדיקות מסודרת ולא להפוך את ה-QA לפעילות חד-פעמית של פרויקט המעבר.

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

15. אילו תקלות נפוצות מתגלות במעבר ל-S/4HANA?

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

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

16. איך בונים Test Strategy לפרויקט S/4HANA?

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

מסמך Test Strategy יכול לכלול:

1. מטרות הפרויקט
2. Scope של הבדיקות
3. מערכות ותהליכים שנכללים בבדיקה
4. סיכונים מרכזיים
5. גישת בדיקות
6. סבבי בדיקה
7. אחריות צוותים
8. ניהול תקלות
9. קריטריוני כניסה ויציאה
10. קריטריוני Go/No-Go
11. תוכנית Regression
12. תוכנית Post Go Live

17. איך לתעד תרחישי בדיקה?

תרחיש בדיקה טוב צריך להיות ברור גם לאדם שלא כתב אותו.

מומלץ לכלול לפחות:

שדה	מה לתעד?
Test ID	מספר ייחודי
תהליך	התהליך העסקי
Preconditions	מה צריך להיות מוכן לפני הבדיקה
Steps	שלבי הביצוע
Expected Result	התוצאה הצפויה
Actual Result	מה קרה בפועל
Status	Pass / Fail / Blocked

18. אוטומציה בבדיקות S/4HANA

לא כל בדיקה בפרויקט S/4HANA צריכה להיות אוטומטית. השאלה החשובה היא היכן האוטומציה מחזירה את ההשקעה שלה.

מועמדים טובים לאוטומציה הם תרחישים:

• חוזרים על עצמם
• קריטיים לעסק
• יציבים יחסית
• בעלי מספר רב של וריאציות
• המהווים חלק מ-Regression Pack

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

אם אתם בוחנים כלים לאוטומציה, ניתן לקרוא גם את ההשוואה בין Playwright, Cypress ו-Selenium.

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

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

לדוגמה:

• אחוז תרחישי הבדיקה שהושלמו
• אחוז תרחישים שעברו
• מספר תקלות לפי חומרה
• מספר תקלות פתוחות
• Defect Leakage
• אחוז כיסוי של תהליכים קריטיים
• אחוז הצלחת Regression
• כמות תקלות לאחר Go Live
• זמן ממוצע לסגירת תקלה
• מספר תקלות חוזרות

20. הטעויות הנפוצות ביותר בבדיקות S/4HANA

טעות 1: מתחילים לבדוק מאוחר מדי

כאשר QA נכנס רק לקראת ה-UAT, בעיות תכנון רבות כבר התקבעו.

טעות 2: בודקים רק את המערכת

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

טעות 3: לא בודקים נתונים בצורה מספקת

בדיקה שטחית של Migration עלולה לפספס פערים משמעותיים.

טעות 4: לא מבצעים Baseline

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

טעות 5: מתמקדים רק בתרחישים חיוביים

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

טעות 6: מסיימים QA ביום ה-Go Live

חלק מהבעיות יופיעו רק תחת שימוש אמיתי, ולכן Post Go Live Testing חשוב לא פחות מבדיקות ההכנה.

צ'קליסט מסכם לבדיקות S/4HANA

סיכום: בדיקות S/4HANA הן תהליך ולא אירוע חד-פעמי

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

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

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