Bilgi Teknolojilerinde Değişimi Yönetmek

iStock-482819124-1254x506[1]

Herakleitos’un günümüzden yaklaşık 2500 yıl önce de dediği gibi “Değişmeyen tek şey değişimin kendisidir.”. 

İhtiyaçların, standartların, yasaların, bağlı sistemlerin ve paydaşların sürekli değiştiği sistemlerde de değişim kaçınılmazdır. Değişimi nasıl yöneteceğimiz ise her ne kadar bize kalmış olsa da, minimum gereksinimler için standartların bizi nerelere yönlendirdiğini izlemekte fayda olduğu gözardı edilemeyecek bir gerçektir.

Gelişmiş ülkelerde standardizasyon önem verilen bir konu olduğu için yıllardır uygulanan teknikler olsa da ülkemizde BT ekipleri/şirketleri değişimi yıllarca yönetmedi. İhtiyaç duyulmadı diyenler de olabilir ama benim görüşüm farklı, ihtiyaç her zaman vardı ama BT’nin iş süreçlerindeki önemi henüz anlaşılamadığı için değişimin yönetilmesi hep geri planda kaldı.

BT sistemlerinin bağımsız çalıştığı ve sayılarının az olduğu zamanlarda her ne kadar kişiye bağımlılık problemi olsa da değişimi insanlar üzerinden yönetmek kolaydı. Çalışan, sorumlu olduğu sistemin tarihçesini de bildiği için dokümante edilmemiş olsa da çalışabilir ve karar verebilir durumdaydı.

Bu durum uzun süre sorun yaratmadı, çalışan orada olduğu sürece sorun çıkmayacağı fikri yönetimlerin kafasında yer etti etmesine ama bu durum da BT birimleri içerisinde kendini geliştirmeyen, varolan sistemi devam ettirme (statüko) üzerine çalışan dinozorların yer etmesine yol açtı.

Dinozorlar statükoyu koruma konusunda iyiydiler, sistematik çalışmamaları sebebiyle dokümantasyon ve kayıt tutma en düşük seviyede kaldığından anlık maliyetleri de düşük kalıyordu fakat işin kalite maliyetleri göz önüne alınınca yaptıklarının yanlış olduğu ortadaydı. Dolayısıyla sistematik bir değişim yönetimi BT için de ihtiyaç durumuna geldi.

Dinozorların diğer bir kötü etkisi de gelişime açık, genç ve arzulu elemanların ekipten ayrılması yönünde oldu. Statükoyu devam ettiren şirketler yeni ve iyi elemanları elinde tutmakta zorlanırken, dinozorlara ayak uyduran ve değişime/gelişime ayak direyen çalışanlar kadroları doldurdu. Bu da şirketlerin günü yakalamasının önünde günden güne büyüyen bir engel haline geldi.

5608686e1900003000fde7df[1]

Son yıllarda sistemlerin sayısının artması ve karmaşıklaşmasının yanısıra entegrasyonların da hayatımızın daha büyük parçaları olduğunu düşündüğümüzde değişimin etkilerinin de paralel olarak büyüdüğünü de anlamak için alim olmaya gerek yok. Bağımsız sistemlerde tek kaynaktan gelip tek ya da az sayıda kaynağı besleyen veriler artık hayatımızın parçaları değiller. Farklı kaynaklardan toplanıp, farklı sistemleri besleyen verilerle karşı karşıyayız. Dijital dönüşümün hızlandığı, nesnelerin interneti ve endüstri 4.0 konseptlerinin de sistemlerimiz arasındaki bağlılığı günden güne arttırdığı bir süreçte oluşan büyük verinin yönetilebilir olması daha da önemli oldu.

Büyük veri diyoruz ve genelde dinozorlar büyük veriyi bir ebat sorunu olarak algılıyorlar. Sorunun bir boyutu elbette verinin çok olması ama diğer bir boyutu da farklı sistemler arasında dağınık olması. Bu dağınık veriyi yönetemedikten sonra toplanan veri bizim için depoladığımız çöpten başka bir şey değildir. Yönetimi içinse sistemlerdeki değişimin etki ve risklerinin yönetilebilir olması gerekmektedir.

