Bunları Salesforce.com’un CEO’su Marc Benioff 2003 Haziranında, o zaman için yeni “bir servis olarak yazılım” (SaaS) konseptinin avantajlarını anlatırken söylemişti. Dört yıl hızlı geçti. Salesforce.com ve düzinelerce başka şirket kurumsal kullanıcıları ve CIO’ları her çeşit SaaS uygulamaları ile tanıştırdılar.

Şimdi SaaS “her yerde” görünüyor. Tabii, SaaS sağlayıcıları bugün CIO’ları yerlerinden etmek yerine onlarla birlikte çalışmak istiyorlar. Peki, CIO’lar SaaS sağlayıcılarla çalışmak istiyorlar mı?

Belki. Bazen. Medimmune isimli ilaç firmasının BT’den sorumlu başkan yardımcısı Peter Young, "SaaS sadece bir araçtır. Bir çözümler mozaiğinin bir parçasıdır" diyor. Accenture danışmanlık şirketinin CIO’su Frank Modruson da, "SaaS başım sıkıştığında kullanabileceğim, her zaman elimin altında olan araçlardan biri." diyor. Giyim perakendecisi American Eagle Outfitters’in CIO’su Rick Milazzo ise “SaaS elinizdeki seçeneklerden biri” diyor.

Fakat SaaS için besledikleri güçlü heyecana rağmen bu CIO’ların üçü de SaaS uygulamalarını epeyce tedbirli bir şekilde kullanıyorlar.

SaaS şimdiye kadar ağırlıklı olarak küçük çaplı firmaların kullanımı ile sınırlanmış gibiydi. AMR Research şirketinde araştırma direktörü olan Rob Bois, "Orta ölçekli pazarlardaki CIO’lar için SaaS kurumsal ölçekte işlevselliğe ulaşmanın tek yolu sayılabilirdi." diyor. Fakat SaaS’ın küçük firmalar için taşıdığı kıymet ne olursa olsun, bu kıymet büyük kurumların ihtiyaçlarına cevap vermeyebiliyor. Büyük kurumların CIO’ları SaaS’ın yazılım portföylerinde bir şekilde rol alabileceğini düşünüyorlar, fakat SaaS fanatikleri bile bu rolün kısıtlı bir rol olabileceğini söylemekteler.

Büyük Şirketler ve SaaS
Bir SaaS uygulamasını kullanmayı düşünen CIO’ların mutlaka sorması gereken birçok soru vardır. Fakat belki de en kritik olan soru şudur: Şirketiniz yüzlerce başka şirketin kullanımı için tasarlanmış bir yazılıma güven duyabilir mi?

Finans servisleri sağlayan bir şirketin IT bölümü olan Schwab Technology’nin finans, insan kaynakları, kiralama ve kurumsal iletişimden sorumlu başkan yardımcısı Lloyd Hohenstein “Size mahsus bir şeyler beklemeyin. Her şeyin özelleştirilmiş olmasına ihtiyaç duyuyorsanız SaaS ile başarılı olamazsınız” diyor.

Hohenstein, SaaS’ın eğer yapılmak istenen işlem çok karmaşık değilse anlamlı olduğunu söylüyor ve ekliyor: Teknolojinin içeride geliştirilmesini gerektiren -sağlayıcının garanti edemeyeceği servis seviyelerini temin etmek gibi- bir sebep olmadıkça SaaS iyi bir seçenek. Tabii, yazılımın işini gerçekten iyi yaptığı farzedilerek.

SaaS Nedir, Ne Değildir?
Gartner Araştırma’nın başkan yardımcılarından Ben Pring, “SaaS” kavramının sağlayıcılar tarafından sıklıkla “bir İnternet bağlantısı üzerinden erişilebilen uygulamalar” şeklinde atıf yapılarak, yanlış bir şekilde kullanıldığını söylüyor: “Bazı sağlayıcıların SaaS için geleneksel “uygulamada dışkaynak kullanımı” yaklaşımları gibi yeniden tanım yapmaları yüzünden, müşterilerin hem kafalarını karıştırıyor hem de tepkilerini çekiyor. “SaaS”, aslında uygulama portföyünüzdeki rolünü kavramanız için de temel teşkil edecek olan bambaşka bir anlama sahiptir.

