"Güncel Olmak" problemi

2003 yılının Nisan ayında, şimdi aktif olmayan Bilişim Cumhuriyeti’nde (www.bilisimcumhuriyeti.com) yayınlanan bir yazımda, CeBIT 2003’de görülen Linux patlamasına değinmiş ve yazıyı “…Tübitak öncülüğünde kurulacak 10-12 kişilik bir ekiple ulusal bir işletim sistemi geliştirilmesi…” yönündeki bir “dilek”le tamamlamıştım.  Bugün geldiğimiz noktada, halen o işletim sisteminin (Pardus) ilk sürümünü makineme indirmekle meşgul durumdayım ve bu durum son derece sevindirici.

(Tabi bunları yazarken sevgili Görkem Çetin ve şirketi Gelecek A.Ş.’nin son derece ciddi özveriler ve planlı çabaları ile meydana getirdikleri Gelecek Linux’u “ulusal değil” sınıflandırmasına yerleştirdiğim düşünülmesin lütfen. Ben de Dr.Karaman gibi sadece bir kulvar farkı görüyorum; ticari – kamusal. Üstelik Gelecek A.Ş. birkaç hafta önce pazara sürdüğü GEL 4.0 NG ve arkasına yerleştirdiği profesyonel destek paketleri ile tıpkı RedHat’in yaptığı gibi, kurumsal pazara giden yolda elini güçlendirdi, tebrikler.)

Yine aynı yazımda, Linux International’ın kurucusu ve Linux camiasının duayenlerinden John “Maddog” Hall ile yaptığım bir söyleşiye yer vermiş ve Linux’un yaygınlaşması yolunda işaret ettiği noktaları aktarmıştım. Maddog, Linux’a yatırım yapmak isteyen şirketlerin üniversiteler ile işbirliğine gitmesinin, üniversiteleri Linux ve açık kaynak temelli yazılımlar konusunda harekete geçirmelerinin önemini vurgulamıştı.

Tübitak harekete geçti, üniversitelerin de harekete geçmesi ile (ki bu hareket de özel üniversitelerin öncülüğünde başladı gibi görünüyor) Linux’u ve olanaklarını tanıyan, kullanan insanların sayısı ve sonuçta “yetişmiş işgücü”müz çoğalacak, halen kurumların Linux’u benimsemesi, en azından “kısmen” kullanmaya başlamaları için engellerden biri daha ortadan kalkacak ve sevgili Kemalettin’in ironik başlıklı (Linux mu? Kalsın) yazısında vurguladığı sorunları da beraberinde temizleyecektir..

Bu yazımda, söz konusu engellerden bir başkasını irdelemek istiyorum. Linux’a geçişin önündeki faktörlerden biri olarak Linux’un düzenli ve sürekli geliştirilmekte olması gösteriliyor (Linux dışındaki platformların neredeyse tümünde bu güncellemelerin sayısı ve frekansı hiç de azımsanacak ölçüde değildir). Linux çekirdeğinde (Kernel) veya GNU/Linux’un parçası olan uygulamalarda yapılacak güncellemelerin kurulu bir sisteme uygulanması sonrası çıkabilecek sorunlara dikkat çekiliyor.

Bu noktada Linux camiasına ciddi bir haksızlık yapıldığını düşünüyorum. Öncelikle her güncelleme ve yamanın derhal uygulanması gerekmeyebilir. Kaldı ki, bilgi işlem yöneticileri, hangi işletim sistemi olursa olsun yeni çıkmış bir “yama”yı, bir güncelleme veya yükseltimi hemen o anda tüm kullanıcıların sistemlerinde veya kurumun sunucularında uygulayamazlar.

Bilgi işlem yöneticileri var olan platformlarının test ortamlarında veya pilot cihazlarda gerekli güncellemeleri vb. uygular, komplikasyonları gözden geçirir, testler yapar ve konfigürasyonlarının olumsuz etkilenmediğini teyit ederler. Microsoft Windows platformu için bu işi yapan profesyonel kurumlar olduğu gibi Microsoft’un sunduğu SUS gibi araçlarla otomatik güncelleme işlemlerini kontrollü biçimde yapmak da mümkün. Benzer bir yaklaşım Linux platformu için de geçerlidir.

