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

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

בפועל, מדובר בתהליך מורכב הרבה יותר.

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

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

היא תהליך הכולל:

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

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

SAP מספקת עבור S/4HANA את Migration Cockpit, המאפשר ליצור פרויקטי הגירה, לבחור Migration Objects, לבצע מיפויים, לבצע סימולציה, להעביר נתונים ולעקוב אחר סטטוס ההעברה.

---

מהי הסבת נתונים ב־SAP?

הסבת נתונים, או Data Migration / Data Conversion, היא תהליך שבו נתונים ממערכת מקור מועברים למערכת יעד תוך התאמתם למבנה, לחוקים ולדרישות של המערכת החדשה.

לדוגמה, בארגון שעובר מ־SAP ECC ל־SAP S/4HANA ניתן להידרש להעביר:

• נתוני לקוחות
• ספקים
• חומרים
• Business Partners
• יתרות חשבונאיות
• יתרות מלאי
• הזמנות רכש פתוחות
• הזמנות מכירה פתוחות
• מסמכים פתוחים
• נתוני בנקים
• נתונים ארגוניים
• נתונים נוספים בהתאם לתכולת הפרויקט

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

זו נקודה חשובה מאוד:

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

---

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

הסיבה המרכזית היא שמערכת SAP אינה רק מאגר מידע.

הנתונים קשורים זה בזה.

לדוגמה, הזמנת רכש יכולה להיות תלויה ב:

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

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

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

צריך להבין את התלות בין הנתונים.

לדוגמה:

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

או:

לקוח → חומר → הזמנת מכירה → משלוח → חשבונית

מכאן נובע עיקרון חשוב:

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

---

הסבת נתונים ב־SAP S/4HANA

בפרויקטים של מעבר ל־SAP S/4HANA, SAP Migration Cockpit מאפשר לבצע הסבת נתונים באמצעות Migration Objects מוגדרים.

SAP מתארת שתי גישות מרכזיות בהתאם לסביבת S/4HANA ולתרחיש ההגירה:

1. העברת נתונים באמצעות Staging Tables.
2. העברת נתונים ישירות ממערכת SAP מקור נתמכת.

ב־Migration Cockpit ניתן לבחור את אובייקטי ההגירה הרלוונטיים, לבצע Mapping, לבצע Simulation ולאחר מכן לבצע את ההעברה בפועל.

המשמעות מבחינת צוות הבדיקות היא חשובה:

לא מספיק לבדוק שהקובץ "נטען".

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

---

שלבי הסבת נתונים נכונה

תהליך הסבת נתונים מקצועי צריך להיות מחולק לשלבים ברורים.

שלב 1: הגדרת Scope

לפני שמתחילים להעביר נתונים צריך להחליט:

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

זהו שלב עסקי ולא רק טכני.

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

---

שלב 2: Data Profiling

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

המטרה היא להבין מה באמת נמצא שם.

לדוגמה:

לקוחות

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

חומרים

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

ספקים

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

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

---

שלב 3: ניקוי נתונים

זהו אחד השלבים החשובים ביותר.

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

אם במערכת הישנה קיימים:

10,000 לקוחות

אבל 1,500 מהם כפולים או לא פעילים, השאלה אינה כיצד להעביר 10,000 לקוחות.

השאלה היא:

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

ניקוי נתונים יכול לכלול:

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

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

בדרך כלל זה אינו פתרון.

---

שלב 4: Mapping

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

לדוגמה:

מערכת מקור	מערכת יעד
IL	ISR
01	1000
KG	KGM
לקוח 12345	Business Partner 800123
מחסן 01	מחסן 1001

המיפוי חייב להיות מתועד.

חשוב במיוחד להגדיר:

• ערך מקור
• ערך יעד
• חוק ההמרה
• מקור המידע
• מי אישר את המיפוי
• האם המיפוי חד־ערכי
• האם קיימים חריגים

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

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

---

שלב 5: Transformation

לא תמיד מספיק להחליף ערך אחד בערך אחר.

לעיתים צריך לבצע Transformation.

לדוגמה:

במערכת הישנה:

תאריך בפורמט מסוים

ובמערכת החדשה:

תאריך בפורמט אחר.

או:

במערכת הישנה קיימים שני שדות:

First Name + Last Name

ובמערכת החדשה המבנה שונה.

Transformation יכול לכלול:

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

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

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

---

שלב 6: טעינת נתונים

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

ב־Migration Cockpit ניתן לבצע טעינה באמצעות מנגנונים הנתמכים בתרחיש ההגירה, כולל Staging Tables וקבצים בהתאם לתרחיש. SAP מתארת גם אפשרות לבצע Validation לקבצים לפני העברתם ל־Staging Tables.

אבל גם כאן:

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

אם SAP מציגה:

100% Loaded

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

---

שלב 7: Simulation

לפני הרצה אמיתית מומלץ לבצע Simulation.

SAP ממליצה לבצע סימולציה לפני העברת הנתונים בפועל. ב־Migration Cockpit ניתן לבצע Simulation ולאחר מכן לבחור אילו רשומות להעביר בפועל.

