פיתוח בוט-סקרייפר לזמינות מוצרים אצל מתחרים

מנתח מלאי: היכן מתקלקל איסוף הנתונים

מנתח מלאי פותר משימה אחת — לספק באופן קבוע תמונה עדכנית של קטלוג זר: מה יש במלאי, מה אזל, מה חזר. כל עוד הדגימה נקייה, רוכש המלאי עובד לפי המצב בפועל. ברגע שבשרשרת "מקור → ניתוח → אחסון → דוח" מופיע אי-תיאום, הנתונים הופכים למסוכנים יותר מהיעדרם: לפיהם מתקבלות החלטות.

התקלה הנפוצה ביותר — מלאי מיושן בקטלוג. הייצוא נלקח במלואו ומשוכתב פעם ביממה, אף שהמקור מתעדכן לעתים קרובות יותר; חלק מהדפים מוגשים מהמטמון, ואיסוף נתוני המלאי מתעד את מצב האתמול כמצב נוכחי. רוכש המלאי רואה "במלאי", והפריט אזל עוד בבוקר.

הסוג השני — כרטיסים ריקים לאחר שינוי בתגיות. הניתוח נשען על אלמנטים ספציפיים בעמוד: כאשר עיצוב מחדש של בלוק המחיר או המלאי גורם לצומת להיעלם, והאוסף מחזיר בשקט "אזל מהמלאי" במקום שגיאת ניתוח. הדוח נראה תקין, אך מחצית הקטלוג בו — אפסים כוזבים.

השלישי — אי-התאמה בין המחסן לחנות. המוצר נמצא במערכת החשבונות (1С), אך אינו מפורסם, או להפך: הכרטיס פתוח, אך היתרה לא נרשמה. ללא השוואה בין שני המקורות הללו, הניטור של קטלוג המתחרה מציג את מה שהקונה רואה, ולא את מה שהספק באמת מוכר.

לאחר מכן מתווספת עבודה ידנית: רוכש המלאי פותח עשרות דפים ובודק מחדש פריטים שנויים במחלוקת, כי אין אמון בייצוא. נבחן כיצד זה נסגר — מבקרת טריות ובדיקת שלמות הניתוח ועד אותות על אי-התאמה.

מה נותן איסוף קבוע של נתוני מלאי ומחירים

כל עוד הבדיקות נעשות ידנית, בין סריקות הקטלוגים נותרת חלון של יום-יומיים, והמחסור בתוכו נשאר בלתי מורגש. רוכש המלאי מבזבז זמן על סריקה מכנית במקום קבלת החלטות על המגוון, ואי-ההתאמה בין הטבלאות הידניות למציאות מצטברת עד לבדיקה הבאה.

איסוף קבוע מסיר את עיקר העבודה הזו: שיעור הבדיקות הידניות יורד לכדי ניתוח חריגים — ככלל, אחוזים בודדים מהנפח הקודם. את השאר מכסה ניטור מחירים ומלאי לפי לוח זמנים: פריטים שלא השתנו אינם מסיחים את הדעת, והשינויים נכנסים מיד לדוח עם זמן תיעוד.

מהירות התגובה ליציאת מוצר מהמלאי מפסיקה להיות תלויה בכך שרוכש המלאי יגיע לכרטיס. האות מגיע ברגע השינוי, ולכן מספר המחסורים שהוחמצו מצטמצם לאפס, וההחלטה על ביטחון מתקבלת באותו יום, ולא אחרי שהספק מכר את המלאי.

סוג נפרד של שגיאות נעלם לחלוטין — מחיר מיושן בגיליון הרכש, כרטיס נשכח, שתי גרסאות של אותה טבלה. היסטוריית השינויים מראה מתי הפריט אזל וחזר, כמה זמן נמשך המחסור וכיצד התנהג המחיר אצל השכנים: זה בסיס למשא ומתן ולתיקון המגוון, ולא ניחוש. כך בדיוק האוטומציה של עבודת רוכש המלאי משנה את תפקיד האדם: הוא מנתח סטיות, ולא מחפש אותן.

שיטות איסוף נתונים: השוואה ומגבלות