ITIL çerçevesinde bir geçiş süreci olarak tanımlanan değişim yönetimi süreci de donanımdan yazılıma, veri yönetiminden ağ yönetimine tüm sistemlerdeki değişikliklerin kayıt altına alınmasından canlıda sorunsuz halde çalışmasına kadar geçen sürede yapılması gerekenleri standardize ederek değişimin kontrollü bir biçimde gerçekleşmesini yönetmeye yarıyor.

IC-change-managment[1].png

Minimum gereksinimler bazında baktığımızda değişim yönetimini 5 adımda özetlesek de diğer süreçlerle bağlantılarının ne kadar derinlere gittiğini gördükçe aslında BT Hizmet Yönetimi’nin ne kadar geniş bir alan olduğunu ve tekil süreçlerden ziyade bir ağ gibi, BT’nin her yerinde uygulandıkça daha iyi sonuçlar ortaya çıkaran bir yönetim sistemi olduğunu görebiliriz.

Adımlara ve bizden istenen minimumlara gelirsek;

  1. Request for Change: Değişiklik Talebi… İstenen değişimin kayıt altına alınması adımıdır. Olay ve talep yönetimi süreçleri ile doğrudan ilişkilidir.
  2. Impact Analysis: Değişikliğin etki ve risklerinin analiz edildiği adımdır. Konfigürasyon yönetimi süreci ile doğrudan ilişkilidir.
  3. Approve / Deny: Onay adımımız. Değişiklik Değerlendirme Kurulu (Change Advisory Board) ile değişikliğin etkilerinin değerlendirildiği bir görüşme yapılır. Değişikliğin zamanlaması ve bağımlılıkları konusunda paydaşların fikri alınır.
  4. Implement Change: Değişikliğin gerçekleştirildiği adım. Geliştirme, test ve devreye alma adımları burada işler. Devreye alma ve konfigürasyon yönetimi süreçleri ile doğrudan ilişkilidir.
  5. Review / Reporting: Devreye alınan değişikliğin etkilerinin canlıda izlendiği adımdır.

Doğrudan ilişkili süreçlere ek olarak değişikliğin içeriğine göre kapasite yönetimi, tedarikçi yönetimi, bütçe yönetimi gibi diğer hizmet yönetimi süreçleri ile de etkileşim olabilir.

Değişim Yönetimi ayrıca yazılım ve sistem geliştirme yaşam döngüsü ile birebir örtüşen bir akışa sahiptir. Analiz, geliştirme, test ve canlıya alma süreçleri birebir değişim döngüsü içerisinde ele alınır. Günlük operasyonlardan oluşan bakım süreci ise yeni değişiklikleri tetikleyerek döngüyü tamamlar.

Sürecin başında tanımlı bir değişiklik yöneticisi bulunması gerekmektedir. Değişiklik Denetleme Kurulu’nun toplanması ve değişiklik onaylarının verilmesi gibi önemli görevler bu yöneticinin sorumluluğunda işleyen görevler olsa da süreç tüm ekibin ahenkli çalışması ile doğru sonuç verir.

Takım çalışması, değişimin yönetilebilmesi için olmazsa olmazdır.

Teamwork[1]

Değişimden etkilenen ve değişimi etkileyen tüm birimlerin ortak bir amaç için, yani değişimin başarılı sonuçlaması için birlikte çalışması bizi doğru sonuca götürür.

Kaçınılmazdan kaçmadan, değişimin ve gelişimin yanında, en doğru sonuçlara ulaşabilmek için bir ekip olarak uyguladığımız değişim yönetimi, kurumsal BT yönetiminde günü ve geleceği kurtarır.

Read it on Medium

CMDB, a pain in the neck… Is it really?

 

For most of the organizations, maintaining a healthy CMDB (Configuration Management DataBase) is a really hard job.

