השעה 3:07 לפנות בוקר. הטלפון שלך מזמזם עם עוד מכירה מוגזמת של Shopify. הלקוח קנה את היחידה האחרונה של משהו שאתה יודע שאזל מהמלאי לפני שלושה ימים. SAP Business One אומר אפס. Shopify אומר שתיים. זהו הדפוס.
אם אתם מפעילים מסחר אלקטרוני על גבי SAP Business One, גרסה מסוימת של זה עולה לכם כסף ובשינה. בעיות סינכרון נובעות לעיתים רחוקות מדבר אחד מקולקל. הן נובעות מקבוצה קטנה של מחלקות כשל, ורוב המפעילים מטפלים בסימפטום במקום במחלקה.
בעיות סנכרון מלאי של מסחר אלקטרוני ב-SAP B1 נובעות כמעט תמיד מאחת מארבע קבוצות כשל: פערים בתזמון ובזמן השהייה בין SAP לחנות, אי התאמות במודל נתונים סביב SKUs ומחסנים, תקלות בתוכנה או במחברים, ושגיאות תצורת תהליכים בתוך SAP. תיקונן דורש זיהוי איזו קבוצה רלוונטית, מכיוון שהפתרון לתזמון לא יתקן בעיית מודל נתונים.
מהו בעצם סנכרון מלאי מסחר אלקטרוני של SAP B1
סנכרון מלאי של מסחר אלקטרוני ב-SAP B1 הוא תהליך של שמירה על דיוק של רמות מלאי, נתוני מוצרים והתחייבויות הזמנות בין SAP Business One לבין ערוץ מכירות מקוון אחד או יותר. הוא פועל דרך תוכנה ביניים או מחבר, ודורש ששתי המערכות יסכימו על מבנה ה-SKU, הגדרות המחסן ותזמון העדכון. ללא הסכם זה, מתקבלים מכירת יתר, מחסור במלאי או מלאי דמה שהחנות מאמינה שקיים, אך המחסן לא.
ארבע סוגי הכשלים העומדים מאחורי רוב בעיות הסנכרון של SAP B1
רוב מנהלי התפעול מתארים את בעיית הסנכרון שלהם באותו אופן: המספרים שגויים. סיבה זו כמעט תמיד נופלת תחת אחת מארבע קטגוריות. ידיעת הקטגוריה שבה אתם נמצאים אומרת לכם מה לתקן ולמי התיקון.
1. כשלים בתזמון ובזמן השהייה
זוהי מחלקת הכשלים הנפוצה ביותר. חזית החנות שלך קוראת את המלאי בתדירות מסוימת, SAP מעדכן בתדירות אחרת, ותוכנת הביניים מתאמת בתדירות שלישית. בין לבין, הלקוחות ממשיכים לקנות. אם הסנכרון שלך פועל כל חמש עשרה דקות וה-SKU הנמכר ביותר שלך נמכר כל ארבע, תמכור יתר על המידה את המוצר הזה בכל שבוע. בעיות תזמון מחמירות במהלך מבצעים ושיאים עונתיים, וזה בדיוק הזמן שבו אתה הכי פחות יכול להרשות לעצמך אותם.
2. אי התאמות במודל הנתונים
SAP B1 חושב במונחים של פריטים, מחסנים, מיקומי סל וקבוצות יחידת מידה (UoM). Shopify חושב במוצרים, וריאציות ומיקומים. למג'נטו, BigCommerce ואמזון לכל אחת מהן יש מודל משלה. כאשר פריט SAP משתרע על פני שלושה מחסנים והחנות שלך יודעת רק מספר זמין אחד, ההיגיון שבמהלך איחוד שלושת המחסנים הללו לאחד הוא המקום שבו קיימות רוב חוסר ההתאמות.
תסמינים נפוצים: מלאי המוצג כזמין אך נמצא בפועל במחסן שאינו ניתן למכירה, וריאציות הממופות באופן שגוי להורים, וחבילות שמפחיתות את הרכיבים הלא נכונים.
3. כשלים בתוכנת ביניים ובחיבורים
שכבת האינטגרציה נבנית לעיתים רחוקות על ידי אותו צוות שמפעיל את כל אחת מהמערכות, ובפער הזה מצטברים כשלים שקטים. קריאות API מגיעות לפסק זמן ולא מנסות שוב. תורים חוזרים בזמן קפיצות תנועה. עדכון פלטפורמה משנה סכימת webhook ותוכנת ביניים ממשיכה לפרסם בקוד הישן במשך שבועות לפני שמישהו שם לב.
כשלים אלה הם ערמומיים משום שלעתים קרובות הם אינם מייצרים התראות שהצוות רואה. האינטגרציה עבדה הבוקר, כך שאף אחד לא בודק, ובצהריים אתם מאתיים הזמנות בפיגור.
4. כשלים בתהליך ובתצורה
לפעמים המערכות תקינות והבעיה היא איך הצוות משתמש בהן. התאמות מלאי ידניות שעוקפות את הסנכרון, העברות מחסן שנרשמות בקבוצות, החזרות שמעובדות דרך החנות אך לעולם לא משתקפות ל-SAP, מלאי שלילי המותר על ידי הגדרה, והרשאות שמאפשרות למשתמש הלא נכון לדרוס ספירות. אף רכישה של תוכנה לא פותרת את זה.
כיצד לאבחן איזו מחלקת כשל יש לך
אבחון מהיר. כדי לזהות את מחלקת הכשל בסנכרון המלאי שלך ב-SAP B1, בדוק מכירה יתרה או חוסר מלאי אחרונים וענה על שלוש שאלות. ראשית, מה הציגה כל מערכת ברגע המכירה, והאם חותמת הזמן האחרונה של הסנכרון המוצלח קדמה לפער? שנית, האם הפריט כלל מספר מחסנים, וריאציות או חבילות? שלישית, האם בוצעה התאמה ידנית ב-24 השעות שקדמו לכך? התשובות ממופות למחלקות כשל בתזמון, מודל נתונים, תוכנה ביניים או תהליך.
לוחות מחוונים משקרים במהלך האבחון משום שהם מראים את המצב כעת, ולא את המצב בו התרחשה הבעיה. השיטה האמינה היחידה היא סיור תקרית: שחזור ציר הזמן של כשל אמיתי אחד ובדיקת חילוקי דעות בין המערכות.
תיקונים, מאורגנים לפי מחלקת כשל
עבור בעיות תזמון והשהייה:
- העברת SKUs במהירות גבוהה לנתיב סנכרון כמעט בזמן אמת, גם אם שאר הקטלוג נשאר מתוזמן
- הוסיפו אחסון מלאי בצד המסחר האלקטרוני עבור מוצרים שנעים מהר יותר מקצב הסנכרון שלכם.
- השתמשו בהקטנות המונעות על ידי webhook במקום בקריאות מבוססות סקר
עבור אי התאמות במודל נתונים:
- תיעוד המיפוי בין מחסני SAP למודל מיקום החנות ובדיקתו מדי רבעון
- סטנדרטיזציה של מבנה ה-SKU ואכיפתו בעת יצירת הפריט, לא במהלך הסנכרון
- עבור חבילות וערכות, בחרו מערכת רשומה אחת ומנעו מהשנייה להפחית רכיבים
- סמן מחסנים שאינם ניתנים למכירה והדר אותם מהחישוב הזמין
עבור בעיות תוכנה ותחברות:
- ניטור והתרעה בשכבת האינטגרציה, לא רק בנקודות הקצה
- דרוש מדיניות ניסיון חוזר עם טיפול באותיות ללא אישור עבור קריאות API שנכשלו
- עקוב אחר כל שינוי בסכימה משני הצדדים ובדוק את האינטגרציה מולה
- דעו את הסכם ה-SLA ואת נתיב ההסלמה של ספק התוכנה שלכם לפני שאתם זקוקים לו
עבור כשלים בתהליך ובתצורה:
- סגור את הפירצה בהתאמה הידנית. כל שינוי בספירה ב-SAP אמור להפעיל סנכרון.
- הבא העברות מחסן לאותו קצב כמו עדכוני מכירות
- מסחר אלקטרוני שיקוף חוזר ל-SAP באותו יום בו הוא מפרסם
- ביקורת רבעונית על הרשאות המשתמש והסרה של הרשאות כתיבה מכל מי שאינו זקוק להן
מתי להחליף את תוכנת הביניים שלך לעומת מתי לשמור אותה
החלטת החלפה. החלף את תוכנת הביניים של SAP B1 למסחר אלקטרוני כאשר שלושה תנאים מתקיימים בו זמנית: אירועי סנכרון חוזרים על עצמם לאחר שהספק מיישם תיקונים, הספק אינו יכול להסביר את הסיבות הבסיסיות בפירוט טכני, וצרכי העסק שלך גדלו על מה שהמחבר תומך בו. שמור אותו אם האירועים נפתרים וההתאמה הארכיטקטונית עדיין תואמת את מפת הדרכים שלך. צוותים רבים מחליפים מוקדם מדי, ואז מגלים שהכשל האמיתי היה במודל הנתונים שלהם.
דפוסים שתזהו
קחו לדוגמה קמעונאית ביגוד בינונית שמפעילה מבצע בן יומיים שמוכרת יותר מדי ממק"ט דגל בכמה מאות יחידות. האינסטינקט הוא להאשים את המבצע, אבל הסיבה הסבירה יותר היא מודל הנתונים: הפריט מחולק למחסן ראשי ולמחסן לעיבוד החזרות, ותוכנת הביניים מסכמת את שניהם למספר הזמין. המבצע רק חשף את מה שהמיפוי כבר עשה בציר זמן איטי יותר.
קחו לדוגמה מפיץ שהתוכנה שלו מורידה בשקט אחוז קטן מעדכוני המלאי בשעות השיא של אחר הצהריים. למחבר אין תור ללא אותיות, כך שעדכונים שנכשלו פשוט נעלמים. אף אחד לא שם לב עד שמנהל מחסן משווה ידנית דוח SAP שבועי לסך הכל של החנות. דפוס זה נפוץ דווקא משום שהוא בלתי נראה - האינטגרציה מדווחת על הצלחה בקריאות שעברו, ושום דבר לא מדווח על השיחות שלא.
קחו לדוגמה צוות שרואה מכירות יתר ממוקדות בימי שני. הסיבה לכך היא בדרך כלל התאמות ידניות בסופי שבוע ב-SAP שעוקפות את הסנכרון. אף שינוי בתוכנה לא פותר את זה. שינוי בתהליך העבודה - ניתוב כל ההתאמות דרך הנתיב המסונכרן - פותר את זה תוך שבוע.
אלו שלושת הדפוסים המופיעים בתדירות הגבוהה ביותר בשיעורי הכישלון הנ"ל. אם אחד מהם נשמע כמו בוקר יום שני שלכם, אתם כנראה כבר יודעים באיזה שיעור אתם נמצאים.
רשימת בדיקה לפני תחילת העבודה עבור תקינות סנכרון מלאי מסחר אלקטרוני של SAP B1
- קצב הסנכרון המתועד לפי רמת מהירות SKU
- מיפוי ממחסן למיקום עדכני ונבדק בתשעים הימים האחרונים
- התראות ניטור תוכנה מנותבות לאדם שיראה אותן בפועל
- מדיניות ניסיון חוזר ומדיניות מודעות ללא אישור אושרה עם ספק האינטגרציה שלך
- תהליך עבודה של כוונון ידני נסגר, או שנרשם וסונכרן אוטומטית
- שיקוף החזרות מחנות ל-SAP אומתה ברבעון זה
- מעקב אחר מקרי מכירה יתרה ואובדן מלאי באמצעות תיוג סיבה בסיסית
כאשר מסחר אלקטרוני מבוסס SAP הופך לתשובה
אם עבדתם על ארבע סוגי הכשל והתיקונים עדיין לא תקפים, ייתכן שהארכיטקטורה עצמה היא המגבלה. מסחר אלקטרוני תלוי תוכנה (middleware) צובר מורכבות לאורך זמן - כל ערוץ, קידום או כלל מחסן חדש מוסיף עוד תפר התאמה, ובסופו של דבר הצוות מבלה יותר שעות בתחזוקת האינטגרציה מאשר בגידול העסק. פלטפורמת מסחר אלקטרוני מקורית של SAP מסירה לחלוטין את שכבת האינטגרציה הזו על ידי הפעלה ישירה על SAP Business One, כך שמלאי, חשבונות לקוחות, תמחור ולוגיקת הזמנות חולקים מקור אמת יחיד ללא תוכנה שתכשל. זהו המודל עליו בנוי FocusPoint, והוא נוטה להיות הגיוני עבור מפעילים שיומן האירועים שלהם ממשיך להצביע חזרה לאינטגרציה, לא משנה למי הוא שייך. זו לא תהיה התשובה הנכונה עבור כולם - אבל אם אתם קוראים את זה בשעה 3 לפנות בוקר בפעם השלישית ברבעון הזה, כדאי להעריך לפני שאתם מחדשים את חוזה המחבר.
שאלות נפוצות
מהי הסיבה הנפוצה ביותר לבעיות סנכרון מלאי ב-SAP B1? כשלים בתזמון ובזמן השהייה הם הנפוצים ביותר, ואחריהם חוסר התאמה במודל הנתונים. שניהם מייצרים מספרים שגויים אך דורשים תיקונים שונים.
האם SAP B1 יכול לסנכרן מלאי בזמן אמת עם Shopify? כן, באמצעות תוכנת ביניים המונעת על ידי webhook שדוחפת עדכונים בהתאם לשינויים ולא לפי לוח זמנים. סנכרון בזמן אמת אפשרי עבור רוב הקטלוגים, אם כי העלות עולה עם נפח העסקאות ומספר ה-SKU.
מדוע שינויים במלאי מתרחשים גם כאשר תוכנת הביניים מדווחת על הצלחה? תוכנת הביניים מדווחת לעיתים קרובות על קריאה ל-API כמוצלחת כאשר הקריאה התקבלה, ולא כאשר הנתונים הותאמו. שינויים נובעים בדרך כלל מניסיונות חוזרים שמעולם לא התרחשו, אי התאמות בסכימה שנכפו בשקט, או התאמות ידניות מחוץ לנתיב הסנכרון.
באיזו תדירות יש לסנכרן את המלאי בין SAP B1 לפלטפורמת המסחר האלקטרוני שלי? התאם את הקצב למהירות. SKUs הנעים במהירות מצדיקים סנכרון כמעט בזמן אמת. מוצרים הנעים לאט יכולים להסתנכרן כל שעה או פחות. לוח זמנים אחד שמתאים לכולם כמעט תמיד שגוי עבור חלק מהקטלוג שלך.
האם זו בעיה ב-SAP B1 או בעיית תוכנה בינונית? בדרך כלל תוכנה בינונית או תהליך. SAP B1 עצמו גורם לעיתים רחוקות לבעיות סינכרון. שכבת האינטגרציה והאופן שבו צוותים משתמשים ב-SAP הם המקורות השכיחים יותר.
האם אני יכול לתקן את הבעיות האלה מבלי להחליף את המערכת הנוכחית שלי? ברוב המקרים, כן. תיקוני תהליכים ותצורה פותרים חלק גדול מבעיות הסנכרון ללא החלפת תוכנה. החלפה היא התשובה הנכונה רק לאחר שתיקונים זולים יותר נכשלו.
מה לעשות הלאה
אם הצוות שלכם סובל ממכירות יתר חוזרות ונשנות, הצעד הקטן ביותר והשימושי הוא לבחור אירוע אחד משלושים הימים האחרונים ולעבור אותו על ארבע קטגוריות הכשל הנ"ל. בדרך כלל תדעו לפי הקטגוריה השנייה איזו מהן אחראית לבעיה. החלק הקשה ביותר אינו התיקון. זה לשבור את ההרגל להתייחס לכל כשל בסנכרון כאל אותה בעיה.
בקשו הצעת מחיר ללא תשלום וללא התחייבות, המותאמת לסביבת SAP Business One שלכם, לאינטגרציות ולזרימות עבודה של מסחר אלקטרוני B2B ו-B2C.
