מאת: ד"ר דניאל גלין, ניתוב מערכות *

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

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

 

 

א. מבוא

 

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

א. עלויות בקרה (costs of control) הנחלקות ל עלויות מניעה (prevention costs) ולעלויות הערכה (appraisal costs).

ב. עלויות כשל (costs of failure of control) הנחלקות לעלויות כשל פנימי (internal failure costs) ולעלויות כשל חיצוני (external failure costs).

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

 

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

 

 

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

 

מבין הפרסומים בתחום זה בישראל, חשובים במיוחד הם כאלה המביאים נתונים כמותיים על עלויות איכות בפועל, המאפשרים בחלקם לבחון באופן ראשוני את מודל עלויות האיכות הקלאסי. עבודת תשתית חשובה במיוחד היא מחקר "עלויות האי-איכות בישראל" (נוה איתן והלוי אבנר, 1996), המציג לראשונה תמונה מקיפה על עלויות האיכות ומרכיביהן בענפי המשק השונים בישראל.  כך לדוגמא נמצא במחקר זה, כי בענף המתכת, חשמל ואלקטרוניקה, המקדיש 4.6% מהמכירות למניעת כשלים, עלות נזקי הכשלים היא 3.2% מהמכירות בלבד.  לעומת זאת, בענף הטקסטיל, הלבשה ועור, המקדיש רק 1.6% מהמכירות למניעת כשלי איכות, היקף הנזקים הנגרמים עקב כשלי איכות מגיע ל15.1% מהמכירות. נתונים על התפתחות מערכת האיכות של חברת "אלביט", בשנים 1979-1991 (לוז, 1992), מראים כי גידול חלקן של ההוצאות למניעה מכלול עלויות האיכות מ – 8% ב – 1979 ל – 31% ב -1991, היה מלווה בירידה משמעותית ביותר של % עלויות האיכות מערך המכירות, מ – 15.4% בשנת 1979 ועד ל – 5.5% בלבד בשנת 1991. הישגי מערכת האיכות והניהול בחברת "אל-אופ" באמצעות נתוני עלויות איכות, כפי שנמדדו בחברה בתקופה שבין 1987-1996 מוצגים ע"י יצחק שפס (1998).  החברה הצליחה להוריד את עלויות האיכות מ – 20% מהמכירות ב -1987- ל – 4.9% מהמכירות ב – 1996.

 

מאמר זה עוסק בעלויות איכות בפיתוח תוכנה, כשהכוונה היא לתוכנה למערכות מידע ניהוליות (MIS), ולא לקושחה

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

 

 

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

 

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

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

 

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

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

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

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

 

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

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

 

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

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

 

 

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

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

 

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

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

 

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

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

 

 

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

 

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

 

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

המקורות העיקריים והאמינים ביותר לגבי עלויות האיכות הם:

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

 

קשיים אופייניים בביצוע רישומים אלה של עלויות איכות הם:

1. קשיים בהשגת המשאבים הנדרשים (כוח אדם, משאבי מיחשוב) לתפעול השוטף של בקרת הרישומים.
2. קשיים הנובעים מגורמי אנוש, ובמיוחד התנגדות עובדים לכל רישום המצביע על ביצועיהם.
3. קשיים של אמינות הנתונים, הנובעים מדיווח חלקי או אף מוטה.
4. קשיים אלה מתבלטים במיוחד לגבי נתוני עלויות כשל פנימי וחיצוני. בנושאים אלה נטייתם של מרבית האנשים לפעול להקטנת עלויות הכשל הרשומות, וזאת ע"י:
5. אי רישום או רישום חלקי של שעות עבודה המושקעות בתיקונים לאחר כשל פנימי או חיצוני.
6. תשלום פיצוי ללקוח או החזר כספים ללקוח בצורה שלא תירשם בספרי החברה כעלות כשל חיצוני, וזאת ע"י פיצוי הלקוח בצורה שאיננה ישירה, ע"י הנחות ברכישת שירותים אחרים, מסירת מוצרים ללא תשלום וכד'.

 

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

 

קשיים באיסוף נתונים של עלויות היערכות ובקרה ניהולית:

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

קשיים באיסוף נתונים על עלויות כשל ניהולי:

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

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

 

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

 

 

ד. סיכום

 

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

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

 

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

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

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

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

ביבליוגרפיה

 

• לוז אבי (1992)  "כלכלת האיכות באלביט", ספר המאמרים של הכינוס ה9- של האיגוד הישראלי לאיכות, עמ' 124 – 127.

 

• נוה איתן והלוי אבנר (1996) "עלות האי-איכות בישראל", המרכז לאיכות ומצויינות, משרד ראש הממשלה, 69 עמ'.

 

• שפס יצחק (1998) "TQM הלכה למעשה – 10 שנות יישום", איכות, חוברת 17, עמ' 10 –

 

• Crosby P. B. (1992) “Quality is Free”, McGraw-Hill, New-York.

 

• Feigenbaum A. V. (1991) “Total Quality Control”, 3^rd Edition, revised, McGraw-Hill, New-York.
• ISO (1997) “International Standard ISO 9000-3: Guidelines for  the Application of ISO 9001:1994 to the Development, Supply, Installation and Maintenance of Computer Software”, International Organization for Standardization, Geneve, Switzerland.

 

 

 

 

tweet[Google] Follow @leadersnet

 

 

מנהיגים ברשת

www.leadersnet.co.il

leaders@leadersnet.co.il

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