איפשהו ב-ERP שלכם יושב מספר, לפעמים נקרא נקודת הזמנה, שקובע מתי יוצאת הזמנת רכש לכל פריט שאתם מחזיקים. מישהו קבע את המספר הזה פעם אחת, לרוב כשהפריט נטען למערכת בפעם הראשונה. ברוב הארגונים אף אחד לא חוזר אליו אחרי זה. הבעיה היא ששני הדברים שהמספר הזה מבוסס עליהם, כמה מהר הפריט נמכר וכמה זמן לוקח להביא עוד ממנו, ממשיכים לזוז בשקט ברקע, בזמן שהמספר שמניח שהם לא זזים נשאר בדיוק במקום שבו קבעו אותו.
מה נקודת ההזמנה אמורה בעצם לייצג?
בלי להיכנס לחשבון המדויק, נקודת ההזמנה עונה על שאלה אחת: כמה תמכרו בין הרגע שבו תוציאו הזמנה לרגע שבו היא תגיע, ועוד רווח ביטחון למקרה שהזמן הזה יימשך יותר או שהמכירות יהיו גבוהות מהרגיל. במילים פשוטות: נקודת הזמנה שווה ביקוש רגיל לאורך זמן האספקה, ועוד מלאי ביטחון, וברגע שהמלאי יורד לרמה הזו אמורה לצאת הזמנה חדשה. שני חלקי המספר הזה, אומדן הביקוש וזמן האספקה, הם מדידות של המצב בעולם ביום שבו מישהו חישב אותם לאחרונה. אף אחד מהם אינו חוק טבע.
למה המספר מתיישן בלי שאף אחד מחליט על כך?
שני דברים רגילים קורים לכל פריט עם הזמן, וכל אחד מהם לבד מספיק כדי לקלקל את נקודת ההזמנה הישנה.
הביקוש זז. פריט מקבל לקוח מוסדי חדש, מאבד מקום מדף למתחרה, נכנס לעונה חלשה, או פשוט עולה או יורד כמו שרוב הביקוש נוהג לעשות. אף אחד מזה לא דורש שמישהו יקבל החלטה. זה פשוט קורה, ונקודת ההזמנה שחושבה לפני שנה או שנתיים ממשיכה להניח את הקצב הישן.
גם זמן האספקה זז, ולעיתים קרובות יותר ובכיוון שהכי כואב. ספק עובר מפעל, נתיב הובלה נהיה עמוס, תקנת מכס חדשה מוסיפה שבוע, או שהספק הוותיק מחליק בשקט מארבעה שבועות לשישה. אף אחד לא מריץ מחדש את חישוב נקודת ההזמנה כשזה קורה, כי שדה זמן האספקה ב-ERP נחשב בדרך כלל הגדרה קבועה ולא משהו שצריך לעקוב אחריו. לזמן האספקה יש התנהגות אחת שהופכת את זה לגרוע יותר: יש לו רצפה, כי ייצור ועוד הובלה לא יורדים מתחת למינימום מסוים, אבל אין לו תקרה. חודש רע יכול להוסיף שבועות ואף אחד מהם לא חוזר. כשנקודת הזמנה מבוססת בשקט על זמן אספקה ממוצע משנה שעברה, בדיוק השנים שבהן היא הכי טועה הן השנים שבהן עיכוב אמיתי פוגע, וההשפעה לא נשארת מוגבלת לפריט אחד. המאמר המקורי בנושא הראה שהשונות בהזמנות יכולה להיות גדולה יותר מהשונות במכירות בפועל, ושהעיוות הזה נוטה לגדול ככל שמתרחקים במעלה שרשרת האספקה (Lee, Padmanabhan ו-Whang, “Information Distortion in a Supply Chain: The Bullwhip Effect”, Management Science 43(4), 1997, עמ’ 546-558). נקודת הזמנה שהתיישנה, שמגיבה באיחור לשינוי אמיתי בביקוש או בזמן האספקה, היא בדיוק הסוג של כלל מקומי שמזין אות מעוות לתוך השרשרת הזו.
אילו פריטים הכי חשופים לזה?
לא כולם באותה מידה. שלושה דפוסים כדאי לבדוק קודם:
- פריטים מיובאים עם הובלה ארוכה או לא עקבית. זמן האספקה הוא הנתון שהכי סביר שהשתנה בשקט והכי פחות סביר שמישהו עדכן מחדש.
- פריטים שדפוס הביקוש שלהם באמת השתנה, לקוח מפתח חדש, ערוץ שגדל או הצטמצם, עונתיות שפעם הייתה שטוחה.
- כל דבר שאף אחד לא נגע בו מאז שהוגדר. אם שדה נקודת ההזמנה מציג בדיוק את הערך שהיה לו לפני שנתיים, זו לא הוכחה שהוא עדיין נכון. זו הוכחה שאף אחד לא בדק.
איזו בדיקה אפשר להריץ על המספרים שלכם השבוע?
ייצוא מה-ERP וגיליון אקסל, ותו לא.
- שלפו את נקודת ההזמנה ותאריך העדכון האחרון שלה עבור הפריטים המובילים שלכם בהכנסה. כל מה שלא נגעו בו יותר משנה כדאי לבדוק, בלי קשר לביצועים עד עכשיו.
- השוו את זמן האספקה הרשום ב-ERP מול מה שבאמת קרה בכמה מהזמנות הרכש האחרונות מאותו ספק. פער של כמה ימים על פריט מיובא הוא דבר נפוץ, וזה אומר שכל נקודת הזמנה שנבנתה על המספר הישן טועה באותה מידה.
- בדקו את המכירות בפועל בשני הרבעונים האחרונים מול קצב הביקוש שנקודת ההזמנה מניחה. אם הם התרחקו זה מזה, מלאי הביטחון מותאם כרגע לעסק שכבר לא מתקיים.
- התחילו מהפריטים שהיה בהם חוסר או עודף בשנה האחרונה. זו לא רשימה מקרית, זה בדיוק המקום שבו הנחה שהתיישנה כבר עלתה לכם משהו.
זו הרגל תחזוקה, לא פרויקט. הפריטים ששווה לבדוק מחדש הם בדרך כלל רשימה קצרה, לא כל הקטלוג, ומציאת הרשימה הזו היא הדבר הראשון שהעבודה שלנו על עיתוד מלאי ברמת פריט עושה לפני שממליצים לבנות משהו.