SaaS modelinde, “çoklu kiracılı (multitenant) mimari” olarak bilinen, yazılımın tüm müşteriler tarafından kullanılacak bir kod temeli söz konusudur. Yazılım kullanıcıların bireysel ihtiyaçlarına göre konfigüre edilebilir olmakla birlikte, kodun kendisi herkes için aynıdır ve her müşteri için özelleştirilme gibi bir durum sözkonusu değildir. Bir müşterinin taleplerine göre yapılan geliştirmeler tüm müşteriler için de anında geçerli olur. Yani, bizzat yazılımın kendisi üzerine kurulu olan rekabet avantajını ya da farklılaştırmayı unutabilirsiniz.

SaaS’ın temelini oluşturan veri modeli ve sistem mimarisi de özelleştirilebilir değildir. Sağlayıcı açısından bunun avantajı, yazılımın birçok farklı versiyonları arasında uyumluluk ve yükseltme işlemleri için gereken zamanın çok daha az olmasıdır.

Ayrıca tüm müşteriler aynı versiyonu kullanacaklarından ve herkes yazılımı kendi ekipmanları üzerinde çalıştırmayacağından, şirketin müşteriler için sunduğu desteğin maliyeti de düşecektir.

Girişim sermayedarlarının SaaS’la yakından ilgilenmelerinin bir sebebi budur. 1996’dan bu yana SaaS girişimlerine yatırım yapan Foundation Capital’in ortaklarından Warren Weiss, girişim sermayedarlarının SaaS’ın başlangıç maliyetlerini düşürebilmesinden ve daha kısa bir “pazara sunma” süresi vaat etmesinden hoşlandıklarını belirtiyor.

Tier1 Research şirketinin başkan yardımcısı Michael Mankowski, CIO’lar için bunun bir çok avantaj manasına geldiğini söylüyor: “Daha hızlı kurulum (çünkü “yerinde kurulum” işlemi yoktur), güncel teknolojiye daha kolay erişim (çünkü değişiklikler sadece bir kod temelinde yapılabilir), daha az hata (çünkü tek koda sahip olmak hatalara yol açan karmaşıklığı azaltır). SaaS sağlayıcısı, tasarrufları müşterisine yansıtırsa şirket için maliyetler daha da düşebilir.

SaaS, uzun süredir var olan uygulama servis sağlayıcı (ASP), “iş süreci dışkaynak sağlayıcısı” (BPO) ve hizmet yönetimi sağlayıcısı (MSP) gibi, “talep-üzerine”, dışkaynaklı IT modellerinin yeni ve zekice bir çözüm yöntemidir (bkz. tanımlar kutusu)

Gartner’dan Pring, “SaaS için, yazılım geliştirmenin evriminde bir sonraki adım denebilir” diyor. Örnekler arasında Salesforce.com CRM, Everdream destek merkezi yönetim çözümü, SuccessFactors personel performans yönetimi ve Ketera harcama yönetimi yazılımı bulunmakta.

SaaS’ın İşe Yaradığı Yerler
Accenture’dan Modruson, bir CIO’nun SaaS’ı tercih etmesindeki en önemli sebepleri, daha hızlı çözüm sunması, altyapı ve peşin lisans maliyetlerinin olmaması ile sizin kaynaklarınızı “gerçek farkı ortaya koyan” özel süreçlere odaklamanıza izin verecek şekilde, standart iş süreçlerini kendi üzerine alması olarak sıralıyor.

Modruson, “Başlangıç maliyetleriniz o kadar fazla değil. Üstelik hızlı bir şekilde işleme alma ve gerekirse yön değiştirme imkânına sahipsiniz. Paket uygulamalarda bu ölçüde esnekliğim yok” diyor ve SaaS’ın tüm birimler arasında standart süreçlere ve standart bir sisteme sahip olma imkânı verdiğini söylüyor.

Uygulama alanının diğer uygulama ve süreçlere çok ileri seviyede entegre olması durumunda bu avantajların fazla bir anlamı yok. Sağlık ve temizlik mamülleri üreticisi Shaklee’nin CIO’su Ken Harris, bir SaaS uygulamasının düzgün şekilde yalıtılmış bir işlem için çözüm getirmesinin gerektiğini söylüyor. Modruson da, “SaaS işte o zaman büyük bir şirket için daha kolay bir çözüm hale gelir” diye ekliyor.

Accenture, SaaS çözümü ile bir “personel alım yönetimi” uygulaması başlattı çünkü bu iş süreci, başka sistemlerle önemli ölçüde bir etkileşim içine girmiyor. Ancak yeni bir eleman tutulduktan sonra, o eleman üzerindeki veri, Accenture’ın personel yetki, izin ve konumlarını yöneten kurum-içi ERP sistemine gönderilmiştir.

SaaS modelinin seçimindeki temel kriterlerden biri de, müşteri hizmetlerini geliştirme ya da rakiplere göre daha yüksek marjinler sağlama gibi, bir şirketin rekabet gücü açısından fark oluşturan uygulamalar olmamasıdır.

