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

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

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

1. כניסה לתהליך שינוי בלי לאבחן בתחילת הדרך את גודל הפער בין המצב המצוי למצב הרצוי ואת המשאבים הנדרשים כדי לסגור את הפער. כתוצאה מראייה שונה של גודל הפער נוצרת ציפייה שונה אצל בעלי עניין שונים לגבי מהות תהליך השינוי והמאמץ הנדרש כדי לשנות אותו. לפעמים טעות זו נובעת ממוביל השינוי שמגדיר את הפער לפי מה שהוא יודע/יכול לעשות ולא לפי "התמונה הגדולה" הכוללת ראיה רחבה של צורך הארגון.
2. הטלת הובלת השינוי על מנהל שיחסית פנוי כרגע, במקום על מנהל בכיר, אפילו חבר הנהלה, שמסוגל להנהיג את השינוי.  הציפייה היא שפרויקט שינוי יתנהל כמו כל פרויקט רגיל. ציפייה בהחלט מובנת, אולם פרויקט שינוי מתמודד עם אתגרים נוספים, כגון: התנגדות לשינוי, קונפליקט בין אחריות וסמכות, גיוס משאבים וכדומה.
3. אי תיאום ציפיות עם בעלי העניין השונים שמושפעים ו/או משפיעים על הצלחת הפרויקט. מה ייחשב מבחינתם להצלחה? כיצד מודדים את אותה ההצלחה?
4. הספונסר מאמין שמדובר בתהליך חד פעמי ולא בתהליך שיפור מתמשך.
5. הספונסר חושב שמדובר בהוצאה ולא בהשקעה כיוון שההחזר על ההשקעה לאחר תקופת זמן, לא מוצג בבהירות. כתוצאה מכך, נוצר קושי לקבל תמיכה לאורך זמן, כיוון שלא ברור מתי אפשר יהיה ליהנות מפירות המאמץ.
6. הציפייה של מנהלי היחידות העסקיות מעובדיהם היא לתרום להצלחת הפעילות שבאחריותם (אופטימום לוקאלי) לעומת הציפייה של מוביל השינוי ו/או המנכ"ל למיקוד בהצלחה העסקית הכוללת של כל הארגון (אופטימום גלובלי).
7. יציאה לדרך בלי לסנכרן ציפיות בין מנהלי הפרויקטים/תוכניות/פורטפוליו לאסטרטגיה הארגונית הכוללת – למה בכלל צריך את הפרויקט שלי? מה הקשר בין ההצלחה של הפרויקט שלי להצלחה הכוללת של החברה?
8. לא ברור למנהלי פרויקט/תוכנית/פורטפוליו מה נדרש מהם לעשות כדי להטמיע את השינוי בשגרת חייהם החדשה.
9. ציפייה לאחידות בהטמעת השינוי ביחידות העסקיות השונות בלי תפירה והתאמה ליכולת, לסביבה, ולבעלי העניין המעורבים.
10. חוסר ציפייה ממנהל פרויקט השינוי לנהל את פרויקט השינוי כמו כל אחד מהפרויקטים האחרים (לצאת לדרך עם תוכנית, לבקר ולנטר את ההתקדמות למול התכנון ולמסד מנגנוני תקשורת לפרויקט השינוי).

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

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

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

המאמר פורסם בגיליון אפריל 2014 של עיתון Information World

כנגד ארבעה בנים דברה תורת הניהול, אחד חכם, ואחד רשע, ואחד תם, ואחד שאינו יודע לשאול.

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

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

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

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

ואיזה מנהל/ת את/ה ??

אשמח לשיתוף באחת הרשתות החברתיות שקישורן להלן.

 וחוץ מזה  ……

האם אתם מכירים עוד אי הבנות? אשמח לשמוע ולהוסיף לרשימה

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

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

אי עמידה בהתחייבויות

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

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

שביעות רצון נמוכה של הלקוחות

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

• תלונות
• נטישה
• נתק

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

ניהול לא אופטימאלי

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

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

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

תהליכים לא מיטביים

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

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

בעיות איכות

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

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

מצב רוח ירוד של העובדים

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

• תסכול, שחיקה,
• עבודה מסביב לשעון
• אין תחושה שיש יד מכוונת/מנהלת

ספקים לא מרוצים

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

• יחסים לא הוגנים בין הארגון לספקיו
• חוסר שקיפות לגבי עמידתם בהתחייבות

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

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

