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

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

תחומי פיתוח AI

שאלות נפוצות

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

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

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

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

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

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

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

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

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

מה משתנה אחרי ההטמעה: אפקטים מדידים

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

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

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

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

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

מצבי עבודה של המודל: אצווה, זרימה, היברידי

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

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

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

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

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

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

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

מה מוסרים לידיים: תצורות ונוהלים

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

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

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

מקרה בוחן: הרכבה מחדש של המבחר ויציאה ממלאי לא סחיר

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

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

מה שינו

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

מדדים לפני ואחרי

  • שיעור המלאי הלא סחיר: 34% → 11% בתוך שני רבעונים.
  • דיוק הפגיעה בביקוש: 58% → 84%.
  • הרכבה מחדש של המטריצה: שלושה שבועות → יומיים.
  • הכנסה למק״ט: +19% באותו נפח מדף.
  • זמן עד להשפעה: ההחלטות הראשונות להוצאה — בשבוע השלישי, שינוי יציב — עד סוף הרבעון השני.

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

במה מודל דירוג שונה מכללים על סף

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

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

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

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

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

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

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

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

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

האם נפח היסטוריית המכירות יספיק?

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

למה המערכת ממליצה כך?

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

תביאו בחשבון את העונתיות שלנו?

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

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

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

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

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

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

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

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