Bulut Dediler, Üstümüzden Geçti: Türkiye’de Cloud Geçişinin Acı Gerçekleri
İçindekiler
Giriş: Gökyüzüne Bakarken Cüzdanı Düşürenler
Cloud’un sihrine kapılan yöneticiler
Hype mı, ihtiyaç mı?
Cloud = Ucuzluk Efsanesi
TCO (Toplam Sahip Olma Maliyeti) hesaplamayanlar kulübü
Lisans maliyetleri ve danışmanlık kabusu
Kopyala-Yapıştır Cloud Stratejileri
ABD'den ithal vizyonlar, yerli felaketler
Türkiye gerçekleriyle uyuşmayan mimariler
Gizli Masraflar ve Açık Kalan Portlar
Egress ücretleri, yedekleme masrafları, güvenlik boşlukları
“Sunucuyu kapatmayı unuttuk” vakaları
Cloud Native mi, Cloud Tourist mi?
Sadece “lift & shift” yapanların ibretlik hikâyeleri
Aslında sadece veri merkezini taşıyan firmalar
Veri Nerede, Kimde, Kiminle?
KVKK, GDPR, data residency sorunları
Multicloud karmaşası içinde kaybolan şirketler
Cloud’a Geçtik, Ama Süreçler Hâlâ Analog
Sistem dijital, ama onay hâlâ WhatsApp'tan
Süreç dijitalleşmedikçe teknoloji yetim kalır
Yöneticinin Cloud ile İmtihanı
CIO’lar “bulut” anlatıyor, CFO’lar “niye bu kadar pahalı” diyor
Yönetim kuruluna PowerPoint bulutu satmak
Sonuç: Bulutun Üzerine Basmadan Yükselmek
Gerçekçi planlar, kademeli geçiş ve kurum içi eğitim
Cloud, bir hedef değil; bir araçtır
1. Giriş: Gökyüzüne Bakarken Cüzdanı Düşürenler
Cloud’un sihrine kapılan yöneticiler
Köln Üniversitesi Bilgi Sistemleri yüksek lisansından çıkıp, AWS üzerinde CI/CD boru hatları kurduğum, Kubernetes’le pod üstüne pod dizdiğim günlerden sonra Türkiye’ye döndüm ve kendimi— SAP danışmanlığı gibi dışında tutamadım—ve istesem de istemesem de bu cloud işlerinin tam göbeğinde buldum. İstemesem de bulaştım yani… Yoksa ben gayet mutluydum YAML dosyalarımla baş başa.
Şimdi biraz kral çıplak diyelim sevgili dostum. Türkiye’de teknolojiye bulaşmak demek, sadece sistem kurmak değil; bazen mitlerle, bazen de epik yanlış anlamalarla boğuşmak demek. Cloud da bu konuda tam bir altın madeni… Kimi için modernlik göstergesi, kimi için “rakip yaptıysa biz de yapalım” motivasyonu. Ama çoğu zaman ortak noktaları şu: Ne yaptığını bilmeden geçmek.
Yıllar içinde öyle traji-komik anılar biriktirdim ki... Üzerine kitap yazsam, IT bölümü ağlarken satış bölümü güler. Bu yazıda bazılarına değineceğim. Ama esas olarak;
Cloud’un Türkiye’de neden hâlâ bir “yanlış anlama festivali” olarak yaşandığını,
Hayal kırıklıklarının nasıl teknik hatadan çok zihinsel bir hazırlık eksikliğinden kaynaklandığını,
Ve en çok da bu işin moda değil, mimari bir farkındalık meselesi olduğunu anlatacağım.
Hazırsan başlayalım. Çünkü bu bulut hikâyesinde çoğu zaman gökyüzü değil, kafalar karışık.
Ben Köln Üniversitesi’nde yüksek lisans yaparken; bulut sistemleri sadece bir PowerPoint slaytı değil, sistem mimarisinin kemiğiydi. Uygulamalı projelerde AWS üzerinde load balancer’dan IAM politikasına kadar her şeyi ellerimle kurcaladım. CI/CD boru hatları kurduk, Kubernetes üzerinde production deployment yaptık. Mezuniyetten sonra Almanya’da bir e-ticaret şirketinde DevOps mühendisi olarak canlı sistemleri buluta taşıdım. Gerçek “cloud geçişi” nedir, onu iliklerine kadar yaşadım.
Buradan bakınca Türkiye’deki geçiş çabaları bazen çok... naif geliyor. “EC2 açınca bulutta oluyoruz sanan” yöneticilere anlatacak sabit IP’m kalmadı.
Hype mı, ihtiyaç mı?
Cloud, ehil ellerde roket yakıtıdır; bizde ise eşeğe Ferrari logosu yapıştırmak. “Rakip firma AWS’e geçmiş”, “Holding Azure’a imza atmış”, “Danışman GCP dedi”—tamam da kardeşim, senin uygulama monolit mi, stateless mi, yoksa bir muhasebe Frankenstein’ı mı? Veritabanın replikasyon mu bekliyor, ölümü mü? Bandwidth’i ölçen yok; konuşma döner dolaşır, “öğle yemeğinde kuzu tandır mı yiyelim tavuk mu?”ya bağlanır.
Gerçek sorun şu: Cloud geçişi teknoloji değil, psiko-sosyolojik evrim. Ama bizde ‘ihtiyaç analizi’ yerine hala “Sunucuları başka yere alalım, fatura da mümkünse üç ay sonra gelsin” mantığı hâkim. Netice?
Hype treninin ilk virajda teker patlar, lokomotif CFO’nun üzerine devrilir.
Üç ay geçer, aynı yönetici “Niye bu kadar pahalı oldu?”, “Dashboard niye açılmıyor?” diye inler. Çünkü mesele sadece EC2 açıp “buluta geçtik” tweet’i atmak değil; mesele bulutun mantığını iliklerine kadar içselleştirmek.
Türkiye’de eşitsiz denklem:
Cloud = (Sunucu + Moda) / Zihinsel OlgunlukCloud = (Sunucu + Moda) / Zihinsel Olgunluk
Sonuç hep < 1 çıkıyor; o yüzden daha yolun başında cüzdanı değil, niyetini düşüren kurum çok.
Dakika 1 – “Türkiye’ye Geldiğim İlk Yıllardan bir anım..
(2012’nin son çeyreği; AWS’in henüz “Classic Load Balancer” dediğimiz günler)
Almanya’daki DevOps mesailerinin ardından Türkiye’ye dönüşümün ilk aylarıydı. Bir perakende şirketi, “Amazon EC2 açınca ERP hızlanır” efsanesine kapılmış. SAP ECC, web mağazası ve Oracle RAC hepsi tek datacenter’da; gece-gündüz fan uğultusu. Yönetim kurulunda karar: “Hafta sonu hepsini AWS’e taşıyoruz, hem de kesintisiz!”
Teknik tablo
Cumartesi 23:00: rsync başlıyor, kimse replication lag ölçmüyor. Pazar 04:30: EC2’ler kalktı diyoruz; fakat security group’larda 1521 portu kapalı, SAP logon ekranı kara ekran. Saat 06:00: DNS hala eski IP’yi çözünce kullanıcıların yarısı eski, yarısı yeni veritabanına yazıyor—split-brain.
08:15: CRM yöneticisi arıyor: “Müşteri sayıları çift görünüyor, kampanya bütçesi ikiye katlandı!” 09:00’da CFO: “AWS faturası dakikada dolar sayıyor, ama site satır satır hata veriyor; tasarruf nerede?”
Çözüm: Eski sunucuların elektrik fişi çekilmemişti, kablo geri takıldı; ben de Point-in-Time Restore ile RDS’i cumartesi 22:59’a çektim. Kaybolan siparişler Excel’de VLOOKUP’la avlandı. Pazartesi sabahı yönetim, “Geçişi başarıyla test ettik, bir sonraki denemeyi planlıyoruz” diye bülten yayınladı.
Ders: Cloud “ucuz” veya “havalı” diye değil, tasarlanmış süreç ve ölçülmüş gereksinim için seçilir. DNS TTL’i düşürmeden “kesintisiz geçiş” diyen, bulutun değil adrenalin’in peşindedir.
Ve o gün anladım: Türkiye’de bulut göçü, çoğu zaman teknik bir sprintten çok, organizasyonel olgunluk sınavı. Sunucuyu değil, önce fikri taşımazsanız faturayı da, veriyi de, sinirleri de yakarsınız.
2. Cloud = Ucuzluk Efsanesi
TCO (Toplam Sahip Olma Maliyeti) Hesaplamayanlar Kulübü
Türkiye'de birçok şirkette bulut geçişiyle ilgili ilk cümle şu oluyor:
“Abi, sunucuları AWS'e alalım; hem daha ucuz, hem daha havalı.”
Sanki bulut, bir “Black Friday” kampanyasıymış gibi. Ama hiçbir Excel'de TCO (Toplam Sahip Olma Maliyeti) hücresi yok. Hâlbuki işin içinde sadece EC2 fiyatı yok; egress ücretleri, snapshot saklama, veritabanı lisansları, support paketleri, trafik artışları, region farklılıkları, monitoring araçları ve tabii ki insan kaynağı var.
Üstelik işin ironik yanı: Cloud’a geçerken ilk yıl IT bütçesi genelde %30-50 artar. Ama bu önceden söylenmez. Çünkü TCO konuşulmaz.
Geçen yıl bir projede, migration sonrası fatura görünce CFO şöyle dedi:
“Biz bunu donanım almayalım diye yapmadık mı? Her ay donanım alıyormuşuz gibi bir şey bu!”
Evet, haklı. Çünkü cloud, operational expense (OPEX) olarak görünür ama, strategic düşünülmezse sadece bitmeyen bir kira olur.
Lisans Maliyetleri ve Danışmanlık Kabusu
Şimdi gelelim işin bir başka karanlık köşesine: Lisanslar. Özellikle veritabanı ve middleware tarafı. Cloud’da eski sistemleri lift-and-shift yapınca, onlar da geliyor tabii: Oracle, SAP, Windows Server, Red Hat abonelikleri...
Bir müşteride gördüm: EC2’ye geçiş yapılmış ama hâlâ on-prem lisans modeliyle ödeniyor. Çünkü bulut için ayrı lisanslama gerekiyor, ama bunu kimse projede düşünmemiş. Sonuç? Aynı ürüne çift lisans parası ödenmiş.
Danışmanlık tarafı da ayrı bir bahis. Her cloud provider kendi “sertifikalı partner” ordusuyla geliyor. Ama o partnerler çoğu zaman sadece sertifika koleksiyoncusu. Gerçek kullanım tecrübesi değil, satış odaklı “best practice” slaytları var.
Projenin 4. ayında müşteri “Biz hâlâ niye staging’deyiz?” diye sorunca, danışman cevap veriyor:
“Çünkü production ortamı için Terraform modülleri tamamlanmadı. Bir de IAM policy’lerde naming standardı tartışılıyor...”
Yani “maliyet düşsün” diye çıkılan yolculuk, çoğu zaman lisans bataklığı, fazladan danışman faturası ve aylar süren mimari arayışlarıyla sonuçlanıyor.
Özet: Cloud ucuz değildir. Doğru planlanmazsa, pahalı bile değildir—tehlikelidir. Çünkü cloud geçişi sadece teknoloji değil; maliyet modelinin, sorumluluğun ve bilgi seviyesinin komple yeniden tasarlanmasıdır.
Ama bizde genelde formül şöyle:
Cloud = EC2 fiyatı + umut
Gerçek = EC2 + snapshot + egress + support + Terraform danışmanı + panik maili3 – Kopyala-Yapıştır Cloud Stratejileri
ABD'den İthal Vizyonlar, Yerli Felaketler
Bak sevgili dostum, şu “Silicon Valley’de böyle yapmışlar, biz de aynısını yapalım” hastalığı var ya... O, bizim sektörde bir virüs gibi. Her sunumda bir unicorn logosu, her mimari şemada bir Kafka, bir Kubernetes, bir EventBus havada uçuşuyor. Ama proje ekibine bakıyorsun: Frontend’ci bir stajyer, DevOps’çu bir YouTube mezunu, mimari sorumlusu da ERP'den yeni transfer. Yani vizyon ithal, ama ekip hâlâ “yaz gelsin” kafasında.
Bir gün toplantıda bir müdür “Uber bunu Serverless yapmış, biz de yapalım” dedi. Ben sordum:
“Abi, bizde hangi servis trigger olacak da fonksiyon çağıracak?” Cevap: “Henüz servis yok ama olursa hazırlıklı olalım.”
İşte tam burada başlıyor felaketin prototipi. Sıfırdan gelen veri akışı, monitoring yok, failover yok ama 12 katmanlı mimari çizilmiş. İnternetten indirilen Terraform template'leriyle cloud kurmaya çalışıyorlar. Sonuç: Sunucular açılıyor ama neden açıldıklarını kimse bilmiyor.
Türkiye Gerçekleriyle Uyuşmayan Mimariler
Kardeşim, mimari dediğin şey sadece teknoloji değil; organizasyonun, kültürün, alışkanlıkların toplamıdır. Ama bizde yapı şu:
Onay hala WhatsApp’tan
Süreç Excel'de
API'ler var ama dökümantasyon “abi sonra yazarız” seviyesinde
Test ortamı = “canlıda deneriz”
Böyle bir yapıya “Event-Driven Microservice” mimarisi kurarsan ne olur? Olmaz. Yani olur da... çalışır gibi olur. Ama ilk trafik yükselince, log ekranı Matrix'e döner, hata kodları yağar, sonra herkes sessizce yeniden monolit döner.
Bir şirkette gördüm, Kafka kurmuşlar. Ama tek bir producer var, consumer yok. Yani adamlar sadece veri yayınlayıp kendi kendilerine bakıyorlar. Dedim ki: “Peki bu logları kim okuyacak?” Cevap geldi: “Şimdilik yazıyoruz, okuyan çıkar.”
Arkadaşlar, cloud mimarisi böyle bir şey değil. Bu iş “yüksek teknolojiye özenme” meselesi değil. Önce ihtiyaç, sonra mimari, sonra ekip gelir. Yoksa o AWS logosunu oraya koymak, sadece faturayı büyütür; seni değil.
4 – Gizli Masraflar ve Açık Kalan Portlar
Egress Ücretleri, Yedekleme Masrafları, Güvenlik Boşlukları
Cloud’un en büyük yanılgısı şu: “Gidince ucuzluyor.” Gerçekte olan ise: “Gidince neye para ödediğini bile anlamıyorsun.”
Bir firmada e-ticaret uygulaması geçişi sırasında yaşadığımız tablo şöyleydi: Uygulama çalışıyor, evet. Ama müşteri görselleri S3’ten geliyor, videolar ayrı CDN’den, tüm trafik logları dış servislere gidiyor. Sonuç? Egress faturası, EC2 ücretinin tam 4 katı.
Kimse “biz bu veriyi dışarı ne kadar çıkarıyoruz” diye sormamış. Çünkü cloud faturası bizde hâlâ “kabaca tahmin edilir”, sonra ay sonunda “şaşırılır.”
Yedekleme desen ayrı dünya. Snapshot alınıyor, evet. Ama kim siliyor? Kim takip ediyor? Klasik cümle:
“Abi bir ara alınmıştı, duruyordur ya.”
Duruyor. Hem de güzelce fatura olarak duruyor. Haftalık alınan ama aylarca kullanılmayan snapshot’lar. Lifecycle policy yok. S3 klasöründe ne olduğunu kimse bilmiyor. Arada bir “delete” tuşuna basmaya korkuyorlar, çünkü neyin silineceğinden emin değiller.
Gelelim güvenlik meselesine… Test ortamı kurmuşlar; RDP açık, 22 numaralı port dışa açık, public IP üzerinden erişim serbest. IAM policy’lerde “FullAccess” verilmiş, kimse farkında değil. Firewall? Yok. Logging? Pasif. Log bakmak zaten bizde hâlâ “loglar dolmasın diye açılmayan şey” kategorisinde.
“Sunucuyu Kapatmayı Unuttuk” Vakaları
Gerçek bir olay: Geçtiğimiz yıl bir firmanın staging ortamı için 4 EC2 açılmış. Aradan 7 ay geçmiş, ortam kullanılmamış ama hâlâ çalışıyor. Toplamda 1.800 dolar fatura ödenmiş. Kimse fark etmemiş. Neden? Çünkü bu sunuculara isim bile verilmemiş: i-08x3randomxyz.
AWS Console'a giriyoruz, CPU %0.3. Network yok, disk IO sıfır. Kısacası bir “zombi makine”. Orada ama yaşayan bir sebebi yok.
Bu tespiti yaptıktan sonra ekibe sordum:
“Bunlar neden açık?” Yanıt: “Abi Ar-Ge bir test yapacaktı, sonra ne oldu bilmiyoruz.”
Ne oldu biliyor musun? Kapanmadı. Çünkü bizde cloud sunucuları genellikle açılır, ama nedense kapatılmaya utanılır. Tıpkı bir misafirlikte gitmeye çekinmek gibi: “Ayıp olmasın, dursun.”
Cloud’un en tehlikeli tarafı, gizli kalemlerin sessizce büyümesi. Bir bakmışsın snapshot’lar 2 TB olmuş. Bir bakmışsın aylardır çalışmayan bir sunucu faturanın %30’unu yiyor. Bir bakmışsın open port’tan içeri girilmiş, sen hâlâ staging’e production verisi yüklüyorsun.
Cloud teknolojisi kötü değil. Ama kontrolsüz bırakıldığında, seni değil, sadece kredi kartını optimize ediyor.
5 – Cloud Native mi, Cloud Tourist mi?
Sadece “Lift & Shift” Yapanların İbretlik Hikâyeleri
Cloud native olmak, uygulamanı cloud’un doğasına uygun biçimde yeniden tasarlamak demek. Ama bizim birçok şirkette bu kelimenin karşılığı hala şu:
“Abi mevcut sistemi alalım, EC2’ye kopyalayalım, çalışır zaten.”
Yani içeride 20 yıllık monolit var; cron job’lar hardcoded, log’lar dosyaya yazılıyor, kullanıcı oturumları sunucu belleğinde tutuluyor... Ama bunu alıp birebir EC2’ye taşıyınca, adı “cloud geçişi” oluyor. Tabelada değişiklik, mimaride sıfır oynama.
Bir projede şöyle oldu: SAP’nin yanında çalışan özel geliştirilmiş bir fiyat hesaplama motorunu alıp EC2’ye taşıdılar. Kullandığı veritabanı hala on-prem’de. Arada IPsec tüneli var, latency 300ms. İlk gün çağrı merkezi aradı:
“Sistem çalışıyor ama her şey 3 saniye geç geliyor, kullanıcılar panik oldu.”
Geç kalması değil mesele… Asıl mesele, hala “çalışıyor” denmesi.
Çünkü bizde sistem çökmeyince kötü çalışıyor olması “makul” kabul ediliyor.
Aslında Sadece Veri Merkezini Taşıyan Firmalar
Bu kopyala-yapıştır geçişlerin ortak bir yanı var: Veri merkezi taşınıyor ama alışkanlıklar yerli yerinde.
Monitoring Hala manuel.
Deploy hala dosya atma.
Geliştirici hala “ben prod’a girmem, ama log’a bakarım” kafasında.
Süreçlerin tamamı hala Excel’de tutuluyor.
Uygulama restart edince oturumlar siliniyor, çünkü hala sticky session var.
Bir şirkette "container’a geçtik" dediler. Girdim baktım: Docker container içinde Apache var, tek dosya, config içinde hardcoded IP’ler. Kubernetes yok, scaling yok, log forwarding yok. Ama dashboard’ta güzel bir pod ikonu var diye mutlu herkes.
Yani turistik gezi gibi… Gitmişken fotoğraf çekilmiş ama hiç yerel halkla konuşulmamış. Sistemi oraya götürmüşler ama davranışlar hala eski mahalle.
Cloud native olmak, teknolojik değil; kültürel bir dönüşüm. Kodun, verinin, yapının ve en önemlisi ekibin düşünme biçiminin değişmesi gerek.
Yoksa sadece veri merkezini taşırsın. Ve adını “dönüşüm” koyarsın. Ama gerçekte yaptığın sadece şunu söylemek olur:
“Biz aynı şeyi, daha pahalı bir yerde yapmaya başladık.”
6 – Veri Nerede, Kimde, Kiminle?
KVKK, GDPR, Data Residency Sorunları
Türkiye’de cloud denince, genelde ilk sorulan şu oluyor:
“Sunucular nerede?”
Ama bu soru çoğu zaman sadece merak düzeyinde kalıyor. Çünkü cevabı bilen yok.
Şirketler veriyi taşıyor ama taşınan şeyin ne olduğu, nerede durduğu ve hangi regülasyona tabi olduğu konusunda ya hiçbir bilgiye sahip değil ya da “biz danışmandan duyduk” seviyesiyle yetiniliyor.
Örneğin: KVKK’ya göre kişisel veri yurt dışına çıkarılacaksa açık rıza, yeterli ülke, ya da kurul onayı gibi yollar şart. Ama birçok firmada S3 bucket’ı Frankfurt’ta, RDS Dublin’de, Lambda’lar Paris’te… Hiçbir kullanıcıdan rıza alınmamış. Hatta kullanıcı verisinin hangi sistemde durduğu bile belli değil.
Bir şirkette veritabanını AWS Aurora’ya taşıdılar. Region: Stockholm. Sebep? “Developer Stockholm’de yaşıyor, latency düşük olsun diye.” Peki KVKK?
“Onu legal bakar.”
Bakmaz. O veri gitti. Ve sen muhtemelen KVKK’ya değil, mahkemeye bakarsın bir gün.
GDPR desen ayrı bir dünya. Bir AB vatandaşı Türk e-ticaret sitesinden sipariş veriyor, verisi Avrupa dışına çıkıyor, ama şirketin veri sorumlusu kim, belli değil. DPO atanmış mı? Hayır. Kayıt silme, veri taşınabilirliği, izleme kayıtları? Yok. Ama “biz buluta geçtik” diye basın bülteni hazır.
Multicloud Karmaşası İçinde Kaybolan Şirketler
Son yılların en gözde moda akımı: Multicloud. Çok havalı. AWS + Azure + GCP. Sanki cloud olimpiyatı yapıyoruz.
Ama içeride durum şöyle: – Log’lar AWS CloudWatch’ta – Sunucular Azure’da – CDN GCP’de – Ve kimse bütün sistemin nereden ne yaptığını tam olarak bilmiyor.
Bir gün prod ortamı çöktü. Sebebi: GCP üzerindeki Cloud DNS kaydı güncellenmemiş. Ama ekibin %90’ı AWS’e bakıyor, kalanlar Azure ile uğraşıyor. DNS’i kim tutuyor?
“Galiba Barış Bey ilgileniyordu, ama işten ayrıldı.”
Yani sistemi 3 ayrı kıtaya yaymışsın ama hala IT sorumluluğu kişilere endeksli. “Cloud’dayız” diyorsun ama dependency management hala kahve molasında konuşuluyor.
Sonuç: Veri sadece bir dosya değil. Onun saklandığı yer, işlendiği sistem, geçtiği yol hepsi sorumluluktur. Cloud geçişi sadece bir teknoloji seçimi değil, aynı zamanda hukuki bir taahhüttür. Sen veri merkezini taşıyınca kurtuldum sanırsın ama aslında veri seni taşır.
Ve eğer verinin nerede, kimde, hangi şartla durduğunu bilmiyorsan… O veri bir gün karşında delil olarak durabilir.
7 – Cloud’a Geçtik, Ama Süreçler Hâlâ Analog
Sistem dijital, ama onay hala WhatsApp'tan
Bir firmaya giriyorsun, cloud geçişi tamamlanmış. EC2'ler tıkır tıkır çalışıyor, Kubernetes cluster ayakta, Prometheus-Grafana panelleri dashboard’da dans ediyor. Ama biraz içeriyi kurcalayınca tablo şöyle:
Tedarik onayı WhatsApp grubunda,
Satış hedefleri Excel'de tutuluyor,
Fiyat teklifi hala Word dosyasında ve imza için yazıcı kuyruğuna düşüyor.
“Cloud’a geçtik” demek kolay. Ama “dijital dönüşüm” dediğimiz şey sadece teknolojiyi dışa aktarmak değil, kültürü içeriye entegre etmektir.
Sistem ne kadar dijital olursa olsun, süreç hala analogsa o sistem yetim kalır. Kimsesiz. Sahipsiz. Ve gün gelir, kendisine bağlı olmayan bir karar süreci yüzünden başarısız ilan edilir.
Bir müşteride gördüm: Kargo yönetimi için AWS üzerinde süper bir mimari kurmuşlar. Event-driven, serverless, real-time alert sistemleri… Ama depoda kargoya çıkacak liste hâlâ Excel’de hazırlanıyor ve kuryeye WhatsApp’tan atılıyor.
Bir noktada sistem alarm verdi: “Paket çıkmadı.” Araştırdık, çıkmış. Ama sistem onu görmüyor çünkü Excel’le dijital sistem arasında hiçbir entegrasyon yok. Yani cloud çalışıyor ama süreç hala kağıt üstünde.
Ne oldu? Yönetim cloud sistemini suçladı.
“Bu sistem doğru veri göstermiyor.”
Hayır dostum. Sen sistemi dijitalleştirdin ama davranışı değiştirmedin. Veriyi uçurdun ama süreci hala yerde süründürüyorsun.
Süreç dijitalleşmedikçe teknoloji yetim kalır
Bir şirkette teknoloji yatırımı yapılır, dashboard kurulur, RPA gelir, CRM entegre edilir... Ama kurumun refleksi değişmedikçe tüm bu altyapı bir “güzel vitrin” olmaktan öteye geçemez.
Yani dışarıdan bakınca “dijital dönüşüm yapılmış” gibi görünür, ama içeride hala
"Abi yazdırayım, imzalatayım, tarayayım” zinciri,
“Ben onun mailini print ettim, yanımda taşıyorum” cümlesi,
Ve en kötüsü: “Biz her ihtimale karşı yine de manuel de tutuyoruz.”
Bunlar oldukça, o cloud sistemi en fazla mahalledeki wifi router'ı kadar işe yarar. Çünkü teknolojinin en güçlü olduğu an, süreçle konuşabildiği andır.
Yoksa ne kadar güçlü olursa olsun, o sistem bağlantısız bir organ gibi çürümeye mahkûmdur.
O yüzden, cloud’a geçmek bir milat değil. Gerçek dönüşüm, kurumun kendi reflekslerini de dönüştürmesiyle başlar.
Yani sadece sistemi değil; • Onayı, • Takibi, • Sorumluluğu, • Hatta iletişim dilini de yeniden kurgulamak gerekir.
Aksi takdirde, “cloud’a geçtik” dediğiniz yapı sadece modern bir kaos olur. Renkli panelleri olan, ama kararları yine “grup mesajında ping’leyerek” verilen bir kaos.
8 – Yöneticinin Cloud ile İmtihanı
CIO’lar “bulut” anlatıyor, CFO’lar “niye bu kadar pahalı” diyor
Yıllardır aynı tabloyu görüyorum: CIO sunuma girer, ekranda bir AWS mimari diyagramı, içinde renkli kutular: EC2, Lambda, RDS, Route 53… Cümleye şöyle başlar:
“Dijitalleşiyoruz. Artık her şey bulutta.”
Sunum devam eder. SLA’lardan, uptime’dan, global entegrasyonlardan bahsedilir. Araya Gartner raporu da sıkıştırılır tabii, çünkü "başkaları da yapmış" argümanı hala en güçlü silahtır.
Sonra odaya CFO döner:
“Güzel ama... bu ay AWS’ye 147 bin TL ödemişiz. Bu nasıl oldu?”
Sessizlik. CIO cevap verir:
“Ama amortisman yok.” CFO: “Fatura var.” CIO: “Fiziksel bakım yok.” CFO: “Kur farkı var.” CIO: “Esnek altyapı.” CFO: “Esnek mi? Her ay daha fazla geliyor.”
İşte burada mesele artık teknolojiden çıkıp, anlayış farkına girer. Çünkü IT tarafı bulutun teknik esnekliğine, finans tarafı ise ay sonu PDF’ine bakar. Bu iki dünya birbirine yaklaşmadıkça, cloud hep “pahalı oyuncak” gibi görünür.
Oysa gerçek şu: Bulut, doğru kullanıldığında maliyeti değil, verimsizliği azaltır. Ama kimse ölçmüyorsa, raporlamıyorsa, kaynakları yöneten yoksa... O zaman evet, faturası da büyür, tartışması da.
Yönetim kuruluna PowerPoint bulutu satmak
Cloud projelerinde belki de en büyük sınav, teknolojiyi anlatmak değil; anlamayanlara “mış gibi” anlatmaktır. Bir CIO olarak girdiğiniz yönetim kurulu toplantısında, slaytlar arasında dolanırken şunu fark edersiniz: Kimse EC2’nin ne olduğunu sormuyor, herkes “ne kadar tuttu?”yu bekliyor.
O yüzden sunumlar hep şöyle hazırlanır:
Başlangıç: Vizyon, inovasyon, global örnekler
Orta kısım: Renkli kutular, flow diyagramları
Son: “Bu yatırım bize çeviklik kazandıracak” temalı kapanış
Ama içeride bir kişi vardır ki sunumu beklemez, doğrudan mail atar:
“Bu bulutun ROI’si nedir? Kaç günde kendini amorti eder?”
İşte tam orada PowerPoint biter, gerçek başlar.
Çünkü yönetim kuruluna teknoloji satılmaz. Risk azaltımı, hız ve müşteri memnuniyeti satılır. Ama bunları da ölçmeden, raporlamadan, sadece güzel sunumla anlatmaya çalışırsan… Bulut projesi bir süre sonra “o pahalı iş” olarak hatırlanır.
Yönetici tarafında cloud bir dönüşüm değilse, bir çarpışmaya dönüşür. CIO vizyon anlatır, CFO Excel açar. CEO ortada kalır: “Yatırımı yaptık, ama çalışanlar hala Excel gönderiyor” diye dertlenir. Yani sadece sistemi değil, anlatım biçimini ve değer algısını da dijitalleştirmek gerekir.
Yoksa o bulut, şirketin üstünden geçer geçer, ama altına bir damla bile bırakmaz.
9 – Sonuç: Bulutun Üzerine Basmadan Yükselmek
Gerçekçi planlar, kademeli geçiş ve kurum içi eğitim
Cloud… öyle sihirli bir kutu değil. Basitçe söyleyelim: Cloud geçmek, önce ayakkabıyı çıkarmayı bilmekle başlar. Yani eski alışkanlıkları sorgulamakla, süreçleri anlamakla, nereye ne için geçtiğini gerçekten tartışmakla.
Bu işin sihri, EC2 açmakta, Kubernetes kurmakta, Terraform dosyası yazmakta değil. Gerçek sihir, neye ihtiyaç olduğunu anladığında başlıyor.
O yüzden doğru yol:
Gerçekçi planlar
Kademeli geçiş
Ve en önemlisi: kurum içi eğitim Yani “hangi tool’u kullanacağız?” sorusundan önce, “neden bu tool’a ihtiyaç duyuyoruz?” sorusunu sormak.
Geçiş bir gecede olmaz. İyi bir cloud yolculuğu, mimariyle başlar ama kültürle devam eder. Çünkü teknoloji ne kadar güçlü olursa olsun, onu taşıyan zihniyet ala 1998 modelse, o sistem bir yere gitmez. Sadece daha pahalı olur.
Cloud, bir hedef değil; bir araçtır
Cloud’a geçmek, bir hedef değildir. Cloud, tıpkı elektrik, internet ya da ulaşım gibi bir altyapıdır. İşin sonunda sana hız kazandırmalı, esneklik sunmalı, maliyetini yönetilebilir hale getirmeli. Ama bunları yapmıyorsa, sadece modaya uymuşsundur. Bazen de pahalıya patlayan bir vitrin yatırımı yapmış olursun.
Her şirketin yolculuğu farklıdır. Aynı çözüm her yerde aynı sonuçları vermez. Ama ortak olan tek şey şudur: Cloud’a geçmeden önce, oraya ait olup olmadığını anlamak gerekir.
Yoksa yükseldiğini sanırken, sadece başının döndüğünü fark edersin.
Eğer buraya kadar geldiysen, okurken hem gülümsediğini hem de “bizde de aynısı oldu” diye iç geçirdiğini tahmin edebiliyorum. Ben bu yazıyı bir teknoloji manifestosu gibi değil, yılların içinden süzülmüş bir sağduyu çağrısı gibi kaleme aldım. Kimi satırlarında anılar vardı, kimi satırlarında hayal kırıklıkları. Ama hepsinde gerçek vardı.
Cloud yolculuğu teknik olduğu kadar insani bir yolculuktur. Ve bu yolculukta en çok ihtiyaç duyduğumuz şey, dürüstlük ve öğrenme isteği.
Vakit ayırıp okuduğun için teşekkür ederim. Eğer bu satırlar sana bir fikir verdiyse, bir kafa açtıysa ya da sadece bir tebessüm bıraktıysa, benim için yeter.
Bir sonraki yazıda yeniden görüşmek üzere.
Yorumlar
Yorum Gönder