En "Kaliteli" Proje!

Zaman, maliyet ve kalite. Proje Yönetiminin olmazsa olmaz üçlüsü. Bunları bir denge içinde götüremediğimizde bazen biri bazen tümü birden olumsuz yönde gelişme eğilimi gösterebiliyorlar.

Projelerde “kalite” kavramı, son yılların modası olarak -son derece yanlış bir biçimde- içeriğini tam anlamıyla kavramak ve uygulamaktan uzak şekilde pazarlama unsuru olarak rağbet gören ISO-xxxx ve benzeri sistemlerin anlattığından biraz daha farklı.

Özellikle dış projelerde kalite kavramı, doğrudan doğruya müşteri memnuniyeti ve müşteri sadakati ile neredeyse eş anlamlı. Projenin kalitesinden söz ederken aslında müşteri memnuniyetini sağlama düzeyinden söz etmeliyiz.

Müşteri memnuniyeti, işin sonuçları açısından bakıldığında tek başına proje kalitesinin ve aslında proje hedeflerinin önemli unsurlarını içeriyor gerçekten de:

* Projenin bütçesinde tamamlanması
* Projenin zamanında tamamlanması
* Projenin beklenen çıktıları -fazlasıyla- üretmesi
* Operasyonel süreç -eğer varsa- boyunca elde edilen performans

Bir müşteri temsilcisinin veya satış yöneticisinin öncelikleri yukarıdaki müşteri beklentileri ile örtüşmekte iken proje yönetimi perspektifinden bakıldığında durum biraz daha karmaşık olabilir, hatta olmalıdır. Dikkat edildiğinde, yukarıda sayılan unsurların aslında projenin, “sonuçları” ile ilgili olduğu görülüyor. Bununla birlikte proje sürecinin kendisi de, kurumun standartları çerçevesinde ayrı bir kalite bileşenidir:

* Proje gerçekleştirilirken kurumun planlama ve belgelendirme standartları gözetildi mi ?
* Proje yönetim disiplininin gerektirdiği araçlar ve metodlar uygulandı mı ?
* Karşılaşılan sorunların nedenleri araştırılıp kalıcı çözüm sağlandı mı ?
* Planlamaya uygunluk ne derecede sağlandı ?

Bu saptamaları ve ayırımı yapmak işin sonucu açısından önemli ancak yeterli değil. Ele almamız gereken konu, proje yönetimi, proje planlaması yaparken yukarıdaki sonuçlara ulaşmayı garanti edecek çalışmalar olmalı.

Son derece basit araçlar yardımıyla bir projenin memnun edici sonuçlara ulaşma olasılığı ve kurumun benimsediği proje yönetim metodolojisine uygun yürütülmesi denetim altında tutulabilir.

Kalite planının değil kendisi telaffuzu bile birçok proje yöneticisi için angarya gibi görünebilir. Özellikle hiç kalite planı yapmamış ve işe yararlığını sınamamış ise. Sonuçta, “ben projeyi planına uygun olarak yürütürsem zaten sorun çıkmaz.” mantığı daha hakimdir.

Kalite planı, isminin çağrıştırdığı veya bazı metodolojilerin “dayattığı” gibi karmaşık ve kullanışsız bir “zorunlu” belge olmak durumunda değildir.

Tıpkı projenin çıktıları gibi, kalite planı da iki türlü olabilir; iyi tasarlanmış ancak işlemeyen, kötü tasarlanmış ancak çalışan. Önemli olan tabii ki iyi tasarlanmış ve iyi çalışanı elde etmek. Bu amaçla kalite planı yapılırken hedefe götürecek bir biçem ve içerik seçimi yararlı olacaktır.

Kalite, somut bir nesne olmadığı için ilk anda kağıda dökülmesi zor görünebiliyor. Onu somutlaştıran kalite planıdır. Kalite planı, “kalite” kavramını oluşturan bileşenleri tanımlar ve kontrol yöntemlerini içerir.

