הקופה יודעת מה נמכר, מתי, באיזה סניף ובאיזה מחיר. ה-ERP יודע מה קניתם, מה נשאר במחסן, כמה זה עלה ומה נרשם בספרים. כמעט כל שאלה ניהולית ברשת מסעדות או ברשת קמעונאית יושבת בתפר בין השתיים: מה הרווח של הסניף, לאן נעלם המלאי, אם המבצע השתלם. ובלי חיבור, את התפר הזה סוגר מישהו באקסל, פעם בחודש.
המאמר הזה מיועד למי שמחפש "אינטגרציה בין קופה לפריוריטי" או "חיבור קופה לחשבשבת", ורוצה להבין, לפני השיחה עם המיישם, מה אפשר לקבל מהחיבור, באילו דרכים עושים אותו, ואיפה הוא נופל.
מה יושב בקופה ומה יושב ב-ERP
הקופה וה-ERP מחזיקים שני חצאים של אותו עסק. הקופה מחזיקה את צד המכירה, ברזולוציה גבוהה. ה-ERP מחזיק את צד העלות ואת הספרים.
בקופה נמצאות העסקאות עצמן: כל שורה שנמכרה, הפריט, הכמות, המחיר, ההנחה שניתנה, השעה, הסניף, הקופאי ואמצעי התשלום. שם נמצאים גם המבצעים, הביטולים והזיכויים, ובמסעדות גם השולחן, המלצר ומקור ההזמנה.
ב-ERP נמצאים הרכש וחשבוניות הספקים, המלאי ותנועות המלאי, העלויות, המחירון, הנהלת החשבונות, ולפעמים עץ המוצר או המתכון. זה המקום שבו יודעים מה הפריט עלה, ולא רק במה הוא נמכר.
כל מערכת טובה במה שהיא נבנתה לו. הבעיה מתחילה כששואלים שאלה שחוצה את הגבול.
השאלות שצריכות את שתי המערכות
רוב השאלות שעולות בישיבת הנהלה של רשת צריכות נתון אחד מהקופה ונתון אחד מה-ERP. אף אחת מהמערכות לא עונה עליהן לבד.
| השאלה | מה צריך מהקופה | מה צריך מה-ERP |
|---|---|---|
| מה הרווח הגולמי של כל סניף, ושל כל פריט? | מכירות לפי פריט וסניף, אחרי הנחות | עלות הפריט, מהרכש או מעץ המוצר |
| לאן נעלם המלאי? | מה נמכר | מה נקנה, מה נספר, מה הועבר |
| המבצע הרוויח, או רק הגדיל מחזור? | כמות ומחיר בזמן המבצע ואחריו | העלות של הפריטים שבמבצע |
| הקופה סגרה נכון? | סיכום יומי לפי אמצעי תשלום | מה נרשם בבנק ובספרים |
| איפה השכר גבוה מדי ביחס למכירות? | מכירות לפי שעה וסניף | עלות השכר, ולרוב גם שעון הנוכחות |
השאלה השלישית היא דוגמה טובה. הקופה מראה שהמבצע הצליח: יותר עסקאות, מחזור גבוה יותר. ה-ERP יודע מה הפריטים האלה עלו. רק יחד רואים אם ההנחה ייצרה רווח, או רק הזיזה סחורה בשוליים נמוכים. על ההשוואה בין סניפים כתבנו במאמר על רווחיות לפי סניף.
שלוש דרכים לחבר קופה ל-ERP
יש שלוש דרכים מקובלות לחבר קופה ל-ERP: הממשק של יצרן המערכת, ייצוא תקופתי לקובץ, או שכבה נפרדת שקוראת את שתי המערכות ומחברת אותן. הן לא מוציאות זו את זו, ורוב העסקים מגיעים לשתיים מהן.
הממשק של היצרן או של המיישם. ליצרני ה-ERP ולספקי הקופות יש ברוב המקרים ממשק מוכן, ישירות או דרך בית תוכנה שמתמחה בזה. ברוב ההטמעות הוא נועד להנהלת חשבונות ולמלאי: הוא מעביר את המכירות מהקופה אל ה-ERP, לפעמים כשורות פריט ולפעמים כסיכום יומי לסניף, ומוריד את הכמויות מהמלאי. מה בדיוק עובר, באיזו תדירות ובאיזו רמת פירוט, משתנה ממערכת למערכת ומגרסה לגרסה. לכן זו השאלה הראשונה למיישם.
ייצוא לקובץ. הקופה מייצאת כל לילה קובץ, ומישהו, או תהליך מתוזמן, טוען אותו ל-ERP או לאקסל. זול ומהיר להקמה. גם שביר: הקובץ משנה מבנה, התהליך נופל בשקט, ומגלים את זה בסוף החודש.
שכבה שקוראת את שתי המערכות. מערכת BI, או מערכת AI מבוססת נתונים, שמתחברת לקופה ול-ERP, ולצידם למערכת השכר, לנוכחות ולפלטפורמות המשלוחים, קוראת מכולם, ומחברת את הנתונים על מפתח משותף: פריט, סניף, תאריך. הנתונים התפעוליים לא זזים. הקופה ממשיכה למכור, ה-ERP ממשיך לנהל ספרים, והחיבור חי בשכבה שמעליהם.
ההבדל המעשי: שתי הדרכים הראשונות מעבירות נתונים ממערכת למערכת, בכיוון אחד. השלישית לא מעבירה כלום, אלא מסתכלת על שתיהן יחד. לכן היא גם היחידה שעונה על השאלות מהטבלה בלי שמישהו יבנה דוח לכל שאלה.
למה ממשק שעובד עדיין לא עונה על השאלות הניהוליות
גם כשהממשק החשבונאי עובד מצוין, רוב השאלות הניהוליות נשארות באקסל. הסיבה פשוטה: הממשק נבנה לספרים, לא לניתוח.
הממשק מעביר את מה שהנהלת החשבונות צריכה: סכומי מכירה, מע"מ, אמצעי תשלום, כמויות למלאי. בהרבה הטמעות הוא לא מעביר את השעה, את הקופאי, את המבצע שבמסגרתו ניתנה ההנחה או את מקור ההזמנה. ובכיוון ההפוך, מה-ERP לקופה, עוברים בדרך כלל רק פריטים ומחירון, לא עלויות.
התוצאה היא שהספרים מסודרים, ושאלה כמו "מה הרווח לפי שעה בסניף הזה" עדיין דורשת ייצוא מהקופה, ייצוא מה-ERP, ומישהו שיחבר ביניהם.
המכשולים: מק"טים, תזמון, ביטולים ומע"מ
חיבור קופה ל-ERP נופל כמעט תמיד על ארבעה דברים: פריטים שלא תואמים, תזמון שונה של הרישום, טיפול בביטולים והחזרות, ומע"מ. אף אחד מהם לא טכני במהותו. כולם עניין של הגדרה.
מק"טים שלא תואמים. הקופה מכירה ברקוד או קוד פריט של הקופה. ה-ERP מכיר מק"ט של המחסן. הם לא תמיד אותו דבר, ובמיוחד לא כשפותחים פריט בקופה ביום עמוס, כשקונים בקרטון ומוכרים ביחידה, או כשהמוצר הנמכר אינו המוצר הנקנה. במסעדה זה הכלל: מוכרים מנה, קונים מרכיבים. המתכון הוא הגשר, ובלי מתכון מתוחזק אין תמחיר למנה.
תזמון. יום הקופה נגמר בסגירה, גם אם היא אחרי חצות. ה-ERP רושם לפי תאריך קלנדרי. חשבונית הספק מגיעה שבוע אחרי הסחורה. ספירת המלאי נעשתה ביום שלישי, והדוח רץ ליום ראשון. כשמשווים מכירות לעלויות צריך להשוות בדיוק את אותה תקופה, אחרת הפער שמוצאים הוא פער בתאריכים, לא בעסק.
ביטולים, החזרות וזיכויים. ביטול לפני תשלום, החזרה אחרי תשלום, זיכוי שמומש בסניף אחר, החזר שנעשה לאמצעי תשלום אחר. כל אחד מהם צריך להופיע באותה צורה בשתי המערכות, ולרוב הוא לא. לפני החיבור מחליטים איך סופרים כל מקרה, וכותבים את זה.
מע"מ. מחירי הקופה כוללים מע"מ. העלויות ב-ERP רשומות לרוב נטו. מי שמחלק מכירות ברוטו בעלות נטו מקבל רווח גולמי יפה ושגוי. זו הטעות השקטה ביותר ברשימה, כי המספר נראה סביר.
לרשימה מצטרפות העמלות: סליקה, פלטפורמות משלוחים, מועדוני הטבות. המכירה נרשמת בקופה במלואה, והעמלה מגיעה אחר כך כחשבונית ספק ב-ERP. אם לא משייכים אותה חזרה למכירות, הסניף שעובד הכי הרבה עם משלוחים נראה רווחי יותר ממה שהוא.
מה מנהל מקבל כשהקופה וה-ERP מחוברים
כשהקופה וה-ERP מחוברים נכון, המנהל מקבל ארבעה דברים שלא היו לו: רווח גולמי לפי סניף ופריט כל בוקר, פחת שמחושב ולא מנוחש, מבצעים שנמדדים ברווח, והתאמת קופה שנעשית לבד.
- רווח, ולא רק מחזור. הדוח היומי מראה לא רק כמה נמכר בכל סניף, אלא מה נשאר אחרי עלות המכר וההנחות. סניף עם מחזור גבוה ושוליים נמוכים מתגלה מיד, ולא בסגירת הרבעון.
- פחת מחושב. מלאי פתיחה ועוד קניות פחות מכירות אמור להיות שווה למלאי סגירה. הפער בין מה שאמור להיות למה שנספר הוא הפחת, לפי פריט ולפי סניף. בלי חיבור, הפער הזה הוא הערכה.
- מבצעים ברווח. מה קרה לשוליים של הקטגוריה בזמן המבצע, ומה קרה למכירות בשבוע שאחריו.
- התאמה שוטפת. סיכום הקופה לפי אמצעי תשלום מול מה שנכנס לבנק ונרשם בספרים, בלי לחכות לסוף החודש.
ומעל כל אלה, התראות: סניף שהשוליים שלו ירדו, פריט שהפחת שלו קפץ, יום שבו סיכום הקופה לא מתיישב עם הבנק.
חמש שאלות לפני שמחברים
לפני שחותמים על ממשק, כדאי לשאול חמש שאלות. התשובות קובעות מה באמת תקבלו.
- מה עובר בממשק: שורות פריט, או סיכום יומי לסניף? ואילו שדות: שעה, הנחה, מבצע, אמצעי תשלום?
- מי הבעלים של קטלוג הפריטים, ומה קורה כשפותחים פריט חדש בקופה?
- מתי הנתונים מתעדכנים, ומי יודע כשהממשק נופל?
- איך סופרים ביטולים, החזרות, זיכויים ועמלות, ואיפה זה כתוב?
- מי מאמת את המספרים מול הספרים בחודש הראשון?
אם לשאלה הראשונה אין תשובה ברורה, החיבור יסדר את הספרים, ולא את ישיבת ההנהלה.
ברשתות שעובדות עם מערכת אחת לקופה ולמלאי, השאלות האלה קטנות יותר, אבל לא נעלמות: השכר, הנוכחות ופלטפורמות המשלוחים עדיין יושבים בחוץ. על המערכות שאפשר לחבר כתבנו בעמוד האינטגרציות.
איפה Figureit נכנסת
Figureit היא מערכת AI מבוססת דאטה ליעילות עסקית. היא מתחברת לקופות ול-ERP, בין אם זו פריוריטי, חשבשבת או מערכת אחרת, ולצידן לשכר, לנוכחות ולפלטפורמות המשלוחים, ומחברת את הכול במקום אחד. את התאמת הפריטים, הטיפול במע"מ ובהחזרות והאימות מול הספרים עושה הצוות של Figureit בהקמה. אחר כך שואלים בעברית: "מה הרווח הגולמי של כל סניף השבוע, אחרי הנחות ופחת, ואיזה סניף ירד הכי הרבה?" ומקבלים טבלה, גרף, ואת שאלת ההמשך שואלים באותו מקום.
המערכת מציפה ועונה. אם לסגור מבצע, להעביר מלאי או לשנות איוש, מחליטים אתם.