• אחראי – Responsible – בעלי עניין שאחריותם לבצע את המטלה, לייצר את התפוקה, ולדאוג לקבלת משוב על איכות עבודתם משאר בעלי העניין הרלוונטיים;
• נושא באחריות – Accountable – בעל עניין שהוא מקבל את ההחלטות, ובין היתר, אחראי לכך שהתפוקה תהיה איכותית; האדם שנמצא בחזית ואליו פונים בשאלות או אפילו תלונות לגבי איכות התפוקה וזמני האספקה שלה. אותו מנהל דואג למשאבים הנדרשים לביצוע המטלה, ובסמכותו להאציל את ביצועה לאנשים אחרים, אחראי-ביצוע. בסיום המשימה, המנהל הנושא באחריות מאשר (בחתימה או בדרך אחרת) שאכן המשימה בוצעה לשביעות רצונו. לכל משימה חייב להיות אדם אחד שהוא נושא באחריות.
• יועץ – Consulted – אדם מומחה בתחום המשימה עימו מתייעצים לגבי ביצועה ו/או מזמינים אותו לסקירה של התוצר
• דורש דיווח – Informed – בעל עניין שמודיעים לו על מצב המשימה. בדרך כלל, בסיומה.

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

מודל R.A.C.I נבנה כדי להתמודד עם אתגר זה.

להלן דוגמה:

איך בונים את טבלת ה- R.A.C.I?

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

לסיכום, מה היה לנו עד כה ?

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

בקשה להצעת מחיר בנושאים הקשורים להסמכה לתקני AS9100, IATF-16949
בקשה להצעת מחיר בנושאים הקשורים להסמכה לתקני AS9100, IATF-16949
בבקשה לשלוח למייל של שלומית סעד-נוי – Shlomit_sn@sii.org.il
טלפון: 036467871

2) IQC

http://www.iqc.co.il/?categoryId=87406

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

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

ציור 1 – מחזור חיי פיתוח מוצר

נראה פשוט? לא ממש

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

כיצד בכל זאת, נטמיע תהליך שיטתי ?

אחד האמצעים לתאר תהליך פיתוח מוצר מקצה לקצה הוא תהליך כולל הנקרא "ניהול מחזור חיי פיתוח מוצר" – Product Life Cycle Management (PLCM), הכולל את הרכיבים הבאים:

1. שלבי הפיתוח – "הקוביות"
2. תוצרים – תפוקות ו/או תשומות של שלבי הפיתוח – "החיצים"
3. בעלי עניין – זיהוי בעלי העניין בכל תהליך בפרויקט – מי אחראי ליצירת התוצרים, מי מאשר, מי אמור להיות מושפע ומי אמור להיות מיודע.

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

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

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

​      לכל שלב, מתוארים הפרטים הבאים:

• שם ותיאור התהליך;
• הפונקציה האחראית לפתח את התוצר;
• תוצר התהליך;
• פונקציה האחראית לאשר את התוצר. בדרך כלל תהיה זו הפונקציה שתשתמש בתוצר.

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

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

למי התהליך מתאים ?

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

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

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

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

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

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

מדוע חשוב להגדיר הצלחה של פרויקטים?

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

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

מה זה בעצם פרויקט מוצלח?

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

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

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

OK, מה למדוד?

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

מדידת לו"ז, תכולה ותקציב

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

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

תכנון הלו"ז –מושפע מצורכי הלקוחות, או הארגון מבחינת Time-to-Market; קשה יותר להצליח בפרויקט עם לו"ז צפוף.

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

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

מדידת שביעות רצון הלקוחות

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

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

מדידה נוספת עקיפה של שביעות רצון הלקוח, היא מדידת הנכונות להמלצה. שואלים את הלקוח עד כמה יהיה מוכן להמליץ על הארגון ללקוחות נוספים בסקלה שבין 0 ל-10. ציון 9-10 נחשב ללקוח מרוצה, 7-8 נחשב ללקוח פסיבי, אדיש; כל ציון אחר נחשב כלקוח לא מרוצה.

מדידת ביצועי תוצר הפרויקט

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

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

מדידת החזר על השקעה – Return On Investment – ROI

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

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

בקרה רציפה, ולא רק בסוף הפרויקט

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

תאום ציפיות

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

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

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

