SaaS mı özel yazılım mı sorusu, işletmenin yalnızca bir program seçmesiyle ilgili değildir. Hangi işleyişe uyum sağlayacağını, verilerini nasıl yöneteceğini ve gelecekteki değişiklikleri nasıl ele alacağını da etkiler. Hazır hizmet belirli ihtiyaçları karşılayabilir; özel geliştirme ise işletmeye özgü davranışların kurulmasını mümkün kılabilir. Ancak bu iki yaklaşımın hiçbiri her koşulda üstün değildir. Önce hangi problemin çözüleceği, hangi sınırların kabul edilebileceği ve işletmenin hangi sorumlulukları üstleneceği anlaşılmalıdır.

İçindekiler

SaaS, yazılımın hizmet olarak kullanıldığı modeli anlatır. Özel yazılım ise belirli ihtiyaçlar için geliştirme kapsamını ifade eder. Bunlar bütünüyle karşıt teknik kavramlar değildir. Özel geliştirilen uygulama bulutta çalışabilir; bir hizmette de belirli özelleştirmeler bulunabilir. Bu nedenle isimlerden çok sunulan işlev, veri ve sorumluluk düzenine bakmak gerekir. Bu rehber dokuz ölçütle karşılaştırmayı açıklar. Belirli fiyat, ürün üstünlüğü veya yatırım getirisi sunmaz. Gerçek karar, işletmenin ihtiyaçları ve incelenen tekliflerin koşullarıyla verilir.

SaaS mı özel yazılım mı diye araştırırken önce günlük işinizden bir örnek seçin. Bugün hangi bilgi tekrar giriliyor, hangi onay bekliyor veya hangi rapor karar vermeyi zorlaştırıyor? Özel yazılım geliştirme görüşmesinde bu soruları somut dosyalarla anlatabilirsiniz. Hazır hizmetleri de aynı ihtiyaç listesiyle değerlendirin. Sadece ürün tanıtımındaki modül adlarına bakmak yeterli olmayabilir. Aynı isimli işlev farklı sağlayıcılarda başka davranışlar içerebilir. İlk sürüm beklentisi ve kabul edilebilir sınırlar açık yazılmalıdır.

SaaS mı özel yazılım mı sorusunda önce kavramları ayırın

SaaS mı özel yazılım mı sorusundan bağımsız olarak bir uygulamanın size özel geliştirilmesi, bütün çalışma ortamının işletmede bulunacağı anlamına gelmez. Bulut hizmetleri kullanılabilir. Hazır uygulamanın kullanılması da işletmenin bütün teknik ve veri sorumluluklarını ortadan kaldırmaz. Hesaplar, erişimler ve girilen bilgilerin yönetimi yine önemlidir. Hangi hizmetin kim tarafından yönetildiği anlaşılmalıdır. Teklifte kullanılan hazır, bulut veya özel sözcükleri ayrıntılı kapsamın yerine geçmez. Satın alınan veya geliştirilen şeyin somut çıktısı açıklanmalıdır. Bu ayrım yanlış beklentileri erken azaltabilir.

SaaS mı özel yazılım mı karşılaştırmasında hizmet modeliyle işlev uyumunu ayrı değerlendirin. Bir hazır ürün ihtiyacınızı doğrudan karşılayabilir; başka biri sürekli dış dosya kullanmanızı gerektirebilir. Özel geliştirme de doğru ihtiyaç tanımı olmadan iyi sonuç vermez. Her şey yapılabilir ifadesi, neyin hangi kapsamla yapılacağını açıklamaz. İşletmenin kararları, veri hazırlığı ve kullanıcı katılımı gerekir. Uygun seçenek yalnızca ürün adından veya geliştirme sözü verilmesinden çıkarılamaz. Gösterim ve örnek senaryolar üzerinden kontrol yapılmalıdır.

Karşılaştırmada kullanılacak 9 ölçüt

1. Temel iş akışına uyum

Önce işletme için vazgeçilmez işlemleri seçin. Siparişin nasıl açıldığı, onayın kim tarafından verildiği ve hangi sonucun beklendiği yazılır. Hazır üründe bu işlemlerin gerçekten nasıl yapıldığı görülebilir. Sadece özellik var işaretine dayanmayın. Aynı sonuç için çok sayıda geçici dosya gerekiyorsa kullanım yükü artabilir. Buna karşılık mevcut çalışma biçiminizde gereksiz adımlar bulunabilir. Her alışkanlığın aynen korunması zorunlu değildir. İş kuralıyla geçmişten gelen tercih birbirinden ayrılmalıdır.