בחירת שיטת האיסוף קובעת לא רק את מהירות ההפעלה, אלא גם כמה זמן יידרש לתחזוקה בעוד חצי שנה. נבחן ארבע אפשרויות שביניהן באמת בוחרים: החלפת נתונים עם האתר דרך ממשק תוכנה, סריקת דפי קטלוג, ייצוא מוכן מהספק ושירות ניטור חיצוני.

בפועל, השיטות כמעט תמיד משולבות: היכן שיש ממשק — עובדים דרכו, את השאר מכסים בסריקת קטלוג, והייצוא מהספק משמש כערוץ גיבוי למקרה של אי-זמינות. נתונים מכל המקורות מובאים לסכימה אחידה: מק"ט, פלטפורמה, יתרה, זמן מדידה. אז תקלה בערוץ אחד לא מפילה את האיסוף, ואי-התאמות בין המקורות נראות מיד.

שלבי הפיתוח: מניתוח המשימה ועד ההפעלה

שלבי הפיתוח של הבוט אצלנו מתבצעים בסדר קבוע: תחילה אנו מסכימים מה בדיוק נחשב למלאי, לאחר מכן אוספים נתונים ורק אז מכניסים אותם ללוח זמנים. זה מסיר את הסיכון העיקרי — בוט שעובד באופן פורמלי, אך מציג לא את מה שנדרש לרכש.

1. ביקורת מקורות נתונים. מנתחים כל אתר: האם יש ממשק תוכנה פתוח או רק תגיות כרטיסים, כיצד בנויה החלוקה לעמודים, האם יש צורך בסריקת תת-דומיינים אזוריים. בפלט — רשימת מקורות עם תדירות עדכון וכללי התאמת מוצרים.
2. סכימת איסוף ומפתח התאמה. ניקח מזהה יציב — מק"ט או ברקוד — כדי ששינוי שם הכרטיס לא ייתן "אזל מהמלאי" כוזב. התנהגות בעת שינוי תגיות מתוארת מראש: אות שגיאה במקום ייצוא ריק שקט.
3. בניית ליבה על מקור אחד-שניים. נריץ אחסון והשוואת מחירים באתרים פשוטים, לפני חיבור השאר. כך שגיאות לוגיות עולות לפני שמופיעים עשרה מקורות בסכימה.
4. לוח זמנים לעדכונים. המרווח נבחר בהתאם למשימה, ההרצות מפוזרות בזמן, מספר הפניות בו-זמניות מוגבל, וקיימים ניסיונות חוזרים במקרה של תקלות רשת, כדי ששרתים זרים לא יראו בנו עומס.
5. הרצת מבחן. משווים את התוצאה לדגימה ידנית בכמה עשרות כרטיסים, מחשבים את שיעור אי-ההתאמות ובודקים מה הבוט עושה עם פריטים שהוסרו מהמכירה או הוסתרו מהקטלוג.
6. קבלה. בודקים על סט אמיתי: שלמות לפי כל מקור, טריות הנתונים עד לרגע הדוח, מספר התראות שווא. הקריטריונים מסוכמים לפני ההפעלה, כדי שהקבלה תהיה פורמליות ולא ויכוח.
7. מסירה והדרכה. מוסרים קונפיגורציות, תיעוד והוראות לחיבור מקור חדש, ומראים כיצד לקרוא את יומן השגיאות. לאחר מכן מחזור העדכון של הבוט מנוהל על ידי צוות הלקוח בעצמו.

ערכת אספקה: קוד, סכימות, תקנוני עדכון

לאחר המסירה, אצל הלקוח נשארת לא שירות בצד שלנו, אלא ערכה מלאה: קוד, תיעוד לבוט ותקנונים שלפיהם ניתן לפתח את המערכת בכוחות עצמם או להעביר לצוות אחר ללא הנדסה הפוכה. הרשימה מעוגנת במסמך — כל סעיף נבדק בעת הקבלה.

• קוד מקור — מאגר עם היסטוריית שינויים, מחולק למודולים: סריקת מקורות, ניתוח דפים, התאמת מוצרים, שליחת התראות.

• סכימת איסוף נתונים — רשימת מקורות ושדות לכל אחד, תדירות הסריקה, סימנים להיעדר מלאי, כללי השהיה בעת מגבלות מצד המקור.

• כללי התאמה — לפי אילו מאפיינים מוצר נחשב לאותו מוצר אצל מוכרים שונים, כיצד מטופלים כפילויות ושינויי שמות, טבלת חריגים.