Is it really that difficult or are we doing something wrong?

Let me tell you something, it is not that difficult and yes, you are doing something wrong.

Organizations start projects for CMDB implementation and most of them result with a failure. You are not destined to fail, all you need is to plan it right and take time to analyze before you implement, not the other way around.

And do not forget that the configuration management process is the core of IT service management, so have your CMDB and configuration management process before you start with other processes like change management for the best result.

CAREER-DEV_iStock-518310332[1]

First of all, start with a good scope definition. You don’t want to fill your CMDB with configuration items that you are not really dealing with. Take time to understand what different units work on, where do they keep their data, whether scanning and auto-populating the CMDB is possible, and on what extent the scanning tools can populate your CMDB.

Now you know what you can do and what you should do.

Decide on the classes and carefully select the attributes for each class depending on your needs and the capability of your data sources. You now have your organization’s data dictionary with all the details.

The next step is to decide on the relations between classes: Applications run on servers, depends on network and so on.

You are now ready to implement it once you have everything ready on paper.

Then comes the related processes, your service management will be shaped around the CMDB. How you are going to track the change history, when you are going to update a CI, how you are going to use the dependencies in order to fix the problems, they are all the subjects of related processes but cannot be done if you don’t have a steady CMDB.

It is not that difficult to accomplish but it must be done in the right order. Do it right once and you will be ready to excel in the other processes as well.

Explaining IT Strategies to the Non-IT Executives in a World of Technology

Why so expensive?

It’s what we usually hear from the C level executives in the budgeting period that IT is a huge cost. Are we doing something wrong? Are our estimations so bad that the C levels go crazy each time we sit down around the table.

Most probably NO!

But why do we get misunderstood?

Here you can find some answers from my experiences and thoughts on the dilemma of explaining IT budgets to the non-IT executives (especially for manufacturing companies in emerging markets).

The Problem:

Not everyone works in a tech company. Life is easier for those who work in tech since the executives know technology.

For the rest, you should understand that the technological progress is faster than the changes in the traditional businesses. Businesses like manufacturing or finance have evolved throuhout the years but the core processes remained more or less the same. Yes, they are using more technology today but their main processes are the same as they used to be in the past. There is automation, there is AI, they have all the data they don’t even need but they are still using all these technologies in order to do the jobs they used to do, just faster and more reliable.

I would like to point out that those are the 2 businesses that use technology the most, all the other businesses are behind these 2 which most of the economy relies on.

Technology became a part of almost all businesses very fast. Most companies did not even have computers or internet just 2 decades ago and now even the local store around the corner uses internet for banking and ordering goods. Technology is more and more integrated as the complexity and size of the business grows.

But most of these companies are run by executives who did not use computers as a part of their daily routine when they first started working. Some of them were able to be a part of the change and understand the meaning of IT in their business but for most of them IT is all about buying “computers and stuff”.

Today companies need infrastructure and software as well as support but that’s not the end. More business processes evolve with technology so larger companies started to either become tech companies or create tech companies to support their needs.

Outsourcing is an option, it s still profitable especially in the developed markets where the awareness and the level of technology is higher.

What about the emerging markets?

There is a great potential in the emerging markets since they still have a long way to go in their local businesses but on the other hand they are the ones outsourcing the developed markets so they have the right resources.

All they need is to have right strategies to lead the companies (or countries) in the right direction.

How are we supposed to convince the executives that what we are doing is not an extra cost but it is essential to the continuity of the business?

First of all we must all know that “doing what everyone else is doing” will not take us to the lead.

We must do what everyone else is doing and just then we will be on the same level with our competitors. We must look for areas of innovation after this point.

For many years, executives expected IT departments to miraculously take the company to another level when they wanted to invest on IT processes. They thought this was continuous improvement (or Kaizen if you are working in a Lean environment).

Let’s agree on something; being ITIL compliant or ISO 27001 certified is not something that will make you a star, it is the baseline. Whatever you do after that point will take you to the other levels.