SaaS mı özel yazılım mı kararında uyumsuzluğun önemini değerlendirin. Küçük bir ekran tercihiyle zorunlu onay adımı aynı ağırlıkta değildir. İşletme hangi sınırları kabul edebileceğini açıklamalıdır. Bir hazır ürün süreç değişikliğiyle yeterli olabilir. Özel geliştirme de bazı ihtiyaçların sonraki sürüme bırakılmasını gerektirebilir. Karşılaştırma, her iki seçeneğin gerçek kapsamına dayanmalıdır. Eksik işlevin günlük işte nasıl karşılanacağı ve kimin sorumluluğunda olacağı görülürse toplam yük daha anlaşılır hale gelir.

Değerlendirmeyi gerçek veya güvenli temsili kayıtlarla yapın. Normal işlem ve istisna seçilmelidir. Kısmi teslim, eksik bilgi veya iptal gibi durumlar uygulanacak kapsama göre denenebilir. Gösterimi yapan kişinin ideal örneği tek başına yeterli olmayabilir. Kullanıcı kendi işini anlatmalı ve beklediği sonucu kontrol etmelidir. Deneme, bir ürünün bütün teknik güvenliğini kanıtlamaz; işlev uyumuna dair bilgi sağlar. Kritik teknik ve erişim kontrolleri ayrıca değerlendirilmelidir. Sonuçlar kısa notlarla kaydedilebilir.

2. Değişiklik ve özelleştirme ihtiyacı

Hazır hizmette ayar değişikliği, ek modül veya bağlantı olanağı bulunabilir. Bunların sınırları sağlayıcının güncel belgeleriyle kontrol edilmelidir. Her değişikliğin destekleneceği varsayılmamalıdır. Özel geliştirmede ise yeni davranışın süre, test ve bakım etkisi bulunabilir. Her isteğin mevcut bedelle yapılacağı düşünülmemelidir. İhtiyacın ne kadar sık değiştiği ve hangi bölümlerin işletmeye özgü olduğu anlaşılmalıdır. Henüz kullanıcılarla konuşulmamış kararlar, teknik özelleştirme gereği gibi sunulmamalıdır.

SaaS mı özel yazılım mı sorusunda gelecekteki bütün fikirleri ilk sürüme eklemek gerekmez. Önce zorunlu iş, yakın dönem ihtiyaç ve yalnızca olasılık olan fikir ayrılır. Hazır ürünün yol haritasında bulunan özelliğin ne zaman sunulacağı kesin olmayabilir. Özel projede de henüz incelenmemiş talep için kesin tarih verilmemelidir. Karar, bugün mevcut olan veya açık kapsamla taahhüt edilen işler üzerinden yapılır. Sonraki geliştirmelerin nasıl değerlendirileceği ayrıca konuşulabilir. Beklenti kaydı yanlış anlamaları azaltabilir.

Özelleştirme talebinde sonucu anlatın. Belirli düğme veya teknoloji istemek yerine kullanıcının hangi işi yapması gerektiğini açıklayın. Hazır ürünün mevcut yöntemi yeterli olabilir veya özel geliştirmede daha sade seçenek bulunabilir. Alternatiflerin kullanıcı yükü de değerlendirilir. Sadece yapılabilir sözüne dayanmak yerine nasıl kullanılacağı görülmelidir. Değişiklik sonrası güncellemelerin ve bakımın kim tarafından yönetileceği sorulabilir. Özellikle üçüncü taraf eklentilere bağlı yapı düşünülüyorsa sorumlulukların ayrımı anlaşılır olmalıdır.

3. Veri sahipliği ve erişim

İşletmenin hangi bilgileri tuttuğu ve bu bilgilere nasıl ulaşacağı açıklanmalıdır. Dışa aktarma biçimi, alanlar ve kayıt ilişkileri önemlidir. Bir tablo indirilebilmesi bütün eklerin ve geçmiş hareketlerin alınabildiğini göstermez. Kullanılan hizmetin güncel koşulları incelenir. Özel geliştirmede de aktarım veya rapor erişimi kendiliğinden tamamlanmış sayılmaz. Teslim kapsamı içinde hangi veriye hangi yöntemle ulaşılacağı konuşulmalıdır. Kullanım hakkı ve ticari koşullar gerektiğinde uzman desteğiyle ayrıca değerlendirilir.

