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

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

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

מטרה: לנהל את משאבי האנוש בפרויקט כך שיובילו את הפרויקט לסיומו המוצלח.

להלן הפרקטיקות של ניהול משאבי אנוש אותן יש לבצע בשלבי מחזור חיי הפרויקט:

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

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

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

איך אתם מנהלים את משאבי האנוש של הפרויקט? מוזמנים להגיב באחת הרשתות החברתיות שקישורן להלן. תודה

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

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

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

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

להלן הפרקטיקות של ניהול איכות בפרויקט אותן יש לבצע בשלבי מחזור חיי הפרויקט:

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

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

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

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

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

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

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

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

להלן הפרקטיקות של ניהול עלות אותן יש לבצע בשלבי מחזור חיי הפרויקט:

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

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

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

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

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

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

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

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

להלן הפרקטיקות של ניהול זמן אותן יש לבצע בשלבי מחזור חיי הפרויקט:

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

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

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

איך אתם מנהלים זמן בפרויקט שלכם? אשמח לשיתוף באחת הרשתות החברתיות שקישורן להלן

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

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

ה-PMBOK מתייחס לתכולה בשני אופנים:
  1. תכולת מוצר – התכונות והפונקציות של המוצר או השירות
  2. תכולת פרויקט – העבודה שיש לנהל ולבצע כדי לספק מוצר או שירות עם תכולת המוצר המוסכמת.

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

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

להלן הפרקטיקות של ניהול תכולה אותן יש לבצע בשלבי מחזור חיי הפרויקט:

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

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

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

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

גוף הידע בניהול פרויקטים (PMBOK Guide), מכיל עשרה תחומי ידע.

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

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

אחד מעשרת תחומי הידע של ה- PMBOK הוא ניהול אינטגרציה.

מטרת התהליך: לשלב את הפעילויות הנובעות מיישום כל הפרקטיקות של שאר התחומים הקשורים לניהול הפרויקט.

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

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

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

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

גוף הידע בניהול פרויקטים (PMBOK Guide), מכיל עשרה תחומי ידע.

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

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

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

כדי להיות 10 בניהול פרויקטים, עלינו:

  1. להיות 10 בניהול אינטגרציה
  2. להיות 10 בניהול תכולה
  3. להיות 10 בניהול זמן
  4. להיות 10 בניהול עלויות
  5. להיות 10 בניהול איכות
  6. להיות 10 בניהול משאבי אנוש
  7. להיות 10 בניהול תקשורת
  8. להיות 10 בניהול סיכונים
  9. להיות 10 בניהול רכש
  10. להיות 10 בניהול בעלי עניין

בהצלחה לכולנו !

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

בגרסת התקן  9001:2015 ISO.הוחלפה הדרישה לפעולה מונעת לתהליך של ניהול סיכונים.

האם לדעתכם יש הבדל בין פעולה מונעת לניהול סיכונים? אם יש הבדל – מהו?

כדי ענות על השאלה, נשווה את שני התהליכים, לפי שלביהם:

זיהוי

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

הערכת נזק

פעולה מונעת: הערכת הצורך בפעולה למניעת הופעתן של אי-התאמות
ניהול סיכונים: הערכת הסיכון (אומדן הנזק)

החלטה על פעולה

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

מעקב ובקרה

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

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

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

סוף מעשה במחשבה תחילה

תהליך ניהול סיכונים מוסיף שתי פעולות חשובות מעבר לפעולה המונעת:

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

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

יש הבדל או אין הבדל?

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

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

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

האם השינוי חשוב?

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

ארגונים רבים בארץ ובעולם עוברים תהליך התעדה לפי תקן 9001 ISO. עד כה, ברוב הארגונים, תהליך ניהול סיכונים שיטתי אינו מוטמע בחלק גדול מהארגונים, במיוחד בארגונים קטנים. הכנסת התהליך לתקן הבסיסי והפופולארי גורמת להרבה מאד ארגונים למסד תהליך שכזה, לתועלתם. עד כה, תהליך ניהול סיכונים היה חובה רק בתקני ISO אחרים יותר כגון: ISO 27001 לבטיחות מידע, ISO 14001 לבטיחות הסביבה ועוד. המלצתי – גם אם הדרישה היא "רק" ל- Risk-Based-Thinking – מסדו תהליך ניהול סיכונים שיטתי. אל תסתפקו בדרישה המנינמלית. שהרי – לא מספיק למסד חשיבה על… מיסוד תהליך שיטתי מביא תועלת רבה.

   

