תחזית מכירות ב-ML: מצבר הזדמנויות B2B ועד קמעונאות B2C

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

תחומי פיתוח AI

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1365
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

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

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

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

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

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

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

מה נותנת תחזית ביקוש מנוהלת: האפקט במספרים

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

דיוק התחזית באופק יומי ושבועי

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

מחסור בפוזיציות נמכרות

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

מלאי קפוא ומחזור מלאי

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

סוג שגיאות תכנון שהוסר

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

פורמטים של מודלי תחזית מכירות: רגרסיה ואנסמבלים

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

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

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

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

איך אנחנו מטמיעים מודל תחזית: שלבי העבודה

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

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

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

מה מקבלים לידיים: ארטיפקטים ונהלים

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

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

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

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

מה היה לפני ההטמעה

את קו הבסיס מדדו במשך שבועיים לפי שלוש קבוצות מדדים: שיעור הפוזיציות במחסור, נפח מלאי עודף ומאמץ העבודה של המתכננים. בהתחלה המחסור עמד על 11–14% מהמבחר, מחזור מלאי הסחורה הגיע ל-74 ימים, ושני מתכננים בזבזו על חישוב מחדש של התוכנית כ-30 שעות בשבוע.

מה השתנה אחרי

המודל מחשב ביקוש ברמה של "פוזיציה — נקודה — שבוע", מתחשב בנפרד במבצעים, בעונתיות ובלוח האספקות, והחישוב מחדש נעשה מדי יום. המתכנן כבר לא בונה תוכנית מאפס: הוא מטפל רק בפוזיציות עם סטייה מעל הסף — אלו 5–8% מהמבחר. מעבר כזה עשינו עבור רשת «מרידיאן».

בתוך שני רבעונים המחסור ירד ל-4–6%, המחזור הצטמצם ל-51 ימים, דיוק המשלוחים בזמן עלה מ-82% ל-96%, והמחיקות לפי תוקף ירדו כמעט בחצי. מאמץ התכנון — כ-9 שעות בשבוע במקום 30; הזמן שהתפנה עבר לעבודה עם ספקים ולמבצעים מקומיים.

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

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

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

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

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

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

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

ספקות טכניים נפוצים לפני ההתחלה

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

כמה היסטוריה צריך כדי שהתחזית תעבוד?

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

הנתונים יושבים במערכות שונות — זה מכשול?

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

איך לחזות מוצרים חדשים שאין להם היסטוריה?

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

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

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

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

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

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

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