Kurulu Linux sistemlerini gelişmeler doğrultusunda güncellemek için sayıları giderek artan Linux uzmanlarının danışmanlığından veya spesifik Linux paketlerinin sunduğu otomatik güncelleme olanaklarından pekala yararlanılabilir, kurum içerisinde uzmanlık geliştirilebilir. Üstelik Linux çekirdeğinde ve paketlerde gerçekleştirilen bu düzenli ve sürekli güncellemeler olumsuz değil, olumlu algılanmalı ve yakından izlenmelidir.

Linux’a geçiş için çekinceleri bulunan kurumların, mevcut platformlarını tümüyle Linux’a taşıyabilecekleri veya her durumda taşımaları gerektiğini düşünmemekle birlikte bu doğrultuda var olduğu düşünülen engellerden birinin daha anlamını yitirdiğini söyleyebiliriz.

Hoşçakalın…

(Bu yazının aslı BTdünyası‘nda yayınlanmıştır.)

Hedef odaklı tedarikçi yönetimi

Daha önceki yazılarımda değindiğim üzere, hem “müşteri” tarafının hem de “tedarikçi” tarafının Dış Kaynak Kullanım (DKK) projelerinden olası en yüksek verimi elde etmeleri ve bir “kazan-kazan” durumunun gerçekleşmesi, büyük ölçüde her iki tarafın beklentilerini ve hedeflerini netleştirmelerine bağlı.

Bu bağlamda açmak istediğim başlıklardan biri, bilişim DKK projeleri özelinde “tedarikçi yönetimi”.

Kurum belirli bir nedenle DKK’na karar vermiş ve uygulamaya almış olabilir. Birçok projede –eğer varsa- bilgi işlem yöneticileri, sürecin aktif birer üyesi olarak baştan sona dek, tedarikçi seçimini de içerecek bir rol oynarken kimi örneklerde sürecin dışında tutulup yalnızca sonuçlarından haberdar edilebiliyorlar.

İkinci durumda hem bilgi işlem yöneticisi hem de tedarikçi maça 1-0 yenik başlıyor! İş böyle başlayınca da ilişki geliştirmek ve başarılı bir DKK projesi ortaya çıkarmak son derece güç olabiliyor.

İlk örnekte ise, müşteri-tedarikçi taraflarının birbirlerini, beklentilerini ve hedeflerini daha iyi tanımış ve anlamış olmaları beklenebilir. Bu durumda, ortaya çıkacak projenin sorunsuz yürüme olasılığı yüksektir.

DKK projesine “yürü” denmesi ile birlikte bilgi işlem yöneticisi ve tedarikçi ilişkisi başlar ve her nasıl başlarsa başlasın, şirket yöneticileri veya sahipleri sonucun hedefledikleri gibi olmasını bekler. Bu beklentiyi gerçekleyecek olan anahtar ekip de –genellikle- müşterinin bilgi işlem departmanıdır.

Her durumda bilgi işlem yönetimi, tedarikçisinin kapasite ve yeteneklerini “deneme-yanılma” mantığı içerisinde öğrenmeye değil, onu yönetmeye çalışmalıdır. Bu çalışma, DKK projesini başarıya götürecek bir unsur olmasının yanında pürüzlerin aşılmasını da hızlandıracaktır.

Bununla birlikte, iyi bir DKK tedarikçisi, müşterisinin hedeflerini anlamaya ve gerçeklemeye çabalarken bunlara paralel olarak bilgi işlem departmanının beklentilerini, olası endişelerini ve hedeflerini de algılamak ve tümünün idaresini bir arada sürdürmek durumundadır. Bu doğrultuda hareket eden bir tedarikçi ile çalışıyorsanız işinize yoğunlaşmanız kolaylaşacaktır.

Müşteri tarafındaki proje sahiplerinin (yukarıda söz ettiğimiz gibi genelde bilgi işlem yönetiminin), tedarikçi ilişkisini sağlıklı olarak sürdürebilmeleri (ve DKK projesini başarıyla hayata geçirebilmeleri) için üzerinde durulması gereken kritik noktalar mevcuttur. Bunlar genel yönetim becerileri olmayıp, spesifik bir DKK projesine ait konular olarak ele alınmalıdır;

