קיט זה דן בנושא הרחב של תועלות, ישימות ועלות/תועלת. הוא תומך ברכיב 1.6 של עץ המערכת ומסייע בהגדרתו ובדיקתו. רכיב 1.6 הוא מורכב מאד ואורתוגונלי לעץ המערכת כולו. הוא מכסה מספר נושאים מרכזיים: תועלות המערכת, ישימותה (היתכנותה), איכותה (טיבה) והמדד המסכם הכולל: עלות/תועלת המערכת. כל אחד מתת הסעיפים של רכיב זה הוא עולם בפני עצמו.
רכיב 1.6 מציג את תועלות המערכת לצד ישימותה ואופן היתכנות השגת תועלות אלה. בהנחה שאין בעיות היתכנות בסיסיות ולא סיכונים מיוחדים, המינוח הנכון הוא סבירות ולא ישימות, מה גם שבמפת"ח המונח יישום הוא בשימוש אחר. אלא שהמונח חקר ישימות נפוץ ומקובל ולפיכך גם במפת"ח נשתמש בו. עם זאת, נשתמש לחילופין גם במונחים סבירות והיתכנות.
רכיב זה עוסק למעשה בשני תת-נושאים נכבדים:
· 1.6.1 סיכונים - ישימות הפרויקט
· 1.6.2 עלות/תועלת – ישימות עסקית
ניהול סיכונים או בחינת ישימות הפרויקט הוא כלי מרכזי וחיוני ביותר עבור מנהל הפרויקט וכל הגורמים האחרים המעורבים בפרויקט. כלי זה מסייע באיתור נקודות תורפה וכשלים פוטנציאליים העשויים לגרום לחריגות משמעותיות בלוחות הזמנים, בעלויות ובתכני הפרויקט, אם לא להפסקת הפרויקט וכישלונו. ניהול סיכונים מאפשר לאתר נקודות תורפה אלה מבעוד מועד, להעריכן ולנקוט בפעולות מתקנות מתאימות. זה מטופל בהרחבה בקיט ניהול סיכונים בכרך זה.
הקיט הנוכחי עוסק בישימות העסקית של הפרויקט. ישימות עסקית נחלקת למספר מרכיבים:
· תועלות וחסכונות
· ישימות: איכות וטיב
· עלות/תועלת -איכות כוללת
נושא התועלות הוא יחסית עצמאי והתלות שלו היא בעיקר ברכיב 1.2 יעדים ומטרות (תועלות הן בד"כ כימות של מטרות). שני תת-הנושאים האחרים: חקר ישימות ועלות/תועלת, תלויים ברכיב 5 עלות (ובתועלות) ואי לכך יוגדרו בד"כ לקראת סיכום עץ המערכת, למשל, בסוף האפיון.
חקר ישימות (Feasibility Study) כולל שני נושאים:
· בדיקת היתכנות: האם פיתוח המערכת והתקנתה ניתנים לביצוע?
· בדיקת טיב: מה איכות הפתרון המוצע כשלעצמו (יחסית למקובל בשוק) ויחסית לחלופות אפשריות?
היא למקרים קיצוניים: האם בכלל ניתן לבנות את המערכת. הבדיקה היא ברמה פרטנית של רכיבים (או קבוצת רכיבים) ויכולה להיעשות לכל הרכיבים, או רק לרכיבים קריטיים - CSF, אשר עיכובים בהם עלולים לגרום לעיכוב במערכת כולה. בדיקה זו מתוארת להלן. בעבר התרכזה הבדיקה בהיתכנות הפיסית ממש. היום, עקב התבגרות עולם המחשוב ומגוון הפתרונות האפשריים, ההתמקדות היא יותר בהיבטים ארגוניים ואנושיים והיא משיקה לתחום בדיקת טיב. היתכנות, היום, איננה במובן של האם הדבר בכלל ניתן לביצוע (feasible), אלא האם הוא סביר.
נקראת גם הערכת עלות/תועלת וכוונתה מה מידת איכות הפתרון המוצע:
· כשלעצמו, היינו, יחסית למקובל בשוק
· יחסית לחלופות אחרות: האם זה פתרון טוב (לא בהכרח הטוב ביותר), האם הוא פתרון סביר?
שני ההקשרים גולשים כבר לתחום של ניתוח חלופות. חקר ישימות וניתוח חלופות הם נושאים קרובים ויש לעתים בלבול-מה ביניהם. ההבדל העקרוני הוא ברור בחקר ישימות נבדקת ישימותו של פתרוןx בעוד שבניתוח חלופות נערכת בדיקה השוואתית של מספר פתרונות (x לעומת y לעומתz וכו'). להסבר נרחב יותר ראה הקיט ניתוח חלופות בכרך זה. בדיקת טיב היא לפי מדדי האיכות. אחד ממדדי האיכות הוא כלכליות, לפיכך בדיקת טיב מבוססת על אמידת עלויות המערכת כשלב מוקדם (כך כמובן גם הערכת העלות/תועלת). להסבר נרחב על אמידת עלות המערכת ראה קיט אמידת עלויות בכרך זה.
העובדה שישימות ועלות/תועלת הוא רכיב בעץ המערכת - רכיב שיש להגדירו ולבנותו כמו כל רכיב אחר - פירושה שמדידת תועלתיות חקר ישימותה והערכת העלות/תועלת שלה מתבצעים באופן שוטף במהלך מחזור החיים. בנוסף, רכיב 1.6 הוא סופר-אורתוגונלי (חוצה מערכת) ולפיכך רצוי שהטיפול בו ייעשה לאחר הטיפול ברכיבים האחרים ושתוקדש לכך פעילות מיוחדת בתכנית העבודה. רכיב 1.6 הוא אפוא, אורתוגונלי הן על פני עץ המערכת והן על פני שלבי מחזור החיים. בפרקי מחזור החיים השונים מודגשות נקודות הזמן הטבעיות לחקר ישימות ולהערכת עלות/תועלת:
· סוף שלב הייזום
· סוף שלב האפיון
· שלב בקשה להצעות לאחר קבלת הצעות הספקים
שלב בקשה להצעות הוא כולו חקר ישימות אחד גדול. פרויקט העובר שלב זה מבצע חקר ישימות באופן טבעי, כולל בדיקת היתכנות, סיכום עלות/תועלת וכו'. בפרויקטים שאינם יוצאים למכרז, מומלץ שיבוצע במקום שלב הבקשה להצעות, חקר ישימות מפורט.
· שלב בדיקות המערכת.
מדידת תועלות והכימות שלהן נעשים ע"י יחידות שירות שהמערכת מספקת למשתמשי הקצה (בני-אדם או מערכות מידע אחרות). יחידת שירות היא טרנזקצית קלט או עדכון, תשובה לשאילתא, הפקת דו"ח או העברת קובץ - כל דבר שניתן להגדירו כשירות של המערכת לעולם החיצון. כל השאר הם שירותים פנימיים ואינם כלולים בתועלות.
יחידת שירות תוגדר לפי:
· הנמען (מקבל השירות)
· ערך כלכלי או שווה ערך
· כמות (x יחידות שירות לחודש/יום).
מערכות מידע חייבות להציג תועלות ישירות לארגון - היינו פעילויות ונתונים המובנים למשתמש ולדרג הניהולי:
· מס' כניסות למחסן
· מס' דוחות מלאי שהופקו ולמי נשלחו
· מס' שאילתות במערכת כ"א
· חיסכון ישיר בהוצאה כספית
מערכות תשתית, שתפקידן לשרת מערכות מידע והטרנזקציות שלהן הן פנימיות, יציגו תועלת נגזרת, היינו, יחידות שירות שהן מספקות למערכות המידע כגון: זמני עיבוד, פעולות קלט/פלט, מנות תקשורת, שטחי אחסון, פעולות Housekeeping, מס' קומפילציות, מס' הפעלות של העורך (editor) וכו'. יחידות שירות של תשתיות אינן בהכרח קשות יותר להגדרה. דווקא משום שהן טכניות יותר ואינן מחויבות להצגת תועלת ישירה, ניתן וצריך להגדירן באופן ברור.
בכל מקרה, בין במערכות מידע בהן התועלת היא ישירה ובין במערכות תשתית בהן התועלת היא עקיפה, קשה לתת נוסחא מתמטית מדויקת ובמקרים רבים תתואר התועלת במלל חופשי ובשפת בני אדם. בהקשר זה חשוב לשנן את כללי האצבע הבאים:
· במקרים רבים ניתן להציג את התועלת במונחים יחסיים (לעומת המצב הקיים), בפרט במקרים של החלפה של אחד לאחד. למשל, המערכת החדשה תספק את כל השירותים של המערכת הקיימת בחצי מההוצאה הקיימת. תועלת יחסית היא קלה יותר הן בהגדרתה והן במדידתה (באימות שאכן הושגו התועלות שנצפו), בתנאי שיש מדידות כלשהן במצב הקיים.
· המבחן המרכזי איננו נוסחה מתמטית מול מלל חופשי אלא יכולת המדידה גם אם היא גסה. גם אם התועלות מנוסחות במלל חופשי או, טוב יותר, בטבלה פשוטה, ולא בנוסחה ברורה, אבל ניתן לאמתן בבוא העת מול המצב הקיים.
לסיכום: יש להציג את יחידות השירות שהמערכת מספקת, באופן מוחלט או יחסי. דוגמא:
· העלאת מס' כניסות וניפוקים ל/מ מחסן מ- 100 ליום כיום, ל- 150 תייעל את עבודת המחסנאים ותאפשר להוריד את כמות המלאי השוטף ב- 25%.
· הנפקת תעודת עובד מגנטית תתרום לא רק לרווחת העובד אלא תאפשר החלפת מערכת איסוף ש"ע במערכת חדשה וזולה יותר, תאפשר פריסה של תחנות איסוף נוספות בעלות הנוכחית, תקצר תורים ותקטין את הצורך בבקרת איכות הנתונים ותיקונים ידניים.
בדיקת איכות (טיב) כללית נעשית ע"י עימות רכיבים 1-2 בעץ המערכת מול רכיבים 3-5. ברכיבים 1-2 מוגדרת מהות המערכת ויעדיה ואילו רכיבים 3-5 מגדירים את הטכנולוגיה בעזרתה תיבנה המערכת, את צורת המימוש ואת העלויות הצפויות.
בבדיקות טיב ואיכות המתוארות בסעיף זה ובשני הסעיפים הבאים, מוזכר לעתים קרובות המונח "עימות", היינו הצגה של שני רכיבים (או קבוצת רכיבים) והערכת משמעות פתרון X המכיל את שניהם. אין נוסחאות מדויקות ל"עימותים" כאלה. זו האמנות של איכות ועלות/תועלת. ההנחה היא שעצם הצגה ברורה של רכיב מול רכיב, כאשר לגבי כל רכיב לחוד יש מידע פחות או יותר ברור, תסייע בקבלת החלטה נכונה ובהפיכת האמנות לאומנות אם לא למדע מדויק.
את תוצאות בדיקת הטיב הכללית אפשר להעריך בעזרת הטבלה הבאה:
רכיב ראשי |
יעדי המערכת (רכיב 1) והיישום (רכיב 2) |
||
בעץ המערכת |
רמת ההגדרה |
מוגדרים היטב |
אינם ברורים |
טכנולוגית המערכת מימוש המערכת (רכיב 4) עלות המערכת (רכיב 5) |
מוגדרים ומוכרים |
ניתן לצפות למערכת בעלת ישימות טובה ואיכות גבוהה |
מה בכלל רוצים? האם ברור מי הלקוח? ישימות - בסכנה. |
אינם ברורים |
בדיקת טיב (איכות) מפורטת, נעשית לפי עץ המערכת:
· איכות הטכנולוגיה, לפי ארבעת מדדי האיכות
· איכות היישום, לפי ארבעת מדדי האיכות
· איכות המימוש, לפי ארבעת מדדי האיכות
· עימות והצלבות: איכות הטכנולוגיה והמימוש ביחס ליישום.
בדיקות מפורטות אלה נעשות באופן טבעי במהלך הפרויקט במסגרת שיקופיםreviews - ואבטחת איכותQA - . ראה קיטים בשמות אלה בנושאים התומכים.
בדיקת איכות וישימות כוללת היא סיכום העלות מול תועלת הפרויקט. המושג עלות/תועלת מובן היטב באופן אינטואיטיבי, אך הגדרתו, מדידתו וכימותו הן סבוכות למדי.
להלן מספר דרכים (שיטות) אפשריות, חלקן תיאורטיות-מה וחלקן (קצת) יותר מעשיות:
· הפרדת רכיבים
· עימות רכיבים
· שיטת המפ"ל
בדומה למדדים אחרים (ראה הקיט מדדים - Metrics בכרך איכות/כלים וטכניקות), גם במדד עלות/תועלת, השיטות המוצעות טובות יותר לעריכת בדיקה השוואתית מאשר להערכה אבסולוטית. במילים אחרות, השיטה לא תיתן מדד (מספר סטטיסטי) ברור, אך תוכל להראות שהעלות/תועלת של מערכת X עדיפה או נחותה מול זו של מערכת Y.
עלות/תועלת הוא מדד מסכם (אולי המדד המסכם מספר אחד) המוצג, בד"כ בפני דרג ניהולי בכיר שצריך לקבל החלטות מרכזיות באשר להמשך הפרויקט. אין צורך וגם אין זה נבון להציג בפני דרג זה מדד סטטיסטי אחד מסכם וללוותו בהסברים ומונחים טכניים מפורטים. הדרך הנבונה היא ראשית להפריד בין התועלת לעלות ולהציג כל אחד מהם לחוד.
· תועלות - במונחים שהמנהלים מכירים ובשפת הארגון, לפי אחת מהשיטות שלהלן.
· עלות - במספרים ברורים לפי החלוקה של רכיב 5 ולפי הטבלאות שבנספח 5.5: ריכוז עלויות.
העמדת התועלות מול העלויות (קרי, היחס ביניהם), היא כבר מורכבת יותר ומתוארת בהמשך. הסיכום הגרפי, בשיטת דלפי גם הוא מתואר בהמשך.
בעקרון, עלות/תועלת היא עימות של רכיב היעדים (בפרט לאחר שהוגדרו המטרות ברכיב 1.2 והתועלות בתת-רכיב 1.6.1 לעיל) עם רכיב העלות - כל השאר, יישום, טכנולוגיה ומימוש הוא קופסא שחורה. ההנחה היא שהיישום, הטכנולוגיה והמימוש מיישמים את היעדים נאמנה ואם כך, אז בצד התועלת יש רק יעדים ומטרות. בדרך זו מוצגים יעדי המערכת ישירות מול העלות, אם באופן כולל ("הנה כל המטרות שיושמו והנה כמה שזה עלה"), או, אם אפשר, באופן פרטני יותר ("מטרה זו עלתה X, מטרה זו Y וכו').
דרך אחרת היא מדידה ישירה של עלות יחידות השירות. דרך זו טובה בעיקר במערכות עובדות המכילות תת-מערכת פנימית לחשבונאות (accounting), אשר מודדת הן את הטרנזקציות המתבצעות והן את משאבי המחשב (כולל שימוש בתוכנות, ברשת התקשורת וכו'). מידע גולמי זה מעובד בהמשך ע"י מערכת תמחיר, אשר מגלמת הוצאות נוספות (חיצוניות) ומחשבת "עלות לטרנזקציה". ההשוואה הסופית היא: כמה עולה יחידת שירות מסוימת בפתרון (חלופה) א' וכמה בפתרון (חלופה) ב'. צריך כמובן למצוא דרך לשקלל את יחידות השירות השונות ולהציג סל של יחידות שירות ולהשוות את עלות הסל בפתרון (חלופה) א' מול עלותו בפתרון (חלופה) ב'.
דרך נוספת היא זו המקובלת בבדיקת הצעות ספקים. בדרך זו העימות הוא בין יישום-טכנולוגיה-ומימוש כמייצגים את התועלת מול העלות. בדיקה זו מפורטת בקיט בקשה להצעות - RFP (ראה מפ"ל - מסמכים פנימיים לבדיקה שם). דרך זו מדגישה שוב שמדידת עלות/תועלת היא יחסית ולא ערך אבסולוטי. הצוות המקצועי צריך לתת ציון לפתרון שהוא מציע.
להלן מוצגים סיכום חישובי עלות/תועלת למספר חלופות כפי שמפת"ח ממליץ עליהם.
· ישנן שלוש חלופות לבחינה
· יחס עלות/תועלת נקבע ל- 70% / 30%
1. ציר העלות (ציר Y צד שמאל) ייבנה באופן הבא: החלופה הזולה ביותר תקבל ערך של 100%. שאר החלופות יקבלו ערך לפי הנוסחא הבאה: ערך החלופה הזולה לחלק בערך חלופה X כפול 100.
החלופה היקרה ביותר איננה 0. ככל שההפרש בין החלופה הזולה לחלופה היקרה גדול יותר, שואף הניקוד של החלופה היקרה ל- 0.
2. ציר התועלת (ציר Y צד ימין) ייבנה באופן הבא: התועלות של החלופות, יהיו הציון שהם קבלו על בסיס 100.
3. הציר האופקי – ציר ה- X: הציר האופקי (ציר X) חולק לעשר נקודות עלות תועלת. ככל שהנקודה קרובה יותר לציר העלות, היחס עלות/תועלת נוטה יותר לצד העלות (הנקודה בה ציר ה-X מתלכד עם ציר העלות, פירושה שהשיקול היחיד הוא עלות: 0% לתועלת ו- 100% לעלות). ככל שהנקודה קרובה יותר לציר התועלת, היחס עלות/תועלת נוטה יותר לצד התועלת (הנקודה בה ציר הX- מתלכד עם ציר התועלת, פירושה שהשיקול היחיד הוא תועלת: 0% לעלות ו- 100% לתועלת).
השימוש בתרשים בעת סיכום הבדיקה, הוא לפי הצעדים הבאים:
· התווית הנקודות על ציר העלות כמוסבר לעיל.
· התווית הנקודות על ציר התועלת כמוסבר לעיל.
· חיבור נקודות העלות והתועלת לכל חלופה
· בחירת החלופה הטובה ביותר (יחס עלות/תועלת מיטבי): יש להעלות אנך מנקודת העלות/תועלת שנקבעה על הציר האופקי. אנך זה חותך את כל קווי החלופות שהותוו בפעולה 3. החלופה שנחתכת הכי גבוה היא החלופה הנבחרת.
מקרי קצה: חלופה שקו העלות/תועלת שלה נמוך לכל אורכו מחלופה אחרת (כלשהיא) - נופלת. חלופה שקו העלות/תועלת שלה גבוה מכל שאר החלופות לכל אורכו - נבחרת (בלי קשר לנקודת היחס עלות/תועלת, היינו, בלי צורך להעלות אנך).
התוצרים בקיט זה מרוכזים בחוברת MS-Ecxel וכוללים את הגליונות הבאים:
· חישוב עלויות פיתוח הפרויקט במשך חמש שנים
· חישוב עלויות תחזוקה במשך חמש שנים
· חישוב תועלות הפרויקט במשך חמש שנים
· פריסת העלויות והתועלות על פני התקופה והצגת ההחזר המצטבר בהתחשב במקדמי אי-ודאות לעלויות ותועלות
· גיליון סיכום לפרויקט שמאפשר חישוב עדכני של ההחזר המצטבר וחישוב אחוז הסטיה מהתכנון המקורי
הגליון מציג את עלות ההקמה (פיתוח) ועלות התחזוקה של הפרויקט, בסה"כ ובפריסה לאורך אופק הזמן. מדובר במונחים סופיים של הוצאה כספית. ברור שעל מנת להגיע לערכים כספיים יש לאמוד תחילה את המשאבים הדרושים להקמת המערכת:
· ח"א של המפתחים והמשתמשים
· עלויות חומרה ותוכנות נרכשות
· היקף הדרכות והטמעות
· היקף התיעוד
יש להפוך אומדן זה למונחים כספיים. ראה קיט אמידת עלויות בכרך זה.
הטופס מחולק לשני חלקים:
· הערכת עלויות הפיתוח
· הערכת עלויות התחזוקה
נקראת גם עלות הקמה - מתמקדת במשאבים הדרושים להבאת מהדורה ראשונה של המערכת לכלל תפעול שוטף ושירות למשתמשי הקצה. עלות זו נחלקת לשלוש קבוצות:
· תשומות כ"א: בחלוקה לפי מחזור החיים של המערכת. יש להקפיד לכלול בקבוצה זו את כל כוח האדם המעורב בפרויקט, שעות עבודה מקצועיות ושעות ניהול
· טכנולוגיה ותשתית: בחלוקה לפי חומרה, ציוד היקפי, תוכנות בסיסיות, כלים למשתמש קצה וכו'.
· הוצאות נוספות: בקבוצה זו ניתן לכלול כל הוצאה נוספת שלא נכללה בקבוצות הקודמות לרבות תשומות כ"א של או"ש, משתמש, אבטחת איכות וכו'.
נקראת גם עלות שוטפת. מתמקדת במשאבים הדרושים לתפעול (ייצור) ותחזוקה שוטפים של המערכת על פני אותו אופק הזמן של עלות הפיתוח. עלות זו כוללת לא רק תיקוני שגיאות ותיקונים הכרחיים (Force Majeure), אלא גם שינויים ושיפורים וגרסאות חדשות. עלות זו נחלקת לארבע קבוצות:
· תשומות כ"א
· טכנולוגיה ותשתית
· הוצאות ייצור
· הוצאות נוספות: בקבוצה זו ניתן לכלול כל הוצאה נוספת שלא נכללה בקבוצות הקודמות.
שורות הסיכום "סה"כ פיתוח" ו- "סה"כ תחזוקה", הן העלות הנומינלית של הפרויקט, ומועברות לטופס המסכם של הערכת עלות/תועלת (ראה להלן). עיקר ההקפדה צריך להיות על נכונות המספרים בשורות מסכמות אלו ועל החלוקה הפנימית שלהן לקבוצות המשנה
על מנת לתת יתר תוקף ואמינות לנתוני העלות/תועלת של הפרויקט, יש להעריך את מקדם אי-הוודאות של עלויות הפרויקט – מה הסבירות שעלויות הפרויקט יישארו כמפורט באומדן הראשוני?
מקדם אי הוודאות הוא מספר הנע בין 1 ל- 0.34, כאשר 1 פירושו ביטחון מלא באומדני העלות, 0.9 פירושו ביטחון גבוה (90%), 0.8 - ביטחון טוב (80%) וכו'. את הערכת העלות הנומינלית מחלקים במקדם הוודאות ומקבלים את הערכת העלות המתוקנת. מקדם ודאות של 0.5, למשל, משמעותו שהעלות המתוקנת גבוהה פי שניים מהעלות הנומינלית. (למקדם ודאות 0 אין משמעות, הערך המעשי נמוך ביותר הוא 0.34 שפירושו פי 3!).
את הערכת מקדם הוודאות לעלות יש לבצע בעזרת טופס הערכת מקדם אי-וודאות המצוי בקיט אמידת עלויות בלשונית תוצרים.
הטופס בנוי בצורה של שאלון המכיל שאלות או גורמים העשויים להשפיע על רמת הוודאות של הערכת העלות. לרוב השאלות יש גם תת שאלות (גורמי משנה) שמטרתן לסייע במתן תשובה לשאלה הראשית. בתשובה לכל שאלה ראשית יש לתת, בטור "אי ודאות" ערך מספרי הנע בין 0 ל- 5, כאשר:
מקדם וודאות |
רמת הוודאות |
רמת אי-הוודאות |
ביאור |
0 |
גמורה |
- |
לא צפויות בעיות בתחום זה ואין לגורם זה השפעה על הערכת העלות המקורית, או שההערכה המקורית כבר לקחה גורם זה בחשבון |
1 |
גבוהה |
נמוכה מאד |
צפויות בעיות קלות בתחום זה שעשויה להיות להן השפעת מה על הערכת העלות המקורית |
2 |
טובה |
נמוכה |
צפויות בעיות מסוימות בתחום זה שעשויה להיות להן השפעה על הערכת העלות המקורית |
3 |
בינונית |
בינונית |
צפויות בעיות בתחום זה שעשויות לגרום לשינוי בהערכת העלות המקורית |
4 |
נמוכה |
גבוהה |
צפויות בעיות בתחום זה שתהיינה להן השפעות משמעותיות על הערכת העלות המקורית. השפעה זו לא נלקחה בחשבון בעת הערכת העלות הנומינלית |
5 |
נמוכה ביותר |
גבוהה מאד |
צפויות בעיות רציניות בתחום זה. לגורם זה עלולה להיות השפעה משמעותית ביותר על הערכת העלות המקורית. השפעה זו לא נלקחה בחשבון בעת הערכת העלות הנומינלית |
הטור "מקדם ודאות" לוקח את הערך המספרי שניתן בטור הקודם ("אי ודאות") מחלק אותו ב- 100 (הערך 2 הופך ל- 0.02, 5 הופך ל- 0.05 וכו') ומחסיר אותו מ- 100. (2 הופך בסופו של דבר ל- 0.98, 5 ל- 0.95 וכו'). טור זה מחושב אוטומטית ע"י נוסחה המצויה בטבלה
הטור "תוצאה מצטברת" הוא הכפלה מצטברת של הערכים שבטור הקודם ("מקדם ודאות") ומציג את מקדם הודאות המצטבר.
שורת הסיכום "סה"כ מקדם ודאות" מכילה ערך אחד בלבד, בטור "תוצאה מצטברת". יש לשים לב שערך זה לא יכול להיות קטן מ- 0.34 שפירושו של דבר שהסטייה המכסימלית שמקדם הודאות של העלות יכול לגרום היא סטייה של פי שלושה. פרויקט שעלותו הנומינלית היא 100 יהפוך, אחרי חילוק ב- 0.34 לעלות מתוקנת של 294.
כימות התועלות של הפרויקט היא פעילות לא פשוטה לביצוע ורצוי להסתייע בכך בגורמים נוספים בארגון כגון גורמי שיווק לגבי תועלות שיווקיות, גורמי יח"צ לגבי שיפור תדמית, גורמי או"ש לגבי התייעלות וכד'.
תועלות הפרויקט מחולקות בטופס למספר תת-נושאים:
· חסכונות (כ"א, הוצאות, ...)
· הגדלת הכנסות
· מניעת סיכון / הפסד
· תועלות אחרות
יש לתת הערכה במונחים סופיים של הוצאה כספית בסה"כ ובפריסה לאורך אופק הזמן.
בסוף הטבלה, יש לתת הערכה למקדם אי-הוודאות לעמידה בהערכת התועלות. מקדם זה נע בין 0 – האומדן לא צפוי להשתנות עד ל- 0.35 – אמידת התועלות תשתנה עד פי 3 מההערכה המקורית.
לטבלה זו מועברות שורות הסיכום מטבלאות חישוב העלויות וחישוב התועלות לעיל תוך שמירה על רמת הפריסה לאורך אופק הזמן.
· ריכוז תועלות הפרויקט מוכפלות במקדם אי הוודאות
· עלויות הפיתוח והתחזוקה של הפרויקט מוכפלות במקדם כנ"ל
· חישוב החזר מצטבר בפריסה רב שנתית (תועלות פחות עלויות)
סעיף זה מכיל מידע בהיבט שלא הופיע בטפסים הקודמים. מטרתו להציג נתוני ביצוע של הפרויקט באמצעות השוואת התכנון העדכני מול התכנון המקורי. מידע זה עומד לרשות הגורמים הניהוליים בשיקוליהם הכלליים.
אבטחת האיכות לתהליך חישוב עלות/תועלת לפרויקט תבחן את הנקודות הבאות:
· ביצוע החישובים בנקודות מחזור החיים הנ"ל (כמינימום).
· מידת הפירוט של הטבלאות: האם החישובים מבוססים על "הערכות אצבע" או "אמידה לפי מיטב שיפוט" או על אמידה פרטנית ע"פ שיטה מוגדרת ומסודרת?
· הקשר בין אמידת עלויות וחישוב עלויות: מה קדם למה? מה מתבסס על מה?
· מידת הכיסוי של רכיבי עץ המערכת. על מה הושם הדגש?
· 1.2 יעדים ומטרות
· 5.1 עלות הקמה
· 5.2 עלות שוטפת (תחזוקה)
· פיתוח יחידות מסירה נוספות (5.1 & 5.2)
· 5.5 עלות כוללת (עם פריסה או בלי)
· לפי מה נבחרו סעיפי העלות והתועלת:
· רכיבי עץ המערכת?
· שלבי מחזור החיים?
· אחר?
· האם שונו הטורים של התשומות?
· מידת מעורבות כלכלנים ואנשי תקציב לצד מומחי מחשוב וגורמים נוספים בארגון (או"ש, שיווק, הנדסת ייצור וכד'). מי הוביל את חישוב העלויות והתועלות?
במקרים רבים אבטחת איכות משתתפת באופן פעיל בחישוב ואמידת העלויות והתועלות ועליה "לבדוק את עצמה".