Satıcı toplantının sonunda o cümleyi kurdu: "İki hafta ücretsiz deneyin, kararınızı sonra verirsiniz." Kurulum yapıldı, kullanıcılar tanımlandı, herkes tamam dedi. On dört gün sonra sisteme bakıldığında içeride tek bir gerçek kayıt yoktu; yalnızca eğitim gününde girilen "deneme DÖF" ve "test dokümanı" duruyordu. Karar toplantısında da yine aynı sunum açıldı ve seçim, iki hafta önceki izlenimle aynı şekilde verildi. Bir QMS POC çalışmasının amacı tam olarak bunu engellemektir: sistemin sizin verinizle, sizin insanlarınızın elinde nasıl davrandığını görmek. Aşağıda on iş gününe sığan, sonunda evet ya da hayır çıkaran bir kurgu var.
Demo başka, kavram kanıtı başka
Demoda klavye tedarikçidedir. Senaryoyu o seçer, veriyi o hazırlar, akış hiç takılmadan ilerler. Kavram kanıtı (proof of concept) ise tam tersidir: senaryoyu siz yazarsınız, veriyi siz verirsiniz, tuşlara sizin kalite sorumlunuz basar. İkisi arasındaki fark, canlıya alındıktan sonra ortaya çıkan sürprizlerin büyük kısmını önceden görmenizi sağlar.
Bir POC'un iyi ya da kötü bittiğini anlamanın tek yolu, başlamadan önce başarının tanımını yazmış olmaktır. "Beğendik" bir kriter değildir. "Geçen ay kapattığımız 12 DÖF kaydının tamamı sisteme girildi, kök neden ve etkinlik doğrulama alanları doldurulabildi, termin uyarısı ilgili kişilere ulaştı" bir kriterdir. Bu ayrımı kurmadan yapılan denemeler, süre bitiminde herkesin farklı bir şey hatırladığı toplantılarla sonuçlanır.
Başlamadan önce seçilecek üç şey
Birincisi kapsam. İki haftada tüm modülleri denemeye kalkarsanız hiçbirini gerçekten denemiş olmazsınız. En fazla iki modül seçin ve bunlar günlük hayatınızda en çok acıtan iki süreç olsun. Çoğu otomotiv tedarikçisinde bu ikili doküman yönetimi ve düzeltici faaliyettir; bazılarında kalibrasyon ve tedarikçi değerlendirme öne çıkar.
İkincisi ekip. POC'u üç kişiyle yürütün: kayıt girecek bir kalite sorumlusu, onay verecek bir yönetici, kurulum ve yetkilendirmeyi yapacak bir bilgi işlem personeli. Bu üç kişinin iki hafta boyunca günde yarım saatlerini ayıracakları takvimde yazılı olmalı. Yazılı olmayan zaman ayrılmaz; deneme de bu yüzden yarıda kalır.
Üçüncüsü veri. Uydurma kayıtla yapılan denemede her sistem çalışır. Gerçek veriniz ise kendi karmaşasını da beraberinde getirir: aynı prosedürün iki farklı adla kaydedilmiş olması, revizyon numarası boş satırlar, sorumlusu ayrılmış personel olan açık DÖF kayıtları. Sistemin bunlarla ne yaptığını görmek, denemenin asıl değeridir.
Hangi veriyi seçmeli?
Kural basit: geçen ayın gerçek kayıtları. Doküman tarafında yürürlükteki 15 dokümanı ve bunlardan üçünün revizyon geçmişini alın; içlerine bilerek bir tanesini yürürlükten kalkmış hâliyle koyun. Düzeltici faaliyet tarafında geçen ay açılan kayıtların tamamını, kapanmış ve açık olanlarıyla birlikte girin. Kalibrasyon deneyecekseniz gelecek 60 gün içinde süresi dolacak cihazları seçin, çünkü uyarı mekanizmasını ancak böyle test edersiniz.
Veriyi girmeden önce üzerinde kısa bir temizlik yapmayın; bilerek olduğu gibi girin. Amaç sistemin nasıl davrandığını görmek olduğu kadar, kendi verinizin ne durumda olduğunu da görmektir. Bu iki haftada çıkan kirli veri listesi, ilerideki gerçek aktarımın hazırlık işini de baştan önünüze koyar.
On iş günlük takvim
Aşağıdaki tablo, sahada işleyen bir QMS POC takvimidir. Günleri kaydırabilirsiniz ama sıralamayı bozmayın; kurulumdan önce senaryo yazılmazsa deneme kendiliğinden demoya dönüşür. Takvimi ekibin ortak ajandasına gerçek toplantı olarak koyun; "boş bulduğumuz zaman gireriz" denilen kayıtlar hiçbir zaman girilmez. Her günün sonunda tek satırlık bir not tutmak da yeterlidir: bugün ne girildi, nerede takıldık.
| Gün | Yapılacak iş | Sorumlu | Çıktı |
|---|---|---|---|
| 0 | Kapsam, senaryo ve başarı kriterlerinin yazılması | Kalite yöneticisi | POC planı, 1 sayfa |
| 1 | Kurulum, kullanıcı ve yetki tanımları | Bilgi işlem + tedarikçi | Çalışan test ortamı |
| 2 | Ekibe 2 saatlik uygulamalı eğitim | Tedarikçi | Katılım kaydı |
| 3-4 | 15 dokümanın ve revizyonlarının girilmesi | Kalite sorumlusu | Yürürlükteki doküman listesi |
| 5-6 | Geçen ayın DÖF kayıtlarının girilmesi | Kalite sorumlusu | Açık ve kapalı DÖF listesi |
| 7 | Onay, bildirim ve termin uyarılarının denenmesi | Yönetici | Bildirim ekran görüntüleri |
| 8 | Rapor ve dışa aktarma denemesi | Kalite yöneticisi | Excel/PDF çıktıları |
| 9 | Değerlendirme formunun doldurulması | Tüm ekip | Kriter bazlı puan tablosu |
| 10 | Karar toplantısı | Yönetim | Evet / hayır kararı |
Sıfırıncı gün en kritik olanıdır ve genelde atlanır. O bir sayfa yazılmadan kurulum yapılırsa, ikinci haftanın sonunda elinizde ölçebileceğiniz hiçbir şey olmaz.
Deneme boyunca tedarikçinin ekranın başında durması, sonucu sessizce bozan şeydir. Yardım etme niyetiyle kayıtları o girer, takılınan yerde klavyeyi eline alır ve iki haftanın sonunda sistemin kendi başınıza kullanılabilir olup olmadığı hâlâ bilinmez. Kuralı baştan koyun: eğitim günü hariç, tedarikçi soru sorulduğunda cevaplar, tuşa basmaz. Zorlandığınız her adımı da not edin; o notlar eğitim planınızın ilk taslağıdır.
POC ortamını doğru kurmak
Deneme ortamı, canlı ortamın küçültülmüş hâli gibi kurulmalıdır. Kullanıcıları gerçek rolleriyle tanımlayın: kayıt giren, onaylayan, salt okunur bakan. Herkese yönetici yetkisi verilen bir QMS POC ortamında yetki kurgusunu hiç test etmemiş olursunuz, oysa canlıda en çok tartışılan konu tam olarak budur. Bir kullanıcının başkasının kaydını değiştirip değiştiremediğini, bir onaycının kendi açtığı kaydı onaylayıp onaylayamadığını mutlaka deneyin.
Ortamın nerede çalıştığı da denemenin bir parçasıdır. Kendi sunucunuza kuruluyorsa kurulumun ne kadar sürdüğünü, hangi bileşenlerin gerektiğini ve bilgi işlemin ne kadar müdahale ettiğini not edin; bu, gerçek kurulumda karşılaşacağınız tablonun birebir provasıdır. Hattaki bir terminalden ya da tablet üzerinden erişimi de deneyin. Operatörün yürürlükteki talimatı üç tuşta bulamadığı bir doküman yönetimi kurgusu, ofiste ne kadar iyi görünürse görünsün sahada kullanılmaz.
Ölçülebilir başarı kriterleri
Kriterleri iki başlıkta yazın: yapılabilirlik ve süre. Yapılabilirlik kriterleri sistemin o işi yapıp yapmadığını sorar. Örneğin: yürürlükteki bir prosedürün yeni revizyonu onaylandığında öncekinin otomatik olarak yürürlükten kalkması; bir DÖF kaydına birden fazla aksiyon ve farklı sorumlu atanabilmesi; termini geçen kayıt için sorumluya ve amirine bildirim gitmesi; kayıtların Excel'e eksiksiz aktarılabilmesi.
Süre kriterleri ise aynı işi bugünkü yönteminizle karşılaştırır. Bir DÖF kaydının açılması bugün kaç dakika sürüyor, sistemde kaç dakika sürdü? Yürürlükteki doküman listesini çıkarmak bugün ne kadar zaman alıyor, sistemde kaç saniye? Bu ölçümleri kronometreyle yapın ve forma yazın. Karar toplantısında iki rakam yan yana durduğunda tartışma kısalır.
Kriter sayısını on beşle sınırlayın. Elli kriterli formlar doldurulmaz, doldurulsa da okunmaz. Şartname yazdıysanız kriterleri oradan seçin; zaten QMS şartnamesindeki kabul kriterleri doğrudan POC senaryosuna dönüşür.
POC sırasında en çok yapılan hatalar
Kapsamın şişmesi başı çeker. İkinci haftada "bir de tedarikçi modülüne bakalım" denir, kurulum yapılır, kimse girmez ve elde yarım kalmış üç modül kalır. Kapsamı sıfırıncı günde kilitleyin. Hemen ardından denemenin tek kişiye bırakılması gelir; kayıt girenle onay veren aynı kişi olduğunda akışın en önemli kısmı hiç sınanmamış olur.
Sorunların not edilmemesi de en az bunlar kadar yaygın. Deneme boyunca karşılaşılan her takılma tek bir listede toplanmalı, her satırın yanında hangi ekranda olduğu yazmalıdır. Bu liste hem karar toplantısının girdisi hem de seçim yapıldıktan sonra tedarikçiye verilecek ilk iş listesidir. Bir başka klasik hata da veri aktarımını hiç denememektir. En azından bir Excel dosyasını içe aktarmayı deneyin; gerçek geçişin en uzun kalemi budur ve veri göçü tarafında ne kadar zorlanacağınızı iki hafta içinde önünüze koyar.
En sinsi olanı ise sona kalıyor: denemenin sessizce uzatılması. "Bir hafta daha bakalım" cümlesi ilk söylendiğinde masum görünür, üçüncü kez söylendiğinde deneme artık bitmeyen bir sürece dönüşmüştür. Süre uzatma talebi geldiğinde tek soru şu olsun: hangi kriter henüz test edilemedi ve bunun için kaç gün gerekiyor? Cevap belirsizse süre uzatılmaz, karar verilir.
POC ortamında girilen kayıtlar kalite kaydı değildir; deneme verisidir. Karar verildikten sonra bu ortamı canlı sisteme dönüştürmeyin, temiz kurulumla başlayın. Aksi hâlde deneme sırasında girilmiş yarım kayıtlar ve test dokümanları canlı sisteme sızar. Bir sonraki denetimde yürürlükteki doküman listenizde "test prosedürü" görünmesinden daha rahatsız edici bir başlangıç yoktur.
Denemenin görünmeyen maliyeti
Bir QMS POC bedava değildir. Üç kişinin on iş günü boyunca günde yarım saati, eğitim için ayrılan iki saat, bilgi işlemin kurulum için verdiği yarım gün toplandığında yaklaşık yirmi beş saatlik bir emek çıkar. Bu maliyeti baştan kabul edin ve karşılığında ne aldığınızı bilin: canlıya alma sırasında yaşanacak sürprizlerin büyük kısmını iki hafta içinde, henüz sözleşme imzalanmamışken görürsünüz.
Aynı emeği harcamamanın maliyeti ise çok daha yüksektir. Yanlış seçilmiş bir sistemden dönmek üç yıllık bir sözleşme, taşınamayan bir veri yığını ve yeniden eğitilecek bir ekip demektir. Bu yüzden yönetimden POC için zaman istemekte tereddüt etmeyin; iki haftalık ayrılmış zaman, üç yıllık bir kararın en ucuz sigortasıdır.
Karar toplantısı ve değerlendirme formu
Onuncu gün toplantısında sunum açılmaz. Masaya iki belge konur: kriter formu ve takılma listesi. Her kriterin karşısına üç seçenekten biri işaretlenir; karşılandı, kısmen karşılandı, karşılanmadı. Kısmen ve karşılanmadı satırlarının yanına tek cümlelik gerekçe yazılır. Bu form imzalanır ve satın alma dosyasına konur.
Kararın eşiğini de önceden belirleyin. Sahada tuttuğunu gördüğümüz ölçü şu: kritik işaretlenmiş kriterlerin tamamı karşılanacak, toplamda da beşte dördünün altına düşülmeyecek. Altındaysa ya kapsam daraltılıp ikinci bir kısa deneme yapılır ya da başka bir ürüne geçilir. Karar evetse takvim hemen kurulur; 90 günlük devreye alma planı POC bitiminden sonraki hafta başlamalıdır, çünkü ekibin alışkanlığı sıcakken ilerlemek en kolay dönemdir.
Birden fazla ürünü aynı senaryoyla denemek, elinizdeki en adil yöntemdir. Aynı 12 DÖF kaydını ve aynı 15 dokümanı iki ayrı sisteme girin. İki hafta yerine üç hafta harcarsınız ama karar artık izlenime değil, aynı işin iki sistemde kaç adımda tamamlandığına dayanır. Ölçtüğünüz şey de yazılımın yeteneği değil, sizin işinizin o yazılımda ne kadar yol kat ettiğidir. Böyle kurgulanmış bir QMS POC bittiğinde karar zaten kendini yazmış olur; toplantıda yapılan tek şey onu imzalamaktır. PaKalite'yi indirip kendi sunucunuza kurarak bu denemeyi tedarikçi beklemeden başlatabilirsiniz.