SaaS mı özel yazılım mı karşılaştırmasında verinin nerede ve hangi düzenle tutulduğunu sorun. Teknik konum tek başına güvenlik veya uygunluk hükmü vermez. Kullanıcı yetkileri, saklama ve dış hizmet bağımlılıkları da önemlidir. İşletmenin gerçek yükümlülükleri ayrıca ele alınmalıdır. Bu yazı mevzuata uygunluk görüşü sunmaz. Amaç doğru soruların baştan sorulmasıdır. Bilginin asıl kaynağı ve güncel sorumlusu belli olduğunda hem kullanım hem ilerideki geçiş daha anlaşılır planlanabilir.

4. Bağlantılar ve mevcut programlar

Muhasebe, stok veya başka sistemlerle veri alışverişi gerekiyorsa bunu ayrı ihtiyaç olarak yazın. Hazır ürünün bağlantı listesinde isim görmek yeterli olmayabilir. Hangi işlemler, hangi sürümler ve hangi koşullar destekleniyor? Özel geliştirmede de karşı sistemin erişim olanakları incelenmelidir. Her programın gereken veriyi sunabildiği varsayılmaz. Resmi belgeler, test hesabı ve kullanım sınırları kontrol edilir. Bağlantının geliştirme bedeliyle üçüncü tarafın hizmet bedeli farklı olabilir. Hata takibinin sorumlusu da açıklanmalıdır.

SaaS mı özel yazılım mı kararında bağlantı ihtiyacını yalnızca ilk veri gönderimiyle sınırlamayın. Günlük güncelleme, başarısız kayıt ve tekrar gönderim düşünülmelidir. Aynı bilginin iki yerde değişmesi durumunda hangi kaynak geçerli olacak? Kullanıcı verinin güncelliğini nasıl anlayacak? Bu sorular kapsamı etkileyebilir. İyi çalışan bağlantı, sadece teknik istek göndermek değil iş açısından tutarlı sonuç üretmektir. Örnek senaryolarla deneme yapılması ve başarısız durumların görünür olması değerlendirmeye yardımcı olur.

5. Hesap ve güvenlik sorumlulukları

Hizmet sağlayıcının yönettiği alanlarla işletmenin sorumlu olduğu alanlar ayrılmalıdır. Kullanıcı açılışı, erişim iptali ve veri doğruluğu gibi işler işletmede kalabilir. Özel geliştirmede altyapı ve uygulama bakımını farklı taraflar yönetebilir. Microsoft’un bulutta paylaşılan sorumluluk açıklaması, hizmet türüne göre sorumlulukların değiştiğini gösterir. Bu kaynak belirli teklifinizin hukuki koşullarını belirlemez. İlgili hizmet ve anlaşma ayrıca incelenmelidir. Temel yaklaşım, yönetilen hizmet kullanırken işletmenin hiçbir sorumluluğu kalmadığını varsaymamaktır.

SaaS mı özel yazılım mı değerlendirmesinde doğru kişinin doğru kayda erişmesi temel konudur. Menülerin görünümü, dosya indirme ve kayıt ayrıntıları birlikte ele alınır. Bir ürünün tanınmış olması sizin ayarlarınızın doğru yapıldığını kanıtlamaz. Özel uygulamanın geliştirilmiş olması da kontrollerin kendiliğinden yeterli olduğu anlamına gelmez. Uygun teknik değerlendirme ve kullanım senaryoları gerekir. İşletme hangi rolün hangi bilgiyi görmesi gerektiğini açıklamalıdır. Bu kararlar teknik ekip tarafından varsayımla doldurulmamalıdır.

6. Başlangıç ve devam eden maliyet

Karşılaştırmada yalnızca ilk ödeme görülmemelidir. Lisans, kullanıcı sayısı, dış hizmet ve bakım gibi devam eden giderler olabilir. Özel geliştirmede de barındırma veya düzenli destek gerekebilir. Güncel ücretler ilgili teklif ve resmi tarifeden doğrulanmalıdır. Burada piyasa rakamı verilmez. Hangi dönemin karşılaştırıldığı ve hangi kullanım varsayımlarının geçerli olduğu yazılmalıdır. Bir seçeneğin düşük başlangıç bedeli, bütün dönem için daha düşük toplam yük getireceğini tek başına göstermez. İşletmenin kendi zamanı da önemlidir.

