BT Servis Operasyonlarında Kurulması Gereken Denge

ITIL derki;
Servis Operasyonları tekrarlanan standart işlemlerden daha fazlasını kapsamaktadır. Kullanıcılara sağlanan bütün fonksiyonaliteler, süreçler, aktiviteler belirli bir katma değer sağlamak için tasarlanmıştır fakat bir yandan bu servisler her zaman gelişmektedir.
BT Ekiplerinin içe ve dışa odaklanmaları birbirleri ile çatışan çalışmalar içerebilir. Fazlası ile dışa odaklı BT Ekipleri, müşteri odaklı çalışırlar, müşterilerin isterklerine öncelik verirler onlara kesintisiz bir hizmet sunmak için hızlı çözümler üretirler.

Bilgi Teknolojileri çok hızlı değişen çeşitli sistemler üzerine kurulu olduğu için içe odaklı BT Ekipleri, kendilerine bu anlamda geliştirmeye yönelik çalışmalara ağırlık verirler. Her ne kadar temel amaç müşteri memnuniyeti olsa da, kaliteli hizmet teslimleri daha çok zaman ve para gerektirebiliyor.



Fazlası ile dış odaklı BT Birimleri müşteriye verile taahütlerin çok hesabını yapmaz her talebi hızlıca gerçekleştirebileceğine inanır ve genelde sonuç, yerine getirilemeyen taahütler, orta ya da uzun zamanda çıkan teknolojik sorunlar olur. Fazlası ile içe bağımlı BT Birimleri çok gelişmiş sistemleri müşterinin çok basit bir ihtiyacını karşılamak için kullanabilir bu durumda servisler çok daha pahalı sunulabilir.

Peki hangi yaklaşım doğrudur? İşte burda iç ve dış odaklı çalışmaların dengesi tutturulmalıdır. Terazi herhangi bir tarafa çok kaymamalıdır. Birden çok BT Birimini barındıran kurumlarda, BT Birimlerinin kendi içerisindeki yaklaşımlarının da diğer BT Birimleri ile uyumlu olmalıdır.

EVA - Ekonomik Katma Değer

Şirketlerin finansal verimliliğini ölçmek için birçok yöntem, değer(net kar artışı, hisse başına kar, kar marjı vs.) ve oran(Fiyat/Kazanç, Piyasa Değeri / Defter Değeri, Likidite Oranı vs.) kullanılmaktadır. Genel anlamda kabul görmüş olan EVA yöntemi, şirketin bütününün performansını ölçmekle beraber şirketlerin SBU(Strategic Business Unit) yani birimlerinin de ayrı ayrı performansını ölçmek için kullanılır.

Aslında işin özü çok net ve basittir. Şirketin sağladığı karın sermaye maliyetini karşılayıp karşılamadığının ölçülmesidir.

EVA = Net Gelir - Sermaye Maliyeti X Toplam Yatırım
Formülünde, Sermaye maliyeti aslında sermayenizi farklı bir alanda kullansaydınız elde edeceğiniz getiridir. Fırsat Maliyeti olarak da tanımlanabilir.

Çok kaba bir örnekle, elinizde 100.000TL var bu parayı faize verirseniz, sene sonunda 15.000TL faiz geliri alacaksınız. Bir iş kurmaya karar verdiniz.
İşinizden ilk sene %20'luk net kar elde ederseniz;
EVA'nız;
EVA = 120.000 - 100.000 X 0,15 = 5.000'dir ki bu pozitif değer iyi bir yatırım yaptığınızın göstergesidir.

