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