Cuma akşamı 19:40. Üretim çoktan durmuş, kalite ofisinde üç kişi kalmış: kalite şefi, bilgi işlemden bir mühendis ve girdi kontrolden bir tekniker. Masada dört yıllık kalibrasyon takip dosyası açık, ekranda ise yeni kalite yönetim sistemi yazılımı ilk kez boş bir ekipman listesiyle bakıyor. Soru basit ama can sıkıcı: "Bu 620 satırın hangisi hâlâ geçerli?" Kurulumun gerçekte nerede zorlaştığını gösteren an tam da budur. Yazılımı sunucuya kurmak birkaç saat, sistemi işletir hale getirmek ise haftalar sürer. Bu yazıda bir kalite yönetim sistemi yazılımı kurulumunu proje disipliniyle nasıl yürüteceğinizi, veri göçünü nasıl planlayacağınızı ve devreye alırken ISO 9001 / IATF 16949 madde 7.5.3 dokümante bilginin kontrolü şartını nasıl koruyacağınızı anlatıyoruz.
Kurulum neden bir yazılım işi değil, bir proje işidir?
Firmalar kurulumu çoğunlukla bilgi işlemin görevi sayar. Oysa devreye alma sırasında alınan kararların neredeyse tamamı kalite kararıdır: doküman numaralandırma mantığı, onay zincirinde kimin imzası olacağı, DÖF'ün hangi aşamada kapanmış sayılacağı, kalibrasyon periyodunun hangi tarihten sayılacağı. Bunlar sunucu ayarı değil, kalite yönetim sistemi tasarımıdır. Yazılım yalnızca bu tasarımı uygular.
Bu yüzden ilk toplantıda üç şey netleşmelidir: proje sahibi kim, hangi modül hangi tarihte canlıya alınacak, kararı kim verecek. Sahibi belli olmayan kurulumlar altı ay sonra hâlâ "veri hazırlanıyor" aşamasında bulunur.
Kurulum öncesi hangi hazırlıklar yapılmalı?
Kuruluma başlamadan önce eldeki sistemin fotoğrafını çekmek gerekir. Pratikte şu dört envanter yeterlidir:
- Doküman envanteri: yürürlükteki prosedür, talimat ve form listesi; her birinin revizyon numarası ve sahibi. Bu liste madde 7.5.1 kapsamının da temelidir.
- Kayıt envanteri: hangi kayıt nerede tutuluyor, saklama süresi ne, kim erişiyor.
- Süreç sahipleri listesi: her modülün karşısında bir isim olmalı; boş kalan satır, kurulumda tıkanacak yer demektir.
- Ana veri listeleri: ekipman, tedarikçi, ürün, hata kodu, müşteri. Bunlar temizlenmeden hiçbir modül anlamlı çalışmaz.
Hata kodu listesi özellikle önemlidir. Birçok firmada aynı kusur üç farklı isimle kaydedilir: "çapak", "çapaklı", "kenar çapağı". Bu üçlü yazılıma olduğu gibi taşınırsa Pareto analizi ilk günden yanlış çıkar ve madde 9.1.1 izleme-ölçme verisi güvenilirliğini kaybeder.
Veri göçü nasıl planlanır?
Veri göçü kurulumun en çok küçümsenen adımıdır. İşleyen bir sıralama şudur:
- Ana verileri (ekipman, tedarikçi, ürün, doküman listesi) ayıkla ve tekilleştir.
- Her listeyi süreç sahibine imzalatarak dondur; göç sırasında liste değişmesin.
- Şablon dosyayla test yüklemesi yap, hata satırlarını düzelt.
- Hareket kayıtlarında sadece saklama süresi devam eden dönemi taşı.
- Yüklemeden sonra örnekleme ile doğrula: her listeden 20 satır elle karşılaştır.
- Eski dosyaları salt okunur arşive al; silme, kilitle.
Sondaki madde tartışma yaratır ama pazarlığa açık değildir. Madde 7.5.3.2 kayıtların korunmasını, okunabilir kalmasını ve istenmeyen değişikliğe karşı güvence altına alınmasını ister. Göç sırasında "nasıl olsa yenisine geçtik" diyerek eski klasörü silen firma, bir sonraki denetimde geçmiş dönemin kanıtını sunamaz.
Bir kalıp firmasında veri göçü iki kez yapıldı. Birincisinde ekipman listesi bilgi işlem tarafından "olduğu gibi" aktarıldı: 620 satırın 180'i hurdaya ayrılmış, 40'ı başka fabrikaya gitmiş cihazlardı. Yazılım ertesi gün 180 gecikmiş kalibrasyon uyarısı üretti, kalite ekibi uyarıları kapatamayınca bildirimleri kapattı. Temizlenmemiş veriyi taşımak, sistemi ilk haftasında güvenilmez hale getirir.
Pilot bölüm nasıl seçilir?
Tüm modülleri aynı gün açmak, hiçbir modülü düzgün açmamakla aynı sonucu verir. Pilot bölüm seçerken günlük veri üreten, süreç sahibi net ve ekibi işbirliğine açık bir alan arayın. Girdi kontrol ve nihai kontrol tipik olarak iyi adaylardır; ölçüm verisi düzenli akar, sonuç iki hafta içinde ölçülebilir.
| Faz | Tipik süre | Çıktı | İlgili madde |
|---|---|---|---|
| Hazırlık ve envanter | 1-2 hafta | Doküman ve ana veri listeleri | 7.5.1 |
| Kurulum ve yapılandırma | 1 hafta | Yetki matrisi, onay akışları | 5.3 |
| Veri göçü | 1-2 hafta | Doğrulanmış ana veri | 7.5.3 |
| Pilot ve paralel yürütme | 2-3 hafta | Canlı kayıt üreten bir bölüm | 9.1.1 |
| Yaygınlaştırma | 4-8 hafta | Tüm modüller devrede | 4.4 |
| Devreye alma değerlendirmesi | 1 hafta | YGG girdisi, açık madde listesi | 9.3.2 |
Paralel yürütmeyi iki-üç haftadan uzun tutmayın. Uzayan her hafta, ekibin eski forma geri dönme ihtimalini artırır. Geçiş sürecinin insan tarafını kalite yönetim yazılımına geçiş yazımızda ayrıntılı ele aldık.
Devreye alırken hangi ayarlar mutlaka yapılmalı?
Canlıya geçmeden önce kontrol edilmesi gereken ayarlar sanıldığından azdır ama hepsi kritiktir: kullanıcı rolleri ve yetki matrisi, doküman onay zinciri, revizyon numaralama kuralı, DÖF kapanış kriteri, kalibrasyon uyarı süresi, yedekleme takvimi ve bildirim alıcıları. Yetkilendirme özellikle dikkat ister; bir kalite yönetim sistemi yazılımı içinde herkesin her dokümanı yayınlayabildiği bir kurulum, madde 7.5.2 onay şartını fiilen ortadan kaldırır. Yedekleme ve erişim tarafını veri güvenliği ve yedekleme yazımızda derinleştirdik.
Kurulumun ikinci ayında ERP tarafına bakmak da işe yarar. Sipariş, parti ve ürün bilgisinin elle iki sisteme girildiği bir yapı uzun ömürlü olmaz; bu konuyu ERP ve MES entegrasyonu yazımızda anlattık.
Yeni sisteme geçmiş bir firmada denetçinin ilk sorduğu şey yazılımın markası değildir. "Geçiş tarihiniz ne, geçişten önceki kayıtlara nasıl ulaşıyorsunuz, aynı prosedürün iki sistemde iki farklı revizyonu var mı?" diye sorar. En sık görülen bulgu şudur: yazılıma yüklenen prosedür Rev.04, kalite panosunda asılı olan Rev.03. Madde 7.5.3.1 kullanım noktasında geçerli sürümün bulunmasını istediği için bu doğrudan uygunsuzluktur. Devreye alma günü tüm kâğıt kopyaları toplamak, kurulum planının bir maddesi olmalıdır.
Kurulumda en sık hangi hatalar yapılıyor?
Yıllar içinde tekrar eden birkaç hata var ve hepsi kurulumun ilk üç haftasında belirginleşiyor. En yaygını, kapsamı baştan çok geniş tutmaktır: on iki modülü aynı anda açan firma, üçüncü haftada hiçbir modülde düzgün veri üretemez. İkincisi, süreç sahibini belirlemeden yapılandırmaya başlamaktır; ekranlar bilgi işlemin anladığı gibi kurulur, sahada kimse tanımaz. Üçüncüsü, eski formu birebir ekrana kopyalamaktır. Kâğıt formda 38 alan varsa, bunların çoğu zaten yıllardır boş dolduruluyordur; hepsini zorunlu alan yapan kurulum ilk günden yavaş çalışır.
Dördüncü hata daha sinsi: yazılımı mevcut dağınık süreci hızlandırmak için kullanmak. Onay zinciri kâğıtta beş imzaysa ve bunların üçü işlevsizse, aynı beş imzayı dijitale taşımak yalnızca beklemeyi dijitalleştirir. Kurulum, süreci sadeleştirmek için doğal bir fırsattır; madde 4.4 süreçlerin ve etkileşimlerinin belirlenmesini isterken tam olarak bu gözden geçirmeyi kastediyor. Beşincisi ise klasik: ilk uygunsuzlukta sisteme değil eski yönteme dönmek. Bir hafta kâğıda dönen ekip, üç ay sonra hâlâ kâğıtta olur.
Kurulumun başarısı nasıl ölçülür?
"Yazılım kuruldu" cümlesi bir sonuç değildir. Devreye almanın gerçekten tuttuğunu üç göstergeden anlarsınız: sistemde açılan kayıt sayısının haftalık artışı, gecikmiş aksiyonların toplam aksiyona oranı ve modülü kullanan aktif kullanıcı yüzdesi. Bu üç rakam ilk ayın sonunda yatay bir çizgi çiziyorsa sorun yazılımda değil, kullanıcı alışkanlığındadır; o zaman eğitim ve kullanıcı adaptasyonu tarafını yeniden ele almak gerekir. Devreye alma raporunu ilk yönetimin gözden geçirmesi toplantısına girdi olarak sunmak, madde 9.3.2 açısından da işi kolaylaştırır.
Son bir uyarı: kurulumu bitmiş saymak için tüm açık maddelerin kapanmasını beklemeyin. Açık madde listesi sahipli ve terminliyse sistem canlıdır. Beklemek, geçişi tamamlamayan firmaların en sevdiği erteleme biçimidir.