Bir perakende zincirinin İstanbul’daki operasyon müdürü, mağaza bazlı stok takibini iyileştirmek için BT birimine talep açıyor. Kuyruktaki onlarca proje arasında bu talep üç ay bekliyor. Sabırsızlanan müdür, no-code bir platform üzerinde kendi çözümünü geliştiriyor; iki hafta içinde çalışır hale getiriyor. Başarı hikayesi gibi görünen bu tablo, kurumun BT yöneticisi için farklı bir anlam taşıyor: Hangi verilere erişiliyor? Yedekleme var mı? Müdür işten ayrılırsa bu uygulama ne olacak? No-code araçların iş birimlerine kazandırdığı hız gerçek; ancak bu hızın kurumsal kontrol mekanizmaları olmadan büyümesi, çözülen sorundan daha büyük sorunlar yaratıyor. Mesele, iş birimlerini kısıtlamak değil; hangi sınırlar içinde özgür olduklarını net biçimde tanımlamak.
No-code platformlar, kod yazmadan görsel arayüzlerle uygulama geliştirmeye olanak tanıyan araçlardır. Formlar, iş akışları, basit veri tabanları, bildirim sistemleri ve raporlama ekranları bu araçlarla saatler içinde kurulabiliyor. Türkiye’de özellikle 2018-2019 döneminde bu platformlara olan kurumsal ilgi belirgin biçimde arttı; kur baskısının yazılım bütçelerini kıstığı bir ortamda, iş birimlerinin kendi çözümlerini üretme isteği güçlendi. Ancak platformun sunduğu kolaylık, yönetişim sorununun da kaynağı. BT’nin onaylamadığı, veri mimarisine entegre edilmemiş, güvenlik denetiminden geçirilmemiş uygulamaların kurumsal ortamda çoğalması; uzun yıllardır savaşılan ‘gölge BT’ (shadow IT) sorununu farklı bir kılıkta geri getiriyor. No-code araçlar bu sorunu ortadan kaldırmıyor; yalnızca erişim eşiğini düşürüyor.
Bu noktada kurumların ihtiyaç duyduğu şey bir yasak değil, bir sınıflandırma çerçevesi. Uygulamaları kritiklik düzeylerine göre katmanlara ayırmak, hem iş birimlerine anlamlı bir özgürlük alanı açıyor hem de kurumsal riskleri yönetilebilir tutuyor. Birinci katman; yalnızca bir kişinin veya küçük bir ekibin kullandığı, kurumsal sistemlere doğrudan bağlanmayan, müşteri veya finansal veri içermeyen kişisel verimlilik araçlarıdır. Bu katmanda iş birimi tam özerk olabilir; BT onayı gerekmez. İkinci katman; birden fazla departmanı etkileyen, ortak veri kullanan veya süreç entegrasyonu gerektiren uygulamaları kapsar. Burada iş birimi geliştirme yapabilir; ancak BT mimarisiyle uyumlu şablonlar içinde ve belirli kontrol noktalarından geçerek. Üçüncü katman ise finansal işlemler, müşteri kişisel verileri veya yasal raporlama içeren kritik uygulamalardır. Bu katmanda geliştirme yetkisi BT’de kalır; iş birimi yalnızca gereksinim sahibidir.
Kademeli yetki modelinin işe yaraması için sınıflandırmanın yazılı ve herkes tarafından anlaşılır olması gerekiyor. Türkiye’deki pek çok kurumda bu tür çerçeveler ya hiç yok ya da BT departmanının iç dokümanlarında gömülü kalıyor; iş birimleri neyin serbest neyin yasak olduğunu bilmiyor. Sonuç: ya her şeyi BT’ye soruyor ve yavaşlıyor, ya da hiçbir şeyi sormadan ilerliyor ve risk yaratıyor. İyi tasarlanmış bir yetki modeli, iş biriminin uygulamasını başlatmadan önce beş ila on dakikada yanıtlayabileceği bir kritiklik anketi içermeli. ‘Bu uygulama KVKK kapsamında kişisel veri işleyecek mi?’, ‘ERP veya muhasebe sistemiyle veri alışverişi yapacak mı?’, ‘Birden fazla departman bu uygulamaya bağımlı olacak mı?’ gibi sorular, uygulamayı doğru katmana yerleştiriyor ve süreç başlamadan önce doğru denetim mekanizmasını devreye sokuyor. KVKK’nın 2018’de yürürlüğe girmesiyle birlikte kişisel veri işleyen her uygulamanın bu soruyu atlaması artık yasal bir risk.
Yetki modelinin sürdürülebilir olması için teknik altyapının da buna göre kurulması gerekiyor. İş birimlerine açık no-code platformların kurumsal BT ortamıyla nasıl entegre olduğu, hangi veri kaynaklarına erişebildiği ve hangi kimlik doğrulama mekanizmalarını kullandığı önceden tanımlanmalı. Türkiye’deki orta ölçekli şirketlerde sık karşılaşılan sorun şu: platform satın alınıyor, birkaç pilot uygulama yapılıyor, ardından iş birimleri kendi başına büyümeye başlıyor. Altı ay sonra BT, hangi uygulamanın nerede çalıştığını, hangi verilere dokunduğunu bilmiyor. Bu noktada geri adım atmak; çalışan uygulamaları devre dışı bırakmak veya yeniden yapılandırmak, baştan doğru yönetişim kurmaktan çok daha maliyetli. Platformun sunduğu merkezi yönetim paneli, uygulama envanteri ve erişim logları bu nedenle seçenek değil, zorunluluk.
Bir de kurumsal kültür boyutu var. İş birimleri, BT’yi hız kesen bir engel olarak gördüğünde no-code araçları tam da bu engeli aşmak için kullanıyor. BT ise iş birimlerini kontrolsüz risk kaynağı olarak gördüğünde her talebi merkezi denetim altına almaya çalışıyor. Bu iki bakış açısı çatıştığında, no-code platformun getirdiği potansiyel değer kurumsal gerilimin altında kayboluyor. Çözüm, ortak bir dil kurmak: iş birimi hangi sorunu çözmek istediğini, BT bu çözümün hangi koşullarda desteklenebileceğini birlikte tanımlamalı. Bazı Türk holdingleri bu süreci ‘dijital ürün ekibi’ modeliyle yürütüyor; BT ve iş birimi temsilcilerinin bir arada çalıştığı küçük ekipler, no-code geliştirmeyi hem hızlı hem de denetimli tutuyor. Bu yapı mükemmel değil; kaynak gerektirir ve koordinasyon maliyeti taşır. Ama alternatif olan kontrolsüz büyüme, sonunda kurumun tamamına yük olan bir uygulama ormanı yaratıyor.
No-code araçlar iş birimlerine gerçek bir özgürlük alanı açıyor; ancak bu özgürlüğün sınırları kurumun kendisi tarafından çizilmeli. Kritiklik sınıflandırması, kademeli yetki modeli ve merkezi uygulama envanteri; bu üç unsur bir arada olmadan no-code benimsemesi kurumsal değer üretmek yerine yeni bir gölge BT dalgasına dönüşür. Türkiye’nin 2019 gerçeğinde, bütçe kısıtı altında hız arayan iş birimleri ile kaynak yetersizliğiyle boğuşan BT departmanları arasındaki gerilim, doğru yönetişim çerçevesiyle yönetilebilir bir işbirliğine dönüşebilir. Başlangıç noktası basit: hangi uygulamanın kim tarafından, hangi koşullarla geliştirilebileceğini herkesin anlayacağı bir dille yazıya dökmek.