Personel yeni programı kullanmıyor — neden ve ne yapmalı?
Yazılım teslim edildi, eğitim verildi, kimse kullanmıyor. Bu bir disiplin sorunu değil; sebepleri belli ve çoğu proje başlarken önlenebiliyor.

En pahalı başarısızlık biçimi
Yazılım projelerinde en pahalı sonuç, sistemin çökmesi değil. Sistem çalışıyor, teslim alınmış, ödemesi yapılmış — ama kimse kullanmıyor.
Süreç eski hâliyle devam ediyor. Ustabaşı hâlâ deftere yazıyor, depo sorumlusu hâlâ Excel’i açıyor, ay sonunda birisi oturup verileri sisteme toplu giriyor.
Ödenen paranın tamamı zarar hanesine yazılıyor ve üstüne bir de “biz bu işleri beceremiyoruz” inancı kalıyor.
Bu sonucun sebepleri belli ve büyük kısmı proje başlarken önlenebiliyor.
Bu bir disiplin sorunu değil
İlk teşhis genellikle yanlış konuyor: “personel direniyor”, “alışkanlıklarını bırakmıyor”, “teknolojiye kapalı”.
Sahada gördüğümüz tablo farklı. Kullanıcılar yeni yolu, eskisinden hızlıysa benimsiyor. Yavaşsa benimsemiyor ve bu tamamen rasyonel bir davranış.
Tezgâh başındaki kişi için hesap basit: kâğıda yazmak beş saniye sürüyor. Tablette üç ekran gezip dört alan doldurmak kırk saniye sürüyor. Vardiya boyunca otuz kez tekrarlanan bir işte bu fark, günde yirmi dakika demek.
Örnek senaryo — Bir işletmede üretim kaydı için tablet konuyor. Operatör önce iş emrini arıyor, sonra listeden ürünü seçiyor, sonra miktarı giriyor, sonra kaydediyor. Dört adım. Eldivenle çalışıldığı için dokunmatik ekran ilk seferde tepki vermiyor. İki hafta sonra tabletler kullanılmıyor. Çözüm eğitimi tekrarlamak değildi: iş emri barkodu okutulduğunda ilk üç adımın atlanması ve yalnızca miktar sorulması. Aynı kayıt kırk saniyeden beş saniyeye indi ve kullanım kendiliğinden başladı.
Benimsememenin beş sebebi
1. Yeni yol eskisinden yavaş. En yaygın sebep. Ölçün: aynı işi eski ve yeni yöntemle yaptırıp süreyi tutun.
2. Kullanacak kişi tasarıma hiç katılmamış. Sistem yöneticiye gösterilerek yapılmış, kullanan kişi sonucu görmüş. Direncin kaynağı çoğu zaman burası.
3. Sistem işi kolaylaştırmıyor, yalnızca kaydediyor. Kullanıcıya hiçbir şey vermeyen, sadece veri isteyen bir ekran benimsenmiyor. Sistem karşılığında bir şey vermeli: aradığını bulmak, geçmişi görmek, bir işi tekrarlamak.
4. Hatanın bedeli yüksek. Yanlış girilen kaydı düzeltmenin yolu yoksa kullanıcı riske girmiyor ve kâğıda dönüyor.
5. Sahanın koşulları hesaba katılmamış. Eldiven, toz, ışık, gürültü, internet kesintisi. Ofis için tasarlanmış bir ekran üretim sahasında çalışmıyor.
Belirti | Muhtemel sebep | Ne yapılmalı |
|---|---|---|
Ay sonunda toplu giriş yapılıyor | Anlık giriş çok yavaş | Adım sayısını azalt |
Kâğıt hâlâ dolaşıyor | Sistem karşılık vermiyor | Kullanıcıya değer üret |
Veri girilmiş ama saçma | Zorunlu tutulmuş | Zorunluluğu değil yolu düzelt |
Tek kişi kullanıyor | Yetki veya eğitim eksiği | Kapsamı genişlet |
“Bozuk” deniyor ama arıza yok | Beklenti farkı | Kullanacak kişiyle konuş |
Zorunlu tutmak neden işe yaramıyor?
“Kullanmak zorunda” demek, veri girişini sağlıyor ama veri kalitesini sağlamıyor.
Kullanıcı sistemi geçmek için alanları rastgele dolduruyor: miktar hep 1, açıklama hep aynı, tarih varsayılan. Ortaya çıkan tablo, hiç veri olmamasından daha tehlikeli — çünkü artık yanlış veriye güveniliyor ve o veriye bakılarak karar veriliyor.
Dikkat — Sistemdeki veri kalitesini ölçmenin pratik yolu: bir haftanın kayıtlarını açıp aynı değerin kaç kez tekrarlandığına bakın. Tekrar oranı yüksekse veri girilmiyor, geçiliyor demektir.
Proje başlarken yapılacak tek şey
Benimsemeyi belirleyen en güçlü etken, projenin ilk gününde alınan bir karar: sistemi fiilen kullanacak kişi masada mı?
Ustabaşı, depo sorumlusu, planlamacı — kim kullanacaksa ilk toplantıda olmalı ve ekran tasarımı ona sorularak yapılmalı.
Bu, nezaket meselesi değil. O kişi, yöneticinin bilmediği şeyleri biliyor: hangi bilginin ne zaman elinin altında olduğunu, hangi sırayla çalıştığını, hangi durumda iki işi aynı anda yaptığını.
Sonradan gösterilen sistem her zaman “bize sorulmadan yapılmış” oluyor ve direnç oradan başlıyor. Bu maddeyi teklif aşamasında sormak da mümkün; yazılım firması seçerken sorulacak sorular listesinde yer alıyor.
Devreye alma, paralel dönem ve bitiş tarihi
Eski sistemi bir anda kapatmak riskli, hiç kapatmamak ise projeyi öldürüyor.
Doğru kurgu şu:
- Paralel dönem başlat. Eski ve yeni sistem birlikte çalışsın.
- Bitiş tarihini baştan koy. Genellikle iki üç ay. Tarihsiz paralel dönem hiç bitmiyor.
- Haftalık karşılaştır. İki sistemin verisi arasındaki her fark ya yeni sistemde bir eksik ya süreçte bir belirsizlik gösteriyor.
- Farkları kapat, sonra eskisini kapat.
Dördüncü adım atlanırsa eski sistem “yedek” diye yıllarca yaşıyor ve kimse yenisine tam geçmiyor.
Eğitimin biçimi süresinden önemli
Toplu eğitim toplantısı, sunum ve gönderilen kullanım kılavuzu — üçü de yapılıyor ve üçü de tek başına zayıf.
İşe yarayan şey ilk hafta saha başında destek. Kullanıcının kendi işini, kendi verisiyle, ilk kez yaptığı an öğrenmenin gerçekleştiği an. O anda yanında biri varsa sistem öğreniliyor; yoksa ilk takılmada kâğıda dönülüyor.
İkinci olarak, her rol için tek sayfalık bir “bu ekranda ne yapıyorsun” kâğıdı, kırk sayfalık kılavuzdan daha çok okunuyor.
Süreç iyileştirme ve saha eğitimi tarafında Sanayi ve Teknoloji Bakanlığı’nın Model Fabrika programı uygulamalı bir yapı sunuyor; eğitim ve danışmanlık kalemleri için KOSGEB’in İşletme Geliştirme Destek Programı başlığına da bakılabilir.
İpucu — Devreye alma tarihini üretimin en yoğun haftasına koymayın. Yoğunlukta hiç kimsenin yeni bir şey öğrenecek hâli olmuyor ve sistem daha ilk gün terk ediliyor.
Kalite ve kayıt tarafında ek bir gerekçe
Kalite yönetim sistemi olan işletmelerde kayıtların izlenebilir olması ayrıca gerekiyor. Kâğıt üzerinde tutulan kayıtların denetimde toparlanması hem zaman alıyor hem eksik kalıyor.
Standartlar ve belgelendirme tarafı için Türk Standardları Enstitüsü başvuru kaynağı. Sistemin benimsenmesi bu tarafta ayrıca değer üretiyor: denetim öncesi haftalarca süren evrak toplama işi ortadan kalkıyor.
Sistemin bir iç sahibi olmalı
Devreye alma sonrası en sık atlanan şey, sistemin işletme içinde kime ait olduğu.
Tedarikçi projeyi teslim edip çekiliyor. Sorular ortada kalıyor: yeni bir kullanıcı nasıl açılır, bir alan nasıl eklenir, rapor nasıl değiştirilir. Cevabı bilen kimse yoksa sistem donuyor ve zamanla ihtiyacın gerisine düşüyor.
İç sahip teknik biri olmak zorunda değil. Yapması gereken iş şu: soruları toplamak, hangilerinin ayarla çözüleceğini öğrenmek ve kalanları tedarikçiye tek elden iletmek.
Bu rol tanımlanmadığında herkes tedarikçiyi ayrı ayrı arıyor, talepler çelişiyor ve hiçbiri önceliklenmiyor.
Benimseme nasıl ölçülür?
"Kullanılıyor mu" sorusunun cevabı kanaate bırakılmamalı; sistemin kendi verisinden ölçülebiliyor.
Aktif kullanıcı oranı. Sisteme erişimi olan kaç kişiden kaçı bu hafta giriş yaptı?
Kayıt gecikmesi. İşin yapıldığı an ile kaydedildiği an arasındaki ortalama süre. Bu süre uzuyorsa sistem toplu giriş aracına dönüşüyor demektir.
Veri tekrar oranı. Aynı değerin kaç kez tekrarlandığı. Yüksekse alanlar geçiliyor, doldurulmuyor.
Eski yöntemin izleri. Kâğıt hâlâ dolaşıyor mu, Excel dosyası hâlâ güncelleniyor mu?
Dördü de haftalık bakılabilecek ölçüler ve dördü de sorunu erken gösteriyor. Üç ay sonra fark edilen benimseme sorunu geri döndürülemez hâle geliyor.
Dikkat — Benimseme ölçümünü personeli denetlemek için değil sistemi düzeltmek için kullanın. Ölçümün baskı aracına dönüştüğü yerde veri kalitesi bozuluyor ve elinizde yanlış bir tablo kalıyor.
İlk üç ayın planı
İlk hafta: Saha başında destek. Her rolün ilk gerçek işini yanında biri varken yapması.
İkinci ve üçüncü hafta: Günlük kısa kontrol. Takılınan noktaların listelenmesi ve hızlı düzeltmelerin yapılması. Bu dönemde yapılan küçük iyileştirmeler benimsemeyi en çok etkileyen müdahaleler.
İkinci ay: Haftalık karşılaştırma. Yeni sistemin verisi eski yöntemle karşılaştırılıyor, farklar kapatılıyor.
Üçüncü ay: Eski yöntemin kapatılması ve ölçümlerin gözden geçirilmesi.
Bu planın en kritik parçası ikinci ve üçüncü hafta. Kullanıcılar sorunlarını o dönemde söylüyor; kimse dinlemezse bir daha söylemiyor ve sessizce eski yönteme dönüyor.
Yönetimin rolü zorlamak değil, engel kaldırmak
Benimseme sorunlarında yönetimin ilk refleksi baskı oluyor: talimat, uyarı, takip.
Baskı kısa vadede veri girişini artırıyor ama veri kalitesini düşürüyor. Kullanıcı sistemi geçmek için alanları geçiştiriyor ve elinizde dolu ama yanlış bir veritabanı kalıyor.
İşe yarayan rol farklı: engel kaldırmak. Kullanıcının söylediği "şu ekran çok yavaş", "eldivenle çalışmıyor", "burada iki kez aynı şeyi giriyorum" gibi cümlelerin her biri kaldırılabilir bir engel. Bunlar kaldırıldıkça kullanım kendiliğinden artıyor.
Yönetimin ikinci işi görünürlük: sistemin ürettiği bilgiyi kullanmak. Kimse kullanmadığı bir sisteme veri girmek istemiyor. Haftalık toplantıda sistemden alınan bir rapora bakılıyorsa, veriyi giren kişi neden girdiğini biliyor.
Personel değiştiğinde ne oluyor?
Devreye alma başarılı geçse bile, altı ay sonra gelen yeni personel sistemi öğrenemiyorsa kazanım eriyor.
Bunu önleyen üç şey var ve üçü de proje sırasında üretilmeli:
Rol başına tek sayfalık kullanım kâğıdı. Kırk sayfalık kılavuz okunmuyor; tek sayfa okunuyor.
Kısa ekran kayıtları. Her ana iş için iki üç dakikalık kayıt, canlı eğitimden daha çok tekrar izleniyor.
İç sahibin belli olması. Yeni gelen kişinin kime soracağı belliyse öğrenme kendiliğinden yürüyor.
Bu üçü teklif aşamasında istenmezse projede üretilmiyor; sonradan üretmek hem pahalı hem eksik oluyor.
Sonuç — “Personel kullanmıyor” bir sonuç, sebep değil. Sebep neredeyse her zaman şu ikisinden biri: yeni yol eskisinden yavaş ya da kullanacak kişiye hiç sorulmamış. İkisi de proje başlarken önlenebiliyor, sonradan düzeltmek çok daha pahalı.
Devreye alma ve saha eğitimini projenin parçası olarak yürütüyoruz; çalışma biçimimiz yazılım geliştirme sayfasında. Kümenin genel çerçevesi fabrikalar için yazılım yazısında.
Bu konuyla ilgili
- depoda sayım tutmuyor — Kullanılmayan sistemin ürettiği ilk sorun.