SaaS mı özel yazılım mı tablosunda aynı işleri karşılaştırın. Veri temizliği, eğitim ve geçiş bir seçenekte dahil, diğerinde işletmeye bırakılmış olabilir. Bu fark görünür olsun. Kullanım arttığında hangi koşulun bedeli değiştireceği sorulabilir. Özel projede yeni özelliklerin değerlendirme yöntemi, hazır hizmette paket değişikliğinin koşulları açıklanır. Gelecek fiyatların değişmeyeceği varsayılmamalıdır. Karar kesinleşmeden gerekli dış hizmetlerin ve sorumluların listesi hazırlanabilir. Böylece gizli kabul edilen iş yükleri daha erken görülebilir.

7. Kullanıma geçiş ve eğitim

Hazır uygulamanın bulunması, işletmenin ertesi gün bütün işlemlerini taşıyabileceğini garanti etmez. Veri, hesap ve kullanıcı hazırlığı gerekebilir. Özel uygulamada da geliştirme bitişi ile gerçek geçiş ayrı değerlendirilir. Eski sistemin hangi tarihe kadar kullanılacağı ve yeni kaydın nerede tutulacağı belirlenmelidir. Aynı verinin iki yerde değiştirilmesi tutarsızlık yaratabilir. Eğitim görevler üzerinden planlanabilir. Her kullanıcının bütün özellikleri öğrenmesi gerekmeyebilir. İlk gün yapacağı işlemi ve sorun bildirimi yöntemini bilmesi önemlidir.

SaaS mı özel yazılım mı seçimi yapılırken kullanıcı denemesine zaman ayırın. Gerçek görevler seçin: kayıt oluşturma, belge bulma veya rapor alma gibi. Kullanıcının nerede zorlandığı görülür. Bu bir çalışan sınavı değildir; çözümün anlaşılır olup olmadığını anlamak içindir. Alışılmadık ekran, eksik işlev ve yanlış veri ayrı sorunlardır. Her rahatsızlık yeni geliştirme gerektirmeyebilir; kısa açıklama veya ayar yeterli olabilir. Geri bildirimler sınıflandırılır ve zorunlu işler önceliklendirilir.

8. Destek ve değişiklik takibi

Destek kanalının ve sorumluların kim olduğu anlaşılmalıdır. Hata düzeltme, kullanım sorusu ve yeni özellik talebi farklı işlerdir. Hazır ürünün destek paketi her konuda özel geliştirme sağlayacağı anlamına gelmez. Özel projede de sınırsız yeni özellik varsayılmamalıdır. Hangi durumda nasıl başvurulacağı ve hangi bilgilerin isteneceği konuşulur. Yanıtla çözüm aynı olay değildir. İnceleme veya dış sağlayıcıdan bilgi beklenmesi gerekebilir. Gerçekçi hizmet açıklaması, ayrıntısı bilinmeyen geniş sözlerden daha kolay değerlendirilir.

SaaS mı özel yazılım mı karşılaştırmasında sürüm değişikliklerinin kullanıcıya etkisini de sorun. Hazır hizmette arayüz veya davranış sağlayıcı tarafından güncellenebilir. Özel sistemde güncellemelerin planı farklı kurulabilir. Her iki durumda da işletmenin hazırlığı gerekebilir. Kullanıcı belgelerinin ne zaman güncelleneceği ve önemli değişikliğin nasıl duyurulacağı açıklanmalıdır. Eski işleyişe dayanan iç yönergeler zamanla yanlış hale gelebilir. Yazılım bakımıyla işletmenin bilgi düzeni birlikte düşünülürse geçişler daha anlaşılır yönetilebilir.

9. Ayrılma ve başka çözüme geçiş

Bir gün farklı çözüm seçmeniz gerekebileceğini başlangıçta düşünün. Verilerin hangi biçimde alınacağı, hesapların ne zaman kapanacağı ve geçiş için hangi bilgilere ihtiyaç duyulacağı açıklanmalıdır. Kaynak kod ve kullanım hakkı koşulları özel projede ayrıca değerlendirilir. Hazır hizmette dışa aktarma sınırları veya ücretli işlemler bulunabilir; güncel koşullar kontrol edilir. Bu yazı belirli hakkın varlığına hükmetmez. Ticari anlaşmanın ilgili uzmanlarla incelenmesi gerekebilir. Teknik teslimle hukuki koşulların aynı şey olmadığı unutulmamalıdır.

