Bütçe toplantısında genel müdür soruyor: "Geçen yıl aldığımız kalite yazılımına ne oldu?" Kalite müdürü cevabı hazırlamış: doküman modülü çalışıyor, revizyonlar sistemde. Gerisi sessizlik. DÖF'ler hâlâ e-postayla dönüyor, iç denetim planı Excel'de, müşteri şikâyetleri ortak klasördeki bir dosyada. Odadaki herkesin vardığı sonuç aynı: "Yazılım tutmadı." Oysa yazılımın tuttuğu ya da tutmadığı gün, o toplantıdan on beş ay önce, kimsenin farkında olmadığı bir kararda belli olmuştu. QMS projesi başarısızlık nedenleri neredeyse hiçbir zaman teknik değildir; sahada tekrar eden dokuz tanesini ve her birinin erken sinyalini sırayla açıyoruz.
Bu yazıdaki maddelerin hepsi, kurulumdan sonra bizzat izlediğimiz projelerden çıktı. Kimisi altı ayda toparlandı, kimisi hiç toparlanamadı. Aradaki farkı yaratan şey her seferinde aynıydı: sorunun teknik olmadığını kabul edip organizasyonel tarafa müdahale etmek. Yazılımı değiştiren firmalar ikinci denemede de aynı duvara çarptı.
Proje hangi hafta öldü?
Başarısız kalite yazılımı projelerini geriye doğru izlediğinizde ölüm anı hep aynı yerde çıkar: canlıya geçişten sonraki ikinci ve dördüncü hafta arası. O aralıkta biri sistemi atlayıp işini eski yöntemle yapar, kimse buna itiraz etmez ve o an sistemin zorunlu değil isteğe bağlı olduğu ilan edilmiş olur. Bunun ardından her hafta bir istisna daha eklenir. Altıncı ayda geriye yalnızca doküman modülü kalır, çünkü o modülü kullanmamanın alternatifi yoktur; talimatın son revizyonu bir yerde durmak zorundadır.
Dolayısıyla soru "yazılım iyi miydi" değil, "hangi hafta hangi istisnaya izin verdik" olmalıdır. Aşağıdaki dokuz neden bu istisnaların nereden çıktığını gösteriyor. Hiçbiri yeni değil ve hepsi projenin ilk üç ayında görünür sinyal veriyor.
Nedenleri üç kümeye ayırdık: kararla ilgili olanlar, kurgu ve veriyle ilgili olanlar, kullanım ve süreklilikle ilgili olanlar. Bu ayrım işinize yarayacak, çünkü QMS projesi başarısızlık nedenleri arasında en çok görmezden gelinenler birinci kümededir ve düzeltmesi de en ucuz olanlar yine oradadır. Kurulum bütçesinin yüzde birini bile harcamadan, sadece kim neyi sahiplenecek sorusunu cevaplayarak projelerin çoğunu kurtarmak mümkün. İkinci ve üçüncü kümedekiler ise para değil, karar istiyor.
Karar ve sahiplik kaynaklı nedenler
1. Projenin sahibi belli değil
Sözleşme kalite bölümü tarafından imzalanmış, kurulum bilgi işlem tarafından yapılmış, kullanım ise üretimden bekleniyor. Kimsenin adı projenin karşısında yazmıyor. Erken sinyal: proje toplantılarının katılımcı listesi her seferinde değişiyorsa sahip yok demektir. Düzeltme, tek bir ada haftada bir gün ayırmak ve o kişiye karar yetkisi vermektir; iki kişiyle paylaştırılan sahiplik pratikte sıfır sahipliktir.
2. Yönetim desteği konuşmadan ibaret
Açılış toplantısında yapılan "bu proje bizim için önemli" konuşması hiçbir şeyi değiştirmez. ISO 9001 madde 5.1 liderlikten hesap verebilirlik ve kaynak sağlama ister; bunun somut karşılığı müdürlerin onaylarını sistem üzerinden vermesidir. Erken sinyal: canlıya geçişin üçüncü haftasında bir müdür bile sisteme girmemişse proje çoktan zayıflamıştır. Düzeltme basittir ve maliyeti yoktur; e-postayla gelen onay taleplerine "sistemden gönder" diye cevap verilmesi yeter.
3. Kapsam ilk günden çok geniş tutulmuş
On sekiz modülün tamamı aynı ay devreye alınmaya çalışılır, herkes her ekranı yarım öğrenir ve hiçbir süreç tam kapanmaz. Erken sinyal: devreye alma planında aynı haftaya dört modül yazılmışsa plan zaten gerçekçi değildir. Düzeltme, önce tek bir süreci uçtan uca kapatmaktır. DÖF akışı bu iş için en uygun adaydır, çünkü gecikmesi görünür ve herkesi ilgilendirir.
Kurgu ve veri kaynaklı nedenler
4. Mevcut süreç düzeltilmeden dijitalleştirilmiş
Kâğıt üzerinde beş imza gerektiren bir form, sisteme de beş onay adımıyla taşınır. Sonuç, aynı yavaşlığın ekranda tekrar edilmesidir ve kullanıcı haklı olarak "eskisi daha hızlıydı" der. Erken sinyal: bir kaydın ortalama kapanma süresi kâğıt döneme göre uzuyorsa akış yanlış kurgulanmıştır. Düzeltme, dijitalleştirmeden önce onay adımlarını gözden geçirmek ve bilgilendirme ile onayı ayırmaktır; haberdar olması gereken kişiyi onay zincirine koymak en sık yapılan kurgu hatasıdır.
5. Veri aktarımı planlanmamış
Eski kayıtların ne kadarının taşınacağı kararlaştırılmadığında iki uçtan biri yaşanır: ya her şey taşınmaya çalışılır ve proje aylarca gecikir, ya da hiçbir şey taşınmaz ve kullanıcı geçmişi aramak için hâlâ eski klasöre gider. Erken sinyal: kullanıcılar sisteme girdikten sonra hâlâ ortak klasörü açıyorsa aktarım eksiktir. Düzeltme, açık kayıtları ve güncel revizyonlu dokümanları taşıyıp kapanmış eskileri arşive almak, sonra da eski klasörü salt okunur yapmaktır.
6. Doküman yapısı sisteme kurulmadan yüklenmiş
Yüzlerce dosya, klasör mantığı düşünülmeden sisteme atılır. Arama çalışmaz, revizyon sahibi belirsizdir, aynı talimatın iki kopyası ortaya çıkar. ISO 9001 madde 7.5.3 dokümante bilginin (documented information) erişilebilir ve uygun olmasını, güncelliğini yitirmiş sürümlerin istenmeyen kullanımının önlenmesini ister. Erken sinyal: aynı doküman numarasının iki kaydı varsa yapı kurulmamış demektir. Düzeltmenin yolu doküman yönetimi kurallarını yüklemeden önce yazmaktan geçer.
Bir tedarikçide projeyi kurtaran hamle şuydu: kalite müdürü, e-postayla gelen bütün DÖF taleplerine tek bir cümleyle cevap vermeye başladı — "Sistemden aç, oradan bakacağım." İlk hafta birkaç kişi kızdı, ikinci haftadan itibaren talepler sistemden gelmeye başladı, altıncı haftada e-postayla gelen kalmadı. Yazılım değişmedi, değişen tek şey istisnaya izin verilmemesiydi.
Kullanım ve süreklilik kaynaklı nedenler
7. Eğitim herkese aynı biçimde verilmiş
Operatör, mühendis ve müdür aynı salonda aynı iki saatlik sunumu izler; kimse kendi işini öğrenmez. Erken sinyal: eğitimden sonraki ilk ayda kayıtların büyük çoğunluğu tek bir kişinin adına açılıyorsa eğitim tutmamıştır. Düzeltme, rol bazlı bir program kurmaktır; ayrıntılı bir örneği QMS kullanıcı eğitimi planı yazısında verdik.
8. Paralel sistem kapatılmamış
Kâğıt form da duruyor, Excel de duruyor, sistem de var. İnsan doğal olarak en alışık olduğunu seçer. Erken sinyal: matbaadan hâlâ aynı form basılıyorsa paralel sistem yaşıyordur. Düzeltme sert ama etkilidir: geçiş tarihinden sonra kâğıt formun basımını durdurun, kalan stoğu toplayın ve eski Excel dosyalarını salt okunur klasöre alın. Bu adım atılmadığında hiçbir eğitim ya da hatırlatma işe yaramaz.
9. Kullanım verisi hiç izlenmiyor
Proje canlıya geçtikten sonra kimse kaç kayıt açıldığına, kaçının süresinde kapandığına bakmaz. Sistem sessizce ölür ve bunu on beş ay sonra bütçe toplantısında fark edersiniz. Erken sinyal, sinyalin hiç olmamasıdır. Düzeltme, aylık üç sayıyı yönetimin gözden geçirme gündemine koymaktır: açılan kayıt sayısı, süresinde kapanan oranı ve sisteme giren farklı kullanıcı sayısı. Üçüncüsü, benimsenmeyi en dürüst gösteren rakamdır.
Bu üç sayıyı bir sayfada tutmak on dakikalık iştir ve karşılığı büyüktür. Bir müşterimizde aylık rapor gündeme girdikten sonra ikinci ayda bakım bölümünün sisteme hiç girmediği ortaya çıktı; sebep dirençsizdi, sadece kimse onlara kullanıcı tanımlamamıştı. Rapor olmasaydı bu, yıl sonu denetiminde bulgu olarak dönecekti. Ölçülmeyen bir sistemin kullanılmadığını fark etmenin başka yolu yok; kullanıcılar durumu kendiliğinden gelip söylemiyor, sessizce eski yönteme dönüyorlar.
Erken uyarı sinyalleri tablosu
Dokuz nedenin her birini ne zaman ve nereye bakarak yakalayacağınız şu tabloda duruyor. Kontrolü ayda bir yapmak yeterli.
| Neden | Erken sinyal | Ne zaman görünür |
|---|---|---|
| Sahip belirsiz | Toplantı katılımcıları her seferinde değişiyor | 1. ay |
| Yönetim desteği sözde | Hiçbir müdür sisteme girmemiş | 3. hafta |
| Kapsam çok geniş | Aynı haftaya üçten fazla modül planlanmış | Planlama aşaması |
| Süreç düzeltilmeden taşınmış | Kayıt kapanma süresi kâğıda göre uzamış | 2. ay |
| Veri aktarımı eksik | Kullanıcı hâlâ ortak klasörü açıyor | 1. ay |
| Doküman yapısı kurgusuz | Aynı numaraya iki kayıt, arama sonuç vermiyor | Yükleme haftası |
| Eğitim rol bazlı değil | Kayıtların çoğu tek kişinin adına açılıyor | 1. ay |
| Paralel sistem açık | Kâğıt form basımı sürüyor | 2. hafta |
| Kullanım izlenmiyor | Aylık kullanım raporu hiç istenmemiş | 3. ay |
Yarım kalmış bir QMS projesi denetimde kendini hemen ele verir. Denetçi bir DÖF kaydı ister, sistemden çıktı alırsınız; sonra o DÖF'ün doğrulama kanıtını sorar, cevap e-posta ekindedir. Kaydın bir kısmı sistemde bir kısmı dışarıda olduğunda, denetçi sürecin kontrol altında olmadığını görür. Yarı dijital bir sistem, tam kâğıt bir sistemden daha zayıf bir izlenebilirlik üretir.
Yazılımın payı ne kadar?
Yukarıdaki dokuz maddenin tamamı organizasyonel; bu, yazılımın hiç payı yok demek değil. QMS projesi başarısızlık nedenleri listesine eklenmesi gereken üç teknik durum daha var ve üçü de sahada projeyi doğrudan zorlaştırıyor. Birincisi, arayüzün kullanıcının diliyle konuşmamasıdır; vardiya amiri anlamadığı bir alanı doldurmaz, kaydı mühendise bırakır ve sistemin kullanıcı sayısı beş kişide kalır. İkincisi, modüllerin birbirine bağlı olmamasıdır; DÖF ile doküman ayrı adalar hâlinde çalışıyorsa aynı bilgiyi iki kez girmek zorunda kalırsınız ve ikinci giriş er ya da geç yapılmaz. Üçüncüsü ise değişiklik talebine verilen cevap süresidir. Basit bir alan eklemesi üç aya yayılıyorsa süreç yazılıma değil, yazılım sürece dayatılıyor demektir.
Bu üçünü satın alma aşamasında ölçebilirsiniz. Demo sırasında kendi DÖF formunuzu açtırıp "şu alanı ekleyin" deyin ve ne kadar sürdüğüne bakın. Aynı demoda bir dokümanın revizyon geçmişini ve o dokümana bağlı kaydı gösterin diye isteyin. Kalite yönetimi süreçlerinin birbirine bağlı yürüdüğü bir yapıda bu iki isteğin cevabı dakikalar içinde gelir. Gelmiyorsa, projeyi başlatmadan önce bilmeniz gereken bir şeyi öğrenmiş olursunuz.
Bir de sık atlanan bir teknik neden var: performans. Yüz kişilik bir tesiste doküman arama sekiz saniye sürüyorsa kullanıcı üçüncü aramada vazgeçer ve klasöre döner. Bunu demoda değil, kendi doküman hacminizle test edin. Sunucu ve veritabanı ayarları kurulumun ilk haftasında yapılmadığında, altıncı ayda "sistem yavaş" şikâyeti gelir ve o şikâyet çok geçmeden "sistem kullanışsız" cümlesine dönüşür.
Rayına oturtmak için ilk otuz gün
Ölmüş görünen bir projeyi yeniden başlatmanın yolu yeni yazılım almak değildir. Sırayla şunu yapın: bir sahip atayın ve adını yazılı olarak duyurun, tek bir süreç seçin, o süreç için paralel yolu kapatın, ilgili rollere kırk beş dakikalık hedefli eğitim verin ve dördüncü haftanın sonunda üç sayıyı ölçün. Otuz gün sonunda o süreç sistemde tam kapanıyorsa ikinci süreci ekleyin. Kapanmıyorsa ikinci süreci hiç eklemeyin, önce birincinin engelini bulun.
Bu otuz günlük turu kaç kez tekrarlayacağınızı baştan söyleyin. Süreçlerin tamamını aynı anda açmak yerine her ay bir tanesini eklediğinizde, altıncı ayın sonunda altı süreç gerçekten kapanır durumda olur; hepsini ilk ay açan firmalarda ise altıncı ayda kaç sürecin canlı olduğunu kimse söyleyemez. Sıralamayı da rastgele yapmayın: önce gecikmesi görünen ve birden çok bölümü ilgilendiren süreçleri alın, en sona kayıt hacmi düşük olanları bırakın.
Yazılım seçiminin de payı var elbette; Türkçe olmayan bir arayüz ya da sahayla konuşmayan bir kurgu işi zorlaştırır. Ama QMS projesi başarısızlık nedenleri listesindeki dokuz maddenin hepsi yazılımın dışındadır ve hepsi yönetilebilir. Firmanızın hangi noktada durduğunu görmek istiyorsanız QMS olgunluk seviyeleri yazısındaki basamaklarla kendi durumunuzu eşleştirin; oradan çıkacak tablo, hangi nedenin sizde canlı olduğunu da gösterir. PaKalite kurulumlarında da ilk otuz günde tek süreç kuralını öneriyoruz, çünkü ekibin sistemin bir yerde gerçekten kapandığını görmesi gerekiyor. Projenin kaderi, satın alma kararında değil, ilk istisnaya "hayır" dendiği gün belli oluyor.