התשובה הקצרה
Cutover הוא תרגיל תפעולי, לא שלב טכני. שלושה דברים קובעים אם הוא יצליח: תוכנית ברמת שעה עם שם אחראי לכל צעד, Reconciliation שמוכיח שהנתונים נכונים ולא רק שהם הגיעו, וקריטריוני Go/No-Go שנכתבו כשכולם רגועים.
ההבדל בין ארגון שעבר מעבר חלק לארגון שספג שבועיים כאוס הוא כמעט תמיד מספר הרצות החזרה - לא איכות הכלים.
תכנון ההסבה כולה מתואר במיגרציית נתונים ל-Salesforce.
מבנה החלון: שלושה גלים
| גל | מתי | מה נטען |
|---|---|---|
| Historical | 3-10 ימים לפני | נתוני עבר סגורים: עסקאות סגורות, Cases סגורים, היסטוריה |
| Delta | בחלון עצמו | כל מה שהשתנה מאז הגל הראשון |
| Post-Go-Live | 24-72 שעות אחרי | קבצים כבדים, נתונים לא קריטיים, השלמות |
הפיצול הזה הוא מה שמאפשר חלון קצר. ארגון שמנסה לטעון הכול בלילה אחד מגלה שזמן הטעינה תלוי בנפח, וזמן הנפח לא ניתן לדחיסה מעבר למגבלות הפלטפורמה.
לוח זמנים לדוגמה - חלון של 12 שעות
| שעה | פעולה | אחראי |
|---|---|---|
| T-2 | אישור Go, בדיקת זמינות צוות ומקבל החלטות | ראש הפרויקט |
| T0 | Freeze במערכת המקור, ניתוק אינטגרציות יוצאות | IT Ops |
| T0+1 | חילוץ Delta ואימות ספירות במקור | Data Lead |
| T0+2 | טעינת Delta לפי סדר תלויות | Migration |
| T0+6 | Reconciliation אוטומטי: ספירות, סכומים, קשרים | QA |
| T0+8 | דגימה ידנית ואישור בעלי תהליך | Business |
| T0+9 | נקודת אל-חזור: החלטה Go / Rollback | Steering |
| T0+10 | הפעלת אינטגרציות, פתיחת הרשאות משתמשים | IT Ops |
| T0+11 | Smoke Tests בתהליכים קריטיים | QA + Business |
| T0+12 | הודעת פתיחה למשתמשים, מעבר להיפר-קייר | תקשורת |
שני עקרונות בלוח: לכל שורה יש שם, ולכל בדיקה יש סף מספרי. שורה בלי אחראי לא תבוצע; בדיקה בלי סף תיפתר בוויכוח.
Reconciliation: ארבע רמות שאין לדלג עליהן
ספירה - כמה רשומות במקור מול היעד, לכל ישות ולכל טווח תאריכים. תופס טעינות חלקיות.
סכום - סכומי שדות כספיים ומספריים. תופס המרות שגויות, חיתוכים ואיפוסים שקטים; ספירה תקינה לא תגלה אותם.
קשרים - כמה ילדים לכל הורה, וכמה רשומות יתומות. תופס סדר טעינה שגוי ומיפוי מפתחות שבור.
דגימה ידנית - 20 עד 50 רשומות שנבחרו מראש, כולל מקרי קצה: לקוח עם תווים מיוחדים, עסקה במטבע זר, רשומה שעברה מיזוג. זו הרמה היחידה שתופסת שגיאה סמנטית - נתון שנטען בהצלחה למקום הלא נכון.
התלות בין דיוק ההמרה לאיכות ה-Mapping מוסברת בData Mapping למיגרציה.
תרחיש: המעבר שנעצר בשעה השמינית
חברת הפצה תכננה חלון של עשר שעות בסוף שבוע. הטעינה עברה, הספירות התאימו במדויק, והצוות התכונן לפתוח. בדגימה הידנית התגלה שאצל שישה מתוך 30 לקוחות שנבדקו, ההזדמנויות הפתוחות שויכו לבעלים הלא נכון - תוצאה של טבלת מיפוי משתמשים שלא עודכנה אחרי שני עזיבות ומעבר תפקיד.
הספירות היו תקינות. הסכומים היו תקינים. רק הדגימה תפסה את זה. הצוות לא ביצע Rollback: הוא זיהה שמדובר ב-1,400 רשומות הניתנות לתיקון בשאילתה, ביצע תיקון ממוקד בתוך החלון, ואימת שוב.
ההחלטה התאפשרה כי קריטריון No-Go הוגדר מראש כ"שגיאה שאינה ניתנת לתיקון בתוך שעתיים" ולא כ"כל שגיאה". קריטריון מנוסח היטב הוא מה שמאפשר לצוות עייף לקבל החלטה נכונה בשלוש לפנות בוקר.
היפר-קייר: 14 הימים שאחרי
חלון Cutover מסתיים בפתיחה למשתמשים, אבל הסיכון נמשך. נדרש צוות בכוננות עם ערוץ פנייה יחיד, דוח יומי של חריגות אינטגרציה, ומעקב אחר מדדי איכות מול Baseline. תקלות מסווגות לפי השפעה עסקית ולא לפי מי צעק חזק יותר.
מדידה שוטפת של איכות אחרי המעבר מתוארת במדדי איכות נתונים.
סיכונים נפוצים ופעולות מניעה
| סיכון | כיצד הוא נראה בפועל | פעולת מניעה |
|---|---|---|
| חלון יחיד לכל הנפח | הטעינה חורגת והמעבר נדחה | פיצול לשלושה גלים |
| אינטגרציה שהתעוררה | רשומות כפולות או עדכונים סותרים | ניתוק מבוקר והפעלה מסודרת |
| Reconciliation שטחי | ספירות תקינות ונתונים שגויים | ארבע רמות כולל דגימה ידנית |
| אין קריטריוני No-Go | ממשיכים קדימה מתוך מומנטום | ספים כתובים לפני החלון |
| מיפוי משתמשים ישן | בעלות שגויה על רשומות | רענון טבלת משתמשים יום לפני |
כיצד מודדים הצלחה
| תחום | מה מודדים | קצב בדיקה |
|---|---|---|
| דיוק הסבה | פערי ספירה, סכום וקשרים | בכל גל וב-Cutover |
| עמידה בזמנים | סטייה מהזמנים בלוח | בכל Rehearsal |
| יציבות אחרי מעבר | כשלי אינטגרציה ותקלות P1 ליום | יומי ב-14 הימים |
| אימוץ | כניסות ופעולות מול Baseline | שבועי בחודש הראשון |
ליווי בתכנון והרצת Cutover מתבצע במסגרת שירות אינטגרציות ודאטה.
Checklist ל-Go/No-Go
- ☐ שתי הרצות Rehearsal מלאות בנפח ייצור
- ☐ לוח זמנים בשעות עם אחראי לכל שורה
- ☐ תוכנית Freeze מוסכמת עם העסק
- ☐ רשימת אינטגרציות לניתוק ולהפעלה, בסדר
- ☐ תסריט Reconciliation בארבע רמות אוטומטי ככל האפשר
- ☐ מדגם ידני מוגדר מראש כולל מקרי קצה
- ☐ טבלת מיפוי משתמשים ובעלות עודכנה
- ☐ קריטריוני No-Go כתובים עם ספים מספריים
- ☐ נקודת אל-חזור ותוכנית Fix-Forward
- ☐ צוות היפר-קייר, ערוץ פנייה ודוח יומי
מקורות מקצועיים
- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – אינטגרציות ודאטה — https://hpi.pro/integrations-data