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

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

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

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

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

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

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

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

1)      תחילה עלינו למסד תהליכי מדידה וניתוח שיטתיים.
2)      תמיכת הנהלה הכרחית, כיוון שהתהליך לא קורה מעצמו; נדרשת נכונות להשקעה ומוכנות ליישום המסקנות של התהליך.

ניתוח סיבות שורש ופתירתן

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

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

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

"המקור היחיד לידע הוא הניסיון." – אלברט איינשטיין

 איך אנו מממשים מטרות בארגון (ולפעמים גם בחיים האישיים)? – באמצעות פרויקטים!

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

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

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

האם עלינו לחכות שמנהלי הפרויקטים יחכימו דרך הרגליים? האם יש דרך ללמוד מניסיון של אחרים? אחרים במשמעות הכי רחבה, גם מחוץ לארגון שלנו? מחוץ למדינה שלנו? ….. הבשורה המשמחת היא שיש דרך ללמוד מניסיון של אחרים, והיא להשתמש במודלים הידועים כ-Best Practicesבעולם. לנושא ניהול פרויקטים ישנם מספר מודלים: למשל  PMBOK1, CMMI2 ואחרים. יתרון השימוש במודלים הוא בכך שהמודל מדריך מה צריך לעשות במובן של פרקטיקות מעשיות. פרקטיקות אלה הן תוצאה של אלפי שנות ניסיון מצטבר בארגונים ברחבי העולם, במהלך 20-30 השנים האחרונות. מודלים אלה אף מתעדכנים לעיתים קרובות כדי להתאים את הפרקטיקות למציאות המשתנה.

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

תחומי התהליך המרכזיים בתחום ניהול הפרויקטים, בהם מתמקד מודל ה-CMMI:

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

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

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

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

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

הטיפול בדרישות, על פי מודל ה-CMMI מכוסה על ידי שני תחומי תהליך:

1) ניהול דרישות

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

2) פיתוח דרישות

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

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

ניהול דרישות שיטתי על פי מודל ה-CMMI:

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

חמש הפרקטיקות החיוניות לניהול דרישות שיטתי

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

עשה

ואם לא תעשה…

הבנת הדרישות

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

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

השגת מחויבות לדרישות

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

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

ניהול שינויים לדרישות

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

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

ניהול עקיבות דו-כיוונית

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

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

הלימה בין הדרישות לתוכנית העבודה

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

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

נושא מאתגר אבל….

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

==

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

 

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

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

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

מודל ה-CMMI מחלק את תהליך ניהול המדידות לשני תהליכי משנה:
1)      בחירת המדידות כך שיתמכו בחזון, באסטרטגיה ובתוכניות הארגון
2)      ביצוע תהליך המדידות, ניתוחן והצגת התוצאות בצורה שתתמוך בתהליך קבלת ההחלטות.

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

בחירת המדידות כך שיתמכו בחזון, באסטרטגיה ובתוכניות הארגון

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

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

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

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

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

דוגמה לסיכום

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

יעד עסקי:

  • קיצור לו"ז
  • להיות הראשון בשוק עם המוצר

מידע נדרש:

הערכה (estimation) של זמן ההשקה

מטרת המדידה:

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

סוגי מדידות:

זמן התחלה וסיום מוערך וזמן בפועל של התחלה וסיום של משימות

מדידות:

  • ביצועי עמידה באבני דרך
  • % הפרויקטים שעומדים בלו"ז
  • דיוק בהערכת לו"ז

קבלת החלטות

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

==

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

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

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

מודל ה-CMMI נתן את הדעת לסוגיה זו בתחום התהליך Decision Analysis and Resolution (DAR). בתחילה, נועד התהליך כדי לבחור בין מספר פתרונות טכניים לפיתוח מוצרים, למשל: בחירת ארכיטקטורה אופטימאלית מתוך מספר אפשרויות,  או בחירת כלים. אולם, התהליך כוחו יפה גם לבעיות שאינן טכניות כלל, למשל: בחירת ספק או יועץ, בחירת המוצרים שייכללו בפורטפוליו ועוד כהנה וכהנה דוגמאות.

