Müşteri denetiminin ikinci gününde OEM'in tedarikçi kalite mühendisi doküman ekranına bakarken durdu: "Bu çizimler ve kontrol planları hangi ülkedeki sunucuda duruyor?" Kalite müdürü IT sorumlusuna baktı, IT sorumlusu "sağlayıcının bulutunda" dedi. Denetçi not aldı, arkasından veri merkezinin konumunu, erişim kayıtlarını ve alt yüklenici listesini istedi. O gün kimse hazır değildi. On premise mi bulut mu kalite yazılımı sorusu böyle anlarda teknik bir tercih olmaktan çıkar, müşteri ilişkisinin parçası hâline gelir. Aşağıda iki modeli beş eksende karşılaştırıp hangi profildeki firmanın hangisini seçmesi gerektiğini net söylüyoruz.
İki modelin gerçek tanımı
Şirket içi kurulumda (on-premise) yazılım sizin sunucunuzda çalışır, veri tabanı sizin disklerinizde durur, yedeği siz alırsınız. Bulut modelinde yazılım sağlayıcının ya da bir bulut operatörünün altyapısında çalışır, siz tarayıcıdan bağlanırsınız, yedekleme ve güncelleme sağlayıcının sorumluluğundadır. Aradaki fark bir kutu meselesi değil, sorumluluk ve kontrol paylaşımıdır.
Piyasada üçüncü bir seçenek de var: özel bulut, yani sağlayıcının sizin adınıza ayrılmış bir sunucuda çalıştırdığı kurulum. Bu model şirket içi kurulumun kontrolünü değil, bulutun rahatlığını verir; verinin fiziksel konumu ve erişim yetkileri hâlâ sağlayıcıdadır. Teklif alırken "özel bulut" ifadesini duyduğunuzda tek soru şudur: veri tabanı yedeğini istediğim anda kendi diskime indirebiliyor muyum?
On premise mi bulut mu kalite yazılımı tartışmasını sağlıklı yürütmenin ön şartı, kararı IT'ye tek başına bırakmamaktır. IT doğal olarak işletme yüküne bakar ve bulutu tercih eder; kalite ise kayıtların denetimde nerede durduğuna bakar. Doğru karar bu iki bakışın kesişme noktasındadır ve masada satın alma da olmalıdır, çünkü çıkış maliyeti ve sözleşme maddeleri onun işidir. Üç bölümün ortak imzaladığı bir karar, üç yıl sonra kimsenin savunmadığı bir karar olmaktan kurtulur.
Eksen 1: Veri sahipliği ve verinin konumu
Kalite sistemindeki veri, sıradan bir kurumsal veri değildir. İçinde müşteri çizimleri, kontrol planları, özel karakteristik listeleri, tedarikçi fiyat performansı ve personel yetkinlik kayıtları vardır. Bunların bir kısmı müşterinin fikri mülkiyetidir, bir kısmı kişisel veridir. IATF 16949 madde 7.5.3.2.1 kayıtların saklanma sürelerini ve korunmasını şart koşar; kaydı nerede tuttuğunuzu değil, ona istendiğinde erişebildiğinizi ve koruduğunuzu sorar. Ama müşterinin özel şartları çoğu zaman daha ileri gider ve konumu da sorgular.
Kişisel veri tarafı ayrı bir başlıktır. Eğitim kayıtları, yetkinlik değerlendirmeleri ve operatör performans verileri KVKK kapsamına girer; sunucu yurt dışındaysa yurt dışına veri aktarımı kuralları devreye girer. Bu konuyu ayrıntılı olarak QDMS ve KVKK yazısında ele aldık. Karar verirken şu soruyu yanıtlayın: bir denetimde verinin fiziksel konumunu ve ona kimlerin eriştiğini belgeleyebiliyor muyuz?
Eksen 2: Erişim, kesinti ve hız
Bulut modelinin en görünür riski internet bağımlılığıdır. Hat kesildiğinde doküman onayı durur, uygunsuzluk kaydı açılamaz, sevkiyat serbest bırakma bekler. Organize sanayi bölgelerinin çoğunda hat kalitesi iyidir ama tek hatla çalışan bir fabrikada yılda birkaç kez saatlerce kesinti yaşanır. Yedek hat maliyetini bulut modelinin bedeline eklemeniz gerekir; aksi hâlde karşılaştırma eksik kalır.
Hız tarafında ise fark, dosya boyutunda ortaya çıkar. Doküman ve DÖF kayıtları küçüktür, bulut üzerinden rahat çalışır. Ama üretim hattındaki bir terminalden 40 MB'lık bir müşteri çizimini ya da bir ölçüm cihazından toplu veri setini her açışta indiriyorsanız, yerel ağ üzerinde çalışan bir kurulum belirgin biçimde hızlıdır. Kendi kullanım profilinizi bilmeden bu ekseni değerlendiremezsiniz.
Ölçmek için basit bir yöntem var: bir hafta boyunca kalite bölümünün açtığı dosyaların boyutunu ve sayısını not edin. Toplam günlük trafik birkaç yüz megabaytın altındaysa bağlantı hızı tartışma konusu değildir. Üretim tarafındaki terminaller de çizim görüntülüyorsa rakam hızla büyür ve o zaman yerel ağ avantajı somutlaşır. Tahminle yürütülen bu tartışma her toplantıda yeniden başlar; bir haftalık ölçüm tartışmayı kapatır.
Şirket içi kurulum seçen firmaların yaptığı en sık hata, sunucuyu kurup yedeklemeyi işin sonuna bırakmaktır. "Otomatik yedek alınıyor" cümlesinin tek geçerli kanıtı, bir geri yükleme tatbikatıdır. Altı ayda bir, yedeği boş bir makineye geri yükleyin ve sistemin açıldığını görün. Yedeği hiç denenmemiş bir firmada disk arızası yaşandığında kaybedilen şey yazılım değil, beş yıllık kalite kaydıdır.
Eksen 3: Güncelleme kontrolü
Bulutta güncelleme sağlayıcının takvimiyle gelir. Bu bir kolaylıktır: yeni sürüm için kimseyi beklemezsiniz, IT işi yoktur. Ama aynı özellik, bir sabah geldiğinizde ekranın değişmiş olması ve kırk kullanıcının "buton nereye gitti" diye sormasıdır. Doğrulanmış süreçleri olan medikal ve savunma firmalarında bu durum ciddi bir sorundur; her sürüm değişikliğinin etkisini değerlendirmeniz gerekir.
Şirket içi kurulumda güncellemeyi ne zaman alacağınıza siz karar verirsiniz. Denetimden bir hafta önce sürüm yükseltmeyi ertelersiniz, yıl sonu kapanışında sisteme dokunmazsınız. Bunun bedeli, güncellemeyi kimsenin başlatmaması ve sistemin yıllarca eski sürümde kalmasıdır. İki modelin de bu eksende kendi riski var; hangisinin sizin için daha yönetilebilir olduğuna bakın.
Pratik bir orta yol var: bulut kullanıyorsanız sağlayıcıdan sürüm notlarını en az iki hafta önceden yazılı isteyin ve değişikliği önce test ortamında görün. Şirket içi kurulumda ise güncellemeyi takvime bağlayın; yılda bir sabit ay belirleyin ve o ayı denetim takviminden uzak tutun. İki modelde de riski yöneten şey, güncellemenin sürpriz olmaktan çıkmasıdır.
Bir de doğrulama yükü var. Medikal ve savunma tarafında yazılım sürümü değiştiğinde etkilenen süreçlerin yeniden değerlendirilmesi beklenir. Yılda dört kez otomatik güncelleme alan bir sistemde bu, yılda dört kez yapılacak bir değerlendirme demektir. Şirket içi kurulumda güncellemeyi yılda bir kez planlı olarak aldığınızda aynı iş bir kereye iner. Bu, on premise mi bulut mu kalite yazılımı kararında düzenlemeye tabi sektörler için tek başına belirleyici olabilecek bir kalemdir.
Eksen 4: Çıkış maliyeti
Beş yıl sonra sistemi değiştirmek istediğinizde ne olacağı, satın alma anında hiç konuşulmayan konudur. Şirket içi kurulumda veri tabanı sizin sunucunuzdadır; yedeği alır, yeni sisteme aktarırsınız. Bulut modelinde ise verinin size hangi formatta, hangi sürede ve hangi bedelle teslim edileceği sözleşmede yazmıyorsa, bu konu fesih anında pazarlık masasına düşer. Dosya ekleri ve iz kayıtları çoğu zaman dışa aktarımın kapsamı dışında kalır ve asıl sıkıntı orada çıkar.
Sözleşmeye şu cümleyi koydurun: fesih hâlinde tüm veri, dosya ekleri ve iz kayıtları ham veri tabanı yedeği olarak otuz gün içinde ücretsiz teslim edilir. Bu tek cümle, beş yıl sonraki pazarlık gücünüzü belirler.
Çıkış maliyetinin ikinci bileşeni veri değil, alışkanlıktır. Beş yıl kullanılmış bir sistemde ekip kendi çalışma biçimini o ekranlara göre kurmuştur; taşınma kararı verildiğinde asıl direnç teknik değil, insanidir. Bu yüzden ilk seçimde "gerekirse değiştiririz" varsayımına güvenmeyin. Uygulamada firmalar sistemi değiştirmez, katlanır. Kararı da bu gerçeğe göre verin.
Eksen 5: Beş yıllık bedel
Maliyet karşılaştırması genellikle yanlış yapılır: bulutun aylık bedeli ile şirket içi kurulumun lisans bedeli yan yana konur, sunucu ve IT tarafı unutulur. Doğru karşılaştırma beş yıllık kümülatif toplam üzerinden yapılır ve her iki tarafın kendi gizli kalemleri hesaba girer. Kalem listesinin tamamını TCO hesabı yazısındaki tablodan alabilirsiniz.
| Eksen | Şirket içi (on-premise) | Bulut |
|---|---|---|
| Veri sahipliği ve konum | Veri sizin sunucunuzda; konum belgelenebilir | Sağlayıcının altyapısında; konum sözleşmeye bağlı |
| İnternet kesintisi | Yerel ağ ayaktaysa sistem çalışır | Erişim durur, kayıt açılamaz |
| Güncelleme kontrolü | Zamanlama sizde; erteleme riski var | Otomatik gelir; sürprize açık |
| Çıkış maliyeti | Yedeği alırsınız, ek bedel yok | Sözleşmeye bağlı; format ve süre riski |
| Sunucu ve IT yükü | Donanım, yedekleme ve bakım sizde | Sağlayıcıda; IT yükü düşük |
| Beş yıllık bedel yapısı | Önden ağır, sonra düşük | Sabit ve tekrarlayan; kullanıcıyla artar |
| Uzak erişim ve çok tesis | VPN gerektirir | Doğrudan çalışır |
Hangi profildeki firma hangisini seçmeli?
Kararı netleştirelim. Otomotiv, savunma ve havacılık tedarikçisiyseniz, müşteri çizimlerini ve kontrol planlarını sistemde tutuyorsanız, tek yerleşkede çalışıyorsanız ve kendi sunucunuz zaten varsa şirket içi kurulum doğru tercihtir. Müşteri denetiminde veri konumu sorusuna tek cümlede cevap verirsiniz ve çıkış maliyetiniz sıfırdır. IT ekibiniz yoksa bile, doğru kurulmuş bir sistemin bakım yükü ayda birkaç saattir.
Buna karşılık üç farklı şehirde tesisi olan, sahada çalışan denetçileri bulunan ve IT tarafında hiç kaynak ayırmak istemeyen bir firma için bulut daha rahattır. Küçük ölçekli, yirmi kullanıcının altındaki firmalarda da bulutun işletme kolaylığı ağır basar. Kararı verirken belirleyici soru şudur: verinizin fiziksel konumu bir müşteri şartı mı, yoksa sadece bir tercih mi? Şart ise tartışma biter.
PaKalite'yi şirket içi kurulum üzerine kurmamızın nedeni bu profildir: otomotiv ve metal sektöründe müşteri verisi taşıyan firmalar için kontrolün fabrikada kalması, çoğu zaman diğer bütün kriterlerin önüne geçer. Yine de kararı ideolojik vermeyin; yukarıdaki beş ekseni kendi firmanız için puanlayın ve toplamı yüksek olan modeli seçin.
Puanlamayı yaparken eksenlere eşit ağırlık vermeyin. Müşteri şartı olan bir kriter tek başına diğer dördünü geçersiz kılar; internet altyapısı zayıf bir tesiste erişim ekseni diğerlerinden ağır basar. Pratikte şöyle çalışın: önce elemeyi yapın, sonra puanlayın. Bir eksende "bu bizim için kabul edilemez" diyorsanız o modeli listeden çıkarın ve kalan modeli TCO tablosuna taşıyın. On premise mi bulut mu kalite yazılımı sorusunun cevabı çoğu firmada aslında bu tek elemede belli olur; geri kalan çalışma, kararı yazılı olarak gerekçelendirmek içindir.
Kararı verdikten sonra da bir kontrol maddesi bırakın: yılda bir kez, yönetim gözden geçirme gündemine "kurulum modeli hâlâ uygun mu" satırını ekleyin. Yeni bir tesis açıldığında, yeni bir müşteri şartı geldiğinde ya da hat altyapısı değiştiğinde denge değişebilir. Bu maddeyi gündeme koymak beş dakika sürer ve modelinizin sessizce eskimesini engeller.