SaaS mı özel yazılım mı kararında çıkış planı kötü niyet göstergesi değildir. İşletme büyüyebilir, ihtiyaç değişebilir veya kullanılan hizmet kapanabilir. Gelecekte bütün koşulların aynı kalacağı varsayılmamalıdır. Geçiş sırasında verinin anlamını korumak için alan açıklamaları ve kayıt ilişkileri gerekebilir. Sadece dosyayı almak yeterli olmayabilir. Hangi kaydın neyi temsil ettiğinin bilinmesi önemlidir. Önceden konuşulan devir yöntemi, ileride seçeneklerin daha bilinçli değerlendirilmesine yardımcı olur. Kesin geçiş planı gerçek koşullara göre hazırlanır.

Varsayımsal örnek: Ortak ihtiyaç ve özel onay kuralı

Bir işletmenin müşteri, teklif ve görev takibine ihtiyaç duyduğunu düşünelim. Bu tamamen varsayımsal örnekte hazır hizmetin temel işlevleri uygundur; ancak belirli siparişler farklı onay yolundan geçmektedir. Önce bu kuralın gerçekten vazgeçilmez olup olmadığı araştırılır. Hazır ürün ayarla karşılayabiliyor mu, ek bağlantı mı gerekiyor, yoksa süreç değişikliği kabul edilebilir mi? Özel geliştirmede aynı kuralın nasıl yapılacağı ve hangi diğer bölümleri etkileyeceği değerlendirilir. Karar sadece özellik adından çıkarılmaz.

SaaS mı özel yazılım mı sorusu örnekte birden fazla sonuca açık kalır. İşletme hazır ürünü seçebilir, sınırlı ek geliştirme kullanabilir veya farklı kapsamla özel uygulama yaptırabilir. Hiçbiri veriler ve koşullar görülmeden doğru ilan edilmez. Burada gerçek müşteri sonucu veya maliyet karşılaştırması bulunmaz. Örnek, temel ihtiyacın karşılanmasıyla özel kuralın öneminin ayrı değerlendirilmesini anlatır. Gerçek seçim için aynı senaryoların teklif edilen yöntemlerde nasıl çalıştığı gösterilmelidir. İşletmenin karar sorumlusu bu değerlendirmeye katılmalıdır.

Aynı ürün adının farklı paketlerini karşılaştırmak

SaaS mı özel yazılım mı araştırmasında hazır hizmetlerin paketleri, kullanıcı sınırları ve erişilebilen özellikleri farklı olabilir. Bir gösterimde gördüğünüz özellik aldığınız pakette bulunmayabilir. Güncel resmi açıklama veya teklif üzerinden doğrulama yapılmalıdır. Deneme hesabında açık olan bütün işlevlerin kalıcı pakete dahil olduğu varsayılmamalıdır. Özel geliştirmede de sunulan örnek ekranın sizin kapsamınıza dahil olup olmadığı sorulur. Tanıtım malzemesiyle teslim koşulları ayrı okunmalıdır. Gerekli işlevlerin hangi kayıtta taahhüt edildiği anlaşılır olursa yanlış beklenti azalabilir.

SaaS mı özel yazılım mı karşılaştırmasına bu nedenle ürün veya sağlayıcı adı değil, belirli kapsam ve koşul girilmelidir. İncelenen sürüm, paket ve teklif tarihi yazılabilir. Sonradan koşul değişirse değerlendirme güncellenir. Bir özelliğin bulunmaması her zaman seçeneği elemek için yeterli değildir; iş etkisi görülmelidir. Fakat vazgeçilmez işlevin gelecekte belki sunulacağına dayanarak kesin karar vermek de eksik olabilir. Bilinenle olası olan ayrılır. İşletmenin risk kabulü somut bilgiyle yapılmalıdır.

Karar tablosunu gerçek kayıtlarla doldurmak

SaaS mı özel yazılım mı için bir karşılaştırma tablosu hazırlanabilir. Dokuz ölçütün yanına sağlanan, sınırlı, belirsiz gibi durumlar yazılır. Her durumun açıklaması ve bilgi kaynağı bulunsun. Toplam puanlama kullanılsa bile kritik ihtiyacın belirsizliği gizlenmemelidir. Örneğin veri çıkışı vazgeçilmezse diğer güçlü özellikler bu eksikliği otomatik karşılamaz. Uygun durumda ek inceleme veya deneme istenir. Kararın gerekçesi kısa kayıtla korunabilir. Daha sonra ihtiyaç değiştiğinde hangi varsayımın yenilendiği görülebilir.

