Build modeli, kurumun gerçekten farklılaştığı ve sürekli ürün sahipliği kurabildiği alanlarda anlamlıdır. Buy modeli standartlaşmış ihtiyaçlarda hız ve kanıtlanmış yetenek sağlar. Partner modeli ise uzmanlık, kapasite veya pazara erişim açığını kapatabilir. Sağlıklı karar; stratejik değer, gereksinim belirsizliği, entegrasyon, veri kontrolü, güvenlik, insan kaynağı, TCO, değişiklik hızı ve çıkış planını aynı matriste değerlendirir. En iyi sonuç çoğu zaman çekirdeği satın alıp farklılaştırıcı katmanı geliştiren kontrollü hibrit modeldir.
Karar, ürün özelliği listesinden önce iş kabiliyetini tanımlamakla başlar
Kurumlar çoğu zaman çözümü, problemi netleştirmeden seçer. Hazır bir ürünün güçlü demosu veya geliştirme ekibinin “yaparız” güveni; gerçek süreç, veri, kontrol ve değişim ihtiyacını gölgeleyebilir. Önce hangi iş sonucunun değişmesi gerektiği, hangi kabiliyetin standart olduğu, hangi katmanın kuruma özgü değer ürettiği ve başarının nasıl ölçüleceği tanımlanmalıdır.
| Soru | Kararı nasıl etkiler? | Kanıt |
|---|---|---|
| Kabiliyet stratejik olarak farklılaştırıcı mı? | Build veya özel ortaklık lehine ağırlık yaratır. | Müşteri değeri, gelir, hız veya risk avantajı |
| İhtiyaç piyasada standartlaşmış mı? | Buy ve yapılandırma lehine ağırlık yaratır. | Referans süreç, ürün olgunluğu, entegrasyon ekosistemi |
| Gereksinimler hızla değişiyor mu? | Modüler ve kontrol edilebilir mimari gerekir. | Değişiklik sıklığı, mevzuat, ürün yol haritası |
| Kurum kalıcı ürün sahipliği kurabilir mi? | Build kararının sürdürülebilirliğini belirler. | Ürün, mimari, güvenlik ve operasyon kapasitesi |
Build, buy, partner ve hibrit modeller farklı sorumluluk dağılımlarıdır
Build, çekirdek ürün kararları ve yaşam döngüsünün kurumda olduğu geliştirme modelidir. Buy, hazır bir ürünün yapılandırılması ve işletilmesidir. Partner, uzmanlık, teslimat veya ortak ürün geliştirme sorumluluğunun dış bir tarafla paylaşılmasıdır. Hibrit ise standart altyapıyı satın alıp farklılaştırıcı süreç, veri veya deneyim katmanını kurumun kontrolünde geliştirmeyi amaçlar.
| Model | Güçlü olduğu durum | Başlıca risk |
|---|---|---|
| Build | Farklılaştırıcı kabiliyet, özel veri ve hızlı ürün iterasyonu | Süre, yetenek, bakım ve anahtar kişiye bağımlılık |
| Buy | Standart süreç, hızlı devreye alma ve olgun kontrol seti | Uyumsuz süreç, lisans artışı ve vendor lock-in |
| Partner | Eksik uzmanlık, kapasite açığı veya ortak pazara erişim | Sorumluluk belirsizliği ve bilgi birikiminin dışarıda kalması |
| Hibrit | Standart çekirdek + kuruma özgü değer katmanı | Entegrasyon ve sınır yönetimi karmaşıklığı |
“Satın almak” geliştirme ihtiyacını ortadan kaldırmaz; veri migrasyonu, entegrasyon, kimlik, raporlama, yapılandırma, test ve değişim yönetimi yine kurumun sorumluluğundadır. “Build” de her bileşeni sıfırdan yazmak anlamına gelmez; açık kaynak, bulut servisleri ve yeniden kullanılabilir bileşenler kontrollü biçimde kullanılabilir.
Stratejik farklılaşma testi gereksiz özel geliştirmeyi sınırlar
Özel geliştirme, yalnız “ihtiyacımız farklı” beyanıyla savunulmamalıdır. Farklılığın müşteri, gelir, operasyon, risk veya öğrenme avantajı üretmesi gerekir. Maaş bordrosu, genel muhasebe veya standart onay akışı gibi alanlarda süreç farklılığı çoğu zaman değer değil tarihsel alışkanlıktır. Buna karşılık özel fiyatlama, risk motoru, içerik üretim zinciri veya özgün müşteri deneyimi stratejik olabilir.
Farklılık değer üretiyor mu?
Müşterinin seçimini, geliri, maliyeti veya riski ölçülebilir biçimde etkiliyor mu?
Özgün veri avantajı var mı?
Kurumun verisi ve öğrenme döngüsü çözümün kalıcı üstünlüğünü besliyor mu?
Değişim kurum kontrolünde mi olmalı?
Ürün yol haritası ve mevzuat değişimi tedarikçi temposundan hızlı mı?
Sahiplik sürdürülebilir mi?
Ürün, mimari, güvenlik, test ve operasyon ekipleri kalıcı mı?
Dört sorunun çoğuna güçlü kanıt verilemiyorsa, özel geliştirme yerine hazır ürünün süreç standardizasyonu ve kontrollü entegrasyonla kullanılması daha sağlıklı olabilir.
Karar, ilk satın alma veya geliştirme bütçesiyle değil toplam sahip olma maliyetiyle verilmelidir
TCO hesabı; lisans veya geliştirme ücretinin yanında analiz, veri temizliği, entegrasyon, güvenlik, test, eğitim, değişim yönetimi, altyapı, destek, yükseltme, performans, denetim, iş sürekliliği ve çıkış maliyetlerini içermelidir. Build modelinde bakım ve teknik borç; buy modelinde kullanıcı, işlem, depolama ve eklenti lisansları görünür hâle getirilmelidir.
| Maliyet alanı | Build | Buy/Partner |
|---|---|---|
| Başlangıç | Ürün, tasarım, geliştirme, platform | Lisans, kurulum, danışmanlık, yapılandırma |
| Geçiş | Eski sistem entegrasyonu ve veri taşıma | Veri migrasyonu, süreç uyarlama, entegrasyon |
| İşletim | Ekip, altyapı, izleme, güvenlik, destek | Lisans, kapasite, destek, yönetilen hizmet |
| Değişim | Backlog, test, teknik borç | Değişiklik talebi, eklenti, yol haritası bağımlılığı |
| Çıkış | Dokümantasyon ve ekip devamlılığı | Veri ihracı, geçiş desteği, sözleşme ve bağımlılık |
Karar en az üç senaryoyla incelenmelidir: taban plan, büyüme planı ve stres senaryosu. Kullanıcı sayısı, işlem hacmi veya entegrasyon sayısı arttığında maliyet eğrisinin nasıl değiştiği özellikle gösterilmelidir.
Güvenlik ve tedarikçi incelemesi seçimden önce başlamalıdır
Ürünün veri işleme konumu, alt tedarikçileri, güvenlik geliştirme süreci, kimlik modeli, olay bildirimi, yama politikası, iş sürekliliği, denetim kanıtları ve çıkış kabiliyeti incelenmelidir. Sertifika veya pazar payı tek başına ürünün kurumun kullanım bağlamında güvenli olduğunu kanıtlamaz.
- Veri sahipliği, kullanım hakkı, saklama ve silme koşulları
- Kimlik, MFA, rol ve ayrıcalıklı erişim modeli
- Güvenlik açığı, yama ve olay bildirim süreleri
- Alt tedarikçi ve kritik hizmet bağımlılıkları
- Veri ihracı, açık format ve çıkış desteği
- Kaynak kodu, escrow veya iş sürekliliği seçenekleri
- Fiyat değişikliği ve lisans denetimi hükümleri
- Ürün yaşam döngüsü ve destek sonu politikası
NIST ve CISA’nın tedarikçi inceleme yaklaşımları, alıcının karar öncesinde makul araştırma yapmasını ve güvenlik gereksinimlerini sözleşme ile yaşam döngüsüne bağlamasını önerir.
Mimari karar ürün sınırlarını ve geri dönüş maliyetini belirler
Hazır ürün seçilirken yalnız fonksiyonlar değil API, olay modeli, veri ihracı, kimlik entegrasyonu, uzantı mekanizması, sürüm uyumluluğu ve gözlemlenebilirlik değerlendirilmelidir. Özel geliştirmede ise açık standartlar, modüler sınırlar, yeniden kullanım ve otomatik test zorunlu olmalıdır.
Karar süreci ihtiyaçtan kontrollü pilota ilerlemelidir
- İş problemini, hedef KPI’yı ve mevcut sürecin baz çizgisini yazın.
- Kabiliyeti standart, farklılaştırıcı ve zorunlu kontrol katmanlarına ayırın.
- Build, buy, partner ve hibrit seçenekleri için aynı değerlendirme ölçütlerini kullanın.
- Beş yıllık TCO, süre, insan kaynağı ve çıkış senaryosu oluşturun.
- Güvenlik, veri, mimari ve tedarikçi durum tespitini yapın.
- Gerçek veri ve entegrasyonla sınırlı pilot uygulayın.
- Başarı, başarısızlık ve durdurma eşiklerini önceden belirleyin.
- Sözleşme ve teslimat kabul kriterlerini kanıta bağlayın.
- Canlı sonrası ürün sahipliği ve değer izleme modelini kurun.
Senaryo: Müşteri teklif ve fiyatlama platformu
Kurumun standart CRM, müşteri ve aktivite yönetimi ihtiyacı hazır ürünle karşılanabilir. Ancak sektör verisi, fiyatlama kuralları, risk sinyalleri ve onay zinciri kurumun farklılaştırıcı kabiliyeti olabilir. Bu durumda CRM’i satın alıp fiyatlama motoru ve karar servislerini açık API üzerinden kurum kontrolünde geliştirmek dengeli bir hibrit modeldir. Kabul kriterleri yalnız ekranların çalışması değil; fiyat doğruluğu, teklif süresi, yetki kontrolü, audit izi ve geri alma kabiliyeti olmalıdır.
Başarı teslim tarihinden sonra değer ve değişim kabiliyetiyle ölçülür
İş sahibi sonuç ve öncelikleri; ürün sahibi backlog ve kabul kriterlerini; mimari ekip sınırları ve entegrasyonları; güvenlik ve veri ekipleri kontrol şartlarını; satın alma ve hukuk sözleşme ile çıkış haklarını; finans TCO ve değer gerçekleşmesini yönetir.
| KPI | Ne ölçer? | Yanlış yorum |
|---|---|---|
| Değer gerçekleşmesi | Hedef iş sonucuna katkı | Projenin zamanında bitmesi |
| Değişiklik süresi | Yeni ihtiyacın güvenli yayına alınması | Backlog büyüklüğü |
| Toplam maliyet | Kullanım ve sonuç başına TCO | İlk teklif fiyatı |
| Bağımlılık riski | Alternatif, ihracat ve çıkış kabiliyeti | Tedarikçi sayısı |
| Operasyon güveni | Süreklilik, hata, güvenlik ve geri alma | Yalnız uptime |
Kaynaklar ve gözden geçirme notu
Bu rehberde değişebilir veya teknik iddialar için öncelikle resmî kurum, ürün geliştiricisi ve birincil araştırma kaynakları kullanılmıştır. Bağlantılar 27 Temmuz 2026 tarihinde gözden geçirilmiştir.
- 01UK Government — Technology Code of Practice
Teknolojiyi tasarlama, geliştirme ve satın alma kararlarında kullanıcı, açık standart, bulut, güvenlik ve sürdürülebilirlik ölçütlerini tanımlar.
- 02GDS — To Build or to Buy
Build, buy, configure ve customise seçeneklerini değerlendiren resmî satın alma stratejisi yaklaşımını açıklar.
- 03GOV.UK Service Manual — Choosing Technology
Teknoloji kararlarının hizmet kalitesi, işletim ve iterasyon kabiliyetine etkisini ele alır.
- 04CISA — Secure by Demand Guide
Yazılım müşterilerinin satın alma sürecinde güvenlik beklentilerini ve tedarikçi sorularını belirlemesine yardımcı olur.
- 05NIST SP 1326 — Supplier Due Diligence
Potansiyel tedarikçi ve ürünler için makul araştırma ve siber tedarik zinciri durum tespiti yaklaşımını tanımlar.