Müşteri Özel Gereklilikleri (CSR) BT Departmanını Nasıl Etkiler?

IATF 16949 belgeli bir tedarikçinin BT ekibi standardın kendi maddelerine genelde hazırdır. Denetimde sorun çıkaran, müşteri özel gereklilikleridir (CSR). OEM’in kalite el kitabındaki tek cümle BT için yeni bir saklama süresi, bir bilgi güvenliği etiketi ya da kesintisiz çalışması beklenen bir EDI bağlantısı anlamına gelir; ve bu cümleyi çoğu zaman BT’den kimse okumamıştır. Aşağıda CSR dokümanlarını BT gözüyle okumayı, yükümlülükleri ayıklamayı ve bunları takip edilebilir bir aksiyon listesine çevirmeyi anlatıyoruz.

CSR nedir ve IATF ile ilişkisi

Müşteri özel gereklilikleri, bir OEM’in veya üst seviye tedarikçinin IATF 16949’a ek olarak tedarikçilerinden beklediği kuralların bütünüdür. IATF 16949 bunları isteğe bağlı bırakmaz: madde 4.3.2, CSR’ların değerlendirilmesini ve kalite yönetim sisteminin kapsamına alınmasını ister. Denetçi, müşteriniz için geçerli bir CSR’ı karşılamadığınızı görürse bunu standardın ihlali olarak yazar. “Bu müşterinin el kitabı” savunması geçmez.

CSR’ların BT açısından üç özelliği var:

• Dağınıktırlar: Tek bir dokümanda değil; kalite el kitabı, tedarikçi portalı duyuruları, lojistik el kitabı, satın alma genel şartları ve sözleşme eklerine yayılmış olabilirler.
• Değişirler: OEM’ler CSR dokümanlarını revize eder; yeni sürüm çoğu zaman yalnız portalda yayımlanır, kimseye e-posta gelmez.
• Zincir boyunca aşağı akarlar: IATF 16949 madde 8.4.3.1, yasal ve düzenleyici gereklilikler ile özel ürün/proses karakteristiklerinin tedarikçilere aktarılmasını ve tedarik zinciri boyunca aşağıya yansıtılmasını ister; birçok OEM CSR’ı da kendi gerekliliklerinin alt tedarikçilere aktarılmasını şart koşar. Tier 2 iseniz gereklilikler size hem doğrudan müşterinizden hem de onun aktardığı OEM gerekliliklerinden gelir.

IATF tarafından tanınan OEM’lerin CSR dokümanlarının listesi ve bağlantıları IATF Global Oversight sitesinde yayımlanır. Ama tüm müşteriler bu listede değildir, sözleşme bazlı ek gereklilikler de orada görünmez. Liste başlangıç noktasıdır, envanter değil.

CSR’larda BT’yi ilgilendiren tipik başlıklar

CSR metni kalite ekibi için yazılır; BT yükümlülüğü satır arasında kalır. “Bilgi güvenliği” kelimesi hiç geçmeyen bir paragraf EDI kesintisi için bildirim süresi tanımlıyor olabilir. Okurken şu başlıkları arayın:

Bilgi güvenliği ve gizlilik

Bazı OEM’ler belirli bir bilgi güvenliği seviyesinin kanıtını ister: TISAX etiketi, ISO 27001 sertifikası ya da kendi güvenlik anketlerinin doldurulması. Prototip veya müşteri çizimiyle çalışan tedarikçiler için bu gereklilik daha sıkıdır. Gereklilik anket olarak geldiyse cevaplama yöntemi için otomotiv müşteri bilgi güvenliği anketleri yazısı yol gösterir; TISAX talebi geldiyse tedarik zincirinde TISAX talebi yazısı süreci anlatır.

Elektronik veri değişimi ve portallar

Teslimat planı, sevk bildirimi, fatura ve kalite bildirimleri için belirli EDI standartları (örneğin EDIFACT DELFOR/DESADV, VDA mesajları, ANSI X12) ve iletim protokolleri (örneğin OFTP2, AS2) istenebilir. CSR ayrıca EDI mesajlarının hangi süre içinde işleneceğini ya da sevk bildiriminin sevkiyattan ne kadar önce gönderileceğini tanımlayabilir. Bu süreler doğrudan sistem erişilebilirliği gereksinimine dönüşür. EDI sunucusu gece durursa sabahki sevkiyat bildirimsiz çıkar.

Kayıt saklama

IATF’in genel kuralı parçanın aktif olduğu süre artı bir yıldır; CSR’lar belirli kayıtlar için daha uzun sabit süreler tanımlayabilir. Bu bilgi arşivin saklama kurallarına aktarılmalı. Uygulaması PPAP ve kalite kayıtlarının arşivlenmesi yazısında.

Acil durum ve süreklilik