Örneklemek gerekirse; kurum içi bir sunucu değişikliği projesini ele alalım. Hedef daha stabil ve sorunsuz çalışan, işletim maliyeti daha düşük olan, yeni donanımlar üzerinde yeni bir işletim sistemi platformuna geçmek olsun (hangi işletim sisteminden hangisine geçtiğimizi hayalgücünüze bırakıyorum 🙂

Projeden beklentilerimizi sıralayalım;

* Yeni platforma geçildikten sonra kesinti olmaması
* Tüm verilerin yeni ortama transfer edilmiş olması
* Kullanıcıların uygulamalara erişiminin sorunsuz olması
* …

Proje zaman planlaması tek başına yukarıdaki sonuçlara ulaşmayı garanti etmez. Hangi görevlerin ne zaman, kim ve ne kadar sürede yapılması gerektiğini tanımlayabilirsiniz. Ancak olumsuz senaryolar, birbirini izlemesi gereken görevlerin aksaması gibi durumlarda ne yapacağınızı bilmeniz gerekir ve bunu zaman planı ile de ilişkilendirebilirsiniz:

Yeni Donanım Seçimi -> Uzman Görüşü -> Tedarikçi Seçimi -> Alternatifler -> Test prosedürlerinin varlığı -> Uygulama denetimi

Sadece yeni donanım seçim fazına ait son derece basit görünen bir dizi eylemi yan yana yazdık. Anahtar sözcük yazılı hale getirmek, planlamak. Yukarıdaki basit diziyi bir kalite planının parçaları olarak görebilirsiniz.

Yeni donanım tedariki öncesi bir uzmanın önerisini aldık mı ? Tedarikçimize alternatif var mı ? Ürünün, doğru ürün olduğunu ve bizim işimize uygun olduğunu kontrol edecek süreçlerimiz tanımlı mı ? Bunları denetledik mi ?

Her bir proje fazı için benzer bir çalışma yapıldığında en basit haliyle bir kalite planınız var demektir. Eğer bir metodoloji kullanıyorsanız, metodolojinizin öngördüğü kalite plan şablonlarına bir de bu gözle bakın -ve mümkünse onları kullanın…

Hoşçakalın…

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

AB Sürecinde Tehditler, Fırsatlar

Proje yönetimi konusuna bir ara verip, Avrupa Birliği sürecinde geldiğimiz nokta, bu sürecin ülkemiz ve sektörümüz özelinde getirecekleri (ve götürebilecekleri!) hakkındaki kişisel yorumlarımı çok kısaca sizlerle paylaşmak istiyorum.

3 Ekim’de (Emre Kongar hocamız gibi ben de tarih fetişizmine karşıyım ama girilen yolu tanımlamak açısından kullanmayı uygun buluyorum) verilen karar, ülkemizin gelecekteki durumu açısından son derece kritik öneme sahip. Ancak burada “önem” sözcüğünü “kesin gerekliydi, çok iyi oldu.” anlamında değil, sadece bizi son derece ciddi gelişmelerin, değişikliklerin beklediğini vurgulayabilmek için kullanıyorum.

Avrupa Birliğine mutlak karşıt veya mutlak yandaş bir yorum getirmek düşüncesinde değilim. Ayrıca AB üyeliğine karşı olanların büyükçe bir kısmının, neye, kime karşı olduklarını da anlayabilmiş değilim. Karşı olmak beraberinde somut ve genel kabul görebilecek alternatifleri getirmeli diye düşünüyorum.

3 Ekim sürecinde -ki bu süreç en azından bir on yıl kadar alacak gibi görünüyor- tehditler ve fırsatları bir arada görmek mümkün. Algılanan tehditler açıkça ortada ve genellikle Cumhuriyetimizin bütünlüğüne yönelik. Bu bakımdan, AB karşıtlarının endişelerini derinden paylaşıyorum.

Bazı AB yetkililerinin “Kemalizmden vazgeçin”, “Soykırımı tanıyın, tazminat (toprak!) verin”, “Güneydoğuda federatif çözümü gündeme getirin” tarzındaki cümlelerini tüylerim diken diken olarak dehşet içinde okuyorum! Türkiye’yi Türkiye yapan değerleri kaşıyarak kanatmaya çalıştıklarını, tarihimizi bize unutturmak gayretinde olduklarını düşünmeye başlıyorum.

Aynı kişilerin Türkiye’ye geldiklerinde ayaklarının tozuyla, özellikle ve öncelikle Diyarbakır ilimizi ziyaret etmelerini de son derece “ilginç” buluyorum (bu işi bir gezi planı çerçevesinde yapıyor olsalar Diyarbakır’ın muhteşem tarihi güzelliklerini görmeye gidiyorlar diye düşünebilirdik…)

Akla ilk gelen fikir doğal olarak şu; emperyal (yayılmacı) devletler geçmişte savaşla yapamadıklarını bugün politik ve ekonomik yoldan mı yapmaya çalışıyorlar ? Türkiye’nin süregiden AB hikayesi, çok daha büyük bir planın küçük bir parçası olabilir mi ? Şu ana dek verdiğimiz ve vermeye devam edecekmişiz gibi görünen ödünlerin sonu nereye varacak ? Acaba kaynaklarımız bizlerin denetiminden çıkacak mı ?

Bunlar özgün değil, her birimizin aklına gelebilecek düşünceler. Mesele, bu olasılıkları göz ardı etmeden ilerlemek ve her tokalaşmanın ardından “parmaklarımızı saymak” (sanıyorum Genelkurmay İkinci Başkanı Org. İlker Başbuğ’un sözüydü bu ?)

Çok net görülemeyen diğer bir tehdit unsuru da toplumsal yaşantımıza yönelik. Dini konulardan bağımsız, yaşam tarzı olarak yakın olduğumuz birkaç Avrupa ülkesi (Yunanistan, İspanya, İtalya…) dışında diğerleri ile toplumsal yaşantı anlamında ortak noktalar bulmamız neredeyse imkansız. Bu çerçevede dayatılacak olan toplumsal kurallar bizlere “uymayabilir”. Nitekim yukarıda saydığım ülkeler de bu alanda zorluklar yaşadılar ve yaşıyorlar.

İş dünyası da sorunlar yaşayacak. Yeni kanunlar, yönetmelikler, prosedürler tüm yerli işletmeleri zorlayacak. Geniş kapsamlı dönüşümler yaşaması gereken kurumların bir kısmı belki de bu geçişi atlatamayacak ve oyun dışı kalacak. Örneğin tarım sektörünün yaşayacağı sorunlar, baskılar daha şimdiden kendini göstermeye başladı.

Gelelim fırsatlara… Beklenenin aksine, kalifiye Türk işgücünün kısmi serbest dolaşımının üyelik öncesi bir dönemde gündeme gelebileceği kanısındayım. AB ülkelerinin azalan nüfusları, yükselen -kalifiye- işçilik maliyetleri bunu zorunlu kılıyor olacak. Avrupalıların “Türkler geliyor!” korkularının kısa zamanda rafa kalkacağını düşünüyorum. Bu durum AB ülkeleri ve Türkiye arasında iyice açılmış olan ücret skalalarını Türk çalışanlar lehine “düzeltecek” (iş dünyasını zorlayacak bir diğer gelişme olarak da görülebilir bu durum.)

Bilişim sektörü ve bilişim çalışanları (yöneticiler, uzmanlar…) için son derece açık fırsatlar görüyorum. Herşeyden önce; artan rekabet baskısı bilgisayarlaşmayı da artıracak. Bilgisayarlaşmanın artması, hem donanımcı, hem yazılımcı hem de entegratör şirketleri canlandıracak. Kurumsal dönüşümler bağlamında, bilişim uzmanlarına ve danışmanlara olan ihtiyaç giderek daha çok hissedilir olacak.

Bilişim şirketlerinin hedef pazarları da bir anda genişleyerek tüm AB ülkelerini içerir hale gelecek. Uzakdoğu ile doğal bir coğrafi köprü olan ülkemizdeki büyük dağıtım şirketlerinin Avrupa ülkelerini birer sevkiyat noktası haline getirmesi hayal değil (geçmişte tersini yaşadık bunun). Aynı şekilde, Avrupa’daki emsalleriyle rekabet edebilecek kurumsal kaynak planlama yazılımlarımızı bizim uzmanlarımız Avrupa şirketleri bünyesinde uyarlıyor olacaklar. İnternet’in gücünü arkasına alan yaratıcı insanlarımızın AB’ye ihracat hamlesi başlatacak uygulamalar geliştirmesi de çok uzak ihtimal değil…

Tüm bunlar olası üyelik öncesinde gündeme gelebilecek şeyler. Avrupa sanayi ve ekonomi devlerinin Türkiye’ye olan ilgisi ve yatırımlarının patlama şeklinde artacağını, bu yatırımların içerideki ekonomiyi de canlandıracağını öngörmek için kahin olmak gerekmiyor. Türkiye’nin tam üyeliğine yüksek ihtimal veren ve erken kalkan yol alır hesabına gidenler şimdiden ülkemize akın etmeye başladı bile. Ancak bu noktada parayı bastırana tarlasını satıpta, bu yabancılar da nereden çıktı diye dert yanan köylünün durumuna düşmemek için uyanık olmak ve ulusal duruşumuzu, sınırlarımızı netleştirmek gereğinin de altını çizmek istiyorum.

Hoşçakalın…

Projelerde Zaman Kontrolü

Zaman yönetimi prensipleri, Proje Yönetim disiplininden bağımsız olarak her birimizin günlük iş ve özel yaşantımızda dikkate almamız gereken son derece yararlı “araçlar”. Zaman planlaması başlı başına bir eğitim programı olabilecek kadar geniş kapsamlı.

Bu yazıda kısaca incelemeye çalışacağımız konu ise projelerde zamanın kontrolü, yönetimi konusundaki durumsal yaklaşımlar.

Herhangi bir işi projelendirmenin amaçlarından biri de zaman kısıt(lar)ına karşı verilecek “mücadeleyi” detaylandırmaktır. Bu kısıt(lar) birkaç koşulda, farklı biçimlerde ortaya çıkabilir.

Bizim amacımız aşağıda birkaçı listelenen farklı koşullar çerçevesinde proje yöneticisinin dikkatini yoğunlaştıracağı kontrol noktalarının altını çizmek;

1) Projenin başlangıç zamanı belirli, süresi belirsizdir.
2) Projenin hem başlangıç zamanı hem de süresi belirlidir.
3) Projenin bitiş zamanı (“deadline”) belirli, süresi belirsizdir.
4) Projenin tamamlanma süresi belirlidir.