כמובן, שמשך הזמן בפועל תלוי בגורמים רבים: גודל הארגון, מורכבות הארגון, רמת בשלות התהליכים בארגון, מידת שיתוף הפעולה של אנשי הארגון עם יועץ האיכות ועוד.

בתיאור שלהלן – יועץ האיכות יכול להיות מומחה בארגון או יועץ חיצוני.

שלבי תהליך ההתעדה, לקבלת תו התקן:

שלב א – הכנת ספר הנהלים של החברה

למה?	הקמת מערכת איכות מתועדת ויעילה לצורך השגת שביעות רצון לקוח ושיפור מתמיד
מי?	יועץ איכות
כמה זמן?	כשבועיים עד חודש
מה?	1) נהלים: שדרוג תהליכי העבודה הקיימים בחברה, בהתאמה לאופייה ופעילותיה: מדיניות איכות מדריך האיכות הכולל תיאור תמיכת כל תהליכי הארגון בדרישות התקן 2) קביעת מדדי איכות 3) כתיבת תוכנית איכות  4) הוראות עבודה, תבניות, רשימות תיוג וטפסים, לפי הצורך, למשל: טופס ריכוז אי התאמות / פעילות מתקנת טופס ריכוז תלונות לקוח טופס ריכוז אי התאמות ספקים טבלת מעקב הדרכות ריכוז תוצאות לגבי שביעות רצון לקוחות טבלת ניהול סיכונים
הערות	עבור מבדק ההסמכה הראשון נדרש לשדרג את תהליכי העבודה על פי התקן עבור מבדק מעקב נדרש לסקור ולהתאים את מערכת האיכות

שלב ב – הטמעת התהליכים בשטח לפי ספר הנהלים

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

 שלב ג – בדיקת הטמעה ודיווח להנהלה

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

שלב ד – מבדק חיצוני

מה?	קבלת אישור מגורם מוסמך שאכן מערכת האיכות מתפקדת על פי התקן
מי?	נציג הארגון
כמה זמן?	גמיש
מה?	1) הגשת הצעות למכוני הסמכה 2) בחירת הארגון המסמיך 3) מסירה של ספר הנהלים לארגון המסמיך לבדיקה מקדימה ואישור 4) מבדק  של הארגון המסמיך מבדק ראשוני שמטרתו הסמכת הארגון לפי התקן מבדק מעקב שמטרתו בדיקת תחזוקת מערכת האיכות ושיפורה המתמיד ​5) קבלת התעודה מהארגון המסמיך

עושים זאת בשבילכם

אנחנו נשדרג עבורכם את מערכת ניהול האיכות שלכם,

נבצע עבורכם את המבדקים הפנימיים,

נלווה אתכם במבדק החיצוני עד לקבלת ההסמכה,

ונשאיר לכם תשתית של מערכת ניהול איכות שתוכלו לתחזק בעצמכם.

פנו אלינו

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

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

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

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

תהליך מניעת תקלות על רגל אחת:

1.  זיהוי וניתוח סיבות לתקלות.
2. לאחר שזוהה המקור לתקלה – טיפול בתקלה ובגורם לה כדי למנוע הופעה מחודשת;
3. בנוסף –

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

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

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

גגג

גג

גג

גגגגג

גגגג

גגג

גגג

גגגג

גגג

פירוט תהליך ניתוח סיבות שורש ופתירתן:

1)    זיהוי סיבות השורש לתופעות שנבחרו

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

1.1  בחר תופעות לניתוח

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

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

דוגמה לפעולה סדרתית: התחלת שלב בפרויקט;

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

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

1.2   נתח סיבות שורש לתופעות והצע פעולות לטפל באותן סיבות שורש

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

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

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

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

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

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

2)    טיפול בסיבות השורש של אותן תופעות שנבחרו

בשלב זה, סיבות השורש של אותן תקלות שנותחו מטופלות באופן שיטתי.

2.1 ממש את הפעולות שמוצעות

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

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

פעולות שיגרמו לתוצאות חיוביות ממשיות, יוטמעו רוחבית בארגון.

2.2 נתח את השפעת הפעולות

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

2.3 תעד את ניתוח סיבה-תוצאה

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

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

ליישם, ליישם, ליישם

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

ומה עם חקר סיבות השורש להצלחה?

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

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

מקור:

CMMI For Development, Guidelines for Process Integration and Product Improvement, third edition, Mary-Beth Chrissis, Mike Korad, Sandy Shrum