ניתוח מערכות הוא הדרך שבה הופכים יעד עסקי מעורפל כמו "שיפור שימור לקוחות" לקבוצה ממוקדת של שאלות ניתוח שניתן לענות עליהן באמצעות נתונים ולהשתמש בהן לקבלת החלטות. מדריך זה מציע שיטה שלב אחר שלב: הגדרת ההחלטה, בחירת מדדי ביצוע מרכזיים (KPIs), קביעת נקודת ייחוס (Baseline), פילוח חכם, זיהוי מקורות נתונים וכתיבת השערות הניתנות לבדיקה.
התחילו מההחלטה, לא מלוח הבקרה (ניתוח מערכות)
ניתוח מערכות מתחיל בהגדרת ההחלטה שאתם מנסים לקבל, ולאחר מכן עבודה לאחור עד להוכחות המינימליות הנדרשות. אם תתחילו בלוחות בקרה (Dashboards), תסיימו עם טריוויה: תרשימים מעניינים שלא משנים את הצעד הבא שלכם.
אני משתמש בכלל פשוט בעבודה על מוצר וצמיחה: אם ניתוח לא יכול להגדיר את ההחלטה שהוא תומך בה, הוא עדיין לא ניתוח. זהו דיווח.
כתבו את ההחלטה שלכם במשפט אחד עם בחירה מחייבת:
"האם עלינו לעשות X או Y עבור קהל Z בשבועות ה-T הקרובים?"
דוגמאות שמגבילות את העבודה בפועל:
"האם עלינו להשיק התראות חיוב שנתיות ללקוחות בשירות עצמי ברבעון זה, או להתמקד בשיפור תהליך הקליטה (Onboarding)?"
"האם עלינו להרחיב את החיפוש הממומן למילות מפתח חדשות, או להשקיע את התקציב הזה במייל מחזור חיים?"
כאן צוותים נתקעים לעיתים קרובות בקבלת החלטות מבוססת קונצנזוס. אנשים מתווכחים על הטקטיקה המועדפת עליהם, לא על הראיות. ניסוח מבוסס החלטה מצמצם את המקום לפוליטיקה כי הוא הופך את הפשרה למפורשת. אם הצוות שלכם זקוק לעזרה ביישור קו לגבי המסגרת המתאימה ביותר לפני כתיבת השאלות, השתמשו ב-איך לבחור מסגרת קבלת החלטות לצוות שלכם כעבודת הכנה.
כעת הגדירו איך נראה "טוב" בהחלטה. זה עדיין לא KPI. זהו גבול. לדוגמה: "נשיק זאת רק אם זה ישפר את שימור הלקוחות ל-90 יום מבלי להגדיל את כמות פניות התמיכה ללקוח."
תרגום יעדים ל-KPIs והגדרה מדידה (ניתוח מערכות)
שאלות ניתוח צריכות להתחיל עם KPI אחד, הכתוב בצורה ששאילתת SQL תוכל לענות עליה. אם הגדרת ה-KPI שלכם לא יכולה לשרוד שאילתה, אתם תתווכחו עליה מאוחר יותר.
יעד כמו "הגדלת הפעלה" יכול להתמפות למדדים שונים לחלוטין: אירוע הערך הראשון, שיעור השלמת שלבי הקליטה, זמן להצלחה ראשונה, או המרה לתשלום. בחרו KPI ראשי אחד ו-KPI הגנה אחד. שניים זה מספיק לרוב ההחלטות.
השתמשו בטבלה זו כדי לכפות בהירות:
הצהרת יעד
KPI ראשי (הגדרה מדויקת)
KPI הגנה
מדוע ה-KPI הזה מתאים להחלטה
שיפור שימור
שימור לקוחות ל-90 יום לחשבונות SMB חדשים
פניות לתמיכה לכל חשבון פעיל
ההחלטה משפיעה על שימוש מתמשך, לא רק על רכישה
צמיחת הכנסות
שימור הכנסות נטו (NRR) לקבוצת לקוחות בינוניים
MRR שנטש
מונע "צמיחה" שהיא למעשה נטישה
הפחתת עלויות
עלות לכל פנייה שנפתרה
שביעות רצון לקוחות (CSAT)
מונע קיצוץ עלויות שפוגע בחוויה
כשאתם צריכים שפה משותפת ל-KPIs, אני מפנה צוותים להגדרות הקנוניות של מדדים נפוצים כמו שימור והמרה ב-עקרונות המדידה של גוגל ולאחר מכן מתאים אותם למציאות המוצר. הנקודה היא לא להעתיק את גוגל. הנקודה היא להפסיק להתווכח על מה מדד אומר.
קביעת נקודת ייחוס ויעד כדי ש"טוב יותר" לא יהיה סובייקטיבי
שאלה ניתוחית חזקה כוללת נקודת ייחוס (Baseline) וסף, אחרת לא ניתן לדעת אם התשובה משמעותית. "האם ההפעלה השתפרה?" היא שאלה חלשה. "האם ההפעלה השתפרה בלפחות 3 נקודות אחוז לעומת נקודת הייחוס של 8 השבועות האחרונים?" היא שאלה שניתן לפעול לפיה.
לנקודת הייחוס יש שלושה חלקים:
הערך הנוכחי, 2) חלון ההשוואה, ו-3) השונות הצפויה.
אם לא תתחשבו בשונות, תטעו ותראו רעש כאות. כאן אנשים מבלבלים בין מתאם לסיבתיות, או משיקים שינויים אחרי שבוע בר מזל.
אם אתם צריכים רענון מעשי על שונות, דף הוויקיפדיה על ניתוח שונות (ANOVA) הוא נקודת התחלה מוצקה. אתם לא צריכים להריץ ANOVA לכל החלטה עסקית, אבל אתם צריכים את המודל המנטלי: שינויים נצפים הם שילוב של השפעה ואקראיות.
דוגמה לנקודת ייחוס שמונעת החלטות גרועות:
נקודת ייחוס: "המרה מניסיון לתשלום עמדה בממוצע על 12.4% במהלך 10 השבועות האחרונים עם תנודה שבועית של פלוס/מינוס 1.1 נקודות אחוז."
יעד: "נתעדף יוזמה זו רק אם נראה לפחות +2.5 נקודות אחוז לאורך 4 שבועות."
היעד הזה הופך ללוגיקת ההחלטה שלכם. אם זה עומד ביעד, אתם מרחיבים. אם לא, אתם עוצרים או מבצעים איטרציה.
הוספת פילוח כדי שלא תבצעו אופטימיזציה לממוצע
פילוח הופך שאלת ניתוח אחת לתצוגה מוכנה להחלטה על ידי הצגת המקום שבו ההשפעה באמת מתרחשת. ללא פילוח, אתם יכולים בקלות "לנצח" ב-KPI הכללי בזמן שאתם מפסידים בפלח החשוב.
בחרו פלחים שממופים למנופים אמיתיים או להבדלים אמיתיים בין לקוחות. בפועל, הפלחים בעלי החזר ההשקעה (ROI) הגבוה ביותר נוטים להיות:
ערוץ רכישה (ממומן לעומת אורגני לעומת שותף)
גודל לקוח או דרגת תוכנית
שלב במחזור החיים (משתמשים חדשים לעומת ותיקים)
גיאוגרפיה כאשר תמחור, תשלום או רגולציה שונים
המלכודת היא פילוח מוקדם מדי. ראיתי צוותים מבזבזים שבועיים על פילוח לפי דגם מכשיר כאשר הגורם האמיתי היה דרגת התוכנית.
משפט פילוח טוב נראה כך: "נעריך את ה-KPI באופן כללי, ולאחר מכן לפי דרגת תוכנית וערוץ רכישה. אם ה-SMB משתפר אך השוק הבינוני יורד, אנחנו לא משיקים."
אם אתם רוצים דרך מובנית להשוות אפשרויות ברגע שהפלחים מתחילים למשוך אתכם לכיוונים שונים, מטריצת קבלת החלטות היא הכלי הנקי ביותר. אתם יכולים גם להעמיק עם הטקסונומיה הרחבה יותר ב-מסגרות קבלת החלטות: המדריך המלא כדי להימנע מהמצאת תהליך חדש בכל פעם.
זיהוי מקורות נתונים ופערי מכשור לפני כתיבת השערות
שאלת ניתוח טובה רק כמו מקור הנתונים שיכול לענות עליה. לפני שאתם מתחייבים לשאלה, רשמו מאיפה יגיעו הנתונים ואיזו מערכת "אמת" מחזיקה בהם.
מקורות טיפוסיים ומה הם טובים עבורם:
מקור נתונים
הכי טוב עבור
מצב כשל נפוץ
אירועי מוצר (מחסן נתונים)
התנהגות, משפכים, שימור
מאפייני אירוע חסרים, שמות לא עקביים
מערכת חיוב
הכנסות, שדרוגים, נטישה
שינויים רטרואקטיביים, החזרים שלא טופלו
CRM
צינור מכירות, שלבי עסקה
בעיות היגיינה של אנשי מכירות
פלטפורמת תמיכה
כרטיסים, קטגוריות, זמן לפתרון
זליגת תיוג לאורך זמן
אם אתם מוצאים פער במכשור, אל "תעריכו בקירוב" אלא אם ההחלטה בעלת סיכון נמוך. הערכות יוצרות ביטחון כוזב. הצוותים הטובים ביותר מתייחסים למכשור כאל משטח מוצר, לא כאל בקשה חד-פעמית.
עבור צוותים הבונים תהליכי עבודה מבוססי בינה מלאכותית, אני ממליץ גם לכתוב "חוזה נתונים" קצר לכל אירוע מפתח: שם, הגדרה, מאפיינים נדרשים ובעלים. זה מונע את המוות האיטי של המדדים שלכם לאורך זמן.
כתיבת השערות הניתנות לבדיקה שמחברות סיבה לתוצאה
השערה הניתנת לבדיקה מציינת את השינוי, הכיוון הצפוי, השפעת ה-KPI והפלח. זהו הגשר בין ניתוח לפעולה.
הנה תבנית שבה השתמשתי ב-SaaS, זירות מסחר ותפעול פנימי:
"אם נבצע [שינוי] עבור [פלח], אז [KPI] [יעלה/ירד] בלפחות [סף] בתוך [מסגרת זמן], מכיוון ש-[מנגנון]."
דוגמה:
"אם נוסיף רשימת תיוג לקליטה עבור ניסיונות שירות עצמי חדשים, אז ההפעלה (אירוע ערך ראשון תוך 7 ימים) תעלה בלפחות 2 נקודות אחוז תוך 4 שבועות, מכיוון שמשתמשים יגלו את זרימת העבודה המרכזית מהר יותר."
שתי הערות מעשיות שמפרידות השערות אמיתיות ממשאלות לב:
ראשית, סעיף ה"מכיוון ש" צריך להיות ניתן להפרכה. אם המנגנון הוא "משתמשים יאהבו את זה יותר", אי אפשר לבדוק זאת. אם המנגנון הוא "מפחית זמן להצלחה ראשונה", אפשר.
שנית, בחרו השפעה מינימלית ניתנת לזיהוי ששווה את עלות ההנדסה וההזדמנות. אם העסק שלכם צריך עלייה של 5 נקודות אחוז כדי שזה ישנה, תפסיקו לכתוב השערות שחוגגות 0.5 נקודות אחוז.
כאן ניתוח תרחישים מוכיח את ערכו. עבור החלטות בעלות סיכון גבוה, כתבו תוצאות של תרחיש אופטימי, צפוי ופסימי הקשורים לאותה הגדרת KPI. ל-Harvard Business Review יש סקירה שימושית על חשיבת תרחישים ככלי החלטה ב-מדריך לתכנון תרחישים.
הפיכת שאלות ניתוח ללוח אפשרויות שהצוות שלכם באמת יכול להשתמש בו
הדרך המהירה ביותר להפחית חשיבת יתר היא להציב כל אפשרות, הראיות שלה והתוצאות שלה זו לצד זו. כאן רוב הצוותים עדיין מסתמכים על מסמכים מפוזרים ושרשורים ארוכים, וזו הסיבה שהחלטות מרגישות איטיות גם כשהנתונים קיימים.
אני אוהב לבנות את התוצר כמפת אפשרויות:
אפשרות א', ב', ג'
עבור כל אחת: השפעת KPI צפויה, רמת ביטחון, פלחים מושפעים, סיכונים ותוצאות מסדר שני
כלל ההחלטה: אילו ראיות מפעילות "השקה", "איטרציה" או "עצירה"
תרשים זרימה פשוט של החלטות יכול לעזור אם הארגון שלכם זקוק לשערים מפורשים, אך בפועל, תצוגת לוח שימושית יותר כי היא שומרת על ההקשר עקבי ככל שמידע חדש מגיע. זו בדיוק הבעיה שלשמה נבנתה Lucid: הפיכת דילמה מבולגנת ללוח החלטות מובנה עם יתרונות, חסרונות ותוצאות, ואז מתן אפשרות להשוות בתצוגות רשת, טבלה או מיקוד ככל שההקשר משתנה.
אם אתם רוצים תהליך עבודה מוכן לצוות, התחילו עם הצהרת היעד הגולמית שלכם וזרקו אותה למפת אפשרויות, ואז שפרו כל עמודה עד שהשאלות יהפכו לניתנות לבדיקה. הצוותים שלנו משלבים זאת לעיתים קרובות עם צלילה לעומק לאופן שבו מנהלי מוצר וצוותי UX משתמשים בעוזר בינה מלאכותית אישי כדי להאיץ את הסינתזה מבלי לאבד קפדנות.
שאלות נפוצות
מהם 3 ה-KPIs המובילים?
אין שלושה מובילים אוניברסליים, אך רוב העסקים יכולים לעגן החלטות בהכנסות (NRR או MRR), שימור (שימור לקוחות או קבוצות) ויעילות רכישה (CAC או תקופת החזר). שלושת הנכונים תלויים בהחלטה ובמודל העסקי שלכם.
מהם היתרונות והחסרונות של בינה מלאכותית לעבודת ניתוח?
בינה מלאכותית מצוינת למבנה של קלטים מבולגנים, יצירת השערות מועמדות וזיהוי פלחים או מדדי הגנה חסרים. החיסרון הוא ביטחון כוזב: בינה מלאכותית תסכם בביטחון נתונים חלשים, לכן אתם עדיין צריכים הגדרות נקיות, נקודות ייחוס ומכשור.
מהם 5 היתרונות ו-5 החסרונות של בינה מלאכותית?
יתרונות: מהירות, עקביות, רוחב סיעור מוחות, סינתזה מהירה ותיעוד החלטות. חסרונות: עובדות הזויות, הטיות נסתרות, סיכוני פרטיות, הסתמכות יתר ותוצרים שבירים כאשר הגדרות הקלט אינן ברורות.
איך מחשבים MAP?
MAP מתייחס בדרך כלל ל-Mean Average Precision באחזור מידע, לא לניתוח KPI עסקי. אם התכוונתם למדד שיווקי, הבהירו אם אתם מתכוונים למשתמשים פעילים חודשיים (MAU), מחיר ממוצע או משהו אחר, ואז הגדירו זאת במדויק לפני החישוב.
הצעד הבא: כתבו שאלה אחת מוכנה להחלטה היום
בחרו יעד אמיתי שאתם מתווכחים עליו כרגע. כתבו את משפט ההחלטה, בחרו KPI אחד עם הגדרה מדויקת, קבעו חלון נקודת ייחוס והוסיפו פלח אחד שחשוב. לאחר מכן המירו זאת להשערה עם סף שבאמת הייתם פועלים לפיו.
אם אתם רוצים שזה יהפוך ללוח אפשרויות מובנה שניתן להשוות זו לצד זו, התחילו טיוטה ב-Lucid על ידי יצירת חשבון ב-יצירת סביבת העבודה שלכם ב-Lucid והדביקו את היעד שלכם כפי שהוא. הגרסה הראשונה שלכם לא צריכה להיות נקייה. המבנה יכפה בהירות.