SaaS mı özel yazılım mı değerlendirmesinde işletme içi farklı görüşleri de toplayın. Yönetici raporu, satış çalışanı günlük girişi, operasyon sorumlusu istisnaları önemseyebilir. Tek kişinin görüşü bütün işleyişi temsil etmeyebilir. Herkesin her toplantıya katılması gerekmez; görev bazlı örnekler yeterli başlangıç sağlayabilir. Çelişen önceliklerin karar sahibi belli olmalıdır. Teknik ekip işletme adına hangi sürecin daha önemli olduğuna tek başına hükmetmemelidir. Karar ve uygulama sorumluluklarının ayrılması karşılaştırmayı daha anlaşılır kılar.

Tek bir özelliğin bütün kararı yönetmesini önlemek

SaaS mı özel yazılım mı karşılaştırmasında kullanıcıların en çok dikkatini çeken ekran bütün seçimi yönlendirebilir. Oysa güzel raporun arkasında gereken veri bulunmayabilir veya günlük giriş zor olabilir. Temel görevler ayrı değerlendirilmelidir. Kullanıcı kayıt açabiliyor, doğru veriyi bulabiliyor ve istisnayı yönetebiliyor mu? Yönetici raporu kendi sorusuna cevap veriyor mu? Bu ihtiyaçların önem sırası işletme tarafından belirlenir. Tek bir güçlü özellik diğer kritik eksikleri otomatik karşılamaz. Kararın gerekçeleri ayrı satırlarda gösterilebilir.

SaaS mı özel yazılım mı sorusunda bir eksikliğin gerçek iş etkisini araştırmak da önemlidir. Tercih edilen renk bulunmamasıyla gerekli onay rolünün olmaması aynı ağırlıkta değildir. Kullanıcı mevcut yöntemden farklı bir adım görünce onu eksik sanabilir. Bazen açıklama veya kısa deneme yeterli olur. Bazen gerçekten günlük iş karşılanmıyordur. Bu ayrım ancak somut görev üzerinden görülebilir. Ürün tanıtımındaki işaretler, kullanıcıların yaptığı işlemi tamamen temsil etmez. Değerlendirme süresini anlamlı örneklere ayırmak daha yararlı olabilir.

Kullanıcı sayısının ötesindeki ihtiyaçlar

SaaS mı özel yazılım mı seçilirken sadece kaç kişinin giriş yapacağı sorulmayabilir. Hangi roller bulunduğu, aynı anda hangi işlemlerin yapıldığı ve dosyaların büyüklüğü de önemlidir. Kullanıcı hesabı sayısı iş yükünün tamamını göstermez. Birkaç kişinin yoğun veri işlemesi ile çok kişinin ara sıra kayıt okuması farklı olabilir. Hazır hizmetin kullanım sınırları resmi belgelerden öğrenilir. Özel geliştirmede gereksinimler ve çalışma ortamı buna göre değerlendirilir. Ölçülmemiş kapasite veya hız için kesin sonuç söylenmemelidir.

SaaS mı özel yazılım mı karar kaydında büyüme varsayımları da bulunabilir. Yakında yeni şube açılması planlanıyor mu, dış kullanıcı eklenecek mi veya daha fazla belge tutulacak mı? Bunlar kesinleşmiş ihtiyaçla olası fikir olarak ayrılır. Her olasılığı ilk sürüme eklemek kapsamı gereksiz büyütebilir. Ancak bütün büyüme ihtimalini yok saymak da sonraki değişiklikleri zorlaştırabilir. Hangi durumda yeniden değerlendirme yapılacağı konuşulur. Seçimin bir defalık ve değişmez kabul edilmesi yerine, dayandığı varsayımların görünür olması daha faydalıdır.

İki çözümü birlikte kullanmak