Yukarıdaki durumların her biri farklı zaman kontrol yaklaşımlarını da beraberinde getirmelidir. Birinci duruma sıklıkla rastlanmamakla birlikte yazılım projelerinin veya kurum içi projelerin bir çoğunda fiili olarak meydana gelen durumdur (hiçbir proje “bitmemek” veya “uzamak” üzere başlamaz tabi. Onun için “fiili” sözcüğünü kullandım.)

Böyle projelerin zaman planlamasını yaparken her bir proje adımını (görevi) tanımlamak ve alacağı zamanı detaylandırmaya çalışmak son derece yararlı bir pratiktir. Proje yöneticisinin yalnızca bölüm yöneticileriyle değil, doğrudan iş başında olacak teknik ekiple birebir yapacağı çalışmalar, her bir görev için gerekecek sürenin belirlenmesinde yardımcı olabilir.

Böylesi detaylı bir çalışma, projenin en azından istenen zamanda tamamlanmasına yardımcı olmasının yanında, zamana bağlı maliyetlerin kontrol altında tutulması için de son derece kritiktir. Tersi durumda projenin tamamlanabilirliği dahi risk altında demektir.

İkinci duruma dış (müşteri) projelerde sıklıkla rastlıyoruz (olması gerektiği gibi). Proje takımına, belirli kilometre taşlarında (“milestone”) kontrol edilen zaman odaklı “hedefler” koymak önemli bir zaman kontrol aracıdır. Zaman burada projenin en önemli parametrelerinden biridir.

Bu tür projeler için her bir görevin alacağı süreyi detaylandırmak yerine tamamlanma yüzdeleri şeklinde, kilometre taşlarının izlenmesi daha anlamlı olabilir. Beklenen zamandan daha geç ulaşılan ilk kilometre taşı, proje yönetiminin alarm zillerini çaldırmalı, proje sponsorları derhal haberdar edilmeli ve sapmaların nedenleri araştırılmalıdır. Böylesi bir durumda ya projenin zaman planı yeniden düzenlenir ya da sonraki hedeflere daha hızlı ulaşacak düzenlemeler yapılır.

Burada özellikle kritik yol (“critical path”) üzerinde bulunan görevlerin, yani sürelerinde ya da başlangıç bitiş zamanlarında yapılacak değişikliklerin tüm projeyi etkileyeceği görevlerin daha yakından ve periyodik olarak (mümkün ise günlük) izlenmesi önerilir.

Üçüncü durumda yer alan projeler genellikle iç projeler, dış kaynak kullanım projeleri veya arge projeleridir. Belirli bir tarihe yönelik konulan tamamlanma hedefine (“deadline”) ulaşabilmek konusunda proje yöneticisinin yeterli zamanı varmış gibi görünür.

Bu durum aldatıcı olabilir. Proje bitiş tarihi baz alınarak planlama yapılmaya başlandığında geriye doğru gidilerek proje için bir başlangıç tarihi belirlenir. Bu başlangıç tarihi, gerçekte olması gerekenden ileri bir tarihe rastlıyor olabilir. Diğer görevlerden bağımsız yürüyebilecek görevlerin olabildiğince erken zamanlarda tamamlanması ve eğer varsa başlangıca kalan sürenin proje ekipleri ile müzakere edilerek planlama detaylarına ayrılması isabetli olur.

Ancak bazı görevler bağımsız görünseler bile proje aktivasyon fazının erken zamanlarında yapılmaları yarar sağlamayabilir. Özellikle dış kaynak kullanım projelerinde, projede görev alacak teknik ekibin erken bir dönemde eğitimden geçirilmesi, aktivasyondan operasyona dek geçecek sürede kazanılan spesifik bilgilerin “unutulmasına” yol açabilir.

Dördüncü duruma, kaynaklara bağımlılığın üst düzeyde olduğu projelerde, nadiren rastlanır. Özellikle pahalı kaynakların en uygun tarihlerde kullanılması açısından proje yöneticisine (ve proje sponsoruna) esneklik sağlanmış olur. Başlangıç ve bitiş tarihleri genellikle kaynakların en uyguna sağlanabildiği veya atıl olduğu dönemlere getirilir.

Sonraki yazımda, “kalite” kavramının proje yönetim disiplinindeki yeri ve yönetimini ele alacağım.

Hoşçakalın…

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

Travma'nın ilacı organizasyonel değişim

Merhaba,

Dış kaynak kullanım (DKK) projelerini (sadece bilişim değil, her alandaki) hayata geçiren kurumların atlatmak zorunda oldukları bazı “travma”lar var.

Bunlardan biri de; var olan ve dış kaynak kullanım projesinden etkilenen bölüm, grup veya kişilerin yeni “gerçeklik” etrafında nasıl yapılanacakları ve organizasyonel hiyerarşilerinin ne derece veya biçimde etkileneceği konusu.

Kurumların, organizasyonel travmaları hangi hasar derecesinde atlatacakları –ki bunlar da sadece DKK projeleri sonucunda değil, yeniden yapılanma çabaları sırasında da oluşabilirler- tamamıyla yöneticilerin yaklaşımlarına, stratejilerine ve uygulayacakları taktiklere bağlıdır.

DKK projeleri genellikle organizasyonel değişiklikleri zorunlu kılsa da bunlar çoğunlukla “olumsuz” yönde gerçekleşmiyor. Üst yönetimlerin yaklaşımlarına bağlı olmakla birlikte; bu tür projeleri hayata geçiren kurumların birçoğunun deneyimli çalışanlarının istihdamını sürdürdüğü ve onlara farklı olanaklar sağlayarak deneyimlerini kurumun ihtiyaçları doğrultusunda “değer”e çevirdiğini görüyoruz.

Değişimlerin sosyal etkilerini mümkün olduğunca hafif tutmak veya en azından bu etkileri göz ardı etmeden hareket etmek son derece iyi bir pratik olabilir. Ancak bu doğrultuda atılan –iyi niyetli- adımlarda sorun yaratabilen uygulama örneklerine de rastlamak mümkün olabiliyor.

