Yeni sisteme geçilmesinin üzerinden altı ay geçmişti. Gözetim denetiminde denetçi müşteri şikâyetleri klasörünü karıştırırken 2019 tarihli bir DÖF'ün numarasını buldu ve kapanış kanıtını istedi: "Bu faaliyetin etkinliğini nasıl doğruladınız?" Kalite ekibi yeni sistemde arattı, kayıt yoktu. Kayıt eski yazılımın lisansı bittiği için kapatılan veritabanının içinde kalmıştı ve o veritabanını açacak sunucu iki ay önce silinmişti. Bu sahne, kötü planlanmış bir QDMS veri göçünün nasıl bittiğini en net anlatan örnektir. Aşağıda hangi kaydın taşınacağına karar veren eleme kriterini ve eski sistemi kapatmadan önce mutlaka yapılması gereken doğrulamayı anlatıyoruz.
QDMS veri göçünde asıl sorulması gereken soru
Yazılım değiştirirken sorulan soru genellikle "verilerimizi taşıyabilir miyiz?" olur. Doğru soru bu değil. Doğru soru şudur: hangi kaydın saklama süresi hâlâ devam ediyor ve o kayıt saklama süresi boyunca okunabilir kalacak mı? Standartlar sizden kayıtları belirli bir yazılımın içinde tutmanızı istemez; ISO 9001 madde 7.5.3 kayıtların korunmasını, okunabilirliğini ve erişilebilirliğini ister. Yani bir kaydı PDF olarak arşivlemek de geçerli bir yöntemdir, yeter ki bulunabilsin.
Bu ayrımı yaptığınızda veri göçü işi birden küçülür. Her şeyi taşımaya çalışan firmalar projeyi aylarca uzatır, üstelik yeni sisteme eski sistemin çöpünü de taşır. Taşınacak veri, üzerinde hâlâ işlem yapılacak veridir: yürürlükteki dokümanlar, açık DÖF'ler, henüz kapanmamış denetim bulguları, geçerli kalibrasyon kayıtları, aktif personelin yetkinlik kayıtları. Gerisi arşiv malzemesidir.
Eleme kriteri: dört soruluk süzgeç
Her kayıt türünü dört soruluk bir süzgeçten geçirin; cevaplar taşıma kararını neredeyse kendiliğinden verir. Bu kaydın üzerinde önümüzdeki 12 ayda işlem yapılacak mı? Bir raporun ya da eğilim analizinin girdisi mi? Saklama süresi ne zaman doluyor? Müşteri ya da mevzuat kaydı belirli bir biçimde istiyor mu? Dördüne birden "hayır" diyebildiğiniz kayıt yeni sisteme değil, arşive gider.
| Kayıt türü | Yeni sisteme taşı | Arşivde bırak | Gerekçe |
|---|---|---|---|
| Yürürlükteki prosedür, talimat, form | Tamamı | — | Günlük kullanımda, dağıtım ve onay akışı gerekiyor |
| Yürürlükten kalkmış doküman revizyonları | Sadece revizyon geçmişi metni | PDF nüshalar | Değişikliğin nedeni sistemde, nüsha arşivde yeterli |
| Açık DÖF ve uygunsuzluklar | Tamamı, elle ve detaylı | — | Takip ve etkinlik doğrulaması devam ediyor |
| Kapanmış DÖF | Son 3 yıl | Daha eskisi | Tekrar eden problem analizi 3 yıllık veriyle yapılır |
| İç denetim raporları | Son 2 sertifikasyon çevrimi | Daha eskisi | Denetim programı geçmişi ve bulgu eğilimi için |
| Kalibrasyon kayıtları | Aktif ekipmanın son 2 sertifikası | Hurdaya ayrılan ekipman | Geriye dönük geçerlilik incelemesi için gerekli |
| Eğitim kayıtları | Çalışan personelin tamamı | Ayrılan personel | Yetkinlik matrisi güncel personel üzerinden yürür |
| Tedarikçi karneleri | Son 12 ayın puanları | Daha eskisi | Onaylı tedarikçi listesi kararları güncel veriye dayanır |
Tablodaki "arşivde bırak" satırları hiçbir şey yapmayacaksınız anlamına gelmez. Bu kayıtların hepsi eski sistemden PDF olarak dışa aktarılıp, kayıt türüne ve yıla göre klasörlenmiş bir arşive konur. Arşivin yolu, sorumlusu ve saklama süresi kayıt kontrol prosedürünüzde yazılı olmalıdır. Aksi hâlde iki yıl sonra o klasörü kimse bulamaz.
Doküman revizyon geçmişini kaybetmeden aktarma
Göçte en çok tartışılan konu doküman revizyon geçmişidir. Eski sistemde bir prosedürün altı revizyonu, her birinin onay tarihi ve onaylayan kişisi durur. Yeni sisteme yüklediğinizde çoğu firma yalnızca son revizyonu yükler ve geçmiş uçar. Bunun önüne geçmenin basit bir yolu var: eski sistemden revizyon geçmişi raporunu tablo olarak dışa aktarın, her doküman için revizyon no, tarih, değişiklik açıklaması ve onaylayan bilgisini yeni kaydın geçmiş alanına metin olarak yerleştirin.
Revizyon numarasını asla sıfırlamayın. Rev.6 olan bir prosedür yeni sistemde Rev.1 olarak açılırsa, sahadaki nüshalarla sistem arasında kalıcı bir uyuşmazlık doğar ve bir sonraki denetimde doküman yönetimi tarafından bulgu alırsınız. Aynı şekilde doküman kodlarını da göç fırsatı sayıp değiştirmeyin. Kodlama sistemini iyileştirmek istiyorsanız bunu göçten en az üç ay sonra, ayrı bir çalışma olarak yapın.
Açık kayıtlar elle taşınır
Açık DÖF, açık denetim bulgusu ve devam eden müşteri şikâyeti kayıtları toplu içe aktarımla taşınmaz. Bunları tek tek, açan kişiyle birlikte gözden geçirerek girin. Sebebi şu: bu kayıtların çoğunda kök neden alanı yarım, doğrulama planı boş, sorumlu kişi şirketten ayrılmış olur. Toplu aktarım bu eksikleri yeni sisteme aynen kopyalar. Elle giriş ise her kaydı bir kez daha okumaya zorlar ve genelde açık kayıtların %20-30'unun aslında kapatılabilir durumda olduğu ortaya çıkar.
Bu adımı kalite ekibi tek başına yapmasın. Üretim, bakım ve satın almadan birer kişiyle iki saatlik bir oturum kurun, açık DÖF listesini ekrana yansıtın ve tek tek karar verin: devam mı, kapanış mı, birleştirme mi. Bu oturum göç projesinin en verimli iki saatidir.
En sık yapılan hata, eski sistemin lisansı bitmeden göçün tamamlanacağı varsayımıyla hareket etmektir. Lisans süresi dolduğunda tedarikçi erişimi kapatır ve veritabanı kendi biçiminde kilitli kalır. Göç projesine başlamadan önce eski sistemin tam veritabanı yedeğini ve tüm ekleri kendi sunucunuza indirin. Bu tek hareket, altı ay sonra denetim odasında yaşanacak paniği tamamen ortadan kaldırır.
Elle giriş sırasında bir de numaralandırma kararı vermeniz gerekir. Açık kayıtların yeni sistemde eski numarasıyla mı yoksa yeni bir numarayla mı açılacağı, projenin başında tek bir cümleyle kararlaştırılmalıdır. Sahada işe yarayan yöntem, yeni sistemin kendi numarasını vermek ve eski numarayı ayrı bir alanda saklamaktır. Böylece hem numaralandırma tutarlı kalır hem de "DOF-2023-118 nerede?" sorusu tek aramayla cevaplanır.
Veriyi dışa aktarırken hangi biçimi istemelisiniz?
Eski yazılımın tedarikçisinden veri istediğinizde çoğu zaman size bir ekran raporu ya da PDF çıktısı verilir. Bu yeterli değildir. Üç ayrı çıktı isteyin ve her birini sözleşmede ya da yazılı talepte adıyla belirtin. Tablo biçiminde veri: dokümanlar, kayıtlar ve kullanıcı listesi için CSV ya da Excel. Eklerin kendisi: her kaydın altındaki dosyalar, kayıt numarasına göre klasörlenmiş hâlde. Bir de ham veritabanı yedeği; hiç açmayacak olsanız bile isteyin.
Ekler en çok atlanan parçadır. Tablo çıktısında "ek dosya: var" yazar ama dosyanın kendisi gelmez; altı ay sonra bir DÖF'ün kapanış kanıtını aradığınızda elinizde yalnızca kaydın satırı kalır. Dışa aktarımı teslim aldığınızda rastgele 10 kaydı seçip ekinin açıldığını kontrol edin. Bu kontrol yarım saat sürer ve projedeki en yüksek getirili yarım saattir.
Dosya adlarında Türkçe karakter sorunu da burada ortaya çıkar. Eski sistemden gelen "Kalıp Bakım Talimatı_Rev3.pdf" gibi bir ad, aktarım sırasında bozulabilir ve dosya açılmaz hâle gelebilir. Aktarımdan sonra klasördeki dosya adlarını hızlıca tarayın; bozuk karakter içeren adları düzeltmek, dosyayı kaybetmekten çok daha kolaydır.
QDMS veri göçünü kim yürütür, ne kadar sürer?
Orta ölçekli bir imalat firmasında, iki kişilik bir kalite ekibiyle veri göçü altı ile on hafta arasında tamamlanır. Bu sürenin yaklaşık yarısı taşımaya değil, karar vermeye gider: hangi kaydın taşınacağı, hangisinin arşive gideceği, kimin sorumlu olacağı. Kararların hızlı alınması için tek bir kişinin onay yetkisi olması gerekir; komite ile yürütülen göç projeleri iki katı sürer.
Ekipte üç rol vardır. Kalite müdürü eleme kriterini onaylar ve tartışmalı kayıtlarda son sözü söyler. Kalite sorumlusu taşıma listelerini hazırlar, doğrulamaları yapar. IT ise dışa aktarım, yedekleme ve içe aktarımın teknik kısmını yürütür. Yeni yazılımın tedarikçisi de sürecin içinde olmalı ama kararları o vermemelidir; onun işi biçimi ve yöntemi çözmektir.
Göç sırasında sistemi dondurma penceresi
Bir QDMS veri göçü projesinde en sessiz kayıp burada yaşanır. Veriyi aktardığınız gün ile yeni sistemin canlıya alındığı gün arasında bir boşluk varsa, o boşlukta eski sisteme girilen her kayıt kaybolur. Bunu önlemenin yolu bir dondurma penceresi ilan etmektir: belirlenen tarihten itibaren eski sisteme yeni kayıt açılmaz, açılması gerekenler kâğıda yazılır ve yeni sistem açıldığında oraya girilir. Pencere 3-5 günü geçmemelidir.
Dondurma tarihini tüm kullanıcılara en az iki hafta önceden duyurun ve duyuruyu yazılı yapın. Sözlü duyurulan dondurma tarihleri sahada tutmaz; birileri eski sisteme kayıt açmaya devam eder ve o kayıtlar aktarım listesine giremediği için sessizce kaybolur. Pencere kapandığında eski sistemin yazma yetkilerini kaldırıp yalnızca okuma yetkisi bırakın; bu, kuralı hatırlatmanın en kesin yoludur.
Eski sistemi kapatmadan önce doğrulama listesi
Göç tamamlandı denilen an ile eski sistemin gerçekten kapatılabileceği an aynı gün değildir. Aradaki farkı bu kontrol listesi doldurur ve tamamı tamamlanmadan hiçbir lisans iptal edilmez.
| # | Doğrulama adımı | Kabul kriteri |
|---|---|---|
| 1 | Yürürlükteki doküman sayısı karşılaştırması | Eski ve yeni sistemdeki sayı birebir aynı |
| 2 | Rastgele 20 doküman içerik kontrolü | Revizyon no, tarih, onaylayan ve dosya içeriği aynı |
| 3 | Açık kayıt mutabakatı | Açık DÖF ve bulgu sayıları eşleşiyor, sorumluları atanmış |
| 4 | Arşiv PDF setinin bütünlüğü | Her kayıt türü için yıl klasörleri eksiksiz, dosyalar açılıyor |
| 5 | Eski numara alanı doldurulmuş | Taşınan her kayıtta eski sistem numarası görünüyor |
| 6 | Ham veritabanı yedeği | Yedek şirket sunucusunda, geri yükleme bir kez denenmiş |
| 7 | Salt okunur erişim süresi | Eski sistem en az 1 ay okunabilir modda açık kalmış |
| 8 | Kayıt kontrol prosedürü güncellemesi | Arşivin yeri, sorumlusu ve saklama süresi yazılı |
Altıncı maddedeki "geri yükleme bir kez denenmiş" ifadesi önemlidir. Yedek almak yetmez; o yedeğin gerçekten açıldığını görmek gerekir. Sahada yedeğin bozuk olduğunun fark edildiği an, genellikle ona ihtiyaç duyulan andır.
Denetçi yazılım değiştirdiğinizi öğrendiğinde ilgisini çeken şey yeni sistemin yetenekleri değil, geçiş öncesi döneme ait bir kaydı ne kadar sürede bulabildiğinizdir. Genelde kapanmış bir DÖF ya da eski bir kalibrasyon sertifikası ister. Beş dakikada gelirse konu kapanır; "eski sistemde kalmıştı" cevabı gelirse kayıt kontrolünden bulgu yazılır.
Göç sonrası ilk 90 gün
QDMS veri göçünün başarısı, canlıya geçiş günü değil üçüncü ayın sonunda belli olur. İlk 90 günde şu üç şeyi ölçün: yeni sistemde açılan kayıt sayısı, kullanıcı sayısı ve arşive dönme sıklığı. Yeni sistemde açılan kayıt sayısı eski aylık ortalamanın altındaysa, insanlar hâlâ kayıt açmadan iş yapıyor demektir. Arşive dönme sıklığı beklenenden yüksekse, taşıma kriteriniz fazla dar kalmıştır ve bir grup kaydı ek olarak taşımanız gerekir.
İkinci ayda bir iç denetim planlayın ve kapsamı doğrudan geçiş süreci olsun. İç denetim ekibi, taşınan kayıtların tam olup olmadığını ve arşive erişimin çalışıp çalışmadığını yerinde görsün. Bu, dış denetimden önce sorunları kendi başınıza bulmanızın en ucuz yoludur. Excel'den gelen bir yapıya geçiyorsanız sıralama biraz farklı işler; onu Excel'den geçiş planı yazımızda ayrıca anlattık.
Eski sistemin kapatıldığı tarihi de bir tutanakla kayıt altına alın. Tutanakta kapanış tarihi, yedeğin bulunduğu yer, arşiv klasörünün yolu ve doğrulama listesinin tamamlandığı bilgisi yer alsın. Bu tek sayfalık kayıt, yıllar sonra "eski verilere ne oldu" sorusuna verilecek en sağlam cevaptır.