‫ניהול תצורה מערכתי – סיסמא או מקצוע?‬ ‫ישראל גת‬ ‫די‪.‬אס‪.‬די‪ .‬דטה סיסטמס דיזיינרס ‪ 1989‬בע"מ‬ ‫רח' וייצמ ‪ 54‬כפר סבא ‪44247‬‬ ‫טל‪ ,09-7413294 .‬פקס‪[email protected] ,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‬‬