SaaS hakkında düşünmek bir şirketin bu konuları iyice düşünüp tartmasına yol açar. Bu da bir IT yatırım stratejisine karar vermek için başlı başına yararlı bir durum olur. AMR’den Bois, “Şirketler kendi iş süreçlerinin ne kadar kendilerine özgü olduğu konusunda abartılı bir görüşe sahiptirler. Her zaman aslında gerektiğinden çok fazla özelleştirmeye ihtiyaç duyduğunuzu düşünürsünüz.” diyor.

Ön-ofis personel alımı ve yerleştirmesi için Bullhorn’un SaaS yazılımını kullanan Sapphire Technologies’in CIO’su Martin Perry; “Bordro, Web konferansı hatta ofis verimlilik uygulamaları için kimi kullandığınıza kimse dikkat etmeyecektir.” diyor.

Accenture’dan Modruson, SaaS uygulamalarının bir çok şirketin dahili olarak çalıştırdığı paket uygulamalara göre daha az konfigüre edilebilir olduğunu (hepten özelleştirilemez olmadığını) söylüyor. Bu da şirketi gerçekte bir değeri olmayan özelleştirmelere kaynak aktarmaktansa standart iş süreçlerini kullanmaya zorladığı için aslında gizli bir lütuf gibidir.

Modruson, standart bir SaaS aracını kullanmanın her şirketin ondan aynı sonucu alacağı anlamına da gelmeyeceğini belirtiyor ve “Araç, iş süreçlerinizi mümkün hale getirir. Sizin kontrol ettiğiniz, iş süreçlerinizdir” diyor.

Salesforce.com gibi birçok CRM aracı, şirketlerin özgün iş süreçlerini standart fakat yüksek seviyede yapılandırılabilir, ayarlanabilir bir kod temeli üzerinde mümkün hale getirdiği için övülmektedir. Sapphire’dan Perry, “İşin sırrı, konfigürasyonda ve onu nasıl kullandığınızdadır. İş süreci farklılaştırmalarınız daha sonra sahne alır.” diyor. AMR’den Bois, Salesforce.com’un agresif pazarlama stratejisinden ve Oracle ve SAP gibi şirketlerin CRM çözümlerine kıyasla satışçılar için daha kolay kullanılabilir olmasından ötürü, SaaS’ın en iyi CRM alanında bilindiğini söylüyor. Bunda, satış ekiplerinin kullandıkları uygulamalar hakkında sıklıkla söz söylemeleri de yardımcı bir faktör.

SaaS, her ikisi de mazilerinde bir “servis bürosu” mantığı ile dışarıdan firmalar tarafından sunulmuş olan insan kaynakları ve satın alma iş modellerinde de yaygın bir şekilde kullanılabiliyor.

Örnekler arasında Concur Technologies’in harcama ve seyahat yönetim yazılımı, SuccessFoctor’un personel performans yönetimi yazılımı, ADP’nin kârlılık yönetimi yazılımı ve Ariba’nın satın alma yazılımı bulunuyor.

SaaS uygulamaları web analizleri, gemiciler için konteyner yerleştirme analizleri ve destek merkezi yönetimi gibi alanlarda da bulunabilir –ki hepsi de geçmişte dışarıdan hizmet büroları tarafından halledilmiş olan işlerdir. Tier1 analisti Mankowski, “bu alanlardaki uygulamalar genel olarak yığınsal veri değiş tokuşuna ve dahili uygulamalar için SaaS’ı kolay ve uygun bir seçim yapan standart, yaygın arayüzlere dayalıdır” diyor.

SaaS’ın yaygın bir şekilde benimsendiği üçüncü bir alan da WebEx, Citrix Online ve Adobe tarafından sunulan Web konferans servisleri.

Web konferansı ve araştırma ağları gibi uygulamalar bir SaaS yaklaşımı ile iyi bir uyum göstermektedir çünkü bu uygulamalar IT’nin uzmanlık ve operasyonlar için yatırım yapmak zorunda olmaksızın kullanıcılara işlevsellik sunmasını sağlamaktadır. Accenture’dan Modruson, “Bu ölçekle ilgili bir konu. Ben bir araştırma yazılımını kendim geliştirmezdim. Çünkü o kadar fazla araştırma yapmıyorum.” diyor.

