Değerlendirme toplantısında masada altı aday vardı. IT müdürü sunumun ortasında araya girdi ve iki cümle kurdu: "Kalite verisinin yurt dışı sunucuda durmasını istemiyoruz. Ayrıca arayüz Türkçe olacak, çeviri değil." Liste o anda altıdan üçe indi. Bu iki şart pazarlıkla esnetilebilecek türden değildir; birincisi müşteri sözleşmelerinden, ikincisi sahadaki kullanıcı gerçeğinden gelir. QDMS yerine ne kullanılır sorusunun cevabı da tam burada şekillenir: seçenekler ihtiyaca göre değil, önce bu tür kısıtlara göre elenir. Aşağıda kalan seçenekleri ölçek, kapsam ve geçiş maliyeti üzerinden ayırıyorum.
İki şart listeyi neden bu kadar daraltıyor?
Verinin yurt içinde kalması şartı üç kaynaktan gelir: müşteri özel şartları, sektörel mevzuat ve şirketin kendi bilgi güvenliği politikası. Otomotivde bazı OEM sözleşmeleri ürün ve süreç verisinin bulunduğu ülkeyi sınırlar; savunma ve havacılıkta bu genellikle tartışmasız bir şarttır. Bulut abonelik modeliyle satılan uluslararası platformların çoğu bu şartı ya hiç karşılamaz ya da ek maliyetli özel bir kurulumla karşılar.
İkinci şart olan arayüz dili teklif aşamasında önemsiz görünür, devreye almada ise eğitim süresini belirler. Çeviri arayüzlerde kalite terminolojisi tutarsızlaşır; "nonconformity" bir ekranda uygunsuzluk, diğerinde uyumsuzluk olarak geçtiğinde tezgâh başındaki kullanıcı hangi menüye gireceğini bulamaz. Türkçe destek dili ise problem anında ortaya çıkar: üretimin durduğu bir sabahta İngilizce bilet açıp saat farkıyla cevap beklemek kabul edilebilir değildir.
Elemeden sonra kalan dört yaklaşım
QDMS yerine ne kullanılır sorusunun cevabı, bu elemeden sonra dört başlıkta toplanır. Birinci yaklaşım kurumsal Türk kalite yönetim paketleridir. Geniş modül yelpazesi, olgunlaşmış iş akışı motoru ve yerleşik danışmanlık ağı sunarlar; kurumsal ölçekte çalışan firmalarda yaygındır. İkinci yaklaşım otomotiv odaklı yerli çözümlerdir; modül sayısı daha odaklı olsa da FMEA, kontrol planı, PPAP, SPC ve MSA tarafında derinleşirler. Bu ikinci grubun ayırt edici yanı, çekirdek araçları eklenti değil doğal parça olarak barındırmasıdır.
Üçüncü yaklaşım sektörel niş yazılımlardır; gıda, sağlık ya da laboratuvar gibi alanlarda mevzuata özel işlevleriyle öne çıkarlar. Metal ve otomotiv tarafında bu grup genellikle yetersiz kalır, çünkü sevkiyat kalitesi ve müşteri şikâyeti akışları farklı kurgulanmıştır. Sektör bazlı ayrımı sektörler sayfamızda ayrıntılandırdık. Dördüncü yaklaşım ise şirket içinde yazılım geliştirmektir ve ayrı bir başlık hak eder.
Bir metal işleme firmasında kalite ekibi kendi doküman takip uygulamasını yazdırmıştı. İlk yıl gayet iyi çalıştı. İkinci yılın sonunda yazılımı geliştiren mühendis işten ayrıldı, kaynak kod dokümante edilmemişti ve IATF 16949 geçişinde saklama süresi kuralları değişince kimse dokunamadı. Firma iki yılın sonunda hazır pakete geçti ve veriyi taşımak için ek bir aktarım projesi ödedi. En sık görülen hata, iç geliştirmenin maliyetini ilk sürümü yazma süresiyle ölçmektir; asıl maliyet sürdürmektir.
Ölçek eşleştirmesi: hangi firmaya hangisi oturur?
QDMS yerine ne kullanılır sorusuna ölçekten bağımsız tek bir cevap yok; sahada gözlenen eşleştirme aşağıdaki tablodaki gibidir. Doküman sayısı ve kullanıcı sayısı, sektörden bağımsız olarak en iyi iki göstergedir; üçüncü gösterge ise otomotiv çekirdek araçlarına ihtiyaç duyup duymadığınızdır.
| Firma profili | Aktif doküman | Uygun yaklaşım | Tipik devreye alma |
|---|---|---|---|
| ISO 9001 belgeli küçük imalatçı | 100-200 | Klasör yapısı + master liste disiplini | — |
| Büyüyen imalatçı, tek tesis | 200-400 | Otomotiv odaklı yerli çözüm ya da temel paket | 6-10 hafta |
| Tier-2 otomotiv tedarikçisi | 300-600 | Çekirdek araçları içeren yerli çözüm | 3-5 ay |
| Tier-1, çok tesisli | 600+ | Kurumsal Türk KYS paketi | 6-12 ay |
| Sektörel mevzuatı ağır firma | Değişken | Sektörel niş yazılım | 4-8 ay |
Tablodaki ilk satır kasıtlı olarak boş bırakıldı. 200 aktif dokümanın ve 25 kullanıcının altında yazılım almak çoğu zaman erken bir karardır; bu ölçekte tek bir kişinin sürdürebildiği bir klasör düzeni hâlâ yetiyor. Bu eşiğin üstünde ise revizyon dağıtımı ve okundu kaydı elle sürdürülemez hâle gelir. Metal ve otomotiv tarafındaki özel ihtiyaçları metal sektörü kalite yazılımı sayfasında topladık.
Geçişin gerçek maliyeti
Teklifte görünen lisans bedeli, geçiş maliyetinin genellikle yarısından azdır. Kalan kalemler şunlar: doküman envanterinin ayıklanması, eski sistemden veri aktarımı, paralel çalışma dönemi, kullanıcı eğitimi ve ilk altı ayda kalite ekibinin normalin üzerinde harcadığı zaman. Doküman ayıklama kalemini küçümsemeyin; 600 dokümanlı bir arşivde kullanılmayan ve mükerrer kayıtları temizlemek bir kişinin iki üç haftasını alır ama devreye alma süresini yarıya indirir.
İkinci kalem eski sistemin kapatılmasıdır. Kayıt saklama süreleri otomotivde ürün ömrü artı belirli bir süre olarak tanımlanır; IATF 16949 madde 7.5.3.2.1 bu sürelerin tanımlanmasını ister. Geçmiş kayıtlarınızı yeni sisteme taşıyamıyorsanız eski sistemi salt okunur olarak açık tutmak zorunda kalırsınız ve bu paralel bir maliyettir. Sözleşme imzalamadan önce verinin hangi formatta dışa aktarılabileceğini yazılı hâle getirin.
Şirket içinde yazılım geliştirmek
Bu seçenek ilk bakışta ucuz görünür ve teknik ekibi olan firmalarda sık gündeme gelir. İlk sürümü yazmak birkaç ay alır; asıl yük sonrasında gelir. Standart revizyonu geldiğinde, müşteri özel şartı değiştiğinde, yeni bir tesis eklendiğinde ya da geliştirici ayrıldığında yazılımın sürdürülmesi gerekir. Kalite yazılımı bir kez yazılıp bırakılan bir araç değildir; yılda birkaç kez değişen kurallara uyum ister.
İç geliştirme ancak iki koşul birlikte sağlanırsa savunulabilir: süreçleriniz piyasadaki hiçbir pakete uymayacak kadar özgünse ve yazılımı sürdürecek kalıcı bir ekibiniz varsa. Bu iki koşulu birlikte sağlayan firma sayısı azdır. Genel çerçeve için kalite yönetim sistemi yazılımı sayfasına bakabilirsiniz.
Yerli çözümlerde nelere bakmalı?
QDMS yerine ne kullanılır listesini üçe indirdikten sonra sıra teste gelir; üç şeyi demo oturumunda kendi verinizle deneyin. Birincisi doküman zinciri: kendi prosedürünüzü yükleyin, iki kademeli onaydan geçirin, revize edin ve o revizyondan eğitim ihtiyacı doğmasını isteyin. İkincisi bulgu zinciri: bir denetim bulgusu açıp DÖF'e bağlatın, kök nedenden doğan aksiyonun bir kontrol planı satırını güncellemesini izleyin.
Üçüncüsü kullanıcı sayısı politikasıdır. Sahayı da sisteme almak istiyorsanız lisans bedelinin kişi başına bağlı olup olmadığı, birkaç yıl içinde toplam maliyeti belirleyen kalem hâline gelir. PaKalite'yi kurgularken çıkış noktamız bu üç madde oldu: şirket içi kurulum, Türkçe arayüz ve modüllerin tek veri üzerinde çalışması. Ölçütlerin tamamını puanlayan bir tabloyu QDMS alternatifi karşılaştırma yazısında bulabilirsiniz.
Paralel çalışma dönemi nasıl yönetilir?
Geçişin en riskli kısmı, iki sistemin bir süre birlikte yürüdüğü dönemdir. Bu dönem ne kadar uzarsa kayıtların ikiye bölünme riski o kadar artar. Uygulamada dört haftalık bir paralel dönem yeterlidir; bu sürede yeni dokümanlar yalnızca yeni sisteme açılır, eski sistem salt okunur hâle getirilir. Yeni doküman açılışını eski sistemde de sürdüren firmalar altı ay sonra hangi listenin doğru olduğunu tartışır.
Paralel dönemde bir de geçiş kesme tarihi ilan edin ve bu tarihi yönetim imzasıyla duyurun. Tarih olmadan geçiş kendiliğinden tamamlanmaz, kullanıcı alışkanlığı eski sisteme çeker. Kesme tarihinden sonra eski sistemden gelen hiçbir kaydı kabul etmeyin; kayıt saklama yükümlülüğü için eski sistemi yalnızca okuma amaçlı açık tutun.
Devreye alma takvimi: hafta hafta
400 dokümanlı bir firmada tipik takvim şöyle işler. İlk iki hafta doküman envanterinin ayıklanması ve süreç sahibi listesinin güncellenmesiyle geçer; bu iki hafta yazılıma hiç dokunulmaz. Üçüncü ve dördüncü haftada kurulum, yetki tanımları ve doküman türlerinin ayarlanması yapılır. Beşinci haftada pilot bir bölümle başlanır; genellikle kalite ile birlikte tek bir üretim bölümü seçilir.
Altıncı ve sekizinci hafta arasında toplu doküman aktarımı ve kullanıcı eğitimleri yürür. Eğitim gruplarını küçük tutun ve oturumu katılımcıların kendi dokümanları üzerinden yürütün; ekrana dokunmadan öğrenen kullanıcı sayısı çok azdır. Dokuzuncu ve onuncu haftada DÖF modülü açılır. Denetim ve eğitim modülleri dördüncü aydan sonra devreye girer. Takvimi sıkıştırıp hepsini tek hamlede açmaya çalışanlarda ise ikinci çeyrek aktarım işine gidiyor.
Yeni sistemin ilk denetimi
Geçişten sonraki ilk belgelendirme ya da müşteri denetimi, sistemin gerçek sınavıdır. Denetçi büyük olasılıkla iki şeyi sorar: geçiş sırasında kayıt kaybı oldu mu ve eski kayıtlara nasıl erişiliyor? Bu iki soruya hazırlıklı gidin. Geçiş planını, aktarılan kayıt sayısını ve doğrulama yöntemini yazılı bir kayda dönüştürün; denetimde bu tek sayfalık kayıt uzun sözlü açıklamaların yerini tutar.
İkinci hazırlık, saklama sürelerinin yeni sistemde doğru tanımlandığını göstermektir. Eski sistemde on yıl tutulan bir kayıt türü yeni sistemde beş yıl olarak tanımlanmışsa bu bir uygunsuzluktur ve aktarım sırasında en sık atlanan ayardır.
Karar öncesi kontrol listesi
QDMS yerine ne kullanılır sorusunu bir toplantıda tartışacaksanız, girmeden önce şu beş bilgiyi hazırlayın: aktif doküman adediniz, sistemi kullanacak kişi sayısı, yılda açtığınız DÖF adedi, otomotiv çekirdek araçlarına ihtiyaç duyup duymadığınız ve verinin nerede duracağına dair IT politikanız. Bu beş bilgi, on teklifi üçe indirir ve geri kalan karşılaştırmayı gerçekten anlamlı hâle getirir.
Son bir uyarı: yeni sistemin başarısını modül sayısıyla değil, bir yıl sonra iyileşmesini beklediğiniz üç sayıyla ölçün. Denetim hazırlık süresi, DÖF kapanma süresi ve doküman onay süresi. Geçiş öncesi bu üçünü kayıt altına alın; aksi hâlde bir yıl sonra "daha iyi mi oldu?" sorusuna yalnızca hislerle cevap verirsiniz.
Bütçe tarafında da gerçekçi olun. Yerli çözümlere geçmenin lisans avantajı vardır ama geçişin kendisi bedavaya gelmez; doküman ayıklama, veri aktarımı, eğitim ve paralel dönemde harcanan mesai gerçek kalemlerdir. Bu kalemleri baştan bütçeye koyan firmalar projeyi planlanan sürede bitiriyor, koymayanlar ise dördüncü ayda ek onay peşinde koşuyor. Geçişi bir yazılım alımı değil, birkaç aylık bir iyileştirme projesi olarak planlayın; sahada farkı yaratan bakış açısı bu. Projeye bir sorumlu, bir takvim ve bir bitiş tarihi atayın; üçü olmadan geçiş süresiz bir "devam ediyor" durumuna sıkışır. Kalite tarafında bu sıkışma en pahalı hâliyle denetim haftasında ortaya çıkar, çünkü o hafta ne eski sistem ne yeni sistem tam anlamıyla hazırdır. Takvimi denetim tarihinden en az iki ay önce bitecek şekilde kurun.