Simulation מאפשרת לזהות בעיות כמו:

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

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

---

איך בודקים הסבת נתונים ב־SAP?

כאן נכנס תפקיד ה־QA.

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

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

---

1. בדיקות כמות

השאלה הראשונה:

כמה רשומות היו במקור וכמה קיימות ביעד?

לדוגמה:

אובייקט	מקור	יעד	פער
לקוחות	12,500	12,500	0
ספקים	3,200	3,198	2
חומרים	48,000	47,850	150
הזמנות פתוחות	8,500	8,500	0

אבל חשוב להבין:

התאמה בכמות אינה מוכיחה תקינות.

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

---

2. בדיקות איכות

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

לדוגמה:

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

אפשר לקחת מדגם ולבצע השוואה:

Source → Target

לדוגמה:

שדה	Source	Target	תוצאה
Customer	10025	10025	תקין
Name	ABC Ltd	ABC Ltd	תקין
Currency	ILS	ILS	תקין
Payment Terms	30	30	תקין

---

3. בדיקות שלמות

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

לדוגמה:

אם היו במערכת המקור 5,000 ספקים, אבל רק 4,950 הועברו, צריך לדעת בדיוק:

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

אסור להסתפק במספר כולל.

---

4. בדיקות Referential Integrity

כאן בודקים את הקשרים בין הנתונים.

לדוגמה:

האם לכל הזמנת רכש קיים ספק?

האם לכל פריט בהזמנה קיים Material Master?

האם לכל לקוח קיימת ישות מתאימה?

האם לכל מסמך קיימים הנתונים הדרושים ליצירתו?

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

---

5. בדיקות יתרות

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

לדוגמה:

• יתרות חשבונות
• יתרות לקוחות
• יתרות ספקים
• מלאי
• בנקים
• יתרות GL

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

צריך לבדוק גם סכומים.

לדוגמה:

סכום יתרות במקור = סכום יתרות ביעד

או, אם קיים פער מתוכנן:

הפער מוסבר ומתועד.

---

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

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

לדוגמה:

Procure to Pay

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

Order to Cash

לקוח → הזמנה → משלוח → חשבונית → גבייה

Finance

מסמך → חשבון → יתרה → דוח פיננסי

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

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

---

7. בדיקות דוחות

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

לדוגמה:

מריצים דוח במערכת המקור:

Customers by Company Code

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

משווים:

• מספר רשומות
• סכומים
• קבוצות
• סטטוסים
• ערכים מרכזיים

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

---

8. Reconciliation – התאמה בין מקור ליעד

Reconciliation היא אחת הפעולות החשובות ביותר בתהליך.

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

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

חשוב לבצע התאמות בכמה רמות:

Level 1 – Count

מספר רשומות.

Level 2 – Amount

סכומים.

Level 3 – Key Fields

שדות מרכזיים.

Level 4 – Business Rules

חוקים עסקיים.

Level 5 – End-to-End

האם התהליך העסקי עובד.

SAP מציינת שבדיקת Data Migration צריכה לבדוק מעבר ל־Row Count בלבד, כולל בדיקת ערכי עמודות, ניתוחים, מדגמים והשוואות מתאימות.

---

טעויות נפוצות בהסבת נתונים ב־SAP

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

זו אחת הטעויות היקרות ביותר.

הצוות מגיע כמה שבועות לפני Go Live ומגלה:

• כפילויות
• נתונים חסרים
• Mapping לא פתור
• בעיות איכות
• נתונים שאינם נתמכים

בשלב הזה כבר אין מספיק זמן.

הפתרון

להתחיל Data Profiling מוקדם.

---

טעות 2: חושבים שה־IT אחראי על איכות הנתונים

IT אחראי על התהליך הטכנולוגי.

אבל מי שקובע אם נתון עסקי נכון?

בדרך כלל ה־Business.

לדוגמה:

האם לקוח צריך להיות פעיל?

האם ספק כפול?

איזה קוד מס נכון?

איזה תנאי תשלום צריך להיות?

אלה החלטות עסקיות.

לכן הסבת נתונים מוצלחת דורשת שיתוף פעולה בין:

IT + Business + Data Owners + QA + Project Management

---

טעות 3: בודקים רק מספר רשומות

לדוגמה:

100,000 רשומות במקור
100,000 רשומות ביעד

נראה מצוין.

אבל יכול להיות שהרשומות שגויות.

לכן Count הוא רק בדיקה אחת.

---

טעות 4: לא מבצעים כמה סבבי הסבה

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

לכן תהליך נכון יכול להיראות כך:

Migration 1 → בדיקות → תיקונים

Migration 2 → בדיקות → תיקונים

Migration 3 → בדיקות → תיקונים

Dress Rehearsal → בדיקות

Production Migration

זה הרבה יותר בטוח מאשר ניסיון ראשון בייצור.

---

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

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

• 500,000 לקוחות
• נתונים היסטוריים
• חריגים
• כפילויות
• מסמכים פתוחים
• נתונים פיננסיים
• אינטגרציות

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

---

טעות 6: לא מתעדים חריגים

