ניתוח מערכות הוא הדרך המהירה ביותר להפוך את השאלה "באיזה כלי כדאי לנו לבחור?" להשוואה מבוקרת, זה לצד זה, שניתן להציג בפני מחלקת הכספים, אבטחת המידע והצוות שיצטרך לעבוד עם הכלי. להלן דוגמה מעשית למטריצת קבלת החלטות לבחירת כלים, הכוללת קריטריונים, משקלים, ציונים משוקללים, עלות כוללת, סיכוני הטמעה וכיצד לתעד הנחות כדי לשמור על אמינות המטריצה.
מדוע ניתוח מערכות עדיף על בחירת כלים מבוססת תחושת בטן
ניתוח מערכות, בהקשר של בחירת כלים, אומר שאתם מעריכים אפשרויות כמערכת של אילוצים ופשרות: דרישות, עלויות, סיכונים והשלכות עתידיות. זה לא "איזה דמו הרגיש הכי טוב", אלא "איזו אפשרות מנצחת בהתחשב בסדרי העדיפויות ובמציאות שלנו".
ראיתי צוותים מבטלים החלטה על ספק לאחר פיילוט, כי ההשוואה המקורית התעלמה משני גורמי כישלון צפויים: עיכוב בהטמעה ועלויות נסתרות. מטריצת קבלת החלטות ברורה חושפת את אלו מוקדם, לפני שמשקיעים שבועות ברכש ואינטגרציה.
הערה מעשית: המטריצה שלכם טובה רק כפי שהגדרות הקריטריונים שלכם טובות. אם "קלות שימוש" אומרת דבר אחד ל-IT ודבר אחר למשתמשי הקצה, הציונים שלכם יהיו חסרי משמעות. כאן עוזרת מסגרת החלטות מובנית; אם אתם רוצים מדריך רחב יותר לבחירת המודל הנכון לארגון שלכם, התחילו ב-.
קריטריונים למטריצת קבלת החלטות עבור תוכנה וספקים (מה לכלול)
מטריצת קבלת החלטות היא טבלה שבה אפשרויות מקבלות ניקוד מול קריטריונים, לרוב תוך שימוש במשקלים המשקפים סדרי עדיפויות. עבור בחירת תוכנה וספקים, הקריטריונים שמפרידים בעקביות בין "טוב על הנייר" לבין "עובד בייצור" הם אלו הקשורים לאימוץ, סיכון ועלות כוללת.
הנה הרשימה הקצרה שאני משתמש בה הכי הרבה, מנוסחת כך שניתן לנקד אותה:
התאמה פונקציונלית: אחוז מקרי השימוש ההכרחיים הנתמכים ללא עבודה מותאמת אישית.
אינטגרציה ונתונים: זהות (Identity), ממשקי API, ייצוא נתונים, ועד כמה נתיב האינטגרציה שביר.
אבטחה ותאימות: SSO, יומני ביקורת, מיקום נתונים, הסמכות, ועמידות הספק.
מאמץ הטמעה: זמן להשגת ערך, שעות עבודה פנימיות, תלות ביועצים חיצוניים.
עלות כוללת (TCO): רישוי פלוס עלויות הטמעה, זמן ניהול, תוספים ועלויות צמיחה.
סיכון ספק: יציבות מפת הדרכים, איכות התמיכה, תנאי חוזה, עלויות יציאה.
שילוב זה הוא צורה של ניתוח החלטות מרובה קריטריונים בשפה פשוטה. אם אתם מתפתים להוסיף 20 קריטריונים, אל תעשו זאת. אתם תיצרו תחושת דיוק כוזבת. היצמדו למה שבאמת ישנה את ההחלטה.
דוגמה למטריצת החלטות: בחירת פלטפורמת תמיכה (מספרים מחושבים)
דוגמה זו למטריצת החלטות משווה שלושה ספקים פיקטיביים עבור פלטפורמת תמיכה ב-SaaS לשוק הביניים: AtlasDesk, BeaconSupport, ו-CitrineCX. לחברה יש כיום 25 נציגי תמיכה, היא מצפה ל-40 בשנה הבאה, וזקוקה לאינטגרציה עם Salesforce ו-SSO.
סולם ניקוד: 1 (גרוע) עד 5 (מצוין). סך המשקלים הוא 100.
קריטריון
משקל
ציון AtlasDesk
ציון BeaconSupport
ציון CitrineCX
התאמה פונקציונלית
25
4
5
3
אינטגרציה ונתונים
20
3
4
5
אבטחה ותאימות
15
4
3
5
מאמץ הטמעה
15
3
4
2
עלות כוללת (TCO)
15
5
3
2
סיכון ספק
10
3
4
3
כעת חשבו נקודות משוקללות:
משקל * ציון
וסכמו אותן. (אם אתם מעדיפים סולם של 0-100, הכפילו משקלים בציונים ואז חלקו ב-5 בסוף. הדירוג נשאר זהה.)
אפשרות
סך משוקלל (מתוך 500)
מנורמל (מתוך 100)
AtlasDesk
365
73
BeaconSupport
410
82
CitrineCX
380
76
BeaconSupport מנצחת בהשוואת המטריצה. אבל אתם עדיין לא סיימו. טבלת סיכום המטריצה היא כלי עזר להחלטה, לא תחליף לשיקול דעת. שני הסעיפים הבאים הם המקום שבו רוב הצוותים מאמתים את המנצח או מגלים גורם פוסל.
אם אתם רוצים דרך מובנית ליצור ולשמור על עקביות באפשרויות אלו ככל שמידע חדש מגיע, זה בדיוק מה שלוח ההחלטות של Lucid נועד עבורו: אתם קולטים את הקלט המבולגן פעם אחת, ומפת האפשרויות מתעדכנת ככל שאתם מעדנים את האילוצים. (עוד על זרימת עבודה זו בהמשך.)
כיצד לחשב ציונים משוקללים (ולהימנע ממלכודות מתמטיות נפוצות)
ניקוד משוקלל הוא פשוט, אך צוותים עדיין טועים בו בדרכים שיוצרות הטיה בתוצאה.
שיטה נקייה:
הגדירו קריטריונים עם מחוון ניקוד בשורה אחת (מה אומר 1 לעומת 5).
הקצו משקלים על בסיס סדרי עדיפויות, כאשר המשקלים מסתכמים ל-100.
נקדו כל אפשרות באופן עצמאי, רצוי על ידי 2-3 סוקרים, ואז בצעו התאמה.
הכפילו משקל בציון וסכמו.
שתי מלכודות שאני רואה שוב ושוב:
ראשית, צוותים "סופרים פעמיים" את אותו רעיון. דוגמה: אתם מנקדים "אבטחה" וגם מנקדים "תאימות" ו"מיקום נתונים" בנפרד, ואז עדיין מתייחסים ל"אבטחה" כאל קטגוריה כוללת. אם אתם צריכים תתי-קריטריונים, פצלו את הקריטריון במפורש או אחדו אותם.
שנית, צוותים נותנים למשקלים להפוך לפשרה פוליטית במקום לשקף אילוצים אמיתיים. אם הצוות המשפטי שלכם אומר שהחוזה חייב לכלול סעיף DPA ספציפי, זה לא "משקל נמוך". זהו שער (Gate).
כלל טוב: התייחסו לדרישות קשיחות כשערי מעבר/כישלון, ונקדו רק את מה שבאמת מהווה פשרה. זו לוגיקת החלטות בסיסית, אך היא מונעת מכם "לממוצע החוצה" דרישה שאינה ניתנת למשא ומתן.
עלות בעלות כוללת (TCO) היא המקום שבו בחירות כלים נכשלות בשקט. עלות הרישיון היא רק שורה אחת. השאר מסתתר בהטמעה, תקורה ניהולית ומחירי צמיחה.
עבור דוגמה זו, אנו מוסיפים הערכת TCO פשוטה ל-12 חודשים ותמונת מצב של סיכונים. זה לא נועד להיות חשבונאות מושלמת. זה נועד למנוע מכם לבחור ספק ש"זול" רק בחשבונית הראשונה.
גורם עלות וסיכון (12 חודשים)
AtlasDesk
BeaconSupport
CitrineCX
רישיונות
$48,000
$72,000
$90,000
שירותי הטמעה
$8,000
$12,000
$25,000
שעות הטמעה פנימיות (משוקללות)
$18,000
$12,000
$30,000
תקורה ניהולית (משוקללת)
$10,000
$8,000
$12,000
TCO מוערך ל-12 חודשים
$84,000
$104,000
$157,000
סיכון הטמעה (נמוך/בינוני/גבוה)
בינוני
נמוך
גבוה
סיכון יציאה (ייצוא נתונים, נעילה)
בינוני
בינוני
גבוה
שימו לב מה קורה: BeaconSupport אינה הזולה ביותר, אך היא בעלת סיכון ההטמעה הנמוך ביותר. ברכש אמיתי, זה לרוב חשוב יותר מהפרש של 20 אלף דולר, כי עיכובים יוצרים עלות הזדמנות ותחלופת צוות.
אם אתם רוצים למסד זאת, השאילו מושג מצוותי בטיחות ותאימות: מטריצת בקרת סיכונים. עבור כל סיכון מרכזי (עיכובי SSO, שגיאות בהעברת נתונים, אימוץ על ידי נציגים, שבריריות אינטגרציה), רשמו את הבקרה (תוכנית פיילוט, נתיב חזרה, SLA של ספק, בעלים פנימי) וסמנו האם זה ישים. אם אינכם יכולים לציין את הבקרה, אינכם מבינים את הסיכון עדיין.
עבור שפת סיכונים וחשיבה הסתברותית, אני לרוב מתייחס למסגרת של NIST סביב מושגי ניהול סיכונים, החל מ-סקירת מסגרת ניהול הסיכונים של NIST כדי לשמור על צוותים מקורקעים בבקרות מעשיות, לא בתחושות.
תעדו הנחות כדי שהמטריצה שלכם תישאר ניתנת להגנה
מטריצת החלטות נכשלת כשהיא הופכת לגיליון אלקטרוני שאף אחד לא סומך עליו. הפתרון פשוט: רשמו את ההנחות לצד המספרים.
עבור דוגמה זו, יומן ההנחות עשוי לכלול:
"ציון התאמה פונקציונלית מניח שלא נתמוך בתיבת דואר מרובת מותגים בשנה הראשונה."
"ציון אינטגרציה מניח מגבלות API של Salesforce ברמה הנוכחית."
"סיכון הטמעה מניח שנוכל להקצות מנהל אחד ל-20% משרה למשך 8 שבועות."
זה ההבדל בין מטריצה ששורדת בדיקה לבין כזו שקורסת ברגע שמחלקת הכספים שואלת "מאיפה זה הגיע?".
כשאתם עושים זאת בלוח החלטות חי במקום בגיליון אלקטרוני סטטי, אתם יכולים לשמור על הנחות צמודות לכל אפשרות ולעדכן השלכות כשההקשר משתנה. זו ההבטחה המרכזית של Lucid: קלט מבולגן נכנס, אפשרויות מובנות יוצאות, ניתנות לשינוי מיידי כשהמציאות משתנה.
אם אתם רוצים ספריית עזר רחבה יותר של מודלים (מתי להשתמש במטריצה לעומת DACI לעומת גישת דלת חד-כיוונית), שמרו את מסגרות החלטות: המדריך המלא בסימניות.
מתי להשתמש בתרשים זרימה להחלטות לעומת מטריצת החלטות (ואיך צוותים מגיעים לקונצנזוס)
תרשים זרימה להחלטות הוא הטוב ביותר כשהבחירה מבוססת בעיקרה על כללים: "אם אנחנו מאחסנים PII, אז אנחנו צריכים הסמכת X". מטריצת קבלת החלטות היא הטובה ביותר כשאתם מאזנים פשרות על פני ממדים מרובים.
אם אתם תקועים, שאלו: האם אנחנו מתווכחים על עובדות, או על סדרי עדיפויות? עובדות דורשות תרשים זרימה ודרישות סף. סדרי עדיפויות דורשים מטריצה.
קבלת החלטות בקונצנזוס הופכת לקלה יותר כשמפרידים ניקוד ממשקל. אני אוהב את הדפוס הזה:
בעלי עניין מסכימים על הגדרות קריטריונים תחילה.
יחידים מנקדים אפשרויות באופן עצמאי.
הקבוצה מתווכחת רק על הפערים הגדולים ביותר (היכן שהציונים נבדלים ב-2 ומעלה).
ההנהלה קובעת משקלים על בסיס אסטרטגיה, ואז לוקחת אחריות על ההחלטה הסופית.
אמת אחת ששווה לחזור עליה: אתם לא צריכים שכולם יסכימו על המנצח, אבל אתם כן צריכים שכולם יסכימו שהתהליך היה הוגן.
עבור ביסוס חיצוני מדוע קריטריונים מובנים מפחיתים הטיות, נקודת ההתחלה הקלאסית היא עבודתו של כהנמן על הטיות בשיקול דעת וקבלת החלטות. אתם לא מנסים להסיר שיקול דעת. אתם מנסים למנוע מהדעה הרועשת ביותר להתחזות לאמת.
השתמשו ב-Lucid כדי להפוך את המטריצה שלכם ללוח אפשרויות חי (ניתוח מערכות בפועל)
גיליונות אלקטרוניים הם בסדר עד לרגע שבו ההקשר משתנה: תמחור זז, אבטחת מידע מוצאת דרישה חדשה, או ציר הזמן של ההטמעה שלכם זז. אז אתם מסיימים עם כאוס גרסאות ומטריצה שאף אחד לא מעדכן.
Lucid בנויה לניתוח מערכות שנשאר עדכני. אתם יכולים לכתוב או להקליט את הדילמה, ו-Lucid מייצרת מפת אפשרויות עם יתרונות, חסרונות והשלכות עתידיות. לאחר מכן אתם משווים אפשרויות בתצוגות רשת/טבלה/מיקוד, והלוח מתעדכן ככל שאתם מעדנים הנחות.
אם אתם רוצים לנסות זאת על בחירת כלי אמיתית השבוע, התחילו עם החלטה אחת ושמרו עליה ממוקדת: שלוש אפשרויות, שישה קריטריונים, יומן הנחות אחד. קבעו סשן עבודה של 45 דקות, לא פרויקט מחקר של שבועיים. כשאתם מוכנים, צרו חשבון Lucid ובנו את לוח ההחלטות הראשון שלכם מההערות שכבר יש לכם.
