Yapay Zeka Danışmanları Şirket İçi SaaS Değişiminin Kapsamını Nasıl Belirler?

Günlük ücretini hak eden her danışman, şirket içi bir SaaS değişiminin kapsamını aynı şekilde belirler: Her aracı görebildiğiniz kısımlara ve her seferinde doğru olması gereken kısımlara ayırmak. SaaS (aylık olarak kiraladığınız yazılımlar) çoğunlukla daha küçük bir kayıt tutma çekirdeği üzerinde duran ekranlar, iş akışları ve raporlardan oluşur. Yapay zeka, ilk yarının yeniden oluşturulmasını ucuzlattı. İkinci yarı ise değişim projelerinin sonlandığı yerdir ve iyi bir kapsam belirleme süreci, abonelik faturanızın ne kadarının aslında orada yaşadığını ölçmek için vardır.

Şirket içi SaaS değişim kapsamının adım adım nasıl bir araya geldiği ve çoğunu belirleyen tek soru aşağıdadır. (Aşağıdaki tedarikçi adları ve anket rakamları yayınlandığı tarih itibarıyla doğrudur; ayrıntıları bir anlık görüntü olarak değerlendirin.)

Bir SaaS değişim kapsamı aslında neleri içerir?

Özellik listesi değil, bir görev envanteri. Danışman, aracın gerçekleştirdiği her görevi, her birine kimin dokunduğunu ve çıktısı yanlış olduğunda ne olacağını listeler. Onay zincirleri, gösterge panelleri (dashboard'lar) ve formlar bir sütuna gider. Para hareketleri, stok sayıları, vergi ve çalışan kayıtları ise başka bir sütuna. Teslim edilecek öğe bu harita, görev başına bir risk derecesi ve aracın sessizce bağlı olduğu her sistemin bir listesidir.

Derecelendirme sorusu işin tüm püf noktasıdır: Bu çıktı yanlış olsaydı, bunu nasıl fark ederdiniz ve maliyeti ne olurdu? Güncel olmayan bir gösterge paneli ilk bakışta fark edilir ve hiçbir maliyeti olmaz. Yanlış bir ödeme toplamı ise vergi zamanında fark edilir ve gerçek paraya mal olur.

Ürün neden iki katmana ayrılmalı?

Çünkü yapay zeka bir katmanın maliyetini sıfırlarken diğerine dokunmadı. Arayüz katmanını (formlar, gösterge panelleri, dahili araçlar, onay iş akışları) yeniden oluşturmak artık çok hızlı; mevcut modeller saatler içinde çalışan web uygulamaları üretiyor ki GPT-5.6'nın çalışan bir POS oluşturup oluşturamayacağını sorduğumuzda tam olarak bunu tespit ettik. Altyapı katmanı ise farklıdır: Ödeme işleme, PCI uyumluluğu (ödeme işlemcilerinin uyguladığı kart güvenliği kuralları), eşzamanlılık altında envanter (aynı son ürünü satan iki kasa) ve mutabakat sağlayan raporlar (banka mevduatınızla eşleşen toplamlar). Bu katman kod uzun olduğu için zor değildir. Zordur çünkü orada 'neredeyse doğru' hiçbir değer taşımaz ve doğruluğu kanıtlamak, kodu üretmekten daha maliyetlidir.

Daha iyi modeller de bu kısıtlamayı ortadan kaldırmaz. Darboğaz kod üretimi değil, doğrulama ve sorumluluktur; bu nedenle dürüst bir kapsam doğrulamayı fiyatlandırır. Üretim demodur. Doğrulama ise fatura.

Klarna'nın SaaS değişimi aslında neyi kanıtladı?

"SaaS'ımızı yapay zeka ile değiştirdik" hikayelerinin en ses getireni aslında bir kapsam belirleme dersidir. 2024'ün sonlarında Klarna CEO'su, şirketin yapay zeka dönüşümünün bir parçası olarak Salesforce ve Workday'i bıraktığını duyurdu ve manşetler yapay zekanın SaaS'ın yerini tamamen aldığını bildirdi. Sonraki haberler daha dar kapsamlı bir durum ortaya koydu: Klarna İK'yı başka bir tedarikçiye taşıdı ve CRM ihtiyaçlarını alternatif araçlar ile şirket içi entegrasyonların birleşimiyle, üzerine yapay zeka ekleyerek karşıladı¹. Fintek alanındaki en agresif yapay zeka programlarından birini yürüten lisanslı bir banka bile kayıt sistemlerini (iş verilerinizin yetkili kopyası) kanıtlanmış platformlarda tuttu ve yalnızca çevre sistemleri yeniden inşa etti.

Bu bir cesaret eksikliği değildi. Bu, kapsam belirleme sürecinin tıkır tıkır işlemesiydi.

Hangi rakamlar bir değişim projesini haklı çıkarır?

Önce israfı önleyin, sonra inşa edin. Yönetim altındaki 40 milyondan fazla lisansa dayanan Zylo'nun 2026 SaaS Yönetim Endeksi, çalışan başına yıllık ortanca SaaS harcamasını 9.455 $ olarak belirliyor, lisansların ortalama %36'sının kullanılmadığını ortaya koyuyor ve BT doğrudan %15'ini yönetirken iş birimlerinin SaaS harcamalarının %81'ini kontrol ettiğini gösteriyor². Bir danışman, herhangi bir öneride bulunmadan önce teknoloji yığınınızı bu rakamlara göre derecelendirir: Kullanılmayan lisansları iptal edin, çakışan araçları birleştirin ve ancak bundan sonra yeniden inşa edilecek adayları kısa listeye alın.

Kısa listeye giren araçlar benzer bir profile sahiptir: Yüksek tekrarlayan maliyet, çoğunlukla arayüz katmanında yer alan görevler ve bir şey bozulduğunda küçük bir etki alanı. Abonelik gideri, inşa etme ve sürdürme maliyetinden daha hızlı büyüdüğünde ve her doğru olması gereken görev başka birinin zaten işlettiği bir altyapıda kalabildiğinde proje onaylanır.

POS bu kapsam belirlemenin neresinde yer alıyor?

Yelpazenin hiç bağışlamayan tarafında. Bir POS, butonlardan oluşan bir ızgara ve bir sepet ile arayüz projesi gibi görünür, bu nedenle işletme sahipleri bunun bir gösterge paneli gibi kapsamlandırılacağını varsayar. Oran tam tersinedir. Ödeme ekranı ürünün küçük bir dilimidir; geri kalanı ödemeler, sertifikalı fiziki kart donanımı, aynı anda satış yapan iki kasaya dayanan envanter, vergi kuralları ve mutabakat sağlayan gün sonu raporlarıdır. Bir POS yanlış olduğunda, her gün para konusunda yanlış demektir.

Bu nedenle danışmanlar, bir POS'u yeniden inşa etme kapsamını Klarna'nın defteri kapsamlandırdığı gibi belirler: Özel arayüz, kanıtlanmış altyapı. Bu ayrım önceden bir geliştirici ekibi gerektiriyordu. Artık bir ürün kategorisi haline geldi: Final'ın Build özelliği, sade dille yazılmış bir komutu önizleyebileceğiniz ve dağıtabileceğiniz bir ödeme akışına dönüştürür ve aynı ticaret altyapısına karşı derlemek için kendi yapay zekanızı MCP üzerinden bağlayabilirsiniz. Ödemeler, envanter, raporlama ve donanım zaten doğrulanmış olan katmanda kalır.

Peki şirket içi SaaS değişiminin kapsamı nasıl belirlenmeli?

Her aracı iki katmanına ayırın, her bir görevi fark edilmeyen hatalı bir çıktının maliyetine göre derecelendirin ve koda değil doğrulamaya fiyat biçin. Arayüzleri ve iş akışlarını özgürce yeniden inşa edin; kayıt sistemlerini başkasının doğru tuttuğu altyapıda bırakın. Herhangi bir aracı şirket içinde yeniden inşa etmeden önce sorun: Çıktısı yanlış olsaydı, bunu ne kadar hızlı anlardım? Yanıt "hızlı değil" ise, o görev kanıtlanmış sistemlerde kalmalıdır.

Ve teknoloji yığınınızın yeniden inşa etmek istediğiniz kısmı ticaret tarafıysa, bugünün modellerinin kendi başlarına neleri inşa edebileceğine ve neleri inşa edemeyeceğine dürüstçe bakarak başlayın: Gerçek bir POS yapımında Claude, ChatGPT ve Gemini karşılaştırması veya özel bir POS oluşturmak için Gemini 3.6 Flash'ın nasıl kullanılacağına dair iki kodsuz yöntem.