תהליך קבלת החלטות

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

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

בארגון בו קיים תהליך קבלת החלטות שיטתי, קיימת תשתית הכוללת את הפרקטיקות הבאות:
1.      הנחיות לגבי הדרישה מתי להפעיל את תהליך קבלת ההחלטות השיטתי
2.      מיסוד מנגנון הערכה
3.      זיהוי מספר פתרונות אלטרנטיביים
4.      בחירת  השיטות להערכת הפתרונות השונים
5.      בחינת הפתרונות האלטרנטיביים תוך שימוש בשיטות שמוסדו להערכתם
6.      בחירת הפתרונות הטובים ביותר מתוך סך הפתרונות האפשריים בהתבסס על קריטריוני ההערכה

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

הנחיות לגבי הדרישה מתי להפעיל את תהליך קבלת ההחלטות השיטתי

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

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

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

מיסוד קריטריוני הערכה

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

נושא 1 4 7 10 ציון
מידת התאמת הפרויקט לאסטרטגיית הארגון  התאמה מינורית  התאמה קטנה. לא פרויקט מפתח  התאמה טובה; מתאים במספר נושאים התאמה חזקה לאסטרטגיית הארגון  6
 מידת התאמת הפרויקט לאסטרטגיה של קו המוצרים אליו מיועד  התאמה מינורית  התאמה קטנה. לא פרויקט מפתח  התאמה טובה; מתאים במספר נושאים התאמה חזקה לאסטרטגית הארגון  7
 חשיבות אסטרטגית  מינורית; לא ייגרם כל נזק מהשמטת הפרויקט  בינוני; בעל השפעה פיננסית מורגשת  חשוב; יהיה קשה להצליח אם הפרויקט לא ייכנס לפורטפוליו או ייכשל גבוה מאד; עתיד הארגון תלוי בפרויקט זה  8
 ציון משוקלל      70

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

קריטריון משקל ציון
התאמה אסטרטגית 15% 70
יתרונות תחרותיים 15% 70
סינרגיה עם היכולות הנוכחיות 15% 59
הזדמנויות/ סיכונים טכניים 15% 37
התאמה לשוק 20% 45
הזדמנויות/סיכונים פיננסים 20% 43
 ציון משוקלל 50

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

זיהוי מספר פתרונות אלטרנטיביים

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

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

בחירת  השיטות להערכת הפתרונות השונים

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

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

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

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

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

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

סיכום – החלטות טובות נובעות מניסיון, וניסיון נובע מהחלטות גרועות

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

 

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

אחד מתחומי התהליך של מודל CMMI הוא ניהול נכסי התהליך הארגוני –Organizational Process Definition, השם דגש על תשתית ארגונית טובה כדי לאפשר עקביות בניהול ותפעול. תשתית כזו מאפשרת לצבור את הידע הארגוני ב"מגירות" ובכך לשתף ידע ושיעורים הנלמדים משימוש בתהליכים מיטביים (best practices) או תהליכים שאינם מתאימים.

מפת הדרכים לבניית תשתית תהליכית לארגון

האיור שלעיל מתאר את שבעת המרכיבים של תשתית תהליכית, ואילו הן:

1

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

2

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

3

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

4

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

5

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

6

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

7

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

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

להלן תיאור התוצאות של אי-יישום של הפרקטיקות:

1

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

2

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

3

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

4

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

5

היעדר ספרייה עבור הנכסים הארגוניים
בלגן!

6

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

7

היעדר חוקים והנחיות לצוותים
בלגן!

הבסיס לניהול ידע

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

רוצים לעבוד ביעילות?…..רוצים!
רוצים לשפר ביצועים עסקיים?….רוצים!
רוצים להפחית סיכונים?…..רוצים!

מתי מתחילים? ….לא עכשיו. עכשיו סוף שנה/תחילת שנה/לפני החג/ אחרי החג.. בדיוק היה שינוי ארגוני/עוד מעט יהיה שינוי ארגוני…. (מחקו את המיותר או החליפו תירוץ סיבה).

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

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

