חזרה למקרי הבוחן

הפצה · מדעי החיים יבואנית ומפיצה ישראלית של מוצרי מעבדה

כל יום, ספר ההזמנות הפתוח הופך להזמנות רכש ב-SAP, לפי ספק ואופן משלוח

SAP Business One יבוא והפצה, שלושה מחסנים רץ מדי יום מאז ספטמבר

2,263

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

287

שורות לא הוזמנו, כי המלאי וההזמנות שבדרך מכסים אותן

איך אנחנו מספרים את המקרים האלה

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

האתגר

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

הזמן לא הלך על הקלדה. כל שורה דרשה החלטה:

מאות שורות פתוחות בכל רגע, וכל אחת עוברת את ארבע השאלות האלה.

איך חשבנו על זה

הגישה

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

01 · שלושה שערים לכל שורה

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

02 · חריג הולך לאדם, לא לניחוש

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

03 · כל שורה נגמרת בסל

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

איך בנינו את הלוגיקה

בתוך התרחיש

התרחיש רץ פעם ביום בשעה קבועה. ה-SAP של הלקוח יושב על שרת מקומי, ו-Make מגיעה אליו דרך ה-On-Prem Agent, בלי לחשוף אותו לאינטרנט.

המערכות בתרחיש

השלבים

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

למה זה לא היה נבנה טוב אחרת

SAP יושב על שרת מקומי

כלי ענן לא מגיע אליו בלי לפתוח את השרת החוצה או לבנות לו שכבת API. ה-On-Prem Agent מחבר את Make ל-SAP בלי לחשוף את השרת לאינטרנט.

הכללים שייכים לרכש, לא למערכת

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

קריאה אחת במקום ייצוא

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

התוצאות

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

למה Make Enterprise

יש לכם תהליך פנימי כזה?

תהליך שגוזל זמן לאנשים אבל אין לו בעלים מובהק לפיתוח. זה בדיוק מה ש-Make Enterprise פותר.