SaaS Hangi Durumlarda Çok Anlamlı Değil?
Uygulamalar şirketin çekirdeğine –genellikle ERP, finansal, iş zekâsı ve üretim sistemleri– dokunuyorsa SaaS modeline dikkatli yaklaşılmalıdır. Shaklee’den Harris, bunun sebebini, bu uygulamaların genelde bir şirketi diğer rakiplerinden ayıran temel iş süreçlerini yansıtacak şekilde özelleştirilmiş olmalarına bağlıyor.

Örnek olarak, donanım distribütörü Zones şirketi satış ve dağıtımı analizi için bir dizi özel “iş zekâsı” uygulaması eklemek istedi. Fakat CIO ve başkan yardımcısı Anwar Jiwani bu sistemi kurum içinde geliştirmek ya da yönetimi için özel eleman tahsis etmek istemedi. SaaS destekli iş zekâsı araçları düşündü, fakat onların raporlarının fazla genel kapsamlı olacağını anladı. İstediği özel iş zekâsı uygulamalarını tasarlaması ve barındırması için SeaTab Software’le anlaştı.

Temel fikir, arzu edilen teknolojiyi elde ederken aynı zamanda Zones’un dahili kaynak yatırımlarını da minimumda tutmaktı. Jiwani, “Hedefim, iş zekâsı geliştirme işini dışkaynaklı halletmekti.” diyor.

SaaS uygulamalarından uzak durmak için bir başka sebep de, aradığınız işlevlerin aslında onlara sizin bizzat sahip olmanızı gerektirecek kadar kritik özellikte olmalarıdır.

İşlemci üreticisi Texas Instruments’in kurumsal iş uygulamalarından sorumlu başkan yardımcısı Dan Murphree; “Sürekli hizmet verebilme anlamında aşırı derecede yüksek standartlara sahibiz ve işlerimizi global esasta yürütüyoruz.” diyor. “Eğer bir SaaS uygulaması sadece bir saat süreliğine bile kullanılır durumda olmazsa, bu ciddi bir iş karışıklığına yol açar. Bunu yapabilecek servis sağlayıcıların olmadığını söylemiyorum. Fakat eğer biz onu kendi güvenilirlik ve kontrol seviyemizde yaparsak neye sahip olduğumuzu da biliriz.” Murphree, SaaS uygulamalarını aksama süresinin işleri kesintiye uğratmayacağı bir taşeron yönetim yazılımı olan IQNavigator gibi, kritik olmayan fonksiyonlar için ayırıyor.

Genel olarak SaaS’ı liste dışı bırakan bir diğer konu ise entegrasyondur. Disk sürücü üreticisi Seagate Technology’nin CIO’su Mark Brewer, Oracle ile yaptıkları “talep üzerine ERP” görüşmesinde “hayır” demişti. Brewer, “Eğer yazılım güncellemeleri için uğraşmak zorunda kalmasam gerçekten harika olurdu fakat IT sistemimin geri kalanı ile çok fazla entegrasyon noktası var. Bununla uğraşmak çok büyük bir problem olacaktı” diyor. Fakat birçok SaaS temelli insan kaynakları uygulamasını yüklemekte bir sakınca görmedi, çünkü entegrasyon basit ve kolaydı.

CRM’i de içeren bazı uygulama sahaları SaaS için “gri bölge” durumunda. Bir yüksek teknoloji tedarikçisi, Salesforce.com yerine sonunda Oracle’ın CRM yazılımını seçmeye karar verdi. Çünkü CRM kullanımları siparişten nakite kadar uzanıyor, uygulamayı ERP sisteminin kalbine getiriyordu.

Satışçılar Salesforce.com’u tercih ettiler, fakat CIO onu şirketin satış süreçleri için gerekli olan ERP işlem seviyesinde çalıştırmayı başaramadı. Bütün şirketler satış tahminlerini ve envanterlerini sürekli olarak yeniden ayarlamak zorunda olmadıkları için bu seviyede bir entegrasyona gerek duymazlar. Schwab’dan Hohenstein, buna gerek duyanlar için, meselenin karmaşık bir entegrasyon işi anlamına geldiği görüşünde. Deloitte Danışmanlık şirketinin SaaS uygulamasında yönetici olan Tina Phillips, “Eğer sahada biri siparişleri alıyorsa bu entegrasyona ihtiyaç duyacaklardır. Değilse, veri yığınsal olarak bir defada gönderilebilir.” diyor.

Entegrasyon: Bir Meydan Okuma
Gartner’dan Pring, SaaS uygulamalarını kullanmanın rahatlığı –özellikle karar verme iş kullanıcıları öncülüğünde yapılıyorsa-- bir “IT meydan okuması” denebilecek önemli bir konuyu gözlerden kaçırabilir diyor. Bu meydan okuma hem diğer kurumsal uygulamalarla hem de veri kaynakları ile entegrasyondur.