Make sure that your executives are on the same page with you on this. Make sure that the IT standards are the baseline that you need to comply with, not a magic wand.

Form a compliance team to ensure your organization meets the baseline.

And now we can talk about innovation.

Internet of Things (IoT), Industry 4.0, Digital Transformation, Big Data, Artificial Intelligence and all those great areas of innovation is now ahead of you.

But again, doing what everyone else is doing is not going to get you to the lead so plan your projects accordingly.

First, start with baby steps: draw your technological baseline. See what everone else is doing and pinpoint the problematic areas to catch up with the baseline.

Form a team for innovation, do not overload the team with the routine, let the other teams handle the daily routine while the innovation team builds your future.

Keep it simple.

Use the power of iterative development.

Set achievable targets and manage the innovation.

And the world is yours once you pass the baseline.

There is one more thing to remember: yesterday’s innovation is today’s baseline.

So, improve continually!

Now it’s the Kaizen time 😉

Endüstri 4.0 Treninde Boş Koltuklar

Sanayi devrimlerini geriden takip etme alışkanlığı olan ülkemizde belki de ilk defa dünyaya bu kadar yakınız.

Diğer taraftan da bir o kadar uzak…

Son zamanların trendi “Endüstri 4.0” ile insandan bağımsızlığa doğru ilerleyen üretimin bizi nerelere götüreceğini merakla izliyoruz. Katıldığım seminerlerde herkes bir başarı hikayesi paylaşıyor ama gerçekte başarılan ne çok sorgulanmıyor.

Birinci sanayi devrimi buharlı makinelerle gerçekleşti, treni kaçırdık. Treni kaçırdık derken sözün gelişi değil, hakikaten buharlı trenlerle bile batıdan yıllar sonra tanışabildik.

Seri üretim ile gelişen ikinci sanayi devrimi de geç uğradı topraklarımıza, batılı ülkeler savaş teknolojilerini bile seri üretmeye geçtiğinde biz maalesef hala el işiyle, usta-çırak ilişkisiyle devam ettik. Sadece batı ilerlemedi bu devrimde, Japonya gibi doğu ülkeleri de çok iyi yerlere geldiler sanayide.

Bilgisayarların ve otomasyonun kullanıldığı üçüncü sanayi devrimi de geç geldi bize. Bize derken yerli üretimden bahsediyorum, topraklarımızda otomasyon vardı belli ölçüde ama çoğunluğu yabancı sermayeydi yakın zamana kadar.

Gelişmiş ülkeler otomasyonu olabilecek en üst seviyede uçtan uca sağlayacak duruma geldikten sonra daha fazla ne yapabiliriz sorusu gündeme geldi.

İşte dördüncü sanayi devrimi ya da popüler adıyla Endüstri 4.0 böyle doğdu. Bazıları için otomasyonun devamı ya da endüstri 3.5 olarak görülse de yapılanlar, aslında bunun bir adım ilerisine geçme potansiyeli ortaya çıktığı için 4.0 akımı başladı.

Ve belki de ilk defa zamanında tepki verdik ülke olarak bir teknolojik gelişmeye. Ne yazık ki altyapımız olmadan girdik yarışa ve yanlış stratejilerle ilerlediğimiz bu yarışta geride gidiyoruz ama çağın dinamikleri 50 ya da 100 sene önceki gibi değil, küçük gelişmelerle bir adım öne geçebilmek de mümkün bilgi çağında.

Peki neyimiz eksik diye baktığımızda temel olarak 3 ana sebep görüyorum:

  1. Otomasyon teknolojilerinde yetersizlik
  2. Bilişim teknolojilerinde yetersizlik
  3. İnsan kaynağında yetersizlik.

