Satın alma müdürünün e-postası kısaydı: "Kalite yazılımı için üç firmadan teklif alacağız, bize bir şartname yazar mısın? Cumaya kadar lazım." Kalite müdürü boş bir Word sayfası açtı, internette bulduğu bir örneği indirdi ve ilk sayfada durdu; metin bir hastane bilgi yönetim sistemi için yazılmıştı. İkinci örnek bir belediyenin evrak sistemine aitti. Üçüncüsünde "kullanıcı dostu arayüz sunulacaktır" diye bir madde vardı ve bunun nasıl ölçüleceği hiçbir yerde yazmıyordu. İyi bir QMS şartnamesi internetten indirilmez, çünkü şartname aslında sizin süreçlerinizin yazıya dökülmüş hâlidir. Aşağıda madde madde doldurabileceğiniz bir iskelet ve her fonksiyonel şartın yanına ölçülebilir kabul kriterinin nasıl yazıldığı var.
Şartname yazmadan önce yapılacak tek iş
Şartnameye oturmadan önce mevcut durumu bir sayfada çıkarın: hangi süreç hangi dosyada yürüyor, ayda kaç kayıt üretiliyor, kaç kişi giriyor. Doküman master listesinde kaç yürürlükteki doküman var? Geçen yıl kaç DÖF açıldı, kaçı termininde kapandı? Kaç ölçüm cihazı takip ediliyor? Bu sayılar olmadan yazılan şartname, tedarikçiye fiyat verebileceği bir zemin sunmaz ve gelen teklifleri karşılaştıramazsınız.
Aynı sayfada bir de "acı listesi" tutun. En çok zaman kaybettiğiniz üç işi yazın: revizyonu geçmiş doküman kopyalarının hatta bulunması, DÖF terminlerinin unutulması, kalibrasyon tarihi geçmiş bir mastarın kullanılması gibi. Şartnamenin en değerli maddeleri bu listeden doğar. Genel yetenek listelerinden değil.
Şartnamenin altı bölümü
İşleyen bir şartname altı bölümden oluşur. Bölümleri ayrı tutmanın pratik sebebi şu: teklifleri değerlendirirken her bölümü farklı kişi puanlar. Fonksiyonel bölümü kalite, teknik bölümü bilgi işlem, idari bölümü satın alma okur.
| Bölüm | İçeriği | En sık yapılan hata |
|---|---|---|
| 1. Kapsam | Hangi modüller, kaç kullanıcı, hangi lokasyonlar | Kapsam dışının yazılmaması |
| 2. Fonksiyonel şartlar | Sistemin ne yapacağı, modül modül | Ölçülemeyen sıfatlar kullanmak |
| 3. Teknik şartlar | Kurulum yeri, veritabanı, yetkilendirme, yedekleme | Tek bir ürünü tarif etmek |
| 4. Hizmet şartları | Eğitim, veri göçü, destek, SLA | Eğitim gün sayısının belirsizliği |
| 5. Kabul kriterleri | Her fonksiyonel maddenin test cümlesi | Bölümün hiç yazılmaması |
| 6. İdari şartlar | Takvim, ödeme, ceza, referans, teklif formatı | Teklif formatının serbest bırakılması |
Bu altı bölümü sırayla doldurduğunuzda ortaya çıkan belge hem teklif almaya hem de sonradan sözleşmenin ekine konmaya uygundur. Zaten şartnamenin gerçek ömrü teklif aşamasında değil, canlıya alma sonrasında başlar.
Kapsam: neyi satın almadığınızı da yazın
Kapsam bölümü iki listeden oluşur. Birinci liste kapsam içi modüllerdir: doküman yönetimi, DÖF, iç denetim, kalibrasyon, eğitim, tedarikçi değerlendirme, müşteri şikâyeti, ölçüm ve izleme. İkinci liste kapsam dışıdır: örneğin ERP entegrasyonu bu aşamada istenmiyorsa, bakım yönetimi sonraki yıla bırakılıyorsa bunu açıkça yazın. Kapsam dışını yazmayan şartnameler, tekliflerde bambaşka fiyat aralıklarına yol açar ve karşılaştırma imkânsızlaşır.
Kapsamın içine kullanıcı profillerini de koyun. Kaç kişi kayıt girecek, kaç kişi yalnızca onay verecek, kaç kişi salt okunur bakacak? Orta ölçekli bir tedarikçide bu dağılım genelde piramide benzer: az sayıda kişi kayıt girer, birkaç katı onay ve görüntüleme yapar, hat tarafındaki en kalabalık grup ise yalnızca yürürlükteki talimatı okur. Kendi sayılarınızı bu üç satıra yazın ve lisans modelinin bu profillere göre fiyatlanmasını isteyin.
Lokasyon bilgisini de atlamayın. Tek fabrikada mı çalışacak, ikinci tesise de açılacak mı, farklı tesislerin doküman numaralandırması ortak mı olacak? İki tesisli bir yapıda ortak doküman havuzu ile ayrı havuz arasındaki fark, satın alma sonrasında değiştirilmesi en pahalı kararlardan biridir. Bir QMS şartnamesinin kapsam bölümü bu kararı baştan yazmalıdır.
Fonksiyonel şartları yazmanın kuralı
Bir fonksiyonel şart cümlesi üç parçadan oluşur: hangi olay olduğunda, sistem ne yapar, hangi ölçüyle. Sıfat kullanmayın. "Gelişmiş raporlama" ya da "esnek iş akışı" gibi ifadeler teklif veren herkesin evet diyeceği, hiç kimseyi bağlamayan cümlelerdir. Aşağıdaki iki örneği karşılaştırın.
Zayıf madde: "Sistem, doküman yönetimi konusunda kapsamlı özellikler sunmalıdır." Güçlü madde: "Bir dokümanın yeni revizyonu onaylandığında sistem önceki revizyonu otomatik olarak yürürlükten kaldırır, arşiv listesinde erişilebilir tutar ve yürürlükteki liste ekranında yalnızca güncel revizyonu gösterir." İkinci cümleyi bir kişi sistem başında beş dakikada test eder. Birincisini kimse test edemez.
Modül modül ilerleyin. Doküman tarafında revizyon, onay akışı, dağıtım listesi, okundu bilgisi ve yürürlükten kaldırma maddeleri yazın; ISO 9001'in dokümante bilgi (documented information) kontrolü için istediği güncellik, erişim ve koruma beklentileri bu maddelerin arka planıdır. Düzeltici faaliyet tarafında kayıt açma, kök neden, aksiyon atama, termin uyarısı ve etkinlik doğrulama adımlarını isteyin; DÖF sürecinin kendi mantığını bilmeden bu maddeler yazılmaz.
Şartnameyi bir ürünün ekran görüntülerine bakarak yazmak, sahada gördüğümüz en pahalı alışkanlıklardan biri. Demoyu izlersiniz, o üründeki alan adlarını maddelere taşırsınız ve farkında olmadan tek firmayı tarif eden bir belge çıkarırsınız. Diğer iki teklif ya hiç gelmez ya da "kısmen karşılıyoruz" diye gelir; ortada karşılaştırma diye bir şey kalmaz. Maddeleri kendi sürecinizin diliyle yazın, ürünün diliyle değil.
Kabul kriteri sütunu: şartnamenin belkemiği
Fonksiyonel şartlarınızı bir tabloya alın ve yanına ikinci bir sütun açın: kabul kriteri. Bu sütun, canlıya alma gününde o maddenin karşılandığını nasıl kanıtlayacağınızı söyler. Kabul kriteri yazılamayan bir madde, aslında yeterince düşünülmemiş bir maddedir; ya silin ya da netleştirin. QMS şartnamesinin gerçek gücü bu sütunda saklıdır; teklif değerlendirmesinde herkesin evet dediği maddeleri birbirinden ayıran tek şey kabul kriteridir.
Örnek bir satır şöyle görünür. Madde: "Termini geçen düzeltici faaliyetler için sorumlu ve amirine otomatik hatırlatma gönderilir." Kabul kriteri: "Termini dün olan bir test kaydı oluşturulur; ertesi sabah sorumlu ve amirinin gelen kutusunda hatırlatma bulunur, kaydın durumu gecikmiş olarak görünür." Bu iki cümle, kabul testi gününde tartışmayı bitirir. Kabul kriterleri bölümünü POC senaryonuzla aynı dille yazarsanız, denemede test ettiğiniz maddeler doğrudan kabul testine geçer.
Teknik ve hizmet şartları
Teknik bölümde sistemin nerede çalışacağını netleştirin: şirket içi sunucuda mı, bulutta mı, ikisi de kabul mü? Veritabanı yedeğinin kim tarafından, hangi sıklıkta alınacağı; kullanıcı yetkilerinin rol bazlı tanımlanıp tanımlanmayacağı; kim, ne zaman, hangi kaydı değiştirdi bilgisinin tutulup tutulmayacağı bu bölümdedir. Kayıt değişiklik günlüğü otomotivde tartışmasız bir gerekliliktir; kanıtın kim tarafından değiştirildiğini gösteremiyorsanız kayıt güvenilirliğini savunamazsınız.
Hizmet şartlarında eğitim gün sayısını, eğitimin yerinde mi uzaktan mı verileceğini, kaç kişilik gruplar hâlinde yapılacağını yazın. Veri göçünü de buraya koyun: hangi Excel dosyalarının hangi modüle aktarılacağı, revizyon geçmişinin taşınıp taşınmayacağı ve doğrulamanın nasıl yapılacağı. Bu kalem çoğu şartnamede unutulur, sonra da projenin en uzun süren işi olur; Excel'den veri göçü yazısındaki adımları şartname maddesine çevirebilirsiniz. Arayüz dilinin ve destek dilinin Türkçe olması da bu bölümde açıkça istenmelidir.
Şartname denetime girmez; şartnamede unutulan madde ise iki yıl sonra bulgu olarak karşınıza çıkar. Kayıtların değiştirilemezliği, yürürlükten kalkmış dokümanların istenmeyen kullanımının önlenmesi ve kayıt saklama sürelerinin sistemde tanımlanması en çok atlanan üç maddedir. Bunları fonksiyonel bölüme yazmadıysanız, satın alınan sistemde de bulunmaz ve bir sonraki denetimde açık verirsiniz.
Şartnameyi kiminle birlikte yazmalısınız
Bir QMS şartnamesini tek başına kalite müdürünün yazması, sistemin de yalnız kalite biriminin kullanacağı bir araç olarak doğmasına yol açar. Masaya en az dört kişiyi oturtun: doküman ve DÖF akışını bilen kalite sorumlusu, sunucu ve yetkilendirme tarafını bilen bilgi işlem, hat tarafındaki kullanım gerçeğini bilen üretim şefi ve teklif sürecini yönetecek satın alma. İki saatlik tek bir oturum çoğu zaman yeter; önemli olan her bölümün sahibinin belli olmasıdır.
Bu oturumda tartışılması gereken üç soru vardır. Birincisi: hangi kayıt hangi birimde doğuyor ve kim onaylıyor? İkincisi: hangi bilgiye hattaki operatörün erişmesi gerekiyor ve hangi cihazdan bakacak? Üçüncüsü: hangi rapor yönetim gözden geçirmesine girecek? Bu üç sorunun cevabı, şartnamenin fonksiyonel bölümünün yarısını doğrudan yazdırır. Sistemin bütününü nasıl kurguladığınızı görmek için kalite yönetim sistemi yapısına da bir kez daha bakmakta fayda var.
Puanlama ve idari maddeler
Teklifleri karşılaştırabilmek için şartnamenin sonuna bir puanlama tablosu koyun. Fonksiyonel uyum yüzde 50, teknik uyum yüzde 20, hizmet ve destek yüzde 15, fiyat yüzde 15 gibi bir dağılım işe yarar; oranları kendi önceliğinize göre değiştirin ama yazın. Her fonksiyonel madde için tedarikçiden üç seçenekten birini işaretlemesini isteyin: standart olarak var, geliştirmeyle sağlanır, karşılanmıyor. İkinci seçeneği işaretlediği maddelerde süre ve bedel belirtmesini şart koşun.
İdari bölümde teklif formatını sabitleyin. Fiyatın lisans, kurulum, eğitim, veri göçü ve yıllık bakım olarak ayrıştırılmasını isteyin; toplam rakam veren teklifler karşılaştırılamaz. Takvimi de buraya yazın: sözleşmeden itibaren kaç hafta içinde kurulum, kaç hafta içinde pilot modül, kaç hafta içinde tam geçiş. Gecikme hâlinde uygulanacak ceza oranını ve düzeltme süresini de ekleyin.
Referans isteme maddesini de ciddiye alın. Tedarikçiden benzer ölçekte ve tercihen otomotiv sektöründe en az iki referans, bu referanslarda hangi modüllerin canlı olduğu bilgisiyle birlikte istensin. Referansı telefonda arayıp tek bir soru sorun: canlıya alma sözleşmede yazan tarihte tamamlandı mı, tamamlanmadıysa neden? Bu tek sorunun cevabı, tekliflerin fiyat farkından daha fazla şey anlatır.
Teklif sürecine bir de soru-cevap dönemi ekleyin. Şartname gönderildikten sonra bir haftalık pencere açın, gelen soruların tamamını topluca cevaplayın ve cevapları teklif verecek herkese aynı anda gönderin. Bunu yapmayan kuruluşlarda tedarikçiler farklı bilgilerle fiyat verir, gelen teklifler de birbiriyle karşılaştırılamaz hâle gelir. Cevap metni şartnamenin eki sayılır ve sonradan çıkan yorum farklarını baştan keser. Gelen soruların hangi maddelerde yoğunlaştığına da bakın; aynı maddeye üç ayrı firmadan soru geldiyse orayı siz yeterince açık yazmamışsınızdır.
Şartnameyi canlı tutmak
Hazırladığınız QMS şartnamesi teklif alındıktan sonra çekmeceye kaldırılacak bir belge değildir. Kabul kriterleri bölümünü olduğu gibi sözleşmenin ekine koyun, kabul testinde madde madde imzalayın, canlıya alma sonrasında da açık kalan maddeleri bir takip listesinde tutun. Üç ay sonra "şu özellik gelecekti" tartışması çıktığında elinizde imzalı bir belge olur. Sözleşme tarafındaki hükümleri QMS sözleşmesi ve SLA maddeleri yazısıyla birlikte değerlendirin.
Şartname ne kadar iyi yazılırsa yazılsın, kâğıt üzerinde her maddeye evet diyen bir teklif mutlaka gelir. Bunun ilacı tek: şartnameyi bir deneme kurgusuyla eşleştirin ve kendi verinizle çalıştırılmamış hiçbir maddeye karşılandı demeyin. Şartname, sorumluluğu tedarikçiye devretmenin değil, ne istediğinizi önce kendinize anlatmanın yoludur. Yazarken en çok öğrendiğiniz şey de zaten kendi süreçleriniz olur.