שאלות ראיון לתפקיד אנליסט עסקי

גישה: מטרה ← בעלי עניין ← החלטות ← נתונים ← דרישות ← אימות

קודם כול אבהיר את המטרה העסקית. דשבורד צריך לתמוך בקבלת החלטות, ולא רק להציג נתונים. אשאל אילו החלטות הדשבורד אמור להזין, מי ישתמש בו, באיזו תדירות, אילו פעולות יינקטו בעקבותיו ומהן נקודות הכאב הקיימות. אחר כך אזהה את בעלי העניין: הנהלה בכירה, מנהלים, עובדי השטח, כספים, הנדסת נתונים, ציות וכל מי שאחראי על מערכות המקור. בעלי עניין שונים עשויים להזדקק לתצוגות שונות, להגדרות שונות ולתדירות רענון שונה. בשלב הבא אגדיר את המדדים ואת דרישות הנתונים. לכל מדד אתעד הגדרה, בעלים, טבלה או מערכת מקור, לוגיקת חישוב, מסננים, רמת פירוט (grain), תדירות רענון ומגבלות ידועות. אבהיר גם הרשאות גישה, צורכי ייצוא, אפשרויות drill-down, התראות ודרישות למגמות היסטוריות. אחרי ניסוח הדרישות אתקף אותן מול בעלי העניין בעזרת מוקאפים או wireframes. אוודא שהדשבורד עונה על ההחלטות שלשמן נבנה ושהגדרות המדדים תואמות את מקור האמת. לבסוף אגדיר קריטריוני קבלה ותרחישי UAT, כדי שאפשר יהיה לבדוק את הדשבורד לפני השחרור.

גישה: הבעיה לפני הפתרון

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

גישה: הבהרת השינוי ← הערכת ההשפעה ← תעדוף ← תקשורת

קודם כול אבהיר מה השתנה ולמה. האם מדובר בצורך עסקי חדש, בדרישה שפוספסה, בשינוי רגולטורי, בהעדפה של בעל עניין, באילוץ טכני או בממצא מהבדיקות? הסיבה חשובה, כי חלק מהשינויים הם חובה ואחרים הם עניין של פשרות. אחר כך אעריך את ההשפעה: היקף, לוחות זמנים, עלות, תלויות, חוויית משתמש, מודל נתונים, אינטגרציות, בדיקות, הדרכה וסיכון. אעבוד עם צוותי המוצר, הפיתוח, ה-QA ובעלי העניין העסקיים כדי להעריך את ההשפעה. בשלב הבא נחליט איך לטפל בשינוי: לכלול אותו עכשיו, לדחות אותו לשלב מאוחר יותר, להחליף בו דרישה אחרת, או לוותר עליו אם הוא לא תומך במטרה. את ההחלטה ואת הנימוק לה צריך לתעד ביומן שינויים. לבסוף אעדכן את כל הגורמים בבהירות. התוצאה הגרועה ביותר היא זחילת היקף (scope creep) סמויה. BA חזק הופך את הפשרות לגלויות ושומר על הסכמה בין בעלי העניין לגבי מה יימסר ומה לא.

גישה: מצב קיים ← צווארי בקבוק ← גורם שורש ← מצב עתידי ← מדדים

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

גישה: היקף ← גורמים מעורבים ← זרימה ← חריגים ← בקרות

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

גישה: JOIN ← סינון ← קיבוץ לפי חודש וקטגוריה ← סכימת הכנסות

נניח שיש לנו את הטבלאות orders, order_items ו-products. הצעד הראשון והחשוב הוא לזהות את רמת הפירוט (grain). ההכנסות עשויות להישמר ברמת ההזמנה או ברמת הפריט. אם קטגוריית המוצר נמצאת ברמת הפריט, צריך לצבור את הכנסות הפריטים לפי קטגוריה, ולא לחבר את הקטגוריה ישירות להכנסות ברמת ההזמנה ובכך לשכפל סכומים. השאילתה צריכה לבצע JOIN בין order_items ל-products לפי product_id, לחבר את orders כדי לקבל את תאריך ההזמנה ואת הסטטוס שלה, לסנן להזמנות שהושלמו, לקבץ לפי date_trunc חודשי ולפי קטגוריית מוצר, ואז לסכום את הכנסות הפריטים. אם קיימים החזרים או הנחות, יש להבהיר אם ההכנסות צריכות להיות ברוטו או נטו. תשובה חזקה מזכירה גם אימות: השוואת סך ההכנסות החודשיות מהשאילתה לדוח הכנסות של הכספים או של מקור האמת, בדיקה של קטגוריות מוצר חסרות, ווידוא שהזמנות שבוטלו והזמנות בדיקה אינן נכללות.

