TSSODYP Wiki - Kullanıcı katkıları [tr]

Entegre Lojistik Destek (ELD) Rehberi

2023-01-13T10:50:14Z

Oozdemir:

'''[https://tssodypwiki.ssb.gov.tr/images/1/17/TSSODYP-04_ELD_Rehberi_20230113.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şkanlığı çatısı altında, ilgili tüm paydaşların katılımıyla faaliyet göstermek üzere Türk Savunma Sanayii Ömür Devri Yönetimi Platformu (TSSÖDYP) kurulmuştur.

TSSÖDYP; savunma ve güvenlik sistemlerine ilişkin ihtiyacın belirlenmesi, sistemlerin tedariki, kullanımı, desteklenmesi ve envanterden çıkarması safhalarını bir bütün halinde ele alan Sistem Ömür Devri Yönetimi ilke ve uygulamalarının ülkemizde yaygınlaştırılmasını ve savunma programlarının/ projelerinin yürütülmesinde savunma ve güvenlik ekosistemini oluşturan tüm paydaşlarca anlayış birliğine ulaşılmasını amaçlamaktadır.

Savunma sistemlerinin ömür devri yönetiminde millî bünyemize uygun, ülkemize özgü çözümler üretmek ve bunları dokümante etmek gibi önemli bir misyonu olan TSSÖDYP; Başkanlığımız, Milli Savunma Bakanlığı ve ilgili birimleri, Genelkurmay Başkanlığı, K.K.K.lığı, Dz.K.K.lığı, Hv.K.K.lığı, J.Gn.K.lığı, S.G.K.lığı, EGM, TÜBİTAK, SASAD ve savunma sanayii firmaları temsilcilerinin katılımı ile çalışmalarına devam etmektedir.

Sistem ömür devri yönetimi yaklaşımı ile; savunma ve güvenlik sistemlerine ilişkin ihtiyacın belirlenmesi aşamasından envanterden çıkarma safhasının sonuna kadar görev alan tüm kamu kurum ve kuruluşları ile özel sektör firmalarının sistemlerin istenilen performans seviyesinde mümkün olan en az maliyetle tedariki, kullanımı ve lojistik desteğinin sağlanabilmesi için görev, yetki ve sorumlulukları çerçevesinde ömür devrinin tamamında birlikte çalışmaları öngörülmektedir.

Bu itibarla, savunma ve güvenlik sistemlerine ilişkin ihtiyacın belirlenmesinin, tedarikinin, kullanımının, lojistik desteğinin ve envanterden çıkarılmasının en baştan uzun soluklu bir program olarak kurgulanmasının ve ilgili birimler aracılığı ile sistem ömür devri yönetimi faaliyetlerinin yürütülmesinin faydalı olacağı değerlendirilmektedir.

TSSÖDYP tarafından son iki buçuk yıl içinde gerçekleştirilen çalışmalar ile savunma ve güvenlik sistemlerinin ömür devri yönetimine ilişkin planlama ve uygulamaya esas olacak yaklaşımları ortaya koyan 13 adet rehber, iki adet bilgi kitapçığı ve bir adet terminoloji dokümanı hazırlanmıştır. Uygulamalardan alınacak geri bildirimler ile söz konusu dokümanların güncellenmesi, geliştirilmesi ve önümüzdeki dönemde uygulamaya esas düzenlemelerin alt yapısını oluşturması hedeflenmektedir.

TSSÖDYP çalışmalarına katkı veren ve dokümanların hazırlanmasında görev alan tüm paydaşlarımıza teşekkürlerimi sunuyorum.

Prof.Dr. İsmail DEMİR

T.C. Cumhurbaşkanlığı

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.

Bu nedenle, tedarik edilen sistemlerin kullanım döneminde hedeflenen muharebe ve/veya operasyon performansının sürdürülebilirliğinin ve maliyet etkinliğinin sağlanması amacıyla sistemlerin ömür devrinde rol ve sorumluluğu bulunan tüm paydaşların katılımı ile Sistem Ömür Devri Yönetimi yaklaşımı geliştirilmiştir.

Sistem Ömür Devri Yönetiminin temel amacı; mevcut durumdaki değişimlere uyum sağlamaktan ziyade gelecekte ortaya çıkabilecek değişimleri öngörmek, belirlenen hedefler doğrultusunda gerekli önlemleri alarak değişimleri yönlendirmek ve kontrol altında tutmaktır. Harekât ihtiyaçlarının zamanında ve verimli şekilde karşılanması ve sahip olunan kaynakların maliyet etkin kullanımı esastır. Başka bir deyişle, sistem ömür devri yönetimi geleceği bugünden tasarlamak ve planlamaktır.

Bu doküman; Savunma Sanayii Başkanlığı (SSB), Milli Savunma Bakanlığının ilgili birimleri, Türk Silahlı Kuvvetleri (TSK), diğer ihtiyaç makamları ve savunma sanayi firmalarında Sistem Ömür Devri Yönetimi’nin bir kültür olarak yaygınlaştırılmasına ve uygulanmasına yönelik rehber oluşturmak amacıyla savunma sistemlerinin ömür devrinde rol ve sorumluluğu bulunan ilgili paydaşların katılımıyla hazırlanmıştır.

Entegre Lojistik Rehberi ile savunma ve güvenlik sistemlerinin görevlerini zamanında ve eksiksiz olarak yerine getirebilmesi için ihtiyaç duyulan destek unsurlarının ve lojistik destek faaliyetlerinin ihtiyaç belirleme aşamasından itibaren planlanmasına ve kullanım safhasındaki uygulamalara yardımcı olunması amaçlanmıştır.
= 1. GENEL =

== 1.1. GİRİŞ ==
Entegre Lojistik Destek (ELD) Rehberi, savunma ve güvenlik sistemlerinin görevlerini istenilen performans seviyesinde, zamanında ve kesintisiz yerine getirebilmesi için ihtiyaç duyulan destek unsurlarının ihtiyaç belirleme aşamasından başlamak üzere tedarik dönemi boyunca planlanması, temin edilmesi ve envantere alınan sistem/platformun kullanımı sırasında lojistik desteğinin sağlanması faaliyetlerinde yol gösterici rol oynamak üzere hazırlanmıştır. ELD ile ilgili konularda kavramsal bütünlük sağlanması, savunma sistemlerinin ömür devri yönetiminde yer alan tüm paydaşlar arasındaki iletişimin sağlıklı biçimde gerçekleştirilmesini sağlayacaktır.

== 1.2. AMAÇ ==
Bu doküman, sistem ömür devri yönetiminde rol ve sorumluluğu bulunan tüm paydaşlara ELD prensipleri, politikaları, yöntemler, standartlar ve organizasyonlar hakkında temel bilgileri vermek, yönlendirmek ve kavramsal birliği sağlamak için hazırlanmıştır.

Bu doküman, savunma ve güvenlik sektöründe görev alan tüm paydaşların ELD faaliyetlerine rehberlik etmek üzere hazırlanmıştır.

== 1.3. KAPSAM ==
Bu doküman, ülkemizde yürütülen/yürütülecek savunma ve güvenlik proje/programlarında sistem ömür devri yönetimi anlayışı içinde; gerektiğinde çok uluslu projelerde müşterek harekât isterleri, iletişim ve işbirliğinin yerine getirilmesine hizmet edecek ELD planlama ve uygulamalarını bir araya getirerek bir dizi halinde sunulmasına ilişkin esasları kapsamaktadır.

== 1.4. REHBERİN KULLANIMI ==
Bu dokümanda;

İlk bölüm; giriş, amaç, kapsam, referanslar gibi genel bilgileri içermektedir. Ayrıca terim ve kısaltmalar da bu bölümün içindedir.

İkinci bölümde; ELD, ELD’nin zaman içindeki gelişimi ve ilgili diğer kavramlar açıklanmaktadır.

Üçüncü Bölümde; ELD neden gereklidir sorusuna yanıt arandıktan sonra, ELD elemanları listelenmekte ve ELD elemanları hakkında detaylı bilgi verilmektedir.

Dördüncü Bölümde; ELD’nin bir alt kümesi olarak kabul edilen LDA kapsamı hakkında bilgilendirme yer almaktadır.

Beşinci Bölümde; ELD faaliyetlerinin sistem mühendisliği süreçleri ile ilişkileri anlatılmaktadır.

Altıncı Bölümde; proje yönetimi ve ELD ilişkisi çerçevesinde sistem ömür devri safhaları, proje ELD dokümanları ve takvimi oluşturulması ve acil ihtiyaçların karşılanması konularına yer verilimektedir.

ELD Planı Şablonu EK-A’da verilmiştir.

== 1.5. REHBERİN GÜNCELLENMESİ ==
Rehber ilgili paydaşların ihtiyacı doğrultusunda güncellenecektir. Değişiklikler aşağıdaki tablodan izlenebilecektir.

'''Tablo 1 Değişiklik izleme Tablosu'''
{| class="wikitable"
|'''Revizyon No'''
|'''Revizyon Tarihi'''
|'''Değişiklik Yapılan Başlık No'''
|'''Yapılan Değişiklik'''
|-
|01
|Ağustos 2021
|
|İlk yayın
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|}

== 1.6. REFERANSLAR ==
1. SSB 2019 – 2023 Stratejik Planı

2. NATO Logistic Handbook, November 2012

3. NATO AAP-48 NATO System Life Cycle Stages and Processes, March 2020

4. NATO ALP-10 NATO Guidance on Integrated Logistics Support for Multinational Armament Programmes,2015

5. NATO Action Sheet C-M(2005)0108-AS1 NATO Policy for Systems Life Cycle Management, 16 January 2006

6. INCOSE Systems Enginering Handbook (INCOSE SE HDBK), 2015

7. Guide to Life Cycles and Life Cycle Models, March 2017, Issue 1.1, Systems Engineering and Project Management Working Group

8. System Development Life-Cycle Methodologies Guide

9. DoD Directive 5000.39 Acquisition and Management of Integrated Logistic Support for Systems and Equipment, 1983.

10. Logistics Engineering and Management, Blanchard BS, 1992

11. Integrated Logistics Support Handbook, Jones JV, 2006

12. DoD Manual 4160.21, Defense Material Disposition, 2015

13. DoD Manual 4160.28, Defense Demilitarization, 2017

14. DoD Manual 5000.04-M-1, Cost and Software Data Reporting, 2011

15. ASPIRE – Supportability Engineering Training Notes

16. DAU Integrated Product Support Element Guidebook, 2011

17. Performansa Dayalı Lojistik Sektör Değerlendirme Raporu, STM, Kasım 2017

18. Standartlar- Spesifikasyon SX000i International Guide for the use of the S-Series Integrated Logistic Support (ILS) specifications, Mart 2020

19. S1000D International Specification for Technical Publications, Issue No. 5.0, 2019

20. S2000M International Specification for Material Management, Issue No. 6.1, 2017

21. S3000L International Specification for Logistics Support Analysis LSA, Issue No. 1.1, 2014

22. S4000P International Specification for Developing and Continuously Improving Preventive Maintenance, Issue No. 2.0, 2018

23. S5000F International Specification for In-service Data Feedback, Issue No. 1.0, 2016

24. NATO Standard AAP-20 NATO Programme Management Framework (NATO Life Cycle Model), Edition C Version 1 October 2015

25. MIL-STD-1369, Integrated Logistic Support Program Requirements, 1971

26. ISO/IEC 15288 Systems and Software Engineering — System Life Cycle Processes, Second edition, 2008.

27. MIL-STD-1388-1A, Logistic Support Analysis, Notice 4, 1993

28. MIL-STD-1388-2B, DOD Requirements for a Logistic Support Analysis Record, 1991

29. MIL-HDBK-502A Product Support Analysis, 2013

30. MIL-PRF-49506 Logistics Management Information, 1996

31. UK-DEF-STAN-00-60 Part 1 Logistics Support Analysis (LSA) and Logistic Support Analysis Record (LSAR), Issue 2, 1998

32. GEIA 0007 Logistics Product Data Handbook, 2007

33. TSSÖDYP Doküman Seti
{| class="wikitable"
|+
! colspan="2" |'''TSSÖDYP DOKÜMAN SETİ'''
|-
|'''DOKÜMAN ADI '''
| '''DOKÜMAN KODU'''
|-
|Sistem Ömür Devri Yönetimi Rehberi (Ana Çerçeve)
|TSSÖDYP-01
|-
|Sistem Ömür Devri Yönetimi Süreçleri Rehberi
|TSSÖDYP-02
|-
|Ürün Destek Stratejileri ve Modelleri Rehberi
|TSSÖDYP-03
|-
|Entegre Lojistik Destek (ELD) Rehberi
|TSSÖDYP-04
|-
|Entegre Lojistik Destek (ELD) İsterleri Hazırlama Rehberi
| TSSÖDYP-05
|-
|Lojistik Destek Analizleri ve Kayıtları Rehberi
|TSSÖDYP-06
|-
|Tedarik Zinciri Yönetimi Rehberi
|TSSÖDYP-07
|-
|Sistem Ömür Devri Yönetiminde Demodelik Yönetimi Rehberi
|TSSÖDYP-08
|-
|Kullanım ve Destek İhtiyaçları Çerçevesinde Yerlileştirme/

Millîleştirme Rehberi
|TSSÖDYP-09
|-
|Kullanım ve Destek Safhaları Kalite Yönetimi Rehberi
|TSSÖDYP-10
|-
|Sistem Ömür Devri Yönetiminde Konfigürasyon Yönetimi Rehberi
|TSSÖDYP-11
|-
|Teknik Yayın Hazırlama Rehberi
|TSSÖDYP-12
|-
|Eğitim ve Eğitim İhtiyaçları Rehberi
|TSSÖDYP-13
|-
|Sistem Ömür Devri Yönetimi Terminolojisi
|TSSÖDYP-14
|-
|Kodlandırma ve Sınıflandırma Bilgi Kitapçığı
|TSSÖDYP-15
|-
|ASD/AIA S-Serisi ELD Spesifikasyonları Seti Tanıtım Kitapçığı
|TSSÖDYP-16
|}

== 1.7. TANIMLAR VE KISALTMALAR ==

=== 1.7.1. TANIMLAR ===
'''Tablo 2 Tanımlar Tablosu'''
{| class="wikitable"
|'''Terim'''
|'''Tanım'''
|'''Diğer Kullanım'''
|-
|Bakım

Maintenance
|Ürün ömür devri boyunca uygulanacak bakım konseptlerini ve gereksinimleri içeren ELD Elemanıdır.
|
|-
|Bilgisayar Kaynakları

Computer Resources
|Görev kritik bilgisayar yazılım/donanım sistemlerinin işletilmesi ve desteği için ihtiyaç duyulan tesis, donanım, yazılım, iletişim, dokümantasyon, iş gücü ve personel ihtiyaçlarını kapsayan ELD Elemanıdır.
|
|-
|Destek ve Test Ekipmanları

Support and Test Equipment
|Ürünün ihtiyaç duyulduğunda kullanıma hazır olmasını sağlamak üzere, kullanımı, desteği ve ikmalini sürdürebilmek için gerekli destek ekipmanlarının (mobil veya sabit) tedarik edilmesine ve desteklenmesine ilişkin yönetsel faaliyetlerin belirlenmesi, planlanması, kaynak tahsisi ve uygulanması faaliyetlerini içeren ELD Elemanıdır.
|
|-
|Eğitim ve Eğitim Desteği

Training and Training Support
|Belirlenen eğitim stratejisinin uygulanması ile eğitim desteği kaynaklarının belirlenerek planlanması, ürünün ömür devri boyunca en uygun performans ve kullanıma hazır bulunuşluk seviyesini sağlayacak şekilde kullanılması, idamesi ve desteklenmesi için ihtiyaç duyulan personelin eğitilmesine ilişkin ELD Elemanıdır.
|
|-
|Ekonomik Ömür

Economic Life
|İhtiyacı karşılayacak yeni sistemlerin tedarik ve idame maliyetinin mevcut sistemlerin idame maliyetine oranla daha ekonomik olduğunun değerlendirilmesine kadar mevcut sistemlerin hizmet içinde kaldığı süredir.
|
|-
|İdame Mühendisliği

Sustaining Engineering
|Kullanımda olan ürünlerin desteklenmesine ilişkin işletim ve idamesi için gerekli olan teknik görevleri (mühendislik ve lojistik incelemeler, analizler vb) kapsayan ELD Elemanıdır.
|
|-
|İkmal Desteği

Supply Support
|Mümkün olan en düşük ömür devri maliyetinde en iyi kabiliyetin kullanıma hazır olmasını sağlayabilmek için gerekli onarım parçaları, yedekleri ve bütün ikmal sınıflarını tedarik etmek için yönetim faaliyetlerinin belirlenmesine, planlanmasına, söz konusu faaliyetlere yönelik kaynağın sağlanmasına ve faaliyetlerin icra edilmesine ilişkin ELD Elemanıdır.
|
|-
|İş gücü ve Personel

Manpower and Personnel
|Ürünün ömür devri boyunca kullanılması ve idame edilmesi için gerekli nitelikte iş gücü ve personelin belirlenmesi, planlanması, kaynağın sağlanması ve istihdam edilmesi faaliyetlerini içeren ELD Elemanıdır.
|
|-
|Lojistik Hacim

Logistics Footprint
|Savunma ve güvenlik kurumlarının harekata/operasyona hazır olmaları ve icra edecekleri harekatı/operasyonu sürdürebilmeleri için ihtiyaç duyulan lojistik destek girdilerinin tamamıdır (örneğin; yakıt, yedek parçalar, destek ekipmanları, ulaştırma, personel vb.).
|Lojistik Ayak İzi
|-
|Paketleme, Elleçleme, Depolama, Ulaştırma

Packaging, Handling, Storage and Transportation
|Malzeme yönetimi; ihtiyaç duyulan malzemeyi, ihtiyaç duyulan yere, ihtiyaç duyulan miktarda, uygun koşullarda, ihtiyaç duyulan sıklıkla, ihtiyaç duyulan şekilde yönlendirerek, ihtiyaç duyulan zamanda uygun yöntem kullanımı ile uygun maliyette sağlayan ELD Elemanıdır.
|
|-
|Tasarıma Etki/

Tasarım Etkileşimi

Design Influence/ Interface
|Geliştirme projelerinin başarılı olması için; halen kullanımda olan benzer sistemlerden yola çıkılarak ELD hedeflerinin, proje başında kullanıcı ile birlikte konması, tüm tasarım aşamasından başlayarak bu hedeflere göre projenin yürütülmesi ve desteklenebilirlik kriterlerinin ölçülebilir metrikler ile tasarıma yansıtılmasının sağlanması çalışmalarını içeren ELD Elemanıdır.
|
|-
|Teknik Veri ve Dokümantasyon

Technical Information and Data
|Kayıt şekli ya da yönteminden bağımsız olarak bilimsel ve teknik içerikli kayıtlı veri ve bilgileri içeren ELD Elemanıdır.
|
|-
|Tesisler ve Altyapı

Facilities and Infrastructure
|Yeni tesis ve altyapının türleri (eğitim tesisi, ekipman/malzeme/tehlikeli madde deposu, bakım tesisleri, bilgisayar donanım/yazılım sistemleri/ağ ve iletişim sistemleri altyapısı vb.) veya mevcut tesis ve altyapılardaki iyileştirmer, lokasyon, alan, çevre ve güvenlik gereksinimleri ve gerekli ekipmanların belirlenmesine yönelik faaliyetlerin tümünü içeren ELD Elemanıdır.
|
|-
|Ürün Destek Yönetimi

Product Support Management
|Bütün ELD elemanlarını kapsayacak şekilde ürün desteğinin planlanması, sağlanması ve finanse edilmesini kapsayan ELD Elemanıdır.
|
|}

=== 1.7.2. KISALTMALAR ===
'''Tablo 3 Kısaltmalar Tablosu'''
{| class="wikitable"
|'''KISALTMA'''
|'''Açık Yazımı'''
|'''Diğer Kullanım'''
|-
|ASD
|Aerospace and Defence Industries Association of Europe
|
|-
|BGA

MTA
|Bakım Görev Analizi

Maintenance Task Analyze
|
|-
|BÖM

WLC
|Bütün Ömür Maliyeti

Whole Life Cost
|
|-
|CİT

BIT
|Cihaz İçi Test-

Built in Test
|
|-
|DKÖT
|Destek, Kalibrasyon, Ölçü ve Test
|
|-
|ELD

ILS
|Entegre Lojistik Destek

Integrated Logistics Support
|
|-
|ELDP

ILSP
|Entegre Lojistik Destek Planı

Integrated Logistics Support Plan
|
|-
|HTEA

FMEA
|Hata Türleri Etkileri Analizi

Failure Modes and Effects Analysis
|
|-
|HTEKA

FMECA
|Hata Türleri Etkileri ve Kritiklik Analizi

Failure Modes, Effects and Criticality Analysis
|
|-
|LDA

LSA
|Lojistik Destek Analizi

Logistic Support Analysis
|
|-
|LDAK

LSAR
|Lojistik Destek Analizi Kayıtları

Logistic Support Analysis Records
|
|-
|NATO
|North Atlantic Treaty Organization
|
|-
|OSA

LORA
|Onarım Seviyesi Analizi

Level of Repair Analysis
|
|-
|ÖDM

LCC
|Ömür Devri Maliyeti

Life Cycle Cost
|
|-
|PDL

PBL
|Performansa Dayalı Lojistik

Performance Based Logistic
|
|-
|ÖBGG

PMTR
|Önleyici Bakım Görev Gereksinimleri

Preventive Maintenance Task Requirements
|
|-
|PTD
|Proje Tanımlama Dokümanı
|
|-
|RAHAT

COTS
|Rafta Hazır Ticari Ürün

Commercially off the Shelf Item
|Raf Ürünü
|-
|RAMST
|Güvenilirlik-Kullanıma Hazır Olma-İdame Edilebilirlik-Desteklenebilirlik-Test Edilebilirlik

Reliability-Availability-Maintainability-Supportability-Testability
|
|-
|TÇD

RFP
|Teklife Çağrı Dosyası

Request for Proposal
|
|-
|TSSÖDYP
|Türk Savunma Sanayii Ömür Devri Yönetimi Platformu
|
|-
|TSOM

TOC
|Toplam Sahip Olma Maliyeti

Total Ownership Cost
|
|}

== 1.8. TABLOLAR VE ŞEKİLLER ==

=== 1.8.1. TABLOLAR ===
Tablo 1: Değişiklik izleme Tablosu

Tablo 2 Tanımlar Tablosu

Tablo 3 Kısaltmalar Tablosu

Tablo 4 Desteklenebilirlik –Sistem

Tablo 5 ÖDM Bileşenleri

Tablo 6 ELD Faaliyetleri Kapsamında Hazırlanacak ve Güncelenecek Dokümanlar

=== 1.8.2. ŞEKİLLER ===
Şekil 1 Sivil Lojistik Mimarisi

Şekil 2 Sistem; Odak Sistem ve Destek Unsurları

Şekil 3 Bütçelenebilir Operasyonel Etkinlik

Şekil 4 Sistem Ömür Devri Safhaları

Şekil 5 Sistem Ömür Devri Yönetimi Süreçleri

Şekil 6 ÖDM, TSOM ve BÖM arasındaki ilişki

Şekil 7 ELD Elemanları ile Optimum Lojistik Destek İlişkisi

Şekil 8 Bakım Faaliyetleri

Şekil 9 Savunma ve Güvenlik Sistemi İçin Başarı Kriterleri

Şekil 10 Temel LDA Süreci

= 2. TEMEL KAVRAMLAR =

== 2.1. LOJİSTİK ==
Lojistik,‘’logisticos’’ kelimesinden türemiş olup, “hesap yapma bilimi” ya da ‘’hesapta becerikli” anlamına gelmektedir. Bir başka görüşe göre de Lojistik, Logic (mantık) ve Statistics (istatistik) kelimelerinin birleşmesinden meydana gelmiştir.

Blanchard’a göre lojistik; destek elemanlarının satın alınması, ikmali, malzemelerin taşınması ve dağıtımı (taşıma, ulaştırma ve ürünlerin depolanması), bakımı, kullanımı ve planlanan ömür süreleri boyunca yapılacak tüm destek faaliyetlerini içerir.

Yazılı kaynaklar, geçmişten günümüze askerî alanda güç unsurlarını hareket ettirme yeteneğinin savaşların kazananı ve kaybedenini belirlemede ne derece önemli olduğunu göstermektedir. Büyük İskender’in kısa süre içinde büyük topraklar fethetmesini sağlayan stratejinin temelinde başarılı lojistik planlamaları yatar. Doğru planlama, iyi hazırlık ve doğru tercihler ile yönetilen lojistik, Büyük İskender’in çağdaşlarına göre çok daha esnek ve süratli bir orduya sahip olmasını sağlamıştır. Benzer şekilde, süratli ve esnek bir askerî güç ve lojistik yeteneğine sahip güçlü bir kuvvet yapısına sahip olması Osmanlı İmparatorluğu’nun üç kıtaya hükmeder hale gelmesindeki en önemli unsurlardan biridir.

Milli güvenliğin temel unsurlarından biri olan askerî gücün edinilmesinde savunma sistemlerindeki sayısal üstünlüğün yeterli olmadığı bilinmektedir. Askerî gücün kazanımında eğitim, disiplin, moral-motivasyon, yönetim ve özellikle teknolojik yeterlilik ile elde edilen nitelik üstünlüğüne ihtiyaç vardır.

Sahip olunan sistemlerin beklenen fonksiyonlarını kabul edilebilir performans seviyesinde en az maliyetle ve kullanım ömrü boyunca sağlayabilmesi temel hedeftir. Bu hedef; sisteme sahip olan, tedarikinde, kullanımında ve desteğinde görev alan veya ödenen bedelde payı olan tüm paydaşlar için ortaktır.

Yüksek rekabet ortamında mevcut veya olası tehditlerin çeşitliliği, değişim hızı ve yeteneği; yüksek caydırıcılık gücüne sahip, ileri teknoloji ürünü, dolayısı ile karmaşık yapıda savunma sistemlerine sahip olmayı gerektirir. Bu tür sistemlerin öngörülen ömürleri boyunca harekât ihtiyacını karşılayabilecek şekilde göreve hazır bulundurulması; teknik, idari ve bütçesel birçok problemin üstesinden eşzamanlı olarak gelinmesi ile mümkündür. Başka bir deyişle, herbiri kendi içinde uzmanlık isteyen birçok disiplinin, birbiri ile uyum içinde ortak bir hedefe doğru yönlendirilmesi gerekir. Zira sahip olunan savunma sistemlerinin hazır bulunuşluğu silahlanma programlarının başlıca gereksinimlerinden biridir. Hazır bulunuşluk ise ihtiyaç duyulan lojistik desteğin ihtiyaç duyulan yer ve zamanda varlığına bağlıdır.

Savunma ve güvenlik sisteminin kullanıma alınmasından itibaren ihtiyaç duyulduğu anda göreve hazır olabilmesi için ilgili destek unsurlarının odak sistemle eşzamanlı olarak geliştirilmesi, tedariki ve hazırlanması gerekir. Bu hedefe maliyet etkin şekilde ulaşılabilmesi kullanıcıların, tasarımcıların ve lojistik destek ekiplerinin ihtiyacın belirlenmesi aşamasından itibaren birlikte çalışmasına bağlıdır.

Dünyadaki mevcut askerî lojistik sisteminin gelecekteki savaşlarda operasyonların hızına yetişebilmek için yetersiz kalacağına ve yeni bir bakış açısına ihtiyaç olduğuna dair işaretler mevcuttur. Hâlihazırda sivil ticaret şirketlerinin yurt içinde veya dünya çapında uygulayabildikleri ürün dağıtım teknikleri ve eriştikleri sürat bu işaretlerden birisidir.

İnsansız sistemler ve dronların gelecekteki savaşlarda daha fazla rol alacağı şimdiden bellidir. Gelecekte harekât alanının genişlemesiyle; yüksek hızlı, çok boyutlu, eşzamanlı harekât ve şartların değişimine anlık cevap verebilme yeteneklerine ihtiyaç duyulacaktır. Bu ihtiyaç, bilgi teknolojilerinin artan oranda kullanımı ile karşılanabilir.

Ortak kaynak veri tabanları, güvenli iletişim ağları, artırılmış gerçeklik, sanal gerçeklik, karma gerçeklik, uzaktan bakım, yapay zekâ, 3 boyutlu yazıcılar vb. uygulamaların yaygınlaşacağı öngörülmektedir. Bu sebeple, programlar/projeler ömür devri yönetimi yaklaşımı ile kurgulanırken bilgi teknolojilerinin kullanımı konusuna da özel bir önem verilmesi gerekmektedir.

== 2.2. MİLLÎ GÜVENLİK VE LOJİSTİK İLİŞKİSİ ==
Milli güvenlik; siyasi, askerî, ekonomik, beşeri, coğrafi, bilimsel, teknolojik, psiko-sosyal ve kültürel millî güç unsurlarından meydana gelir. Lojistik kavramına en üst seviyeden bakıldığında Stratejik Lojistik ve Uygulamalı Lojistik olarak iki temel alanın mevcut olduğu görülebilir.

=== 2.2.1. STRATEJİK LOJİSTİK ===
Askerî güç ve ekonomik güç milli güvenlikle birlikte ele alındığında stratejik lojistik alanını oluşturur. Ülkenin mevcut havalimanları, demir yolları, kara yolları, fabrikalar, tersaneler, tesisler, depolar, yetişmiş iş gücü, bilimsel ve teknik çalışmalar/kurumlar, mali sistem, iletişim sistemleri, savunma ve güvenlik kurumları gibi alt yapılar ve bunların akılcı yönetimi stratejik seviyedeki lojistik unsurları oluşturur.

=== 2.2.2. UYGULAMALI LOJİSTİK ===
Uygulamalı lojistik, savunma ve güvenlik alanında ihtiyaç duyulan sistemlerin/platformların tedariği, kullanımı ve idamesine ilişkin lojistik fonksiyonlardır. Uygulamalı lojistik, Tedarik Lojistiği ve İşletim Lojistiği olmak üzere iki ana bölüme ayrılır.

=== 2.2.2.1. TEDARİK LOJİSTİĞİ ===
Tedarik lojistiği; ihtiyaç duyulan sistemin araştırılması, tasarlanması, geliştirilmesi, üretilmesi, envantere alınması ile kullanım ve destek unsurlarının temin ve tedarik edilmesine ait faaliyetleri içerir.

Tedarik lojistiği faaliyetleri, sistem mühendisliği sürecinin bir parçasıdır. Alternatif çözümler içinde desteklenebilirliği en yüksek olan çözüme ulaşılmaya çalışılır. Bu kapsamda, her bir alternatif çözüm ile ilgili olarak;

* Lojistik kısıtlar ile destek gereksinimlerinin belirlenmesi (harekât ihtiyaçları),
* İstenilen performans seviyesinde, desteklenebilirliği ve sürdürülebilirliği yüksek, maliyet etkin sistem çözümlerinin öne çıkarılması,
* Ürün tasarımının belirlenen lojistik destek gereksinimlerini tam ve doğru olarak sağlaması,
* Planlanan destek çözümünün işlerliğinin doğrulanması,
* Destek için gerekli malzeme ve ekipmanların tedarik edilmesi ya da üretilmesi, görev yerlerine ikmali ve kurulumu,
* Yapılması gerekli modifikasyon ve değişikliklerin uygulanması

faaliyetleri yürütülür.

=== 2.2.2.2. İŞLETİM LOJİSTİĞİ ===
İşletim lojistiği; Sistem ömür devrinin Kullanım, Destek ve Envanterden Çıkarma safhalarındaki destek ihtiyaçlarının belirlenmesi, sistem, destek ve ikmal malzemelerinin depolanması, dağıtımı, ulaştırılması, bakımı, kullanıma hazır bulundurulması ve envanterden çıkarılması faaliyetlerinin planlanması, yürütülmesi, gözden geçirilmesi ve iyileştirilmesidir. İşletim lojistiği; bakım/onarım, malzeme ikmali, taşıma, ulaştırma, tesis, iş gücü, eğitim vb. hususları kapsar.

== 2.3. ASKERÎ LOJİSTİK ==
Askeri Lojistik, mevcut ve öngörülen kuvvet yapısının; sistemler, altyapı ve hizmetlerin ömür devri çerçevesinde, savaşta, barışta, gerginlik/kriz döneminde, yetki ve sorumluluklara uygun yönetimini kapsayan faaliyetler bütünüdür.

== 2.4. SİVİL LOJİSTİK ==
Sivil lojistik; sistem, müşteri servisi, talep tahmini, ulaştırması, dağıtımı, ürün kontrolü, parça ve servis desteği, satın alma, paketleme, geri dönüşüm, değişim, taşıma ve depolama faaliyetlerinin tümünü kapsamaktadır.
[[Dosya:Şekil1 Sivil Lojistik Mimari.jpg|alt=Şekil 1 Sivil Lojistik Mimarisi|sol|küçükresim|500x500pik|Şekil 1 Sivil Lojistik Mimarisi]]

== 2.5. SİSTEM ==
'''Sistem;''' ömür devrinin ilk safhasından itibaren Odak Sistem ve Destek Unsurlarının ayrılmaz bir bütün halinde ele alındığı ve yönetildiği bileşenler topluluğudur.

'''Odak Sistem;''' herhangi bir portföy/program/proje çerçevesinde, yeni bir temel yetenek kazandıran ya da mevcut bir temel yeteneğin kapsamlı modernizasyonuna yönelik olan, tedariki, kullanımı ve desteği yüksek maliyetli ve/veya gerçekleştirilmesi nispeten uzun zaman alacak olan savunma ve güvenlik sistemleridir.

Odak Sistemin temel görevi, savunma ve güvenlik ihtiyacını belirlenen kullanım konsepti ve görev profilleri çerçevesinde istenilen performans seviyesinde karşılamaktır. Odak Sistem, sistemler sistemi olarak tanımlanabilecek bir yapı olabileceği gibi sadece alt sistemlerden ve sistem elemanlarından oluşan bir yapı da olabilir. Bu çerçevede, Odak Sistem – yukarıdaki tanıma uygun olacak şekilde - savunma sistemi/platformu, ana silah sistemi, ana sistem, ana malzeme, ürün, cihaz ve benzerlerini ifade etmektedir.

'''Destek Unsurları;''' Odak Sistemin belirlenen kullanım konsepti ve görev profilleri çerçevesinde istenilen performans seviyesinde görev yapabilmesi ve maliyet etkin olarak kullanımında sürekliliğin sağlanması için ihtiyaç duyulan unsurlardır. Destek Unsurları, bunlarla sınırlı olmamak üzere Şekil 2’deki hususları kapsar.
[[Dosya:Sistem Odak Sistem.png|alt=Şekil 2 Sistem; Odak Sistem ve Destek Unsurları|sol|küçükresim|600x600pik|Şekil 2 Sistem; Odak Sistem ve Destek Unsurları]]

Sistem tasarımında teknik, taktik, lojistik ve mali hususlar bir bütün halinde ele alınarak sistemin ömür devri boyunca Şekil 3’te gösterildiği şekilde bütçelenebilir operasyonel etkinliğe sahip olması hedeflenmektedir.
[[Dosya:Şekil3 Bütçelenebilir Operasyonel Etkinlik.jpg|alt=Şekil 3 Bütçelenebilir Operasyonel Etkinlik|sol|küçükresim|600x600pik|Şekil 3 Bütçelenebilir Operasyonel Etkinlik]]

== 2.6. DESTEKLENEBİLİRLİK ==
Desteklenebilirlik; Operasyonel konseptler çerçevesinde, “Odak Sistem” ve “Destek Unsurları”nın bir bütünü olan “Sistem” tasarımının, destek faaliyetlerini yürütme ve göreve hazır olma/bulunma gereksinimlerini, planlanan ömür devri boyunca, barış ve savaş şartlarında, kabul edilebilir maliyetler dahilinde karşılayabilme kabiliyetidir.

Desteklenebilir ürün geliştirmede kullanılacak başlıca tasarım parametreleri; güvenilirlik, kullanıma hazır olma, idame edilebilirlik, sürdürülebilirlik, test edilebilirlik ve emniyettir.

Sistemi oluşturan her bir unsurun karakteristiğinin, yukarıda bahsedilen parametreler üzerinde değişen oranlarda etkisi mevcuttur. Öte yandan tüm unsurlar birbirleri ile de etkileşim halindedirler. Lojistik destek kapsamında yapılan analizlerde, her bir unsurun desteklenebilirlik ölçütleri üzerindeki etkisi ve duyarlılık derecesi (degree of precision) ile sistemi oluşturan diğer unsurlar ile etkileşim derecesi incelenir.

Sistemden beklenen fonksiyonel çıktı ve performans değerlerine ulaşabilmeyi sağlayan, sistemi oluşturan unsurların teorik olarak sınırsız sayıda kombinasyonundan bahsedilebilir. Bu da, alternatiflerin maliyet ekseninde karşılaştırılmasını gerekli kılar.

Sistemi oluşturan birçok unsurun zamanla değişkenlik arzeden karakteristiğe sahip olması (özellikle İnsan/Destek Sistemi karakteristiği), desteklenebilirlik hedeflerinin ürün ömür devri boyunca takibini gerektirir.

Odak sistemlerin lojistik desteğini doğrudan etkileyen ana unsurlar, sistem bileşenlerine ayrılarak Tablo 4 içeriğinde verilmiştir.

'''Tablo 4 Desteklenebilirlik –Sistem'''
{| class="wikitable"
| colspan="3" |

'''SİSTEM'''

''a. Desteklenebilirlik''
|-
|'''Odak Sistem'''
|'''Destek Sistemi'''
|'''İşletimsel Sistem'''
|-
|· ''Güvenilirlik''

· ''İdame Edilebilirlik''

· ''Test Edilebilirlik''

· ''Lojistik Desteklenebilirlik''

''İyileştirilebilir tasarım, Desteklenebilir sistem mimarisi, Standardizasyon, ''

''Entegre bakım desteği (CİT vb.), Emniyet,''

''Kullanım kolaylığı,''

''Düşük riskli destek unsurları,''

''İzleme kolaylığı,''

''Elden çıkartılabilme kolaylığı,''

''…''
|· ''Lojistik Desteklenebilirlik''

''Fiziksel ve Organizasyonel Yapılanma''

'' Basit,''

'' Ekonomik,''

'' Erişilebilir,''

'' Esnek,''

'' Sürdürülebilir,''

'' İhtiyacı Karşılayabilen''

''Tanımlı Süreçler ve Prosedürler''

''Kaynaklar''

'' Personel-iş gücü,''

'' Yedek parça, sarf malzemeleri,''

'' Test donanımı, avadanlıklar,''

'' Destek ekipmanları,''

'' Teknik veri,''

'' Tesis,''

'' Ulaşım''

'' …''
|· ''Kullanım Konsepti''

· ''Görev Profilleri''

· ''Bakım Konsepti''
|}
Desteklenebilirlik ilişkili ürün performans parametreleri [https://tssodypwiki.ssb.gov.tr/index.php/Entegre_Lojistik_Destek_(ELD)_%C4%B0sterleri_Haz%C4%B1rlama_Rehberi TSSÖDYP-05 ELD İsterleri Hazırlama Rehberi] EK-A Parametre Listesinde verilmekte, bahse konu parametrelere ilişkin detaylı bilgi [https://tssodypwiki.ssb.gov.tr/index.php/Lojistik_Destek_Analizleri_ve_Kay%C4%B1tlar%C4%B1_Rehberi TSSÖDYP-06 Lojistik Destek Analizleri ve Kayıtları Rehberinde] yer almaktadır.

== 2.7. SÜRDÜRÜLEBİLİRLİK ==
Karmaşık savunma ve güvenlik sistemlerinin ömrü 30-40 yıl veya daha uzun süreli planlanabilir. Sistemden beklenen fonksiyonları bu uzun zaman periyodunda yerine getirebilmesi, sistemin başlangıçtaki performansı ile kullanılabilmesi ve faaliyetini planlanan süre ve seviyede devam ettirebilmesi ile ÖDM’nin düşürülmesi sistemin tasarım sürecinde dikkate alınmalıdır.

Sistemin idamesine ilişkin kullanım ve destek safhalarındaki faaliyetlerin etkin şekilde planlanması ve yürütülmesi sürdürülebilirliğin sağlanmasındaki en önemli faktördür.

== 2.8. SİSTEM ÖMÜR DEVRİ YÖNETİMİ ==
Sistem ömür devri yönetimi konusunda bilgi almak üzere; [https://tssodypwiki.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)] ve [https://tssodypwiki.ssb.gov.tr/index.php/Sistem_%C3%96m%C3%BCr_Devri_Y%C3%B6netimi_S%C3%BCre%C3%A7leri_Rehberi TSSÖDYP-02 Sistem Ömür Devri Yönetimi Süreçleri Rehberinden] faydalanılabilir.

=== 2.8.1. SİSTEM ÖMÜR DEVRİ SAFHALARI ===
Sistem ömür devri yönetiminde, benzer amaçlar ve performans ölçütleri doğrultusunda çeşitli modeller söz konusudur. Karmaşık sistemlerin tedarikinde, kullanımında ve envanterden çıkarılmasında karşılaşılabilecek riskleri azaltmak ve etkili bir risk yönetimi sağlayabilmek amacıyla, organizasyonlar tarafından ömür devri modellerinin çeşitli versiyonları üretilmiştir. Sistem ömür devri modelleri çeşitli standart ve rehber dokümanlar ile desteklenmektedir.

[https://tssodypwiki.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)’]de Sistem Ömür Devri; Ön Konsept, Konsept, Geliştirme, Üretim, Kullanım, Destek ve Envanterden Çıkarma olmak üzere Şekil 4’te gösterildiği üzere 7 safhadan oluşmaktadır.
[[Dosya:Şekil4 Sistem Ömür Devri Safhaları.jpg|alt=Şekil 4 Sistem Ömür Devri Safhaları|sol|küçükresim|600x600pik|Şekil 4 Sistem Ömür Devri Safhaları ]]

=== 2.8.2. SİSTEM ÖMÜR DEVRİ YÖNETİMİ SÜREÇLERİ ===
Sistem ömür devri yönetiminin temel amacı; performans, maliyet etkinlik, takvim, kalite, operasyonel çevre, ELD ve demodelik gibi faktörleri göz önünde bulundurarak ömür devri boyunca sistem kabiliyetlerinin optimizasyonudur. Sistem ömür devri yönetimi modelinin başarılı bir şekilde işletilmesi ve yönetilmesi için gerekli süreçler [https://tssodypwiki.ssb.gov.tr/index.php/Sistem_%C3%96m%C3%BCr_Devri_Y%C3%B6netimi_S%C3%BCre%C3%A7leri_Rehberi TSSÖDYP-02 Sistem Ömür Devri Yönetimi Süreçleri Rehberi’nde] tanımlanmaktadır. Sistem ömür devri süreçleri; Mutabakat Süreçleri, Organizasyonel Program/Proje Destek Süreçleri, Program/Proje Süreçleri ve Teknik Süreçler olmak üzere Şekil 5’te verildiği üzere 4 ana kategoride toplanmıştır.
[[Dosya:Şekil5 Sistem Ömür Devri Yönetimi Süreçler.jpg|alt=Şekil 5 Sistem Ömür Devri Yönetimi Süreçleri|sol|küçükresim|881x881pik|Şekil 5 Sistem Ömür Devri Yönetimi Süreçleri]]

=== 2.8.3. SİSTEM ÖMÜR DEVRİ YÖNETİMİNDE PAYDAŞLAR, ROLLER VE SORUMLULUKLAR ===
Sistem ömür devri boyunca; ilgili paydaşların ihtiyaçlarının, beklentilerinin ve sorumluluklarının belirlenmesi, sorunsuz programlar/projeler yürütebilmenin ilk ve en önemli koşullarındandır.

Bir program/proje kapsamında ihtiyaç makamları, kullanıcılar, tedarik makamları, idame makamları, ana yükleniciler, alt yükleniciler, tedarikçiler, orjinal ekipman üreticileri ve diğer katkı sağlayabilecek organizasyonlar paydaş olarak nitelendirilebilir. Paydaşların sürece katılımı sistem ömür devrinin farklı noktalarında gerçekleşebilir.

Sistem ömür devri yönetimi kurgusunda, belirli bir düzen dahilinde ihtiyaçların netleştirilmesi amacıyla ilgili paydaşlar ön çalışmalarını yaparlar. Daha sonra bu ihtiyaçlar paydaş isterlerine dönüştürülür ve çeşitli formlarda kayıt altına alınır. Açık ve net olmayan ifadelerin anlaşılır ve ölçülebilir isterlere dönüştürülebilmesi için paydaşlar arasında ortak çalışma yapılır. Bu aşamada başvurulacak paydaş ihtiyaçları ve ister tanımlama sürecinde; operasyonel konsept dokümanı, stratejik işletme/kullanım planları vb. kaynaklardan faydalanılabilecektir.

Paydaş ihtiyaçları; geliştirme safhasına ait gereksinim tanımlama, tasarım, test ve doğrulama, entegrasyon gibi önemli aktivitelerin temelini oluşturacağı için ömür devri yönetimi kurgusunda sistem mühendisliği açısından önemli bir rol üstlenir. Paydaşlar arasında sağlanacak iletişimin yapı taşı paydaş isterleri olacaktır.

Sistem ömür devri safhalarına yönelik olarak her safhada ilgisi olabilecek paydaşlar tanımlanmalıdır. Paydaş isterleri; fonksiyonel, operasyonel, ara yüz, çevre, insan faktörleri, lojistik, bakım, tasarım, üretim, doğrulama, teslimat, eğitim, sertifikasyon, elden çıkarma, desteklenebilirlik, kalite, emniyet, özel mühendislik ve güvenlik gibi çeşitli kategorilerde sınıflandırılabilir ve ilgili faaliyetler için sorumluluklar tanımlanır.

=== 2.8.4. FİZİKÎ ÖMÜR, TEKNOLOJİK ÖMÜR, PLANLANAN KULLANIM ÖMRÜ ===
Bir sistemin ya da ürünün sistem ömür devri konsepti ifade edilirken, “ömür” kavramı üzerinde ilgili paydaşlar ile fikir birliği sağlanması, ihtiyacı net olarak anlama ve verimli bir planlama açısından faydalı olacaktır. Bu kapsamda fizikî ömür, teknolojik ömür ve planlanan kullanım ömrü ifadeleri aşağıda açıklanmıştır.

Sistem ömür devri kurgusu içinde kullanımına başlanan bir ürünün fiziksel ömrünün, teknolojik ömrünün ve planlanan kullanım ömrünün aynı anda başladığı ifade edilebilir. Ancak, sistemin tedariki süresince geçen zaman teknolojik ömür açısından önemli bir risk içerebilir. Bu sebeple, ihtiyaçların sadece mevcut teknoloji çerçevesinde değil ileriye dönük teknolojik öngörüleri de kapsayacak şekilde karşılanması gerekir.

Sistemin ilk kurulumu ile birlikte üretim ve kalite hatalarının sıklıkla ortaya çıkabileceği bir dönem yaşanması olasıdır. Bu dönemde ürünün fizikî ve teknolojik ömrünün devam ettiğini, planlanan kullanım ömrü içinde olduğunu ancak henüz faydalı ömrüne erişmediğini ifade edebiliriz. Hatalı planlama ya da uzun ürün geliştirme süreçleri vb. nedenler dolayısıyla çok erken dönemlerde yeni teknoloji bir ürünle karşılaşılması gibi durumlar söz konusu olabilecektir. Bu dönem sonrası nispeten arıza sıklığının azaldığı ve sistemin daha etkin kullanılabildiği “faydalı ömür” dönemi başlayacaktır. Son olarak faydalı ömür sonrası tekrar arıza sıklıkları artacak ve sistem yavaş yavaş planlanan kullanım ömrünün sonuna gelecektir. Bu durumda genellikle planlanan kullanım ömrünün devam etmemesi tercih edilebilecektir. Özellikle görev kritik sistemler söz konusu olduğunda yeni teknolojiye ve arıza sıklığına hassasiyet daha fazla ağırlığa sahip karar değişkeni olacaktır.

Yukarıda yer alan değerlendirmeler ışığında; fiziksel ömür kavramı, diğer kavramlara nazaran daha net bir şekilde ifade edilebilir. Bir sistemin kendisinden beklenen fonksiyonları yerine getirmek suretiyle fiziksel özellikleri el verdiği sürece görevini yapabilmesi, sistemin fiziksel ömrü olarak nitelendirilebilir. Ancak teknolojik ömür ve planlanan kullanım ömrü; çevresel, ekonomik, coğrafik, teknolojik vb. faktörlerden daha fazla etkilenmektedir. Teknolojik ömür; kabiliyet ihtiyacını karşılayan bilgi ve becerinin yeni bir düşünce, gelişme vb. ile karşılanabilmesine kadar geçen süre olarak nitelendirilebilir. Bu süreyi erken aşamalarda bir sistem için öngörmek, dünya ile sürekli irtibat halinde olmak ve yenilikleri takip etmekten geçecektir. Son olarak; planlanan kullanım ömrünün, sistem ömür devrinin ön konsept ve konsept safhalarında ihtiyacı karşılamaya yönelik karşılıklı fikir alışverişleri neticesinde geliştirilen sistemlerin tasarlanan hizmet süreleri olduğunu ifade edebiliriz.

== 2.9. ÖMÜR DEVRİ MALİYETİ (ÖDM) ==
ÖDM, sistemin tedarik döneminde ödenen maliyet ile kullanım, destek ve envanterden çıkarma boyunca ödenen maliyetlerin toplamıdır. ÖDM’nin başlıca bileşenleri, araştırma-geliştirme, yatırım, üretim, kullanım, destek ve envanterden çıkarma maliyetleridir. Karmaşık savunma sistemlerinde kullanım, destek ve envanterden çıkarma maliyetleri toplamının diğer bileşenlerin toplamından daha yüksek olduğu bilinmektedir.

Uzun vadede sisteme sahip olma maliyetinin en düşük seviyede tutulması, yüklenici açısından ekonomik rekabetin bir boyutudur. ÖDM, kısa vadeli maliyet düşürme faaliyetleri yerine ileri görüşlülükle uzun vadede maliyeti etkileyen unsurların tespit edilmesini ve maliyet etkin alternatif çözümlerin ortaya konulabilmesi için yaratıcı fikirler üretebilen mühendislik faaliyetlerini gerekli kılar. Başka bir deyişle, projelerin zaman ve bütçe kısıtları dışında uzun vadede sahip olma maliyeti açısından değerlendirilmesini sağlar.

Başarılı bir ÖDM analizinin en önemli kaynağı, kullanımda olan sistemlerden toplanan verilerdir. Gerçekleşen maliyet, ürünün kullanım süresiyle orantılı olarak değişkenlik gösterir. ÖDM analizi süreklilik arzetmeli ve sonuçları canlı tutulmalıdır. Güncel sonuçlar; sahip olma maliyetinin yanı sıra sistemin kalan ömrü boyunca beklenen maliyetinin tahmini, kullanım ve bakım bütçelerinin belirlenmesi, yeni sistemlerin geliştirilmesi sürecinde oluşan gecikmelerin maliyet analizi ve karar destek mekanizmalarında kullanılır.

Finansal açıdan değerlendirme, maliyetin ilgili finans kaynakları ile ilişkilendirilmesi sonucunda Bütçelenebilirlik (Affordability) değerlendirmesinin yapılabilmesini mümkün kılar. Bu sebeple ÖDM hem yönetim hem de mühendislik tarafında, maliyet/bütçe kontrolü ve karar verme mekanizmalarında yol gösterici etkiye sahiptir.

Sistemin elde edilmesi sürecinde, işletme-idame ve elden çıkarma maliyetlerinin azaltılmasına yönelik sorumluluğun yüklenici firmalar tarafından da üstlenilmesi doğal olarak müşterinin/kullanıcının başlıca beklentisidir. Bu beklentinin karşılanmasına yönelik olarak sistem bazında farklı tedarik sözleşme teknikleri uygulanabilir ya da tedarik sözleşmesi içeriğinde teşvik edici ya da yönlendirici isterler tanımlanabilir.

ÖDM analizi, ÖDM’ni oluşturan her bir bileşenin birbirleri ile etkileşiminin tanımlanması, ÖDM değerinin hesaplanması ve niteliğinin belirlenmesine yönelik bir analizdir. ÖDM analizi çıktısı “tahmin” olup hassasiyeti analizde kullanılan girdilerin çeşit ve niteliğine bağlıdır. Sisteme ait ÖDM’nin tahmin edilmesinde 3 ana yaklaşımdan bahsedilebilir:

* Finansal yaklaşım: Projenin belli başlı maliyet unsurlarına (Ar-Ge, satın alma, kullanım ve destek, tesis, personel vb.) ilişkin finansal kısıtlar ve yaklaşımlar ile ek bütçe talepleri ile sisteme ait ÖDM belirlenebilir.
* İş Kırılım Ağacı yaklaşımı: Geliştirilecek ve tesis edilecek sistem unsurlarını tümüyle ve detayları ile ortaya koyabilen iş kırılım ağacının her bir bileşenine ilişkin maliyetlendirmeler ile ÖDM belirlenebilir.
* Ömür Devri Maliyet Kategorileri yaklaşımı: Maliyet kategorileri (DoD 5000.4-M, Cost Analysis Guidance and Procedures):
** Araştırma-Geliştirme
** Yatırım (Üretim)
** Kullanım-Destek
** Envanterden Çıkarma

Maliyetin analiz edilmesi ile ilgili farklı ülkeler ve/veya kullanıcılar; değişik yöntemler, araçlar ve terminolojiler kullanabilir. Kullanılan ve Şekil 6’da birbirleri ile ilişkileri bulunan başlıca konseptler aşağıda yer almaktadır:

1. Ömür Devri Maliyeti (ÖDM) (LCC -Life Cycle Cost)

(ÖDM = Direkt Maliyetler + Endirekt Değişken Maliyetler)

2. Toplam Sahip Olma Maliyeti (TOC-Total Ownership Cost)

(TSOM = ÖDM + Bağlı endirekt Sabit Maliyetler)

3. Bütün Ömür Maliyeti (WLC-Whole Life Cost)

(BÖM = TSOM + Bağlı Olmayan Endirekt Sabit Maliyetler)
[[Dosya:Şekil6 ÖDM, TSOM ve BÖM arasındaki ilişki.jpg|alt=Şekil 6 ÖDM, TSOM ve BÖM arasındaki ilişki|sol|küçükresim|500x500pik|Şekil 6 ÖDM, TSOM ve BÖM arasındaki ilişki]]

ÖDM, ürünün elde edilmesi, kullanım, destek ve envanterden çıkarma ile ilişkili tüm direkt maliyetler ile indirekt-değişken maliyetleri içerir. Direkt maliyette sadece ortaya konulan ürüne yönelik faaliyetler ya da kaynaklar söz konusudur. Birden fazla değişik ürün ile ilişkilendirilebilecek maliyet, ürünler arasında ölçülebilir şekilde paylaştırılıyor ise bu da direkt maliyet olarak kaydedilir. Aksi halde indirekt olarak nitelendirilir. Değişken maliyetler, ürünün karmaşıklığı, parça/bileşen sayısı ve kırılım seviyesine bağlı olarak değişkenlik gösteren maliyetlerdir. Bunun haricindeki indirekt maliyetler ÖDM analizi kapsamına girmez.

BÖM, TSOM ve Bağlı Olmayan Endirekt Sabit Maliyetleri kapsar.

TSOM, ÖDM ve Bağlı İndirekt Sabit Maliyetleri içerir. Sabit maliyetler üründen çok organizasyon ile ilişkili maliyetlerdir ve ürünün varlığından etkilenmezler. Ürünün satın alınması, kullanım, destek ve envanterden çıkarma ile ilişkilendirilebilen kaynak ve faaliyetler bağlı olarak nitelendirilir. Bağlı olmayan indirekt sabit maliyetler; ürünün satın alınması, kullanımı, desteği ve envanterden çıkarılması ile ilişkilendirilemeyen faaliyetler sonucunda ortaya çıkan maliyetlerdir.

Projenin her aşamasında aynı detayda ve doğrulukta ÖDM analizi yürütülemez. İş geliştirme safhasında, stratejik yaklaşımları yönlendirebilecek detayda maliyet analizleri yapılabilir. Projenin erken aşamalarında, müşteri gereksinimlerinin karşılanmasına yönelik alternatif çözümlerin ekonomik ve finansal değerlendirilmesinde kullanılacak ÖDM, öngörülen sistem karakteristiklerine dayanarak geliştirilir. Çözüm alternatifinin seçilmesini takiben, Tablo 5’te örneği sunulan, çözüme ait ÖDM bileşenleri tablosu detaylandırılarak sistem karakteristiklerine dayanarak doldurulur. Faaliyetler, Tabloda belirtilenlerle sınırlı değildir.

'''Tablo 5 ÖDM Bileşenleri'''
{| class="wikitable"
| rowspan="3" |'''FAALİYETLER'''
| colspan="3" |'''MALİYETLER'''
|-
| colspan="2" | '''SİSTEM'''

''Kullanım/Bakım Konsepti''
|'''PROJE'''
|-
|'''Odak Sistem'''
|'''Destek Sistemi'''
|'''Özel'''
|-
|''Proje Yönetim''
|
|
|
|-
|''Bilgi''
|
|
|
|-
|''Analiz''
|
|
|
|-
|''Simülasyon''
|
|
|
|-
|''Mühendislik''
|
|
|
|-
|''Satın alma''
|
|
|
|-
|''Üretim''
|
|
|
|-
|''Entegrasyon''
|
|
|
|-
|''Test, Deneme, İşlevsel Gösterim''
|
|
|
|-
|''Paketleme''
|
|
|
|-
|''Elleçleme''
|
|
|
|-
|''Depolama''
|
|
|
|-
|''Nakliye (Ulaştırma)''
|
|
|
|-
|''Montaj''
|
|
|
|-
|''Eğitim''
|
|
|
|-
|''Kullanıcı Dokümanları''
|
|
|
|-
|''Kullanım''
|
|
|
|-
|''Bakım''
|
|
|
|-
|''İkmal''
|
|
|
|-
|''Envanterden Çıkarma''
|
|
|
|}

= 3. ENTEGRE LOJİSTİK DESTEK (ELD) =
ELD, karmaşık savunma sistemlerine sahip olmanın beraberinde getirdiği lojistik destek sorunların çözümü için geliştirilen bir metodolojidir. Bu alanda yaşanan başlıca sorun, bu tür sistemleri edinmenin ve hazır bulundurmanın yüksek maliyetidir. Sahip olma maliyeti yükseldikçe, performans ve maliyet arasındaki ilişki daha fazla sorgulanır hale gelir. Ayrıca; ileri teknoloji seviyesi, yüksek hareket kabiliyeti gibi özellikler ilave yeteneklere sahip olmayı gerektirirken geliştirme sürelerinin uzunluğu, tam harekât yeteneğinin kazanılması için geçen zaman ve sistemin planlanan ömrü sistemlerin sürdürülebilir olmasını gerekli kılar.

ELD farklı kaynaklarda benzer biçimde tanımlanır:

ASD SX000i’deki tanımlamaya göre ELD; “Lojistik faaliyetlerin (örneğin, desteklenebilirlik ve savunma sistemlerine/platformlarına –donanım veya yazılım- ait lojistik destek konularının) ve lojistik destek elemanlarının, zamanında ve maliyet etkin biçimde planlandığı, tedarik edildiği, uygulandığı, test edildiği ve sağlandığı idari ve teknik süreçtir”.

NATO Logistics Handbook 2012’de ELD; “Program/Projenin başlangıç sürecinde, sistem/malzemenin lojistik destek konularının titizlikle değerlendirilerek sistem ömür devri yönetimine dahil edilmesidir” şeklinde tarif edilmektedir. ELD için NATO müttefiklerinin hedefleri ile uyumlu olarak hazırlanmış olan ALP-10 rehberine göre; harekâta hazır bulunuşluğu sağlamak için gerekli tüm finansal ve diğer kaynaklar, performans hedeflerini elde etme ve zamanında teslim için gerekli kaynaklar kadar önemlidir. Bu rehberde ELD “sistem çözümüne ilişkin desteklenebilirlik hususlarının, sistem ömür devrinin erken safhalarından itibaren sürece entegre edildiği ve maliyet etkin bir şekilde destek unsurlarının planlandığı teknik süreç” şeklinde ifade edilir.

Amerikan Savunma Bakanlığı Direktifi 5000.39 ve MIL-STD-1369-A’daki ELD tanımı ise; “Aşağıda listelenmiş amaçlara erişmek için kontrollü, bütünleşik ve iteratif biçimde gerçekleştirilen idari ve teknik faaliyetler bütünüdür:

* Destek ihtiyaçlarının sistem ve ekipman tasarımına entegrasyonu,
* Destek ihtiyaçlarının, hazır olma ve tasarım amaçları ile uyumlu ve herbiri ile etkileşim içinde belirlenmesi,
* Gerekli desteği temin etmek,
* Kullanım safhasında ihtiyaç duyulan desteği en düşük maliyetle sunmak.

Blanchard, B.S. “Logistics Engineering and Management” isimli kitabında ELD’yi “sistemin nihai kullanıcısının sadece performans ihtiyacını değil, ürünün planlanmış ömrü boyunca hızlı ve ekonomik biçimde desteklenmesini de temin etmeye yardımcı olacak ilk planlama, bütçeleme ve kontrolleri sağlayan bir yönetim fonksiyonudur. ELD’nin ana hedefi, desteğin farklı elemanlarının (örneğin, test ve destek ekipmanları, yedek parça/onarım malzemeleri, gibi) bir araya getirilmesinin teminidir” şeklinde tanımlar.

Jones, J.V., “Integrated Logistics Support Handbook” isimli kitabında ELD’yi “önceden belirlenmiş ve ölçülebilir hedeflere, kabul edilebilir sahip olma maliyeti içinde ulaşılması amacıyla, desteklenebilir sistem tasarımı ve uygun destek kabiliyetini elde etmek için ihtiyaç duyulan faaliyetlerin kontrollü ve bütünleşik yönetimidir” şeklinde tanımlar. Bahse konu kitapta ayrıca; ELD faaliyetleri ile:

* Sistemler için ihtiyaç duyulan lojistik desteğe yönelik tasarıma etkide bulunulmasının,
* Sistemin hazır olma durumu hedefleri ile bu hedeflere katkıda bulunan destek gereksinimlerinin belirlenmesi ve geliştirilmesinin,
* Gerekli lojistik desteğin planlanması ve temin edilmesinin,
* İhtiyaç duyulan desteğin en az maliyetle sağlanmasının amaçlandığı belirtilmiştir.

Tanımlardan anlaşılacağı üzere; ihtiyaçların tespit edildiği ve sistemin geliştirildiği süreçte, kullanım, destek ve envanterden çıkarma safhalarında sistemin ihtiyaç duyacağı lojistik desteğin ve destek maliyetlerinin tanımlanması ve maliyet-performans dengesinin sağlanmasına yönelik tasarım faaliyetlerinde bulunulması, ELD metodolojisinin dayandığı temel husustur. Performans ile maliyet arasındaki ilişkinin doğrusal olmaması, bu kapsamdaki çalışmaların uzman ekip tarafından sistematik biçimde ve titizlikle yürütülmesini gerekli kılar. Bununla birlikte; karmaşık sistemlerin geliştirilme süreleri ile fiilen kullanılması arasında geçen sürelerin uzunluğu sebebiyle, ihtiyaç belirleme ve geliştirme safhalarında verilen kararların sonuçları belki de yıllar sonra görülebilir. Bu sebeple, lojistik mühendislerinin sistem ömür devrinin erken safhalarından itibaren aktif rol alması kritik derecede önemlidir. Tanımlanan performansın ömür devri boyunca maliyet etkin biçimde sağlanması taahhüt edildiğinden, lojistik mühendislerinin sorumluluğu ömür devrinin kalan safhalarında da devam edecektir.

ELD’nin başlangıç sorumluluğu, ihtiyaç belirleme ve tanımlama aşamalarında ihtiyaç makamları, kullanıcılar ve idame makamlarındadır. Tedarik makamları Teklife Çağrı Dokümanı (TÇD) ile birlikte başlangıç seviyesindeki ELD Planını (ELDP) yayımlar. Tedarik sözleşmesi ile yüklenici ELD isterlerine uygun şekilde ELDP’yi hazırlar. ELDP’nin hazırlanmasında ihtiyaç makamı, kullanıcı, idame makamı ve tadarik makamı gerekli girdi ve kontrolleri sağlar. ELD faaliyetleri ve ELDP hazırlanması çalışmaları ELD programı çerçevesinde yürütülür. ELD programı, en uygun destek gereksinimlerinin yanında bu gereksinimleri karşılayacak tasarımın ortaya konulmasını hedefler. En uygun çözümün elde edilebilmesi, kapsamlı sistem ve lojistik mühendisliği yöntemleri ve prosedürlerinin uygulanması ile mümkün olur. Süreç, ömür devri ve sistem seviyesi hedefleri ortaya koyan, bu hedeflere erişmek için belirsizliği yöneten ve gerektiği durumlarda kendini adapte eden yenilikçi ve tekrar eden yönetim anlayışı ile yönlendirilir.

Hem kullanıcı (ihtiyaç sahibi) hem de yüklenici tarafında ELD faaliyetlerini yönetip yürütecek organizasyonlar ve süreçler mevcut ve tanımlı olmalıdır. ELD kendi içinde farklı özelliklerde ve birbirinden nispeten bağımsız birçok disiplini (ELD elemanları) bir arada kullanmayı gerektirir. ELD programı, sistem mühendisliği sürecinin bütünleşik bir parçası olarak, kullanıcının, yüklenicinin ve alt yükleniciler ile tedarikçi organizasyonlarının ilgili unsurlarını kapsayan karmaşık bir destek organizasyonunun faaliyetlerini koordine eder. Kullanıcı ve yüklenici organizasyonları içinde, ELD elemanlarını yönetecek ve yürütecek uzman kişiler bulunmalıdır. ELD faaliyetlerini organizasyon içinde ve organizasyonlar arasında koordine etmek ve yönetmek, organizasyonel yapı ve süreçlerin yanı sıra ELD elemanlarına da tam olarak hâkim olmayı gerektirir.

ELD faaliyetleri [https://tssodypwiki.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)’]de belirlenen sistem ömür devri yönetimi modeli esas alınarak yapılandırılmıştır. Bu model, ihtiyaç belirleme ve ihtiyaç tanımlama aşamalarından oluşan ön konsept safhası ile başlayıp envanterden çıkarma safhasını da içine alan ömür devrinin tamamını resmeder. ELD, ön konsept safhasında başlayıp sistemin ömür devri boyunca devam edecek olan lojistik desteğin planlanmasına ve sağlanmasına ilişkin faaliyetler bütünüdür. Erken aşamalarda amaç desteklenebilirlik kapsamında sistem tasarımı üzerinde bir etkiye sahip olunması ve destek ihtiyaçlarının belirlenmesidir. Sonraki aşamalarda ise destek unsurlarının (ELD elemanlarının) tasarlanması, üretimi/temini/teslimi/ifası ve kullanım yerinde hazır bulundurulmasıdır. Ana fonksiyonu itibarıyla geliştirme safhasındaki tasarım aşamalarında yürütülen sistem mühendisliği, sistem ömür devrinin tamamına etki eden ana unsurdur. Bu nedenle; desteklenebilirlik ve destek unsurlarının tespiti ve geliştirilmesi gibi bazı faaliyetlerin, sistem tasarımı belirli bir olgunluk seviyesine gelinceye kadar ELD ve sistem mühendisliği çalışmaları arasında yinelemeli (iteratif) olarak icra edilmesi gerekmektedir. ELD’nin hedeflenen başarıya erişmesinde kullanılan en temel araç Lojistik Destek Analizleri (LDA)’dır. LDA; sistem geliştirme sürecinde destek gereksinimlerinin tanımlanması, analiz edilmesi ve somut hale getirilmesi faaliyetlerini içeren ve desteklenebilirlik anlamında tasarımın etkilenmesini hedefleyen bir analizdir. Tasarım olgunlaşarak netleştikçe, LDA faaliyetleri destek gereksinimleri kapsamında ihtiyaçların/kaynakların detaylandırılmasına ve gerekli verinin sağlanmasına odaklanır. Kullanım ve destek safhalarında ise planlamalara karşılık gerçekleşmeleri izlemek amacıyla kullanım ve bakım verisi geri bildirimlerinin sağlanması esastır. Tasarıma geri bildirim sağlayacak servis ekiplerinin ve idamede görev alan personel/kuruluşların girdileri ışığında saha koşulları altında desteklenebilirlik parametrelerinin değerlendirilmesi LDA sürecinin önemli bileşenlerindendir.

ELD en genel hali ile “savunma ve güvenlik sistemlerinin toplam ÖDM’yi en düşük seviyede tutabilmek ve bu sistemleri etkin ve verimli bir şekilde idame edebilmek maksadıyla kullanım ve destek safhasındaki ihtiyaçların tedarik döneminde bütünleşik bir şekilde ele alınmasını sağlayacak yönetimsel ve teknik bakış açısı” olarak tanımlanmaktadır.

Mühendislik/endüstriyel bakış açısı ile ELD “son kullanıcıya ömür devri boyunca desteklenebilir bir sistem teslim edebilmek maksadıyla, sistemin tasarım sürecinin maliyet, planlama ve kontrol açılarından bütünleşik olarak ele alınması” veya “en az maliyetle işletilebilecek bir destek sisteminin yaratılabilmesi maksadıyla, tüm lojistik ihtiyaçları ve disiplinleri bütünleşik bir şekilde yönetme fonksiyonu” şeklinde tanımlanabilir.

== 3.1. ELD’NİN TARİHÇESİ ==
ELD kavramı, 2. Dünya Savaşı sonrasında yaşanan soğuk savaş dönemi ile askerî alanda hayat bulmuş ve gelişmiş bir kavramdır. Yüksek teknolojiye sahip, karmaşık yapıdaki silah sistemlerinin hazır bulunuşluk maliyetlerinin yüksekliği 1960’lı yıllarda tecrübe edilmeye başlayınca çözüm üretilmesi ihtiyacı doğmuştur. Bulunan çözüm oldukça basittir; silah ve destek sistemlerinin kullanım ve idame dönemi maliyetlerini en aza indirecek şekilde tasarlanması. Bir başka deyişle “sonrasını baştan düşünmek”. ELD yaklaşımı ve ilk uygulamalar ABD Savunma Bakanlığı’nın 19 Haziran 1964 tarihli “Sistemler ve Teçhizat için ELD’nin Geliştirilmesi Direktifi” ile başlamıştır. Bu direktifte ELD, “sistemlerin bütün bakım ve onarım seviyelerinde desteklenmesi” olarak ifade edilmiştir. Zaman içinde ELD’nin askerî ve mühendislik/endüstriyel bakış açıları ile farklı tanımlamaları ortaya çıkmıştır.

ELD’nin başlangıçtaki hedefleri;

* Maliyet ekin biçimde bakım faaliyeti yürütülerek yüksek hazır bulunuşluğun elde edilmesi,
* Güvenilir ve idame edilebilir sistem tasarımı,
* Sistem kullanıma alınmadan önce ihtiyaç duyulan destek kaynaklarının hazır bulundurulması ve
* Lojistik destek için gerekli kaynaklar için ihtiyaç duyulan bütçenin planlanması başlıkları altında toplanmıştır.

1980’lere gelindiğinde ELD hedefleri değişim geçirerek;

* Lojistik hususların tasarım safhasından itibaren dikkate alınarak lojistik destek sağlanmasına ilişkin isterler çerçevesinde tasarıma etki edilerek savunma sisteminin desteklenebilirliğinin arttırılması,
* Bağımsız lojistik elemanların tamamının birlikte tedariki ve yönetimi ile daha etkin bir lojistik destek sağlanması şekline dönüşmüştür.

ELD elemanlarının bütünleşik ve ortak hedefe yönelecek biçimde yönetimi bütçe, kaynak ve yetenek israfının olmadığı bir destek sisteminin elde edilmesini sağlar. ELD elemanların her biri kendi içinde bağımsız ve farklı disiplinlere sahip olmasına rağmen esas olan ELD disiplini içinde bütün elemanların bütünleşik bir yapıda yönetilmesidir. Terminolojik olarak lojistik kavramının genişliği ve derinliğinden kaynaklanan kavram kargaşasını ortadan kaldırmak için ELD yerine bazı ülkelerin ve kurumların yayınlarında Entegre Ürün Desteği ve ELD Elemanları yerine Entegre Ürün Desteği Elemanları ifadeleri kullanılmaya başlanmıştır. Aynı şekilde, NATO bünyesinde ELD yerine Entegre Ömür Devri Desteği kavramının kullanılması yönünde bir eğilim bulunmaktadır. Ancak, halen ELD kavramı birçok ülkede ve ülkemizde yaygın şekilde kullanılmaktadır.

Terminolojideki değişimlere rağmen en üst seviyede sistemin kullanıma/göreve hazır olmasının en az maliyetle elde edilmesi temel prensibi her zaman geçerliliğini korumaktadır.

ELD yaklaşımı ile birlikte, lojistik disiplinler olarak da ifade edilebilecek ELD elemanları [bakım, ikmal desteği, iş gücü ve personel, destek ve test ekipmanları, tasarıma etki/tasarım etkileşimi, teknik veri ve dokümantasyon, eğitim ve eğitim desteği, tesisler ve altyapı, PEDU (paketleme, elleçleme, depolama ve ulaştırma), bilgisayar kaynakları, idame mühendisliği, ürün destek yönetimi] arasındaki entegrasyona odaklanılmış ve en iyi değer yaratma konusundaki çabalar bir disiplin altında toplanmıştır.

Ülkemizdeki uygulamalara bakıldığında, ihtiyaç makamlarının ELD konusundaki faaliyetlerini hazırlamış oldukları yönergeler vasıtasıyla proje faaliyetlerinin ayrılmaz bir parçası olarak yürüttükleri görülmektedir. Buna paralel olarak, Savunma Sanayii Başkanlığı (SSB) tarafından imzalanan sözleşmelerde başlangıcından itibaren ELD’ye ilişkin hususlar yer almakla birlikte 2005 yılında standart sözleşme metinlerinin hazırlanması ve uygulamaya konulması sonucunda, ELD’ye ilişkin hususlarda anlayış ve uygulama birliği sağlanmıştır. Sistem ömür devri yönetimi ilke ve uygulamalarının daha iyi anlaşılabilmesi amacıyla 2009, 2012 ve 2017 yıllarında SSB tarafından geniş katılımlı konferanslar düzenlenmiştir. TSSÖDYP’nin temellerini oluşturan Entegre Lojistik Destek Platformu çalışmaları da 2011 yılında gerçekleştirilerek sistem ömür devri yönetimi yaklaşımının fikri altyapısı oluşturulmuştur. İhtiyaç makamları, kullanıcılar, idame makamları ve tedarik makamları tarafından savunma ve güvenlik sistemlerinin ömür devri yönetiminde kilit rol oynayan ELD disiplinine ilişkin gelişmelerin ve yeni bakış açılarının iyileştirme faaliyetleri kapsamında uygulama alanına aktarılması çalışmalarına ülkemizde artan bir hızla devam edilmektedir.

== 3.2. ELD’NİN AMACI ==
ELD’nin başlıca hedeflerinden birisi de ürünlerin operasyonel kullanım süresini arttırırken destek ihtiyacını en az düzeye indirmektir. Böylece ürün ömür devri boyunca daha yüksek kazanımlara ulaşılarak finansal fayda elde edilmesi sağlanır. ELD, ürünün desteklenebilirliğinin tasarım aşamasında göz önünde bulundurulması için sistem mühendisliği çalışmalarına geri bildirimde bulunmak suretiyle ürün ile ilgili desteklenebilirlik gereksinimlerini belirler ve müşterinin ihtiyacı olan teknik desteği asgari maliyet ile yerine getirmeyi amaçlar. Bu nedenle ELD, sistem tasarımının başlangıcından itibaren, mühendislik çalışmalarının ayrılmaz bir parçasıdır. ELD mühendisleri, sistem ve tasarım mühendisleri ile birlikte çalışarak desteklenebilirliğin, tasarım çalışmaları süresince göz önünde bulundurulmasını sağlar.

Bu amaca yönelik olarak aşağıdaki temel faaliyetler gerçekleştirilir:

* En uygun kullanıma/göreve hazır bulunuşluk oranını en az maliyetle gerçekleştirecek ürün tasarımına ulaşılması,
* Kullanım, bakım, eğitim vb. lojistik destek kapsamındaki görevlerin eksiksiz olarak yerine getirilmesi,
* Ürünün görev yapacağı harekât ortamında ve görev profillerinde en uygun performans ve hazır bulunuşluğunun temini için ihtiyaç duyulan tüm destek kaynaklarının tasarımı, geliştirilmesi, bütçelenmesi ve doğrulanmasına yönelik desteğin planlanması ve geliştirilmesi,
* Ürünü desteklemek için gerekli unsurların sağlanması,
* Destek çözümünün fiziksel unsurlarının ihtiyaç duyulan yer ve zamanda hazır bulundurulması,
* Ürün ömür devrinin başından envanterden çıkarma safhasının sonuna kadar desteklenebilirlik çalışmalarının yürütülmesi ve lojistik desteğin sağlanması,
* Destek çözümünün fiziksel unsurlarının, harekât/operasyon gereksinimlerindeki değişimler ve teknolojik gelişmelere uyum sağlayacak biçimde güncellenmesi.

== 3.3. SİSTEM ÖMÜR DEVRİ VE ELD ==
Sistem ömür devrinin planlanmasında ve yönetiminde [https://tssodypwiki.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)] ve [https://tssodypwiki.ssb.gov.tr/index.php/Sistem_%C3%96m%C3%BCr_Devri_Y%C3%B6netimi_S%C3%BCre%C3%A7leri_Rehberi TSSÖDYP-02 Sistem Ömür Devri Yönetimi Süreçleri Rehberleri] referans olarak kullanılır.

ELD; savunma ve güvenlik sistemlerinin tanımlanması, tasarımı, geliştirilmesi, üretimi, temini, konuşlandırılması, kullanımı, desteklenmesi ve envanterden çıkarılması faaliyetlerini maliyet etkin olarak planlayan ve bu planın uygulanmasını sağlayan tüm idari ve teknik aktivitelerin gerçekleştirildiği bir yönetim organizasyonudur.

Sistem ömür devrinin her bir safhasındaki ELD faaliyetleri, içinde bulunulan safhaya göre farklılık göstermektedir. Söz konusu faaliyetler sistem isterlerine, proje tipine, tedarik yöntemine, tedarik kaynağına göre farklılık gösterebilir ve faaliyetlerin tamamına her sistem için ihtiyaç duyulmayabilir. Tüm safhalarda yürütülecek faaliyetlerin yürürlükteki mevzuata uygun biçimde insan veya çevreye zarar vermeyecek şekilde yürütülmesi esastır.

Ön konsept safhasında desteklenebilirlik kapsamı ve hedefleri belirlenir. İhtiyacın tanımlandığı bu safhada, destek kapsamının şekillendirilmesi ve temel isterlerin tespit edilmesi beklenir. Destek kapsamı, ilerleyen ömür devri safhalarında yürütülecek destek faaliyetlerine yön verecek ve ilgili isterlerin belirlenmesinde etkin olacak stratejiyi ortaya koyar.

Konsept safhasında gerçekleştirilen ELD faaliyetleri;

* Kısıtlar göz önünde bulundurularak destek kaynaklarının belirlenmesi,
* Proje gruplarına lojistik uzmanlarının dahil edilmesi veya lojistik çalışma grupları oluşturulması,
* Sistem çözümlerinin güvenilirlik, idame edilebilirlik ve kullanım destek düzenlemeleri açısından değerlendirilmesi,
* Sistem çözümleri için gereken lojistik destek kapsamının her bir ELD elemanı bazında belirlenmesi,
* Lojistik ile ilgili standardizasyon isterlerinin belirlenmesi,
* Güvenilirlik, Kullanılabilirlik, İdame Edilebilirlik, Desteklenebilirlik ve Test Edilebilirlik parametreleri için hedeflerin belirlenmesi,
* Lojistik destek kilometre taşlarının belirlenmesi,
* Sistem çözümleri için başlangıç ömür devri maliyetlerinin analiz edilmesi, lojistik planların gerçekleşmesinde amaçlanan lojistik faaliyetlerin hazırlığı için kullanılacak fonların tanımlanması,
* Lojistik gereksinimlerin iş tanımına, şartnameye, teklife çağrı dokümanına, seçim değerlendirme kriteri ve sözleşmelere dahil olması..

Geliştirme safhasında gerçekleştirilen ELD faaliyetleri;

* Desteklenebilirlik ve sürdürülebilirliğin sağlanmasına yönelik tasarımı etkileme faaliyetlerinin yürütülmesi,
* Güvenilirlik, Kullanılabilirlik, İdame Edilebilirlik, Desteklenebilirlik ve Test Edilebilirlik parametreleri için hedeflerin gerçekleştirildiğinin mümkün olduğunca test edilerek ve ölçülerek doğrulanması,
* Destek elemanlarının geliştirilmesi, tedariki, üretimi ve hazır edilmesinin takvime uygun olarak sağlanması,
* Kullanım safhasının başlangıcındaki lojistik planlarının finansmanının sağlanması,
* Planlanan lojistik desteğin yürütüldüğünü ve operasyonel hedeflerin karşılandığını test edip ölçülerek, hedefleri doğrulamaya yönelik planlama yapılması,
* Kullanım safhasında sistemin desteğini sağlayacak organizasyonun teşkil edilmesi,
* Bakım Planı geliştirilmesi.

Üretim Safhasında gerçekleştirilen ELD faaliyetleri;

* Ürünlerin tasarım, kullanıma/göreve hazır bulunma ve desteklenebilirlik isterlerinin karşılaması,
* Konuşlandırma gereksinimlerini karşılamak üzere ELD elemanlarının temin/ifa edilmiş olması, lojistik desteğe ilişkin düzenlemelerinin kullanım safhası başlamadan önce tamamlanması,
* Desteklenebilirliği etkileyecek tüm unsurların takvime uygun olarak hazır bulundurulmasının sağlanması,
* Odak sistem ile birlikte ELD kapsamındaki teslimat kalemlerinin (teknik yayınlar, destek ve test ekipmanları, başlangıç yedekleri, destek yazılımı lisansları, gerekli insan gücü, tesisler vb.) hazır olduklarının doğrulanması,
* Bakım planlarının güncellenmesi, kullanıcıya sistemin ve teknik özelliklerinin açıklamaları ile teslim edilmesi.

Kullanım safhasında gerçekleştirilen ELD faaliyetleri;

* ELD organizasyonunun sürekliliğini sağlayacak finansal ve yönetsel kaynakların düzenlenmesi,
* En iyi işlevselliği sağlamak için ELD yönetim sisteminin gerektirdiği periyodik gözden geçirmelerin gerçekleştirilmesi,
* Desteklenebilirlik gereksinimleri ve talep edilen değişikliklerin ÖDM’ye etkisinin belirlenmesi,
* Sistemin kullanım safhasındaki performasına ait geri bildirimler ile bakım/onarım verilerinin toplanması ve kayıt altına alınaması,
* Lojistik desteğin planlanan ve gerçekleşen faaliyetler olarak ayrı ayrı analiz edilerek değerlendirilmesi ve gerekli görülen alanlarda iyileştirme yapılması,
* Sistemdeki eksikler ile güncelleme/iyileştirme ihtiyaçlarının tanımlanması ve modifikasyon kararları öncesinde tasarım ve destek arasındaki ödünleşimlerinin değerlendirilmesi,
* ELD elemanlarının değişen şartlara uyumlandırılması sağlanması.

Destek safhasında gerçekleştirilen ELD faaliyetleri destek planlama ve destek uygulama aşamaları olmak üzere iki aşamada yürütülür. Ön konsept, konsept, geliştirme ve üretim safhalarında desteklenebilirliğe ve lojistik destek planlamalarına ilişkin yürütülen faaliyetler destek planlama aşaması içindedir. Kullanım ve envanterden çıkarma safhalarında yürütülen lojistik destek faaliyetleri ise destek uygulama aşaması kapsamındadır.

Envanterden çıkarma safhasında gerçekleştirilen ELD faaliyetleri;

* Envanterden Çıkarma Planı’na uyumlu olarak kullanım safhasındaki gerekli destek faaliyetlerinin sonlandırılması,
* Envanterden çıkarma safhasındaki sistem için uygulanabilir ELD elemanlarının analiz edilmesi ve uygulaması için ELDP’de dokümante edilmesi,
* Sisteme ait ELD verilerinin gelecekte kullanılabilmesi için uygun şekilde arşivlenmesi,
* Envanterden çıkarılan donanımların tekrar kullanımının, uygun şekilde hurdaya ayrılmasının veya yeniden dönüşümünün değerlendirilmesi.

== 3.4. ÖMÜR DEVRİ MALİYETİ VE ELD ==
Ömür devrinin erken aşamaları, ÖDM’ye etki eden en önemli kararların verildiği dönemdir. Çoğu zaman; sistem tasarımının sonuna gelindiğinde, sistem ÖDM’nin yaklaşık %85’i bu dönem içinde veya öncesinde alınan tasarıma ve lojistik desteğe ilişkin kararlar ile belirlenmiş olur. Ömür devrinin ilk dönemlerinde ömür devri maliyet analizi istenilen seviyede performans sağlamak amacıyla seçilen tasarım alternatiflerinin maliyete olan etkilerini belirlemek üzerine yoğunlaşır.

ÖDM’nin yaklaşık %60 ila %80’i,kullanım safhasındaki faaliyetler ve idame gereksinimlerinin karşılanması sonucunda ortaya çıkmaktadır. Bu sebeple, destek ve bakım konseptlerinin mümkün olan en erken safhada, özellikle tasarımla etkileşim içinde belirlenmesi kritik derecede önemlidir.

== 3.5. ELD ORGANİZASYONU VE SÜREÇLERİ ==
Sistem ömür devri yönetimi kapsamında; ELD faaliyetlerinin planlanması, yürütülmesi ve kontrol edilmesi için ön konsept safhasında ihtiyaç makamı/kullanıcı bünyesinde ilgili paydaşların yer aldığı bir ELD Ön Çalışma Grubu oluşturulması önerilir. Bu grup tarafından sisteme ilişkin temel lojistik ihtiyaçlar ve isterler belirlenir, belirlenen isterler Proje/İhtiyaç Tanımlama Dokümanında belirtilir.

Konsept safhasında tedarik makamı tarafından ihtiyaç makamı/kullanıcı ve idame makamı temsilcileri ile ilgili diğer paydaşların yer alacağı bir ELD Çalışma Grubu oluşturulur. Ön konsept safhasında ELD Ön Çalışma Grubu tarafından yapılmış olan çalışmalar, ELD Çalışma Grubunca ihtiyaç duyulan ilk girdileri sağlar. Yürütülecek fizibilite çalışmaları ile ELD Çalışma Grubu tarafından sanayiinin ELD konusundaki girdileri alınır. Geliştirme safhasında ELD Çalışma Grubuna yüklenici firma temsilcileri de dâhil edilerek üretim ve kullanım safhalarında grubun sürekliliği sağlanır.

ELD Ön Çalışma Grubunun görev ve sorumlulukları;

Ön Konsept safhasında (Destek Planlama Aşaması);

* Sistem ve ELD elemanları ile ilgili ihtiyaçların/isterlerin belirlenmesi,
* Belirlenen isterlere göre Proje/İhtiyaç Tanımlama Dokümanına girdi sağlanması

ELD Çalışma Grubunun görev ve sorumlulukları;

Konsept safhasında (Destek Planlama Aşaması);

* Proje yönetim sürecinde yapılacak ELD yönetim stratejisinin oluşturulması,
* ELD faaliyetlerinin planlanması ve ELDP kapsamının hazırlanması,
* LDA faaliyetleri ile hazırlanacak rapor ve planların kapsamının belirlenmesi,
* Tasarım faaliyetlerinde kullanılacak standartlar ve yazılım alt yapısının belirlenmesi,
* Desteklenebilirlik ve lojistik destek sağlanmasına ilişkin yüklenici/teklif değerlendirme kriterlerinin hazırlanması,
* Sistem tasarımına yönelik ELD gereksinimleri ile ilgili girdilerin yapılması,
* ELD isterlerinin nihai hale getirilmesi ve TÇD’de yer almasının sağlanması.

Geliştirme ve üretim safhalarında (Destek Planlama Aşaması);

* Tasarım kapsamında yapılan faaliyetlerin incelenmesi ve değerlendirilmesi maksadıyla düzenli aralıklarla ELD gözden geçirme toplantıları yapılması,
* Sistem kalifikasyon test sonuçlarının lojistik gereksinimler açısından uygunluğunun kontrol edilmesi,
* Hazırlanan analiz raporları ve ELDP’nin uygunluğunun incelenmesi,
* ELD elemanlarına ilişkin kapsamın uygunluğu ve yeterliliğinin kontrol edilmesi,
* Prototip sistemlerin test ve kabul muayenelerinde lojistik hususlar kapsamında görev alınması,
* Üretim sürecinde ELD ile ilgili faaliyetlerin takip ve kontrol edilmesi,
* Sistemin konuşlandırılması aşamasında, kullanım ve destek faaliyetlerinin uygunluğu ve yeterliliğinin kontrol edilmesi, değerlendirilmesi, ihtiyaç durumunda düzeltici önlemler alınması,
* Projenin özelliğine göre ELD teslimatlarının yapılmasının sağlanması,

Kullanım safhasında (Destek Uygulama Aşaması);

* ELD teslimatlarının yapılmasının sağlanması,
* Sistem kullanım ve lojistik destek verilerinin değerlendirilmesi;
* Kullanım ve lojistik destek verileri kullanılarak sistemin güvenilirlik, hazır bulunuşluk, bakım yapılabilirlik, desteklenebilirlik vb. hususlarına ilişkin analizlerin yapılması,
* Analiz sonuçları ile sistem tasarım verileri ve kullanıcı isterlerinin karşılaştırılması,
* İhtiyaç durumunda düzeltici önlemler alınması,
* Lojistik destek faaliyetlerinin (bakım, onarım, malzeme tedariki, depolama, ulaştırma vb.) ELDP ve ilgili diğer dokümantasyona göre yürütülmesi,
* Sistemin kullanım ömrü ve ÖDM’nin sürekli olarak kontrol edilmesi,
* Sistem ömür devri verileri ve LDA sonuçlarına göre sistem üzerinde gerekli düzeltici faaliyetlerin yapılması veya sistemin envanterden çıkartılması.

== 3.6. ELD ELEMANLARI ==
ELD, bir ürünün desteklenebilirliği ve ömür devri maliyetlerini optimize edecek destek çözümünü geliştirmek için ihtiyaç duyulan lojistik destek unsurlarının tam olarak anlaşılması ve optimum lojistik destek hedefine erişmek amacı ile bütünleşik biçimde yönetilmesi esasına dayanır.

Bu fonksiyonlar, ELD elemanları olarak adlandırılan on iki kategori altında gruplanır:

* Bakım
* İkmal Desteği
* İş gücü ve Personel
* Destek ve Test Ekipmanları
* Tasarıma Etki/Tasarım Etkileşimi
* Teknik Veri ve Dokümantasyon
* Eğitim ve Eğitim Desteği
* Tesisler ve Altyapı
* Paketleme, Elleçleme, Depolama, Ulaştırma (PEDU)
* Bilgisayar Kaynakları
* İdame Mühendisliği
* Ürün Destek Yönetimi
[[Dosya:Şekil7 ELED Elemanları İle Optimum Lojistik Destek İlişkisi.jpg|alt=|sol|küçükresim|650x650pik|Şekil 7 ELD Elemanları ile Optimum Lojistik Destek İlişkisi]]

=== 3.6.1. BAKIM ===
Ürün ömür devri boyunca uygulanacak bakım konseptlerini ve gereksinimleri içerir. Bu ELD elemanının, diğer lojistik destek elemanlarının planlanması, geliştirilmesi ve tedarikinde büyük etkisi vardır.

Bakım elemanının amacı, olabilecek en iyi ekipman/kabiliyet kombinasyonunu mümkün olan en düşük maliyette sağlayabilmek için bakım konsepti ve gereksinimlerini belirlemek, planlamak, kaynak sağlamak, uygulamak ve bakım için gerekli faaliyetleri gerçekleştirmektedir.
[[Dosya:Şekil 8 Bakım Faaliyetleri.png|alt=Şekil 8 Bakım Faaliyetleri|sol|küçükresim|600x600pik|Şekil 8 Bakım Faaliyetleri]]

Sistemin ömür devri boyunca kendisinden beklenen yetenekleri ve hizmetleri yerine getirmesi ve kullanım sürdürülebilirliğini sağlaması maksadıyla Şekil 8’de verilen önleyici ve düzeltici bakım faaliyetleri yürütülür.

Önleyici bakım faaliyetleri, planlı bakım faaliyetleri olup sistemde arıza meydana gelmeden önce arızanın önlenmesi maksadıyla yürütülen planlı/periyodik bakım faaliyetleridir. Önleyici bakım faaliyetleri kapsamında arızalar meydana gelmeden önce alınacak tedbirlerin belirlenmesine ve uygulanmasına yönelik analizlerin düzenli olarak yapılması da sağlanmalıdır.

Düzeltici bakım faaliyetleri, plansız bakım faaliyetleri olup sistemde arıza meydana geldiğinde yürütülecek onarım/tamir işlemleridir. Plansız bakımlar arızanın tespit edilmesi, arızanın giderilmesi, özel durumlarda arıza onarımı/tamiri sonrası gerçekleştirilmesi gereken kontrollerin yapılması faaliyetlerini içerir. Düzeltici bakım faaliyetlerine ilişkin sonuçların/verilerin analiz edilerek arıza oluşma sıklıklarına ve periyotlarına göre önleyici bakım faaliyeti kapsamına alınabilecek faaliyetlerin belirlenmesini ve bu kapsama alınmasını sağlayacak bir mekanizma kurulması bakım etkinliğinin artılması açısından önemli bir çalışmadır.

Bakımın planlanması ve yürütülmesi kapsamında aşağıdaki faaliyetler gerçekleştirilir.

'''Bakım konseptinin geliştirilmesi'''

Bakım konsepti, ELDP ve destek konsepti kullanılarak geliştirilir.

'''Bakım Onarım Seviyesi Analizi (LORA)'''

Sözleşme ve ekleri, tasarım mühendislik verileri, ELDP, yazılım desteklenebilirlik analiz raporu, RAMST raporları, destek konsepti kullanılarak LORA gerçekleştirilir.

'''Bakım planının geliştirilmesi'''

Bakım planı; sözleşme, ELDP, LORA raporu ve bakım konsepti kullanılarak geliştirilir.

'''Bakım görevlerinin yürütülmesi'''

Bakım faaliyetleri, sözleşme ve ekleri ile bakım planına uygun olarak yürütülür.

'''Desteklenebilirlik Emniyet Analizleri'''

Tasarım mühendislik verileri, ELDP, LDAK, MTA raporu ve RAMST raporları kullanılarak yazılım Desteklenebilirlik Emniyet Analizleri gerçekleştirilir.

'''Önleyici Bakımın Geliştirilmesi ve Sürekli İyileştirme (RCM vb. yöntemler)'''

Tasarım mühendislik verileri, ELDP, RAMST raporları, tedarikçi verileri ve LDAK kullanılarak Önleyici Bakım Görev Gereksinimleri (ÖBGG) geliştirilir.

'''Bakım Görev Analizleri (MTA)'''

Sözleşme ve ekleri, tasarım mühendislik verileri, ELDP, LORA raporu, RAMST raporları, planlı bakım planı ve destek konsepti kullanılarak MTA gerçekleştirilir.

'''Kullanım Safhasında Bakım Optimizasyonu'''

Kullanım safhasında bazı faktörler sistem ve ELD elemanları üzerinde bir etkiye sahip olabilir. Bu tür faktörler daha önce belirlenmiş bakım konsepti ve önleyici bakım faaliyetleri üzerinde bir değişiklik yapılmasını gerektirebilir. Bu durumda önleyici bakım görevlerinin etkinliğinin artırılması için optimizasyon çalışması yapılmalıdır.

Kullanım safhasında bakım optimizasyonunun sağlanması için aşağıdaki faaliyetler yürütülür:

* Analizlerin yapılarak eksik/aksak hususlar ile darboğazların tespit edilmesi,
* Önleyici bakım faaliyetleri kapsamında arızalar meydana gelmeden önce alınacak tedbirlerin belirlenmesi ve uygulanması
* Sıklıkla oluşan arızalara ve bu arızaların periyotlarına göre önleyici bakım faaliyeti kapsamına alınabilecek faaliyetlerin belirlenmesine ve bu kapsama alınmasına yönelik bir mekanizma kurulması.

'''Tanı Analizlerinin gerçekleştirilmesi (D&PHM)'''

Sözleşme ve ekleri, tasarım mühendislik verileri, ELDP ve RAMST raporları kullanılarak tanı analizleri (Diagnostics&Prognostics and Health Management Analysis) gerçekleştirilir.

'''Yazılım Desteklenebilirlik Analizleri'''

Tasarım mühendislik verileri, ELDP, LORA raporu, MTA raporu, RAMST raporu ve destek konsepti kullanılarak Yazılım Etki Analizi gerçekleştirilir. Yazılım Etki Analizi; yazılımın, ürünün kullanım ve desteğindeki etkilerini tarif eder.

=== 3.6.2. İKMAL DESTEĞİ ===
İkmal destek elemanının amacı; mümkün olan en düşük ÖDM’de en iyi kabiliyetin kullanıma hazır olmasını sağlayabilmek için gerekli onarım parçaları, yedekleri ve bütün ikmal maddelerini/hizmetlerini tedarik etmek için yönetim faaliyetlerinin belirlenmesi, planlanması, söz konusu faaliyetlere yönelik kaynağın sağlanması ve faaliyetlerin icra edilmesidir. Böylece; doğru onarım parçaları, yedekler ve malzemelerin, doğru nitelik ve nicelikte, doğru zamanda, doğru fiyata, doğru yerde olması sağlanır. Bu kapsamda üretilecek tedarik verisi; satın alınacak, kontrol edilecek, paketlenerek son kullanıcıya teslim edilecek ürünlere ait tanımlama, açıklama ve test bilgilerini içerir.

İkmal destek; yedeklerin, tamir parçalarının ve malzemelerin tedarik edilmesi, listelenmesi, teslim alınması, depolanması, transferi, dağıtılması ve envanterden çıkarılmasına dair gereksinimlerin belirlenmesi için gerekli bütün yönetsel işlemler, prosedürler ve tekniklerden oluşur. Bu süreç; başlangıç desteğine yönelik ön tedarik hazırlığı ile birlikte ihtiyaç duyulan ikmal maddelerinin/hizmetlerinin tedarikini/ifasını, dağıtımını ve yenilenmesini de kapsar ve temelde iki faaliyetten oluşur.

'''Ön Tedarik Verisinin Sağlanması'''

Bu faaliyet çerçevesinde; ürüne gerekli desteği sağlayabilmek için satın alınması gereken malzeme miktarını da içerecek şekilde, ön tedarik verisi temin edilir. Kodlandırma ise, ikmal sisteminde yer alan ekipman, komponent ve parçaların standart bir şekilde isimlendirilmesi, tanımlanması ve sınıflandırılmasını sağlar.

'''Malzeme İkmalinin Gerçekleştirilmesi'''

Bir kurum, kuruluş ya da şirketin barış ve savaş ortamında yürütmüş olduğu lojistik faaliyetlerin başarısı; ikmal maddelerinin doğru, kesintisiz ve hızlı akışına bağlıdır. Bu akışın sağlanmasında, tedarik, envanter tutma, stok kontrolü, depolama, bilgi sistemleri kullanımı, tesis yerleşimi gibi etkenler çok önemlidir. İkmal faaliyetleri, müşteriden gelen siparişlerin yönetilmesi ve mevcut stoklardan ya da stokta bulunmadığı durumda tedarik edilerek ihtiyaçların karşılanmasından oluşur. Bu faaliyet kısmen müşteri, kısmen de yüklenici tarafından yürütülür. Fiyat tekliflerinin oluşturulması, siparişlerin verilmesi, teslimatların gerçekleştirilmesi ve faturalandırılması gibi aktiviteleri içerir.

=== 3.6.3. İŞ GÜCÜ VE PERSONEL ===
İş gücü ve personel ELD elemanının amacı; ürünün ömür devri boyunca kullanılması ve idame edilmesi için gerekli nitelikte iş gücü ve personelin belirlenmesi, planlanması, kaynağın sağlanması ve istihdam edilmesidir. Yapılacak iş gücü ve personel analizi ile ürünün ömür devri süresince kullanımı, idamesi ve desteklenmesi için ihtiyaç duyulan kalifikasyona ve yeteneğe sahip iş gücü ve personelin tespit edilmesine, sağlanmasına ve istihdamına yönelik çalışma yapılır. İş gücünü planlarken, sadece iş odaklı operasyonel planlama süreçleriyle yetinmeyip bunun ötesine geçerek stratejik planlamanın yapılması da günümüz rekabet ortamında önemli bir konudur. Aslında iş gücü planlaması özünde; yapılması gerekli işe, uygun kişinin, reel maliyet ve olması gereken zamanda katılımı olarak özetlenebilir. Burada ilgili insan kaynaklarının becerileri ve yetenekleri, bilgi birikimleri ve tecrübeleri ile uzun vadede şirket içerisinde alacakları çeşitli görev tanımları gibi konular da gözönüne alınmaktadır. Örneğin; bir kişi işten ayrıldığında iş akışı etkilenmeden yerine geçebilecek olan insan kaynağının öncesinde planlanması veya kurum içi eğitim çalışmalarıyla yetkinliklerinin yükseltilmesi doğrultusunda kariyer planlarının yapılması gibi maddeler hayata geçirilmelidir.

=== 3.6.4. DESTEK VE TEST EKİPMANLARI ===
Destek ve Test Ekipmanları ELD elemanının amacı; ürünün ihtiyaç duyulduğunda kullanıma hazır olmasını sağlamak üzere, kullanımı, desteği ve ikmalini sürdürebilmek için gerekli destek ekipmanlarının (mobil veya sabit) tedarik edilmesi ve desteklenmesine ilişkin yönetsel faaliyetlerin belirlenmesi, planlanması, kaynak tahsisi ve uygulanmasıdır.

Destek ve test ekipmanı, ürünün destek ve idamesi için gerekli olan her türlü ekipmanı kapsayan bir terimdir. Kapsamına; çok kullanımlı destek elemanları, el aletleri/takım/avandanlıklar, meteoroloji ve kalibrasyon ekipmanları, ölçü aletleri ve manuel/otomatik test ekipmanları dahildir.

Ürün tedariği esnasında program yöneticilerinden beklenenlerden biri de envanterde mevcut olan destek ekipmanlarının kullanımına ağırlık verilmesi ve yeni destek ekipmanı geliştirme ihtiyacının asgariye indirilmesi vasıtasıyla envanterdeki destek ekipmanı miktarının artmasının önlenmesidir.

Bu kapsamda iki ana faaliyet gerçekleştirilir:

'''Destek ve Test Ekipmanları Gereksinimlerinin Analiz Edilmesi'''

Bu analiz, ELDP’den veya diğer ELD unsurları tarafından belirlenen gereksinimlerden türetilen destek ve test ekipmanları gereksinimlerini tanımlar ve dokümante eder. Bu tanımlama esnasında; yeni, genişletilmiş veya yükseltilmiş destek ve test ekipmanları seçeneklerinin yanı sıra mevcut ekipmanların kullanımı da dikkate alınmalıdır. Analizler kapsamında aynı zamanda, destek ekipmanının nasıl envanterden çıkarılacağı da planlanmalıdır.

Bu faaliyetin çıktısı olan Destek ve Test Ekipmanları Planı, bütün destek ekipmanlarını tanımladığı gibi ekipmanın kendisi için lojistik desteği de öngörmelidir.

'''Destek ve Test Ekipmanlarının Sağlanması'''

Bu faaliyet; destek teçhizatının geliştirilmesi, üretilmesi, satın alınması, kurulması ve idame edilmesini kapsar. Ömür devri safhalarında üretilecek “Destek ve Test Ekipmanları Raporu” ilgili tarafın yönetimine, destek ve test ekipmanlarının durumunun anlık bir özetini sunar. Test faaliyetlerinin herhangi bir aksaklığa uğramadan yürütülebilmesi için ilgili test ekipmanlarının zamanında ve uygun yerde hazır bulundurulması hususu doğrulama ve geçerleme faaliyetlerini gerçekleştiren birimler ile koordine edilir.

=== 3.6.5. TASARIMA ETKİ/TASARIM ETKİLEŞİMİ ===
Geliştirme projelerinin başarılı olması için; halen kullanımda olan benzer sistemlerden yola çıkılarak ELD hedeflerinin, proje başında kullanıcı ile birlikte belirlenmesi, tüm tasarım aşamasından başlayarak bu hedeflere göre projenin yürütülmesi ve desteklenebilirlik kriterlerinin ölçülebilir metrikler ile tasarıma yansıtılmasının sağlanması gerekmektedir. Başarılı bir ürünü üç temel kriter ile tarifleyebiliriz; tasarım olarak performans hedeflerini karşılayan, maliyet etkin ve desteklenebilir.

Bu üç temel unsur, bir biri ile ayrılmaz ve beraber değerlendirilmesi gereken unsurlardır. Eğer bu üç unsuru detaylandırmak istersek, aşağıdaki şekilde deniz platformu için basit bir örnek verebiliriz. Her türlü performans hedeflerini karşılamak için tasarlanan sistemin, görevi esnasında kritik arıza yaşamamalıdır. Arıza yaşadığında ise, bu arızayı gidermek için eğitilmiş personeli, eğitim kitapları, yedek parçası, destek ekipmanları ile kolay, hızlı ve uygun maliyetle onarılabiliyor olması gerekmektedir.
[[Dosya:Şekil9 Savunma Ve Güvenlik Sistemi İçin Başarı Kriteri.jpg|alt=Şekil 9 Savunma ve Güvenlik Sistemi İçin Başarı Kriterleri|sol|küçükresim|500x500pik|Şekil 9 Savunma ve Güvenlik Sistemi İçin Başarı Kriterleri]]

Tasarıma Etki/Tasarım Etkileşimi ELD elemanı kapsamında:

* Desteklenebilirliğin sağlanması için ürünün fikir aşamasından itibaren ömür devri boyunca tasarımına (İlk tasarım, iyileştirme, yarı ömür modernizasyonları vb.) etki edilmesi,
* Kullanıma hazır bulunma, etkinlik ve ÖDM için en uygun tasarımı elde etmek amacıyla sistem mühendisliği sürecine dahil olunması gerekir.

Tasarıma Etki/Tasarım Etkileşimi; sistem mühendisliğinin güvenilirlik, kullanıma hazır bulunma, idame edilebilirlik, desteklenebilirlik, test edilebilirlik gibi niceliksel tasarım parametrelerinin işlevsel ELD elemanları ile entegrasyonudur. Tasarıma Etki/Tasarım Etkileşimi, ürün tasarımı ile ürünü desteklemek için ihtiyaç duyulan kaynaklar arasındaki dinamiği ortaya koyar.

Söz konusu tasarım parametreleri, gereksinimlerle ilişkilendirilmiş olmalı ve operasyonel terimler şeklinde ifade edilmelidir. Böylece ürün destek gereksinimleri, ürünün kullanıma hazır bulunma hedefleri ile maliyetlerin etkin şekilde dengelenmesini sağlayacak şekilde belirlenir. Bu amaçla aşağıdaki üç konu başlığı altında verilen ana faaliyetler gerçekleştirilir:

'''ÖDM Analizlerinin Gerçekleştirilmesi'''

ÖDM analizi, ürün için farklı tasarım alternatifleri arasında maliyet etkinlik açısından en iyi seçeneği belirler.

'''LDA’nın Gerçekleştirilmesi'''

LDA faaliyeti, ilgili standartlara uygun olarak bir LDA veri tabanı oluşturur. LDA veri tabanı, bütün lojistik verilerin kayıt altına alındığı ve muhafaza edildiği tek ortamdır. Tedarik, mühendislik ve kullanıcılar arasında veri tutarlılığının sağlanabilmesi için tüm ELD elemanları arasındaki veri akışı LDA veri tabanı (LDA Kayıtları, LDAK) üzerinden sağlanır. Örneğin, teknik dokümanların ve bakım prosedürlerinin hazırlığı, LORA analizleri, MTA ve ÖDM analizleri için ortak bilgi kaynağı LDAK’dır.

'''RAMST Analizlerinin Geçekleştirilmesi'''

Bu faaliyet esnasında; ürün tasarımının güvenilirlik, kullanıma hazır bulunuşluk, idame edilebilirlik ve test edilebilirlik karakteristikleri analiz edilir.

=== 3.6.6. TEKNİK VERİ VE DOKÜMANTASYON ===
Teknik Veri ve Dokümantasyon; kayıt şekli ya da yönteminden bağımsız olarak bilimsel ve teknik içerikli kayıtlı veri ve bilgilerdir. Bilgisayar yazılımı, finansal ya da idari bilgiler gibi sözleşme yönetim bilgileri Teknik Veri ve Dokümantasyon kapsamına girmez.

Teknik Veri ve Dokümantasyon elemanının başlıca iki hedefi mevcuttur:

* Bilgiyi elde etme ve bakım faaliyetlerini tanımlama, planlama, doğrulama, kaynak tespiti ve yürütme,
* Teknik yayın planlama, geliştirme, üretme ve bakımı.

Bu maksatla yürütülen faaliyetler ise, teknik veri paketini geliştirme ve teknik yayınların hazırlanması süreçleri olarak aşağıdaki iki başlık altında özetlenmektedir.

'''Teknik Veri Paketini Geliştirme'''

Teknik Veri Paketi (TVP), bir ürün/sistemin ürün ömür devri boyunca tedarik stratejisi, geliştirme, üretime hazırlama, üretim geliştirme, üretim, mühendislik ve lojistik aktivitelerini destekleyebilecek yeterlilikte teknik olarak tanımlanmasıdır. TVP geliştirme süreci, birçok farklı ELD fonksiyonunu destekleyebilecek şekilde organize edilmiş olmalı ve yönetilmelidir. TVP, ürünün/sistemin performansını sağlayabilmesi için ihtiyaç duyulan tasarım konfigürasyonu ve ilgili tüm prosedürleri tanımlar ve ilave olarak değişik veri türlerini içerir. TVP’nin oluşturulmasında; veri gereksinimleri ve mülkiyet hakları korunarak, verinin zamanında ve uygun maliyetle elde edilmesi, güncel tutulması, kullanım amacına uygunluğu ve yeterliliği, ayrıca kullanım noktasına en uygun şekilde ulaştırılması gibi hususların tanımlanması ve kontrolü hususlarına da azami dikkat gösterilir.

'''Teknik Yayınların Hazırlanması'''

Teknik yayınlar, ürünün mimarisi ve fonksiyonları ile kullanımını tarif eden dokümanlardır. Kullanım ve bakım talimatları, parça listeleri, teknik bilgi ve prosedürleri kapsar. Teknik yayınların muhatabı idame makamları ve/veya son kullanıcılar olup herhangi bir formatta yayınlanabilirler. Teknik yayınlar bir ürünün desteklenmesi açısından önemli öğelerdir. Teknik yayın hazırlanmasında izlenecek süreç ve yaklaşımlar "[https://tssodypwiki.ssb.gov.tr/index.php/Teknik_Yay%C4%B1n_Haz%C4%B1rlama_Rehberi TSSÖDYP-12 Teknik Yayın Hazırlama Rehberi]” nde açıklanmıştır.

=== 3.6.7. EĞİTİM VE EĞİTİM DESTEĞİ ===
Bu ELD elemanının hedefi; belirlenen eğitim stratejisinin uygulanması ile eğitim desteği kaynaklarının belirlenerek planlanması, ürünün ömür devri boyunca en uygun performans ve kullanıma hazır bulunuşluk seviyesini sağlayacak şekilde kullanılması, idamesi ve desteklenmesi için personeli eğitmektir.

Eğitim İhtiyaçları Analizi, ürünün kullanımı için doğru eğitimin belirlenmesi amacıyla yapılmalıdır. Eğitim İhtiyaçları Analizi içinde yer alan isterler, eğitimi alacak personelin yetkinliğini de dikkate almalıdır.

Ürünü görev sahasında kullanacak ve idame ettirecek personelin eğitimi ürün sahaya konuşlandırılmadan hemen önce ya da kullanıma alınmadan önce verilir. İlerleyen safhalarda ürün ömür devri süresince mevcut veya yeni personel için tekâmül eğitimleri de ayrıca önceden planlanmış olmalıdır. Eğitim ve eğitim desteğine ilişkin faaliyetler kapsamında eğitim ihtiyacının analiz edilmesi, tasarlanması, geliştirilmesi, uygulanması ve denetlenmesi hususunda izlenecek süreç ve yaklaşımlar "[https://tssodypwiki.ssb.gov.tr/index.php/E%C4%9Fitim_ve_E%C4%9Fitim_%C4%B0htiya%C3%A7lar%C4%B1_Rehberi TSSÖDYP-13 Eğitim ve Eğitim İhtiyaçları Rehberi]"nde açıklanmıştır.

=== 3.6.8. TESİSLER VE ALTYAPI ===
Tesisler ve altyapı; bir ürünün entegrasyonu, işletilmesi ve desteklenmesi için gerekli olan sabit ve yarı sabit varlıklar veya mobil tesislerden oluşur.

Bu ELD elemanı; yeni tesis ve altyapının türleri (eğitim tesisi, ekipman/malzeme/tehlikeli madde deposu, bakım tesisleri, bilgisayar donanım/yazılım sistemleri/ağ ve iletişim sistemleri altyapısı vb.) veya mevcut tesis ve altyapılardaki iyileştirmeler, lokasyon, alan, çevre ve güvenlik gereksinimleri ve gerekli ekipmanların belirlenmesine yönelik faaliyetlerin tümünü içerir.

Tesis ve alt yapı planlaması; bütçeleme, tedarik veya inşaat sürelerinin çok uzun olabilmesi nedeniyle ürün ömür devrinde mümkün olan en erken safhada gerçekleştirilmeye çalışılmalıdır.

Bu kapsamda yürütülen başlıca faaliyetler aşağıdaki iki başlık altında verilmiştir:

'''Tesis ve Altyapı Analizlerinin Gerçekleştirilmesi'''

Bu analiz, ELDP veya diğer ELD elemanları tarafından ortaya konulan taleplerden kaynaklanan tesis ve altyapı gereksinimlerini belirler ve dokümante eder. Söz konusu tesis ve altyapı gereksinimleri en uygun çözümün temelini de şekillendirir. Çözüm oluşturulurken mevcut tesis ve altyapılar değerlendirilmelidir. Aynı zamanda, tesislerin bakımı ve envanterden çıkarma planları da düşünülmelidir.

'''Tesis ve Altyapının Sağlanması'''

Bu faaliyet; tesis ve altyapının geliştirilmesi, inşa edilmesi, tedarik edilmesi ve idame edilmesini kapsar. İnşaat ve benzeri altyapı faaliyetleri, karakteristik olarak üründen ayrı olmaları sebebi ile genellikle ayrı sözleşmeler altında yürütülür ve her birinin kendi ömür devirleri söz konusudur.

=== 3.6.9. PAKETLEME, ELLEÇLEME, DEPOLAMA VE ULAŞTIRMA (PEDU) ===
Malzeme yönetimi; ihtiyaç duyulan malzemeyi, ihtiyaç duyulan yere, ihtiyaç duyulan miktarda, uygun koşullarda, ihtiyaç duyulan sıklıkla, ihtiyaç duyulan şekilde yönlendirerek, ihtiyaç duyulan zamanda uygun yöntem kullanımı ile uygun maliyette sağlayan bilimdir. Bir ürünün bakım ve onarımı ile illişkili faaliyetlerin yanı sıra, ürünün kullanımı ve elleçlenmesi esnasında dikkate alınması gereken birçok ilave hususlar mevcuttur. PEDU, bir ürünün doğrudan kullanımı ve bakımı ile ilişkilendirilemeyen ancak ürünün uygun kullanımı açısından önem arz eden görevleri kapsar. Bu görevleri belirleyebilmek amacıyla Paketleme, Elleçleme, Depolama ve Ulaştırma (PEDU) analizleri gerçekleştirilir. PEDU analizi, PEDU görevlerinin ve bu görevlere ilişkin personel, destek ekipmanı, yedek parça ve sarf malzemeleri, tesis ve eğitim ihtiyaçlarının belirlenmesini kapsar. Analizlerin çıktıları PEDU Planı’nda dokümante edilir.

PEDU görevlerinin bir kısmı ömür devrinin erken safhalarında, diğer kısmı ise daha ileriki aşamalarda (örneğin bir prototip veya ürün ortaya çıktığı zamanlarda) dikkate alınmalıdır. Bu görevler, bütün ürün, teçhizat ve destek elemanlarının uygun şekilde muhafaza edilmesi, paketlenmesi, taşınması ve sevk edilmesini sağlayacak tasarım önlemleri, süreçler, kaynaklar ve prosedürlerin bütünüdür. Çevresel koşullar, uzun ve kısa dönem depolama şartlarına göre ekipmanın korunması gibi hususları da dikkate alır.

=== 3.6.10. BİLGİSAYAR KAYNAKLARI ===
Bilgisayar Kaynakları; görev kritik bilgisayar yazılım/donanım sistemlerinin işletilmesi ve desteği için ihtiyaç duyulan tesis, donanım, yazılım, iletişim, dokümantasyon, iş gücü ve personel ihtiyaçlarını kapsar. Amacı, görev kritik bilgisayar yazılım/donanım sistemlerininin tedariki ve yönetimi, idamesi ve güncellenmesi için gerekli olan kaynakların tespiti, planlanması, tahsisi ve kullanıma alımının gerçekleştirilmesidir.

Bu kapsamda aşağıda verilen iki temel faaliyet yürütülür:

'''Bilgisayar Kaynak Analizinin Gerçekleştirilmesi'''

Bu analiz, ELDP veya diğer ELD elemanlarının taleplerinden türetilen bilgisayar kaynak gereksinimlerini belirler ve dokümante eder. Yeni, modifiye edilmiş veya geliştirilmiş bilgisayar kaynaklarının yanı sıra mevcut bilgisayar kaynakları da bu analiz kapsamında göz önünde bulundurulmalıdır. Analiz, aynı zamanda bilgisayar kaynaklarının envanterden çıkarma planlamasını da (örneğin verinin arşivlenmesi) kapsamalıdır.

'''Bilgisayar Kaynaklarının Sağlanması'''

Bu faaliyet; bilgisayar kaynaklarının geliştirilmesi, üretilmesi, satın alınması, kurulması ve idame ettirilmesini kapsar. Sistem ömür devri safhaları boyunca hazırlanacak olan bilgisayar kaynakları raporu, yönetime bilgisayar kaynaklarının güncel durumu hakkında bilgi sağlar.

=== 3.6.11. İDAME MÜHENDİSLİĞİ ===
Bu ELD elemanının amacı, kullanımda olan ürünleri bulundukları operasyonel çevre koşullarında desteklemektir. Bu faaliyet envanterde bulunan ve/veya envantere alınan bir sistemin kullanımı ve desteklenmesi için gerekli olan tüm teknik görevleri kapsar (mühendislik ve lojistik incelemeler, analizler vb). İdame Mühendisliği, sistemin kullanım ömrü boyunca kusurlarının belirlenmesi, gözden geçirilmesi, değerlendirilmesi ve çözüme kavuşturulmasını içerir. Yapılan çalışmaların çıktıları geri bildirim bilgisi ve tasarım eksikliklerini ele alan veya desteklenebilirlik tasarım faktörlerini geliştiren mühendislik değişiklikleri şeklinde tasarıma yönelik değerlendirme ve önerilerdir.

İdame Mühendisliği çalışmaları hem sistemi ana hat çekilmiş konfigürasyon ve kabiliyetlerine geri çevirir hem de performans ve kabiliyetleri iyileştirmek için fırsatları belirler. Sistemin teknik ve desteklenebilirlik açısından kusurlarının belirlenmesi, ölçülmesi, doğrulanması, ilişkili kök neden analizleri, kusurun düzeltilme potansiyelinin değerlendirilmesi ve bir dizi düzeltici işlem seçeneğinin geliştirilmesi, bu amaçla yapılan çalışmalardır. Bu çalışmalar aynı zamanda, seçilen düzeltici işlemlerin konfigürasyon ve bakım süreçlerinde uygulanmasını ve anahtar idame metriklerinin izlenmesini de kapsar.

İdame mühendisliği faaliyetleri aşağıda verilen iki ana başlık altında toplanabilir:

'''Hata ve Kusurların Belirlenmesi ve Teknik Analizlerin Gerçekleştirilmesi'''

Bu aktivite bir hata/kusura ilişkin hususları belirlemek için yürütülen bilimsel çalışmalardan oluşur. Bu kapsamda aşağıda sıralanan türden çalışmalar gerçekleştirilir:

* Bütün kullanım ve bakım verilerinin toplanması ve öncelik sınıflandırılmasının yapılması,
* Çevre ve emniyet tehditlerinin, hata türleri ve etkilerinin, güvenilirlik ve idame edilebilirlik eğilimlerinin, kullanım profil değişikliklerinin analiz edilmesi,
* Hizmet içi problemlere dair (operasyonel tehditler, hata/kusur raporları, parça demodeliği, korozyon etkileri, güvenilirliğin azalması vb.) kök neden analizlerinin gerçekleştirilmesi,

Yapılan çalışmaların sonuçlarına dair elde edilen bilgiler geri bildirim olarak ilgili taraflara mutlaka aktarılmalıdır.

'''Çözümlerin Geliştirilmesi'''

İdame metriklerini iyileştirecek şekilde; hata/kusurların değerlendirilmesi ve sorunların düzeltilmesi, iyileştirilmesi veya sonlandırılması için gereken işlemlerin yapılması ve önerilen ürün modifikasyonunun geliştirilmesi, bu kapsamda gerçekleştirilen faaliyetlerdir. Bu faaliyetlerin çıktısı mühendislik değişiklik teklifleridir.

=== 3.6.12. ÜRÜN DESTEK YÖNETİMİ ===
Ürün Destek Yönetimi (ÜDY); bütün ELD elemanlarını kapsayacak şekilde ürün desteğinin planlanması, yönetilmesi ve finanse edilmesini kapsar. Destek konseptinin ve ELDP’nin hazırlanması, geliştirilmesi ve detaylandırılmasının yanı sıra demodelik planının hazırlanması ve raporunun oluşturulması da bu ELD elemanı bünyesinde gerçekleştirilen faaliyetlerdendir. ÜDY, belirli bir sistem veya hizmet için ELD ihtiyaçlarının detaylandırıldığı ELD elemanıdır. Bu doğrultuda aşağıda dört alt başlıkta verilen temel faaliyetler gerçekleştirilir.

'''Ürün Destek Gereksinimlerinin Toplanması'''

Lojistik destek gereksinimlerinden türetilen destek konsepti, lojistik desteğin temel çerçevesini tanımlar. Destek konsepti; lojistik desteğin planlanması, yürütülmesi ve dokümante edilmesinin yanı sıra ürünün hizmete alınması, kullanılması, planlı/plansız bakımlarının yapılması (bakım/onarım) ve envanterden çıkarılmasına da esas teşkil eder. Destek konsepti operasyonel gereksinimler ve kullanım senaryoları esas alınarak belirlenir ve ürünün ömür devrine yönelik stratejiler ve temel lojistik gereksinimleri tanımlar.

Destek konsepti; kullanıma hazır olma, güvenilirlik, idame edilebilirlik, desteklenebilirlik ve test edilebilirlik gibi faktörleri içerir. Aynı zamanda, farklı destek alternatifleri içerip, bu alternatiflerin gerekli kaynaklar, mali etkileşimler ve ilişkili riskler açısından değerlendirilmesini de öngörebilir.

ÜDY, destek konseptininin geliştirilmesi ve destek gereksinimlerinin tanımlanmasından sorumludur. Bu kapsamda; sözleşme, şartname, gereksinim tanımlama dokümanı, tasarım mühendislik verileri vb. dokümanlar kullanılarak;

* Destek konseptinin belirlenmesi ve geçerli kılınması için uygun ödünleşim analizlerinin yapılması,
* Bütün ELD elemanlarının birbiriyle entegre şekilde yönetilmesi sağlanır.

'''ELDP Hazırlanması'''

ELDP; savunma ve güvenlik sistemlerinin lojistik ihtiyaçlarına yönelik ELD elemanlarının bütünleşik olarak yönetimine ilişkin planlanma, uygulanma ve koordinasyon faaliyetlerini içeren dokümandır. Uygun ELD elemanlarına ilişkin planlama ve uygulamaya yönelik detaylar ELDP’de yer alır.

ELDP şablonu Ek’te verilmiştir.

'''Demodelik Yönetiminin Gerçekleştirilmesi'''

Bu faaliyet; demodelik stratejisinin belirlenmesi, Demodelik Yönetim Planı’nın geliştirilmesi ve demodelik çözümlerinin uygulanmasını içerir. Bu faaliyetlerin sonuçları bir Demodelik Raporu (araştırma verileri, risk analiz verileri ve ilgili düzeltme adımları vb.)’nda derlenir. (Bkz. [https://tssodypwiki.ssb.gov.tr/index.php/Sistem_%C3%96m%C3%BCr_Devri_Y%C3%B6netiminde_Demodelik_Y%C3%B6netimi_Rehberi TSSÖDYP-08 Sistem Ömür Devri Yönetiminde Demodelik Yönetimi Rehberi])

'''Lojistik Destek Sözleşmesinin Yönetilmesi'''

Bu faaliyet; mevcut tedarik sözleşmesine uyum ve sözleşmenin yönetilmesine katkı sağlar, alt sözleşmelerin ve destek sözleşmelerinin oluşturulmasını kapsar, çıktıları yönetim raporları ve ürün destek sözleşmeleridir.

Lojistik destek sözleşmesi, bir ürünün işletilmesi ve desteklenmesi için ihtiyaç duyulan mal ve hizmet alımına yönelik sözleşmedir.

Yönetim raporları ise ürün destek yöneticisi tarafından oluşturulan herhangi bir idari rapor olup bunlarla sınırlı olmamak kaydıyla aşağıdaki hususları içerebilir:

* ELD programı ana kilometre taşı takvimi
* Lojistik unsurlar için uygulama takvimi
* İş Tanımı ile kıyaslandığında her bir lojistik unsurun mevcut durumu.

Raporlandırma sistemi, projeye bağlı olup, proje özel raporlandırma gereksinimlerine yönelik standart bir çözümü yoktur.

= 4. LOJİSTİK DESTEK ANALİZİ (LDA) =
LDA çalışmalarında [https://tssodypwiki.ssb.gov.tr/index.php/Lojistik_Destek_Analizleri_ve_Kay%C4%B1tlar%C4%B1_Rehberi TSSÖDYP-06 Lojistik Destek Analizleri ve Kayıtları Rehberi] esas alınacak olup LDA’ya ilişkin genel bilgiler aşağıda verilmiştir.

LDA, sistemin/bileşenin belirlenmiş sürdürülebilirlik ve kullanıma hazır olma ihtiyaçlarına ulaşılmasına yönelik desteklenebilirlik gereksinimlerini değerlendiren ve ürün tasarımı ile destek sistemi gereksinimlerini entegre eden sistematik ve yinelemeli (iteratif) bir süreçtir.

LDA lojistik destek faaliyetlerinin maliyet etkin olarak yürütülmesinde yol gösterici en önemli faaliyettir. Tüm lojistik destek faaliyetlerinin teknik disiplin içinde maliyet etkin olarak planlanması, koordine edilmesi ve yönetilmesi için LDA rehberliğinde:

* Ürün ve ELD elemanları; desteklenebilirlik, güvenilirlik, test edilebilirlik ve uygun ÖDM ile tasarlanır,
* Kullanım ve Destek Safhaları boyunca ürünün istenilen performans seviyesinde kullanılabilmesi için ihtiyaç duyulan kaynaklar tanımlanır,
* ELD elemanlarına ilişkin esas bilgiler oluşturulur.

LDA, sistem mühendisliği süreçleri paralelinde gerçekleştirilen geniş bir analizler kümesini içerir. Söz konusu analizlerin amacı, desteklenebilirliğin sistem performans gereksinimlerine dahil edilmesinin sağlanması, sistemin en uygun destek sistemi ve alt yapı ile birlikte geliştirilmesi ve tedarik edilmesidir. LDA etkin ve verimli bir destek çözümünün tasarlanması ve geliştirilmesine yönelik çeşitli analitik tekniklerin entegrasyonunu ihtiva eder.

LDA’nın amaçlarından biri karmaşık teknik ürünler için kullanım ve destek safhaları boyunca en uygun lojistik desteğin sağlanmasıdır. Lojistik destek gereksinimlerini tanımlama, analiz etme ve niceliklerini belirlemenin yanı sıra, sistem geliştirme safhasında desteklenebilir bir tasarım ortaya çıkarmaya yönelik faaliyetleri içerir.

== 4.1. LDA FAALİYETİ, ROLLER VE SORUMLULUKLAR ==
LDA faaliyeti Şekil 9’da gösterildiği şekilde aşağıda sıralanan amaçlara yönelik olarak niceliksel bazı analiz yöntemlerinin seçilmesi ve uygulanmasını içeren bir süreçtir:

* Sistem tasarımına girdi sağlamak üzere lojistik kriterlerin belirlenmesi ve oluşturulması,
* Farklı tasarım alternatiflerinin değerlendirilmesi,
* Lojistik destek elemanlarının belirlenmesi ve tedariği,
* Kullanım esnasında sisteme yönelik destek kabiliyetinin değerlendirilmesi.
[[Dosya:Şekil10 Temel LDA Süreci.jpg|alt=Şekil 10 Temel LDA Süreci|sol|küçükresim|698x698pik|Şekil 10 Temel LDA Süreci]]

Ürün geliştirme süreçlerinde paydaş temsilcilerinden oluşan farklı disiplinlere mensup personelin katılımı ile Entegre Ürün Takımları (EÜT) oluşturulabilir. EÜT’ler gözetim seviyesinde olabileceği gibi doğrudan geliştirme sürecinin içinde görev yapacak şekilde de olabilir. Özellikle sistem mühendisliği çalışmalarında EÜT’lerin görüşleri ve katkıları önem kazanır. Ayrıca EÜT’lerin oluşturulmasına ihtiyaç duyulmadığı durumlarda, Program/proje yönetiminden sorumlu olan gruplar EÜT mantığı ile çalışacak şekilde teşekkül ettirilebilir. EÜT liderleri, ilgili ürününün geliştirilmesinden ve bütçesinden sorumludur. ELD yöneticilerinin görevi projeler kapsamında ürün geliştirme ekiplerine lojistik destek ve desteklenebilirlik konularında uzmanlık desteği ve imkân sağlamaktır.

LDA programı kapsamında destek sisteminin geliştirmesinden sorumlu bir lojistik ekibi olması tavsiye edilir. Bu ekip, ürünün tasarımı, geliştirilmesi, üretimi, kullanılması ve desteğinden sorumlu EÜT’nin bir parçası olmalıdır Bu anlamda EÜT’lere atanan lojistik ve desteklenebilirlik uzmanları/personeli ekip içinde aşağıda sıralanan faaliyetlerden sorumlu olacaktır:

* Güvenilirlik, idame edilebilirlik, test edilebilirlik, insan mühendisliği, cihaz içi test (CİT) ve çevresel uygunluk gibi konularda girdi sağlayarak sistem ve destek sistemi tasarımına desteklenebilirlik karakteristiklerinin katılmasını sağlamak,
* Destek sistemini ve eğitim sistemini geliştirmek ve lojistik destek kaynaklarını (ikmal destek, destek ekipmanı, teknik veri, tesisler, PEDU, iş gücü ve personel, eğitim ve eğitim teçhizatı) planlamak, geliştirmek ve sunmak,
* Ürün geliştirme sistem mühendisliği ve tasarım mühendisliği süreçleri içinde lojistik mühendisliği faaliyetlerini gerçekleştirmek,
* LDA, standardizasyon, değiştirilebilirlik ve birlikte çalışabilirlik sağlamak,
* LDA sorumlusu/lideri ile ELD yöneticisi ve diğer işlevsel yönetim sorumluları arasındaki koordinasyonun ve arayüzlerin oluşturulması ve sürdürülmesi LDA programının başarısı açısından büyük önem taşır. Ayrıca, etkin bir ELD/LDA program yönetimi açısından hem müşteri hem de yüklenici bünyesinde bir ELD/LDA organizasyonu oluşturulması gereklidir.

Desteklenebilirliğin entegre ürün geliştirme proje organizasyonuna dahil edilmesi aşağıda sıralanan lojistik yönetim hedeflerine ulaşılmasını sağlar:

* Tasarım ve test verilerinin değerlendirilmesi, desteklenebilirlik alternatifleri ve ödünleşim analizi değerlendirmelerinin tasarıma yansıtılması,
* Detaylı şartname isterlerinin oluşturulması,
* Lojistik kaynak planlamasının gerektiğinde uyarlanabilirliğinin sağlanması,
* Operasyonel kullanıma hazır olma ve göreve hazır olma eşik değerlerine ilişkin gereksinimlerin karşılanması,
* Ürünün beklenen operasyonel çevre koşullarında desteklenebilirliğinin temini,
* Destek sisteminin beklenen performansı sağlaması,

Lojistik yönetimi hedeflerine ulaşabilmek için ise uygun bir organizasyon oluşturulmalıdır. Bu doğrultuda:

* Lojistik mühendisliğinin aktif katılımının ve tasarıma etkisinin en üst düzeyde tutulduğu bir entegre ürün geliştirme organizasyonu oluşturmak,
* ELD sürecini tasarım mühendisliği ve sistem mühendisliği ile sürekli etkileşim içinde olacak şekilde yapılandırmak,
* Ürünü geliştirirken müşteri ve tedarikçilerle yakın şekilde çalışma yapılması gerekir.

Lojistik yönetim hedeflerinin karşılanabilmesi için oluşturulacak LDA sürecinde;

* Tasarıma desteklenebilirlik gereksinimlerini entegre etmeye yönelik LDA prosedürlerinin tanımlanması,
* Destek sistemi konfigürasyonunun ürün tasarım konfigürasyonu ile uyumlu olmasının sağlanması,
* Detaylı bakım planlama ve toplam lojistik kaynak gereksinimlerinin tümevarım yöntemiyle belirlenmesinin sağlanması,
* Lojistik Destek Analizi Kayıtları (LDAK)’nın tutulacağı veritabanının oluşturulmasının sağlanması gerekir.

== 4.2. LDAK YÖNETİMİ ==
LDA süreci sonunda ortaya çıkan veriler, mühendislik ve ürün destek faaliyetleri tarafından kullanımlarını sağlamak için belirli biçimlere uyarlanır ve kayıt altına alınır. Bu veriye “Lojistik Destek Bilgisi” adı verilir ve çeşitli endüstri standartlarına uygun olarak oluşturulan veri tabanı ise “LDAK” olarak adlandırılır.

Sözleşmelerde yer verilen LDAK gereksinimleri, planlanan destek konsepti ile uyumlu ve uyarlanmış içerikte olmalıdır. İhtiyaç makamı, uyumsuzlukları ve gerekenden fazla yapılabilecek sözleşmesel teslimatları önleyebilmek için programın çeşitli işlevsel alanlarından gelecek verilere yönelik gereksinimleri koordine etmelidir. LDAK, nihayetinde ürün destek yöneticisine bütün ELD unsurlarını dikkate alan etkin bir ürün destek paketi oluşturmakta yardımcı olur.

“Lojistik Destek Analizi Veri Tabanı” bir nevi, yapılan lojistik destek analizi kayıtlarının toplandığı kütüktür.

= 5. SİSTEM MÜHENDİSLİĞİ FAALİYETLERİ VE ELD =
Sistem Mühendisliği''';''' yetenek ihtiyacına cevap verebilecek karmaşık sisteme ait isterlerin oluşturulması, bütünleşik bir anlayışla ömür devri süresince birbiri ile uyum içinde çalışacak alt sistem çözüm setlerinin geliştirilmesi ve bunların doğrulanmasıdır. İhtiyacın tanımlanması aşamasında, fonksiyonel olarak tariflenen yeteneğin fiziksel gereksinimlere dönüşümü sürecinde; ihtiyaç duyulacak destek amaçlı ürünler ve geliştirme, üretim/inşaat, konuşlandırma, kullanım, destek, envanterden çıkarma, eğitim ve doğrulama süreçlerini de kapsayan tüm ürünleri içeren sistem mimarisi, anlaşılabilirliği arttırarak doğru çözüme erişmede yardımcı olur.

Tedarik lojistiğinin temel amaçlarından birisi destek gereksinimlerinin sistem tasarım gereksinimlerinin ayrılamaz bir parçası olmasını sağlamaktır. Bu kapsamda yürütülecek proje faaliyetleri ancak eş zamanlı olarak hem yüklenici, hem de kullanıcı ve tedarik makamı tarafından, sistem mühendisliği teknik ve idari faaliyetleri ile bütünleşik vaziyette yürütülmesi halinde hedefine ulaşabilir.

Lojistik planlama; sistem mühendisliği sürecinin bir parçası olup, bu süreç sağlıklı işletilmeksizin projenin nihai hedeflerine erişilmesi söz konusu olamaz.

Sistem geliştirme sürecinin amacı; müşteri ihtiyaçlarını karşılayacak en uygun sistemi, fiziksel kısıtlamalar, zaman, performans ve maliyet kriterlerini göz önüne alarak geliştirmektir. Sistem ile kastedilen, kullanıcı ve diğer paydaşların yararına olan ürün ve hizmetleri, tanımlanmış olan çevre şartlarında sağlamak için insan tarafından meydana getirilen ve kullanılan yapılardır. Sistemi oluşturan bileşenler; donanım, yazılım, veri, insan, süreç, prosedür ve talimat, tesis, malzeme vb. olabilir. ELD faaliyetleri ve ilgili ürünler sistemin teknik karmaşıklığına, değişkenliğine, maliyetine vb. faktörlere bağlı olarak farklılık gösterir. Ürünün özelliği ve bulunulan ömür devri safhasına göre uygun ELD elemanları sistem mühendisliği sürecine dahil edilir.

İhtiyaca cevap verebilecek karmaşık bir sistemin meydana getirilmesi; bütünleşik bir anlayışla ömür devri süresince birbiri ile uyum içinde çalışacak alt sistem çözüm setleri geliştirilmesi ve doğrulanmasını gerektirir. Sistem mühendisliği bu kapsamda aşağıda verilen başlıca faaliyetleri yürütür:

* Teknik faktörlerin planlanması ve organizasyonu,
* Sistemin idamesi için ömür devri boyunca ihtiyaç duyulacak hususların dikkate alınması,
* İhtiyacın tanımlanması aşamasında fonksiyonel olarak tariflenen yeteneğin teknik gereksinimlere dönüşümü,
* Teknik gereksinimleri karşılayabilecek elde edilebilir sistem çözümü alternatiflerinin üretilmesi,
* Destek sisteminin de tanımlandığı toplam sistem çözümlerinin değerlendirilmesi,
* Karar verilen çözümün gerçeklenmesi ve uygulanması,
* Çözümün doğrulanması.

Sistemin idamesi için ömür devri boyunca ihtiyaç duyulacak hususların dikkate alınabilmesi için farklı disiplinlerden uzmanlaşmış ekiplerin, ihtiyaç makamının, tedarik makamının, kullanıcıların ve idame makamının da sürece dahil olması gerekir. Lojistik konusunda uzmanlaşmış bir ekibin bu süreçlerde yer alması ve odak sistem ile birlikte destek sisteminin fonksiyonel, sistemsel ve fiziki gereksinimlerinin belirlenmesinde rol alması zorunludur (Bkz. [https://tssodypwiki.ssb.gov.tr/index.php/Entegre_Lojistik_Destek_(ELD)_%C4%B0sterleri_Haz%C4%B1rlama_Rehberi TSSÖDYP-05 Entegre Lojistik Destek İsterleri Hazırlama Rehberi]).

= 6. PROGRAM/PROJE YÖNETİMİ VE ELD =
Programlama; planlama ile belirlenen hedeflerin kaynaklar bazında nasıl gerçekleştirileceğinin bir zaman boyutu üzerinde projelendirilmesi işlemidir. Program/proje ise belli kriterler içinde tamamlanacak belirlenmiş bir hedefi, başlangıcı ve sonu olan, sınırlı para ve tüketim kaynakları (zaman, personel ve teçhizat) bulunan birbiri ile ilgili bir dizi faaliyetler ve görevlerdir. Programların daha kapsamlı olarak ömür devrinini tamamını dikkate alacak şekilde kurgulanması gerekir.

Operasyonel ihtiyaçların giderilmesi, gerekli donanım, yazılım ve destek unsurlarının en ekonomik şekilde bir araya getirilmesi sonucunda oluşan sistem ile gerçekleştirilir. Program başlangıcında, sistemin tüm unsurlarının ve bunlar ile ilgili gereksinimlerin yeterli seviyede ve doğru tanımlanmış olması vazgeçilmez bir şarttır.

Talep edilen performans gereksinimlerine cevap verebilecek sistem tasarım özelliklerinin; ömür devri maliyet, bütçe, takvim ve performans özellikleri ile optimum noktada birleşebilmesi ilgili program organizasyon birimlerinin koordineli ve eşzamanlı çalışması ile sağlanabilir.

Belirgin bir hedefe yönelik olarak; bir ana sistem veya teçhizatın harekât ihtiyacı olarak belirlendiği andan, hizmet dışı bırakıldığı zamana kadar olan sürede mevcut kaynakların planlanması, proje yönetiminin ve ofisinin teşkilatlandırılması, faaliyet programının disiplini ile projenin gerçekleştirilmesi için bilgi, beceri, araç ve tekniklerin proje faaliyetlerine uygulanmasıdır. Buna ömür devri program yönetimi adı verilmektedir. Zaman, maliyet ve performans programın/projenin başlıca kısıtlarıdır.

İhtiyaç duyulan performans gereksinimlerine cevap verebilecek odak sistem ve destek sistemi tasarım özelliklerinin ömür boyu maliyet, bütçe, takvim ve performans özellikleri ile optimum noktada birleşebilmesi, ilgili program organizasyonel birimlerinin koordineli ve eşzamanlı çalışması ile sağlanabilir. Desteklenebilirlik gereklerinin tasarıma dahil edilmesi ve ömür boyu maliyet hedefinin erişilebilmesi, tasarım birimlerinin operasyonel ihtiyacın tanımlanmasından itibaren desteklenebilirlik hedeflerine yönlendirilmesini gerektirir. Bunun için ELD isterlerinin anlaşılır, açık ve ölçülebilir şekilde tespit edilmiş olması gerekir ([https://tssodypwiki.ssb.gov.tr/index.php/Entegre_Lojistik_Destek_(ELD)_%C4%B0sterleri_Haz%C4%B1rlama_Rehberi TSSÖDYP-05 Entegre Lojistik Destek İsterleri Hazırlama Rehberi]).

Program başlangıcında, sistem desteklenebilirliğine ait hedefleri ve gerekleri analiz etmek, tanımlamak ve doğrulamak için ihtiyaç duyulan tüm desteklenebililik analizleri planlanır. Bu kapsamda yürütülecek faaliyetlerde [https://tssodypwiki.ssb.gov.tr/index.php/Lojistik_Destek_Analizleri_ve_Kay%C4%B1tlar%C4%B1_Rehberi TSSÖDYP-06 Lojistik destek Analizleri ve Kayıtları Rehberi] referans olarak alınır.

Her bir program için desteklenebilirlik ile ilgili hedefler ve analizler, en az aşağıdaki hususların dikkate alındığı bir strateji ile belirlenir:

* Kullanıma/Göreve Hazır Olma gereği,
* Donanım ve yazılım tasarım öngörüleri,
* Kullanım konsepti ve barış/savaş operasyonel gereksinimleri,
* Destek konsepti,
* Tahmini Güvenilirlik ve İdame Edilebilirlik değerleri,
* Tahmini ÖDM, Maliyet Kategorileri (Ar-Ge, Üretim, İşletme-Destek, Envanterden Çıkarma)
* Lojistik destek kaynak gerekleri,
* Desteklenebilirlik analizlerini yürütebilmek için gerekli lojistik destek verisi,
* Mevcut saha verileri, mevcut sistemlerin performans değerlendirmeleri, desteklenebilirlik, maliyet ve göreve hazır olma oranlarında tahmini iyileşme değerleri,
* Program risklerindeki azalmaları da kapsayacak biçimde, analizlerin uygulanmasının tasarım üzerindeki olası etkileri,
* Herbir desteklenebilirlik analizinin tahmini maliyeti.

Desteklenebilirlik analizlerinin kapsamını etkileyecek bir diğer husus, projenin bulunduğu aşama ya da görev sistemi tasarım konseptidir. Tasarım yoğun projelerde, desteklenebilirlik analizleri tasarıma girdi sağlarken tasarım çıktıları destek planlamasında kullanılır. Alternatif destek sistemi çözümleri yanı sıra görev sistemi tasarımına yönelik alternatifler (tasarım, ticari, hazır ürün) değerlendirilir. RAHAT (Rafta Hazır Ticari/COTS/Commercial Of The Shelf) ya da tasarım gerektirmeyen çözümlerde, desteklenebilirlik analizleri destek sistemi üzerine yoğunlaşır.

Tasarımı tamamlanmış ürünlerin yeni projelerde kullanılması sürecinde, ürünün sisteme ait diğer unsurlar ile uyumlu olması konusu başlangıçta sorgulanmalıdır.

Ticari destek çözümleri söz konusu ise, desteklenebilirlik analizleri ticari destek altyapısı ile arayüzlerin tanımlanması konusuna yoğunlaşır.

İyileştirme projelerinde, tasarım esnekliği desteklenebilirlik analizlerinin kapsamını belirleyen başlıca unsurdur.

Desteklenebilirlik ile ilgili hususlar, sistem mimarisi ile ilgili kararlar verilirken mutlaka göz önünde tutulmalıdır.

Desteklenebilirlik ihtiyaçlarının ya da gereklerinin sözleşme ve ekleri ile tanımlanmamış olduğu ya da türetilmesi için yeterli bilgiye sahip olunmadığı durumlarda, aşağıda belirtilen hususlar dikkate alınmak suretiyle desteklenebililik gerekleri oluşturulur ve bunların tasarım sürecinde dikkate alınması sağlanır.

* Tedarik/ihtiyaç makamlarının prensipleri dikkate alınır. Yerlileştirme/ Millîleştirme çalışmaları için [https://tssodypwiki.ssb.gov.tr/index.php?title=Kullan%C4%B1m_ve_Destek_%C4%B0htiya%C3%A7lar%C4%B1_%C3%87er%C3%A7evesinde_Yerlile%C5%9Ftirme/Millile%C5%9Ftirme_Rehberi&redirect=no TSSÖDYP-09 Kullanım ve Destek İhtiyaçları Çerçevesinde Yerlileştirme/Millîleştirme Rehberi] referans doküman olarak kullanılır.
* Mevcut benzer sistemlerin veya ekipmanların kullanımı sürecinde edinilmiş tecrübeler ve kayıtlara dayalı yapılan analizler, tahmin ve öngörülere dayalı gereksinim belirleme yöntemine göre daha kesin ve doğru sonuçlar verecektir. Tecrübeler, analizler ve kayıtlar ELD birimleri başta olmak üzere ilgili birimlerden sorgulanır. Eğer tecrübeye dayalı veri mevcut değilse, özellikle yüksek risk öngörülen alanlarda, analizlere temel olabilecek verilerin temin edilmesine yönelik faaliyetler yürütülür.

* Standartlara dayalı gereksinimler yerine performans gereksinimlerinin tanımlanması tasarımcılara daha geniş hareket alanı sağlayabilir. Bu yöntem uygun görülmesi durumunda kullanılır.
* Gereksinimler değişken kullanım profilleri (barış ve savaş şartları gibi) için ayrı ayrı belirlenir.
* Desteklenebilirlik analizlerinin yapılması için gerekli zaman ve kaynak miktarı öngörülür. Sonuçları tasarım kararlarına etki edemeyecek kadar uzun zamanda elde edilebilecek analizlere ihtiyaç duyan desteklenebilirlik gereksinimlerinin ortaya konması anlamlı değildir. Bunun istisnası; ileriye yönelik planlı ürün iyileştirme faaliyetleridir. Desteklenebilirlik analizleri sonucunda elde edilecek fayda; desteklenebilirlik unsurlarının görev sistemi performans gerekleri içinde yer almış olması ve destek sisteminin, görev sistemi ile eşzamanlı olarak geliştirilmesinin sağlanmasıdır.
* Desteklenebilirlik gereksinimlerinin belirlenmesinde uluslararası rekabet şartları dikkate alınır.
* Desteklenebilirlik gereksinimlerinin belirlenmesi tekrar eden yapıda bir faaliyettir. Desteklenebilirliği etkileyen unsurlar (özellikle insan ile bağımlı unsurlar) değişken bir yapıya sahip olup, sistem ömür devri içinde dahi dikkate alınması gerekli değişimler olabilir. Ürün ömür devri boyunca, desteklenebilirliği etkileyen unsurlar sürekli gözlenmeli ve gereksinimler güncellenmelidir.
* Desteklenebilirlik gereksinimleri maliyet olarak erişilebilir olmalıdır.
* Tedarikçiler, sağlanacak desteğin ayrılmaz bir parçasıdır. Program yöneticisi, lojistik destek ve desteklenebilirlik açısından tedarikçi adaylarını periyodik olarak değerlendirmelidir.

== 6.1. SİSTEM ÖMÜR DEVRİ SAFHALARI VE ELD ==
[https://tssodypwiki.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)] ve [https://tssodypwiki.ssb.gov.tr/index.php/Sistem_%C3%96m%C3%BCr_Devri_Y%C3%B6netimi_S%C3%BCre%C3%A7leri_Rehberi TSSÖDYP-02 Sistem Ömür Devri Yönetimi Süreçleri Rehberi] referans dokümanlar olarak kullanılır.

'''Ön Konsept ve Konsept Safhaları'''

TSSÖDYP-05 Entegre Lojistik Destek İsterleri Hazırlama Rehberi, ön konsept ve konsept safhalarında ihtiyaç makamlarının hazırlayacakları Proje/İhtiyaç Tanımlama Dokümanı (PTD vb.) ve ekleri ile Teklife Çağrı Dokümanı (TÇD)’de savunma ve güvenlik sistemlerinin lojistik destek isterlerinin belirlenmesinde kullanılacak rehberdir.

Bu safhalarda sistem tasarım alternatifleri risk ve maliyetler açısından değerlendirilir. Bu kapsamda, işletim ve bakım konsept alternatifleri, destek sistemi alternatifleri, görev sistemi tasarım alternatifleri ile ilgili risk ve maliyet analizleri yapılır, fonksiyonel kırılım üst seviyeleri için performans ihtiyaçları belirlenmeye çalışılır.

Üzerinde çalışılmış olan alternatif destek sistemi çözümleri ve konseptlerin Sistem çözümü içindeki diğer desteklenebilirlik unsurları ile uyumu ve sistemin ÖDM’ye etkisi değerlendirilir. Seçilen destek sistemi ve konsept, başlangıç destek planlarının ve gereklerinin oluşturulmasına temel teşkil eder. Desteklenebilirliği etkileyebilecek performans gereklerinin bu safhalarda tanımlanması önemlidir.

Konsept safhasının sonunda ürün detstk stratejisinin ve modelinin belirlenmesi ve müteakip safhalardaki gelişmelere göre güncellenebilir/geliştirilebilir durumda olması gerekir. ([http://ssbwiki.ssb.gov.tr/index.php/%C3%9Cr%C3%BCn_Destek_Stratejileri_ve_Modelleri_Rehberi TSSÖDYP-03 Ürün Destek Startejileri ve Modelleri Rehberi])

'''Geliştirme Safhası'''

[https://tssodypwiki.ssb.gov.tr/index.php/Lojistik_Destek_Analizleri_ve_Kay%C4%B1tlar%C4%B1_Rehberi TSSÖDYP-06 Lojistik Destek Analizleri ve Kayıtları Rehberi], ELD faaliyetlerinin merkezinde yer alan LDA’nın gerçekleştirilmesi ve bu analizler sonrasında oluşturulacak LDA Kayıtları konusunda hazırlanmış bir dokümandır.

Bu safhada desteklenebilir ve ekonomik olarak elde edilebilir bir odak sistem tasarımı faaliyetlerine katılım sağlanır.

Tasarım faaliyetleri kapsamında LDA faaliyeleri destek sisteminin tasarlanması/organizasyonu konususuna odaklanır. Odak sistem tasarımında olabilecek değişiklikler destek sisteminin tasarımında da dikkate alınır. Sistem tasarımı lojistik destek yapısını ve lojistik ihtiyaçlar da sistem tasarımını etkilemektedir. Burada en önemli husus lojistik destek isterlerinin odak sistem tasarımı üzerinde bir etkiye sahip olmasıdır.

LDA’da, sistem tasarımına etki eden en az aşağıdaki faktörler göz önünde bulundurulur.

* Kullanıcının genel hususlara ilişkin isterleri,
* Kullanıcının güvenilirlik, hazır bulunuşluk ve desteklenebilirlik isterleri,
* Benzer sistemlerin saha (kullanım ve lojistik destek) verileri,
* İdarenin sistemle ilgili kullanım, bakım ve tedarik konseptleri/yönergeleri,
* Sistem ömür devri kullanım senaryoları (kullanım, depolama, taşıma vb.)
* Muharebe alanının coğrafi ve atmosferik şartları,
* Güvenlik ve emniyet gereksinimleri,
* Modülerlik gereksinimi,
* İstenen ürünün yapılabilirliğine yönelik mevcut teknolojik imkânlar,
* Yüklenicinin imkân ve kabiliyetleri,
* Standardizasyon ve diğer sistemler ile uyumlu çalışabilirlik gereksinimi,
* Test edilebilirlik gereksinimi,
* Ergonomi (insan faktörü) gereksinimi,
* Lojistik destek faaliyetlerinde maliyet etkinlik,
* Demodelik gereksinimi,
* Onarılabilirlik ve modernize edilebilirlik gereksinimleri,
* Modernizasyon gereksinimi,
* Ömür durum tespiti ve uzatımının yapılabilirlik gereksinimi.

Benzer sistemlerden elde edilen kullanıcı verileri ile mevcut imkân ve yetenekleri yeni sistemin tasarımına aktarılması maksadıyla tasarım süreci başlatılmadan yüklenici ve ELD çalışma grubu tarafından kullanıcı tesislerinde inceleme yapılmalıdır. Bu kapsamda aşağıdaki hususlarda inceleme yapılır ve kullanım çalışması raporu hazırlanır.

1. Benzer sistemlerin:

1.1. Harekât/operasyon görevi,

1.2. Taktik ve teknik özellikleri,

1.3. Ürün ağacı ve alt parçaların fonksiyonel görevleri,

1.4. Zaafiyetleri ve üstünlükleri,

2. Mevcut lojistik destek imkân ve yetenekleri:

2.1. Bakım konsepti ve yapısı,

2.2. İkmal desteği konsepti ve yapısı,

2.3. Personel durumu (miktar ve nitelik),

2.4. Destek ve test ekipmanları,

2.5. Teknik veri ve dokümantasyon oluşturma konsepti,

2.6. Eğitim konsepti, eğitim destek ve eğitim yardımcı malzemeleri,

2.7. Tesisler ve altyapı,

2.8. Paketleme, elleçleme, depolama (alanları, şartları vb.) ve ulaştırma,

2.9. Bilgisayar Kaynakları,

2.10. İdame Mühendisliği,

2.11. Ürün Destek Yönetimi,

3. Çevresel, coğrafi ve atmosferik şartlar,

4. Ömür devri kullanım, depolama ve ulaştırma senaryoları (süre, mesafe ve şartları),

5. Konfigürasyon yönetimi yapısı,

6. Aktarma ve elden çıkarma konsepti,

7. Standardizasyon yaklaşımı,

8. Demodelik yönetimi yaklaşımı,

9. Modülerlik yaklaşımı ve parçaların birbirleri yerine kullanılabilirlik gereksinimi,

10. Emniyet ve güvenlik gereksinimleri,

11. Kullanım ve lojistik destek sürecinde elde edilen tecrübeler,

12. Kullanım ve lojistik destek faaliyetlerinden sorumlu personelin teklif ve önerileri,

13. Garanti süreci yönetimi,

14. Sistemin konuşlandırılma şartları ve esasları.

Sistem tasarımı kapsamında yapılan faaliyetlerin etkinliği, sistemin kullanım ve destek safhalarındaki performansını doğrudan etkileyecektir. Sistem tasarımının olgunlaşması, yedek parça listeleri, eğitim programlarının tanımlanması ve doküman içeriklerinin belirlenmesi gibi çıktıların üretilmesine izin verir.

'''Üretim ve Kullanım Safhaları'''

Bu safhalardaki lojistik destek aktiviteleri ELDP’ye uygun şekilde yürütülür. ELDP projelerdeki gelişmelere uygun şekilde sürekli güncel tutulur. Kullanım ve destek faaliyetlerini yürütecek olan organizasyonun tabi olduğu mevzuat ve uygulamakta olduğu yönergeler de ELDP hazırlığı sürecinde göz önünde bulundurulmalıdır.

Sistemin teslimatı öncesinde, işletmeye alınabilmesi için gerekli destek altyapısı ve kaynaklar hazırlanır. Sistemin teslimi ve görevine başlaması önemli bir aşamadır. Bu aşamada ilgili destek unsurları da yerinde bulunmalıdır. Devam eden süreçte sistemin başlangıçtaki performansını sürdürmesi ya da değişen koşullara uyum sağlayabilmesi, etkin ve sürekli destek faaliyeti ile mümkün olabilir.

Ürünün üretilebilirliği ile ilgili yapılan tasarım güncellemelerinin desteklenebilirliği etkileyen unsurlara etkileri değerlendirilir ve gerek görülmesi halinde güncellemeler yapılır.

Kullanım safhası ve destek uygulama aşaması, ürünün envantere girmesinden envanterden çıkarılmasına kadar olan süre olup, bu safhada odak sistemin fiilen kullanımı ve istenilen performansta görevini yerine getirmesini sağlayacak lojistik destek faaliyetleri icra edilir.

Kullanım safhası ve destek uygulama aşamasında icra edilen faaliyetlere yönelik aşağıda belirtilen veriler sistemin iyileştirilmesi ve sistem performansının arttırılması maksadıyla kayıt altına alınır:

* Kullanım verileri,
* Lojistik destek verileri,
** Arıza durumu,
** Bakım faaliyetleri,
** Yedek parça (miktar, maliyet, tedarik durumu ve süresi vb.),

* Konfigürasyon verileri,
* Ömür devri verileri
** Fiziki ömür
** Ekonomik ömür
** Teknolojik ömür

* Tedarik ve ikmal verileri,
* Sistem ömür devri kullanım senaryolarındaki (stratejik kararlar) değişimler,
* Muharebe alanının coğrafi ve atmosferik şartlarındaki değişimler ve bu değişimlerin sistem üzerindeki etkileri,
* Sistem emniyet ve güvenlik zafiyetlerini önlemek için yapılan işlemler.

Zaman içinde, operasyonel ihtiyaçlarda ve destek sistem kabiliyetlerindeki değişiklikler takip edilir. Sistemin, görevini istenilen seviyede yerine getirip getirmediğini ve bakım faaliyetlerinin etkinliğini kontrol etmek amacıyla saha verilerine dayalı LDA yapılır. Desteklenebilirliğin istenilen seviyede tutulabilmesi için gerek görülen iyileştirmeler belirlenir ve uygulanır.

'''Envanterden Çıkarma Safhası'''

Sistemin yaklaşık kullanım ömrü ve envanterden çıkarma ile ilgili hususlar, sistem tedariki aşamasında belirlenmiş olmalıdır. Ekonomik, teknolojik veya fiziki ömrünü tamamlayan sistemlerin işletim ve destek maliyetleri artarken, sistem güvenilirlik ve hazır bulunuşluk değerleri ile sistem performansları düşer.

Bir sistemin envanterden çıkarılma kararı, sistemler için ayrılan kullanım, bakım ve idame maliyetlerini azaltmak, aşırı yedek parça stokunu önlemek ve mevcut stokların yıllara sâri olarak azaltılarak envanterden çıkış maliyetini düşürmek için yeterli süre öncesinde alınır.

Sistemin envanterden çıkarılmasına karar verilmesi için aşağıdaki hususların değerlendirilmiş olması gerekir:

* Kullanım ve destek destek safhalarında yapılan aşağıda verilen saha verilerine dayalı analizler ve değerlendirme sonuçları,
** Güvenilirlik analiz sonuçları,
** Hazır bulunuşluk analiz sonuçları,
** Bakım yapılabilirlik/onarılabilirlik analiz sonuçları,
** Demodelik analiz sonuçları,
** İnsan faktörü analiz sonuçları,
** Emniyet ve güvenlik analiz sonuçları,
** ELD donanımlarının uygunluğu ve yeterliliği,

* Tedarik edilebilirlik durumu,
** Yedek parça tedarik edilebilirlik durumu,
** Tedarik sürelerindeki değişim,
** Alt parçaların demodelik durumu,
** Üreticilerin üretim stratejilerindeki değişimler (üretimi durdurma, başka modele geçiş vb.)

* Sistem ömür devri verileri
** Ekonomik ömür,
** Fiziki ömür,
** Teknolojik ömür,

* Konfigürasyon yönetimi sistemi verileri,
* Yasal düzenlemer,
* Uluslararası anlaşmalar,
* Sistem performans değerleri,
* Sistemin mevcut muharebe görevi ve bu görevi yerine getirebilecek alternatif sistemlerin miktar ve yetenekleri,
* Güvenlik, emniyet ve risk oluşturma durumları,
* Muharebe gereksinimindeki (stratejik planlarda) değişiklikler,
* Mali kaynak durumu,
* Sistemin ihtiyaç duyduğu mühimmat, yedek parça veya sarf malzemesi.

Envanterden çıkarılması kararı alınan sistemler kademeli olarak envanterden çıkarılır. Öncelikle durumu en kötü olanlardan başlanır ve belli bir plan çerçevesinde ayıklamaya tabi tutulur. Ayıklamadan elde edilen yedek parçalardan kullanılabilir durumda olanlar, envanterdeki dayanıklı taşınır mal ve sistemlerin idamesinde kullanılır.

Envanterden çıkarma planı, gelişmelere bağlı olarak güncellenir. Güncellemede, yeni tedarik edilecek sistemlere ayrılan kaynağın yetersizliği, tedarikte yaşanan sorunlar, mevcut sistemin ihtiyacı karşılama durumu dikkate alınır. Envanterden çıkarma zamanı gerekirse uzatılır veya tehdit durumu, tedarik planında gecikmeler ve sistemin işletilmesinin maliyet etkin olmaması gibi hususlar dikkate alınarak ilgili sistemlerin daha kısa sürede envanter dışına çıkarılması için plan revize edilir.

İnsan ve çevre sağlığına zarar verebilecek işlemlerden kaçınılır, envanterden çıkarma işlemi yürütlükteki mevzuata uygun biçimde yapılır.

Envanterden çıkarma sürecinde elde edilen atıl konumdaki malzemelerden en fazla oranda fayda sağlamaya yönelik aşağıda sunulan alternatifler değerlendirilir;

* Ayıklanarak başka amaçlar için kullanılabilir,
* Diğer ülke, kurum ve kuruluşlara satılabilir, devir veya hibe edilebilir,
* Ar-Ge çalışması için üniversitelere veya araştırma kurumlarına hibe edilebilir,
* Sergilenmesi maksadıyla müzelere hibe edilebilir,
* Çevre düzenlemeleri için belediyelere veya üniversitelere hibe edilebilir,
* Hurda niteliğinde satılabilir.

== 6.2. PROJE ELD FAALİYETLERİ İLE İLİŞKİLİ DOKÜMANLAR ==
[[Dosya:Tablo 6 ELD Faaliyetleri Kapsamında Hazırlanacak ve Güncelenecek Dokümanlar.jpg|sol|küçükresim|714x714pik|Tablo 6 ELD Faaliyetleri Kapsamında Hazırlanacak ve Güncelenecek Dokümanlar]]

== 6.3. ACİL İHTİYACIN KARŞILANMASI ==
Acil ihtiyaç sebebiyle hazır ürün alımı yoluna gidilebilir. Ancak bu durumda da ortaya konulan çözüm, operasyonel görev profillerini eksiksiz olarak yerine getirmeli ve yüksek seviyede desteklenebilirlik özelliklerine sahip olmalıdır. Acil alım kararlarında; savunma ve güvenlik sistemlerinin lojistik desteğinin sağlanmasındaki zorluklar, kullanım safhasında ortaya çıkabilecek ilave maliyetler, kullanım kısıtları, yurtdışı bağımlılığın artması gibi hususlar dikkate alınmalıdır. Acil ihtiyaç kapsamında yer alan sistemler için de mutlaka gerekli uyarlamalar kapsamında LDA yapılmalı ve ELD Planları hazırlanmalıdır.

=== EK-A ELD PLAN ŞABLONU ===
Bu ELD Plan Şablonu genel hususları kapsayacak şekilde örnek olarak hazırlanmıştır. TÇD ve/veya Sözleşmelerde tedarik makamlarınca uygun görülen formatların kullanılması esastır. Ancak ELDP’nin hazırlanmasında bu şablonda yer alan hususların göz önünde bulundurulması gerekir.

[[Dosya:Şekil şablon.jpg|alt=|sol|küçükresim|539x539pik]]

[[Dosya:Hazırlayanlar.jpg|sol|küçükresim|462x462pik]]

'''DEĞİŞİKLİK KAYITLARI'''
[[Dosya:Değişiklik Kayıtları.jpg|sol|küçükresim|450x450pik]]

'''KISALTMALAR'''
[[Dosya:Kısaltmalar.jpg|sol|küçükresim|450x450pik]]

'''GENEL'''

(Bu ELDP şablonu başlıkları ve içeriği, ülkemizdeki uygulamalar, NATO Çok Uluslu Projelerde ELD Kılavuzu ve ASD/AIA ELD Spesifikasyonları dişkkate alınarak hazırlanmıştır. ELDP kapsamında aşağıda listelene on iki ELD elemanı yer almaktadır:

* Bakım
* İkmal Desteği
* İş gücü ve Personel
* Destek ve Test Ekipmanları
* Tasarıma Etki/Tasarım Etkileşimi
* Teknik Veri ve Dokümantasyon
* Eğitim ve Eğitim Desteği
* Tesisler ve Altyapı
* Paketleme, Elleçleme, Depolama, Ulaştırma (PEDU)
* Bilgisayar Kaynakları
* İdame Mühendisliği
* Ürün Destek Yönetimi

'''Giriş'''

[Bu kısımda, ELDP’nin amacı, kapsamı ve kullanımı hakkında bilgi verilir. Geçmiş süreç özetlenir ve planın geliştirilmesinde izlenen genel yaklaşım tanımlanır.]

'''Sistem Tanımı'''

[İhtiyacı karşılamak amacı ile önerilen sistem çözümü (Odak sistem/desteklenecek sistem) hakkında kısa bilgilendirme yapılır.

* Sistemin fonksiyonel gereksinimleri
* Sistemin fiziksel konfigürasyonu]

'''Program Yönetimi'''

[Tariflenen sistem çözümüne ilişkin tedarik ve geliştirme sürecini yöneten organizasyon, politika ve ilgili süreçler tanımlanır. Program yöneticisi ve katılım sağlayan diğer organizasyonlar, görev ve sorumluluklarıyla birlikte belirtilir. Gerekli iletişim bilgileri, sorumlular bazında aktarılır.]

''<Örnek Başı>''

''Sistemin ömür devri boyunca tanımlı performansını en az maliyet ve yüksek kullanıma hazır bulunma oranında sağlayabilmek için tüm ELD elemanları, organizasyon içinde ELD konusunda bilgili ve tecrübe sahibi ekip tarafından, organizasyonun kalite yönetim sisteminde tanımlı süreçlere uygun olarak planlanır, yürütülür, analiz edilir ve güncellenir. Bu amaçla ihtiyaç duyulacak kaynakların zamanında ve ihtiyaç duyulan yerde hazır bulundurulması sağlanır. ''

''Yüklenicinin organizasyon yapısına ilişkin bilgiler verilir.''

''Proje Yönetimi ve ELD organizasyon şemaları sunulur.''

''Tedarik makamı, ihtiyaç makamı, kullanıcı(lar), idame makamları, yüklenici, altyükleniciler ve tedarikçiler ile arayüzler tanımlanır.''

''İletişim yolları tanımlanır.''

''Temas noktaları tanımlanır.''

''<Örnek Sonu>''

'''Program Kilometre Taşları'''

[Tedarik programının ne zaman başladığını ve ELD görevlerinin ne zaman ve nasıl tamamlanacağını da içeren program kilometre taşları takvimi tanımlanır. Takvim, her program gözden geçirme öncesi ve önemli değişikliklerde güncellenir. Tipik bir takvim tüm zorunlu kilometre taşları ve önemli ara hedefleri gösterir. ELD takvimi proje uygulama takvimi ile uyumlu olmalıdır.

Güncellemenin kolaylığı açısından takvimi içeren tablolar ELDP’nin eki olarak sunulmalıdır.]

''<Örnek Başı> ''

{| class="wikitable"
|'''''Zaman (T0+ay)'''''
|'''''Tarih'''''
|'''''Açıklama'''''
|-
|''0''
|''Eylül 20xx''
|''Sözleşme imzalanması''
|-
|''1''
|''Ekim 20xx''
|''Program Başlangıç Gözden Geçirme''
|-
|''4''
|''Ocak 20xx''
|''Program Gözden Geçirme Toplantısı #1 / ''

''Sistem Gereksinimleri Gözden Geçirme ''
|-
|''7''
|''Nisan 20xx''
|''Ön Tasarım Gözden Geçirme''
|-
|9
|Eylül 20xx
|Program Gözden Geçirme Toplantısı #2
|-
|''11''
|''Ağustos 2004''
|''Kritik Tasarım Gözden Geçirme''
|-
|''…''
|''…''
|''…''
|-
|''30''
|''Mart 20xx''
|''Fabrika Kabul Testleri #1''
|-
|''30-32''
|''Mart 20xx ve Mayıs 20xx''
|''Xxx Eğitimi''
|-
|''31''
|''Nisan 20xx''
|''Teslimat''
|-
|''32''
|''Mayıs 20xx''
|''Destek ve Test Ekipmanları Teslimat''
|-
|''…''
|''…''
|''…''
|-
|''56''
|''Mayıs 20''
|''Program Kapanış Toplantısı''
|}
''<Örnek Sonu>''

'''İlgili Dokümanlar'''

[Tedarik programı ile uyumlu olacak biçimde, ELD faaliyetleri için ilave bilgi ve rehberlik sağlayacak dokümanlar listelenir. Referans numarası, doküman numarası, dokümanın tam adı, yayın tarihi ve versiyon bilgisi açık biçimde verilir. Yayın tarihi ve versiyon bilgisi olmayan dokümanların geçerli en son versiyonları kullanılır. ELDP içinde dokümanın kısa ismi referans numarası ile birlikte kullanılabilir.]

''<Örnek Başı> ''

{| class="wikitable"
|'''''Referans No'''''
|'''''Doküman No'''''
|'''''Doküman Adı'''''
|-
|''[1]''
|
|
|-
|''[2]''
|
|
|-
|''…''
|
|
|-
|
|
|
|-
|
|
|
|}
''<Örnek Sonu>''

'''TEDARİK PROGRAMINDA DESTEKLENEBİLİRLİK'''

[ELD hedeflerine erişebilmek, desteklenebilirliğin sağlanmış olmasına bağlıdır. Tedarik stratejisi kapsamında desteklenebilirlik planlamasına girdi sağlayacak gereksinimler, hedefler, bütçe kısıtları ve desteklenebilirlik analizi stratejisi vb. bu kısımda tanımlanır. ]

'''Operasyonel ve Desteklenebilirlik Gereksinimleri'''

[Görev senaryoları ve gerekleri, operasyonel çevre koşulları, güvenlik gereksinimleri, taşıma gereksinimleri, istihdam, konuşlanma planları, muharebe hizmet destek unsurları vb. hususlar kısaca tanımlanır. Gereksinim dokümanları, desteklenebilirlik analizlerine girdi olması amacıyla yıllık çalışma günü, yıllık görev sayısı, ortalama görev süresi gibi ihtiyaç duyulan detayları sağlamalıdır. Barış, savaş ve kriz dönemleri için önerilen sistem göreve hazır bulunma hedefleri ve bu hedefleri destekleyen RAM eşik değerleri tanımlanır. Sistemin görevi tam yapabilmesi ya da görevde öngörülen seviyedeki başarıyı sağlayabilmesi için gereksinimler listelenir. Uygulanabilir bir hazır bulunma raporlama sistemi, kullanılabilecek formlar ve raporlama sıklığı kararlaştırılır.]

''<Örnek Başı>''

''Harekât Çevre Koşulları''

''Kullanım Konsepti (Savaş, Barış, Kriz)''

''Görev Profilleri''

''Kullanıma Hazır Bulunma Gereksinimleri''

''Güvenilirlik Gereksinimleri''

''İdame Edilebilirlik Gereksinimleri''

''Test Edilebilirlik Gereksinimleri''

''Demodelik Yönetimi''

''Diğer Gereksinimler''

''İyileştirilebilir tasarım, ''

''Desteklenebilir sistem mimarisi, ''

''Standardizasyon, ''

''Entegre bakım desteği (CİT vb.),''

''İnsan mühendisliği,''

''Emniyet, ''

''Kullanım kolaylığı, ''

''Düşük riskli destek unsurları, ''

''İzleme kolaylığı, ''

''Yazılım desteği, ''

''Envanterden çıkarma kolaylığı, ''

''…''

''<Örnek Sonu>''

'''Tedarik Stratejisi'''

[Bu başlıkta kabul edilen tedarik yaklaşımı tanımlanır. Başlangıçta, ihtiyaç duyulan gereksinimlerin sistem modifikasyonu, teknoloji transferi, yeni tasarım veya ticari hazır ürün gibi seçeneklerle karşılanabilmesi durumları söz konusu olabilir. Kabul edilen durum için sözleşmesel yaklaşım ve teşvik hususları tanımlanır.]

'''Destek Riskleri'''

[Tanımlı tedarik stratejisi kapsamında öngörülen destek konsepti ve (varsa) alternatif destek konseptleri ile ilişkili riskler bu başlık altında tanımlanır. En az aşağıdaki alanlar değerlendirilebilir:

Bakım/onarım kabiliyeti seviyesinin değiştirilmesinin etkileri nelerdir?

Envanterde yeni ürün geliştirilmesinden kaynaklanan riskleri azaltabilecek birimler veya alt sistemler mevcut mudur?

Önerilen sistem çözümü destek organizasyonuna nasıl entegre edilecektir?]

'''Personel Gereksinimleri'''

[Sistemin kullanımı, desteklenmesi ve idamesinde görev alacak personelin yüksek kabiliyet seviyelerine sahip olması ihtiyacını azaltmak için alınacak önlemler ve hedefler tanımlanır. Kullanım ve destek maliyetlerini azaltmak için yaklaşımlar ve teşvik hususları belirtilir.]

'''Kaynak Tercihi'''

[Kaynak seçim sürecinde ELD ve desteklenebilirliğin nasıl adresleneceği tanımlanır. Beklenen tedarik maliyetine ek olarak tahmini kullanım, bakım ve destek maliyetlerinin, kaynak değerlendirme sürecinde göz önünde bulundurulabilmesi amacıyla planlar aktarılır.]

'''Tedarikte Destek Elemanları'''

[Sözleşme dokümanlarında yer alan, ELD elemanlarına ilişkin gereksinimler adreslenir. Hızlandırılmış tedarik söz konusu ise hangi kalemlerin hızlandırılma ihtiyacı olacağı ve nasıl gerçekleştirileceği belirtilir. Standart dışı bütçe ihtiyaçları listelenir.]

'''Planlı Konuşlanma ve İstihdam'''

[Planlanan operasyonel konseptler tanımlanmalıdır.]

'''Performansa Dayalı Lojistik (PDL)'''

[Diğer sözleşme türlerine göre faydalarını içerecek şekilde PDL stratejisi ve uygulaması tartışılır.]

'''ELD/Desteklenebilirlik Bütçesi-ÖDM'''

Yürütülecek çalışmaların kapsamı ve derinliğini belirlemek için toplam ÖDM’nin başta tasarıma etki/tasarım etkileşimi olmak üzere ilgili ELD elemanları altında belirlenmesinde kullanılacak ve güncellenecek çalışmalar tanımlanır. Desteğin, birim yöneticilerine ve idameyi sağlayacak/sorumlu olacak makamlara geçişi için gerekli planlamalar çalışmalara dahil edilir.

Maliyet tahmininde kullanılacak model ve uyarlamalar ile modellemede geçerli olacak kısıtlamalar ve varsayımlara ilişkin bilgiler, tedarik makamından alınmalıdır. Koordinasyon/iletişim kanalları ve raporlama takvimi belirtilir. Gereksinimleri de içerecek şekilde ELD elemanları, başlıca fonksiyonlar, kullanım ve idame için maliyet tahmini sonuçları belirtilir.]

'''Desteklenebilirlik Analizi Stratejisi'''

[Tedarik sürecinde yürütülmesi planlanan desteklenebilirlik analizi tanımlanır ve varsa gerekli spesifik analizler belirtilir. Aşağıdaki hususlar kapsamında kısa açıklamalar aktarılır:

Seçilen desteklenebilirlik analizinin tedarik programı ihtiyaçları ve safhalarına göre nasıl uyarlanacağı tanımlanır.

ELD elemanlarının geliştirilmesine girdi sağlayacak lojistik yönetim bilgisinin nasıl kullanılacağı tanımlanır.

Lojistik yönetim bilgisi üretilecek ve dokümante edilecek her donanım/yazılım için kırılım ve bakım seviyesi belirtilir.

Verinin yeterlilik ve tutarlılık açısından nasıl doğrulanacağı ve bu kapsamdaki sorumluluklar tanımlanır.

Desteklenebilirlik analizleri için veri kaynakları belirtilir. Veri tekrarını ve tutarsız veriyi önleyecek kontroller aktarılır ve daha önceki safhalarda gerçekleştirilen desteklenebilirlik analiz sonuçları özetlenir.]

''<Örnek Başı>''

''ASD/AIA S3000L spesifikasyonuna uygun olarak LDA gerçekleştirilecektir. Seçilen desteklenebilirlik analizleri, program ihtiyaçları ve aşamalarına göre güncellenebilecektir. Lojistik bilgi ve veri üretilecek her konfigürasyon birimi için gereksinimler sağlanacak ve ürün kırılımları aktarılacaktır.''

''Sistem mühendisliği koordinasyonu ile analizlere girdi olacak veri kaynakları kontrol edilecektir. Aşağıdaki analizlerin yapılması planlanmaktadır:''

''FMEA/FMECA''

''FTA''

''RCM''

''DSEA (Damage and Special Event Analysis)''

''MTA''

''LORA''

''RAM analizleri''

''Yedek parça analizleri''

''<Örnek Sonu>''

'''Desteklenebilirlik Test ve Değerlendirmesi'''

[Planlanan test ve değerlendirme konsepti, kapsamı, hedefleri ve geliştirme testlerinde ve operasyonel testlerde nasıl karşılanacakları kısaca tanımlanır. Desteklenebilirlik test konularını tanımlayacak organizasyonlar listelenir. Bu konular ve amaçlar ELDP içinde özetlenir ve Test ve Değerlendirme Ana Planına dahil edilir. Bu kapsamda dikkate alınması gerekli hususlar en az aşağıdakileri içermelidir:

ELDP ile doğrudan ilişkili özel test gereksinimleri,

Beklenen kritik desteklenebilirlik hususları ve destek planlamasına etkileri,

Kritik hususların çözümlerinin değerlendirilmesi için ihtiyaç duyulan test ve değerlendirme,

Test ve değerlendirme işlemleri için gerekli eğitim, iş gücü ve yetenekler,

Desteklenebilirlik hususlarını çözmek için gerekli aksiyonların başlangıç ve bitiş tarihleri,

Lojistik Yönetim Bilgisi ve test verisi toplama sistemleri arasında arayüzler,

Cihaz içi veya destekleyici otomatik çalıştırma, test ve bakım ekipmanlarının test ve değerlendirmesi (mümkün olduğunca ilgili yazılımları da kapsayacak biçimde),

Tamamlanan test sonuçlarının planlı test aksiyonlarını, kriterlerini, gereksinimlerini, vs. nasıl etkileyeceği,

Önerilen test lokasyonları, veri toplama prosedürleri ve veri kullanımı, test ve değerlendirme faaliyetlerinde görev alan organizasyonlar ve sorumluluklarını da içerecek şekilde başlıca önlemler ve faaliyetlerin özetinin sağlanması,
Lojistik Yönetim Bilgisi ve sistem destek paketi bileşenlerini, taslak ya da son sürüm teknik yayınları, bütün test, ölçüm ve diagnostik ekipmanlarını, bakım kademe yetki tablolarını, onarım parçaları/özel onarım alet listeleri, kurtarma ekipmanları vb. doğrulayan lojistik demonstrasyon planları,

[Lojistik demonstrasyon, prototip ürün ya da yazılım hazır olduğunda en kısa sürede gerçekleştirilmelidir. Lojistik demonstrasyon, geliştirmeye yönelik ve operasyonel testler öncesinde kaynakların ve sistem destek paketi bileşenlerinin hazır bulunuşluğuna imkan verecek bir zamanlama ile tamamlanmalıdır. ]

Prototip ürün/yazılım geliştirme için gereklerin ve kullanılacak metotların tanımlanması.]

'''ELD ELEMANLARI PLANI'''

[Her ELD elemanı için detaylı şekilde planlamalar bu bölümde aktarılacaktır. ELD elemanlarına yönelik gereksinimler ve aktarılması gereken durumlar eksiksiz paylaşılacaktır. Bu bölümde ELD elemanları özelinde personel gereksinimlerine ve kısıtlara da yer verilir.]

'''Bakım'''

[Bütün bakım seviyelerini içerecek şekilde sistem bakım konsepti tanımlanır. Sisteme özgü bakım yaklaşımı kapsamında yürütülecek getiri-götürü değerlendirmeleri aktarılır.

Tanımlı hazır bulunma seviyelerinde görev yapabilmek için gerekli bakım görevleri tanımlanır.

Lojistik analizler sonucu ortaya çıkan destek konsepti aktarılır. Her bakım seviyesi için önerilen ve mevcut olan yetenekler, el aletleri, test, güvenlik prosedürleri, destek, kalibrasyon, ölçüm ve teşhis ekipmanları vb. belirtilir. Bileşenlerin ve onarım parçalarının sökülme durumları için muhtemel tasarımlara yönelik analizler bu bölüme dahil edilir.

Her destek alternatifinin zayıf ve güçlü yönleri ve destek konseptinin sistem tasarımı, tedarik ve işletme-destek maliyetleri ve etkilenen ELD elemanlarına etkileri aktarılır.

Çok uluslu kullanım amacıyla tedarik edilen sistemlerde merkezi bakım ve ikmal desteğinin fizibilite çalışmaları tariflenir.

Bakım ortamı aşağıdakileri içerecek şekilde tariflenir:

Bakım ortamı, kısıtlamalar ve konuşlanma takvimi için gereksinimler tanımlanır. Arızalı birim geri dönüş süreleri, yıllık direkt bakım işçiliği vb. detaylar desteklenebilirlik analizlerinde kullanılmak üzere aktarılır. Gereksinim dokümanlarında aktarılan lojistik destek parametreleri listelenir. İhtiyaç duyulması halinde lojistik yönetim bilgisine başvurulur.

Savaş hasarı, yerinde onarım prosedürleri gibi özel durumları da içerecek şekilde her bakım seviyesinde gerçekleştirilecek bakım faaliyetlerinin kapsamı belirtilir. Alternatif yaklaşımlar değerlendirilir ve seçim sürecinde faydalanılan kriterler tanımlanır.

İkmal ve bakım desteği sağlayacak lojistik destek yapısı tanımlanır.

Özel görevler kapsamında söz konusu olabilecek destek aktiviteleri, özel onarım faaliyetleri ve onarım lokasyonları tanımlanır.

Kullanım ve depolama yerlerine ve sarf istatistiklerine göre bakım malzemeleri ihtiyacı tanımlanır.

Ürünün performans ve maliyet açısından en uygun şekilde desteklenmesini sağlayacak bakım seviyeleri tanımlanır.

Bakım sırasında ortaya çıkabilecek muhtemel emniyet risklerini en aza indirecek çalışmalar belirtilir.

Çevresel riskler açısından nükleer, biyolojik ve kimyasal kirliliğe ilişkin bakım konseptleri ve özel gereksinimler listelenir.]

'''İkmal Desteği'''

İkmal; bir askerî birlik ve kurumun teçhizi, bakımı ve harekâtı için ihtiyaç duyulan her türlü ikmal maddelerinin cins ve miktarlarının tespiti, tedariki, depolanması ve depodayken bakımı, dağıtımı ve son işlemi faaliyetlerini kapsar.

İkmal destek unsurunun amacı, “mümkün olan en düşük ÖDM’de en iyi kabiliyetin kullanıma hazır olması”nı sağlayabilmek için gerekli onarım parçaları, yedekleri ve bütün ikmal sınıflarını tedarik etmek için yönetim faaliyetlerinin belirlenmesi, planlanması, söz konusu faaliyetlere yönelik kaynağın sağlanması ve faaliyetlerin icra edilmesidir. Bu kapsamda üretilen tedarik verisi; satın alınacak, kontrol edilecek, paketlenerek son kullanıcıya teslim edilecek ürünlere ait tanımlama, açıklama ve test bilgilerini içerir.

Önerilen ikmal desteği konsepti, kısıtlamalar ile sisteme ve destek ekipmanlarına özgü gereksinimler tanımlanır. Bu kapsamda aşağıdaki hususlar değerlendirilir:

Standart ikmal desteği prosedürlerinden potansiyel sapmalar tanımlanır. Bunların maliyet, iş gücü, hazır bulunma vb. faktörlere olan etkileri değerlendirilir.

Uygulanabilir seviyede, onarım parçaları, mühimmat, petrol ürünleri ve yağlar, kritik parçalar ve yardımcı birimler, özel ve ortak el aletleri ve destek ve test ekipmanları için kataloglama, tedarik, paketleme, muhafaza, fatura, depolama ve elden çıkarma planı tanımlanır.

Desteklenebilirlik analizi/lojistik yönetim bilgisi, saha tecrübeleri ve test verilerine göre kullanım ve arıza verilerinin gözden geçirilmesi ve düzenlenmesi için planlar belirtilir.

Aşağıdaki hususlarda yapılan planlamalar aktarılır:

İhtiyaç duyulan ikmal desteği için kapsam, miktar ve özel gereksinimlerin belirlenmesi,

Uzun teslim sürelerine sahip birimler ve dışarıdan alınan birimlerin tanımlanması,

Kritik parçalar, hizmetler ve ekipmanların tanımlanması,

Yeniden tedarik (Re-procurement),

Devlet malı malzemelerin tanımlanması,

Nükleer kritik malzemelerin tanımlanması,

İkmal desteği yöntemi ve tipi (örneğin, parça değişimlerinin küçük parça, takım, modül veya fabrikasyon konsepti) tanımlanması,

Hizmet alımları arasında ikmal desteği açısından oluşabilecek boşluklara ilişkin olarak ikmal desteği anlaşmalarında olası ihtiyaçların tariflenmesi,

Temin çalışmalarına tedarik programının etkilerinin değerlendirilmesi,

Diğer ikmal desteği organizasyonları için gerekli bilgilerin sağlanması,

Operasyonlar sırasında tüketilen temel sürdürülebilirlik malzemeleri (mühimmat, petrol ürünleri, yağlar, güç kaynakları, diğer sarf malzemeler vb.) için gereklerin tanımlanması. Gereksinimler farklı görev profillerine göre uyarlanır.]

'''İş gücü ve Personel'''

[İş gücü, belirli bir işin yapılabilmesi için gerekli olan personel veya pozisyon sayısını; personel ise, işin doğru şekilde yapılabilmesi için gerekli olan yetenek ve kabiliyetler, bilgi, beceri ve tecrübe seviyelerine sahip olmayı ifade eder.

Sistem çözümünün kullanıcı ve bakım iş gücü tanımlanır. Test edilmesi önerilen birimler için iş gücünün nasıl sağlanacağı tariflenir. Bu hususlara kısıtlamalar, sisteme özgü gerekler ve insan-makine arayüzü dahil edilir. Savaş, barış ve kriz dönemi gereksinimleri için kuvvet yapısı değerlendirilir.

Sistemin kullanımı, bakımı ve desteği için gerekli personelin yetenek gereksinimleri aktarılır. Sistem kullanımı, bakımı ve taşınması esnasında insan arayüzü problemlerini en aza indirecek emniyet ve insan mühendisliği kısıtları tanımlanır. Bu tanımlamalara uygulanabilir ölçüde sistem emniyet ve tehlike değerlendirme gereksinimleri ve sonuçları dahil edilir.]

'''Destek ve Test Ekipmanları'''

[Destek ekipmanı, ürünün destek ve idamesi için gerekli olan her türlü ekipmanı kapsayan bir ifadedir. Kapsamına, çok kullanımlı destek elemanları, el aletleri/avandanlıklar, meteoroloji ve kalibrasyon ekipmanları, manuel/otomatik test ekipmanları dahildir.

Destek ekipmanı gereksinimlerini tanımlamak için kullanılan prosedürler tanımlanır.

Stoklarda yer alan standart destek ekipmanlarının değerlendirilmesi için gereksinimler tanımlanır. Standart destek, kalibrasyon, ölçüm ve test aletlerinin kullanımını en üst seviyede mümkün kılacak prosedürler aktarılır.

Kıt destek kaynakları için gereksinimleri içerebilmesi adına destekle ilgili donanımın ana öğeleri tanımlanır.

Destek ve test ekipmanları ve DKÖT’e özgü donanım test, geliştirme ve destek gereksinimleri tanımlanır. DKÖT’ler vb. birimler için çevresel ve depolama gereksinimleri belirtilir.

Destek ve test ekipmanları ve DKÖT’e özgü test ve değerlendirme amaçları tanımlanır ve test ve değerlendirme ana planları için gerekli girdiler sağlanır.]

'''Tasarıma Etki/TasarımEtkileşimi'''

[ELD ve ÖDM’nin kaynak seçimi, sistem tasarımı ve tedarik kararlarını nasıl etkileyeceği tanımlanır. Tasarım önerilerinde ve önerilen mühendislik değişikliklerinde ELD’nin bütün olarak dikkate alınmasını sağlamak için ELD ve diğer planlara ilişkin tasarım kısıtları açıklanır. Tasarım gözden geçirmeleri ve alternatif değerlendirme çalışmalarına ELD personelinin katılımı sağlanır.

İklimsel kısıtlar, çevre ve enerji kısıtları ve insiyatiflerin yanı sıra ilgili alternatif değerlendirmeleri tanımlanır.

Yeni teknolojileri tanımlamak için bağımsız Ar-Ge programları ve diğer desteklenebilirlik çalışmaları tanımlanır.

Lojistik ile ilişkili dayanıklılık ve hayatta kalma/beka kabiliyeti (survivability) tanımlanır.

Komponent ve ana parça standardizasyonu ve birlikte çalışabilirlik gereksinimleri aktarılır.

Sistem tasarımını etkileyebilecek kazanılmış dersler ve benzeri sistemlere yönelik tecrübelerin uygulanabilirliği aktarılır.]

''<Örnek Başı>''

''Ömür Devri Maliyet Analizi''

''LDA''

''RAMST Analizleri''

''<Örnek Sonu>''

'''Teknik Veri ve Dokümantasyon'''

[Kayıt şekli ya da yönteminden bağımsız olarak bilimsel ve teknik içerikli kayıtlı veri ve bilgilerdir. Bilgisayar yazılımı, finansal ya da idari bilgiler gibi sözleşme yönetim bilgileri teknik veri ve dokümantasyon kapsamına girmez.

Teknik veri elemanının başlıca iki hedefi mevcuttur:

Bilgiyi elde etme ve bakım faaliyetlerini tanımlama, planlama, doğrulama, kaynak tespiti ve yürütme,

Teknik yayın planlama, geliştirme, üretim ve bakımı.

Bu bölümde teknik yayın konsepti aktarılır.

Doküman güncelleme ve sonlandırma gereksinimleri belirtilir. Bu kapsamda sistem üretim takvimleri ile koordinasyon sağlanması önemlidir. Onarım parçaları listesi, destek ekipmanları listesi, görev tahsisatı ve teknik yayınların kullanım ve bakım talimatları açıklamaları arasında uyumluluk sağlamak için Lojistik Yönetim Bilgisinin kaynak girdi olarak teknik yayın hazırlıklarında nasıl kullanılacağı tarif edilir.

Teknik yayınların geçerli kılma ve doğrulama kriterleri belirtilir ve test desteği anlamında ihtiyaç duyulabilecek miktar ve teknik yayın çeşitleri belirlenir.

Son versiyon teknik yayınların hazırlanma ve basım takvimleri tanımlanır.

Teknik veri paketine ihtiyaç duyulup duyulmadığına karar vermek için plan tanımlanır, tedarik stratejisine etkileri değerlendirilir.]

'''Eğitim ve Eğitim Desteği'''

[Eğitim ve eğitim araçları gereksinimlerinin nasıl karşılanacağı ve bu gereksinimleri karşılamada kimlerin sorumlu olacağı tanımlanır. Eğitim test ve doğrulama prosedürleri aktarılır. Hedef kitle ve eğitim kısıtları hakkında bilgi sağlanır.

Uzun dönemli eğitim tesis gereksinimleri hakkında bilgi sağlanır.

İhtiyaç duyulan eğitim ve eğitim araçlarının tedarik planı tariflenir.

Donanım, yazılım, insan arayüzü, destek birimleri ve test ekipmanlarının kullanım ve bakım faaliyetlerine özgü, eğitim kurumlarından alınması gerekebilecek eğitimler ve planlar değerlendirilir.

Hassas, sınıflandırılmış veya tehlikeli bileşenler, parça, malzeme ve mühimmat için harekât ve depolama faaliyetleri kapsamında ihtiyaç duyulabilecek standart dışı PEDU eğitim gereksinimleri tanımlanır.]

'''Tesisler ve Altyapı'''

[Odak sistem ve destek ekipmanlarının kullanımı, depolanması, test edilmesi, eğitim faaliyetleri, bakımı ve envanterden çıkarılması süreçlerinde ihtiyaç duyulacak tesis ve altyapı gereksinimleri tanımlanır. Planlı bakım, kalibrasyon, yazılım kurulumu, depolama, eğitim ve personel tesisleri gereksinimleri ve kısıtları tanımlanır.

Mevcut sabit ve hareketli tesislerin kabiliyetleri ve eksiklikleri odak sistemin kendisi ile bakım ve destek ihtiyaçları için tanımlanır. Tanımlanan eksiklikleri giderebilecek modifikasyon gereksinimleri listelenir. Modifikasyona uğrayacak ya da yeni kurulacak tesisler için program yönetimi gerekleri aktarılır. Tesis güvenlik gereksinimleri tanımlanır.]

'''Paketleme, Elleçleme, Depolama ve Ulaşım (PEDU)'''

[Sisteme özgü gereksinimler ile yönetim sorumlulukları ve prosedürler, tedarik sürecinde PEDU gereksinimlerinin tanımlanması ve zamanında karşılanması maksadıyla tanımlanır.

Öngörülen PEDU seçenekleri ve kısıtları tanımlanır.

Sistemin, bileşenlerin, parçaların ve test ekipmanlarının depolama ve iklimsel gereksinimleri belirtilir.

Tanımlanan lojistik problemlerin çözümlerine, PEDU gereksinimleri ve risklerinin değerlendirilmesinin dahil edilmesi için yapılacak faaliyetler belirlenir.

İlk ürün ile birlikte kullanıma hazır olması beklenen ve gerekli olan PEDU hususları tanımlanır.

PEDU sistemleri ve prosedürlerinin, mevcut ve projelendirilmiş değişiklikleri tanımlanır. Paralelde geliştirilen, entegrasyonu yapılan ya da test edilen PEDU ekipmanları ile arayüzler belirlenir.

PEDU test gereksinimlerinin tanımlandığı ve test ve değerlendirme ana planlarına dahil edildiği doğrulanır.

PEDU faaliyetleri sırasında dikkat edilecek özel hususlar tanımlanır.

Paketleme, depolama ve ulaştırmaya ilişkin hususlar

* Paketleme ve Paketi Açma
* Güvenlik
* Koruma
* Depolama
* Zararlı Madde Taşıma
* Yük Sandığı Konsepti
* Kaldırma
* Ulaştırma Şartları
* ….

Elleçleme ve kullanıma hazır hale getirmeye ilişkin hususlar:

* Emniyet İkazları
* Kullanım Talimatı
* Kullanım
* Yükleme ve boşaltma
* Çekme Taşıma Ekipmanı
* Kullanım Değişikliği
* Konuşlandırma
* Ürün koruma
* Buzlanma Önlemi
* Elektrik Yük Kontrolü
* Manyetik Dayanım Kontrolü
* İstatistiksel Veri Kayıtları
* …

Sistem sevkiyatı kapsamında kullanılabilecek konteynırların belirlenmesi için gerekli aksiyonlar listelenir.

Sistem çözümü için uygun depolama standardı belirtilir.

Birim ve kuvvet konuşlanabilirliği ile ilişki olanları da içerecek şekilde özel ulaştırma sorumlulukları, gereksinimleri ve kısıtları tanımlanır. Gerekli stratejik ve taktik taşıma modları ve araç tipi tanımlanır. Kullanıcının taşıma kısıtları, konteynır uyumluluğunu içerecek şekilde belirlenir. Uygun zamanlarda tasarım ve performans değerlendirmeleri gerçekleştirilir.

Ekipman gönderimi için katılım sağlayan hizmetlere özgü özel gereksinimleri içerecek şekilde ulaşım ihtiyaçları tanımlanır.

Hava/Kara/Deniz taşımacılığı kullanılacaksa uygun araç tipine göre yükleme ve boşaltma konfigürasyon düzeni açıklanır. Ağırlık ve hacim dahil edilir.

Kaldırma ve bağlama gereksinimleri ve prosedürlerinin son sistem konfigürasyonunda yer almasını sağlamak için gereksinimler tanımlanır.]

'''Bilgisayar Kaynakları'''

[Görev kritik bilgisayar donanım/yazılım sistemlerinin kullanımı ve desteği için gerekli olan tesis, donanım, yazılım, dokümantasyon ve iş gücü ihtiyacını kapsar. Amacı, görev kritik bilgisayar donanım ve/veya yazılım sistemlerinin planlanması ve yönetimi için gerekli olan kaynakların tespiti, planlanması ve tahsisinin gerçekleştirilmesidir.]

'''İdame Mühendisliği'''

[Bu ELD elemanının amacı, kullanımda olan ürünleri bulundukları operasyonel çevre koşullarında desteklemektir. Bu faaliyet envanterde bulunan ve/veya envantere alınan bir sistemin kullanımı ve desteklenmesi için gerekli olan tüm teknik görevleri kapsar (mühendislik ve lojistik incelemeler, analizler vb). İdame Mühendisliği, sistemin kullanım ömrü boyunca kusurlarının belirlenmesi, gözden geçirilmesi, değerlendirilmesi ve çözüme kavuşturulmasını içerir. İdame mühendisliği faaliyetleri iki ana başlık altında toplanabilir:

Kusurların belirlenmesi ve teknik analizlerin gerçekleştirilmesi.

Çözümlerin geliştirilmesi.]

'''Ürün Destek Yönetimi (ÜDY)'''

[Ürün Destek Yönetimi (ÜDY); bütün ELD elemanlarını kapsayacak şekilde ürün desteğinin planlanması, yönetilmesi ve finanse edilmesini kapsar. Destek konseptinin ve ELDP’nin hazırlanması, geliştirilmesi ve detaylandırılmasının yanı sıra demodelik planının hazırlanması ve raporunun oluşturulması da bu ELD elemanı bünyesinde gerçekleştirilen faaliyetlerdendir. ÜDY, belirli bir sistem veya hizmet için ELD ihtiyaçlarının detaylandırıldığı ELD elemanıdır. Bu doğrultuda dört temel faaliyet gerçekleştirilir:

Ürün Destek Gereksinimlerinin Toplanması

ELDP’nin Hazırlanması ve Geliştirilmesi

Sözleşme Yönetimi

Demodelik Yönetimi]

'''KULLANIMA ALMA VE KULLANIM DESTEĞİNİN SAĞLANMASI'''

'''Kullanıma Alma'''

[Program kapsamında hedeflenen ilk harekât yeteneği sağlanabilmesi için yapılan planlama aktarılır. Sistem kullanıma alma dokümantasyonu hazırlanması için prosedürler ve takvim özetlenir. Kullanıma alma faaliyetinin nasıl yürütüleceği hakkında bilgi verilir.]

'''Program Geçişi'''

[Bu yönde bir düzenleme öngörülmüşse programın program yönetim organizasyonundan idameden sorumlu destek organizasyonuna nasıl ve ne zaman devredileceği ile ilgili açıklama verilir. Geçmişte edinilmiş tecrübelerden bu program için uygulanabilecek olanlar belirtilir. Onarım parçası kullanımı, eğitim, teknik veri vb. bilgilerin nasıl toplanacağı ve kullanılacağı gösterilir. Sistemin kullanımı için yeterli seviyede ikmal, eğitim ve sistem idamesi için gerekli tüm veriler detaylı olarak sağlanır.]

'''Üretim Sonrası Destek'''

[Geliştirme safhasının erken dönemlerinde başlangıç Üretim Sonrası Destek Planı oluşturulur. Kullanım safhasındaki lojistik desteğin sürdürülebilirliği için kaynakları ve yönetim adımlarını içeren bu plan ürün destek stratejisi ve modeli ile uyum içinde olmalıdır (Bkz. TSSÖDYP-03 Ürün Destek Stratejileri ve Modelleri Rehberi). Üretim Sonrası destek planının güncel tutulması için güncelleme takvimi oluşturulmalıdır. Üretim safhası öncesinde, sonrasında ve destek safhası içinde kayda değer değişiklikler olduğunda plan güncellenmelidir.]

'''Kullanıma Alma Sonrası Destek Analizi'''

[Sistem ömür devri boyunca en az destek maliyeti ile yüksek kullanıma/göreve hazır olma değerlerinin sağlanması önemlidir. Kullanıma alma sonrası sistem desteğini izlemek için bir plan geliştirilmelidir. Kullanıma/göreve hazır olma ve destek ölçümleri/verileri, veri kaynakları, veri analiz yöntemleri ve sistem desteklenebilirliğini geliştirecek ya da ELD problemlerini düzeltecek prosedürler tanımlanır.]

'''Envanterden Çıkarma'''

[Beklenen sistem ömrü uzun olsa bile ELDP içeriğinde envanterden çıkarma faaliyetlerinin tanımlanması ihmal edilmemelidir. Envanterden çıkarılan malzemenin ekonomik açıdan değeri yüksek olmasa da çevreye olası etkileri elden çıkarma planlamasında dikkate alınacaktır. Sistem ömrünün herhangi bir anında kaza ya da büyük hasara yol açan arıza gibi durumlarda envanterden çıkarma faaliyetlerine başvurabilme ihtimali de envanterden çıkarma planlarının geliştirilmesini gerektirir.]

'''DOKÜMANIN HAZIRLANMASINDA GÖREV ALAN KURUM/KURULUŞLAR'''

SAVUNMA SANAYİİ BAŞKANLIĞI

ASELSAN A.Ş.

BMC POWER MOTOR VE KONTROL TEKNOLOJİLERİ A.Ş.

FNSS SAVUNMA SİSTEMLERİ A.Ş.

HAVELSAN A.Ş.

METEKSAN SAVUNMA SANAYİ A.Ş.

ROKETSAN A.Ş.

TUBİTAK BİLGEM İLTAREN

YATEM BİLİŞİM VE TEKNOLOJİ SİSTEMLERİ A.Ş.

Dosya:TSSODYP-04 ELD Rehberi 20230113.pdf

2023-01-13T10:49:44Z

Oozdemir:

Sistem Ömür Devri Yönetimi Rehberi (Ana Çerçeve)

2023-01-13T10:48:03Z

Oozdemir:

'''[https://tssodypwiki.ssb.gov.tr/images/6/66/TSSODYP-01_Sistem_%C3%96m%C3%BCr_Devri_Y%C3%B6netimi_Rehberi_%28Ana_%C3%87er%C3%A7eve%29_20230103.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şkanlığı çatısı altında, ilgili tüm paydaşların katılımıyla faaliyet göstermek üzere Türk Savunma Sanayii Ömür Devri Yönetimi Platformu (TSSÖDYP) kurulmuştur.

TSSÖDYP; savunma ve güvenlik sistemlerine ilişkin ihtiyacın belirlenmesi, sistemlerin tedariki, kullanımı, desteklenmesi ve envanterden çıkarması safhalarını bir bütün halinde ele alan Sistem Ömür Devri Yönetimi ilke ve uygulamalarının ülkemizde yaygınlaştırılmasını ve savunma programlarının/ projelerinin yürütülmesinde savunma ve güvenlik ekosistemini oluşturan tüm paydaşlarca anlayış birliğine ulaşılmasını amaçlamaktadır.

Savunma sistemlerinin ömür devri yönetiminde millî bünyemize uygun, ülkemize özgü çözümler üretmek ve bunları dokümante etmek gibi önemli bir misyonu olan TSSÖDYP; Başkanlığımız, Milli Savunma Bakanlığı ve ilgili birimleri, Genelkurmay Başkanlığı, K.K.K.lığı, Dz.K.K.lığı, Hv.K.K.lığı, J.Gn.K.lığı, S.G.K.lığı, EGM, TÜBİTAK, SASAD ve savunma sanayii firmaları temsilcilerinin katılımı ile çalışmalarına devam etmektedir.

Sistem ömür devri yönetimi yaklaşımı ile; savunma ve güvenlik sistemlerine ilişkin ihtiyacın belirlenmesi aşamasından envanterden çıkarma safhasının sonuna kadar görev alan tüm kamu kurum ve kuruluşları ile özel sektör firmalarının sistemlerin istenilen performans seviyesinde mümkün olan en az maliyetle tedariki, kullanımı ve lojistik desteğinin sağlanabilmesi için görev, yetki ve sorumlulukları çerçevesinde ömür devrinin tamamında birlikte çalışmaları öngörülmektedir.

Bu itibarla, savunma ve güvenlik sistemlerine ilişkin ihtiyacın belirlenmesinin, tedarikinin, kullanımının, lojistik desteğinin ve envanterden çıkarılmasının en baştan uzun soluklu bir program olarak kurgulanmasının ve ilgili birimler aracılığı ile sistem ömür devri yönetimi faaliyetlerinin yürütülmesinin faydalı olacağı değerlendirilmektedir.

TSSÖDYP tarafından son iki buçuk yıl içinde gerçekleştirilen çalışmalar ile savunma ve güvenlik sistemlerinin ömür devri yönetimine ilişkin planlama ve uygulamaya esas olacak yaklaşımları ortaya koyan 13 adet rehber, iki adet bilgi kitapçığı ve bir adet terminoloji dokümanı hazırlanmıştır. Uygulamalardan alınacak geri bildirimler ile söz konusu dokümanların güncellenmesi, geliştirilmesi ve önümüzdeki dönemde uygulamaya esas düzenlemelerin alt yapısını oluşturması hedeflenmektedir.

TSSÖDYP çalışmalarına katkı veren ve dokümanların hazırlanmasında görev alan tüm paydaşlarımıza teşekkürlerimi sunuyorum.

Prof.Dr. İsmail DEMİR

T.C. Cumhurbaşkanlığı

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.

Bu nedenle, tedarik edilen sistemlerin kullanım döneminde hedeflenen muharebe ve/veya operasyon performansının sürdürülebilirliğinin ve maliyet etkinliğinin sağlanması amacıyla sistemlerin ömür devrinde rol ve sorumluluğu bulunan tüm paydaşların katılımı ile Sistem Ömür Devri Yönetimi yaklaşımı geliştirilmiştir.

Sistem Ömür Devri Yönetiminin temel amacı; mevcut durumdaki değişimlere uyum sağlamaktan ziyade gelecekte ortaya çıkabilecek değişimleri öngörmek, belirlenen hedefler doğrultusunda gerekli önlemleri alarak değişimleri yönlendirmek ve kontrol altında tutmaktır. Harekât ihtiyaçlarının zamanında ve verimli şekilde karşılanması ve sahip olunan kaynakların maliyet etkin kullanımı esastır. Başka bir deyişle, sistem ömür devri yönetimi geleceği bugünden tasarlamak ve planlamaktır.

Bu doküman; Savunma Sanayii Başkanlığı (SSB), Milli Savunma Bakanlığının ilgili birimleri, Türk Silahlı Kuvvetleri (TSK), diğer ihtiyaç makamları ve savunma sanayi firmalarında Sistem Ömür Devri Yönetimi’nin bir kültür olarak yaygınlaştırılmasına ve uygulanmasına yönelik rehber oluşturmak amacıyla savunma sistemlerinin ömür devrinde rol ve sorumluluğu bulunan ilgili paydaşların katılımıyla hazırlanmıştır.

Sonuç olarak; sistem ömür devrinin etkin şekilde yönetilmesiyle ülkemize muharebe ve/veya operasyon üstünlüğü kazandırılırken, sistemlerin ömür devri maliyetleri düşürülerek savunma giderleri azaltılacak, ülke ekonomisine önemli katkılar sağlanacak, savunma sanayii firmalarımızın uluslararası alandaki rekabet etme seviyesi artırılacak ve ömür devri yönetimi kapsamında savunma ve güvenlik alanındaki portföy/program/projelerde ömür devri yönetimi ve lojistik faaliyetlerin ortak bir anlayışla işbirliği içinde yürütülmesi hedeflenmektedir.

= 1. GENEL =

== 1.1. GİRİŞ ==
Çok hızlı bir değişimin yaşandığı günümüzde, orduların sadece bu değişime ayak uydurmaları yeterli olmayıp önleyici bir yaklaşımla çevresinde meydana gelebilecek değişimleri hızla öngörmesi, milli hedefleri doğrultusunda değişimi yönlendirebilmesi ve gerekli önlemleri zamanında alabilmesi daha başarılı olmalarının vazgeçilmez şartıdır.

Bu amaçla; değişen tehdit ve muharebe ve/veya operasyon şartlarına reaksiyon gösterilebilmesi, ihtiyaç duyulan yeteneklerin doğru stratejiler ışığında belirlenip doğru zamanda ve maliyet etkin olarak kazanılabilmesi ve sürdürülebilirliğinin sağlanabilmesi, savunma sistemlerinin performansının artırılabilmesi, kullanım ve destek faaliyetlerinde yaşanan sorunların giderilebilmesi ve ömür devri maliyetlerinin azaltılabilmesi için Sistem Ömür Devri Yönetimi yaklaşımı geliştirilmiştir.

Geleneksel lojistik destek anlayışının aksine Sistem Ömür Devri Yönetimi yaklaşımında;

* Sistemin tüm ömür devri safhaları birbirleri ile etkileşim içinde bütünleşik olarak yönetilir.
* Kullanım ve destek safhası gereksinimleri, sistem ömür devrinin ilk safhalarında yapılan bilimsel çalışmalarla belirlenir ve Odak Sistem ile birlikte tasarlanıp tedarik edilir.
* Envanterdeki sistemlerin, muhtemel tehdit ve beklenen görev ortamında yeterliliği devamlı olarak değerlendirilir ve yetersizliklerin giderilmesine yönelik önlemler zamanında alınır.

Sistem Ömür Devri Yönetimi yaklaşımının SSB, TSK, diğer ihtiyaç makamları ve savunma sanayii firmalarında bir kültür olarak yaygınlaşması ve etkin bir şekilde kullanılması ile savunma sistemlerinin muharebe ve/veya operasyon performanslarının artacağı, sistem ömür devri maliyetlerinin düşeceği öngörülmektedir.

Sistem ömür devri boyunca sistem etkinliğinin sağlanması için, tüm sistem ömür devrinin safhalar halinde tanımlanması, yürütülen faaliyetlerin ölçülmesi, geliştirilmesi ve iyileştirilmesi esastır. Bu amaçla, ihtiyacın ortaya çıkışından ürünün envanterden çıkarılmasına kadar tanımlanan tüm safha ve aşamalar içinde yer alan faaliyetlerin bütünleşik olarak yönetimi esas alınmalıdır.

== 1.2. AMAÇ ==
Bu dokümanın amacı:

* Tedarik edilecek/edilen sistemlerin, ömür devri süresince hedeflenen muharebe ve/veya operasyon performansını maliyet etkin şekilde karşılayabilmesini sağlayacak bir Sistem Ömür Devri Yönetimi yaklaşımı ortaya koymak,
* Sistem Ömür Devri Yönetim yaklaşımının uygulanmasını sağlayacak ilke, usul ve esasları belirlemek,
* Sistem Ömür Devri Yönetimi faaliyetlerinin bütünlük içinde planlanmasına, koordine edilmesine, yürütülmesine, denetlenmesine ve iyileştirilmesine imkân sağlayacak ana çerçeveyi oluşturmak,
* Sistem Ömür Devri Yönetimi yaklaşımını SSB, TSK, diğer ihtiyaç makamları ve savunma sanayii firmalarında bir kültür olarak yaygınlaştırmak,
* Tedarik edilecek/edilen sistemlerin ömür devri yönetimi faaliyetlerinin ilgili birimler arasında koordineli ve iş birliği içerisinde yürütmek ve uygulamalarda standartları sağlamak,
* Sistemlerin ömür devri süre ve maliyetlerini belirlemeye ve kontrol etmeye yönelik altyapının oluşturulması,
* Sistemlerin ömür devri safhalarını ve safhalar arasındaki geçiş kriterlerini ortaya koyarak, envanterden çıkarma zamanlarını bilimsel istatistiki modellerle tahmin edecek esasları belirlemek, bu kapsamda çıkacak ihtiyaçları zamanında tespit etmek, önceden bu ihtiyaçlara yönelik planlama yaparak yeni sistemlerin envantere girmesini sağlamak, kaynakların daha etkin olarak kullanılmasını mümkün kılacak modellerin geliştirilmesi ile sistemlerin göreve hazır olma seviyelerini üst düzey tutmaktır.

Bu doküman, savunma ve güvenlik sektöründe görev alan tüm paydaşların sistem ömür devri yönetimi faaliyetlerinde rehberlik etmek üzere hazırlanmıştır.

== 1.3. KAPSAM ==
Bu doküman, Sistem Ömür Devri Yönetimi çerçevesinde yer alan tüm safhalara ve bu safhalarda yürütülecek faaliyetlere ilişkin esasları kapsamaktadır. Hedeflenen performans değerlerinin sağlanması için; tanımlanan her bir safhanın amacının, bu safhalarda yer alacak aşamaların, kilometre taşlarının, yürütülecek faaliyetlerin ve her bir safha ve aşamaya ait girdi ve çıktıların belirlenmesi gereklidir.

== 1.4. REHBERİN KULLANIMI ==
Bu doküman sistem ömür devri yönetimi kavramının ana hatlarıyla tanımlanması amacıyla 5 bölümden oluşmaktadır:

* İlk bölüm; giriş, amaç, kapsam, referanslar gibi genel bilgileri içermektedir. Ayrıca terim ve kısaltmalar da bu bölümün içindedir.
* İkinci bölümde, Sistem Ömür Devri Yönetimi kapsamında yer alan temel kavramlar hakkında bilgi verilmiştir.
* Üçüncü bölümde; Sistem Ömür Devri Yönetimi yapısı, safha, aşama, kilometre taşları tanımları, faaliyetler ve aralarındaki ilişkiler aktarılmıştır.
* Dördüncü bölümde, bir önceki bölümde tanımlanan yapıya göre Sistem Ömür Devri Yönetimi safhaları ve bu safhalara yönelik bilgiler detaylandırılmıştır.
* Beşinci bölümde, dokümanda yer alan bilgilerin Odak Sistemin bulunacağı safhaya ve proje türüne göre nasıl uyarlanacağı açıklanmıştır.
* Dokümanın son bölümünde ise ilgili ekler yer almaktadır.

== 1.5. REHBERİN GÜNCELLENMESİ ==
Rehber; ilgili paydaşların ihtiyacı doğrultusunda güncellenecektir. Değişiklikler, aşağıdaki Değişiklik İzleme Tablosu’ndan izlenecektir.

'''Tablo 1 Değişiklik İzleme Tablosu'''
{| class="wikitable"
|'''YAYIN NO'''
|'''YAYIN TARİHİ'''
|'''DEĞİŞİKLİK YAPILAN BÖLÜM/SAYFA'''
|'''AÇIKLAMA'''
|-
|01
|Ağustos 2021
|
|İlk yayın
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|}

== 1.6. REFERANSLAR ==
1. NATO STANDARD, AAP-20 NATO PROGRAMME MANAGEMENT FRAMEWORK (NATO Life Cycle Model), Rev. C, October 2015.

2. NATO STANDARD, AAP-48 NATO SYSTEM LIFE CYCLE PROCESSES, Rev. B, March 2013.

3. INCOSE SYSTEMS ENGINEERING HANDBOOK, A GUIDE FOR SYSTEM LIFE CYCLE PROCESSES AND ACTIVITIES, 2015.

4. ISO/IEC 15288, SYSTEMS AND SOFTWARE ENGINEERING – SYSTEM LIFE CYCLE PROCESSES, 2015.

5. TSSÖDYP Doküman Seti

{| class="wikitable"
|+
! colspan="2" |'''TSSÖDYP DOKÜMAN SETİ'''
|-
|'''DOKÜMAN ADI '''
| '''DOKÜMAN KODU'''
|-
|Sistem Ömür Devri Yönetimi Rehberi (Ana Çerçeve)
|TSSÖDYP-01
|-
|Sistem Ömür Devri Yönetimi Süreçleri Rehberi
|TSSÖDYP-02
|-
|Ürün Destek Stratejileri ve Modelleri Rehberi
|TSSÖDYP-03
|-
|Entegre Lojistik Destek (ELD) Rehberi
|TSSÖDYP-04
|-
|Entegre Lojistik Destek (ELD) İsterleri Hazırlama Rehberi
| TSSÖDYP-05
|-
|Lojistik Destek Analizleri ve Kayıtları Rehberi
|TSSÖDYP-06
|-
|Tedarik Zinciri Yönetimi Rehberi
|TSSÖDYP-07
|-
|Sistem Ömür Devri Yönetiminde Demodelik Yönetimi Rehberi
|TSSÖDYP-08
|-
|Kullanım ve Destek İhtiyaçları Çerçevesinde Yerlileştirme/

Millîleştirme Rehberi
|TSSÖDYP-09
|-
|Kullanım ve Destek Safhaları Kalite Yönetimi Rehberi
|TSSÖDYP-10
|-
|Sistem Ömür Devri Yönetiminde Konfigürasyon Yönetimi Rehberi
|TSSÖDYP-11
|-
|Teknik Yayın Hazırlama Rehberi
|TSSÖDYP-12
|-
|Eğitim ve Eğitim İhtiyaçları Rehberi
|TSSÖDYP-13
|-
|Sistem Ömür Devri Yönetimi Terminolojisi
|TSSÖDYP-14
|-
|Kodlandırma ve Sınıflandırma Bilgi Kitapçığı
|TSSÖDYP-15
|-
|ASD/AIA S-Serisi ELD Spesifikasyonları Seti Tanıtım Kitapçığı
|TSSÖDYP-16
|}

== 1.7. TANIMLAR VE KISALTMALAR ==

=== 1.7.1. TANIMLAR ===
'''Tablo 2 Tanımlar Tablosu'''
{| class="wikitable"
|'''Terim'''
|'''Tanım'''
|'''Diğer Kullanım'''
|-
|Araştırma-Geliştirme Research-Development
|Belirli bir konuyu anlamak üzere bilgi üretilmesini, üretilen bilginin uygulanmasıyla teknoloji geliştirilmesini veya elde edilen teknolojiyi kullanarak sistem geliştirilmesini amaçlayan, seri üretim içermeyen faaliyetlerdir.
|
|-
|Arıza

Failure
|Bir konfigürasyon biriminin kendinden beklenen şekilde çalışmaması ve/veya beklenen çıktıları üretememesi durumudur.
|
|-
|Aşama

Phase
|Safhalar içerisinde bulunan ve ilgili safhanın tamamlanabilmesi için gerekli çıktıların üretildiği bölümlerdir.
|
|-
|Bakım Görev Analizi

Maintenance Task Analysis
|Düzeltici ve önleyici faaliyetler için prosedürler, yedek parça, destek ekipmanı, personel beceri seviyesi, tahmini süreler, tesis gereksinimleri vb. bilgilerin çıkarılması sağlayan detaylı bir analizdir.
|
|-
|Demodelik Yönetimi

Obsolescence Management
|Tasarım, geliştirme, üretim ve ürün desteği dönemlerinde ürün içeriğindeki parçaların üretim sürecinde ya da bulunabilirliğinde meydana gelebilecek değişimlerden kaynaklanan problemlerin farkında olmak ve bu problemlerin etkilerini azaltmak için çözüm yöntemleri belirlemek amacıyla yürütülen düzeltici ve önleyici faaliyetlerin yönetilmesi disiplinidir.
|
|-
|Destek Safhası

Support Stage
|Odak Sistem ve destek unsurlarının işlev devamlılığını ve kullanım sürdürülebilirliğini etkinleştiren destek hizmetlerinin planlanması ve sağlanması safhasıdır.
|
|-
|Desteklenebilirlik

Supportability
|Sistem tasarım özelliklerinin ve planlanan lojistik kaynakların sistemden beklenen kullanıma hazır bulunma gereklerini sistemin ömür devri boyunca uygun maliyette karşılayabilme derecesidir.
|
|-
|Destek Unsurları

Enablling Systems
|Odak Sistemin belirlenen kullanım konsepti ve görev profilleri çerçevesinde istenilen performans seviyesinde görev yapabilmesi ve maliyet etkin olarak kullanımında sürekliliğin sağlanması için ihtiyaç duyulan unsurlardır.
|
|-
|Doğrulama

Verification
|Ürün ya da hizmetin istenen özellikte olduğunu; gerekleri karşıladığını; kullanıma uygunluğunu göstermek amacıyla yapılan sistematik değerlendirmelerdir.
|
|-
|Entegre Lojistik Destek

Integrated Logistics Support
|Ürünlerin lojistik destek gereksinimlerinin tanımlanması, analizi ve planlanmasına yönelik; lojistik planlama ve analiz, bakım/onarım (B/O), eğitim, teknik yayın ve diğer ilgili konularda, tasarım aşamasından itibaren, bilimsel yöntemler kullanarak planlanıp yürütülen işlevlerin bütünleşik ele alındığı çalışmalardır.
|Bütünleşik Lojistik Destek
|-
|Envanterden Çıkarma Safhası

Retirement Stage
|Kullanımdan kaldırılmasına karar verilmiş olan Odak Sistem, alt sistem, sistem elemanları ve/veya destek unsurlarının envanterden çıkarılması safhasıdır.
|Elden Çıkarma
|-
|Fiziksel Konfigürasyon Denetimi

Physical Configuration Audit
|Bir konfigürasyon kaleminin üretilmiş (İng. As-built) veya idame edilen (As-Maintained) konfigürasyonunun, teknik dokümanlarına göre resmi olarak incelenmesidir.
|Fiziksel Konfigürasyon Tetkiki
|-
|Fonksiyonel
Konfigürasyon

Denetimi

Functional

Configuration Audit
|Bir konfigürasyon biriminin sistem spesifikasyonları bünyesinde tanımlanan performans ve fonksiyonel karakteristiklerini sağladığını ve geliştirilmesinin tamamlandığını geçerli kılma amacıyla yapılan
denetimlerdir.
|Fonksiyonel Konfigürasyon Tetkiki
|-
|Geliştirme Safhası

Development Stage
|Belirlenen sistem çözümüne ve gereksinimlere uygun olarak Odak Sistem ve destek unsurlarının tasarımı, entegrasyonu, doğrulanması ve kalifikasyonu faaliyetlerinin yürütülmesi safhasıdır.
|
|-
|Göreve Hazır Bulunma Readiness
|İhtiyaç duyulan sistemin ilgili görev profili kapsamında kullanıma hazır bulunmasıdır.
|
|-
|Güvenilirlik

Reliability
|Belirli bir zaman periyodunda, istenen çevresel ve coğrafi şartlar altında ve belirlenen kullanım profillerinde sistemin gereken fonksiyonunu hata yapmadan yapabilme/başarabilme olasılığıdır.
|
|-
|Hata

Fault
|Sistem fonksiyonlarında azalma, kesilme ya da kayba neden olan olaylardır.
|
|-
|Hata Modları, Etkileri ve Kritiklik Analizi

Failure Modes, Effects and Criticality Analysis
|Bir sistem bünyesinde meydana gelebilecek potansiyel hata modlarının, etkilerinin ve kritiklik seviyelerinin değerlendirildiği analizdir.
|
|-
|İhtiyaç Makamı
|Bir malın, teçhizatın, sistemin ve hizmetin tedarik edilmesi için ihtiyacı tespit eden, tedarik edilmesi için teklif yapan, tedarik edildikten sonra kullanıcılara dağıtımını yapan makamdır.
|Kullanıcı

Müşteri
|-
|İşlevsel Konfigürasyon Denetimi

Functional Configuration Audit
|İşlevsel ve/veya tahsis edilmiş ana çizgileriyle belirlenmiş gereksinimleri başarmış bir konfigürasyon kaleminin işlevsel özelliklerinin resmi olarak incelenmesidir.
|İşlevsel Konfigürasyon Tetkiki
|-
|Kalifikasyon

Qualification
|Gereksinimlerin tam olarak ya da belirli sınırlar dahilinde karşılandığının gösterilmesidir.
|
|-
|Karar Noktası

Decision Gate
|Safhalar arasındaki geçişlerde, önceki safhada yapılmış çalışmaların yeterliliğinin ve sonraki safhada yapılacak çalışmalar için gerekli girdilerin değerlendirildiği karar noktalarıdır.
|
|-
|Kavramsal Tasarım

Conceptual Design
|Teklife Çağrı Dokümanlarında yer alan gereksinimlere göre sistem çözümüne yönelik çalışmaların yapılmasıdır.
|
|-
|Kilometre Taşı

Milestone
|Safha içerisindeki ilerlemeyi ölçmek için kullanılan kontrol noktalarıdır.
|
|-
|Konfigürasyon Yönetimi

Configuration Management
|Tüm ömür devri boyunca ürünün başarım, işlevsel ve fiziksel özelliklerini gereksinimler, tasarım, üretim ve işletim bilgileriyle uyumlu kılan ve bu uyumu koruyan teknik ve yönetsel süreçtir.
|
|-
|Konsept Safhası

Concept Stage
|Sistem çözümüne ilişkin detaylı çalışmaların yürütülerek sistem gereksinimlerinin tanımlandığı ve bu ihtiyaçların karşılanma esaslarının planlandığı safhadır.
|
|-
|Kritik Tasarım Gözden Geçirme

Critical Design Review
|Bir konfigürasyon birimi veya işlevsel olarak ilişkili konfigürasyon birimlerinin üretim aşamasına geçmeden önce, ilgili teknik dokümanlardaki tasarım çözümünün sistem, alt sistem ve arayüz gereksinimlerini karşılayacağının teyit edilmesidir. Teknik değerlendirmenin yanı sıra program riskleri ve proje takvimi değerlendirilmesi de yapılır.
|
|-
|Kullanım Safhası

Utilisation Stage
|Odak Sistem ve destek unsurlarının kullanıma alınması ve fiilen kullanılması safhasıdır.
|
|-
|Kullanıma Hazır Olma

Availability
|İhtiyaç duyulan sistemin, zamanın herhangi bir anında kullanıma hazır olma derecesidir.
|
|-
|Lojistik Destek Analizi

Logistic Support Analysis
|Ürün Ömür Devri boyunca ürün için ihtiyaç duyulacak lojistik destek kaynak ve ihtiyaçlarının tanımlanması ve geliştirilmesi, lojistik destek unsurlarının tasarıma etkilerinin belirlenmesi, destek problemi çıkarabilecek ve maliyeti artıracak noktaların erken tespiti ve lojistik destek veri tabanı oluşturulmasına yönelik yapılan çalışmalardır.
|
|-
|Lojistik Destek Analizi Planı

Logistic Support Analysis Plan
|Proje süresince yürütülecek LDA faaliyetlerinin kimler tarafından, nasıl ve hangi esaslara dayanılarak yürütüleceğinin anlatıldığı ve proje kapsamında hangi analizlerin yapılacağına ve nasıl yapılacağına dair hazırlanan plandır.
|
|-
|Malzeme Listesi

Bill of Material
|Birimlerin (örneğin ürün, alt ürün, bileşen ve ham malzemeler) arasındaki ata-çocuk ilişkisini tanımlayan dokümandır.
|Ürün Ağacı
|-
|Modernizasyon
|Savunma ve güvenlik kurumlarının modern araç, gereç ve sistemlerle donatılmasına yönelik faaliyetler ile envanterde mevcut olan sistemlerin/platformların veya yazılımların teknolojik gelişmelere ve savunma, harekât ve operasyonel ihtiyaçlara bağlı olarak performansının artırılmasıdır.
|
|-
|Odak Sistem

System of Interest
|Herhangi bir portföy/program/proje çerçevesinde, yeni bir temel yetenek kazandıran ya da mevcut bir temel yeteneğin kapsamlı modernizasyonuna yönelik olan, tedariki ve kullanım ve desteği yüksek maliyetli ve/veya gerçekleştirilmesi nispeten uzun zaman alacak olan savunma ve güvenlik sistemleridir.
|Savunma sistemi/ platformu, ana silah sistemi, ana sistem, ana malzeme, ürün ve benzerleri
|-
|Onarım Seviyeleri Analizi

Level of Repair Analysis
|Bir onarım faaliyeti için en ekonomoik ve verimli bakım seviyelerinin belirlendiği analizdir.
|
|-
|Operasyonel Konsept Dokümanı
|Sistemin belirlenen ihtiyaçlar doğrultusunda kullanım şeklinin tanımlandığı, üst seviye hedeflerinin ve gereksinimlerinin yer aldığı dokümandır.
|Kullanım Konsept Dokümanı
|-
|Ön Konsept Safhası

Pre-Concept Stage
|Harekât ve lojistik ihtiyaçlara esas gereksinimlere, yeteneklere ve risk alanlarına yönelik ihtiyacın giderilmesi için seçeneklerin belirlenmesi ve sistem çözümüne karar verilmesi halinde uygun sistem çözümüne yönelik ihtiyaç tanımının ana hatları ile ortaya koyulması faaliyetlerinin yürütüldüğü safhadır.
|
|-
|Ön Tasarım

Preliminary Design
|Sistem için İşlevsel Mimari Model ve Fiziksel Mimari Model oluşturulmasıdır.
|
|-
|Ön Tasarım Gözden Geçirme

Preliminary Design Review
|Bir konfigürasyon biriminin veya işlevsel olarak ilişkili konfigürasyon birimlerinin resmi teknik gözden geçirmesidir. Bu gözden geçirme faaliyetinde; sistem yerleşimi, kullanıcı arayüzü, sistem emniyeti, taşınabilirlik gibi sistem ve kullanıcı arayüzü etkileşimi konularında onay alınarak, alt sistem tasarım ve yerleşiminin kullanıcı ihtiyaçlarını karşılar nitelikte olacağı garanti edilir. Sistemin fonksiyonel hedefleri ile fiziksel sistemlerin eşleştiği gösterilir.
|
|-
|Ön Yapılabilirlik Etüdü
|Proje Tanımlama Dokümanlarında belirtilen sistem yeteneklerine dayanarak sistem alternatiflerinin hazırlandığı, her bir alternatife ilişkin taktik ihtiyaçlar ile endüstriyel imkânların karşılaştırıldığı, alternatif sistemlerin harekât etkinlik ve uygunluk ile performans ve tahmini maliyetinin değerlendirildiği, bu değerlendirmeye göre en maliyet-etkin sistem alternatifinin ve teknik özelliklerinin belirlendiği ayrıntılı çalışmalardır.
|
|-
|Prototip

Prototype
|Teknoloji geliştirme faaliyetleri sonucunda ortaya çıkan yeni ürün ve sürecin tüm teknik özelliklerini ve performansını içeren bir modelin oluşturulması, sistem/alt sistem modelinin güvenilirliğinin daha yüksek laboratuvar ya da sanal ortamda ve sistemin gerçek ortamda performansının gösteriminin yapılmasıdır.
|
|-
|Proje/İhtiyaç Tanımlama Dokümanı
|Projelerin veya ihtiyaçların her biri için hazırlanan ve ihtiyacın ortaya konmasından tedarik aşamasına kadar gerekli teknik, taktik ve lojistik bilgileri kapsayan bir etüt dokümanıdır.
|
|-
|Safha

Stage
|Sistem ömür devri içerisinde tanımlanmış, işin daha küçük, anlaşılır ve zamanlanabilir bir şekilde yürütülmesini sağlayan yapılardır.
|
|-
|Sistem Çözümü

Material Solution
|İhtiyacı karşılamaya yönelik sistem seçenekleri için her bir sistem seçeneği ile ilgili kullanım konseptlerinin ve ihtiyaç belirleme aşamasındaki verilerin dikkate alınarak değerlendirilmesidir.
|
|-
|Sistem Mimarisi

System Architecture
|Sistemin yapısını, davranışını ve diğer yönlerini belirleyen kavramsal yapıdır.
|
|-
|Sistem Ömür Devri

System Life Cycle
|İhtiyacın belirlenmesi ile başlayan, ön konsept, konsept, geliştirme, üretim, kullanım, destek safhalarından geçen ve ürünün envanterden çıkarılması safhası ile son bulan zaman dilimidir.
|
|-
|Sürdürülebilirlik

Sustainability
|Tanımlı koşullar altında operasyonel hedefleri başarmak için belirli bir oranı ya da seviyeyi muhafaza edebilme becerisidir.
|
|-
|Tedarik Makamı
|Tedarik faaliyetlerini yürütmekle yetkili kurumlardır.
|
|-
|Tedarik Zinciri Yönetimi

Supply Chain Management
|Alt yükleniciler, yükleniciler, tedarik makamı, ihtiyaç makamı ve kullanıcı arasındaki malzeme, para ve bilgi etkileşimlerini kapsayan bağlantı zincirine ilişkin; ham madde ve bileşenlerin tedariki, imalat ve montajı, dağıtım ve teslimi ile olası geri dönüşüm ve yeniden kullanım faaliyetlerinin bütünleşik yönetimidir.
|
|-
|Teklife Çağrı Dokümanı

Request for Proposal
|Tedarik edilecek ürün ve hizmet alımları ile yapım işlerinin teknik şartnamesi, ihale konusu işin tanımı, hangi şartlarda yapılacağı, sözleşme görüşmelerine esas mali, idari, hukuki hususları, teklif verme şekli gibi konuları kapsayan dokümandır.
|
|-
|Teknik Veri Paketi

Technical Data Package
|Bir ürünün temin, üretim, muayene, mühendislik ve lojistik destek faaliyetlerinin desteklenmesi için yeterli teknik tanımıdır. Teknik Veri Paketi; modeller, teknik resimler, ilgili listeler, şartnameler, standartlar, performans gereksinimleri, kalite güvence gereksinimleri, yazılım dokümantasyonu ve paketleme detayları gibi uygulanabilir teknik verilerden oluşur.
|
|-
|Test Edilebilirlik

Testability
|Test kriterlerinin belirlenme ve test performansını kolaylaştırma derecesidir.
|
|-
|Uyarlama

Tailoring
|Bulunduğu safha gereksinimlerine göre odak sistemin ömür devrine ilişkin yürütülen faaliyetlerin birtakım süreç ve iş ürünlerinde değişiklikler yapılarak ele alınmasıdır.
|
|-
|Üretim Safhası

Production Stage
|Kalifikasyonu tamamlanan Odak Sistem ve destek unsurlarının üretilmesi safhasıdır.
|
|-
|Üretim Hattı Kalifikasyonu

Production Line Qualification
|Üretim hattının tanımlı spesifikasyonlara uygunluğunun kontrolüdür.
|
|-
|Yapılabilirlik Etüdü
|Bir görev yeteneğinin karşılanması amacıyla sistemlerin kullanımına, geliştirilmesine ve üretimine esas hususların ortaya konulması, planlamalara dahil edilen ve ihtiyaçları karşılayabileceği tespit edilen platform/sistem/ alt sistem için bu platform/sistem/alt sisteme ait teknolojilerin mevcut durumunun analizi, ayrıntılı teknoloji analizlerinin yapılması, ömür devri dahil maliyetlerinin tespit edilmesi, risk yönetimi, görev ve harekat ihtiyacını karşılayan sistemin vazgeçilmez ve arzu edilen taktik ve teknik özelliklerinin envantere giriş zamanı açısından incelenmesi, proje yönetim esas ve usulleri ile tedarik makamının ve tedarik modelinin belirlenmesi, proje ile ilgili maliyet-etkinlik ve fayda değer analiz çalışmalarıdır.
|
|}

=== 1.7.2. KISALTMALAR ===
'''Tablo 3 Kısaltmalar Tablosu'''
{| class="wikitable"
|'''Kısaltma'''
|'''Açıklama'''
|'''Diğer Kullanım'''
|-
|ADB

SRU
|Atölyede Değiştirilebilir Birim

Shop Replaceable Unit
|
|-
|Ar-Ge

R&D
|Araştırma-Geliştirme

Research-Development
|
|-
|BGA

MTA
|Bakım Görev Analizi

Maintenance Task Analysis
|
|-
|BoM
|Ürün Ağacı

Bill of Materials
|Malzeme Listesi
|-
|DELTMATO

DOTMLPFI
|Doktrin, Eğitim, Liderlik, Teşkilat, Malzeme, Altyapı, Tesisler, Ortak Çalışabilirlik

Doctrine, Organization, Training, Materiel, Leadership and Education, Personnel, Facilities and Interoperability
|
|-
|ELD

ILS
|Entegre Lojistik Destek

Integrated Logistics Support
|
|-
|HDB

LRU
|Hatta Değiştirilebilir Birim

Line Replaceable Unit
|
|-
|HTEKA

FMECA
|Hata Türleri Etkileri ve Kritiklik Analizi

Failure Modes, Effects and Criticality Analysis
|
|-
|KTGG

CDR
|Kritik Tasarım Gözden Geçirme

Critical Design Review
|
|-
|LDA

LSA
|Lojistik Destek Analizi

Logistic Support Anaylsis
|
|-
|LDAP

LSAP
|Lojistik Destek Analizi Planı

Logistic Support Anaylsis Plan
|
|-
|OSA

LORA
|Onarım Seviyesi Analizi

Level of Repair Analysis
|
|-
|ÖTGG

PDR
|Ön Tasarım Gözden Geçirme

Preliminary Design Review
|
|-
|PPP
|Paket Proje Planı
|
|-
|PUT
|Proje Uygulama Takvimi
|
|-
|TÇD

RFP
|Teklife Çağrı Dosyası

Request for Proposal
|
|-
|TDAP
|Test ve Değerlendirme Ana Planı
|
|-
|TVP

TDP
|Teknik Veri Paketi

Technical Data Package
|
|}

== 1.8. TABLOLAR VE ŞEKİLLER ==

=== 1.8.1. TABLOLAR ===
Tablo 1 Değişiklik İzleme Tablosu

Tablo 2 Tanımlar Tablosu

Tablo 3 Kısaltmalar Tablosu

Tablo 4 Uyarlama

Tablo 5 Farklı Kurumlarda/Standartlarda Sistem Ömür Devri Safhaları Terminolojisi

=== 1.8.2. ŞEKİLLER ===
Şekil 1 Sistem; Odak Sistem ve Destek Unsurları

Şekil 2 Sistem Ömür Devri Safhaları

Şekil 3 Sistem Ömür Devri Maliyet Dağılımı

Şekil 4 Sistem Ömür Devri Sürecinde Alınan Kararların Gerçekleşen Maliyet Üzerindeki Etkisi

Şekil 5 Örnek Program Safhaları ve İlişkili Elemanlar

Şekil 6 Ön Konsept Safhası

Şekil 7 Konsept Safhası

Şekil 8 Geliştirme Safhası

Şekil 9 Üretim Safhası

Şekil 10 Kullanım Safhası

Şekil 11 Destek Safhası

Şekil 12 Envanterden Çıkarma Safhası

Şekil 13 Risk ve Süreç Denge Grafiği – McConnel, INCOSE SE Handbook.

= 2. SİSTEM ÖMÜR DEVRİ YÖNETİMİ =

== 2.1. TEMEL KAVRAMLAR ==
'''Sistem Ömür Devri;''' ihtiyacın belirlenmesi ile başlayan ve sistemin envanterden çıkarılması ile son bulan zaman dilimidir.
[[Dosya:Sistem Odak Sistem.png|alt=Şekil 1 Sistem; Odak Sistem ve Destek Unsurları|sol|küçükresim|600x600pik|Şekil 1 Sistem; Odak Sistem ve Destek Unsurları]]

'''Sistem;''' ömür devrinin ilk safhasından itibaren Odak Sistem ve Destek Unsurlarının ayrılmaz bir bütün halinde ele alındığı ve yönetildiği bileşenler topluluğudur.

'''Odak Sistem;''' herhangi bir portföy/program/proje çerçevesinde, yeni bir temel yetenek kazandıran ya da mevcut bir temel yeteneğin kapsamlı modernizasyonuna yönelik olan, tedariki, kullanımı ve desteği yüksek maliyetli ve/veya gerçekleştirilmesi nispeten uzun zaman alacak olan savunma ve güvenlik sistemleridir.

Odak Sistemin temel görevi, savunma ve güvenlik ihtiyacını belirlenen kullanım konsepti ve görev profilleri çerçevesinde istenilen performans seviyesinde karşılamaktır. Odak Sistem, sistemler sistemi olarak tanımlanabilecek bir yapı olabileceği gibi sadece alt sistemlerden ve sistem elemanlarından oluşan bir yapı da olabilir. Bu çerçevede, Odak Sistem – yukarıdaki tanıma uygun olacak şekilde - savunma sistemi/platformu, ana silah sistemi, ana sistem, ana malzeme, ürün, cihaz ve benzerlerini ifade etmektedir.

'''Destek Unsurları;''' Odak Sistemin belirlenen kullanım konsepti ve görev profilleri çerçevesinde istenilen performans seviyesinde görev yapabilmesi ve maliyet etkin olarak kullanımında sürekliliğin sağlanması için ihtiyaç duyulan unsurlardır. Destek Unsurları, bunlarla sınırlı olmamak üzere Şekil 1’deki hususları kapsar.

== 2.2. SİSTEM ÖMÜR DEVRİ YÖNETİMİNE GİRİŞ ==
Sistem Ömür Devri Yönetimi; performans, maliyet, takvim, kalite, çalışma ortamı, ELD ve demodelik kriterlerine dikkat edilerek sistemin ömür devri boyunca savunma yeteneklerini optimize etmeyi amaçlamaktadır.

İhtiyaç duyulan savunma ve güvenlik yeteneklerinin kazanılması ve sürdürülebilirliğinin sağlanmasına yönelik olarak Sistem Ömür Devri Yönetimi kapsamında aşağıda belirtilen faaliyetlerin icra edilmesi hedeflenmektedir:

* Harekât, operasyon ve lojistik ihtiyaçlara yönelik gereksinimlerin, yeteneklerin ve risk alanlarının belirlenmesi,
* İhtiyacın giderilmesine yönelik sistem seçeneklerinin belirlenmesi ve uygun sistem çözümüne karar verilmesi,
* Odak Sistem ile birlikte destek unsurlarının da kullanım, destek ve envanterden çıkarma safhalarındaki gereksinimleri karşılayacak şekilde; ihtiyaç tanımlama aşamasından itibaren göz önünde bulundurulması,
* Belirlenen sistem çözümüne ve hedeflenen performansa uygun olarak tasarım, geliştirme ve üretim faaliyetlerinin yürütülmesi,
* Tedarik edilen ve kullanıma alınan sistemin kullanım ve destek safhalarından elde edilen veriler dikkate alınarak sistem üzerinde gerekli iyileştirmelerin yapılması,
* Kullanımdan kaldırılmasına karar verilmiş olan Odak Sistem, alt sistem, sistem elemanları ve/veya destek unsurlarının envanterden çıkarılmasıdır.

Sistem ömür devri; uzun bir dönemi kapsamakta, yürütülen işler açısından farklılıklar göstermekte ve birbiri ile etkileşim içinde olan faaliyetlerden oluşmaktadır. Sistem ömür devrinin safhalara ayrılması sureti ile sistemlerin daha etkin yönetilmesi mümkün olmaktadır.

Sistem Ömür Devri Yönetimi aşağıda belirtilen yedi safhadan oluşur:

* Ön Konsept,
* Konsept,
* Geliştirme,
* Üretim,
* Kullanım,
* Destek,
* Envanterden Çıkarma.

Şekil 2’de görüldüğü üzere her bir safha, sistem ömür devrinde yürütülen temel faaliyetleri temsil eder.
[[Dosya:Şekil2 Sistem Ömür Devri.jpg|alt=Şekil 2 Sistem Ömür Devri Safhaları|sol|küçükresim|650x650pik|Şekil 2 Sistem Ömür Devri Safhaları]]

Sistem ömür devri safhaları, her bir safhada birbirleri ile etkileşim içinde olan faaliyetler dikkate alınarak eş zamanlı yürütülür. İhtiyacı karşılayacak sistem çözümünün bulunacağı safhaya ve proje türüne göre sistem ömür devri safhalarında uyarlamalar söz konusu olabilir.

Bu safhalar boyunca önleyici, geliştirici, düzeltici ve iyileştirici tedbirlerin alınarak muharebe ve/veya operasyon etkinliğinin sağlanması ve ömür devri maliyetinin kontrol altında tutulması amaçlanır.

Ön konsept, konsept, geliştirme ve üretim safhalarında verilen kararlar, Odak Sistemlerin kullanım safhasındaki performansı üzerinde önemli bir etkiye sahiptir. Odak Sistemlerin istenilen performans seviyesinde görev yapabilmesi ön konsept, konsept ve geliştirme safhalarında destek unsurlarına ilişkin yapılacak detaylı analizlere, planlara ve alınacak tedbirlere bağlıdır. Bu sebeple, programların/projelerin başlangıcından itibaren ürün destek stratejileri ve ELD Planları üzerinde çalışılmaya başlanmalıdır.

== 2.3. SİSTEM ÖMÜR DEVRİ MALİYETİ ==
Sistem ömür devri maliyeti; bir harekât ihtiyacının karşılanması kapsamında sistem çözümü kararının verilmesinden, ürünün envanterden çıkarılmasına kadar yürütülen faaliyetler sonucu ortaya çıkan maliyetlerin toplamıdır.

Ömür devri maliyetinin ana faaliyetlere göre dağılımı Şekil 3’te gösterilmiştir.
[[Dosya:Şekil3 Sistem Ömür Devri Maliyet.jpg|alt=Şekil 3 Sistem Ömür Devri Maliyet Dağılımı|sol|küçükresim|650x650pik|Şekil 3 Sistem Ömür Devri Maliyet Dağılımı]]

Şekil 3, ömür devri maliyetlerinin safhalara göre dağılımını; Tedarik Dönemi, Kullanım ve Destek Dönemi ve Envanterden Çıkarma Dönemi kırılımında yansıtmaktadır. Tedarik Dönemi, bu doküman içerisinde kullanılan terminoloji (Şekil 1) doğrultusunda Ön Konsept, Konsept, Geliştirme ve Üretim safhalarına karşılık gelmektedir. Ömür devri maliyetinin temel unsurları; araştırma-geliştirme, test ve değerlendirme, yatırım, üretim, kullanım, destek ve envanterden çıkarma maliyetleridir. Ömür devri maliyet unsurlarının, sistem ömür devri safhalarına göre dağılımını yapacak olursak; kullanım ve destek dönemine ilişkin maliyetler - farklı sistemlerde değişiklik göstermekle birlikte - toplam ömür devri maliyetinin ortalama % 70’ini oluşturmaktadır.

Kullanım ve destek safhalarındaki maliyetlerin sadece bu safhalarda alınacak tedbirler ve bu tedbirlere bağlı yürütülecek faaliyetler ile istenilen oranda düşürülmesi mümkün değildir. Şekil 4’te görüldüğü üzere; yapılan bilimsel çalışmalar, ömür devri maliyetinin % 90-95 oranında tedarik döneminde alınan kararlar ile belirlendiğini göstermektedir.
[[Dosya:ŞEKİL4 Sistem Ömür Devri Sürecinde Alınan Kararların Gerçekleşen Maliyet Üzerindeki Etkisi.jpg|alt=Şekil 4 Sistem Ömür Devri Sürecinde Alınan Kararların Gerçekleşen Maliyet Üzerindeki Etkisi|sol|küçükresim|650x650pik|Şekil 4 Sistem Ömür Devri Sürecinde Alınan Kararların Gerçekleşen Maliyet Üzerindeki Etkisi]]

Ön konsept, konsept, geliştirme ve üretim safhalarında verilen kararlar, Odak Sistemlerin kullanım ve destek safhalarındaki maliyetlerini büyük ölçüde etkilemektedir. Sistem ömür devri maliyetlerinde önemli oranda tasarruf sağlanabilmesi bahse konu odak sistemlerin ön konsept, konsept ve geliştirme safhalarında yapılacak detaylı analizlere ve bu analizlerin sonucunda alınacak kararlara bağlıdır.

== 2.4. SİSTEM ÖMÜR DEVRİ SAFHALARINA GENEL BAKIŞ ==
Sistem Ömür Devri Yönetimi Rehber Dokümanı kapsamında, safha ve aşamalarda gerçekleştirilecek faaliyetler ve hazırlanacak dokümanlar tanımlanmaya çalışılmış, bu faaliyetler için herhangi bir sorumluluk belirtilmemiştir. Tüm safha ve aşamalarda ilgili mevzuat ve düzenlemeler gereğince ana sorumlularla birlikte ilgili paydaşların yer alabileceği değerlendirilmiştir.

'''Ön Konsept Safhası'''

Harekât ve lojistik ihtiyaçlara esas gereksinimlere, yeteneklere ve risk alanlarına yönelik ihtiyacın giderilmesi için seçeneklerin belirlenmesi ve sistem çözümüne karar verilmesi halinde uygun sistem çözümüne yönelik ihtiyaç tanımının ana hatları ile ortaya koyulması faaliyetlerinin yürütüldüğü safhadır.

'''Konsept Safhası'''

Sistem çözümüne ilişkin detaylı çalışmaların yürütülerek sistem gereksinimlerinin tanımlandığı ve bu ihtiyaçların karşılanma esaslarının planlandığı safhadır.

'''Geliştirme Safhası'''

Belirlenen sistem çözümüne ve gereksinimlere uygun olarak Odak Sistem ve destek unsurlarının tasarımı, entegrasyonu, doğrulanması ve kalifikasyonu faaliyetlerinin yürütülmesi safhasıdır.

'''Üretim Safhası'''

Kalifikasyonu tamamlanan Odak Sistem ve destek unsurlarının üretilmesi safhasıdır.

'''Kullanım Safhası'''

Odak Sistem ve destek unsurlarının kullanıma alınması ve fiilen kullanılması safhasıdır.

'''Destek Safhası'''

Odak Sistem ve destek unsurlarının işlev devamlılığını ve kullanım sürdürülebilirliğini etkinleştiren destek hizmetlerinin planlanması ve sağlanması safhasıdır. Odak Sisteme ve destek unsurlarına ilişkin desteğin planlanması; Ön Konsept, Konsept, Geliştirme, Üretim ve Kullanım safhalarındaki çalışmalarla birlikte yürütülür.

'''Envanterden Çıkarma Safhası'''

Kullanımdan kaldırılmasına karar verilmiş olan Odak Sistem, alt sistem, sistem elemanları ve/veya destek unsurlarının envanterden çıkarılması safhasıdır.

= 3. SİSTEM ÖMÜR DEVRİ YÖNETİM YAKLAŞIMI =

== 3.1. GENEL ==
Aşağıdaki şekilde bir savunma ve güvenlik programının sistem ömür devri yönetimi safhaları şematik olarak gösterilmiştir. Bu şematik gösterimden yola çıkılarak programın sistem ömür devri yönetimindeki safhaları, aşamaları, karar noktaları, giriş ve çıkış kriterleri ile kilometre taşları açıklanacaktır. Bu safhaların her birinde yapılacak çalışmalarda, bilimsel teknik ve yöntemlerden faydalanılır. Örneğin; karar noktalarında karar ağaçları kullanılması verilecek kararlarda kolaylık sağlayacaktır.
[[Dosya:Şekil5.png|alt=Şekil 5 Örnek Program Safhaları ve İlişkili Elemanlar|sol|küçükresim|650x650pik|Şekil 5 Örnek Program Safhaları ve İlişkili Elemanlar]]

=== 3.1.1. SAFHALAR ===
Bir tedarik programı/projesi; Ön Konsept, Konsept, Geliştirme, Üretim, Kullanım, Destek ve Envanterden Çıkarma olmak üzere yedi safhadan oluşmaktadır.

5’te de görüldüğü üzere programın her safhasında girdiler, çıktılar ve safhaların sonundaki karar noktalarında incelenecek olan giriş ve çıkış kriterleri bulunmaktadır. Safhaların en başında safha boyunca yapılacak çalışmaları yönlendirmek, çalışmalar sırasında ihtiyaç duyulacak bilgileri sağlamak amacıyla girdiler bulunmaktadır.

Safhaların sonlarında ise safha boyunca girdiler ve yapılan çalışmalar ile üretilmiş bilgiler çıktı olarak belirtilmiştir.

Safha 1 ve Safha 2 ardışık olarak yürütülebildiği gibi birbiri ile eş zamanlı olarak da yürütülebilir. Eş zamanlı olarak yürütülecek olan safhalara geçiş için geçilecek safhaya ilişkin girdilerin tamamlanması gereklidir. Safhaların tamamlanması için ise ilgili safhaya ilişkin çıkış kriterlerinin tamamlanması yeterlidir.

Program safhalarının başlangıç ve bitişi programın tümü ile birlikte değerlendirilmelidir.

=== 3.1.2. GİRDİLER VE ÇIKTILAR ===
Şekil 5’te de görüldüğü üzere bir programın ilgili safhasının başlaması için her safhaya özel olarak tanımlanmış girdilerin tamamlanmış olması gerekmektedir.

Girdiler, ihtiyaç veya tedarik makamından alınan bilgiler olabildiği gibi, ilgili safhada yapılacak analiz çalışmalarına girdi oluşturabilecek diğer çalışmaların sonucunda üretilen rapor/doküman vb. de olabilmektedir.

Bununla birlikte bir programın ilgili safhasında yapılan çalışmaların sonucunda ortaya çıkan bilgi paketleri dokümanlar ve/veya raporlar ilgili safhanın çıktısıdır. Safhanın tamamlanabilmesi için çıkış kriterlerinden bir tanesi de ilgili safhanın çıktılarının tamamlanmış olmasıdır. Özellikle bir sonraki safhada girdi olarak kullanılacak çıktılar her safhanın sonunda mutlaka çıktı olarak ortaya konulmalıdır.

=== 3.1.3. FAALİYETLER ===
Safhaların içerisinde girdilerin çıktılara dönüştürülmesi için yapılan tüm çalışmalardır. Faaliyetler, safhaların detaylı olarak anlatıldığı bölümde aşamalar kırılımında ele alınacaktır.

=== 3.1.4. AŞAMALAR ===
Safhalar içerisinde bulunan ve ilgili safhanın tamamlanabilmesi için gerekli çıktıların üretildiği yerlerdir. Aynı safha içinde yer alan aşamalarda yapılan çalışmalar ardışık bir sıra takip eder.

=== 3.1.5. KARAR NOKTALARI ===
Karar noktaları; safhalar arasındaki geçişlerde, önceki safhada yapılmış çalışmaların yeterliliğinin ve sonraki safhada yapılacak çalışmalar için gerekli girdilerin değerlendirildiği, aynı zamanda öğrenilmiş derslerin kaydedildiği noktalardır.

Karar noktalarında alınan kararlar gereği bir sonraki safhaya geçiş ve bir önceki safhadan çıkış onaylanmış olur. Karar noktaları; imzalı toplantı tutanakları, rapor ve/veya program yönetiminin kabul ettiği herhangi bir şekilde geçilebilir.

Karar noktalarında alınan bazı kararlar aşağıda listelenmiştir.

* Bir sonraki safhaya geçiş ve o safhadaki çalışmaların yürütülmesi kararı
* Mevcut safhaya devam etme kararı
* Daha önceki safhaya dönme veya daha sonraki bir safhaya atlama kararı
* Programın askıya alınması kararı
* Programın sonlandırılması kararı

=== 3.1.6. GİRİŞ ve ÇIKIŞ KRİTERLERİ ===
Giriş ve çıkış kriterleri; karar noktalarında alınacak kararları desteklemek amacıyla kullanılan ölçütlerdir.

Karar noktalarında giriş ve çıkış kriterlerinin birden farklı şekilde ele alındığı durumlar vardır.

1. Safha 1’den Safha 2’ye geçişte, Safha 1’in çıkış kriterleri ve Safha 2’nin giriş kriterleri karar noktasında alınacak kararlar açısından belirleyici olur.

2. Herhangi bir safhanın yalnızca giriş kriteri ilgili safhaya geçiş için karar noktasında alınacak kararlarda belirleyici olur. Bu durum genellikle eşgüdüm içerisinde yürütülecek safhalarda karşılaşılan bir durumdur.

3. Herhangi bir safhanın yalnızca çıkış kriteri ilgili safhadan çıkış için karar noktasında alınacak kararlarda belirleyici olur. Bu durum genellikle ömür devri yönetiminin sonuna gelindiğinde ya da ilgili safhanın sonunda başka bir safhaya geçilmeyecek ise karşılaşılan bir durumdur.

=== 3.1.7. KİLOMETRE TAŞLARI ===
Karar noktalarından farklı olarak kilometre taşları, safhaların içerisindeki aşamalar arasında veya herhangi bir noktada süreci gözlemlemek amacıyla bulunurlar. İlgili safhalarda, kilometre taşları “M [Safha No]. [Sıra No]” şeklinde numaralandırılmıştır.

= 4. SİSTEM ÖMÜR DEVRİ SAFHALARI =

== 4.1. ÖN KONSEPT SAFHASI ==

=== 4.1.1. AMAÇ ===
Ön Konsept Safhasının amacı;

* Yetenek kazanımına veya bir tehdidin ortadan kaldırılmasına yönelik harekât ve lojistik ihtiyaçların belirlenmesi ve tanımlanması,
* Sistem çözümüne gidilmeden ihtiyaçların mevcut imkân ve kabiliyetlerle veya bunların geliştirilmesi suretiyle karşılanma imkânının araştırılması,
* Sistem çözümüne ihtiyaç olup olmadığı kararının verilmesi,
* Sistem çözümüne karar verilmesi halinde,
** Harekât ihtiyacını karşılayacak seçeneklerin belirlenmesi ve değerlendirilmesi,
** Uygun sistem çözümüne yönelik ihtiyaç tanımının ana hatları ile ortaya konulduğu Proje/İhtiyaç Tanımlama Dokümanı ve eklerinin hazırlanmasıdır.

=== 4.1.2. TANIM ===
Ön Konsept Safhası; harekât ve lojistik destek ihtiyaçlarının mevcut imkân ve kabiliyetlerle karşılanıp karşılanamayacağı hususunun belirlenmesi, karşılanamaması halinde maliyet, performans, süre ve risk gibi hususlar göz önünde bulundurularak olası sistem seçeneklerinin oluşturulması, değerlendirilmesi ve uygun sistem çözümüne yönelik ihtiyaç tanımının ana hatları ile ortaya konulması faaliyetlerini kapsayan safhadır. Bu safhada yürütülen faaliyetler ve alınan kararlar başlatılacak program/proje üzerinde önemli bir etkiye sahiptir.

=== 4.1.3. AŞAMALAR ===
Ön Konsept Safhası, iki aşamadan ve iki kilometre taşından oluşur. Her aşamanın girdileri, çıktıları, başarım kriterleri ve aşamalar süresince tüm paydaşlarca değerlendirilerek üretilen iş ürünleri vardır. Aşamalar boyunca yapılan gözden geçirmelerde, ilgili aşama sonunda üretilmesi gereken iş ürünleri ve risk tanımlamaları incelenerek riski yönetmek için alınması gereken eylemler karara bağlanır.

* İhtiyaç Belirleme Aşaması
** İlgili Kilometre Taşları: M1.1 - Sistem çözümüne ihtiyaç olup olmadığı kararı

* İhtiyaç Tanımlama Aşaması
** İlgili Kilometre Taşları: M1.2 - Proje başlatılmak üzere dokümanların tedarik makamına gönderilmesi kararı

=== 4.1.4. FAALİYETLER ===
'''Savunma ve Güvenlik İhtiyaçlarının Belirlenme Aşaması'''

Bu aşamanın amacı; harekât ve lojistik destek ihtiyaçlarının,

* Harekât verileri
* Tatbikat verileri,
* Tehditlerdeki değişimler,
* Yasal yükümlülükler,
* Teknolojik yenilikler,
* Alternatifler (DELTMATO - Doktrin, Eğitim, Liderlik, Teşkilat, Malzeme, Altyapı, Tesisler, Ortak çalışabilirlik),
* Mevcut imkân ve kabiliyetler ile uzun vadede sahip olunmasına ihtiyaç duyulan imkân ve kabiliyetler,
* Muharebe ve/veya operasyon alanının coğrafi, atmosferik ve çevresel şartları,
* Kaynak durumu,
* İşletme ve lojistik destek sürecinde yaşanan zafiyetler ve elde edilen veriler,
* Ülkemizdeki sosyoekonomik gelişmeler

değerlendirilerek karşılanıp karşılanamayacağının belirlenmesi aşamasıdır.

* Hazırlanan Dokümanlar: Mevcut imkân ve kabiliyetlerle karşılanamayan ürünler için proje kararı
* Gözden Geçirmeler: İhtiyacın mevcut imkân ve kabiliyetlerle karşılanıp karşılanamadığı, Sistem çözümüne ihtiyaç olup olmadığı

'''İhtiyaç Tanımlama Aşaması'''

Bu aşamanın amacı; ihtiyacı karşılamaya yönelik sistem seçenekleri için her bir sistem seçeneği ile ilgili kullanım konseptlerinin ve ihtiyaç belirleme aşamasındaki verilerin dikkate alınarak değerlendirilmesidir. Bu aşamada ön yapılabilirlik çalışması yürütülerek en iyi sistem çözümüne yönelik ihtiyaç tanımı ana hatları ile ortaya konulur ve yürütülen faaliyetler ile genel amaç ve hedefleri belirleyen bir yol haritası çizilir.

* Hazırlanan Dokümanlar: Proje/İhtiyaç Tanımlama Dokümanı,
* Gözden Geçirmeler: Hazırlanan dokümanların uygunluğu

=== 4.1.5. KİLOMETRE TAŞLARI ===
Ön Konsept safhasındaki kilometre taşları:

* M1.1: Sistem çözümüne ihtiyaç olup olmadığı kararı
* M1.2: Proje başlatmak üzere dokümanların tedarik makamına gönderilmesi kararı

=== 4.1.6. GİRİŞ KRİTERLERİ ===

* Yetenek kazanımı,
* Harekât ve/veya lojistik ihtiyacın bulunması

=== 4.1.7. ÇIKIŞ KRİTERLERİ ===

* Proje/İhtiyaç Tanımlama Dokümanının oluşturulmuş olması

=== 4.1.8. GİRDİLER ===

* Harekât Verileri
* Tatbikat Verileri
* Tehditlerdeki Değişimler
* Yasal Yükümlülükler
* Teknolojik Yenilikler
* Alternatifler (DELTMATO – Doktrin, Eğitim, Liderlik, Teşkilat, Malzeme, Altyapı, Tesisler ve Ortak Çalışabilirlik)
* Mevcut İmkân ve Kabiliyetler

=== 4.1.9. ÇIKTILAR ===

* Proje/İhtiyaç Tanımlama Dokümanı
* Operasyonel Konsept Dokümanı
[[Dosya:TSSODYP01.06.jpg|alt=Şekil 6 Ön Konsept Safhası|sol|küçükresim|724x724pik|Şekil 6 Ön Konsept Safhası]]

== 4.2. KONSEPT SAFHASI ==

=== 4.2.1. AMAÇ ===
Konsept safhasının amacı;

* Harekât ve lojistik destek ihtiyacının karşılanmasına yönelik olarak, ana hatları ortaya konulan ihtiyaç tanımına ilişkin sistem çözümünün yapılabilirliğinin değerlendirilmesi,
* Sistem tedarikine yönelik planlamaların yapılarak Teklife Çağrı Dokümanının (TÇD) hazırlanması ve yayımlanması,
* Tedarik sözleşmesinin imzalanmasıdır.

=== 4.2.2. TANIM ===
Sistem çözümüne ilişkin detaylı çalışmalar kapsamında Yapılabilirlik Etüdü’nün hazırlandığı, sistem gereksinimlerinin tanımlandığı ve bu gereksinimlerin karşılanma esaslarının planlandığı safhadır. Bu safhada alınan kararlar; maliyet, performans (göreve hazır olma, görevi yerine getirme) ve desteklenebilirlik açısından sistem ömür devri üzerinde büyük bir etkiye sahiptir.

=== 4.2.3. AŞAMALAR ===

* İnceleme ve TÇD Hazırlama Aşaması
** İlgili Kilometre Taşları: M2.1 - TÇD ve eklerinin yayınlanması kararı

* Teklif Değerlendirme ve Sözleşme Görüşmeleri Aşaması
** İlgili Kilometre Taşları: M2.2 - Sözleşme imzalanması

=== 4.2.4. FAALİYETLER ===
'''İnceleme ve TÇD Hazırlama Aşaması'''

İnceleme aşamasında, sistem çözümüne ilişkin ihtiyaçlar detaylandırılarak gereksinimlere dönüştürülür. Sistem gereksinimlerinin eksiksiz tespit edilebilmesi ve uzun vadeli ürün destek stratejilerinin oluşturulabilmesi için tüm paydaşların (ihtiyaç ve tedarik makamı, sanayici, üniversiteler vb.) katılımı sağlanmalıdır. İnceleme aşamasında yapılan çalışmalara bağlı olarak Proje/İhtiyaç Tanımlama Dokümanı, Konsept safhasında güncellenebilir.

* Hazırlanan Dokümanlar: Yapılabilirlik Raporu, kullanım ve görev profilleri, TÇD ve Ekleri
* Gözden Geçirmeler: Sistem gereksinimlerinin gözden geçirilmesi, Ürün destek stratejilerinin ve modellerinin değerlendirilmesi (Lojistik Destek, Sanayii Katılımı, Kamu Özel Sektör İş birlikleri vb.)

'''Teklif Değerlendirme ve Sözleşme Görüşmeleri Aşaması'''

Bu aşamada gereksinimlerin ne oranda sağlanabildiğine dair genel bir değerlendirme yapmak amacıyla; yapılabilirlik çalışmalarından faydalanılarak maliyet, performans, süre ve risk analizleri gerçekleştirilir. Önerilen sistem çözümü için kurulacak program çerçevesinde ürüne ve programa özgü destek stratejileri geliştirilir ve başlangıç ELD Planlarına aktarılır.

* Hazırlanan Dokümanlar: Operasyonel Konsept Dokümanı, Sözleşme ve Ekleri (Teknik İsterler, İş Tanımı ve diğerleri), Ürün Destek Stratejisi ve Modeli (Yerlileştirme/Millîleştirme dahil), Ömür Devri Maliyet Tahmini, Kullanım Konsepti ve Görev Profilleri, Risk Değerlendirme Planı, Proje Uygulama Takvimi, Proje Yönetim Planı, ELD Planı, Kalite Yönetim Planı, Konfigürasyon Yönetim Planı, Demodelik Yönetim Planı

* Gözden Geçirmeler: Teklif Gözden Geçirmeleri

=== 4.2.5. KİLOMETRE TAŞLARI ===
Konsept safhası kilometre taşları:

* M2.1: TÇD ve Eklerinin Yayınlanması Kararı
* M2.2: Sözleşme İmzalanması

=== 4.2.6. GİRİŞ KRİTERLERİ ===

* Uygun sistem çözümüne yönelik ihtiyaç tanımının ana hatları ile ortaya konulmuş olması

=== 4.2.7. ÇIKIŞ KRİTERLERİ ===

* Sözleşmenin imzalanması

=== 4.2.8. GİRDİLER ===

* Proje/İhtiyaç Tanımlama Dokümanı,
* Operasyonel Konsept Dokümanı.

=== 4.2.9. ÇIKTILAR ===

* Sözleşme ve Ekleri
* Operasyonel Konsept Dokümanı
* Ürün Destek Stratejisi ve Modeli (Yerlileştirme/Millîleştirme dahil)
* Ömür Devri Maliyet Tahmini
* Risk Değerlendirme Planı
* Proje Yönetim Planı
* ELD Planı
* Kalite Yönetim Planı
* Konfigürasyon Yönetim Planı
* Demodelik Yönetim Planı

[[Dosya:ŞEKİL7Konsept Safhası.jpg|alt=Şekil 7 Konsept Safhası|sol|küçükresim|733x733pik|Şekil 7 Konsept Safhası]]

== 4.3. GELİŞTİRME SAFHASI ==

=== 4.3.1. AMAÇ ===
Geliştirme safhasının amacı, gereksinimleri karşılayacak bir Odak Sistemi tasarlamak ve üretime hazır hale getirmektir. Bu süreç sonunda tasarlanan Odak Sistemin üretilebilir, test edilebilir, değerlendirilebilir, işletilebilir, desteklenebilir ve kullanımdan kaldırılabilir nitelikte olması gerekmektedir. Odak sistem çalışmalarına paralel olarak ELD elemanlarına ilişkin detay çalışmalara bu safhada başlanır.

=== 4.3.2. TANIM ===
Geliştirme Safhası, Konsept Safhasının temel çıktısı olan program/proje sözleşmesinin imzalanması ile başlar. Bu safhada sözleşme (ekleri dahil) ve Operasyonel Konsept Dokümanı esas alınarak faaliyetler yürütülür. Yükleniciler, teklif çalışmaları kapsamında hazırlamış oldukları dokümanları sözleşme ve Operasyonel Konsept Dokümanı ile uyumlu olmak veya uyumlu hale getirmek şartıyla bu safhada kullanabilirler. Bağlayıcı olan sözleşmedir. Geliştirme safhası Odak Sisteme ilişkin dokümantasyonun ve kayıtların oluşturulması ile tamamlanır. Bu safha süresince Odak Sistemin konfigürasyonu kademeli olarak gelişir ve üretim safhası için hazır hale gelir.

Geliştirme Safhası toplam 6 aşamadan ve bu aşamalar içinde gerçekleştirilen toplam 10 adet kilometre taşından oluşur. Her aşamanın kendi girdileri, çıktıları, başarım kriterleri ve aşamalar süresince üretilen iş ürünleri mevcuttur. Aşamalar boyunca yapılan gözden geçirmelerde, ilgili aşama sonunda üretilmesi gereken iş ürünleri ve risk tanımlamaları gözden geçirilerek riski yönetmek için yürütülmesi gereken faaliyetler karara bağlanır.

=== 4.3.3. AŞAMALAR ===

* Kavramsal Tasarım Aşaması
** İlgili Kilometre Taşları: -

* Sistem Gereksinim Tanımlama Aşaması
** İlgili Kilometre Taşları: M3.1

* Ön Tasarım Aşaması
** İlgili Kilometre Taşları: M3.2, M3.3

* Detay Tasarım Aşaması
** İlgili Kilometre Taşları: M3.4

* Entegrasyon ve Doğrulama Aşaması
** İlgili Kilometre Taşları: M3.5, M3.6, M3.7

* Ürün Kalifikasyon Aşaması
** İlgili Kilometre Taşları: M3.8, M3.9, M3.10

=== 4.3.4. FAALİYETLER ===
'''Kavramsal Tasarım Aşamasında;''' Sözleşmede yer alan gereksinimlere göre sistem çözümüne yönelik çalışmalar yapılır. Başlangıç tasarım çözümü çizimler, modeller, prototipler vb. yollar ile belirlenir. Kavramsal tasarım çalışmaları yüklenici adayı tarafından sözleşmeden önce gerçekleştirilmiş ise sonuçlar teklif dokümanları ile sunulabilir. Ancak, sözleşme imzasından sonra kavramsal tasarımın sözleşme hükümlerine uygun hale getirilmesi gerekir. Kavramsal tasarıma ilişkin sonuçlar Kavramsal Tasarım Raporu ile sunulur.

* Hazırlanan Dokümanlar: Kavramsal Tasarım Raporu (Teklif Dokümanları ile sunulmuş olması durumunda sözleşme hükümlerine uygun hale getirilmesi zorunludur)
* Gözden Geçirmeler: -

'''Sistem Gereksinim Tanımlama Aşamasında;''' paydaş isteklerinin ayrıştırılması, türetilmesi ve sınıflandırılması ile önceliklendirilmesi yapılır. Tanımlanan gereksinimler için doğrulama yöntemleri belirlenir.

* Hazırlanan Dokümanlar: Sistem Gereksinim Tanımlama Dokümanı
* Gözden Geçirmeler: Sistem Gereksinimleri Gözden Geçirme Toplantısı

'''Ön Tasarım Aşamasında;''' Sistemin İşlevsel Mimari Model ve Fiziksel Mimari Model’i oluşturulur. Alt sistem gereksinim analizi ve alt sistem gereksinim tanımlama faaliyetleri gerçekleştirilir.

* Hazırlanan Dokümanlar: Sistem Tasarım Tanımlama (STT) Dokümanı, Sistem Arayüz Kontrol Dokümanı, Test ve Değerlendirme Ana Planı (TDAP), Alt Sistemler için Gereksinim Tanımlama Dokümanları, Güncellenmiş ELD Planı ve Alt Planları (Teknik Dokümantasyon Planı, Planı, Eğitim Planı, LDAP, Envanterden Çıkarma Planı vb.)
* Gözden Geçirmeler: Ön Tasarım Gözden Geçirme Toplantısı

'''Detay Tasarım Aşamasında;''' alt sistem ve sistem detaylı analiz (performans, yapısal, dinamik, termal, güvenilirlik vb.) ve tasarım faaliyetleri (yapısal, fonksiyonel, yazılım, ara yüz) gerçekleştirilir. Üretim ve test faaliyetleri için gereken hazırlık yapılır. Ön Tasarım Aşamasında hazırlanan Test ve Değerlendirme Ana Planı içerisinde, bu aşamanın çıktısı olarak verilen Sistem ve Alt Sistem Doğrulama Planları yer alabilir.

* Hazırlanan Dokümanlar: TVP (katı modeller, teknik resimler, şartnameler, Ürün Ağacı, yazılım, dokümantasyon vb.), Sistem ve Alt Sistem Doğrulama Planları, LDA Çıktıları, Güvenilirlik ve Emniyet Çıktıları, Güncellenmiş Sistem Ömür Devri Yönetim Stratejisi ve Modeli
* Gözden Geçirmeler: Kritik Tasarım Gözden Geçirme (Kritik tasarım gözden geçirme faaliyetlerine ELD birimlerinin katılımı sağlanmalıdır.)

'''Entegrasyon ve Doğrulama Aşamasında;''' tanımlı doğrulama yöntemleri ile entegrasyonu yapılan prototiplerin (sistem ve alt sistem) test ve değerlendirme faaliyetleri sistem ve alt sistem gereksinim tanımlama dokümanları ve tasarım doğrulama planlarına göre gerçekleştirilir.

* Hazırlanan Dokümanlar: Doğrulama Test Prosedürleri, Doğrulama Sonuç Raporları
* Gözden Geçirmeler: Test Hazırlıkları Gözden Geçirme Toplantısı, Tasarım Doğrulama Gözden Geçirme Toplantısı
* Denetimler: İşlevsel Konfigürasyon Denetimi

'''Ürün Kalifikasyon Aşamasında;''' tanımlı doğrulama yöntemleri ile entegrasyonu yapılan prototiplerin (sistem ve alt sistem) test ve değerlendirme faaliyetleri müşteri istekleri ve sistem gereksinim tanımlama dokümanlarına uygun olarak hazırlanan test prosedürlerine göre gerçekleştirilir. Seri üretim aşaması için hazırlıklar tamamlanır. Bu süreç sonunda gerçeklenen Odak Sistemin üretilebilir, test edilebilir, değerlendirilebilir, işletilebilir, desteklenebilir ve kullanımdan kaldırılabilir nitelikte olması güvence altına alınır.

* Hazırlanan Dokümanlar: Kalifikasyon Test Prosedürleri, Kalifikasyon Sonuç Raporları
* Gözden Geçirmeler: Kalifikasyon Gözden Geçirme Toplantısı, Üretim Hazırlıkları Gözden Geçirme Toplantısı
* Denetimler: Fiziksel Konfigürasyon Denetimi

=== 4.3.5. KİLOMETRE TAŞLARI ===
Geliştirme Aşamasındaki kilometre taşları yapılacak gözden geçirme toplantıları ve konfigürasyon denetimlerinden oluşmaktadır:

* M3.1: Sistem Gereksinimleri Gözden Geçirme Toplantısı
* M3.2: Sistem Fonksiyonel Gözden Geçirme Toplantısı
* M3.3: Ön Tasarım Gözden Geçirme Toplantısı
* M3.4: Kritik Tasarım Gözden Geçirme Toplantısı
* M3.5: Test Hazırlıkları Gözden Geçirme Toplantısı
* M3.6: Tasarım Doğrulama Gözden Geçirme Toplantısı
* M3.7: İşlevsel Konfigürasyon Denetimi
* M3.8: Kalifikasyon Gözden Geçirme Toplantısı
* M3.9: Fiziksel Konfigürasyon Denetimi
* M3.10: Üretim Hazırlıkları Gözden Geçirme Toplantısı

=== 4.3.6. GİRİŞ KRİTERLERİ ===
Konsept safhasının çıktılarının oluşturulmuş olması

=== 4.3.7. ÇIKIŞ KRİTERLERİ ===
Odak Sistem ile ilgili dokümantasyonun ve Teknik Veri Paketinin oluşturulmuş olması

=== 4.3.8. GİRDİLER ===

* Sözleşme ve Ekleri
* Operasyonel Konsept Dokümanı
* Ürün Destek Stratejisi ve Modeli (Yerlileştirme/Millîleştirme dahil)
* Kavramsal Tasarım Raporu / Teklifi (Sözleşme’nin bağlayıcı nitelikte olması sebebiyle sözleşme imzasından önce sunulmuş veya üzerinde çalışılmış bütün hususların sözleşme hükümlerine uygun hale getirilmesi zorunludur. Aksi takdirde sözleşme imzasından önce hazırlanmış/sunulmuş dokümanların geçerliliği bulunmayacaktır.)
* Proje Yönetim Planı
* ELD Planı
* Ömür Devri Maliyet Tahmini
* Kalite Yönetim Planı
* Konfigürasyon Yönetim Planı
* Risk Değerlendirme Planı
* Demodelik Yönetimi Planı

=== 4.3.9. ÇIKTILAR ===

* Sözleşme ve Ekleri
* TVP
* Prototip / Odak Sistem
* Yedek / Destek Donanımları
* Üretim Planı
* Teknik Yayın (Bakım ve diğerleri)
* Eğitim / Eğitim Dokümanları
* Güncellenmiş Proje Yönetim Planı
* Güncellenmiş ELD Planı
* Güncellenmiş Kalite Yönetim Planı
* Güncellenmiş Konfigürasyon Yönetim Planı
* Güncellenmiş Risk Değerlendirme Planı
* Güncellenmiş Demodelik Yönetimi Planı
* Güncellenmiş Ömür Devri Maliyet Tahmini
[[Dosya:Şekil8 Geliştirme Safhası.jpg|alt=Şekil 8 Geliştirme Safhası|sol|küçükresim|990x990pik|Şekil 8 Geliştirme Safhası]]

== 4.4. ÜRETİM SAFHASI ==

=== 4.4.1. AMAÇ ===
Üretim safhasının amacı, Odak Sistemi üretmek ve gereksinimlerin karşılandığını doğrulamaktır. Üretim safhasında, Odak Sisteminin üretimi ile birlikte ELD Elemanları başta olmak üzere destek ihtiyaçlarına yönelik üretim/kazanım faaliyetleri de yürütülür.

=== 4.4.2. TANIM ===
Üretim safhası, girdilerin incelenmesi ve analizi ile başlar. Bu analiz sonucunda çıktılar ve safhanın uygulama adımları belirlenir. Detaylı üretim planı ve kalite yönetim planı üretilir ve uygulanır.

Üretim ve kalite yönetim planına kritik yol analizi yapılarak öncelikler belirlenir ve Odak Sistemin üretim döneminde verimliliği artırılır. Risk değerlendirmesi yapılarak daha detay düzeydeki kritik yollar ve üretim safhasındaki hassas faaliyetler belirlenir.

Üretim safhasının sonunda Odak Sistem ile birlikte diğer ELD elemanları birleştirilerek kabiliyetin ürün ile sağlanması hedeflenir. Üretim safhasının sonunda sürdürülebilir kullanım ve destek dönemi için gereken tüm ELD elemanları planlanmış ve Odak Sistemin envanterden çıkarılması ile ilgili konsept geliştirilmiş olur.

=== 4.4.3. AŞAMALAR ===
Üretim safhasının aşamaları;

* İlk Üretim
** İlgili Kilometre Taşları: M4.1, M4.2

* Seri Üretim
** İlgili Kilometre Taşları: M4.3

olarak belirlenmiştir.

=== 4.4.4. FAALİYETLER ===
'''İlk Üretim Aşamasında;''' ürün ile ilgili olan malzemelerin üretilmesi, üretimin kontrolü ve gözlenmesi (Teknik, kalite ve performans özelliklerinin) ve kabul ve kalifikasyonların gerçekleştirilmesi faaliyetleri yürütülür.

* Hazırlanan Dokümanlar: Üretim Hattı Kalifikasyon Test Prosedürleri, Üretim Hattı Kalifikasyon Sonuç Raporları
* Gözden Geçirmeler: Üretim Planı Gözden Geçirme

'''Seri Üretim Aşamasında;''' ilk üretim aşaması faaliyetlerine ek olarak aşağıdaki faaliyetler yürütülür:

* Üretim safhasının bitimi ile ilgili kabul dokümanlarının oluşturulması ve yönetilmesi
* İlgili tüm verilerin arşivlenmesi
* ELD Planı’nın ihtiyaç varsa güncellenmesi
* Envanterden çıkarma konsepti ile ilgili girdilerin verilmesi
* Konfigürasyon Yönetim Planı’nın ihtiyaç varsa güncellenmesi
* Demodelik yönetimi stratejisinin ya da planının ihtiyaç varsa güncellenmesi
* Ürün ile ilgili ihtiyaç varsa ömür devri maliyet tahmininin güncellenmesi
* Öğrenilmiş derslerin safha sonunda dokümante edilmesi
* Ürünün ELD elemanları ile ilgili uygulama yöntemlerinin ve güncellemelerin kontrol edilmesi faaliyetleri gerçekleştirilir.
* Hazırlanan Dokümanlar: Kabul Test Prosedürleri, Kabul Test Sonuç Raporları
* Gözden Geçirmeler: Kabul Test Prosedürleri Gözden Geçirme

=== 4.4.5. KİLOMETRE TAŞLARI ===
Üretim safhasındaki kilometre taşları aşağıda belirtilmiştir:

* M4.1: Üretim planının onaylanması
* M4.2: Kalite planının onaylanması
* M4.3: Odak Sistemin ihtiyaç makamı ve tedarik makamı tarafından kabulü

=== 4.4.6. GİRİŞ KRİTERLERİ ===
Üretim safhasındaki giriş kriterleri aşağıda belirtilmiştir:

* Üretim safhası içindeki aşamalarda gerçekleştirilecek faaliyetler için gerekli kaynakların varlığı

=== 4.4.7. ÇIKIŞ KRİTERLERİ ===
Üretim safhasındaki çıkış kriterleri aşağıda belirtilmiştir:

* Safha çıktılarının sunulması
* Programın durdurulması, devamı, bir önceki safhaya geri dönüş gibi kararların verilmesi

=== 4.4.8. GİRDİLER ===
Üretim safhasındaki safha girdileri aşağıda belirtilmiştir:

* TVP
* Güncellenmiş Proje Yönetim Planı
* Güncellenmiş ELD Planı
* Güncellenmiş Kalite Yönetim Planı
* Güncellenmiş Konfigürasyon Yönetim Planı
* Güncellenmiş Risk Değerlendirme Planı
* Güncellenmiş Demodelik Yönetimi Planı
* Üretim Planları
* Ömür Devri Maliyet Tahmini
* Riskler ve Aksiyon Planı
* Bakım El Kitapları
* Eğitim/Eğitim Dokümanları
* Prototip / Odak Sistem

=== 4.4.9. ÇIKTILAR ===
Üretim safhasındaki safha çıktıları aşağıda belirtilmiştir:

* Üretilmiş Odak Sistem
* Yedek / Destek Donanımları
* Teknik Yayın (Bakım ve diğerleri)
* Eğitim/Eğitim Dokümanları
* Envanterden Çıkarma Safhası için Güncellenmiş Konsept
* Sürdürülebilir Kullanım ve Destek Dönemi için Gerekli Tüm ELD Elemanları
* Güncellenmiş ELD Planı ve Alt Planlar
* Güncellenmiş Kalite Yönetim Planı
* Güncellenmiş Konfigürasyon Yönetim Planı
* Güncellenmiş Demodelik Yönetimi Planı
* Güncellenmiş Ömür Devri Maliyet Tahmini
[[Dosya:TSSODYP01.09.jpg|alt=Şekil 9 Üretim Safhası|sol|küçükresim|950x950pik|Şekil 9 Üretim Safhası]]

== 4.5. KULLANIM SAFHASI ==

=== 4.5.1. AMAÇ ===
Kullanım safhası, ürünün envanterde bulunduğu ve/veya harekat alanlarında fiilen kullanıldığı safhadır.

Kullanım safhası, sınırlı yetenekle üretilmiş ürünlerin kullanımı ile başlayabilir. İlave yetenekler tamamlanıp, sisteme eklenir ve hedeflenen tüm yetenek kullanıcıya sağlanır.

=== 4.5.2. TANIM ===
Kullanım safhası, Odak Sistemin operasyonel çerçevede kullanıma hazır hale gelmesi (aktifleştirilmesi) ile birlikte başlar ve bundan itibaren sorumluluk tamamen kullanıcıya geçer. Odak Sistem, hizmet dışı kaldığı anda bu safha sonlanır. Odak Sistemin etkin hale getirilmesi ve kullanılmaya başlamasıyla birlikte, performansı izlenmeli ve uygunsuzluklar, eksiklikler, arızalar uygun şekilde kayıt altına alınmalı, tanımlanmalı, çözülmeli ve sonrasında da tüm sonuçlar kayıt altına alınmalıdır. Kullanım safhası süresince, Odak Sistem ve verilen hizmetler geliştirilebilir, bu da farklı konfigürasyonların ortaya çıkmasına neden olabilir. Bu tarz konfigürasyon değişikliklerinin Konfigürasyon Yönetim Planı uygulamaları doğrultusunda dokümante edilmesi gereklidir. İlgili organizasyonun, operasyonel altyapıya tesis, ekipman, eğitimli personel ve el kitapları dahil (tüm bunların üretim safhasında geliştirilmiş veya edinilmiş olması gerekir) sahip olduğu varsayılmaktadır.

=== 4.5.3. AŞAMALAR ===

* Odak Sistemin Kullanımı Aşaması
** İlgili Kilometre Taşları: M5.1, M5.2

=== 4.5.4. FAALİYETLER ===
Kullanım safhasının faaliyetleri Destek safhası ile yakından ilişkilidir ve çoğu zaman bu faaliyetler iç içe geçmiş durumdadır.

Kullanım Safhası, Odak Sistemin Kullanımı Aşaması boyunca aşağıdaki faaliyetlerin yerine getirilmesi gereklidir;

* Etkinleştirilmiş ürün ve hizmetler sağlanması,
* Eğitilmiş ve kalifiye operatörler atanması,
* Sistemin tanımlı operasyonel çevresinde etkin hale getirilmesi,
* Sistemin operasyonel planlara, iş güvenliğine, çevre koruma yönetmeliklerine ve uluslararası insan hakları hukukuna uygun olarak kullanıldığından emin olacak şekilde operasyonun izlenmesi,
* Servis performansının güvenilirlik, bakım yapılabilirlik ve kullanıma hazır olma değerlerini kapsayacak şekilde kabul edilebilir parametreler dâhilinde olduğunu doğrulamak amacıyla veri toplayarak, sistem operasyonun izlenmesi,
* Sağlanan hizmetlerle ilgili bir uygunsuzluk olması durumunda, hata tanımlama faaliyetlerinin gerçekleştirilmesi,
* Uygulanabilir olan durumlar için düzeltici faaliyetlerin belirlenmesi,
* Gerekli olması durumunda, işletim prosedürlerinin güncellenmesi,
* Kullanıcı geri bildirimlerinin alınması,
* Uygulanabilir olması durumunda, düzeltici tasarım değişikliklerinin talep edilmesi,
* Ömür durum tespiti ve uzatımı yaklaşımının belirlenmesi,
* Mühendislik değişikliklerinin gözden geçirilmesi ve uygulamaya alınması,
* Kazanılmış dersleri kaçırmamak için, faaliyet sonrası gözden geçirmelerin gerçekleştirilmesi.

Kullanım safhasında:

* Hazırlanan Dokümanlar: Kullanım dönemi verileri ile hazırlanan/güncellenen dokümanlar.
* Gözden Geçirmeler: Kullanım dönemi verilerine yönelik çeşitli gözden geçirmeler.

=== 4.5.5. KİLOMETRE TAŞLARI ===

* M5.1: Kullanım Gözden Geçirme (In-Service Review)
* M5.2: Planlı Büyük Bakımlar (Planned major maintenance events)

=== 4.5.6. GİRİŞ KRİTERLERİ ===

* Kalifikasyon sonuçları ve muayene kabul raporları
* Safha faaliyetlerini gerçekleştirmek için tedarik desteği, insan gücü ve personel, destek ve test ekipmanı, eğitim ve eğitim desteği, teknik bilgi ve veri paketi, tesisler ve alt yapı, bilgisayar kaynakları vb. kaynakların hazır bulunması

=== 4.5.7. ÇIKIŞ KRİTERLERİ ===

* Envanterden çıkarma planının hazırlanmış ve onaylanmış olması
* Envanterden çıkarma planının hem donanım hem de yazılımlar için tüm prosedürleri içermesi
* Gerekli safha çıktılarının sağlanması
* Programı sonlandırma kriteri

=== 4.5.8. GİRDİLER ===

* Sözleşme ve Ekleri
* Kullanıma hazır odak sistemin üretilmiş ve envantere alınmış olması
* Kullanıcı tarafında, malzeme dışında kalan, ilke, organizasyon, eğitim, materyal, liderlik ve eğitim ve eğitim desteği, tesisler ve birlikte çalışabilirlik gibi tüm gerekliliklerin (DELTMATO: Doktrin, Eğitim, Liderlik, Teşkilat, Malzeme, Altyapı, Tesisler, Ortak çalışabilirlik) tamamlanmış olması
* Destek safhası için bakım, insan gücü ve personel, alt yapı, ambalajlama, taşıma, depolama, nakliye ve bilgisayar kaynakları gibi hususları kapsayan tüm plan ve hükümlerin sağlanmış olması
* Uluslararası insan hakları hukuku ile ilgili olarak planlanmış çözümlerin, çevresel emniyet ve sağlık risk değerlendirmelerinin ve sistem emniyet programlarının uygunluğunun kanıtlanmış olması
* Envanterden çıkarma safhası için belirlenmiş konseptin gerekli olması durumunda güncellenmesi
* Kullanım için sınırlama ve özel koşulların yerine getirilmesinde eksikliklerin bildirilmesi ve gerekiyorsa, kullanım safhasının sürdürülmesi için resmi onayların alınması
* Ürün Destek Stratejisi ve Modeli (Yerlileştirme/Millîleştirme dahil)
* Tedarik Zinciri Yönetimi
* Destek Stratejileri Metrikleri, İyileştirme Metrikleri, Envanter Bilgileri
* Destek ve Test Ekipmanları
* Kalite Yönetim Planı
* Konfigürasyon Yönetim Planı
* ELD Planı
* Demodelik Yönetim Planı
* Ömür Devri Maliyet Tahmini
* Kazanılmış Dersler

=== 4.5.9. ÇIKTILAR ===

* Sağlanan Yetenek
* Odak Sistemin Envanterden Çıkarılması Kararı
* Envanterden Çıkarma Onayı
* Kullanım ve Bakım Verileri Dokümanı
* Güncellenmiş Ömür Devri Maliyet Tahmini
* Kazanılmış Dersler

[[Dosya:TSSODYP01.10.jpg|alt=Şekil 10 Kullanım Safhası|sol|küçükresim|721x721pik|Şekil 10 Kullanım Safhası]]

== 4.6. DESTEK SAFHASI ==

=== 4.6.1. AMAÇ ===
Sistemin ömür devri boyunca kendisinden beklenen yetenekleri ve hizmetleri yerine getirmesi ve kullanım sürdürülebilirliğini sağlaması maksadıyla planlanan lojistik destek hizmetlerinin yürütülmesidir.

=== 4.6.2. TANIM ===
Destek Safhası; Odak Sistemin işlevine ve kullanımına yönelik lojistik destek kapsamında yer alan bakım ve diğer destek gereklerinin planlanması çalışmaları ile başlar. Bu safha, Odak Sistem kullanıcısının yürüteceği destek hizmetine yönelik tüm faaliyetlerin kapsamının tanımlanmasını içerir. Ürüne özgü destek stratejisinin ve planların oluşturulması ve uygulanması bu safhadaki temel faaliyettir. Odak Sistemlerin muharebe ve/veya operasyon etkinliğinin sağlanması açısından Odak Sisteme ilişkin teknik gereksinimler kadar lojistik desteğe ilişkin gereksinimlerin de karşılanması zorunluluğu vardır. Sistem ömür devrinin erken safhalarından itibaren ELD çalışmalarına başlanılması ve geliştirme safhasında sistem mühendisliği ile ELD ve LDA çalışmalarının birlikte yürütülmesi esastır. Destek unsuru ve hizmetin tanımlanması, sınıflandırılması, performansının izlenmesi, aksaklıkların, eksikliklerin ve hataların raporlanmasının yanı sıra, bu aksaklık ve eksikliklerin düzeltilmesine yönelik çözüm önerilerinin sunulması da destek safhası kapsamında yürütülür. Öngörülen/karşılaşılan darboğazların çözümleri; bakım yapısında gözden geçirme sonucu yapılan değişiklikler, büyük/küçük sistem hizmet değişikliği veya Odak Sistem ve/veya destek unsurlarının envanterden çıkarılması şeklinde olabilir. Bu safhadaki geri bildirimler ve yeniden değerlendirme faaliyetleri kritik öneme sahiptir. Bu safha destek faaliyetlerinin tamamlanması ve Odak Sistemin envanterden çıkarılması ile son bulur.

=== 4.6.3. AŞAMALAR ===

* Desteğin Planlanması Aşaması
** İlgili Kilometre Taşları: M6.1

* Desteğin Uygulanması Aşaması
** İlgili Kilometre Taşları: M6.2, M6.3

=== 4.6.4. FAALİYETLER ===
Sistem Ömür Devri Yönetimi içindeki safhalarla karşılaştırıldığında kullanım ve destek safhaları diğer safhalara göre daha uzun bir süreyi kapsamaktadır. Bu uzun süre boyunca Odak Sistemle ilgili tüm parametreler değişmekte, kısıtlar farklılaşmakta, söz konusu iki safhada yer alan tüm fiziki ve fiziki olmayan ögeler arasındaki ilişkilerin şekli, büyüklüğü, yönü, yoğunluğu da buna uygun olarak değişim göstermektedir. Bu nedenle Kullanım Safhası ile Destek Safhasının, bir birleri üzerindeki etkileri göz ardı edilmeden ayrı ayrı değerlendirilmesinin planlama, uygulama ve program/proje yönetimi açısından önemli faydaları bulunmaktadır. Teknolojideki hızlı değişim ve idame maliyetlerindeki artış dikkate alındığında Destek Safhasının çok zamanlı, çok katmanlı ve dinamik tarzda tasarlanması önem kazanmaktadır.

Destek Safhası süresince;

* Destek stratejisinin/planının (periyodik bakım, arıza tespiti, onarım, test işlemleri vb.) planlanması ve uygulanması,
* Odak Sistemin geliştirme, üretim ve kullanım safhalarında yapılan lojistik destek analizlerine göre hazırlanan ELD Planı kapsamında uygulamaların gerçekleştirilmesi,
* Sistem yeterliliğinin değerlendirilmesi için kullanım ve hata verilerinin izlenmesi,
* Düzeltici, önleyici ve duruma bağlı bakım faaliyetlerinin geliştirilmesi ve yapılandırılmış yeterliliğin onaylanması, (Tedarik makamı, üretici, kullanıcı, teknik otorite ve destek unsurları arasındaki ilişki ve etkileşiminin en yüksek seviyede olmasını sağlamak bakımından)
* Geçmiş problemlerin ve bunlara yönelik olarak yürütülen düzeltici eylemler ve eğilimlerinin raporlarının hazırlanması,
* Demodelik yönetiminin sağlanması,
* Alınan derslerin oluşturulması amacıyla “Eylem Sonrası Gözden Geçirme” faaliyetleri yürütülmesi,
* Savunma sistemleri tedarik edildiğinde son kullanıcı ihtiyaçlarının karşılanması ve bu sistemleri faal tutacak desteğin sağlanması esastır. Odak sistemlerin kullanım ve destek safhasında, zamanla operasyonel çevrelerdeki ihtiyaçlar değişmekte, lojistik destekte zorluk, kesinti ve yüksek maliyet artışları yaşanmakta (demodelik), yaşlanan sistem kabiliyetlerinde düşüş olabilmekte, aynı zamanda teknolojik gelişmelere uyum ve yeni kabiliyet ekleme ihtiyaçları ortaya çıkmaktadır. Savunma platform ve sistemlerinin öngörülen ömür devri boyunca kabiliyet muhafazasının sağlanması ve/veya arttırılması kapsamında bu sistemler için çözüm olarak yarı ömür (devri) modernizasyonunun / ömür ortası kabiliyet yükseltmesinin yapılması planlanır ve bu maksatla modernizasyon/modifikasyon projeleri geliştirilir.

=== 4.6.5. KİLOMETRE TAŞLARI ===

* M6.1: Sahada İlk kullanım
* M6.2: Hizmet Durumu Gözden Geçirme
* M6.3: Modifikasyon/İyileştirme, Ömür Uzatım Faaliyetleri

=== 4.6.6. GİRİŞ KRİTERLERİ ===

* Sistem destek ihtiyacı
* Destek safhası esnasında kullanılacak destek sistemlerinin, sistem elemanlarının ve hizmetlerin bir araya getirilmesi

=== 4.6.7. ÇIKIŞ KRİTERLERİ ===

* Envanterden çıkarma planının hazırlanmış ve onaylanmış olması
* Safhanın beklenen çıktılarının ilgili seviyelere dağıtımı
* Proje/Program sonlandırma kriterleri/stratejileri

=== 4.6.8. GİRDİLER ===
'''Destek Planlama Aşaması:'''

* Sistem Kullanım ve Destek Gerekleri
* Mevcut İmkan ve Kabiliyetler
* Ürün Destek Stratejisi ve Modeli (Yerlileştirme/Millîleştirme dahil)
* Ömür Devri Maliyet Tahmini
* Sözleşme ve Ekleri
* ELD Planı
* Kalite Yönetim Planı
* Konfigürasyon Yönetim Planı
* Demodelik Yönetim Planı
* Alınan Dersler

'''Destek Uygulama Aşaması:'''

* Sözleşme ve Ekleri
* Ürün Destek Stratejisi ve Modeli (Yerlileştirme/Millîleştirme dahil)
* Sürdürülebilir Kullanım ve Destek Dönemi için Gerekli Tüm ELD Elemanları
* Ömür Devri Maliyet Tahmini
* ELD Planı
* Kalite Yönetim Planı
* Konfigürasyon Yönetim Planı
* Demodelik Yönetim Planı
* Alınan Dersler

=== 4.6.9. ÇIKTILAR ===

* Güncellenmiş Kullanım ve Bakım Verileri
* Odak Sistemin Güvenilirlik, Hazır Bulunuşluk Oranı, Desteklenebilirlik Durumu
* Muharebe ve/veya Operasyon Performansı
* Güncellenmiş Sistem Bakım Gerekleri
* Kullanıcı Hata Raporları
* Güncellenmiş Ömür Devri Maliyet Tahmini ve Gerçekleşen Maliyet
* İdame Stratejisinde Düzeltici Faaliyetler
* Odak Sistem Envanterden Çıkarma Kararı
* Deaktivasyon Onayı
* Alınan Dersler

[[Dosya:Şekil 11 Destek Safhası.jpg|alt=Şekil 11 Destek Safhası|sol|küçükresim|722x722pik|Şekil 11 Destek Safhası]]

== 4.7. ENVANTERDEN ÇIKARMA SAFHASI ==

=== 4.7.1. AMAÇ ===
Envanterden çıkarma, sahip olunan Odak Sistemin yeniden kullanım, transfer, hibe, satış, imha veya diğer seçeneklerle değerlendirilmesi sürecidir.

Envanterden çıkarma safhasının amacı; planlanan kullanım ömrü sonunda veya kullanım ömrü dolmadan envanterden çıkarma kararının verilebildiği durumlarda ilgili sistemin operasyonel ve destek hizmetlerinin sonlandırılması ve sistem için mümkün olan seçeneklerin değerlendirilerek sürecin işletilmesidir. Bu kapsamda standart yapıda envanterden çıkarma rehber dokümanlarını işletebilmek faydalı bir uygulamadır. Süreç sonucunda temel çıktılar:

* Ulusal güvenlik düzenlemelerinin korunması,
* Çevreye etki edebilecek hataların minimuma indirilmesi,
* Kısa veya uzun vadede çevreyi ve insan sağlığını olumsuz etkileyecek zehirli maddelerin etkilerinin yok edilmesi,
* Planlanan envanterden çıkarma opsiyonlarıyla ilgili olabilecek açık ihtiyaçların karşılanabilmesi,
* Optimum parasal dönüşün sağlanması,
* Sistemin yok edilmesi ya da değerlendirilmeksizin kullanımının terk edilmesi seçimlerinin minimize edilmesi,
* Özellikle savunma sanayii ürünlerinde silahların yayılması ya da kötü amaçlı gruplar tarafından ele geçirilmelerinin engellenmesi olacaktır.

=== 4.7.2. TANIM ===
Envanterden çıkarma safhası resmi olarak Odak Sistemin kullanımdan kaldırılması kararı ile başlasa da sistem ömür devrinin erken safhalarında gerekli planlamalar yapılmalıdır. Geliştirme programlarında envanterden çıkarma gereksinimleri; tasarıma dâhil edilmeli, envanterden çıkarma kararları ve yürütülecek faaliyetler, etkilenen paydaşlar açısından dikkatlice değerlendirilmeli ve en fazla faydayı sağlayacak opsiyonlar uygulamaya alınmalıdır. Envanterden çıkarma kararlarının alınmasında şüphesiz en önemli kriter, sistemden beklenen tanımlı fonksiyonların/operasyonel etkinliğin maliyet etkin bir şekilde tam anlamıyla yerine getirilip getirilemediğinin sorgulanmasıdır. Bu aşamada gelişen teknoloji dolayısıyla ortaya çıkabilecek yeni kabiliyet ihtiyaçları da etkili bir diğer faktör olarak belirtilebilir.

Sistem envanterden çıkarma gereksinimleri; sürecin özellikle çevresel ve ekonomik boyutta önemli etkileri olabileceği için bir plan dâhilinde projenin erken safhalarından itibaren yönetilmesi gereken bir konudur. Faydalı ömür sonuna gelmeden geliştirilmesi gereken envanterden çıkarma planı, seçeneklerin tanımlanması ve gereklerin belirlenmesi ile yasal ve düzenleyici gereklere uyumu sağlayacaktır. Bu planın safha başlangıcından önce tamamlanmış olması gerekmektedir.

Erken dönemlerde planlama ile ürün kullanımı süresince de ortaya çıkabilecek atıkların yönetimi sağlanabilecektir. Bu kapsamda, geliştirme safhasında zararlı maddelerin ürün verisi ve konfigürasyon yönetimi olarak ürün kırılımında yer alması sürecin önemli bir iş adımı olarak örnek verilebilir. Yine kimyasal malzemelerin uluslararası düzenlemelere göre kodlandırılması ayrı bir geliştirme safhası aktivitesi olarak aktarılabilir.

Envanterden çıkarma safhası aktiviteleri kapsamında ürün demontajı gibi bazı görevler, Bakım Görev Analizi (Maintenance Task Analysis) çalışmaları kapsamında değerlendirilebilir. Belirli bir formatı olmamasına rağmen, plan aşağıdakileri içerebilir:

* Sürecin tanımlanması
* Organizasyonel sorumluluklar
* Güvenlik hususları
* Tehlikeli madde idaresi ve sivilleştirme gereksinimleri
* Envanterden çıkarma takvimi
* Envanterden çıkarma maliyeti ve finansman

Envanterden çıkarma safhası kapsamında planlamalara dâhil edilebilecek bir takım faktörler söz konusudur. Faaliyetin niteliğine göre uyarlama mümkündür. Aşağıdakiler örnek olarak listelenebilir:

* Optimum geri dönüşü sağlayacak satış metotlarının değerlendirilmesi
* Sivilleştirme programlarının değerlendirilmesi
* Ticari düzenleme ve yasalara uyum gösterilmesi
* Alt yüklenici kullanımı söz konusu olacaksa buna uygun gereksinimlerin belirlenmesi ve bunların etkin yönetimi
* Uygun yerleşim planı ve çeşitli güvenlik önemlerine sahip envanterden çıkarma tesisleri
* Müşteriler için fazla/artık ürünler konusunda yeniden kullanım, bağış ve pazar desteği seçeneklerinin değerlendirilmesi
* Tehlike unsuru içeren bileşenler için yetki durumlarına göre envanterden çıkarma talimatlarının belirtilmesi
* Çevresel korumanın sağlanabilmesi için uygun ulaştırma/taşıma elemanları
* Farklı düzenlemelere göre hareket etmeyi gerektirebilecek sistem bileşenlerinin ayrıştırılması ve tehlikeli maddeler için uygun depolama koşullarının oluşturulması
* Hazır ürünler için envanterden çıkarma gereksinimlerinin, tedarikleri ile birlikte değerlendirilmesi
* Radyoaktif atık, nükleer silahlar ve kimyasal yayılma ile ilgili malzemeler ve kriptolojik bilgi içeren güvenlik birimlerinin ayrıca değerlendirilmesi

=== 4.7.3. AŞAMALAR ===
Envanterden çıkarma safhası iki aşamadan oluşur:

* İlişkinin Kesilmesi Usulleri Aşaması; Odak sistem ve destek unsurlarının hizmet sürelerinin sonlandırıldığı, erken safhalarda planlanan faaliyetlerin detaylandırıldığı ve maksimum faydayı sağlayacak stratejilerin geliştirildiği aşamadır.
** İlgili kilometre taşları: M7.1

* İlişkinin Kesilmesi Aşaması; bir önceki aşamada geliştirilen stratejilerin onaylanması ile başlar. Faydalı ömür sonunda savunma ve güvenlik sisteminin sivilleştirilmesi ve envanterden çıkarılması ile ilişkili maliyetlerin değerlendirilmesi gerekmektedir. Bu aşamada, sistem kaynak havuzuna tekrar eklenebilecek değerli malzemelerin ve parçaların maliyet etkin bir şekilde envanterden çıkarılması değerlendirilir. Sistemi oluşturan bütün elemanların ekonomik geri dönüşüm seçenekleri değerlendirilmeden envanterden çıkarılmasının önüne geçilir.
İlişkinin kesilmesi aşaması; envanterden çıkarma safhasına yönelik faaliyetlerin sonlandırıldığı aşama olacaktır. Bu aşamada, farklı sistem bileşenleri için farklı envanterden çıkarma seçenekleri söz konusu olabilecektir. Sistem ömür devri maliyeti hesaplamaları için maliyet ve elde edilen gelir kayıtları değerlendirilir. Diğer projelere yönelik süreçlerin iyileştirilmesi için kazanılmış dersler mutlaka kayıt altına alınmalı ve etkin kullanıma sunulması açısından uygun şekilde muhafaza edilmeleri sağlanmalıdır.

** İlgili kilometre taşları: M7.2

=== 4.7.4. FAALİYETLER ===
Envanterden çıkarma safhasında yürütülebilecek faaliyetler aşağıdaki şekilde listelenebilir:

'''İlişkinin Kesilmesi Usulleri Aşamasında;'''

* Tehlike analizi ve risk değerlendirmesi yapılması (özellikle kullanım ömrü dolmadan envanterden çıkarma kararı verildiğinde güvenlik ve gizlilik anlamında gerekli önlemlerin değerlendirilmesi)
* Odak Sistem sayısı, envanterden çıkarma takvimi, işlem sırası vb. bilgileri içeren envanterden çıkarma stratejisinin tanımlanması
* Envanterden çıkarma sırasında kullanılacak yardımcı bileşenlerin ve hizmetlerin tedariği
* Operasyondan kaldırmaya hazırlamak için Odak Sistem deaktivasyonu
* Sistem personelinin programdan çekilmesi
* Envanterden çıkarma bölgelerine gönderilecek birimlerin gerekli bilgilerinin sağlandığı dokümantasyon ile gönderilmesi
* Envanterden çıkarma programlarının yürütülmesinden sorumlu olacak birimler ile askeri makamların koordinasyonunun sağlanması
* Değerli malzemelerin geri dönüşüm programlarının izlenmesi ve gerekli desteğin sağlanması
* Ayrıştırılan sistem elemanları için yeterli alanların düzenlenmesi, mevcut durumlarının korunması ve temasın azaltılması
* Kirlilik ve karışmanın engellenmesi, düzgün kimliklendirme işlemlerinin yürütülmesi ve depolama alanlarında bilgilendirici yazı, levha ve çizgilerin kullanılması
** Hazırlanan Dokümanlar: Envanterden Çıkarma Stratejisi
** Gözden Geçirmeler: …

'''İlişkinin Kesilmesi Aşamasında;'''

* Yeniden kullanım, geri dönüşüm, yenileme (reconditioning), yenileştirme (overhaul), arşivleme, yok etme, bağışlama, iade (return) veya satış vb. işlemler için Odak Sistemin envanterden çıkarılmasını kolaylaştırmak anlamında Odak Sistemin yönetilebilir elemanlara demonte edilmesi
* Gerekli güvenlik önlemlerinin sağlanması
* Eğer Odak Sistem depolanacaksa, koruma tesisleri, depolama lokasyonları, gözlem kriterleri ve depolama periyotlarının tanımlanması
* Atık yönetimini kolaylaştırmak ve atık miktarını azaltmak için gerekli hallerde Odak Sistemin yok edilmesi
* Tehlikeli maddelerin uygun depolama ve taşıma işlemlerinin yürütülmesi
* Hurda geri dönüşüm programlarına destek sağlanması, hurda ayıklama ve kimliklendirme işlemlerinin yapılması
* Çeşitli opsiyonlarda tekrar kullanımı mümkün olacak birimler için kalite kontrol süreçlerinin işletilmesi
* Düzenli aralıklarla stok durumunun izlenmesi ve kayıtların güncellenmesi
* Konfigürasyon anlamında gerekli kayıtların tutulması
* Herhangi bir kaydın/bilginin envanterden çıkarılmasında paydaş onaylarının alınması
* Envanterden çıkarma faaliyetleri sonrası sağlık, emniyet, güvenlik ve çevresel anlamda zararlı faktörlerin olmadığının temin edilmesi
* Envanterden çıkarma raporlarının hazırlanması
* Uzun dönemli sağlık, emniyet, güvenlik ve çevre tehlikeleri durumlarında denetim ve gözden geçirmelere izin vermek adına program ömrü boyunca toplanan bilginin arşivlenmesi
** Hazırlanan Dokümanlar: Envanterden Çıkarma Safhası Gerçekleşme Raporu
** Gözden Geçirmeler: -

=== 4.7.5. KİLOMETRE TAŞLARI ===

* M7.1: Envanterden çıkarma stratejisi
* M7.2: Envanterden çıkarma safhası gerçekleşme raporu

=== 4.7.6. GİRİŞ KRİTERLERİ ===

* Envanterden çıkarma kararı ve konsepti
* Envanterden çıkarma planının hazırlanması
* Envanterden çıkarma stratejisinin geliştirilmesi

=== 4.7.7. ÇIKIŞ KRİTERLERİ ===

* Envanterden çıkarma safhası gerçekleşme raporu

=== 4.7.8. GİRDİLER ===

* Envanterden Çıkarma Kararı Alınan Sistem/Ürün
* İlgili Malzemelere Yönelik Emniyet Veri Dosyaları
* Envanterden Çıkarma Planı
* Envanterden Çıkarma Stratejisi
* Kullanım ve Bakım Verileri
* Ömür Devri Maliyet Tahmini ve Gerçekleşen Maliyet

=== 4.7.9. ÇIKTILAR ===

* Envanterden Çıkarma Safhası Gerçekleşme Raporu
* Olası Mali Fayda
* Toplam Ömür Devri Maliyeti Raporu
* Sonraki Programlar için Geri Besleme
* Gerçekleşen Ömür Devri Maliyeti
[[Dosya:Şekil12 Envanterden Çıkarma Safhası.jpg|alt=Şekil 12 Envanterden Çıkarma Safhası|sol|küçükresim|990x990pik|Şekil 12 Envanterden Çıkarma Safhası]]

= 5. UYARLAMA =
Sistem Ömür Devri Yönetimi Rehber Dokümanı; ömür devri faaliyetleri ve bu faaliyetler sırasında oluşturulacak iş ürünlerinin, NATO AAP-20, NATO AAP-48 ve ISO/IEEE 15288 standartları temel alınarak oluşturulan genel bir modeli tanımlamaktadır. Bu model Odak Sistemin yapısına göre olduğu gibi kullanılabileceği gibi, bazı durumlarda birtakım süreç ve iş ürünlerinde değişikliklerin yapılması gerekebilir. Genel anlamda, yapılacak bu değişiklikler Odak Sistemin durumuna göre, sistem mühendisliği süreçlerinin daha yoğun ya da seyrek şekilde ele alınması şeklinde gerçekleşir.

Uyarlama faaliyeti, risk ve süreç yoğunluğu arasında denge kurulmasını gerektirir. Şekil‑13’te görüldüğü gibi sistem mühendisliği faaliyetlerinin yoğunluğu arttıkça, ürün doğruluğu ile ilgili sorun yaşama riski azalmaktadır. Ancak bu ilişki doğrusal değildir ve artan efora karşılık edinilen kazanımın optimizasyon bölgesi dışında çok düşük seviyede olduğu görülmektedir. Bu durum grafiğin iki uç bölgesinde de projenin takvimsel ve maliyet risklerinin artmasına neden olmaktadır. Uyarlama faaliyetini yapacak olan uzman personelin iki durum arasındaki dengeyi oluşturması gerekmektedir.
[[Dosya:Şekil13 Risk Ve Süreç Denge Grafiği.jpg|alt=Şekil 13 Risk ve Süreç Denge Grafiği – McConnel, INCOSE SE Handbook|sol|küçükresim|800x800pik|Şekil 13 Risk ve Süreç Denge Grafiği – McConnel, INCOSE SE Handbook]]

'''Uyarlamanın Zamanlaması:'''

Sistem ömür devri içinde Konsept safhasının inceleme aşamasında ilk uyarlama faaliyetinin gerçekleştirilmesi ve sözleşmeye yansıtılması amaçlanmaktadır. Ancak uyarlama, ömür devri boyunca dinamik olarak tüm aşamalar içinde değişen risk ve koşullara göre her zaman ele alınması gereken bir faaliyettir. Projenin sözleşmeye bağlanması ile birlikte uyarlama faaliyetlerinin ne şekilde ele alınacağı hususunun proje içinde hazırlanacak olan yönetsel planlarda (Sistem Mühendisliği Yönetim Planı, Proje Yönetim Planı, Kalite Yönetim Planı vs.) tanımlanması ve yönetilmesi gerekmektedir.

'''Uyarlama Faaliyetleri:'''

* Uyarlama faaliyetini tetikleyen durumlar/gerekçeler her aşama için tanımlanır ve açıklanarak kayıt altına alınır. ''Bu durumlar aşağıda örnek olarak listelenmiş olup, farklı projeler kapsamında bunların dışında uyarlama gerekçeleri de oluşturulabilir''
** Proje riskleri, büyüklüğü, karmaşıklık seviyesi, paydaşlarının sayısı ve takvimi
** Teknoloji hazırlık seviyeleri
** Kullanım döneminin başlangıç zamanı ve toplam süresi
** Güvenlik, emniyet, kullanılabilirlik ve bulunabilirlik özellikleri ile ilgili koşullar
** Operasyonel koşullar ve kullanıcının acil ihtiyaçları
** Yeni gelişen teknolojiler
** Projeye tahsis edilmiş kaynaklar ve bütçe
** Servis sağlayıcı sistemlerin bulunabilirliği
** Ömür devri içindeki paydaşların program içindeki rol ve sorumlulukları
** Uymakla yükümlü olunan mevzuat (anayasa ve kanunlar, uluslararası antlaşmalar, kanun hükmünde kararnameler, tüzük ve yönetmelikler, yönergeler vb.)
** Müşteri tarafından talep edilen veya uymakla sorumlu olunan diğer standartlar

* Uyarlama alanları belirlenir.

Değişiklik yapılacak süreç adımları, iş ürünleri, gözden geçirme faaliyetleri vb. belirlenir ve uyarlama şekli tanımlanır.

* Uyarlama sonuçlarının etkileri tanımlanır ve bunlardan etkilenen tüm paydaşlardan görüş alınır.

* Uyarlama kararı verilir ve bu karar “Karar Yönetim Süreci” disiplini içinde ele alınır. Bu kapsamda kararı tetikleyen sebepler, etkileri, sonuçları, riskleri, getiri-götürü analizleri, paydaşların karar ile olan ilişkisi, kararın karakterizasyonu ve tüm olası alternatif çözümlerin incelenmesi ile en faydalı kararın verildiğinin kanıtlanması gerekir.

* Karar sonrası uyarlanmış süreç ve iş ürünleri tanımlanır.
* Yapılan tüm çalışmalar kayıt altına alınır. Bu kayıt bir rapor formatında oluşturulur.
* Uyarlama süreci ile ilgisi olan tüm paydaşlardan onay alınır.

= 6. EKLER =

== 6.1. UYARLAMA ÖRNEĞİ ==
Bu doküman kapsamında tanımlanan safha, aşama, girdi, çıktı, faaliyet vb. Sistem Ömür Devri Yönetimi elemanları, Uyarlama bölümünde anlatıldığı üzere çeşitli nedenlerle farklılaşabilecektir. Hazır Alım Projesi, Geliştirme Projesi, Üretim Projesi vb. proje türleri Sistem Ömür Devri Yönetimini şekillendirecek en önemli faktörlerden olacaktır. Zira bir geliştirme projesi için Sistem Ömür Devri Yönetiminin tüm safhaları işletilebilecekken, tasarımı ve doğrulaması daha önce farklı bir proje ile tamamlanmış yeni bir üretim projesi için geliştirme safhasına yönelik birçok faaliyet uyarlanabilecektir. Örnek bir geliştirme projesi için uyarlama bilgileri aşağıda verilmiştir:

* Kullanıcının elinde hazır alımla tedarik edilen daha eski nesil bir sistem bulunmaktadır.
* İlk kez geliştirilen, karmaşık sayılabilecek bir kara aracı söz konusudur.

'''Tablo 4 Uyarlama'''
{| class="wikitable"
|'''Sıra No'''
|'''Görev No'''
|'''Safha / Aşama / Faaliyet / Karar noktası'''
|'''Açıklama'''
|'''Uyarlama Bilgisi'''
|'''Referans Doküman'''
|-
|1
|1
|Ön Konsept Safhası
|Harekât ve lojistik ihtiyaçların belirlenmesi ve tanımlanmasını içerdiği için uyarlanamaz.
|Uyarlanamaz
|
|-
|2
|1.1
|İhtiyaç Belirleme Aşaması
|Sistem çözümüne ihtiyaç olup olmadığı kararı gerektiği için uyarlanamaz.
|Uyarlanamaz
|
|-
|3
|1.1.1
|Proje Kararı
|Bir sonraki aşamaya geçiş veya proje sonlandırma kriteri olduğu için uyarlanamaz.
|Uyarlanamaz
|
|-
|4
|1.2
|İhtiyaç Tanımlama Aşaması
|İhtiyacı karşılamaya yönelik sistem seçenekleri değerlendirildiğinden uyarlanamaz.
|Uyarlanamaz
|
|-
|5
|1.2.1
|Proje / İhtiyaç Tanımlama Dokümanı
|Sistem çözümü işaret etmeden temel gereksinimleri içerecek bir doküman hazırlanacaktır.
|Uyarlanamaz
|X Projesi Proje Tanımlama Dokümanı Rev1
|-
|6
|1.2.2
|Ön Yapılabilirlik Raporu
|Ön yapılabilirlik raporu hazırlanacaktır.
|Uyarlanamaz
|Ön Yapılabilirlik Raporu Rev1
|-
|7
|1.2.3
|Proje Planı (ELD Elemanları dahil)
|Proje/İhtiyaç Tanımlama Dokümanı ve ön yapılabilirlik raporu haricinde ihtiyaç tanımlaması için gereken dokümanlar belirlenecek ve hazırlanacaktır.
|Uyarlanamaz
|Proje Planı (ELD Elemanları dahil) Rev1
|-
|8
|1.2.4
|Tedarik Makamına Gönderilmesi Kararı
|Karar olduğu için uyarlanamaz.
|Uyarlanamaz
|
|-
|9
|2
|Konsept Safhası
|İhtiyacın karşılanmasına yönelik sistem çözümünün yapılabilirliğinin değerlendirilmesini kapsadığı için uyarlanamaz.
|Uyarlanamaz
|
|-
|10
|2.1
|İnceleme Aşaması
|Sistem çözümüne ilişkin ihtiyaçların detaylandırılarak gereksinimlere dönüştürülmesini içerdiği için uyarlanamaz.
|Uyarlanamaz
|
|-
|11
|2.1.1
|Yapılabilirlik Raporu
|Sistem gereksinimlerinin eksiksiz tespit edilebilmesi ve uzun vadeli ürün destek stratejilerinin oluşturulabilmesi için tüm paydaşların katılımı ile oluşturulmuş Yapılabilirlik Raporu hazırlanacaktır.
|Uyarlanamaz
|
|-
|12
|2.1.2
|Detaylı Proje Planı (ELD Elemanları dahil)
|Detaylı Proje Planı hazırlanacaktır.
|Uyarlanamaz
|
|-
|13
|2.1.3
|Kullanım Konsepti ve Görev Profilleri
|Destek stratejisinin belirlenebilmesi için değişik operasyon modlarını da içerecek şekilde araçların/görev ekipmanlarının dağılımı ve kullanım görev profili oluşturulacaktır.
|Uyarlanamaz
|
|-
|14
|2.1.4
|TÇD ve Ekleri
|TÇD uyarlanamaz.
|Uyarlanamaz
|
|-
|15
|2.2
|Projelendirme Aşaması
|Proje maliyet, performans, süre ve risk analizleri gerçekleştirildiği için uyarlanamaz.
|Uyarlanamaz
|
|-
|16
|2.2.1
|Operasyonel Konsept Dokümanı
|Kullanıcının gizli harekat bilgilerini açıklamayacağı fakat tasarım ve lojistik destek tasarımı için gerekli olan bilgileri sağlayacak şekilde (beraber görev yapacağı araçlar, kullanım konsepti, birlik isimleri belirtmeden birliklere dağılımı, farklı kullanım modları, depolama alanları, vb. ) Operasyonel Konsept Dokümanı hazırlanacaktır.
|Uyarlanamaz
|
|-
|17
|2.2.2
|Sözleşme ve Ekleri
|Uyarlanamaz.
|Uyarlanamaz
|
|-
|18
|2.2.3
|Ürün Destek Strateji ve Modeli (Yerlileştirme/Millîleştirme dahil)
|Ürün Destek Strateji ve Modeli (Yerlileştirme/Millîleştirme dahil) hazırlanacaktır.
|Uyarlanamaz
|
|-
|19
|2.2.4
|Ömür Devri Maliyet Tahmini
|Hazırlanacaktır.
|Uyarlanamaz
|
|-
|20
|2.2.5
|Kullanım Konsepti ve Görev Profili
|İnceleme aşamasında hazırlanan Görev profili Operasyonel Konsept Dokümanı ile beraber incelenerek güncellemesi yapılacaktır.
|Uyarlanamaz
|
|-
|21
|2.2.6
|Risk Değerlendirme Planı
|Risk Değerlendirme Planı hazırlanacaktır.
|Uyarlanamaz
|
|-
|22
|2.2.7
|Proje Uygulama Takvimi (PUT)
|PUT hazırlanacaktır.
|Uyarlanamaz
|
|-
|23
|2.2.8
|Proje Yönetim Planı
|Proje Yönetim Planı hazırlanacaktır.
|Uyarlanamaz
|
|-
|24
|2.2.9
|ELD Planı
|ELD Planı hazırlanacaktır.
|Uyarlanamaz
|
|-
|25
|2.2.10
|Kalite Yönetim Planı
|Kalite Yönetim Planı hazırlanacaktır.
|Uyarlanamaz
|
|-
|26
|2.2.11
|Konfigürasyon Yönetim Planı
|Konfigürasyon Yönetim Planı hazırlanacaktır.
|Uyarlanamaz
|
|-
|27
|2.2.12
|Demodelik Yönetimi Planı
|Ürün destek stratejisi ve ELD planı kapsamında Geliştirme safhasında hazırlanmasına karar verilmiştir.
|Uyarlanmıştır
|
|-
|28
|3
|Geliştirme Safhası
|Hedeflere uygun olarak Odak Sistem ve destek unsurlarının tasarım ve geliştirme faaliyetleri yürütüleceği için uyarlanamaz.
|Uyarlanamaz
|
|-
|29
|3.1
|Kavramsal Tasarım Aşaması
|Sistem çözümüne yönelik ilk geliştirme çalışmalarını içerdiğinden uyarlanamaz.
|Uyarlanamaz
|
|-
|30
|3.1.1
|Kavramsal Tasarım Raporu / Teklif Dokümanları
|Sözleşme imzası öncesi ilk değerlendirmeler teklif dokümanları ile iletildiği için Kavramsal Tasarım Raporu hazırlanmayacaktır.
|Uyarlanmıştır
|
|-
|31
|3.2
|Sistem Gereksinim Tanımlama Aşaması
|Gereksinimlerin yönetimi gerçekleştirildiği için uyarlanamaz.
|Uyarlanamaz
|
|-
|32
|3.2.1
|Sistem Gereksinim Tanımlama Dokümanı
|Projedeki Odak Sistem, alt sistem ve konfigürasyon birimlerinin gereksinimlerini yönetmek ve bu gereksinimlerle proje planları ve iş ürünleri arasındaki tutarsızlıkları engellemek amacıyla Sistem Gereksinim Tanımlama Dokümanı hazırlanacaktır.
|Uyarlanamaz
|
|-
|33
|3.2.2
|Sistem Gereksinimleri Gözden Geçirme Toplantısı
|İlgili paydaşların katılımıyla Sistem Gereksinim Gözden Geçirme Toplantıları düzenli olarak icra edilecektir.
|Uyarlanamaz
|
|-
|34
|3.3
|Ön Tasarım Aşaması
|Sistem mimarisi oluşturulması ve alt sistem gereksinim tanımlama faaliyetleri yürütüldüğü için uyarlanamaz.
|Uyarlanamaz
|
|-
|35
|3.3.1
|Sistem Tasarım Tanımlama Dokümanı
|Elektriksel ve mekanik arayüzler, nereden-nereye bilgileri, mesajlaşma arayüzleri ve şemaları vb. bilgileri içerecek Sistem Tasarım Tanımlama Dokümanı hazırlanacaktır.
|Uyarlanamaz
|
|-
|36
|3.3.2
|Sistem Arayüz Kontrol Dokümanı
|Sistem Tasarım Tanımlama Dokümanı Ek’i olarak verilecektir.
|Uyarlanmıştır
|
|-
|37
|3.3.3
|Test ve Değerlendirme Ana Planı
|Test edilecek yapılara ilişkin test gereksinimleri ve test planlarını içeren Test ve Değerlendirme Ana Planı hazırlanacaktır.
|Uyarlanamaz
|
|-
|38
|3.3.4
|Alt Sistemler İçin Gereksinim Tanımlama Dokümanları
|Sistem Tasarım Tanımlama Dokümanı Ek’i olarak verilecektir.
|Uyarlanmıştır
|
|-
|39
|3.3.5
|Güncellenmiş ELD Planı ve Alt Planlar
|Detay bileşenlerin detay tasarım aşamasında belli olması sebebiyle Envanterden Çıkarma Planı detay tasarım aşamasında hazırlanacaktır. ELD Planı ve diğer alt planlar ihtiyaçlar doğrultusunda güncellenecektir.
|Uyarlanmıştır
|
|-
|40
|3.3.6
|Ön Tasarım Gözden Geçirme Toplantısı
|İlgili paydaşların katılımıyla Ön Tasarım Gözden Geçirme Toplantısı düzenlenecektir.
|Uyarlanamaz
|
|-
|41
|3.4
|Detay Tasarım Aşaması
|Sistem ve alt sistem detay analiz ve tasarım faaliyetleri yürütüleceğinden uyarlanamaz.
|Uyarlanamaz
|
|-
|42
|3.4.1
|Teknik Veri Paketi
|Proje kapsamında gerekli katı modeller, teknik resimler, şartnameler, BoM, yazılım dokümantasyon vb. üretilecektir.
|Uyarlanamaz
|
|-
|43
|3.4.2
|Sistem ve Alt Sistem Doğrulama Planları
|Test ve Değerlendirme Ana Planı içerisinde verilecektir.
|Uyarlanmıştır
|
|-
|44
|3.4.3
|LDA Çıktıları
|Örnek 1:

Daha önce geliştirilmiş olan ortak alt sistem / LRU / SRU kapsamında hazırlanmış FMECA, RCM, LORA, MTA vb. analiz kayıtlarından faydalanılabilecektir. Diğer aday alt sistem / LRU / SRU’lar için LDA sonuçları kaydedilecektir.

Aday birimler ve gerçekleştirilecek analizlere yönelik planlama Lojistik Destek Analiz Planı içerisinde takip edilecektir. Güvenilirlik ve Emniyet çalışmaları ile etkileşimler; bu plan ve özel mühendislik faaliyetleri sonucunda üretilecek planlar ile sağlanacaktır.

Örnek 2:

LDA aday alt sistemler S3000L spesifikasyonuna göre seçilerek kritik görülen alt sistemler için LDA yapılacaktır.
|Örnek 1:Kısmen Uyarlanmıştır

Örnek 2:Uyarlanmıştır
|
|-
|45
|3.4.4
|Güvenilirlik ve Emniyet Çıktıları
|Daha önce geliştirilmiş olan ortak alt sistem / LRU / SRU kapsamında gerçekleştirilmiş GİK (RAMST) analiz sonuçlarından faydalanılabilecektir. Diğer aday alt sistem / LRU / SRU’lar için GİK çalışmaları yürütülecektir.
|Kısmen Uyarlanmıştır
|
|-
|46
|3.4.5
|Güncellenmiş Sistem Ömür Devri Yönetimi Stratejisi ve Modeli
|Detay tasarım faaliyetleri sonrası Sistem Ömür Devri Yönetim Stratejisi ve Modeli güncellenecektir.
|Uyarlanamaz
|
|-
|47
|3.4.6
|Kritik Tasarım Gözden Geçirme Toplantısı
|İlgili paydaşların katılımıyla Kritik Tasarım Gözden Geçirme Toplantısı düzenlenecektir.
|Uyarlanamaz
|
|-
|48
|3.5
|Entegrasyon ve Doğrulama Aşaması
|Sistem ve alt sistem test ve değerlendirme faaliyetleri yürütüleceğinden uyarlanamaz.
|Uyarlanamaz
|
|-
|49
|3.5.1
|Doğrulama Test Prosedürleri
|Sistem gereksinimleri ile uyumlu olarak yürütülecek testler sırasında kullanılacak kaynaklar, ihtiyaç duyulan test düzenekleri ve destek unsurları ile detaylı test adımlarını/metodolojisini içerecek Doğrulama Test Prosedürleri hazırlanacaktır.
|Uyarlanamaz
|
|-
|50
|3.5.2
|Doğrulama Sonuç Raporları
|Test faaliyetleriyle elde edilen sonuçları ve karşılaşılan hataları/uygunsuzlukları içerecek Doğrulama Sonuç Raporları hazırlanacaktır.
|Uyarlanamaz
|
|-
|51
|3.5.3
|Test Hazırlıkları Gözden Geçirme Toplantısı
|Doğrulama Test Prosedürleri ilgili paydaşlar ile hazırlanarak Test Hazırlıkları Gözden Geçirme Toplantısı gerçekleştirilecektir.
|Uyarlanamaz
|
|-
|52
|3.5.4
|Tasarım Doğrulama Gözden Geçirme Toplantısı
|İlgili paydaşların katılımıyla test sonuçları (Tasarım Doğrulama Gözden Geçirme Toplantısı) gözden geçirilecektir.
|Uyarlanamaz
|
|-
|53
|3.5.5
|İşlevsel Konfigürasyon Denetimi
|İşlevsel Konfigürasyon Denetimi gerçekleştirilecektir.
|Uyarlanamaz
|
|-
|54
|3.6
|Ürün Kalifikasyon Aşaması
|Odak Sistemin üretilebilir, test edilebilir, değerlendirilebilir, işletilebilir, desteklenebilir ve kullanımdan kaldırılabilir nitelikte olması sağlanacağından uyarlanamaz.
|Uyarlanamaz
|
|-
|55
|3.6.1
|Kalifikasyon Test Prosedürleri
|Sistem gereksinimlerinin karşılandığını gösterebilmek adına gerekli kaynakları içerecek şekilde Kalifikasyon Test Prosedürleri hazırlanacaktır.
|Uyarlanamaz
|
|-
|56
|3.6.2
|Kalifikasyon Sonuç Raporları
|Kalifikasyon faaliyetleri ile elde edilen sonuçlar, uygunsuzluklar ve düzeltici faaliyetler Kalifikasyon Sonuç Raporlarında kaydedilecektir.
|Uyarlanamaz
|
|-
|57
|3.6.3
|Kalifikasyon Gözden Geçirme Toplantısı
|Kalifikasyon Test Prosedürleri ilgili paydaşlar ile hazırlanarak Kalifikasyon Gözden Geçirme Toplantısı gerçekleştirilecektir.
|Uyarlanamaz
|
|-
|58
|3.6.4
|Üretim Hazırlıkları Gözden Geçirme Toplantısı
|Üretim Hazırlıkları Gözden Geçirme Toplantısı gerçekleştirilecektir.
|Uyarlanamaz
|
|-
|59
|3.6.5
|Fonksiyonel Konfigürasyon Denetimi
|Fonksiyonel Konfigürasyon Denetimi gerçekleştirilecektir.
|Uyarlanamaz
|
|-
|60
|4
|Üretim Safhası
|Odak Sistemin ve destek unsurlarının üretilmesi ve test edilmesi faaliyetleri gerçekleştirileceği için uyarlanamaz.
|Uyarlanamaz
|
|-
|61
|4.1
|İlk Üretim Aşaması
|Uyarlanamaz. Üretim faaliyetleri kontrol edilip kabul ve kalifikasyonlar gerçekleştirilecektir.
|Uyarlanamaz
|
|-
|62
|4.1.1
|Üretim Hattı Kalifikasyon Test Prosedürleri
|Üretim hattı kalifikasyonu sağlanacağından uyarlanamaz.
|Uyarlanamaz
|
|-
|63
|4.1.2
|Üretim Hattı Kalifikasyon Sonuç Raporları
|Üretim hattı uygunsuzlukları ile ilgili hataların minimuma indirilmesi hedeflendiğinden uyarlanamaz.
|Uyarlanamaz
|
|-
|64
|4.1.3
|Üretim Planının Gözden Geçirilmesi
|Değişken koşullar dolayısıyla üretim planının güncel tutulması gerektiğinden uyarlanamaz.
|Uyarlanamaz
|
|-
|65
|4.2
|Seri Üretim Aşaması
|Geliştirme sözleşmesi kapsamında sadece prototip üretimi gerçekleştirileceğinden seri üretim aşaması işletilmeyecektir.
|Uyarlanmıştır
|
|-
|66
|5
|Kullanım Safhası
|Odak Sistem etkin hale getirilip kullanıma alınacağı için uyarlanamaz.
|Uyarlanamaz
|
|-
|67
|5.1
|Odak Sistemin Kullanımı Aşaması
|Odak Sistem tanımlı operasyon çevresinde gerekli destek unsurları ile etkin hale getirileceğinden uyarlanamaz.
|Uyarlanamaz
|
|-
|68
|6
|Destek Safhası
|Sistemin ömür devri boyunca kendisinden beklenen kabiliyetleri yerine getirmesi, kullanım sürdürülebilirliğini sağlaması hedeflendiğinden uyarlanamaz.
|Uyarlanamaz
|
|-
|69
|6.1
|Destek Planlama ve Uygulama Aşamaları
|Uyarlanamaz.
|Uyarlanamaz
|
|-
|70
|7
|Envanterden Çıkarma Safhası
|Sahip olunan Odak Sistemin ve destek unsurlarının kullanım süresi sonunda envanterden çıkarma seçenekleri ile değerlendirilmesi finansal etki, yasal yükümlülükler, çevresel faktörler vb. konularda fayda sağlayacağından uyarlanamaz.
|Uyarlanamaz
|
|-
|71
|7.1
|İlişkinin Kesilmesi Usulleri Aşaması
|Odak Sistem ve destek unsurlarının hizmet sürelerinin sonlandırıldığı ve erken safhalarda planlanan faaliyetlerin detaylandırıldığı aşama olduğundan uyarlanamaz.
|Uyarlanamaz
|
|-
|72
|7.1.1
|Envanterden Çıkarma Stratejisi
|Maksimum getiriyi sağlayacak stratejilerin geliştirilmesi gerektiğinden uyarlanamaz.
|Uyarlanamaz
|
|-
|73
|7.2
|İlişkinin Kesilmesi Aşaması
|Envanterden çıkarma stratejileri uygulanacağından uyarlanamaz.
|Uyarlanamaz
|
|-
|74
|7.2.1
|Envanterden Çıkarma Safhası Gerçekleşme Raporu
|Envanterden çıkarma faaliyetlerine yönelik sonuçlar belirtileceğinden uyarlanamaz.
|Uyarlanamaz
|
|}

== 6.2. SİSTEM ÖMÜR DEVRİ KARŞILAŞTIRMALARI ==
Sistem Ömür Devri Yönetimi Rehberi hazırlıkları sırasında NATO AAP-20 standardı referans alınmıştır. Bu bölümde safha isimlendirmelerinin farklı kurumlarda, standartlarda ya da rehberlerde nasıl kullanıldığına dair bilgilendirme amaçlanmıştır.

'''Tablo 5 Farklı Kurumlarda/Standartlarda Sistem Ömür Devri Safhaları Terminolojisi'''
{| class="wikitable"
|'''AAP-20'''
|'''UK MoD'''
|'''US DoD'''
|'''SX000i S-Series Specification'''
|'''NASA Systems Engineering Handbook'''
|'''ISO/IEC 15288 Systems and Software Engineering-System Life Cycle Processes'''
|-
|'''Ön Konsept'''
|Konsept (Concept)
|Sistem Çözümü Analizi (Material Solution Analysis)
| rowspan="2" |Hazırlık (Preparation)
|Konsept Çalışmaları (Concept Studies)
| rowspan="2" |Konsept (Concept)
|-
|'''Konsept'''
|Değerlendirme (Assessment)
|Teknoloji Geliştirme (Technology Development)
|Konsept ve Teknoloji Geliştirme (Concept and Technology Development)
|-
| rowspan="2" |'''Geliştirme'''
| rowspan="2" |Gösterim (Demonstration)
| rowspan="2" |Mühendislik ve Üretim Geliştirme (Engineering and Manufacturing Development)
| rowspan="2" |Geliştirme (Development)
|İlk Tasarım ve Teknoloji (Preliminary Design and Technology)
| rowspan="2" |Geliştirme (Development)
|-
|Son Tasarım (Final Design)
|-
| rowspan="2" |'''Üretim'''
| rowspan="2" |Üretim (Manufacture)
| rowspan="2" |Üretim ve Konuşlanma (Production and Deployment)
| rowspan="2" |Üretim (Production)
|Son Tasarım ve Üretim (Final Design and Fabrication)
| rowspan="2" |Üretim (Production)
|-
|Sistem Montajı, Entegrasyon ve Test, Kullanıma Alma (System Assembly, Integration and Test, Launch)
|-
|'''Kullanım'''
|Kullanım (In-Service)
| rowspan="3" |Operasyon ve Destek (Operations and Support)
| rowspan="2" |Kullanım (In-Service)
| rowspan="2" |Operasyon ve Sürdürülebilirlik (Operations and Sustainment)
|Kullanım (Utilization)
|-
|'''Destek'''
|<nowiki>-</nowiki>
|Destek (Support)
|-
|'''Envanterden Çıkarma'''
|Sonlandırma (Terminate)
|Envanterden Çıkarma (Disposal)
|Envanterden Çıkarma (Closeout)
|Envanterden Çıkarma (Retirement)
|}

= 7. KAYNAKÇA =
1. Systems Engineering and Management for Sustainable Development – Volume II, Edited by Andrew P. Sage, ENCYCLOPEDIA OF LIFE SUPPORT SYSTEMS

2. Systems Life Cycle Costing, Economic Analysis, Estimation and Management John Vail Farr (Basım: 2011), (Modified from Andrews, Richard. 2003. An overview of Acquisition Logistics. DAU)

3. Logistics Engineering and Management (Benjamin S. Blanchard)

4. Systems Engineering and Analysis (Benjamin S. Blanchard &Wolter J. Fabrycky)

5. Systems Engineering Handbook, A Guide for System Life Cycle Processes and Activities, International Council on Systems Engineering, 2010

'''DOKÜMANIN HAZIRLANMASINDA GÖREV ALAN KURUM/KURULUŞLAR'''

SAVUNMA SANAYİİ BAŞKANLIĞI

MİLLİ SAVUNMA BAKANLIĞI

KARA KUVVETLERİ KOMUTANLIĞI

ASKERİ FABRİKALAR GENEL MÜDÜRLÜĞÜ

TERSANELER GENEL MÜDÜRLÜĞÜ

ASELSAN A.Ş.

EPENEK GESG SAVUNMA VE GÜVENLİK SİSTEMLERİ LTD. ŞTİ.

FNSS SAVUNMA SİSTEMLERİ A.Ş.

MİLSOFT YAZILIM TEKNOLOJİLERİ A.Ş.

ROKETSAN A.Ş.

Dosya:TSSODYP-01 Sistem Ömür Devri Yönetimi Rehberi (Ana Çerçeve) 20230103.pdf

2023-01-13T10:45:10Z

Oozdemir:

Entegre Lojistik Destek (ELD) Rehberi

2023-01-13T07:17:11Z

Oozdemir:

'''[https://tssodypwiki.ssb.gov.tr/images/a/af/TSSODYP_04_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şkanlığı çatısı altında, ilgili tüm paydaşların katılımıyla faaliyet göstermek üzere Türk Savunma Sanayii Ömür Devri Yönetimi Platformu (TSSÖDYP) kurulmuştur.

TSSÖDYP; savunma ve güvenlik sistemlerine ilişkin ihtiyacın belirlenmesi, sistemlerin tedariki, kullanımı, desteklenmesi ve envanterden çıkarması safhalarını bir bütün halinde ele alan Sistem Ömür Devri Yönetimi ilke ve uygulamalarının ülkemizde yaygınlaştırılmasını ve savunma programlarının/ projelerinin yürütülmesinde savunma ve güvenlik ekosistemini oluşturan tüm paydaşlarca anlayış birliğine ulaşılmasını amaçlamaktadır.

Savunma sistemlerinin ömür devri yönetiminde millî bünyemize uygun, ülkemize özgü çözümler üretmek ve bunları dokümante etmek gibi önemli bir misyonu olan TSSÖDYP; Başkanlığımız, Milli Savunma Bakanlığı ve ilgili birimleri, Genelkurmay Başkanlığı, K.K.K.lığı, Dz.K.K.lığı, Hv.K.K.lığı, J.Gn.K.lığı, S.G.K.lığı, EGM, TÜBİTAK, SASAD ve savunma sanayii firmaları temsilcilerinin katılımı ile çalışmalarına devam etmektedir.

Sistem ömür devri yönetimi yaklaşımı ile; savunma ve güvenlik sistemlerine ilişkin ihtiyacın belirlenmesi aşamasından envanterden çıkarma safhasının sonuna kadar görev alan tüm kamu kurum ve kuruluşları ile özel sektör firmalarının sistemlerin istenilen performans seviyesinde mümkün olan en az maliyetle tedariki, kullanımı ve lojistik desteğinin sağlanabilmesi için görev, yetki ve sorumlulukları çerçevesinde ömür devrinin tamamında birlikte çalışmaları öngörülmektedir.

Bu itibarla, savunma ve güvenlik sistemlerine ilişkin ihtiyacın belirlenmesinin, tedarikinin, kullanımının, lojistik desteğinin ve envanterden çıkarılmasının en baştan uzun soluklu bir program olarak kurgulanmasının ve ilgili birimler aracılığı ile sistem ömür devri yönetimi faaliyetlerinin yürütülmesinin faydalı olacağı değerlendirilmektedir.

TSSÖDYP tarafından son iki buçuk yıl içinde gerçekleştirilen çalışmalar ile savunma ve güvenlik sistemlerinin ömür devri yönetimine ilişkin planlama ve uygulamaya esas olacak yaklaşımları ortaya koyan 13 adet rehber, iki adet bilgi kitapçığı ve bir adet terminoloji dokümanı hazırlanmıştır. Uygulamalardan alınacak geri bildirimler ile söz konusu dokümanların güncellenmesi, geliştirilmesi ve önümüzdeki dönemde uygulamaya esas düzenlemelerin alt yapısını oluşturması hedeflenmektedir.

TSSÖDYP çalışmalarına katkı veren ve dokümanların hazırlanmasında görev alan tüm paydaşlarımıza teşekkürlerimi sunuyorum.

Prof.Dr. İsmail DEMİR

T.C. Cumhurbaşkanlığı

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.

Bu nedenle, tedarik edilen sistemlerin kullanım döneminde hedeflenen muharebe ve/veya operasyon performansının sürdürülebilirliğinin ve maliyet etkinliğinin sağlanması amacıyla sistemlerin ömür devrinde rol ve sorumluluğu bulunan tüm paydaşların katılımı ile Sistem Ömür Devri Yönetimi yaklaşımı geliştirilmiştir.

Sistem Ömür Devri Yönetiminin temel amacı; mevcut durumdaki değişimlere uyum sağlamaktan ziyade gelecekte ortaya çıkabilecek değişimleri öngörmek, belirlenen hedefler doğrultusunda gerekli önlemleri alarak değişimleri yönlendirmek ve kontrol altında tutmaktır. Harekât ihtiyaçlarının zamanında ve verimli şekilde karşılanması ve sahip olunan kaynakların maliyet etkin kullanımı esastır. Başka bir deyişle, sistem ömür devri yönetimi geleceği bugünden tasarlamak ve planlamaktır.

Bu doküman; Savunma Sanayii Başkanlığı (SSB), Milli Savunma Bakanlığının ilgili birimleri, Türk Silahlı Kuvvetleri (TSK), diğer ihtiyaç makamları ve savunma sanayi firmalarında Sistem Ömür Devri Yönetimi’nin bir kültür olarak yaygınlaştırılmasına ve uygulanmasına yönelik rehber oluşturmak amacıyla savunma sistemlerinin ömür devrinde rol ve sorumluluğu bulunan ilgili paydaşların katılımıyla hazırlanmıştır.

Entegre Lojistik Rehberi ile savunma ve güvenlik sistemlerinin görevlerini zamanında ve eksiksiz olarak yerine getirebilmesi için ihtiyaç duyulan destek unsurlarının ve lojistik destek faaliyetlerinin ihtiyaç belirleme aşamasından itibaren planlanmasına ve kullanım safhasındaki uygulamalara yardımcı olunması amaçlanmıştır.
= 1. GENEL =

== 1.1. GİRİŞ ==
Entegre Lojistik Destek (ELD) Rehberi, savunma ve güvenlik sistemlerinin görevlerini istenilen performans seviyesinde, zamanında ve kesintisiz yerine getirebilmesi için ihtiyaç duyulan destek unsurlarının ihtiyaç belirleme aşamasından başlamak üzere tedarik dönemi boyunca planlanması, temin edilmesi ve envantere alınan sistem/platformun kullanımı sırasında lojistik desteğinin sağlanması faaliyetlerinde yol gösterici rol oynamak üzere hazırlanmıştır. ELD ile ilgili konularda kavramsal bütünlük sağlanması, savunma sistemlerinin ömür devri yönetiminde yer alan tüm paydaşlar arasındaki iletişimin sağlıklı biçimde gerçekleştirilmesini sağlayacaktır.

== 1.2. AMAÇ ==
Bu doküman, sistem ömür devri yönetiminde rol ve sorumluluğu bulunan tüm paydaşlara ELD prensipleri, politikaları, yöntemler, standartlar ve organizasyonlar hakkında temel bilgileri vermek, yönlendirmek ve kavramsal birliği sağlamak için hazırlanmıştır.

Bu doküman, savunma ve güvenlik sektöründe görev alan tüm paydaşların ELD faaliyetlerine rehberlik etmek üzere hazırlanmıştır.

== 1.3. KAPSAM ==
Bu doküman, ülkemizde yürütülen/yürütülecek savunma ve güvenlik proje/programlarında sistem ömür devri yönetimi anlayışı içinde; gerektiğinde çok uluslu projelerde müşterek harekât isterleri, iletişim ve işbirliğinin yerine getirilmesine hizmet edecek ELD planlama ve uygulamalarını bir araya getirerek bir dizi halinde sunulmasına ilişkin esasları kapsamaktadır.

== 1.4. REHBERİN KULLANIMI ==
Bu dokümanda;

İlk bölüm; giriş, amaç, kapsam, referanslar gibi genel bilgileri içermektedir. Ayrıca terim ve kısaltmalar da bu bölümün içindedir.

İkinci bölümde; ELD, ELD’nin zaman içindeki gelişimi ve ilgili diğer kavramlar açıklanmaktadır.

Üçüncü Bölümde; ELD neden gereklidir sorusuna yanıt arandıktan sonra, ELD elemanları listelenmekte ve ELD elemanları hakkında detaylı bilgi verilmektedir.

Dördüncü Bölümde; ELD’nin bir alt kümesi olarak kabul edilen LDA kapsamı hakkında bilgilendirme yer almaktadır.

Beşinci Bölümde; ELD faaliyetlerinin sistem mühendisliği süreçleri ile ilişkileri anlatılmaktadır.

Altıncı Bölümde; proje yönetimi ve ELD ilişkisi çerçevesinde sistem ömür devri safhaları, proje ELD dokümanları ve takvimi oluşturulması ve acil ihtiyaçların karşılanması konularına yer verilimektedir.

ELD Planı Şablonu EK-A’da verilmiştir.

== 1.5. REHBERİN GÜNCELLENMESİ ==
Rehber ilgili paydaşların ihtiyacı doğrultusunda güncellenecektir. Değişiklikler aşağıdaki tablodan izlenebilecektir.

'''Tablo 1 Değişiklik izleme Tablosu'''
{| class="wikitable"
|'''Revizyon No'''
|'''Revizyon Tarihi'''
|'''Değişiklik Yapılan Başlık No'''
|'''Yapılan Değişiklik'''
|-
|01
|Ağustos 2021
|
|İlk yayın
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|}

== 1.6. REFERANSLAR ==
1. SSB 2019 – 2023 Stratejik Planı

2. NATO Logistic Handbook, November 2012

3. NATO AAP-48 NATO System Life Cycle Stages and Processes, March 2020

4. NATO ALP-10 NATO Guidance on Integrated Logistics Support for Multinational Armament Programmes,2015

5. NATO Action Sheet C-M(2005)0108-AS1 NATO Policy for Systems Life Cycle Management, 16 January 2006

6. INCOSE Systems Enginering Handbook (INCOSE SE HDBK), 2015

7. Guide to Life Cycles and Life Cycle Models, March 2017, Issue 1.1, Systems Engineering and Project Management Working Group

8. System Development Life-Cycle Methodologies Guide

9. DoD Directive 5000.39 Acquisition and Management of Integrated Logistic Support for Systems and Equipment, 1983.

10. Logistics Engineering and Management, Blanchard BS, 1992

11. Integrated Logistics Support Handbook, Jones JV, 2006

12. DoD Manual 4160.21, Defense Material Disposition, 2015

13. DoD Manual 4160.28, Defense Demilitarization, 2017

14. DoD Manual 5000.04-M-1, Cost and Software Data Reporting, 2011

15. ASPIRE – Supportability Engineering Training Notes

16. DAU Integrated Product Support Element Guidebook, 2011

17. Performansa Dayalı Lojistik Sektör Değerlendirme Raporu, STM, Kasım 2017

18. Standartlar- Spesifikasyon SX000i International Guide for the use of the S-Series Integrated Logistic Support (ILS) specifications, Mart 2020

19. S1000D International Specification for Technical Publications, Issue No. 5.0, 2019

20. S2000M International Specification for Material Management, Issue No. 6.1, 2017

21. S3000L International Specification for Logistics Support Analysis LSA, Issue No. 1.1, 2014

22. S4000P International Specification for Developing and Continuously Improving Preventive Maintenance, Issue No. 2.0, 2018

23. S5000F International Specification for In-service Data Feedback, Issue No. 1.0, 2016

24. NATO Standard AAP-20 NATO Programme Management Framework (NATO Life Cycle Model), Edition C Version 1 October 2015

25. MIL-STD-1369, Integrated Logistic Support Program Requirements, 1971

26. ISO/IEC 15288 Systems and Software Engineering — System Life Cycle Processes, Second edition, 2008.

27. MIL-STD-1388-1A, Logistic Support Analysis, Notice 4, 1993

28. MIL-STD-1388-2B, DOD Requirements for a Logistic Support Analysis Record, 1991

29. MIL-HDBK-502A Product Support Analysis, 2013

30. MIL-PRF-49506 Logistics Management Information, 1996

31. UK-DEF-STAN-00-60 Part 1 Logistics Support Analysis (LSA) and Logistic Support Analysis Record (LSAR), Issue 2, 1998

32. GEIA 0007 Logistics Product Data Handbook, 2007

33. TSSÖDYP Doküman Seti
{| class="wikitable"
|+
! colspan="2" |'''TSSÖDYP DOKÜMAN SETİ'''
|-
|'''DOKÜMAN ADI '''
| '''DOKÜMAN KODU'''
|-
|Sistem Ömür Devri Yönetimi Rehberi (Ana Çerçeve)
|TSSÖDYP-01
|-
|Sistem Ömür Devri Yönetimi Süreçleri Rehberi
|TSSÖDYP-02
|-
|Ürün Destek Stratejileri ve Modelleri Rehberi
|TSSÖDYP-03
|-
|Entegre Lojistik Destek (ELD) Rehberi
|TSSÖDYP-04
|-
|Entegre Lojistik Destek (ELD) İsterleri Hazırlama Rehberi
| TSSÖDYP-05
|-
|Lojistik Destek Analizleri ve Kayıtları Rehberi
|TSSÖDYP-06
|-
|Tedarik Zinciri Yönetimi Rehberi
|TSSÖDYP-07
|-
|Sistem Ömür Devri Yönetiminde Demodelik Yönetimi Rehberi
|TSSÖDYP-08
|-
|Kullanım ve Destek İhtiyaçları Çerçevesinde Yerlileştirme/

Millîleştirme Rehberi
|TSSÖDYP-09
|-
|Kullanım ve Destek Safhaları Kalite Yönetimi Rehberi
|TSSÖDYP-10
|-
|Sistem Ömür Devri Yönetiminde Konfigürasyon Yönetimi Rehberi
|TSSÖDYP-11
|-
|Teknik Yayın Hazırlama Rehberi
|TSSÖDYP-12
|-
|Eğitim ve Eğitim İhtiyaçları Rehberi
|TSSÖDYP-13
|-
|Sistem Ömür Devri Yönetimi Terminolojisi
|TSSÖDYP-14
|-
|Kodlandırma ve Sınıflandırma Bilgi Kitapçığı
|TSSÖDYP-15
|-
|ASD/AIA S-Serisi ELD Spesifikasyonları Seti Tanıtım Kitapçığı
|TSSÖDYP-16
|}

== 1.7. TANIMLAR VE KISALTMALAR ==

=== 1.7.1. TANIMLAR ===
'''Tablo 2 Tanımlar Tablosu'''
{| class="wikitable"
|'''Terim'''
|'''Tanım'''
|'''Diğer Kullanım'''
|-
|Bakım

Maintenance
|Ürün ömür devri boyunca uygulanacak bakım konseptlerini ve gereksinimleri içeren ELD Elemanıdır.
|
|-
|Bilgisayar Kaynakları

Computer Resources
|Görev kritik bilgisayar yazılım/donanım sistemlerinin işletilmesi ve desteği için ihtiyaç duyulan tesis, donanım, yazılım, iletişim, dokümantasyon, iş gücü ve personel ihtiyaçlarını kapsayan ELD Elemanıdır.
|
|-
|Destek ve Test Ekipmanları

Support and Test Equipment
|Ürünün ihtiyaç duyulduğunda kullanıma hazır olmasını sağlamak üzere, kullanımı, desteği ve ikmalini sürdürebilmek için gerekli destek ekipmanlarının (mobil veya sabit) tedarik edilmesine ve desteklenmesine ilişkin yönetsel faaliyetlerin belirlenmesi, planlanması, kaynak tahsisi ve uygulanması faaliyetlerini içeren ELD Elemanıdır.
|
|-
|Eğitim ve Eğitim Desteği

Training and Training Support
|Belirlenen eğitim stratejisinin uygulanması ile eğitim desteği kaynaklarının belirlenerek planlanması, ürünün ömür devri boyunca en uygun performans ve kullanıma hazır bulunuşluk seviyesini sağlayacak şekilde kullanılması, idamesi ve desteklenmesi için ihtiyaç duyulan personelin eğitilmesine ilişkin ELD Elemanıdır.
|
|-
|Ekonomik Ömür

Economic Life
|İhtiyacı karşılayacak yeni sistemlerin tedarik ve idame maliyetinin mevcut sistemlerin idame maliyetine oranla daha ekonomik olduğunun değerlendirilmesine kadar mevcut sistemlerin hizmet içinde kaldığı süredir.
|
|-
|İdame Mühendisliği

Sustaining Engineering
|Kullanımda olan ürünlerin desteklenmesine ilişkin işletim ve idamesi için gerekli olan teknik görevleri (mühendislik ve lojistik incelemeler, analizler vb) kapsayan ELD Elemanıdır.
|
|-
|İkmal Desteği

Supply Support
|Mümkün olan en düşük ömür devri maliyetinde en iyi kabiliyetin kullanıma hazır olmasını sağlayabilmek için gerekli onarım parçaları, yedekleri ve bütün ikmal sınıflarını tedarik etmek için yönetim faaliyetlerinin belirlenmesine, planlanmasına, söz konusu faaliyetlere yönelik kaynağın sağlanmasına ve faaliyetlerin icra edilmesine ilişkin ELD Elemanıdır.
|
|-
|İş gücü ve Personel

Manpower and Personnel
|Ürünün ömür devri boyunca kullanılması ve idame edilmesi için gerekli nitelikte iş gücü ve personelin belirlenmesi, planlanması, kaynağın sağlanması ve istihdam edilmesi faaliyetlerini içeren ELD Elemanıdır.
|
|-
|Lojistik Hacim

Logistics Footprint
|Savunma ve güvenlik kurumlarının harekata/operasyona hazır olmaları ve icra edecekleri harekatı/operasyonu sürdürebilmeleri için ihtiyaç duyulan lojistik destek girdilerinin tamamıdır (örneğin; yakıt, yedek parçalar, destek ekipmanları, ulaştırma, personel vb.).
|Lojistik Ayak İzi
|-
|Paketleme, Elleçleme, Depolama, Ulaştırma

Packaging, Handling, Storage and Transportation
|Malzeme yönetimi; ihtiyaç duyulan malzemeyi, ihtiyaç duyulan yere, ihtiyaç duyulan miktarda, uygun koşullarda, ihtiyaç duyulan sıklıkla, ihtiyaç duyulan şekilde yönlendirerek, ihtiyaç duyulan zamanda uygun yöntem kullanımı ile uygun maliyette sağlayan ELD Elemanıdır.
|
|-
|Tasarıma Etki/

Tasarım Etkileşimi

Design Influence/ Interface
|Geliştirme projelerinin başarılı olması için; halen kullanımda olan benzer sistemlerden yola çıkılarak ELD hedeflerinin, proje başında kullanıcı ile birlikte konması, tüm tasarım aşamasından başlayarak bu hedeflere göre projenin yürütülmesi ve desteklenebilirlik kriterlerinin ölçülebilir metrikler ile tasarıma yansıtılmasının sağlanması çalışmalarını içeren ELD Elemanıdır.
|
|-
|Teknik Veri ve Dokümantasyon

Technical Information and Data
|Kayıt şekli ya da yönteminden bağımsız olarak bilimsel ve teknik içerikli kayıtlı veri ve bilgileri içeren ELD Elemanıdır.
|
|-
|Tesisler ve Altyapı

Facilities and Infrastructure
|Yeni tesis ve altyapının türleri (eğitim tesisi, ekipman/malzeme/tehlikeli madde deposu, bakım tesisleri, bilgisayar donanım/yazılım sistemleri/ağ ve iletişim sistemleri altyapısı vb.) veya mevcut tesis ve altyapılardaki iyileştirmer, lokasyon, alan, çevre ve güvenlik gereksinimleri ve gerekli ekipmanların belirlenmesine yönelik faaliyetlerin tümünü içeren ELD Elemanıdır.
|
|-
|Ürün Destek Yönetimi

Product Support Management
|Bütün ELD elemanlarını kapsayacak şekilde ürün desteğinin planlanması, sağlanması ve finanse edilmesini kapsayan ELD Elemanıdır.
|
|}

=== 1.7.2. KISALTMALAR ===
'''Tablo 3 Kısaltmalar Tablosu'''
{| class="wikitable"
|'''KISALTMA'''
|'''Açık Yazımı'''
|'''Diğer Kullanım'''
|-
|ASD
|Aerospace and Defence Industries Association of Europe
|
|-
|BGA

MTA
|Bakım Görev Analizi

Maintenance Task Analyze
|
|-
|BÖM

WLC
|Bütün Ömür Maliyeti

Whole Life Cost
|
|-
|CİT

BIT
|Cihaz İçi Test-

Built in Test
|
|-
|DKÖT
|Destek, Kalibrasyon, Ölçü ve Test
|
|-
|ELD

ILS
|Entegre Lojistik Destek

Integrated Logistics Support
|
|-
|ELDP

ILSP
|Entegre Lojistik Destek Planı

Integrated Logistics Support Plan
|
|-
|HTEA

FMEA
|Hata Türleri Etkileri Analizi

Failure Modes and Effects Analysis
|
|-
|HTEKA

FMECA
|Hata Türleri Etkileri ve Kritiklik Analizi

Failure Modes, Effects and Criticality Analysis
|
|-
|LDA

LSA
|Lojistik Destek Analizi

Logistic Support Analysis
|
|-
|LDAK

LSAR
|Lojistik Destek Analizi Kayıtları

Logistic Support Analysis Records
|
|-
|NATO
|North Atlantic Treaty Organization
|
|-
|OSA

LORA
|Onarım Seviyesi Analizi

Level of Repair Analysis
|
|-
|ÖDM

LCC
|Ömür Devri Maliyeti

Life Cycle Cost
|
|-
|PDL

PBL
|Performansa Dayalı Lojistik

Performance Based Logistic
|
|-
|ÖBGG

PMTR
|Önleyici Bakım Görev Gereksinimleri

Preventive Maintenance Task Requirements
|
|-
|PTD
|Proje Tanımlama Dokümanı
|
|-
|RAHAT

COTS
|Rafta Hazır Ticari Ürün

Commercially off the Shelf Item
|Raf Ürünü
|-
|RAMST
|Güvenilirlik-Kullanıma Hazır Olma-İdame Edilebilirlik-Desteklenebilirlik-Test Edilebilirlik

Reliability-Availability-Maintainability-Supportability-Testability
|
|-
|TÇD

RFP
|Teklife Çağrı Dosyası

Request for Proposal
|
|-
|TSSÖDYP
|Türk Savunma Sanayii Ömür Devri Yönetimi Platformu
|
|-
|TSOM

TOC
|Toplam Sahip Olma Maliyeti

Total Ownership Cost
|
|}

== 1.8. TABLOLAR VE ŞEKİLLER ==

=== 1.8.1. TABLOLAR ===
Tablo 1: Değişiklik izleme Tablosu

Tablo 2 Tanımlar Tablosu

Tablo 3 Kısaltmalar Tablosu

Tablo 4 Desteklenebilirlik –Sistem

Tablo 5 ÖDM Bileşenleri

Tablo 6 ELD Faaliyetleri Kapsamında Hazırlanacak ve Güncelenecek Dokümanlar

=== 1.8.2. ŞEKİLLER ===
Şekil 1 Sivil Lojistik Mimarisi

Şekil 2 Sistem; Odak Sistem ve Destek Unsurları

Şekil 3 Bütçelenebilir Operasyonel Etkinlik

Şekil 4 Sistem Ömür Devri Safhaları

Şekil 5 Sistem Ömür Devri Yönetimi Süreçleri

Şekil 6 ÖDM, TSOM ve BÖM arasındaki ilişki

Şekil 7 ELD Elemanları ile Optimum Lojistik Destek İlişkisi

Şekil 8 Bakım Faaliyetleri

Şekil 9 Savunma ve Güvenlik Sistemi İçin Başarı Kriterleri

Şekil 10 Temel LDA Süreci

= 2. TEMEL KAVRAMLAR =

== 2.1. LOJİSTİK ==
Lojistik,‘’logisticos’’ kelimesinden türemiş olup, “hesap yapma bilimi” ya da ‘’hesapta becerikli” anlamına gelmektedir. Bir başka görüşe göre de Lojistik, Logic (mantık) ve Statistics (istatistik) kelimelerinin birleşmesinden meydana gelmiştir.

Blanchard’a göre lojistik; destek elemanlarının satın alınması, ikmali, malzemelerin taşınması ve dağıtımı (taşıma, ulaştırma ve ürünlerin depolanması), bakımı, kullanımı ve planlanan ömür süreleri boyunca yapılacak tüm destek faaliyetlerini içerir.

Yazılı kaynaklar, geçmişten günümüze askerî alanda güç unsurlarını hareket ettirme yeteneğinin savaşların kazananı ve kaybedenini belirlemede ne derece önemli olduğunu göstermektedir. Büyük İskender’in kısa süre içinde büyük topraklar fethetmesini sağlayan stratejinin temelinde başarılı lojistik planlamaları yatar. Doğru planlama, iyi hazırlık ve doğru tercihler ile yönetilen lojistik, Büyük İskender’in çağdaşlarına göre çok daha esnek ve süratli bir orduya sahip olmasını sağlamıştır. Benzer şekilde, süratli ve esnek bir askerî güç ve lojistik yeteneğine sahip güçlü bir kuvvet yapısına sahip olması Osmanlı İmparatorluğu’nun üç kıtaya hükmeder hale gelmesindeki en önemli unsurlardan biridir.

Milli güvenliğin temel unsurlarından biri olan askerî gücün edinilmesinde savunma sistemlerindeki sayısal üstünlüğün yeterli olmadığı bilinmektedir. Askerî gücün kazanımında eğitim, disiplin, moral-motivasyon, yönetim ve özellikle teknolojik yeterlilik ile elde edilen nitelik üstünlüğüne ihtiyaç vardır.

Sahip olunan sistemlerin beklenen fonksiyonlarını kabul edilebilir performans seviyesinde en az maliyetle ve kullanım ömrü boyunca sağlayabilmesi temel hedeftir. Bu hedef; sisteme sahip olan, tedarikinde, kullanımında ve desteğinde görev alan veya ödenen bedelde payı olan tüm paydaşlar için ortaktır.

Yüksek rekabet ortamında mevcut veya olası tehditlerin çeşitliliği, değişim hızı ve yeteneği; yüksek caydırıcılık gücüne sahip, ileri teknoloji ürünü, dolayısı ile karmaşık yapıda savunma sistemlerine sahip olmayı gerektirir. Bu tür sistemlerin öngörülen ömürleri boyunca harekât ihtiyacını karşılayabilecek şekilde göreve hazır bulundurulması; teknik, idari ve bütçesel birçok problemin üstesinden eşzamanlı olarak gelinmesi ile mümkündür. Başka bir deyişle, herbiri kendi içinde uzmanlık isteyen birçok disiplinin, birbiri ile uyum içinde ortak bir hedefe doğru yönlendirilmesi gerekir. Zira sahip olunan savunma sistemlerinin hazır bulunuşluğu silahlanma programlarının başlıca gereksinimlerinden biridir. Hazır bulunuşluk ise ihtiyaç duyulan lojistik desteğin ihtiyaç duyulan yer ve zamanda varlığına bağlıdır.

Savunma ve güvenlik sisteminin kullanıma alınmasından itibaren ihtiyaç duyulduğu anda göreve hazır olabilmesi için ilgili destek unsurlarının odak sistemle eşzamanlı olarak geliştirilmesi, tedariki ve hazırlanması gerekir. Bu hedefe maliyet etkin şekilde ulaşılabilmesi kullanıcıların, tasarımcıların ve lojistik destek ekiplerinin ihtiyacın belirlenmesi aşamasından itibaren birlikte çalışmasına bağlıdır.

Dünyadaki mevcut askerî lojistik sisteminin gelecekteki savaşlarda operasyonların hızına yetişebilmek için yetersiz kalacağına ve yeni bir bakış açısına ihtiyaç olduğuna dair işaretler mevcuttur. Hâlihazırda sivil ticaret şirketlerinin yurt içinde veya dünya çapında uygulayabildikleri ürün dağıtım teknikleri ve eriştikleri sürat bu işaretlerden birisidir.

İnsansız sistemler ve dronların gelecekteki savaşlarda daha fazla rol alacağı şimdiden bellidir. Gelecekte harekât alanının genişlemesiyle; yüksek hızlı, çok boyutlu, eşzamanlı harekât ve şartların değişimine anlık cevap verebilme yeteneklerine ihtiyaç duyulacaktır. Bu ihtiyaç, bilgi teknolojilerinin artan oranda kullanımı ile karşılanabilir.

Ortak kaynak veri tabanları, güvenli iletişim ağları, artırılmış gerçeklik, sanal gerçeklik, karma gerçeklik, uzaktan bakım, yapay zekâ, 3 boyutlu yazıcılar vb. uygulamaların yaygınlaşacağı öngörülmektedir. Bu sebeple, programlar/projeler ömür devri yönetimi yaklaşımı ile kurgulanırken bilgi teknolojilerinin kullanımı konusuna da özel bir önem verilmesi gerekmektedir.

== 2.2. MİLLÎ GÜVENLİK VE LOJİSTİK İLİŞKİSİ ==
Milli güvenlik; siyasi, askerî, ekonomik, beşeri, coğrafi, bilimsel, teknolojik, psiko-sosyal ve kültürel millî güç unsurlarından meydana gelir. Lojistik kavramına en üst seviyeden bakıldığında Stratejik Lojistik ve Uygulamalı Lojistik olarak iki temel alanın mevcut olduğu görülebilir.

=== 2.2.1. STRATEJİK LOJİSTİK ===
Askerî güç ve ekonomik güç milli güvenlikle birlikte ele alındığında stratejik lojistik alanını oluşturur. Ülkenin mevcut havalimanları, demir yolları, kara yolları, fabrikalar, tersaneler, tesisler, depolar, yetişmiş iş gücü, bilimsel ve teknik çalışmalar/kurumlar, mali sistem, iletişim sistemleri, savunma ve güvenlik kurumları gibi alt yapılar ve bunların akılcı yönetimi stratejik seviyedeki lojistik unsurları oluşturur.

=== 2.2.2. UYGULAMALI LOJİSTİK ===
Uygulamalı lojistik, savunma ve güvenlik alanında ihtiyaç duyulan sistemlerin/platformların tedariği, kullanımı ve idamesine ilişkin lojistik fonksiyonlardır. Uygulamalı lojistik, Tedarik Lojistiği ve İşletim Lojistiği olmak üzere iki ana bölüme ayrılır.

=== 2.2.2.1. TEDARİK LOJİSTİĞİ ===
Tedarik lojistiği; ihtiyaç duyulan sistemin araştırılması, tasarlanması, geliştirilmesi, üretilmesi, envantere alınması ile kullanım ve destek unsurlarının temin ve tedarik edilmesine ait faaliyetleri içerir.

Tedarik lojistiği faaliyetleri, sistem mühendisliği sürecinin bir parçasıdır. Alternatif çözümler içinde desteklenebilirliği en yüksek olan çözüme ulaşılmaya çalışılır. Bu kapsamda, her bir alternatif çözüm ile ilgili olarak;

* Lojistik kısıtlar ile destek gereksinimlerinin belirlenmesi (harekât ihtiyaçları),
* İstenilen performans seviyesinde, desteklenebilirliği ve sürdürülebilirliği yüksek, maliyet etkin sistem çözümlerinin öne çıkarılması,
* Ürün tasarımının belirlenen lojistik destek gereksinimlerini tam ve doğru olarak sağlaması,
* Planlanan destek çözümünün işlerliğinin doğrulanması,
* Destek için gerekli malzeme ve ekipmanların tedarik edilmesi ya da üretilmesi, görev yerlerine ikmali ve kurulumu,
* Yapılması gerekli modifikasyon ve değişikliklerin uygulanması

faaliyetleri yürütülür.

=== 2.2.2.2. İŞLETİM LOJİSTİĞİ ===
İşletim lojistiği; Sistem ömür devrinin Kullanım, Destek ve Envanterden Çıkarma safhalarındaki destek ihtiyaçlarının belirlenmesi, sistem, destek ve ikmal malzemelerinin depolanması, dağıtımı, ulaştırılması, bakımı, kullanıma hazır bulundurulması ve envanterden çıkarılması faaliyetlerinin planlanması, yürütülmesi, gözden geçirilmesi ve iyileştirilmesidir. İşletim lojistiği; bakım/onarım, malzeme ikmali, taşıma, ulaştırma, tesis, iş gücü, eğitim vb. hususları kapsar.

== 2.3. ASKERÎ LOJİSTİK ==
Askeri Lojistik, mevcut ve öngörülen kuvvet yapısının; sistemler, altyapı ve hizmetlerin ömür devri çerçevesinde, savaşta, barışta, gerginlik/kriz döneminde, yetki ve sorumluluklara uygun yönetimini kapsayan faaliyetler bütünüdür.

== 2.4. SİVİL LOJİSTİK ==
Sivil lojistik; sistem, müşteri servisi, talep tahmini, ulaştırması, dağıtımı, ürün kontrolü, parça ve servis desteği, satın alma, paketleme, geri dönüşüm, değişim, taşıma ve depolama faaliyetlerinin tümünü kapsamaktadır.
[[Dosya:Şekil1 Sivil Lojistik Mimari.jpg|alt=Şekil 1 Sivil Lojistik Mimarisi|sol|küçükresim|500x500pik|Şekil 1 Sivil Lojistik Mimarisi]]

== 2.5. SİSTEM ==
'''Sistem;''' ömür devrinin ilk safhasından itibaren Odak Sistem ve Destek Unsurlarının ayrılmaz bir bütün halinde ele alındığı ve yönetildiği bileşenler topluluğudur.

'''Odak Sistem;''' herhangi bir portföy/program/proje çerçevesinde, yeni bir temel yetenek kazandıran ya da mevcut bir temel yeteneğin kapsamlı modernizasyonuna yönelik olan, tedariki, kullanımı ve desteği yüksek maliyetli ve/veya gerçekleştirilmesi nispeten uzun zaman alacak olan savunma ve güvenlik sistemleridir.

Odak Sistemin temel görevi, savunma ve güvenlik ihtiyacını belirlenen kullanım konsepti ve görev profilleri çerçevesinde istenilen performans seviyesinde karşılamaktır. Odak Sistem, sistemler sistemi olarak tanımlanabilecek bir yapı olabileceği gibi sadece alt sistemlerden ve sistem elemanlarından oluşan bir yapı da olabilir. Bu çerçevede, Odak Sistem – yukarıdaki tanıma uygun olacak şekilde - savunma sistemi/platformu, ana silah sistemi, ana sistem, ana malzeme, ürün, cihaz ve benzerlerini ifade etmektedir.

'''Destek Unsurları;''' Odak Sistemin belirlenen kullanım konsepti ve görev profilleri çerçevesinde istenilen performans seviyesinde görev yapabilmesi ve maliyet etkin olarak kullanımında sürekliliğin sağlanması için ihtiyaç duyulan unsurlardır. Destek Unsurları, bunlarla sınırlı olmamak üzere Şekil 2’deki hususları kapsar.
[[Dosya:Sistem Odak Sistem.png|alt=Şekil 2 Sistem; Odak Sistem ve Destek Unsurları|sol|küçükresim|600x600pik|Şekil 2 Sistem; Odak Sistem ve Destek Unsurları]]

Sistem tasarımında teknik, taktik, lojistik ve mali hususlar bir bütün halinde ele alınarak sistemin ömür devri boyunca Şekil 3’te gösterildiği şekilde bütçelenebilir operasyonel etkinliğe sahip olması hedeflenmektedir.
[[Dosya:Şekil3 Bütçelenebilir Operasyonel Etkinlik.jpg|alt=Şekil 3 Bütçelenebilir Operasyonel Etkinlik|sol|küçükresim|600x600pik|Şekil 3 Bütçelenebilir Operasyonel Etkinlik]]

== 2.6. DESTEKLENEBİLİRLİK ==
Desteklenebilirlik; Operasyonel konseptler çerçevesinde, “Odak Sistem” ve “Destek Unsurları”nın bir bütünü olan “Sistem” tasarımının, destek faaliyetlerini yürütme ve göreve hazır olma/bulunma gereksinimlerini, planlanan ömür devri boyunca, barış ve savaş şartlarında, kabul edilebilir maliyetler dahilinde karşılayabilme kabiliyetidir.

Desteklenebilir ürün geliştirmede kullanılacak başlıca tasarım parametreleri; güvenilirlik, kullanıma hazır olma, idame edilebilirlik, sürdürülebilirlik, test edilebilirlik ve emniyettir.

Sistemi oluşturan her bir unsurun karakteristiğinin, yukarıda bahsedilen parametreler üzerinde değişen oranlarda etkisi mevcuttur. Öte yandan tüm unsurlar birbirleri ile de etkileşim halindedirler. Lojistik destek kapsamında yapılan analizlerde, her bir unsurun desteklenebilirlik ölçütleri üzerindeki etkisi ve duyarlılık derecesi (degree of precision) ile sistemi oluşturan diğer unsurlar ile etkileşim derecesi incelenir.

Sistemden beklenen fonksiyonel çıktı ve performans değerlerine ulaşabilmeyi sağlayan, sistemi oluşturan unsurların teorik olarak sınırsız sayıda kombinasyonundan bahsedilebilir. Bu da, alternatiflerin maliyet ekseninde karşılaştırılmasını gerekli kılar.

Sistemi oluşturan birçok unsurun zamanla değişkenlik arzeden karakteristiğe sahip olması (özellikle İnsan/Destek Sistemi karakteristiği), desteklenebilirlik hedeflerinin ürün ömür devri boyunca takibini gerektirir.

Odak sistemlerin lojistik desteğini doğrudan etkileyen ana unsurlar, sistem bileşenlerine ayrılarak Tablo 4 içeriğinde verilmiştir.

'''Tablo 4 Desteklenebilirlik –Sistem'''
{| class="wikitable"
| colspan="3" |

'''SİSTEM'''

''a. Desteklenebilirlik''
|-
|'''Odak Sistem'''
|'''Destek Sistemi'''
|'''İşletimsel Sistem'''
|-
|· ''Güvenilirlik''

· ''İdame Edilebilirlik''

· ''Test Edilebilirlik''

· ''Lojistik Desteklenebilirlik''

''İyileştirilebilir tasarım, Desteklenebilir sistem mimarisi, Standardizasyon, ''

''Entegre bakım desteği (CİT vb.), Emniyet,''

''Kullanım kolaylığı,''

''Düşük riskli destek unsurları,''

''İzleme kolaylığı,''

''Elden çıkartılabilme kolaylığı,''

''…''
|· ''Lojistik Desteklenebilirlik''

''Fiziksel ve Organizasyonel Yapılanma''

'' Basit,''

'' Ekonomik,''

'' Erişilebilir,''

'' Esnek,''

'' Sürdürülebilir,''

'' İhtiyacı Karşılayabilen''

''Tanımlı Süreçler ve Prosedürler''

''Kaynaklar''

'' Personel-iş gücü,''

'' Yedek parça, sarf malzemeleri,''

'' Test donanımı, avadanlıklar,''

'' Destek ekipmanları,''

'' Teknik veri,''

'' Tesis,''

'' Ulaşım''

'' …''
|· ''Kullanım Konsepti''

· ''Görev Profilleri''

· ''Bakım Konsepti''
|}
Desteklenebilirlik ilişkili ürün performans parametreleri [https://tssodypwiki.ssb.gov.tr/index.php/Entegre_Lojistik_Destek_(ELD)_%C4%B0sterleri_Haz%C4%B1rlama_Rehberi TSSÖDYP-05 ELD İsterleri Hazırlama Rehberi] EK-A Parametre Listesinde verilmekte, bahse konu parametrelere ilişkin detaylı bilgi [https://tssodypwiki.ssb.gov.tr/index.php/Lojistik_Destek_Analizleri_ve_Kay%C4%B1tlar%C4%B1_Rehberi TSSÖDYP-06 Lojistik Destek Analizleri ve Kayıtları Rehberinde] yer almaktadır.

== 2.7. SÜRDÜRÜLEBİLİRLİK ==
Karmaşık savunma ve güvenlik sistemlerinin ömrü 30-40 yıl veya daha uzun süreli planlanabilir. Sistemden beklenen fonksiyonları bu uzun zaman periyodunda yerine getirebilmesi, sistemin başlangıçtaki performansı ile kullanılabilmesi ve faaliyetini planlanan süre ve seviyede devam ettirebilmesi ile ÖDM’nin düşürülmesi sistemin tasarım sürecinde dikkate alınmalıdır.

Sistemin idamesine ilişkin kullanım ve destek safhalarındaki faaliyetlerin etkin şekilde planlanması ve yürütülmesi sürdürülebilirliğin sağlanmasındaki en önemli faktördür.

== 2.8. SİSTEM ÖMÜR DEVRİ YÖNETİMİ ==
Sistem ömür devri yönetimi konusunda bilgi almak üzere; [https://tssodypwiki.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)] ve [https://tssodypwiki.ssb.gov.tr/index.php/Sistem_%C3%96m%C3%BCr_Devri_Y%C3%B6netimi_S%C3%BCre%C3%A7leri_Rehberi TSSÖDYP-02 Sistem Ömür Devri Yönetimi Süreçleri Rehberinden] faydalanılabilir.

=== 2.8.1. SİSTEM ÖMÜR DEVRİ SAFHALARI ===
Sistem ömür devri yönetiminde, benzer amaçlar ve performans ölçütleri doğrultusunda çeşitli modeller söz konusudur. Karmaşık sistemlerin tedarikinde, kullanımında ve envanterden çıkarılmasında karşılaşılabilecek riskleri azaltmak ve etkili bir risk yönetimi sağlayabilmek amacıyla, organizasyonlar tarafından ömür devri modellerinin çeşitli versiyonları üretilmiştir. Sistem ömür devri modelleri çeşitli standart ve rehber dokümanlar ile desteklenmektedir.

[https://tssodypwiki.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)’]de Sistem Ömür Devri; Ön Konsept, Konsept, Geliştirme, Üretim, Kullanım, Destek ve Envanterden Çıkarma olmak üzere Şekil 4’te gösterildiği üzere 7 safhadan oluşmaktadır.
[[Dosya:Şekil4 Sistem Ömür Devri Safhaları.jpg|alt=Şekil 4 Sistem Ömür Devri Safhaları|sol|küçükresim|600x600pik|Şekil 4 Sistem Ömür Devri Safhaları ]]

=== 2.8.2. SİSTEM ÖMÜR DEVRİ YÖNETİMİ SÜREÇLERİ ===
Sistem ömür devri yönetiminin temel amacı; performans, maliyet etkinlik, takvim, kalite, operasyonel çevre, ELD ve demodelik gibi faktörleri göz önünde bulundurarak ömür devri boyunca sistem kabiliyetlerinin optimizasyonudur. Sistem ömür devri yönetimi modelinin başarılı bir şekilde işletilmesi ve yönetilmesi için gerekli süreçler [https://tssodypwiki.ssb.gov.tr/index.php/Sistem_%C3%96m%C3%BCr_Devri_Y%C3%B6netimi_S%C3%BCre%C3%A7leri_Rehberi TSSÖDYP-02 Sistem Ömür Devri Yönetimi Süreçleri Rehberi’nde] tanımlanmaktadır. Sistem ömür devri süreçleri; Mutabakat Süreçleri, Organizasyonel Program/Proje Destek Süreçleri, Program/Proje Süreçleri ve Teknik Süreçler olmak üzere Şekil 5’te verildiği üzere 4 ana kategoride toplanmıştır.
[[Dosya:Şekil5 Sistem Ömür Devri Yönetimi Süreçler.jpg|alt=Şekil 5 Sistem Ömür Devri Yönetimi Süreçleri|sol|küçükresim|881x881pik|Şekil 5 Sistem Ömür Devri Yönetimi Süreçleri]]

=== 2.8.3. SİSTEM ÖMÜR DEVRİ YÖNETİMİNDE PAYDAŞLAR, ROLLER VE SORUMLULUKLAR ===
Sistem ömür devri boyunca; ilgili paydaşların ihtiyaçlarının, beklentilerinin ve sorumluluklarının belirlenmesi, sorunsuz programlar/projeler yürütebilmenin ilk ve en önemli koşullarındandır.

Bir program/proje kapsamında ihtiyaç makamları, kullanıcılar, tedarik makamları, idame makamları, ana yükleniciler, alt yükleniciler, tedarikçiler, orjinal ekipman üreticileri ve diğer katkı sağlayabilecek organizasyonlar paydaş olarak nitelendirilebilir. Paydaşların sürece katılımı sistem ömür devrinin farklı noktalarında gerçekleşebilir.

Sistem ömür devri yönetimi kurgusunda, belirli bir düzen dahilinde ihtiyaçların netleştirilmesi amacıyla ilgili paydaşlar ön çalışmalarını yaparlar. Daha sonra bu ihtiyaçlar paydaş isterlerine dönüştürülür ve çeşitli formlarda kayıt altına alınır. Açık ve net olmayan ifadelerin anlaşılır ve ölçülebilir isterlere dönüştürülebilmesi için paydaşlar arasında ortak çalışma yapılır. Bu aşamada başvurulacak paydaş ihtiyaçları ve ister tanımlama sürecinde; operasyonel konsept dokümanı, stratejik işletme/kullanım planları vb. kaynaklardan faydalanılabilecektir.

Paydaş ihtiyaçları; geliştirme safhasına ait gereksinim tanımlama, tasarım, test ve doğrulama, entegrasyon gibi önemli aktivitelerin temelini oluşturacağı için ömür devri yönetimi kurgusunda sistem mühendisliği açısından önemli bir rol üstlenir. Paydaşlar arasında sağlanacak iletişimin yapı taşı paydaş isterleri olacaktır.

Sistem ömür devri safhalarına yönelik olarak her safhada ilgisi olabilecek paydaşlar tanımlanmalıdır. Paydaş isterleri; fonksiyonel, operasyonel, ara yüz, çevre, insan faktörleri, lojistik, bakım, tasarım, üretim, doğrulama, teslimat, eğitim, sertifikasyon, elden çıkarma, desteklenebilirlik, kalite, emniyet, özel mühendislik ve güvenlik gibi çeşitli kategorilerde sınıflandırılabilir ve ilgili faaliyetler için sorumluluklar tanımlanır.

=== 2.8.4. FİZİKÎ ÖMÜR, TEKNOLOJİK ÖMÜR, PLANLANAN KULLANIM ÖMRÜ ===
Bir sistemin ya da ürünün sistem ömür devri konsepti ifade edilirken, “ömür” kavramı üzerinde ilgili paydaşlar ile fikir birliği sağlanması, ihtiyacı net olarak anlama ve verimli bir planlama açısından faydalı olacaktır. Bu kapsamda fizikî ömür, teknolojik ömür ve planlanan kullanım ömrü ifadeleri aşağıda açıklanmıştır.

Sistem ömür devri kurgusu içinde kullanımına başlanan bir ürünün fiziksel ömrünün, teknolojik ömrünün ve planlanan kullanım ömrünün aynı anda başladığı ifade edilebilir. Ancak, sistemin tedariki süresince geçen zaman teknolojik ömür açısından önemli bir risk içerebilir. Bu sebeple, ihtiyaçların sadece mevcut teknoloji çerçevesinde değil ileriye dönük teknolojik öngörüleri de kapsayacak şekilde karşılanması gerekir.

Sistemin ilk kurulumu ile birlikte üretim ve kalite hatalarının sıklıkla ortaya çıkabileceği bir dönem yaşanması olasıdır. Bu dönemde ürünün fizikî ve teknolojik ömrünün devam ettiğini, planlanan kullanım ömrü içinde olduğunu ancak henüz faydalı ömrüne erişmediğini ifade edebiliriz. Hatalı planlama ya da uzun ürün geliştirme süreçleri vb. nedenler dolayısıyla çok erken dönemlerde yeni teknoloji bir ürünle karşılaşılması gibi durumlar söz konusu olabilecektir. Bu dönem sonrası nispeten arıza sıklığının azaldığı ve sistemin daha etkin kullanılabildiği “faydalı ömür” dönemi başlayacaktır. Son olarak faydalı ömür sonrası tekrar arıza sıklıkları artacak ve sistem yavaş yavaş planlanan kullanım ömrünün sonuna gelecektir. Bu durumda genellikle planlanan kullanım ömrünün devam etmemesi tercih edilebilecektir. Özellikle görev kritik sistemler söz konusu olduğunda yeni teknolojiye ve arıza sıklığına hassasiyet daha fazla ağırlığa sahip karar değişkeni olacaktır.

Yukarıda yer alan değerlendirmeler ışığında; fiziksel ömür kavramı, diğer kavramlara nazaran daha net bir şekilde ifade edilebilir. Bir sistemin kendisinden beklenen fonksiyonları yerine getirmek suretiyle fiziksel özellikleri el verdiği sürece görevini yapabilmesi, sistemin fiziksel ömrü olarak nitelendirilebilir. Ancak teknolojik ömür ve planlanan kullanım ömrü; çevresel, ekonomik, coğrafik, teknolojik vb. faktörlerden daha fazla etkilenmektedir. Teknolojik ömür; kabiliyet ihtiyacını karşılayan bilgi ve becerinin yeni bir düşünce, gelişme vb. ile karşılanabilmesine kadar geçen süre olarak nitelendirilebilir. Bu süreyi erken aşamalarda bir sistem için öngörmek, dünya ile sürekli irtibat halinde olmak ve yenilikleri takip etmekten geçecektir. Son olarak; planlanan kullanım ömrünün, sistem ömür devrinin ön konsept ve konsept safhalarında ihtiyacı karşılamaya yönelik karşılıklı fikir alışverişleri neticesinde geliştirilen sistemlerin tasarlanan hizmet süreleri olduğunu ifade edebiliriz.

== 2.9. ÖMÜR DEVRİ MALİYETİ (ÖDM) ==
ÖDM, sistemin tedarik döneminde ödenen maliyet ile kullanım, destek ve envanterden çıkarma boyunca ödenen maliyetlerin toplamıdır. ÖDM’nin başlıca bileşenleri, araştırma-geliştirme, yatırım, üretim, kullanım, destek ve envanterden çıkarma maliyetleridir. Karmaşık savunma sistemlerinde kullanım, destek ve envanterden çıkarma maliyetleri toplamının diğer bileşenlerin toplamından daha yüksek olduğu bilinmektedir.

Uzun vadede sisteme sahip olma maliyetinin en düşük seviyede tutulması, yüklenici açısından ekonomik rekabetin bir boyutudur. ÖDM, kısa vadeli maliyet düşürme faaliyetleri yerine ileri görüşlülükle uzun vadede maliyeti etkileyen unsurların tespit edilmesini ve maliyet etkin alternatif çözümlerin ortaya konulabilmesi için yaratıcı fikirler üretebilen mühendislik faaliyetlerini gerekli kılar. Başka bir deyişle, projelerin zaman ve bütçe kısıtları dışında uzun vadede sahip olma maliyeti açısından değerlendirilmesini sağlar.

Başarılı bir ÖDM analizinin en önemli kaynağı, kullanımda olan sistemlerden toplanan verilerdir. Gerçekleşen maliyet, ürünün kullanım süresiyle orantılı olarak değişkenlik gösterir. ÖDM analizi süreklilik arzetmeli ve sonuçları canlı tutulmalıdır. Güncel sonuçlar; sahip olma maliyetinin yanı sıra sistemin kalan ömrü boyunca beklenen maliyetinin tahmini, kullanım ve bakım bütçelerinin belirlenmesi, yeni sistemlerin geliştirilmesi sürecinde oluşan gecikmelerin maliyet analizi ve karar destek mekanizmalarında kullanılır.

Finansal açıdan değerlendirme, maliyetin ilgili finans kaynakları ile ilişkilendirilmesi sonucunda Bütçelenebilirlik (Affordability) değerlendirmesinin yapılabilmesini mümkün kılar. Bu sebeple ÖDM hem yönetim hem de mühendislik tarafında, maliyet/bütçe kontrolü ve karar verme mekanizmalarında yol gösterici etkiye sahiptir.

Sistemin elde edilmesi sürecinde, işletme-idame ve elden çıkarma maliyetlerinin azaltılmasına yönelik sorumluluğun yüklenici firmalar tarafından da üstlenilmesi doğal olarak müşterinin/kullanıcının başlıca beklentisidir. Bu beklentinin karşılanmasına yönelik olarak sistem bazında farklı tedarik sözleşme teknikleri uygulanabilir ya da tedarik sözleşmesi içeriğinde teşvik edici ya da yönlendirici isterler tanımlanabilir.

ÖDM analizi, ÖDM’ni oluşturan her bir bileşenin birbirleri ile etkileşiminin tanımlanması, ÖDM değerinin hesaplanması ve niteliğinin belirlenmesine yönelik bir analizdir. ÖDM analizi çıktısı “tahmin” olup hassasiyeti analizde kullanılan girdilerin çeşit ve niteliğine bağlıdır. Sisteme ait ÖDM’nin tahmin edilmesinde 3 ana yaklaşımdan bahsedilebilir:

* Finansal yaklaşım: Projenin belli başlı maliyet unsurlarına (Ar-Ge, satın alma, kullanım ve destek, tesis, personel vb.) ilişkin finansal kısıtlar ve yaklaşımlar ile ek bütçe talepleri ile sisteme ait ÖDM belirlenebilir.
* İş Kırılım Ağacı yaklaşımı: Geliştirilecek ve tesis edilecek sistem unsurlarını tümüyle ve detayları ile ortaya koyabilen iş kırılım ağacının her bir bileşenine ilişkin maliyetlendirmeler ile ÖDM belirlenebilir.
* Ömür Devri Maliyet Kategorileri yaklaşımı: Maliyet kategorileri (DoD 5000.4-M, Cost Analysis Guidance and Procedures):
** Araştırma-Geliştirme
** Yatırım (Üretim)
** Kullanım-Destek
** Envanterden Çıkarma

Maliyetin analiz edilmesi ile ilgili farklı ülkeler ve/veya kullanıcılar; değişik yöntemler, araçlar ve terminolojiler kullanabilir. Kullanılan ve Şekil 6’da birbirleri ile ilişkileri bulunan başlıca konseptler aşağıda yer almaktadır:

1. Ömür Devri Maliyeti (ÖDM) (LCC -Life Cycle Cost)

(ÖDM = Direkt Maliyetler + Endirekt Değişken Maliyetler)

2. Toplam Sahip Olma Maliyeti (TOC-Total Ownership Cost)

(TSOM = ÖDM + Bağlı endirekt Sabit Maliyetler)

3. Bütün Ömür Maliyeti (WLC-Whole Life Cost)

(BÖM = TSOM + Bağlı Olmayan Endirekt Sabit Maliyetler)
[[Dosya:Şekil6 ÖDM, TSOM ve BÖM arasındaki ilişki.jpg|alt=Şekil 6 ÖDM, TSOM ve BÖM arasındaki ilişki|sol|küçükresim|500x500pik|Şekil 6 ÖDM, TSOM ve BÖM arasındaki ilişki]]

ÖDM, ürünün elde edilmesi, kullanım, destek ve envanterden çıkarma ile ilişkili tüm direkt maliyetler ile indirekt-değişken maliyetleri içerir. Direkt maliyette sadece ortaya konulan ürüne yönelik faaliyetler ya da kaynaklar söz konusudur. Birden fazla değişik ürün ile ilişkilendirilebilecek maliyet, ürünler arasında ölçülebilir şekilde paylaştırılıyor ise bu da direkt maliyet olarak kaydedilir. Aksi halde indirekt olarak nitelendirilir. Değişken maliyetler, ürünün karmaşıklığı, parça/bileşen sayısı ve kırılım seviyesine bağlı olarak değişkenlik gösteren maliyetlerdir. Bunun haricindeki indirekt maliyetler ÖDM analizi kapsamına girmez.

BÖM, TSOM ve Bağlı Olmayan Endirekt Sabit Maliyetleri kapsar.

TSOM, ÖDM ve Bağlı İndirekt Sabit Maliyetleri içerir. Sabit maliyetler üründen çok organizasyon ile ilişkili maliyetlerdir ve ürünün varlığından etkilenmezler. Ürünün satın alınması, kullanım, destek ve envanterden çıkarma ile ilişkilendirilebilen kaynak ve faaliyetler bağlı olarak nitelendirilir. Bağlı olmayan indirekt sabit maliyetler; ürünün satın alınması, kullanımı, desteği ve envanterden çıkarılması ile ilişkilendirilemeyen faaliyetler sonucunda ortaya çıkan maliyetlerdir.

Projenin her aşamasında aynı detayda ve doğrulukta ÖDM analizi yürütülemez. İş geliştirme safhasında, stratejik yaklaşımları yönlendirebilecek detayda maliyet analizleri yapılabilir. Projenin erken aşamalarında, müşteri gereksinimlerinin karşılanmasına yönelik alternatif çözümlerin ekonomik ve finansal değerlendirilmesinde kullanılacak ÖDM, öngörülen sistem karakteristiklerine dayanarak geliştirilir. Çözüm alternatifinin seçilmesini takiben, Tablo 5’te örneği sunulan, çözüme ait ÖDM bileşenleri tablosu detaylandırılarak sistem karakteristiklerine dayanarak doldurulur. Faaliyetler, Tabloda belirtilenlerle sınırlı değildir.

'''Tablo 5 ÖDM Bileşenleri'''
{| class="wikitable"
| rowspan="3" |'''FAALİYETLER'''
| colspan="3" |'''MALİYETLER'''
|-
| colspan="2" | '''SİSTEM'''

''Kullanım/Bakım Konsepti''
|'''PROJE'''
|-
|'''Odak Sistem'''
|'''Destek Sistemi'''
|'''Özel'''
|-
|''Proje Yönetim''
|
|
|
|-
|''Bilgi''
|
|
|
|-
|''Analiz''
|
|
|
|-
|''Simülasyon''
|
|
|
|-
|''Mühendislik''
|
|
|
|-
|''Satın alma''
|
|
|
|-
|''Üretim''
|
|
|
|-
|''Entegrasyon''
|
|
|
|-
|''Test, Deneme, İşlevsel Gösterim''
|
|
|
|-
|''Paketleme''
|
|
|
|-
|''Elleçleme''
|
|
|
|-
|''Depolama''
|
|
|
|-
|''Nakliye (Ulaştırma)''
|
|
|
|-
|''Montaj''
|
|
|
|-
|''Eğitim''
|
|
|
|-
|''Kullanıcı Dokümanları''
|
|
|
|-
|''Kullanım''
|
|
|
|-
|''Bakım''
|
|
|
|-
|''İkmal''
|
|
|
|-
|''Envanterden Çıkarma''
|
|
|
|}

= 3. ENTEGRE LOJİSTİK DESTEK (ELD) =
ELD, karmaşık savunma sistemlerine sahip olmanın beraberinde getirdiği lojistik destek sorunların çözümü için geliştirilen bir metodolojidir. Bu alanda yaşanan başlıca sorun, bu tür sistemleri edinmenin ve hazır bulundurmanın yüksek maliyetidir. Sahip olma maliyeti yükseldikçe, performans ve maliyet arasındaki ilişki daha fazla sorgulanır hale gelir. Ayrıca; ileri teknoloji seviyesi, yüksek hareket kabiliyeti gibi özellikler ilave yeteneklere sahip olmayı gerektirirken geliştirme sürelerinin uzunluğu, tam harekât yeteneğinin kazanılması için geçen zaman ve sistemin planlanan ömrü sistemlerin sürdürülebilir olmasını gerekli kılar.

ELD farklı kaynaklarda benzer biçimde tanımlanır:

ASD SX000i’deki tanımlamaya göre ELD; “Lojistik faaliyetlerin (örneğin, desteklenebilirlik ve savunma sistemlerine/platformlarına –donanım veya yazılım- ait lojistik destek konularının) ve lojistik destek elemanlarının, zamanında ve maliyet etkin biçimde planlandığı, tedarik edildiği, uygulandığı, test edildiği ve sağlandığı idari ve teknik süreçtir”.

NATO Logistics Handbook 2012’de ELD; “Program/Projenin başlangıç sürecinde, sistem/malzemenin lojistik destek konularının titizlikle değerlendirilerek sistem ömür devri yönetimine dahil edilmesidir” şeklinde tarif edilmektedir. ELD için NATO müttefiklerinin hedefleri ile uyumlu olarak hazırlanmış olan ALP-10 rehberine göre; harekâta hazır bulunuşluğu sağlamak için gerekli tüm finansal ve diğer kaynaklar, performans hedeflerini elde etme ve zamanında teslim için gerekli kaynaklar kadar önemlidir. Bu rehberde ELD “sistem çözümüne ilişkin desteklenebilirlik hususlarının, sistem ömür devrinin erken safhalarından itibaren sürece entegre edildiği ve maliyet etkin bir şekilde destek unsurlarının planlandığı teknik süreç” şeklinde ifade edilir.

Amerikan Savunma Bakanlığı Direktifi 5000.39 ve MIL-STD-1369-A’daki ELD tanımı ise; “Aşağıda listelenmiş amaçlara erişmek için kontrollü, bütünleşik ve iteratif biçimde gerçekleştirilen idari ve teknik faaliyetler bütünüdür:

* Destek ihtiyaçlarının sistem ve ekipman tasarımına entegrasyonu,
* Destek ihtiyaçlarının, hazır olma ve tasarım amaçları ile uyumlu ve herbiri ile etkileşim içinde belirlenmesi,
* Gerekli desteği temin etmek,
* Kullanım safhasında ihtiyaç duyulan desteği en düşük maliyetle sunmak.

Blanchard, B.S. “Logistics Engineering and Management” isimli kitabında ELD’yi “sistemin nihai kullanıcısının sadece performans ihtiyacını değil, ürünün planlanmış ömrü boyunca hızlı ve ekonomik biçimde desteklenmesini de temin etmeye yardımcı olacak ilk planlama, bütçeleme ve kontrolleri sağlayan bir yönetim fonksiyonudur. ELD’nin ana hedefi, desteğin farklı elemanlarının (örneğin, test ve destek ekipmanları, yedek parça/onarım malzemeleri, gibi) bir araya getirilmesinin teminidir” şeklinde tanımlar.

Jones, J.V., “Integrated Logistics Support Handbook” isimli kitabında ELD’yi “önceden belirlenmiş ve ölçülebilir hedeflere, kabul edilebilir sahip olma maliyeti içinde ulaşılması amacıyla, desteklenebilir sistem tasarımı ve uygun destek kabiliyetini elde etmek için ihtiyaç duyulan faaliyetlerin kontrollü ve bütünleşik yönetimidir” şeklinde tanımlar. Bahse konu kitapta ayrıca; ELD faaliyetleri ile:

* Sistemler için ihtiyaç duyulan lojistik desteğe yönelik tasarıma etkide bulunulmasının,
* Sistemin hazır olma durumu hedefleri ile bu hedeflere katkıda bulunan destek gereksinimlerinin belirlenmesi ve geliştirilmesinin,
* Gerekli lojistik desteğin planlanması ve temin edilmesinin,
* İhtiyaç duyulan desteğin en az maliyetle sağlanmasının amaçlandığı belirtilmiştir.

Tanımlardan anlaşılacağı üzere; ihtiyaçların tespit edildiği ve sistemin geliştirildiği süreçte, kullanım, destek ve envanterden çıkarma safhalarında sistemin ihtiyaç duyacağı lojistik desteğin ve destek maliyetlerinin tanımlanması ve maliyet-performans dengesinin sağlanmasına yönelik tasarım faaliyetlerinde bulunulması, ELD metodolojisinin dayandığı temel husustur. Performans ile maliyet arasındaki ilişkinin doğrusal olmaması, bu kapsamdaki çalışmaların uzman ekip tarafından sistematik biçimde ve titizlikle yürütülmesini gerekli kılar. Bununla birlikte; karmaşık sistemlerin geliştirilme süreleri ile fiilen kullanılması arasında geçen sürelerin uzunluğu sebebiyle, ihtiyaç belirleme ve geliştirme safhalarında verilen kararların sonuçları belki de yıllar sonra görülebilir. Bu sebeple, lojistik mühendislerinin sistem ömür devrinin erken safhalarından itibaren aktif rol alması kritik derecede önemlidir. Tanımlanan performansın ömür devri boyunca maliyet etkin biçimde sağlanması taahhüt edildiğinden, lojistik mühendislerinin sorumluluğu ömür devrinin kalan safhalarında da devam edecektir.

ELD’nin başlangıç sorumluluğu, ihtiyaç belirleme ve tanımlama aşamalarında ihtiyaç makamları, kullanıcılar ve idame makamlarındadır. Tedarik makamları Teklife Çağrı Dokümanı (TÇD) ile birlikte başlangıç seviyesindeki ELD Planını (ELDP) yayımlar. Tedarik sözleşmesi ile yüklenici ELD isterlerine uygun şekilde ELDP’yi hazırlar. ELDP’nin hazırlanmasında ihtiyaç makamı, kullanıcı, idame makamı ve tadarik makamı gerekli girdi ve kontrolleri sağlar. ELD faaliyetleri ve ELDP hazırlanması çalışmaları ELD programı çerçevesinde yürütülür. ELD programı, en uygun destek gereksinimlerinin yanında bu gereksinimleri karşılayacak tasarımın ortaya konulmasını hedefler. En uygun çözümün elde edilebilmesi, kapsamlı sistem ve lojistik mühendisliği yöntemleri ve prosedürlerinin uygulanması ile mümkün olur. Süreç, ömür devri ve sistem seviyesi hedefleri ortaya koyan, bu hedeflere erişmek için belirsizliği yöneten ve gerektiği durumlarda kendini adapte eden yenilikçi ve tekrar eden yönetim anlayışı ile yönlendirilir.

Hem kullanıcı (ihtiyaç sahibi) hem de yüklenici tarafında ELD faaliyetlerini yönetip yürütecek organizasyonlar ve süreçler mevcut ve tanımlı olmalıdır. ELD kendi içinde farklı özelliklerde ve birbirinden nispeten bağımsız birçok disiplini (ELD elemanları) bir arada kullanmayı gerektirir. ELD programı, sistem mühendisliği sürecinin bütünleşik bir parçası olarak, kullanıcının, yüklenicinin ve alt yükleniciler ile tedarikçi organizasyonlarının ilgili unsurlarını kapsayan karmaşık bir destek organizasyonunun faaliyetlerini koordine eder. Kullanıcı ve yüklenici organizasyonları içinde, ELD elemanlarını yönetecek ve yürütecek uzman kişiler bulunmalıdır. ELD faaliyetlerini organizasyon içinde ve organizasyonlar arasında koordine etmek ve yönetmek, organizasyonel yapı ve süreçlerin yanı sıra ELD elemanlarına da tam olarak hâkim olmayı gerektirir.

ELD faaliyetleri [https://tssodypwiki.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)’]de belirlenen sistem ömür devri yönetimi modeli esas alınarak yapılandırılmıştır. Bu model, ihtiyaç belirleme ve ihtiyaç tanımlama aşamalarından oluşan ön konsept safhası ile başlayıp envanterden çıkarma safhasını da içine alan ömür devrinin tamamını resmeder. ELD, ön konsept safhasında başlayıp sistemin ömür devri boyunca devam edecek olan lojistik desteğin planlanmasına ve sağlanmasına ilişkin faaliyetler bütünüdür. Erken aşamalarda amaç desteklenebilirlik kapsamında sistem tasarımı üzerinde bir etkiye sahip olunması ve destek ihtiyaçlarının belirlenmesidir. Sonraki aşamalarda ise destek unsurlarının (ELD elemanlarının) tasarlanması, üretimi/temini/teslimi/ifası ve kullanım yerinde hazır bulundurulmasıdır. Ana fonksiyonu itibarıyla geliştirme safhasındaki tasarım aşamalarında yürütülen sistem mühendisliği, sistem ömür devrinin tamamına etki eden ana unsurdur. Bu nedenle; desteklenebilirlik ve destek unsurlarının tespiti ve geliştirilmesi gibi bazı faaliyetlerin, sistem tasarımı belirli bir olgunluk seviyesine gelinceye kadar ELD ve sistem mühendisliği çalışmaları arasında yinelemeli (iteratif) olarak icra edilmesi gerekmektedir. ELD’nin hedeflenen başarıya erişmesinde kullanılan en temel araç Lojistik Destek Analizleri (LDA)’dır. LDA; sistem geliştirme sürecinde destek gereksinimlerinin tanımlanması, analiz edilmesi ve somut hale getirilmesi faaliyetlerini içeren ve desteklenebilirlik anlamında tasarımın etkilenmesini hedefleyen bir analizdir. Tasarım olgunlaşarak netleştikçe, LDA faaliyetleri destek gereksinimleri kapsamında ihtiyaçların/kaynakların detaylandırılmasına ve gerekli verinin sağlanmasına odaklanır. Kullanım ve destek safhalarında ise planlamalara karşılık gerçekleşmeleri izlemek amacıyla kullanım ve bakım verisi geri bildirimlerinin sağlanması esastır. Tasarıma geri bildirim sağlayacak servis ekiplerinin ve idamede görev alan personel/kuruluşların girdileri ışığında saha koşulları altında desteklenebilirlik parametrelerinin değerlendirilmesi LDA sürecinin önemli bileşenlerindendir.

ELD en genel hali ile “savunma ve güvenlik sistemlerinin toplam ÖDM’yi en düşük seviyede tutabilmek ve bu sistemleri etkin ve verimli bir şekilde idame edebilmek maksadıyla kullanım ve destek safhasındaki ihtiyaçların tedarik döneminde bütünleşik bir şekilde ele alınmasını sağlayacak yönetimsel ve teknik bakış açısı” olarak tanımlanmaktadır.

Mühendislik/endüstriyel bakış açısı ile ELD “son kullanıcıya ömür devri boyunca desteklenebilir bir sistem teslim edebilmek maksadıyla, sistemin tasarım sürecinin maliyet, planlama ve kontrol açılarından bütünleşik olarak ele alınması” veya “en az maliyetle işletilebilecek bir destek sisteminin yaratılabilmesi maksadıyla, tüm lojistik ihtiyaçları ve disiplinleri bütünleşik bir şekilde yönetme fonksiyonu” şeklinde tanımlanabilir.

== 3.1. ELD’NİN TARİHÇESİ ==
ELD kavramı, 2. Dünya Savaşı sonrasında yaşanan soğuk savaş dönemi ile askerî alanda hayat bulmuş ve gelişmiş bir kavramdır. Yüksek teknolojiye sahip, karmaşık yapıdaki silah sistemlerinin hazır bulunuşluk maliyetlerinin yüksekliği 1960’lı yıllarda tecrübe edilmeye başlayınca çözüm üretilmesi ihtiyacı doğmuştur. Bulunan çözüm oldukça basittir; silah ve destek sistemlerinin kullanım ve idame dönemi maliyetlerini en aza indirecek şekilde tasarlanması. Bir başka deyişle “sonrasını baştan düşünmek”. ELD yaklaşımı ve ilk uygulamalar ABD Savunma Bakanlığı’nın 19 Haziran 1964 tarihli “Sistemler ve Teçhizat için ELD’nin Geliştirilmesi Direktifi” ile başlamıştır. Bu direktifte ELD, “sistemlerin bütün bakım ve onarım seviyelerinde desteklenmesi” olarak ifade edilmiştir. Zaman içinde ELD’nin askerî ve mühendislik/endüstriyel bakış açıları ile farklı tanımlamaları ortaya çıkmıştır.

ELD’nin başlangıçtaki hedefleri;

* Maliyet ekin biçimde bakım faaliyeti yürütülerek yüksek hazır bulunuşluğun elde edilmesi,
* Güvenilir ve idame edilebilir sistem tasarımı,
* Sistem kullanıma alınmadan önce ihtiyaç duyulan destek kaynaklarının hazır bulundurulması ve
* Lojistik destek için gerekli kaynaklar için ihtiyaç duyulan bütçenin planlanması başlıkları altında toplanmıştır.

1980’lere gelindiğinde ELD hedefleri değişim geçirerek;

* Lojistik hususların tasarım safhasından itibaren dikkate alınarak lojistik destek sağlanmasına ilişkin isterler çerçevesinde tasarıma etki edilerek savunma sisteminin desteklenebilirliğinin arttırılması,
* Bağımsız lojistik elemanların tamamının birlikte tedariki ve yönetimi ile daha etkin bir lojistik destek sağlanması şekline dönüşmüştür.

ELD elemanlarının bütünleşik ve ortak hedefe yönelecek biçimde yönetimi bütçe, kaynak ve yetenek israfının olmadığı bir destek sisteminin elde edilmesini sağlar. ELD elemanların her biri kendi içinde bağımsız ve farklı disiplinlere sahip olmasına rağmen esas olan ELD disiplini içinde bütün elemanların bütünleşik bir yapıda yönetilmesidir. Terminolojik olarak lojistik kavramının genişliği ve derinliğinden kaynaklanan kavram kargaşasını ortadan kaldırmak için ELD yerine bazı ülkelerin ve kurumların yayınlarında Entegre Ürün Desteği ve ELD Elemanları yerine Entegre Ürün Desteği Elemanları ifadeleri kullanılmaya başlanmıştır. Aynı şekilde, NATO bünyesinde ELD yerine Entegre Ömür Devri Desteği kavramının kullanılması yönünde bir eğilim bulunmaktadır. Ancak, halen ELD kavramı birçok ülkede ve ülkemizde yaygın şekilde kullanılmaktadır.

Terminolojideki değişimlere rağmen en üst seviyede sistemin kullanıma/göreve hazır olmasının en az maliyetle elde edilmesi temel prensibi her zaman geçerliliğini korumaktadır.

ELD yaklaşımı ile birlikte, lojistik disiplinler olarak da ifade edilebilecek ELD elemanları [bakım, ikmal desteği, iş gücü ve personel, destek ve test ekipmanları, tasarıma etki/tasarım etkileşimi, teknik veri ve dokümantasyon, eğitim ve eğitim desteği, tesisler ve altyapı, PEDU (paketleme, elleçleme, depolama ve ulaştırma), bilgisayar kaynakları, idame mühendisliği, ürün destek yönetimi] arasındaki entegrasyona odaklanılmış ve en iyi değer yaratma konusundaki çabalar bir disiplin altında toplanmıştır.

Ülkemizdeki uygulamalara bakıldığında, ihtiyaç makamlarının ELD konusundaki faaliyetlerini hazırlamış oldukları yönergeler vasıtasıyla proje faaliyetlerinin ayrılmaz bir parçası olarak yürüttükleri görülmektedir. Buna paralel olarak, Savunma Sanayii Başkanlığı (SSB) tarafından imzalanan sözleşmelerde başlangıcından itibaren ELD’ye ilişkin hususlar yer almakla birlikte 2005 yılında standart sözleşme metinlerinin hazırlanması ve uygulamaya konulması sonucunda, ELD’ye ilişkin hususlarda anlayış ve uygulama birliği sağlanmıştır. Sistem ömür devri yönetimi ilke ve uygulamalarının daha iyi anlaşılabilmesi amacıyla 2009, 2012 ve 2017 yıllarında SSB tarafından geniş katılımlı konferanslar düzenlenmiştir. TSSÖDYP’nin temellerini oluşturan Entegre Lojistik Destek Platformu çalışmaları da 2011 yılında gerçekleştirilerek sistem ömür devri yönetimi yaklaşımının fikri altyapısı oluşturulmuştur. İhtiyaç makamları, kullanıcılar, idame makamları ve tedarik makamları tarafından savunma ve güvenlik sistemlerinin ömür devri yönetiminde kilit rol oynayan ELD disiplinine ilişkin gelişmelerin ve yeni bakış açılarının iyileştirme faaliyetleri kapsamında uygulama alanına aktarılması çalışmalarına ülkemizde artan bir hızla devam edilmektedir.

== 3.2. ELD’NİN AMACI ==
ELD’nin başlıca hedeflerinden birisi de ürünlerin operasyonel kullanım süresini arttırırken destek ihtiyacını en az düzeye indirmektir. Böylece ürün ömür devri boyunca daha yüksek kazanımlara ulaşılarak finansal fayda elde edilmesi sağlanır. ELD, ürünün desteklenebilirliğinin tasarım aşamasında göz önünde bulundurulması için sistem mühendisliği çalışmalarına geri bildirimde bulunmak suretiyle ürün ile ilgili desteklenebilirlik gereksinimlerini belirler ve müşterinin ihtiyacı olan teknik desteği asgari maliyet ile yerine getirmeyi amaçlar. Bu nedenle ELD, sistem tasarımının başlangıcından itibaren, mühendislik çalışmalarının ayrılmaz bir parçasıdır. ELD mühendisleri, sistem ve tasarım mühendisleri ile birlikte çalışarak desteklenebilirliğin, tasarım çalışmaları süresince göz önünde bulundurulmasını sağlar.

Bu amaca yönelik olarak aşağıdaki temel faaliyetler gerçekleştirilir:

* En uygun kullanıma/göreve hazır bulunuşluk oranını en az maliyetle gerçekleştirecek ürün tasarımına ulaşılması,
* Kullanım, bakım, eğitim vb. lojistik destek kapsamındaki görevlerin eksiksiz olarak yerine getirilmesi,
* Ürünün görev yapacağı harekât ortamında ve görev profillerinde en uygun performans ve hazır bulunuşluğunun temini için ihtiyaç duyulan tüm destek kaynaklarının tasarımı, geliştirilmesi, bütçelenmesi ve doğrulanmasına yönelik desteğin planlanması ve geliştirilmesi,
* Ürünü desteklemek için gerekli unsurların sağlanması,
* Destek çözümünün fiziksel unsurlarının ihtiyaç duyulan yer ve zamanda hazır bulundurulması,
* Ürün ömür devrinin başından envanterden çıkarma safhasının sonuna kadar desteklenebilirlik çalışmalarının yürütülmesi ve lojistik desteğin sağlanması,
* Destek çözümünün fiziksel unsurlarının, harekât/operasyon gereksinimlerindeki değişimler ve teknolojik gelişmelere uyum sağlayacak biçimde güncellenmesi.

== 3.3. SİSTEM ÖMÜR DEVRİ VE ELD ==
Sistem ömür devrinin planlanmasında ve yönetiminde [https://tssodypwiki.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)] ve [https://tssodypwiki.ssb.gov.tr/index.php/Sistem_%C3%96m%C3%BCr_Devri_Y%C3%B6netimi_S%C3%BCre%C3%A7leri_Rehberi TSSÖDYP-02 Sistem Ömür Devri Yönetimi Süreçleri Rehberleri] referans olarak kullanılır.

ELD; savunma ve güvenlik sistemlerinin tanımlanması, tasarımı, geliştirilmesi, üretimi, temini, konuşlandırılması, kullanımı, desteklenmesi ve envanterden çıkarılması faaliyetlerini maliyet etkin olarak planlayan ve bu planın uygulanmasını sağlayan tüm idari ve teknik aktivitelerin gerçekleştirildiği bir yönetim organizasyonudur.

Sistem ömür devrinin her bir safhasındaki ELD faaliyetleri, içinde bulunulan safhaya göre farklılık göstermektedir. Söz konusu faaliyetler sistem isterlerine, proje tipine, tedarik yöntemine, tedarik kaynağına göre farklılık gösterebilir ve faaliyetlerin tamamına her sistem için ihtiyaç duyulmayabilir. Tüm safhalarda yürütülecek faaliyetlerin yürürlükteki mevzuata uygun biçimde insan veya çevreye zarar vermeyecek şekilde yürütülmesi esastır.

Ön konsept safhasında desteklenebilirlik kapsamı ve hedefleri belirlenir. İhtiyacın tanımlandığı bu safhada, destek kapsamının şekillendirilmesi ve temel isterlerin tespit edilmesi beklenir. Destek kapsamı, ilerleyen ömür devri safhalarında yürütülecek destek faaliyetlerine yön verecek ve ilgili isterlerin belirlenmesinde etkin olacak stratejiyi ortaya koyar.

Konsept safhasında gerçekleştirilen ELD faaliyetleri;

* Kısıtlar göz önünde bulundurularak destek kaynaklarının belirlenmesi,
* Proje gruplarına lojistik uzmanlarının dahil edilmesi veya lojistik çalışma grupları oluşturulması,
* Sistem çözümlerinin güvenilirlik, idame edilebilirlik ve kullanım destek düzenlemeleri açısından değerlendirilmesi,
* Sistem çözümleri için gereken lojistik destek kapsamının her bir ELD elemanı bazında belirlenmesi,
* Lojistik ile ilgili standardizasyon isterlerinin belirlenmesi,
* Güvenilirlik, Kullanılabilirlik, İdame Edilebilirlik, Desteklenebilirlik ve Test Edilebilirlik parametreleri için hedeflerin belirlenmesi,
* Lojistik destek kilometre taşlarının belirlenmesi,
* Sistem çözümleri için başlangıç ömür devri maliyetlerinin analiz edilmesi, lojistik planların gerçekleşmesinde amaçlanan lojistik faaliyetlerin hazırlığı için kullanılacak fonların tanımlanması,
* Lojistik gereksinimlerin iş tanımına, şartnameye, teklife çağrı dokümanına, seçim değerlendirme kriteri ve sözleşmelere dahil olması..

Geliştirme safhasında gerçekleştirilen ELD faaliyetleri;

* Desteklenebilirlik ve sürdürülebilirliğin sağlanmasına yönelik tasarımı etkileme faaliyetlerinin yürütülmesi,
* Güvenilirlik, Kullanılabilirlik, İdame Edilebilirlik, Desteklenebilirlik ve Test Edilebilirlik parametreleri için hedeflerin gerçekleştirildiğinin mümkün olduğunca test edilerek ve ölçülerek doğrulanması,
* Destek elemanlarının geliştirilmesi, tedariki, üretimi ve hazır edilmesinin takvime uygun olarak sağlanması,
* Kullanım safhasının başlangıcındaki lojistik planlarının finansmanının sağlanması,
* Planlanan lojistik desteğin yürütüldüğünü ve operasyonel hedeflerin karşılandığını test edip ölçülerek, hedefleri doğrulamaya yönelik planlama yapılması,
* Kullanım safhasında sistemin desteğini sağlayacak organizasyonun teşkil edilmesi,
* Bakım Planı geliştirilmesi.

Üretim Safhasında gerçekleştirilen ELD faaliyetleri;

* Ürünlerin tasarım, kullanıma/göreve hazır bulunma ve desteklenebilirlik isterlerinin karşılaması,
* Konuşlandırma gereksinimlerini karşılamak üzere ELD elemanlarının temin/ifa edilmiş olması, lojistik desteğe ilişkin düzenlemelerinin kullanım safhası başlamadan önce tamamlanması,
* Desteklenebilirliği etkileyecek tüm unsurların takvime uygun olarak hazır bulundurulmasının sağlanması,
* Odak sistem ile birlikte ELD kapsamındaki teslimat kalemlerinin (teknik yayınlar, destek ve test ekipmanları, başlangıç yedekleri, destek yazılımı lisansları, gerekli insan gücü, tesisler vb.) hazır olduklarının doğrulanması,
* Bakım planlarının güncellenmesi, kullanıcıya sistemin ve teknik özelliklerinin açıklamaları ile teslim edilmesi.

Kullanım safhasında gerçekleştirilen ELD faaliyetleri;

* ELD organizasyonunun sürekliliğini sağlayacak finansal ve yönetsel kaynakların düzenlenmesi,
* En iyi işlevselliği sağlamak için ELD yönetim sisteminin gerektirdiği periyodik gözden geçirmelerin gerçekleştirilmesi,
* Desteklenebilirlik gereksinimleri ve talep edilen değişikliklerin ÖDM’ye etkisinin belirlenmesi,
* Sistemin kullanım safhasındaki performasına ait geri bildirimler ile bakım/onarım verilerinin toplanması ve kayıt altına alınaması,
* Lojistik desteğin planlanan ve gerçekleşen faaliyetler olarak ayrı ayrı analiz edilerek değerlendirilmesi ve gerekli görülen alanlarda iyileştirme yapılması,
* Sistemdeki eksikler ile güncelleme/iyileştirme ihtiyaçlarının tanımlanması ve modifikasyon kararları öncesinde tasarım ve destek arasındaki ödünleşimlerinin değerlendirilmesi,
* ELD elemanlarının değişen şartlara uyumlandırılması sağlanması.

Destek safhasında gerçekleştirilen ELD faaliyetleri destek planlama ve destek uygulama aşamaları olmak üzere iki aşamada yürütülür. Ön konsept, konsept, geliştirme ve üretim safhalarında desteklenebilirliğe ve lojistik destek planlamalarına ilişkin yürütülen faaliyetler destek planlama aşaması içindedir. Kullanım ve envanterden çıkarma safhalarında yürütülen lojistik destek faaliyetleri ise destek uygulama aşaması kapsamındadır.

Envanterden çıkarma safhasında gerçekleştirilen ELD faaliyetleri;

* Envanterden Çıkarma Planı’na uyumlu olarak kullanım safhasındaki gerekli destek faaliyetlerinin sonlandırılması,
* Envanterden çıkarma safhasındaki sistem için uygulanabilir ELD elemanlarının analiz edilmesi ve uygulaması için ELDP’de dokümante edilmesi,
* Sisteme ait ELD verilerinin gelecekte kullanılabilmesi için uygun şekilde arşivlenmesi,
* Envanterden çıkarılan donanımların tekrar kullanımının, uygun şekilde hurdaya ayrılmasının veya yeniden dönüşümünün değerlendirilmesi.

== 3.4. ÖMÜR DEVRİ MALİYETİ VE ELD ==
Ömür devrinin erken aşamaları, ÖDM’ye etki eden en önemli kararların verildiği dönemdir. Çoğu zaman; sistem tasarımının sonuna gelindiğinde, sistem ÖDM’nin yaklaşık %85’i bu dönem içinde veya öncesinde alınan tasarıma ve lojistik desteğe ilişkin kararlar ile belirlenmiş olur. Ömür devrinin ilk dönemlerinde ömür devri maliyet analizi istenilen seviyede performans sağlamak amacıyla seçilen tasarım alternatiflerinin maliyete olan etkilerini belirlemek üzerine yoğunlaşır.

ÖDM’nin yaklaşık %60 ila %80’i,kullanım safhasındaki faaliyetler ve idame gereksinimlerinin karşılanması sonucunda ortaya çıkmaktadır. Bu sebeple, destek ve bakım konseptlerinin mümkün olan en erken safhada, özellikle tasarımla etkileşim içinde belirlenmesi kritik derecede önemlidir.

== 3.5. ELD ORGANİZASYONU VE SÜREÇLERİ ==
Sistem ömür devri yönetimi kapsamında; ELD faaliyetlerinin planlanması, yürütülmesi ve kontrol edilmesi için ön konsept safhasında ihtiyaç makamı/kullanıcı bünyesinde ilgili paydaşların yer aldığı bir ELD Ön Çalışma Grubu oluşturulması önerilir. Bu grup tarafından sisteme ilişkin temel lojistik ihtiyaçlar ve isterler belirlenir, belirlenen isterler Proje/İhtiyaç Tanımlama Dokümanında belirtilir.

Konsept safhasında tedarik makamı tarafından ihtiyaç makamı/kullanıcı ve idame makamı temsilcileri ile ilgili diğer paydaşların yer alacağı bir ELD Çalışma Grubu oluşturulur. Ön konsept safhasında ELD Ön Çalışma Grubu tarafından yapılmış olan çalışmalar, ELD Çalışma Grubunca ihtiyaç duyulan ilk girdileri sağlar. Yürütülecek fizibilite çalışmaları ile ELD Çalışma Grubu tarafından sanayiinin ELD konusundaki girdileri alınır. Geliştirme safhasında ELD Çalışma Grubuna yüklenici firma temsilcileri de dâhil edilerek üretim ve kullanım safhalarında grubun sürekliliği sağlanır.

ELD Ön Çalışma Grubunun görev ve sorumlulukları;

Ön Konsept safhasında (Destek Planlama Aşaması);

* Sistem ve ELD elemanları ile ilgili ihtiyaçların/isterlerin belirlenmesi,
* Belirlenen isterlere göre Proje/İhtiyaç Tanımlama Dokümanına girdi sağlanması

ELD Çalışma Grubunun görev ve sorumlulukları;

Konsept safhasında (Destek Planlama Aşaması);

* Proje yönetim sürecinde yapılacak ELD yönetim stratejisinin oluşturulması,
* ELD faaliyetlerinin planlanması ve ELDP kapsamının hazırlanması,
* LDA faaliyetleri ile hazırlanacak rapor ve planların kapsamının belirlenmesi,
* Tasarım faaliyetlerinde kullanılacak standartlar ve yazılım alt yapısının belirlenmesi,
* Desteklenebilirlik ve lojistik destek sağlanmasına ilişkin yüklenici/teklif değerlendirme kriterlerinin hazırlanması,
* Sistem tasarımına yönelik ELD gereksinimleri ile ilgili girdilerin yapılması,
* ELD isterlerinin nihai hale getirilmesi ve TÇD’de yer almasının sağlanması.

Geliştirme ve üretim safhalarında (Destek Planlama Aşaması);

* Tasarım kapsamında yapılan faaliyetlerin incelenmesi ve değerlendirilmesi maksadıyla düzenli aralıklarla ELD gözden geçirme toplantıları yapılması,
* Sistem kalifikasyon test sonuçlarının lojistik gereksinimler açısından uygunluğunun kontrol edilmesi,
* Hazırlanan analiz raporları ve ELDP’nin uygunluğunun incelenmesi,
* ELD elemanlarına ilişkin kapsamın uygunluğu ve yeterliliğinin kontrol edilmesi,
* Prototip sistemlerin test ve kabul muayenelerinde lojistik hususlar kapsamında görev alınması,
* Üretim sürecinde ELD ile ilgili faaliyetlerin takip ve kontrol edilmesi,
* Sistemin konuşlandırılması aşamasında, kullanım ve destek faaliyetlerinin uygunluğu ve yeterliliğinin kontrol edilmesi, değerlendirilmesi, ihtiyaç durumunda düzeltici önlemler alınması,
* Projenin özelliğine göre ELD teslimatlarının yapılmasının sağlanması,

Kullanım safhasında (Destek Uygulama Aşaması);

* ELD teslimatlarının yapılmasının sağlanması,
* Sistem kullanım ve lojistik destek verilerinin değerlendirilmesi;
* Kullanım ve lojistik destek verileri kullanılarak sistemin güvenilirlik, hazır bulunuşluk, bakım yapılabilirlik, desteklenebilirlik vb. hususlarına ilişkin analizlerin yapılması,
* Analiz sonuçları ile sistem tasarım verileri ve kullanıcı isterlerinin karşılaştırılması,
* İhtiyaç durumunda düzeltici önlemler alınması,
* Lojistik destek faaliyetlerinin (bakım, onarım, malzeme tedariki, depolama, ulaştırma vb.) ELDP ve ilgili diğer dokümantasyona göre yürütülmesi,
* Sistemin kullanım ömrü ve ÖDM’nin sürekli olarak kontrol edilmesi,
* Sistem ömür devri verileri ve LDA sonuçlarına göre sistem üzerinde gerekli düzeltici faaliyetlerin yapılması veya sistemin envanterden çıkartılması.

== 3.6. ELD ELEMANLARI ==
ELD, bir ürünün desteklenebilirliği ve ömür devri maliyetlerini optimize edecek destek çözümünü geliştirmek için ihtiyaç duyulan lojistik destek unsurlarının tam olarak anlaşılması ve optimum lojistik destek hedefine erişmek amacı ile bütünleşik biçimde yönetilmesi esasına dayanır.

Bu fonksiyonlar, ELD elemanları olarak adlandırılan on iki kategori altında gruplanır:

* Bakım
* İkmal Desteği
* İş gücü ve Personel
* Destek ve Test Ekipmanları
* Tasarıma Etki/Tasarım Etkileşimi
* Teknik Veri ve Dokümantasyon
* Eğitim ve Eğitim Desteği
* Tesisler ve Altyapı
* Paketleme, Elleçleme, Depolama, Ulaştırma (PEDU)
* Bilgisayar Kaynakları
* İdame Mühendisliği
* Ürün Destek Yönetimi
[[Dosya:Şekil7 ELED Elemanları İle Optimum Lojistik Destek İlişkisi.jpg|alt=|sol|küçükresim|650x650pik|Şekil 7 ELD Elemanları ile Optimum Lojistik Destek İlişkisi]]

=== 3.6.1. BAKIM ===
Ürün ömür devri boyunca uygulanacak bakım konseptlerini ve gereksinimleri içerir. Bu ELD elemanının, diğer lojistik destek elemanlarının planlanması, geliştirilmesi ve tedarikinde büyük etkisi vardır.

Bakım elemanının amacı, olabilecek en iyi ekipman/kabiliyet kombinasyonunu mümkün olan en düşük maliyette sağlayabilmek için bakım konsepti ve gereksinimlerini belirlemek, planlamak, kaynak sağlamak, uygulamak ve bakım için gerekli faaliyetleri gerçekleştirmektedir.
[[Dosya:Şekil 8 Bakım Faaliyetleri.png|alt=Şekil 8 Bakım Faaliyetleri|sol|küçükresim|600x600pik|Şekil 8 Bakım Faaliyetleri]]

Sistemin ömür devri boyunca kendisinden beklenen yetenekleri ve hizmetleri yerine getirmesi ve kullanım sürdürülebilirliğini sağlaması maksadıyla Şekil 8’de verilen önleyici ve düzeltici bakım faaliyetleri yürütülür.

Önleyici bakım faaliyetleri, planlı bakım faaliyetleri olup sistemde arıza meydana gelmeden önce arızanın önlenmesi maksadıyla yürütülen planlı/periyodik bakım faaliyetleridir. Önleyici bakım faaliyetleri kapsamında arızalar meydana gelmeden önce alınacak tedbirlerin belirlenmesine ve uygulanmasına yönelik analizlerin düzenli olarak yapılması da sağlanmalıdır.

Düzeltici bakım faaliyetleri, plansız bakım faaliyetleri olup sistemde arıza meydana geldiğinde yürütülecek onarım/tamir işlemleridir. Plansız bakımlar arızanın tespit edilmesi, arızanın giderilmesi, özel durumlarda arıza onarımı/tamiri sonrası gerçekleştirilmesi gereken kontrollerin yapılması faaliyetlerini içerir. Düzeltici bakım faaliyetlerine ilişkin sonuçların/verilerin analiz edilerek arıza oluşma sıklıklarına ve periyotlarına göre önleyici bakım faaliyeti kapsamına alınabilecek faaliyetlerin belirlenmesini ve bu kapsama alınmasını sağlayacak bir mekanizma kurulması bakım etkinliğinin artılması açısından önemli bir çalışmadır.

Bakımın planlanması ve yürütülmesi kapsamında aşağıdaki faaliyetler gerçekleştirilir.

'''Bakım konseptinin geliştirilmesi'''

Bakım konsepti, ELDP ve destek konsepti kullanılarak geliştirilir.

'''Bakım Onarım Seviyesi Analizi (LORA)'''

Sözleşme ve ekleri, tasarım mühendislik verileri, ELDP, yazılım desteklenebilirlik analiz raporu, RAMST raporları, destek konsepti kullanılarak LORA gerçekleştirilir.

'''Bakım planının geliştirilmesi'''

Bakım planı; sözleşme, ELDP, LORA raporu ve bakım konsepti kullanılarak geliştirilir.

'''Bakım görevlerinin yürütülmesi'''

Bakım faaliyetleri, sözleşme ve ekleri ile bakım planına uygun olarak yürütülür.

'''Desteklenebilirlik Emniyet Analizleri'''

Tasarım mühendislik verileri, ELDP, LDAK, MTA raporu ve RAMST raporları kullanılarak yazılım Desteklenebilirlik Emniyet Analizleri gerçekleştirilir.

'''Önleyici Bakımın Geliştirilmesi ve Sürekli İyileştirme (RCM vb. yöntemler)'''

Tasarım mühendislik verileri, ELDP, RAMST raporları, tedarikçi verileri ve LDAK kullanılarak Önleyici Bakım Görev Gereksinimleri (ÖBGG) geliştirilir.

'''Bakım Görev Analizleri (MTA)'''

Sözleşme ve ekleri, tasarım mühendislik verileri, ELDP, LORA raporu, RAMST raporları, planlı bakım planı ve destek konsepti kullanılarak MTA gerçekleştirilir.

'''Kullanım Safhasında Bakım Optimizasyonu'''

Kullanım safhasında bazı faktörler sistem ve ELD elemanları üzerinde bir etkiye sahip olabilir. Bu tür faktörler daha önce belirlenmiş bakım konsepti ve önleyici bakım faaliyetleri üzerinde bir değişiklik yapılmasını gerektirebilir. Bu durumda önleyici bakım görevlerinin etkinliğinin artırılması için optimizasyon çalışması yapılmalıdır.

Kullanım safhasında bakım optimizasyonunun sağlanması için aşağıdaki faaliyetler yürütülür:

* Analizlerin yapılarak eksik/aksak hususlar ile darboğazların tespit edilmesi,
* Önleyici bakım faaliyetleri kapsamında arızalar meydana gelmeden önce alınacak tedbirlerin belirlenmesi ve uygulanması
* Sıklıkla oluşan arızalara ve bu arızaların periyotlarına göre önleyici bakım faaliyeti kapsamına alınabilecek faaliyetlerin belirlenmesine ve bu kapsama alınmasına yönelik bir mekanizma kurulması.

'''Tanı Analizlerinin gerçekleştirilmesi (D&PHM)'''

Sözleşme ve ekleri, tasarım mühendislik verileri, ELDP ve RAMST raporları kullanılarak tanı analizleri (Diagnostics&Prognostics and Health Management Analysis) gerçekleştirilir.

'''Yazılım Desteklenebilirlik Analizleri'''

Tasarım mühendislik verileri, ELDP, LORA raporu, MTA raporu, RAMST raporu ve destek konsepti kullanılarak Yazılım Etki Analizi gerçekleştirilir. Yazılım Etki Analizi; yazılımın, ürünün kullanım ve desteğindeki etkilerini tarif eder.

=== 3.6.2. İKMAL DESTEĞİ ===
İkmal destek elemanının amacı; mümkün olan en düşük ÖDM’de en iyi kabiliyetin kullanıma hazır olmasını sağlayabilmek için gerekli onarım parçaları, yedekleri ve bütün ikmal maddelerini/hizmetlerini tedarik etmek için yönetim faaliyetlerinin belirlenmesi, planlanması, söz konusu faaliyetlere yönelik kaynağın sağlanması ve faaliyetlerin icra edilmesidir. Böylece; doğru onarım parçaları, yedekler ve malzemelerin, doğru nitelik ve nicelikte, doğru zamanda, doğru fiyata, doğru yerde olması sağlanır. Bu kapsamda üretilecek tedarik verisi; satın alınacak, kontrol edilecek, paketlenerek son kullanıcıya teslim edilecek ürünlere ait tanımlama, açıklama ve test bilgilerini içerir.

İkmal destek; yedeklerin, tamir parçalarının ve malzemelerin tedarik edilmesi, listelenmesi, teslim alınması, depolanması, transferi, dağıtılması ve envanterden çıkarılmasına dair gereksinimlerin belirlenmesi için gerekli bütün yönetsel işlemler, prosedürler ve tekniklerden oluşur. Bu süreç; başlangıç desteğine yönelik ön tedarik hazırlığı ile birlikte ihtiyaç duyulan ikmal maddelerinin/hizmetlerinin tedarikini/ifasını, dağıtımını ve yenilenmesini de kapsar ve temelde iki faaliyetten oluşur.

'''Ön Tedarik Verisinin Sağlanması'''

Bu faaliyet çerçevesinde; ürüne gerekli desteği sağlayabilmek için satın alınması gereken malzeme miktarını da içerecek şekilde, ön tedarik verisi temin edilir. Kodlandırma ise, ikmal sisteminde yer alan ekipman, komponent ve parçaların standart bir şekilde isimlendirilmesi, tanımlanması ve sınıflandırılmasını sağlar.

'''Malzeme İkmalinin Gerçekleştirilmesi'''

Bir kurum, kuruluş ya da şirketin barış ve savaş ortamında yürütmüş olduğu lojistik faaliyetlerin başarısı; ikmal maddelerinin doğru, kesintisiz ve hızlı akışına bağlıdır. Bu akışın sağlanmasında, tedarik, envanter tutma, stok kontrolü, depolama, bilgi sistemleri kullanımı, tesis yerleşimi gibi etkenler çok önemlidir. İkmal faaliyetleri, müşteriden gelen siparişlerin yönetilmesi ve mevcut stoklardan ya da stokta bulunmadığı durumda tedarik edilerek ihtiyaçların karşılanmasından oluşur. Bu faaliyet kısmen müşteri, kısmen de yüklenici tarafından yürütülür. Fiyat tekliflerinin oluşturulması, siparişlerin verilmesi, teslimatların gerçekleştirilmesi ve faturalandırılması gibi aktiviteleri içerir.

=== 3.6.3. İŞ GÜCÜ VE PERSONEL ===
İş gücü ve personel ELD elemanının amacı; ürünün ömür devri boyunca kullanılması ve idame edilmesi için gerekli nitelikte iş gücü ve personelin belirlenmesi, planlanması, kaynağın sağlanması ve istihdam edilmesidir. Yapılacak iş gücü ve personel analizi ile ürünün ömür devri süresince kullanımı, idamesi ve desteklenmesi için ihtiyaç duyulan kalifikasyona ve yeteneğe sahip iş gücü ve personelin tespit edilmesine, sağlanmasına ve istihdamına yönelik çalışma yapılır. İş gücünü planlarken, sadece iş odaklı operasyonel planlama süreçleriyle yetinmeyip bunun ötesine geçerek stratejik planlamanın yapılması da günümüz rekabet ortamında önemli bir konudur. Aslında iş gücü planlaması özünde; yapılması gerekli işe, uygun kişinin, reel maliyet ve olması gereken zamanda katılımı olarak özetlenebilir. Burada ilgili insan kaynaklarının becerileri ve yetenekleri, bilgi birikimleri ve tecrübeleri ile uzun vadede şirket içerisinde alacakları çeşitli görev tanımları gibi konular da gözönüne alınmaktadır. Örneğin; bir kişi işten ayrıldığında iş akışı etkilenmeden yerine geçebilecek olan insan kaynağının öncesinde planlanması veya kurum içi eğitim çalışmalarıyla yetkinliklerinin yükseltilmesi doğrultusunda kariyer planlarının yapılması gibi maddeler hayata geçirilmelidir.

=== 3.6.4. DESTEK VE TEST EKİPMANLARI ===
Destek ve Test Ekipmanları ELD elemanının amacı; ürünün ihtiyaç duyulduğunda kullanıma hazır olmasını sağlamak üzere, kullanımı, desteği ve ikmalini sürdürebilmek için gerekli destek ekipmanlarının (mobil veya sabit) tedarik edilmesi ve desteklenmesine ilişkin yönetsel faaliyetlerin belirlenmesi, planlanması, kaynak tahsisi ve uygulanmasıdır.

Destek ve test ekipmanı, ürünün destek ve idamesi için gerekli olan her türlü ekipmanı kapsayan bir terimdir. Kapsamına; çok kullanımlı destek elemanları, el aletleri/takım/avandanlıklar, meteoroloji ve kalibrasyon ekipmanları, ölçü aletleri ve manuel/otomatik test ekipmanları dahildir.

Ürün tedariği esnasında program yöneticilerinden beklenenlerden biri de envanterde mevcut olan destek ekipmanlarının kullanımına ağırlık verilmesi ve yeni destek ekipmanı geliştirme ihtiyacının asgariye indirilmesi vasıtasıyla envanterdeki destek ekipmanı miktarının artmasının önlenmesidir.

Bu kapsamda iki ana faaliyet gerçekleştirilir:

'''Destek ve Test Ekipmanları Gereksinimlerinin Analiz Edilmesi'''

Bu analiz, ELDP’den veya diğer ELD unsurları tarafından belirlenen gereksinimlerden türetilen destek ve test ekipmanları gereksinimlerini tanımlar ve dokümante eder. Bu tanımlama esnasında; yeni, genişletilmiş veya yükseltilmiş destek ve test ekipmanları seçeneklerinin yanı sıra mevcut ekipmanların kullanımı da dikkate alınmalıdır. Analizler kapsamında aynı zamanda, destek ekipmanının nasıl envanterden çıkarılacağı da planlanmalıdır.

Bu faaliyetin çıktısı olan Destek ve Test Ekipmanları Planı, bütün destek ekipmanlarını tanımladığı gibi ekipmanın kendisi için lojistik desteği de öngörmelidir.

'''Destek ve Test Ekipmanlarının Sağlanması'''

Bu faaliyet; destek teçhizatının geliştirilmesi, üretilmesi, satın alınması, kurulması ve idame edilmesini kapsar. Ömür devri safhalarında üretilecek “Destek ve Test Ekipmanları Raporu” ilgili tarafın yönetimine, destek ve test ekipmanlarının durumunun anlık bir özetini sunar. Test faaliyetlerinin herhangi bir aksaklığa uğramadan yürütülebilmesi için ilgili test ekipmanlarının zamanında ve uygun yerde hazır bulundurulması hususu doğrulama ve geçerleme faaliyetlerini gerçekleştiren birimler ile koordine edilir.

=== 3.6.5. TASARIMA ETKİ/TASARIM ETKİLEŞİMİ ===
Geliştirme projelerinin başarılı olması için; halen kullanımda olan benzer sistemlerden yola çıkılarak ELD hedeflerinin, proje başında kullanıcı ile birlikte belirlenmesi, tüm tasarım aşamasından başlayarak bu hedeflere göre projenin yürütülmesi ve desteklenebilirlik kriterlerinin ölçülebilir metrikler ile tasarıma yansıtılmasının sağlanması gerekmektedir. Başarılı bir ürünü üç temel kriter ile tarifleyebiliriz; tasarım olarak performans hedeflerini karşılayan, maliyet etkin ve desteklenebilir.

Bu üç temel unsur, bir biri ile ayrılmaz ve beraber değerlendirilmesi gereken unsurlardır. Eğer bu üç unsuru detaylandırmak istersek, aşağıdaki şekilde deniz platformu için basit bir örnek verebiliriz. Her türlü performans hedeflerini karşılamak için tasarlanan sistemin, görevi esnasında kritik arıza yaşamamalıdır. Arıza yaşadığında ise, bu arızayı gidermek için eğitilmiş personeli, eğitim kitapları, yedek parçası, destek ekipmanları ile kolay, hızlı ve uygun maliyetle onarılabiliyor olması gerekmektedir.
[[Dosya:Şekil9 Savunma Ve Güvenlik Sistemi İçin Başarı Kriteri.jpg|alt=Şekil 9 Savunma ve Güvenlik Sistemi İçin Başarı Kriterleri|sol|küçükresim|500x500pik|Şekil 9 Savunma ve Güvenlik Sistemi İçin Başarı Kriterleri]]

Tasarıma Etki/Tasarım Etkileşimi ELD elemanı kapsamında:

* Desteklenebilirliğin sağlanması için ürünün fikir aşamasından itibaren ömür devri boyunca tasarımına (İlk tasarım, iyileştirme, yarı ömür modernizasyonları vb.) etki edilmesi,
* Kullanıma hazır bulunma, etkinlik ve ÖDM için en uygun tasarımı elde etmek amacıyla sistem mühendisliği sürecine dahil olunması gerekir.

Tasarıma Etki/Tasarım Etkileşimi; sistem mühendisliğinin güvenilirlik, kullanıma hazır bulunma, idame edilebilirlik, desteklenebilirlik, test edilebilirlik gibi niceliksel tasarım parametrelerinin işlevsel ELD elemanları ile entegrasyonudur. Tasarıma Etki/Tasarım Etkileşimi, ürün tasarımı ile ürünü desteklemek için ihtiyaç duyulan kaynaklar arasındaki dinamiği ortaya koyar.

Söz konusu tasarım parametreleri, gereksinimlerle ilişkilendirilmiş olmalı ve operasyonel terimler şeklinde ifade edilmelidir. Böylece ürün destek gereksinimleri, ürünün kullanıma hazır bulunma hedefleri ile maliyetlerin etkin şekilde dengelenmesini sağlayacak şekilde belirlenir. Bu amaçla aşağıdaki üç konu başlığı altında verilen ana faaliyetler gerçekleştirilir:

'''ÖDM Analizlerinin Gerçekleştirilmesi'''

ÖDM analizi, ürün için farklı tasarım alternatifleri arasında maliyet etkinlik açısından en iyi seçeneği belirler.

'''LDA’nın Gerçekleştirilmesi'''

LDA faaliyeti, ilgili standartlara uygun olarak bir LDA veri tabanı oluşturur. LDA veri tabanı, bütün lojistik verilerin kayıt altına alındığı ve muhafaza edildiği tek ortamdır. Tedarik, mühendislik ve kullanıcılar arasında veri tutarlılığının sağlanabilmesi için tüm ELD elemanları arasındaki veri akışı LDA veri tabanı (LDA Kayıtları, LDAK) üzerinden sağlanır. Örneğin, teknik dokümanların ve bakım prosedürlerinin hazırlığı, LORA analizleri, MTA ve ÖDM analizleri için ortak bilgi kaynağı LDAK’dır.

'''RAMST Analizlerinin Geçekleştirilmesi'''

Bu faaliyet esnasında; ürün tasarımının güvenilirlik, kullanıma hazır bulunuşluk, idame edilebilirlik ve test edilebilirlik karakteristikleri analiz edilir.

=== 3.6.6. TEKNİK VERİ VE DOKÜMANTASYON ===
Teknik Veri ve Dokümantasyon; kayıt şekli ya da yönteminden bağımsız olarak bilimsel ve teknik içerikli kayıtlı veri ve bilgilerdir. Bilgisayar yazılımı, finansal ya da idari bilgiler gibi sözleşme yönetim bilgileri Teknik Veri ve Dokümantasyon kapsamına girmez.

Teknik Veri ve Dokümantasyon elemanının başlıca iki hedefi mevcuttur:

* Bilgiyi elde etme ve bakım faaliyetlerini tanımlama, planlama, doğrulama, kaynak tespiti ve yürütme,
* Teknik yayın planlama, geliştirme, üretme ve bakımı.

Bu maksatla yürütülen faaliyetler ise, teknik veri paketini geliştirme ve teknik yayınların hazırlanması süreçleri olarak aşağıdaki iki başlık altında özetlenmektedir.

'''Teknik Veri Paketini Geliştirme'''

Teknik Veri Paketi (TVP), bir ürün/sistemin ürün ömür devri boyunca tedarik stratejisi, geliştirme, üretime hazırlama, üretim geliştirme, üretim, mühendislik ve lojistik aktivitelerini destekleyebilecek yeterlilikte teknik olarak tanımlanmasıdır. TVP geliştirme süreci, birçok farklı ELD fonksiyonunu destekleyebilecek şekilde organize edilmiş olmalı ve yönetilmelidir. TVP, ürünün/sistemin performansını sağlayabilmesi için ihtiyaç duyulan tasarım konfigürasyonu ve ilgili tüm prosedürleri tanımlar ve ilave olarak değişik veri türlerini içerir. TVP’nin oluşturulmasında; veri gereksinimleri ve mülkiyet hakları korunarak, verinin zamanında ve uygun maliyetle elde edilmesi, güncel tutulması, kullanım amacına uygunluğu ve yeterliliği, ayrıca kullanım noktasına en uygun şekilde ulaştırılması gibi hususların tanımlanması ve kontrolü hususlarına da azami dikkat gösterilir.

'''Teknik Yayınların Hazırlanması'''

Teknik yayınlar, ürünün mimarisi ve fonksiyonları ile kullanımını tarif eden dokümanlardır. Kullanım ve bakım talimatları, parça listeleri, teknik bilgi ve prosedürleri kapsar. Teknik yayınların muhatabı idame makamları ve/veya son kullanıcılar olup herhangi bir formatta yayınlanabilirler. Teknik yayınlar bir ürünün desteklenmesi açısından önemli öğelerdir. Teknik yayın hazırlanmasında izlenecek süreç ve yaklaşımlar "[https://tssodypwiki.ssb.gov.tr/index.php/Teknik_Yay%C4%B1n_Haz%C4%B1rlama_Rehberi TSSÖDYP-12 Teknik Yayın Hazırlama Rehberi]” nde açıklanmıştır.

=== 3.6.7. EĞİTİM VE EĞİTİM DESTEĞİ ===
Bu ELD elemanının hedefi; belirlenen eğitim stratejisinin uygulanması ile eğitim desteği kaynaklarının belirlenerek planlanması, ürünün ömür devri boyunca en uygun performans ve kullanıma hazır bulunuşluk seviyesini sağlayacak şekilde kullanılması, idamesi ve desteklenmesi için personeli eğitmektir.

Eğitim İhtiyaçları Analizi, ürünün kullanımı için doğru eğitimin belirlenmesi amacıyla yapılmalıdır. Eğitim İhtiyaçları Analizi içinde yer alan isterler, eğitimi alacak personelin yetkinliğini de dikkate almalıdır.

Ürünü görev sahasında kullanacak ve idame ettirecek personelin eğitimi ürün sahaya konuşlandırılmadan hemen önce ya da kullanıma alınmadan önce verilir. İlerleyen safhalarda ürün ömür devri süresince mevcut veya yeni personel için tekâmül eğitimleri de ayrıca önceden planlanmış olmalıdır. Eğitim ve eğitim desteğine ilişkin faaliyetler kapsamında eğitim ihtiyacının analiz edilmesi, tasarlanması, geliştirilmesi, uygulanması ve denetlenmesi hususunda izlenecek süreç ve yaklaşımlar "[https://tssodypwiki.ssb.gov.tr/index.php/E%C4%9Fitim_ve_E%C4%9Fitim_%C4%B0htiya%C3%A7lar%C4%B1_Rehberi TSSÖDYP-13 Eğitim ve Eğitim İhtiyaçları Rehberi]"nde açıklanmıştır.

=== 3.6.8. TESİSLER VE ALTYAPI ===
Tesisler ve altyapı; bir ürünün entegrasyonu, işletilmesi ve desteklenmesi için gerekli olan sabit ve yarı sabit varlıklar veya mobil tesislerden oluşur.

Bu ELD elemanı; yeni tesis ve altyapının türleri (eğitim tesisi, ekipman/malzeme/tehlikeli madde deposu, bakım tesisleri, bilgisayar donanım/yazılım sistemleri/ağ ve iletişim sistemleri altyapısı vb.) veya mevcut tesis ve altyapılardaki iyileştirmeler, lokasyon, alan, çevre ve güvenlik gereksinimleri ve gerekli ekipmanların belirlenmesine yönelik faaliyetlerin tümünü içerir.

Tesis ve alt yapı planlaması; bütçeleme, tedarik veya inşaat sürelerinin çok uzun olabilmesi nedeniyle ürün ömür devrinde mümkün olan en erken safhada gerçekleştirilmeye çalışılmalıdır.

Bu kapsamda yürütülen başlıca faaliyetler aşağıdaki iki başlık altında verilmiştir:

'''Tesis ve Altyapı Analizlerinin Gerçekleştirilmesi'''

Bu analiz, ELDP veya diğer ELD elemanları tarafından ortaya konulan taleplerden kaynaklanan tesis ve altyapı gereksinimlerini belirler ve dokümante eder. Söz konusu tesis ve altyapı gereksinimleri en uygun çözümün temelini de şekillendirir. Çözüm oluşturulurken mevcut tesis ve altyapılar değerlendirilmelidir. Aynı zamanda, tesislerin bakımı ve envanterden çıkarma planları da düşünülmelidir.

'''Tesis ve Altyapının Sağlanması'''

Bu faaliyet; tesis ve altyapının geliştirilmesi, inşa edilmesi, tedarik edilmesi ve idame edilmesini kapsar. İnşaat ve benzeri altyapı faaliyetleri, karakteristik olarak üründen ayrı olmaları sebebi ile genellikle ayrı sözleşmeler altında yürütülür ve her birinin kendi ömür devirleri söz konusudur.

=== 3.6.9. PAKETLEME, ELLEÇLEME, DEPOLAMA VE ULAŞTIRMA (PEDU) ===
Malzeme yönetimi; ihtiyaç duyulan malzemeyi, ihtiyaç duyulan yere, ihtiyaç duyulan miktarda, uygun koşullarda, ihtiyaç duyulan sıklıkla, ihtiyaç duyulan şekilde yönlendirerek, ihtiyaç duyulan zamanda uygun yöntem kullanımı ile uygun maliyette sağlayan bilimdir. Bir ürünün bakım ve onarımı ile illişkili faaliyetlerin yanı sıra, ürünün kullanımı ve elleçlenmesi esnasında dikkate alınması gereken birçok ilave hususlar mevcuttur. PEDU, bir ürünün doğrudan kullanımı ve bakımı ile ilişkilendirilemeyen ancak ürünün uygun kullanımı açısından önem arz eden görevleri kapsar. Bu görevleri belirleyebilmek amacıyla Paketleme, Elleçleme, Depolama ve Ulaştırma (PEDU) analizleri gerçekleştirilir. PEDU analizi, PEDU görevlerinin ve bu görevlere ilişkin personel, destek ekipmanı, yedek parça ve sarf malzemeleri, tesis ve eğitim ihtiyaçlarının belirlenmesini kapsar. Analizlerin çıktıları PEDU Planı’nda dokümante edilir.

PEDU görevlerinin bir kısmı ömür devrinin erken safhalarında, diğer kısmı ise daha ileriki aşamalarda (örneğin bir prototip veya ürün ortaya çıktığı zamanlarda) dikkate alınmalıdır. Bu görevler, bütün ürün, teçhizat ve destek elemanlarının uygun şekilde muhafaza edilmesi, paketlenmesi, taşınması ve sevk edilmesini sağlayacak tasarım önlemleri, süreçler, kaynaklar ve prosedürlerin bütünüdür. Çevresel koşullar, uzun ve kısa dönem depolama şartlarına göre ekipmanın korunması gibi hususları da dikkate alır.

=== 3.6.10. BİLGİSAYAR KAYNAKLARI ===
Bilgisayar Kaynakları; görev kritik bilgisayar yazılım/donanım sistemlerinin işletilmesi ve desteği için ihtiyaç duyulan tesis, donanım, yazılım, iletişim, dokümantasyon, iş gücü ve personel ihtiyaçlarını kapsar. Amacı, görev kritik bilgisayar yazılım/donanım sistemlerininin tedariki ve yönetimi, idamesi ve güncellenmesi için gerekli olan kaynakların tespiti, planlanması, tahsisi ve kullanıma alımının gerçekleştirilmesidir.

Bu kapsamda aşağıda verilen iki temel faaliyet yürütülür:

'''Bilgisayar Kaynak Analizinin Gerçekleştirilmesi'''

Bu analiz, ELDP veya diğer ELD elemanlarının taleplerinden türetilen bilgisayar kaynak gereksinimlerini belirler ve dokümante eder. Yeni, modifiye edilmiş veya geliştirilmiş bilgisayar kaynaklarının yanı sıra mevcut bilgisayar kaynakları da bu analiz kapsamında göz önünde bulundurulmalıdır. Analiz, aynı zamanda bilgisayar kaynaklarının envanterden çıkarma planlamasını da (örneğin verinin arşivlenmesi) kapsamalıdır.

'''Bilgisayar Kaynaklarının Sağlanması'''

Bu faaliyet; bilgisayar kaynaklarının geliştirilmesi, üretilmesi, satın alınması, kurulması ve idame ettirilmesini kapsar. Sistem ömür devri safhaları boyunca hazırlanacak olan bilgisayar kaynakları raporu, yönetime bilgisayar kaynaklarının güncel durumu hakkında bilgi sağlar.

=== 3.6.11. İDAME MÜHENDİSLİĞİ ===
Bu ELD elemanının amacı, kullanımda olan ürünleri bulundukları operasyonel çevre koşullarında desteklemektir. Bu faaliyet envanterde bulunan ve/veya envantere alınan bir sistemin kullanımı ve desteklenmesi için gerekli olan tüm teknik görevleri kapsar (mühendislik ve lojistik incelemeler, analizler vb). İdame Mühendisliği, sistemin kullanım ömrü boyunca kusurlarının belirlenmesi, gözden geçirilmesi, değerlendirilmesi ve çözüme kavuşturulmasını içerir. Yapılan çalışmaların çıktıları geri bildirim bilgisi ve tasarım eksikliklerini ele alan veya desteklenebilirlik tasarım faktörlerini geliştiren mühendislik değişiklikleri şeklinde tasarıma yönelik değerlendirme ve önerilerdir.

İdame Mühendisliği çalışmaları hem sistemi ana hat çekilmiş konfigürasyon ve kabiliyetlerine geri çevirir hem de performans ve kabiliyetleri iyileştirmek için fırsatları belirler. Sistemin teknik ve desteklenebilirlik açısından kusurlarının belirlenmesi, ölçülmesi, doğrulanması, ilişkili kök neden analizleri, kusurun düzeltilme potansiyelinin değerlendirilmesi ve bir dizi düzeltici işlem seçeneğinin geliştirilmesi, bu amaçla yapılan çalışmalardır. Bu çalışmalar aynı zamanda, seçilen düzeltici işlemlerin konfigürasyon ve bakım süreçlerinde uygulanmasını ve anahtar idame metriklerinin izlenmesini de kapsar.

İdame mühendisliği faaliyetleri aşağıda verilen iki ana başlık altında toplanabilir:

'''Hata ve Kusurların Belirlenmesi ve Teknik Analizlerin Gerçekleştirilmesi'''

Bu aktivite bir hata/kusura ilişkin hususları belirlemek için yürütülen bilimsel çalışmalardan oluşur. Bu kapsamda aşağıda sıralanan türden çalışmalar gerçekleştirilir:

* Bütün kullanım ve bakım verilerinin toplanması ve öncelik sınıflandırılmasının yapılması,
* Çevre ve emniyet tehditlerinin, hata türleri ve etkilerinin, güvenilirlik ve idame edilebilirlik eğilimlerinin, kullanım profil değişikliklerinin analiz edilmesi,
* Hizmet içi problemlere dair (operasyonel tehditler, hata/kusur raporları, parça demodeliği, korozyon etkileri, güvenilirliğin azalması vb.) kök neden analizlerinin gerçekleştirilmesi,

Yapılan çalışmaların sonuçlarına dair elde edilen bilgiler geri bildirim olarak ilgili taraflara mutlaka aktarılmalıdır.

'''Çözümlerin Geliştirilmesi'''

İdame metriklerini iyileştirecek şekilde; hata/kusurların değerlendirilmesi ve sorunların düzeltilmesi, iyileştirilmesi veya sonlandırılması için gereken işlemlerin yapılması ve önerilen ürün modifikasyonunun geliştirilmesi, bu kapsamda gerçekleştirilen faaliyetlerdir. Bu faaliyetlerin çıktısı mühendislik değişiklik teklifleridir.

=== 3.6.12. ÜRÜN DESTEK YÖNETİMİ ===
Ürün Destek Yönetimi (ÜDY); bütün ELD elemanlarını kapsayacak şekilde ürün desteğinin planlanması, yönetilmesi ve finanse edilmesini kapsar. Destek konseptinin ve ELDP’nin hazırlanması, geliştirilmesi ve detaylandırılmasının yanı sıra demodelik planının hazırlanması ve raporunun oluşturulması da bu ELD elemanı bünyesinde gerçekleştirilen faaliyetlerdendir. ÜDY, belirli bir sistem veya hizmet için ELD ihtiyaçlarının detaylandırıldığı ELD elemanıdır. Bu doğrultuda aşağıda dört alt başlıkta verilen temel faaliyetler gerçekleştirilir.

'''Ürün Destek Gereksinimlerinin Toplanması'''

Lojistik destek gereksinimlerinden türetilen destek konsepti, lojistik desteğin temel çerçevesini tanımlar. Destek konsepti; lojistik desteğin planlanması, yürütülmesi ve dokümante edilmesinin yanı sıra ürünün hizmete alınması, kullanılması, planlı/plansız bakımlarının yapılması (bakım/onarım) ve envanterden çıkarılmasına da esas teşkil eder. Destek konsepti operasyonel gereksinimler ve kullanım senaryoları esas alınarak belirlenir ve ürünün ömür devrine yönelik stratejiler ve temel lojistik gereksinimleri tanımlar.

Destek konsepti; kullanıma hazır olma, güvenilirlik, idame edilebilirlik, desteklenebilirlik ve test edilebilirlik gibi faktörleri içerir. Aynı zamanda, farklı destek alternatifleri içerip, bu alternatiflerin gerekli kaynaklar, mali etkileşimler ve ilişkili riskler açısından değerlendirilmesini de öngörebilir.

ÜDY, destek konseptininin geliştirilmesi ve destek gereksinimlerinin tanımlanmasından sorumludur. Bu kapsamda; sözleşme, şartname, gereksinim tanımlama dokümanı, tasarım mühendislik verileri vb. dokümanlar kullanılarak;

* Destek konseptinin belirlenmesi ve geçerli kılınması için uygun ödünleşim analizlerinin yapılması,
* Bütün ELD elemanlarının birbiriyle entegre şekilde yönetilmesi sağlanır.

'''ELDP Hazırlanması'''

ELDP; savunma ve güvenlik sistemlerinin lojistik ihtiyaçlarına yönelik ELD elemanlarının bütünleşik olarak yönetimine ilişkin planlanma, uygulanma ve koordinasyon faaliyetlerini içeren dokümandır. Uygun ELD elemanlarına ilişkin planlama ve uygulamaya yönelik detaylar ELDP’de yer alır.

ELDP şablonu Ek’te verilmiştir.

'''Demodelik Yönetiminin Gerçekleştirilmesi'''

Bu faaliyet; demodelik stratejisinin belirlenmesi, Demodelik Yönetim Planı’nın geliştirilmesi ve demodelik çözümlerinin uygulanmasını içerir. Bu faaliyetlerin sonuçları bir Demodelik Raporu (araştırma verileri, risk analiz verileri ve ilgili düzeltme adımları vb.)’nda derlenir. (Bkz. [https://tssodypwiki.ssb.gov.tr/index.php/Sistem_%C3%96m%C3%BCr_Devri_Y%C3%B6netiminde_Demodelik_Y%C3%B6netimi_Rehberi TSSÖDYP-08 Sistem Ömür Devri Yönetiminde Demodelik Yönetimi Rehberi])

'''Lojistik Destek Sözleşmesinin Yönetilmesi'''

Bu faaliyet; mevcut tedarik sözleşmesine uyum ve sözleşmenin yönetilmesine katkı sağlar, alt sözleşmelerin ve destek sözleşmelerinin oluşturulmasını kapsar, çıktıları yönetim raporları ve ürün destek sözleşmeleridir.

Lojistik destek sözleşmesi, bir ürünün işletilmesi ve desteklenmesi için ihtiyaç duyulan mal ve hizmet alımına yönelik sözleşmedir.

Yönetim raporları ise ürün destek yöneticisi tarafından oluşturulan herhangi bir idari rapor olup bunlarla sınırlı olmamak kaydıyla aşağıdaki hususları içerebilir:

* ELD programı ana kilometre taşı takvimi
* Lojistik unsurlar için uygulama takvimi
* İş Tanımı ile kıyaslandığında her bir lojistik unsurun mevcut durumu.

Raporlandırma sistemi, projeye bağlı olup, proje özel raporlandırma gereksinimlerine yönelik standart bir çözümü yoktur.

= 4. LOJİSTİK DESTEK ANALİZİ (LDA) =
LDA çalışmalarında [https://tssodypwiki.ssb.gov.tr/index.php/Lojistik_Destek_Analizleri_ve_Kay%C4%B1tlar%C4%B1_Rehberi TSSÖDYP-06 Lojistik Destek Analizleri ve Kayıtları Rehberi] esas alınacak olup LDA’ya ilişkin genel bilgiler aşağıda verilmiştir.

LDA, sistemin/bileşenin belirlenmiş sürdürülebilirlik ve kullanıma hazır olma ihtiyaçlarına ulaşılmasına yönelik desteklenebilirlik gereksinimlerini değerlendiren ve ürün tasarımı ile destek sistemi gereksinimlerini entegre eden sistematik ve yinelemeli (iteratif) bir süreçtir.

LDA lojistik destek faaliyetlerinin maliyet etkin olarak yürütülmesinde yol gösterici en önemli faaliyettir. Tüm lojistik destek faaliyetlerinin teknik disiplin içinde maliyet etkin olarak planlanması, koordine edilmesi ve yönetilmesi için LDA rehberliğinde:

* Ürün ve ELD elemanları; desteklenebilirlik, güvenilirlik, test edilebilirlik ve uygun ÖDM ile tasarlanır,
* Kullanım ve Destek Safhaları boyunca ürünün istenilen performans seviyesinde kullanılabilmesi için ihtiyaç duyulan kaynaklar tanımlanır,
* ELD elemanlarına ilişkin esas bilgiler oluşturulur.

LDA, sistem mühendisliği süreçleri paralelinde gerçekleştirilen geniş bir analizler kümesini içerir. Söz konusu analizlerin amacı, desteklenebilirliğin sistem performans gereksinimlerine dahil edilmesinin sağlanması, sistemin en uygun destek sistemi ve alt yapı ile birlikte geliştirilmesi ve tedarik edilmesidir. LDA etkin ve verimli bir destek çözümünün tasarlanması ve geliştirilmesine yönelik çeşitli analitik tekniklerin entegrasyonunu ihtiva eder.

LDA’nın amaçlarından biri karmaşık teknik ürünler için kullanım ve destek safhaları boyunca en uygun lojistik desteğin sağlanmasıdır. Lojistik destek gereksinimlerini tanımlama, analiz etme ve niceliklerini belirlemenin yanı sıra, sistem geliştirme safhasında desteklenebilir bir tasarım ortaya çıkarmaya yönelik faaliyetleri içerir.

== 4.1. LDA FAALİYETİ, ROLLER VE SORUMLULUKLAR ==
LDA faaliyeti Şekil 9’da gösterildiği şekilde aşağıda sıralanan amaçlara yönelik olarak niceliksel bazı analiz yöntemlerinin seçilmesi ve uygulanmasını içeren bir süreçtir:

* Sistem tasarımına girdi sağlamak üzere lojistik kriterlerin belirlenmesi ve oluşturulması,
* Farklı tasarım alternatiflerinin değerlendirilmesi,
* Lojistik destek elemanlarının belirlenmesi ve tedariği,
* Kullanım esnasında sisteme yönelik destek kabiliyetinin değerlendirilmesi.
[[Dosya:Şekil10 Temel LDA Süreci.jpg|alt=Şekil 10 Temel LDA Süreci|sol|küçükresim|698x698pik|Şekil 10 Temel LDA Süreci]]

Ürün geliştirme süreçlerinde paydaş temsilcilerinden oluşan farklı disiplinlere mensup personelin katılımı ile Entegre Ürün Takımları (EÜT) oluşturulabilir. EÜT’ler gözetim seviyesinde olabileceği gibi doğrudan geliştirme sürecinin içinde görev yapacak şekilde de olabilir. Özellikle sistem mühendisliği çalışmalarında EÜT’lerin görüşleri ve katkıları önem kazanır. Ayrıca EÜT’lerin oluşturulmasına ihtiyaç duyulmadığı durumlarda, Program/proje yönetiminden sorumlu olan gruplar EÜT mantığı ile çalışacak şekilde teşekkül ettirilebilir. EÜT liderleri, ilgili ürününün geliştirilmesinden ve bütçesinden sorumludur. ELD yöneticilerinin görevi projeler kapsamında ürün geliştirme ekiplerine lojistik destek ve desteklenebilirlik konularında uzmanlık desteği ve imkân sağlamaktır.

LDA programı kapsamında destek sisteminin geliştirmesinden sorumlu bir lojistik ekibi olması tavsiye edilir. Bu ekip, ürünün tasarımı, geliştirilmesi, üretimi, kullanılması ve desteğinden sorumlu EÜT’nin bir parçası olmalıdır Bu anlamda EÜT’lere atanan lojistik ve desteklenebilirlik uzmanları/personeli ekip içinde aşağıda sıralanan faaliyetlerden sorumlu olacaktır:

* Güvenilirlik, idame edilebilirlik, test edilebilirlik, insan mühendisliği, cihaz içi test (CİT) ve çevresel uygunluk gibi konularda girdi sağlayarak sistem ve destek sistemi tasarımına desteklenebilirlik karakteristiklerinin katılmasını sağlamak,
* Destek sistemini ve eğitim sistemini geliştirmek ve lojistik destek kaynaklarını (ikmal destek, destek ekipmanı, teknik veri, tesisler, PEDU, iş gücü ve personel, eğitim ve eğitim teçhizatı) planlamak, geliştirmek ve sunmak,
* Ürün geliştirme sistem mühendisliği ve tasarım mühendisliği süreçleri içinde lojistik mühendisliği faaliyetlerini gerçekleştirmek,
* LDA, standardizasyon, değiştirilebilirlik ve birlikte çalışabilirlik sağlamak,
* LDA sorumlusu/lideri ile ELD yöneticisi ve diğer işlevsel yönetim sorumluları arasındaki koordinasyonun ve arayüzlerin oluşturulması ve sürdürülmesi LDA programının başarısı açısından büyük önem taşır. Ayrıca, etkin bir ELD/LDA program yönetimi açısından hem müşteri hem de yüklenici bünyesinde bir ELD/LDA organizasyonu oluşturulması gereklidir.

Desteklenebilirliğin entegre ürün geliştirme proje organizasyonuna dahil edilmesi aşağıda sıralanan lojistik yönetim hedeflerine ulaşılmasını sağlar:

* Tasarım ve test verilerinin değerlendirilmesi, desteklenebilirlik alternatifleri ve ödünleşim analizi değerlendirmelerinin tasarıma yansıtılması,
* Detaylı şartname isterlerinin oluşturulması,
* Lojistik kaynak planlamasının gerektiğinde uyarlanabilirliğinin sağlanması,
* Operasyonel kullanıma hazır olma ve göreve hazır olma eşik değerlerine ilişkin gereksinimlerin karşılanması,
* Ürünün beklenen operasyonel çevre koşullarında desteklenebilirliğinin temini,
* Destek sisteminin beklenen performansı sağlaması,

Lojistik yönetimi hedeflerine ulaşabilmek için ise uygun bir organizasyon oluşturulmalıdır. Bu doğrultuda:

* Lojistik mühendisliğinin aktif katılımının ve tasarıma etkisinin en üst düzeyde tutulduğu bir entegre ürün geliştirme organizasyonu oluşturmak,
* ELD sürecini tasarım mühendisliği ve sistem mühendisliği ile sürekli etkileşim içinde olacak şekilde yapılandırmak,
* Ürünü geliştirirken müşteri ve tedarikçilerle yakın şekilde çalışma yapılması gerekir.

Lojistik yönetim hedeflerinin karşılanabilmesi için oluşturulacak LDA sürecinde;

* Tasarıma desteklenebilirlik gereksinimlerini entegre etmeye yönelik LDA prosedürlerinin tanımlanması,
* Destek sistemi konfigürasyonunun ürün tasarım konfigürasyonu ile uyumlu olmasının sağlanması,
* Detaylı bakım planlama ve toplam lojistik kaynak gereksinimlerinin tümevarım yöntemiyle belirlenmesinin sağlanması,
* Lojistik Destek Analizi Kayıtları (LDAK)’nın tutulacağı veritabanının oluşturulmasının sağlanması gerekir.

== 4.2. LDAK YÖNETİMİ ==
LDA süreci sonunda ortaya çıkan veriler, mühendislik ve ürün destek faaliyetleri tarafından kullanımlarını sağlamak için belirli biçimlere uyarlanır ve kayıt altına alınır. Bu veriye “Lojistik Destek Bilgisi” adı verilir ve çeşitli endüstri standartlarına uygun olarak oluşturulan veri tabanı ise “LDAK” olarak adlandırılır.

Sözleşmelerde yer verilen LDAK gereksinimleri, planlanan destek konsepti ile uyumlu ve uyarlanmış içerikte olmalıdır. İhtiyaç makamı, uyumsuzlukları ve gerekenden fazla yapılabilecek sözleşmesel teslimatları önleyebilmek için programın çeşitli işlevsel alanlarından gelecek verilere yönelik gereksinimleri koordine etmelidir. LDAK, nihayetinde ürün destek yöneticisine bütün ELD unsurlarını dikkate alan etkin bir ürün destek paketi oluşturmakta yardımcı olur.

“Lojistik Destek Analizi Veri Tabanı” bir nevi, yapılan lojistik destek analizi kayıtlarının toplandığı kütüktür.

= 5. SİSTEM MÜHENDİSLİĞİ FAALİYETLERİ VE ELD =
Sistem Mühendisliği''';''' yetenek ihtiyacına cevap verebilecek karmaşık sisteme ait isterlerin oluşturulması, bütünleşik bir anlayışla ömür devri süresince birbiri ile uyum içinde çalışacak alt sistem çözüm setlerinin geliştirilmesi ve bunların doğrulanmasıdır. İhtiyacın tanımlanması aşamasında, fonksiyonel olarak tariflenen yeteneğin fiziksel gereksinimlere dönüşümü sürecinde; ihtiyaç duyulacak destek amaçlı ürünler ve geliştirme, üretim/inşaat, konuşlandırma, kullanım, destek, envanterden çıkarma, eğitim ve doğrulama süreçlerini de kapsayan tüm ürünleri içeren sistem mimarisi, anlaşılabilirliği arttırarak doğru çözüme erişmede yardımcı olur.

Tedarik lojistiğinin temel amaçlarından birisi destek gereksinimlerinin sistem tasarım gereksinimlerinin ayrılamaz bir parçası olmasını sağlamaktır. Bu kapsamda yürütülecek proje faaliyetleri ancak eş zamanlı olarak hem yüklenici, hem de kullanıcı ve tedarik makamı tarafından, sistem mühendisliği teknik ve idari faaliyetleri ile bütünleşik vaziyette yürütülmesi halinde hedefine ulaşabilir.

Lojistik planlama; sistem mühendisliği sürecinin bir parçası olup, bu süreç sağlıklı işletilmeksizin projenin nihai hedeflerine erişilmesi söz konusu olamaz.

Sistem geliştirme sürecinin amacı; müşteri ihtiyaçlarını karşılayacak en uygun sistemi, fiziksel kısıtlamalar, zaman, performans ve maliyet kriterlerini göz önüne alarak geliştirmektir. Sistem ile kastedilen, kullanıcı ve diğer paydaşların yararına olan ürün ve hizmetleri, tanımlanmış olan çevre şartlarında sağlamak için insan tarafından meydana getirilen ve kullanılan yapılardır. Sistemi oluşturan bileşenler; donanım, yazılım, veri, insan, süreç, prosedür ve talimat, tesis, malzeme vb. olabilir. ELD faaliyetleri ve ilgili ürünler sistemin teknik karmaşıklığına, değişkenliğine, maliyetine vb. faktörlere bağlı olarak farklılık gösterir. Ürünün özelliği ve bulunulan ömür devri safhasına göre uygun ELD elemanları sistem mühendisliği sürecine dahil edilir.

İhtiyaca cevap verebilecek karmaşık bir sistemin meydana getirilmesi; bütünleşik bir anlayışla ömür devri süresince birbiri ile uyum içinde çalışacak alt sistem çözüm setleri geliştirilmesi ve doğrulanmasını gerektirir. Sistem mühendisliği bu kapsamda aşağıda verilen başlıca faaliyetleri yürütür:

* Teknik faktörlerin planlanması ve organizasyonu,
* Sistemin idamesi için ömür devri boyunca ihtiyaç duyulacak hususların dikkate alınması,
* İhtiyacın tanımlanması aşamasında fonksiyonel olarak tariflenen yeteneğin teknik gereksinimlere dönüşümü,
* Teknik gereksinimleri karşılayabilecek elde edilebilir sistem çözümü alternatiflerinin üretilmesi,
* Destek sisteminin de tanımlandığı toplam sistem çözümlerinin değerlendirilmesi,
* Karar verilen çözümün gerçeklenmesi ve uygulanması,
* Çözümün doğrulanması.

Sistemin idamesi için ömür devri boyunca ihtiyaç duyulacak hususların dikkate alınabilmesi için farklı disiplinlerden uzmanlaşmış ekiplerin, ihtiyaç makamının, tedarik makamının, kullanıcıların ve idame makamının da sürece dahil olması gerekir. Lojistik konusunda uzmanlaşmış bir ekibin bu süreçlerde yer alması ve odak sistem ile birlikte destek sisteminin fonksiyonel, sistemsel ve fiziki gereksinimlerinin belirlenmesinde rol alması zorunludur (Bkz. [https://tssodypwiki.ssb.gov.tr/index.php/Entegre_Lojistik_Destek_(ELD)_%C4%B0sterleri_Haz%C4%B1rlama_Rehberi TSSÖDYP-05 Entegre Lojistik Destek İsterleri Hazırlama Rehberi]).

= 6. PROGRAM/PROJE YÖNETİMİ VE ELD =
Programlama; planlama ile belirlenen hedeflerin kaynaklar bazında nasıl gerçekleştirileceğinin bir zaman boyutu üzerinde projelendirilmesi işlemidir. Program/proje ise belli kriterler içinde tamamlanacak belirlenmiş bir hedefi, başlangıcı ve sonu olan, sınırlı para ve tüketim kaynakları (zaman, personel ve teçhizat) bulunan birbiri ile ilgili bir dizi faaliyetler ve görevlerdir. Programların daha kapsamlı olarak ömür devrinini tamamını dikkate alacak şekilde kurgulanması gerekir.

Operasyonel ihtiyaçların giderilmesi, gerekli donanım, yazılım ve destek unsurlarının en ekonomik şekilde bir araya getirilmesi sonucunda oluşan sistem ile gerçekleştirilir. Program başlangıcında, sistemin tüm unsurlarının ve bunlar ile ilgili gereksinimlerin yeterli seviyede ve doğru tanımlanmış olması vazgeçilmez bir şarttır.

Talep edilen performans gereksinimlerine cevap verebilecek sistem tasarım özelliklerinin; ömür devri maliyet, bütçe, takvim ve performans özellikleri ile optimum noktada birleşebilmesi ilgili program organizasyon birimlerinin koordineli ve eşzamanlı çalışması ile sağlanabilir.

Belirgin bir hedefe yönelik olarak; bir ana sistem veya teçhizatın harekât ihtiyacı olarak belirlendiği andan, hizmet dışı bırakıldığı zamana kadar olan sürede mevcut kaynakların planlanması, proje yönetiminin ve ofisinin teşkilatlandırılması, faaliyet programının disiplini ile projenin gerçekleştirilmesi için bilgi, beceri, araç ve tekniklerin proje faaliyetlerine uygulanmasıdır. Buna ömür devri program yönetimi adı verilmektedir. Zaman, maliyet ve performans programın/projenin başlıca kısıtlarıdır.

İhtiyaç duyulan performans gereksinimlerine cevap verebilecek odak sistem ve destek sistemi tasarım özelliklerinin ömür boyu maliyet, bütçe, takvim ve performans özellikleri ile optimum noktada birleşebilmesi, ilgili program organizasyonel birimlerinin koordineli ve eşzamanlı çalışması ile sağlanabilir. Desteklenebilirlik gereklerinin tasarıma dahil edilmesi ve ömür boyu maliyet hedefinin erişilebilmesi, tasarım birimlerinin operasyonel ihtiyacın tanımlanmasından itibaren desteklenebilirlik hedeflerine yönlendirilmesini gerektirir. Bunun için ELD isterlerinin anlaşılır, açık ve ölçülebilir şekilde tespit edilmiş olması gerekir ([https://tssodypwiki.ssb.gov.tr/index.php/Entegre_Lojistik_Destek_(ELD)_%C4%B0sterleri_Haz%C4%B1rlama_Rehberi TSSÖDYP-05 Entegre Lojistik Destek İsterleri Hazırlama Rehberi]).

Program başlangıcında, sistem desteklenebilirliğine ait hedefleri ve gerekleri analiz etmek, tanımlamak ve doğrulamak için ihtiyaç duyulan tüm desteklenebililik analizleri planlanır. Bu kapsamda yürütülecek faaliyetlerde [https://tssodypwiki.ssb.gov.tr/index.php/Lojistik_Destek_Analizleri_ve_Kay%C4%B1tlar%C4%B1_Rehberi TSSÖDYP-06 Lojistik destek Analizleri ve Kayıtları Rehberi] referans olarak alınır.

Her bir program için desteklenebilirlik ile ilgili hedefler ve analizler, en az aşağıdaki hususların dikkate alındığı bir strateji ile belirlenir:

* Kullanıma/Göreve Hazır Olma gereği,
* Donanım ve yazılım tasarım öngörüleri,
* Kullanım konsepti ve barış/savaş operasyonel gereksinimleri,
* Destek konsepti,
* Tahmini Güvenilirlik ve İdame Edilebilirlik değerleri,
* Tahmini ÖDM, Maliyet Kategorileri (Ar-Ge, Üretim, İşletme-Destek, Envanterden Çıkarma)
* Lojistik destek kaynak gerekleri,
* Desteklenebilirlik analizlerini yürütebilmek için gerekli lojistik destek verisi,
* Mevcut saha verileri, mevcut sistemlerin performans değerlendirmeleri, desteklenebilirlik, maliyet ve göreve hazır olma oranlarında tahmini iyileşme değerleri,
* Program risklerindeki azalmaları da kapsayacak biçimde, analizlerin uygulanmasının tasarım üzerindeki olası etkileri,
* Herbir desteklenebilirlik analizinin tahmini maliyeti.

Desteklenebilirlik analizlerinin kapsamını etkileyecek bir diğer husus, projenin bulunduğu aşama ya da görev sistemi tasarım konseptidir. Tasarım yoğun projelerde, desteklenebilirlik analizleri tasarıma girdi sağlarken tasarım çıktıları destek planlamasında kullanılır. Alternatif destek sistemi çözümleri yanı sıra görev sistemi tasarımına yönelik alternatifler (tasarım, ticari, hazır ürün) değerlendirilir. RAHAT (Rafta Hazır Ticari/COTS/Commercial Of The Shelf) ya da tasarım gerektirmeyen çözümlerde, desteklenebilirlik analizleri destek sistemi üzerine yoğunlaşır.

Tasarımı tamamlanmış ürünlerin yeni projelerde kullanılması sürecinde, ürünün sisteme ait diğer unsurlar ile uyumlu olması konusu başlangıçta sorgulanmalıdır.

Ticari destek çözümleri söz konusu ise, desteklenebilirlik analizleri ticari destek altyapısı ile arayüzlerin tanımlanması konusuna yoğunlaşır.

İyileştirme projelerinde, tasarım esnekliği desteklenebilirlik analizlerinin kapsamını belirleyen başlıca unsurdur.

Desteklenebilirlik ile ilgili hususlar, sistem mimarisi ile ilgili kararlar verilirken mutlaka göz önünde tutulmalıdır.

Desteklenebilirlik ihtiyaçlarının ya da gereklerinin sözleşme ve ekleri ile tanımlanmamış olduğu ya da türetilmesi için yeterli bilgiye sahip olunmadığı durumlarda, aşağıda belirtilen hususlar dikkate alınmak suretiyle desteklenebililik gerekleri oluşturulur ve bunların tasarım sürecinde dikkate alınması sağlanır.

* Tedarik/ihtiyaç makamlarının prensipleri dikkate alınır. Yerlileştirme/ Millîleştirme çalışmaları için [https://tssodypwiki.ssb.gov.tr/index.php?title=Kullan%C4%B1m_ve_Destek_%C4%B0htiya%C3%A7lar%C4%B1_%C3%87er%C3%A7evesinde_Yerlile%C5%9Ftirme/Millile%C5%9Ftirme_Rehberi&redirect=no TSSÖDYP-09 Kullanım ve Destek İhtiyaçları Çerçevesinde Yerlileştirme/Millîleştirme Rehberi] referans doküman olarak kullanılır.
* Mevcut benzer sistemlerin veya ekipmanların kullanımı sürecinde edinilmiş tecrübeler ve kayıtlara dayalı yapılan analizler, tahmin ve öngörülere dayalı gereksinim belirleme yöntemine göre daha kesin ve doğru sonuçlar verecektir. Tecrübeler, analizler ve kayıtlar ELD birimleri başta olmak üzere ilgili birimlerden sorgulanır. Eğer tecrübeye dayalı veri mevcut değilse, özellikle yüksek risk öngörülen alanlarda, analizlere temel olabilecek verilerin temin edilmesine yönelik faaliyetler yürütülür.

* Standartlara dayalı gereksinimler yerine performans gereksinimlerinin tanımlanması tasarımcılara daha geniş hareket alanı sağlayabilir. Bu yöntem uygun görülmesi durumunda kullanılır.
* Gereksinimler değişken kullanım profilleri (barış ve savaş şartları gibi) için ayrı ayrı belirlenir.
* Desteklenebilirlik analizlerinin yapılması için gerekli zaman ve kaynak miktarı öngörülür. Sonuçları tasarım kararlarına etki edemeyecek kadar uzun zamanda elde edilebilecek analizlere ihtiyaç duyan desteklenebilirlik gereksinimlerinin ortaya konması anlamlı değildir. Bunun istisnası; ileriye yönelik planlı ürün iyileştirme faaliyetleridir. Desteklenebilirlik analizleri sonucunda elde edilecek fayda; desteklenebilirlik unsurlarının görev sistemi performans gerekleri içinde yer almış olması ve destek sisteminin, görev sistemi ile eşzamanlı olarak geliştirilmesinin sağlanmasıdır.
* Desteklenebilirlik gereksinimlerinin belirlenmesinde uluslararası rekabet şartları dikkate alınır.
* Desteklenebilirlik gereksinimlerinin belirlenmesi tekrar eden yapıda bir faaliyettir. Desteklenebilirliği etkileyen unsurlar (özellikle insan ile bağımlı unsurlar) değişken bir yapıya sahip olup, sistem ömür devri içinde dahi dikkate alınması gerekli değişimler olabilir. Ürün ömür devri boyunca, desteklenebilirliği etkileyen unsurlar sürekli gözlenmeli ve gereksinimler güncellenmelidir.
* Desteklenebilirlik gereksinimleri maliyet olarak erişilebilir olmalıdır.
* Tedarikçiler, sağlanacak desteğin ayrılmaz bir parçasıdır. Program yöneticisi, lojistik destek ve desteklenebilirlik açısından tedarikçi adaylarını periyodik olarak değerlendirmelidir.

== 6.1. SİSTEM ÖMÜR DEVRİ SAFHALARI VE ELD ==
[https://tssodypwiki.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)] ve [https://tssodypwiki.ssb.gov.tr/index.php/Sistem_%C3%96m%C3%BCr_Devri_Y%C3%B6netimi_S%C3%BCre%C3%A7leri_Rehberi TSSÖDYP-02 Sistem Ömür Devri Yönetimi Süreçleri Rehberi] referans dokümanlar olarak kullanılır.

'''Ön Konsept ve Konsept Safhaları'''

TSSÖDYP-05 Entegre Lojistik Destek İsterleri Hazırlama Rehberi, ön konsept ve konsept safhalarında ihtiyaç makamlarının hazırlayacakları Proje/İhtiyaç Tanımlama Dokümanı (PTD vb.) ve ekleri ile Teklife Çağrı Dokümanı (TÇD)’de savunma ve güvenlik sistemlerinin lojistik destek isterlerinin belirlenmesinde kullanılacak rehberdir.

Bu safhalarda sistem tasarım alternatifleri risk ve maliyetler açısından değerlendirilir. Bu kapsamda, işletim ve bakım konsept alternatifleri, destek sistemi alternatifleri, görev sistemi tasarım alternatifleri ile ilgili risk ve maliyet analizleri yapılır, fonksiyonel kırılım üst seviyeleri için performans ihtiyaçları belirlenmeye çalışılır.

Üzerinde çalışılmış olan alternatif destek sistemi çözümleri ve konseptlerin Sistem çözümü içindeki diğer desteklenebilirlik unsurları ile uyumu ve sistemin ÖDM’ye etkisi değerlendirilir. Seçilen destek sistemi ve konsept, başlangıç destek planlarının ve gereklerinin oluşturulmasına temel teşkil eder. Desteklenebilirliği etkileyebilecek performans gereklerinin bu safhalarda tanımlanması önemlidir.

Konsept safhasının sonunda ürün detstk stratejisinin ve modelinin belirlenmesi ve müteakip safhalardaki gelişmelere göre güncellenebilir/geliştirilebilir durumda olması gerekir. ([http://ssbwiki.ssb.gov.tr/index.php/%C3%9Cr%C3%BCn_Destek_Stratejileri_ve_Modelleri_Rehberi TSSÖDYP-03 Ürün Destek Startejileri ve Modelleri Rehberi])

'''Geliştirme Safhası'''

[https://tssodypwiki.ssb.gov.tr/index.php/Lojistik_Destek_Analizleri_ve_Kay%C4%B1tlar%C4%B1_Rehberi TSSÖDYP-06 Lojistik Destek Analizleri ve Kayıtları Rehberi], ELD faaliyetlerinin merkezinde yer alan LDA’nın gerçekleştirilmesi ve bu analizler sonrasında oluşturulacak LDA Kayıtları konusunda hazırlanmış bir dokümandır.

Bu safhada desteklenebilir ve ekonomik olarak elde edilebilir bir odak sistem tasarımı faaliyetlerine katılım sağlanır.

Tasarım faaliyetleri kapsamında LDA faaliyeleri destek sisteminin tasarlanması/organizasyonu konususuna odaklanır. Odak sistem tasarımında olabilecek değişiklikler destek sisteminin tasarımında da dikkate alınır. Sistem tasarımı lojistik destek yapısını ve lojistik ihtiyaçlar da sistem tasarımını etkilemektedir. Burada en önemli husus lojistik destek isterlerinin odak sistem tasarımı üzerinde bir etkiye sahip olmasıdır.

LDA’da, sistem tasarımına etki eden en az aşağıdaki faktörler göz önünde bulundurulur.

* Kullanıcının genel hususlara ilişkin isterleri,
* Kullanıcının güvenilirlik, hazır bulunuşluk ve desteklenebilirlik isterleri,
* Benzer sistemlerin saha (kullanım ve lojistik destek) verileri,
* İdarenin sistemle ilgili kullanım, bakım ve tedarik konseptleri/yönergeleri,
* Sistem ömür devri kullanım senaryoları (kullanım, depolama, taşıma vb.)
* Muharebe alanının coğrafi ve atmosferik şartları,
* Güvenlik ve emniyet gereksinimleri,
* Modülerlik gereksinimi,
* İstenen ürünün yapılabilirliğine yönelik mevcut teknolojik imkânlar,
* Yüklenicinin imkân ve kabiliyetleri,
* Standardizasyon ve diğer sistemler ile uyumlu çalışabilirlik gereksinimi,
* Test edilebilirlik gereksinimi,
* Ergonomi (insan faktörü) gereksinimi,
* Lojistik destek faaliyetlerinde maliyet etkinlik,
* Demodelik gereksinimi,
* Onarılabilirlik ve modernize edilebilirlik gereksinimleri,
* Modernizasyon gereksinimi,
* Ömür durum tespiti ve uzatımının yapılabilirlik gereksinimi.

Benzer sistemlerden elde edilen kullanıcı verileri ile mevcut imkân ve yetenekleri yeni sistemin tasarımına aktarılması maksadıyla tasarım süreci başlatılmadan yüklenici ve ELD çalışma grubu tarafından kullanıcı tesislerinde inceleme yapılmalıdır. Bu kapsamda aşağıdaki hususlarda inceleme yapılır ve kullanım çalışması raporu hazırlanır.

1. Benzer sistemlerin:

1.1. Harekât/operasyon görevi,

1.2. Taktik ve teknik özellikleri,

1.3. Ürün ağacı ve alt parçaların fonksiyonel görevleri,

1.4. Zaafiyetleri ve üstünlükleri,

2. Mevcut lojistik destek imkân ve yetenekleri:

2.1. Bakım konsepti ve yapısı,

2.2. İkmal desteği konsepti ve yapısı,

2.3. Personel durumu (miktar ve nitelik),

2.4. Destek ve test ekipmanları,

2.5. Teknik veri ve dokümantasyon oluşturma konsepti,

2.6. Eğitim konsepti, eğitim destek ve eğitim yardımcı malzemeleri,

2.7. Tesisler ve altyapı,

2.8. Paketleme, elleçleme, depolama (alanları, şartları vb.) ve ulaştırma,

2.9. Bilgisayar Kaynakları,

2.10. İdame Mühendisliği,

2.11. Ürün Destek Yönetimi,

3. Çevresel, coğrafi ve atmosferik şartlar,

4. Ömür devri kullanım, depolama ve ulaştırma senaryoları (süre, mesafe ve şartları),

5. Konfigürasyon yönetimi yapısı,

6. Aktarma ve elden çıkarma konsepti,

7. Standardizasyon yaklaşımı,

8. Demodelik yönetimi yaklaşımı,

9. Modülerlik yaklaşımı ve parçaların birbirleri yerine kullanılabilirlik gereksinimi,

10. Emniyet ve güvenlik gereksinimleri,

11. Kullanım ve lojistik destek sürecinde elde edilen tecrübeler,

12. Kullanım ve lojistik destek faaliyetlerinden sorumlu personelin teklif ve önerileri,

13. Garanti süreci yönetimi,

14. Sistemin konuşlandırılma şartları ve esasları.

Sistem tasarımı kapsamında yapılan faaliyetlerin etkinliği, sistemin kullanım ve destek safhalarındaki performansını doğrudan etkileyecektir. Sistem tasarımının olgunlaşması, yedek parça listeleri, eğitim programlarının tanımlanması ve doküman içeriklerinin belirlenmesi gibi çıktıların üretilmesine izin verir.

'''Üretim ve Kullanım Safhaları'''

Bu safhalardaki lojistik destek aktiviteleri ELDP’ye uygun şekilde yürütülür. ELDP projelerdeki gelişmelere uygun şekilde sürekli güncel tutulur. Kullanım ve destek faaliyetlerini yürütecek olan organizasyonun tabi olduğu mevzuat ve uygulamakta olduğu yönergeler de ELDP hazırlığı sürecinde göz önünde bulundurulmalıdır.

Sistemin teslimatı öncesinde, işletmeye alınabilmesi için gerekli destek altyapısı ve kaynaklar hazırlanır. Sistemin teslimi ve görevine başlaması önemli bir aşamadır. Bu aşamada ilgili destek unsurları da yerinde bulunmalıdır. Devam eden süreçte sistemin başlangıçtaki performansını sürdürmesi ya da değişen koşullara uyum sağlayabilmesi, etkin ve sürekli destek faaliyeti ile mümkün olabilir.

Ürünün üretilebilirliği ile ilgili yapılan tasarım güncellemelerinin desteklenebilirliği etkileyen unsurlara etkileri değerlendirilir ve gerek görülmesi halinde güncellemeler yapılır.

Kullanım safhası ve destek uygulama aşaması, ürünün envantere girmesinden envanterden çıkarılmasına kadar olan süre olup, bu safhada odak sistemin fiilen kullanımı ve istenilen performansta görevini yerine getirmesini sağlayacak lojistik destek faaliyetleri icra edilir.

Kullanım safhası ve destek uygulama aşamasında icra edilen faaliyetlere yönelik aşağıda belirtilen veriler sistemin iyileştirilmesi ve sistem performansının arttırılması maksadıyla kayıt altına alınır:

* Kullanım verileri,
* Lojistik destek verileri,
** Arıza durumu,
** Bakım faaliyetleri,
** Yedek parça (miktar, maliyet, tedarik durumu ve süresi vb.),

* Konfigürasyon verileri,
* Ömür devri verileri
** Fiziki ömür
** Ekonomik ömür
** Teknolojik ömür

* Tedarik ve ikmal verileri,
* Sistem ömür devri kullanım senaryolarındaki (stratejik kararlar) değişimler,
* Muharebe alanının coğrafi ve atmosferik şartlarındaki değişimler ve bu değişimlerin sistem üzerindeki etkileri,
* Sistem emniyet ve güvenlik zafiyetlerini önlemek için yapılan işlemler.

Zaman içinde, operasyonel ihtiyaçlarda ve destek sistem kabiliyetlerindeki değişiklikler takip edilir. Sistemin, görevini istenilen seviyede yerine getirip getirmediğini ve bakım faaliyetlerinin etkinliğini kontrol etmek amacıyla saha verilerine dayalı LDA yapılır. Desteklenebilirliğin istenilen seviyede tutulabilmesi için gerek görülen iyileştirmeler belirlenir ve uygulanır.

'''Envanterden Çıkarma Safhası'''

Sistemin yaklaşık kullanım ömrü ve envanterden çıkarma ile ilgili hususlar, sistem tedariki aşamasında belirlenmiş olmalıdır. Ekonomik, teknolojik veya fiziki ömrünü tamamlayan sistemlerin işletim ve destek maliyetleri artarken, sistem güvenilirlik ve hazır bulunuşluk değerleri ile sistem performansları düşer.

Bir sistemin envanterden çıkarılma kararı, sistemler için ayrılan kullanım, bakım ve idame maliyetlerini azaltmak, aşırı yedek parça stokunu önlemek ve mevcut stokların yıllara sâri olarak azaltılarak envanterden çıkış maliyetini düşürmek için yeterli süre öncesinde alınır.

Sistemin envanterden çıkarılmasına karar verilmesi için aşağıdaki hususların değerlendirilmiş olması gerekir:

* Kullanım ve destek destek safhalarında yapılan aşağıda verilen saha verilerine dayalı analizler ve değerlendirme sonuçları,
** Güvenilirlik analiz sonuçları,
** Hazır bulunuşluk analiz sonuçları,
** Bakım yapılabilirlik/onarılabilirlik analiz sonuçları,
** Demodelik analiz sonuçları,
** İnsan faktörü analiz sonuçları,
** Emniyet ve güvenlik analiz sonuçları,
** ELD donanımlarının uygunluğu ve yeterliliği,

* Tedarik edilebilirlik durumu,
** Yedek parça tedarik edilebilirlik durumu,
** Tedarik sürelerindeki değişim,
** Alt parçaların demodelik durumu,
** Üreticilerin üretim stratejilerindeki değişimler (üretimi durdurma, başka modele geçiş vb.)

* Sistem ömür devri verileri
** Ekonomik ömür,
** Fiziki ömür,
** Teknolojik ömür,

* Konfigürasyon yönetimi sistemi verileri,
* Yasal düzenlemer,
* Uluslararası anlaşmalar,
* Sistem performans değerleri,
* Sistemin mevcut muharebe görevi ve bu görevi yerine getirebilecek alternatif sistemlerin miktar ve yetenekleri,
* Güvenlik, emniyet ve risk oluşturma durumları,
* Muharebe gereksinimindeki (stratejik planlarda) değişiklikler,
* Mali kaynak durumu,
* Sistemin ihtiyaç duyduğu mühimmat, yedek parça veya sarf malzemesi.

Envanterden çıkarılması kararı alınan sistemler kademeli olarak envanterden çıkarılır. Öncelikle durumu en kötü olanlardan başlanır ve belli bir plan çerçevesinde ayıklamaya tabi tutulur. Ayıklamadan elde edilen yedek parçalardan kullanılabilir durumda olanlar, envanterdeki dayanıklı taşınır mal ve sistemlerin idamesinde kullanılır.

Envanterden çıkarma planı, gelişmelere bağlı olarak güncellenir. Güncellemede, yeni tedarik edilecek sistemlere ayrılan kaynağın yetersizliği, tedarikte yaşanan sorunlar, mevcut sistemin ihtiyacı karşılama durumu dikkate alınır. Envanterden çıkarma zamanı gerekirse uzatılır veya tehdit durumu, tedarik planında gecikmeler ve sistemin işletilmesinin maliyet etkin olmaması gibi hususlar dikkate alınarak ilgili sistemlerin daha kısa sürede envanter dışına çıkarılması için plan revize edilir.

İnsan ve çevre sağlığına zarar verebilecek işlemlerden kaçınılır, envanterden çıkarma işlemi yürütlükteki mevzuata uygun biçimde yapılır.

Envanterden çıkarma sürecinde elde edilen atıl konumdaki malzemelerden en fazla oranda fayda sağlamaya yönelik aşağıda sunulan alternatifler değerlendirilir;

* Ayıklanarak başka amaçlar için kullanılabilir,
* Diğer ülke, kurum ve kuruluşlara satılabilir, devir veya hibe edilebilir,
* Ar-Ge çalışması için üniversitelere veya araştırma kurumlarına hibe edilebilir,
* Sergilenmesi maksadıyla müzelere hibe edilebilir,
* Çevre düzenlemeleri için belediyelere veya üniversitelere hibe edilebilir,
* Hurda niteliğinde satılabilir.

== 6.2. PROJE ELD FAALİYETLERİ İLE İLİŞKİLİ DOKÜMANLAR ==
[[Dosya:Tablo 6 ELD Faaliyetleri Kapsamında Hazırlanacak ve Güncelenecek Dokümanlar.jpg|sol|küçükresim|714x714pik|Tablo 6 ELD Faaliyetleri Kapsamında Hazırlanacak ve Güncelenecek Dokümanlar]]

== 6.3. ACİL İHTİYACIN KARŞILANMASI ==
Acil ihtiyaç sebebiyle hazır ürün alımı yoluna gidilebilir. Ancak bu durumda da ortaya konulan çözüm, operasyonel görev profillerini eksiksiz olarak yerine getirmeli ve yüksek seviyede desteklenebilirlik özelliklerine sahip olmalıdır. Acil alım kararlarında; savunma ve güvenlik sistemlerinin lojistik desteğinin sağlanmasındaki zorluklar, kullanım safhasında ortaya çıkabilecek ilave maliyetler, kullanım kısıtları, yurtdışı bağımlılığın artması gibi hususlar dikkate alınmalıdır. Acil ihtiyaç kapsamında yer alan sistemler için de mutlaka gerekli uyarlamalar kapsamında LDA yapılmalı ve ELD Planları hazırlanmalıdır.

=== EK-A ELD PLAN ŞABLONU ===
Bu ELD Plan Şablonu genel hususları kapsayacak şekilde örnek olarak hazırlanmıştır. TÇD ve/veya Sözleşmelerde tedarik makamlarınca uygun görülen formatların kullanılması esastır. Ancak ELDP’nin hazırlanmasında bu şablonda yer alan hususların göz önünde bulundurulması gerekir.

[[Dosya:Şekil şablon.jpg|alt=|sol|küçükresim|539x539pik]]

[[Dosya:Hazırlayanlar.jpg|sol|küçükresim|462x462pik]]

'''DEĞİŞİKLİK KAYITLARI'''
[[Dosya:Değişiklik Kayıtları.jpg|sol|küçükresim|450x450pik]]

'''KISALTMALAR'''
[[Dosya:Kısaltmalar.jpg|sol|küçükresim|450x450pik]]

'''GENEL'''

(Bu ELDP şablonu başlıkları ve içeriği, ülkemizdeki uygulamalar, NATO Çok Uluslu Projelerde ELD Kılavuzu ve ASD/AIA ELD Spesifikasyonları dişkkate alınarak hazırlanmıştır. ELDP kapsamında aşağıda listelene on iki ELD elemanı yer almaktadır:

* Bakım
* İkmal Desteği
* İş gücü ve Personel
* Destek ve Test Ekipmanları
* Tasarıma Etki/Tasarım Etkileşimi
* Teknik Veri ve Dokümantasyon
* Eğitim ve Eğitim Desteği
* Tesisler ve Altyapı
* Paketleme, Elleçleme, Depolama, Ulaştırma (PEDU)
* Bilgisayar Kaynakları
* İdame Mühendisliği
* Ürün Destek Yönetimi

'''Giriş'''

[Bu kısımda, ELDP’nin amacı, kapsamı ve kullanımı hakkında bilgi verilir. Geçmiş süreç özetlenir ve planın geliştirilmesinde izlenen genel yaklaşım tanımlanır.]

'''Sistem Tanımı'''

[İhtiyacı karşılamak amacı ile önerilen sistem çözümü (Odak sistem/desteklenecek sistem) hakkında kısa bilgilendirme yapılır.

* Sistemin fonksiyonel gereksinimleri
* Sistemin fiziksel konfigürasyonu]

'''Program Yönetimi'''

[Tariflenen sistem çözümüne ilişkin tedarik ve geliştirme sürecini yöneten organizasyon, politika ve ilgili süreçler tanımlanır. Program yöneticisi ve katılım sağlayan diğer organizasyonlar, görev ve sorumluluklarıyla birlikte belirtilir. Gerekli iletişim bilgileri, sorumlular bazında aktarılır.]

''<Örnek Başı>''

''Sistemin ömür devri boyunca tanımlı performansını en az maliyet ve yüksek kullanıma hazır bulunma oranında sağlayabilmek için tüm ELD elemanları, organizasyon içinde ELD konusunda bilgili ve tecrübe sahibi ekip tarafından, organizasyonun kalite yönetim sisteminde tanımlı süreçlere uygun olarak planlanır, yürütülür, analiz edilir ve güncellenir. Bu amaçla ihtiyaç duyulacak kaynakların zamanında ve ihtiyaç duyulan yerde hazır bulundurulması sağlanır. ''

''Yüklenicinin organizasyon yapısına ilişkin bilgiler verilir.''

''Proje Yönetimi ve ELD organizasyon şemaları sunulur.''

''Tedarik makamı, ihtiyaç makamı, kullanıcı(lar), idame makamları, yüklenici, altyükleniciler ve tedarikçiler ile arayüzler tanımlanır.''

''İletişim yolları tanımlanır.''

''Temas noktaları tanımlanır.''

''<Örnek Sonu>''

'''Program Kilometre Taşları'''

[Tedarik programının ne zaman başladığını ve ELD görevlerinin ne zaman ve nasıl tamamlanacağını da içeren program kilometre taşları takvimi tanımlanır. Takvim, her program gözden geçirme öncesi ve önemli değişikliklerde güncellenir. Tipik bir takvim tüm zorunlu kilometre taşları ve önemli ara hedefleri gösterir. ELD takvimi proje uygulama takvimi ile uyumlu olmalıdır.

Güncellemenin kolaylığı açısından takvimi içeren tablolar ELDP’nin eki olarak sunulmalıdır.]

''<Örnek Başı> ''

{| class="wikitable"
|'''''Zaman (T0+ay)'''''
|'''''Tarih'''''
|'''''Açıklama'''''
|-
|''0''
|''Eylül 20xx''
|''Sözleşme imzalanması''
|-
|''1''
|''Ekim 20xx''
|''Program Başlangıç Gözden Geçirme''
|-
|''4''
|''Ocak 20xx''
|''Program Gözden Geçirme Toplantısı #1 / ''

''Sistem Gereksinimleri Gözden Geçirme ''
|-
|''7''
|''Nisan 20xx''
|''Ön Tasarım Gözden Geçirme''
|-
|9
|Eylül 20xx
|Program Gözden Geçirme Toplantısı #2
|-
|''11''
|''Ağustos 2004''
|''Kritik Tasarım Gözden Geçirme''
|-
|''…''
|''…''
|''…''
|-
|''30''
|''Mart 20xx''
|''Fabrika Kabul Testleri #1''
|-
|''30-32''
|''Mart 20xx ve Mayıs 20xx''
|''Xxx Eğitimi''
|-
|''31''
|''Nisan 20xx''
|''Teslimat''
|-
|''32''
|''Mayıs 20xx''
|''Destek ve Test Ekipmanları Teslimat''
|-
|''…''
|''…''
|''…''
|-
|''56''
|''Mayıs 20''
|''Program Kapanış Toplantısı''
|}
''<Örnek Sonu>''

'''İlgili Dokümanlar'''

[Tedarik programı ile uyumlu olacak biçimde, ELD faaliyetleri için ilave bilgi ve rehberlik sağlayacak dokümanlar listelenir. Referans numarası, doküman numarası, dokümanın tam adı, yayın tarihi ve versiyon bilgisi açık biçimde verilir. Yayın tarihi ve versiyon bilgisi olmayan dokümanların geçerli en son versiyonları kullanılır. ELDP içinde dokümanın kısa ismi referans numarası ile birlikte kullanılabilir.]

''<Örnek Başı> ''

{| class="wikitable"
|'''''Referans No'''''
|'''''Doküman No'''''
|'''''Doküman Adı'''''
|-
|''[1]''
|
|
|-
|''[2]''
|
|
|-
|''…''
|
|
|-
|
|
|
|-
|
|
|
|}
''<Örnek Sonu>''

'''TEDARİK PROGRAMINDA DESTEKLENEBİLİRLİK'''

[ELD hedeflerine erişebilmek, desteklenebilirliğin sağlanmış olmasına bağlıdır. Tedarik stratejisi kapsamında desteklenebilirlik planlamasına girdi sağlayacak gereksinimler, hedefler, bütçe kısıtları ve desteklenebilirlik analizi stratejisi vb. bu kısımda tanımlanır. ]

'''Operasyonel ve Desteklenebilirlik Gereksinimleri'''

[Görev senaryoları ve gerekleri, operasyonel çevre koşulları, güvenlik gereksinimleri, taşıma gereksinimleri, istihdam, konuşlanma planları, muharebe hizmet destek unsurları vb. hususlar kısaca tanımlanır. Gereksinim dokümanları, desteklenebilirlik analizlerine girdi olması amacıyla yıllık çalışma günü, yıllık görev sayısı, ortalama görev süresi gibi ihtiyaç duyulan detayları sağlamalıdır. Barış, savaş ve kriz dönemleri için önerilen sistem göreve hazır bulunma hedefleri ve bu hedefleri destekleyen RAM eşik değerleri tanımlanır. Sistemin görevi tam yapabilmesi ya da görevde öngörülen seviyedeki başarıyı sağlayabilmesi için gereksinimler listelenir. Uygulanabilir bir hazır bulunma raporlama sistemi, kullanılabilecek formlar ve raporlama sıklığı kararlaştırılır.]

''<Örnek Başı>''

''Harekât Çevre Koşulları''

''Kullanım Konsepti (Savaş, Barış, Kriz)''

''Görev Profilleri''

''Kullanıma Hazır Bulunma Gereksinimleri''

''Güvenilirlik Gereksinimleri''

''İdame Edilebilirlik Gereksinimleri''

''Test Edilebilirlik Gereksinimleri''

''Demodelik Yönetimi''

''Diğer Gereksinimler''

''İyileştirilebilir tasarım, ''

''Desteklenebilir sistem mimarisi, ''

''Standardizasyon, ''

''Entegre bakım desteği (CİT vb.),''

''İnsan mühendisliği,''

''Emniyet, ''

''Kullanım kolaylığı, ''

''Düşük riskli destek unsurları, ''

''İzleme kolaylığı, ''

''Yazılım desteği, ''

''Envanterden çıkarma kolaylığı, ''

''…''

''<Örnek Sonu>''

'''Tedarik Stratejisi'''

[Bu başlıkta kabul edilen tedarik yaklaşımı tanımlanır. Başlangıçta, ihtiyaç duyulan gereksinimlerin sistem modifikasyonu, teknoloji transferi, yeni tasarım veya ticari hazır ürün gibi seçeneklerle karşılanabilmesi durumları söz konusu olabilir. Kabul edilen durum için sözleşmesel yaklaşım ve teşvik hususları tanımlanır.]

'''Destek Riskleri'''

[Tanımlı tedarik stratejisi kapsamında öngörülen destek konsepti ve (varsa) alternatif destek konseptleri ile ilişkili riskler bu başlık altında tanımlanır. En az aşağıdaki alanlar değerlendirilebilir:

Bakım/onarım kabiliyeti seviyesinin değiştirilmesinin etkileri nelerdir?

Envanterde yeni ürün geliştirilmesinden kaynaklanan riskleri azaltabilecek birimler veya alt sistemler mevcut mudur?

Önerilen sistem çözümü destek organizasyonuna nasıl entegre edilecektir?]

'''Personel Gereksinimleri'''

[Sistemin kullanımı, desteklenmesi ve idamesinde görev alacak personelin yüksek kabiliyet seviyelerine sahip olması ihtiyacını azaltmak için alınacak önlemler ve hedefler tanımlanır. Kullanım ve destek maliyetlerini azaltmak için yaklaşımlar ve teşvik hususları belirtilir.]

'''Kaynak Tercihi'''

[Kaynak seçim sürecinde ELD ve desteklenebilirliğin nasıl adresleneceği tanımlanır. Beklenen tedarik maliyetine ek olarak tahmini kullanım, bakım ve destek maliyetlerinin, kaynak değerlendirme sürecinde göz önünde bulundurulabilmesi amacıyla planlar aktarılır.]

'''Tedarikte Destek Elemanları'''

[Sözleşme dokümanlarında yer alan, ELD elemanlarına ilişkin gereksinimler adreslenir. Hızlandırılmış tedarik söz konusu ise hangi kalemlerin hızlandırılma ihtiyacı olacağı ve nasıl gerçekleştirileceği belirtilir. Standart dışı bütçe ihtiyaçları listelenir.]

'''Planlı Konuşlanma ve İstihdam'''

[Planlanan operasyonel konseptler tanımlanmalıdır.]

'''Performansa Dayalı Lojistik (PDL)'''

[Diğer sözleşme türlerine göre faydalarını içerecek şekilde PDL stratejisi ve uygulaması tartışılır.]

'''ELD/Desteklenebilirlik Bütçesi-ÖDM'''

Yürütülecek çalışmaların kapsamı ve derinliğini belirlemek için toplam ÖDM’nin başta tasarıma etki/tasarım etkileşimi olmak üzere ilgili ELD elemanları altında belirlenmesinde kullanılacak ve güncellenecek çalışmalar tanımlanır. Desteğin, birim yöneticilerine ve idameyi sağlayacak/sorumlu olacak makamlara geçişi için gerekli planlamalar çalışmalara dahil edilir.

Maliyet tahmininde kullanılacak model ve uyarlamalar ile modellemede geçerli olacak kısıtlamalar ve varsayımlara ilişkin bilgiler, tedarik makamından alınmalıdır. Koordinasyon/iletişim kanalları ve raporlama takvimi belirtilir. Gereksinimleri de içerecek şekilde ELD elemanları, başlıca fonksiyonlar, kullanım ve idame için maliyet tahmini sonuçları belirtilir.]

'''Desteklenebilirlik Analizi Stratejisi'''

[Tedarik sürecinde yürütülmesi planlanan desteklenebilirlik analizi tanımlanır ve varsa gerekli spesifik analizler belirtilir. Aşağıdaki hususlar kapsamında kısa açıklamalar aktarılır:

Seçilen desteklenebilirlik analizinin tedarik programı ihtiyaçları ve safhalarına göre nasıl uyarlanacağı tanımlanır.

ELD elemanlarının geliştirilmesine girdi sağlayacak lojistik yönetim bilgisinin nasıl kullanılacağı tanımlanır.

Lojistik yönetim bilgisi üretilecek ve dokümante edilecek her donanım/yazılım için kırılım ve bakım seviyesi belirtilir.

Verinin yeterlilik ve tutarlılık açısından nasıl doğrulanacağı ve bu kapsamdaki sorumluluklar tanımlanır.

Desteklenebilirlik analizleri için veri kaynakları belirtilir. Veri tekrarını ve tutarsız veriyi önleyecek kontroller aktarılır ve daha önceki safhalarda gerçekleştirilen desteklenebilirlik analiz sonuçları özetlenir.]

''<Örnek Başı>''

''ASD/AIA S3000L spesifikasyonuna uygun olarak LDA gerçekleştirilecektir. Seçilen desteklenebilirlik analizleri, program ihtiyaçları ve aşamalarına göre güncellenebilecektir. Lojistik bilgi ve veri üretilecek her konfigürasyon birimi için gereksinimler sağlanacak ve ürün kırılımları aktarılacaktır.''

''Sistem mühendisliği koordinasyonu ile analizlere girdi olacak veri kaynakları kontrol edilecektir. Aşağıdaki analizlerin yapılması planlanmaktadır:''

''FMEA/FMECA''

''FTA''

''RCM''

''DSEA (Damage and Special Event Analysis)''

''MTA''

''LORA''

''RAM analizleri''

''Yedek parça analizleri''

''<Örnek Sonu>''

'''Desteklenebilirlik Test ve Değerlendirmesi'''

[Planlanan test ve değerlendirme konsepti, kapsamı, hedefleri ve geliştirme testlerinde ve operasyonel testlerde nasıl karşılanacakları kısaca tanımlanır. Desteklenebilirlik test konularını tanımlayacak organizasyonlar listelenir. Bu konular ve amaçlar ELDP içinde özetlenir ve Test ve Değerlendirme Ana Planına dahil edilir. Bu kapsamda dikkate alınması gerekli hususlar en az aşağıdakileri içermelidir:

ELDP ile doğrudan ilişkili özel test gereksinimleri,

Beklenen kritik desteklenebilirlik hususları ve destek planlamasına etkileri,

Kritik hususların çözümlerinin değerlendirilmesi için ihtiyaç duyulan test ve değerlendirme,

Test ve değerlendirme işlemleri için gerekli eğitim, iş gücü ve yetenekler,

Desteklenebilirlik hususlarını çözmek için gerekli aksiyonların başlangıç ve bitiş tarihleri,

Lojistik Yönetim Bilgisi ve test verisi toplama sistemleri arasında arayüzler,

Cihaz içi veya destekleyici otomatik çalıştırma, test ve bakım ekipmanlarının test ve değerlendirmesi (mümkün olduğunca ilgili yazılımları da kapsayacak biçimde),

Tamamlanan test sonuçlarının planlı test aksiyonlarını, kriterlerini, gereksinimlerini, vs. nasıl etkileyeceği,

Önerilen test lokasyonları, veri toplama prosedürleri ve veri kullanımı, test ve değerlendirme faaliyetlerinde görev alan organizasyonlar ve sorumluluklarını da içerecek şekilde başlıca önlemler ve faaliyetlerin özetinin sağlanması,
Lojistik Yönetim Bilgisi ve sistem destek paketi bileşenlerini, taslak ya da son sürüm teknik yayınları, bütün test, ölçüm ve diagnostik ekipmanlarını, bakım kademe yetki tablolarını, onarım parçaları/özel onarım alet listeleri, kurtarma ekipmanları vb. doğrulayan lojistik demonstrasyon planları,

[Lojistik demonstrasyon, prototip ürün ya da yazılım hazır olduğunda en kısa sürede gerçekleştirilmelidir. Lojistik demonstrasyon, geliştirmeye yönelik ve operasyonel testler öncesinde kaynakların ve sistem destek paketi bileşenlerinin hazır bulunuşluğuna imkan verecek bir zamanlama ile tamamlanmalıdır. ]

Prototip ürün/yazılım geliştirme için gereklerin ve kullanılacak metotların tanımlanması.]

'''ELD ELEMANLARI PLANI'''

[Her ELD elemanı için detaylı şekilde planlamalar bu bölümde aktarılacaktır. ELD elemanlarına yönelik gereksinimler ve aktarılması gereken durumlar eksiksiz paylaşılacaktır. Bu bölümde ELD elemanları özelinde personel gereksinimlerine ve kısıtlara da yer verilir.]

'''Bakım'''

[Bütün bakım seviyelerini içerecek şekilde sistem bakım konsepti tanımlanır. Sisteme özgü bakım yaklaşımı kapsamında yürütülecek getiri-götürü değerlendirmeleri aktarılır.

Tanımlı hazır bulunma seviyelerinde görev yapabilmek için gerekli bakım görevleri tanımlanır.

Lojistik analizler sonucu ortaya çıkan destek konsepti aktarılır. Her bakım seviyesi için önerilen ve mevcut olan yetenekler, el aletleri, test, güvenlik prosedürleri, destek, kalibrasyon, ölçüm ve teşhis ekipmanları vb. belirtilir. Bileşenlerin ve onarım parçalarının sökülme durumları için muhtemel tasarımlara yönelik analizler bu bölüme dahil edilir.

Her destek alternatifinin zayıf ve güçlü yönleri ve destek konseptinin sistem tasarımı, tedarik ve işletme-destek maliyetleri ve etkilenen ELD elemanlarına etkileri aktarılır.

Çok uluslu kullanım amacıyla tedarik edilen sistemlerde merkezi bakım ve ikmal desteğinin fizibilite çalışmaları tariflenir.

Bakım ortamı aşağıdakileri içerecek şekilde tariflenir:

Bakım ortamı, kısıtlamalar ve konuşlanma takvimi için gereksinimler tanımlanır. Arızalı birim geri dönüş süreleri, yıllık direkt bakım işçiliği vb. detaylar desteklenebilirlik analizlerinde kullanılmak üzere aktarılır. Gereksinim dokümanlarında aktarılan lojistik destek parametreleri listelenir. İhtiyaç duyulması halinde lojistik yönetim bilgisine başvurulur.

Savaş hasarı, yerinde onarım prosedürleri gibi özel durumları da içerecek şekilde her bakım seviyesinde gerçekleştirilecek bakım faaliyetlerinin kapsamı belirtilir. Alternatif yaklaşımlar değerlendirilir ve seçim sürecinde faydalanılan kriterler tanımlanır.

İkmal ve bakım desteği sağlayacak lojistik destek yapısı tanımlanır.

Özel görevler kapsamında söz konusu olabilecek destek aktiviteleri, özel onarım faaliyetleri ve onarım lokasyonları tanımlanır.

Kullanım ve depolama yerlerine ve sarf istatistiklerine göre bakım malzemeleri ihtiyacı tanımlanır.

Ürünün performans ve maliyet açısından en uygun şekilde desteklenmesini sağlayacak bakım seviyeleri tanımlanır.

Bakım sırasında ortaya çıkabilecek muhtemel emniyet risklerini en aza indirecek çalışmalar belirtilir.

Çevresel riskler açısından nükleer, biyolojik ve kimyasal kirliliğe ilişkin bakım konseptleri ve özel gereksinimler listelenir.]

'''İkmal Desteği'''

İkmal; bir askerî birlik ve kurumun teçhizi, bakımı ve harekâtı için ihtiyaç duyulan her türlü ikmal maddelerinin cins ve miktarlarının tespiti, tedariki, depolanması ve depodayken bakımı, dağıtımı ve son işlemi faaliyetlerini kapsar.

İkmal destek unsurunun amacı, “mümkün olan en düşük ÖDM’de en iyi kabiliyetin kullanıma hazır olması”nı sağlayabilmek için gerekli onarım parçaları, yedekleri ve bütün ikmal sınıflarını tedarik etmek için yönetim faaliyetlerinin belirlenmesi, planlanması, söz konusu faaliyetlere yönelik kaynağın sağlanması ve faaliyetlerin icra edilmesidir. Bu kapsamda üretilen tedarik verisi; satın alınacak, kontrol edilecek, paketlenerek son kullanıcıya teslim edilecek ürünlere ait tanımlama, açıklama ve test bilgilerini içerir.

Önerilen ikmal desteği konsepti, kısıtlamalar ile sisteme ve destek ekipmanlarına özgü gereksinimler tanımlanır. Bu kapsamda aşağıdaki hususlar değerlendirilir:

Standart ikmal desteği prosedürlerinden potansiyel sapmalar tanımlanır. Bunların maliyet, iş gücü, hazır bulunma vb. faktörlere olan etkileri değerlendirilir.

Uygulanabilir seviyede, onarım parçaları, mühimmat, petrol ürünleri ve yağlar, kritik parçalar ve yardımcı birimler, özel ve ortak el aletleri ve destek ve test ekipmanları için kataloglama, tedarik, paketleme, muhafaza, fatura, depolama ve elden çıkarma planı tanımlanır.

Desteklenebilirlik analizi/lojistik yönetim bilgisi, saha tecrübeleri ve test verilerine göre kullanım ve arıza verilerinin gözden geçirilmesi ve düzenlenmesi için planlar belirtilir.

Aşağıdaki hususlarda yapılan planlamalar aktarılır:

İhtiyaç duyulan ikmal desteği için kapsam, miktar ve özel gereksinimlerin belirlenmesi,

Uzun teslim sürelerine sahip birimler ve dışarıdan alınan birimlerin tanımlanması,

Kritik parçalar, hizmetler ve ekipmanların tanımlanması,

Yeniden tedarik (Re-procurement),

Devlet malı malzemelerin tanımlanması,

Nükleer kritik malzemelerin tanımlanması,

İkmal desteği yöntemi ve tipi (örneğin, parça değişimlerinin küçük parça, takım, modül veya fabrikasyon konsepti) tanımlanması,

Hizmet alımları arasında ikmal desteği açısından oluşabilecek boşluklara ilişkin olarak ikmal desteği anlaşmalarında olası ihtiyaçların tariflenmesi,

Temin çalışmalarına tedarik programının etkilerinin değerlendirilmesi,

Diğer ikmal desteği organizasyonları için gerekli bilgilerin sağlanması,

Operasyonlar sırasında tüketilen temel sürdürülebilirlik malzemeleri (mühimmat, petrol ürünleri, yağlar, güç kaynakları, diğer sarf malzemeler vb.) için gereklerin tanımlanması. Gereksinimler farklı görev profillerine göre uyarlanır.]

'''İş gücü ve Personel'''

[İş gücü, belirli bir işin yapılabilmesi için gerekli olan personel veya pozisyon sayısını; personel ise, işin doğru şekilde yapılabilmesi için gerekli olan yetenek ve kabiliyetler, bilgi, beceri ve tecrübe seviyelerine sahip olmayı ifade eder.

Sistem çözümünün kullanıcı ve bakım iş gücü tanımlanır. Test edilmesi önerilen birimler için iş gücünün nasıl sağlanacağı tariflenir. Bu hususlara kısıtlamalar, sisteme özgü gerekler ve insan-makine arayüzü dahil edilir. Savaş, barış ve kriz dönemi gereksinimleri için kuvvet yapısı değerlendirilir.

Sistemin kullanımı, bakımı ve desteği için gerekli personelin yetenek gereksinimleri aktarılır. Sistem kullanımı, bakımı ve taşınması esnasında insan arayüzü problemlerini en aza indirecek emniyet ve insan mühendisliği kısıtları tanımlanır. Bu tanımlamalara uygulanabilir ölçüde sistem emniyet ve tehlike değerlendirme gereksinimleri ve sonuçları dahil edilir.]

'''Destek ve Test Ekipmanları'''

[Destek ekipmanı, ürünün destek ve idamesi için gerekli olan her türlü ekipmanı kapsayan bir ifadedir. Kapsamına, çok kullanımlı destek elemanları, el aletleri/avandanlıklar, meteoroloji ve kalibrasyon ekipmanları, manuel/otomatik test ekipmanları dahildir.

Destek ekipmanı gereksinimlerini tanımlamak için kullanılan prosedürler tanımlanır.

Stoklarda yer alan standart destek ekipmanlarının değerlendirilmesi için gereksinimler tanımlanır. Standart destek, kalibrasyon, ölçüm ve test aletlerinin kullanımını en üst seviyede mümkün kılacak prosedürler aktarılır.

Kıt destek kaynakları için gereksinimleri içerebilmesi adına destekle ilgili donanımın ana öğeleri tanımlanır.

Destek ve test ekipmanları ve DKÖT’e özgü donanım test, geliştirme ve destek gereksinimleri tanımlanır. DKÖT’ler vb. birimler için çevresel ve depolama gereksinimleri belirtilir.

Destek ve test ekipmanları ve DKÖT’e özgü test ve değerlendirme amaçları tanımlanır ve test ve değerlendirme ana planları için gerekli girdiler sağlanır.]

'''Tasarıma Etki/TasarımEtkileşimi'''

[ELD ve ÖDM’nin kaynak seçimi, sistem tasarımı ve tedarik kararlarını nasıl etkileyeceği tanımlanır. Tasarım önerilerinde ve önerilen mühendislik değişikliklerinde ELD’nin bütün olarak dikkate alınmasını sağlamak için ELD ve diğer planlara ilişkin tasarım kısıtları açıklanır. Tasarım gözden geçirmeleri ve alternatif değerlendirme çalışmalarına ELD personelinin katılımı sağlanır.

İklimsel kısıtlar, çevre ve enerji kısıtları ve insiyatiflerin yanı sıra ilgili alternatif değerlendirmeleri tanımlanır.

Yeni teknolojileri tanımlamak için bağımsız Ar-Ge programları ve diğer desteklenebilirlik çalışmaları tanımlanır.

Lojistik ile ilişkili dayanıklılık ve hayatta kalma/beka kabiliyeti (survivability) tanımlanır.

Komponent ve ana parça standardizasyonu ve birlikte çalışabilirlik gereksinimleri aktarılır.

Sistem tasarımını etkileyebilecek kazanılmış dersler ve benzeri sistemlere yönelik tecrübelerin uygulanabilirliği aktarılır.]

''<Örnek Başı>''

''Ömür Devri Maliyet Analizi''

''LDA''

''RAMST Analizleri''

''<Örnek Sonu>''

'''Teknik Veri ve Dokümantasyon'''

[Kayıt şekli ya da yönteminden bağımsız olarak bilimsel ve teknik içerikli kayıtlı veri ve bilgilerdir. Bilgisayar yazılımı, finansal ya da idari bilgiler gibi sözleşme yönetim bilgileri teknik veri ve dokümantasyon kapsamına girmez.

Teknik veri elemanının başlıca iki hedefi mevcuttur:

Bilgiyi elde etme ve bakım faaliyetlerini tanımlama, planlama, doğrulama, kaynak tespiti ve yürütme,

Teknik yayın planlama, geliştirme, üretim ve bakımı.

Bu bölümde teknik yayın konsepti aktarılır.

Doküman güncelleme ve sonlandırma gereksinimleri belirtilir. Bu kapsamda sistem üretim takvimleri ile koordinasyon sağlanması önemlidir. Onarım parçaları listesi, destek ekipmanları listesi, görev tahsisatı ve teknik yayınların kullanım ve bakım talimatları açıklamaları arasında uyumluluk sağlamak için Lojistik Yönetim Bilgisinin kaynak girdi olarak teknik yayın hazırlıklarında nasıl kullanılacağı tarif edilir.

Teknik yayınların geçerli kılma ve doğrulama kriterleri belirtilir ve test desteği anlamında ihtiyaç duyulabilecek miktar ve teknik yayın çeşitleri belirlenir.

Son versiyon teknik yayınların hazırlanma ve basım takvimleri tanımlanır.

Teknik veri paketine ihtiyaç duyulup duyulmadığına karar vermek için plan tanımlanır, tedarik stratejisine etkileri değerlendirilir.]

'''Eğitim ve Eğitim Desteği'''

[Eğitim ve eğitim araçları gereksinimlerinin nasıl karşılanacağı ve bu gereksinimleri karşılamada kimlerin sorumlu olacağı tanımlanır. Eğitim test ve doğrulama prosedürleri aktarılır. Hedef kitle ve eğitim kısıtları hakkında bilgi sağlanır.

Uzun dönemli eğitim tesis gereksinimleri hakkında bilgi sağlanır.

İhtiyaç duyulan eğitim ve eğitim araçlarının tedarik planı tariflenir.

Donanım, yazılım, insan arayüzü, destek birimleri ve test ekipmanlarının kullanım ve bakım faaliyetlerine özgü, eğitim kurumlarından alınması gerekebilecek eğitimler ve planlar değerlendirilir.

Hassas, sınıflandırılmış veya tehlikeli bileşenler, parça, malzeme ve mühimmat için harekât ve depolama faaliyetleri kapsamında ihtiyaç duyulabilecek standart dışı PEDU eğitim gereksinimleri tanımlanır.]

'''Tesisler ve Altyapı'''

[Odak sistem ve destek ekipmanlarının kullanımı, depolanması, test edilmesi, eğitim faaliyetleri, bakımı ve envanterden çıkarılması süreçlerinde ihtiyaç duyulacak tesis ve altyapı gereksinimleri tanımlanır. Planlı bakım, kalibrasyon, yazılım kurulumu, depolama, eğitim ve personel tesisleri gereksinimleri ve kısıtları tanımlanır.

Mevcut sabit ve hareketli tesislerin kabiliyetleri ve eksiklikleri odak sistemin kendisi ile bakım ve destek ihtiyaçları için tanımlanır. Tanımlanan eksiklikleri giderebilecek modifikasyon gereksinimleri listelenir. Modifikasyona uğrayacak ya da yeni kurulacak tesisler için program yönetimi gerekleri aktarılır. Tesis güvenlik gereksinimleri tanımlanır.]

'''Paketleme, Elleçleme, Depolama ve Ulaşım (PEDU)'''

[Sisteme özgü gereksinimler ile yönetim sorumlulukları ve prosedürler, tedarik sürecinde PEDU gereksinimlerinin tanımlanması ve zamanında karşılanması maksadıyla tanımlanır.

Öngörülen PEDU seçenekleri ve kısıtları tanımlanır.

Sistemin, bileşenlerin, parçaların ve test ekipmanlarının depolama ve iklimsel gereksinimleri belirtilir.

Tanımlanan lojistik problemlerin çözümlerine, PEDU gereksinimleri ve risklerinin değerlendirilmesinin dahil edilmesi için yapılacak faaliyetler belirlenir.

İlk ürün ile birlikte kullanıma hazır olması beklenen ve gerekli olan PEDU hususları tanımlanır.

PEDU sistemleri ve prosedürlerinin, mevcut ve projelendirilmiş değişiklikleri tanımlanır. Paralelde geliştirilen, entegrasyonu yapılan ya da test edilen PEDU ekipmanları ile arayüzler belirlenir.

PEDU test gereksinimlerinin tanımlandığı ve test ve değerlendirme ana planlarına dahil edildiği doğrulanır.

PEDU faaliyetleri sırasında dikkat edilecek özel hususlar tanımlanır.

Paketleme, depolama ve ulaştırmaya ilişkin hususlar

* Paketleme ve Paketi Açma
* Güvenlik
* Koruma
* Depolama
* Zararlı Madde Taşıma
* Yük Sandığı Konsepti
* Kaldırma
* Ulaştırma Şartları
* ….

Elleçleme ve kullanıma hazır hale getirmeye ilişkin hususlar:

* Emniyet İkazları
* Kullanım Talimatı
* Kullanım
* Yükleme ve boşaltma
* Çekme Taşıma Ekipmanı
* Kullanım Değişikliği
* Konuşlandırma
* Ürün koruma
* Buzlanma Önlemi
* Elektrik Yük Kontrolü
* Manyetik Dayanım Kontrolü
* İstatistiksel Veri Kayıtları
* …

Sistem sevkiyatı kapsamında kullanılabilecek konteynırların belirlenmesi için gerekli aksiyonlar listelenir.

Sistem çözümü için uygun depolama standardı belirtilir.

Birim ve kuvvet konuşlanabilirliği ile ilişki olanları da içerecek şekilde özel ulaştırma sorumlulukları, gereksinimleri ve kısıtları tanımlanır. Gerekli stratejik ve taktik taşıma modları ve araç tipi tanımlanır. Kullanıcının taşıma kısıtları, konteynır uyumluluğunu içerecek şekilde belirlenir. Uygun zamanlarda tasarım ve performans değerlendirmeleri gerçekleştirilir.

Ekipman gönderimi için katılım sağlayan hizmetlere özgü özel gereksinimleri içerecek şekilde ulaşım ihtiyaçları tanımlanır.

Hava/Kara/Deniz taşımacılığı kullanılacaksa uygun araç tipine göre yükleme ve boşaltma konfigürasyon düzeni açıklanır. Ağırlık ve hacim dahil edilir.

Kaldırma ve bağlama gereksinimleri ve prosedürlerinin son sistem konfigürasyonunda yer almasını sağlamak için gereksinimler tanımlanır.]

'''Bilgisayar Kaynakları'''

[Görev kritik bilgisayar donanım/yazılım sistemlerinin kullanımı ve desteği için gerekli olan tesis, donanım, yazılım, dokümantasyon ve iş gücü ihtiyacını kapsar. Amacı, görev kritik bilgisayar donanım ve/veya yazılım sistemlerinin planlanması ve yönetimi için gerekli olan kaynakların tespiti, planlanması ve tahsisinin gerçekleştirilmesidir.]

'''İdame Mühendisliği'''

[Bu ELD elemanının amacı, kullanımda olan ürünleri bulundukları operasyonel çevre koşullarında desteklemektir. Bu faaliyet envanterde bulunan ve/veya envantere alınan bir sistemin kullanımı ve desteklenmesi için gerekli olan tüm teknik görevleri kapsar (mühendislik ve lojistik incelemeler, analizler vb). İdame Mühendisliği, sistemin kullanım ömrü boyunca kusurlarının belirlenmesi, gözden geçirilmesi, değerlendirilmesi ve çözüme kavuşturulmasını içerir. İdame mühendisliği faaliyetleri iki ana başlık altında toplanabilir:

Kusurların belirlenmesi ve teknik analizlerin gerçekleştirilmesi.

Çözümlerin geliştirilmesi.]

'''Ürün Destek Yönetimi (ÜDY)'''

[Ürün Destek Yönetimi (ÜDY); bütün ELD elemanlarını kapsayacak şekilde ürün desteğinin planlanması, yönetilmesi ve finanse edilmesini kapsar. Destek konseptinin ve ELDP’nin hazırlanması, geliştirilmesi ve detaylandırılmasının yanı sıra demodelik planının hazırlanması ve raporunun oluşturulması da bu ELD elemanı bünyesinde gerçekleştirilen faaliyetlerdendir. ÜDY, belirli bir sistem veya hizmet için ELD ihtiyaçlarının detaylandırıldığı ELD elemanıdır. Bu doğrultuda dört temel faaliyet gerçekleştirilir:

Ürün Destek Gereksinimlerinin Toplanması

ELDP’nin Hazırlanması ve Geliştirilmesi

Sözleşme Yönetimi

Demodelik Yönetimi]

'''KULLANIMA ALMA VE KULLANIM DESTEĞİNİN SAĞLANMASI'''

'''Kullanıma Alma'''

[Program kapsamında hedeflenen ilk harekât yeteneği sağlanabilmesi için yapılan planlama aktarılır. Sistem kullanıma alma dokümantasyonu hazırlanması için prosedürler ve takvim özetlenir. Kullanıma alma faaliyetinin nasıl yürütüleceği hakkında bilgi verilir.]

'''Program Geçişi'''

[Bu yönde bir düzenleme öngörülmüşse programın program yönetim organizasyonundan idameden sorumlu destek organizasyonuna nasıl ve ne zaman devredileceği ile ilgili açıklama verilir. Geçmişte edinilmiş tecrübelerden bu program için uygulanabilecek olanlar belirtilir. Onarım parçası kullanımı, eğitim, teknik veri vb. bilgilerin nasıl toplanacağı ve kullanılacağı gösterilir. Sistemin kullanımı için yeterli seviyede ikmal, eğitim ve sistem idamesi için gerekli tüm veriler detaylı olarak sağlanır.]

'''Üretim Sonrası Destek'''

[Geliştirme safhasının erken dönemlerinde başlangıç Üretim Sonrası Destek Planı oluşturulur. Kullanım safhasındaki lojistik desteğin sürdürülebilirliği için kaynakları ve yönetim adımlarını içeren bu plan ürün destek stratejisi ve modeli ile uyum içinde olmalıdır (Bkz. TSSÖDYP-03 Ürün Destek Stratejileri ve Modelleri Rehberi). Üretim Sonrası destek planının güncel tutulması için güncelleme takvimi oluşturulmalıdır. Üretim safhası öncesinde, sonrasında ve destek safhası içinde kayda değer değişiklikler olduğunda plan güncellenmelidir.]

'''Kullanıma Alma Sonrası Destek Analizi'''

[Sistem ömür devri boyunca en az destek maliyeti ile yüksek kullanıma/göreve hazır olma değerlerinin sağlanması önemlidir. Kullanıma alma sonrası sistem desteğini izlemek için bir plan geliştirilmelidir. Kullanıma/göreve hazır olma ve destek ölçümleri/verileri, veri kaynakları, veri analiz yöntemleri ve sistem desteklenebilirliğini geliştirecek ya da ELD problemlerini düzeltecek prosedürler tanımlanır.]

'''Envanterden Çıkarma'''

[Beklenen sistem ömrü uzun olsa bile ELDP içeriğinde envanterden çıkarma faaliyetlerinin tanımlanması ihmal edilmemelidir. Envanterden çıkarılan malzemenin ekonomik açıdan değeri yüksek olmasa da çevreye olası etkileri elden çıkarma planlamasında dikkate alınacaktır. Sistem ömrünün herhangi bir anında kaza ya da büyük hasara yol açan arıza gibi durumlarda envanterden çıkarma faaliyetlerine başvurabilme ihtimali de envanterden çıkarma planlarının geliştirilmesini gerektirir.]

'''DOKÜMANIN HAZIRLANMASINDA GÖREV ALAN KURUM/KURULUŞLAR'''

SAVUNMA SANAYİİ BAŞKANLIĞI

ASELSAN A.Ş.

BMC POWER MOTOR VE KONTROL TEKNOLOJİLERİ A.Ş.

FNSS SAVUNMA SİSTEMLERİ A.Ş.

HAVELSAN A.Ş.

METEKSAN SAVUNMA SANAYİ A.Ş.

ROKETSAN A.Ş.

TUBİTAK BİLGEM İLTAREN

YATEM BİLİŞİM VE TEKNOLOJİ SİSTEMLERİ A.Ş.

Sistem Ömür Devri Yönetimi Rehberi (Ana Çerçeve)

2023-01-13T07:16:36Z

Oozdemir:

'''[https://tssodypwiki.ssb.gov.tr/images/3/39/TSSODYP_01_180822_web.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şkanlığı çatısı altında, ilgili tüm paydaşların katılımıyla faaliyet göstermek üzere Türk Savunma Sanayii Ömür Devri Yönetimi Platformu (TSSÖDYP) kurulmuştur.

TSSÖDYP; savunma ve güvenlik sistemlerine ilişkin ihtiyacın belirlenmesi, sistemlerin tedariki, kullanımı, desteklenmesi ve envanterden çıkarması safhalarını bir bütün halinde ele alan Sistem Ömür Devri Yönetimi ilke ve uygulamalarının ülkemizde yaygınlaştırılmasını ve savunma programlarının/ projelerinin yürütülmesinde savunma ve güvenlik ekosistemini oluşturan tüm paydaşlarca anlayış birliğine ulaşılmasını amaçlamaktadır.

Savunma sistemlerinin ömür devri yönetiminde millî bünyemize uygun, ülkemize özgü çözümler üretmek ve bunları dokümante etmek gibi önemli bir misyonu olan TSSÖDYP; Başkanlığımız, Milli Savunma Bakanlığı ve ilgili birimleri, Genelkurmay Başkanlığı, K.K.K.lığı, Dz.K.K.lığı, Hv.K.K.lığı, J.Gn.K.lığı, S.G.K.lığı, EGM, TÜBİTAK, SASAD ve savunma sanayii firmaları temsilcilerinin katılımı ile çalışmalarına devam etmektedir.

Sistem ömür devri yönetimi yaklaşımı ile; savunma ve güvenlik sistemlerine ilişkin ihtiyacın belirlenmesi aşamasından envanterden çıkarma safhasının sonuna kadar görev alan tüm kamu kurum ve kuruluşları ile özel sektör firmalarının sistemlerin istenilen performans seviyesinde mümkün olan en az maliyetle tedariki, kullanımı ve lojistik desteğinin sağlanabilmesi için görev, yetki ve sorumlulukları çerçevesinde ömür devrinin tamamında birlikte çalışmaları öngörülmektedir.

Bu itibarla, savunma ve güvenlik sistemlerine ilişkin ihtiyacın belirlenmesinin, tedarikinin, kullanımının, lojistik desteğinin ve envanterden çıkarılmasının en baştan uzun soluklu bir program olarak kurgulanmasının ve ilgili birimler aracılığı ile sistem ömür devri yönetimi faaliyetlerinin yürütülmesinin faydalı olacağı değerlendirilmektedir.

TSSÖDYP tarafından son iki buçuk yıl içinde gerçekleştirilen çalışmalar ile savunma ve güvenlik sistemlerinin ömür devri yönetimine ilişkin planlama ve uygulamaya esas olacak yaklaşımları ortaya koyan 13 adet rehber, iki adet bilgi kitapçığı ve bir adet terminoloji dokümanı hazırlanmıştır. Uygulamalardan alınacak geri bildirimler ile söz konusu dokümanların güncellenmesi, geliştirilmesi ve önümüzdeki dönemde uygulamaya esas düzenlemelerin alt yapısını oluşturması hedeflenmektedir.

TSSÖDYP çalışmalarına katkı veren ve dokümanların hazırlanmasında görev alan tüm paydaşlarımıza teşekkürlerimi sunuyorum.

Prof.Dr. İsmail DEMİR

T.C. Cumhurbaşkanlığı

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.

Bu nedenle, tedarik edilen sistemlerin kullanım döneminde hedeflenen muharebe ve/veya operasyon performansının sürdürülebilirliğinin ve maliyet etkinliğinin sağlanması amacıyla sistemlerin ömür devrinde rol ve sorumluluğu bulunan tüm paydaşların katılımı ile Sistem Ömür Devri Yönetimi yaklaşımı geliştirilmiştir.

Sistem Ömür Devri Yönetiminin temel amacı; mevcut durumdaki değişimlere uyum sağlamaktan ziyade gelecekte ortaya çıkabilecek değişimleri öngörmek, belirlenen hedefler doğrultusunda gerekli önlemleri alarak değişimleri yönlendirmek ve kontrol altında tutmaktır. Harekât ihtiyaçlarının zamanında ve verimli şekilde karşılanması ve sahip olunan kaynakların maliyet etkin kullanımı esastır. Başka bir deyişle, sistem ömür devri yönetimi geleceği bugünden tasarlamak ve planlamaktır.

Bu doküman; Savunma Sanayii Başkanlığı (SSB), Milli Savunma Bakanlığının ilgili birimleri, Türk Silahlı Kuvvetleri (TSK), diğer ihtiyaç makamları ve savunma sanayi firmalarında Sistem Ömür Devri Yönetimi’nin bir kültür olarak yaygınlaştırılmasına ve uygulanmasına yönelik rehber oluşturmak amacıyla savunma sistemlerinin ömür devrinde rol ve sorumluluğu bulunan ilgili paydaşların katılımıyla hazırlanmıştır.

Sonuç olarak; sistem ömür devrinin etkin şekilde yönetilmesiyle ülkemize muharebe ve/veya operasyon üstünlüğü kazandırılırken, sistemlerin ömür devri maliyetleri düşürülerek savunma giderleri azaltılacak, ülke ekonomisine önemli katkılar sağlanacak, savunma sanayii firmalarımızın uluslararası alandaki rekabet etme seviyesi artırılacak ve ömür devri yönetimi kapsamında savunma ve güvenlik alanındaki portföy/program/projelerde ömür devri yönetimi ve lojistik faaliyetlerin ortak bir anlayışla işbirliği içinde yürütülmesi hedeflenmektedir.

= 1. GENEL =

== 1.1. GİRİŞ ==
Çok hızlı bir değişimin yaşandığı günümüzde, orduların sadece bu değişime ayak uydurmaları yeterli olmayıp önleyici bir yaklaşımla çevresinde meydana gelebilecek değişimleri hızla öngörmesi, milli hedefleri doğrultusunda değişimi yönlendirebilmesi ve gerekli önlemleri zamanında alabilmesi daha başarılı olmalarının vazgeçilmez şartıdır.

Bu amaçla; değişen tehdit ve muharebe ve/veya operasyon şartlarına reaksiyon gösterilebilmesi, ihtiyaç duyulan yeteneklerin doğru stratejiler ışığında belirlenip doğru zamanda ve maliyet etkin olarak kazanılabilmesi ve sürdürülebilirliğinin sağlanabilmesi, savunma sistemlerinin performansının artırılabilmesi, kullanım ve destek faaliyetlerinde yaşanan sorunların giderilebilmesi ve ömür devri maliyetlerinin azaltılabilmesi için Sistem Ömür Devri Yönetimi yaklaşımı geliştirilmiştir.

Geleneksel lojistik destek anlayışının aksine Sistem Ömür Devri Yönetimi yaklaşımında;

* Sistemin tüm ömür devri safhaları birbirleri ile etkileşim içinde bütünleşik olarak yönetilir.
* Kullanım ve destek safhası gereksinimleri, sistem ömür devrinin ilk safhalarında yapılan bilimsel çalışmalarla belirlenir ve Odak Sistem ile birlikte tasarlanıp tedarik edilir.
* Envanterdeki sistemlerin, muhtemel tehdit ve beklenen görev ortamında yeterliliği devamlı olarak değerlendirilir ve yetersizliklerin giderilmesine yönelik önlemler zamanında alınır.

Sistem Ömür Devri Yönetimi yaklaşımının SSB, TSK, diğer ihtiyaç makamları ve savunma sanayii firmalarında bir kültür olarak yaygınlaşması ve etkin bir şekilde kullanılması ile savunma sistemlerinin muharebe ve/veya operasyon performanslarının artacağı, sistem ömür devri maliyetlerinin düşeceği öngörülmektedir.

Sistem ömür devri boyunca sistem etkinliğinin sağlanması için, tüm sistem ömür devrinin safhalar halinde tanımlanması, yürütülen faaliyetlerin ölçülmesi, geliştirilmesi ve iyileştirilmesi esastır. Bu amaçla, ihtiyacın ortaya çıkışından ürünün envanterden çıkarılmasına kadar tanımlanan tüm safha ve aşamalar içinde yer alan faaliyetlerin bütünleşik olarak yönetimi esas alınmalıdır.

== 1.2. AMAÇ ==
Bu dokümanın amacı:

* Tedarik edilecek/edilen sistemlerin, ömür devri süresince hedeflenen muharebe ve/veya operasyon performansını maliyet etkin şekilde karşılayabilmesini sağlayacak bir Sistem Ömür Devri Yönetimi yaklaşımı ortaya koymak,
* Sistem Ömür Devri Yönetim yaklaşımının uygulanmasını sağlayacak ilke, usul ve esasları belirlemek,
* Sistem Ömür Devri Yönetimi faaliyetlerinin bütünlük içinde planlanmasına, koordine edilmesine, yürütülmesine, denetlenmesine ve iyileştirilmesine imkân sağlayacak ana çerçeveyi oluşturmak,
* Sistem Ömür Devri Yönetimi yaklaşımını SSB, TSK, diğer ihtiyaç makamları ve savunma sanayii firmalarında bir kültür olarak yaygınlaştırmak,
* Tedarik edilecek/edilen sistemlerin ömür devri yönetimi faaliyetlerinin ilgili birimler arasında koordineli ve iş birliği içerisinde yürütmek ve uygulamalarda standartları sağlamak,
* Sistemlerin ömür devri süre ve maliyetlerini belirlemeye ve kontrol etmeye yönelik altyapının oluşturulması,
* Sistemlerin ömür devri safhalarını ve safhalar arasındaki geçiş kriterlerini ortaya koyarak, envanterden çıkarma zamanlarını bilimsel istatistiki modellerle tahmin edecek esasları belirlemek, bu kapsamda çıkacak ihtiyaçları zamanında tespit etmek, önceden bu ihtiyaçlara yönelik planlama yaparak yeni sistemlerin envantere girmesini sağlamak, kaynakların daha etkin olarak kullanılmasını mümkün kılacak modellerin geliştirilmesi ile sistemlerin göreve hazır olma seviyelerini üst düzey tutmaktır.

Bu doküman, savunma ve güvenlik sektöründe görev alan tüm paydaşların sistem ömür devri yönetimi faaliyetlerinde rehberlik etmek üzere hazırlanmıştır.

== 1.3. KAPSAM ==
Bu doküman, Sistem Ömür Devri Yönetimi çerçevesinde yer alan tüm safhalara ve bu safhalarda yürütülecek faaliyetlere ilişkin esasları kapsamaktadır. Hedeflenen performans değerlerinin sağlanması için; tanımlanan her bir safhanın amacının, bu safhalarda yer alacak aşamaların, kilometre taşlarının, yürütülecek faaliyetlerin ve her bir safha ve aşamaya ait girdi ve çıktıların belirlenmesi gereklidir.

== 1.4. REHBERİN KULLANIMI ==
Bu doküman sistem ömür devri yönetimi kavramının ana hatlarıyla tanımlanması amacıyla 5 bölümden oluşmaktadır:

* İlk bölüm; giriş, amaç, kapsam, referanslar gibi genel bilgileri içermektedir. Ayrıca terim ve kısaltmalar da bu bölümün içindedir.
* İkinci bölümde, Sistem Ömür Devri Yönetimi kapsamında yer alan temel kavramlar hakkında bilgi verilmiştir.
* Üçüncü bölümde; Sistem Ömür Devri Yönetimi yapısı, safha, aşama, kilometre taşları tanımları, faaliyetler ve aralarındaki ilişkiler aktarılmıştır.
* Dördüncü bölümde, bir önceki bölümde tanımlanan yapıya göre Sistem Ömür Devri Yönetimi safhaları ve bu safhalara yönelik bilgiler detaylandırılmıştır.
* Beşinci bölümde, dokümanda yer alan bilgilerin Odak Sistemin bulunacağı safhaya ve proje türüne göre nasıl uyarlanacağı açıklanmıştır.
* Dokümanın son bölümünde ise ilgili ekler yer almaktadır.

== 1.5. REHBERİN GÜNCELLENMESİ ==
Rehber; ilgili paydaşların ihtiyacı doğrultusunda güncellenecektir. Değişiklikler, aşağıdaki Değişiklik İzleme Tablosu’ndan izlenecektir.

'''Tablo 1 Değişiklik İzleme Tablosu'''
{| class="wikitable"
|'''YAYIN NO'''
|'''YAYIN TARİHİ'''
|'''DEĞİŞİKLİK YAPILAN BÖLÜM/SAYFA'''
|'''AÇIKLAMA'''
|-
|01
|Ağustos 2021
|
|İlk yayın
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|}

== 1.6. REFERANSLAR ==
1. NATO STANDARD, AAP-20 NATO PROGRAMME MANAGEMENT FRAMEWORK (NATO Life Cycle Model), Rev. C, October 2015.

2. NATO STANDARD, AAP-48 NATO SYSTEM LIFE CYCLE PROCESSES, Rev. B, March 2013.

3. INCOSE SYSTEMS ENGINEERING HANDBOOK, A GUIDE FOR SYSTEM LIFE CYCLE PROCESSES AND ACTIVITIES, 2015.

4. ISO/IEC 15288, SYSTEMS AND SOFTWARE ENGINEERING – SYSTEM LIFE CYCLE PROCESSES, 2015.

5. TSSÖDYP Doküman Seti

{| class="wikitable"
|+
! colspan="2" |'''TSSÖDYP DOKÜMAN SETİ'''
|-
|'''DOKÜMAN ADI '''
| '''DOKÜMAN KODU'''
|-
|Sistem Ömür Devri Yönetimi Rehberi (Ana Çerçeve)
|TSSÖDYP-01
|-
|Sistem Ömür Devri Yönetimi Süreçleri Rehberi
|TSSÖDYP-02
|-
|Ürün Destek Stratejileri ve Modelleri Rehberi
|TSSÖDYP-03
|-
|Entegre Lojistik Destek (ELD) Rehberi
|TSSÖDYP-04
|-
|Entegre Lojistik Destek (ELD) İsterleri Hazırlama Rehberi
| TSSÖDYP-05
|-
|Lojistik Destek Analizleri ve Kayıtları Rehberi
|TSSÖDYP-06
|-
|Tedarik Zinciri Yönetimi Rehberi
|TSSÖDYP-07
|-
|Sistem Ömür Devri Yönetiminde Demodelik Yönetimi Rehberi
|TSSÖDYP-08
|-
|Kullanım ve Destek İhtiyaçları Çerçevesinde Yerlileştirme/

Millîleştirme Rehberi
|TSSÖDYP-09
|-
|Kullanım ve Destek Safhaları Kalite Yönetimi Rehberi
|TSSÖDYP-10
|-
|Sistem Ömür Devri Yönetiminde Konfigürasyon Yönetimi Rehberi
|TSSÖDYP-11
|-
|Teknik Yayın Hazırlama Rehberi
|TSSÖDYP-12
|-
|Eğitim ve Eğitim İhtiyaçları Rehberi
|TSSÖDYP-13
|-
|Sistem Ömür Devri Yönetimi Terminolojisi
|TSSÖDYP-14
|-
|Kodlandırma ve Sınıflandırma Bilgi Kitapçığı
|TSSÖDYP-15
|-
|ASD/AIA S-Serisi ELD Spesifikasyonları Seti Tanıtım Kitapçığı
|TSSÖDYP-16
|}

== 1.7. TANIMLAR VE KISALTMALAR ==

=== 1.7.1. TANIMLAR ===
'''Tablo 2 Tanımlar Tablosu'''
{| class="wikitable"
|'''Terim'''
|'''Tanım'''
|'''Diğer Kullanım'''
|-
|Araştırma-Geliştirme Research-Development
|Belirli bir konuyu anlamak üzere bilgi üretilmesini, üretilen bilginin uygulanmasıyla teknoloji geliştirilmesini veya elde edilen teknolojiyi kullanarak sistem geliştirilmesini amaçlayan, seri üretim içermeyen faaliyetlerdir.
|
|-
|Arıza

Failure
|Bir konfigürasyon biriminin kendinden beklenen şekilde çalışmaması ve/veya beklenen çıktıları üretememesi durumudur.
|
|-
|Aşama

Phase
|Safhalar içerisinde bulunan ve ilgili safhanın tamamlanabilmesi için gerekli çıktıların üretildiği bölümlerdir.
|
|-
|Bakım Görev Analizi

Maintenance Task Analysis
|Düzeltici ve önleyici faaliyetler için prosedürler, yedek parça, destek ekipmanı, personel beceri seviyesi, tahmini süreler, tesis gereksinimleri vb. bilgilerin çıkarılması sağlayan detaylı bir analizdir.
|
|-
|Demodelik Yönetimi

Obsolescence Management
|Tasarım, geliştirme, üretim ve ürün desteği dönemlerinde ürün içeriğindeki parçaların üretim sürecinde ya da bulunabilirliğinde meydana gelebilecek değişimlerden kaynaklanan problemlerin farkında olmak ve bu problemlerin etkilerini azaltmak için çözüm yöntemleri belirlemek amacıyla yürütülen düzeltici ve önleyici faaliyetlerin yönetilmesi disiplinidir.
|
|-
|Destek Safhası

Support Stage
|Odak Sistem ve destek unsurlarının işlev devamlılığını ve kullanım sürdürülebilirliğini etkinleştiren destek hizmetlerinin planlanması ve sağlanması safhasıdır.
|
|-
|Desteklenebilirlik

Supportability
|Sistem tasarım özelliklerinin ve planlanan lojistik kaynakların sistemden beklenen kullanıma hazır bulunma gereklerini sistemin ömür devri boyunca uygun maliyette karşılayabilme derecesidir.
|
|-
|Destek Unsurları

Enablling Systems
|Odak Sistemin belirlenen kullanım konsepti ve görev profilleri çerçevesinde istenilen performans seviyesinde görev yapabilmesi ve maliyet etkin olarak kullanımında sürekliliğin sağlanması için ihtiyaç duyulan unsurlardır.
|
|-
|Doğrulama

Verification
|Ürün ya da hizmetin istenen özellikte olduğunu; gerekleri karşıladığını; kullanıma uygunluğunu göstermek amacıyla yapılan sistematik değerlendirmelerdir.
|
|-
|Entegre Lojistik Destek

Integrated Logistics Support
|Ürünlerin lojistik destek gereksinimlerinin tanımlanması, analizi ve planlanmasına yönelik; lojistik planlama ve analiz, bakım/onarım (B/O), eğitim, teknik yayın ve diğer ilgili konularda, tasarım aşamasından itibaren, bilimsel yöntemler kullanarak planlanıp yürütülen işlevlerin bütünleşik ele alındığı çalışmalardır.
|Bütünleşik Lojistik Destek
|-
|Envanterden Çıkarma Safhası

Retirement Stage
|Kullanımdan kaldırılmasına karar verilmiş olan Odak Sistem, alt sistem, sistem elemanları ve/veya destek unsurlarının envanterden çıkarılması safhasıdır.
|Elden Çıkarma
|-
|Fiziksel Konfigürasyon Denetimi

Physical Configuration Audit
|Bir konfigürasyon kaleminin üretilmiş (İng. As-built) veya idame edilen (As-Maintained) konfigürasyonunun, teknik dokümanlarına göre resmi olarak incelenmesidir.
|Fiziksel Konfigürasyon Tetkiki
|-
|Fonksiyonel
Konfigürasyon

Denetimi

Functional

Configuration Audit
|Bir konfigürasyon biriminin sistem spesifikasyonları bünyesinde tanımlanan performans ve fonksiyonel karakteristiklerini sağladığını ve geliştirilmesinin tamamlandığını geçerli kılma amacıyla yapılan
denetimlerdir.
|Fonksiyonel Konfigürasyon Tetkiki
|-
|Geliştirme Safhası

Development Stage
|Belirlenen sistem çözümüne ve gereksinimlere uygun olarak Odak Sistem ve destek unsurlarının tasarımı, entegrasyonu, doğrulanması ve kalifikasyonu faaliyetlerinin yürütülmesi safhasıdır.
|
|-
|Göreve Hazır Bulunma Readiness
|İhtiyaç duyulan sistemin ilgili görev profili kapsamında kullanıma hazır bulunmasıdır.
|
|-
|Güvenilirlik

Reliability
|Belirli bir zaman periyodunda, istenen çevresel ve coğrafi şartlar altında ve belirlenen kullanım profillerinde sistemin gereken fonksiyonunu hata yapmadan yapabilme/başarabilme olasılığıdır.
|
|-
|Hata

Fault
|Sistem fonksiyonlarında azalma, kesilme ya da kayba neden olan olaylardır.
|
|-
|Hata Modları, Etkileri ve Kritiklik Analizi

Failure Modes, Effects and Criticality Analysis
|Bir sistem bünyesinde meydana gelebilecek potansiyel hata modlarının, etkilerinin ve kritiklik seviyelerinin değerlendirildiği analizdir.
|
|-
|İhtiyaç Makamı
|Bir malın, teçhizatın, sistemin ve hizmetin tedarik edilmesi için ihtiyacı tespit eden, tedarik edilmesi için teklif yapan, tedarik edildikten sonra kullanıcılara dağıtımını yapan makamdır.
|Kullanıcı

Müşteri
|-
|İşlevsel Konfigürasyon Denetimi

Functional Configuration Audit
|İşlevsel ve/veya tahsis edilmiş ana çizgileriyle belirlenmiş gereksinimleri başarmış bir konfigürasyon kaleminin işlevsel özelliklerinin resmi olarak incelenmesidir.
|İşlevsel Konfigürasyon Tetkiki
|-
|Kalifikasyon

Qualification
|Gereksinimlerin tam olarak ya da belirli sınırlar dahilinde karşılandığının gösterilmesidir.
|
|-
|Karar Noktası

Decision Gate
|Safhalar arasındaki geçişlerde, önceki safhada yapılmış çalışmaların yeterliliğinin ve sonraki safhada yapılacak çalışmalar için gerekli girdilerin değerlendirildiği karar noktalarıdır.
|
|-
|Kavramsal Tasarım

Conceptual Design
|Teklife Çağrı Dokümanlarında yer alan gereksinimlere göre sistem çözümüne yönelik çalışmaların yapılmasıdır.
|
|-
|Kilometre Taşı

Milestone
|Safha içerisindeki ilerlemeyi ölçmek için kullanılan kontrol noktalarıdır.
|
|-
|Konfigürasyon Yönetimi

Configuration Management
|Tüm ömür devri boyunca ürünün başarım, işlevsel ve fiziksel özelliklerini gereksinimler, tasarım, üretim ve işletim bilgileriyle uyumlu kılan ve bu uyumu koruyan teknik ve yönetsel süreçtir.
|
|-
|Konsept Safhası

Concept Stage
|Sistem çözümüne ilişkin detaylı çalışmaların yürütülerek sistem gereksinimlerinin tanımlandığı ve bu ihtiyaçların karşılanma esaslarının planlandığı safhadır.
|
|-
|Kritik Tasarım Gözden Geçirme

Critical Design Review
|Bir konfigürasyon birimi veya işlevsel olarak ilişkili konfigürasyon birimlerinin üretim aşamasına geçmeden önce, ilgili teknik dokümanlardaki tasarım çözümünün sistem, alt sistem ve arayüz gereksinimlerini karşılayacağının teyit edilmesidir. Teknik değerlendirmenin yanı sıra program riskleri ve proje takvimi değerlendirilmesi de yapılır.
|
|-
|Kullanım Safhası

Utilisation Stage
|Odak Sistem ve destek unsurlarının kullanıma alınması ve fiilen kullanılması safhasıdır.
|
|-
|Kullanıma Hazır Olma

Availability
|İhtiyaç duyulan sistemin, zamanın herhangi bir anında kullanıma hazır olma derecesidir.
|
|-
|Lojistik Destek Analizi

Logistic Support Analysis
|Ürün Ömür Devri boyunca ürün için ihtiyaç duyulacak lojistik destek kaynak ve ihtiyaçlarının tanımlanması ve geliştirilmesi, lojistik destek unsurlarının tasarıma etkilerinin belirlenmesi, destek problemi çıkarabilecek ve maliyeti artıracak noktaların erken tespiti ve lojistik destek veri tabanı oluşturulmasına yönelik yapılan çalışmalardır.
|
|-
|Lojistik Destek Analizi Planı

Logistic Support Analysis Plan
|Proje süresince yürütülecek LDA faaliyetlerinin kimler tarafından, nasıl ve hangi esaslara dayanılarak yürütüleceğinin anlatıldığı ve proje kapsamında hangi analizlerin yapılacağına ve nasıl yapılacağına dair hazırlanan plandır.
|
|-
|Malzeme Listesi

Bill of Material
|Birimlerin (örneğin ürün, alt ürün, bileşen ve ham malzemeler) arasındaki ata-çocuk ilişkisini tanımlayan dokümandır.
|Ürün Ağacı
|-
|Modernizasyon
|Savunma ve güvenlik kurumlarının modern araç, gereç ve sistemlerle donatılmasına yönelik faaliyetler ile envanterde mevcut olan sistemlerin/platformların veya yazılımların teknolojik gelişmelere ve savunma, harekât ve operasyonel ihtiyaçlara bağlı olarak performansının artırılmasıdır.
|
|-
|Odak Sistem

System of Interest
|Herhangi bir portföy/program/proje çerçevesinde, yeni bir temel yetenek kazandıran ya da mevcut bir temel yeteneğin kapsamlı modernizasyonuna yönelik olan, tedariki ve kullanım ve desteği yüksek maliyetli ve/veya gerçekleştirilmesi nispeten uzun zaman alacak olan savunma ve güvenlik sistemleridir.
|Savunma sistemi/ platformu, ana silah sistemi, ana sistem, ana malzeme, ürün ve benzerleri
|-
|Onarım Seviyeleri Analizi

Level of Repair Analysis
|Bir onarım faaliyeti için en ekonomoik ve verimli bakım seviyelerinin belirlendiği analizdir.
|
|-
|Operasyonel Konsept Dokümanı
|Sistemin belirlenen ihtiyaçlar doğrultusunda kullanım şeklinin tanımlandığı, üst seviye hedeflerinin ve gereksinimlerinin yer aldığı dokümandır.
|Kullanım Konsept Dokümanı
|-
|Ön Konsept Safhası

Pre-Concept Stage
|Harekât ve lojistik ihtiyaçlara esas gereksinimlere, yeteneklere ve risk alanlarına yönelik ihtiyacın giderilmesi için seçeneklerin belirlenmesi ve sistem çözümüne karar verilmesi halinde uygun sistem çözümüne yönelik ihtiyaç tanımının ana hatları ile ortaya koyulması faaliyetlerinin yürütüldüğü safhadır.
|
|-
|Ön Tasarım

Preliminary Design
|Sistem için İşlevsel Mimari Model ve Fiziksel Mimari Model oluşturulmasıdır.
|
|-
|Ön Tasarım Gözden Geçirme

Preliminary Design Review
|Bir konfigürasyon biriminin veya işlevsel olarak ilişkili konfigürasyon birimlerinin resmi teknik gözden geçirmesidir. Bu gözden geçirme faaliyetinde; sistem yerleşimi, kullanıcı arayüzü, sistem emniyeti, taşınabilirlik gibi sistem ve kullanıcı arayüzü etkileşimi konularında onay alınarak, alt sistem tasarım ve yerleşiminin kullanıcı ihtiyaçlarını karşılar nitelikte olacağı garanti edilir. Sistemin fonksiyonel hedefleri ile fiziksel sistemlerin eşleştiği gösterilir.
|
|-
|Ön Yapılabilirlik Etüdü
|Proje Tanımlama Dokümanlarında belirtilen sistem yeteneklerine dayanarak sistem alternatiflerinin hazırlandığı, her bir alternatife ilişkin taktik ihtiyaçlar ile endüstriyel imkânların karşılaştırıldığı, alternatif sistemlerin harekât etkinlik ve uygunluk ile performans ve tahmini maliyetinin değerlendirildiği, bu değerlendirmeye göre en maliyet-etkin sistem alternatifinin ve teknik özelliklerinin belirlendiği ayrıntılı çalışmalardır.
|
|-
|Prototip

Prototype
|Teknoloji geliştirme faaliyetleri sonucunda ortaya çıkan yeni ürün ve sürecin tüm teknik özelliklerini ve performansını içeren bir modelin oluşturulması, sistem/alt sistem modelinin güvenilirliğinin daha yüksek laboratuvar ya da sanal ortamda ve sistemin gerçek ortamda performansının gösteriminin yapılmasıdır.
|
|-
|Proje/İhtiyaç Tanımlama Dokümanı
|Projelerin veya ihtiyaçların her biri için hazırlanan ve ihtiyacın ortaya konmasından tedarik aşamasına kadar gerekli teknik, taktik ve lojistik bilgileri kapsayan bir etüt dokümanıdır.
|
|-
|Safha

Stage
|Sistem ömür devri içerisinde tanımlanmış, işin daha küçük, anlaşılır ve zamanlanabilir bir şekilde yürütülmesini sağlayan yapılardır.
|
|-
|Sistem Çözümü

Material Solution
|İhtiyacı karşılamaya yönelik sistem seçenekleri için her bir sistem seçeneği ile ilgili kullanım konseptlerinin ve ihtiyaç belirleme aşamasındaki verilerin dikkate alınarak değerlendirilmesidir.
|
|-
|Sistem Mimarisi

System Architecture
|Sistemin yapısını, davranışını ve diğer yönlerini belirleyen kavramsal yapıdır.
|
|-
|Sistem Ömür Devri

System Life Cycle
|İhtiyacın belirlenmesi ile başlayan, ön konsept, konsept, geliştirme, üretim, kullanım, destek safhalarından geçen ve ürünün envanterden çıkarılması safhası ile son bulan zaman dilimidir.
|
|-
|Sürdürülebilirlik

Sustainability
|Tanımlı koşullar altında operasyonel hedefleri başarmak için belirli bir oranı ya da seviyeyi muhafaza edebilme becerisidir.
|
|-
|Tedarik Makamı
|Tedarik faaliyetlerini yürütmekle yetkili kurumlardır.
|
|-
|Tedarik Zinciri Yönetimi

Supply Chain Management
|Alt yükleniciler, yükleniciler, tedarik makamı, ihtiyaç makamı ve kullanıcı arasındaki malzeme, para ve bilgi etkileşimlerini kapsayan bağlantı zincirine ilişkin; ham madde ve bileşenlerin tedariki, imalat ve montajı, dağıtım ve teslimi ile olası geri dönüşüm ve yeniden kullanım faaliyetlerinin bütünleşik yönetimidir.
|
|-
|Teklife Çağrı Dokümanı

Request for Proposal
|Tedarik edilecek ürün ve hizmet alımları ile yapım işlerinin teknik şartnamesi, ihale konusu işin tanımı, hangi şartlarda yapılacağı, sözleşme görüşmelerine esas mali, idari, hukuki hususları, teklif verme şekli gibi konuları kapsayan dokümandır.
|
|-
|Teknik Veri Paketi

Technical Data Package
|Bir ürünün temin, üretim, muayene, mühendislik ve lojistik destek faaliyetlerinin desteklenmesi için yeterli teknik tanımıdır. Teknik Veri Paketi; modeller, teknik resimler, ilgili listeler, şartnameler, standartlar, performans gereksinimleri, kalite güvence gereksinimleri, yazılım dokümantasyonu ve paketleme detayları gibi uygulanabilir teknik verilerden oluşur.
|
|-
|Test Edilebilirlik

Testability
|Test kriterlerinin belirlenme ve test performansını kolaylaştırma derecesidir.
|
|-
|Uyarlama

Tailoring
|Bulunduğu safha gereksinimlerine göre odak sistemin ömür devrine ilişkin yürütülen faaliyetlerin birtakım süreç ve iş ürünlerinde değişiklikler yapılarak ele alınmasıdır.
|
|-
|Üretim Safhası

Production Stage
|Kalifikasyonu tamamlanan Odak Sistem ve destek unsurlarının üretilmesi safhasıdır.
|
|-
|Üretim Hattı Kalifikasyonu

Production Line Qualification
|Üretim hattının tanımlı spesifikasyonlara uygunluğunun kontrolüdür.
|
|-
|Yapılabilirlik Etüdü
|Bir görev yeteneğinin karşılanması amacıyla sistemlerin kullanımına, geliştirilmesine ve üretimine esas hususların ortaya konulması, planlamalara dahil edilen ve ihtiyaçları karşılayabileceği tespit edilen platform/sistem/ alt sistem için bu platform/sistem/alt sisteme ait teknolojilerin mevcut durumunun analizi, ayrıntılı teknoloji analizlerinin yapılması, ömür devri dahil maliyetlerinin tespit edilmesi, risk yönetimi, görev ve harekat ihtiyacını karşılayan sistemin vazgeçilmez ve arzu edilen taktik ve teknik özelliklerinin envantere giriş zamanı açısından incelenmesi, proje yönetim esas ve usulleri ile tedarik makamının ve tedarik modelinin belirlenmesi, proje ile ilgili maliyet-etkinlik ve fayda değer analiz çalışmalarıdır.
|
|}

=== 1.7.2. KISALTMALAR ===
'''Tablo 3 Kısaltmalar Tablosu'''
{| class="wikitable"
|'''Kısaltma'''
|'''Açıklama'''
|'''Diğer Kullanım'''
|-
|ADB

SRU
|Atölyede Değiştirilebilir Birim

Shop Replaceable Unit
|
|-
|Ar-Ge

R&D
|Araştırma-Geliştirme

Research-Development
|
|-
|BGA

MTA
|Bakım Görev Analizi

Maintenance Task Analysis
|
|-
|BoM
|Ürün Ağacı

Bill of Materials
|Malzeme Listesi
|-
|DELTMATO

DOTMLPFI
|Doktrin, Eğitim, Liderlik, Teşkilat, Malzeme, Altyapı, Tesisler, Ortak Çalışabilirlik

Doctrine, Organization, Training, Materiel, Leadership and Education, Personnel, Facilities and Interoperability
|
|-
|ELD

ILS
|Entegre Lojistik Destek

Integrated Logistics Support
|
|-
|HDB

LRU
|Hatta Değiştirilebilir Birim

Line Replaceable Unit
|
|-
|HTEKA

FMECA
|Hata Türleri Etkileri ve Kritiklik Analizi

Failure Modes, Effects and Criticality Analysis
|
|-
|KTGG

CDR
|Kritik Tasarım Gözden Geçirme

Critical Design Review
|
|-
|LDA

LSA
|Lojistik Destek Analizi

Logistic Support Anaylsis
|
|-
|LDAP

LSAP
|Lojistik Destek Analizi Planı

Logistic Support Anaylsis Plan
|
|-
|OSA

LORA
|Onarım Seviyesi Analizi

Level of Repair Analysis
|
|-
|ÖTGG

PDR
|Ön Tasarım Gözden Geçirme

Preliminary Design Review
|
|-
|PPP
|Paket Proje Planı
|
|-
|PUT
|Proje Uygulama Takvimi
|
|-
|TÇD

RFP
|Teklife Çağrı Dosyası

Request for Proposal
|
|-
|TDAP
|Test ve Değerlendirme Ana Planı
|
|-
|TVP

TDP
|Teknik Veri Paketi

Technical Data Package
|
|}

== 1.8. TABLOLAR VE ŞEKİLLER ==

=== 1.8.1. TABLOLAR ===
Tablo 1 Değişiklik İzleme Tablosu

Tablo 2 Tanımlar Tablosu

Tablo 3 Kısaltmalar Tablosu

Tablo 4 Uyarlama

Tablo 5 Farklı Kurumlarda/Standartlarda Sistem Ömür Devri Safhaları Terminolojisi

=== 1.8.2. ŞEKİLLER ===
Şekil 1 Sistem; Odak Sistem ve Destek Unsurları

Şekil 2 Sistem Ömür Devri Safhaları

Şekil 3 Sistem Ömür Devri Maliyet Dağılımı

Şekil 4 Sistem Ömür Devri Sürecinde Alınan Kararların Gerçekleşen Maliyet Üzerindeki Etkisi

Şekil 5 Örnek Program Safhaları ve İlişkili Elemanlar

Şekil 6 Ön Konsept Safhası

Şekil 7 Konsept Safhası

Şekil 8 Geliştirme Safhası

Şekil 9 Üretim Safhası

Şekil 10 Kullanım Safhası

Şekil 11 Destek Safhası

Şekil 12 Envanterden Çıkarma Safhası

Şekil 13 Risk ve Süreç Denge Grafiği – McConnel, INCOSE SE Handbook.

= 2. SİSTEM ÖMÜR DEVRİ YÖNETİMİ =

== 2.1. TEMEL KAVRAMLAR ==
'''Sistem Ömür Devri;''' ihtiyacın belirlenmesi ile başlayan ve sistemin envanterden çıkarılması ile son bulan zaman dilimidir.
[[Dosya:Sistem Odak Sistem.png|alt=Şekil 1 Sistem; Odak Sistem ve Destek Unsurları|sol|küçükresim|600x600pik|Şekil 1 Sistem; Odak Sistem ve Destek Unsurları]]

'''Sistem;''' ömür devrinin ilk safhasından itibaren Odak Sistem ve Destek Unsurlarının ayrılmaz bir bütün halinde ele alındığı ve yönetildiği bileşenler topluluğudur.

'''Odak Sistem;''' herhangi bir portföy/program/proje çerçevesinde, yeni bir temel yetenek kazandıran ya da mevcut bir temel yeteneğin kapsamlı modernizasyonuna yönelik olan, tedariki, kullanımı ve desteği yüksek maliyetli ve/veya gerçekleştirilmesi nispeten uzun zaman alacak olan savunma ve güvenlik sistemleridir.

Odak Sistemin temel görevi, savunma ve güvenlik ihtiyacını belirlenen kullanım konsepti ve görev profilleri çerçevesinde istenilen performans seviyesinde karşılamaktır. Odak Sistem, sistemler sistemi olarak tanımlanabilecek bir yapı olabileceği gibi sadece alt sistemlerden ve sistem elemanlarından oluşan bir yapı da olabilir. Bu çerçevede, Odak Sistem – yukarıdaki tanıma uygun olacak şekilde - savunma sistemi/platformu, ana silah sistemi, ana sistem, ana malzeme, ürün, cihaz ve benzerlerini ifade etmektedir.

'''Destek Unsurları;''' Odak Sistemin belirlenen kullanım konsepti ve görev profilleri çerçevesinde istenilen performans seviyesinde görev yapabilmesi ve maliyet etkin olarak kullanımında sürekliliğin sağlanması için ihtiyaç duyulan unsurlardır. Destek Unsurları, bunlarla sınırlı olmamak üzere Şekil 1’deki hususları kapsar.

== 2.2. SİSTEM ÖMÜR DEVRİ YÖNETİMİNE GİRİŞ ==
Sistem Ömür Devri Yönetimi; performans, maliyet, takvim, kalite, çalışma ortamı, ELD ve demodelik kriterlerine dikkat edilerek sistemin ömür devri boyunca savunma yeteneklerini optimize etmeyi amaçlamaktadır.

İhtiyaç duyulan savunma ve güvenlik yeteneklerinin kazanılması ve sürdürülebilirliğinin sağlanmasına yönelik olarak Sistem Ömür Devri Yönetimi kapsamında aşağıda belirtilen faaliyetlerin icra edilmesi hedeflenmektedir:

* Harekât, operasyon ve lojistik ihtiyaçlara yönelik gereksinimlerin, yeteneklerin ve risk alanlarının belirlenmesi,
* İhtiyacın giderilmesine yönelik sistem seçeneklerinin belirlenmesi ve uygun sistem çözümüne karar verilmesi,
* Odak Sistem ile birlikte destek unsurlarının da kullanım, destek ve envanterden çıkarma safhalarındaki gereksinimleri karşılayacak şekilde; ihtiyaç tanımlama aşamasından itibaren göz önünde bulundurulması,
* Belirlenen sistem çözümüne ve hedeflenen performansa uygun olarak tasarım, geliştirme ve üretim faaliyetlerinin yürütülmesi,
* Tedarik edilen ve kullanıma alınan sistemin kullanım ve destek safhalarından elde edilen veriler dikkate alınarak sistem üzerinde gerekli iyileştirmelerin yapılması,
* Kullanımdan kaldırılmasına karar verilmiş olan Odak Sistem, alt sistem, sistem elemanları ve/veya destek unsurlarının envanterden çıkarılmasıdır.

Sistem ömür devri; uzun bir dönemi kapsamakta, yürütülen işler açısından farklılıklar göstermekte ve birbiri ile etkileşim içinde olan faaliyetlerden oluşmaktadır. Sistem ömür devrinin safhalara ayrılması sureti ile sistemlerin daha etkin yönetilmesi mümkün olmaktadır.

Sistem Ömür Devri Yönetimi aşağıda belirtilen yedi safhadan oluşur:

* Ön Konsept,
* Konsept,
* Geliştirme,
* Üretim,
* Kullanım,
* Destek,
* Envanterden Çıkarma.

Şekil 2’de görüldüğü üzere her bir safha, sistem ömür devrinde yürütülen temel faaliyetleri temsil eder.
[[Dosya:Şekil2 Sistem Ömür Devri.jpg|alt=Şekil 2 Sistem Ömür Devri Safhaları|sol|küçükresim|650x650pik|Şekil 2 Sistem Ömür Devri Safhaları]]

Sistem ömür devri safhaları, her bir safhada birbirleri ile etkileşim içinde olan faaliyetler dikkate alınarak eş zamanlı yürütülür. İhtiyacı karşılayacak sistem çözümünün bulunacağı safhaya ve proje türüne göre sistem ömür devri safhalarında uyarlamalar söz konusu olabilir.

Bu safhalar boyunca önleyici, geliştirici, düzeltici ve iyileştirici tedbirlerin alınarak muharebe ve/veya operasyon etkinliğinin sağlanması ve ömür devri maliyetinin kontrol altında tutulması amaçlanır.

Ön konsept, konsept, geliştirme ve üretim safhalarında verilen kararlar, Odak Sistemlerin kullanım safhasındaki performansı üzerinde önemli bir etkiye sahiptir. Odak Sistemlerin istenilen performans seviyesinde görev yapabilmesi ön konsept, konsept ve geliştirme safhalarında destek unsurlarına ilişkin yapılacak detaylı analizlere, planlara ve alınacak tedbirlere bağlıdır. Bu sebeple, programların/projelerin başlangıcından itibaren ürün destek stratejileri ve ELD Planları üzerinde çalışılmaya başlanmalıdır.

== 2.3. SİSTEM ÖMÜR DEVRİ MALİYETİ ==
Sistem ömür devri maliyeti; bir harekât ihtiyacının karşılanması kapsamında sistem çözümü kararının verilmesinden, ürünün envanterden çıkarılmasına kadar yürütülen faaliyetler sonucu ortaya çıkan maliyetlerin toplamıdır.

Ömür devri maliyetinin ana faaliyetlere göre dağılımı Şekil 3’te gösterilmiştir.
[[Dosya:Şekil3 Sistem Ömür Devri Maliyet.jpg|alt=Şekil 3 Sistem Ömür Devri Maliyet Dağılımı|sol|küçükresim|650x650pik|Şekil 3 Sistem Ömür Devri Maliyet Dağılımı]]

Şekil 3, ömür devri maliyetlerinin safhalara göre dağılımını; Tedarik Dönemi, Kullanım ve Destek Dönemi ve Envanterden Çıkarma Dönemi kırılımında yansıtmaktadır. Tedarik Dönemi, bu doküman içerisinde kullanılan terminoloji (Şekil 1) doğrultusunda Ön Konsept, Konsept, Geliştirme ve Üretim safhalarına karşılık gelmektedir. Ömür devri maliyetinin temel unsurları; araştırma-geliştirme, test ve değerlendirme, yatırım, üretim, kullanım, destek ve envanterden çıkarma maliyetleridir. Ömür devri maliyet unsurlarının, sistem ömür devri safhalarına göre dağılımını yapacak olursak; kullanım ve destek dönemine ilişkin maliyetler - farklı sistemlerde değişiklik göstermekle birlikte - toplam ömür devri maliyetinin ortalama % 70’ini oluşturmaktadır.

Kullanım ve destek safhalarındaki maliyetlerin sadece bu safhalarda alınacak tedbirler ve bu tedbirlere bağlı yürütülecek faaliyetler ile istenilen oranda düşürülmesi mümkün değildir. Şekil 4’te görüldüğü üzere; yapılan bilimsel çalışmalar, ömür devri maliyetinin % 90-95 oranında tedarik döneminde alınan kararlar ile belirlendiğini göstermektedir.
[[Dosya:ŞEKİL4 Sistem Ömür Devri Sürecinde Alınan Kararların Gerçekleşen Maliyet Üzerindeki Etkisi.jpg|alt=Şekil 4 Sistem Ömür Devri Sürecinde Alınan Kararların Gerçekleşen Maliyet Üzerindeki Etkisi|sol|küçükresim|650x650pik|Şekil 4 Sistem Ömür Devri Sürecinde Alınan Kararların Gerçekleşen Maliyet Üzerindeki Etkisi]]

Ön konsept, konsept, geliştirme ve üretim safhalarında verilen kararlar, Odak Sistemlerin kullanım ve destek safhalarındaki maliyetlerini büyük ölçüde etkilemektedir. Sistem ömür devri maliyetlerinde önemli oranda tasarruf sağlanabilmesi bahse konu odak sistemlerin ön konsept, konsept ve geliştirme safhalarında yapılacak detaylı analizlere ve bu analizlerin sonucunda alınacak kararlara bağlıdır.

== 2.4. SİSTEM ÖMÜR DEVRİ SAFHALARINA GENEL BAKIŞ ==
Sistem Ömür Devri Yönetimi Rehber Dokümanı kapsamında, safha ve aşamalarda gerçekleştirilecek faaliyetler ve hazırlanacak dokümanlar tanımlanmaya çalışılmış, bu faaliyetler için herhangi bir sorumluluk belirtilmemiştir. Tüm safha ve aşamalarda ilgili mevzuat ve düzenlemeler gereğince ana sorumlularla birlikte ilgili paydaşların yer alabileceği değerlendirilmiştir.

'''Ön Konsept Safhası'''

Harekât ve lojistik ihtiyaçlara esas gereksinimlere, yeteneklere ve risk alanlarına yönelik ihtiyacın giderilmesi için seçeneklerin belirlenmesi ve sistem çözümüne karar verilmesi halinde uygun sistem çözümüne yönelik ihtiyaç tanımının ana hatları ile ortaya koyulması faaliyetlerinin yürütüldüğü safhadır.

'''Konsept Safhası'''

Sistem çözümüne ilişkin detaylı çalışmaların yürütülerek sistem gereksinimlerinin tanımlandığı ve bu ihtiyaçların karşılanma esaslarının planlandığı safhadır.

'''Geliştirme Safhası'''

Belirlenen sistem çözümüne ve gereksinimlere uygun olarak Odak Sistem ve destek unsurlarının tasarımı, entegrasyonu, doğrulanması ve kalifikasyonu faaliyetlerinin yürütülmesi safhasıdır.

'''Üretim Safhası'''

Kalifikasyonu tamamlanan Odak Sistem ve destek unsurlarının üretilmesi safhasıdır.

'''Kullanım Safhası'''

Odak Sistem ve destek unsurlarının kullanıma alınması ve fiilen kullanılması safhasıdır.

'''Destek Safhası'''

Odak Sistem ve destek unsurlarının işlev devamlılığını ve kullanım sürdürülebilirliğini etkinleştiren destek hizmetlerinin planlanması ve sağlanması safhasıdır. Odak Sisteme ve destek unsurlarına ilişkin desteğin planlanması; Ön Konsept, Konsept, Geliştirme, Üretim ve Kullanım safhalarındaki çalışmalarla birlikte yürütülür.

'''Envanterden Çıkarma Safhası'''

Kullanımdan kaldırılmasına karar verilmiş olan Odak Sistem, alt sistem, sistem elemanları ve/veya destek unsurlarının envanterden çıkarılması safhasıdır.

= 3. SİSTEM ÖMÜR DEVRİ YÖNETİM YAKLAŞIMI =

== 3.1. GENEL ==
Aşağıdaki şekilde bir savunma ve güvenlik programının sistem ömür devri yönetimi safhaları şematik olarak gösterilmiştir. Bu şematik gösterimden yola çıkılarak programın sistem ömür devri yönetimindeki safhaları, aşamaları, karar noktaları, giriş ve çıkış kriterleri ile kilometre taşları açıklanacaktır. Bu safhaların her birinde yapılacak çalışmalarda, bilimsel teknik ve yöntemlerden faydalanılır. Örneğin; karar noktalarında karar ağaçları kullanılması verilecek kararlarda kolaylık sağlayacaktır.
[[Dosya:Şekil5.png|alt=Şekil 5 Örnek Program Safhaları ve İlişkili Elemanlar|sol|küçükresim|650x650pik|Şekil 5 Örnek Program Safhaları ve İlişkili Elemanlar]]

=== 3.1.1. SAFHALAR ===
Bir tedarik programı/projesi; Ön Konsept, Konsept, Geliştirme, Üretim, Kullanım, Destek ve Envanterden Çıkarma olmak üzere yedi safhadan oluşmaktadır.

5’te de görüldüğü üzere programın her safhasında girdiler, çıktılar ve safhaların sonundaki karar noktalarında incelenecek olan giriş ve çıkış kriterleri bulunmaktadır. Safhaların en başında safha boyunca yapılacak çalışmaları yönlendirmek, çalışmalar sırasında ihtiyaç duyulacak bilgileri sağlamak amacıyla girdiler bulunmaktadır.

Safhaların sonlarında ise safha boyunca girdiler ve yapılan çalışmalar ile üretilmiş bilgiler çıktı olarak belirtilmiştir.

Safha 1 ve Safha 2 ardışık olarak yürütülebildiği gibi birbiri ile eş zamanlı olarak da yürütülebilir. Eş zamanlı olarak yürütülecek olan safhalara geçiş için geçilecek safhaya ilişkin girdilerin tamamlanması gereklidir. Safhaların tamamlanması için ise ilgili safhaya ilişkin çıkış kriterlerinin tamamlanması yeterlidir.

Program safhalarının başlangıç ve bitişi programın tümü ile birlikte değerlendirilmelidir.

=== 3.1.2. GİRDİLER VE ÇIKTILAR ===
Şekil 5’te de görüldüğü üzere bir programın ilgili safhasının başlaması için her safhaya özel olarak tanımlanmış girdilerin tamamlanmış olması gerekmektedir.

Girdiler, ihtiyaç veya tedarik makamından alınan bilgiler olabildiği gibi, ilgili safhada yapılacak analiz çalışmalarına girdi oluşturabilecek diğer çalışmaların sonucunda üretilen rapor/doküman vb. de olabilmektedir.

Bununla birlikte bir programın ilgili safhasında yapılan çalışmaların sonucunda ortaya çıkan bilgi paketleri dokümanlar ve/veya raporlar ilgili safhanın çıktısıdır. Safhanın tamamlanabilmesi için çıkış kriterlerinden bir tanesi de ilgili safhanın çıktılarının tamamlanmış olmasıdır. Özellikle bir sonraki safhada girdi olarak kullanılacak çıktılar her safhanın sonunda mutlaka çıktı olarak ortaya konulmalıdır.

=== 3.1.3. FAALİYETLER ===
Safhaların içerisinde girdilerin çıktılara dönüştürülmesi için yapılan tüm çalışmalardır. Faaliyetler, safhaların detaylı olarak anlatıldığı bölümde aşamalar kırılımında ele alınacaktır.

=== 3.1.4. AŞAMALAR ===
Safhalar içerisinde bulunan ve ilgili safhanın tamamlanabilmesi için gerekli çıktıların üretildiği yerlerdir. Aynı safha içinde yer alan aşamalarda yapılan çalışmalar ardışık bir sıra takip eder.

=== 3.1.5. KARAR NOKTALARI ===
Karar noktaları; safhalar arasındaki geçişlerde, önceki safhada yapılmış çalışmaların yeterliliğinin ve sonraki safhada yapılacak çalışmalar için gerekli girdilerin değerlendirildiği, aynı zamanda öğrenilmiş derslerin kaydedildiği noktalardır.

Karar noktalarında alınan kararlar gereği bir sonraki safhaya geçiş ve bir önceki safhadan çıkış onaylanmış olur. Karar noktaları; imzalı toplantı tutanakları, rapor ve/veya program yönetiminin kabul ettiği herhangi bir şekilde geçilebilir.

Karar noktalarında alınan bazı kararlar aşağıda listelenmiştir.

* Bir sonraki safhaya geçiş ve o safhadaki çalışmaların yürütülmesi kararı
* Mevcut safhaya devam etme kararı
* Daha önceki safhaya dönme veya daha sonraki bir safhaya atlama kararı
* Programın askıya alınması kararı
* Programın sonlandırılması kararı

=== 3.1.6. GİRİŞ ve ÇIKIŞ KRİTERLERİ ===
Giriş ve çıkış kriterleri; karar noktalarında alınacak kararları desteklemek amacıyla kullanılan ölçütlerdir.

Karar noktalarında giriş ve çıkış kriterlerinin birden farklı şekilde ele alındığı durumlar vardır.

1. Safha 1’den Safha 2’ye geçişte, Safha 1’in çıkış kriterleri ve Safha 2’nin giriş kriterleri karar noktasında alınacak kararlar açısından belirleyici olur.

2. Herhangi bir safhanın yalnızca giriş kriteri ilgili safhaya geçiş için karar noktasında alınacak kararlarda belirleyici olur. Bu durum genellikle eşgüdüm içerisinde yürütülecek safhalarda karşılaşılan bir durumdur.

3. Herhangi bir safhanın yalnızca çıkış kriteri ilgili safhadan çıkış için karar noktasında alınacak kararlarda belirleyici olur. Bu durum genellikle ömür devri yönetiminin sonuna gelindiğinde ya da ilgili safhanın sonunda başka bir safhaya geçilmeyecek ise karşılaşılan bir durumdur.

=== 3.1.7. KİLOMETRE TAŞLARI ===
Karar noktalarından farklı olarak kilometre taşları, safhaların içerisindeki aşamalar arasında veya herhangi bir noktada süreci gözlemlemek amacıyla bulunurlar. İlgili safhalarda, kilometre taşları “M [Safha No]. [Sıra No]” şeklinde numaralandırılmıştır.

= 4. SİSTEM ÖMÜR DEVRİ SAFHALARI =

== 4.1. ÖN KONSEPT SAFHASI ==

=== 4.1.1. AMAÇ ===
Ön Konsept Safhasının amacı;

* Yetenek kazanımına veya bir tehdidin ortadan kaldırılmasına yönelik harekât ve lojistik ihtiyaçların belirlenmesi ve tanımlanması,
* Sistem çözümüne gidilmeden ihtiyaçların mevcut imkân ve kabiliyetlerle veya bunların geliştirilmesi suretiyle karşılanma imkânının araştırılması,
* Sistem çözümüne ihtiyaç olup olmadığı kararının verilmesi,
* Sistem çözümüne karar verilmesi halinde,
** Harekât ihtiyacını karşılayacak seçeneklerin belirlenmesi ve değerlendirilmesi,
** Uygun sistem çözümüne yönelik ihtiyaç tanımının ana hatları ile ortaya konulduğu Proje/İhtiyaç Tanımlama Dokümanı ve eklerinin hazırlanmasıdır.

=== 4.1.2. TANIM ===
Ön Konsept Safhası; harekât ve lojistik destek ihtiyaçlarının mevcut imkân ve kabiliyetlerle karşılanıp karşılanamayacağı hususunun belirlenmesi, karşılanamaması halinde maliyet, performans, süre ve risk gibi hususlar göz önünde bulundurularak olası sistem seçeneklerinin oluşturulması, değerlendirilmesi ve uygun sistem çözümüne yönelik ihtiyaç tanımının ana hatları ile ortaya konulması faaliyetlerini kapsayan safhadır. Bu safhada yürütülen faaliyetler ve alınan kararlar başlatılacak program/proje üzerinde önemli bir etkiye sahiptir.

=== 4.1.3. AŞAMALAR ===
Ön Konsept Safhası, iki aşamadan ve iki kilometre taşından oluşur. Her aşamanın girdileri, çıktıları, başarım kriterleri ve aşamalar süresince tüm paydaşlarca değerlendirilerek üretilen iş ürünleri vardır. Aşamalar boyunca yapılan gözden geçirmelerde, ilgili aşama sonunda üretilmesi gereken iş ürünleri ve risk tanımlamaları incelenerek riski yönetmek için alınması gereken eylemler karara bağlanır.

* İhtiyaç Belirleme Aşaması
** İlgili Kilometre Taşları: M1.1 - Sistem çözümüne ihtiyaç olup olmadığı kararı

* İhtiyaç Tanımlama Aşaması
** İlgili Kilometre Taşları: M1.2 - Proje başlatılmak üzere dokümanların tedarik makamına gönderilmesi kararı

=== 4.1.4. FAALİYETLER ===
'''Savunma ve Güvenlik İhtiyaçlarının Belirlenme Aşaması'''

Bu aşamanın amacı; harekât ve lojistik destek ihtiyaçlarının,

* Harekât verileri
* Tatbikat verileri,
* Tehditlerdeki değişimler,
* Yasal yükümlülükler,
* Teknolojik yenilikler,
* Alternatifler (DELTMATO - Doktrin, Eğitim, Liderlik, Teşkilat, Malzeme, Altyapı, Tesisler, Ortak çalışabilirlik),
* Mevcut imkân ve kabiliyetler ile uzun vadede sahip olunmasına ihtiyaç duyulan imkân ve kabiliyetler,
* Muharebe ve/veya operasyon alanının coğrafi, atmosferik ve çevresel şartları,
* Kaynak durumu,
* İşletme ve lojistik destek sürecinde yaşanan zafiyetler ve elde edilen veriler,
* Ülkemizdeki sosyoekonomik gelişmeler

değerlendirilerek karşılanıp karşılanamayacağının belirlenmesi aşamasıdır.

* Hazırlanan Dokümanlar: Mevcut imkân ve kabiliyetlerle karşılanamayan ürünler için proje kararı
* Gözden Geçirmeler: İhtiyacın mevcut imkân ve kabiliyetlerle karşılanıp karşılanamadığı, Sistem çözümüne ihtiyaç olup olmadığı

'''İhtiyaç Tanımlama Aşaması'''

Bu aşamanın amacı; ihtiyacı karşılamaya yönelik sistem seçenekleri için her bir sistem seçeneği ile ilgili kullanım konseptlerinin ve ihtiyaç belirleme aşamasındaki verilerin dikkate alınarak değerlendirilmesidir. Bu aşamada ön yapılabilirlik çalışması yürütülerek en iyi sistem çözümüne yönelik ihtiyaç tanımı ana hatları ile ortaya konulur ve yürütülen faaliyetler ile genel amaç ve hedefleri belirleyen bir yol haritası çizilir.

* Hazırlanan Dokümanlar: Proje/İhtiyaç Tanımlama Dokümanı,
* Gözden Geçirmeler: Hazırlanan dokümanların uygunluğu

=== 4.1.5. KİLOMETRE TAŞLARI ===
Ön Konsept safhasındaki kilometre taşları:

* M1.1: Sistem çözümüne ihtiyaç olup olmadığı kararı
* M1.2: Proje başlatmak üzere dokümanların tedarik makamına gönderilmesi kararı

=== 4.1.6. GİRİŞ KRİTERLERİ ===

* Yetenek kazanımı,
* Harekât ve/veya lojistik ihtiyacın bulunması

=== 4.1.7. ÇIKIŞ KRİTERLERİ ===

* Proje/İhtiyaç Tanımlama Dokümanının oluşturulmuş olması

=== 4.1.8. GİRDİLER ===

* Harekât Verileri
* Tatbikat Verileri
* Tehditlerdeki Değişimler
* Yasal Yükümlülükler
* Teknolojik Yenilikler
* Alternatifler (DELTMATO – Doktrin, Eğitim, Liderlik, Teşkilat, Malzeme, Altyapı, Tesisler ve Ortak Çalışabilirlik)
* Mevcut İmkân ve Kabiliyetler

=== 4.1.9. ÇIKTILAR ===

* Proje/İhtiyaç Tanımlama Dokümanı
* Operasyonel Konsept Dokümanı
[[Dosya:TSSODYP01.06.jpg|alt=Şekil 6 Ön Konsept Safhası|sol|küçükresim|724x724pik|Şekil 6 Ön Konsept Safhası]]

== 4.2. KONSEPT SAFHASI ==

=== 4.2.1. AMAÇ ===
Konsept safhasının amacı;

* Harekât ve lojistik destek ihtiyacının karşılanmasına yönelik olarak, ana hatları ortaya konulan ihtiyaç tanımına ilişkin sistem çözümünün yapılabilirliğinin değerlendirilmesi,
* Sistem tedarikine yönelik planlamaların yapılarak Teklife Çağrı Dokümanının (TÇD) hazırlanması ve yayımlanması,
* Tedarik sözleşmesinin imzalanmasıdır.

=== 4.2.2. TANIM ===
Sistem çözümüne ilişkin detaylı çalışmalar kapsamında Yapılabilirlik Etüdü’nün hazırlandığı, sistem gereksinimlerinin tanımlandığı ve bu gereksinimlerin karşılanma esaslarının planlandığı safhadır. Bu safhada alınan kararlar; maliyet, performans (göreve hazır olma, görevi yerine getirme) ve desteklenebilirlik açısından sistem ömür devri üzerinde büyük bir etkiye sahiptir.

=== 4.2.3. AŞAMALAR ===

* İnceleme ve TÇD Hazırlama Aşaması
** İlgili Kilometre Taşları: M2.1 - TÇD ve eklerinin yayınlanması kararı

* Teklif Değerlendirme ve Sözleşme Görüşmeleri Aşaması
** İlgili Kilometre Taşları: M2.2 - Sözleşme imzalanması

=== 4.2.4. FAALİYETLER ===
'''İnceleme ve TÇD Hazırlama Aşaması'''

İnceleme aşamasında, sistem çözümüne ilişkin ihtiyaçlar detaylandırılarak gereksinimlere dönüştürülür. Sistem gereksinimlerinin eksiksiz tespit edilebilmesi ve uzun vadeli ürün destek stratejilerinin oluşturulabilmesi için tüm paydaşların (ihtiyaç ve tedarik makamı, sanayici, üniversiteler vb.) katılımı sağlanmalıdır. İnceleme aşamasında yapılan çalışmalara bağlı olarak Proje/İhtiyaç Tanımlama Dokümanı, Konsept safhasında güncellenebilir.

* Hazırlanan Dokümanlar: Yapılabilirlik Raporu, kullanım ve görev profilleri, TÇD ve Ekleri
* Gözden Geçirmeler: Sistem gereksinimlerinin gözden geçirilmesi, Ürün destek stratejilerinin ve modellerinin değerlendirilmesi (Lojistik Destek, Sanayii Katılımı, Kamu Özel Sektör İş birlikleri vb.)

'''Teklif Değerlendirme ve Sözleşme Görüşmeleri Aşaması'''

Bu aşamada gereksinimlerin ne oranda sağlanabildiğine dair genel bir değerlendirme yapmak amacıyla; yapılabilirlik çalışmalarından faydalanılarak maliyet, performans, süre ve risk analizleri gerçekleştirilir. Önerilen sistem çözümü için kurulacak program çerçevesinde ürüne ve programa özgü destek stratejileri geliştirilir ve başlangıç ELD Planlarına aktarılır.

* Hazırlanan Dokümanlar: Operasyonel Konsept Dokümanı, Sözleşme ve Ekleri (Teknik İsterler, İş Tanımı ve diğerleri), Ürün Destek Stratejisi ve Modeli (Yerlileştirme/Millîleştirme dahil), Ömür Devri Maliyet Tahmini, Kullanım Konsepti ve Görev Profilleri, Risk Değerlendirme Planı, Proje Uygulama Takvimi, Proje Yönetim Planı, ELD Planı, Kalite Yönetim Planı, Konfigürasyon Yönetim Planı, Demodelik Yönetim Planı

* Gözden Geçirmeler: Teklif Gözden Geçirmeleri

=== 4.2.5. KİLOMETRE TAŞLARI ===
Konsept safhası kilometre taşları:

* M2.1: TÇD ve Eklerinin Yayınlanması Kararı
* M2.2: Sözleşme İmzalanması

=== 4.2.6. GİRİŞ KRİTERLERİ ===

* Uygun sistem çözümüne yönelik ihtiyaç tanımının ana hatları ile ortaya konulmuş olması

=== 4.2.7. ÇIKIŞ KRİTERLERİ ===

* Sözleşmenin imzalanması

=== 4.2.8. GİRDİLER ===

* Proje/İhtiyaç Tanımlama Dokümanı,
* Operasyonel Konsept Dokümanı.

=== 4.2.9. ÇIKTILAR ===

* Sözleşme ve Ekleri
* Operasyonel Konsept Dokümanı
* Ürün Destek Stratejisi ve Modeli (Yerlileştirme/Millîleştirme dahil)
* Ömür Devri Maliyet Tahmini
* Risk Değerlendirme Planı
* Proje Yönetim Planı
* ELD Planı
* Kalite Yönetim Planı
* Konfigürasyon Yönetim Planı
* Demodelik Yönetim Planı

[[Dosya:ŞEKİL7Konsept Safhası.jpg|alt=Şekil 7 Konsept Safhası|sol|küçükresim|733x733pik|Şekil 7 Konsept Safhası]]

== 4.3. GELİŞTİRME SAFHASI ==

=== 4.3.1. AMAÇ ===
Geliştirme safhasının amacı, gereksinimleri karşılayacak bir Odak Sistemi tasarlamak ve üretime hazır hale getirmektir. Bu süreç sonunda tasarlanan Odak Sistemin üretilebilir, test edilebilir, değerlendirilebilir, işletilebilir, desteklenebilir ve kullanımdan kaldırılabilir nitelikte olması gerekmektedir. Odak sistem çalışmalarına paralel olarak ELD elemanlarına ilişkin detay çalışmalara bu safhada başlanır.

=== 4.3.2. TANIM ===
Geliştirme Safhası, Konsept Safhasının temel çıktısı olan program/proje sözleşmesinin imzalanması ile başlar. Bu safhada sözleşme (ekleri dahil) ve Operasyonel Konsept Dokümanı esas alınarak faaliyetler yürütülür. Yükleniciler, teklif çalışmaları kapsamında hazırlamış oldukları dokümanları sözleşme ve Operasyonel Konsept Dokümanı ile uyumlu olmak veya uyumlu hale getirmek şartıyla bu safhada kullanabilirler. Bağlayıcı olan sözleşmedir. Geliştirme safhası Odak Sisteme ilişkin dokümantasyonun ve kayıtların oluşturulması ile tamamlanır. Bu safha süresince Odak Sistemin konfigürasyonu kademeli olarak gelişir ve üretim safhası için hazır hale gelir.

Geliştirme Safhası toplam 6 aşamadan ve bu aşamalar içinde gerçekleştirilen toplam 10 adet kilometre taşından oluşur. Her aşamanın kendi girdileri, çıktıları, başarım kriterleri ve aşamalar süresince üretilen iş ürünleri mevcuttur. Aşamalar boyunca yapılan gözden geçirmelerde, ilgili aşama sonunda üretilmesi gereken iş ürünleri ve risk tanımlamaları gözden geçirilerek riski yönetmek için yürütülmesi gereken faaliyetler karara bağlanır.

=== 4.3.3. AŞAMALAR ===

* Kavramsal Tasarım Aşaması
** İlgili Kilometre Taşları: -

* Sistem Gereksinim Tanımlama Aşaması
** İlgili Kilometre Taşları: M3.1

* Ön Tasarım Aşaması
** İlgili Kilometre Taşları: M3.2, M3.3

* Detay Tasarım Aşaması
** İlgili Kilometre Taşları: M3.4

* Entegrasyon ve Doğrulama Aşaması
** İlgili Kilometre Taşları: M3.5, M3.6, M3.7

* Ürün Kalifikasyon Aşaması
** İlgili Kilometre Taşları: M3.8, M3.9, M3.10

=== 4.3.4. FAALİYETLER ===
'''Kavramsal Tasarım Aşamasında;''' Sözleşmede yer alan gereksinimlere göre sistem çözümüne yönelik çalışmalar yapılır. Başlangıç tasarım çözümü çizimler, modeller, prototipler vb. yollar ile belirlenir. Kavramsal tasarım çalışmaları yüklenici adayı tarafından sözleşmeden önce gerçekleştirilmiş ise sonuçlar teklif dokümanları ile sunulabilir. Ancak, sözleşme imzasından sonra kavramsal tasarımın sözleşme hükümlerine uygun hale getirilmesi gerekir. Kavramsal tasarıma ilişkin sonuçlar Kavramsal Tasarım Raporu ile sunulur.

* Hazırlanan Dokümanlar: Kavramsal Tasarım Raporu (Teklif Dokümanları ile sunulmuş olması durumunda sözleşme hükümlerine uygun hale getirilmesi zorunludur)
* Gözden Geçirmeler: -

'''Sistem Gereksinim Tanımlama Aşamasında;''' paydaş isteklerinin ayrıştırılması, türetilmesi ve sınıflandırılması ile önceliklendirilmesi yapılır. Tanımlanan gereksinimler için doğrulama yöntemleri belirlenir.

* Hazırlanan Dokümanlar: Sistem Gereksinim Tanımlama Dokümanı
* Gözden Geçirmeler: Sistem Gereksinimleri Gözden Geçirme Toplantısı

'''Ön Tasarım Aşamasında;''' Sistemin İşlevsel Mimari Model ve Fiziksel Mimari Model’i oluşturulur. Alt sistem gereksinim analizi ve alt sistem gereksinim tanımlama faaliyetleri gerçekleştirilir.

* Hazırlanan Dokümanlar: Sistem Tasarım Tanımlama (STT) Dokümanı, Sistem Arayüz Kontrol Dokümanı, Test ve Değerlendirme Ana Planı (TDAP), Alt Sistemler için Gereksinim Tanımlama Dokümanları, Güncellenmiş ELD Planı ve Alt Planları (Teknik Dokümantasyon Planı, Planı, Eğitim Planı, LDAP, Envanterden Çıkarma Planı vb.)
* Gözden Geçirmeler: Ön Tasarım Gözden Geçirme Toplantısı

'''Detay Tasarım Aşamasında;''' alt sistem ve sistem detaylı analiz (performans, yapısal, dinamik, termal, güvenilirlik vb.) ve tasarım faaliyetleri (yapısal, fonksiyonel, yazılım, ara yüz) gerçekleştirilir. Üretim ve test faaliyetleri için gereken hazırlık yapılır. Ön Tasarım Aşamasında hazırlanan Test ve Değerlendirme Ana Planı içerisinde, bu aşamanın çıktısı olarak verilen Sistem ve Alt Sistem Doğrulama Planları yer alabilir.

* Hazırlanan Dokümanlar: TVP (katı modeller, teknik resimler, şartnameler, Ürün Ağacı, yazılım, dokümantasyon vb.), Sistem ve Alt Sistem Doğrulama Planları, LDA Çıktıları, Güvenilirlik ve Emniyet Çıktıları, Güncellenmiş Sistem Ömür Devri Yönetim Stratejisi ve Modeli
* Gözden Geçirmeler: Kritik Tasarım Gözden Geçirme (Kritik tasarım gözden geçirme faaliyetlerine ELD birimlerinin katılımı sağlanmalıdır.)

'''Entegrasyon ve Doğrulama Aşamasında;''' tanımlı doğrulama yöntemleri ile entegrasyonu yapılan prototiplerin (sistem ve alt sistem) test ve değerlendirme faaliyetleri sistem ve alt sistem gereksinim tanımlama dokümanları ve tasarım doğrulama planlarına göre gerçekleştirilir.

* Hazırlanan Dokümanlar: Doğrulama Test Prosedürleri, Doğrulama Sonuç Raporları
* Gözden Geçirmeler: Test Hazırlıkları Gözden Geçirme Toplantısı, Tasarım Doğrulama Gözden Geçirme Toplantısı
* Denetimler: İşlevsel Konfigürasyon Denetimi

'''Ürün Kalifikasyon Aşamasında;''' tanımlı doğrulama yöntemleri ile entegrasyonu yapılan prototiplerin (sistem ve alt sistem) test ve değerlendirme faaliyetleri müşteri istekleri ve sistem gereksinim tanımlama dokümanlarına uygun olarak hazırlanan test prosedürlerine göre gerçekleştirilir. Seri üretim aşaması için hazırlıklar tamamlanır. Bu süreç sonunda gerçeklenen Odak Sistemin üretilebilir, test edilebilir, değerlendirilebilir, işletilebilir, desteklenebilir ve kullanımdan kaldırılabilir nitelikte olması güvence altına alınır.

* Hazırlanan Dokümanlar: Kalifikasyon Test Prosedürleri, Kalifikasyon Sonuç Raporları
* Gözden Geçirmeler: Kalifikasyon Gözden Geçirme Toplantısı, Üretim Hazırlıkları Gözden Geçirme Toplantısı
* Denetimler: Fiziksel Konfigürasyon Denetimi

=== 4.3.5. KİLOMETRE TAŞLARI ===
Geliştirme Aşamasındaki kilometre taşları yapılacak gözden geçirme toplantıları ve konfigürasyon denetimlerinden oluşmaktadır:

* M3.1: Sistem Gereksinimleri Gözden Geçirme Toplantısı
* M3.2: Sistem Fonksiyonel Gözden Geçirme Toplantısı
* M3.3: Ön Tasarım Gözden Geçirme Toplantısı
* M3.4: Kritik Tasarım Gözden Geçirme Toplantısı
* M3.5: Test Hazırlıkları Gözden Geçirme Toplantısı
* M3.6: Tasarım Doğrulama Gözden Geçirme Toplantısı
* M3.7: İşlevsel Konfigürasyon Denetimi
* M3.8: Kalifikasyon Gözden Geçirme Toplantısı
* M3.9: Fiziksel Konfigürasyon Denetimi
* M3.10: Üretim Hazırlıkları Gözden Geçirme Toplantısı

=== 4.3.6. GİRİŞ KRİTERLERİ ===
Konsept safhasının çıktılarının oluşturulmuş olması

=== 4.3.7. ÇIKIŞ KRİTERLERİ ===
Odak Sistem ile ilgili dokümantasyonun ve Teknik Veri Paketinin oluşturulmuş olması

=== 4.3.8. GİRDİLER ===

* Sözleşme ve Ekleri
* Operasyonel Konsept Dokümanı
* Ürün Destek Stratejisi ve Modeli (Yerlileştirme/Millîleştirme dahil)
* Kavramsal Tasarım Raporu / Teklifi (Sözleşme’nin bağlayıcı nitelikte olması sebebiyle sözleşme imzasından önce sunulmuş veya üzerinde çalışılmış bütün hususların sözleşme hükümlerine uygun hale getirilmesi zorunludur. Aksi takdirde sözleşme imzasından önce hazırlanmış/sunulmuş dokümanların geçerliliği bulunmayacaktır.)
* Proje Yönetim Planı
* ELD Planı
* Ömür Devri Maliyet Tahmini
* Kalite Yönetim Planı
* Konfigürasyon Yönetim Planı
* Risk Değerlendirme Planı
* Demodelik Yönetimi Planı

=== 4.3.9. ÇIKTILAR ===

* Sözleşme ve Ekleri
* TVP
* Prototip / Odak Sistem
* Yedek / Destek Donanımları
* Üretim Planı
* Teknik Yayın (Bakım ve diğerleri)
* Eğitim / Eğitim Dokümanları
* Güncellenmiş Proje Yönetim Planı
* Güncellenmiş ELD Planı
* Güncellenmiş Kalite Yönetim Planı
* Güncellenmiş Konfigürasyon Yönetim Planı
* Güncellenmiş Risk Değerlendirme Planı
* Güncellenmiş Demodelik Yönetimi Planı
* Güncellenmiş Ömür Devri Maliyet Tahmini
[[Dosya:Şekil8 Geliştirme Safhası.jpg|alt=Şekil 8 Geliştirme Safhası|sol|küçükresim|990x990pik|Şekil 8 Geliştirme Safhası]]

== 4.4. ÜRETİM SAFHASI ==

=== 4.4.1. AMAÇ ===
Üretim safhasının amacı, Odak Sistemi üretmek ve gereksinimlerin karşılandığını doğrulamaktır. Üretim safhasında, Odak Sisteminin üretimi ile birlikte ELD Elemanları başta olmak üzere destek ihtiyaçlarına yönelik üretim/kazanım faaliyetleri de yürütülür.

=== 4.4.2. TANIM ===
Üretim safhası, girdilerin incelenmesi ve analizi ile başlar. Bu analiz sonucunda çıktılar ve safhanın uygulama adımları belirlenir. Detaylı üretim planı ve kalite yönetim planı üretilir ve uygulanır.

Üretim ve kalite yönetim planına kritik yol analizi yapılarak öncelikler belirlenir ve Odak Sistemin üretim döneminde verimliliği artırılır. Risk değerlendirmesi yapılarak daha detay düzeydeki kritik yollar ve üretim safhasındaki hassas faaliyetler belirlenir.

Üretim safhasının sonunda Odak Sistem ile birlikte diğer ELD elemanları birleştirilerek kabiliyetin ürün ile sağlanması hedeflenir. Üretim safhasının sonunda sürdürülebilir kullanım ve destek dönemi için gereken tüm ELD elemanları planlanmış ve Odak Sistemin envanterden çıkarılması ile ilgili konsept geliştirilmiş olur.

=== 4.4.3. AŞAMALAR ===
Üretim safhasının aşamaları;

* İlk Üretim
** İlgili Kilometre Taşları: M4.1, M4.2

* Seri Üretim
** İlgili Kilometre Taşları: M4.3

olarak belirlenmiştir.

=== 4.4.4. FAALİYETLER ===
'''İlk Üretim Aşamasında;''' ürün ile ilgili olan malzemelerin üretilmesi, üretimin kontrolü ve gözlenmesi (Teknik, kalite ve performans özelliklerinin) ve kabul ve kalifikasyonların gerçekleştirilmesi faaliyetleri yürütülür.

* Hazırlanan Dokümanlar: Üretim Hattı Kalifikasyon Test Prosedürleri, Üretim Hattı Kalifikasyon Sonuç Raporları
* Gözden Geçirmeler: Üretim Planı Gözden Geçirme

'''Seri Üretim Aşamasında;''' ilk üretim aşaması faaliyetlerine ek olarak aşağıdaki faaliyetler yürütülür:

* Üretim safhasının bitimi ile ilgili kabul dokümanlarının oluşturulması ve yönetilmesi
* İlgili tüm verilerin arşivlenmesi
* ELD Planı’nın ihtiyaç varsa güncellenmesi
* Envanterden çıkarma konsepti ile ilgili girdilerin verilmesi
* Konfigürasyon Yönetim Planı’nın ihtiyaç varsa güncellenmesi
* Demodelik yönetimi stratejisinin ya da planının ihtiyaç varsa güncellenmesi
* Ürün ile ilgili ihtiyaç varsa ömür devri maliyet tahmininin güncellenmesi
* Öğrenilmiş derslerin safha sonunda dokümante edilmesi
* Ürünün ELD elemanları ile ilgili uygulama yöntemlerinin ve güncellemelerin kontrol edilmesi faaliyetleri gerçekleştirilir.
* Hazırlanan Dokümanlar: Kabul Test Prosedürleri, Kabul Test Sonuç Raporları
* Gözden Geçirmeler: Kabul Test Prosedürleri Gözden Geçirme

=== 4.4.5. KİLOMETRE TAŞLARI ===
Üretim safhasındaki kilometre taşları aşağıda belirtilmiştir:

* M4.1: Üretim planının onaylanması
* M4.2: Kalite planının onaylanması
* M4.3: Odak Sistemin ihtiyaç makamı ve tedarik makamı tarafından kabulü

=== 4.4.6. GİRİŞ KRİTERLERİ ===
Üretim safhasındaki giriş kriterleri aşağıda belirtilmiştir:

* Üretim safhası içindeki aşamalarda gerçekleştirilecek faaliyetler için gerekli kaynakların varlığı

=== 4.4.7. ÇIKIŞ KRİTERLERİ ===
Üretim safhasındaki çıkış kriterleri aşağıda belirtilmiştir:

* Safha çıktılarının sunulması
* Programın durdurulması, devamı, bir önceki safhaya geri dönüş gibi kararların verilmesi

=== 4.4.8. GİRDİLER ===
Üretim safhasındaki safha girdileri aşağıda belirtilmiştir:

* TVP
* Güncellenmiş Proje Yönetim Planı
* Güncellenmiş ELD Planı
* Güncellenmiş Kalite Yönetim Planı
* Güncellenmiş Konfigürasyon Yönetim Planı
* Güncellenmiş Risk Değerlendirme Planı
* Güncellenmiş Demodelik Yönetimi Planı
* Üretim Planları
* Ömür Devri Maliyet Tahmini
* Riskler ve Aksiyon Planı
* Bakım El Kitapları
* Eğitim/Eğitim Dokümanları
* Prototip / Odak Sistem

=== 4.4.9. ÇIKTILAR ===
Üretim safhasındaki safha çıktıları aşağıda belirtilmiştir:

* Üretilmiş Odak Sistem
* Yedek / Destek Donanımları
* Teknik Yayın (Bakım ve diğerleri)
* Eğitim/Eğitim Dokümanları
* Envanterden Çıkarma Safhası için Güncellenmiş Konsept
* Sürdürülebilir Kullanım ve Destek Dönemi için Gerekli Tüm ELD Elemanları
* Güncellenmiş ELD Planı ve Alt Planlar
* Güncellenmiş Kalite Yönetim Planı
* Güncellenmiş Konfigürasyon Yönetim Planı
* Güncellenmiş Demodelik Yönetimi Planı
* Güncellenmiş Ömür Devri Maliyet Tahmini
[[Dosya:TSSODYP01.09.jpg|alt=Şekil 9 Üretim Safhası|sol|küçükresim|950x950pik|Şekil 9 Üretim Safhası]]

== 4.5. KULLANIM SAFHASI ==

=== 4.5.1. AMAÇ ===
Kullanım safhası, ürünün envanterde bulunduğu ve/veya harekat alanlarında fiilen kullanıldığı safhadır.

Kullanım safhası, sınırlı yetenekle üretilmiş ürünlerin kullanımı ile başlayabilir. İlave yetenekler tamamlanıp, sisteme eklenir ve hedeflenen tüm yetenek kullanıcıya sağlanır.

=== 4.5.2. TANIM ===
Kullanım safhası, Odak Sistemin operasyonel çerçevede kullanıma hazır hale gelmesi (aktifleştirilmesi) ile birlikte başlar ve bundan itibaren sorumluluk tamamen kullanıcıya geçer. Odak Sistem, hizmet dışı kaldığı anda bu safha sonlanır. Odak Sistemin etkin hale getirilmesi ve kullanılmaya başlamasıyla birlikte, performansı izlenmeli ve uygunsuzluklar, eksiklikler, arızalar uygun şekilde kayıt altına alınmalı, tanımlanmalı, çözülmeli ve sonrasında da tüm sonuçlar kayıt altına alınmalıdır. Kullanım safhası süresince, Odak Sistem ve verilen hizmetler geliştirilebilir, bu da farklı konfigürasyonların ortaya çıkmasına neden olabilir. Bu tarz konfigürasyon değişikliklerinin Konfigürasyon Yönetim Planı uygulamaları doğrultusunda dokümante edilmesi gereklidir. İlgili organizasyonun, operasyonel altyapıya tesis, ekipman, eğitimli personel ve el kitapları dahil (tüm bunların üretim safhasında geliştirilmiş veya edinilmiş olması gerekir) sahip olduğu varsayılmaktadır.

=== 4.5.3. AŞAMALAR ===

* Odak Sistemin Kullanımı Aşaması
** İlgili Kilometre Taşları: M5.1, M5.2

=== 4.5.4. FAALİYETLER ===
Kullanım safhasının faaliyetleri Destek safhası ile yakından ilişkilidir ve çoğu zaman bu faaliyetler iç içe geçmiş durumdadır.

Kullanım Safhası, Odak Sistemin Kullanımı Aşaması boyunca aşağıdaki faaliyetlerin yerine getirilmesi gereklidir;

* Etkinleştirilmiş ürün ve hizmetler sağlanması,
* Eğitilmiş ve kalifiye operatörler atanması,
* Sistemin tanımlı operasyonel çevresinde etkin hale getirilmesi,
* Sistemin operasyonel planlara, iş güvenliğine, çevre koruma yönetmeliklerine ve uluslararası insan hakları hukukuna uygun olarak kullanıldığından emin olacak şekilde operasyonun izlenmesi,
* Servis performansının güvenilirlik, bakım yapılabilirlik ve kullanıma hazır olma değerlerini kapsayacak şekilde kabul edilebilir parametreler dâhilinde olduğunu doğrulamak amacıyla veri toplayarak, sistem operasyonun izlenmesi,
* Sağlanan hizmetlerle ilgili bir uygunsuzluk olması durumunda, hata tanımlama faaliyetlerinin gerçekleştirilmesi,
* Uygulanabilir olan durumlar için düzeltici faaliyetlerin belirlenmesi,
* Gerekli olması durumunda, işletim prosedürlerinin güncellenmesi,
* Kullanıcı geri bildirimlerinin alınması,
* Uygulanabilir olması durumunda, düzeltici tasarım değişikliklerinin talep edilmesi,
* Ömür durum tespiti ve uzatımı yaklaşımının belirlenmesi,
* Mühendislik değişikliklerinin gözden geçirilmesi ve uygulamaya alınması,
* Kazanılmış dersleri kaçırmamak için, faaliyet sonrası gözden geçirmelerin gerçekleştirilmesi.

Kullanım safhasında:

* Hazırlanan Dokümanlar: Kullanım dönemi verileri ile hazırlanan/güncellenen dokümanlar.
* Gözden Geçirmeler: Kullanım dönemi verilerine yönelik çeşitli gözden geçirmeler.

=== 4.5.5. KİLOMETRE TAŞLARI ===

* M5.1: Kullanım Gözden Geçirme (In-Service Review)
* M5.2: Planlı Büyük Bakımlar (Planned major maintenance events)

=== 4.5.6. GİRİŞ KRİTERLERİ ===

* Kalifikasyon sonuçları ve muayene kabul raporları
* Safha faaliyetlerini gerçekleştirmek için tedarik desteği, insan gücü ve personel, destek ve test ekipmanı, eğitim ve eğitim desteği, teknik bilgi ve veri paketi, tesisler ve alt yapı, bilgisayar kaynakları vb. kaynakların hazır bulunması

=== 4.5.7. ÇIKIŞ KRİTERLERİ ===

* Envanterden çıkarma planının hazırlanmış ve onaylanmış olması
* Envanterden çıkarma planının hem donanım hem de yazılımlar için tüm prosedürleri içermesi
* Gerekli safha çıktılarının sağlanması
* Programı sonlandırma kriteri

=== 4.5.8. GİRDİLER ===

* Sözleşme ve Ekleri
* Kullanıma hazır odak sistemin üretilmiş ve envantere alınmış olması
* Kullanıcı tarafında, malzeme dışında kalan, ilke, organizasyon, eğitim, materyal, liderlik ve eğitim ve eğitim desteği, tesisler ve birlikte çalışabilirlik gibi tüm gerekliliklerin (DELTMATO: Doktrin, Eğitim, Liderlik, Teşkilat, Malzeme, Altyapı, Tesisler, Ortak çalışabilirlik) tamamlanmış olması
* Destek safhası için bakım, insan gücü ve personel, alt yapı, ambalajlama, taşıma, depolama, nakliye ve bilgisayar kaynakları gibi hususları kapsayan tüm plan ve hükümlerin sağlanmış olması
* Uluslararası insan hakları hukuku ile ilgili olarak planlanmış çözümlerin, çevresel emniyet ve sağlık risk değerlendirmelerinin ve sistem emniyet programlarının uygunluğunun kanıtlanmış olması
* Envanterden çıkarma safhası için belirlenmiş konseptin gerekli olması durumunda güncellenmesi
* Kullanım için sınırlama ve özel koşulların yerine getirilmesinde eksikliklerin bildirilmesi ve gerekiyorsa, kullanım safhasının sürdürülmesi için resmi onayların alınması
* Ürün Destek Stratejisi ve Modeli (Yerlileştirme/Millîleştirme dahil)
* Tedarik Zinciri Yönetimi
* Destek Stratejileri Metrikleri, İyileştirme Metrikleri, Envanter Bilgileri
* Destek ve Test Ekipmanları
* Kalite Yönetim Planı
* Konfigürasyon Yönetim Planı
* ELD Planı
* Demodelik Yönetim Planı
* Ömür Devri Maliyet Tahmini
* Kazanılmış Dersler

=== 4.5.9. ÇIKTILAR ===

* Sağlanan Yetenek
* Odak Sistemin Envanterden Çıkarılması Kararı
* Envanterden Çıkarma Onayı
* Kullanım ve Bakım Verileri Dokümanı
* Güncellenmiş Ömür Devri Maliyet Tahmini
* Kazanılmış Dersler

[[Dosya:TSSODYP01.10.jpg|alt=Şekil 10 Kullanım Safhası|sol|küçükresim|721x721pik|Şekil 10 Kullanım Safhası]]

== 4.6. DESTEK SAFHASI ==

=== 4.6.1. AMAÇ ===
Sistemin ömür devri boyunca kendisinden beklenen yetenekleri ve hizmetleri yerine getirmesi ve kullanım sürdürülebilirliğini sağlaması maksadıyla planlanan lojistik destek hizmetlerinin yürütülmesidir.

=== 4.6.2. TANIM ===
Destek Safhası; Odak Sistemin işlevine ve kullanımına yönelik lojistik destek kapsamında yer alan bakım ve diğer destek gereklerinin planlanması çalışmaları ile başlar. Bu safha, Odak Sistem kullanıcısının yürüteceği destek hizmetine yönelik tüm faaliyetlerin kapsamının tanımlanmasını içerir. Ürüne özgü destek stratejisinin ve planların oluşturulması ve uygulanması bu safhadaki temel faaliyettir. Odak Sistemlerin muharebe ve/veya operasyon etkinliğinin sağlanması açısından Odak Sisteme ilişkin teknik gereksinimler kadar lojistik desteğe ilişkin gereksinimlerin de karşılanması zorunluluğu vardır. Sistem ömür devrinin erken safhalarından itibaren ELD çalışmalarına başlanılması ve geliştirme safhasında sistem mühendisliği ile ELD ve LDA çalışmalarının birlikte yürütülmesi esastır. Destek unsuru ve hizmetin tanımlanması, sınıflandırılması, performansının izlenmesi, aksaklıkların, eksikliklerin ve hataların raporlanmasının yanı sıra, bu aksaklık ve eksikliklerin düzeltilmesine yönelik çözüm önerilerinin sunulması da destek safhası kapsamında yürütülür. Öngörülen/karşılaşılan darboğazların çözümleri; bakım yapısında gözden geçirme sonucu yapılan değişiklikler, büyük/küçük sistem hizmet değişikliği veya Odak Sistem ve/veya destek unsurlarının envanterden çıkarılması şeklinde olabilir. Bu safhadaki geri bildirimler ve yeniden değerlendirme faaliyetleri kritik öneme sahiptir. Bu safha destek faaliyetlerinin tamamlanması ve Odak Sistemin envanterden çıkarılması ile son bulur.

=== 4.6.3. AŞAMALAR ===

* Desteğin Planlanması Aşaması
** İlgili Kilometre Taşları: M6.1

* Desteğin Uygulanması Aşaması
** İlgili Kilometre Taşları: M6.2, M6.3

=== 4.6.4. FAALİYETLER ===
Sistem Ömür Devri Yönetimi içindeki safhalarla karşılaştırıldığında kullanım ve destek safhaları diğer safhalara göre daha uzun bir süreyi kapsamaktadır. Bu uzun süre boyunca Odak Sistemle ilgili tüm parametreler değişmekte, kısıtlar farklılaşmakta, söz konusu iki safhada yer alan tüm fiziki ve fiziki olmayan ögeler arasındaki ilişkilerin şekli, büyüklüğü, yönü, yoğunluğu da buna uygun olarak değişim göstermektedir. Bu nedenle Kullanım Safhası ile Destek Safhasının, bir birleri üzerindeki etkileri göz ardı edilmeden ayrı ayrı değerlendirilmesinin planlama, uygulama ve program/proje yönetimi açısından önemli faydaları bulunmaktadır. Teknolojideki hızlı değişim ve idame maliyetlerindeki artış dikkate alındığında Destek Safhasının çok zamanlı, çok katmanlı ve dinamik tarzda tasarlanması önem kazanmaktadır.

Destek Safhası süresince;

* Destek stratejisinin/planının (periyodik bakım, arıza tespiti, onarım, test işlemleri vb.) planlanması ve uygulanması,
* Odak Sistemin geliştirme, üretim ve kullanım safhalarında yapılan lojistik destek analizlerine göre hazırlanan ELD Planı kapsamında uygulamaların gerçekleştirilmesi,
* Sistem yeterliliğinin değerlendirilmesi için kullanım ve hata verilerinin izlenmesi,
* Düzeltici, önleyici ve duruma bağlı bakım faaliyetlerinin geliştirilmesi ve yapılandırılmış yeterliliğin onaylanması, (Tedarik makamı, üretici, kullanıcı, teknik otorite ve destek unsurları arasındaki ilişki ve etkileşiminin en yüksek seviyede olmasını sağlamak bakımından)
* Geçmiş problemlerin ve bunlara yönelik olarak yürütülen düzeltici eylemler ve eğilimlerinin raporlarının hazırlanması,
* Demodelik yönetiminin sağlanması,
* Alınan derslerin oluşturulması amacıyla “Eylem Sonrası Gözden Geçirme” faaliyetleri yürütülmesi,
* Savunma sistemleri tedarik edildiğinde son kullanıcı ihtiyaçlarının karşılanması ve bu sistemleri faal tutacak desteğin sağlanması esastır. Odak sistemlerin kullanım ve destek safhasında, zamanla operasyonel çevrelerdeki ihtiyaçlar değişmekte, lojistik destekte zorluk, kesinti ve yüksek maliyet artışları yaşanmakta (demodelik), yaşlanan sistem kabiliyetlerinde düşüş olabilmekte, aynı zamanda teknolojik gelişmelere uyum ve yeni kabiliyet ekleme ihtiyaçları ortaya çıkmaktadır. Savunma platform ve sistemlerinin öngörülen ömür devri boyunca kabiliyet muhafazasının sağlanması ve/veya arttırılması kapsamında bu sistemler için çözüm olarak yarı ömür (devri) modernizasyonunun / ömür ortası kabiliyet yükseltmesinin yapılması planlanır ve bu maksatla modernizasyon/modifikasyon projeleri geliştirilir.

=== 4.6.5. KİLOMETRE TAŞLARI ===

* M6.1: Sahada İlk kullanım
* M6.2: Hizmet Durumu Gözden Geçirme
* M6.3: Modifikasyon/İyileştirme, Ömür Uzatım Faaliyetleri

=== 4.6.6. GİRİŞ KRİTERLERİ ===

* Sistem destek ihtiyacı
* Destek safhası esnasında kullanılacak destek sistemlerinin, sistem elemanlarının ve hizmetlerin bir araya getirilmesi

=== 4.6.7. ÇIKIŞ KRİTERLERİ ===

* Envanterden çıkarma planının hazırlanmış ve onaylanmış olması
* Safhanın beklenen çıktılarının ilgili seviyelere dağıtımı
* Proje/Program sonlandırma kriterleri/stratejileri

=== 4.6.8. GİRDİLER ===
'''Destek Planlama Aşaması:'''

* Sistem Kullanım ve Destek Gerekleri
* Mevcut İmkan ve Kabiliyetler
* Ürün Destek Stratejisi ve Modeli (Yerlileştirme/Millîleştirme dahil)
* Ömür Devri Maliyet Tahmini
* Sözleşme ve Ekleri
* ELD Planı
* Kalite Yönetim Planı
* Konfigürasyon Yönetim Planı
* Demodelik Yönetim Planı
* Alınan Dersler

'''Destek Uygulama Aşaması:'''

* Sözleşme ve Ekleri
* Ürün Destek Stratejisi ve Modeli (Yerlileştirme/Millîleştirme dahil)
* Sürdürülebilir Kullanım ve Destek Dönemi için Gerekli Tüm ELD Elemanları
* Ömür Devri Maliyet Tahmini
* ELD Planı
* Kalite Yönetim Planı
* Konfigürasyon Yönetim Planı
* Demodelik Yönetim Planı
* Alınan Dersler

=== 4.6.9. ÇIKTILAR ===

* Güncellenmiş Kullanım ve Bakım Verileri
* Odak Sistemin Güvenilirlik, Hazır Bulunuşluk Oranı, Desteklenebilirlik Durumu
* Muharebe ve/veya Operasyon Performansı
* Güncellenmiş Sistem Bakım Gerekleri
* Kullanıcı Hata Raporları
* Güncellenmiş Ömür Devri Maliyet Tahmini ve Gerçekleşen Maliyet
* İdame Stratejisinde Düzeltici Faaliyetler
* Odak Sistem Envanterden Çıkarma Kararı
* Deaktivasyon Onayı
* Alınan Dersler

[[Dosya:Şekil 11 Destek Safhası.jpg|alt=Şekil 11 Destek Safhası|sol|küçükresim|722x722pik|Şekil 11 Destek Safhası]]

== 4.7. ENVANTERDEN ÇIKARMA SAFHASI ==

=== 4.7.1. AMAÇ ===
Envanterden çıkarma, sahip olunan Odak Sistemin yeniden kullanım, transfer, hibe, satış, imha veya diğer seçeneklerle değerlendirilmesi sürecidir.

Envanterden çıkarma safhasının amacı; planlanan kullanım ömrü sonunda veya kullanım ömrü dolmadan envanterden çıkarma kararının verilebildiği durumlarda ilgili sistemin operasyonel ve destek hizmetlerinin sonlandırılması ve sistem için mümkün olan seçeneklerin değerlendirilerek sürecin işletilmesidir. Bu kapsamda standart yapıda envanterden çıkarma rehber dokümanlarını işletebilmek faydalı bir uygulamadır. Süreç sonucunda temel çıktılar:

* Ulusal güvenlik düzenlemelerinin korunması,
* Çevreye etki edebilecek hataların minimuma indirilmesi,
* Kısa veya uzun vadede çevreyi ve insan sağlığını olumsuz etkileyecek zehirli maddelerin etkilerinin yok edilmesi,
* Planlanan envanterden çıkarma opsiyonlarıyla ilgili olabilecek açık ihtiyaçların karşılanabilmesi,
* Optimum parasal dönüşün sağlanması,
* Sistemin yok edilmesi ya da değerlendirilmeksizin kullanımının terk edilmesi seçimlerinin minimize edilmesi,
* Özellikle savunma sanayii ürünlerinde silahların yayılması ya da kötü amaçlı gruplar tarafından ele geçirilmelerinin engellenmesi olacaktır.

=== 4.7.2. TANIM ===
Envanterden çıkarma safhası resmi olarak Odak Sistemin kullanımdan kaldırılması kararı ile başlasa da sistem ömür devrinin erken safhalarında gerekli planlamalar yapılmalıdır. Geliştirme programlarında envanterden çıkarma gereksinimleri; tasarıma dâhil edilmeli, envanterden çıkarma kararları ve yürütülecek faaliyetler, etkilenen paydaşlar açısından dikkatlice değerlendirilmeli ve en fazla faydayı sağlayacak opsiyonlar uygulamaya alınmalıdır. Envanterden çıkarma kararlarının alınmasında şüphesiz en önemli kriter, sistemden beklenen tanımlı fonksiyonların/operasyonel etkinliğin maliyet etkin bir şekilde tam anlamıyla yerine getirilip getirilemediğinin sorgulanmasıdır. Bu aşamada gelişen teknoloji dolayısıyla ortaya çıkabilecek yeni kabiliyet ihtiyaçları da etkili bir diğer faktör olarak belirtilebilir.

Sistem envanterden çıkarma gereksinimleri; sürecin özellikle çevresel ve ekonomik boyutta önemli etkileri olabileceği için bir plan dâhilinde projenin erken safhalarından itibaren yönetilmesi gereken bir konudur. Faydalı ömür sonuna gelmeden geliştirilmesi gereken envanterden çıkarma planı, seçeneklerin tanımlanması ve gereklerin belirlenmesi ile yasal ve düzenleyici gereklere uyumu sağlayacaktır. Bu planın safha başlangıcından önce tamamlanmış olması gerekmektedir.

Erken dönemlerde planlama ile ürün kullanımı süresince de ortaya çıkabilecek atıkların yönetimi sağlanabilecektir. Bu kapsamda, geliştirme safhasında zararlı maddelerin ürün verisi ve konfigürasyon yönetimi olarak ürün kırılımında yer alması sürecin önemli bir iş adımı olarak örnek verilebilir. Yine kimyasal malzemelerin uluslararası düzenlemelere göre kodlandırılması ayrı bir geliştirme safhası aktivitesi olarak aktarılabilir.

Envanterden çıkarma safhası aktiviteleri kapsamında ürün demontajı gibi bazı görevler, Bakım Görev Analizi (Maintenance Task Analysis) çalışmaları kapsamında değerlendirilebilir. Belirli bir formatı olmamasına rağmen, plan aşağıdakileri içerebilir:

* Sürecin tanımlanması
* Organizasyonel sorumluluklar
* Güvenlik hususları
* Tehlikeli madde idaresi ve sivilleştirme gereksinimleri
* Envanterden çıkarma takvimi
* Envanterden çıkarma maliyeti ve finansman

Envanterden çıkarma safhası kapsamında planlamalara dâhil edilebilecek bir takım faktörler söz konusudur. Faaliyetin niteliğine göre uyarlama mümkündür. Aşağıdakiler örnek olarak listelenebilir:

* Optimum geri dönüşü sağlayacak satış metotlarının değerlendirilmesi
* Sivilleştirme programlarının değerlendirilmesi
* Ticari düzenleme ve yasalara uyum gösterilmesi
* Alt yüklenici kullanımı söz konusu olacaksa buna uygun gereksinimlerin belirlenmesi ve bunların etkin yönetimi
* Uygun yerleşim planı ve çeşitli güvenlik önemlerine sahip envanterden çıkarma tesisleri
* Müşteriler için fazla/artık ürünler konusunda yeniden kullanım, bağış ve pazar desteği seçeneklerinin değerlendirilmesi
* Tehlike unsuru içeren bileşenler için yetki durumlarına göre envanterden çıkarma talimatlarının belirtilmesi
* Çevresel korumanın sağlanabilmesi için uygun ulaştırma/taşıma elemanları
* Farklı düzenlemelere göre hareket etmeyi gerektirebilecek sistem bileşenlerinin ayrıştırılması ve tehlikeli maddeler için uygun depolama koşullarının oluşturulması
* Hazır ürünler için envanterden çıkarma gereksinimlerinin, tedarikleri ile birlikte değerlendirilmesi
* Radyoaktif atık, nükleer silahlar ve kimyasal yayılma ile ilgili malzemeler ve kriptolojik bilgi içeren güvenlik birimlerinin ayrıca değerlendirilmesi

=== 4.7.3. AŞAMALAR ===
Envanterden çıkarma safhası iki aşamadan oluşur:

* İlişkinin Kesilmesi Usulleri Aşaması; Odak sistem ve destek unsurlarının hizmet sürelerinin sonlandırıldığı, erken safhalarda planlanan faaliyetlerin detaylandırıldığı ve maksimum faydayı sağlayacak stratejilerin geliştirildiği aşamadır.
** İlgili kilometre taşları: M7.1

* İlişkinin Kesilmesi Aşaması; bir önceki aşamada geliştirilen stratejilerin onaylanması ile başlar. Faydalı ömür sonunda savunma ve güvenlik sisteminin sivilleştirilmesi ve envanterden çıkarılması ile ilişkili maliyetlerin değerlendirilmesi gerekmektedir. Bu aşamada, sistem kaynak havuzuna tekrar eklenebilecek değerli malzemelerin ve parçaların maliyet etkin bir şekilde envanterden çıkarılması değerlendirilir. Sistemi oluşturan bütün elemanların ekonomik geri dönüşüm seçenekleri değerlendirilmeden envanterden çıkarılmasının önüne geçilir.
İlişkinin kesilmesi aşaması; envanterden çıkarma safhasına yönelik faaliyetlerin sonlandırıldığı aşama olacaktır. Bu aşamada, farklı sistem bileşenleri için farklı envanterden çıkarma seçenekleri söz konusu olabilecektir. Sistem ömür devri maliyeti hesaplamaları için maliyet ve elde edilen gelir kayıtları değerlendirilir. Diğer projelere yönelik süreçlerin iyileştirilmesi için kazanılmış dersler mutlaka kayıt altına alınmalı ve etkin kullanıma sunulması açısından uygun şekilde muhafaza edilmeleri sağlanmalıdır.

** İlgili kilometre taşları: M7.2

=== 4.7.4. FAALİYETLER ===
Envanterden çıkarma safhasında yürütülebilecek faaliyetler aşağıdaki şekilde listelenebilir:

'''İlişkinin Kesilmesi Usulleri Aşamasında;'''

* Tehlike analizi ve risk değerlendirmesi yapılması (özellikle kullanım ömrü dolmadan envanterden çıkarma kararı verildiğinde güvenlik ve gizlilik anlamında gerekli önlemlerin değerlendirilmesi)
* Odak Sistem sayısı, envanterden çıkarma takvimi, işlem sırası vb. bilgileri içeren envanterden çıkarma stratejisinin tanımlanması
* Envanterden çıkarma sırasında kullanılacak yardımcı bileşenlerin ve hizmetlerin tedariği
* Operasyondan kaldırmaya hazırlamak için Odak Sistem deaktivasyonu
* Sistem personelinin programdan çekilmesi
* Envanterden çıkarma bölgelerine gönderilecek birimlerin gerekli bilgilerinin sağlandığı dokümantasyon ile gönderilmesi
* Envanterden çıkarma programlarının yürütülmesinden sorumlu olacak birimler ile askeri makamların koordinasyonunun sağlanması
* Değerli malzemelerin geri dönüşüm programlarının izlenmesi ve gerekli desteğin sağlanması
* Ayrıştırılan sistem elemanları için yeterli alanların düzenlenmesi, mevcut durumlarının korunması ve temasın azaltılması
* Kirlilik ve karışmanın engellenmesi, düzgün kimliklendirme işlemlerinin yürütülmesi ve depolama alanlarında bilgilendirici yazı, levha ve çizgilerin kullanılması
** Hazırlanan Dokümanlar: Envanterden Çıkarma Stratejisi
** Gözden Geçirmeler: …

'''İlişkinin Kesilmesi Aşamasında;'''

* Yeniden kullanım, geri dönüşüm, yenileme (reconditioning), yenileştirme (overhaul), arşivleme, yok etme, bağışlama, iade (return) veya satış vb. işlemler için Odak Sistemin envanterden çıkarılmasını kolaylaştırmak anlamında Odak Sistemin yönetilebilir elemanlara demonte edilmesi
* Gerekli güvenlik önlemlerinin sağlanması
* Eğer Odak Sistem depolanacaksa, koruma tesisleri, depolama lokasyonları, gözlem kriterleri ve depolama periyotlarının tanımlanması
* Atık yönetimini kolaylaştırmak ve atık miktarını azaltmak için gerekli hallerde Odak Sistemin yok edilmesi
* Tehlikeli maddelerin uygun depolama ve taşıma işlemlerinin yürütülmesi
* Hurda geri dönüşüm programlarına destek sağlanması, hurda ayıklama ve kimliklendirme işlemlerinin yapılması
* Çeşitli opsiyonlarda tekrar kullanımı mümkün olacak birimler için kalite kontrol süreçlerinin işletilmesi
* Düzenli aralıklarla stok durumunun izlenmesi ve kayıtların güncellenmesi
* Konfigürasyon anlamında gerekli kayıtların tutulması
* Herhangi bir kaydın/bilginin envanterden çıkarılmasında paydaş onaylarının alınması
* Envanterden çıkarma faaliyetleri sonrası sağlık, emniyet, güvenlik ve çevresel anlamda zararlı faktörlerin olmadığının temin edilmesi
* Envanterden çıkarma raporlarının hazırlanması
* Uzun dönemli sağlık, emniyet, güvenlik ve çevre tehlikeleri durumlarında denetim ve gözden geçirmelere izin vermek adına program ömrü boyunca toplanan bilginin arşivlenmesi
** Hazırlanan Dokümanlar: Envanterden Çıkarma Safhası Gerçekleşme Raporu
** Gözden Geçirmeler: -

=== 4.7.5. KİLOMETRE TAŞLARI ===

* M7.1: Envanterden çıkarma stratejisi
* M7.2: Envanterden çıkarma safhası gerçekleşme raporu

=== 4.7.6. GİRİŞ KRİTERLERİ ===

* Envanterden çıkarma kararı ve konsepti
* Envanterden çıkarma planının hazırlanması
* Envanterden çıkarma stratejisinin geliştirilmesi

=== 4.7.7. ÇIKIŞ KRİTERLERİ ===

* Envanterden çıkarma safhası gerçekleşme raporu

=== 4.7.8. GİRDİLER ===

* Envanterden Çıkarma Kararı Alınan Sistem/Ürün
* İlgili Malzemelere Yönelik Emniyet Veri Dosyaları
* Envanterden Çıkarma Planı
* Envanterden Çıkarma Stratejisi
* Kullanım ve Bakım Verileri
* Ömür Devri Maliyet Tahmini ve Gerçekleşen Maliyet

=== 4.7.9. ÇIKTILAR ===

* Envanterden Çıkarma Safhası Gerçekleşme Raporu
* Olası Mali Fayda
* Toplam Ömür Devri Maliyeti Raporu
* Sonraki Programlar için Geri Besleme
* Gerçekleşen Ömür Devri Maliyeti
[[Dosya:Şekil12 Envanterden Çıkarma Safhası.jpg|alt=Şekil 12 Envanterden Çıkarma Safhası|sol|küçükresim|990x990pik|Şekil 12 Envanterden Çıkarma Safhası]]

= 5. UYARLAMA =
Sistem Ömür Devri Yönetimi Rehber Dokümanı; ömür devri faaliyetleri ve bu faaliyetler sırasında oluşturulacak iş ürünlerinin, NATO AAP-20, NATO AAP-48 ve ISO/IEEE 15288 standartları temel alınarak oluşturulan genel bir modeli tanımlamaktadır. Bu model Odak Sistemin yapısına göre olduğu gibi kullanılabileceği gibi, bazı durumlarda birtakım süreç ve iş ürünlerinde değişikliklerin yapılması gerekebilir. Genel anlamda, yapılacak bu değişiklikler Odak Sistemin durumuna göre, sistem mühendisliği süreçlerinin daha yoğun ya da seyrek şekilde ele alınması şeklinde gerçekleşir.

Uyarlama faaliyeti, risk ve süreç yoğunluğu arasında denge kurulmasını gerektirir. Şekil‑13’te görüldüğü gibi sistem mühendisliği faaliyetlerinin yoğunluğu arttıkça, ürün doğruluğu ile ilgili sorun yaşama riski azalmaktadır. Ancak bu ilişki doğrusal değildir ve artan efora karşılık edinilen kazanımın optimizasyon bölgesi dışında çok düşük seviyede olduğu görülmektedir. Bu durum grafiğin iki uç bölgesinde de projenin takvimsel ve maliyet risklerinin artmasına neden olmaktadır. Uyarlama faaliyetini yapacak olan uzman personelin iki durum arasındaki dengeyi oluşturması gerekmektedir.
[[Dosya:Şekil13 Risk Ve Süreç Denge Grafiği.jpg|alt=Şekil 13 Risk ve Süreç Denge Grafiği – McConnel, INCOSE SE Handbook|sol|küçükresim|800x800pik|Şekil 13 Risk ve Süreç Denge Grafiği – McConnel, INCOSE SE Handbook]]

'''Uyarlamanın Zamanlaması:'''

Sistem ömür devri içinde Konsept safhasının inceleme aşamasında ilk uyarlama faaliyetinin gerçekleştirilmesi ve sözleşmeye yansıtılması amaçlanmaktadır. Ancak uyarlama, ömür devri boyunca dinamik olarak tüm aşamalar içinde değişen risk ve koşullara göre her zaman ele alınması gereken bir faaliyettir. Projenin sözleşmeye bağlanması ile birlikte uyarlama faaliyetlerinin ne şekilde ele alınacağı hususunun proje içinde hazırlanacak olan yönetsel planlarda (Sistem Mühendisliği Yönetim Planı, Proje Yönetim Planı, Kalite Yönetim Planı vs.) tanımlanması ve yönetilmesi gerekmektedir.

'''Uyarlama Faaliyetleri:'''

* Uyarlama faaliyetini tetikleyen durumlar/gerekçeler her aşama için tanımlanır ve açıklanarak kayıt altına alınır. ''Bu durumlar aşağıda örnek olarak listelenmiş olup, farklı projeler kapsamında bunların dışında uyarlama gerekçeleri de oluşturulabilir''
** Proje riskleri, büyüklüğü, karmaşıklık seviyesi, paydaşlarının sayısı ve takvimi
** Teknoloji hazırlık seviyeleri
** Kullanım döneminin başlangıç zamanı ve toplam süresi
** Güvenlik, emniyet, kullanılabilirlik ve bulunabilirlik özellikleri ile ilgili koşullar
** Operasyonel koşullar ve kullanıcının acil ihtiyaçları
** Yeni gelişen teknolojiler
** Projeye tahsis edilmiş kaynaklar ve bütçe
** Servis sağlayıcı sistemlerin bulunabilirliği
** Ömür devri içindeki paydaşların program içindeki rol ve sorumlulukları
** Uymakla yükümlü olunan mevzuat (anayasa ve kanunlar, uluslararası antlaşmalar, kanun hükmünde kararnameler, tüzük ve yönetmelikler, yönergeler vb.)
** Müşteri tarafından talep edilen veya uymakla sorumlu olunan diğer standartlar

* Uyarlama alanları belirlenir.

Değişiklik yapılacak süreç adımları, iş ürünleri, gözden geçirme faaliyetleri vb. belirlenir ve uyarlama şekli tanımlanır.

* Uyarlama sonuçlarının etkileri tanımlanır ve bunlardan etkilenen tüm paydaşlardan görüş alınır.

* Uyarlama kararı verilir ve bu karar “Karar Yönetim Süreci” disiplini içinde ele alınır. Bu kapsamda kararı tetikleyen sebepler, etkileri, sonuçları, riskleri, getiri-götürü analizleri, paydaşların karar ile olan ilişkisi, kararın karakterizasyonu ve tüm olası alternatif çözümlerin incelenmesi ile en faydalı kararın verildiğinin kanıtlanması gerekir.

* Karar sonrası uyarlanmış süreç ve iş ürünleri tanımlanır.
* Yapılan tüm çalışmalar kayıt altına alınır. Bu kayıt bir rapor formatında oluşturulur.
* Uyarlama süreci ile ilgisi olan tüm paydaşlardan onay alınır.

= 6. EKLER =

== 6.1. UYARLAMA ÖRNEĞİ ==
Bu doküman kapsamında tanımlanan safha, aşama, girdi, çıktı, faaliyet vb. Sistem Ömür Devri Yönetimi elemanları, Uyarlama bölümünde anlatıldığı üzere çeşitli nedenlerle farklılaşabilecektir. Hazır Alım Projesi, Geliştirme Projesi, Üretim Projesi vb. proje türleri Sistem Ömür Devri Yönetimini şekillendirecek en önemli faktörlerden olacaktır. Zira bir geliştirme projesi için Sistem Ömür Devri Yönetiminin tüm safhaları işletilebilecekken, tasarımı ve doğrulaması daha önce farklı bir proje ile tamamlanmış yeni bir üretim projesi için geliştirme safhasına yönelik birçok faaliyet uyarlanabilecektir. Örnek bir geliştirme projesi için uyarlama bilgileri aşağıda verilmiştir:

* Kullanıcının elinde hazır alımla tedarik edilen daha eski nesil bir sistem bulunmaktadır.
* İlk kez geliştirilen, karmaşık sayılabilecek bir kara aracı söz konusudur.

'''Tablo 4 Uyarlama'''
{| class="wikitable"
|'''Sıra No'''
|'''Görev No'''
|'''Safha / Aşama / Faaliyet / Karar noktası'''
|'''Açıklama'''
|'''Uyarlama Bilgisi'''
|'''Referans Doküman'''
|-
|1
|1
|Ön Konsept Safhası
|Harekât ve lojistik ihtiyaçların belirlenmesi ve tanımlanmasını içerdiği için uyarlanamaz.
|Uyarlanamaz
|
|-
|2
|1.1
|İhtiyaç Belirleme Aşaması
|Sistem çözümüne ihtiyaç olup olmadığı kararı gerektiği için uyarlanamaz.
|Uyarlanamaz
|
|-
|3
|1.1.1
|Proje Kararı
|Bir sonraki aşamaya geçiş veya proje sonlandırma kriteri olduğu için uyarlanamaz.
|Uyarlanamaz
|
|-
|4
|1.2
|İhtiyaç Tanımlama Aşaması
|İhtiyacı karşılamaya yönelik sistem seçenekleri değerlendirildiğinden uyarlanamaz.
|Uyarlanamaz
|
|-
|5
|1.2.1
|Proje / İhtiyaç Tanımlama Dokümanı
|Sistem çözümü işaret etmeden temel gereksinimleri içerecek bir doküman hazırlanacaktır.
|Uyarlanamaz
|X Projesi Proje Tanımlama Dokümanı Rev1
|-
|6
|1.2.2
|Ön Yapılabilirlik Raporu
|Ön yapılabilirlik raporu hazırlanacaktır.
|Uyarlanamaz
|Ön Yapılabilirlik Raporu Rev1
|-
|7
|1.2.3
|Proje Planı (ELD Elemanları dahil)
|Proje/İhtiyaç Tanımlama Dokümanı ve ön yapılabilirlik raporu haricinde ihtiyaç tanımlaması için gereken dokümanlar belirlenecek ve hazırlanacaktır.
|Uyarlanamaz
|Proje Planı (ELD Elemanları dahil) Rev1
|-
|8
|1.2.4
|Tedarik Makamına Gönderilmesi Kararı
|Karar olduğu için uyarlanamaz.
|Uyarlanamaz
|
|-
|9
|2
|Konsept Safhası
|İhtiyacın karşılanmasına yönelik sistem çözümünün yapılabilirliğinin değerlendirilmesini kapsadığı için uyarlanamaz.
|Uyarlanamaz
|
|-
|10
|2.1
|İnceleme Aşaması
|Sistem çözümüne ilişkin ihtiyaçların detaylandırılarak gereksinimlere dönüştürülmesini içerdiği için uyarlanamaz.
|Uyarlanamaz
|
|-
|11
|2.1.1
|Yapılabilirlik Raporu
|Sistem gereksinimlerinin eksiksiz tespit edilebilmesi ve uzun vadeli ürün destek stratejilerinin oluşturulabilmesi için tüm paydaşların katılımı ile oluşturulmuş Yapılabilirlik Raporu hazırlanacaktır.
|Uyarlanamaz
|
|-
|12
|2.1.2
|Detaylı Proje Planı (ELD Elemanları dahil)
|Detaylı Proje Planı hazırlanacaktır.
|Uyarlanamaz
|
|-
|13
|2.1.3
|Kullanım Konsepti ve Görev Profilleri
|Destek stratejisinin belirlenebilmesi için değişik operasyon modlarını da içerecek şekilde araçların/görev ekipmanlarının dağılımı ve kullanım görev profili oluşturulacaktır.
|Uyarlanamaz
|
|-
|14
|2.1.4
|TÇD ve Ekleri
|TÇD uyarlanamaz.
|Uyarlanamaz
|
|-
|15
|2.2
|Projelendirme Aşaması
|Proje maliyet, performans, süre ve risk analizleri gerçekleştirildiği için uyarlanamaz.
|Uyarlanamaz
|
|-
|16
|2.2.1
|Operasyonel Konsept Dokümanı
|Kullanıcının gizli harekat bilgilerini açıklamayacağı fakat tasarım ve lojistik destek tasarımı için gerekli olan bilgileri sağlayacak şekilde (beraber görev yapacağı araçlar, kullanım konsepti, birlik isimleri belirtmeden birliklere dağılımı, farklı kullanım modları, depolama alanları, vb. ) Operasyonel Konsept Dokümanı hazırlanacaktır.
|Uyarlanamaz
|
|-
|17
|2.2.2
|Sözleşme ve Ekleri
|Uyarlanamaz.
|Uyarlanamaz
|
|-
|18
|2.2.3
|Ürün Destek Strateji ve Modeli (Yerlileştirme/Millîleştirme dahil)
|Ürün Destek Strateji ve Modeli (Yerlileştirme/Millîleştirme dahil) hazırlanacaktır.
|Uyarlanamaz
|
|-
|19
|2.2.4
|Ömür Devri Maliyet Tahmini
|Hazırlanacaktır.
|Uyarlanamaz
|
|-
|20
|2.2.5
|Kullanım Konsepti ve Görev Profili
|İnceleme aşamasında hazırlanan Görev profili Operasyonel Konsept Dokümanı ile beraber incelenerek güncellemesi yapılacaktır.
|Uyarlanamaz
|
|-
|21
|2.2.6
|Risk Değerlendirme Planı
|Risk Değerlendirme Planı hazırlanacaktır.
|Uyarlanamaz
|
|-
|22
|2.2.7
|Proje Uygulama Takvimi (PUT)
|PUT hazırlanacaktır.
|Uyarlanamaz
|
|-
|23
|2.2.8
|Proje Yönetim Planı
|Proje Yönetim Planı hazırlanacaktır.
|Uyarlanamaz
|
|-
|24
|2.2.9
|ELD Planı
|ELD Planı hazırlanacaktır.
|Uyarlanamaz
|
|-
|25
|2.2.10
|Kalite Yönetim Planı
|Kalite Yönetim Planı hazırlanacaktır.
|Uyarlanamaz
|
|-
|26
|2.2.11
|Konfigürasyon Yönetim Planı
|Konfigürasyon Yönetim Planı hazırlanacaktır.
|Uyarlanamaz
|
|-
|27
|2.2.12
|Demodelik Yönetimi Planı
|Ürün destek stratejisi ve ELD planı kapsamında Geliştirme safhasında hazırlanmasına karar verilmiştir.
|Uyarlanmıştır
|
|-
|28
|3
|Geliştirme Safhası
|Hedeflere uygun olarak Odak Sistem ve destek unsurlarının tasarım ve geliştirme faaliyetleri yürütüleceği için uyarlanamaz.
|Uyarlanamaz
|
|-
|29
|3.1
|Kavramsal Tasarım Aşaması
|Sistem çözümüne yönelik ilk geliştirme çalışmalarını içerdiğinden uyarlanamaz.
|Uyarlanamaz
|
|-
|30
|3.1.1
|Kavramsal Tasarım Raporu / Teklif Dokümanları
|Sözleşme imzası öncesi ilk değerlendirmeler teklif dokümanları ile iletildiği için Kavramsal Tasarım Raporu hazırlanmayacaktır.
|Uyarlanmıştır
|
|-
|31
|3.2
|Sistem Gereksinim Tanımlama Aşaması
|Gereksinimlerin yönetimi gerçekleştirildiği için uyarlanamaz.
|Uyarlanamaz
|
|-
|32
|3.2.1
|Sistem Gereksinim Tanımlama Dokümanı
|Projedeki Odak Sistem, alt sistem ve konfigürasyon birimlerinin gereksinimlerini yönetmek ve bu gereksinimlerle proje planları ve iş ürünleri arasındaki tutarsızlıkları engellemek amacıyla Sistem Gereksinim Tanımlama Dokümanı hazırlanacaktır.
|Uyarlanamaz
|
|-
|33
|3.2.2
|Sistem Gereksinimleri Gözden Geçirme Toplantısı
|İlgili paydaşların katılımıyla Sistem Gereksinim Gözden Geçirme Toplantıları düzenli olarak icra edilecektir.
|Uyarlanamaz
|
|-
|34
|3.3
|Ön Tasarım Aşaması
|Sistem mimarisi oluşturulması ve alt sistem gereksinim tanımlama faaliyetleri yürütüldüğü için uyarlanamaz.
|Uyarlanamaz
|
|-
|35
|3.3.1
|Sistem Tasarım Tanımlama Dokümanı
|Elektriksel ve mekanik arayüzler, nereden-nereye bilgileri, mesajlaşma arayüzleri ve şemaları vb. bilgileri içerecek Sistem Tasarım Tanımlama Dokümanı hazırlanacaktır.
|Uyarlanamaz
|
|-
|36
|3.3.2
|Sistem Arayüz Kontrol Dokümanı
|Sistem Tasarım Tanımlama Dokümanı Ek’i olarak verilecektir.
|Uyarlanmıştır
|
|-
|37
|3.3.3
|Test ve Değerlendirme Ana Planı
|Test edilecek yapılara ilişkin test gereksinimleri ve test planlarını içeren Test ve Değerlendirme Ana Planı hazırlanacaktır.
|Uyarlanamaz
|
|-
|38
|3.3.4
|Alt Sistemler İçin Gereksinim Tanımlama Dokümanları
|Sistem Tasarım Tanımlama Dokümanı Ek’i olarak verilecektir.
|Uyarlanmıştır
|
|-
|39
|3.3.5
|Güncellenmiş ELD Planı ve Alt Planlar
|Detay bileşenlerin detay tasarım aşamasında belli olması sebebiyle Envanterden Çıkarma Planı detay tasarım aşamasında hazırlanacaktır. ELD Planı ve diğer alt planlar ihtiyaçlar doğrultusunda güncellenecektir.
|Uyarlanmıştır
|
|-
|40
|3.3.6
|Ön Tasarım Gözden Geçirme Toplantısı
|İlgili paydaşların katılımıyla Ön Tasarım Gözden Geçirme Toplantısı düzenlenecektir.
|Uyarlanamaz
|
|-
|41
|3.4
|Detay Tasarım Aşaması
|Sistem ve alt sistem detay analiz ve tasarım faaliyetleri yürütüleceğinden uyarlanamaz.
|Uyarlanamaz
|
|-
|42
|3.4.1
|Teknik Veri Paketi
|Proje kapsamında gerekli katı modeller, teknik resimler, şartnameler, BoM, yazılım dokümantasyon vb. üretilecektir.
|Uyarlanamaz
|
|-
|43
|3.4.2
|Sistem ve Alt Sistem Doğrulama Planları
|Test ve Değerlendirme Ana Planı içerisinde verilecektir.
|Uyarlanmıştır
|
|-
|44
|3.4.3
|LDA Çıktıları
|Örnek 1:

Daha önce geliştirilmiş olan ortak alt sistem / LRU / SRU kapsamında hazırlanmış FMECA, RCM, LORA, MTA vb. analiz kayıtlarından faydalanılabilecektir. Diğer aday alt sistem / LRU / SRU’lar için LDA sonuçları kaydedilecektir.

Aday birimler ve gerçekleştirilecek analizlere yönelik planlama Lojistik Destek Analiz Planı içerisinde takip edilecektir. Güvenilirlik ve Emniyet çalışmaları ile etkileşimler; bu plan ve özel mühendislik faaliyetleri sonucunda üretilecek planlar ile sağlanacaktır.

Örnek 2:

LDA aday alt sistemler S3000L spesifikasyonuna göre seçilerek kritik görülen alt sistemler için LDA yapılacaktır.
|Örnek 1:Kısmen Uyarlanmıştır

Örnek 2:Uyarlanmıştır
|
|-
|45
|3.4.4
|Güvenilirlik ve Emniyet Çıktıları
|Daha önce geliştirilmiş olan ortak alt sistem / LRU / SRU kapsamında gerçekleştirilmiş GİK (RAMST) analiz sonuçlarından faydalanılabilecektir. Diğer aday alt sistem / LRU / SRU’lar için GİK çalışmaları yürütülecektir.
|Kısmen Uyarlanmıştır
|
|-
|46
|3.4.5
|Güncellenmiş Sistem Ömür Devri Yönetimi Stratejisi ve Modeli
|Detay tasarım faaliyetleri sonrası Sistem Ömür Devri Yönetim Stratejisi ve Modeli güncellenecektir.
|Uyarlanamaz
|
|-
|47
|3.4.6
|Kritik Tasarım Gözden Geçirme Toplantısı
|İlgili paydaşların katılımıyla Kritik Tasarım Gözden Geçirme Toplantısı düzenlenecektir.
|Uyarlanamaz
|
|-
|48
|3.5
|Entegrasyon ve Doğrulama Aşaması
|Sistem ve alt sistem test ve değerlendirme faaliyetleri yürütüleceğinden uyarlanamaz.
|Uyarlanamaz
|
|-
|49
|3.5.1
|Doğrulama Test Prosedürleri
|Sistem gereksinimleri ile uyumlu olarak yürütülecek testler sırasında kullanılacak kaynaklar, ihtiyaç duyulan test düzenekleri ve destek unsurları ile detaylı test adımlarını/metodolojisini içerecek Doğrulama Test Prosedürleri hazırlanacaktır.
|Uyarlanamaz
|
|-
|50
|3.5.2
|Doğrulama Sonuç Raporları
|Test faaliyetleriyle elde edilen sonuçları ve karşılaşılan hataları/uygunsuzlukları içerecek Doğrulama Sonuç Raporları hazırlanacaktır.
|Uyarlanamaz
|
|-
|51
|3.5.3
|Test Hazırlıkları Gözden Geçirme Toplantısı
|Doğrulama Test Prosedürleri ilgili paydaşlar ile hazırlanarak Test Hazırlıkları Gözden Geçirme Toplantısı gerçekleştirilecektir.
|Uyarlanamaz
|
|-
|52
|3.5.4
|Tasarım Doğrulama Gözden Geçirme Toplantısı
|İlgili paydaşların katılımıyla test sonuçları (Tasarım Doğrulama Gözden Geçirme Toplantısı) gözden geçirilecektir.
|Uyarlanamaz
|
|-
|53
|3.5.5
|İşlevsel Konfigürasyon Denetimi
|İşlevsel Konfigürasyon Denetimi gerçekleştirilecektir.
|Uyarlanamaz
|
|-
|54
|3.6
|Ürün Kalifikasyon Aşaması
|Odak Sistemin üretilebilir, test edilebilir, değerlendirilebilir, işletilebilir, desteklenebilir ve kullanımdan kaldırılabilir nitelikte olması sağlanacağından uyarlanamaz.
|Uyarlanamaz
|
|-
|55
|3.6.1
|Kalifikasyon Test Prosedürleri
|Sistem gereksinimlerinin karşılandığını gösterebilmek adına gerekli kaynakları içerecek şekilde Kalifikasyon Test Prosedürleri hazırlanacaktır.
|Uyarlanamaz
|
|-
|56
|3.6.2
|Kalifikasyon Sonuç Raporları
|Kalifikasyon faaliyetleri ile elde edilen sonuçlar, uygunsuzluklar ve düzeltici faaliyetler Kalifikasyon Sonuç Raporlarında kaydedilecektir.
|Uyarlanamaz
|
|-
|57
|3.6.3
|Kalifikasyon Gözden Geçirme Toplantısı
|Kalifikasyon Test Prosedürleri ilgili paydaşlar ile hazırlanarak Kalifikasyon Gözden Geçirme Toplantısı gerçekleştirilecektir.
|Uyarlanamaz
|
|-
|58
|3.6.4
|Üretim Hazırlıkları Gözden Geçirme Toplantısı
|Üretim Hazırlıkları Gözden Geçirme Toplantısı gerçekleştirilecektir.
|Uyarlanamaz
|
|-
|59
|3.6.5
|Fonksiyonel Konfigürasyon Denetimi
|Fonksiyonel Konfigürasyon Denetimi gerçekleştirilecektir.
|Uyarlanamaz
|
|-
|60
|4
|Üretim Safhası
|Odak Sistemin ve destek unsurlarının üretilmesi ve test edilmesi faaliyetleri gerçekleştirileceği için uyarlanamaz.
|Uyarlanamaz
|
|-
|61
|4.1
|İlk Üretim Aşaması
|Uyarlanamaz. Üretim faaliyetleri kontrol edilip kabul ve kalifikasyonlar gerçekleştirilecektir.
|Uyarlanamaz
|
|-
|62
|4.1.1
|Üretim Hattı Kalifikasyon Test Prosedürleri
|Üretim hattı kalifikasyonu sağlanacağından uyarlanamaz.
|Uyarlanamaz
|
|-
|63
|4.1.2
|Üretim Hattı Kalifikasyon Sonuç Raporları
|Üretim hattı uygunsuzlukları ile ilgili hataların minimuma indirilmesi hedeflendiğinden uyarlanamaz.
|Uyarlanamaz
|
|-
|64
|4.1.3
|Üretim Planının Gözden Geçirilmesi
|Değişken koşullar dolayısıyla üretim planının güncel tutulması gerektiğinden uyarlanamaz.
|Uyarlanamaz
|
|-
|65
|4.2
|Seri Üretim Aşaması
|Geliştirme sözleşmesi kapsamında sadece prototip üretimi gerçekleştirileceğinden seri üretim aşaması işletilmeyecektir.
|Uyarlanmıştır
|
|-
|66
|5
|Kullanım Safhası
|Odak Sistem etkin hale getirilip kullanıma alınacağı için uyarlanamaz.
|Uyarlanamaz
|
|-
|67
|5.1
|Odak Sistemin Kullanımı Aşaması
|Odak Sistem tanımlı operasyon çevresinde gerekli destek unsurları ile etkin hale getirileceğinden uyarlanamaz.
|Uyarlanamaz
|
|-
|68
|6
|Destek Safhası
|Sistemin ömür devri boyunca kendisinden beklenen kabiliyetleri yerine getirmesi, kullanım sürdürülebilirliğini sağlaması hedeflendiğinden uyarlanamaz.
|Uyarlanamaz
|
|-
|69
|6.1
|Destek Planlama ve Uygulama Aşamaları
|Uyarlanamaz.
|Uyarlanamaz
|
|-
|70
|7
|Envanterden Çıkarma Safhası
|Sahip olunan Odak Sistemin ve destek unsurlarının kullanım süresi sonunda envanterden çıkarma seçenekleri ile değerlendirilmesi finansal etki, yasal yükümlülükler, çevresel faktörler vb. konularda fayda sağlayacağından uyarlanamaz.
|Uyarlanamaz
|
|-
|71
|7.1
|İlişkinin Kesilmesi Usulleri Aşaması
|Odak Sistem ve destek unsurlarının hizmet sürelerinin sonlandırıldığı ve erken safhalarda planlanan faaliyetlerin detaylandırıldığı aşama olduğundan uyarlanamaz.
|Uyarlanamaz
|
|-
|72
|7.1.1
|Envanterden Çıkarma Stratejisi
|Maksimum getiriyi sağlayacak stratejilerin geliştirilmesi gerektiğinden uyarlanamaz.
|Uyarlanamaz
|
|-
|73
|7.2
|İlişkinin Kesilmesi Aşaması
|Envanterden çıkarma stratejileri uygulanacağından uyarlanamaz.
|Uyarlanamaz
|
|-
|74
|7.2.1
|Envanterden Çıkarma Safhası Gerçekleşme Raporu
|Envanterden çıkarma faaliyetlerine yönelik sonuçlar belirtileceğinden uyarlanamaz.
|Uyarlanamaz
|
|}

== 6.2. SİSTEM ÖMÜR DEVRİ KARŞILAŞTIRMALARI ==
Sistem Ömür Devri Yönetimi Rehberi hazırlıkları sırasında NATO AAP-20 standardı referans alınmıştır. Bu bölümde safha isimlendirmelerinin farklı kurumlarda, standartlarda ya da rehberlerde nasıl kullanıldığına dair bilgilendirme amaçlanmıştır.

'''Tablo 5 Farklı Kurumlarda/Standartlarda Sistem Ömür Devri Safhaları Terminolojisi'''
{| class="wikitable"
|'''AAP-20'''
|'''UK MoD'''
|'''US DoD'''
|'''SX000i S-Series Specification'''
|'''NASA Systems Engineering Handbook'''
|'''ISO/IEC 15288 Systems and Software Engineering-System Life Cycle Processes'''
|-
|'''Ön Konsept'''
|Konsept (Concept)
|Sistem Çözümü Analizi (Material Solution Analysis)
| rowspan="2" |Hazırlık (Preparation)
|Konsept Çalışmaları (Concept Studies)
| rowspan="2" |Konsept (Concept)
|-
|'''Konsept'''
|Değerlendirme (Assessment)
|Teknoloji Geliştirme (Technology Development)
|Konsept ve Teknoloji Geliştirme (Concept and Technology Development)
|-
| rowspan="2" |'''Geliştirme'''
| rowspan="2" |Gösterim (Demonstration)
| rowspan="2" |Mühendislik ve Üretim Geliştirme (Engineering and Manufacturing Development)
| rowspan="2" |Geliştirme (Development)
|İlk Tasarım ve Teknoloji (Preliminary Design and Technology)
| rowspan="2" |Geliştirme (Development)
|-
|Son Tasarım (Final Design)
|-
| rowspan="2" |'''Üretim'''
| rowspan="2" |Üretim (Manufacture)
| rowspan="2" |Üretim ve Konuşlanma (Production and Deployment)
| rowspan="2" |Üretim (Production)
|Son Tasarım ve Üretim (Final Design and Fabrication)
| rowspan="2" |Üretim (Production)
|-
|Sistem Montajı, Entegrasyon ve Test, Kullanıma Alma (System Assembly, Integration and Test, Launch)
|-
|'''Kullanım'''
|Kullanım (In-Service)
| rowspan="3" |Operasyon ve Destek (Operations and Support)
| rowspan="2" |Kullanım (In-Service)
| rowspan="2" |Operasyon ve Sürdürülebilirlik (Operations and Sustainment)
|Kullanım (Utilization)
|-
|'''Destek'''
|<nowiki>-</nowiki>
|Destek (Support)
|-
|'''Envanterden Çıkarma'''
|Sonlandırma (Terminate)
|Envanterden Çıkarma (Disposal)
|Envanterden Çıkarma (Closeout)
|Envanterden Çıkarma (Retirement)
|}

= 7. KAYNAKÇA =
1. Systems Engineering and Management for Sustainable Development – Volume II, Edited by Andrew P. Sage, ENCYCLOPEDIA OF LIFE SUPPORT SYSTEMS

2. Systems Life Cycle Costing, Economic Analysis, Estimation and Management John Vail Farr (Basım: 2011), (Modified from Andrews, Richard. 2003. An overview of Acquisition Logistics. DAU)

3. Logistics Engineering and Management (Benjamin S. Blanchard)

4. Systems Engineering and Analysis (Benjamin S. Blanchard &Wolter J. Fabrycky)

5. Systems Engineering Handbook, A Guide for System Life Cycle Processes and Activities, International Council on Systems Engineering, 2010

'''DOKÜMANIN HAZIRLANMASINDA GÖREV ALAN KURUM/KURULUŞLAR'''

SAVUNMA SANAYİİ BAŞKANLIĞI

MİLLİ SAVUNMA BAKANLIĞI

KARA KUVVETLERİ KOMUTANLIĞI

ASKERİ FABRİKALAR GENEL MÜDÜRLÜĞÜ

TERSANELER GENEL MÜDÜRLÜĞÜ

ASELSAN A.Ş.

EPENEK GESG SAVUNMA VE GÜVENLİK SİSTEMLERİ LTD. ŞTİ.

FNSS SAVUNMA SİSTEMLERİ A.Ş.

MİLSOFT YAZILIM TEKNOLOJİLERİ A.Ş.

ROKETSAN A.Ş.

Dosya:Sistem Odak Sistem.png

2023-01-13T07:14:54Z

Oozdemir:

Teknik Yayın Hazırlama Rehberi

2023-01-13T07:11:33Z

Oozdemir:

'''[https://tssodypwiki.ssb.gov.tr/images/d/dc/TSSODYP-12_Teknik_Yay%C4%B1n_Haz%C4%B1rlama_Rehberi_rev.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şkanlığı çatısı altında, ilgili tüm paydaşların katılımıyla faaliyet göstermek üzere Türk Savunma Sanayii Ömür Devri Yönetimi Platformu (TSSÖDYP) kurulmuştur.

TSSÖDYP; savunma ve güvenlik sistemlerine ilişkin ihtiyacın belirlenmesi, sistemlerin tedariki, kullanımı, desteklenmesi ve envanterden çıkarması safhalarını bir bütün halinde ele alan Sistem Ömür Devri Yönetimi ilke ve uygulamalarının ülkemizde yaygınlaştırılmasını ve savunma programlarının/ projelerinin yürütülmesinde savunma ve güvenlik ekosistemini oluşturan tüm paydaşlarca anlayış birliğine ulaşılmasını amaçlamaktadır.

Savunma sistemlerinin ömür devri yönetiminde millî bünyemize uygun, ülkemize özgü çözümler üretmek ve bunları dokümante etmek gibi önemli bir misyonu olan TSSÖDYP; Başkanlığımız, Milli Savunma Bakanlığı ve ilgili birimleri, Genelkurmay Başkanlığı, K.K.K.lığı, Dz.K.K.lığı, Hv.K.K.lığı, J.Gn.K.lığı, S.G.K.lığı, EGM, TÜBİTAK, SASAD ve savunma sanayii firmaları temsilcilerinin katılımı ile çalışmalarına devam etmektedir.

Sistem ömür devri yönetimi yaklaşımı ile; savunma ve güvenlik sistemlerine ilişkin ihtiyacın belirlenmesi aşamasından envanterden çıkarma safhasının sonuna kadar görev alan tüm kamu kurum ve kuruluşları ile özel sektör firmalarının sistemlerin istenilen performans seviyesinde mümkün olan en az maliyetle tedariki, kullanımı ve lojistik desteğinin sağlanabilmesi için görev, yetki ve sorumlulukları çerçevesinde ömür devrinin tamamında birlikte çalışmaları öngörülmektedir.

Bu itibarla, savunma ve güvenlik sistemlerine ilişkin ihtiyacın belirlenmesinin, tedarikinin, kullanımının, lojistik desteğinin ve envanterden çıkarılmasının en baştan uzun soluklu bir program olarak kurgulanmasının ve ilgili birimler aracılığı ile sistem ömür devri yönetimi faaliyetlerinin yürütülmesinin faydalı olacağı değerlendirilmektedir.

TSSÖDYP tarafından son iki buçuk yıl içinde gerçekleştirilen çalışmalar ile savunma ve güvenlik sistemlerinin ömür devri yönetimine ilişkin planlama ve uygulamaya esas olacak yaklaşımları ortaya koyan 13 adet rehber, iki adet bilgi kitapçığı ve bir adet terminoloji dokümanı hazırlanmıştır. Uygulamalardan alınacak geri bildirimler ile söz konusu dokümanların güncellenmesi, geliştirilmesi ve önümüzdeki dönemde uygulamaya esas düzenlemelerin alt yapısını oluşturması hedeflenmektedir.

TSSÖDYP çalışmalarına katkı veren ve dokümanların hazırlanmasında görev alan tüm paydaşlarımıza teşekkürlerimi sunuyorum.

Prof.Dr. İsmail DEMİR

T.C. Cumhurbaşkanlığı

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.

Bu nedenle, tedarik edilen sistemlerin kullanım döneminde hedeflenen muharebe ve/veya operasyon performansının sürdürülebilirliğinin ve maliyet etkinliğinin sağlanması amacıyla sistemlerin ömür devrinde rol ve sorumluluğu bulunan tüm paydaşların katılımı ile Sistem Ömür Devri Yönetimi yaklaşımı geliştirilmiştir.

Sistem Ömür Devri Yönetiminin temel amacı; mevcut durumdaki değişimlere uyum sağlamaktan ziyade gelecekte ortaya çıkabilecek değişimleri öngörmek, belirlenen hedefler doğrultusunda gerekli önlemleri alarak değişimleri yönlendirmek ve kontrol altında tutmaktır. Harekât ihtiyaçlarının zamanında ve verimli şekilde karşılanması ve sahip olunan kaynakların maliyet etkin kullanımı esastır. Başka bir deyişle, sistem ömür devri yönetimi geleceği bugünden tasarlamak ve planlamaktır.

Bu doküman; Savunma Sanayii Başkanlığı (SSB), Milli Savunma Bakanlığının ilgili birimleri, Türk Silahlı Kuvvetleri (TSK), diğer ihtiyaç makamları ve savunma sanayi firmalarında Sistem Ömür Devri Yönetimi’nin bir kültür olarak yaygınlaştırılmasına ve uygulanmasına yönelik rehber oluşturmak amacıyla savunma sistemlerinin ömür devrinde rol ve sorumluluğu bulunan ilgili paydaşların katılımıyla hazırlanmıştır.

Bir ürünün ömür devri boyunca etkin şekilde görev yapabilmesini destekleyen en önemli unsurlardan biri teknik yayınlardır. Teknik yayın; ürünün ömrü boyunca kurulum, işletim, bakım, onarım ve desteği için gerekli dokümanları (basılı veya elektronik ortamda) ve verileri kapsar.

Teknik yayın basılı veya elektronik ortamda bulunan bir doküman olmaktan çok günümüz koşullarında artık bir veri bütünü olarak görülmekte ve yönetilmektedir. Bu bakış açısıyla verilerin en etkin ve verimli şekilde yönetimi sağlanarak kullanıcının istediği zaman ve formatlarda basılı/elektronik doküman oluşturabilmesi daha kolay hale gelmiştir. Ayrıca teknik yayına veri bütünü gözüyle bakılarak, istenen bilgi ve detaylara günümüz bilgi yönetim sistemleri ve gelişen dijital teknolojileri kullanarak erişmek çok daha hızlı ve hatasız olabilmektedir.

Teknik yayın hazırlama rehberi, bu gelişmeler ve süreçler gözetilerek hazırlanmış; dünyada kabul görmüş teknik yayın standartları çerçevesinde ülkemiz ve savunma sanayiimizin gereksinimleri düşünülerek geliştirilmiştir. Ana hedef, savunma ve güvenlik alanında faaliyet gösteren tüm kullanıcıların ihtiyaçları doğrultusunda bilgi oluşturabilmek ve bilgiye en hızlı erişim, bilginin en etkin yönetimi ve standardizasyonun sağlanmasıdır.

= 1. GENEL =

== 1.1. GİRİŞ ==
Teknik yayın konusunda standart gereksinimlerin oluşturulması ile teknik yayın hazırlayan ve kullanan kurumların veya kuruluşların dışında, tedarik makamlarının da tedarik ve satın alma süreçlerinde hızlanma, standardizasyon ve rekabete açık bir ortam sağlayacaktır. Teknik yayınların layıkıyla hazırlanması ve kullanılması sonucunda sistemlerin istenilen performans seviyesinde en az maliyetle ömür devri boyunca kullanılabileceği değerlendirilmektedir.

== 1.2. AMAÇ ==
Teknik Yayın Hazırlama Rehberinin amacı, gerek teknik yayın hazırlayan kurumlara ve kuruluşlara, gerekse teknik yayını kullanan tüm paydaşlara rehber olmak ve teknik yayın konusundaki ister, beklenti ve yöntemleri açıklamaktır.

Teknik yayın gereksinimi ortaya çıktığında; tüm paydaşların aynı hususları algılamasını sağlamak, genel beklentiyi belirlemek ve teknik yayın hazırlanması için izlenecek yöntem ve kuralları ortaya koymaktır.

Bu rehberle teknik yayın hazırlayacak kurumların ve kuruluşların; neleri, nasıl ve hangi kaynaklarla hazırlaması gerektiğini en başından planlayabilmesini sağlamak ve teknik yayını kullanacak kurumların kendilerine nasıl bir doküman ulaşacağını en başından bilmesi ve bu hususları her yayın için standart olarak kabul etmelerini sağlamak hedeflenmiştir.

== 1.3. KAPSAM ==
Teknik Yayın Hazırlama Rehberinin kapsamı; teknik yayın ve verilerin planlanmasına, tasarımına, üretimine, geliştirilmesine, yönetimine, değişimine, dağıtımına, güncelleme takibine ve kullanımına yönelik süreçler, kurallar ve uygulamalardır.

Teknik yayına, bir ürünün işletme, bakım, onarım ve envanterden çıkarma dokümantasyonu ve verisi olarak bakıldığında; ilgili ürüne ait ve ömür devri boyunca işletme, bakım, onarım ve envanterden çıkarma için üretilecek tüm yayınlar ve veriler bu rehberin kapsamı içine girmektedir. Unutulmamalıdır ki Lojistik Destek Analizleri (LDA) sonuçları bu yayınların en önemli girdileridir.

Teknik Yayın Hazırlama Rehberinde, tasarım ve üretime yönelik hazırlanan dokümanlara (tasarım resimleri, CAD modelleri vb.) yer verilmemiştir.

== 1.4. REHBERİN KULLANIMI ==
Teknik Yayın Hazırlama Rehberi, beş bölüm ve üç ekten oluşmaktadır.

Birinci bölüm; giriş, 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.

İkinci bölüm, teknik yayın kavramı konusunda genel bilgi vermektedir. Teknik yayın süreci anlatılmakta ve teknik yayın ile lojistik destek analizleri arasındaki ilişkiler bu bölümde tanımlanmaktadır.

Üçüncü bölümde, teknik yayınların üretilmesi ve sonrasındaki süreçlerde uygulanacak iş kuralları açıklanmıştır. S1000D spesifikasyonu ile ilgili temel bilgiler verilmiştir. İş kurallarının sınıflandırılması, gereklilikleri, dokümante edilmesi, kontrol edilmesi gibi süreçler bu bölümde anlatılmıştır.

Dördüncü bölümde; iki ve üçüncü bölümlerde genel olarak anlatılan süreç ve standartların, karşılaşılan çeşitli projelerdeki isterlere göre uyarlanması detaylandırılmış ve her projenin kendine has özelliklerini dikkate alarak süreç ve standartların uyarlanmasında nasıl bir yol izlenmesi gerektiği anlatılmıştır. Basılı yayın ile etkileşimli elektronik teknik yayın (IETM/P) hazırlama arasındaki farklar ve uygulamalar bu bölümde belirtilmiştir.

Rehberin Ek-A’sında, tedarik makamları tarafından belirlenen/belirlenebilecek veya bir proje çerçevesinde yükleniciler tarafından cevaplanarak dokümante edilmesi beklenen İş Kurallarını listelemektedir.

Ek-B’de, örnek bir teknik yayın formatı şablonu tanımlanmıştır. Kapak, sayfa yapısı, uyarı, dikkat ve notların kullanımı, tabloların yapısı, referans verme kuralları, yol gösterici olması amacıyla bu bölümde örnek olarak verilmiştir. İşbu ek, örnek olması amacıyla hazırlanmış olup, bir proje çerçevesinde üçüncü bölümde ve Ek-A’da belirtilen İş Kuralları kararlarına göre değişiklik gösterebilir.

Ek-C’de, teknik yayın hazırlarken kullanılacak kelime, cümle, cümle yapısı gibi konularda öneri ve yol gösterici olabilecek örnekler verilmiştir.

== 1.5. REHBERİN GÜNCELLENMESİ ==
Rehber; ilgili paydaşların ihtiyacı doğrultusunda güncellenecektir. Değişiklikler, aşağıdaki Değişiklik İzleme Tablosu’ndan izlenecektir.

'''Tablo 1 Değişiklik İzleme Tablosu'''
{| class="wikitable"
|'''YAYIN NO'''
|'''YAYIN TARİHİ'''
|'''DEĞİŞİKLİK YAPILAN BÖLÜM/SAYFA'''
|'''AÇIKLAMA'''
|-
|01
|Ağustos 2021
|<nowiki>-</nowiki>
|İlk yayın
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|}

== 1.6. REFERANS DOKÜMANLAR ==
Teknik Yayın Hazırlama Rehberi’ne referans olan kaynaklar:
{| class="wikitable"
|'''DOKÜMAN NUMARASI'''
|'''DOKÜMAN AÇIKLAMA'''
|-
|'''Def Stan 00-60 (Part 10)'''
|Integrated Logistic Support Part 10: Electronic Documentation
|-
|'''MIL-HDBK-523'''
|Guide to The General Style and Format of S1000D Technical Manual Data Modules
|-
|'''MIL-PRF-38807C'''
|Technical Manuals- Illustrated Parts Breakdown (IPB)
|-
|'''MIL-STD-38784A'''
|DOD Standard Practice General Style And Format Requirements For Technical Manuals
|-
|'''S1000D'''
|International Specification for Technical Publications
|-
|'''S2000M'''
|International Specification for Material Management
|}

{| class="wikitable"
|+
! colspan="2" |'''TSSÖDYP DOKÜMAN SETİ'''
|-
|'''DOKÜMAN ADI '''
| '''DOKÜMAN KODU'''
|-
|Sistem Ömür Devri Yönetimi Rehberi (Ana Çerçeve)
|TSSÖDYP-01
|-
|Sistem Ömür Devri Yönetimi Süreçleri Rehberi
|TSSÖDYP-02
|-
|Ürün Destek Stratejileri ve Modelleri Rehberi
|TSSÖDYP-03
|-
|Entegre Lojistik Destek (ELD) Rehberi
|TSSÖDYP-04
|-
|Entegre Lojistik Destek (ELD) İsterleri Hazırlama Rehberi
| TSSÖDYP-05
|-
|Lojistik Destek Analizleri ve Kayıtları Rehberi
|TSSÖDYP-06
|-
|Tedarik Zinciri Yönetimi Rehberi
|TSSÖDYP-07
|-
|Sistem Ömür Devri Yönetiminde Demodelik Yönetimi Rehberi
|TSSÖDYP-08
|-
|Kullanım ve Destek İhtiyaçları Çerçevesinde Yerlileştirme/

Millîleştirme Rehberi
|TSSÖDYP-09
|-
|Kullanım ve Destek Safhaları Kalite Yönetimi Rehberi
|TSSÖDYP-10
|-
|Sistem Ömür Devri Yönetiminde Konfigürasyon Yönetimi Rehberi
|TSSÖDYP-11
|-
|Teknik Yayın Hazırlama Rehberi
|TSSÖDYP-12
|-
|Eğitim ve Eğitim İhtiyaçları Rehberi
|TSSÖDYP-13
|-
|Sistem Ömür Devri Yönetimi Terminolojisi
|TSSÖDYP-14
|-
|Kodlandırma ve Sınıflandırma Bilgi Kitapçığı
|TSSÖDYP-15
|-
|ASD/AIA S-Serisi ELD Spesifikasyonları Seti Tanıtım Kitapçığı
|TSSÖDYP-16
|}

== 1.7. KISALTMALAR VE TANIMLAR ==

=== 1.7.1. TANIMLAR ===
'''Tablo 2 Tanımlar'''
{| class="wikitable"
|'''TANIM'''
|'''AÇIKLAMA'''
|'''DİĞER KULLANIM'''
|-
|Bilgi Kümesi
|Bilgi kümesi, kararlaştırılan derinlik ve kapsama göre ihtiyaç duyulan bilgilerin (data modülü, görsel, multimedia, v.b.) CSDB içinde, sanal bir başlık altında yönetilmesidir. Bilgi seti olarak da adlandırılmaktadır.
|
|-
|İş Kuralı
Business Rule
|S1000D'nin ilgili bölümünün nasıl uygulanacağı konusunda proje veya organizasyon tarafından alınan karardır.
|
|-
|İş Kuralları Değişimi

Business Rules Exchange
|Bir projede uygulanacak iş kurallarının, belirli bir formata göre standart bir şekilde dokümante edilmesini ve proje kapsamında hazırlanacak olan veri modüllerinin hangi iş kurallarına göre yazıldığının tanımlanabilmesini ve denetlenebilmesini sağlamaya yarayan bir veri modülüdür.
|
|-
|İş Kuralları Karar Noktası

Business Rules Decision Point
|İş Kuralı Karar Noktası, iş kurallarının bir ID, başlık ve açıklama cümlesi ile tanımlanmış haline verilen isimdir.
|
|-
|Ortak Kaynak Veritabanı

Common Source Database
|Bir proje dahilinde teknik yayınları üretmek için gerekli olan tüm nesnelerden oluşan (veri modülleri, resimler, videolar vb.) veri deposudur.
|
|-
|Mevcut Veri
|İçerik olarak güncelliğini ve geçerliliğini koruyan ancak format ve yapı itibari ile S1000D uyumlu olmayan (kağıt baskı, S1000D’den farklı diğer formatlar vb.) verilerdir.
|
|-
|Paylaşılabilir İçerik Nesnesi Referans Modeli

Sharable Content Object Reference Model
|SCORM; eğitim içeriklerinin donanım veya işletim sistemi farklılıklarından etkilenmeden kullanılabildiği, her Web tarayıcı ortamında işletilebildiği, ihtiyaç duyulan her an ilgili içeriklere erişimin mümkün kılındığı ve içeriklerin tekrar kullanılabilirliğinin sağlandığı, içerik paylaşımına dair referans modelin tanımlandığı bir standarttır.
|
|-
|Sistem
|Fonksiyonel olarak farklı görevleri yerine getirebilen, bir veya birden fazla fiziksel parçadan meydana gelen yazılım veya donanımdır.
|
|-
|Şema
|Veri modüllerinin hazırlanmasında kullanılan, XML formatında olan ve farklı kullanım alanlarına göre özelleştirilmiş veri alanlarına sahip şablonlardır.
|
|-
|Teknik Yayın
Technical Publication
|Ürünün ömrü boyunca kurulum, işletim, bakım, onarım ve desteği için gerekli dokümanlar (basılı veya elektronik ortamda) ve verilerdir.
|
|-
|Ürün
Product
|Yüklenici tarafından, sözleşme kapsamında tedarik makamına teslim edilecek ve her bir sözleşme değişikliği için Kabul’e Esas Ürün ve Hizmetler Listesi başlıklı lahikalarında belirtilen kalemler ve bunlara ilişkin tüm sistem, donanım, yazılım ve dokümanlardır. Bu kalemler kara, deniz, hava araçları, platformlar, silah, sistem, yazılım ve bunlara ilişkin tüm destek donanım ve yazılımlarını içerebilir.
|
|-
|Veri Modülü

Data Module
|Ürün ve destek ekipmanının tanımı, çalışması, parçalarının belirlenmesi veya bakımı için gerekli bilgileri içeren bağımsız veri birimi. Veri birimi, tanımlama ve durum bölümü ile içerik bölümünden oluşur.
|
|}

=== 1.7.2. KISALTMALAR ===
'''Tablo 3 Kısaltmalar'''
{| class="wikitable"
|'''Kısaltma'''
|'''Açık Yazımı'''
|'''Diğer Kullanım'''
|-
|ARGE

R&D
|Araştırma-Geliştirme

Research-Development
|
|-
|BRDP
|İş Kuralları Karar Noktası

Business Rules Decision Point
|
|-
|BREX
|İş Kuralları Değişimi

Business Rules Exchange
|
|-
|CAD
|Bilgisayar Destekli Tasarım

Computer Aided Design
|
|-
|CIR
|Ortak Bilgi Havuzu

Common Information Repository
|
|-
|CSDB
|Ortak Kaynak Veritabanı

Common Source Database
|
|-
|DMC
|Veri Modülü Kodu

Data Module Code
|
|-
|EETD/Y

IETM/P
|Etkileşimli Elektronik Teknik Doküman/Yayın

Interactive Electronic Technical Manual/Publication
|
|-
|ELD

ILS
|Entegre Lojistik Destek

Integrated Logistics Support
|
|-
|GMB

RCM
|Güvenilirlik Merkezli Bakım

Reliability Centered Maintenance
|
|-
|HTML
|Hiper Metin İşaret Dili

Hypertext Markup Langauge
|
|-
|ICN
|Bilgi Kontrol Numarası

Information Control Number
|
|-
|IPB/IPC/IPD
|Resimli Parça Kırılımı/Katalogu/Veri

Illustrated Parts Breakdown/Catalog/Data
|
|-
|OSA

LORA
|Onarım Seviyesi Analizi

Level of Repair Analysis
|
|-
|Pdf
|Taşınabilir Doküman Formatı

Portable Document Format
|
|-
|PM
|Yayın Modülü

Publication Module
|
|-
|PMC
|Yayın Modül Kodu

Publication Module Code
|
|-
|PYP
|Proje Yönetim Planı
|
|-
|RAHAT

COTS
|Rafta Hazır Ticari Ürün

Commercially off the Shelf Item
|Raf Ürünü
|-
|SCORM
|Paylaşılabilir İçerik Nesnesi Referans Modeli

Shareable Content Object Reference Model 
|
|-
|SNS
|Standard Numbering Sytem

(S1000D spesifikasyonunda, ürünün referans edilmesinde standardizasyonu sağlayan numaralama sistemidir)
|
|-
|SVİL/DVİL
|Sözleşme Veri İsterleri Listesi

Doküman Veri İsterleri Listesi
|
|-
|TY
|Teknik Yayın
|
|-
|TYP
|Teknik Yayın Planı
|
|}

== 1.8. TABLOLAR ve ŞEKİLLER ==

=== 1.8.1. TABLOLAR ===
Tablo 1 Değişiklik İzleme Tablosu

Tablo 2 Tanımlar

Tablo 3 Kısaltmalar

=== 1.8.2. ŞEKİLLER ===
Şekil 1 Teknik Yayın Üretim Mimarisi

Şekil 2 Veri Modül Kod Yapısı

Şekil 3 Örnek ICN Yapısı

Şekil 4 Yayın Modülü Kodlama Yapısı

Şekil 5 İş Kuralı Kategorileri

Şekil 6 Katmanlı Yapı

Şekil 7: Örnek Katmanlı Yapı

Şekil 8 İş Kuralı Kategorilerinin Belirlenmesi

Şekil 9 Kapak Sayfası (Örnek)

Şekil 10 Değişiklik İzleme Tablosu (Örnek)

Şekil 11 İçindekiler Listesi (Örnek)

Şekil 12 Şekiller Listesi (Örnek)

Şekil 13 Tablolar Listesi (Örnek)

Şekil 14 Kısaltmalar Tablosu (Örnek)

Şekil 15 Tanımlar Tablosu (Örnek)

Şekil 16 Semboller Listesi Tablosu (Örnek)

Şekil 17 Referans Dokümanlar Tablosu (Örnek)

Şekil 18 İlgili Dokümanlar Tablosu (Örnek)

Şekil 19 Başlıklar (Örnek)

Şekil 20 Tablo (Örnek)

Şekil 21 Şekil (Örnek)

Şekil 22 Teknik Yayın Cilt/Klasör (Örnek)

= 2. TEKNİK YAYIN ve SÜREÇLERİ =

== 2.1. TEKNİK YAYIN NEDİR? ==
Teknik Yayın çok genel anlamı ile tanımlayıcı bilgi ve talimatlar olup; ürünün ömrü boyunca kurulum, işletim, bakım, onarım ve desteği için gerekli doküman (basılı veya elektronik ortamda) ve veri olarak tanımlanabilir. Teknik yayınlar; talimat, el kitabı, katalog, prosedür, bülten, broşür, web sayfası, vb. şekilde hazırlanabilir. Ancak bunlarla sınırlı değildir.

== 2.2. TEKNİK YAYIN SÜRECİ ==
Teknik Yayın (TY) üretim süreci genel olarak üç ana aşamadan oluşmaktadır;

* Planlama
* Üretim ve Doğrulama
* Yayım / Teslimat

Teknik Yayın üretim süreci S1000D bölümleri ile olan ilişkilerini de içerecek şekilde Şekil 1’de verilmiştir.
[[Dosya:Şekil1 Teknik Yayın Üretim Mimarisi.jpg|alt=Şekil 1 Teknik Yayın Üretim Mimarisi|sol|küçükresim|500x500pik|Şekil 1 Teknik Yayın Üretim '''Mimarisi''']]

=== 2.2.1. PLANLAMA AŞAMASI ===

==== <big>2.2.1.1. TY PLANININ HAZIRLANMASI</big> ====
Sistem ömür devri yönetimi uygulamaları kapsamında tedarik makamı tarafından yürütülen sözleşmeler ile talep edilen TY listesini SVİL’de, TY’ye ilişkin gereksinimleri ise Teknik Şartname, ELD Planı, TY Gereksinimleri Dokümanı gibi ilgili tanımlama dokümanlarında belirtir.

Üretici sözleşmede yer alan TY gereksinimlerine uygun olarak TY Planı (TYP) hazırlar. TYP proje kapsamında TY’ye yönelik yürütülecek planlama, üretim ve yayım faaliyetlerini tanımlar. TYP bunlarla sınırlı olmayıp aşağıdaki temel bilgileri içermelidir:

* Proje ve ürün tanımında ürüne ilişkin genel bilgiler ile ürün geliştirme programına yönelik bilgiler bulunmalıdır. (TY üretimini etkileyebilecek proje kısıtları ve kabullerine özellikle yer verilmelidir)
* Teslimat kalemleriyle ilgili oluşturulacak TY isimleri, kısa tanımları (kapsam, hedef kitle vb.), yayım yöntemleri (basılı, pdf, HTML vb.), gizlilik dereceleri gibi hususlara ve miktarlarına yer verilmelidir.
* Takvime ilişkin; her bir teslimat kalemi için ana iş kalemleri ve aşamaları başlangıç ve bitiş tarihleri ile belirtilir.
* Standartlar ve kurallar kapsamında; TY üretiminde kullanılacak referans dokümanlar (standart, rehber, biçim kılavuzları vb.) belirtilir.
* Tedarik makamınca sağlanacaklar; TY üretimine ilişkin Üreticiye sağlanacak doküman, cihaz vb. içerir.
* Kabuller; TY doğrulama ve kabul yöntemlerine ilişkin genel bilgileri içerir.
* Telif hakları; TY telif haklarının (yayım, kopyalama, değiştirme vb.) kime ait olduğu belirtilmelidir

TYP’nin Tedarik Makamı/Kullanıcı ile paylaşımı, TY sürecinin sağlıklı yürümesi için tüm taraflar açısından önemlidir. Bazı projelerde TYP’nin kendisi teslimat kalemidir. Ancak TYP’nin teslimat kalemi olmadığı durumlarda, TYP’deki bilgiler ELD Planında ya da Proje Yönetim Planı (PYP) gibi üst dokümanlarla Tedarik Makamı/Kullanıcıya ulaştırılmalıdır.

==== <big>2.2.1.2. ŞABLON VE KURALLARIN BELİRLENMESİ</big> ====
TY Listesinde yer alan her bir doküman için şablon ve kurallar (iş kuralları) belirlenir.

TY Şablonu; dokümanda yer alacak bölümler (dış kapak, iç kapak, değişiklik takip, uyarılar, içindekiler, bölümler, kısımlar, paragraflar, indeks, arka kapak gibi bölümler) kullanılacak biçimler, görsellerin kullanımı gibi dokümanın içeriği ve genel yapısı hakkında bilgi veren dokümanlardır. TY Şablonu, TY’leri hazırlayacak ekibi yönlendirmekle birlikte Kullanıcı/Tedarik Makamının erken aşamada TY’ye ilişkin görüş ve önerilerini almak için kullanılır.

TY Şablonu, TY Planında belirtilen standart ve kurallara uyumlu şekilde hazırlanır. TY Şablonu belirlenirken, var ise Kullanıcı/Tedarik Makamının belirlediği şablon ve kurallardan, genel biçim kılavuzlarından ve bu dokümanda referans bölümünde yer alan standartlardan faydalanılır.

TY hazırlanırken kullanılacak genel kurallar TY Planında belirtilmiş olmalıdır. TY Planında belirtilen kurallar burada detaylandırılır. Kurallara ilişkin detaylar Bölüm 3 içinde açıklanmıştır.

TY Listesinde yer alan her bir doküman için teknik yayın numarası belirlenmiş olmalıdır. TY numarası Kullanıcı/Tedarik Makamı tarafından belirlenen yönteme uygun olarak belirlenir ve dokümante edilir.

==== <big>2.2.1.3. ANA HATLARIN BELİRLENMESİ</big> ====
Ana hat, her bir teknik yayın kapsamında yer alacak olan konu başlıklarını içeren dokümandır. Bu yönüyle ana hatlar teknik yayının iskeleti olarak değerlendirilebilir. Detaylı ve kapsamlı bir ana hattın hazırlanması, ürünün kullanımı ve idamesine ilişkin tüm bilginin TY’de yer almasını sağlamak için vazgeçilmezdir.

Ana hat, TY'nin içeriğini hiyerarşik bir yapıda bütüncül olarak sunar;
[[Dosya:Şekil Doküman Bölüm.jpg|sol|küçükresim|400x400pik]]

TY sürecinin erken aşamalarında (planlama aşamasında) tamamlanması gereken ana hattı oluşturmak için, ürün ve mevcut ise benzer ürünlere ilişkin mevcut dokümanları (teknik tanımlama, tasarım, üretim, ELD dokümanları gibi) incelemek ve analiz etmek gerekir. Ürüne ilişkin azami bilgi edindikten sonra belirlenmiş olan standart içerik var ise buna uygun olarak TY kullanıcısına (hedef kitleye) aktarılması gereken konu başlıkları belirlenir.

Ana hatların Tedarik Makamı/Kullanıcı onayına sunulması önemlidir. Bu sayede, henüz başlangıç aşamasında, Tedarik Makamı/Kullanıcının TY süreci ve çıktıları hakkında bilgi sahibi olması sağlanmış ve görüşleri alınmış olunur.

=== 2.2.2. ÜRETIM VE DOĞRULAMA AŞAMASI ===

==== <big>2.2.2.1. İÇERİKLERİN GELİŞTİRİLMESİ</big> ====
Ana hatta yer alan her bir başlık (paragraf) LDA çıktıları ve ürün dokümanları (tanımlama, tasarım, üretim dokümanları gibi) kullanılarak oluşturulur. TY’de temelde dört tür bilgi yer alır. Bunlar; arayüz, kavramsal, talimat ve referans bilgileridir.

'''Arayüz bilgileri''', ürünü ve işlevlerini açıklayan bilgilerdir. Donanım için arayüz bilgisi genellikle fotoğraf veya çizim şeklindedir (örneğin patlatılmış görüntüler (exploded views)). Yazılım için ise genellikle bağlama duyarlı yardım (help) kullanılır (örneğin elektronik etiketler (tooltips)).

Arayüz bilgilerini oluşturmak için daha çok tanımlama ve tasarım dokümanlarından, mevcut ise de prototip ürünlerden faydalanılır. TY'de yer alan görseller fotoğraf ya da 2D/3D yani iki ya da üç boyutlu teknik çizimler kullanılarak üretilir.

'''Kavramsal bilgiler;''' ürünün bir özelliğinin arkasındaki ‘niçin’ sorusuna cevap verir ki bu okuyucunun konuyu anlaması ve pekiştirmesi için gereklidir çünkü kavramsal bilgiler TY'yi bir arada tutan yapıştırıcı gibidirler, kavramsal bilgiler olmadan TY sadece bir adımlar listesidir. Kavramsal bilgilere genel olarak TY'nin giriş bölümlerinde yer verilir ve kavramsal bilgileri oluşturmak için tanımlama ve tasarım dokümanlarından faydalanılır.

'''Talimat bilgileri;''' bir işin nasıl yapılacağını adım adım açıklayan iş odaklı bilgilerdir (örn. kullanım ve bakım ve onarım talimatları). TY'lerin büyük bölümü ürünün nasıl kullanılacağı ya da bakım ve onarımının nasıl yapılacağını içeren talimat bilgilerinden oluşur. Talimat bilgilerini oluşturmak için LDA, test ve üretim dokümanlarından, mevcut ise prototip ürünlerden faydalanılır.

'''Referans bilgileri;''' okuyucuların ihtiyaç duyduklarında erişmeleri üzerine sunulan bilgilerdir (örn: sözlük, kısaltmalar listesi. vb.). Sözlük bu kategoriye en iyi örnektir. Referans bilgileri oluşturmak için tasarım dokümanları ve ilgili referans dokümanlardan (standartlar vb.) faydalanılır.

==== <big>2.2.2.2. TY ÜRETİMİ (İLK TASLAK)</big> ====
İçerik üretim ve yayım ortamının farklı olduğu durumlarda içerikler (bilgi kümeleri) ana hat ve şablona uygun olarak yayım ortamına aktarılır. İçerik yazımı ve yayım için MS Word ve Adobe Frame Maker gibi yaygın kullanılan yazımlar olmakla birlikte büyük projelerde kurumsal düzeyde (tasarım, üretim gibi diğer süreçlerle entegre çalışan) yazım ve yayım yazılımları mevcuttur. S1000D standardında içerik yazımı için S1000D uyumlu editörler kullanılır.

İçeriklerin yayım ortamında birbirine entegre edilmesi ile ilk taslak TY hazırlanmış olur. İlk taslak TY, Üretici bünyesinde kontrol için gözden geçirmeye çıkarılır. Bu aşamada;

* Tasarım ekibi ve konu uzmanları içeriği teknik olarak kontrol eder.
* Eş düzey teknik yazarlar TY'yi şekil, düzen ve bütünlük açısından değerlendirir.
* S1000D uyumlu yayınlar, BREX veri modülü vasıtası ile iş kuralları açısından kalite kontrol sürecine tabi tutulur.
* Tespit edilen hatalar ve eksiklikler gözden geçirme ekibince karara bağlanıp giderildikten sonra ilk taslak sürüm hazır hale gelir.

==== <big>2.2.2.3. EDİTÖR KONTROLÜ (ARA TASLAK)</big> ====
İlk taslak TY, üretici bünyesinde editör kontrolüne sunulur. Editörler mevcut TY'yi aşağıdaki kontrollerden geçirir;

* Şablon ve biçimlere uygunluk,
* Terminoloji bütünlüğü,
* Yazım ve dil bilgisi kurallarına uygunluk,
* Bilgilerin açık ve anlaşılır olması,
* İçeriğin tam, tutarlı ve iyi düzenlenmiş olması,
* Baskı ve yayıma uygunluğu,
* İş kurallarına uygunluk.

Tespit edilen hususlar gözden geçirme ekibince değerlendirilerek TY'ye yansıtılır. Böylece ara taslak sürüm TY doğrulama için hazırdır.

==== <big>2.2.2.4. DOĞRULAMA (SON TASLAK)</big> ====
TY'nin yeterliliği ve doğruluğu, ürün ile uyumu Üretici sorumluluğundadır. Üretici, Tedarik Makamı/Kullanıcı ile yapacağı doğrulamayı önce kendi bünyesinde gerçekleştirerek hazırlıkları tamamlar, sonrasında doğrulamayı Tedarik Makamı/Kullanıcı ile gerçekleştirir.

Doğrulama için ürün geliştirme süreci ve LDA'nın ilgili görevleri tamamlanmış olmalıdır. TY'de yer alan tüm bilgiler;

* Mümkün olduğunca son ürün ya da üretim prototipi üzerinde uygulama ve gözlem ile doğrulanır,
* Mümkün olmadığında ise LDA kapsamında gerçekleştirilen bakım görevleri analizi ve çıktıları kullanılarak doğrulanır.

Doğrulama aşamasında tespit edilen hata ve eksiklikler Üretici tarafından TY'ye yansıtılır.

=== 2.2.3. YAYIM/TESLIMAT ===

==== <big>2.2.3.1. DOKÜMANLARIN ONAYLANMASI VE YAYIMLANMASI</big> ====
Doğrulaması yapılmış TY’lerin basım kontrolleri, aşağıda verilen denetimleri içerecek şekilde baskı öncesinde Üretici tarafından yapılır;

* Şablona uygunluk,
* Sağ ve sol sayfa düzeni,
* Sayfa sonu ve sayfalarda metin uzunluğu dengesi,
* Sayfa sonunda cümle bölünmesinin olmaması,
* Başlıklar ve altlıklar,
* Şekil ve tablo numaralandırmaları,
* Çapraz referans uyumu (linkler, bkz., dipnot vb.),
* Kapak, iç kapak, şekil listesi, tablo listesi, içindekiler, indeks vb. doğruluğu.

Denetim sonrası TY'ler genelde PDF formatına dönüştürülerek basıma hazır hale getirilir.

Denetimi tamamlanmış TY’ler Son Taslak olarak Tedarik Makamı/Kullanıcı onayına sunulur. TY’ler, TY Planı ve sözleşmeye uygun olarak Tedarik Makamı/Kullanıcı tarafından kontrol edilir. Tedarik Makamı/Kullanıcı tespitleri Üretici ile birlikte değerlendirilir ve TY’lere uygulanacak değişiklikler belirlenir. Üretici bu değişiklikleri TY’lere uygular ve TY’leri tekrar onaya sunar.

Onaylanan TY'ler, doküman planında belirtildiği şekilde ve miktarda basılı ve/veya elektronik ortamda ilk sürüm TY olarak hazır edilir.

Elektronik ortamda yayımlanacak dokümanlar (IETM/P) ve veri modülleri, uygun yazım ve yayım araçları ile xml, html vb. yapıda yayımlanır.

==== <big>2.2.3.2. DEĞİŞİKLİK YÖNETİMİ</big> ====
Yayım sonrasında özellikle teknolojik yenilikler nedeniyle üründe yapılan değişikliklerin TY’lere yansıtılması, dokümanda tespit edilen hatalar var ise bunların giderilmesi gerekir.

Değişiklikleri çeşitli açılardan sınıflandırılması:

* Değişiklik nedenine göre:

o Editoryal (Yazım)

o Format/Düzen

o İçerik

* Değişiklik tipine göre:

o Ekleme

o Düzeltme

o Silme

* Değişiklik önem derecesine göre:

o Rutin

o Acil

o Emniyet Kritik

Değişiklik önem derecesine göre yürütülecek süreçler:

* Rutin: Teknik dokümanlarda yapılan, ancak müşterinin iş süreçlerinde bir değişiklik yaratmayacak değişikliklerdir. Rutin önem derecesindeki değişikliklerin, bir sonraki doküman teslim tarihine kadar bekletilerek, zamanı geldiğinde ihtiyaç sahibi/tedarik makamına iletilmesi gerekir.

* Acil: Teknik dokümanlarda, sistem/cihaz güvenliği veya insan hayatına etki etmeyen ancak ihtiyaç sahibinin iş süreçlerine etki eden değişikliklerdir. Acil önem derecesindeki değişikliklerin ihtiyaç sahibine bildirilme süresi, proje, bakım anlaşması vb., dokümanlar çerçevesinde belirlenmelidir.

* Emniyet Kritik: Teknik dokümanlarda, sistem/cihaz güvenliğine veya insan hayatına etki eden değişikliklerdir. Emniyet Kritik önem derecesindeki değişikliklerin teknik dokümana yansıtılması zaman alabileceğinden, ihtiyaç sahibinin elindeki dokümantasyonun problemli bölümü ve ihtiyaç sahibine önerilen geçici çözüm, en hızlı iletişim yolu (mail, kurye vb.) ile ihtiyaç sahibine ulaştırılacaktır. Değişikliğin teknik doküman yansıtılması ve ihtiyaç sahibine bildirilme süresi, proje, bakım anlaşması vb., dokümanlar çerçevesinde belirlenmelidir.

Yayımlanan TY’lere ilişkin değişiklikler, ilgili proje/sözleşmenin Konfigürasyon Yönetim Planına uygun olarak yönetilmelidir. Uygulanacak değişiklikler “2.2.2 Üretim ve Doğrulama Aşaması” ile “2.2.3 Yayım/Teslimat” bölümlerinde açıklanan süreçlere uygun olarak yürütülür. Değişiklikler TY’lerde yer alan Değişiklik Çizelgelerine işlenir, TY’lerin sürüm tarihi ve numarası revize edilir. Yeni sürüm TY’ler Tedarik Makamı/Kullanıcılara yayımlanır.

Savunma ve güvenlik ürünlerinin ömrünün uzun olduğu değerlendirildiğinde TY’lerin güncellenmesi, ürün ile uyumunun sağlanması ayrı bir önem arz eder. Bu nedenle TY güncellemelerine ürün destek stratejilerinde yer verilmiş olmalıdır.

== 2.3. LOJİSTİK DESTEK ANALİZLERİ (LDA) ==
Lojistik Destek Analizleri; lojistik destek faaliyetlerinin maliyet etkin olarak yürütülmesinde yol gösterici en önemli faaliyettir. Tüm lojistik destek faaliyetlerinin teknik disiplin içinde maliyet etkin olarak planlanması, koordine edilmesi ve yönetilmesi için LDA rehberliğinde;

* Ürün ve destek unsurları; desteklenebilirlik, güvenilirlik, test edilebilirlik ve uygun ömür devri maliyeti ile tasarlanır.
* Kullanım ve Destek Safhaları boyunca ürünün istenilen performans seviyesinde kullanılabilmesi için ihtiyaç duyulan kaynaklar tanımlanır.
* ELD elemanlarına ilişkin esas bilgiler oluşturulur.

Sistem ömür devri boyunca olası darboğazların öngörülmesi, bahse konu darboğazların bertaraf edilmesine yönelik önleyici planların oluşturulması ve oluşturulan önleyici planların iyileştirilmesi, geliştirilmesi ve yönetilmesi amacıyla Lojistik Destek Analizleri tekrarlamalı olarak yürütülür.(Bkz. [https://tssodypwiki.ssb.gov.tr/index.php/Lojistik_Destek_Analizleri_ve_Kay%C4%B1tlar%C4%B1_Rehberi TSSÖDYP-06 LDA ve Kayıtları Rehberi])

=== 2.3.1. TEKNIK YAYIN VE LDA ARASINDAKI İLIŞKILER ===
Lojistik Destek Analizi temelde ürünün desteği için gerekli kaynakların tanımlanması ve destek maliyetini düşürmek için tasarımı etkilemek amacıyla yapıldığı dikkate alındığında, teknik yayının içereceği bakım ve onarım bilgilerinin oluşturulması faaliyetlerinde LDA çıktıları önemli bir girdi oluşturacaktır.

Teknik doküman yazımına esas olacak LDA temelde son kullanıcı gereksinimleri, mühendislik çizimleri, mühendislik spesifikasyonları, idame edilebilirlik ve desteklenebilirlik verisi, üretici verileri gibi kaynakları esas alır.

Teknik yayınlar açısından, LDA çıktılarının en önemlileri aşağıda listelenmiştir;

* LDA Aday Kalem Listesi (Candidate Item List),
* Bakım Görev Analizi (Maintenance Task Analysis),
* Planlı Bakım Analizi (Scheduled Maintenence Analysis),
* Onarım Seviyesi Analizi (Level of Repair Analysis),
* Bakım Tahsis Çizelgesi (Maintenance Allocation Chart).

=== 2.3.2. LDA ADAY KALEM LISTESI ===
Lojistik Destek Analizi faaliyetleri arasında yer alan LDA adaylarının belirlenmesi süreci, teknik yayınlardaki bakım ve onarım görevlerinde ve resimli parça kataloğunda yer alacak, yani bakım faaliyetlerinde bulunulacak kalemlerin belirlenmesi için temel teşkil eder. LDA faaliyetleri belirlenen bu adaylar için yürütülür ve LDA aday kalem listesinde yer alır.

=== 2.3.3. BAKIM GÖREV ANALİZİ ===
Yürütülen LDA faaliyetleri arasında teknik yayınlar ile en çok ilgili olanı Bakım Görev Analizi’dir. LDA ve ilgili diğer analizler (RCM vb.) sonucu belirlenen planlı/plansız bakım görevlerine ait ihtiyaçlar, LDA sürecinin en temel analizlerinden olan Bakım Görev Analizi (MTA) ile belirlenmektedir. MTA sürecinde ilk olarak bakım ve onarım görevinin anlaşılırlığının arttırılıp görevin yürütülmesi sürecini kolaylaştırmak için görev alt görevlere ve adımlara ayrılır. Görevin öncesinde ve sonrasında yürütülmesi gereken faaliyetler belirlenir. Bakım görevinin yürütülmesi için gereken lojistik ihtiyaçlar (yedekler, personel, destek ve test ekipmanları, tesis, vb.) belirlenir.

Sökme, takma, test, arıza bulma/giderme, vb. bakım görevlerine ait teknik yayınlar hazırlanırken MTA çıktıları kullanılmaktadır. Bu analizin çıktıları çoğu zaman doğrudan kullanılamaz. Bilhassa prosedürlerin içerikleri konusunda MTA çıktıları ile teknik yayınlar arasında farklar yer almaktadır. Bu farklar prosedürlerin teknik olarak içeriğinin değiştirilmesinden ziyade prosedürün ifade ediliş tarzının değiştirilmesi şeklindedir.

MTA çıktısı olarak hazırlanan prosedürde adımlar, süreci anlatacak detayda olmakla birlikte bu detay bir teknik yayın çıktısı ile kıyaslandığında yetersizdir. Teknik yayınlar standartları gereği birçok kurala tabidirler. Teknik yayın hazırlanma sürecinde MTA çıktılarının prosedürel kısımları ilgili teknik yayın standardına uygun olarak tekrar ifade edilir. Bu aşamada adımlar sadeleştirilip sayıları arttırılabilir, kullanılan kelimelerde değişiklikler yapılabilir. MTA çıktılarından yedekler, sarf malzemeleri, test/destek ekipmanları da yine ilgili teknik yayın standardına uygun olarak, teknik yayın içerisinde yerini alır.

=== 2.3.4. PLANLI BAKIM ANALİZİ ===
Planlı bakım görevlerinin belirleneceği analizlerin sonucunda;

* Planlı bakım görevleri ve aralıkları tanımlanır.
* Tanımlanan görevler Lojistik Destek Analizi (LDA) sürecinde detaylandırılır.

İdame edilebilirlik çalışmaları sürecinde değerlendirilen lojistik gereksinimler, LDA içinde yer alır ve uyuşmazlık gösteren durumlar tasarım birimlerine bildirilerek gerekli önlemlerin alınması doğrultusunda, ürünün desteklenebilirliği ve idame edilebilirliği takip edilir.

Tanımlanan planlı bakımlar; bakım aralıkları, personel, bakım süreleri, destek ekipman gereksinimleri ve bakımda kullanılan malzemeler vb. veriler doğrultusunda değerlendirilir ve ilgili bakımın yapılacağı yer, zaman ve düzeltici bakım görevleri tanımlanır.

Ayrıca MTA sürecinde tanımlanan bakım görevleri sırasında ihtiyaç duyulacak destek ekipmanları ve altyapı gereksinimleri için olması gereken özellikler de belirlenir.

Analiz çıktıları, Bakım Planlama dokümanı, Bakım El Kitabı ve/veya Veri Modülü (Data Module) içinde yer almak üzere, Teknik Yayın sorumlusuna iletilir.

=== 2.3.5. ONARIM SEVİYESİ ANALİZİ ===
Onarım seviyesi analizi (LORA) ile bakım adayı parçalar için, bakım planının sınırları ve LORA aday parçalarının bakım ve onarımı için en düşük işletim ve destek maliyeti belirlenir.

LORA ihtiyaç makamının operasyon senaryolarına uyumlu, maliyet etkin ve yararlı bir bakım konsepti oluşturmak için her bir aday parçaya mantıklı bir onarım seviyesi belirleme analizi yapılarak gerçekleştirilir. LORA süreci genel olarak iki aşamadan oluşur. Birincisi, arızalı parçanın onarılabilir mi ya da elden çıkarılabilir mi olduğu kararının verilmesi, ikincisi ise, onarılabilir olma durumuna karar verilen parçaların hangi bakım seviyesinde onarılacağı kararının verilmesidir. Ekonomik olmayan değerler karar aşamasında etkili olmadığı takdirde, sınırlı sayıda ekonomik faktör de değerlendirmeye dâhil edilebilir. Bu sınırlı sayıdaki ekonomik faktörler, analizi genişletmek ve ömür devri maliyetini düşürmek için dikkate alınmalıdır.

LORA, LDA süreci ile iç içe geçmiş bir süreçtir ve analizler çalışma saatleri, bakım işlemleri oranı, bakım zamanları, bakım aletleri ve bakım maliyeti ile ekonomik olmayan faktörler (bakım personeli meslek ve beceri gereksinimleri) gibi operasyonel ve destek faktörlerinin değerlendirmeleri tekrarlanarak yapılır. LDA’nın bir parçası olarak LORA sürecinde LDA sonuçları kullanılır ve sonrasında Lojistik Destek Analiz Kayıt sonuçları girdi oluşturur.

LORA’nın en önemli çıktısı olan Kaynak, Bakım/Onarım ve Geri Kazanım (SM&R) Kodu, doğrudan bakım ve onarım ile ilişkili olup Lojistik Destek Analiz Kaydı veri tabanında tutulmalıdır. SM&R kodu aday parçaya uygulanabilecek bakım ve onarım faaliyetlerini sistematik olarak betimlemek için kullanılan bir koddur.

=== 2.3.6. BAKIM TAHSİS ÇİZELGESİ ===
LDA süreçlerinde belirlenen tüm bakım görevleri belirlenen formatta ve belirlenen bakım seviyeleri için; lojistik kırılım bilgilerini, bakım türünü, bakım süresini, gerekli destek ekipmanı gibi bilgileri içerecek şekilde Bakım Tahsis Çizelgesi sunulur.

Bakım Tahsis Çizelgeleri, bakım ve onarıma yönelik olarak hazırlanan teknik yayında yer alan görevlerin ilgili bakım kademesine uygun olarak seçilmesinde kullanılır.

== 2.4. ORTAK BİLGİ HAVUZU ==
Ortak Bilgi Havuzu konsepti, bir proje çerçevesinde veya kurum içindeki her projede ortak olarak kullanılacak bilgileri (doküman, talimat, LDA kayıtları, figür, multimedya öğeler vb.) bir havuzda toplamak ve kullanıcıların bu havuzdan faydalanarak gereken dokümanları üretmelerini sağlamak üzere ortaya konmuştur.

Ortak Bilgi Havuzuna toplanacak bilgilere örnek olarak dikkat ve uyarılar, malzeme bilgileri, destek ekipmanları sayılabilir.

Ortak Bilgi Havuzu oluşturup yönetilerek;

* Kurumda üretilmiş her dokümanda aynı kavram ve bilgiler kullanılarak tutarlılık sağlanır.
* Hatalı bilgileri kaynağında (Ortak Bilgi Havuzunda) düzelterek bu bilgiler referans verilen tüm dokümanlarda eş zamanlı olarak düzeltilmesi yapılır.
* Ortak Bilgi Havuzuna girilen bir bilginin tüm ekip tarafından kullanılması sağlanarak tekrarlı girişler azaltılır. Böylece hata yapma olasılığı düşer.

= 3. İŞ KURALLARI =

== 3.1. AMAÇ ==
Bu bölümün amacı, S1000D’nin uygulanacağı projelerde iş kuralı kavramını detaylı olarak tanımlamak ve S1000D ile uyumlu kalabilmek için yanıtlanması zorunlu olan iş kurallarının ne zaman ve kimler tarafından belirlenmesi gerektiğini açıklamaktır.

== 3.2. KAPSAM ==
S1000D spesifikasyonunun teknik yayın süreçlerinin tamamında (planlama, yönetim, üretim, revizyon takibi/yönetimi, dağıtım ve kullanım) uygulanan uyarlama (tailoring) faaliyetlerini kapsamaktadır.

== 3.3. İŞ KURALI NEDİR? ==
İş Kuralı, S1000D spesifikasyonu ile hazırlanacak teknik yayınların planlanması, yönetimi, üretimi, değişimi, dağıtımı, kullanımı ile ilgili alınan kararların tümüdür. S1000D’nin içeriğinde yer almayan ancak S1000D’nin uygulanması üzerinde etkisi olan diğer tüm konular hakkında alınan kararlar da iş kuralıdır.

İş Kuralı Karar Noktası, iş kurallarının bir ID (unique identifier), başlık ve açıklama cümlesi ile tanımlanmış haline verilen isimdir. Bu yapı S1000D’nin 4.1 versiyonu ile birlikte ortaya çıkmıştır.

== 3.4. İŞ KURALLARI NEDEN ÖNEMLİDİR? ==
S1000D, savunma ve güvenlik alanında faaliyet gösteren ihtiyaç makamı, tedarik makamı, kullanıcı ve yüklenicilerin (uygulayıcılar) tercihine bırakılan pek çok seçeneğin yer aldığı bir spesifikasyondur. Eğer bu uygulayıcılar, S1000D’de tanımlanan şemaları, süreçleri, Standart Numbering System (SNS) yapılarını, bilgi kodlarını, bilgi kümelerini vb. açıklayıcı içerikleri nasıl kullanacaklarına dair standart bir yol haritası çizmezlerse S1000D ile uyumlu, ancak kendi içinde uyumsuz içeriklerin hazırlanması riski doğacaktır. Bu durum, bir projedeki dokümantasyon faaliyetlerinde çalışacak birden fazla paydaşın olması durumunda daha da karmaşık bir hal alacaktır. Aşağıdaki örnekler olası risklerin bir kısmını ortaya koymaktadır:

* Projede kullanılacak SNS yapısının belirlenmemesi, hazırlanan veri modüllerinin üretilen ürünün kırılımında bulunan hangi alt sistem veya cihaza ait olduğunun yöneticiler, yazarlar ve son kullanıcılar tarafından anlaşılamamasına neden olacaktır.
* Hazırlanan veri modüllerinin bir kısmında metin vurgusunun kelimeleri kalınlaştırarak bir kısmında ise kelimelerin altının çizerek yapılması, son kullanıcı açısından yanlış anlaşılmalara neden olacaktır.
* Görsel nesnelerin ve çoklu ortam nesnelerinin formatlarına karar verilmemesi halinde yazılım ihtiyacının tam anlaşılamamasından dolayı IETP gösterim araçlarında bazı görsel nesneler ve çoklu ortam nesneleri görüntülenemeyecektir.
* Gizlilik derecelendirmesi bulunan içeriklerin listelenmemesi ve ilgili içeriklere erişim yetkilerinin tanımlanmaması, güvenlik açıklarına neden olacaktır.
* S1000D’nin bazı versiyonlarındaki şemaların eleman ve nitelik isimleri farklıdır. Eğer projede uygulanacak S1000D versiyonu/versiyonları belirlenmezse farklı versiyonlarda hazırlanan veri modüllerinin birbirleri ile ilişkilendirilmesi güçlük yaratacaktır. Ayrıca eski versiyona adapte olan kişiler yeni versiyonun, yeni versiyona adapte olan kişiler de eski versiyonun içeriğine hakim olmayabilirler.

Bu durum süreçlerin ve ürünlerin yönetilmesi açısından proje süresince ciddi problemler doğuracaktır.

Bu ve benzer riskler, önlem alınmadığı takdirde düzeltilmesi maliyetli olacak sorunlar yaratacaktır. İş kurallarının önemi bu noktada ortaya çıkmaktadır. İş kuralları, tanımından da anlaşılacağı gibi proje kapsamında yürütülecek dokümantasyon faaliyetlerinin ve dokümantasyonla ilişkili diğer faaliyetlerin planlanmasını sağlamaktadır. Bu nedenle yukarıda belirtilen veya benzeri risklere karşı alınabilecek en iyi önlem; teknik yayınlarla ilgili gereksinimlerin çok net tanımlandığı, iş akışlarının ve süreçlerinin tasarlandığı, bilgi güvenliği ile ilgili açık noktanın bırakılmadığı, S1000D’nin sunduğu seçenekler arasından proje ihtiyaçlarını karşılayacak olanların belirlenerek standart bir uygulama planının ortaya konduğu kuralları belirlemek, dokümante etmek ve dokümantasyon faaliyetlerinde rol alacak kişi ve kurumları belirlenen bu kurallar konusunda bilinçlendirmektir.

== 3.5. GENEL ==
İş kuralı kavramı ilk olarak S1000D’nin 2.0 versiyonu ile kullanılmaya başlanmıştır. Versiyon 2.2 ile beraber iş kurallarının standart bir yapıda dokümante edilmesine olanak tanıyan İş Kuralları Değişimi (BREX) şeması yayınlanmıştır. Versiyon 4.1 yayınlanana kadar iş kuralları kavramı, yayınlanan her sürümle beraber hem daha detaylı açıklamalarla tanımlanmış hem de yer aldığı konu başlıklarının sayısı artmıştır. Versiyon 4.1’in yayınlanmasıyla beraber ise iş kurallarına standart bir yapı kazandırılarak İş Kuralı Karar Noktası (BRDP) kavramı ortaya atılmıştır. Böylece iş kurallarının izlenebilirliği arttırılmıştır. Versiyon 4.2 ile birlikte iş kurallarının dokümante edilmesine yönelik BREX şemasına ek olarak brdoc şeması yayınlanmıştır.

İş kurallarının proje ihtiyaçları çerçevesinde tanımlanması ve dokümante edilmesi, S1000D’nin 4.1 versiyonu ile beraber uygulanması zorunlu olan ana kriterlerinden birisi halini almıştır. İş kurallarının çeşitli kategoriler altında sınıflandırılması, bu süreç boyunca iş kurallarının daha iyi anlaşılmasında, birbirleri ile ilişkili olan iş kurallarının tespit edilmesinde ve iş kuralları arasındaki farklılıkların daha net ortaya konulmasında oldukça yararlı olmaktadır. İş kurallarının kategoriler altında sınıflandırılması, karar noktalarının kapsamını standart bir yapıya sokarak taraflar arasında ortaya çıkabilecek görüş ayrılıklarını da önlemektedir.

Bazı iş kuralları projeden projeye (proje ihtiyaçları ve proje kapsamı doğrultusunda) tanımlanabilecekken, bazı iş kuralları ise alınan birtakım kurumsal/organizasyonel kararların her projede aynı şekilde uygulanmasını gerektirebilir. Örnek vermek gerekirse; teknik dokümanların yazılacağı dil, üretici firma açısından projeden projeye, müşteriden müşteriye göre farklılık gösterebilir. Ancak tedarik makamları için teknik dokümanların yazılacağı dilin Türkçe olması kurumsal bir karardır ve her projede olduğu gibi uygulanması istenebilir. Projelerde farklı karar alıcıların bulunması nedeniyle ortaya çıkabilecek karışıklıkların önlenmesi için iş kuralları katmanlı bir yapıda dokümante edilmelidir.

Katmanlı iş kurallarının uygulandığı projelerde, birbirleri ile ilişkili olabilecek karar noktalarının bulunması nedeniyle bir katmanda “A” iş kuralı hakkında alınan karar ile farklı bir katmanda “B” iş kuralı için alınan karar arasında çelişki doğabilir. Farklı bir örnekte ise bir üretici, daha önceki bir projede hazırlamış olduğu içerikleri yeni bir projede de kullanmak istediği zaman, iş kurallarının bu iki proje arasında ciddi farklılıklar göstermesi durumunda aynı içeriği tekrar kullanabilmek için S1000D’nin farklı birtakım yöntemlerini kullanmak zorunda kalabilir.

İş kurallarının katmanlı bir yapıda belirlenmesi, bunların bir kısmının birbirleri ile ilişkili olması nedeniyle kurumlar arasındaki hiyerarşide olduğu gibi yukarıdan aşağıya doğru lineer bir biçimde yapılamaz. Örnek vermek gerekirse, BRDP-S1-00006 numaralı karar noktası projede kullanılacak şemaların belirlenmesini ister. Üst katmanlardan birisinin bu karar noktası hakkında “projede sadece IPD, procedure ve descriptive şemaları kullanılacaktır.” gibi kesin bir karar alması, Ortak Bilgi Havuzu (CIR) şemasının kullanımına karar verilen BRDP-S1-00375 numaralı iş kuralının alt katmana bırakılması ve alt katmanın/katmanların CIR’ı kullanma yönünde olumlu karar alması durumunda, projenin iş kuralları arasında çelişkili bir durum oluşturacaktır. Karar katmanları arasında ortaya çıkabilecek bu gibi çatışmaların önlenmesi ile ilgili öneriler Madde 3.8.1’de yer almaktadır.

== 3.6. TEMEL BİLGİLER ==
Bu bölümde, iş kurallarında bahsi geçen ve S1000D spesifikasyonuna özgü temel yapı ve elemanların açıklamalarına yer verilmiştir.

=== 3.6.1. ORTAK KAYNAK VERİ TABANI (CSDB) ===
Ortak kaynak veri tabanı, bilginin yönetilmesinde kullanılan en önemli ve kritik elemandır. Bu eleman, projenin ihtiyaç duyduğu tüm yayınları oluşturan bilginin, görsel öğenin, multi-medyanın, v.b. verilerin yönetildiği alandır.

CSDB’nin ana görevleri:

* Teknik yayın oluşturma prosesini,
* Doküman yazarlarının kontrolünü,
* Doküman Kalite kontrol sürecini,
* İş ortakları, tedarikçiler ve müşteriler arasındaki veri transferini,
* Depolandığı yerdeki formatından bağımsız olarak çeşitli medyalarda görüntülenmek üzere teknik yayın üretimini sağlamaktır.

CSDB içinde yönetilen, referans edilebilen ve değiştirilebilen tüm objeler CSDB Objesi olarak tanımlanır ve aşağıda listelenmiştir:

* Veri modülleri
* Veri modüllerinde referanslı görsel öğeler, multimedia ve diğer veriler
* Veri yönetim listeleri (Data management lists)
* Yorum modülleri (Comments)
* Yayın modülleri (Publication modules)
* Veri değişim listeleri (Data dispatch notes)

=== 3.6.2. CSDB OBJELERİ ===
Bu bölümde CSDB objeleri arasından, S1000D uygulamalarında sıklıkla kullanılan temel yapılar tanıtılacaktır.

=== 3.6.2.1. VERİ MODÜLÜ ===
Veri Modülü, kendi başına anlamlı olacak şekilde bilgi içeren en küçük ünitedir. Veri modüllerinin içeriğini metinler, görsel öğeler, multimedia öğeleri vb. veriler oluşturmaktadır. Veri modülleri bunlardan sadece metinleri doğrudan içinde tutar. Geri kalan görsel öğe, multimedia vb. verilere referans verilir. Formatı XML’dir.

Veri modülleri S1000D spesifikasyonu tarafından belirlenen şemalar kullanılarak hazırlanır. Bu şemalardan bazıları:

* Açıklama Bilgileri Şeması
* Prosedür Bilgi Şeması
* Hata Giderme Bilgi Şeması
* Bakım Planlama Bilgi Şeması
* Kullanıcı/Operatör Bilgi Şeması
* Resimli Parça Kataloğu Bilgi Şeması
* Kablolama Veri Şeması
* Servis Bülteni Şeması
* Bakım Kontrol Çizelgesi ve Muayene Şeması
* İş Kuralları Değişimi (BREX) Şeması

Teknik dokümanı veri modülleri halinde ayrıştırıp tasarlarken, farklı dokümanlarda da kullanılabilecek veri modülleri oluşturmaya çok dikkat etmek gerekmektedir. Tekrar kullanılabilir içerikler oluşturmak hem dokümanların yazılma/hazırlanma sürelerini kısaltacaktır, hem de kontrolünü ve revizyon takibini oldukça kolaylaştıracaktır. Ancak veri modüllerin kullanımı sırasında da zincirleme referanslar (iç içe çok fazla referans kullanımı) oluşturmaktan da kaçınmak önerilir. Aksi halde veri modüllerinin birbirleri ile olan ilişkilerini takip etmekte zorluklar ortaya çıkacaktır.

==== <big>3.6.2.2. GÖRSEL ÖĞE VE MULTİMEDYALAR</big> ====
Görsel öğe, videolar, vb. multimedia nesneleri, teknik içeriklerin anlaşılırlığını arttırmak maksadıyla, yazılı olarak yapılan tarif ve tanımlamaların üç boyutlu veya iki boyutlu materyallere dönüştürülmüş halleridir.

S1000D spesifikasyonu ile uyumlu dokümanlar hazırlanabilmesi için, teknik dokümanlarda yer alan tüm görsel öğeler, videolar, vb. multimedia nesneleri Bilgi Kontrol Numarası (ICN) kodu ile tanımlanmış fiziksel dosyalar halinde CSDB’de yönetilmek zorundadır.

==== <big>3.6.2.3. YAYIN MODÜLÜ</big> ====
Yayının aslında veri modüllerinden oluşmaktadır. Bu yapı yayın modülü ile sağlanır. Yayın modülleri, bir teknik yayının hangi içeriklerden oluşacağının referans edilerek tanımlandığı ve bu içerikler arasındaki başlık hiyerarşisinin kurgulandığı yerdir. Yayın modülleri de tıpkı veri modülleri gibi XML formatındadır. Yayın modüllerinde yer alan referanslar;

* Veri modüllerine,
* Yayın modüllerine,
* Mevcut teknik yayınlara (içerik açısından güncel ancak dosya formatı açısından S1000D’ye uygun olmayan yayınlar) yapılabilir.

=== 3.6.3. KODLAMA YAPILARI ===
CSDB Objelerinin, S1000D spesifikasyonunda tanımlanan yöntemlere göre kodlanması gerekmektedir. Bu kodları oluşturan alanlarda kullanılacak bilgilerin, projenin dokümantasyon faaliyetlerine ve hatta içerik analizine başlamadan önce tanımlanmış ve kararlaştırılmış olması çok önemlidir.

==== <big>3.6.3.1. VERİ MODÜLÜ KODLAMA (DMC) YAPISI</big> ====
Veri modülü kodu, bir veri modülünün standart bir formatı bulunan tanımlayıcısıdır. Veri modülü kodu, veri modülünün “identAndStatusSection” elemanının altında yer almaktadır. Veri modülü kodu, dil ve ülke kodu, versiyon ve taslak sürüm numaraları ile birlikte kullanıldığında veri modülünü özgün olarak tanımlar. Bu kod, bir veri modülünün CSDB içinde yönetilebilmesini sağlar.

Veri modülü kodu minimum 17, maksimum 41 karakterden oluşmaktadır. 41 karakter için örnek yapı aşağıda verilmiştir.
[[Dosya:Şekil2 Veri Modül Kod Yapısı.jpg|alt=Şekil 2 Veri Modül Kod Yapısı|sol|küçükresim|600x600pik|Şekil 2 Veri Modül Kod Yapısı]]

Veri modülü kodunu oluşturan bilgi haneleri aşağıda tanımlanmıştır:

* Model Tanımlama Kodu: Dokümantasyonu yapılacak olan Ürünü veya Projeyi tanımlamaktadır. Bu kod, Ürüne/Sisteme ait tüm modelleri kapsayıcı nitelikte olmalıdır.
* Sistem Ayrım Kodu: Bir Sisteme/Ürüne ait alt sistemlerin, alt-alt sistemlerin ve bileşenlerin alternatiflerini belirtmek için kullanılan bir koddur.
* SNS: Projeyi/Ürünü oluşturan sistemleri, cihazları, bileşenleri, parçaları, v.b. standart bir dille tarif edebilmek için dizayn edilmiştir.
** Malzeme Kalem Kategori Kodu: SNS’leri kullanım koşullarına/alanlarına göre (kara, hava, deniz, ordonat, taktik füze vb.) kategorize etmek için kullanılan koddur.
** Sistem Kodu: Sistemde/Üründe yer alan sistemlerin tanımlanmasında kullanılır.
** Alt Sistem Kodu: Sistemi oluşturan alt sistemlerin tanımlanmasında kullanılır.
** Alt Alt Sistem Kodu: Alt sistemleri oluşturan alt alt sistemlerin tanımlanmasında kullanılır.
** Bileşen Kodu: Alt alt sistemleri oluşturan bileşenlerin tanımlanmasında kullanılır.

* Sökme Kodu: SNS’in yetmediği hallerde, bileşen seviyesinin altında kalan diğer tüm ürün kılımının tanımlanmasında kullanılır.
* Sökme Kodu Türevi: Sistemin/Ürünün sökme kodu ile numaralandırılan ünitelerine/bileşenlerine ait alternatiflerin tanımlanmasında kullanılır.
* Bilgi Kodu: Veri modülünün içinde ne tür bilgilerin olduğunu tanımlayan koddur. (Bakım, işletme talimatı, vb.)
* Bilgi Kodu Türevi: Veri modülünde yer alan bilgilerin alternatiflerinin tanımlanmasında kullanılır.
* Kalem Konum Kodu: Bir kalemin lokasyonuna göre bilginin sınıflandırılmasında kullanılan koddur. Bu kodun alabileceği değerler aşağıdaki gibidir:
** "A" – Ürünün/Sistemin üstünde takılı olan objeler için geçerlidir.
** "B" – Ürünün/Sistemin üstünden sökülen bir ana bileşene montajlı olan objeler için geçerlidir.
** "C" – Tezgah üstündeki objeler için geçerlidir.
** "D" – Üç kategoriyi de kapsayan bilgilerdir (A, B ve C kategorileri).
** "T" – Eğitim ile ilgili bilgilerdir.

* Eğitim Kodu: Opsiyonel bir koddur. Eğitim ve insan performansı ile ilgili veri modüllerinin içinde ne tür bilgilerin bulunduğunu tanımlayan koddur.
* Eğitim Etkinlik Kodu: Eğitim Kodu ile birlikte kullanımı zorunlu olan bir koddur. Eğitim ve insan performansı ile ilgili içeriklerin türünün tanımlanmasında kullanılır.
** "A" – Eğitim Planı
** "B" – Eğitim İçeriğinin Genel Değerlendirmesi
** "C" – Eğitim İçeriği
** "D" – Eğitim Özeti
** "E" – Ölçme ve Değerlendirme

'''Örnek-1:''' Bir deniz platformuna ait veri modülünün kodlandırılması

NOT: Bu örnek uygulamada iş kuralları arasından '''BRDP-S1-00001''' numaralı, '''"I" ve "O" karakterlerinin kullanımı''' başlıklı iş kuralında “I” ve “O” karakterlerinin kullanımı serbest bırakılmıştır.

NOT: Bu örnek uygulamada iş kuralları arasından '''BRDP-S1-00003''' numaralı, '''Uygulanacak S1000D versiyonu''' başlıklı iş kuralında S1000D’nin 4.1 versiyonunun uygulanmasına karar verilmiştir.

NOT: Bu örnek uygulamada iş kuralları arasından '''BRDP-S1-00337''' numaralı, '''Malzeme Kalem Kategori Kodunun kullanımı''' başlıklı iş kuralında Malzeme Kalem Kategori Kodunun kullanılmasına karar verilmiştir.

NOT: Bu örnek uygulamada iş kuralları arasından '''BRDP-S1-00336''' numaralı, '''Ürün SNS yapısı''' başlıklı iş kuralında S1000D spesifikasyonunda tanımlanmış olan SNS yapısının kullanılmasına karar verilmiştir. SNS’te yer alan bileşen kodunun 4 karakter olarak kullanılmasına karar verilmiştir. SNS yapısının tamamının Poje İş Kuralları dokümanında indekslendiği varsayılacaktır.

NOT: Bu örnek uygulamada iş kuralları arasından '''BRDP-S1-00334''' numaralı, '''Sistem farklılık kodunun tahsisi''' başlıklı iş kuralının tanımlandığı ve kullanılabilecek değerlerin Poje İş Kuralları dokümanında indekslendiği varsayılacaktır.

NOT: Bu örnek uygulamada iş kuralları arasından '''BRDP-S1-00332''' numaralı, '''Ürene tahsis edilecek model tanımlama kodu''' başlıklı iş kuralının tanımlandığı ve kullanılabilecek değerlerin Poje İş Kuralları dokümanında indekslendiği varsayılacaktır.

(''Bu örnekte tüm resimli parça kataloğu dokümanından bahsedilmemektedir. Yalnızca ana tahrik dizeline ait, patlatılmış resim ve bu resimde pozlanmış parçalara ait bilgilerin yer alacağı bir adet veri modülünden bahsedilmektedir''.)

MILGEM Projesi kapsamında üretilen TCG Heybeliada ve TCG Büyükada korvetlerine ait ana tahrik dizellerinin resimli parça bilgisinin yer aldığı veri modülünün kodu aşağıdaki gibidir:

'''DMC-MILGEM-AAA-HA1-50-0000-010-941A-D'''

İlgili veri modülünde yer alan;

* Model Tanımlama Kodu olarak Proje’nin adı “MILGEM” kullanılmıştır.
* Sistem Ayrım Kodu olarak “AAA” değeri kullanılmıştır.
* SNS yapısı olarak S1000D spesifikasyonunda yer alan bölüm 8.2.8 kullanılmıştır. Sistem Kodu, Malzeme Kalem Kategori Kodu ile birlikte kullanılmıştır.
** Malzeme Kalem Kategori Kodu deniz sistemleri için “H” değerini alır.
** Sistem Kodu, bir deniz platformunun ana tahrik dizeli için “A1” değerini alır.
** Alt Sistem Kodu, bir deniz platformunun ana tahrik dizeli için “5” değerini alır.
** Alt Alt Sistem Kodu, bir deniz platformunun ana tahrik dizeli için “0” değerini alır.
** Bileşen kodu, Proje İş Kuralları Dokümanı’nda tanımlandığı şekilde, ana tahrik dizeli için “0000” değerini alır.

* Sökme Kodu, ilgili veri modülünün resimli parça kataloğuna ait olması nedeniyle “01” değeri kullanılmıştır.
* Sökme Kodu Türevi, ilgili veri modülü baz resmi içerdiğinden “0” değeri kullanılmıştır.
* Bilgi Kodu, resimli parça kataloğu veri modülleri için, S1000D spesifikasyonu bölüm 8.4.2’de “941” olarak belirtilmiştir. Bu nedenle bilgi kodu olarak “941” kullanılmıştır.
* Bilgi Kodu Türevi olarak “A” değeri kullanılmıştır.
* Kalem Konum Kodu, ilgili veri modülünde yer alan teknik içerikler, ”A”, “B” ve “C” koşullarının 3’ü için de geçerli olduğundan “D” değerinin kullanılmıştır.

'''Örnek-2:''' Bir kara platformuna ait veri modülünün kodlandırılması

NOT: Bu örnek uygulamada iş kuralları arasından '''BRDP-S1-00001''' numaralı, '''"I" ve "O" karakterlerinin kullanımı''' başlıklı iş kuralında “I” ve “O” karakterlerinin kullanımı serbest bırakılmıştır.

NOT: Bu örnek uygulamada iş kuralları arasından '''BRDP-S1-00003''' numaralı, '''Uygulanacak S1000D versiyonu''' başlıklı iş kuralında S1000D’nin 4.1 versiyonunun uygulanmasına karar verilmiştir.

NOT: Bu örnek uygulamada iş kuralları arasından '''BRDP-S1-00337''' numaralı, '''Malzeme Kalem Kategori Kodunun kullanımı''' başlıklı iş kuralında Malzeme Kalem Kategori Kodunun kullanılmasına karar verilmiştir.

NOT: Bu örnek uygulamada iş kuralları arasından '''BRDP-S1-00336''' numaralı, '''Ürün SNS yapısı''' başlıklı iş kuralında S1000D spesifikasyonunda tanımlanmış olan SNS yapısının kullanılmasına karar verilmiştir. Bileşen kodunun 4 karakter olarak kullanılmasına karar verilmiştir. Ayrıca SNS yapısının tamamının Poje İş Kuralları dokümanında indekslendiği varsayılacaktır.

NOT: Bu örnek uygulamada iş kuralları arasından '''BRDP-S1-00334''' numaralı, '''Sistem farklılık kodunun tahsisi''' başlıklı iş kuralının tanımlandığı ve kullanılabilecek değerlerin Poje İş Kuralları dokümanında indekslendiği varsayılacaktır.

NOT: Bu örnek uygulamada iş kuralları arasından '''BRDP-S1-00332''' numaralı, '''Ürene tahsis edilecek model tanımlama kodu''' başlıklı iş kuralının tanımlandığı ve kullanılabilecek değerlerin Poje İş Kuralları dokümanında indekslendiği varsayılacaktır.

Fırtına Obüslerine ait güç grubunun yakıt pompasının sökülüp yerine yenisinin takıldığı bakım prosedürüne ait veri modülünün kodu aşağıdaki gibidir:

'''DMC-FIRTINA-AAA-GA1-12-0100-00AAA-921A-A'''

İlgili veri modülünde yer alan;

* Model Tanımlama Kodu olarak Platform’un adı “FIRTINA” kullanılmıştır.
* Sistem Ayrım Kodu olarak, “AAA” değerinin kullanılmıştır.
* SNS yapısı olarak S1000D spesifikasyonunda yer alan bölüm 8.2.8 kullanılmıştır. Sistem Kodu, Malzeme Kalem Kategori Kodu ile birlikte kullanılmıştır.
** Malzeme Kalem Kategori Kodu kara sistemleri için “G” değerini alır.
** Sistem Kodu, bir kara platformunun güç grubu için “A1” değerini alır.
** Alt Sistem Kodu, bir kara platformunun güç grubunun dizel motoru için “1” değerini alır.
** Alt Alt Sistem Kodu, Proje İş Kuralları Dokümanı’nda tanımlandığı şekilde, güç grubunun dizel motoruna ait yakıt sistemi için “2” değerini alır.
** Bileşen kodu, Proje İş Kuralları Dokümanı’nda tanımlandığı şekilde, güç grubunun dizel motoruna ait yakıt pompası için “0100” değerini alır.

* Sökme Kodu, SNS yapısı veri modülüne konu olan ürün kırılımını tanımlamakta yeterli olduğundan “00” değeri kullanılmıştır.
* Sökme Kodu Türevi, “AAA” değeri kullanılmıştır.
* Bilgi Kodu, bir parçanın sökülüp yenisi ile değiştirildiği bakım işlemlerinin yer aldığı veri modülleri için, S1000D spesifikasyonu bölüm 8.4.2’de “921” olarak belirtilmiştir. Bu nedenle bilgi kodu olarak “921” kullanılmıştır.
* Bilgi Kodu Türevi olarak “A” değeri kullanılmıştır.
* Kalem Konum Kodu, ilgili veri modülünde yer alan teknik içerikler, yalnızca yakıt pompası güç grubu üstünde montajlı haldeyken geçerli olacağından, ”A” değerinin kullanılmıştır.

==== <big>3.6.3.2. GÖRSEL ÖĞE KODLAMA YAPISI (ICN)</big> ====
ICN kodu, bir görsel öğe, multimedia vb. verilerin standart formatları bulunan tanımlayıcısıdır. ICN kodu, diğer CSDB objelerinden farklı olarak yalnızca dosya adında tanımlanabilir (S1000D versiyon 4.2 ile birlikte ICN tanımlayıcı-veri (meta-data) şeması geliştirilmiştir. Bu durumla birlikte ICN kodu bilgisi hem ICN tanımlayıcı-veri dosyasında hem de ilgili görsel nesnenin dosya adında tutulmaya başlanmıştır.). Bu kod, görsel öğe, multimedia vb. verilerin CSDB içinde yönetilebilmesini sağlar.

S1000D spesifikasyonunda görsel öğe, multimedia veya diğer medyaların kodlandırılmasında iki farklı kod yapısı tanımlanmıştır. Bu bölümde, bunlardan yalnızca SNS yapısını içermekte olan kodlama formatına yer verilecektir.

ICN kodu minimum 29, maksimum 47 karakterden oluşmaktadır.
[[Dosya:Şekil3 Örnek ICN Yapısı.jpg|alt=Şekil 3 Örnek ICN Yapısı|sol|küçükresim|600x600pik|Şekil 3 Örnek ICN Yapısı]]

* Önek: Önek olarak “ICN” kullanılır.
* Model Tanımlama Kodu (MIC): Veri modülü kodundaki kullanımı ile aynıdır.
* Sistem Ayrım Kodu: Veri modülü kodundaki kullanımı ile aynıdır.
* SNS: Veri modülü kodundaki kullanımı ile aynıdır
* Sorumlu Firma Kodu: Sorumlu firma kodu, bir görsel öğe, multimedia vb. verilerden, veri modüllerinde kullanımı hariç olarak, sorumlu olan firmayı tanımlayan bir koddur. Bu kod, proje ekibi veya organizasyon tarafından tanımlanmalıdır.
* Üretici Kodu: Üretici kodu, bir görsel öğe, multimedia vb. verileri hazırlayan firmanın CAGE kodu bilgisidir.
* Özgün Tanımlayıcı: Özgün tanımlayıcı beş alfanümerik karakterden oluşur. Bu tanımlayıcı, aynı MIC, SNS, üretici ve sorumlu firma koduna sahip olan nesnelerin özgün bir şekilde tanımlanmasını sağlar.
* Türev Kodu: Türev kodu, bir alfanümerik karakterden oluşur. Bu kod, görsel öğenin, multimedianın vb. verilerin varyasyonlarını tanımlar. Bir görsel öğenin baz hali için bu değer “A” olarak kullanılır. Aynı görsel öğenin türevleri için bu değer “B” den başlayarak “Z”ye kadar arttırılır. Bir görsel öğenin türevi, ilgili görselin ölçeklenmiş, kırpılmış, döndürülmüş ve/veya açıklayıcı notlar eklenmiş halidir.
* Versiyon Numarası: Görsel öğenin versiyon bilgisini tanımlar.
* Gizlilik Derecesi: Görsel öğenin gizlilik derecesini tanımlar.

==== <big>3.6.3.3. YAYIN MODÜLÜ KODLAMA YAPISI</big> ====
Yayın modülü kodu, bir yayın modülünün standart bir formatı bulunan tanımlayıcısıdır. Yayın modülü kodu, yayın modülünün “identAndStatusSection” elemanının altında yer almaktadır. Yayın modülü kodu, dil ve ülke kodu, versiyon ve taslak sürüm numaraları ile birlikte kullanıldığında yayın modülünü özgün olarak tanımlar. Bu kod, bir yayın modülünün CSDB içinde yönetilebilmesini sağlar.

Yayın modülü kodu minimum 14, maksimum 26 karakterden oluşmaktadır.
[[Dosya:Şekil4 Yayın Modülü Kodlama Yapısı.jpg|alt=Şekil 4 Yayın Modülü Kodlama Yapısı|sol|küçükresim|550x550pik|Şekil 4 Yayın Modülü Kodlama Yapısı]]

* Model Tanımlama Kodu (MIC): Veri modülü kodundaki kullanımı ile aynıdır.
* Tanzim Eden Otorite: Yayın modülünü tanzim eden firmanın/kurumun CAGE kodu bilgisini tanımlar.
* Yayın Numarası: Yayın modülünün numarasını tanımlar.
* Cilt Numarası: Yayın modülünün cilt numarasını tanımlar.

== 3.7. İŞ KURALI KATEGORİLERİ ==
İş kuralı kategorisi; ürün tanımlama, bakım felsefesi ve kullanım konsepti, gizlilik ve güvenlik, iş süreçleri, verilerin oluşturulması, verilerin transfer edilmesi, veri bütünlüğünün korunması ve yönetilmesi, çıktı formatı ve mevcut verilerin yönetimi ve kullanımı gibi farklı pek çok konuda uygulanabilecek kuralların tanımlandığı özgün bir gruplandırma şeklidir.

S1000D’nin içinde on farklı iş kuralı kategorisi tanımlanmıştır. Bu kategoriler, iş kuralı geliştiricilerin S1000D içinde yer alan tüm majör iş kurallarını değerlendirmelerini sağlayacak şekilde tanımlanmıştır.

Bir iş kuralı birden fazla kategorinin altında sınıflandırılabilir. Ayrıca iş kuralı kategorileri de birbirinden izole yapılar değildir. Bazı kategoriler birbirleri ile ilişkili hatta birbirini tamamlayan özelliktedir. Örnek vermek gerekirse; İş Kuralı Kategorisi 7 (Veri Transferi) ile İş Kuralı Kategorisi 8 (Veri Bütünlüğü ve Yönetimi) arasında ilişkili konular/kararlar vardır.

İş Kuralı Kategorileri aşağıdaki şekilde belirtilmiştir.
[[Dosya:Şekil 5 İş Kuralı Kategorileri.png|alt=Şekil 5 İş Kuralı Kategorileri|sol|küçükresim|500x500pik|Şekil 5 İş Kuralı Kategorileri]]

Kategorilerin açıklandığı alt başlıklarda verilen örnekler zorlayıcı özellikte olmayıp, ilgili alt başlıkların anlaşılabilirliğini arttırıcı yönde katkı sağlayacağı düşünüldüğünden verilmiştir.

=== 3.7.1. KATEGORİ 1- GENEL ===
Genel kategorisi altında sınıflandırılan iş kuralları, diğer kategoriler altında sınıflandırılamayan ve S1000D’nin uygulanmasında dokümantasyon süreçlerinin üzerinde daha geniş bir etki alanı olan kurallardır.

Genel kategorisi aşağıdaki kuralları içermekle beraber bunlarla sınırlı değildir:

* S1000D’nin hangi versiyonunun uygulanacağı,
* Projede S1000D’nin hangi bölümlerinin kullanılacağının ve uygulanacağının tanımlanması,
* Dil birliğinin sağlanması ve anlam karmaşasına düşülmemesi için proje boyunca kullanılacak kavramların tanımlanması.

Aşağıdaki karar noktaları, bu kategoriye örnek teşkil etmektedir:

'''İş Kuralı Karar Noktası BRDP-S1-00003 – Uygulanacak S1000D versiyonu''':

* S1000D’nin hangi versiyonunun veya versiyonlarının uygulanacağına karar ver.

'''İş Kuralı Karar Noktası BRDP-S1-00008 – Muhtemel teslimatlar''':

* Teslimat kalemlerinin ne olacağına karar ver:
** S1000D nesnelerinin (veri modülleri, yayın modülleri, görsel öğelerin listesi ve çoklu ortam nesneleri, veri modül listeleri, vb.) dosya tabanlı transfer metodu ile teslimi.
** Sayfa formatlı yayınlar ve/veya etkileşimli elektronik teknik yayınlar (IETM)

=== 3.7.2. KATEGORİ 2- ÜRÜN TANIMLAMA ===
Ürün tanımlama kategorisi, proje faaliyetleri kapsamında teknik yayınları hazırlanacak olan ürünün kırılımı (fiziksel veya fonksiyonel kırılım) ile veri modülü kodlandırma stratejisi arasındaki ilişkileri tanımlayan iş kurallarını içermektedir. Veri modül kodu, veri modülünün ait olduğu konfigürasyon elemanının ve veri modülünün içerdiği bilginin tanımlandığı iki ana gruptan oluşmaktadır. Bu kategoride konfigürasyon elemanının tanımlandığı grup ile ilgili iş kuralları ele alınmaktadır. Ayrıca alt yüklenicilerden tedarik edilecek alt sistemler ve bunların tanımlanması da bu kategori altında değerlendirilmelidir.

Veri modül kodunda, konfigürasyon elemanının tanımlandığı grupta, bize ürün kırılımına ait bilgiyi veren SNS yapısı bulunmaktadır. Projede kullanılacak SNS yapısı genellikle mühendislik veya tasarım faaliyetleri sırasında oluşturulan ürün kırılımı ile birlikte tanımlanmaktadır.

Ürün tanımlama kategorisi ayrıca içerik filtresi (applicability) ile ilgili kuralları da kapsamaktadır.

Ürün tanımlama kategorisi aşağıdaki kuralları içermekle beraber bunlarla sınırlı değildir:

Ürünün ve alt kırılımının tanımlanmasında kullanılacak;

* Model Tanımlama Kodu (MIC),
* Sistem Ayrım Kodu,
* Malzeme Kalem Kategori Kodu,
* SNS yapısının (S1000D’de yer alan SNS yapılarından hangisinin uygulanacağının belirlenmesi veya projeye özgü SNS yapılarının hazırlanması ile ilgili alınan karar)
* Sökme Kodu,
* Sökme Kodu Türevi,
* İçerik filtresi (applicability) bilgilerinin belirlenmesi.

Aşağıdaki karar noktası, bu kategoriye örnek teşkil etmektedir:

'''İş Kuralı Karar Noktası BRDP-S1-00331– Veri modülü kodlama stratejisi''':

* Ürün ve projede uygulanacak veri modülü kodlama stratejisini belirle.

=== 3.7.3. KATEGORİ 3- BAKIM FELSEFESİ VE KULLANIM KONSEPTİ ===
Bakım felsefesi ve kullanım konsepti kategorisi, bir kurumun veya projenin teknik dokümantasyon faaliyetlerinde ihtiyaç duyduğu bilgilerin tanımlandığı iş kurallarını kapsamaktadır. Bu bilgiler başlıca teknik dokümanların kapsam ve içerik derinliğinin tanımlandığı bilgi kümelerinin listesi ve/veya detaylı tanımlarını, veri modül kodunun ikinci ana grubu olan ve bilginin tanımlandığı kodlandırma yapısında yer alan bilgi kodunu, bilgi kodu türevini, kalem yerleşim kodunu ve bilgi kodunun taşıyacağı adı içermektedir. Bilgi kümeleri hakkındaki detaylı bilginin hangi kategoride (Kategori 1 veya 3) tanımlanması gerektiği kurum veya projede dokümantasyon faaliyetlerini yönetecek grupların kararına bırakılmıştır.

Bakım felsefesi ve kullanım konsepti ile ilgili iş kuralları, sözleşmede tanımlanmakta veya sözleşmede yapılan tanımlamalara göre yanıtlanmaktadır.

Bu kategorinin altında bulunan iş kuralları, proje çerçevesinde varsa yürütülecek LDA faaliyetleri ile uyum içinde tanımlanmalıdır.

Veri modüllerinin kodlama stratejisinin bir parçası olan bilgi kodunun, bilgi kodu türevinin ve kalem yerleşim kodunun tanımlanması bu kategorinin altında gerçekleştirilir. Bu işlem, projenin/kurumun teknik doküman ihtiyacının tanımlandığı karar noktaları (kategori 1) ve veri modül kodunda ürün kırılımının tanımlandığı karar noktaları (kategori 2) ile birlikte düşünülmelidir.

Ayrıca eğitim ve beceri düzeylerinin tanımlanması ile ilgili iş kuralları da bu kategorinin altında yer almaktadır.

Bakım felsefesi ve kullanım konsepti kategorisi aşağıdaki kuralları içermekle beraber bunlarla sınırlı değildir:

* Kullanılacak bilgi kümelerinin yapılarının listelenmesi,
* Kullanılacak bilgi kümelerinin detaylı bir şekilde açıklanması,
* Kullanılacak bilgi kodlarının ve bilgi kodu adlarının listelenmesi veya detaylı olarak açıklanması,
* Kullanılacak kalem yerleşim kodlarının belirlenmesi,
* Teslim edilecek veri modüllerinde yer alan/alacak içeriklerin derinliğinin bakım seviyelerine göre belirlenmesi,
* Veri modül kodlarında kullanılacak bilgi kodlarının ve kalem yerleşim kodunun belirlendiği iş kurallarının, kategori 2’de yer alan ürün kırılımı tanımlamaya dönük iş kuralları ile eşleştirilmesi,
* Bilgi kodu türevlerinin nasıl kullanılacağının belirlenmesi,
* Eğitim ve beceri düzeyi bilgilerinin nasıl kullanılacağının belirlenmesi.

Aşağıdaki karar noktası, bu kategoriye örnek teşkil etmektedir:

'''İş Kuralı Karar Noktası BRDP-S1-00052– Bilgi kod ve isimlendirmesi''':

* Kullanılacak bilgi kod ve isimlerine karar ver.

=== 3.7.4. KATEGORİ 4- GİZLİLİK VE GÜVENLİK ===
Gizlilik ve güvenlik kategorisi güvenlik, gizlilik ve telif hakları ile ilgili tüm konuları kapsamaktadır. Bu kategori başlıca gizlilik derecelendirmesinin ve telif hakkı işaretlerinin nasıl kullanılacağının, içeriklerin kullanımı veya açığa çıkması ile ilgili kısıtlamaların, içeriğin imhası ile ilgili talimatların ve diğer benzer kısıtlamaların tanımlandığı iş kurallarını kapsamaktadır.

Ayrıca verilerin oluşturulmasında, gözden geçirilmesinde, değişiklik ve düzeltme yapılmasında, yönetilmesinde vb. diğer faaliyetlerdeki yetkilerin tanımlanması konusu da bu kategorinin altında yer almaktadır. Örnek vermek gerekirse, birden fazla kurumun dokümantasyon faaliyetlerinde birlikte çalışması gereken projelerde; yönetici kurum/kuruluş/şirket gizlilik derecesi bulunan verilerin veya telif hakkı açısından kısıtlamaların bulunduğu verilerin oluşturulmasında, gözden geçirilmesinde, değişiklik ve düzeltme yapılmasında, yönetilmesinde vb. diğer faaliyetlerde kimin hangi yetkilere sahip olacağına dair kısıtlamalarda bulunabilir.

Gizlilik ve güvenlik ile ilgili iş kurallarının belirlenmesi sırasında ulusal güvenlik kısıtlamalarının göz önünde bulundurulması gerekmektedir.

Gizlilik ve güvenlik iş kurallarının belirlenmesinde, projenin güvenlik talimatları kullanılmalıdır.

Gizlilik ve güvenlik kategorisi aşağıdaki kuralları içermekle beraber bunlarla sınırlı değildir:

* Gizlilik derecelendirmelerinin ve bunların kullanımının tanımlanması,
* Telif hakkı işaretlemelerinin kullanımının belirlenmesi,
* Bilginin kullanımı, dağıtımı, açığa çıkarılması, imhası vb. ile ilgili talimatların belirlenmesi,
* Ulusal güvenlik kısıtlamalarının tanımlanması,
* Varsa projeye özel gizlilik talimatlarının tanımlanması,
* Gizlilik derecelendirmelerine göre kişi ve/veya kurumların yetkilerinin tanımlanması.

Aşağıdaki karar noktası, bu kategoriye örnek teşkil etmektedir:

'''İş Kuralı Karar Noktası BRDP-S1-00016– Gizlilik sınıflandırmasının gösterimi''':

* Gizlilik sınıflandırmasının nasıl markalanıp, gösterileceğine karar ver.

=== 3.7.5. KATEGORİ 5- İŞ SÜREÇLERİ ===
İş süreçleri kategorisi, kurumlar içerisinde veya projede çalışan firmalar/kurumlar içerisinde S2000M uyumlu tedarik süreçlerinde ve LDA, tasarım/mühendislik, eğitim vb. faaliyetlerde görev alan farklı disiplinler ile teknik yayın süreçleri arasındaki ilişkilerin tanımlandığı iş kurallarını kapsamaktadır.

Kalite kontrol süreçleri ve bu süreçlerin projede bilgi üreten, üretilen bu bilgiyi kullanarak CSDB nesneleri hazırlayan, hazırlanan CSDB nesnelerini gözden geçiren/onaylayan, CSDB nesnelerini kullanarak nihai dokümanları oluşturan vb. faaliyetlerde bulunan kurum veya kişilerle olan etkileşimini tanımlayan kuralların da bu kategori altında ele alınması gerekmektedir.

Ayrıca üretilecek içeriklerin hem eğitim dokümanlarında hem de bakım ve kullanıcı dokümanlarında kullanılması gereken projelerde hem eğitim ekibinin hem de teknik yayın ekibinin ihtiyaçlarını karşılayacak nitelikteki içeriklerin nasıl üretileceği ile ilgili kararlar da bu kategori altında ele alınmalıdır.

Ayrıca oluşturulan bir içeriğin birden fazla alanda (eğitim, bakım ve kullanıcı dokümanları vb.) kullanılması gereken projelerde, hazırlanacak içeriklerin veya başka bir projede hazırlanmış ve ilgili projede de kullanılabilecek içeriklerin tekrar kullanılabilirliğinin en üst düzeyde olmasını sağlayacak süreçlerin tanımlandığı iş kuralları da belirlenmelidir.

Aşağıdaki amaçlara ulaşılabilmesi için söz konusu kuralların belirlenmesinde veri modül kodlama stratejisinin de göz önünde bulundurulması gerekmektedir:

* Veri modüllerinin eğitim dokümanlarında ve bakım dokümanlarında tekrar kullanılabilirliğini en uygun şekilde sağlayabilecek şekilde modüler içerikler hazırlanması,
* Etkileşimli çoklu ortam ve simülasyonlarda kullanılabilir özellikte bakım, kullanım ve eğitim içeriklerinin geliştirilmesi,
* Veri modül kodu ve/veya yayın modülü kodu ve eğitim içeriğinin kaydı gereksinimleri arasındaki ilişkinin kurulması

İş süreçleri kategorisi aşağıdaki kuralları içermekle beraber bunlarla sınırlı değildir:

* Diğer disiplinlerin teknik yayınlara ne tür girdiler yaptığı ve bunun sonucunda teknik yayınlarda ne tür çıktılar elde edildiğinin tanımlanması,
* Alt yüklenicilerden teslimat kalemlerine yapılacak girdilerin proje hiyerarşisine göre sıraya sokulması,
* Üretici, alt yüklenici ve müşteri arasında mutabakata varılmış iş süreçlerinin oluşturulması,
* Kalite kontrol süreçleri içindeki onay kriterlerinin projede taraf olan tüm kurumların birbirleri olan etkileşiminin göz önünde bulundurularak belirlenmesi,
* Tekrar kullanılabilirlik ve birlikte kullanılabilirliğin planlanması.

Aşağıdaki karar noktası, bu kategoriye örnek teşkil etmektedir:

'''İş Kuralı Karar Noktası BRDP-S1-00268– Eğitim hedefleri''':

* Görev analizi maddelerine uygun öğrenme hedefleri geliştirip geliştirmemeye karar ver.

=== 3.7.6. KATEGORİ 6- VERİLERİN OLUŞTURULMASI ===
Verilerin oluşturulması kategorisi metinsel içeriklerin, görsel öğelerin ve çoklu ortam nesnelerinin oluşturulması hakkında bilgi veren iş kurallarını kapsamaktadır.

Bu karar kategorisi içeriği itibari ile iki farklı alt kategoriye ayrılmıştır. Bu kategoriler:

* Kategori 6a-Metinsel Verilerin Oluşturulması,
* Kategori 6b-Görsel Nesnelerin ve Çoklu ortam Nesnelerinin Oluşturulması.

==== <big>3.7.6.1. KATEGORİ 6A- METİNSEL VERİLERİN OLUŞTURULMASI</big> ====
Metinsel verilerin oluşturulması ile ilgili iş kuralları, teknik yayınlardaki içeriklerin tekrar kullanılabilirliğini en üst düzeye çıkartan kural ve kılavuzlar içermektedir. Tekrar kullanılabilirlik, bir teknik dokümanı oluşturan içeriklerin aynı doküman içerisinde tekrar kullanımı ile sağlanabileceği gibi farklı teknik dokümanlar ve eğitim içeriklerinde kullanılabilmesi ile de sağlanabilmektedir.

Bu kurallar, teknik içeriklerin ve eğitim içeriklerinin nasıl geliştirilmesi gerektiği ile ilgili bilgiler sağlamaktadır. Bu kategori örnek olarak; sözlük kullanımı, sayıların nasıl gösterilmesi gerektiği, yazarların teknik terimlere nasıl referans vermesi gerektiği, çoklu ortam öğelerinin bakım, kullanım ve eğitim içeriklerini desteklemekte nasıl kullanılması gerektiğini ve bir terminoloji veri tabanının nasıl oluşturulması ve kullanılması gerektiği vb. konularla ilgili kararları içerir.

İşaretleme (XML Etiketleme) iş kuralları, şemalarda yer alan elemanların ve niteliklerin nasıl kullanılması gerektiği ile ilgili bilgi sağlamaktadır.

Metinsel verilerin oluşturulması kategorisi aşağıdaki kuralları içermekle beraber bunlarla sınırlı değildir:

* Yazım kuralları (terminoloji kuralları, sözlük kullanımları, sayıların kullanımı ile ilgili kurallar vb.),
* Biçimlendirme kuralları,
* Çoklu ortam ve görsel öğelerin metinsel anlatımlarla ilişkilendirilme ihtiyacı.

Aşağıdaki karar noktası, bu kategoriye örnek teşkil etmektedir:

'''İş Kuralı Karar Noktası BRDP-S1-00026– Metin vurgusu''':

* Metinlerin vurgulanması için hangi metodun kullanılacağına karar ver.

==== <big>3.7.6.2. KATEGORİ 6B- GÖRSEL NESNELERİN VE ÇOKLU ORTAM NESNELERİNİN OLUŞTURULMASI</big> ====
Bu bölüm, görsel nesnelerin ve çoklu ortam nesnelerinin oluşturulması ile ilgili iş kurallarını kapsamaktadır. Bu kurallar biçim, detay ve veri formatı olarak üçe ayrılır.

Biçimlerle ilgili kurallar; görselin boyutları, renk kullanımı, çizgi kalınlıkları, yazı fontları, projeksiyon yöntemleri (izometrik veya trimetrik) gibi görsel nesnelerin ve çoklu ortam nesnelerinin karakteristik özelliklerini belirlemekte kullanılmaktadır.

Görsel nesneler üzerinde aktif nokta (hot spot) kullanımı da bu kategorinin altında yer almaktadır.

Veri formatı ile ilgili kurallar, görsel öğelerin hangi formatlarda üretilmesi, depolanması ve görüntülenmesi gerektiğini tanımlamaktadır. Bu kararlar eleman ve nitelik kullanımları üzerinde etkisi olabilmektedir. Ayrıca biçim ve veri formatı ile ilgili kararları birbirinden ayrı ele almak çoğu zaman mümkün olmamaktadır.

Görsel nesnelerin ve çoklu ortam nesnelerinin oluşturulması kategorisi aşağıdaki kuralları içermekle beraber bunlarla sınırlı değildir:

* Grafik biçimi ile ilgili kurallar,
* Etkileşim ile ilgili kurallar,
* Çoklu ortam formatları,
* Metinsel anlatımlarla nesneler arasında bağlantı (link) oluşturulması.

Aşağıdaki karar noktası, bu kategoriye örnek teşkil etmektedir:

'''İş Kuralı Karar Noktası BRDP-S1-00129– Multimedya kullanımı''':

* Multimedya kullanılıp kullanılmayacağına karar ver.

=== 3.7.7. KATEGORİ 7- VERİ TRANSFERİ ===
Projede çalışan firmaların kendi aralarında ve müşterileriyle yaptıkları veri transferi işlemleriyle ilgili olan iş kuralları veri transferi kategorisi altında yer almaktadır. Veri Gönderme Notu (DDN), Veri Model İhtiyaç Listesi (DMRL) ve CSDB Statü Listesi (CSL) yapılarının kullanımı ile ilgili kurallar bu kategorinin altında bulunan iş kurallarına örnek olarak verilebilir. Ayrıca S1000D’de tarif edilen dosya tabanlı transfer protokolünün nasıl kullanılacağı, veri transferlerinin ne sıklıkla yapılacağı, transfer edilen verilerin arasında kalite kontrol süreçlerinden geçmemiş olanların versiyon numaralarının nasıl tanımlanacağı ve kabul/red kriterlerinin neler olacağı ile ilgili iş kuralları da bu kategorinin altında yer almaktadır.

Veri transferi kategorisi aşağıdaki kuralları içermekle beraber bunlarla sınırlı değildir:

* Veri Gönderme Notu (DDN) kullanımı ile ilgili kurallar,
* Veri Model İhtiyaç Listesi (DMRL) kullanımı ile ilgili kurallar,
* CSDB Statü Listesi (CSL) kullanımı ile ilgili kurallar,
* Dosya tabanlı transfer protokolünün kullanım şekli ile ilgili kurallar,
* Veri transfer sıklığının belirlenmesi,
* Veri modülü versiyonları ile ilgili kurallar,
* Bilgi Kontrol Numarası (ICN) numarası ile kodlandırılan verilerle ilgili kurallar,
* Kabul/red kriterlerinin belirlenmesi.

Aşağıdaki karar noktası, bu kategoriye örnek teşkil etmektedir:

'''İş Kuralı Karar Noktası BRDP-S1-00009 – Veri transferi sıklığı''':

* Veri transferi sıklığına karar ver.

=== 3.7.8. KATEGORİ 8- VERİ BÜTÜNLÜĞÜ VE YÖNETİMİ ===
Veri bütünlüğü ve yönetimi kategorisi, CSDB içindeki veri tutarlılığının sağlanması ile ilgili iş kurallarını kapsamaktadır. Bu kategori, veri yönetiminin müşteri ve verileri hazırlayan tarafların her ikisinde de sağlıklı olarak sağlanabilmesi açısından veri transferi kategorisi ile yakın bir ilişki içindedir.

İhtiyaç olması halinde, tedarikçilerin S1000D uyumlu veri üretmediği durumlarda ilgili verilerin teslimi ve kabulü ile ilgili süreçlerin tanımlandığı iş kuralları da bu kategoride ele alınabilir.

İş akışları ve kalite kontrol ile ilgili iş kuralları da bu veri bütünlüğü ve yönetimi kategorisinin kapsamındadır. Bu kurallar da veri transferi kategorisi ile bağlantılıdır.

Veri bütünlüğü ve yönetimi kategorisi aşağıdaki kuralları içermekle beraber bunlarla sınırlı değildir:

* İş akışı ile ilgili kurallar (Hem firma içi hem de projede birlikte çalışan tüm taraflar arasındaki),
* Kalite kontrol ile ilgili kurallar.

Aşağıdaki karar noktası, bu kategoriye örnek teşkil etmektedir:

'''İş Kuralı Karar Noktası BRDP-S1-00017– Kalite kontrol kuralları''':

* Veri modülü ve teslimatlarla ilgili kalite control süreçlerini belirle.

=== 3.7.9. KATEGORİ 9- MEVCUT VERİLERİN YÖNETİMİ VE KULLANIMI ===
Mevcut veri kavramı, içerik olarak güncelliğini ve geçerliliğini koruyan ancak format ve yapı itibari ile S1000D uyumlu olmayan (kağıt baskı, S1000D’den farklı diğer formatlar vb.) verileri tanımlamaktadır.

Mevcut verilerin S1000D’de istenen formata dönüştürülmesi ve yönetilmesi ile ilgili iş kuralları, belli bir ölçüde S1000D’nin kapsamının dışında kaldığı için spesifikasyonda yer alan diğer iş kurallarından ayrılmaktadır. Bunun sebebi, mevcut verilerin formatının ve bu mevcut verilere S1000D uyumlu bir yapı kazandırılmasının firmadan firmaya ve projeden projeye değişiklik gösterecek olmasıdır.

Mevcut verilerin yönetimi ve kullanımı kategorisi aşağıdaki kuralları içermekle beraber bunlarla sınırlı değildir:

* Mevcut verilerin S1000D uyumlu hale dönüştürülmesi ile ilgili kurallar (bu kuralların içine, kaynak veri ile dönüştürüleceği S1000D formatı arasındaki eleman ve nitelik eşleştirmelerinin nasıl yapılacağı da girmektedir.).
* Mevcut verilerin teknik yayınlarda kullanım şekli ile ilgili kurallar.

Aşağıdaki karar noktası, bu kategoriye örnek teşkil etmektedir:

'''İş Kuralı Karar Noktası BRDP-S1-00542– IETM’de mevcut verilerin kullanım metodu''':

* Mevcut bilgiler için bunları IETM’de veri modülü içinde mi kapsanacağı yoksa referans mı verileceğini belirle.

=== 3.7.10. KATEGORİ 10- ÇIKTI YAPISI VE FORMATI ===
Bu kategori, S1000D verilerinin çıktı yapısı ve formatının (sayfa formatları, IETP formatları, çoklu ortam formatları, SCORM formatları, vb.) tanımlandığı iş kurallarını kapsamaktadır. Üretilen verilerin hangi kısımlarının hangi formatta yayınlanacağı konusunda taraflar arasında alınan kararlar bu kategoride belirtilmelidir.

Şemalarda kullanılan eleman ve niteliklerin, nihai çıktıda nasıl görüntüleneceği (biçim, font, renk, metinler arasındaki boşluklar vb.) ile ilgili detaylı açıklamalar bu kategoride tanımlanmalıdır. Bu kategori, verilerin oluşturulması kategorisi ile (özellikle metinsel verilerin oluşturulması – kategori 6a) oldukça yakın bir ilişki içindedir. Örnek vermek gerekirse; yazarlar hangi elemana bir metin yazdıkları zaman dokümanın nihai görüntüsünde bu metinlerin belireceğini bilirlerse tekrarlı veya hatalı iş yapılmasının önüne geçilmiş olacaktır.

Projede ihtiyaç duyulması halinde, S1000D’de önerildiği üzere fonksiyonellik matrisi oluşturulabilir. Projede alınan kararlar çerçevesinde fonksiyonellik matrisinin kullanılması, çıktı yapısı ve formatı üzerinde doğrudan etkili olacaktır.

Çıktı yapısı ve formatı kategorisi aşağıdaki kuralları içermekle beraber bunlarla sınırlı değildir:

* Üretilen verilerin hangi kısımlarının sayfa formatında hangilerinin IETP formatında yayınlanacağı,
* Sayfa formatı ve IETP formatının ekran görüntüsünün özellikleri,
* Hangi veri modüllerinin SCORM formatında yayınlanacağı,
* Hangi veri modüllerinin simülasyon formatında yayınlanacağı,
* Görünüm ve his ile ilgili kurallar.

Aşağıdaki karar noktası, bu kategoriye örnek teşkil etmektedir:

'''İş Kuralı Karar Noktası BRDP-S1-00304 – İçindekiler bilgisinin seviyelendirilmesi''':

* Seviyelendirimiş içerik bilgisinin kullanılmasına ve kaç seviyeye kadar inileceğine karar ver.

== 3.8. KARAR KATMANLARI ==
İş kuralı karar katmanı, belirlenen iş kurallarının proje paydaşları arasındaki hiyerarşisine göre seviyelendirilmiş halidir.

Katmanlı iş kuralı modelinde, bir alt katman kendisinin bir üst katmanında bulunan paydaşın belirlediği iş kurallarını doğrudan uygulamak zorundadır. Kesin bir tanımlama yapılmaması durumunda, kapsamını genişletebilir veya tamamen kendisi belirleyebilir.

Katmanlı yapı, aşağıdaki şekilde de belirtiği gibi projenin kapsamı ve kurumların yapısına göre Katman 2’den N’ye kadar arttırılabilir. Ancak katmanlı yapının ilk katmanı her zaman S1000D olmak zorundadır. Bu yapının genel işleyişinde alt katmanlara inildikçe iş kurallarının sayısında artış, belirlenmemiş iş kurallarının sayısında ise azalma meydana gelir. Bunun sebebi üst katmanlarda alınan kararların, alt katmanlar tarafından direkt uygulanacak olmasıdır. Bu nedenle alt katmanlara inildikçe yanıtlanması gereken iş kuralları, üst katmanın kendisiyle ilgili herhangi bir tanım ortaya koymadığı kurallarla sınırlı kalacaktır. Karar alıcıların hedefi, yazarların insiyatifine olabildiğince az karara bağlanmamış iş kuralı bırakmak olmalıdır.
[[Dosya:Şekil6 Katmanlı Yapı.jpg|alt=Şekil 6 Katmanlı Yapı|sol|küçükresim|378x378pik|Şekil 6 Katmanlı Yapı]]

Katmanlı yapıya bir örnek aşağıda sunulmuştur.
[[Dosya:Şekil7 Örnek Katmanlı Yapı.jpg|alt=Şekil 7 Örnek Katmanlı Yapı|sol|küçükresim|400x400pik|Şekil 7 Örnek Katmanlı Yapı]]

Proje paydaşları, kendi karar katmanlarında ihtiyaç duyulması halinde kendi iş kuralı karar noktalarını oluşturabilirler.

Her bir karar noktası (paydaşların kendi katmanlarında oluşturdukları da dahil olmak üzere) tüm paydaşlar tarafından değerlendirilmelidir.

İş Kuralları Arasındaki Uyumsuzlukların Çözülmesi

Yukarıda bahsedildiği gibi alt karar katmanı, üst karar katmanının aldığı kararlara uymak zorundadır. Bu durum, proje kapsamında üretilen teknik verilerin farklı müşterilere teslim edileceği hallerde çeşitli sorunlar yaratacaktır. İki farklı müşterinin iş kuralları arasındaki uyumsuzluk nedeniyle üretici firma hazırladığı teknik verileri her iki müşteri için ayrı ayrı hazırlamak ya da içerik filtresi kullanmak zorunda kalabilir.

Çok uluslu savunma projelerinde, her ulusun kendi iş kuralları bulunabilir. Bu durumda, teknik içeriklerin farklı iş kurallarına göre tekrar yazılmasını gerektirebilir. Aynı içeriğin iki farklı şekilde oluşturulması içeriklerin yönetilmesinde çeşitli sorunlar (bir içerik güncellenirken diğerinin güncellenmemesi, veri transferlerinde yanlış gönderiler yapılması vb.) yaşanmasına neden olacaktır. Bunu önlemek ya da sorunu en aza indirgemek için ulusların iş kurallarını ilgili proje için bir arada değerlendirip ortak bir noktada buluşturması önerilmektedir.

Benzer problemler farklı müşterilerle çalışan üreticilerin başına sıklıkla gelebilir. Örnek vermek gerekirse, ürettiği ürün hem sivil hem de askeri projelerde kullanılabilen bir üretici, iki müşterinin iş kuralları arasındaki uyuşmazlıklardan dolayı teknik verilerin her müşteri için ayrı ayrı veri hazırlamak zorunda kalabilir. Bu durumu önlemek için üretici firma, müşterileri ile iş kuralları konusunda mutabakat sağlamalıdır.

Ayrıca iş kuralları arasında farklılık bulunan proje paydaşlarının dokümantasyon süreçlerine başlamadan önce iş kuralları konusunda mutabakat sağlamaları, tekrarlı ve/veya hatalı iş yapılmasının önüne geçecektir.

Verilerin farklı iş kuralları nedeniyle tekrar tekrar yazılması, veri yönetimini içinden çıkılmaz bir duruma sokabilir. Bu nedenle herhangi bir katmanda iş kurallarının belirlenmesi konusunda görev alan kişilerin hem üreticilerin daha önce hazırlamış olduğu teknik verilerin tekrar kullanılabilirliğini sağlayıcı yönde, hem de proje ihtiyaçlarını karşılayacak şekilde optimum bir çözüm üretmesi gerekmektedir.

S1000D, verilerin tekrar tekrar hazırlanmasını önlemek açısından, özellikle RAHAT ürünlerin S1000D’de hazırlanmış teknik içeriklerini olduğu gibi kullanmayı tavsiye etmektedir.

Her üst katman belirlediği iş kuralları konusunda alt katmanları bilgilendirmelidir. Örnek vermek gerekirse; bir kurum, belirlediği kurumsal kararlar varsa projelerde çalışan firmaları aldığı bu kararlar konusunda bilgilendirmek zorundadır.

Projelerde belirlenen iş kuralları arasında; yukarıda verilen örneklere benzer çelişki yaratan durumların ortaya çıkması halinde, proje paydaşlarının tamamı ilgili sorunun çözüme ulaştırılmasında eşit derecede sorumluluk sahibidir. Sonuç olarak yaşanan çelişkilerin çözüme ulaştırılması aşağıdaki yöntemlerle sağlanabilir:

* Çelişki yaratan iş kurallarının koordineli bir çalışmayla hem müşterinin hem de üreticilerin ihtiyaç ve yaşayacağı sorunlar göz önünde bulundurularak değiştirilmesi veya bu kurallardan feragat edilmesi,
* Veri modüllerinin her proje için iş kurallarına göre baştan hazırlanması

== 3.9. PROJE KARARLARININ BELİRLENMESİ ==
İş kurallarının belirlenmesi, yaşayan bir süreçtir ve proje tamamlanana kadar devam edebilir. Belirlenen kuralların proje süresince yaşanan sorunlar/aksaklıklar, teknolojinin gelişmesi, bir takım yeni ihtiyaçların ortaya çıkması vb. sebeplerden ötürü değiştirilmesi gerekebilir. Ayrıca iş kurallarının tam olarak nasıl bir sırayla ve ne zaman belirleneceği o projenin kapsamına ve ihtiyaçlarına, dokümantasyon faaliyetlerinde bulunacak kurumların iş süreçlerine doğrudan bağlıdır. Bu ve benzer nedenlerden dolayı; hazırlanan bu rehber dokümanda, iş kurallarının belirlenmesi sürecinde, iş kuralı kategorilerinin belirlenme sırasıyla ilgili genel bir tablo ortaya konacaktır.
[[Dosya:Şekil8 İş Kuralı Kategorilerinin Belirlenmesi.jpg|alt=Şekil 8 İş Kuralı Kategorilerinin Belirlenmesi|sol|küçükresim|700x700pik|Şekil 8 İş Kuralı Kategorilerinin Belirlenmesi]]

Şekil 8 dokümantasyon süreçlerinden bağımsız olarak iş kurallarının ne tür bir zaman planı çerçevesinde tanımlandığını genel hatlarıyla ortaya koymaktadır. Başarılı bir dokümantasyon planı açısından iş kurallarının tanımlanmasına, sözleşme ve içerik geliştirme süreçlerinden önce başlanması tavsiye edilmektedir. Ancak S1000D uygulamalarının geneline bakıldığında, S1000D’nin uyumluluk için zorunlu tuttuğu ana kriterleri sağlayacak karar noktalarının belirlendiği, kalan kararların ise proje zaman planına yayılarak belirlendiği gözlemlenmektedir.

İş kurallarının tanımlanmasında ve uygulanmasında başarılı bir sonucun elde edilebilmesi için iş kurallarının hangi sırayla veya hangi zamanda tanımlandığından daha çok, bu tanımlama süresince kurumlar ve proje paydaşları arasındaki iletişimin ne kadar kuvvetli olduğu ön plana çıkmaktadır. Kararların mutabakat çerçevesinde alınması, herkesin belirlenen kurallardan aynı anlamı çıkartması, alınan bir kararın uygulamasında görülen zorluğun tüm tarafların ortak çalışmasıyla o karar noktası üzerindeki sorunları gidermesi projenin başarısı üstünde çok daha büyük bir etkiye sahiptir.

== 3.10. BREX VERİ MODÜLÜ ==
BREX veri modülü, S1000D’nin şemalarından birisi olan BREX şeması ile hazırlanır. Proje faaliyetleri içerisinde hazırlanan BREX veri modülü de tıpkı diğer veriler (veri modüleri, görsel nesneler, vb.) gibi bir CSDB nesnesidir.

Bu şemanın amacı; belirlenen iş kurallarının belirli bir formata göre standart bir şekilde dokümante edilmesini, proje kapsamında hazırlanacak olan veri modüllerinin hangi iş kurallarına göre yazıldığının tanımlanabilmesini ve denetlenebilmesini sağlamaktır.

İş kurallarını BREX şemasını kullanarak dokümante ederken yanlış anlaşılmaya mahal vermeyecek, net ve herkes tarafından aynı anlama gelecek açıklamalar kullanmak, iş kurallarının uygulanmasında yanlış anlaşılmalardan kaynaklanabilecek hataların ortaya çıkmasının da önüne geçmiş olur.

Aşağıda BREX veri modülünün kullanımı ile ilgili çeşitli örnekler belirtilmiştir:

* BREX veri modülü, projeye özgü veya kuruma ait iş kurallarının, kurumlar ve/veya proje paydaşları arasında paylaşılabilmesini sağlamakta kullanılabilir.
* S1000D’nin bazı seçenekli niteliklerinin kullanımında seçilen değerlerin doğru yorumlanabilmesini destekler. Örnek vermek gerekirse “gizlilik sınıflandırması” niteliğinin alabileceği değerler 01, 02, 03, …, 99 olabilmektedir. Bu değerlerin ne anlama geleceği BREX içinde tanımlanabilir. Bu sayede proje paydaşları “gizlilik sınıflandırması” niteliğinin aldığı değerlerin ne anlama geldiğini bilir.
* Hazırlanan CSDB nesnelerinin projenin ve/veya kurumun iş kurallarına uygun olarak hazırlanıp hazırlanmadığını kontrol etmekte kullanılabilir. Bu yöntemin uygulanma biçimi, kullanılan yazılımlara göre değişiklik gösterebilir.

Bir kurum veya proje ekibi, S1000D’de yer alan tüm yapıların (SNS yapıları, bilgi kümeleri, sayfa formatı vb.) olduğu gibi uygulanmasına karar verirse, varsayılan BREX veri modülünü uygulayabilir. Ancak kurumların iş kuralları ve/veya proje paydaşlarının proje kapsamında uygulanmak üzere kurumsal olarak tanımladıkları iş kuralları varsa, bu kuralların dokümante edilebilmesi için BREX veri modülü hazırlanmalıdır.

== 3.11. İŞ KURALLARI DOKÜMANI NEDİR? ==
İş Kuralları dokümanı, BREX veri modülünden farklı bir dokümandır. BREX veri modülü içerisinde; alınan kararların detaylarına, kararlarla ilgili örneklere ve çeşitli destekleyici materyallerin (görsel nesneler, vb.) kullanılmasına yer verilecek yeterlilikte alan bulunmamaktadır. Bu nedenle iş kurallarının ayrıca dokümante edilmesi, tanımlanan iş kurallarının projelerde uygulanabilmesi açısından bir gerekliliktir.

= 4. TEKNİK YAYIN HAZIRLAMA UYARLAMASI =

== 4.1. TEKNİK YAYIN SÜREÇ VE STANDARTLARININ UYARLANMASI ==
Projelerin Teknik Yayın ihtiyaçları; projenin tipi, tedarik yöntemi, ürün, teknik yayın tipi, kullanıcı gereksinimleri, proje takvimi, proje bütçesi vb. değişkenler nedeniyle farklılık gösterebilecektir. Bu sebeple projelerin sözleşme aşamasında, bu rehber dokümanda belirtilen yöntem ve gereksinimlerden hangilerinin hangi detayda ve gerekiyorsa hangi standart esas alınarak uygulanacağı, kullanıcı ihtiyaçları ve maliyet arasındaki optimum denge gözetilerek belirlenmelidir. Belirlenen gereksinimler ilgili projenin iş kuralları olarak Teknik Yayın Planında detaylı şekilde tariflenmeli ve Teknik Yayın hazırlama sürecinde uygulanmalıdır.

Projeler kapsamında hazırlanan Teknik Yayınlarda kurumsal standardizasyonların sağlanabilmesi için; genel yazım kurallarına ilişkin standartlar, teknik yayın tipleri ve bunlara göre ilgili kurumlarca hazırlanacak kurum içi yönergelerde belirtilmeli ve söz konusu standartlar, İş Kuralları olarak sözleşmelerin Doküman Veri İstek Listeleri kısımlarına ek olarak konulmalıdır.

Bununla birlikte projenin değişkenlerine göre Teknik Yayın Gereksinim Planlama Süreçlerinde göz önünde bulundurulması gerekli durumlardan bazıları aşağıda belirtilmiştir:

'''a. RAfta HAzır Ticari (RAHAT) Ürün Alım Projeleri Teknik Yayınları:'''

Proje kapsamında tedarik edilen RAHAT ürünlere ait teknik yayınlarda; bu ürünlerin üreticileri tarafından hazırlanmış olan teknik yayınlar şayet ilgili ürünün kullanımı ve bakımı ile ilgili yeterli bilgiyi içeriyorsa olduğu gibi kullanımı veya bazı sınırlı ilavelerle yeterli duruma getirilmesi uygun olacaktır. Ancak mevcut üretici teknik yayınlarında daha kapsamlı revizyon ihtiyacı olan durumlarda, ürünün üreticisi tarafından bunların yeniden yazılması seçeneği değerlendirilmelidir.

'''b. AR-GE/MÜ-GE Projeleri Teknik Yayınları:'''

Yeni ürün tasarım ve geliştirme projeleri kapsamındaki ürünlere yönelik olarak; teknik yayınların uygun şekilde oluşturulabilmesi için gerekli LDA süreçleri işletilerek işletme ve idame için gerekli bilgi ve verilerin toplanması/oluşturulması sağlanmalıdır. Bu tip projelerde orijinal malzeme üreticilerinden gerekli bilgiler (sökme-takma talimatları vb.) alınmalıdır. İhtiyaç duyulacak bakım onarım teknik verileri ve teknik yayınları ile ikmal desteğine ilişkin katalog ve liste gereksinimleri, İhtiyaç Makamlarının bakım kademeleri ve proje lojistik destek konsepti dikkate alınarak belirlenmelidir.

'''c. Hazır Alım Projeleri Teknik Yayınları:'''

Hazır Alımı yapılan projelerin Teknik Yayınlarının baştan geliştirilmesi oldukça yüksek bir maliyet gerektireceği ve LDA süreçlerinin çoğunun tamamlandığı bir dönemde icra edildiğinden, Üretici veya Yüklenicinin yeni bir veri seti üretmesi beklenmemeli ancak üretilmiş olan verilerin düzenlemesi ve sunumuna yönelik ihtiyaçların karşılanması hedeflenmelidir.

Sistem üreticileri açısından farklı proje tipleri, ürünler ve müşteriler için ortaya çıkan farklılıkları kolaylıkla yönetebilmenin yöntemi, teknik yayın veri tabanları ile verinin oluşturularak istenilen çıktı içeriği ve formatına hızlıca uyarlanmasını sağlamaktır.

== 4.2. BASILI TEKNİK YAYIN İLE ETKİLEŞİMLİ ELEKTRONİK TEKNİK YAYIN (IETM/P) HAZIRLAMA ARASINDAKİ FARKLAR ==
Bu rehber dokümanının önceki bölümlerinde bahsedildiği üzere teknik yayın hazırlama süreçlerinin temel adımları benzer olmakla birlikte, sürecin ana çıktısı olan teknik yayının basılı kopya formatında hazırlanması ile Etkileşimli Elektronik Teknik Yayın (IETM/P) olarak hazırlanması farklı süreç adımları ve altyapı gereksinimlerine sahiptir. Söz konusu farklılıklar ve gereksinimler aşağıda özet olarak belirtilmiştir:

'''a. Basılı Teknik Yayın Hazırlama Süreçleri ve Uygulamaları:'''

Basılı teknik yayınlar; sistem ve ürünlere ilişkin teknik veri ve bilgilerin kullanıcı ihtiyaçları doğrultunda yapılan sınıflandırmaya göre ayrı el kitapları, kataloglar ve listeler şeklinde kağıt ortamında basılı hale getirilerek, sayfa bazlı olarak okuyucuya sunulduğu yayınlardır. Basılı yayınlar, hazırlanan teknik yayın planları doğrultusunda ayrı kitap, cilt, fasikül, bölüm, kısımlar olarak belirlenen yazım kural ve şablonları kullanılarak, genellikle kelime işleme yazılımları vasıtasıyla elektronik ortamda oluşturulmakta, renkli veya renksiz şekillerde basılı hale getirilmektedir.

'''b. Etkileşimli Elektronik Teknik Yayın (IETM/P) Hazırlama Süreçleri ve Uygulamaları:'''

Teknik yayınlar doğrudan kağıt medya üzerinde basılı olarak hazırlanabileceği gibi elektronik ortamlarda da hazırlanabilmektedir. Elektronik ortamda hazırlanan teknik yayınlar Elektronik Teknik Yayın (ETM) olarak isimlendirilmektedir.

Etkileşimli Elektronik Teknik Yayın (IETM/P), ürünlerin tanımlayıcı bilgileri, kullanım ve bakım onarımına yönelik olarak son kullanıcıya elektronik görüntüleme araçları (monitör, dizüstü bilgisayar, tablet vb.) aracılığı ile etkileşimli ekran sunumu şeklinde aktarılmak üzere editör yazılım araçları kullanılarak elektronik ortamda “hazırlanan” veya “yazılan” bilgi kümelerinden oluşan teknik yayınlardır.

IETM aşağıdaki temel özelliklere sahiptir:

* Bilginin formatı ve biçimi, ekran üzerinde görüntü bazlı olarak (sayfa bazlı değil) gösterilirken azami ölçüde kavranabilirliği sağlayacak şekilde ayarlanır.
* Teknik Yayınları oluşturan teknik bilgi bileşenleri arasındaki ilişkinin yapısı kullanıcın ihtiyaç duyduğu bilgiye farklı yollardan erişimi için geniş olanaklar sağlar.
* Bilgisayarlar, dizüstü bilgisayarlar ve tablet gibi görüntüleme araçları; ihtiyaç duyulan prosedür adımlarının, yönlendirme talimatlarının ve ilave bilgilerin etkileşimli olarak aktarılmasını sağlarlar.
* Ekran üzerindeki sunumlar; ilişkisel veri tabanında metin, grafik, ses ve/veya video şeklinde depolanan materyallerin mantıksal olarak ilişkilendirilmesi ile oluşturulan ve rasgele erişilebilir IETM veri bileşenlerini içerebilmektedir.
* IETM, kullanıcı geri bildirimlerine göre oluşturulabilen koşullu dallandırma mekanizmalarına sahiptir. Değişkenler kullanım sırasında değerlendirilir ve değerleri içeriğe ve kullanıcı girdilerine bağlıdır.

ETM’ler özelliklerine ve kabiliyetlerine göre 6 sınıfa ayrılmaktadır. Sınıf 0’a giren teknik yayınlar; herhangi bir etkileşimli özelliğe sahip olmamalarından ötürü yalnızca ETM olarak tanımlanmakta, diğer sınıflara giren teknik yayınlar ise etkileşimli özelliklere de sahip olduklarından Etkileşimli Elektronik Teknik Yayın (IETM) olarak tanımlanmaktadır. Teknik yayın sınıfları ile ilgili açıklamalar aşağıda yer almaktadır:

'''Sınıf 0 – İndekslenmeden Taranan ETM’ler:''' Bu sınıfa giren ETM’ler, basılı dokümanların hücresel (raster) görsel olarak tarandığı ve elektronik ortama aktarıldığı dokümanlardır. Ancak bu dokümanları oluşturan taranmış sayfalar indekslenmemektedir. Bu tip dokümanlarda mükerrer bilgiler olabilmektedir. Bu durum aynı bilgileri tekrar yazmak için emek sarfiyatı gerektirdiğinden istenen bir durum değildir.

'''Sınıf I – İndekslenerek Taranan IETM’ler:''' Bu sınıfa giren IETM’ler, basılı dokümanların hücresel (raster) görsel olarak tarandığı ve elektronik ortama aktarıldığı dokümanlardır.

Sınıf-I (Sayfa Görüntüsü Görüntüleme Sistemleri) teknik yayın sistemlerinde kullanılan görüntü saklama ve görüntüleme teknolojisi bir belgenin tam sayfa kodlamasını kullanır (örneğin, Postscript sayfa açıklama dili). Bu sınıfın elektronik-ekran versiyonu, kullanıcının akıllı bir dizin kullanarak sayfa çevirme ve sınırlı arama özelliğine sahip bir ekranda tam sayfa görüntüyü görüntülediği versiyondur. Bu sistemler, verinin sayfa bütünlüğünü değiştirmeksizin mümkün olduğunca etkileşimli özelliklere sahiptir. Sınıf-I teknik yayın sistemleriyle ele alınan basit teknik yayınlar, elektronik ekran için yazılmamıştır.

Bu dokümanların kapak sayfası otomatik olarak oluşturulmaktadır. Kapak sayfasında bulunan linkler aracılığı ile taranmış sayfalara erişim mümkündür. Bu tip dokümanlarda mükerrer bilgiler olabilmektedir.

Sınıf-I teknik yayınlar basılı yayınların aşırı alan kaplama, ağırlık gereksinimleri ile baskı kağıdı ve sayfa değişim güncellemeleriyle doküman idamesi sorunlarının önlenmesini sağlayan görece olarak düşük maliyetle oluşturulabilen teknik yayınlardır.

'''Sınıf II – Aşağı ve Yukarı Yönlü Kaydırılabilen IETM’ler:''' Bu sınıfa giren IETM’ler, fonksiyonel özelliklerin Sınıf 0 ve Sınıf I’e giren teknik yayınlara göre artış gösterdiği, metinlerin resim olarak tutulmayıp bilgisayar dili ile kodlandırıldığı dokümanlardır.

Sınıf-II (Sayfa Odaklı Teknik Yayınların Köprü Metni Görünümü.) teknik yayın sistemleri, mevcut sayfa odaklı teknik yayınların elektronik geri alma ve görüntüleme kapasitesine uyarlamak için özel olarak tasarlanmış sistemlerdir. Bu uygulamaların birçoğunda, mevcut sayfa görüntüleri çeşitli şekillerde sayısallaştırılır, dizin oluşturma ve çapraz referanslama bilgileri mümkün olan en iyi şekilde eklenir. Bu dokümanların kapak sayfası otomatik olarak oluşturulabilmektedir. Kapak sayfasında bulunan linkler aracılığı ile doküman içeriklerine erişim sağlanabilmektedir. Hatta metinler arasında da linkler oluşturulabilmektedir. Bu dokümanlarda Sınıf 0 ve Sınıf I’de olmayan bir diğer özellik ise doküman içeriği üzerinde çeşitli değişiklikler yapılabiliyor olmasıdır. Adobe firmasının geliştirmiş olduğu dosya formatı olan PDF, Sınıf II IETM’lerin sahip oluğu özellikleri taşımaktadır. Bu tip dokümanlarda mükerrer bilgiler olabilmektedir.

Sınıf-II teknik yayınlar, mevcut teknik yayınların gereksinimlerine göre geleneksel yayın sistemi kullanılarak oluşturulmuş olan dokümanlara etkileşimli sunum kabiliyeti eklenmesini sağlar.

Diğer uygulamalar, genellikle orijinal belgeyi hazırlamak için kullanılan otomatik yayınlama sistemiyle ilişkilendirilmiş olup, çevrimiçi doküman görüntüleyicileri içerir. Sınıf-II teknik yayınlar genellikle SGML görüntüleyiciler ile görüntülenmektedir.

'''Sınıf III – Lineer Yapılı IETM’ler:''' Bu IETM’ler; içeriklerin eğitim, bakım vb. fonksiyonel paketler halinde görüntülenebileceği ara yüze sahiptir.

Sınıf-III (Köprü Metni IETM’leri) teknik yayın sistemleri, orijinali sayfa formatında basılı teknik yayın oluşturmak üzere tasarlanmış teknik yayınların, bir IETM biçiminde gösterilmek üzere dönüştürme işlemlerini gerçekleştirir. Söz konusu dönüştürme işleminin yapılabilmesi için doküman içeriğinde yer alan metinlerin IETM yazım standartlarında belirtilen metin etiketleri kullanılarak oluşturulması gerekir.

Bu sınıfta hazırlanan IETM’ler ile ses dosyaları, videolar veya diğer sistem ve yazılımlar arasında linkler oluşturulabilmektedir. Bu tip dokümanlarda mükerrer bilgiler olabilmektedir.

Sınıf-III teknik yayınlar, mevcut yayınların IETM biçimine dönüştürülmesine olanak sağlayarak, kağıt kullanımının kaldırılmasından elde edilen faydalara ilave olarak teknisyen performansının arttırılmasına imkan oluşturmaktadır.

Sınıf-III teknik yayın sistemleri, mevcut teknik yayın dosyalarının, Sınıf-IV sistemlerin (yani, IETM Veri Tabanı Sistemleri) çoğu özelliği ile elektronik ekrana dönüştürülebilmesi için bir geçiş adımı oluşturur.

'''Sınıf IV – Hiyerarşik Yapılı IETM’ler:''' Bu sınıfa giren IETM’lerin önceki sınıflandırmalara göre en büyük farkı, mükerrer bilgilerin olmaması veya çok aza indirilmesine olanak sağlamasıdır.

Sınıf IV IETM’lerde verilerin hazırlanması ve yönetimi diğer ETM sınıflarından oldukça farklıdır. Sınıf-IV teknik yayın sistemleri (Veri Tabanı Yönelimli IETM); teknik yayın verilerinin bir bilgisayar tarafından etkileşimli olarak gösterimi için gerekli, veri bileşenlerini ve özelliklerini içeren bir veri tabanı formuna özel olarak yazıldığı sistemlerdir.

Sınıf-IV teknik yayın hazırlama sürecinde öncelikli olarak IETM veri bileşenleri ile bu bileşenlerin özellik ve bağlantı bilgilerini içeren ilişkisel veya nesne yönelimli bir veri tabanı oluşturulur. Veriler modüler olarak hazırlanır ve yapısal veri tabanı içerisinde tutulur. Veri tabanında oluşturulan verilerin, bakım yardımcısı gibi bir elektronik görüntüleme sisteminde görüntülenebilmesi için teknik yayın yayımlama yazılım araçları vasıtasıyla veri tabanından çekilerek derlenmesi ve biçimlendirilmesi gereklidir. (Örn: Uyarı ve İkazlar bir kez yazılıp tekrar kullanılabilmektedir.) Fonksiyonel özellikler açısından Sınıf III IETM’lerin sergileyebildiği tüm fonksiyonel özellikleri sergileyebilmektedir.

Sınıf IV teknik yayınlar, elektronik ortam kullanımına özel olarak yazıldığından ve idamesi sağlandığından, elektronik ortamın olanaklarının en iyi şekilde kullanılmasını sağlarlar.

'''Sınıf V – Veri Tabanı ile Entegre IETM’ler:''' Sınıf-V teknik yayınların kapsamını gelişen teknolojik olanaklar şekillendirdiğinden, net olarak tanımlamak güçtür. Sınıflandırma şemasına dahil edilmesi, diğer otomatik Teknik Yayın sınıflarından daha iyi performans elde etmek için gösterilebilecek, gelecekteki çeşitli entegre kavramları öngörmeyi amaçlamaktadır.

Sınıf-V (Entegre İşlem IETM) teknik yayın sistemleri, kullanıcıya IETM özelliklerinin yanı sıra sağladığı bilgisayar programları veya uzman-sistem işlem yazılımları ile etkileşim kabiliyetleri ile diğer teknik yayınlarından farklılaşır. Bu sınıfa giren IETM'ler, fonksiyonel özellikler açısından Sınıf IV IETM'lerin sergileyebildiği tüm fonksiyonel özellikleri sergileyebilmektedir. Ayrıca teknik yayında yer alan içerikler ile yazılımlar ve cihazlar arasında etkileşime müsaade etmektedir.

Sınıf V teknik yayınların, daha iyi bir performans sağlamasının yanı sıra, bilginin kullanıcıya sunumunun etkinliğinin artırılması için; sunum sırasında gerçekleştirilen tam zamanında eğitim sistemi, aktif uzman öneri sistemi veya bilgisayarlı teşhis işlemi gibi ek uygulamaları IETM'in kapsamına entegre etmesi beklenir. Bu programlar arıza teşhis ve sorun giderme işlemleri sırasında veya Bilgisayar Tabanlı Eğitimler sırasında gerekli bakım bilgilerine erişim için Uzman Sistem işlemleri gibi kullanıcıya rehberlik edecek akıllı bilgiler sağlarlar. Bu prosedürler, Sınıf-IV kabiliyetleri kapsamında kullanıcı kontrolünde başlatılan IETM bilgisi gösterimlerini destekleyen, Uzman Sistem programı tarafından başlatılan, etkileşimli diyalogu içerirler.

Sınıf V teknik yayınlar da Sınıf IV gibi, elektronik ortam kullanımına özel olarak yazıldığından ve idamesi sağlandığından, elektronik ortamın olanaklarının en iyi şekilde kullanılmasını sağlarlar.

Sınıf-V teknik yayın uygulamaları, Sınıf-IV IETM veri tabanında olduğu gibi özenle oluşturulmuş, önceden yazılmış bilgileri içeren veri tabanına dayanan bir sistemde çalışmak için çok uygundurlar ve böyle bir IETM veri tabanının doğal bir uzantısı olarak tasarlanabilirler. Sınıf-V veri tabanları, IETM ile entegre yazılım ürünlerini (örneğin, bilgisayar destekli işlemler veya uzman sistem yazılımlarını) ve ayrıca teslim edilen ürünler olarak teknik bilgileri içerir.

'''c. Basılı Yayın ile IETM Arasındaki Temel Farklar:'''

* Basılı Yayında içerik tüm okuyucular için sabit şekilde oluşturulurken IETM’de kullanıcının bilgi seviyesine uygun şekilde içerik sunumu yapılabilmektedir. Başlangıç Yetenek Seviyesi ve Uzman Yetenek Seviyesi gibi seviye bazlı içerik tipleri oluşturularak okuyucu bilgi düzeyine göre ilgili prosedürler en basit adımları da içerecek şekilde veya basit işlem adımlarının detayları kapalı şekilde okuyucuya aktarılabilmektedir.
* Dikkat, Uyarı ve Not gibi teknik yayın kısımları basılı yayında sabit bir görsel olarak okuyucuya aktarılırken, IETM’de okuyucunun dikkatini daha fazla çekecek şekilde görselleştirilerek aktarılması mümkündür.
* Basılı Yayında ilgili bilgiler okuyucuya metin, çizim veya renkli-renksiz fotoğraf gibi sabit görseller kullanılarak aktarılırken; IETM’de 3B hareket ettirilebilir katı model görselleri, animasyonlu görseller, sesli ve hareketli medya kullanımı, kullanıcı etkileşimi sağlayan hotspot vb. teknik yayın anlaşılabilirliğini arttıracak sunum yöntemleri kullanılmasına olanak sağlamaktadır.
* Basılı yayında okuyucunun okuma sırasında yönleneceği referans bilgi ve kısımlara erişim için sayfa çevirme ve arama eforunu elle yapması söz konusuyken, IETM’de okuyucu teknik yayın içerisinde sağlanan link adreslerine tıklayarak ilgili kısımlara vakit ve dikkat kaybı yaşamadan erişebilmektedir.
* Basılı yayında okuyucunun ihtiyaç duyduğu anlık bilgilere erişimi için dizin ve içindekiler tablosu üzerinden birçok bilgiyi gözden geçirmek zorunluluğu söz konusu iken; IETM’de sunulan arama ve yardım menüleri üzerinden aranılan bilgilerin tamamına vakit ve dikkat kaybı yaşamadan erişim imkanı bulunmaktadır.
* Basılı yayınların güncellenme, dağıtım ve teknik yayın konfigürasyon kontrolünün sağlanması eforları çok daha fazla zaman, yüksek maliyet ile gecikme ve hata riskleri meydana getirirken; IETM’de doküman güncelleme, dağıtım ve konfigürasyon kontrolü faaliyetleri daha kısa sürede ve daha az riskle daha sağlıklı şekilde gerçekleştirilebilmektedir.
* Basılı yayında okuyucunun ilgili tedarik kataloglarını kullanarak bir tedarik faaliyetini başlatması manuel süreç esasları ile yürütülmek durumundayken, IETM’de bu süreç mevcut bilişim politikalarının izin vermesi durumunda çevrimiçi olarak internet ağı üzerinden çok hızlı şekilde düşük efor ve düşük hata ile yürütülebilmektedir.
* Basılı yayınların fiziksel olarak muhafazası, ilave alan, erişim güvenliğinin sağlanması ve teknik yayınların idame ettirilmesi bakımından daha fazla kaynak gereksinimine sahipken; IETM sistem üzerinde gömülü olarak kullanılabilmekte, fiziksel olarak ilave alan gereksinimini ortadan kaldırılabilmekte, erişim güvenliği açısından şifreleme ve hızlı şekilde güncelleme yapılabilmesine olanak sağlamaktadır.

= EK-A =

== İŞ KURALLARI İNDEKSİ ==

Tedarik makamlarınca belirlenen/belirlenebilecek veya bir proje çerçevesinde yükleniciler tarafından cevaplanarak dokümante edilmesi beklenen/beklenebilecek <ins>iş kurallarının listesi aşağıda belirtilmiştir.</ins>

Bu listede yer verilmeyen iş kuralı karar noktalarının tümü, bir alt karar katmanına bırakılmıştır.

Bu tablodaki ID sütunu S1000D 4.1 Spesifikasyonundaki İş Kurallarına verilen referansı göstermektedir. Karar sütunu ise, Teknik Yayın hazırlamada uygulanacak karar ve önerileri göstermektedir.
{| class="wikitable"
|'''ID'''
|'''Başlık'''
|'''Açıklama'''
|'''Karar'''
|'''Kategori'''
|-
|BRDP-S1-00001
|"I" ve " "O" karakterlerinin kullanımı
|"I" ve "O" karakterlerinin nerelerde ve nasıl kullanılacağına karar ver.
|Veri modül kodlamasında Model Tanımlama Kodu dışında “I” ve “O” harfleri kullanılmayacaktır. Verilerde kullanılacak kodlamalarda kararlar alt katmanlar tarafından alınacaktır.
|2
|-
|BRDP-S1-00003
|Uygulanacak S1000D versiyonu
|S1000D’nin hangi versiyonunun veya versiyonlarının uygulanacağına karar ver.
|Versiyon 4.1 ve üstü olacak şekilde alt katmanlar tarafından karar verilecektir.
|1
|-
|BRDP-S1-00004
|Kullanılacak bilgi kümeleri
|Kullanılacak bilgi kümelerine (S1000D’de yer alan ve/veya projeye özgü hazırlanan/hazırlanacak olan bilgi kümeleri) karar ver.
|Bir alt katman karar verecektir.
|3
|-
|BRDP-S1-00005
|Üretilecek yayınlar
|Hangi yayınların hazırlanacağına karar ver.
|Bir alt katman karar verecektir.
|1, 3, 10
|-
|BRDP-S1-00006
|Şema kullanımı
|S1000D’nin hangi şemalarının kullanılacağına ve bu şemaların bilgi kümeleri içinde nasıl kullanılacağına karar ver.
|Minimum PM, BREX, tanımlama (descriptive) şemaları kullanılacaktır. Diğer şemaların kullanımına proje ihtiyacına göre alt katmanlar tarafından karar verilecektir.
|1, 6a
|-
|BRDP-S1-00008
|Teslimat kalemleri
|Teslimat kalemlerinin ne olacağına karar ver:

· S1000D nesnelerinin (veri modülleri, yayın modülleri, görsel öğelerin listesi ve çoklu ortam nesneleri, veri modül listeleri, vb.) dosya tabanlı transfer metodu ile teslimi.

· Sayfa formatlı yayınlar ve/veya etkileşimli elektronik teknik yayınlar (IETM)
|Bir alt katman karar verecektir.
|1, 10
|-
|BRDP-S1-00012
|Gizlilik sınıflandırması değerleri ve şartlarına karar ver (Gizlilik sınıflandırması ataması)
|Gizlilik sınıflandırması ataması için hangi değerlerin kullanılacağına karar ver ve uygun tanımları belirle. Bkz: Bölüm 3.9.6.1
|MSY 317-2 (C) *

SSM-RHB-3500 / 001 *

“01” Tasnif Dışı

“02” Hizmete Özel

“03” Özel

“04” Gizli

“05” Çok Gizli

Olarak kullanılacaktır.
|4
|-
|BRDP-S1-00013
|Gizlilik sınıflandırmasının kullanımı ve işaretleme (gizlilik sınıflandırması atama)
|Gizlilik sınıflandırmasının nasıl kullanılacağına karar ver.
|Bkz. MSY 317-2 (C) *

'''2. Bölüm, 2. Konu, e maddesi'''

Bir data modülü içindeki bilgilerden herhangi birinin gizlilik derecesi “Tasnif Dışı”ndan yüksek ise o bilginin yazıldığı elementte bulunan securityClassification attribute’u kullanılarak bu bilgi tanımlanır.

Data modülün gizlilik derecesi, o data modülü içindeki en yüksek gizlilik derecesini taşıyan içeriğe göre belirlenir.
|4
|-
|BRDP-S1-00016
|Gizlilik sınıflandırmasının sunumu
|Gizlilik sınıflandırmasının nasıl gösterileceği/işaretleneceğine karar ver.
|Bkz. MSY 317-2 (C) *

2. Bölüm, 2. Konu, d maddesi
|4
|-
|BRDP-S1-00020
|Dili belirle.
|Data modülleri üretmek için hangi dilin kullanılacağına karar ver.
|Data Modüllerinin yazıldığı dil Türkçe olacaktır. Ancak proje özelinde tedarik makamı başka dillerin kullanımına da müsaade edebilir.
|6a
|-
|BRDP-S1-00022
|Standart sözlük
|Data modülleri üretmek için hangi standart sözlüğün kullanılacağına karar ver.
|Bir alt katman karar verecektir.
|6a
|-
|BRDP-S1-00023
|Terminoloji Veri Tabanı veya Sözlüğünün kullanımı
|Terminoloji Veri Tabanı mı Sözlük mü kullanılacağına karar ver. İçerikler ve yönetimi konusunda uzlaşma sağla.
|Tedarik makamı/ihtiyaç makamı tarafından belirlenecektir. Ancak ihtiyaç olması halinde bir alt katman tarafından karar verilecektir.
|6a
|-
|BRDP-S1-00024
|Kısaltmalar için standart liste kullanımı.
|Standart Kısaltma Listesi kullanılıp kullanılmayacağına karar ver. Kullanılacaksa içeriği ve yönetimi konusunda uzlaşma sağla.
|Bir alt katman karar verecektir.
|6a
|-
|BRDP-S1-00025
|Ölçüm Birimleri
|Birincil ve ikincil birimler için hangi ölçüm biriminin kullanılacağına karar ver.
|Türkiye’de üretilen tüm donanımlar için SI birim sistemi, RAHAT ürünler için ise dokümanda geçtiği haliyle kullanılmalı.
|6a
|-
|BRDP-S1-00026
|Vurgulanacak Metinler
|Metin vurgulama için hangi yöntemin kullanılacağına karar ver.
|Vurgulamalar yalnızca harflerin kalınlaştırılması ile verilecektir.
|6a
|-
|BRDP-S1-00036
|Başlık sayfasında revizyon ve taslak sürüm bilgisinin belirtilmesi
|Başlık sayfasında revizyon ve taslak sürüm bilgisinin kullanılıp kullanılmayacağınakarar ver.
|Kapak sayfasında versiyon/revizyon bilgisi bulunacaktır.
|6a, 10
|-
|BRDP-S1-00047
|Ülke ve Dil Kodları
|Kullanılacak ülke ve dil kodlarına karar ver ve proje boyunca aynı şekilde kullan.
|ISO 639 codes

Örneğin:

Ülke Kodu: TR

Dil Kodu: tur
|5
|-
|BRDP-S1-00052
|Bilgi Kodu ve Adlandırmalarının belirlenmesi
|Hangi bilgi kodu ve ilgili bilgi adlarının kullanılacağına karar ver, kullanılacak her bilgi kodu için bir şema ata.
|Bir alt katman karar verecektir.
|3, 5
|-
|BRDP-S1-00069
|<logo> elementinin kullanımı
|<logo> elemanının kullanılıp kullanılmayacağına ve kullanılacaksa fiziksel adının ne olacağına (ICN kodu) karar ver.
|Bir alt katman karar verecektir.
|5, 10
|-
|BRDP-S1-00121
|Standart tablo tiplerinin kullanımı
|Proje’de geçerli olacak standart tablo tiplerini tanımla ve bu tablo tipleri için hangi iş kurallarının tanımlanması gerektiğini belirle.
|Bir alt katman karar verecektir.
|6a
|-
|BRDP-S1-00122
|Tabloların şekil olarak kullanımı
|Tabloların data modül içeriklerinde şekil olarak kullanılıp kullanılmayacağına karar ver. Kullanılacaksa hangi koşullar altında kullanılacağını tanımla.
|Bir alt katman karar verecektir.
|6a
|-
|BRDP-S1-00304
|Hiyerarşik “İçindekiler” sayfası kullanımı
|Hiyerarşik “İçindekiler” sayfası kullanılıp kullanılmayacağına karar ver. Eğer kullanılacaksa kaçıncı seviyeye inileceğini belirle.
|En çok 5 seviyeye kadar inilecektir.
|6a, 10
|-
|BRDP-S1-00306
|İçindekiler sayfasında versiyon bilgisi ve/veya tarihinin kullanımı
|İçindekiler sayfasında listelenecek içeriklerin versiyon bilgilerinin (<issueInfo>/<externalPubIssueInfo>) ve/veya tarihlerinin (<issueDate>/<externalPubIssueDate>) kullanılıp kullanılmayacağına karar ver.
|İçermeyecektir.
|6a, 10
|-
|BRDP-S1-00310
|S1000D’de hazırlanmış içeriklerin toplam sayfa sayısının nasıl derleneceği
|S1000D’de hazırlanmış içeriklerin toplam sayfa sayısının derlenmesinde <footnoteRemarks> elemanının kullanımına karar ver.
|Bir alt katman karar verecektir.
|6a, 10
|-
|BRDP-S1-00328
|S1000D terminolojisinin çevirisi
|Müsaade edilen özellik değerlerinin projeye uygun dile çevrilip çevrilmeyeceğine karar ver.
|Türkçe tanımları kullanılacak.

Ancak proje özelinde tedarik makamı başka dillerin kullanımına da müsaade edebilir.

Bkz.: AÇG 1.2 Terminoloji Rehberi *
|6a
|-
|BRDP-S1-00331
|Data modülü kodlama stratejisi
|Ürün ve/veya projede uygulanacak data modülü kodlama stratejisini belirle.
|Bir alt katman karar verecektir.
|2, 3, 5
|-
|BRDP-S1-00336
|Ürün SNS yapısı
|Hangi SNS yapısının kullanılacağına karar ver.
|Bir alt katman karar verecektir.
|2
|-
|BRDP-S1-00337
|Malzeme kategorisi kodunun kullanımı
|Malzeme kategorisi kodunun kullanımına karar ver.
|Bir alt katman karar verecektir.
|2
|-
|BRDP-S1-00366
|Proje’ye özgü BREX data modülü kullanımı
|Projeye özgü BREX data modülü hazırlanıp hazırlanmayacağına karar ver.
|Her projede, proje ihtiyacını yansıtan BREX data modülü hazırlanacaktır.
|1, 5
|-
|BRDP-S1-00475
|Sayfa boyutu
|Her yayın için sayfa boyutlarına (Katlı (foldout) sayfalar da dahil) karar ver.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00476
|Sayfa formatlı yayınlarda katlı (foldout) sayfaların gösterimi
|Sayfa formatlı yayınlarda katlı (foldout) sayfaların hangi koşullar altında gösterileceğine karar ver.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00477
|Taslak numarasının gösterimi
|Taslak numarasının gösterilip gösterilmeyeceğine karar ver. Karar detayları dokümante edilmelidir.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00478
|“… Tarafından Hazırlanmıştır” – “Basımı …’da Yapılmıştır” ifadelerinin gösterimi
|Yayınların kim tarafından hazırlandığı veya basımının nerede yapıldığı bilgisinin görüntülenip görüntülenmeyeceğine karar ver.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00480
|Data modülü kodunun gösterimi
|Data modülü kodunun alt bilgide görüntülenmesinde S1000D’de yer alan standart yöntemin mi yoksa projeye / kuruma özgü bir yöntemin mi kullanılacağına karar ver.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00481
|Versiyon tarihinin gösterimi
|Versiyon tarihinin alt bilgide görüntülenmesinde S1000D’de yer alan standart yöntemin mi yoksa projeye / kuruma özgü bir yöntemin mi kullanılacağına karar ver.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00482
|Sayfa numaralarının gösterimi
|Sayfa numaralarının alt bilgide görüntülenmesinde S1000D’de yer alan standart yöntemin mi yoksa projeye / kuruma özgü bir yöntemin mi kullanılacağına karar ver.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00485
|Gizlilik derecelendirmesinin görüntülenmesi
|Gizlilik derecelendirmesinin görüntülenmesi sırasında ibarenin tüm harflerinin büyük mü yoksa baş harfinin büyük diğerlerinin küçük mü olacağına karar ver.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00487
|Gizlilik derecelendirmesi olmayan yayınlarda gizlilik derecelendirmesinin gösteriminin hariç tutulması
|Gizlilik derecelendirmesi olmayan yayınlarda gizlilik derecelendirmesinin gösterilip gösterilmeyeceğine karar ver.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00489
|<logo> elemanının gösterilmesi
|Basılı dokümanlarda <logo> elemanında yer alan logo tipi seçeneklerinden herhangi birisinin kullanılıp kullanılmayacağına karar ver. Bu elemanın nasıl görüntüleneceğine karar ver. (Örn: boyutu, renkleri, vb.)
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00490
|“Data Modülü Sonu” ifadesinin gösterimi
|Data modülünün sona erdiğini tanımlayacak ifadenin nasıl kullanılacağına karar ver. (“Data Modülü Sonu” olarak mı yoksa “Sonu” ifadesinden önce data modülü başlığının kullanılması yolu ile mi?)
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00491
|“Data Modülü Sonu” ifadesinin sayfa üzerindeki yerleşimi
|“Data Modülü Sonu” ifadesinin sayfa alt bilgisine mi yoksa sayfanın metin alanında mı görüntüleneceğine karar ver.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00496
|Doküman başlığının gösterimi
|Doküman başlıklarının gösterim yerini belirle.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00498
|Tablolar dizininin gösterimi
|Tablolar dizininin görüntülenip görüntülenmeyeceğine karar ver.
|Her dokümanda tablolar listesi bulunacaktır.
|10
|-
|BRDP-S1-00499
|Tablolar dizininde “Tablo” ifadesinin kullanımı
|Tablolar dizininde “Tablo” ifadesinin tablo numaralarından önce kullanılıp kullanılmayacağına karar ver.
|Tablolar listesinde Tablo ön eki bulunacaktır.
|10
|-
|BRDP-S1-00500
|Şekiller dizininin gösterimi
|Şekiller dizininin görüntülenip görüntülenmeyeceğine karar ver.
|Her dokümanda şekiller listesi olacaktır.
|10
|-
|BRDP-S1-00501
|Şekiller dizininde “Şekil” ifadesinin kullanımı
|Şekiller dizininde “Şekil” ifadesinin şekil numaralarından önce kullanılıp kullanılmayacağına karar ver.
|Şekiller listesinde Şekil ön eki bulunacaktır.
|10
|-
|BRDP-S1-00502
|Başlıkların gösterimi (yerleşim düzeni)
|Başlıkların gösterilmesinde S1000D’nin standart metodunun kullanılıp kullanılmayacağına karar ver. Kullanılmayacaksa Proje veya Kurum kararını tanımla.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00505
|Metin paragraflarının gösterimi
|Yazı boyutu, boşluk ve hizalaması için önerilen kuralların kullanılıp kullanılmayacağına karar ver.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00507
|Listeler için kullanılacak ön ekler
|Proje boyunca listeler için sabit bir ön ek seti kullanılıp kullanılmayacağına karar ver.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00513
|Uyarı ve Dikkatlerin gösterimi
|Uyarıların adım/paragraf numarası öncesinde gösterimi için alternatif kuralın kullanılıp kullanılmayacağına karar ver.

Not: Adım numaralarının uyarıyı takip etmesinin potansiyel tehlikelerinin farkına varılmalı ve aralarında net bir bağlantı olduğundan emin olunmalıdır.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00514
|Uyarı ve Dikkatlerde sembollerin gösterimi
|Uyarı ve dikkatlerde sembollerin kullanımına karar ver. Semboller standart ve dökümante edilmiş olmalıdır.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00517
|Değişiklik işaretlerinin gösterimi
|Değişiklik işaretlerinin gösterimine karar ver.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00527
|Kapak sayfasında görüntülenecek eleman ve nitelikler
|Kapak sayfasında görüntülenecek eleman ve niteliklere karar ver.

'''Not:'''

Bu karar noktasında alınan kararlar S1000D bölüm 3.9.5.2.16.’de yer alan karar noktaları ile uyumlu olmalıdır.
|Bir alt katman karar verecektir.
|1, 10
|-
|BRDP-S1-00528
|Kapak sayfasında kullanılacak görsel öğenin ebatları
|Eğer kapak sayfasında görsel öğe kullanılacaksa bu görselin yüksekliğine karar ver.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00533
|IETP’ler için kural ve yönlendirme kullanımı
|IETP görüntüleyicinin ekran ve arayüz tasarımı ile ilgili kural ve yönlendirmelerinin olup olmayacağına karar ver. Ayrıca IETP görüntüleyici üzerinden yazdırılacak olan içeriklerin çıktı formatının S1000D bölüm 6.3.1’dekine veya projede bu bölüme alternatif olarak hazırlanan formata uygunluğunu sağla.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00537
|Fonksiyonellik matrisinin kullanımı
|Fonksiyonellik matrisinin kullanımına karar ver. Eğer kullanılacaksa fonksiyonellik matrisini doldur. (Bkz. S1000D bölüm 6.4.2.)
|Sınıf 4 ve 5 IETM’ler için kullanılacaktır.
|4, 7, 10
|-
|BRDP-S1-00549
|SNS başlıklarının ve açıklamalarının çevirisi
|Projede kullanılacak SNS’lerin başlık ve açıklamalarının proje diline çevirisinin yapılıp yapılmayacağına karar ver.
|Bir alt katman karar verecektir
|2
|-
|BRDP-S1-00550
|Projeye özgü bilgi kodlarının kullanımı
|S1000D’nin proje ihtiyacına göre tanımlanmasına müsaade ettiği bilgi kodlarının kullanımına karar ver. Projeye özgü bilgi kodları kullanılacaksa bu kodlar için kısa ve detaylı açıklamalar hazırla.
|Bir alt katman karar verecektir
|3
|-
|BRDP-S1-00551
|Bilgi kodu açıklamalarının çevirisi
|Bilgi kodu açıklamalarının proje diline çevirisinin yapılıp yapılmayacağına karar ver.
|Bir alt katman karar verecektir
|3
|}
<nowiki>*</nowiki> İlgili yönerge/yönetmeliklerin en son sürümü kullanılacaktır.

Eğitim dokümantasyonu S1000D spesifikasyonu çerçevesinde hazırlanırken aşağıdaki iş kurallarının da dikkate alınarak planlama yapılması gerekmektedir.

{| class="wikitable"
|'''ID'''
|'''Başlık'''
|'''Açıklama'''
|'''Karar'''
|'''Kategori'''
|-
|BRDP-S1-00267
|Performans analizi gerçekleştirme
|İş performansını etkileyebilecek faktörlere karar vermek için bir performans analizi mi yoksa eğitim gereksinimlerini belirlemek için eğitim ihtiyaçları analizi mi yapılacağına karar ver.
|Bir alt katman karar verecektir
|3, 5, 6a
|-
|BRDP-S1-00268
|Eğitim konularının hedeflerinin geliştirilmesi
|Eğitim konularının hedeflerinin, görev analizi elemanları ile uyumlu olarak geliştirilip geliştirilmeyeceği-ne karar ver. Eğitim konuları, görev analizi elemanları ile uyumlu olarak geliştirilmelidir. Eğitim içerikleri ile görev analizi elemanları arasındaki uyum ne kadar erken tesis edilirse, verilerin tekrar kullanılabilirliği de o kadar artar. İçerik planlaması için Bkz. S1000D bölüm 3.9.7.
|Bir alt katman karar verecektir.
|3, 5, 6a
|-
|BRDP-S1-00269
|Ders planlarının SCORM içerik paketleri olarak hazırlanması
|Ders planlarının SCORM içerik paketleri olarak hazırlanıp, hazırlanmayacağına karar ver.
|Bir alt katman karar verecektir.
|5, 6a, 7
|-
|BRDP-S1-00270
|Ömür devri ihtiyaçlarının performans analizi verileri için tanımlanması
|Müşterinin organizasyonu ve ürüne bağlı olarak değişen insan performansı sistemi için yapılan performans analizi sonucunda elde edilen analiz bilgisi ve gereksinimler için ömür devri ihtiyacını belirle.
|Bir alt katman karar verecektir.
|3, 5, 6a
|-
|BRDP-S1-00271
|Ömür devri ihtiyaçlarının eğitim ihtiyacı analizi verileri için tanımlanması
|Eğitim uygulaması için yapılan eğitim gereksinimleri analizi sonucunda elde edilen analiz bilgisi ve gereksinimler için ömür devri ihtiyacını belirle.
|Bir alt katman karar verecektir.
|3, 5, 6a
|-
|BRDP-S1-00272
|Eğitim hedefinin anlatıldığı içeriklerde <dmRef> elemanının kullanımı
|Eğitim hedefinin anlatıldığı içeriklerde, içeriği destekleyici farklı içeriklere, <dmRef> elemanını kullanarak referans verilip verilemeyeceğine karar ver.
|Bir alt katman karar verecektir.
|6a
|-
|BRDP-S1-00273
|<weightingFactor> (ağırlık faktörü) niteliğinin kullanımı
|Sınav sorularına ağırlık faktörü uygulanıp uygulanmayacağına karar ver.
|Bir alt katman karar verecektir.
|3, 5, 6a
|-
|BRDP-S1-00274
|<attempts> (tekrarlama) niteliğinin kullanımı
|Sınav sorularına birden fazla kez cevap verme şansının verilip verilmeyeceğine karar ver.
|Bir alt katman karar verecektir.
|3, 5, 6a
|-
|BRDP-S1-00552
|Eğitim kodu açıklamalarının çevirisi
|Eğitim kodu açıklamalarının proje diline çevirisinin yapılıp yapılmayacağına karar ver.
|Bir alt katman karar verecektir
|3, 5
|}

= EK-B =

== TEKNİK YAYIN ŞABLON ÖRNEĞİ ==
Bu bölümde teknik yayın şablonu örnek olarak verilmiştir. Şablon, proje çerçevesinde oluşturulacak iş kuralları kapsamında her projede ihtiyaca göre değiştirilebilir ve genişletilip daraltılabilir. Her proje başlangıcında tüm paydaşlarca kabul görecek iş kuralları dokümanı hazırlanmalı ve alınan kararlar proje kapsamındaki tüm teknik yayınlarda uygulanmalıdır.

'''<big>1. KAPAK VE GİRİŞ BÖLÜMÜ ÖRNEĞİ</big>'''

'''<big>1.1. KAPAK</big>'''

Kapak sayfası aşağıdaki bilgilerden uygulanabilir olanları kapsamalıdır:

'''1. ''' Teknik yayının güvenlik seviyesi

'''2. ''' Teknik yayın numarası

'''3. ''' Cilt numarası (Teknik yayının birden fazla ciltten oluştuğu durumlarda)

'''4. ''' Versiyon (revizyon) numarası

'''5. ''' Teknik yayının tipi (Bakım El Kitabı, Resimli Parça Kataloğu vb.)

'''6. ''' Bakım seviyesi

'''7. ''' Ürünün tanımı/ismi

'''8. ''' Model numarası/Parça Numarası

'''9. ''' Ürün/Sistem NATO Stok Numarası (NSN)

'''10. '''Alt ürünün tanımı/ismi (Teknik yayının birden fazla ciltten oluştuğu durumlarda)

'''11. '''Üretici ismi/adresi / Web Adresi

'''12. '''Sözleşme numarası

'''13. '''Kullanıcı İsmi

'''14. '''Yayın tarihi

'''15. '''Telif hakkı

'''16. '''SVİL/DVİL Numarası

'''17. '''Proje logosu / kısa adı

'''18. '''Ürünün resmi

Kapak sayfasının ön yüzüne sığmayan bilgiler olduğu durumda kapağın arka yüzüne devam edilir, aksi takdirde boş bırakılır.

Teknik yayının cilt sırtına teknik yayın numarası ve ürünün tanımı/ismi yazılır.

Ön kapağa sığmayan bilgilerin olduğu durumda aşağıdaki bilgiler için kapağın arka kısmı kullanılabilir.

'''1. ''' Telif hakkı

'''2. ''' Üretici ismi/adresi / Web Adresi

'''3. ''' Teknik Yayın ile ilgili kısıtlar, açıklamalar, hata bildirimi vb. bilgiler
[[Dosya:Şekil9 Kapak Sayfası.jpg|alt=|sol|küçükresim|527x527pik]]

[[Dosya:Şekil9b Kapak Sayfası.jpg|alt=Şekil 9 Kapak Sayfası (Örnek)|sol|küçükresim|493x493pik|Şekil 9 Kapak Sayfası (Örnek)]]

'''<big>1.2. DEĞİŞİKLİK İZLEME TABLOSU</big>'''

Teknik yayına ilişkin değişikliklerin belirtildiği tablodur. Bu tablo aşağıdaki bilgileri kapsamalıdır.

* Versiyon (revizyon) numarası
* Değişiklik tarihi
* Değişiklik yapılan bölüm / paragraf
* Eklenen veya değiştirilen sayfalar aşağıdaki şekilde kodlanmalıdır.
** Y=Yeni sayfa
** D=Değişen sayfa

'''“Y”''' ilave edilen Yeni Sayfayı belirtmektedir. Bunun anlamı, belirtilen tarih ve versiyonda o sayfanın ilave yapıldığını göstermektir.

Yeni ilave edilen sayfaların numaralandırması için farklı yöntemler mevcut olmakla birlikte, araya girecek sayfanın takip eden sayfaların numaralarını değiştirmemesi amacıyla, önceki sayfa numarasına A harfinden başlamak üzere harfler ilavesi ile yapılması uygun olacaktır. Örneğin:

Sayfa numarası 3-15 ile 3-16 arasına iki yeni sayfa ilavesi yapılacak ise, eklenen sayfalar için 3-15A ve 3-15B numaraları kullanılabilir. Böylece takip eden sayfa numarası değişmeden 3-16 olarak kalır.

'''“D”''' Değişiklik yapılan sayfayı belirtmektedir'''.''' Bunun anlamı belirtilen tarih ve versiyonda o sayfada değişiklik yapıldığını göstermektir.

Bilgilerin silinmesi neticesinde tamamen silinecek sayfalar değişiklik kapsamında değerlendirilebilir. Silinecek sayfa boş ve mevcut sayfa numarası olarak (sayfa üzerinde “Bu sayfa boş bırakılmıştır” ibaresi ile) korunur. Böylece takip eden sayfaların numaraları değiştirilmez. Örneğin:

Sayfa numarası 3-15 olan sayfa kaldırılacak ise, bu sayfa üzerindeki bilgiler silinerek ve üzerine “Bu sayfa boş bırakılmıştır” ibaresi yazılı olarak, yine 3-15 sayfa numarası ile dokümanda bırakılır. Böylece takip eden sayfa numarası değişmeden 3-16 olarak kalır.

* Değişikliğin sebebi

Değişiklik İzleme Tablosunda, teknik yayındaki değişikliklerin tamamı veya sadece yapılan son değişiklik gösterilebilir.
[[Dosya:Şekil 10 Değişiklik İzleme Tablosu (Örnek).jpg|alt=Şekil 10 Değişiklik İzleme Tablosu (Örnek)|sol|küçükresim|600x600pik|Şekil 10 Değişiklik İzleme Tablosu (Örnek)]]

'''<big>1.3. İÇINDEKİLER SAYFASI</big>'''

Teknik yayında yer alan tüm bölümlerin listelendiği tablodur. İçindekiler bölümü aşağıdaki bilgileri içermelidir:

* Bölüm/Kısım/Paragraf numarası
* Bölüm/Kısım/Paragraf adı
* Sayfa numarası

İçindekiler sayfası; kapak ve değişiklik izleme tablosunu içermemelidir.
[[Dosya:Şekil11 İçindekiler Listesi.jpg|alt=Şekil 11 İçindekiler Listesi (Örnek)|sol|küçükresim|600x600pik|Şekil 11 İçindekiler Listesi (Örnek)]]

'''<big>1.4. ŞEKILLER LİSTESİ</big>'''

Bu liste teknik yayında bulunan tüm şekilleri listeler. Aşağıdaki bilgileri içerir.

* Şekil numarası
* Şekil ismi
* Sayfa numarası
[[Dosya:Şekil12 Şekiller Listesi.jpg|alt=Şekil 12 Şekiller Listesi (Örnek)|sol|küçükresim|600x600pik|Şekil 12 Şekiller Listesi (Örnek)]]

'''<big>1.5. TABLOLAR LİSTESİ</big>'''

Bu liste teknik yayında bulunan tüm tabloları listeler. Aşağıdaki bilgileri içerir.

* Tablo numarası
* Tablo ismi
* Sayfa numarası
[[Dosya:Şekil13 Tablolar Listesi.jpg|alt=Şekil 13 Tablolar Listesi (Örnek)|sol|küçükresim|600x600pik|Şekil 13 Tablolar Listesi (Örnek)]]

'''<big>1.6. KISALTMALAR LİSTESİ</big>'''

Bu liste teknik yayında kullanılan kısaltmaların açıklamalarını alfabetik sıra ile listeler ve aşağıdaki bilgileri içerir:

* Kısaltma
* Kısaltmanın açıklaması
[[Dosya:Şekil14 Kısaltmalar Tablosu.jpg|alt=Şekil 14 Kısaltmalar Tablosu (Örnek)|sol|küçükresim|600x600pik|Şekil 14 Kısaltmalar Tablosu (Örnek)]]

'''<big>1.7. TANIMLAR LİSTESİ</big>'''

Bu liste teknik yayında kullanılan tanımların açıklamalarını alfabetik sıra ile listeler ve aşağıdaki bilgileri içerir.

* Tanım
* Tanımın açıklaması
[[Dosya:Şekil15 Tanımlar Tablosu.jpg|alt=Şekil 15 Tanımlar Tablosu (Örnek)|sol|küçükresim|600x600pik|Şekil 15 Tanımlar Tablosu (Örnek)]]

'''<big>1.8. SEMBOLLER LİSTESİ</big>'''

Bu liste teknik yayında kullanılan özel sembollerin açıklamalarını listeler. Aşağıdaki bilgileri içerir.

* Sembol
* Sembolün açıklaması
[[Dosya:Şekil16 Semboller Listesi.jpg|alt=Şekil 16 Semboller Listesi Tablosu (Örnek)|sol|küçükresim|400x400pik|Şekil 16 Semboller Listesi Tablosu (Örnek)]]

'''<big>1.9. REFERANS DOKÜMANLAR TABLOSU</big>'''

Bu tablo teknik yayınla ilişkili dokümanları listeler. Aşağıdaki bilgileri içerir.

* Doküman numarası
* Doküman açıklama
* Doküman yayın tarihi
* Versiyon (revizyon) numarası
[[Dosya:Şekil17 Referans Dokümanlar Tablosu.jpg|alt=Şekil 17 Referans Dokümanlar Tablosu (Örnek)|sol|küçükresim|550x550pik|Şekil 17 Referans Dokümanlar Tablosu (Örnek)]]

'''<big>1.10. TEKNIK YAYININ AMACI</big>'''

Bu bölümde teknik yayının kullanım amacı, kapsamı, kullanımına yönelik bilgi, teknik yayınla ilgili değişiklik istek usulleri, varsa kısıtlar ve özel bilgiler verilir.

'''<big>1.11. EMNİYET TEDBİRLERİ</big>'''

Bu bölümde ürünle ilgili genel emniyet tedbirleri açıklanır. İhtiyaç duyulmadıkça, teknik yayının diğer bölümlerinde bu emniyet tedbirleri tekrarlanmaz.

'''<big>1.12. İKAZ VE NOT STANDARTLARI</big>'''

Teknik yayında kullanılacak olan ikazlar, uygulanmadıklarında yaşanabilecek durumun kritikliğine göre iki seviye halinde kategorilendirilir ve “DİKKAT”, “UYARI” vb. şekilde isimlendirilir. Bu isimlendirme kuvvetler arasında farklılık gösterebilmektedir.

* 1. Seviye İkaz: Doğru şekilde uygulanmadığında personelin yaralanmasına ya da hayatını kaybetmesine neden olabilecek prosedürler, işlem adımları, uygulamalar vb. için kullanılır.

* 2. Seviye İkaz: Dikkatle takip edilmemesi durumunda ekipmanın zarar görmesine ya da kullanılamaz hale gelmesine neden olabilecek prosedürler, işlem adımları, uygulamalar vb. için kullanılır.

İkazlara ek olarak, özellikle vurgulanmak istenen bir bilgi olduğunda, not ifadesi kullanılır. Not içerisinde kesinlikle talimat verilmemelidir.

İkazlar ilgili paragraftan önce verilmelidir. Notlar ise ilgili paragraftan önce veya sonra gelebilir.

İkaz ve notlar işlem adımı olarak verilmez ve paragraf numarası atanmaz.

İkaz ve notlar birden fazla paragraftan oluşursa, sadece bir kere başlık yazılır.

Birden fazla ikazın peşpeşe verilmesi gereken durumlarda, yazılma sırası “1. SEVİYE İKAZ” / “2. SEVİYE İKAZ” / “NOT” şeklinde olmalıdır.

İkazlar, tehlikeden korunmak için ne yapılması ya da yapılmaması gerektiği konusunda basit ve net bir talimat ile başlamalıdır. Bu talimat, konu ile ilgili diğer bilgiler arasında kaybolup gitmemelidir. Önce talimat verilmeli, sonra gerekiyorsa ek bilgiler verilmelidir.

Yönergelerde personelin işleme devam edebilmesi için sağlanması gereken bir koşul varsa, bu koşul 1. veya 2. seviye ikaz olarak işlem adımından önce verilmelidir.

Not ifadeleri, özellikle vurgulanmak istenen bir bilgi olduğunda kullanılmalı, not içerisinde kesinlikle talimat verilmemelidir.

1. seviye ikaz, 2. seviye ikaz ve notların yazımı için teknik yayın içerisinde kolaylıkla fark edilebilen başlık, font ve biçim formatları belirlenmeli, iş kuralları dokümanına yansıtılmalı ve teknik yayının tamamında tutarlı olarak bu formatlar kullanılmalıdır.

'''<big>1.13. İLGİLİ DOKÜMANLAR</big>'''

İlgili dokümanlar belirtilmelidir. Aşağıdaki bilgileri içerir.

* Doküman numarası
* Doküman adı
* Doküman yayın tarihi
* Yayınlayan
[[Dosya:Şekil18 İlgili Dokümanlar Tablosu.jpg|alt=Şekil 18 İlgili Dokümanlar Tablosu (Örnek)|sol|küçükresim|500x500pik|Şekil 18 İlgili Dokümanlar Tablosu (Örnek)]]

'''<big>1.14. GENEL YAPI ÖRNEĞİ</big>'''

'''<big>1.14.1. BAŞLIKLAR</big>'''

* '''Bölüm'''

Sayfa başlangıcının ortasına, büyük ve kalın harflerle önce varsa bölüm numarası tek başına, alt satırına bölüm adı yazılır. Bölümler dokümanın sağ tarafındaki sayfadan başlamalı. Sol taraftaki sayfa gerekirse boş bırakılmalıdır.

* '''Kısım'''

Bölüm numarası ve adından sonra bir satır boşluk bırakılarak, kısım numarası ve adı büyük ve kalın harflerle tek satıra yazılır.

* '''Paragraf'''

Teknik yayın metni, paragraflar ve alt paragraflara bölünerek yazılır. Paragraf ve alt paragraf başlıkları tek başlarına koyu olarak yazılır. Paragraf, büyük harflerle, alt paragraflar ise sadece baş harfleri büyük olacak şekilde yazılır.
[[Dosya:Şekil19 Başlıklar.jpg|alt=Şekil 19 Başlıklar (Örnek)|sol|küçükresim|485x485pik|Şekil 19 Başlıklar (Örnek)]]

'''<big>1.14.2. TABLOLAR</big>'''

Referans veriler (resim, çizim, diyagramlar hariç) çizelgeler halinde sunulur. Tablolar, tablo ismi ve numarası, tablo başlığı, satır ve sütunlardan oluşur.

Tablonun ismi ve numarası tablonun üstünde veya altında, tabloyla beraber sayfanın ortasında baş harfleri büyük ve koyu olacak şekilde yazılmalıdır. Tablo numaralandırılması, bölüm bilgisini de içermelidir. Tablo başlıkları tablonun içinde kalacak şekilde hücre ortasında koyu olarak yazılır. Diğer sayfaya taşan tablolarda tablo ismi, numarası ve tablo başlıkları tekrar edilmelidir.
[[Dosya:Şekil20 Tablo.jpg|alt=|sol|küçükresim|500x500pik|Şekil 20 Tablo (Örnek)]]

'''<big>1.14.3. ŞEKİLLER</big>'''

Şekil (resimler, çizimler, diyagramlar) ismi ve numarası, şeklin altında ve ortasında baş harfleri büyük ve koyu olacak şekilde yazılmalıdır. Şekil numaralandırılması, bölüm bilgisini de içermelidir. Standart sayfaya sığmayan şekiller katlanabilir sayfa halinde hazırlanabilir.
[[Dosya:Şekil21 Şekil .jpg|alt=Şekil 21 Şekil (Örnek)|sol|küçükresim|400x400pik|Şekil 21 Şekil (Örnek)]]

'''<big>1.14.4. TEKNİK YAYIN CİLT/KLASÖR İŞLEMLERİ</big>'''

Teknik yayınların cilt/klasör kapaklarına Paragraf 4.1.1’deki bilgilerden gerekli görülenler konulur. Aşağıdaki şekilde gösterilen veriler, cilt/klasör sırt kısmına cilt/klasör kalınlığına göre yazılır
[[Dosya:Şekil22 Teknik Yayın Cilt.jpg|alt=Şekil 22 Teknik Yayın Cilt/Klasör (Örnek)|sol|küçükresim|500x500pik|Şekil 22 Teknik Yayın Cilt/Klasör (Örnek)]]

'''<big>1.14.5. REFERANSLAR</big>'''

Teknik yayın içinde verilecek referanslar, konunun anlatıldığı cümlenin sonuna parantez içinde ilgili paragraf/tablo/şekil numarası verilerek gösterilir Örneğin Şekiller uygulaması (bak.Prg.4.3.3.) / (bak. Şekil 2-55) vb.

= EK-C =

== TEKNİK YAYIN YAZIM ÖRNEKLERİ ==

Bu bölümde teknik yayın hazırlarken kullanılacak kelime, cümle, cümle yapısı gibi konularda öneri ve yol gösterici olabilecek örnekler verilmiştir.

'''1 Kelimeler'''

'''1.1 – Teknik isimler kullan (gerekirse kısaltarak kullan).'''

Jargon ve mesleki argo kullanmaktan kaçın. Seçtiğin kelimelerin genel kullanılan kelimeler olduğundan emin ol.

''Örneğin;''

''YANLIŞ: Yüzey timsah derisi gibiyse boyama işlemini tekrarla.''

''DOĞRU: Yüzey pürüzsüz değilse boyama işlemini tekrarla.''

'''1.2 – Aynı şey için birden fazla teknik isim kullanma.'''

Bir birim ya da parçadan bahsederken yalnızca bir isim kullan. Örneğin, metnin ilk kısmında "anten" olarak tanımladığın parçadan daha sonra "sensör" diye bahsetme.

'''1.3 – Seçme şansın varsa, en kısa ve en basit ifadeyi kullan.'''

Bir şeyi isimlendirmek ya da tarif etmek için kullanılabilecek birden fazla ifade olması durumunda, en kısa ve en basit ifadeyi kullan.

'''1.4 – Bir şeyi tarif etmek için kullanacağın ifadeyi bir kez seçtiysen, hep aynı ifadeyi kullanmaya devam et.'''

Prosedür adımlarında geçen bir işlem birden fazla yerde tekrarlanıyorsa, her seferinde bu işlemi aynı kelimelerle ifade et. Aynı kelimeler ve cümle yapılarının tekrar tekrar kullanılması, okuyan kişinin metni anlamasını kolaylaştırır.

''Örneğin;''

''1. Filtreyi çıkartmak için plakadaki vidaları sök.''

''2. Filtreyi sabitleyen vidaları sök ve filtreyi plakadan ayır.''

Bu iki cümle, aynı işlemi farklı ifadeler ile anlatır. Farklı yönergelerde aynı işlem için bu iki cümlenin de kullanılması, okuyucunun kafasını karıştıracaktır. İfade olarak hangi cümle daha uygunsa seç ve bu işlemi anlatırken hep aynı cümleyi kullan.

Betimleyici anlatım kısımlarında bu kural geçerli değildir. Aksine, farklı kelime ve cümle yapılarının kullanılması, metni daha okunabilir ve ilgi çekici kılmak için gereklidir.

'''1.5 – Talimatların olabildiğince net olsun.'''

Yazdığın yönergeler, bir işlemin yapılmamasının sonuçlarını değil, o işlemin nasıl yapılacağını anlatmalıdır.

''Örneğin;''

''YANLIŞ: Farklı sıcaklıklar, boyanın kuruma süresini değiştirir.''

''DOĞRU: Boyanın kuruma süresini kısaltmak için sıcaklığı arttır.''

'''2 Cümleler'''

Teknik yayın hazırlarken temel hedef, metinleri olabildiğince basit, okunması ve anlaşılması kolay tutmaktır. Bu, yazılan cümlelerin kısa tutulmasını ve metnin karmaşık hale gelmesinden kaçınılmasını gerektirir.

'''2.1 – Bir cümlede yalnızca bir konudan bahset.'''

Bazı metin yazarları, bildikleri her şeyi bir anda anlatabilmek adına uzun cümleler kurarlar. Ancak, aktarılmak istenen bilgi tüm detaylarıyla 1-2 cümlede anlatılmaya çalışıldığında, okuyucunun kafası karışacaktır. Bu yüzden, bilgi yavaş yavaş sunulmalı ve her cümle yalnız bir konu ile ilgili olmalıdır. Böylece cümlelerin uzunluğu da kabul edilebilir seviyeye inecektir.

'''2.2 – Cümleleri kısaltmak için özne ya da yüklemi cümleden çıkartma.'''

Özne ya da yüklemin bulunmadığı cümleler, anlam açısından muğlaklık yaratacaktır. Bu nedenle, cümleleri kısaltmak için mutlak öğelerden birini çıkartma değil, cümleyi birden fazla parçaya bölme yöntemi kullanılmalıdır.

'''2.3 – Karmaşık metinler için madde madde anlatım yöntemini kullan.'''

Birden fazla işlem, olay vb. anlatan uzun bir cümle yerine maddelere bölünmüş bir cümle yapısı kullanmak, metnin okunmasını ve maddeler arasındaki ilişkinin görülmesini kolaylaştırır.

Madde madde anlatım yönteminde:

* Cümlenin giriş kısmının sonuna (:) konulur.
* Maddelerin ilk harfleri büyük olur.
* Her bir maddede bir cümle varsa (madde içerisinde cümle tamamlanıyorsa) sonuna (.) konur.
* Her bir madde ayrı bir cümle değilse sonlarına (.) konulmaz, yalnızca son maddenin sonuna (.) konur.

''Örneğin;''

''YANLIŞ: Kontrol paneli üzerinde bir ON/OFF anahtarı, bir START düğmesi ve bir STOP/TEST düğmesi bulunur.''

''DOĞRU: Kontrol paneli üzerinde:''

* ''Bir ON/OFF anahtarı''
* ''Bir START düğmesi''
* ''Bir STOP/TEST düğmesi bulunur.''

'''2.4 – Art arda gelen ve konu ile igili olan cümleleri bağlamak için bağlaçları kullan.'''

Art arda gelen ve konu ile ilintili olan cümleleri bağlamak için ayrıca, ama, fakat, aynı zamanda, bu nedenle vb. gibi bağlaçların kullanılması, cümleler arasındaki ilişkinin aktarılmasını kolaylaştırır.

''Örneğin;''

''Bu güvenlik önlemleri, yakıt tankında çalışabilmek için gereken minimum gereksinimlerdir. Ancak; işlem sırasında bulunulan bölge, ek önlemler alınmasını gerektirebilir.''

'''3 Yönergeler / Prosedürler'''

'''3.1 – Yönerge cümlelerini olabildiğince kısa tut (maksimum 20 kelime)'''

Yapılacak işlemlerde izlenecek talimatların açık ve net olması, kolayca anlaşılması gerekir. Bunu sağlamak için cümlelerin kısa tutulması önemli bir adımdır. Talimat içeren cümleler için maksimum uzunluk 20 kelime olarak belirlenmiştir.

''Örneğin;''

''YANLIŞ: Birim ön panel konnektörleri söküldükten sonra birimi platforma sabitleyen 8 adet vida, büyük boy yıldız tornavida kullanılarak sökülür.''

''DOĞRU: 1. Birim ön panel konnektörlerini sök.''

''2. Birimi platforma sabitleyen 8 adet vidayı, büyük boy yıldız tornavida kullanarak sök.''

'''3.2 – Bir cümlede yalnızca bir talimat ver.'''

Yönergelerin her bir adımda bir işlem anlatılacak şekilde yazılması, okuyucu için takip etmesi ve uygulaması kolay prosedürler oluşturur.

''Örneğin;''

''YANLIŞ: Birim ön panel konnektörleri söküldükten sonra birimi platforma sabitleyen 8 adet vida, büyük boy yıldız tornavida kullanılarak sökülür.''

''DOĞRU: 1. Birim ön panel konnektörlerini sök.''

''2. Birimi platforma sabitleyen 8 adet vidayı, büyük boy yıldız tornavida kullanarak sök.''

'''3.3 – Bir cümlede birden fazla talimatı yalnızca birden fazla işlemin aynı anda yapıldığı durumlarda ver.'''

Birden fazla işlemin aynı anda yapılması gereken durumlar olabilir. Bu durumlarda, talimatların aynı adımda verilmesi gerekir.

''Örneğin;''

''DOĞRU: Anahtarı TEST konumuna getir ve lambanın yandığından emin ol.''

'''3.4 – Talimatlarda, etken bir fiili 2. tekil kişinin emir kipinde kullan.'''

Talimat verilen cümlelerde, yapılacak işlemin emir kipi ile ifade edilmesi gerekir. Prosedürdeki işlemler, uygulayan kişinin tercihine bırakılmayan, yapılması şart olan adımlardır. Dolayısıyla yazım dilinin de bu zorunluluk durumunu ifade edebilmesi gerekir.

''Örneğin;''

''YANLIŞ: Montaj yüzeyi lifsiz bez ile kurulanır.''

''YANLIŞ: Montaj yüzeyi lifsiz bez ile kurulanmalıdır.''

''YANLIŞ: Montaj yüzeyini lifsiz bez ile kurulayın.''

''YANLIŞ: Montaj yüzeyini lifsiz bez ile kurulayınız.''

''DOĞRU: Montaj yüzeyini lifsiz bez ile kurula.''

'''3.5 – Talimatın başında betimleyici bir cümle geçiyorsa, bu cümleyi talimatın geri kalanından virgül ile ayır.'''

Bazı yönerge adımları komutla başlamayabilir. Zaman zaman, bir işlemden önce bazı şartların sağlanması gerekiyor olabilir. Bu durumda, beklenen bu şartı ifade etmek için betimleyici bir cümle ile yönergeye başlamak gerekebilir. Bu cümlenin, talimatın geri kalanından virgül ile ayrılarak vurgulanması gerekir.

''Örneğin;''

''DOĞRU: Işık yandığında, anahtarı NORMAL konumuna getir.''

''DOĞRU: Yüzey kuruyunca, bazı sür.''

''DOĞRU: Input ledi yeşil olarak yanıp sönünce, ana şalteri ON konumuna al.''

'''4 Betimleyici / Tanımlayıcı Anlatım'''

'''4.1 – Anlatım cümlelerini mümkün olduğunca kısa tut (maksimum 25 kelime).'''

Prosedür anlatımlarında 20 kelimeden uzun cümleler kullanılması tavsiye edilmezken betimleyici anlatımda 25 kelimeye kadar izin verilmektedir. Yine de çok uzun ve karmaşık yapılı cümleler kullanılmamalıdır.

'''4.2 – Metni dikkat çekici kılmak için farklı cümle uzunlukları ve yapıları kullanmaya çalış.'''

Peş peşe kısa cümlelerden oluşan bir metin sıkıcı olacak, sürekli uzun cümlelerin kullanılması ise takibi zor bir metin ortaya çıkaracaktır. Bu nedenle, betimleyici anlatım kısımlarında farklı cümle uzunlukları ve farklı cümle yapıları kullanılarak metin kolay okunur ve dikkat çekici hale getirilmelidir.

'''4.3 – Metnin mantığını gösterebilmek için paragrafları kullan.'''

Prosedür ve yönergelerde metin sıralı maddeler halinde verilir, böylece metnin akışındaki mantık okuyucu tarafından kolayca takip edilebilir. Anlatım kısımlarında ise bu görev, paragraflar tarafından yerine getirilir. Her bir paragraf, bir konu ile ilgili bilgiyi içeren ayrı bir birimdir ve diğer birimlerden (dolayısıyla diğer konulardan) aradaki beyaz satır boşluğu ile ayrılır.

'''4.4 – Her bir paragrafta yalnızca bir konudan bahset.'''

Bir paragrafta yalnızca bir konu anlatılmalıdır. Bir konu ile ilgili başlayan paragrafın devamında başka bir konuya geçilmemelidir. Ayrıca, paragrafta anlatılan konu uzunsa ve bir paragraf yeterli gelmeyecekse, konu bölünmeli ve her biri kendi paragrafında anlatılmalıdır.

'''4.5 – Paragrafa her zaman ana fikir cümlesi ile başla.'''

Bir paragrafın en önemli kısmı, ilk cümlesidir. Bu ilk cümle, okuyucuya paragrafın ne hakkında olduğunu söylemelidir. Okuyucu, sadece ana fikir cümlelerini okuyarak metnin genel hatlarıyla ne anlattığına hakim olabilmelidir. Okuyucu belli bir bilgiyi arıyor ise, ana fikir cümlelerini tarayarak istediği bilginin hangi paragrafta anlatıldığını bulabilmelidir. Ana fikir cümlesinden sonra gelen cümleler konuya ilişkin detayları ve ek bilgileri vermelidir. Her bir cümle kendinden önce gelenlerle mantıksal olarak bağlantılı olmalı ve kullanıcıya yeni bilgiler sunmalıdır.

'''4.6 – Bir paragrafın maksimum uzunluğu 6 cümledir. Tek cümlelik paragraf kullanacaksan, bunu 10 paragrafta 1 kereden daha sık yapma.'''

Uzun paragraflar, karmaşık bir konuyu anlatmanıza imkân sunar. Ancak kendi içinde anlaşılır ve tek konu hakkında olmalıdır. Bir konu ile ilgili başlayıp başka konulara geçen bir paragraf oluşturulmaması gerekir.

Kısa paragraflar bilgiyi basitleştirip bu bilgiyi okuyucuya hızla sunmanızı sağlar. Ancak peş peşe kısa paragraflar oluşturmak, konular arasındaki ilişkiyi tam verememenize neden olabilir. Bilgiler birbirinden kopuk olabilir.

İdeal olan, okuyucunun ilgisini çekebilmek için metin içerisinde farklı uzunluklarda paragraflar kullanılmasıdır.

'''5 Dikkat, Uyarı ve Notlar'''

'''5.1 – Dikkat ve uyarılara basit ve net bir talimatla başla.'''

Dikkat ve uyarılar, tehlikeden korunmak için ne yapılması ya da yapılmaması gerektiği konusunda basit ve net bir talimat ile başlamalıdır. Bu talimat, konu ile ilgili diğer bilgiler arasında kaybolup gitmemelidir. Önce talimat verilmeli, sonra gerekiyorsa ek bilgiler verilmelidir.

''Örneğin;''

''YANLIŞ:''

''DİKKAT''

''BU MOTORDA KULLANILAN SENTETİK YAĞDA, UZUN SÜRE CİLT İLE TEMAS ETMESİ DURUMUNDA EMİLİM İLE ZEHİRLENME DURUMU YARATABİLECEK MADDELER BULUNUR.''

''DOĞRU:''

''DİKKAT''

''MOTOR YAĞINI CİLDİNE TEMAS ETTİRME.''

''YAĞ ZEHİRLİDİR. CİLTTEN EMİLİP VÜCUDA KARIŞABİLİR.''

'''5.2 – Dikkat ve uyarı talimatlarında spesifik bilgi verdikten sonra, gerekiyorsa, muhtemel risk hakkında fikir vermek için dikkat ve uyarıya kısa bir açıklama ekle.'''

Verilen talimatın daha etkili olabilmesi için, talimata uyulmaması durumunda yaşanacak olumsuzluğun açıklanması gerekebilir. Bu durumda, talimattan sonra kısa bir açıklama eklenebilir.

Örneğin;

''UYARI''

''ANA ŞALTER İNDİRİLMEDEN ÖNCE YEŞİL LEDİN YANIYOR OLDUĞUNDAN EMİN OL.''

''YEŞİL LED YANMADAN ŞALTER İNDİRİLİRSE VİNÇ AKSAMI ZARAR GÖREBİLİR.''

'''5.3 – İşleme devam edilebilmesi için sağlanması gereken bir koşul varsa, bu koşulu dikkat ya da uyarı olarak önden ver.'''

Örneğin;

''UYARI''

''ANA ŞALTER İNDİRİLMEDEN ÖNCE YEŞİL LEDİN YANIYOR OLDUĞUNDAN EMİN OL.''

''YEŞİL LED YANMADAN ŞALTER İNDİRİLİRSE VİNÇ AKSAMI ZARAR GÖREBİLİR.''

'''5.4 – Notları talimat değil, bilgi vermek için yaz.'''

Not ifadeleri, özellikle vurgulanmak istenen bir bilgi olduğunda kullanılır. Not içerisinde kesinlikle talimat verilmemelidir.

'''6 Noktalama İşaretleri ve Kelime Sayıları'''

'''6.1 – Maddeli anlatımlar oluşturmak için (:) ve madde imi kullan (bknz. 2.3).'''

'''6.2 – Parantezleri:'''

* Görsele ya da metne çapraz referans yaparken
* Görselde ya da metinde bir şeyi tanımlayan harfleri ya da sayıları alıntılarken
* Virgülle ayırmanın yeterli gelmediği metinleri işaretlerken
* Asıl cümlenin bir parçası olmayan ama belirtilmesi gerekecek kadar önemli olan ifadeleri yazarken kullan.

'''6.3 – Cümle uzunluklarını tespit etmek için kelimeleri sayarken:'''

* Parantez içerisindeki metin ayrı bir cümle olarak sayılır.
* (:) ya da (-) nokta gibi düşünülür.
* Sayılar birer kelime olarak sayılır.
* Alfa numerik bir ifade bir kelime olarak sayılır.
* Kısaltmalar birer kelime olarak sayılır.
* Başlıklar, plakalar ve alıntılanan metinler birer kelime olarak sayılır. 

'''7 Dil Birliği ve Kelime Kullanımı'''

'''7.1 – Kabul görmüş Türkçe karşılığı olan tüm isimler için daima Türkçe kullan.'''

'''7.2 – Tüm teknik yayınlarda ortak olarak kullanılmasına karar verilen kelimeler konusunda özenli davran.'''

* “Cursor” yerine “İmleç”
* “Mouse” yerine “İmleç sürücü”
* “Spacebar” yerine “Boşluk tuşu”
* “Öge” yerine “bileşen”, “alt sistem”
* “Tüketim malzemesi” yerine “sarf malzeme”
* “Zorunlu sistem ögeleri” yerine “standart sistem birimleri/alt birimleri”
* “Yardımcı ögeler” yerine “destek ekipmanları”
* “Test kaynakları” yerine “test gereç ve yardımcıları”

'''DOKÜMANIN HAZIRLANMASINDA GÖREV ALAN KURUM/KURULUŞLAR'''

SAVUNMA SANAYİİ BAŞKANLIĞI

MİLLİ SAVUNMA BAKANLIĞI

* KARA KUVVETLERİ KOMUTANLIĞI

ASELSAN A.Ş.

FNSS SAVUNMA SİSTEMLERİ A.Ş.

HAVELSAN A.Ş.

ROKETSAN A.Ş.

SİMSOFT BİLGİSAYAR TEKNOLOJİLERİ LTD. ŞTİ./BİLTEN LTD.ŞTİ.

TÜRK HAVACILIK VE UZAY SANAYİİ A.Ş.

VİYA LOJİSTİK MÜHENDİSLİK VE BİLİŞİM TEKNOLOJİLERİ LTD.ŞTİ

Teknik Yayın Hazırlama Rehberi

2023-01-13T07:06:47Z

Oozdemir:

'''[https://tssodypwiki.ssb.gov.tr/images/d/dc/TSSODYP-12_Teknik_Yay%C4%B1n_Haz%C4%B1rlama_Rehberi_rev.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şkanlığı çatısı altında, ilgili tüm paydaşların katılımıyla faaliyet göstermek üzere Türk Savunma Sanayii Ömür Devri Yönetimi Platformu (TSSÖDYP) kurulmuştur.

TSSÖDYP; savunma ve güvenlik sistemlerine ilişkin ihtiyacın belirlenmesi, sistemlerin tedariki, kullanımı, desteklenmesi ve envanterden çıkarması safhalarını bir bütün halinde ele alan Sistem Ömür Devri Yönetimi ilke ve uygulamalarının ülkemizde yaygınlaştırılmasını ve savunma programlarının/ projelerinin yürütülmesinde savunma ve güvenlik ekosistemini oluşturan tüm paydaşlarca anlayış birliğine ulaşılmasını amaçlamaktadır.

Savunma sistemlerinin ömür devri yönetiminde millî bünyemize uygun, ülkemize özgü çözümler üretmek ve bunları dokümante etmek gibi önemli bir misyonu olan TSSÖDYP; Başkanlığımız, Milli Savunma Bakanlığı ve ilgili birimleri, Genelkurmay Başkanlığı, K.K.K.lığı, Dz.K.K.lığı, Hv.K.K.lığı, J.Gn.K.lığı, S.G.K.lığı, EGM, TÜBİTAK, SASAD ve savunma sanayii firmaları temsilcilerinin katılımı ile çalışmalarına devam etmektedir.

Sistem ömür devri yönetimi yaklaşımı ile; savunma ve güvenlik sistemlerine ilişkin ihtiyacın belirlenmesi aşamasından envanterden çıkarma safhasının sonuna kadar görev alan tüm kamu kurum ve kuruluşları ile özel sektör firmalarının sistemlerin istenilen performans seviyesinde mümkün olan en az maliyetle tedariki, kullanımı ve lojistik desteğinin sağlanabilmesi için görev, yetki ve sorumlulukları çerçevesinde ömür devrinin tamamında birlikte çalışmaları öngörülmektedir.

Bu itibarla, savunma ve güvenlik sistemlerine ilişkin ihtiyacın belirlenmesinin, tedarikinin, kullanımının, lojistik desteğinin ve envanterden çıkarılmasının en baştan uzun soluklu bir program olarak kurgulanmasının ve ilgili birimler aracılığı ile sistem ömür devri yönetimi faaliyetlerinin yürütülmesinin faydalı olacağı değerlendirilmektedir.

TSSÖDYP tarafından son iki buçuk yıl içinde gerçekleştirilen çalışmalar ile savunma ve güvenlik sistemlerinin ömür devri yönetimine ilişkin planlama ve uygulamaya esas olacak yaklaşımları ortaya koyan 13 adet rehber, iki adet bilgi kitapçığı ve bir adet terminoloji dokümanı hazırlanmıştır. Uygulamalardan alınacak geri bildirimler ile söz konusu dokümanların güncellenmesi, geliştirilmesi ve önümüzdeki dönemde uygulamaya esas düzenlemelerin alt yapısını oluşturması hedeflenmektedir.

TSSÖDYP çalışmalarına katkı veren ve dokümanların hazırlanmasında görev alan tüm paydaşlarımıza teşekkürlerimi sunuyorum.

Prof.Dr. İsmail DEMİR

T.C. Cumhurbaşkanlığı

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.

Bu nedenle, tedarik edilen sistemlerin kullanım döneminde hedeflenen muharebe ve/veya operasyon performansının sürdürülebilirliğinin ve maliyet etkinliğinin sağlanması amacıyla sistemlerin ömür devrinde rol ve sorumluluğu bulunan tüm paydaşların katılımı ile Sistem Ömür Devri Yönetimi yaklaşımı geliştirilmiştir.

Sistem Ömür Devri Yönetiminin temel amacı; mevcut durumdaki değişimlere uyum sağlamaktan ziyade gelecekte ortaya çıkabilecek değişimleri öngörmek, belirlenen hedefler doğrultusunda gerekli önlemleri alarak değişimleri yönlendirmek ve kontrol altında tutmaktır. Harekât ihtiyaçlarının zamanında ve verimli şekilde karşılanması ve sahip olunan kaynakların maliyet etkin kullanımı esastır. Başka bir deyişle, sistem ömür devri yönetimi geleceği bugünden tasarlamak ve planlamaktır.

Bu doküman; Savunma Sanayii Başkanlığı (SSB), Milli Savunma Bakanlığının ilgili birimleri, Türk Silahlı Kuvvetleri (TSK), diğer ihtiyaç makamları ve savunma sanayi firmalarında Sistem Ömür Devri Yönetimi’nin bir kültür olarak yaygınlaştırılmasına ve uygulanmasına yönelik rehber oluşturmak amacıyla savunma sistemlerinin ömür devrinde rol ve sorumluluğu bulunan ilgili paydaşların katılımıyla hazırlanmıştır.

Bir ürünün ömür devri boyunca etkin şekilde görev yapabilmesini destekleyen en önemli unsurlardan biri teknik yayınlardır. Teknik yayın; ürünün ömrü boyunca kurulum, işletim, bakım, onarım ve desteği için gerekli dokümanları (basılı veya elektronik ortamda) ve verileri kapsar.

Teknik yayın basılı veya elektronik ortamda bulunan bir doküman olmaktan çok günümüz koşullarında artık bir veri bütünü olarak görülmekte ve yönetilmektedir. Bu bakış açısıyla verilerin en etkin ve verimli şekilde yönetimi sağlanarak kullanıcının istediği zaman ve formatlarda basılı/elektronik doküman oluşturabilmesi daha kolay hale gelmiştir. Ayrıca teknik yayına veri bütünü gözüyle bakılarak, istenen bilgi ve detaylara günümüz bilgi yönetim sistemleri ve gelişen dijital teknolojileri kullanarak erişmek çok daha hızlı ve hatasız olabilmektedir.

Teknik yayın hazırlama rehberi, bu gelişmeler ve süreçler gözetilerek hazırlanmış; dünyada kabul görmüş teknik yayın standartları çerçevesinde ülkemiz ve savunma sanayiimizin gereksinimleri düşünülerek geliştirilmiştir. Ana hedef, savunma ve güvenlik alanında faaliyet gösteren tüm kullanıcıların ihtiyaçları doğrultusunda bilgi oluşturabilmek ve bilgiye en hızlı erişim, bilginin en etkin yönetimi ve standardizasyonun sağlanmasıdır.

= 1. GENEL =

== 1.1. GİRİŞ ==
Teknik yayın konusunda standart gereksinimlerin oluşturulması ile teknik yayın hazırlayan ve kullanan kurumların veya kuruluşların dışında, tedarik makamlarının da tedarik ve satın alma süreçlerinde hızlanma, standardizasyon ve rekabete açık bir ortam sağlayacaktır. Teknik yayınların layıkıyla hazırlanması ve kullanılması sonucunda sistemlerin istenilen performans seviyesinde en az maliyetle ömür devri boyunca kullanılabileceği değerlendirilmektedir.

== 1.2. AMAÇ ==
Teknik Yayın Hazırlama Rehberinin amacı, gerek teknik yayın hazırlayan kurumlara ve kuruluşlara, gerekse teknik yayını kullanan tüm paydaşlara rehber olmak ve teknik yayın konusundaki ister, beklenti ve yöntemleri açıklamaktır.

Teknik yayın gereksinimi ortaya çıktığında; tüm paydaşların aynı hususları algılamasını sağlamak, genel beklentiyi belirlemek ve teknik yayın hazırlanması için izlenecek yöntem ve kuralları ortaya koymaktır.

Bu rehberle teknik yayın hazırlayacak kurumların ve kuruluşların; neleri, nasıl ve hangi kaynaklarla hazırlaması gerektiğini en başından planlayabilmesini sağlamak ve teknik yayını kullanacak kurumların kendilerine nasıl bir doküman ulaşacağını en başından bilmesi ve bu hususları her yayın için standart olarak kabul etmelerini sağlamak hedeflenmiştir.

== 1.3. KAPSAM ==
Teknik Yayın Hazırlama Rehberinin kapsamı; teknik yayın ve verilerin planlanmasına, tasarımına, üretimine, geliştirilmesine, yönetimine, değişimine, dağıtımına, güncelleme takibine ve kullanımına yönelik süreçler, kurallar ve uygulamalardır.

Teknik yayına, bir ürünün işletme, bakım, onarım ve envanterden çıkarma dokümantasyonu ve verisi olarak bakıldığında; ilgili ürüne ait ve ömür devri boyunca işletme, bakım, onarım ve envanterden çıkarma için üretilecek tüm yayınlar ve veriler bu rehberin kapsamı içine girmektedir. Unutulmamalıdır ki Lojistik Destek Analizleri (LDA) sonuçları bu yayınların en önemli girdileridir.

Teknik Yayın Hazırlama Rehberinde, tasarım ve üretime yönelik hazırlanan dokümanlara (tasarım resimleri, CAD modelleri vb.) yer verilmemiştir.

== 1.4. REHBERİN KULLANIMI ==
Teknik Yayın Hazırlama Rehberi, beş bölüm ve üç ekten oluşmaktadır.

Birinci bölüm; giriş, 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.

İkinci bölüm, teknik yayın kavramı konusunda genel bilgi vermektedir. Teknik yayın süreci anlatılmakta ve teknik yayın ile lojistik destek analizleri arasındaki ilişkiler bu bölümde tanımlanmaktadır.

Üçüncü bölümde, teknik yayınların üretilmesi ve sonrasındaki süreçlerde uygulanacak iş kuralları açıklanmıştır. S1000D spesifikasyonu ile ilgili temel bilgiler verilmiştir. İş kurallarının sınıflandırılması, gereklilikleri, dokümante edilmesi, kontrol edilmesi gibi süreçler bu bölümde anlatılmıştır.

Dördüncü bölümde; iki ve üçüncü bölümlerde genel olarak anlatılan süreç ve standartların, karşılaşılan çeşitli projelerdeki isterlere göre uyarlanması detaylandırılmış ve her projenin kendine has özelliklerini dikkate alarak süreç ve standartların uyarlanmasında nasıl bir yol izlenmesi gerektiği anlatılmıştır. Basılı yayın ile etkileşimli elektronik teknik yayın (IETM/P) hazırlama arasındaki farklar ve uygulamalar bu bölümde belirtilmiştir.

Rehberin Ek-A’sında, tedarik makamları tarafından belirlenen/belirlenebilecek veya bir proje çerçevesinde yükleniciler tarafından cevaplanarak dokümante edilmesi beklenen İş Kurallarını listelemektedir.

Ek-B’de, örnek bir teknik yayın formatı şablonu tanımlanmıştır. Kapak, sayfa yapısı, uyarı, dikkat ve notların kullanımı, tabloların yapısı, referans verme kuralları, yol gösterici olması amacıyla bu bölümde örnek olarak verilmiştir. İşbu ek, örnek olması amacıyla hazırlanmış olup, bir proje çerçevesinde üçüncü bölümde ve Ek-A’da belirtilen İş Kuralları kararlarına göre değişiklik gösterebilir.

Ek-C’de, teknik yayın hazırlarken kullanılacak kelime, cümle, cümle yapısı gibi konularda öneri ve yol gösterici olabilecek örnekler verilmiştir.

== 1.5. REHBERİN GÜNCELLENMESİ ==
Rehber; ilgili paydaşların ihtiyacı doğrultusunda güncellenecektir. Değişiklikler, aşağıdaki Değişiklik İzleme Tablosu’ndan izlenecektir.

'''Tablo 1 Değişiklik İzleme Tablosu'''
{| class="wikitable"
|'''YAYIN NO'''
|'''YAYIN TARİHİ'''
|'''DEĞİŞİKLİK YAPILAN BÖLÜM/SAYFA'''
|'''AÇIKLAMA'''
|-
|01
|Ağustos 2021
|<nowiki>-</nowiki>
|İlk yayın
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|}

== 1.6. REFERANS DOKÜMANLAR ==
Teknik Yayın Hazırlama Rehberi’ne referans olan kaynaklar:
{| class="wikitable"
|'''DOKÜMAN NUMARASI'''
|'''DOKÜMAN AÇIKLAMA'''
|-
|'''Def Stan 00-60 (Part 10)'''
|Integrated Logistic Support Part 10: Electronic Documentation
|-
|'''MIL-HDBK-523'''
|Guide to The General Style and Format of S1000D Technical Manual Data Modules
|-
|'''MIL-PRF-38807C'''
|Technical Manuals- Illustrated Parts Breakdown (IPB)
|-
|'''MIL-STD-38784A'''
|DOD Standard Practice General Style And Format Requirements For Technical Manuals
|-
|'''S1000D'''
|International Specification for Technical Publications
|-
|'''S2000M'''
|International Specification for Material Management
|}

{| class="wikitable"
|+
! colspan="2" |'''TSSÖDYP DOKÜMAN SETİ'''
|-
|'''DOKÜMAN ADI '''
| '''DOKÜMAN KODU'''
|-
|Sistem Ömür Devri Yönetimi Rehberi (Ana Çerçeve)
|TSSÖDYP-01
|-
|Sistem Ömür Devri Yönetimi Süreçleri Rehberi
|TSSÖDYP-02
|-
|Ürün Destek Stratejileri ve Modelleri Rehberi
|TSSÖDYP-03
|-
|Entegre Lojistik Destek (ELD) Rehberi
|TSSÖDYP-04
|-
|Entegre Lojistik Destek (ELD) İsterleri Hazırlama Rehberi
| TSSÖDYP-05
|-
|Lojistik Destek Analizleri ve Kayıtları Rehberi
|TSSÖDYP-06
|-
|Tedarik Zinciri Yönetimi Rehberi
|TSSÖDYP-07
|-
|Sistem Ömür Devri Yönetiminde Demodelik Yönetimi Rehberi
|TSSÖDYP-08
|-
|Kullanım ve Destek İhtiyaçları Çerçevesinde Yerlileştirme/

Millîleştirme Rehberi
|TSSÖDYP-09
|-
|Kullanım ve Destek Safhaları Kalite Yönetimi Rehberi
|TSSÖDYP-10
|-
|Sistem Ömür Devri Yönetiminde Konfigürasyon Yönetimi Rehberi
|TSSÖDYP-11
|-
|Teknik Yayın Hazırlama Rehberi
|TSSÖDYP-12
|-
|Eğitim ve Eğitim İhtiyaçları Rehberi
|TSSÖDYP-13
|-
|Sistem Ömür Devri Yönetimi Terminolojisi
|TSSÖDYP-14
|-
|Kodlandırma ve Sınıflandırma Bilgi Kitapçığı
|TSSÖDYP-15
|-
|ASD/AIA S-Serisi ELD Spesifikasyonları Seti Tanıtım Kitapçığı
|TSSÖDYP-16
|}

== 1.7. KISALTMALAR VE TANIMLAR ==

=== 1.7.1. TANIMLAR ===
'''Tablo 2 Tanımlar'''
{| class="wikitable"
|'''TANIM'''
|'''AÇIKLAMA'''
|'''DİĞER KULLANIM'''
|-
|Bilgi Kümesi
|Bilgi kümesi, kararlaştırılan derinlik ve kapsama göre ihtiyaç duyulan bilgilerin (data modülü, görsel, multimedia, v.b.) CSDB içinde, sanal bir başlık altında yönetilmesidir. Bilgi seti olarak da adlandırılmaktadır.
|
|-
|İş Kuralı
Business Rule
|S1000D'nin ilgili bölümünün nasıl uygulanacağı konusunda proje veya organizasyon tarafından alınan karardır.
|
|-
|İş Kuralları Değişimi

Business Rules Exchange
|Bir projede uygulanacak iş kurallarının, belirli bir formata göre standart bir şekilde dokümante edilmesini ve proje kapsamında hazırlanacak olan veri modüllerinin hangi iş kurallarına göre yazıldığının tanımlanabilmesini ve denetlenebilmesini sağlamaya yarayan bir veri modülüdür.
|
|-
|İş Kuralları Karar Noktası

Business Rules Decision Point
|İş Kuralı Karar Noktası, iş kurallarının bir ID, başlık ve açıklama cümlesi ile tanımlanmış haline verilen isimdir.
|
|-
|Ortak Kaynak Veritabanı

Common Source Database
|Bir proje dahilinde teknik yayınları üretmek için gerekli olan tüm nesnelerden oluşan (veri modülleri, resimler, videolar vb.) veri deposudur.
|
|-
|Mevcut Veri
|İçerik olarak güncelliğini ve geçerliliğini koruyan ancak format ve yapı itibari ile S1000D uyumlu olmayan (kağıt baskı, S1000D’den farklı diğer formatlar vb.) verilerdir.
|
|-
|Paylaşılabilir İçerik Nesnesi Referans Modeli

Sharable Content Object Reference Model
|SCORM; eğitim içeriklerinin donanım veya işletim sistemi farklılıklarından etkilenmeden kullanılabildiği, her Web tarayıcı ortamında işletilebildiği, ihtiyaç duyulan her an ilgili içeriklere erişimin mümkün kılındığı ve içeriklerin tekrar kullanılabilirliğinin sağlandığı, içerik paylaşımına dair referans modelin tanımlandığı bir standarttır.
|
|-
|Sistem
|Fonksiyonel olarak farklı görevleri yerine getirebilen, bir veya birden fazla fiziksel parçadan meydana gelen yazılım veya donanımdır.
|
|-
|Şema
|Veri modüllerinin hazırlanmasında kullanılan, XML formatında olan ve farklı kullanım alanlarına göre özelleştirilmiş veri alanlarına sahip şablonlardır.
|
|-
|Teknik Yayın
Technical Publication
|Ürünün ömrü boyunca kurulum, işletim, bakım, onarım ve desteği için gerekli dokümanlar (basılı veya elektronik ortamda) ve verilerdir.
|
|-
|Ürün
Product
|Yüklenici tarafından, sözleşme kapsamında tedarik makamına teslim edilecek ve her bir sözleşme değişikliği için Kabul’e Esas Ürün ve Hizmetler Listesi başlıklı lahikalarında belirtilen kalemler ve bunlara ilişkin tüm sistem, donanım, yazılım ve dokümanlardır. Bu kalemler kara, deniz, hava araçları, platformlar, silah, sistem, yazılım ve bunlara ilişkin tüm destek donanım ve yazılımlarını içerebilir.
|
|-
|Veri Modülü

Data Module
|Ürün ve destek ekipmanının tanımı, çalışması, parçalarının belirlenmesi veya bakımı için gerekli bilgileri içeren bağımsız veri birimi. Veri birimi, tanımlama ve durum bölümü ile içerik bölümünden oluşur.
|
|}

=== 1.7.2. KISALTMALAR ===
'''Tablo 3 Kısaltmalar'''
{| class="wikitable"
|'''Kısaltma'''
|'''Açık Yazımı'''
|'''Diğer Kullanım'''
|-
|ARGE

R&D
|Araştırma-Geliştirme

Research-Development
|
|-
|BRDP
|İş Kuralları Karar Noktası

Business Rules Decision Point
|
|-
|BREX
|İş Kuralları Değişimi

Business Rules Exchange
|
|-
|CAD
|Bilgisayar Destekli Tasarım

Computer Aided Design
|
|-
|CIR
|Ortak Bilgi Havuzu

Common Information Repository
|
|-
|CSDB
|Ortak Kaynak Veritabanı

Common Source Database
|
|-
|DMC
|Veri Modülü Kodu

Data Module Code
|
|-
|EETD/Y

IETM/P
|Etkileşimli Elektronik Teknik Doküman/Yayın

Interactive Electronic Technical Manual/Publication
|
|-
|ELD

ILS
|Entegre Lojistik Destek

Integrated Logistics Support
|
|-
|GMB

RCM
|Güvenilirlik Merkezli Bakım

Reliability Centered Maintenance
|
|-
|HTML
|Hiper Metin İşaret Dili

Hypertext Markup Langauge
|
|-
|ICN
|Bilgi Kontrol Numarası

Information Control Number
|
|-
|IPB/IPC/IPD
|Resimli Parça Kırılımı/Katalogu/Veri

Illustrated Parts Breakdown/Catalog/Data
|
|-
|OSA

LORA
|Onarım Seviyesi Analizi

Level of Repair Analysis
|
|-
|Pdf
|Taşınabilir Doküman Formatı

Portable Document Format
|
|-
|PM
|Yayın Modülü

Publication Module
|
|-
|PMC
|Yayın Modül Kodu

Publication Module Code
|
|-
|PYP
|Proje Yönetim Planı
|
|-
|RAHAT

COTS
|Rafta Hazır Ticari Ürün

Commercially off the Shelf Item
|Raf Ürünü
|-
|SCORM
|Paylaşılabilir İçerik Nesnesi Referans Modeli

Shareable Content Object Reference Model 
|
|-
|SNS
|Standard Numbering Sytem

(S1000D spesifikasyonunda, ürünün referans edilmesinde standardizasyonu sağlayan numaralama sistemidir)
|
|-
|SVİL/DVİL
|Sözleşme Veri İsterleri Listesi

Doküman Veri İsterleri Listesi
|
|-
|TY
|Teknik Yayın
|
|-
|TYP
|Teknik Yayın Planı
|
|}

== 1.8. TABLOLAR ve ŞEKİLLER ==

=== 1.8.1. TABLOLAR ===
Tablo 1 Değişiklik İzleme Tablosu

Tablo 2 Tanımlar

Tablo 3 Kısaltmalar

=== 1.8.2. ŞEKİLLER ===
Şekil 1 Teknik Yayın Üretim Mimarisi

Şekil 2 Veri Modül Kod Yapısı

Şekil 3 Örnek ICN Yapısı

Şekil 4 Yayın Modülü Kodlama Yapısı

Şekil 5 İş Kuralı Kategorileri

Şekil 6 Katmanlı Yapı

Şekil 7: Örnek Katmanlı Yapı

Şekil 8 İş Kuralı Kategorilerinin Belirlenmesi

Şekil 9 Kapak Sayfası (Örnek)

Şekil 10 Değişiklik İzleme Tablosu (Örnek)

Şekil 11 İçindekiler Listesi (Örnek)

Şekil 12 Şekiller Listesi (Örnek)

Şekil 13 Tablolar Listesi (Örnek)

Şekil 14 Kısaltmalar Tablosu (Örnek)

Şekil 15 Tanımlar Tablosu (Örnek)

Şekil 16 Semboller Listesi Tablosu (Örnek)

Şekil 17 Referans Dokümanlar Tablosu (Örnek)

Şekil 18 İlgili Dokümanlar Tablosu (Örnek)

Şekil 19 Başlıklar (Örnek)

Şekil 20 Tablo (Örnek)

Şekil 21 Şekil (Örnek)

Şekil 22 Teknik Yayın Cilt/Klasör (Örnek)

= 2. TEKNİK YAYIN ve SÜREÇLERİ =

== 2.1. TEKNİK YAYIN NEDİR? ==
Teknik Yayın çok genel anlamı ile tanımlayıcı bilgi ve talimatlar olup; ürünün ömrü boyunca kurulum, işletim, bakım, onarım ve desteği için gerekli doküman (basılı veya elektronik ortamda) ve veri olarak tanımlanabilir. Teknik yayınlar; talimat, el kitabı, katalog, prosedür, bülten, broşür, web sayfası, vb. şekilde hazırlanabilir. Ancak bunlarla sınırlı değildir.

== 2.2. TEKNİK YAYIN SÜRECİ ==
Teknik Yayın (TY) üretim süreci genel olarak üç ana aşamadan oluşmaktadır;

* Planlama
* Üretim ve Doğrulama
* Yayım / Teslimat

Teknik Yayın üretim süreci S1000D bölümleri ile olan ilişkilerini de içerecek şekilde Şekil 1’de verilmiştir.
[[Dosya:Şekil1 Teknik Yayın Üretim Mimarisi.jpg|alt=Şekil 1 Teknik Yayın Üretim Mimarisi|sol|küçükresim|500x500pik|Şekil 1 Teknik Yayın Üretim '''Mimarisi''']]

=== 2.2.1. PLANLAMA AŞAMASI ===

==== <big>2.2.1.1. TY PLANININ HAZIRLANMASI</big> ====
Sistem ömür devri yönetimi uygulamaları kapsamında tedarik makamı tarafından yürütülen sözleşmeler ile talep edilen TY listesini SVİL’de, TY’ye ilişkin gereksinimleri ise Teknik Şartname, ELD Planı, TY Gereksinimleri Dokümanı gibi ilgili tanımlama dokümanlarında belirtir.

Üretici sözleşmede yer alan TY gereksinimlerine uygun olarak TY Planı (TYP) hazırlar. TYP proje kapsamında TY’ye yönelik yürütülecek planlama, üretim ve yayım faaliyetlerini tanımlar. TYP bunlarla sınırlı olmayıp aşağıdaki temel bilgileri içermelidir:

* Proje ve ürün tanımında ürüne ilişkin genel bilgiler ile ürün geliştirme programına yönelik bilgiler bulunmalıdır. (TY üretimini etkileyebilecek proje kısıtları ve kabullerine özellikle yer verilmelidir)
* Teslimat kalemleriyle ilgili oluşturulacak TY isimleri, kısa tanımları (kapsam, hedef kitle vb.), yayım yöntemleri (basılı, pdf, HTML vb.), gizlilik dereceleri gibi hususlara ve miktarlarına yer verilmelidir.
* Takvime ilişkin; her bir teslimat kalemi için ana iş kalemleri ve aşamaları başlangıç ve bitiş tarihleri ile belirtilir.
* Standartlar ve kurallar kapsamında; TY üretiminde kullanılacak referans dokümanlar (standart, rehber, biçim kılavuzları vb.) belirtilir.
* Tedarik makamınca sağlanacaklar; TY üretimine ilişkin Üreticiye sağlanacak doküman, cihaz vb. içerir.
* Kabuller; TY doğrulama ve kabul yöntemlerine ilişkin genel bilgileri içerir.
* Telif hakları; TY telif haklarının (yayım, kopyalama, değiştirme vb.) kime ait olduğu belirtilmelidir

TYP’nin Tedarik Makamı/Kullanıcı ile paylaşımı, TY sürecinin sağlıklı yürümesi için tüm taraflar açısından önemlidir. Bazı projelerde TYP’nin kendisi teslimat kalemidir. Ancak TYP’nin teslimat kalemi olmadığı durumlarda, TYP’deki bilgiler ELD Planında ya da Proje Yönetim Planı (PYP) gibi üst dokümanlarla Tedarik Makamı/Kullanıcıya ulaştırılmalıdır.

==== <big>2.2.1.2. ŞABLON VE KURALLARIN BELİRLENMESİ</big> ====
TY Listesinde yer alan her bir doküman için şablon ve kurallar (iş kuralları) belirlenir.

TY Şablonu; dokümanda yer alacak bölümler (dış kapak, iç kapak, değişiklik takip, uyarılar, içindekiler, bölümler, kısımlar, paragraflar, indeks, arka kapak gibi bölümler) kullanılacak biçimler, görsellerin kullanımı gibi dokümanın içeriği ve genel yapısı hakkında bilgi veren dokümanlardır. TY Şablonu, TY’leri hazırlayacak ekibi yönlendirmekle birlikte Kullanıcı/Tedarik Makamının erken aşamada TY’ye ilişkin görüş ve önerilerini almak için kullanılır.

TY Şablonu, TY Planında belirtilen standart ve kurallara uyumlu şekilde hazırlanır. TY Şablonu belirlenirken, var ise Kullanıcı/Tedarik Makamının belirlediği şablon ve kurallardan, genel biçim kılavuzlarından ve bu dokümanda referans bölümünde yer alan standartlardan faydalanılır.

TY hazırlanırken kullanılacak genel kurallar TY Planında belirtilmiş olmalıdır. TY Planında belirtilen kurallar burada detaylandırılır. Kurallara ilişkin detaylar Bölüm 3 içinde açıklanmıştır.

TY Listesinde yer alan her bir doküman için teknik yayın numarası belirlenmiş olmalıdır. TY numarası Kullanıcı/Tedarik Makamı tarafından belirlenen yönteme uygun olarak belirlenir ve dokümante edilir.

==== <big>2.2.1.3. ANA HATLARIN BELİRLENMESİ</big> ====
Ana hat, her bir teknik yayın kapsamında yer alacak olan konu başlıklarını içeren dokümandır. Bu yönüyle ana hatlar teknik yayının iskeleti olarak değerlendirilebilir. Detaylı ve kapsamlı bir ana hattın hazırlanması, ürünün kullanımı ve idamesine ilişkin tüm bilginin TY’de yer almasını sağlamak için vazgeçilmezdir.

Ana hat, TY'nin içeriğini hiyerarşik bir yapıda bütüncül olarak sunar;
[[Dosya:Şekil Doküman Bölüm.jpg|sol|küçükresim|400x400pik]]

TY sürecinin erken aşamalarında (planlama aşamasında) tamamlanması gereken ana hattı oluşturmak için, ürün ve mevcut ise benzer ürünlere ilişkin mevcut dokümanları (teknik tanımlama, tasarım, üretim, ELD dokümanları gibi) incelemek ve analiz etmek gerekir. Ürüne ilişkin azami bilgi edindikten sonra belirlenmiş olan standart içerik var ise buna uygun olarak TY kullanıcısına (hedef kitleye) aktarılması gereken konu başlıkları belirlenir.

Ana hatların Tedarik Makamı/Kullanıcı onayına sunulması önemlidir. Bu sayede, henüz başlangıç aşamasında, Tedarik Makamı/Kullanıcının TY süreci ve çıktıları hakkında bilgi sahibi olması sağlanmış ve görüşleri alınmış olunur.

=== 2.2.2. ÜRETIM VE DOĞRULAMA AŞAMASI ===

==== <big>2.2.2.1. İÇERİKLERİN GELİŞTİRİLMESİ</big> ====
Ana hatta yer alan her bir başlık (paragraf) LDA çıktıları ve ürün dokümanları (tanımlama, tasarım, üretim dokümanları gibi) kullanılarak oluşturulur. TY’de temelde dört tür bilgi yer alır. Bunlar; arayüz, kavramsal, talimat ve referans bilgileridir.

'''Arayüz bilgileri''', ürünü ve işlevlerini açıklayan bilgilerdir. Donanım için arayüz bilgisi genellikle fotoğraf veya çizim şeklindedir (örneğin patlatılmış görüntüler (exploded views)). Yazılım için ise genellikle bağlama duyarlı yardım (help) kullanılır (örneğin elektronik etiketler (tooltips)).

Arayüz bilgilerini oluşturmak için daha çok tanımlama ve tasarım dokümanlarından, mevcut ise de prototip ürünlerden faydalanılır. TY'de yer alan görseller fotoğraf ya da 2D/3D yani iki ya da üç boyutlu teknik çizimler kullanılarak üretilir.

'''Kavramsal bilgiler;''' ürünün bir özelliğinin arkasındaki ‘niçin’ sorusuna cevap verir ki bu okuyucunun konuyu anlaması ve pekiştirmesi için gereklidir çünkü kavramsal bilgiler TY'yi bir arada tutan yapıştırıcı gibidirler, kavramsal bilgiler olmadan TY sadece bir adımlar listesidir. Kavramsal bilgilere genel olarak TY'nin giriş bölümlerinde yer verilir ve kavramsal bilgileri oluşturmak için tanımlama ve tasarım dokümanlarından faydalanılır.

'''Talimat bilgileri;''' bir işin nasıl yapılacağını adım adım açıklayan iş odaklı bilgilerdir (örn. kullanım ve bakım ve onarım talimatları). TY'lerin büyük bölümü ürünün nasıl kullanılacağı ya da bakım ve onarımının nasıl yapılacağını içeren talimat bilgilerinden oluşur. Talimat bilgilerini oluşturmak için LDA, test ve üretim dokümanlarından, mevcut ise prototip ürünlerden faydalanılır.

'''Referans bilgileri;''' okuyucuların ihtiyaç duyduklarında erişmeleri üzerine sunulan bilgilerdir (örn: sözlük, kısaltmalar listesi. vb.). Sözlük bu kategoriye en iyi örnektir. Referans bilgileri oluşturmak için tasarım dokümanları ve ilgili referans dokümanlardan (standartlar vb.) faydalanılır.

==== <big>2.2.2.2. TY ÜRETİMİ (İLK TASLAK)</big> ====
İçerik üretim ve yayım ortamının farklı olduğu durumlarda içerikler (bilgi kümeleri) ana hat ve şablona uygun olarak yayım ortamına aktarılır. İçerik yazımı ve yayım için MS Word ve Adobe Frame Maker gibi yaygın kullanılan yazımlar olmakla birlikte büyük projelerde kurumsal düzeyde (tasarım, üretim gibi diğer süreçlerle entegre çalışan) yazım ve yayım yazılımları mevcuttur. S1000D standardında içerik yazımı için S1000D uyumlu editörler kullanılır.

İçeriklerin yayım ortamında birbirine entegre edilmesi ile ilk taslak TY hazırlanmış olur. İlk taslak TY, Üretici bünyesinde kontrol için gözden geçirmeye çıkarılır. Bu aşamada;

* Tasarım ekibi ve konu uzmanları içeriği teknik olarak kontrol eder.
* Eş düzey teknik yazarlar TY'yi şekil, düzen ve bütünlük açısından değerlendirir.
* S1000D uyumlu yayınlar, BREX veri modülü vasıtası ile iş kuralları açısından kalite kontrol sürecine tabi tutulur.
* Tespit edilen hatalar ve eksiklikler gözden geçirme ekibince karara bağlanıp giderildikten sonra ilk taslak sürüm hazır hale gelir.

==== <big>2.2.2.3. EDİTÖR KONTROLÜ (ARA TASLAK)</big> ====
İlk taslak TY, üretici bünyesinde editör kontrolüne sunulur. Editörler mevcut TY'yi aşağıdaki kontrollerden geçirir;

* Şablon ve biçimlere uygunluk,
* Terminoloji bütünlüğü,
* Yazım ve dil bilgisi kurallarına uygunluk,
* Bilgilerin açık ve anlaşılır olması,
* İçeriğin tam, tutarlı ve iyi düzenlenmiş olması,
* Baskı ve yayıma uygunluğu,
* İş kurallarına uygunluk.

Tespit edilen hususlar gözden geçirme ekibince değerlendirilerek TY'ye yansıtılır. Böylece ara taslak sürüm TY doğrulama için hazırdır.

==== <big>2.2.2.4. DOĞRULAMA (SON TASLAK)</big> ====
TY'nin yeterliliği ve doğruluğu, ürün ile uyumu Üretici sorumluluğundadır. Üretici, Tedarik Makamı/Kullanıcı ile yapacağı doğrulamayı önce kendi bünyesinde gerçekleştirerek hazırlıkları tamamlar, sonrasında doğrulamayı Tedarik Makamı/Kullanıcı ile gerçekleştirir.

Doğrulama için ürün geliştirme süreci ve LDA'nın ilgili görevleri tamamlanmış olmalıdır. TY'de yer alan tüm bilgiler;

* Mümkün olduğunca son ürün ya da üretim prototipi üzerinde uygulama ve gözlem ile doğrulanır,
* Mümkün olmadığında ise LDA kapsamında gerçekleştirilen bakım görevleri analizi ve çıktıları kullanılarak doğrulanır.

Doğrulama aşamasında tespit edilen hata ve eksiklikler Üretici tarafından TY'ye yansıtılır.

=== 2.2.3. YAYIM/TESLIMAT ===

==== <big>2.2.3.1. DOKÜMANLARIN ONAYLANMASI VE YAYIMLANMASI</big> ====
Doğrulaması yapılmış TY’lerin basım kontrolleri, aşağıda verilen denetimleri içerecek şekilde baskı öncesinde Üretici tarafından yapılır;

* Şablona uygunluk,
* Sağ ve sol sayfa düzeni,
* Sayfa sonu ve sayfalarda metin uzunluğu dengesi,
* Sayfa sonunda cümle bölünmesinin olmaması,
* Başlıklar ve altlıklar,
* Şekil ve tablo numaralandırmaları,
* Çapraz referans uyumu (linkler, bkz., dipnot vb.),
* Kapak, iç kapak, şekil listesi, tablo listesi, içindekiler, indeks vb. doğruluğu.

Denetim sonrası TY'ler genelde PDF formatına dönüştürülerek basıma hazır hale getirilir.

Denetimi tamamlanmış TY’ler Son Taslak olarak Tedarik Makamı/Kullanıcı onayına sunulur. TY’ler, TY Planı ve sözleşmeye uygun olarak Tedarik Makamı/Kullanıcı tarafından kontrol edilir. Tedarik Makamı/Kullanıcı tespitleri Üretici ile birlikte değerlendirilir ve TY’lere uygulanacak değişiklikler belirlenir. Üretici bu değişiklikleri TY’lere uygular ve TY’leri tekrar onaya sunar.

Onaylanan TY'ler, doküman planında belirtildiği şekilde ve miktarda basılı ve/veya elektronik ortamda ilk sürüm TY olarak hazır edilir.

Elektronik ortamda yayımlanacak dokümanlar (IETM/P) ve veri modülleri, uygun yazım ve yayım araçları ile xml, html vb. yapıda yayımlanır.

==== <big>2.2.3.2. DEĞİŞİKLİK YÖNETİMİ</big> ====
Yayım sonrasında özellikle teknolojik yenilikler nedeniyle üründe yapılan değişikliklerin TY’lere yansıtılması, dokümanda tespit edilen hatalar var ise bunların giderilmesi gerekir.

Yayımlanan TY’lere ilişkin değişiklikler, ilgili proje/sözleşmenin Konfigürasyon Yönetim Planına uygun olarak yönetilmelidir. Uygulanacak değişiklikler “2.2.2 Üretim ve Doğrulama Aşaması” ile “2.2.3 Yayım/Teslimat” bölümlerinde açıklanan süreçlere uygun olarak yürütülür. Değişiklikler TY’lerde yer alan Değişiklik Çizelgelerine işlenir, TY’lerin sürüm tarihi ve numarası revize edilir. Yeni sürüm TY’ler Tedarik Makamı/Kullanıcılara yayımlanır.

Savunma ve güvenlik ürünlerinin ömrünün uzun olduğu değerlendirildiğinde TY’lerin güncellenmesi, ürün ile uyumunun sağlanması ayrı bir önem arz eder. Bu nedenle TY güncellemelerine ürün destek stratejilerinde yer verilmiş olmalıdır.

== 2.3. LOJİSTİK DESTEK ANALİZLERİ (LDA) ==
Lojistik Destek Analizleri; lojistik destek faaliyetlerinin maliyet etkin olarak yürütülmesinde yol gösterici en önemli faaliyettir. Tüm lojistik destek faaliyetlerinin teknik disiplin içinde maliyet etkin olarak planlanması, koordine edilmesi ve yönetilmesi için LDA rehberliğinde;

* Ürün ve destek unsurları; desteklenebilirlik, güvenilirlik, test edilebilirlik ve uygun ömür devri maliyeti ile tasarlanır.
* Kullanım ve Destek Safhaları boyunca ürünün istenilen performans seviyesinde kullanılabilmesi için ihtiyaç duyulan kaynaklar tanımlanır.
* ELD elemanlarına ilişkin esas bilgiler oluşturulur.

Sistem ömür devri boyunca olası darboğazların öngörülmesi, bahse konu darboğazların bertaraf edilmesine yönelik önleyici planların oluşturulması ve oluşturulan önleyici planların iyileştirilmesi, geliştirilmesi ve yönetilmesi amacıyla Lojistik Destek Analizleri tekrarlamalı olarak yürütülür.(Bkz. [https://tssodypwiki.ssb.gov.tr/index.php/Lojistik_Destek_Analizleri_ve_Kay%C4%B1tlar%C4%B1_Rehberi TSSÖDYP-06 LDA ve Kayıtları Rehberi])

=== 2.3.1. TEKNIK YAYIN VE LDA ARASINDAKI İLIŞKILER ===
Lojistik Destek Analizi temelde ürünün desteği için gerekli kaynakların tanımlanması ve destek maliyetini düşürmek için tasarımı etkilemek amacıyla yapıldığı dikkate alındığında, teknik yayının içereceği bakım ve onarım bilgilerinin oluşturulması faaliyetlerinde LDA çıktıları önemli bir girdi oluşturacaktır.

Teknik doküman yazımına esas olacak LDA temelde son kullanıcı gereksinimleri, mühendislik çizimleri, mühendislik spesifikasyonları, idame edilebilirlik ve desteklenebilirlik verisi, üretici verileri gibi kaynakları esas alır.

Teknik yayınlar açısından, LDA çıktılarının en önemlileri aşağıda listelenmiştir;

* LDA Aday Kalem Listesi (Candidate Item List),
* Bakım Görev Analizi (Maintenance Task Analysis),
* Planlı Bakım Analizi (Scheduled Maintenence Analysis),
* Onarım Seviyesi Analizi (Level of Repair Analysis),
* Bakım Tahsis Çizelgesi (Maintenance Allocation Chart).

=== 2.3.2. LDA ADAY KALEM LISTESI ===
Lojistik Destek Analizi faaliyetleri arasında yer alan LDA adaylarının belirlenmesi süreci, teknik yayınlardaki bakım ve onarım görevlerinde ve resimli parça kataloğunda yer alacak, yani bakım faaliyetlerinde bulunulacak kalemlerin belirlenmesi için temel teşkil eder. LDA faaliyetleri belirlenen bu adaylar için yürütülür ve LDA aday kalem listesinde yer alır.

=== 2.3.3. BAKIM GÖREV ANALİZİ ===
Yürütülen LDA faaliyetleri arasında teknik yayınlar ile en çok ilgili olanı Bakım Görev Analizi’dir. LDA ve ilgili diğer analizler (RCM vb.) sonucu belirlenen planlı/plansız bakım görevlerine ait ihtiyaçlar, LDA sürecinin en temel analizlerinden olan Bakım Görev Analizi (MTA) ile belirlenmektedir. MTA sürecinde ilk olarak bakım ve onarım görevinin anlaşılırlığının arttırılıp görevin yürütülmesi sürecini kolaylaştırmak için görev alt görevlere ve adımlara ayrılır. Görevin öncesinde ve sonrasında yürütülmesi gereken faaliyetler belirlenir. Bakım görevinin yürütülmesi için gereken lojistik ihtiyaçlar (yedekler, personel, destek ve test ekipmanları, tesis, vb.) belirlenir.

Sökme, takma, test, arıza bulma/giderme, vb. bakım görevlerine ait teknik yayınlar hazırlanırken MTA çıktıları kullanılmaktadır. Bu analizin çıktıları çoğu zaman doğrudan kullanılamaz. Bilhassa prosedürlerin içerikleri konusunda MTA çıktıları ile teknik yayınlar arasında farklar yer almaktadır. Bu farklar prosedürlerin teknik olarak içeriğinin değiştirilmesinden ziyade prosedürün ifade ediliş tarzının değiştirilmesi şeklindedir.

MTA çıktısı olarak hazırlanan prosedürde adımlar, süreci anlatacak detayda olmakla birlikte bu detay bir teknik yayın çıktısı ile kıyaslandığında yetersizdir. Teknik yayınlar standartları gereği birçok kurala tabidirler. Teknik yayın hazırlanma sürecinde MTA çıktılarının prosedürel kısımları ilgili teknik yayın standardına uygun olarak tekrar ifade edilir. Bu aşamada adımlar sadeleştirilip sayıları arttırılabilir, kullanılan kelimelerde değişiklikler yapılabilir. MTA çıktılarından yedekler, sarf malzemeleri, test/destek ekipmanları da yine ilgili teknik yayın standardına uygun olarak, teknik yayın içerisinde yerini alır.

=== 2.3.4. PLANLI BAKIM ANALİZİ ===
Planlı bakım görevlerinin belirleneceği analizlerin sonucunda;

* Planlı bakım görevleri ve aralıkları tanımlanır.
* Tanımlanan görevler Lojistik Destek Analizi (LDA) sürecinde detaylandırılır.

İdame edilebilirlik çalışmaları sürecinde değerlendirilen lojistik gereksinimler, LDA içinde yer alır ve uyuşmazlık gösteren durumlar tasarım birimlerine bildirilerek gerekli önlemlerin alınması doğrultusunda, ürünün desteklenebilirliği ve idame edilebilirliği takip edilir.

Tanımlanan planlı bakımlar; bakım aralıkları, personel, bakım süreleri, destek ekipman gereksinimleri ve bakımda kullanılan malzemeler vb. veriler doğrultusunda değerlendirilir ve ilgili bakımın yapılacağı yer, zaman ve düzeltici bakım görevleri tanımlanır.

Ayrıca MTA sürecinde tanımlanan bakım görevleri sırasında ihtiyaç duyulacak destek ekipmanları ve altyapı gereksinimleri için olması gereken özellikler de belirlenir.

Analiz çıktıları, Bakım Planlama dokümanı, Bakım El Kitabı ve/veya Veri Modülü (Data Module) içinde yer almak üzere, Teknik Yayın sorumlusuna iletilir.

=== 2.3.5. ONARIM SEVİYESİ ANALİZİ ===
Onarım seviyesi analizi (LORA) ile bakım adayı parçalar için, bakım planının sınırları ve LORA aday parçalarının bakım ve onarımı için en düşük işletim ve destek maliyeti belirlenir.

LORA ihtiyaç makamının operasyon senaryolarına uyumlu, maliyet etkin ve yararlı bir bakım konsepti oluşturmak için her bir aday parçaya mantıklı bir onarım seviyesi belirleme analizi yapılarak gerçekleştirilir. LORA süreci genel olarak iki aşamadan oluşur. Birincisi, arızalı parçanın onarılabilir mi ya da elden çıkarılabilir mi olduğu kararının verilmesi, ikincisi ise, onarılabilir olma durumuna karar verilen parçaların hangi bakım seviyesinde onarılacağı kararının verilmesidir. Ekonomik olmayan değerler karar aşamasında etkili olmadığı takdirde, sınırlı sayıda ekonomik faktör de değerlendirmeye dâhil edilebilir. Bu sınırlı sayıdaki ekonomik faktörler, analizi genişletmek ve ömür devri maliyetini düşürmek için dikkate alınmalıdır.

LORA, LDA süreci ile iç içe geçmiş bir süreçtir ve analizler çalışma saatleri, bakım işlemleri oranı, bakım zamanları, bakım aletleri ve bakım maliyeti ile ekonomik olmayan faktörler (bakım personeli meslek ve beceri gereksinimleri) gibi operasyonel ve destek faktörlerinin değerlendirmeleri tekrarlanarak yapılır. LDA’nın bir parçası olarak LORA sürecinde LDA sonuçları kullanılır ve sonrasında Lojistik Destek Analiz Kayıt sonuçları girdi oluşturur.

LORA’nın en önemli çıktısı olan Kaynak, Bakım/Onarım ve Geri Kazanım (SM&R) Kodu, doğrudan bakım ve onarım ile ilişkili olup Lojistik Destek Analiz Kaydı veri tabanında tutulmalıdır. SM&R kodu aday parçaya uygulanabilecek bakım ve onarım faaliyetlerini sistematik olarak betimlemek için kullanılan bir koddur.

=== 2.3.6. BAKIM TAHSİS ÇİZELGESİ ===
LDA süreçlerinde belirlenen tüm bakım görevleri belirlenen formatta ve belirlenen bakım seviyeleri için; lojistik kırılım bilgilerini, bakım türünü, bakım süresini, gerekli destek ekipmanı gibi bilgileri içerecek şekilde Bakım Tahsis Çizelgesi sunulur.

Bakım Tahsis Çizelgeleri, bakım ve onarıma yönelik olarak hazırlanan teknik yayında yer alan görevlerin ilgili bakım kademesine uygun olarak seçilmesinde kullanılır.

== 2.4. ORTAK BİLGİ HAVUZU ==
Ortak Bilgi Havuzu konsepti, bir proje çerçevesinde veya kurum içindeki her projede ortak olarak kullanılacak bilgileri (doküman, talimat, LDA kayıtları, figür, multimedya öğeler vb.) bir havuzda toplamak ve kullanıcıların bu havuzdan faydalanarak gereken dokümanları üretmelerini sağlamak üzere ortaya konmuştur.

Ortak Bilgi Havuzuna toplanacak bilgilere örnek olarak dikkat ve uyarılar, malzeme bilgileri, destek ekipmanları sayılabilir.

Ortak Bilgi Havuzu oluşturup yönetilerek;

* Kurumda üretilmiş her dokümanda aynı kavram ve bilgiler kullanılarak tutarlılık sağlanır.
* Hatalı bilgileri kaynağında (Ortak Bilgi Havuzunda) düzelterek bu bilgiler referans verilen tüm dokümanlarda eş zamanlı olarak düzeltilmesi yapılır.
* Ortak Bilgi Havuzuna girilen bir bilginin tüm ekip tarafından kullanılması sağlanarak tekrarlı girişler azaltılır. Böylece hata yapma olasılığı düşer.

= 3. İŞ KURALLARI =

== 3.1. AMAÇ ==
Bu bölümün amacı, S1000D’nin uygulanacağı projelerde iş kuralı kavramını detaylı olarak tanımlamak ve S1000D ile uyumlu kalabilmek için yanıtlanması zorunlu olan iş kurallarının ne zaman ve kimler tarafından belirlenmesi gerektiğini açıklamaktır.

== 3.2. KAPSAM ==
S1000D spesifikasyonunun teknik yayın süreçlerinin tamamında (planlama, yönetim, üretim, revizyon takibi/yönetimi, dağıtım ve kullanım) uygulanan uyarlama (tailoring) faaliyetlerini kapsamaktadır.

== 3.3. İŞ KURALI NEDİR? ==
İş Kuralı, S1000D spesifikasyonu ile hazırlanacak teknik yayınların planlanması, yönetimi, üretimi, değişimi, dağıtımı, kullanımı ile ilgili alınan kararların tümüdür. S1000D’nin içeriğinde yer almayan ancak S1000D’nin uygulanması üzerinde etkisi olan diğer tüm konular hakkında alınan kararlar da iş kuralıdır.

İş Kuralı Karar Noktası, iş kurallarının bir ID (unique identifier), başlık ve açıklama cümlesi ile tanımlanmış haline verilen isimdir. Bu yapı S1000D’nin 4.1 versiyonu ile birlikte ortaya çıkmıştır.

== 3.4. İŞ KURALLARI NEDEN ÖNEMLİDİR? ==
S1000D, savunma ve güvenlik alanında faaliyet gösteren ihtiyaç makamı, tedarik makamı, kullanıcı ve yüklenicilerin (uygulayıcılar) tercihine bırakılan pek çok seçeneğin yer aldığı bir spesifikasyondur. Eğer bu uygulayıcılar, S1000D’de tanımlanan şemaları, süreçleri, Standart Numbering System (SNS) yapılarını, bilgi kodlarını, bilgi kümelerini vb. açıklayıcı içerikleri nasıl kullanacaklarına dair standart bir yol haritası çizmezlerse S1000D ile uyumlu, ancak kendi içinde uyumsuz içeriklerin hazırlanması riski doğacaktır. Bu durum, bir projedeki dokümantasyon faaliyetlerinde çalışacak birden fazla paydaşın olması durumunda daha da karmaşık bir hal alacaktır. Aşağıdaki örnekler olası risklerin bir kısmını ortaya koymaktadır:

* Projede kullanılacak SNS yapısının belirlenmemesi, hazırlanan veri modüllerinin üretilen ürünün kırılımında bulunan hangi alt sistem veya cihaza ait olduğunun yöneticiler, yazarlar ve son kullanıcılar tarafından anlaşılamamasına neden olacaktır.
* Hazırlanan veri modüllerinin bir kısmında metin vurgusunun kelimeleri kalınlaştırarak bir kısmında ise kelimelerin altının çizerek yapılması, son kullanıcı açısından yanlış anlaşılmalara neden olacaktır.
* Görsel nesnelerin ve çoklu ortam nesnelerinin formatlarına karar verilmemesi halinde yazılım ihtiyacının tam anlaşılamamasından dolayı IETP gösterim araçlarında bazı görsel nesneler ve çoklu ortam nesneleri görüntülenemeyecektir.
* Gizlilik derecelendirmesi bulunan içeriklerin listelenmemesi ve ilgili içeriklere erişim yetkilerinin tanımlanmaması, güvenlik açıklarına neden olacaktır.
* S1000D’nin bazı versiyonlarındaki şemaların eleman ve nitelik isimleri farklıdır. Eğer projede uygulanacak S1000D versiyonu/versiyonları belirlenmezse farklı versiyonlarda hazırlanan veri modüllerinin birbirleri ile ilişkilendirilmesi güçlük yaratacaktır. Ayrıca eski versiyona adapte olan kişiler yeni versiyonun, yeni versiyona adapte olan kişiler de eski versiyonun içeriğine hakim olmayabilirler.

Bu durum süreçlerin ve ürünlerin yönetilmesi açısından proje süresince ciddi problemler doğuracaktır.

Bu ve benzer riskler, önlem alınmadığı takdirde düzeltilmesi maliyetli olacak sorunlar yaratacaktır. İş kurallarının önemi bu noktada ortaya çıkmaktadır. İş kuralları, tanımından da anlaşılacağı gibi proje kapsamında yürütülecek dokümantasyon faaliyetlerinin ve dokümantasyonla ilişkili diğer faaliyetlerin planlanmasını sağlamaktadır. Bu nedenle yukarıda belirtilen veya benzeri risklere karşı alınabilecek en iyi önlem; teknik yayınlarla ilgili gereksinimlerin çok net tanımlandığı, iş akışlarının ve süreçlerinin tasarlandığı, bilgi güvenliği ile ilgili açık noktanın bırakılmadığı, S1000D’nin sunduğu seçenekler arasından proje ihtiyaçlarını karşılayacak olanların belirlenerek standart bir uygulama planının ortaya konduğu kuralları belirlemek, dokümante etmek ve dokümantasyon faaliyetlerinde rol alacak kişi ve kurumları belirlenen bu kurallar konusunda bilinçlendirmektir.

== 3.5. GENEL ==
İş kuralı kavramı ilk olarak S1000D’nin 2.0 versiyonu ile kullanılmaya başlanmıştır. Versiyon 2.2 ile beraber iş kurallarının standart bir yapıda dokümante edilmesine olanak tanıyan İş Kuralları Değişimi (BREX) şeması yayınlanmıştır. Versiyon 4.1 yayınlanana kadar iş kuralları kavramı, yayınlanan her sürümle beraber hem daha detaylı açıklamalarla tanımlanmış hem de yer aldığı konu başlıklarının sayısı artmıştır. Versiyon 4.1’in yayınlanmasıyla beraber ise iş kurallarına standart bir yapı kazandırılarak İş Kuralı Karar Noktası (BRDP) kavramı ortaya atılmıştır. Böylece iş kurallarının izlenebilirliği arttırılmıştır. Versiyon 4.2 ile birlikte iş kurallarının dokümante edilmesine yönelik BREX şemasına ek olarak brdoc şeması yayınlanmıştır.

İş kurallarının proje ihtiyaçları çerçevesinde tanımlanması ve dokümante edilmesi, S1000D’nin 4.1 versiyonu ile beraber uygulanması zorunlu olan ana kriterlerinden birisi halini almıştır. İş kurallarının çeşitli kategoriler altında sınıflandırılması, bu süreç boyunca iş kurallarının daha iyi anlaşılmasında, birbirleri ile ilişkili olan iş kurallarının tespit edilmesinde ve iş kuralları arasındaki farklılıkların daha net ortaya konulmasında oldukça yararlı olmaktadır. İş kurallarının kategoriler altında sınıflandırılması, karar noktalarının kapsamını standart bir yapıya sokarak taraflar arasında ortaya çıkabilecek görüş ayrılıklarını da önlemektedir.

Bazı iş kuralları projeden projeye (proje ihtiyaçları ve proje kapsamı doğrultusunda) tanımlanabilecekken, bazı iş kuralları ise alınan birtakım kurumsal/organizasyonel kararların her projede aynı şekilde uygulanmasını gerektirebilir. Örnek vermek gerekirse; teknik dokümanların yazılacağı dil, üretici firma açısından projeden projeye, müşteriden müşteriye göre farklılık gösterebilir. Ancak tedarik makamları için teknik dokümanların yazılacağı dilin Türkçe olması kurumsal bir karardır ve her projede olduğu gibi uygulanması istenebilir. Projelerde farklı karar alıcıların bulunması nedeniyle ortaya çıkabilecek karışıklıkların önlenmesi için iş kuralları katmanlı bir yapıda dokümante edilmelidir.

Katmanlı iş kurallarının uygulandığı projelerde, birbirleri ile ilişkili olabilecek karar noktalarının bulunması nedeniyle bir katmanda “A” iş kuralı hakkında alınan karar ile farklı bir katmanda “B” iş kuralı için alınan karar arasında çelişki doğabilir. Farklı bir örnekte ise bir üretici, daha önceki bir projede hazırlamış olduğu içerikleri yeni bir projede de kullanmak istediği zaman, iş kurallarının bu iki proje arasında ciddi farklılıklar göstermesi durumunda aynı içeriği tekrar kullanabilmek için S1000D’nin farklı birtakım yöntemlerini kullanmak zorunda kalabilir.

İş kurallarının katmanlı bir yapıda belirlenmesi, bunların bir kısmının birbirleri ile ilişkili olması nedeniyle kurumlar arasındaki hiyerarşide olduğu gibi yukarıdan aşağıya doğru lineer bir biçimde yapılamaz. Örnek vermek gerekirse, BRDP-S1-00006 numaralı karar noktası projede kullanılacak şemaların belirlenmesini ister. Üst katmanlardan birisinin bu karar noktası hakkında “projede sadece IPD, procedure ve descriptive şemaları kullanılacaktır.” gibi kesin bir karar alması, Ortak Bilgi Havuzu (CIR) şemasının kullanımına karar verilen BRDP-S1-00375 numaralı iş kuralının alt katmana bırakılması ve alt katmanın/katmanların CIR’ı kullanma yönünde olumlu karar alması durumunda, projenin iş kuralları arasında çelişkili bir durum oluşturacaktır. Karar katmanları arasında ortaya çıkabilecek bu gibi çatışmaların önlenmesi ile ilgili öneriler Madde 3.8.1’de yer almaktadır.

== 3.6. TEMEL BİLGİLER ==
Bu bölümde, iş kurallarında bahsi geçen ve S1000D spesifikasyonuna özgü temel yapı ve elemanların açıklamalarına yer verilmiştir.

=== 3.6.1. ORTAK KAYNAK VERİ TABANI (CSDB) ===
Ortak kaynak veri tabanı, bilginin yönetilmesinde kullanılan en önemli ve kritik elemandır. Bu eleman, projenin ihtiyaç duyduğu tüm yayınları oluşturan bilginin, görsel öğenin, multi-medyanın, v.b. verilerin yönetildiği alandır.

CSDB’nin ana görevleri:

* Teknik yayın oluşturma prosesini,
* Doküman yazarlarının kontrolünü,
* Doküman Kalite kontrol sürecini,
* İş ortakları, tedarikçiler ve müşteriler arasındaki veri transferini,
* Depolandığı yerdeki formatından bağımsız olarak çeşitli medyalarda görüntülenmek üzere teknik yayın üretimini sağlamaktır.

CSDB içinde yönetilen, referans edilebilen ve değiştirilebilen tüm objeler CSDB Objesi olarak tanımlanır ve aşağıda listelenmiştir:

* Veri modülleri
* Veri modüllerinde referanslı görsel öğeler, multimedia ve diğer veriler
* Veri yönetim listeleri (Data management lists)
* Yorum modülleri (Comments)
* Yayın modülleri (Publication modules)
* Veri değişim listeleri (Data dispatch notes)

=== 3.6.2. CSDB OBJELERİ ===
Bu bölümde CSDB objeleri arasından, S1000D uygulamalarında sıklıkla kullanılan temel yapılar tanıtılacaktır.

=== 3.6.2.1. VERİ MODÜLÜ ===
Veri Modülü, kendi başına anlamlı olacak şekilde bilgi içeren en küçük ünitedir. Veri modüllerinin içeriğini metinler, görsel öğeler, multimedia öğeleri vb. veriler oluşturmaktadır. Veri modülleri bunlardan sadece metinleri doğrudan içinde tutar. Geri kalan görsel öğe, multimedia vb. verilere referans verilir. Formatı XML’dir.

Veri modülleri S1000D spesifikasyonu tarafından belirlenen şemalar kullanılarak hazırlanır. Bu şemalardan bazıları:

* Açıklama Bilgileri Şeması
* Prosedür Bilgi Şeması
* Hata Giderme Bilgi Şeması
* Bakım Planlama Bilgi Şeması
* Kullanıcı/Operatör Bilgi Şeması
* Resimli Parça Kataloğu Bilgi Şeması
* Kablolama Veri Şeması
* Servis Bülteni Şeması
* Bakım Kontrol Çizelgesi ve Muayene Şeması
* İş Kuralları Değişimi (BREX) Şeması

Teknik dokümanı veri modülleri halinde ayrıştırıp tasarlarken, farklı dokümanlarda da kullanılabilecek veri modülleri oluşturmaya çok dikkat etmek gerekmektedir. Tekrar kullanılabilir içerikler oluşturmak hem dokümanların yazılma/hazırlanma sürelerini kısaltacaktır, hem de kontrolünü ve revizyon takibini oldukça kolaylaştıracaktır. Ancak veri modüllerin kullanımı sırasında da zincirleme referanslar (iç içe çok fazla referans kullanımı) oluşturmaktan da kaçınmak önerilir. Aksi halde veri modüllerinin birbirleri ile olan ilişkilerini takip etmekte zorluklar ortaya çıkacaktır.

==== <big>3.6.2.2. GÖRSEL ÖĞE VE MULTİMEDYALAR</big> ====
Görsel öğe, videolar, vb. multimedia nesneleri, teknik içeriklerin anlaşılırlığını arttırmak maksadıyla, yazılı olarak yapılan tarif ve tanımlamaların üç boyutlu veya iki boyutlu materyallere dönüştürülmüş halleridir.

S1000D spesifikasyonu ile uyumlu dokümanlar hazırlanabilmesi için, teknik dokümanlarda yer alan tüm görsel öğeler, videolar, vb. multimedia nesneleri Bilgi Kontrol Numarası (ICN) kodu ile tanımlanmış fiziksel dosyalar halinde CSDB’de yönetilmek zorundadır.

==== <big>3.6.2.3. YAYIN MODÜLÜ</big> ====
Yayının aslında veri modüllerinden oluşmaktadır. Bu yapı yayın modülü ile sağlanır. Yayın modülleri, bir teknik yayının hangi içeriklerden oluşacağının referans edilerek tanımlandığı ve bu içerikler arasındaki başlık hiyerarşisinin kurgulandığı yerdir. Yayın modülleri de tıpkı veri modülleri gibi XML formatındadır. Yayın modüllerinde yer alan referanslar;

* Veri modüllerine,
* Yayın modüllerine,
* Mevcut teknik yayınlara (içerik açısından güncel ancak dosya formatı açısından S1000D’ye uygun olmayan yayınlar) yapılabilir.

=== 3.6.3. KODLAMA YAPILARI ===
CSDB Objelerinin, S1000D spesifikasyonunda tanımlanan yöntemlere göre kodlanması gerekmektedir. Bu kodları oluşturan alanlarda kullanılacak bilgilerin, projenin dokümantasyon faaliyetlerine ve hatta içerik analizine başlamadan önce tanımlanmış ve kararlaştırılmış olması çok önemlidir.

==== <big>3.6.3.1. VERİ MODÜLÜ KODLAMA (DMC) YAPISI</big> ====
Veri modülü kodu, bir veri modülünün standart bir formatı bulunan tanımlayıcısıdır. Veri modülü kodu, veri modülünün “identAndStatusSection” elemanının altında yer almaktadır. Veri modülü kodu, dil ve ülke kodu, versiyon ve taslak sürüm numaraları ile birlikte kullanıldığında veri modülünü özgün olarak tanımlar. Bu kod, bir veri modülünün CSDB içinde yönetilebilmesini sağlar.

Veri modülü kodu minimum 17, maksimum 41 karakterden oluşmaktadır. 41 karakter için örnek yapı aşağıda verilmiştir.
[[Dosya:Şekil2 Veri Modül Kod Yapısı.jpg|alt=Şekil 2 Veri Modül Kod Yapısı|sol|küçükresim|600x600pik|Şekil 2 Veri Modül Kod Yapısı]]

Veri modülü kodunu oluşturan bilgi haneleri aşağıda tanımlanmıştır:

* Model Tanımlama Kodu: Dokümantasyonu yapılacak olan Ürünü veya Projeyi tanımlamaktadır. Bu kod, Ürüne/Sisteme ait tüm modelleri kapsayıcı nitelikte olmalıdır.
* Sistem Ayrım Kodu: Bir Sisteme/Ürüne ait alt sistemlerin, alt-alt sistemlerin ve bileşenlerin alternatiflerini belirtmek için kullanılan bir koddur.
* SNS: Projeyi/Ürünü oluşturan sistemleri, cihazları, bileşenleri, parçaları, v.b. standart bir dille tarif edebilmek için dizayn edilmiştir.
** Malzeme Kalem Kategori Kodu: SNS’leri kullanım koşullarına/alanlarına göre (kara, hava, deniz, ordonat, taktik füze vb.) kategorize etmek için kullanılan koddur.
** Sistem Kodu: Sistemde/Üründe yer alan sistemlerin tanımlanmasında kullanılır.
** Alt Sistem Kodu: Sistemi oluşturan alt sistemlerin tanımlanmasında kullanılır.
** Alt Alt Sistem Kodu: Alt sistemleri oluşturan alt alt sistemlerin tanımlanmasında kullanılır.
** Bileşen Kodu: Alt alt sistemleri oluşturan bileşenlerin tanımlanmasında kullanılır.

* Sökme Kodu: SNS’in yetmediği hallerde, bileşen seviyesinin altında kalan diğer tüm ürün kılımının tanımlanmasında kullanılır.
* Sökme Kodu Türevi: Sistemin/Ürünün sökme kodu ile numaralandırılan ünitelerine/bileşenlerine ait alternatiflerin tanımlanmasında kullanılır.
* Bilgi Kodu: Veri modülünün içinde ne tür bilgilerin olduğunu tanımlayan koddur. (Bakım, işletme talimatı, vb.)
* Bilgi Kodu Türevi: Veri modülünde yer alan bilgilerin alternatiflerinin tanımlanmasında kullanılır.
* Kalem Konum Kodu: Bir kalemin lokasyonuna göre bilginin sınıflandırılmasında kullanılan koddur. Bu kodun alabileceği değerler aşağıdaki gibidir:
** "A" – Ürünün/Sistemin üstünde takılı olan objeler için geçerlidir.
** "B" – Ürünün/Sistemin üstünden sökülen bir ana bileşene montajlı olan objeler için geçerlidir.
** "C" – Tezgah üstündeki objeler için geçerlidir.
** "D" – Üç kategoriyi de kapsayan bilgilerdir (A, B ve C kategorileri).
** "T" – Eğitim ile ilgili bilgilerdir.

* Eğitim Kodu: Opsiyonel bir koddur. Eğitim ve insan performansı ile ilgili veri modüllerinin içinde ne tür bilgilerin bulunduğunu tanımlayan koddur.
* Eğitim Etkinlik Kodu: Eğitim Kodu ile birlikte kullanımı zorunlu olan bir koddur. Eğitim ve insan performansı ile ilgili içeriklerin türünün tanımlanmasında kullanılır.
** "A" – Eğitim Planı
** "B" – Eğitim İçeriğinin Genel Değerlendirmesi
** "C" – Eğitim İçeriği
** "D" – Eğitim Özeti
** "E" – Ölçme ve Değerlendirme

'''Örnek-1:''' Bir deniz platformuna ait veri modülünün kodlandırılması

NOT: Bu örnek uygulamada iş kuralları arasından '''BRDP-S1-00001''' numaralı, '''"I" ve "O" karakterlerinin kullanımı''' başlıklı iş kuralında “I” ve “O” karakterlerinin kullanımı serbest bırakılmıştır.

NOT: Bu örnek uygulamada iş kuralları arasından '''BRDP-S1-00003''' numaralı, '''Uygulanacak S1000D versiyonu''' başlıklı iş kuralında S1000D’nin 4.1 versiyonunun uygulanmasına karar verilmiştir.

NOT: Bu örnek uygulamada iş kuralları arasından '''BRDP-S1-00337''' numaralı, '''Malzeme Kalem Kategori Kodunun kullanımı''' başlıklı iş kuralında Malzeme Kalem Kategori Kodunun kullanılmasına karar verilmiştir.

NOT: Bu örnek uygulamada iş kuralları arasından '''BRDP-S1-00336''' numaralı, '''Ürün SNS yapısı''' başlıklı iş kuralında S1000D spesifikasyonunda tanımlanmış olan SNS yapısının kullanılmasına karar verilmiştir. SNS’te yer alan bileşen kodunun 4 karakter olarak kullanılmasına karar verilmiştir. SNS yapısının tamamının Poje İş Kuralları dokümanında indekslendiği varsayılacaktır.

NOT: Bu örnek uygulamada iş kuralları arasından '''BRDP-S1-00334''' numaralı, '''Sistem farklılık kodunun tahsisi''' başlıklı iş kuralının tanımlandığı ve kullanılabilecek değerlerin Poje İş Kuralları dokümanında indekslendiği varsayılacaktır.

NOT: Bu örnek uygulamada iş kuralları arasından '''BRDP-S1-00332''' numaralı, '''Ürene tahsis edilecek model tanımlama kodu''' başlıklı iş kuralının tanımlandığı ve kullanılabilecek değerlerin Poje İş Kuralları dokümanında indekslendiği varsayılacaktır.

(''Bu örnekte tüm resimli parça kataloğu dokümanından bahsedilmemektedir. Yalnızca ana tahrik dizeline ait, patlatılmış resim ve bu resimde pozlanmış parçalara ait bilgilerin yer alacağı bir adet veri modülünden bahsedilmektedir''.)

MILGEM Projesi kapsamında üretilen TCG Heybeliada ve TCG Büyükada korvetlerine ait ana tahrik dizellerinin resimli parça bilgisinin yer aldığı veri modülünün kodu aşağıdaki gibidir:

'''DMC-MILGEM-AAA-HA1-50-0000-010-941A-D'''

İlgili veri modülünde yer alan;

* Model Tanımlama Kodu olarak Proje’nin adı “MILGEM” kullanılmıştır.
* Sistem Ayrım Kodu olarak “AAA” değeri kullanılmıştır.
* SNS yapısı olarak S1000D spesifikasyonunda yer alan bölüm 8.2.8 kullanılmıştır. Sistem Kodu, Malzeme Kalem Kategori Kodu ile birlikte kullanılmıştır.
** Malzeme Kalem Kategori Kodu deniz sistemleri için “H” değerini alır.
** Sistem Kodu, bir deniz platformunun ana tahrik dizeli için “A1” değerini alır.
** Alt Sistem Kodu, bir deniz platformunun ana tahrik dizeli için “5” değerini alır.
** Alt Alt Sistem Kodu, bir deniz platformunun ana tahrik dizeli için “0” değerini alır.
** Bileşen kodu, Proje İş Kuralları Dokümanı’nda tanımlandığı şekilde, ana tahrik dizeli için “0000” değerini alır.

* Sökme Kodu, ilgili veri modülünün resimli parça kataloğuna ait olması nedeniyle “01” değeri kullanılmıştır.
* Sökme Kodu Türevi, ilgili veri modülü baz resmi içerdiğinden “0” değeri kullanılmıştır.
* Bilgi Kodu, resimli parça kataloğu veri modülleri için, S1000D spesifikasyonu bölüm 8.4.2’de “941” olarak belirtilmiştir. Bu nedenle bilgi kodu olarak “941” kullanılmıştır.
* Bilgi Kodu Türevi olarak “A” değeri kullanılmıştır.
* Kalem Konum Kodu, ilgili veri modülünde yer alan teknik içerikler, ”A”, “B” ve “C” koşullarının 3’ü için de geçerli olduğundan “D” değerinin kullanılmıştır.

'''Örnek-2:''' Bir kara platformuna ait veri modülünün kodlandırılması

NOT: Bu örnek uygulamada iş kuralları arasından '''BRDP-S1-00001''' numaralı, '''"I" ve "O" karakterlerinin kullanımı''' başlıklı iş kuralında “I” ve “O” karakterlerinin kullanımı serbest bırakılmıştır.

NOT: Bu örnek uygulamada iş kuralları arasından '''BRDP-S1-00003''' numaralı, '''Uygulanacak S1000D versiyonu''' başlıklı iş kuralında S1000D’nin 4.1 versiyonunun uygulanmasına karar verilmiştir.

NOT: Bu örnek uygulamada iş kuralları arasından '''BRDP-S1-00337''' numaralı, '''Malzeme Kalem Kategori Kodunun kullanımı''' başlıklı iş kuralında Malzeme Kalem Kategori Kodunun kullanılmasına karar verilmiştir.

NOT: Bu örnek uygulamada iş kuralları arasından '''BRDP-S1-00336''' numaralı, '''Ürün SNS yapısı''' başlıklı iş kuralında S1000D spesifikasyonunda tanımlanmış olan SNS yapısının kullanılmasına karar verilmiştir. Bileşen kodunun 4 karakter olarak kullanılmasına karar verilmiştir. Ayrıca SNS yapısının tamamının Poje İş Kuralları dokümanında indekslendiği varsayılacaktır.

NOT: Bu örnek uygulamada iş kuralları arasından '''BRDP-S1-00334''' numaralı, '''Sistem farklılık kodunun tahsisi''' başlıklı iş kuralının tanımlandığı ve kullanılabilecek değerlerin Poje İş Kuralları dokümanında indekslendiği varsayılacaktır.

NOT: Bu örnek uygulamada iş kuralları arasından '''BRDP-S1-00332''' numaralı, '''Ürene tahsis edilecek model tanımlama kodu''' başlıklı iş kuralının tanımlandığı ve kullanılabilecek değerlerin Poje İş Kuralları dokümanında indekslendiği varsayılacaktır.

Fırtına Obüslerine ait güç grubunun yakıt pompasının sökülüp yerine yenisinin takıldığı bakım prosedürüne ait veri modülünün kodu aşağıdaki gibidir:

'''DMC-FIRTINA-AAA-GA1-12-0100-00AAA-921A-A'''

İlgili veri modülünde yer alan;

* Model Tanımlama Kodu olarak Platform’un adı “FIRTINA” kullanılmıştır.
* Sistem Ayrım Kodu olarak, “AAA” değerinin kullanılmıştır.
* SNS yapısı olarak S1000D spesifikasyonunda yer alan bölüm 8.2.8 kullanılmıştır. Sistem Kodu, Malzeme Kalem Kategori Kodu ile birlikte kullanılmıştır.
** Malzeme Kalem Kategori Kodu kara sistemleri için “G” değerini alır.
** Sistem Kodu, bir kara platformunun güç grubu için “A1” değerini alır.
** Alt Sistem Kodu, bir kara platformunun güç grubunun dizel motoru için “1” değerini alır.
** Alt Alt Sistem Kodu, Proje İş Kuralları Dokümanı’nda tanımlandığı şekilde, güç grubunun dizel motoruna ait yakıt sistemi için “2” değerini alır.
** Bileşen kodu, Proje İş Kuralları Dokümanı’nda tanımlandığı şekilde, güç grubunun dizel motoruna ait yakıt pompası için “0100” değerini alır.

* Sökme Kodu, SNS yapısı veri modülüne konu olan ürün kırılımını tanımlamakta yeterli olduğundan “00” değeri kullanılmıştır.
* Sökme Kodu Türevi, “AAA” değeri kullanılmıştır.
* Bilgi Kodu, bir parçanın sökülüp yenisi ile değiştirildiği bakım işlemlerinin yer aldığı veri modülleri için, S1000D spesifikasyonu bölüm 8.4.2’de “921” olarak belirtilmiştir. Bu nedenle bilgi kodu olarak “921” kullanılmıştır.
* Bilgi Kodu Türevi olarak “A” değeri kullanılmıştır.
* Kalem Konum Kodu, ilgili veri modülünde yer alan teknik içerikler, yalnızca yakıt pompası güç grubu üstünde montajlı haldeyken geçerli olacağından, ”A” değerinin kullanılmıştır.

==== <big>3.6.3.2. GÖRSEL ÖĞE KODLAMA YAPISI (ICN)</big> ====
ICN kodu, bir görsel öğe, multimedia vb. verilerin standart formatları bulunan tanımlayıcısıdır. ICN kodu, diğer CSDB objelerinden farklı olarak yalnızca dosya adında tanımlanabilir (S1000D versiyon 4.2 ile birlikte ICN tanımlayıcı-veri (meta-data) şeması geliştirilmiştir. Bu durumla birlikte ICN kodu bilgisi hem ICN tanımlayıcı-veri dosyasında hem de ilgili görsel nesnenin dosya adında tutulmaya başlanmıştır.). Bu kod, görsel öğe, multimedia vb. verilerin CSDB içinde yönetilebilmesini sağlar.

S1000D spesifikasyonunda görsel öğe, multimedia veya diğer medyaların kodlandırılmasında iki farklı kod yapısı tanımlanmıştır. Bu bölümde, bunlardan yalnızca SNS yapısını içermekte olan kodlama formatına yer verilecektir.

ICN kodu minimum 29, maksimum 47 karakterden oluşmaktadır.
[[Dosya:Şekil3 Örnek ICN Yapısı.jpg|alt=Şekil 3 Örnek ICN Yapısı|sol|küçükresim|600x600pik|Şekil 3 Örnek ICN Yapısı]]

* Önek: Önek olarak “ICN” kullanılır.
* Model Tanımlama Kodu (MIC): Veri modülü kodundaki kullanımı ile aynıdır.
* Sistem Ayrım Kodu: Veri modülü kodundaki kullanımı ile aynıdır.
* SNS: Veri modülü kodundaki kullanımı ile aynıdır
* Sorumlu Firma Kodu: Sorumlu firma kodu, bir görsel öğe, multimedia vb. verilerden, veri modüllerinde kullanımı hariç olarak, sorumlu olan firmayı tanımlayan bir koddur. Bu kod, proje ekibi veya organizasyon tarafından tanımlanmalıdır.
* Üretici Kodu: Üretici kodu, bir görsel öğe, multimedia vb. verileri hazırlayan firmanın CAGE kodu bilgisidir.
* Özgün Tanımlayıcı: Özgün tanımlayıcı beş alfanümerik karakterden oluşur. Bu tanımlayıcı, aynı MIC, SNS, üretici ve sorumlu firma koduna sahip olan nesnelerin özgün bir şekilde tanımlanmasını sağlar.
* Türev Kodu: Türev kodu, bir alfanümerik karakterden oluşur. Bu kod, görsel öğenin, multimedianın vb. verilerin varyasyonlarını tanımlar. Bir görsel öğenin baz hali için bu değer “A” olarak kullanılır. Aynı görsel öğenin türevleri için bu değer “B” den başlayarak “Z”ye kadar arttırılır. Bir görsel öğenin türevi, ilgili görselin ölçeklenmiş, kırpılmış, döndürülmüş ve/veya açıklayıcı notlar eklenmiş halidir.
* Versiyon Numarası: Görsel öğenin versiyon bilgisini tanımlar.
* Gizlilik Derecesi: Görsel öğenin gizlilik derecesini tanımlar.

==== <big>3.6.3.3. YAYIN MODÜLÜ KODLAMA YAPISI</big> ====
Yayın modülü kodu, bir yayın modülünün standart bir formatı bulunan tanımlayıcısıdır. Yayın modülü kodu, yayın modülünün “identAndStatusSection” elemanının altında yer almaktadır. Yayın modülü kodu, dil ve ülke kodu, versiyon ve taslak sürüm numaraları ile birlikte kullanıldığında yayın modülünü özgün olarak tanımlar. Bu kod, bir yayın modülünün CSDB içinde yönetilebilmesini sağlar.

Yayın modülü kodu minimum 14, maksimum 26 karakterden oluşmaktadır.
[[Dosya:Şekil4 Yayın Modülü Kodlama Yapısı.jpg|alt=Şekil 4 Yayın Modülü Kodlama Yapısı|sol|küçükresim|550x550pik|Şekil 4 Yayın Modülü Kodlama Yapısı]]

* Model Tanımlama Kodu (MIC): Veri modülü kodundaki kullanımı ile aynıdır.
* Tanzim Eden Otorite: Yayın modülünü tanzim eden firmanın/kurumun CAGE kodu bilgisini tanımlar.
* Yayın Numarası: Yayın modülünün numarasını tanımlar.
* Cilt Numarası: Yayın modülünün cilt numarasını tanımlar.

== 3.7. İŞ KURALI KATEGORİLERİ ==
İş kuralı kategorisi; ürün tanımlama, bakım felsefesi ve kullanım konsepti, gizlilik ve güvenlik, iş süreçleri, verilerin oluşturulması, verilerin transfer edilmesi, veri bütünlüğünün korunması ve yönetilmesi, çıktı formatı ve mevcut verilerin yönetimi ve kullanımı gibi farklı pek çok konuda uygulanabilecek kuralların tanımlandığı özgün bir gruplandırma şeklidir.

S1000D’nin içinde on farklı iş kuralı kategorisi tanımlanmıştır. Bu kategoriler, iş kuralı geliştiricilerin S1000D içinde yer alan tüm majör iş kurallarını değerlendirmelerini sağlayacak şekilde tanımlanmıştır.

Bir iş kuralı birden fazla kategorinin altında sınıflandırılabilir. Ayrıca iş kuralı kategorileri de birbirinden izole yapılar değildir. Bazı kategoriler birbirleri ile ilişkili hatta birbirini tamamlayan özelliktedir. Örnek vermek gerekirse; İş Kuralı Kategorisi 7 (Veri Transferi) ile İş Kuralı Kategorisi 8 (Veri Bütünlüğü ve Yönetimi) arasında ilişkili konular/kararlar vardır.

İş Kuralı Kategorileri aşağıdaki şekilde belirtilmiştir.
[[Dosya:Şekil 5 İş Kuralı Kategorileri.png|alt=Şekil 5 İş Kuralı Kategorileri|sol|küçükresim|500x500pik|Şekil 5 İş Kuralı Kategorileri]]

Kategorilerin açıklandığı alt başlıklarda verilen örnekler zorlayıcı özellikte olmayıp, ilgili alt başlıkların anlaşılabilirliğini arttırıcı yönde katkı sağlayacağı düşünüldüğünden verilmiştir.

=== 3.7.1. KATEGORİ 1- GENEL ===
Genel kategorisi altında sınıflandırılan iş kuralları, diğer kategoriler altında sınıflandırılamayan ve S1000D’nin uygulanmasında dokümantasyon süreçlerinin üzerinde daha geniş bir etki alanı olan kurallardır.

Genel kategorisi aşağıdaki kuralları içermekle beraber bunlarla sınırlı değildir:

* S1000D’nin hangi versiyonunun uygulanacağı,
* Projede S1000D’nin hangi bölümlerinin kullanılacağının ve uygulanacağının tanımlanması,
* Dil birliğinin sağlanması ve anlam karmaşasına düşülmemesi için proje boyunca kullanılacak kavramların tanımlanması.

Aşağıdaki karar noktaları, bu kategoriye örnek teşkil etmektedir:

'''İş Kuralı Karar Noktası BRDP-S1-00003 – Uygulanacak S1000D versiyonu''':

* S1000D’nin hangi versiyonunun veya versiyonlarının uygulanacağına karar ver.

'''İş Kuralı Karar Noktası BRDP-S1-00008 – Muhtemel teslimatlar''':

* Teslimat kalemlerinin ne olacağına karar ver:
** S1000D nesnelerinin (veri modülleri, yayın modülleri, görsel öğelerin listesi ve çoklu ortam nesneleri, veri modül listeleri, vb.) dosya tabanlı transfer metodu ile teslimi.
** Sayfa formatlı yayınlar ve/veya etkileşimli elektronik teknik yayınlar (IETM)

=== 3.7.2. KATEGORİ 2- ÜRÜN TANIMLAMA ===
Ürün tanımlama kategorisi, proje faaliyetleri kapsamında teknik yayınları hazırlanacak olan ürünün kırılımı (fiziksel veya fonksiyonel kırılım) ile veri modülü kodlandırma stratejisi arasındaki ilişkileri tanımlayan iş kurallarını içermektedir. Veri modül kodu, veri modülünün ait olduğu konfigürasyon elemanının ve veri modülünün içerdiği bilginin tanımlandığı iki ana gruptan oluşmaktadır. Bu kategoride konfigürasyon elemanının tanımlandığı grup ile ilgili iş kuralları ele alınmaktadır. Ayrıca alt yüklenicilerden tedarik edilecek alt sistemler ve bunların tanımlanması da bu kategori altında değerlendirilmelidir.

Veri modül kodunda, konfigürasyon elemanının tanımlandığı grupta, bize ürün kırılımına ait bilgiyi veren SNS yapısı bulunmaktadır. Projede kullanılacak SNS yapısı genellikle mühendislik veya tasarım faaliyetleri sırasında oluşturulan ürün kırılımı ile birlikte tanımlanmaktadır.

Ürün tanımlama kategorisi ayrıca içerik filtresi (applicability) ile ilgili kuralları da kapsamaktadır.

Ürün tanımlama kategorisi aşağıdaki kuralları içermekle beraber bunlarla sınırlı değildir:

Ürünün ve alt kırılımının tanımlanmasında kullanılacak;

* Model Tanımlama Kodu (MIC),
* Sistem Ayrım Kodu,
* Malzeme Kalem Kategori Kodu,
* SNS yapısının (S1000D’de yer alan SNS yapılarından hangisinin uygulanacağının belirlenmesi veya projeye özgü SNS yapılarının hazırlanması ile ilgili alınan karar)
* Sökme Kodu,
* Sökme Kodu Türevi,
* İçerik filtresi (applicability) bilgilerinin belirlenmesi.

Aşağıdaki karar noktası, bu kategoriye örnek teşkil etmektedir:

'''İş Kuralı Karar Noktası BRDP-S1-00331– Veri modülü kodlama stratejisi''':

* Ürün ve projede uygulanacak veri modülü kodlama stratejisini belirle.

=== 3.7.3. KATEGORİ 3- BAKIM FELSEFESİ VE KULLANIM KONSEPTİ ===
Bakım felsefesi ve kullanım konsepti kategorisi, bir kurumun veya projenin teknik dokümantasyon faaliyetlerinde ihtiyaç duyduğu bilgilerin tanımlandığı iş kurallarını kapsamaktadır. Bu bilgiler başlıca teknik dokümanların kapsam ve içerik derinliğinin tanımlandığı bilgi kümelerinin listesi ve/veya detaylı tanımlarını, veri modül kodunun ikinci ana grubu olan ve bilginin tanımlandığı kodlandırma yapısında yer alan bilgi kodunu, bilgi kodu türevini, kalem yerleşim kodunu ve bilgi kodunun taşıyacağı adı içermektedir. Bilgi kümeleri hakkındaki detaylı bilginin hangi kategoride (Kategori 1 veya 3) tanımlanması gerektiği kurum veya projede dokümantasyon faaliyetlerini yönetecek grupların kararına bırakılmıştır.

Bakım felsefesi ve kullanım konsepti ile ilgili iş kuralları, sözleşmede tanımlanmakta veya sözleşmede yapılan tanımlamalara göre yanıtlanmaktadır.

Bu kategorinin altında bulunan iş kuralları, proje çerçevesinde varsa yürütülecek LDA faaliyetleri ile uyum içinde tanımlanmalıdır.

Veri modüllerinin kodlama stratejisinin bir parçası olan bilgi kodunun, bilgi kodu türevinin ve kalem yerleşim kodunun tanımlanması bu kategorinin altında gerçekleştirilir. Bu işlem, projenin/kurumun teknik doküman ihtiyacının tanımlandığı karar noktaları (kategori 1) ve veri modül kodunda ürün kırılımının tanımlandığı karar noktaları (kategori 2) ile birlikte düşünülmelidir.

Ayrıca eğitim ve beceri düzeylerinin tanımlanması ile ilgili iş kuralları da bu kategorinin altında yer almaktadır.

Bakım felsefesi ve kullanım konsepti kategorisi aşağıdaki kuralları içermekle beraber bunlarla sınırlı değildir:

* Kullanılacak bilgi kümelerinin yapılarının listelenmesi,
* Kullanılacak bilgi kümelerinin detaylı bir şekilde açıklanması,
* Kullanılacak bilgi kodlarının ve bilgi kodu adlarının listelenmesi veya detaylı olarak açıklanması,
* Kullanılacak kalem yerleşim kodlarının belirlenmesi,
* Teslim edilecek veri modüllerinde yer alan/alacak içeriklerin derinliğinin bakım seviyelerine göre belirlenmesi,
* Veri modül kodlarında kullanılacak bilgi kodlarının ve kalem yerleşim kodunun belirlendiği iş kurallarının, kategori 2’de yer alan ürün kırılımı tanımlamaya dönük iş kuralları ile eşleştirilmesi,
* Bilgi kodu türevlerinin nasıl kullanılacağının belirlenmesi,
* Eğitim ve beceri düzeyi bilgilerinin nasıl kullanılacağının belirlenmesi.

Aşağıdaki karar noktası, bu kategoriye örnek teşkil etmektedir:

'''İş Kuralı Karar Noktası BRDP-S1-00052– Bilgi kod ve isimlendirmesi''':

* Kullanılacak bilgi kod ve isimlerine karar ver.

=== 3.7.4. KATEGORİ 4- GİZLİLİK VE GÜVENLİK ===
Gizlilik ve güvenlik kategorisi güvenlik, gizlilik ve telif hakları ile ilgili tüm konuları kapsamaktadır. Bu kategori başlıca gizlilik derecelendirmesinin ve telif hakkı işaretlerinin nasıl kullanılacağının, içeriklerin kullanımı veya açığa çıkması ile ilgili kısıtlamaların, içeriğin imhası ile ilgili talimatların ve diğer benzer kısıtlamaların tanımlandığı iş kurallarını kapsamaktadır.

Ayrıca verilerin oluşturulmasında, gözden geçirilmesinde, değişiklik ve düzeltme yapılmasında, yönetilmesinde vb. diğer faaliyetlerdeki yetkilerin tanımlanması konusu da bu kategorinin altında yer almaktadır. Örnek vermek gerekirse, birden fazla kurumun dokümantasyon faaliyetlerinde birlikte çalışması gereken projelerde; yönetici kurum/kuruluş/şirket gizlilik derecesi bulunan verilerin veya telif hakkı açısından kısıtlamaların bulunduğu verilerin oluşturulmasında, gözden geçirilmesinde, değişiklik ve düzeltme yapılmasında, yönetilmesinde vb. diğer faaliyetlerde kimin hangi yetkilere sahip olacağına dair kısıtlamalarda bulunabilir.

Gizlilik ve güvenlik ile ilgili iş kurallarının belirlenmesi sırasında ulusal güvenlik kısıtlamalarının göz önünde bulundurulması gerekmektedir.

Gizlilik ve güvenlik iş kurallarının belirlenmesinde, projenin güvenlik talimatları kullanılmalıdır.

Gizlilik ve güvenlik kategorisi aşağıdaki kuralları içermekle beraber bunlarla sınırlı değildir:

* Gizlilik derecelendirmelerinin ve bunların kullanımının tanımlanması,
* Telif hakkı işaretlemelerinin kullanımının belirlenmesi,
* Bilginin kullanımı, dağıtımı, açığa çıkarılması, imhası vb. ile ilgili talimatların belirlenmesi,
* Ulusal güvenlik kısıtlamalarının tanımlanması,
* Varsa projeye özel gizlilik talimatlarının tanımlanması,
* Gizlilik derecelendirmelerine göre kişi ve/veya kurumların yetkilerinin tanımlanması.

Aşağıdaki karar noktası, bu kategoriye örnek teşkil etmektedir:

'''İş Kuralı Karar Noktası BRDP-S1-00016– Gizlilik sınıflandırmasının gösterimi''':

* Gizlilik sınıflandırmasının nasıl markalanıp, gösterileceğine karar ver.

=== 3.7.5. KATEGORİ 5- İŞ SÜREÇLERİ ===
İş süreçleri kategorisi, kurumlar içerisinde veya projede çalışan firmalar/kurumlar içerisinde S2000M uyumlu tedarik süreçlerinde ve LDA, tasarım/mühendislik, eğitim vb. faaliyetlerde görev alan farklı disiplinler ile teknik yayın süreçleri arasındaki ilişkilerin tanımlandığı iş kurallarını kapsamaktadır.

Kalite kontrol süreçleri ve bu süreçlerin projede bilgi üreten, üretilen bu bilgiyi kullanarak CSDB nesneleri hazırlayan, hazırlanan CSDB nesnelerini gözden geçiren/onaylayan, CSDB nesnelerini kullanarak nihai dokümanları oluşturan vb. faaliyetlerde bulunan kurum veya kişilerle olan etkileşimini tanımlayan kuralların da bu kategori altında ele alınması gerekmektedir.

Ayrıca üretilecek içeriklerin hem eğitim dokümanlarında hem de bakım ve kullanıcı dokümanlarında kullanılması gereken projelerde hem eğitim ekibinin hem de teknik yayın ekibinin ihtiyaçlarını karşılayacak nitelikteki içeriklerin nasıl üretileceği ile ilgili kararlar da bu kategori altında ele alınmalıdır.

Ayrıca oluşturulan bir içeriğin birden fazla alanda (eğitim, bakım ve kullanıcı dokümanları vb.) kullanılması gereken projelerde, hazırlanacak içeriklerin veya başka bir projede hazırlanmış ve ilgili projede de kullanılabilecek içeriklerin tekrar kullanılabilirliğinin en üst düzeyde olmasını sağlayacak süreçlerin tanımlandığı iş kuralları da belirlenmelidir.

Aşağıdaki amaçlara ulaşılabilmesi için söz konusu kuralların belirlenmesinde veri modül kodlama stratejisinin de göz önünde bulundurulması gerekmektedir:

* Veri modüllerinin eğitim dokümanlarında ve bakım dokümanlarında tekrar kullanılabilirliğini en uygun şekilde sağlayabilecek şekilde modüler içerikler hazırlanması,
* Etkileşimli çoklu ortam ve simülasyonlarda kullanılabilir özellikte bakım, kullanım ve eğitim içeriklerinin geliştirilmesi,
* Veri modül kodu ve/veya yayın modülü kodu ve eğitim içeriğinin kaydı gereksinimleri arasındaki ilişkinin kurulması

İş süreçleri kategorisi aşağıdaki kuralları içermekle beraber bunlarla sınırlı değildir:

* Diğer disiplinlerin teknik yayınlara ne tür girdiler yaptığı ve bunun sonucunda teknik yayınlarda ne tür çıktılar elde edildiğinin tanımlanması,
* Alt yüklenicilerden teslimat kalemlerine yapılacak girdilerin proje hiyerarşisine göre sıraya sokulması,
* Üretici, alt yüklenici ve müşteri arasında mutabakata varılmış iş süreçlerinin oluşturulması,
* Kalite kontrol süreçleri içindeki onay kriterlerinin projede taraf olan tüm kurumların birbirleri olan etkileşiminin göz önünde bulundurularak belirlenmesi,
* Tekrar kullanılabilirlik ve birlikte kullanılabilirliğin planlanması.

Aşağıdaki karar noktası, bu kategoriye örnek teşkil etmektedir:

'''İş Kuralı Karar Noktası BRDP-S1-00268– Eğitim hedefleri''':

* Görev analizi maddelerine uygun öğrenme hedefleri geliştirip geliştirmemeye karar ver.

=== 3.7.6. KATEGORİ 6- VERİLERİN OLUŞTURULMASI ===
Verilerin oluşturulması kategorisi metinsel içeriklerin, görsel öğelerin ve çoklu ortam nesnelerinin oluşturulması hakkında bilgi veren iş kurallarını kapsamaktadır.

Bu karar kategorisi içeriği itibari ile iki farklı alt kategoriye ayrılmıştır. Bu kategoriler:

* Kategori 6a-Metinsel Verilerin Oluşturulması,
* Kategori 6b-Görsel Nesnelerin ve Çoklu ortam Nesnelerinin Oluşturulması.

==== <big>3.7.6.1. KATEGORİ 6A- METİNSEL VERİLERİN OLUŞTURULMASI</big> ====
Metinsel verilerin oluşturulması ile ilgili iş kuralları, teknik yayınlardaki içeriklerin tekrar kullanılabilirliğini en üst düzeye çıkartan kural ve kılavuzlar içermektedir. Tekrar kullanılabilirlik, bir teknik dokümanı oluşturan içeriklerin aynı doküman içerisinde tekrar kullanımı ile sağlanabileceği gibi farklı teknik dokümanlar ve eğitim içeriklerinde kullanılabilmesi ile de sağlanabilmektedir.

Bu kurallar, teknik içeriklerin ve eğitim içeriklerinin nasıl geliştirilmesi gerektiği ile ilgili bilgiler sağlamaktadır. Bu kategori örnek olarak; sözlük kullanımı, sayıların nasıl gösterilmesi gerektiği, yazarların teknik terimlere nasıl referans vermesi gerektiği, çoklu ortam öğelerinin bakım, kullanım ve eğitim içeriklerini desteklemekte nasıl kullanılması gerektiğini ve bir terminoloji veri tabanının nasıl oluşturulması ve kullanılması gerektiği vb. konularla ilgili kararları içerir.

İşaretleme (XML Etiketleme) iş kuralları, şemalarda yer alan elemanların ve niteliklerin nasıl kullanılması gerektiği ile ilgili bilgi sağlamaktadır.

Metinsel verilerin oluşturulması kategorisi aşağıdaki kuralları içermekle beraber bunlarla sınırlı değildir:

* Yazım kuralları (terminoloji kuralları, sözlük kullanımları, sayıların kullanımı ile ilgili kurallar vb.),
* Biçimlendirme kuralları,
* Çoklu ortam ve görsel öğelerin metinsel anlatımlarla ilişkilendirilme ihtiyacı.

Aşağıdaki karar noktası, bu kategoriye örnek teşkil etmektedir:

'''İş Kuralı Karar Noktası BRDP-S1-00026– Metin vurgusu''':

* Metinlerin vurgulanması için hangi metodun kullanılacağına karar ver.

==== <big>3.7.6.2. KATEGORİ 6B- GÖRSEL NESNELERİN VE ÇOKLU ORTAM NESNELERİNİN OLUŞTURULMASI</big> ====
Bu bölüm, görsel nesnelerin ve çoklu ortam nesnelerinin oluşturulması ile ilgili iş kurallarını kapsamaktadır. Bu kurallar biçim, detay ve veri formatı olarak üçe ayrılır.

Biçimlerle ilgili kurallar; görselin boyutları, renk kullanımı, çizgi kalınlıkları, yazı fontları, projeksiyon yöntemleri (izometrik veya trimetrik) gibi görsel nesnelerin ve çoklu ortam nesnelerinin karakteristik özelliklerini belirlemekte kullanılmaktadır.

Görsel nesneler üzerinde aktif nokta (hot spot) kullanımı da bu kategorinin altında yer almaktadır.

Veri formatı ile ilgili kurallar, görsel öğelerin hangi formatlarda üretilmesi, depolanması ve görüntülenmesi gerektiğini tanımlamaktadır. Bu kararlar eleman ve nitelik kullanımları üzerinde etkisi olabilmektedir. Ayrıca biçim ve veri formatı ile ilgili kararları birbirinden ayrı ele almak çoğu zaman mümkün olmamaktadır.

Görsel nesnelerin ve çoklu ortam nesnelerinin oluşturulması kategorisi aşağıdaki kuralları içermekle beraber bunlarla sınırlı değildir:

* Grafik biçimi ile ilgili kurallar,
* Etkileşim ile ilgili kurallar,
* Çoklu ortam formatları,
* Metinsel anlatımlarla nesneler arasında bağlantı (link) oluşturulması.

Aşağıdaki karar noktası, bu kategoriye örnek teşkil etmektedir:

'''İş Kuralı Karar Noktası BRDP-S1-00129– Multimedya kullanımı''':

* Multimedya kullanılıp kullanılmayacağına karar ver.

=== 3.7.7. KATEGORİ 7- VERİ TRANSFERİ ===
Projede çalışan firmaların kendi aralarında ve müşterileriyle yaptıkları veri transferi işlemleriyle ilgili olan iş kuralları veri transferi kategorisi altında yer almaktadır. Veri Gönderme Notu (DDN), Veri Model İhtiyaç Listesi (DMRL) ve CSDB Statü Listesi (CSL) yapılarının kullanımı ile ilgili kurallar bu kategorinin altında bulunan iş kurallarına örnek olarak verilebilir. Ayrıca S1000D’de tarif edilen dosya tabanlı transfer protokolünün nasıl kullanılacağı, veri transferlerinin ne sıklıkla yapılacağı, transfer edilen verilerin arasında kalite kontrol süreçlerinden geçmemiş olanların versiyon numaralarının nasıl tanımlanacağı ve kabul/red kriterlerinin neler olacağı ile ilgili iş kuralları da bu kategorinin altında yer almaktadır.

Veri transferi kategorisi aşağıdaki kuralları içermekle beraber bunlarla sınırlı değildir:

* Veri Gönderme Notu (DDN) kullanımı ile ilgili kurallar,
* Veri Model İhtiyaç Listesi (DMRL) kullanımı ile ilgili kurallar,
* CSDB Statü Listesi (CSL) kullanımı ile ilgili kurallar,
* Dosya tabanlı transfer protokolünün kullanım şekli ile ilgili kurallar,
* Veri transfer sıklığının belirlenmesi,
* Veri modülü versiyonları ile ilgili kurallar,
* Bilgi Kontrol Numarası (ICN) numarası ile kodlandırılan verilerle ilgili kurallar,
* Kabul/red kriterlerinin belirlenmesi.

Aşağıdaki karar noktası, bu kategoriye örnek teşkil etmektedir:

'''İş Kuralı Karar Noktası BRDP-S1-00009 – Veri transferi sıklığı''':

* Veri transferi sıklığına karar ver.

=== 3.7.8. KATEGORİ 8- VERİ BÜTÜNLÜĞÜ VE YÖNETİMİ ===
Veri bütünlüğü ve yönetimi kategorisi, CSDB içindeki veri tutarlılığının sağlanması ile ilgili iş kurallarını kapsamaktadır. Bu kategori, veri yönetiminin müşteri ve verileri hazırlayan tarafların her ikisinde de sağlıklı olarak sağlanabilmesi açısından veri transferi kategorisi ile yakın bir ilişki içindedir.

İhtiyaç olması halinde, tedarikçilerin S1000D uyumlu veri üretmediği durumlarda ilgili verilerin teslimi ve kabulü ile ilgili süreçlerin tanımlandığı iş kuralları da bu kategoride ele alınabilir.

İş akışları ve kalite kontrol ile ilgili iş kuralları da bu veri bütünlüğü ve yönetimi kategorisinin kapsamındadır. Bu kurallar da veri transferi kategorisi ile bağlantılıdır.

Veri bütünlüğü ve yönetimi kategorisi aşağıdaki kuralları içermekle beraber bunlarla sınırlı değildir:

* İş akışı ile ilgili kurallar (Hem firma içi hem de projede birlikte çalışan tüm taraflar arasındaki),
* Kalite kontrol ile ilgili kurallar.

Aşağıdaki karar noktası, bu kategoriye örnek teşkil etmektedir:

'''İş Kuralı Karar Noktası BRDP-S1-00017– Kalite kontrol kuralları''':

* Veri modülü ve teslimatlarla ilgili kalite control süreçlerini belirle.

=== 3.7.9. KATEGORİ 9- MEVCUT VERİLERİN YÖNETİMİ VE KULLANIMI ===
Mevcut veri kavramı, içerik olarak güncelliğini ve geçerliliğini koruyan ancak format ve yapı itibari ile S1000D uyumlu olmayan (kağıt baskı, S1000D’den farklı diğer formatlar vb.) verileri tanımlamaktadır.

Mevcut verilerin S1000D’de istenen formata dönüştürülmesi ve yönetilmesi ile ilgili iş kuralları, belli bir ölçüde S1000D’nin kapsamının dışında kaldığı için spesifikasyonda yer alan diğer iş kurallarından ayrılmaktadır. Bunun sebebi, mevcut verilerin formatının ve bu mevcut verilere S1000D uyumlu bir yapı kazandırılmasının firmadan firmaya ve projeden projeye değişiklik gösterecek olmasıdır.

Mevcut verilerin yönetimi ve kullanımı kategorisi aşağıdaki kuralları içermekle beraber bunlarla sınırlı değildir:

* Mevcut verilerin S1000D uyumlu hale dönüştürülmesi ile ilgili kurallar (bu kuralların içine, kaynak veri ile dönüştürüleceği S1000D formatı arasındaki eleman ve nitelik eşleştirmelerinin nasıl yapılacağı da girmektedir.).
* Mevcut verilerin teknik yayınlarda kullanım şekli ile ilgili kurallar.

Aşağıdaki karar noktası, bu kategoriye örnek teşkil etmektedir:

'''İş Kuralı Karar Noktası BRDP-S1-00542– IETM’de mevcut verilerin kullanım metodu''':

* Mevcut bilgiler için bunları IETM’de veri modülü içinde mi kapsanacağı yoksa referans mı verileceğini belirle.

=== 3.7.10. KATEGORİ 10- ÇIKTI YAPISI VE FORMATI ===
Bu kategori, S1000D verilerinin çıktı yapısı ve formatının (sayfa formatları, IETP formatları, çoklu ortam formatları, SCORM formatları, vb.) tanımlandığı iş kurallarını kapsamaktadır. Üretilen verilerin hangi kısımlarının hangi formatta yayınlanacağı konusunda taraflar arasında alınan kararlar bu kategoride belirtilmelidir.

Şemalarda kullanılan eleman ve niteliklerin, nihai çıktıda nasıl görüntüleneceği (biçim, font, renk, metinler arasındaki boşluklar vb.) ile ilgili detaylı açıklamalar bu kategoride tanımlanmalıdır. Bu kategori, verilerin oluşturulması kategorisi ile (özellikle metinsel verilerin oluşturulması – kategori 6a) oldukça yakın bir ilişki içindedir. Örnek vermek gerekirse; yazarlar hangi elemana bir metin yazdıkları zaman dokümanın nihai görüntüsünde bu metinlerin belireceğini bilirlerse tekrarlı veya hatalı iş yapılmasının önüne geçilmiş olacaktır.

Projede ihtiyaç duyulması halinde, S1000D’de önerildiği üzere fonksiyonellik matrisi oluşturulabilir. Projede alınan kararlar çerçevesinde fonksiyonellik matrisinin kullanılması, çıktı yapısı ve formatı üzerinde doğrudan etkili olacaktır.

Çıktı yapısı ve formatı kategorisi aşağıdaki kuralları içermekle beraber bunlarla sınırlı değildir:

* Üretilen verilerin hangi kısımlarının sayfa formatında hangilerinin IETP formatında yayınlanacağı,
* Sayfa formatı ve IETP formatının ekran görüntüsünün özellikleri,
* Hangi veri modüllerinin SCORM formatında yayınlanacağı,
* Hangi veri modüllerinin simülasyon formatında yayınlanacağı,
* Görünüm ve his ile ilgili kurallar.

Aşağıdaki karar noktası, bu kategoriye örnek teşkil etmektedir:

'''İş Kuralı Karar Noktası BRDP-S1-00304 – İçindekiler bilgisinin seviyelendirilmesi''':

* Seviyelendirimiş içerik bilgisinin kullanılmasına ve kaç seviyeye kadar inileceğine karar ver.

== 3.8. KARAR KATMANLARI ==
İş kuralı karar katmanı, belirlenen iş kurallarının proje paydaşları arasındaki hiyerarşisine göre seviyelendirilmiş halidir.

Katmanlı iş kuralı modelinde, bir alt katman kendisinin bir üst katmanında bulunan paydaşın belirlediği iş kurallarını doğrudan uygulamak zorundadır. Kesin bir tanımlama yapılmaması durumunda, kapsamını genişletebilir veya tamamen kendisi belirleyebilir.

Katmanlı yapı, aşağıdaki şekilde de belirtiği gibi projenin kapsamı ve kurumların yapısına göre Katman 2’den N’ye kadar arttırılabilir. Ancak katmanlı yapının ilk katmanı her zaman S1000D olmak zorundadır. Bu yapının genel işleyişinde alt katmanlara inildikçe iş kurallarının sayısında artış, belirlenmemiş iş kurallarının sayısında ise azalma meydana gelir. Bunun sebebi üst katmanlarda alınan kararların, alt katmanlar tarafından direkt uygulanacak olmasıdır. Bu nedenle alt katmanlara inildikçe yanıtlanması gereken iş kuralları, üst katmanın kendisiyle ilgili herhangi bir tanım ortaya koymadığı kurallarla sınırlı kalacaktır. Karar alıcıların hedefi, yazarların insiyatifine olabildiğince az karara bağlanmamış iş kuralı bırakmak olmalıdır.
[[Dosya:Şekil6 Katmanlı Yapı.jpg|alt=Şekil 6 Katmanlı Yapı|sol|küçükresim|378x378pik|Şekil 6 Katmanlı Yapı]]

Katmanlı yapıya bir örnek aşağıda sunulmuştur.
[[Dosya:Şekil7 Örnek Katmanlı Yapı.jpg|alt=Şekil 7 Örnek Katmanlı Yapı|sol|küçükresim|400x400pik|Şekil 7 Örnek Katmanlı Yapı]]

Proje paydaşları, kendi karar katmanlarında ihtiyaç duyulması halinde kendi iş kuralı karar noktalarını oluşturabilirler.

Her bir karar noktası (paydaşların kendi katmanlarında oluşturdukları da dahil olmak üzere) tüm paydaşlar tarafından değerlendirilmelidir.

İş Kuralları Arasındaki Uyumsuzlukların Çözülmesi

Yukarıda bahsedildiği gibi alt karar katmanı, üst karar katmanının aldığı kararlara uymak zorundadır. Bu durum, proje kapsamında üretilen teknik verilerin farklı müşterilere teslim edileceği hallerde çeşitli sorunlar yaratacaktır. İki farklı müşterinin iş kuralları arasındaki uyumsuzluk nedeniyle üretici firma hazırladığı teknik verileri her iki müşteri için ayrı ayrı hazırlamak ya da içerik filtresi kullanmak zorunda kalabilir.

Çok uluslu savunma projelerinde, her ulusun kendi iş kuralları bulunabilir. Bu durumda, teknik içeriklerin farklı iş kurallarına göre tekrar yazılmasını gerektirebilir. Aynı içeriğin iki farklı şekilde oluşturulması içeriklerin yönetilmesinde çeşitli sorunlar (bir içerik güncellenirken diğerinin güncellenmemesi, veri transferlerinde yanlış gönderiler yapılması vb.) yaşanmasına neden olacaktır. Bunu önlemek ya da sorunu en aza indirgemek için ulusların iş kurallarını ilgili proje için bir arada değerlendirip ortak bir noktada buluşturması önerilmektedir.

Benzer problemler farklı müşterilerle çalışan üreticilerin başına sıklıkla gelebilir. Örnek vermek gerekirse, ürettiği ürün hem sivil hem de askeri projelerde kullanılabilen bir üretici, iki müşterinin iş kuralları arasındaki uyuşmazlıklardan dolayı teknik verilerin her müşteri için ayrı ayrı veri hazırlamak zorunda kalabilir. Bu durumu önlemek için üretici firma, müşterileri ile iş kuralları konusunda mutabakat sağlamalıdır.

Ayrıca iş kuralları arasında farklılık bulunan proje paydaşlarının dokümantasyon süreçlerine başlamadan önce iş kuralları konusunda mutabakat sağlamaları, tekrarlı ve/veya hatalı iş yapılmasının önüne geçecektir.

Verilerin farklı iş kuralları nedeniyle tekrar tekrar yazılması, veri yönetimini içinden çıkılmaz bir duruma sokabilir. Bu nedenle herhangi bir katmanda iş kurallarının belirlenmesi konusunda görev alan kişilerin hem üreticilerin daha önce hazırlamış olduğu teknik verilerin tekrar kullanılabilirliğini sağlayıcı yönde, hem de proje ihtiyaçlarını karşılayacak şekilde optimum bir çözüm üretmesi gerekmektedir.

S1000D, verilerin tekrar tekrar hazırlanmasını önlemek açısından, özellikle RAHAT ürünlerin S1000D’de hazırlanmış teknik içeriklerini olduğu gibi kullanmayı tavsiye etmektedir.

Her üst katman belirlediği iş kuralları konusunda alt katmanları bilgilendirmelidir. Örnek vermek gerekirse; bir kurum, belirlediği kurumsal kararlar varsa projelerde çalışan firmaları aldığı bu kararlar konusunda bilgilendirmek zorundadır.

Projelerde belirlenen iş kuralları arasında; yukarıda verilen örneklere benzer çelişki yaratan durumların ortaya çıkması halinde, proje paydaşlarının tamamı ilgili sorunun çözüme ulaştırılmasında eşit derecede sorumluluk sahibidir. Sonuç olarak yaşanan çelişkilerin çözüme ulaştırılması aşağıdaki yöntemlerle sağlanabilir:

* Çelişki yaratan iş kurallarının koordineli bir çalışmayla hem müşterinin hem de üreticilerin ihtiyaç ve yaşayacağı sorunlar göz önünde bulundurularak değiştirilmesi veya bu kurallardan feragat edilmesi,
* Veri modüllerinin her proje için iş kurallarına göre baştan hazırlanması

== 3.9. PROJE KARARLARININ BELİRLENMESİ ==
İş kurallarının belirlenmesi, yaşayan bir süreçtir ve proje tamamlanana kadar devam edebilir. Belirlenen kuralların proje süresince yaşanan sorunlar/aksaklıklar, teknolojinin gelişmesi, bir takım yeni ihtiyaçların ortaya çıkması vb. sebeplerden ötürü değiştirilmesi gerekebilir. Ayrıca iş kurallarının tam olarak nasıl bir sırayla ve ne zaman belirleneceği o projenin kapsamına ve ihtiyaçlarına, dokümantasyon faaliyetlerinde bulunacak kurumların iş süreçlerine doğrudan bağlıdır. Bu ve benzer nedenlerden dolayı; hazırlanan bu rehber dokümanda, iş kurallarının belirlenmesi sürecinde, iş kuralı kategorilerinin belirlenme sırasıyla ilgili genel bir tablo ortaya konacaktır.
[[Dosya:Şekil8 İş Kuralı Kategorilerinin Belirlenmesi.jpg|alt=Şekil 8 İş Kuralı Kategorilerinin Belirlenmesi|sol|küçükresim|700x700pik|Şekil 8 İş Kuralı Kategorilerinin Belirlenmesi]]

Şekil 8 dokümantasyon süreçlerinden bağımsız olarak iş kurallarının ne tür bir zaman planı çerçevesinde tanımlandığını genel hatlarıyla ortaya koymaktadır. Başarılı bir dokümantasyon planı açısından iş kurallarının tanımlanmasına, sözleşme ve içerik geliştirme süreçlerinden önce başlanması tavsiye edilmektedir. Ancak S1000D uygulamalarının geneline bakıldığında, S1000D’nin uyumluluk için zorunlu tuttuğu ana kriterleri sağlayacak karar noktalarının belirlendiği, kalan kararların ise proje zaman planına yayılarak belirlendiği gözlemlenmektedir.

İş kurallarının tanımlanmasında ve uygulanmasında başarılı bir sonucun elde edilebilmesi için iş kurallarının hangi sırayla veya hangi zamanda tanımlandığından daha çok, bu tanımlama süresince kurumlar ve proje paydaşları arasındaki iletişimin ne kadar kuvvetli olduğu ön plana çıkmaktadır. Kararların mutabakat çerçevesinde alınması, herkesin belirlenen kurallardan aynı anlamı çıkartması, alınan bir kararın uygulamasında görülen zorluğun tüm tarafların ortak çalışmasıyla o karar noktası üzerindeki sorunları gidermesi projenin başarısı üstünde çok daha büyük bir etkiye sahiptir.

== 3.10. BREX VERİ MODÜLÜ ==
BREX veri modülü, S1000D’nin şemalarından birisi olan BREX şeması ile hazırlanır. Proje faaliyetleri içerisinde hazırlanan BREX veri modülü de tıpkı diğer veriler (veri modüleri, görsel nesneler, vb.) gibi bir CSDB nesnesidir.

Bu şemanın amacı; belirlenen iş kurallarının belirli bir formata göre standart bir şekilde dokümante edilmesini, proje kapsamında hazırlanacak olan veri modüllerinin hangi iş kurallarına göre yazıldığının tanımlanabilmesini ve denetlenebilmesini sağlamaktır.

İş kurallarını BREX şemasını kullanarak dokümante ederken yanlış anlaşılmaya mahal vermeyecek, net ve herkes tarafından aynı anlama gelecek açıklamalar kullanmak, iş kurallarının uygulanmasında yanlış anlaşılmalardan kaynaklanabilecek hataların ortaya çıkmasının da önüne geçmiş olur.

Aşağıda BREX veri modülünün kullanımı ile ilgili çeşitli örnekler belirtilmiştir:

* BREX veri modülü, projeye özgü veya kuruma ait iş kurallarının, kurumlar ve/veya proje paydaşları arasında paylaşılabilmesini sağlamakta kullanılabilir.
* S1000D’nin bazı seçenekli niteliklerinin kullanımında seçilen değerlerin doğru yorumlanabilmesini destekler. Örnek vermek gerekirse “gizlilik sınıflandırması” niteliğinin alabileceği değerler 01, 02, 03, …, 99 olabilmektedir. Bu değerlerin ne anlama geleceği BREX içinde tanımlanabilir. Bu sayede proje paydaşları “gizlilik sınıflandırması” niteliğinin aldığı değerlerin ne anlama geldiğini bilir.
* Hazırlanan CSDB nesnelerinin projenin ve/veya kurumun iş kurallarına uygun olarak hazırlanıp hazırlanmadığını kontrol etmekte kullanılabilir. Bu yöntemin uygulanma biçimi, kullanılan yazılımlara göre değişiklik gösterebilir.

Bir kurum veya proje ekibi, S1000D’de yer alan tüm yapıların (SNS yapıları, bilgi kümeleri, sayfa formatı vb.) olduğu gibi uygulanmasına karar verirse, varsayılan BREX veri modülünü uygulayabilir. Ancak kurumların iş kuralları ve/veya proje paydaşlarının proje kapsamında uygulanmak üzere kurumsal olarak tanımladıkları iş kuralları varsa, bu kuralların dokümante edilebilmesi için BREX veri modülü hazırlanmalıdır.

== 3.11. İŞ KURALLARI DOKÜMANI NEDİR? ==
İş Kuralları dokümanı, BREX veri modülünden farklı bir dokümandır. BREX veri modülü içerisinde; alınan kararların detaylarına, kararlarla ilgili örneklere ve çeşitli destekleyici materyallerin (görsel nesneler, vb.) kullanılmasına yer verilecek yeterlilikte alan bulunmamaktadır. Bu nedenle iş kurallarının ayrıca dokümante edilmesi, tanımlanan iş kurallarının projelerde uygulanabilmesi açısından bir gerekliliktir.

= 4. TEKNİK YAYIN HAZIRLAMA UYARLAMASI =

== 4.1. TEKNİK YAYIN SÜREÇ VE STANDARTLARININ UYARLANMASI ==
Projelerin Teknik Yayın ihtiyaçları; projenin tipi, tedarik yöntemi, ürün, teknik yayın tipi, kullanıcı gereksinimleri, proje takvimi, proje bütçesi vb. değişkenler nedeniyle farklılık gösterebilecektir. Bu sebeple projelerin sözleşme aşamasında, bu rehber dokümanda belirtilen yöntem ve gereksinimlerden hangilerinin hangi detayda ve gerekiyorsa hangi standart esas alınarak uygulanacağı, kullanıcı ihtiyaçları ve maliyet arasındaki optimum denge gözetilerek belirlenmelidir. Belirlenen gereksinimler ilgili projenin iş kuralları olarak Teknik Yayın Planında detaylı şekilde tariflenmeli ve Teknik Yayın hazırlama sürecinde uygulanmalıdır.

Projeler kapsamında hazırlanan Teknik Yayınlarda kurumsal standardizasyonların sağlanabilmesi için; genel yazım kurallarına ilişkin standartlar, teknik yayın tipleri ve bunlara göre ilgili kurumlarca hazırlanacak kurum içi yönergelerde belirtilmeli ve söz konusu standartlar, İş Kuralları olarak sözleşmelerin Doküman Veri İstek Listeleri kısımlarına ek olarak konulmalıdır.

Bununla birlikte projenin değişkenlerine göre Teknik Yayın Gereksinim Planlama Süreçlerinde göz önünde bulundurulması gerekli durumlardan bazıları aşağıda belirtilmiştir:

'''a. RAfta HAzır Ticari (RAHAT) Ürün Alım Projeleri Teknik Yayınları:'''

Proje kapsamında tedarik edilen RAHAT ürünlere ait teknik yayınlarda; bu ürünlerin üreticileri tarafından hazırlanmış olan teknik yayınlar şayet ilgili ürünün kullanımı ve bakımı ile ilgili yeterli bilgiyi içeriyorsa olduğu gibi kullanımı veya bazı sınırlı ilavelerle yeterli duruma getirilmesi uygun olacaktır. Ancak mevcut üretici teknik yayınlarında daha kapsamlı revizyon ihtiyacı olan durumlarda, ürünün üreticisi tarafından bunların yeniden yazılması seçeneği değerlendirilmelidir.

'''b. AR-GE/MÜ-GE Projeleri Teknik Yayınları:'''

Yeni ürün tasarım ve geliştirme projeleri kapsamındaki ürünlere yönelik olarak; teknik yayınların uygun şekilde oluşturulabilmesi için gerekli LDA süreçleri işletilerek işletme ve idame için gerekli bilgi ve verilerin toplanması/oluşturulması sağlanmalıdır. Bu tip projelerde orijinal malzeme üreticilerinden gerekli bilgiler (sökme-takma talimatları vb.) alınmalıdır. İhtiyaç duyulacak bakım onarım teknik verileri ve teknik yayınları ile ikmal desteğine ilişkin katalog ve liste gereksinimleri, İhtiyaç Makamlarının bakım kademeleri ve proje lojistik destek konsepti dikkate alınarak belirlenmelidir.

'''c. Hazır Alım Projeleri Teknik Yayınları:'''

Hazır Alımı yapılan projelerin Teknik Yayınlarının baştan geliştirilmesi oldukça yüksek bir maliyet gerektireceği ve LDA süreçlerinin çoğunun tamamlandığı bir dönemde icra edildiğinden, Üretici veya Yüklenicinin yeni bir veri seti üretmesi beklenmemeli ancak üretilmiş olan verilerin düzenlemesi ve sunumuna yönelik ihtiyaçların karşılanması hedeflenmelidir.

Sistem üreticileri açısından farklı proje tipleri, ürünler ve müşteriler için ortaya çıkan farklılıkları kolaylıkla yönetebilmenin yöntemi, teknik yayın veri tabanları ile verinin oluşturularak istenilen çıktı içeriği ve formatına hızlıca uyarlanmasını sağlamaktır.

== 4.2. BASILI TEKNİK YAYIN İLE ETKİLEŞİMLİ ELEKTRONİK TEKNİK YAYIN (IETM/P) HAZIRLAMA ARASINDAKİ FARKLAR ==
Bu rehber dokümanının önceki bölümlerinde bahsedildiği üzere teknik yayın hazırlama süreçlerinin temel adımları benzer olmakla birlikte, sürecin ana çıktısı olan teknik yayının basılı kopya formatında hazırlanması ile Etkileşimli Elektronik Teknik Yayın (IETM/P) olarak hazırlanması farklı süreç adımları ve altyapı gereksinimlerine sahiptir. Söz konusu farklılıklar ve gereksinimler aşağıda özet olarak belirtilmiştir:

'''a. Basılı Teknik Yayın Hazırlama Süreçleri ve Uygulamaları:'''

Basılı teknik yayınlar; sistem ve ürünlere ilişkin teknik veri ve bilgilerin kullanıcı ihtiyaçları doğrultunda yapılan sınıflandırmaya göre ayrı el kitapları, kataloglar ve listeler şeklinde kağıt ortamında basılı hale getirilerek, sayfa bazlı olarak okuyucuya sunulduğu yayınlardır. Basılı yayınlar, hazırlanan teknik yayın planları doğrultusunda ayrı kitap, cilt, fasikül, bölüm, kısımlar olarak belirlenen yazım kural ve şablonları kullanılarak, genellikle kelime işleme yazılımları vasıtasıyla elektronik ortamda oluşturulmakta, renkli veya renksiz şekillerde basılı hale getirilmektedir.

'''b. Etkileşimli Elektronik Teknik Yayın (IETM/P) Hazırlama Süreçleri ve Uygulamaları:'''

Teknik yayınlar doğrudan kağıt medya üzerinde basılı olarak hazırlanabileceği gibi elektronik ortamlarda da hazırlanabilmektedir. Elektronik ortamda hazırlanan teknik yayınlar Elektronik Teknik Yayın (ETM) olarak isimlendirilmektedir.

Etkileşimli Elektronik Teknik Yayın (IETM/P), ürünlerin tanımlayıcı bilgileri, kullanım ve bakım onarımına yönelik olarak son kullanıcıya elektronik görüntüleme araçları (monitör, dizüstü bilgisayar, tablet vb.) aracılığı ile etkileşimli ekran sunumu şeklinde aktarılmak üzere editör yazılım araçları kullanılarak elektronik ortamda “hazırlanan” veya “yazılan” bilgi kümelerinden oluşan teknik yayınlardır.

IETM aşağıdaki temel özelliklere sahiptir:

* Bilginin formatı ve biçimi, ekran üzerinde görüntü bazlı olarak (sayfa bazlı değil) gösterilirken azami ölçüde kavranabilirliği sağlayacak şekilde ayarlanır.
* Teknik Yayınları oluşturan teknik bilgi bileşenleri arasındaki ilişkinin yapısı kullanıcın ihtiyaç duyduğu bilgiye farklı yollardan erişimi için geniş olanaklar sağlar.
* Bilgisayarlar, dizüstü bilgisayarlar ve tablet gibi görüntüleme araçları; ihtiyaç duyulan prosedür adımlarının, yönlendirme talimatlarının ve ilave bilgilerin etkileşimli olarak aktarılmasını sağlarlar.
* Ekran üzerindeki sunumlar; ilişkisel veri tabanında metin, grafik, ses ve/veya video şeklinde depolanan materyallerin mantıksal olarak ilişkilendirilmesi ile oluşturulan ve rasgele erişilebilir IETM veri bileşenlerini içerebilmektedir.
* IETM, kullanıcı geri bildirimlerine göre oluşturulabilen koşullu dallandırma mekanizmalarına sahiptir. Değişkenler kullanım sırasında değerlendirilir ve değerleri içeriğe ve kullanıcı girdilerine bağlıdır.

ETM’ler özelliklerine ve kabiliyetlerine göre 6 sınıfa ayrılmaktadır. Sınıf 0’a giren teknik yayınlar; herhangi bir etkileşimli özelliğe sahip olmamalarından ötürü yalnızca ETM olarak tanımlanmakta, diğer sınıflara giren teknik yayınlar ise etkileşimli özelliklere de sahip olduklarından Etkileşimli Elektronik Teknik Yayın (IETM) olarak tanımlanmaktadır. Teknik yayın sınıfları ile ilgili açıklamalar aşağıda yer almaktadır:

'''Sınıf 0 – İndekslenmeden Taranan ETM’ler:''' Bu sınıfa giren ETM’ler, basılı dokümanların hücresel (raster) görsel olarak tarandığı ve elektronik ortama aktarıldığı dokümanlardır. Ancak bu dokümanları oluşturan taranmış sayfalar indekslenmemektedir. Bu tip dokümanlarda mükerrer bilgiler olabilmektedir. Bu durum aynı bilgileri tekrar yazmak için emek sarfiyatı gerektirdiğinden istenen bir durum değildir.

'''Sınıf I – İndekslenerek Taranan IETM’ler:''' Bu sınıfa giren IETM’ler, basılı dokümanların hücresel (raster) görsel olarak tarandığı ve elektronik ortama aktarıldığı dokümanlardır.

Sınıf-I (Sayfa Görüntüsü Görüntüleme Sistemleri) teknik yayın sistemlerinde kullanılan görüntü saklama ve görüntüleme teknolojisi bir belgenin tam sayfa kodlamasını kullanır (örneğin, Postscript sayfa açıklama dili). Bu sınıfın elektronik-ekran versiyonu, kullanıcının akıllı bir dizin kullanarak sayfa çevirme ve sınırlı arama özelliğine sahip bir ekranda tam sayfa görüntüyü görüntülediği versiyondur. Bu sistemler, verinin sayfa bütünlüğünü değiştirmeksizin mümkün olduğunca etkileşimli özelliklere sahiptir. Sınıf-I teknik yayın sistemleriyle ele alınan basit teknik yayınlar, elektronik ekran için yazılmamıştır.

Bu dokümanların kapak sayfası otomatik olarak oluşturulmaktadır. Kapak sayfasında bulunan linkler aracılığı ile taranmış sayfalara erişim mümkündür. Bu tip dokümanlarda mükerrer bilgiler olabilmektedir.

Sınıf-I teknik yayınlar basılı yayınların aşırı alan kaplama, ağırlık gereksinimleri ile baskı kağıdı ve sayfa değişim güncellemeleriyle doküman idamesi sorunlarının önlenmesini sağlayan görece olarak düşük maliyetle oluşturulabilen teknik yayınlardır.

'''Sınıf II – Aşağı ve Yukarı Yönlü Kaydırılabilen IETM’ler:''' Bu sınıfa giren IETM’ler, fonksiyonel özelliklerin Sınıf 0 ve Sınıf I’e giren teknik yayınlara göre artış gösterdiği, metinlerin resim olarak tutulmayıp bilgisayar dili ile kodlandırıldığı dokümanlardır.

Sınıf-II (Sayfa Odaklı Teknik Yayınların Köprü Metni Görünümü.) teknik yayın sistemleri, mevcut sayfa odaklı teknik yayınların elektronik geri alma ve görüntüleme kapasitesine uyarlamak için özel olarak tasarlanmış sistemlerdir. Bu uygulamaların birçoğunda, mevcut sayfa görüntüleri çeşitli şekillerde sayısallaştırılır, dizin oluşturma ve çapraz referanslama bilgileri mümkün olan en iyi şekilde eklenir. Bu dokümanların kapak sayfası otomatik olarak oluşturulabilmektedir. Kapak sayfasında bulunan linkler aracılığı ile doküman içeriklerine erişim sağlanabilmektedir. Hatta metinler arasında da linkler oluşturulabilmektedir. Bu dokümanlarda Sınıf 0 ve Sınıf I’de olmayan bir diğer özellik ise doküman içeriği üzerinde çeşitli değişiklikler yapılabiliyor olmasıdır. Adobe firmasının geliştirmiş olduğu dosya formatı olan PDF, Sınıf II IETM’lerin sahip oluğu özellikleri taşımaktadır. Bu tip dokümanlarda mükerrer bilgiler olabilmektedir.

Sınıf-II teknik yayınlar, mevcut teknik yayınların gereksinimlerine göre geleneksel yayın sistemi kullanılarak oluşturulmuş olan dokümanlara etkileşimli sunum kabiliyeti eklenmesini sağlar.

Diğer uygulamalar, genellikle orijinal belgeyi hazırlamak için kullanılan otomatik yayınlama sistemiyle ilişkilendirilmiş olup, çevrimiçi doküman görüntüleyicileri içerir. Sınıf-II teknik yayınlar genellikle SGML görüntüleyiciler ile görüntülenmektedir.

'''Sınıf III – Lineer Yapılı IETM’ler:''' Bu IETM’ler; içeriklerin eğitim, bakım vb. fonksiyonel paketler halinde görüntülenebileceği ara yüze sahiptir.

Sınıf-III (Köprü Metni IETM’leri) teknik yayın sistemleri, orijinali sayfa formatında basılı teknik yayın oluşturmak üzere tasarlanmış teknik yayınların, bir IETM biçiminde gösterilmek üzere dönüştürme işlemlerini gerçekleştirir. Söz konusu dönüştürme işleminin yapılabilmesi için doküman içeriğinde yer alan metinlerin IETM yazım standartlarında belirtilen metin etiketleri kullanılarak oluşturulması gerekir.

Bu sınıfta hazırlanan IETM’ler ile ses dosyaları, videolar veya diğer sistem ve yazılımlar arasında linkler oluşturulabilmektedir. Bu tip dokümanlarda mükerrer bilgiler olabilmektedir.

Sınıf-III teknik yayınlar, mevcut yayınların IETM biçimine dönüştürülmesine olanak sağlayarak, kağıt kullanımının kaldırılmasından elde edilen faydalara ilave olarak teknisyen performansının arttırılmasına imkan oluşturmaktadır.

Sınıf-III teknik yayın sistemleri, mevcut teknik yayın dosyalarının, Sınıf-IV sistemlerin (yani, IETM Veri Tabanı Sistemleri) çoğu özelliği ile elektronik ekrana dönüştürülebilmesi için bir geçiş adımı oluşturur.

'''Sınıf IV – Hiyerarşik Yapılı IETM’ler:''' Bu sınıfa giren IETM’lerin önceki sınıflandırmalara göre en büyük farkı, mükerrer bilgilerin olmaması veya çok aza indirilmesine olanak sağlamasıdır.

Sınıf IV IETM’lerde verilerin hazırlanması ve yönetimi diğer ETM sınıflarından oldukça farklıdır. Sınıf-IV teknik yayın sistemleri (Veri Tabanı Yönelimli IETM); teknik yayın verilerinin bir bilgisayar tarafından etkileşimli olarak gösterimi için gerekli, veri bileşenlerini ve özelliklerini içeren bir veri tabanı formuna özel olarak yazıldığı sistemlerdir.

Sınıf-IV teknik yayın hazırlama sürecinde öncelikli olarak IETM veri bileşenleri ile bu bileşenlerin özellik ve bağlantı bilgilerini içeren ilişkisel veya nesne yönelimli bir veri tabanı oluşturulur. Veriler modüler olarak hazırlanır ve yapısal veri tabanı içerisinde tutulur. Veri tabanında oluşturulan verilerin, bakım yardımcısı gibi bir elektronik görüntüleme sisteminde görüntülenebilmesi için teknik yayın yayımlama yazılım araçları vasıtasıyla veri tabanından çekilerek derlenmesi ve biçimlendirilmesi gereklidir. (Örn: Uyarı ve İkazlar bir kez yazılıp tekrar kullanılabilmektedir.) Fonksiyonel özellikler açısından Sınıf III IETM’lerin sergileyebildiği tüm fonksiyonel özellikleri sergileyebilmektedir.

Sınıf IV teknik yayınlar, elektronik ortam kullanımına özel olarak yazıldığından ve idamesi sağlandığından, elektronik ortamın olanaklarının en iyi şekilde kullanılmasını sağlarlar.

'''Sınıf V – Veri Tabanı ile Entegre IETM’ler:''' Sınıf-V teknik yayınların kapsamını gelişen teknolojik olanaklar şekillendirdiğinden, net olarak tanımlamak güçtür. Sınıflandırma şemasına dahil edilmesi, diğer otomatik Teknik Yayın sınıflarından daha iyi performans elde etmek için gösterilebilecek, gelecekteki çeşitli entegre kavramları öngörmeyi amaçlamaktadır.

Sınıf-V (Entegre İşlem IETM) teknik yayın sistemleri, kullanıcıya IETM özelliklerinin yanı sıra sağladığı bilgisayar programları veya uzman-sistem işlem yazılımları ile etkileşim kabiliyetleri ile diğer teknik yayınlarından farklılaşır. Bu sınıfa giren IETM'ler, fonksiyonel özellikler açısından Sınıf IV IETM'lerin sergileyebildiği tüm fonksiyonel özellikleri sergileyebilmektedir. Ayrıca teknik yayında yer alan içerikler ile yazılımlar ve cihazlar arasında etkileşime müsaade etmektedir.

Sınıf V teknik yayınların, daha iyi bir performans sağlamasının yanı sıra, bilginin kullanıcıya sunumunun etkinliğinin artırılması için; sunum sırasında gerçekleştirilen tam zamanında eğitim sistemi, aktif uzman öneri sistemi veya bilgisayarlı teşhis işlemi gibi ek uygulamaları IETM'in kapsamına entegre etmesi beklenir. Bu programlar arıza teşhis ve sorun giderme işlemleri sırasında veya Bilgisayar Tabanlı Eğitimler sırasında gerekli bakım bilgilerine erişim için Uzman Sistem işlemleri gibi kullanıcıya rehberlik edecek akıllı bilgiler sağlarlar. Bu prosedürler, Sınıf-IV kabiliyetleri kapsamında kullanıcı kontrolünde başlatılan IETM bilgisi gösterimlerini destekleyen, Uzman Sistem programı tarafından başlatılan, etkileşimli diyalogu içerirler.

Sınıf V teknik yayınlar da Sınıf IV gibi, elektronik ortam kullanımına özel olarak yazıldığından ve idamesi sağlandığından, elektronik ortamın olanaklarının en iyi şekilde kullanılmasını sağlarlar.

Sınıf-V teknik yayın uygulamaları, Sınıf-IV IETM veri tabanında olduğu gibi özenle oluşturulmuş, önceden yazılmış bilgileri içeren veri tabanına dayanan bir sistemde çalışmak için çok uygundurlar ve böyle bir IETM veri tabanının doğal bir uzantısı olarak tasarlanabilirler. Sınıf-V veri tabanları, IETM ile entegre yazılım ürünlerini (örneğin, bilgisayar destekli işlemler veya uzman sistem yazılımlarını) ve ayrıca teslim edilen ürünler olarak teknik bilgileri içerir.

'''c. Basılı Yayın ile IETM Arasındaki Temel Farklar:'''

* Basılı Yayında içerik tüm okuyucular için sabit şekilde oluşturulurken IETM’de kullanıcının bilgi seviyesine uygun şekilde içerik sunumu yapılabilmektedir. Başlangıç Yetenek Seviyesi ve Uzman Yetenek Seviyesi gibi seviye bazlı içerik tipleri oluşturularak okuyucu bilgi düzeyine göre ilgili prosedürler en basit adımları da içerecek şekilde veya basit işlem adımlarının detayları kapalı şekilde okuyucuya aktarılabilmektedir.
* Dikkat, Uyarı ve Not gibi teknik yayın kısımları basılı yayında sabit bir görsel olarak okuyucuya aktarılırken, IETM’de okuyucunun dikkatini daha fazla çekecek şekilde görselleştirilerek aktarılması mümkündür.
* Basılı Yayında ilgili bilgiler okuyucuya metin, çizim veya renkli-renksiz fotoğraf gibi sabit görseller kullanılarak aktarılırken; IETM’de 3B hareket ettirilebilir katı model görselleri, animasyonlu görseller, sesli ve hareketli medya kullanımı, kullanıcı etkileşimi sağlayan hotspot vb. teknik yayın anlaşılabilirliğini arttıracak sunum yöntemleri kullanılmasına olanak sağlamaktadır.
* Basılı yayında okuyucunun okuma sırasında yönleneceği referans bilgi ve kısımlara erişim için sayfa çevirme ve arama eforunu elle yapması söz konusuyken, IETM’de okuyucu teknik yayın içerisinde sağlanan link adreslerine tıklayarak ilgili kısımlara vakit ve dikkat kaybı yaşamadan erişebilmektedir.
* Basılı yayında okuyucunun ihtiyaç duyduğu anlık bilgilere erişimi için dizin ve içindekiler tablosu üzerinden birçok bilgiyi gözden geçirmek zorunluluğu söz konusu iken; IETM’de sunulan arama ve yardım menüleri üzerinden aranılan bilgilerin tamamına vakit ve dikkat kaybı yaşamadan erişim imkanı bulunmaktadır.
* Basılı yayınların güncellenme, dağıtım ve teknik yayın konfigürasyon kontrolünün sağlanması eforları çok daha fazla zaman, yüksek maliyet ile gecikme ve hata riskleri meydana getirirken; IETM’de doküman güncelleme, dağıtım ve konfigürasyon kontrolü faaliyetleri daha kısa sürede ve daha az riskle daha sağlıklı şekilde gerçekleştirilebilmektedir.
* Basılı yayında okuyucunun ilgili tedarik kataloglarını kullanarak bir tedarik faaliyetini başlatması manuel süreç esasları ile yürütülmek durumundayken, IETM’de bu süreç mevcut bilişim politikalarının izin vermesi durumunda çevrimiçi olarak internet ağı üzerinden çok hızlı şekilde düşük efor ve düşük hata ile yürütülebilmektedir.
* Basılı yayınların fiziksel olarak muhafazası, ilave alan, erişim güvenliğinin sağlanması ve teknik yayınların idame ettirilmesi bakımından daha fazla kaynak gereksinimine sahipken; IETM sistem üzerinde gömülü olarak kullanılabilmekte, fiziksel olarak ilave alan gereksinimini ortadan kaldırılabilmekte, erişim güvenliği açısından şifreleme ve hızlı şekilde güncelleme yapılabilmesine olanak sağlamaktadır.

= EK-A =

== İŞ KURALLARI İNDEKSİ ==

Tedarik makamlarınca belirlenen/belirlenebilecek veya bir proje çerçevesinde yükleniciler tarafından cevaplanarak dokümante edilmesi beklenen/beklenebilecek <ins>iş kurallarının listesi aşağıda belirtilmiştir.</ins>

Bu listede yer verilmeyen iş kuralı karar noktalarının tümü, bir alt karar katmanına bırakılmıştır.

Bu tablodaki ID sütunu S1000D 4.1 Spesifikasyonundaki İş Kurallarına verilen referansı göstermektedir. Karar sütunu ise, Teknik Yayın hazırlamada uygulanacak karar ve önerileri göstermektedir.
{| class="wikitable"
|'''ID'''
|'''Başlık'''
|'''Açıklama'''
|'''Karar'''
|'''Kategori'''
|-
|BRDP-S1-00001
|"I" ve " "O" karakterlerinin kullanımı
|"I" ve "O" karakterlerinin nerelerde ve nasıl kullanılacağına karar ver.
|Veri modül kodlamasında Model Tanımlama Kodu dışında “I” ve “O” harfleri kullanılmayacaktır. Verilerde kullanılacak kodlamalarda kararlar alt katmanlar tarafından alınacaktır.
|2
|-
|BRDP-S1-00003
|Uygulanacak S1000D versiyonu
|S1000D’nin hangi versiyonunun veya versiyonlarının uygulanacağına karar ver.
|Versiyon 4.1 ve üstü olacak şekilde alt katmanlar tarafından karar verilecektir.
|1
|-
|BRDP-S1-00004
|Kullanılacak bilgi kümeleri
|Kullanılacak bilgi kümelerine (S1000D’de yer alan ve/veya projeye özgü hazırlanan/hazırlanacak olan bilgi kümeleri) karar ver.
|Bir alt katman karar verecektir.
|3
|-
|BRDP-S1-00005
|Üretilecek yayınlar
|Hangi yayınların hazırlanacağına karar ver.
|Bir alt katman karar verecektir.
|1, 3, 10
|-
|BRDP-S1-00006
|Şema kullanımı
|S1000D’nin hangi şemalarının kullanılacağına ve bu şemaların bilgi kümeleri içinde nasıl kullanılacağına karar ver.
|Minimum PM, BREX, tanımlama (descriptive) şemaları kullanılacaktır. Diğer şemaların kullanımına proje ihtiyacına göre alt katmanlar tarafından karar verilecektir.
|1, 6a
|-
|BRDP-S1-00008
|Teslimat kalemleri
|Teslimat kalemlerinin ne olacağına karar ver:

· S1000D nesnelerinin (veri modülleri, yayın modülleri, görsel öğelerin listesi ve çoklu ortam nesneleri, veri modül listeleri, vb.) dosya tabanlı transfer metodu ile teslimi.

· Sayfa formatlı yayınlar ve/veya etkileşimli elektronik teknik yayınlar (IETM)
|Bir alt katman karar verecektir.
|1, 10
|-
|BRDP-S1-00012
|Gizlilik sınıflandırması değerleri ve şartlarına karar ver (Gizlilik sınıflandırması ataması)
|Gizlilik sınıflandırması ataması için hangi değerlerin kullanılacağına karar ver ve uygun tanımları belirle. Bkz: Bölüm 3.9.6.1
|MSY 317-2 (C) *

SSM-RHB-3500 / 001 *

“01” Tasnif Dışı

“02” Hizmete Özel

“03” Özel

“04” Gizli

“05” Çok Gizli

Olarak kullanılacaktır.
|4
|-
|BRDP-S1-00013
|Gizlilik sınıflandırmasının kullanımı ve işaretleme (gizlilik sınıflandırması atama)
|Gizlilik sınıflandırmasının nasıl kullanılacağına karar ver.
|Bkz. MSY 317-2 (C) *

'''2. Bölüm, 2. Konu, e maddesi'''

Bir data modülü içindeki bilgilerden herhangi birinin gizlilik derecesi “Tasnif Dışı”ndan yüksek ise o bilginin yazıldığı elementte bulunan securityClassification attribute’u kullanılarak bu bilgi tanımlanır.

Data modülün gizlilik derecesi, o data modülü içindeki en yüksek gizlilik derecesini taşıyan içeriğe göre belirlenir.
|4
|-
|BRDP-S1-00016
|Gizlilik sınıflandırmasının sunumu
|Gizlilik sınıflandırmasının nasıl gösterileceği/işaretleneceğine karar ver.
|Bkz. MSY 317-2 (C) *

2. Bölüm, 2. Konu, d maddesi
|4
|-
|BRDP-S1-00020
|Dili belirle.
|Data modülleri üretmek için hangi dilin kullanılacağına karar ver.
|Data Modüllerinin yazıldığı dil Türkçe olacaktır. Ancak proje özelinde tedarik makamı başka dillerin kullanımına da müsaade edebilir.
|6a
|-
|BRDP-S1-00022
|Standart sözlük
|Data modülleri üretmek için hangi standart sözlüğün kullanılacağına karar ver.
|Bir alt katman karar verecektir.
|6a
|-
|BRDP-S1-00023
|Terminoloji Veri Tabanı veya Sözlüğünün kullanımı
|Terminoloji Veri Tabanı mı Sözlük mü kullanılacağına karar ver. İçerikler ve yönetimi konusunda uzlaşma sağla.
|Tedarik makamı/ihtiyaç makamı tarafından belirlenecektir. Ancak ihtiyaç olması halinde bir alt katman tarafından karar verilecektir.
|6a
|-
|BRDP-S1-00024
|Kısaltmalar için standart liste kullanımı.
|Standart Kısaltma Listesi kullanılıp kullanılmayacağına karar ver. Kullanılacaksa içeriği ve yönetimi konusunda uzlaşma sağla.
|Bir alt katman karar verecektir.
|6a
|-
|BRDP-S1-00025
|Ölçüm Birimleri
|Birincil ve ikincil birimler için hangi ölçüm biriminin kullanılacağına karar ver.
|Türkiye’de üretilen tüm donanımlar için SI birim sistemi, RAHAT ürünler için ise dokümanda geçtiği haliyle kullanılmalı.
|6a
|-
|BRDP-S1-00026
|Vurgulanacak Metinler
|Metin vurgulama için hangi yöntemin kullanılacağına karar ver.
|Vurgulamalar yalnızca harflerin kalınlaştırılması ile verilecektir.
|6a
|-
|BRDP-S1-00036
|Başlık sayfasında revizyon ve taslak sürüm bilgisinin belirtilmesi
|Başlık sayfasında revizyon ve taslak sürüm bilgisinin kullanılıp kullanılmayacağınakarar ver.
|Kapak sayfasında versiyon/revizyon bilgisi bulunacaktır.
|6a, 10
|-
|BRDP-S1-00047
|Ülke ve Dil Kodları
|Kullanılacak ülke ve dil kodlarına karar ver ve proje boyunca aynı şekilde kullan.
|ISO 639 codes

Örneğin:

Ülke Kodu: TR

Dil Kodu: tur
|5
|-
|BRDP-S1-00052
|Bilgi Kodu ve Adlandırmalarının belirlenmesi
|Hangi bilgi kodu ve ilgili bilgi adlarının kullanılacağına karar ver, kullanılacak her bilgi kodu için bir şema ata.
|Bir alt katman karar verecektir.
|3, 5
|-
|BRDP-S1-00069
|<logo> elementinin kullanımı
|<logo> elemanının kullanılıp kullanılmayacağına ve kullanılacaksa fiziksel adının ne olacağına (ICN kodu) karar ver.
|Bir alt katman karar verecektir.
|5, 10
|-
|BRDP-S1-00121
|Standart tablo tiplerinin kullanımı
|Proje’de geçerli olacak standart tablo tiplerini tanımla ve bu tablo tipleri için hangi iş kurallarının tanımlanması gerektiğini belirle.
|Bir alt katman karar verecektir.
|6a
|-
|BRDP-S1-00122
|Tabloların şekil olarak kullanımı
|Tabloların data modül içeriklerinde şekil olarak kullanılıp kullanılmayacağına karar ver. Kullanılacaksa hangi koşullar altında kullanılacağını tanımla.
|Bir alt katman karar verecektir.
|6a
|-
|BRDP-S1-00304
|Hiyerarşik “İçindekiler” sayfası kullanımı
|Hiyerarşik “İçindekiler” sayfası kullanılıp kullanılmayacağına karar ver. Eğer kullanılacaksa kaçıncı seviyeye inileceğini belirle.
|En çok 5 seviyeye kadar inilecektir.
|6a, 10
|-
|BRDP-S1-00306
|İçindekiler sayfasında versiyon bilgisi ve/veya tarihinin kullanımı
|İçindekiler sayfasında listelenecek içeriklerin versiyon bilgilerinin (<issueInfo>/<externalPubIssueInfo>) ve/veya tarihlerinin (<issueDate>/<externalPubIssueDate>) kullanılıp kullanılmayacağına karar ver.
|İçermeyecektir.
|6a, 10
|-
|BRDP-S1-00310
|S1000D’de hazırlanmış içeriklerin toplam sayfa sayısının nasıl derleneceği
|S1000D’de hazırlanmış içeriklerin toplam sayfa sayısının derlenmesinde <footnoteRemarks> elemanının kullanımına karar ver.
|Bir alt katman karar verecektir.
|6a, 10
|-
|BRDP-S1-00328
|S1000D terminolojisinin çevirisi
|Müsaade edilen özellik değerlerinin projeye uygun dile çevrilip çevrilmeyeceğine karar ver.
|Türkçe tanımları kullanılacak.

Ancak proje özelinde tedarik makamı başka dillerin kullanımına da müsaade edebilir.

Bkz.: AÇG 1.2 Terminoloji Rehberi *
|6a
|-
|BRDP-S1-00331
|Data modülü kodlama stratejisi
|Ürün ve/veya projede uygulanacak data modülü kodlama stratejisini belirle.
|Bir alt katman karar verecektir.
|2, 3, 5
|-
|BRDP-S1-00336
|Ürün SNS yapısı
|Hangi SNS yapısının kullanılacağına karar ver.
|Bir alt katman karar verecektir.
|2
|-
|BRDP-S1-00337
|Malzeme kategorisi kodunun kullanımı
|Malzeme kategorisi kodunun kullanımına karar ver.
|Bir alt katman karar verecektir.
|2
|-
|BRDP-S1-00366
|Proje’ye özgü BREX data modülü kullanımı
|Projeye özgü BREX data modülü hazırlanıp hazırlanmayacağına karar ver.
|Her projede, proje ihtiyacını yansıtan BREX data modülü hazırlanacaktır.
|1, 5
|-
|BRDP-S1-00475
|Sayfa boyutu
|Her yayın için sayfa boyutlarına (Katlı (foldout) sayfalar da dahil) karar ver.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00476
|Sayfa formatlı yayınlarda katlı (foldout) sayfaların gösterimi
|Sayfa formatlı yayınlarda katlı (foldout) sayfaların hangi koşullar altında gösterileceğine karar ver.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00477
|Taslak numarasının gösterimi
|Taslak numarasının gösterilip gösterilmeyeceğine karar ver. Karar detayları dokümante edilmelidir.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00478
|“… Tarafından Hazırlanmıştır” – “Basımı …’da Yapılmıştır” ifadelerinin gösterimi
|Yayınların kim tarafından hazırlandığı veya basımının nerede yapıldığı bilgisinin görüntülenip görüntülenmeyeceğine karar ver.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00480
|Data modülü kodunun gösterimi
|Data modülü kodunun alt bilgide görüntülenmesinde S1000D’de yer alan standart yöntemin mi yoksa projeye / kuruma özgü bir yöntemin mi kullanılacağına karar ver.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00481
|Versiyon tarihinin gösterimi
|Versiyon tarihinin alt bilgide görüntülenmesinde S1000D’de yer alan standart yöntemin mi yoksa projeye / kuruma özgü bir yöntemin mi kullanılacağına karar ver.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00482
|Sayfa numaralarının gösterimi
|Sayfa numaralarının alt bilgide görüntülenmesinde S1000D’de yer alan standart yöntemin mi yoksa projeye / kuruma özgü bir yöntemin mi kullanılacağına karar ver.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00485
|Gizlilik derecelendirmesinin görüntülenmesi
|Gizlilik derecelendirmesinin görüntülenmesi sırasında ibarenin tüm harflerinin büyük mü yoksa baş harfinin büyük diğerlerinin küçük mü olacağına karar ver.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00487
|Gizlilik derecelendirmesi olmayan yayınlarda gizlilik derecelendirmesinin gösteriminin hariç tutulması
|Gizlilik derecelendirmesi olmayan yayınlarda gizlilik derecelendirmesinin gösterilip gösterilmeyeceğine karar ver.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00489
|<logo> elemanının gösterilmesi
|Basılı dokümanlarda <logo> elemanında yer alan logo tipi seçeneklerinden herhangi birisinin kullanılıp kullanılmayacağına karar ver. Bu elemanın nasıl görüntüleneceğine karar ver. (Örn: boyutu, renkleri, vb.)
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00490
|“Data Modülü Sonu” ifadesinin gösterimi
|Data modülünün sona erdiğini tanımlayacak ifadenin nasıl kullanılacağına karar ver. (“Data Modülü Sonu” olarak mı yoksa “Sonu” ifadesinden önce data modülü başlığının kullanılması yolu ile mi?)
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00491
|“Data Modülü Sonu” ifadesinin sayfa üzerindeki yerleşimi
|“Data Modülü Sonu” ifadesinin sayfa alt bilgisine mi yoksa sayfanın metin alanında mı görüntüleneceğine karar ver.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00496
|Doküman başlığının gösterimi
|Doküman başlıklarının gösterim yerini belirle.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00498
|Tablolar dizininin gösterimi
|Tablolar dizininin görüntülenip görüntülenmeyeceğine karar ver.
|Her dokümanda tablolar listesi bulunacaktır.
|10
|-
|BRDP-S1-00499
|Tablolar dizininde “Tablo” ifadesinin kullanımı
|Tablolar dizininde “Tablo” ifadesinin tablo numaralarından önce kullanılıp kullanılmayacağına karar ver.
|Tablolar listesinde Tablo ön eki bulunacaktır.
|10
|-
|BRDP-S1-00500
|Şekiller dizininin gösterimi
|Şekiller dizininin görüntülenip görüntülenmeyeceğine karar ver.
|Her dokümanda şekiller listesi olacaktır.
|10
|-
|BRDP-S1-00501
|Şekiller dizininde “Şekil” ifadesinin kullanımı
|Şekiller dizininde “Şekil” ifadesinin şekil numaralarından önce kullanılıp kullanılmayacağına karar ver.
|Şekiller listesinde Şekil ön eki bulunacaktır.
|10
|-
|BRDP-S1-00502
|Başlıkların gösterimi (yerleşim düzeni)
|Başlıkların gösterilmesinde S1000D’nin standart metodunun kullanılıp kullanılmayacağına karar ver. Kullanılmayacaksa Proje veya Kurum kararını tanımla.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00505
|Metin paragraflarının gösterimi
|Yazı boyutu, boşluk ve hizalaması için önerilen kuralların kullanılıp kullanılmayacağına karar ver.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00507
|Listeler için kullanılacak ön ekler
|Proje boyunca listeler için sabit bir ön ek seti kullanılıp kullanılmayacağına karar ver.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00513
|Uyarı ve Dikkatlerin gösterimi
|Uyarıların adım/paragraf numarası öncesinde gösterimi için alternatif kuralın kullanılıp kullanılmayacağına karar ver.

Not: Adım numaralarının uyarıyı takip etmesinin potansiyel tehlikelerinin farkına varılmalı ve aralarında net bir bağlantı olduğundan emin olunmalıdır.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00514
|Uyarı ve Dikkatlerde sembollerin gösterimi
|Uyarı ve dikkatlerde sembollerin kullanımına karar ver. Semboller standart ve dökümante edilmiş olmalıdır.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00517
|Değişiklik işaretlerinin gösterimi
|Değişiklik işaretlerinin gösterimine karar ver.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00527
|Kapak sayfasında görüntülenecek eleman ve nitelikler
|Kapak sayfasında görüntülenecek eleman ve niteliklere karar ver.

'''Not:'''

Bu karar noktasında alınan kararlar S1000D bölüm 3.9.5.2.16.’de yer alan karar noktaları ile uyumlu olmalıdır.
|Bir alt katman karar verecektir.
|1, 10
|-
|BRDP-S1-00528
|Kapak sayfasında kullanılacak görsel öğenin ebatları
|Eğer kapak sayfasında görsel öğe kullanılacaksa bu görselin yüksekliğine karar ver.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00533
|IETP’ler için kural ve yönlendirme kullanımı
|IETP görüntüleyicinin ekran ve arayüz tasarımı ile ilgili kural ve yönlendirmelerinin olup olmayacağına karar ver. Ayrıca IETP görüntüleyici üzerinden yazdırılacak olan içeriklerin çıktı formatının S1000D bölüm 6.3.1’dekine veya projede bu bölüme alternatif olarak hazırlanan formata uygunluğunu sağla.
|Bir alt katman karar verecektir.
|10
|-
|BRDP-S1-00537
|Fonksiyonellik matrisinin kullanımı
|Fonksiyonellik matrisinin kullanımına karar ver. Eğer kullanılacaksa fonksiyonellik matrisini doldur. (Bkz. S1000D bölüm 6.4.2.)
|Sınıf 4 ve 5 IETM’ler için kullanılacaktır.
|4, 7, 10
|-
|BRDP-S1-00549
|SNS başlıklarının ve açıklamalarının çevirisi
|Projede kullanılacak SNS’lerin başlık ve açıklamalarının proje diline çevirisinin yapılıp yapılmayacağına karar ver.
|Bir alt katman karar verecektir
|2
|-
|BRDP-S1-00550
|Projeye özgü bilgi kodlarının kullanımı
|S1000D’nin proje ihtiyacına göre tanımlanmasına müsaade ettiği bilgi kodlarının kullanımına karar ver. Projeye özgü bilgi kodları kullanılacaksa bu kodlar için kısa ve detaylı açıklamalar hazırla.
|Bir alt katman karar verecektir
|3
|-
|BRDP-S1-00551
|Bilgi kodu açıklamalarının çevirisi
|Bilgi kodu açıklamalarının proje diline çevirisinin yapılıp yapılmayacağına karar ver.
|Bir alt katman karar verecektir
|3
|}
<nowiki>*</nowiki> İlgili yönerge/yönetmeliklerin en son sürümü kullanılacaktır.

Eğitim dokümantasyonu S1000D spesifikasyonu çerçevesinde hazırlanırken aşağıdaki iş kurallarının da dikkate alınarak planlama yapılması gerekmektedir.

{| class="wikitable"
|'''ID'''
|'''Başlık'''
|'''Açıklama'''
|'''Karar'''
|'''Kategori'''
|-
|BRDP-S1-00267
|Performans analizi gerçekleştirme
|İş performansını etkileyebilecek faktörlere karar vermek için bir performans analizi mi yoksa eğitim gereksinimlerini belirlemek için eğitim ihtiyaçları analizi mi yapılacağına karar ver.
|Bir alt katman karar verecektir
|3, 5, 6a
|-
|BRDP-S1-00268
|Eğitim konularının hedeflerinin geliştirilmesi
|Eğitim konularının hedeflerinin, görev analizi elemanları ile uyumlu olarak geliştirilip geliştirilmeyeceği-ne karar ver. Eğitim konuları, görev analizi elemanları ile uyumlu olarak geliştirilmelidir. Eğitim içerikleri ile görev analizi elemanları arasındaki uyum ne kadar erken tesis edilirse, verilerin tekrar kullanılabilirliği de o kadar artar. İçerik planlaması için Bkz. S1000D bölüm 3.9.7.
|Bir alt katman karar verecektir.
|3, 5, 6a
|-
|BRDP-S1-00269
|Ders planlarının SCORM içerik paketleri olarak hazırlanması
|Ders planlarının SCORM içerik paketleri olarak hazırlanıp, hazırlanmayacağına karar ver.
|Bir alt katman karar verecektir.
|5, 6a, 7
|-
|BRDP-S1-00270
|Ömür devri ihtiyaçlarının performans analizi verileri için tanımlanması
|Müşterinin organizasyonu ve ürüne bağlı olarak değişen insan performansı sistemi için yapılan performans analizi sonucunda elde edilen analiz bilgisi ve gereksinimler için ömür devri ihtiyacını belirle.
|Bir alt katman karar verecektir.
|3, 5, 6a
|-
|BRDP-S1-00271
|Ömür devri ihtiyaçlarının eğitim ihtiyacı analizi verileri için tanımlanması
|Eğitim uygulaması için yapılan eğitim gereksinimleri analizi sonucunda elde edilen analiz bilgisi ve gereksinimler için ömür devri ihtiyacını belirle.
|Bir alt katman karar verecektir.
|3, 5, 6a
|-
|BRDP-S1-00272
|Eğitim hedefinin anlatıldığı içeriklerde <dmRef> elemanının kullanımı
|Eğitim hedefinin anlatıldığı içeriklerde, içeriği destekleyici farklı içeriklere, <dmRef> elemanını kullanarak referans verilip verilemeyeceğine karar ver.
|Bir alt katman karar verecektir.
|6a
|-
|BRDP-S1-00273
|<weightingFactor> (ağırlık faktörü) niteliğinin kullanımı
|Sınav sorularına ağırlık faktörü uygulanıp uygulanmayacağına karar ver.
|Bir alt katman karar verecektir.
|3, 5, 6a
|-
|BRDP-S1-00274
|<attempts> (tekrarlama) niteliğinin kullanımı
|Sınav sorularına birden fazla kez cevap verme şansının verilip verilmeyeceğine karar ver.
|Bir alt katman karar verecektir.
|3, 5, 6a
|-
|BRDP-S1-00552
|Eğitim kodu açıklamalarının çevirisi
|Eğitim kodu açıklamalarının proje diline çevirisinin yapılıp yapılmayacağına karar ver.
|Bir alt katman karar verecektir
|3, 5
|}

= EK-B =

== TEKNİK YAYIN ŞABLON ÖRNEĞİ ==
Bu bölümde teknik yayın şablonu örnek olarak verilmiştir. Şablon, proje çerçevesinde oluşturulacak iş kuralları kapsamında her projede ihtiyaca göre değiştirilebilir ve genişletilip daraltılabilir. Her proje başlangıcında tüm paydaşlarca kabul görecek iş kuralları dokümanı hazırlanmalı ve alınan kararlar proje kapsamındaki tüm teknik yayınlarda uygulanmalıdır.

'''<big>1. KAPAK VE GİRİŞ BÖLÜMÜ ÖRNEĞİ</big>'''

'''<big>1.1. KAPAK</big>'''

Kapak sayfası aşağıdaki bilgilerden uygulanabilir olanları kapsamalıdır:

'''1. ''' Teknik yayının güvenlik seviyesi

'''2. ''' Teknik yayın numarası

'''3. ''' Cilt numarası (Teknik yayının birden fazla ciltten oluştuğu durumlarda)

'''4. ''' Versiyon (revizyon) numarası

'''5. ''' Teknik yayının tipi (Bakım El Kitabı, Resimli Parça Kataloğu vb.)

'''6. ''' Bakım seviyesi

'''7. ''' Ürünün tanımı/ismi

'''8. ''' Model numarası/Parça Numarası

'''9. ''' Ürün/Sistem NATO Stok Numarası (NSN)

'''10. '''Alt ürünün tanımı/ismi (Teknik yayının birden fazla ciltten oluştuğu durumlarda)

'''11. '''Üretici ismi/adresi / Web Adresi

'''12. '''Sözleşme numarası

'''13. '''Kullanıcı İsmi

'''14. '''Yayın tarihi

'''15. '''Telif hakkı

'''16. '''SVİL/DVİL Numarası

'''17. '''Proje logosu / kısa adı

'''18. '''Ürünün resmi

Kapak sayfasının ön yüzüne sığmayan bilgiler olduğu durumda kapağın arka yüzüne devam edilir, aksi takdirde boş bırakılır.

Teknik yayının cilt sırtına teknik yayın numarası ve ürünün tanımı/ismi yazılır.

Ön kapağa sığmayan bilgilerin olduğu durumda aşağıdaki bilgiler için kapağın arka kısmı kullanılabilir.

'''1. ''' Telif hakkı

'''2. ''' Üretici ismi/adresi / Web Adresi

'''3. ''' Teknik Yayın ile ilgili kısıtlar, açıklamalar, hata bildirimi vb. bilgiler
[[Dosya:Şekil9 Kapak Sayfası.jpg|alt=|sol|küçükresim|527x527pik]]

[[Dosya:Şekil9b Kapak Sayfası.jpg|alt=Şekil 9 Kapak Sayfası (Örnek)|sol|küçükresim|493x493pik|Şekil 9 Kapak Sayfası (Örnek)]]

'''<big>1.2. DEĞİŞİKLİK İZLEME TABLOSU</big>'''

Teknik yayına ilişkin değişikliklerin belirtildiği tablodur. Bu tablo aşağıdaki bilgileri kapsamalıdır.

* Versiyon (revizyon) numarası
* Değişiklik tarihi
* Değişiklik yapılan bölüm / paragraf
* Eklenen veya değiştirilen sayfalar aşağıdaki şekilde kodlanmalıdır.
** Y=Yeni sayfa
** D=Değişen sayfa

'''“Y”''' ilave edilen Yeni Sayfayı belirtmektedir. Bunun anlamı, belirtilen tarih ve versiyonda o sayfanın ilave yapıldığını göstermektir.

Yeni ilave edilen sayfaların numaralandırması için farklı yöntemler mevcut olmakla birlikte, araya girecek sayfanın takip eden sayfaların numaralarını değiştirmemesi amacıyla, önceki sayfa numarasına A harfinden başlamak üzere harfler ilavesi ile yapılması uygun olacaktır. Örneğin:

Sayfa numarası 3-15 ile 3-16 arasına iki yeni sayfa ilavesi yapılacak ise, eklenen sayfalar için 3-15A ve 3-15B numaraları kullanılabilir. Böylece takip eden sayfa numarası değişmeden 3-16 olarak kalır.

'''“D”''' Değişiklik yapılan sayfayı belirtmektedir'''.''' Bunun anlamı belirtilen tarih ve versiyonda o sayfada değişiklik yapıldığını göstermektir.

Bilgilerin silinmesi neticesinde tamamen silinecek sayfalar değişiklik kapsamında değerlendirilebilir. Silinecek sayfa boş ve mevcut sayfa numarası olarak (sayfa üzerinde “Bu sayfa boş bırakılmıştır” ibaresi ile) korunur. Böylece takip eden sayfaların numaraları değiştirilmez. Örneğin:

Sayfa numarası 3-15 olan sayfa kaldırılacak ise, bu sayfa üzerindeki bilgiler silinerek ve üzerine “Bu sayfa boş bırakılmıştır” ibaresi yazılı olarak, yine 3-15 sayfa numarası ile dokümanda bırakılır. Böylece takip eden sayfa numarası değişmeden 3-16 olarak kalır.

* Değişikliğin sebebi

Değişiklik İzleme Tablosunda, teknik yayındaki değişikliklerin tamamı veya sadece yapılan son değişiklik gösterilebilir.
[[Dosya:Şekil 10 Değişiklik İzleme Tablosu (Örnek).jpg|alt=Şekil 10 Değişiklik İzleme Tablosu (Örnek)|sol|küçükresim|600x600pik|Şekil 10 Değişiklik İzleme Tablosu (Örnek)]]

'''<big>1.3. İÇINDEKİLER SAYFASI</big>'''

Teknik yayında yer alan tüm bölümlerin listelendiği tablodur. İçindekiler bölümü aşağıdaki bilgileri içermelidir:

* Bölüm/Kısım/Paragraf numarası
* Bölüm/Kısım/Paragraf adı
* Sayfa numarası

İçindekiler sayfası; kapak ve değişiklik izleme tablosunu içermemelidir.
[[Dosya:Şekil11 İçindekiler Listesi.jpg|alt=Şekil 11 İçindekiler Listesi (Örnek)|sol|küçükresim|600x600pik|Şekil 11 İçindekiler Listesi (Örnek)]]

'''<big>1.4. ŞEKILLER LİSTESİ</big>'''

Bu liste teknik yayında bulunan tüm şekilleri listeler. Aşağıdaki bilgileri içerir.

* Şekil numarası
* Şekil ismi
* Sayfa numarası
[[Dosya:Şekil12 Şekiller Listesi.jpg|alt=Şekil 12 Şekiller Listesi (Örnek)|sol|küçükresim|600x600pik|Şekil 12 Şekiller Listesi (Örnek)]]

'''<big>1.5. TABLOLAR LİSTESİ</big>'''

Bu liste teknik yayında bulunan tüm tabloları listeler. Aşağıdaki bilgileri içerir.

* Tablo numarası
* Tablo ismi
* Sayfa numarası
[[Dosya:Şekil13 Tablolar Listesi.jpg|alt=Şekil 13 Tablolar Listesi (Örnek)|sol|küçükresim|600x600pik|Şekil 13 Tablolar Listesi (Örnek)]]

'''<big>1.6. KISALTMALAR LİSTESİ</big>'''

Bu liste teknik yayında kullanılan kısaltmaların açıklamalarını alfabetik sıra ile listeler ve aşağıdaki bilgileri içerir:

* Kısaltma
* Kısaltmanın açıklaması
[[Dosya:Şekil14 Kısaltmalar Tablosu.jpg|alt=Şekil 14 Kısaltmalar Tablosu (Örnek)|sol|küçükresim|600x600pik|Şekil 14 Kısaltmalar Tablosu (Örnek)]]

'''<big>1.7. TANIMLAR LİSTESİ</big>'''

Bu liste teknik yayında kullanılan tanımların açıklamalarını alfabetik sıra ile listeler ve aşağıdaki bilgileri içerir.

* Tanım
* Tanımın açıklaması
[[Dosya:Şekil15 Tanımlar Tablosu.jpg|alt=Şekil 15 Tanımlar Tablosu (Örnek)|sol|küçükresim|600x600pik|Şekil 15 Tanımlar Tablosu (Örnek)]]

'''<big>1.8. SEMBOLLER LİSTESİ</big>'''

Bu liste teknik yayında kullanılan özel sembollerin açıklamalarını listeler. Aşağıdaki bilgileri içerir.

* Sembol
* Sembolün açıklaması
[[Dosya:Şekil16 Semboller Listesi.jpg|alt=Şekil 16 Semboller Listesi Tablosu (Örnek)|sol|küçükresim|400x400pik|Şekil 16 Semboller Listesi Tablosu (Örnek)]]

'''<big>1.9. REFERANS DOKÜMANLAR TABLOSU</big>'''

Bu tablo teknik yayınla ilişkili dokümanları listeler. Aşağıdaki bilgileri içerir.

* Doküman numarası
* Doküman açıklama
* Doküman yayın tarihi
* Versiyon (revizyon) numarası
[[Dosya:Şekil17 Referans Dokümanlar Tablosu.jpg|alt=Şekil 17 Referans Dokümanlar Tablosu (Örnek)|sol|küçükresim|550x550pik|Şekil 17 Referans Dokümanlar Tablosu (Örnek)]]

'''<big>1.10. TEKNIK YAYININ AMACI</big>'''

Bu bölümde teknik yayının kullanım amacı, kapsamı, kullanımına yönelik bilgi, teknik yayınla ilgili değişiklik istek usulleri, varsa kısıtlar ve özel bilgiler verilir.

'''<big>1.11. EMNİYET TEDBİRLERİ</big>'''

Bu bölümde ürünle ilgili genel emniyet tedbirleri açıklanır. İhtiyaç duyulmadıkça, teknik yayının diğer bölümlerinde bu emniyet tedbirleri tekrarlanmaz.

'''<big>1.12. İKAZ VE NOT STANDARTLARI</big>'''

Teknik yayında kullanılacak olan ikazlar, uygulanmadıklarında yaşanabilecek durumun kritikliğine göre iki seviye halinde kategorilendirilir ve “DİKKAT”, “UYARI” vb. şekilde isimlendirilir. Bu isimlendirme kuvvetler arasında farklılık gösterebilmektedir.

* 1. Seviye İkaz: Doğru şekilde uygulanmadığında personelin yaralanmasına ya da hayatını kaybetmesine neden olabilecek prosedürler, işlem adımları, uygulamalar vb. için kullanılır.

* 2. Seviye İkaz: Dikkatle takip edilmemesi durumunda ekipmanın zarar görmesine ya da kullanılamaz hale gelmesine neden olabilecek prosedürler, işlem adımları, uygulamalar vb. için kullanılır.

İkazlara ek olarak, özellikle vurgulanmak istenen bir bilgi olduğunda, not ifadesi kullanılır. Not içerisinde kesinlikle talimat verilmemelidir.

İkazlar ilgili paragraftan önce verilmelidir. Notlar ise ilgili paragraftan önce veya sonra gelebilir.

İkaz ve notlar işlem adımı olarak verilmez ve paragraf numarası atanmaz.

İkaz ve notlar birden fazla paragraftan oluşursa, sadece bir kere başlık yazılır.

Birden fazla ikazın peşpeşe verilmesi gereken durumlarda, yazılma sırası “1. SEVİYE İKAZ” / “2. SEVİYE İKAZ” / “NOT” şeklinde olmalıdır.

İkazlar, tehlikeden korunmak için ne yapılması ya da yapılmaması gerektiği konusunda basit ve net bir talimat ile başlamalıdır. Bu talimat, konu ile ilgili diğer bilgiler arasında kaybolup gitmemelidir. Önce talimat verilmeli, sonra gerekiyorsa ek bilgiler verilmelidir.

Yönergelerde personelin işleme devam edebilmesi için sağlanması gereken bir koşul varsa, bu koşul 1. veya 2. seviye ikaz olarak işlem adımından önce verilmelidir.

Not ifadeleri, özellikle vurgulanmak istenen bir bilgi olduğunda kullanılmalı, not içerisinde kesinlikle talimat verilmemelidir.

1. seviye ikaz, 2. seviye ikaz ve notların yazımı için teknik yayın içerisinde kolaylıkla fark edilebilen başlık, font ve biçim formatları belirlenmeli, iş kuralları dokümanına yansıtılmalı ve teknik yayının tamamında tutarlı olarak bu formatlar kullanılmalıdır.

'''<big>1.13. İLGİLİ DOKÜMANLAR</big>'''

İlgili dokümanlar belirtilmelidir. Aşağıdaki bilgileri içerir.

* Doküman numarası
* Doküman adı
* Doküman yayın tarihi
* Yayınlayan
[[Dosya:Şekil18 İlgili Dokümanlar Tablosu.jpg|alt=Şekil 18 İlgili Dokümanlar Tablosu (Örnek)|sol|küçükresim|500x500pik|Şekil 18 İlgili Dokümanlar Tablosu (Örnek)]]

'''<big>1.14. GENEL YAPI ÖRNEĞİ</big>'''

'''<big>1.14.1. BAŞLIKLAR</big>'''

* '''Bölüm'''

Sayfa başlangıcının ortasına, büyük ve kalın harflerle önce varsa bölüm numarası tek başına, alt satırına bölüm adı yazılır. Bölümler dokümanın sağ tarafındaki sayfadan başlamalı. Sol taraftaki sayfa gerekirse boş bırakılmalıdır.

* '''Kısım'''

Bölüm numarası ve adından sonra bir satır boşluk bırakılarak, kısım numarası ve adı büyük ve kalın harflerle tek satıra yazılır.

* '''Paragraf'''

Teknik yayın metni, paragraflar ve alt paragraflara bölünerek yazılır. Paragraf ve alt paragraf başlıkları tek başlarına koyu olarak yazılır. Paragraf, büyük harflerle, alt paragraflar ise sadece baş harfleri büyük olacak şekilde yazılır.
[[Dosya:Şekil19 Başlıklar.jpg|alt=Şekil 19 Başlıklar (Örnek)|sol|küçükresim|485x485pik|Şekil 19 Başlıklar (Örnek)]]

'''<big>1.14.2. TABLOLAR</big>'''

Referans veriler (resim, çizim, diyagramlar hariç) çizelgeler halinde sunulur. Tablolar, tablo ismi ve numarası, tablo başlığı, satır ve sütunlardan oluşur.

Tablonun ismi ve numarası tablonun üstünde veya altında, tabloyla beraber sayfanın ortasında baş harfleri büyük ve koyu olacak şekilde yazılmalıdır. Tablo numaralandırılması, bölüm bilgisini de içermelidir. Tablo başlıkları tablonun içinde kalacak şekilde hücre ortasında koyu olarak yazılır. Diğer sayfaya taşan tablolarda tablo ismi, numarası ve tablo başlıkları tekrar edilmelidir.
[[Dosya:Şekil20 Tablo.jpg|alt=|sol|küçükresim|500x500pik|Şekil 20 Tablo (Örnek)]]

'''<big>1.14.3. ŞEKİLLER</big>'''

Şekil (resimler, çizimler, diyagramlar) ismi ve numarası, şeklin altında ve ortasında baş harfleri büyük ve koyu olacak şekilde yazılmalıdır. Şekil numaralandırılması, bölüm bilgisini de içermelidir. Standart sayfaya sığmayan şekiller katlanabilir sayfa halinde hazırlanabilir.
[[Dosya:Şekil21 Şekil .jpg|alt=Şekil 21 Şekil (Örnek)|sol|küçükresim|400x400pik|Şekil 21 Şekil (Örnek)]]

'''<big>1.14.4. TEKNİK YAYIN CİLT/KLASÖR İŞLEMLERİ</big>'''

Teknik yayınların cilt/klasör kapaklarına Paragraf 4.1.1’deki bilgilerden gerekli görülenler konulur. Aşağıdaki şekilde gösterilen veriler, cilt/klasör sırt kısmına cilt/klasör kalınlığına göre yazılır
[[Dosya:Şekil22 Teknik Yayın Cilt.jpg|alt=Şekil 22 Teknik Yayın Cilt/Klasör (Örnek)|sol|küçükresim|500x500pik|Şekil 22 Teknik Yayın Cilt/Klasör (Örnek)]]

'''<big>1.14.5. REFERANSLAR</big>'''

Teknik yayın içinde verilecek referanslar, konunun anlatıldığı cümlenin sonuna parantez içinde ilgili paragraf/tablo/şekil numarası verilerek gösterilir Örneğin Şekiller uygulaması (bak.Prg.4.3.3.) / (bak. Şekil 2-55) vb.

= EK-C =

== TEKNİK YAYIN YAZIM ÖRNEKLERİ ==

Bu bölümde teknik yayın hazırlarken kullanılacak kelime, cümle, cümle yapısı gibi konularda öneri ve yol gösterici olabilecek örnekler verilmiştir.

'''1 Kelimeler'''

'''1.1 – Teknik isimler kullan (gerekirse kısaltarak kullan).'''

Jargon ve mesleki argo kullanmaktan kaçın. Seçtiğin kelimelerin genel kullanılan kelimeler olduğundan emin ol.

''Örneğin;''

''YANLIŞ: Yüzey timsah derisi gibiyse boyama işlemini tekrarla.''

''DOĞRU: Yüzey pürüzsüz değilse boyama işlemini tekrarla.''

'''1.2 – Aynı şey için birden fazla teknik isim kullanma.'''

Bir birim ya da parçadan bahsederken yalnızca bir isim kullan. Örneğin, metnin ilk kısmında "anten" olarak tanımladığın parçadan daha sonra "sensör" diye bahsetme.

'''1.3 – Seçme şansın varsa, en kısa ve en basit ifadeyi kullan.'''

Bir şeyi isimlendirmek ya da tarif etmek için kullanılabilecek birden fazla ifade olması durumunda, en kısa ve en basit ifadeyi kullan.

'''1.4 – Bir şeyi tarif etmek için kullanacağın ifadeyi bir kez seçtiysen, hep aynı ifadeyi kullanmaya devam et.'''

Prosedür adımlarında geçen bir işlem birden fazla yerde tekrarlanıyorsa, her seferinde bu işlemi aynı kelimelerle ifade et. Aynı kelimeler ve cümle yapılarının tekrar tekrar kullanılması, okuyan kişinin metni anlamasını kolaylaştırır.

''Örneğin;''

''1. Filtreyi çıkartmak için plakadaki vidaları sök.''

''2. Filtreyi sabitleyen vidaları sök ve filtreyi plakadan ayır.''

Bu iki cümle, aynı işlemi farklı ifadeler ile anlatır. Farklı yönergelerde aynı işlem için bu iki cümlenin de kullanılması, okuyucunun kafasını karıştıracaktır. İfade olarak hangi cümle daha uygunsa seç ve bu işlemi anlatırken hep aynı cümleyi kullan.

Betimleyici anlatım kısımlarında bu kural geçerli değildir. Aksine, farklı kelime ve cümle yapılarının kullanılması, metni daha okunabilir ve ilgi çekici kılmak için gereklidir.

'''1.5 – Talimatların olabildiğince net olsun.'''

Yazdığın yönergeler, bir işlemin yapılmamasının sonuçlarını değil, o işlemin nasıl yapılacağını anlatmalıdır.

''Örneğin;''

''YANLIŞ: Farklı sıcaklıklar, boyanın kuruma süresini değiştirir.''

''DOĞRU: Boyanın kuruma süresini kısaltmak için sıcaklığı arttır.''

'''2 Cümleler'''

Teknik yayın hazırlarken temel hedef, metinleri olabildiğince basit, okunması ve anlaşılması kolay tutmaktır. Bu, yazılan cümlelerin kısa tutulmasını ve metnin karmaşık hale gelmesinden kaçınılmasını gerektirir.

'''2.1 – Bir cümlede yalnızca bir konudan bahset.'''

Bazı metin yazarları, bildikleri her şeyi bir anda anlatabilmek adına uzun cümleler kurarlar. Ancak, aktarılmak istenen bilgi tüm detaylarıyla 1-2 cümlede anlatılmaya çalışıldığında, okuyucunun kafası karışacaktır. Bu yüzden, bilgi yavaş yavaş sunulmalı ve her cümle yalnız bir konu ile ilgili olmalıdır. Böylece cümlelerin uzunluğu da kabul edilebilir seviyeye inecektir.

'''2.2 – Cümleleri kısaltmak için özne ya da yüklemi cümleden çıkartma.'''

Özne ya da yüklemin bulunmadığı cümleler, anlam açısından muğlaklık yaratacaktır. Bu nedenle, cümleleri kısaltmak için mutlak öğelerden birini çıkartma değil, cümleyi birden fazla parçaya bölme yöntemi kullanılmalıdır.

'''2.3 – Karmaşık metinler için madde madde anlatım yöntemini kullan.'''

Birden fazla işlem, olay vb. anlatan uzun bir cümle yerine maddelere bölünmüş bir cümle yapısı kullanmak, metnin okunmasını ve maddeler arasındaki ilişkinin görülmesini kolaylaştırır.

Madde madde anlatım yönteminde:

* Cümlenin giriş kısmının sonuna (:) konulur.
* Maddelerin ilk harfleri büyük olur.
* Her bir maddede bir cümle varsa (madde içerisinde cümle tamamlanıyorsa) sonuna (.) konur.
* Her bir madde ayrı bir cümle değilse sonlarına (.) konulmaz, yalnızca son maddenin sonuna (.) konur.

''Örneğin;''

''YANLIŞ: Kontrol paneli üzerinde bir ON/OFF anahtarı, bir START düğmesi ve bir STOP/TEST düğmesi bulunur.''

''DOĞRU: Kontrol paneli üzerinde:''

* ''Bir ON/OFF anahtarı''
* ''Bir START düğmesi''
* ''Bir STOP/TEST düğmesi bulunur.''

'''2.4 – Art arda gelen ve konu ile igili olan cümleleri bağlamak için bağlaçları kullan.'''

Art arda gelen ve konu ile ilintili olan cümleleri bağlamak için ayrıca, ama, fakat, aynı zamanda, bu nedenle vb. gibi bağlaçların kullanılması, cümleler arasındaki ilişkinin aktarılmasını kolaylaştırır.

''Örneğin;''

''Bu güvenlik önlemleri, yakıt tankında çalışabilmek için gereken minimum gereksinimlerdir. Ancak; işlem sırasında bulunulan bölge, ek önlemler alınmasını gerektirebilir.''

'''3 Yönergeler / Prosedürler'''

'''3.1 – Yönerge cümlelerini olabildiğince kısa tut (maksimum 20 kelime)'''

Yapılacak işlemlerde izlenecek talimatların açık ve net olması, kolayca anlaşılması gerekir. Bunu sağlamak için cümlelerin kısa tutulması önemli bir adımdır. Talimat içeren cümleler için maksimum uzunluk 20 kelime olarak belirlenmiştir.

''Örneğin;''

''YANLIŞ: Birim ön panel konnektörleri söküldükten sonra birimi platforma sabitleyen 8 adet vida, büyük boy yıldız tornavida kullanılarak sökülür.''

''DOĞRU: 1. Birim ön panel konnektörlerini sök.''

''2. Birimi platforma sabitleyen 8 adet vidayı, büyük boy yıldız tornavida kullanarak sök.''

'''3.2 – Bir cümlede yalnızca bir talimat ver.'''

Yönergelerin her bir adımda bir işlem anlatılacak şekilde yazılması, okuyucu için takip etmesi ve uygulaması kolay prosedürler oluşturur.

''Örneğin;''

''YANLIŞ: Birim ön panel konnektörleri söküldükten sonra birimi platforma sabitleyen 8 adet vida, büyük boy yıldız tornavida kullanılarak sökülür.''

''DOĞRU: 1. Birim ön panel konnektörlerini sök.''

''2. Birimi platforma sabitleyen 8 adet vidayı, büyük boy yıldız tornavida kullanarak sök.''

'''3.3 – Bir cümlede birden fazla talimatı yalnızca birden fazla işlemin aynı anda yapıldığı durumlarda ver.'''

Birden fazla işlemin aynı anda yapılması gereken durumlar olabilir. Bu durumlarda, talimatların aynı adımda verilmesi gerekir.

''Örneğin;''

''DOĞRU: Anahtarı TEST konumuna getir ve lambanın yandığından emin ol.''

'''3.4 – Talimatlarda, etken bir fiili 2. tekil kişinin emir kipinde kullan.'''

Talimat verilen cümlelerde, yapılacak işlemin emir kipi ile ifade edilmesi gerekir. Prosedürdeki işlemler, uygulayan kişinin tercihine bırakılmayan, yapılması şart olan adımlardır. Dolayısıyla yazım dilinin de bu zorunluluk durumunu ifade edebilmesi gerekir.

''Örneğin;''

''YANLIŞ: Montaj yüzeyi lifsiz bez ile kurulanır.''

''YANLIŞ: Montaj yüzeyi lifsiz bez ile kurulanmalıdır.''

''YANLIŞ: Montaj yüzeyini lifsiz bez ile kurulayın.''

''YANLIŞ: Montaj yüzeyini lifsiz bez ile kurulayınız.''

''DOĞRU: Montaj yüzeyini lifsiz bez ile kurula.''

'''3.5 – Talimatın başında betimleyici bir cümle geçiyorsa, bu cümleyi talimatın geri kalanından virgül ile ayır.'''

Bazı yönerge adımları komutla başlamayabilir. Zaman zaman, bir işlemden önce bazı şartların sağlanması gerekiyor olabilir. Bu durumda, beklenen bu şartı ifade etmek için betimleyici bir cümle ile yönergeye başlamak gerekebilir. Bu cümlenin, talimatın geri kalanından virgül ile ayrılarak vurgulanması gerekir.

''Örneğin;''

''DOĞRU: Işık yandığında, anahtarı NORMAL konumuna getir.''

''DOĞRU: Yüzey kuruyunca, bazı sür.''

''DOĞRU: Input ledi yeşil olarak yanıp sönünce, ana şalteri ON konumuna al.''

'''4 Betimleyici / Tanımlayıcı Anlatım'''

'''4.1 – Anlatım cümlelerini mümkün olduğunca kısa tut (maksimum 25 kelime).'''

Prosedür anlatımlarında 20 kelimeden uzun cümleler kullanılması tavsiye edilmezken betimleyici anlatımda 25 kelimeye kadar izin verilmektedir. Yine de çok uzun ve karmaşık yapılı cümleler kullanılmamalıdır.

'''4.2 – Metni dikkat çekici kılmak için farklı cümle uzunlukları ve yapıları kullanmaya çalış.'''

Peş peşe kısa cümlelerden oluşan bir metin sıkıcı olacak, sürekli uzun cümlelerin kullanılması ise takibi zor bir metin ortaya çıkaracaktır. Bu nedenle, betimleyici anlatım kısımlarında farklı cümle uzunlukları ve farklı cümle yapıları kullanılarak metin kolay okunur ve dikkat çekici hale getirilmelidir.

'''4.3 – Metnin mantığını gösterebilmek için paragrafları kullan.'''

Prosedür ve yönergelerde metin sıralı maddeler halinde verilir, böylece metnin akışındaki mantık okuyucu tarafından kolayca takip edilebilir. Anlatım kısımlarında ise bu görev, paragraflar tarafından yerine getirilir. Her bir paragraf, bir konu ile ilgili bilgiyi içeren ayrı bir birimdir ve diğer birimlerden (dolayısıyla diğer konulardan) aradaki beyaz satır boşluğu ile ayrılır.

'''4.4 – Her bir paragrafta yalnızca bir konudan bahset.'''

Bir paragrafta yalnızca bir konu anlatılmalıdır. Bir konu ile ilgili başlayan paragrafın devamında başka bir konuya geçilmemelidir. Ayrıca, paragrafta anlatılan konu uzunsa ve bir paragraf yeterli gelmeyecekse, konu bölünmeli ve her biri kendi paragrafında anlatılmalıdır.

'''4.5 – Paragrafa her zaman ana fikir cümlesi ile başla.'''

Bir paragrafın en önemli kısmı, ilk cümlesidir. Bu ilk cümle, okuyucuya paragrafın ne hakkında olduğunu söylemelidir. Okuyucu, sadece ana fikir cümlelerini okuyarak metnin genel hatlarıyla ne anlattığına hakim olabilmelidir. Okuyucu belli bir bilgiyi arıyor ise, ana fikir cümlelerini tarayarak istediği bilginin hangi paragrafta anlatıldığını bulabilmelidir. Ana fikir cümlesinden sonra gelen cümleler konuya ilişkin detayları ve ek bilgileri vermelidir. Her bir cümle kendinden önce gelenlerle mantıksal olarak bağlantılı olmalı ve kullanıcıya yeni bilgiler sunmalıdır.

'''4.6 – Bir paragrafın maksimum uzunluğu 6 cümledir. Tek cümlelik paragraf kullanacaksan, bunu 10 paragrafta 1 kereden daha sık yapma.'''

Uzun paragraflar, karmaşık bir konuyu anlatmanıza imkân sunar. Ancak kendi içinde anlaşılır ve tek konu hakkında olmalıdır. Bir konu ile ilgili başlayıp başka konulara geçen bir paragraf oluşturulmaması gerekir.

Kısa paragraflar bilgiyi basitleştirip bu bilgiyi okuyucuya hızla sunmanızı sağlar. Ancak peş peşe kısa paragraflar oluşturmak, konular arasındaki ilişkiyi tam verememenize neden olabilir. Bilgiler birbirinden kopuk olabilir.

İdeal olan, okuyucunun ilgisini çekebilmek için metin içerisinde farklı uzunluklarda paragraflar kullanılmasıdır.

'''5 Dikkat, Uyarı ve Notlar'''

'''5.1 – Dikkat ve uyarılara basit ve net bir talimatla başla.'''

Dikkat ve uyarılar, tehlikeden korunmak için ne yapılması ya da yapılmaması gerektiği konusunda basit ve net bir talimat ile başlamalıdır. Bu talimat, konu ile ilgili diğer bilgiler arasında kaybolup gitmemelidir. Önce talimat verilmeli, sonra gerekiyorsa ek bilgiler verilmelidir.

''Örneğin;''

''YANLIŞ:''

''DİKKAT''

''BU MOTORDA KULLANILAN SENTETİK YAĞDA, UZUN SÜRE CİLT İLE TEMAS ETMESİ DURUMUNDA EMİLİM İLE ZEHİRLENME DURUMU YARATABİLECEK MADDELER BULUNUR.''

''DOĞRU:''

''DİKKAT''

''MOTOR YAĞINI CİLDİNE TEMAS ETTİRME.''

''YAĞ ZEHİRLİDİR. CİLTTEN EMİLİP VÜCUDA KARIŞABİLİR.''

'''5.2 – Dikkat ve uyarı talimatlarında spesifik bilgi verdikten sonra, gerekiyorsa, muhtemel risk hakkında fikir vermek için dikkat ve uyarıya kısa bir açıklama ekle.'''

Verilen talimatın daha etkili olabilmesi için, talimata uyulmaması durumunda yaşanacak olumsuzluğun açıklanması gerekebilir. Bu durumda, talimattan sonra kısa bir açıklama eklenebilir.

Örneğin;

''UYARI''

''ANA ŞALTER İNDİRİLMEDEN ÖNCE YEŞİL LEDİN YANIYOR OLDUĞUNDAN EMİN OL.''

''YEŞİL LED YANMADAN ŞALTER İNDİRİLİRSE VİNÇ AKSAMI ZARAR GÖREBİLİR.''

'''5.3 – İşleme devam edilebilmesi için sağlanması gereken bir koşul varsa, bu koşulu dikkat ya da uyarı olarak önden ver.'''

Örneğin;

''UYARI''

''ANA ŞALTER İNDİRİLMEDEN ÖNCE YEŞİL LEDİN YANIYOR OLDUĞUNDAN EMİN OL.''

''YEŞİL LED YANMADAN ŞALTER İNDİRİLİRSE VİNÇ AKSAMI ZARAR GÖREBİLİR.''

'''5.4 – Notları talimat değil, bilgi vermek için yaz.'''

Not ifadeleri, özellikle vurgulanmak istenen bir bilgi olduğunda kullanılır. Not içerisinde kesinlikle talimat verilmemelidir.

'''6 Noktalama İşaretleri ve Kelime Sayıları'''

'''6.1 – Maddeli anlatımlar oluşturmak için (:) ve madde imi kullan (bknz. 2.3).'''

'''6.2 – Parantezleri:'''

* Görsele ya da metne çapraz referans yaparken
* Görselde ya da metinde bir şeyi tanımlayan harfleri ya da sayıları alıntılarken
* Virgülle ayırmanın yeterli gelmediği metinleri işaretlerken
* Asıl cümlenin bir parçası olmayan ama belirtilmesi gerekecek kadar önemli olan ifadeleri yazarken kullan.

'''6.3 – Cümle uzunluklarını tespit etmek için kelimeleri sayarken:'''

* Parantez içerisindeki metin ayrı bir cümle olarak sayılır.
* (:) ya da (-) nokta gibi düşünülür.
* Sayılar birer kelime olarak sayılır.
* Alfa numerik bir ifade bir kelime olarak sayılır.
* Kısaltmalar birer kelime olarak sayılır.
* Başlıklar, plakalar ve alıntılanan metinler birer kelime olarak sayılır. 

'''7 Dil Birliği ve Kelime Kullanımı'''

'''7.1 – Kabul görmüş Türkçe karşılığı olan tüm isimler için daima Türkçe kullan.'''

'''7.2 – Tüm teknik yayınlarda ortak olarak kullanılmasına karar verilen kelimeler konusunda özenli davran.'''

* “Cursor” yerine “İmleç”
* “Mouse” yerine “İmleç sürücü”
* “Spacebar” yerine “Boşluk tuşu”
* “Öge” yerine “bileşen”, “alt sistem”
* “Tüketim malzemesi” yerine “sarf malzeme”
* “Zorunlu sistem ögeleri” yerine “standart sistem birimleri/alt birimleri”
* “Yardımcı ögeler” yerine “destek ekipmanları”
* “Test kaynakları” yerine “test gereç ve yardımcıları”

'''DOKÜMANIN HAZIRLANMASINDA GÖREV ALAN KURUM/KURULUŞLAR'''

SAVUNMA SANAYİİ BAŞKANLIĞI

MİLLİ SAVUNMA BAKANLIĞI

* KARA KUVVETLERİ KOMUTANLIĞI

ASELSAN A.Ş.

FNSS SAVUNMA SİSTEMLERİ A.Ş.

HAVELSAN A.Ş.

ROKETSAN A.Ş.

SİMSOFT BİLGİSAYAR TEKNOLOJİLERİ LTD. ŞTİ./BİLTEN LTD.ŞTİ.

TÜRK HAVACILIK VE UZAY SANAYİİ A.Ş.

VİYA LOJİSTİK MÜHENDİSLİK VE BİLİŞİM TEKNOLOJİLERİ LTD.ŞTİ

Dosya:TSSODYP-12 Teknik Yayın Hazırlama Rehberi rev.pdf

2023-01-13T07:06:11Z

Oozdemir:

Lojistik Destek Analizleri ve Kayıtları Rehberi

2022-08-25T13:02:41Z

Oozdemir: /* EK-G BAKIM GÖREV ANALİZİ (BGA) */

'''[https://tssodypwiki.ssb.gov.tr/images/9/95/TSSODYP_06_180822_web.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şkanlığı çatısı altında, ilgili tüm paydaşların katılımıyla faaliyet göstermek üzere Türk Savunma Sanayii Ömür Devri Yönetimi Platformu (TSSÖDYP) kurulmuştur.

TSSÖDYP; savunma ve güvenlik sistemlerine ilişkin ihtiyacın belirlenmesi, sistemlerin tedariki, kullanımı, desteklenmesi ve envanterden çıkarması safhalarını bir bütün halinde ele alan Sistem Ömür Devri Yönetimi ilke ve uygulamalarının ülkemizde yaygınlaştırılmasını ve savunma programlarının/ projelerinin yürütülmesinde savunma ve güvenlik ekosistemini oluşturan tüm paydaşlarca anlayış birliğine ulaşılmasını amaçlamaktadır.

Savunma sistemlerinin ömür devri yönetiminde millî bünyemize uygun, ülkemize özgü çözümler üretmek ve bunları dokümante etmek gibi önemli bir misyonu olan TSSÖDYP; Başkanlığımız, Milli Savunma Bakanlığı ve ilgili birimleri, Genelkurmay Başkanlığı, K.K.K.lığı, Dz.K.K.lığı, Hv.K.K.lığı, J.Gn.K.lığı, S.G.K.lığı, EGM, TÜBİTAK, SASAD ve savunma sanayii firmaları temsilcilerinin katılımı ile çalışmalarına devam etmektedir.

Sistem ömür devri yönetimi yaklaşımı ile; savunma ve güvenlik sistemlerine ilişkin ihtiyacın belirlenmesi aşamasından envanterden çıkarma safhasının sonuna kadar görev alan tüm kamu kurum ve kuruluşları ile özel sektör firmalarının sistemlerin istenilen performans seviyesinde mümkün olan en az maliyetle tedariki, kullanımı ve lojistik desteğinin sağlanabilmesi için görev, yetki ve sorumlulukları çerçevesinde ömür devrinin tamamında birlikte çalışmaları öngörülmektedir.

Bu itibarla, savunma ve güvenlik sistemlerine ilişkin ihtiyacın belirlenmesinin, tedarikinin, kullanımının, lojistik desteğinin ve envanterden çıkarılmasının en baştan uzun soluklu bir program olarak kurgulanmasının ve ilgili birimler aracılığı ile sistem ömür devri yönetimi faaliyetlerinin yürütülmesinin faydalı olacağı değerlendirilmektedir.

TSSÖDYP tarafından son iki buçuk yıl içinde gerçekleştirilen çalışmalar ile savunma ve güvenlik sistemlerinin ömür devri yönetimine ilişkin planlama ve uygulamaya esas olacak yaklaşımları ortaya koyan 13 adet rehber, iki adet bilgi kitapçığı ve bir adet terminoloji dokümanı hazırlanmıştır. Uygulamalardan alınacak geri bildirimler ile söz konusu dokümanların güncellenmesi, geliştirilmesi ve önümüzdeki dönemde uygulamaya esas düzenlemelerin alt yapısını oluşturması hedeflenmektedir.

TSSÖDYP çalışmalarına katkı veren ve dokümanların hazırlanmasında görev alan tüm paydaşlarımıza teşekkürlerimi sunuyorum.

Prof.Dr. İsmail DEMİR

T.C. Cumhurbaşkanlığı

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.

Bu nedenle, tedarik edilen sistemlerin kullanım döneminde hedeflenen muharebe ve/veya operasyon performansının sürdürülebilirliğinin ve maliyet etkinliğinin sağlanması amacıyla sistemlerin ömür devrinde rol ve sorumluluğu bulunan tüm paydaşların katılımı ile Sistem Ömür Devri Yönetimi yaklaşımı geliştirilmiştir.

Sistem Ömür Devri Yönetiminin temel amacı; mevcut durumdaki değişimlere uyum sağlamaktan ziyade gelecekte ortaya çıkabilecek değişimleri öngörmek, belirlenen hedefler doğrultusunda gerekli önlemleri alarak değişimleri yönlendirmek ve kontrol altında tutmaktır. Harekât ihtiyaçlarının zamanında ve verimli şekilde karşılanması ve sahip olunan kaynakların maliyet etkin kullanımı esastır. Başka bir deyişle, sistem ömür devri yönetimi geleceği bugünden tasarlamak ve planlamaktır.

Bu doküman; Savunma Sanayii Başkanlığı (SSB), Milli Savunma Bakanlığının ilgili birimleri, Türk Silahlı Kuvvetleri (TSK), diğer ihtiyaç makamları ve savunma sanayi firmalarında sistem ömür devri yönetiminin bir kültür olarak yaygınlaştırılmasına ve uygulanmasına yönelik rehber oluşturmak amacıyla savunma sistemlerinin ömür devrinde rol ve sorumluluğu bulunan ilgili paydaşların katılımıyla hazırlanmıştır.

Lojistik Destek Analizi (LDA); desteklenebilirlik açısından ürün tasarımını etkilemeyi amaçlayan tasarımın erken aşamalarında başlayıp ömür devri boyunca devam eden güvenilirliği, kullanıma hazır olmayı, idame edilebilirliği, maliyeti ve zaman etkinliğini ön plana çıkaran analizlerden oluşan bir süreçtir.

LDA, sistemin ve bileşenlerinin belirlenmiş kullanıma hazır olma ve desteklenebilirlik /sürdürülebilirlik ihtiyaçlarına ulaşılabilmesi amacıyla ürün tasarımı ile destek sistemini/organizasyonunu entegre eden sistematik ve yinelemeli analizler bütünüdür. LDA sonuçları elektronik veritabanında dokümante edilir. Lojistikle ilgili dokümante edilen bilgiler Entegre Lojistik Destek (ELD) fiziksel kaynaklarının (örn. iş gücü ve personel, yedek parça, eğitim, destek ekipmanları, eğitim ve eğitim desteği teknik yayınlar vb) belirlenmesini, optimize edilmesini ve izlenebilirliğini sağlar.

= 1. GENEL =

== 1.1. GİRİŞ ==
Bu doküman, Türk Savunma Sanayii Ömür Devri Yönetim Platformu (TSSÖDYP) tarafından Entegre Lojistik Destek (ELD) faaliyetlerinin merkezinde yer alan Lojistik Destek Analizleri’nin (LDA) gerçekleştirilmesi ve bu analizler sonrasında oluşturulacak LDA Kayıtları konusunda rehberlik etmek üzere hazırlanmıştır.

== 1.2. AMAÇ ==
Bu rehberin amacı ülkemizde yürütülen program/projelerde savunma ve güvenlik sistemlerinin ömür devri boyunca gerçekleştirilebilecek LDA faaliyetlerine yönelik uygulanması önerilen süreçleri, genel gereksinimleri ve bilgi/veri değişim yöntemlerini tanımlamaktır. Rehber aynı zamanda ihtiyaç makamı, kullanıcı, idame makamı, tedarik makamı, yüklenici, ve diğer paydaşlar arasında LDA faaliyetlerinin gerçekleştirilmesine yönelik arayüzleri ortaya koymayı ve LDA ihtiyaçlarının sözleşmelerde en doğru şekilde tanımlanabileceği, LDA çıktılarının neler olabileceği ve paydaşlar tarafından nasıl kullanılabileceğine dair yol gösterici olmayı hedeflemektedir.

Desteklenebilir ürünler ve en uygun destek çözümlerinin maliyet etkin şekilde geliştirilmesinde önemli bir rolü olan LDA faaliyetlerinin ürün ömür devri safhalarına uygun olacak şekilde yürütülmesi ve proje türü ve büyüklüğüne göre uyarlanması gerekmektedir. Bu çerçevede, kaynakların etkin şekilde kullanılması ve yürütülen faaliyetlerden azami seviyede verim elde edilmesi rehberin birincil amaçları arasında yer almaktadır.

Bu doküman, savunma ve güvenlik sektöründe görev alan tüm paydaşların Lojistik Destek Analizleri ve Kayıtları faaliyetlerinde rehberlik etmek üzere hazırlanmıştır.

== 1.3. KAPSAM ==
Bu rehber:

* Savunma ve güvenlik projelerinde/programlarında yürütülecek lojistik destek analizleri ve yöntemleri hakkında bilgiler,
* LDA süreçleri ve gereksinimleri,
* Analiz sonuçlarının nasıl değerlendirileceği ve maliyet-etkin bir çözüme nasıl ulaşılabileceğine dair kılavuz bilgiler,
* LDA ve desteklenebilirlik mühendisliği disiplinleri (Örn. güvenilirlik, idame edilebilirlik, test edilebilirlik, sürdürülebilirlik, kullanıma hazır olma) arasındaki ara yüzler,
* LDA ve diğer ELD elemanları (ikmal destek, teknik veri, eğitim ve eğitim desteği vb.) arasındaki ara yüzler,
* LDA sürecinin nasıl uyarlanacağına dair genel ilkeler,

hakkında bilgiler içermektedir.

== 1.4. REHBERİN KULLANIMI ==
Bu doküman savunma ve güvenlik projelerinde/programlarında kullanılabilecek LDA sürecinin ve metodolojisinin ana hatlarıyla tanımlanması amacıyla 5 bölümden oluşmaktadır:

* İlk bölüm; giriş, amaç, kapsam, referanslar gibi genel bilgileri içermektedir; ayrıca terim ve kısaltmalar da bu bölümün içindedir.
* İkinci bölümde, lojistik destek analizleri ile ilgili genel bir bilgilendirme yapılmaktadır.
* Üçüncü bölümde; sistem tasarımının ayrılmaz bir parçası olan desteklenebilirlik kavramı ve desteklenebilirlik ilişkili tasarım faktörlerinin hangi aşamalarda değerlendirilmesi gerektiği hususlarına yönelik açıklayıcı bilgiler yer almaktadır.
* Dördüncü bölümde, herhangi bir projenin başlangıç aşamasında ihtiyaç makamı ve yüklenicinin LDA gereksinimlerinin belirlenmesine ilişkin nasıl anlaşmaya varacaklarına yönelik izlenecek yol yer almaktadır,
* Beşinci bölümde, yüklenici ve müşteri uygun desteklenebilirlik seviyesine erişmek için gerçekleştirilmesi gereken faaliyetlerin tanımlandığı LDA süreci açıklanmaktadır,
* Altıncı bölümde, tasarıma etki/tasarım etkileşimi
* Yedincibölümde, kullanım ve destek safhalarında gerçekleştirilen LDA ve bu analizler sonucunda reaktif/proaktif aksiyonların alınarak ürün performansının beklenen düzeyde seyrinin sağlanmasına ilişkin süreç yer almaktadır,
* Sekizinci bölümde, konfigürasyonlarının doğru belirlenmesi, değişikliklerin kontrol edilmesi ve değişikliklerin uygulanma durumunun kayıt altına alınmasını sağlayan konfigürasyon yönetimi disiplininde izlenebilirliğin LDA çerçevesinde yürütülmesi ilişkisi yer almaktadır,
* Dokuzuncu bölümde, LDA’nın lojistik desteğin yönetilmesi için düzenli yürütülerek kayıt altına alınması, değerlendirilmesi faaliyetlerinin esasları ve standartları açıklanmaktadır. Programlara/projelere özgü olarak yine ihtiyaç sahipleri ve yükleniciler bu rehberde referans verilen veya diğer ulusal/uluslararası standart/spesifikasyonların ilave olarak kullanılması konusunda mutabakat sağlayabilirler. Projenin/ürünün karmaşıklık seviyesi ilave olarak kullanılabilecek standart/spesifikasyonları belirlemede de etken olacaktır,
* Onuncu bölümde, fiziksel destek kaynak gereksinimlerinin belirlenmesi ve destek ürünlerinin oluşturulması kapsmaında ELD elemanlarına ilişkin çalışmaların yürütlmesine yönelik bilgiler verilmektedir,
* Onbirinci bölümde, LDA ve kayıtlarına ilişkin faaliyetlerin uyarlanmasına yönelik olarak tanımlanan bütün faaliyetlerin/analizlerin her türlü projede ve her safhada gerçekleştirmek yerine etkin uygulamaların yapılmasını sağlamak amacıyla kullanıcıların projelere özgü görev/faaliyetleri seçebilmesi için yol gösterecek içerik yer almaktadır,
* Dokümanın son bölümünde ise ilgili ekler yer almaktadır.

== 1.5. REHBERİN GÜNCELLENMESİ ==
Rehberin yüklenici, ihtiyaç makamı ve diğer paydaşlar tarafından referans alınarak kullanılması kapsamında güncellenme ihtiyacının olması durumunda aşağıda sunulan izleme tablosu yardımıyla değişikliklerin takibi sağlanacaktır.

'''Tablo 1 Değişiklik İzleme Tablosu'''
{| class="wikitable"
|'''Revizyon No'''
|'''Revizyon Tarihi'''
|'''Değişiklik Yapılan Başlık No'''
|'''Yapılan Değişiklik'''
|-
|01
|Ağustos 2021
|
|İlk Yayın
|-
|
|
|
|
|-
|
|
|
|
|}

== 1.6. REFERANSLAR ==
{| class="wikitable"
|1.
|MIL-HDBK-502A Product Support Analysis, Mart 2013
|-
|2.
|ASD/AIA S3000L International Procedure Specification for Logistics Support Analysis (LSA), Temmuz 2014
|-
|3.
|ASD S4000P International Specification for Developing and Continuously Improving Preventive Maintenance, Ağustos 2018
|-
|4.
|MIL-STD-1388-2B DoD Requirements for a Logistic Support Analysis Record, Mart 1991
|-
|5.
|SAE ARP5580 Recommended Failure Modes and Effects Analysis (FMEA) Practices for Non-Automobile Applications
|-
|6.
|TSSÖDYP Doküman Seti
|}
{| class="wikitable"
|+
! colspan="2" |'''TSSÖDYP DOKÜMAN SETİ'''
|-
|'''DOKÜMAN ADI '''
| '''DOKÜMAN KODU'''
|-
|Sistem Ömür Devri Yönetimi Rehberi (Ana Çerçeve)
|TSSÖDYP-01
|-
|Sistem Ömür Devri Yönetimi Süreçleri Rehberi
|TSSÖDYP-02
|-
|Ürün Destek Stratejileri ve Modelleri Rehberi
|TSSÖDYP-03
|-
|Entegre Lojistik Destek (ELD) Rehberi
|TSSÖDYP-04
|-
|Entegre Lojistik Destek (ELD) İsterleri Hazırlama Rehberi
| TSSÖDYP-05
|-
|Lojistik Destek Analizleri ve Kayıtları Rehberi
|TSSÖDYP-06
|-
|Tedarik Zinciri Yönetimi Rehberi
|TSSÖDYP-07
|-
|Sistem Ömür Devri Yönetiminde Demodelik Yönetimi Rehberi
|TSSÖDYP-08
|-
|Kullanım ve Destek İhtiyaçları Çerçevesinde Yerlileştirme/

Millîleştirme Rehberi
|TSSÖDYP-09
|-
|Kullanım ve Destek Safhaları Kalite Yönetimi Rehberi
|TSSÖDYP-10
|-
|Sistem Ömür Devri Yönetiminde Konfigürasyon Yönetimi Rehberi
|TSSÖDYP-11
|-
|Teknik Yayın Hazırlama Rehberi
|TSSÖDYP-12
|-
|Eğitim ve Eğitim İhtiyaçları Rehberi
|TSSÖDYP-13
|-
|Sistem Ömür Devri Yönetimi Terminolojisi
|TSSÖDYP-14
|-
|Kodlandırma ve Sınıflandırma Bilgi Kitapçığı
|TSSÖDYP-15
|-
|ASD/AIA S-Serisi ELD Spesifikasyonları Seti Tanıtım Kitapçığı
|TSSÖDYP-16
|}

== 1.7. TANIMLAR VE KISALTMALAR ==

=== 1.7.1. TANIMLAR ===
'''Tablo 2 Tanımlar Tablosu'''
{| class="wikitable"
|'''Terim'''
|'''Tanım'''
|'''Diğer Kullanım'''
|-
|Emniyet

Safety
|Ölüm, yaralanma, mesleki hastalık, ekipman veya mülkte hasar veya kayıp veya çevreye verilen hasara neden olabilecek koşullardan bağımsız olmak.
|
|-
|Güvenilirlik

Reliability
|Belirli bir zaman periyodunda, istenen çevresel ve coğrafi şartlar altında ve belirlenen kullanım profillerinde sistemin gereken fonksiyonunu hata yapmadan yapabilme/başarabilme olasılığıdır.
|
|-
|İdame Edilebilirlik

Maintainability
|Belirlenmiş prosedür ve kaynaklar kullanılarak, tanımlı bakım onarım seviyelerinde belirlenmiş yeteneğe sahip personel tarafından bakım faaliyeti gerçekleştirildiğinde, odak sistemin öngörülen performans seviyesinde tutulabilmesi veya öngörülen performans seviyesinde tekrar çalışır duruma geri getirilebilmesi kabiliyetinin ölçüsüdür.
|
|-
|Kullanıcı

User
|Harp araç, silah ve malzemelerini kullanacak ve/veya idamesini sağlayacak birimleri ifade eder.
|İhtiyaç Makamı/İdame Makamı
|-
|Kullanıma Hazır Olma

Availability
|Sistemlerin istenilen herhangi bir zamanda, istenilen performans ölçütlerini karşılayacak şekilde faal durumda olma ihtimalidir.
|
|-
|LDA İş Tanımı Dokümanı

LSA Guidance Conference Document
|LDA İş Tanımlama Toplantısı’nda değerlendirilen bulguların, analizlerin, yürütülecek faaliyetlerin ve sonuç kararlarının mutabakat altına alındığı dokümandır.
|LDA Kılavuz Konferansı Belgesi
|-
|LDA İş Tanımı Toplantısı

LSA Guidance Conference
|Desteklenebilirlik açısından ürün tasarımını etkilemeyi amaçlayan, tasarımın erken aşamalarında başlayıp, ömür devri boyunca devam eden; güvenilirliği, kullanıma hazır olmayı, maliyeti ve zaman etkinliğini ön plana çıkaran bir dizi analiz sürecinin performansına ilişkin bağlayıcı kararların alınmasını sağlayan, kullanıcı/tedarik makamı ve yüklenici tarafından yönetim kadrosu ve uzmanların katılımıyla gerçekleştirilen toplantılardır.
|LDA Kılavuz Konferansı
|-
|Müşteri

Customer
|Süreç çıktılarının teslim edildiği, yani çıktıların kullanıcısı olan taraflardır. İç müşteriler, organizasyon içinde yer alan ve sürecin bir sonraki adımı için çıktıları kullanan fonksiyon ya da fonksiyonlardır. Dış müşteriler ise, organizasyon dışında yer alan kişi ya da kuruluşlardır.
|Alıcı, İhtiyaç Makamı, Kullanıcı, Tedarik Makamı, İdame Makamı
|-
|Teklife Çağrı Dokümanı

Request for Proposal
|Tedarik edilecek ürün ve hizmet alımları ile yapım işlerinin teknik şartnamesi, ihale konusu işin tanımı, hangi şartlarda yapılacağı, sözleşme görüşmelerine esas mali, idari, hukuki hususları ve teklif verme şekli gibi konuları kapsayan dokümandır.
|
|-
|Ürün

Product
|Yüklenici tarafından, sözleşme kapsamında tedarik makamına teslim edilecek ve her bir sözleşme değişikliği için belirtilen kalemler ve bunlara ilişkin tüm sistem, donanım, yazılım ve dokümanlardır. Bu kalemler kara, deniz, hava araçları, platformlar, silah, sistem, yazılım ve bunlara ilişkin tüm destek donanım ve yazılımlarını içerebilir.
|
|-
|Ürün Kırılımı

Product Breakdown
|En az değiştirilebilir kalemlere kadar inen ürünün ürün ağacının lojistik açıdan incelenmiş fizikselkırılımıdır.
|
|-
|Yönetişim

Governance
|Resmî ve özel kuruluşlarda idari, ekonomik, politik otoritenin ortak kullanımı, karşılıklı etkilerin birlikte belirlenerek yönetimi.
|
|-
|Yüklenici

Contractor
|Bir sözleşme ile hizmet veya ürünü tasarlayan/geliştiren/üreten veya teslim/ifa eden firma, kurum ve kuruluşlar.
|
|}
=== 1.7.2. KISALTMALAR ===
'''Tablo 3 Kısaltmalar Tablosu'''
{| class="wikitable"
|'''Kısaltma'''
|'''Açık Yazımı'''
|'''Diğer Kullanım'''
|-
|<nowiki>-AIA</nowiki>
|Aerospace Industry Association of America
|
|-
|<nowiki>-ASD</nowiki>
|Aerospace andDefenceIndustries Association of Europe
|
|-
|AAK

IUA
|Analiz Altındaki Kalem

ItemUnder Analysis
|
|-
|AAS

SUA
|Analiz AltındakiSistem

SystemUnder Analysis
|
|-
|AKL

CIL
|Aday Kalem Listesi

Candidate Item List
|
|-
|BİM

MRI
|Bakım İlgili Malzeme

Maintenance Relevant Item
|
|-
|BÖM

MSI
|Bakım Önemli Malzeme

Maintenance Significant Item
|
|-
|DSB

TBD
|Daha Sonra Belirlenecek

To Be Determined
|
|-
|ELD

ILS
|Entegre Lojistik Destek

Integrated Logistics Support
|
|-
|GGT

RC
|Gözden Geçirme Toplantısı

Review Conference
|GGK

Gözden Geçirme Konferansı KK

Kılavuz Konferansı
|-
|GMB

RCM
|Güvenilirlik Merkezli Bakım

Reliability Centered Maintenance
|
|-
|HDB

LRU
|Hatta Değiştirilebilir Birim

Line Replaceable Unit
|
|-
|HTEA

FMEA
|Hata Türleri Etkileri Analizi

Failure Modes and Effects Analysis
|
|-
|HTEKA

FMECA
|Hata Türleri Etkileri ve Kritiklik Analizi

Failure Modes, Effects and Criticality Analysis
|
|-
|KKK
|Konfigürasyon Kontrol Kurulu
|
|-
|LDA

LSA
|Lojistik Destek Analizi

Logistic Support Anaylsis
|
|-
|LDAK

LSAR
|Lojistik Destek Analizi Kayıtları

Logistic Support Analysis Records
|
|-
|LDAP

LSAP
|Lojistik Destek Analizi Planı

Logistics Support Analysis Plan
|
|-
|LDAİTT
|Lojistik Destek Analizi İş Tanımlama Toplantısı
|
|-
|BGA

MTA
|Bakım Görev Analizi

Maintenance Task Analysis
|
|-
|NATO

NATO
|North Atlantic Treaty Organization
|
|-
|NSN

NSN
|NATO Stok Numarası

NATO Stock Number
|
|-
|ODS

MDT
|Ortalama Duruş Süresi

Mean Downtime
|
|-
|OOS

MTTR
|Ortalama Onarım Süresi

Mean Time to Repair
|
|-
|OSA

LORA
|Onarım Seviyesi Analizi

Level of Repair Analysis
|
|-
|ÖDM

LCC
|Ömür Devri Maliyeti

Life Cycle Cost
|
|-
|PEDU

PHST
|Paketleme Elleçleme Depolama Ulaştırma

Packaging Handling Storage Transportation
|
|-
|RAHAT

COTS
|Rafta Hazır Ticari Ürün

Commercially off the Shelf Item
|Raf Ürünü
|-
|TÇD

RFP
|Teklife Çağrı Dosyası

Request for Proposal
|
|-
|D&TE

S&TE
|Destek ve Test Ekipmanı

Support and Test Equipment
|
|}

== 1.8. TABLOLAR VE ŞEKİLLER ==

=== 1.8.1. TABLOLAR ===
Tablo 1 Değişiklik İzleme Tablosu

Tablo 2 Tanımlar Tablosu

Tablo 3 Kısaltmalar Tablosu.

Tablo 4 Örnek Soru Seti

Tablo 5 Kalem Türüne Bağlı Olarak İdame Edilebilirlik Analiz Derinliği

Tablo 6 OSA’nın Farklı Derinliklerinin Sınıflandırılması

Tablo 7 Yorumlama sürecinin zaman takvimi ile açıklanması

Tablo 8 Durum kodu örnekleri

Tablo 9 LDA Tarafından Belirlenen Farklı Yedek Parça Türleri Listesi

Tablo 10 Analiz Faaliyetleri Seçim Kriterleri

Tablo 11 Analiz Faaliyetleri Öneri Matrisi

Tablo 12 Ömür devri safhalarındaki aktivitelerin özeti

Tablo 13 Olayların Sebep Tiplerine ilişkin Örnekler

Tablo 14 Olayların meydana gelme olasılıkları

Tablo 15 Teknoloji Seviyeleri

Tablo 16 Teknoloji hassasiyetinin değerlendirilmesi

Tablo 17 Teknoloji-Hassasiyet Değerlendirmesi

Tablo 18 Onarım Seviyesi Analizi Süreç Adımları

Tablo 19 Bakım Seviyeleri ve Tanımlı Görevlere İlişkin Örnekler

Tablo 20 Görev Gereksinimleri Örneği

Tablo 21 Görev kaynaklarına örnekler

Tablo 22 Montaj Prosedürü için Gerekli Görev Kaynakları Örneği

Tablo 23 Elektronik Komple için montaj prosedürü-görev kaynakları özeti

Tablo 24 Farklı Proje Safhalarında Yazılım Destek Analizi

Tablo 25 Uyumluluk Matrisi

=== 1.8.2. ŞEKİLLER ===
Şekil 1 Entegre Lojistik Destek İşlevsel Elemanları (S3000L’den uyarlanmıştır)

Şekil 2 Tedarik Maliyetlerine Karşı Kullanım ve Destek Maliyetleri

Şekil 3 ÖDM ve LDA Arasındaki Etkileşim

Şekil 4 Temel LDA Süreci

Şekil 5 LDA adayı belirlenmesinde kullanılabilecek örnek akış diyagramı (Yapısal Olmayan Malzeme için) (S3000L)

Şekil 6 LDA adayı belirlenmesinde kullanılabilecek örnek akış diyagramı (Yapısal Malzeme için)

Şekil 7 Müşteri ile yüklenici arasındaki veri alışverişi süreci (örnek)

Şekil 8 Kullanıma Hazır Olma Kırılımı

Şekil 9 Ergonomi/Simülasyon Yazılımlarından Örnek Görüntü

Şekil 10 Kullanım safhası LDA süreci

Şekil 11 Kullanım ve destek safhası* bakım gözden geçirme akışı

Şekil 12 Modifikasyon ve değişiklik uygulaması için kullanım safhası LDA – 1

Şekil 13 Kullanım dönemi malzeme yönetimi

Şekil 14 Lojistik Destek Analizleri ile Teknik Dokümantasyon Arasındaki İlişki

Şekil 15 Lojistik Destek Analizleri ile Malzeme Desteği Arasındaki İlişki

Şekil 16 LDA ve Test Ekipmanı Arasındaki İlişki

Şekil 17 LDA ve Eğitim Arasındaki İlişki

Şekil 18 Ömür devri safhalarına göre analiz akış süreci

Şekil 19 GMB – BGA Arayüzü

Şekil 20 Bakım Görevlerinin Belirlenmesi

Şekil 21 Görev Yapılarının Oluşturulması

= 2. LOJİSTİK DESTEK ANALİZLERİNE GİRİŞ =

== 2.1. LOJİSTİK DESTEK ANALİZLERİ NEDİR? ==
Savunma ve güvenlik sistemlerinin (ürünün) temel görevi, savunma ve güvenlik ihtiyacını belirlenen kullanım konsepti ve görev profilleri çerçevesinde istenilen performans seviyesinde karşılamaktır. Ürünün kendisine tanımlanan fonksiyonları “kesintiye uğramaksızın” yerine getirebilmesi; destek unsurlarının sağlanması ve ilgili prosedürlerin yürütülmesi ile mümkündür.

Bu kapsamda; harekât ihtiyaçlarının zamanında ve verimli şekilde karşılanması ve sahip olunan kaynakların maliyet etkin kullanımı esastır. Lojistik Destek faaliyetleri söz konusu ürünün istenilen performans seviyesinde faaliyet gösterebilmesi için ihtiyaç duyulan kaynakların sağlanması ve idamesi ile ilgili idari ve teknik süreçleri kapsar.

Lojistik Destek Analizi (LDA); lojistik destek faaliyetlerinin maliyet etkin olarak yürütülmesinde yol gösterici en önemli faaliyettir. Tüm lojistik destek faaliyetlerinin teknik disiplin içinde maliyet etkin olarak planlanması, koordine edilmesi ve yönetilmesi için LDA rehberliğinde;

* Ürün ve destek unsurları güvenilirlik, kullanıma hazır olma, idame edilebilirlik, desteklenebilirlik, test edilebilirlik ve uygun Ömür Devri Maliyeti (ÖDM) ile tasarlanır,
* Kullanım ve Destek Safhaları boyunca ürünün istenilen performans seviyesinde kullanılabilmesi için ihtiyaç duyulan kaynaklar tanımlanır,
* ELD elemanlarına ilişkin esas bilgiler oluşturulur.

Lojistik Destek Analizleri; sistem ömür devri boyunca desteklenebilirlikle ilişkili olası darboğazların öngörülmesi, bahse konu darboğazların giderilmesine yönelik önleyici planların oluşturulması ve oluşturulan planların iyileştirilmesi, geliştirilmesi ve uygulamaya aktarılması amacıyla yinelemeli olarak yürütülür.

== 2.2. TARİHÇESİ VE GELİŞİMİ ==
Lojistik Destek Analizlerinin gelişimi, sayısal bilgi işlem platformları ve kompleks sistemlerin yaygınlaştığı, teknoloji yönetiminin teknoloji savaşlarına dönüştüğü 1970’li yıllardan itibaren yaklaşık 50 yıllık bir dönem içinde gerçekleşmiştir.

ELD uygulamalarının 1965 yılında Amerika’da ortaya çıkması ile birlikte, bir sistemin desteğinin de en az performans karakteristikleri kadar önemli olduğu kabul edilmiştir.

İhtiyaç Makamlarının ELD’nin uygulanmasındaki temel hedefleri; lojistik destek konularının sistemin tasarımına etki etmesini sağlamak, ürünün kullanıma/göreve hazır olma hedeflerine ilişkin ve bu hedeflere ulaşılmasını sağlayan destek gereksinimlerini belirlemek ve geliştirmek, gerekli desteği minimum maliyetle temin etmek ve ürün envantere alındıktan sonra lojistik desteğini sağlamaktır.

1980’lerin başında, LDA’ya yönelik bir süreç geliştirilerek MIL-STD-13881A yayımlanmıştır. Bu süreç en iyi ticari uygulamaları esas alarak geliştirilirken, desteklenebilir bir tasarım elde etme hedefine yönelik bütün faaliyetleri sistem mühendisliği süreçlerine entegre edecek bir metodoloji tanımlamış ve aynı zamanda fiziksel destek çözümünün geliştirilmesine yönelik basit fakat etkin yöntemler sunmuştur. Başlangıçta ABD Silahlı Kuvvetlerinin ana sistem tedarik mevzuatlarında yer verilen LDA prensipleri, halen kullanılmakta olan diğer standartların da yürürlüğe girmesiyle birlikte tedarik ve sistem mühendisliği bilimlerindeki merkez olma rolünü üstlenmiştir.

Etkin uygulamalarının görülmeye başlanması ile birlikte, Birleşik Krallık Savunma Bakanlığı tarafından da LDA süreci “Defence Standard 00-60”a entegre edilerek yayımlanmıştır. Diğer birçok ülkenin de süreci kendi sistemlerine adapte ederek kullanmaya başlamasıyla, desteklenebilirlik gereksinimlerinin sistem tasarımına dahil edilmesi sürecinde LDA evrensel bir araç haline gelmiştir.

Günümüzde ülkelerin, resmi ve özel kurumların genel prensipleri örtüşmekle birlikte uygulamada küçük farklılıklar içeren standart ve rehber dokümanları ile uygulama desteği sağlayan birçok ticari yazılım ve girişim sayesinde yeterli çeşitlilik ve derinlik oluşmuş bulunmaktadır.

== 2.3. ENTEGRE LOJİSTİK DESTEK SÜRECİ İÇİNDE LOJİSTİK DESTEK ANALİZLERİNİN YERİ VE ÖNEMİ ==
Bir ürünün ömür devri boyunca desteklenebilmesi için kullanılacak teknik bilgi ve destek çözümünü geliştirmeye dair sorumluluk ELD sürecinin kapsamındadır. ELD elemanları aşağıda belirtildiği gibidir:

* Bakım
* İkmal Desteği
* İşgücü ve Personel
* Destek ve Test Ekipmanları
* Tasarıma Etki/Tasarım Etkileşimi
* Teknik Veri ve Dokümantasyon
* Eğitim ve Eğitim Desteği
* Tesisler ve Altyapı
* Paketleme, Elleçleme, Depolama, Ulaştırma (PEDU)
* Bilgisayar Kaynakları
* İdame Mühendisliği
* Ürün Destek Yönetimi

LDA, bir ELD elemanı değildir ancak ELD’nin ayrılmaz ve temel bir parçasıdır ([https://tssodypwiki.ssb.gov.tr/index.php/Entegre_Lojistik_Destek_(ELD)_Rehberi Bkz. TSSÖDYP-04 Entegre Lojistik Destek Rehberi]).

LDA programı, ELD planlama ve kaynakların belirlenmesi için kullanılacak teknik verilerin temel kaynağını oluşturur. Lojistik Destek Analizleri ile destek elemanı gereksinimleri tanımlanarak tasarıma etki arayüzü sağlanmış olur. Ayrıca, analiz faaliyetleri ile maliyet etkin bakım çözümü, bakım seviyeleri, bakım görevleri, bakım için gerekli destek kaynakları ile yedek parça planlaması gibi hususlar belirlenerek ELD elemanlarına girdi sağlanır. Lojistik destek analizlerinin sonuçları ve destek kaynak verileri, LDA veritabanında kayıt altına alınarak bütün program elemanlarına, tasarım alternatiflerinin desteklenebilirliğini ve hedeflerini değerlendirmede kullanılacak ortak bir veri kaynağına erişimi sağlar.

ELD elemanlarının herbirinin kendi alanlarında kaynak kullanımına ilişkin verileri toplama, analiz etme ve saklama gibi işlemleri ayrı ayrı yürütmeleri, üretilen bilgiler arasında tutarsızlığa veya devamsızlığa sebep olur. LDA süreci ile birlikte tek bir veri tabanının kullanılması her bir ELD elemanının, diğerleri ile aynı bilgiyi kullanması ve bir elemanın ürettiği verilerin diğerlerinin kullanımına da sunulmasını sağlar.
[[Dosya:Şekil1 ELD Elemanları ile LDA Arasındaki İlişki.jpg|alt=|sol|küçükresim|600x600pik|Şekil 1 ELD Elemanları ile LDA Arasındaki İlişki]]

== 2.4. LDA VE ÖMÜR DEVRİ MALİYETLERİ ==
Sistemin ömür devri boyunca gerçekleşen toplam maliyetlerini tanımlamak için farklı terimler kullanılır. Bunlardan ÖDM sistemin geliştirme, üretim (veya satın alma), kullanım, destek ve elden çıkarılmasına ilişkin bütün doğrudan ve dolaylı maliyetleri kapsar.

Ürünün kullanım ve destek maliyeti genellikle tedarik maliyetinin çok üzerindedir. Bu nedenle belirli bir ürünün tedarik edilmesine ilişkin karar verme süreci sadece ürünün tedarik maliyeti değil, ömür devri boyunca beklenen kullanım ve destek maliyetleri ile envanterden çıkarma maliyetlerinden de etkilenmelidir. Tedarik maliyeti ile kullanım ve destek maliyetlerinin bütünü nisbi büyüklükleri figüratif olarak vurgulanmak üzere Şekil 2’de gösterilmektedir.
[[Dosya:Şekil 2 Tedarik Maliyetlerine Karşı Kullanım ve Destek Maliyetleri .jpg|sol|küçükresim|500x500pik|Şekil 2 Tedarik Maliyetlerine Karşı Kullanım ve Destek Maliyetleri ]]

ÖDM analizleri, alternatif sistem çözümlerini mukayese etmek için kullanılan teknik bir süreçtir. Bu analizlerin temel amacı, alternatifler arasındaki farkları vurgulamaktır. Bir geliştirme programında ÖDM analizleri, tasarım çözümü daha kesin olarak bilinmeden gerçekleştirilir ve değerlendirilir.

ÖDM analiz faaliyetleri, programın erken safhalarında, LDA faaliyetlerinden önce başlatılır. Dolayısıyla, ÖDM sonuçları, erken dönem LDA faaliyetleri kapsamında hazırlıklar yapılırken mevcut durumdadır. Bu sonuçlar, LDA program planının ve çerçevesinin oluşturulması için bir kriter teşkil edebileceği gibi, LDA aday kalemlerinin seçilmesi ve her bir aday için gerçekleştirilecek analizlerin belirlenmesini de destekler.

ÖDM analizleri tasarıma etki, ürün konfigürasyonunda yer alacak kalemlerin belirlenmesi ve Onarım Seviyesi Analizi (OSA) gibi faaliyetler esnasında karar verme kriteri olarak ve LDA gereksinimlerinin gerçekleştirilmesinin maliyet etkisini tahmin etmek için de kullanılabilir. Dolayısıyla ÖDM analiz sonuçlarının, LDA sürecinde aşağıda yer alan konulara ilişkin bir karar kriteri olarak kullanılması mümkündür:

* LDA aday kalemlerinin belirlenmesi
* Her bir aday kalem için gerçekleştirilecek analizlerin belirlenmesi
* Tasarım üzerinde etki
* Konfigürasyon Birimlerinin/Kalemlerinin Değerlendirilmesi
* Onarım Seviyesi Analizi (OSA)

LDA süreci kapsamında Hata Türleri ve Etkileri Analizi (HTEA), Bakım görev Analizi (BGA) gibi farklı analiz faaliyetleri sonucunda birçok veri üretilir. Süreç boyunca kayıt altına alınan gereksinimler ve üretilen veriler daha sonra ÖDM modelini güncellemek için de girdi oluştururlar. Dolayısıyla, LDA veri tabanı ile ÖDM analizleri arasında tutarlılığı sağlamak son derece önemlidir. ÖDM ve LDA arasındaki etkileşim Şekil 3’te gösterilmiştir.
[[Dosya:Şekil3 ÖDM ve LDA Arasındaki Etkileşim.jpg|alt=|sol|küçükresim|760x760pik|Şekil 3 ÖDM ve LDA Arasındaki Etkileşim]]

== 2.5. LDA SÜRECİNİN ÇIKTILARI VE PROJELERDE LDA FAALİYETLERİNİN ETKİSİ ==
Bir tedarik programını etkileyen dört temel faktör; maliyet, takvim, performans ve desteklenebilirliktir. LDA süreci, bir sistem/ekipman ile ilişkili olarak desteklenebilirlik ve maliyet faktörlerine doğrudan girdi sağlayarak tedarik ile ilişkili karar verme sürecine önemli katkıda bulunur.

Programlar arasında farklılık göstermekle birlikte LDA sürecinin çıktısı olarak sistem seviyesinde tedarik kararlarını etkileyen temel hususlar şunlardır:

* Maliyet: Bütün savunma tedarik programları yüksek kalite ve kabiliyete sahip, bütçelenebilir sistemler temin etmeyi hedefler. Bir ürünün bütçeye uygunluğunun değerlendirilebilmesi için destek yatırımları ve kullanım ve destek maliyetlerinin de diğer tedarik maliyet kalemleri ile birlikte dikkate alınması gerekir. Ömür devri maliyet tahminleri, farklı sistem alternatifleri için yatırım maliyetleri ile tekrarlanan maliyetleri karşılaştırır. Kullanılan maliyet analizi yöntemi, sistem seviyesi güvenilirlik, idame edilebilirlik vb. karakteristikleri, kullanım oranları ve operasyon senaryoları varsayımlarına dayanan belli göreve hazır olma seviyelerine ulaşmak için gerekli olan destek kaynaklarını dikkate almalıdır.
* Bütçelenebilirlik: ÖDM’ye dair bütün ana kalemler dikkate alınmalıdır. Bu çalışmalarda temel hedef, kullanıma hazır olma gibi ana kısıtları dikkate alarak maliyetleri en aza indirgemektir. Ürünün tedarik programı sonrasında, kullanım ömrü boyunca sürdürülecek değerlendirmeler ömür devrinin etkin olarak yönetimine önemli katkı sağlar. Bu değerlendirmeler, sadece maliyetlerin zaman içinde değişmesi nedeniyle değil aynı zamanda “bütçeye uygunluk” değerlendirmesinin de değişen ekonomik koşullara bağlı olarak değişime tabi olması nedeniyle gerekli olacaktır. Yıllara sari olarak sistemin kullanım ve desteği için karşılaşılacak mali boyut bütçelenebilir olmalıdır. Dolayısıyla, sistemin ömür devri boyunca sahip olma maliyetini azaltacak fırsatları araştırmak önemlidir.
* İş gücü ve personel kısıtları: Yeni sistem/ekipmanlar ile birlikte ortaya çıkacak iş gücü ve personel beceri ihtiyaçları, performans, ağırlık vb. diğer tasarım parametreleri ile birlikte yeni sistem/ekipman konseptinin ilk ortaya çıkışıyla birlikte erken safhalarda yönetilmelidir.
* Göreve Hazır Olma: Ürün desteği ile ilgili tasarım parametreleri (örn. güvenilirlik, idame edilebilirlik), ürün destek kaynakları (yedek parça, iş gücü vb.) ve ikmal sistemi parametreleri sistemin kullanıma hazır olma hedefleri ile ilişkilendirilmelidir. Bu tür hedefler, sistemden sisteme, barış zamanı ve savaş zamanı durumlarına göre değişkenlik gösterir. Sistemin göreve hazır olması, sistemin kullanım profilleri içinde yer alan görevler için gerekli olan tüm unsurların hazır bulunması demektir ve sistemin/ekipmanın en erken safhalarından itibaren yönetilmesidir.

== 2.6. LDA STANDARTLARI/SPESİFİKASYONLARI ==

* MIL-STD-1388-1A (iptal): LDA konusunda en bilinen ve yaygın olarak kullanılan standart “MIL-STD-1388-1A Logistic Support Analysis” isimli standarttır. Amerikan Savunma Bakanlığı tarafından ilk olarak 1983 tarihinde yayımlanan bu standart, mantıksal ve yinelemeli bir kurgu ile gerçekleştirildiğinde LDA sürecini oluşturan genel gereksinimler ve görev tanımlarından oluşmaktadır. MIL-STD 1388-1A, 1997 yılında iptal edilmiş olup yerini “MIL-HDBK-502 Tedarik Lojistiği” dokümanı almıştır.
* MIL-STD-1388-2B (iptal): 1388-1A’ya göre gerçekleştirilecek analizlere dair veri tanımlarının ilişkisel tablo yapısına dayandırıldığı veri tabanı standardıdır. 1996 yılında iptal edilmiştir.
* MIL-HDBK-502A: Amerikan Savunma Bakanlığı tarafından 1997 tarihinde “Tedarik Lojistiği” ismi ile yayımlanan bu el kitabının “A revizyonu” 2013 yılında “Ürün Destek Analizleri” ismi ile tekrar yayımlanmıştır (Amerika’da önceki yıllarda lojistik destek analizleri olarak adlandırılan analizler günümüzde ürün destek analizleri olarak isimlendirilmektedir). Halen yürürlükte olan bu doküman, sistem ve ekipmanların ömür devri boyunca ürün destek analizlerinin gerçekleştirilmesine yönelik bir çerçeve tanımlamaktadır. Bütün olarak ürün destek analizleri sürecini ve ilişkili faaliyetleri, Savunma Bakanlığı desteklenebilirlik hedeflerini karşılayabilmek için söz konusu faaliyetlerin seçim ve uyarlama yöntemlerini ve LDA teslimatlarına yönelik olarak sözleşmelerde yer alabilecek örnek ifadeleri içermektedir.
* MIL-PRF 49506 (iptal): Lojistik Yönetim Bilgisi isimli bu spesifikasyon tedarik lojistiği yönetim işlevine, yüklenicilerden destek ve destek ilişkili mühendislik ve lojistik bilgilerinin temin edilmesine yönelik olarak 1996 yılında yayımlanmış ancak 2005 yılında iptal edilmiştir.
* UK-DEF-STAN-00-60 Part 1 (iptal): İngiltere Savunma Bakanlığı tarafından 1994 yılında yayımlanan UK-DEF-STAN-00-60 Part 1 “Logistic Support Analysis (LSA) and Logistic Support Analysis Record (LSAR)” ise MIL-STD-1388’in bir varyantı olarak nitelendirilebilir. 2010 yılında iptal edilmiştir. Günümüzde UK-DEF-STAN-00-600 kullanılmaktadır.
* GEIA 0007: “Lojistik Ürün Bilgisi” olarak isimlendirilen bu standartta veri tanımları 1388-2B gibi tablo yapısına dayalı olmakla birlikte, veri değişimi XML teknolojisi üzerine inşa edilmiştir. MIL-STD-1388-2B’nin yerini almıştır.
* S3000L: Hazırlık çalışmalarına Aerospace and Defence Industries Association of Europe (ASD) tarafından 2005 yılında başlanılan S3000L’nin 1.0 versiyonu ASD ve Aerospace Industry Association of America (AIA) arasında Haziran 2010 tarihinde imzalanan mutabakat zaptı ile birlikte yayımlanmış, Temmuz 2014 tarihinde 1.1 versiyonu ile güncellenmiştir. S3000L genel olarak MIL-STD-1388-1A, MIL-HDBK-502, DEF-STAN-00-60 ve ISO 10303-239 PLCS içerisinde tanımlanan aktivite modeline dayandırılmıştır.
[[Dosya:LDA Doküman Gelişimi.png|alt=LDA Doküman Gelişimi|sol|küçükresim|800x800pik|LDA Doküman Gelişimi]]

= 3. DESTEKLENEBİLİRLİK VE DESTEKLENEBİLİRLİK İLİŞKİLİ TASARIM FAKTÖRLERİ =

== 3.1. DESTEKLENEBİLİRLİK NEDİR? ==
Desteklenebilirlik, sistem tasarım özelliklerinin ve planlanan lojistik kaynakların sistemden beklenen operasyon ve göreve hazır olma gereklerini sistemin ömür devri boyunca uygun maliyette karşılayabilme derecesidir (yeteneğidir). Desteklenebilirlik sistem tasarımının ayrılmaz bir parçası olup ömür devrinin erken safhalarında değerlendirilmelidir.

Desteklenebilirliğin ömür devrinin erken safhalarında, sistem geliştirme safhasında dikkate alınması sistemi desteklemek için gereken kaynak miktarının azaltılmasında, sistemin gayri-faal kalma süresinin kısalmasında etkilidir. Bu da ÖDM’nin azaltılmasında ve sistemin faal tutulmasında önemli bir rol oynar. Desteklenebilirliğin ömür devrinin erken safhalarında değerlendirilmemesi tedarik ve destek maliyetlerinde artışa, teslimat sürelerinde uzamaya, gayrı faal kalma süresinde artışa ve kalite ile ilişkili problemlere yol açabilir ve bu da ÖDM’de ciddi artışlara neden olabilir.

== 3.2. DESTEKLENEBİLİRLİK HEDEFLERİ ==
Desteklenebilirlik hedefleri, sistemden beklenen görev ve performans ölçütleri ile yakından ilişkilidir. Temel hedef sistemin kullanıma/göreve hazır olması ve kendisine verilen görevi başarı ile tamamlayabilmesidir. Göreve hazır olma sistemin teknik özellikleri, destek altyapısı (ekipman, malzeme, iş gücü ve eğitimli personel vb.), destek idari yapısı, organizasyonu ve destek süreçleri ile ilişkilidir ve sistemin operasyonel uygunluğunun bir göstergesidir.

Bir diğer desteklenebilirlik hedefi ise sistemin maliyet etkin bir şekilde desteklenmesidir. Sistemin kendinden beklenen performans ve göreve hazır olma kriterlerini karşılayabilmesi için gerekli olan tasarım özelliklerinin, destek kaynaklarının ve destek altyapısının belirlenmesinde maliyet etkin bir yaklaşım izlenilmesini hedefler.

Desteklenebilirlik, destek sisteminin destek ihtiyaçlarına mümkün olan en kısa sürede yanıt verebilmesini hedefler. Destek sisteminin etkin olmasında destek idari yapısı ve organizasyonu, destek altyapısı (test, destek ve kalibrasyon ekipmanları, destek ve yedek malzemeleri, eğitimli personel ve iş gücü vb.), destek kaynaklarının boyut, ağırlık, paketleme, taşınma vb. özellikleri ve destek süreçleri gibi faktörler önemli rol oynar.

== 3.3. DESTEKLENEBİLİRLİK İLİŞKİLİ ÜRÜN PERFORMANS PARAMETRELERİ ==
Ürün desteklenebilirliği, sistemlerin, alt sistemlerin ve bileşenlerin kullanıma hazır olma ve operasyonel kabiliyetlerinin idamesi için gerekli destek bileşenlerinin oluşturulmasıdır. Bu kapsamda yapılan analizlerin temel amacı desteklenebilirlik parametrelerinin sistem tasarımlarına dahil edilmesinin sağlanmasıdır.

Desteklenebilirlik maliyet, takvim ve performans ile birlikte sistem tedarik kararlarını etkileyen ana faktörlerden biridir. Yüksek kalitede maliyet etkin çözümler üretilerek kullanıcı/tedarik makamı ihtiyaçları karşılanmalıdır. Erken safhalarda iyileştirme noktalarının belirlenebilmesi ve desteklenebilirlik bakış açısıyla tasarımlara etki edilebilmesi için LDA, konsept/geliştirme safhasının en başından itibaren projelerin ayrılmaz bir parçası olmalıdır. Bu anlamda, sistem/ekipman geliştirme süreçlerine etki eden desteklenebilirlik parametreleri; amaçlar, eşik değerler, nitel ve nicel kısıtlar ve sistem/ekipman geliştirme gerekleri olarak sınıflandırılabilir.

Desteklenebilirlik karakteristikleri projeler arasında farklı tanımlanabilmekle birlikte en yaygın olarak kullanılan performans parametreleri şunlardır:

* Arızalar Arası Ortalama Süre,
* Ortalama Onarım Süresi,
* Onarım Çevrim Süresi,
* Kullanıma Hazır Olma,
* ÖDM.

Aşağıdaki belirtilen unsurlarla desteklenebilirlik sürecine girdi olacak şekilde ara yüzler sağlanmalıdır:

* Güvenilirlik,
* İdame edilebilirlik,
* Kullanıma hazır olma,
* Desteklenebilirlik
* Test edilebilirlik,
* İnsan faktörleri mühendisliği,
* Entegre lojistik destek elemanları,
* Konfigürasyon yönetimi,
* Envanterden çıkarma yönetimi,
* ÖDM.

= 4. LDA GENEL GEREKSİNİMLERİ =

== 4.1. LOJİSTİK DESTEK ANALİZ PROGRAMI ==
Sistem/ekipman tasarım ve geliştirme programlarında bir LDA Programı oluşturulması ve uygulanması faaliyetlerin sistematik ve zamanında gerçekleştirilmesi kapsamında önemlidir. LDA programı, aşağıdaki temel elemanlardan oluşur:

* Tasarımı desteklenebilirliği sağlayacak şekilde etkilemek ve uygun lojistik kaynaklarını tespit edebilmek için gerçekleştirilmesi gereken LDA faaliyetlerini belirleyen bir LDA planı
* LDA gereksinimlerinin zamanlamasını ortaya koyan bir takvim/planlama (LDA takvimi proje faz ihtiyaçlarına dayandırılmalı ve diğer proje gereksinimleri ile birbirini tamamlayıcı ve destekleyici şekilde ortaya konmalıdır)
* LDA faaliyetlerine ilişkin sorumlulukların tanımlanarak ilgili personele atanması
* Tasarım, güvenilirlik, emniyet ve ELD elemanları (disiplinleri) ile gerekli arayüzlerin kurulması ile girdi-çıktıların sağlanması

=== 4.1.1. LDA STRATEJİSİ ===
Tedarik programının erken safhalarında genel bir LDA stratejisi geliştirilmelidir.

LDA stratejisinin belirlenmesi, bir LDA programı kapsamında gerçekleştirilmesi gereken ilk planlama faaliyeti olup maliyet açısından en etkin programı geliştirmede kritik öneme sahiptir. Bu faaliyet genel olarak LDA faaliyetlerini içeren herhangi bir talep dokümanı oluşturulmadan gerçekleştirilmelidir. LDA gereksinimlerini nihai hale getirmeden önce olası tasarım ve operasyonel yaklaşımların, desteklenebilirlik karakteristiklerinin ve mevcut verilerin analiz edilmesi, LDA programının tasarım üzerinde desteklenebilirlik etkisini azami ölçüde sunan temel alanlara odaklanmasını sağlar.

LDA stratejisi sistem/ekipman için önerilen desteklenebilirlik hedeflerinin kapsamını ve gerçekleştirilmesi istenen niceliksel analizleri, tedarik programı açısından en iyi maliyet faydasını sağlayacak şekilde belirlemelidir.

TÇD oluşturulurken tanımlanacak ön LDA stratejisi yüklenici tarafından yapılması “zorunlu/tavsiye edilen/isteğe bağlı” LDA faaliyetlerinin teklif aşamasında belirlenmesine ışık tutmalıdır. Yüklenicinin etkin bir LDA programı oluşturması ve yürütmesinde kullanılan LDA stratejisi, yüklenici seçim sürecinde etkili olmalıdır.

LDA stratejisi oluşturmanın ilk adımı hem müşteri hem de yüklenici tarafında herhangi bir çalışmaya başlamadan önce LDA’ya ilişkin ne yapılması gerektiğine dair bilinçli bir karar verme sürecinin yürütülmesini sağlamaktır.

LDA gereksinimleri, ürünü oluşturan sistemler, alt sistemler ve bileşenler için niceliksel, niteliksel ve test ile ilişkili LDA gereksinimlerinin sağlanmasını içerecek şekilde kapsamlı bir LDA programı oluşturmak amacıyla analiz edilir. Bu çalışmanın sonunda ortaya çıkan LDA programı LDA gereksinimlerini karşılayan uyarlanmış ve maliyet etkin bir program olmalıdır.

LDA programının yönetimi için LDA stratejisinin oluşturulmasına başlanması ön konsept safhasında ihtiyaç makamı/kullanıcı tarafından gerçekleştirilmesi gereken bir faaliyettir ve bu strateji TÇD yayımlanmadan önce ihtiyaç makamı/kullanıcı ve tedarik makamı tarafından netleştirilmelidir. Yüklenici adayları LDA stratejisine yönelik çalışmalarını konsept safhasında yaparlar. Yüklenici, geliştirme ve üretim safhalarında LDA stratejisinin geliştirilmesi ve güncellenmesi sorumluluğunu üstlenir. Yüklenicinin bu sorumluluğu kullanım ve destek safhalarında da garanti dönemi ve sonrasına ilişkin düzenlemelere bağlı olarak devam eder. Ancak LDA stratejisi konusundaki genel sorumluluk sistemin ömür devri boyunca müşteri’dedir.

Strateji geliştirilirken verilmesi gereken önemli kararlardan biri hangi LDA görevlerinin/ faaliyetlerinin kim tarafından gerçekleştirileceğidir. İstenen LDA faaliyetlerinin gerçekleştirilmesinin yaklaşık olarak maliyeti, gerekli olduğunda kaynakların/bütçenin sağlanabilmesi amacıyla kamu tarafından hesaplanmalı/öngörülmelidir.

LDA Stratejisi geliştirme faaliyeti tek başına spesifik bir doküman üretilmesine yol açmaz. Bu faaliyetin sonuçları ELD Planı’nda (ELDP) yer alır.

Program ilerledikçe, takvim değişikliği, tasarım değişikliği, bütçe/maliyet değişikliği gibi önemli değişiklikler olduğunda, LDA stratejisi de güncellenmelidir.

=== 4.1.2. LDA AKTİVİTELERİ VE TEMEL LDA SÜRECİ ===
LDA süreci ile tasarıma etki faaliyetleri Şekil 4’de gösterilmektedir. Zamansal olarak akış projeye özgü olarak farklılık gösterebilir.
[[Dosya:Şekil6.4.jpg|alt=Şekil 4 Temel LDA Süreci|sol|küçükresim|632x632pik|Şekil 4 Temel LDA Süreci]]

Müşteri gereksinimleri ve operasyonel konsept benzer sistemler ve/veya tasarım ve geliştirme faaliyeti yapılmış olan sistem/alt sisteme ait veriler kullanılarak yapılan karşılaştırmalı analiz sonuçları da tasarım ve geliştirme faaliyetlerinin girdisi olacaktır. Bu bilgiler ile bu bilgilere dayalı olarak yapılan varsayımlar kullanılarak taslak olarak aday kalem listesi hazırlanır. Tasarım ve geliştirme faaliyetleri kapsamında emniyet analizi, güvenilirlik analizi ve HTEKA çalışmaları yapılır ve sonuçlara göre tasarıma girdi sağlanır. Bu çalışmaların çıktıları da insan faktörleri analizi, hata ağacı analizi, yazılım destek analizi, özel olay ve hasar analizi, önleyici bakım analizi, test edilebilirlik analizi için kullanılır. Bu analizler sonunda aday kalem listesi nihai hale gelir. Bu liste üzerinden OSA ve BGA yapılır. Kullanım ve destek dönemi LDA faaliyetleri ihtiyaç olması durumuda (güncellemelerin/modifikasyonların olması durumunda, kullanım verilerine göre vb) gerekli görülen analizler tekrar yapılacak ve ELD elemanları üzerine etkisi tekrar değerlendirilecektir. Bu süreç kapsamında konfigürasyon yönetim faaliyetleri yürütülerek tüm bilgi/verilerin kayıt altına alınması, izlenebilirliğin kurulması sağlanacaktır.

=== 4.1.3. PROGRAM YÖNETİM İLKELERİ, ROLLER VE SORUMLULUKLAR ===
Lojistik destek analizleri kapsamında organizasyonlar içerisinde tanımlanmış ekipler, aşağıda sıralanan faaliyetlerden sorumlu olacaktır:

* Güvenilirlik, idame edilebilirlik, kullanıma hazır olma, desteklenebilirlik, test edilebilirlik, insan mühendisliği ve çevresel uygunluk gibi konularda girdi sağlayarak sistem ve destek sistemi tasarımına desteklenebilirlik karakteristiklerinin katılmasının sağlanması ve ilgili gereksinimlerin tanımlanması,
* Destek sistemini ve gerek duyulduğu takdirde eğitim sistemini geliştirmek ve lojistik destek kaynaklarının (ikmal destek, destek ekipmanı, teknik veri, tesisler, PEDU, iş gücü ve personel, eğitim ve eğitim desteği) planlaması, geliştirilmesi ve sunulması,
* Sistem mühendisliği ve tasarım mühendisliği faaliyetleri ile desteklenebilirlik mühendisliği faaliyetleri arayüzünün kurulması,
* Standardizasyonun, birbirinin yerine kullanılabilirliğin, birlikte çalışabilirliğin ve demodelik yönetiminin sağlanması.

Desteklenebilirlik sorumlusu/lideri ile ELD yöneticisi ve diğer işlevsel yönetim sorumluları arasındaki koordinasyonun ve ara yüzlerin oluşturulması ve sürdürülmesi LDA programının başarısı açısından büyük önem taşır. Ayrıca, etkin bir ELD/LDA program yönetimi açısından hem müşteri hem de yüklenici bünyesinde bir ELD/LDA organizasyonu oluşturulması gereklidir.

=== 4.1.4. LOJİSTİK DESTEK ANALİZİ PLANI (LDAP) ===
LDAP, proje süresince yürütülecek LDA faaliyetlerinin kimler tarafından, nasıl ve hangi esaslara dayanılarak yürütüleceğinin yer aldığı ve özellikle analizlerin icrasında rol alacak kişilerin sık sık başvuracağı bir el kitabı niteliğindedir. Bu plan, bir bakıma proje kapsamında hangi analizlerin yapılacağı ve nasıl yapılacağına dair bir yol haritası çizer. Aynı zamanda, programın farklı safhalarında ilerlemeyi ölçmek için de bir temel sunar.

LDAP, proje fazlarına göre uygun kapsam ve derinlikte aşağıdakilerle sınırlı olmamak kaydıyla gerekli bilgileri içermelidir:

* İlgili proje dokümanlarında tanımlanan sistemin lojistik gereksinimlerinin karşılanması için nasıl bir LDA programı yürütüleceği tanımlanmalıdır,
* LDA organizasyonu tanıtılır. Yöneticiler, analiz ekipleri, tasarım ekipleri, altyükleniciler, arayüzü sağlayacak sorumlular ile müşteri tarafındaki sorumlular belirtilir.
* Sistem ve alt sistemlerin tanımı yapılır, alt sistemlerin arayüz bilgileri belirtilir, görev profilleri tanımlanır.
* Sistemin karşı karşıya kalacağı çevresel koşullar, stres etkenleri (mekanik, termal, elektriksel, kimyasal, elektro-kimyasal, radyasyon) ve yüklemeler/zorlamalar belirlenir.
* Lojistik destek analizlerinin çerçevesini oluşturacak olan temel kural ve varsayımlar tanımlanır.
* Her bir LDA faaliyeti için referans alınacak standartlar, kullanılacak matematiksel modeller ve formüller tanımlanır, bu faaliyetlerin nasıl raporlanacağı belirtilir.
* Lojistik destek analizlerinin uygulama adımları kısaca anlatılarak çalışma ekipleri, tasarım ekipleri, alt yükleniciler ve müşterinin ilgili adımlardaki rolleri tanımlanır.
* LDA için aday kalemlerin seçim kriterleri belirtilir. Aday kalem listesi ve aday kalem listesinde yer alan sistem elemanlarına hangi analizlerin uygulanacağı listelenir (liste, analiz için önerilen ve önerilmeyen bütün bileşenleri ve seçilme/seçilmeme gerekçelerini içermelidir).

* LDA’ya tabi olacak bileşenlerin seçilmesinde kullanılacak kırılım yapısının (yazılım kalemleri dahil) belirlenir.
* Kullanılacak kırılım elemanlarının numaralandırma sistemi tanımlanır.
* Desteklenebilirlik ve desteklenebilirlik ilişkili tasarım gereksinimlerinin tasarımcılara ve ilgili personele hangi yöntemlerle aktarılacağı belirtilir.
* Desteklenebilirlik ve desteklenebilirlik ilişkili tasarım gereksinimlerinin altyüklenicilere kırılma yöntemleri ve uygulanacak kontroller belirtilir.
* LDA verilerinin konfigürasyon yönetim süreci tanımlanır.
* Projenin genel takvimi ile entegre olan LDA uygulama takvimi oluşturularak süreçlerin izlenebilirliği sağlanır.
* Kullanım ve destek safhaları kapsamında planlanan faaliyetler ve bu dönemde toplanması gereken verilerin içeriği tanımlanır.
* LDA faaliyetlerinin ELD ve tasarım süreçleri ile olan arayüzleri tanımlanır.
* Gözden geçirme faaliyetlerinin detayları belirlenir.

LDAP, konsept safhasında taslak olarak hazırlanmalı ve geliştirme safhasının başında detaylandırılarak güncellenmelidir. LDA faaliyetleri yapısı itibari ile yinelemeli ve dinamiktir. LDAP’ın projenin mevcut durumunu ve planlanan değişiklikleri yansıtacak şekilde gerektiğinde güncellenmesi gerekir.

LDA faaliyetlerinin planlanması ve koordinasyonu desteklenebilirlik mühendislerinin sorumluluğundadır. LDA sürecinin, sistem mühendisliği ve tasarım süreçlerinin entegre bir parçası olması sağlanmalıdır. Bu doğrultuda oluşturulacak bir LDAP, ömür devri boyunca gerekli ve/veya ihtiyaç duyulan safhalarda LDA faaliyetlerinin gerçekleştirilebilmesi için gerekli stratejiyi ve proje gereksinimlerini karşılamak için gerekli olan yönetim, organizasyon ve prosedürleri tanımlar.

LDAP etkin bir LDA programı oluşturmak ve yürütmek için kullanılan temel araçtır. Planda yer alacak birçok husus müşteri ve yüklenici arasında gerçekleştirilecek LDA İş Tanımlama Toplantısı’nda görüşülerek karara bağlanabilir. TÇD’lere cevaben hazırlanan LDAP, müşteri tarafından yüklenici adaylarının LDA yaklaşımlarını ve faaliyetleri yürütecek organizasyon yapılarını değerlendirmek amacıyla kullanılabilir.

LDAP formatı sözleşme kapsamında müşteri tarafından belirlenebilir. Eğer sözleşmede bir format belirlenmemişse yüklenici söz konusu ürün ve proje gereksinimlerine en uygun formatı kendisi belirleyecektir.

Örnek bir LDAP içeriği EK-I’da sunulmuştur.

=== 4.1.5. PROGRAM VE TASARIM GÖZDEN GEÇİRMELERİNE KATILIM ===
LDA çalışmaları; ön tasarım/kritik tasarım gibi tasarım gözden geçirme toplantıları, teknik bilgi toplantıları, üretime hazırlık gözden geçirme toplantısı gibi proje kapsamında gerçekleştirilen gözden geçirmelerin bir parçası olmalıdır.

Desteklenebilirlikle ilgili bütün hususlar ve mevcut durum bilgisi uygun ve zamanında çözümler elde edilebilmesini sağlamak ve takip edebilmek üzere gözden geçirme toplantıları sonuç dokümanlarında dokümante edilir. Diğer taraftan sistem/ekipman tasarım gözden geçirmelerine ilave olarak LDA’ya özel gözden geçirme toplantıları da ihtiyaç duyulması halinde planlanabilir. Bu toplantılarda tasarım ve program gözden geçirmelerinde adreslenen birtakım konular daha detaylı şekilde incelenebilir ve/veya LDA faaliyetlerinin ilerleme durumları gözden geçirilebilir. Proje gözden geçirme toplantılarına LDA faaliyetlerinin dahil edilmemesi ürünün geliştirmesi ve desteklenmesine ilişkin risklerin artmasına sebep olacaktır.

= 5. LOJİSTİK DESTEK ANALİZ SÜRECİ =
Yeni bir ürünün hizmete alınması veya mevcut sistemlerin modernizasyonu ile birlikte bütün lojistik gereksinimler de doğru zamanda sağlanmış olmalıdır. Bu amaçla ürünün tasarımı esnasında lojistik gereksinimlerin dikkate alınmasını sağlayacak bir süreç oluşturulması gereklidir. Söz konusu süreç kapsamında yüklenici ve müşteri uygun desteklenebilirlik seviyesine erişmek için gerçekleştirilmesi gereken faaliyetler üzerinde mutabakat sağlamalıdır. Lojistik hususların erken dönemde ele alınması hem operasyonel hem de ekonomik açıdan büyük önem taşır. Operasyonel konsepte uygun şekilde kullanılamayan ve idame edilemeyen bir ürün kullanıcı açısından kabul edilebilir olmayacaktır.
[[Dosya:TSSODYP06.LDASURECI.jpg|alt=|sol|küçükresim|758x758pik]]

== 5.1. ÜRÜN KULLANIM VERİSİNİN TANIMLANMASI ==
Yeni bir ürünün desteklenebilirlik özelliklerinin belirlenebilmesi için ürünün planlanan kullanımına yönelik ilişkili bütün verilerin erişilebilir olması ve bu bilgilerin uygun bir şekilde Operasyonel Kullanım Konsepti (veya Operasyonel Konsept) dokümanında yer alması veya ilgili diğer dokümanlarda derlenmiş olarak belirtilmesi gerekir.

Projelerin erken safhalarında bazen ihtiyaç duyulan bilgiler tam olarak mevcut olmayabilir. Ancak kullanım senaryosunun konsept sahfasında tanımlanmış olması önemlidir. Bu durumda ürünün kullanımına ilişkin bilgiler yinelemeli adımlarla derlenmelidir. Kullanım senaryosundaki olası değişiklikler lojistik açıdan kritik önem arzetmekte olup, desteklenebilirlik mühendisleri tarafından dikkate alınarak analiz tekrarının gerekip gerekmediği değerlendirilmelidir.

Ürün kullanım verileri; genel kullanım bilgisi, operasyonel gereksinimler, müşteri gereksinimleri, saha incelemelerinden gelen bilgiler ile kalifikasyon ve sertifikasyon gereksinimleridir.

=== 5.1.1. ÜRÜN GENEL KULLANIM BİLGİSİ ===
Hizmete alınacak ürünün kullanımına yönelik tüm ön şartlar ve ürün tasarımı ile performans verilerinden kaynaklı stratejik hususlar dikkate alınarak genel bir destek stratejisini tanımlanmalı ve ELDP içerisinde dokümante edilmelidir. Söz konusu strateji, daha ileri lojistik destek analizlerin gerçekleştirilmesi ve operasyonel gereksinimlerin ve müşteri gereksinimlerinin oluşturulmasına esas temel kılavuzu oluşturmalıdır.

Operasyonel konsept ve müşteri gereksinimleri oluşturulmadan önce veya eşzamanlı olarak ürünün kullanımına yönelik cevaplanması önerilen bazı örnek sorular aşağıda sıralanmıştır (S3000L). Soruların cevaplanmasının temel amacı, mevcut olan en iyi bilgiyi kullanmak şeklinde belirlenmelidir.

* Ürün nasıl kullanılacaktır? (Ürünün, kilit özellikleri ve gereksinimleri ile temel teknik veri ihtiyaçlarını da içerecek şekilde kısa bir tanımı)
* Yükleneci Lojistik Desteği istenecek midir? Eğer istenecekse, hangi bakım kedemelerinde? (Bu çok genel bir soru olup, aşağıda sıralanan bazı hususların detaylı incelenemesinin akabinde cevaplanması mümkün olacaktır.)
* Ürün nerede kullanılacak ve idame edilecektir?
* Ürün hangi çevresel koşullarda kullanılacak ve idame edilecektir? (Örn. sabit, mobil, endüstriyel, tehlikeli, tehlikesiz)
* Ürünün karakteristiklerini etkileyecek (güvenilirlik, idame edilebilirlik, vb) çevresel koşullar nelerdir? Çevresel koşullar, ürünün onarım tarzını etkileyecek mi?

* Ürün ne kadar süre ile kullanılacaktır? (Örneğin, eğer ürün kısa bir süre için envanterde kalacaksa bu durumda uzun ve maliyetli bir organik destek yapısı oluşturma süreci yerine yüklenici desteği tercih edilebilir.)
* Bakım konsepti nedir? Ürün desteği için kaç bakım kademesi planlamaktadır?
* Her bakım kademesi için tipik özellikler ve/veya faaliyetler neler olabilir?
* Yeni ürünün destek konseptine adapte edilebilecek sürmekte olan bakım kabiliyetleri var mı?
* Öngörülen kullanım mahallinde veya yakınında bulunan başka veya benzer ürünlere yönelik mevcut bakım kabiliyetlerinin yeni ürün için kullanılması mümkün ve etkin olabilecek midir?
* İhtiyaç Makamı/kullanıcı ürünün onarım faaliyetlerine dahil olmalı mı yoksa gerçekleştireceği basit düzeltici bakım ile mi sınırlı olmalıdır? İhtiyaç Makamı’nın sürece dahil olması kendisi tarafından sağlanabilecek yeteneklere bağlıdır. Ayrıca, idame makamlarının imkan ve kabiliyetleri de dikkate alınmalıdır.

* Kullanıcı açısından önleyici ve düzeltici bakım faaliyetleri için bakım süresi ve sıklığı konusunda kabul edilebilir rakamlar nelerdir?
* Önleyici bakımlar için kısıtlamalar söz konusu mudur? (örn. personel ve tesislerin mevcudiyetine ilişkin bazı özel ön şartlar nelerdir)?
* Geliştirilen yazılım ne kadar olgun ve ne kadarı müşteriye özgüdür? (Yazılımların tam olarak olgun bir seviyeye erişmesi uzun süreler alabilir. Lojistik destek yapısı kullanıcı tarafından talep edilecek potansiyel güncellemelerin yazılım bakımını da adreslemelidir).
* Kullanıcı tarafından gerçekleştirilecek herhangi bir yazılım/veri yükleme/kaldırma işlemi var mıdır? Ürünün yazılım/veri yükleme işleminden sonra düzgün şekilde çalıştığı nasıl güvence altına alınacaktır?
* Teknolojideki değişikliklerden kaynaklı olarak üründe beklenen yenileme veya iyileştirme/yükseltme ihtiyaçları nelerdir? (Bu soru, destek yapısının üründeki değişikliklere nasıl ayak uydurabileceği ve destek stratejisinin nasıl uyarlanacağına ilişkindir. Bu konuda öngörülen zorluklar Yüklenici Lojistik Desteği stratejisinin belirlenmesinde etken olabilir).

=== 5.1.2. OPERASYONEL GEREKSİNİMLER ===
Operasyonel gereksinimler hem niceliksel hem de niteliksel olarak tanımlanmalıdır. Donanım, kullanım ve desteklenebilirlik arasında ilişkileri tanımlayan, işletim mahali ve ürün kullanımına yönelik daha önce gerçekleştirilen analizler dikkate alınmalıdır.

Desteklenebilirlik gereksinimleri doğrudan operasyonel gereksinimlerinden türetilirler. Her bir desteklenebilirlik gereksinimi bir operasyonel gereksinime dayandırılmalı, aralarındaki ilişki açıkça belirlenmeli ve sistem gereksinimleri kapsamında dokümante edilmelidir.

Operasyonel gereksinimler yazılırken anahtar performans göstergeleri de belirlenmelidir. Anahtar bir parametre olarak tanımlanmayan herhangi bir parametre, desteklenebilirlik karakteristiklerinin olumsuz etkilendiği durumlarda değiştirilmek için aday olacaktır. Operasyonel gereksinimler, yüklenicinin programın erken safhalarında “zorunlu olan özellikler” ile “olsa iyi olur” diye düşünülen özellikler arasında karar vermesini gerektirir. Desteklenebilirlik mühendisleri için bu bilgi, maliyetten bağımsız olarak, neleri desteklemek zorunda oldukları ve neler için ödünleşim yapabileceklerini anlamak açısından kritik öneme sahiptir.

==== <big>5.1.2.1. GENEL KULLANIM SENARYOSU</big> ====

==== Genel kullanım senaryosunda, ürünün kullanımını, ürünün kullanımından doğan çevresel etkileri tanımlayan bütün bilgiler derlenmelidir. Söz konusu bilgilere ilişkin örnekler aşağıda sıralanmıştır: ====
* Bütün kullanım ve/veya görev alanlarının genel tanıtımı,
* Muhtemel operasyonel senaryolar ve her bir senaryo için gereksinimler,
* Ürünün kullanımından kaynaklanan olumsuz çevresel etkiler ve bu etkilerden kaçınabilmek veya onları azaltabilmek için yapılması gerekenler,
* Halen kullanımda olan ürünler için, kullanım dönemi boyunca ortaya çıkan desteklenebilirlik ilişkili problemler,
* Yeni ürünün mevcut ürünlerle etkileşimi ve birlikte kullanılabilirliği,
* Hareket kabiliyeti gereksinimleri,

==== <big>5.1.2.2. PLANLANAN MEVKİLERİN COĞRAFİ KONUMLARI VE ÖZEL KOŞULLARI</big> ====
Ürünün kullanılacağı alanlar ve bu alanlara ilişkin varsa özel koşulları tanımlayan detaylar derlenmelidir. Bu konudaki bilgilere yönelik örnekler aşağıda sıralanmıştır:

* Operasyon alanlarının sayısı ve coğrafi yerleşimi,
* Her bir operasyon mahallinin coğrafi yapısı ve iklim koşulları,
* Her bir operasyon mahallinin tipi,
* Her bir operasyon mahalline özel koşullar (varsa),
* Söz konusu alanın, barış veya savaş durumu bölgesi olup olmadığı (Tehdit durumları, asgari düzeyde müdahale ile sınırlı olan özel acil durum bakım konseptlerinin geliştirilmesini gerektirir),
* Her bir operasyon alanına erişmek için yeterli altyapı mevcut mu?
* Her bir alan için özel bir altyapı gereksinimi var mı?
* Her bir alan için mevcut ve planlanan kabiliyetler neler (Örn. ekipman, altyapı, personel, tesis, ikmal deposu, onarım atölyesi, vb.),
* Farklı alanlar arasında etkileşimler (örneğin, bir alandan diğer bir alana bakım desteği verilmesi).

==== <big>5.1.2.3. KONUŞLANMA VE ÜRÜN DESTEĞİ</big> ====
Ürünün konuşlanmasına ve konuşlanmadan kaynaklanan etkileşimlere dair detaylar derlenmelidir. Ürünün konuşlandırılacağı yer, organik veya yüklenici desteğine ilişkin kararları etkileyecektir. Bu konuda:

* Her bölgede desteklenecek sistem sayısı,
* Her bölgede konuşlandırılacak ürünler ve
* Farklı alanlar arasında kullanımdan kaynaklanan etkileşimler gibi bilgilerin toplanması gerekir.

==== <big>5.1.2.4. KULLANIMA GENEL BAKIŞ</big> ====
Ürünün planlanan kullanım bilgisi lojistik analizlere temel girdi olarak tanımlanmalıdır. Kullanımın sıklığı ve süresi, ürün güvenilirliği ile birlikte ihtiyaç duyulacak destek kaynaklarının kapsamını ve miktarını belirlemekte başlangıç noktasını oluşturur. İlişkili bilgilere örnekler aşağıda sıralanmıştır:

* Her bir lokasyon için temel kullanım/görev bilgileri
* Performans parametreleri ve kısıtlar (Menzil, doğruluk oranı, faydalı yük, hız vb. parametreler ölçülebilir terimlerle tanımlanmalıdır. Genel terimler veya yoruma açık belirsiz ifadelerden kaçınılmalıdır).
* Öngörülen kullanıma hazır olma ve kullanım başarı oranları
* Birim zamanda operasyon
* Kullanım günü, haftası, ayı veya yılına özgü kullanım/görev profili
* Ürünün işletim zamanı içerisinde eğitim amaçlı kullanılma oranı
* Daimi kullanım şartları/Olası bakım aralıkları
* Her bir kullanım etkinliğinin ortalama süresi
* Birim zamanda kullanıma yönelik temel ölçüm bazı

=== 5.1.3. MÜŞTERİ GEREKSİNİMLERİ ===
Ürünün uygun şekilde kullanımının sağlanması için müşteri bütün lojistik ilişkili isterlerini de yükleniciye iletmelidir. Müşteri isterlerinin kapsamı ve içeriğinde yer alabilecek bilgiler aşağıda tanımlanmıştır.

==== <big>5.1.3.1. İKMAL KONSEPTİ</big> ====
İkmal konsepti desteklenebilirlik mühendisleri açısından kritik önem arzetmektedir. Yedek parça ve sarf malzeme tedariğinin nasıl organize edileceğine dair genel karar, bakım senaryoları üzerinde önemli etki gösterebilmektedir. Lojistikçi, depolama alanlarına yönelik planlama ihtiyacı olup olmadığı ve tedarik zinciri yönetiminin dış kaynaktan temini durumunda kim tarafından yönetileceğine karar vermelidir. Özellikle tesis inşaatına dair maliyetler ve teknolojik eskime dikkate alınması gereken önemli hususlardır.

==== <big>5.1.3.2. DESTEK EKİPMANI KONSEPTİ</big> ====
Maliyet açısından etkin olması durumunda özel destek ekipmanları yerine yaygın destek ekipmanları tedarik edilmelidir. Maliyetleri düşürmek için, mevcut destek ekipmanlarının kullanılıp kullanılamayacağı veya yeni sisteme adapte edilip edilemeyeceğinin değerlendirilmesi önemlidir.

==== <big>5.1.3.3. PERSONEL ENTEGRASYONU VE EĞİTİM</big> ====
İşgücü konusu birçok sistemin desteklenebilirliği için önem taşır. Destek personelinin uygun zamanda eğitim alabilmesi için planlama yapılmalıdır.

Eğitim ihtiyaçlarının iki bileşeni vardır: Başlangıç ve süreklilik eğitimleri. Her ikisi de yeterli personel becerisinin sağlanması açısından önemlidir. Personel devir oranlarının yüksek olması, belirli bir beceri setinin idamesini zorlaştıran bir etkendir. Desteğin planlanması aşamasında bu hususlar da dikkate alınmalıdır.

==== <big>5.1.3.4. TESİSLER</big> ====
Tesislere ilişkin uzun saha temin ve tahsis süreleri, tesis ihtiyaçlarının erken dönemde planlanmasını zorunlu kılar. Bakım faaliyetlerinde kullanılacak tesisler bakım sürecindeki tüm faaliyetleri ve iş akışlarını destekleyecek şekilde planlanmalıdır.

==== <big>5.1.3.5. BİLİŞİM VE HABERLEŞME KAYNAKLARI</big> ====
Bilişim ve haberleşme kaynak ihtiyaçları desteklenebilirlik mühendislerinin erken dönemde hazırlık yapmalarını gerektiren bir başka alandır. Bu konuda dikkate alınması gereken hususlar aşağıda sıralanmıştır:

* Diğer hizmetlerle ara yüzü sağlamak için ne gibi kısıtlar vardır/gereklidir?
* Örneğin X altyapısı operasyonel kullanılabilirlik açısından arzu edilir bir iyileştirme sunarken, başka bir hizmet tarafından kullanılan Y haberleşme ağına erişime engel oluyorsa nasıl bir ödünleşim yapılmalıdır?
* Nasıl bir bilgi teknolojisi altyapısına ihtiyaç duyulmaktadır?

Bilgi teknolojisi kaynaklarının bilgisayar donanımı, ağ bileşenleri, ağ kablolamaları haberleşme protokolleri, yazılım paketleri, veri güvenliği ve standartlar gibi birçok yönü vardır. Bu konu aynı zamanda gelecekte öngörülen kabiliyetlerin de anlaşılmasını gerektirir. “Sahaya verildiği zaman kullanımda olacağı tahmin edilen sistemler”le ara yüzü olacak şekilde bir sistem tasarlamak tasarım ve desteklenebilirlik mühendislerinin diğer ilgili projelerin durumundan haberdar olmalarını gerektirir. Sistemin planlanan gelecekteki haberleşme mimarisi ile nasıl bir ara yüz kuracağı ele alınmalıdır. Lojistikçi, muhtemel bilgi teknolojisi sistem değişikliklerinin etkisini değerlendirmeli ve lojistik yapıda gerekli düzenlemeleri belirlemelidir.

=== 5.1.4. SAHA İNCELEMELERİ ===
Saha incelemeleri, tasarlanacak olan ürünle ilişkili yürütülecek olan LDA faaliyetlerinin planlanmasında çok büyük bir öneme sahiptir. Yürütülen inceleme faaliyetlerinde ihtiyaç makamı/kullanıcı/idame makamı’nın bünyesinde bulunan eğitim ve kurs yerlerinin, bakım fabrikalarının ve bakım birliklerinin imkânları ve kullanıcı ve bakım personelinin bilgi ve tecrübesi tespit edilir. Bu sayede tasarımı yapılacak olan sistemin kullanım ve destek süreçleri geliştirilirken, mevcut tesis imkimkânanları ve personel becerileri göz önünde bulundurulur. Envanterde bulunan benzer sistemler detaylı olarak incelenir, bu sistemler ile ilgili bakım personellerin ve sistemi kullanan operatörlerin yaşadıkları sıkıntılar ve zorluklar tespit edilir. Muharebe/operasyon alanında, bakım fabrikalarında, bakım birliklerinde yedek parça ve sarf malzemesi tedariğinde yaşanan problemler, bakım yöntemlerinin uygulanmasında yaşanan sorunlar, yedek ve sarf malzemelerinin paketlenmesinde, depolanmasında, elleçlenmesinde ve taşınmasında yaşanan sorunlar tespit edilir. Bu kapsamda saha incelemelerinde, proje kapsamına göre LDA faaliyetleri ile ilişkili soru setleri oluşturularak, incelenmekte olan sistemin/sistemlerin geneli ve mümkünse alt sistem ve parça seviyesinde detaylı bilgiler toplanır.

Saha incelemelerinde kullanılabilecek örnek bir soru seti Tablo 4’de verilmiş olup proje veya konuya özgü sorular da bu tabloya eklenebilir.

'''Tablo 4 Örnek Soru Seti'''
{| class="wikitable"
| colspan="2" |'''Örnek Soru Seti'''
|-
|'''Sıra No'''
|'''PEDU'''
|-
|001
|Kaç tip ambar mevcut? Ambarların/Depoların ortam koşulları nedir? (Nem, sıcaklık, aydınlatma, havalandırma, vb.)
|-
|002
|Kullanılan bir paketleme standardı var mı?
|-
|003
|Paketleme malzemesi olarak ne kullanılıyor?
|-
|004
|Kullanılan paketler tekrar paketlemede kullanılabilir özellikte mi?
|-
|005
|Paket dolgu malzemesi kullanılıyor mu? Ne tip bir dolgu malzemesi kullanılıyor?
|-
|006
|Tampon malzeme kullanılıyor mu? Kullanılıyorsa kalınlığı nedir?
|-
|007
|Uygun kaldırma noktası mevcut mu? Eğer uygun kaldırma noktası yoksa bu durum taşıma/kaldırma vb. işlemler sırasında zorluk çıkartıyor mu?
|-
|008
|Kaldırma, depodan araca yükleme, araçtan depoya aktarma, vb. işlemler sırasında kullanılan ekipman nedir? (vinç, cayraskal, forklift, vb.)
|-
|009
|Etikette yer alan bilgiler nelerdir? Herhangi bir etiketleme standardı kullanılıyor mu?

(sandık numarası, alt sistem/cihaz/malzeme adı, ambalaj sıra no, netve brüt ağırlık ve hacimleri, NSN ve/veya Parça no, miktar, son kullanma tarihi, v.b)
|-
|010
|Kutusundan/Paketinden çıkartırken ve kullanıma hazırlarken uygulanan özel bir işlem var mı? Herhangi bir askeri standart kullanılıyor mu?
|-
|011
|Araçtan sökülen ve farklı bir bakım seviyesine nakli yapılacak sistem bileşeni paketleniyor mu? Herhangi bir askeri standart kullanılıyor mu?
|-
|012
|Araçtan sökülen ve uzun süre depoda tutulacak olan sistem bileşeni paketleniyor mu? Herhangi bir askeri standart kullanılıyor mu?
|-
|'''Sıra No'''
|'''BGA'''
|-
|013
|Bakımlar, bakım dokümanı dışında başka hiçbir dokümana ihtiyaç duyulmadan gerçekleştirilebiliyor mu?
|-
|014
|Bakım sarf ve yedeklerinin tedariğinde zorluk yaşanıyor mu? Alternatifleri var mı?
|-
|015
|Bakım sarf ve yedeklerinin tedariği gecikiyor mu? Maliyet bilgileri mevcut mu?
|-
|016
|Depoda/Ambarda muhafaza edilen malzemeye uygulanan bir bakım mevcut mu?
|-
|017
|Bakım sistem çalışır vaziyetteyken yapılabiliyor mu?
|-
|018
|Cihaz sistem üzerinde montajlıyken ilgili parça sökülebiliyor mu?
|-
|019
|Cihaz sistem üzerinde montajlıyken ilgili parçanın bakımı yapılabiliyor mu?
|-
|020
|Bakımı yapan personelin ihtisası (elektrik, motor, vb.) ne olmalı?
|-
|021
|Ne tip bir temizlik malzemesi ile temizleniyor?
|-
|022
|Temizlik malzemesinin insan sağlığına ne gibi etkileri var?
|-
|023
|Bakım işlemlerinde boyanın temizlenmesine ve tekrar boyanmasına ihtiyaç var mı?
|-
|024
|Özel tezgâh ihtiyacı var mı?
|-
|025
|Özel alet/avadanlık gerekiyor mu? Gerekiyorsa kaç adet, bunlar neler?
|-
|026
|Kullanılan alet/avadanlıklar metrik birim sisteminde mi?
|-
|027
|Bakım dokümanlarında hangi birim sistemi kullanılıyor? Kullanılan birim sistemi zorluk yaratıyor mu?
|-
|028
|Periyotları çakışan bakımlar olduğunda yapılacak bakımlarda sökülmesi gereken parçalar birbirleri ile ardışık veya ilişkili mi?
|-
|029
|Periyotları çakışmayan bakımlar arasında ardışık/ilişkili parçaların sökülmesi gereken bakımlar var mı?
|-
|030
|Bakımlar karmaşık adımlardan mı oluşuyor?
|-
|031
|Periyodik bakım tanımlı olduğu halde uygulanmazsa araç veya sistem bundan nasıl etkileniyor?
|-
|032
|Periyodik parça değişimli bakımlarda, periyodu gelmeden arızalanan/değiştirilmesi gereken parçalar oluyor mu?
|-
|033
|Bakımda kullanılan veya değiştirilen parçalar için özel imha metodu var mı?
|-
|'''Sıra No'''
|'''HTEKA'''
|-
|034
|Hasarlı parça ıskartaya mı ayrılıyor yoksa laboratuvar incelemesi yapılmak üzere üreticiye/ilgili bakım kademesine gönderiliyor mu?
|-
|035
|Diyagnostik imkânı var mı?
|-
|036
|Çalışma değerleri herhangi bir ölçüm cihazı ile izlenebiliyor mu?
|-
|037
|Çalışma değerlerinin herhangi bir ölçüm cihazı ile izlenemiyor olması arıza tespitinde zorluk yaratıyor mu?
|-
|038
|Arızalandığı zaman sistemi durdurmak gerekiyor mu yoksa sistem çalışmaya devam edebilir mi?
|-
|039
|Arızalandığı zaman sisteme veya diğer alt sistemlere/bileşenlere de zarar veriyor mu?
|-
|040
|Meydana gelen arızalar/hatalar arasında mevcut bakımlar ile giderilemeyen oluyor mu?
|-
|041
|Arıza kayıtları var mı? Seri kontrollü olarak tutuluyor mu?
|-
|'''Sıra No'''
|'''OSA'''
|-
|042
|İlgili sistem bileşeninin bakımları hangi kademede yapılıyor?
|-
|043
|Aynı anda kaç sistemin bakımı yapılabiliyor?
|-
|044
|Eğer limit aşımı olursa bakımı yapılacak araç farklı birliğe mi yönlendiriliyor, bir üst kademeye mi yönlendiriliyor yoksa sırada mı bekliyor?
|-
|045
|Bakımı yapılacak araç/sistem ne tip bir taşıtla getiriliyor?
|-
|046
|Ulaştırma maliyetleri nedir? (Taşıt cinsi + km)
|-
|047
|Bakımı yapılacak aracın/sistemin birliğe taşınması ne kadar sürüyor?
|-
|048
|Bir üst kademede bakımı yapılacak aracın/sistemin ilgili kademeye ulaşması ne kadar sürüyor?
|-
|049
|Bakımı bir üst kademede yapılacak sistem bileşeninin hata/arıza tespiti hangi kademede yapılıyor?
|-
|050
|Birlik seviyesinde bakımı yapılacak sistem bileşeninin hata/arıza tespiti hangi kademede yapılıyor?
|-
|051
|Taşıma/ulaştırma için hangi yönetmeliklere tabii tutuluyor?
|}

=== 5.1.5. KALİFİKASYON VE SERTİFİKASYON GEREKSİNİMLERİ ===
Müşteri, bir kalifikasyon süreci yürütmek istediğinde, ürünün kalifikasyonu içerisinde bakım faaliyetlerinin ne şekilde ele alınacağı yüklenici ve müşteri tarafından programın erken safhalarında açıklığa kavuşturulmalıdır. Kalifikasyon gereksinimleri müşteri tarafından belirlenmeli ve operasyonel gereksinimler ile aynı zamanda yükleniciye iletilmelidir.

Benzer şekilde ürünün öngörülen çevresel koşullarda işletimi için bir sertifikasyon süreci gerekiyorsa, sertifikasyonun kapsamında yer alacak bakım faaliyetlerinin belirlenmesi ve dokümante edilmesine özellikle dikkat edilmelidir. Bu faaliyetler yerine getirilmesi zorunlu faaliyetlerdir. Sertifikasyonu etkileyen bakım faaliyetleri birinci derece önceliğe sahip olmalıdır.

Kalifikasyon gereksinimleri müşteri tarafından belirlenirken sertifikasyon gereksinimleri bir sertifikasyon otoritesi tarafından belirlenir. Müşteri ve yüklenici, kalifikasyon ve sertifikasyon süreçleri arasındaki farkların ilgili kişiler tarafından bilinmesini sağlamalıdır.

== 5.2. LDA İLİŞKİLİ ÜRÜN TASARIM VE PERFORMANS VERİLERİNİN BELİRLENMESİ ==
Ürün tasarım ve performans verileri LDA’yı doğrudan veya dolaylı olarak etkilemektedir. Sistemin ömür devri boyunca karşılaşacağı çevresel koşullar, kullanım parametreleri ve performans isterleri LDA için önemli girdilerdir. Örnek olarak bir askeri kara aracının %60 eğime tırmanması ile ilgili teknik bir ister LDA’yı etkilemektedir. Aracın bu denli yüksek bir eğim tırmanma kabiliyeti, araç operatörlerinin bu konuda eğitimli ve bilgili olması ile mümkündür. Aynı zamanda ömür devri boyunca bu gibi bir durumla kaç kez karşılaşacağı bilgisi de aracın bakım planlaması için önem arz etmektedir.

LDA ile ilişkili ürün tasarım ve performans verileri belirlenirken yalnızca sistemin ömür devri boyunca karşılaşacağı çevresel koşullar, kullanım parametreleri ve performans isterlerinden değil, aynı zamanda bu isterleri gerçekleştirecek fiziksel ekipmanlardan ve bu ekipmanların üreticilerinin üretmiş olduğu teknik dokümanlardan da faydalanılır.

Örnek olarak askeri bir kara aracında teknik isterleri sağlaması için seçilmiş bir motorun yağlama ve bakım periyotları LDA için büyük önem arz eder. Diğer bir örnek ise motorun arızalar arası ortalama süresi, yani güvenilirlik karakteristikleridir. Yedek parçaların neler olduğunun belirlenmesi ve ne zaman nerede bulunması gerektiği bilgisi LDA sonuçları ile ortaya konacaktır.

Sistem gereksinim tanımlama aşamasında ve/veya ön tasarım aşamasında yürütülen ürün tasarım ve performans verilerinin belirlenmesi faaliyetleri esnasında dikkate alınabilecek hususlar aşağıdaki başlıklarda detaylı bir şekilde yer almaktadır:

* LDA ile ilgili veri ve bilgilerin seçim kriterleri
* LDA veri seçiminde genel LDA yaklaşımlarının ve ilkelerinin etkisi
* Seçim değerlerinin doğrulanması ile ilgili kabul kuralları
* Öngörülen değerlerin doğrulanması için kriterler ve prosedürler
* İhtiyaç makamı/kullanıcı/tedarik makamı/idame makamının katılımı

=== 5.2.1. LDA İLE İLGİLİ VERİ VE BİLGİLERİN SEÇİM KRİTERLERİ ===
LDA ile ilişkili olarak dikkate alınması gereken veri ve bilgiler, LDA süreci kapsamında doğrulama ve kontrollere tabi olan veri ve bilgilerdir. Seçim kriterleri; LDA uygulanacak ürüne, ilgili sözleşmeye, şartnameye ve belirlenmiş ELD yaklaşımına bağlı olarak ayrıntılı bir şekilde belirlenmelidir. İlgili bilgiler, oluşturulan LDA süreci kapsamında doğrulanacak bir hedef belirlemek üzere LDA veri tabanı içerisinde gereksinim olarak dokümante edilebilirler. Genel bir yaklaşım olarak, aşağıdaki paragraflarda tanımlanan seçim kriterleri göz önünde bulundurulmalıdır:

==== <big>5.2.1.1. Sözleşme Dokümanlarından Türetilen LDA Bilgi ve Verilerinin Seçimi</big> ====
LDA veri tabanında dokümante edilmiş bilgilerle doğrulanabilecek LDA ilişkili ürün tasarım ve performans özellikleri için, sözleşme dokümanlarının dikkatle değerlendirilmesi gerekmektedir. Genellikle ürün gereksinimleri ya da Anahtar Performans Göstergeleri olarak adlandırılan önemli noktalar, potansiyel olarak sözleşme teşvikleriyle ilgili zorunlu hedefler ve/veya eşikler oluşturmak için bu dokümanlarda ele alınmaktadır.

Anahtar Performans Göstergeleri örnekleri:

* Çalışma saati başına belirtilen Maksimum Bakım Saati.

''Bu değer başarılı bakım tasarımı ile ilgili bir referans noktası olarak kullanılabilir.''

* Onarım için belirtilen Maksimum Ortalama Süre ve Onarım için belirtilen Maksimum Ortalama Süre Yüzdesi.

''Bu değerler belirlenen zaman kısıtlamaları içinde onarımla ilişkili olduğu için başarılı bir tasarım göstergesi olarak kullanılabilir.''

* Çalışma saati başına belirtilen Maksimum Hata Sayısı.

''Bu değer ürünün istenen güvenilirliğin ve ters orantılı olarak bakım iş yükünün bir göstergesidir.''

* Minimum Kullanılabilirlik ile ilgili belirlenmiş rakamlar.

''Bu değerler kullanıma hazır olma konusunda başarılı bir tasarım göstergesi olarak kullanılabilir.''

* Test edilebilirlik özellikleri.

''Bu değerler hayati fonksiyonların izlenmesine ve Cihaz İçi Test Ekipmanı (CITE) ve genel test mimarisi gibi yollarla potansiyel arızaların tespit ve lokalizasyonuna yönelik tasarımın kabiliyetini göstermektedir.''

* Minimum Kullanım Ömrü

''Bu değer minimum kullanım ömrü gereksinimini gösterir. Bu değer belirlenen eşiğin altına düşme riskini göstermelidir.''

==== <big>5.2.1.2. Ürün Kullanım Verilerinden Türetilen LDA Bilgi ve Verilerinin Seçimi</big> ====
İlgili bilgiler LDA veri tabanında temel referans olarak dokümante edilir.

Örnekler:

* Ölçüm Tabanı ile Yıllık Kullanım Gereksinimleri,
* İşletme yeri/tesis sayısı,
* Her tesiste işletilecek sistem sayısı,
* Her tesiste kurulacak bakım seviyeleri,
* Her tesiste mevcut bakım personeli (branş ve beceriye göre kişi sayısı)

==== <big>5.2.1.3. Ürün Şartnamelerinden Gelen LDA Bilgi ve Verilerinin Seçimi</big> ====
Ürünün tasarımını ve performansını etkileyen LDA ile ilgili parametreler doğrulama ve/veya kontrol amaçlı LDA veri tabanında belgelenir.

Örnekler:

* Minimum değer gösteren ilgili ölçüm tabanı ile birlikte MTBF,
* Güvenilirlik artışı,
* Cihaz İçi Test Ekipmanı ile belirlenmiş test özellikleri,
* Ortalama Onarım Süresi,
* Diğer Ürün Belgelerinde Yer Alan Ürün Sertifikasyonu ve Doğrulaması ile ilgili LDA Veri ve Bilgilerinin Seçilmesi.

LDA ile ilgili bilgiler tasarım bölümleri, emniyet veya müşteri dokümanlarından da elde edilebilir.

Örnekler:

* Özel kullanım ve/veya onarım sınırlamaları (Örneğin; sıcaklık aralıkları, anti-statik koruma gereksinimleri, temiz hava onarım koşulları),
* Geçerlilik bilgisi (Örneğin; sürüm uygulanabilirliği),
* Tehlikeli arızaların sınıflandırılması,
* Depolama sınırlamaları ve/veya gereksinimleri,
* Belirli parçaların kritiklik sınıflandırması,
* Zamanlanmış gereksinimler (Örneğin; belirlenen zaman sınırları, büyük bakım (overhaul) gereksinimleri).

=== 5.2.2. LDA VERİ SEÇİMİNDE GENEL LDA YAKLAŞIMLARININ VE İLKELERİNİN ETKİSİ ===
İlgili ürün tasarımı ve performans verilerinin belirlenmesinden önce, LDA programının uyarlanmasının bir parçası olarak genel bir LDA yaklaşımı oluşturulmalıdır. Uyarlama süreçleri projenin karmaşıklığına, iş birimlerine (yükleniciye) ve bilinen risk faktörlerine bağlıdır. Bu kısıtlamalar ve performans gereksinimleri, gerekli analiz çabaları, zaman, program ve tahsis edilen bütçe arasında, proje için en uygun maliyet/fayda ile dengelenir. Sonrasında bu gereksinimler, konular ve kısıtlamalar gözden geçirilir ve tüm paydaşlar arasında bir fikir birliği sağlamak için LDA İş Tanımlama Toplantısı’nda değerlendirilir. Bu bulgular, analizler ve sonuç anlaşmaları LDA İş Tanımı ile belgelendirilir.

Bu uyarlama aktivitesi yinelemeli bir süreçtir ve programın her aşamasında tekrarlanmalıdır. Her bir önceki aşamadan elde edilen sonuçlar ve öğrenilen dersler, aşağıdaki aşamaların her biri için uyarlama analizinin bir parçası olmalıdır.

Genel LDA yaklaşımları ve ilkeleri, LDA süreci ile ilgili olarak ürün tasarımı ve performans verilerinin seçimini etkileyebilir. Bu alanda sürdürülebilirlik için dikkate alınması gereken örnekler aşağıdaki gibidir:

* Üç seviyeli bakım konsepti

Bakım faaliyetleri kullanıcı, birlik ve fabrika/firma seviyesi olarak ayrılmıştır. Kullanıcı seviyesinde operatör/kullanıcı/sürücü/mürettebat tarafından yapılabilecek bakımlar icra edilir. Birlik seviyesinde arızalı Hatta Değiştirilebilir Birimler (HDB), faal HDB'ler ile değiştirilirken; fabrika/firma seviyesinde arızalı HDB'lerin onarımları yapılır. Fabrika/firma seviyesi bakım faaliyetleri üretici firmalar tarafından yapılabileceği gibi organik bakım tesislerinde gerçekleştirilebilir.

* Önceden belirlenmiş iki seviye bakım konsepti

Bakım esasen ''arızalı parçanın değiştirilmesi'' ya da ''arızalı parçanın onarımı'' olmak üzere iki bakım seviyesiyle sınırlıdır. İki seviyeli bakım konseptleri işletme sahasında çıkarılacak ve değiştirilecek ekipmanın (HDB) düşük bir arıza oranı ve yüksek bir test edilebilirlik oranına sahip olduğu takdirde genel maliyet hususları sebebiyle tercih edilir.

Bu konsept ile LDA verileri önceden belirlenmiş Bakım Seviyeleri (BS) ile sınırlandırılır.

* Belirli bir bakım seviyesi üzerinde yoğunlaştırılmış Onarım

Onarım, maliyet etkinliğinden bağımsız olarak maksimum özerklik elde etmek için organik bakım tesisleri ile sınırlıdır.

Bu konsept ile, onarım opsiyonu verileri önceden belirlenmiş BS ile sınırlandırılır.

* BS 1 ve/veya 2'de Sınırlı Onarım

Herhangi bir operasyonel aksama süresini kısaltmak için düzeltici bakım eylemi bir yedek parça değişimi (yerinde olmayan onarım -) ile sınırlandırılabilir.

Bu konsept ile bakım görevi önceden belirlenmiş kriterler ile sınırlandırılır.

* Tek kaynak prensibi

Büyük onarım gerektiğinde, sistem/alt sistem/bileşen tedarikçisi ilgili deneyime, personele ve ekipmana en çok sahip ve en hızlı hazır olan şeklinde tercih edilmelidir.

Bu konseptte onarım verileri tedarikçi bilgileri ile sınırlandırılır.

* Ara destek kavramı

Bakım Konsepti (BK) kararlarından önce deneyim kazanmak ve riskleri azaltmak için ara destek aşaması oluşturulabilir.

Bu konseptte BK verileri ön bilgi ile sınırlandırılır.

* Rafta Hazır Ticari Ürün (RAHAT) kavramı

Piyasada mevcut ekipman kullanıldığında ilgili koşullar kabul edilmelidir.

Bu konsept ile veriler ilgili tedarikçi bilgilerini/koşullarını yansıtmalıdır.

=== 5.2.3. DOĞRULAMA DEĞERLERİNE İLİŞKİN KABUL KURALLARI ===
Doğrulama süreci esnasında belirsizliklerden kaçınmak için açıkça tanımlanmış kabul kuralları oluşturulmalıdır. Bu kurallar, LDA ilişkili ürün tasarım ve performans verilerine dair sonuçların hassas bir şekilde kabul veya reddedilmesine imkân sağlayacaktır.

==== <big>5.2.3.1. Ölçüm Değerleri Kategorisi</big> ====
İlgili ölçüm değerinin önemini ifade eden gereksinim türleri tanımlanmalıdır. Bu türler:

* Zorunlu değerler,
* Hedefler,
* Eşikler (minimum veya maksimum değerler).

==== <big>5.2.3.2. Toleransların Belirlenmesi</big> ====
Tanımlanan her bir ölçüm değeri için ilgili toleranslar ifade edilmelidir.

* Tek bir değer için atanmış,
* Benzer değerlerden oluşan bir grup ile ilgili toleranslar, örneğin; tek bir kalem yerine grubun başarısızlık oranını karşılamak için analiz edilen kalemlerin belirli bir alanı içindeki hata oranlarının telafi edilmesi (Örneğin; ek kısıtlamaların izlenmesi).

==== <big>5.2.3.3. Kabul Kriterlerinin Oluşturulması</big> ====
İlgili gereksinim ile birlikte her bir değer için ölçülebilir kabul kuralları oluşturulmalıdır. Bu kurallar, LDA veri tabanında belgelenen değerlerin kabul edilmesine veya reddine yol açan temel koşulları (Örneğin, yeterli istatistik güven düzeylerine dayalı olarak minimum gerekli değerlerin yerine getirilmesi) tanımlamalıdır.

Ayrıca, oluşturulmuş durum bilgilerinin sonuçları açıkça belirtilmelidir:

* Belgelenen değerin kabul edildiğini gösteren Analiz Altındaki Kalem’in (AAK) durumu,
* AAK'nin belgelenmiş değerin ilgili gerekçeyle reddedildiğini gösteren durumu,
* Belgelenen şeklin şartlı kabul edildiğini belirten AAK'nin durumu (Örneğin; genel olarak kabul edilebilir ancak yeniden çalışma gerektiren).

==== <big>5.2.3.4. Özel Kuralların Oluşturulması</big> ====
Özel kurallar belirlendiğinde, belirsizlikten kaçınmak için ilgili koşullar ve ilgili değerler net olarak tanımlanmalıdır:

* Başarısız olarak belirtilen LDA verilerine ilişkin ceza düzenlemelerinin oluşturulması
* Belirtilen LDA değerini aşması durumunda ödüllerin oluşturulması

=== 5.2.4. ÖNGÖRÜLEN DEĞERLERİN DOĞRULANMASI İÇİN KRİTERLER VE PROSEDÜRLER ===
Son olarak, doğrulamaya tabi olan verilerin ve/veya diğer bilgilerin doğrulanması için kriterler oluşturulmalıdır.

==== <big>5.2.4.1. Ölçülebilir Hedef Değerlerin Belirlenmesi</big> ====
Göz önüne alınan veri unsurları için ilgili öngörülen değer aralığı LDA veri tabanı içerisinde, orijinal toleransları ve varsa ilgili kabul kuralları ile birlikte orijinal hedefi dikkate alarak bir gereklilik olarak kurulmalı ve belgelendirilmelidir.

==== <big>5.2.4.2. Öngörülen Değerlerin Doğrulanması</big> ====
Analiz sürecinden elde edilen LDA veri tabanında belgelenen ilgili veriler ve diğer bilgiler, ilişkili kabul edilebilir değerlerle karşılaştırılmalıdır. Sonuç, gerçekleşen LDA değerlerinin öngörülen değerler ile tutarlı olup olmadığını belirten analiste ve/veya ilgili yönetime rapor edilmelidir.

==== <big>5.2.4.3. Doğrulama Yöntemi</big> ====
Öngörülen değerler ve doğrulama yöntemleri üzerinde anlaşmaya varılmalıdır:

* Analitik kanıt sunarak doğrulama (LDA veri tabanında belgelenmiş),
* Uygun testlere dayanan bir analitik yöntem kullanarak doğrulama (Örneğin; bir test teçhizatında),
* Ürünün prototipinde veya seri versiyonlarında gösterim ile doğrulama,
* Sertifika ve/veya gösterim programları kurallarına göre doğrulama,
* Deneme oturumları ile doğrulama (Örneğin; Kullanıcı/Tedarik Makam personeli tarafından gerçekleştirilen),
* Uzun süreli denemeler sırasında doğrulama (Örneğin; belirli bir “olgunluk aşaması” sırasında).

==== <big>5.2.4.4. Özel Amaçlar için Doğrulama</big> ====
Sertifikalar, nitelikler veya lisanslar elde etmek için özel amaçlar için doğrulama gerektiğinde belirli kurallar oluşturulabilir.

==== <big>5.2.4.5. Durum Kodlarının Güncellenmesi</big> ====
Doğrulama sonuçlarına bağlı olarak ilgili durum bilgisi durum tahsisi için belirlenen kuralları izleyerek doğrulama sonucuna bağlanmalıdır.

=== 5.2.5. KULLANICI/TEDARİK MAKAMI KATILIMI ===
LDA süreci kapsamında doğrulama ve kontrole tabi ürün tasarım ve performans verilerinin seçimi müşteri tarafından LDA GGT sırasında kabul edilmeli ve KKB'de belgelenmelidir. Bu aynı zamanda ilgili kuralların ve öngörülen değerlerin anlaşılması için de geçerlidir.

== 5.3. LDA İŞ TANIMLAMA TOPLANTISI ==
LDA uygulanacak aday kalemlerin seçimi, bahse konu aday listesine uygulanacak yöntemler ile ilgili LDA İş Tanımının yapılması, LDA aktivitelerinin belirlenmesi ve planlaması için tüm paydaşların katılımı ile LDA İş Tanımlama Toplantısı gerçekleştirilir. Bu toplantıda alınan kararlar neticesinde LDA adayları seçim kriterleri nihai hale getirilir ve LDA İş Tanımı ve LDA planı onaylanır. Böylelikle ilgili projede LDA uygulanırken izlenecek yöntemler, ara çıktılar, safha sonlarında yer alan çıktılar tümüyle belirlenmiş olur.

Bu kapsamda yer alan öneriler ile verimli bir LDA iş süreci işletilebilmesi hedeflenmektedir.
[[Dosya:LDA İş Süreci v.jpg|alt=|sol|küçükresim|687x687pik]]

=== 5.3.1. LDA İŞ TANIMLAMA TOPLANTISI HAZIRLIK FAALIYETLERI ===
Toplantı esnasında en iyi performansı sağlayabilmek için toplantı girdilerinin hazır olması, sonuç ve nihai mutabakata dair net beklentilerin tanımlı olması ve taslak LDA iş tanımı kapsamında hazırlanmış kontrol listelerinin kullanılması ile izlenecek adımların takibi ve üzerinde gerçekleştirilecek çalışmaların yönetilmesi kapsamında faydalıdır.

LDA İş Tanımlama Toplantısı için girdi olabilecek dokümanlar aşağıdaki şekildedir:

* Sözleşme ve Ekleri,
* Genel kullanım hususları,
* Operasyonel gereksinimler,
* Taslak LDA adayları listesi,
* Taslak veri elemanları listesi,
* Taslak LDA İş Tanımı,
* Taslak LDAP.

Diğer taraftan, erken stratejik değerlendirmelere bağlı olarak zorunlu ve önerilen LDA aktivitelerinin belirlenmesi gibi hususların önceden düşünülmüş olması yararlı olacaktır.

Bu kapsamda aşağıdaki hususlar dikkate alınarak çalışmalar yürütülür;

* '''Aday Kalem ve Aday Olmayan Kalem:'''

LDA adayı tüm LDA aktivitelerinin ana yönlendiricisidir. Potansiyel bir LDA adayı, genel olarak onarım yapılabilen veya planlı/plansız bakım görevi bulunan bir sistem, alt sistem, ekipman, modül veya alt modül seviyesindeki bir kalemdir. Analiz edilecek kalemin konfigürasyon listesinde olup olmaması, yukarıdaki kriterlere ek olarak proje özelindeki kriterlere de bağlı olarak değişebilmektedir.

Donanımla ilgili tanımlamaya ek olarak, özel aktiviteler ürün kırılımının uygulanabilir olması durumunda özel bir bölümünde tanımlanabilir. Örneğin, yapısal bileşenlerin onarımı için standart uygulamaların tarifi, ürün kırılımının özel bir bölümünde belirtilebilmektedir. Bu durumda, donanım dışı bazı arıza unsurları da kendilerine özel aktiviteler veya bakım görevleri tanımlandığı için LDA adayı olabilmektedir.

Aday olmayan malzemeler için ayrıntılı bir lojistik analiz gerekli değildir. Bu tip malzemeler fiziksel ürün kırılımda görünmek zorunda değildir. Özel bir lojistik kaynağın gerekmediği, standart görevlere tabi olan malzemeler de potansiyel aday olmayan malzemedir. Aday olmayan malzemeler için tipik örneklere sarf malzemeleri, vidalar, cıvatalar, somunlar, rondelalar verilebilir. Bununla birlikte, bir malzeme LDA adayı seçim sürecinde aday olarak belirlenmemişse bile Aday Kalem Listesinde aday olarak seçilmeme sebepleriyle birlikte dokümante edilmelidir.

* '''Bakım İlgili Malzeme (BİM) ve Bakım Önemli Malzeme (BÖM):'''

LDA adaylarının belirlenmesi sürecinde bakım/onarım gerektiren malzemeler dikkate alınmalıdır. Bakım görevleri, planlı bakım görevleri ve plansız bakım görevleri olmak üzere iki kategoriye ayrılmaktadır. Bu aşamada aşağıda tanımları verilen iki kavram ortaya çıkmaktadır.

Bakım İlgili Malzeme (BİM): Bir arıza veya hasar durumunda onarılan veya değiştirilebilen malzemelerdir. Bu malzemeler potansiyel LDA adayıdır. Fakat bu malzemeler doğrudan Bakım Önemli Malzeme (BÖM) değildir.

Bakım Önemli Malzeme (BÖM): Önleyici bakım analizleri sonucunda planlı bakım görevleri tanımlanan malzemelerdir. Bu bakım görevleri LDA veritabanında dokümante edilmelidir.

* '''Yapısal Malzeme, Yapısal Önemli Malzeme:'''

Ürün Kırılımında yer alan yapısal malzemeler tipik LDA adayıdır. Bu malzemeler ayrıca planlı bakım analizi için de potansiyel adaylardır. Yapısal malzemelere ilişkin tanımlar aşağıda yer almaktadır.

Yapısal Malzeme: Yapısal Malzeme, sistemin üstyapısının bir parçasıdır. Yapısal Önemli Malzeme (Structure Significant Item) olarak LDA adayı olabilmektedir.

Yapısal Önemli Malzeme: Planlı bakım analizi sonucunda belirlenen malzemelerdir.

* '''Donanım Olmayan Malzeme (Non-Hardware Item):'''

Fiziksel Ürün Kırılımlarında sadece ürüne ait donanımlar dokümante edilmektedir. Ancak özel bir donanıma ait olmayan, bir grup malzeme için (kablo, vb.) tanımlanan bakım görevleri olması durumunda bu tip malzemeler Donanım Olmayan Malzeme adı altında Ürün Kırılımlarına eklenebilmektedir. Bu tip malzemeler LDA adayı olabilmektedir.

=== 5.3.2. LDA İŞ TANIMLAMA TOPLANTISI ===
Bu toplantı, ihtiyaç makamı/kullanıcı/idame makamı/tedarik makamı ve yüklenici tarafından yönetim kadrosu ve uzmanların katılımıyla gerçekleştirilir. Bu toplantı ile LDA Aday Kalem Listesi, Veri Eleman Listesi, LDA İş Tanımı ve LDA Planı nihai haline getirilerek karşılıklı mutabakat sağlanarak gözden geçirme toplantıları ile ömür devri boyunca dokümanlara ilişkin gerekli çalışmalar yürütülür.

==== <big>5.3.2.1. LDA Aday Kalem Listesi</big> ====
Yükleniciler tarafından taslak olarak hazırlanan ilk aday listesi; LDA İş Tanımlama Toplantılarında müşteri ve yüklenici tarafından değerlendirilmeli ve ilk sürüm Aday Kalem Listesi (AKL) dokümanı, seçim kriterlerini de içerecek şekilde yayımlanmalıdır. AKL dokümanı ürün ömür devri boyunca yaşayan, üzerinde değişikliklerin yapılabildiği bir dokümandır.

LDA İş Tanımlama Toplantısında ürün için yapılacak analiz çalışmalarının da yer aldığı AKL dokümanı önemli bir adım olarak yer almaktadır.

LDA sürecinin yönetilebilmesi için analizlerin ve dokümantasyonun versiyon kodları ile tanımlanması gerekmektedir. Çalışmaların etkinliğinin arttırılabilmesi ve proje kapsamında raporların rahat alınabilmesi için AKL’nin bir lojistik veri tabanına girilmesi faydalı olacaktır.

AKL’de yapılacak bütün değişiklikler yüklenici ve müşteri ile koordineli olarak yapılmalıdır. Böylece her iki tarafta yer alan LDA / ELD yöneticileri LDA sürecini güncel dokümanlar üzerinden takip edebilecek ve sözleşmesel gereksinimlerin karşılanıp karşılanmadığını kontrol edebilecektir.

==== <big>5.3.2.2. LDA Adaylarının Sınıflandırılması</big> ====
Ürün Kırılımında yer alan her malzeme için her analiz çalışmasının yapılması durumu gerek maliyet gerekse iş gücü açısından değerlendirilmelidir. Bu nedenle LDA Adaylarının sınıflandırılması gerekmektedir. Sınıflandırma yapılırken malzemenin durumu, kullanıcı/tedarik makamı ile görüşmeler ve üretici firmanın değerlendirmeleri önem arz etmektedir. LDA adaylarının sınıflandırılmasına yönelik tanımlar aşağıda yer almaktadır:

Tam Aday: Geniş ölçekli LDA verisinin oluşturulması gereken malzemelerdir.

Kısmi Aday: Kısmi ölçekli LDA verisinin oluşturulması gereken malzemelerdir.

Aday Ailesi: Özel gereksinimlere odaklanarak analiz edilecek malzeme gruplarıdır (standart kablolar, vb.). Bu tip malzemeler için belirli analiz çalışmaları yapılmaktadır.

Standart Prosedür Adayı: Standart onarım prosedürleri olan ve kısmi ölçüde analiz çalışmaları yapılması gereken malzemelerdir.

'''<big>5.3.2.2.1. LDA Adayları Seçim Süreci ve Kriterleri</big>'''

LDA adayı seçimi için, Ürün Kırılımında yer alan her malzemenin LDA’nın amaçları açısından değerlendirilmesi gerekir. Değerlendirme sonucu, bir malzemenin seçim kurallarına göre bir aday olduğunu gösterir ise ilgili malzeme LDA adayı olarak belirtilebilir. LDA Adaylarının seçimi için aşağıdaki kriterler ve akış diyagramlarından faydalanılmaktadır.

'''<big>5.3.2.2.2. LDA Adaylarının Seçilmesi, Tanımlanması ve Sınıflandırılması</big>'''

LDA süreci oldukça maliyetli bir süreçtir. Bu nedenle, LDA adaylarının ve ilgili analiz faaliyetlerinin seçilmesi esnasında, LDA sürecinden elde edilen faydalar ile LDA çalışmaları için harcanacak çaba arasında iyi bir denge kurmaya özen gösterilmelidir. Analiz süreçlerinin türüne ve analizin derinliğine göre LDA adayları farklılık gösterebilmektedir.

LDA adaylarının seçilmesi için lojistik açıdan irdelenmiş uygun bir ürün kırılımına ihtiyaç bulunmaktadır. Lojistik kırılımın oluşturulması, LDA süreci boyunca gerçekleştirilecek tüm analizler için yapılması gereken ilk ve temel faaliyettir. Bu sayede analiz edilecek malzemeler de irdelenmiş olacaktır.
[[Dosya:TSSODYP06.05.jpg|alt=|sol|küçükresim|694x694pik|Şekil 5 LDA Adayı Belirlenmesinde Kullanılabilecek Örnek Akış Diyagramı (Yapısal Olmayan Malzeme için) (S3000L)]]

[[Dosya:Şekil 6 LDA Adayı Belirlenmesinde Kullanılabilecek Örnek Akış Diyagramı (Yapısal Malzeme için).jpg|alt=|sol|küçükresim|624x624pik|Şekil 6 LDA Adayı Belirlenmesinde Kullanılabilecek Örnek Akış Diyagramı (Yapısal Malzeme için)]]

LDA adaylarının seçilmesi yöntemlerine geçilmeden önce aşağıda verilen tanımların iyi anlaşılması gerekmektedir.

'''Ürün Kırılımları:'''

LDA Adaylarının seçilebilmesi için ürün kırılımlarının yeterli derinlikte oluşturulmuş olması gerekmektedir. Bu husus incelenmelidir.

'''Mevcut Analiz Sonuçları:'''

Daha önceden yapılmış olan analiz sonuçları LDA adayları seçiminde kullanılabilmektedir. Mevcut/benzer sistemlere ait deneyimler, güvenilirlik verileri ve Hata Türleri Etkileri ve Kritiklik Analizi (FMECA) verileri bu kapsamında kullanılabilir.

'''Aday Seçim Kriterleri:'''

LDA adayları seçimi yapılırken Kullanıcı/Tedarik Makamı ile Yüklenici arasında mutabakat sağlanmalıdır. LDA İş Tanımlama Toplantılarına taslak LDA Aday Kalem Listesi ile başlanmalıdır. LDA adayları seçilirken göz önünde bulundurulabilecek kriterlere örnekler aşağıda verilmiştir:

* Malzemeye tanımlı planlı/plansız bakım görevi ve tanımlanmış bakım seviyeleri (örneğin, malzemenin hatta değiştirilmesi ve/veya kullanıcı tarafından belirlenniş seviyede bakım talebi) olup olmadığı bilgisi,
* Malzemeye özel lojistik gereksinim (Personel, eğitim, test&destek ekipmanı, vb.) ihtiyacı,
* Malzemeye özel prosedür (yıldırım düşmesi sonrası yapılacak işlemler, vb. ) ihtiyacı,
* Hasar sonrası tehlike yaratma ihtimali olan malzemeler,
* Malzemeye tanımlı arıza tespiti ve/veya fonksiyonel test görevleri olup olmadığı,
* Yeni teknoloji kullanan malzemeler,
* Ömürlü malzemeler,
* Potansiyel maliyet arttırıcı malzemeler,

* Uzun onarım zamanı nedeni ile kullanıma hazır olmayı etkileyen malzemeler,
* Kullanıcı özel isteği olan malzemeler,
* Kullanıcı tarafından yazılım yüklenebilen malzemeler,
* Bir LDA adayı malzemeye ulaşmak için sökülmesi/takılması gereken malzemeler,
* Genel görevlere ait verilerin LDA veritabanında bulunması (LDA veritabanında verilerin olması durumunda, benzer koşullarda kullanılıp kullanılmayacağı, yapılacak modifikasyonların kapsamı vb. hususlar değerlendirilmelidir.),
* Farklı bir LDA programından alınan verinin entegrasyonunu gerektiren malzemeler (Farklı bir üreticiden alınan LDA verisinin doğrudan kullanılması veya değişiklikler yapılarak mevcut proje LDA verilerine uyumlu hale getirilmesi gerekiyor ise),
* Lojistik analizleri detaylı olmayan malzeme grupları (kablo, vb.),
* Analiz edilecek ürünün karmaşıklığı.

Ayrıca aşağıdaki koşulların bulunduğu malzemeler potansiyel LDA adayı olarak seçilebilmektedir:

* Potansiyel kullanıma hazır olmayı etkileyen faktörlere sahip malzemeler,
* Potansiyel maliyeti etkileyen malzemeler,
* Potansiyel Bakım/Onarımı etkileyen malzemeler,
* Sözleşmesel LDA gerekleri olan malzemeler.

Yukarıda yer alan bütün kriterler için ölçülebilir eşik değerlerinin olması gerekmektedir. Örneğin, malzemenin hata/arıza sıklığının bakım açısından önemli olup olmadığını belirten MTBF gibi açık eşik değerleri belirtilmelidir.

'''Aday Sınıflandırması'''

LDA adaylarını sınıflandırılırken bazı seçim kriterlerinin göz önünde bulundurulması gerekmektedir. LDA adayları sınıflandırılmasında kullanılabilecek bazı sorular aşağıda verilmiştir;

Aşağıda verilen sorulardan herhangi birine “Evet” cevabı verilmesi durumunda malzeme potansiyel Tam Aday’dır. Eğer soruların hepsine “Hayır” cevabı veriliyor ise malzeme muhtemelen Tam Aday değildir.

''Tam Aday için Sınıflandırma Kriterleri:''

Malzeme yeni geliştirilmiş veya büyük bir modifikasyona uğramış malzeme mi?

* Malzeme HDB mi?
* Onarılabilir malzeme mi?
* Düşük Güvenilirliği olan malzeme mi?
* Bakım/Onarım görevi olan malzeme mi?
* Malzeme için tanımlı bakım/onarım görevi kompleks mi? (uzun süren, personel ihtiyacı fazla olan vb.)
* Bakım/Onarım için gerekli olan özel test&destek ekipmanı var mı?
* Planlı bakım analizi sonrası ortaya çıkan planlı veya önleyici bakım var mı?

Aşağıda verilen sorulardan herhangi birine “Evet” cevabı verilmesi durumunda malzeme potansiyel Kısmi Aday’dır. Eğer soruların hepsine “Hayır” cevabı veriliyor ise malzeme muhtemelen Kısmi Aday değildir.

''Kısmi Aday için Sınıflandırma Kriterleri:''

* Erişim için başka bir malzemenin sökülmesi gerekiyor mu?
* Erişim için sökme işlemi sık mı gerçekleştiriliyor?
* Malzeme bakım, test prosedürleri göz önünde bulundurularak daha önce Tam Aday olarak tanımlanmış mı?
* Temizleme, depolama gibi genel aktiviteleri tanımlanmış donanım harici malzeme mi?

LDA Aday Aileleri tanımı benzer veya aynı malzemelerin gruplanması için kullanılmaktadır. Örnek olarak kablolar verilebilir. Aynı özelliklerde ve aynı/benzer konnektörleri olan kablolar bir Aday Ailesi altında değerlendirilebilir. Aşağıda ''Aday Ailesi için Sınıflandırma Kriterleri'' kapsamında kullanılacak sorular yer almaktadır;

''Aday Ailesi için Sınıflandırma Kriterleri:''

* Malzeme sisteme birden fazla aynı veya benzer yollar ile monte edildi mi?
* Bakım/onarım görevleri aynı veya benzer olan malzemeleri gruplamak mümkün mü?

==== <big>5.3.2.3. LDA İş Tanımı</big> ====
Raporlama, veri elemanları tanımları, veri değişim prosedürleri ve analizleri gerçekleştirmek için kullanılacak yazılım seçimleri gibi faaliyetler hakkında lojistik destek analiz süreci uygulama kurallarını içeren doküman, LDA İş Tanımlama Toplantısının önemli bir çıktısıdır.

Amaçlanan lojistik destek analiz süreci çerçevesinde, ürün tasarımı seçimi, doğrulama ve kontrol ile ilişkili performans verisi konusunda, LDA İş Tanımlama Toplantısı ihtiyaç makamı/kullanıcı/idame makamı/tedarik makamı ve yüklenicinin katılımı ile icra edilmeli ve gerekli noktalara toplantı kararlarında yer verilmelidir.

Tasarım ve desteklenebilirlik gereksinimleri için ilgili bütün önerilerin kontrol listeleriyle değerlendirilmesi sağlanmalıdır. Örneğin;

* LDA ile ilgili ürün tasarım ve performans verisinin tanımlanmış olması,
** Sözleşmesel dokümanlardan çıkarılan LDA verisi ve bilgisi (Çalışma saati başına tanımlı maksimum bakım işçiliği saati, tanımlı maksimum ortalama onarım süresi, çalışma süresi başına maksimum arıza sayısı vb.)
** Ürün kullanım verisinden çıkarılan LDA verisi ve bilgisi (Yıllık operasyon gereksinimleri, operasyon lokasyonları ve her lokasyonda görev alacak sistem sayısı, lokasyonlara göre bakım seviyeleri ve bakım personelleri vb.)
** Tasarım ve performans spesifikasyonlarından çıkarılan LDA verisi ve bilgisi (Tanımlı Arızalar Arası Ortalama Süre (MTBF) değerleri, güvenilirlik gelişimi, test edilebilirlik özellikleri vb.)
** Farklı ürün dokümanlarında geçen ilgili LDA verisi ve bilgisi (Özel çalışma ve/veya onarım kısıtları, teslimat planları, arızaların tehlike sınıfları, depolama kısıtları vb.)
** Seçilen LDA verisi ve sertifikasyon ve doğrulama veya diğer lisanslama amaçlı özel gereksinimlere konu olan bilgiler uygun şekilde not edildi mi? (Versiyon uyumluluğu vb.)

* İlgili değerlerin doğrulanması ile ilişkili kabul kuralları tanımlanması,
** Seçilen veri/bilgi için ölçülebilir hedef değerler tanımlandı mı?
** Seçilen verilere karşı ölçüm figürleri kategorize edildi mi?
** Seçilen veri/bilgi için toleranslar tanımlandı mı?
** Uygulanabilir tazmin kuralları belirlendi mi?
** Belirlenen değerler kullanıcı/tedarik makamı için kabul edilebilir midir?
** Durum bilgisiyle ilişkili kabul sonuçları tanımlandı mı?
** Uygulanabilir ceza ve ödül düzenlemeleri oluşturuldu mu?

* Aşağıdaki konuları etkileyen genel LDA stratejileri ve prensipleri kurulması,
** Tercih edilen bakım konseptinin tanımlanması
** Tedarik zinciri yönetimi destek konseptinin tanımlanması
** Onarımların bakım seviyelerine dağılımı
** Bakım seviyesi onarımları için söz konusu olabilecek sınırlamalar
** Tek kaynak prensiplerinin belirlenmesi
** Ara seviye destek konsepti uygulanabilir mi?
** Hazır alım konseptine ilişkin değerlendirme

==== <big>5.3.2.4. LDA Planı</big> ====
Raporlama, veri elemanları tanımları, veri değişim prosedürleri ve analizleri gerçekleştirmek için kullanılacak yazılım seçimleri gibi faaliyetler hakkında lojistik destek analiz süreci uygulama kurallarını içeren bu doküman, LDA İş Tanımlama Toplantısının önemli bir çıktısıdır. LDA İş Tanımlama Toplantılarında tüm paydaşların katılımı ve mutabakatı ile tasarım desteklenebilirliğini sağlayacak şekilde etkileyen ve uygun lojistik kaynaklarını tespit edilebilmesi için gerçekleştirilecek gerekli LDA faaliyetlerini belirleyen LDA planı oluşturulur.

Md.4.1.4 altında LDA Planı kapsamı genişletilerek ele alınmıştır.

=== 5.3.3. LDA İŞ TANIMLAMA TOPLANTISI ÇIKTILARI ===
LDA İş Tanımlama toplantısı sonucunda; taslak olarak toplantıya sunulan dokümanların nihai hale getirilmesi ile LDA sürecinin performansına ilişkin bağlayıcı anlaşmalar ortaya konulur.

LDA İş Tanımlama Toplantısı çıktı dokümanları aşağıda yer almaktadır:

* LDA adayları listesi
* Veri elemanları listesi
* LDA İş Tanımı
* LDAP

== 5.4. LOJİSTİK DESTEK ANALİZ FAALİYETLERİ ==
LDA ömür devrinin erken aşamalarında uygun seviyede gerçekleştirilecek ön analizlerle maliyet ilişkili kararlara destek olur. Gerekli durumlarda LDA, konsept safhasının başlangıcından itibaren tasarımı lojistik hususlara ilişkin olarak etkilemeli ve bu görev ürünün tüm ömür devri boyunca devam ettirilmelidir.

Tasarım girdileri, güvenilirlik, idame edilebilirlik, test edilebilirlik ya da planlı bakım analizi gibi farklı analiz kaynaklarından sağlanabilir. LDA adaylarına yönelik analiz faaliyetleri, analiz için harcanacak çabanın uygun bir seviyede planlanmasını sağlayacak eşik değerler tanımlanmadığı durumlarda yüksek analiz maliyetlerine yol açabilmektedir. Bu nedenle, analizler için harcanacak çaba ile analizler sonucunda elde edilecek ve yeterli seviyede destek gereksiniminlerini (kullanıcının ihtiyaçlarını ve lojistik destek maliyet kısıtlarını karşılayan) belirlemek için zorunlu olan bilgi arasındaki bir dengenin kurulması gerekir. Bu dengeyi kurabilmek ise, bir dizi ön değerlendirme yapmayı gerektirir. Bu amaçla, yapılacak analizlerle ilgili atama kriter ve kuralları yüklenici tarafından düşünülmeli ve proje ihtiyaçlarını sağlamak üzere uyarlanmış genel esaslar olarak müşteriye sunulmalıdır. Bu değerlendirmenin, hem LDA programının kendisi için harcanak çaba hem de Analiz Edilen Kalemin ömür devri boyunca ortaya çıkacak destek maliyetleri üzerinde etkisi vardır. Dolayısıyla, söz konusu faaliyetin projenin erken safhalarında bir başlangıç değerlendirmesi olarak gerçekleştirilmesi önemlidir.

Bir LDA aday kalemi için uygulanabilir analizleri belirlemekteki temel yaklaşım, analiz için harcanan çabaya kıyasla beklenilen faydanın daha fazla olduğu değerlendirilen analizlerin yapılması şeklinde olmalıdır. Bu değerlendirmeler yapılırken, “öğrenilmiş dersler” vasıtasıyla elde edilen bilgiler hem yüklenici hem de müşteri tarafından dikkate alınmalıdır. Bu şekilde elde edilen bilgiler dikkate alındığında, bazı durumlarda ilave analiz faaliyeti gerçekleştirmeden LDA ilişkili kararların alınması mümkün olabilmektedir.

Uygulanabilir olduğu durumlarda, yeni analiz yöntemlerinin kullanımı da maliyet etkileri ile birlikte değerlendirilmelidir. Örneğin, bir simülasyonun klasik analiz yöntemlerine göre daha kapsayıcı sonuçlar üretmesi mümkündür.

=== 5.4.1. POTANSİYEL ANALİZ FAALİYETLERİ ===
Yapılacak potansiyel analiz faaliyetleri aşağıda verilmiştir, bu analizlerin sonuçları LDA veri tabanı (LDAK) üzerinde dokümante edilmelidir.

1. Genel LDA İhtiyaçlarının Belirlenmesine Yönelik Analiz

2. Karşılaştırmalı Analiz

3. İnsan Faktörü Analizi

4. Konfigürasyon Değerlendirme

5. Güvenilirlik Analizi

6. İdame Edilebilirlik Analizi

7. Test Edilebilirlik Analizi

8. Hata Türleri, Etkileri (ve Kritiklik) Analizi (FMEA/FMECA) Değerlendirmesi

9. Hasar Analizi

10. Özel Olay Analizi

11. Planlı Bakım Analizi

12. Onarım Seviyesi Analizi (OSA)

13. Bakım Görev Analizi (BGA)

14. Yazılım Destek Analizi

15. Lojistik İlişkili Operasyonlar Analizi

16. Eğitim İhtiyaçları Analizi

LDA faaliyetleri kapsamında, her bir analiz sonuçlarının nasıl dokümante edileceği, teslim edileceği ve değerlendirileceği bilgileri LDAP kapsamında ele alınır.

==== <big>5.4.1.1. Genel LDA İhtiyaçlarının Belirlenmesine Yönelik Analiz</big> ====
LDA faaliyetleri için başlangıç noktası herhangi bir görevin/analizin yapılmasına yönelik tanımlanmış ön koşullardır. Bu doğrultuda, kaynakların etkin kullanımı açısından gerçekleştirilmek istenen analizlerin amaçları/gerekçeleri açıkça tanımlanmalıdır.

Genel LDA ihtiyaçlarının belirlenmesi, daha çok sözleşmesel, müşteri ve kullanıcı isterleri ile ilgilidir. Proje için genel LDA ihtiyaçlarının uygun bir şekilde ele alınması ve müşteri ile mutabakatın sağlanması aşamasında aşağıdaki hususlar dikkate alınmalıdır:

* Oluşturulan ürün kullanım verisi (Operasyonel Gereksinimler, Müşteri Gereksinimleri), hedeflenen destek stratejisi ve ilkeleri ile alternatif destek çözümleri,
* Hangi sözleşmesel bilgilerin LDA sonuçları ile gösterilmesi ve geçerli kılınmasının gerektiği, bu geçerli kılmanın nasıl ve hangi derinlikte yapılacağı,
* Özel ilgi alanlarına ilişkin gerekli raporların (örneğin yönetim raporları, program durum gözden geçirmeleri, performans ölçme raporları, doğrulama raporları, vb.) tanımlanması,
* En iyi yatırım geri dönüşünü garanti edecek ödünleşim analiz sonuçları (Örneğin; müşteri talepleri aynı hedefe farklı yöntemlerle ulaşmanın mümkün olup olmayacağı konusunda değerlendirilebilir. Bu değerlendirme neticesinde geliştirilecek alternatif çözümlerin önemli oranda daha az çaba ile gerçekleştirilebileceği de tespit edilebilir. Ancak dikkat edilmesi gereken müşteri gereksinimlerinin kabul edilebilir seviyede karşılanmasıdır.).

==== <big>5.4.1.2. Karşılaştırmalı Analiz</big> ====
Etkin bir LDA programının anahtarlarından biri karşılaştırmalı sistemlerden elde edilen verilerin kullanılması ve analiz edilmesidir. Tarihsel veri gözden geçirme olarak adlandırılan bu süreç, kıyaslanabilecek benzer sistemlerden/ekipmanlardan elde edilen tecrübeye dayalı bilgilerin yeni geliştirilen sistemin desteklenebilirliği ve performansını iyileştirmede kullanılmasını içerir .

Karşılaştırmalı analiz sadece özel bir istek olan durumlarda gerçekleştirilmelidir. Analizin ön koşulu bir ekipmanın, bir sistemin ya da bir son ürünün karşılaştırmalı bilgilerinin mevcut ve karar verme açısından (sadece başlangıç LDA faaliyetlerine yönelik olarak) kullanılabilir olmasıdır. Eğer karşılaştırmalı bir sistem tanımlanabilirse, kullanılabilecek karşılaştırma verilerinin elde edilebilmesi için uygun analizler yapılabilir. Analiz sonuçlarının dokümante edilmesi için karşılaştırma faktörlerini ve verilerini ve/veya karşılaştırılabilir LDA adaylarına ilişkin destek çözümlerini ele alan özel özet raporlar hazırlanabilir.

Karşılaştırmalı sistem ve alt sistemlerin belirlenmesi, yeni sistemin/ekipmanın tasarımı, operasyonel ve destek karakteristikleri ile tahmin edilecek parametreye dair bilgi sahibi olmayı gerektirir. Eğer tasarım parametreleri (ör; güvenilirlik, idame edilebilirlik) tahmin edilecekse, tasarım karakteristikleri yeni sisteme/ekipmana benzer olan operasyonel sistemler/ekipmanlar seçilmelidir. Yeni sistem için ana alt sistemler belirlendiğinde, tasarım parametrelerinin tahmini için kullanılacak ana hat karşılaştırma sistemi, birden fazla sistemin alt sistemlerinden oluşan kompozit bir sistem olabilir. Destek parametreleri (ikmal süresi, dönüş süreleri, ulaştırma süreleri, personel kısıtları vb) tahmin edileceği zaman ise, yeni sistemin/ekipmanın destek konseptine benzer mevcut sistemler (destek sistemleri) belirlenmelidir. Seçilen destek sistemi, tasarım karakteristiği açısından benzer olan sistemleri/ekipmanları destekleyen sistemlerden tamamen farklı bir destek sistemi de olabilir.

Gerçekçi bir karşılaştırmalı sistem tespit edilebilirse bu sisteme ilişkin bilgiler aşağıdaki hususların belirlenmesinde yardımcı olur:

a. Yüksek hata oranı potansiyeline sahip alt sistem ve komponentler

b. Gayri Faal Süresine etki eden temel unsurlar

c. Desteklenebilirliği geliştiren tasarım özellikleri

d. Potansiyel desteklenebilirlik problem alanları

e. Potansiyel emniyet veya insan faktörü etkileri içeren tasarım konseptleri

f. Destek kaynaklarına dair gereksinimler

g. Ürün destek gereksinimlerini, kullanım ve destek maliyetlerini ve sistemlerin erişilen göreve hazır olma seviyelerini etkileyen tasarım, operasyon ve destek konseptleri.

Bu faaliyetin ilk sonuçları, operasyonel gereksinimler ve müşteri gereksinimleri dahil desteklenebilirlik faktörlerini geliştirmek için kullanılır. İleriki safahalarda gerçekleştirilen karşılatırmalı analiz sonuçları da bu dokümanlara dahil edilir. Analiz sonuçları aynı zamanda ürün destek modeli belirlenirken girdi olarak kullanılabilir.

==== <big>5.4.1.3. İnsan Faktörü (Ergonomi) Analizi</big> ====
Bir ürüne ilişkin potansiyel destek çözümlerinin, insan faktörü gereksinimleri dahil, belirlenmiş eşik değerlerinin içerisinde olmasını sağlayabilmek için LDA, idame edilebilirlik ve desteklenebilirlik işlevleri sıkı şekilde koordine edilmelidir. İnsan faktörlerinin özellikle operasyonel ve bakım faaliyetlerinin uygulanabilirliği konusunda belirleyici etkisi vardır.

İnsan faktörü analizleri, diğer desteklenebilirlik mühendisliği fonksiyonları gibi, bakım ekibi ve destek ekipmanı gereksinimlerinin belirlenmesi çalışmalarına kaynak veri sağlar. Bu ilişki, tasarım gözden geçirme sürecinde başlar ve bakım görev analizlerinin geliştirilmesi süreci boyunca devam eder.

İnsan faktörü analizlerinin, Bakım Görev Analizi (BGA)’ne tabi tutulan LDA adayları üzerinde etkisi olabilmektedir. İnsan faktörleri, özel sınırlamalar (örneğin, özel yetenekler gerektiren bakım görevlerinin uygulanabilirliği ile ilgili) için bir gerekçe teşkil edebilir. Bu analizler esnasında hem ergonomik hususların hem de uygun bir insan-makine ara yüzüne yönelik tanımlanmış kuralların göz önünde bulundurulması gereklidir. LDA faaliyetleri üzerinde belirleyici etkileri olabilecek bazı hususlar aşağıda örneklendirilmiştir:

* Ağır yükleri kaldırma ve taşıma becerisi
* Özel koşullarda uzun bir süre hareket etme becerisi
* Tehlikeli malzemelerin elleçlemesi
* Personel istihdamında yasal sınırlamalar (güvenlik kısıtlamaları, vb)

İnsan faktörü analizi sonuçları, projenin mümkün olan en erken safhalarında dokümante edilmeli ve ilgili tüm dokümanlara girdi yapılmalıdır. İnsan faktörlerinin etkileri, LDA veri tabanı içerisinde farklı alanlarda yer alabilir. Tasarıma yönelik her değişiklik önerisi veya modifikasyon, bakımda da değişikliklere yol açar ve bu da insan faktörü kısıt ve sınırlamalarının gözden geçirilmesini gerektirir. Ömür devrinin sonunda, envanterden çıkarma safhasında, insan faktörleri yine kritik öneme sahip hale gelir. Zira bu safhada, insan sağlığı üzerinde etkisi olan malzemelerin ele alınması ihtiyacı doğabilmektedir.

EK-A, insan faktörü mühendisliği ile lojistik destek analizi süreci arasındaki ilişki ve entegrasyonu tanımlamaktadır.

==== <big>5.4.1.4. Konfigürasyon Değerlendirme</big> ====
Herhangi bir LDA adayı için tasarım konfigürasyonundan önemli ölçülerde sapma olması durumunda, konfigürasyon değerlendirmesi zorunludur. Ürünün geçerli kılınmasına ilişkin potansiyel değişiklikler, mühendislik değişiklikleri, sapmalar veya feragatler incelenmelidir. Konfigürasyon değerlendirmeleri, sapma gösteren bakım konsepti ve/veya lojistik destek gereksinim (personel, malzeme gibi) ihtiyacının genel değerlendirmesi şeklinde yapılmalı ve LDA adayları için analiz ihtiyaçları yeniden değerlendirilmelidir.

==== <big>5.4.1.5. Güvenilirlik Analizlerinin Değerlendirilmesi</big> ====
LDA adaylarının hedeflenen kullanım senaryoları ile ilişkili güvenilirlik tahminlerinin (örneğin MTBF), LDA çalışmaları kapsamında kullanımları değerlendirilmelidir. Güvenilirlik değerlerinin belirlenmesi tasarım ve geliştirme ile ilgili bir görevdir. Ancak bu analizlerin sonuçlarının dokümante edilmesi LDA için son derece önemlidir. Genel olarak, her bir donanım LDA adayı için güvenilirlik analizinin yapılması zorunlu kabul edilir. Buna ek olarak, güvenilirlik tahminlerinin LDA ürün kırılımında yer alan bütün gerekli elemanlara yönelik olarak genişletilmesi ve bu değerlerin bütün diğer ürün kırılımı arasında da tutarlılığının sağlanması önemlidir.

Güvenilirlik değerleri, Hata Türleri ve Etkileri Analizi (HTEA)’nin sonuçları içerisinde bir LDA adayı kalemin farklı hata türlerine ait hata oranları ile doğrudan ilişkilidir. Bu iki alan lojistik veri tabanı üzerinde tutarlı olmalıdır.

==== <big>5.4.1.6. İdame Edilebilirlik Analizi</big> ====
İdame edilebilirlik belirlenmiş prosedür ve kaynaklar kullanılarak, tanımlı bakım onarım seviyelerinde belirlenmiş yeteneğe sahip personel tarafından bakım faaliyeti gerçekleştirildiğinde, odak sistemin öngörülen performans seviyesinde tutulabilmesi veya öngörülen performans seviyesinde tekrar çalışır duruma geri getirilebilmesi kabiliyetinin ölçüsüdür.

Her bir LDA adayı için, teknik açıdan desteklenebilir olup olmadığına karar verebilmek üzere idame edilebilirlik analizinin yapılması önemlidir. Uygulanabilir olduğu durumlarda aşağıdaki konuları ele alan idame edilebilirlik analizleri gerçekleştirilmelidir:

* Müşteri gereksinimlerini yansıtan idame edilebilirlik özelliklerinin değerlendirilmesi,
* Uygulanabilir her LDA adayı kalem için bakım konseptini desteklemek amacıyla farklı seviyelerdeki bakım görevlerinin belirlenmesi,
* Farklı desteklenebilirlik açılarının araştırılması (nihai ürünün modüler tasarıma sahip olması, erişilebilirlik kolaylığı, özel bölgelerde yerleşim konsepti- MTBF değeri en kötü olan parçaların diğer parçaların arkasına gelecek şekilde yerleştirilmemesi- gibi).

Genelde, idame edilebilirlik analizi farklı detay seviyelerinde aşağıda sıralanan uygulamalarla gerçekleştirilebilir:

* Mevcut bilgilerin en düşük seviyede olduğu durumlarda, En İyi Mühendislik Kararlarının kullanılması,
* Ekipman tedarikçileri kaynaklı bilgilerin veri dönüşümü ile veya dönüşüm gerektirmeden değerlendirilmesi,
* AAK için bakım konsepti oluşturulurken; alternatiflerin kıyaslanmasında Onarım Seviyesi Analizi (OSA) ve/veya Önleyici Bakım Analizi, Planlı Bakım Analizi gibi destekleyici analizlerin dikkate alınması,
* Operasyonel profillere göre görevini gerçekleştiren ürünler için, bakım ve desteğe odaklanarak sınırlı bakım kaynakları ya da operasyonel profillerin değişmesi gibi durumların olası sonuçlarını değerlendiren simülasyon araçlarının kullanımı.

Farklı kalem tiplerine göre uygulanacak idame edilebilirlik analizinin seviyesi Tablo 5’de belirtilmiştir.

'''Tablo 5 Kalem Türüne Bağlı Olarak İdame Edilebilirlik Analizi Derinliği'''
{| class="wikitable"
|'''Analiz Edilen Kalemler'''
|'''İdame Edilebilirlik Analiz Derinliği'''
|-
|Halen karşılaştırılabilir koşullarda kullanılmakta olan kalemler.
|Orta seviye bilgi ve veri dönüşümü ihtiyacı vardır. Daha detaylı idame edilebilirlik analizi isteğe bağlı olarak yapılabilir.
|-
|Halen kullanımda olmakla birlikte, karşılaştırılabilir koşullar altında kullanılmayan kalemler.
|Dikkatli veri dönüşümü gereklidir, yeni koşullara göre daha detaylı bir idame edilebilirlik analizi yapılması gerekebilecektir.
|-
|Büyük modifikasyon olmadan kullanılabilecek RAHAT kalemler.
|Lojistik özellikler ve/veya gereksinimlere ilişkin uygunsuzlukların dokümante edilmesi ve müşteri tarafından kabul edilmesi gereklidir.
|-
|Hazır bulunan ve minör değişiklikler gerektiren kalemler.
|Orta seviye bilgi ve veri dönüşümü ihtiyacı vardır, daha detaylı idame edilebilirlik analizi isteğe bağlı olarak yapılabilir.
|-
|Hazır bulunan ve majör değişiklikler gerektiren kalemler.
|Dikkatli veri dönüşümü gereklidir, yeni koşullara göre daha detaylı bir idame edilebilirlik analizi yapılması önemlidir.
|-
|İyi bilinen bir teknolojiye bağlı olarak yeni geliştirilen kalemler.
|Detaylı idame edilebilirlik analizinin yapılması gerekir.
|-
|Yeni bir teknolojiye bağlı olarak yeni geliştirilen kalemler.
|Detaylı idame edilebilirlik analizi mutlaka yapılmalıdır.
|}
İdame edilebilirlik analiz sonuçları dikkatli bir şekilde dokümante edilmeli ve analiz sonucunda ortaya çıkan bakım konsepti ile ilişkili veriler lojistik veri tabanına kayıt edilmelidir.

==== <big>5.4.1.7. Test Edilebilirlik Analizi</big> ====
Test edilebilirlik analizi için gerekli olan girdiler;

* İdame edilebilirlik stratejisinin tanımlanması
* Tüm test mimarisinin ve test prensiplerinin tanımlanması
* Sözleşmesel test edilebilirlik gereksinimlerinin tanımlanması ve doğrulanması
* FMEA/FMECA dokümanlarında geçen test edilebilirlik ile ilişkili bilgilerin değerlendirilmesi
* İlişkili tüm seviyelerde gereksinimlerin fonksiyonel kontrolünün tanımlanması
* İlişkili lojistik kaynak gereksinimlerinin (personel, yüklenebilir yazılım, test yazılımı gibi) tanımlanması

Test edilebilirlik analizi, idame edilebilirlik analizi ile yakından ilişkilidir. Test edilebilirlik analizi sonuçları idame edilebilirlik analizlerini doğrudan etkiler. Kalemin test özelliğine ilişkin herhangi bir düzeltici bakım, düzeltilecek hatanın fark edilebilmesine bağlıdır. Bir hata herhangi bir test prosedürüyle doğrulanamazsa, ilgili onarım görevi gerçekleştirilemez. Tüm bunlara ilave olarak, bir kalemin onarım sonrası da fonksiyonelliğinin test edilmesi gereklidir. Arıza fark etme/doğrulamanın detay seviyesi, bakım konseptini etkileyen en önemli etkendir.

Test edilebilirlik özelliklerinin tasarım tamamlandıktan sonra belirlenmesi neredeyse imkânsızdır. Bu nedenle, test edilebilirlik gereksinimleri uygulanabilir her kalem için geliştirme safhasında tanımlanmalıdır.

Cihaz İçi Test (CIT) yeteneği olan tüm kalemler için test edilebilirlik analizi zorunludur. İlişkili test edilebilirlik özellikleri tanımlanmalı ve dokümante edilmelidir. Bir şekilde tüm test mimarisinde gözlenen indirgenmiş (reduced) CIT yeteneğine sahip kalemler için (RAHAT kalemler gibi) test edilebilirlik analizinin yapılması önemlidir.

Test edilebilirlik özellikleri ile ilgili veri tipleri lojistik veri tabanında ya da test edilebilirlik raporlarında dokümante edilmelidir. Üreticiler için test edilebilirlik özelliklerinin ne şekilde uygulanacağına ilişkin kuralların tanımlanması ve doğrulanması gereklidir.

==== <big>5.4.1.8. Olaya Dayalı Bakıma İlişkin Analiz Faaliyetleri</big> ====
'''<big>5.4.1.8.1. Hata Türleri Etkileri ve Kritiklik Analizi/Hata Türleri Etkileri Analizi (HTEKA/HTEA)</big>'''

HTEKA’nın amacı, bir ürünün potansiyel hata durumlarını tanımlamaktır. Hata durumlarının kritikliğinin hesaba katılmadığı durumda, yapılan analiz faaliyeti HTEA olarak adlandırılır. Fonksiyonel hatalar sistem HTEKA’sı yapılarak tanımlanır/analiz edilir, teknik hatalar ise alt sistem HTEKA yaklaşımı ile tanımlanır/analiz edilir.

'''Sistem Hata Türleri Etkileri ve Kritiklik Analizi (HTEKA)'''

Sistem HTEKA’sı yukarıdan aşağıya yaklaşımını kullanarak, Ürünün farklı sistemlerini analiz eder. Bu amaçla, potansiyel fonksiyonel hatalar, bu hataların etkileri, kritikliği, son etkisi ve hata sebepleri belirlenir.

Emniyet, yasal ya da çevre bütünlüğünden dolayı kritik olduğu tespit edilen potansiyel hata etkilerinin önlenmesi zorunludur. Operasyonel/görev ilişkili ya da ekonomik sebeplerden dolayı istenmeyen diğer hata etkileri de önlenmelidir. Analiz sonuçları, önleyici bakım (planlı bakım) ve düzeltici bakım faaliyetlerinin tanımlanması için ya da yeniden tasarım gereksinimleri için ana çizgiyi oluşturacaktır.

'''Alt -Sistem Hata türleri Etkileri ve Kritiklik Analizi (HTEKA)'''

Alt sistem HTEKA’sı, üründe bulunan herhangi bir alt sistemde meydana gelebilecek teknik hataların olasılığını ve sonucunu tanımlayacak detayda aşağıdan yukarıya yaklaşımı ile gerçekleştirilir.

Emniyet analizi faaliyetleri (örneğin hata ağacı analizi) sistem ve alt sistem HTEKA’sına bağlıdır. Hata ağaçlarında, emniyet kritik hata kombinasyonları da tanımlanabilir. Hataların gerçekleşme olasılık seviyelerine bağlı olarak, yeniden tasarım, düzeltici bakım (onarım ya da yenisi ile değişim gibi) ve/veya önleyici (planlı) bakım gereksinimleri tanımlanmalıdır.

'''<big>5.4.1.8.2. Hasar Analizi</big>'''

Hasara elverişli bileşenler, en azından kısmi LDA adayı kalemi olarak değerlendirilmelidir. Genelde hasarlar, her bir durum için kritikliğinin ya da derecesinin önceden belirlenemeyeceği özel olaylardır. Yine de aynı yolla meydana gelebilen ya da aynı yolla tespit edilebilen hasar sınıflarının tanımlanması yararlı olacaktır. Analiz sonuçları, lojistik veri tabanında dokümante edilmelidir (örneğin yapısal elemanlar için test ve onarım prosedürlerinin veri tabanında belirtilmesi gibi). Hasarlarla ilgili güvenilirlik değerleri normalde mevcut değildir. Yalnızca, istatistiksel değerlendirmelerin yardımıyla bir tahminde bulunmak mümkün olabilir.

<big>'''5.4.1.8.3. Özel Olay Analizi'''</big>

Özel olayın bir türü olarak hasarlar dışında, başka diğer olayların da AAK’nin ya da ürünün bakım konseptine etkisi olabilir. Fonksiyonelliğini garanti etmek için özel bakım uygulamaları gerektiren, olası özel olayların tanımlanması ve dokümante edilmesi önemlidir. Ayrıca, gerekli bakım uygulamalarının ve personel, malzeme, yazılım gibi gerekli kaynaklarla ilişkili bilgilerin tanımlanmış ve dokümante edilmiş olması gereklidir.

Bakım uygulaması gerektiren bazı özel olay örnekleri;

* Sıcaklık limitlerinin aşılması
* Mekanik yükleme limitlerinin aşılması (örneğin aşırı torklama)
* İzin verilen hız limitlerinin aşılması
* Tuz yüklü atmosferde operasyonel kullanım
* Kumlu ortamda kullanım
* Yıldırım
* Uçaktan zor iniş
* Harici nesnelerle çarpışma
* Sert İniş (Hava Araçları)

==== <big>5.4.1.9. Planlı Bakım Analizi</big> ====
Planlı Bakım Analizi (Scheduled Maintenance Analysis), emniyet ilişkili, büyük ölçüde ekonomik ve ekolojik hataları önlemek için yapılır. Emniyet kritik bir durum varsa analizin yapılması zorunludur. Beklenen önemli ekonomik ya da ekolojik dezavantajlar varsa analizin tekrar yapılması gerekir. Analiz sonuçları bakım konseptini doğrudan etkiler. Planlı bakım uygulamalarının lojistik veri tabanı üzerinde mutlaka dokümante edilmesi gerekir.

==== <big>5.4.1.10. Onarım Seviyesi Analizi (OSA)</big> ====
Genel destek stratejisine bağlı olarak, her bir kalem için bakım ve/veya onarımının hangi seviyede yapılacağına karar verilmesi gereklidir. Bu kararı desteklemek için analiz edilecek LDA adayı kalemin tipine bağlı olarak birkaç yöntemden birisi uygulanarak OSA gerçekleştirilir.

'''Tablo 6 OSA’nın Farklı Derinliklerinin Sınıflandırılması'''
{| class="wikitable"
|'''OSA Sınıflandırması'''
|'''Tanım'''
|-
|Basitleştirilmiş OSA
|Mevcut en iyi bilgiler göz önünde bulundurularak en iyi mühendislik yaklaşımının temellerinden elde edilebilir. Sonuçların mutlaka dokümante edilmesi gerekir.
|-
|Tam OSA
|Bu kapsamlı analizin yapılabilmesi için kalemin kendisiyle ve kullanım içeriği ile ilişkili olarak gerekli tüm verinin (örneğin; operasyonel senaryolar, yedek parça tedariki, maliyet gibi) olması gereklidir.
|-
|Simülasyon Üzerinden Analiz
|AAK bu kalemin intikal ve operasyonel senaryoları ile ilgili oldukça detaylı bilgileri hesaba katan bir simülasyon en iyi OSA sonuçlarını oluşturabilir. Bu durum simülasyon için yazılım paketinde kullanılacak uygun formattaki tam bir bilgi/veri setini gerektirir. Bu bilgi/veri setini hazırlamak ilave çabaya sebep olabileceğinden bu durumun da ayrıca değerlendirilmesi gerekecektir.
|}
Her durumda, uygulanabilir olduğu ölçüde OSA yapılması zorunlu bir analizdir.

==== <big>5.4.1.11. Bakım Görev Analizi (BGA)</big> ====
Bakım Görev Analizi, LDA sürecindeki merkezi analiz faaliyetlerinden birisidir. Burada, tanımlanmış bakım görevleri (hem planlı hem plansız) mevcut olan gerekli tüm bilgilerle aşağıdaki gibi detaylandırılır.

* İlgili bakım görevinin yerine getirilebilmesi, eğitim gereksinimleri ve kritik görevler için ön koşulların ne olduğu gibi genel görev bilgilerinin dokümante edilmesi,
* Bakım görevlerinin tanımlı olaylara (arızalar, hasarlar, özel olaylar, zaman kısıtlamaları gibi) atanması,
* İlgili lojistik kaynak gereksinimlerinin (personel, destek ekipmanı, yedek parçalar, alt yapı, yazılım gibi) tanımlanması,
* Görev sıklığının hesaplanması,
* Tanımlanmış görevden önce ve sonra yapılması gerekli olan görevler.

==== <big>5.4.1.12. Yazılım Destek Analizi</big> ====
Kullanıcı tarafından yüklenebilir veri/yazılım içeren her bir kalem aşağıdaki hususlar kapsamında analiz edilmelidir. Bu analiz, bakım ve hizmet görevlerini kapsar.

* Kullanıcı tarafından yüklenebilir yazılım/veri içeren donanım bakımı
* Kullanım hazırlığı için gereken veri ve/veya operasyonel yazılım
* Kullanıcı tarafından yüklenebilir yazılım sürümleri ile birlikte kalemin/birimin revizyonunun güncellenmesi için verilecek yazılım desteği

Yazılım Destek Analiz programı yazılım değişikliklerini, sürümleri ve yazılımda bir virüs (bug) olması durumunda yazılımın bakımını yönetecekse, oluşturulacak süreç donanım için olan LDA süreci ile aynı çizgide olmalıdır.

==== <big>5.4.1.13. Lojistik İlişkili Operasyonlar Analizi</big> ====
Bir ürünün kullanımı ve bakımına ilişkin görevlerin yanısıra, operasyon açısından dikkate alınması gereken bazı ilave hususlar vardır. Bazı durumlarda doğrudan ürünün kullanımıyla veya bakımıyla ilişkilendirilemeyen görevler söz konusu olabilir. Ancak bu görevler, operasyon ve bakım tesislerinde normal operasyonlara destek olarak yürütülür (ör; paketleme, elleçleme, depolama, ulaştırma, demirleme gibi).

Bu görevler ürünün doğru kullanımı açısından son derece önemlidir. Lojistik ilişkili operasyonel görevler olarak nitelendirilebilecek bu görevler, operasyonları çeşitli açılardan kısıtlayabilirler (kullanım kolaylığı, kullanılabilirlik, kullanım esnekliği, mobilite gibi). Bu doğrultuda Analiz Altındaki Sistemin (AAS) genel kullanımı için önemli olan görevlerin tanımlanabilmesi amacıyla operasyonel gereksinimler analiz edilmelidir ve bu görevler lojistik veri tabanında dokümante edilmelidir.

==== <big>5.4.1.14. Eğitim İhtiyaçları Analizi (EİA)</big> ====
Bu analiz kapsamında, belirli bir görevin özel bir eğitim gerektirip gerektirmediğine karar verilir. Eğitim gerekli ise, eğitimin etkili bir şekilde nasıl uygulanabileceği belirlenmelidir. Bu süreç, belirlenen görevlere ilişkin LDA veri tabanında yer alan içerikten faydalanarak desteklenebilir.

Eğitim gereksinimlerine yönelik kriterler LDA İş Tanımlama Toplantısı esnasında Yüklenici ve Müşteri arasında görüşülmeli ve uyumlu hale getirilmelidir. Belirlenen kriterler LDA veri tabanına aktarılmalı ve her bir görev bu kriterlere göre değerlendirilmelidir. Elde edilen sonuç, LDA veri tabanında yer alan görevlere dair mevcut verilere dayalı bir ön Eğitim İhtiyaçları Analizi kararı olabilir.

==== <big>5.4.1.15. Envanterden Çıkarma Analizi</big> ====
Bir sistemin faydalı ömrü sona erdiğinde, emniyet (patlayıcı emniyeti dahil), güvenlik ve çevreye dair hukuki ve düzenleyici gereksinimlere uygun olarak envanterden çıkarılması gerekir. Tasarım süreci boyunca, sistemde yer alan tehlikeli maddeler dokümante edilmeli ve sistemin emniyetli bir şekilde bertaraf edilmesi planlanmalıdır.

Bu analizlerin amacı sistem/birim ve ilişkili tesis ekipmanları için envanterden çıkarma prosedürlerinin belirlenmesidir. Bu amaçla, komponent, komple, tali komple, parça ve malzemelerden tehlikeli madde, atık ve çevre kirletici madde içerebilecek olanlar ile yeniden işlenebilecek, yeniden kullanılabilecek veya kurtarılabilecek malzemeler belirlenir.

Malzemelerin envanterden çıkarma prosedürlerinin belirlenmesi ve dokümante edilmesi gerekir. Bu faaliyetin gerçekleştirilmemesi, ürün işletimi ve idamesinde görev yapan personelin sağlık ve emniyetini etkileyebilir. Ekipman veya komponentlerin demilitarize edilmesi, ulusal güvenlik açısından önemli bir konu olup gizli verilerin tehlikeye atılmasının önlenmesi gerekir.

Komponent, komple, tali komple, parça ve malzemelerin envanterden çıkarılmasına yönelik detaylı prosedürlerin oluşturulmasından yüklenici, bütün olarak sistem/ekipmanın envanterden çıkarılması/demilitarize edilmesinden ise ihtiyaç makamı/kullanıcı/idame makamı sorumludur.

== 5.5. MÜŞTERİNİN LDA PROGRAMINA KATILIMI ==
LDA sürecine dair yüklenici’nin yorum ve yaklaşımının müşterininkiyle aynı doğrultuda olduğunu garanti altına almak için müşteri tüm LDA programı boyunca uygun derinlikte sürece dahil olmalıdır.

=== 5.5.1. MÜŞTERİNİN ADAY KALEMLERİ DEĞERLENDİRMESİ VE TAVSİYE EDİLEN ANALİZ AKTİVİTELERİ ===
LDA adaylarının seçimi ve bu aday kalemlere uygun analiz aktivitelerinin atanması, LDA sürecinde maliyeti önemli ölçüde etkileyen husustur. Bu sebeple, LDA adaylarının seçimi projenin erken aşamalarında büyük bir özenle yapılmalıdır. Riski azaltmak için, uygulanabilir olması durumunda sözleşmenin imzalanmasından önce taslak aday kalem listesi hazırlanmalıdır.

==== <big>5.5.1.1. LDA Süreci Değerlendirme Kurallarının Konulması</big> ====

==== Değerlendirme kuralları yüklenici ve müşterinin ortak kararı ile belirlenmelidir. Değerlendirme kurallarının belirlenmesi için en az aşağıdakileri içerecek şekilde bazı genel kurallar koyulmalıdır: ====
Yalnızca LDA GGT’de anlaşılan kuralları içeren hususlar veya müşteri ile yüklenici arasında anlaşılan gelecek LDA süreci içerisindeki (ör. LDA gözden geçirmeleri) kurallar dikkate alınmalıdır.

Eğer bir değerlendirme gerçekleştirilmiş ve başarılı olarak sonuçlanmışsa, doğrudan ilgili yeni bir husus olmadığında aynı konu tekrar değerlendirilmemelidir.

* Yalnızca LDA ile ilişkili kurallar değerlendirmeye alınmalıdır.
* Diğer hususlar (ör. teknik dokümantasyon, ikmal desteği, eğitim vb.) LDA değerlendirme kuralları kapsamına alınmamalıdır.
* Müşteri veya yüklenici kadrosunda oluşan bir değişiklik daha önce karar alınmış değerlendirmeleri etkilememelidir.
* LDA teslimatlarının yayımlanması ile bu teslimatlara verilecek görüşler için cevapların oluşturulması süreleri arasında geçecek zaman için sınır kuralları koyulmalıdır.
* Yüklenicinin LDA teslimatlarının içerisindeki detay değerlendirme daveti ve değerlendirme sonuçları uygun kodlar kullanılarak bir durum kodu ile belirtilmelidir.
* Bilgilerin detayları, yapısı ve kullanılacak kodlar müşteriyle de koordine edilmek suretiyle yüklenicinin sorumluluğunda olmalıdır.
* LDA gözden geçirme yapısı durum kodu tarafından temsil edilen bilgi grubu doğrultusunda organize edilmelidir.
* Durum kodu için lojistik veri tabanı içerisinde uygun veri elemanı tanımlanmalıdır.
* Her LDA adayını ilgilendiren durum kodu lojistik veri tabanında uygulanabilir olarak güncel tutulmalıdır.

Değerlendirme sonuçları dokümante edilmeli ve belirlenmiş değerlendirme prosedürüne uygun olarak yükleniciye gönderilmeli ve tüm konular açıklığa kavuşana kadar takip edilmelidir.

Ürün kırılımının özellikle yapısı, içeriği ve derinliğinin uygunluğu, LDA aday kalem seçim kriterlerinin net bir şekilde tanımlanmış olması ve bu kalemler için yapılacak analiz faaliyetlerinin seçim kriterlerinin uygunluğu müşteri tarafından ilk değerlendirme kapsamında değerlendirilmeli ve görüşler yükleniciye iletilmelidir. Bu aşamadan sonra yapılacak değerlendirmeler, yüklenici tarafından yapılan her bir teslimat kapsamında olacaktır. Proje LDA programına göre uyarlanarak yüklenici tarafından hazırlanan dokümanların nasıl iletileceği, görüşlerin/yorumların nasıl hazırlanacağı, ilgili görüş/yorumların değerlendirme süreci, üzerinde mutabakatın sağlanması gibi tüm aşamaları içeren değerlendirme süreci (yorum verme süreci de içeren) dokümante edilmeli ve LDAP kapsamında tanımlanan sürece uygun olarak tanımlanmalıdır. Müşteri, LDA sürecinde ilerleme sağlayabilmek için yaptığı değerlendirmeleri, özellikle mutabık kalınan/kalınmayan noktaları ve mutabık kalınmayan hususlarda açıklamalarını yükleniciye resmi olarak aktarmalıdır. Tüm LDA çıktıları konfigürasyon yönetim ilkelerine göre kayıt altına alınmalıdır. Ayrıca, müşteri tarafından verilen görüş/yorumlar, bunlara oluşturulan cevaplar ve son durumun da kayıt altına alınması izlenebilirlik açısından gereklidir.

Şekil 7’de müşteri ve yüklenici arasındaki bilgi alışverişi için örnek bir süreç gösterilmiştir. Tablo 7’de ise zaman aralıkları hakkında açıklamalar verilmiştir.
[[Dosya:TSSODYP06.07.jpg|alt=|sol|küçükresim|645x645pik|Şekil 7 Müşteri İle Yüklenici Arasındaki Veri Alışverişi Süreci (Örnek)]]

'''Tablo 7 Yorumlama Sürecinin ZamanTakvimi ile Açıklanması'''
{| class="wikitable"
|'''Zaman'''
|'''Eylemler'''
|-
|Sözleşme T0+…
|Yüklenici tarafından LDA teslimat kalemlerinin hazırlanmasına başlanması.
|-
|T1
|Sözleşmesel LDA teslimat kalemlerinin müşteriye anlaşılan formatta teslim edilmesi
|-
|T2
|T2 ve T1 arasında müşterinin teslim edilen kalemler üzerinde (LDA verisi, LDA raporları) yorum verme süreci gerçekleşecektir. T2 için anlaşılan zamanda yorumların yükleniciye iletilmesi gerçekleşecektir.
|-
|T3
|LDA gözden geçirme eforunun azaltılması için, kolayca cevaplanacak her tipte yorumlar LDA gözden geçirme öncesinde eğer mümkünse yüklenici tarafından ele alınmalıdır. Bununla beraber, müşterinin yorumlarıyla ilgili her karar dikkatlice dokümante edilmelidir.

Bu süreçte, birden fazla soru-cevap döngüsü özel soruları detaylıca açıklayabilir, fakat döngü sayısı, daha fazla kapsamlı soruların netleştirilmesi gerektiğinden sınırlandırılmalıdır. (ör. LDA gözden geçirmesinde veya yüklenici ve müşteri arasındaki daha uzun netleştirme süreci)
|-
|T4
|T2 ve T4 arasındaki zamanda, müşteri ve yüklenici arasındaki netleştirme döngülerini dikkate alarak, kalan müşteri yorumları yükleniciye teslim edilecektir. Bu yorumlar LDA gözden geçirmesindeki netleştirme ve tartışmalar için temel oluşturacaktır.
|-
|TGözden Geçirme
|LDA gözden geçirme zamanı. LDA gözden geçirmesindeki her kararın karşılık gelen durum bilgisi güncellemesi ile birlikte dokümante edildiğinden emin olunmalıdır.
|}
Müşteri ile gerçekleştirilecek analiz verilerinin değişimi hususunda uygulanması gereken adımlar LDAP kapsamında ele alınacaktır:

* Veri ve doküman değişimi için uygun kuralların koyulması (bkz: 5.5.1.2)
* Yüklenici tarafından LDA veri ve dokümanların toplanması (bkz: 5.5.1.3)
* Yüklenici tarafından LDA veri/dokümanlarının teslimatı (bkz: 5.5.1.4)
* Müşteri değerlendirmesi ve değerlendirme sonuçlarının dağıtımı (bkz: 5.5.1.5)
* Yüklenici tarafından müşteri cevaplarının dağıtımı (bkz: 5.5.1.6)
* Anlaşılmayan yorumlarla ilişkili yüklenici cevaplarının dağıtılması (bkz: 5.5.1.7)

==== <big>5.5.1.2. Veri ve doküman değişimi için uygun kuralların koyulması</big> ====
Uygun anlaşmalar ve kurallar LDA GGT’de ve devamındaki LDA anlaşmalarında müşteri ile yüklenici arasında dokümante edilip üzerinde anlaşılmalıdır. Örneğin:

* Kullanılan yazılımlar,
* Veri ve rapor formatları (ör. Dex-formatı),
* Periyodiklik,
* Teslimat ve cevap süreleri,
* Dağıtım paydaşları ve uyulması gereken akış.

==== <big>5.5.1.3. Yüklenici tarafından LDA veri ve dokümanlarının toplanması</big> ====
Müşteri ve yüklenicinin arasında yapılan LDA GGT ve sonrasında yapılan LDA anlaşmaları mutabakatla dokümante edilmelidir. Bu dokümantasyon en az aşağıdaki hususları içermelidir:

* Uygun veri/doküman değişiminin ve endüstri içindeki veri/doküman paylaşım ağının kurulması,
* İş ilişkisinde bulunulan firmalar ve LDA ile ilişkili disiplinler arasında istenen teslimatlar için veri/dokümanların toplanması,
* Endüstri içi kalite kontroller, harmonizasyon ve teslimat anlaşması performansları.

==== <big>5.5.1.4. Yüklenici tarafından LDA veri/dokümanlarının teslimatı</big> ====
Müşteri ve yüklenicinin arasında yapılan LDA GGT ve sonrasında yapılan LDA anlaşmaları üzerinde anlaşılarak dokümante edilmelidir. Bu dokümantasyon en az aşağıdaki hususları içermelidir:

* LDA teslimlerinin son teslim tarihini içerecek şekilde (uygulanabilir olduğu durumda) üzerinde anlaşılan dağıtım kurallarının dikkate alınarak dağıtılması,
* Yüklenici iç dokümantasyonu ve resmi LDA teslimatlarının dağıtımı.

==== <big>5.5.1.5. Müşteri değerlendirmesi ve değerlendirme sonuçlarının dağıtımı</big> ====
Müşteri ve yüklenicinin arasında yapılan LDA GGT ve sonrasında yapılan LDA anlaşmaları üzerinde anlaşılarak dokümante edilmelidir. Bu dokümantasyon en az aşağıdaki hususları içermelidir:

* Yüklenicinin LDA teslimatının gerektiği gibi dağıtılması,
* Resmi müşteri yanıtlarına verilen tüm cevapların uyumlandırılması,
* Müşteri yanıtının yükleniciye dağıtımı.

==== <big>5.5.1.6. Yüklenici tarafından müşteri cevaplarının dağıtımı</big> ====
Müşteri ve yüklenicinin arasında LDA GGT ve sonrasında yapılan LDA anlaşmaları üzerinde anlaşılarak dokümante edilmelidir. Bu dokümantasyon en az aşağıdaki hususları içermelidir:

* Resmi müşteri cevaplarının kaydı,
* Endüstri iç dağıtımı,
* Yüklenici araştırma sonuçlarının tanımlanması, dağıtılması ve uyumlandırılması,
* Müşteri yanıt detaylarına göre (uygun olabildiğince) LDA veri tabanının güncellenmesi,
* Genel yorum ve anlaşmazlıklara yüklenici cevabının uyumlandırılarak hazırlanması.

==== <big>5.5.1.7. Anlaşılmayan yorumlarla ilişkili yüklenici cevaplarının dağıtılması</big> ====
Yükleniciden gelen tekrarlı analiz verileriyle ilgili adımlar 5.5.1.4’te verilmiştir.

== 5.6. LDA İŞ TANIMLAMA GÖZDEN GEÇİRME TOPLANTISI ==
Yüklenici ve müşterinin katılımıyla aşağıdaki hususları gerçekleştirmek için bir LDA İş Tanımlama Gözden Geçirme Toplantısı (LDA İş Tanımlama GGT) planlanmalıdır:

* Açıkta kalan konularla ilgili bir karara ulaşarak mutabakatın sağlamak,
* Müşterinin açıkta kalan konularla ilgili onayına ulaşmak,
* LDA aday kalemlerinin durumunu izlemek, (ör. tamamlanması ve kalitesi),
* Sürecin tüm fazlarıyla ilişkili lojistik desteği değerlendirmek,
* LDA sürecini geliştirmek için müşteri ve yüklenici arasındaki ek anlaşmalara ulaşmak.

=== 5.6.1. LDA GÖZDEN GEÇİRME SÜRECİ ===
LDA GGT, LDA aday kalem seviyesinde gerçekleştirilmelidir. Toplantıdan önce, yüklenici müşteriyi üzerinde konuşulacak LDA adayları ile ilgili bilgilendirmelidir.

LDA GGT’de LDA teslimatları ve ilişkili veri elemanları değerlendirilmeli ve belirlenmiş olan kabul kriteri gözetilerek kararlar alınmalıdır. Alınan her karar raporlanmalıdır.

Karmaşık LDA aday kalemleri uzun zamana yayılan projelerin farklı aşamaları içinde ulaşılabilir tipte bilgiye bağlı olarak bir dizi analiz aktivitesi gerektirebilir. Diğer yandan, bazı kararlar projenin en erken aşamalarında var olan kısıtlı bilgiye dayanarak alınmalıdır (ör. Ön bakım konseptinin belirlenmesi) Bazı kararlar ise projenin oldukça ileri bir aşamasına kadar belirli olmayan netleşmiş bir tasarım gerektirir (ör. Planlı bakım görevlerinin zaman açısından belirlenmesi vb.). Bu sebeple, birden fazla gözden geçirme gerçekleştirilebilir. Her LDA GGT’si değerlendirmesi istenen ve durum kodlarıyla gösterilen LDA adaylarına ait tüm adımları içermelidir.

LDA sürecinin yinelemeli doğasından ötürü, LDA GGT’si esnasındaki herhangi bir onay geçici değerlendirme olarak alınmalı fakat yüklenicinin LDA sürecine devam etmesine de izin vermelidir. LDA sürecinin doğası gereği, tasarım değişikliklerinden, teknik verilerin güncellenmesinden ve/veya destek ve operasyonel çevreden ötürü veriler tekrar gözden geçirilmelidir.

Nihai sonuçlar LDA dokümanlarında ve/veya veri tabanlarında dokümante edilmelidir ve her proje fazında dondurulmuş olarak düşünülmelidir. Buna ilişkin kabul kararları üzerinde LDA GGT’de anlaşılmalıdır.

LDA GGT’leri değişen tasarım ve analiz faaliyetleriyle paralel olarak gerçekleştirilmelidir. Bu toplantılar üzerinde anlaşılan periyotlarda veya değerlendirilecek bilgiye dayalı olarak düzenli olarak gerçekleştirilmelidir. Toplantı notları müşteri ve yüklenicinin gerçekleştireceği eylemleri içerek şekilde hazırlanmalıdır.

=== 5.6.2. GÖZDEN GEÇİRME KONUSU ===
Bir LDA GGT’sinde veya sonrasındaki anlaşmalarda müşteri ve yüklenici arasındaki sözleşmesel tüm kalemler LDA GGT’sinde gözden geçirilmelidir. LDA süreci için gerekli olarak tanımlanan ve belirlenmiş olan LDA programıyla ara yüzü olan diğer lojistik süreçleri etkileyebilecek her şey gözden geçirmenin konusudur.

LDA ile ilişkili analizlere ilişkin prosedür ve prensiplere giriş, analizlerin amaçları hakkında ortak bir anlayışa ulaşmak, ilgili kısıtlamalar ve LDA sonuçlarını değerlendirmek için yüklenici tarafından müşteriye sunulmalıdır.

Müşterinin özel olarak ilgilendiği kalemleri yansıtan raporların yanında ilerleme raporları ve veri kalite raporları da yüklenici tarafından sağlanmalıdır. Aşağıda bazı örnekler verilmiştir:

* Çalışma saati başına ortalama adam-saat gibi idame edilebilirlik değerleri,
* Belirlenmiş limitler içerisinde gerçekleşecek idame edilebilirlik görevleri için Ortalama Geçen Zaman gibi lojistik performans parametreleri.

=== 5.6.3. GÖZDEN GEÇİRME YAPISINA ÖRNEKLER ===
LDA gözden geçirme süreci içerisindeki adımlar bir projenin LDA verilerinin yayımlanması ve onaylanması için aşağıdaki şekilde düzenlenebilir:

* LDA gözden geçirme basamağı- 1. Aday Kalem listesi ve bakım analiz ataması (bkz: 5.6.3.1),
* LDA gözden geçirme basamağı- 2. Onarım seviyesi analizi ve bakım konsepti bilgisi (bkz: 5.6.3.2),
* LDA gözden geçirme basamağı-3. HTEA ve Planlı Bakım Analizi sonuçları (bkz: 5.6.3.3),
* LDA gözden geçirme basamağı-4. Bakım Görev Analizi (bkz: 5.6.3.4).

==== <big>5.6.3.1. Aday Kalem Listesi ve Bakım Analizi Ataması</big> ====
Bu basamak, sonrasında gelen LDA veri tabanı içerisinde dokümante edilen tüm LDA aktivitelerinin temelini oluşturmaktadır. Aşağıdakileri içerir:

* LDA aday kalemlerinin uygulanabilir olduğu durumda gruplanarak seçimi,
* Aday tipinin ve ilgili özelliklerinin (HDB’lerin tanımlanması, potansiyel maliyetler, potansiyel bakımlar, potansiyel kullanıma hazır olma) tanımlanması,
* Seçilmiş her aday için gerçekleştirilecek LDA ilişkili analiz aktivitelerinin atanması
* Detayları gösteren durum kodu,
* Aday kalem seviyesindeki her tasarım konfigürasyonundaki değişikliklerin LDA veri tabanında yönetilmesi.

==== <big>5.6.3.2. Onarım Seviyesi Analizi ve Bakım Konsepti Bilgisi</big> ====
Bu basamakta, bakım görevleri ilgili bakım seviyelerine atanarak ön bakım konsepti hazırlanır. Tipik olarak aşağıdakileri içerir:

* Yüklenici tarafından önerilen bakım konsepti,
* Ürüne ekipman entegrasyonu ile ilişkili bakım görevlerinin tanımlanması (ekipman çıkarılması ve yüklenmesi, ekipman ve sistem seviyesinde fonksiyonel testlerin performansı vb.),
* Önerilen bakım konseptinin doğrulanması,
* Red veya alternatif çözüm olabilecek bakım konsepti üzerindeki müşteri kararı.

==== <big>5.6.3.3. HTEA ve Planlı Bakım Analizi sonuçları</big> ====
Bu basamakta, bakım konsepti planlanmamış bakım görevlerinin HTEA ile belirlenmesiyle son haline getirilir. Planlı Bakım Analizi sonuçları ise planlı bakım görevlerini belirler.

==== <big>5.6.3.4. Bakım Görev Analizi</big> ====
Bu basamakta, belirlenmiş bakım görevleri, gereksinimlere ve uygulanmasına göre analiz edilir.

* Uygulanabilir derinlik ve ölçüde gerekli bakım görevlerinin tanımı
* Her görev adımının süresi
* Bakım aktivitelerini destekleyecek ilgili lojistik kaynakların tanımlanması (ör. Personel, destek ekipmanı, yedek parça, veri ve yazılım, sarf malzeme, tesisler)

==== <big>5.6.4. DURUM KODU ÖRNEKLERİ</big> ====
Durum kodları aşağıdaki ifadeleri yansıtacak şekilde düzenlenir:

* Dahil olan firmaların sorumlulukları; her görev grubu için görevli firma belirlenmelidir. Bu aynı zamanda üzerinde anlaşılan iş dağılımının detaylarını da yansıtır.
* LDA adayının tipi (tam aday, kısmi aday vb.)
* Önemli konular (kullanıcı tarafından yüklenebilir yazılım, veri vb.)
* Gözden geçirme aşaması göstergesi

Tablo 8, potansiyel kodlar ve karşılık gelen anlamları için örnek vermektedir. (Her LDA adayı için gözden geçirme aşaması göstergesi olarak)

'''Tablo 8 Durum Kodu Örnekleri'''
{| class="wikitable"
|'''Kod'''
|'''Tanım'''
|-
|X
|“Çalışır durumda”, değerlendirme istenmiyor
|-
|N
|İlgili LDA adayı için uygulanabilir değil
|-
|R
|Değerlendirme istendi ve Sıradaki LDA GGT’sinde karar verilecek
|-
|A
|Gösterge üzerinde müşteriyle geçici olarak anlaşıldı
|-
|B
|Müşteriyle geçici olarak anlaşıldı ancak son kabul için küçük bir çalışma gerektiriyor
|-
|O
|Müşteriyle üzerinde anlaşılamadı ve açık konu olarak kaldı.
|}

=== 5.6.5. DURUM KODU ATAMASININ DERİNLİĞİ ===
Her LDA adayı için minimum bir gereksinim olarak ilgili durum kodları atanmalıdır. Ayrıca, değerlendirme konusu detaylı bir şekilde adreslenebilir. (modifiye edilen bir LDA adayının değerlendirme ihtiyacı vb.) Bu karar LDA GGT’da alınmalıdır.

=== 5.6.6. DURUM KODLARININ İŞLEVİ ===
Durum kodları, gözden geçirme sürecinin yapısını yansıtır ve LDA veri tabanı içerisinde dokümante edilmesi gereken tüm sözleşmesel konuları adresler. LDA veri tabanı içeriğiyle ilgili tüm durum özeti raporları için kullanılabilir. (örneğin her LDA GGK sonrası LDA alanındaki gelişmelerin yansıtılması.)

Durum kodu tarafından filtrelenen bir LDA aday kalem listesi, müşterinin dikkatini özel bir konuya çekmek için kullanılabilir.

Durum kodu ayrıca ELD elemanlarına ilişkin ürünleri yaratırken karşılaşılabilecek riskler dikkate alınarak dur ya da devam et durumunu belirtmek için de kullanılabilir.

=== 5.6.7. LDA GGT’SİNDE DURUM KODUNUN TANIMLANMASI ===
Gözden geçirme aşamaları, ilgili durum kod yapısı ve uygulanabilir durum kodları yüklenici tarafından önerilip LDA GGT’sinde derinlik ve detay seviyesi ile beraber müşteri tarafından da onaylanmalıdır.

= 6. TASARIMA ETKİ/TASARIM ETKİLEŞİMİ =
LDA’nın temel amaçları, tasarımı etkilemek, en etkin destek konseptini oluşturmak ve lojistik kaynak gereksinimlerini tanımlamaktır. Bu bölümde bu amaçlar içerisinden özellikle ürün tasarımına etki üzerinde durulmuştur.

LDA gereksinimlerini karşılamak ve ÖDM azaltabilmek amacıyla tasarıma etki edebilme fırsatı projenin geliştirme safhasında en yüksek düzeydedir. Erken dönemde gerçekleştirilecek tasarıma etki, ileriki safhalarda ürünü kullanıma ve desteğe uygun hale getirme amaçlı tasarım değişikliği ihtiyaçlarını azaltabilir veya tamamen ortadan kaldırabilir. Tasarımın etkilenmesi, proje dönemi boyunca gerçekleştirilecek gözden geçirmeler ve ana hatlar ile yapılandırılmış bir şekilde gerçekleştirilir. Tasarımda (yazılım veya donanım) rol alan kişiler açısından bu faaliyet tasarım programı ile LDA programı arasında etkileşim sağlanması açısından önemlidir.

== 6.1. LDA’DAN ETKİLENEN VE KARŞILIKLI OLARAK LDA’YI ETKİLEYEN TASARIM PARAMETRELERİ ==

* LDA’nın tasarıma etki edebilmesi için nasıl bir strateji geliştirilmesi gerektiği ve bunun sağlayacağı faydalar,
* Tedarikçi bakış açısı,
* Kilometre taşlarındaki gözden geçirmeler.

== 6.2. LDA TARAFINDAN ETKİLENEBİLECEK VE LDA FAALİYETLERİNİ ETKİLEYEBİLECEK TASARIM PARAMETRELERİ ==
Bir ürünü daha verimli ve maliyet açısından daha etkin hale getirmek üzere sistem/altsistem veya ekipman tasarımını etkilemede kullanılabilecek birçok özellik vardır. Bu özelliklerden başlıcaları aşağıda sıralanmış ve ilerleyen bölümlerde açıklamalar verilmiştir.

* Kullanıma hazır olma,
* Güvenilirlik,
* İdame edilebilirlik,
* Test edilebilirlik,
* Prognostik,
* Standartlaştırma,
* Değiştirilebilirlik
* Çevresel hususlar,
* İnsan faktörü/ergonomi,
* Demodelik,
* Desteklenebilirlik,
* Maliyet etkinlik,
* Yazılım tasarımı.

=== 6.2.1. KULLANIMA HAZIR OLMA ===
Bir ürünün kullanıma hazır olması, ürürün bilinmeyen bir zamanda görev veya operasyon ihtiyacı doğduğunda söz konusu görev veya operasyonun başlangıç anında faal ve kullanıma uygun olma durumunun bir ölçüsüdür.

Güvenilirlik, idame edilebilirlik ve desteklenebilirlik ürünün kullanıma hazır olmasına etki eden faktörlerdir (Şekil 8).
[[Dosya:Şekil8 Kullanıma Hazır Olma Kırılımı.jpg|alt=|sol|küçükresim|583x583pik|Şekil 8 Kullanıma Hazır Olma Kırılımı]]

Bir sistemin Tasarımsal Kullanıma Hazır Olma ölçüsü (Inherent Availability), ürünün güvenilirlik ve idame edilebilirliği tarafından belirlenir ve sistemin zaman içinde herhangi bir anda, tanımlı kullanım koşulları altında ve ideal destek ortamında (destek kaynaklarında herhangi bir zafiyet olmadığı durumda) yeterli düzeyde çalışacağı olasılık olarak tanımlanır. Önleyici bakım ve gecikme zamanlarını kapsamaz.
[[Dosya:Tasarımsal Kullanıma Hazır Olma.jpg|sol|küçükresim]]

Aİ= Tasarımsal Kullanıma Hazır Olma

MTBF = Arızalar Arası Ortalama Süre

MTTR = Ortalama Onarım Süresi

Ulaşılabilir Kullanıma Hazır Olma (Achived Availability) ise tasarımsal kullanıma hazır olmaya benzemekle birlikte kapsamında önleyici bakım faaliyetlerini de bulundurur ve aşağıdaki şekilde ifade edilir:
[[Dosya:Ulaşılabilir Kullanıma Hazır Olma .jpg|sol|küçükresim]]

Aa = Ulaşılabilir Kullanıma Hazır Olma

MTBM = Bakımlar Arasındaki Ortalama Süre

M= Ortalama Aktif Bakım İşlem Süresi

Operasyonel Kullanıma Hazır Olma (Operational Availability) ise ürün ve destek sisteminin birleşimi ile ortaya çıkar. Bir sistemin tanımlı kullanım koşullarında, ideal olmayan gerçek destek ortamında ihtiyaç duyulduğunda yeterli düzeyde çalışma olasılığı olarak tanılanır ve aşağıdaki şekilde ifade edilir:
[[Dosya:Operasyonel Kullanıma Hazır Olma .jpg|sol|küçükresim]]

AO= Operasyonel Kullanıma Hazır Olma

MTBM = Bakımlar Arasındaki Ortalama Süre

MDT = Bakım İçin Sistemin Servis Dışı Kaldığı Ortalama Süre

=== 6.2.2. GÜVENİLİRLİK ===
Güvenilirlik, bir sistemin destek kaynaklarına etki eden birincil faktördür. Ürünün belirli koşullar altında hatasız performans gösterme süresi veya belirli koşullar altında belirli bir süre kendisinden beklenen işlevini yerine getirme olasılığı ile ilişkilidir. Güvenilirlik kullanıma hazır olma değeri ile doğrudan ilişkilidir.

Yüksek güvenilirlikli ürünler genellikle maliyet etkindir. Ancak, düşük güvenilirlikli ürün kullanımından kaçınmanın mümkün olmadığı durumlarda, ürün tasarımı bu durumu hatanın yerinin kolay belirlenmesinin ve bakım faaliyetlerinin kolay olmasını sağlayarak dengelemelidir. Bunun için sistem tasarımının erken aşamasında güvenilirliğin bir tasarım parametresi olarak ele alınması gerekmektedir. Kullanıma hazır olma oranını koruyabilmek için düşük güvenilirliğin idame edilebilirlik ve desteklenebilirliğin artırılması ile dengelenmesi bir ölçüde mümkün olabilmektedir.

Projenin güvenilirlik ile ilgili gereksinimleri incelenerek (eğer yoksa hedef bir güvenilirlik değeri yüklenici tarafından benzer sistemlerin verileri kullanılarak belirlenebilir) güvenilirlik ataması yapılır. Böylelikle her bir fiziksel alt sistemin sahip olması gereken güvenilirlik metrik değerleri projenin geliştirme safhasında belli olur. Güvenilirlik atamaları yapılırken çeşitli askeri standartlardan, veri tabanlarından veya geçmişteki sistemlerin saha verilerinden faydalanılabilir. Güvenilirlik metrik ölçüsü onarılabilir olan sistemler için (tek kullanımlık olmayan araç, silah sistem gibi) arızalar arası ortalama süre olarak tanımlanabilir. Tek kullanımlık olan sistemler (füze sistemi gibi) için ise görev güvenilirlik değeri yüzde olarak tanımlanabilir.

Güvenilirlikle ilgili olarak tasarım kapsamında dikkate alınması gereken hususlara ilişkin örnekler aşağıda verilmiştir:

* Üründe güvenilirliği düşük alt sistem ve bileşenler için yedekleme yapılabilir.
* Uygulanabilir olduğu ölçüde askeri standartlara uygun ürün seçimleri yapılmalıdır.
* Benzer sistem ve projelerdeki güvenilir olduğu bilinen parçaların yeniden kullanımı ilk kez kullanılacak parça seçimine göre tasarımda öncelikli olmalıdır.
* Yalıtım malzemelerinin kullanımı değerlendirilmelidir.

Güvenilirlik açısından bir diğer tasarıma etki etme faaliyeti ise HTEKA (Hata türleri, Etkileri, Kritiklik Analizi) vasıtası ile olur. Sistemin arıza verme senaryoları tek tek incelenerek olasılıklar hesaplanır ve sistemin arıza durumunda arızanın göreve engel teşkil edip etmeyeceği araştırılır. Göreve engel teşkil eden arızaların tek hatadan kaynaklanması durumunda bazı önlemler alınarak sistemin tek hatadan gayri faal olma durumunun engellemesi hedeflenir. Ayrıca kritik bir arıza birden çok kez tekrarlanıyor ya da tekrarlanma olasılığı yüksek çıkıyor ise tasarıma geri bildirim verilerek tasarımın değiştirilmesi ya da sistemin yedeklenmesi gibi önlemler alınması sağlanır.

Tasarıma etki ara yüzünün oluşturulması kapsamında başlangıç noktası olarak kullanılabilecek kontrol listesi aşağıda verilmiştir;

* Hata modları ve etkileri tanımlandı mı?
* Kalemlerin arıza oranları biliniyor mu?
* Arıza oranı yüksek parçalar belirlendi mi?
* Ortalama ömrün ne olduğuna karar verildi mi?
* Ekipman tasarım karmaşıklığı minimize edildi mi?
* Uygulanabilir olan durumlar için ikincil hatalara (birincil hataların sonucu olarak meydana gelen hatalar) karşı korunma önlemleri alındı mı?
* Güvenilirlik gereksinimleri karşılanıyor mu?

=== 6.2.3. İDAME EDİLEBİLİRLİK ===
İdame edilebilirlik güvenilirliğin yanında kullanıma hazır olmayı etkileyen bir diğer önemli faktördür.

İdame edilebilirlik, belirlenmiş prosedür ve kaynaklar kullanılarak, tanımlı bakım onarım seviyelerinde belirlenmiş yeteneğe sahip personel tarafından bakım faaliyeti gerçekleştirildiğinde, odak sistemin öngörülen performans seviyesinde tutulabilmesi veya öngörülen performans seviyesinde tekrar çalışır duruma geri getirilebilmesi kabiliyetinin ölçüsüdür.

İdame edilebilirliğin karakteristikleri

* Bir ekipmanın işlevselliğini korumak veya işlevsel haline geri getirmek için ekipmanın değiştirilmesi,
* Onarım için geçen süre,
* Destek kaynaklarının miktarı ve karmaşıklığı ve
* Faaliyetleri gerçekleştiren personelin gerekli beceri seviyeleri olabilir.

Projenin idame edilebilirlik ile ilgili gereksinimleri incelenerek (eğer yoksa hedef bir idame edilebilirlik değeri yüklenici tarafından belirlenebilir) idame edilebilirlik süre kırılımı yapılır. Böylelikle her bir fiziksel alt sistemin sahip olması gereken idame edilebilirlik metrik değerleri projenin geliştirme safhasında belli olur. İdame edilebilirlik kırılımları yapılırken çeşitli askeri standardlardan, veri tabanlarından veya envanterde bulunan ve halihazırda kullanılan sistemlerin saha verilerinden faydalanılabilir.

İdame edilebilirlik ile ilgili gerçekleşen süreler, testler ve kullanıcıya verilen eğitimler sırasında ölçülüp doğrulanabilir. Ayrıca ürünlerin garanti döneminde yapılan bakımlardan toplanan verilerden de sistemlere yapılan bakımların ortalama süreleri çıkarılabilir.

İdame edilebilirlik ile ilgili yüklenicilerin karşılaştığı ulaşım, erişim, bakım yapılamama, sökülememe gibi problemlerin incelenmesi açısından 3B model yazılımları ve bazı destekleyici yazılımlar kullanılabilir. Bu yazılımların kullanılmasının amacı zorlukla yapılabilecek bir bakım onarım faaliyetini geliştirme safhasında modeller üzerinden önceden kestirebilmektir.

Tasarıma etki ara yüzünün oluşturulması kapsamında başlangıç noktası olarak kullanılabilecek kontrol listesi aşağıda verilmiştir;

* Farklı tiplerdeki bağlantı elemanlarının toplam sayıları minimuma indirildi mi?
* Bağlantı elemanları standart aletler için olan gereksinimlere bağlı olarak mı seçildi?
* Ekipman yenisi ile değiştirilebilir kalemler olarak mı tanımlandı?
* Bir kalemin yenisi ile değiştirilmesi için gereken süre minimize edildi mi?
* Operasyonel çevre koşulları dikkate alındı mı?
* Yazılımın nasıl yükleneceği, yükleme süresi vb. parametreler dikkate alındı mı?

=== 6.2.4. TEST EDİLEBİLİRLİK ===
Test edilebilirlik, bir bileşenin durumunun (çalıştırılabilir, çalıştırılamaz ve düşük fonksiyonlu çalıştırılabilir) ve hataların/başarızılıkların lokasyonunun zamanında ve belirli bir güven seviyesinde belirlenebilmesini sağlayan bir tasarım özelliğidir.

Test edilebilirlik gereksinimlerini karşılayacak bir tasarım çözümü, ürüne entegre bir test sistemi ile veya destek kaynaklarının bir parçası olan ve hataların lokalizasyonu için ürünle arayüzü bulunan bir test sistemi ile sağlanabilir. İyi tasarlanmış test sistemleri, hataların/arızaların bulunması ve düzeltilmesi için harcanacak çabayı azaltacağı gibi sistemin işlevselliğini doğrulamak için de kullanılabilir.

Test edilebilirlik gereksinimlerinden dolayı yeniden tasarım yapmak çok karmaşık bir faaliyettir

Arıza fark etme/doğrulamanın detay seviyesi, uygulanabilir bakım konseptini etkileyen en önemli etken olduğundan test edilebilirlik özelliklerinin tasarım tamamlandıktan sonra belirlenmesi mümkün olmayacaktır. Bu nedenle, test edilebilirlik gereksinimleri uygulanabilir her kalem için tasarım ve geliştirme safhalarında tanımlanmalıdır. HTEA/HTEKA sonuçları test edilebilirlik gereksinimlerini nasıl etkilediği konusuna EK-B’de değinilmektedir.

Test edilebilirlik analiz faaliyeti LDA faaliyeti olmayıp, yapılacak diğer lojistik destek analizlerinde bu çalışmanın çıktıları doğrudan kullanılacaktır. Bu anlamda analiz sonuçları, hem LDA girdisi hem de tasarım girdisi olacaktır. Hata Tespit Oranı, Hata İzolasyon Oranı ve Süresi test edilebilirlik parametreleridir. Testedilebilirlik analizi ile, FMECA çıktıları kullanılarak hata tespiti ile hata izolasyonuna ilişkin veriler belirlenir.

* LDA girdisi; BGA’da belirlenen bir bakım görevi kapsamında bir kalemin test edilmesine ilişkin girdi sağlayacaktır.
* Tasarım girdisi; tasarıma etki kapsamında ise, arızalandığı durumda etki seviyesi yıkıcı olan bir donanıma test edilebilirlik özelliğinin kazandırılması, arıza sinyali olarak arıza mesajlarının tasarımına ve test ekipmanı gereksinimlerine girdi sağlanması örnek olarak verilebilir.

Tasarıma etki ara yüzünün oluşturulması kapsamında başlangıç noktası olarak kullanılabilecek kontrol listesi aşağıda verilmiştir;

* Uygulanabilir olan durumlar için birim içi test (self-test) durumu sağlandı mı?
* Birim içi test otomatik olarak mı yapılıyor?
* Doğrudan arıza göstergesi sağlandı mı (örneğin ışık yanması, uyarı çıkması gibi)?
* Kontrol ve hata izolasyonunu mümkün kılacak test ara yüzleri sağlandı mı?
* Test ara yüzleri erişilebilir mi?
* Test ara yüzleri fonksiyonel mi veya ardışık test yapmayı kolaylaştıracak şekilde mi?
* Test ara yüzleri yenisi ile değiştirilebilir kalemlerin doğrudan testini yapmaya olanak veriyor mu?
* Test noktaları gerekli olması halinde görsel olarak etiketlenmiş mi?
* Her ekipmanın işlev bozukluğu tespit edilebiliyor mu?
* Yazılım yeterli test bilgisini sağlıyor mu?

=== 6.2.5. PROGNOSTİK ===
Bazı ürün parametreleri ve verileri, bakım veya onarım ihtiyaçlarının kestirilmesine yönelik modellerde kullanılabilir. Prognostik, bir sisteme ilişkin ne zaman arıza oluşacağına dair kestirimde kullanmak üzere sistemin operasyonel durumuna dair veri toplanması ve analiz edilmesine izin veren bir tekniktir. Prognostik, test edilebilirliğin bir alt kümesi olarak düşünülebilir; ancak veri depolama ve anlık veri analizleri karmaşık olabilir, dolayısıyla genellikle kritik performans özelliklerine uygulanır.

Prognostiğin amacı, görev performansını sürdürebilmek için parçaları gerçekten arızalanmadan önce değiştirmek için optimum zamanı kestirmektir. Bileşenler özelinde ömrü, kullanım süresi, çevresel faktörler, benzer komponentlerin arızaları gibi bilgiler toplanır. Bu bilgiler daha sonra kestirimci modele veri olarak girilirse belirli bir komponentin ne zaman arızalanacağına yönelik bir tahmin oluşturulur.

Bakım/onarım prognostik işlevi, ürünün veya destek sisteminin bir parçası olarak tasarlanabilir.

Prognostiğin faydası, ürünün “sağlık” durumunun bilinmesi ve bu bilgiye dayanarak kritik arızalardan kaçınma ve sistemin işlevselselliğini idame edecek faaliyetleri planlayabilme olarak tanımlanabilir. Prognostik özellikleri olmayan bir sistemde, sistem ömrünü uzatmak için önleyici bakım kullanılır ve sistem emniyeti düzeltici bakım işlem ve kaynaklarına karşı dengelenmeye çalışılır.

Ancak, parçaların arızalanmadan önce değiştirilmeleri yararlı ömürlerinin bir kısmının kullanılamaması ile sonuçlanmaktadır. Ayrıca, prognostik ancak yeterli ve uygun verinin toplanabilmesi durumunda etkin olacaktır. Dolayısıyla, prognostik tekniği kullanılması kararı, geliştirme ve kullanım maliyetlerinin operasyon esnasındaki arızaların etki ve maliyetleri ile kıyaslanarak verilmelidir.

=== 6.2.6. STANDARTLAŞTIRMA ===
Genel olarak, özel tasarlanmış ekipmanlar yerine standart ekipman kullanımı daha maliyet etkindir. Gereksinimleri karşılayan mevcut bir parça veya sistem kullanıldığında geliştirme/ tasarım maliyeti ve süresi azalmaktadır.

Gereksinimleri karşılayan standartlaştırılmış ekipman kullanımı ile, mevcut lojistik destek kaynaklarının kullanımı da mümkün olabilir. Böylece destek sistemi kaynaklarının tasarım ve temini için yatırım ihtiyaçları azalır. Özel geliştirilmiş destek ekipmanı ihtiyacı ortaya çıkaran tasarım kararları, maliyeti artıracağı için dikkatle ele alınmalıdır.

Standartlaştırmanın diğer avantajı, ürün/sistem olgunluğu ve bilgisindeki artış ile operasyonel birimin hareket kabiliyetindeki artıştır.

Üründe kullanılan parçaların daha önce kullanıcı envanterinde kullanılıp kullanılmaması idame edilebilirlik açısından önemli rol oynar. Daha önce kullanıcının aşina olduğu sistemin aynısını veya bir benzerini yeni tasarımda kullanmak hem eğitimler hem ikmal hem de bakım personeli tecrübesinden faydalanabilme açısından faydalıdır.

Hali hazırda envanterde bulunan tüm sistemlerin tanıtıldığı ortak bir veri tabanı kullanılarak bir standartlaştırma yapılırsa veya yüklenici ve müşteri temsilcilerinin bulunduğu bir çalışma grubu ile envanterdeki benzer sistemler incelenirse aynı fonksiyon için tasarıma etki edilerek aynı veya benzer sistemlerin entegrasyonu sağlanabilir.

Standartlaştırmanın potansiyel faydalarını etkileyen faktörler aşağıda sıralanmıştır:

* Mevcut ekipmanların kullanımı, yeni destek kaynağı geliştirmede ortaya çıkacak geliştirme maliyetlerinden kaçınmayı sağlar,
* Yeni eğitim programı geliştirme maliyetlerinden kaçınılabilir,
* Destek kaynaklarının müşterekliği, destek kaynaklarının hazır olmasını artırırken lojistik hacmi azaltır,
* Standartlaştırılmış elemanların kullanımı destek kaynak gereksininmlerini belirlemek için gerekli geliştirme süresini kısaltır,
* Farklı ekipmanların kullanımı öğrenmek yerine aynı ekipmanın kullanımı söz konusu destek ve test ekipmanlarını kullanan personelin eğitim süresini azaltır ve personelin yetkinliğini artırır.

Standartlaştırma aynı zamanda değiştirilebilirliği de kapsar.

Yazılım tasarımı da örneğin programlama dilleri, bilgi yapıları veya yazılım ve bilgi taşıyan medya gibi konulara ilişkin standartlaştırma gereksinimlerinden etkilenebilir.

Standartlaştırmanın olası faydalarını gerçeğe dönüştürebilmek için ilgili gereksinimlerin tasarım faaliyetleri başlamadan önce belirlenmiş olması gerekir.

=== 6.2.7. BİRBİRİYLE DEĞİŞTİRİLEBİLİRLİK ===
Değiştirilebilirlik, performans ve dayanıklılık açısından eşdeğer işlevsel ve fiziksel karakteristiğe sahip olan iki veya daha fazla elemanın, kendileri veya bitişiklerindeki elemanlar üzerinde, ayarlama hariç tadilat gerektirmeden ve performans açısından seçim yapmadan, birbirleriyle değiştirilebilme kabiliyetine sahip olduğu durum olarak tanımlanır. Değiştirilebilirlik, benzer ekipmanlardaki parça veya komplelerin, tadilat veya fiziksel değişiklik gerektirmeden birbiri ile değiştirilebilme kabiliyeti olarak da adlandırılabilir.

Bir ürün tasarımının, uygun durumlarda ürünün kendi üzerinde veya ürünler arasında ekipman, komponent ve parçaların değiştirilebilirliğine olanak verecek şekilde gerçekleştirilmesi bir çok avantaj sağlayacaktır. Burada amaçlanan ekipman kullanımında esnekliği artırmak ve yedek parça stok seviyelerinde azalma sağlamaktır.

Değiştirilebilirlik, standartlaştırmanın sağlanmasında temel yöntemlerden birisidir. Standartlaştırma ile değiştirilebilirlik ilişkisine örnek olarak bir savunma ve güvenlik sisteminin gözetleme işinde kullanılan bataryanın başka bir sistem kapsamında da kullanılabilmesi verilebilir. Bu sayede batarya şarj cihazı da ortak olacağı için bir çok avantaj (tek bir bakım yönteminin olması gibi) sağlanacaktır.

Etkili olabilmesi için, değiştirilebilirlik ile ilgili gereksinimlerin tasarım faaliyetleri başlamadan tanımlanması gerekir.

=== 6.2.8. ÇEVRESEL HUSUSLAR ===
Bilinen operasyonel ve bakım çevresel koşulları ekipman ve tasarım çözümü tercihlerini etkileyebilir. Bakım ve operasyonu etkileyen parametrelere örnek olarak sıcaklık, nem, kumlu ve tuzlu ortamlar verilebilir. Ürün aynı zamanda ulaştırma, söküm, kurulum ve depolanması esnasında da gereksinimleri karşılamalıdır.

Bakım, iletim ve envanterden çıkarma için çevresel bir bakış açısıyla gerekli olan kimyasallar/malzemeler de önemlidir. Tehlikeli malzemelerin, tehlikeli atıkların ve çevresel kirleticilerin içerilmesinin sonuçlarının ürünle temas halinde bulunan personelin emniyeti ve ÖDM üzerinde etkisi vardır.

Çevresel etkilerin geliştirme safhasında göz önünde bulundurulması, sistemin kullanım, destek ve envanterden çıkarma safhalarında ortaya çıkabilecek sorunların önüne geçer. Bu nedenle çevresel hususların gereksinim olarak tanımlanması gerekmektedir.

Sistemin hangi çevresel koşullara maruz kalacağı bilgisi, sarf malzemelerinin (yağlar, yakıt vb.) seçiminde de göz önünde bulundurulması gereken hususlardandır.

=== 6.2.9. İNSAN FAKTÖRÜ/ERGONOMİ ===
İnsan faktörü mühendisliği, tasarıma etki kapsamında ele alınması gereken desteklenebilirlik mühendisliği fonksiyonlarından birisidir. Bu disiplin ile LDA süreci arasında sürekli bir ilişki ve entegrasyon söz konusudur.

İnsan faktörü/ergonomi ile ilgili olarak tasarım geri bildirimleri gereksinim olsun ya da olmasın üretilen sistemlerde insan-makine ara yüzü var ise göz önüne alınması gereken bir faktördür. İnsan faktörleri ve ergonomi ile ilgili kullanıcı makamı ve tedarik makamı yüklenicilere hangi istatistiksel antropometrik veri tabanını kullanarak sistem tasarımı yapılacağını bildirmelidir. Aksi halde sistem tasarımı çok geniş bir insan popülasyonunu kapsayacağından karmaşık hale gelebilir. Bu anlamda kullanıcı makamının karar vereceği bir antropometrik veri tabanının insan faktörleri ve ergonomi analizlerinde kullanılması önemlidir.

Bu analizler kapsamında, insan faktörü ve ergonomiye ilişkin ürün gereksinimleri belirlenmelidir. Ürün tasarımı operatör ve teknisyenler için erişilebilirlik hususlarını dikkate almalıdır.

Söküm takım faaliyetlerine ilişkin olarak erişilebilirliği analiz etmek için sanal araçlar veya başka yöntemler kullanılabilir. Konsept safhasından itibaren bakım ilişkili faaliyetleri simüle etmek maksadıyla bir takım ergonomi/simülasyon yazılımları kullanılabileceği gibi (Şekil 9), oluşturulan mock-up’lar üzerinden de analizler gerçekleştirilebilir. Böylelikle, tasarımın erken safhalarında bakım ve idame edilebilirliğe yönelik tedbirler (mühendislik değişimleri, bakım destek teçhizatı ihtiyacı tespitleri, bakım görev değişiklikleri vb.) alınarak tasarıma yön verilebilir.
[[Dosya:Şekil 9 Ergonomi-Simülasyon .jpg|sol|küçükresim|450x450pik|Şekil 9 Ergonomi/Simülasyon Yazılımlarından Örnek Görüntü]]

Bakım, operasyon ve envanterden çıkarmada ihtiyaç duyulan kimyasallar/malzemeler de insan faktörleri perspektifinden önem taşır. Tehlikeli madde veya çevre kirletici ihtiva etmenin personelin emniyeti ve destek kaynağı ihtiyaçlarına etkisi vardır.

Tasarıma etki ara yüzünün oluşturulması kapsamında başlangıç noktası olarak kullanılabilecek kontrol listesi aşağıda verilmiştir;

* Uygulanabilir olan alanlar için kapaklar sağlandı mı ve açılır kapanır mı?
* Açıklıkların boyut ve konumu erişim için yeterli mi?
* Etiketlemeler yapıldı mı? Etiketlerin kapsaması gereken bilgiler yeterli mi?
* Kapaklara erişim için gerekli bağlantılar minimize edildi mi?
* Herhangi bir araç olmadan erişim sağlanabiliyor mu?
* Erişim için alet gerekiyorsa, sayılar minimize edildi mi ve standart aletlerin kullanımı sağlanabiliyor mu?
* Modüller ve komponentler arası erişim uygun mu?
* Tehlikeli malzemeler tanımlandı mı ve minimize edildi mi?
* Bir bakım görevini yerine getirirken koruyucu ekipman kullanmak gerekiyor mu? (Bu cevap BGA kaynak gereksinimlerine girdi olacaktır).
* Erişim gereksinimleri bakım sıklıkları ile uyumlu mu?

İnsan faktörleri ve ergonomi ile ilgili olarak MIL-HDBK 1472 ve DEF STAN-00-25 standartları referans olarak alınabilir.

İnsan faktörleri kapsamında gereksinimlerin tanımlanması ve bu gereksinimlerin lojistik açıdan da değerlendirilmesi gerekmektedir. İlave gereksinim tanımlama ihtiyacı ortaya çıkarsa sistem gereksinimlerine lojistik gereksinim olarak eklenmelidir. Örneğin, sistemin çalışma sıcaklığının 60 oC olduğu durum için sistem çevresel gereksinimleri kapsamında gereksinim tanımlanmış olabilir ancak sistemi doğrudan personel kullanacaksa sıcaklığa karşı koruyucu ekipmanla ilgili lojistik gereksinimi ya da personelin temas edeceği yüzeylerle ilgili alınacak tasarım önlemine ilişkin gereksinimin de tanımlanması gerekmektedir. Diğer taraftan insan faktörleri analizi ile ortaya çıkan sonuçların BGA kapsamında da uygulanması gerekmektedir. Örneğin, limitin aşıldığı bir bakım görevi varsa, ek bakımcılar, taşıma kolları eklenebilir ya da kalemin ağırlık yada boyutları kişi kaldırma limitlerini aşıyorsa ilgili bakım görevi için mekanik olarak taşıma tanımlanabilir.

=== 6.2.10. DEMODELİK ===
Ürünün ömür devrinin uzunluğuna bağlı olarak, muhtemel demodelik durumlarının geliştirme safhasında ele alınması önemlidir. Demodelik sorunu, kullanıcı makamına teslim edilen sistemin önleyici veya düzeltici bakımı için yedek parça, sarf malzemesi veya ikmalde zafiyet oluşması ile ortaya çıkar.

Demodelik sorunları ortaya çıkmadan önce (proaktif yaklaşım) veya çıktığı durumlarda (reaktif yaklaşım) sistemin işlevselliğini koruyabilmek için eyleme geçmek gerekli olacaktır. Bu durumda alınabilecek tipik kararlar yeniden tasarım/modifikasyon, ömürlük satın alma veya sistemin hurdaya ayrılarak yeni bir sistemin devreye alınması vb’dir. Bu nedenle, bir sistemin tasarımı esnasında veya belli bir tasarıma uygun sistem veya alt sistem seçimlerinde, demodelik sebebiyle gelecekte bazı elemanların değiştirilme ihtimalini akılda tutmak gerekir.

Demodeliği doğru yöneterek yüksek maliyetlerden kaçınmak mümkündür.

Demodelik yönetiminde amaç, sistemin demodeliği oluşmadan uyarı veren bir sistem kurmak, böylelikle demodelik oluştuğundaki yüksek maliyetlerden ve kullanıma hazır olma oranının düşmesinden kaçınmaktır.

Teknolojik eskimeye ise genellikle modernizasyonlar ile çözüm bulunmaktadır.

Sistemin tasarımı yapılırken teknolojik, ekonomik, siyasi vb. öngörülerde bulunularak uzun yıllar ikmal sorunu yaşanmayacak sistemleri veya parçaları tercih etmek ileride oluşabilecek ikmal problemlerinin önüne geçecektir (Detaylı bilgi için Bkz. [https://tssodypwiki.ssb.gov.tr/index.php/Sistem_%C3%96m%C3%BCr_Devri_Y%C3%B6netiminde_Demodelik_Y%C3%B6netimi_Rehberi TSSÖDYP-08 Sistem Ömür Devri Yönetiminde Demodelik Yönetimi Rehberi]).

=== 6.2.11. DESTEKLENEBİLİRLİK ===
Desteklenebilirlik, bir ürünün kullanılabilmesi ve idame edilebilmesi için gerekli olan bütün kaynakların yeterli miktarda sağlanma derecesine dair bir ölçüttür. Desteklenebilirlik sadece ürün değil bütün lojistik destek kaynaklarını (teknik dokümantasyon, destek ekipmanı, yedek parça, personel vb.) kapsar.

Sistem tasarımı esnasında, idame edilebilirlik ve güvenilirlik hususları dikkate alınarak sistemi desteklemek için ihtiyaç duyulacak kaynakların miktarı azaltılabilir. Aktif bakım süreleri ile lojistik ve idari gecikmelerin toplamından oluşan kullanım dışı kalma süresi (downtime) bu şekilde azaltılabilir. Daha çok destek kaynağına ihtiyaç duyan bir sistem bu kaynaklarda yaşanacak sıkıntı ve bekleme risklerine daha çok maruz kalacaktır.

=== 6.2.12. MALİYET ETKİNLİK ===
ELD’nin ve aynı zamanda LDA’nın en önemli konularından bir diğeri maliyet etkinliktir. Maliyet etkinlik, sistemin maliyet ve sistem etkinliği hedefleri ile destek maliyetleri üzerinde birbiri ile ilişkili etkileri bakımından alternatiflerin (faaliyetler, yöntemler, yaklaşımlar, silah sistemleri, destek sistemleri, vb) analizinden türetilen karşılaştırmalı bir değerlendirmedir.

Tasarım ve tasarım ilişkili kararların ÖDM üzerinde önemli etkisi vardır. Alternatif tasarım çözümleri arasında, destek kaynaklarını da içeren karşılaştırmalı analizlerin yapılması gereklidir. Maliyet etkinlik bu anlamda kullanıma hazır olma karakteristiği ile ÖDM’nin dengelenmesidir.

Desteklenebilir sistemlerin maliyet etkin bir şekilde işletme ve idamesi için her alanda tasarım iyileştirmesi yapılabilir. Örnek olarak idame edilebilirlik kapsamında yapılan tasarım geri bildirimleri ile bakım onarım süreleri azaltılarak maliyet etkinlik bir açıdan sağlanmış olur.

Ayrıca sistemin ÖDM analizi yapılarak analizde çıkan yüksek maliyet kalemlerine odaklanmak suretiyle kullanım ve destek maliyetlerinin düşürülmesi hedeflenir.

=== 6.2.13. YAZILIM TASARIMI ===
Yazılım tasarımı; ürün tasarımlarının ayrılmaz bir parçasıdır. Yazılım tasarımı, bu bölümde daha önce tanımlanan bazı özellikleri kazandırabilmek üzere hassasiyetle ele alınması gereken bir konudur.

EK-H’de tanımlanan yazılım destek faaliyetlerinin sonuçları dikkate alındığında, sistemin kullanıma hazır olma gereksinimini karşılamak üzere yazılımın nasıl tasarlanacağı ve gerçekleştirileceğine dair bazı kararlar alınması gerekmektedir.

== 6.3. TASARIMA ETKİ ==
LDA’nın genel hedefleri tasarımı etkilemek, en etkin destek konseptini oluşturmak ve lojistik destek kaynak gereksinimlerini belirlemektir. Tasarımda serbest hareket edebilme özgürlüğü (esneklik) ve tasarımı etkileme fırsatları program/proje türlerine göre değişmektedir. Bu durum strateji belirlerken temel girdiyi oluşturur.

Geliştime programlarının yapısı aşağıdaki şekilde çeşitlilik gösterebilir:

* Savunma ve güvenlik sistemi ve destek ürünlerinin en baştan geliştirildiği yeni geliştirme programları
* Mevcut bir ürün için sistem/alt sistem tasarım değişiklikleri/iyileştirmeler
* İhtiyaç makamı/kullanıcı veya bir tedarikçi tarafından yürütülen ve mevcut teknolojiyi kullanan hızlandırılmış geliştirme programları

Dolayısıyla bir geliştirme programındaki tasarım esnekliği ve olası tasarım etkisi derecesi değişkendir. Genellikle, bir geliştirme programı, birden fazla değişik yapının bir kombinasyonudur. LDA faaliyetleri ve hedefleri de buna uygun şekilde odaklanmalıdır. Ayrıca, bir programda destek sistemi için tasarım esnekliği söz konusu iken ürün için bu esneklik daha az olabilir veya tersi durum da söz konusu olabilir.

Tasarımcılar, tasarım faaliyetlerinin başlangıcından itibaren güvenilirlik, idame edilebilirlik, kullanıma hazır olma ve desteklenebilirlik hedeflerine yönelmiş olmalıdırlar.

Diğer taraftan, alt yüklenici tarafından gerçekleştirilen tasarım faaliyetleri de kurum içi tasarım gibi ele alınmalıdır. Tasarım faaliyetleri daha başlamadan tasarımı etkileyebilmek üzere alt yükleniciye özel LDA hedefleri ve gereksinimlerinin sağlanması, detaylı takvimlerin oluşturulması gerekmektedir. LDA gereksinimlerinin gözden geçirilmesi ve değerlendirilmesi de proje kapsamında gerçekleştirilen gözden geçirme toplantılarının gündemine dahil edilmelidir. Altyüklenici ve tedarikçileri dahil eden, “aşağıdan yukarıya” gözden geçirmeler de uygulanabilir olduğu ölçüde planlanmalıdır.

Desteklenebilirliği belirleyen tanılama özellikleri, arayüzler, güvenilirlik tahminleri, demodelik değerlendirmeleri, bileşen işlevleri gibi teknik tasarım bilgileri tasarım dokümantasyonun parçası olmalıdır.

Gözden geçirmelerde gündeme alınabilecek bazı konular aşağıda belirtilmiştir:

* LDA’nın iş dağılım ağacına göre yürütülmesi,
* Önerilen tasarım özelliklerinin desteklenebilirliği, maliyeti, kullanıma hazır olmayı ve yeni veya kritik destek kaynakları gereksinimlerini içerecek şekilde LDA açısından değerlendirilmesi,
* Karşılaşılan, önerilen, alınan düzeltici faaliyetler (değerlendirmedeki destek alternatifleri, değerlendirme ve ödünleşim analiz sonuçları, varolan ürünlerle yapılan karşılaştırmalı analiz, önerilen veya alınan tasarım yada yeniden tasarım eylemleri vb.),
* LDA gereksinimlerinin gözden geçirilmesi,
* Hedef belirleme veya ulaşma yolundaki ilerleme,
* Gerekli, tamamlanan, planlanan LDA dokümantasyonu,
* LDA’yı etkileyen tasarım, planlama, konfigürasyon değişiklikleri ve analiz problemleri.

= 7. KULLANIM ve DESTEK SAFHALARINDA LOJİSTİK DESTEK ANALİZLERİ =
Ürün Ömür Devrinin ilk safhalarında, LDA metodolojisi kullanılarak geliştirilen destek faaliyetleri, ürüne ait kapasite ve kullanım gereksinimlerinin karşılandığını, ömür devri maliyetlerinin optimize edildiğini ve ürünün sürdürülebilir olduğunu garanti eder. Kullanım safhası süresince ise bir ürünün bakım ve çalışabilirliğinin sürekliliğini sağlamak için; kullanıcıdan alınan geribildirim verilerinin analiz edilerek, ilk varsayımlar ile gerçek kullanıma ait deneyim ve verilerin karşılaştırılması, uygulanacak olan destek faaliyetlerinin izlenmesi, değerlendirilmesi ve gerekmesi halinde güncellenmesi ve/veya uyarlanması faaliyetleri yürütülecektir.

Kullanım safhası LDA, ürün ömür devri faaliyetlerinin vazgeçilmez bir parçasıdır. Ürün kullanıma alındıktan sonra, ilgili hizmet içi veriler toplanmalı ve tanımlanmış destek gereksinimlerine karşı analiz edilmelidir. Destek gereksinimleri ürün ömür devri boyunca ihtiyaca göre değişiklik gösterebilmektedir. Bu nedenle, LDA metodolojisi uygun şekilde güncellenerek ürün destek gereksinimlerine yönelik çözüm ve önerilerin sürekli iyileştirilmesi sağlanmalıdır.

Bu aktiviteler neticesinde, destek çözüm ve önerileri:

Kullanım dönemi LDA faaliyetlerinin olumlu etkileri arasında aşağıdakiler sayılabilir:

* Ürün kullanılabilirliğinin arttırılması
* Ürünü desteklemek için gerekli kaynakların gerçek kullanım dönemi ile uyumlulaştırılması ve gerekli olması halinde iyileştirilmesi
* Modifikasyonlar ile ürünün geliştirilmesi
* Lojistik hacmin azaltılması
* Lojistik destek maliyetinin düşürülmesi

Kullanım dönemi safhasında LDA faaliyetlerinin uygulanması hem kullanıcı hem de yüklenici için bir kazan-kazan yaklaşımı oluşturmaktadır çünkü:

* Yüklenici, fiili ürün kullanımı hakkında bilgi alma ve ürün destek hususlarını öngörme noktalarında daha iyi bir pozisyona sahip olmakta ve destek sorunlarının çözümünde etkinliği arttıracak yeteneklerini geliştirmektedir.
* Kullanıcı ise, yüklenicinin ürün desteklenebilirliği ve destek sistemi verimliliğine getirdiği sürekli iyileştirmelerden faydalanarak ihtiyacının sürekli olarak sağlanması durumuna sahip olabilmektedir.

Kullanım dönemi LDA aktivitelerinin derinliği ve kapsamı yaşanacak değişikliklerin ölçeğine bağlı olacaktır. Bu değişiklikler aşağıdakilerden kaynaklanabilir:

* Ürün değişiklikleri ve yarı-ömür güncellemeleri (Bazen ‘teknoloji ekleme’ olarak da adlandırılır); bu seçenek, sistemin tümü ya da bazı bölümlerinde gerçekleştirilecek tasarım güncellemelerinin ve yenilemelerin, uygulanabilir olması durumunda ürün ömrü boyunca hangi noktalarda yapılacağının önceden kararlaştırılmasını gerektirir.
* Operasyonel ve çevresel gereksinim değişiklikleri veya operasyonel ve çevresel koşullardaki değişiklikler; bu değişiklikler, verilen destek üzerindeki etkilerin belirlenmesi için değerlendirilmelidir. Gerekli görülen analiz tekrarları sonucunda ürün veya destek çözümünde de değişiklikler gerekebilir.
* Mevzuat değişiklikleri; eğer değişiklikler ürün ile alakalı ise verilen destek çözümü üzerindeki etkileri değerlendirilmelidir.

Kullanım safhası LDA süreci genel hatlarıyla Şekil 10‘da verilmiştir.
[[Dosya:Şekil10 Kullanım Safhası LDA Süreci.jpg|alt=|sol|küçükresim|600x600pik|Şekil 10 Kullanım Safhası LDA Süreci]]

Kullanım ve Destek safhalarında LDA, kullanıcının teknik, lojistik ve ekonomik gereksinimlerine uyumluluğu sağlamak için ürün destek kaynaklarını – gerektiğinde – incelemeyi amaçlar. Bu incelemeler aşağıdaki nedenlerden dolayı tetiklenebilir:

* Elde edilen ve tahmin edilen sonuçlar arasında tutarsızlık olması
* Kullanıcı talebini karşılamak ya da harici kurallar ve mevzuata uyumlu olmak için üründe modifikasyon ve değişiklik yapılması
* Kullanım ve destek geri bildiriminin, risk ve fırsat yönetimini destekleyen genel sürecin bir parçası olarak dikkate alınıp optimizasyon alanlarının aranması

Kullanım dönemi boyunca birkaç LDA tekrarı yapılabileceği için LDA faaliyetlerinin sonunda bir Konfigürasyon Yönetimi (KY) sürecinin işletilmesi hayati önem taşır. Bu, kapsamlı bir konfigürasyon kontrolü, muhasebe ve denetim içerir. Buna ek olarak, kullanım dönemi LDA, ürünün hizmete girişinde hazır bulunması gereken bir kullanım ve bakım geri bildirim sistemine de ihtiyaç duyacaktır.
=== 7.1.1. KULLANIM VE DESTEK SAFHASI VERİ ANALİZİ VE LDA ===
Ürünle ilgili kullanım ve destek safhalarında herhangi bir konfigürasyon değişikliği, durumununda etki analizinin gerçekleştirilmesi ve bu değişikliklerin idame edilen ürünlerde, değişiklik yönetimi ve sapmaların sahadaki birimlere uygulanmasının planlaması ve yönetimi önem arz eden konuların başında gelir.

Kullanım ve destek safhalarında öne çıkan konfigürasyon yönetimi faaliyeti yüklenici tarafından desteklenen her bir ünitenin destek varlıklarının (destek ekipmanları, test program setleri, eğitim dokümanları ve yardımcı malzemeleri, el kitapları ve yazılımlar) konfigürasyon bilgilerinin takip edilebilirliğinin sağlanmasıdır. Eğer bu kalemlerde herhangi bir değişiklik varsa bu değişiklik, sapma ve feragat önerilerinde (MDT) değişen konfigürasyon bilgilerinden dolayı değişmesi muhtemel destek unsurları ve ELD elemanlarının (kullanıcı el kitapları, bakım kitapları, bakım araçları, tamir kitleri, yedek parçalar vb.) değişiklikten nasıl etkileneceği detaylı bir şekilde tanımlanmalıdır.

Sistemin envantere girmesiyle birlikte sistemin kullanım verilerinin toplanması önemli olacaktır. Destek kaynaklarının gerçek kullanımdaki durumları (bakım ihtiyaçları, eğitim yeterlilik durumu, yedek parça ihtiyaç durumu vb.) ve sistem performansının izlenmesi için bu verilerin toplanarak gerekli değerlendirmelerin yapılması gerekmektedir. Kullanım ve destek safhaları kapsamında toplanan veriler, güvenilirlik ve bakım yapılabilirlik gereksinimleri ile ilgili olarak kullanım başarısının ne olduğuna karar vermeyi ve destek çözümünün eksikliklerinin belirlenmesini mümkün kılacaktır. Bu verilerin analiz edilmesi, eksikliklerin sebebinin anlaşılmasını ve uygun çözümlerin geliştirilmesini sağlayacaktır. Hizmet içi kullanım döneminde toplanan kullanım verileri ile daha önceden yapılmış olan lojistik destek analiz faaliyetlerinin bir kısmının ya da tamamının tekrarlanması gerekebilir.

Tekrarlanması gereken lojistik destek analiz faaliyetlerinin hangileri olduğu ve tekrarlanacak olanların da kapsamı ve detay seviyesi aşağıda örnek olarak verilen değişikliklere bağlı olacaktır;

* Ürün modifikasyonları ve yarı ömür güncellemesi (eskimiş ya da demode olmuş kalemlerin değiştirilmesi de dahil edilebilir)
* Operasyonel ya da çevresel gereksinimlerin değişmesi durumunda bunun sağlanan destek üzerine etkilerinin değerlendirilmesi gerekir. Bu değerlendirme sonucunda, tekrar yapılması gereken analizler ve dolayısıyla destek çözümü ile ilgili değişiklikler ortaya çıkabilir.
* Kullanım esnasında, tasarım ve geliştirme döneminde yapılan analiz sonuçları ile kullanım esnasında ortaya çıkan durumlar arasında tutarsızlıklar varsa, ilgili analizlerin tekrar gözden geçirilmesi gerekebilir.
* Kullanım ve destek geri bildirimlerinin dikkate alınmasıyla optimizasyon alanları araştırılabilir ve buna bağlı olarak gerekli olduğu düşünülen LDA faaliyetleri de tekrar gözden geçirilebilir.
* Kullanıma hazır olma, yedek parça sayıları gibi tasarım güvenilirlik değerlerine göre yapılan hesaplamaların, operasyonel ortam koşullarındaki mevcut durumu yansıtacak şekilde güncellenmeleri gerekmektedir.

Şekil 11’de kullanım ve destek safhaları bakım gözden geçirme süreci verilmiştir.
[[Dosya:Şekil 11 Kullanım ve Destek Safhası* Bakım Gözden Geçirme Süreci.jpg|alt=|sol|küçükresim|700x700pik|Şekil 11 Kullanım ve Destek Safhası* Bakım Gözden Geçirme Süreci]]

<nowiki>*</nowiki>Destek safhası, destek planlama ve destek uygulama olmak üzere iki aşamadan oluşmaktadır. Bu süreçte destek uygulama aşaması kastedilmektedir.

=== 7.1.2. MODİFİKASYON VE DEĞİŞİKLİK UYGULAMASI İÇİN KULLANIM SAFHASI LDA ===
LDA faaliyetlerine olan ihtiyaç, tasarlanan ürünün Kullanım ve Destek Safhası’nın başlamasıyla birlikte son bulmamaktadır. Bir ürüne ait en uzun safha olan Kullanım ve Destek Safhası süresince, ürün konfigürasyonunda yapılacak modifikasyonlardan dolayı LDA faaliyetlerinin ihtiyaç duyulan derinlikte tekrar icra edilmesi ve modifikasyonlardan önce üretilmiş olan verilerin güncellenmesi veya bazı faaliyetlerin baştan yapılması gerekebilir. Bu nedenle LDA faaliyetleri boyunca üretilen verilerin ve analiz faaliyetleri süresince alınan kararların, ürünün envanterden çıkarılması safhasına kadar kayıt altında tutulması ve güncelliğinin sağlanması gerekmektedir.

Sürece ilişkin örnek Şekil 12’de verilmiştir.
[[Dosya:TSSODYP06.12.jpg|alt=|sol|küçükresim|615x615pik|Şekil 12 Modifikasyon ve Değişiklik Uygulaması İçin Kullanım Safhası LDA]]

=== 7.1.3. KULLANIM VE DESTEK SAFHALARI MALZEME YÖNETİMİ ===
Kullanım ve destek safhaları boyunca ürünler üzerinde güvenilirliği ve/veya performansı iyileştirmek, bir sistem elemanını/ekipmanı millileştirmek, vb. amaçlarla çeşitli modifikasyonlar yapılabilir. Müşteri’nin, ikmal desteğini planlayabilmesi ve tedarik süreçlerini yönetebilmesi için ürün konfigürasyonunda yapılan bu modifikasyonların konfigürasyon yönetimi faaliyeti kapsamında işlem görmesi ve ilgili veri kayıtlarının güncellenmesi gerekmektedir.

Kullanım ve destek safhaları süreci malzeme yönetimi süreci Şekil-13’te verilmiştir.
[[Dosya:Şekil13 Kullanım ve Destek Safhaları Malzeme Yönetimi Süreci.jpg|alt=|sol|küçükresim|700x700pik|Şekil 13 Kullanım ve Destek Safhaları Malzeme Yönetimi Süreci]]

= 8. LDA VE KONFİGÜRASYON YÖNETİMİ =
Konfigürasyon Yönetimi (KY), farklı ürün konfigürasyonlarının doğru belirlenmesi, değişikliklerin kontrol edilmesi ve değişikliklerin uygulanma durumunun kayıt altına alınmasını sağlayan bir disiplindir.

KY, ürün ağacının en alt seviyesinden başlayarak gerçekleştirilir ve istenilen, tasarlanan, üretilen, desteklenen ürün bilgisini belirlerken değişikliklerin teknik ve operasyonel performansının yanı sıra ELD faaliyetleri üzerindeki etkilerini de değerlendirir.

== 8.1. LDA SÜRECİNDE KONFİGÜRASYON YÖNETİMİ ==
LDA faaliyetlerinin çıktıları, bir projenin KY süreçlerine dahil olmalıdır. KY sürecinin ana unsurlarından birisi ürün kırılımının oluşturulmasıdır. Ürünün konfigürasyonunu tanımlamak için oluşturulan kurallar ürün kırılımının ELD dahil bütün proje alanlarında izlenebilirliğini sağlamalıdır.

Belirlenen kurallara göre geliştirilen ürün kırılımı, ilgili ürünün farklı konfigürasyonlarını da kapsayıcı özellikte olmalıdır. Ürün kırılımının, ELD’nin tüm alanları için temel olacak şekilde oluşturulması oldukça önemlidir.

Projede farklı amaçlara yönelik farklı ürün kırılımları oluşturulabilir. Genel olarak çoğu projede ürünün tasarım kırılımı bir veri yönetim sistemi altında kontrol edilir. Aynı ürün için bir LDA kırılımı oluşturulabileceği gibi operasyonel ve bakım verilerinin geri beslemelerine yönelik ayrı bir kırılım da oluşturulabilir. Farklı amaçlar için farklı kırılımlar oluşturulması, çoğu zaman bu kırılımlar arasında tutarsızlıkların oluşmasına ve farklı disiplinler arasında ürün ilişkili verilerin iletilmesinde sorunlara yol açmaktadır. Bu nedenle proje kapsamında yürütülen konfigürasyon faaliyetleri ile izlenebilirliğin kurulması ve kayıt altına alınması önemlidir (Bkz. [https://tssodypwiki.ssb.gov.tr/index.php/Sistem_%C3%96m%C3%BCr_Devri_Y%C3%B6netiminde_Konfig%C3%BCrasyon_Y%C3%B6netimi_Rehberi TSSÖDYP-11 Sistem Ömür Devri Yönetiminde Konfigürasyon Yönetimi]).

= 9. LOJİSTİK YÖNETİM VE LDA İLİŞKİSİ =

== 9.1. LOJİSTİK DESTEK ANALİZ KAYITLARI (LDAK) ==
LDA süreci sonunda ortaya çıkan veriler mühendislik ve ürün destek faaliyetleri tarafından kullanımlarını geliştirmek için belirli biçimlere uyarlanır ve kayıt altına alınırlar. Bu veriye lojistik yönetim bilgisi adı verilir ve çeşitli endüstri standartlarına uygun olarak oluşturulan veri tabanı da Lojistik Destek Analiz Kayıtları (LDAK) olarak adlandırılır.

Sözleşmelerde yer verilen LDAK gereksinimleri planlanan destek konsepti ile uyumlu ve uyarlanmış içerikte olmalıdır. Müşteri uyumsuzlukları ve gerekenden fazla olabilecek sözleşmesel teslimatları önleyebilmek için programın çeşitli işlevsel alanlarından gelecek verilere yönelik gereksinimleri koordine etmelidir. LDAK, nihayetinde bütün ELD unsurlarını dikkate alan etkin bir ürün destek paketi oluşturulmasında yardımcı olur.

Bir LDA veri tabanı içerisinde genel olarak aşağıdaki başlıklara yönelik veriler kayıt altına alınır:

* İşlevsel Gereksinimler
* Operasyonlar ve Bakım
* Güvenilirlik gereksinimleri ve analizlerin sonuçları
* Görev analizleri
* Personel becerileri ve eğitim
* Destek ekipmanları
* Test Altındaki Birim
* Tesisler
* Taşınabilirlik
* Tedarik ve kataloglama verileri

Bir projede lojistik yönetim verisi olarak nelerin kayıt altına alınacağı ve LDA sonrası oluşturulacak dokümantasyon, projeye özel olarak ve ürünün ömür devri safhasına göre uyarlanmalıdır. LDAK’ın uyarlanması analizler için seçilen standart, gerçekleştirilmek üzere seçilen analizler ve bunların derinliği konusunda verilen kararlarla uyumlu olmalıdır. Uyarlama LDAK için referans alınacak standardı/spesifikasyonu, ihtiyaç duyulan veri elemanlarını ve formatını, tercih edilen veri transfer ve/veya raporlandırma yönetmini de kapsamalıdır.

== 9.2. LDAK STANDARTLARI/SPESİFİKASYONLARI ==
LDAK kayıtlarına yönelik standartlar, bir sistem veya nihai ürünün geliştirilmesi veya tedarik edilmesi esnasında üretilen lojistik destek analiz bilgilerini tanımlar. Bu konuda geliştirilen standartlar genel olarak ELD programını desteklemek için gerekli olan teknik verilerin oluşturulması, idamesi, temini ve kullanımında maliyet etkinliği sağlamaya yöneliktir.

LDAK’a yönelik yaygın olarak bilinen standart Amerika Savunma Bakanlığı tarafından 1991’de yayımlanan MIL-STD-1388-2B’dir. Standardın amacı, LDA Kayıtlarının geliştirilmesi ve teslimatına yönelik bir örnek gereksinimleri ortaya koymaktır. MIL-STD-1388-1A’da tanımlı olan lojistik destek analizlerden uygulanabilir olanlarının gerçekleştirilmesi sonrasında ortaya çıkan bilgilerin kayıt altına alınmasını düzenler. Standart içerisinde yer alan veri elemanı tanımları (data item definition) üretilecek verilerin tanımı ve biçimini belirleyerek standardizasyonunu sağlar. MIL-STD 1388-2B, 1996 yılında iptal edilmiş olmasına rağmen günümüzde halen bazı projelerde kullanımı devam etmektedir.

MIL-HDBK-502, Tedarik Lojistiği kılavuzudur. Plan ve program ilkelerini ortaya koyan MIL-STD-1388-1A kılavuzuna benzerdir. Bir anlamda, MIL-STD 1388 1A gelişerek MIL-HDBK-502’ye dönüşmüştür. MIL-PRF-49506 (Lojistik Yönetim Bilgisi) lojistik destek tanımlarıdır ve MIL-STD-1388 2B’nin yerini almıştır. Lojistik kayıtlarının “neler” olması gerektiğini değil de “nasıl” tutulması gerektiğini tarif etmeye çalışır. Gene de MIL-STD 1388-2B başlıklarının yaklaşık üçte birini kullanır. Aynı şekilde; MIL-STD 1388-2B gelişerek MIL-PRF-49506’ya dönüşmüştür.

SAE Lojistik Komitesi’nin yayımladığı GEIA-STD-0007 standardı ise; XML kullanılmasını, verilerin ve bunlarla yapılan işlemlerin, karakter tahdidi olmaksızın saklanmasını sağlar. MIL-STD 1388-2B’de yer alan başlıklar aynen korunur ancak, bu standardın vurguladığı nokta ilişkisel veri tabanlarında olduğu gibi verinin nasıl kaydedileceğinden ziyade nasıl transfer edileceğidir (örn., XML şemaları). Amerika’da yaygın olarak kullanılan standart artık GEIA-STD-0007’dir.

Yukarıdaki standartlara ek olarak AeroSpace and Defence Industries Association of Europe (ASD) bünyesinde geliştirilmekte olan S-Serisi spesifikasyonları arasında hem LDA süreçlerinin hem de LDAK yapısının tanımlandığı ASD/AIA S3000L spesifikasyonu vardır. S3000L’de yer alan veri yapıları da GEIA’da olduğu gibi XML formatındadır.

LDAK konusunda dikkate alınması gereken önemli bir nokta, standartların herhangi bir programda ihtiyaç duyulabilecek her türlü veri elemanını tanımlamaya yönelik oldukları, bu nedenle belli bir projede nasıl kullanılacaklarına özellikle dikkat edilmesi gerektiğidir. Standartlarda yer alan veri elemanı tanımlarının yaklaşık %15-20 kadarı tek bir projede gerçekten uygulanabilir olmaktadır.

== 9.3. ORTAK KAYNAK VERİ TABANI ==

* LDAP’da tanımlanan faaliyetler, belirlenen aday kalemler üzerinde uygulandıkça, ortaya o aday kalemlerin sahip olduğu özelliklerle ve birbirleri ile ilişki içinde olan pek cok bilgi çıkmaya başlar (örn., bir pompanın hata türleri, hata türünü gidermek için uygulanması gereken bakım/onarım faaliyeti, bakımda ihtiyaç duyulan yedek parçalar, bu yedek parçaların paketleme bilgileri, vb.). Bu bilgiler yapısal bir veri tabanı, yani ilişkili veriler arasındaki bağlantıların ve referansların tanımlanabildiği bir veri tabanı uygulaması içinde kayıt altına alınabilir. Bu sayede ürünün tüm ömür devri boyunca yaşayacağı değişimler de düşünüldüğünde ürüne ait LDA kayıtlarının yönetimi, tutarlılığı, revizyon takibi gibi konularda ciddi kazanımlar elde edilebilir. Bu özellikleri taşıyan veri yapıları/standartları, 9.2 numaralı konu başlığında yer almaktadır.

* LDA kayıtlarının tutulacağı bir veri tabanı uygulaması hem ihtiyaç makamı hem de yükleniciler açısından projenin kapsam ve türü, ürünün karmaşıklığı, LDA verilerinin miktarı vb. parametrelere göre bir ihtiyaç olabilir. Bu ihtiyaç, LDA faaliyetlerinin ürünün tüm ömür devri süresince devam eden canlı faaliyetler olmasından kaynaklanmaktadır. Ana Yükleniciler ve alt yükleniciler LDA faaliyetlerinde çoğunlukla tasarım ve test verilerini kullanarak, ürünün envantere girdiği andan itibaren ihtiyaç duyulacak lojistik verileri geliştirirler. İhtiyaç Makamı ise tasarım ve test verileri yerine saha verilerini kullanarak Ana Yüklenici’den temin ettikleri LDA kayıtlarını idame ederler ve gerekli hallerde güncellerler veya güncellenmesi için yüklenici ile görüşürler. Ana Yüklenici ve İhtiyaç Makamı arasında LDA kayıtlarının transfer edilebilmesi için her iki kurumun kullandığı veri tabanı uygulamasının da aynı standart veri yapısını desteklemesi gerekmektedir. Aksi takdirde iki farklı veri yapısını birbirine dönüştürebilecek bir diğer yazılıma daha ihtiyaç duyulacaktır.

== 9.4. VERİ TÜRLERİ VE SEÇİMİ ==
Bir projede hangi verilerin üretileceği yüklenici ve ihtiyaç makamı’nın birlikte yapacağı bir çalışma ile LDAP’da tanımlanan LDA faaliyetleri, faaliyetlere ait kural ve varsayımlar, bu faaliyetlerin derinliği, uygulanacak LDAK standardı ve aday kalem listesi göz önünde bulundurularak belirlenmelidir. LDA kayıtlarının yönetiminde ürünün ömür devri süresince hem müşterinin hem de yüklenici’nin rol ve sorumlulukları olduğundan dolayı, ortak bir çalışma yürütülmesinde fayda vardır. Bu verilerin projenin hangi safhalarında üretileceği, hangi sıklıkla paylaşılacağı/transfer edileceği ve yayınlanacağı ise LDA zaman planına göre belirlenmelidir.

== 9.5. VERİ SINIFLANDIRMASI ==

=== 9.5.1. MÜŞTERİ TARAFINDAN SAĞLANAN VERİLER ===
Müşteri, ürünü geliştiren/temin eden firmanın ulaşması gereken hedef değerleri tanımlamalıdır. Bu değerler, İhtiyaç makamının/kullanıcının operasyonel gereksinimlerine, hali hazırda kullanılmakta olan benzer sistemlerin lojistik verilerine ve lojistik operasyonlarının yarattığı maliyetlerin bir arada değerlendirilmesiyle belirlenebilir. Örneğin 20 tankın görevlendirildiği bir operasyonda operasyonun başarıyla tamamlanabilmesi için 18 tank yeterli oluyorsa, tedarik edilecek tankın hedef güvenilirliğinin kabaca %90 olduğu söylenebilir veya bir alt sistemin erişim kolaylığını tanımlamakta hedef bakım süreleri tanımlanarak ilgili alt sistemin kolay sökülebileceği bir tasarıma gidilmesi sağlanabilir. İhtiyaç Makamı/Tedarik Makamı’nın sağlayacağı veriler rasyonel ve ölçülebilir olmalıdır. Bu verilerin bir kısmının belirlenmesinde yüklenici ve müşteri birlikte çalışarak envanterdeki ürünler üzerinde ölçümler ve analizler yapabilir ve ortak bir paydada buluşulması sağlanabilir.

=== 9.5.2. YÜKLENİCİ TARAFINDAN ÜRETİLEN VERİLER ===
Yüklenici, müşteri tarafından tanımlanan hedef değerleri ve ürünün mühendislik ve test verilerini kullanarak belirlenen LDA faaliyetlerini yürütür. Bu faaliyetlerinin sonucu olarak da ürünün özelliklerini yansıtan lojistik verilerini üretir.

== 9.6. LDAK’IN GELİŞTİRİLMESİ VE YÖNETİLMESİ ==
LDAK ile ilgili karşılaşılan önemli sorunlardan birisi veri tabanının nasıl geliştirileceğidir. İhtiyaç duyulan bilgiden ziyade spesifik veri elemanlarına konsantre olmak uygulamayı temel amacından saptırabilmektedir. Veri tabanı geliştirilirken odaklanılması gereken temel nokta verileri türeten analiz sürecinin kendisidir.

LDAK’ın ürünün ömür devri boyunca kullanılacak verileri içermesi bir başka hususu daha ön plana çıkartır. Başlangıçta analizler çoğunlukla sistemin güvenilirliği, idame edilebilirliği, test edilebilirliği ve sistem kullanımının çevresel etkileri konusundaki kesitirimlere dayanır. Gerçekte bu kestirimler çoğunlukla sanıldığı kadar hassas değildir. Sistemi ömür devri boyunca destekleyecek kaynakların ayarlanması ve yönetilebilmesi amacıyla bu verilerin zaman içerisinde gerçek kullanımdan toplanan veriler ile yer değiştirmesi önemlidir.

== 9.7. LDAK’IN KULLANILMASI ==
LDAK veri tabanı, sadece oluşturulup bir yerlerde dosyalanmak için değil gerçek anlamda kullanılmak üzere tasarlanmalıdır. Oluşturulan/kayıt altına alınan veriler bütün ELD elemanları tarafından program kapsamında detaylı destek planlarının ve gereksinimlerinin oluşturulması için kullanılmalıdır. LDAK içerisinde yer alan veriler, sistemi desteklemek için gerekli lojistik kaynakları belirlemenin yanı sıra, desteklenebilirliği artırmaya yönelik tasarım değişikliği ihtiyaçlarını belirlemek için de kullanılır.

Bir proje başlatıldığında LDAK’ın nasıl kullanılacağının belirlenmesi, kullanım yöntemlerinin tanımlanması ve herkes tarafından anlaşılması açısından önemlidir. LDAK’ın gerçek faydalarının ve potansiyelinin anlaşılabilmesi öncelikle ortak kaynak veri tabanı konseptinin ve LDAK raporlama kabiliyetlerinin anlaşılmasını gerektirir.

== 9.8. LDA ÖZETLERİ/ RAPORLARI/ÇIKTILARI – STANDARTLARA GÖRE KARŞILAŞTIRMA ==
LDAK veri tabanlarından çeşitli konu başlıklarına göre raporlar üretilmesi mümkündür. Söz konusu raporlar veri tabanı içerisinden detaylı ama kullanılabilir bir biçimde veri derlemesi yapılarak hazırlanmalıdır.Raporlar, çok zaman gerektiren veya kritik bakım görevleri, personel ve beceri gereksinimleri, eğitim ihtiyaçları, bakım atama çizelgeleri (maintenance allocation chart) ve test ve detsek ekipmanı gereksinimleri gibi konuları kapsayabilirler.

= 10. FİZİKSEL DESTEK KAYNAK GEREKSİNİMLERİNİN BELİRLENMESİ VE DESTEK ÜRÜNLERİNİN OLUŞTURULMASI =
Fiziksel kaynak gereksinimi olarak nitelendirilen ELD ürünlerinin oluşturulmaya ne zaman başlanacağı teknik dokümantasyon ve resimli parça verilerinin mevcut olması dahil birçok faktöre bağlıdır. Tasarım ya da bakım konseptinde ortaya çıkabilecek değişikliklerin de lojistik ürünler üzerine etkisi oldukça fazladır. Bu kapsamda, dikkate alınması gereken ELD ürünleri şunlardır:

* Teknik Dokümantasyon
* Malzeme Desteği (resimli parça verileri)
* Genel ve Özel Destek Ekipmanları
* Eğitim
* Üretim tesisleri uzun süren planlama/gerçekleştirme/kalifikasyon gibi sebeplerle tipik bir ELD ürünü olarak kabul edilmezler. Üretim tesisleri vb.leri geniş kapsamlı olarak projelerin erken safhalarında dikkate alınmalıdır.

== 10.1. TEKNİK DOKÜMANTASYON ==
Teknik dokümantasyon iki ana bölümden oluşur;

* Sistemin bakım ve onarımına ilişkin el kitapları
* Sistemin kullanımına ilişkin el kitabı (Kullanıcı Dokümantasyonu)

Geliştirme safhası boyunca gerçekleştirilen lojistik destek analiz faaliyetleri ile esas alınacak bakım konseptinin ne olduğu, ne tür personel, destek ekipmanı ve yedek parçaların gerekli olduğu ve bakım onarım faaliyetlerinin nasıl gerçekleştirileceği gibi bilgileri tanımlanmış olur. Bu nedenle, sistemin bakım onarım faaliyetleri ile ilgili olan teknik dokümantasyonun geliştirilmesine, analiz çalışmalarının bir seviyeye gelmesiyle başlanmalıdır.

Teknik el kitaplarının lojistik destek analiz sonuçlarına uygun olarak hazırlanması durumunda hatalı teknik dokümantasyon oluşturma ve dolayısıyla yeniden işleme riski ortadan kalkacaktır. Ancak bazı durumlarda, teknik dokümantasyon geliştirme süreci zaman kısıtları veya sözleşmesel şartlar nedeniyle projenin daha erken safhalarında başlamak zorunda olabilir. Bu durumda verilen bilgiler analizler sonuçlanana kadar bir seviyede kalacaktır.

Sistemin bakım ve onarımına ilişkin teknik dokümantasyon geliştirme sürecinin temeli LDA veri tabanında dokümante edilen bakım görevleridir. Ürünün ömür devri boyunca ihtiyaç duyacağı lojistik destek analizleri ile tanımlanan tüm görevler bakıma ilişkin dokümantasyonlarda yer almalıdır. Bu amaçla, Yüklenici bünyesinde teknik dokümantasyon geliştiren ekipler ile LDA faaliyetlerini yürüten ekipler arasında sıkı bir koordinasyon sağlanması önemlidir. LDA ile teknik dokümantasyon arasındaki ilişki Şekil 14’de gösterilmiştir.
[[Dosya:Şekil14 LDA ve Teknik Dokümantasyon.jpg|alt=|sol|küçükresim|550x550pik|Şekil 14 Lojistik Destek Analizleri ile Teknik Dokümantasyon Arasındaki İlişki]]

Ürünün kullanımına yönelik teknik dokümantasyonun (Kullanıcı El Kitapları vb.) geliştirilmesi genel olarak LDA sürecinden bağımsız bir faaliyettir. Özellikle operasyonel analiz faaliyetleri sonucu ortaya çıkan bilgilerin kullanıcı dokümantasyonu geliştirilirken de dikkate alınması gereklidir. Bu alanda tanımlanan ve LDA veri tabanında dokümante edilen görevler, hem bakım-onarım hem de kullanım için olan teknik dokümantasyonun bir parçası olabilir.

LDA faaliyetleri sonucu belirlenen ve LDA veri tabanında dokümante edilen her bir bakım/onarım görevi ürünün bakım/onarımına ilişikin teknik dokümantasyona yansıtılmalıdır. Bununla birlikte, bakım onarım teknik dokümantasyonu, dokümante edilmiş LDA görevlerinin ötesinde bilgiler de içerebilir (LDA veri tabanında her bir bakım faaliyeti olmayabilir ya da her parça LDA adayı olmayabilir). LDA’nın amacı, doğru derinlikte bakım ve maliyet ile doğrudan ilişkili kalemlerin analiz edilmesidir. Teknik dokümantasyonlarda kalan ekipmanların ya da parçaların da göz önünde bulundurulması ve bunlara ilişkin bilgilerin de yer alması gerekmektedir. Bu bilgilerin detayları ve derinliği de müşteri ve yüklenici arasındaki anlaşmalara bağlıdır ve gözden geçirmelerin gündem maddelerinden olmalıdır.

Dikkat edilmesi gereken hususların bazıları aşağıda verilmiştir;

* Teknik dokümantasyon için bakım görevleri hazır mı?
* LDA çıktıları teknik dokümantasyon için yeterli değilse, yine de doküman hazırlıklarına başlamanın riskleri nelerdir?
* LDA veri tabanının bir parçası olmayan hangi ilave faaliyetlerin teknik dokümantasyon içerisinde yer alması gereklidir?

== 10.2. İKMAL DESTEĞİ ==
Yedek parçaların neler olduğu, LDA faaliyetleri ile belirlenir. Bakım konseptine bağlı olarak yedek parçaların belirlenmesi büyük ölçüde farklılık gösterebilir. Örneğin 2 seviyeli basit bir bakım senaryosunda komple bileşenler değiştirilecek ve sistemin operatörü tarafından onarım faaliyetleri gerçekleştirilmeyecektir. Bu durumda sadece az sayıda yedek parça tanımlanacaktır. Bununla birlikte, tanımlanmış bütün bileşenlerin ek olarak ihtiyaç duyduğu standart parçalar gibi ilave yedek parçalar da tanımlanabilir.

Belirleyici soru LDA içindeki arızanın boyutudur. Teorik olarak son parçaya kadar bir parçalama mümkündür ancak çaba çok büyük olduğundan bu kabul edilemez olacaktır. Bu nedenle uygulamada, LDA süreci içindeki yedek parçaların tanımlanması belirli bir seviyede duracaktır. Tipik olarak bakım ve maliyet faktörleri LDA süreci içerisinde tanımlanmalıdır. Bu bilgi LDA veri tabanındaki bakım görevlerinin gereksinimleri kapsamında belgelenmiştir. Teknik destek için açıklandığı gibi benzer bir süreç de malzeme desteği için oluşturulmalıdır. LDA faaliyetlerinin ilerlemesine bağlı olarak malzeme desteği ile ilgili lojistik ürünlerin oluşturulmasının başlangıcı LDA'nın ilgili bakım ve maliyet faktörleri tarafından tetiklenmelidir.

Aynı durum teknik dokümantasyon için de geçerlidir; çoğu durumda, gerekli tüm yedek parçalar LDA tarafından belirlenemez. Bununla birlikte, bir LDA görevi tarafından belirlenen tüm yedek parçalar malzeme destek kapsamında değerlendirilmelidir. Tablo 9 farklı türdeki yedek parçalara genel bir bakış ve bunların tanımlama sürecinde dikkate alınması gerekenleri göstermektedir.

'''Tablo 9 LDA Tarafından Belirlenen Farklı Yedek Parça Türleri Listesi'''
{| class="wikitable"
|'''Yedek Parça Tipi'''
|'''Açıklama'''
|'''LDA ile Malzeme Desteği Arasındaki Korelasyon'''
|-
|Komple ekipman parçası
|· Bakım odaklı

· Maliyet odaklı

Kullanım sahasında yer değiştirme görevlerinin (planlı veya plansız) değiştirilmesi için gerekli yedek parçalar (kullanım sahasında herhangi bir onarım yapılmadan komple ekipmanın değiştirilmesi)
|Ekipmanın gerekli bir yedek parça olarak tanımlanması LDA'da tanımlanan bir bakım görevi tarafından onaylanmalıdır.
|-
|Özel yedek parça
|Kullanım sahasında ekipman onarımı veya bakım işleri için gerekli yedek parçalar (ekipmanın onarımı kullanım sahasında yapılacaktır)
|Bu bileşenin gerekli bir yedek parça olarak tanımlanması LDA'da tanımlanan bir bakım görevi tarafından onaylanmalıdır.
|-
|Standart parçalar
|Kullanım sahasındaki onarım veya bakım görevleri için gerekli standart parçalar (örneğin, parçaların veya contaların takılması) (ekipmanın onarımı kullanım sahasında yapılacaktır)
|Bu bileşenin gerekli bir yedek parça olarak tanımlanması LDA'daki eksiklik kaynaklı malzeme desteği tarafından onaylanmalıdır.
|-
|Sarf malzeme
|Sıvı, gres, özel kimyasal ürünler, kaynak malzeme, tutkal gibi gerekli sarf malzemeleri
|Bu bileşenin gerekli bir yedek parça olarak tanımlanması malzeme desteği veya LDA tarafından onaylanabilir.
|}
LDA ile malzeme desteği drasındaki ilişki Şekil 15’de gösterilmektedir.
[[Dosya:Şekil15Lojistik Destek Analizleri ile Malzeme Desteği Arasındaki İlişki.jpg|alt=|sol|küçükresim|550x550pik|Şekil 15 Lojistik Destek Analizleri ile Malzeme Desteği Arasındaki İlişki]]

== 10.3. GENEL VE ÖZEL DESTEK/TEST EKİPMANLARI ==
Sistemler ve ekipmanlar genel olarak kullanımlarını ve idamelerini desteklemek için ilave ekipmanlara ihtiyaç duyarlar. Bir ürünün kullanım ve bakımı için gerekli olan herhangi bir ekipman destek ekipmanı olarak adlandırılır. Destek ekipmanı bazen, özel bir kullanım için tasarlanmış bir “özel ekipman” olabileceği gibi bazen de birden fazla kullanım alanı olan “genel bir ekipman” olabilir

LDA sürecinde ilgili destek ve test ekipmanının belirlenmesi ana görevlerden birisidir. Gerekli destek/test ekipmanının zamanında tedarik hazırlığının yapılmasının kritik önemi vardır ve bu anlamda ortak ve özel destek/test ekipmanı arasındaki ayrım yapılmalıdır. Özellikle, özel destek/test ekipmanlarına yönelik ihtiyaçlar ve gereksinimleri LDA sürecinde belirlenmelidir. Bu belirlemeden sonra da geliştirme ve tedarik süreci başlamalıdır.

LDA veri tabanındaki statü bilgileri destek ve test ekipmanlarından sorumlu birimler tarafından faaliyetleri başlatmak için kullanılabilir. Ancak, bazı durumlarda destek/test ekipmanı gereksinimleri dokümante edilmiş LDA görevleri dışında kaynaklardan da türetilebilir. Örneğin genel aletlerin belirlenmesi için mutlaka LDA veri tabanına giriş yapılması gerekmez (basit bir tornavida için belirli bir LDA görevi tarafından ihtiyaç belirlenmesi gerekmez).

Destek ekipmanı gereksinimlerinin belirlenmesinde bakım konseptinin büyük bir rolü vardır. Kaç seviyede bakım yapılacağı ve her seviyede gerçekleştirilmesi beklenen bakım görevlerinin neler olabileceği, genel olarak destek ekipmanı ihtiyaçlarını tanımlayan temel girdidir. Teorik olarak, organizasyonel seviyede gerçekleştirilecek bakımların ara seviye ve fabrika/depo seviyesi bakımlara nazaran daha az destek ekipmanına ihtiyaç duyması beklenir. Buna paralel olarak organizasyonel seviyede kullanılacak destek ekipmanlarının maliyetleri de normalde diğer seviyelere göre daha düşük olacaktır.

Destek ekipmanı gereksinimlerini etkileyen önemli bir diğer faktör üründe yer alacak cihaz içi test (BIT) kabiliyetidir. Örneğin, bir ekipman bir arızayı sistem içerisinde küçük bir modüle kadar ayrıştırabilecek test kabiliyetine sahipse ve operatör bu modülü genel aletler kullanarak söküp değiştirebiliyorsa hem organizasyonel hem de diğer bakım seviyelerinde karmaşık bir destek ekipmanı ihtiyacı olmayabilir. Bu durumda ara seviye sistemin tamamında hata ayrıştırması yapmak yerine değiştirilen modüllerin onarımına odaklanılabilir.

Sistemin kullanıma hazır olma hedefleri gerek duyulacak destek ekipmanlarının belirlenmesinde dikkate alınması gereken bir diğer faktördür. Güvenilirlik, İdame Edilebilirlik ve Kullanıma Hazır Olma unsurları öncelikle belirlenmelidir. Bu sayede ürünle ilgili işletim ve bakım ihtiyaçlarına uygun ekipmanların belirlenmesi sağlanacaktır. Tasarım olgunlaştıkça, destek ekipman tür ve miktarlarına dair gereksinimler Bakım Görev Analizi (BGA) kapsamında belirlenir.

Destek ekipmanları belirlenirken işletme ve çevre şartları göz önünde bulundurulmalı, ürün için yapılan lojistik destek analizleri ve ürün özellikleri dikkate alınarak yedek malzeme stoklaması yapılmalı, ürünü kullanıma almak için gerekli test, ayar ve kalibrasyon cihazları belirlenmelidir. LDA ve test ekipmanları arasındaki ilişki Şekil 16’da gösterilmektedir.
[[Dosya:Şekil16LDA ve Test Ekipmanları Arasındaki İlişki.jpg|alt=|sol|küçükresim|500x500pik|Şekil 16 LDA ve Test Ekipmanları Arasındaki İlişki]]

== 10.4. EĞİTİM ==
Gerekli bakım görevleriyle ilgili bütün bilgiler (örn. performans detayları, gerekli destek ekipmanı, zorluk ve kritiklik, süre, çalışma adımları, gerekli personel sayısı) sağlanana kadar bakım faaliyetleriyle ilgili eğitim ihtiyaçları belirlenemez. Eğitim gereksinimlerini tanımlamanın ilk adımı bir Eğitim İhtiyaçları Analizi (EİA) olmalıdır. Bu, LDA tarafından belirlenen bakım görevlerine dayanabilir. LDA ve eğitim arasındaki ilişki Şekil 17’de gösterilmektedir.
[[Dosya:Şekil17LDA ve Eğitim.jpg|alt=|sol|küçükresim|550x550pik|Şekil 17 LDA ve Eğitim Arasındaki İlişki]]

Eğitimin içeriğini belirleme ve geliştirme süreci müşteri ve yüklenici arasındaki anlaşmalara göre LDA sonuçları ve/veya mevcut teknik belgelerde geçen bilgiler kullanılarak sağlanmalıdır. Çünkü eğitim ekipmanlarının geliştirilmesi çok maliyetli olabilir (eğitim videoları, eğitim kuleleri, eğitim simülatörleri, vb üretimi).

Mümkün olan en iyi destek için LDA veri tabanındaki eğitim bilgilerinin belgelenmesi önemlidir. LDA veri tabanı "gerekli eğitim", personel için beceri seviyeleri veya varsa daha ayrıntılı bilgi gibi basit işaretler içerebilir. LDA veri tabanının eğitim gereksinimlerinin çıkarılmasını destekleyen sorgular içerecek şekilde tasarlanması önerilir.

== 10.5. TESİSLER VE ALTYAPI ==
Tesisler ve altyapı, bir sistemi desteklemek için gerekli olan kalıcı ve yarı-kalıcı gayrimenkul varlıklarından oluşmaktadır. Bu alanda yapılan çalışmalar, tesislerin türlerinin tanımlamasını (ör: eğitim, ekipman depolama, bakım, tedarik depolama, mühimmat depolama, bilgisayar donanım/yazılım sistemleri, ağ ve iletişim sistemleri) veya konum, alan ihtiyaçları, çevre ve güvenlik gereksinimleri ve ekipmanlarının belirlenmesi ile tesis iyileştirmelerini kapsar. Sistem çalışmasının etkililiğini en üst düzeye çıkarmaya olanak sağlayacak; eğitim, bakım ve depolama faaliyetlerinin gerçekleştirilmesi için en düşük sahip olma maliyetli tesisin belirlenmesi, planlanması, kaynak sağlanması ve satın alınması, bu öğenin amacıdır. Tesisler ve altyapı; tesis ve altyapı türlerini tanımlamak için yapılan çalışmalar, tesis ve altyapı iyileştirmeleri, konum, alan ihtiyaçları, çevre ve güvenlik gereksinimleri ve ekipmanları dahil olmak üzere bir sistemi desteklemek için gerekli olan kalıcı ve yarı kalıcı gayrimenkul varlıklarından ve altyapıdan oluşur. Yapılan LDA faaliyetleri savunma ve güvenlik sisteminin kullanımı ve idamesi için ihtiyaç duyulacak tesis ve altyapı özelliklerinin belirlenmesine katkı sağlayacaktır.

== 10.6. PAKETLEME, ELLEÇLEME, DEPOLAMA VE ULAŞIM ==
Bir ürünün normal kullanımı dışındaki paketleme, taşıma, depolama ve nakliye faaliyetleri ihtiyaca göre belirlenmelidir. Bu hususların bir kısmı analiz sonuçlarından ortaya çıkmayabilir. Ancak ürünün kullanıma alınmasıyla birlikte eksik ve/veya yetersiz bilgi sebebiyle kullanıma ilişkin hatalar olabilir. Bu nedenle, bu bilgilerin belirlenerek ilgili teknik dokümantasyonlarda belirlenmesi önemlidir.

=== 10.6.1. PAKETLEME ===
AKK ve/veya bileşenleri için paketleme konsepti aşağıda verilen örnek durumlara göre belirlenebilir;

* Paketleme kısa süreli ve/veya uzun süreli depolama için mi gereklidir?
* Paketleme nakliye için gerekli midir ve ne tür bir nakliye yapılacaktır?
* Depolama veya nakliye için özel bir konteyner gerekli midir?
* Depolama veya nakliye döneminde aşırı iklim koşullarından dolayı özel koruma gerekli midir? (Örneğin deniz taşımacılığı)
* Nakliye veya depolama süresince, örneğin bakım faaliyetleri (depolama görevleri) gerçekleştirmek için ürün ambalajından çıkarılıp yeniden ambalajlanması gerekir mi?
* Destek ekipmanı ve tesisleriyle ilgili muhafazanın çıkarılması ve paketin açılması için ne gereklidir?

=== 10.6.2. ELLEÇLEME ===
Ürün taşıma görevleri aşağıda verilen örnek durumlara göre belirlenebilir;

* Taşıma için gerekli güvenlik önlemleri ve sınırlamalar dikkate alınmalıdır.
* Normal kullanım haricinde herhangi bir şekilde park etmek, çekmek, vinçle kaldırmak veya taşımak için gerekli talimatlar belirlenmelidir.
* Ürünün yer değiştirmesi için gerekli talimatlar, örneğin takma noktaları, gerekli adaptörler, özel bileşenler için destekler, denge ağırlıkları, kriko prosedürleri belirlenmelidir.
* Ürün taşımada gereken ek ekipman ve malzemeler önceden belirlenmelidir. (örn. çekme çubukları veya kablolar)

=== 10.6.3. DEPOLAMA ===
Depolama süresi boyunca ve depolama sonucunda ürün işlevselliğini garanti etmek için depolama prosedürleri analiz edilmeli ve belgelenmelidir. Depolama koşulları aşağıda verilen örnek durumlara göre belirlenebilir;

* Gerekli depolama uzun süreli depolama veya kısa süreli depolama çözümü olarak mı değerlendiriliyor?
* Ürün/bileşen özel hassasiyette depolanacak mı?
* Depolanacak ürün bileşenlerini çıkarmak ve bu bileşenleri özel şartlarda ayrı olarak depolamak gerekli midir?
* Depolama sırasında yapısal ve sistem bütünlüğünü korumak için ne tür bir kontrol ve önleyici bakım gereklidir? (örn. Tekerlek dönüşü, elektrik gücü, motor çalışması ve basınç kontrolleri vb.)
* Depo içi bakım için bir zaman çizelgesi sağlandı mı?
* Depolama süresince beklenen aşırı iklim koşulları (ısı, don, nem vb.) var mı?
* Depolamaya giriş için gerekli özel teknikler var mı? (örn. Temizlik ve koruma, sıvı sistemi boşaltma/yenileme, statik topraklama, koruyucu boşluk, özel bileşenlerin sökülmesi vb.)
* Depolamadan çıkarılması ve kullanıma geri dönmesi için gerekli özel teknikler var mı? (örn. Koruma ve temizleme, sıvı sisteminin yenilenmesi, özel bileşenlerin tekrar montajı, fonksiyonel kontroller, kullanıma hazırlama)
* Saklama süresi boyunca ne tür bir güvenlik önlemi gereklidir? (örn. Hareketli bir bileşenin demirlenmesi/sabitlenmesi ve bloke edilmesi, karanlık bir depolama alanında tutulup ışığa maruz kalmaması vb.)
* Depolanan ürün/bileşenin ömrü ile bağlantılı olarak depolama süresini dikkate almak gerekli midir?

=== 10.6.4. ULAŞIM ===
Müşteri gereksinimlerine dayanarak, ürünün taşınabilirliğinin analizi aşağıda verilen örnek durumlara göre belirlenebilir;

* Nakliye için hazırlanma ve nakliye sonrası yapılması gerekli faaliyetler için harcanan iş gücü ve süre nedir?
* Personel, araçlar, sarf malzemeleri ve tesislerle ilgili nakliye sonrası hazırlık ve iyileştirme için gereksinimler nelerdir?
* Özel koşullar altında nakliye için ek çevresel şartlar nelerdir? (örneğin deniz taşımacılığı, kumlu çöl ortamı, nem, ısı, don gibi aşırı iklim koşulları gibi)
* Özel koşullar altında nakliye için ek güvenlik gereksinimleri nelerdir? (örn. Hava taşımacılığı durumunda bir nakliye uçağı içinde demirleme/sabitleme)
* Taşıma süresince gerekli servis işlemleri nelerdir? (özellikle uzun yolculuklarda)
* Ürün bileşenlerini nakliye için sökmek veya tüm ürünü belirli bir seviyeye indirgemek gerekli midir?
* Konteyner/taşıma kutusu kavramı düşünülmeli mi?
* Kızakların ve/veya paletlerin kullanımı kabul edilebilir mi?

= 11. LDA VE KAYITLARINA İLİŞKİN FAALİYETLERİN UYARLANMASI =
Sürecin uyarlanmasında bu rehberden etkin olarak faydalabilmek kullanıcıların kendi projelerine uygun olan işlevleri seçmeleri ve uygulamaları ile mümkün olabilir. Rehberin bölümleri ilgili projeye münferit olarak dahil edilebilir veya kapsamdan çıkartılabilir. Uyarlama aynı zamanda analize tabi tutulacak aday kalemlerin (ürün bileşenleri) çeşitliliği ve sayısı, bir aday kalem için yapılacak analizlerin neler olacağı, analizler esnasında kullanılacak veriler ile analiz bilgilerinin nasıl kayıt altına alınacağı konularında da gerçekleştirilebilir.

Projenin/Programın erken safhalarında bir LDA stratejisi belirlemek ve LDA programı oluşturmak uyarlama için yapılması gereken ilk adımlardır.

Uyarlama esnasında dikkat edilmesi gereken önemli bir nokta sadece LDA sürecinin değil genel anlamda ELD sürecinin uyarlanması, farklı ELD disiplinleri açısından referans alınabilecek standartların/süreçlerin birbirleri ile uyumlaştırılarak LDA veri tabanına sonuçların yansıtılması ve uyarlama esnasında varsa eskiden kalan/mevcut verilerin (legacy data) nasıl ele alınabileceği, yeni standartalara ve yazılım araçlarına nasıl geçiş yapılabileceği gibi konuların da ele alınmasıdır.

Lojistik iş tanımlama toplantısı, uyarlamanın ilk olarak tartışılacağı ve kararlaştırılacağı adımlardan birisi olabilir.

LDA sürecinin bir proje kapsamında uyarlanması aşamalı bir faaliyettir. Genel LDA çerçevesinin belirlenmesinden LDAK içerisinde yer alacak veri elemanlarının belirlenmesine kadar devam eder. Bu kapsamda uyarlama aşamaları şöyle sıralanabilir:

* Projede uygulanacak analizlerin seçilmesi ve her bir aday kalem için hangi analizlerin uygulanabilir olduğunun belirlenmesi
* Projeye özel iş kurallarının belirlenmesi (örn. Ürün kırılımı için seçilecek yöntem, OSA yöntemi, lojistik FMEA, vb.)
* Proje gereksinimlerine göre belirlenen standart/spesifikasyon içerisinden veri elemanlarının seçilmesi

== 11.1. PROJE KAPSAMINDA ANALİZ GEREKSİNİMLERİNİN BELİRLENMESİ, SEÇİM KRİTERLERİ ==
Bölüm 5.4.1’de tanımlanan potansiyel lojistik destek analizleri içerisinden proje kapsamında hangilerinin gerçekleştirileceğinin belirlenmesi uyarlama sürecinin önemli bir adımdır.

Tablo 10’da LDA analiz faaliyetlerinin seçimi ve aday kalemlere atanması için dikkate alınabilecek örnek kriterler yer almaktadır. Seçim kriterleri de projeye göre farklılık gösterebileceğinden özel durumlar da dikkate alınarak uyarlanmaları mümkündür. Seçim faaliyetinden önce, kullanılacak kriterler üzerinde tüm paydaşlar arasında uyumlaştırılmış olması gereklidir. Bu uyumlaştırma LDA GGT’de sağlanabilir.

'''Tablo 10 Analiz Faaliyetleri Seçim Kriterleri'''
{| class="wikitable"
|'''Kriter Grubu'''
|'''Kriter'''
|'''Öneri'''
|-
| rowspan="6" |Kullanım tecrübesine sahip olunan kalemler
|Halen karşılaştırılabilir koşullarda kullanılmakta olan kalemler
|Mevcut analiz verilerinin orta derecede dönüşümünün yapılması
|-
|Halen kullanılan -fakat karşılaştırılabilir şartlar altında olmayan- kalemler
|Mevcut analiz verilerinin dönüşümünün dikkatli yapılması
|-
|Majör modifikasyon gerektirmeden kullanılabilecek RAHAT kalemler
|Mevcut analiz verilerinin orta derecede dönüşümünün yapılması
|-
|Minör/Majör değişiklik gerektirecek kalemler
|Mevcut analiz verilerinin dikkatli dönüşümünün yapılması yeni analizlerin gerçekleştirilmesi
|-
|Bilinen bir teknolojiye bağlı olarak yeni geliştirilen kalemler
|Analiz faaliyetlerinin gerekli detay seviyesinde yapılması (önemle tavsiye edilir)
|-
|Yeni bir teknolojiye bağlı olarak yeni geliştirilen kalemler
|Analiz faaliyetlerinin gerekli detay seviyesinde yapılması gereklidir.
|-
| rowspan="3" |Geniş bir bakış açısı gerektirdiği ya da özel öneme sahip olduğu için değerlendirilmesi gereken kalemler
|Potansiyel göreve hazır olma ve/veya maliyet etmenleri
|Bu kalemler için kriterlerin LDA GGT’da detaylandırılması gerekir.
|-
|Müşterinin ısrarlı ilgisine konu olma
| rowspan="2" |Kalemlerin LDA GGT’de detaylandırılması gerekir.
|-
|LDA ilişkili sözleşmesel yükümlülükler
|-
| rowspan="4" |Kendi tasarım özellikleri gereği veya yerleşim yerinden dolayı değerlendirilmesi gereken kalemler
|İlgili arıza/hata sıklığı, iş yükü, özel lojistik gereksinimlere (personel ve/veya) ilişkin olarak Bakım Önemli Kalemler
|Bu kalemler için kriterin LDA GGT’de detaylandırılması gerekir.
|-
|Planlı bakıma veya ömür limitlerine tabi kalemler
|Planlı bakım analizi için kriterlerin LDA GGT’de detaylandırılması gerekir.
|-
|Özel olaylardan kaynaklanan önleyici bakıma tabi kalemler
|Özel olay analizi için kriterlerin LDA GGT’de detaylandırılması gerekir.
|-
|Yerleşim yeri nedeniyle potansiyel hasarlarla karşılaşmaya müsait kalemler
|Hasar analizi için kriterlerin LDA GGT’de detaylandırılması gerekir.
|-
| rowspan="4" |LDA aday tipleri
|Tam aday
|Uygulanabilir analizlerin yapılması, sonuçların LDA veri tabanında kayıt altına alınması,
|-
|Kısmi Aday
|Temel seviyede bilgilerin LDAK içerisinde kayıt altına alınması
|-
|Aday aileleri
|Bir grup bileşenin tek bir LDA adayı kalem olarak ele alınması, uygulanabilir analizlerin yapılması ve sonuçların LDAK içerisinde kayıt altına alınması,
|-
|Standart prosedürlere tabi kalemler
|Temel seviyede bilgilerin LDAK içerisinde kayıt altına alınması
|-
| rowspan="5" |Müşteri tarafından bilgi talep edilen durumlar
|LDA sürecinden beklenen bilgiler
| rowspan="4" |LDA GGT süresince, müşteri ile uyumlaştırılmalı ve üzerinde mutabık kalınmalıdır.
|-
|Tavsiye edilen lojistik destek esaslarına dair öneri
|-
|Olası alternatiflerin tanımlanması (donanım, yazılım, destek konseptleri için) ve ilişkili sonuçları (ör., lojistik destek gereksinimleri)
|-
|Tavsiye edilen bakım konseptleri ve ilgili bakım görevlerine dair teklif
|-
|İlgili lojistik destek maliyetlerinin tahmini
|İlişkili lojistik destek gereksinimlerin belirlenmesi, lojistik destek maliyet tahmini, erken dönem sistem/proje kararlarına yönelik bilgiler (önemli maliyet etkisi)
|}
Her bir LDA aday kalemine hangi analizlerin uygulanacağına dair seçimle ilgili kararların dokümante edilmesi için bir matris kullanılabilir. Seçimler esnasında, bütçe ya da zaman gibi kısıtlar varsa, buna göre önceliklendirme yapılabilir.

Bu matris, LDA adaylarının tanımlanması ve görev seçim kriterleri ile buradan çıkan sonuçları içerecek şekilde LDA GGT öncesinde yüklenici tarafından hazırlanmalı ve toplantı esnasında müşteri ile uzlaşılan kararları yansıtmalıdır. Dokümanın, değişiklikleri yansıtması, ‘kazanılmış dersler’e ilişkin sonuçları kapsaması ve sistemin ömür devri boyunca izlenebilirliği sağlayan yaşayan bir doküman olması önemlidir.

LDA aday kalemleri ve uygulanacak analizlere ilişkin taslak bir listenin, teklif süreci esnasında LDA görev atamalarına ilişkin rehberlik sağlaması ve risk azaltma amaçlı olarak müşteriye sunulması tavsiye edilir.

Seçilen analiz faaliyetlerini kayıt almaya dair matrise ilişkin bir örnek Tablo 11’da verilmiştir.

'''Tablo 11 Analiz Faaliyetleri Öneri Matrisi'''
{| class="wikitable"
|Seviye
|Aday Tipi
|Adı
|Genel LDA Gerekleri
|Karşılaştırmalı Analiz
|İnsan Faktörü Analizi
|Konfigürasyon Değerlendirme
|Güvenilirlik Analizi Değerlendirmesi
|İdame Edilebilirlik Analizi
|Test Edilebilirlik Analizi
|HTEA / HTEKA
|Hasar Analizi

|Özel Olay Analizi
|Planlı Bakım Analizi
|OSA
|BGA
|Yazılım Destek Analizi
|Lojistik İlişkili Operasyonlar Analizi
|Eğitim İhtiyaçları Analizi (TNA)
|Sıralama
|-
|1
|Sistem
|<nowiki>-</nowiki>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|-
|1.1
|Alt Sistem
|<nowiki>-</nowiki>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|-
|1.1.1
|Aday Değil
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|-
|1.1.2
|Tam Aday
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|-
|1.1.3
|Kısmi Aday
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|-
| colspan="20" |0 = Uygulanabilir Değil 1 = İsteğe Bağlı 2 = Tavsiye Edilen 3 = Kuvvetle Önerilen 4 = Zorunlu
|}
LDA adayları tarafından yönlendirilmeyen bütün genel görevlere ilişkin tavsiyeler farklı dokümanlarda kayıt altına alınmalıdır.

== 11.2. ÖMÜR DEVRİ SAFHALARINA GÖRE ANALİZLERİN UYARLANMASI ==
LDA aktivitelerinin gerçekleştirilebilmesi için projenin farklı safhalarında farklı veri setleri erişilebilir durumda olmalıdır. Tanımlanan LDA görevlerinden bazıları projenin erken safhalarında gerçekleştirilebilirken bazıları tasarımla ilgili detaylı ve nihai bilgilerin oluştuğu dönemlerde yürütülebilir. Ömür devri safhalarına (Bkz.[https://tssodypwiki.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)] ) göre analiz faaliyetlerinin akış süreci Şekil 18’de örnek olarak verilmiştir.
[[Dosya:TSSÖDYP06 Ş.18.jpg|alt=|sol|küçükresim|689x689pik|Şekil 18 Ömür Devri Safhalarına Göre Analiz Akış Süreci]]

LDA aktiviteleri geliştirme safhasının sonunda bitmez. Üretim safhasında da üründe gerçekleştirilecek değişikliklerin kapsamına bağlı olarak LDA birkaç kez daha tekrarlanabilir. Bu durum kullanım safhasında da geçerlidir. Kullanım safhasında ürüne kapsamlı modifikasyonlar yapılması söz konusu olabilir. Dolayısıyla LDA sürecinin belirli şartlara bağlı olarak tekrarlanması gerekmektedir. Bu yüzden, lojistik verinin ve kararların dokümantasyonunun sistem ömür devri boyunca envanterden çıkarma safhasına kadar devam ettirilmesi gerekir.

==== <big>11.2.1.1. Erken Dönem Analiz Faaliyetleri</big> ====
Projenin erken safhalarında, LDA aktiviteleri düşük seviyede bilgi gerektiren durumlarla sınırlıdır. LDA GGT’den önce operasyonel ve müşteri gereksinimleri ile ilgili bilgiler normalde erişilebilir durumdadır. Dolayısıyla LDA GGT’den önce LDA sürecinin temel kurallarına ilişkin taslağın hazırlanması GGT çalışmalarını hızlandıracaktır.

Analiz altındaki sistem veya kalem hakkında detaylı bilgi bu aşamada normalde erişilebilir değildir. Bu aşamada, yalnızca sürecin uygulanması için temel koşul ve kurallar erişilebilir durumdadır, ancak genel LDA ihtiyaçlarının belirlenmesi analizi, karşılaştırmalı analiz, insan faktörleri analizi, operasyonlar analizi, konfigürasyon değerlendirmesi gibi bazı analizlere LDA sürecinin erken aşamalarında da başlanabilir.

==== <big>11.2.1.2. Tasarım ve Geliştirme Dönemi Analiz Faaliyetleri</big> ====
LDA süreci, tasarım ve geliştirme dönemi boyunca tasarım süreci ile beraber yürümelidir. Bu durum, çok erken faz ya da tasarım donduktan sonraki faz hariç, tüm LDA aktivitelerine uygulanır. Bu aktiviteler aşağıdaki gibidir:

* Konfigürasyon değerlendirmesi
* Güvenilirlik analizi değerlendirmesi
* İdame edilebilirlik analizi
* Test edilebilirlik analizi
* HTEKA / HTEA
* Hasar analizi
* Özel olay analizi
* Planlı bakım analizi
* Onarım seviyesi analizi
* Bakım görev analizi
* Yazılım ve veri yükleme/indirme/taşıma analizi
* Yazılım tasarım ve yazılım bakım analizi
* Lojistik İlişkili Operasyonlar analizi

Tasarım donduktan sonra, lojistik ile ilgili veri toplanma işlemi büyük ölçüde tamamlanmış olmalıdır. Bu yüzden, detaylı veri gerektiren analiz aktiviteleri, sabitlenmiş tasarımı garantiye almak ve maliyetli analiz aktivitelerini tekrarlamak riskini azaltmak için tasarım sürecinin son aşamalarında gerçekleştirilmelidir.

* Operasyonel senaryoların simülasyonu
* Eğitim ihtiyaçları analizi

==== <big>11.2.1.3. Kullanım Dönemi Analiz Faaliyetleri</big> ====
Kullanım safhası boyunca, lojistik analiz faaliyetleri tekrarlanacak olup bu durum azalan ölçüde olacaktır. Eğer ürün teknik güncellemeler ya da tasarım değişikliğine uğrarsa, lojistik gereksinimleri dikkate alan yeni bir analiz yapılmalıdır. Analizin derinliği ve genişliği, sistemin tipine ve değişikliğin ölçüsüne bağlı olacaktır.

==== <big>11.2.1.4. Sistem Ömür Devri Safhalarındaki Aktivitelerin Özeti</big> ====
Tablo 12, tüm ömür devri safhalarındaki potansiyel analiz aktivitelerinin özetini göstermektedir. (ör: veri ve bilgi toplama, yönetim, teknik/lojistik analizler ve hazırlık görevleri). Bu tablo, tasarım ve geliştirme dönemine ek olarak Ön Tasarım Gözden Geçirme (ÖTGG) ve Kritik Tasarım Gözden Geçirme (KTGG) gibi tipik aşamaları da içerir.

'''Tablo 12 Sistem Ömür Devri Safhalarındaki Aktivitelerin Özeti'''
{| class="wikitable"
| rowspan="2" |'''Ön Konsept & Konsept Safhası'''
| colspan="3" |'''Geliştirme Safhası'''
| rowspan="2" |'''Üretim Safhası'''
| rowspan="2" |'''Kullanım Safhası (Destek Uygulama Aşaması ile birlikte)'''
| rowspan="2" |'''Envanterden Çıkarma Safhası'''
|-
|'''Yapılabilirlik çalışması'''
|'''Ön Tasarım'''

'''(PDR)'''
|'''Kritik Tasarım (CDR)'''
|-
|Performans Ürün verisi (CRD)
|Performans Ürün verisi güncellemeleri (CRD)
|
|
|
|
|
|-
|Ürün kullanım verisi
|Ürün kullanım verisi güncellemeleri (ORD)
|
|
|
|
|
|-
|
|İdame Edilebilirlik Çalışmaları
|İdame Edilebilirlik Analizleri
|İdame Edilebilirlik Analizleri Güncellemeleri
|
| rowspan="4" |Geri besleme verilerine dayanan destek konseptinin süregelen optimizasyonu→ Hizmet içi LDA

Analiz sonuçlarının ve konfigürasyon değişikliği bazlı ELD ürünlerinin güncellenmesi
|
|-
|
|Güvenilirlik Çalışmaları
|Güvenilirlik Analizleri
|Güvenilirlik Analizleri

Güncellemeleri
|
|
|-
|Karşılaştırmalı çalışmalar
|Karşılaştırmalı çalışmalar
|Karşılaştırmalı çalışmalar
|
|
|
|-
|
|
|ELD ürünlerinin geliştirilmesinin planlanması
|ELD ürünlerinin geliştirilmesi
|ELD ürünlerinin güncellenmesi
|
|-
|
|
|
|
|
|Enventerden Çıkarmanın planlanması
|
|}

= 12. EKLER =

== EK-A İNSAN FAKTÖRÜ ANALİZLERİ VE LDA ==

'''<big>1. GİRİŞ</big>'''

İnsan faktörü analizleri, LDA faaliyetleri esnasında bakım ekibi ve destek ekipmanı gereksinimlerinin belirlenmesi için kullanılabilecek kaynak veriyi sağlarlar. Bu ilişki tasarım süreci esnasında başlar ve bakım görev analizlerinin geliştirilmesi süreci boyunca devam eder.

LDA, idame edilebilirlik ve desteklenebilirlik işlevleri, potansiyel destek çözümlerinin insan faktörü gereksinimlerini de kapsayan eşik değerlerin içerisinde kalmasını sağlayacak şekilde koordine edilmelidir. Bunun için operasyonel ve bakım görevlerinin gerçekleştirilmesinde gerekli olan destek kaynaklarının ve ekip büyüklüğünün dikkate alınması gerekir. İnsan faktörü kısıtlamaları ürünün tasarımını etkilemenin yanı sıra destek ortamının oluşturulmasını da etkiler. İnsanın kısıtlı kabiliyetleri, ürün kullanımı ve desteği üzerinde kısıtlamalara yol açar.

Bu EK teknik ve LDA faaliyetleri gerçekleştiren personele yönelik olarak hazırlanmıştır. Bölümde insan faktörleri ve lojistik destek analiz süreci arasındaki ilişkiler ve entegrasyonu tanımlanmaktadır. İnsan faktörü analiz sonuçlarının projenin mümkün olan en erken safhalarında dokümante edilmesi tavsiye edilmektedir. LDA veri tabanı içerisinde insan faktörlerinin etkileri farklı yerlerde görünebilir. Uyarı ve ikazların yanı sıra, belirli bir görev yerine getirmek veya personeli olumsuz çevresel ortamda koruyabilmek için gerekli özel ekipman ihtiyaçları bu konuda örnek teşkil edebilir.

<big>'''2. LOJİSTİK DESTEK ANALİZLERİ VE İNSAN FAKTÖRLERİ'''</big>

'''<big>2.1. FİZİKSEL KABİLİYETLER VE KISITLAMALAR</big>'''

LDA ve insan faktörü entegrasyonu ürünün bütün ömür devri boyunca süreklilik arz eder. Üründe gerçekleştirilen modifikasyonlar veya önerilen tasarım değişiklikleri beraberinde bakım görevlerinde de değişiklik gerektirebilir.

LDA ve insan faktörü analizlerinin ortak hedeflerinin yanı sıra kendilerine özel amaç ve hedefleri de vardır. İnsan faktörleri antropometrik hususlar, ergonomik hususlar ve diğer fizyolojik hususlara ilişkin değişik standartlara odaklanabilir. LDA da bu standartları dikkate almalı ve potansiyel destek çözümlerini değerlendirmelidir. Bu konuya verilebilecek örneklerden biri, ortalama insan önkolunun çapıdır. Bilek hareketinin ötesinde erişim gerektiren bir panelin tasarımında uygun standartlarda verilen minimum ölçü dikkate alınmalıdır. Bu durumda, insan faktörü bütün erişim panelleri için söz konusu ölçü gereksiniminin dikkate alınmasını sağlamak üzere tasarıma etki eder. Buna ilave olarak LDA, kısıtlı hareket imkânları olan bir ortamda gerçekleştirilecek bir görevin tamamlanabilmesi için gerekli destek ekipmanlarını tanımlar. Eğer, analiz faaliyetleri esnasında alternatif tasarım çözümleri belirlenirse, bunlar tasarım sürecinde dikkate alınmak üzere tasarım ekiplerine bildirilir.

'''<big>2.2. TEHLİKELİ DURUMLARDAN KAYNAKLANAN KISITLAMALAR</big>'''

İnsan faktörlerinin dikkate alınması gereken bir başka nokta insan sağlığına karşı tehditlerden dolayı bazı aktivitelerin kısıtlanmasıdır.

Tehlikeli maddelerin ele alınması, fiziksel bütünlüğün korunması açısından katı yasal düzenlemelere tabidir. Özellikle ürün ömür devri sonunda, ürününün envanterden çıkarma safhasında insan sağlığına zararalı olabilecek malzemelere maruz kalma ve dolayısıyla insan faktörü büyük önem arz eder.

Çok sıcak veya soğuk, nemli, yeraltı veya sualtı, çok gürültülü vb. aşırı çevresel koşullar altında gerçekleştirilen faaliyetlere ilişkin kısıtlamalar da dikkate alınması gereken hususlardandır. İnsanların bu çevresel koşulların etkisine karşı korunmaları da fiziksel kısıtlamalar gibi LDA süreci içerisinde ele alınmalıdır.

<big>'''3. İNSAN FAKTÖRÜ ANALİZLERİ'''</big>

'''<big>3.1. TASARIMA ETKİ</big>'''

İnsan faktörü tasarım kısıtı ve gereksinimlerini tanımlayan çeşitli standartlar vardır. Bu standartlar, yüklenici/müşteri mutabakatında uygun şekilde referans verilmeli ve sözleşmelere dahil edilmelidir.

İnsan faktörleri niceliksel verileri bakım ekibinin becerileri, sayısı ve destek ekipmanı ihtiyaçları belirlenirken dikkate alınmalıdır. Örneğin, insan faktörleri, tek bir kişinin taşıyabileceği ağırlık limitlerini belirler. Bu limitler mekanik kaldırma araçlarını, ayaklık ihtiyaçlarını ve/veya personel sayısını belirler. Bu bilgi, tasarım alternatiflerinin değerlendirilmesi için kullanılabilir. İnsan faktörleri, bakım görevlerine uygulabilecek spesifikasyon ve standartları sağlar.

Ekip büyüklüğüne ilişkin personel gereksinimler, uygulanabilir olduğu durumlarda demografik özellikleri de dikkate almalıdır. Örneğin tamamen erkeklerden oluşan bir ekip için tanımlanacak yük kaldırma limiti, kadın erkek karma bir ekibin yük kaldırma limitinden daha yüksek olacaktır. Yani ekipmanın ağırlığı, kaldırılabilmesi için gerekli personel sayısını belirler ancak bu sayı farklı demografik özelliklere göre değişiklik gösterebilir. Ağırlık sınırlamaları, mekanik kaldırma gereksinimleri için de dikkate alınarak destek ekipmanı gereksinimlerini etkilemelidir.

<big>'''3.2. LDA İÇİN İLKELER'''</big>

LDA İş Tanımlama Toplantısı, LDA ve insan faktörü analizlerine uygulanacak kural ve ilkeleri belirlemelidir. Yüklenici ve müşteri arasında uygulanacak spesifik standart üzerinde mutabakata varmalı ve standarda yönelik istisnalar da tanımlanmalıdır.

LDA tasarım sürecinden aldığı girdileri kullanır ve her altenatif tasarım/tasarım unsurları için ödünleşim analizleri gerçekleştirir. İlk tasarım faaliyetlerinden itibaren, LDA tasarımı analiz ederek alternatiflere yönelik destek gereksinimleri karşılaştırarak tavsiyelerde bulunur. Süreç bütün olası bakım görevlerini tanımlamayı içerir. Her bakım görevi için ihtiyaç duyulacak kaynakların listesi oluşturulur. Bu kaynaklar, yedek parça, sarf malzemesi, bakım işçilik saati, eğitim, destek ve test ekipmanlarını kapsar. İnsan faktörüne özel hususlar bakım personelinin sayısı, ilgili destek ekipmanları vb’dir.

Bakım personeli sayısı, bakım görevine ilişkin gerekli beceriler, değiştirilen ekipmanın ölçüleri ve ağırlığndan etkilenir. MIL-STD 1472 gibi çeşitli insan faktörü standartları tek bir kişinin taşıyabileceği ağırlık limitlerini tanımlamaktadır. Ekipman belli bir uzaklığa taşınacaksa, bunun için de limitler söz konusudur. Bu limitler BGA esnasında dikkate alınmalıdır. Limitlerin aşıldığı durumlarda ilave personel ihtiyacı ortaya çıkacak, ekipman üzerinde tutma yeri tasarlanması gerekecektir. Bu gibi durumlarda mekanik kaldırma araçları tanımlanması da dikkate alınabilecektir.

Analiz süreci yinelemeli bir süreç olup, her tasarım değişikliğinde de tekrarlanmalıdır. LDA süreci içerisinde, detaylı BGA ürün tasarımın onaylanmasından sonra başlar. Her bakım görevi, ilgili insan faktörü standardı ile kıyaslanarak bütün bakım ve operasyon faaliyetlerinin insan faktörü limitleri içerisinde olduğu teyit edilir.

'''<big>4. DİKKATE ALINMASI GEREKEN İNSAN FAKTÖRLERİ</big>'''

Aşağıda sıralanan insan faktörleri, dikkate alınması gereken insan faktörleri açısından sınırlayıcı değildir; ancak ürün tasarımını etkileyecek ve özellikle LDA alanında destek ortamının tasarımında dikkate alınabilecek insan faktörlerine örnek olarak dikkate alınabilir.

<big>'''4.1. ANTROPOMETRİK HUSUSLAR'''</big>
* Görüş hattı (yatay ve dikey görme alanı)
* Ses sinyali gereksinimleri
* Kol, el ve başparmak için kas gücü
* Dikey çekme hareketleri için gerekli kas gücü
* Yatay çekme ve itme hareketleri için gerekli kas gücü
* Kaldırılabilecek ünitelerin azami ağırlığı
* Destek ekipmanlarının azami ağırlığı
'''<big>4.2. ERGONOMİK HUSUSLAR</big>'''
* Kumandaların tasarımı (ör. Anahtarlar, çevirme kolları, kumanda kolları, el çarkları, pedallar, düğmeler, vs.)
* Minimum tutacak ölçüleri
* Çalışma alanı tasarımı (oturarak, ayakta, mobil)
* Zor erişilebilirlik – rampa ve merdivenler
* Kapı ve erişim paneli ölçüleri
* Aydınlatma gereksinimleri
'''<big>4.3. ÇEVRESEL HUSUSLAR</big>'''
* Etkin sıcaklık
* Aşırı sıcak ve soğuk sıcaklık limitleri
* Rüzgarın soğutma etkisinin insan üzerinde etkisi
* Aşırı iklim koşullarında insan performansındaki düşmeler
* Havalandırma gereksinimleri
* Ultraviyole ışımaya maruz kalma
* Toz ve duman gibi kirliliğie maruz kalma
* Gürültü limitleri 
== EK-B HTE(K)A ve SONUÇLARININ LDA İÇERİSİNDE KULLANIMI ==
<big>'''1. GENEL'''</big>

Hata Türleri ve Etkileri Analizi (HTEA) olaya dayalı bakım analizlerinden biridir. Önleyici Bakım Analizleri ve Özel Olay Analizleri önleyici bakımlara odaklanırken HTEA ve Hasar Analizleri düzeltici bakımlara odaklanır (Hasarlar aynı zamanda önleyici bakıma da tabi olabilir).

HTEA, üründe bünyesel bir arıza oluştuğu durumda uygulanması gereken düzeltici bakım görevlerinin belirlenmesine yönelik yöntem ve karar mantığını ortaya koyar.

Bütün ekipman ve bileşenler önleyici bakım uygulansın ya da uygulanmasın hata yapmaya eğilimli olup, önleyici bakım için adaydırlar. Bazı hata/arızalar operasyon esnasında veya bir bakım görevi ya da muayene esnasında teşhis edilebilir veya gözlenebilirler (kişiler veya entegre test sistemleri vasıtasıyla). Bazı hatalar ise teşhis edilebilmekle birlikte lokalize edilemezler ve bazıları da hiç teşhis edilemezler.

Dolayısıyla birçok durumda, hatalı ünitelerin sökülmesi ve değiştirilebilmesi için öncelikle teşhis ve tespit edilmelerine yönelik ilave arıza giderme (troubleshooting) işlemlerinin yapılması gerekir. Bu işlemler:

* HTEA’dan türetilen veriler ile karakterize edilir ve LDA kayıtları altında dokümante edilmelidir,
* İlgili teknik yayınlarda dokümante edilmelidir
* Özel aletler ve test ekipmanları gerektirebilir.

HTE(K)A ve sonuçlarının LDA içinde kullanımının kapsamı:

* Mevcut dokümanlardan mümkün olduğunca yaralanmak (ör, tasarım ekibi tarafından gerçekleştirilen HTEKA) veya HTEA verisinin üzerine LDA ihtiyaçlarına göre uyarlanmış çalışma inşa etmek ya da mevcut hiçbir doküman yoksa yeni bir HTEA çalışması gerçekleştirilmesi

* Hataların tespit edilmeleri ve hatalı bileşenlerin lokalize edilmeleri için uygun vasıtaları analiz edilmesi
* Özel arıza teşhis prosedürlerine yönelik olası gereksinimlerin belirlenmesi
* Muhtemel özel alet ve test ekipmanı ihtiyaçlarının belirlemesi
* Sonuçların kayıt altına alınması

faaliyetlerini kapsar.

Süreç, ürün içerisindeki yeni geliştirilen, başka bir projeden tekrar kullanılan veya RAHAT malzeme olarak temin edilen herhangi bir bileşen için uygulanabilir.

Tasarım, geliştirme ve üretim faaliyetlerine yönelik çeşitli HTEA ve HTEKA türleri söz konusudur.

'''<big>2. TASARIM VE GELİŞTİRME FAALİYETLERİNDE HTEKA</big>'''

HTEKA, geliştirme safhasında yapılması gereken analiz faaliyetidir. Diğer taraftan ihtiyaç olması halinde (tasarım değişikliği, modifikasyon vb) ilgili safhalarda güncellenebilecek bir analizdir.

HTEKA’nın hedefi bir sistem tasarımındaki bütün hata türlerini belirlemek olmakla birlikte, birincil amacı katastrofik ve kirtik hata türlerinin erken tespit edilerek, mümkün olan en erken safhada tasarım değişiklikleri ile ortadan kaldırılması ya da minimize edilmesidir. Dolayısıyla HTEKA çalışmaları, başlangıçta ön tasarım bilgileri ortaya çıkar çıkmaz en üst sistem seviyesinde işlevsel bir HTEKA ile başlayarak daha fazla tasarım bilgisi ortaya çıktıkça alt seviyelere yaygınlaştırılarak devam eder.

HTEKA, tasarım faaliyetlerine yönelik bir güvenilirlik görevi olmasına rağmen başka amaçlarla da kullanılabilir. HTEKA veya ondan türetilmiş başka diğer analizler idame edilebilirlik, emniyet, kullanılabilirlik, LDA için ve bakım konseptinin detaylandırılması, hata tespit ve teşhisi için kullanılabilir. HTEKA’nın bu çok amaçlı kullanımı, aynı proje kapsamında gerçekleştirilen faaliyetlerin kopyalanmasının önlenmesi açısından planlama aşamasında dikkate alınmalıdır.

<big>'''3. LDA HTEA VE TASARIM YÖNELİMLİ HTEKA'''</big>

Tasarım yönelimli HTEKA’nın bir ürünün her bir komponentinin güvenilirliğini ve niceliğini belirlemesi gerekirken bu seviyede bir detay, bakım amaçları için her zaman gerekli değildir, Bakım faaliyetleri bütün komponentlere değil, daha yüksek seviyede bir kırılımda yer alan değiştirilebilir veya onarılabilir komponentlere odaklanmalıdır. Bu nedenle, LDA HTEA tasarım yönelimli HTEA ile genel olarak tutarlı olmakla birlikte birebir aynı değildir. Bu iki faaliyet arasında yeterli uyum, zamanlamanın uygunluğu ve izlenebilirliği sağlamak açısından sıkı ara yüzler tanımlanmalı ve koordinasyon gerçekleştirilmelidir.

Tasarım HTEKA ve LDA HTEA arasındaki temel fark, tasarım açısından farklı olan bazı hata türleri, nihayetinde aynı bakım faaliyetine yol açıyorlarsa LDA HTEA açısından gruplanarak tek bir hata modu gibi ele alınabilir.

<big>'''4. LDA HTEA VE İDAME EDİLEBİLİRLİK, BAKIM VE EMNİYET ANALİZLERİ'''</big>

İdame edilebilirlik, bakım ve emniyet analizleri gibi diğer analizler LDA HTEA’dan veri kullanabilir veya tasarım HTEKA’dan türetilebilir (ör. OSA, GMB ve PBA gibi). Mevcut çalışmalardan azami fayda sağlamak ve tekrarlamaları önlemek için bu analizlerin de HTEKA ve LDA HTEA ile sıkı bir biçimde koordine edilmesi gerekir.

== EK-C HASAR VE ÖZEL OLAY ANALİZLERİ ==
'''<big>1. GENEL</big>'''

Sistemin kullanımı esnasında meydana gelebilecek özel olaylar ve hasarların sistem kullanımına etkileri ve bu durumlar karşısında uygulanması gereken bakım faaliyetlerinin belirlenmesi amaçlanmaktadır. Bu bakım faaliyetleri tüm bakım konseptini etkileyeceğinden analiz edilmeleri kritiktir. Özel olaylar ve hasar durumları tanımlandıktan sonra BGA kapsamında analiz edilirler. Elde benzer sistemlerle ilgili kullanım verilerinin olması durumunda, bu bilgilerin de mutlaka referans alınmaları gerekmektedir. Hasar ve özel olay analizleri, geliştirme safhasının kavramsal tasarım aşamasında yapılması gereken bir analiz faaliyetidir. Diğer taraftan ihtiyaç olması halinde (tasarım değişikliği, modifikasyon vb) ilgili safhalarda güncellenebilecek bir analizdir.

Olası tehlikelerin tanımlandığı ve bu tehlikelerin analiz edildiği (tehlikelerin neler olduğuna, hangi ömür evresinde meydana gelebileceğine, ciddiyetine, meydana gelme olasılığına ve alınacak önlemlere ilişkin bilgileri kapsayan) emniyet analizleri kapsamında gerçekleştirilen Ön Tehlike Analizi sonuçları hasar ve özel olay analizi için girdi olacaktır.

Bakım uygulaması gerektiren bazı özel olay örnekleri;

* Sıcaklık limitlerinin aşılması
* Mekanik yükleme limitlerinin aşılması (örneğin aşırı torklama)
* Nakliye ömür evresinde izin verilen araç hız limitlerinin aşılması
* Korozif ortamda sistemin operasyonel kullanımı
* Kumlu ortamda sistemin kullanımı
* Yıldırım çarpması
* Sistemin entegre olduğu harici uçar platformun ani iniş yapması
* Harici nesnelerle çarpışma

Aşağıda hasar ve özel olay analizi kapsamında kullanılan terimler ve tanımları verilmiştir.
{| class="wikitable"
|'''Hasar (damage)'''
|''':'''
|Fonksiyonelliğin kaybı ya da azalmasıdır (sistemin doğal arızaları hariç). Bir hasar durumu karşısında tanımlanmış bir bakım görevi gerekecektir. Sistem özelinde hasarlar belirlenirken gruplara ayrılabilir; örneğin, çizikler, oyuklar ve çatlakların bir hasar ailesi olarak belirlenmesi gibi.
|-
|'''Harici sebep (external cause)'''
|''':'''
|Sistemin kullanımından bağımsız olarak meydana gelen durumdur.
|-
|'''Dahili sebep (internal cause)'''
|''':'''
|Yalnızca sistem kullanımının bir sonucu olan durumdur.
|-
|'''Özel olay (special event);'''
|''':'''
|Sistemin ömrü boyunca meydana gelebilecek ve normal kullanım olarak düşünülmemiş olaydır. Dış sebeplerden (meteorolojik olaylar gibi) ya da kullanım dışı durumlardan (bir uçağın aşırı ivmelenmesi) kaynaklı olabilir.
|}
<big>'''2. ANALİZ SÜRECİ'''</big>

<big>'''2.1. ÖZEL OLAYLARIN TANIMLANMASI'''</big>

1. Adım; özel olayların tanımlanması kapsamında, ilk olarak bir olay yaratabilecek farklı sebeplerin listelenmesi gerekir. Olaylar harici veya dahili sebeplerden kaynaklı olabilir ve doğal olaylardan ya da insan hatalarından etkilenebilir. Tablo 13’de olayların sebeplerine örnekler verilmiştir.

Hasarlar ise, her bir durum için kritikliğinin ya da derecesinin verilemediği özel olaylardır. Bu nedenle, aynı yolla meydana gelebilen ya da aynı yolla tespit edilebilen hasarların da özel olay analizi kapsamında ele alınması gerekmektedir.

'''Tablo 13 Olayların Sebep Tiplerine İlişkin Örnekler'''
{| class="wikitable"
| colspan="2" |'''Sebep Tipleri'''
|'''Örnekler'''
|-
| rowspan="4" |Harici sebepler (external causes)
|Doğal sebepler
|Meteorolojik sebepler
|-
|İnsan kaynaklı sebepler
|Kullanım, taşıma vb. hataları
|-
|Operasyon çevresinden kaynaklı sebepler
|· Elektromanyetik alan

· Yüksek akım

· Tozlu, kumlu ortam
|-
|Nakliye, depolama koşullarından kaynaklı sebepler
|· Şok

· Titreşim

· Basınç
|-
| rowspan="2" |Dahili sebepler (internal causes)
|Olağan dışı kullanımdan kaynaklı sebepler
|Operasyon limitlerinin dışına çıkılması - ani iniş, aşırı ivme gibi
|-
|İşlev bozukluklarından kaynaklı sebepler
|Aşırı ısınma
|}
2. adım; özel olaylar tanımlandıktan sonra, bu özel olayın sistemin hangi ömür evresinde (kullanım, bakım, depolama, nakliye vb.) meydana geleceğinin tanımlanması gerekmektedir. Örneğin, kullanım ya da nakliye için hazırlık süresince elle taşımanın dış yüzeye olan etkisi ya da kullanım ömür evresinde sistemin mekanik kısımlarında meydana gelen beklenmeyen aşınmalar gibi.

3. Adım; özel olaylar belirlendikten sonra her bir olayın meydana gelme olasılığı analiz edilmelidir.

'''Tablo 14 Olayların Meydana Gelme Olasılıkları'''
{| class="wikitable"
|'''Puanlama'''
|'''Meydana gelme'''
|'''Açıklama'''
|-
|1
|Son derece düşük ihtimal
|Meydana gelme olasılığı sıfıra yakındır.
|-
|2
|Düşük ihtimal
|Meydana gelme ihtimali pek mümkün değildir. Özel olaylar seyrek olarak meydana gelir.
|-
|3
|Ara sıra
|Arada sırada (sadece birkaç özel olay) meydana gelebilir.
|-
|4
|Olası
|Meydana gelme ihtimali orta seviyededir.
|-
|5
|Sık
|Meydana gelme ihtimali çok yüksektir.
|}
4. Adım; özel olayların meydana gelme olasılıklarına bağlı olarak, bu olayların bakım gerektiren ya da hiçbir analiz gerektirmeyen şeklinde gruplandırılmaları gerekmektedir.

'''<big>2.1. POTANSİYEL ARIZALARIN TANIMLANMASI</big>'''

Sistem tasarımında kullanılan teknolojinin değerlendirilmesi iki bakış açısı ile yapılabilir;

* Teknoloji yeni geliştirilen mi yoksa hali hazırda kullanılan bir teknoloji mi?
* Teknoloji hasara karşı dayanıklı mı yoksa hassas mı?

1. Adım; sistemin tüm alt sistem ve kalemleri için kullanılan teknolojiler tanımlanmalıdır. Tablo 15’te teknoloji seviyeleri ve açıklamaları ile bunların puanlama bilgileri verilmiştir.

'''Tablo 15 Teknoloji Seviyeleri'''
{| class="wikitable"
|'''Puanlama'''
|'''Teknoloji seviyesi'''
|'''Açıklama'''
|-
|1
|İyi bilinen
|Birçok benzer projede kullanılmış bir teknolojidir.
|-
|2
|Bilinen
|Birçok benzer projede kullanılmış bir teknoloji olup, ilgili proje kapsamında modifikasyonlar söz konusudur.
|-
|3
|Tamamen yeni
|Yakın zamandaki projelerde kullanılmış bir teknoloji olup, çok az geri bildirim olmuştur.
|}
2. Adım; teknolojinin hassasiyetinin değerlendirilmesi. 1. Adım’da tanımlanan her bir teknoloji için, meydana gelebilecek olası hata tiplerinin tanımlanması gerekir. (Örneğin, metaller üzerinde meydana gelebilecek korozyon ve bu korozyonun tipleri, montaj yerlerinde meydana gelebilecek gerilme korozyonu gibi). Teknoloji hassasiyetinin değerlendirilmesi Tablo 16’de verilmiştir.

'''Tablo 16 Teknoloji Hassasiyetinin Değerlendirilmesi'''
{| class="wikitable"
|'''Puanlama'''
|'''Hassasiyet Derecesi'''
|'''Açıklama'''
|-
|1
|Aşırı düşük
|Bu teknoloji için ürünün ömrü boyuncaki hasar ihtimali aşırı düşüktür.
|-
|2
|Düşük
|Bu teknolojinin hasar ihtimali çok düşüktür.
|-
|3
|Orta
|Bu teknolojinin hasar ihtimali düşüktür.
|-
|4
|Yüksek
|Bu teknolojide ürünün ömrü boyunca muhtemelen hasar meydana gelecektir.
|-
|5
|Aşırı Yüksek
|Bu teknolojide ürünün ömrü boyunca hasar meydana gelmesi durumu çok olasıdır.
|}
Adım 3; teknoloji tanımlanması ile hassasiyet oranı birlikte değerlendirilerek seçim eşiği (selection threshold) tanımlanır. Seçim eşiği de proje ihtiyaçlarına bağlı olarak belirlenebilir. Teknoloji-hassasiyet değerlendirmesi Tablo 17’da verilmiştir.

'''Tablo 17 Teknoloji-Hassasiyet Değerlendirmesi'''
{| class="wikitable"
| colspan="2" rowspan="2" |
| colspan="5" |Hassasiyet Derecesi
|-
|1
|2
|3
|4
|5
|-
| rowspan="3" |Teknoloji Seviyeleri
|1
|1
|1
|2
|3
|4
|-
|2
|1
|2
|3
|3
|4
|-
|3
|2
|3
|4
|4
|4
|}
'''<big>2.2. ÜRÜNÜN ELEMAN YA DA KISIMLARININ TANIMLANMASI</big>'''

1. Adım; seçilen her bir özel olay için ürün ağacı üzerinden etkilenen kalemler tanımlanmalıdır.

2. Adım; seçilen teknoloji ve hasarlar için ürün ağacı üzerinden etkilenen kalemler tanımlanmalıdır.

3. Adım; bir önceki adımlarda tanımlanan ürün ağacı kalemleri için farklı tehditlere maruz kalmaları durumunda tasarımlarının analiz edilip gerekirse sonuçlar tasarım girdisi olarak tanımlanmalıdır.

<big>'''2.3. KRİTİKLİK ANALİZİ'''</big>

Her bir potansiyel hasarlanabilir kalem için, sistemin hizmet ömrüne olan etkisini ifade edecek şekilde kritikliklerinin değerlendirilmesi gerekmektedir. Bunun için aşağıdaki sorulara verilen cevapların herhangi biri ‘evet’ ise kritik olduğu değerlendirilebilecektir.

* Hasar emniyeti tehdit eden seviyelerde mi sonuçlanıyor?
* Hasar kullanılabilirliğin tehdit edilmesi ile mi sonuçlanıyor?
* Hasar önemli mülkiyet kaybı ile mi sonuçlanıyor?
'''<big>2.4. BAKIM GÖREV GEREKSİNİMLERİNİN TANIMLANMASI</big>'''

Tanımlanmış özel olaylar ve hasarlar karşısında gerçekleştirilmesi gereken bakım görevlerinin tanımlanması gerekmektedir.

Meydana gelebilecek her bir hasarın tespit edilmesinin, lokalizasyonunun, ölçülmesinin veya takibinin yapılması (görsel muayene, tahribatsız muayene gibi) ile sistemin fonksiyonunun eski haline getirilmesi (örneğin, sökme ve takma görevleri, onarım görevleri) kapsamında uygulanması gereken tüm faaliyetlerin belirlenmesi gerekmektedir. Bakım görevleri BGA kapsamında belirlenecektir.

== EK-D LOJİSTİK İLİŞKİLİ OPERASYONLAR ANALİZİ ==
<big>'''1. GENEL'''</big>

Sistemin bakım ve onarım faaliyetlerine ek olarak, operasyon ve kullanımı ile ilgili durumlar da söz konusu olduğundan; sistemin kullanılabilirliği, kullanım esnekliği, mobilitesi gibi hususlara ilişkin sınırların tanımlanması ve bu gibi hususlara ilişkin bilgilerin ilgili el kitaplarında tanımlanması hem sistemin doğru kullanımı hem de saha verilerinin doğru bir şekilde toplanması açısından gerekmektedir. Diğer taraftan, bu hususlar garanti dönemini kapsayan uygulamaları da doğrudan etkileyecektir. Lojistik ilişkili operasyonlar sistemin direkt olarak kullanımının ya da bakımının dokümante edildiği ilgili dokümantasyonlara atanamasa da sistemin uygun kullanımı açısından önem taşımakta olup bu bilgilerin de dokümantasyonlara eklenmesi gerekmektedir.

Lojistik ilişkili operasyonların tanımlanması (personel, destek ekipmanı, sarf malzemeler, yedek parçalar, eğitim vb. gereksinimlerle ilişkili) lojistik analiz faaliyetleri için önemli girdiler oluşturacaktır. Sistemin kullanım konsepti bilgileri ile birlikte, lojistik ilişkili operasyonların bazıları sistem ömür döngüsünün konsept safhasında göz önünde bulundurulurken, bazıları daha sonraki safhalarda (örneğin prototiplerin üretilmesiyle ya da BGA analizinin yapılmasıyla birlikte) ele alınabilir. Diğer taraftan, lojistik ilişkili operasyonlar analizi ihtiyaç olması halinde (tasarım değişikliği, modifikasyon vb) ilgili safhalarda güncellenebilecek bir analizdir.

'''<big>2. ÜRÜN KULLANIM DESTEĞİ</big>'''

'''<big>2.1. KULLANIMA HAZIRLIK</big>'''

Sistemi operasyona hazırlamak için sistemi kullanıma hazırlama kapsamında yapılması gereken bakım faaliyetleri dışında kalan diğer gerekli faaliyetlerin tanımlanması gerekmektedir. Sistemin doğru kullanım için yanal sistemlerin ve/veya parçaların hazırlanması buna örnek olarak verilebilir. Tipik kullanıma hazırlama görevleri servis görevleri olarak sınıflandırılabilir (bir uçağa özel bir ekipman ekleyerek keşif görevine hazırlamak gibi).

<big>'''2.2. YÜKLEME VE İNDİRME'''</big>

Kargo olarak taşıması olan her bir ürün için yükleme ve indirme prosedürleri projenin erken safhalarında analiz edilmelidir. Örnek olarak, ne tarz bir kargo taşımasının planlandığı, hangi boyut ve ağırlık parametrelerinin göz önünde bulundurulduğu, kargonun özel etkilere (ivme, manyetik alan, nem vb.) hassasiyeti olup olmadığı, yanlış kullanım sonucu kargonun kritik ve tehlikeli durumlara sebebiyet verip vermeyeceği, ne tarz bir kargo güvenliği gerektiği verilebilir. Ayrıca yükleme/indirme ve kargo güvenliği için özel bir ekipman gerekip gerekmediği, topraklama ihtiyacının olup olmadığı da değerlendirilmelidir.

'''<big>3. PAKETLEME, ELLEÇLEME, DEPOLAMA VE ULAŞTIRMA (PEDU)</big>'''

Tipik PEDU görevleri, paketleme, koruma, güvenlik önlemleri, depolama, taşıma, ulaştırma, çekme, istifleme, kaldırma olarak tanımlanabilir.

'''<big>3.1. PAKETLEME</big>'''

Paketleme ve paketten çıkarma için asgari düzeyde aşağıdakiler değerlendirilmelidir:

* Paketleme uzun süreli mi kısa süreli mi depolama için yapılacak?
* Taşıma yapılacak mı, yapılacaksa ne tarz bir taşımaya göre paketleme yapılacak?
* Depolama ve taşıma için özel bir sandık, kutu vb. gerekiyor mu?
* Depolama ve taşıma periyodunda sıradışı iklim koşulları için özel bir koruma gerekiyor mu?
* Taşıma ve depolama esnasında sistemin bir bakım görevini gerçekleştirmek için paketlemesini açmak ve tekrar paketlemek gerekiyor mu?
* Paketlemeyi açmak için destek ekipmanı ve tesisi ilgilendiren bir durum var mı?
'''<big>3.2. ELLEÇLEME</big>'''

Elleçleme için asgari düzeyde aşağıdakiler değerlendirilmelidir:

* Sistemi taşırken gerekli olan güvenlik önlem ve limitleri nelerdir?
* Sistemin normal kullanımından farklı olan çekme, vinçle kaldırma ve hareket ettirme için gerekli yönlendirmeler nelerdir?
* Sistem elleçlenirken ekstra ekipman ve malzemeler gerekiyor mu?

Taşıma, yükleme, onarım, bakım vb. için sistemin kaldırma konsepti belirlenmelidir. Ürünün hem kendisinin hem de komponentlerinin kaldırılması söz konusuysa onlar da düşünülmelidir.

'''<big>3.3. DEPOLAMA</big>'''

Ürünün fonksiyonelliğini depolama esnasında ve depolama sonrasında da garanti etmek için depolama prosedürleri analiz edilmeli ve dokümante edilmelidir. Depolama için asgari düzeyde aşağıdakiler değerlendirilmelidir:

* Depolama çözümü kısa döneme yönelik mi uzun döneme yönelik midir?
* Depolanacak ürünün özel bir hassasiyeti var mıdır?
* Depolanacak üründen komponent çıkarmak ve bu komponentleri özel koşullar altında ayrıca depolamak gerekiyor mu?
* Depolama esnasında sıradışı iklim koşullar var mı?
* Depoya giriş için özel teknikler (temizleme, koruma, özel parçaların çıkarılması vb.) gerekiyor mu?
* Depodan çıkarma ve tekrar depoya koyma için özel teknikler (fonksiyonel kontroller, kullanım hazırlığı vb.) gerekiyor mu?
* Depolama periyodu için ne tarz güvenlik önlemleri gerekiyor? (ör. Hareketli parçaları bloklamak, ışığa karşı koruma sağlamak vb.)
* Depolama zamanı ürünün ömründen sayılacak mı?
<big>'''3.4. İSTİFLEME'''</big>

Depolama ve taşımanın bir parçası olan istifleme kapsamında gerekli güvenlik gereksinimleri tanımlanmalıdır. Depolamada itme vb. durumların gerçekleşme ihtimali varsa bu durumda sistem davraşının ne olacağı değerlendirilmelidir.

'''<big>3.5. TAŞIMA</big>'''

Taşıma için asgari düzeyde aşağıdakiler değerlendirilmelidir:

* Taşımaya hazırlık ve taşıma sonrası için gereken süre ve efor nedir?
* Taşımaya hazırlık ve taşıma sonrası için gereken personel, ekipman, sarf malzemesi ve tesisler nelerdir?
* Özel koşullarda taşıma için gereken çevresel ve güvenlik gereksinimleri nedir?
* Taşıma periyodu için gerekli servis aksiyonları var mıdır?
* Taşıma için üründen komponent çıkarmak gerekli midir?
* Taşıma sandığı konsepti olacak mı?
* Taşımada kızak ve palet kullanımı olacak mı?
'''<big>3.6. BAĞLAMA</big>'''

Bağlama kısa ya da uzun vadeli olarak, ürünü bir yere sabitlemek veya bir taşıma aracının içinde sistemin güvenli olarak bulunmasını sağlamaktır. Özel teknikler (ör. Denge ağırlığı, bağlama noktaları, bağlama esnasında gerekecek ekipman vb.) de değerlendirilmelidir.

'''<big>4. ENVANTERDEN ÇIKARMA VE GERİ DÖNÜŞÜM</big>'''

Sistemin (mühimmat, silah sistemi, destek ekipmanı vb.) envanterden çıkarma prosedürlerinin tanımlanmış olması gerekmektedir. Ayrıca tek kullanımlık sistemlere ait taşıma saklama kutuları için uygulanabilir olması için geri dönüşüm metotları da tanımlanmalıdır.

'''<big>5. LOJİSTİK İLİŞKİLİ OPERASYONLAR İÇİN KONTROL LİSTESİ</big>'''

Tüm faaliyetler (ayarlama, sızdırma, kalibrasyon, kontrol, temizleme, koruma, taşıma sandığı konsepti, tuzdan arındırma, envanterden çıkarma, kaldırma, yükseltme, kargoya yükleme, paketleme, geri dönüşüm, ikmal, güvenlik önlemleri, istifleme, depolama, taşıma, kargodan indirme, paketlemeyi açma, vinçle kaldırma vb.) ve bu faaliyetlerin sistemin hangi ömür evresinde gerçekleştirileceği/uygulanacağı belirlenmeli ve özel bir destek ekipmanı gerekliliği ile bu faaliyetlerin tasarım üzerinde bir etkisi olup olmadığı kontrol edilmelidir.

== EK-E PLANLI BAKIM PROGRAMI GELİŞTİRME ==
'''<big>1. GENEL</big>'''

Planlı bakım programının geliştirilmesi ile amaçlanan, planlı bakım görevlerinin yerine getirilmesi kapsamında ürünün Operatör Bakım Planının (Operator Maintenance Plan) geliştirilmesi için süreçleri ve kuralları tanımlamaktır. Planlı bakım görevleri de aslen Önleyici Bakım Görev Gereksinimlerinden (PMTR - Preventive Maintenance Task Requirements) ortaya çıkmaktadır.

Önleyici Bakım Görev Gereksinimleri ile ilişkili sistem ya da ekipman/kalemler otomatik olarak LDA adayı kalem olacaktır. LDA adaylarına atanmış tüm Planlı Bakım Görev Gereksinimleri daha sonra BGA’ya (bkz.EK-G BAKIM GÖREV ANALİZİ) tabi tutulacaktır. Planlı bakım programı geliştirme faaliyeti geliştirme safhasından başlar. Diğer taraftan ihtiyaç olması halinde (tasarım değişikliği, modifikasyon vb) ilgili safhalarda güncellenebilecek bir analizdir.

'''<big>2. ANALİZ YÖNTEMLERİ</big>'''

Önleyici Bakım Görev Gereksinimlerinin belirlenmesi kapsamında üç farklı analiz metodu tanımlanmıştır. (Analizler hakkında detaylı bilgi için; bkz. ‘S4000P International specification for developing and continuously improving preventive maintenance’.)

* '''Sistem analizi (System analysis)'''

Ekipman ve kalemleri de kapsayan sistem için uygulanabilir ve etkili Önleyici Bakım Görev Gereksinimlerinin geliştirilmesi için kullanılan bir analiz yöntemidir. Ürün kırılım yapısına bağlı olarak, bu sistemler tasarım HTEKA’sına göre şeffaf bir şekilde analiz edilir. Sistemin veya analiz edilen bir kısmının bakım yapılamaz olarak varsayılması durumunda, bununla ilgili geri bildirim mutlaka sağlanmalıdır.

* '''Yapı Analizi (Structure Analysis)'''

Ürünün mekanik yapısı için uygulanabilir ve etkili Önleyici Bakım Görev Gereksinimlerinin tanımlanması kapsamında yapılan analizdir. Analiz kapsamında, yorulma analizi sonuçları, çevresel bozulma (environmental deterioration) parametreleri, kazara oluşan hasar etkileri (accidental damage impacts) göz önünde bulundurulur.

* '''Bölgesel Analiz (Zonal Analysis)'''

Ürünün tipine ve kullanım alanına göre bağlı olarak yapılabilecek analizler;

Standart Bölgesel Analiz

Gelişmiş Bölgesel Analiz

Yüksek yoğunluklu radyasyon alanları analizi

'''<big>3. ÖNLEYİCİ BAKIM GÖREV GEREKSİNİMLERİ İÇİN EŞİKLER, ARALIKLAR VE TETİKLEYİCİ OLAYLAR</big>'''

Tek bir Önleyici Bakım Görev Gereksinimi için, planlı eşiklerin, aralıkların ya da tetikleyici olayların farklı tipleri seçilebilir;

* Bir kere yap eşikleri (perform once); örneğin silah sistemi üzerinden belirli sayıda füzenin ateşlenmesi sonrasında tetik mekanizmasının kontrol edilmesi ya da belirli bir süre kullanım sonrasında silah sistemi üzerinde bulunan özel vidaların torklarının kontrol edilmesi şeklinde tanımlanan bakım görevi. Periyodik aralıklarla tanımlanan bakım görevleri birbirine paralel de olabilir; belirli bir kullanım süresi sonunda silah sistemi üzerinde bulunan özel vidaların değiştirilmesi ve aynı zamanda her beş yılda bir kez ilgili vidaların değiştirilmesi gibi.

* Periyodik aralıklar (Periodical); örneğin, tanımlanmış her bir kullanım süresi sonunda (örneğin 3 yılda bir) silah sistemi üzerinde bulunan özel vidaların değiştirilmesi.
* Bir kere yap eşikleri ile periyodik aralıkların kombinasyonu; örneğin 500 döngülük kullanım sonrası ilk muayenenin yapılması (bir kere yap eşiği-PO) ve sonrasında her 1000 döngülük kullanım sonrası periyodik muayene.
* Periyodik aralıklar ile tetikleyici olayların kombinasyonu; örneğin her 1000 döngülük kullanım sonrası periyodik muayene şeklinde tanımlanan bakım görevi, periyodik yapılan bu muayeneler esnasında karşılaşılan bir olay sonucu periyodik bakım görevlerinin her 800 döngüde yapılmasının bakım görevi olarak tanımlanması.

Bakım görev gereksinimleri belirlenirken, sistemin tasarım ve geliştirmesi için esas alınan kullanım parametreleri kapsamında kullanım durumu mutlaka değerlendirmelidir. Önleyici Bakım Görev Gereksinimleri için belirlenecek aralıklar aşağıda belirtilenlere bağlı olabilir;

* Ürün kullanım parametreleri (örneğin, kullanım saatleri, döngü, katedilen mesafe gibi)
* Takvim bazlı parametreler (ana aralık olarak takvim bazlı parametreler seçilirse eğer ürünün gerçek kullanım yoğunluğu, planlı ürün bakım eforuna etki etmeksizin değişebilir. Diğer taraftan gerçek kullanım yoğunluğu, kullanıma yönelik olan ana aralıklar ile daha iyi gösterilecektir.)

* Ürün kullanımı ve takvim bazlı parametrelerin kombinasyonu
* Tanımlanmış etkili ve uygulanabilir her bir önleyici bakım görev gereksiniminin, fonksiyonel hata etkisinin kritikliğine göre en kötü senaryo karşısında kendine özgü durumu vardır. Kritiklik kategorisi, aralıkların artmasına ya da azalmasına karar vermeyi mümkün kılacaktır.

* Tanımlı önleyici bakım görev gereksinimleri tek bir bakım seviyesinde ya da birden fazla bakım seviyesinde gerçekleştirilebileceğinden, aralıklar tanımlanırken bu husus da göz önünde bulundurulmalıdır.
* Aralıkların uzatılması hata sebeplerinin ortaya çıkarılamaması riski artıracak fakat bakım maliyetleri azalacaktır.
* Aralıkların azaltılması durumunda ise hata sebeplerinin (Failure Causes) ortaya çıkarılması ile ilgili risk azalacaktır ancak bakım maliyetleri artacaktır.
* Fonksiyonel hata etkisi emniyet ile ilgili olan durumlarda aralık uzatılmamalıdır.
'''<big>4. TANIMLANACAK ÖNLEYİCİ BAKIM GÖREV GEREKSİNİMLERİNİN (PMTR) BELİRLENMESİ İÇİN KULLANILABİLECEK KAYNAKLAR</big>'''
* Yasal düzenlemelerden gelen gereksinimler
* Emniyet Analizi/hata ağacı analizinden gelen gereksinimler
* Yapısal muayeneler ile ilgili yorulmalar
* Üretici firma tarafından belirlenen gereksinimler
* Mühendislik yaklaşımları
* Diğer projelerden edinilen tecrübeler
* Depolama kriterlerine bağlı öngörülen planlı faaliyetler

İlerleyen analiz aşamalarında ortaya çıkan potansiyel bakım problemlerinin tespit edilebilmesi açısından, görev uygulanabilirliği ve etkinliği ile ilgili yapılmış olan varsayımları doğrulayabilmek için geri bildirimlerin sağlanması önemlidir.

'''<big>5. KULLANICI BAKIM PROGRAMININ GELİŞTİRİLMESİ</big>'''

Bir önleyici bakım görev gereksiniminin tip ve değer olarak bir tane ya da tip ve değerin kombinasyonlarından oluşan iki ya da daha fazla aralığı vardır. Eğer birden fazla aralık tanımlanmışsa, kullanım senaryosuna bağlı olarak ilk gelen aralık ile bakım başlatılır.

Her bir önleyici bakım gereksiniminin başlangıç aralık tipleri ve değerleri ile birlikte bakım seviyelerinin, personel, destek ekipmanı, yedek parça, teknik dokümantasyon gibi gerekli kaynakların belirlenmesi için BGA ve OSA kapsamında analiz edilmesi gerekmektedir.

Önleyici bakım görev gereksinimlerinin dokümantasyonunun ve sistem entegrasyon standartlarına göre geçerlilik onayının tamamlanmasından sonra, daha sonraki sistem bakım programı için ana görev paketlerinin aralıklarının tanımlanması ve asgari aşağıdaki hususların dokümante edilmesi gerekmektedir;

* Kullanım senaryoları ve sapmalar
* Ana görev paketlerinin aralık tipleri ile ilgili alınan kararlar/tahminler
* Aralıkların uyarlanması için hesaplama kuralları (örneğin, güvenilirlik değerleri ile kullanım saatlerinin birlikte değerlendirilmesi durumu)

Örneğin;

Bir silah sistemi için emniyet ilişkili bir önleyici bakım görev gereksinimi kapsamında, her 600 saatlik kullanım saatinde görsel muayene yapılması durumunda, herhangi bir ‘bir kez yap eşiği’ (perform once threshold) olmadan periyodik aralık 600 kullanım saati olacaktır. Önleyici bakım görev gereksinimi kategorisi de emniyet olacaktır.

Kullanım senaryosu; Silah Sisteminin bir takvim yılı içerisinde azami 1000 kullanım saati ile kullanılacağı planlanmıştır. Ana görev paketi için aralık tipinin kullanıcı tarafından takvim bazlı olmasına karar verilmiştir (Emniyet kritik durum göz önünde bulundurulduğunda, 600 saatlik muayene gerekliliğini sağlayacak şekilde her altı ayda bir muayene yapılması, senede bir kez de kapsamlı muayene yapılması şeklinde).

Bu kullanım senaryosundaki limitlere göre, birinci planlı görevin, 600 kullanım saatlik periyodik aralığı aşmayan ana görev paketleri kapsamında yerine getirilmesi gerekmektedir. Bu nedenle planlı görevin 500 kullanım saatini kapsayan her altı ayda bir yerine getirilmesi gerekir. Azami 1000 kullanım saati ile ilişkili her yıl gerçekleştirilecek bir görevin seçimine emniyet açısından aralık aşımı söz konusu olduğu için izin verilmemelidir.

Tüm önleyici bakım görev gereksinimleri için BGA kapsamında aşağıdaki hususların değerlendirilmesi gerekmektedir;

* Tek bir faaliyetin ve/veya bakım görevlerinin potansiyel karşılıklı bağımlılık durumu (örneğin, bir bakım görevi başlamadan bir diğerinin tamamlanmış olması gerekliliği)
* Potansiyel bir zaman tasarrufu, bir kez erişim sağlandıktan sonra görevlerin yerine getirilmesi ile sağlanabilir. (Örneğin; sistemde bulunan bir kapak açıldığında gerekli tüm görevlerin yerine getirilmesi)
* Sürenin etkili kullanılabilmesi için paralel yapılması gereken görevlerin mutlaka göz önünde bulundurulması
* Planlı bakım görevleri her zaman ardışık olarak yerine getirilmez, birbirine paralel olabilir ya da kısmen birbirinden bağımsız olabilirler, bu husus da göz önünde bulundurulmalıdır.

Diğer taraftan, farklı bakım seviyeleri, periyodik aralıklar ve bir kez yap eşikleri (eğer varsa) ile tanımlanan önleyici bakım görev gereksinimlerini etkileyeceğinden bu hususların da OSA kapsamında dikkate alınması gerekmektedir.

Önleyici bakım görev gereksinimleri, proje kapsamında uygulama kolaylığı sağlanacağı değerlendirildiği durumda üç ana grup altında toplanabilirler.

* Sistemin kullanıma/göreve başlamasından önce
* Sistemin kullanım veya görevine anlık kısa bir ara verilmesinden sonra
* Ürünün kullanım veya görevini tamamlanmasından sonra
'''<big>6. GÜVENİLİRLİK MERKEZLİ BAKIM (GMB) ANALİZİ YAKLAŞIMI</big>'''

GMB sistemin doğal güvenilirliğini kaynakların minimum israfı ile sürdürebilmesi için gerekli olan planlı bakım görevlerinin tanımlandığı analiz yöntemidir.

Sistemdeki olası hataların, sırasıyla emniyet ve çevre, görev ve kullanım ile maliyet üzerine olan etkileri incelenir. Buna göre gerçekleştirilecek faaliyetlere ilişkin önceliklendirme yapılmış olur. GMB hataların öncelikle planlı bakım faaliyetleri ile önlenmesini ve önlenemiyorsa da hataların etkilerini kabul edilebilir seviyeye indirmeyi amaçlayan güvenilirlik odaklı LDA faaliyetidir.

Şekil 19’da GMB kapsamında hata türlerine bağlı olarak bakım görevlerinin tanımlanması ile bu görevlerin analizinin yapılması için BGA’ya olan girdiler gösterilmiştir.
[[Dosya:Şekil19GMB – BGA Arayüzü.jpg|alt=|sol|küçükresim|650x650pik|Şekil 19 GMB – BGA Arayüzü]]

== EK-F ONARIM SEVİYESİ ANALİZİ (OSA) ==
'''<big>1. GENEL</big>'''

OSA maliyet, güvenilirlik değerleri, bakım yapılabilirlik/test edilebilirlik kısıtlamaları ya da hazır bulunurluk gibi amaçların da gözetildiği; onarma, yenisi ile değiştirme gibi kararların alındığı ve ilgili görevler için bakım seviyelerinin belirlendiği analiz çalışmasıdır. Analiz sonuçları bakım görevlerini ve bu görevlerle ilişkili ekipman, personel, yedek parça gibi kaynakları doğrudan etkiler. OSA’nın amacı optimum bakım çözümüne karar vermektir.

Bir bileşenin doğasından kaynaklı olarak onarılabilir ya da onarılamaz olduğu bilgisi BGA’da belirlenir. OSA’nın ilk adımı ise bu kalemlerden onarılabilir olanların ekonomik maliyet kriterleri ile ekonomik olmayan kriterlerin göz önünde bulundurularak analiz edilmesidir. BGA’da onarılabilir olarak belirlenen kalem için OSA sonrasında değerlendirme kriterlerine göre yenisi ile değiştirilmesi kararı verilebilir.

OSA yaparken her bir seviyedeki, her bir bakım merkezindeki imkân ve kabiliyetlerin neler olduğunun önceden bilinmesi gerekir. Hat üzerinde sökülen ünitelerden başka, bunların içinin nerelerde açılabileceği, onarım sırasında üzerlerinde parça değişikliği yapılıp yapılmayacağı, onarımı mümkün değilse nerede envanterden çıkarılacağı belirlenir.

OSA BGA’yı tamamlayıcı niteliktedir. Saha inceleme rapolarının, mühendislik verilerininin ve proje gereksinimlerinin girdi olarak kullanıldığı OSA, tasarımın netlik kazanması ile geliştirme safhasında bakım görev analizine paralel bir şekilde yürütülür. Diğer taraftan ihtiyaç olması halinde (tasarım değişikliği, modifikasyon vb) ilgili safhalarda güncellenebilecek bir analizdir.

'''<big>2. ANALİZ SÜRECİ</big>'''

Sistemler için onarım seviyeleri genellikle ikiye veya üçe ayrılır:

a) Operasyonel seviyede (O-level) bakım-onarım

b) Ara seviyede (I-level) bakım-onarım

c) Fabrika/Depo seviyesinde (D-level) bakım-onarım

Analiz sonuçlarına göre her bir ekipman için, “Kaynak, Bakım ve Onarım” (Source, Maintenance and Recoverability – SM&R codes) kodlaması yapılır. Buna göre; bir ekipmanın arızası olduğunda onarım yapılıp yapılmayacağı, yenisiyle değiştirilip değiştirilmeyeceği, onarılamıyorsa envanterden çıkarılıp çıkarılmayacağı bilinir.

Analiz, yedek parça ile arızayı tespit etmek ve onarımını gerçekleştirmek için gerekli olan destek ekipmanı, personel, eğitim, teknik dokümantasyon gibi başlıca ekonomik maliyet faktörleri kullanılarak yapılır. Ayrıca, kullanıma hazır olma gereksinimleri, güvenilirlik, bakım yapılabilirlik gibi ekonomik olmayan faktörler de göz önünde bulundurulmalıdır. Bu faktörlerin, sistem için gereksinim önceliklendirmesine göre değerlendirilmesi yapılmalıdır. OSA süreç adımları Tablo 18’de yer almaktadır.

'''Tablo 18 Onarım Seviyesi Analizi Süreç Adımları'''
{| class="wikitable"
|'''İŞLEM ADIMI'''
|'''TANIMI'''
|'''GİRDİLER'''
|'''ÇIKTILAR'''
|-
| rowspan="2" |1
|Onarım Seviyesi Analizi yapılacak donanım kalemleri belirlenir
|<nowiki>- Kırılımlı Parça Listesi</nowiki>
|<nowiki>- Analizi yapılacak ekipman ve cihazların listesi</nowiki>
|-
|Donanım ürünlerinin üst seviye, alt seviye kırılımları saptanır. Parça listesindeki ürünler ‘onarılabili”, “onarılamaz” ‘arıza yedeği’ vb. kategorilere ayrılır.
|<nowiki>- Üretici firmalardan sağlanan teknik dokümanlar</nowiki>

- Kırılımlı Parça Listesi

- Tasarım dokümanları
|<nowiki>- Analizi yapılacak ekipman ve cihazların ‘yeniden tasnif edilmiş’ listesi</nowiki>
|-
| rowspan="5" |2
|Sökme ve takma işlemlerinin hangi bakım-onarım seviyesinde yapılacağı belirlenir
|<nowiki>- Analizi yapılacak ekipman ve cihazların yeniden tasnif edilmiş listesi</nowiki>
|<nowiki>- SM&R kodunun ilgili hanesi doldurulur.</nowiki>
|-
|Yönetmelikler, lisans hakları, bilgi güvenliği vb. kısıtlamalar incelenir
|<nowiki>- Üretici firmaların açıklamaları</nowiki>

- Üretici firmalardan sağlanan teknik dokümanlar

- Teknik ve idarî yönetmelikler
|Kısıtlamalarla ilgili sorulara verilen “Evet” veya “Hayır” şeklindeki yanıtlar
|-
|Tesis (atölye), bakım destek ve test ekipmanı, iş gücünün sahip olması gereken yetenekler belirlenir.

İş güvenliği, çevrenin korunması vb. etkenler irdelenir.
|<nowiki>- Alan uzmanlarının, sistem mühendislerinin ve diğer Proje paydaşlarının görüş ve değerlendirmeleri</nowiki>
|Gereksinimlerle ilgili sorulara verilen “Evet” veya “Hayır” şeklindeki yanıtlar
|-
|Operasyonel seviyedeki uzun süren bakım faaliyetlerinden bilhassa ‘sök-tak’ işlemleri (varsa) belirlenir.
|<nowiki>- Yapılan ölçümler</nowiki>

- Mühendislik tahminleri

- (Varsa) Ürünle ilgili geçmişte tutulmuş kullanım-bakım kayıtları
|Uzun süren söküm takım faaliyetleriyle ilgili sorulara verilen “Evet” veya “Hayır” şeklindeki yanıtlar
|-
|İhtiyaç makamının/kullanıcının operasyonlara ve bakım faaliyetlerine yönelik stratejileri incelenir
|<nowiki>- Gizli gizlilik dereceli ekipman ve malzemelerin listesi</nowiki>
|İhtiyaç makamının/kullanıcının operasyonel stratejisiyle ilgili sorulara verilen “Evet” veya “Hayır” şeklindeki yanıtlar
|-
| rowspan="4" |3
|Hangi seviyede envanterden çıkarılacağı belirlenir
|<nowiki>- Onarılabilen ve onarılamaz ekipman ve cihazların listesi</nowiki>

- Tasfiye edilecek olanların hangi seviyede envanterden çıkarılacağının bilgisi
|<nowiki>- Devre dışı bırakılacak ürünler için, hangi İhtiyaç makamının/kullanıcının ya da firmanın yetkili olduğu belirlenir.</nowiki>

- SM&R kodunun ilgili hanesi doldurulur.
|-
|Onarılabilenler belirlenir
|<nowiki>- Üretici firmaların tavsiyeleri, çözüm önerileri</nowiki>

- Güvenilirlik, idame edilebilirlik ve kullanıma hazır olma sonuçları
|<nowiki>- Onarılabilen ekipman ve cihazların listesi </nowiki>
|-
|Daha masraflı olduğu için onarımı tercih edilmeyenler belirlenir
|<nowiki>- MTBF değerleri</nowiki>

- Yeni ürünün birim fiyatı

- Yeni ürünün piyasada bulunup bulunmadığı bilgisi
|<nowiki>- Onarılmayıp, operasyonel veya depo seviyesinde envanterden çıkarılacak olan ekipman ve cihazların listesi</nowiki>
|-
|Operasyonel seviyede onarılabilecek olanlar belirlenir
|<nowiki>- Birim fiyatının çok yüksek olduğu bilinen ürünlerin listesi </nowiki>

- Operasyonel seviyedeki onarım imkânları ve maliyeti
|Operasyonel seviyede, ara seviyede ve depo seviyesinde onarılabilecek ekipman ve cihazların listesi
|-
| rowspan="3" |4
|Onarım seviyesi belirlenir
|<nowiki>- D-seviyesi bakım-onarım merkezlerinin imkânlarının değerlendirilmesi</nowiki>
|<nowiki>- D-seviyesi bakımın (onarımın) nerede yapılacağı belirlenir</nowiki>

- SM&R kodunun ilgili hanesi doldurulur.
|-
|Depo seviyesi için kurallar ve kısıtlamalar belirlenir
|<nowiki>- Yönetmelikler</nowiki>

- Lisans hakları, bilgi güvenliği vb. kısıtlamalar
|<nowiki>- Depo seviyesinde, yurt içinde veya yurt dışında onarım yapılacak olan ekipman ve cihazların listesi</nowiki>
|-
|Maliyetlere bakılır
|<nowiki>- Yurt içi merkezlerdeki bakım-onarım maliyeti</nowiki>

- Yurt dışı merkezlerdeki bakım-onarım maliyeti
|<nowiki>- Belirlenmiş olan yurt içi ve yurt dışı bakım-onarım merkezleri</nowiki>
|}
Örneğin, bir sistem için kullanıma hazır olma gereksinimi kritik ise, maliyet hususları ikinci planda kalabilir ve onarımın daha maliyet etkin olduğunun değerlendirilmesine rağmen, arızalı kalemin yenisi ile değiştirilmesi kararı verilebilir. MTTR değeri yüksekse arızalı sistemin onarımı maliyet etkin olsa bile, kullanıma hazır olma gereksinimini sağlayabilmek için arızalı kalemin yenisi ile değiştirme kararı verilebilir. Ya da bir sistemin kullanım konsepti düşünüldüğünde arıza oranı düşükse (örneğin, 10 yıllık raf ömrü olan sistemin yılda 300 saat kullanılmasının öngörüldüğü ve MTBF değerinin 4000 saat olması gibi) ve onarım maliyeti için gerekli kaynaklar düşünüldüğünde malzeme maliyetinin üzerine çıkıyorsa alınan karar yenisi ile değiştirilip arızalı parçanın onarımı değil elden çıkarılması olmalıdır.
{| class="wikitable"
|OSA’nın, projenin erken safhalarında başlanması durumunda test edilebilirlik özellikleri, modülerlik, erişilebilirlik gereksinimlerinin tanımlanması ile tasarıma etki sağlanabilir.
|}
Aşağıda belirtilen soruların cevabı evet ise bu kalemlerin OSA kapsamında analiz edilmesi gerekmektedir;

* Kalemin tasarımı onarıma izin veriyor mu?
* Kalemin onarımı belirli bir bakım seviyesi ile sınırlı mı?

Sarf malzemelerin (somun, cıvata, conta vb.) analize dahil edilmesine gerek yoktur.

Örneğin; ürün ağacında sistemin bir alt seviyesinde bulunan ‘elektronik komple’ arızası olayının meydana gelmesi durumunda BGA kapsamında tanımlanan düzeltici görevin (kalemin onarılabilir olduğu durum için) aşağıdaki gibi olduğu varsayılsın;

Düzeltici Görev 1; Arızalı olan elektronik komplenin yenisi ile değiştirilmesiyle sisteminin onarımı

Düzeltici Görev 2; Doğrudan arızalı elektronik komplenin onarımı ile sistem onarımının yapılması

Bu örnek kapsamında, elektronik komplenin yenisi ile değiştirilmesi durumunda arızalı elektronik komplenin onarılması ya da elden çıkarılması ve bu faaliyetlerin hangi seviyede yapılacağı ile ilgili karar OSA kapsamında verilecektir. Bu karar verilirken de hem onarım maliyeti (işçilik, eğitim vs.) hem de asıl malzeme maliyeti ile elektronik komplenin güvenilirlik değeri göz önünde bulundurulmalıdır.

'''<big>2.1. OSA VERİLERİ</big>'''

OSA kapsamında yapılan değerlendirmelerde kullanılan veriler bakım ilişkili verilerdir. Bunların bir kısmı yedek parça, tesis, destek ekipmanı, personel ve yetenek seviyesi, eğitim ihtiyacı gibi maliyet ilişkili verilerdir. Bir kısmı ise, güvenilirlik bilgisi (MTBF gibi), planlı bakım aralıkları, sistem hazır bulunurluğu, stoktaki yedek parçaların hazır bulunurluğu, bakım için gerekli personelin hazır bulunurluğu gibi doğrudan maliyetle ilişkili olmayan verilerdir.

Toplam maliyet hesaplamaları yapılırken, gerekli kaynakların sadece başlangıçta gereken veya tekrar eden maliyet olarak değerlendirilmesi gerekmektedir. Örneğin, işçilik süresi ya da alt yapı bakımı tekrar eden bir maliyetken, destek ekipmanı tedariki ya da alt yapı kurulumu için sadece başlangıç maliyeti söz konusudur.

'''<big>2.2. BAKIM SEVİYELERİNİN BELİRLENMESİ</big>'''

Bakım çözüm önerisinin oluşturulması kapsamında, hangi bakım görevinin hangi seviyede yapılacağının belirlenmesi ve bunun için de bakım seviyelerinin tanımlanması gerekmektedir. Bakım seviyeleri, her sisteme özel olarak kullanıcı ile anlaşılarak belirlenmelidir. Daha sonra, tanımlanan bakım görevlerinin altyapı, personel, yetkinlik gibi hususlar düşünüldüğünde hangi seviyede yapılacağına karar verilmelidir.

Tablo 19’de bakım seviyeleri ve bu seviyeler kapsamında tanımlanabilecek görevlere ilişkin örnekler verilmiştir. Seviye isimleri, seviyeler için tanımlanacak yetkiler sisteme/projeye özgü kararlar olup tablo sadece örnekleme amaçlı olarak verilmiştir.

'''Tablo 19 Bakım Seviyeleri ve Tanımlı Görevlere İlişkin Örnekler'''
{| class="wikitable"
|'''Seviye Adı'''
|'''Amaç'''
|'''Tanımlı Bakım Görevleri'''
|-
|'''Seviye 1'''
|Sistemin hazır halde olmasının sağlanmasıdır.
|· Kullanıma hazırlama (genel bakım)

· Kullanım öncesi ve sonrası yapılacak muayeneler, fonksiyonel kontroller

· Arıza tespiti

· Önleyici bakım faaliyetleri

· Düzeltici bakım (yenisi ile değiştirme ve ayarlama gerekiyorsa yapılması - kalibrasyon vb.)

· Basit modifikasyonlar
|-
|'''Seviye 2'''
|Sistemin hazırda bulunma seviyesini olası en yüksek seviyede tutmayı sürdürmektir. (Seviye 1 kapsamında yenisi ile değiştirilen arızalı alt sistem, HDB ve modüllerin onarım faaliyetleri yapılabilir. Hem önleyici hem koruyucu bakımları içerebilir.
|· Modül ve alt sistem onarımları

· Orta seviye yapısal onarımlar

· Büyük planlı muayeneler

· Orta seviye modifikasyonlar

· Seviye 1 için teknik destek

· Mühendislik verileri ile ilişkili yazılım hizmeti

· Ürünün korunması
|-
|'''Seviye 3'''
|Sistemin hazırda bulunma seviyesini - mühendislik desteği de sağlayarak - olası en yüksek seviyede tutmayı garanti etmektir. Tüm onarım ve büyük bakımlar yapılacaktır. Tasarımı ya da operasyonel yeteneği iyileştirmek için büyük modifikasyonlar yapılabilir.
|· Özel yetenek veya ekipman gerektiren onarımlar

· Büyük yapısal onarımlar

· Büyük planlı muayeneler

· Kapsamlı modifikasyon ve güncelleme programları

· Seviye 1 ve 2 için teknik destek

· Yazılım modifikasyonları
|}
'''<big>2.3. BAKIM ÇÖZÜM ÖNERİSİNİN OLUŞTURULMASI</big>'''

Hem maliyet hem de teknik kriterlerin birlikte değerlendirilmesi kritiktir. BGA kapsamında belirlenen görevler üzerinden değerlendirme hem teknik hem mali olarak yapılır ve onarım kararı ya da envanterden çıkarma kararı verilir. Her bir görev kapsamında bu kararlar verildikten sonra, bu görevlerin hangi seviyelerde yapılacağı belirlenir. Ayrıca, tanımlanan benzer bakım faaliyetlerinin mümkün olduğunca tek bir bakım yeri için tanımlanmış olması da (onarım yapılacak kalemin bir kısmının bir bakım merkezinde bir kısmının başka bir bakım merkezinde yapılmaması gibi) önemlidir. Yapılan tüm analiz çalışması sonunda sistemin bakım çözüm önerisi oluşturulmuş olacaktır.

Örnek OSA tablosu:
[[Dosya:TSSÖDYP06.ÖRNEK OSA.jpg|alt=|sol|küçükresim|772x772pik]]

{| class="wikitable"
|Not 1: "PAOKD" SM&R kodu açıklaması şöyledir:

▪ Malzeme belli bir süre kullanmak üzere satın alınmış ve depolanmıştır. ( PA - - - )

▪ Malzeme operasyonel bakım seviyesinde sökülüp takılır ve değiştirilir. ( - - O - - )

▪ Tamir edilebilir malzemedir. Tümüyle tamiri anlaşmalı yüklenici tesislerinde yapılır. ( - - - K - )

▪ Malzemenin tamir maliyeti artarsa ve yenisiyle değiştirmenin maliyetini geçerse, hurdaya ayrılır. ( - - - - D)
|Not 2: "PAOZZ" SM&R kodu açıklaması şöyledir:

▪ Malzeme belli bir süre kullanmak üzere satın alınmış ve depolanmıştır. ( PA - - - )

▪ Malzeme operasyonel bakım seviyesinde sökülüp takılır ve değiştirilir. ( - - O - - )

▪ Tamir edilemeyen malzemedir. Yenisiyle değiştirilir. ( - - - Z - )

▪ Malzeme hurdaya ayrılır. ( - - - - Z )
|}

== EK-G BAKIM GÖREV ANALİZİ (BGA) ==
'''<big>1. GENEL</big>'''

Bakım faaliyetleri, sistem konfigürasyonunda bulunan ve görev için kritik olan bütün ekipmanlar için gereksinimlere uygun olarak, görev faaliyetlerini kesintiye uğratmayacak, sorunsuz ve kazasız bir şekilde tamamlanmasına yönelik tedbirlerin alınması ve gerektiğinde müdahale edilmesi esasına dayanır. Bu amaca yönelik her türlü kaynak ihtiyacı (iş gücü, malzeme, tesis vb.) önceden hesaplanmalı ve tahsis edilmelidir.

Sistemde/ekipmanlarda herhangi bir arızanın ortaya çıkması mümkün olduğunca engellenmeli (önleyici bakım), arıza ortaya çıktığında ise çok kısa bir süre içerisinde müdahale ederek (düzeltici bakım) yeniden çalışır duruma getirilmelidir.

Bakım faaliyetleri ekipmanın onarım yapılmasını da kapsar. Ancak, operasyonel seviyedeki onarım işleri, ekipmanın yeniden çalışır hâle getirilmesi maksadıyla yapılacak temel müdahalelerle (arıza tespit, sökme, takma ve son test faaliyetleriyle) sınırlıdır. Depo seviyesinde ise, onarım yapılması gerekli görülen ekipmanlar için ihtiyaç duyulan her türlü imkân bulunmaktadır.

Planlı ve plansız bakım görevleri belirlendikten sonra, bu işlerin yapılabilmesi için gerekli personelin, eğitimlerinin, tesis veya atölye ihtiyaçlarının, test ekipmanlarının ve bakım sırasında ihtiyaç duyulabilecek malzemelerin belirlenmesi gerekir.

Bakım görevleri, işlem adımlarına ayrıştırılarak her bir adımın ne kadar sürede tamamlanacağı hesaplanır. Tüm bu verilerle, maliyet etkinliğinin sağlanmasına ve operasyonların olumsuz şekilde etkilenmeyeceği zaman aralıklarının belirlenmesine çalışılır.

Sistemlerin yazılım konfigürasyonunda bulunan geliştirilmiş yazılım kodlarının tamamı, kullanılan ticarî ve açık kaynak yazılım paketlerinin hepsi, vb kalemler için bakım planlaması garanti kapsamında yüklenici firmadan alınacak destekle sınırlı tutulmalıdır. Ancak, kritik görülen hususlar için ek tedbirlere ve düzenlemelere baş vurulmalıdır.

BGA, geliştirme safhasında yapılması gereken bir analiz faaliyetidir. Diğer taraftan ihtiyaç olması halinde (tasarım değişikliği, modifikasyon vb) ilgili safhalarda güncellenebilecek bir analizdir.

'''<big>2. ANALİZLER</big>'''

'''<big>2.1. BAKIM GÖREVLERİNİN BELİRLENMESİ</big>'''

Bakım görevleri belirlenirken ürün kırılımının yapılmış ve LDA adayı kalemlerin listelenmiş olması gerekmektedir. LDA adayı olarak seçilen her bir kalem için bakım görevleri belirlenmelidir.

Hata durumları, arızalar, özel olaylar vs. bakım görevlerini belirlerken ana etmenler olacaktır (HTEKA, özel olay ve hasar analizi, GMB). Ayrıca yazılım yükleme gibi durumlardan kaynaklı görevler de tanımlanabilir.
[[Dosya:TSSODYP06.20.jpg|alt=|sol|küçükresim|450x450pik|Şekil 20 Bakım Görevlerinin Belirlenmesi]]

Özel olay sonrası gerekli olan muayeneler ve/veya GMB sonrasında; genel, kullanıcı talebine bağlı ve/veya hazırlık için yapılacak faaliyetlerden kaynaklı bakım görevleri ortaya çıkabilir. Bu faaliyetlerin de BGA kapsamında değerlendirilmesi gerekmektedir.

'''<big>2.2. BAKIM GÖREV YAPILARININ OLUŞTURULMASI</big>'''

Görev yapıları oluşturulurken görevler analiz faaliyetinde kolaylık sağlaması açısından iki sınıfa ayrılır.

'''Düzeltici görevler (rectifying tasks);''' Her düzeltici bakım görevi arıza, hata veya özel olay gibi bir durumdan dolayı gerçekleştirilir. Doğrudan ilgili olayı çözmek amaçlı (event solver) yapılan herhangi bir bakım faaliyeti düzeltici görev olarak adlandırılabilir. Hem alt görevleri hem de referans destek görevlerini kapsar.

Örneğin;
{| class="wikitable"
|'''Olay'''
|'''Düzeltici görev'''
|-
|Hata/Arıza
|Onarım veya yenisi ile değiştirme prosedürü
|-
|Özel Olay
|Muayene/arıza yeri
|-
|Sistem ömrünün eşik değerine yaklaşması
|Planlı bakım
|}
'''Destek görevleri (supporting tasks);''' Düzeltici görevlerin aksine destek görevleri, meydana gelen durum karşısında (arıza, hata vb.) bu durumun çözülmesi amacıyla yapılmaz. Bağımsız bir görev olarak hata ya da arıza durumunu çözmez ve/veya özel bir olaydan sonra gerçekleştirilmez. Düzeltici görevlerin uygulanmasını sağlayan destekleyici görevlerdir. Test prosedürleri, erişim sağlama/kaldırmak, kurulum kaldırma/yükleme/montaj/demontaj prosedürleri örnek olarak verilebilir.

Tablo 20’de, ürün ağacında yer alan bir ‘elektronik komple’ arızası olayının meydana gelmesi durumunda, düzeltici görev, takip eden görevler ve uyarıların neler olduğu örneklenmiştir. Elektronik komple arızası karşısında, kalemin onarılabilir ve onarılamaz olması şeklinde iki farklı durum varsayılmıştır.

Elektronik komple arızası için varsayılan iki farklı durum;

1. durum; elektronik komplenin onarılamaz bir kalem olarak tanımlanmış olması

2. durum; elektronik komplenin onarılabilir bir kalem olarak tanımlanmış olması

'''Tablo 20 Görev Gereksinimleri Örneği'''
{| class="wikitable"
|'''Olay (Event)'''
|'''Düzeltici Görev'''
|'''Takip Eden Olası Görevler *'''
|'''Uyarı'''
|-
|Elektronik komple arızası (elektronik komplenin onarılamadığı durum)

|Arızalı olan elektronik komplenin yenisi ile değiştirilmesi
|Arızalı elektronik komplenin elden çıkarılması
|· Onarılamaz elektronik komplenin yedek parça olarak tanımlanmış olması gerekmektedir.

· Arızalı elektronik komplenin elden çıkartılması prosedürlerinin ilgili dokümanda belirtilmiş olması gerekmektedir.
|-
| rowspan="2" |Elektronik komple arızası (elektronik komplenin onarılabildiği durum)
|Arızalı olan elektronik komplenin yenisi ile değiştirilmesiyle sistemin onarımı
|Arızalı olan elektronik komplenin onarımı
|Elektronik komplenin yedek parça olarak tanımlanmış olması gerekmektedir. Bu sayede son ürün olan sistem, arızalı alt sistemin onarımı tamamlanana kadar beklememiş olacaktır.
|-
|Doğrudan arızalı elektronik komplenin onarımı ile sistem onarımının yapılması
|Yok.
|Komponentin yedek parça olarak tanımlanması gerekli değildir (onarılıp tekrar takıldığı için). Bu durumda son ürün olan sistem, arızalı alt sistemin onarımı tamamlanana kadar beklemiş olacaktır.
|-
| colspan="4" |* Bakım/onarım seviyeleri belirlendikten sonra, bu seviyelere göre takip eden işlemler değişebilecektir (arızalı sistemin bakım için belirlenen üst seviyeye gönderilmesi gibi).
|}
Görev yapıları oluşturulurken, düzeltici görevlerden önce destek görevlerinin tanımlanması gerekmektedir. Destek görevleri de iş adımlarına bölünebilir. Destek görevleri tanımlanmadan önce, iş adımları öncesi yapılması gereken işlemler de tanımlanmalıdır. Adımlar öncesi yapılacak faaliyetler, sistem ile doğrudan ilişkili olmayan, erişim için yapılan faaliyetlerdir. Görev yapılarının oluşturulmasına ilişkin adımlar Şekil 21’de gösterilmiştir.
[[Dosya:Şekil21Görev Yapılarının Oluşturulması.jpg|alt=|sol|küçükresim|437x437pik|Şekil 21 Görev Yapılarının Oluşturulması]]

Örneğin, bir ‘elektronik komple’ arızası, elektronik komplenin yenisi ile değiştirilmesi;

Elektronik Komple için sökme prosedürü (adımlar, görevler);

Adım 1 öncesi yapılacak işlem; kapağı kaldırmak için vidaların açılması

Görev 1; kapağın kaldırılması

Adım 2; elektronik komplenin gövdeden ayrılması

Görev 2; elektronik komplenin demonte edilmesi

Görevler tanımlanırken, ön koşulların ve/veya ön koşulların sağlanabilmesi için gereken faaliyetlerin de tanımlanması gerekir. Örneğin, görevin emniyetli bir ortamda gerçekleştirilmesi için gerekli olan tüm ön koşulları (uyarı ve dikkat edilecek hususların) kapsayacak şekilde emniyet ön koşullarının ve/veya emniyet yönetmelikleri de dahil gerekli personel yetenekleri, sertifikasyonları vs. durumlarını kapsayan personel ön koşullarının tanımlanması.

Bazı tasarımsal sebeplerden kaynaklı sistem hataları öngörülemeyebilir. Hasar ya da özel olayların meydana gelmesi ile ilgili benzer sistemler ve/veya benzer projeler kapsamında edinilmiş herhangi bir tecrübe varsa, bu tecrübe öngörülemeyen olayların ne kadar sıklıkla meydana gelebileceği ve ilgili bakım faaliyetlerinin sıklığı konusunda fikir verebilir. Bu nedenle, bakım faaliyetleri ile ilgili planlama yapılırken uygulanabilir olduğu ölçüde öngörülemeyen bu tarz olayların da dikkate alınması önemlidir.

'''<big>2.3. GÖREV KAYNAKLARININ BELİRLENMESİ</big>'''

Bir görevin yerine getirilmesi için gerekli olan kaynakların (özel bir ekipman kullanımı için personel eğitimi de dahil) görevin içinde tanımlanması gerekmektedir. Görevin yerine getirilmesi kapsamında gerekli olan yedek parçalar, destek ekipmanı, personel, alt yapı gibi kaynakların belirlenmesi ve ilgili görevlere atanması gerekmektedir. Görev kaynaklarına ilişkin örnekler ve açıklamaları Tablo 21’de verilmiştir.

'''Tablo 21 Görev Kaynaklarına Örnekler'''
{| class="wikitable"
|'''Kaynak'''
|'''Açıklama'''
|-
|Yedek parçalar
|Yedek parçalar fiilen gerekli oldukları alt görevlere atanırlar.
|-
|Sarf malzemeler
|Sarf malzemeler fiilen gerekli oldukları alt görevlere atanırlar.
|-
|Destek ekipmanı **
|Destek ekipmanı fiilen gerekli olduğu alt göreve atanabilir ya da tüm görev boyunca gerekliyse de tek bir alt görev yerine ana göreve atanabilir.

İlgili ekipmanı hangi personelin kullanacağı ve eğitimin gerekli olup olmadığı bilgisinin de eklenmesi gerekir
|-
|Personel
|Personel (hem görev kapsamında ihtiyaç duyulacak personel sayısı hem de personel gereklilikleri) fiilen gerekli olduğu alt görevlere atanırlar.
|-
|Tesis
|Tesisler fiilen gerekli olduğu alt görevlere atanırlar.
|-
|Teknik dokümantasyon
|Teknik dokümanlar fiilen ilişkili olduğu alt görevlere atanırlar.
|-
| colspan="2" |** Bakım görevlerine destek ekipmanı atanırken ilgili ekipmanın mevcut ve doğrulanmış bir ekipman olması, yeni geliştirilen bir ekipman ise tüm gereksinimlerinin tanımlanmış ve dokümante edilerek yayımlanmış olması gerekmektedir.
|}
Her bir görev kapsamında görev kaynakları belirlendikten sonra, sistem seviyesinde tüm görevler düzeyinde, alt görevler ve destek görevlerinden gelen tüm kaynakların özetlenmesi gerekmektedir. Tablo 22’de montaj prosedürü için gerekli görev kaynaklarına ilişkin örnek verilmiştir.

'''Tablo 22 Montaj Prosedürü için Gerekli Görev Kaynakları Örneği'''
{| class="wikitable"
| colspan="8" |'''Elektronik Komple için Montaj Prosedürü-Görev Kaynakları'''
|-
|'''Adım/Adım Öncesi Yapılacak İşlemler/Alt Görev'''
|'''Yedek'''
|'''Sarf Malz.'''
|'''Destek Ekipmanı'''
|'''Personel'''
|'''Özel Tesis'''
|'''Geçen Toplam Süre'''
|'''İşçilik Süresi'''
|-
|Alt görev; Elektronik Komplenin gövde içine yerleştirilmesi
|Elektronik Komple
|Yok
|Yok.
|1 personel
|ESD korumalı alan.
|10 dk
|10 dk
|-
|Adım 1; Kapağın kapatılması
|Conta (x1)
|Yapıştırıcı
|Yok
|2 personel
|ESD korumalı alan.
|5 dk (işçilik)

60 dk (yapıştırıcının kuruması için)
|5 dk + 5 dk
|-
|Adım 2; vidaların takılması
|Rondela

(x6)
|Yok.
|Yok.
|1 personel
|ESD korumalı alan.
|3 dk
|3 dk
|}
'''Tablo 23 Elektronik Komple İçin Montaj Prosedürü-Görev Kaynakları Özeti'''
{| class="wikitable"
|'''Kaynak tipi'''
|'''Kaynak'''
|'''Miktar'''
|-
| rowspan="3" |Yedek Parça
|Elektronik Komple
|1
|-
|Rondela
|6
|-
|Conta
|1
|-
|Sarf Malzeme
|Yapıştırıcı
|
|-
|Personel
|Personel
|2
|-
|Özel Tesis
|ESD korumalı alan
|<nowiki>-</nowiki>
|-
|İşçilik Süresi
|Personel
|18 dk
|-
|Montaj için gereken toplam süre
|<nowiki>-</nowiki>
|78 dk
|}
Geçen Toplam Süre (MET; Mean Elapsed Time); İlgili bakım görevinin yerine getirilmesi için gereken toplam süredir. Alt görevlerden ve referans verilen destek görevlerinden gelen sürelerin toplamı ile hesaplanır.

İşçilik Süresi (Labor time); yapılacak personel işinin toplam süresidir. Aynı alt görev için birden fazla personel çalışıyorsa her yetenek seviyesi için işçilik süresi toplanmalıdır. Örneğin aynı seviye kapsamında üç personel 20 dk süren bir görev için aynı zamanda çalışıyorsa, bu görev için gerekli toplam işçilik süresi 3x20=60 dk’dır.

BGA kapsamında görev süreleri, yedek parça, ekipman gibi gerekli olan tüm görev kaynaklarının hazır olduğu varsayımı ile hesaplanmalıdır (‘spanner in hand’ olan zamanlar). Bakım/onarım faaliyeti hazırlıkları ile ilgili olan dokümantasyon, destek ekipmanı veya malzemenin getirilmesi gibi üretken olmayan faaliyetler ve benzer şekilde lojistik gecikme süreleri (logistic delay time) bu sürelere dahil edilmemelidir.

Diğer taraftan, tüm faaliyetler görev sürelerine dahil edilmelidir. Örneğin, malzeme sertleşmesi ya da boya kuruması gibi üretken olmayan faaliyetlerin bir sonraki adım için tamamlanmış olmaları gerektiğinden mutlaka görev süresine dahil edilmelidir.

Bakım faaliyetleri ile ilgili olan ve bakım görevlerinden türetilen eğitim gereksinimlerinin her bir görev kapsamında tanımlanmış olması, faaliyeti yerine getirecek personel için yetenek seviyesi, karmaşık görevler için ekip eğitimi ihtiyacı olup olmadığı, eğitim gerektiren destek ekipmanının olup olmadığı, özel eğitim, tecrübe vs. ihtiyacının olup olmadığı gibi hususların göz önünde bulundurulması gerekmektedir.

Bir kalem yedek parça olmayabilir ancak başka bir kalemin onarımı kapsamında yerinden çıkarılması gerekebilir. Yerinden çıkarılma sonrası hasar görme ihtimali varsa ve/veya tekrar kullanılamaz bir kalemse bunun da yedek parça olarak tanımlanması gerekmektedir.
{| class="wikitable"
| colspan="2" |'''Bakım uygulaması sürecinin sistem hazır bulunurluğu ile ilişkisi;'''

Bakım faaliyetleri boyunca sistem hazır bulunurluğu sistem için en önemli bilgilerden birisidir. Farklı kırılım seviyeleri için hazır bulunurluk farklılık gösterebileceği gibi yapılan analiz sonuçları, maliyet değerlendirmeleri de hazır bulunurluk kapsamında göz önünde bulundurulması gereken faktörlerdir.

Bakım uygulaması süresince sistem hazır bulunurluğunu etkileyecek 3 farklı durum olabilir:

* Bakım süresi boyunca sistem kullanılabilir olmayabilir, bu durumda sistemin tekrar kullanılabilir hale gelmesi için bakım ve onarım faaliyetlerinin tamamlanmış olması gerekir.
* Bakım süresi boyunca sistemin tam kapasite ile kullanılmaya devam edilebilmesidir. Bu durumda, arızalı olan kısım daha sonra onarılmak üzere yenisi ile değiştirilir ve onarılan kısım da tekrar kullanılmak üzere stoklanır.
* Bakım süresince sistemin eksik kapasite ile kullanılması olabilir. Bakım ve onarım faaliyetleri tamamlandıktan sonra tam kapasite ile kullanılabilecektir.
|-
|Bakım faaliyetlerinin yerine getirilmesi, çevre koşullarına, kullanıcı değişikliklerine ve buna bağlı olarak kullanım/bakım alanlarının personel, ekipman ile ilgili ön koşullarındaki değişikliklere, barış ve savaş zamanı senaryolara bağlı olarak farklılık gösterecektir. Bu durumda görevin kendisi aynı kalabilir ancak ihtiyaç duyulacak destek ekipmanları, görev süresi vb değişebilir.
|
|}

Örnek BGA Formu:
[[Dosya:Bga.jpg|sol|küçükresim|800x800pik]]

== EK-H YAZILIM DESTEK ANALİZİ (YDA) ==
'''<big>1. GENEL</big>'''

Sistemin desteklenebilirliğini sağlayabilmek için LDA süreci kapsamında yazılımlar için de YDA süreci yürütülür. YDA, maliyet etkin bir yazılım destek konseptinin kurulması için donanıma benzer şekilde yazılım açısından da sistemi desteklemeyi amaçlar. Yazılım Destek Konsepti (YDK) belirlenirken, bir ürün içerisindeki yazılımın kullanımının devamlılığını sağlamak için gerekli tüm aktivitelerin dikkate alınması gerekir. YDA’da, yeterli bir YDK geliştirmek için ekipman, araç, personel, dokümantasyon, altyapı, gerekli yetkinlik ve eğitim gibi hususlar analiz edilir.

Donanım gibi, yazılım da operasyon ve bakım gereksinimlerine göre analiz edilmelidir. Veriler de, aynı yazılımlar gibi hem fiziksel hem işlevsel bir bakış açısıyla ele alınabilirler.

Yazılımın kullanım şartları ile bakım şartları birbirinden net şekilde ayrılmalı ve yazılım modifikasyonu tanımı net bir şekilde koyulmalıdır. Örneğin, operasyonel husular, yazılımın ürüne yüklenmesini içerebilirken; yazılım modifikasyonu bir problemi çözmek için ya da yazılımın performansını iyileştirmek veya prosedürler, veriler ve yazılımın performansını etkileyecek sistemlere adaptasyon için kaynak kodunun değiştirilmesi olabilir.

Yazılım bakım ve idamesinin amacı, teslim edilen yazılıma ‘maliyet etkin’ şekilde destek verebilmektir.

Yazılım bakım ve idamesi dört şekilde ele alınabilir:

* Teslim edilen yazılım ürünlerindeki hataların giderilmesi (düzeltici bakım);
* Yazılımın performansının ve özelliklerinin iyileştirilmesi (mükemmelleştirici bakım);
* Yazılımın değişen çevre koşullarına, donanıma, işletim sistemine ve muhtelif arayüzlere adaptasyonu (uyarlayıcı bakım);
* Yazılımın daha az karmaşık, daha anlaşılabilir, bakımının daha kolay yapılabildiği şekle çevrilmesi (önleyici bakım).

Yazılım bakım ve idame süreci kapsamında en az aşağıdaki faaliyetlerin gerçekleştirilmesi tavsiye edilir:

* Bakım planı ve bakım süreçlerinin oluşturulması;
* Problem Raporu ve Değişiklik İsteği süreçlerinin oluşturulması (taleplerin alınması, kaydedilmesi, güncellenmesi, izlenmesi, testlerle doğrulanması ve geri beslemenin yapılması);
* Konfigürasyon yönetiminin uygulanması.

Yazılım değişikliklerinin sisteme entegre edilmesi aşamasından önce bazı analizler yapılır. Yapılacak bakımın:

* Niteliği (düzeltici, uyarlayıcı vb.);
* Kapsamı (yazılımdaki değişikliğin büyüklüğü, işlemlerin maliyeti, bakım süresi);
* Kritikliği (performans, emniyet, bilgi güvenliği hususları) değerlendirilir.
'''<big>2. FARKLI PROJE SAFHALARINDA YDA</big>'''

YDA’nın yazılım içeren bir ürün için tüm ömür devri boyunca uygulanması gerekmektedir. Yapılacak faaliyetler, proje safhaları dikkate alınarak gerçekleştirilmelidir. Örneğin, geliştirme safhasında, YDA’nın uygulaması önemlidir çünkü yazılımın gelecekteki yükleme, servis ve modifikasyonları için desteklenebilirlik gereksinimleri açısından yazılım mimarisi ve tasarımı etkilenebilir.

'''Tablo 24 Farklı Proje Safhalarında Yazılım Destek Analizi'''
{| class="wikitable"
|'''Geliştirme'''
|'''Üretim'''
|'''Kullanım ve Destek'''
|'''Envanterden Çıkarma'''
|-
| colspan="2" |· LDAP’da YDA kapsamının belirlemesi

· Karşılaştırmalı analiz

· YDK’nın belirlenmesi

'''Detaylı yazılım analiz görevleri:'''

· Konfigürasyon değerlendirmesi

· YDA

· Yazılım için OSA

· Yazılım ilişkili görevler için BGA
|· Periyodik değerlendirme

· Kullanım safhasındaki teknik modifikasyonların yönetimi

· Konfigürasyon yönetimi
|· Verilerin silinmesi

· Verilerin yer değiştirmesi

· Verilerin arşivlenmesi
|}
Erken fazlarda, YDA temel yazılım destek gereksinimlerinin belirlenmesine yardımcı olur. Envanterden çıkarma safhasında, donanımlar için olduğu gibi yazılımlar için de envanterden çıkarma prosedürlerinin tanımlanması gerekmektedir. Eğer yazılım verisi yeni geliştirilecek sistemler veya ilerleyen operasyonlarda kullanılacaksa, verilerin yer değiştirilmesi hususu kapsamında uygulanması gereken prosedürlerin de göz önünde bulundurulması ve tanımlanması gerekmektedir.

'''<big>3. YAZILIM KIRILIM KONSEPTİ</big>'''

Yazılımlar için de donanımlara benzer olarak fiziksel veya işlevsel konsept değerlendirilerek bir kırılım gerçekleştirilebilir. Yazılımın yüklendiği üst donanımlarından birisinin elemanı olması, yazılımın kendisini çalıştıran donanımın bir elemanı olması veya yazılımın fiziksel olarak üzerinde bulunduğu donanımın bir elemanı olması örnek olarak verilebilir.

Fiziksel bir kırılım içerisinde yer alan yazılım kalemleri genellikle, işlevselliğinin doğrudan kullanıcı tarafından gözlemlenebildiği elemanlardır. Yazılım ürün kırılımında farklı hiyerarşik seviyelerde yer alabilir. Fiziksel kırılım içerisinde yazılımı spesifik bir seviyeye atamak, üründeki konfigürasyon kontrolü ihtiyacı ve yazılımın operasyon ve bakım üzerindeki lojistik etkilerini belirtmek içindir. Fiziksel kırılım, bir ürünün kırılımındaki yazılımı belirlemek için operasyonel amaçlar kapsamında kullanılabilir ve donanımın yanında yazılımın da bakıma yönelik işlemlerinin değerlendirilmesini mümkün kılar.

LDA ürün kırılımında bir yazılım kalemini yönetmenin en kolay yolu yazılımı kategorilerine göre HDB, ADB veya parça/komponent olarak tanımlamaktır. Fiziksel yazılım kategorileri 3 başlık altında incelenebilir;

* Alanda Yüklenebilir Yazılım (Field-Loadable Software); bir sistem/ürün üzerindeki ekipmanın bir veya birkaç parçasına ekipmanı demonte etmeden yüklenebilen yazılımdır.
* Atölyede Yüklenebilir Yazılım (Shop-Loadable Software); bir HDB üzerinde yüklenebilecek bir yazılımdır ancak HDB’nin üründen demontajını gerektirir.
* Yerleşik Yazılım/Bellenim; HDB veya ADB’ye yüklenebilecek ancak operasyonel ürün üzerindeki yükleniminin demontajı ve bir komponentin yeniden konumlandırılmasını gerektirebilecek yazılımdır.

İşlevsel kırılım, yazılımın nasıl modifiye ve entegre edileceği ile yeniden tasarım olduğunda farklı yazılım elemanlarının arasındaki dikkate alınması gereken ilişkiyi gösterir. İşlevsel kırılımda yer alan yazılım kalemleri yazılımın diğer yazılımlarla entegrasyon ihtiyacından ötürü işlevsel/tasarım açılarını tanımlarlar. Böyle bir kırılım, yazılım modifikasyon desteği için kritiktir. Bu yüzden de işlevsel kırılımın yazılım tasarımını olabildiğinde takip etmesi önemlidir.

Yazılım modifikasyonuna yönelik olarak işlevsel yazılım kırılımı yazılım tasarım gereksinimlerini takip eder. Klasik yazılım konfigürasyon kalem seviyesi yaklaşımına ek olarak daha üst seviyede (altsistem ve sistem seviyesi) yazılımın sisteme entegrasyonunun da değerlendirilmesi gerekmektedir.

'''<big>4. YAZILIM DESTEK ANALİZİ</big>'''

Ürün kullanım safhasına girmeden gerekli destek altyapısının sağlandığından emin olmak önemlidir. YDA’nın amacı, yazılım desteklenebilirlik gereksinimlerini erken safhalarda belirlemek ve sistem operasyonu ve sonraki değişikliklerin desteklenebilirliği için yazılım tasarımını etkilemektir.

'''<big>4.1. YDA ADAY KALEM SEÇİMİ</big>'''

Donanım aday kalem seçimiyle benzer yaklaşım izlenecektir.

'''<big>4.2. YAZILIM BAKIMI</big>'''

Bakım faaliyeti gerektirecek tüm olaylar, yazılım desteğinin başlangıcı olarak değerlendirilebilir. Bu olaylar, operasyonel, teknik, yazılım geliştirme gereksinimleri ve yazılım hataları olarak gruplanabilir.

* Operasyonel olaylar; operasyonel bir gereksinim ile ilgili, donanım üzerinden dokümante edilebilen donanım bakımını, kullanıma hazırlığı ve görev sonrası gereksinimleri kapsayan olaylardır.
* Teknik olaylar; yazılım paketinin, değişen koşullara olan adaptasyonunu gerektirir. Yazılımın üzerinde olduğu donanımın değişmesi, birbiriyle çalışan sistemlerin teknolojisinde değişme örnek olarak verilebilir.
* Yazılım geliştirme gereksinimleri; yazılım değişiklikleri yazılım paketinin karmaşıklığı ve boyutuna göre değişen aralıklarda yapılır. Yazılım hatalarının düzeltilmesinin yanında, yeni yazılım yayımlanması için son kullanıcı gereksinimleri ve koşullardaki değişikliklere girdi sağlar. Yazılım geliştirme demek, geliştirilecek yeni özellikler veya genişletilecek fonksiyonellik veya mevcut yazılımın kullanım konforu demektir.
* Yazılım hataları; desteği başlatan ana sebep yazılım hatalarıdır. Bu hatalara verilecek destek ile ilişkili reaksiyonlar hatanın ciddiyetine bağlıdır. Her yazılım hatası yazılım modifikasyonu gerektirmeyecektir. Modifikasyonun gerekli olmadığı durumlarda bile, bir sonraki hatanın tespiti için dokümantasyonun doğru hazırlanmış olması gerekmektedir.
** Minör hata: Genellikle, kullanıcının sistemi kullanım konforu ve ergonomisi ile ilişkili olup sistemin operasyonel kullanımı ile ilgili kritiklik yaratmayan ancak gene de hata olarak ele alınması gereken durumlardır.
** Orta seviye hata: Sistemin işlevselliğini azaltan hatalardır. Sistemin kullanımı azalan bir performans veya hiçbir kısıtlama dahi olmadan devam edebilir.
** Major hata: Tüm sistemin tamamen kapatılmasına veya çok kısıtlı koşullar altında çalışmasına neden olan kabul edilemez hatalardır. Sistem performansı ciddi oranda azalır.

Yazılım hataları donanım hataları gibi belirli onarım değişim prosedürleriyle ele alınamaz. Bu yüzden bir yazılım hatasında alınması gerekli olan aksiyon hemen bilinemeyeceğinden alınamayabilir. Örneğin bir yazılım hatasında sistemi kapatıp açmak hatayı düzeltebilirken, diğer bir hatada sistemi kapattıktan sonra sistemin daha fazla zarar görmemesi için tekrar açılmaması gerekebilecektir. Ya da bir donanımdaki bozulma sebebiyle de yazılım çalışmayabilir. Bu durumda yazılım kaynak kodunda gerçek bir doğal hata bulunmamakta olup bu durum dış hasar olarak ele alınır.

'''<big>4.3. YDA KAPSAMINDA HTEKA/HTEA</big>'''

HTEKA/HTEA tüm sistemde gerçekleştirilen bir analiz methodu olduğu için yazılım kalemleri ile de doğrudan ilişkilidir. Tanımlanmış olan her bir hata modu için işlevsellik bir yazılıma mı dayalı ya da komple bir yazılım tarafından mı sağlanıyor kararı verilmelidir. Yazılımın geliştirme safhasında, yazılım mimarisinde ilgili hata modu bilgilerinin sistemde spesifik bir hataya sebep olmasını engelleyecek ya da en azından azaltacak şekilde dikkate alınması gerekmektedir. Ayrıca, tasarım, yazılım hatalarının tespit edilebildiği, kayıt altına alınabildiği ve sistemin güvenli modda çalışmaya devam edeceği şekilde olmalıdır.

Sistemin kullanım safhasında, yazılım hatalarından kaynaklı sistem hataları, yazılım değişikliğine sebep olmaktadır. LDA HTEA’sının temel prensibi, spesifik bir sistem arızasına sebep olabilecek tüm yazılım hatalarını ve aynı yazılım değişikliğine sebep olacak tüm sistem hatalarını gruplamaktır. Analiz, yazılımın gerçekleştirdiği fonksiyon üzerinden gidecektir fakat genellikle bir kaynak kodundaki spesifik bir hataya kadar değerlendirecek şekilde HTEKA/HTEA yapmak pratik değildir.

Kullanım safhasındaki diğer bir konu ise yazılım mühendislerine spesifik bir hata hakkında bilgi vermek ve yazılım hatalarından kaynaklı gereksiz bakım görevlerini önlemektir. BIT ile tespit edilebilen veya kullanıcı tarafından tanımlanabilen bir yazılım hatası demontaj sayısını ve donanımla ilişkili olmayacak hataları azaltacaktır (ekipmanın değiştirilmesi ile yazılım hatasının ortadan kaldırılamaması gibi).

'''<big>4.4. YAZILIM İÇİN PLANLI BAKIM ANALİZİ (PBA)</big>'''

GMB gibi PBA’lar donanımlar gibi yazılımlara uygulanabilir değildir. Yazılım hataları, yazılım tasarımının istenmeyen etkilerinin sonucu olduğundan PBA kapsamında tanımlanmış bir bakım görevi ile düzeltilemezler. PBA sonuçları yazılım içeren bir donanımda, planlı bakım görevlerini belirleyecek şekilde kullanılabilir ancak bu analiz yine de donanım için olacaktır.

Yazılımlar da küvet eğrisi davranışını izleyerek ilk kullanımda çokça hata yaparlar. Geliştirme safhası boyunca kararlı bir davranışa kadar kod hataları düzeltilerek tekrarlayan bir şekilde yazılım yayımlamaları yapılır. İlerleyen kullanımlarda hata oranları her ne kadar düşse de yazılımda ilk kapsamından farklı olarak modifikasyonlar olacağından hata oranları yine artacaktır.

'''<big>4.5. YAZILIM İÇİN OSA</big>'''

Yazılım için OSA donanımlarda olduğu gibi ya da oldukça benzer olacak şekilde ele alınmalıdır. OSA sonucunda ortaya çıkan görevler yeni yazılım yayını veya operasyonel bir yazılım ihtiyacının doğması veya veri yükleme gibi dışsal nedenlerden kaynaklanabilir. Eğer bu görevler çok sık gerçekleşirse OSA sonuçları donanımlara karşılık gelen görevlerden farklı olabilir.

Yazılım değişikliği için ekipman hakkında detaylı bilgi (donanımla ilintili yazılım geliştirme ortamı ve yazılım geliştirme araçları) ve personel yetkinliği gereklidir. Ayrıca, sözleşmeye bağlı durumlar, yazılım modifikasyon faaliyetlerinin hangi destek seviyesinde gerçekleştirileceğini etkileyebilir.

'''<big>4.6. YAZILIM İÇİN BGA</big>'''

İlgili yazılım destek başlatıcılarının (olaylar) belirlenmesinden sonra operasyonel/bakım veya modifikasyon görevleri belirlenmelidir. Amaç bunları tanımlamak ve bunlara gerekli kaynakları ve görev karakteristiklerini belirlemektir (süre, insan ihtiyacı, ön koşullar, güvenlik koşulları vb.).

SAE JA1005 referans alınarak farklı olaylar sonucunda hangi yazılım destek görevlerinin gerçekleştirileceğine ulaşılabilir.

'''<big>5. YAZILIM DESTEK KONSEPTİ ÇERÇEVESİ</big>'''

Yazılım destek konsepti yazılım tasarım sürecinin erken safhalarında başlamalıdır. Eğer değişiklik gereksinimleri farklı kaynaklardansa, yazılım değişikliği daha kolay olacaktır. Ayrıca, yükleme ve konfigürasyon prosedürleri de olabildiğince kolay olmalıdır.

Yazılım desteğinin 3 farklı perspektifi vardır;

* İlki; destek profili, seviyeler, aktörler ve aktivitelerden oluşur.
* İkincisi; destek fonksiyonları olan operasyon, yönetim ve modifikasyonlardır.
* Sonuncusu ise destek sınıfları olan süreçler, ürün ve çevredir.

Yazılım desteğinin LDA kapsamında olup olmayacağı proje kapsamında yapılması planlanan faaliyetler ile birlikte değerlendirilmeli ve yapılması gerektiği değerlendirilirse LDAP’a eklenmelidir. Büyük miktarda yazılım içeren büyük ve karmaşık sistemlerde yazılım desteklenebilirliği ayrı bir alan olarak değerlendirilmelidir. Yazılımlar donanımlara fonksiyonellik katmak için tasarlandıklarından donanım ile arasındaki arayüzler kurulana kadar süreçler birlikte işletilmeli, gözden geçirilmeli, pratiğe dökülmeli ve dokümante edilmelidir.

'''<big>5.1. YAZILIM DESTEK PROFİLİ</big>'''

Yazılım destek profili kapsamında, yazılım desteğinin gerçekleştirileceği yer, organizasyon ve ilişkili personelin dikkate alınması gerekmektedir. Yazılım destek seviyeleri aşağıdaki gibi tanımlanabilir;

* Operasyonel seviye (seviye 1); bu destek seviyesi, yazılımın operasyonel kullanımındaki yerini tanımlar. Bu seviyede, operasyonel servis desteği adı altında basit destek görevleri gerçekleştirilir.
* Orta seviye destek (seviye 2); hem operasyonel servis desteğiyle hem de yönetim desteği ile ilgili tüm destek faaliyetlerini içerir.
* Üst seviye destek (seviye 3); yönetim desteğine ek olarak modifikasyon desteği de burada sağlanır. Yapılacak faaliyetler, karışıklık, boyut, modülerlik, programlama teknikleri vs. gibi yazılım paketinin kendisine ve yazılım modifikasyonunu gerçekleştirecek ekipmana (araçlar, personel, tesisler) dayanır.

* Yazılım sağlayıcı ve/veya geliştirici (seviye 4); yazılım sağlayıcı normalde yazılım modifikasyonuyla ilişkili gerekli geliştirme araçları ve personel ile donatılmış en üst yetenekteki destek seviyesidir. Kullanıcılar çoğunlukla bu yetkinliğe sahip olmadıklarından yazılım modifikasyonları için genelde bu seviyede destek sağlanır.

Yazılım destek rollerinin belirlenmesinin ilk aşaması kullanıcı ve yüklenici firma rollerinin tanımlanmasıdır. İkinci aşaması ise, yazılım kullanım ve desteğiyle ilişkili personellerin rollerinin (yetkinlik, erişim, eğitim vb.) tanımlanmasıdır. Aşağıda destek rolleri ve bu kapsamda tanımlanan aktiviteler ve yetkilere ilişkin örnekler verilmiştir;

* Basit düzeyde kullanıcı; yazılım sistemlerinin düzeltilmesi veya modifikasyonuyla ilgili bir yetkisi yoktur. Ana görevleri yazılım içeren sistemi operasyonel olarak çalışır durumda tutmak ve sistem/yazılım hatalarını raporlamaktır.
* Orta düzeyde kullanıcı; yazılım sistemlerinin düzeltilmesi ile ilgili yetenek ve bilgiye sahiptir. Yazılımı çalışır durumda tutmak için operasyonel destek aktivitelerini gerçekleştirirken, yazılım ve veri yükleme vb. yazılım güncelleme aktivitelerine ise destek vermezler.
* Sistem yöneticileri; üst düzey kullanıcılarıdır. Operasyonel destekle ilgili tüm aktivitelerden ve yönetim desteğinden sorumludurlar. Yazılım modifikasyonu gerçekleştirmeseler de, tipik yönetim görevleri olan performans parametrelerinin değiştirilmesi gibi yazılım konfigürasyon işlerinden, ek yazılım paketi yüklemeleri vb. işlerden sorumludurlar.

* Servis sağlayıcı; kalifiye operasyonel desteğinden ve yardım hattı gibi ek servislerden sorumludurlar. Müşteri veya yüklenici tarafında ikamet ederler ve modifikasyon desteği de sağlarlar.
* Yüklenici/Yazılım geliştirici; en üst seviyeden yazılım modifikasyon desteği sağlarlar.

Farklı destek görevleri ve seviyeleri için farklı bölgelerde farklı kaynaklarla nasıl yapılacağını gösteren kullanım durumlarının tanımlanması gerekmektedir.

'''<big>5.2. DESTEK FONKSİYONLARI</big>'''

Yazılımla ilişkili bakım görevleri aşağıda belirtilen hususlara göre farklı kategorilere ayrılabilir;

* Görev basit bir yükleme/kaldırma görevi mi yoksa yazılımın A cihazından B cihazına taşınma işlemi mi?
* Yazılım yüklemesi ya da kaldırılması için bir donanımı çıkarmak gerekli mi?
* Yazılım modifikasyonu gerekli mi? Yazılım modifikasyonunun özel destek görevleri gerektiren geniş bir alan olması sebebiyle modifikasyonun kapsamı tam olarak belirlenebiliyor mu?
'''<big>5.2.1. OPERASYONEL SERVİS DESTEĞİ</big>'''

Operasyonel servis görevleri sistemin günlük operasyonel görevleriyle ilişkili tüm aktiviteleri tanımlar. Fakat bu görevler sistem kullanımı üzerinde farklı kalite ve derinlikte etkilere sebep olabilir (ör. sistem atıl zamanları, test gereksinimleri vb.). Bu görevler, destek seviyesi 1 ve 2’de kullanıcı tarafından yürütülen basit görevlerdir.

Görevler, yeni bir işlevsellik veya yeteneğin provizyonu için (yazılım yükleme, yazılım kaldırma, yazılım konfigürasyonu, harita vb. veri yükleme) sistemin geri döndürülmesi veya hata durumlarında problem raporlama (yazılımı geri döndürme, geri döndürme problemlerinin raporlaması - hata gerçekleştiğinde yazılım ve donanımların konfigürasyonu, hatanın tipi, geri döndürmenin başarım durumu, hatanın ciddiyeti), operasyon sonrası veri kaldırma ve organizasyonel görevler (yazılımın teslimi, operasyonel konfigürasyon kontrolü) olmak üzere 3 tipte sınıflandırılabilir.

Gömülü yazılımların veya bellenimlerin yükleme görevleri BGA’da belirlenmelidir.

'''<big>5.2.2. YÖNETİM DESTEĞİ</big>'''

Operasyonel destek ile yazılım modifikasyon görevleri arasında bir yerdedir. Her seviyede kullanıcı tarafından gerçekleştirilebileceği gibi destek organizasyonları tarafından da gerçekleştirilebilir. Problem raporlaması, sistem konfigürasyon kontrolü, teslim ve yükleme ile kullanıcı desteği gibi görev tipleri mevcuttur.

'''<big>5.2.3. YAZILIM MODİFİKASYON DESTEĞİ</big>'''

Yazılım modifikasyonu, düzeltici, adaptif veya tamamlayıcı sebeplerden ötürü olabilir. Genellikle yüklenici tarafında yapılan bir aktivite olsa da kritikliği düşük değişiklikleri karşılayan ekipman ve yetenekli personel varsa kullanıcı da gerçekleştirebilir. Yazılım modifikasyonu, kodlama değişikliğinin uygulanması ve test gibi modifikasyonun direkt kendi aktivitelerini ve problemin araştırılması ve konfigürasyon kontrolü gibi ilişkili görevleri de içerir. Genellikle, yazılım değişikliği için en kritik sebep ürünün operasyonunda kabul edilemez bir duruma sebep olan gerçek bir hata yaşanmasıdır. Adaptif değişiklikler de kritik bir durumdan kaynaklanabilir ancak daha tahmin edilebilir ve planlanabilir değişikliklerdir. Tamamlayıcı değişiklikler ise işlevselliği ve kullanıcı kolaylığını artırmak için yapılan değişikliklerdir. Genellikle bir sürüm yükseltme ile birlikte yapılırlar. Kullanıcı gereksinimleri bir süre boyunca toplanır ve yeni yazılım paketinin yayınlanmasıyla uygulamaya koyulurlar. Yazılım modifikasyon görevleri, problem araştırması, değişikliğin uygulanması, değişikliğin yayınlanması, konfigürasyon kontrolü faaliyetlerinden oluşur.

'''<big>6. DESTEK SINIFLARI</big>'''

'''<big>6.1. SÜREÇLER</big>'''

Yazılım desteğine ilişkin süreçlerin nasıl uygulamaya konulacağı, girdiler, çıktılar, kontroller ve kaynakları da içerecek şekilde dokümante edilmelidir. Bu kapsamda, akış şemaları, tanımlar, gereksinim ve sorumluluklar verilebilir. Uluslararası veya şirket içi kabul görmüş bir standart ve kullanılabilir ölçülebilir performans parametreleri tanımlanabilir.

'''<big>6.2. ÜRÜN</big>'''

Yazılım ürün karakteristiğinde desteklenebilirlik mümkün olduğunca erken safhalarda adreslenmelidir. Yazılım kalitesi, yazılımın ne kadar iyi ya da kötü tasarlandığına bağlıdır. İyi bir yazılım tasarımı için gereksinimlerin net bir şekilde tanımlanması ve grafiksel kullanıcı arayüzü desteğinin sağlanması gerekmektedir. Modülerlik, değiştirilebilirlik, genişletilebilirlik, basitlik, kolay kullanım, kararlılık, tutarlılık, işlem süresi performansı gibi hususlar tipik yazılım kalite göstergerleri olarak verilebilir.

'''<big>6.3. ÇEVRE</big>'''

Kaliteyi etkileyen çevresel durumlar yazılımı kullanacak ve destekleyecek personel ile başlar. Doğru bir yazılım desteği kapsamında personelin yazılım destek işi için doğru kişi olması, yetenek ve deneyiminin seviyesi, sorunsuz bir yazılım desteğini garanti etmek için kaç kişinin gerekeceği gibi konular önemlidir. Personele ek olarak, tesisler, ofislerin genişliği vb. konular da desteğin kalitesi açısından önemlidir. Bakım görevlerinin belirlenmesi kapsamında bu hususların mutlaka değerlendirilmesi gerekmektedir.

'''<big>7. DESTEKLENEBİLİRLİK FAKTÖRLERİ</big>'''

Yazılım için desteklenebilirlik faktörlerinin bazıları operasyonel destek ile ilişkiliyken, bazıları yazılım modifikasyon desteği ile ilgili olabilirler. Bu nedenle bu faktörlerin proje gereksinimleri dikkate alınarak ele alınması önemlidir. Yazılım desteklenebilirlik faktörleri ile ilgili açıklamalar ilerleyen bölümlerde verilmiştir. Yazılım desteklenebilirlik faktörlerinin geliştirme safhasında dikkate alınması (uygulanabilir olanlar için gereksinim tanımlanması, işlevsel akışa dahil edilmesi vb.) gerekmektedir.

'''<big>7.1. UYUMLULUK MATRİSİ</big>'''

Bir sistemde farklı donanımlar üzerindeki farklı yazılımların birlikte çalışabildiği ve yazılım kalemleri içeren fiziksel kırılım içerisinde yazılımların donanımlarla uyumluluğu doğrulanmalıdır. Yazılım paketi taşıyan birbiriyle konuşan ekipmanlarla ilişkili uyumluluk matrisi hazırlanmalıdır.

Tablo 24’de örnek bir uyumluluk matrisi verilmiştir. Tabloda verilen bilgilere göre, donanım 2 üzerinde yer alan ‘A’ ve ‘B’ yazılımlarının birbirileri ile uyumluluğu, benzer şekilde donanım 2 ile hem ‘A’ hem ‘B’ yazılımının uyumlu olduğu ve donanım 1 ile ‘A’ yazılımının uyumluluğu doğrulanmalıdır.

'''Tablo 25 Uyumluluk Matrisi'''
{| class="wikitable"
|
|Donanım 1
|Donanım 2
|-
|Yazılım A
|x
|x
|-
|Yazılım B
|<nowiki>-</nowiki>
|x
|}
'''<big>7.2. DOKÜMANTASYON</big>'''

Tanımlanmış bakım seviyeleri kapsamında yazılım destek dokümantasyonunun hazırlanması gerekmektedir. Yüklenici tarafında gerekli yazılım destek dokümantasyonu veya kullanıcıya tanımlanan yetkiler dahilinde son kullanıcı el kitabı, yükleme, konfigürasyon gibi amaçları olan yönetim dokümantasyonları olabilir.

Operasyonel açıdan, orta ve üst düzey kullanıcılar açısından dokümantasyon önemlidir. Dokümantasyon; yükleme, konfigürasyon adımları ve sorun giderme ile ilgili taktikler içermelidir. Ciddi hatalar oluşması durumunda da yüklenici firma iletişime geçilecek kişinin iletişim bilgilerini de içermelidir.

'''<big>7.3. YAZILIM YÜKLEME VE KALDIRMA</big>'''

Yazılımların güvenli bir şekilde sisteme yüklendiği, sistemin problemsiz çalıştığı ve yazılımın kaldırılması test prosedürleri ile doğrulanmış ve dokümante edilmiş olmalıdır.

'''<big>7.4. DONANIMLAR ÜZERİNDE TAŞINMA</big>'''

Eğer yazılımın bir donanım üzerinde taşınması gerekiyorsa yazılımın tipine, boyutuna ve güvenlik gereksinimlerine göre hangi donanımla taşınacağı belirlenir. Çipler veya usb belleklerle taşınıp taşınamayacağı, hard disk ya da DVD ihtiyacı olup olmadığı, donanımda taşımanının güvenli olup olmadığı değerlendirilmelidir.

'''<big>7.5. GENİŞLEME KAPASİTESİ</big>'''

Genişleme kapasitesi sistem tasarımının bir parçasıdır, yazılımla ilişkili olsa da genellikle tüm sistem tasarımı içerisinde ele alınması gereken bir donanım karakteristiğidir. Yazılımın hesaplama kaynakları üzerinde kısıtlamalarda (işlemci performansı, bellek, girdi/çıktı bant genişliği, veritabanı kapasitesi, network performansı vb.) limiti olmadan ne kadar değiştirilebildiği ile ilgilenir. Genişleme kapasitesi yeterli detayda ele alınmazsa yazılım modifikasyonu limitli olacaktır. Modifikasyon maliyeti ciddi ölçüde artacak ve ek aktiviteler gerekebilecektir. Genişleme kapasitesi, sabit donanım konfigürasyonu olan sistemlerde ve gömülü sistem gerçek zaman uygulamalarında yüksek önem taşır. Bu nedenle tasarım safhasında genişleme kapasitesinin göz önünde bulundurulması önemlidir.

'''<big>7.6. MODÜLER YAZILIM TASARIMI</big>'''

Modülerlik yazılım tasarım yapısının bir özelliğidir. Bir yazılım paketinin içindeki işlevselliğin farklı alanları modüller yardımıyla yapılandırılır. Bir yazılım tasarımına modülerlik kazandırma imkânı tasarım yöntemi, programlama araçları ve programlama dili seçimiyle belirlenir. Optimum modülerliğe, desteklenebilir tasarım karşısında işlevsel ve performans gereksinimlerinin dengelenmesi ile ulaşılır. Yetersiz modülerlik ilave modifikasyon eforuna ve maliyetine sebep olur. Bu nedenle tasarım safhasında modülerliğin göz önünde bulundurulması önemlidir.

'''<big>7.7. MODİFİKASYON FREKANSI (DEĞİŞİKLİK TRAFİĞİ)</big>'''

Yazılımın modifikasyon ihtiyacının oranıdır. Yazılım kullanımından önce modifikasyon frekansı tahminleri benzer uygulamaların (kullanımdaki yazılımlar) yardımı ile yazılımın bazı karakteristikleriyle, test ve deneme fazındaki deneyimlerle yapılabilir. Modifikasyon frekansının kararlılığı yazılım entegrasyonunu ve sistem operasyonunu etkiler. Değişiklik trafiği, yazılım destek aktivitelerinin hacmini etkiler. Yüksek değişiklik trafiği daha fazla yazılım modifikasyon aktivitesi demektir. Bu nedenle tasarım safhasında modifikasyon frekansının göz önünde bulundurulması önemlidir.

'''<big>7.8. GERİYE DÖNDÜRME</big>'''

Bir yazılım hatasından kaynaklı sistem çalışmadığında, sistemi yeniden başlatmak veya en azından kabul edilebilir bir sürede azalmış ama kabul edilebilir işlevselliğe getirmek gereklidir. Geriye döndürme yazılımın erken tasarım safhalarında, sağlıklı izleme durumu, hataya toleranslı denetimciler, hata ayıklama (debug) özelliği için tasarım gibi konular da değerlendirilmelidir. Erişilebilir ekipmanla operasyonel gerçek zaman güncellemesi gerçekleştirebilecek bir geriye döndürme özelliği olması kritik önem taşımakta olup geliştirme safhasında dikkate alınmalıdır. Gerçek bir acil durum oluşmadan yazılımın geriye döndürülmesi test edilmiş olmalıdır.

'''<big>7.9. EMNİYET ENTEGRASYONU</big>'''

Sistemin emniyet analizi yazılımlar da dikkate alınarak yapıldıktan sonra, sistem tasarımı kritik fonksiyonları olan yazılım kalemlerinin minimize edilmiş olduğunu ya da en azından kritik fonksiyonların yazılımın diğer kısımlarından ayrıştırıldığını garanti etmelidir. Emniyet entegrasyonu yalnızca yazılım tasarımıyla ilgili değildir. Yazılımın taşıma, yükleme ve kullanımında da (ör. yazılımlara kullanıcı erişimleri) belirli bir emniyet seviyesine ulaştığı garanti edilmelidir.

'''<big>7.10. GÜVENLİK</big>'''

Yazılımın kendisi ile ilgili olup; dijital imza, aktivasyon veya lisans anahtarları, kriptolama, çevrimsel hata denetimi gibi güvenlik metotları mevcuttur. Yazılımın güvenlik sınıflandırması, çalıştırılabilir kodu ve dokümantasyonu yazılım destek aktivitelerini kısıtlayabilir. Yazılıma erişim kısıtlanabilir ve spesifik yazılım test görevleri ve ekipmanlarının önemini artıracak gereksinimler tanımlanabilir. Yazılımın güvenlik sınıflandırması, uygulamaya ve ekipmanın tasarımına bağlıdır. Mümkün olduğu ölçüde güvenlik seviyesi yüksek yazılımlar, sistemdeki diğer yazılımlardan ayrı olmalıdır. Güvenlik gereksinimleri sınıflandırmada kullanılacak ve sınıflandırmaya uygun olarak modifikasyon ve yazılımın ele alma kısıtlarını belirleyecektir.

Güvenliğin diğer bir boyutu operasyonel karakteristiktir. Yazılım paketinin hem uygun kullanıcı erişimi gibi iç güvenlik hem de dış güvenlik açısından güvenli bir ortamda çalıştığı garanti edilmelidir. Bu anlamda ağ ve güvenlik duvarı yönetim aktiviteleri, virüs tespiti ve savunma aktiviteleri gerçekleştirilir.

Savunma ve güvenlik sistemlerindeki yazılımlar üçüncü tarafın eline geçmemesi için kullanımdan sonra silinebilir. Bu konuya ilişkin tedbirlerin alınmış olması gerekir.

'''<big>7.11. BOYUT</big>'''

Yazılım paketinin boyutu, beklenen değişiklik trafiği seviyesi ve modifikasyonları uygulamak için gereken kaynaklar açısından desteklenebilirlik parametrelerini etkiler. Yazılımın boyutu, uygulamaya ve tasarım çözümüne bağlıdır. Sistem tasarımında boyutla ilgili bir kısıt varsa yazılım gereksinimlerinde belirtmelidir. Birçok yazılım desteği yazılımın boyutuna ve karmaşıklığına bağlıdır.

'''<big>7.12. YETKİNLİKLER</big>'''

Yetkinlik gereksinimleri, sistem tasarımı, yazılım tasarımı ve uygulanabilir yazılım destek politikası tarafından belirlenir. Personelin yetkinlik seviyesi, birden fazla açıdan değerlendirilmelidir. Sırasıyla basit düzeyde kullanıcı, yönetim sorumluluğu olan operatörler ve en yetkin olması gereken yazılım modifikasyonu yapacak kişilerdir.

'''<big>7.13. YAZILIM DAĞITIMI</big>'''

Yazılım LAN, WAN gibi ağlar üzerinden veya bir donanım aracılığıyla farklı medya tipleri ile dağıtılabilir.

'''<big>7.14. TEKNOLOJİ</big>'''

Yazılım tasarım yöntemleri ve destek araçları, işleten sistemler, programlama dilleri, derleyiciler, hata ayıklayıcılar, yazılım test metot ve test ortamı, projeye özgü ekipman ve teknikler gibi yazılım mühendisliği metotları ve yazılım geliştirme-uygulamada kullanılan araçlar da dikkate alınmalıdır. Teknolojinin ağ üzerinden yapılacak destek bakım konseptini kolaylaştırması gibi operasyonel olarak da etkileri vardır.

== EK-I ÖRNEK LDA PLANI ==
'''<big>1. GENEL</big>'''
* Programın hem yüklenici hem de müşteri tarafındaki yönetim yapıları
* LDA faaliyetlerinin proje takvimi ile entegrasyonu
* Sorumluluklar
* Değişiklik yönetimi
* Risk yönetimi
* İş paylaşımı anlaşmaları

'''<big>2. SİSTEM TANIMI VE OPERASYONEL KONSEPT TANIMI (BKZ. BÖLÜM 5.1)</big>'''

'''<big>3. LDA SÜRECİNİN VE ANALİZ FAALİYETLERİNİN AMACI</big>'''

LDAK’nın çıktılarından biri olarak, yüklenici ve müşteri LDA faaliyetleri sonucu oluşan verilerin nasıl kullanılacağına dair prensiplerde anlaşmalıdır. Analiz verilerinin bir lojistik veri tabanında dokümante edilmesi gereksinimi, veri toplamanın amacını da ortaya koymalıdır. Bu amaçla, hangi veri elemanlarının lojistik veri tabanında kaydedileceği dikkatle kararlaştırılmalı ve veri elemanları tanımlanan bu amaçlarla ilişkilendirilmelidir. Seçim konusundaki bu hassasiyet analiz faaliyetleri açısından da gösterilmelidir. Özellikle geniş kapsamlı ve detaylı analizler için seçim teknik ve ekonomik hususları dikkate alarak gerçekleştirilmelidir.

Proje kapsamında uygulanmasına karar verilen analiz faaliyetleri;

* EK-A İnsan Faktörü Analizleri ve LDA,
* EK-B HTE(K)A ve Sonuçlarının LDA İçerisine Kullanımı,
* EK-C Hasar ve Özel Olay Analizleri,
* EK-D Lojistik İlişkili Operasyonlar Analizi,
* EK-E Planlı Bakım Programı Geliştirme,
* EK-F Onarım Seviyesi Analizi,
* EK-G Bakım Görev Analizi,
* EK-H Yazılım Destek Analizi,
* İdame Edilebilirlik (Bkz Bölüm 6.2.3) Analizi.

bölümlerinde yer alan yöntemler uygulanarak gerçekleştirilmelidir. Ancak ilgili yöntemlerin proje türü, süreçleri ve gereksinimlerine göre hangi kural ve varsayımlar çerçevesine nasıl uygulanacağı alt başlıklar halinde detaylı bir şekilde uyarlanmalıdır. Hangi faaliyetlerin hangi seviyede yapılacağı bilgisi ile yapılan uyarlamalar ile gerekçeleri LDAP’ın bu bölümünde belirtilmelidir.

'''<big>4. ÜRÜN KIRILIM YÖNTEMİ</big>'''

Planın bu bölümünde bir ürün kırılım yöntemi oluşturmak üzere kurallar belirlenmelidir. Müşteri ve Yüklenici arasında, kırılım elemanlarının nasıl tanımlanacağı (ör, S1000D Standart Numaralandırma Sistemi, 1388-2B Lojistik Kontrol Numarası sistem veya Müşteri tarafından tercih edilecek diğer sistem) açıklığa kavuşturulmalıdır. Kırılım için hem fiziksel hem de işlevsel yapının birlikte kullanılması gerekli görülüyorsa, bu iki yapının birbiri ile nasıl ilişkilendirileceği tanımlanmalıdır. Yöntem, yazılım kalemlerinin hiyerarşik yapıda nasıl kapsanacağını ve farklı nihai ürün varyantlarının nasıl ele alınacağını da açıklamalıdır.

'''<big>5. ANALİZ EDİLEN KALEM İÇİN KIRILIM DERİNLİĞİNİN BELİRLENMESİ</big>'''

Kırılım türünün yanısıra derinliği de son derece önemli bir niteliktir. Nihai karar verilirken aşağıdaki hususlar dikkate alınmalıdır:

* İlgili bütün yedek parçaları belirlemek için tam detaylı bir kırılım gerekli midir ve bu kırılım uygun ve etkili midir?
* Sadece HDB seviyesine kadar inen bir kırılım uygun ve etkili midir?
* Belirli yetki kademeleri için tanımlanmış tamir konsepti için hangi seviyede kırılım gereklidir?
* Eğer isteniyorsa, işlevsel kırılım hangi amaçla gerekli görülmektedir (ör. planlı bakım analizleri) ve işlevsel kırılım ile fiziksel kırılım arasındaki bağlantı nasıl oluşturulmaktadır?

'''<big>6. LDA ADAY SEÇİM KRİTERLERİ</big>'''

LDA adaylarının seçimi için oluşturulan kriterler LDA Planında dokümante edilmelidir. Bu konuda bir akış şeması da oluşturulabilir.

'''<big>7. ADAY KALEM LİSTESİ (AKL)</big>'''

LDA İş Tanımlama Toplantısı (LDAİTT)’na hazırlık olarak yüklenici tarafından taslak bir AKL hazırlanmalı, toplantıda yüklenici ve müşteri arasında tartışılarak AKL üzerinde mutabakata varılmalıdır. Üzerinde uzlaşılan AKL, LDAİTT’nın resmi bir çıktısıdır.

'''<big>8. ADAY ELEMANLAR İÇİN POTANSİYEL ANALİZ FAALİYETLERİ</big>'''

AKL sadece ürün ağacından analize tabi olmak üzere seçilen elemanları değil aynı zamanda bu elemanlar için gerçekleştirilecek analiz faaliyetlerini de içerebilir. Seçilen analizlerle birlikte, analizlerin gerçekleştirileceği derinlik de tanımlanmalıdır. Örneğin BGA için her bir bakım görevinin hangi derinlikte dokümante edileceği ve personel gereksinimlerinin belirlenmesine gerek olup olmadığı tanımlanmalıdır.

AKL aynı zamanda LDA programı için bütün eforun özetlendiği bir gözden geçirme vasıtası olarak ve çalışmaların ilerlemesinin takip edildiği bir yönetim aracı olarak da kullanılabilir.

'''<big>9. YEDEK PARÇALARIN BELİRLENMESİ VE YEDEK PARÇA SAYILARININ HESAPLAMASI (Bkz. EK-G BAKIM GÖREV ANALİZİ) </big>'''

'''<big>10. HİZMET İÇİ KULLANIM VE DESTEK SAFHALARI LDA FAALİYETLERİ (Bkz. BÖLÜM 7)</big>'''

'''<big>11. LDA SÜRECİ-TASARIM SÜRECİ ARAYÜZÜ</big>'''

Yapılan LDA faaliyetleri ile tasarım faaliyetlerinin birbiri ile arayüzünün nasıl tesis edileceği ve izlenebilirliğin nasıl sağlanacağı bu bölüm kapsamında açıklanmalıdır.

'''<big>12. LDA SÜRECİ-ELD SÜRECİ ARAYÜZÜ</big>'''

Yapılan LDA faaliyetleri ile ELD faaliyetlerinin birbiri ile arayüzünün nasıl tesis edileceği ve izlenebilirliğin nasıl sağlanacağı bu bölüm kapsamında açıklanmalıdır.

'''<big>13. LDA FAALİYETLERİNİN PERFORMANSININ ÖLÇÜLMESİ VE DOĞRULANMASI</big>'''

LDA faaliyetlerinin performansı, örneğin lojistik veri tabanın statü bilgisi vasıtasıyla sürekli olarak değerlendirilmelidir. Bir analiz faaliyetinin tam olarak gerçekleştirilmesi veya bir aday bileşenin bilgilerinin lojistik veri tabanında tam olarak dokümante edilmesine dair kriterler açık bir şekilde belirlenmelidir ve gerektiğinde kabul kriteri olarak tanımlanmalıdır.

'''<big>14. BİLİŞİM HUSUSLARI</big>'''

Farklı bölgelerdeki aynı analiz aktiviteleri için farklı yazılım paketleri kullanılmamalıdır. Kullanılması durumunda entegrasyon ve uyumlandırma süreçleri açısından bir takım riskler oluşabilir. Lisans ile ilişkili hususlar, sözleşmesel kısıtlar, bilişim hususları ile ilişkili türlü faktörlerden birçok proje farklı yazılım paketleri kullanmaktadır. Böyle bir durumda, gerçekleştirilecek görevler için tüm paydaşlar arasında uyumlu olan yazılım paketinin kullanımı tavsiye edilir. Yazılım paketleri ile ilgili kararlar LDA GGT’da dokümante edilmelidir. Bir program esnasındaki yazılım yayımlama değişiklikleri uyumlandırılmalı ve etkilenen tüm paylaşlar arasında mutabakat sağlanmalıdır.

'''<big>DOKÜMANIN HAZIRLANMASINDA GÖREV ALAN KURUM/KURULUŞLAR</big>'''

SAVUNMA SANAYİİ BAŞKANLIĞI

MİLLİ SAVUNMA BAKANLIĞI

KARA KUVVETLERİ KOMUTANLIĞI

HAVA KUVVETLERİ KOMUTANLIĞI

TERSANELER GENEL MÜDÜRLÜĞÜ

ASELSAN A.Ş.

ASFAT A.Ş.

BMC OTOMOTİV SANAYİ VE TİCARET A.Ş.

HAVELSAN A.Ş.

METEKSAN SAVUNMA SANAYİ A.Ş.

MİLSOFT YAZILIM TEKNOLOJİLERİ A.Ş.

NUROL MAKİNA VE SANAYİ A.Ş.

OTOKAR OTOMATİV VE SAVUNMA SANAYİ A.Ş.

ROKETSAN A.Ş

SATURN DANIŞMANLIK EĞİTİM VE MÜH.LTD.ŞTİ.

SDT UZAY VE SAVUNMA TEKNOLOJİLERİ

VİYA LOJİSTİK MÜHENDİSLİK VE BİLİŞİM TEKNOLOJİLERİ LTD.ŞTİ.

Lojistik Destek Analizleri ve Kayıtları Rehberi

2022-08-25T07:54:55Z

Oozdemir: /* EK-F ONARIM SEVİYESİ ANALİZİ (OSA) */

Dosya:TSSÖDYP06.ÖRNEK OSA.jpg

2022-08-25T07:54:30Z

Oozdemir:

TSSÖDYP06.ÖRNEK OSA

Lojistik Destek Analizleri ve Kayıtları Rehberi

2022-08-25T07:52:40Z

Oozdemir: /* EK-G BAKIM GÖREV ANALİZİ (BGA) */

'''[https://tssodypwiki.ssb.gov.tr/images/9/95/TSSODYP_06_180822_web.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şkanlığı çatısı altında, ilgili tüm paydaşların katılımıyla faaliyet göstermek üzere Türk Savunma Sanayii Ömür Devri Yönetimi Platformu (TSSÖDYP) kurulmuştur.

TSSÖDYP; savunma ve güvenlik sistemlerine ilişkin ihtiyacın belirlenmesi, sistemlerin tedariki, kullanımı, desteklenmesi ve envanterden çıkarması safhalarını bir bütün halinde ele alan Sistem Ömür Devri Yönetimi ilke ve uygulamalarının ülkemizde yaygınlaştırılmasını ve savunma programlarının/ projelerinin yürütülmesinde savunma ve güvenlik ekosistemini oluşturan tüm paydaşlarca anlayış birliğine ulaşılmasını amaçlamaktadır.

Savunma sistemlerinin ömür devri yönetiminde millî bünyemize uygun, ülkemize özgü çözümler üretmek ve bunları dokümante etmek gibi önemli bir misyonu olan TSSÖDYP; Başkanlığımız, Milli Savunma Bakanlığı ve ilgili birimleri, Genelkurmay Başkanlığı, K.K.K.lığı, Dz.K.K.lığı, Hv.K.K.lığı, J.Gn.K.lığı, S.G.K.lığı, EGM, TÜBİTAK, SASAD ve savunma sanayii firmaları temsilcilerinin katılımı ile çalışmalarına devam etmektedir.

Sistem ömür devri yönetimi yaklaşımı ile; savunma ve güvenlik sistemlerine ilişkin ihtiyacın belirlenmesi aşamasından envanterden çıkarma safhasının sonuna kadar görev alan tüm kamu kurum ve kuruluşları ile özel sektör firmalarının sistemlerin istenilen performans seviyesinde mümkün olan en az maliyetle tedariki, kullanımı ve lojistik desteğinin sağlanabilmesi için görev, yetki ve sorumlulukları çerçevesinde ömür devrinin tamamında birlikte çalışmaları öngörülmektedir.

Bu itibarla, savunma ve güvenlik sistemlerine ilişkin ihtiyacın belirlenmesinin, tedarikinin, kullanımının, lojistik desteğinin ve envanterden çıkarılmasının en baştan uzun soluklu bir program olarak kurgulanmasının ve ilgili birimler aracılığı ile sistem ömür devri yönetimi faaliyetlerinin yürütülmesinin faydalı olacağı değerlendirilmektedir.

TSSÖDYP tarafından son iki buçuk yıl içinde gerçekleştirilen çalışmalar ile savunma ve güvenlik sistemlerinin ömür devri yönetimine ilişkin planlama ve uygulamaya esas olacak yaklaşımları ortaya koyan 13 adet rehber, iki adet bilgi kitapçığı ve bir adet terminoloji dokümanı hazırlanmıştır. Uygulamalardan alınacak geri bildirimler ile söz konusu dokümanların güncellenmesi, geliştirilmesi ve önümüzdeki dönemde uygulamaya esas düzenlemelerin alt yapısını oluşturması hedeflenmektedir.

TSSÖDYP çalışmalarına katkı veren ve dokümanların hazırlanmasında görev alan tüm paydaşlarımıza teşekkürlerimi sunuyorum.

Prof.Dr. İsmail DEMİR

T.C. Cumhurbaşkanlığı

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.

Bu nedenle, tedarik edilen sistemlerin kullanım döneminde hedeflenen muharebe ve/veya operasyon performansının sürdürülebilirliğinin ve maliyet etkinliğinin sağlanması amacıyla sistemlerin ömür devrinde rol ve sorumluluğu bulunan tüm paydaşların katılımı ile Sistem Ömür Devri Yönetimi yaklaşımı geliştirilmiştir.

Sistem Ömür Devri Yönetiminin temel amacı; mevcut durumdaki değişimlere uyum sağlamaktan ziyade gelecekte ortaya çıkabilecek değişimleri öngörmek, belirlenen hedefler doğrultusunda gerekli önlemleri alarak değişimleri yönlendirmek ve kontrol altında tutmaktır. Harekât ihtiyaçlarının zamanında ve verimli şekilde karşılanması ve sahip olunan kaynakların maliyet etkin kullanımı esastır. Başka bir deyişle, sistem ömür devri yönetimi geleceği bugünden tasarlamak ve planlamaktır.

Bu doküman; Savunma Sanayii Başkanlığı (SSB), Milli Savunma Bakanlığının ilgili birimleri, Türk Silahlı Kuvvetleri (TSK), diğer ihtiyaç makamları ve savunma sanayi firmalarında sistem ömür devri yönetiminin bir kültür olarak yaygınlaştırılmasına ve uygulanmasına yönelik rehber oluşturmak amacıyla savunma sistemlerinin ömür devrinde rol ve sorumluluğu bulunan ilgili paydaşların katılımıyla hazırlanmıştır.

Lojistik Destek Analizi (LDA); desteklenebilirlik açısından ürün tasarımını etkilemeyi amaçlayan tasarımın erken aşamalarında başlayıp ömür devri boyunca devam eden güvenilirliği, kullanıma hazır olmayı, idame edilebilirliği, maliyeti ve zaman etkinliğini ön plana çıkaran analizlerden oluşan bir süreçtir.

LDA, sistemin ve bileşenlerinin belirlenmiş kullanıma hazır olma ve desteklenebilirlik /sürdürülebilirlik ihtiyaçlarına ulaşılabilmesi amacıyla ürün tasarımı ile destek sistemini/organizasyonunu entegre eden sistematik ve yinelemeli analizler bütünüdür. LDA sonuçları elektronik veritabanında dokümante edilir. Lojistikle ilgili dokümante edilen bilgiler Entegre Lojistik Destek (ELD) fiziksel kaynaklarının (örn. iş gücü ve personel, yedek parça, eğitim, destek ekipmanları, eğitim ve eğitim desteği teknik yayınlar vb) belirlenmesini, optimize edilmesini ve izlenebilirliğini sağlar.

= 1. GENEL =

== 1.1. GİRİŞ ==
Bu doküman, Türk Savunma Sanayii Ömür Devri Yönetim Platformu (TSSÖDYP) tarafından Entegre Lojistik Destek (ELD) faaliyetlerinin merkezinde yer alan Lojistik Destek Analizleri’nin (LDA) gerçekleştirilmesi ve bu analizler sonrasında oluşturulacak LDA Kayıtları konusunda rehberlik etmek üzere hazırlanmıştır.

== 1.2. AMAÇ ==
Bu rehberin amacı ülkemizde yürütülen program/projelerde savunma ve güvenlik sistemlerinin ömür devri boyunca gerçekleştirilebilecek LDA faaliyetlerine yönelik uygulanması önerilen süreçleri, genel gereksinimleri ve bilgi/veri değişim yöntemlerini tanımlamaktır. Rehber aynı zamanda ihtiyaç makamı, kullanıcı, idame makamı, tedarik makamı, yüklenici, ve diğer paydaşlar arasında LDA faaliyetlerinin gerçekleştirilmesine yönelik arayüzleri ortaya koymayı ve LDA ihtiyaçlarının sözleşmelerde en doğru şekilde tanımlanabileceği, LDA çıktılarının neler olabileceği ve paydaşlar tarafından nasıl kullanılabileceğine dair yol gösterici olmayı hedeflemektedir.

Desteklenebilir ürünler ve en uygun destek çözümlerinin maliyet etkin şekilde geliştirilmesinde önemli bir rolü olan LDA faaliyetlerinin ürün ömür devri safhalarına uygun olacak şekilde yürütülmesi ve proje türü ve büyüklüğüne göre uyarlanması gerekmektedir. Bu çerçevede, kaynakların etkin şekilde kullanılması ve yürütülen faaliyetlerden azami seviyede verim elde edilmesi rehberin birincil amaçları arasında yer almaktadır.

Bu doküman, savunma ve güvenlik sektöründe görev alan tüm paydaşların Lojistik Destek Analizleri ve Kayıtları faaliyetlerinde rehberlik etmek üzere hazırlanmıştır.

== 1.3. KAPSAM ==
Bu rehber:

* Savunma ve güvenlik projelerinde/programlarında yürütülecek lojistik destek analizleri ve yöntemleri hakkında bilgiler,
* LDA süreçleri ve gereksinimleri,
* Analiz sonuçlarının nasıl değerlendirileceği ve maliyet-etkin bir çözüme nasıl ulaşılabileceğine dair kılavuz bilgiler,
* LDA ve desteklenebilirlik mühendisliği disiplinleri (Örn. güvenilirlik, idame edilebilirlik, test edilebilirlik, sürdürülebilirlik, kullanıma hazır olma) arasındaki ara yüzler,
* LDA ve diğer ELD elemanları (ikmal destek, teknik veri, eğitim ve eğitim desteği vb.) arasındaki ara yüzler,
* LDA sürecinin nasıl uyarlanacağına dair genel ilkeler,

hakkında bilgiler içermektedir.

== 1.4. REHBERİN KULLANIMI ==
Bu doküman savunma ve güvenlik projelerinde/programlarında kullanılabilecek LDA sürecinin ve metodolojisinin ana hatlarıyla tanımlanması amacıyla 5 bölümden oluşmaktadır:

* İlk bölüm; giriş, amaç, kapsam, referanslar gibi genel bilgileri içermektedir; ayrıca terim ve kısaltmalar da bu bölümün içindedir.
* İkinci bölümde, lojistik destek analizleri ile ilgili genel bir bilgilendirme yapılmaktadır.
* Üçüncü bölümde; sistem tasarımının ayrılmaz bir parçası olan desteklenebilirlik kavramı ve desteklenebilirlik ilişkili tasarım faktörlerinin hangi aşamalarda değerlendirilmesi gerektiği hususlarına yönelik açıklayıcı bilgiler yer almaktadır.
* Dördüncü bölümde, herhangi bir projenin başlangıç aşamasında ihtiyaç makamı ve yüklenicinin LDA gereksinimlerinin belirlenmesine ilişkin nasıl anlaşmaya varacaklarına yönelik izlenecek yol yer almaktadır,
* Beşinci bölümde, yüklenici ve müşteri uygun desteklenebilirlik seviyesine erişmek için gerçekleştirilmesi gereken faaliyetlerin tanımlandığı LDA süreci açıklanmaktadır,
* Altıncı bölümde, tasarıma etki/tasarım etkileşimi
* Yedincibölümde, kullanım ve destek safhalarında gerçekleştirilen LDA ve bu analizler sonucunda reaktif/proaktif aksiyonların alınarak ürün performansının beklenen düzeyde seyrinin sağlanmasına ilişkin süreç yer almaktadır,
* Sekizinci bölümde, konfigürasyonlarının doğru belirlenmesi, değişikliklerin kontrol edilmesi ve değişikliklerin uygulanma durumunun kayıt altına alınmasını sağlayan konfigürasyon yönetimi disiplininde izlenebilirliğin LDA çerçevesinde yürütülmesi ilişkisi yer almaktadır,
* Dokuzuncu bölümde, LDA’nın lojistik desteğin yönetilmesi için düzenli yürütülerek kayıt altına alınması, değerlendirilmesi faaliyetlerinin esasları ve standartları açıklanmaktadır. Programlara/projelere özgü olarak yine ihtiyaç sahipleri ve yükleniciler bu rehberde referans verilen veya diğer ulusal/uluslararası standart/spesifikasyonların ilave olarak kullanılması konusunda mutabakat sağlayabilirler. Projenin/ürünün karmaşıklık seviyesi ilave olarak kullanılabilecek standart/spesifikasyonları belirlemede de etken olacaktır,
* Onuncu bölümde, fiziksel destek kaynak gereksinimlerinin belirlenmesi ve destek ürünlerinin oluşturulması kapsmaında ELD elemanlarına ilişkin çalışmaların yürütlmesine yönelik bilgiler verilmektedir,
* Onbirinci bölümde, LDA ve kayıtlarına ilişkin faaliyetlerin uyarlanmasına yönelik olarak tanımlanan bütün faaliyetlerin/analizlerin her türlü projede ve her safhada gerçekleştirmek yerine etkin uygulamaların yapılmasını sağlamak amacıyla kullanıcıların projelere özgü görev/faaliyetleri seçebilmesi için yol gösterecek içerik yer almaktadır,
* Dokümanın son bölümünde ise ilgili ekler yer almaktadır.

== 1.5. REHBERİN GÜNCELLENMESİ ==
Rehberin yüklenici, ihtiyaç makamı ve diğer paydaşlar tarafından referans alınarak kullanılması kapsamında güncellenme ihtiyacının olması durumunda aşağıda sunulan izleme tablosu yardımıyla değişikliklerin takibi sağlanacaktır.

'''Tablo 1 Değişiklik İzleme Tablosu'''
{| class="wikitable"
|'''Revizyon No'''
|'''Revizyon Tarihi'''
|'''Değişiklik Yapılan Başlık No'''
|'''Yapılan Değişiklik'''
|-
|01
|Ağustos 2021
|
|İlk Yayın
|-
|
|
|
|
|-
|
|
|
|
|}

== 1.6. REFERANSLAR ==
{| class="wikitable"
|1.
|MIL-HDBK-502A Product Support Analysis, Mart 2013
|-
|2.
|ASD/AIA S3000L International Procedure Specification for Logistics Support Analysis (LSA), Temmuz 2014
|-
|3.
|ASD S4000P International Specification for Developing and Continuously Improving Preventive Maintenance, Ağustos 2018
|-
|4.
|MIL-STD-1388-2B DoD Requirements for a Logistic Support Analysis Record, Mart 1991
|-
|5.
|SAE ARP5580 Recommended Failure Modes and Effects Analysis (FMEA) Practices for Non-Automobile Applications
|-
|6.
|TSSÖDYP Doküman Seti
|}
{| class="wikitable"
|+
! colspan="2" |'''TSSÖDYP DOKÜMAN SETİ'''
|-
|'''DOKÜMAN ADI '''
| '''DOKÜMAN KODU'''
|-
|Sistem Ömür Devri Yönetimi Rehberi (Ana Çerçeve)
|TSSÖDYP-01
|-
|Sistem Ömür Devri Yönetimi Süreçleri Rehberi
|TSSÖDYP-02
|-
|Ürün Destek Stratejileri ve Modelleri Rehberi
|TSSÖDYP-03
|-
|Entegre Lojistik Destek (ELD) Rehberi
|TSSÖDYP-04
|-
|Entegre Lojistik Destek (ELD) İsterleri Hazırlama Rehberi
| TSSÖDYP-05
|-
|Lojistik Destek Analizleri ve Kayıtları Rehberi
|TSSÖDYP-06
|-
|Tedarik Zinciri Yönetimi Rehberi
|TSSÖDYP-07
|-
|Sistem Ömür Devri Yönetiminde Demodelik Yönetimi Rehberi
|TSSÖDYP-08
|-
|Kullanım ve Destek İhtiyaçları Çerçevesinde Yerlileştirme/

Millîleştirme Rehberi
|TSSÖDYP-09
|-
|Kullanım ve Destek Safhaları Kalite Yönetimi Rehberi
|TSSÖDYP-10
|-
|Sistem Ömür Devri Yönetiminde Konfigürasyon Yönetimi Rehberi
|TSSÖDYP-11
|-
|Teknik Yayın Hazırlama Rehberi
|TSSÖDYP-12
|-
|Eğitim ve Eğitim İhtiyaçları Rehberi
|TSSÖDYP-13
|-
|Sistem Ömür Devri Yönetimi Terminolojisi
|TSSÖDYP-14
|-
|Kodlandırma ve Sınıflandırma Bilgi Kitapçığı
|TSSÖDYP-15
|-
|ASD/AIA S-Serisi ELD Spesifikasyonları Seti Tanıtım Kitapçığı
|TSSÖDYP-16
|}

== 1.7. TANIMLAR VE KISALTMALAR ==

=== 1.7.1. TANIMLAR ===
'''Tablo 2 Tanımlar Tablosu'''
{| class="wikitable"
|'''Terim'''
|'''Tanım'''
|'''Diğer Kullanım'''
|-
|Emniyet

Safety
|Ölüm, yaralanma, mesleki hastalık, ekipman veya mülkte hasar veya kayıp veya çevreye verilen hasara neden olabilecek koşullardan bağımsız olmak.
|
|-
|Güvenilirlik

Reliability
|Belirli bir zaman periyodunda, istenen çevresel ve coğrafi şartlar altında ve belirlenen kullanım profillerinde sistemin gereken fonksiyonunu hata yapmadan yapabilme/başarabilme olasılığıdır.
|
|-
|İdame Edilebilirlik

Maintainability
|Belirlenmiş prosedür ve kaynaklar kullanılarak, tanımlı bakım onarım seviyelerinde belirlenmiş yeteneğe sahip personel tarafından bakım faaliyeti gerçekleştirildiğinde, odak sistemin öngörülen performans seviyesinde tutulabilmesi veya öngörülen performans seviyesinde tekrar çalışır duruma geri getirilebilmesi kabiliyetinin ölçüsüdür.
|
|-
|Kullanıcı

User
|Harp araç, silah ve malzemelerini kullanacak ve/veya idamesini sağlayacak birimleri ifade eder.
|İhtiyaç Makamı/İdame Makamı
|-
|Kullanıma Hazır Olma

Availability
|Sistemlerin istenilen herhangi bir zamanda, istenilen performans ölçütlerini karşılayacak şekilde faal durumda olma ihtimalidir.
|
|-
|LDA İş Tanımı Dokümanı

LSA Guidance Conference Document
|LDA İş Tanımlama Toplantısı’nda değerlendirilen bulguların, analizlerin, yürütülecek faaliyetlerin ve sonuç kararlarının mutabakat altına alındığı dokümandır.
|LDA Kılavuz Konferansı Belgesi
|-
|LDA İş Tanımı Toplantısı

LSA Guidance Conference
|Desteklenebilirlik açısından ürün tasarımını etkilemeyi amaçlayan, tasarımın erken aşamalarında başlayıp, ömür devri boyunca devam eden; güvenilirliği, kullanıma hazır olmayı, maliyeti ve zaman etkinliğini ön plana çıkaran bir dizi analiz sürecinin performansına ilişkin bağlayıcı kararların alınmasını sağlayan, kullanıcı/tedarik makamı ve yüklenici tarafından yönetim kadrosu ve uzmanların katılımıyla gerçekleştirilen toplantılardır.
|LDA Kılavuz Konferansı
|-
|Müşteri

Customer
|Süreç çıktılarının teslim edildiği, yani çıktıların kullanıcısı olan taraflardır. İç müşteriler, organizasyon içinde yer alan ve sürecin bir sonraki adımı için çıktıları kullanan fonksiyon ya da fonksiyonlardır. Dış müşteriler ise, organizasyon dışında yer alan kişi ya da kuruluşlardır.
|Alıcı, İhtiyaç Makamı, Kullanıcı, Tedarik Makamı, İdame Makamı
|-
|Teklife Çağrı Dokümanı

Request for Proposal
|Tedarik edilecek ürün ve hizmet alımları ile yapım işlerinin teknik şartnamesi, ihale konusu işin tanımı, hangi şartlarda yapılacağı, sözleşme görüşmelerine esas mali, idari, hukuki hususları ve teklif verme şekli gibi konuları kapsayan dokümandır.
|
|-
|Ürün

Product
|Yüklenici tarafından, sözleşme kapsamında tedarik makamına teslim edilecek ve her bir sözleşme değişikliği için belirtilen kalemler ve bunlara ilişkin tüm sistem, donanım, yazılım ve dokümanlardır. Bu kalemler kara, deniz, hava araçları, platformlar, silah, sistem, yazılım ve bunlara ilişkin tüm destek donanım ve yazılımlarını içerebilir.
|
|-
|Ürün Kırılımı

Product Breakdown
|En az değiştirilebilir kalemlere kadar inen ürünün ürün ağacının lojistik açıdan incelenmiş fizikselkırılımıdır.
|
|-
|Yönetişim

Governance
|Resmî ve özel kuruluşlarda idari, ekonomik, politik otoritenin ortak kullanımı, karşılıklı etkilerin birlikte belirlenerek yönetimi.
|
|-
|Yüklenici

Contractor
|Bir sözleşme ile hizmet veya ürünü tasarlayan/geliştiren/üreten veya teslim/ifa eden firma, kurum ve kuruluşlar.
|
|}
=== 1.7.2. KISALTMALAR ===
'''Tablo 3 Kısaltmalar Tablosu'''
{| class="wikitable"
|'''Kısaltma'''
|'''Açık Yazımı'''
|'''Diğer Kullanım'''
|-
|<nowiki>-AIA</nowiki>
|Aerospace Industry Association of America
|
|-
|<nowiki>-ASD</nowiki>
|Aerospace andDefenceIndustries Association of Europe
|
|-
|AAK

IUA
|Analiz Altındaki Kalem

ItemUnder Analysis
|
|-
|AAS

SUA
|Analiz AltındakiSistem

SystemUnder Analysis
|
|-
|AKL

CIL
|Aday Kalem Listesi

Candidate Item List
|
|-
|BİM

MRI
|Bakım İlgili Malzeme

Maintenance Relevant Item
|
|-
|BÖM

MSI
|Bakım Önemli Malzeme

Maintenance Significant Item
|
|-
|DSB

TBD
|Daha Sonra Belirlenecek

To Be Determined
|
|-
|ELD

ILS
|Entegre Lojistik Destek

Integrated Logistics Support
|
|-
|GGT

RC
|Gözden Geçirme Toplantısı

Review Conference
|GGK

Gözden Geçirme Konferansı KK

Kılavuz Konferansı
|-
|GMB

RCM
|Güvenilirlik Merkezli Bakım

Reliability Centered Maintenance
|
|-
|HDB

LRU
|Hatta Değiştirilebilir Birim

Line Replaceable Unit
|
|-
|HTEA

FMEA
|Hata Türleri Etkileri Analizi

Failure Modes and Effects Analysis
|
|-
|HTEKA

FMECA
|Hata Türleri Etkileri ve Kritiklik Analizi

Failure Modes, Effects and Criticality Analysis
|
|-
|KKK
|Konfigürasyon Kontrol Kurulu
|
|-
|LDA

LSA
|Lojistik Destek Analizi

Logistic Support Anaylsis
|
|-
|LDAK

LSAR
|Lojistik Destek Analizi Kayıtları

Logistic Support Analysis Records
|
|-
|LDAP

LSAP
|Lojistik Destek Analizi Planı

Logistics Support Analysis Plan
|
|-
|LDAİTT
|Lojistik Destek Analizi İş Tanımlama Toplantısı
|
|-
|BGA

MTA
|Bakım Görev Analizi

Maintenance Task Analysis
|
|-
|NATO

NATO
|North Atlantic Treaty Organization
|
|-
|NSN

NSN
|NATO Stok Numarası

NATO Stock Number
|
|-
|ODS

MDT
|Ortalama Duruş Süresi

Mean Downtime
|
|-
|OOS

MTTR
|Ortalama Onarım Süresi

Mean Time to Repair
|
|-
|OSA

LORA
|Onarım Seviyesi Analizi

Level of Repair Analysis
|
|-
|ÖDM

LCC
|Ömür Devri Maliyeti

Life Cycle Cost
|
|-
|PEDU

PHST
|Paketleme Elleçleme Depolama Ulaştırma

Packaging Handling Storage Transportation
|
|-
|RAHAT

COTS
|Rafta Hazır Ticari Ürün

Commercially off the Shelf Item
|Raf Ürünü
|-
|TÇD

RFP
|Teklife Çağrı Dosyası

Request for Proposal
|
|-
|D&TE

S&TE
|Destek ve Test Ekipmanı

Support and Test Equipment
|
|}

== 1.8. TABLOLAR VE ŞEKİLLER ==

=== 1.8.1. TABLOLAR ===
Tablo 1 Değişiklik İzleme Tablosu

Tablo 2 Tanımlar Tablosu

Tablo 3 Kısaltmalar Tablosu.

Tablo 4 Örnek Soru Seti

Tablo 5 Kalem Türüne Bağlı Olarak İdame Edilebilirlik Analiz Derinliği

Tablo 6 OSA’nın Farklı Derinliklerinin Sınıflandırılması

Tablo 7 Yorumlama sürecinin zaman takvimi ile açıklanması

Tablo 8 Durum kodu örnekleri

Tablo 9 LDA Tarafından Belirlenen Farklı Yedek Parça Türleri Listesi

Tablo 10 Analiz Faaliyetleri Seçim Kriterleri

Tablo 11 Analiz Faaliyetleri Öneri Matrisi

Tablo 12 Ömür devri safhalarındaki aktivitelerin özeti

Tablo 13 Olayların Sebep Tiplerine ilişkin Örnekler

Tablo 14 Olayların meydana gelme olasılıkları

Tablo 15 Teknoloji Seviyeleri

Tablo 16 Teknoloji hassasiyetinin değerlendirilmesi

Tablo 17 Teknoloji-Hassasiyet Değerlendirmesi

Tablo 18 Onarım Seviyesi Analizi Süreç Adımları

Tablo 19 Bakım Seviyeleri ve Tanımlı Görevlere İlişkin Örnekler

Tablo 20 Görev Gereksinimleri Örneği

Tablo 21 Görev kaynaklarına örnekler

Tablo 22 Montaj Prosedürü için Gerekli Görev Kaynakları Örneği

Tablo 23 Elektronik Komple için montaj prosedürü-görev kaynakları özeti

Tablo 24 Farklı Proje Safhalarında Yazılım Destek Analizi

Tablo 25 Uyumluluk Matrisi

=== 1.8.2. ŞEKİLLER ===
Şekil 1 Entegre Lojistik Destek İşlevsel Elemanları (S3000L’den uyarlanmıştır)

Şekil 2 Tedarik Maliyetlerine Karşı Kullanım ve Destek Maliyetleri

Şekil 3 ÖDM ve LDA Arasındaki Etkileşim

Şekil 4 Temel LDA Süreci

Şekil 5 LDA adayı belirlenmesinde kullanılabilecek örnek akış diyagramı (Yapısal Olmayan Malzeme için) (S3000L)

Şekil 6 LDA adayı belirlenmesinde kullanılabilecek örnek akış diyagramı (Yapısal Malzeme için)

Şekil 7 Müşteri ile yüklenici arasındaki veri alışverişi süreci (örnek)

Şekil 8 Kullanıma Hazır Olma Kırılımı

Şekil 9 Ergonomi/Simülasyon Yazılımlarından Örnek Görüntü

Şekil 10 Kullanım safhası LDA süreci

Şekil 11 Kullanım ve destek safhası* bakım gözden geçirme akışı

Şekil 12 Modifikasyon ve değişiklik uygulaması için kullanım safhası LDA – 1

Şekil 13 Kullanım dönemi malzeme yönetimi

Şekil 14 Lojistik Destek Analizleri ile Teknik Dokümantasyon Arasındaki İlişki

Şekil 15 Lojistik Destek Analizleri ile Malzeme Desteği Arasındaki İlişki

Şekil 16 LDA ve Test Ekipmanı Arasındaki İlişki

Şekil 17 LDA ve Eğitim Arasındaki İlişki

Şekil 18 Ömür devri safhalarına göre analiz akış süreci

Şekil 19 GMB – BGA Arayüzü

Şekil 20 Bakım Görevlerinin Belirlenmesi

Şekil 21 Görev Yapılarının Oluşturulması

= 2. LOJİSTİK DESTEK ANALİZLERİNE GİRİŞ =

== 2.1. LOJİSTİK DESTEK ANALİZLERİ NEDİR? ==
Savunma ve güvenlik sistemlerinin (ürünün) temel görevi, savunma ve güvenlik ihtiyacını belirlenen kullanım konsepti ve görev profilleri çerçevesinde istenilen performans seviyesinde karşılamaktır. Ürünün kendisine tanımlanan fonksiyonları “kesintiye uğramaksızın” yerine getirebilmesi; destek unsurlarının sağlanması ve ilgili prosedürlerin yürütülmesi ile mümkündür.

Bu kapsamda; harekât ihtiyaçlarının zamanında ve verimli şekilde karşılanması ve sahip olunan kaynakların maliyet etkin kullanımı esastır. Lojistik Destek faaliyetleri söz konusu ürünün istenilen performans seviyesinde faaliyet gösterebilmesi için ihtiyaç duyulan kaynakların sağlanması ve idamesi ile ilgili idari ve teknik süreçleri kapsar.

Lojistik Destek Analizi (LDA); lojistik destek faaliyetlerinin maliyet etkin olarak yürütülmesinde yol gösterici en önemli faaliyettir. Tüm lojistik destek faaliyetlerinin teknik disiplin içinde maliyet etkin olarak planlanması, koordine edilmesi ve yönetilmesi için LDA rehberliğinde;

* Ürün ve destek unsurları güvenilirlik, kullanıma hazır olma, idame edilebilirlik, desteklenebilirlik, test edilebilirlik ve uygun Ömür Devri Maliyeti (ÖDM) ile tasarlanır,
* Kullanım ve Destek Safhaları boyunca ürünün istenilen performans seviyesinde kullanılabilmesi için ihtiyaç duyulan kaynaklar tanımlanır,
* ELD elemanlarına ilişkin esas bilgiler oluşturulur.

Lojistik Destek Analizleri; sistem ömür devri boyunca desteklenebilirlikle ilişkili olası darboğazların öngörülmesi, bahse konu darboğazların giderilmesine yönelik önleyici planların oluşturulması ve oluşturulan planların iyileştirilmesi, geliştirilmesi ve uygulamaya aktarılması amacıyla yinelemeli olarak yürütülür.

== 2.2. TARİHÇESİ VE GELİŞİMİ ==
Lojistik Destek Analizlerinin gelişimi, sayısal bilgi işlem platformları ve kompleks sistemlerin yaygınlaştığı, teknoloji yönetiminin teknoloji savaşlarına dönüştüğü 1970’li yıllardan itibaren yaklaşık 50 yıllık bir dönem içinde gerçekleşmiştir.

ELD uygulamalarının 1965 yılında Amerika’da ortaya çıkması ile birlikte, bir sistemin desteğinin de en az performans karakteristikleri kadar önemli olduğu kabul edilmiştir.

İhtiyaç Makamlarının ELD’nin uygulanmasındaki temel hedefleri; lojistik destek konularının sistemin tasarımına etki etmesini sağlamak, ürünün kullanıma/göreve hazır olma hedeflerine ilişkin ve bu hedeflere ulaşılmasını sağlayan destek gereksinimlerini belirlemek ve geliştirmek, gerekli desteği minimum maliyetle temin etmek ve ürün envantere alındıktan sonra lojistik desteğini sağlamaktır.

1980’lerin başında, LDA’ya yönelik bir süreç geliştirilerek MIL-STD-13881A yayımlanmıştır. Bu süreç en iyi ticari uygulamaları esas alarak geliştirilirken, desteklenebilir bir tasarım elde etme hedefine yönelik bütün faaliyetleri sistem mühendisliği süreçlerine entegre edecek bir metodoloji tanımlamış ve aynı zamanda fiziksel destek çözümünün geliştirilmesine yönelik basit fakat etkin yöntemler sunmuştur. Başlangıçta ABD Silahlı Kuvvetlerinin ana sistem tedarik mevzuatlarında yer verilen LDA prensipleri, halen kullanılmakta olan diğer standartların da yürürlüğe girmesiyle birlikte tedarik ve sistem mühendisliği bilimlerindeki merkez olma rolünü üstlenmiştir.

Etkin uygulamalarının görülmeye başlanması ile birlikte, Birleşik Krallık Savunma Bakanlığı tarafından da LDA süreci “Defence Standard 00-60”a entegre edilerek yayımlanmıştır. Diğer birçok ülkenin de süreci kendi sistemlerine adapte ederek kullanmaya başlamasıyla, desteklenebilirlik gereksinimlerinin sistem tasarımına dahil edilmesi sürecinde LDA evrensel bir araç haline gelmiştir.

Günümüzde ülkelerin, resmi ve özel kurumların genel prensipleri örtüşmekle birlikte uygulamada küçük farklılıklar içeren standart ve rehber dokümanları ile uygulama desteği sağlayan birçok ticari yazılım ve girişim sayesinde yeterli çeşitlilik ve derinlik oluşmuş bulunmaktadır.

== 2.3. ENTEGRE LOJİSTİK DESTEK SÜRECİ İÇİNDE LOJİSTİK DESTEK ANALİZLERİNİN YERİ VE ÖNEMİ ==
Bir ürünün ömür devri boyunca desteklenebilmesi için kullanılacak teknik bilgi ve destek çözümünü geliştirmeye dair sorumluluk ELD sürecinin kapsamındadır. ELD elemanları aşağıda belirtildiği gibidir:

* Bakım
* İkmal Desteği
* İşgücü ve Personel
* Destek ve Test Ekipmanları
* Tasarıma Etki/Tasarım Etkileşimi
* Teknik Veri ve Dokümantasyon
* Eğitim ve Eğitim Desteği
* Tesisler ve Altyapı
* Paketleme, Elleçleme, Depolama, Ulaştırma (PEDU)
* Bilgisayar Kaynakları
* İdame Mühendisliği
* Ürün Destek Yönetimi

LDA, bir ELD elemanı değildir ancak ELD’nin ayrılmaz ve temel bir parçasıdır ([https://tssodypwiki.ssb.gov.tr/index.php/Entegre_Lojistik_Destek_(ELD)_Rehberi Bkz. TSSÖDYP-04 Entegre Lojistik Destek Rehberi]).

LDA programı, ELD planlama ve kaynakların belirlenmesi için kullanılacak teknik verilerin temel kaynağını oluşturur. Lojistik Destek Analizleri ile destek elemanı gereksinimleri tanımlanarak tasarıma etki arayüzü sağlanmış olur. Ayrıca, analiz faaliyetleri ile maliyet etkin bakım çözümü, bakım seviyeleri, bakım görevleri, bakım için gerekli destek kaynakları ile yedek parça planlaması gibi hususlar belirlenerek ELD elemanlarına girdi sağlanır. Lojistik destek analizlerinin sonuçları ve destek kaynak verileri, LDA veritabanında kayıt altına alınarak bütün program elemanlarına, tasarım alternatiflerinin desteklenebilirliğini ve hedeflerini değerlendirmede kullanılacak ortak bir veri kaynağına erişimi sağlar.

ELD elemanlarının herbirinin kendi alanlarında kaynak kullanımına ilişkin verileri toplama, analiz etme ve saklama gibi işlemleri ayrı ayrı yürütmeleri, üretilen bilgiler arasında tutarsızlığa veya devamsızlığa sebep olur. LDA süreci ile birlikte tek bir veri tabanının kullanılması her bir ELD elemanının, diğerleri ile aynı bilgiyi kullanması ve bir elemanın ürettiği verilerin diğerlerinin kullanımına da sunulmasını sağlar.
[[Dosya:Şekil1 ELD Elemanları ile LDA Arasındaki İlişki.jpg|alt=|sol|küçükresim|600x600pik|Şekil 1 ELD Elemanları ile LDA Arasındaki İlişki]]

== 2.4. LDA VE ÖMÜR DEVRİ MALİYETLERİ ==
Sistemin ömür devri boyunca gerçekleşen toplam maliyetlerini tanımlamak için farklı terimler kullanılır. Bunlardan ÖDM sistemin geliştirme, üretim (veya satın alma), kullanım, destek ve elden çıkarılmasına ilişkin bütün doğrudan ve dolaylı maliyetleri kapsar.

Ürünün kullanım ve destek maliyeti genellikle tedarik maliyetinin çok üzerindedir. Bu nedenle belirli bir ürünün tedarik edilmesine ilişkin karar verme süreci sadece ürünün tedarik maliyeti değil, ömür devri boyunca beklenen kullanım ve destek maliyetleri ile envanterden çıkarma maliyetlerinden de etkilenmelidir. Tedarik maliyeti ile kullanım ve destek maliyetlerinin bütünü nisbi büyüklükleri figüratif olarak vurgulanmak üzere Şekil 2’de gösterilmektedir.
[[Dosya:Şekil 2 Tedarik Maliyetlerine Karşı Kullanım ve Destek Maliyetleri .jpg|sol|küçükresim|500x500pik|Şekil 2 Tedarik Maliyetlerine Karşı Kullanım ve Destek Maliyetleri ]]

ÖDM analizleri, alternatif sistem çözümlerini mukayese etmek için kullanılan teknik bir süreçtir. Bu analizlerin temel amacı, alternatifler arasındaki farkları vurgulamaktır. Bir geliştirme programında ÖDM analizleri, tasarım çözümü daha kesin olarak bilinmeden gerçekleştirilir ve değerlendirilir.

ÖDM analiz faaliyetleri, programın erken safhalarında, LDA faaliyetlerinden önce başlatılır. Dolayısıyla, ÖDM sonuçları, erken dönem LDA faaliyetleri kapsamında hazırlıklar yapılırken mevcut durumdadır. Bu sonuçlar, LDA program planının ve çerçevesinin oluşturulması için bir kriter teşkil edebileceği gibi, LDA aday kalemlerinin seçilmesi ve her bir aday için gerçekleştirilecek analizlerin belirlenmesini de destekler.

ÖDM analizleri tasarıma etki, ürün konfigürasyonunda yer alacak kalemlerin belirlenmesi ve Onarım Seviyesi Analizi (OSA) gibi faaliyetler esnasında karar verme kriteri olarak ve LDA gereksinimlerinin gerçekleştirilmesinin maliyet etkisini tahmin etmek için de kullanılabilir. Dolayısıyla ÖDM analiz sonuçlarının, LDA sürecinde aşağıda yer alan konulara ilişkin bir karar kriteri olarak kullanılması mümkündür:

* LDA aday kalemlerinin belirlenmesi
* Her bir aday kalem için gerçekleştirilecek analizlerin belirlenmesi
* Tasarım üzerinde etki
* Konfigürasyon Birimlerinin/Kalemlerinin Değerlendirilmesi
* Onarım Seviyesi Analizi (OSA)

LDA süreci kapsamında Hata Türleri ve Etkileri Analizi (HTEA), Bakım görev Analizi (BGA) gibi farklı analiz faaliyetleri sonucunda birçok veri üretilir. Süreç boyunca kayıt altına alınan gereksinimler ve üretilen veriler daha sonra ÖDM modelini güncellemek için de girdi oluştururlar. Dolayısıyla, LDA veri tabanı ile ÖDM analizleri arasında tutarlılığı sağlamak son derece önemlidir. ÖDM ve LDA arasındaki etkileşim Şekil 3’te gösterilmiştir.
[[Dosya:Şekil3 ÖDM ve LDA Arasındaki Etkileşim.jpg|alt=|sol|küçükresim|760x760pik|Şekil 3 ÖDM ve LDA Arasındaki Etkileşim]]

== 2.5. LDA SÜRECİNİN ÇIKTILARI VE PROJELERDE LDA FAALİYETLERİNİN ETKİSİ ==
Bir tedarik programını etkileyen dört temel faktör; maliyet, takvim, performans ve desteklenebilirliktir. LDA süreci, bir sistem/ekipman ile ilişkili olarak desteklenebilirlik ve maliyet faktörlerine doğrudan girdi sağlayarak tedarik ile ilişkili karar verme sürecine önemli katkıda bulunur.

Programlar arasında farklılık göstermekle birlikte LDA sürecinin çıktısı olarak sistem seviyesinde tedarik kararlarını etkileyen temel hususlar şunlardır:

* Maliyet: Bütün savunma tedarik programları yüksek kalite ve kabiliyete sahip, bütçelenebilir sistemler temin etmeyi hedefler. Bir ürünün bütçeye uygunluğunun değerlendirilebilmesi için destek yatırımları ve kullanım ve destek maliyetlerinin de diğer tedarik maliyet kalemleri ile birlikte dikkate alınması gerekir. Ömür devri maliyet tahminleri, farklı sistem alternatifleri için yatırım maliyetleri ile tekrarlanan maliyetleri karşılaştırır. Kullanılan maliyet analizi yöntemi, sistem seviyesi güvenilirlik, idame edilebilirlik vb. karakteristikleri, kullanım oranları ve operasyon senaryoları varsayımlarına dayanan belli göreve hazır olma seviyelerine ulaşmak için gerekli olan destek kaynaklarını dikkate almalıdır.
* Bütçelenebilirlik: ÖDM’ye dair bütün ana kalemler dikkate alınmalıdır. Bu çalışmalarda temel hedef, kullanıma hazır olma gibi ana kısıtları dikkate alarak maliyetleri en aza indirgemektir. Ürünün tedarik programı sonrasında, kullanım ömrü boyunca sürdürülecek değerlendirmeler ömür devrinin etkin olarak yönetimine önemli katkı sağlar. Bu değerlendirmeler, sadece maliyetlerin zaman içinde değişmesi nedeniyle değil aynı zamanda “bütçeye uygunluk” değerlendirmesinin de değişen ekonomik koşullara bağlı olarak değişime tabi olması nedeniyle gerekli olacaktır. Yıllara sari olarak sistemin kullanım ve desteği için karşılaşılacak mali boyut bütçelenebilir olmalıdır. Dolayısıyla, sistemin ömür devri boyunca sahip olma maliyetini azaltacak fırsatları araştırmak önemlidir.
* İş gücü ve personel kısıtları: Yeni sistem/ekipmanlar ile birlikte ortaya çıkacak iş gücü ve personel beceri ihtiyaçları, performans, ağırlık vb. diğer tasarım parametreleri ile birlikte yeni sistem/ekipman konseptinin ilk ortaya çıkışıyla birlikte erken safhalarda yönetilmelidir.
* Göreve Hazır Olma: Ürün desteği ile ilgili tasarım parametreleri (örn. güvenilirlik, idame edilebilirlik), ürün destek kaynakları (yedek parça, iş gücü vb.) ve ikmal sistemi parametreleri sistemin kullanıma hazır olma hedefleri ile ilişkilendirilmelidir. Bu tür hedefler, sistemden sisteme, barış zamanı ve savaş zamanı durumlarına göre değişkenlik gösterir. Sistemin göreve hazır olması, sistemin kullanım profilleri içinde yer alan görevler için gerekli olan tüm unsurların hazır bulunması demektir ve sistemin/ekipmanın en erken safhalarından itibaren yönetilmesidir.

== 2.6. LDA STANDARTLARI/SPESİFİKASYONLARI ==

* MIL-STD-1388-1A (iptal): LDA konusunda en bilinen ve yaygın olarak kullanılan standart “MIL-STD-1388-1A Logistic Support Analysis” isimli standarttır. Amerikan Savunma Bakanlığı tarafından ilk olarak 1983 tarihinde yayımlanan bu standart, mantıksal ve yinelemeli bir kurgu ile gerçekleştirildiğinde LDA sürecini oluşturan genel gereksinimler ve görev tanımlarından oluşmaktadır. MIL-STD 1388-1A, 1997 yılında iptal edilmiş olup yerini “MIL-HDBK-502 Tedarik Lojistiği” dokümanı almıştır.
* MIL-STD-1388-2B (iptal): 1388-1A’ya göre gerçekleştirilecek analizlere dair veri tanımlarının ilişkisel tablo yapısına dayandırıldığı veri tabanı standardıdır. 1996 yılında iptal edilmiştir.
* MIL-HDBK-502A: Amerikan Savunma Bakanlığı tarafından 1997 tarihinde “Tedarik Lojistiği” ismi ile yayımlanan bu el kitabının “A revizyonu” 2013 yılında “Ürün Destek Analizleri” ismi ile tekrar yayımlanmıştır (Amerika’da önceki yıllarda lojistik destek analizleri olarak adlandırılan analizler günümüzde ürün destek analizleri olarak isimlendirilmektedir). Halen yürürlükte olan bu doküman, sistem ve ekipmanların ömür devri boyunca ürün destek analizlerinin gerçekleştirilmesine yönelik bir çerçeve tanımlamaktadır. Bütün olarak ürün destek analizleri sürecini ve ilişkili faaliyetleri, Savunma Bakanlığı desteklenebilirlik hedeflerini karşılayabilmek için söz konusu faaliyetlerin seçim ve uyarlama yöntemlerini ve LDA teslimatlarına yönelik olarak sözleşmelerde yer alabilecek örnek ifadeleri içermektedir.
* MIL-PRF 49506 (iptal): Lojistik Yönetim Bilgisi isimli bu spesifikasyon tedarik lojistiği yönetim işlevine, yüklenicilerden destek ve destek ilişkili mühendislik ve lojistik bilgilerinin temin edilmesine yönelik olarak 1996 yılında yayımlanmış ancak 2005 yılında iptal edilmiştir.
* UK-DEF-STAN-00-60 Part 1 (iptal): İngiltere Savunma Bakanlığı tarafından 1994 yılında yayımlanan UK-DEF-STAN-00-60 Part 1 “Logistic Support Analysis (LSA) and Logistic Support Analysis Record (LSAR)” ise MIL-STD-1388’in bir varyantı olarak nitelendirilebilir. 2010 yılında iptal edilmiştir. Günümüzde UK-DEF-STAN-00-600 kullanılmaktadır.
* GEIA 0007: “Lojistik Ürün Bilgisi” olarak isimlendirilen bu standartta veri tanımları 1388-2B gibi tablo yapısına dayalı olmakla birlikte, veri değişimi XML teknolojisi üzerine inşa edilmiştir. MIL-STD-1388-2B’nin yerini almıştır.
* S3000L: Hazırlık çalışmalarına Aerospace and Defence Industries Association of Europe (ASD) tarafından 2005 yılında başlanılan S3000L’nin 1.0 versiyonu ASD ve Aerospace Industry Association of America (AIA) arasında Haziran 2010 tarihinde imzalanan mutabakat zaptı ile birlikte yayımlanmış, Temmuz 2014 tarihinde 1.1 versiyonu ile güncellenmiştir. S3000L genel olarak MIL-STD-1388-1A, MIL-HDBK-502, DEF-STAN-00-60 ve ISO 10303-239 PLCS içerisinde tanımlanan aktivite modeline dayandırılmıştır.
[[Dosya:LDA Doküman Gelişimi.png|alt=LDA Doküman Gelişimi|sol|küçükresim|800x800pik|LDA Doküman Gelişimi]]

= 3. DESTEKLENEBİLİRLİK VE DESTEKLENEBİLİRLİK İLİŞKİLİ TASARIM FAKTÖRLERİ =

== 3.1. DESTEKLENEBİLİRLİK NEDİR? ==
Desteklenebilirlik, sistem tasarım özelliklerinin ve planlanan lojistik kaynakların sistemden beklenen operasyon ve göreve hazır olma gereklerini sistemin ömür devri boyunca uygun maliyette karşılayabilme derecesidir (yeteneğidir). Desteklenebilirlik sistem tasarımının ayrılmaz bir parçası olup ömür devrinin erken safhalarında değerlendirilmelidir.

Desteklenebilirliğin ömür devrinin erken safhalarında, sistem geliştirme safhasında dikkate alınması sistemi desteklemek için gereken kaynak miktarının azaltılmasında, sistemin gayri-faal kalma süresinin kısalmasında etkilidir. Bu da ÖDM’nin azaltılmasında ve sistemin faal tutulmasında önemli bir rol oynar. Desteklenebilirliğin ömür devrinin erken safhalarında değerlendirilmemesi tedarik ve destek maliyetlerinde artışa, teslimat sürelerinde uzamaya, gayrı faal kalma süresinde artışa ve kalite ile ilişkili problemlere yol açabilir ve bu da ÖDM’de ciddi artışlara neden olabilir.

== 3.2. DESTEKLENEBİLİRLİK HEDEFLERİ ==
Desteklenebilirlik hedefleri, sistemden beklenen görev ve performans ölçütleri ile yakından ilişkilidir. Temel hedef sistemin kullanıma/göreve hazır olması ve kendisine verilen görevi başarı ile tamamlayabilmesidir. Göreve hazır olma sistemin teknik özellikleri, destek altyapısı (ekipman, malzeme, iş gücü ve eğitimli personel vb.), destek idari yapısı, organizasyonu ve destek süreçleri ile ilişkilidir ve sistemin operasyonel uygunluğunun bir göstergesidir.

Bir diğer desteklenebilirlik hedefi ise sistemin maliyet etkin bir şekilde desteklenmesidir. Sistemin kendinden beklenen performans ve göreve hazır olma kriterlerini karşılayabilmesi için gerekli olan tasarım özelliklerinin, destek kaynaklarının ve destek altyapısının belirlenmesinde maliyet etkin bir yaklaşım izlenilmesini hedefler.

Desteklenebilirlik, destek sisteminin destek ihtiyaçlarına mümkün olan en kısa sürede yanıt verebilmesini hedefler. Destek sisteminin etkin olmasında destek idari yapısı ve organizasyonu, destek altyapısı (test, destek ve kalibrasyon ekipmanları, destek ve yedek malzemeleri, eğitimli personel ve iş gücü vb.), destek kaynaklarının boyut, ağırlık, paketleme, taşınma vb. özellikleri ve destek süreçleri gibi faktörler önemli rol oynar.

== 3.3. DESTEKLENEBİLİRLİK İLİŞKİLİ ÜRÜN PERFORMANS PARAMETRELERİ ==
Ürün desteklenebilirliği, sistemlerin, alt sistemlerin ve bileşenlerin kullanıma hazır olma ve operasyonel kabiliyetlerinin idamesi için gerekli destek bileşenlerinin oluşturulmasıdır. Bu kapsamda yapılan analizlerin temel amacı desteklenebilirlik parametrelerinin sistem tasarımlarına dahil edilmesinin sağlanmasıdır.

Desteklenebilirlik maliyet, takvim ve performans ile birlikte sistem tedarik kararlarını etkileyen ana faktörlerden biridir. Yüksek kalitede maliyet etkin çözümler üretilerek kullanıcı/tedarik makamı ihtiyaçları karşılanmalıdır. Erken safhalarda iyileştirme noktalarının belirlenebilmesi ve desteklenebilirlik bakış açısıyla tasarımlara etki edilebilmesi için LDA, konsept/geliştirme safhasının en başından itibaren projelerin ayrılmaz bir parçası olmalıdır. Bu anlamda, sistem/ekipman geliştirme süreçlerine etki eden desteklenebilirlik parametreleri; amaçlar, eşik değerler, nitel ve nicel kısıtlar ve sistem/ekipman geliştirme gerekleri olarak sınıflandırılabilir.

Desteklenebilirlik karakteristikleri projeler arasında farklı tanımlanabilmekle birlikte en yaygın olarak kullanılan performans parametreleri şunlardır:

* Arızalar Arası Ortalama Süre,
* Ortalama Onarım Süresi,
* Onarım Çevrim Süresi,
* Kullanıma Hazır Olma,
* ÖDM.

Aşağıdaki belirtilen unsurlarla desteklenebilirlik sürecine girdi olacak şekilde ara yüzler sağlanmalıdır:

* Güvenilirlik,
* İdame edilebilirlik,
* Kullanıma hazır olma,
* Desteklenebilirlik
* Test edilebilirlik,
* İnsan faktörleri mühendisliği,
* Entegre lojistik destek elemanları,
* Konfigürasyon yönetimi,
* Envanterden çıkarma yönetimi,
* ÖDM.

= 4. LDA GENEL GEREKSİNİMLERİ =

== 4.1. LOJİSTİK DESTEK ANALİZ PROGRAMI ==
Sistem/ekipman tasarım ve geliştirme programlarında bir LDA Programı oluşturulması ve uygulanması faaliyetlerin sistematik ve zamanında gerçekleştirilmesi kapsamında önemlidir. LDA programı, aşağıdaki temel elemanlardan oluşur:

* Tasarımı desteklenebilirliği sağlayacak şekilde etkilemek ve uygun lojistik kaynaklarını tespit edebilmek için gerçekleştirilmesi gereken LDA faaliyetlerini belirleyen bir LDA planı
* LDA gereksinimlerinin zamanlamasını ortaya koyan bir takvim/planlama (LDA takvimi proje faz ihtiyaçlarına dayandırılmalı ve diğer proje gereksinimleri ile birbirini tamamlayıcı ve destekleyici şekilde ortaya konmalıdır)
* LDA faaliyetlerine ilişkin sorumlulukların tanımlanarak ilgili personele atanması
* Tasarım, güvenilirlik, emniyet ve ELD elemanları (disiplinleri) ile gerekli arayüzlerin kurulması ile girdi-çıktıların sağlanması

=== 4.1.1. LDA STRATEJİSİ ===
Tedarik programının erken safhalarında genel bir LDA stratejisi geliştirilmelidir.

LDA stratejisinin belirlenmesi, bir LDA programı kapsamında gerçekleştirilmesi gereken ilk planlama faaliyeti olup maliyet açısından en etkin programı geliştirmede kritik öneme sahiptir. Bu faaliyet genel olarak LDA faaliyetlerini içeren herhangi bir talep dokümanı oluşturulmadan gerçekleştirilmelidir. LDA gereksinimlerini nihai hale getirmeden önce olası tasarım ve operasyonel yaklaşımların, desteklenebilirlik karakteristiklerinin ve mevcut verilerin analiz edilmesi, LDA programının tasarım üzerinde desteklenebilirlik etkisini azami ölçüde sunan temel alanlara odaklanmasını sağlar.

LDA stratejisi sistem/ekipman için önerilen desteklenebilirlik hedeflerinin kapsamını ve gerçekleştirilmesi istenen niceliksel analizleri, tedarik programı açısından en iyi maliyet faydasını sağlayacak şekilde belirlemelidir.

TÇD oluşturulurken tanımlanacak ön LDA stratejisi yüklenici tarafından yapılması “zorunlu/tavsiye edilen/isteğe bağlı” LDA faaliyetlerinin teklif aşamasında belirlenmesine ışık tutmalıdır. Yüklenicinin etkin bir LDA programı oluşturması ve yürütmesinde kullanılan LDA stratejisi, yüklenici seçim sürecinde etkili olmalıdır.

LDA stratejisi oluşturmanın ilk adımı hem müşteri hem de yüklenici tarafında herhangi bir çalışmaya başlamadan önce LDA’ya ilişkin ne yapılması gerektiğine dair bilinçli bir karar verme sürecinin yürütülmesini sağlamaktır.

LDA gereksinimleri, ürünü oluşturan sistemler, alt sistemler ve bileşenler için niceliksel, niteliksel ve test ile ilişkili LDA gereksinimlerinin sağlanmasını içerecek şekilde kapsamlı bir LDA programı oluşturmak amacıyla analiz edilir. Bu çalışmanın sonunda ortaya çıkan LDA programı LDA gereksinimlerini karşılayan uyarlanmış ve maliyet etkin bir program olmalıdır.

LDA programının yönetimi için LDA stratejisinin oluşturulmasına başlanması ön konsept safhasında ihtiyaç makamı/kullanıcı tarafından gerçekleştirilmesi gereken bir faaliyettir ve bu strateji TÇD yayımlanmadan önce ihtiyaç makamı/kullanıcı ve tedarik makamı tarafından netleştirilmelidir. Yüklenici adayları LDA stratejisine yönelik çalışmalarını konsept safhasında yaparlar. Yüklenici, geliştirme ve üretim safhalarında LDA stratejisinin geliştirilmesi ve güncellenmesi sorumluluğunu üstlenir. Yüklenicinin bu sorumluluğu kullanım ve destek safhalarında da garanti dönemi ve sonrasına ilişkin düzenlemelere bağlı olarak devam eder. Ancak LDA stratejisi konusundaki genel sorumluluk sistemin ömür devri boyunca müşteri’dedir.

Strateji geliştirilirken verilmesi gereken önemli kararlardan biri hangi LDA görevlerinin/ faaliyetlerinin kim tarafından gerçekleştirileceğidir. İstenen LDA faaliyetlerinin gerçekleştirilmesinin yaklaşık olarak maliyeti, gerekli olduğunda kaynakların/bütçenin sağlanabilmesi amacıyla kamu tarafından hesaplanmalı/öngörülmelidir.

LDA Stratejisi geliştirme faaliyeti tek başına spesifik bir doküman üretilmesine yol açmaz. Bu faaliyetin sonuçları ELD Planı’nda (ELDP) yer alır.

Program ilerledikçe, takvim değişikliği, tasarım değişikliği, bütçe/maliyet değişikliği gibi önemli değişiklikler olduğunda, LDA stratejisi de güncellenmelidir.

=== 4.1.2. LDA AKTİVİTELERİ VE TEMEL LDA SÜRECİ ===
LDA süreci ile tasarıma etki faaliyetleri Şekil 4’de gösterilmektedir. Zamansal olarak akış projeye özgü olarak farklılık gösterebilir.
[[Dosya:Şekil6.4.jpg|alt=Şekil 4 Temel LDA Süreci|sol|küçükresim|632x632pik|Şekil 4 Temel LDA Süreci]]

Müşteri gereksinimleri ve operasyonel konsept benzer sistemler ve/veya tasarım ve geliştirme faaliyeti yapılmış olan sistem/alt sisteme ait veriler kullanılarak yapılan karşılaştırmalı analiz sonuçları da tasarım ve geliştirme faaliyetlerinin girdisi olacaktır. Bu bilgiler ile bu bilgilere dayalı olarak yapılan varsayımlar kullanılarak taslak olarak aday kalem listesi hazırlanır. Tasarım ve geliştirme faaliyetleri kapsamında emniyet analizi, güvenilirlik analizi ve HTEKA çalışmaları yapılır ve sonuçlara göre tasarıma girdi sağlanır. Bu çalışmaların çıktıları da insan faktörleri analizi, hata ağacı analizi, yazılım destek analizi, özel olay ve hasar analizi, önleyici bakım analizi, test edilebilirlik analizi için kullanılır. Bu analizler sonunda aday kalem listesi nihai hale gelir. Bu liste üzerinden OSA ve BGA yapılır. Kullanım ve destek dönemi LDA faaliyetleri ihtiyaç olması durumuda (güncellemelerin/modifikasyonların olması durumunda, kullanım verilerine göre vb) gerekli görülen analizler tekrar yapılacak ve ELD elemanları üzerine etkisi tekrar değerlendirilecektir. Bu süreç kapsamında konfigürasyon yönetim faaliyetleri yürütülerek tüm bilgi/verilerin kayıt altına alınması, izlenebilirliğin kurulması sağlanacaktır.

=== 4.1.3. PROGRAM YÖNETİM İLKELERİ, ROLLER VE SORUMLULUKLAR ===
Lojistik destek analizleri kapsamında organizasyonlar içerisinde tanımlanmış ekipler, aşağıda sıralanan faaliyetlerden sorumlu olacaktır:

* Güvenilirlik, idame edilebilirlik, kullanıma hazır olma, desteklenebilirlik, test edilebilirlik, insan mühendisliği ve çevresel uygunluk gibi konularda girdi sağlayarak sistem ve destek sistemi tasarımına desteklenebilirlik karakteristiklerinin katılmasının sağlanması ve ilgili gereksinimlerin tanımlanması,
* Destek sistemini ve gerek duyulduğu takdirde eğitim sistemini geliştirmek ve lojistik destek kaynaklarının (ikmal destek, destek ekipmanı, teknik veri, tesisler, PEDU, iş gücü ve personel, eğitim ve eğitim desteği) planlaması, geliştirilmesi ve sunulması,
* Sistem mühendisliği ve tasarım mühendisliği faaliyetleri ile desteklenebilirlik mühendisliği faaliyetleri arayüzünün kurulması,
* Standardizasyonun, birbirinin yerine kullanılabilirliğin, birlikte çalışabilirliğin ve demodelik yönetiminin sağlanması.

Desteklenebilirlik sorumlusu/lideri ile ELD yöneticisi ve diğer işlevsel yönetim sorumluları arasındaki koordinasyonun ve ara yüzlerin oluşturulması ve sürdürülmesi LDA programının başarısı açısından büyük önem taşır. Ayrıca, etkin bir ELD/LDA program yönetimi açısından hem müşteri hem de yüklenici bünyesinde bir ELD/LDA organizasyonu oluşturulması gereklidir.

=== 4.1.4. LOJİSTİK DESTEK ANALİZİ PLANI (LDAP) ===
LDAP, proje süresince yürütülecek LDA faaliyetlerinin kimler tarafından, nasıl ve hangi esaslara dayanılarak yürütüleceğinin yer aldığı ve özellikle analizlerin icrasında rol alacak kişilerin sık sık başvuracağı bir el kitabı niteliğindedir. Bu plan, bir bakıma proje kapsamında hangi analizlerin yapılacağı ve nasıl yapılacağına dair bir yol haritası çizer. Aynı zamanda, programın farklı safhalarında ilerlemeyi ölçmek için de bir temel sunar.

LDAP, proje fazlarına göre uygun kapsam ve derinlikte aşağıdakilerle sınırlı olmamak kaydıyla gerekli bilgileri içermelidir:

* İlgili proje dokümanlarında tanımlanan sistemin lojistik gereksinimlerinin karşılanması için nasıl bir LDA programı yürütüleceği tanımlanmalıdır,
* LDA organizasyonu tanıtılır. Yöneticiler, analiz ekipleri, tasarım ekipleri, altyükleniciler, arayüzü sağlayacak sorumlular ile müşteri tarafındaki sorumlular belirtilir.
* Sistem ve alt sistemlerin tanımı yapılır, alt sistemlerin arayüz bilgileri belirtilir, görev profilleri tanımlanır.
* Sistemin karşı karşıya kalacağı çevresel koşullar, stres etkenleri (mekanik, termal, elektriksel, kimyasal, elektro-kimyasal, radyasyon) ve yüklemeler/zorlamalar belirlenir.
* Lojistik destek analizlerinin çerçevesini oluşturacak olan temel kural ve varsayımlar tanımlanır.
* Her bir LDA faaliyeti için referans alınacak standartlar, kullanılacak matematiksel modeller ve formüller tanımlanır, bu faaliyetlerin nasıl raporlanacağı belirtilir.
* Lojistik destek analizlerinin uygulama adımları kısaca anlatılarak çalışma ekipleri, tasarım ekipleri, alt yükleniciler ve müşterinin ilgili adımlardaki rolleri tanımlanır.
* LDA için aday kalemlerin seçim kriterleri belirtilir. Aday kalem listesi ve aday kalem listesinde yer alan sistem elemanlarına hangi analizlerin uygulanacağı listelenir (liste, analiz için önerilen ve önerilmeyen bütün bileşenleri ve seçilme/seçilmeme gerekçelerini içermelidir).

* LDA’ya tabi olacak bileşenlerin seçilmesinde kullanılacak kırılım yapısının (yazılım kalemleri dahil) belirlenir.
* Kullanılacak kırılım elemanlarının numaralandırma sistemi tanımlanır.
* Desteklenebilirlik ve desteklenebilirlik ilişkili tasarım gereksinimlerinin tasarımcılara ve ilgili personele hangi yöntemlerle aktarılacağı belirtilir.
* Desteklenebilirlik ve desteklenebilirlik ilişkili tasarım gereksinimlerinin altyüklenicilere kırılma yöntemleri ve uygulanacak kontroller belirtilir.
* LDA verilerinin konfigürasyon yönetim süreci tanımlanır.
* Projenin genel takvimi ile entegre olan LDA uygulama takvimi oluşturularak süreçlerin izlenebilirliği sağlanır.
* Kullanım ve destek safhaları kapsamında planlanan faaliyetler ve bu dönemde toplanması gereken verilerin içeriği tanımlanır.
* LDA faaliyetlerinin ELD ve tasarım süreçleri ile olan arayüzleri tanımlanır.
* Gözden geçirme faaliyetlerinin detayları belirlenir.

LDAP, konsept safhasında taslak olarak hazırlanmalı ve geliştirme safhasının başında detaylandırılarak güncellenmelidir. LDA faaliyetleri yapısı itibari ile yinelemeli ve dinamiktir. LDAP’ın projenin mevcut durumunu ve planlanan değişiklikleri yansıtacak şekilde gerektiğinde güncellenmesi gerekir.

LDA faaliyetlerinin planlanması ve koordinasyonu desteklenebilirlik mühendislerinin sorumluluğundadır. LDA sürecinin, sistem mühendisliği ve tasarım süreçlerinin entegre bir parçası olması sağlanmalıdır. Bu doğrultuda oluşturulacak bir LDAP, ömür devri boyunca gerekli ve/veya ihtiyaç duyulan safhalarda LDA faaliyetlerinin gerçekleştirilebilmesi için gerekli stratejiyi ve proje gereksinimlerini karşılamak için gerekli olan yönetim, organizasyon ve prosedürleri tanımlar.

LDAP etkin bir LDA programı oluşturmak ve yürütmek için kullanılan temel araçtır. Planda yer alacak birçok husus müşteri ve yüklenici arasında gerçekleştirilecek LDA İş Tanımlama Toplantısı’nda görüşülerek karara bağlanabilir. TÇD’lere cevaben hazırlanan LDAP, müşteri tarafından yüklenici adaylarının LDA yaklaşımlarını ve faaliyetleri yürütecek organizasyon yapılarını değerlendirmek amacıyla kullanılabilir.

LDAP formatı sözleşme kapsamında müşteri tarafından belirlenebilir. Eğer sözleşmede bir format belirlenmemişse yüklenici söz konusu ürün ve proje gereksinimlerine en uygun formatı kendisi belirleyecektir.

Örnek bir LDAP içeriği EK-I’da sunulmuştur.

=== 4.1.5. PROGRAM VE TASARIM GÖZDEN GEÇİRMELERİNE KATILIM ===
LDA çalışmaları; ön tasarım/kritik tasarım gibi tasarım gözden geçirme toplantıları, teknik bilgi toplantıları, üretime hazırlık gözden geçirme toplantısı gibi proje kapsamında gerçekleştirilen gözden geçirmelerin bir parçası olmalıdır.

Desteklenebilirlikle ilgili bütün hususlar ve mevcut durum bilgisi uygun ve zamanında çözümler elde edilebilmesini sağlamak ve takip edebilmek üzere gözden geçirme toplantıları sonuç dokümanlarında dokümante edilir. Diğer taraftan sistem/ekipman tasarım gözden geçirmelerine ilave olarak LDA’ya özel gözden geçirme toplantıları da ihtiyaç duyulması halinde planlanabilir. Bu toplantılarda tasarım ve program gözden geçirmelerinde adreslenen birtakım konular daha detaylı şekilde incelenebilir ve/veya LDA faaliyetlerinin ilerleme durumları gözden geçirilebilir. Proje gözden geçirme toplantılarına LDA faaliyetlerinin dahil edilmemesi ürünün geliştirmesi ve desteklenmesine ilişkin risklerin artmasına sebep olacaktır.

= 5. LOJİSTİK DESTEK ANALİZ SÜRECİ =
Yeni bir ürünün hizmete alınması veya mevcut sistemlerin modernizasyonu ile birlikte bütün lojistik gereksinimler de doğru zamanda sağlanmış olmalıdır. Bu amaçla ürünün tasarımı esnasında lojistik gereksinimlerin dikkate alınmasını sağlayacak bir süreç oluşturulması gereklidir. Söz konusu süreç kapsamında yüklenici ve müşteri uygun desteklenebilirlik seviyesine erişmek için gerçekleştirilmesi gereken faaliyetler üzerinde mutabakat sağlamalıdır. Lojistik hususların erken dönemde ele alınması hem operasyonel hem de ekonomik açıdan büyük önem taşır. Operasyonel konsepte uygun şekilde kullanılamayan ve idame edilemeyen bir ürün kullanıcı açısından kabul edilebilir olmayacaktır.
[[Dosya:TSSODYP06.LDASURECI.jpg|alt=|sol|küçükresim|758x758pik]]

== 5.1. ÜRÜN KULLANIM VERİSİNİN TANIMLANMASI ==
Yeni bir ürünün desteklenebilirlik özelliklerinin belirlenebilmesi için ürünün planlanan kullanımına yönelik ilişkili bütün verilerin erişilebilir olması ve bu bilgilerin uygun bir şekilde Operasyonel Kullanım Konsepti (veya Operasyonel Konsept) dokümanında yer alması veya ilgili diğer dokümanlarda derlenmiş olarak belirtilmesi gerekir.

Projelerin erken safhalarında bazen ihtiyaç duyulan bilgiler tam olarak mevcut olmayabilir. Ancak kullanım senaryosunun konsept sahfasında tanımlanmış olması önemlidir. Bu durumda ürünün kullanımına ilişkin bilgiler yinelemeli adımlarla derlenmelidir. Kullanım senaryosundaki olası değişiklikler lojistik açıdan kritik önem arzetmekte olup, desteklenebilirlik mühendisleri tarafından dikkate alınarak analiz tekrarının gerekip gerekmediği değerlendirilmelidir.

Ürün kullanım verileri; genel kullanım bilgisi, operasyonel gereksinimler, müşteri gereksinimleri, saha incelemelerinden gelen bilgiler ile kalifikasyon ve sertifikasyon gereksinimleridir.

=== 5.1.1. ÜRÜN GENEL KULLANIM BİLGİSİ ===
Hizmete alınacak ürünün kullanımına yönelik tüm ön şartlar ve ürün tasarımı ile performans verilerinden kaynaklı stratejik hususlar dikkate alınarak genel bir destek stratejisini tanımlanmalı ve ELDP içerisinde dokümante edilmelidir. Söz konusu strateji, daha ileri lojistik destek analizlerin gerçekleştirilmesi ve operasyonel gereksinimlerin ve müşteri gereksinimlerinin oluşturulmasına esas temel kılavuzu oluşturmalıdır.

Operasyonel konsept ve müşteri gereksinimleri oluşturulmadan önce veya eşzamanlı olarak ürünün kullanımına yönelik cevaplanması önerilen bazı örnek sorular aşağıda sıralanmıştır (S3000L). Soruların cevaplanmasının temel amacı, mevcut olan en iyi bilgiyi kullanmak şeklinde belirlenmelidir.

* Ürün nasıl kullanılacaktır? (Ürünün, kilit özellikleri ve gereksinimleri ile temel teknik veri ihtiyaçlarını da içerecek şekilde kısa bir tanımı)
* Yükleneci Lojistik Desteği istenecek midir? Eğer istenecekse, hangi bakım kedemelerinde? (Bu çok genel bir soru olup, aşağıda sıralanan bazı hususların detaylı incelenemesinin akabinde cevaplanması mümkün olacaktır.)
* Ürün nerede kullanılacak ve idame edilecektir?
* Ürün hangi çevresel koşullarda kullanılacak ve idame edilecektir? (Örn. sabit, mobil, endüstriyel, tehlikeli, tehlikesiz)
* Ürünün karakteristiklerini etkileyecek (güvenilirlik, idame edilebilirlik, vb) çevresel koşullar nelerdir? Çevresel koşullar, ürünün onarım tarzını etkileyecek mi?

* Ürün ne kadar süre ile kullanılacaktır? (Örneğin, eğer ürün kısa bir süre için envanterde kalacaksa bu durumda uzun ve maliyetli bir organik destek yapısı oluşturma süreci yerine yüklenici desteği tercih edilebilir.)
* Bakım konsepti nedir? Ürün desteği için kaç bakım kademesi planlamaktadır?
* Her bakım kademesi için tipik özellikler ve/veya faaliyetler neler olabilir?
* Yeni ürünün destek konseptine adapte edilebilecek sürmekte olan bakım kabiliyetleri var mı?
* Öngörülen kullanım mahallinde veya yakınında bulunan başka veya benzer ürünlere yönelik mevcut bakım kabiliyetlerinin yeni ürün için kullanılması mümkün ve etkin olabilecek midir?
* İhtiyaç Makamı/kullanıcı ürünün onarım faaliyetlerine dahil olmalı mı yoksa gerçekleştireceği basit düzeltici bakım ile mi sınırlı olmalıdır? İhtiyaç Makamı’nın sürece dahil olması kendisi tarafından sağlanabilecek yeteneklere bağlıdır. Ayrıca, idame makamlarının imkan ve kabiliyetleri de dikkate alınmalıdır.

* Kullanıcı açısından önleyici ve düzeltici bakım faaliyetleri için bakım süresi ve sıklığı konusunda kabul edilebilir rakamlar nelerdir?
* Önleyici bakımlar için kısıtlamalar söz konusu mudur? (örn. personel ve tesislerin mevcudiyetine ilişkin bazı özel ön şartlar nelerdir)?
* Geliştirilen yazılım ne kadar olgun ve ne kadarı müşteriye özgüdür? (Yazılımların tam olarak olgun bir seviyeye erişmesi uzun süreler alabilir. Lojistik destek yapısı kullanıcı tarafından talep edilecek potansiyel güncellemelerin yazılım bakımını da adreslemelidir).
* Kullanıcı tarafından gerçekleştirilecek herhangi bir yazılım/veri yükleme/kaldırma işlemi var mıdır? Ürünün yazılım/veri yükleme işleminden sonra düzgün şekilde çalıştığı nasıl güvence altına alınacaktır?
* Teknolojideki değişikliklerden kaynaklı olarak üründe beklenen yenileme veya iyileştirme/yükseltme ihtiyaçları nelerdir? (Bu soru, destek yapısının üründeki değişikliklere nasıl ayak uydurabileceği ve destek stratejisinin nasıl uyarlanacağına ilişkindir. Bu konuda öngörülen zorluklar Yüklenici Lojistik Desteği stratejisinin belirlenmesinde etken olabilir).

=== 5.1.2. OPERASYONEL GEREKSİNİMLER ===
Operasyonel gereksinimler hem niceliksel hem de niteliksel olarak tanımlanmalıdır. Donanım, kullanım ve desteklenebilirlik arasında ilişkileri tanımlayan, işletim mahali ve ürün kullanımına yönelik daha önce gerçekleştirilen analizler dikkate alınmalıdır.

Desteklenebilirlik gereksinimleri doğrudan operasyonel gereksinimlerinden türetilirler. Her bir desteklenebilirlik gereksinimi bir operasyonel gereksinime dayandırılmalı, aralarındaki ilişki açıkça belirlenmeli ve sistem gereksinimleri kapsamında dokümante edilmelidir.

Operasyonel gereksinimler yazılırken anahtar performans göstergeleri de belirlenmelidir. Anahtar bir parametre olarak tanımlanmayan herhangi bir parametre, desteklenebilirlik karakteristiklerinin olumsuz etkilendiği durumlarda değiştirilmek için aday olacaktır. Operasyonel gereksinimler, yüklenicinin programın erken safhalarında “zorunlu olan özellikler” ile “olsa iyi olur” diye düşünülen özellikler arasında karar vermesini gerektirir. Desteklenebilirlik mühendisleri için bu bilgi, maliyetten bağımsız olarak, neleri desteklemek zorunda oldukları ve neler için ödünleşim yapabileceklerini anlamak açısından kritik öneme sahiptir.

==== <big>5.1.2.1. GENEL KULLANIM SENARYOSU</big> ====

==== Genel kullanım senaryosunda, ürünün kullanımını, ürünün kullanımından doğan çevresel etkileri tanımlayan bütün bilgiler derlenmelidir. Söz konusu bilgilere ilişkin örnekler aşağıda sıralanmıştır: ====
* Bütün kullanım ve/veya görev alanlarının genel tanıtımı,
* Muhtemel operasyonel senaryolar ve her bir senaryo için gereksinimler,
* Ürünün kullanımından kaynaklanan olumsuz çevresel etkiler ve bu etkilerden kaçınabilmek veya onları azaltabilmek için yapılması gerekenler,
* Halen kullanımda olan ürünler için, kullanım dönemi boyunca ortaya çıkan desteklenebilirlik ilişkili problemler,
* Yeni ürünün mevcut ürünlerle etkileşimi ve birlikte kullanılabilirliği,
* Hareket kabiliyeti gereksinimleri,

==== <big>5.1.2.2. PLANLANAN MEVKİLERİN COĞRAFİ KONUMLARI VE ÖZEL KOŞULLARI</big> ====
Ürünün kullanılacağı alanlar ve bu alanlara ilişkin varsa özel koşulları tanımlayan detaylar derlenmelidir. Bu konudaki bilgilere yönelik örnekler aşağıda sıralanmıştır:

* Operasyon alanlarının sayısı ve coğrafi yerleşimi,
* Her bir operasyon mahallinin coğrafi yapısı ve iklim koşulları,
* Her bir operasyon mahallinin tipi,
* Her bir operasyon mahalline özel koşullar (varsa),
* Söz konusu alanın, barış veya savaş durumu bölgesi olup olmadığı (Tehdit durumları, asgari düzeyde müdahale ile sınırlı olan özel acil durum bakım konseptlerinin geliştirilmesini gerektirir),
* Her bir operasyon alanına erişmek için yeterli altyapı mevcut mu?
* Her bir alan için özel bir altyapı gereksinimi var mı?
* Her bir alan için mevcut ve planlanan kabiliyetler neler (Örn. ekipman, altyapı, personel, tesis, ikmal deposu, onarım atölyesi, vb.),
* Farklı alanlar arasında etkileşimler (örneğin, bir alandan diğer bir alana bakım desteği verilmesi).

==== <big>5.1.2.3. KONUŞLANMA VE ÜRÜN DESTEĞİ</big> ====
Ürünün konuşlanmasına ve konuşlanmadan kaynaklanan etkileşimlere dair detaylar derlenmelidir. Ürünün konuşlandırılacağı yer, organik veya yüklenici desteğine ilişkin kararları etkileyecektir. Bu konuda:

* Her bölgede desteklenecek sistem sayısı,
* Her bölgede konuşlandırılacak ürünler ve
* Farklı alanlar arasında kullanımdan kaynaklanan etkileşimler gibi bilgilerin toplanması gerekir.

==== <big>5.1.2.4. KULLANIMA GENEL BAKIŞ</big> ====
Ürünün planlanan kullanım bilgisi lojistik analizlere temel girdi olarak tanımlanmalıdır. Kullanımın sıklığı ve süresi, ürün güvenilirliği ile birlikte ihtiyaç duyulacak destek kaynaklarının kapsamını ve miktarını belirlemekte başlangıç noktasını oluşturur. İlişkili bilgilere örnekler aşağıda sıralanmıştır:

* Her bir lokasyon için temel kullanım/görev bilgileri
* Performans parametreleri ve kısıtlar (Menzil, doğruluk oranı, faydalı yük, hız vb. parametreler ölçülebilir terimlerle tanımlanmalıdır. Genel terimler veya yoruma açık belirsiz ifadelerden kaçınılmalıdır).
* Öngörülen kullanıma hazır olma ve kullanım başarı oranları
* Birim zamanda operasyon
* Kullanım günü, haftası, ayı veya yılına özgü kullanım/görev profili
* Ürünün işletim zamanı içerisinde eğitim amaçlı kullanılma oranı
* Daimi kullanım şartları/Olası bakım aralıkları
* Her bir kullanım etkinliğinin ortalama süresi
* Birim zamanda kullanıma yönelik temel ölçüm bazı

=== 5.1.3. MÜŞTERİ GEREKSİNİMLERİ ===
Ürünün uygun şekilde kullanımının sağlanması için müşteri bütün lojistik ilişkili isterlerini de yükleniciye iletmelidir. Müşteri isterlerinin kapsamı ve içeriğinde yer alabilecek bilgiler aşağıda tanımlanmıştır.

==== <big>5.1.3.1. İKMAL KONSEPTİ</big> ====
İkmal konsepti desteklenebilirlik mühendisleri açısından kritik önem arzetmektedir. Yedek parça ve sarf malzeme tedariğinin nasıl organize edileceğine dair genel karar, bakım senaryoları üzerinde önemli etki gösterebilmektedir. Lojistikçi, depolama alanlarına yönelik planlama ihtiyacı olup olmadığı ve tedarik zinciri yönetiminin dış kaynaktan temini durumunda kim tarafından yönetileceğine karar vermelidir. Özellikle tesis inşaatına dair maliyetler ve teknolojik eskime dikkate alınması gereken önemli hususlardır.

==== <big>5.1.3.2. DESTEK EKİPMANI KONSEPTİ</big> ====
Maliyet açısından etkin olması durumunda özel destek ekipmanları yerine yaygın destek ekipmanları tedarik edilmelidir. Maliyetleri düşürmek için, mevcut destek ekipmanlarının kullanılıp kullanılamayacağı veya yeni sisteme adapte edilip edilemeyeceğinin değerlendirilmesi önemlidir.

==== <big>5.1.3.3. PERSONEL ENTEGRASYONU VE EĞİTİM</big> ====
İşgücü konusu birçok sistemin desteklenebilirliği için önem taşır. Destek personelinin uygun zamanda eğitim alabilmesi için planlama yapılmalıdır.

Eğitim ihtiyaçlarının iki bileşeni vardır: Başlangıç ve süreklilik eğitimleri. Her ikisi de yeterli personel becerisinin sağlanması açısından önemlidir. Personel devir oranlarının yüksek olması, belirli bir beceri setinin idamesini zorlaştıran bir etkendir. Desteğin planlanması aşamasında bu hususlar da dikkate alınmalıdır.

==== <big>5.1.3.4. TESİSLER</big> ====
Tesislere ilişkin uzun saha temin ve tahsis süreleri, tesis ihtiyaçlarının erken dönemde planlanmasını zorunlu kılar. Bakım faaliyetlerinde kullanılacak tesisler bakım sürecindeki tüm faaliyetleri ve iş akışlarını destekleyecek şekilde planlanmalıdır.

==== <big>5.1.3.5. BİLİŞİM VE HABERLEŞME KAYNAKLARI</big> ====
Bilişim ve haberleşme kaynak ihtiyaçları desteklenebilirlik mühendislerinin erken dönemde hazırlık yapmalarını gerektiren bir başka alandır. Bu konuda dikkate alınması gereken hususlar aşağıda sıralanmıştır:

* Diğer hizmetlerle ara yüzü sağlamak için ne gibi kısıtlar vardır/gereklidir?
* Örneğin X altyapısı operasyonel kullanılabilirlik açısından arzu edilir bir iyileştirme sunarken, başka bir hizmet tarafından kullanılan Y haberleşme ağına erişime engel oluyorsa nasıl bir ödünleşim yapılmalıdır?
* Nasıl bir bilgi teknolojisi altyapısına ihtiyaç duyulmaktadır?

Bilgi teknolojisi kaynaklarının bilgisayar donanımı, ağ bileşenleri, ağ kablolamaları haberleşme protokolleri, yazılım paketleri, veri güvenliği ve standartlar gibi birçok yönü vardır. Bu konu aynı zamanda gelecekte öngörülen kabiliyetlerin de anlaşılmasını gerektirir. “Sahaya verildiği zaman kullanımda olacağı tahmin edilen sistemler”le ara yüzü olacak şekilde bir sistem tasarlamak tasarım ve desteklenebilirlik mühendislerinin diğer ilgili projelerin durumundan haberdar olmalarını gerektirir. Sistemin planlanan gelecekteki haberleşme mimarisi ile nasıl bir ara yüz kuracağı ele alınmalıdır. Lojistikçi, muhtemel bilgi teknolojisi sistem değişikliklerinin etkisini değerlendirmeli ve lojistik yapıda gerekli düzenlemeleri belirlemelidir.

=== 5.1.4. SAHA İNCELEMELERİ ===
Saha incelemeleri, tasarlanacak olan ürünle ilişkili yürütülecek olan LDA faaliyetlerinin planlanmasında çok büyük bir öneme sahiptir. Yürütülen inceleme faaliyetlerinde ihtiyaç makamı/kullanıcı/idame makamı’nın bünyesinde bulunan eğitim ve kurs yerlerinin, bakım fabrikalarının ve bakım birliklerinin imkânları ve kullanıcı ve bakım personelinin bilgi ve tecrübesi tespit edilir. Bu sayede tasarımı yapılacak olan sistemin kullanım ve destek süreçleri geliştirilirken, mevcut tesis imkimkânanları ve personel becerileri göz önünde bulundurulur. Envanterde bulunan benzer sistemler detaylı olarak incelenir, bu sistemler ile ilgili bakım personellerin ve sistemi kullanan operatörlerin yaşadıkları sıkıntılar ve zorluklar tespit edilir. Muharebe/operasyon alanında, bakım fabrikalarında, bakım birliklerinde yedek parça ve sarf malzemesi tedariğinde yaşanan problemler, bakım yöntemlerinin uygulanmasında yaşanan sorunlar, yedek ve sarf malzemelerinin paketlenmesinde, depolanmasında, elleçlenmesinde ve taşınmasında yaşanan sorunlar tespit edilir. Bu kapsamda saha incelemelerinde, proje kapsamına göre LDA faaliyetleri ile ilişkili soru setleri oluşturularak, incelenmekte olan sistemin/sistemlerin geneli ve mümkünse alt sistem ve parça seviyesinde detaylı bilgiler toplanır.

Saha incelemelerinde kullanılabilecek örnek bir soru seti Tablo 4’de verilmiş olup proje veya konuya özgü sorular da bu tabloya eklenebilir.

'''Tablo 4 Örnek Soru Seti'''
{| class="wikitable"
| colspan="2" |'''Örnek Soru Seti'''
|-
|'''Sıra No'''
|'''PEDU'''
|-
|001
|Kaç tip ambar mevcut? Ambarların/Depoların ortam koşulları nedir? (Nem, sıcaklık, aydınlatma, havalandırma, vb.)
|-
|002
|Kullanılan bir paketleme standardı var mı?
|-
|003
|Paketleme malzemesi olarak ne kullanılıyor?
|-
|004
|Kullanılan paketler tekrar paketlemede kullanılabilir özellikte mi?
|-
|005
|Paket dolgu malzemesi kullanılıyor mu? Ne tip bir dolgu malzemesi kullanılıyor?
|-
|006
|Tampon malzeme kullanılıyor mu? Kullanılıyorsa kalınlığı nedir?
|-
|007
|Uygun kaldırma noktası mevcut mu? Eğer uygun kaldırma noktası yoksa bu durum taşıma/kaldırma vb. işlemler sırasında zorluk çıkartıyor mu?
|-
|008
|Kaldırma, depodan araca yükleme, araçtan depoya aktarma, vb. işlemler sırasında kullanılan ekipman nedir? (vinç, cayraskal, forklift, vb.)
|-
|009
|Etikette yer alan bilgiler nelerdir? Herhangi bir etiketleme standardı kullanılıyor mu?

(sandık numarası, alt sistem/cihaz/malzeme adı, ambalaj sıra no, netve brüt ağırlık ve hacimleri, NSN ve/veya Parça no, miktar, son kullanma tarihi, v.b)
|-
|010
|Kutusundan/Paketinden çıkartırken ve kullanıma hazırlarken uygulanan özel bir işlem var mı? Herhangi bir askeri standart kullanılıyor mu?
|-
|011
|Araçtan sökülen ve farklı bir bakım seviyesine nakli yapılacak sistem bileşeni paketleniyor mu? Herhangi bir askeri standart kullanılıyor mu?
|-
|012
|Araçtan sökülen ve uzun süre depoda tutulacak olan sistem bileşeni paketleniyor mu? Herhangi bir askeri standart kullanılıyor mu?
|-
|'''Sıra No'''
|'''BGA'''
|-
|013
|Bakımlar, bakım dokümanı dışında başka hiçbir dokümana ihtiyaç duyulmadan gerçekleştirilebiliyor mu?
|-
|014
|Bakım sarf ve yedeklerinin tedariğinde zorluk yaşanıyor mu? Alternatifleri var mı?
|-
|015
|Bakım sarf ve yedeklerinin tedariği gecikiyor mu? Maliyet bilgileri mevcut mu?
|-
|016
|Depoda/Ambarda muhafaza edilen malzemeye uygulanan bir bakım mevcut mu?
|-
|017
|Bakım sistem çalışır vaziyetteyken yapılabiliyor mu?
|-
|018
|Cihaz sistem üzerinde montajlıyken ilgili parça sökülebiliyor mu?
|-
|019
|Cihaz sistem üzerinde montajlıyken ilgili parçanın bakımı yapılabiliyor mu?
|-
|020
|Bakımı yapan personelin ihtisası (elektrik, motor, vb.) ne olmalı?
|-
|021
|Ne tip bir temizlik malzemesi ile temizleniyor?
|-
|022
|Temizlik malzemesinin insan sağlığına ne gibi etkileri var?
|-
|023
|Bakım işlemlerinde boyanın temizlenmesine ve tekrar boyanmasına ihtiyaç var mı?
|-
|024
|Özel tezgâh ihtiyacı var mı?
|-
|025
|Özel alet/avadanlık gerekiyor mu? Gerekiyorsa kaç adet, bunlar neler?
|-
|026
|Kullanılan alet/avadanlıklar metrik birim sisteminde mi?
|-
|027
|Bakım dokümanlarında hangi birim sistemi kullanılıyor? Kullanılan birim sistemi zorluk yaratıyor mu?
|-
|028
|Periyotları çakışan bakımlar olduğunda yapılacak bakımlarda sökülmesi gereken parçalar birbirleri ile ardışık veya ilişkili mi?
|-
|029
|Periyotları çakışmayan bakımlar arasında ardışık/ilişkili parçaların sökülmesi gereken bakımlar var mı?
|-
|030
|Bakımlar karmaşık adımlardan mı oluşuyor?
|-
|031
|Periyodik bakım tanımlı olduğu halde uygulanmazsa araç veya sistem bundan nasıl etkileniyor?
|-
|032
|Periyodik parça değişimli bakımlarda, periyodu gelmeden arızalanan/değiştirilmesi gereken parçalar oluyor mu?
|-
|033
|Bakımda kullanılan veya değiştirilen parçalar için özel imha metodu var mı?
|-
|'''Sıra No'''
|'''HTEKA'''
|-
|034
|Hasarlı parça ıskartaya mı ayrılıyor yoksa laboratuvar incelemesi yapılmak üzere üreticiye/ilgili bakım kademesine gönderiliyor mu?
|-
|035
|Diyagnostik imkânı var mı?
|-
|036
|Çalışma değerleri herhangi bir ölçüm cihazı ile izlenebiliyor mu?
|-
|037
|Çalışma değerlerinin herhangi bir ölçüm cihazı ile izlenemiyor olması arıza tespitinde zorluk yaratıyor mu?
|-
|038
|Arızalandığı zaman sistemi durdurmak gerekiyor mu yoksa sistem çalışmaya devam edebilir mi?
|-
|039
|Arızalandığı zaman sisteme veya diğer alt sistemlere/bileşenlere de zarar veriyor mu?
|-
|040
|Meydana gelen arızalar/hatalar arasında mevcut bakımlar ile giderilemeyen oluyor mu?
|-
|041
|Arıza kayıtları var mı? Seri kontrollü olarak tutuluyor mu?
|-
|'''Sıra No'''
|'''OSA'''
|-
|042
|İlgili sistem bileşeninin bakımları hangi kademede yapılıyor?
|-
|043
|Aynı anda kaç sistemin bakımı yapılabiliyor?
|-
|044
|Eğer limit aşımı olursa bakımı yapılacak araç farklı birliğe mi yönlendiriliyor, bir üst kademeye mi yönlendiriliyor yoksa sırada mı bekliyor?
|-
|045
|Bakımı yapılacak araç/sistem ne tip bir taşıtla getiriliyor?
|-
|046
|Ulaştırma maliyetleri nedir? (Taşıt cinsi + km)
|-
|047
|Bakımı yapılacak aracın/sistemin birliğe taşınması ne kadar sürüyor?
|-
|048
|Bir üst kademede bakımı yapılacak aracın/sistemin ilgili kademeye ulaşması ne kadar sürüyor?
|-
|049
|Bakımı bir üst kademede yapılacak sistem bileşeninin hata/arıza tespiti hangi kademede yapılıyor?
|-
|050
|Birlik seviyesinde bakımı yapılacak sistem bileşeninin hata/arıza tespiti hangi kademede yapılıyor?
|-
|051
|Taşıma/ulaştırma için hangi yönetmeliklere tabii tutuluyor?
|}

=== 5.1.5. KALİFİKASYON VE SERTİFİKASYON GEREKSİNİMLERİ ===
Müşteri, bir kalifikasyon süreci yürütmek istediğinde, ürünün kalifikasyonu içerisinde bakım faaliyetlerinin ne şekilde ele alınacağı yüklenici ve müşteri tarafından programın erken safhalarında açıklığa kavuşturulmalıdır. Kalifikasyon gereksinimleri müşteri tarafından belirlenmeli ve operasyonel gereksinimler ile aynı zamanda yükleniciye iletilmelidir.

Benzer şekilde ürünün öngörülen çevresel koşullarda işletimi için bir sertifikasyon süreci gerekiyorsa, sertifikasyonun kapsamında yer alacak bakım faaliyetlerinin belirlenmesi ve dokümante edilmesine özellikle dikkat edilmelidir. Bu faaliyetler yerine getirilmesi zorunlu faaliyetlerdir. Sertifikasyonu etkileyen bakım faaliyetleri birinci derece önceliğe sahip olmalıdır.

Kalifikasyon gereksinimleri müşteri tarafından belirlenirken sertifikasyon gereksinimleri bir sertifikasyon otoritesi tarafından belirlenir. Müşteri ve yüklenici, kalifikasyon ve sertifikasyon süreçleri arasındaki farkların ilgili kişiler tarafından bilinmesini sağlamalıdır.

== 5.2. LDA İLİŞKİLİ ÜRÜN TASARIM VE PERFORMANS VERİLERİNİN BELİRLENMESİ ==
Ürün tasarım ve performans verileri LDA’yı doğrudan veya dolaylı olarak etkilemektedir. Sistemin ömür devri boyunca karşılaşacağı çevresel koşullar, kullanım parametreleri ve performans isterleri LDA için önemli girdilerdir. Örnek olarak bir askeri kara aracının %60 eğime tırmanması ile ilgili teknik bir ister LDA’yı etkilemektedir. Aracın bu denli yüksek bir eğim tırmanma kabiliyeti, araç operatörlerinin bu konuda eğitimli ve bilgili olması ile mümkündür. Aynı zamanda ömür devri boyunca bu gibi bir durumla kaç kez karşılaşacağı bilgisi de aracın bakım planlaması için önem arz etmektedir.

LDA ile ilişkili ürün tasarım ve performans verileri belirlenirken yalnızca sistemin ömür devri boyunca karşılaşacağı çevresel koşullar, kullanım parametreleri ve performans isterlerinden değil, aynı zamanda bu isterleri gerçekleştirecek fiziksel ekipmanlardan ve bu ekipmanların üreticilerinin üretmiş olduğu teknik dokümanlardan da faydalanılır.

Örnek olarak askeri bir kara aracında teknik isterleri sağlaması için seçilmiş bir motorun yağlama ve bakım periyotları LDA için büyük önem arz eder. Diğer bir örnek ise motorun arızalar arası ortalama süresi, yani güvenilirlik karakteristikleridir. Yedek parçaların neler olduğunun belirlenmesi ve ne zaman nerede bulunması gerektiği bilgisi LDA sonuçları ile ortaya konacaktır.

Sistem gereksinim tanımlama aşamasında ve/veya ön tasarım aşamasında yürütülen ürün tasarım ve performans verilerinin belirlenmesi faaliyetleri esnasında dikkate alınabilecek hususlar aşağıdaki başlıklarda detaylı bir şekilde yer almaktadır:

* LDA ile ilgili veri ve bilgilerin seçim kriterleri
* LDA veri seçiminde genel LDA yaklaşımlarının ve ilkelerinin etkisi
* Seçim değerlerinin doğrulanması ile ilgili kabul kuralları
* Öngörülen değerlerin doğrulanması için kriterler ve prosedürler
* İhtiyaç makamı/kullanıcı/tedarik makamı/idame makamının katılımı

=== 5.2.1. LDA İLE İLGİLİ VERİ VE BİLGİLERİN SEÇİM KRİTERLERİ ===
LDA ile ilişkili olarak dikkate alınması gereken veri ve bilgiler, LDA süreci kapsamında doğrulama ve kontrollere tabi olan veri ve bilgilerdir. Seçim kriterleri; LDA uygulanacak ürüne, ilgili sözleşmeye, şartnameye ve belirlenmiş ELD yaklaşımına bağlı olarak ayrıntılı bir şekilde belirlenmelidir. İlgili bilgiler, oluşturulan LDA süreci kapsamında doğrulanacak bir hedef belirlemek üzere LDA veri tabanı içerisinde gereksinim olarak dokümante edilebilirler. Genel bir yaklaşım olarak, aşağıdaki paragraflarda tanımlanan seçim kriterleri göz önünde bulundurulmalıdır:

==== <big>5.2.1.1. Sözleşme Dokümanlarından Türetilen LDA Bilgi ve Verilerinin Seçimi</big> ====
LDA veri tabanında dokümante edilmiş bilgilerle doğrulanabilecek LDA ilişkili ürün tasarım ve performans özellikleri için, sözleşme dokümanlarının dikkatle değerlendirilmesi gerekmektedir. Genellikle ürün gereksinimleri ya da Anahtar Performans Göstergeleri olarak adlandırılan önemli noktalar, potansiyel olarak sözleşme teşvikleriyle ilgili zorunlu hedefler ve/veya eşikler oluşturmak için bu dokümanlarda ele alınmaktadır.

Anahtar Performans Göstergeleri örnekleri:

* Çalışma saati başına belirtilen Maksimum Bakım Saati.

''Bu değer başarılı bakım tasarımı ile ilgili bir referans noktası olarak kullanılabilir.''

* Onarım için belirtilen Maksimum Ortalama Süre ve Onarım için belirtilen Maksimum Ortalama Süre Yüzdesi.

''Bu değerler belirlenen zaman kısıtlamaları içinde onarımla ilişkili olduğu için başarılı bir tasarım göstergesi olarak kullanılabilir.''

* Çalışma saati başına belirtilen Maksimum Hata Sayısı.

''Bu değer ürünün istenen güvenilirliğin ve ters orantılı olarak bakım iş yükünün bir göstergesidir.''

* Minimum Kullanılabilirlik ile ilgili belirlenmiş rakamlar.

''Bu değerler kullanıma hazır olma konusunda başarılı bir tasarım göstergesi olarak kullanılabilir.''

* Test edilebilirlik özellikleri.

''Bu değerler hayati fonksiyonların izlenmesine ve Cihaz İçi Test Ekipmanı (CITE) ve genel test mimarisi gibi yollarla potansiyel arızaların tespit ve lokalizasyonuna yönelik tasarımın kabiliyetini göstermektedir.''

* Minimum Kullanım Ömrü

''Bu değer minimum kullanım ömrü gereksinimini gösterir. Bu değer belirlenen eşiğin altına düşme riskini göstermelidir.''

==== <big>5.2.1.2. Ürün Kullanım Verilerinden Türetilen LDA Bilgi ve Verilerinin Seçimi</big> ====
İlgili bilgiler LDA veri tabanında temel referans olarak dokümante edilir.

Örnekler:

* Ölçüm Tabanı ile Yıllık Kullanım Gereksinimleri,
* İşletme yeri/tesis sayısı,
* Her tesiste işletilecek sistem sayısı,
* Her tesiste kurulacak bakım seviyeleri,
* Her tesiste mevcut bakım personeli (branş ve beceriye göre kişi sayısı)

==== <big>5.2.1.3. Ürün Şartnamelerinden Gelen LDA Bilgi ve Verilerinin Seçimi</big> ====
Ürünün tasarımını ve performansını etkileyen LDA ile ilgili parametreler doğrulama ve/veya kontrol amaçlı LDA veri tabanında belgelenir.

Örnekler:

* Minimum değer gösteren ilgili ölçüm tabanı ile birlikte MTBF,
* Güvenilirlik artışı,
* Cihaz İçi Test Ekipmanı ile belirlenmiş test özellikleri,
* Ortalama Onarım Süresi,
* Diğer Ürün Belgelerinde Yer Alan Ürün Sertifikasyonu ve Doğrulaması ile ilgili LDA Veri ve Bilgilerinin Seçilmesi.

LDA ile ilgili bilgiler tasarım bölümleri, emniyet veya müşteri dokümanlarından da elde edilebilir.

Örnekler:

* Özel kullanım ve/veya onarım sınırlamaları (Örneğin; sıcaklık aralıkları, anti-statik koruma gereksinimleri, temiz hava onarım koşulları),
* Geçerlilik bilgisi (Örneğin; sürüm uygulanabilirliği),
* Tehlikeli arızaların sınıflandırılması,
* Depolama sınırlamaları ve/veya gereksinimleri,
* Belirli parçaların kritiklik sınıflandırması,
* Zamanlanmış gereksinimler (Örneğin; belirlenen zaman sınırları, büyük bakım (overhaul) gereksinimleri).

=== 5.2.2. LDA VERİ SEÇİMİNDE GENEL LDA YAKLAŞIMLARININ VE İLKELERİNİN ETKİSİ ===
İlgili ürün tasarımı ve performans verilerinin belirlenmesinden önce, LDA programının uyarlanmasının bir parçası olarak genel bir LDA yaklaşımı oluşturulmalıdır. Uyarlama süreçleri projenin karmaşıklığına, iş birimlerine (yükleniciye) ve bilinen risk faktörlerine bağlıdır. Bu kısıtlamalar ve performans gereksinimleri, gerekli analiz çabaları, zaman, program ve tahsis edilen bütçe arasında, proje için en uygun maliyet/fayda ile dengelenir. Sonrasında bu gereksinimler, konular ve kısıtlamalar gözden geçirilir ve tüm paydaşlar arasında bir fikir birliği sağlamak için LDA İş Tanımlama Toplantısı’nda değerlendirilir. Bu bulgular, analizler ve sonuç anlaşmaları LDA İş Tanımı ile belgelendirilir.

Bu uyarlama aktivitesi yinelemeli bir süreçtir ve programın her aşamasında tekrarlanmalıdır. Her bir önceki aşamadan elde edilen sonuçlar ve öğrenilen dersler, aşağıdaki aşamaların her biri için uyarlama analizinin bir parçası olmalıdır.

Genel LDA yaklaşımları ve ilkeleri, LDA süreci ile ilgili olarak ürün tasarımı ve performans verilerinin seçimini etkileyebilir. Bu alanda sürdürülebilirlik için dikkate alınması gereken örnekler aşağıdaki gibidir:

* Üç seviyeli bakım konsepti

Bakım faaliyetleri kullanıcı, birlik ve fabrika/firma seviyesi olarak ayrılmıştır. Kullanıcı seviyesinde operatör/kullanıcı/sürücü/mürettebat tarafından yapılabilecek bakımlar icra edilir. Birlik seviyesinde arızalı Hatta Değiştirilebilir Birimler (HDB), faal HDB'ler ile değiştirilirken; fabrika/firma seviyesinde arızalı HDB'lerin onarımları yapılır. Fabrika/firma seviyesi bakım faaliyetleri üretici firmalar tarafından yapılabileceği gibi organik bakım tesislerinde gerçekleştirilebilir.

* Önceden belirlenmiş iki seviye bakım konsepti

Bakım esasen ''arızalı parçanın değiştirilmesi'' ya da ''arızalı parçanın onarımı'' olmak üzere iki bakım seviyesiyle sınırlıdır. İki seviyeli bakım konseptleri işletme sahasında çıkarılacak ve değiştirilecek ekipmanın (HDB) düşük bir arıza oranı ve yüksek bir test edilebilirlik oranına sahip olduğu takdirde genel maliyet hususları sebebiyle tercih edilir.

Bu konsept ile LDA verileri önceden belirlenmiş Bakım Seviyeleri (BS) ile sınırlandırılır.

* Belirli bir bakım seviyesi üzerinde yoğunlaştırılmış Onarım

Onarım, maliyet etkinliğinden bağımsız olarak maksimum özerklik elde etmek için organik bakım tesisleri ile sınırlıdır.

Bu konsept ile, onarım opsiyonu verileri önceden belirlenmiş BS ile sınırlandırılır.

* BS 1 ve/veya 2'de Sınırlı Onarım

Herhangi bir operasyonel aksama süresini kısaltmak için düzeltici bakım eylemi bir yedek parça değişimi (yerinde olmayan onarım -) ile sınırlandırılabilir.

Bu konsept ile bakım görevi önceden belirlenmiş kriterler ile sınırlandırılır.

* Tek kaynak prensibi

Büyük onarım gerektiğinde, sistem/alt sistem/bileşen tedarikçisi ilgili deneyime, personele ve ekipmana en çok sahip ve en hızlı hazır olan şeklinde tercih edilmelidir.

Bu konseptte onarım verileri tedarikçi bilgileri ile sınırlandırılır.

* Ara destek kavramı

Bakım Konsepti (BK) kararlarından önce deneyim kazanmak ve riskleri azaltmak için ara destek aşaması oluşturulabilir.

Bu konseptte BK verileri ön bilgi ile sınırlandırılır.

* Rafta Hazır Ticari Ürün (RAHAT) kavramı

Piyasada mevcut ekipman kullanıldığında ilgili koşullar kabul edilmelidir.

Bu konsept ile veriler ilgili tedarikçi bilgilerini/koşullarını yansıtmalıdır.

=== 5.2.3. DOĞRULAMA DEĞERLERİNE İLİŞKİN KABUL KURALLARI ===
Doğrulama süreci esnasında belirsizliklerden kaçınmak için açıkça tanımlanmış kabul kuralları oluşturulmalıdır. Bu kurallar, LDA ilişkili ürün tasarım ve performans verilerine dair sonuçların hassas bir şekilde kabul veya reddedilmesine imkân sağlayacaktır.

==== <big>5.2.3.1. Ölçüm Değerleri Kategorisi</big> ====
İlgili ölçüm değerinin önemini ifade eden gereksinim türleri tanımlanmalıdır. Bu türler:

* Zorunlu değerler,
* Hedefler,
* Eşikler (minimum veya maksimum değerler).

==== <big>5.2.3.2. Toleransların Belirlenmesi</big> ====
Tanımlanan her bir ölçüm değeri için ilgili toleranslar ifade edilmelidir.

* Tek bir değer için atanmış,
* Benzer değerlerden oluşan bir grup ile ilgili toleranslar, örneğin; tek bir kalem yerine grubun başarısızlık oranını karşılamak için analiz edilen kalemlerin belirli bir alanı içindeki hata oranlarının telafi edilmesi (Örneğin; ek kısıtlamaların izlenmesi).

==== <big>5.2.3.3. Kabul Kriterlerinin Oluşturulması</big> ====
İlgili gereksinim ile birlikte her bir değer için ölçülebilir kabul kuralları oluşturulmalıdır. Bu kurallar, LDA veri tabanında belgelenen değerlerin kabul edilmesine veya reddine yol açan temel koşulları (Örneğin, yeterli istatistik güven düzeylerine dayalı olarak minimum gerekli değerlerin yerine getirilmesi) tanımlamalıdır.

Ayrıca, oluşturulmuş durum bilgilerinin sonuçları açıkça belirtilmelidir:

* Belgelenen değerin kabul edildiğini gösteren Analiz Altındaki Kalem’in (AAK) durumu,
* AAK'nin belgelenmiş değerin ilgili gerekçeyle reddedildiğini gösteren durumu,
* Belgelenen şeklin şartlı kabul edildiğini belirten AAK'nin durumu (Örneğin; genel olarak kabul edilebilir ancak yeniden çalışma gerektiren).

==== <big>5.2.3.4. Özel Kuralların Oluşturulması</big> ====
Özel kurallar belirlendiğinde, belirsizlikten kaçınmak için ilgili koşullar ve ilgili değerler net olarak tanımlanmalıdır:

* Başarısız olarak belirtilen LDA verilerine ilişkin ceza düzenlemelerinin oluşturulması
* Belirtilen LDA değerini aşması durumunda ödüllerin oluşturulması

=== 5.2.4. ÖNGÖRÜLEN DEĞERLERİN DOĞRULANMASI İÇİN KRİTERLER VE PROSEDÜRLER ===
Son olarak, doğrulamaya tabi olan verilerin ve/veya diğer bilgilerin doğrulanması için kriterler oluşturulmalıdır.

==== <big>5.2.4.1. Ölçülebilir Hedef Değerlerin Belirlenmesi</big> ====
Göz önüne alınan veri unsurları için ilgili öngörülen değer aralığı LDA veri tabanı içerisinde, orijinal toleransları ve varsa ilgili kabul kuralları ile birlikte orijinal hedefi dikkate alarak bir gereklilik olarak kurulmalı ve belgelendirilmelidir.

==== <big>5.2.4.2. Öngörülen Değerlerin Doğrulanması</big> ====
Analiz sürecinden elde edilen LDA veri tabanında belgelenen ilgili veriler ve diğer bilgiler, ilişkili kabul edilebilir değerlerle karşılaştırılmalıdır. Sonuç, gerçekleşen LDA değerlerinin öngörülen değerler ile tutarlı olup olmadığını belirten analiste ve/veya ilgili yönetime rapor edilmelidir.

==== <big>5.2.4.3. Doğrulama Yöntemi</big> ====
Öngörülen değerler ve doğrulama yöntemleri üzerinde anlaşmaya varılmalıdır:

* Analitik kanıt sunarak doğrulama (LDA veri tabanında belgelenmiş),
* Uygun testlere dayanan bir analitik yöntem kullanarak doğrulama (Örneğin; bir test teçhizatında),
* Ürünün prototipinde veya seri versiyonlarında gösterim ile doğrulama,
* Sertifika ve/veya gösterim programları kurallarına göre doğrulama,
* Deneme oturumları ile doğrulama (Örneğin; Kullanıcı/Tedarik Makam personeli tarafından gerçekleştirilen),
* Uzun süreli denemeler sırasında doğrulama (Örneğin; belirli bir “olgunluk aşaması” sırasında).

==== <big>5.2.4.4. Özel Amaçlar için Doğrulama</big> ====
Sertifikalar, nitelikler veya lisanslar elde etmek için özel amaçlar için doğrulama gerektiğinde belirli kurallar oluşturulabilir.

==== <big>5.2.4.5. Durum Kodlarının Güncellenmesi</big> ====
Doğrulama sonuçlarına bağlı olarak ilgili durum bilgisi durum tahsisi için belirlenen kuralları izleyerek doğrulama sonucuna bağlanmalıdır.

=== 5.2.5. KULLANICI/TEDARİK MAKAMI KATILIMI ===
LDA süreci kapsamında doğrulama ve kontrole tabi ürün tasarım ve performans verilerinin seçimi müşteri tarafından LDA GGT sırasında kabul edilmeli ve KKB'de belgelenmelidir. Bu aynı zamanda ilgili kuralların ve öngörülen değerlerin anlaşılması için de geçerlidir.

== 5.3. LDA İŞ TANIMLAMA TOPLANTISI ==
LDA uygulanacak aday kalemlerin seçimi, bahse konu aday listesine uygulanacak yöntemler ile ilgili LDA İş Tanımının yapılması, LDA aktivitelerinin belirlenmesi ve planlaması için tüm paydaşların katılımı ile LDA İş Tanımlama Toplantısı gerçekleştirilir. Bu toplantıda alınan kararlar neticesinde LDA adayları seçim kriterleri nihai hale getirilir ve LDA İş Tanımı ve LDA planı onaylanır. Böylelikle ilgili projede LDA uygulanırken izlenecek yöntemler, ara çıktılar, safha sonlarında yer alan çıktılar tümüyle belirlenmiş olur.

Bu kapsamda yer alan öneriler ile verimli bir LDA iş süreci işletilebilmesi hedeflenmektedir.
[[Dosya:LDA İş Süreci v.jpg|alt=|sol|küçükresim|687x687pik]]

=== 5.3.1. LDA İŞ TANIMLAMA TOPLANTISI HAZIRLIK FAALIYETLERI ===
Toplantı esnasında en iyi performansı sağlayabilmek için toplantı girdilerinin hazır olması, sonuç ve nihai mutabakata dair net beklentilerin tanımlı olması ve taslak LDA iş tanımı kapsamında hazırlanmış kontrol listelerinin kullanılması ile izlenecek adımların takibi ve üzerinde gerçekleştirilecek çalışmaların yönetilmesi kapsamında faydalıdır.

LDA İş Tanımlama Toplantısı için girdi olabilecek dokümanlar aşağıdaki şekildedir:

* Sözleşme ve Ekleri,
* Genel kullanım hususları,
* Operasyonel gereksinimler,
* Taslak LDA adayları listesi,
* Taslak veri elemanları listesi,
* Taslak LDA İş Tanımı,
* Taslak LDAP.

Diğer taraftan, erken stratejik değerlendirmelere bağlı olarak zorunlu ve önerilen LDA aktivitelerinin belirlenmesi gibi hususların önceden düşünülmüş olması yararlı olacaktır.

Bu kapsamda aşağıdaki hususlar dikkate alınarak çalışmalar yürütülür;

* '''Aday Kalem ve Aday Olmayan Kalem:'''

LDA adayı tüm LDA aktivitelerinin ana yönlendiricisidir. Potansiyel bir LDA adayı, genel olarak onarım yapılabilen veya planlı/plansız bakım görevi bulunan bir sistem, alt sistem, ekipman, modül veya alt modül seviyesindeki bir kalemdir. Analiz edilecek kalemin konfigürasyon listesinde olup olmaması, yukarıdaki kriterlere ek olarak proje özelindeki kriterlere de bağlı olarak değişebilmektedir.

Donanımla ilgili tanımlamaya ek olarak, özel aktiviteler ürün kırılımının uygulanabilir olması durumunda özel bir bölümünde tanımlanabilir. Örneğin, yapısal bileşenlerin onarımı için standart uygulamaların tarifi, ürün kırılımının özel bir bölümünde belirtilebilmektedir. Bu durumda, donanım dışı bazı arıza unsurları da kendilerine özel aktiviteler veya bakım görevleri tanımlandığı için LDA adayı olabilmektedir.

Aday olmayan malzemeler için ayrıntılı bir lojistik analiz gerekli değildir. Bu tip malzemeler fiziksel ürün kırılımda görünmek zorunda değildir. Özel bir lojistik kaynağın gerekmediği, standart görevlere tabi olan malzemeler de potansiyel aday olmayan malzemedir. Aday olmayan malzemeler için tipik örneklere sarf malzemeleri, vidalar, cıvatalar, somunlar, rondelalar verilebilir. Bununla birlikte, bir malzeme LDA adayı seçim sürecinde aday olarak belirlenmemişse bile Aday Kalem Listesinde aday olarak seçilmeme sebepleriyle birlikte dokümante edilmelidir.

* '''Bakım İlgili Malzeme (BİM) ve Bakım Önemli Malzeme (BÖM):'''

LDA adaylarının belirlenmesi sürecinde bakım/onarım gerektiren malzemeler dikkate alınmalıdır. Bakım görevleri, planlı bakım görevleri ve plansız bakım görevleri olmak üzere iki kategoriye ayrılmaktadır. Bu aşamada aşağıda tanımları verilen iki kavram ortaya çıkmaktadır.

Bakım İlgili Malzeme (BİM): Bir arıza veya hasar durumunda onarılan veya değiştirilebilen malzemelerdir. Bu malzemeler potansiyel LDA adayıdır. Fakat bu malzemeler doğrudan Bakım Önemli Malzeme (BÖM) değildir.

Bakım Önemli Malzeme (BÖM): Önleyici bakım analizleri sonucunda planlı bakım görevleri tanımlanan malzemelerdir. Bu bakım görevleri LDA veritabanında dokümante edilmelidir.

* '''Yapısal Malzeme, Yapısal Önemli Malzeme:'''

Ürün Kırılımında yer alan yapısal malzemeler tipik LDA adayıdır. Bu malzemeler ayrıca planlı bakım analizi için de potansiyel adaylardır. Yapısal malzemelere ilişkin tanımlar aşağıda yer almaktadır.

Yapısal Malzeme: Yapısal Malzeme, sistemin üstyapısının bir parçasıdır. Yapısal Önemli Malzeme (Structure Significant Item) olarak LDA adayı olabilmektedir.

Yapısal Önemli Malzeme: Planlı bakım analizi sonucunda belirlenen malzemelerdir.

* '''Donanım Olmayan Malzeme (Non-Hardware Item):'''

Fiziksel Ürün Kırılımlarında sadece ürüne ait donanımlar dokümante edilmektedir. Ancak özel bir donanıma ait olmayan, bir grup malzeme için (kablo, vb.) tanımlanan bakım görevleri olması durumunda bu tip malzemeler Donanım Olmayan Malzeme adı altında Ürün Kırılımlarına eklenebilmektedir. Bu tip malzemeler LDA adayı olabilmektedir.

=== 5.3.2. LDA İŞ TANIMLAMA TOPLANTISI ===
Bu toplantı, ihtiyaç makamı/kullanıcı/idame makamı/tedarik makamı ve yüklenici tarafından yönetim kadrosu ve uzmanların katılımıyla gerçekleştirilir. Bu toplantı ile LDA Aday Kalem Listesi, Veri Eleman Listesi, LDA İş Tanımı ve LDA Planı nihai haline getirilerek karşılıklı mutabakat sağlanarak gözden geçirme toplantıları ile ömür devri boyunca dokümanlara ilişkin gerekli çalışmalar yürütülür.

==== <big>5.3.2.1. LDA Aday Kalem Listesi</big> ====
Yükleniciler tarafından taslak olarak hazırlanan ilk aday listesi; LDA İş Tanımlama Toplantılarında müşteri ve yüklenici tarafından değerlendirilmeli ve ilk sürüm Aday Kalem Listesi (AKL) dokümanı, seçim kriterlerini de içerecek şekilde yayımlanmalıdır. AKL dokümanı ürün ömür devri boyunca yaşayan, üzerinde değişikliklerin yapılabildiği bir dokümandır.

LDA İş Tanımlama Toplantısında ürün için yapılacak analiz çalışmalarının da yer aldığı AKL dokümanı önemli bir adım olarak yer almaktadır.

LDA sürecinin yönetilebilmesi için analizlerin ve dokümantasyonun versiyon kodları ile tanımlanması gerekmektedir. Çalışmaların etkinliğinin arttırılabilmesi ve proje kapsamında raporların rahat alınabilmesi için AKL’nin bir lojistik veri tabanına girilmesi faydalı olacaktır.

AKL’de yapılacak bütün değişiklikler yüklenici ve müşteri ile koordineli olarak yapılmalıdır. Böylece her iki tarafta yer alan LDA / ELD yöneticileri LDA sürecini güncel dokümanlar üzerinden takip edebilecek ve sözleşmesel gereksinimlerin karşılanıp karşılanmadığını kontrol edebilecektir.

==== <big>5.3.2.2. LDA Adaylarının Sınıflandırılması</big> ====
Ürün Kırılımında yer alan her malzeme için her analiz çalışmasının yapılması durumu gerek maliyet gerekse iş gücü açısından değerlendirilmelidir. Bu nedenle LDA Adaylarının sınıflandırılması gerekmektedir. Sınıflandırma yapılırken malzemenin durumu, kullanıcı/tedarik makamı ile görüşmeler ve üretici firmanın değerlendirmeleri önem arz etmektedir. LDA adaylarının sınıflandırılmasına yönelik tanımlar aşağıda yer almaktadır:

Tam Aday: Geniş ölçekli LDA verisinin oluşturulması gereken malzemelerdir.

Kısmi Aday: Kısmi ölçekli LDA verisinin oluşturulması gereken malzemelerdir.

Aday Ailesi: Özel gereksinimlere odaklanarak analiz edilecek malzeme gruplarıdır (standart kablolar, vb.). Bu tip malzemeler için belirli analiz çalışmaları yapılmaktadır.

Standart Prosedür Adayı: Standart onarım prosedürleri olan ve kısmi ölçüde analiz çalışmaları yapılması gereken malzemelerdir.

'''<big>5.3.2.2.1. LDA Adayları Seçim Süreci ve Kriterleri</big>'''

LDA adayı seçimi için, Ürün Kırılımında yer alan her malzemenin LDA’nın amaçları açısından değerlendirilmesi gerekir. Değerlendirme sonucu, bir malzemenin seçim kurallarına göre bir aday olduğunu gösterir ise ilgili malzeme LDA adayı olarak belirtilebilir. LDA Adaylarının seçimi için aşağıdaki kriterler ve akış diyagramlarından faydalanılmaktadır.

'''<big>5.3.2.2.2. LDA Adaylarının Seçilmesi, Tanımlanması ve Sınıflandırılması</big>'''

LDA süreci oldukça maliyetli bir süreçtir. Bu nedenle, LDA adaylarının ve ilgili analiz faaliyetlerinin seçilmesi esnasında, LDA sürecinden elde edilen faydalar ile LDA çalışmaları için harcanacak çaba arasında iyi bir denge kurmaya özen gösterilmelidir. Analiz süreçlerinin türüne ve analizin derinliğine göre LDA adayları farklılık gösterebilmektedir.

LDA adaylarının seçilmesi için lojistik açıdan irdelenmiş uygun bir ürün kırılımına ihtiyaç bulunmaktadır. Lojistik kırılımın oluşturulması, LDA süreci boyunca gerçekleştirilecek tüm analizler için yapılması gereken ilk ve temel faaliyettir. Bu sayede analiz edilecek malzemeler de irdelenmiş olacaktır.
[[Dosya:TSSODYP06.05.jpg|alt=|sol|küçükresim|694x694pik|Şekil 5 LDA Adayı Belirlenmesinde Kullanılabilecek Örnek Akış Diyagramı (Yapısal Olmayan Malzeme için) (S3000L)]]

[[Dosya:Şekil 6 LDA Adayı Belirlenmesinde Kullanılabilecek Örnek Akış Diyagramı (Yapısal Malzeme için).jpg|alt=|sol|küçükresim|624x624pik|Şekil 6 LDA Adayı Belirlenmesinde Kullanılabilecek Örnek Akış Diyagramı (Yapısal Malzeme için)]]

LDA adaylarının seçilmesi yöntemlerine geçilmeden önce aşağıda verilen tanımların iyi anlaşılması gerekmektedir.

'''Ürün Kırılımları:'''

LDA Adaylarının seçilebilmesi için ürün kırılımlarının yeterli derinlikte oluşturulmuş olması gerekmektedir. Bu husus incelenmelidir.

'''Mevcut Analiz Sonuçları:'''

Daha önceden yapılmış olan analiz sonuçları LDA adayları seçiminde kullanılabilmektedir. Mevcut/benzer sistemlere ait deneyimler, güvenilirlik verileri ve Hata Türleri Etkileri ve Kritiklik Analizi (FMECA) verileri bu kapsamında kullanılabilir.

'''Aday Seçim Kriterleri:'''

LDA adayları seçimi yapılırken Kullanıcı/Tedarik Makamı ile Yüklenici arasında mutabakat sağlanmalıdır. LDA İş Tanımlama Toplantılarına taslak LDA Aday Kalem Listesi ile başlanmalıdır. LDA adayları seçilirken göz önünde bulundurulabilecek kriterlere örnekler aşağıda verilmiştir:

* Malzemeye tanımlı planlı/plansız bakım görevi ve tanımlanmış bakım seviyeleri (örneğin, malzemenin hatta değiştirilmesi ve/veya kullanıcı tarafından belirlenniş seviyede bakım talebi) olup olmadığı bilgisi,
* Malzemeye özel lojistik gereksinim (Personel, eğitim, test&destek ekipmanı, vb.) ihtiyacı,
* Malzemeye özel prosedür (yıldırım düşmesi sonrası yapılacak işlemler, vb. ) ihtiyacı,
* Hasar sonrası tehlike yaratma ihtimali olan malzemeler,
* Malzemeye tanımlı arıza tespiti ve/veya fonksiyonel test görevleri olup olmadığı,
* Yeni teknoloji kullanan malzemeler,
* Ömürlü malzemeler,
* Potansiyel maliyet arttırıcı malzemeler,

* Uzun onarım zamanı nedeni ile kullanıma hazır olmayı etkileyen malzemeler,
* Kullanıcı özel isteği olan malzemeler,
* Kullanıcı tarafından yazılım yüklenebilen malzemeler,
* Bir LDA adayı malzemeye ulaşmak için sökülmesi/takılması gereken malzemeler,
* Genel görevlere ait verilerin LDA veritabanında bulunması (LDA veritabanında verilerin olması durumunda, benzer koşullarda kullanılıp kullanılmayacağı, yapılacak modifikasyonların kapsamı vb. hususlar değerlendirilmelidir.),
* Farklı bir LDA programından alınan verinin entegrasyonunu gerektiren malzemeler (Farklı bir üreticiden alınan LDA verisinin doğrudan kullanılması veya değişiklikler yapılarak mevcut proje LDA verilerine uyumlu hale getirilmesi gerekiyor ise),
* Lojistik analizleri detaylı olmayan malzeme grupları (kablo, vb.),
* Analiz edilecek ürünün karmaşıklığı.

Ayrıca aşağıdaki koşulların bulunduğu malzemeler potansiyel LDA adayı olarak seçilebilmektedir:

* Potansiyel kullanıma hazır olmayı etkileyen faktörlere sahip malzemeler,
* Potansiyel maliyeti etkileyen malzemeler,
* Potansiyel Bakım/Onarımı etkileyen malzemeler,
* Sözleşmesel LDA gerekleri olan malzemeler.

Yukarıda yer alan bütün kriterler için ölçülebilir eşik değerlerinin olması gerekmektedir. Örneğin, malzemenin hata/arıza sıklığının bakım açısından önemli olup olmadığını belirten MTBF gibi açık eşik değerleri belirtilmelidir.

'''Aday Sınıflandırması'''

LDA adaylarını sınıflandırılırken bazı seçim kriterlerinin göz önünde bulundurulması gerekmektedir. LDA adayları sınıflandırılmasında kullanılabilecek bazı sorular aşağıda verilmiştir;

Aşağıda verilen sorulardan herhangi birine “Evet” cevabı verilmesi durumunda malzeme potansiyel Tam Aday’dır. Eğer soruların hepsine “Hayır” cevabı veriliyor ise malzeme muhtemelen Tam Aday değildir.

''Tam Aday için Sınıflandırma Kriterleri:''

Malzeme yeni geliştirilmiş veya büyük bir modifikasyona uğramış malzeme mi?

* Malzeme HDB mi?
* Onarılabilir malzeme mi?
* Düşük Güvenilirliği olan malzeme mi?
* Bakım/Onarım görevi olan malzeme mi?
* Malzeme için tanımlı bakım/onarım görevi kompleks mi? (uzun süren, personel ihtiyacı fazla olan vb.)
* Bakım/Onarım için gerekli olan özel test&destek ekipmanı var mı?
* Planlı bakım analizi sonrası ortaya çıkan planlı veya önleyici bakım var mı?

Aşağıda verilen sorulardan herhangi birine “Evet” cevabı verilmesi durumunda malzeme potansiyel Kısmi Aday’dır. Eğer soruların hepsine “Hayır” cevabı veriliyor ise malzeme muhtemelen Kısmi Aday değildir.

''Kısmi Aday için Sınıflandırma Kriterleri:''

* Erişim için başka bir malzemenin sökülmesi gerekiyor mu?
* Erişim için sökme işlemi sık mı gerçekleştiriliyor?
* Malzeme bakım, test prosedürleri göz önünde bulundurularak daha önce Tam Aday olarak tanımlanmış mı?
* Temizleme, depolama gibi genel aktiviteleri tanımlanmış donanım harici malzeme mi?

LDA Aday Aileleri tanımı benzer veya aynı malzemelerin gruplanması için kullanılmaktadır. Örnek olarak kablolar verilebilir. Aynı özelliklerde ve aynı/benzer konnektörleri olan kablolar bir Aday Ailesi altında değerlendirilebilir. Aşağıda ''Aday Ailesi için Sınıflandırma Kriterleri'' kapsamında kullanılacak sorular yer almaktadır;

''Aday Ailesi için Sınıflandırma Kriterleri:''

* Malzeme sisteme birden fazla aynı veya benzer yollar ile monte edildi mi?
* Bakım/onarım görevleri aynı veya benzer olan malzemeleri gruplamak mümkün mü?

==== <big>5.3.2.3. LDA İş Tanımı</big> ====
Raporlama, veri elemanları tanımları, veri değişim prosedürleri ve analizleri gerçekleştirmek için kullanılacak yazılım seçimleri gibi faaliyetler hakkında lojistik destek analiz süreci uygulama kurallarını içeren doküman, LDA İş Tanımlama Toplantısının önemli bir çıktısıdır.

Amaçlanan lojistik destek analiz süreci çerçevesinde, ürün tasarımı seçimi, doğrulama ve kontrol ile ilişkili performans verisi konusunda, LDA İş Tanımlama Toplantısı ihtiyaç makamı/kullanıcı/idame makamı/tedarik makamı ve yüklenicinin katılımı ile icra edilmeli ve gerekli noktalara toplantı kararlarında yer verilmelidir.

Tasarım ve desteklenebilirlik gereksinimleri için ilgili bütün önerilerin kontrol listeleriyle değerlendirilmesi sağlanmalıdır. Örneğin;

* LDA ile ilgili ürün tasarım ve performans verisinin tanımlanmış olması,
** Sözleşmesel dokümanlardan çıkarılan LDA verisi ve bilgisi (Çalışma saati başına tanımlı maksimum bakım işçiliği saati, tanımlı maksimum ortalama onarım süresi, çalışma süresi başına maksimum arıza sayısı vb.)
** Ürün kullanım verisinden çıkarılan LDA verisi ve bilgisi (Yıllık operasyon gereksinimleri, operasyon lokasyonları ve her lokasyonda görev alacak sistem sayısı, lokasyonlara göre bakım seviyeleri ve bakım personelleri vb.)
** Tasarım ve performans spesifikasyonlarından çıkarılan LDA verisi ve bilgisi (Tanımlı Arızalar Arası Ortalama Süre (MTBF) değerleri, güvenilirlik gelişimi, test edilebilirlik özellikleri vb.)
** Farklı ürün dokümanlarında geçen ilgili LDA verisi ve bilgisi (Özel çalışma ve/veya onarım kısıtları, teslimat planları, arızaların tehlike sınıfları, depolama kısıtları vb.)
** Seçilen LDA verisi ve sertifikasyon ve doğrulama veya diğer lisanslama amaçlı özel gereksinimlere konu olan bilgiler uygun şekilde not edildi mi? (Versiyon uyumluluğu vb.)

* İlgili değerlerin doğrulanması ile ilişkili kabul kuralları tanımlanması,
** Seçilen veri/bilgi için ölçülebilir hedef değerler tanımlandı mı?
** Seçilen verilere karşı ölçüm figürleri kategorize edildi mi?
** Seçilen veri/bilgi için toleranslar tanımlandı mı?
** Uygulanabilir tazmin kuralları belirlendi mi?
** Belirlenen değerler kullanıcı/tedarik makamı için kabul edilebilir midir?
** Durum bilgisiyle ilişkili kabul sonuçları tanımlandı mı?
** Uygulanabilir ceza ve ödül düzenlemeleri oluşturuldu mu?

* Aşağıdaki konuları etkileyen genel LDA stratejileri ve prensipleri kurulması,
** Tercih edilen bakım konseptinin tanımlanması
** Tedarik zinciri yönetimi destek konseptinin tanımlanması
** Onarımların bakım seviyelerine dağılımı
** Bakım seviyesi onarımları için söz konusu olabilecek sınırlamalar
** Tek kaynak prensiplerinin belirlenmesi
** Ara seviye destek konsepti uygulanabilir mi?
** Hazır alım konseptine ilişkin değerlendirme

==== <big>5.3.2.4. LDA Planı</big> ====
Raporlama, veri elemanları tanımları, veri değişim prosedürleri ve analizleri gerçekleştirmek için kullanılacak yazılım seçimleri gibi faaliyetler hakkında lojistik destek analiz süreci uygulama kurallarını içeren bu doküman, LDA İş Tanımlama Toplantısının önemli bir çıktısıdır. LDA İş Tanımlama Toplantılarında tüm paydaşların katılımı ve mutabakatı ile tasarım desteklenebilirliğini sağlayacak şekilde etkileyen ve uygun lojistik kaynaklarını tespit edilebilmesi için gerçekleştirilecek gerekli LDA faaliyetlerini belirleyen LDA planı oluşturulur.

Md.4.1.4 altında LDA Planı kapsamı genişletilerek ele alınmıştır.

=== 5.3.3. LDA İŞ TANIMLAMA TOPLANTISI ÇIKTILARI ===
LDA İş Tanımlama toplantısı sonucunda; taslak olarak toplantıya sunulan dokümanların nihai hale getirilmesi ile LDA sürecinin performansına ilişkin bağlayıcı anlaşmalar ortaya konulur.

LDA İş Tanımlama Toplantısı çıktı dokümanları aşağıda yer almaktadır:

* LDA adayları listesi
* Veri elemanları listesi
* LDA İş Tanımı
* LDAP

== 5.4. LOJİSTİK DESTEK ANALİZ FAALİYETLERİ ==
LDA ömür devrinin erken aşamalarında uygun seviyede gerçekleştirilecek ön analizlerle maliyet ilişkili kararlara destek olur. Gerekli durumlarda LDA, konsept safhasının başlangıcından itibaren tasarımı lojistik hususlara ilişkin olarak etkilemeli ve bu görev ürünün tüm ömür devri boyunca devam ettirilmelidir.

Tasarım girdileri, güvenilirlik, idame edilebilirlik, test edilebilirlik ya da planlı bakım analizi gibi farklı analiz kaynaklarından sağlanabilir. LDA adaylarına yönelik analiz faaliyetleri, analiz için harcanacak çabanın uygun bir seviyede planlanmasını sağlayacak eşik değerler tanımlanmadığı durumlarda yüksek analiz maliyetlerine yol açabilmektedir. Bu nedenle, analizler için harcanacak çaba ile analizler sonucunda elde edilecek ve yeterli seviyede destek gereksiniminlerini (kullanıcının ihtiyaçlarını ve lojistik destek maliyet kısıtlarını karşılayan) belirlemek için zorunlu olan bilgi arasındaki bir dengenin kurulması gerekir. Bu dengeyi kurabilmek ise, bir dizi ön değerlendirme yapmayı gerektirir. Bu amaçla, yapılacak analizlerle ilgili atama kriter ve kuralları yüklenici tarafından düşünülmeli ve proje ihtiyaçlarını sağlamak üzere uyarlanmış genel esaslar olarak müşteriye sunulmalıdır. Bu değerlendirmenin, hem LDA programının kendisi için harcanak çaba hem de Analiz Edilen Kalemin ömür devri boyunca ortaya çıkacak destek maliyetleri üzerinde etkisi vardır. Dolayısıyla, söz konusu faaliyetin projenin erken safhalarında bir başlangıç değerlendirmesi olarak gerçekleştirilmesi önemlidir.

Bir LDA aday kalemi için uygulanabilir analizleri belirlemekteki temel yaklaşım, analiz için harcanan çabaya kıyasla beklenilen faydanın daha fazla olduğu değerlendirilen analizlerin yapılması şeklinde olmalıdır. Bu değerlendirmeler yapılırken, “öğrenilmiş dersler” vasıtasıyla elde edilen bilgiler hem yüklenici hem de müşteri tarafından dikkate alınmalıdır. Bu şekilde elde edilen bilgiler dikkate alındığında, bazı durumlarda ilave analiz faaliyeti gerçekleştirmeden LDA ilişkili kararların alınması mümkün olabilmektedir.

Uygulanabilir olduğu durumlarda, yeni analiz yöntemlerinin kullanımı da maliyet etkileri ile birlikte değerlendirilmelidir. Örneğin, bir simülasyonun klasik analiz yöntemlerine göre daha kapsayıcı sonuçlar üretmesi mümkündür.

=== 5.4.1. POTANSİYEL ANALİZ FAALİYETLERİ ===
Yapılacak potansiyel analiz faaliyetleri aşağıda verilmiştir, bu analizlerin sonuçları LDA veri tabanı (LDAK) üzerinde dokümante edilmelidir.

1. Genel LDA İhtiyaçlarının Belirlenmesine Yönelik Analiz

2. Karşılaştırmalı Analiz

3. İnsan Faktörü Analizi

4. Konfigürasyon Değerlendirme

5. Güvenilirlik Analizi

6. İdame Edilebilirlik Analizi

7. Test Edilebilirlik Analizi

8. Hata Türleri, Etkileri (ve Kritiklik) Analizi (FMEA/FMECA) Değerlendirmesi

9. Hasar Analizi

10. Özel Olay Analizi

11. Planlı Bakım Analizi

12. Onarım Seviyesi Analizi (OSA)

13. Bakım Görev Analizi (BGA)

14. Yazılım Destek Analizi

15. Lojistik İlişkili Operasyonlar Analizi

16. Eğitim İhtiyaçları Analizi

LDA faaliyetleri kapsamında, her bir analiz sonuçlarının nasıl dokümante edileceği, teslim edileceği ve değerlendirileceği bilgileri LDAP kapsamında ele alınır.

==== <big>5.4.1.1. Genel LDA İhtiyaçlarının Belirlenmesine Yönelik Analiz</big> ====
LDA faaliyetleri için başlangıç noktası herhangi bir görevin/analizin yapılmasına yönelik tanımlanmış ön koşullardır. Bu doğrultuda, kaynakların etkin kullanımı açısından gerçekleştirilmek istenen analizlerin amaçları/gerekçeleri açıkça tanımlanmalıdır.

Genel LDA ihtiyaçlarının belirlenmesi, daha çok sözleşmesel, müşteri ve kullanıcı isterleri ile ilgilidir. Proje için genel LDA ihtiyaçlarının uygun bir şekilde ele alınması ve müşteri ile mutabakatın sağlanması aşamasında aşağıdaki hususlar dikkate alınmalıdır:

* Oluşturulan ürün kullanım verisi (Operasyonel Gereksinimler, Müşteri Gereksinimleri), hedeflenen destek stratejisi ve ilkeleri ile alternatif destek çözümleri,
* Hangi sözleşmesel bilgilerin LDA sonuçları ile gösterilmesi ve geçerli kılınmasının gerektiği, bu geçerli kılmanın nasıl ve hangi derinlikte yapılacağı,
* Özel ilgi alanlarına ilişkin gerekli raporların (örneğin yönetim raporları, program durum gözden geçirmeleri, performans ölçme raporları, doğrulama raporları, vb.) tanımlanması,
* En iyi yatırım geri dönüşünü garanti edecek ödünleşim analiz sonuçları (Örneğin; müşteri talepleri aynı hedefe farklı yöntemlerle ulaşmanın mümkün olup olmayacağı konusunda değerlendirilebilir. Bu değerlendirme neticesinde geliştirilecek alternatif çözümlerin önemli oranda daha az çaba ile gerçekleştirilebileceği de tespit edilebilir. Ancak dikkat edilmesi gereken müşteri gereksinimlerinin kabul edilebilir seviyede karşılanmasıdır.).

==== <big>5.4.1.2. Karşılaştırmalı Analiz</big> ====
Etkin bir LDA programının anahtarlarından biri karşılaştırmalı sistemlerden elde edilen verilerin kullanılması ve analiz edilmesidir. Tarihsel veri gözden geçirme olarak adlandırılan bu süreç, kıyaslanabilecek benzer sistemlerden/ekipmanlardan elde edilen tecrübeye dayalı bilgilerin yeni geliştirilen sistemin desteklenebilirliği ve performansını iyileştirmede kullanılmasını içerir .

Karşılaştırmalı analiz sadece özel bir istek olan durumlarda gerçekleştirilmelidir. Analizin ön koşulu bir ekipmanın, bir sistemin ya da bir son ürünün karşılaştırmalı bilgilerinin mevcut ve karar verme açısından (sadece başlangıç LDA faaliyetlerine yönelik olarak) kullanılabilir olmasıdır. Eğer karşılaştırmalı bir sistem tanımlanabilirse, kullanılabilecek karşılaştırma verilerinin elde edilebilmesi için uygun analizler yapılabilir. Analiz sonuçlarının dokümante edilmesi için karşılaştırma faktörlerini ve verilerini ve/veya karşılaştırılabilir LDA adaylarına ilişkin destek çözümlerini ele alan özel özet raporlar hazırlanabilir.

Karşılaştırmalı sistem ve alt sistemlerin belirlenmesi, yeni sistemin/ekipmanın tasarımı, operasyonel ve destek karakteristikleri ile tahmin edilecek parametreye dair bilgi sahibi olmayı gerektirir. Eğer tasarım parametreleri (ör; güvenilirlik, idame edilebilirlik) tahmin edilecekse, tasarım karakteristikleri yeni sisteme/ekipmana benzer olan operasyonel sistemler/ekipmanlar seçilmelidir. Yeni sistem için ana alt sistemler belirlendiğinde, tasarım parametrelerinin tahmini için kullanılacak ana hat karşılaştırma sistemi, birden fazla sistemin alt sistemlerinden oluşan kompozit bir sistem olabilir. Destek parametreleri (ikmal süresi, dönüş süreleri, ulaştırma süreleri, personel kısıtları vb) tahmin edileceği zaman ise, yeni sistemin/ekipmanın destek konseptine benzer mevcut sistemler (destek sistemleri) belirlenmelidir. Seçilen destek sistemi, tasarım karakteristiği açısından benzer olan sistemleri/ekipmanları destekleyen sistemlerden tamamen farklı bir destek sistemi de olabilir.

Gerçekçi bir karşılaştırmalı sistem tespit edilebilirse bu sisteme ilişkin bilgiler aşağıdaki hususların belirlenmesinde yardımcı olur:

a. Yüksek hata oranı potansiyeline sahip alt sistem ve komponentler

b. Gayri Faal Süresine etki eden temel unsurlar

c. Desteklenebilirliği geliştiren tasarım özellikleri

d. Potansiyel desteklenebilirlik problem alanları

e. Potansiyel emniyet veya insan faktörü etkileri içeren tasarım konseptleri

f. Destek kaynaklarına dair gereksinimler

g. Ürün destek gereksinimlerini, kullanım ve destek maliyetlerini ve sistemlerin erişilen göreve hazır olma seviyelerini etkileyen tasarım, operasyon ve destek konseptleri.

Bu faaliyetin ilk sonuçları, operasyonel gereksinimler ve müşteri gereksinimleri dahil desteklenebilirlik faktörlerini geliştirmek için kullanılır. İleriki safahalarda gerçekleştirilen karşılatırmalı analiz sonuçları da bu dokümanlara dahil edilir. Analiz sonuçları aynı zamanda ürün destek modeli belirlenirken girdi olarak kullanılabilir.

==== <big>5.4.1.3. İnsan Faktörü (Ergonomi) Analizi</big> ====
Bir ürüne ilişkin potansiyel destek çözümlerinin, insan faktörü gereksinimleri dahil, belirlenmiş eşik değerlerinin içerisinde olmasını sağlayabilmek için LDA, idame edilebilirlik ve desteklenebilirlik işlevleri sıkı şekilde koordine edilmelidir. İnsan faktörlerinin özellikle operasyonel ve bakım faaliyetlerinin uygulanabilirliği konusunda belirleyici etkisi vardır.

İnsan faktörü analizleri, diğer desteklenebilirlik mühendisliği fonksiyonları gibi, bakım ekibi ve destek ekipmanı gereksinimlerinin belirlenmesi çalışmalarına kaynak veri sağlar. Bu ilişki, tasarım gözden geçirme sürecinde başlar ve bakım görev analizlerinin geliştirilmesi süreci boyunca devam eder.

İnsan faktörü analizlerinin, Bakım Görev Analizi (BGA)’ne tabi tutulan LDA adayları üzerinde etkisi olabilmektedir. İnsan faktörleri, özel sınırlamalar (örneğin, özel yetenekler gerektiren bakım görevlerinin uygulanabilirliği ile ilgili) için bir gerekçe teşkil edebilir. Bu analizler esnasında hem ergonomik hususların hem de uygun bir insan-makine ara yüzüne yönelik tanımlanmış kuralların göz önünde bulundurulması gereklidir. LDA faaliyetleri üzerinde belirleyici etkileri olabilecek bazı hususlar aşağıda örneklendirilmiştir:

* Ağır yükleri kaldırma ve taşıma becerisi
* Özel koşullarda uzun bir süre hareket etme becerisi
* Tehlikeli malzemelerin elleçlemesi
* Personel istihdamında yasal sınırlamalar (güvenlik kısıtlamaları, vb)

İnsan faktörü analizi sonuçları, projenin mümkün olan en erken safhalarında dokümante edilmeli ve ilgili tüm dokümanlara girdi yapılmalıdır. İnsan faktörlerinin etkileri, LDA veri tabanı içerisinde farklı alanlarda yer alabilir. Tasarıma yönelik her değişiklik önerisi veya modifikasyon, bakımda da değişikliklere yol açar ve bu da insan faktörü kısıt ve sınırlamalarının gözden geçirilmesini gerektirir. Ömür devrinin sonunda, envanterden çıkarma safhasında, insan faktörleri yine kritik öneme sahip hale gelir. Zira bu safhada, insan sağlığı üzerinde etkisi olan malzemelerin ele alınması ihtiyacı doğabilmektedir.

EK-A, insan faktörü mühendisliği ile lojistik destek analizi süreci arasındaki ilişki ve entegrasyonu tanımlamaktadır.

==== <big>5.4.1.4. Konfigürasyon Değerlendirme</big> ====
Herhangi bir LDA adayı için tasarım konfigürasyonundan önemli ölçülerde sapma olması durumunda, konfigürasyon değerlendirmesi zorunludur. Ürünün geçerli kılınmasına ilişkin potansiyel değişiklikler, mühendislik değişiklikleri, sapmalar veya feragatler incelenmelidir. Konfigürasyon değerlendirmeleri, sapma gösteren bakım konsepti ve/veya lojistik destek gereksinim (personel, malzeme gibi) ihtiyacının genel değerlendirmesi şeklinde yapılmalı ve LDA adayları için analiz ihtiyaçları yeniden değerlendirilmelidir.

==== <big>5.4.1.5. Güvenilirlik Analizlerinin Değerlendirilmesi</big> ====
LDA adaylarının hedeflenen kullanım senaryoları ile ilişkili güvenilirlik tahminlerinin (örneğin MTBF), LDA çalışmaları kapsamında kullanımları değerlendirilmelidir. Güvenilirlik değerlerinin belirlenmesi tasarım ve geliştirme ile ilgili bir görevdir. Ancak bu analizlerin sonuçlarının dokümante edilmesi LDA için son derece önemlidir. Genel olarak, her bir donanım LDA adayı için güvenilirlik analizinin yapılması zorunlu kabul edilir. Buna ek olarak, güvenilirlik tahminlerinin LDA ürün kırılımında yer alan bütün gerekli elemanlara yönelik olarak genişletilmesi ve bu değerlerin bütün diğer ürün kırılımı arasında da tutarlılığının sağlanması önemlidir.

Güvenilirlik değerleri, Hata Türleri ve Etkileri Analizi (HTEA)’nin sonuçları içerisinde bir LDA adayı kalemin farklı hata türlerine ait hata oranları ile doğrudan ilişkilidir. Bu iki alan lojistik veri tabanı üzerinde tutarlı olmalıdır.

==== <big>5.4.1.6. İdame Edilebilirlik Analizi</big> ====
İdame edilebilirlik belirlenmiş prosedür ve kaynaklar kullanılarak, tanımlı bakım onarım seviyelerinde belirlenmiş yeteneğe sahip personel tarafından bakım faaliyeti gerçekleştirildiğinde, odak sistemin öngörülen performans seviyesinde tutulabilmesi veya öngörülen performans seviyesinde tekrar çalışır duruma geri getirilebilmesi kabiliyetinin ölçüsüdür.

Her bir LDA adayı için, teknik açıdan desteklenebilir olup olmadığına karar verebilmek üzere idame edilebilirlik analizinin yapılması önemlidir. Uygulanabilir olduğu durumlarda aşağıdaki konuları ele alan idame edilebilirlik analizleri gerçekleştirilmelidir:

* Müşteri gereksinimlerini yansıtan idame edilebilirlik özelliklerinin değerlendirilmesi,
* Uygulanabilir her LDA adayı kalem için bakım konseptini desteklemek amacıyla farklı seviyelerdeki bakım görevlerinin belirlenmesi,
* Farklı desteklenebilirlik açılarının araştırılması (nihai ürünün modüler tasarıma sahip olması, erişilebilirlik kolaylığı, özel bölgelerde yerleşim konsepti- MTBF değeri en kötü olan parçaların diğer parçaların arkasına gelecek şekilde yerleştirilmemesi- gibi).

Genelde, idame edilebilirlik analizi farklı detay seviyelerinde aşağıda sıralanan uygulamalarla gerçekleştirilebilir:

* Mevcut bilgilerin en düşük seviyede olduğu durumlarda, En İyi Mühendislik Kararlarının kullanılması,
* Ekipman tedarikçileri kaynaklı bilgilerin veri dönüşümü ile veya dönüşüm gerektirmeden değerlendirilmesi,
* AAK için bakım konsepti oluşturulurken; alternatiflerin kıyaslanmasında Onarım Seviyesi Analizi (OSA) ve/veya Önleyici Bakım Analizi, Planlı Bakım Analizi gibi destekleyici analizlerin dikkate alınması,
* Operasyonel profillere göre görevini gerçekleştiren ürünler için, bakım ve desteğe odaklanarak sınırlı bakım kaynakları ya da operasyonel profillerin değişmesi gibi durumların olası sonuçlarını değerlendiren simülasyon araçlarının kullanımı.

Farklı kalem tiplerine göre uygulanacak idame edilebilirlik analizinin seviyesi Tablo 5’de belirtilmiştir.

'''Tablo 5 Kalem Türüne Bağlı Olarak İdame Edilebilirlik Analizi Derinliği'''
{| class="wikitable"
|'''Analiz Edilen Kalemler'''
|'''İdame Edilebilirlik Analiz Derinliği'''
|-
|Halen karşılaştırılabilir koşullarda kullanılmakta olan kalemler.
|Orta seviye bilgi ve veri dönüşümü ihtiyacı vardır. Daha detaylı idame edilebilirlik analizi isteğe bağlı olarak yapılabilir.
|-
|Halen kullanımda olmakla birlikte, karşılaştırılabilir koşullar altında kullanılmayan kalemler.
|Dikkatli veri dönüşümü gereklidir, yeni koşullara göre daha detaylı bir idame edilebilirlik analizi yapılması gerekebilecektir.
|-
|Büyük modifikasyon olmadan kullanılabilecek RAHAT kalemler.
|Lojistik özellikler ve/veya gereksinimlere ilişkin uygunsuzlukların dokümante edilmesi ve müşteri tarafından kabul edilmesi gereklidir.
|-
|Hazır bulunan ve minör değişiklikler gerektiren kalemler.
|Orta seviye bilgi ve veri dönüşümü ihtiyacı vardır, daha detaylı idame edilebilirlik analizi isteğe bağlı olarak yapılabilir.
|-
|Hazır bulunan ve majör değişiklikler gerektiren kalemler.
|Dikkatli veri dönüşümü gereklidir, yeni koşullara göre daha detaylı bir idame edilebilirlik analizi yapılması önemlidir.
|-
|İyi bilinen bir teknolojiye bağlı olarak yeni geliştirilen kalemler.
|Detaylı idame edilebilirlik analizinin yapılması gerekir.
|-
|Yeni bir teknolojiye bağlı olarak yeni geliştirilen kalemler.
|Detaylı idame edilebilirlik analizi mutlaka yapılmalıdır.
|}
İdame edilebilirlik analiz sonuçları dikkatli bir şekilde dokümante edilmeli ve analiz sonucunda ortaya çıkan bakım konsepti ile ilişkili veriler lojistik veri tabanına kayıt edilmelidir.

==== <big>5.4.1.7. Test Edilebilirlik Analizi</big> ====
Test edilebilirlik analizi için gerekli olan girdiler;

* İdame edilebilirlik stratejisinin tanımlanması
* Tüm test mimarisinin ve test prensiplerinin tanımlanması
* Sözleşmesel test edilebilirlik gereksinimlerinin tanımlanması ve doğrulanması
* FMEA/FMECA dokümanlarında geçen test edilebilirlik ile ilişkili bilgilerin değerlendirilmesi
* İlişkili tüm seviyelerde gereksinimlerin fonksiyonel kontrolünün tanımlanması
* İlişkili lojistik kaynak gereksinimlerinin (personel, yüklenebilir yazılım, test yazılımı gibi) tanımlanması

Test edilebilirlik analizi, idame edilebilirlik analizi ile yakından ilişkilidir. Test edilebilirlik analizi sonuçları idame edilebilirlik analizlerini doğrudan etkiler. Kalemin test özelliğine ilişkin herhangi bir düzeltici bakım, düzeltilecek hatanın fark edilebilmesine bağlıdır. Bir hata herhangi bir test prosedürüyle doğrulanamazsa, ilgili onarım görevi gerçekleştirilemez. Tüm bunlara ilave olarak, bir kalemin onarım sonrası da fonksiyonelliğinin test edilmesi gereklidir. Arıza fark etme/doğrulamanın detay seviyesi, bakım konseptini etkileyen en önemli etkendir.

Test edilebilirlik özelliklerinin tasarım tamamlandıktan sonra belirlenmesi neredeyse imkânsızdır. Bu nedenle, test edilebilirlik gereksinimleri uygulanabilir her kalem için geliştirme safhasında tanımlanmalıdır.

Cihaz İçi Test (CIT) yeteneği olan tüm kalemler için test edilebilirlik analizi zorunludur. İlişkili test edilebilirlik özellikleri tanımlanmalı ve dokümante edilmelidir. Bir şekilde tüm test mimarisinde gözlenen indirgenmiş (reduced) CIT yeteneğine sahip kalemler için (RAHAT kalemler gibi) test edilebilirlik analizinin yapılması önemlidir.

Test edilebilirlik özellikleri ile ilgili veri tipleri lojistik veri tabanında ya da test edilebilirlik raporlarında dokümante edilmelidir. Üreticiler için test edilebilirlik özelliklerinin ne şekilde uygulanacağına ilişkin kuralların tanımlanması ve doğrulanması gereklidir.

==== <big>5.4.1.8. Olaya Dayalı Bakıma İlişkin Analiz Faaliyetleri</big> ====
'''<big>5.4.1.8.1. Hata Türleri Etkileri ve Kritiklik Analizi/Hata Türleri Etkileri Analizi (HTEKA/HTEA)</big>'''

HTEKA’nın amacı, bir ürünün potansiyel hata durumlarını tanımlamaktır. Hata durumlarının kritikliğinin hesaba katılmadığı durumda, yapılan analiz faaliyeti HTEA olarak adlandırılır. Fonksiyonel hatalar sistem HTEKA’sı yapılarak tanımlanır/analiz edilir, teknik hatalar ise alt sistem HTEKA yaklaşımı ile tanımlanır/analiz edilir.

'''Sistem Hata Türleri Etkileri ve Kritiklik Analizi (HTEKA)'''

Sistem HTEKA’sı yukarıdan aşağıya yaklaşımını kullanarak, Ürünün farklı sistemlerini analiz eder. Bu amaçla, potansiyel fonksiyonel hatalar, bu hataların etkileri, kritikliği, son etkisi ve hata sebepleri belirlenir.

Emniyet, yasal ya da çevre bütünlüğünden dolayı kritik olduğu tespit edilen potansiyel hata etkilerinin önlenmesi zorunludur. Operasyonel/görev ilişkili ya da ekonomik sebeplerden dolayı istenmeyen diğer hata etkileri de önlenmelidir. Analiz sonuçları, önleyici bakım (planlı bakım) ve düzeltici bakım faaliyetlerinin tanımlanması için ya da yeniden tasarım gereksinimleri için ana çizgiyi oluşturacaktır.

'''Alt -Sistem Hata türleri Etkileri ve Kritiklik Analizi (HTEKA)'''

Alt sistem HTEKA’sı, üründe bulunan herhangi bir alt sistemde meydana gelebilecek teknik hataların olasılığını ve sonucunu tanımlayacak detayda aşağıdan yukarıya yaklaşımı ile gerçekleştirilir.

Emniyet analizi faaliyetleri (örneğin hata ağacı analizi) sistem ve alt sistem HTEKA’sına bağlıdır. Hata ağaçlarında, emniyet kritik hata kombinasyonları da tanımlanabilir. Hataların gerçekleşme olasılık seviyelerine bağlı olarak, yeniden tasarım, düzeltici bakım (onarım ya da yenisi ile değişim gibi) ve/veya önleyici (planlı) bakım gereksinimleri tanımlanmalıdır.

'''<big>5.4.1.8.2. Hasar Analizi</big>'''

Hasara elverişli bileşenler, en azından kısmi LDA adayı kalemi olarak değerlendirilmelidir. Genelde hasarlar, her bir durum için kritikliğinin ya da derecesinin önceden belirlenemeyeceği özel olaylardır. Yine de aynı yolla meydana gelebilen ya da aynı yolla tespit edilebilen hasar sınıflarının tanımlanması yararlı olacaktır. Analiz sonuçları, lojistik veri tabanında dokümante edilmelidir (örneğin yapısal elemanlar için test ve onarım prosedürlerinin veri tabanında belirtilmesi gibi). Hasarlarla ilgili güvenilirlik değerleri normalde mevcut değildir. Yalnızca, istatistiksel değerlendirmelerin yardımıyla bir tahminde bulunmak mümkün olabilir.

<big>'''5.4.1.8.3. Özel Olay Analizi'''</big>

Özel olayın bir türü olarak hasarlar dışında, başka diğer olayların da AAK’nin ya da ürünün bakım konseptine etkisi olabilir. Fonksiyonelliğini garanti etmek için özel bakım uygulamaları gerektiren, olası özel olayların tanımlanması ve dokümante edilmesi önemlidir. Ayrıca, gerekli bakım uygulamalarının ve personel, malzeme, yazılım gibi gerekli kaynaklarla ilişkili bilgilerin tanımlanmış ve dokümante edilmiş olması gereklidir.

Bakım uygulaması gerektiren bazı özel olay örnekleri;

* Sıcaklık limitlerinin aşılması
* Mekanik yükleme limitlerinin aşılması (örneğin aşırı torklama)
* İzin verilen hız limitlerinin aşılması
* Tuz yüklü atmosferde operasyonel kullanım
* Kumlu ortamda kullanım
* Yıldırım
* Uçaktan zor iniş
* Harici nesnelerle çarpışma
* Sert İniş (Hava Araçları)

==== <big>5.4.1.9. Planlı Bakım Analizi</big> ====
Planlı Bakım Analizi (Scheduled Maintenance Analysis), emniyet ilişkili, büyük ölçüde ekonomik ve ekolojik hataları önlemek için yapılır. Emniyet kritik bir durum varsa analizin yapılması zorunludur. Beklenen önemli ekonomik ya da ekolojik dezavantajlar varsa analizin tekrar yapılması gerekir. Analiz sonuçları bakım konseptini doğrudan etkiler. Planlı bakım uygulamalarının lojistik veri tabanı üzerinde mutlaka dokümante edilmesi gerekir.

==== <big>5.4.1.10. Onarım Seviyesi Analizi (OSA)</big> ====
Genel destek stratejisine bağlı olarak, her bir kalem için bakım ve/veya onarımının hangi seviyede yapılacağına karar verilmesi gereklidir. Bu kararı desteklemek için analiz edilecek LDA adayı kalemin tipine bağlı olarak birkaç yöntemden birisi uygulanarak OSA gerçekleştirilir.

'''Tablo 6 OSA’nın Farklı Derinliklerinin Sınıflandırılması'''
{| class="wikitable"
|'''OSA Sınıflandırması'''
|'''Tanım'''
|-
|Basitleştirilmiş OSA
|Mevcut en iyi bilgiler göz önünde bulundurularak en iyi mühendislik yaklaşımının temellerinden elde edilebilir. Sonuçların mutlaka dokümante edilmesi gerekir.
|-
|Tam OSA
|Bu kapsamlı analizin yapılabilmesi için kalemin kendisiyle ve kullanım içeriği ile ilişkili olarak gerekli tüm verinin (örneğin; operasyonel senaryolar, yedek parça tedariki, maliyet gibi) olması gereklidir.
|-
|Simülasyon Üzerinden Analiz
|AAK bu kalemin intikal ve operasyonel senaryoları ile ilgili oldukça detaylı bilgileri hesaba katan bir simülasyon en iyi OSA sonuçlarını oluşturabilir. Bu durum simülasyon için yazılım paketinde kullanılacak uygun formattaki tam bir bilgi/veri setini gerektirir. Bu bilgi/veri setini hazırlamak ilave çabaya sebep olabileceğinden bu durumun da ayrıca değerlendirilmesi gerekecektir.
|}
Her durumda, uygulanabilir olduğu ölçüde OSA yapılması zorunlu bir analizdir.

==== <big>5.4.1.11. Bakım Görev Analizi (BGA)</big> ====
Bakım Görev Analizi, LDA sürecindeki merkezi analiz faaliyetlerinden birisidir. Burada, tanımlanmış bakım görevleri (hem planlı hem plansız) mevcut olan gerekli tüm bilgilerle aşağıdaki gibi detaylandırılır.

* İlgili bakım görevinin yerine getirilebilmesi, eğitim gereksinimleri ve kritik görevler için ön koşulların ne olduğu gibi genel görev bilgilerinin dokümante edilmesi,
* Bakım görevlerinin tanımlı olaylara (arızalar, hasarlar, özel olaylar, zaman kısıtlamaları gibi) atanması,
* İlgili lojistik kaynak gereksinimlerinin (personel, destek ekipmanı, yedek parçalar, alt yapı, yazılım gibi) tanımlanması,
* Görev sıklığının hesaplanması,
* Tanımlanmış görevden önce ve sonra yapılması gerekli olan görevler.

==== <big>5.4.1.12. Yazılım Destek Analizi</big> ====
Kullanıcı tarafından yüklenebilir veri/yazılım içeren her bir kalem aşağıdaki hususlar kapsamında analiz edilmelidir. Bu analiz, bakım ve hizmet görevlerini kapsar.

* Kullanıcı tarafından yüklenebilir yazılım/veri içeren donanım bakımı
* Kullanım hazırlığı için gereken veri ve/veya operasyonel yazılım
* Kullanıcı tarafından yüklenebilir yazılım sürümleri ile birlikte kalemin/birimin revizyonunun güncellenmesi için verilecek yazılım desteği

Yazılım Destek Analiz programı yazılım değişikliklerini, sürümleri ve yazılımda bir virüs (bug) olması durumunda yazılımın bakımını yönetecekse, oluşturulacak süreç donanım için olan LDA süreci ile aynı çizgide olmalıdır.

==== <big>5.4.1.13. Lojistik İlişkili Operasyonlar Analizi</big> ====
Bir ürünün kullanımı ve bakımına ilişkin görevlerin yanısıra, operasyon açısından dikkate alınması gereken bazı ilave hususlar vardır. Bazı durumlarda doğrudan ürünün kullanımıyla veya bakımıyla ilişkilendirilemeyen görevler söz konusu olabilir. Ancak bu görevler, operasyon ve bakım tesislerinde normal operasyonlara destek olarak yürütülür (ör; paketleme, elleçleme, depolama, ulaştırma, demirleme gibi).

Bu görevler ürünün doğru kullanımı açısından son derece önemlidir. Lojistik ilişkili operasyonel görevler olarak nitelendirilebilecek bu görevler, operasyonları çeşitli açılardan kısıtlayabilirler (kullanım kolaylığı, kullanılabilirlik, kullanım esnekliği, mobilite gibi). Bu doğrultuda Analiz Altındaki Sistemin (AAS) genel kullanımı için önemli olan görevlerin tanımlanabilmesi amacıyla operasyonel gereksinimler analiz edilmelidir ve bu görevler lojistik veri tabanında dokümante edilmelidir.

==== <big>5.4.1.14. Eğitim İhtiyaçları Analizi (EİA)</big> ====
Bu analiz kapsamında, belirli bir görevin özel bir eğitim gerektirip gerektirmediğine karar verilir. Eğitim gerekli ise, eğitimin etkili bir şekilde nasıl uygulanabileceği belirlenmelidir. Bu süreç, belirlenen görevlere ilişkin LDA veri tabanında yer alan içerikten faydalanarak desteklenebilir.

Eğitim gereksinimlerine yönelik kriterler LDA İş Tanımlama Toplantısı esnasında Yüklenici ve Müşteri arasında görüşülmeli ve uyumlu hale getirilmelidir. Belirlenen kriterler LDA veri tabanına aktarılmalı ve her bir görev bu kriterlere göre değerlendirilmelidir. Elde edilen sonuç, LDA veri tabanında yer alan görevlere dair mevcut verilere dayalı bir ön Eğitim İhtiyaçları Analizi kararı olabilir.

==== <big>5.4.1.15. Envanterden Çıkarma Analizi</big> ====
Bir sistemin faydalı ömrü sona erdiğinde, emniyet (patlayıcı emniyeti dahil), güvenlik ve çevreye dair hukuki ve düzenleyici gereksinimlere uygun olarak envanterden çıkarılması gerekir. Tasarım süreci boyunca, sistemde yer alan tehlikeli maddeler dokümante edilmeli ve sistemin emniyetli bir şekilde bertaraf edilmesi planlanmalıdır.

Bu analizlerin amacı sistem/birim ve ilişkili tesis ekipmanları için envanterden çıkarma prosedürlerinin belirlenmesidir. Bu amaçla, komponent, komple, tali komple, parça ve malzemelerden tehlikeli madde, atık ve çevre kirletici madde içerebilecek olanlar ile yeniden işlenebilecek, yeniden kullanılabilecek veya kurtarılabilecek malzemeler belirlenir.

Malzemelerin envanterden çıkarma prosedürlerinin belirlenmesi ve dokümante edilmesi gerekir. Bu faaliyetin gerçekleştirilmemesi, ürün işletimi ve idamesinde görev yapan personelin sağlık ve emniyetini etkileyebilir. Ekipman veya komponentlerin demilitarize edilmesi, ulusal güvenlik açısından önemli bir konu olup gizli verilerin tehlikeye atılmasının önlenmesi gerekir.

Komponent, komple, tali komple, parça ve malzemelerin envanterden çıkarılmasına yönelik detaylı prosedürlerin oluşturulmasından yüklenici, bütün olarak sistem/ekipmanın envanterden çıkarılması/demilitarize edilmesinden ise ihtiyaç makamı/kullanıcı/idame makamı sorumludur.

== 5.5. MÜŞTERİNİN LDA PROGRAMINA KATILIMI ==
LDA sürecine dair yüklenici’nin yorum ve yaklaşımının müşterininkiyle aynı doğrultuda olduğunu garanti altına almak için müşteri tüm LDA programı boyunca uygun derinlikte sürece dahil olmalıdır.

=== 5.5.1. MÜŞTERİNİN ADAY KALEMLERİ DEĞERLENDİRMESİ VE TAVSİYE EDİLEN ANALİZ AKTİVİTELERİ ===
LDA adaylarının seçimi ve bu aday kalemlere uygun analiz aktivitelerinin atanması, LDA sürecinde maliyeti önemli ölçüde etkileyen husustur. Bu sebeple, LDA adaylarının seçimi projenin erken aşamalarında büyük bir özenle yapılmalıdır. Riski azaltmak için, uygulanabilir olması durumunda sözleşmenin imzalanmasından önce taslak aday kalem listesi hazırlanmalıdır.

==== <big>5.5.1.1. LDA Süreci Değerlendirme Kurallarının Konulması</big> ====

==== Değerlendirme kuralları yüklenici ve müşterinin ortak kararı ile belirlenmelidir. Değerlendirme kurallarının belirlenmesi için en az aşağıdakileri içerecek şekilde bazı genel kurallar koyulmalıdır: ====
Yalnızca LDA GGT’de anlaşılan kuralları içeren hususlar veya müşteri ile yüklenici arasında anlaşılan gelecek LDA süreci içerisindeki (ör. LDA gözden geçirmeleri) kurallar dikkate alınmalıdır.

Eğer bir değerlendirme gerçekleştirilmiş ve başarılı olarak sonuçlanmışsa, doğrudan ilgili yeni bir husus olmadığında aynı konu tekrar değerlendirilmemelidir.

* Yalnızca LDA ile ilişkili kurallar değerlendirmeye alınmalıdır.
* Diğer hususlar (ör. teknik dokümantasyon, ikmal desteği, eğitim vb.) LDA değerlendirme kuralları kapsamına alınmamalıdır.
* Müşteri veya yüklenici kadrosunda oluşan bir değişiklik daha önce karar alınmış değerlendirmeleri etkilememelidir.
* LDA teslimatlarının yayımlanması ile bu teslimatlara verilecek görüşler için cevapların oluşturulması süreleri arasında geçecek zaman için sınır kuralları koyulmalıdır.
* Yüklenicinin LDA teslimatlarının içerisindeki detay değerlendirme daveti ve değerlendirme sonuçları uygun kodlar kullanılarak bir durum kodu ile belirtilmelidir.
* Bilgilerin detayları, yapısı ve kullanılacak kodlar müşteriyle de koordine edilmek suretiyle yüklenicinin sorumluluğunda olmalıdır.
* LDA gözden geçirme yapısı durum kodu tarafından temsil edilen bilgi grubu doğrultusunda organize edilmelidir.
* Durum kodu için lojistik veri tabanı içerisinde uygun veri elemanı tanımlanmalıdır.
* Her LDA adayını ilgilendiren durum kodu lojistik veri tabanında uygulanabilir olarak güncel tutulmalıdır.

Değerlendirme sonuçları dokümante edilmeli ve belirlenmiş değerlendirme prosedürüne uygun olarak yükleniciye gönderilmeli ve tüm konular açıklığa kavuşana kadar takip edilmelidir.

Ürün kırılımının özellikle yapısı, içeriği ve derinliğinin uygunluğu, LDA aday kalem seçim kriterlerinin net bir şekilde tanımlanmış olması ve bu kalemler için yapılacak analiz faaliyetlerinin seçim kriterlerinin uygunluğu müşteri tarafından ilk değerlendirme kapsamında değerlendirilmeli ve görüşler yükleniciye iletilmelidir. Bu aşamadan sonra yapılacak değerlendirmeler, yüklenici tarafından yapılan her bir teslimat kapsamında olacaktır. Proje LDA programına göre uyarlanarak yüklenici tarafından hazırlanan dokümanların nasıl iletileceği, görüşlerin/yorumların nasıl hazırlanacağı, ilgili görüş/yorumların değerlendirme süreci, üzerinde mutabakatın sağlanması gibi tüm aşamaları içeren değerlendirme süreci (yorum verme süreci de içeren) dokümante edilmeli ve LDAP kapsamında tanımlanan sürece uygun olarak tanımlanmalıdır. Müşteri, LDA sürecinde ilerleme sağlayabilmek için yaptığı değerlendirmeleri, özellikle mutabık kalınan/kalınmayan noktaları ve mutabık kalınmayan hususlarda açıklamalarını yükleniciye resmi olarak aktarmalıdır. Tüm LDA çıktıları konfigürasyon yönetim ilkelerine göre kayıt altına alınmalıdır. Ayrıca, müşteri tarafından verilen görüş/yorumlar, bunlara oluşturulan cevaplar ve son durumun da kayıt altına alınması izlenebilirlik açısından gereklidir.

Şekil 7’de müşteri ve yüklenici arasındaki bilgi alışverişi için örnek bir süreç gösterilmiştir. Tablo 7’de ise zaman aralıkları hakkında açıklamalar verilmiştir.
[[Dosya:TSSODYP06.07.jpg|alt=|sol|küçükresim|645x645pik|Şekil 7 Müşteri İle Yüklenici Arasındaki Veri Alışverişi Süreci (Örnek)]]

'''Tablo 7 Yorumlama Sürecinin ZamanTakvimi ile Açıklanması'''
{| class="wikitable"
|'''Zaman'''
|'''Eylemler'''
|-
|Sözleşme T0+…
|Yüklenici tarafından LDA teslimat kalemlerinin hazırlanmasına başlanması.
|-
|T1
|Sözleşmesel LDA teslimat kalemlerinin müşteriye anlaşılan formatta teslim edilmesi
|-
|T2
|T2 ve T1 arasında müşterinin teslim edilen kalemler üzerinde (LDA verisi, LDA raporları) yorum verme süreci gerçekleşecektir. T2 için anlaşılan zamanda yorumların yükleniciye iletilmesi gerçekleşecektir.
|-
|T3
|LDA gözden geçirme eforunun azaltılması için, kolayca cevaplanacak her tipte yorumlar LDA gözden geçirme öncesinde eğer mümkünse yüklenici tarafından ele alınmalıdır. Bununla beraber, müşterinin yorumlarıyla ilgili her karar dikkatlice dokümante edilmelidir.

Bu süreçte, birden fazla soru-cevap döngüsü özel soruları detaylıca açıklayabilir, fakat döngü sayısı, daha fazla kapsamlı soruların netleştirilmesi gerektiğinden sınırlandırılmalıdır. (ör. LDA gözden geçirmesinde veya yüklenici ve müşteri arasındaki daha uzun netleştirme süreci)
|-
|T4
|T2 ve T4 arasındaki zamanda, müşteri ve yüklenici arasındaki netleştirme döngülerini dikkate alarak, kalan müşteri yorumları yükleniciye teslim edilecektir. Bu yorumlar LDA gözden geçirmesindeki netleştirme ve tartışmalar için temel oluşturacaktır.
|-
|TGözden Geçirme
|LDA gözden geçirme zamanı. LDA gözden geçirmesindeki her kararın karşılık gelen durum bilgisi güncellemesi ile birlikte dokümante edildiğinden emin olunmalıdır.
|}
Müşteri ile gerçekleştirilecek analiz verilerinin değişimi hususunda uygulanması gereken adımlar LDAP kapsamında ele alınacaktır:

* Veri ve doküman değişimi için uygun kuralların koyulması (bkz: 5.5.1.2)
* Yüklenici tarafından LDA veri ve dokümanların toplanması (bkz: 5.5.1.3)
* Yüklenici tarafından LDA veri/dokümanlarının teslimatı (bkz: 5.5.1.4)
* Müşteri değerlendirmesi ve değerlendirme sonuçlarının dağıtımı (bkz: 5.5.1.5)
* Yüklenici tarafından müşteri cevaplarının dağıtımı (bkz: 5.5.1.6)
* Anlaşılmayan yorumlarla ilişkili yüklenici cevaplarının dağıtılması (bkz: 5.5.1.7)

==== <big>5.5.1.2. Veri ve doküman değişimi için uygun kuralların koyulması</big> ====
Uygun anlaşmalar ve kurallar LDA GGT’de ve devamındaki LDA anlaşmalarında müşteri ile yüklenici arasında dokümante edilip üzerinde anlaşılmalıdır. Örneğin:

* Kullanılan yazılımlar,
* Veri ve rapor formatları (ör. Dex-formatı),
* Periyodiklik,
* Teslimat ve cevap süreleri,
* Dağıtım paydaşları ve uyulması gereken akış.

==== <big>5.5.1.3. Yüklenici tarafından LDA veri ve dokümanlarının toplanması</big> ====
Müşteri ve yüklenicinin arasında yapılan LDA GGT ve sonrasında yapılan LDA anlaşmaları mutabakatla dokümante edilmelidir. Bu dokümantasyon en az aşağıdaki hususları içermelidir:

* Uygun veri/doküman değişiminin ve endüstri içindeki veri/doküman paylaşım ağının kurulması,
* İş ilişkisinde bulunulan firmalar ve LDA ile ilişkili disiplinler arasında istenen teslimatlar için veri/dokümanların toplanması,
* Endüstri içi kalite kontroller, harmonizasyon ve teslimat anlaşması performansları.

==== <big>5.5.1.4. Yüklenici tarafından LDA veri/dokümanlarının teslimatı</big> ====
Müşteri ve yüklenicinin arasında yapılan LDA GGT ve sonrasında yapılan LDA anlaşmaları üzerinde anlaşılarak dokümante edilmelidir. Bu dokümantasyon en az aşağıdaki hususları içermelidir:

* LDA teslimlerinin son teslim tarihini içerecek şekilde (uygulanabilir olduğu durumda) üzerinde anlaşılan dağıtım kurallarının dikkate alınarak dağıtılması,
* Yüklenici iç dokümantasyonu ve resmi LDA teslimatlarının dağıtımı.

==== <big>5.5.1.5. Müşteri değerlendirmesi ve değerlendirme sonuçlarının dağıtımı</big> ====
Müşteri ve yüklenicinin arasında yapılan LDA GGT ve sonrasında yapılan LDA anlaşmaları üzerinde anlaşılarak dokümante edilmelidir. Bu dokümantasyon en az aşağıdaki hususları içermelidir:

* Yüklenicinin LDA teslimatının gerektiği gibi dağıtılması,
* Resmi müşteri yanıtlarına verilen tüm cevapların uyumlandırılması,
* Müşteri yanıtının yükleniciye dağıtımı.

==== <big>5.5.1.6. Yüklenici tarafından müşteri cevaplarının dağıtımı</big> ====
Müşteri ve yüklenicinin arasında LDA GGT ve sonrasında yapılan LDA anlaşmaları üzerinde anlaşılarak dokümante edilmelidir. Bu dokümantasyon en az aşağıdaki hususları içermelidir:

* Resmi müşteri cevaplarının kaydı,
* Endüstri iç dağıtımı,
* Yüklenici araştırma sonuçlarının tanımlanması, dağıtılması ve uyumlandırılması,
* Müşteri yanıt detaylarına göre (uygun olabildiğince) LDA veri tabanının güncellenmesi,
* Genel yorum ve anlaşmazlıklara yüklenici cevabının uyumlandırılarak hazırlanması.

==== <big>5.5.1.7. Anlaşılmayan yorumlarla ilişkili yüklenici cevaplarının dağıtılması</big> ====
Yükleniciden gelen tekrarlı analiz verileriyle ilgili adımlar 5.5.1.4’te verilmiştir.

== 5.6. LDA İŞ TANIMLAMA GÖZDEN GEÇİRME TOPLANTISI ==
Yüklenici ve müşterinin katılımıyla aşağıdaki hususları gerçekleştirmek için bir LDA İş Tanımlama Gözden Geçirme Toplantısı (LDA İş Tanımlama GGT) planlanmalıdır:

* Açıkta kalan konularla ilgili bir karara ulaşarak mutabakatın sağlamak,
* Müşterinin açıkta kalan konularla ilgili onayına ulaşmak,
* LDA aday kalemlerinin durumunu izlemek, (ör. tamamlanması ve kalitesi),
* Sürecin tüm fazlarıyla ilişkili lojistik desteği değerlendirmek,
* LDA sürecini geliştirmek için müşteri ve yüklenici arasındaki ek anlaşmalara ulaşmak.

=== 5.6.1. LDA GÖZDEN GEÇİRME SÜRECİ ===
LDA GGT, LDA aday kalem seviyesinde gerçekleştirilmelidir. Toplantıdan önce, yüklenici müşteriyi üzerinde konuşulacak LDA adayları ile ilgili bilgilendirmelidir.

LDA GGT’de LDA teslimatları ve ilişkili veri elemanları değerlendirilmeli ve belirlenmiş olan kabul kriteri gözetilerek kararlar alınmalıdır. Alınan her karar raporlanmalıdır.

Karmaşık LDA aday kalemleri uzun zamana yayılan projelerin farklı aşamaları içinde ulaşılabilir tipte bilgiye bağlı olarak bir dizi analiz aktivitesi gerektirebilir. Diğer yandan, bazı kararlar projenin en erken aşamalarında var olan kısıtlı bilgiye dayanarak alınmalıdır (ör. Ön bakım konseptinin belirlenmesi) Bazı kararlar ise projenin oldukça ileri bir aşamasına kadar belirli olmayan netleşmiş bir tasarım gerektirir (ör. Planlı bakım görevlerinin zaman açısından belirlenmesi vb.). Bu sebeple, birden fazla gözden geçirme gerçekleştirilebilir. Her LDA GGT’si değerlendirmesi istenen ve durum kodlarıyla gösterilen LDA adaylarına ait tüm adımları içermelidir.

LDA sürecinin yinelemeli doğasından ötürü, LDA GGT’si esnasındaki herhangi bir onay geçici değerlendirme olarak alınmalı fakat yüklenicinin LDA sürecine devam etmesine de izin vermelidir. LDA sürecinin doğası gereği, tasarım değişikliklerinden, teknik verilerin güncellenmesinden ve/veya destek ve operasyonel çevreden ötürü veriler tekrar gözden geçirilmelidir.

Nihai sonuçlar LDA dokümanlarında ve/veya veri tabanlarında dokümante edilmelidir ve her proje fazında dondurulmuş olarak düşünülmelidir. Buna ilişkin kabul kararları üzerinde LDA GGT’de anlaşılmalıdır.

LDA GGT’leri değişen tasarım ve analiz faaliyetleriyle paralel olarak gerçekleştirilmelidir. Bu toplantılar üzerinde anlaşılan periyotlarda veya değerlendirilecek bilgiye dayalı olarak düzenli olarak gerçekleştirilmelidir. Toplantı notları müşteri ve yüklenicinin gerçekleştireceği eylemleri içerek şekilde hazırlanmalıdır.

=== 5.6.2. GÖZDEN GEÇİRME KONUSU ===
Bir LDA GGT’sinde veya sonrasındaki anlaşmalarda müşteri ve yüklenici arasındaki sözleşmesel tüm kalemler LDA GGT’sinde gözden geçirilmelidir. LDA süreci için gerekli olarak tanımlanan ve belirlenmiş olan LDA programıyla ara yüzü olan diğer lojistik süreçleri etkileyebilecek her şey gözden geçirmenin konusudur.

LDA ile ilişkili analizlere ilişkin prosedür ve prensiplere giriş, analizlerin amaçları hakkında ortak bir anlayışa ulaşmak, ilgili kısıtlamalar ve LDA sonuçlarını değerlendirmek için yüklenici tarafından müşteriye sunulmalıdır.

Müşterinin özel olarak ilgilendiği kalemleri yansıtan raporların yanında ilerleme raporları ve veri kalite raporları da yüklenici tarafından sağlanmalıdır. Aşağıda bazı örnekler verilmiştir:

* Çalışma saati başına ortalama adam-saat gibi idame edilebilirlik değerleri,
* Belirlenmiş limitler içerisinde gerçekleşecek idame edilebilirlik görevleri için Ortalama Geçen Zaman gibi lojistik performans parametreleri.

=== 5.6.3. GÖZDEN GEÇİRME YAPISINA ÖRNEKLER ===
LDA gözden geçirme süreci içerisindeki adımlar bir projenin LDA verilerinin yayımlanması ve onaylanması için aşağıdaki şekilde düzenlenebilir:

* LDA gözden geçirme basamağı- 1. Aday Kalem listesi ve bakım analiz ataması (bkz: 5.6.3.1),
* LDA gözden geçirme basamağı- 2. Onarım seviyesi analizi ve bakım konsepti bilgisi (bkz: 5.6.3.2),
* LDA gözden geçirme basamağı-3. HTEA ve Planlı Bakım Analizi sonuçları (bkz: 5.6.3.3),
* LDA gözden geçirme basamağı-4. Bakım Görev Analizi (bkz: 5.6.3.4).

==== <big>5.6.3.1. Aday Kalem Listesi ve Bakım Analizi Ataması</big> ====
Bu basamak, sonrasında gelen LDA veri tabanı içerisinde dokümante edilen tüm LDA aktivitelerinin temelini oluşturmaktadır. Aşağıdakileri içerir:

* LDA aday kalemlerinin uygulanabilir olduğu durumda gruplanarak seçimi,
* Aday tipinin ve ilgili özelliklerinin (HDB’lerin tanımlanması, potansiyel maliyetler, potansiyel bakımlar, potansiyel kullanıma hazır olma) tanımlanması,
* Seçilmiş her aday için gerçekleştirilecek LDA ilişkili analiz aktivitelerinin atanması
* Detayları gösteren durum kodu,
* Aday kalem seviyesindeki her tasarım konfigürasyonundaki değişikliklerin LDA veri tabanında yönetilmesi.

==== <big>5.6.3.2. Onarım Seviyesi Analizi ve Bakım Konsepti Bilgisi</big> ====
Bu basamakta, bakım görevleri ilgili bakım seviyelerine atanarak ön bakım konsepti hazırlanır. Tipik olarak aşağıdakileri içerir:

* Yüklenici tarafından önerilen bakım konsepti,
* Ürüne ekipman entegrasyonu ile ilişkili bakım görevlerinin tanımlanması (ekipman çıkarılması ve yüklenmesi, ekipman ve sistem seviyesinde fonksiyonel testlerin performansı vb.),
* Önerilen bakım konseptinin doğrulanması,
* Red veya alternatif çözüm olabilecek bakım konsepti üzerindeki müşteri kararı.

==== <big>5.6.3.3. HTEA ve Planlı Bakım Analizi sonuçları</big> ====
Bu basamakta, bakım konsepti planlanmamış bakım görevlerinin HTEA ile belirlenmesiyle son haline getirilir. Planlı Bakım Analizi sonuçları ise planlı bakım görevlerini belirler.

==== <big>5.6.3.4. Bakım Görev Analizi</big> ====
Bu basamakta, belirlenmiş bakım görevleri, gereksinimlere ve uygulanmasına göre analiz edilir.

* Uygulanabilir derinlik ve ölçüde gerekli bakım görevlerinin tanımı
* Her görev adımının süresi
* Bakım aktivitelerini destekleyecek ilgili lojistik kaynakların tanımlanması (ör. Personel, destek ekipmanı, yedek parça, veri ve yazılım, sarf malzeme, tesisler)

==== <big>5.6.4. DURUM KODU ÖRNEKLERİ</big> ====
Durum kodları aşağıdaki ifadeleri yansıtacak şekilde düzenlenir:

* Dahil olan firmaların sorumlulukları; her görev grubu için görevli firma belirlenmelidir. Bu aynı zamanda üzerinde anlaşılan iş dağılımının detaylarını da yansıtır.
* LDA adayının tipi (tam aday, kısmi aday vb.)
* Önemli konular (kullanıcı tarafından yüklenebilir yazılım, veri vb.)
* Gözden geçirme aşaması göstergesi

Tablo 8, potansiyel kodlar ve karşılık gelen anlamları için örnek vermektedir. (Her LDA adayı için gözden geçirme aşaması göstergesi olarak)

'''Tablo 8 Durum Kodu Örnekleri'''
{| class="wikitable"
|'''Kod'''
|'''Tanım'''
|-
|X
|“Çalışır durumda”, değerlendirme istenmiyor
|-
|N
|İlgili LDA adayı için uygulanabilir değil
|-
|R
|Değerlendirme istendi ve Sıradaki LDA GGT’sinde karar verilecek
|-
|A
|Gösterge üzerinde müşteriyle geçici olarak anlaşıldı
|-
|B
|Müşteriyle geçici olarak anlaşıldı ancak son kabul için küçük bir çalışma gerektiriyor
|-
|O
|Müşteriyle üzerinde anlaşılamadı ve açık konu olarak kaldı.
|}

=== 5.6.5. DURUM KODU ATAMASININ DERİNLİĞİ ===
Her LDA adayı için minimum bir gereksinim olarak ilgili durum kodları atanmalıdır. Ayrıca, değerlendirme konusu detaylı bir şekilde adreslenebilir. (modifiye edilen bir LDA adayının değerlendirme ihtiyacı vb.) Bu karar LDA GGT’da alınmalıdır.

=== 5.6.6. DURUM KODLARININ İŞLEVİ ===
Durum kodları, gözden geçirme sürecinin yapısını yansıtır ve LDA veri tabanı içerisinde dokümante edilmesi gereken tüm sözleşmesel konuları adresler. LDA veri tabanı içeriğiyle ilgili tüm durum özeti raporları için kullanılabilir. (örneğin her LDA GGK sonrası LDA alanındaki gelişmelerin yansıtılması.)

Durum kodu tarafından filtrelenen bir LDA aday kalem listesi, müşterinin dikkatini özel bir konuya çekmek için kullanılabilir.

Durum kodu ayrıca ELD elemanlarına ilişkin ürünleri yaratırken karşılaşılabilecek riskler dikkate alınarak dur ya da devam et durumunu belirtmek için de kullanılabilir.

=== 5.6.7. LDA GGT’SİNDE DURUM KODUNUN TANIMLANMASI ===
Gözden geçirme aşamaları, ilgili durum kod yapısı ve uygulanabilir durum kodları yüklenici tarafından önerilip LDA GGT’sinde derinlik ve detay seviyesi ile beraber müşteri tarafından da onaylanmalıdır.

= 6. TASARIMA ETKİ/TASARIM ETKİLEŞİMİ =
LDA’nın temel amaçları, tasarımı etkilemek, en etkin destek konseptini oluşturmak ve lojistik kaynak gereksinimlerini tanımlamaktır. Bu bölümde bu amaçlar içerisinden özellikle ürün tasarımına etki üzerinde durulmuştur.

LDA gereksinimlerini karşılamak ve ÖDM azaltabilmek amacıyla tasarıma etki edebilme fırsatı projenin geliştirme safhasında en yüksek düzeydedir. Erken dönemde gerçekleştirilecek tasarıma etki, ileriki safhalarda ürünü kullanıma ve desteğe uygun hale getirme amaçlı tasarım değişikliği ihtiyaçlarını azaltabilir veya tamamen ortadan kaldırabilir. Tasarımın etkilenmesi, proje dönemi boyunca gerçekleştirilecek gözden geçirmeler ve ana hatlar ile yapılandırılmış bir şekilde gerçekleştirilir. Tasarımda (yazılım veya donanım) rol alan kişiler açısından bu faaliyet tasarım programı ile LDA programı arasında etkileşim sağlanması açısından önemlidir.

== 6.1. LDA’DAN ETKİLENEN VE KARŞILIKLI OLARAK LDA’YI ETKİLEYEN TASARIM PARAMETRELERİ ==

* LDA’nın tasarıma etki edebilmesi için nasıl bir strateji geliştirilmesi gerektiği ve bunun sağlayacağı faydalar,
* Tedarikçi bakış açısı,
* Kilometre taşlarındaki gözden geçirmeler.

== 6.2. LDA TARAFINDAN ETKİLENEBİLECEK VE LDA FAALİYETLERİNİ ETKİLEYEBİLECEK TASARIM PARAMETRELERİ ==
Bir ürünü daha verimli ve maliyet açısından daha etkin hale getirmek üzere sistem/altsistem veya ekipman tasarımını etkilemede kullanılabilecek birçok özellik vardır. Bu özelliklerden başlıcaları aşağıda sıralanmış ve ilerleyen bölümlerde açıklamalar verilmiştir.

* Kullanıma hazır olma,
* Güvenilirlik,
* İdame edilebilirlik,
* Test edilebilirlik,
* Prognostik,
* Standartlaştırma,
* Değiştirilebilirlik
* Çevresel hususlar,
* İnsan faktörü/ergonomi,
* Demodelik,
* Desteklenebilirlik,
* Maliyet etkinlik,
* Yazılım tasarımı.

=== 6.2.1. KULLANIMA HAZIR OLMA ===
Bir ürünün kullanıma hazır olması, ürürün bilinmeyen bir zamanda görev veya operasyon ihtiyacı doğduğunda söz konusu görev veya operasyonun başlangıç anında faal ve kullanıma uygun olma durumunun bir ölçüsüdür.

Güvenilirlik, idame edilebilirlik ve desteklenebilirlik ürünün kullanıma hazır olmasına etki eden faktörlerdir (Şekil 8).
[[Dosya:Şekil8 Kullanıma Hazır Olma Kırılımı.jpg|alt=|sol|küçükresim|583x583pik|Şekil 8 Kullanıma Hazır Olma Kırılımı]]

Bir sistemin Tasarımsal Kullanıma Hazır Olma ölçüsü (Inherent Availability), ürünün güvenilirlik ve idame edilebilirliği tarafından belirlenir ve sistemin zaman içinde herhangi bir anda, tanımlı kullanım koşulları altında ve ideal destek ortamında (destek kaynaklarında herhangi bir zafiyet olmadığı durumda) yeterli düzeyde çalışacağı olasılık olarak tanımlanır. Önleyici bakım ve gecikme zamanlarını kapsamaz.
[[Dosya:Tasarımsal Kullanıma Hazır Olma.jpg|sol|küçükresim]]

Aİ= Tasarımsal Kullanıma Hazır Olma

MTBF = Arızalar Arası Ortalama Süre

MTTR = Ortalama Onarım Süresi

Ulaşılabilir Kullanıma Hazır Olma (Achived Availability) ise tasarımsal kullanıma hazır olmaya benzemekle birlikte kapsamında önleyici bakım faaliyetlerini de bulundurur ve aşağıdaki şekilde ifade edilir:
[[Dosya:Ulaşılabilir Kullanıma Hazır Olma .jpg|sol|küçükresim]]

Aa = Ulaşılabilir Kullanıma Hazır Olma

MTBM = Bakımlar Arasındaki Ortalama Süre

M= Ortalama Aktif Bakım İşlem Süresi

Operasyonel Kullanıma Hazır Olma (Operational Availability) ise ürün ve destek sisteminin birleşimi ile ortaya çıkar. Bir sistemin tanımlı kullanım koşullarında, ideal olmayan gerçek destek ortamında ihtiyaç duyulduğunda yeterli düzeyde çalışma olasılığı olarak tanılanır ve aşağıdaki şekilde ifade edilir:
[[Dosya:Operasyonel Kullanıma Hazır Olma .jpg|sol|küçükresim]]

AO= Operasyonel Kullanıma Hazır Olma

MTBM = Bakımlar Arasındaki Ortalama Süre

MDT = Bakım İçin Sistemin Servis Dışı Kaldığı Ortalama Süre

=== 6.2.2. GÜVENİLİRLİK ===
Güvenilirlik, bir sistemin destek kaynaklarına etki eden birincil faktördür. Ürünün belirli koşullar altında hatasız performans gösterme süresi veya belirli koşullar altında belirli bir süre kendisinden beklenen işlevini yerine getirme olasılığı ile ilişkilidir. Güvenilirlik kullanıma hazır olma değeri ile doğrudan ilişkilidir.

Yüksek güvenilirlikli ürünler genellikle maliyet etkindir. Ancak, düşük güvenilirlikli ürün kullanımından kaçınmanın mümkün olmadığı durumlarda, ürün tasarımı bu durumu hatanın yerinin kolay belirlenmesinin ve bakım faaliyetlerinin kolay olmasını sağlayarak dengelemelidir. Bunun için sistem tasarımının erken aşamasında güvenilirliğin bir tasarım parametresi olarak ele alınması gerekmektedir. Kullanıma hazır olma oranını koruyabilmek için düşük güvenilirliğin idame edilebilirlik ve desteklenebilirliğin artırılması ile dengelenmesi bir ölçüde mümkün olabilmektedir.

Projenin güvenilirlik ile ilgili gereksinimleri incelenerek (eğer yoksa hedef bir güvenilirlik değeri yüklenici tarafından benzer sistemlerin verileri kullanılarak belirlenebilir) güvenilirlik ataması yapılır. Böylelikle her bir fiziksel alt sistemin sahip olması gereken güvenilirlik metrik değerleri projenin geliştirme safhasında belli olur. Güvenilirlik atamaları yapılırken çeşitli askeri standartlardan, veri tabanlarından veya geçmişteki sistemlerin saha verilerinden faydalanılabilir. Güvenilirlik metrik ölçüsü onarılabilir olan sistemler için (tek kullanımlık olmayan araç, silah sistem gibi) arızalar arası ortalama süre olarak tanımlanabilir. Tek kullanımlık olan sistemler (füze sistemi gibi) için ise görev güvenilirlik değeri yüzde olarak tanımlanabilir.

Güvenilirlikle ilgili olarak tasarım kapsamında dikkate alınması gereken hususlara ilişkin örnekler aşağıda verilmiştir:

* Üründe güvenilirliği düşük alt sistem ve bileşenler için yedekleme yapılabilir.
* Uygulanabilir olduğu ölçüde askeri standartlara uygun ürün seçimleri yapılmalıdır.
* Benzer sistem ve projelerdeki güvenilir olduğu bilinen parçaların yeniden kullanımı ilk kez kullanılacak parça seçimine göre tasarımda öncelikli olmalıdır.
* Yalıtım malzemelerinin kullanımı değerlendirilmelidir.

Güvenilirlik açısından bir diğer tasarıma etki etme faaliyeti ise HTEKA (Hata türleri, Etkileri, Kritiklik Analizi) vasıtası ile olur. Sistemin arıza verme senaryoları tek tek incelenerek olasılıklar hesaplanır ve sistemin arıza durumunda arızanın göreve engel teşkil edip etmeyeceği araştırılır. Göreve engel teşkil eden arızaların tek hatadan kaynaklanması durumunda bazı önlemler alınarak sistemin tek hatadan gayri faal olma durumunun engellemesi hedeflenir. Ayrıca kritik bir arıza birden çok kez tekrarlanıyor ya da tekrarlanma olasılığı yüksek çıkıyor ise tasarıma geri bildirim verilerek tasarımın değiştirilmesi ya da sistemin yedeklenmesi gibi önlemler alınması sağlanır.

Tasarıma etki ara yüzünün oluşturulması kapsamında başlangıç noktası olarak kullanılabilecek kontrol listesi aşağıda verilmiştir;

* Hata modları ve etkileri tanımlandı mı?
* Kalemlerin arıza oranları biliniyor mu?
* Arıza oranı yüksek parçalar belirlendi mi?
* Ortalama ömrün ne olduğuna karar verildi mi?
* Ekipman tasarım karmaşıklığı minimize edildi mi?
* Uygulanabilir olan durumlar için ikincil hatalara (birincil hataların sonucu olarak meydana gelen hatalar) karşı korunma önlemleri alındı mı?
* Güvenilirlik gereksinimleri karşılanıyor mu?

=== 6.2.3. İDAME EDİLEBİLİRLİK ===
İdame edilebilirlik güvenilirliğin yanında kullanıma hazır olmayı etkileyen bir diğer önemli faktördür.

İdame edilebilirlik, belirlenmiş prosedür ve kaynaklar kullanılarak, tanımlı bakım onarım seviyelerinde belirlenmiş yeteneğe sahip personel tarafından bakım faaliyeti gerçekleştirildiğinde, odak sistemin öngörülen performans seviyesinde tutulabilmesi veya öngörülen performans seviyesinde tekrar çalışır duruma geri getirilebilmesi kabiliyetinin ölçüsüdür.

İdame edilebilirliğin karakteristikleri

* Bir ekipmanın işlevselliğini korumak veya işlevsel haline geri getirmek için ekipmanın değiştirilmesi,
* Onarım için geçen süre,
* Destek kaynaklarının miktarı ve karmaşıklığı ve
* Faaliyetleri gerçekleştiren personelin gerekli beceri seviyeleri olabilir.

Projenin idame edilebilirlik ile ilgili gereksinimleri incelenerek (eğer yoksa hedef bir idame edilebilirlik değeri yüklenici tarafından belirlenebilir) idame edilebilirlik süre kırılımı yapılır. Böylelikle her bir fiziksel alt sistemin sahip olması gereken idame edilebilirlik metrik değerleri projenin geliştirme safhasında belli olur. İdame edilebilirlik kırılımları yapılırken çeşitli askeri standardlardan, veri tabanlarından veya envanterde bulunan ve halihazırda kullanılan sistemlerin saha verilerinden faydalanılabilir.

İdame edilebilirlik ile ilgili gerçekleşen süreler, testler ve kullanıcıya verilen eğitimler sırasında ölçülüp doğrulanabilir. Ayrıca ürünlerin garanti döneminde yapılan bakımlardan toplanan verilerden de sistemlere yapılan bakımların ortalama süreleri çıkarılabilir.

İdame edilebilirlik ile ilgili yüklenicilerin karşılaştığı ulaşım, erişim, bakım yapılamama, sökülememe gibi problemlerin incelenmesi açısından 3B model yazılımları ve bazı destekleyici yazılımlar kullanılabilir. Bu yazılımların kullanılmasının amacı zorlukla yapılabilecek bir bakım onarım faaliyetini geliştirme safhasında modeller üzerinden önceden kestirebilmektir.

Tasarıma etki ara yüzünün oluşturulması kapsamında başlangıç noktası olarak kullanılabilecek kontrol listesi aşağıda verilmiştir;

* Farklı tiplerdeki bağlantı elemanlarının toplam sayıları minimuma indirildi mi?
* Bağlantı elemanları standart aletler için olan gereksinimlere bağlı olarak mı seçildi?
* Ekipman yenisi ile değiştirilebilir kalemler olarak mı tanımlandı?
* Bir kalemin yenisi ile değiştirilmesi için gereken süre minimize edildi mi?
* Operasyonel çevre koşulları dikkate alındı mı?
* Yazılımın nasıl yükleneceği, yükleme süresi vb. parametreler dikkate alındı mı?

=== 6.2.4. TEST EDİLEBİLİRLİK ===
Test edilebilirlik, bir bileşenin durumunun (çalıştırılabilir, çalıştırılamaz ve düşük fonksiyonlu çalıştırılabilir) ve hataların/başarızılıkların lokasyonunun zamanında ve belirli bir güven seviyesinde belirlenebilmesini sağlayan bir tasarım özelliğidir.

Test edilebilirlik gereksinimlerini karşılayacak bir tasarım çözümü, ürüne entegre bir test sistemi ile veya destek kaynaklarının bir parçası olan ve hataların lokalizasyonu için ürünle arayüzü bulunan bir test sistemi ile sağlanabilir. İyi tasarlanmış test sistemleri, hataların/arızaların bulunması ve düzeltilmesi için harcanacak çabayı azaltacağı gibi sistemin işlevselliğini doğrulamak için de kullanılabilir.

Test edilebilirlik gereksinimlerinden dolayı yeniden tasarım yapmak çok karmaşık bir faaliyettir

Arıza fark etme/doğrulamanın detay seviyesi, uygulanabilir bakım konseptini etkileyen en önemli etken olduğundan test edilebilirlik özelliklerinin tasarım tamamlandıktan sonra belirlenmesi mümkün olmayacaktır. Bu nedenle, test edilebilirlik gereksinimleri uygulanabilir her kalem için tasarım ve geliştirme safhalarında tanımlanmalıdır. HTEA/HTEKA sonuçları test edilebilirlik gereksinimlerini nasıl etkilediği konusuna EK-B’de değinilmektedir.

Test edilebilirlik analiz faaliyeti LDA faaliyeti olmayıp, yapılacak diğer lojistik destek analizlerinde bu çalışmanın çıktıları doğrudan kullanılacaktır. Bu anlamda analiz sonuçları, hem LDA girdisi hem de tasarım girdisi olacaktır. Hata Tespit Oranı, Hata İzolasyon Oranı ve Süresi test edilebilirlik parametreleridir. Testedilebilirlik analizi ile, FMECA çıktıları kullanılarak hata tespiti ile hata izolasyonuna ilişkin veriler belirlenir.

* LDA girdisi; BGA’da belirlenen bir bakım görevi kapsamında bir kalemin test edilmesine ilişkin girdi sağlayacaktır.
* Tasarım girdisi; tasarıma etki kapsamında ise, arızalandığı durumda etki seviyesi yıkıcı olan bir donanıma test edilebilirlik özelliğinin kazandırılması, arıza sinyali olarak arıza mesajlarının tasarımına ve test ekipmanı gereksinimlerine girdi sağlanması örnek olarak verilebilir.

Tasarıma etki ara yüzünün oluşturulması kapsamında başlangıç noktası olarak kullanılabilecek kontrol listesi aşağıda verilmiştir;

* Uygulanabilir olan durumlar için birim içi test (self-test) durumu sağlandı mı?
* Birim içi test otomatik olarak mı yapılıyor?
* Doğrudan arıza göstergesi sağlandı mı (örneğin ışık yanması, uyarı çıkması gibi)?
* Kontrol ve hata izolasyonunu mümkün kılacak test ara yüzleri sağlandı mı?
* Test ara yüzleri erişilebilir mi?
* Test ara yüzleri fonksiyonel mi veya ardışık test yapmayı kolaylaştıracak şekilde mi?
* Test ara yüzleri yenisi ile değiştirilebilir kalemlerin doğrudan testini yapmaya olanak veriyor mu?
* Test noktaları gerekli olması halinde görsel olarak etiketlenmiş mi?
* Her ekipmanın işlev bozukluğu tespit edilebiliyor mu?
* Yazılım yeterli test bilgisini sağlıyor mu?

=== 6.2.5. PROGNOSTİK ===
Bazı ürün parametreleri ve verileri, bakım veya onarım ihtiyaçlarının kestirilmesine yönelik modellerde kullanılabilir. Prognostik, bir sisteme ilişkin ne zaman arıza oluşacağına dair kestirimde kullanmak üzere sistemin operasyonel durumuna dair veri toplanması ve analiz edilmesine izin veren bir tekniktir. Prognostik, test edilebilirliğin bir alt kümesi olarak düşünülebilir; ancak veri depolama ve anlık veri analizleri karmaşık olabilir, dolayısıyla genellikle kritik performans özelliklerine uygulanır.

Prognostiğin amacı, görev performansını sürdürebilmek için parçaları gerçekten arızalanmadan önce değiştirmek için optimum zamanı kestirmektir. Bileşenler özelinde ömrü, kullanım süresi, çevresel faktörler, benzer komponentlerin arızaları gibi bilgiler toplanır. Bu bilgiler daha sonra kestirimci modele veri olarak girilirse belirli bir komponentin ne zaman arızalanacağına yönelik bir tahmin oluşturulur.

Bakım/onarım prognostik işlevi, ürünün veya destek sisteminin bir parçası olarak tasarlanabilir.

Prognostiğin faydası, ürünün “sağlık” durumunun bilinmesi ve bu bilgiye dayanarak kritik arızalardan kaçınma ve sistemin işlevselselliğini idame edecek faaliyetleri planlayabilme olarak tanımlanabilir. Prognostik özellikleri olmayan bir sistemde, sistem ömrünü uzatmak için önleyici bakım kullanılır ve sistem emniyeti düzeltici bakım işlem ve kaynaklarına karşı dengelenmeye çalışılır.

Ancak, parçaların arızalanmadan önce değiştirilmeleri yararlı ömürlerinin bir kısmının kullanılamaması ile sonuçlanmaktadır. Ayrıca, prognostik ancak yeterli ve uygun verinin toplanabilmesi durumunda etkin olacaktır. Dolayısıyla, prognostik tekniği kullanılması kararı, geliştirme ve kullanım maliyetlerinin operasyon esnasındaki arızaların etki ve maliyetleri ile kıyaslanarak verilmelidir.

=== 6.2.6. STANDARTLAŞTIRMA ===
Genel olarak, özel tasarlanmış ekipmanlar yerine standart ekipman kullanımı daha maliyet etkindir. Gereksinimleri karşılayan mevcut bir parça veya sistem kullanıldığında geliştirme/ tasarım maliyeti ve süresi azalmaktadır.

Gereksinimleri karşılayan standartlaştırılmış ekipman kullanımı ile, mevcut lojistik destek kaynaklarının kullanımı da mümkün olabilir. Böylece destek sistemi kaynaklarının tasarım ve temini için yatırım ihtiyaçları azalır. Özel geliştirilmiş destek ekipmanı ihtiyacı ortaya çıkaran tasarım kararları, maliyeti artıracağı için dikkatle ele alınmalıdır.

Standartlaştırmanın diğer avantajı, ürün/sistem olgunluğu ve bilgisindeki artış ile operasyonel birimin hareket kabiliyetindeki artıştır.

Üründe kullanılan parçaların daha önce kullanıcı envanterinde kullanılıp kullanılmaması idame edilebilirlik açısından önemli rol oynar. Daha önce kullanıcının aşina olduğu sistemin aynısını veya bir benzerini yeni tasarımda kullanmak hem eğitimler hem ikmal hem de bakım personeli tecrübesinden faydalanabilme açısından faydalıdır.

Hali hazırda envanterde bulunan tüm sistemlerin tanıtıldığı ortak bir veri tabanı kullanılarak bir standartlaştırma yapılırsa veya yüklenici ve müşteri temsilcilerinin bulunduğu bir çalışma grubu ile envanterdeki benzer sistemler incelenirse aynı fonksiyon için tasarıma etki edilerek aynı veya benzer sistemlerin entegrasyonu sağlanabilir.

Standartlaştırmanın potansiyel faydalarını etkileyen faktörler aşağıda sıralanmıştır:

* Mevcut ekipmanların kullanımı, yeni destek kaynağı geliştirmede ortaya çıkacak geliştirme maliyetlerinden kaçınmayı sağlar,
* Yeni eğitim programı geliştirme maliyetlerinden kaçınılabilir,
* Destek kaynaklarının müşterekliği, destek kaynaklarının hazır olmasını artırırken lojistik hacmi azaltır,
* Standartlaştırılmış elemanların kullanımı destek kaynak gereksininmlerini belirlemek için gerekli geliştirme süresini kısaltır,
* Farklı ekipmanların kullanımı öğrenmek yerine aynı ekipmanın kullanımı söz konusu destek ve test ekipmanlarını kullanan personelin eğitim süresini azaltır ve personelin yetkinliğini artırır.

Standartlaştırma aynı zamanda değiştirilebilirliği de kapsar.

Yazılım tasarımı da örneğin programlama dilleri, bilgi yapıları veya yazılım ve bilgi taşıyan medya gibi konulara ilişkin standartlaştırma gereksinimlerinden etkilenebilir.

Standartlaştırmanın olası faydalarını gerçeğe dönüştürebilmek için ilgili gereksinimlerin tasarım faaliyetleri başlamadan önce belirlenmiş olması gerekir.

=== 6.2.7. BİRBİRİYLE DEĞİŞTİRİLEBİLİRLİK ===
Değiştirilebilirlik, performans ve dayanıklılık açısından eşdeğer işlevsel ve fiziksel karakteristiğe sahip olan iki veya daha fazla elemanın, kendileri veya bitişiklerindeki elemanlar üzerinde, ayarlama hariç tadilat gerektirmeden ve performans açısından seçim yapmadan, birbirleriyle değiştirilebilme kabiliyetine sahip olduğu durum olarak tanımlanır. Değiştirilebilirlik, benzer ekipmanlardaki parça veya komplelerin, tadilat veya fiziksel değişiklik gerektirmeden birbiri ile değiştirilebilme kabiliyeti olarak da adlandırılabilir.

Bir ürün tasarımının, uygun durumlarda ürünün kendi üzerinde veya ürünler arasında ekipman, komponent ve parçaların değiştirilebilirliğine olanak verecek şekilde gerçekleştirilmesi bir çok avantaj sağlayacaktır. Burada amaçlanan ekipman kullanımında esnekliği artırmak ve yedek parça stok seviyelerinde azalma sağlamaktır.

Değiştirilebilirlik, standartlaştırmanın sağlanmasında temel yöntemlerden birisidir. Standartlaştırma ile değiştirilebilirlik ilişkisine örnek olarak bir savunma ve güvenlik sisteminin gözetleme işinde kullanılan bataryanın başka bir sistem kapsamında da kullanılabilmesi verilebilir. Bu sayede batarya şarj cihazı da ortak olacağı için bir çok avantaj (tek bir bakım yönteminin olması gibi) sağlanacaktır.

Etkili olabilmesi için, değiştirilebilirlik ile ilgili gereksinimlerin tasarım faaliyetleri başlamadan tanımlanması gerekir.

=== 6.2.8. ÇEVRESEL HUSUSLAR ===
Bilinen operasyonel ve bakım çevresel koşulları ekipman ve tasarım çözümü tercihlerini etkileyebilir. Bakım ve operasyonu etkileyen parametrelere örnek olarak sıcaklık, nem, kumlu ve tuzlu ortamlar verilebilir. Ürün aynı zamanda ulaştırma, söküm, kurulum ve depolanması esnasında da gereksinimleri karşılamalıdır.

Bakım, iletim ve envanterden çıkarma için çevresel bir bakış açısıyla gerekli olan kimyasallar/malzemeler de önemlidir. Tehlikeli malzemelerin, tehlikeli atıkların ve çevresel kirleticilerin içerilmesinin sonuçlarının ürünle temas halinde bulunan personelin emniyeti ve ÖDM üzerinde etkisi vardır.

Çevresel etkilerin geliştirme safhasında göz önünde bulundurulması, sistemin kullanım, destek ve envanterden çıkarma safhalarında ortaya çıkabilecek sorunların önüne geçer. Bu nedenle çevresel hususların gereksinim olarak tanımlanması gerekmektedir.

Sistemin hangi çevresel koşullara maruz kalacağı bilgisi, sarf malzemelerinin (yağlar, yakıt vb.) seçiminde de göz önünde bulundurulması gereken hususlardandır.

=== 6.2.9. İNSAN FAKTÖRÜ/ERGONOMİ ===
İnsan faktörü mühendisliği, tasarıma etki kapsamında ele alınması gereken desteklenebilirlik mühendisliği fonksiyonlarından birisidir. Bu disiplin ile LDA süreci arasında sürekli bir ilişki ve entegrasyon söz konusudur.

İnsan faktörü/ergonomi ile ilgili olarak tasarım geri bildirimleri gereksinim olsun ya da olmasın üretilen sistemlerde insan-makine ara yüzü var ise göz önüne alınması gereken bir faktördür. İnsan faktörleri ve ergonomi ile ilgili kullanıcı makamı ve tedarik makamı yüklenicilere hangi istatistiksel antropometrik veri tabanını kullanarak sistem tasarımı yapılacağını bildirmelidir. Aksi halde sistem tasarımı çok geniş bir insan popülasyonunu kapsayacağından karmaşık hale gelebilir. Bu anlamda kullanıcı makamının karar vereceği bir antropometrik veri tabanının insan faktörleri ve ergonomi analizlerinde kullanılması önemlidir.

Bu analizler kapsamında, insan faktörü ve ergonomiye ilişkin ürün gereksinimleri belirlenmelidir. Ürün tasarımı operatör ve teknisyenler için erişilebilirlik hususlarını dikkate almalıdır.

Söküm takım faaliyetlerine ilişkin olarak erişilebilirliği analiz etmek için sanal araçlar veya başka yöntemler kullanılabilir. Konsept safhasından itibaren bakım ilişkili faaliyetleri simüle etmek maksadıyla bir takım ergonomi/simülasyon yazılımları kullanılabileceği gibi (Şekil 9), oluşturulan mock-up’lar üzerinden de analizler gerçekleştirilebilir. Böylelikle, tasarımın erken safhalarında bakım ve idame edilebilirliğe yönelik tedbirler (mühendislik değişimleri, bakım destek teçhizatı ihtiyacı tespitleri, bakım görev değişiklikleri vb.) alınarak tasarıma yön verilebilir.
[[Dosya:Şekil 9 Ergonomi-Simülasyon .jpg|sol|küçükresim|450x450pik|Şekil 9 Ergonomi/Simülasyon Yazılımlarından Örnek Görüntü]]

Bakım, operasyon ve envanterden çıkarmada ihtiyaç duyulan kimyasallar/malzemeler de insan faktörleri perspektifinden önem taşır. Tehlikeli madde veya çevre kirletici ihtiva etmenin personelin emniyeti ve destek kaynağı ihtiyaçlarına etkisi vardır.

Tasarıma etki ara yüzünün oluşturulması kapsamında başlangıç noktası olarak kullanılabilecek kontrol listesi aşağıda verilmiştir;

* Uygulanabilir olan alanlar için kapaklar sağlandı mı ve açılır kapanır mı?
* Açıklıkların boyut ve konumu erişim için yeterli mi?
* Etiketlemeler yapıldı mı? Etiketlerin kapsaması gereken bilgiler yeterli mi?
* Kapaklara erişim için gerekli bağlantılar minimize edildi mi?
* Herhangi bir araç olmadan erişim sağlanabiliyor mu?
* Erişim için alet gerekiyorsa, sayılar minimize edildi mi ve standart aletlerin kullanımı sağlanabiliyor mu?
* Modüller ve komponentler arası erişim uygun mu?
* Tehlikeli malzemeler tanımlandı mı ve minimize edildi mi?
* Bir bakım görevini yerine getirirken koruyucu ekipman kullanmak gerekiyor mu? (Bu cevap BGA kaynak gereksinimlerine girdi olacaktır).
* Erişim gereksinimleri bakım sıklıkları ile uyumlu mu?

İnsan faktörleri ve ergonomi ile ilgili olarak MIL-HDBK 1472 ve DEF STAN-00-25 standartları referans olarak alınabilir.

İnsan faktörleri kapsamında gereksinimlerin tanımlanması ve bu gereksinimlerin lojistik açıdan da değerlendirilmesi gerekmektedir. İlave gereksinim tanımlama ihtiyacı ortaya çıkarsa sistem gereksinimlerine lojistik gereksinim olarak eklenmelidir. Örneğin, sistemin çalışma sıcaklığının 60 oC olduğu durum için sistem çevresel gereksinimleri kapsamında gereksinim tanımlanmış olabilir ancak sistemi doğrudan personel kullanacaksa sıcaklığa karşı koruyucu ekipmanla ilgili lojistik gereksinimi ya da personelin temas edeceği yüzeylerle ilgili alınacak tasarım önlemine ilişkin gereksinimin de tanımlanması gerekmektedir. Diğer taraftan insan faktörleri analizi ile ortaya çıkan sonuçların BGA kapsamında da uygulanması gerekmektedir. Örneğin, limitin aşıldığı bir bakım görevi varsa, ek bakımcılar, taşıma kolları eklenebilir ya da kalemin ağırlık yada boyutları kişi kaldırma limitlerini aşıyorsa ilgili bakım görevi için mekanik olarak taşıma tanımlanabilir.

=== 6.2.10. DEMODELİK ===
Ürünün ömür devrinin uzunluğuna bağlı olarak, muhtemel demodelik durumlarının geliştirme safhasında ele alınması önemlidir. Demodelik sorunu, kullanıcı makamına teslim edilen sistemin önleyici veya düzeltici bakımı için yedek parça, sarf malzemesi veya ikmalde zafiyet oluşması ile ortaya çıkar.

Demodelik sorunları ortaya çıkmadan önce (proaktif yaklaşım) veya çıktığı durumlarda (reaktif yaklaşım) sistemin işlevselliğini koruyabilmek için eyleme geçmek gerekli olacaktır. Bu durumda alınabilecek tipik kararlar yeniden tasarım/modifikasyon, ömürlük satın alma veya sistemin hurdaya ayrılarak yeni bir sistemin devreye alınması vb’dir. Bu nedenle, bir sistemin tasarımı esnasında veya belli bir tasarıma uygun sistem veya alt sistem seçimlerinde, demodelik sebebiyle gelecekte bazı elemanların değiştirilme ihtimalini akılda tutmak gerekir.

Demodeliği doğru yöneterek yüksek maliyetlerden kaçınmak mümkündür.

Demodelik yönetiminde amaç, sistemin demodeliği oluşmadan uyarı veren bir sistem kurmak, böylelikle demodelik oluştuğundaki yüksek maliyetlerden ve kullanıma hazır olma oranının düşmesinden kaçınmaktır.

Teknolojik eskimeye ise genellikle modernizasyonlar ile çözüm bulunmaktadır.

Sistemin tasarımı yapılırken teknolojik, ekonomik, siyasi vb. öngörülerde bulunularak uzun yıllar ikmal sorunu yaşanmayacak sistemleri veya parçaları tercih etmek ileride oluşabilecek ikmal problemlerinin önüne geçecektir (Detaylı bilgi için Bkz. [https://tssodypwiki.ssb.gov.tr/index.php/Sistem_%C3%96m%C3%BCr_Devri_Y%C3%B6netiminde_Demodelik_Y%C3%B6netimi_Rehberi TSSÖDYP-08 Sistem Ömür Devri Yönetiminde Demodelik Yönetimi Rehberi]).

=== 6.2.11. DESTEKLENEBİLİRLİK ===
Desteklenebilirlik, bir ürünün kullanılabilmesi ve idame edilebilmesi için gerekli olan bütün kaynakların yeterli miktarda sağlanma derecesine dair bir ölçüttür. Desteklenebilirlik sadece ürün değil bütün lojistik destek kaynaklarını (teknik dokümantasyon, destek ekipmanı, yedek parça, personel vb.) kapsar.

Sistem tasarımı esnasında, idame edilebilirlik ve güvenilirlik hususları dikkate alınarak sistemi desteklemek için ihtiyaç duyulacak kaynakların miktarı azaltılabilir. Aktif bakım süreleri ile lojistik ve idari gecikmelerin toplamından oluşan kullanım dışı kalma süresi (downtime) bu şekilde azaltılabilir. Daha çok destek kaynağına ihtiyaç duyan bir sistem bu kaynaklarda yaşanacak sıkıntı ve bekleme risklerine daha çok maruz kalacaktır.

=== 6.2.12. MALİYET ETKİNLİK ===
ELD’nin ve aynı zamanda LDA’nın en önemli konularından bir diğeri maliyet etkinliktir. Maliyet etkinlik, sistemin maliyet ve sistem etkinliği hedefleri ile destek maliyetleri üzerinde birbiri ile ilişkili etkileri bakımından alternatiflerin (faaliyetler, yöntemler, yaklaşımlar, silah sistemleri, destek sistemleri, vb) analizinden türetilen karşılaştırmalı bir değerlendirmedir.

Tasarım ve tasarım ilişkili kararların ÖDM üzerinde önemli etkisi vardır. Alternatif tasarım çözümleri arasında, destek kaynaklarını da içeren karşılaştırmalı analizlerin yapılması gereklidir. Maliyet etkinlik bu anlamda kullanıma hazır olma karakteristiği ile ÖDM’nin dengelenmesidir.

Desteklenebilir sistemlerin maliyet etkin bir şekilde işletme ve idamesi için her alanda tasarım iyileştirmesi yapılabilir. Örnek olarak idame edilebilirlik kapsamında yapılan tasarım geri bildirimleri ile bakım onarım süreleri azaltılarak maliyet etkinlik bir açıdan sağlanmış olur.

Ayrıca sistemin ÖDM analizi yapılarak analizde çıkan yüksek maliyet kalemlerine odaklanmak suretiyle kullanım ve destek maliyetlerinin düşürülmesi hedeflenir.

=== 6.2.13. YAZILIM TASARIMI ===
Yazılım tasarımı; ürün tasarımlarının ayrılmaz bir parçasıdır. Yazılım tasarımı, bu bölümde daha önce tanımlanan bazı özellikleri kazandırabilmek üzere hassasiyetle ele alınması gereken bir konudur.

EK-H’de tanımlanan yazılım destek faaliyetlerinin sonuçları dikkate alındığında, sistemin kullanıma hazır olma gereksinimini karşılamak üzere yazılımın nasıl tasarlanacağı ve gerçekleştirileceğine dair bazı kararlar alınması gerekmektedir.

== 6.3. TASARIMA ETKİ ==
LDA’nın genel hedefleri tasarımı etkilemek, en etkin destek konseptini oluşturmak ve lojistik destek kaynak gereksinimlerini belirlemektir. Tasarımda serbest hareket edebilme özgürlüğü (esneklik) ve tasarımı etkileme fırsatları program/proje türlerine göre değişmektedir. Bu durum strateji belirlerken temel girdiyi oluşturur.

Geliştime programlarının yapısı aşağıdaki şekilde çeşitlilik gösterebilir:

* Savunma ve güvenlik sistemi ve destek ürünlerinin en baştan geliştirildiği yeni geliştirme programları
* Mevcut bir ürün için sistem/alt sistem tasarım değişiklikleri/iyileştirmeler
* İhtiyaç makamı/kullanıcı veya bir tedarikçi tarafından yürütülen ve mevcut teknolojiyi kullanan hızlandırılmış geliştirme programları

Dolayısıyla bir geliştirme programındaki tasarım esnekliği ve olası tasarım etkisi derecesi değişkendir. Genellikle, bir geliştirme programı, birden fazla değişik yapının bir kombinasyonudur. LDA faaliyetleri ve hedefleri de buna uygun şekilde odaklanmalıdır. Ayrıca, bir programda destek sistemi için tasarım esnekliği söz konusu iken ürün için bu esneklik daha az olabilir veya tersi durum da söz konusu olabilir.

Tasarımcılar, tasarım faaliyetlerinin başlangıcından itibaren güvenilirlik, idame edilebilirlik, kullanıma hazır olma ve desteklenebilirlik hedeflerine yönelmiş olmalıdırlar.

Diğer taraftan, alt yüklenici tarafından gerçekleştirilen tasarım faaliyetleri de kurum içi tasarım gibi ele alınmalıdır. Tasarım faaliyetleri daha başlamadan tasarımı etkileyebilmek üzere alt yükleniciye özel LDA hedefleri ve gereksinimlerinin sağlanması, detaylı takvimlerin oluşturulması gerekmektedir. LDA gereksinimlerinin gözden geçirilmesi ve değerlendirilmesi de proje kapsamında gerçekleştirilen gözden geçirme toplantılarının gündemine dahil edilmelidir. Altyüklenici ve tedarikçileri dahil eden, “aşağıdan yukarıya” gözden geçirmeler de uygulanabilir olduğu ölçüde planlanmalıdır.

Desteklenebilirliği belirleyen tanılama özellikleri, arayüzler, güvenilirlik tahminleri, demodelik değerlendirmeleri, bileşen işlevleri gibi teknik tasarım bilgileri tasarım dokümantasyonun parçası olmalıdır.

Gözden geçirmelerde gündeme alınabilecek bazı konular aşağıda belirtilmiştir:

* LDA’nın iş dağılım ağacına göre yürütülmesi,
* Önerilen tasarım özelliklerinin desteklenebilirliği, maliyeti, kullanıma hazır olmayı ve yeni veya kritik destek kaynakları gereksinimlerini içerecek şekilde LDA açısından değerlendirilmesi,
* Karşılaşılan, önerilen, alınan düzeltici faaliyetler (değerlendirmedeki destek alternatifleri, değerlendirme ve ödünleşim analiz sonuçları, varolan ürünlerle yapılan karşılaştırmalı analiz, önerilen veya alınan tasarım yada yeniden tasarım eylemleri vb.),
* LDA gereksinimlerinin gözden geçirilmesi,
* Hedef belirleme veya ulaşma yolundaki ilerleme,
* Gerekli, tamamlanan, planlanan LDA dokümantasyonu,
* LDA’yı etkileyen tasarım, planlama, konfigürasyon değişiklikleri ve analiz problemleri.

= 7. KULLANIM ve DESTEK SAFHALARINDA LOJİSTİK DESTEK ANALİZLERİ =
Ürün Ömür Devrinin ilk safhalarında, LDA metodolojisi kullanılarak geliştirilen destek faaliyetleri, ürüne ait kapasite ve kullanım gereksinimlerinin karşılandığını, ömür devri maliyetlerinin optimize edildiğini ve ürünün sürdürülebilir olduğunu garanti eder. Kullanım safhası süresince ise bir ürünün bakım ve çalışabilirliğinin sürekliliğini sağlamak için; kullanıcıdan alınan geribildirim verilerinin analiz edilerek, ilk varsayımlar ile gerçek kullanıma ait deneyim ve verilerin karşılaştırılması, uygulanacak olan destek faaliyetlerinin izlenmesi, değerlendirilmesi ve gerekmesi halinde güncellenmesi ve/veya uyarlanması faaliyetleri yürütülecektir.

Kullanım safhası LDA, ürün ömür devri faaliyetlerinin vazgeçilmez bir parçasıdır. Ürün kullanıma alındıktan sonra, ilgili hizmet içi veriler toplanmalı ve tanımlanmış destek gereksinimlerine karşı analiz edilmelidir. Destek gereksinimleri ürün ömür devri boyunca ihtiyaca göre değişiklik gösterebilmektedir. Bu nedenle, LDA metodolojisi uygun şekilde güncellenerek ürün destek gereksinimlerine yönelik çözüm ve önerilerin sürekli iyileştirilmesi sağlanmalıdır.

Bu aktiviteler neticesinde, destek çözüm ve önerileri:

Kullanım dönemi LDA faaliyetlerinin olumlu etkileri arasında aşağıdakiler sayılabilir:

* Ürün kullanılabilirliğinin arttırılması
* Ürünü desteklemek için gerekli kaynakların gerçek kullanım dönemi ile uyumlulaştırılması ve gerekli olması halinde iyileştirilmesi
* Modifikasyonlar ile ürünün geliştirilmesi
* Lojistik hacmin azaltılması
* Lojistik destek maliyetinin düşürülmesi

Kullanım dönemi safhasında LDA faaliyetlerinin uygulanması hem kullanıcı hem de yüklenici için bir kazan-kazan yaklaşımı oluşturmaktadır çünkü:

* Yüklenici, fiili ürün kullanımı hakkında bilgi alma ve ürün destek hususlarını öngörme noktalarında daha iyi bir pozisyona sahip olmakta ve destek sorunlarının çözümünde etkinliği arttıracak yeteneklerini geliştirmektedir.
* Kullanıcı ise, yüklenicinin ürün desteklenebilirliği ve destek sistemi verimliliğine getirdiği sürekli iyileştirmelerden faydalanarak ihtiyacının sürekli olarak sağlanması durumuna sahip olabilmektedir.

Kullanım dönemi LDA aktivitelerinin derinliği ve kapsamı yaşanacak değişikliklerin ölçeğine bağlı olacaktır. Bu değişiklikler aşağıdakilerden kaynaklanabilir:

* Ürün değişiklikleri ve yarı-ömür güncellemeleri (Bazen ‘teknoloji ekleme’ olarak da adlandırılır); bu seçenek, sistemin tümü ya da bazı bölümlerinde gerçekleştirilecek tasarım güncellemelerinin ve yenilemelerin, uygulanabilir olması durumunda ürün ömrü boyunca hangi noktalarda yapılacağının önceden kararlaştırılmasını gerektirir.
* Operasyonel ve çevresel gereksinim değişiklikleri veya operasyonel ve çevresel koşullardaki değişiklikler; bu değişiklikler, verilen destek üzerindeki etkilerin belirlenmesi için değerlendirilmelidir. Gerekli görülen analiz tekrarları sonucunda ürün veya destek çözümünde de değişiklikler gerekebilir.
* Mevzuat değişiklikleri; eğer değişiklikler ürün ile alakalı ise verilen destek çözümü üzerindeki etkileri değerlendirilmelidir.

Kullanım safhası LDA süreci genel hatlarıyla Şekil 10‘da verilmiştir.
[[Dosya:Şekil10 Kullanım Safhası LDA Süreci.jpg|alt=|sol|küçükresim|600x600pik|Şekil 10 Kullanım Safhası LDA Süreci]]

Kullanım ve Destek safhalarında LDA, kullanıcının teknik, lojistik ve ekonomik gereksinimlerine uyumluluğu sağlamak için ürün destek kaynaklarını – gerektiğinde – incelemeyi amaçlar. Bu incelemeler aşağıdaki nedenlerden dolayı tetiklenebilir:

* Elde edilen ve tahmin edilen sonuçlar arasında tutarsızlık olması
* Kullanıcı talebini karşılamak ya da harici kurallar ve mevzuata uyumlu olmak için üründe modifikasyon ve değişiklik yapılması
* Kullanım ve destek geri bildiriminin, risk ve fırsat yönetimini destekleyen genel sürecin bir parçası olarak dikkate alınıp optimizasyon alanlarının aranması

Kullanım dönemi boyunca birkaç LDA tekrarı yapılabileceği için LDA faaliyetlerinin sonunda bir Konfigürasyon Yönetimi (KY) sürecinin işletilmesi hayati önem taşır. Bu, kapsamlı bir konfigürasyon kontrolü, muhasebe ve denetim içerir. Buna ek olarak, kullanım dönemi LDA, ürünün hizmete girişinde hazır bulunması gereken bir kullanım ve bakım geri bildirim sistemine de ihtiyaç duyacaktır.
=== 7.1.1. KULLANIM VE DESTEK SAFHASI VERİ ANALİZİ VE LDA ===
Ürünle ilgili kullanım ve destek safhalarında herhangi bir konfigürasyon değişikliği, durumununda etki analizinin gerçekleştirilmesi ve bu değişikliklerin idame edilen ürünlerde, değişiklik yönetimi ve sapmaların sahadaki birimlere uygulanmasının planlaması ve yönetimi önem arz eden konuların başında gelir.

Kullanım ve destek safhalarında öne çıkan konfigürasyon yönetimi faaliyeti yüklenici tarafından desteklenen her bir ünitenin destek varlıklarının (destek ekipmanları, test program setleri, eğitim dokümanları ve yardımcı malzemeleri, el kitapları ve yazılımlar) konfigürasyon bilgilerinin takip edilebilirliğinin sağlanmasıdır. Eğer bu kalemlerde herhangi bir değişiklik varsa bu değişiklik, sapma ve feragat önerilerinde (MDT) değişen konfigürasyon bilgilerinden dolayı değişmesi muhtemel destek unsurları ve ELD elemanlarının (kullanıcı el kitapları, bakım kitapları, bakım araçları, tamir kitleri, yedek parçalar vb.) değişiklikten nasıl etkileneceği detaylı bir şekilde tanımlanmalıdır.

Sistemin envantere girmesiyle birlikte sistemin kullanım verilerinin toplanması önemli olacaktır. Destek kaynaklarının gerçek kullanımdaki durumları (bakım ihtiyaçları, eğitim yeterlilik durumu, yedek parça ihtiyaç durumu vb.) ve sistem performansının izlenmesi için bu verilerin toplanarak gerekli değerlendirmelerin yapılması gerekmektedir. Kullanım ve destek safhaları kapsamında toplanan veriler, güvenilirlik ve bakım yapılabilirlik gereksinimleri ile ilgili olarak kullanım başarısının ne olduğuna karar vermeyi ve destek çözümünün eksikliklerinin belirlenmesini mümkün kılacaktır. Bu verilerin analiz edilmesi, eksikliklerin sebebinin anlaşılmasını ve uygun çözümlerin geliştirilmesini sağlayacaktır. Hizmet içi kullanım döneminde toplanan kullanım verileri ile daha önceden yapılmış olan lojistik destek analiz faaliyetlerinin bir kısmının ya da tamamının tekrarlanması gerekebilir.

Tekrarlanması gereken lojistik destek analiz faaliyetlerinin hangileri olduğu ve tekrarlanacak olanların da kapsamı ve detay seviyesi aşağıda örnek olarak verilen değişikliklere bağlı olacaktır;

* Ürün modifikasyonları ve yarı ömür güncellemesi (eskimiş ya da demode olmuş kalemlerin değiştirilmesi de dahil edilebilir)
* Operasyonel ya da çevresel gereksinimlerin değişmesi durumunda bunun sağlanan destek üzerine etkilerinin değerlendirilmesi gerekir. Bu değerlendirme sonucunda, tekrar yapılması gereken analizler ve dolayısıyla destek çözümü ile ilgili değişiklikler ortaya çıkabilir.
* Kullanım esnasında, tasarım ve geliştirme döneminde yapılan analiz sonuçları ile kullanım esnasında ortaya çıkan durumlar arasında tutarsızlıklar varsa, ilgili analizlerin tekrar gözden geçirilmesi gerekebilir.
* Kullanım ve destek geri bildirimlerinin dikkate alınmasıyla optimizasyon alanları araştırılabilir ve buna bağlı olarak gerekli olduğu düşünülen LDA faaliyetleri de tekrar gözden geçirilebilir.
* Kullanıma hazır olma, yedek parça sayıları gibi tasarım güvenilirlik değerlerine göre yapılan hesaplamaların, operasyonel ortam koşullarındaki mevcut durumu yansıtacak şekilde güncellenmeleri gerekmektedir.

Şekil 11’de kullanım ve destek safhaları bakım gözden geçirme süreci verilmiştir.
[[Dosya:Şekil 11 Kullanım ve Destek Safhası* Bakım Gözden Geçirme Süreci.jpg|alt=|sol|küçükresim|700x700pik|Şekil 11 Kullanım ve Destek Safhası* Bakım Gözden Geçirme Süreci]]

<nowiki>*</nowiki>Destek safhası, destek planlama ve destek uygulama olmak üzere iki aşamadan oluşmaktadır. Bu süreçte destek uygulama aşaması kastedilmektedir.

=== 7.1.2. MODİFİKASYON VE DEĞİŞİKLİK UYGULAMASI İÇİN KULLANIM SAFHASI LDA ===
LDA faaliyetlerine olan ihtiyaç, tasarlanan ürünün Kullanım ve Destek Safhası’nın başlamasıyla birlikte son bulmamaktadır. Bir ürüne ait en uzun safha olan Kullanım ve Destek Safhası süresince, ürün konfigürasyonunda yapılacak modifikasyonlardan dolayı LDA faaliyetlerinin ihtiyaç duyulan derinlikte tekrar icra edilmesi ve modifikasyonlardan önce üretilmiş olan verilerin güncellenmesi veya bazı faaliyetlerin baştan yapılması gerekebilir. Bu nedenle LDA faaliyetleri boyunca üretilen verilerin ve analiz faaliyetleri süresince alınan kararların, ürünün envanterden çıkarılması safhasına kadar kayıt altında tutulması ve güncelliğinin sağlanması gerekmektedir.

Sürece ilişkin örnek Şekil 12’de verilmiştir.
[[Dosya:TSSODYP06.12.jpg|alt=|sol|küçükresim|615x615pik|Şekil 12 Modifikasyon ve Değişiklik Uygulaması İçin Kullanım Safhası LDA]]

=== 7.1.3. KULLANIM VE DESTEK SAFHALARI MALZEME YÖNETİMİ ===
Kullanım ve destek safhaları boyunca ürünler üzerinde güvenilirliği ve/veya performansı iyileştirmek, bir sistem elemanını/ekipmanı millileştirmek, vb. amaçlarla çeşitli modifikasyonlar yapılabilir. Müşteri’nin, ikmal desteğini planlayabilmesi ve tedarik süreçlerini yönetebilmesi için ürün konfigürasyonunda yapılan bu modifikasyonların konfigürasyon yönetimi faaliyeti kapsamında işlem görmesi ve ilgili veri kayıtlarının güncellenmesi gerekmektedir.

Kullanım ve destek safhaları süreci malzeme yönetimi süreci Şekil-13’te verilmiştir.
[[Dosya:Şekil13 Kullanım ve Destek Safhaları Malzeme Yönetimi Süreci.jpg|alt=|sol|küçükresim|700x700pik|Şekil 13 Kullanım ve Destek Safhaları Malzeme Yönetimi Süreci]]

= 8. LDA VE KONFİGÜRASYON YÖNETİMİ =
Konfigürasyon Yönetimi (KY), farklı ürün konfigürasyonlarının doğru belirlenmesi, değişikliklerin kontrol edilmesi ve değişikliklerin uygulanma durumunun kayıt altına alınmasını sağlayan bir disiplindir.

KY, ürün ağacının en alt seviyesinden başlayarak gerçekleştirilir ve istenilen, tasarlanan, üretilen, desteklenen ürün bilgisini belirlerken değişikliklerin teknik ve operasyonel performansının yanı sıra ELD faaliyetleri üzerindeki etkilerini de değerlendirir.

== 8.1. LDA SÜRECİNDE KONFİGÜRASYON YÖNETİMİ ==
LDA faaliyetlerinin çıktıları, bir projenin KY süreçlerine dahil olmalıdır. KY sürecinin ana unsurlarından birisi ürün kırılımının oluşturulmasıdır. Ürünün konfigürasyonunu tanımlamak için oluşturulan kurallar ürün kırılımının ELD dahil bütün proje alanlarında izlenebilirliğini sağlamalıdır.

Belirlenen kurallara göre geliştirilen ürün kırılımı, ilgili ürünün farklı konfigürasyonlarını da kapsayıcı özellikte olmalıdır. Ürün kırılımının, ELD’nin tüm alanları için temel olacak şekilde oluşturulması oldukça önemlidir.

Projede farklı amaçlara yönelik farklı ürün kırılımları oluşturulabilir. Genel olarak çoğu projede ürünün tasarım kırılımı bir veri yönetim sistemi altında kontrol edilir. Aynı ürün için bir LDA kırılımı oluşturulabileceği gibi operasyonel ve bakım verilerinin geri beslemelerine yönelik ayrı bir kırılım da oluşturulabilir. Farklı amaçlar için farklı kırılımlar oluşturulması, çoğu zaman bu kırılımlar arasında tutarsızlıkların oluşmasına ve farklı disiplinler arasında ürün ilişkili verilerin iletilmesinde sorunlara yol açmaktadır. Bu nedenle proje kapsamında yürütülen konfigürasyon faaliyetleri ile izlenebilirliğin kurulması ve kayıt altına alınması önemlidir (Bkz. [https://tssodypwiki.ssb.gov.tr/index.php/Sistem_%C3%96m%C3%BCr_Devri_Y%C3%B6netiminde_Konfig%C3%BCrasyon_Y%C3%B6netimi_Rehberi TSSÖDYP-11 Sistem Ömür Devri Yönetiminde Konfigürasyon Yönetimi]).

= 9. LOJİSTİK YÖNETİM VE LDA İLİŞKİSİ =

== 9.1. LOJİSTİK DESTEK ANALİZ KAYITLARI (LDAK) ==
LDA süreci sonunda ortaya çıkan veriler mühendislik ve ürün destek faaliyetleri tarafından kullanımlarını geliştirmek için belirli biçimlere uyarlanır ve kayıt altına alınırlar. Bu veriye lojistik yönetim bilgisi adı verilir ve çeşitli endüstri standartlarına uygun olarak oluşturulan veri tabanı da Lojistik Destek Analiz Kayıtları (LDAK) olarak adlandırılır.

Sözleşmelerde yer verilen LDAK gereksinimleri planlanan destek konsepti ile uyumlu ve uyarlanmış içerikte olmalıdır. Müşteri uyumsuzlukları ve gerekenden fazla olabilecek sözleşmesel teslimatları önleyebilmek için programın çeşitli işlevsel alanlarından gelecek verilere yönelik gereksinimleri koordine etmelidir. LDAK, nihayetinde bütün ELD unsurlarını dikkate alan etkin bir ürün destek paketi oluşturulmasında yardımcı olur.

Bir LDA veri tabanı içerisinde genel olarak aşağıdaki başlıklara yönelik veriler kayıt altına alınır:

* İşlevsel Gereksinimler
* Operasyonlar ve Bakım
* Güvenilirlik gereksinimleri ve analizlerin sonuçları
* Görev analizleri
* Personel becerileri ve eğitim
* Destek ekipmanları
* Test Altındaki Birim
* Tesisler
* Taşınabilirlik
* Tedarik ve kataloglama verileri

Bir projede lojistik yönetim verisi olarak nelerin kayıt altına alınacağı ve LDA sonrası oluşturulacak dokümantasyon, projeye özel olarak ve ürünün ömür devri safhasına göre uyarlanmalıdır. LDAK’ın uyarlanması analizler için seçilen standart, gerçekleştirilmek üzere seçilen analizler ve bunların derinliği konusunda verilen kararlarla uyumlu olmalıdır. Uyarlama LDAK için referans alınacak standardı/spesifikasyonu, ihtiyaç duyulan veri elemanlarını ve formatını, tercih edilen veri transfer ve/veya raporlandırma yönetmini de kapsamalıdır.

== 9.2. LDAK STANDARTLARI/SPESİFİKASYONLARI ==
LDAK kayıtlarına yönelik standartlar, bir sistem veya nihai ürünün geliştirilmesi veya tedarik edilmesi esnasında üretilen lojistik destek analiz bilgilerini tanımlar. Bu konuda geliştirilen standartlar genel olarak ELD programını desteklemek için gerekli olan teknik verilerin oluşturulması, idamesi, temini ve kullanımında maliyet etkinliği sağlamaya yöneliktir.

LDAK’a yönelik yaygın olarak bilinen standart Amerika Savunma Bakanlığı tarafından 1991’de yayımlanan MIL-STD-1388-2B’dir. Standardın amacı, LDA Kayıtlarının geliştirilmesi ve teslimatına yönelik bir örnek gereksinimleri ortaya koymaktır. MIL-STD-1388-1A’da tanımlı olan lojistik destek analizlerden uygulanabilir olanlarının gerçekleştirilmesi sonrasında ortaya çıkan bilgilerin kayıt altına alınmasını düzenler. Standart içerisinde yer alan veri elemanı tanımları (data item definition) üretilecek verilerin tanımı ve biçimini belirleyerek standardizasyonunu sağlar. MIL-STD 1388-2B, 1996 yılında iptal edilmiş olmasına rağmen günümüzde halen bazı projelerde kullanımı devam etmektedir.

MIL-HDBK-502, Tedarik Lojistiği kılavuzudur. Plan ve program ilkelerini ortaya koyan MIL-STD-1388-1A kılavuzuna benzerdir. Bir anlamda, MIL-STD 1388 1A gelişerek MIL-HDBK-502’ye dönüşmüştür. MIL-PRF-49506 (Lojistik Yönetim Bilgisi) lojistik destek tanımlarıdır ve MIL-STD-1388 2B’nin yerini almıştır. Lojistik kayıtlarının “neler” olması gerektiğini değil de “nasıl” tutulması gerektiğini tarif etmeye çalışır. Gene de MIL-STD 1388-2B başlıklarının yaklaşık üçte birini kullanır. Aynı şekilde; MIL-STD 1388-2B gelişerek MIL-PRF-49506’ya dönüşmüştür.

SAE Lojistik Komitesi’nin yayımladığı GEIA-STD-0007 standardı ise; XML kullanılmasını, verilerin ve bunlarla yapılan işlemlerin, karakter tahdidi olmaksızın saklanmasını sağlar. MIL-STD 1388-2B’de yer alan başlıklar aynen korunur ancak, bu standardın vurguladığı nokta ilişkisel veri tabanlarında olduğu gibi verinin nasıl kaydedileceğinden ziyade nasıl transfer edileceğidir (örn., XML şemaları). Amerika’da yaygın olarak kullanılan standart artık GEIA-STD-0007’dir.

Yukarıdaki standartlara ek olarak AeroSpace and Defence Industries Association of Europe (ASD) bünyesinde geliştirilmekte olan S-Serisi spesifikasyonları arasında hem LDA süreçlerinin hem de LDAK yapısının tanımlandığı ASD/AIA S3000L spesifikasyonu vardır. S3000L’de yer alan veri yapıları da GEIA’da olduğu gibi XML formatındadır.

LDAK konusunda dikkate alınması gereken önemli bir nokta, standartların herhangi bir programda ihtiyaç duyulabilecek her türlü veri elemanını tanımlamaya yönelik oldukları, bu nedenle belli bir projede nasıl kullanılacaklarına özellikle dikkat edilmesi gerektiğidir. Standartlarda yer alan veri elemanı tanımlarının yaklaşık %15-20 kadarı tek bir projede gerçekten uygulanabilir olmaktadır.

== 9.3. ORTAK KAYNAK VERİ TABANI ==

* LDAP’da tanımlanan faaliyetler, belirlenen aday kalemler üzerinde uygulandıkça, ortaya o aday kalemlerin sahip olduğu özelliklerle ve birbirleri ile ilişki içinde olan pek cok bilgi çıkmaya başlar (örn., bir pompanın hata türleri, hata türünü gidermek için uygulanması gereken bakım/onarım faaliyeti, bakımda ihtiyaç duyulan yedek parçalar, bu yedek parçaların paketleme bilgileri, vb.). Bu bilgiler yapısal bir veri tabanı, yani ilişkili veriler arasındaki bağlantıların ve referansların tanımlanabildiği bir veri tabanı uygulaması içinde kayıt altına alınabilir. Bu sayede ürünün tüm ömür devri boyunca yaşayacağı değişimler de düşünüldüğünde ürüne ait LDA kayıtlarının yönetimi, tutarlılığı, revizyon takibi gibi konularda ciddi kazanımlar elde edilebilir. Bu özellikleri taşıyan veri yapıları/standartları, 9.2 numaralı konu başlığında yer almaktadır.

* LDA kayıtlarının tutulacağı bir veri tabanı uygulaması hem ihtiyaç makamı hem de yükleniciler açısından projenin kapsam ve türü, ürünün karmaşıklığı, LDA verilerinin miktarı vb. parametrelere göre bir ihtiyaç olabilir. Bu ihtiyaç, LDA faaliyetlerinin ürünün tüm ömür devri süresince devam eden canlı faaliyetler olmasından kaynaklanmaktadır. Ana Yükleniciler ve alt yükleniciler LDA faaliyetlerinde çoğunlukla tasarım ve test verilerini kullanarak, ürünün envantere girdiği andan itibaren ihtiyaç duyulacak lojistik verileri geliştirirler. İhtiyaç Makamı ise tasarım ve test verileri yerine saha verilerini kullanarak Ana Yüklenici’den temin ettikleri LDA kayıtlarını idame ederler ve gerekli hallerde güncellerler veya güncellenmesi için yüklenici ile görüşürler. Ana Yüklenici ve İhtiyaç Makamı arasında LDA kayıtlarının transfer edilebilmesi için her iki kurumun kullandığı veri tabanı uygulamasının da aynı standart veri yapısını desteklemesi gerekmektedir. Aksi takdirde iki farklı veri yapısını birbirine dönüştürebilecek bir diğer yazılıma daha ihtiyaç duyulacaktır.

== 9.4. VERİ TÜRLERİ VE SEÇİMİ ==
Bir projede hangi verilerin üretileceği yüklenici ve ihtiyaç makamı’nın birlikte yapacağı bir çalışma ile LDAP’da tanımlanan LDA faaliyetleri, faaliyetlere ait kural ve varsayımlar, bu faaliyetlerin derinliği, uygulanacak LDAK standardı ve aday kalem listesi göz önünde bulundurularak belirlenmelidir. LDA kayıtlarının yönetiminde ürünün ömür devri süresince hem müşterinin hem de yüklenici’nin rol ve sorumlulukları olduğundan dolayı, ortak bir çalışma yürütülmesinde fayda vardır. Bu verilerin projenin hangi safhalarında üretileceği, hangi sıklıkla paylaşılacağı/transfer edileceği ve yayınlanacağı ise LDA zaman planına göre belirlenmelidir.

== 9.5. VERİ SINIFLANDIRMASI ==

=== 9.5.1. MÜŞTERİ TARAFINDAN SAĞLANAN VERİLER ===
Müşteri, ürünü geliştiren/temin eden firmanın ulaşması gereken hedef değerleri tanımlamalıdır. Bu değerler, İhtiyaç makamının/kullanıcının operasyonel gereksinimlerine, hali hazırda kullanılmakta olan benzer sistemlerin lojistik verilerine ve lojistik operasyonlarının yarattığı maliyetlerin bir arada değerlendirilmesiyle belirlenebilir. Örneğin 20 tankın görevlendirildiği bir operasyonda operasyonun başarıyla tamamlanabilmesi için 18 tank yeterli oluyorsa, tedarik edilecek tankın hedef güvenilirliğinin kabaca %90 olduğu söylenebilir veya bir alt sistemin erişim kolaylığını tanımlamakta hedef bakım süreleri tanımlanarak ilgili alt sistemin kolay sökülebileceği bir tasarıma gidilmesi sağlanabilir. İhtiyaç Makamı/Tedarik Makamı’nın sağlayacağı veriler rasyonel ve ölçülebilir olmalıdır. Bu verilerin bir kısmının belirlenmesinde yüklenici ve müşteri birlikte çalışarak envanterdeki ürünler üzerinde ölçümler ve analizler yapabilir ve ortak bir paydada buluşulması sağlanabilir.

=== 9.5.2. YÜKLENİCİ TARAFINDAN ÜRETİLEN VERİLER ===
Yüklenici, müşteri tarafından tanımlanan hedef değerleri ve ürünün mühendislik ve test verilerini kullanarak belirlenen LDA faaliyetlerini yürütür. Bu faaliyetlerinin sonucu olarak da ürünün özelliklerini yansıtan lojistik verilerini üretir.

== 9.6. LDAK’IN GELİŞTİRİLMESİ VE YÖNETİLMESİ ==
LDAK ile ilgili karşılaşılan önemli sorunlardan birisi veri tabanının nasıl geliştirileceğidir. İhtiyaç duyulan bilgiden ziyade spesifik veri elemanlarına konsantre olmak uygulamayı temel amacından saptırabilmektedir. Veri tabanı geliştirilirken odaklanılması gereken temel nokta verileri türeten analiz sürecinin kendisidir.

LDAK’ın ürünün ömür devri boyunca kullanılacak verileri içermesi bir başka hususu daha ön plana çıkartır. Başlangıçta analizler çoğunlukla sistemin güvenilirliği, idame edilebilirliği, test edilebilirliği ve sistem kullanımının çevresel etkileri konusundaki kesitirimlere dayanır. Gerçekte bu kestirimler çoğunlukla sanıldığı kadar hassas değildir. Sistemi ömür devri boyunca destekleyecek kaynakların ayarlanması ve yönetilebilmesi amacıyla bu verilerin zaman içerisinde gerçek kullanımdan toplanan veriler ile yer değiştirmesi önemlidir.

== 9.7. LDAK’IN KULLANILMASI ==
LDAK veri tabanı, sadece oluşturulup bir yerlerde dosyalanmak için değil gerçek anlamda kullanılmak üzere tasarlanmalıdır. Oluşturulan/kayıt altına alınan veriler bütün ELD elemanları tarafından program kapsamında detaylı destek planlarının ve gereksinimlerinin oluşturulması için kullanılmalıdır. LDAK içerisinde yer alan veriler, sistemi desteklemek için gerekli lojistik kaynakları belirlemenin yanı sıra, desteklenebilirliği artırmaya yönelik tasarım değişikliği ihtiyaçlarını belirlemek için de kullanılır.

Bir proje başlatıldığında LDAK’ın nasıl kullanılacağının belirlenmesi, kullanım yöntemlerinin tanımlanması ve herkes tarafından anlaşılması açısından önemlidir. LDAK’ın gerçek faydalarının ve potansiyelinin anlaşılabilmesi öncelikle ortak kaynak veri tabanı konseptinin ve LDAK raporlama kabiliyetlerinin anlaşılmasını gerektirir.

== 9.8. LDA ÖZETLERİ/ RAPORLARI/ÇIKTILARI – STANDARTLARA GÖRE KARŞILAŞTIRMA ==
LDAK veri tabanlarından çeşitli konu başlıklarına göre raporlar üretilmesi mümkündür. Söz konusu raporlar veri tabanı içerisinden detaylı ama kullanılabilir bir biçimde veri derlemesi yapılarak hazırlanmalıdır.Raporlar, çok zaman gerektiren veya kritik bakım görevleri, personel ve beceri gereksinimleri, eğitim ihtiyaçları, bakım atama çizelgeleri (maintenance allocation chart) ve test ve detsek ekipmanı gereksinimleri gibi konuları kapsayabilirler.

= 10. FİZİKSEL DESTEK KAYNAK GEREKSİNİMLERİNİN BELİRLENMESİ VE DESTEK ÜRÜNLERİNİN OLUŞTURULMASI =
Fiziksel kaynak gereksinimi olarak nitelendirilen ELD ürünlerinin oluşturulmaya ne zaman başlanacağı teknik dokümantasyon ve resimli parça verilerinin mevcut olması dahil birçok faktöre bağlıdır. Tasarım ya da bakım konseptinde ortaya çıkabilecek değişikliklerin de lojistik ürünler üzerine etkisi oldukça fazladır. Bu kapsamda, dikkate alınması gereken ELD ürünleri şunlardır:

* Teknik Dokümantasyon
* Malzeme Desteği (resimli parça verileri)
* Genel ve Özel Destek Ekipmanları
* Eğitim
* Üretim tesisleri uzun süren planlama/gerçekleştirme/kalifikasyon gibi sebeplerle tipik bir ELD ürünü olarak kabul edilmezler. Üretim tesisleri vb.leri geniş kapsamlı olarak projelerin erken safhalarında dikkate alınmalıdır.

== 10.1. TEKNİK DOKÜMANTASYON ==
Teknik dokümantasyon iki ana bölümden oluşur;

* Sistemin bakım ve onarımına ilişkin el kitapları
* Sistemin kullanımına ilişkin el kitabı (Kullanıcı Dokümantasyonu)

Geliştirme safhası boyunca gerçekleştirilen lojistik destek analiz faaliyetleri ile esas alınacak bakım konseptinin ne olduğu, ne tür personel, destek ekipmanı ve yedek parçaların gerekli olduğu ve bakım onarım faaliyetlerinin nasıl gerçekleştirileceği gibi bilgileri tanımlanmış olur. Bu nedenle, sistemin bakım onarım faaliyetleri ile ilgili olan teknik dokümantasyonun geliştirilmesine, analiz çalışmalarının bir seviyeye gelmesiyle başlanmalıdır.

Teknik el kitaplarının lojistik destek analiz sonuçlarına uygun olarak hazırlanması durumunda hatalı teknik dokümantasyon oluşturma ve dolayısıyla yeniden işleme riski ortadan kalkacaktır. Ancak bazı durumlarda, teknik dokümantasyon geliştirme süreci zaman kısıtları veya sözleşmesel şartlar nedeniyle projenin daha erken safhalarında başlamak zorunda olabilir. Bu durumda verilen bilgiler analizler sonuçlanana kadar bir seviyede kalacaktır.

Sistemin bakım ve onarımına ilişkin teknik dokümantasyon geliştirme sürecinin temeli LDA veri tabanında dokümante edilen bakım görevleridir. Ürünün ömür devri boyunca ihtiyaç duyacağı lojistik destek analizleri ile tanımlanan tüm görevler bakıma ilişkin dokümantasyonlarda yer almalıdır. Bu amaçla, Yüklenici bünyesinde teknik dokümantasyon geliştiren ekipler ile LDA faaliyetlerini yürüten ekipler arasında sıkı bir koordinasyon sağlanması önemlidir. LDA ile teknik dokümantasyon arasındaki ilişki Şekil 14’de gösterilmiştir.
[[Dosya:Şekil14 LDA ve Teknik Dokümantasyon.jpg|alt=|sol|küçükresim|550x550pik|Şekil 14 Lojistik Destek Analizleri ile Teknik Dokümantasyon Arasındaki İlişki]]

Ürünün kullanımına yönelik teknik dokümantasyonun (Kullanıcı El Kitapları vb.) geliştirilmesi genel olarak LDA sürecinden bağımsız bir faaliyettir. Özellikle operasyonel analiz faaliyetleri sonucu ortaya çıkan bilgilerin kullanıcı dokümantasyonu geliştirilirken de dikkate alınması gereklidir. Bu alanda tanımlanan ve LDA veri tabanında dokümante edilen görevler, hem bakım-onarım hem de kullanım için olan teknik dokümantasyonun bir parçası olabilir.

LDA faaliyetleri sonucu belirlenen ve LDA veri tabanında dokümante edilen her bir bakım/onarım görevi ürünün bakım/onarımına ilişikin teknik dokümantasyona yansıtılmalıdır. Bununla birlikte, bakım onarım teknik dokümantasyonu, dokümante edilmiş LDA görevlerinin ötesinde bilgiler de içerebilir (LDA veri tabanında her bir bakım faaliyeti olmayabilir ya da her parça LDA adayı olmayabilir). LDA’nın amacı, doğru derinlikte bakım ve maliyet ile doğrudan ilişkili kalemlerin analiz edilmesidir. Teknik dokümantasyonlarda kalan ekipmanların ya da parçaların da göz önünde bulundurulması ve bunlara ilişkin bilgilerin de yer alması gerekmektedir. Bu bilgilerin detayları ve derinliği de müşteri ve yüklenici arasındaki anlaşmalara bağlıdır ve gözden geçirmelerin gündem maddelerinden olmalıdır.

Dikkat edilmesi gereken hususların bazıları aşağıda verilmiştir;

* Teknik dokümantasyon için bakım görevleri hazır mı?
* LDA çıktıları teknik dokümantasyon için yeterli değilse, yine de doküman hazırlıklarına başlamanın riskleri nelerdir?
* LDA veri tabanının bir parçası olmayan hangi ilave faaliyetlerin teknik dokümantasyon içerisinde yer alması gereklidir?

== 10.2. İKMAL DESTEĞİ ==
Yedek parçaların neler olduğu, LDA faaliyetleri ile belirlenir. Bakım konseptine bağlı olarak yedek parçaların belirlenmesi büyük ölçüde farklılık gösterebilir. Örneğin 2 seviyeli basit bir bakım senaryosunda komple bileşenler değiştirilecek ve sistemin operatörü tarafından onarım faaliyetleri gerçekleştirilmeyecektir. Bu durumda sadece az sayıda yedek parça tanımlanacaktır. Bununla birlikte, tanımlanmış bütün bileşenlerin ek olarak ihtiyaç duyduğu standart parçalar gibi ilave yedek parçalar da tanımlanabilir.

Belirleyici soru LDA içindeki arızanın boyutudur. Teorik olarak son parçaya kadar bir parçalama mümkündür ancak çaba çok büyük olduğundan bu kabul edilemez olacaktır. Bu nedenle uygulamada, LDA süreci içindeki yedek parçaların tanımlanması belirli bir seviyede duracaktır. Tipik olarak bakım ve maliyet faktörleri LDA süreci içerisinde tanımlanmalıdır. Bu bilgi LDA veri tabanındaki bakım görevlerinin gereksinimleri kapsamında belgelenmiştir. Teknik destek için açıklandığı gibi benzer bir süreç de malzeme desteği için oluşturulmalıdır. LDA faaliyetlerinin ilerlemesine bağlı olarak malzeme desteği ile ilgili lojistik ürünlerin oluşturulmasının başlangıcı LDA'nın ilgili bakım ve maliyet faktörleri tarafından tetiklenmelidir.

Aynı durum teknik dokümantasyon için de geçerlidir; çoğu durumda, gerekli tüm yedek parçalar LDA tarafından belirlenemez. Bununla birlikte, bir LDA görevi tarafından belirlenen tüm yedek parçalar malzeme destek kapsamında değerlendirilmelidir. Tablo 9 farklı türdeki yedek parçalara genel bir bakış ve bunların tanımlama sürecinde dikkate alınması gerekenleri göstermektedir.

'''Tablo 9 LDA Tarafından Belirlenen Farklı Yedek Parça Türleri Listesi'''
{| class="wikitable"
|'''Yedek Parça Tipi'''
|'''Açıklama'''
|'''LDA ile Malzeme Desteği Arasındaki Korelasyon'''
|-
|Komple ekipman parçası
|· Bakım odaklı

· Maliyet odaklı

Kullanım sahasında yer değiştirme görevlerinin (planlı veya plansız) değiştirilmesi için gerekli yedek parçalar (kullanım sahasında herhangi bir onarım yapılmadan komple ekipmanın değiştirilmesi)
|Ekipmanın gerekli bir yedek parça olarak tanımlanması LDA'da tanımlanan bir bakım görevi tarafından onaylanmalıdır.
|-
|Özel yedek parça
|Kullanım sahasında ekipman onarımı veya bakım işleri için gerekli yedek parçalar (ekipmanın onarımı kullanım sahasında yapılacaktır)
|Bu bileşenin gerekli bir yedek parça olarak tanımlanması LDA'da tanımlanan bir bakım görevi tarafından onaylanmalıdır.
|-
|Standart parçalar
|Kullanım sahasındaki onarım veya bakım görevleri için gerekli standart parçalar (örneğin, parçaların veya contaların takılması) (ekipmanın onarımı kullanım sahasında yapılacaktır)
|Bu bileşenin gerekli bir yedek parça olarak tanımlanması LDA'daki eksiklik kaynaklı malzeme desteği tarafından onaylanmalıdır.
|-
|Sarf malzeme
|Sıvı, gres, özel kimyasal ürünler, kaynak malzeme, tutkal gibi gerekli sarf malzemeleri
|Bu bileşenin gerekli bir yedek parça olarak tanımlanması malzeme desteği veya LDA tarafından onaylanabilir.
|}
LDA ile malzeme desteği drasındaki ilişki Şekil 15’de gösterilmektedir.
[[Dosya:Şekil15Lojistik Destek Analizleri ile Malzeme Desteği Arasındaki İlişki.jpg|alt=|sol|küçükresim|550x550pik|Şekil 15 Lojistik Destek Analizleri ile Malzeme Desteği Arasındaki İlişki]]

== 10.3. GENEL VE ÖZEL DESTEK/TEST EKİPMANLARI ==
Sistemler ve ekipmanlar genel olarak kullanımlarını ve idamelerini desteklemek için ilave ekipmanlara ihtiyaç duyarlar. Bir ürünün kullanım ve bakımı için gerekli olan herhangi bir ekipman destek ekipmanı olarak adlandırılır. Destek ekipmanı bazen, özel bir kullanım için tasarlanmış bir “özel ekipman” olabileceği gibi bazen de birden fazla kullanım alanı olan “genel bir ekipman” olabilir

LDA sürecinde ilgili destek ve test ekipmanının belirlenmesi ana görevlerden birisidir. Gerekli destek/test ekipmanının zamanında tedarik hazırlığının yapılmasının kritik önemi vardır ve bu anlamda ortak ve özel destek/test ekipmanı arasındaki ayrım yapılmalıdır. Özellikle, özel destek/test ekipmanlarına yönelik ihtiyaçlar ve gereksinimleri LDA sürecinde belirlenmelidir. Bu belirlemeden sonra da geliştirme ve tedarik süreci başlamalıdır.

LDA veri tabanındaki statü bilgileri destek ve test ekipmanlarından sorumlu birimler tarafından faaliyetleri başlatmak için kullanılabilir. Ancak, bazı durumlarda destek/test ekipmanı gereksinimleri dokümante edilmiş LDA görevleri dışında kaynaklardan da türetilebilir. Örneğin genel aletlerin belirlenmesi için mutlaka LDA veri tabanına giriş yapılması gerekmez (basit bir tornavida için belirli bir LDA görevi tarafından ihtiyaç belirlenmesi gerekmez).

Destek ekipmanı gereksinimlerinin belirlenmesinde bakım konseptinin büyük bir rolü vardır. Kaç seviyede bakım yapılacağı ve her seviyede gerçekleştirilmesi beklenen bakım görevlerinin neler olabileceği, genel olarak destek ekipmanı ihtiyaçlarını tanımlayan temel girdidir. Teorik olarak, organizasyonel seviyede gerçekleştirilecek bakımların ara seviye ve fabrika/depo seviyesi bakımlara nazaran daha az destek ekipmanına ihtiyaç duyması beklenir. Buna paralel olarak organizasyonel seviyede kullanılacak destek ekipmanlarının maliyetleri de normalde diğer seviyelere göre daha düşük olacaktır.

Destek ekipmanı gereksinimlerini etkileyen önemli bir diğer faktör üründe yer alacak cihaz içi test (BIT) kabiliyetidir. Örneğin, bir ekipman bir arızayı sistem içerisinde küçük bir modüle kadar ayrıştırabilecek test kabiliyetine sahipse ve operatör bu modülü genel aletler kullanarak söküp değiştirebiliyorsa hem organizasyonel hem de diğer bakım seviyelerinde karmaşık bir destek ekipmanı ihtiyacı olmayabilir. Bu durumda ara seviye sistemin tamamında hata ayrıştırması yapmak yerine değiştirilen modüllerin onarımına odaklanılabilir.

Sistemin kullanıma hazır olma hedefleri gerek duyulacak destek ekipmanlarının belirlenmesinde dikkate alınması gereken bir diğer faktördür. Güvenilirlik, İdame Edilebilirlik ve Kullanıma Hazır Olma unsurları öncelikle belirlenmelidir. Bu sayede ürünle ilgili işletim ve bakım ihtiyaçlarına uygun ekipmanların belirlenmesi sağlanacaktır. Tasarım olgunlaştıkça, destek ekipman tür ve miktarlarına dair gereksinimler Bakım Görev Analizi (BGA) kapsamında belirlenir.

Destek ekipmanları belirlenirken işletme ve çevre şartları göz önünde bulundurulmalı, ürün için yapılan lojistik destek analizleri ve ürün özellikleri dikkate alınarak yedek malzeme stoklaması yapılmalı, ürünü kullanıma almak için gerekli test, ayar ve kalibrasyon cihazları belirlenmelidir. LDA ve test ekipmanları arasındaki ilişki Şekil 16’da gösterilmektedir.
[[Dosya:Şekil16LDA ve Test Ekipmanları Arasındaki İlişki.jpg|alt=|sol|küçükresim|500x500pik|Şekil 16 LDA ve Test Ekipmanları Arasındaki İlişki]]

== 10.4. EĞİTİM ==
Gerekli bakım görevleriyle ilgili bütün bilgiler (örn. performans detayları, gerekli destek ekipmanı, zorluk ve kritiklik, süre, çalışma adımları, gerekli personel sayısı) sağlanana kadar bakım faaliyetleriyle ilgili eğitim ihtiyaçları belirlenemez. Eğitim gereksinimlerini tanımlamanın ilk adımı bir Eğitim İhtiyaçları Analizi (EİA) olmalıdır. Bu, LDA tarafından belirlenen bakım görevlerine dayanabilir. LDA ve eğitim arasındaki ilişki Şekil 17’de gösterilmektedir.
[[Dosya:Şekil17LDA ve Eğitim.jpg|alt=|sol|küçükresim|550x550pik|Şekil 17 LDA ve Eğitim Arasındaki İlişki]]

Eğitimin içeriğini belirleme ve geliştirme süreci müşteri ve yüklenici arasındaki anlaşmalara göre LDA sonuçları ve/veya mevcut teknik belgelerde geçen bilgiler kullanılarak sağlanmalıdır. Çünkü eğitim ekipmanlarının geliştirilmesi çok maliyetli olabilir (eğitim videoları, eğitim kuleleri, eğitim simülatörleri, vb üretimi).

Mümkün olan en iyi destek için LDA veri tabanındaki eğitim bilgilerinin belgelenmesi önemlidir. LDA veri tabanı "gerekli eğitim", personel için beceri seviyeleri veya varsa daha ayrıntılı bilgi gibi basit işaretler içerebilir. LDA veri tabanının eğitim gereksinimlerinin çıkarılmasını destekleyen sorgular içerecek şekilde tasarlanması önerilir.

== 10.5. TESİSLER VE ALTYAPI ==
Tesisler ve altyapı, bir sistemi desteklemek için gerekli olan kalıcı ve yarı-kalıcı gayrimenkul varlıklarından oluşmaktadır. Bu alanda yapılan çalışmalar, tesislerin türlerinin tanımlamasını (ör: eğitim, ekipman depolama, bakım, tedarik depolama, mühimmat depolama, bilgisayar donanım/yazılım sistemleri, ağ ve iletişim sistemleri) veya konum, alan ihtiyaçları, çevre ve güvenlik gereksinimleri ve ekipmanlarının belirlenmesi ile tesis iyileştirmelerini kapsar. Sistem çalışmasının etkililiğini en üst düzeye çıkarmaya olanak sağlayacak; eğitim, bakım ve depolama faaliyetlerinin gerçekleştirilmesi için en düşük sahip olma maliyetli tesisin belirlenmesi, planlanması, kaynak sağlanması ve satın alınması, bu öğenin amacıdır. Tesisler ve altyapı; tesis ve altyapı türlerini tanımlamak için yapılan çalışmalar, tesis ve altyapı iyileştirmeleri, konum, alan ihtiyaçları, çevre ve güvenlik gereksinimleri ve ekipmanları dahil olmak üzere bir sistemi desteklemek için gerekli olan kalıcı ve yarı kalıcı gayrimenkul varlıklarından ve altyapıdan oluşur. Yapılan LDA faaliyetleri savunma ve güvenlik sisteminin kullanımı ve idamesi için ihtiyaç duyulacak tesis ve altyapı özelliklerinin belirlenmesine katkı sağlayacaktır.

== 10.6. PAKETLEME, ELLEÇLEME, DEPOLAMA VE ULAŞIM ==
Bir ürünün normal kullanımı dışındaki paketleme, taşıma, depolama ve nakliye faaliyetleri ihtiyaca göre belirlenmelidir. Bu hususların bir kısmı analiz sonuçlarından ortaya çıkmayabilir. Ancak ürünün kullanıma alınmasıyla birlikte eksik ve/veya yetersiz bilgi sebebiyle kullanıma ilişkin hatalar olabilir. Bu nedenle, bu bilgilerin belirlenerek ilgili teknik dokümantasyonlarda belirlenmesi önemlidir.

=== 10.6.1. PAKETLEME ===
AKK ve/veya bileşenleri için paketleme konsepti aşağıda verilen örnek durumlara göre belirlenebilir;

* Paketleme kısa süreli ve/veya uzun süreli depolama için mi gereklidir?
* Paketleme nakliye için gerekli midir ve ne tür bir nakliye yapılacaktır?
* Depolama veya nakliye için özel bir konteyner gerekli midir?
* Depolama veya nakliye döneminde aşırı iklim koşullarından dolayı özel koruma gerekli midir? (Örneğin deniz taşımacılığı)
* Nakliye veya depolama süresince, örneğin bakım faaliyetleri (depolama görevleri) gerçekleştirmek için ürün ambalajından çıkarılıp yeniden ambalajlanması gerekir mi?
* Destek ekipmanı ve tesisleriyle ilgili muhafazanın çıkarılması ve paketin açılması için ne gereklidir?

=== 10.6.2. ELLEÇLEME ===
Ürün taşıma görevleri aşağıda verilen örnek durumlara göre belirlenebilir;

* Taşıma için gerekli güvenlik önlemleri ve sınırlamalar dikkate alınmalıdır.
* Normal kullanım haricinde herhangi bir şekilde park etmek, çekmek, vinçle kaldırmak veya taşımak için gerekli talimatlar belirlenmelidir.
* Ürünün yer değiştirmesi için gerekli talimatlar, örneğin takma noktaları, gerekli adaptörler, özel bileşenler için destekler, denge ağırlıkları, kriko prosedürleri belirlenmelidir.
* Ürün taşımada gereken ek ekipman ve malzemeler önceden belirlenmelidir. (örn. çekme çubukları veya kablolar)

=== 10.6.3. DEPOLAMA ===
Depolama süresi boyunca ve depolama sonucunda ürün işlevselliğini garanti etmek için depolama prosedürleri analiz edilmeli ve belgelenmelidir. Depolama koşulları aşağıda verilen örnek durumlara göre belirlenebilir;

* Gerekli depolama uzun süreli depolama veya kısa süreli depolama çözümü olarak mı değerlendiriliyor?
* Ürün/bileşen özel hassasiyette depolanacak mı?
* Depolanacak ürün bileşenlerini çıkarmak ve bu bileşenleri özel şartlarda ayrı olarak depolamak gerekli midir?
* Depolama sırasında yapısal ve sistem bütünlüğünü korumak için ne tür bir kontrol ve önleyici bakım gereklidir? (örn. Tekerlek dönüşü, elektrik gücü, motor çalışması ve basınç kontrolleri vb.)
* Depo içi bakım için bir zaman çizelgesi sağlandı mı?
* Depolama süresince beklenen aşırı iklim koşulları (ısı, don, nem vb.) var mı?
* Depolamaya giriş için gerekli özel teknikler var mı? (örn. Temizlik ve koruma, sıvı sistemi boşaltma/yenileme, statik topraklama, koruyucu boşluk, özel bileşenlerin sökülmesi vb.)
* Depolamadan çıkarılması ve kullanıma geri dönmesi için gerekli özel teknikler var mı? (örn. Koruma ve temizleme, sıvı sisteminin yenilenmesi, özel bileşenlerin tekrar montajı, fonksiyonel kontroller, kullanıma hazırlama)
* Saklama süresi boyunca ne tür bir güvenlik önlemi gereklidir? (örn. Hareketli bir bileşenin demirlenmesi/sabitlenmesi ve bloke edilmesi, karanlık bir depolama alanında tutulup ışığa maruz kalmaması vb.)
* Depolanan ürün/bileşenin ömrü ile bağlantılı olarak depolama süresini dikkate almak gerekli midir?

=== 10.6.4. ULAŞIM ===
Müşteri gereksinimlerine dayanarak, ürünün taşınabilirliğinin analizi aşağıda verilen örnek durumlara göre belirlenebilir;

* Nakliye için hazırlanma ve nakliye sonrası yapılması gerekli faaliyetler için harcanan iş gücü ve süre nedir?
* Personel, araçlar, sarf malzemeleri ve tesislerle ilgili nakliye sonrası hazırlık ve iyileştirme için gereksinimler nelerdir?
* Özel koşullar altında nakliye için ek çevresel şartlar nelerdir? (örneğin deniz taşımacılığı, kumlu çöl ortamı, nem, ısı, don gibi aşırı iklim koşulları gibi)
* Özel koşullar altında nakliye için ek güvenlik gereksinimleri nelerdir? (örn. Hava taşımacılığı durumunda bir nakliye uçağı içinde demirleme/sabitleme)
* Taşıma süresince gerekli servis işlemleri nelerdir? (özellikle uzun yolculuklarda)
* Ürün bileşenlerini nakliye için sökmek veya tüm ürünü belirli bir seviyeye indirgemek gerekli midir?
* Konteyner/taşıma kutusu kavramı düşünülmeli mi?
* Kızakların ve/veya paletlerin kullanımı kabul edilebilir mi?

= 11. LDA VE KAYITLARINA İLİŞKİN FAALİYETLERİN UYARLANMASI =
Sürecin uyarlanmasında bu rehberden etkin olarak faydalabilmek kullanıcıların kendi projelerine uygun olan işlevleri seçmeleri ve uygulamaları ile mümkün olabilir. Rehberin bölümleri ilgili projeye münferit olarak dahil edilebilir veya kapsamdan çıkartılabilir. Uyarlama aynı zamanda analize tabi tutulacak aday kalemlerin (ürün bileşenleri) çeşitliliği ve sayısı, bir aday kalem için yapılacak analizlerin neler olacağı, analizler esnasında kullanılacak veriler ile analiz bilgilerinin nasıl kayıt altına alınacağı konularında da gerçekleştirilebilir.

Projenin/Programın erken safhalarında bir LDA stratejisi belirlemek ve LDA programı oluşturmak uyarlama için yapılması gereken ilk adımlardır.

Uyarlama esnasında dikkat edilmesi gereken önemli bir nokta sadece LDA sürecinin değil genel anlamda ELD sürecinin uyarlanması, farklı ELD disiplinleri açısından referans alınabilecek standartların/süreçlerin birbirleri ile uyumlaştırılarak LDA veri tabanına sonuçların yansıtılması ve uyarlama esnasında varsa eskiden kalan/mevcut verilerin (legacy data) nasıl ele alınabileceği, yeni standartalara ve yazılım araçlarına nasıl geçiş yapılabileceği gibi konuların da ele alınmasıdır.

Lojistik iş tanımlama toplantısı, uyarlamanın ilk olarak tartışılacağı ve kararlaştırılacağı adımlardan birisi olabilir.

LDA sürecinin bir proje kapsamında uyarlanması aşamalı bir faaliyettir. Genel LDA çerçevesinin belirlenmesinden LDAK içerisinde yer alacak veri elemanlarının belirlenmesine kadar devam eder. Bu kapsamda uyarlama aşamaları şöyle sıralanabilir:

* Projede uygulanacak analizlerin seçilmesi ve her bir aday kalem için hangi analizlerin uygulanabilir olduğunun belirlenmesi
* Projeye özel iş kurallarının belirlenmesi (örn. Ürün kırılımı için seçilecek yöntem, OSA yöntemi, lojistik FMEA, vb.)
* Proje gereksinimlerine göre belirlenen standart/spesifikasyon içerisinden veri elemanlarının seçilmesi

== 11.1. PROJE KAPSAMINDA ANALİZ GEREKSİNİMLERİNİN BELİRLENMESİ, SEÇİM KRİTERLERİ ==
Bölüm 5.4.1’de tanımlanan potansiyel lojistik destek analizleri içerisinden proje kapsamında hangilerinin gerçekleştirileceğinin belirlenmesi uyarlama sürecinin önemli bir adımdır.

Tablo 10’da LDA analiz faaliyetlerinin seçimi ve aday kalemlere atanması için dikkate alınabilecek örnek kriterler yer almaktadır. Seçim kriterleri de projeye göre farklılık gösterebileceğinden özel durumlar da dikkate alınarak uyarlanmaları mümkündür. Seçim faaliyetinden önce, kullanılacak kriterler üzerinde tüm paydaşlar arasında uyumlaştırılmış olması gereklidir. Bu uyumlaştırma LDA GGT’de sağlanabilir.

'''Tablo 10 Analiz Faaliyetleri Seçim Kriterleri'''
{| class="wikitable"
|'''Kriter Grubu'''
|'''Kriter'''
|'''Öneri'''
|-
| rowspan="6" |Kullanım tecrübesine sahip olunan kalemler
|Halen karşılaştırılabilir koşullarda kullanılmakta olan kalemler
|Mevcut analiz verilerinin orta derecede dönüşümünün yapılması
|-
|Halen kullanılan -fakat karşılaştırılabilir şartlar altında olmayan- kalemler
|Mevcut analiz verilerinin dönüşümünün dikkatli yapılması
|-
|Majör modifikasyon gerektirmeden kullanılabilecek RAHAT kalemler
|Mevcut analiz verilerinin orta derecede dönüşümünün yapılması
|-
|Minör/Majör değişiklik gerektirecek kalemler
|Mevcut analiz verilerinin dikkatli dönüşümünün yapılması yeni analizlerin gerçekleştirilmesi
|-
|Bilinen bir teknolojiye bağlı olarak yeni geliştirilen kalemler
|Analiz faaliyetlerinin gerekli detay seviyesinde yapılması (önemle tavsiye edilir)
|-
|Yeni bir teknolojiye bağlı olarak yeni geliştirilen kalemler
|Analiz faaliyetlerinin gerekli detay seviyesinde yapılması gereklidir.
|-
| rowspan="3" |Geniş bir bakış açısı gerektirdiği ya da özel öneme sahip olduğu için değerlendirilmesi gereken kalemler
|Potansiyel göreve hazır olma ve/veya maliyet etmenleri
|Bu kalemler için kriterlerin LDA GGT’da detaylandırılması gerekir.
|-
|Müşterinin ısrarlı ilgisine konu olma
| rowspan="2" |Kalemlerin LDA GGT’de detaylandırılması gerekir.
|-
|LDA ilişkili sözleşmesel yükümlülükler
|-
| rowspan="4" |Kendi tasarım özellikleri gereği veya yerleşim yerinden dolayı değerlendirilmesi gereken kalemler
|İlgili arıza/hata sıklığı, iş yükü, özel lojistik gereksinimlere (personel ve/veya) ilişkin olarak Bakım Önemli Kalemler
|Bu kalemler için kriterin LDA GGT’de detaylandırılması gerekir.
|-
|Planlı bakıma veya ömür limitlerine tabi kalemler
|Planlı bakım analizi için kriterlerin LDA GGT’de detaylandırılması gerekir.
|-
|Özel olaylardan kaynaklanan önleyici bakıma tabi kalemler
|Özel olay analizi için kriterlerin LDA GGT’de detaylandırılması gerekir.
|-
|Yerleşim yeri nedeniyle potansiyel hasarlarla karşılaşmaya müsait kalemler
|Hasar analizi için kriterlerin LDA GGT’de detaylandırılması gerekir.
|-
| rowspan="4" |LDA aday tipleri
|Tam aday
|Uygulanabilir analizlerin yapılması, sonuçların LDA veri tabanında kayıt altına alınması,
|-
|Kısmi Aday
|Temel seviyede bilgilerin LDAK içerisinde kayıt altına alınması
|-
|Aday aileleri
|Bir grup bileşenin tek bir LDA adayı kalem olarak ele alınması, uygulanabilir analizlerin yapılması ve sonuçların LDAK içerisinde kayıt altına alınması,
|-
|Standart prosedürlere tabi kalemler
|Temel seviyede bilgilerin LDAK içerisinde kayıt altına alınması
|-
| rowspan="5" |Müşteri tarafından bilgi talep edilen durumlar
|LDA sürecinden beklenen bilgiler
| rowspan="4" |LDA GGT süresince, müşteri ile uyumlaştırılmalı ve üzerinde mutabık kalınmalıdır.
|-
|Tavsiye edilen lojistik destek esaslarına dair öneri
|-
|Olası alternatiflerin tanımlanması (donanım, yazılım, destek konseptleri için) ve ilişkili sonuçları (ör., lojistik destek gereksinimleri)
|-
|Tavsiye edilen bakım konseptleri ve ilgili bakım görevlerine dair teklif
|-
|İlgili lojistik destek maliyetlerinin tahmini
|İlişkili lojistik destek gereksinimlerin belirlenmesi, lojistik destek maliyet tahmini, erken dönem sistem/proje kararlarına yönelik bilgiler (önemli maliyet etkisi)
|}
Her bir LDA aday kalemine hangi analizlerin uygulanacağına dair seçimle ilgili kararların dokümante edilmesi için bir matris kullanılabilir. Seçimler esnasında, bütçe ya da zaman gibi kısıtlar varsa, buna göre önceliklendirme yapılabilir.

Bu matris, LDA adaylarının tanımlanması ve görev seçim kriterleri ile buradan çıkan sonuçları içerecek şekilde LDA GGT öncesinde yüklenici tarafından hazırlanmalı ve toplantı esnasında müşteri ile uzlaşılan kararları yansıtmalıdır. Dokümanın, değişiklikleri yansıtması, ‘kazanılmış dersler’e ilişkin sonuçları kapsaması ve sistemin ömür devri boyunca izlenebilirliği sağlayan yaşayan bir doküman olması önemlidir.

LDA aday kalemleri ve uygulanacak analizlere ilişkin taslak bir listenin, teklif süreci esnasında LDA görev atamalarına ilişkin rehberlik sağlaması ve risk azaltma amaçlı olarak müşteriye sunulması tavsiye edilir.

Seçilen analiz faaliyetlerini kayıt almaya dair matrise ilişkin bir örnek Tablo 11’da verilmiştir.

'''Tablo 11 Analiz Faaliyetleri Öneri Matrisi'''
{| class="wikitable"
|Seviye
|Aday Tipi
|Adı
|Genel LDA Gerekleri
|Karşılaştırmalı Analiz
|İnsan Faktörü Analizi
|Konfigürasyon Değerlendirme
|Güvenilirlik Analizi Değerlendirmesi
|İdame Edilebilirlik Analizi
|Test Edilebilirlik Analizi
|HTEA / HTEKA
|Hasar Analizi

|Özel Olay Analizi
|Planlı Bakım Analizi
|OSA
|BGA
|Yazılım Destek Analizi
|Lojistik İlişkili Operasyonlar Analizi
|Eğitim İhtiyaçları Analizi (TNA)
|Sıralama
|-
|1
|Sistem
|<nowiki>-</nowiki>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|-
|1.1
|Alt Sistem
|<nowiki>-</nowiki>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|-
|1.1.1
|Aday Değil
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|-
|1.1.2
|Tam Aday
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|-
|1.1.3
|Kısmi Aday
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|-
| colspan="20" |0 = Uygulanabilir Değil 1 = İsteğe Bağlı 2 = Tavsiye Edilen 3 = Kuvvetle Önerilen 4 = Zorunlu
|}
LDA adayları tarafından yönlendirilmeyen bütün genel görevlere ilişkin tavsiyeler farklı dokümanlarda kayıt altına alınmalıdır.

== 11.2. ÖMÜR DEVRİ SAFHALARINA GÖRE ANALİZLERİN UYARLANMASI ==
LDA aktivitelerinin gerçekleştirilebilmesi için projenin farklı safhalarında farklı veri setleri erişilebilir durumda olmalıdır. Tanımlanan LDA görevlerinden bazıları projenin erken safhalarında gerçekleştirilebilirken bazıları tasarımla ilgili detaylı ve nihai bilgilerin oluştuğu dönemlerde yürütülebilir. Ömür devri safhalarına (Bkz.[https://tssodypwiki.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)] ) göre analiz faaliyetlerinin akış süreci Şekil 18’de örnek olarak verilmiştir.
[[Dosya:TSSÖDYP06 Ş.18.jpg|alt=|sol|küçükresim|689x689pik|Şekil 18 Ömür Devri Safhalarına Göre Analiz Akış Süreci]]

LDA aktiviteleri geliştirme safhasının sonunda bitmez. Üretim safhasında da üründe gerçekleştirilecek değişikliklerin kapsamına bağlı olarak LDA birkaç kez daha tekrarlanabilir. Bu durum kullanım safhasında da geçerlidir. Kullanım safhasında ürüne kapsamlı modifikasyonlar yapılması söz konusu olabilir. Dolayısıyla LDA sürecinin belirli şartlara bağlı olarak tekrarlanması gerekmektedir. Bu yüzden, lojistik verinin ve kararların dokümantasyonunun sistem ömür devri boyunca envanterden çıkarma safhasına kadar devam ettirilmesi gerekir.

==== <big>11.2.1.1. Erken Dönem Analiz Faaliyetleri</big> ====
Projenin erken safhalarında, LDA aktiviteleri düşük seviyede bilgi gerektiren durumlarla sınırlıdır. LDA GGT’den önce operasyonel ve müşteri gereksinimleri ile ilgili bilgiler normalde erişilebilir durumdadır. Dolayısıyla LDA GGT’den önce LDA sürecinin temel kurallarına ilişkin taslağın hazırlanması GGT çalışmalarını hızlandıracaktır.

Analiz altındaki sistem veya kalem hakkında detaylı bilgi bu aşamada normalde erişilebilir değildir. Bu aşamada, yalnızca sürecin uygulanması için temel koşul ve kurallar erişilebilir durumdadır, ancak genel LDA ihtiyaçlarının belirlenmesi analizi, karşılaştırmalı analiz, insan faktörleri analizi, operasyonlar analizi, konfigürasyon değerlendirmesi gibi bazı analizlere LDA sürecinin erken aşamalarında da başlanabilir.

==== <big>11.2.1.2. Tasarım ve Geliştirme Dönemi Analiz Faaliyetleri</big> ====
LDA süreci, tasarım ve geliştirme dönemi boyunca tasarım süreci ile beraber yürümelidir. Bu durum, çok erken faz ya da tasarım donduktan sonraki faz hariç, tüm LDA aktivitelerine uygulanır. Bu aktiviteler aşağıdaki gibidir:

* Konfigürasyon değerlendirmesi
* Güvenilirlik analizi değerlendirmesi
* İdame edilebilirlik analizi
* Test edilebilirlik analizi
* HTEKA / HTEA
* Hasar analizi
* Özel olay analizi
* Planlı bakım analizi
* Onarım seviyesi analizi
* Bakım görev analizi
* Yazılım ve veri yükleme/indirme/taşıma analizi
* Yazılım tasarım ve yazılım bakım analizi
* Lojistik İlişkili Operasyonlar analizi

Tasarım donduktan sonra, lojistik ile ilgili veri toplanma işlemi büyük ölçüde tamamlanmış olmalıdır. Bu yüzden, detaylı veri gerektiren analiz aktiviteleri, sabitlenmiş tasarımı garantiye almak ve maliyetli analiz aktivitelerini tekrarlamak riskini azaltmak için tasarım sürecinin son aşamalarında gerçekleştirilmelidir.

* Operasyonel senaryoların simülasyonu
* Eğitim ihtiyaçları analizi

==== <big>11.2.1.3. Kullanım Dönemi Analiz Faaliyetleri</big> ====
Kullanım safhası boyunca, lojistik analiz faaliyetleri tekrarlanacak olup bu durum azalan ölçüde olacaktır. Eğer ürün teknik güncellemeler ya da tasarım değişikliğine uğrarsa, lojistik gereksinimleri dikkate alan yeni bir analiz yapılmalıdır. Analizin derinliği ve genişliği, sistemin tipine ve değişikliğin ölçüsüne bağlı olacaktır.

==== <big>11.2.1.4. Sistem Ömür Devri Safhalarındaki Aktivitelerin Özeti</big> ====
Tablo 12, tüm ömür devri safhalarındaki potansiyel analiz aktivitelerinin özetini göstermektedir. (ör: veri ve bilgi toplama, yönetim, teknik/lojistik analizler ve hazırlık görevleri). Bu tablo, tasarım ve geliştirme dönemine ek olarak Ön Tasarım Gözden Geçirme (ÖTGG) ve Kritik Tasarım Gözden Geçirme (KTGG) gibi tipik aşamaları da içerir.

'''Tablo 12 Sistem Ömür Devri Safhalarındaki Aktivitelerin Özeti'''
{| class="wikitable"
| rowspan="2" |'''Ön Konsept & Konsept Safhası'''
| colspan="3" |'''Geliştirme Safhası'''
| rowspan="2" |'''Üretim Safhası'''
| rowspan="2" |'''Kullanım Safhası (Destek Uygulama Aşaması ile birlikte)'''
| rowspan="2" |'''Envanterden Çıkarma Safhası'''
|-
|'''Yapılabilirlik çalışması'''
|'''Ön Tasarım'''

'''(PDR)'''
|'''Kritik Tasarım (CDR)'''
|-
|Performans Ürün verisi (CRD)
|Performans Ürün verisi güncellemeleri (CRD)
|
|
|
|
|
|-
|Ürün kullanım verisi
|Ürün kullanım verisi güncellemeleri (ORD)
|
|
|
|
|
|-
|
|İdame Edilebilirlik Çalışmaları
|İdame Edilebilirlik Analizleri
|İdame Edilebilirlik Analizleri Güncellemeleri
|
| rowspan="4" |Geri besleme verilerine dayanan destek konseptinin süregelen optimizasyonu→ Hizmet içi LDA

Analiz sonuçlarının ve konfigürasyon değişikliği bazlı ELD ürünlerinin güncellenmesi
|
|-
|
|Güvenilirlik Çalışmaları
|Güvenilirlik Analizleri
|Güvenilirlik Analizleri

Güncellemeleri
|
|
|-
|Karşılaştırmalı çalışmalar
|Karşılaştırmalı çalışmalar
|Karşılaştırmalı çalışmalar
|
|
|
|-
|
|
|ELD ürünlerinin geliştirilmesinin planlanması
|ELD ürünlerinin geliştirilmesi
|ELD ürünlerinin güncellenmesi
|
|-
|
|
|
|
|
|Enventerden Çıkarmanın planlanması
|
|}

= 12. EKLER =

== EK-A İNSAN FAKTÖRÜ ANALİZLERİ VE LDA ==

'''<big>1. GİRİŞ</big>'''

İnsan faktörü analizleri, LDA faaliyetleri esnasında bakım ekibi ve destek ekipmanı gereksinimlerinin belirlenmesi için kullanılabilecek kaynak veriyi sağlarlar. Bu ilişki tasarım süreci esnasında başlar ve bakım görev analizlerinin geliştirilmesi süreci boyunca devam eder.

LDA, idame edilebilirlik ve desteklenebilirlik işlevleri, potansiyel destek çözümlerinin insan faktörü gereksinimlerini de kapsayan eşik değerlerin içerisinde kalmasını sağlayacak şekilde koordine edilmelidir. Bunun için operasyonel ve bakım görevlerinin gerçekleştirilmesinde gerekli olan destek kaynaklarının ve ekip büyüklüğünün dikkate alınması gerekir. İnsan faktörü kısıtlamaları ürünün tasarımını etkilemenin yanı sıra destek ortamının oluşturulmasını da etkiler. İnsanın kısıtlı kabiliyetleri, ürün kullanımı ve desteği üzerinde kısıtlamalara yol açar.

Bu EK teknik ve LDA faaliyetleri gerçekleştiren personele yönelik olarak hazırlanmıştır. Bölümde insan faktörleri ve lojistik destek analiz süreci arasındaki ilişkiler ve entegrasyonu tanımlanmaktadır. İnsan faktörü analiz sonuçlarının projenin mümkün olan en erken safhalarında dokümante edilmesi tavsiye edilmektedir. LDA veri tabanı içerisinde insan faktörlerinin etkileri farklı yerlerde görünebilir. Uyarı ve ikazların yanı sıra, belirli bir görev yerine getirmek veya personeli olumsuz çevresel ortamda koruyabilmek için gerekli özel ekipman ihtiyaçları bu konuda örnek teşkil edebilir.

<big>'''2. LOJİSTİK DESTEK ANALİZLERİ VE İNSAN FAKTÖRLERİ'''</big>

'''<big>2.1. FİZİKSEL KABİLİYETLER VE KISITLAMALAR</big>'''

LDA ve insan faktörü entegrasyonu ürünün bütün ömür devri boyunca süreklilik arz eder. Üründe gerçekleştirilen modifikasyonlar veya önerilen tasarım değişiklikleri beraberinde bakım görevlerinde de değişiklik gerektirebilir.

LDA ve insan faktörü analizlerinin ortak hedeflerinin yanı sıra kendilerine özel amaç ve hedefleri de vardır. İnsan faktörleri antropometrik hususlar, ergonomik hususlar ve diğer fizyolojik hususlara ilişkin değişik standartlara odaklanabilir. LDA da bu standartları dikkate almalı ve potansiyel destek çözümlerini değerlendirmelidir. Bu konuya verilebilecek örneklerden biri, ortalama insan önkolunun çapıdır. Bilek hareketinin ötesinde erişim gerektiren bir panelin tasarımında uygun standartlarda verilen minimum ölçü dikkate alınmalıdır. Bu durumda, insan faktörü bütün erişim panelleri için söz konusu ölçü gereksiniminin dikkate alınmasını sağlamak üzere tasarıma etki eder. Buna ilave olarak LDA, kısıtlı hareket imkânları olan bir ortamda gerçekleştirilecek bir görevin tamamlanabilmesi için gerekli destek ekipmanlarını tanımlar. Eğer, analiz faaliyetleri esnasında alternatif tasarım çözümleri belirlenirse, bunlar tasarım sürecinde dikkate alınmak üzere tasarım ekiplerine bildirilir.

'''<big>2.2. TEHLİKELİ DURUMLARDAN KAYNAKLANAN KISITLAMALAR</big>'''

İnsan faktörlerinin dikkate alınması gereken bir başka nokta insan sağlığına karşı tehditlerden dolayı bazı aktivitelerin kısıtlanmasıdır.

Tehlikeli maddelerin ele alınması, fiziksel bütünlüğün korunması açısından katı yasal düzenlemelere tabidir. Özellikle ürün ömür devri sonunda, ürününün envanterden çıkarma safhasında insan sağlığına zararalı olabilecek malzemelere maruz kalma ve dolayısıyla insan faktörü büyük önem arz eder.

Çok sıcak veya soğuk, nemli, yeraltı veya sualtı, çok gürültülü vb. aşırı çevresel koşullar altında gerçekleştirilen faaliyetlere ilişkin kısıtlamalar da dikkate alınması gereken hususlardandır. İnsanların bu çevresel koşulların etkisine karşı korunmaları da fiziksel kısıtlamalar gibi LDA süreci içerisinde ele alınmalıdır.

<big>'''3. İNSAN FAKTÖRÜ ANALİZLERİ'''</big>

'''<big>3.1. TASARIMA ETKİ</big>'''

İnsan faktörü tasarım kısıtı ve gereksinimlerini tanımlayan çeşitli standartlar vardır. Bu standartlar, yüklenici/müşteri mutabakatında uygun şekilde referans verilmeli ve sözleşmelere dahil edilmelidir.

İnsan faktörleri niceliksel verileri bakım ekibinin becerileri, sayısı ve destek ekipmanı ihtiyaçları belirlenirken dikkate alınmalıdır. Örneğin, insan faktörleri, tek bir kişinin taşıyabileceği ağırlık limitlerini belirler. Bu limitler mekanik kaldırma araçlarını, ayaklık ihtiyaçlarını ve/veya personel sayısını belirler. Bu bilgi, tasarım alternatiflerinin değerlendirilmesi için kullanılabilir. İnsan faktörleri, bakım görevlerine uygulabilecek spesifikasyon ve standartları sağlar.

Ekip büyüklüğüne ilişkin personel gereksinimler, uygulanabilir olduğu durumlarda demografik özellikleri de dikkate almalıdır. Örneğin tamamen erkeklerden oluşan bir ekip için tanımlanacak yük kaldırma limiti, kadın erkek karma bir ekibin yük kaldırma limitinden daha yüksek olacaktır. Yani ekipmanın ağırlığı, kaldırılabilmesi için gerekli personel sayısını belirler ancak bu sayı farklı demografik özelliklere göre değişiklik gösterebilir. Ağırlık sınırlamaları, mekanik kaldırma gereksinimleri için de dikkate alınarak destek ekipmanı gereksinimlerini etkilemelidir.

<big>'''3.2. LDA İÇİN İLKELER'''</big>

LDA İş Tanımlama Toplantısı, LDA ve insan faktörü analizlerine uygulanacak kural ve ilkeleri belirlemelidir. Yüklenici ve müşteri arasında uygulanacak spesifik standart üzerinde mutabakata varmalı ve standarda yönelik istisnalar da tanımlanmalıdır.

LDA tasarım sürecinden aldığı girdileri kullanır ve her altenatif tasarım/tasarım unsurları için ödünleşim analizleri gerçekleştirir. İlk tasarım faaliyetlerinden itibaren, LDA tasarımı analiz ederek alternatiflere yönelik destek gereksinimleri karşılaştırarak tavsiyelerde bulunur. Süreç bütün olası bakım görevlerini tanımlamayı içerir. Her bakım görevi için ihtiyaç duyulacak kaynakların listesi oluşturulur. Bu kaynaklar, yedek parça, sarf malzemesi, bakım işçilik saati, eğitim, destek ve test ekipmanlarını kapsar. İnsan faktörüne özel hususlar bakım personelinin sayısı, ilgili destek ekipmanları vb’dir.

Bakım personeli sayısı, bakım görevine ilişkin gerekli beceriler, değiştirilen ekipmanın ölçüleri ve ağırlığndan etkilenir. MIL-STD 1472 gibi çeşitli insan faktörü standartları tek bir kişinin taşıyabileceği ağırlık limitlerini tanımlamaktadır. Ekipman belli bir uzaklığa taşınacaksa, bunun için de limitler söz konusudur. Bu limitler BGA esnasında dikkate alınmalıdır. Limitlerin aşıldığı durumlarda ilave personel ihtiyacı ortaya çıkacak, ekipman üzerinde tutma yeri tasarlanması gerekecektir. Bu gibi durumlarda mekanik kaldırma araçları tanımlanması da dikkate alınabilecektir.

Analiz süreci yinelemeli bir süreç olup, her tasarım değişikliğinde de tekrarlanmalıdır. LDA süreci içerisinde, detaylı BGA ürün tasarımın onaylanmasından sonra başlar. Her bakım görevi, ilgili insan faktörü standardı ile kıyaslanarak bütün bakım ve operasyon faaliyetlerinin insan faktörü limitleri içerisinde olduğu teyit edilir.

'''<big>4. DİKKATE ALINMASI GEREKEN İNSAN FAKTÖRLERİ</big>'''

Aşağıda sıralanan insan faktörleri, dikkate alınması gereken insan faktörleri açısından sınırlayıcı değildir; ancak ürün tasarımını etkileyecek ve özellikle LDA alanında destek ortamının tasarımında dikkate alınabilecek insan faktörlerine örnek olarak dikkate alınabilir.

<big>'''4.1. ANTROPOMETRİK HUSUSLAR'''</big>
* Görüş hattı (yatay ve dikey görme alanı)
* Ses sinyali gereksinimleri
* Kol, el ve başparmak için kas gücü
* Dikey çekme hareketleri için gerekli kas gücü
* Yatay çekme ve itme hareketleri için gerekli kas gücü
* Kaldırılabilecek ünitelerin azami ağırlığı
* Destek ekipmanlarının azami ağırlığı
'''<big>4.2. ERGONOMİK HUSUSLAR</big>'''
* Kumandaların tasarımı (ör. Anahtarlar, çevirme kolları, kumanda kolları, el çarkları, pedallar, düğmeler, vs.)
* Minimum tutacak ölçüleri
* Çalışma alanı tasarımı (oturarak, ayakta, mobil)
* Zor erişilebilirlik – rampa ve merdivenler
* Kapı ve erişim paneli ölçüleri
* Aydınlatma gereksinimleri
'''<big>4.3. ÇEVRESEL HUSUSLAR</big>'''
* Etkin sıcaklık
* Aşırı sıcak ve soğuk sıcaklık limitleri
* Rüzgarın soğutma etkisinin insan üzerinde etkisi
* Aşırı iklim koşullarında insan performansındaki düşmeler
* Havalandırma gereksinimleri
* Ultraviyole ışımaya maruz kalma
* Toz ve duman gibi kirliliğie maruz kalma
* Gürültü limitleri 
== EK-B HTE(K)A ve SONUÇLARININ LDA İÇERİSİNDE KULLANIMI ==
<big>'''1. GENEL'''</big>

Hata Türleri ve Etkileri Analizi (HTEA) olaya dayalı bakım analizlerinden biridir. Önleyici Bakım Analizleri ve Özel Olay Analizleri önleyici bakımlara odaklanırken HTEA ve Hasar Analizleri düzeltici bakımlara odaklanır (Hasarlar aynı zamanda önleyici bakıma da tabi olabilir).

HTEA, üründe bünyesel bir arıza oluştuğu durumda uygulanması gereken düzeltici bakım görevlerinin belirlenmesine yönelik yöntem ve karar mantığını ortaya koyar.

Bütün ekipman ve bileşenler önleyici bakım uygulansın ya da uygulanmasın hata yapmaya eğilimli olup, önleyici bakım için adaydırlar. Bazı hata/arızalar operasyon esnasında veya bir bakım görevi ya da muayene esnasında teşhis edilebilir veya gözlenebilirler (kişiler veya entegre test sistemleri vasıtasıyla). Bazı hatalar ise teşhis edilebilmekle birlikte lokalize edilemezler ve bazıları da hiç teşhis edilemezler.

Dolayısıyla birçok durumda, hatalı ünitelerin sökülmesi ve değiştirilebilmesi için öncelikle teşhis ve tespit edilmelerine yönelik ilave arıza giderme (troubleshooting) işlemlerinin yapılması gerekir. Bu işlemler:

* HTEA’dan türetilen veriler ile karakterize edilir ve LDA kayıtları altında dokümante edilmelidir,
* İlgili teknik yayınlarda dokümante edilmelidir
* Özel aletler ve test ekipmanları gerektirebilir.

HTE(K)A ve sonuçlarının LDA içinde kullanımının kapsamı:

* Mevcut dokümanlardan mümkün olduğunca yaralanmak (ör, tasarım ekibi tarafından gerçekleştirilen HTEKA) veya HTEA verisinin üzerine LDA ihtiyaçlarına göre uyarlanmış çalışma inşa etmek ya da mevcut hiçbir doküman yoksa yeni bir HTEA çalışması gerçekleştirilmesi

* Hataların tespit edilmeleri ve hatalı bileşenlerin lokalize edilmeleri için uygun vasıtaları analiz edilmesi
* Özel arıza teşhis prosedürlerine yönelik olası gereksinimlerin belirlenmesi
* Muhtemel özel alet ve test ekipmanı ihtiyaçlarının belirlemesi
* Sonuçların kayıt altına alınması

faaliyetlerini kapsar.

Süreç, ürün içerisindeki yeni geliştirilen, başka bir projeden tekrar kullanılan veya RAHAT malzeme olarak temin edilen herhangi bir bileşen için uygulanabilir.

Tasarım, geliştirme ve üretim faaliyetlerine yönelik çeşitli HTEA ve HTEKA türleri söz konusudur.

'''<big>2. TASARIM VE GELİŞTİRME FAALİYETLERİNDE HTEKA</big>'''

HTEKA, geliştirme safhasında yapılması gereken analiz faaliyetidir. Diğer taraftan ihtiyaç olması halinde (tasarım değişikliği, modifikasyon vb) ilgili safhalarda güncellenebilecek bir analizdir.

HTEKA’nın hedefi bir sistem tasarımındaki bütün hata türlerini belirlemek olmakla birlikte, birincil amacı katastrofik ve kirtik hata türlerinin erken tespit edilerek, mümkün olan en erken safhada tasarım değişiklikleri ile ortadan kaldırılması ya da minimize edilmesidir. Dolayısıyla HTEKA çalışmaları, başlangıçta ön tasarım bilgileri ortaya çıkar çıkmaz en üst sistem seviyesinde işlevsel bir HTEKA ile başlayarak daha fazla tasarım bilgisi ortaya çıktıkça alt seviyelere yaygınlaştırılarak devam eder.

HTEKA, tasarım faaliyetlerine yönelik bir güvenilirlik görevi olmasına rağmen başka amaçlarla da kullanılabilir. HTEKA veya ondan türetilmiş başka diğer analizler idame edilebilirlik, emniyet, kullanılabilirlik, LDA için ve bakım konseptinin detaylandırılması, hata tespit ve teşhisi için kullanılabilir. HTEKA’nın bu çok amaçlı kullanımı, aynı proje kapsamında gerçekleştirilen faaliyetlerin kopyalanmasının önlenmesi açısından planlama aşamasında dikkate alınmalıdır.

<big>'''3. LDA HTEA VE TASARIM YÖNELİMLİ HTEKA'''</big>

Tasarım yönelimli HTEKA’nın bir ürünün her bir komponentinin güvenilirliğini ve niceliğini belirlemesi gerekirken bu seviyede bir detay, bakım amaçları için her zaman gerekli değildir, Bakım faaliyetleri bütün komponentlere değil, daha yüksek seviyede bir kırılımda yer alan değiştirilebilir veya onarılabilir komponentlere odaklanmalıdır. Bu nedenle, LDA HTEA tasarım yönelimli HTEA ile genel olarak tutarlı olmakla birlikte birebir aynı değildir. Bu iki faaliyet arasında yeterli uyum, zamanlamanın uygunluğu ve izlenebilirliği sağlamak açısından sıkı ara yüzler tanımlanmalı ve koordinasyon gerçekleştirilmelidir.

Tasarım HTEKA ve LDA HTEA arasındaki temel fark, tasarım açısından farklı olan bazı hata türleri, nihayetinde aynı bakım faaliyetine yol açıyorlarsa LDA HTEA açısından gruplanarak tek bir hata modu gibi ele alınabilir.

<big>'''4. LDA HTEA VE İDAME EDİLEBİLİRLİK, BAKIM VE EMNİYET ANALİZLERİ'''</big>

İdame edilebilirlik, bakım ve emniyet analizleri gibi diğer analizler LDA HTEA’dan veri kullanabilir veya tasarım HTEKA’dan türetilebilir (ör. OSA, GMB ve PBA gibi). Mevcut çalışmalardan azami fayda sağlamak ve tekrarlamaları önlemek için bu analizlerin de HTEKA ve LDA HTEA ile sıkı bir biçimde koordine edilmesi gerekir.

== EK-C HASAR VE ÖZEL OLAY ANALİZLERİ ==
'''<big>1. GENEL</big>'''

Sistemin kullanımı esnasında meydana gelebilecek özel olaylar ve hasarların sistem kullanımına etkileri ve bu durumlar karşısında uygulanması gereken bakım faaliyetlerinin belirlenmesi amaçlanmaktadır. Bu bakım faaliyetleri tüm bakım konseptini etkileyeceğinden analiz edilmeleri kritiktir. Özel olaylar ve hasar durumları tanımlandıktan sonra BGA kapsamında analiz edilirler. Elde benzer sistemlerle ilgili kullanım verilerinin olması durumunda, bu bilgilerin de mutlaka referans alınmaları gerekmektedir. Hasar ve özel olay analizleri, geliştirme safhasının kavramsal tasarım aşamasında yapılması gereken bir analiz faaliyetidir. Diğer taraftan ihtiyaç olması halinde (tasarım değişikliği, modifikasyon vb) ilgili safhalarda güncellenebilecek bir analizdir.

Olası tehlikelerin tanımlandığı ve bu tehlikelerin analiz edildiği (tehlikelerin neler olduğuna, hangi ömür evresinde meydana gelebileceğine, ciddiyetine, meydana gelme olasılığına ve alınacak önlemlere ilişkin bilgileri kapsayan) emniyet analizleri kapsamında gerçekleştirilen Ön Tehlike Analizi sonuçları hasar ve özel olay analizi için girdi olacaktır.

Bakım uygulaması gerektiren bazı özel olay örnekleri;

* Sıcaklık limitlerinin aşılması
* Mekanik yükleme limitlerinin aşılması (örneğin aşırı torklama)
* Nakliye ömür evresinde izin verilen araç hız limitlerinin aşılması
* Korozif ortamda sistemin operasyonel kullanımı
* Kumlu ortamda sistemin kullanımı
* Yıldırım çarpması
* Sistemin entegre olduğu harici uçar platformun ani iniş yapması
* Harici nesnelerle çarpışma

Aşağıda hasar ve özel olay analizi kapsamında kullanılan terimler ve tanımları verilmiştir.
{| class="wikitable"
|'''Hasar (damage)'''
|''':'''
|Fonksiyonelliğin kaybı ya da azalmasıdır (sistemin doğal arızaları hariç). Bir hasar durumu karşısında tanımlanmış bir bakım görevi gerekecektir. Sistem özelinde hasarlar belirlenirken gruplara ayrılabilir; örneğin, çizikler, oyuklar ve çatlakların bir hasar ailesi olarak belirlenmesi gibi.
|-
|'''Harici sebep (external cause)'''
|''':'''
|Sistemin kullanımından bağımsız olarak meydana gelen durumdur.
|-
|'''Dahili sebep (internal cause)'''
|''':'''
|Yalnızca sistem kullanımının bir sonucu olan durumdur.
|-
|'''Özel olay (special event);'''
|''':'''
|Sistemin ömrü boyunca meydana gelebilecek ve normal kullanım olarak düşünülmemiş olaydır. Dış sebeplerden (meteorolojik olaylar gibi) ya da kullanım dışı durumlardan (bir uçağın aşırı ivmelenmesi) kaynaklı olabilir.
|}
<big>'''2. ANALİZ SÜRECİ'''</big>

<big>'''2.1. ÖZEL OLAYLARIN TANIMLANMASI'''</big>

1. Adım; özel olayların tanımlanması kapsamında, ilk olarak bir olay yaratabilecek farklı sebeplerin listelenmesi gerekir. Olaylar harici veya dahili sebeplerden kaynaklı olabilir ve doğal olaylardan ya da insan hatalarından etkilenebilir. Tablo 13’de olayların sebeplerine örnekler verilmiştir.

Hasarlar ise, her bir durum için kritikliğinin ya da derecesinin verilemediği özel olaylardır. Bu nedenle, aynı yolla meydana gelebilen ya da aynı yolla tespit edilebilen hasarların da özel olay analizi kapsamında ele alınması gerekmektedir.

'''Tablo 13 Olayların Sebep Tiplerine İlişkin Örnekler'''
{| class="wikitable"
| colspan="2" |'''Sebep Tipleri'''
|'''Örnekler'''
|-
| rowspan="4" |Harici sebepler (external causes)
|Doğal sebepler
|Meteorolojik sebepler
|-
|İnsan kaynaklı sebepler
|Kullanım, taşıma vb. hataları
|-
|Operasyon çevresinden kaynaklı sebepler
|· Elektromanyetik alan

· Yüksek akım

· Tozlu, kumlu ortam
|-
|Nakliye, depolama koşullarından kaynaklı sebepler
|· Şok

· Titreşim

· Basınç
|-
| rowspan="2" |Dahili sebepler (internal causes)
|Olağan dışı kullanımdan kaynaklı sebepler
|Operasyon limitlerinin dışına çıkılması - ani iniş, aşırı ivme gibi
|-
|İşlev bozukluklarından kaynaklı sebepler
|Aşırı ısınma
|}
2. adım; özel olaylar tanımlandıktan sonra, bu özel olayın sistemin hangi ömür evresinde (kullanım, bakım, depolama, nakliye vb.) meydana geleceğinin tanımlanması gerekmektedir. Örneğin, kullanım ya da nakliye için hazırlık süresince elle taşımanın dış yüzeye olan etkisi ya da kullanım ömür evresinde sistemin mekanik kısımlarında meydana gelen beklenmeyen aşınmalar gibi.

3. Adım; özel olaylar belirlendikten sonra her bir olayın meydana gelme olasılığı analiz edilmelidir.

'''Tablo 14 Olayların Meydana Gelme Olasılıkları'''
{| class="wikitable"
|'''Puanlama'''
|'''Meydana gelme'''
|'''Açıklama'''
|-
|1
|Son derece düşük ihtimal
|Meydana gelme olasılığı sıfıra yakındır.
|-
|2
|Düşük ihtimal
|Meydana gelme ihtimali pek mümkün değildir. Özel olaylar seyrek olarak meydana gelir.
|-
|3
|Ara sıra
|Arada sırada (sadece birkaç özel olay) meydana gelebilir.
|-
|4
|Olası
|Meydana gelme ihtimali orta seviyededir.
|-
|5
|Sık
|Meydana gelme ihtimali çok yüksektir.
|}
4. Adım; özel olayların meydana gelme olasılıklarına bağlı olarak, bu olayların bakım gerektiren ya da hiçbir analiz gerektirmeyen şeklinde gruplandırılmaları gerekmektedir.

'''<big>2.1. POTANSİYEL ARIZALARIN TANIMLANMASI</big>'''

Sistem tasarımında kullanılan teknolojinin değerlendirilmesi iki bakış açısı ile yapılabilir;

* Teknoloji yeni geliştirilen mi yoksa hali hazırda kullanılan bir teknoloji mi?
* Teknoloji hasara karşı dayanıklı mı yoksa hassas mı?

1. Adım; sistemin tüm alt sistem ve kalemleri için kullanılan teknolojiler tanımlanmalıdır. Tablo 15’te teknoloji seviyeleri ve açıklamaları ile bunların puanlama bilgileri verilmiştir.

'''Tablo 15 Teknoloji Seviyeleri'''
{| class="wikitable"
|'''Puanlama'''
|'''Teknoloji seviyesi'''
|'''Açıklama'''
|-
|1
|İyi bilinen
|Birçok benzer projede kullanılmış bir teknolojidir.
|-
|2
|Bilinen
|Birçok benzer projede kullanılmış bir teknoloji olup, ilgili proje kapsamında modifikasyonlar söz konusudur.
|-
|3
|Tamamen yeni
|Yakın zamandaki projelerde kullanılmış bir teknoloji olup, çok az geri bildirim olmuştur.
|}
2. Adım; teknolojinin hassasiyetinin değerlendirilmesi. 1. Adım’da tanımlanan her bir teknoloji için, meydana gelebilecek olası hata tiplerinin tanımlanması gerekir. (Örneğin, metaller üzerinde meydana gelebilecek korozyon ve bu korozyonun tipleri, montaj yerlerinde meydana gelebilecek gerilme korozyonu gibi). Teknoloji hassasiyetinin değerlendirilmesi Tablo 16’de verilmiştir.

'''Tablo 16 Teknoloji Hassasiyetinin Değerlendirilmesi'''
{| class="wikitable"
|'''Puanlama'''
|'''Hassasiyet Derecesi'''
|'''Açıklama'''
|-
|1
|Aşırı düşük
|Bu teknoloji için ürünün ömrü boyuncaki hasar ihtimali aşırı düşüktür.
|-
|2
|Düşük
|Bu teknolojinin hasar ihtimali çok düşüktür.
|-
|3
|Orta
|Bu teknolojinin hasar ihtimali düşüktür.
|-
|4
|Yüksek
|Bu teknolojide ürünün ömrü boyunca muhtemelen hasar meydana gelecektir.
|-
|5
|Aşırı Yüksek
|Bu teknolojide ürünün ömrü boyunca hasar meydana gelmesi durumu çok olasıdır.
|}
Adım 3; teknoloji tanımlanması ile hassasiyet oranı birlikte değerlendirilerek seçim eşiği (selection threshold) tanımlanır. Seçim eşiği de proje ihtiyaçlarına bağlı olarak belirlenebilir. Teknoloji-hassasiyet değerlendirmesi Tablo 17’da verilmiştir.

'''Tablo 17 Teknoloji-Hassasiyet Değerlendirmesi'''
{| class="wikitable"
| colspan="2" rowspan="2" |
| colspan="5" |Hassasiyet Derecesi
|-
|1
|2
|3
|4
|5
|-
| rowspan="3" |Teknoloji Seviyeleri
|1
|1
|1
|2
|3
|4
|-
|2
|1
|2
|3
|3
|4
|-
|3
|2
|3
|4
|4
|4
|}
'''<big>2.2. ÜRÜNÜN ELEMAN YA DA KISIMLARININ TANIMLANMASI</big>'''

1. Adım; seçilen her bir özel olay için ürün ağacı üzerinden etkilenen kalemler tanımlanmalıdır.

2. Adım; seçilen teknoloji ve hasarlar için ürün ağacı üzerinden etkilenen kalemler tanımlanmalıdır.

3. Adım; bir önceki adımlarda tanımlanan ürün ağacı kalemleri için farklı tehditlere maruz kalmaları durumunda tasarımlarının analiz edilip gerekirse sonuçlar tasarım girdisi olarak tanımlanmalıdır.

<big>'''2.3. KRİTİKLİK ANALİZİ'''</big>

Her bir potansiyel hasarlanabilir kalem için, sistemin hizmet ömrüne olan etkisini ifade edecek şekilde kritikliklerinin değerlendirilmesi gerekmektedir. Bunun için aşağıdaki sorulara verilen cevapların herhangi biri ‘evet’ ise kritik olduğu değerlendirilebilecektir.

* Hasar emniyeti tehdit eden seviyelerde mi sonuçlanıyor?
* Hasar kullanılabilirliğin tehdit edilmesi ile mi sonuçlanıyor?
* Hasar önemli mülkiyet kaybı ile mi sonuçlanıyor?
'''<big>2.4. BAKIM GÖREV GEREKSİNİMLERİNİN TANIMLANMASI</big>'''

Tanımlanmış özel olaylar ve hasarlar karşısında gerçekleştirilmesi gereken bakım görevlerinin tanımlanması gerekmektedir.

Meydana gelebilecek her bir hasarın tespit edilmesinin, lokalizasyonunun, ölçülmesinin veya takibinin yapılması (görsel muayene, tahribatsız muayene gibi) ile sistemin fonksiyonunun eski haline getirilmesi (örneğin, sökme ve takma görevleri, onarım görevleri) kapsamında uygulanması gereken tüm faaliyetlerin belirlenmesi gerekmektedir. Bakım görevleri BGA kapsamında belirlenecektir.

== EK-D LOJİSTİK İLİŞKİLİ OPERASYONLAR ANALİZİ ==
<big>'''1. GENEL'''</big>

Sistemin bakım ve onarım faaliyetlerine ek olarak, operasyon ve kullanımı ile ilgili durumlar da söz konusu olduğundan; sistemin kullanılabilirliği, kullanım esnekliği, mobilitesi gibi hususlara ilişkin sınırların tanımlanması ve bu gibi hususlara ilişkin bilgilerin ilgili el kitaplarında tanımlanması hem sistemin doğru kullanımı hem de saha verilerinin doğru bir şekilde toplanması açısından gerekmektedir. Diğer taraftan, bu hususlar garanti dönemini kapsayan uygulamaları da doğrudan etkileyecektir. Lojistik ilişkili operasyonlar sistemin direkt olarak kullanımının ya da bakımının dokümante edildiği ilgili dokümantasyonlara atanamasa da sistemin uygun kullanımı açısından önem taşımakta olup bu bilgilerin de dokümantasyonlara eklenmesi gerekmektedir.

Lojistik ilişkili operasyonların tanımlanması (personel, destek ekipmanı, sarf malzemeler, yedek parçalar, eğitim vb. gereksinimlerle ilişkili) lojistik analiz faaliyetleri için önemli girdiler oluşturacaktır. Sistemin kullanım konsepti bilgileri ile birlikte, lojistik ilişkili operasyonların bazıları sistem ömür döngüsünün konsept safhasında göz önünde bulundurulurken, bazıları daha sonraki safhalarda (örneğin prototiplerin üretilmesiyle ya da BGA analizinin yapılmasıyla birlikte) ele alınabilir. Diğer taraftan, lojistik ilişkili operasyonlar analizi ihtiyaç olması halinde (tasarım değişikliği, modifikasyon vb) ilgili safhalarda güncellenebilecek bir analizdir.

'''<big>2. ÜRÜN KULLANIM DESTEĞİ</big>'''

'''<big>2.1. KULLANIMA HAZIRLIK</big>'''

Sistemi operasyona hazırlamak için sistemi kullanıma hazırlama kapsamında yapılması gereken bakım faaliyetleri dışında kalan diğer gerekli faaliyetlerin tanımlanması gerekmektedir. Sistemin doğru kullanım için yanal sistemlerin ve/veya parçaların hazırlanması buna örnek olarak verilebilir. Tipik kullanıma hazırlama görevleri servis görevleri olarak sınıflandırılabilir (bir uçağa özel bir ekipman ekleyerek keşif görevine hazırlamak gibi).

<big>'''2.2. YÜKLEME VE İNDİRME'''</big>

Kargo olarak taşıması olan her bir ürün için yükleme ve indirme prosedürleri projenin erken safhalarında analiz edilmelidir. Örnek olarak, ne tarz bir kargo taşımasının planlandığı, hangi boyut ve ağırlık parametrelerinin göz önünde bulundurulduğu, kargonun özel etkilere (ivme, manyetik alan, nem vb.) hassasiyeti olup olmadığı, yanlış kullanım sonucu kargonun kritik ve tehlikeli durumlara sebebiyet verip vermeyeceği, ne tarz bir kargo güvenliği gerektiği verilebilir. Ayrıca yükleme/indirme ve kargo güvenliği için özel bir ekipman gerekip gerekmediği, topraklama ihtiyacının olup olmadığı da değerlendirilmelidir.

'''<big>3. PAKETLEME, ELLEÇLEME, DEPOLAMA VE ULAŞTIRMA (PEDU)</big>'''

Tipik PEDU görevleri, paketleme, koruma, güvenlik önlemleri, depolama, taşıma, ulaştırma, çekme, istifleme, kaldırma olarak tanımlanabilir.

'''<big>3.1. PAKETLEME</big>'''

Paketleme ve paketten çıkarma için asgari düzeyde aşağıdakiler değerlendirilmelidir:

* Paketleme uzun süreli mi kısa süreli mi depolama için yapılacak?
* Taşıma yapılacak mı, yapılacaksa ne tarz bir taşımaya göre paketleme yapılacak?
* Depolama ve taşıma için özel bir sandık, kutu vb. gerekiyor mu?
* Depolama ve taşıma periyodunda sıradışı iklim koşulları için özel bir koruma gerekiyor mu?
* Taşıma ve depolama esnasında sistemin bir bakım görevini gerçekleştirmek için paketlemesini açmak ve tekrar paketlemek gerekiyor mu?
* Paketlemeyi açmak için destek ekipmanı ve tesisi ilgilendiren bir durum var mı?
'''<big>3.2. ELLEÇLEME</big>'''

Elleçleme için asgari düzeyde aşağıdakiler değerlendirilmelidir:

* Sistemi taşırken gerekli olan güvenlik önlem ve limitleri nelerdir?
* Sistemin normal kullanımından farklı olan çekme, vinçle kaldırma ve hareket ettirme için gerekli yönlendirmeler nelerdir?
* Sistem elleçlenirken ekstra ekipman ve malzemeler gerekiyor mu?

Taşıma, yükleme, onarım, bakım vb. için sistemin kaldırma konsepti belirlenmelidir. Ürünün hem kendisinin hem de komponentlerinin kaldırılması söz konusuysa onlar da düşünülmelidir.

'''<big>3.3. DEPOLAMA</big>'''

Ürünün fonksiyonelliğini depolama esnasında ve depolama sonrasında da garanti etmek için depolama prosedürleri analiz edilmeli ve dokümante edilmelidir. Depolama için asgari düzeyde aşağıdakiler değerlendirilmelidir:

* Depolama çözümü kısa döneme yönelik mi uzun döneme yönelik midir?
* Depolanacak ürünün özel bir hassasiyeti var mıdır?
* Depolanacak üründen komponent çıkarmak ve bu komponentleri özel koşullar altında ayrıca depolamak gerekiyor mu?
* Depolama esnasında sıradışı iklim koşullar var mı?
* Depoya giriş için özel teknikler (temizleme, koruma, özel parçaların çıkarılması vb.) gerekiyor mu?
* Depodan çıkarma ve tekrar depoya koyma için özel teknikler (fonksiyonel kontroller, kullanım hazırlığı vb.) gerekiyor mu?
* Depolama periyodu için ne tarz güvenlik önlemleri gerekiyor? (ör. Hareketli parçaları bloklamak, ışığa karşı koruma sağlamak vb.)
* Depolama zamanı ürünün ömründen sayılacak mı?
<big>'''3.4. İSTİFLEME'''</big>

Depolama ve taşımanın bir parçası olan istifleme kapsamında gerekli güvenlik gereksinimleri tanımlanmalıdır. Depolamada itme vb. durumların gerçekleşme ihtimali varsa bu durumda sistem davraşının ne olacağı değerlendirilmelidir.

'''<big>3.5. TAŞIMA</big>'''

Taşıma için asgari düzeyde aşağıdakiler değerlendirilmelidir:

* Taşımaya hazırlık ve taşıma sonrası için gereken süre ve efor nedir?
* Taşımaya hazırlık ve taşıma sonrası için gereken personel, ekipman, sarf malzemesi ve tesisler nelerdir?
* Özel koşullarda taşıma için gereken çevresel ve güvenlik gereksinimleri nedir?
* Taşıma periyodu için gerekli servis aksiyonları var mıdır?
* Taşıma için üründen komponent çıkarmak gerekli midir?
* Taşıma sandığı konsepti olacak mı?
* Taşımada kızak ve palet kullanımı olacak mı?
'''<big>3.6. BAĞLAMA</big>'''

Bağlama kısa ya da uzun vadeli olarak, ürünü bir yere sabitlemek veya bir taşıma aracının içinde sistemin güvenli olarak bulunmasını sağlamaktır. Özel teknikler (ör. Denge ağırlığı, bağlama noktaları, bağlama esnasında gerekecek ekipman vb.) de değerlendirilmelidir.

'''<big>4. ENVANTERDEN ÇIKARMA VE GERİ DÖNÜŞÜM</big>'''

Sistemin (mühimmat, silah sistemi, destek ekipmanı vb.) envanterden çıkarma prosedürlerinin tanımlanmış olması gerekmektedir. Ayrıca tek kullanımlık sistemlere ait taşıma saklama kutuları için uygulanabilir olması için geri dönüşüm metotları da tanımlanmalıdır.

'''<big>5. LOJİSTİK İLİŞKİLİ OPERASYONLAR İÇİN KONTROL LİSTESİ</big>'''

Tüm faaliyetler (ayarlama, sızdırma, kalibrasyon, kontrol, temizleme, koruma, taşıma sandığı konsepti, tuzdan arındırma, envanterden çıkarma, kaldırma, yükseltme, kargoya yükleme, paketleme, geri dönüşüm, ikmal, güvenlik önlemleri, istifleme, depolama, taşıma, kargodan indirme, paketlemeyi açma, vinçle kaldırma vb.) ve bu faaliyetlerin sistemin hangi ömür evresinde gerçekleştirileceği/uygulanacağı belirlenmeli ve özel bir destek ekipmanı gerekliliği ile bu faaliyetlerin tasarım üzerinde bir etkisi olup olmadığı kontrol edilmelidir.

== EK-E PLANLI BAKIM PROGRAMI GELİŞTİRME ==
'''<big>1. GENEL</big>'''

Planlı bakım programının geliştirilmesi ile amaçlanan, planlı bakım görevlerinin yerine getirilmesi kapsamında ürünün Operatör Bakım Planının (Operator Maintenance Plan) geliştirilmesi için süreçleri ve kuralları tanımlamaktır. Planlı bakım görevleri de aslen Önleyici Bakım Görev Gereksinimlerinden (PMTR - Preventive Maintenance Task Requirements) ortaya çıkmaktadır.

Önleyici Bakım Görev Gereksinimleri ile ilişkili sistem ya da ekipman/kalemler otomatik olarak LDA adayı kalem olacaktır. LDA adaylarına atanmış tüm Planlı Bakım Görev Gereksinimleri daha sonra BGA’ya (bkz.EK-G BAKIM GÖREV ANALİZİ) tabi tutulacaktır. Planlı bakım programı geliştirme faaliyeti geliştirme safhasından başlar. Diğer taraftan ihtiyaç olması halinde (tasarım değişikliği, modifikasyon vb) ilgili safhalarda güncellenebilecek bir analizdir.

'''<big>2. ANALİZ YÖNTEMLERİ</big>'''

Önleyici Bakım Görev Gereksinimlerinin belirlenmesi kapsamında üç farklı analiz metodu tanımlanmıştır. (Analizler hakkında detaylı bilgi için; bkz. ‘S4000P International specification for developing and continuously improving preventive maintenance’.)

* '''Sistem analizi (System analysis)'''

Ekipman ve kalemleri de kapsayan sistem için uygulanabilir ve etkili Önleyici Bakım Görev Gereksinimlerinin geliştirilmesi için kullanılan bir analiz yöntemidir. Ürün kırılım yapısına bağlı olarak, bu sistemler tasarım HTEKA’sına göre şeffaf bir şekilde analiz edilir. Sistemin veya analiz edilen bir kısmının bakım yapılamaz olarak varsayılması durumunda, bununla ilgili geri bildirim mutlaka sağlanmalıdır.

* '''Yapı Analizi (Structure Analysis)'''

Ürünün mekanik yapısı için uygulanabilir ve etkili Önleyici Bakım Görev Gereksinimlerinin tanımlanması kapsamında yapılan analizdir. Analiz kapsamında, yorulma analizi sonuçları, çevresel bozulma (environmental deterioration) parametreleri, kazara oluşan hasar etkileri (accidental damage impacts) göz önünde bulundurulur.

* '''Bölgesel Analiz (Zonal Analysis)'''

Ürünün tipine ve kullanım alanına göre bağlı olarak yapılabilecek analizler;

Standart Bölgesel Analiz

Gelişmiş Bölgesel Analiz

Yüksek yoğunluklu radyasyon alanları analizi

'''<big>3. ÖNLEYİCİ BAKIM GÖREV GEREKSİNİMLERİ İÇİN EŞİKLER, ARALIKLAR VE TETİKLEYİCİ OLAYLAR</big>'''

Tek bir Önleyici Bakım Görev Gereksinimi için, planlı eşiklerin, aralıkların ya da tetikleyici olayların farklı tipleri seçilebilir;

* Bir kere yap eşikleri (perform once); örneğin silah sistemi üzerinden belirli sayıda füzenin ateşlenmesi sonrasında tetik mekanizmasının kontrol edilmesi ya da belirli bir süre kullanım sonrasında silah sistemi üzerinde bulunan özel vidaların torklarının kontrol edilmesi şeklinde tanımlanan bakım görevi. Periyodik aralıklarla tanımlanan bakım görevleri birbirine paralel de olabilir; belirli bir kullanım süresi sonunda silah sistemi üzerinde bulunan özel vidaların değiştirilmesi ve aynı zamanda her beş yılda bir kez ilgili vidaların değiştirilmesi gibi.

* Periyodik aralıklar (Periodical); örneğin, tanımlanmış her bir kullanım süresi sonunda (örneğin 3 yılda bir) silah sistemi üzerinde bulunan özel vidaların değiştirilmesi.
* Bir kere yap eşikleri ile periyodik aralıkların kombinasyonu; örneğin 500 döngülük kullanım sonrası ilk muayenenin yapılması (bir kere yap eşiği-PO) ve sonrasında her 1000 döngülük kullanım sonrası periyodik muayene.
* Periyodik aralıklar ile tetikleyici olayların kombinasyonu; örneğin her 1000 döngülük kullanım sonrası periyodik muayene şeklinde tanımlanan bakım görevi, periyodik yapılan bu muayeneler esnasında karşılaşılan bir olay sonucu periyodik bakım görevlerinin her 800 döngüde yapılmasının bakım görevi olarak tanımlanması.

Bakım görev gereksinimleri belirlenirken, sistemin tasarım ve geliştirmesi için esas alınan kullanım parametreleri kapsamında kullanım durumu mutlaka değerlendirmelidir. Önleyici Bakım Görev Gereksinimleri için belirlenecek aralıklar aşağıda belirtilenlere bağlı olabilir;

* Ürün kullanım parametreleri (örneğin, kullanım saatleri, döngü, katedilen mesafe gibi)
* Takvim bazlı parametreler (ana aralık olarak takvim bazlı parametreler seçilirse eğer ürünün gerçek kullanım yoğunluğu, planlı ürün bakım eforuna etki etmeksizin değişebilir. Diğer taraftan gerçek kullanım yoğunluğu, kullanıma yönelik olan ana aralıklar ile daha iyi gösterilecektir.)

* Ürün kullanımı ve takvim bazlı parametrelerin kombinasyonu
* Tanımlanmış etkili ve uygulanabilir her bir önleyici bakım görev gereksiniminin, fonksiyonel hata etkisinin kritikliğine göre en kötü senaryo karşısında kendine özgü durumu vardır. Kritiklik kategorisi, aralıkların artmasına ya da azalmasına karar vermeyi mümkün kılacaktır.

* Tanımlı önleyici bakım görev gereksinimleri tek bir bakım seviyesinde ya da birden fazla bakım seviyesinde gerçekleştirilebileceğinden, aralıklar tanımlanırken bu husus da göz önünde bulundurulmalıdır.
* Aralıkların uzatılması hata sebeplerinin ortaya çıkarılamaması riski artıracak fakat bakım maliyetleri azalacaktır.
* Aralıkların azaltılması durumunda ise hata sebeplerinin (Failure Causes) ortaya çıkarılması ile ilgili risk azalacaktır ancak bakım maliyetleri artacaktır.
* Fonksiyonel hata etkisi emniyet ile ilgili olan durumlarda aralık uzatılmamalıdır.
'''<big>4. TANIMLANACAK ÖNLEYİCİ BAKIM GÖREV GEREKSİNİMLERİNİN (PMTR) BELİRLENMESİ İÇİN KULLANILABİLECEK KAYNAKLAR</big>'''
* Yasal düzenlemelerden gelen gereksinimler
* Emniyet Analizi/hata ağacı analizinden gelen gereksinimler
* Yapısal muayeneler ile ilgili yorulmalar
* Üretici firma tarafından belirlenen gereksinimler
* Mühendislik yaklaşımları
* Diğer projelerden edinilen tecrübeler
* Depolama kriterlerine bağlı öngörülen planlı faaliyetler

İlerleyen analiz aşamalarında ortaya çıkan potansiyel bakım problemlerinin tespit edilebilmesi açısından, görev uygulanabilirliği ve etkinliği ile ilgili yapılmış olan varsayımları doğrulayabilmek için geri bildirimlerin sağlanması önemlidir.

'''<big>5. KULLANICI BAKIM PROGRAMININ GELİŞTİRİLMESİ</big>'''

Bir önleyici bakım görev gereksiniminin tip ve değer olarak bir tane ya da tip ve değerin kombinasyonlarından oluşan iki ya da daha fazla aralığı vardır. Eğer birden fazla aralık tanımlanmışsa, kullanım senaryosuna bağlı olarak ilk gelen aralık ile bakım başlatılır.

Her bir önleyici bakım gereksiniminin başlangıç aralık tipleri ve değerleri ile birlikte bakım seviyelerinin, personel, destek ekipmanı, yedek parça, teknik dokümantasyon gibi gerekli kaynakların belirlenmesi için BGA ve OSA kapsamında analiz edilmesi gerekmektedir.

Önleyici bakım görev gereksinimlerinin dokümantasyonunun ve sistem entegrasyon standartlarına göre geçerlilik onayının tamamlanmasından sonra, daha sonraki sistem bakım programı için ana görev paketlerinin aralıklarının tanımlanması ve asgari aşağıdaki hususların dokümante edilmesi gerekmektedir;

* Kullanım senaryoları ve sapmalar
* Ana görev paketlerinin aralık tipleri ile ilgili alınan kararlar/tahminler
* Aralıkların uyarlanması için hesaplama kuralları (örneğin, güvenilirlik değerleri ile kullanım saatlerinin birlikte değerlendirilmesi durumu)

Örneğin;

Bir silah sistemi için emniyet ilişkili bir önleyici bakım görev gereksinimi kapsamında, her 600 saatlik kullanım saatinde görsel muayene yapılması durumunda, herhangi bir ‘bir kez yap eşiği’ (perform once threshold) olmadan periyodik aralık 600 kullanım saati olacaktır. Önleyici bakım görev gereksinimi kategorisi de emniyet olacaktır.

Kullanım senaryosu; Silah Sisteminin bir takvim yılı içerisinde azami 1000 kullanım saati ile kullanılacağı planlanmıştır. Ana görev paketi için aralık tipinin kullanıcı tarafından takvim bazlı olmasına karar verilmiştir (Emniyet kritik durum göz önünde bulundurulduğunda, 600 saatlik muayene gerekliliğini sağlayacak şekilde her altı ayda bir muayene yapılması, senede bir kez de kapsamlı muayene yapılması şeklinde).

Bu kullanım senaryosundaki limitlere göre, birinci planlı görevin, 600 kullanım saatlik periyodik aralığı aşmayan ana görev paketleri kapsamında yerine getirilmesi gerekmektedir. Bu nedenle planlı görevin 500 kullanım saatini kapsayan her altı ayda bir yerine getirilmesi gerekir. Azami 1000 kullanım saati ile ilişkili her yıl gerçekleştirilecek bir görevin seçimine emniyet açısından aralık aşımı söz konusu olduğu için izin verilmemelidir.

Tüm önleyici bakım görev gereksinimleri için BGA kapsamında aşağıdaki hususların değerlendirilmesi gerekmektedir;

* Tek bir faaliyetin ve/veya bakım görevlerinin potansiyel karşılıklı bağımlılık durumu (örneğin, bir bakım görevi başlamadan bir diğerinin tamamlanmış olması gerekliliği)
* Potansiyel bir zaman tasarrufu, bir kez erişim sağlandıktan sonra görevlerin yerine getirilmesi ile sağlanabilir. (Örneğin; sistemde bulunan bir kapak açıldığında gerekli tüm görevlerin yerine getirilmesi)
* Sürenin etkili kullanılabilmesi için paralel yapılması gereken görevlerin mutlaka göz önünde bulundurulması
* Planlı bakım görevleri her zaman ardışık olarak yerine getirilmez, birbirine paralel olabilir ya da kısmen birbirinden bağımsız olabilirler, bu husus da göz önünde bulundurulmalıdır.

Diğer taraftan, farklı bakım seviyeleri, periyodik aralıklar ve bir kez yap eşikleri (eğer varsa) ile tanımlanan önleyici bakım görev gereksinimlerini etkileyeceğinden bu hususların da OSA kapsamında dikkate alınması gerekmektedir.

Önleyici bakım görev gereksinimleri, proje kapsamında uygulama kolaylığı sağlanacağı değerlendirildiği durumda üç ana grup altında toplanabilirler.

* Sistemin kullanıma/göreve başlamasından önce
* Sistemin kullanım veya görevine anlık kısa bir ara verilmesinden sonra
* Ürünün kullanım veya görevini tamamlanmasından sonra
'''<big>6. GÜVENİLİRLİK MERKEZLİ BAKIM (GMB) ANALİZİ YAKLAŞIMI</big>'''

GMB sistemin doğal güvenilirliğini kaynakların minimum israfı ile sürdürebilmesi için gerekli olan planlı bakım görevlerinin tanımlandığı analiz yöntemidir.

Sistemdeki olası hataların, sırasıyla emniyet ve çevre, görev ve kullanım ile maliyet üzerine olan etkileri incelenir. Buna göre gerçekleştirilecek faaliyetlere ilişkin önceliklendirme yapılmış olur. GMB hataların öncelikle planlı bakım faaliyetleri ile önlenmesini ve önlenemiyorsa da hataların etkilerini kabul edilebilir seviyeye indirmeyi amaçlayan güvenilirlik odaklı LDA faaliyetidir.

Şekil 19’da GMB kapsamında hata türlerine bağlı olarak bakım görevlerinin tanımlanması ile bu görevlerin analizinin yapılması için BGA’ya olan girdiler gösterilmiştir.
[[Dosya:Şekil19GMB – BGA Arayüzü.jpg|alt=|sol|küçükresim|650x650pik|Şekil 19 GMB – BGA Arayüzü]]

== EK-F ONARIM SEVİYESİ ANALİZİ (OSA) ==
'''<big>1. GENEL</big>'''

OSA maliyet, güvenilirlik değerleri, bakım yapılabilirlik/test edilebilirlik kısıtlamaları ya da hazır bulunurluk gibi amaçların da gözetildiği; onarma, yenisi ile değiştirme gibi kararların alındığı ve ilgili görevler için bakım seviyelerinin belirlendiği analiz çalışmasıdır. Analiz sonuçları bakım görevlerini ve bu görevlerle ilişkili ekipman, personel, yedek parça gibi kaynakları doğrudan etkiler. OSA’nın amacı optimum bakım çözümüne karar vermektir.

Bir bileşenin doğasından kaynaklı olarak onarılabilir ya da onarılamaz olduğu bilgisi BGA’da belirlenir. OSA’nın ilk adımı ise bu kalemlerden onarılabilir olanların ekonomik maliyet kriterleri ile ekonomik olmayan kriterlerin göz önünde bulundurularak analiz edilmesidir. BGA’da onarılabilir olarak belirlenen kalem için OSA sonrasında değerlendirme kriterlerine göre yenisi ile değiştirilmesi kararı verilebilir.

OSA yaparken her bir seviyedeki, her bir bakım merkezindeki imkân ve kabiliyetlerin neler olduğunun önceden bilinmesi gerekir. Hat üzerinde sökülen ünitelerden başka, bunların içinin nerelerde açılabileceği, onarım sırasında üzerlerinde parça değişikliği yapılıp yapılmayacağı, onarımı mümkün değilse nerede envanterden çıkarılacağı belirlenir.

OSA BGA’yı tamamlayıcı niteliktedir. Saha inceleme rapolarının, mühendislik verilerininin ve proje gereksinimlerinin girdi olarak kullanıldığı OSA, tasarımın netlik kazanması ile geliştirme safhasında bakım görev analizine paralel bir şekilde yürütülür. Diğer taraftan ihtiyaç olması halinde (tasarım değişikliği, modifikasyon vb) ilgili safhalarda güncellenebilecek bir analizdir.

'''<big>2. ANALİZ SÜRECİ</big>'''

Sistemler için onarım seviyeleri genellikle ikiye veya üçe ayrılır:

a) Operasyonel seviyede (O-level) bakım-onarım

b) Ara seviyede (I-level) bakım-onarım

c) Fabrika/Depo seviyesinde (D-level) bakım-onarım

Analiz sonuçlarına göre her bir ekipman için, “Kaynak, Bakım ve Onarım” (Source, Maintenance and Recoverability – SM&R codes) kodlaması yapılır. Buna göre; bir ekipmanın arızası olduğunda onarım yapılıp yapılmayacağı, yenisiyle değiştirilip değiştirilmeyeceği, onarılamıyorsa envanterden çıkarılıp çıkarılmayacağı bilinir.

Analiz, yedek parça ile arızayı tespit etmek ve onarımını gerçekleştirmek için gerekli olan destek ekipmanı, personel, eğitim, teknik dokümantasyon gibi başlıca ekonomik maliyet faktörleri kullanılarak yapılır. Ayrıca, kullanıma hazır olma gereksinimleri, güvenilirlik, bakım yapılabilirlik gibi ekonomik olmayan faktörler de göz önünde bulundurulmalıdır. Bu faktörlerin, sistem için gereksinim önceliklendirmesine göre değerlendirilmesi yapılmalıdır. OSA süreç adımları Tablo 18’de yer almaktadır.

'''Tablo 18 Onarım Seviyesi Analizi Süreç Adımları'''
{| class="wikitable"
|'''İŞLEM ADIMI'''
|'''TANIMI'''
|'''GİRDİLER'''
|'''ÇIKTILAR'''
|-
| rowspan="2" |1
|Onarım Seviyesi Analizi yapılacak donanım kalemleri belirlenir
|<nowiki>- Kırılımlı Parça Listesi</nowiki>
|<nowiki>- Analizi yapılacak ekipman ve cihazların listesi</nowiki>
|-
|Donanım ürünlerinin üst seviye, alt seviye kırılımları saptanır. Parça listesindeki ürünler ‘onarılabili”, “onarılamaz” ‘arıza yedeği’ vb. kategorilere ayrılır.
|<nowiki>- Üretici firmalardan sağlanan teknik dokümanlar</nowiki>

- Kırılımlı Parça Listesi

- Tasarım dokümanları
|<nowiki>- Analizi yapılacak ekipman ve cihazların ‘yeniden tasnif edilmiş’ listesi</nowiki>
|-
| rowspan="5" |2
|Sökme ve takma işlemlerinin hangi bakım-onarım seviyesinde yapılacağı belirlenir
|<nowiki>- Analizi yapılacak ekipman ve cihazların yeniden tasnif edilmiş listesi</nowiki>
|<nowiki>- SM&R kodunun ilgili hanesi doldurulur.</nowiki>
|-
|Yönetmelikler, lisans hakları, bilgi güvenliği vb. kısıtlamalar incelenir
|<nowiki>- Üretici firmaların açıklamaları</nowiki>

- Üretici firmalardan sağlanan teknik dokümanlar

- Teknik ve idarî yönetmelikler
|Kısıtlamalarla ilgili sorulara verilen “Evet” veya “Hayır” şeklindeki yanıtlar
|-
|Tesis (atölye), bakım destek ve test ekipmanı, iş gücünün sahip olması gereken yetenekler belirlenir.

İş güvenliği, çevrenin korunması vb. etkenler irdelenir.
|<nowiki>- Alan uzmanlarının, sistem mühendislerinin ve diğer Proje paydaşlarının görüş ve değerlendirmeleri</nowiki>
|Gereksinimlerle ilgili sorulara verilen “Evet” veya “Hayır” şeklindeki yanıtlar
|-
|Operasyonel seviyedeki uzun süren bakım faaliyetlerinden bilhassa ‘sök-tak’ işlemleri (varsa) belirlenir.
|<nowiki>- Yapılan ölçümler</nowiki>

- Mühendislik tahminleri

- (Varsa) Ürünle ilgili geçmişte tutulmuş kullanım-bakım kayıtları
|Uzun süren söküm takım faaliyetleriyle ilgili sorulara verilen “Evet” veya “Hayır” şeklindeki yanıtlar
|-
|İhtiyaç makamının/kullanıcının operasyonlara ve bakım faaliyetlerine yönelik stratejileri incelenir
|<nowiki>- Gizli gizlilik dereceli ekipman ve malzemelerin listesi</nowiki>
|İhtiyaç makamının/kullanıcının operasyonel stratejisiyle ilgili sorulara verilen “Evet” veya “Hayır” şeklindeki yanıtlar
|-
| rowspan="4" |3
|Hangi seviyede envanterden çıkarılacağı belirlenir
|<nowiki>- Onarılabilen ve onarılamaz ekipman ve cihazların listesi</nowiki>

- Tasfiye edilecek olanların hangi seviyede envanterden çıkarılacağının bilgisi
|<nowiki>- Devre dışı bırakılacak ürünler için, hangi İhtiyaç makamının/kullanıcının ya da firmanın yetkili olduğu belirlenir.</nowiki>

- SM&R kodunun ilgili hanesi doldurulur.
|-
|Onarılabilenler belirlenir
|<nowiki>- Üretici firmaların tavsiyeleri, çözüm önerileri</nowiki>

- Güvenilirlik, idame edilebilirlik ve kullanıma hazır olma sonuçları
|<nowiki>- Onarılabilen ekipman ve cihazların listesi </nowiki>
|-
|Daha masraflı olduğu için onarımı tercih edilmeyenler belirlenir
|<nowiki>- MTBF değerleri</nowiki>

- Yeni ürünün birim fiyatı

- Yeni ürünün piyasada bulunup bulunmadığı bilgisi
|<nowiki>- Onarılmayıp, operasyonel veya depo seviyesinde envanterden çıkarılacak olan ekipman ve cihazların listesi</nowiki>
|-
|Operasyonel seviyede onarılabilecek olanlar belirlenir
|<nowiki>- Birim fiyatının çok yüksek olduğu bilinen ürünlerin listesi </nowiki>

- Operasyonel seviyedeki onarım imkânları ve maliyeti
|Operasyonel seviyede, ara seviyede ve depo seviyesinde onarılabilecek ekipman ve cihazların listesi
|-
| rowspan="3" |4
|Onarım seviyesi belirlenir
|<nowiki>- D-seviyesi bakım-onarım merkezlerinin imkânlarının değerlendirilmesi</nowiki>
|<nowiki>- D-seviyesi bakımın (onarımın) nerede yapılacağı belirlenir</nowiki>

- SM&R kodunun ilgili hanesi doldurulur.
|-
|Depo seviyesi için kurallar ve kısıtlamalar belirlenir
|<nowiki>- Yönetmelikler</nowiki>

- Lisans hakları, bilgi güvenliği vb. kısıtlamalar
|<nowiki>- Depo seviyesinde, yurt içinde veya yurt dışında onarım yapılacak olan ekipman ve cihazların listesi</nowiki>
|-
|Maliyetlere bakılır
|<nowiki>- Yurt içi merkezlerdeki bakım-onarım maliyeti</nowiki>

- Yurt dışı merkezlerdeki bakım-onarım maliyeti
|<nowiki>- Belirlenmiş olan yurt içi ve yurt dışı bakım-onarım merkezleri</nowiki>
|}
Örneğin, bir sistem için kullanıma hazır olma gereksinimi kritik ise, maliyet hususları ikinci planda kalabilir ve onarımın daha maliyet etkin olduğunun değerlendirilmesine rağmen, arızalı kalemin yenisi ile değiştirilmesi kararı verilebilir. MTTR değeri yüksekse arızalı sistemin onarımı maliyet etkin olsa bile, kullanıma hazır olma gereksinimini sağlayabilmek için arızalı kalemin yenisi ile değiştirme kararı verilebilir. Ya da bir sistemin kullanım konsepti düşünüldüğünde arıza oranı düşükse (örneğin, 10 yıllık raf ömrü olan sistemin yılda 300 saat kullanılmasının öngörüldüğü ve MTBF değerinin 4000 saat olması gibi) ve onarım maliyeti için gerekli kaynaklar düşünüldüğünde malzeme maliyetinin üzerine çıkıyorsa alınan karar yenisi ile değiştirilip arızalı parçanın onarımı değil elden çıkarılması olmalıdır.
{| class="wikitable"
|OSA’nın, projenin erken safhalarında başlanması durumunda test edilebilirlik özellikleri, modülerlik, erişilebilirlik gereksinimlerinin tanımlanması ile tasarıma etki sağlanabilir.
|}
Aşağıda belirtilen soruların cevabı evet ise bu kalemlerin OSA kapsamında analiz edilmesi gerekmektedir;

* Kalemin tasarımı onarıma izin veriyor mu?
* Kalemin onarımı belirli bir bakım seviyesi ile sınırlı mı?

Sarf malzemelerin (somun, cıvata, conta vb.) analize dahil edilmesine gerek yoktur.

Örneğin; ürün ağacında sistemin bir alt seviyesinde bulunan ‘elektronik komple’ arızası olayının meydana gelmesi durumunda BGA kapsamında tanımlanan düzeltici görevin (kalemin onarılabilir olduğu durum için) aşağıdaki gibi olduğu varsayılsın;

Düzeltici Görev 1; Arızalı olan elektronik komplenin yenisi ile değiştirilmesiyle sisteminin onarımı

Düzeltici Görev 2; Doğrudan arızalı elektronik komplenin onarımı ile sistem onarımının yapılması

Bu örnek kapsamında, elektronik komplenin yenisi ile değiştirilmesi durumunda arızalı elektronik komplenin onarılması ya da elden çıkarılması ve bu faaliyetlerin hangi seviyede yapılacağı ile ilgili karar OSA kapsamında verilecektir. Bu karar verilirken de hem onarım maliyeti (işçilik, eğitim vs.) hem de asıl malzeme maliyeti ile elektronik komplenin güvenilirlik değeri göz önünde bulundurulmalıdır.

'''<big>2.1. OSA VERİLERİ</big>'''

OSA kapsamında yapılan değerlendirmelerde kullanılan veriler bakım ilişkili verilerdir. Bunların bir kısmı yedek parça, tesis, destek ekipmanı, personel ve yetenek seviyesi, eğitim ihtiyacı gibi maliyet ilişkili verilerdir. Bir kısmı ise, güvenilirlik bilgisi (MTBF gibi), planlı bakım aralıkları, sistem hazır bulunurluğu, stoktaki yedek parçaların hazır bulunurluğu, bakım için gerekli personelin hazır bulunurluğu gibi doğrudan maliyetle ilişkili olmayan verilerdir.

Toplam maliyet hesaplamaları yapılırken, gerekli kaynakların sadece başlangıçta gereken veya tekrar eden maliyet olarak değerlendirilmesi gerekmektedir. Örneğin, işçilik süresi ya da alt yapı bakımı tekrar eden bir maliyetken, destek ekipmanı tedariki ya da alt yapı kurulumu için sadece başlangıç maliyeti söz konusudur.

'''<big>2.2. BAKIM SEVİYELERİNİN BELİRLENMESİ</big>'''

Bakım çözüm önerisinin oluşturulması kapsamında, hangi bakım görevinin hangi seviyede yapılacağının belirlenmesi ve bunun için de bakım seviyelerinin tanımlanması gerekmektedir. Bakım seviyeleri, her sisteme özel olarak kullanıcı ile anlaşılarak belirlenmelidir. Daha sonra, tanımlanan bakım görevlerinin altyapı, personel, yetkinlik gibi hususlar düşünüldüğünde hangi seviyede yapılacağına karar verilmelidir.

Tablo 19’de bakım seviyeleri ve bu seviyeler kapsamında tanımlanabilecek görevlere ilişkin örnekler verilmiştir. Seviye isimleri, seviyeler için tanımlanacak yetkiler sisteme/projeye özgü kararlar olup tablo sadece örnekleme amaçlı olarak verilmiştir.

'''Tablo 19 Bakım Seviyeleri ve Tanımlı Görevlere İlişkin Örnekler'''
{| class="wikitable"
|'''Seviye Adı'''
|'''Amaç'''
|'''Tanımlı Bakım Görevleri'''
|-
|'''Seviye 1'''
|Sistemin hazır halde olmasının sağlanmasıdır.
|· Kullanıma hazırlama (genel bakım)

· Kullanım öncesi ve sonrası yapılacak muayeneler, fonksiyonel kontroller

· Arıza tespiti

· Önleyici bakım faaliyetleri

· Düzeltici bakım (yenisi ile değiştirme ve ayarlama gerekiyorsa yapılması - kalibrasyon vb.)

· Basit modifikasyonlar
|-
|'''Seviye 2'''
|Sistemin hazırda bulunma seviyesini olası en yüksek seviyede tutmayı sürdürmektir. (Seviye 1 kapsamında yenisi ile değiştirilen arızalı alt sistem, HDB ve modüllerin onarım faaliyetleri yapılabilir. Hem önleyici hem koruyucu bakımları içerebilir.
|· Modül ve alt sistem onarımları

· Orta seviye yapısal onarımlar

· Büyük planlı muayeneler

· Orta seviye modifikasyonlar

· Seviye 1 için teknik destek

· Mühendislik verileri ile ilişkili yazılım hizmeti

· Ürünün korunması
|-
|'''Seviye 3'''
|Sistemin hazırda bulunma seviyesini - mühendislik desteği de sağlayarak - olası en yüksek seviyede tutmayı garanti etmektir. Tüm onarım ve büyük bakımlar yapılacaktır. Tasarımı ya da operasyonel yeteneği iyileştirmek için büyük modifikasyonlar yapılabilir.
|· Özel yetenek veya ekipman gerektiren onarımlar

· Büyük yapısal onarımlar

· Büyük planlı muayeneler

· Kapsamlı modifikasyon ve güncelleme programları

· Seviye 1 ve 2 için teknik destek

· Yazılım modifikasyonları
|}
'''<big>2.3. BAKIM ÇÖZÜM ÖNERİSİNİN OLUŞTURULMASI</big>'''

Hem maliyet hem de teknik kriterlerin birlikte değerlendirilmesi kritiktir. BGA kapsamında belirlenen görevler üzerinden değerlendirme hem teknik hem mali olarak yapılır ve onarım kararı ya da envanterden çıkarma kararı verilir. Her bir görev kapsamında bu kararlar verildikten sonra, bu görevlerin hangi seviyelerde yapılacağı belirlenir. Ayrıca, tanımlanan benzer bakım faaliyetlerinin mümkün olduğunca tek bir bakım yeri için tanımlanmış olması da (onarım yapılacak kalemin bir kısmının bir bakım merkezinde bir kısmının başka bir bakım merkezinde yapılmaması gibi) önemlidir. Yapılan tüm analiz çalışması sonunda sistemin bakım çözüm önerisi oluşturulmuş olacaktır.

Örnek OSA tablosu:
[[Dosya:Osa.png|sol|küçükresim|990x990pik]]

{| class="wikitable"
|Not 1: "PAOKD" SM&R kodu açıklaması şöyledir:

▪ Malzeme belli bir süre kullanmak üzere satın alınmış ve depolanmıştır. ( PA - - - )

▪ Malzeme operasyonel bakım seviyesinde sökülüp takılır ve değiştirilir. ( - - O - - )

▪ Tamir edilebilir malzemedir. Tümüyle tamiri anlaşmalı yüklenici tesislerinde yapılır. ( - - - K - )

▪ Malzemenin tamir maliyeti artarsa ve yenisiyle değiştirmenin maliyetini geçerse, hurdaya ayrılır. ( - - - - D)
|Not 2: "PAOZZ" SM&R kodu açıklaması şöyledir:

▪ Malzeme belli bir süre kullanmak üzere satın alınmış ve depolanmıştır. ( PA - - - )

▪ Malzeme operasyonel bakım seviyesinde sökülüp takılır ve değiştirilir. ( - - O - - )

▪ Tamir edilemeyen malzemedir. Yenisiyle değiştirilir. ( - - - Z - )

▪ Malzeme hurdaya ayrılır. ( - - - - Z )
|}

== EK-G BAKIM GÖREV ANALİZİ (BGA) ==
'''<big>1. GENEL</big>'''

Bakım faaliyetleri, sistem konfigürasyonunda bulunan ve görev için kritik olan bütün ekipmanlar için gereksinimlere uygun olarak, görev faaliyetlerini kesintiye uğratmayacak, sorunsuz ve kazasız bir şekilde tamamlanmasına yönelik tedbirlerin alınması ve gerektiğinde müdahale edilmesi esasına dayanır. Bu amaca yönelik her türlü kaynak ihtiyacı (iş gücü, malzeme, tesis vb.) önceden hesaplanmalı ve tahsis edilmelidir.

Sistemde/ekipmanlarda herhangi bir arızanın ortaya çıkması mümkün olduğunca engellenmeli (önleyici bakım), arıza ortaya çıktığında ise çok kısa bir süre içerisinde müdahale ederek (düzeltici bakım) yeniden çalışır duruma getirilmelidir.

Bakım faaliyetleri ekipmanın onarım yapılmasını da kapsar. Ancak, operasyonel seviyedeki onarım işleri, ekipmanın yeniden çalışır hâle getirilmesi maksadıyla yapılacak temel müdahalelerle (arıza tespit, sökme, takma ve son test faaliyetleriyle) sınırlıdır. Depo seviyesinde ise, onarım yapılması gerekli görülen ekipmanlar için ihtiyaç duyulan her türlü imkân bulunmaktadır.

Planlı ve plansız bakım görevleri belirlendikten sonra, bu işlerin yapılabilmesi için gerekli personelin, eğitimlerinin, tesis veya atölye ihtiyaçlarının, test ekipmanlarının ve bakım sırasında ihtiyaç duyulabilecek malzemelerin belirlenmesi gerekir.

Bakım görevleri, işlem adımlarına ayrıştırılarak her bir adımın ne kadar sürede tamamlanacağı hesaplanır. Tüm bu verilerle, maliyet etkinliğinin sağlanmasına ve operasyonların olumsuz şekilde etkilenmeyeceği zaman aralıklarının belirlenmesine çalışılır.

Sistemlerin yazılım konfigürasyonunda bulunan geliştirilmiş yazılım kodlarının tamamı, kullanılan ticarî ve açık kaynak yazılım paketlerinin hepsi, vb kalemler için bakım planlaması garanti kapsamında yüklenici firmadan alınacak destekle sınırlı tutulmalıdır. Ancak, kritik görülen hususlar için ek tedbirlere ve düzenlemelere baş vurulmalıdır.

BGA, geliştirme safhasında yapılması gereken bir analiz faaliyetidir. Diğer taraftan ihtiyaç olması halinde (tasarım değişikliği, modifikasyon vb) ilgili safhalarda güncellenebilecek bir analizdir.

'''<big>2. ANALİZLER</big>'''

'''<big>2.1. BAKIM GÖREVLERİNİN BELİRLENMESİ</big>'''

Bakım görevleri belirlenirken ürün kırılımının yapılmış ve LDA adayı kalemlerin listelenmiş olması gerekmektedir. LDA adayı olarak seçilen her bir kalem için bakım görevleri belirlenmelidir.

Hata durumları, arızalar, özel olaylar vs. bakım görevlerini belirlerken ana etmenler olacaktır (HTEKA, özel olay ve hasar analizi, GMB). Ayrıca yazılım yükleme gibi durumlardan kaynaklı görevler de tanımlanabilir.
[[Dosya:TSSODYP06.20.jpg|alt=|sol|küçükresim|450x450pik|Şekil 20 Bakım Görevlerinin Belirlenmesi]]

Özel olay sonrası gerekli olan muayeneler ve/veya GMB sonrasında; genel, kullanıcı talebine bağlı ve/veya hazırlık için yapılacak faaliyetlerden kaynaklı bakım görevleri ortaya çıkabilir. Bu faaliyetlerin de BGA kapsamında değerlendirilmesi gerekmektedir.

'''<big>2.2. BAKIM GÖREV YAPILARININ OLUŞTURULMASI</big>'''

Görev yapıları oluşturulurken görevler analiz faaliyetinde kolaylık sağlaması açısından iki sınıfa ayrılır.

'''Düzeltici görevler (rectifying tasks);''' Her düzeltici bakım görevi arıza, hata veya özel olay gibi bir durumdan dolayı gerçekleştirilir. Doğrudan ilgili olayı çözmek amaçlı (event solver) yapılan herhangi bir bakım faaliyeti düzeltici görev olarak adlandırılabilir. Hem alt görevleri hem de referans destek görevlerini kapsar.

Örneğin;
{| class="wikitable"
|'''Olay'''
|'''Düzeltici görev'''
|-
|Hata/Arıza
|Onarım veya yenisi ile değiştirme prosedürü
|-
|Özel Olay
|Muayene/arıza yeri
|-
|Sistem ömrünün eşik değerine yaklaşması
|Planlı bakım
|}
'''Destek görevleri (supporting tasks);''' Düzeltici görevlerin aksine destek görevleri, meydana gelen durum karşısında (arıza, hata vb.) bu durumun çözülmesi amacıyla yapılmaz. Bağımsız bir görev olarak hata ya da arıza durumunu çözmez ve/veya özel bir olaydan sonra gerçekleştirilmez. Düzeltici görevlerin uygulanmasını sağlayan destekleyici görevlerdir. Test prosedürleri, erişim sağlama/kaldırmak, kurulum kaldırma/yükleme/montaj/demontaj prosedürleri örnek olarak verilebilir.

Tablo 20’de, ürün ağacında yer alan bir ‘elektronik komple’ arızası olayının meydana gelmesi durumunda, düzeltici görev, takip eden görevler ve uyarıların neler olduğu örneklenmiştir. Elektronik komple arızası karşısında, kalemin onarılabilir ve onarılamaz olması şeklinde iki farklı durum varsayılmıştır.

Elektronik komple arızası için varsayılan iki farklı durum;

1. durum; elektronik komplenin onarılamaz bir kalem olarak tanımlanmış olması

2. durum; elektronik komplenin onarılabilir bir kalem olarak tanımlanmış olması

'''Tablo 20 Görev Gereksinimleri Örneği'''
{| class="wikitable"
|'''Olay (Event)'''
|'''Düzeltici Görev'''
|'''Takip Eden Olası Görevler *'''
|'''Uyarı'''
|-
|Elektronik komple arızası (elektronik komplenin onarılamadığı durum)

|Arızalı olan elektronik komplenin yenisi ile değiştirilmesi
|Arızalı elektronik komplenin elden çıkarılması
|· Onarılamaz elektronik komplenin yedek parça olarak tanımlanmış olması gerekmektedir.

· Arızalı elektronik komplenin elden çıkartılması prosedürlerinin ilgili dokümanda belirtilmiş olması gerekmektedir.
|-
| rowspan="2" |Elektronik komple arızası (elektronik komplenin onarılabildiği durum)
|Arızalı olan elektronik komplenin yenisi ile değiştirilmesiyle sistemin onarımı
|Arızalı olan elektronik komplenin onarımı
|Elektronik komplenin yedek parça olarak tanımlanmış olması gerekmektedir. Bu sayede son ürün olan sistem, arızalı alt sistemin onarımı tamamlanana kadar beklememiş olacaktır.
|-
|Doğrudan arızalı elektronik komplenin onarımı ile sistem onarımının yapılması
|Yok.
|Komponentin yedek parça olarak tanımlanması gerekli değildir (onarılıp tekrar takıldığı için). Bu durumda son ürün olan sistem, arızalı alt sistemin onarımı tamamlanana kadar beklemiş olacaktır.
|-
| colspan="4" |* Bakım/onarım seviyeleri belirlendikten sonra, bu seviyelere göre takip eden işlemler değişebilecektir (arızalı sistemin bakım için belirlenen üst seviyeye gönderilmesi gibi).
|}
Görev yapıları oluşturulurken, düzeltici görevlerden önce destek görevlerinin tanımlanması gerekmektedir. Destek görevleri de iş adımlarına bölünebilir. Destek görevleri tanımlanmadan önce, iş adımları öncesi yapılması gereken işlemler de tanımlanmalıdır. Adımlar öncesi yapılacak faaliyetler, sistem ile doğrudan ilişkili olmayan, erişim için yapılan faaliyetlerdir. Görev yapılarının oluşturulmasına ilişkin adımlar Şekil 21’de gösterilmiştir.
[[Dosya:Şekil21Görev Yapılarının Oluşturulması.jpg|alt=|sol|küçükresim|437x437pik|Şekil 21 Görev Yapılarının Oluşturulması]]

Örneğin, bir ‘elektronik komple’ arızası, elektronik komplenin yenisi ile değiştirilmesi;

Elektronik Komple için sökme prosedürü (adımlar, görevler);

Adım 1 öncesi yapılacak işlem; kapağı kaldırmak için vidaların açılması

Görev 1; kapağın kaldırılması

Adım 2; elektronik komplenin gövdeden ayrılması

Görev 2; elektronik komplenin demonte edilmesi

Görevler tanımlanırken, ön koşulların ve/veya ön koşulların sağlanabilmesi için gereken faaliyetlerin de tanımlanması gerekir. Örneğin, görevin emniyetli bir ortamda gerçekleştirilmesi için gerekli olan tüm ön koşulları (uyarı ve dikkat edilecek hususların) kapsayacak şekilde emniyet ön koşullarının ve/veya emniyet yönetmelikleri de dahil gerekli personel yetenekleri, sertifikasyonları vs. durumlarını kapsayan personel ön koşullarının tanımlanması.

Bazı tasarımsal sebeplerden kaynaklı sistem hataları öngörülemeyebilir. Hasar ya da özel olayların meydana gelmesi ile ilgili benzer sistemler ve/veya benzer projeler kapsamında edinilmiş herhangi bir tecrübe varsa, bu tecrübe öngörülemeyen olayların ne kadar sıklıkla meydana gelebileceği ve ilgili bakım faaliyetlerinin sıklığı konusunda fikir verebilir. Bu nedenle, bakım faaliyetleri ile ilgili planlama yapılırken uygulanabilir olduğu ölçüde öngörülemeyen bu tarz olayların da dikkate alınması önemlidir.

'''<big>2.3. GÖREV KAYNAKLARININ BELİRLENMESİ</big>'''

Bir görevin yerine getirilmesi için gerekli olan kaynakların (özel bir ekipman kullanımı için personel eğitimi de dahil) görevin içinde tanımlanması gerekmektedir. Görevin yerine getirilmesi kapsamında gerekli olan yedek parçalar, destek ekipmanı, personel, alt yapı gibi kaynakların belirlenmesi ve ilgili görevlere atanması gerekmektedir. Görev kaynaklarına ilişkin örnekler ve açıklamaları Tablo 21’de verilmiştir.

'''Tablo 21 Görev Kaynaklarına Örnekler'''
{| class="wikitable"
|'''Kaynak'''
|'''Açıklama'''
|-
|Yedek parçalar
|Yedek parçalar fiilen gerekli oldukları alt görevlere atanırlar.
|-
|Sarf malzemeler
|Sarf malzemeler fiilen gerekli oldukları alt görevlere atanırlar.
|-
|Destek ekipmanı **
|Destek ekipmanı fiilen gerekli olduğu alt göreve atanabilir ya da tüm görev boyunca gerekliyse de tek bir alt görev yerine ana göreve atanabilir.

İlgili ekipmanı hangi personelin kullanacağı ve eğitimin gerekli olup olmadığı bilgisinin de eklenmesi gerekir
|-
|Personel
|Personel (hem görev kapsamında ihtiyaç duyulacak personel sayısı hem de personel gereklilikleri) fiilen gerekli olduğu alt görevlere atanırlar.
|-
|Tesis
|Tesisler fiilen gerekli olduğu alt görevlere atanırlar.
|-
|Teknik dokümantasyon
|Teknik dokümanlar fiilen ilişkili olduğu alt görevlere atanırlar.
|-
| colspan="2" |** Bakım görevlerine destek ekipmanı atanırken ilgili ekipmanın mevcut ve doğrulanmış bir ekipman olması, yeni geliştirilen bir ekipman ise tüm gereksinimlerinin tanımlanmış ve dokümante edilerek yayımlanmış olması gerekmektedir.
|}
Her bir görev kapsamında görev kaynakları belirlendikten sonra, sistem seviyesinde tüm görevler düzeyinde, alt görevler ve destek görevlerinden gelen tüm kaynakların özetlenmesi gerekmektedir. Tablo 22’de montaj prosedürü için gerekli görev kaynaklarına ilişkin örnek verilmiştir.

'''Tablo 22 Montaj Prosedürü için Gerekli Görev Kaynakları Örneği'''
{| class="wikitable"
| colspan="8" |'''Elektronik Komple için Montaj Prosedürü-Görev Kaynakları'''
|-
|'''Adım/Adım Öncesi Yapılacak İşlemler/Alt Görev'''
|'''Yedek'''
|'''Sarf Malz.'''
|'''Destek Ekipmanı'''
|'''Personel'''
|'''Özel Tesis'''
|'''Geçen Toplam Süre'''
|'''İşçilik Süresi'''
|-
|Alt görev; Elektronik Komplenin gövde içine yerleştirilmesi
|Elektronik Komple
|Yok
|Yok.
|1 personel
|ESD korumalı alan.
|10 dk
|10 dk
|-
|Adım 1; Kapağın kapatılması
|Conta (x1)
|Yapıştırıcı
|Yok
|2 personel
|ESD korumalı alan.
|5 dk (işçilik)

60 dk (yapıştırıcının kuruması için)
|5 dk + 5 dk
|-
|Adım 2; vidaların takılması
|Rondela

(x6)
|Yok.
|Yok.
|1 personel
|ESD korumalı alan.
|3 dk
|3 dk
|}
'''Tablo 23 Elektronik Komple İçin Montaj Prosedürü-Görev Kaynakları Özeti'''
{| class="wikitable"
|'''Kaynak tipi'''
|'''Kaynak'''
|'''Miktar'''
|-
| rowspan="3" |Yedek Parça
|Elektronik Komple
|1
|-
|Rondela
|6
|-
|Conta
|1
|-
|Sarf Malzeme
|Yapıştırıcı
|
|-
|Personel
|Personel
|2
|-
|Özel Tesis
|ESD korumalı alan
|<nowiki>-</nowiki>
|-
|İşçilik Süresi
|Personel
|18 dk
|-
|Montaj için gereken toplam süre
|<nowiki>-</nowiki>
|78 dk
|}
Geçen Toplam Süre (MET; Mean Elapsed Time); İlgili bakım görevinin yerine getirilmesi için gereken toplam süredir. Alt görevlerden ve referans verilen destek görevlerinden gelen sürelerin toplamı ile hesaplanır.

İşçilik Süresi (Labor time); yapılacak personel işinin toplam süresidir. Aynı alt görev için birden fazla personel çalışıyorsa her yetenek seviyesi için işçilik süresi toplanmalıdır. Örneğin aynı seviye kapsamında üç personel 20 dk süren bir görev için aynı zamanda çalışıyorsa, bu görev için gerekli toplam işçilik süresi 3x20=60 dk’dır.

BGA kapsamında görev süreleri, yedek parça, ekipman gibi gerekli olan tüm görev kaynaklarının hazır olduğu varsayımı ile hesaplanmalıdır (‘spanner in hand’ olan zamanlar). Bakım/onarım faaliyeti hazırlıkları ile ilgili olan dokümantasyon, destek ekipmanı veya malzemenin getirilmesi gibi üretken olmayan faaliyetler ve benzer şekilde lojistik gecikme süreleri (logistic delay time) bu sürelere dahil edilmemelidir.

Diğer taraftan, tüm faaliyetler görev sürelerine dahil edilmelidir. Örneğin, malzeme sertleşmesi ya da boya kuruması gibi üretken olmayan faaliyetlerin bir sonraki adım için tamamlanmış olmaları gerektiğinden mutlaka görev süresine dahil edilmelidir.

Bakım faaliyetleri ile ilgili olan ve bakım görevlerinden türetilen eğitim gereksinimlerinin her bir görev kapsamında tanımlanmış olması, faaliyeti yerine getirecek personel için yetenek seviyesi, karmaşık görevler için ekip eğitimi ihtiyacı olup olmadığı, eğitim gerektiren destek ekipmanının olup olmadığı, özel eğitim, tecrübe vs. ihtiyacının olup olmadığı gibi hususların göz önünde bulundurulması gerekmektedir.

Bir kalem yedek parça olmayabilir ancak başka bir kalemin onarımı kapsamında yerinden çıkarılması gerekebilir. Yerinden çıkarılma sonrası hasar görme ihtimali varsa ve/veya tekrar kullanılamaz bir kalemse bunun da yedek parça olarak tanımlanması gerekmektedir.
{| class="wikitable"
| colspan="2" |'''Bakım uygulaması sürecinin sistem hazır bulunurluğu ile ilişkisi;'''

Bakım faaliyetleri boyunca sistem hazır bulunurluğu sistem için en önemli bilgilerden birisidir. Farklı kırılım seviyeleri için hazır bulunurluk farklılık gösterebileceği gibi yapılan analiz sonuçları, maliyet değerlendirmeleri de hazır bulunurluk kapsamında göz önünde bulundurulması gereken faktörlerdir.

Bakım uygulaması süresince sistem hazır bulunurluğunu etkileyecek 3 farklı durum olabilir:

* Bakım süresi boyunca sistem kullanılabilir olmayabilir, bu durumda sistemin tekrar kullanılabilir hale gelmesi için bakım ve onarım faaliyetlerinin tamamlanmış olması gerekir.
* Bakım süresi boyunca sistemin tam kapasite ile kullanılmaya devam edilebilmesidir. Bu durumda, arızalı olan kısım daha sonra onarılmak üzere yenisi ile değiştirilir ve onarılan kısım da tekrar kullanılmak üzere stoklanır.
* Bakım süresince sistemin eksik kapasite ile kullanılması olabilir. Bakım ve onarım faaliyetleri tamamlandıktan sonra tam kapasite ile kullanılabilecektir.
|-
|Bakım faaliyetlerinin yerine getirilmesi, çevre koşullarına, kullanıcı değişikliklerine ve buna bağlı olarak kullanım/bakım alanlarının personel, ekipman ile ilgili ön koşullarındaki değişikliklere, barış ve savaş zamanı senaryolara bağlı olarak farklılık gösterecektir. Bu durumda görevin kendisi aynı kalabilir ancak ihtiyaç duyulacak destek ekipmanları, görev süresi vb değişebilir.
|
|}

Örnek BGA Formu:
[[Dosya:Bga.jpg|sol|küçükresim|800x800pik]]

== EK-H YAZILIM DESTEK ANALİZİ (YDA) ==
'''<big>1. GENEL</big>'''

Sistemin desteklenebilirliğini sağlayabilmek için LDA süreci kapsamında yazılımlar için de YDA süreci yürütülür. YDA, maliyet etkin bir yazılım destek konseptinin kurulması için donanıma benzer şekilde yazılım açısından da sistemi desteklemeyi amaçlar. Yazılım Destek Konsepti (YDK) belirlenirken, bir ürün içerisindeki yazılımın kullanımının devamlılığını sağlamak için gerekli tüm aktivitelerin dikkate alınması gerekir. YDA’da, yeterli bir YDK geliştirmek için ekipman, araç, personel, dokümantasyon, altyapı, gerekli yetkinlik ve eğitim gibi hususlar analiz edilir.

Donanım gibi, yazılım da operasyon ve bakım gereksinimlerine göre analiz edilmelidir. Veriler de, aynı yazılımlar gibi hem fiziksel hem işlevsel bir bakış açısıyla ele alınabilirler.

Yazılımın kullanım şartları ile bakım şartları birbirinden net şekilde ayrılmalı ve yazılım modifikasyonu tanımı net bir şekilde koyulmalıdır. Örneğin, operasyonel husular, yazılımın ürüne yüklenmesini içerebilirken; yazılım modifikasyonu bir problemi çözmek için ya da yazılımın performansını iyileştirmek veya prosedürler, veriler ve yazılımın performansını etkileyecek sistemlere adaptasyon için kaynak kodunun değiştirilmesi olabilir.

Yazılım bakım ve idamesinin amacı, teslim edilen yazılıma ‘maliyet etkin’ şekilde destek verebilmektir.

Yazılım bakım ve idamesi dört şekilde ele alınabilir:

* Teslim edilen yazılım ürünlerindeki hataların giderilmesi (düzeltici bakım);
* Yazılımın performansının ve özelliklerinin iyileştirilmesi (mükemmelleştirici bakım);
* Yazılımın değişen çevre koşullarına, donanıma, işletim sistemine ve muhtelif arayüzlere adaptasyonu (uyarlayıcı bakım);
* Yazılımın daha az karmaşık, daha anlaşılabilir, bakımının daha kolay yapılabildiği şekle çevrilmesi (önleyici bakım).

Yazılım bakım ve idame süreci kapsamında en az aşağıdaki faaliyetlerin gerçekleştirilmesi tavsiye edilir:

* Bakım planı ve bakım süreçlerinin oluşturulması;
* Problem Raporu ve Değişiklik İsteği süreçlerinin oluşturulması (taleplerin alınması, kaydedilmesi, güncellenmesi, izlenmesi, testlerle doğrulanması ve geri beslemenin yapılması);
* Konfigürasyon yönetiminin uygulanması.

Yazılım değişikliklerinin sisteme entegre edilmesi aşamasından önce bazı analizler yapılır. Yapılacak bakımın:

* Niteliği (düzeltici, uyarlayıcı vb.);
* Kapsamı (yazılımdaki değişikliğin büyüklüğü, işlemlerin maliyeti, bakım süresi);
* Kritikliği (performans, emniyet, bilgi güvenliği hususları) değerlendirilir.
'''<big>2. FARKLI PROJE SAFHALARINDA YDA</big>'''

YDA’nın yazılım içeren bir ürün için tüm ömür devri boyunca uygulanması gerekmektedir. Yapılacak faaliyetler, proje safhaları dikkate alınarak gerçekleştirilmelidir. Örneğin, geliştirme safhasında, YDA’nın uygulaması önemlidir çünkü yazılımın gelecekteki yükleme, servis ve modifikasyonları için desteklenebilirlik gereksinimleri açısından yazılım mimarisi ve tasarımı etkilenebilir.

'''Tablo 24 Farklı Proje Safhalarında Yazılım Destek Analizi'''
{| class="wikitable"
|'''Geliştirme'''
|'''Üretim'''
|'''Kullanım ve Destek'''
|'''Envanterden Çıkarma'''
|-
| colspan="2" |· LDAP’da YDA kapsamının belirlemesi

· Karşılaştırmalı analiz

· YDK’nın belirlenmesi

'''Detaylı yazılım analiz görevleri:'''

· Konfigürasyon değerlendirmesi

· YDA

· Yazılım için OSA

· Yazılım ilişkili görevler için BGA
|· Periyodik değerlendirme

· Kullanım safhasındaki teknik modifikasyonların yönetimi

· Konfigürasyon yönetimi
|· Verilerin silinmesi

· Verilerin yer değiştirmesi

· Verilerin arşivlenmesi
|}
Erken fazlarda, YDA temel yazılım destek gereksinimlerinin belirlenmesine yardımcı olur. Envanterden çıkarma safhasında, donanımlar için olduğu gibi yazılımlar için de envanterden çıkarma prosedürlerinin tanımlanması gerekmektedir. Eğer yazılım verisi yeni geliştirilecek sistemler veya ilerleyen operasyonlarda kullanılacaksa, verilerin yer değiştirilmesi hususu kapsamında uygulanması gereken prosedürlerin de göz önünde bulundurulması ve tanımlanması gerekmektedir.

'''<big>3. YAZILIM KIRILIM KONSEPTİ</big>'''

Yazılımlar için de donanımlara benzer olarak fiziksel veya işlevsel konsept değerlendirilerek bir kırılım gerçekleştirilebilir. Yazılımın yüklendiği üst donanımlarından birisinin elemanı olması, yazılımın kendisini çalıştıran donanımın bir elemanı olması veya yazılımın fiziksel olarak üzerinde bulunduğu donanımın bir elemanı olması örnek olarak verilebilir.

Fiziksel bir kırılım içerisinde yer alan yazılım kalemleri genellikle, işlevselliğinin doğrudan kullanıcı tarafından gözlemlenebildiği elemanlardır. Yazılım ürün kırılımında farklı hiyerarşik seviyelerde yer alabilir. Fiziksel kırılım içerisinde yazılımı spesifik bir seviyeye atamak, üründeki konfigürasyon kontrolü ihtiyacı ve yazılımın operasyon ve bakım üzerindeki lojistik etkilerini belirtmek içindir. Fiziksel kırılım, bir ürünün kırılımındaki yazılımı belirlemek için operasyonel amaçlar kapsamında kullanılabilir ve donanımın yanında yazılımın da bakıma yönelik işlemlerinin değerlendirilmesini mümkün kılar.

LDA ürün kırılımında bir yazılım kalemini yönetmenin en kolay yolu yazılımı kategorilerine göre HDB, ADB veya parça/komponent olarak tanımlamaktır. Fiziksel yazılım kategorileri 3 başlık altında incelenebilir;

* Alanda Yüklenebilir Yazılım (Field-Loadable Software); bir sistem/ürün üzerindeki ekipmanın bir veya birkaç parçasına ekipmanı demonte etmeden yüklenebilen yazılımdır.
* Atölyede Yüklenebilir Yazılım (Shop-Loadable Software); bir HDB üzerinde yüklenebilecek bir yazılımdır ancak HDB’nin üründen demontajını gerektirir.
* Yerleşik Yazılım/Bellenim; HDB veya ADB’ye yüklenebilecek ancak operasyonel ürün üzerindeki yükleniminin demontajı ve bir komponentin yeniden konumlandırılmasını gerektirebilecek yazılımdır.

İşlevsel kırılım, yazılımın nasıl modifiye ve entegre edileceği ile yeniden tasarım olduğunda farklı yazılım elemanlarının arasındaki dikkate alınması gereken ilişkiyi gösterir. İşlevsel kırılımda yer alan yazılım kalemleri yazılımın diğer yazılımlarla entegrasyon ihtiyacından ötürü işlevsel/tasarım açılarını tanımlarlar. Böyle bir kırılım, yazılım modifikasyon desteği için kritiktir. Bu yüzden de işlevsel kırılımın yazılım tasarımını olabildiğinde takip etmesi önemlidir.

Yazılım modifikasyonuna yönelik olarak işlevsel yazılım kırılımı yazılım tasarım gereksinimlerini takip eder. Klasik yazılım konfigürasyon kalem seviyesi yaklaşımına ek olarak daha üst seviyede (altsistem ve sistem seviyesi) yazılımın sisteme entegrasyonunun da değerlendirilmesi gerekmektedir.

'''<big>4. YAZILIM DESTEK ANALİZİ</big>'''

Ürün kullanım safhasına girmeden gerekli destek altyapısının sağlandığından emin olmak önemlidir. YDA’nın amacı, yazılım desteklenebilirlik gereksinimlerini erken safhalarda belirlemek ve sistem operasyonu ve sonraki değişikliklerin desteklenebilirliği için yazılım tasarımını etkilemektir.

'''<big>4.1. YDA ADAY KALEM SEÇİMİ</big>'''

Donanım aday kalem seçimiyle benzer yaklaşım izlenecektir.

'''<big>4.2. YAZILIM BAKIMI</big>'''

Bakım faaliyeti gerektirecek tüm olaylar, yazılım desteğinin başlangıcı olarak değerlendirilebilir. Bu olaylar, operasyonel, teknik, yazılım geliştirme gereksinimleri ve yazılım hataları olarak gruplanabilir.

* Operasyonel olaylar; operasyonel bir gereksinim ile ilgili, donanım üzerinden dokümante edilebilen donanım bakımını, kullanıma hazırlığı ve görev sonrası gereksinimleri kapsayan olaylardır.
* Teknik olaylar; yazılım paketinin, değişen koşullara olan adaptasyonunu gerektirir. Yazılımın üzerinde olduğu donanımın değişmesi, birbiriyle çalışan sistemlerin teknolojisinde değişme örnek olarak verilebilir.
* Yazılım geliştirme gereksinimleri; yazılım değişiklikleri yazılım paketinin karmaşıklığı ve boyutuna göre değişen aralıklarda yapılır. Yazılım hatalarının düzeltilmesinin yanında, yeni yazılım yayımlanması için son kullanıcı gereksinimleri ve koşullardaki değişikliklere girdi sağlar. Yazılım geliştirme demek, geliştirilecek yeni özellikler veya genişletilecek fonksiyonellik veya mevcut yazılımın kullanım konforu demektir.
* Yazılım hataları; desteği başlatan ana sebep yazılım hatalarıdır. Bu hatalara verilecek destek ile ilişkili reaksiyonlar hatanın ciddiyetine bağlıdır. Her yazılım hatası yazılım modifikasyonu gerektirmeyecektir. Modifikasyonun gerekli olmadığı durumlarda bile, bir sonraki hatanın tespiti için dokümantasyonun doğru hazırlanmış olması gerekmektedir.
** Minör hata: Genellikle, kullanıcının sistemi kullanım konforu ve ergonomisi ile ilişkili olup sistemin operasyonel kullanımı ile ilgili kritiklik yaratmayan ancak gene de hata olarak ele alınması gereken durumlardır.
** Orta seviye hata: Sistemin işlevselliğini azaltan hatalardır. Sistemin kullanımı azalan bir performans veya hiçbir kısıtlama dahi olmadan devam edebilir.
** Major hata: Tüm sistemin tamamen kapatılmasına veya çok kısıtlı koşullar altında çalışmasına neden olan kabul edilemez hatalardır. Sistem performansı ciddi oranda azalır.

Yazılım hataları donanım hataları gibi belirli onarım değişim prosedürleriyle ele alınamaz. Bu yüzden bir yazılım hatasında alınması gerekli olan aksiyon hemen bilinemeyeceğinden alınamayabilir. Örneğin bir yazılım hatasında sistemi kapatıp açmak hatayı düzeltebilirken, diğer bir hatada sistemi kapattıktan sonra sistemin daha fazla zarar görmemesi için tekrar açılmaması gerekebilecektir. Ya da bir donanımdaki bozulma sebebiyle de yazılım çalışmayabilir. Bu durumda yazılım kaynak kodunda gerçek bir doğal hata bulunmamakta olup bu durum dış hasar olarak ele alınır.

'''<big>4.3. YDA KAPSAMINDA HTEKA/HTEA</big>'''

HTEKA/HTEA tüm sistemde gerçekleştirilen bir analiz methodu olduğu için yazılım kalemleri ile de doğrudan ilişkilidir. Tanımlanmış olan her bir hata modu için işlevsellik bir yazılıma mı dayalı ya da komple bir yazılım tarafından mı sağlanıyor kararı verilmelidir. Yazılımın geliştirme safhasında, yazılım mimarisinde ilgili hata modu bilgilerinin sistemde spesifik bir hataya sebep olmasını engelleyecek ya da en azından azaltacak şekilde dikkate alınması gerekmektedir. Ayrıca, tasarım, yazılım hatalarının tespit edilebildiği, kayıt altına alınabildiği ve sistemin güvenli modda çalışmaya devam edeceği şekilde olmalıdır.

Sistemin kullanım safhasında, yazılım hatalarından kaynaklı sistem hataları, yazılım değişikliğine sebep olmaktadır. LDA HTEA’sının temel prensibi, spesifik bir sistem arızasına sebep olabilecek tüm yazılım hatalarını ve aynı yazılım değişikliğine sebep olacak tüm sistem hatalarını gruplamaktır. Analiz, yazılımın gerçekleştirdiği fonksiyon üzerinden gidecektir fakat genellikle bir kaynak kodundaki spesifik bir hataya kadar değerlendirecek şekilde HTEKA/HTEA yapmak pratik değildir.

Kullanım safhasındaki diğer bir konu ise yazılım mühendislerine spesifik bir hata hakkında bilgi vermek ve yazılım hatalarından kaynaklı gereksiz bakım görevlerini önlemektir. BIT ile tespit edilebilen veya kullanıcı tarafından tanımlanabilen bir yazılım hatası demontaj sayısını ve donanımla ilişkili olmayacak hataları azaltacaktır (ekipmanın değiştirilmesi ile yazılım hatasının ortadan kaldırılamaması gibi).

'''<big>4.4. YAZILIM İÇİN PLANLI BAKIM ANALİZİ (PBA)</big>'''

GMB gibi PBA’lar donanımlar gibi yazılımlara uygulanabilir değildir. Yazılım hataları, yazılım tasarımının istenmeyen etkilerinin sonucu olduğundan PBA kapsamında tanımlanmış bir bakım görevi ile düzeltilemezler. PBA sonuçları yazılım içeren bir donanımda, planlı bakım görevlerini belirleyecek şekilde kullanılabilir ancak bu analiz yine de donanım için olacaktır.

Yazılımlar da küvet eğrisi davranışını izleyerek ilk kullanımda çokça hata yaparlar. Geliştirme safhası boyunca kararlı bir davranışa kadar kod hataları düzeltilerek tekrarlayan bir şekilde yazılım yayımlamaları yapılır. İlerleyen kullanımlarda hata oranları her ne kadar düşse de yazılımda ilk kapsamından farklı olarak modifikasyonlar olacağından hata oranları yine artacaktır.

'''<big>4.5. YAZILIM İÇİN OSA</big>'''

Yazılım için OSA donanımlarda olduğu gibi ya da oldukça benzer olacak şekilde ele alınmalıdır. OSA sonucunda ortaya çıkan görevler yeni yazılım yayını veya operasyonel bir yazılım ihtiyacının doğması veya veri yükleme gibi dışsal nedenlerden kaynaklanabilir. Eğer bu görevler çok sık gerçekleşirse OSA sonuçları donanımlara karşılık gelen görevlerden farklı olabilir.

Yazılım değişikliği için ekipman hakkında detaylı bilgi (donanımla ilintili yazılım geliştirme ortamı ve yazılım geliştirme araçları) ve personel yetkinliği gereklidir. Ayrıca, sözleşmeye bağlı durumlar, yazılım modifikasyon faaliyetlerinin hangi destek seviyesinde gerçekleştirileceğini etkileyebilir.

'''<big>4.6. YAZILIM İÇİN BGA</big>'''

İlgili yazılım destek başlatıcılarının (olaylar) belirlenmesinden sonra operasyonel/bakım veya modifikasyon görevleri belirlenmelidir. Amaç bunları tanımlamak ve bunlara gerekli kaynakları ve görev karakteristiklerini belirlemektir (süre, insan ihtiyacı, ön koşullar, güvenlik koşulları vb.).

SAE JA1005 referans alınarak farklı olaylar sonucunda hangi yazılım destek görevlerinin gerçekleştirileceğine ulaşılabilir.

'''<big>5. YAZILIM DESTEK KONSEPTİ ÇERÇEVESİ</big>'''

Yazılım destek konsepti yazılım tasarım sürecinin erken safhalarında başlamalıdır. Eğer değişiklik gereksinimleri farklı kaynaklardansa, yazılım değişikliği daha kolay olacaktır. Ayrıca, yükleme ve konfigürasyon prosedürleri de olabildiğince kolay olmalıdır.

Yazılım desteğinin 3 farklı perspektifi vardır;

* İlki; destek profili, seviyeler, aktörler ve aktivitelerden oluşur.
* İkincisi; destek fonksiyonları olan operasyon, yönetim ve modifikasyonlardır.
* Sonuncusu ise destek sınıfları olan süreçler, ürün ve çevredir.

Yazılım desteğinin LDA kapsamında olup olmayacağı proje kapsamında yapılması planlanan faaliyetler ile birlikte değerlendirilmeli ve yapılması gerektiği değerlendirilirse LDAP’a eklenmelidir. Büyük miktarda yazılım içeren büyük ve karmaşık sistemlerde yazılım desteklenebilirliği ayrı bir alan olarak değerlendirilmelidir. Yazılımlar donanımlara fonksiyonellik katmak için tasarlandıklarından donanım ile arasındaki arayüzler kurulana kadar süreçler birlikte işletilmeli, gözden geçirilmeli, pratiğe dökülmeli ve dokümante edilmelidir.

'''<big>5.1. YAZILIM DESTEK PROFİLİ</big>'''

Yazılım destek profili kapsamında, yazılım desteğinin gerçekleştirileceği yer, organizasyon ve ilişkili personelin dikkate alınması gerekmektedir. Yazılım destek seviyeleri aşağıdaki gibi tanımlanabilir;

* Operasyonel seviye (seviye 1); bu destek seviyesi, yazılımın operasyonel kullanımındaki yerini tanımlar. Bu seviyede, operasyonel servis desteği adı altında basit destek görevleri gerçekleştirilir.
* Orta seviye destek (seviye 2); hem operasyonel servis desteğiyle hem de yönetim desteği ile ilgili tüm destek faaliyetlerini içerir.
* Üst seviye destek (seviye 3); yönetim desteğine ek olarak modifikasyon desteği de burada sağlanır. Yapılacak faaliyetler, karışıklık, boyut, modülerlik, programlama teknikleri vs. gibi yazılım paketinin kendisine ve yazılım modifikasyonunu gerçekleştirecek ekipmana (araçlar, personel, tesisler) dayanır.

* Yazılım sağlayıcı ve/veya geliştirici (seviye 4); yazılım sağlayıcı normalde yazılım modifikasyonuyla ilişkili gerekli geliştirme araçları ve personel ile donatılmış en üst yetenekteki destek seviyesidir. Kullanıcılar çoğunlukla bu yetkinliğe sahip olmadıklarından yazılım modifikasyonları için genelde bu seviyede destek sağlanır.

Yazılım destek rollerinin belirlenmesinin ilk aşaması kullanıcı ve yüklenici firma rollerinin tanımlanmasıdır. İkinci aşaması ise, yazılım kullanım ve desteğiyle ilişkili personellerin rollerinin (yetkinlik, erişim, eğitim vb.) tanımlanmasıdır. Aşağıda destek rolleri ve bu kapsamda tanımlanan aktiviteler ve yetkilere ilişkin örnekler verilmiştir;

* Basit düzeyde kullanıcı; yazılım sistemlerinin düzeltilmesi veya modifikasyonuyla ilgili bir yetkisi yoktur. Ana görevleri yazılım içeren sistemi operasyonel olarak çalışır durumda tutmak ve sistem/yazılım hatalarını raporlamaktır.
* Orta düzeyde kullanıcı; yazılım sistemlerinin düzeltilmesi ile ilgili yetenek ve bilgiye sahiptir. Yazılımı çalışır durumda tutmak için operasyonel destek aktivitelerini gerçekleştirirken, yazılım ve veri yükleme vb. yazılım güncelleme aktivitelerine ise destek vermezler.
* Sistem yöneticileri; üst düzey kullanıcılarıdır. Operasyonel destekle ilgili tüm aktivitelerden ve yönetim desteğinden sorumludurlar. Yazılım modifikasyonu gerçekleştirmeseler de, tipik yönetim görevleri olan performans parametrelerinin değiştirilmesi gibi yazılım konfigürasyon işlerinden, ek yazılım paketi yüklemeleri vb. işlerden sorumludurlar.

* Servis sağlayıcı; kalifiye operasyonel desteğinden ve yardım hattı gibi ek servislerden sorumludurlar. Müşteri veya yüklenici tarafında ikamet ederler ve modifikasyon desteği de sağlarlar.
* Yüklenici/Yazılım geliştirici; en üst seviyeden yazılım modifikasyon desteği sağlarlar.

Farklı destek görevleri ve seviyeleri için farklı bölgelerde farklı kaynaklarla nasıl yapılacağını gösteren kullanım durumlarının tanımlanması gerekmektedir.

'''<big>5.2. DESTEK FONKSİYONLARI</big>'''

Yazılımla ilişkili bakım görevleri aşağıda belirtilen hususlara göre farklı kategorilere ayrılabilir;

* Görev basit bir yükleme/kaldırma görevi mi yoksa yazılımın A cihazından B cihazına taşınma işlemi mi?
* Yazılım yüklemesi ya da kaldırılması için bir donanımı çıkarmak gerekli mi?
* Yazılım modifikasyonu gerekli mi? Yazılım modifikasyonunun özel destek görevleri gerektiren geniş bir alan olması sebebiyle modifikasyonun kapsamı tam olarak belirlenebiliyor mu?
'''<big>5.2.1. OPERASYONEL SERVİS DESTEĞİ</big>'''

Operasyonel servis görevleri sistemin günlük operasyonel görevleriyle ilişkili tüm aktiviteleri tanımlar. Fakat bu görevler sistem kullanımı üzerinde farklı kalite ve derinlikte etkilere sebep olabilir (ör. sistem atıl zamanları, test gereksinimleri vb.). Bu görevler, destek seviyesi 1 ve 2’de kullanıcı tarafından yürütülen basit görevlerdir.

Görevler, yeni bir işlevsellik veya yeteneğin provizyonu için (yazılım yükleme, yazılım kaldırma, yazılım konfigürasyonu, harita vb. veri yükleme) sistemin geri döndürülmesi veya hata durumlarında problem raporlama (yazılımı geri döndürme, geri döndürme problemlerinin raporlaması - hata gerçekleştiğinde yazılım ve donanımların konfigürasyonu, hatanın tipi, geri döndürmenin başarım durumu, hatanın ciddiyeti), operasyon sonrası veri kaldırma ve organizasyonel görevler (yazılımın teslimi, operasyonel konfigürasyon kontrolü) olmak üzere 3 tipte sınıflandırılabilir.

Gömülü yazılımların veya bellenimlerin yükleme görevleri BGA’da belirlenmelidir.

'''<big>5.2.2. YÖNETİM DESTEĞİ</big>'''

Operasyonel destek ile yazılım modifikasyon görevleri arasında bir yerdedir. Her seviyede kullanıcı tarafından gerçekleştirilebileceği gibi destek organizasyonları tarafından da gerçekleştirilebilir. Problem raporlaması, sistem konfigürasyon kontrolü, teslim ve yükleme ile kullanıcı desteği gibi görev tipleri mevcuttur.

'''<big>5.2.3. YAZILIM MODİFİKASYON DESTEĞİ</big>'''

Yazılım modifikasyonu, düzeltici, adaptif veya tamamlayıcı sebeplerden ötürü olabilir. Genellikle yüklenici tarafında yapılan bir aktivite olsa da kritikliği düşük değişiklikleri karşılayan ekipman ve yetenekli personel varsa kullanıcı da gerçekleştirebilir. Yazılım modifikasyonu, kodlama değişikliğinin uygulanması ve test gibi modifikasyonun direkt kendi aktivitelerini ve problemin araştırılması ve konfigürasyon kontrolü gibi ilişkili görevleri de içerir. Genellikle, yazılım değişikliği için en kritik sebep ürünün operasyonunda kabul edilemez bir duruma sebep olan gerçek bir hata yaşanmasıdır. Adaptif değişiklikler de kritik bir durumdan kaynaklanabilir ancak daha tahmin edilebilir ve planlanabilir değişikliklerdir. Tamamlayıcı değişiklikler ise işlevselliği ve kullanıcı kolaylığını artırmak için yapılan değişikliklerdir. Genellikle bir sürüm yükseltme ile birlikte yapılırlar. Kullanıcı gereksinimleri bir süre boyunca toplanır ve yeni yazılım paketinin yayınlanmasıyla uygulamaya koyulurlar. Yazılım modifikasyon görevleri, problem araştırması, değişikliğin uygulanması, değişikliğin yayınlanması, konfigürasyon kontrolü faaliyetlerinden oluşur.

'''<big>6. DESTEK SINIFLARI</big>'''

'''<big>6.1. SÜREÇLER</big>'''

Yazılım desteğine ilişkin süreçlerin nasıl uygulamaya konulacağı, girdiler, çıktılar, kontroller ve kaynakları da içerecek şekilde dokümante edilmelidir. Bu kapsamda, akış şemaları, tanımlar, gereksinim ve sorumluluklar verilebilir. Uluslararası veya şirket içi kabul görmüş bir standart ve kullanılabilir ölçülebilir performans parametreleri tanımlanabilir.

'''<big>6.2. ÜRÜN</big>'''

Yazılım ürün karakteristiğinde desteklenebilirlik mümkün olduğunca erken safhalarda adreslenmelidir. Yazılım kalitesi, yazılımın ne kadar iyi ya da kötü tasarlandığına bağlıdır. İyi bir yazılım tasarımı için gereksinimlerin net bir şekilde tanımlanması ve grafiksel kullanıcı arayüzü desteğinin sağlanması gerekmektedir. Modülerlik, değiştirilebilirlik, genişletilebilirlik, basitlik, kolay kullanım, kararlılık, tutarlılık, işlem süresi performansı gibi hususlar tipik yazılım kalite göstergerleri olarak verilebilir.

'''<big>6.3. ÇEVRE</big>'''

Kaliteyi etkileyen çevresel durumlar yazılımı kullanacak ve destekleyecek personel ile başlar. Doğru bir yazılım desteği kapsamında personelin yazılım destek işi için doğru kişi olması, yetenek ve deneyiminin seviyesi, sorunsuz bir yazılım desteğini garanti etmek için kaç kişinin gerekeceği gibi konular önemlidir. Personele ek olarak, tesisler, ofislerin genişliği vb. konular da desteğin kalitesi açısından önemlidir. Bakım görevlerinin belirlenmesi kapsamında bu hususların mutlaka değerlendirilmesi gerekmektedir.

'''<big>7. DESTEKLENEBİLİRLİK FAKTÖRLERİ</big>'''

Yazılım için desteklenebilirlik faktörlerinin bazıları operasyonel destek ile ilişkiliyken, bazıları yazılım modifikasyon desteği ile ilgili olabilirler. Bu nedenle bu faktörlerin proje gereksinimleri dikkate alınarak ele alınması önemlidir. Yazılım desteklenebilirlik faktörleri ile ilgili açıklamalar ilerleyen bölümlerde verilmiştir. Yazılım desteklenebilirlik faktörlerinin geliştirme safhasında dikkate alınması (uygulanabilir olanlar için gereksinim tanımlanması, işlevsel akışa dahil edilmesi vb.) gerekmektedir.

'''<big>7.1. UYUMLULUK MATRİSİ</big>'''

Bir sistemde farklı donanımlar üzerindeki farklı yazılımların birlikte çalışabildiği ve yazılım kalemleri içeren fiziksel kırılım içerisinde yazılımların donanımlarla uyumluluğu doğrulanmalıdır. Yazılım paketi taşıyan birbiriyle konuşan ekipmanlarla ilişkili uyumluluk matrisi hazırlanmalıdır.

Tablo 24’de örnek bir uyumluluk matrisi verilmiştir. Tabloda verilen bilgilere göre, donanım 2 üzerinde yer alan ‘A’ ve ‘B’ yazılımlarının birbirileri ile uyumluluğu, benzer şekilde donanım 2 ile hem ‘A’ hem ‘B’ yazılımının uyumlu olduğu ve donanım 1 ile ‘A’ yazılımının uyumluluğu doğrulanmalıdır.

'''Tablo 25 Uyumluluk Matrisi'''
{| class="wikitable"
|
|Donanım 1
|Donanım 2
|-
|Yazılım A
|x
|x
|-
|Yazılım B
|<nowiki>-</nowiki>
|x
|}
'''<big>7.2. DOKÜMANTASYON</big>'''

Tanımlanmış bakım seviyeleri kapsamında yazılım destek dokümantasyonunun hazırlanması gerekmektedir. Yüklenici tarafında gerekli yazılım destek dokümantasyonu veya kullanıcıya tanımlanan yetkiler dahilinde son kullanıcı el kitabı, yükleme, konfigürasyon gibi amaçları olan yönetim dokümantasyonları olabilir.

Operasyonel açıdan, orta ve üst düzey kullanıcılar açısından dokümantasyon önemlidir. Dokümantasyon; yükleme, konfigürasyon adımları ve sorun giderme ile ilgili taktikler içermelidir. Ciddi hatalar oluşması durumunda da yüklenici firma iletişime geçilecek kişinin iletişim bilgilerini de içermelidir.

'''<big>7.3. YAZILIM YÜKLEME VE KALDIRMA</big>'''

Yazılımların güvenli bir şekilde sisteme yüklendiği, sistemin problemsiz çalıştığı ve yazılımın kaldırılması test prosedürleri ile doğrulanmış ve dokümante edilmiş olmalıdır.

'''<big>7.4. DONANIMLAR ÜZERİNDE TAŞINMA</big>'''

Eğer yazılımın bir donanım üzerinde taşınması gerekiyorsa yazılımın tipine, boyutuna ve güvenlik gereksinimlerine göre hangi donanımla taşınacağı belirlenir. Çipler veya usb belleklerle taşınıp taşınamayacağı, hard disk ya da DVD ihtiyacı olup olmadığı, donanımda taşımanının güvenli olup olmadığı değerlendirilmelidir.

'''<big>7.5. GENİŞLEME KAPASİTESİ</big>'''

Genişleme kapasitesi sistem tasarımının bir parçasıdır, yazılımla ilişkili olsa da genellikle tüm sistem tasarımı içerisinde ele alınması gereken bir donanım karakteristiğidir. Yazılımın hesaplama kaynakları üzerinde kısıtlamalarda (işlemci performansı, bellek, girdi/çıktı bant genişliği, veritabanı kapasitesi, network performansı vb.) limiti olmadan ne kadar değiştirilebildiği ile ilgilenir. Genişleme kapasitesi yeterli detayda ele alınmazsa yazılım modifikasyonu limitli olacaktır. Modifikasyon maliyeti ciddi ölçüde artacak ve ek aktiviteler gerekebilecektir. Genişleme kapasitesi, sabit donanım konfigürasyonu olan sistemlerde ve gömülü sistem gerçek zaman uygulamalarında yüksek önem taşır. Bu nedenle tasarım safhasında genişleme kapasitesinin göz önünde bulundurulması önemlidir.

'''<big>7.6. MODÜLER YAZILIM TASARIMI</big>'''

Modülerlik yazılım tasarım yapısının bir özelliğidir. Bir yazılım paketinin içindeki işlevselliğin farklı alanları modüller yardımıyla yapılandırılır. Bir yazılım tasarımına modülerlik kazandırma imkânı tasarım yöntemi, programlama araçları ve programlama dili seçimiyle belirlenir. Optimum modülerliğe, desteklenebilir tasarım karşısında işlevsel ve performans gereksinimlerinin dengelenmesi ile ulaşılır. Yetersiz modülerlik ilave modifikasyon eforuna ve maliyetine sebep olur. Bu nedenle tasarım safhasında modülerliğin göz önünde bulundurulması önemlidir.

'''<big>7.7. MODİFİKASYON FREKANSI (DEĞİŞİKLİK TRAFİĞİ)</big>'''

Yazılımın modifikasyon ihtiyacının oranıdır. Yazılım kullanımından önce modifikasyon frekansı tahminleri benzer uygulamaların (kullanımdaki yazılımlar) yardımı ile yazılımın bazı karakteristikleriyle, test ve deneme fazındaki deneyimlerle yapılabilir. Modifikasyon frekansının kararlılığı yazılım entegrasyonunu ve sistem operasyonunu etkiler. Değişiklik trafiği, yazılım destek aktivitelerinin hacmini etkiler. Yüksek değişiklik trafiği daha fazla yazılım modifikasyon aktivitesi demektir. Bu nedenle tasarım safhasında modifikasyon frekansının göz önünde bulundurulması önemlidir.

'''<big>7.8. GERİYE DÖNDÜRME</big>'''

Bir yazılım hatasından kaynaklı sistem çalışmadığında, sistemi yeniden başlatmak veya en azından kabul edilebilir bir sürede azalmış ama kabul edilebilir işlevselliğe getirmek gereklidir. Geriye döndürme yazılımın erken tasarım safhalarında, sağlıklı izleme durumu, hataya toleranslı denetimciler, hata ayıklama (debug) özelliği için tasarım gibi konular da değerlendirilmelidir. Erişilebilir ekipmanla operasyonel gerçek zaman güncellemesi gerçekleştirebilecek bir geriye döndürme özelliği olması kritik önem taşımakta olup geliştirme safhasında dikkate alınmalıdır. Gerçek bir acil durum oluşmadan yazılımın geriye döndürülmesi test edilmiş olmalıdır.

'''<big>7.9. EMNİYET ENTEGRASYONU</big>'''

Sistemin emniyet analizi yazılımlar da dikkate alınarak yapıldıktan sonra, sistem tasarımı kritik fonksiyonları olan yazılım kalemlerinin minimize edilmiş olduğunu ya da en azından kritik fonksiyonların yazılımın diğer kısımlarından ayrıştırıldığını garanti etmelidir. Emniyet entegrasyonu yalnızca yazılım tasarımıyla ilgili değildir. Yazılımın taşıma, yükleme ve kullanımında da (ör. yazılımlara kullanıcı erişimleri) belirli bir emniyet seviyesine ulaştığı garanti edilmelidir.

'''<big>7.10. GÜVENLİK</big>'''

Yazılımın kendisi ile ilgili olup; dijital imza, aktivasyon veya lisans anahtarları, kriptolama, çevrimsel hata denetimi gibi güvenlik metotları mevcuttur. Yazılımın güvenlik sınıflandırması, çalıştırılabilir kodu ve dokümantasyonu yazılım destek aktivitelerini kısıtlayabilir. Yazılıma erişim kısıtlanabilir ve spesifik yazılım test görevleri ve ekipmanlarının önemini artıracak gereksinimler tanımlanabilir. Yazılımın güvenlik sınıflandırması, uygulamaya ve ekipmanın tasarımına bağlıdır. Mümkün olduğu ölçüde güvenlik seviyesi yüksek yazılımlar, sistemdeki diğer yazılımlardan ayrı olmalıdır. Güvenlik gereksinimleri sınıflandırmada kullanılacak ve sınıflandırmaya uygun olarak modifikasyon ve yazılımın ele alma kısıtlarını belirleyecektir.

Güvenliğin diğer bir boyutu operasyonel karakteristiktir. Yazılım paketinin hem uygun kullanıcı erişimi gibi iç güvenlik hem de dış güvenlik açısından güvenli bir ortamda çalıştığı garanti edilmelidir. Bu anlamda ağ ve güvenlik duvarı yönetim aktiviteleri, virüs tespiti ve savunma aktiviteleri gerçekleştirilir.

Savunma ve güvenlik sistemlerindeki yazılımlar üçüncü tarafın eline geçmemesi için kullanımdan sonra silinebilir. Bu konuya ilişkin tedbirlerin alınmış olması gerekir.

'''<big>7.11. BOYUT</big>'''

Yazılım paketinin boyutu, beklenen değişiklik trafiği seviyesi ve modifikasyonları uygulamak için gereken kaynaklar açısından desteklenebilirlik parametrelerini etkiler. Yazılımın boyutu, uygulamaya ve tasarım çözümüne bağlıdır. Sistem tasarımında boyutla ilgili bir kısıt varsa yazılım gereksinimlerinde belirtmelidir. Birçok yazılım desteği yazılımın boyutuna ve karmaşıklığına bağlıdır.

'''<big>7.12. YETKİNLİKLER</big>'''

Yetkinlik gereksinimleri, sistem tasarımı, yazılım tasarımı ve uygulanabilir yazılım destek politikası tarafından belirlenir. Personelin yetkinlik seviyesi, birden fazla açıdan değerlendirilmelidir. Sırasıyla basit düzeyde kullanıcı, yönetim sorumluluğu olan operatörler ve en yetkin olması gereken yazılım modifikasyonu yapacak kişilerdir.

'''<big>7.13. YAZILIM DAĞITIMI</big>'''

Yazılım LAN, WAN gibi ağlar üzerinden veya bir donanım aracılığıyla farklı medya tipleri ile dağıtılabilir.

'''<big>7.14. TEKNOLOJİ</big>'''

Yazılım tasarım yöntemleri ve destek araçları, işleten sistemler, programlama dilleri, derleyiciler, hata ayıklayıcılar, yazılım test metot ve test ortamı, projeye özgü ekipman ve teknikler gibi yazılım mühendisliği metotları ve yazılım geliştirme-uygulamada kullanılan araçlar da dikkate alınmalıdır. Teknolojinin ağ üzerinden yapılacak destek bakım konseptini kolaylaştırması gibi operasyonel olarak da etkileri vardır.

== EK-I ÖRNEK LDA PLANI ==
'''<big>1. GENEL</big>'''
* Programın hem yüklenici hem de müşteri tarafındaki yönetim yapıları
* LDA faaliyetlerinin proje takvimi ile entegrasyonu
* Sorumluluklar
* Değişiklik yönetimi
* Risk yönetimi
* İş paylaşımı anlaşmaları

'''<big>2. SİSTEM TANIMI VE OPERASYONEL KONSEPT TANIMI (BKZ. BÖLÜM 5.1)</big>'''

'''<big>3. LDA SÜRECİNİN VE ANALİZ FAALİYETLERİNİN AMACI</big>'''

LDAK’nın çıktılarından biri olarak, yüklenici ve müşteri LDA faaliyetleri sonucu oluşan verilerin nasıl kullanılacağına dair prensiplerde anlaşmalıdır. Analiz verilerinin bir lojistik veri tabanında dokümante edilmesi gereksinimi, veri toplamanın amacını da ortaya koymalıdır. Bu amaçla, hangi veri elemanlarının lojistik veri tabanında kaydedileceği dikkatle kararlaştırılmalı ve veri elemanları tanımlanan bu amaçlarla ilişkilendirilmelidir. Seçim konusundaki bu hassasiyet analiz faaliyetleri açısından da gösterilmelidir. Özellikle geniş kapsamlı ve detaylı analizler için seçim teknik ve ekonomik hususları dikkate alarak gerçekleştirilmelidir.

Proje kapsamında uygulanmasına karar verilen analiz faaliyetleri;

* EK-A İnsan Faktörü Analizleri ve LDA,
* EK-B HTE(K)A ve Sonuçlarının LDA İçerisine Kullanımı,
* EK-C Hasar ve Özel Olay Analizleri,
* EK-D Lojistik İlişkili Operasyonlar Analizi,
* EK-E Planlı Bakım Programı Geliştirme,
* EK-F Onarım Seviyesi Analizi,
* EK-G Bakım Görev Analizi,
* EK-H Yazılım Destek Analizi,
* İdame Edilebilirlik (Bkz Bölüm 6.2.3) Analizi.

bölümlerinde yer alan yöntemler uygulanarak gerçekleştirilmelidir. Ancak ilgili yöntemlerin proje türü, süreçleri ve gereksinimlerine göre hangi kural ve varsayımlar çerçevesine nasıl uygulanacağı alt başlıklar halinde detaylı bir şekilde uyarlanmalıdır. Hangi faaliyetlerin hangi seviyede yapılacağı bilgisi ile yapılan uyarlamalar ile gerekçeleri LDAP’ın bu bölümünde belirtilmelidir.

'''<big>4. ÜRÜN KIRILIM YÖNTEMİ</big>'''

Planın bu bölümünde bir ürün kırılım yöntemi oluşturmak üzere kurallar belirlenmelidir. Müşteri ve Yüklenici arasında, kırılım elemanlarının nasıl tanımlanacağı (ör, S1000D Standart Numaralandırma Sistemi, 1388-2B Lojistik Kontrol Numarası sistem veya Müşteri tarafından tercih edilecek diğer sistem) açıklığa kavuşturulmalıdır. Kırılım için hem fiziksel hem de işlevsel yapının birlikte kullanılması gerekli görülüyorsa, bu iki yapının birbiri ile nasıl ilişkilendirileceği tanımlanmalıdır. Yöntem, yazılım kalemlerinin hiyerarşik yapıda nasıl kapsanacağını ve farklı nihai ürün varyantlarının nasıl ele alınacağını da açıklamalıdır.

'''<big>5. ANALİZ EDİLEN KALEM İÇİN KIRILIM DERİNLİĞİNİN BELİRLENMESİ</big>'''

Kırılım türünün yanısıra derinliği de son derece önemli bir niteliktir. Nihai karar verilirken aşağıdaki hususlar dikkate alınmalıdır:

* İlgili bütün yedek parçaları belirlemek için tam detaylı bir kırılım gerekli midir ve bu kırılım uygun ve etkili midir?
* Sadece HDB seviyesine kadar inen bir kırılım uygun ve etkili midir?
* Belirli yetki kademeleri için tanımlanmış tamir konsepti için hangi seviyede kırılım gereklidir?
* Eğer isteniyorsa, işlevsel kırılım hangi amaçla gerekli görülmektedir (ör. planlı bakım analizleri) ve işlevsel kırılım ile fiziksel kırılım arasındaki bağlantı nasıl oluşturulmaktadır?

'''<big>6. LDA ADAY SEÇİM KRİTERLERİ</big>'''

LDA adaylarının seçimi için oluşturulan kriterler LDA Planında dokümante edilmelidir. Bu konuda bir akış şeması da oluşturulabilir.

'''<big>7. ADAY KALEM LİSTESİ (AKL)</big>'''

LDA İş Tanımlama Toplantısı (LDAİTT)’na hazırlık olarak yüklenici tarafından taslak bir AKL hazırlanmalı, toplantıda yüklenici ve müşteri arasında tartışılarak AKL üzerinde mutabakata varılmalıdır. Üzerinde uzlaşılan AKL, LDAİTT’nın resmi bir çıktısıdır.

'''<big>8. ADAY ELEMANLAR İÇİN POTANSİYEL ANALİZ FAALİYETLERİ</big>'''

AKL sadece ürün ağacından analize tabi olmak üzere seçilen elemanları değil aynı zamanda bu elemanlar için gerçekleştirilecek analiz faaliyetlerini de içerebilir. Seçilen analizlerle birlikte, analizlerin gerçekleştirileceği derinlik de tanımlanmalıdır. Örneğin BGA için her bir bakım görevinin hangi derinlikte dokümante edileceği ve personel gereksinimlerinin belirlenmesine gerek olup olmadığı tanımlanmalıdır.

AKL aynı zamanda LDA programı için bütün eforun özetlendiği bir gözden geçirme vasıtası olarak ve çalışmaların ilerlemesinin takip edildiği bir yönetim aracı olarak da kullanılabilir.

'''<big>9. YEDEK PARÇALARIN BELİRLENMESİ VE YEDEK PARÇA SAYILARININ HESAPLAMASI (Bkz. EK-G BAKIM GÖREV ANALİZİ) </big>'''

'''<big>10. HİZMET İÇİ KULLANIM VE DESTEK SAFHALARI LDA FAALİYETLERİ (Bkz. BÖLÜM 7)</big>'''

'''<big>11. LDA SÜRECİ-TASARIM SÜRECİ ARAYÜZÜ</big>'''

Yapılan LDA faaliyetleri ile tasarım faaliyetlerinin birbiri ile arayüzünün nasıl tesis edileceği ve izlenebilirliğin nasıl sağlanacağı bu bölüm kapsamında açıklanmalıdır.

'''<big>12. LDA SÜRECİ-ELD SÜRECİ ARAYÜZÜ</big>'''

Yapılan LDA faaliyetleri ile ELD faaliyetlerinin birbiri ile arayüzünün nasıl tesis edileceği ve izlenebilirliğin nasıl sağlanacağı bu bölüm kapsamında açıklanmalıdır.

'''<big>13. LDA FAALİYETLERİNİN PERFORMANSININ ÖLÇÜLMESİ VE DOĞRULANMASI</big>'''

LDA faaliyetlerinin performansı, örneğin lojistik veri tabanın statü bilgisi vasıtasıyla sürekli olarak değerlendirilmelidir. Bir analiz faaliyetinin tam olarak gerçekleştirilmesi veya bir aday bileşenin bilgilerinin lojistik veri tabanında tam olarak dokümante edilmesine dair kriterler açık bir şekilde belirlenmelidir ve gerektiğinde kabul kriteri olarak tanımlanmalıdır.

'''<big>14. BİLİŞİM HUSUSLARI</big>'''

Farklı bölgelerdeki aynı analiz aktiviteleri için farklı yazılım paketleri kullanılmamalıdır. Kullanılması durumunda entegrasyon ve uyumlandırma süreçleri açısından bir takım riskler oluşabilir. Lisans ile ilişkili hususlar, sözleşmesel kısıtlar, bilişim hususları ile ilişkili türlü faktörlerden birçok proje farklı yazılım paketleri kullanmaktadır. Böyle bir durumda, gerçekleştirilecek görevler için tüm paydaşlar arasında uyumlu olan yazılım paketinin kullanımı tavsiye edilir. Yazılım paketleri ile ilgili kararlar LDA GGT’da dokümante edilmelidir. Bir program esnasındaki yazılım yayımlama değişiklikleri uyumlandırılmalı ve etkilenen tüm paylaşlar arasında mutabakat sağlanmalıdır.

'''<big>DOKÜMANIN HAZIRLANMASINDA GÖREV ALAN KURUM/KURULUŞLAR</big>'''

SAVUNMA SANAYİİ BAŞKANLIĞI

MİLLİ SAVUNMA BAKANLIĞI

KARA KUVVETLERİ KOMUTANLIĞI

HAVA KUVVETLERİ KOMUTANLIĞI

TERSANELER GENEL MÜDÜRLÜĞÜ

ASELSAN A.Ş.

ASFAT A.Ş.

BMC OTOMOTİV SANAYİ VE TİCARET A.Ş.

HAVELSAN A.Ş.

METEKSAN SAVUNMA SANAYİ A.Ş.

MİLSOFT YAZILIM TEKNOLOJİLERİ A.Ş.

NUROL MAKİNA VE SANAYİ A.Ş.

OTOKAR OTOMATİV VE SAVUNMA SANAYİ A.Ş.

ROKETSAN A.Ş

SATURN DANIŞMANLIK EĞİTİM VE MÜH.LTD.ŞTİ.

SDT UZAY VE SAVUNMA TEKNOLOJİLERİ

VİYA LOJİSTİK MÜHENDİSLİK VE BİLİŞİM TEKNOLOJİLERİ LTD.ŞTİ.