Low-code Platformlar Vatandaş Geliştiriciyi Özgürleştirir — Ama Yönetişim Çerçevesi Yoksa Sadece Gölge BT’nin Lisanslı Versiyonunu Üretir

Satış ekibi Power Apps lisansını aldıktan 6 hafta sonra, Ankara merkezli 295 çalışanlı bir sigorta aracı kurumunun tek BT sorumlusu masasında 14 yeni uygulama talebiyle karşı karşıya kaldı. Bu uygulamaların 9’u şirket veri kaynaklarına bağlanmak istiyordu; 3’ü ise o tarihe kadar yalnızca üst düzey satış müdürlerinin görebileceği poliçe kârlılık verilerine erişim talep ediyordu. Sistem kilitlenmemişti, kimse kötü niyetli değildi. Ortadaki sorun başkaydı: low-code platformu satın almak, onu yönetmek anlamına gelmez.Vatandaş geliştirici (citizen developer) hareketi, 2018’den bu yana kurumsal teknoloji gündeminin kalıcı bir parçası haline geldi. Temel fikir şu: Kod yazmayı bilmeyen bir satış müdürü, lojistik planlayıcısı veya insan kaynakları uzmanı, sürükle-bırak arayüzlere sahip low-code platformlar aracılığıyla kendi iş uygulamalarını geliştirebilir. Microsoft Power Platform, Mendix, OutSystems gibi araçlar bu hareketi kurumsal ölçeğe taşıdı. Mantığı açık: BT bekleme kuyruğunu kısalt, iş birimlerine özerklik ver, dijital dönüşümü merkezden değil kenarlardan büyüt. Sorun bu fikrin yanlış olmasında değil; arkasındaki yönetişim çerçevesinin çoğu kurumda hiç kurulmamasında.Türkiye’deki KOBİ gerçeği bu harekete ayrı bir dinamik katıyor. BT departmanı ya yok ya da 1-2 kişiden oluşuyor; yazılım harcamaları döviz bazlı ve 2022’nin enflasyon ortamında bu maliyet neredeyse her çeyrekte yeniden hesaplanıyor. Dışarıdan özel uygulama geliştirme pahalı; özelleştirilmiş ERP modülleri 4-6 aylık proje takvimi istiyor. Bu koşullarda satış müdürünün kendi uygulamasını geliştirmesi fikri sadece cazip değil, çoğu şirket için zorunluluk gibi görünüyor. Ancak bu pragmatizm, platforma verilen lisansın bir yönetişim çerçevesiyle desteklenmesi zorunluluğunu ortadan kaldırmıyor. Tam tersine, BT kaynağı az olan kurumlar için yönetişim boşluğu daha tehlikeli bir hale geliyor; çünkü sorun büyüdüğünde düzeltecek kapasite de yok.Gölge BT, yani IT departmanının onayı ve bilgisi dışında kullanılan yazılım ve sistemler, 2000’lerin ortasından bu yana kurumsal güvenliğin kronik sorunlarından biriydi. Biri şirket dosyasını Dropbox’a attı, biri WhatsApp üzerinden müşteri verisi paylaştı, biri kişisel Google hesabıyla teklife müşteri verisi bağladı. Low-code platformları bu sorunu köklü biçimde çözmedi; platforma verilen kurumsal lisans bir meşruiyet hissi yarattı ama aynı riski farklı bir kılık altında devam ettiriyor. Fark şu: eski gölge BT görünmezdi ve IT departmanının radarının dışında kalıyordu; yeni nesil ise şirketin kendi lisansladığı platform üzerinde işliyor ve bu yüzden daha kabul edilebilir görünüyor. Daha kabul edilebilir görünmesi, daha az riskli olduğu anlamına gelmiyor.Gaziantep’te makine imalatı yapan orta ölçekli bir fabrikada üretim planlama ekibi — temsili bir vaka olarak paylaşıyorum — vardiya takip uygulamasını low-code araçlarıyla 11 günde hayata geçirdi. Aynı iş ERP özelleştirmesiyle 4-5 aylık proje sürecine girecekti; üstelik özelleştirme maliyeti mevcut bütçeye sığmıyordu. Fayda gerçek ve somut. Ancak bu faydanın gerçekleştiği ortamda veri erişim kuralları önceden yazılmıştı; uygulama canlıya alınmadan bir BT onay adımından geçmişti; uygulama sahibi olarak fabrika müdürünün adı kayıt altına alınmıştı. Bu koşullar olmadan aynı süreç farklı bir sonuca varırdı. Low-code’un getirdiği hız, çerçeve olmadan sürdürülebilir değil.Şimdi asıl soruna gelelim: 2022 Türkiye’sinde low-code benimsemesinde hangi noktalar en çok sorun çıkarıyor? Veri erişim sınırlarının belirsizliği birincil kırık nokta. Bir satış uzmanının kendi ekibinin satış hunisi verilerine erişmesi normaldir; şirketin tüm fiyatlandırma parametrelerine veya rekabetçi teklif geçmişine erişmesi değil. Ama low-code platformlarda bu sınır varsayılan olarak tanımlı gelmiyor. Kullanıcı bağlantı sihirbazında hangi veri kaynağını görebiliyorsa onu seçiyor. Ankara’daki sigorta vakasında tam olarak bu yaşandı: hasar takip verisi ile poliçe kârlılık verisi aynı API bağlantısı üzerinden erişilebilir durumdaydı ve ikisi arasında hiçbir izin katmanı yoktu.İkinci kırık nokta uygulama yaşam döngüsü sahipsizliği. Vatandaş geliştirici uygulamayı kurar, birkaç ay çalışır, sonra o kişi başka bir role geçer veya şirketten ayrılır. Uygulama çalışmaya devam eder ama sahibi kalmaz. Kim güncelleyecek? Kim sorun giderecek? Kim kapatacak? Türkiye’de devir hızının yüksek olduğu sektörlerde — perakende, çağrı merkezi, lojistik — sahipsiz uygulama yığını hızla büyüyor. Platform yöneticisi bu uygulamaların %79’unun hiçbir zaman resmi olarak kapatılmadığını fark ettiğinde genellikle iş büyümüş oluyor. (Bu oran, benzer vakalarda tutarlı biçimde karşılaştığım örüntüden geliyor; kamuya açık bir araştırma verisi değil.)Üçüncü kırık nokta KVKK uyum kör noktası. Kişisel veri içeren bir iş akışı vatandaş geliştiricinin uygulamasına taşındığında, o akışın KVKK kapsamında değerlendirilmesi gerektiği çoğu zaman fark edilmiyor. Veri işleme kaydı güncellenmiyor, aydınlatma metni gözden geçirilmiyor, veri aktarım güvenliği sorgulanmıyor. BT departmanı süreçten dışarıda kaldığı için bu kontroller kendiliğinden düşüyor. 2022 itibarıyla KVKK denetimleri sektör bazlı yoğunlaşıyor; önümüzdeki yıllarda bu kör noktanın ağır bir yük haline gelebileceğini öngörmek için kâhin olmak gerekmiyor.Low-code altyapısını yönetmek için Pazartesi sabahı uygulanabilecek üç somut adım var. Birincisi, veri sınıflandırması ve erişim haritası çıkarmak: hangi veri kaynağına kimin, hangi koşulda bağlanabileceği yazılı hale getirilmeli. Bu belge olmadan low-code izni vermek, deponun anahtarını dağıtmak ama içini düzenlememek gibi. İkincisi, uygulama onay katmanı kurmak: bir çalışanın geliştirdiği uygulama canlıya alınmadan en az iki kontrol geçmeli — veri erişimi uygunluğu ve KVKK kapsam değerlendirmesi. Bu iki kontrol için karmaşık bir süreç şart değil; 12-15 soruluk yapılandırılmış bir form ve BT sorumlusunun 30 dakikası yeterli. Üçüncüsü, sahiplik kaydı tutmak: her uygulama için bir sorumlu atanmalı ve bu kayıt merkezi bir tabloda güncel tutulmalı. Kişi şirketten ayrılırken söz konusu uygulama ya yeni bir sahibe devredilmeli ya da kapatılmalı. Başka seçenek yok.Ankara’daki sigorta kurumunun BT sorumlusu o 14 uygulamanın 6’sını onayladı, 5’ini veri erişim kısıtlamalarıyla revize etti, 3’ünü kapattı. Tüm süreç 3 hafta aldı. Asıl zaman kaybı bu değerlendirme değildi; daha önce yapılmayan politika çalışmasıydı. Low-code hızı gerçek ve anlamlı bir değer taşıyor. Ama bu hız, ancak kurumun hangi veriye kimin dokunamayacağını bildiği ve bu bilgiyi yazılı bir çerçeveye döktüğü sürece sürdürülebilir oluyor. Aksi halde platform, özgürleştirici bir araç değil, yönetilemeyen karmaşanın kurumsal onaylı versiyonuna dönüşüyor. Şirketinizde bugün kaç tane sahipsiz low-code uygulaması çalışıyor? Bu sorunun cevabını bilmiyorsanız, oradan başlayın.