• תיעוד הבוט — הוראות הפעלה מאפס, הרכב הסביבה, היכן מאוחסנים מפתחות גישה וכיצד להחליפם ללא עריכת קוד.

• תקנון עדכון — תדירות בחינת המקורות, סדר חיבור חנות חדשה, פעולות בעת שינוי תגיות דפים במקור.

• העברת הרשאות — חשבונות, תפקידים, סדר החלפת מפתחות עם עזיבת עובד, למי מוצמדת כל הרשאה.

• אחסון היסטוריה — עומק אחסון צילומי מלאי ומחירים, לוח זמנים לניקוי, פורמט ייצוא לניתוח.

• תקנון תמיכה — זמן תגובה לתקלת איסוף, סדר שחזור ובקרה, שבו שתיקת הבוט אינה נקראת כ"יש מוצר".

מקרה בוחן: בקרת מגוון ברשת קמעונאית

רשת קמעונאית עם מגוון של כמה אלפי פריטים ניהלה את בקרת המלאי אצל המתחרים באופן ידני: מנהלי קטגוריות סרקו כרטיסים בשווקים מקוונים ובאתרי ספקים, השוו יתרות בטבלה משותפת וביצעו תיקונים ביד.

השוואה מלאה ארכה לצוות של שלושה אנשים כמעט שני ימי עבודה, ולכן שינויים התגלו באיחור — כבר לאחר שהמוצר אזל מהמלאי, וההחלטה על הרכש התקבלה בעיוורון.

מה שינו

הרכבנו מנתח שסורק לפי לוח זמנים רשימה מוגדרת של מקורות — מאתרי ספקים ועד Яндекс Маркет — ומשווה מלאי ומחיר לצילום הקודם. את המצב אנו שומרים לכל פריט: הערך האחרון, זמן השינוי, המקור.

את התגיות אנו מתארים בקונפיגורציית סלקטורים בנפרד מהלוגיקה של הסריקה, ולכן שינוי בקוד האתר בצד המקור לא מפיל את האיסוף — מתקנים תיאור אחד, ללא עריכות בקוד. ניסיונות חוזרים לבקשות שנכשלו מבוצעים בהשהיה גדלה, ואי-התאמות בין מקורות מסומנות כחשודות, ולא כשינוי במלאי.

מה קרה

ההשוואה אורכת 15–20 דקות במקום יומיים, והסיכום מגיע לפני פתיחת המשמרת. שיעור השינויים שנתפסו ביממה הראשונה עלה מ-40% ל-95% — הרכש מגיב בעוד המתחרה טרם מכר את המלאי. הפעולות הידניות פחתו פי כמה: המנהל מנתח רק אי-התאמות חשודות, ולא את כל הרשימה.

כאשר במקור אחד השתנו התגיות פעמיים, האיסוף שוחזר תוך 20 דקות על ידי תיקון הסלקטורים, ללא שכתוב הלוגיקה.

במה שונה איסוף דרך ממשק תוכנה מסריקת דפים?

אם לחנות יש ממשק תוכנה, המלאי מגיע בשדות מוכנים: יתרה לפי מחסן, סטטוס "במלאי" או "בהזמנה", זמן אספקה. אנו מושכים עשרות ומאות פריטים בבקשה אחת ומקבלים סט ערכים שאינו תלוי באופן שבו הכרטיס מוצג באתר באותו רגע. המהירות והיציבות של האיסוף כאן מקסימליות, כל עוד ההסכמה עם המקור לא השתנתה.

סריקת דפים מופעלת היכן שאין ממשק או שהוא לא מספק הכל. תגיות הקטלוג — זו הסכמה חד-צדדית: שינוי במבנה האתר, החלפת תבנית הכרטיס או העברת בלוק המלאי שוברים את הדגימה.

לכן היציבות של האיסוף כאן נשענת על כללים המחוברים למשמעות הבלוק ולמרכיבים שכנים, ולא לשמות מחלקות ספציפיים, ועל השוואה קבועה עם כרטיסים לדוגמה.

ממשק תוכנה או סריקת דפים — זו לא בחירה של "או-או". לרוב הערוץ הראשי הוא הממשק, והסריקה משמשת כגיבוי: מאשרת מלאי בנקודות מכירה שהממשק לא מכסה, ומספקת גיבוי כשהתשובות מגיעות באיחור.

