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

 

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

 

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

 

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

 

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

ואו, עוד דיון מרתק ! גנאדי - הקמת הפורום הזה אכן היתה רעיון טוב. תודה.

 

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

או בניסוח אחר, לאיזה בעיה בדיוק ניהול סיכונים נותן פתרון ?

צטט: agileman 2008-10-07 17:44:24

ואו, עוד דיון מרתק ! גנאדי - הקמת הפורום הזה אכן היתה רעיון טוב. תודה.

 

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

או בניסוח אחר, לאיזה בעיה בדיוק ניהול סיכונים נותן פתרון ?

לאלעד שלום ותודה,

 

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

 

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

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

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

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

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

שלום דביר, אבקש להתייחס לדבריך,

 

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

 

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

 

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

 

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

שמעון שלום,

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

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

ביטול הסיכון (לדוגמא אם יש תכונה מסובכת מדי, פשוט מוותרים עליה ולא מכניסים אותה לגרסא)

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

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

הכנת תוכנית פעולה למקרה שהסיכון יתממש

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

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

 

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

דביר שלום,

תודה על הפירוט של 5 הפעולות שהבאת לדיון, באמת מדובר בפעולות פשוטות, מזכירות את 5 הפעולות המפורטות בספר ה PMBOK בגירסתו מ 2004 (פרק 11.5.2). אין ספק, נקיטת פעולות שכאלה תורמת להקטנת השפעת הסיכונים על תוצאות הפרויקט ולהצלחת פרויקטים. הדיון שפתחתי בו מנסה לבחון דרכים לשיפור של השיטות הנוכחיות. לא מכיון שהן לא עובדות אף פעם, אלא מכיון שלעיתים בכל זאת הן נכשלות, משמע יש מקום לשיפור. עד שיימצא השיפור, השיטה שאתה מציג הינה בהחלט בעלת פוטנציאל הצלחה, גם אם לא ב 100%.

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

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

צטט: גנאדי 2008-10-10 00:00:59

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

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

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

 

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

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

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

 

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

 

רק דעתי כמובן.

אלעד.

אלעד שלום ותודה על הצטרפותך לדיון.

 

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

 

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

 

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

 

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

 

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

 

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

 

הטיפול באי הוודאויות, כדאי שיהיה פרואקטיבי. כך אני סבור.

צטט: שמעון זיירמן 2008-10-10 09:52:26

צטט: גנאדי 2008-10-10 00:00:59

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

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

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

 

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

היי גנאדי,

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

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