Bu örneklerin başında, DKK’dan etkilenen tüm bir kadroyu, mevcut hiyerarşileri ve görev tanımları çerçevesinde aynı organizasyonel bünye içerisinde bir arada tutmak yer alıyor. Bu tür örneklerde DKK hedefinin kadrolu personel sayısını azaltmak olmadığı, etkinliği ve verimliliği artırmak olduğu düşünülebilir.

Yönetimlerin, süreç içerisinde gözden kaçırma eğiliminde olduğu konuların başında, tüm DKK projelerinin temelinde yer alan “işi daha … yapmak” (noktaların yerine “iyi”, “ucuz”, “verimli” vb. sözcüklerden birini yerleştirebilirsiniz…) hedefinin, DKK tedarikçisi olarak seçtikleri firmanın deneyim ve yetenekleri üzerine yerleştiğidir.

Son derece profesyonelce iş yapan, karlı, başarılı bir işletme veya bölüm yürütüyor olsanız da, daha önceki yazılarda tanımını tartıştığımız “çekirdek” işiniz dışında kalan (ve DKK satıcılarının doğal hedefi olan) konularda “daha …” olmanız pek olası değildir (ayrıca olmaya çalışmanın gerekliliği de tartışılır.)

DKK arayışına girişmenin başlangıç noktasını teşkil eden bu basit gerçek, bir kez DKK’na karar verilip uygulamaya başlandıktan sonra kolayca göz ardı edilebiliyor. Yukarıda sözünü ettiğimiz gibi, özellikle mevcut organizasyonun yerini koruduğu durumlarda DKK tedarikçisi ve daha önce onun görevlerini yerine getiren kurum içi grupların çatışması neredeyse kaçınılmaz hale geliyor.

Çatışmalar, iş yapış biçimlerinin farklılığı (“eskiden böyle yapmıyorduk!”), kurum kültürlerinin farklılığı gibi nedenlerden kaynaklanabilir. Bu çatışmalar, özellikle projelerin başlangıç süreçlerinde karşılaşılan uyum problemleri ile tetiklenir ve büyür.

DKK’dan etkilenen bölümlerin yöneticileri (ki bilişim projeleri özelinde genellikle bilgi işlem yöneticileri) için bu çatışmalar üst yönetimler nezdinde çoğu kez birer başarısızlık ve uyumsuzluk ifadesi olarak görülürler ve bu nedenle de mümkün olduğunca önlenmelerinde yarar vardır. Çalışanlarınızı, tedarikçiniz ile işbirliğine zorlamanız olası değildir. İşbirliği, zorlama olmaksızın ortak hedefler etrafında çalışarak, net görev tanımları çerçevesinde gelişebilir. Tarafların birbirlerinin ayaklarına basmayacakları düzenlemeleri yapmak da yöneticiye kalıyor.

Çatışmaların önüne geçmek, eski organizasyon yapısının yeniden düzenlenmesi ile mümkün olabilir. Tedarikçiniz ile aynı işleri yapmaya devam eden çalışanlarınıza, tedarikçinizin sorumluluk alanı dışında kalan farklı görevler atayabilirsiniz. Bazı çalışanlarınız için değişik yöntemler benimsemelisiniz. Örneğin, iş devri nedeniyle tedarikçiniz ile yakın çalışmak durumunda bulunan ekip üyeleriniz, devir sonrası için planlanan kariyer patikaları hakkında bilgilendirilebilir. Böylelikle çalışanınız, tedarikçiniz ile işbirliği konusunda –en azından eskisine göre- daha istekli olacaktır.

Organizasyonel yapılarda bir başka dönüşüm şekli, belirli çalışanlarınızı tedarikçinizin faaliyetlerini raporlamaktan sorumlu kılmak veya tam tersi çalışanlarınızın, fonksiyonel açıdan tedarikçinize bağlı olarak işlerini sürdürmesini sağlamaktır. Bu son duruma çok sık rastlanmamakla birlikte başarılı örnekleri görülüyor.

DKK sonrası organizasyonel değişimlerin belki de en can acıtıcı olanı hiyerarşik düzenlemelerde yaşanıyor. Kurum bünyesinde, belirli bir grubun, bölümün yönetimini üstlenmiş çalışanların yönetim alanlarını yitirmeleri kişisel kaygılarını artıracak ve bir başka çatışmayı tetikleyebilecektir.

Kurumlarımızda fazla örneğini görmediğimiz bir uygulama ile bu sorunu da kolayca aşmak mümkün. Dikey hareket olanağı kısıtlanmış veya geri adım atmak zorunda kalmış yetenekli çalışanlarınız için yatay hareket olanakları yaratabilir, yönetsel seviyede ücretlendirme ve yöneticilerin sahip olduğu manfaatlerden yararlanmalarını sağlayabilirseniz, etki alanı kayıbının sonuçlarını asgariye indirgeyebilirsiniz.

Hoşçakalın…

(Bu yazı BTdünyası için hazırlanmış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.)

Proje yönetiminde; zaman, kalite ve maliyet

Proje yönetiminin birkaç “olmazsa olmaz” kuralı vardır. Bunların başında da zaman-kalite-maliyet üçgenini dengede tutabilmek gelir. Üç bileşenin işleyiş mekanizmaları, birbirlerine etkileri doğru kavrandığında hem proje yönetimini yürütenler hem de proje sahipleri arasındaki çatışmaların önlenebilmesi beklenir.

Bir projenin hayata geçirilmesi (gerçekleştirimi) sırasında söz konusu üç unsurun (zaman, kalite ve maliyet) her zaman için planladığı şekilde yönetilmesi mümkün olmayabilir.

Zamanında tamamlanamayan proje adımları (görevler), özellikle de “kritik yol” adı verilen ve proje toplam süresini doğrudan etkileyen işler çizelgesi üzerinde iseler projenin belirlenen zamanda bitirilmesi olanaksızlaşabilir.

Proje yönetim felsefesini hicvetmek için söylenen “Bir bebeği 9 ayrı kadın 1 ayda dünyaya getirebilir.” espirisinde altı çizildiği gibi, bazı görevleri kaynak çoğaltımı yoluyla daha kısa sürede tamamlamak olanaksızdır. Bu tür görevleri zamanında bitirmenin yolu kaliteden ödün vermek gibi görünebilir.

Kalite kavramı, proje yönetiminin geçmiş dönemlerinde zaman ve maliyet unsurlarının yanında daha geri planda, ikincil öneme sahip iken son yıllarda en az diğer iki unsur kadar ilgi çekmeye başladı.

