מדריך זה דן בהיבט התיאורטי והמעשי של הגדרת וניהול מדדים בארגון/בפרויקט. בהיבט התיאורטי, מציג המדריך מודלים מקובלים להגדרת מדדים (כגוןGoals, Question, Metrics ו-Balanced Scorecard). בהיבט המעשי, מציג המדריך שיטה להקמת מערכת מדידה אפקטיבית בארגון או בפרויקט.
מדדים ומדידה הם נושאים תומכים מובהקים שכן הם חוצים את מחזור החיים ועץ המערכת לכל אורכם. הנושא מורכב הן בהגדרה והן בביצוע ועם זאת הוא חשוב וחיוני לקידום האיכות והניהול האפקטיבי של ארגון ושל פרויקט.
מה שלא מדיד קשה מאוד לניהול, וקשה אף יותר (עד בלתי אפשרי) לשפר, ושיפור מתמיד כידוע הוא אחת מאבני היסוד הבסיסיות של ניהול איכות בארגון ובפרויקט.
אחת הסיבות המרכזיות לכישלון (או אי-הצלחה) של ארגונים היא אי-יכולתם ליישם את האסטרטגיה בה הם בחרו. לרובם יש אסטרטגיה טובה, רק שיש קושי ביישומה. איך מתרגמים את ההצהרות הכוללניות של האסטרטגיה הארגונית לפעילויות היומיומיות שעושים כל העובדים? איך דואגים שכל הפעילויות תבוצענה באופן מתואם, אשר מצטרף לכלל כוח משותף חזק המיישם את האסטרטגיה שנבחרה? אחד הכלים אשר יכול לסייע רבות בכך הוא הקמת מערכת מדידה אפקטיבית. מערכת זו תיגזר מהאסטרטגיה הארגונית, ותקבל פירוט הולך וגדל ככל שיורדים מטה, כך שכל הפעילויות החשובות בארגון תקבלנה ביטוי במערכת המדידה, וכך יהיה ברור בדיוק עד כמה כל מחלקה בארגון תורמת ליישום האסטרטגיה הארגונית. אגב, רעיון זה נכון גם לאגף, חטיבה ומחלקה וניתן ליישום באותה המידה.
מערכת מדידה מאפשרת לארגון לגשר על הפער בין האסטרטגיה הארגונית/חטיבתית והפעילויות המבוצעות בפועל ברמת המחלקה והצוות
ארגונים משתמשים במדדים כדי להבין את המאפיינים של תהליכים ומוצרים על-מנת להשיג בצורה שיטתית מטרות שהוגדרו מראש (כגון: שיפור איכות המוצר, ייעול תהליך הפיתוח וכו'). ניתן גם להשתמש במדדים ברמת פרויקט בודד, אם כי מירב התועלת יופק מהטמעת מערך מדדים אחיד לרוחב כל הפרויקטים הגדולים בארגון.
פעילות המדידה היא פעילות אחת מתוך סדרה ארוכה של פעילויות ניהול שמטרתן לאפשר לדעת היכן הארגון או הפרויקט נמצא, כיצד הוא מתקדם לעבר המטרות שהוגדרו ועד כמה הוא השיג אותן, וכדי לאפשר לכוון את הארגון/הפרויקט לכיוון הרצוי ולהביאו אל היעד הרצוי.
ניתן לחלק באופן גס את המדדים לשני סוגים עיקריים:
· מדדים של תהליך. למשל: כמה זמן נמשך כל חלק בתהליך? כמה תקלות התגלו בכל שלב של התהליך? ועוד.
· מדדים של מוצר. למשל: סה"כ מספר התקלות שהתגלה במהלך בדיקות המוצר? מורכבות הקוד, מידת בשלות המוצר להתקנה בסביבת הייצור, ועוד.
אוסף הפעילויות ותוצרים הקשורים למדידה, משלב הגדרתם, דרך איסוף הנתונים ועד לניתוחם, מהווה מערכת בפני עצמה, הנקראת מערכת מדידה. למערכת זו יש (כמו לכל מערכת) יעדים, יישום, טכנולוגיה, מימוש ועלות.
המטרות העיקריות של מערכת מדידה הן:
· בקרה: להעריך את מצבו הנוכחי של הארגון/פרויקט מבחינת השגת מטרותיו ויעדיו, ולאפשר להנהלה לדעת בצורה מוחשית וברורה עד כמה הוא רחוק מהיעדים שהוצבו. באופן זה, ההנהלה יכולה לקבל החלטות המבוססות על עובדות, ולא על "תחושות בטן".
· הערכת המוצר: להעריך את איכות המוצר המפותח ולסייע בשיפורו.
· הערכת התהליכים: להעריך את איכות תהליך פיתוח המוצר ולסייע בשיפורו (מבחינת יעילותו, האפקטיביות שלו, רמת התפוקה שלו, זיהוי בעיות בשלביו השונים וכו').
· הערכת החזר על השקעה: להעריך את יחס העלות/תועלת של המערכת ולסייע בשיפורו.
· צפי/תחזיות: להעריך מהן המגמות בתחום איכות התהליך או איכות המוצר, ובכך לאפשר "לחזות" את המצב העתידי.
מטרות נוספות אפשריות של מערכת מדידה:
· להעריך פריון עבודה וביצועים (של ספק חיצוני או של חלק פנימי בארגון ואף של עובד מסוים) ובכך לאפשר לתגמל באופן אובייקטיבי, ולא על-סמך "תחושות בטן".
· לאמוד את היתרונות והתועלת (במונחי פריון ואיכות) המתקבלים משימוש בשיטות או בכלי עזר חדשים.
· לשמש בסיס לאמידת עלויות של פרויקטים חדשים.
· לאפשר הערכת טיב השירות המתקבל על-ידי קבלן משנה.
· לסייע בהשוואות בין פרויקטים ומערכות, מתוך מטרה לזהות חריגים בארגון ולשפרם.
· לקבוע את מידת הצלחת הפרויקט או היחידה הארגונית בהשגת מטרות שנקבעו.
· לאתר נקודות תורפה בהן כדאי לטפל על מנת לשפר תהליכים או מוצרים.
לפני שניגשים לבצע מדידה כלשהי, רצוי לוודא שיעדי הארגון וחזונו מוגדרים היטב, או כפי שניסח זאת היטב לואיס קרול בספרו "עליסה בארץ הפלאות":
"... התואיל להגיד לי, בבקשה, באיזו דרך עלי ללכת מכאן?"
"זה תלוי במידה רבה לאן את רוצה להגיע" אמר החתול.
"לא איכפת לי כל כך לאן" אמרה אליס.
"אם כך, לא משנה באיזו דרך תלכי" אמר החתול.
"-בתנאי שאגיע לאן שהוא" הוסיפה אליס.
"בטוח שתגיעי", אמר החתול, "אם רק תתמידי בהליכה".
כלומר, אפשר למדוד "סתם כך", ולראות מה יצא מזה. ייתכן שיצא מזה משהו טוב. אבל זאת לא הדרך הנכונה. מדידה היא פעילות הגוזלת משאבים. אם המדידה מבוצעת רק כדי לדעת "מה קורה", רוב הסיכויים שההחזר על ההשקעה לא יהיה טוב. יש לנצל את המדידה ככלי ניהולי אשר מאפשר לכוון את הארגון לכיוון המטרות והיעדים שהוצבו לו, או כלשון אמרה ישנה:
מדידה אינה מטרה. מדידה היא אמצעי להשגת מטרות
אמרה נוספת מפורסמת היא "לא ניתן לנהל מה שלא ניתן למדוד". אמרה זו אולי קשוחה מדי, כי הרי בבירור קיימים ארגונים שבהם לא מודדים כמעט דבר, ובכל זאת הם מתנהלים. אמנם הם מתנהלים, אך לא כל-כך טוב. העובדה המוכחת היא שקשה מאוד לנהל ארגון ללא מדדים. הוכח בעשרות מחקרים בעשרות השנים האחרונות שארגונים שמנוהלים על-בסיס מדדים שורדים יותר טוב ומצליחים יותר מארגונים אחרים. לא לחינם נכנס נושא המדידה כנושא מרכזי (אחד משמונת העקרונות של ניהול איכות) בתקן ISO 9001 החל ממהדורת 2000 (ראה קיט תקן ISO 9000 בכרך איכות), וזאת מתוך ראיה שלא ניתן להשיג שיפור מתמיד ללא מדידה, ויש לעבור מניהול לפי תחושות לניהול לפי עובדות. כמו-כן, לא לחינם נושא זה מקבל מקום מרכזי במודל ה- CMM (מודל בשלות היכולת, Capability Maturity Model, ראה קיט שיטת CMM בכרך איכות) וזאת מתוך ראיה שארגון בוגר בעל תהליכים אפקטיביים הוא ארגון המודד את עצמו ומשתמש במדדים אלה כדי לנהל באופן שוטף את הפעילויות.
ברור ומוכח מעל לכל ספק שארגון הרוצה להצליח, הרוצה להיות איכותי, והרוצה שלקוחותיו יהיו שבעי רצון ונאמנים לו, חייב להתנהל בצורה שיטתית, מדידה, עם חזון ומטרות ברורות ומדידות, עם מערכת מדידה מוגדרת ואפקטיבית, ועם תהליכים ומוצרים שנמדדים באופן שוטף ועומדים ביעדים מוגדרים ומדידים.
יש לשים לב שניתן ליישם קיט זה בשתי דרכים שונות ומשלימות:
· בתוך הארגון המפתח מוצר/מערכת או מספק שירות (הספק): מדידה של תהליכי הפיתוח ושל איכות המוצר עצמו, על-מנת להשיג את יעדי הארגון הספק, ועל-מנת למדוד את מידת ההצלחה של פרויקטים.
· בתוך הארגון הקולט את המוצר (הלקוח): מדידה של תהליכי העבודה של הארגון, ושל תועלות המערכת שפותחה, על-מנת למדוד את יחס העלות/תועלת של המערכת שפותחה.
קיט זה מדבר על יישום שתי הדרכים. הן לא סותרות אחת את השנייה. להיפך, הן משלימות אחת את השנייה.
העיסוק במדידה ושיפור מתמיד רלוונטי לפרויקט בודד (במהלך מחזור החיים שלו) וגם לארגון שלם או לחלק של ארגון:
· המסקנות שפרויקט בודד יוכל להפיק מהמדדים יאפשרו לנהל אותו יותר טוב (מדדי בקרה), יעזרו לפרויקט להשתפר תוך-כדי פיתוחו (שיפור מתמיד תוך כדי הפרויקט!) ויעזרו למדוד את מידת הצלחתו הסופית של אותו פרויקט.
· המסקנות שארגון שלם יוכל להפיק ממערכת מדידה אפקטיבית יעזרו לאותו ארגון להבין עד כמה הוא משיג את יעדיו העסקיים, להשוות בין פרויקטים, לאתר חריגים (באופן אובייקטיבי), ולשפר באופן מתמיד את יעילות ואפקטיביות הארגון כולו, ע"י הצבת יעדים קשים יותר מדי שנה, מדידת השגתם, ונקיטת פעולות בהתאם. באופן כזה ארגון יוכל להיעזר במערכת המדידה שלו על-מנת להגיע לשיפור מתמיד בכל ההיבטים: ביעילות, באפקטיביות ובאיכות.
דוגמא תבהיר את העניין ותחדד אותו.
ראשית תובא דוגמא פשוטה מתחום המכירות.
תחום המכירות מתנהל מאז ומתמיד בצורה מדידה, וזה ברור. מה יותר פשוט מזה? אם המכירות של ארגון מסוים בשנה הקודמת היו מליון דולר, ומנהלו הציג מטרה של התרחבות של 10% לשנה הקרובה, הרי שהיעד המדיד לשנה הקרובה הוא מכירות של 1,100,000$ (זאת רק דוגמא. ברור שישנם יעדים נוספים בתחום של רווחיות, נתח שוק וכו'). מכאן ברור לכולם כיצד מבצעים "הקצאה" של היעד הזה למחלקות השונות. אם אגף המכירות מחולק למחלקות לפי אזורים גיאוגרפיים, ניתן להקצות לכל מחלקה יעד מדיד משלה: מחלקת אסיה צריכה למכור בהיקף של 500,000$ בשנה הקרובה, מחלקת צפון אמריקה 450,000$ וכו'. מכאן אפשר לרדת הלאה, ולהקצות לכל איש מכירות "יעד אישי משלו": משה כהן צריך למכור השנה בהיקף של 60,000$ וכו'. ברור ופשוט.
אם כך, למה בתחום ניהול פרויקטים הדבר לא כל-כך ברור? למה זה לא מובן מאליו שצריך לפעול באותה השיטה גם בתחום זה? האמת היא, שאין שום סיבה, מלבד העובדה שזה דורש ידע וניסיון. הניסיון מלמד כי הקמת מערכת מדידה אפקטיבית, אשר תיתן מענה לשאלות הקריטיות לצורך תפקוד הארגון והשגת מטרותיו, הישרדותו והצלחתו על-פני שאר המתחרים אינה דבר פשוט כלל. מטרת קיט זה היא להקנות את הידע הדרוש לכך.
להלן דוגמא מקבילה, מתחום פיתוח התוכנה.
לפי הנתונים שנאספו בשנה האחרונה, על כל שנת אדם של השקעה בפיתוח תוכנה, התגלו בשלב בדיקות המערכת 20 תקלות (בפיתוח הכוונה היא לכל שלבי מחזור החיים: החל מאפיון, עיצוב ובניה, בדיקות, ועד להתקנה והרצה). מטרת הארגון לשנה הקרובה היא להגדיל את הרווחיות מ- 10% (מבחינת היחס בין הרווחים להכנסות) ל- 13%. לשם כך, יש צורך לבצע סדרת פעולות לשיפור וייעול תהליכי הפיתוח. אחת מהפעולות היא להקטין את כמות התקלות המיוצרות במהלך הפיתוח, כך שעל כל שנת אדם בפיתוח תתגלינה רק 15 תקלות בשלב בדיקות המערכת (כמובן ללא הפחתת ההשקעה בבדיקות, וללא הפחתת מידת האפקטיביות של הבדיקות). כלומר, הארגון כולו צריך להשתפר ב- 25% במדד הזה (ירידה של 5, מ- 20 ל- 15). מניתוח המדדים של השנה שעברה, מתברר שהמדד של תקלות לכל שנת אדם במחלקה א' עומד על 17, ובמחלקה ב' עומד על 24. לכן בהקשר של מדד זה, היעד המחלקתי לשנה הקרובה עבור מחלקה א' הוא 13, ועבור מחלקה ב' הוא 18 (ירידה של 25%).
לשם עמידה ביעד זה, המחלקות תצטרכנה לבצע סדרה של פעילויות שיפור שונות ומגוונות, אשר מטרתן תהיה לשפר את תהליך פיתוח התוכנה. דוגמאות לפעילויות אשר יכולות להקטין את המדד (ובכך לשפר את איכות התהליך ואת יעילותו):
· שיפור תהליך העיצוב (התגלה כי במחלקה א' 34% מהתקלות הן תקלות עיצוביות!) ע"י הפיכתו לפשוט יותר, העברת הדרכה לכל המעצבים, ליווי המעצבים הפחות מנוסים ע"י מעצבים מנוסים, ושיפור אפקטיביות סקרי העיצוב.
· שיפור תהליך בדיקות היחידה (התגלה כי במחלקה ב' 56% מהתקלות שהתגלו בשלב בדיקות המערכת היו יכולות להתגלות כבר בשלב בדיקות היחידה!) ע"י סקירת מפרטי בדיקות היחידה בסיום שלב העיצוב ע"י מעצבים מפתחים מנוסים (כתנאי לתחילת הפיתוח), הטמעת כלי ממוחשב לניהול בדיקות היחידה (כדי לאפשר לראשי הצוותים בקרה יותר טובה על סטאטוס הביצוע וסטאטוס תיקון התקלות שהתגלו בשלב זה).
· המשך ההשקעה בבדיקות המערכת, באותו היקף כמו שנה שעברה. לשם כך, לכל פרויקט יוקצו משאבי בדיקות באותו יחס כמו שנה שעברה (למרות שהפעילויות לעיל יגרמו להתייעלות מסוימת בפעילות הבדיקות).
בתחילת שנת העבודה כל מחלקה גיבשה תוכנית מחלקתית לעמידה ביעדי הארגון. כמו-כן, הוכנה תוכנית ברורה וישימה לנושא המדדים הארגוניים, כך שהיה ברור מהם המדדים הנמדדים, מה מטרת המדידה, ומי אחראי לאסוף את הנתונים ולנתחם. ראשי הצוותים וראשי הפרויקטים עקבו באופן שבועי אחר ביצוע הפעילויות ואחר סטאטוס המדדים. מדי שבועיים נותחו כל המדדים, היה ברור האם המחלקה אכן מתקדמת לעבר היעד המדיד שהוגדר, ובמידה ולא, האם נדרש לנקוט צעדים לתיקון המצב. מדי חודש ראשי המחלקות סקרו את סטאטוס עמידת המחלקות ביעדים המדידים שלהן והורו על פעילויות לביצוע כדי לעמוד בכך. עוזריהם של ראשי המחלקות וידאו כי ההחלטות מבוצעות באופן אפקטיבי (כלומר, באופן המתבטא במדדים!).
באופן דומה, מדי רבעון סקר המנכ"ל את סטאטוס עמידת הארגון ביעדים המדידים הארגוניים:
· בסוף רבעון 1 המדד של תקלות לכל שנת אדם עלה מ- 20 ל- 21.
· ברבעון 2 הוא ירד ל- 17.
· ברבעון 3 הוא ירד ל- 15,
· בסה"כ השנתי המדד ירד ל- 13 !
ירידה זו פינתה כ- 20% ממשאבי המחלקות לפיתוח של פרויקטים נוספים, והגדילה בצורה משמעותית את היחס "מכירות לעובד", דבר אשר הביא לגידול ברווחיות החברה מ- 10% ל- 15% !
אם נראה שהדוגמא קצת אופטימית, מוגזמת, וורודה מדי, זה נכון. הדוגמא מוקצנת בכוונה, כדי להעביר את המסר. המסר הוא (אם לא היה ברור עד עכשיו...):
מדדים הם כלי ניהולי ממדרגה ראשונה לשם השגת מטרות ולשם שיפור מתמיד
להלן דוגמאות שימושיות נוספות:
א. פרויקט א' הצליח לפתח ולבדוק רק 20% מהדרישות שהוגדרו באפיון תוך 60% ממשך הפרויקט. הדבר סוטה באופן מהותי מהיעד שהוצב. יש צורך לנתח לעומק את הסיבות לעיכובים ולהמליץ על פעולות מתקנות לשם התגברות על הפער שנוצר, מתוך מטרה לעמוד בלוח-הזמנים המקורי, ללא התפשרות על האיכות.
ב. בפרויקט ב' המערכת עומדת רק ב- 50% מדרישות הביצועים תחת עומס מלא. יש לנתח את צווארי הבקבוק ולהמליץ על פעולות מתקנות לשיפור ביצועי המערכת.
ג. בפרויקט ב' נכשלו 55% מצעדי הבדיקות בסבב הראשון של בדיקות המערכת. זה מעיד על בדיקות יחידה ובדיקות אינטגרציה לא אפקטיביות. יש לנתח לעומק את סיבות השורש הגורמות לכך, ולהמליץ על פעולות מתקנות לשיפור תהליכי בדיקות היחידה ובדיקות האינטגרציה.
ד. בפרויקט ג' התגלו רק 10% מהתקלות הצפויות (יחסית להיקף ההשקעה בפיתוח) לאחר שני סבבי בדיקות. יש לנתח לעומק את הסיבות לחוסר האפקטיביות של שלב בדיקות המערכת ולנקוט בפעולות מתקנות.
ה. פרויקט ד' התחיל עם 10 סיכונים פעילים מעל רמה 15, ולאחר שנה הגיע למצב שבו 8 סיכונים ירדו מתחת לרמה 12, בעוד ששניים אחרים עלו לרמה של 25. יש לבחון את הסיבות לכך ולהכין בדחיפות תוכניות להתמודדות עם התממשות הסיכונים.
ו. בפרויקט ה' 30% מהתקלות החמורות אשר התגלו בשטח (אצל הלקוח) פתוחות כבר שבועיים ומעלה ועדיין לא תוקנו. מתוכן, 54% נובעות מבעיות בהתקנת המוצר, ולא בעיות קוד. יש להכין רשימת פעילויות למניעת בעיות ההתקנה בפרויקט זה, ובפרויקטים דומים בעתיד.
רק ידיעה מוקדמת וברורה של יעדי הארגון ושל מטרות המדידה תגרום להתמקדות במדדים הרלוונטיים ולהפקת תועלת אמיתית מהם. חשוב לציין שכל מה שנאמר לעיל לגבי "ארגון", תקף גם במידה רבה מאוד לחלק של ארגון (מחלקה/חטיבה וכו') וגם לפרויקט אחד בודד בתוך המחלקה. גם לפרויקט יש מטרות, והמדידה בתוך פרויקט צריכה לאפשר לו להשיג את מטרותיו, ואף לאפשר לו להשתפר באופן מתמיד (מסבב לסבב, מגרסה לגרסה). בסופו של דבר, המטרה המרכזית של פרויקט היא עמידה ביעדי המערכת, או בלשון יותר מדויקת, עמידה במדדי התועלת ומדדי העלות/תועלת המפורטים ברכיב 1.6 בעץ המערכת. כל המדדים האחרים אשר יבוצע בהם שימוש בפרויקט אמורים לשרת את המטרה העליונה הזאת. ייתכן כמובן מצב מורכב, שבו בפרויקט מסוים יבוצע שימוש במספר מדדים, שחלקם אמורים לתרום להשגת מטרות הפרויקט, וחלקם אמורים לתרום להשגת מטרות המחלקה והארגון.
כדאי להדגיש את האבחנה בין מדידה ישירה למדידה עקיפה. בשל הקושי למדוד ישויות מסוימות (רכיבי עץ מערכת או תהליכי פיתוח) ובשל העובדה שיש השלכות וקשרים בין הישויות, נוח לעתים וכלכלי יותר למדוד ישות מסוימת באופן עקיף דרך ישויות הקשורות אליה (משליכות או מושלכות) ולא באופן ישיר. דוגמא קלאסית לכך היא מדידה של זמני ביצוע וזמני תגובה של המערכת כתחליף למדדי תפוקה של האדם העובד עם המחשב.
ניתן לעיתים להתחיל דווקא מהבעיות הניצבות בפני ארגון. במקרים כאלה, קיימת תחושה של בעיה במצב הקיים, ומוקמת מערכת מדידה לשם אישוש התחושה ומדידת הנזק הנגרם מהבעיות. לאחר תכנון פתרון לבעיות, יש כמובן למדוד את מידת הצלחת הפתרון ומידת הקטנת הבעיות.
בניגוד לאינטואיציה, במדדים לא מתקיים הכלל של "כל המרבה הרי זה משובח". יש לבחור מספר מדדים מצומצם, אשר נותנים את התועלת המרבית במינימום התקורה. אין לנסות "למדוד כל מה שזז". זהו מתכון לכישלון. ככל שהארגון יתבגר והתהליכים שלו יבשילו, ניתן יהיה להנהיג עוד ועוד מדדים, אך שוב, בתנאי שאיסופם יבוצע במינימום תקורה ועד כמה שיותר בצורה אוטומטית, שהם יהיו מבוססים על כמה שיותר נתונים אובייקטיביים ולא על תחושות בטן סובייקטיביות, וכמובן שהם יביאו תועלת מוחשית.
המלצת מפת"ח היא לא להיסחף, במיוחד אם נושא המדדים הוא ראשוני והתחלתי בארגון, ולהתמקד במספר מדדים אשר מייצגים את המאמצים העיקריים בארגון. מדדים אלה עשויים להתחלף או להתרחב מידי פעם, בהתאם למטרות הארגון.
יש לזכור: LESS IS MORE.
התהליך להקמת מערכת מדידה מורכב מהצעדים הבאים:
.jpg)
להלן הפירוט:
1. הגדרת המדדים לפי שיטת GQM (Goal, Question, Metric) בשלושה שלבים:
· הגדרת מטרות המדידה (Goals).
· חקירה של תכונות המוצר/תהליך לשם השגת המטרות. החקירה מתבצעת באמצעות שאלות (Questions).
· קביעת המדדים עצמם שאמורים לענות על השאלות (Metrics).
2. כתיבת תוכנית המדדים ואישורה. ראה גלופת תוכנית המדדים בלשונית "תוצרים" בקיט זה.
3. סימולציה (בדיקת ישימות) כדי לוודא שהמדדים שהוגדרו מתאימים ועונים על הצורך, וניתנים למדידה. במקרים רבים אפשר ורצוי לאסוף נתונים היסטוריים כדי "לחוש" את המדד ולוודא שהגדרתו היא נכונה.
4. מדידה בפועל (איסוף נתונים) עם נתונים אמיתיים.
5. ניתוח הנתונים ונקיטת פעולות בהתאם לתוצאות ולהחלטות. בלי שלב זה אין טעם בכל פעילות המדידה!
כאמור, רצוי מאוד לדעת מהם מטרות הארגון/הפרויקט, לפני שניגשים להגדיר את המדדים עצמם. במידה ומטרות הארגון/פרויקט ידועות ומוגדרות, הצעד הראשון בתהליך הקמת מערכת המדידה הוא הגדרת מטרות המדידה וגזירת המדדים הקונקרטיים (Metrics) ממטרות אלה. דרך פעולה מומלצת היא מודל ה- Goal/Question/Metric - GQM שלBasili . לפי מודל זה, תהליך הגדרת המדדים נחלק לשלושה שלבים עיקריים:
· Goal – הגדרת מטרות המדידה
· Question – חקירת המטרות באמצעות שאלות (ראה הסבר בהמשך)
· Metric – הגדרת המדדים
בהתבוננות מההתחלה לסוף, מודל GQM אומר שקשה להגדיר את המדדים ישר "על ההתחלה", בלי להבין את מטרות המדידה, ובלי לשאול את עצמנו שאלות לגבי מטרות אלה. לעיתים קרובות יישום המודל ע"פ שלושת הצעדים הללו יאפשר להגדיר מדדים טובים יותר מאשר "פשוט להגיד מה מודדים וזהו". במקרים מורכבים הדבר אף אינו אפשרי ועלול להביא למצב בו מודדים את הדבר הלא נכון!
בהתבוננות "מהסוף להתחלה", מודל GQM אומר שמדדים צריכים להיות מוגדרים כך שניתן בעזרתם לענות על שאלות מסוימות ובכך להעריך את מידת העמידה של הישות ביעדים שנקבעו לה ולהשיג את מטרת המדידה.
לשם מה נחוצה בכלל המדידה? אילו החלטות רוצים לקבל? מה יעשו עם המדד הזה? כיצד מתחברת מטרת המדידה עם יעדי הפרויקט/מחלקה/ארגון?
אין להתבלבל בין מטרות הארגון ומטרות המדידה. מטרות הארגון הן ברמה הרבה יותר גבוהה. מטרות המדידה הן ברמה הרבה יותר נמוכה ו"מעשית". שתיהן חשובות.
לכל פעילות צריכה להיות מטרה. גם לפעילות המדידה צריכה להיות מוגדרת מטרה ברורה. הגדרת מטרות המדידה נותנת תשובה לשאלה: לשם מה אנו בכלל רוצים למדוד? מה אנחנו מנסים להשיג במדידה הזאת? (האם זה כדי לעמוד ביעד מדיד מסוים? האם זה כדי לשפר את יעילות התהליך?)
לדוגמא, מטרות מדידה יכולות להיות:
· בקרה על מידת השגת יעדי המערכת (רכיב 1.2 בעץ המערכת).
· שיפור יכולת העמידה בלוח הזמנים (רכיב 4.2 בעץ המערכת).
· הערכת שיטות או כלים חדשים (רכיב 3.13) על-מנת לאפשר קבלת החלטות מושכלת לגבי אימוצם או אי-אימוצם.
· מעקב אחר התקדמות הפרויקט בהיבט של מימוש התכולה שהובטחה.
· זיהוי מודולים בעלי כמות תקלות גבוהה מהממוצע (רכיב 2.7).
· הגדלת אמינות ותחזוקתיות (רכיבים 4.8 ו- 4.6).
הישויות העולות מתוך הגדרת מטרות אלה הן: לו"ז, עלות, כלים, מודולים, קבצים וכו'. המבחן העליון של מטרות אלה הוא היכולת לקשרן באופן ברור עם יעדי הפרויקט ויעדי הארגון. במונחי מפת"ח פירושו של דבר זה הוא קישור עם רכיב כלשהו בעץ המערכת או פעילות במחזור החיים (מוצר או תהליך) כמוצג לעיל בסוגריים ליד כל מטרה. קישור זה גם עשוי לחסוך וויכוחים והתנצחויות בין בעלי התפקידים השונים באשר למטרות וישויות המדידה.
מהם המאפיינים והתכונות של הישות (מוצר, תהליך) אותם רוצים למדוד ואשר חיוניים להשגת המטרה? חקירה היא סדרה של שאלות שמטרתן לסייע בהגדרת מדדים לישות. בחקירה מאתרים "מדדים כלליים" (מאפיינים איכותיים).
חקירה היא העלאת שאלות באשר למאפיינים אותם רוצים למדוד ולהעריך לגבי הישויות, על-מנת להשיג את המטרות שהוגדרו למדידה.
דוגמאות לשאלות שאפשר לשאול על מטרות:
· המטרה: בקרה על מידת השגת יעדי המערכת. השאלות: כמה יעדים הושגו באופן מלא? כמה יעדים הושגו באופן חלקי? כמה יעדים מתוכננים להיות מושגים תוך רבעון?
· המטרה: שיפור יכולת העמידה בלוח הזמנים. השאלות: כמה אבני דרך פנימיות מומשו ללא חריגה מהלו"ז המקורי? כמה מומשו ללא חריגה מהלו"ז המעודכן האחרון שאושר?
· המטרה: מעקב אחר התקדמות הפרויקט בהיבט של מימוש התכולה שהובטחה. השאלות: כמה דרישות מערכת מומשו עד כה? כמה נבדקו בהצלחה (אומתו) עד כה? מה הצפי לסיום פיתוח ובדיקות כל הדרישות?
· המטרה: הגדלת אמינות ותחזוקתיות. השאלות: מהי אמינות המוצר בחצי השנה הראשונה לאחר ההתקנה? כמה זמן לוקח לתקן תקלות קריטיות?
המדדים הם המאפיינים הקונקרטיים הנגזרים מהשאלות ואשר לגביהם יש (וניתן!) לאסוף מידע כמותי (ועד כמה שניתן אובייקטיבי). הערה: לרוב המילה "מדד" נקראת בספרות Metric. לעיתים רחוקות יותר, היא נקראת Measure.
הצעד הבא הוא הגדרת המדדים (Metrics) עצמם. צעד זה הוא לעתים פשוט ביותר ונגזר ישירות מתוך השאלות שנשאלו ולעתים הוא קשה מאד ויש עליו הרבה חילוקי דעות. לדוגמא, הגדרת מדד עבור "מס' שגיאות שהתגלו" היא יחסית פשוטה, בעוד שהגדרת מדדים ל-"פונקציונאליות" של מוצר היא לא תמיד פשוטה. במערכות תוכנה יש קושי נוסף מיוחד, כמוסבר בפרק מדדי תוכנה להלן, ולצורך כך מוצעים מדדים מיוחדים.
מדד טוב צריך לקיים מספר תנאים עיקריים:
· הוא מובע ביחידות ברורות שקל יחסית למדוד אותן ולכמת אותן. חשוב להגדירו באופן ברור וללא "עמימות". למשל, מדד "כמות שורות הקוד": האם הוא כולל שורות רווח או לא? כולל שורות הערה או לא? האם הוא סופר פקודות שלמות בלבד, או שבמקרה שפקודה מתפרסת על-פני שתי שורות הוא יחשב זאת כשתי שורות נפרדות? יש להגדיר את כל זה במפורש ובצורה ברורה לחלוטין בגלופת הגדרת המדד (ראה גלופה).
· ברור איך הוא מתקשר לשאלות וכיצד הוא תורם להשגת מטרות המדידה ובכך לקבלת החלטות טובה ולהשגת יעדי הארגון/פרויקט.
· הוא מבוסס עד כמה שאפשר על נתונים אובייקטיביים ולא סובייקטיביים. למשל: משך זמן הוא נתון אובייקטיבי. רמת סיכון היא נתון סובייקטיבי במידה מסוימת (אלא אם מעורבים מספר בעלי עניין בהערכת רמת הסיכון, ומתקיים תהליך של חישוב ממוצע וסטיית תקן כדי להגיע לקונצנזוס – ראה מודל דלפי במילון המונחים המרכזי).
יש להיזהר במיוחד ממדדים המקיימים את התנאי הראשון בלבד, כלומר, מדדים שקל להגדירם ולאסוף נתונים עליהם, אך לא ברור מה בדיוק עושים עם הנתונים, איך לנתחם באופן משמעותי, וכיצד הם תורמים להשגת מטרות המדידה. באופן בוטה, ניתן לנסח זאת כך:
תנאי חשוב נוסף הוא "עקביות המדד", בחתך מערכות ובחתך זמן. האם המדד מספיק מנורמל כך שניתן להשוות את תוצאות המדידה בין פרויקטים שונים בעלי גודל ונסיבות שונות? אם לא, קשה להשוות נתונים לאורך זמן ולהציג ניתוחים תקופתיים כדי להבין מהי המגמה. דוגמא לכך הוא מדד "כמות שורות קוד" שעשוי להשתנות משפת תכנות אחת לשנייה (אם כי יש "טבלאות המרה" אשר מסייעות בהשוואה כזאת למרות ההבדלים).
כחלק מהגדרת המדד מומלץ כבר לקבוע, במידת האפשר, יעד מדיד שאותו רוצים להשיג. יש לשים לב שבשלב זה לא תמיד ניתן להגדיר יעדים מדידים ברורים לאותן מטרות. לעיתים ניתן להגדיר זאת רק לאחר מדידה ובחינת המצב הקיים כתוצאה מאותה המדידה (מה שנקרא "ליצור בסיס התחלתי" או baseline).
תוכנית המדדים מסכמת את מטרות המדידות, השאלות שעליהן עונים, ומפרטת עד הפסיק האחרון את הנוסחאות לחישוב המדדים אותם מודדים (ללא השארת "עמימויות"), מי אחראי על איסוף הנתונים, מי אחראי על ניתוחם ובאיזו תדירות.
זה הזמן לוודא שאכן כל המדדים מוגדרים היטב ושהם מודדים את מה שרוצים למדוד, לא יותר ולא פחות. יש לחשוב מראש על בעיות צפויות באיסוף הנתונים ובאמינותם, ולוודא שיש לכך מענה בתוכנית. ראה הסימולציה בפרק הבא, שאמורה לעזור בכך.
אם מערכת המדידה היא פרויקטלית, לטובת פיתוח מערכת אחת, יש לתעד אותה במסגרת תיק המערכת של אותו פרויקט. אם מערכת המדידה משרתת ארגון שלם או חלק של ארגון, יש להשתמש בגלופה לתוכנית מדדים בלשונית התוצרים בקיט זה.
לאחר הגדרת המדדים וטרם תחילת איסוף הנתונים (יישום מערכת המדידה), יש לערוך בדיקת ישימות קצרה: האם אכן ניתן לנתח את התוצאות והאם באמת ניתן להפיק את התועלת המצופה מכך? בדיקה זו תתבצע באמצעות סימולציה, שמשמעותה היא איסוף נתונים פיקטיביים ואקראיים, או טוב יותר, נתונים היסטוריים אמיתיים (אם קיימים), רישומם באופן מסודר, ניתוח על פי הנוסחאות שהוגדרו, בחינת משמעות התוצאות, והגדרת הפעילויות הרלוונטיות בהתאם לכך. המטרה היא לא באמת לבצע את הפעילויות, אלא רק לראות שההגדרות טובות ופרקטיות.
המצב האידיאלי הוא שרוב הנתונים יאספו בצורה אוטומטית וכתוצר לוואי של העבודה השוטפת. בצורה כזאת התקורה בהפעלת מערכת המדידה תהיה מינימאלית. רצוי לאסוף את כל המדדים לבסיס נתונים אחד גדול, אם כי הדבר אינו הכרחי (זה יכול לייעל את פעולת מערכת המדידה).
ניתן לחלק את המדדים למספר קטגוריות לפי שיטת איסוף נתונים עליהם:
נתונים שניתן לקבלם כתוצר נלווה לעבודה השוטפת ובהשקעה שולית, למשל:
· מספר שעות המושקעות בתוצר מסוים. תנאי לכך הוא כמובן שהתוצר מוגדר היטב במערכת ניהול פרויקטים או מערכת תמחיר, ושבאופן שוטף וטבעי נאספים עליו נתוני שעות עבודה, במערכת איסוף שעות קיימת בארגון.
· אחוז סטייה במימוש אבני דרך פנימיות וחיצוניות.
נתונים שאפשר לשחזרם באמינות גם במועד מאוחר יותר, למשל:
· מספר שורות קוד - גודל המודול (נשמר בספרייה או ניתן לספירה מחדש).
· מורכבות התוכנית (למשל ע"י תוכנה המודדת את המדד הציקלומטי של McCabe. ראה פירוט בנספח על מדדי תוכנה בהמשך המדריך).
נתונים שיש לאסוף אותם באופן מיוחד, רצוי בעזרת מערכת כלי ממוחשב, למשל:
· מידע על תקלות: סיווג כל תקלה לפי המקור שגרם לה: טעות באפיון/עיצוב/קידוד, טעות בתרחיש הבדיקות, וכו'.
יש להיזהר ממצב בו רוב מערכת המדידה מבוססת על נתונים השייכים לקטגוריה השלישית (יש לאסוף אותם באופן מיוחד). נתונים בקטגוריה זו עלולים להכיל אי-דיוקים רבים, ועלולים להיות לא מספיק אמינים כדי לבסס עליהם החלטות מושכלות.
ניתוח המדדים צריך לתת מענה לשאלות שנשאלו, ולמטרות המדידה שהוגדרו. יש לנתח לא רק את המצב הנוכחי, אלא גם את המגמות ואת מידת השגת היעדים המדידים שהוצבו.
לאור הניתוח הזה ניתן להחליט על פעולות שצריך לנקוט כדי לשפר את מידת העמידה ביעד מדיד כזה או אחר. אם נסתכל על מערכת המדידה כעל "לוח שעונים", הרי שפעולת ניתוח המדדים וההחלטה על נקיטת פעולות היא הפעילות של "להסתכל על לוח השעונים ולהחליט מה צריך לעשות עכשיו".
ללא ניתוח הנתונים והחלטה על נקיטת פעולות מתאימות, כל פעילות המדידה היא לחינם
בניתוח הנתונים, כמו כבר במדידה ובאיסוף, יש להיזהר מיצירת זיקה מפורשת בין ליקוי לכאורה לבין אדם מסוים. הטלת עונשים על מדדים "גרועים" יכול אולי להיראות כמו רעיון טוב, אבל למעשה הוא עלול (במידה גבוהה של סבירות) לגרום לנזק חמור לארגון. אם למשל לא תהיה בקרה מספקת על שיטת המדידה ואופן דיווח הנתונים, קיים חשש להטיית התוצאות (מתוך רצון "לא להיענש"). אם שיטת התגמול לפי מדדים מוגדרת היטב, ומערכת המדידה מבוקרת גם היטב, אז בהחלט ניתן להגיע למצב שבו מערכת התגמול אכן תהיה מבוססת על מערכת המדידה (לפחות בחלקה). קיימים ארגונים רבים המיישמים שיטה כזאת בהצלחה.
שיטת ה-BSC היא שיטה להקמת מערכת מדידה ארגונית אשר אמורה לגשר באופן אפקטיבי על אותו פער בין האסטרטגיה של הארגון לביצועים בפועל. השיטה הומצאה ע"י Kaplan ו- Norton בשנת 1993, וצברה מאז פופולאריות רבה, בשל פשטותה ועוצמתה.
שיטת BSC מגדירה באופן ברור ומפורש באלו סוגי מדדים (באלו נושאים) במיוחד צריך להתעסק ארגון על-מנת לממש את האסטרטגיה שלו.
שיטת BSC מתאימה במיוחד לארגונים בינוניים ומעלה. היא פחות מתאימה לארגונים קטנים. יישום השיטה יכול להימשך מספר חודשים עד שנתיים עד שניתן יהיה לראות תועלות אמיתיות, אולם ארגונים שעברו את המהפך ומתנהלים כעת לפי שיטה זו יכולים לתרגם את האסטרטגיה שלהם בצורה מאוד שיטתית ובעלת עוצמה לסדרת מדדים ארגוניים ברורים היורדים כלפי מטה עד אחרון העובדים.
מכאן אפשר להבין את מקור השם Balanced Scorecard ("גיליון ציונים מאוזן", באנגלית זה נשמע יותר טוב...). השם מגיע מהעובדה שבסופו של דבר יש "גיליון ציונים" לכל אחד ואחד מעובדי החברה, וכל אחת ממחלקות החברה, וגיליונות אלה מתואמים באופן מלא אחד עם השני ועם מטרות ואסטרטגיית החברה. גיליון זה מפרט את מטרות העובד, המדדים שלו, יעדיו המדידים לטווח הקרוב והבינוני (רבעון, חציון, שנה), והפעילויות שהוא אמור לבצע כדי להגשים זאת. העובד פועל בראש ובראשונה לפי המוגדר באותו גיליון. אין זה אומר שאין מקום ליצירתיות ואלתור, אך על העובד למלא קודם כל את חלקו בארגון, כפי שהגיליון מגדיר. אולי זה נקרא במבט ראשון נוקשה וקשיח, אך לאמתו של דבר זאת שיטת ניהול הרבה יותר הגיונית ואפקטיבית מאשר "בוא נגדיר אסטרטגיה וניתן לכל אחד מהמנהלים והעובדים להבין בעצמו מה לעשות כדי לממש אותה". יתרון נוסף של שיטה זו הוא שהיא מסייעת לעובדים להבין גם את מטרות הארגון ולהבין כיצד הם תורמים להן בעבודתם, דבר המייצר מחויבות אצל העובדים ותמריץ לעבודה אפקטיבית יותר.
בצורה כזאת ארגונים אלה יכולים לכוון את פעילויות כל העובדים וכל חלקי הארגון לכיוון המטרה הרצויה, ובאופן זה יכולתם לממש את האסטרטגיה שלהם משתפרת בצורה דרמטית. אם נזכור שרוב הארגונים נכשלים במימוש האסטרטגיה שלהם (למרות שהיא טובה), הרי שיכולת זו נותנת לאותם ארגונים יתרון חשוב על-פני מתחריהם.
שיטת BSC מגדירה ראשית כי על הארגון להגדיר לעצמו את החזון (Vision) והאסטרטגיה (Strategy). החזון עונה על השאלה "לאן הארגון רוצה להגיע?". האסטרטגיה עונה על השאלה "איך להגיע לשם?". זה לא חדש, רוב הארגונים מגדירים חזון ואסטרטגיה כחלק מהניהול השוטף שלהם.
לאחר שהללו מוגדרים ומוסכמים, על הארגון להגדיר מטרות (Objectives) אשר נגזרות מאותה אסטרטגיה. אולם, ופה העניין העיקרי, מטרות אלה צריכות להיות מחולקות לארבע קבוצות:
1. מטרות פיננסיות (כספיות).
2. מטרות הקשורות ללקוחות.
3. מטרות הקשורות לתהליכים הפנימיים של הארגון.
4. מטרות הקשורות לתהליכי הלמידה והצמיחה של הארגון.
הרעיון המרכזי הוא שהצלחת הארגון לממש את האסטרטגיה שלו תגיע רק אם הארגון ילמד ויצמח, דבר אשר יביא לתהליכים פנימיים אפקטיביים, דבר אשר יוביל ללקוחות מרוצים, דבר אשר יביא להצלחה כלכלית. אולם ההצלחה הכלכלית היא רק "קצה הקרחון". היא תוצאתית, ונובעת מכל המטרות הקודמות. לנסות לנהל את הארגון אך ורק לפי מטרות כלכליות דומה לניסיון להטיס מטוס רק לפי מד הדלק שלו...
לאחר-מכן מגדירים לכל מטרה באופן מפורט: מדדים (Measures), יעדים מדידים (Targets), ופעילויות (Initiatives) להשגת אותם יעדים.
כל הנ"ל מתבצע בצורה איטרטיבית, מלמעלה כלפי מטה בארגון (Top-Down). המטרה של הארגון כולו הופכת להיות מטרת-העל של מחלקה מסוימת, והיא בצורה מגדירה לעצמה מטרות משנה וכך הלאה.
באופן כזה מקבלים קבוצה של מדדים ברורים אשר מאפשרים לדעת בדיוק היכן הארגון נמצא ביחס למידת מימוש האסטרטגיה שלו. בנוסף, לכל חלק בארגון יש מדדים משלו, וברור לגמרי כיצד הוא תורם להשגת האסטרטגיה הארגונית. בסופו של דבר הגדרת המדדים מגיעה אפילו עד העובד הפשוט, אשר מוגדרים לו מספר קטן של מדדים ברורים, ואשר מחדדים לו כיצד ההנהלה מעוניינת שהוא יפעל על מנת להביא להצלחת הארגון כולו. באופן כזה, ההצהרות העמומות אשר מופיעות בד"כ בחזון בצורה של "הספק מספר אחד במדינה", "עובדים מרוצים שמספקים שירות מעולה", מתורגמות לפעילויות יומיומיות ברורות ומדידות.
לפי שיטת BSC תהליך יישום ה- BSC מורכב מהשלבים הבאים:
תרגום החזון (Translating the vision)
· בשלב זה מחדדים את הגדרת החזון ואת האסטרטגיה האמורה להשיגו. משיגים על כך הסכמה רחבה ככל האפשרי של הדרג הניהולי הבכיר ודרג הביניים.
הפצת האסטרטגיה עד אחרון העובדים וקישור ליעדים מחלקתיים ואישיים (Communicating and linking)
· הפצת האסטרטגיה לכל העובדים, כנסי הסברה, עלוני הסברה, פרסום המידע באתר הפנימי של החברה, וכל פעילויות ה"שיווק" הדרושות כדי שהעובדים "יקנו" את האסטרטגיה שגובשה.
· את המטרות הארגוניות מפרטים עבור כל מחלקה ומחלקה, כך שברור לכל מחלקה מהן מטרותיה שלה כדי לאפשר את מימוש המטרות הארגוניות. ממשיכים הלאה עם הפירוט יותר ויותר למטה, עד שמגיעים למטרות אישיות לכל עובד.
· המלצת BSC היא לקשר את ביצועי העובד (כפי שמשתקפים במדדים האישיים שלו!) לתגמול הכספי שלו. קיים מספר לא קטן של חברות המיישמות עקרון זה בהצלחה. חשוב כמובן להקפיד לבצע בקרה מתאימה לתהליך איסוף הנתונים ודיווח תוצאות המדדים על-מנת למנוע מצב של דיווח נתונים לא אמינים.
חשוב מאוד: יש להמשיך וליישם את שיטת BSC בכל רמות הארגון, מלמעלה ועד למטה. השארת המדדים והיעדים ברמת ההנהלה בלבד מקטינה באופן משמעותי ביותר את הסיכוי להצליח ביישום השיטה
תכנון עסקי מפורט (Business planning)
· קביעת יעדים מדידים אישיים ומחלקתיים, לפי המדדים שהוגדרו.
· תכנון מפורט לכל הפעילויות העסקיות על-מנת לוודא שכל הפעילויות תורמות להשגת המטרות הארגוניות והמחלקתיות. פעילויות שאינן תורמות – מבוטלות או נדחות!
· הקצאת משאבים לתוכנית כדי שיהיה ניתן לממש את הפעילויות שסוכמו.
· הגדרת אבני-דרך לבקרת התקדמות התוכנית.
משוב ולימוד (Feedback and learning)
· הבהרת וחידוד החזון, לאור תוצאות הביניים (המדידות!) מיישום האסטרטגיה. מתן משוב להנהלה לגבי מידת יישום האסטרטגיה ותיקונים/שינויים שצריך לבצע בהם.
· הפקת לקחים מהתהליך ושיפורו באופן מתמיד.
להלן דוגמא (חלקית) של ארגון המספק שירותים וכיצד הוא יכול להגדיר את מערכת המדידה תוך יישום שיטת BSC.
חזון הארגון
ספק מהטובים בעולם, מוכוון לקוחות, מספק שירותים איכותיים ביותר בכל העולם.
אסטרטגיה
· S1: להיות יותר מוכוון לקוח.
· S2: להגדיל את כמות העסקים ואיכותם.
· ועוד...
מטרות עבור S1:
· S1-01 (מטרה הקשורה ללקוח): להבטיח הספקה בזמן.
· S1-02 (מטרה הקשורה ללקוח): להגדיל את איכות המוצרים
· S2-01 (מטרה הקשורה לתהליכים פנימיים): להקטין את הזמן הכולל להספקת המוצרים.
· ועוד ...
מדדים עבור S1-02:
· S1-02-M1: אחוז המוצרים הפגומים שיוצרו.
· S1-02-M2: אחוז המשלוחים שסופקו ללקוחות עם מוצרים פגומים.
יעדים מדידים עבור S1-02:
· S1-02-M1: 0.02% בשנה הקרובה.
· S1-02-M2: 0% בשנה הקרובה.
פעילויות (Initiatives) עבור S1-02:
· שיפור תהליך הייצור ע"י איתור נקודות התורפה ומניעת תקלות.
· שיפור תהליך המשלוח כדי לוודא ששום מוצר פגום לא יסתנן למשלוח ללקוח.
ארגונים שעברו את התהליך (הקשה) של יישום שיטת BSC מצהירים כי עתה קל הרבה יותר לנהל אותם, קל יותר לכוון אותם לכיוון הרצוי, לשלוט בפעילויות היומיומיות של העובדים אשר אמורים בסופו של דבר להגשים את החזון הארגוני.
מנהלים שהיו שותפים לתהליך יישום BSC מצהירים כי עתה ברור להם הרבה יותר "מה רוצים מהם בדיוק".
נראה כי לשיטת BSC אכן יתרונות רבים, אולם יש להיזהר מיישומה ללא ליווי צמוד של יועץ מנוסה. כשלון ביישום (עקב נפילה ל"מלכודות" ידועות) עלול לגרום לנזק חמור לארגון.
למדדים ומדידה, בהקשר של מחזור החיים, יש משמעות משולשת:
1. מדידה של מחזור החיים, כלומר מדידה של תהליכי פיתוח המערכת.
2. היכן במחזור החיים מתבצעות מדידות (הן של המערכת והן של מחזור החיים עצמו).
3. מי מבצע את המדידות.
להלן פירוט כל סעיף.
מדדי מחזור החיים מודדים את תהליך הפיתוח עצמו, במטרה לוודא שהוא יעיל ואפקטיבי (ראה ההגדרה של יעילות ושל אפקטיביות במילון המונחים המרכזי).
להלן דוגמאות למדדים של מחזור החיים עצמו:
· אחוז הדרישות (המוגדרות בתיק האפיון) אשר סיימו פיתוח אך טרם נבדקו.
· כמות התקלות שהתגלו במהלך בדיקות המערכת, בסיווג לפי השלב במחזור החיים שבו נוצרה התקלה (אפיון/עיצוב/בניה).
· קצב תחלופת כוח-האדם (Turnover) בחלוקה לשלבי מחזור החיים.
· אחוז ההשקעה בבדיקות המערכת, מתוך סה"כ ההשקעה בפרויקט כולו.
מדידת מדדים אלה והמעקב אחריהם הם מעקב ביצוע מול תכנון של הפרויקט, אשר מתועד, באופן שוטף, בפרק המנהלה של תיק המערכת של השלב הנידון. ניתן גם לשייך כל מדד לסעיף הרלוונטי בעץ המערכת, ולתעד את מדידתו באותו סעיף (למשל, בדוגמאות לעיל, כמות התקלות ואחוז ההשקעה בבדיקות מערכת שייכים לסעיף 4.8.1 – תוכנית הבדיקות, ואילו מדד קצב תחלופת כוח-אדם שייך לסעיף 5.1 – עלות הקמה).
גלופות לימוד ועבודה בנושאים התומכים: ניהול פרויקטים, ניהול משימות ושיקופים, מסייעות בבניית תיעוד זה.
הגדרת מדדים ומדידות מתבצעת באופן שוטף לאורך מחזור החיים, אך בפרט במקומות הבאים:
· בתחילת ובסיום כל שלב ראשי בתהליך הפיתוח.
· בשיקופים/סקרים ראשיים.
· בבקרות מזדמנות של צוות ניהול האיכות או הצוות המנהלי (ועדת ההיגוי).
· בכל מקרה בו מתגלות תקלות או סטיות מהמצב הרצוי (אם כי להתחיל למדוד כשכבר יש בעיה זה ככל הנראה מאוחר מדי...)
זאת בד"כ אחת הבעיות הנפוצות של נושא המדדים. את הגדרת המדדים יש לבצע בתחילת כל שלב במחזור החיים, בשיתוף צוות הפרויקט ופונקצית אבטחת איכות, ולהסתפק ב 3-5 מדדים כמוסבר במבוא.ביצוע המדידות מורכב עוד יותר. יש לשאוף לכך שאת מירב המדידות, בפרט המדידות הבסיסיות והגולמיות, יבצע צוות הפרויקט כחלק מעבודתו השוטפת (המצב האידיאלי הוא שהנתונים יאספו בצורה אוטומאטית וכתוצר לוואי של העבודה השוטפת), אך סביר שחלק מהביצוע ייפול על שכמו של צוות אבטחת איכות. ניתוח הנתונים, הפיכת המדדים הגולמיים למספרים יותר משמעותיים, עריכת חישובים סטטיסטיים "צולבים" וניהול כל זאת ברשומות איכות מסודרות, כל אלה יכולים להיעשות רק ע"י פונקציה מרכזית כמו אבטחת איכות או אפילו עוזרים מיוחדים להנהלת הארגון.
לפירוט נוסף, ראה סקרי הנהלה כמוגדר בקיט תקן ISO9000 שבכרך איכות.
רצוי לעיין תחילה בקיט עץ מערכת אוניברסלי בכרך יסודות.
עץ המערכת הוא הבסיס למדדים. מדדים הם אורתוגונליים לעץ המערכת ו"מפוזרים" בין כל הרכיבים. ברוב המקרים, עצם הפירוט של הרכיב יוצר מדדים "טבעיים" שמוגדרים מאליהם.
להלן רשימה חלקית של רכיבים מיוחדים, המכילים מדדים מובנים, כגון:
רכיב זה נמצא בתיק המערכת, אך הוא אינו קשור למדדים של עץ המערכת, אלא לתיעוד תוצאות מדדים של מחזור החיים. ראה פירוט בפרק הקודם.
מטרות המערכת מתורגמות למדדים ברכיב 1.6 (תועלות וישימות) בעץ המערכת. ראה להלן.
מדידת הנזקים הנגרמים במצב הקיים. עלות מניעת הנזקים (למעשה עלות המערכת) יהוו את הבסיס לניתוח עלות/תועלת.
קישור ליעדי הארגון ע"י מאפיינים המאפשרים כימות ומדידה שאכן המערכת עונה ליעדי ארגון אלה, מתי וכמה. זהו אותו קישור שדובר עליו בהרחבה במבוא לקיט זה, הקישור שמאפשר בסופו של דבר לתרום להשגת יעדי הארגון ע"י השגת יעדי המערכת/הפרויקט.
ניתן ברכיב זה לפרט גם את הקשר של יעדי הפרויקט (להבדיל מיעדי המערכת) ליעדי הארגון הספק (המפתח את המערכת).
· מדדי סיכונים: התפתחות מספר הסיכונים הקריטיים (מעל רמה 15) לאורך זמן. (האם הפעילויות להפחתת הסיכונים אפקטיביות?)
· מדדי תועלות ואיכות.
· מדד מסכם לעלות/תועלת.
· כמות וסוג המשתמשים.
· כמות וסוג מערכות משיקות פנימיות וחיצוניות.
· מידת השימוש החוזר בתבניות תקניות.
· מספר החלונות הפעילים בו זמנית.
· מדדי הנדסת אנוש וארגונומיה.
ראה הרחבה לסעיף 2.4.0 ממשק אדם מחשב בקיט עץ מערכת אוניברסלי.
· התפלגות התהליכים לפי כמות המשתמשים בהם (מאפשר לזהות תהליכים עם יותר מדי משתמשים, או עם מספר משתמשים קטן במיוחד).
· התפלגות התהליכים לפי כמות הפעילויות או נקודות ההחלטה המרכיבות אותם.
· מדדי כמות שורות קוד ו- 'צפיפות תקלות' (Defect Density, כמות תקלות לכל 1000 שורות קוד).
· מדדי סביכות ומבניות.
לפירוט בנושא מדדים אלה, ראה נספח בנושא מדדי תוכנה בהמשך.
· מספר הטבלאות וכמות השדות בהן.
· רמת נרמול הטבלאות.
· מספר הקשרים (מסלולים) בין הטבלאות. כמות וסוג הקשרים (1:M, M:N). ריבוי קשרי (M:N) מצביע על סביכות! סוג הקשרים: קשרי אסוציאציה, קשרי הכלה, קשרי הורשה. מידת היכולת להציג אותם במקביל, או לנוע בקלות מהאחד לשני.
· רמות השבירה, המיון והסיכום. ראה רכיב 2.15 בתיק האפיון.
· מספר סיכוני במ"ם שאותרו.
· מספר ניסיונות עד להצלחת פריצה.
· מספר כניסות לא-חוקיות עד לגילוי.
רכיב זה הוא כולו מדדים!
· זמן ביצוע טרנזקציה (לכל סוג טרנזקציה) או פעולה נפוצה במערכת.
· אחוז דרישות הביצועים שהמערכת עומדת בהם באופן מלא.
· היקף בסיס הנתונים הממוצע והמקסימאלי.
ראה הרחבה לסעיף 2.21 נפחים, עומסים וביצועים בקיט עץ מערכת אוניברסלי.
· אחוז משימות שבוצעו מתוך סה"כ משימות.
· אחוז החריגה באבני הדרך הראשיות בפרויקט.
· מספר משימות שנפתחו בחודש האחרון, לעומת מספר משימות שנסגרו.
· מורכבות תוכנית העבודה (כמות הקשרים בין משימות).
· מספר העדכונים של תוכנית הבסיס בתכנית העבודה.
· מספר השינויים בנתיב הקריטי של הפרויקט.
· מספר הפעילויות שהיה צריך לבצע בשנית.
· אחוז ישויות האפיון (פרק 2.5 בעיקר) אשר השתנו/נוספו בפרק זמן (מדד זה מעיד על יציבות דרישות הלקוח, ואיכות האפיון).
· אחוז ישויות התצורה (תוכניות/קבצי מקור) שהשתנו או נוספו בפרק זמן (מדד זה מעיד על "יציבות" תצורת המערכת).
· זמני תגובה לקריאה (זמן ממוצע עד תחילת טיפול).
· זמני שירות (זמן ממוצע לתיקון, בפילוח לפי חומרת התקלה).
ראה הרחבה לרכיב 4.6 שירות ותחזוקה תחת עץ המערכת.
רכיב 4.8.1 תוכנית הבדיקה מפנה לתיק הבדיקות, כאשר הבדיקות ברובן הן בדיקת מדדים וערכים שנקבעו מראש, ומידת העמידה בהם.
דוגמאות למדדים בתחום הבדיקות:
· אחוז צעדי הבדיקה שעברו בהצלחה בכל סבב בדיקות.
· אחוז התקלות שהתגלו עד כה, מתוך סה"כ כמות התקלות הצפויה (לפי היקף ההשקעה בפיתוח). (מדד זה מאפשר לדעת האם בדיקות המערכת אפקטיביות).
· אחוז התקלות החדשות שהתגלו בסבב הבדיקות הנוכחי, מתוך סה"כ התקלות שהתגלו עד כה (מדד זה מאפשר לדעת האם המוצר כבר התייצב מבחינה פונקציונאלית. אחוז זה יורד ככל שיציבות ובשלות המוצר גדלה. יש להקפיד לבדוק בכל סבב או מדי מספר סבבים בדיקת רגרסיה מלאה, ולמדוד כמה תקלות חדשות התגלו. ככלל, אם התגלו יותר מ- 3%, סביר להניח שהמוצר עדיין לא בשל לשחרור ללקוח).
· אחוז התקלות החדשות שהתגלו בשלב בדיקות הקבלה, מתוך סה"כ התקלות שהתגלו עד כה בשלב בדיקות המערכת. זהו מדד לאפקטיביות בדיקות המערכת.
· זמן פעולה תקינה וללא השבתות (Uptime) באחוזים מתוך סה"כ הזמן שעבר (ביום/בשבוע/בחודש/בשנה).
· זמן ממוצע בין תקלות MTBF (Mean Time Between Failures).
· זמן ממוצע בין תקלות קריטיות (שגרמו להשבתה) MTBCF (Mean Time Between Critical Failures).
· זמן ממוצע להתאוששות מתקלות MTTR (Mean Time To Recover).
· עלויות מתוכננות (מאושרות) מול ביצוע בפועל.
· ניתוח עלות/תועלת לפי שיטת "הערך המושג" (Earned Value). למשל: מדד BCWP (Budgeted Cost of Work Performed) מאפשר לדעת מהו הערך (במונחי התקציב המקורי) של העבודה שבוצעה.
· מדדים לעלויות השוטפות (שלב התחזוקה).
· אמידת עלויות עוסקת, מעצם טבעה, במדדים להערכת היקף המערכת, משאבים נדרשים ולו"ז. ראה הקיט אמידת עלויות בכרך נושאים תומכים.
פירוט מלא של הרכיבים והמאפיינים שלהם (שלגביהם ניתן לערוך מדידות) נמצא בתיקי המערכת השונים, בפרט תיק האפיון ותיק בדיקות המערכת. לרוב רכיבים אלה יש נספחים מפורטים ורשימות תיוג שמעצם טבעם מכילים מדדים
עץ המערכת כולו מתפתח במהלך מחזור החיים וכל רכיב בו מוגדר ומאופיין יותר ויותר עם ההתקדמות במחזור החיים. עצם ההגדרה והאפיון יוצרים מדדים טבעיים וברורים. אם בייזום קשה עדיין "למדוד", הבקרה של תיק האפיון (בשיקופים ובאבטחת איכות) כבר עוסקת בין השאר בבדיקת מדדים. הפיכת אפיון למפרט וכתיבת המפ"ל (מסמך פנימי לבדיקות, בשלב היציאה למכרז, ראה קיט בקשה להצעות), יוצרים מעצם טבעם מדדים ברורים. וכך הלאה בעיצוב, בבנייה וכו'. חשוב שבקרה זו גם תבחן את מידת ה"מדידתיות" (measurability) של כל רכיב: האם הוא מוגדר באופן המאפשר למדוד אותו, האם נקבעו לו מדדים, באיזו מידה מדדים אלה משפיעים על תפקוד המערכת וכו', ניתן לעשות בדיקה זאת באמצעות סימולציה. על מנת למנוע ויכוחים (אילו מדדים חשובים, "מי קבע שזהו הפרמטר לאיכות המערכת" וכו') חשוב להגדיר ולהסכים עליהם מראש.
מדידת עץ המערכת, היינו, מדידת המערכת, נעשית באופן ישיר וטבעי ונובעת מעצם הטיפול בעץ המערכת לאורך השלבים השונים של מחזור החיים
הקישור ליעדי המערכת והארגון שעליהם מדברת שיטת ה- GQM שהוצגה לעיל, נמצא, כמובן, ברכיב היעדים (1) של עץ המערכת. יש לשים לב במיוחד לרכיב 1.4 (השתלבות ביעדי הארגון). שאר הרכיבים, בפרט רכיב 2 יישום, הם בעצם המטרות (הישויות) והמאפיינים.
מדידה ומדדים נעשים לא רק ברמת הפרויקט/מערכת, אלא גם ברמת הארגון כולו (יחידת המחשוב) ולו רק על-מנת להשוות בין הפרויקטים השונים.
הנחיות מפת"ח באשר למדידות על פני הארגון כולו נמצאות במקומות הבאים:
· הקיט תקן ISO9000 בכרך איכות.
· הקיט אבטחת איכות בכרך איכות.
· הקיט ארגון יחידת המחשוב בכרך ניהול.
· הקיט תכנון קיבולת בכרך ניהול.
בסעיף לעיל הדן ב"מי מבצע את המדידות" כבר צוין שיש קושי רב בהגדרת המדדים והסכמה עליהם, ועוד יותר בביצוע המדידות וניתוחן. לעומת זאת, יש למדדים ומדידה "בעלי ברית" חשובים שהקפדה עליהם מסייעת רבות ויכולה לתת מדדים ומדידה כתוצר לוואי שלהם. להלן מספר נושאים מסייעים כאלה:
אמידת עלויות
אמידת עלויות עוסקת, מעצם טבעה, במדדים להערכת היקף המערכת, משאבים נדרשים ולו"ז. ראה הקיט אמידת עלויות בכרך נושאים תומכים.
ניהול תצורה
ניהול תצורה איננה עוסקת ישירות במדידה, אבל חלק מניהול תצורה תקין הוא מדידה של כמות השינויים במרכיבי המערכת (כמה שינויים היו במסמכי האפיון? כמה שינויים בקבצי הקוד?). ראה הקיט ניהול תצורה בכרך נושאים תומכים.
בקשה להצעות (שלב המכרז)
שלב בקשה להצעות כולל הגדרת מדדים ומדידתם מעצם הטיפול במפרט, מפ"ל (מסמך פנימי לבדיקות, הקריטריונים לשקלול ההצעות) ובדיקת ההצעות והשוואה ביניהן. חלק ניכר ממדדים וקריטריונים שהוגדרו בשלב זה יכולים וחייבים לשמש מדדים וקריטריונים לבקרת שלבי הפיתוח הבאים אחרי המכרז: עיצוב, בנייה, בדיקות מערכת וכו'. ראה הקיט בקשה להצעות - RFP ,כרך יסודות בתת-כרך מחזור חיים.
ניתוח חלופות
ניתוח חלופות וחקר ישימות דומים עקרונית לבקשה להצעות ומעצם טבעם נותנים ערכים כמותיים ואיכותיים לחלופות השונות. ערכים אלה הם הקובעים את החלופה המועדפת. ראה הקיט ניתוח חלופות בכרך נושאים תומכים.
ניתוח סיכונים
ניתוח סיכונים מתמקד באותם גורמי הצלחה קריטיים (CSF, Critical Success Factors), רכיבים בעץ המערכת או פעילויות במחזור החיים, אשר עשויים לגרום לאי-היתכנות המערכת או להיתכנותה ביחס עלות/תועלת בלתי סביר. סיכון מוערך ע"י הקצאת ערך כמותי לגורמים אלה: סבירות הסיכון וחומרת הסיכון. יש כאן מדידה מעצם ההגדרה, למרות שהיא יותר סובייקטיבית מטבעה. ראה הקיט ניהול סיכוניםבכרך נושאים תומכים.
בדיקות מערכת
שלב בדיקות המערכת מתמקד למעשה בבדיקת מדדים וערכים שונים שהוגדרו מראש. חלק מהמדדים מתייחסים לתהליך הבדיקות עצמו: מספר סבבי בדיקות, קריטריונים למעבר לשלב הבא, כמות תקלות וכו', וחלק מהמדדים מתייחס לרכיבי המערכת השונים: נפחים, עומסים וביצועים וכו'. ראה הקיט בדיקות מערכת בכרך יסודות, מחזור חיים.
תחקור – הערכת מערכת
שלב תחקור המערכת עוסק בין השאר במדידת התועלות מהמערכת (התועלות בפועל, לאחר הטמעתה), וכן במדידת שביעות הרצון מהמערכת. ראה הקיט תחקור מערכת בכרך יסודות, מחזור חיים.
סוג מיוחד של מדדים הוא מדדי תוכנה (Software Metrics). תוכנה היא מטבעה ישות בעלת מאפיינים רבים שאינם מוחשיים (למשל: מורכבות התוכנה) ולכן קשה להגדיר עבורה מדדים (מאפיינים) אובייקטיבים ומוסכמים. עם זאת (או בגלל זאת), נעשה מאמץ מתמשך, באקדמיה ובתעשייה, להגדיר ולהסכים על מדדים לתוכנה, בפרט מדדים המטפלים בגודל התוכנה ומורכבותה (סביכות).
זהו המדד הפופולארי ביותר למדידת גודל התוכנה. לעיתים הוא נקרא בשם LOC (Lines Of Code) או SLOC (Source Lines Of Code) או אפילו KLOC (Kilo Lines Of Code, כלומר, אלפי שורות קוד). מדד זה, בצירוף המדד של כמות התקלות שהתגלו, נותן מדד פופולארי במיוחד הנקרא "צפיפות תקלות" (Defect Density). הוא מחושב ככמות התקלות לכל אלף שורות קוד. מדד זה נפוץ ביותר בתעשיית התוכנה בשל פשטותו, אולם הוא מעורר גם מחלוקת רבה בשל העובדה שקל מאוד להגיע למסקנות מוטעות אם מתבססים אך ורק עליו.
מדד זה נותן הערכה של "כמות הפונקציונאליות" שהמערכת מספקת, לפי כמות המסכים, השדות, הכפתורים, הקבצים, הקלטים, הדוחות וכו'. מדד זה לא הפך לפופולארי עקב מורכבות מדידתו. היתרון במדד זה שהוא בלתי-תלוי בשפת-תכנות, ולכן הוא מאפשר להשוות את גודל המערכת (מבחינת כמות הפונקציונאליות שהיא מספקת) למערכת אחרת, למרות ששתיהן פותחו בשפות-תכנות שונות.
מודד את מספר פקודות הסתעפות (עם או בלי תנאי) והלולאה בתכנית. מודל זה שייך לקבוצה רחבה יותר של מודלים ומדדים המסתמכים על טכניקת ה- Flow graphs.
מספר נקודות כניסה ויציאה מכל מודול, התפלגות השימוש בפקודות בתכנית, מספר הקריאות למודול, כולל "עומס" הפרמטרים המועבר ומוחזר בכל קריאה.
העושים שימוש בתורת הגרפים למדידת מספר הצמתים בתכנית ומסלולי הבקרה השונים בהם "זורמת" התכנית.
מודד את סביכות התוכנה והיכולת להבינה כפונקציה של מספר המשתנים והפקודות הכולל והייחודי (unique) בתכנית.
כולל קטעים מתים שכלל לא עוברים בהם.
מודדים את מידת מורכבות עיצוב התוכנה. לדוגמא, מדדים שהוצעו ע"י Chidamber ו- Kemerer.
מדדי סביכות מצביעים לא רק על בעיות הנדסיות מבניות העשויות לגרום לתקלות (מחקרים רבים מצביעים על מתאם ברור בין רמת הסביכות למספר התקלות), אלא גם על קושי בהבנת המודול והיכולת "להשתלט" עליו.
מדדים אלה "שייכים" ברובם לרכיב 2.7 של עץ המערכת והם חלק מקבוצת מדדי עץ המערכת המוסברת בפרקים הקודמים
מדדי סביכות בוחנים את התוכנה "מבפנים" בשיטת "הקופסא הלבנה" (או השקופה). קבוצה לא פחות חשובה, הגם שאיננה כל כך "מדעית", הם מדדים חיצוניים המודדים את ההתנהגות הפונקציונאליות של המערכת בשיטת "הקופסה השחורה": נוחיות תפעול, מענה לדרישות, נכונות הנתונים, ביצועים, מס' נפילות וכו'. כל אלה, שייכים כאמור למדדי עץ המערכת כמוסבר בפרקים הקודמים.
מדידת המדדים מהווה מדד נוסף וככזה אין משמעות להגדירו כחלק מאבטחת איכות אלא, אם יש צורך, להגדירו כמדד נוסף. לפיכך, מדידה למדדים תתבצע על פי ההנחיות בכללי א"א, להלן.
אבטחת איכות של מערכת המדידה תתמקד בתוצרים, קרי המדדים עצמם (ובמקרים בהם נכתבה תוכנית מדדים, גם בה), ובתהליך ביצוע המדידה, קרי איסוף הנתונים, ניתוחם וביצוע פעולות שיפור.
מומלץ לבדוק את המדדים לפי רשימת התיוג הבאה:
· מעט מדי מדדים? יותר מדי מדדים?
· מי בדיוק היזם? מה מידת מחויבותו?
· האם מוגדרים ומיושמים יעדים לאיכות המוצר ולתהליך הפיתוח?
· האם ברור מה הצעד הבא ביישום תוכנית המדדים ומה משמעויותיו?
· מי אישר את המדדים? האם יש פורום הדן במדדים?
· האם המדדים נאספים תקופתית, ומוצגים למנהלים המתאימים בארגון (בכל הרמות)?
· האם עומדים ביעדים שהוצבו? אם לא, האם נוקטים בפעילויות רלוונטיות לתיקון המצב?
· האם תוצאות המדידות מכילות מספיק מידע על מנת לקבל החלטה להמשך?
· האם מופקות מסקנות מתהליך המדידה?
· האם התועלת המופקת המדידה עולה על העלות?
· האם קיים עדיין צורך להמשיך ולמדוד?
· האם איסוף המדדים יוצר תקורה בלתי-סבירה?