SaaS mı özel yazılım mı her zaman tekini tamamen dışlamak anlamına gelmeyebilir. İşletme belirli işi hazır hizmette, kendine özgü başka süreci ayrı uygulamada yürütebilir. Bu yaklaşımın uygunluğu veri ve bağlantı koşullarına bağlıdır. İki sistem kullanılması otomatik olarak daha iyi veya daha ucuz sayılmaz. Tekrar veri girişi, yetki yönetimi ve hata takibi yeni sorumluluk doğurabilir. Hangi verinin asıl kaynağı olduğu açıklanmalıdır. Bir bilginin iki yerde değişmesi durumunda hangi kuralın geçerli olacağı belirlenir.

SaaS mı özel yazılım mı yerine birlikte kullanım düşünülüyorsa bağlantının kapsamı somut yazılmalıdır. Hangi alanlar hangi yönde taşınacak ve güncelleme hangi olayla yapılacak? Kaynak hizmetin güncel olanakları incelenir. Her bağlantı için dış sağlayıcıdan erişim veya ücret gerekebilir. İlk başarıyla gönderilen kayıt, bütün hata durumlarının çözüldüğünü kanıtlamaz. Yeniden deneme ve takip yöntemi planlanır. Kullanıcıya verinin güncelliği gerektiğinde gösterilir. İşletmenin bakım ve izleme kapasitesi bu seçenekte ayrıca önem kazanabilir.

Kararı ertelerken neyi öğrenmek gerektiğini yazmak

SaaS mı özel yazılım mı konusunda yeterli bilgi yoksa hemen karar vermek zorunda değilsiniz. Fakat araştırmayı belirsiz bırakmak yerine sorulara ayırın. Veriler dışarı alınabiliyor mu, zorunlu onay yolu ayarlanabiliyor mu ve kullanıcı temel işi yapabiliyor mu? Her sorunun bilgi kaynağı ve sorumlusu belirlenir. Demo, resmi belge veya örnek dışa aktarma farklı cevaplar sağlayabilir. Hangi sonucun kararınızı değiştireceğini düşünün. Böylece araştırma ürün tanıtımlarını tekrar tekrar izlemekten ibaret kalmaz; belirli belirsizliği azaltmaya odaklanır.

SaaS mı özel yazılım mı değerlendirmesi sonunda bütün belirsizliklerin sıfırlanması beklenmeyebilir. Bilinen sınırlar ve kabul edilen varsayımlar kaydedilir. İşletme hangi riski neden kabul ettiğini anlayabilmelidir. Sonraki kontrol noktasında hangi bilginin yeniden değerlendirileceği açıklanabilir. Karar kaydının amacı gelecekte kusurlu taraf bulmak değildir. Seçimin hangi koşullarda yapıldığını görmek ve yeni bilgiyle bilinçli güncellemek içindir. Uygun olmayan bir durum öğrenildiğinde önceki harcama tek başına devam gerekçesi olmamalıdır. Gerçek iş ihtiyacı yeniden ele alınmalıdır.

Yerel işletmeler için değerlendirme görüşmesi

SaaS mı özel yazılım mı araştıran Maltepe, İdealtepe ve Anadolu Yakası işletmeleri, mevcut iş akışını ve incelenen seçeneklerin sınırlarını HD Bilgisayar ile konuşabilir. İletişim numarası 0532 396 34 71, adres Altayçeşme, Oba Çıkmazı No:3, Maltepe, İstanbul’dur. Görüşme zamanı ve yöntemi ayrıca kararlaştırılır. Bu yazı belirli ürünün uygunluğu, fiyatı veya teslim süresi hakkında taahhüt oluşturmaz. Gereksinimler, veri ve sorumluluklar incelenerek yapılacak çalışma netleştirilir.

Seçim öncesi kontrol listesi

SaaS mı özel yazılım mı kararını vermeden önce karşılaştırılan koşulların aynı olduğundan emin olun. Paketler ve teslimler belirsizse önce açıklama isteyin. İşletmenin ayıracağı zaman, veri hazırlığı ve eğitim de düşünülmelidir. Sadece başlangıç fiyatına veya gösterim kalitesine dayanmak yeterli olmayabilir. Gerçek örneklerde kullanıcının beklenen işi yapabildiği görülmelidir. Teknik güvenlik ve veri erişimi için uygun kontroller ayrıca değerlendirilir. Açık sorular ve bunları cevaplayacak kişiler kaydedildiğinde karar daha bilinçli verilebilir.