לאחרונה היינו עדים לאירוע מפחיד בכל קנה מידה: שריפה פרצה במפעל פלסטיק בקיסריה. בכתבה של Ynet  מיום 22.6.14 נכתב שעל כיבוי השריפה עמלו 123 לוחמי אש, 69 כבאיות ו-6 מסוקי כיבוי שגויסו מכל הארץ. האש, שהגיעה לגובה 20-25 מטר, התפשטה למפעל שכן וכילתה גם אותו. היה חשש להתפשטות האש למפעלים סמוכים נוספים. עשרות עובדים שהו במפעל ולמרבית המזל רובם חולצו ללא פגע, למעט שני עובדים שנפגעו במצב קל ובינוני. תושבי הסביבה נאלצו להסתגר שעות רבות בבתיהם ללא מזגן ולסגור את כל הפתחים כדי שלא ישאפו עשן רעיל. בהתאם למסקנות ראשוניות מהאירוע, מדובר בהתלקחות באזור אחסון ששופץ לאחרונה וכנראה טרם התקבל אישור שירותי הכבאות להפעלת המקום. המפעל נשרף כליל ואיתו הכסף שהושקע בשיפוץ. מחדל בטיחותי זה הסב לבעלי המפעלים נזקים עסקיים כבדים בעקבות הרס המפעלים ואי יכולתם לעמוד בהתחייבויות לאספקת סחורה. עובדי המפעל נשארו ללא פרנסה לתקופה ממשוכת.

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

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

האם אפשר למנוע התרחשויות שכאלה?

בוודאי!

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

  • תקן 9001 ISO – תקן ניהול איכות – במסגרת המהדורה החדשה של התקן שצפויה להתפרסם בשנת 2015 צפוי להתווסף פרק שמחייב את הארגון העומד בתקן לבצע סקר סיכונים במקום ההנחיה הקודמת שדיברה על פעילות מונעת בצורה ערטילאית.
  • תקנות ארגון הפיקוח על העבודה (תכנית לניהול הבטיחות), התשע׳׳ג-2013 – במסגרת תכנית בטיחות שכל ארגון מחויב להכין עד אוגוסט 2014 נדרש לבצע הערכה מלאה של כלל סיכוני הבטיחות שיש לארגון.
  • תקן ת"י 18001  או בגרסתו החדש – תקן ISO 45001:2018– מערכת בטיחות וגהות – התקן מחייב ביצוע סקר סיכונים מלא לכל תהליכי עבודה שקשורים לבטיחות.
  • תקן 14001 ISO – מערכת סביבתית – התקן מחייב ביצוע סקר סיכונים מלא לכל ההשפעות הסביבתיות של הארגון.
  • תקן 27001 ISO – תקן אבטחת מידע – התקן מחייב התייחסות לכלל סיכונים שיכולים לפגוע במערכות מידע ומאגרי מידע של הארגון.

איך עושים את זה?

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

OK, מהו סיכון ולמה לנו להתעסק עם זה בכלל?

סיכון הינו הסתברות להפסד כתוצאה מ-:

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

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

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

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

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

מהו תהליך של ניהול סיכונים?

תהליך ניהול סיכונים הוא תהליך של מספר צעדים:

צעד ראשון – הערכת עוצמת הסיכונים

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

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

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

תהליך השלם לטיפול בסיכונים – ראו במאמר אחר – כאן.

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

רקע לניהול דרישות

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

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

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

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

המסתורין של שמות העצם

