Geçiş kararı verildi, sözleşme imzalandı, kurulum tarihi belirlendi. Ardından ilk proje toplantısında masaya gerçek soru düşer: eski sistemde 3.800 doküman ve 900 DÖF kaydı var, bunların hepsi mi taşınacak yoksa son üç yıl mı? Odadaki herkesin farklı bir cevabı olur. IT "hepsini alalım, yer sorun değil" der. Kalite müdürü "hepsini alırsak kaosu da taşırız" diye itiraz eder. Doğru cevap ikisinin ortasındadır ve QDMS veri taşıma projesinin başarısı büyük ölçüde bu ilk kararın ne kadar bilinçli verildiğine bağlıdır.
Bir kalite yazılımı geçişinde, yani veri taşıma projesinde işin teknik kısmı — dosyaların bir yerden bir yere kopyalanması — toplam emeğin belki üçte biridir. Kalan üçte iki, neyin taşınacağına karar vermek, veriyi temizlemek ve insanları yeni akışa alıştırmaktır. Aşağıda bu üçünü sırayla açıyoruz.
Önce karar: neyi taşıyacaksınız?
QDMS veri taşıma kararını duygusal değil kurallı verin. İşe yarayan üç ölçüt var: kayıt hâlâ yürürlükte mi, yasal ya da müşteri kaynaklı bir saklama süresi içinde mi, günlük işte erişilmesi gerekiyor mu? Üçüne de "hayır" diyen bir kayıt yeni sisteme değil arşive gider. Aşağıdaki tablo tipik bir otomotiv tedarikçisinde bu kararın nasıl verildiğini gösteriyor.
| Veri türü | Karar | Gerekçe | Yöntem |
|---|---|---|---|
| Yürürlükteki dokümanlar | Tamamı taşınır | Günlük kullanımda | Toplu içe aktarım + meta veri |
| Son 2-3 revizyon geçmişi | Taşınır | Denetimde istenir | Sürüm kaydı olarak yüklenir |
| Daha eski revizyonlar | Arşive alınır | Nadiren erişilir | Salt okunur PDF klasörü |
| Açık DÖF kayıtları | Tamamı taşınır | Aksiyonlar devam ediyor | Alan eşleştirmeli aktarım |
| Son 3 yılın kapalı DÖF'leri | Taşınır | Eğilim ve tekrar analizi | Özet alanlarla aktarım |
| Daha eski kapalı DÖF'ler | Arşive alınır | Analitik değeri düşük | Tek dosya dışa aktarım |
| Kalibrasyon kayıtları | Aktif cihazlar taşınır | Sertifika geçerliliği sürüyor | Cihaz kartı + son sertifika |
| Eğitim kayıtları | Aktif personel taşınır | Yetkinlik matrisi canlı | Personel bazlı aktarım |
Bu tabloyu kendi verinizle doldurup üst yönetime imzalattırın. Geçiş ortasında "şu kayıtlar da lazımmış" tartışması çıktığında elinizde onaylı bir kapsam belgesi olur. Kapsamı yazılı hâle getirmeyen projelerde taşıma süresi genellikle iki katına çıkar.
Veri temizliği: taşımadan önceki iki hafta
3.800 dokümanın gerçekte kaçı kullanılıyor? Bu soruyu bir kez ciddiyetle sorduğunuzda sayı çoğunlukla yarıya iner. Kullanılmayan formlar, yıllar önce iptal edilmiş talimatlar, aynı içeriğin iki farklı koddaki kopyaları, sahibi şirketten ayrılmış prosedürler. Bunları olduğu gibi yeni sisteme taşımak, dağınıklığı yeni bir arayüzle sürdürmekten başka işe yaramaz.
Temizlik için süreç sahipleriyle iki haftalık bir tarama yapın. Her sürecin sorumlusuna kendi doküman listesini gönderin ve üç sütun doldurmasını isteyin: kullanılıyor, yürürlükten kaldırılacak, birleştirilecek. Bu tarama geçişten bağımsız olarak da değerlidir; ISO 9001 madde 7.5.3.2 dokümante bilginin (documented information) saklanmasını ve elden çıkarılmasını kontrol altında tutmanızı zaten bekler, kullanılmayan bir dokümanı yürürlükten kaldırmak da bu kontrolün parçasıdır. Genel yaklaşımı doküman yönetimi sayfamızda anlatıyoruz.
Taramanın çıktısını sayıya dökün. Baştaki 3.800'lük listenin iki haftalık elemeden sonra 2.150'ye inmesi hiç şaşırtıcı değildir; bir kısmı yürürlükten kalkar, bir kısmı başka dokümanlarla birleşir. Taşınan kayıt sayısındaki bu düşüş aktarım süresini kısaltmakla kalmaz, geçişten sonra kullanıcıların aradıklarını bulma süresini de düşürür. Aynı mantığı DÖF tarafında da uygulayın: mükerrer açılmış, birbirinin kopyası kayıtları birleştirin, konusu belirsiz olanları kapatın.
Temizliği geçişten sonraya bırakmak, bu projelerin en tanıdık tuzağı. "Önce taşıyalım, sonra düzenleriz" cümlesi hemen her projede duyulur ve hemen hiçbirinde gerçekleşmez. Yeni sistem açıldığı gün insanlar çalışmaya başlar, kimse geriye dönüp 1.500 gereksiz dokümanı ayıklamaz. Temizliği taşımadan önce yapın; iki hafta gecikme, iki yıllık dağınıklıktan ucuzdur.
Doküman kodlama sistemi değişimi ve eşleştirme
Geçiş, kodlama mantığını gözden geçirmek için doğal bir andır — ama zorunlu değildir. Mevcut kodlarınız çakışmıyorsa, süreç yapısıyla uyumluysa ve insanlar ezberlemişse dokunmayın. Kodlar anlamsızsa, aynı kod iki dokümanda kullanılıyorsa ya da eski organizasyon şemasına göre kurulmuşsa değiştirin.
Değiştirme kararı verdiyseniz tek bir kural var: eski kod ile yeni kodu yan yana gösteren bir eşleştirme tablosu hazırlayın ve en az bir yıl yayında tutun. Çünkü sahadaki kayıtlar, eski kontrol planları, müşteri yazışmaları ve geçmiş denetim raporları hep eski kodla atıf yapar. Eşleştirme tablosu olmadığında denetçi "PR-KL-07'yi görebilir miyim?" dediğinde odada sessizlik olur. Tabloyu yeni sistemde bir doküman olarak yayınlayın; böylece kendisi de revizyon kontrolü altına girer.
Revizyon geçmişi ve saklama süreleri
Yeni sisteme yalnızca güncel revizyonu taşımak cazip gelir, çünkü hızlıdır. Ancak denetçi bir prosedürün önceki sürümünü istediğinde eski klasöre dönmek zorunda kalırsınız; bu da geçişin amacını boşa çıkarır. Pratik denge şudur: son iki-üç revizyonu, revizyon tarihi ve onaylayan bilgisiyle birlikte sürüm kaydı olarak yükleyin, daha eskisini salt okunur arşivde tutun. Revizyon zincirinin nasıl kanıta dönüştüğünü revizyon takibi yazımızda ayrıntılı anlattık.
Saklama sürelerini de geçiş sırasında netleştirin. IATF 16949 madde 7.5.3.2.1 üretim parça onayı, takım kayıtları, ürün ve proses tasarım kayıtları, satın alma siparişleri ve sözleşmeler gibi kayıtların, ürün üretimde ve servis şartlarında aktif olduğu süre boyunca artı bir takvim yılı saklanmasını ister; müşteri ya da yasal şart daha uzun bir süre belirtiyorsa o geçerlidir. Bu tanım, hangi eski kaydı silemeyeceğinizi doğrudan söyler. Arşiv klasörünün yedeklenme planı da bu noktada yazılı hâle gelmelidir.
Alan eşleştirme: aktarımın gerçek zorluğu
QDMS veri taşıma denince akla dosya kopyalamak gelir ve kopyalamak kolaydır; asıl iş, eski sistemdeki bir kaydın hangi alanının yeni sistemde nereye karşılık geldiğini tanımlamaktır. Eski DÖF formunuzda "sorumlu bölüm" diye tek bir alan varsa ve yeni sistemde "aksiyon sorumlusu" ile "doğrulayan" ayrı alanlarsa, bu ayrım aktarım sırasında elle yapılmak zorundadır. Aynı şekilde eski sistemde serbest metin olarak yazılan hata tipi, yeni sistemde bir seçim listesine dönüşür.
Bu yüzden aktarımdan önce bir eşleştirme dosyası hazırlanır: sol sütunda eski alan adı, sağ sütunda yeni alan adı, üçüncü sütunda dönüşüm kuralı. Serbest metinden listeye dönüşen alanlarda kural şart, aksi hâlde "kaynak hatası", "kaynak hatasi" ve "Kaynak" üç ayrı kategori olarak yeni sisteme girer ve eğilim analizi ilk günden bozulur. Kalibrasyon kayıtlarında da benzer bir durum vardır: cihaz kodu, ölçüm aralığı ve periyot alanlarının birimleri iki sistemde farklı tanımlıysa aktarım sonrası tüm periyotlar kayar.
Paralel kullanım dönemi kaç hafta olmalı?
İki sistemi aynı anda çalıştırmak kulağa güvenli gelir, uzun sürdüğünde ise tam tersi olur. Sahada işleyen model şudur: kesme tarihinden itibaren yeni kayıtlar yalnızca yeni sistemde açılır, eski sistem dört ile altı hafta boyunca yalnızca okuma amaçlı açık kalır. Bu süre, insanların "acaba şu kayıt taşındı mı" telaşını atlatmasına yeter.
Altı haftayı aşan paralel kullanımda kaçınılmaz olan şey yaşanır: bazı kullanıcılar eski sistemde kayıt açmaya devam eder ve hangi verinin doğru olduğu kaybolur. Kesme tarihini baştan ilan edin, o tarihte eski sistemi yazmaya kapatın ve kapatma işlemini bir kayıtla belgeleyin. Açık DÖF'lerin tamamının o tarihten önce yeni sisteme taşınmış olması da şarttır; ortada yarım kalmış bir düzeltici faaliyet bırakmayın.
Sekiz haftalık örnek proje planı
Ortalama büyüklükte bir tedarikçide QDMS veri taşıma işi sekiz haftada tamamlanır. İlk hafta kapsam kararı ve proje ekibinin kurulmasına gider; kalite, IT ve iki süreç sahibi yeterlidir. İkinci ve üçüncü hafta veri temizliği ile eşleştirme tablosunun hazırlanmasıdır. Dördüncü hafta deneme aktarımı yapılır: 50 doküman ve 20 DÖF kaydı yeni sisteme yüklenir, alanların doğru yere düştüğü kontrol edilir. Bu deneme atlanırsa hatalar 3.800 kaydın tamamında tekrarlanır.
Beşinci hafta toplu aktarım ve doğrulama, altıncı hafta kullanıcı eğitimleri, yedinci hafta paralel kullanımın başlangıcı, sekizinci hafta ise eski sistemin yazmaya kapatılmasıdır. Eğitimleri rol bazında verin: doküman sahibi, onaylayan, DÖF sorumlusu ve okuyucu farklı ekranlar görür, hepsine aynı iki saatlik sunumu yapmak zaman kaybıdır. Geçişin maliyet tarafını hesaplamak isterseniz ROI hesaplama rehberimize bakabilirsiniz.
Geçişten sonraki ilk denetimde denetçi iki şeye bakar. Birincisi, geçiş sırasında doküman kontrolünün kesintiye uğrayıp uğramadığı: kesme tarihi civarında yayınlanmış bir revizyon var mı, o revizyon her iki sistemde de doğru mu görünüyor? İkincisi, taşınmayan kayıtlara erişimin nasıl sağlandığı. Arşive erişim yolu doküman yönetimi prosedüründe yazılı değilse, "kayıtlar korunuyor" ifadesi kanıtsız kalır. Geçiş projesinin kendisini de bir değişiklik yönetimi kaydı olarak tutun; planı, onayı ve kapanışı belgelenmiş bir proje denetimde hiç sorun çıkarmaz.
Geçişte tekrarlayan üç hata
En pahalısı, projeyi tek başına IT'ye bırakmak. Aktarım teknik bir iş gibi görünür ama hangi kaydın hangi alana gideceğine ancak kalite karar verebilir. Deneme aktarımını atlamak da aynı kapıya çıkar; 50 kayıtla yapılan yarım günlük bir test, toplu aktarımda çıkacak hataların neredeyse tamamını önceden yakalar. Üçüncü hata eğitimi geçişten sonraya bırakmak: sistem açıldığında ne yapacağını bilmeyen kullanıcı eski alışkanlığına döner ve kayıtları yine masaüstünde tutmaya başlar.
Bir başlık daha var; sayıya dahil etmedik, çünkü hata değil ihmal: geçiş sonrası doğrulama. Toplu aktarımdan sonra rastgele 30 kayıt seçin ve eski sistemdeki hâliyle birebir karşılaştırın. Doküman adı, revizyon numarası, onaylayan, yayın tarihi ve ekli dosya doğru mu? DÖF kayıtlarında kök neden metni kesilmiş mi, tarihler kaymış mı? Bu yarım günlük kontrolün sonucunu bir tutanağa bağlayın; hem projenin kapanış kanıtı olur hem de ilerideki bir tartışmada elinizde veri bulunur.
Geçiş kararı verirken yazılımın kurulum modeli de bu üç başlığı doğrudan etkiler. Şirket içi kurulan bir sistemde veriler kendi sunucunuzda kalır, aktarım ve yedekleme kontrolü sizde olur; PaKalite bu modelle çalışır ve toplu içe aktarım için hazır şablonlar sunar. Ürün hangisi olursa olsun, QDMS veri taşıma planını yazılı yapın, kapsamı imzalatın ve kesme tarihine sadık kalın. Bu üçü tutarsa 3.800 dokümanlık bir taşıma, korkulduğu gibi aylar süren bir kâbusa değil sekiz haftalık düzenli bir projeye dönüşür.