• Temel iş akışı örneklerle karşılaştırıldı mı?
• Zorunlu kural ve kullanım tercihi ayrıldı mı?
• Özelleştirme sınırları güncel bilgiye dayanıyor mu?
• Veriye erişim ve dışa aktarma koşulları açık mı?
• Mevcut program bağlantıları incelendi mi?
• Hesap ve teknik sorumluluklar belli mi?
• Başlangıç ve devam eden giderler ayrıldı mı?
• Geçiş, eğitim ve destek düzeni planlandı mı?
• Çıkış veya devir için gerekli bilgiler biliniyor mu?

Sık sorulan 6 soru

Hazır hizmet her zaman daha ucuz mu olur?

Bu, karşılaştırılan kapsam ve kullanım dönemine bağlıdır. Kullanıcı, paket ve dış hizmet giderleri farklı olabilir. Özel geliştirmede de bakım ve çalışma ortamı gerekir. SaaS mı özel yazılım mı değerlendirmesinde aynı işleri ve dönemi karşılaştırın. İşletmenin veri hazırlığı ve eğitim zamanı da düşünülmelidir. Güncel tutarlar ilgili teklif veya resmi tarifeden doğrulanır. Her proje için tek maliyet üstünlüğü söylenmemelidir.

Özel uygulama bulutta çalışabilir mi?

İhtiyaca uygun mimariyle bu seçenek değerlendirilebilir. Özel geliştirme işlev kapsamını, bulut ise çalışma ortamını anlatır. Kavramlar tamamen karşıt değildir. SaaS mı özel yazılım mı sorusunda teknik yerle işlev uyumunu ayırmak gerekir. Hangi sorumlulukların sağlayıcıda, hangilerinin işletmede bulunduğu açıklanmalıdır. Her bulut hizmetinin aynı koşulları sunduğu varsayılmaz. Kullanılan çözümün belgeleri ve ticari şartları ayrıca incelenir.

Verilerimi her zaman dosya olarak alabilir miyim?

Bu, kullanılan hizmetin veya teslim kapsamının olanaklarına bağlıdır. Dışa aktarılan alanlar, ekler ve geçmiş ilişkiler kontrol edilmelidir. Tek tablo indirilebilmesi bütün verinin taşınabildiğini göstermez. SaaS mı özel yazılım mı seçiminde çıkış koşullarını baştan sorun. Ticari haklar ve teknik yöntemler ayrı değerlendirilir. Uygun durumda örnek dışa aktarma denemesi yapılabilir. İlgili yükümlülükler gerektiğinde uzman desteğiyle incelenmelidir.

Hazır ürün değiştirilemiyorsa hemen elenmeli mi?

Önce değişikliğin önemine bakın. Zorunlu iş kuralı ile ekran tercihi aynı değildir. Mevcut yöntem işi doğru karşılıyorsa alışkanlık değişikliği düşünülebilir. Karşılamıyorsa başka seçenek veya sınırlı ek çalışma gerekebilir. SaaS mı özel yazılım mı değerlendirmesinde gerçek kullanıcı senaryosu kullanın. Sadece tanıtımdaki özellik adlarına bakmayın. Hangi sınırın kabul edilebilir olduğu işletme tarafından açıkça belirlenmelidir.

Özel geliştirmede bütün yeni istekler yapılır mı?

Her talep ayrıca kapsam, teknik etki ve öncelik açısından değerlendirilir. Yapılabilir olması mevcut bedel veya takvime dahil olduğu anlamına gelmez. SaaS mı özel yazılım mı seçimi bu sorumluluğu ortadan kaldırmaz. Yeni isteğin hangi sonuç için gerekli olduğu açıklanmalı, etkilenen işler görünür olmalıdır. İşletme kararları ve kullanıcı değerlendirmesi gerekir. Değişikliklerin onay ve takip yöntemi başlangıçta konuşulabilir.

İlk görüşmede nasıl bir liste hazırlamalıyım?

SaaS mı özel yazılım mı karşılaştırması için vazgeçilmez üç işlemi ve bir istisnayı yazın. Kullanılan programları, veri kaynaklarını ve kullanıcı rollerini ekleyin. İncelediğiniz ürünün hangi paketini gördüğünüzü belirtin. Kesin olmayan bilgileri varsayım olarak işaretleyin. Teknik çözümü kendiniz tamamlamak zorunda değilsiniz. Günlük işte neyin aksadığını ve hangi sonucun gerekli olduğunu anlatmak, yöntem seçiminden önce daha yararlı başlangıç sağlar.