Demo toplantısı 45 dakika sürer ve çok iyi geçer. Satış mühendisi renkli bir gösterge panosu açar, arama kutusuna bir kelime yazar, sonuç anında gelir; herkes başını sallar. Üç ay sonra sistem kurulmuştur ve o güne kadar aklınıza gelmeyen bir şeyi fark edersiniz: yayınlanan bir revizyonun dağıtım listesini dondurup arşivleyemiyorsunuz, yani geçen ay kimin hangi sürümü okuduğunu geri getiremiyorsunuz. Bunun sebebi kötü bir ürün değil, yönetilmemiş bir demodur. Bir QDMS demo talebi gönderirken toplantının gündemini satış ekibine bırakırsanız, size ürünün en parlak tarafını gösterirler; sizin görmeniz gerekense en zorlandığınız işin o sistemde nasıl yürüdüğüdür.
Demo talebini gönderirken ne yazmalısınız
Bir QDMS demo talebi aslında bir brifingtir. Firmaya yazacağınız e-posta üç bilgi içermeli: şirket profili, kapsam ve senaryo listesi. Şirket profili tek paragraftır; kaç kişi çalışıyor, hangi standartlara tabisiniz, kaç lokasyon var, yaklaşık kaç doküman ve kaç kayıt tipi yönetiliyor. Kapsam, ilk etapta hangi modülleri açacağınızı söyler. Senaryo listesi ise en önemli kısımdır: "Toplantıda şu altı senaryoyu bizim dokümanlarımızla görmek istiyoruz" cümlesiyle biten bir liste gönderin.
Bu e-postayı gönderdiğinizde iki şey birden olur. Satış ekibi hazırlıklı gelir ve toplantı gerçekten sizin işinizi konuşur; ayrıca cevap veremeyecekleri bir madde varsa bunu önceden söylemek zorunda kalırlar. Sunumun ortasında "o özellik yol haritamızda" cümlesini duymak, sözleşme imzaladıktan sonra duymaktan iyidir.
Kendi dokümanınızla denenecek altı senaryo
Toplantıya üç dosya götürün: gerçek bir prosedür, bir form ve bir müşteri çizimi ya da dış kaynaklı doküman. Hazır demo verisiyle her sistem düzgün görünür, çünkü o veri sistemin sevdiği biçimde hazırlanmıştır. Aşağıdaki altı senaryo, doküman yönetiminde en çok zorlanılan noktaları kapsar.
| # | Senaryo | Ne kanıtlar |
|---|---|---|
| 1 | Kendi prosedürünüzü kendi kod formatınızla sisteme yükleyin | Kodlama şemanız zorlanmadan taşınıyor mu |
| 2 | Üç kademeli onaya gönderin, ikinci onaycı reddetsin | Ret sonrası akış, gerekçe kaydı ve geri dönüş |
| 3 | Yayınlanan dokümanı revize edin, eski sürümü arayın | Eski revizyon pasifleşiyor mu, arşivden okunabiliyor mu |
| 4 | Dağıtım listesi tanımlayıp okundu teyidi raporu alın | Kim okudu, ne zaman okudu; liste dondurulabiliyor mu |
| 5 | Bir dokümanı yalnız görme yetkisiyle açın, indirmeyi deneyin | Görme, indirme ve yazdırma yetkileri ayrışıyor mu |
| 6 | Müşteri çizimini dış kaynaklı doküman olarak kaydedin | Geçerlilik takibi ve gözden geçirme hatırlatması var mı |
Altı senaryonun her birini sunucunun değil sizin ekibinizden birinin yapmasını isteyin. Fareyi eline alan kişi değiştiğinde arayüzün gerçekten anlaşılır olup olmadığı ortaya çıkar. Sistem kullanıcıya kalite mühendisi mantığıyla değil ustabaşı mantığıyla da açılabilmelidir.
Dördüncü senaryo demolarda nadiren gündeme gelir, oysa asıl ayrım orada çıkar. Yayın anını kaydeden ama dağıtım listesini dondurmayan bir sistemde, altı ay sonra "bu revizyonu o tarihte kimler okumuştu?" sorusunun cevabı kaybolur, çünkü liste bugünkü organizasyona göre yeniden hesaplanır. Müşteri denetiminde tam bu soru sorulur. Demo sırasında bir dağıtım yapın, ardından bir kullanıcıyı listeden çıkarın ve eski raporu tekrar açın. Rapor değiştiyse o sistemde geçmişe dönük kanıtınız yok demektir.
Yazılım firmasına sorulacak sorular
Senaryolar bittikten sonra sıra idari sorulara gelir. Sekiz soruyu yazılı olarak sorun ve cevapları toplantı notuna geçirin. Kurulum kendi sunucumuzda mı olacak, bulutta mı, ikisi de mümkün mü? Veri hangi ülkede duruyor? Kullanıcı tanımlaması etki alanı (domain) hesaplarıyla eşleşiyor mu? Sürüm yükseltmesi nasıl yapılıyor, kesinti süresi ne kadar? Yedekleme ve geri dönüş testini kim yapıyor? Destek talebine kaç saat içinde dönülüyor ve bu süre sözleşmede yazıyor mu? Yeni bir doküman tipi eklemek konfigürasyon mu, geliştirme mi? Ve en önemlisi: sistemden çıkmak istediğimizde verilerimizi hangi biçimde alırız?
Bu son soru, tüm listenin en ayırt edicisidir. Dokümanların yanında revizyon geçmişini, onay kayıtlarını ve okundu teyitlerini de dışa aktarabiliyor musunuz? Cevabı net veren bir tedarikçi verinin size ait olduğunu kabul ediyor demektir. Kaçamak cevap alıyorsanız, sözleşme süresi boyunca pazarlık gücünüzün olmayacağını baştan bilin.
Bir soruyu da kendinize sorun: bu sistemi kim yönetecek? Doküman yönetimi kurulunca kendi kendine yürümez; kod atayan, dağıtım listelerini güncelleyen, yetki taleplerini değerlendiren bir sahibi olmalı. Bu kişi belirlenmeden alınan yazılım, altı ay içinde kalite yöneticisinin ek mesaisine dönüşür. Demo toplantısında tedarikçiye "bizim tarafımızda haftada kaç saatlik bir yönetim işi doğar?" diye sorun; dürüst bir cevap projeyi baştan doğru kurgulamanızı sağlar.
Demoda görmezden gelmeniz gerekenler
Bir sunumda etkileyici duran ama günlük işte pek işe yaramayan üç şey vardır. Birincisi gösterge panolarıdır; renkli grafikler hoş görünür, ama kalite ekibinin günü grafik izleyerek değil doküman revize ederek geçer. İkincisi yapay zekâ etiketli arama özellikleridir; asıl mesele aramanın hızı değil, arama sonucunda çıkan dokümanın güncel olduğundan emin olmanızdır. Üçüncüsü mobil uygulamadır; sahada tablet kullanacaksanız önemlidir, kullanmayacaksanız karar kriteri değildir.
Buna karşılık sunumda hiç konuşulmayan ama üç ay sonra sizi yoracak şeyler şunlardır: toplu işlem yeteneği, doküman kodunun otomatik üretilmesi, şablon yönetimi ve raporların Excel'e aktarımı. Bunları demoda sormazsanız, kurulumdan sonra her biri ayrı bir talep formuna dönüşür.
Demoya iki firmayı aynı gün art arda çağırmayın. Sabah izlenen sunum, öğleden sonrakini gölgeler ve karşılaştırma ikinci firmanın aleyhine döner. Aralarına en az iki gün koyun, her toplantının hemen ardından formu doldurun. Hafızaya güvenilerek yapılan karşılaştırmada belirleyici olan, sistemin yeteneği değil sunumu yapan kişinin anlatım gücü olur.
Toplantıyı kaydetmeyi de düşünün. Ekran kaydı alınmasına izin veren firmalar vardır; izin alarak kaydettiğiniz 90 dakika, karar toplantısında tartışmalı bir noktaya döndüğünüzde hakem olur. "Bunu yapabildiğini söylemişlerdi" cümlesi yerine kaydı açarsınız. Kayda izin verilmiyorsa en az bir kişi not tutsun ve notu toplantı biter bitmez temize çeksin; ertesi güne kalan notların yarısı okunmaz hâle gelir.
Toplu işlem konusunu biraz açalım, çünkü günlük yükün büyük bölümü oradadır. Bir organizasyon değişikliğinde 40 dokümanın onaycısını tek tek değiştirmek yarım gün alır; toplu güncelleme varsa beş dakika. Aynı şey saklama sürelerinde, dağıtım gruplarında ve gözden geçirme tarihlerinde de geçerlidir. Demoda "şu 20 dokümanın sorumlusunu tek seferde değiştirebilir misiniz?" diye sorun ve ekranda görün. Cevap "geliştirme gerekir" ise bu maliyet üç yıl boyunca sizin ekibinizin mesaisinden çıkar.
Deneme sürümü: asıl karar burada verilir
Demo bir sunumdur; QDMS deneme sürümü ise sistemi kendi ekibinizle kullandığınız süredir. Kısa listeye kalan iki firmadan da iki haftalık bir deneme ortamı isteyin. Bu iki hafta içinde beş kullanıcıyla on doküman yayınlayın, bir revizyon döndürün, bir dokümanı reddedin, bir kullanıcının yetkisini kısıtlayın ve bir rapor alın. Bu kadarı sistemin günlük ritminizi taşıyıp taşımadığını gösterir.
Deneme sonunda ekipten yazılı geri bildirim toplayın. Bir cümlelik değil, üç başlıklı: neyi kolay buldun, nerede takıldın, kendi işinde bunu kullanır mısın. Kalite ekibi dışından iki kişinin cevabı, en az sizin kanaatiniz kadar değerlidir; çünkü sistemi asıl onlar kullanacaktır. Kalite yönetim yazılımı seçiminde kullanıcı direnci, teknik yetersizlikten daha çok proje batırır.
Demo öncesi kendi sürecinizi bir sayfaya dökün
Toplantıdan önce yapılması gereken bir hazırlık daha var: mevcut doküman sürecinizi tek sayfaya yazmak. Kaç doküman tipiniz var, hangi tipte kaç kademe onay işliyor, dağıtımı kim yapıyor, revizyon kararını kim veriyor, yılda kaç revizyon çıkıyor. Bu sayfa olmadan demoya giden ekipler sistemi kendi işlerine göre değil, sunumda gördükleri örneğe göre değerlendirir. Sonra kurulum aşamasında "bizde böyle yürümüyordu" cümlesi çıkar ve süreç yazılıma göre eğilir.
Aynı sayfaya bir de sayı koyun: aylık ortalama revizyon adedi, onayda geçen ortalama gün, dağıtım yapılan kişi sayısı. Bu üç sayı hem demoda gerçekçi bir senaryo kurmanızı sağlar hem de bir yıl sonra iyileşmeyi ölçmenizi. Onay süresi 11 günden 3 güne indiyse bunu söyleyebilmek, yatırımın karşılığını göstermenin en somut yoludur. Ölçmediğiniz bir süreci iyileştirdiğinizi iddia edemezsiniz.
Referans ziyareti ve destek ekibini tanımak
Demo ve deneme sürümü sistemi gösterir, referans ziyareti ise firmayı gösterir. Kısa listedeki tedarikçiden benzer ölçekte ve tercihen aynı sektörde çalışan iki referans isteyin, en az birini yerinde ziyaret edin. Orada sorulacak sorular satış toplantısındakinden farklıdır: kurulum planlanan sürede bitti mi, göç sırasında ne patladı, destek talebine kaç saatte dönüldü, sürüm yükseltmesinde kesinti yaşandı mı, bugün yeniden seçseniz aynı sistemi mi alırdınız. Bu beş sorunun cevabı, üç saatlik bir sunumdan daha çok şey anlatır.
Bir de kimlerle çalışacağınızı sorun. Kurulumu yapacak danışmanın adı belli mi, kaç projede çalışmış, destek talebi bir kişiye mi yoksa havuza mı düşüyor? Geciken kurulumların arkasından çoğu zaman ürünün yetersizliği değil, proje yönetiminin zayıflığı çıkar. Demoyu yapan kişiyle kurulumu yapan kişinin farklı olması normaldir, ama ikincisinin kim olduğunu sözleşmeden önce bilmek sizin hakkınızdır.
Yol haritasını da sorun. Hangi özellikler önümüzdeki yıl geliyor, sürüm yükseltmesi ücretli mi, müşteri talepleri nasıl önceliklendiriliyor? Bu sorunun cevabı ürünün canlı olup olmadığını gösterir. İki yıldır yeni sürüm çıkmamış bir yazılıma bağlanmak, dört yıl sonra göç projesini yeniden yaşamak demektir; o projenin nasıl yürüdüğünü doküman yönetimi tarafında bir kez görenler tekrarını istemez.
Değerlendirme formu ve karar
Karar toplantısına gitmeden önce iki sayfalık bir değerlendirme formu doldurun. Üst bölümde altı senaryonun sonucu üçlü ölçekle işaretlensin: sorunsuz yaptı, ek ayar gerektirdi, yapamadı. Alt bölümde sekiz idari sorunun cevabı yazılı dursun. Son bölüme de maliyeti koyun; teklifleri aynı kalemlere indirgemenin yolunu maliyet rehberimizde anlattık. Bu form hem kararınızı savunmanızı sağlar hem de bir yıl sonra "biz bunu neden seçmiştik?" sorusuna cevap verir. Aynı formu her QDMS demo talebi için ayrı ayrı doldurun; iki firmayı hafızadan karşılaştırmak, üç hafta arayla izlenen iki sunumda mümkün değildir.
Kararı verdikten sonraki iş, mevcut arşivi yeni sisteme taşımaktır; o sürecin altı haftalık planını geçiş yazımızda bulabilirsiniz. PaKalite'yi kısa listenize alacaksanız kurulumu kendi sunucunuzda yapabildiğinizi ve modüllerin birbirine bağlı çalıştığını not edin; modüller sayfası hangi senaryonun hangi ekranla karşılandığını gösterir. Bir QDMS demo talebi göndermeden önce altı senaryonuzu yazıya dökün; toplantıyı satış ekibinin sunumu değil sizin gündeminiz yönetsin.