חיבור חנות מקוונת ל-ERP

ארבעה זרמים, לא אחד

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

המלאי: למה ERP לבד לא מספיק

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

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

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

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

תור, ולא קריאה מיידית

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

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

שני דברים פותרים את זה יחד, ושניהם נדרשים:

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

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

מזהה אחד, והוא לא ברור מאליו

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

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

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

חשבוניות דיגיטליות ורגע הקנייה

המעבר לחשבוניות שמונפקות מול רשות המס נוגע בחנות בנקודה הרגישה ביותר: סיום הקנייה.

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

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

איך אני עובד על זה

עיסוק בתחום מאז 2004, עבודה על מערכות AI מאז 2023, פרויקטים ללקוחות בארבע עשרה מדינות. אני ארכיטקט עצמאי ולא ספק פלטפורמה, ולכן המסקנה «אל תחליפו את החנות ואל תחליפו את ה-ERP, תקנו שני זרמים» היא תוצאה לגיטימית, ובתחום הזה גם הנפוצה.

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