Tedarikçi denetiminin öğleden sonraki oturumunda OEM temsilcisi soru listesinin sonuna geliyor: "Kalite kayıtlarınız hangi ülkedeki sunucuda tutuluyor, erişim yetkisi kimlerde?" Odada sessizlik. Kalite müdürü bilgi işlemi arıyor, bilgi işlem yazılım firmasını arıyor, cevap ertesi güne kalıyor. O gün kaybedilen şey bir soru değil, güven. Bulut QMS mi şirket içi QMS mi kararı tam olarak bu tek sorunun etrafında dönüyor; gerisi internet, yedekleme ve maliyet ayrıntısı. Aşağıda dördünü de tek tek açıyoruz.
Baştan söyleyeyim: bulut QMS mi şirket içi QMS mi sorusunun evrensel bir doğru cevabı yok. Aynı sektörde, aynı büyüklükte iki firmada iki farklı model doğru çıkabiliyor. Belirleyici olan üç şey: müşterinizin sözleşmesinde ne yazdığı, bilgi işlem kapasiteniz ve kullanıcı sayınız. Yazının sonunda bu üçünü bir arada değerlendirebileceğiniz bir eşik var; ama önce sorunun neden bu kadar sık gündeme geldiğine bakalım.
Sunucu yeri sorusu neden geliyor
Bu soruyu soran müşteri, standardın bir maddesinden hareket etmiyor. IATF 16949 sunucu konumu için bir şart koymaz. Sorunun kaynağı gizlilik sözleşmeleri ve müşteri özel şartlarıdır. Size verilen çizimler, özel karakteristik listeleri, proses parametreleri ve PPAP dosyaları müşteri mülkiyetindeki bilgidir; ISO 9001 madde 8.5.3 müşteriye ait mülkiyetin korunmasını, bakımının yapılmasını ve kaybolması hâlinde müşteriye bildirilmesini ister. Bu maddenin dijital karşılığı, verinin nerede ve kimin erişimiyle durduğunu bilmektir.
İkinci kaynak kişisel veri mevzuatı. Kalite kayıtlarının çoğu kişisel veri içermez ama eğitim ve yetkinlik kayıtları çalışan bilgisidir. Bu kayıtlar yurt dışındaki bir sunucuda tutuluyorsa aktarım için ayrı bir hukuki dayanak gerekir. Karar aşamasında hukuk ya da uyum biriminizi masaya çağırın; sonradan taşımak, sözleşme yenilerken pazarlık gücünüzü düşürüyor.
İki modelin teknik farkı
Bulut modelinde yazılım sağlayıcının altyapısında çalışır, siz tarayıcıdan bağlanırsınız. Sunucu bakımı, güncelleme ve yedekleme sağlayıcının işidir; karşılığında genelde kullanıcı başına aylık ya da yıllık ücret ödersiniz. Şirket içi kurulumda (on premise) yazılım kendi sunucunuza kurulur, veri bina içindeki diskte durur ve bakım sizin sorumluluğunuzdadır. Üçüncü bir yol da var: bulut sağlayıcıda kiralanan ama size ait bir sunucuda kurulum, yani barındırmanın dışarıda olduğu ama verinin sizin kontrolünüzde kaldığı model.
"Hangisi daha modern" tartışmasına hiç girmeyin. İkisi de sahada yıllardır çalışıyor. Fark, sorumluluğun ve riskin nerede durduğunda.
Üçüncü modeli fazladan bir dipnot sanmayın; otomotiv tedarikçilerinde gittikçe daha sık tercih ediliyor. Sunucu bir veri merkezinde kiralanır, işletim sistemi ve veritabanı sizin yönetiminizdedir, yazılım sağlayıcı yalnızca uygulamaya dokunur. Böylece hem bina içindeki donanım riskinden kurtulursunuz hem de "veri kimin kontrolünde" sorusuna net cevap verirsiniz. Karşılığında bir sistem yöneticisine ihtiyacınız devam eder; bu modeli seçenlerin en sık yaptığı hata, sorumluluğun tamamen dışarı geçtiğini varsayıp yedekleme ve güncelleme takibini kimseye zimmetlememektir.
Başlık başlık karşılaştırma
| Başlık | Bulut QMS | Şirket içi QMS |
|---|---|---|
| Veri konumu | Sağlayıcının veri merkezi, sözleşmede belirtilir | Kendi sunucunuz, konum sizde |
| Müşteri denetimi cevabı | Sağlayıcı belgesi gerekir | Tek cümlede verilir |
| İnternet kesintisi | Erişim durur | Yerel ağdan çalışmaya devam eder |
| Yedekleme sorumluluğu | Sağlayıcı, sözleşme sınırlarında | Firma, tamamen |
| Güncelleme | Otomatik, zamanlaması sağlayıcıda | Planlı, zamanlaması sizde |
| Kurulum yükü | Düşük, birkaç gün | Sunucu hazırlığı gerekir |
| Maliyet yapısı | Sürekli abonelik, kullanıcıya bağlı | Öne yüklü, sonra sabit |
| Sözleşme bitince veri | Dışa aktarım koşulu sözleşmeye yazılmalı | Zaten sizde |
Bu tablonun en sonundaki satır, çoğu firmanın sözleşme imzalarken okumadığı satır. Aboneliği sonlandırdığınızda verinizin hangi formatta, ne kadar süre içinde ve hangi bedelle verileceğini imzadan önce yazdırın. Kalite kayıtları için saklama süreleri yıllarla ölçülür; IATF 16949 madde 7.5.3.2.1 saklama sürelerinin tanımlanmasını ister ve otomotiv müşterileri bu süreyi üretim ömrünün ötesine taşır.
Denetim öncesi hazırlığınıza tek satır ekleyin: "Kalite kayıtları X ülkesinde, Y sağlayıcısının veri merkezinde tutulur; erişim yetkisi şu üç rolde; yedek sıklığı şu." Bu cümleyi bir A4'e yazıp kalite el kitabının ekine koyun. Denetimde bu soruya üç saniyede cevap veren firma ile ertesi güne bırakan firma arasındaki fark, denetçinin geri kalan sorularının tonuna yansıyor.
İnternet kesintisi gerçek bir risk mi
Organize sanayi bölgelerinin çoğunda tek fiber hat var ve yılda birkaç kez kesinti yaşanıyor. Bulut modelinde bu, sistemin durması demek. Kalite açısından somut sonucu şu: operatör güncel iş talimatına ulaşamaz, vardiya amiri uygunsuzluk kaydı açamaz, sevkiyat onayı verilemez. Sekiz saatlik bir kesinti, üretim planını ve müşteri sevkiyatını etkileyebilir.
Bu riski yönetmenin yolu var: ikinci bir internet hattı, kesinti anında ne yapılacağını tarif eden yazılı bir talimat ve kritik dokümanların hat başında yerel kopyası. Şirket içi kurulumda ise risk yerel ağa ve sunucu donanımına kayar; internet kesilse bile sistem fabrika içinde çalışmaya devam eder, ama sunucu arızalanırsa müdahale sizin ekibinizden beklenir. Her iki modelde de acil durum planınızı yazın; IATF 16949 madde 6.1.2.3 acil durum planlarını bilgi teknolojisi altyapısındaki kesintileri de kapsayacak şekilde isteyen bir maddedir.
Yedekleme kimin işi
Bulut modelinde yedekleme sağlayıcının işidir ama sınırsız değildir. Sözleşmede üç sayıyı arayın: yedek alma sıklığı, yedeklerin saklanma süresi ve felaket durumunda geri dönüş süresi. Bu üç sayı yazmıyorsa sözleşme eksiktir. Şirket içi kurulumda sorumluluk tamamen sizdedir ve en sık yapılan hata, yedeğin alındığını varsayıp hiç denememektir.
Her iki modelde de yılda bir kez geri dönüş provası yapın: yedeği ayrı bir makineye açın, üç kaydı kontrol edin ve sonucu bir tutanağa bağlayın. Bu tutanak denetimde de işe yarıyor. Denenmemiş yedek yedek değildir; bunu bir kez, cuma akşamı diski bozulan bir firmada çok pahalı öğrendik.
Denetçi kurulum modelini sorgulamaz, kaydın korunmasını sorgular. Sorular şunlar: bu kayıt bozulursa nereden geri getirirsiniz, en son ne zaman denediniz, kimlerin silme yetkisi var. Üç sorunun cevabı da yazılı olmalı. Bulut kullanan bir firmada bu cevap sağlayıcının hizmet sözleşmesinden, şirket içi kurulumda kendi yedekleme talimatınızdan çıkar.
Güncelleme kimin takvimine göre yapılır
Az konuşulan ama sahada canı yakan başlık bu. Bulut modelinde yazılım güncellemesi sağlayıcının takvimine göre gelir ve genelde haber verilerek yapılır. Sorun, ekranın bir sabah değişmesi ve o gün yüz kişinin alışkanlığının bozulmasıdır. Bir müşteri şikâyetine cevap yetiştirmeye çalıştığınız gün menü yeri değişmişse, bunun bedelini kalite bölümü öder. Şirket içi kurulumda güncellemeyi siz planlarsınız; hafta sonuna alır, önce test ortamında dener, sonra sahaya verirsiniz.
Buna karşılık şirket içi modelin riski, güncellemeyi hiç yapmamaktır. İki yıl geride kalmış bir sürümle çalışan firmalar gördüm; gerekçe hep aynıydı, "çalışıyor, dokunmayalım". Sonra bir hata çıktığında düzeltmenin yolu üç sürüm birden atlamaktan geçiyor ve bu da riskli oluyor. Kurulum modeli ne olursa olsun, yılda en az bir planlı güncelleme penceresi tanımlayın ve bunu bakım takvimine yazın. Bulut QMS mi şirket içi QMS mi tercihini yaparken şunu dürüstçe sorun: güncelleme kontrolünün sizde olması size gerçekten değer katıyor mu? Bu kontrolü kullanmayacaksanız avantaj değildir.
Erişim, mobil kullanım ve saha
Bulut modelinin en gerçek avantajı erişimdir. Evden, müşteri fabrikasından ya da telefondan sisteme girmek altyapı işi olmaktan çıkar. Kalite müdürünün müşteri toplantısındayken bir 8D kaydına bakabilmesi, tedarikçi denetimindeyken soru listesini açabilmesi somut kazançtır. Şirket içi kurulumda aynı erişimi sağlamak mümkün ama bir VPN kurgusu ve bunu yönetecek biri gerekir.
Saha tarafında tablo tersine dönüyor. Hattaki terminaller ve tabletler zaten fabrika ağındadır; yerel sunucuya bağlanmak hem hızlı hem kesintisizdir. Yüz kişilik bir tesiste günlük kayıtların büyük bölümü fabrika içinden giriliyorsa, dışarıdan erişim ihtiyacı birkaç kişiyle sınırlı kalır. Kendi dağılımınıza bakın: kaç kullanıcı bina içinde, kaçı dışarıda? Bu iki sayı, kurulum modeli kararına maliyet tablosundan daha net yön veriyor.
Beş yıllık maliyeti doğru kurmak
Karşılaştırmayı ilk yıl üzerinden yapmayın; bulut modelinin başlangıç maliyeti düşük göründüğü için tablo yanıltır. Beş yıllık hesaba şu kalemleri koyun: abonelik ya da lisans bedeli, sunucu ve depolama, yedekleme çözümü, sistem yöneticisinin zamanı, güncelleme ve destek, kullanıcı sayısı artışının etkisi. Son kalem kritik: bulut modelinde kullanıcı başına ücretlendirme varsa, sahaya yaydıkça maliyet doğrusal artar ve bu da firmaları kullanıcı sayısını kısmaya iter. Kullanıcıyı kısmak ise sistemin benimsenmesini doğrudan baltalar.
Şirket içi kurulumda ilk yıl daha ağırdır; sunucu, kurulum ve sistem yöneticisi zamanı öne yüklenir. Sonraki yıllarda kalemler sabitlenir. Hesabı yaparken kendi kullanıcı sayınızı ve beş yıllık büyüme tahmininizi tabloya koyun. PaKalite'yi şirket içi kurulum üzerine kurmamızın nedeni bu iki başlıktı: kayıtların bina içinde kalması ve kullanıcı sayısının maliyeti belirlememesi. Her firma için doğru tercih bu değil; kendi altyapınıza ve bilgi işlem kapasitenize bakın.
Çıkış maliyeti: sözleşme biterse veri hangi formatta geliyor?
İki modeli karşılaştırırken en az konuşulan kalem, sistemden çıkma maliyetidir. Girişte herkes veri göçünü konuşur, çıkışta ne olacağını kimse sormaz. Oysa beş yıl sonra tedarikçi değiştirmek isterseniz elinizde kalacak şey, sözleşmeye o gün yazdığınız cümleyle sınırlıdır.
Şirket içi kurulumda veritabanı sizin sunucunuzdadır; kötü senaryoda bile ham tabloları dökebilirsiniz. Bulutta ise veriyi alma hakkı sözleşmeden gelir. Teklif aşamasında şu üç şeyi yazılı isteyin: verinin hangi formatta teslim edileceği (ham tablo dökümü mü, yoksa yalnızca ekrandan alınan Excel çıktısı mı), dosya eklerinin ve onay geçmişinin bu teslimata dahil olup olmadığı, ve teslim süresi. En kritik ayrım ikincisidir. Bir doküman kaydının değeri metninde değil, revizyon tarihçesinde, kimin ne zaman onayladığında ve okundu kaydındadır. Sadece güncel dosyaları PDF olarak veren bir çıkış paketi, bir denetimde geçmişe dönük kanıt üretmenizi imkânsız kılar.
Şirket içi kurulumun burada bir bedeli olduğunu da not edin: veri sizde durur ama onu okunabilir tutmak da sizde kalır. Yazılımın desteği bittiğinde elinizde çalışmayan bir uygulamanın veritabanı kalır. Bu yüzden hangi modeli seçerseniz seçin, yılda bir kez tam veri dökümü alıp ayrı bir ortamda saklamak iki tarafta da geçerli bir alışkanlıktır.
Müşteri gizlilik sözleşmesi hangi modeli zorunlu kılıyor?
Otomotiv ve savunma tedarik zincirinde imzaladığınız gizlilik sözleşmelerinde çoğu zaman "teknik verinin ülke dışına çıkarılmaması" ya da "üçüncü taraf sistemlerde saklanmaması" yönünde bir madde bulunur. Bu maddeyi kalite ekibi genelde okumaz, çünkü sözleşme satın alma tarafında imzalanmıştır. Ama kapsamı sandığınızdan geniştir.
Kalite sisteminde tuttuğunuz kayıtların önemli bir kısmı bu tanıma girer: teknik resimler ve revizyonları, kontrol planları, ölçüm sonuçları, PPAP dosyaları, müşteriye özel proses parametreleri. Bunlar yurt dışındaki bir veri merkezinde duruyorsa, sözleşmeye göre ihlal sayılabilecek bir durum vardır. Denetimde bu genelde doğrudan sorulmaz; "kalite kayıtları nerede tutuluyor" sorusunun ardından gelir.
Pratik yol şu: sözleşmelerinizde böyle bir madde varsa, tedarikçiye sunucunun bulunduğu ülkeyi ve varsa alt yüklenici zincirini yazılı sorun. Birçok bulut hizmeti kendi altyapısını başka bir sağlayıcıdan kiralar; veri sizin bildiğiniz firmada değil, onun tedarikçisinde durabilir. Yurt içinde barındırılan bir bulut kurulumu ya da kendi sunucunuzdaki bir kurulum, bu maddeyi karşılamanın iki geçerli yoludur, ama hangisi olursa olsun, sunucunun yerini belgeleyen bir yazıyı denetim dosyanızda hazır bulundurun.
Hangi model kime uygun
Kararı üç soruya indirgeyin. Müşteri sözleşmelerinizde veri konumu ya da erişim kısıtına dair bir madde var mı? Sunucuyu ayakta tutacak, yedeğini alıp deneyecek bir kişiniz var mı? Beş yıl sonra kaç kullanıcınız olacak? İlk soruya evet, ikinciye evet diyorsanız şirket içi kurulum rahat çalışır. İlk soruya hayır, ikinciye hayır diyorsanız bulut modeli sizi daha az yorar. Karışık cevaplarda ise üçüncü soru belirleyici oluyor; kullanıcı sayısı büyüdükçe bulut QMS mi şirket içi QMS mi hesabı ikinci modelin lehine dönüyor.
Bilgi işlem kadrosu olmayan, tek tesisli, kullanıcı sayısı düşük ve müşterisi veri konumu sorusunu sormayan bir işletmede bulut modeli işi kolaylaştırır. Çok kullanıcılı, OEM denetimine giren, gizlilik sözleşmesi ağır ve internet altyapısı zayıf bir tedarikçide ise şirket içi kurulum daha rahat bir zemin verir. Çok tesisli yapılarda karma model çalışıyor: merkezde barındırma, sahada yerel erişim.
Kararı bir kez verip rafa kaldırmayın. Kullanıcı sayısı, müşteri portföyü ve bilgi işlem kadrosu üç yılda değişir; bugün doğru olan model üç yıl sonra pahalı ya da hantal kalabilir. Sözleşmeyi yenilerken aynı üç soruyu yeniden sorun ve cevapları önceki yanıtlarla yan yana koyun. Bir de model değiştirmenin ne kadar süreceğini baştan öğrenin: verinin dışa aktarım formatı, kullanıcı ve yetki tanımlarının taşınıp taşınamayacağı, geçiş sırasında sistemin kaç gün durmak zorunda kalacağı. Bu üç cevabı bilmeyen bir firma, model değiştirme kararını teknik gerekçelerle değil, korkuyla erteliyor.
Yazılımın kendisini de gözden kaçırmayın; kurulum modeli doğru olsa bile arayüz ve destek tarafı zayıfsa sistem tutmaz. Bu tarafı yerli QMS mi yabancı QMS mi yazısında ayrıca tartıştık. Modül kapsamını karşılaştırmak için kalite yönetim sistemi yazılımı sayfasına, müşteri denetimlerinde sorulan diğer başlıklar için tedarikçi yönetimi ve denetim sayfalarına bakabilirsiniz. Nihayetinde bulut QMS mi şirket içi QMS mi sorusunun tek doğru cevabı yok; doğru olan, cevabı denetim gününden önce yazılı hâlde bulundurmak.