Bazı açılardan, SaaS entegrasyonu kurum-içi ya da ASP destekli uygulamaların entegrasyonundan daha kolay olabilir. Bunun sebebi SaaS’ın “çoklu kiracılı (multitenant” yapısının sağlayıcıların veri değiş tokuşuna ve diğer uygulamalara dönük uygulama programlama arayüzlerine (API) daha fazla önem vermesini gerekli kılmasıdır. Böylelikle, geniş bir yelpazedeki müşterilerin SaaS uygulamasını herhangi bir özelleştirmeye ya da önemli bir desteğe gerek olmadan kullanabilmeleri mümkündür.

Sapphire’den Perry, “Entegrasyon nispeten kolay, çünkü birisi zaten onun üzerinde epeyce düşünmüş durumda.”

MedImmune’dan Young, SaaS uygulamasının diğer kurumsal uygulamalardan ne kadar ayrılmış olduğunun başka bir faktör olduğunu söylüyor ve “Eğer gevşek bağlı bir uygulama sahasında XML gibi ortak API’ler kullanıyorlarsa, SaaS uygulamalarını tutturmak daha kolay olabilir.” diyor.

Gartner’dan araştırma başkan yardımcısı Rob Desisto, kurumsal verilerle entegrasyonun daha kolay bir mesele olduğunu söylüyor. Desisto, SaaS uygulamalarının çoğunun uygulama sahalarındaki standart veri formatlarını içeri ya da dışarı aktaracak şekilde tasarlandığını söylüyor ve ciddiye alınmak isteyen sağlayıcılar için bundan başka bir seçenek olmadığını da ekliyor.

Dijital görüntüleme sağlayıcısı EFI’nin CIO’su Calvin Do, SaaS’ın genellikle gerçek zamanlı işlem ortamlarından ziyade, en iyi şekilde, verilerin periyodik ve yığınsal olarak aktarıldığı ortamlarda çalıştığını söylüyor. EFI’de satışçılar iş fırsatlarını yönetmek için Salesforce.com’u kullanıyorlar, fakat fiyat teklifi aşaması geçildiğinde veriler anlaşma analizi ve sipariş yönetimi için ERP sistemine geçiyor. Benzer olarak, performans incelemeleri ve özgeçmiş analizi SuccessFactors’da hallediliyor.

Fakat yeni işe alımlar, ücret ve ünvan değişiklikleri ERP sistemine aktarılıyor. Bu yaklaşım, veriler ERP sistemine girildiğinde bağdaştırma için bir tür özel entegrasyon işlemini olduğu gibi, ERP ve SaaS uygulamaları arasında verilerin ikili kaydını da gerektiriyor. Calvin Do, bu çabanın, birlikte işlerlik için o kadar da iyi tasarlanmamış olan kurum-içi uygulamalar arasında yapılacak benzer bir entegrasyon işlemi için gerekenin yarısı kadar kaynak gerektirdiğini ifade ediyor.

Çoklu SaaS uygulamalarının benimsenmesi birçok açıdan 1990’lı yıllarda şirketlerin “türünün en iyisi” oldukları söylenen uygulamaları getirmelerine ve sonra da her bir uygulamanın üstünde olan iş süreçlerini çalıştırmak için onları nasıl entegre edeceklerini düşünmeye başlamalarına benziyor. Pring, SaaS sağlayıcılarının genel olarak başka uygulamalara bağlanmak ve standartları kullanmak konusunda on yil öncekilerden daha iyi durumda olduklarını kabul etse de, “Bu durum tuhaf bir şekilde 10 yıl öncesini hatırlatıyor.” diyor.

O zamanlar birçok işletme, “türünün en iyisi” uygulamaların entegrasyonu için çabalamanın maliyete değmeyeceğine karar vermişler, onun yerine yazılım setlerini tercih etmeye başlamışlardı. Gartner’dan Desisto, o tip ilk yazılım setlerinin yaygınlaşmaya başlamış olması ve CIO’ların spesifik bir SaaS uygulamasının, onları şu anda ellerinde olan ve yoğun bir şekilde yatırım yaptıkları yazılım setleri ile rekabet edebilecek ek SaaS uygulamaları getirmeye yöneltebileceklerini anlamaları, aynı durumun SaaS için de gerçek olacağını gösteriyor.

Örnek olarak, Salesforce.com kendi CRM yazılımı ve AppExchange platformu üzerinde bir yazılım seti geliştirmek niyetinde. Böylece diğer şirketler Salesforce.com ile aynı mimari ve veri modelini kullanan eklenti uygulamaları geliştirebilecekler. Dolayısıyla, Salesforce.com terfi edildiğinde aksamalara yol açabilecek olan özelleştirme gereksinimi bertaraf edilmiş olacak. Tier1’den Mankowski, ERP sağlayıcısı NetSuite’in ara-pazarlar için sınırlandırılmış da olsa, benzer bir stratejiye sahip olduğunu söylüyor.

Standartları Nasıl Korumalı?
SaaS uygulamalarının çalıştırılması gündemde iken başka meseleler de çıkıyor fakat bunlar IT’de dışkaynak kullanımında deneyimli firmaların aşina olduğu şeyler. Yine de tüm SaaS sağlayıcılarına, özellikle de küçük çaplı müşterilere odaklanmış olanlara aşina olmayabilirler. Servis seviyeleri: Yazılımı dışarıdaki bir oluşum çalıştırdığı için, kurumunuzun ihtiyacınız olan ‘kesintisiz çalışma’ (uptime) ve diğer servisleri alamayacağı endişesi her zaman vardır. Bazı CIO’ların SaaS hakkındaki kaygılarını haklı çıkartacak şekilde, geçen kış Salesforce.com’dan çok sayıda servis kesintisi haberleri geldi.

AMR’den Bois, Salesforce.com ve diğer sağlayıcılar için ”Fakat o zaman büyük meseleler olmamıştı.” diyor ve güvenilirliğin eskiden olduğu kadar büyük bir problem olmadığını ekliyor. Çünkü SaaS sağlayıcıları yüzde 99.999 gibi, genellikle çoğu kurumla aynı ‘kesintisiz erişilebilme’ seviyesini sunmakta. Bois, SaaS anlaşmasının en azından yüzde 99.5’lik bir erişilebilmeyi temin edecek bir “servis seviyesi anlaşması” (SLA) içermesini de salık veriyor.

Gartner analisti Pring, SaaS sağlayıcıların çoğunun servis seviyesi anlaşmalarına olan ihtiyacı öngörmelerini beklemeyin diyor. SaaS sağlayıcıların orta seviye pazarlara odaklandığı gerçeğini yansıtacak şekilde, “SaaS uygulamalarının yüzde 85’inde servis seviyesi anlaşmaları (SLA) yok. Daha çok, ağırlıklı olarak büyük çaptaki kurumları hedefleyen sağlayıcılar SLA’ların öneminin farkında”.

Güvenlik. Birçok CIO’nun zihnindeki güvenlik endişeleri azalmış durumda. Şimdiye kadar SaaS sağlayıcılarda bir güvenlik gediği rapor edilmedi. EFI’den Do, hassas bilgilerin dışarıya gönderilmesi beni endişelendirdi, fakat o zaman bordro bilgilerini zaten göndermiş olduğum aklıma geldi ve dışarıdaki sağlayıcılara güvenebileceğimi düşündüm.” diyor. Yine de güven duymadan önce, sağlayıcıların güvenlik planlarını test ediyor ve onaylıyor. Hohenstein, Schwab bazı durumlarda karışık depolamaya izin verse de, kritik bilgiler sözkonusu olduğunda SaaS sağlayıcılarının verilerini ayrı bir depolama donanımı üzerinde tutmasını tercih ettiğini söylüyor ve ekliyor: “Öyle ya da böyle güvenlikle ilgili çok sıkı şartlarımız var.”

Fakat herkes kolay güvenemiyor. Texas Instruments’dan Murpree, “Hassas bilgileri kullanacak uygulama için bir SaaS sağlayıcısına gitmedik. Kontrolü elden bırakmak istemiyoruz.” diyor. Risk yönetimi. Gartner’dan Desisto, CIO’ların SaaS sağlayıcılardan diğer dışkaynak sunuculardan bekledikleriyle aynı inceleme ve kontrol şartlarını talep etmesi gerektiğini söylüyor. Bunlara, sağlayıcının işten çekilmesi durumunda yazılımın ve tüm verilerin teminat altına alınması, veri gizliliğinin temin edilmesi için “güvenli bölge” (safe harbor) garantisi sağlanması ve sağlayıcının geçirdiği denetlemeleri inceleyebilme yetkisi de dahil.

Accenture’dan Modruson, sertifikasyon süreçlerinin artık standart olduğunu ve harici sertifikasyon için hatırı sayılır bir şirketle çalışmanın daha kolay olduğunu söylüyor. EFI’den Do için önemli olan, bu ihtiyacı anlayan SaaS sağlayıcılarını bulmak. Durumu “Çoğu küçük çaplı şirketler olduğu için lamba, olması gerektiği kadar fazla yanmıyor.” şeklinde özetliyor. Sapphire’den Perry ise, sağlayıcının çökmesi durumunda yeni bir çözüm bulana kadar kurum içi çalıştırmak üzere yazılımın kullanım hakkını almanın da bir başka tedbir olduğunu söylüyor. Bunların bir parçası olarak, SaaS sağlayıcısı tarafından saklanan verilerin yedeklerini aldığınızdan emin olmalısınız.

SaaS’ın kullanımı riskin azaltılmasına da yardımcı olabilir. MedImmune’dan Young örnek olarak, "SaaS’ı hızlı bir şekilde devreye almaya çalışmak, en kıt kaynaklar olan dahili kaynaklara bir sürü para yatırmaktan daha az risklidir” diyor.

Bazı endüstrilerde SaaS sağlayıcıları müşterilerin risklerini üstlenebilirler. Colorado Capital Bank’ın CIO’su Basil Blume buna örnek olarak birçok küçük Amerikan bankası, İnternet bankacılığı ve servet yönetimi platformları için Intuit’in Digital Insight bölümü gibi SaaS sağlayıcıları kullandığını gösteriyor. Küçük bankalar böyle bir yazılımın kanuni düzenlemeleri ve güvenlik gereksinimlerini karşılamak için gereken kaynaklara sahip değiller, bundan dolayı, onlar için bunu yapabilecek, düzenleyiciler tarafından denetlenen ve bir hata durumunda finansal olarak sorumluluğu üstlenen şirketleri kullanmak daha anlamlı.

Blume “Riski transfer ediyoruz. Ödenecek bir miktar var fakat bu durumda da geliştiricileri kadroda tutmama gerek kalmıyor ." diyor.

Gelecek: SaaS Adımı
Endüstri olgunlaştıkça şirketler SaaS modeline giderek daha kritik görevler için de güvenebileceklerini fark edebilir, belki bir gün ERP uygulamalarını bile bu modelde çalıştırabilirler.

Scintific Games’in CTO’su Steve Beason, “SaaS üzerinden ERP’yi düşünürdüm, fakat sadece teknik aksaklık durumunda değil, finansal olarak da korunmaya ihtiyaç duyardım” diyor.

Gartner’dan Pring, böyle bir şeyin mümkün olması için daha yapılacak çok iş olduğunu söylüyor. SaaS bugün mümkün, çünkü geçmişe nazaran artık daha az “kuruma özel” kod var. Pring, "Yirmibeş yıl önce herşey özel kodlardan ibaretti. 15 yıl önce ERP yazılımları paketlendi ve özel kodları azalttı.” diyor. Fakat günümüzde özel kod, kurumsal yazılımların hâlâ yaklaşık yüzde 60’ını oluşturuyor. Bu da, SaaS’ın henüz halledemeyeceği bir çok sahanın var olduğu anlamına geliyor.

“Orta ölçekli pazarlardaki CIO’lar için SaaS kurumsal ölçekte işlevselliğe ulaşmanın tek yolu sayılabilirdi.”

Şirketler kendi iş süreçlerinin ne kadar kendilerine özgü olduğu konusunda abartılı bir görüşe sahiptirler.

Yazılım servislerinin artılarını hesaplarken yönetim maliyetlerini de ekleyin. Yazılım Servisleri (SaaS) uygulamaları genel olarak aylık-kullanıcı başına kiralanmaktadır. Peşin lisanslama masrafları ve önceden hazırlanması gereken ekipman ya da geliştirme kaynaklarına da gerek yoktur. Abonelik bedeline terfi işlemleri gibi yazılım bakımı ve operasyonel giderleri de dahildir.

CIO’lar bu modeli severler. MedImmune ilaç firmasının IT’den sorumlu Başkan Yardımcısı Peter Young "Geleneksel uygulamaları ‘kullandığın-kadar-öde’ modeline çevirmek isterdim" diyor. –Bunu, terfi işlemleri zamanı geldiğinde geleneksel sağlayıcılarla tartışmaya başlamış. (Nucleus Research firmasında analist olan Rebecca Wettemann, "Abonelik ücretlendirmesini talebe bağlı ödeme modeline bağlamaya gerek yok” diyor.)

SaaS ücretlendirmesinin belki de en zorlu kısmı, abonelik şeklindeki ücretlendirme modelinin yazılımın kurum içinde yüklenip çalıştırılmasından daha yüksek bir “toplam sahip olma maliyeti” getirip getirmeyeceğinin tespit edilmesidir.

Kurumların bir çoğu lisansların maliyetini ve yıllık bakım ücretlerinin ne kadar olduğunu bilirken, birçoğu operasyonlar ve destek ekibi, donanım, ağ kaynakları gibi operasyonel maliyetleri bilmez, bundan dolayı kurum içi çözüm maliyetinin SaaS maliyetlerine oranını da bilmez.
Perakende sektöründe faaliyet gösteren American Eagle Outfitters’in CIO’su Rick Milazzo, hesaplamaları yapabilenlerin sadece yeni lisansları değil, hangi sıklıkla terfi yapılacağını ve terfi işlemlerinin gerçek maliyetlerini bilerek aynı zamanda entegrasyon, eğitim ve operasyon maliyetlerini de tahmin etmeleri gerektiğini belirtiyor.
Benzer bir şekilde, SaaS uygulamalarının kullanım tahminleri de kesinlik göstermez. AMR Research’ten analist Rob Rois, “Her ikisinde de maliyetler mükemmel olarak öngörülebilir değildir” diyor.

Fakat bir çokları için, SaaS konusunda önemli olan, toplam sahip olma maliyeti değildir. Kurumlar eğer bir SaaS uygulaması geleneksel bir lisansın beş yıllık amortismanından ve bakım masraflarından daha fazla bir maliyet getirmezse almaya değeceği yönünde kabaca bir hesap yaparlar. Hatta ilk başta biraz yüksek maliyetli olsa bile, yazılımın bakımını yapmak zorunda kalmayacak olmak, ödenecek meblağa değer.

CRM’i de içeren bazı uygulama sahaları SaaS için “gri bölge” durumunda.

“Talep Üzerine Bilgi İşlem” İçin 3 Yöntem
Bu, “talep üzerine (On-Demand) bilgi işlem” modellerinin üç tipi için açıklamalı bir mini sözlüktür.

ASP: Uygulama servis sağlayıcı (application service provider) genelde kritik olmayan bir IT fonksiyonunun hazırlanmasını üstlenir, çünkü CIO onun sahibi olmanın getireceği maliyetleri yüklenmek istemez. Entegrasyon ve uyumluluk konuları ise kurum içi çalıştırılan yazılımdan farklı değildir. Elde edilen maliyet tasarrufları ASP’nin stratejisinin sunduğu temel bir etkinlik avantajına değil, genellikle ASP’nin denizaşırı ve daha ucuz işgücü kullanımına bağlıdır.
Örnekler: Oracle’ın On-Demand ERP yazılımı, HP’nin Workday yazılımı ve web barındırmaları.
BPO bir “iş süreci dışkaynak sağlayıcısı” (business process outsourcer). Ödemelerin gönderilmesi veya kredi kayıtlarının takibi gibi işlerden birinin tüm süreçlerini sizin için halleder. Bu, sağlayıcının fonksiyonu nasıl sunduğu CIO için fazla önemli değilse işe yarar. Satın aldığınız şey, sonuçtur.
Örnekler: ADP bordrolama, Accel tıbbi çevrim ve ödeme işlemleri ile Fair Isaac kredi kayıt servisleri.

MSP: Bir şirket adına bir hizmetler dizisini yürüten “hizmet yönetimi sağlayıcısı”. Bunlar IT servisleri (e-posta güvenliği ve yönetimi gibi), iş servisleri (telekom harcamaları ile ilgilenmek gibi) ya da her ikisi de (bir çağrı merkezinin yönetimi gibi) olabilir. BPO’nun aksine, burada CIO bir MSP’de hangi teknolojilerin yer aldığına, o MSP’nin yaptığı işin diğer IT sistemlerinin ve tabii o kurumun iş süreçlerine nasıl etkileşime girdiğine müdahale edebilir. MSP’ler genellikle kurumun yönetmede fazla başarılı olmadığı, sık değişim gösteren ve yoğun gözetim gerektiren (virüs engelleme ve telekom harcamaları yönetimi gibi) işler için yarayışlıdır.
Örnekler: ScanSafe virüs tarama, Vercuity telekom harcama yönetimi ve Echopass çağrı merkezi operasyon servisleri. Bazı durumlarda, MSP’ler müşterilerine öz-yönetim (bir SaaS hizmeti üzerinden) ve tedarikçi yönetimi (bir MSP hizmeti üzerinden) seçenekleri sunuyorlar.

“Riski transfer ediyoruz. Ödenecek bir miktar var fakat bu durumda da geliştiricileri kadroda tutmama gerek kalmıyor.”