IATF 16949 madde 6.1.2.3, acil durum planlarının bilgi teknolojisi sistemlerine yönelik siber saldırıları da kapsamasını ister. CSR’lar buna müşteriye bildirim süresi, alternatif iletişim kanalı veya tedarik kesintisi bildirimi gibi kurallar ekleyebilir. Fidye yazılımı e-posta sunucusunu da götürdüyse müşteriye hangi kanaldan ulaşacağınız önceden yazılı olmalı. Plan ve tatbikat tarafı için IATF 16949 siber saldırı acil durum planı yazısına bakın.

Mühendislik verisi ve yazılım

Müşteri CAD verisinin hangi formatta alınacağı, hangi kanaldan paylaşılacağı ve proje sonunda nasıl iade edileceği; gömülü yazılım içeren ürünlerde yazılım geliştirme süreci beklentileri bu başlık altında durur. Mühendisin kişisel bulut hesabından paylaşılan bir müşteri çizimi, bu maddenin sahadaki tipik ihlalidir.

CSR–BT aksiyon eşleme tablosu

CSR okumasının çıktısı bir eşleme tablosudur. Her satır bir CSR maddesini, BT’ye yansımasını, sorumluyu ve kanıtı gösterir. Aşağıdaki satırlar tipik bulguları temsil eder; madde numaraları sizin müşterinizin dokümanından gelecek.

CSR gerekliliği	BT aksiyonu	Kanıt	Sahip
Bilgi güvenliği etiketi/sertifikası	Kapsam belirleme, kontrol boşluk analizi	Etiket/sertifika, aksiyon planı	BGYS sorumlusu
Belirli EDI mesaj ve protokolü	EDI altyapısı, sertifika yönetimi, izleme	Test kayıtları, hata izleme raporu	BT uygulama
Sevk bildirimi süresi	Erişilebilirlik hedefi, alarm, yedek prosedür	Kesinti kayıtları, manuel prosedür	BT altyapı
Uzatılmış kayıt saklama	Arşiv saklama kuralı güncellemesi	Saklama matrisi, arşiv yapılandırması	Kalite + BT
Kesinti/kriz bildirimi	Acil durum planına müşteri iletişim adımı	Plan revizyonu, tatbikat kaydı	BT yöneticisi
Portal kullanımı	Kullanıcı ve yetki yönetimi, çıkışta kapatma	Portal kullanıcı listesi gözden geçirmesi	Kalite + BT

Tablo kendi başına bir şey kapatmaz. Her satırın kapanış durumu izlenmeli. Pratikte tablo, aksiyon takip sisteminizde (DÖF aracı, iş takip sistemi veya BGYS aksiyon listesi) her satır için bir kayda dönüşür. Sahibi ve hedef tarihi olmayan satır, bir sonraki denetimde aynı bulgu olarak geri gelir.

Müşteri portalları ve EDI erişim yönetimi

OEM portalları (tedarikçi portalı, kalite bildirim sistemi, mühendislik veri değişim platformu) genellikle BT envanterinde yoktur. Kullanıcıları kalite, lojistik veya satın alma ekibi kendisi açar. Sonuç üç tanıdık risktir:

• İşten ayrılan kullanıcılar: Kurumsal kimlik sisteminde kapatılan kullanıcının harici portaldaki hesabı açık kalır.
• Paylaşılan hesaplar: Tek bir “kalite@” hesabının birden fazla kişi tarafından kullanılması, portalda verilen onayların kime ait olduğunu belirsizleştirir.
• Sahipsiz bildirimler: Portaldan gelen CSR revizyonu veya kalite bildirimi, artık şirkette olmayan birinin e-posta adresine düşer.

Kontrol basittir: harici portallar için bir envanter tutun. Portal adı, müşteri, işlev, hesap sahipleri, bildirim e-posta adresi (kişisel değil, rol tabanlı dağıtım listesi) ve son gözden geçirme tarihi. Bu envanter işten çıkış kontrol listesine ve periyodik erişim gözden geçirmesine bağlanır. Erişim gözden geçirmesinin kanıt olarak nasıl belgeleneceğini erişim gözden geçirme kanıtı yazısı anlatır.

EDI tarafında en sık atlanan nokta sertifika süreleridir. OFTP2 (RFC 5024) ve AS2 bağlantıları sertifika tabanlı kimlik doğrulama ve şifreleme kullanır. Sertifikanın süresi dolunca mesaj akışı durur, teslimat planları gelmez; hata çoğu zaman ilk olarak lojistikte “bu hafta çağrı yok” şeklinde fark edilir. EDI sertifikalarının bitiş tarihleri izleme sistemine eklenmeli, yenileme takvimi karşı tarafla önceden paylaşılmalı. Yeni sertifikayı karşı tarafa son gün göndermek işe yaramaz; onların da devreye alma süresi var.

CSR değişikliklerinin takibi