Kaliteden fedakarlık yapmanızı gerektiren durumların yanında, kaliteyi beklentinin üzerine çıkarmanız gereken veya istemeden de olsa çıkardığınız durumlar da yaşanacaktır. Kalite- maliyet ilişkisi genellikle doğrusal ve eş yönlüdür. Kaliteyi artırırken maliyetiniz artar, kaliteden ödün verirken maliyetiniz azalır (veya azalması beklenir.)

Zaman-kalite arasındaki ilişkide, zamanın “bollaşması” veya en azından plana uygun kullanılabilmesi durumunda kalite planlarının sorunsuz yürümesi beklenir. Tersine, zamanın daralması (ötelenen işler!) yine kaliteden taviz anlamını taşır.

Zaman ve Maliyet ilişkisi,diğer bağıntılardan çok daha fazla doğrusallık taşır. Zamanın uzaması, birçok proje için doğrudan para kayıbı anlamına gelir. Bu kayıp kimi zaman projenin tamamlanması ardından beklenen gelirin zaman maliyeti olabileceği gibi proje gerçekleştirim maliyetlerinin zamana bağlı yükselişi ile de oluşabilir.

Maliyet yapısının değişimi (artan ücretler, kur dalgalanmaları, değişen faiz oranları) özellikle dış finansman gerektiren projelerin hayatı üzerinde çarpıcı etkiye sahiptir. Bir kaynağın maliyetindeki ani yükselme, zamanı uzatarak veya alternatif -düşük maliyetli- kaynaklar kullanarak tolere edilebilir. Ya da proje bütçesi revize edilebilir (tabii ki proje sahiplerinin onayı ile.)

Yukarıdaki “tablo” bize şunu söylüyor; eğer bir diğeri, planlı biçimde değiştirilemiyorsa, üç proje unsuru arasındaki “takas”ın mutlaka bir maliyeti olacaktır. Örneğin, zaman uzarken, uzayan zamanı tolere edebilecek bütçe revizyonlarını yapamıyorsanız maliyetleriniz artacak ve/veya kaliteden ödün vermek zorunda kalacaksınız. Kalitenin artırılması gerekiyorsa yine zaman ve/veya maliyet bileşenlerini yeniden planlamak durumundasınız.

Herhangi bir projenin uygulayacısı değil, sahibi, müşterisi durumundaysanız da yukarıdaki unsurları dikkatle kontrol altında tutmak zorundasınız. Önümüzdeki yazılarda, her bir bileşenin yaratacağı etkileri bağımsız olarak ele almaya ve kontrol yöntemlerini, araçlarını detaylandırmaya çalışacağım.

Hoşçakalın…

Verimerkezleri ve Dış Kaynak Kullanımı

Birkaç yıl önce konuk yazar sıfatıyla IBM’in Çözüm dergisinde yayınlanan bir yazımda, İnternet’in gelişimi paralelinde merkezi bilgi işlemin geri dönmekte olduğunu, dolayısı ile istemci-sunucu (client-server) mimarinin ikinci plana düşeceği günlerin yaklaşmakta bulunduğu konusunu ele almıştım.

Yaşamakta olduğumuz gelişmeler bu beklentiyi destekler nitelikte görünüyor. Yazılım geliştiriciler, İnternet’in olanaklarını da kullanıp merkezde çalışan yazılımlar ve bunlara basit arabirimler (mesela web tarayıcılar) ile erişen uygulamalar geliştiriyorlar. İstemci-sunucu mantığı ile tasarlanan birçok yaygın uygulama, merkezi servis sağlayıcı konseptinde hizmet verecek biçimde yeniden ele alınıyor. İşletim sistemi ve donanımlar da düzenli olarak bu yapıya doğru evriliyor.

Uygulama geliştirme ve uygulama erişiminde beliren yeni eğilimler kendiliğinden ortaya çıkmıyor tabii ki. Maliyet baskıları, yönetim kolaylığı gibi unsurlar son derece etkin. Bu durum verimerkezlerinin ortaya çıkmasını tetikleyen etkenlerin de başında geliyor. Ancak verimerkezlerinin birer hizmet unsuru olarak belirmesindeki tek etken de değil.

Türkiye’de gerek telekomünikasyon sektörünün özelleşmesi, gerekse Türk Telekom’un İnternet erişimi konusunda başlattığı ADSL atağı ISP’lerin erişim pazarını daraltırken, onları ve onların tedarikçilerini verimerkezi işletmeciliğine yönlendiriyor ve yönlendirmeye de devam edecek. Pazardaki gelişmeler ve eğilimler paralelinde büyük verimerkezleri, katma değeri olmayan barındırma (hosting) servislerini bir kenara bırakıp katma değerli, yönetilen servislere ağırlık verme hedefindeler.

ABD’li verimerkezi işleticilerinin önemli bir bölümü Avrupa kıtasındaki yapılanmalarını uzunca bir süre önce tamamladılar. Almanya ve İngiltere gerek pazar büyüklükleri gerekse coğrafi konumları nedeniyle büyük verimerkezi işleticileri için cazibe merkezi konumundalar. CiHOST, Interland gibi devler satınaldıkları şirketler aracılığı ile veya kendilerine bağlı şubeler tesis etmek yoluyla Avrupa’da varlık göstermeye başladılar.

Aslında yapılmakta olan, Avrupa’lı hizmet tüketicisi kuruluşların yerel hizmet alma taleplerine verilen bir yanıt niteliği taşıyor. Güvenlik kaygıları, erişim kolaylığı ve yerinde yönetim gereken durumlarda verimerkezlerine fiziki erişimin kabul edilebilir maliyetlerde olması önemli etkenler.

Aynı etkenlerin baskısı Türkiye’de de kendisini göstermeye başladı. Kuruluşlar, özellikle uygulama sunucu işletimi, e-posta ve web sunucu işletimi gibi alanlarda ülke dışından hizmet almak istemiyorlar. Kıyı köşede vasat sunucular ve bağlantı olanakları ile hizmet sağlayan bazı yerli “verimerkezi” işleticileri ile pazardaki talebin karşılanamayacağı aşikar.

Yakın gelecekte Türkiye’de verimerkezlerine olan kurumsal talebin patlayacağını söylemek kehanet olmaz. Dış Kaynak Kullanım (DKK) konseptinin örnek açılımlarından biri olarak dağıtık ve yerel sunucu sistemlerinin büyük verimerkezlerine taşınması ile hem yönetimin hem de erişimin merkezileştirilmesi olasıdır.

Verimerkezlerine olan talebi artıracak bir diğer unsur felaket kurtarma önlemleri (Disaster Recovery) olacaktır. Makul bir alternatif sunulduğu takdirde hiçbir kurum mevcut teknolojik altyapısının aynısını bir başka coğrafi lokasyonda kendi olanakları ile ayakta tutma maliyetine katlanmak istemeyecektir. Türkiye’nin bir deprem ülkesi oluşu ve tüm dünyada yükselmeye devam eden terör dalgası güvenlik kaygılarının yanında olası felaketlere karşı önlem alma isteğini de beraberinde getirecektir.

