מה קורה אצלכם אחרי שלקוח מבצע הזמנה באתר?
ניקח תרחיש לדוגמה: ההזמנה נכנסת, אישור נשלח ללקוח, ומישהו במשרד פותח את המייל. הוא מעתיק את הפרטים למערכת ההזמנות, בודק שיש מלאי ושולח הודעה למחסן. בהמשך הלקוח מתקשר לברר מתי המשלוח מגיע. מי שעונה לו צריך לשאול אדם נוסף, כי באתר מופיע רק שהתשלום התקבל.
ההזמנה כנראה תצא. הלקוח אולי אפילו יהיה מרוצה. אבל כדי שזה יקרה, כמה אנשים היו צריכים להעביר ביניהם מידע שכבר היה במערכת.
קל להתרגל לעבודה הזאת. היא נכנסת בין שיחות, מיילים ומשימות אחרות, עד שאף אחד כבר לא שואל למה צריך לעשות אותה. כשמסתכלים על עלות האתר או על המנוי למערכת ניהול הלקוחות, השעות האלה לא מופיעות שם.
איפה המחיר הזה מצטבר
נתחיל בדבר שאפשר לספור: זמן העבודה. כמה דקות נדרשות כדי להעביר הזמנה, לבדוק אותה ולענות על שאלות לגביה? וכמה פעמים עושים את זה ביום?
לצורך המחשה בלבד, אם העברה ידנית של הזמנה לוקחת ארבע דקות ויש 30 הזמנות ביום, מדובר בשעתיים ביום. ב־22 ימי עבודה אלה 44 שעות בחודש. זה אינו נתון מלקוח שלנו, אלא חישוב פשוט שאפשר לעשות עם המספרים שלכם.
החישוב הזה עדיין לא כולל תיקונים. כתובת שהועתקה לא נכון, הזמנה שנפתחה פעמיים או שינוי שהלקוח ביקש בטלפון ולא הגיע למחסן. כל מקרה כזה מחזיר את העובדים לאחור: למצוא מה קרה, לברר מי יודע ולתקן גם במקומות האחרים.
ויש גם ההמתנה. לפעמים הפעולה עצמה אורכת דקה, אבל ההזמנה מחכה שעות עד שמישהו מגיע אליה. אם האדם שמכיר את התהליך אינו במשרד, העובדים האחרים צריכים להבין איפה הוא עצר. כך נוצרת תלות באנשים גם במשימות שאפשר להגדיר מראש.
למה כל מערכת מציגה תשובה אחרת
נחזור להזמנה. באתר היא שולמה, במחסן היא עוד לא טופלה, ובמערכת ניהול הלקוחות אין תיעוד של הבקשה לשנות כתובת. שלושת הדברים יכולים להיות נכונים באותו רגע. הבעיה מתחילה כשכל מחלקה רואה רק אחד מהם.
כשאתם שואלים כמה הזמנות עדיין פתוחות, מישהו צריך קודם לברר למה אתם מתכוונים: הזמנות שלא שולמו, שלא נארזו או שלא נמסרו? גם לאחר שמסכימים על ההגדרה, צריך לאסוף את המידע.
חיבור מערכות עסקיות מחייב להחליט מה כל מצב אומר ואיזו מערכת אחראית לעדכן אותו. מי קובע שההזמנה נשלחה? איפה נשמרת הכתובת המעודכנת? מה קורה אם בוטל רק חלק מההזמנה?
בלי ההחלטות האלה, אפשר להעביר נתונים מהר יותר ועדיין לקבל תשובות סותרות. לכן אפיון התהליך צריך לבוא לפני הפיתוח: לעבור עם האנשים שמבצעים את העבודה על הזמנה אמיתית, כולל החריגים, ולהגדיר מה צריך לקרות בכל שלב.
איך נראה חיבור שעוזר בעבודה
בדוגמה שלנו, אפשר לתכנן שהזמנה ששולמה באתר תיפתח במערכת התפעול בלי הקלדה נוספת. המחסן יקבל את הפרטים הדרושים לו, ומצב הטיפול יחזור למקום שבו צוות השירות יכול לראות אותו.
זה הרעיון של אינטגרציה בין מערכות: להעביר מידע ולהפעיל תהליכים בין תוכנות נפרדות. לעיתים משתמשים ב־API, ממשק שמאפשר לתוכנות לתקשר, ולעיתים נדרשים כלי תיווך או פיתוח ייעודי. הסבר על חיבור יישומים באתר IBM.
אבל צריך לתכנן גם את היום שבו החיבור לא יעבוד. אם המערכת המקבלת אינה זמינה, ההזמנה צריכה להישאר במעקב. אם מנסים להעביר אותה שוב, צריך למנוע יצירה של הזמנה כפולה. ומישהו צריך לדעת שההעברה נכשלה ולקבל אחריות על הטיפול.
אלה שאלות שכדאי להכניס לאפיון ולהצעת העבודה: מה קורה בזמן תקלה, איך מזהים אותה ומי מטפל בה אחרי העלייה לאוויר. חיבור שנבנה בלי התייחסות להמשך יכול להשאיר אתכם עם תהליך שאף אחד כבר לא בודק ידנית, אבל גם אינו מפוקח היטב.
מה AI מוסיף כשיש מידע שאפשר להסתמך עליו
כשפרטי ההזמנה, התשלום והטיפול זמינים יחד, אפשר לבנות דרך לשאול עליהם שאלות. למשל: אילו הזמנות ששולמו עדיין מחכות לטיפול? איפה התעכבנו השבוע? על אילו הזמנות הלקוחות כבר פנו לשירות?
כלי AI יכול לשמש ממשק לשאלות כאלה, אם בונים לו גישה למקורות המתאימים ובודקים את התשובות. חיבור מודל למידע הארגוני הוא דפוס עבודה מתועד; הוא דורש בין היתר התייחסות למידע שנשלף ולהרשאות הגישה. הסבר בתיעוד Microsoft.
עצם הוספת האפשרות לשאול שאלה אינה פותרת את בעיית הנתונים. אם מצב המשלוח לא עודכן, צריך שהמערכת תדע להציג את המגבלה הזאת. אם שני לקוחות מופיעים תחת אותו שם, צריך לזהות למי שייכת ההזמנה. לפני שסומכים על התשובה, בודקים אותה מול העבודה בפועל.
אפשר גם להגדיר התראה על הזמנה שממתינה מעבר לזמן שקבעתם, או לפתוח משימת טיפול באופן אוטומטי. פעולה כזאת לא בהכרח דורשת AI. כאשר הכלל ברור, אוטומציה רגילה יכולה להספיק. בפעולות שמשנות הזמנה או מעדכנות לקוח, צריך להחליט גם מה מותר לבצע אוטומטית ומה דורש אישור.
זה הכיוון שאנחנו מכנים ב־Digital Pro Lab ״מוח עסקי״: מקור מידע עסקי שאפשר לתשאל, לקבל ממנו התראות ולהפעיל דרכו תהליכים. כדי לבנות אותו, אנחנו מפתחים ומנהלים את המערכות הנדרשות ומחברים אותן לפעילות של העסק.
מתי נכון להתחיל
אם אותה עבודה ידנית חוזרת בכל יום, יש כבר תהליך שאפשר לבדוק. כשאתם עומדים להקים אתר חדש, להחליף CRM או להרחיב את הפעילות, יש גם הזדמנות להחליט איך המידע יעבור לפני שמקבעים שוב את ההרגלים הקיימים.
אפשר להתחיל מצורך אחד. למשל, שהזמנה תגיע למחסן עם כל הפרטים, או שצוות השירות יוכל לראות מה קרה לה בלי להתקשר לעובד אחר. הצורך הזה יגדיר אילו מערכות צריך לחבר ומה כדאי לפתח.
לפני שמחליטים אם העבודה כדאית, השוו בין העלות הקיימת לעלות השינוי. בדקו את שעות הטיפול והבירורים, את התקלות החוזרות ואת העיכובים, מול עלויות האפיון, הפיתוח והתחזוקה. אם התהליך נדיר ומשתנה בכל פעם, ייתכן שעבודה ידנית עדיין מתאימה לו.
גם החלפת מערכת אינה מסקנה אוטומטית. מתחילים בבדיקה של מה שכבר קיים: מה אפשר לחבר, מה מגביל את התהליך ואיפה באמת חסר כלי. לפעמים צריך חיבור קטן. לפעמים צריך לבנות מערכת טפסים או רכיב תפעולי שלא קיים היום.
הבדיקה שאפשר לעשות כבר השבוע
בחרו הזמנה אחת ועברו איתה מהאתר עד למסירה. שבו עם מי שמטפל בה בכל שלב, ובקשו שיראה לכם מה הוא עושה בפועל. רשמו איפה מעתיקים מידע, איפה מחכים לתשובה ואיפה נדרשת בדיקה נוספת.
מתוך המסלול הזה בחרו מעבר אחד לשיפור. הגדירו איך תדעו שהעבודה השתפרה: פחות הקלדות, פחות בירורים או פחות זמן עד שההזמנה מגיעה לטיפול. מדדו את המצב לפני השינוי ואחריו, ובדקו גם שהחריגים מטופלים.