IATF 16949 madde 7.5.3.2.2, müşteri mühendislik standartları ve spesifikasyonlarındaki değişikliklerin gözden geçirilmesi için dokümante bir süreç ister ve bu gözden geçirmenin en geç 10 iş günü içinde tamamlanmasını şart koşar. Madde mühendislik spesifikasyonları için yazılmıştır; ama CSR değişiklikleri için de aynı disiplinde bir takip pratikte gereklidir.

Asgari yapı şöyle kurulur:

1. CSR kayıt defteri: Her müşteri için geçerli CSR dokümanları, revizyon numaraları, yayın tarihleri ve kaynak (portal yolu veya bağlantı).
2. Değişiklik izleme: Portalları periyodik kontrol eden bir sorumlu ve portal bildirimlerinin düştüğü rol tabanlı bir posta kutusu.
3. Fark analizi: Yeni revizyonda değişen maddelerin listelenmesi; çoğu OEM revizyon geçmişi tablosu yayımlar, yoksa önceki sürümle metin karşılaştırması yapılır.
4. Etki değerlendirmesi: Değişen her madde için “BT etkisi var mı?” sorusunun cevaplanması ve gerekirse eşleme tablosuna yeni satır eklenmesi.
5. Kapanış: Değerlendirme tarihinin ve kararın kayda geçirilmesi.

Bu yapı kurulunca denetçi “bu CSR’ın son revizyonu ne zaman yayımlandı, siz ne zaman değerlendirdiniz?” diye sorduğunda cevap tek kayıttan gelir. Kurulmadıysa cevap bir e-posta yığınında aranır.

Denetimde CSR uyumunun gösterilmesi

IATF denetimlerinde denetçiler genellikle kuruluşun müşteri listesinden ilgili CSR’ları örnekler ve süreçlerde nasıl karşılandığını sorar. BT tarafında masada şunlar olmalı:

• Müşteri bazında güncel CSR listesi ve revizyon durumu
• CSR–BT eşleme tablosu ve her satırın kapanış kanıtı
• İç denetim programında CSR’ların kapsandığını gösteren kayıt (madde 9.2.2.2, kalite yönetim sistemi denetimleriyle birlikte müşteri özel KYS gerekliliklerinin de örneklenmesini ister)
• Harici portal envanteri ve son erişim gözden geçirmesi
• EDI bağlantı ve sertifika izleme kayıtları
• Bilgi güvenliği gerekliliği varsa etiket veya sertifika ve geçerlilik tarihi

Standardın genel BT kanıt setiyle birlikte düşünüldüğünde CSR eşleme tablosu IATF BT hazırlığının merkez dokümanlarından biri olur. Genel çerçeve IATF 16949 denetiminde BT kanıtları yazısında. CSR’lardan BT yükümlülüklerini çıkarmak ve müşteri bilgi güvenliği denetimlerine hazırlanmak için IATF 16949 BT gereklilikleri danışmanlığı ve otomotiv tedarikçi bilgi güvenliği hizmetlerimizden yararlanabilirsiniz.

Sık sorulan sorular

CSR’lar nereden bulunur?

IATF tarafından tanınan OEM’lerin CSR dokümanlarına IATF Global Oversight sitesindeki listeden ve OEM’lerin tedarikçi portallarından ulaşılır. Sözleşmeler, satın alma şartları ve doğrudan müşterinizin kalite el kitabı da CSR içerebilir; hepsi tek bir kayıt defterinde toplanmalıdır.

Tier 2 tedarikçi OEM CSR’larından sorumlu mu?

Doğrudan değil, aktarım yoluyla. IATF 16949 madde 8.4.3.1 yasal gereklilikler ve özel karakteristiklerin tedarik zincirinde aşağıya aktarılmasını ister; birçok OEM CSR’ı da kendi gerekliliklerinin aktarılmasını şart koşar. Bu yüzden Tier 2 tedarikçiye doğrudan müşterisinin gereklilikleri ile müşterinin aktardığı OEM gereklilikleri uygulanır. Hangi CSR’ların geçerli olduğunu doğrudan müşterinizle yazılı olarak netleştirin.

CSR değişikliklerini ne kadar sürede değerlendirmeliyiz?

IATF 16949 madde 7.5.3.2.2 müşteri mühendislik standartları için en geç 10 iş günü süre verir. CSR dokümanı için müşterinin belirttiği bir süre varsa ona uyulur; yoksa benzer bir süreyi iç kural olarak tanımlayıp kayıt altında takip edin.

Bilgi güvenliği gerekliliği olmayan bir CSR BT’yi yine de etkiler mi?

Evet. EDI ve portal kullanımı, kayıt saklama süreleri, acil durum bildirimi ve mühendislik verisi paylaşımı gibi başlıklar, metinde bilgi güvenliği kelimesi hiç geçmese de BT sistemleri ve süreçleri üzerinde doğrudan yükümlülük doğurur.