בתיק העבודות של שמרת הזורע מתועדת פעילות בצוות האינטרנט בשנים 2018–2022, עם אתר סחר, תוכן, קטלוג וחיבורים למערכות עסקיות. המאמר מיועד לעסק המתכנן שינוי פלטפורמה ורוצה להבין מה צריך למפות לפני פיתוח. אין כאן דוח הגירה טכני של הפרויקט; ההמלצות הן רשימת החלטות כללית שנובעת מסוג המורכבות המתואר.
לקרוא את היקף העבודה בהקשר
עמוד המקור מציין עבודה במסגרת צוות, פעילות סביב Magento וממשקי ניהול מסחר, וכן עיסוק בנתונים ובתוכן. הוא אינו מפרט כל גרסת מערכת או את כל חלוקת התפקידים בין הספקים. אין לייחס לאדם אחד את כל תוצרי הצוות או להסיק שהמערכות המתוארות הן המערכות שבהן החברה משתמשת כיום.
ראו את תיאור פרויקט שמרת הזורע. הקישור לעמוד IBASTOM מספק הקשר היסטורי; הוא אינו קישור לאתר הרשמי של הרשת. כאשר בוחנים תיק עבודות, בקשו להבחין בין תפקיד, תוצר ותוצאה עסקית מתועדת.
מיפוי הנתונים לפני העברת פלטפורמה
בפרויקט דומה כדאי למפות מוצרים, וריאציות, קטגוריות, תמונות, לקוחות והזמנות. לכל סוג נתון הגדירו מקור, מזהה קבוע, בעלים וכללי התאמה. שינוי שמות עמודות אינו מבטיח שהמידע יעבור באותה משמעות; שדה שמייצג זמינות במערכת אחת עשוי לייצג מצב שיווקי באחרת.
אל תעבירו את כל המידע רק משום שהוא קיים. קבעו מה נחוץ להפעלה, מה נשמר כתיעוד ומה דורש הרשאה או בדיקה נוספת. מידע אישי ומידע רגיש מחייבים טיפול מתאים, ולא קובץ משותף בלתי מוגבל. יש לתאם את התהליך עם בעלי המערכות והאחריות הרלוונטיים.
בדקו תהליך, לא רק טבלת מוצרים
בחרו תרחיש שמתחיל בעדכון נתון ומסתיים בפעולה באתר. למשל, שינוי מחיר או זמינות במערכת המקור, הופעתו במוצר והמשך להזמנה. הגדירו מה קורה בעיכוב ובכשל. בדיקה של קובץ תקין בלבד לא תחשוף תמיד סנכרון שנקטע באמצע.
הדוגמה היא מסגרת בדיקה מוצעת, ולא טענה על דרך הביצוע בשמרת הזורע. בפרויקט עם כמה ספקים חשוב לקבוע מי מאמת בכל תחנה ומי מקבל התראה. בלי ההפרדה הזו, כל גורם יכול לראות מערכת תקינה בזמן שהלקוח רואה מידע לא מעודכן.
פלטפורמה, הרחבות ורישוי
בבחינת Magento/Adobe Commerce, הפרידו בין היכולות של המוצר המסוים לבין הרחבות וחיבורים. תיעוד Adobe מציג את מוצר B2B כהרחבה ל־Adobe Commerce, והזמינות תלויה ברכישה ובהתקנה המתאימות. אין להניח שכל התקנת Magento כוללת מחירונים או תהליכי רכש עסקיים מתקדמים.
בקשו מספק הפיתוח לרשום אילו רכיבים נדרשים, מי מספק אותם וכיצד מעדכנים אותם. התאמה למערכת ERP או CRM אינה מתקיימת רק מפני ששתי המערכות מציגות API. צריך להסכים על שדות, הרשאות, תדירות וטיפול בתקלות. מדריך Magento ו־Adobe Commerce מפרט את השיקולים ברמת הפלטפורמה.
תוכן וכתובות הם חלק מהמעבר
מפו כתובות ישנות ליעדים החדשים, כולל מוצרים, קטגוריות ומאמרים שנכנסים אליהם ישירות מהחיפוש. שמרו כתובת כאשר התוכן ממשיך באותו תפקיד. כשיש שינוי קבוע, בחרו הפניה לעמוד המקביל ועדכנו גם את הקישורים הפנימיים. אין צורך לשנות כתובת רק כדי להראות שהעיצוב חדש.
Google ממליצה לתכנן מפת מעבר ולבדוק הפניות וכתובות סופיות. ההנחיה אינה מבטיחה היעדר תנודות בתנועה. לאחר ההשקה, צריך לבדוק שגיאות ומפת אתר ולהפריד בין תקלה בתשתית לשינוי בביקוש או במקורות התנועה.
מסירה ותפעול אחרי ההשקה
הגדירו מי מאשר שהקטלוג נכון, מי בודק הזמנה ומי אחראי לטיפול שוטף. ספק טכני יכול לאשר שהקוד פועל, אך בעל העסק צריך לאשר שמחיר, אספקה ומידע מוצר נכונים. תהליך מסירה טוב כולל גם תרחישים חריגים והסבר לתפעול, ולא רק כניסה למערכת.
בפרויקט דומה כדאי להכין מראש:
- דגימת מוצרים פשוטים ומורכבים לבדיקה.
- טבלת שדות ומקורות נתונים.
- רשימת כתובות והפניות.
- תרחישי הזמנה, ביטול וכשל סנכרון.
- הגדרת אחריות ומסלול דיווח.
- רשימת דברים שנדחו לשלב הבא.
טבלת התאמה ובדיקת חזרה לאחור
לצד מיפוי השדות, הכינו טבלת התאמה בין רשומה ישנה לחדשה. השתמשו במזהה יציב ואל תסתמכו רק על שם מוצר שעשוי להשתנות. רשמו גם איך מטפלים ברשומה שלא נמצאה, במוצר כפול ובנתון שנדחה. דוח שמונה רשומות שהועברו אינו מראה לבדו שהנתונים הגיעו לאותה משמעות.
בחרו דגימה שמכסה מצבים שונים: מוצר פשוט, מוצר עם אפשרויות, מוצר לא פעיל והזמנה עם כמה פריטים. בדקו תוכן, תמונות וערכים רלוונטיים, ותעדו מה מאשר את ההתאמה. אלה דוגמאות לבדיקת פרויקט דומה, ולא דיווח על נתוני לקוחות או על תוצאות הגירה היסטורית.
הגדירו נקודת החלטה לפני פתיחה לקהל. מי מאשר את התוכן, מי מאשר את הסנכרון ומי מחליט אם להמתין? תוכנית מעבר צריכה לכלול גם דרך לטפל בכשל ובנתונים שנוצרו בזמן המעבר. אין להניח שאפשר להחזיר מערכת למצב קודם בלי להשפיע על הזמנות חדשות.
כאשר יש כמה ספקים, צרפו את סדר הפעולות למסמך משותף. כתבו מי מבצע ומי מוודא בכל תחנה, ומהי הראיה שהשלב הסתיים. כך מצמצמים מצב שבו כל ספק מסיים את המשימה המקומית שלו, אך המסלול השלם עדיין לא עובד.
לאחר ההשקה, שמרו רשימת חריגים ותאריך טיפול. בעיה שמתגלה בשירות הלקוחות יכולה להעיד על נתון חסר ולא בהכרח על קוד. מיפוי ותיעוד מאפשרים למצוא את המקור במקום לתקן את אותו מידע ידנית בכל מערכת.
הצעד הבא
לפני בחירת כלי הגירה, בנו מיפוי נתונים ותרחיש בדיקה אחד מתחילתו ועד סופו. אם אין בעלים לנתון או לשלב, פתרו זאת לפני פיתוח. לתכנון הקשרים בין המערכות ראו ניהול נתונים, ולתכולת האתר ראו אפיון אתר סחר.
מקורות
שאלות ותשובות
IBASTOM.CO.IL
מה ההכנה החשובה ביותר לפני מעבר פלטפורמה?
מיפוי הנתונים: אילו שדות קיימים, מה מגיע מאיפה, ומה צריך לעבור. בלי מיפוי, מגלים באמצע ההעברה שתכונות, וריאציות או היסטוריית הזמנות לא נתמכות במבנה החדש.
מה עושים עם הכתובות הישנות?
ממפים כל כתובת חשובה לכתובת המקבילה באתר החדש, ומגדירים הפניות קבועות. אחרי ההשקה בודקים ב־Search Console שגיאות 404 ומתקנים מהר.
אפשר לחזור לאחור אם המעבר נכשל?
רק אם מתכננים את זה מראש: גיבוי מלא, האתר הישן זמין עד שהחדש נבדק, ותנאים מוגדרים להחלטה לחזור. בלי תוכנית כזו, תקלה בהשקה הופכת לעבודה בלחץ.
למה הרחבות ורישוי הם חלק מההחלטה?
כי חלק מהיכולות נשענות על הרחבות בתשלום, עם עלות שנתית, תלות בספק ההרחבה ועדכונים. מוודאים על שם מי הרישוי, ומה קורה כשהרחבה מפסיקה להתעדכן.
מה בודקים בשבועות אחרי ההשקה?
הזמנות שנכנסות ומטופלות כרגיל, מלאי שמתעדכן, שגיאות בכתובות, שינויים בתנועה מהחיפוש ופניות של לקוחות על תקלות. השבועות הראשונים חושפים בעיות שבדיקות לפני ההשקה לא תפסו.