İlk 2 sebepten ilki olan otomasyon konusundaki yetersizliğimiz aslında üçüncü sanayi devrimini özümseyememiş ya da bu konuda yeterince yatırım yapmamış olmamızdan kaynaklanıyor. Şirketlere baktığımızda otomasyonun girebileceği pek çok süreç maddi kısıtlar yüzünden hala insana dayalı yürüyor. Zamanında otomasyon teknolojisi yurt dışından yüksek maliyetlerle geldiği için ucuz iş gücünün tercih edilmiş olması sebebiyle çağı yakalayamamışız. İşin kötüsü dışarıdan alamıyoruz, bari içeride geliştirelim diye de bir yatırım olmamış.

Buna paralel gelişmesi gereken bilişim teknolojileri altyapısı da eksik kalmış, otomasyonun bilişimi, bilişimin otomasyonu tetiklediği döngüye giremeyen şirketler otomasyonu bir alet olarak kullanmaktan ileri gidemezken, sadece masraf kalemi olarak görülen IT birimleri hazır yazılımlar ve platformların basit ama garanti çözümleri döngüsüne girerek yabancı menşeli firmalara kaynak akıtmış.

Bu ikisinin birleşiminde ortaya çıkıp, çoğu sanayi firmasında üst yönetimlerce hala fark edilemeyen 3. ve son sebep ise insan kaynağı eksikliği maalesef.

O kadar çalışanımız var diyenleri duyabiliyorum. Neden mi eksik insan kaynağı?

Çünkü doğru değil planlamamız.

Otomasyon kültüründen gelmeyen, bilişim teknolojilerine uzak çalışanlarla zaten endüstri 3.0’ı ucundan yakalayan bir iş yapış şekli var şirketlerimizin.

Bunlara ek olarak trendi yakalamak uğruna başlatılan Endüstri 4.0 projelerine ekstra kaynak ayrılmıyor. Üst yönetimler yıllardan beri süregelen IT yapar yanılsamasından sıyrılamayıp projeleri istiyor fakat proje için ekip oluşturulmuyor.

Ne mi oluyor bu durumda?

Üzerinde tam zamanlı iş yükü bulunan bir çalışan yeni teknolojileri öğrenip, geliştireceği ikinci bir görevin hakkını veremiyor. Aradaki açığı dışarıdan teknoloji alarak kapatmak ise uzun vadede maliyetleri artırırken çalışanların da yetkinlik kazanmasını engelliyor, şirketleri dışa bağımlı yapıyor.

Bu da bizi hedeften uzaklaştırırken başladığımız projeleri daha karmaşık bir sorun haline getiriyor.

Sorunun çözümü ise o kadar da karmaşık değil, insana yatırım yaparken kısa vadeli çözümler yerine biraz sabır göstermek yeterli.

Önce insan kaynağı oluşturulsun, işi dönüşüm olan bir ekip olsun ki bölünmeden, odaklı bir şekilde çözüme gidebilsinler.

Varsın 6 ay sonunda iş emirleriniz otomatik akmasın, bugüne kadar otomatik değildi de işler mi duruyordu?

Varsın üretimden topladığınız veri size bir sonraki arızanızı ne zaman yaşayacağınızı önceden söylemesin, bakımcılarınız belki bir süre daha eskisi gibi çalışırlar.

Kısacası ekibi oluşturduktan sonra onlara biraz da zaman verin. Dışarıdan aldığınız teknoloji günü kurtarır, kendi teknolojiniz yarını.

Kurumsal IT Birimleri Neden Başarılı Olamıyor?

IT yöneticilerinin en büyük derdidir yapılan işi üst yönetime anlatabilmek. O kadar yüksek bir hızla dijitalleşen bir dünyadayız ki işe başladığı yıllarda iş yapma pratiği bilgisayar içermeyen pek çok beyaz yaka ile hala beraber çalışıyoruz ve üst yönetimler de çoğunlukla bu kişilerden oluşuyor.

