מערכת ניהול הזמנות שלא מדברת עם המלאי עולה לכם יותר ממה שנראה

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

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

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

קודם ממפים, אחר כך בוחרים כלי

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

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

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

• ← הזמנות נכנסות – כל ערוץ שבו לקוחות מזמינים: אתר, טלפון, וואטסאפ, איש מכירות בשטח.
• ← בדיקת מלאי – מי בודק, מול איזה קובץ או מערכת, וכמה זמן זה לוקח.
• ← עדכון ללקוח – מי כותב לו ומתי, ומה קורה כשאף אחד לא כתב.
• ← העתקות ידניות – כל מקום שבו נתון עובר מיד ליד. כאן מחברים קודם.

בונים את ליבת ההזמנה: טבלה אחת, סטטוסים ברורים

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

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

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

מחברים את המלאי, ושם מתחילה האוטומציה האמיתית

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

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

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

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

ווטסאפ, לקוחות וסיפור קטן על ישיבה שנגמרה

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

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

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

הצעד הכי חשוב

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

איפה זה נתקע, ומה משתנה בניסיון השני

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

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

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

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

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

מה עושים מחר בבוקר

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

יש לכם תהליך הזמנות שחוזר על עצמו וגוזל זמן? בואו נדבר, שיחת ייעוץ קצרה ללא עלות לקביעת שיחת ייעוץ