חיזוי ביקוש מבוסס ML לקמעונאות ולייצור

מדוע חיזוי ביקוש נכשל בנתונים אמיתיים

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

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

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

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

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

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

המודל חוזה לא מספר אחד לכל הרשת, אלא היררכיה: פריט סחורה — מחסן — שבוע, עם פרופילים עונתיים נפרדים לכל קבוצה. תחזית נקודתית מתוגברת בגבולות קוונטיליים, ולכן תוכנית הרכש נבנית לא מ"ממוצע", אלא מרמת שירות שאתם מגדירים בעצמכם. בתקופת רטרו השגיאה הממוצעת נשמרת בטווח 12–18% לעומת 30–40% בתכנון "מהחודש הקודם".

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

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

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

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

גישות לחיזוי ביקוש: סטטיסטיקה ולמידת מכונה

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

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

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

שלבי הטמעה: מביקורת נתונים ועד מסירת המודל

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

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

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

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

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

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

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

מקרה בוחן: מלאי ומכירות מוחמצות לפני ואחרי ההטמעה

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

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

מה הראה המדד

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

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

מה לעשות אם הנתונים מפוזרים בין כמה מערכות?

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

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

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

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

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

ספקות טכניים: נתונים, איכות, אינטגרציה

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

כיצד התחזית משתלבת במערכת החשבונאית?

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

כיצד מובטחת הגנת נתונים?

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

מי מתחזק את המודל לאחר ההפעלה?

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

נדון במשימה שלכם ונחזור עם תוכנית

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

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

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