גוף הידע בניהול פרויקטים (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 הוא ניהול זמן. ניהול זמן בפרויקט כולל את התהליכים שבאמצעותם מבטיחים שהפרויקט כולל את כל העבודה הנדרשת ורק אותה כדי שייסתים בצורה מוצלחת.

כדי להיות ארגון שהוא 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 – מסדו תהליך ניהול סיכונים שיטתי. אל תסתפקו בדרישה המנינמלית. שהרי – לא מספיק למסד חשיבה על… מיסוד תהליך שיטתי מביא תועלת רבה.

מי צריך להגדיר דרישות?

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

איך מגדירים דרישות?

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

    x