Tüm şirketin birkaç bilgisayar ve yazılım ile döndürüldüğü 90’lardan her çalışanın bilgisayar, tablet, akıllı telefon gibi ara yüzlerle onlarca, hatta yüzlerce sisteme eriştiği günümüze 20 yıl gibi bir sürede geldik, arayüzler basitleştikçe arka plandaki sistemler karmaşıklaştı, sistemler karmaşıklaştıkça IT’nin işi zorlaştı ama son kullanıcı ve üst yönetimin gözü arayüzlerin arkasını göremediği için yapılan işi görünür hale getirmek de daha zor hale geldi.

Eski kafalı yöneticiler, eski alışkanlıklarına devam ettiler bu süreç boyunca ve şirketleri, teknolojik evrimlerinde güçsüz kaldılar. IT’nin kendine özgü sistematiği olduğunu kavrayamadılar, yanlış kurgulanan sistemler yamalı bohçalar haline geldikçe daha da vazgeçilmez oldular şirkette eski IT’ciler.

Ama diğer bir yandan da sorun ve masraf merkezi haline getirdiler IT’yi son kullanıcının ve tabii ki yönetimin gözünde.

IT’yi bir destek birimi olarak görmelerine rağmen IT’nin bir hizmet birimi olarak yapılanmasını gerçekleştiremeyen şirketlerde müşteri memnuniyeti düşerken, bel bağlanan sistemlerin kurumsal kurguda olmaması sebebiyle de verimlilikte beklenen artış yaşanmadı.

Bir de bunun üstüne çoğalan sistemlere ve büyüyen şirketlere paralel bir IT büyümesi gerçekleşmeyince memnuniyetsizlik arttı da arttı.

Bazı şirketler de sorunu tespit edebilmelerine rağmen ilacı yanlış kullandılar. IT hizmetlerini ITIL tabanlı süreçlere geçirirken süreçlerin sadece adlarının olduğu, eski yöntemlerin pratikte işletildiği bir yapıya büründüler, sonuç tabii ki yine düşük müşteri memnuniyeti.

Peki sorun neydi?

Kalite maliyetleri ya ihmal edildi, ya da dile getirilse bile kabul görmedi.

20 yıl öncesinin düşük teknolojili az sayıda sistemine göre kurgulanmış IT kadrosunu, yüksek teknolojili çok sayıda sistemden sorumlu tutup, bir de üzerine ekstra kalite süreçleri getirince bünye yapılan tedaviyi reddetti ve kendi içinde kısayollar oluşturmaya başladı.

Kısayollar kalite maliyeti yaratmadıklarından o an için işe yarar ve masrafsız sonuçlar verdiyse de uzun vadede getirdikleri kalitesizlik maliyetleri ile şirketlere daha büyük zarar verdi.

Peki treni kaçıran bu şirketler için endüstri 4.0, nesnelerin interneti ve dijitalleşme ile yakalanması gereken hedefin daha da hızlı uzaklaştığı bir dünyada çözüm nedir?

Yeniden yapılanma.

Ama daha önce denenen şekliyle değil, kanserli hücrelerden kurtularak, yapıyı sağlam temeller üzerine oturtarak.

Tabii ki IT’ye olan bakış açısında da değişikliklere gitmek gerekli bu yapılanma sırasında. IT’nin, ana iş kolunun iş yapış şeklinin ayrılmaz bir parçası olduğu gerçeğini kabullenerek kurgulanan bir şirket geleceğe emin adımlarla ilerleyebilir, aksi takdirde geçmişin tozlu sayfaları arasında kendisine yer edinmekten başka bir seçeneği yoktur.

Dijitalleşen dünyanın geleceği IT’dir. IT geleceğimizdir.

IT süreçlerinde trendlerin esiri olmak

Aslına bakarsanız sadece yazılım süreçlerinde değil, hayatın her alanında trendlere esiriz. Özellikle kurumsal yapılarda değişim ve çağa ayak uydurma isteği herşeyin hızla değiştiği günümüzde resmi daha yukarıdan gören IT yöneticilerini trendlerin peşinden koşmaya iterken, resmi aşağıdan gören IT profesyonellerinde ise kafa karışıklığına yol açıyor.

Peki sıkıntı nerede?

