2.239
değişiklik
Değişiklikler
Sistem Ömür Devri Yönetiminde Konfigürasyon Yönetimi Rehberi (kaynağı gör)
14.34, 10 Haziran 2022 tarihindeki hâli
, 14.34, 10 Haziran 2022değişiklik özeti yok
[[Dosya:BAŞKANFOTO.jpg|sol|küçükresim|400x400pik]]
'''[https://tssodypwiki.ssb.gov.tr/images/5/57/TSSODYP_11_web_y.l.pdf pdf formatı için tıklayınız.]'''
TSSÖDYP, Savunma Sanayii Başkanlığı çatısı altında faaliyet göstermektedir.
© Fikri mülkiyet hakları T.C. Cumhurbaşkanlığı Savunma Sanayii Başkanlığına aittir. Kaynak gösterilmek kaydıyla alıntı yapılabilir. Üzerinde değişiklik yapmamak kaydıyla olduğu gibi çoğaltılabilir, dağıtılabilir. Para ile satılmaz.
[[Dosya:Başkan resmi y.logo.jpg|sol|küçükresim|430x430px]]
Savunma Sanayii Başkanı
Savunma Sanayii Başkanı
'''<big>ÖZET</big>'''
Tehdit algısında ve savunma konseptinde zamanla meydana gelen değişiklikler, savunma sistemlerinin ömür devri maliyetlerindeki artışlar, savunma bütçelerindeki kısıtlamalar, teknolojideki hızlı gelişmeler, uluslararası rekabet ve günümüz sistemlerinin karmaşıklığı gibi faktörler, kamu ve özel sektörün savunma sistemlerinin tedarikine ve lojistik desteğine yönelik faaliyetlerinin planlanmasında ve icrasında yeni yaklaşımlar ve buna bağlı yeni stratejiler geliştirilmesini zaruri hale getirmiştir.
Tehdit algısında ve savunma konseptinde zamanla meydana gelen değişiklikler, savunma sistemlerinin ömür devri maliyetlerindeki artışlar, savunma bütçelerindeki kısıtlamalar, teknolojideki hızlı gelişmeler, uluslararası rekabet ve günümüz sistemlerinin karmaşıklığı gibi faktörler, kamu ve özel sektörün savunma sistemlerinin tedarikine ve lojistik desteğine yönelik faaliyetlerinin planlanmasında ve icrasında yeni yaklaşımlar ve buna bağlı yeni stratejiler geliştirilmesini zaruri hale getirmiştir.
==1.3. KAPSAM==
==1.3. KAPSAM==
Sistem Ömür Devri Konfigürasyon Yönetimi Rehberi kapsamında:
Sistem Ömür Devri Yönetiminde Konfigürasyon Yönetimi Rehberi kapsamında:
* Rol, yetki ve sorumluluklar ile odak sistemin tanımlandığı perspektif,
* Rol, yetki ve sorumluluklar ile odak sistemin tanımlandığı perspektif,
==1.4. REHBERİN KULLANIMI==
==1.4. REHBERİN KULLANIMI==
Konfigürasyon Yönetimi Rehberi, beş bölümden oluşmaktadır.
Sistem Ömür Devri Yönetiminde Konfigürasyon Yönetimi Rehberi, beş bölümden oluşmaktadır.
Birinci bölüm; amaç, kapsam, referanslar gibi genel bilgileri içermektedir. Ayrıca terim ve kısaltmalar da bu bölümün içinde yer almaktadır.
Birinci bölüm; amaç, kapsam, referanslar gibi genel bilgileri içermektedir. Ayrıca terim ve kısaltmalar da bu bölümün içinde yer almaktadır.
|-
|-
|01
|01
|Temmuz 2021
|Ağustos 2021
|<nowiki>-</nowiki>
|<nowiki>-</nowiki>
|İlk yayın
|İlk yayın
Şekil 1’de sunulan STANAG 4427 hiyerarşisi içinde yer alan dokümanlar ve ekleri uygulamada dikkate alınacaktır.
Şekil 1’de sunulan STANAG 4427 hiyerarşisi içinde yer alan dokümanlar ve ekleri uygulamada dikkate alınacaktır.
[[Dosya:Şekil 1 STANAG 4427 ve ACMP Doküman Hiyerarşisi.png|alt=Şekil 1 STANAG 4427 ve ACMP Doküman Hiyerarşisi|sol|küçükresim|Şekil 1 STANAG 4427 ve ACMP Doküman Hiyerarşisi|500x500pik]]
[[Dosya:Şekil1 STANAG 4427.jpg|alt=Şekil 1 STANAG 4427 ve ACMP Doküman Hiyerarşisi|sol|küçükresim|600x600pik|Şekil 1 STANAG 4427 ve ACMP Doküman Hiyerarşisi]]
Perspektif değerlendirmesinde ilk hedef odak sistemin belirlenmesidir. Odak sistem, Ömür Devri Konfigürasyon Yönetimi süreci bağlamında en basit tanımı ile ömür devri planlaması yapılan sistemdir. Odak sistem; tepe seviyedeki ürün, servis, bileşen ya da eleman ve benzeri olabilir.
Perspektif değerlendirmesinde ilk hedef odak sistemin belirlenmesidir. Odak sistem, Ömür Devri Konfigürasyon Yönetimi süreci bağlamında en basit tanımı ile ömür devri planlaması yapılan sistemdir. Odak sistem; tepe seviyedeki ürün, servis, bileşen ya da eleman ve benzeri olabilir.
Yetenek tabanlı planlama yapılırken (Bkz. TSSÖDYP-01 Sistem Ömür Devri Yönetimi Rehberi (Ana Çerçeve)) ön konsept safhasında başlangıç isterleri ortaya çıkar, bu isterler materyal çözümünden ziyade yetenek ihtiyaçlarını tanımlar ve bu yetenek ihtiyaçları konsept safhasında odak sisteme dönüşür. Bazı tanımlamalarda ön konseptte tanımlanan yetenek ihtiyacı birden fazla odak sistem ile gerçekleşebilir.
Yetenek tabanlı planlama yapılırken (Bkz. [http://ssbwiki.ssb.gov.tr/index.php/Sistem_%C3%96m%C3%BCr_Devri_Y%C3%B6netimi_Rehberi_(Ana_%C3%87er%C3%A7eve) TSSÖDYP-01 Sistem Ömür Devri Yönetimi Rehberi (Ana Çerçeve)]) ön konsept safhasında başlangıç isterleri ortaya çıkar, bu isterler materyal çözümünden ziyade yetenek ihtiyaçlarını tanımlar ve bu yetenek ihtiyaçları konsept safhasında odak sisteme dönüşür. Bazı tanımlamalarda ön konseptte tanımlanan yetenek ihtiyacı birden fazla odak sistem ile gerçekleşebilir.
Şekil 2’de verilen odak sistem kırılımı, “Sistem Kırılımı” olarak da değerlendirilebileceği gibi aynı zamanda Konfigürasyon Yönetimi perspektifinden bakıldığında Konfigürasyon Birimi (KB) seçilmesi için de Ürün Kırılım temelini oluşturur. Tedarik makamı için odak sistem sadece sistemler ve alt sistemlerden teşkil edilen KB ile oluşturulabilirken, alt yüklenici ve onların ürün sağlayıcılarının kendi konfigürasyon yönetim seviyelerinde bu durum daha alt seviye kırılımlara inebilir. Burada izah edilen durumda tedarik makamının herhangi bir seviyede KB belirleme seçeneği her zaman saklıdır.
Şekil 2’de verilen odak sistem kırılımı, “Sistem Kırılımı” olarak da değerlendirilebileceği gibi aynı zamanda Konfigürasyon Yönetimi perspektifinden bakıldığında Konfigürasyon Birimi (KB) seçilmesi için de Ürün Kırılım temelini oluşturur. Tedarik makamı için odak sistem sadece sistemler ve alt sistemlerden teşkil edilen KB ile oluşturulabilirken, alt yüklenici ve onların ürün sağlayıcılarının kendi konfigürasyon yönetim seviyelerinde bu durum daha alt seviye kırılımlara inebilir. Burada izah edilen durumda tedarik makamının herhangi bir seviyede KB belirleme seçeneği her zaman saklıdır.
[[Dosya:Şekil 2 Odak Sistem Yapısı.png|alt=Şekil 2 Odak Sistem Yapısı|sol|küçükresim|Şekil 2 Odak Sistem Yapısı|500x500pik]]
[[Dosya:Şekil2 ODAK.jpg|alt=Şekil 2 Odak Sistem Yapısı|sol|küçükresim|600x600pik|Şekil 2 Odak Sistem Yapısı]]
===2.3.1. SİSTEM ÖMÜR DEVRİ SAFHALARI===
===2.3.1. SİSTEM ÖMÜR DEVRİ SAFHALARI===
TSSÖDYP Sistem Ömür Devri Yönetimine esas safhaları 7 safha olarak belirlemiştir. (Bkz. TSSÖDYP-01 Sistem Ömür Devri Yönetimi Rehberi (Ana Çerçeve)) Şekil 3’te görüleceği üzere bu safhalar ön konsept ile başlar ve envanterden çıkarma ile son bulur.
TSSÖDYP Sistem Ömür Devri Yönetimine esas safhaları 7 safha olarak belirlemiştir. (Bkz. [http://ssbwiki.ssb.gov.tr/index.php/Sistem_%C3%96m%C3%BCr_Devri_Y%C3%B6netimi_Rehberi_(Ana_%C3%87er%C3%A7eve) TSSÖDYP-01 Sistem Ömür Devri Yönetimi Rehberi (Ana Çerçeve)]) Şekil 3’te görüleceği üzere bu safhalar ön konsept ile başlar ve envanterden çıkarma ile son bulur.
Her Odak Sistemin belirli bir ömür devri vardır. Bu ömür devri süresince odak sistem her bir safhadan geçerek tamamlaması gereken görev ve işlemler dâhilinde belirli bir disiplin içerisinde hareket eder. Bir safhadan diğerine belirli süreçleri tamamlayarak geçer. Ömür Devri Konfigürasyon Yönetimi Planlaması faaliyetleri sırasında bu safhalar göz önünde bulundurulmalı ve yazılacak Konfigürasyon Yönetimi Planında safhalar arası geçiş için gerekli Konfigürasyon Yönetimi isterleri ve çıktıları tanımlanmalıdır (Bkz. Bölüm 3.1 Konfigürasyon Yönetimi Planlaması ).
Her Odak Sistemin belirli bir ömür devri vardır. Bu ömür devri süresince odak sistem her bir safhadan geçerek tamamlaması gereken görev ve işlemler dâhilinde belirli bir disiplin içerisinde hareket eder. Bir safhadan diğerine belirli süreçleri tamamlayarak geçer. Ömür Devri Konfigürasyon Yönetimi Planlaması faaliyetleri sırasında bu safhalar göz önünde bulundurulmalı ve yazılacak Konfigürasyon Yönetimi Planında safhalar arası geçiş için gerekli Konfigürasyon Yönetimi isterleri ve çıktıları tanımlanmalıdır (Bkz. Bölüm 3.1 Konfigürasyon Yönetimi Planlaması ).
[[Dosya:Şekil 3 Sistem Ömür Devri Safhaları.jpg|alt=Şekil 3 Sistem Ömür Devri Safhaları|sol|küçükresim|Şekil 3 Sistem Ömür Devri Safhaları|500x500pik]]
[[Dosya:Şekil3 Sistem Ömür Devri .jpg|alt=Şekil 3 Sistem Ömür Devri Safhaları|sol|küçükresim|600x600pik|Şekil 3 Sistem Ömür Devri Safhaları]]
Tedarik/Onay makamı, Müşteriler, yönetim ve öngörü gereği olarak Konfigürasyon Yönetimi sürecinde Temel Çizgileri değerlendirir ve onaylayarak resmiyet kazandırır. Temel çizgi; resmi olarak üzerinde mutabakata varılan bir ürünün ya da dokümanın (spesifikasyon) bundan sonra değişmesinin ancak resmi konfigürasyon değişiklik yönetimi ile mümkün olacağını ifade eder. (Bkz. Bölüm 3.2.4 - Konfigürasyon Temel Çizgileri)
Tedarik/Onay makamı, Müşteriler, yönetim ve öngörü gereği olarak Konfigürasyon Yönetimi sürecinde Temel Çizgileri değerlendirir ve onaylayarak resmiyet kazandırır. Temel çizgi; resmi olarak üzerinde mutabakata varılan bir ürünün ya da dokümanın (spesifikasyon) bundan sonra değişmesinin ancak resmi konfigürasyon değişiklik yönetimi ile mümkün olacağını ifade eder. (Bkz. Bölüm 3.2.4 - Konfigürasyon Temel Çizgileri)
=3. ÖMÜR DEVRİ KONFİGÜRASYON YÖNETİMİ TEMEL ADIMLARI=
=3. ÖMÜR DEVRİ KONFİGÜRASYON YÖNETİMİ TEMEL ADIMLARI=
===3.2.2. ÜRÜN AĞACI===
===3.2.2. ÜRÜN AĞACI===
Ürün ağacı, ürün yapısının hiyerarşik bir yapıda, ast-üst ilişkileri ile birbirine takip eden kalemler arasındaki ilişkinin kolayca görülebildiği tasarım, planlama, tedarik, üretim ve doğrulama faaliyetlerine baz olan kritik bir ana veridir.
Bir ürün ağacı ancak tüm birimler ve o birimlerin tasarlanması, tedarik edilmesi, üretilmesi, doğrulanması vb. faaliyetler için gerekli belgeleri veya üstverileri içerdiği surette ürün ömür devrinin tamamında fayda ve verim sağlayan bir araç haline gelebilir.
Bir ürün ağacı ancak tüm birimler ve o birimlerin tasarlanması, tedarik edilmesi, üretilmesi, doğrulanması vb. faaliyetler için gerekli belgeleri veya üstverileri içerdiği surette ürün ömür devrinin tamamında fayda ve verim sağlayan bir araç haline gelebilir.
Konfigürasyon Temel çizgileri içerdikleri bilgi detayına veya ürün ömür devri safha geçişlerindeki yetki aktarımı dönemlerine göre sınıflandırılırlar.
Konfigürasyon Temel çizgileri içerdikleri bilgi detayına veya ürün ömür devri safha geçişlerindeki yetki aktarımı dönemlerine göre sınıflandırılırlar.
===3.2.4.1. GELENEKSEL KONFİGÜRASYON TEMEL ÇİZGİLERİ===
====<big>3.2.4.1. GELENEKSEL KONFİGÜRASYON TEMEL ÇİZGİLERİ</big>====
===3.2.4.1.1. İşlevsel Temel Çizgi===
=====<big>3.2.4.1.1. İşlevsel Temel Çizgi</big>=====
Genellikle Sistem Gereksinim Tanımlama Aşamasının (Kilometre taşı M1) sonunda ürün seviyesi gereksinimlerin müşteri onayı alınarak (Sistem Gereksinimleri Gözden Geçirme Toplantıları ile) dondurulması ile İşlevsel Temel çizgi oluşturulur.
Genellikle Sistem Gereksinim Tanımlama Aşamasının (Kilometre taşı M1) sonunda ürün seviyesi gereksinimlerin müşteri onayı alınarak (Sistem Gereksinimleri Gözden Geçirme Toplantıları ile) dondurulması ile İşlevsel Temel çizgi oluşturulur.
===3.2.4.1.2. Tahsis Edilmiş Temel Çizgi===
=====<big>3.2.4.1.2. Tahsis Edilmiş Temel Çizgi</big>=====
Ön Tasarım Aşamasının (M3) sonunda, son ürün seviyesi gereksinimlerin Konfigürasyon Birimleri’ne kırılarak atanması (tahsis edilmesi) ile her bir Konfigürasyon Birimi için Tahsis Edilmiş Temel çizgi oluşturulur.
Ön Tasarım Aşamasının (M3) sonunda, son ürün seviyesi gereksinimlerin Konfigürasyon Birimleri’ne kırılarak atanması (tahsis edilmesi) ile her bir Konfigürasyon Birimi için Tahsis Edilmiş Temel çizgi oluşturulur.
===3.2.4.1.3. Geliştirme Konfigürasyonu (Tasarımsal Veya Dahili Temel Çizgi)===
=====<big>3.2.4.1.3. Geliştirme Konfigürasyonu (Tasarımsal Veya Dahili Temel Çizgi)</big>=====
Tasarım bilgileri, Detay Tasarım Aşaması (M4) boyunca peyderpey oluşturulur. Ortaya konulan her bir tasarım doğrulanmadan bir sonraki aktiviteye geçilmez. Doğrulanamayan tasarım çözümlerinin kontrollü ve proje takvimini riske sokmayacak şekilde güncellenebilmesi için yüklenici kontrolünde idame edilen dahili konfigürasyon temel çizgisine “Geliştirme Konfigürasyonu” denir. Bu dahili temel çizginin değişiklik yetkili ve sorumlusu yüklenicidir.
Tasarım bilgileri, Detay Tasarım Aşaması (M4) boyunca peyderpey oluşturulur. Ortaya konulan her bir tasarım doğrulanmadan bir sonraki aktiviteye geçilmez. Doğrulanamayan tasarım çözümlerinin kontrollü ve proje takvimini riske sokmayacak şekilde güncellenebilmesi için yüklenici kontrolünde idame edilen dahili konfigürasyon temel çizgisine “Geliştirme Konfigürasyonu” denir. Bu dahili temel çizginin değişiklik yetkili ve sorumlusu yüklenicidir.
Geliştirme safhasının sonunda Geliştirme Konfigürasyonundaki tüm bilgiler nihai doğrulama olan konfigürasyon tetkikleri sonucunda geçerli kılınarak Ürün Temel Çizgisini oluşturacaktır.
Geliştirme safhasının sonunda Geliştirme Konfigürasyonundaki tüm bilgiler nihai doğrulama olan konfigürasyon tetkikleri sonucunda geçerli kılınarak Ürün Temel Çizgisini oluşturacaktır.
===3.2.4.1.4. Ürün Temel Çizgisi===
=====<big>3.2.4.1.4. Ürün Temel Çizgisi</big>=====
Geleneksel yaklaşımda Ürün Temel Çizgisi, Geliştirme safhasının sonunda doğrulanmış ve geçerli kılınmış tasarım bilgileri olarak tanımlanmaktadır. Bu hali ile Ürün Temel Çizgisi aynı zamanda Teknik Veri Paketi’nin (TVP) büyük bir unsurunu oluşturur.
Geleneksel yaklaşımda Ürün Temel Çizgisi, Geliştirme safhasının sonunda doğrulanmış ve geçerli kılınmış tasarım bilgileri olarak tanımlanmaktadır. Bu hali ile Ürün Temel Çizgisi aynı zamanda Teknik Veri Paketi’nin (TVP) büyük bir unsurunu oluşturur.
Ürün Temel Çizgisinin çekildiği dolayısıyla TVP’nin oluşturulduğu aşama Konfigürasyon Yönetim Planlama faaliyetlerinin bir çıktısı olarak proje takvimi ve ürün olgunluğu göz önüne alınarak netleştirilir. Maliyet etkin bir TVP’nin elde edilebilmesi için düşük ölçekli ilk üretimler tamamlanıp; ürün ve üretim hattının belirli bir olgunluğa ulaşması gerekir. Aksi halde bu olgunluğa ulaşmadan teslim edilen TVP’lerde müşterinin de onaylaması gereken çok sayıda sapma/feragat/değişiklik teklifinin yer alacağı ve olumsuz takvim etkisi yaratacağı değerlendirilmelidir.
Ürün Temel Çizgisinin çekildiği dolayısıyla TVP’nin oluşturulduğu aşama Konfigürasyon Yönetim Planlama faaliyetlerinin bir çıktısı olarak proje takvimi ve ürün olgunluğu göz önüne alınarak netleştirilir. Maliyet etkin bir TVP’nin elde edilebilmesi için düşük ölçekli ilk üretimler tamamlanıp; ürün ve üretim hattının belirli bir olgunluğa ulaşması gerekir. Aksi halde bu olgunluğa ulaşmadan teslim edilen TVP’lerde müşterinin de onaylaması gereken çok sayıda sapma/feragat/değişiklik teklifinin yer alacağı ve olumsuz takvim etkisi yaratacağı değerlendirilmelidir.
===3.2.4.2. ÖMÜR DEVRİ KONFİGÜRASYON TEMEL ÇİZGİLERİ===
====<big>3.2.4.2. ÖMÜR DEVRİ KONFİGÜRASYON TEMEL ÇİZGİLERİ</big>====
Geleneksel konfigürasyon temel çizgilerine ek olarak ömür devrinin farklı safhalarındaki konfigürasyon bilgilerinin sorumluluğunun iç-dış müşteriler arasındaki el değişimi için de temel çizgiler tanımlanabilir. Söz konusu safhaların bitirilme faaliyetini daha kesin hale getirmek ve safha geçişlerindeki yetki ve sorumluluk transferi ile kontrol ihtiyacını sağlam bir zemine oturtabilmek için Ömür Devri Konfigürasyon Temel çizgileri oluşturulabilir.
Geleneksel konfigürasyon temel çizgilerine ek olarak ömür devrinin farklı safhalarındaki konfigürasyon bilgilerinin sorumluluğunun iç-dış müşteriler arasındaki el değişimi için de temel çizgiler tanımlanabilir. Söz konusu safhaların bitirilme faaliyetini daha kesin hale getirmek ve safha geçişlerindeki yetki ve sorumluluk transferi ile kontrol ihtiyacını sağlam bir zemine oturtabilmek için Ömür Devri Konfigürasyon Temel çizgileri oluşturulabilir.
Şekil 4’te olası Ömür Devri Konfigürasyon Temel Çizgilerine örnek verilmiştir.
Şekil 4’te olası Ömür Devri Konfigürasyon Temel Çizgilerine örnek verilmiştir.
[[Dosya:Şekil 4 Sistem Ömür Devri Konfigürasyon Temel Çizgileri.jpg|alt=Şekil 4 Sistem Ömür Devri Konfigürasyon Temel Çizgileri|sol|küçükresim|Şekil 4 Sistem Ömür Devri Konfigürasyon Temel Çizgileri|400x400pik]]
[[Dosya:Şekil4 Sistem Ömür Devri Konfigürasyon.jpg|alt=Şekil 4 Sistem Ömür Devri Konfigürasyon Temel Çizgileri|sol|küçükresim|650x650pik|Şekil 4 Sistem Ömür Devri Konfigürasyon Temel Çizgileri]]
İki veya daha fazla ürünün birleşme/eşleşme sınırında ortak bir şekilde var olabilmeleri için tanımlanan fiziksel ve işlevsel özelliklere Arayüz Bilgileri adı verilir. Ürünler arası arayüzlerin yönetilebilmeleri bu arayüzlerin her iki (veya daha fazla) ürün arasındaki arayüz gereksinimlerinin tanımlanmasına, kayıt altına alınmasına ve değişiklik yönetiminde gözetilmesine bağlıdır.
İki veya daha fazla ürünün birleşme/eşleşme sınırında ortak bir şekilde var olabilmeleri için tanımlanan fiziksel ve işlevsel özelliklere Arayüz Bilgileri adı verilir. Ürünler arası arayüzlerin yönetilebilmeleri bu arayüzlerin her iki (veya daha fazla) ürün arasındaki arayüz gereksinimlerinin tanımlanmasına, kayıt altına alınmasına ve değişiklik yönetiminde gözetilmesine bağlıdır.
Arayüz gereksinimleri, birbiri ile fiziksel ve/veya işlevsel arayüze sahip herhangi bir ürüne yapılacak değişikliklerin değerlendirilmesinde göz önünde bulundurulması gereken kısıtlamalar getirmelidir.
Arayüz gereksinimleri, birbiri ile fiziksel ve/veya işlevsel arayüze sahip herhangi bir ürüne yapılacak değişikliklerin değerlendirilmesinde göz önünde bulundurulması gereken kısıtlamalar getirmelidir.
===3.2.5.1. BİRLİKTE ÇALIŞABİLİRLİK KONFİGÜRASYON YÖNETİM GEREKSİNİMLERİ===
====<big>3.2.5.1. BİRLİKTE ÇALIŞABİLİRLİK KONFİGÜRASYON YÖNETİM GEREKSİNİMLERİ</big>====
Birlikte çalışabilme öncelikle Konfigürasyon Yönetimi bilgilerinin aktarımının garanti altına alınmasını şart koşarak bu bilgilerin tüm paydaşlar tarafından anlaşılabilir ve aktarılabilir olmasını gerektirir. Konfigürasyon Yönetimi bilgilerinin kontrol edilebilir ve kullanılabilir olmasını sağlayabilmek için tüm bu bilgilerin uygun şekilde tanımlanmış (kimliklendirilmiş), birbiri ile uyumlu, yetki kontrollü, tamamlanmış ve kullanıcı imkanları ile okunabilir, görülebilir, işlem görebilir olması gerekir.
Birlikte çalışabilme öncelikle Konfigürasyon Yönetimi bilgilerinin aktarımının garanti altına alınmasını şart koşarak bu bilgilerin tüm paydaşlar tarafından anlaşılabilir ve aktarılabilir olmasını gerektirir. Konfigürasyon Yönetimi bilgilerinin kontrol edilebilir ve kullanılabilir olmasını sağlayabilmek için tüm bu bilgilerin uygun şekilde tanımlanmış (kimliklendirilmiş), birbiri ile uyumlu, yetki kontrollü, tamamlanmış ve kullanıcı imkanları ile okunabilir, görülebilir, işlem görebilir olması gerekir.
Konfigürasyon Değişiklik Yönetimi iş akış şeması Şekil 5’te verilmiştir.
Konfigürasyon Değişiklik Yönetimi iş akış şeması Şekil 5’te verilmiştir.
[[Dosya:Şekil5 Konfigürasyon .jpg|alt=Şekil 5 Konfigürasyon Değişiklik Yönetimi İş Akışı|sol|küçükresim|719x719pik|Şekil 5 Konfigürasyon Değişiklik Yönetimi İş Akışı]]
Mühendislik Değişiklik Teklifi (MDT), değişiklik yönetimi adımlarının tamamında ancak ihtiyaca göre farklı detay seviye bilgiler içererek yer alır. MDT’lerin hazırlanması için aşağıdaki işlemler yapılır:
Mühendislik Değişiklik Teklifi (MDT), değişiklik yönetimi adımlarının tamamında ancak ihtiyaca göre farklı detay seviye bilgiler içererek yer alır. MDT’lerin hazırlanması için aşağıdaki işlemler yapılır:
===3.3.1.1. DEĞİŞİKLİĞİN GERÇEKLEŞTİRİLMESİ (MEŞRU KILINMASI)===
====<big>3.3.1.1. DEĞİŞİKLİĞİN GERÇEKLEŞTİRİLMESİ (MEŞRU KILINMASI)</big>====
Konfigürasyon değişiklik yönetimi faaliyetleri, efor ve maliyet içeren birçok iş adımı içermektedir. Yapılması önerilen değişikliklerin tüm paydaşlar için en fazla faydayı sağladığından emin olmak için herhangi bir işlem yapılmadan önce, olası etkilerin analiz edilerek pozitif değer katmayacak değişiklik/sapma isteklerinin sistematik olarak elenmesi ve kurum hafızasına alınması gereklidir.
Konfigürasyon değişiklik yönetimi faaliyetleri, efor ve maliyet içeren birçok iş adımı içermektedir. Yapılması önerilen değişikliklerin tüm paydaşlar için en fazla faydayı sağladığından emin olmak için herhangi bir işlem yapılmadan önce, olası etkilerin analiz edilerek pozitif değer katmayacak değişiklik/sapma isteklerinin sistematik olarak elenmesi ve kurum hafızasına alınması gereklidir.
===3.3.1.2. DEĞİŞİKLİĞİN NUMARALANDIRILMASI (KİMLİKLENDİRİLMESİ)===
====<big>3.3.1.2. DEĞİŞİKLİĞİN NUMARALANDIRILMASI (KİMLİKLENDİRİLMESİ)</big>====
Meşru bir değişiklik ihtiyacı belirlendikten sonra değişiklik teklifine tekil (eşsiz) bir numara (kimlik) atanır. Bu numara sadece değişiklik isteklerini birbirlerinden ayırmaya değil takip eden tüm bildirim, değerlendirme ve icra işlemlerinde referans alınacak numara görevini de görür. Bu numaraya ek olarak değişikliği özetleyen kısa bir başlık verilmesi tasnif ve değerlendirme faaliyetlerinde kolaylık sağlar.
Meşru bir değişiklik ihtiyacı belirlendikten sonra değişiklik teklifine tekil (eşsiz) bir numara (kimlik) atanır. Bu numara sadece değişiklik isteklerini birbirlerinden ayırmaya değil takip eden tüm bildirim, değerlendirme ve icra işlemlerinde referans alınacak numara görevini de görür. Bu numaraya ek olarak değişikliği özetleyen kısa bir başlık verilmesi tasnif ve değerlendirme faaliyetlerinde kolaylık sağlar.
===3.3.1.3. DEĞİŞİKLİĞİN SINIFLANDIRILMASI===
====<big>3.3.1.3. DEĞİŞİKLİĞİN SINIFLANDIRILMASI</big>====
Değişiklik sınıflandırması değişikliğin etki derecesinin sınıflandırılmasını sağlar. Bu sayede değişiklik teklifi uygun değişiklik onay makamına yönlendirilir. Değişiklik etki sınıfları en temel anlamda “büyük” ve “küçük” (geleneksel olarak Sınıf 1, Sınıf 2) olarak nitelenebileceği gibi onay makamının tipine ve etki çeşitliliğine göre daha fazla sınıf da belirlenebilir. Bu tür bir belirlemede karmaşıklığa engel olmak için çok fazla bölünmelere gidilmemelidir.
Değişiklik sınıflandırması değişikliğin etki derecesinin sınıflandırılmasını sağlar. Bu sayede değişiklik teklifi uygun değişiklik onay makamına yönlendirilir. Değişiklik etki sınıfları en temel anlamda “büyük” ve “küçük” (geleneksel olarak Sınıf 1, Sınıf 2) olarak nitelenebileceği gibi onay makamının tipine ve etki çeşitliliğine göre daha fazla sınıf da belirlenebilir. Bu tür bir belirlemede karmaşıklığa engel olmak için çok fazla bölünmelere gidilmemelidir.
|}
|}
===3.3.1.4. DEĞİŞİKLİĞİN BELGELENDİRİLMESİ===
====<big>3.3.1.4. DEĞİŞİKLİĞİN BELGELENDİRİLMESİ</big>====
Değişiklik veya sapma isteklerinin etkin bir değerlendirilmeye tabi olabilmeleri için anlaşılır, özlü ve geçerli bilgiler içerecek şekilde hazırlanması gerekir. Takvim ve maliyet etkileri olası alternatif çözümler ile müşteri/ihtiyaç makamı talebine göre gereken detayda verilir.
Değişiklik veya sapma isteklerinin etkin bir değerlendirilmeye tabi olabilmeleri için anlaşılır, özlü ve geçerli bilgiler içerecek şekilde hazırlanması gerekir. Takvim ve maliyet etkileri olası alternatif çözümler ile müşteri/ihtiyaç makamı talebine göre gereken detayda verilir.