- ITSM aracı seçimi neden bir süreç kararıdır?
- İhtiyaç analizi: süreçleri, kullanıcıları ve kısıtları çıkarın
- Değerlendirme ölçütleri ve ağırlıklandırma
- Seçim süreci adım adım
- Demoyu siz yönetin: senaryo ve deneme
- Maliyet, referans ve risk kontrolü
- Geçiş planı, benimseme ve sık yapılan hatalar
- Bu beceriyi Mindset programlarında nerede çalışırsınız?
- Sık sorulan sorular
ITSM Yazılımı Nasıl Seçilir: İhtiyaçtan Geçişe Yol Haritası
ITSM aracı seçmek, ürün listesi karşılaştırmaktan önce kendi süreçlerinizi ve kullanıcılarınızı tanımlamayı gerektirir. Ağırlıklı ölçütler, senaryolu demo ve geçiş planı doğru aracı bulmanın yoludur.
Bir bakışta
- Seçim bir yazılım kararı değil, süreç kararıdır. Araç, olgun olmayan bir süreci düzeltmez; var olan süreci hızlandırır ya da görünür kılar.
- Ölçütleri demodan önce yazın ve ağırlıklandırın. Önceden belirlenmiş ağırlıklar, satıcının vitrinine göre karar vermenizi engeller.
- Demoyu satıcı değil siz yönetin. Kendi olay, talep ve değişiklik senaryolarınızı araçta çalıştırtın.
- Kısa listeyi küçük bir denemeyle sınayın. Gerçek kullanıcılar ve gerçek veriyle yapılan deneme, sunum kaynaklı iyimserliği düzeltir.
- Geçiş planı seçimin parçasıdır. Veri taşıma, eğitim ve eski sistemin kapatılması karar aşamasında maliyetlenmelidir.
ITSM aracı seçimi neden bir süreç kararıdır?
ITSM aracı, olay, talep, problem, değişiklik ve bilgi yönetimi gibi pratikleri yürüten ortak çalışma yüzeyidir. Araç ne kadar kapsamlı olursa olsun, kurumun hangi sorunu çözmek istediği belli değilse ekranlar doldurulur ama iş değişmez.
Seçime başlamadan önce şu soruya yazılı yanıt verin: bugün hangi sorun canımızı yakıyor? Kayıp talepler, bilinmeyen sahiplik, yinelenen olaylar, değişiklik kaynaklı kesintiler ve raporlanamayan hizmet seviyesi tipik başlangıçlardır. Yanıt, hangi modüllerin zorunlu hangilerinin sonraya bırakılabilir olduğunu belirler.
Seçim ekibini de baştan kurun. BT operasyonu, hizmet masası, değişiklik ve güvenlik sorumluları, iş birimlerinden en az bir kullanıcı temsilcisi ve satın alma birlikte çalışmalıdır. Yalnız altyapı ekibinin karar verdiği seçimlerde kullanıcı deneyimi, yalnız yöneticinin karar verdiği seçimlerde günlük iş akışı ihmal edilir.
İhtiyaç analizi: süreçleri, kullanıcıları ve kısıtları çıkarın
İhtiyaç analizi birkaç parçadan oluşur. İlki süreç envanteridir: hangi pratikler araçta yürüyecek, hangileri şimdilik tablo ya da e-posta ile kalacak? Sonra kullanıcı grupları: son kullanıcı, hizmet masası ajanı, teknik çözüm ekibi, değişiklik onaycısı ve yönetici ekranda farklı şeyler görmek ister. Son olarak kısıtlar gelir: mevcut altyapı, kimlik doğrulama, kullanılan izleme araçları, uyum ve veri yerleşimi beklentileri.
Her ihtiyacı zorunlu, önemli ya da olsa iyi olur olarak sınıflandırın. Bu sınıflandırma, kısa listeye giren her adaya aynı filtreyi uygulamanızı sağlar. Zorunlu ihtiyaçlardan birini karşılamayan aday, ne kadar güçlü olursa olsun elenir.
Bugünkü olay ve talep kayıtlarından gerçek örnekler toplayın. Bir olayın kaydedilmesinden kapanışına kadar hangi alanların doldurulduğunu, hangi onayların gerektiğini ve hangi raporların istendiğini çıkarın. Bu örnekler, demo aşamasında satıcıya verilecek senaryoların ham maddesidir.
Hizmet kataloğunun olgunluğu da analizin parçasıdır. Katalog yoksa araç seçimi, kataloğun nasıl oluşturulacağı kararıyla birlikte ele alınmalıdır; çünkü talep yönetiminin kalitesi büyük ölçüde katalog tasarımına bağlıdır.
Değerlendirme ölçütleri ve ağırlıklandırma
Ölçütleri gruplayın ve her gruba önem ağırlığı verin. Ağırlıkları demodan önce, ekip olarak ve yazılı biçimde belirleyin; sonradan ayarlanan ağırlıklar tercih edilen ürünü haklı çıkarmaya yarar.
- İşlevsel uyum: olay, talep, problem, değişiklik, bilgi tabanı, hizmet kataloğu, yapılandırma kaydı ve hizmet seviyesi takibi.
- Yapılandırılabilirlik: iş akışlarını, formları ve onayları kod yazmadan uyarlayabilmek.
- Entegrasyon: kimlik dizini, izleme araçları, iletişim kanalları ve varlık envanteri ile bağlantı yöntemleri.
- Raporlama: hizmet seviyesi, kapasite ve eğilim raporlarını ek çaba olmadan üretebilmek.
- Kullanıcı deneyimi: son kullanıcı portalı ve ajan ekranının sadeliği.
- Otomasyon ve yapay zeka: sınıflandırma, yönlendirme ve öneri özelliklerinin gerçek iş yükünde işe yarayıp yaramadığı.
- Güvenlik ve uyum: rol bazlı yetki, denetim izi, veri saklama yeri.
- Toplam sahip olma maliyeti: lisans modeli, kurulum, entegrasyon, eğitim ve işletme emeği.
- Tedarikçi: destek kalitesi, yol haritası şeffaflığı, yerel destek ve topluluk gücü.
Puanlamayı her aday için aynı kişilerin aynı ölçekle yapması gerekir. Puanın yanına kısa bir gerekçe ve kanıt (ekran görüntüsü, demo notu, referans görüşmesi) yazın; gerekçesiz puan toplantıda tartışma çıkarır.
Seçim süreci adım adım
Seçim, tek bir toplantı değil sıralı bir çalışmadır. Tipik akış şöyledir: ihtiyaç ve ölçütler yazılır, geniş bir aday listesi çıkarılır, zorunlu ihtiyaçlara göre kısa listeye inilir, senaryolu demolar yapılır, kısa listedeki adaylarla deneme yürütülür, referanslar ve maliyet modeli doğrulanır, karar verilir ve geçiş planına geçilir.
Kurumun büyüklüğüne göre RFP gerekip gerekmediğine karar verin. Kamu kurumları ve büyük şirketler çoğunlukla resmî teklif süreci işletir; küçük ekipler için ihtiyaç dokümanını adaylara göndermek ve yazılı yanıt istemek yeterli olabilir. Her durumda adaylara aynı belgeyi göndermek karşılaştırmayı adil kılar.
Süreç boyunca bir karar günlüğü tutun: hangi aday neden elendi, hangi varsayımlar yapıldı. Karar günlüğü, yönetim kuruluna ya da satın alma birimine hesap verirken ve ileride aracı değiştirme ihtiyacı doğduğunda işe yarar.
Seçim, ihtiyaçla başlar ve geçiş planıyla biter
- Hazırlıkİhtiyaç ve ölçütlerSorun, zorunlu ihtiyaçlar ve ağırlıklar yazılır.
- TaramaAday listesi ve elemeZorunlu ihtiyaçları karşılamayanlar elenir.
- SınamaSenaryolu demoKendi olay ve talep örnekleriniz araçta çalıştırılır.
- DoğrulamaDeneme ve referansGerçek kullanıcıyla küçük pilot, benzer kurum görüşmeleri.
- KararPuan ve maliyet modeliToplam sahip olma maliyetiyle birlikte karar alınır.
- GeçişTaşıma ve devreye almaVeri, eğitim ve eski sistemin kapatılması planlanır.
Demoyu siz yönetin: senaryo ve deneme
Satıcının hazırladığı demo, aracın en iyi yüzünü gösterir. Bunun yerine her adaya aynı senaryo setini verin: bir kullanıcı portaldan erişim talebi açıyor ve onay zinciri çalışıyor; hizmet masası ajanı bir olayı kaydedip ilgili ekibe yönlendiriyor; bir değişiklik talebi risk değerlendirmesi ve onayla ilerliyor; yönetici hizmet seviyesi raporunu görüyor.
Senaryoları satıcının hazırladığı örnek veriyle değil, kendi veri yapınıza yakın kayıtlarla çalıştırtın. Formu ya da akışı değiştirirken satıcı mühendisinin ne kadar uğraştığını gözlemleyin; bu, aracı sonradan kimin uyarlayacağının da ipucudur.
Kısa listedeki adaylarla küçük bir deneme yapılıyorsa kapsamı dar tutun: tek bir hizmet masası ekibi, tek bir hizmet ailesi, sınırlı bir süre. Başarı ölçütlerini önceden yazın; örneğin kaydın açılma kolaylığı, yönlendirme hataları, ajanın aldığı geri bildirim. Deneme, bir ürünün neye benzediğini değil, sizin ekibinizin onu kullanıp kullanamayacağını sınar.
Hazır yapılandırma mı, uyarlama mı sorusunun yanıtı süreç olgunluğunda yatar
- Süreçleriniz tanımsız ya da dağınıkVarsayılan yapılandırmayı benimseyinHazır iş akışları iyi bir başlangıç iskeletidir; özelleştirme sonra gelir.
- Düzenli süreç ve açık sahiplik varAraçta kendi akışınızı kurunUyarlanabilirlik ölçütünün ağırlığı yüksek olmalıdır.
- Mevzuat ya da sözleşme özel adım isterBu adımı demoda zorunlu senaryo yapınKarşılayamayan aday zorunlu ihtiyaçtan elenir.
Maliyet, referans ve risk kontrolü
Lisans bedeli maliyetin yalnız bir kalemidir. Kurulum ve yapılandırma emeği, entegrasyonlar, eğitim, yönetici ve ajan lisans türleri arasındaki farklar, ek modüller, yükseltme ve yıllık destek birlikte hesaplanmalıdır. Aynı hesabı her aday için aynı kullanıcı sayısı ve aynı kapsam varsayımıyla yapın, çünkü teklifler kuruma göre değişir.
Referans görüşmelerini yalnız satıcının önerdiği müşterilerle sınırlamayın. Benzer büyüklükte ve sektörde bir kurumla konuşmak isteyin, uyarlama yükünü, sürüm yükseltmelerini ve destek yanıt kalitesini sorun. Kullanıcı toplulukları ve bağımsız değerlendirme kaynakları ikinci bir bakış sağlar.
Riskleri açıkça yazın: tek tedarikçiye bağımlılık, veri çıkış yolu, sözleşme sonunda verinin biçimi, ürün yol haritasındaki belirsizlik. Sözleşmede veri iade ve çıkış hükmünün bulunması, ileride araç değiştirmeyi mümkün kılar.
Geçiş planı, benimseme ve sık yapılan hatalar
Seçim kararı, geçiş planı olmadan eksiktir. Mevcut kayıtların ne kadarının taşınacağına, ne kadarının arşivde kalacağına karar verin. Açık olaylar ve talepler taşınır, kapanmış eski kayıtlar çoğunlukla salt okunur arşivde tutulur. Hizmet kataloğu, sorumlu gruplar ve hizmet seviyesi tanımları araç devreye girmeden temizlenmelidir; bozuk veriyi yeni araca taşımak sorunu yalnızca yeni bir yere kopyalar.
Devreye almayı dalgalara bölün. Önce hizmet masası ve temel olay ile talep akışı, sonra değişiklik ve problem, en sonda yapılandırma kaydı ve ileri raporlama gelebilir. Her dalgadan önce ilgili ekibe eğitim verin ve kısa bir yaşam desteği dönemi planlayın.
Benimseme, araç açıldığında bitmez. Ajanların ve kullanıcıların yaşadığı sürtünmeleri toplayın, formları sadeleştirin, kullanılmayan alanları kaldırın. Başarıyı ilk dönemde kayıtların araçta tutulma oranıyla, çözüm süresindeki eğilimle ve kullanıcı geri bildirimiyle izleyin; hedefleri kurumunuzun kendi verisinden koyun.
En yaygın hata, özellik listesine bakarak karar vermektir: her ürün uzun bir liste sunar, fark ise günlük iş akışında ortaya çıkar. İkincisi, ölçütleri demodan sonra belirlemektir; etkileyici bir sunum ağırlıkları kendiliğinden değiştirir.
Bir başka hata, yalnız yöneticinin ya da yalnız teknik ekibin karar vermesidir. Hizmet masası ajanı, aracın en çok kullanıcısıdır ve seçime katılmayan ajan araca direnç gösterir. Ayrıca, bütün ihtiyaçları ilk gün istemektir; kapsamı geniş tutmak seçimi uzatır ve devreye almayı zorlaştırır.
Son olarak, süreç olgunluğunu hesaba katmamaktır. Olay ve değişiklik pratiği oturmamış bir kurum, en kapsamlı aracı alsa da kullanamaz. Böyle durumlarda araç seçimiyle eş zamanlı olarak süreç tasarımı ve sahiplik çalışması yürütülmelidir.
Bu beceriyi Mindset programlarında nerede çalışırsınız?
ITIL 4 Foundation eğitiminin hizmet değer sistemi, hizmet değer zinciri ve yol gösterici ilkeler başlıkları, bir aracın hangi pratiklere ve hangi akışlara hizmet etmesi gerektiğini anlamak için ortak dil sağlar. Hizmet masası, BT operasyon ve satın alma tarafında seçim ekibine katılacak kişiler için bu dil, ölçütleri yazarken işe yarar.
Yönetim düzeyinde çalışan ve seçim kararını sahiplenecek olanlar için ITIL 4 Intermediate programının yönlendirme, planlama ve iyileştirme ile paydaş değeri odaklı modülleri, aracı bir yatırım olarak değerlendirmeye yardımcı olur.
İlgili Mindset programı
ITIL® 4 Foundation Eğitimi
Sık sorulan sorular
Küçük bir BT ekibi için de resmî bir seçim süreci gerekir mi?
Resmî RFP gerekmeyebilir, ama ihtiyaç listesi, ağırlıklı ölçütler ve küçük bir deneme yine değerlidir. Küçük ekipte yanlış araç, tek kişinin iş yükünü hemen artırır. Birkaç saatlik yapılandırma denemesi, aylarca sürecek bir yanlış seçimi önler; gerektiğinde ihtiyaç belgesini adaylara yazılı olarak iletin.
Bulut tabanlı araç mı yerinde kurulum mu seçilmeli?
Bu karar veri yerleşimi, uyum gereksinimleri, işletme kapasiteniz ve yükseltme tercihleriniz tarafından belirlenir. Bulut hizmetinde altyapı emeği azalır, yerinde kurulumda denetim artar ama bakım yükü size geçer. Kuralınızı ölçüt listesine yazıp tüm adaylara aynı biçimde sorun.
Mevcut ITSM aracından başka bir araca geçmek ne zaman mantıklıdır?
Araç artık ihtiyaçları karşılamıyorsa, uyarlama maliyeti ve yükseltme zorluğu değerini aşıyorsa ya da tedarikçi desteği zayıfladıysa geçiş gündeme gelir. Önce sorunun araçtan mı süreçten mi kaynaklandığını ayırın; süreç sorunu yeni araçla da sürer.
Yapay zeka özellikleri seçimde belirleyici olmalı mı?
Sınıflandırma, yönlendirme ve öneri özellikleri değer katabilir, ama etkisini kendi kayıtlarınız üzerinde denemeden bilemezsiniz. Ölçütlerde ağırlığını sınırlı tutun, denemede gerçek veriyle sınayın, yanlış öneri durumunda ne olacağını görün ve hangi kararın insanda kalacağını önceden yazın.
Seçimi kim onaylamalı?
Teknik uygunluğu BT operasyon ve güvenlik, kullanılabilirliği hizmet masası ve iş birimi temsilcileri, maliyeti satın alma ve finans değerlendirir. Son onayı BT yönetimi verir, ancak ölçüt puanlarını ve karar günlüğünü paylaşmak sonraki sorgulamalarda ekibi korur.