מטריצת סמכות ואחריות (הידועה גם בשם מטריצת RACI) מגדירה את אופן המעורבות ואת האחריות של שחקנים בפרויקט – בביצוע פעילויות בפרויקט, לפי ארבעה קודים:

  1. R – Responsible (אחראי)
  2. A – Accountable (נותן דין וחשבון)
  3. C – Consulted – (יועץ)
  4. I – Informed – (מיודע)

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

גם הוואריאציה המעודכנת יותר של המטריצה הנקראת מטריצת RASCI שהוסיפה את הקוד 'S' עבור תפקיד התומך (Support), לא מסייעת לבלבול לטעמנו. אחריות התומך היא אחריות מופשטת וככזו היא רק מגדילה את חוסר הבהירות של המטריצה במקום לשפר אותו.

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

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

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

  1. אחריות לביצוע – זהו הגורם שאחראי שדברים יקרו בין אם הוא מבצע אותם בפועל או מפעיל גורמים אחרים. הוא הגורם שייתן דין וחשבון לגבי הביצוע והוא יכול להיות אחראי בשני המובנים (Accountable + Responsible). גם במטריצה שלנו יהיה רק גורם אחד כזה. המטריצה – לטעמנו, לא צריכה לשקף את כל המבצעים (המשאבים) בפועל – אלה יכולים להיות רבים ומגוונים ויופיעו בתוכנית העבודה של הפרויקט.
  2. אחריות לבקרה – זהו הגורם שאחראי לבקר את הביצוע, צריך להיות לפחות אחד כזה ומוטב שהוא יהיה שונה מזה שאחראי לבצע (עקרון הפרדת הרשויות). לא יעלה על הדעת שתוצר מרכזי בפרויקט אינו מבוקר או שהגורם שאחראי על פיתוח התוצר מבקר את עצמו, טופח לעצמו על השכם וממשיך הלאה.
  3. חובת היוועצות – זהו הגורם שהאחראי לביצוע חייב להיוועץ בו. מובן שההחלטה בסופו של דבר כיצד להתייחס לעצה שקיבל היא של הגורם האחראי לביצוע, אבל חובה עליו לממש את חובת ההיוועצות בצורה מקצועית ועניינית. חובת היוועצות עלולה ליצור צוואר בקבוק בפרויקט ולכן, אם אין הדבר הכרחי, מוטב להשתמש בקוד הבא ולהשאיר לגורם האחראי את המקום לשיקול דעת באשר להיוועצות עצמה.
  4. רצוי להיוועץ – אלה הם גורמים שכדאי להיוועץ בהם אבל אין הכרח. מוטב לשמור את רשימת היועצים ממוקדת בעניין ומצומצמת, ולהימנע מריבוי דעות מוגזם.
  5. חובת יידוע – אלה הם גורמים שחובה ליידע אותם. מובן שחובת היידוע אינה נגמרת בשליחת מייל או בפעילות חד-כיוונית אחרת, אלא בהעברת המסר בצורה ברורה ווידוא קליטה והבנה שלו.
  6. אישור סופי – זהו הגורם שנותן אישור סופי לביצוע – במידה ונדרש כזה. תוצרים רבים דורשים אישור פורמלי אליהם יש להתייחס באופן ענייני ומקצועי ולא כעונש בירוקרטי שיש לחמוק ממנו. אישורים פורמליים עלולים ליצור עיכובים בפרויקט לפיכך, חשוב לזהות אותם ולקדם את השגתם בצורה פרואקטיבית עוד במהלך פיתוח התוצרים הנדונים (אם ניתן).

כיצד תיראה מטריצת סמכות ואחריות "ישראלית"?

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

לדוגמה, בפרויקט פיתוח מערכת מידע חדשה ללקוח כלשהו, אלה כמה מהתוצרים והשחקנים שעשויים להופיע במטריצה:

תוצר/אבן-דרךלקוחמנהל הפרויקטמנתח מע' מידער"צ פיתוחתוכניתןמעצב DBמנהל אבטחת מידעמנהל QA
מסמך אפיון62,61234
מסמך עיצוב612345
תוכנית בדיקות2241

מקרא: 1) אחריות לביצוע 2) אחריות לבקרה 3) חובת היוועצות 4) רצוי להיוועץ 5) חובת יידוע 6) אישור סופי

חשוב לזכור!

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

במצב שבו מנהל הפרויקט נתפס כאחראי יחיד לפרויקט, סביר להניח שהפרויקט לא יעמוד ביעדיו. על מנהל הפרויקט להבהיר בצורה ברורה וחד משמעית את החובות ואת הסמכויות של הגורמים המעורבים בו, וכך לכוונם לנשיאה באחריות (Accountability).

נקודות לבקרה במטריצה

  • כל הגורמים המעורבים זוהו ומופיעים במטריצה
  • כל התוצרים המרכזיים ואבני הדרך הנחוצות מופיעים במטריצה
  • יש רק גורם אחד אחראי לביצוע בכל שורה
  • יש לפחות גורם אחד אחראי לבקרה – שאינו הגורם שאחראי לביצוע
  • ישנה חובת היוועצות רק כאשר נדרשת כזו
  • אין יותר מדי יועצים בכל שורה
  • מי שצריך להיות מיודע אכן זוהה ככזה
  • יש גורם מאשר סופי כאשר נדרש כזה
  • האחריות לביצוע מחולקת בצורה טובה בין הגורמים השונים בפרויקט ואינה מרוכזת אצל גורם אחד מרכזי (אין יותר מדי 'אחריות לביצוע' בעמודה אחת במטריצה)

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

דילוג לתוכן