Portföyünüzdeki projelerin seçimi, önceliklendirilmesi ile ilgili benzer yöntem kullanılabilir. Aslında hayatın her adımında bu yöntemi kullanıyoruz. A deterjanını değil de B deterjanını alırken bu muhakemeyi kendi kafamızda yapıyoruz. Amerikalı bankacıların 3-6-3 (%3'ten mevduat topla, %6'dan mevduatı dağıt, Saat 3'te golf oyna) stratejisi de bu basit analize dayanır.

EVA hesaplanması itibari ile çok göz korkutmasa da Sermaye maliyetinin hesaplanması ve kestirilmesi genelde göreceli olur. Yukarıda verilen örnekte sabit faiz değil de belirli bir fon alınması, iş olarak bir perakende zinciri kurulması değil de, rüzgar enejisi paneli üretilmesi gibi diğer altenatiflerin belirlenmesi her zaman çok kolay değildir.

EVA verilerini ciddi anlamda kullanan kurumlardaki yöneticiler de artık hissedarlarla aynı hedeflerin peşinde koşar ve iki grup arasında yaşanan çıkar çatışmaları son bulur.

Bu yazıda bir EVA reklamı yapılmadığı için(parada anlaşamadık) dezavantajlarından da bahsetmek gerekir.

EVA belirli bir dönem çerçevesindeki getirileri baz alır. Uzun vadeli yatırımların geri dönüşleri bu analiz içerisinde yeralmaz. Yukarıdaki örnekte siz, 100.000 TL'nin 50.000 TL'si ile ciddi bir altyapı yatırımı yapmışsanız bunun EVA için "gider kaleminden" başka bir anlamı yoktur. Halbuki bu yatırım size 2. sene de çok ciddi bir geridönüşü olabilir.

Bu nedenle EVA tek analiz yöntemi olarak seçildiği takdirde dönemlik karlara odaklanılır ve uzun vadeli plan yapılmaz ki bu da şirketi kısa zamanda sıkıntıya sokar.

EVA'nın uygulamasının zor olduğu sektörler genelde entellektüel sermaye ile iş yapılanlardır. IT ve hizmet sektörleri bunlara örnektir.

EVA'nın çok amaçlı kullanımları; şirket performans yönetimi, hisse senedi değerlemesi, şirket satın almaları öncesinde yapılan değerlemeler olarak örneklenebilir. EVA, önemli bir veridir ama şirketin herşeyini analiz etmez bu nedenle diğer analiz yöntemleri ile desteklenmelidir.

Percentage of Sale Approach

C:\Documents and Settings\MG46906\Belgelerim\MBA\FinancialManagement

İş ihtiyacı mı önceliklidir? Bilgi Teknolojileri ihtiyaçları mı?

İş ihtiyacı mı önceliklidir? Bilgi Teknolojileri ihtiyaçları mı? Herşeyden önce iş ihtiyaçları BT ihtiyaçlarını doğurur. İş birimlerinin talepleri olmasa BT birimleri rutin bakım işlerini yürütür ve fazladan bir BT ihtiyacı doğmaz. (Öğrenciler olmasa Milli Eğitim Bakanlığı çok rahat bir iş olurdu) Fakat gene de bu durum bizleri önceliklendirme konusunda kesin bir yargıya yönlendirmez.

Çok maliyetli bir şekilde geliştirilmesi öngörülen bir iş ihtiyacının önüne BT ihtiyacı gelebilir. Bu tip durumlarda genelde fazlandırma ya da benzer iş ihtiyaçlarına ortak bir çözüm üretilecek kapsamlı bir BT atyapı çalışması ihtiyacı olabilir. Maliyet kestirimlerinden sonra genelde projelerin sponsorları bu tip kararları alır. Bu durumlarda BT ihtiyaçları öncelik kazanabilir.

İyi idrak edilmemiş iş ve BT gereksinimleri projenin analiz aşamasından sonraki aşamalarında (genelde bitmesine yakın zamanlarda hatta test aşamalarında) farklı ihtiyaçlar ve değişiklik istekleri olarak karşımıza çıkar. Bu nedenle iş ihtiyaçları çok net ifade edilmelidir, "neyin" yapılacağını iş birimleri ifade ederse, işin "nasıl", "diğer hangi sistemleri etkileyerek" ve "ne kadar maliyetle" yapılacağını BT birimleri kestirebilir. Bu soruların cevapları herkesin mütabık kaldığı bir formatta dokümante edilerek, çok net bir şekilde bütün paydaşlarla paylaşılmalıdır. Aksi durumda projenin geliştirilme süresinde iş birimleri proje hakkında bilgi sahibi olmaya çalışacak, "geliştirmeler ne aşamada?" "ekranlarınız nasıl?", "ne zaman görsel bir demo yapabilirsiniz?" gibi sorularla karşılaşırlar.

İş birimi yeteri kadar bilgilendirilmezse bu sorular kaçınılmaz olacaktır. Bir taksiye binip adresi verdikten sonra arka koltuktan "ne kadar yolumuz kaldı?", "Saat 3'te orda olur muyuz?", "arabada yeterli benzin var mı?", "ortalama hızımız nedir?", "kaçıncı viteste gidiyoruz"(tamam bu soru biraz abartı oldu) şeklinde sorular sorulduğu takdirde şoförün dikkatini dağıtabilirsiniz ayrıca taksi şoförleri size BT birimleri kadar kibar davranmayabilir. Projelerin gidişatı konusunda periyodik bilgilendirmeler yapılmadığı sürece iş birimleri yakın takipte olmak isterler.

Yıllar önce İngiliz bir danışmandan alınan eğitimin başında, eğitmen "Kimler iş analisti? Kimler IT Birimi çalışanı?" diye sordu herkes rengini belli ettikten sonra yorumu "Hmm... Good guys and bad guys are together" oldu. Tabii kimin "good" kimin "bad" olduğu masanın ne tarafında oturduğunuza bağlı. Buradan şu sonucu çıkartıyorum, sadece biz Türklere özgü bir durum değil bu; modern proje yönetilen heryerde bu iki paydaş birbirleri ile çok iyi anlaşamıyor. İş Birimleri ve IT Birimleri birbiri ile koordineli bir çalışma sergilemeli, aynı amaca hizmet ettiklerini unutmadan çalışmalarını yürütmelidir. Aksi halde projelerin kalitesinin düşmesi ve maliyetlerinin artması kaçınılmazdır.

Critical Path Method CPM - Kritik Yol

Critical Path Method, birden çok adımdan oluşan bir projenin, süresini belirleyen adımlar serisidir. Eminim daha önce bu konuda herhangi bir çalışma yapmamış kişiler bu açıklamadan pek birşey anlamamıştır. CPM hakkında bilgi sahibi olanlar da bu açıklama ile bildiklerini unutmadan hemen güncel hayattan bir örnekle açıklamayı "açıklayayım".

Öncelikle Projemizin adı "Yeni Kiralanan Evinize Taşınma". Projemizin bazı varsayımları var; Öncelikle evde şu anda başka bir kiracı oturmakta ve yeni evinize yeni eşyalarla yerleşmek istiyorsunuz. Bu doğrultuda projemizin adımları şu şekilde;




Bu projede hangi adımlar gecikirse eve taşınma işlemi ertelenir. 5 Task'i olan bir proje için gözle bu tespit yapılabilir,
1-Mevcut kiracının evi geç boşaltması
3-Evin Boyanması
4-Yeni eşyaların teslimi

Bu 3 adımdan herhangi birinin gecikmesi taşınmayı direkt geciktirecektir. Peki ya diğer adımlar gecikirse taşınma etkilenmez mi? Bu sorunun cevabını vermek için bir veriye daha ihtiyacımız var. Diğer adımlar "ne kadar" gecikirse taşınmamız ertelenir?
İşte Critical Path üzerinde olmayan adımların projeyi etkilemeyen gecikme süresine "slack" zamanı denir. Minimum (genelde 0) slack süresine ait adımlar Critical Path'i oluşturur.

"Elektrik / Su / Doğalgaz Devir İşlemleri" için slack 2 gündür. İlgili adım 1 ya da 2 gün gecikir ise taşınma işlemi ertelenmeyecektir. Bürokratik belediye işlemlerinin 16'sında tamamlanması bizim proje süremizi etkilemez. Fakat ilgili adım 3 gün geç başlar ya da planlanandan daha uzun sürer ise (mesela 8 gün) bu sefer projenin critical path'i değişir ve tamamlanma süresi etkilenir. Yeni plan şu şekilde olacaktır;




Yeni Critical Path ise;
1-Mevcut kiracının evi geç boşaltması
3-Evin Boyanması
4-Elektrik / Su / Doğalgaz Devir İşlemleri

Burada Critical Path'in nasıl hesaplandığı bilgisi verilmeyecektir. Her modern proje yönetim aracı bu yöntemi uygulayabilir. Burada dikkat edilmesi gereken hususlar vardır. Adımların sadece mantıksal bir şekilde birbirlerini izlemediği (örneğin Eşyaların teslim edilmesi için evin boyanmış olması gerekir) aynı zamanda ortak kaynak kullanan adımların da birbirlerinin önkoşulu olabileceği gözden kaçırılmamalıdır. Eğer Evi kendiniz boyasaydınız, "Elektrik / Su / Doğalgaz Devir İşlemleri" ancak 15'inde başlayabilecekti.
Bir diğer önemli konu da plandaki her değişimden sonra Critical Path'in tekrar hesaplanması gerekliliğidir.