התשובה הקצרה
הוויכוח בין Big Bang להשקה מדורגת מוצג לרוב כשאלת סיכון, אבל הוא בעיקר שאלת תלות. אם שתי יחידות חולקות את אותה רשומה ואת אותו תהליך, פיצולן לגלים שונים מייצר תקופת ביניים יקרה ומועדת לשגיאות. אם היחידות עצמאיות, אין סיבה להעלות את כולן יחד.
הכלל המעשי: קודם ממפים תלות, אחר כך בוחרים אסטרטגיה.
שתי הגישות בקצרה
השקת Big Bang מעלה את כל היחידות בתאריך אחד. היתרון הוא סיום מהיר, מקור אמת יחיד מהיום הראשון ואפס עלות תקופת ביניים. החיסרון הוא ריכוז סיכון: כל טעות פוגעת בכולם באותו רגע, וההתאוששות מורכבת.
השקה מדורגת מעלה יחידה או תהליך בכל גל. היתרון הוא למידה מגל לגל, סיכון מוגבל וצוות שמשתפר. החיסרון הוא משך פרויקט ארוך יותר, עייפות ארגונית, ותקופה ממושכת שבה שתי מערכות חיות במקביל.
מיפוי התלות — הבדיקה שקובעת
| שאלה | תשובה שמובילה ל-Big Bang | תשובה שמובילה לגלים |
|---|---|---|
| האם אותה רשומה מטופלת בשתי יחידות? | כן, באופן שוטף | לא, בעלות ברורה |
| האם התהליך עובר בין המחלקות? | כן, מקצה לקצה | תהליכים נפרדים |
| האם הדיווח הניהולי מאחד את כולן? | כן, יומי | דיווח ברמת יחידה |
| האם אפשר לסנכרן דו-כיוונית בעלות סבירה? | לא | כן |
| האם היחידות חולקות אותו קטלוג מוצרים ותמחור? | כן | לא |
שלוש תשובות ומעלה בעמודה השמאלית — פיצול לגלים יעלה יותר ממה שהוא חוסך.
עלות ה-Coexistence
זהו הסעיף שמכריע החלטות רבות ובכל זאת נשכח בתכנון. תקופת ביניים כוללת: סנכרון דו-כיווני בין Salesforce למערכת הישנה, הפקת דיווח מאוחד משני מקורות, תמיכה בשתי סביבות, הכשרה כפולה למשתמשים שעובדים מול שתיהן, וטיפול בהתנגשויות עדכון.
אמדן מציאותי נע בין 10% ל-25% מתקציב הפרויקט, ועולה ככל שהתקופה מתארכת. אם התוכנית כוללת שנה של Coexistence, יש לבחון ברצינות אם קיצור התקופה שווה את הסיכון הנוסף של השקה רחבה יותר.
סיכוני מיגרציה בכל גישה
ב-Big Bang המיגרציה היא אירוע יחיד, גדול, בחלון זמן קצר. היא דורשת חזרות מלאות (Mock Cutover) ותוכנית חזרה לאחור מוכחת. ב-Rollout מדורג המיגרציה חוזרת בכל גל, אך בהיקף קטן — ובכל פעם צריך להחליט מה קורה לרשומות שנוגעות ליחידות שטרם עלו.
בשני המקרים, איכות הנתונים היא הגורם המכריע ליום ההשקה. פירוט תכנוני מופיע במדריך הטמעת Salesforce.
מטריצת החלטה לפי סוג ארגון
| הקשר | המלצה | נימוק עיקרי |
|---|---|---|
| עד 150 משתמשים, תהליך אחיד | Big Bang | עלות Coexistence עולה על הסיכון |
| ריבוי אתרים או מדינות | גלים לפי אתר | הבדלי רגולציה ותהליך |
| מספר מחלקות עם תהליך משותף | Core משותף ואז גלים | מונע סנכרון דו-כיווני |
| תאריך קשיח לסיום חוזה קיים | Big Bang עם Scope מצומצם | אין זמן לתקופת ביניים |
| ארגון ללא ניסיון קודם ב-Salesforce | גל ראשון קטן | בניית יכולת פנימית |
| מיגרציה מורכבת מריבוי מקורות | גלים | פיזור סיכון הנתונים |
הגישה ההיברידית שעובדת בפועל
רוב ההטמעות הגדולות המוצלחות משלבות: שכבת Core אחידה — מודל נתונים, לקוחות, הרשאות, דיווח בסיסי — עולה לכל הארגון בבת אחת; מעליה גלים לפי יחידה עבור התהליכים הייחודיים. כך נמנע סנכרון דו-כיווני על הנתון המשותף, ובכל זאת נשמרת למידה הדרגתית.
בחירת ההיקף המינימלי לגל הראשון היא החלטה בפני עצמה, ומפורטת בהגדרת MVP ב-Salesforce. בארגונים גדולים ההשלכות רחבות יותר ונדונות בהטמעת Salesforce בארגון גדול.
השלכות על תקופת הייצוב
האסטרטגיה קובעת גם את מבנה ה-Hypercare: ב-Big Bang נדרש צוות גדול לתקופה אינטנסיבית וקצרה; בגלים נדרש צוות קטן שחוזר בכל גל ומצטבר בו ידע. בשני המקרים נדרשים קריטריוני יציאה מוגדרים, כמפורט בHypercare אחרי Go Live.
סיכום
מפו תלות בין יחידות לפני שדנים במתודולוגיה, תמחרו את תקופת ה-Coexistence במספרים, ובחרו לפי ההקשר: ארגון קטן עם תהליך אחיד ילך ל-Big Bang, ארגון רב-אתרי ילך לגלים, ורוב הארגונים הבינוניים ירוויחו מ-Core משותף וגלים מעליו.