לפני כמה שנים גמרתי פרויקט של העלאת מוצרים ידנית לחנות של לקוח. 300 מוצרים. שבועיים עבודה. קיבלתי את התשלום, חזרתי הביתה ואמרתי לעצמי: "אם זה יחזור פעם נוספת, אני לא עושה את זה ככה." זה חזר. הפעם עם 2,000 מוצרים. ואז עם 5,000. ואז הבנתי שהבעיה היא לא רק שזה לוקח זמן ‑ הבעיה היא שהמודל הזה לא יכול לגדול. ואז בניתי מערכת.
הבעיה שחזרה על עצמה בכל לקוח
כל פרויקט של העלאת מוצרים התחיל אותו דבר: לקוח שמח עם קובץ אקסל. "הכל מוכן, צריך רק להעלות." ואז פתחת את הקובץ.
שמות עמודות שונים בכל קובץ ספק. מחירים בפורמטים שונים. תמונות בתיקיה בלי שם שיסביר מה בפנים. קטגוריות שמישהו המציא בזמן אמת. ותיאורי מוצר שהם לרוב "השם + הגודל" בלבד.
לא מאשים אף אחד. ספקים לא שולחים קבצים בפורמט שמתאים ל-WooCommerce. זה פשוט לא הדבר שלהם. אבל מישהו צריך להפוך את מה שהם שולחים למה שהאתר מצפה לקבל.
"הנתונים קיימים" ו"הנתונים מוכנים לאתר" זה לא אותו דבר. זה ההבדל שלמדתי שוב ושוב בכל פרויקט.
הדר, הדרה דיגיטל
הטעות הכי נפוצה שראיתי אצל בעלי חנויות היא לחשוב שהקובץ שהספק שלח כמעט מוכן וצריך רק לתקן שני דברים קטנים. במציאות כל "שני דברים קטנים" הוא בעצם עשרות שורות עם חריגים: מוצר בלי מחיר, קטגוריה שלא קיימת באתר, תמונה שקושרה למק"ט הלא נכון. וכשמנסים לתקן את זה תוך כדי ההעלאה, נכנסים ללופ אינסופי של תיקון, בדיקה, תיקון נוסף.
מי שמזהה את התיאור הזה אצל עצמו לא עשה שום דבר לא נכון. זה פשוט אומר שהתהליך שבו הנתונים עוברים מהספק לחנות מעולם לא תוכנן, הוא רק קרה. וזה בדיוק המקום לעצור ולבנות אותו נכון, לפני שהוא גדל עוד יותר.
למה העלאה ידנית לא יכולה להיות מודל ברמת קנה מידה
אפשר להעלות 50 מוצרים ידנית. זה לוקח יום, זה בסדר. 500 מוצרים ‑ כבר שבוע מלא. 2,000 ‑ חודש. ו-5,000? לא ריאלי אם רוצים גם לבדוק, גם לעדכן מחירים, גם לטפל בתמונות.
יש גם בעיה אחרת: עקביות. כשאדם עושה 500 החלטות ביום, הוא שוגה. פעם כותב "נעלי נשים", פעם "נעליים לנשים", פעם "נעל ‑ נשים". שלוש גרסאות לאותה קטגוריה. בפילטרים של האתר זה כבר כאוס.
קחו למשל תרחיש מדומיין: חנות עם 3 ספקים ו-1,500 מוצרים, שמעדכנת מלאי ומחירים פעם בשבועיים. אם כל עדכון כזה לוקח יומיים של עבודה ידנית, זה כבר יותר מ-100 שעות בשנה שמושקעות רק בהעברת נתונים ממקום למקום, בלי שום ערך יצירתי בתהליך. וזה עוד לפני שסופרים את הטעויות שנכנסות בדרך.
מקור: McKinsey Global Institute, Harnessing Automation
אחרי שהבנתי את זה, הפסקתי לחשוב על "העלאת מוצרים" כשירות ידני וחשבתי עליה כתהליך הנדסי שצריך מבנה.
הטעות הנפוצה ביותר שראיתי אצל עצמי ואצל אחרים היא לנסות לתקן בזמן ריצה: להעלות מוצרים ולתקן שגיאות תוך כדי, ישירות בממשק הניהול של החנות. זה מרגיש מהיר בהתחלה, אבל בפועל אין שום תיעוד למה תוקן ולמה לא. ובעדכון הבא מתחילים כמעט מאפס, כאילו אף אחד לא למד כלום מהפעם הקודמת.
מה הייתה הגישה שלי לבנייה
לא ניסיתי לבנות כלי שעושה הכל לבד. ניסיתי לבנות כלי שמזהה איפה צריך עין אנושית ומה יכול לרוץ בלי.
ההחלטה הזאת הגיעה אחרי כמה ניסיונות כושלים. פעם אחת ניסיתי לבנות תסריט שמשלים אוטומטית קטגוריות חסרות, על סמך שם המוצר בלבד. זה עבד יפה על 80% מהמוצרים ופספס לגמרי את שאר ה-20%, בלי לסמן שהוא בכלל מנחש. זו הייתה טעות שלימדה אותי משהו חשוב: מערכת שמנחשת בלי להגיד שהיא מנחשת מסוכנת יותר מאדם שעובד לאט.
הצינור עובד בשלבים:
- ניקוי נתונים שלב 1
- מיפוי וסיווג שלב 2
- העלאה ואימות שלב 3
בכל שלב, המערכת מדגללת מה שהיא לא בטוחה בו. אני רואה רק את מה שצריך החלטה ‑ לא מנסה לבדוק 5,000 שורות ידנית.
זה גם שינה את התפקיד שלי בתהליך. במקום להיות מי שמעתיק ומדביק שורה אחר שורה, הפכתי להיות מי שמאשר את ההחלטות הגבוליות בלבד. יש סיפוק אחר בבדיקת 40 שורות חריגות מתוך 5,000, לעומת מעבר ידני על כל ה-5,000.
מה בניתי בפועל
לא בניתי אפליקציה פנטסטית עם ממשק יפה. בניתי צינור שמשלב כמה כלים שכבר קיימים ועובדים ‑ ונותן להם לעבוד ביחד.
כל אחד מהחלקים האלה נבנה בהתחלה בנפרד, בפרויקט נפרד, כי כל לקוח הגיע עם בעיה קצת שונה. אבל אחרי כמה פרויקטים ראיתי שהם חוזרים על עצמם באותו סדר בערך, אז חיברתי אותם לצינור אחד שאפשר להתאים לכל לקוח במקום לבנות מחדש כל פעם.
-
סקריפט ניקוי ונורמליזציה
עובד על קובץ הספק. מאחד פורמטי מחיר, מנרמל שמות עמודות, מתרגם לפורמט שמוכן ל-WooCommerce. מסמן שורות בעייתיות ‑ לא מוחק אותן. -
לוגיקת מיפוי קטגוריות
כותבים אותה פעם אחת לכל לקוח: "הקטגוריה X של הספק הופכת לקטגוריה Y בחנות". הפעמים הבאות ‑ אוטומטי. -
שיוך תמונות לפי מק"ט
סקריפט שמחפש בשם קובץ התמונה מספר מוצר תואם. מה שנמצא ‑ מסומן. מה שלא ‑ נכנס לרשימת בדיקה ידנית ממוקדת. -
יצוא WooCommerce CSV מוכן לייבוא
הפלט הסופי הוא קובץ שנכנס ישר לוורדפרס. לא חיבורים, לא API ‑ מיבוא ישיר. פחות נקודות כשל.
למה חשוב להגיד את זה בקול רם: הרבה בעלי עסקים שומעים "אוטומציה" ומדמיינים קסם שפותר הכל בלחיצת כפתור. כשמצפים לקסם ומקבלים מערכת שעדיין דורשת בדיקה של 5% מהשורות, זה מרגיש כמו כישלון. אבל 5% בדיקה ממוקדת על 5,000 מוצרים זה 250 שורות, לא 5,000. זה עדיין ניצחון גדול, גם אם הוא לא מושלם.
האם זה שווה להשקיע בזה
עבור חנויות עם פחות מ-100 מוצרים שלא משתנים ‑ לא בטוח. תלוי בתדירות העדכונים.
עבור חנויות עם 500+ מוצרים, כמה ספקים ועדכונים שוטפים ‑ כן, בהחלט. ההשקעה הראשונית בבניית המבנה מחזירה את עצמה כבר בפרויקט השני. אם בא לך להבין מה נכלל בשירות העלאת מוצרים ותכנים לאתרים, יש שם הסבר מפורט על מה מכוסה ואיך התהליך נראה.
יש גם פן שקשה לכמת: ניחות הדעת. שתי גרסאות "נעלי נשים" בקטגוריות לא נראות בדוח ‑ הן מופיעות כשלקוח לא מוצא מה שהוא מחפש. שם עולה הנזק.
יש לך חנות שהקטלוג שלה מחכה?
קבצי ספקים, תמונות לא ממוינות, מחירים בפורמטים שונים ‑ זה נשמע מוכר? לא חייב לשב על זה לבד.
אני בונה את הצינור שמתאים לחנות שלך ‑ לפי הספקים, הקטגוריות והכמות הספציפית שלך. לא תבנית כללית, משהו שמתאים לך.
כדאי לדבר לפני שמתחילים ‑ לא אחרי שמגלים שמשהו לא עובד.
בניתי את המערכת הזאת כי נמאס לי להרגיש כמו מכונת קופי-פייסט.
לא מתבייש להגיד את זה. העלאה ידנית בקנה מידה גדול זה עבודה שמתישה את האדם ולא מייצרת ערך אמיתי. הערך הוא בהחלטות ‑ לא בלהדביק שורות.
כשבניתי את הצינור, לא שאלתי "איך לעשות את זה מהר יותר". שאלתי "איך להפסיק לעשות את מה שלא חייב להיעשות ידנית". זה הבדל חשוב.
שאלות נפוצות
