המדריך מיועד לעסקים עם חנות גדולה או מורכבת, או לכאלה שהציעו להם לבנות חנות על Magento. הוא מסביר מה ההבדל בין Magento Open Source ל-Adobe Commerce, למי הפלטפורמה מתאימה, ואילו משאבים נדרשים כדי להפעיל אותה לאורך זמן. בסופו תוכלו להעריך אם המורכבות מוצדקת בעסק שלכם, ואילו שאלות להציג לספק.
Magento Open Source מול Adobe Commerce
Magento היא פלטפורמת מסחר בקוד פתוח, שנמצאת היום בבעלות Adobe. יש לה שתי גרסאות עיקריות:
| Magento Open Source | Adobe Commerce | |
|---|---|---|
| רישיון | חינמי, קוד פתוח | מוצר מסחרי ברישיון. המחיר נקבע בהצעה מ-Adobe |
| אחסון | באחריותכם: שרת או ענן | אפשרות לאחסון בענן מנוהל של Adobe, או באחסון עצמאי |
| יכולות B2B, כמו חשבונות חברה, קטלוגים משותפים והצעות מחיר | דורשות הרחבות של צד שלישי או פיתוח | זמינות באמצעות הרחבת B2B ל־Adobe Commerce, בהתאם לזכאות ולהתקנה; ראו תיעוד Adobe |
| תמיכה | קהילה וספקים | תמיכה של Adobe לפי ההסכם |
הליבה משותפת לשתי הגרסאות. ההבדלים הם ביכולות מסחריות, בתשתית המנוהלת ובתמיכה.
למי זה מתאים
Magento נבחרת בדרך כלל כשיש לפחות כמה מהמאפיינים האלה:
- קטלוג גדול, עם מאפייני מוצר רבים ווריאציות מורכבות.
- כמה חנויות, שפות, מטבעות או מחירונים שמנוהלים ממערכת אחת.
- לקוחות עסקיים עם מחירים לפי לקוח, הזמנות חוזרות או אישורי רכש.
- חיבורים עמוקים למערכות ERP, מחסן או CRM.
- צוות פיתוח זמין, פנימי או חיצוני, לאורך זמן.
אם החנות קטנה או בינונית, הקטלוג פשוט ואין צוות טכני קבוע, המורכבות של Magento היא בדרך כלל עלות ולא יתרון. במקרה כזה כדאי לבחון את Shopify או את WooCommerce.
מה נדרש כדי להפעיל אותה
תשתית
Magento דורשת סביבת שרת מוגדרת היטב: PHP, מסד נתונים MySQL או MariaDB, מנוע חיפוש OpenSearch, שכבת מטמון כמו Valkey או Redis, ובדרך כלל גם Varnish. Adobe מפרסמת לכל גרסה שילוב מסוים של גרסאות רכיבים שהיא תומכת בו. לכן שדרוג Magento כרוך לעיתים גם בשדרוג של רכיבי השרת.
צוות
הפעלה תקינה דורשת מפתחים שמכירים את Magento ברמת הקוד, ניהול תצורה וגרסאות, סביבת בדיקה נפרדת, ותהליך מסודר להעלאת שינויים. זה לא אתר שבעל העסק מעדכן בעצמו בלחיצה.
עדכונים ומחזור תמיכה
Adobe מפרסמת עדכוני אבטחה ומגדירה לכל גרסה של Adobe Commerce תקופת תמיכה לפי קו הגרסה והמוצר, כמפורט במדיניות העדכנית. לדוגמה, תמיכה רגילה בגרסה 2.4.8 מתוכננת עד סוף מאי 2028. חנות שנשארת על גרסה שהתמיכה בה הסתיימה לא מקבלת תיקוני אבטחה, ולכן שדרוג תקופתי הוא חלק מהעלות, לא אירוע חריג.
העלויות האמיתיות
- רישיון, ב-Adobe Commerce בלבד.
- אחסון ותשתית שמתאימים לעומס, כולל סביבת בדיקה.
- פיתוח והקמה: עיצוב, הגדרות, הרחבות וחיבורים.
- הרחבות בתשלום, כמו סליקה, משלוחים, חשבוניות ו-B2B ב-Open Source.
- תחזוקה ושדרוגים: עדכוני אבטחה, שדרוגי גרסה ובדיקות אחרי כל שינוי.
הסעיף האחרון הוא מה שמפתיע בדרך כלל. כדאי לבקש מהספק הערכה לעלות שנתית של תחזוקה ושדרוג, לא רק להקמה.
מה לבדוק בחנות שפועלת בישראל
- חברת הסליקה שלכם מציעה הרחבה רשמית ומעודכנת ל-Magento, שתואמת לגרסה שאתם מתכננים.
- הפקת חשבוניות וקבלות דרך חיבור למערכת הנהלת החשבונות.
- תמיכה בעברית ובכיוון מימין לשמאל בתבנית, כולל קופה ומיילים ללקוח.
- נגישות, מדיניות ביטולים לפי חוק הגנת הצרכן, ופרטיות. ראו ניהול חנות אונליין שוטף.
- זמינות של מפתחי Magento בישראל או ספק חיצוני עם ניסיון מוכח.
דוגמה בדיונית: יבואן ציוד משרדי שמוכר לעסקים ולצרכנים שוקל מעבר ל-Magento בגלל מחירונים לפי לקוח והזמנות חוזרות. לפני ההחלטה הוא ממפה כמה לקוחות עסקיים באמת משתמשים במחירונים אלה, ובודק אם יכולת דומה קיימת בפלטפורמה הנוכחית שלו בעזרת הרחבה. אם כן, ייתכן שאין צורך במעבר יקר.
הצעד הבא
רשמו את הדרישות שבגללן Magento נשקלת: גודל קטלוג, ריבוי חנויות, B2B, חיבורים. לכל דרישה בדקו אם פלטפורמה פשוטה יותר עונה עליה, עם הרחבה או בלי. אם רוב הדרישות דורשות Magento, בקשו מהספק הצעה שכוללת הקמה, תשתית ותחזוקה שנתית. לתכנון ולאפיון אפשר להיעזר בעמוד הקמת אתר סחר.
בחינת היתכנות: דרישה אחת מתחילתה ועד סופה
לפני בחירת המערכת, בקשו להדגים דרישה שמייצגת את המורכבות האמיתית: מחירון לקוח, מוצר עם מאפיינים רבים או העברת הזמנה למערכת אחרת. הגדירו נתוני בדיקה, משתמש והרשאות, תוצאה צפויה ותרחיש כשל. הדגמה של מסך מוכן אינה מספיקה כדי להעריך אינטגרציה.
בקשו רשימת רכיבים לפי מוצר וגרסה: ליבה, הרחבות, שירותים ופיתוח מותאם. לכל רכיב ציינו בעל רישיון, עלות תחזוקה, תמיכה ותלות ברכיבים אחרים. אם יכולת מוצגת בהדגמת Adobe Commerce, אל תניחו שהיא כלולה ב־Magento Open Source. גם רכיב מסחרי עשוי לדרוש הרחבה והגדרה מתאימות.
הסכימו מראש על מסלול עדכון: מי בודק תאימות, מי מאשר ביצוע ומי מטפל בכשל. בקשו תיעוד שמאפשר לספק אחר להבין את המערכת. התהליך צריך לכלול את המערכות המחוברות ואת שגרת העסק, לא רק העלאת קוד. אם אין לכך משאבים קבועים, זו מגבלה בבחירת הפלטפורמה שיש לפתור לפני ההקמה.
מקורות
שאלות ותשובות
IBASTOM.CO.IL
Magento מהירה יותר מפלטפורמות אחרות?
היא יכולה להיות מהירה מאוד עם תשתית ומטמון מוגדרים נכון, ואיטית מאוד בלעדיהם. המהירות תלויה בתשתית ובאיכות הפיתוח, לא בשם הפלטפורמה.
אפשר לעבור ל־Magento מפלטפורמה אחרת?
כן, אבל זה פרויקט הגירה מלא: מוצרים, לקוחות, הזמנות, הפניות לכל הכתובות, חיבורים לכל המערכות ובדיקות. ראו מבנה אתר וכתובות URL על שינוי כתובות.
מה קורה אם מפסיקים לעבוד עם הספק שבנה את החנות?
כדאי לוודא מראש שהקוד, הגישה לשרת, מאגר הקוד וההרחבות בתשלום רשומים על שם העסק, ושיש תיעוד. כך ספק אחר יוכל להמשיך את העבודה.
מה הסימן לכך ש־Magento גדולה מדי לעסק?
כשאין לעסק מפתח או ספק קבוע שמכיר את הפלטפורמה, כשהקטלוג פשוט וכשאין צורך בתמחור או בחיבורים מורכבים. במצב כזה העלות והתחזוקה גבוהות מהתועלת, ופלטפורמה פשוטה יותר תתאים.
מה בודקים בהצעת מחיר לתחזוקה?
מה כלול: עדכוני אבטחה וגרסה, ניטור, גיבויים וזמני תגובה לתקלה. בודקים גם מי מעדכן הרחבות בתשלום ומה קורה כשגרסה מגיעה לסוף התמיכה, כי שם מסתתרות רוב העלויות שלא נכנסו להצעה.