יידוע שמות עצם: השתמש אך ורק בשמות עצם מיוּדעים (מלווים בה"א הידיעה). שימוש במונחים ללא יידוע מוביל לריבוי משמעויות.

דוגמה:

המערכת תספק תצוגת זמן

מושא הדרישה (תצוגת זמן) צריך להיות מיודע כדי שיהיה חד-משמעי:

המערכת תציג את השעה-הנוכחית

חיים ומוות ביד הלשון

לשון פעיל: השתמש בלשון פעיל ובישות מבצעת מוגדרת לפעולה. שימוש בלשון סביל מקשה על אימות הדרישה.

דוגמה:

זהות הלקוח תיבדק

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

מערכת-ניהול-החשבונות תוודא את זהות-הלקוח

מי הנושא בעול?

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

כבודו במקומו מונח

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

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

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

כמה ? שבע ! מה שבע ? מה כמה !

כַּמָּתים: המנע מכַּמָּתים (Quantifiers) לא מדויקים. דרישה צריכה להיות מכומתת במדויק.
דוגמה:
המאזניים הביתיים יציגו את המשקל עד לדיוק של בערך 10 גרם.
דוגמאות לכַּמָּתים מעורפלים שמהם יש להימנע: הרבה, בערך, כמעט תמיד, גמיש, משמעותי, יעיל, הגיוני, טיפוסי, מתאים, קרוב ל, בקירוב.
לכן:
המאזניים הביתיים יציגו את המשקל ± 10 גרם.

גאוות יחידה

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

לכל מספר יש לציין במפורש את היחידות בהן הוא נמדד:

למעגל-המודפס תהיה טמפרטורת אחסנה של לא יותר מ-30 מעלות צלזיוס

פועלי כל העולם…

תואר הפועל: המנע משימוש בתארי פועל מעורפלים – תואר הפועל מתאר ומסייג את הפעולה שבה נקבנו.
דוגמה:
מערכת-נתוני-הטיסה תהיה בדרך כלל מקוונת

תארי פועל מעורפלים עלולים להוביל לדרישות רב משמעיות, שלא ניתן לאמת:

"בדרך כלל", "בערך", "מספיק", "באופן טיפוסי"

למערכת-נתוני-הטיסה תהיה זמינות של לפחות xx% במשך של לפחות yy שעות ברציפות

בעזרת השם

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

טעם לוואי

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

גילויי פתיחות

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

Sוגמה:

הכספומט יציג את מספר חשבון הלקוח, היתרה וכן הלאה
פסוקיות פתוחות עלולות להוביל לדרישות רב משמעיות, שאינן ברות-אימות ושאינן משקפות את צרכי בעלי העניין:
"כולל, אבל לא מוגבל ל…", "וכו'", "וכן הלאה", "וכדומה"
  1. הכספומט יציג את מספר החשבון של הלקוח
  2. הכספומט יציג את היתרה של הלקוח
  3. הכספומט יציג את סוג חשבון הלקוח
  4. הכספומט יציג את מסגרת משיכת היתר של הלקוח
  5. הכספומט יציג….

עשרת הכללים לכתיבת דרישה טובה בקטגוריית הדיוק

הכרנו מספר כללים לכתיבת דרישה "טובה" שהם בקטגורית "דיוק":
#
שם הכלל
הסבר
1
יידוע שמות עצם
השתמש בשמות עצם מיוּדעים (מלווים בה"א הידיעה)
2
לשון פעיל
השתמש בלשון פעיל ובישות מבצעת מוגדרת לפעולה
3
נושא הדרישה
הקפד שנושא הדרישה יהיה תואם לרמה המוצר או השירות אליה הדרישה מתייחסת
4
מונחים מוגדרים
השתמש אך ורק במונחים המוגדרים במילון (Glossary)
5
כַּמָּתים
המנע מכַּמָּתים (Quantifiers) לא מדויקים
6
יחידות
השתמש ביחידות מוגדרות ומפורשות לציון כמויות
7
תואר הפועל
המנע משימוש בתארי פועל מעורפלים
8
תואר השם
המנע משימוש בתארי שם
9
פסוקיות לוואי
המנע משימוש בפסוקיות לוואי מעורפלות
10
פסוקיות פתוחות
המנע משימוש בפסוקיות פתוחות

לסיום: נקודה למחשבה

אם כל דרישה באוסף הדרישות מקיימת את כל התכונות המאפיינות דרישה "טובה" – האם זה אומר שאוסף הדרישות כולו הוא "טוב" ? נשמח לתשובה בתיבה למטה

 

על המחבר, אלון מודעי

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

להרשמה השאירו פרטים

    x