מהו מודל (Capability Maturity Model Integration (CMMI ומה עושים כדי שיהיה מועיל?

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

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

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

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

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

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

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

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

סיפור מקרה

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

סיכום

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

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

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

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

==

מאמר זה נכתב בהשראת פוסט בבלוג של הלל גלזר:
CMMI on one leg, Agile CMMI Blog by Hillel Glazer

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

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

מהו מודל CMMI –  Capability Maturity Model Integration לשירות?

מודל שיטתי ל שיפור תהליכי השירות!

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

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

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


ההתייחסות לתחום השירות היא במסגרת אסטרטגיה כוללת.

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

….. ולפרטים בהרחבה

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

מסגרת ה- CMMI כוללת שיטת מבדק לקביעת רמת התהליכים (קיימות 5 רמות), וכן הדרכות. כיוון שהמודל והמבדקים מתבצעים באותה צורה קפדנית בכל העולם, משמשים הציונים המתקבלים במבדק להשוואת (Benchmarking) איכות התהליכים בין הארגונים. כמו כן, מכיל המודל תהליכים מיטביים (Best Practices) מהניסיון שהצטבר בשימוש בו.

למודל ה- CMMI שלושה מופעים ליישומים שונים: 1) פיתוח מוצרים ומערכות; 2) רכש; 3) שירות. מודל  CMMI לשירות נולד בתחילת 2009. הוא מדריך את הגופים בתוך הארגונים הנותנים שירות ללקוחות פנימיים או חיצוניים.

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

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

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

מדוע נדרש מודל CMMI לשירות?

המודל נדרש כיוון שהצורך בשיפור תהליכי שירות הולך וגדל. ארגונים נותני שירות מהווים כ- 80% מהכלכלה הגלובלית העולמית. מודל CMMI לשירות עונה לצרכים ומאפיינים משותפים של ארגונים נותני שירות מתחומים מגוונים:

  1. שירות הוא מוצר לא מוחשי, שאי אפשר לאגור אותו כמלאי; שירות ניתן ונצרך בו זמנית.
  2. קיימים יחסים מתמשכים בין נותני השירות ומקבליו, המגובים לעיתים בהסכמי שירות
  3. שירות מועבר על ידי מערכת התומכת במתן שירות
  4. לשירות מחזור חיים וקצב ייחודיים: בעוד שעיקר  מחזור החיים של מוצר הינו בפיתוח ומיעוטו במתן שירות, בשירות רוב מחזור החיים הינו במתן שירות
 כיום, קיימים מודלים שונים אחרים לשירות, אך הם מתמקדים בתחומים ספציפיים. למשל: מודל ITIL הדן בתהליכי שירות בסביבת טכנולוגיות המידע.
מודל CMMI לשירות מספק מסלול התפתחות ברור, לפי הצרכים העסקיים של הארגון באשר הוא: ארגון פיננסי, ארגון העוסק בחינוך, בריאות, אבטחה, בנייה, תפעול וכדומה.

יישום מודל CMMI  לשירות

קיימות שתי אפשריות ליישום מודל CMMI: מדורג ורציף.

המודל המדורג (Staged)

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

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

 

רמת יכולת תחומי תהליך
1 מבוצע
2 מנוהל ניהול דרישות
תכנון פרויקטים
בקרת פרויקטים
ניהול הסכמי ספקים
מדידות וניתוחן
הבטחת איכות תהליכים ומוצרים
בקרת תצורה
ביצוע השירות
3 מוגדר מיקוד הארגון בתהליך
ניהול נכסי התהליך הארגוני
הדרכות והכשרות בארגוןניהול סיכונים
ניהול משולב (של פרויקט)
תהליכי קבלת החלטות
ניהול קיבולת וזמינות              
טיפול בתקלות ומניעתן
רציפות השירות
פיתוח מערכת שירות
הטמעת מערכת השירות
ניהול אסטרטגית שירות
4 תהליך מדיד ניהול כמותי של פרויקטים
ניהול מדיד של ביצועי הארגון
5 שיפור מתמיד ניתוח סיבות שורש (לתקלות) ופתרונן
פיתוח ומימוש חדשנות בארגון
תרשים 1: רמות תחומי תהליך במודל המדורג של CMMI לשירות
משמעות תוצאות המבדק לפי רמות:
רמה 1 : מבוצע – התהליך לא צפוי, לא מבוקר בצורה מספקת. הפעילויות הן מגיבות
רמה 2: מנוהל – התהליך מבוצע ברמת פרויקט או יחידה  ובדרך כלל מגיב לאירועים
רמה 3: מוגדר – התהליך מבוצע ברמת ארגון ובדרך כלל יוזם אירועים (pro-active)
רמה 4: מדיד – התהליך מדיד ומבוקר
רמה 3: מוגדר –  המיקוד הוא על שיפור מתמיד