בכל Migration יופיעו חריגים.

הבעיה אינה עצם קיום החריג.

הבעיה היא כאשר אין תשובה לשאלה:

למה הנתון הזה לא עבר?

לכן כדאי לנהל Migration Exception Log.

לדוגמה:

ID	אובייקט	בעיה	החלטה	אחראי	סטטוס
001	Customer	חסר Tax ID	להשלים	Business	פתוח
002	Material	קוד לא תקין	Mapping	IT	טופל
003	Vendor	כפילות	לא להעביר	Business	סגור

---

טעות 7: לא בודקים נתונים לאחר העלייה לייצור

גם אם ה־Migration עבר בהצלחה, לא כדאי לסיים את הבדיקות מיד.

צריך לבצע Post Go Live Validation.

לדוגמה:

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

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

---

טעות 8: מתעלמים מה־Cutover

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

ב־Cutover צריך לתאם:

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

לדוגמה:

22:00 – עצירת שינויים

↓

23:00 – Extract

↓

01:00 – Transformation

↓

03:00 – Load

↓

06:00 – Validation

↓

08:00 – Business Approval

↓

09:00 – Go Live

לכן Cutover צריך להיות מתוכנן כמעט כמו פרויקט בפני עצמו.

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

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

---

צ'קליסט לבדיקת הסבת נתונים ב־SAP

לפני אישור Migration מומלץ לעבור על הרשימה הבאה.

לפני ההסבה

• הוגדר Scope
• הוגדרו Migration Objects
• בוצע Data Profiling
• זוהו כפילויות
• בוצע Data Cleansing
• הוגדר Mapping
• הוגדרו Transformation Rules
• הוגדרו בעלי אחריות
• הוגדרו קריטריוני הצלחה
• הוגדרו דוחות להשוואה

במהלך Test Migration

• בוצעה טעינה ראשונית
• בוצע Validation
• בוצעה Simulation
• תועדו שגיאות
• בוצעו תיקונים
• בוצע Re-run
• נבדקו נתוני אב
• נבדקו נתונים טרנזקציוניים
• נבדקו יתרות

לפני Go Live

• בוצע Dress Rehearsal
• זמני ההסבה ידועים
• זמני ה־Downtime מאושרים
• תהליך Cutover מתועד
• קיימת תוכנית Rollback
• קיימים בעלי תפקידים זמינים
• קיימת רשימת בדיקות לאחר Migration
• Business אישר את הנתונים

לאחר Go Live

• בוצעה בדיקת כמויות
• בוצעה בדיקת יתרות
• נבדקו נתוני אב
• נבדקו מסמכים פתוחים
• נבדקו דוחות
• נבדקו ממשקים
• בוצעו תהליכים End-to-End
• Business נתן אישור

---

מי צריך להיות מעורב בהסבת נתונים?

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

מומלץ להגדיר לפחות את התפקידים הבאים:

Project Manager

אחראי על התוכנית, התלויות, הסיכונים וה־Cutover.

SAP Functional

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

Data Migration Team

אחראי על Extract, Transformation ו־Load.

QA

אחראי על אסטרטגיית הבדיקות, תרחישים, Validation ו־Reconciliation.

Business Owner

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

Technical Team

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

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

---

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

אחת השאלות החשובות ביותר היא:

מתי אפשר להגיד שההסבה הצליחה?

לא כדאי להסתפק במשפט:

"הטעינה הסתיימה בהצלחה."

עדיף להגדיר קריטריונים ברורים.

לדוגמה:

נתוני אב

99.9% מהרשומות הנדרשות הועברו בהצלחה.

נתונים פיננסיים

100% מהיתרות הקריטיות תואמות למקור בהתאם לכללי הפרויקט.

מסמכים פתוחים

100% מהמסמכים שהוגדרו ב־Scope הועברו.

תהליכים

100% מהתרחישים הקריטיים עברו.

תקלות

אין תקלות Severity 1 פתוחות.

אישור

ה־Business Owner אישר את תוצאות ה־Reconciliation.

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

---

הסבת נתונים היא לא רק Migration – היא שינוי עסקי

זו אולי הנקודה החשובה ביותר.

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

הוא לעיתים משנה:

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

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

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

---

הקשר בין הסבת נתונים לבדיקות SAP

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

במקום לבצע:

Migration → ואז QA

עדיף לעבוד כך:

Migration → Validation → QA → Reconciliation → תיקון → Migration נוסף

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

כך הבעיות מתגלות מוקדם ולא מגיעות ל־Go Live.

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

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

---

סיכום

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

היא שילוב של:

Data Quality + Mapping + Transformation + Migration + Testing + Reconciliation + Business Validation.

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

הגישה הנכונה היא להתחיל מוקדם, להגדיר Scope, לנקות נתונים, לתעד Mapping, לבצע כמה סבבי Test Migration, לבצע Simulation, להשוות בין מקור ליעד ולערב את הגורמים העסקיים לאורך הדרך.

בסופו של דבר, השאלה החשובה אינה:

"האם הצלחנו להעביר את הנתונים?"

אלא:

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

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

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

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

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