Sözleşme imzalandıktan sonraki ilk toplantıda bilgi işlem sorumlusu tek bir şey istedi: "Bana sunucu gereksinim listesini yazılı verin, satın almaya açayım." Karşı taraftan gelen cevap iki cümleydi: "Standart bir sunucu yeterli, sanal makine de olur." O iki cümle yüzünden satın alma talebi açılamadı, bilgi işlem tahmin yürütmek istemedi, kalite ekibi bekledi ve proje daha ilk günü tamamlanmadan iki hafta kaybetti. QDMS kurulumu gibi şirket içi bir devreye almada zamanın nereye gittiğini soran herkese aynı şeyi söylüyorum: yazılımı sunucuya kurmak yarım gün sürer, geri kalan her şey hazırlıktır ve hazırlık yazılı olmadığında kimse başlayamaz.
Neden "standart sunucu yeter" cevabı işe yaramaz
QDMS kurulumu için sunucu talebi açan bilgi işlem üç rakama ihtiyaç duyar: işlemci çekirdek sayısı, bellek miktarı ve disk alanı. Bunlara ek olarak işletim sistemi sürümü, veritabanı sürümü ve lisans durumu sorulur. Bu altı bilgi olmadan hiçbir satın alma talebi onaya çıkmaz. Kalite tarafındaki proje sorumlusu bu listeyi tedarikçiden ilk hafta içinde yazılı almalı, alamıyorsa bunu bir risk olarak proje planına işlemelidir.
İkinci sıkıntı boyutlandırmanın kullanıcı sayısına göre yapılmasıdır. Oysa belirleyici olan toplam kullanıcı değil, aynı anda sistemde olan kullanıcı sayısıdır. Üç yüz kişilik bir fabrikada vardiya başında yirmi kişi iş talimatı açar, gün içinde kalite ekibinden on beş kişi kayıt girer. Eşzamanlı yük kırk civarındadır, üç yüz değil. Sunucuyu üç yüz kişiye göre almak parayı boşa harcamaktır; yirmi kişiye göre almak ise vardiya değişiminde sistemi dizüstüne çevirir.
Üçüncü olarak, sunucunun ne kadar süre hizmet vereceği baştan konuşulmalıdır. Bir QDMS kurulumu en az beş yıl ayakta kalacak bir yatırımdır; garantisi üç yıl sonra biten bir makineye kurmak, dördüncü yılda planlanmamış bir taşıma projesi yaratır. Sunucu satın alınırken beş yıllık destek paketi ve yedek parça temini de talebe yazılmalıdır.
Donanım, işletim sistemi ve veritabanı için gerçek rakamlar
Aşağıdaki tablo, otomotiv yan sanayide yaptığımız kurulumlarda kullandığımız boyutlandırma aralıklarıdır. Sanal makine de fiziksel sunucu da olur; asıl şart diskin SSD olması ve veritabanı ile dosya alanının ayrı bölümlerde tutulmasıdır.
| Eşzamanlı kullanıcı | İşlemci | Bellek | Disk (5 yıllık) | Yedek alanı |
|---|---|---|---|---|
| 10-25 | 4 çekirdek | 8 GB | 250 GB SSD | 500 GB |
| 25-50 | 4-6 çekirdek | 16 GB | 500 GB SSD | 1 TB |
| 50-100 | 8 çekirdek | 32 GB | 1 TB SSD | 2 TB |
| 100 üzeri | 8-12 çekirdek | 32-64 GB | 2 TB SSD + NAS | 4 TB |
Disk sütunundaki rakamlar veritabanı için değil, dosyalar içindir. Bir kalite sisteminde yer tüketen şey kayıtların kendisi değil eklerdir: taranmış PPAP dosyaları, ölçüm raporları, hatalı parça fotoğrafları, tedarikçi sertifikaları. Kullanıcı başına yılda 150 ile 300 MB arası bir birikim hesaplayın ve beş yıllık alanı baştan ayırın. Sonradan disk büyütmek mümkündür ama planlı kesinti gerektirir ve o kesintiyi kimse istemez.
Veritabanı tarafında dikkat edilecek tek bir teknik ayrıntı var: karakter seti. Veritabanı UTF-8 olarak kurulmazsa Türkçe karakterler sıralamada ve aramada tuhaf davranır; "İzmir" araması "izmir" yazan kaydı bulamaz. Bu hatayı kurulumdan sonra düzeltmek veritabanını yeniden oluşturmak demektir. Kurulum günü tek satırlık bir kontrol, altı ay sonraki bir göçü önler.
Sunucuyu fabrika içine koyarken tek soruyu unutmayın: bu makine nerede duruyor? Üretim sahasının yanındaki bir ofis dolabına konan sunucu, tozdan ve sıcaktan iki yıl içinde arıza verir. Kesintisiz güç kaynağına bağlı, havalandırılan, kilitli bir sistem odası şart. Bunu kurulum gününde değil, sunucu satın alınırken konuşun; sonradan taşımak yarım gün kesinti demektir.
Kurulum gününden önce hazır olması gereken beş liste
Bir QDMS kurulumu projesinde tedarikçi sunucuya bağlanmadan önce sizin tarafınızda beş listenin hazır olması gerekir. Organizasyon şeması bunların en kolayı gibi görünür ama alt birimlerin hangi üst birime bağlandığı yazılı değilse onay akışları kurulamaz. Kullanıcı listesi ad, soyad, sicil numarası, departman, unvan ve kurumsal e-posta içermelidir; eksik e-posta, ilk gün bildirim gönderemeyen bir sistem demektir. Doküman kodlama yapısı en çok tartışma çıkaran listedir: prosedür, talimat, form ve dış kaynaklı doküman için kod şeması ve numara aralığı önceden kararlaştırılmış olmalıdır. Geriye iki liste kalır; süreç listesi ve yürürlükteki doküman envanteri. İkisi de çoğu firmada zaten vardır, sadece güncellenmemiştir.
Bu listeler kurulum günü hazır değilse tedarikçi ekibi sahada bekler ve o gün fatura edilen danışmanlık saati boşa gider. Deneyimimize göre listelerin hazırlanması kalite ekibinden toplam üç ile beş iş günü ister; sözleşme imzalandığı gün bu iş bir kişiye görev olarak verilmelidir. Süreç listesini çıkarırken mevcut kalite el kitabınızdaki süreç haritasını kullanın, sıfırdan yazmayın. Sistem kurgusunun standartla nasıl hizalanacağı konusunda kalite yönetim sistemi sayfamızdaki çerçeve pratik bir kontrol listesi sunar.
Yedekleme planı kurulumdan önce yazılır
Kalite kayıtlarının saklanması bir tercih değil, yükümlülüktür. IATF 16949 madde 6.1.2.3 acil durum planlarını tanımlarken bilgi teknolojisi altyapısındaki arızayı da kapsama alır; yani sunucunuz çöktüğünde kalite kayıtlarına nasıl ulaşacağınızı önceden planlamış olmanız beklenir. Bu planın somut karşılığı üç şeydir: günlük tam yedek, yedeğin ikinci bir fiziksel konumda kopyası ve düzenli aralıklarla yapılan geri yükleme denemesi.
Üçüncüsü en çok atlanan maddedir. Yedek işi her gece yeşil ışık verir, kimse dosyayı açıp bakmaz, sonra gerçek bir arızada yedeğin altı aydır boş dosya ürettiği anlaşılır. Kurulum takvimine "geri yükleme testi" adında ayrı bir gün koyun. O gün yedek dosyasından ikinci bir sunucuya geri dönülür, birkaç doküman açılır, bir onay akışı denenir. Bu testi yılda en az bir kez tekrarlayın ve kaydını tutun; denetimde acil durum planının etkinliği sorulduğunda göstereceğiniz kanıt tam olarak budur.
Dört haftalık devreye alma takvimi
Aşağıdaki takvim, elli kişilik bir kalite ve üretim ekibi için gerçekleşen bir kurulumun sadeleştirilmiş hâlidir. Hafta içi tam gün çalışma varsayılmıştır; paralel yürüyen işler aynı satırda toplanmıştır.
| Hafta | Yapılan iş | Sorumlu | Çıktı |
|---|---|---|---|
| 1 | Sunucu temini, işletim sistemi, veritabanı, yazılım kurulumu, yedek işi | Bilgi işlem | Çalışan test ortamı |
| 2 | Organizasyon şeması, rol matrisi, doküman kodlama yapısı, onay akışları | Kalite + bilgi işlem | İmzalı yetki matrisi |
| 3 | Yürürlükteki dokümanların aktarımı, tedarikçi ve ekipman listeleri | Kalite ekibi | Göç kontrol listesi |
| 4 | Pilot grup eğitimi, iki hattaki gerçek kullanım, geri yükleme testi | Tüm ekip | Canlıya geçiş onayı |
Bu takvimin en kritik satırı ikinci haftadır. Rol matrisi ve doküman kodlama yapısı orada bitmezse üçüncü haftadaki veri göçü başlayamaz, çünkü dosyaların hangi kategoriye ve hangi koda gireceği belli olmaz. Yetki tarafını nasıl kuracağınızı rol yönetimi yazımızda adım adım anlattık; kodlama yapısı için de doküman yönetimi sayfasındaki çerçeveden yararlanabilirsiniz.
Yeni bir sisteme geçen firmada denetçinin ilk sorduğu şey yazılımın markası değildir; geçiş tarihinden önceki kayıtlara nasıl ulaşıldığıdır. Eski sistem kapatılmışsa ve kayıtlar bir dış diske atılmışsa, o diskin nerede durduğu ve kimin eriştiği sorulur. Geçiş planınızda "eski kayıtların erişimi" başlıklı tek bir paragraf, bu konuşmayı beş dakikada bitirir.
Veri göçünde neyi taşıyacağınıza karar verin
Bir QDMS kurulumu projesinin en çok uzayan adımı veri göçüdür ve uzamasının sebebi teknik değil, karar eksikliğidir. "Elimizdeki her şeyi aktaralım" denildiğinde ortaya yürürlükten kalkmış yüzlerce dosya çıkar ve kimse hangisinin geçerli olduğunu bilemez. Doğru yaklaşım nettir: yalnızca yürürlükteki güncel sürümler yeni sisteme taşınır. Geçmiş revizyonlar eski konumda okunabilir kalır, erişim yolu prosedüre yazılır ve kimin erişeceği belirlenir.
Göç sırasında en çok zaman alan iş dosya taşımak değil, her dokümana doğru sahip ve doğru onaycı atamaktır. Beş yüz dokümanlık bir envanterde bu atama elle yapıldığında iki hafta sürer. Bunu hızlandırmanın yolu, göç dosyasını Excel'de hazırlayıp doküman kodu, kategori, süreç sahibi ve onaycı sütunlarını tek seferde doldurmak, ardından toplu içe aktarmaktır. Tedarikçinizin toplu içe aktarma şablonunu ilk hafta isteyin; şablon geç geldiğinde üçüncü hafta kayar ve takvimin tamamı bir hafta arkaya düşer.
Göçe başlamadan önce bir kontrol listesi çıkarın: kaç prosedür, kaç talimat, kaç form, kaç dış kaynaklı doküman var. Bu sayıları göç bittikten sonra sistemdeki sayılarla karşılaştırın. İki liste tutmuyorsa fark nereden geliyor, bulun. Sayısal doğrulama yapılmayan bir göçte eksik kalan dosyalar aylar sonra, o dokümana ihtiyaç duyulduğu anda ortaya çıkar. Ekipman ve kalibrasyon verisi taşınıyorsa aynı doğrulamayı orada da yapın; kalibrasyon tarihleri yanlış aktarıldığında bir sonraki kalibrasyon planı komple kayar.
Pilot kullanım ve canlıya geçiş
Dördüncü hafta pilot içindir ve pilotu bütün fabrikayla değil, iki hat ile yapın. Pilot grubu seçerken bir tuzağa dikkat edin: en istekli kullanıcıları seçerseniz sistem mükemmel çalışıyor gibi görünür. Gruba en az bir şüpheci kullanıcı koyun; sorunları o bulur. Pilot boyunca her sorunu bir listeye yazın, listeyi hafta sonunda tedarikçiyle kapatın ve kapanmayan maddeleri canlıya geçiş kararında gündeme getirin.
Canlıya geçiş bir tarih değil, bir karardır. O kararı verirken üç şeye bakın: yedek geri yükleme testi başarılı mı, yürürlükteki dokümanların tamamı sistemde mi, kullanıcıların en az yüzde sekseni giriş yapıp bir işlem tamamladı mı. Üçü de olumluysa eski sistemi salt okunur hâle getirip yeni sisteme geçin. Paralel kullanım süresini iki haftadan uzun tutmayın; iki sistemin aynı anda güncel kalması imkânsızdır ve bir noktada iki farklı sürüm dolaşmaya başlar.
Kurulum modelini seçerken
Şirket içi kurulumun kazandırdığı şey kontroldür: veri sizin sunucunuzda durur, internet kesildiğinde kalite kayıtlarına erişim devam eder, sürüm geçişinin zamanını siz seçersiniz. Karşılığında sunucunun bakımı, yedeği ve güncellemesi sizin sorumluluğunuzdadır. Bu dengeyi ayrıntılı tarttığımız bulut mu sunucu mu yazısı, karar aşamasındaki bir ekip için iyi bir kontrol listesi sunar. PaKalite'yi şirket içi kuruluma göre tasarlamamızın sebebi de bu tercihin otomotiv tedarikçilerinde hâlâ ağır basması; on sekiz modül aynı veritabanında çalıştığı için kurulum tek seferde biter ve modül eklemek yeni bir kurulum gerektirmez. Hangi çözümü seçerseniz seçin, ilk hafta yazılı bir gereksinim listesi almadan satın almaya çıkmayın.