ניתוח מערכות הוא הדרך המהירה ביותר שאני מכיר כדי למנוע מממשל תאגידי להפוך לוויכוחים ב-Slack ולעיכובים בהשקות. אם אתם מתלבטים בין מטריצת אישורים (Approval Matrix) לבין טבלת RACI, הכלל פשוט: מטריצות אישורים מבהירות מי יכול לומר 'כן' בכל נקודת החלטה, בעוד ש-RACI מבהירה מי מבצע את העבודה ומי אחראי עליה. מדריך זה מספק לכם מפת דרכים מעשית לבחירת הכלי הנכון, עם דוגמאות שניתן לעשות בהן שימוש חוזר.
מטריצת אישורים מול RACI: ההבדל של ה-30 שניות שקובע
ההבדל בין מטריצת אישורים ל-RACI אינו עניין של העדפה עיצובית. זוהי בחירה ניהולית.
מטריצת אישורים (שלעיתים נקראת תבנית מטריצת אישורים בצוותים תפעוליים) היא רשת מובנית הממפה סוגי החלטות למי שחייב לאשר (ולעיתים מי שחייב להיוועץ בו או לקבל עדכון). היא בנויה עבור שליטה, ציות ומהירות ברגע ההתחייבות.
טבלת RACI היא מטריצת הקצאת אחריות הממפה משימות או תוצרים לתפקידים: אחראי לביצוע (Responsible), בעל אחריות כוללת (Accountable), מוועץ (Consulted), ומעודכן (Informed). היא בנויה עבור בהירות בביצוע ומניעת כשלים מסוג "חשבתי שאתה מטפל בזה".
אם הכאב שלכם הוא "אנחנו לא יודעים מי יכול לאשר את זה", אתם צריכים מטריצת אישורים. אם הכאב הוא "אנחנו לא יודעים למי זה שייך", אתם צריכים RACI.
מטריצת אישורים היא הכלי שאתם פונים אליו כאשר הארגון זקוק לתשובה עקבית וניתנת לשחזור לשאלה: "למי יש סמכות לאשר זאת?"
ניתן לראות זאת באישור הוצאות כספיות, קליטת ספקים, חריגות אבטחה, טווחי שכר, שינויי תמחור, סקירה משפטית ושערי מוכנות להשקה. היא גם עמוד השדרה של מערכות "אישורי זרימת עבודה" רבות מכיוון שהיא מתורגמת בצורה נקייה לכללים.
בפועל, מטריצת אישורים מנצחת כאשר:
ההחלטה הפיכה רק בעלות גבוהה (אירוע אבטחה, חשיפה משפטית, סיכון מותג).
אתם זקוקים ליכולת ביקורת ומעקב (מי אישר, מתי, תחת איזו מדיניות).
אישורים חייבים להתרחב מעבר למערכות יחסים אישיות (מנהלים חדשים, אזורים חדשים, מיזוגים ורכישות).
מודל מחשבתי שימושי הוא לוגיקת החלטות: מטריצות אישורים מקודדות לוגיקת החלטות באופן שניתן לאכיפה. RACI לא יכולה לעשות זאת בעצמה מכיוון שהיא לא בנויה סביב ספי החלטה.
אם אתם רוצים את ההגדרה הרשמית של "אחריות" ומבני ממשל, סקירת מטריצת RACI בוויקיפדיה היא בסיס הגון, אך רוב הצוותים נכשלים כי הם עוצרים בהגדרות במקום לתכנן עבור חיכוך אמיתי בזרימת העבודה.
מהי טבלת RACI (ומתי היא מנצחת)
RACI היא הטובה ביותר כאשר העבודה עצמה היא החלק המבולגן: פונקציות מרובות, זרמים מקבילים, בעלות מעורפלת ומסירות (handoffs) שנשברות תחת לחץ.
RACI מנצחת כאשר:
יש לכם ביצוע בין-תחומי (מוצר, עיצוב, הנדסה, שיווק, משפטים).
אתם רואים כפילות ("שני צוותים בנו את אותו הדבר") או פערים ("אף אחד לא הכין את מצגת ההטמעה").
צוואר הבקבוק שלכם הוא תיאום, לא סמכות.
דפוס הכשל הנפוץ ביותר ב-RACI שאני רואה הוא הקצאת יתר של "A" (אחראי). אם יותר מתפקיד אחד אחראי על תוצר, יצרתם ועדה. ועדות לא מוציאות לפועל.
RACI טובה היא קצרה, קשורה לתוצרים אמיתיים, ונבדקת בתחילת פרויקט ושוב בשינוי ההיקף המשמעותי הראשון. אם אתם זקוקים לתפריט רחב יותר של מסגרות מעבר ל-RACI, מסגרות קבלת החלטות: המדריך המלא הוא מקור עזר מועיל.
זכויות החלטה מול אחריות: מבחן ניתוח מערכות מעשי
ניתוח מערכות, המיושם על ממשל, הוא בעצם: זהו היכן המערכת נשברת, ואז בחרו את הכלי שמתקן את הכשל הזה.
הנה המבחן שאני משתמש בו עם צוותים. הסתכלו על 10 ההחלטות האחרונות שלכם שהתעכבו וסווגו את העיכוב:
תסמין עיכוב
סיבת שורש
השתמשו בכלי זה
"אנחנו לא יודעים מי יכול לאשר את זה."
חוסר בזכויות החלטה
מטריצת אישורים
"אנחנו יודעים מי מאשר, אבל אף אחד לא הכין את המידע."
חוסר בבעלות על קלטים
RACI (ואולי תרשים זרימת החלטות)
"המאשר ברור, אבל זה לוקח שבועות."
יותר מדי שערים או ספים לא ברורים
עיצוב מחדש של מטריצת אישורים + ספים הדוקים יותר
"העבודה מתבצעת, אבל אף אחד לא אחראי לתוצאה."
בלבול באחריות
RACI
"אנחנו ממשיכים להתווכח שוב ושוב על אותם פשרות."
אין השוואה מובנית
מטריצת קבלת החלטות + ניתוח תרחישים
השורה האחרונה היא המקום שבו כלים כמו Lucid עוזרים. כאשר צוותים תקועים בעמק ההחלטות (הרבה דעות, אין סגירה), לוח אפשרויות מובנה מאלץ את הפשרות להיחשף ושומר על עקביות התוצאות ככל שההקשר משתנה.
השוואה זה לצד זה: מטריצת אישורים מול טבלת RACI
זוהי השוואת המטריצות הפשוטה ביותר שמחזיקה מעמד בסקירות תפעוליות אמיתיות.
ממד
מטריצת אישורים
טבלת RACI
מטרה עיקרית
הבהרת מי חייב לאשר החלטות ספציפיות
הבהרת מי מחזיק במשימות ותוצרים
יחידת מיפוי
סוג החלטה (הוצאה, סיכון, מדיניות, שער השקה)
פריט עבודה (תוצר, משימה, אבן דרך)
פלט
נתיב אישור וחתימות נדרשות
תפקידי אחריות ותקשורת
הכי טוב עבור
ממשל, ציות, בקרת הוצאות, אישורי זרימת עבודה
ביצוע בין-תחומי, מסירות, בהירות בביצוע
דפוס כשל
יותר מדי מאשרים, זמן מחזור איטי
יותר מדי בעלי אחריות, "כולם מוועצים"
אם אתם בונים דוגמה למטריצת החלטות עבור ההנהלה, טבלה זו בדרך כלל מספיקה כדי ליישב את הוויכוח במהירות.
שתי דוגמאות עבודה (כדי שתוכלו להעתיק את התבנית)
דוגמה 1: קליטת ספק (מטריצת אישורים מנצחת)
כאשר צוות רוצה לקלוט ספק חדש, ההחלטה היא לא "לבצע את העבודה", אלא "האם אנחנו מוכנים לקבל את הסיכון והעלות". בדרך כלל צריך ספים: רמת הוצאה, רמת גישה לנתונים, תנאי חוזה.
מטריצת אישורים נקייה לקליטת ספק משתמשת בשורות כמו "SaaS עם גישה לנתוני לקוחות" ובעמודות כמו "אבטחה", "משפטים", "כספים", "בעל עסק". מערכת הכללים הופכת לאכיפה. זו הסיבה שמטריצות אישורים מיושמות לעיתים קרובות במערכות כרטיסים (ticketing).
כדי לשמור על מהירות, הגדירו מה אומר "אישור". לדוגמה: אבטחה מאשרת רק טיפול בנתונים והיקף גישה, לא תמחור. משפטים מאשרים תנאים, לא ארכיטקטורה. זה נשמע מובן מאליו, אבל זה המקום שבו אישורים מתפשטים ללא שליטה.
דוגמה 2: השקת מוצר (RACI מנצחת, מטריצת אישורים כשכבה דקה)
עבור השקה, העבודה מרובת זרמים: מסרים, תמחור, מסמכים, אנליטיקה, מוכנות תמיכה, תוכנית פריסה. RACI היא עמוד השדרה הנכון כי היא מונעת פערים בלתי נראים.
לאחר מכן הוסיפו מטריצת אישורים דקה רק עבור השערים בעלי הסיכון הגבוה: "השקה ל-100% תעבורה" עשויה לדרוש אישור ממוצר, הנדסה, תמיכה ואבטחה. "שינויי טקסט" כנראה שלא.
אם אתם רוצים דרך ניתנת לשחזור לבחירת השערים האלה, התייחסו לזה כאל ניתוח תרחישים: מה העלות של טעות, ועד כמה זה הפיך?
בעיות הממשל הגדולות ביותר אינן בעיות של כלים. הן בעיות של תכנון.
ראשית, יותר מדי מאשרים. כל מאשר נדרש נוסף מגדיל את זמן המחזור ויוצר מס תיאום. אם אתם צריכים הוכחה, הדינמיקה של תורת התורים היא אותה דינמיקה שהופכת תהליכים רב-שלביים לאיטיים. כאשר אישורים מתנפחים, צמצמו אותם על ידי הידוק ספים והפיכת ה"מוועץ" למפורש במקום משתמע.
שנית, RACI שהופכת לספר טלפונים. אם ב-RACI שלכם יש 40 שורות ו-18 תפקידים, אף אחד לא ישתמש בה. קשרו אותה ל-10 עד 15 התוצרים שבאמת מניעים את הפרויקט. כל השאר יכול לחיות במנהל משימות.
שלישית, אין נקודת החלטה מפורשת. צוותים נסחפים כי הם לעולם לא מגדירים מתי החלטה מתקבלת. תרשים זרימת החלטות קל יכול לעזור: טיוטה, סקירה, אישור, יישום, אימות. טוב מכך, הגדירו קריטריונים של "מוכנות להחלטה" (נתונים, אפשרויות, סיכונים) כדי שמאשרים יפסיקו להתבקש לאשר כוונה מעורפלת.
ההנחיות של גוגל עצמה לגבי הפחתת חיכוך בתהליכים מנוסחות בדרך כלל סביב בהירות ואחריות במערכות תפעוליות. כדאי לסרוק את תוכן ה-re:Work של גוגל בנושא קבלת החלטות עבור דפוסי ניהול מעשיים שמפחיתים את תקורה התיאום.
איך Lucid עוזרת כשצריך את שניהם: אישורים פלוס פשרות ברורות
מטריצות אישורים וטבלאות RACI אומרות לכם מי. הן לא כופות בהירות על מה שאתם בוחרים ביניהם.
כאשר החלטה שנויה במחלוקת, צוותים זקוקים למפת אפשרויות מובנית: חלופות אמיתיות, יתרונות וחסרונות, ותוצאות מסדר שני. זה המקום שבו Lucid משתלבת. אתם יכולים לכתוב או להקליט דילמה מבולגנת, ליצור לוח אפשרויות, ואז להשוות נתיבים בתצוגת רשת, טבלה או מיקוד. כאשר מגיע הקשר חדש, הלוח מתעדכן מבלי לשבור את הלוגיקה.
אם אתם מתקננים ממשל בצוות, התחילו עם המסגרות ואז תפעלו אותן. אנו מכסים את שכבת הבחירה ב-מסגרות קבלת החלטות: המדריך המלא, ואז משתמשים ב-Lucid כדי לשמור על תיעוד ההחלטות עקבי ככל שהמציאות משתנה.
שאלות נפוצות
מה התועלת בשימוש במטריצת אישורים?
מטריצת אישורים הופכת זכויות החלטה למפורשות, מה שמפחית הלוך-חזור ומונע אישורים בצללים. היא גם יוצרת נתיב הניתן לביקורת עבור החלטות הוצאה, סיכון ומדיניות.
האם ניתן להשתמש ב-RACI ובמטריצת אישורים יחד?
כן, וצוותים חזקים עושים זאת לעיתים קרובות. השתמשו ב-RACI עבור בעלות על ביצוע, ואז החילו מטריצת אישורים רק על קבוצה קטנה של שערים בסיכון גבוה שבהם סמכות וציות הם קריטיים.
מה ההבדל בין מטריצת קבלת החלטות למטריצת אישורים?
מטריצת קבלת החלטות משווה אפשרויות מול קריטריונים כדי לבחור את הנתיב הטוב ביותר. מטריצת אישורים מגדירה מי חייב לחתום ברגע שנבחר נתיב.
מדוע טבלאות RACI נכשלות בפועל?
הן נכשלות כאשר "אחראי" (Accountable) מוקצה למספר תפקידים, או כאשר הטבלה מפורטת מדי מכדי להיות שמישה. שמרו עליה קשורה לתוצרים אמיתיים ואכפו אחריות חד-ערוצית.
מוכנים לתקן אישורים תקועים השבוע? שלפו החלטה אחת אחרונה שלקחה יותר מדי זמן, רשמו את נקודת ההחלטה המדויקת, ואז בחרו את הכלי שתואם את הכשל: מטריצת אישורים עבור זכויות החלטה, RACI עבור בעלות. אם הפשרות עדיין מעורפלות, תפסו את הדילמה ב-Lucid והפכו אותה ללוח שניתן להשוות זה לצד זה, ואז שתפו אותו לאישור נקי. התחילו עם לוח חדש ב-יצירת חשבון Lucid.
מטריצת אישורים מול RACI: מתי להשתמש בכל כלי | Lucid
