ניהול תצורה מערכתי - DSD - דטה סיסטמס דיזיינרס 1989 בע"מ

‫ניהול תצורה מערכתי – סיסמא או מקצוע?‬
‫ישראל גת‬
‫די‪.‬אס‪.‬די‪ .‬דטה סיסטמס דיזיינרס ‪ 1989‬בע"מ‬
‫רח' וייצמ ‪ 54‬כפר סבא ‪44247‬‬
‫טל‪ ,09-7413294 .‬פקס‪israel@dsd.co.il ,09-7602829 :‬‬
‫תקציר‬
‫ניהול תצורה מסורתי‪ ,‬כולל פעילויות של הקצאת מזהי' לישויות הנדסיות‪ ,‬שחרור מידע הנדסי וניהול שינויי'‬
‫הנדסיי'‪ .‬פעילויות אלו‪ ,‬מתאימות לארגוני' ע' מוצרי' שתכנונ' נעשה באופ בלעדי ע"י אותו ארגו‪ .‬בארגוני' בעלי‬
‫אופי מערכתי‪ ,‬המשלבי' מוצרי פיתוח מחברות שונות – קבלני משנה או שותפי' עיסקיי'‪ ,‬כמו בחברות המנהלות‬
‫פרויקטי' גדולי'‪ ,‬פעילויות ניהול תצורה מקבלות היבטי' נוספי'‪ ,‬מערכתיי' בגלל הצור( לתא' את תהליכי ניהול‬
‫התצורה ואת המידע של המוצר בי ארגוני' שוני' העובדי' בשיטות שונות וע' מערכות מידע שונות‪.‬‬
‫ניהול התצורה בארגוני' מסוג "בית מערכות" או קבלני' ראשיי' ייצר מקצוע חדש – מנהל תצורה מערכתי ) שההבדל‬
‫בינו לבי עובד ניהול תצורה "קלאסי" דומה להבדל שבי מהנדס מערכת למהנדס פיתוח "קלאסי"‪.‬‬
‫המאמר מגדיר את תפקיד פונקצית ניהול התצורה המערכתית‪ ,‬ומשווה בינה לבי פונקציית ניהול התצורה הקלאסית‪.‬‬
‫דוגמא של יישו' פונקציית ניהול התצורה המערכתית בפרויקט גדול מאד מוצגת א* היא‪.‬‬
‫רקע‬
‫יישו' תהליכי ניהול תצורה ומערכות מידע תומכות )‪ (PLM - Product Life-cycle Management‬בארגוני'‪ ,‬הוא‬
‫דבר שכיח‪ .‬אול'‪ ,‬יישו' זה כיו' מוגבל בדר"כ ליישו' שיטה הומגנית בארגו אחד‪ ,‬ובמוצרי' יחסית פשוטי'‬
‫המתוכנני' ברוב' ע"י אותו הארגו‪.‬‬
‫הגלובליזציה בשוק‪ ,‬הפיכת המוצרי' למורכבי' יותר ויותר‪ ,‬הגדלת התחרותיות‪ ,‬התמקצעות חברות ב) ‪Core‬‬
‫‪ Business‬שלה'‪ ,‬מיזוגי' ורכישת חברות ה חלק מהסיבות המחייבות שיתו* פעולה ומידע בי חברות וארגוני'‬
‫שוני' – שותפי' עסקיי'‪ ,‬חברות)בת וקבלני משנה‪ .‬חברות וארגוני' אלו ממוקמי' באזורי' גיאוגרפיי' שוני' ובעלי‬
‫תרבות ארגונית שונה‪ ,‬אול' עדיי‪ ,‬חייבות לפעול באופ מתוא' על מנת שהמוצר המשות* ממאמצי כול' יעמוד‬
‫בדרישות‪ ,‬ימכר במחיר תחרותי ויהיה בר)תחזוקה‪.‬‬
‫מצב זה מחייב מת פתרונות ניהול תצורה מעבר לגבולות של ארגו בודד‪ .‬שיטת ניהול התצורה צריכה להתמודד בחת(‬
‫של מוצר )או פרויקט( – המפותח ומיוצר בארגוני' שוני' – חלק' באותו קונצר וחלק' בחברות בבעלויות שונות‪,‬‬
‫הנמצאות לעיתי' בתחרות בשווקי' אחרי'‪.‬‬
‫‪ .1‬ניהול התצורה ה"קלאסי"‬
‫ניהול התצורה ה"קלאסי" כשיטה סדורה‪ ,‬התפתח בתחילה בארה"ב בשנות החמישי' של המאה העשרי' לאור‬
‫הסיבוכיות שנדרשה בתוכניות החלל האמריקאיות‪ ,‬והתבטאה בסדרה של סטנדרטי' צבאיי'‪ ,‬שהאחרו בה' )לפני‬
‫שבוטל( היה ]‪ .[1‬דרישות נוספות לניהול תצורה הופיעו בתקני' של ארגוני' תעשייתיי' שוני' כמו איגוד תעשיות‬
‫האלקטרוניקה‪ ,‬ותקני איכות אירופאיי' או של נאטו )‪ .(STANAG ,AQAP‬תקני איכות של ‪ [3] ,[2] ISO‬ושל ‪[4] SAE‬‬
‫התכנסו בסופו של דבר לסטנדרט ”‪ [5] "Consensus‬המקובל כיו' כתק המוביל ג' בתעשייה הבטחונית וג'‬
‫בתעשיות האזרחיות‪.‬‬
‫סטנדרט זה‪ ,‬מציג את התחומי' הבאי' המרכיבי' את תהליכי ניהול התצורה‪:‬‬
‫‬
‫‬
‫‬
‫‬
‫‬
‫תכנו וניהול‬
‫זיהוי תצורה‬
‫ניהול שינויי תצורה‬
‫סטטוס תצורה‬
‫מבדקי' ואימות תצורה‬
‫כשנבח את התהליכי' והדרישות הקשורות לתחומי' אלו ה בסטנדרט וה בחברות המיישמות ניהול תצורה‪ ,‬נראה‬
‫שקונטקסט היישו' הוא "בתו( החברה" והוא מוגבל לנתח המוצר המתוכנ והמיוצר ע"י החברה‪.‬‬
‫טבלה ‪ 1‬מציגה פעילויות ניהול תצורה קלאסיות המבוצעות כיו' בארגוני'‪:‬‬
‫ספרור‬
‫‪1‬‬
‫תחו' פעילות‬
‫תכנו וניהול‬
‫‪2‬‬
‫זיהוי תצורה‬
‫‪3‬‬
‫‪4‬‬
‫ניהול שינויי תצורה‬
‫סטטוס תצורה‬
‫‪5‬‬
‫מבדקי' ואימות תצורה‬
‫תהליכי' מבוצעי'‬
‫ כתיבת נהלי עבודה פנימיי'‬
‫ הכנת תוכנית ניהול תצורה )‪ (CMP‬לפרויקטי' )בחברות‬
‫פרויקטליות(‬
‫ תקנו עלויות ניהול תצורה )בארגוני' בה' ניהול תצורה אינו‬
‫נחשב כ"תקורה"(‬
‫ ניהול שוט* של צוות ניהול תצורה‬
‫ הקצאת מזהי' לפריטי'‪ ,‬מסמכי'‪ ,‬שינויי'‪... ,‬‬
‫ שחרור מסמכי' ושרטוטי' הנדסיי' לארכיו )‪ PLM‬או אחר(‬
‫ בניית ותחזוקת עצי מוצר‬
‫ הקפאות תצורה )ברמת הפריטי' המתוכנני' בחברה(‬
‫ טיפול בהצעות שינוי תצורה‬
‫ יישו' מערכת ‪) PLM‬או יישו' מקומי(‬
‫ יישו' אלמנטי' של ניהול תצורה במערכות ‪ERP‬‬
‫ ביצוע מבדקי' פונקציונליי' )‪(... ,FAI ,ATP‬‬
‫ ביצוע מבדקי' פיזיי' )‪(... ,As-built vs. As-planned‬‬
‫טבלה ‪ – 1‬פעילויות ניהול תצורה "קלאסיות"‬
‫אופ עבודה זה‪ ,‬ישי' ויעיל לחברות וארגוני' המתכנני' את חלקו העיקרי של המוצר )או הפרויקט(‪ ,‬כאשר פריטי'‬
‫שאינ' מתכנו החברה ה' בעיקר פריטי' מסוג מוצר מד* )פריטי ‪.(COTS‬‬
‫‪ .2‬צרכי ניהול תצורה בחברות מסוג "שילוב מערכות"‬
‫בארגו המשלב תתי מערכות המפותחות ע"י שותפי' עיסקיי'‪ ,‬חברות בת וקבלני משנה – המתודולוגיה הקלאסית‬
‫אינה עונה על הנדרש‪ .‬בארגוני' אלו‪ ,‬אחוז הפיתוח העצמי של החברה )ואיתו מידע התצורה המתוכנ ע"י החברה( יכול‬
‫לרדת ל) ‪ ,30% ) 20%‬והמשמעות היא שלחברה אי ידע לגבי התצורה של למעלה מ) ‪ 70%‬מהמוצר‪.‬‬
‫להמחשה‪ ,‬ציור ‪ 2‬מציג ע‪ 2‬מוצר של חברה שרוב המוצר מתוכנ בחברה )חברה ‪ A‬באיור א'( מול ע‪ 2‬מוצר של חברה שרוב‬
‫המוצר מתוכנ ע"י חברות אחרות )חברה ‪ B‬באיור א'(‪:‬‬
‫חברה ‪A‬‬
‫חברה ‪B‬‬
‫מקרא‪:‬‬
‫קבלני משנה‪ ,‬שותפים עסקיים‬
‫החברה בעלת המוצר‪/‬קבלן ראשי לפיתוח‬
‫איור א' – מבנה מוצר לחברה עם תכנון עצמי גבוה )חברה ‪ (A‬מול מבנה‬
‫מוצר של חברה עם תכנון גבוה באמצעות קבלני משנה )חברה ‪(B‬‬
‫במצב הקלאסי המתואר באיור א'‪ ,‬מידע התצורה של חברה ‪ B‬יראה במערכת ניהול התצורה שלה )בהנחה של פעילות‬
‫ניהול תצורה "קלאסית"( כמתואר באיור ב' )ההנחה שפריט אב של הרכבה של קבל משנה‪ ,‬מופיע בכל מקרה במערכת‬
‫המידע של קבל ראשי אול' ללא פירוט לרמות נמוכות יותר(‬
‫חברה ‪B‬‬
‫איור ב' – מבנה מוצר של חברה ‪ B‬במערכת מידע ניהול תצורה של החברה‬
‫)קווים מרוסקים מציינים פריטים "יתומים"(‬
‫כפי שהמחשנו באיור ב' – חברה מסוג "שילוב מערכות" אינה מנהלת את התצורה של רוב המערכת‪ ,‬ותלויה באופ בלעדי‬
‫ו"עיור" ביכולות ובאופ יישו' ניהול התצורה של קבלני משנה‪/‬שותפי' עסקיי'‪ .‬היכולות העיקריות הנפגעות קשורות‬
‫לנושאי' הבאי'‪:‬‬
‫הנדסת המערכת – מאחר ורב חלקי המערכת אינ' ידועי' – יכולת הניתוח של הפעולה המערכתית אינה מליאה‪ ,‬עובדה‬
‫היכולה לפגוע בתכ הכולל של המערכת‪ ,‬במיוחד במערכות מורכבות‪ .‬בנוס* קיימת תלות גבוהה מאוד באיכות של‬
‫יכולות הנדסת מערכת של קבלני המשנה במקרי' בה' המוצרי' שלה' מתממשקי' לחברות צד ג' שונות )שזה המצב‬
‫השכיח(‪.‬‬
‫אבטחת איכות – נותנת אישור תקינות למערכת ולפריטי' המורכבי' בה ללא ידיעה מה באמת המערכת כוללת‬
‫שירות לקוח – נתקל בשתי בעיות עיקריות – האחת – חוסר יכולת לתכנ מדיניות תחזוקה לכל פריטי המערכת )מאחר‬
‫ואינ' מוכרי' לחברת שילוב המערכות(‪ ,‬והשנייה – בעיות במימוש חוזה אחזקה‪ ,‬כאשר מגיעי' פריטי' תקולי'‬
‫מהלקוחות‪ ,‬ופריטי' אלו אינ' מוכרי' ע"י מערכת המידע של החברה המשלבת‪.‬‬
‫הבעיה מחריפה יותר בחברות שעיסוק העיקרי הוא ביצוע פרויקטי' )‪ ,(Design to Order‬מאחר ורב הלקוחות‬
‫הגדולי' דורשי' שקיפות לתהליכי הפיתוח‪ ,‬התכ וההוכחה של כלל מרכיבי המערכת ושקיפות זו אינה קיימת בחברה‬
‫המשלבת‪.‬‬
‫‪ .3‬ניהול תצורה מערכתי‬
‫כדי לענות על דרישות ניהול התצורה של חברות מערכתיות או קבלני' ראשיי' בחברות המפתחות מערכות ע' מרכיבי‬
‫קבלנות משנה גבוהי'‪ ,‬יש לבחו את צרכי ניהול התצורה בהתא' לחלוקה הראשית של ]‪ .[5‬פעילויות אלו מוצגות‬
‫בטבלה ‪ 2‬להל‪:‬‬
‫ספרור‬
‫‪1‬‬
‫תחו' פעילות‬
‫תכנו וניהול‬
‫‪2‬‬
‫זיהוי תצורה‬
‫‪3‬‬
‫ניהול שינויי תצורה‬
‫‪4‬‬
‫סטטוס תצורה‬
‫‪5‬‬
‫מבדקי' ואימות תצורה‬
‫תהליכי' מבוצעי'‬
‫ הכנת תוכנית ניהול תצורה אינטגרטיבית לפרויקט המתייחסת‬
‫לשילוב מוצרי קבלני המשנה בהיבטי ניהול תצורה‬
‫ תיאו' פעילויות ניהול תצורה ע' מנהלי התצורה של קבלני‬
‫המשנה‬
‫ פיתוח‪/‬רכש כלי ומתודולוגית עדכו וסינכרו לניהול תצורה של‬
‫נתוני כלל המערכת מתו( מערכות ניהול התצורה של כל‬
‫השותפי' לפרויקט‪/‬מוצר‬
‫ תיאו' כללי' אחידי' לשילוט של פריטי' שיש לתחזק'‬
‫ תיאו' כללי' אחידי' בפרויקט לשינוי מזהה פריט‪/‬מקט‬
‫)בעקבות שינוי משמעותי(‬
‫ הגדרת תצורת תוכנה מערכתית )שילוב חוקי של גרסאות פריטי‬
‫תצורה של תוכנה שאושרו כפועלי' במתוא'(‬
‫ ניהול ממשקי' מול כל קבלני המשנה )כולל פיקוח על ממשקי'‬
‫בי קבלני משנה לבי עצמ'(‬
‫ הקפאות תצורה למוצרי קבלני משנה‬
‫ מיסוד מנגנו ועדת שינויי' ברמת המוצר‪/‬פרויקט‬
‫ הגדרת כללי' וממשקי' בי ועדות שינויי' של קבלני משנה‬
‫לועדת שינויי' של החברה המשלבת )ובפרויקטי' – מנגנו אישור‬
‫מול הלקוח(‬
‫ הגדרת מידע שיש לקבל מכל קבל משנה לטובת מאגר מידע‬
‫מערכתי ברמת המוצר הכולל‪/‬פרויקט‬
‫ תחזוקת מידע תצורה כלל מערכתי המבוסס על מידע תצורה של‬
‫קבלני המשנה‬
‫ הגדרת תאימות כלל מערכתית חומרה‪/‬תוכנה‬
‫ ‪ As-planned/As-built‬מערכתי משולב ע' מידע קבלני משנה‬
‫ושותפי'‬
‫ תכנו וביצוע מבדקי' אצל קבלני המשנה לוודא ביצוע ניהול‬
‫תצורה כפי שסוכ' )למוצר‪/‬לפרויקט(‬
‫ אימות שרשור דרישות ניהול תצורה )כולל מבדקי' א' נדרש(‬
‫לקבלני משנה ברמות נמוכות יותר‬
‫ מבדקי' לאישור ‪) Baselines‬כולל קבלני משנה ושותפי'‬
‫טבלה ‪ – 2‬פעילויות ניהול תצורה "מערכתיות"‬
‫‪ .4‬ניהול תצורה מערכתי – דוגמא בנושא "ניהול שינויי"‬
‫על מנת להמחיש את פעילות ניהול התצורה המערכתי‪ ,‬נדגי' את אופ יישו' ניהול התצורה המערכתי בנושא ניהול‬
‫שינויי'‪.‬‬
‫נדמיי לעצמנו פרויקט מערכתי גדול בו שותפי' מספר קבלני משנה עיקריי' המפתחי' תתי)מערכות עבור המוצר נשוא‬
‫הפרויקט‪ .‬לפרויקט יש לקוח‪ ,‬ע' דרישות בנושא ניהול שינויי' ‪ ,‬לדוגמא‪ ,‬דרישה להביא לאישורו שינויי' לפי‬
‫קריטריוני' מוסכמי' ו‪/‬או להביא לידיעתו קיומ' של שינויי' במוצר לפי קריטריוני' מסוימי'‪ .‬מנהל התצורה של‬
‫הפרויקט הכולל צרי( לענות על הנושאי' הבאי'‪:‬‬
‫א‪ .‬מאחר ושינויי' יתרחשו ג' בחלקי המערכת המפותחי' ע"י קבלני משנה‪ ,‬כיצד אוכל לבקש אישורי' על שינויי'‬
‫שאני לא יודע שה' קיימי'?‬
‫ב‪ .‬אי( דואגי' למיסוד כללי' אחידי' לדיווח שינויי' של קבלני המשנה אלי כמנהל תצורה של כלל המערכת? אי(‬
‫מוודאי' שכללי' כאלו א' מוסדו אכ פועלי'?‬
‫ג‪ .‬הא' יהיה מכובד וקביל על הלקוח לקבל בקשות שינוי בפורמטי' שוני' של בקשה וע' תכולת מידע שונה בכל‬
‫בקשה? הא' צרי( למסד הסכ' ע' קבלני המשנה – מה תהייה תכולה "מינימאלית" של נתוני' לגבי שינוי מוצע‪,‬‬
‫הא' מעשי לאכו* "טופס בקשת שינוי" אחיד?‬
‫ד‪ .‬שינויי' בחלקי המערכת שבאחריות חברת השילוב‪/‬הקבל הראשי עשויי' להשפיע על חלקי המערכת שבאחריות‬
‫קבלני המשנה‪ .‬אי( נית לקבל מה' השפעות צפויות לפני קבלת החלטה? הא' בהתכתבות? הא' לזמ אות'‬
‫לדיוני ועדת שינויי' ברמת המוצר? הא' ה' יסכימו להשתת*?‬
‫ה‪ .‬מה מידת המינו הנכו של שקיפות מידע השינויי' של קבלני המשנה המתאימה למשימה שלי? )עוד* שקיפות‬
‫מחייב כוח אד' רב‪ ,‬מנגנו מסורבל‪ .‬מאיד( חוסר שקיפות עשוי להביא לשגיאות בהעברת מידע בזמ או באי‬
‫אישור שינוי בדיעבד(‪.‬‬
‫התשובות לשאלות בסעיפי' א' עד ה' לעיל תלויות כמוב במשתני' שוני'‪ .‬גודל ומורכבות הפרויקט‪ ,‬יכולת אכיפת‬
‫כללי' על קבלני משנה‪ ,‬התקשרות ב"קופסה לבנה" או ב"קופסה שחורה"‪ ,‬עלויות שמוכני' לשל' תמורת שקיפות מול‬
‫הסיכוני' הקיימי' בהעדר שקיפות ועוד‪ .‬אי מטרת מאמר זה להגדיר "מתכו בישול" לכל התרחישי' האפשריי'‪ ,‬אלא‬
‫להצי* את הצור( בקבלת החלטות מושכלות ואפקטיביות בפרויקטי' ובחברות מסוג זה‪.‬‬
‫קבלת החלטות אלו‪ ,‬מימוש ומעקב ניהולי על יישומ' בפועל ה' תפקידו העיקרי של מנהל תצורה "מערכתי"‪ ,‬בארגוני'‬
‫בעלי אורינטציה וסוגי פרויטי' ומוצרי' אלו‪.‬‬
‫‪ .5‬יישו מעשי של ניהול תצורה מערכתי – דוגמא בנושא ניהול שינויי‬
‫על מנת להמחיש את תפקיד מנהל התצורה המערכתי‪ ,‬אציג להל את אופ היישו' של נושא ניהול השינויי' בפרויקט‬
‫מערכתי שנוהל ע"י קונסורציו' של חברות‪ .‬ההצגה תתיחס לחברות המשתתפות כמו למוצר בכינויי' על מנת לא לחשו*‬
‫את הפרויקט ומשתתפיו‪.‬‬
‫‪ 5.1‬רקע על הפרויקט‬
‫א‪ .‬פרויקט מערכתי גדול בהק* של מאות מליוני דולר‬
‫ב‪ .‬קונסורציו' המורכב מארבע חברות גדולות במדינות שונות‪ .‬אחת מחברות הקונסורציו' הוגדרה כחברה‬
‫"מובילה" במוב שהיא היתה נקודת הקשר בי הקונסורציו' ללקוח‪ ,‬אול' מעמדה בקונסורציו' עצמו היה שווה‬
‫לשאר החברות‪.‬‬
‫ג‪ .‬לאחת החברות בקונסורציו' היו שלשה קבלני משנה עיקריי' )נתח פיתוח גבוה למוצרי' קריטיי' למערכת(‪.‬‬
‫חברה זו הייתה אחראית על הנדסת המערכת הכוללת‪ ,‬וכנגזר מתפקידה זה ג' על ניהול התצורה המערכתי הכולל‪.‬‬
‫ד‪ .‬לקוח המוצר הוא לקוח קפד‪ ,‬שרצה לראות את תצורת כלל המערכת "כאילו נרכשה ופותחה ע"י חברה אחת"‪.‬‬
‫איור ג' ממחיש את מבנה הקונסורציו'‪.‬‬
‫לקוח‬
‫חבר קונסורציום ‪1‬‬
‫)מוביל(‬
‫חבר קונסורציום ‪2‬‬
‫קב"מ משניים‬
‫חבר קונסורציום ‪3‬‬
‫קב"מ משניים‬
‫חבר קונסורציום ‪4‬‬
‫קב"מ עיקרי ‪A‬‬
‫קב"מ עיקרי ‪B‬‬
‫קב"מ עיקרי ‪C‬‬
‫קב"מ משניים‬
‫קב"מ משניים‬
‫איור ג' – מבנה ארגוני של הפרויקט‬
‫‪ 5.2‬מיקו' ניהול התצורה המערכתי בפרויקט‬
‫ניהול התצורה המערכתי בפרויקט היה באחריות חבר קונסורציו' ‪ ,4‬שהיה אחראי על הנדסת המערכת בפרויקט‬
‫)בקונסורציו'(‪.‬‬
‫‪ 5.3‬אופ יישו' ניהול שינויי' בפרויקט‬
‫בפרויקט הוגדרו כללי ניהול שינויי' שמוסדו חוזית מראש בי חברי הקונסורציו'‪ ,‬ובכל אחד מחוזי קבלנות המשנה‬
‫שכל אחד מחברי הקונסורציו' מימש‪:‬‬
‫‪ 5.3.1‬אישור שינויי'‬
‫כלל ‪ :1‬שינויי' של גור' כלשהו בפרויקט )בכל רמת התקשרות‪ ,‬המשפיעי' על חוזה או סיכו' רשמי אחר או על מוצר‬
‫שנמסר ללקוח – מחייב אישור לקוח לפני יישומו‪ .‬לפני העברת שינוי לאישור לקוח הוא חייב לעבור אישור של ועדת‬
‫השינויי' של הקונסורציו'‪.‬‬
‫כלל ‪ :2‬שינויי' של חבר קונסורציו' המשפיעי' על חוזה או סיכו' רשמי אחר או על מוצר שנמסר לאחד מחברי‬
‫הקונסורציו' – מחייב אישור של ועדת השינויי' של הקונסורציו' לפני יישומו )אול' לא מחייב אישור לקוח(‪ .‬א' יש‬
‫השפעה על הלקוח – ראה כלל ‪.1‬‬
‫כלל ‪ :3‬שינויי' של קבל משנה של הקונסורציו' המשפיעי' על חוזה או סיכו' רשמי אחר או על מוצר שנמסר לאותו‬
‫חבר קונסורציו' – מחייב אישור חבר אותו קונסורציו' לפני יישומו‪ .‬א' יש השפעה על חבר קונסורציו' אחר – ראה‬
‫כלל ‪.2‬‬
‫כלל ‪ :4‬כלל ‪ 3‬חל ג' על קבלני המשנה הלא עיקריי' בפרויקט בהתייחס לקבלני משנה שלה'‪.‬‬
‫כלל ‪ :5‬למנהל התצורה המערכתי יש זכות לזמ לדיוני ועדת שינויי' קונסורציו' נציגי' של חברות מושפעות מהשינוי‬
‫ללא תלות במיקומ' ההיררכי בקונסורציו' )כלומר‪ :‬ג' קבלני משנה ברמה נמוכה(‪.‬‬
‫באופ זה‪ ,‬מוסדה למעשה היררכיה של ארבע )סוגי( ועדות שינויי'‪:‬‬
‫ קונסורציו' ‪ +‬לקוח‬
‫ קונסורציו'‬
‫‬
‫‬
‫כל אחד מחברי הקונסורציו'‬
‫קבלני משנה )עיקריי' או משניי'(‪.‬‬
‫‪ 5.3.2‬פורמט ותכולת בקשת שינוי‬
‫כלל ‪ :1‬שינויי' המחייבי' אישור לקוח יועברו ללקוח בפורמט אחיד שסוכ' ע' הלקוח‪ .‬פורמט פנימי של חבר‬
‫קונסורציו' או קבל משנה יועבר כנספח לפורמט האחיד מול הלקוח‪.‬‬
‫כלל ‪ :2‬הוגדרו מספר מינימלי של שדות מידע שחייבי' להופיע בפורמטי' הפנימיי' של כל חבר קונסורציו' או קבל‬
‫משנה )לדוגמא‪ :‬צור( בביצוע רטרופיט ומספרי' סידוריי' של הציוד עליו יש לבצע רטרופיט(‪.‬‬
‫‪ 5.3.3‬נתוני שינויי' מינוריי' למידע‬
‫כלל ‪ :1‬כל חבר קונסורציו' וקבל משנה יעביר )תקופתית( רשימת שינויי' מינוריי' למנהל התצורה המערכתי למידע‬
‫בלבד‪.‬‬
‫כלל ‪ :2‬למנהל התצורה המערכתי יש זכות לבקש את נתוני השינוי המלאי' לגבי שינוי שקיי' לגביו חשד שסווג באופ‬
‫שגוי )כלומר שינוי שסווג כמינורי‪ ,‬אול' יש לבקש לגביו אישור מרמה ארגונית גבוהה יותר(‬
‫כלל ‪ :3‬מנהל התצורה המערכתי ינהל מערכת מידע שתכלול את כלל השינויי' בפרויקט )‪ meta-data‬של נתוני השינוי(‪.‬‬
‫‪ 5.3.4‬דיווחי יישו' שינויי' גדולי' )‪(Major/Class I‬‬
‫כלל ‪ :1‬כל גור' שהגיש בקשה של שינוי גדול שאושר חייב לדווח על יישו' השינוי במסמכי' המושפעי' מהשינוי‪ ,‬ועל‬
‫יישו' השינוי בציודי' שנמסרו ללקוח או לחברי קונסורציו' לפי מספר סידורי‪.‬‬
‫‪ 5.3.5‬בקרה על ביצוע‬
‫למנהל התצורה המערכתי יש זכות לבצע מבדק אצל חברי קונסורציו' אחרי' ואצל קבלני המשנה שלה' על מנת לוודא‬
‫יישו' כללי ניהול התצורה שסוכמו‪.‬‬
‫‪ .6‬סיכו'‬
‫מקצוע מנהל תצורה "מערכתי" – קיי' כמקצוע לכל דבר‪ ,‬ישי' לחברות מסוג "בית מערכות" או קבלני' ראשיי'‬
‫בפרויקטי' מורכבי'‪ .‬מקצוע זה‪ ,‬מטלותיו‪ ,‬וכישורי האנשי' בתפקיד זה‪ ,‬שונה מהותית ממנהל תצורה בחברה קלסית‬
‫המפתחת את רוב המרכיבי' של מוצריה‪.‬‬
‫המאמר מגדיר את המטלות של מנהל תצורה "קלאסי" ומנהל תצורה "מערכתי"‪ ,‬ומדגי' את אופ היישו' של אחד‬
‫ממרכיבי ניהול התצורה – ניהול שינויי' – בפרויקט אמיתי רחב היק* בו יושמו עקרונות המאמר‪.‬‬
‫‪ .7‬מקורות‬
‫‪[1] MIL-STD-973: “Configuration Management”.‬‬
‫‪[2] ISO 9001: “Quality Systems – Model for Quality Assurance in Design, Development, Production, Installation‬‬
‫”‪and Surviving‬‬
‫”‪[3] ISO 10007: “Quality Management – Guidelines for Configuration Management‬‬
‫‪[4] AS9100 A: Quality Systems - Aerospace - Model for Quality Assurance‬‬
‫‪in Design, Development, Production, Installation and Servicing‬‬
‫”‪[5] EIA-649-A 2004: “National Consensus Standard for Configuration Management‬‬
‫‪[6] I.Gatt, Y. Holtzberg, “Implementing Configuration Management for a Multi-National Program“, e-Business for‬‬
‫‪Industry CALS EUROPE 2000‬‬
‫‪8. Glossary‬‬
‫קבל משנה‬
‫)‬
‫קב"מ‬
‫‪Acceptance Test Procedure‬‬
‫‪Configuration Management‬‬
‫‪Configuration Management Plan‬‬
‫‪Commercial of the Shelf‬‬
‫‪Enterprise Resource Planning‬‬
‫‪First Article Inspection‬‬
‫‪Product Life-cycle Management‬‬
‫‬‫‬‫‬‫‬‫‬‫‬‫‪-‬‬
‫‪ATP‬‬
‫‪CM‬‬
‫‪CMP‬‬
‫‪COTS‬‬
‫‪ERP‬‬
‫‪FAI‬‬
‫‪PLM‬‬