זה עובד גם בכיוון ההפוך: בהיעדר ממשק, הסריקה מכסה הכל, והממשק מתחבר מאוחר יותר, אם החנות פותחת אותו.

ההבדל ניכר בתחזוקה. הממשק משתנה לעתים רחוקות, אך נשבר כולו — יש צורך בבקרת פורמט התגובות והתראה על סטיות. התגיות משתנות לעתים קרובות, אך נקודתית — יש צורך בהיסטוריות לדוגמה ואות אוטומטי בעת גידול בשיעור השדות הריקים. הבחירה מוכתבת על ידי כיסוי השדות הנדרשים, ולא על ידי נוחות הפיתוח.

ספקות לגבי עומס, חסימות ותמיכה

איסוף נתונים מקטלוג זר — זו שאלה של קצב וכללים: תדירות הפניות, מספר הסשנים במקביל ורשימת הדפים אנו מגדירים בהגדרות, ולא משאירים למקריות. זרימת הבקשות נשמרת מתחת לזו של רובוט חיפוש רגיל — העומס על אתר המתחרה נשאר בלתי מורגש עבור בעליו.

להלן — הספקות שנשמעים לרוב לפני ההתחלה: חסימת בקשות, מסגרת חוקית לאיסוף, התראות שווא ותמיכה לאחר ההפעלה.

מה המסגרת החוקית לאיסוף נתונים?

אנו עובדים רק עם מידע פתוח על מלאי ומחיר — ללא אימות, חשבונות אישיים ונתונים אישיים. לכל צילום אנו שומרים את כתובת המקור ואת זמן הקבלה: זה בסיס להשוואה ולניתוח מקרים שנויים במחלוקת.

כיצד מסננים התראות שווא?

השינוי מאושר על ידי בקשה חוזרת לאחר מספר דקות והשוואה לצילום הקודם. אם המלאי חזר לקדמותו, האירוע מסומן כרעש ואינו נכנס להתראה — לדוח נכנסים רק שינויים יציבים.

מי אחראי לעבודה לאחר ההפעלה?

התגיות של דפים זרים משתנות, לכן לאחר המסירה נותר תקנון: בקרת שיעור הצילומים המוצלחים, התראה על נפילה ועל שינוי מבנה, עדכון מתוכנן של כללי הניתוח. אנו מוסרים תיעוד על השדות ואת הסדר להפעלה עצמאית.

נדון במשימה: סכימת איסוף ותוכנית הפעלה

כדי לחזור עם הערכה ותוכנית, ולא עם שאלות הבהרה, יש צורך במינימום נתוני מקור. להלן — מה לשלוח לדיון במשימה: זה מספיק כדי לחשב את היקף העבודה, להרכיב סכימת איסוף ולנקוב בלוחות זמנים.

• רשימת מקורות — פלטפורמות ומדורים שבהם יש לעקוב אחר מלאי: כתובות קטלוגים, קטגוריות, דפי מוצרים.
• רשימות מוצרים — מק"טים, שמות או קישורים לכרטיסים שלפיהם משווים פריטים; אם יש כמה רשימות, ציינו במה הן נבדלות.
• שדות נדרשים — מה בדיוק מתעדים בייצוא: סטטוס מלאי, יתרה, זמן אספקה, כתובת הכרטיס, זמן מדידה.
• תדירות עדכון — פעם ביממה, פעם בשעה או לפי אירוע; מכך תלויים סכימת הסריקה והיקף אחסון ההיסטוריה.
• פורמט ייצוא — טבלה, קובץ או רשומה במערכת החשבונות שלכם, וכן האם יש צורך בהיסטוריית שינויים ובאיזה עומק.
• הרשאות ומגבלות — היכן נדרש אימות, האם יש מגבלות על מספר הפניות והאם יש לעבוד דרך קו פרוקסי שלכם.
• כללי תגובה — למי וכיצד לדווח על שינוי: מכתב, הודעה במסנג'ר או סיכום נפרד.

עם סט זה אנו חוזרים עם תוכנית עבודה: סכימת איסוף לכל מקור, שלבים, הרכב הצוות, סדר בדיקת הנתונים על מדגם מבחן ותנאי הליווי לאחר ההפעלה. תארו את המשימה — נשלח הערכה ותוכנית.