המודל הרציף (Continuous)

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

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

תרשים 2: תחומי תהליך במודל CMMI לשירות רציף

תקציר תחומי התהליך ייחודיים לשירות 

8 מתוך 24 תחומי התהליך של המודל מתמקדים בשירות, והם:

1. ניהול אסטרטגית שירות – Strategic Service Management 

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

תהליכים מרכזיים:

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

2. פיתוח מערכת השירות –  Service System Development

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

תהליכים מרכזיים:

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

3. הטמעה או שדרוג מערכת השירות Service System Transition

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

תהליכים מרכזיים:

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

4. אספקת שירות

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

תהליכים מרכזיים:

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

5. ניהול קיבולת וזמינות –    Capacity and Availability Management

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

תהליכים מרכזיים:

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

6. רציפות השירות –  Service Continuity

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

תהליכים מרכזיים:

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

7.  טיפול בתקלות ומניעתן –  Incident Resolution and Prevention

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

תהליכים מרכזיים:

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

 8. ניהול הסכמי ספקים –  Supplier Agreement Management

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

תהליכים מרכזיים:

  • מיסוד תהליכי רכש – סוגי רכש, תהליך בחירת ספקים, הסכמים
  • ניהול רכש

 סוף דבר

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

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

מאמר זה פורסם בגיליון יולי 2010 של האיגוד הישראלי לאיכות.

 

מודל (Capability Maturity Model Integration (CMMI הוא תקן בינלאומי למדידה של רמת היכולות הארגוניות בפיתוח ו/או במתן שירות בהשוואה לארגונים המובילים בעולם. המודל מדריך ארגונים כיצד לשדרג את תהליכיו ובעל הצלחות מתועדות.

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

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

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

הנושאים איתם מתמודד מודל ה-CMMI:

ניהול פרויקטים

 

רמה נושא
2 ניהול דרישות                                           Requirements Management
2 תכנון פרויקטים                                                           Project Planning
2 בקרת פרויקטים                                   Project Monitoring and Control
2 ניהול הסכמי ספקים                          Supplier Agreement Management
3 ניהול משולב (של פרויקט)                    Integrated Project Management
3 ניהול סיכונים                                                          Risk Management 
4 ניהול פרויקטים כמותי                        Quantitative Project Management

 

פיתוח/הנדסה (R&D)

רמה נושא
3
פיתוח דרישות                                               Requirements Development
3
מתן פיתרונות טכניים                                                      Technical Solution
3
אינטגרציה                                                                  Product Integration
3
אימות                                                                                      Validation
3
תיקוף                                                                                    Verification

תמיכה

ניהול תהליכים

רמה נושא
3 מיקוד הארגון בתהליך                                  Organizational Process Focus
3 הגדרה וניהול התהליך הארגוני                    Organization Process Definition
3 הדרכות והכשרות בארגון                                        Organizational Training
4 ניהול מדיד של ביצועי הארגון              Organizational Process Performance
5 ניהול ביצועי הארגון                    Organizational Performace Management

שירות

  • ניהול אסטרטגית שירות – Strategic Service Management
  • פיתוח מערכת השירות –  Service System Development
  • הטמעה או שדרוג מערכת השירות – Service System Transition
  • אספקת שירות –  Service Delivery
  • ניהול קיבולת וזמינות –    Capacity and Availability Management
  • רציפות השירות –  Service Continuity
  • טיפול בתקלות ומניעתן –  Incident Resolution and Prevention
להרשמה השאירו פרטים

    x