Müşterilerine verdikleri hizmetleri merkezi bilgi işlem sistemleri üzerinden sağlayan kurumlar, merkezdeki altyapıyı çalışmaz hale getirecek bir felaket ile (sel, yangın, deprem, saldırı…) karşılaştıkları takdirde tüm operasyonlarının durması riskiyle de karşılaşabilirler. Üstelik bu durum domino etkisi ile ilgili diğer kişi ve kurumların da operasyonlarını etkileyebilir ve etki alanı büyüklüğünce bir kaosa yol açabilir.

Böyle bir duruma yönelik olarak verimerkezlerinin sunacağı ciddi ve kabul edilebilir alternatifler olmalıdır. Kurumsal bilgi işlem altyapılarının (yazılım + donanım + işleticiler ve prosesler) operasyonu sürdürmeye yetecek kadar kısmı bir verimerkezinde barındırılacak sabit veya paylaşımlı kaynaklarla pekala yeniden oluşturulabilir ve felaket durumu atlatılana dek kurumun hizmet vermesini sağlayabilir. Verimerkezi işleticileri, paylaşımlı kaynaklarını bu amaçla kullanabilir ve son derece kabul edilebilir maliyetlerle felaket kurtarma hizmet projeleri üretebilir.

Özetle; her tür işletmenin bilgi işlem altyapısındaki belirli unsurları Dış Kaynak Kullanımı yoluyla verimerkezlerine bırakabileceğini düşünüyorum. Web sunucular ve e-posta sunucuları en kolay devredilebilecek olanlar. MS Exchange + MS Outlook kombinasyonuna dayalı ofis verimliliği paketleri kullanan kurumlar uzakta barındırılan ve yönetilen hizmetler talep edebilirler. Paylaşımlı kaynaklar ile çok sayıda kurumun sunucuları eşzamanlı olarak yönetilebilir.

Teknik altyapılarını oluşturmuş ve yüksek servis seviyelerini garanti altına alabilmiş verimerkezlerinin ciddi bir DKK pazarı oluşturması ve bu pazardan pay almasının önündeki en büyük engel bilgi güvenliği olacaktır. Müşterisinin bilgi güvenliğine yönelik yatırım yapan, süreçlerini tanımlamış ve bu konudaki sicilini temiz tutmayı başaran verimerkezi işleticileri müşterilerin öncelikli tercihi olacaktır.

Hoşçakalın…

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

Başarılı "outsourcing"in yolu…

Bir önceki yazımda, Dış Kaynak Kullanımı’na (DKK) müşteri gözünden bakmaya, bu bağlamda tedarikçilerin yoğunlaşması gereken konuları bir miktar açmaya çalışmıştım (Dış Kaynak Kullanımını bilişim projeleri özelinde ele alıyorum.)

Yazıyı okuyan arkadaşlarımızdan gelen geribildirimler, DKK’na yaklaşım konusunda tedarikçilerin de değinilmesi gereken bazı beklentileri olduğunu gösterdi (sonuçta, bir DKK projesinin başarılı olması, tedarikçi ve müşteri arasında yapıcı bir işbirliği ve ortaklık kurulmasına dayalı olduğu için bu durum kolayca anlaşılabilir.)

Tedarikçilerin ve aslında müşterilerin de önemli sorunlarından biri DKK projesinden beklenen sonucun her zaman açık biçimde ortaya konmaması. Halbuki, “…DKK projesinin başarılı olması…” cümlesindeki “başarı”nın ölçütü ve tanımı, iyi bir işbirliği adına çok önemli.

Başarı kriterleri, yani DKK projesinden beklenen sonuçlar, müşterinin elde edeceği doğrudan maddi kazançlar (maliyet avantajları) olabileceği gibi, DKK’nın çıktılarından yararlanacak kullanıcıların memnuniyetinin artırılması da olabilir.

Yine de, maliyet avantajları ve kullanıcı memnuniyeti hedeflerinin tek başlarına ele alındıklarında birbirleri ile çelişir olduklarını göz ardı etmemek gerekiyor. Müşteri ve tedarikçi arasında DKK projesiyle hedeflenen sonuçların açıkça tanımlanması ve bu tanımlamaların benimsenmesi, değerlendirme aşamalarında her iki tarafa kolaylık sağlayacaktır.

Proje yönetimi disiplininde üç temel eleman olarak görülen Zaman, Maliyet ve Kalite bileşenleri proje hedeflerinin de çerçevesini oluştururlar. DKK projeleri için de durum farklı değildir. Genellikle, birini esnetmeden diğerini değiştiremezsiniz.

Müşteri olarak, çalışanlarınıza verilecek bilgi işlem desteğini tümüyle tedarikçinize bırakacağınız bir DKK projesi örneğinde, tedarikçinize verebileceğiniz başarı hedeflerini ve olası sonuçlarını bir inceleyelim :

1) “İşi daha ucuza getir…” : Tedarikçiniz bunu basitçe iki yolla sağlayabilir. Birincisi, hizmet hedeflerini en düşük maliyetleri yaratacak biçimde genişletmek, ikincisi de personel maliyetlerini (dolayısı ile yetkinlik seviyesini ve personel sayısını) düşük tutmaktır. Bu hedefi tanımladıktan ve istediğiniz maliyet hedeflerine ulaştıktan sonra tedarikçinizi kullanıcı şikayetlerinden sorumlu tutmanız, ortaklığınızı bozacak veya en azından zedeleyecektir.

2) “Kullanıcılarımın, bilgi işlem departmanından memnuniyet seviyesini yüzde şukadara yükselt…” : Yine aynı araçlar; hizmet hedefleri ve personel yetkinliği, sayısı işbaşında. Daha çok ve yetkin personel, uyulması gereken daha sıkı hedefler, belki cezalar… Tedarikçinizin sunacağı teklifin mali çerçevesinin genişlemesi kaçınılmazdır. Bu hedeflerle süregiden bir DKK projesinde faturaların kabarık olduğundan yakınmak da işbirliğinizi bozabilir.

3) “Hem maliyetlerim eskisinden düşük olsun, hem de çalışanlarımın bilgi işlemden memnuniyeti artsın…” : Müşteri olarak bilgi işlem yönetiminde son derece yüksek maliyetlere katlanıyor ve üstelik çalışanlarınızı memnun edemiyorsanız bu gerçekçi ve hatta tedarikçiniz için kolay ulaşılabilir bir hedef olabilir. Deneyimli bir tedarikçi, elindeki deneyimli personeli, iş süreçleri ve destek araçları ile kolayca altından kalkabilir. Ancak bilgi işlem yönetimini zaten optimum kaynaklarla ve asgari bir memnuniyet seviyesinde sürdürdüğünüze inanıyorsanız, böyle bir hedef temelde pratik ve uygulanır olmayabilir.

