Şirketler, satın alma yazılımları veya dijital dönüşüm hizmetleri alırken, ihale dokümanlarında hâlâ “İhaleye katılan firmanın XX adet üst düzey mühendis bulundurması; yerinde çalışma süresinin en az XX kişi‑ay olması” gibi şartlar sıkça yer alır. Değerlendirme formları ise kişi sayısı, yeterlilik ve birim fiyatı ağırlıklı olarak puanlandırılır—bu yöntem on yıl önce makul olsa da, akıllı araçlar ve yapay zekâ destekli teslimatın yaygınlaştığı günümüzde, yalnızca “en fazla personel”i seçen değil, aynı zamanda “en net sonuç”u sunan tedarikçiyi seçmeyi zorlaştırıyor.
Politika bağlamı: Satın alma mantığı değişiyor
Sanayi ve Bilgi Teknolojileri Bakanlığı’nın Eylül 2026’da yayımladığı “Yapay Zekâ + Yazılım” Özel Eylem Planı, yazılımların akıllı dönüşüme yönelik geliştirilmesini, akıllı araçların hizmet olarak sunulmasını teşvik etmeyi öngörüyor ve ayrıca harcanan kaynağın miktarına değil, elde edilen somut sonuçlara bakılmasını vurguluyor . Satın alanlar açısından işaret çok açık: Hâlâ yalnızca insan günü ve yerinde çalışma sayısı üzerinden değerlendirme yapılırsa, görünen “gürültülü bir uygulama”yı satın alabilir, ancak doğrulanabilen iş süreçlerindeki iyileştirmeleri elde edemez.
İnsan günü değerlendirmesi vs. sonuç odaklı değerlendirme: Aradaki fark nedir
| boyutları | geleneksel insan günü/kişi bazlı değerlendirme | sonuç odaklı değerlendirme |
|---|---|---|
| temel göstergeler | personel sayısı, pozisyon seviyesi, yerinde çalışma gün sayısı, birim fiyat | senaryo kapanış döngüsü, kabul scripti, hizmete alındıktan sonraki KPI’lar |
| talep ifadesi | işlev listesi seçimleri | görev operasyonları + veri ölçütleri + istisna kuralları |
| değişiklik işlemleri | sahada ek personel ve ek ücret görüşmeleri | değişiklik formunun hangi里程碑 ve KPI’ları etkilediği |
| yapay zekâ/akıllı araçlar | genellikle puanlama kapsamına dahil edilmez | verimlilik artışı, insan incelemesi noktaları ve yetki sınırları belirtilmelidir |
| ödeme noktaları | üç aylık veya kişi‑ay bazında ödeme | milestone bazında kabul sonrası ödeme |
| anlaşmazlık odak noktası | “personel yerine getirildi mi” | “script çalışıp çalışmadı, göstergeler iyileşti mi” |
İş mantığı: İhale dokümanları nasıl değiştirilmeli
Satın alma belgelerini “insan gücü satın almak”tan “sonuç satın almak”a dönüştürmek için dört ana bölümden yeniden yazılması önerilir:
- senaryo listesi : Pozisyonlar bazında “mevcut sorunlar → hedef işlemler” şeklinde yazılmalı; örneğin “satın almacı e‑posta ile sipariş vermekten sistem içinde PO onayıyla kapalı döngüye geçmeli”.
- kabul scripti : Her senaryoya ilişkin test adımları, giriş verileri ve beklenen çıktılar eklenmeli; ihaleye katılan firmalar her bir madde için uygulanabilirliği cevaplamalıdır.
- KPI taahhütleri : Hizmete alındıktan sonra 90 gün içinde ölçülebilir göstergeler; örneğin onay sürecinin kısaltılma oranı, hesap eşleşmesi tutarsızlığı oranı, stok doğruluğu — bu göstergeler sistematik olarak alınabilmeli.
- hizmet sınırları : Eğitim, bakım‑destek, veri taşıma, akıllı araç kurallarının bakımını kimin üstleneceği belirlenmeli; böylece “hizmete alındıktan sonra iş bitti” denilmesi önlenmeli.
Puanlama ağırlıkları önerisi: 方案与验收匹配度 40% + 同类案例实效 30% + 价格 20% + 团队能力 10%. Ekibin hâlâ değerlendirilmesi gerekiyor, ancak başlıca etkili olmamalı; aksi takdirde yine de yalnızca personel sayısına odaklanma riski var.
Tasarım mantığı: Akıllı araçlar ve otomasyon nasıl değerlendirme sürecine dahil edilmeli
Eğer çözümde akıllı müşteri hizmetleri, otomatik hatırlatma, kurallar motoru bulunuyorsa, satın alan taraf ihaleye katılan firmalardan şu soruları cevaplamalarını talep etmelidir:
- Giriş‑Çıkış : Hangi belgeler okunacak, hangi durumlar geri yazılacak, denetim mümkün mü?
- Yetki ve yükseltme : Hangi işlemler manuel onay gerektiriyor, süre aşımı durumunda nasıl yükseltilir?
- Doğruluk oranı ve denetim örneklemi : Temel çizgideki taahhüt nasıl ölçülür, yanlış işlem nasıl geri çekilebilir?
- Tedarikçi bağımlılığı : Model, kurallar, bilgi bankası dışarıya aktarılabilir mi; fabrikadan başka bir yere geçilince sistem çökmeyecek mi?
Uygulama ve kabul: Üç aşama güvenlik kontrolü
Sözleşme içinde üç aşamalı güvenlik kontrolünün açıkça belirtilmesi ve ödeme ile kabulün birbirine bağlı olması önerilir:
- Birinci aşama (4–8 hafta) : Temel senaryo scriptleri %100 geçer, kritik rollerin eğitimi tamamlanır. Geçemeyenler ikinci aşama ödemesini almaz.
- İkinci aşama (8–12 hafta) : Departmanlar arası süreçler birleştirilir, arayüzler ve ana veriler istikrar kazanır, KPI temel verileri toplanarak hizmete alınır.
- Üçüncü aşama (90 günlük işletme) : Sözleşmedeki KPI’lar doğrultusunda geriye dönük değerlendirme yapılır; hedefe ulaşmayanlar için düzeltme dönemi ve kesinti hükümleri vardır, sonsuz yerinde kalma yoktur.
Yerinde çalışma sayısı, uygulama aracı olarak kullanılabilir ekte belirtilir, ancak asıl sözleşme konusu olmamalıdır. Asıl sözleşme konusu “hangi scriptler geçti, hangi göstergeler iyileşti” olmalıdır.
Satın alanların yaygın yanılgıları
Yanılgı 1: Düşük fiyatlı insan günü ile ihaleyi kazanmak —sonradan değişikliklerle bedel artar, toplam maliyet daha yüksek olur. Çözüm: Toplam bedelin tavanı + değişiklikler için ayrı bir fiyat tablosu.
Yanılgı 2: Ne kadar çok işlev varsa o kadar iyi —hizmete alındığında düşük oran. Çözüm: Aşamalı senaryolar; ilk aşamada az sayıda ama kapalı döngü.
Yanılgı 3: Ana verileri göz ardı etmek —sistem hizmete alındıktan sonra veriler kirli ve karışık, akıllı araçlar hataları büyütür. Çözüm: Ana veri yönetimi için ayrılmış milestone’lar tek tek kabul edilmeli.
Yanılgı 4: KPI’ların veri alma ölçütünü tanımlamamak —çekişme sırasında herkes kendi hesabını yapar. Çözüm: Göstergelerin formülü, veri kaynakları, istatistiksel dönemler ekte belirtilmeli ve bilgi teknolojileri departmanı tarafından sistemin otomatik veri alma kapasitesi doğrulanmalıdır.
Sonraki adım
ERP, OA, SRM veya özel dijital dönüşüm projeleri için yeniden işe alım yapıyorsanız, öncelikle bir hafta boyunca “ihale sağlık kontrolü” yapabilirsiniz: Mevcut RFP’lerdeki tüm insan günü maddelerini kırmızıya boyayın, her birini senaryo + script + KPI formatına dönüştürün. Tamamen bitiremezseniz de sorun değil; en azından bir sonraki ihale versiyonu hâlâ 2015 mantığıyla insan seçmeye devam etmez.
Yazılım sektöründeki “teknik dönüşüm” sadece tedarikçi tesislerinde değil, aynı zamanda alıcı tarafın satın alma departmanında da gerçekleşir. Kim önce sonuç odaklı değerlendirme yaparsa, akıllı araçlar çağında gerçekten kullanılabilecek, hesap sorulabilecek ve geriye dönük analiz yapılabilen yönetim sistemlerini satın alma ihtimali daha yüksektir; bunun yerine kalın bir personel listesinden faydalanmak değildir.
Devlet şirketleri ve grup satın alımlarında ekstra dikkat gerektiren noktalar
Büyük ölçekli satın alımlarda genellikle hem uyumluluk hem de etkinlik dengesi sağlanmalıdır: İhale dokümanlarında yeterlilik eşiği ve yolsuzluk karşıtı maddeler korunabilir, ancak teknik değerlendirme tablosunda “kabul scripti cevaplarının tamamlanma derecesi” ve “KPI’ların ölçülebilirliği” zorunlu alt başlıklar olarak belirlenmeli; böylece teknik puanlama biçimden öteye geçmemelidir.Grup düzeyinde birden fazla tüzel kişilik senaryosunda, isteğe göre ihale sunumunu yapan tarafın ana verilerin ve yetkilerin nasıl iştirak şirketleri desteklediğini açıklaması; ayrıca birinci aşamada deneme amacıyla belirli bir tüzel kişiliğin uygulama sürecini başarıyla tamamlamasının ardından yaygınlaştırma yapılması önerilmektedir; bunun yerine tüm grup için aynı anda tek bir süreçe geçilmesi doğru değildir.
Satın alma komitesinin sunum bölümünde, sahada rastgele seçilen 2–3 adet işlem senaryosunun ihale sunumunu yapan taraf tarafından uygulanması ve jürinin beklenen çıktıya göre puanlama yapması tavsiye edilir—bu, PPT sunumuna bakmaktan çok daha fazla, sistemin canlı ortamda kullanılmasından sonraki gerçek deneyime yakındır. Sözleşme müzakere aşamasında ise, “KPI’ları karşılayamayan durumlarda uygulanacak düzeltme dönemi ile cezai oranlar” maddelerinin asıl metne dahil edilmesi, sonrasında ilişkiler aracılığıyla yapılan müzakerelere kıyasla her iki tarafın da haklarını daha etkin biçimde koruyacaktır. İhale değerlendirmesi reformu, bir sonraki ulusal standartın yayımlanmasını beklemeye gerek yoktur; bir sonraki satın alma işleminden itibaren hemen bir işlem senaryosu, bir KPI ve bir giriş kontrolü pilot olarak uygulanabilir. Küçük adımlarla deneyip hata yapmak, kusursuz bir şablonu beklemekten çok daha etkili bir şekilde politika ve teknolojideki ikili değişimlere ayak uydurmayı sağlar.