להפוך קושי למקרה עסקי: איך מחשבים עם הלקוח בלי לנפח את הבעיה

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

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

לעבור על מקרה אמיתי

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

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

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

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

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

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

תרגיל חישוב, בלי להלביש עליו חיסכון שלא הוכח

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

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

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

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

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

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

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

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

להמשך העבודה

השאלה שעוזרת לבדוק את התהליך הקיים · העברת המקרה העסקי בתוך הארגון.