Sıkıntı hayatın ritminde.

Hayat biraz hızlı akıyor ve trendler bu hıza ayak uydurmamızda ya bize yardım ediyor ya da bir sonraki trende kadar yerinde saymıyormuşuz izlenimi yaratıyor.

Kafalar mı karıştı? Memnuniyetle açayım:

Bütün iş ne yaptığımızda bitiyor, hangi trendin peşinden gittiğimizde değil.

O gün geliştirdiğiniz web uygulamaları DevOps bakış açısına uygunsa başarılı oluyorsunuz, sizin gözünüzde DevOps en mükemmeli oluyor ama örümcek ağına dönmüş bir ERP sisteminde DevOps aynı sonucu vermiyor.

Agile ile hızlı ve mükemmel sonuçlar alabildiğiniz küçük çaplı projeleriniz var ama aynı anda onlarca kişinin çalıştığı bir Agile projesi ile darboğaz yaşayabiliyorsunuz.

Neden?

Aslında cevap çok basit:

Tek bir trende takılıp gitmek yerine işe uygun yöntemi uygulamak gerekiyor. Trendleri birer araç olarak kullanmak yerine amaç olarak kullanıyoruz.

Bugün büyük kurumlara baktığımızda bir çoğunu bir DevOps çılgınlığının sarmış olduğunu görüyoruz, aynı kurumlar 5–10 yıl önce harıl harıl Agile peşinde koşuyorlardı, son zamanlarda ScrumMaster iş ilanlarında ne kadar azalma olduğunu belki takip edenler de fark etmişlerdir.

Yapılması gereken projeyi iyi anlamak, ihtiyacı trende uydurmaya çalışmak yerine doğru yöntemi belirleyerek ilerlemek, tabii ki bu arada projeyi/operasyonu doğru yönetmek her zamanki gibi önemini koruyor.

Yöntemin doğru seçildiği, kaynakların doğru planlanıp, değişimin doğru yönetildiği bir iş başarıya ulaşır, ayaklardan birindeki dengesizlik tüm işi bozar.

Süreç kelimesinin anlamını unutmamak gerekir:

“Girdileri alıp bir çıktıya dönüştüren her faaliyete süreç denir.”

Herşeyde yaptığımız gibi bu konuda da anlamın içini boşalttığımızdan isimlerin peşinden koşup gerçekte yapmamız gerekenden sapıyoruz, girdileri çıktıya dönüştürmek yerine arayı trendlerle dolduruyoruz. Halbuki bu yöntemleri birer araç olarak kullanmayı öğrenebilsek yakaladığımız esneklik ile daha doğru adımlar atabileceğiz.

Biz ne yapıyoruz? Lean/Agile/DevOps yapıyoruz diye aracımız olması gereken yöntemleri amacımız haline getiriyoruz.

Pek çok kurum tarafından düşülen bu hatadan nasıl kurtulursunuz diye sorarsanız cevabım basit:

İşin teknik derinliğinde boğulan ya da müşteri ile cebelleşen IT yöneticileri yerine yönetim sistemleri ve farklı teknikleri bilen, trendleri takip eden kişileri proje/operasyon yönetiminde kullanmak, kurum içinde bu tarz çalışanları teşvik etmek.

Tabii ki bunu yaparken çok iyi bir teknik çalışanı ya da harika bir satışçıyı da aşağıda tutmamak lazım, aynı kademelerde yükselme şansı her farklı kolda olmalı ki tüm çalışanlar daha iyi kazanabilmek için yöneticiliğe yönelmesinler.

IT proje/operasyon yöneticisi ekibinin yaptığı işi anlayacak kadar teknik bilgiye sahip olmanın yanında proje/operasyona uygun yöntemleri takip edebilecek, standartlara uyum sağlayabilecek vizyonda ise başarı gelir. Aksi takdirde bugün denediğimiz trend yarın çöp olur, tıpkı dünün trendinin bugün yüzüne bakılmadığı gibi.