Kamuda bilgi işlem felaketi – 5 Teknik şartname yazımı
Bu yazı serisinin başından beri kamu bilgi işlem personellerimizden yanlış beklentilerimizin olduğunun altını çizmeye çalışıyorum. Bugün kamu kurumlarımızda bilgi işlem konusunda istihdam edilmiş memurların çoğu, bırakın bir yazılım projesi yapmayı, dışarıya yaptırılacak bir işin teknik şartnamesini bile doğru dürüst yazacak durumda değildirler.
Yapılacak işi doğru tanımlamak, sınırlarını belirlemek, neyi ne şekilde istediğini ölçülebilir şekilde ortaya koyabilmek, işin neredeyse yarısına tekabül eder.
Kopyala-Yapıştır
Kamu teknik şartnamelerini hazırlama işi ile görevlendirilen memurlar ilk iş olarak daha önce yazılmış şartnameler arar bulurlar. Şimdilerde yüksek lisans tezlerinin ne oranda başka tezlerden “alıntı” olduğunu belirleyen yazılımlar var. Kamu teknik şartnameleri bu yazılımlarla gözden geçirilse sanırım çoğunun yüzde seksenden fazla oranda başka şartnamelerden kopyalandığı ortaya çıkar. “Canım bunda ne var, kamu kurumlarının benzer şartları olmasından, bu şartların aynı şekilde yazılmasından daha tabii ne olabilir” denebilir. Şartnamelerle haşır neşir olanlar bilir: şartnamede tutarlılık çok önemlidir. Bu sayfada şöyle yapılacak diye tarif ettiğiniz bir şeyi sonraki sayfada başka türlü tarif ederseniz işi çıkmaza sokarsınız. Dilden dile dolaşan anonim türküler gibi herkesin birşeyler ekleyip çıkarttığı şartnamelerde, tutarsızlıklar ortaya çıkmaya başlar. Öte yandan teknoloji hızla ilerlediğinden, daha iki sene önce yazılmış bir teknik şartnamede kullanımları şart koşulan teknolojilerin çoğu bugün artık “demode” ya da “kabul edilemez” hale gelmiştir. Kopyalanan metinde bunu fark edip düzeltmeye kalkışan memur, –varsa- asıl metindeki tutarlılığı da iyice bozar. Neticede ortaya ihtiva ettiği tutarsız istekler yüzünden gerçekleştirilmesi “imkânsız” şartnamelerden bir tanesi daha çıkartılmış olur.
Analiz
Bilgi işlem çalışanları –tipik bir memur refleksi göstererek- üzerlerine düşen işi asgari seviyeye çekmeye çalışırlar. Proje süresince her aşamada işin içinde olmaları, işin ilerleyişini takip etmeleri, hatta işleyişe zaman zaman istikamet vermeleri gerektiği halde her işi yükleniciye yaptırmak temayülündedirler. Mesela her projenin başında yer alan “analiz” aşamasının tamamen yükleniciye bırakılması biraz da “biz ne istediğimiz tanımlayamıyoruz, önce bizim ne istediğimizi anlamak için bir çalışma yapın” demenin teknik şartname dilinde ifadesidir.
Kâinat Yönetim Sistemi
Türkiye’de yazılım danışmanlığı yaparak hayatını kazanan, yabancı uyruklu bir dostum vardı. Ülkemizdeki tecrübesini bana şöyle anlatmıştı:
Bir kamu kurumunuzla görüşme yaptığımda tam olarak ne istediklerini soruyorum, kabaca birşeyler söyleyip “detaylarını, sen analiz edip anlayacaksın” diyorlar. İşin ne zaman tamamlanmasını beklediklerini soruyorum, “dün” diyorlar! Ne kadar bütçeleri olduğunu soruyorum, “sen bu işi bedava yap, bize iş yapmak önemli bir referanstır” diyorlar. “Peki, hiç olmazsa isteklerinizi azıcık detaylandırın” diyorum, bakıyorum benden resmen “kâinat yönetim sistemi” üretmemi istiyorlar!
Bilişim sistemlerini bilim kurgu Hollywood filmlerinden tanıyan yöneticilerimizin beklentileri yükseliyor. Bilgi işlem personelinin, üzerlerine düşen her işi dışarıya ihale edip rahat etme düşüncesi de işin içine katılınca yukarıda bahsettiğim dostumun “kâinat yönetim sistemi” dediği ucubeler ortaya çıkıyor. Aslında ortaya konan istekler fikir planında çok da yapılamaz görünmüyor ama hakikat, pratikte başka türlü tezahür ediyor. Bir misalle izah etmeye çalışalım.
Mesela bir kurum, yemekhanesinde yemek yiyen personelini takip etmek, yediği yemeklerin ücretini doğru şekilde personelinden almak için bir proje yapıyor olsun. Aslında bunun için yemek alan her personelin işaretleneceği basit bir veritabanı uygulaması kâfidir. Fakat iş ihale edilmişken başka ne yaptırabiliriz diye düşünmeye başlayan memuru sınırlayan tek şey hayal gücüdür! Önce yemeğe gelen personeli programda işaretlemekten ibaret bir iş ile dahi uğraşmamak için otomatik turnike sistemi istenir. Turnikelerin çalışabilmesi için ya manyetik kartlara, ya jeton sistemine ihtiyaç doğar. Memurun hangisinin tercih edileceğini düşünüp kafasını yoracak hali yoktur. Şartnameye, yüklenicinin her iki alternatif için fiyat, performans ve risk analizi yapıp sunması şartı eklenir. Ödenecek ücret hesaplandığında her çalışandan teker teker tahsilatla kim uğraşacak? Hesaplanan ücretlerin maaştan otomatik mahsup edilmesi istenilir. Kuruma kapağı attığından beri meslekleri ile ilgili hiçbir şey yapmayan istatistikçilerin, endüstri mühendislerinin de bu vesileyle heyecanlandığını görürüz. Sipariş edilen yemek miktarının doğru hesaplanması için yemeğe gelecek kişi sayısının tahmin edilmesi gerekir. Bunun için kurumun seneler önce yaptırdığı, kör topal çalışan personel bilgi sistemine entegrasyon istenir. Böylece izinli, dışarıda görevlendirilmiş yahut raporlu personelin sayısına bakılarak sipariş verilecektir. Tedarikçilerin yönetilmesi için de bir modül olsa iyi olmaz mı? Şartnameye, çalışılan tedarikçilerle ilgili verilerin kaydedileceği bir modül eklenir. Nihayetinde yemek temini de bir satın alma sürecidir. Hemen bir “satın alma modülü” ilave edilir. İhalesiyle, kabulüyle, ödemesiyle tüm satın alma süreci elektronik ortama taşınsın istenir. Süreçte mecburen birçok resmi evrak üretildiğinden bir “elektronik belge yönetim sistemi” modülü olmazsa olmaz! Satın alma varsa ödeme vardır, para vardır. Para varsa muhasebe gerekir. Hemen şartnameye bir “muhasebe modülü” yerleştirilir. Bu modül kurumun ana muhasebe yazılımıyla da entegre olacaktır. Şartnamede bir cümle bu gerekliliği halleder. Tabi bu ölçekteki bir sistemde veri operatörü ihtiyacı doğmaktadır. Sistemin amirlerden ve memurlardan oluşan kullanıcıları olacaktır. Bu sefer hangi roldeki kullanıcının sisteme hangi yetkilerle erişeceğinin belirlendiği bir “kullanıcı yönetim modülüne” ihtiyaç doğmuştur. Yöneticinin bakacağı ekranlarla, sıradan kullanıcının ekranları da aynı olmayacaktır. Yöneticiler için özelleştirilebilir raporların alınabildiği bir “karar destek sistemi” şartnamede yerini hemencecik buluverir. Yemek taşıyan araçların, yemekhane personelinin, yemeklerdeki kalori miktarının takibi gibi her uçuk kaçık fikir bir modül olarak şartnameye yerleşir. İşte bir “kâinat yönetim sistemi” şartnamesi daha karşınızdadır!
Böyle “herşeyi” yapmaya kalkanların tek bir şeyi bile başaramadıkları defalarca ispatlanmış bir hakikattir. Tüm sistemler mümkün olduğunca küçük, atomik ama modüler tasarlanmalıdır. Bilişim projeleri mezarlığına dönen kamudaki başarısız projelere otopsi yapsak, birçoğunda kâinat yönetim sistemi virüsünün izlerine rastlayacağımız kesindir.
Hangi Teknoloji? Hangi Yazılım Dili? Hangi Veritabanı?
Hemen her kamu kurumunda bilgi işlem projelerinin başlangıcında artık baygınlık veren tartışmalar tekrarlanır. Acaba yazılım Java dilinde mi geliştirilmelidir yoksa “.Net” mi kullanılmalıdır? Açık kaynak kodlu ürünlerle mi yola çıkılmalıdır, lisanslı ürünler mi satın alınmalıdır? Oracle veritabanı mı tercih edilmelidir yoksa MySql yahut PostgreSQL yeterli midir?
Bütün bu tartışmalar anlamsızdır. Kamu kurumlarının bilgi işlem birimleri, üzerlerine vazife olmayan bir konuda zamanlarını harcamaktadırlar. Çoğu zaman, gelişen teknolojiyi takip konusunda başarısız olan, bilgilerini yenileyemeyen kamu bilgi işlem personelinden, profesyonellere yaptırılacak işin teknolojisi konusunda belirleyici olmalarını istemek de beklemek de doğru değildir. Bilgi işlem personeli, teknolojiye değil, yaptırılan işin neticesinde kurumun ihtiyaçlarının karşılanıp karşılanmadığına odaklanmalıdır. Hangi teknolojilerin, hangi mimarilerin, hangi donanımların, hangi yazılım kütüphanelerinin, hangi bilgisayar dillerinin kullanılacağı konusunda ise mutlaka profesyonellerden danışmanlık hizmeti alınmalıdır.
Twitter: https://twitter.com/salihcenap
Linkedin: https://www.linkedin.com/in/salihcenap
Türkçe karakter kullanılmayan ve büyük harflerle yazılmış yorumlar onaylanmamaktadır.