גישה: מטרה ← איכות השירות ← יעילות ← תוצאה ללקוח ← מדדי הגנה

קודם כול אבהיר את מטרת צוות התמיכה: קיצור זמן הפתרון, שיפור שביעות רצון הלקוחות, שליטה בעלויות, צמצום הסלמות או תמיכה בצמיחה. מדדי KPI צריכים לאזן בין חוויית הלקוח ליעילות התפעולית. מדדי ליבה יכולים לכלול זמן תגובה ראשונה, זמן פתרון ממוצע, עמידה ב-SLA, צבר קריאות, שיעור פתיחה מחדש, שיעור הסלמה, פתרון בפנייה ראשונה, CSAT, שיעור פניות ללקוח, עלות לקריאה ונפח קריאות לפי קטגוריה. אפלח לפי סוג בעיה, עדיפות, ערוץ, דרג לקוח, מוצר, אזור ונציג או צוות. ממוצעים עלולים להסתיר בעיות חמורות בקריאות בעדיפות גבוהה או אצל לקוחות אנטרפרייז. מדדי הגנה (guardrails) חשובים. אם לוחצים על הנציגים רק לקצר את זמן הטיפול, האיכות עלולה לרדת. אם מבצעים אופטימיזציה ל-CSAT בלבד, העלות עלולה לעלות. דשבורד מאוזן צריך להציג מהירות, איכות, עומס עבודה וגורמי שורש, כדי שהצוות יוכל לשפר תהליכים, מוצר ואיוש.

גישה: אימות ← פירוק ← פילוח ← אבחון ← המלצה

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

גישה: משתמש ← מטרה ← ערך ← תנאים שניתנים לבדיקה

סיפור משתמש שימושי מתאר מי צריך משהו, מה נדרש ולמה זה חשוב. הפורמט המקובל: בתור [משתמש], ברצוני [יכולת], כדי ש[תועלת]. משפט הערך חשוב, כי הוא עוזר לצוות להכריע בפשרות. קריטריוני קבלה צריכים להיות ספציפיים וניתנים לבדיקה. הם מגדירים מה חייב להתקיים כדי שהסיפור ייחשב גמור. קריטריונים טובים מכסים את התרחיש התקין (happy path), ולידציה, הרשאות, מצבי שגיאה, מקרי קצה, כללי נתונים, וצרכים לא פונקציונליים כשהם רלוונטיים. דוגמה: בתפקיד ניהול תמיכה, ברצוני לסנן קריאות לפי עדיפות ולפי סטטוס SLA, כדי שאוכל לזהות עבודה דחופה. קריטריוני הקבלה יכולים לכלול את המסננים הזמינים, מצב ברירת המחדל, שילובי מסננים, התנהגות במצב ריק, כללי הרשאות, התנהגות הייצוא וציפיות ביצועים. BA חזק גם מתקף את סיפורי המשתמש מול בעלי העניין, הפיתוח, ה-QA והעיצוב לפני תחילת הפיתוח.

גישה: הצורך העסקי, מה המערכת עושה, יחידת מסירה

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

גישה: היקף ← משתמשים ← תרחישים ← נתונים ← באגים ← אישור סופי

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

גישה: הבנה משותפת ← אילוצים ← חלופות ← תיעוד

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

גישה: מדידה ← פילוח ← אבחון ← שיפור

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

גישה: ערך עסקי ← דחיפות ← סיכון ← מאמץ ← תלויות

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

גישה: עלות נוכחית ← סיכון לשגיאות ← עלות האוטומציה ← תועלות ← המלצה

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

גישה: הגדרת פריון ← נקודת בסיס ← אימוץ ← תוצאה ← מדדי הגנה

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

גישה: הבהרת מטרות ← חשיפת הפשרות ← שימוש בראיות ← החלטה

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

גישה: השפעה עסקית, חלופות, פשרות

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

גישה: בעיה ← ניתוח ← פתרון ← יישום ← השפעה

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

גישה: עמימות ← הנחות ← אימות ← החלטה

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

גישה: הקשר ← פרט ← סיכון ← פעולה ← תוצאה

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