DKK projenizden beklentilerinizi doğru tanımlamak, ölçümleri bu beklentiler çerçevesinde gerçekleştirmek başarılı bir müşteri-tedarikçi ilişkisinin temelini oluşturuyor. Hedef ve değerlendirme kriterleri farklı ise her iki taraf açısından da gergin ve sorunlu bir proje kaçınılmaz oluyor.

Aslında siyah / beyaz gibi bir ayırıma giderek “ya o, ya bu” demek yerine, proje sürecinde, DKK’nın çıktılarından yararlanacak kullanıcıların iş kapsamı ve hizmet hedefleri hakkında doğru bilgilenmeleri sağlanırsa optimum bir noktaya varılabilir (genellikle bir defalık duyurular bu sonucu sağlamaktan çok uzak kalıyor. Doğru iletişim bu noktada kritik bir rol üstleniyor.)

Hoşçakalın…

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

Müşteri gözüyle "outsourcing"

“Outsourcing”, Türkçesi ile Dış Kaynak Kullanımı (DKK) pazarı, sadece Türkiye’de değil, tedarikçiler açısından Avrupa’da da ciddi fırsatlar vaat etmeyi sürdüren bir alan.

Tedarikçilerin önündeki en ciddi engel müşterilerini DKK’na ikna etmek. İşin içinde ikna olunca müşterinin size gelmesi değil, sizin müşteriye gitmeniz, konsepti anlatmanız, servislerinizin DKK konsepti ve müşterinizin beklentisi ile ne derece örtüştüğünü analiz etmeniz gerekiyor.

Bu süreç, her iki taraf açısından da sancılı olabilir. Kısaca “Müşteri” diye adlandırageldiğimiz, ancak genellikle bir kişiden ibaret olmayan karar alıcılar, kendi içlerinde tanımlama sorunları yaşayacaklardır. Müşteri, kendi “çekirdek” işini net olarak tanımlayabiliyorsa sancıların hafif atlatılması beklenebilir.

Örneğin bir yazılım şirketinde, kapıdaki güvenliğin dışarıya bir yerlere verilmesi konusunda daha kolay karar verilebilirken, iç kullanıcılara ve ekipmana yönelik bilgi işlem desteğinin dışarıdan tedarik edilip edil(e)meyeceğine karar vermek o kadar kolay olmayacaktır. Bu durumda hizmet tedarikçisinin işi de zorlaşıyor.

Bir adım daha ileri gidip, “com” objeleri üreten uzman bir yazılım grubu olduğunuzu ve müşterinizin de bu objeleri kendi yazılımlarında kullanabilecek yukarıdaki yazılım şirketi olduğunu düşünün. Böyle bir durumda karar süreci daha karmaşık bir hal alıyor. Acaba bu objelerin üretilmesi hedef müşterinizin çekirdek işi midir, değil midir ?

“Çekirdek iş” kavramını iyi anlamak, hedef müşterinizin neleri “çekirdek iş” olarak gördüğünü yakalamak son derece önemli. Bu konuda çok çarpıcı örneklere rastlanabiliyor. Müşterinizin çekirdek işine yönelik DKK önerileriniz büyük olasılıkla duvara toslayacaktır.

Müşteri tarafında teknik yöneticiler ve iş yöneticileri arasında çekirdek işin tanımı konusunda kavram kargaşası yaşanması sıkça gördüğümüz bir durum. Öncelikleri gereği iş yöneticisi, hedefi olan “satış”a odaklanmak, problemli konuları ayak altından temizlemek, bir anlamda DKK’yı benimsemek eğilimindedir. Buna karşın teknik yöneticiler, ekiplerinin etkinliğini -ve kadrolarının hacmini- artırmanın daha iyi bir fikir olduğunu savunabilirler (ki zaman zaman da haklıdırlar.)

Her iki tarafın tedarikçiye bakışları ve beklentileri bu anlamda farklıdır. DKK konusundaki karar süreci de kaçınılmaz olarak, daha etkili olan yöneticinin yaklaşımı doğrultusunda şekillenecektir. Tedarikçiye düşen, müşterideki farklı bakış açılarını anlamak ve çözümünü ara bir yol bularak şekillendirmektir:

1) Müşterinizi iyi tanıyın, karar vericileri saptayın.
2) Karar vericilerin çekirdek iş olarak gördükleri konuları öğrenin.
3) Karar sürecine etkisi olabilecek operasyonel / teknik yöneticilerin nabzını tutun.
4) DKK önerinizi, teknik yöneticilerin önceliklerini, beklentilerini ve DKK projesinin hayata geçmesi sonrası durumlarını da dikkate alarak hazırlayın.
5) Son kararı verecek kişiyi iyi belirleyin ve ona yönelin.
6) Ancak lütfen unutmayın! DKK projenizin geçiş sürecinde onu başarılı veya başarısız kılabilecek olan müşterinizin ta kendisidir. Bu nedenle her adımı dikkatle planlayın, uzmanlarla çalışın ve müşterinizle temasınızı sürekli açık tutun.
7) İşinizi, müşterinizin yapmakta olduğundan daha verimli yapabileceğinizi kanıtlamanız gerekir. Bunu yolu yaptığınız işe hakim olmak, gelişmeyi sayısal hale getirerek raporlayabilmek ve bunu karar vericilere aktarabilmekten geçiyor.

Müşteri gözüyle bakmaya, ancak karlılık hedeflerini ve müşteri stratejilerini bir kenara bırakmamaya dikkat edilmeli. Diğer yandan da DKK’nın satılabilmesi için temel faktörün aynı işi müşterinizden daha verimli yapmaktan geçtiğini de göz ardı etmeyin.

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

Bir Açık Kaynak Macerası – ve mutlu son

Merhaba. Açık kaynak kodlu yazılımların doğuş macerası ve yazarlarını bu yönde harekete geçiren etmenler konusundaki yazımın hazırlıkları devam ederken ben bir adım ötesine geçip son zamanlarda yaşadığım bazı uygulama deneyimlerini sizlerle paylaşmak istiyorum. Ama öncesinde biraz arkaplan bilgisi vermem lazım.

Geçenlerde kendime yeni bir “makina” topladım. Intel Celeron 1800 işlemcili, Nvidia ekran kartlı ve Serial ATA sabit diskli bir “PC” (meraklısı için söyleyeyim; anakartım Asus P4V800-X).

Diskimi üç ayrı kısıma (partition tabir ettiğimiz şey) ayırıp ilkine Windows kurmayı, ikincisini verilerim için tutmayı ve üçüncüsüne de RedHat Linux kurmayı planladım.