• Yönetmeniz gereken alanı daraltın:
o Eğer bir DKK projesinde, birden fazla tedarikçi ile çalışıyorsanız ve içlerinden biri ana tedarikçi sıfatıyla hareket ediyor ise, diğer tedarikçilerle olan ilişkileri birebir sürdürmeyip ana tedarikçiye bırakın. Böylelikle hem gereksiz yönetim eforu sarfetmemiş hem de çakışmaları asgariye indirmiş olursunuz.
o Ana tedarikçinizin, DKK projeniz için atadığı mevkidaşınızı veya teknik sorumluyu (proje kapsamında sizinle birlikte hareket edecek kişi; genellikle proje yöneticisi) tanıyın ve onunla çalışın. Öncelikle, DKK projesinin satış safhalarında tanıştığınız kişilerle değil, projeyi sürdürecek olan kişilerle haberleşmeyi tercih edin. Pürüzleri çözmeniz ve süreçleri eniyilemeniz böylelikle mümkün olur.
o Tedarikçinizin proje yönetimi ile mutabık kalmadığınız sürece teknik kadroları ile birebir temas etmekten kaçının. Geliştireceğiniz ilişkiler başlangıçta “kısayol” gibi görünebilir ancak zaman içerisinde gereksiz yükler üstlenmeye başladığınızı fark edebilirsiniz.
• Tedarikçiniz tarafından hazırlanacak proje planlarını izlemeniz gelişmeler hakkında soru sorabilmenizi sağlar. Projenin yapısı gereği net bir planlama söz konusu değil ise en azından görev adımlarının yerine getirilip getirilmediğini takip edebilisiniz.
• İletişimden kaçınmayın (e.posta herşey değildir!) Bir iletişim planınız olur ise hangi durumda kiminle ne şekilde haberleşeceğinizi bilirsiniz ve gerektiğinde çözüme daha hızlı ulaşırsınız.
• Düzenli ve etkin değerlendirme toplantıları yaparak veya tedarikçiniz tarafından düzenlenecek toplantılara katılarak, soru işaretlerinizi açıklığa kavuşturabilirsiniz.
• Şeytanın detaylarda gizli olduğu söylenir! Proje sonuçlarını ve dönemsel durum raporlarını takip ettiğinizde gözden kaçma olasılığı bulunan konuları yakalayıp üzerine gidebilirsiniz.
• Tedarikçiniz, benzer projeleri defalarca kez gerçekleştirmiş olabilir. Böyle bir durumda dahi herkesin kendi paraşütünden sorumlu olduğunu bilerek paraşütünüzün zamanında “açılacağından” emin olmaya çalışın.
• Tedarikçinizin sizden yanıt/onay beklediği konuları mümkün olduğunca hızlı değerlendirmeye gayret edin. İnisiyatif kullanabildiğiniz noktalarda kullanmaktan kaçınmayın.

Tedarikçiniz, işe başladıktan sonra artık bir “satıcı” değil, sizin iş ortağınızdır. Bunu bir kenarda tutarak, projenizin, yönetilmesi gereken bir unsuru olan zaman çizelgesine uygunluğunu da denetim altında tutmaya çalışın. Ancak kimi durumlarda rasyonel nedenlere dayalı ve “işin” sağlıklı başlamasına etki edebilecek “pozitif” gecikmelerde üst yönetiminize karşı tedarikçiniz ile birlikte hareket etmeniz gerekebilir.

Heisenberg’in Belirsizlik İlkesi atom altı parçacıklar için “…hızı ne kadar hassas ölçerseniz pozisyonu belirlemek de o denli zorlaşır…” der. Aynı cümleyi proje yönetimine uygulayabiliriz: “…proje zamanlamasına ne kadar hassasiyet gösterirseniz kaliteyi tutturmak o denli zorlaşır…” (uzun soluklu DKK projelerinin aktivasyon süresinde esnek olabilmek genellikle iyi bir pratiktir.)

Hoşçakalın…

(bu yazımın aslı BTdünyası‘nda yayınlanmıştır.)