Serial ATA nispeten yeni bir teknoloji olduğu için işletim sistemleri tarafından doğrudan doğruya tanınmıyor. Neyse ki Windows XP için bir sürücü disketi vardı ve bir biçimde (SCSI filan diye kandırarak.) XP’yi kurmayı başardım (bir kaç kurulumdan sonra NT dosya sisteminden [NTFS] vazgeçerek tekrar FAT32’ye dönmem ayrı bir maceradır ve bu yazıyla ilgisi yoktur.)

Açıkçası ikinci disk bölümünü biçimlendirmek de pek zor olmadı. Sıra Linux’a geldiğinde işler değişti. Ne yaptıysam bir türlü Serial ATA diskimi tanıtamadım. Çekirdek derlemesi vb. şeyler bile işe yaramadı. Hatta bir denemede RedHat ile boğuşurken GRUB ön yükleyicisini kurdum ve kaldırmaya çalışırken XP’nin açılışını da uçurdum.

Tabi bütün sistemi bir kez daha sıfırdan kurmak zorunda kaldım (meraklısına bir not daha; sistem derken sadece işletim sistemini kastetmiyorum. Bir sürü uygulama, özel yazılımlar ve ayarlardan yani başağrısından söz ediyorum…) Antivirüs yazılımı olarak da çok pratik, hızlı ve verimli bulduğum Computer Associates’in e-Trust programını kullanıyorum (yıllık 10 dolar…)

Başarısız GNU/Linux denemelerimden geriye kalan 30 GB’lik koskocaman ve bomboş bir disk bölümü bugün hala makinamda varlığını sürdürüyor, Linux çekirdeğinde VIA’nın Serial ATA desteğini beklemekteyim…

Gelelim asıl konuya; makinamın “esas oğlan”ının Windows XP olacağı, ondan vazgeçemeyeceğim kesinleşince bu kez “Ne kadar az Microsoft o kadar az virüs/dert.” mantığı çerçevesinde alternatif bir web tarayıcısı, alternatif bir ofis paketi ve elektronik posta yazılımı arayışına girdim. İnanın, hepsi için de mükemmele teğet alternatifler buldum 🙂

Arayış başlıyor…

İşe, MS Outlook tarzı bir elektronik posta istemci yazılımı aramakla başladım. Eudora, Pegasus vb. derken hiçbirini beğenmeyip sonunda Mozilla’nın (www.mozilla.org) geliştirilme safhasında bulunan Thunderbird elektronik posta istemcisinde karar kıldım. Thundebird açık kaynak kodlu ve tamamıyla ücretsiz olarak kullanabileceğiniz bir yazılım. Thunderbird kurmak çok zor değil. Ancak güncellemesinde sorun yaşamak istemiyorsanız (ki henüz 0.5 sürümünde olduğu için geliştirilmeye açık.) bir tavsiyem var

Eğer iki disk bölümünüz var ve birini işletim sistemine ayırdıysanız “belgelerim” klasörünüzün, “Documents and Settings” ayarlarınızın ikinci sürücünüz üzerinde bir yerlere işaret etmesinde yarar var. Aksi halde işletim sisteminizi yeniden kurmak, ilk bölümü biçimlendirmek zorunda kalırsanız, tüm belgelerinizi ve beraberinde Thunderbird’ün de tüm ayarlarını kaybediyorsunuz (ben ettim…)

Thunderbird’de birkaç elektronik posta hesabını ayrı ayrı tanımlamak mümkün. Haber öbekleri ilginizi çekiyorsa onlar için de destek sağlıyor.

Thunderbird’ü birkaç aydır hiçbir güvenlik açığı, virüs vb. derdi olmadan gayet verimli şekilde kullanıyorum. Üstelik elektronik postalarım Mailbox formatında tamamıyla açık ve başka yazılımlar tarafından da kolayca erişilebilir biçimde duruyor. Ve kullanmaya alıştıktan sonra diğer e-posta istemcileri çok hantal ve “farklı” gelmeye başlıyor.

Tabi akabinde Internet Explorer’a alternatif bir web tarayıcısı arayışına giriştim. İlk aklıma gelen Opera oldu. Ancak hemen vazgeçtim. Peşinden Netscape, derken Mozilla (www.mozilla.org). Şimdi 1.6 sürümü çıkan açık kaynak kodlu Mozilla tarayıcısının 1.5 sürümünü indirdim, sadece tarayıcısını, DOM ve Java paketlerini kurdum.

“Tabbed Browsing” denen süper bir özellik, farklı arama motorlarını kullanabilen entegre arama özelliği (ben Google’yi tercih ettim.) ve inanılmaz hızı ile benim vazgeçilmez web tarayıcım oldu (size önerim kurar kurmaz Edit -> Preferences menüsüne girmeniz ve dikkatlice tüm seçenekleri okuyup kendinize göre ayarlamanız.)

Ofis paketine gelince. Kısa bir Star Office deneyimi ardından rotamı açık kaynak koduyla ücretsiz dağıtılan OpenOffice 1.1’e çevirdim (www.openoffice.org). Önce hevesle Türkçe sürümünü kurmaya gayret ettiysem de Türkçeleştirmenin ilk aşamalarında olduğunu görüp vazgeçmek ve ingilizcesini kurmak zorunda kaldım.

Bu arada Sun’ın JVM paketini kurmak bir ön koşuldu ve ben bu ön koşulu da yerine getirdim.

OpenOffice, Microsoft ofis paketlerinin bütün bileşenlerine yönelik alternafilere sahip. Üstelik tüm MS Office dosya biçemleri ile de uyumlu. Arkadaşlarımın hazırladığı son derece kompleks xls dosyalarını hiç sorunsuz açıp kayıt edebildim. Bir dip not olarak da; MS Word’e alternatif olarak geliştirilen OpenOffice Writer’ın dış kaynaklardan yapılan “copy-paste” işlemlerinde çok çok iyi olduğu kanısına vardım.

Tüm OpenOffice bileşenleri benim kendi alanlarındaki ihtiyaçlarımı fazlasıyla karşıladı.

Sonuç olarak; masaüstünde –en azından kendi gereksinimlerim çerçevesinde- halen rakipsiz bir ürün olduğunu düşündüğüm Windows XP, son derece kaliteli bir elektronik posta istemcisi olan Thunderbird, hızlı ve vazgeçilmez web tarayıcısı Mozilla, ücretsiz, uyumlu ve çok az kaynak tüketen OpenOffice ile birlikte diğer özel yazılımlarım mutlu bir birliktelik içindeler.

İpucu: Windows XP içerisinde XP’ye gömülü olarak gelen Outlook Express ve diğer bazı uygulamalara erişimi engellemeniz mümkün. Yukarıdaki kurulum hakkında daha fazla bilgi almak için bana yazabilirsiniz…

Not: Yukarıda sözü edilen Office, Windows, Windows XP, Outlook Express Microsoft’un tescilli markalarıdır. Neme lazım yazalım da 🙂