ITSM.express

Versiyon 1.1, 18 April 2024

Ekip

Proje Yöneticisi

Štefan Ondek

Yazarlar

Johann Botha
Etienne Shardlow
Dolf van der Haven

Gözden Geçirenler

Suzanne van Hove
Wim Hoving
 

Bilgilendirme Notu

“Hizmet yönetimini yalnızca ‘hizmet yönetimi’ olarak mı değerlendirmeliyiz, yoksa ‘bilişim teknolojileri (BT) hizmet yönetimi’ olarak mı ele almalıyız? Ya da tamamen farklı bir kavram mı düşünmeliyiz?” gibi soruları ve daha fazlasını kapsayan birçok farklı bakış açısının farkındayız.

Rehber bağlamında, bu konuyu açıklığa kavuşturmak için öncelikle şunu soralım: "Günümüzde hangi hizmet herhangi bir teknolojiye dayanmadan sunulabilir?" Bu sorunun cevabı oldukça basit: Bugün teknoloji, dijital bilgi veya benzeri unsurları kullanmayan bir hizmet neredeyse yok denecek kadar az.

ITSM.express isminden de anlaşılacağı üzere, bu rehberde BT hizmet yönetimini ele alıyoruz. Ancak, burada yer alan bilgilerin yalnızca teknoloji ve dijital alanla sınırlı olmadığını, farklı sektör ve alanlarda da uygulanabilir olduğunu vurgulamak isteriz.

Bu rehberde hizmet yönetimi şu şekilde tanımlanmaktadır: Bir organizasyonun, müşterilerine ve kendisine değer sağlamak amacıyla, çalışanlarının hizmet yaşam döngüsü boyunca gerçekleştirdikleri faaliyetleri destekleyen organizasyonel yetkinlikler, süreçler ve yapıların bütünüdür.

BT hizmet yönetimi (ITSM) ise hizmet yönetiminin bir alt kümesi olup, öncelikli olarak bilgi teknolojisi bileşenlerinden oluşan hizmetlere odaklanır.

Rehberin okuma (ve yazma) kolaylığı açısından, BT hizmet yönetimi yerine “hizmet yönetimi” terimi tercih edilmiş; örnekler ve açıklamalar ise teknoloji odaklı organizasyonlar üzerinden ele alınmıştır.

Önsöz

ITSM.express rehberi, hizmet yönetiminin temel unsurlarını kapsayan, minimalist ve ücretsiz bir kaynaktır. Hizmet yönetiminin kolayca öğrenilmesi, uygulanması ve öğretilmesi amacıyla özel olarak hazırlanmıştır. ITSM.express’in hedef kitlesi, hizmet yönetimi alanında yolculuğuna yeni başlayan, yeni bir hizmet yönetimi sistemi kuran veya mevcut sistemlerini iyileştirmek isteyen kişi ve organizasyonlardır. Bu rehberde mevcut ticari çerçevelere herhangi bir atıfta bulunulmamış, yalnızca standartlar temel alınmıştır. Bu yaklaşımın amacı, ITSM.express rehberinin hizmet yönetimiyle ilgilenen herkes için ücretsiz ve erişilebilir kalmasını sağlamaktır.

Minimalist bir içeriğe sahip olmakla birlikte, bu rehberde yer alan bilgiler ISO/IEC 20000-1:2018 standardı ile uyumludur. ISO/IEC 20000-1 ve diğer birçok (BT) hizmet yönetimi sistemi, hizmet yönetimi faaliyetlerini genellikle birbirinden bağımsız olarak ele alırken, ITSM.express rehberi etkili bir yönetim sistemi oluşturmayı Tanımla, Oluştur, Sun ve Yanıtla olmak üzere dört ana hizmet yönetimi eylemi üzerinden açıklamaktadır.

Bu rehber, sektörün deneyimli uzmanları ve önde gelen isimleri olan Johann Botha, Dolf van der Haven ve Etienne Shardlow tarafından hazırlanmış; Suzanne Van Hove ve Wim Hoving tarafından da gözden geçirilmiştir. Rehberin editörü ve bu projenin arkasındaki isim ise Štefan Ondek’tir. Kendisi, proje ve hizmet yönetimi alanlarında deneyimli bir eğitmen, danışman ve uzman olarak tanınmaktadır. Bahsi geçen kişiler, rehbere tamamen gönüllü olarak ve herhangi bir maddi karşılık beklemeden katkı sağlamıştır. Kendilerine buradan tekrar teşekkür ederiz.

Bu yayının fikrî mülkiyet hakları Slovakya’da kayıtlı, kâr amacı gütmeyen ITSM.express kuruluşuna aittir. Rehber, Creative Commons Attribution license lisansı altında yayınlanmıştır ve bu lisans kullanıcılara aşağıdaki hakları tanır:

• Atıf — İçeriği kullanırken uygun şekilde kaynak göstermeli, lisans bağlantısını eklemeli ve içerikte herhangi bir değişiklik yaptıysanız bunu açıkça belirtmelisiniz. Bu işlemleri, lisans sahibinin sizi veya kullanım biçiminizi onayladığı izlenimini vermeyecek şekilde gerçekleştirmelisiniz.

• Ek kısıtlamalar uygulanamaz  — Bu lisansın izin verdiği kullanımları başkaları için yasal ya da teknolojik yollarla kısıtlayacak herhangi bir ek koşul getiremezsiniz.

Bu rehberin kullanımından doğacak durumlara ilişkin herhangi bir güvence verilmez. İçeriğin nasıl kullanılacağına dair karar ve sorumluluk tamamen size aittir.
 

İçindekiler

Ekip........................................................................................................... 2

Bilgilendirme Notu..................................................................................... 3

Önsöz....................................................................................................... 4

Tanımla..................................................................................................... 7

Yönetişim................................................................................................................. 7

Amaç.................................................................................................................... 7

Faydalar................................................................................................................ 7

Temel Kavramlar.................................................................................................... 7

Süreç.................................................................................................................... 8

Sık Karşılaşılan Sorunlar.......................................................................................... 9

Ek Kaynaklar.......................................................................................................... 9

Risk Yönetimi......................................................................................................... 10

Amaç.................................................................................................................. 10

Faydalar.............................................................................................................. 10

Temel Kavramlar.................................................................................................. 10

Süreç.................................................................................................................. 11

Sık Karşılaşılan Sorunlar................................................................................. 12

Ek Kaynaklar.................................................................................................... 13

Tüketici Etkileşimi................................................................................................. 13

Amaç.................................................................................................................. 13

Faydalar.............................................................................................................. 13

Temel Kavramlar.................................................................................................. 13

Süreç.................................................................................................................. 14

Sık Karşılaşılan Sorunlar................................................................................. 15

Ek Kaynaklar.................................................................................................... 16

Oluşturma............................................................................................... 17

Hizmetin Hayata Geçirilmesi.................................................................................. 17

Hizmet Tasarımı..................................................................................................... 18

Kullanım Koşulları................................................................................................ 18

İhtiyaç Analizi....................................................................................................... 18

Geliştirme mi, Satın Alma mı? (Build or Buy)............................................................ 19

Birden Fazla Hizmet Sağlayıcının Dahil Olduğu Hizmetler.......................................... 19

Hizmet İzleme...................................................................................................... 20

Service Aggregation.............................................................................................. 20

Değişiklik Yönetimi................................................................................................ 20

Amaç.................................................................................................................. 20

Faydalar.............................................................................................................. 20

Temel Kavramlar.................................................................................................. 21

Süreç.................................................................................................................. 21

Sık Karşılaşılan Sorunlar........................................................................................ 23

Sürüm ve Dağıtım Yönetimi................................................................................... 23

Amaç.................................................................................................................. 24

Faydalar.............................................................................................................. 24

Temel Kavramlar.................................................................................................. 24

Süreç.................................................................................................................. 25

Sık Karşılaşılan Sorunlar........................................................................................ 25

Sun......................................................................................................... 26

Koruma - Bilgi Güvenliği........................................................................................ 26

Amaç.................................................................................................................. 26

Süreç.................................................................................................................. 26

Erişim Kontrolü.................................................................................................... 27

Ölçme..................................................................................................................... 28

Amaç.................................................................................................................. 28

Faydalar.............................................................................................................. 28

Temel Kavramlar.................................................................................................. 28

Süreç.................................................................................................................. 28

Sık Karşılaşılan Sorunlar................................................................................. 29

İyileştirme.............................................................................................................. 29

Amaç.................................................................................................................. 29

Süreç.................................................................................................................. 29

Yanıtla..................................................................................................... 31

Hizmet Masası....................................................................................................... 31

Amaç.................................................................................................................. 31

Faydalar........................................................................................................... 32

Süreç.................................................................................................................. 32

Sık Karşılaşılan Sorunlar........................................................................................ 32

Performansın Ölçülmesi....................................................................................... 34

Kullanıcı Taleplerinin Çözümü.............................................................................. 34

Yanıt Süreci............................................................................................................ 35

Amaç.................................................................................................................. 35

Temel Kavramlar.................................................................................................. 35

Süreç.................................................................................................................. 37

Sık Karşılaşılan Sorunlar................................................................................. 40

Tanımla

Tanımla aşaması, bir hizmetin tasarımını kapsar ve yönetişim ile risk yönetimi gibi temel organizasyonel süreçleri içerir. Bu aşamada, hizmet yaşam döngüsünü destekleyen bir yönetim sisteminin temelleri atılır.

Yönetişim

Amaç

Yönetişim, organizasyona yön, politika ve genel işleyişe dair gözetim yoluyla rehberlik sağlayan bir fonksiyondur. Organizasyonun kârlılık, müşteri ve çalışan deneyimi, yürürlükteki yasa ve düzenlemelere uyum gibi iş hedefleri doğrultusunda hareket etmesini sağlar.

ISO 37000 (Governance of Organizations - Kuruluşların Yönetişimi ) ve ISO/IEC 38500 (Governance of IT for the organization - Bilgi Teknolojileri Yönetişimi) gibi standartlara göre, organizasyonda bu fonksiyonları yerine getiren ana grup, "yönetişim organı" olarak adlandırılan  bir yönetim kurulu veya organizasyonun üst kademesindeki nispeten bağımsız bir kişi veya gruptur. Ancak, pratikte yönetişim, yalnızca üst yönetimin değil, organizasyonun her seviyesindeki yöneticilerin kendi sorumluluk alanlarında yerine getirmesi gereken bir sorumluluktur.

Faydalar

İyi yönetişim, hizmet sağlayıcılar da dahil olmak üzere her organizasyonun etkin bir şekilde yönetilmesi için kritik bir unsurdur. Sağladığı başlıca faydalar şunlardır:

• Organizasyonun genel performansının daha iyi izlenmesi ve değerlendirilmesi;

• Operasyonel ve stratejik performans açısından tüm seviyelerde hesap verebilirlik sağlanması;

• Organizasyonun iş yönelimi ve hedefleri konusunda netlik kazanılması,

• Çalışanların, gerçekleştirdikleri faaliyetlerin organizasyonun genel amacıyla olan bağlantısını daha iyi kavraması;

• İlgili bilgilerin izlenmesine dayalı olarak daha bilinçli ve etkili kararlar alınması.

Temel Kavramlar

İyi yönetişim, her organizasyonun kendi yapısına göre belirleyebileceği ancak genellikle aşağıdakilerle örtüşen bazı temel ilkeler üzerine inşa edilir:

• Organizasyonun varoluş amacı,

• Organizasyon ve tüketicileri için değer yaratılması,

• Organizasyon stratejisinin oluşturulması,

• Organizasyon faaliyetlerinin ve gözetimi,

• Tüketiciler, çalışanlar ve otoriteler gibi paydaşlarla etkileşim kurulması,

• Risk yönetimi, 

• Sürdürülebilirliğe odaklanılması.

Süreç

Yukarıda belirtilen ilkeler ve bunlara eklenebilecek diğer unsurlar, yönetişim fonksiyonunun oluşturulması için başlangıç noktasıdır. Bu ilkeler doğrultusunda gerçekleştirilebilecek temel uygulamalar şunlardır:

• Organizasyonun misyon ve vizyonunun belirlenmesi: Organizasyon neyi başarmayı hedefliyor? Bu hedeflere nasıl ulaşmayı planlıyor?

• Organizasyonun faaliyetlerini etkileyen iç ve dış faktörlerin belirlenmesi: Tüketici gereksinimleri, mevzuat ve düzenlemeler, sürdürülebilirlik hedefleri, mevcut kaynakların durumu ve organizasyonun güçlü ve zayıf yönleri gibi unsurlar değerlendirilmelidir.

• Organizasyonun paydaşlarının belirlenmesi: Bu paydaşlar arasında organizasyonun kendi çalışanları ve yöneticileri olduğu gibi, tüketiciler, düzenleyici kurumlar, medya veya hissedarlar da yer alabilir.

• Determine the mission and vision of the organization: what is it that the organization wants to achieve? How do you want to do this?

ISO/IEC 38500:2024, yönetişim fonksiyonunun yerine getirilmesi için uygulanabilecek temel faaliyetleri açıklayan basit bir model sunar. EDMS olarak kısaltılan bu model:

• Değerlendirme (Evaluate): Bölüm 1.2’de belirtilen prensipler doğrultusunda organizasyonun mevcut durumu ve performansının değerlendirilmesi.

• Yönlendirme (Direct): Değerlendirme sonuçlarına göre, gerekli görülmesi hâlinde organizasyonun faaliyetlerinde değişiklik yapılması için  stratejik yönlendirmelerde bulunulması.

• İzleme (Monitor): Organizasyonun performansının, KPI’lar (Temel Performans Göstergeleri), KRI’lar (Temel Risk Göstergeleri) veya diğer uygun göstergeler aracılığıyla izlenmesi.

• Paydaş Katılımı (Stakeholder Engagement): Yönetişim fonksiyonunun hedef ve beklentilerinin, ilgili iç ve dış paydaşlarla etkili biçimde paylaşılması; böylece organizasyonun operasyonel düzeyde nasıl hareket etmesi gerektiğine dair ortak anlayış oluşturulması.

Bu dört faaliyet, organizasyondaki tüm yönetim kademeleri için sorumluluk alanlarının bir parçası olarak kolaylıkla uygulanabilir. Merkezi bir yönetişim fonksiyonu (örneğin bir yönetim kurulu), bu dört faaliyeti organizasyon genelinde yerine getirmelidir; böylece alt düzey yöneticiler, stratejik kararların operasyonlara nasıl yansıtılacağı konusunda gerekli rehberliği almış olurlar.

Ancak bu süreç yalnızca üst yönetimle sınırlı değildir. Bir ekip lideri de kendi düzeyinde aynı döngüyü uygulamalıdır: ekibinin performansını değerlendirmeli, hedeflere ulaşmak için rehberlik etmeli, belirlenen metrikler doğrultusunda süreci izlemeli ve ekibe, hedefler ile performans konusunda düzenli bilgi vermelidir.

Bu nedenle, organizasyondaki yöneticiler aslında iki farklı “şapka” taşırlar: Bir yandan, organizasyonun üst kademelerinden gelen (yönetişim temelli) yönlendirmeleri uygulamaya geçirmekle yükümlüdürler. Diğer yandan ise, kendilerine bağlı ekip ya da birimlere yönelik olarak yönetişim doğrultusunda yön vermeleri beklenir.

Yönetişim (EDMS faaliyetleri) ile yönetim (yönetişimden gelen kararların operasyonel uygulamaya dönüştürülmesi) arasındaki bu ayrım zaman zaman abartılı şekilde ele alınsa da, gerçekte organizasyondaki her yönetim kademesi için bu iki unsur birbiriyle bütünleşik bir yapı oluşturur.

Uygulamada yöneticilerin bir üçüncü “şapkası” daha vardır: yukarıya raporlama sorumluluğu. Bu, yönetişimin “izleme” işleviyle bağlantılıdır. Yöneticiler performansa dair verileri üst yönetime aktararak, onların organizasyonun alt katmanlarını değerlendirmesine ve gerekirse yeni bir yön belirlemesine olanak sağlar.

Sık Karşılaşılan Sorunlar

Yönetişimle ilgili dikkat edilmesi gereken temel noktalar şunlardır:

• Yönetişim, hükümet yönetimi ile karıştırılmamalıdır. Hükümet, toplumun belirli kesimlerini yönetmek ve siyasi yön belirlemek için var olan politik bir yapıdır. Yönetişim ise benzer faaliyetleri içerse de, bir şirketin veya organizasyonun farklı seviyelerinde işleyen bir fonksiyondur ve herhangi bir siyasi amaç barındırmaz.

• Yönetişim yalnızca organizasyonun en üst seviyesindeki yönetim kurulu ile sınırlı değildir. Gerçekte yönetişim, organizasyonun her seviyesinde uygulanmalıdır.

• Yönetişim ve yönetim faaliyetleri birbirine karışmamalıdır. Stratejik yönetişim faaliyetleri (Değerlendirme, Yönlendirme, İzleme, Paydaş Katılımı) ile yönetimin, yönetişimden gelen kararları operasyona dönüştürme süreci arasında net bir ayrım olmalıdır.

• Yönetişim, yalnızca paydaşlar arasında belirli aralıklarla yapılan toplantılar olarak algılanmamalıdır. Yönetişimin, yukarıda açıklanan net hedefleri ve faaliyetleri vardır. Elbette yönetişim süreçleri toplantılar gerektirebilir, ancak bu toplantıların amacının ve katılımcılar üzerindeki sorumluluklarının açık olması gerekir.

Ek Kaynaklar

Yönetişim sürecinin girdileri ve çıktıları hakkında daha fazla bilgi için ITSM.express web sitesine göz atabilirsiniz.

Risk Yönetimi

Amaç

Risk, bir organizasyonun hedeflerini etkileyebilecek her türlü belirsizlik olarak tanımlanır. Bu belirsizlikler hem olumlu hem de olumsuz yönde olabilir. Olumlu riskler, hedeflerin gerçekleştirilmesini kolaylaştırabilecek potansiyel durumları ifade eder ve bu nedenle genellikle "fırsat" olarak değerlendirilir. Organizasyonlar, bu fırsatları stratejik olarak değerlendirmeyi tercih edebilir. Öte yandan, olumsuz riskler, kelimenin günlük kullanımda çağrıştırdığı gibi, çoğu zaman doğrudan tehdit olarak algılanır; bu tür riskler, hedeflere ulaşma sürecini zorlaştırdığı için önlenmesi ya da etkisinin en aza indirilmesi gereken unsurlardır.

Her iki risk türü de etkili bir risk yönetimi anlayışının kapsamına girer. Riskler, organizasyon genelinde yürütülen yönetişim faaliyetleri için temel girdilerden biridir. Bu nedenle, risk yönetimi yalnızca üst düzey stratejik kararlarla sınırlı kalmamalı, organizasyonun tüm seviyelerinde aktif olarak yürütülmelidir. Ayrıca risk yönetimi; bilgi güvenliği, kapasite yönetimi ve diğer birçok hizmet yönetimi süreciyle doğrudan ilişkilidir ve bu alanların ayrılmaz bir parçasıdır.

Bu bölümde ele alınan yapı, risk yönetimi alanında genel kabul görmüş standart olan ISO 31000 (Risk Yönetimi) ile uyumludur.

Faydalar

Yönetişimde olduğu gibi, risk yönetimi de bir organizasyonun sürdürülebilir ve dengeli bir şekilde çalışabilmesi için temel fonksiyonlardan biridir. Etkili bir risk yönetimi süreci aşağıdaki faydaları sağlar:

• Olası tehditler ve zafiyetlere karşı erken uyarı sistemi geliştirir.

• Risklerin gerçekleşmesi durumunda, etkili kontrol mekanizmalarıyla zamanında müdahale edilmesini mümkün kılar.

• Organizasyonun karşı karşıya olduğu risk ortamına dair şeffaf ve bütüncül bir bakış sunar.

• Organizasyon genelinde, iş hedeflerine ulaşılmasını engelleyebilecek unsurlar hakkında kolektif farkındalık oluşturur.
  
   

Temel Kavramlar

Riskler, organizasyonu çeşitli şekillerde etkileyebilecek olaylar veya durumlar olarak tanımlanır. Bunlar; kurumun ya da müşterilerinin bilgilerini korumaya yönelik bilgi güvenliği riskleri, organizasyonun operasyonel performansını tehdit eden riskler (örneğin KPI hedeflerinin karşılanamaması), gizlilik yasaları gibi dış düzenlemelere uyumsuzluktan kaynaklanan uyum riskleri ya da dış tedarikçilere bağlı olarak ortaya çıkabilecek üçüncü taraf riskleri olabilir. Risk yönetimi kapsamında her türden olasılık dikkate alınabilir; ancak asıl önemli olan, bu risklerin etkili şekilde değerlendirilmesidir.

Riskler genellikle iki temel unsur üzerinden değerlendirilir: riskin gerçekleşme olasılığı ve gerçekleşmesi hâlinde organizasyon üzerindeki etkisi. Bu unsurlar çoğunlukla 1 (çok düşük) ile 5 (çok yüksek) arasında derecelendirilen sayısal ölçekler kullanılarak ölçülür. Olasılık ve etki değerleri belirlendikten sonra risk düzeyi aşağıdaki formül ile hesaplanır:

Risk Düzeyi = Olasılık x Etki

Elde edilen bu değer, risk seviyesinin belirlenmesi için temel bir gösterge sunar.

Süreç

ISO 31000 standardına göre tanımlanan risk yönetimi süreci farklı aşamaları içerirve aşağıdaki üç temel adımdan oluşur:

• Risklerin Tanımlanması: Risk yönetimi sürecinin kapsamı, organizasyonun bağlamı ve kabul edilebilir risk düzeylerine ilişkin kriterler dikkate alınarak potansiyel riskler belirlenir. Bu aşamada amaç, organizasyon içindeki zafiyetleri etkileyebilecek tehditlerin tespit edilmesidir.

• Risk Analizi: Bir önceki adımda tanımlanan tehditler ve zafiyetler, bu alanda yetkin kişiler tarafından analiz edilir. Bu kişiler, riskin gerçekleşmesi durumunda doğurabileceği potansiyel etkiyi ve gerçekleşme olasılığını değerlendirir. Bu analiz sonucunda, yukarıda belirtilen risk düzeyi hesaplanır.

• Riskin Değerlendirilmesi: Hesaplanan risk düzeyine dayanarak, hangi aksiyonların alınması gerektiğine karar verilir.

Bir riskle nasıl başa çıkılacağı, büyük ölçüde o riskin niteliğine bağlıdır. Ancak uygulamada bu yaklaşımlar genellikle dört ana başlık altında toplanır:

1. Riski Azaltmak: Bu yaklaşımda, riskin gerçekleşme olasılığını, etkisini veya her ikisini birden azaltmaya yönelik bir aksiyon alınır. Uygulanan bu aksiyonlar, kontrol mekanizması olarak adlandırılır. Bu kontroller: idari (ör: yeni bir süreç veya politika yazmak/uygulamak), teknik (ör: güvenlik duvarı(firewall) kurmak) veya fiziksel (ör: kapılara kilit takmak) olarak uygulanabilir      ve riskin etkisini ya da gerçekleşme ihtimalini düşürmeyi hedefler.
2. Riski Kabul Etmek: Bazı durumlarda, riskin düzeyi onu azaltmak için zaman veya kaynak harcamayı gerektirmeyecek kadar düşük olabilir. Bu durumda risk, olduğu gibi kabul edilir. Ancak bu karar dikkatle ele alınmalıdır; yalnızca ilgili yönetim kademesi, kendi sorumluluk alanı dahilindeki belirli bir seviyeye kadar olan riskleri kabul etme yetkisine sahip olmalıdır. Örneğin, organizasyon içinde “Orta” seviyeye kadar olan risklerin, ilgili birimin yöneticisi tarafından onaylanması koşuluyla kabul edilebileceğine dair bir politika belirlenmiş olabilir. Bu kabul edilebilir eşik, organizasyonun risk iştahı olarak tanımlanır.
3. Riski Devretmek: Eğer riskin yönetimi, organizasyon içindeki başka bir ekibin, farklı bir birimin veya dış bir paydaşın sorumluluğunda ise, bu risk ilgili tarafa devredilebilir. Bu süreç; riskin karşı tarafa açık şekilde iletilmesini, yapılan değerlendirmenin paylaşılmasını ve riskin yönetimiyle ilgili sorumluluğun karşı tarafça benimsenmesini içerir. Karşı taraf, riskin azaltılması yönünde bir aksiyon alıp almayacağına kendisi karar verebilir; ancak risk gerçekleşirse, oluşacak etkiden de sorumlu olacaktır. Örneğin, yetkisiz personelin bir veri merkezine erişim sağlayabileceği yönünde bir risk tespit edilirse, bu risk fiziksel güvenlikten sorumlu birime devredilebilir. İlgili birim, riski sahiplenmeli ve gerekli önlemleri alıp almayacağına karar vermelidir.
4. Riski Üstlenmek: Pozitif riskler (fırsatlar) söz konusu olduğunda, organizasyon bu risklerin gerçekleşmesini teşvik etmeyi tercih edebilir. Bu, riskin gerçekleşmesiyle birlikte doğabilecek olumlu etkinin bilinçli olarak hedeflenmesi anlamına gelir. Örneğin, enerji fiyatlarında veya vergi düzenlemelerinde beklenen olumlu değişiklikler, hizmet maliyetlerini düşürebilir ve organizasyonun pazardaki konumunu güçlendirebilir. Bu gibi durumlarda, söz konusu fırsatların gerçekleşmesi yönünde proaktif bir tutum benimsenebilir.

Bir risk için önlem alındığında, yani belirli bir kontrol mekanizması uygulandığında, riskin gerçekleşme olasılığı ve/veya etkisinin, ilk duruma kıyasla daha düşük olması beklenir. Bu durumda, Olasılık x Etki formülü kullanılarak, artık risk olarak adlandırılan yeni bir risk seviyesi hesaplanır. Artık risk, uygulanan kontroller sonrasında geriye kalan riski ifade eder. Kontroller genellikle risk seviyesini yalnızca belirli bir noktaya kadar azaltabilir; riski tamamen ortadan kaldırmaz. Bu nedenle, artık risk; alınan önlemlere rağmen, riskin hangi düzeyde varlığını sürdürdüğünü gösteren kritik bir göstergedir. Artık risk seviyesi, organizasyonun kabul edilebilir risk düzeyinin (risk iştahı) altında olmalıdır. Eğer hâlâ bu seviyenin üzerinde ise, riski daha da azaltmak için ek kontrol önlemleri uygulanması gerekebilir.

Sık Karşılaşılan Sorunlar

Risk yönetimiyle ilgili dikkat edilmesi gereken temel noktalar şunlardır:

• Risk yönetiminin göz ardı edilmesi. Birçok organizasyonda risk yönetimi ya hiç uygulanmamakta ya da gereğinden fazla karmaşık bir şekilde yapılandırılmaktadır. Oysa bunun yerine, basit ve uygulanabilir bir risk yönetim çerçevesi oluşturarak bu süreci organizasyonun günlük işleyişinin doğal bir parçası haline getirmek mümkündür.

• Risklerin gereksiz yere kabul edilmesi. Bazı risk sahipleri, riskleri analiz edip uygun kontrol önlemleri almak yerine, doğrudan kabule gitmeyi tercih eder. Bu yaklaşım, organizasyonun iş sonuçlarını riske atan ihmalkâr bir tutumdur.

• Kontrollerin etkinliğinin düzenli olarak gözden geçirilmemesi. Bir risk için kontrol uygulandığında, bu kontrolün etkinliği zaman içinde azalma gösterebilir. Tehditler değişebilir, zayıflayabilir ya da yeni biçimlerde ortaya çıkabilir. Bu nedenle kontrollerin düzenli aralıklarla değerlendirilmesi ve gerektiğinde güçlendirilmesi veya alternatiflerle değiştirilmesi gerekir.
  Riski bildirenin otomatik olarak risk sahibi sayılması. Riskin sahipliğinin, onu en iyi şekilde yönetebilecek kişide olması gerekir, bu kişi riski bildiren kişiden farklı biri olabilir. Organizasyonda “riski kim bildirirse o sahiplenir” anlayışı benimsenirse, çalışanlar riskleri bildirmekten kaçınabilir.

Ek Kaynaklar

Risk yönetimi kavramları ve uygulamaları hakkında daha fazla bilgi için ITSM.express web sitesine göz atabilirsiniz.

Tüketici Etkileşimi

Amaç

Bir hizmetin geliştirilmesinin temel amacı, nihai kullanıcılar ya da tüketiciler tarafından kullanılmasını sağlamaktır. Tüketicilerle herhangi bir etkileşim kurulmadan da bir hizmet geliştirilebilir, ancak bu durumda ortaya çıkan hizmet, onların ihtiyaçlarına hitap etmeyebilir ve dolayısıyla kullanılmaz hâle gelebilir. Tüketici etkileşimi, hizmetin geliştirme sürecinin en başından, hizmetin sonlandırılmasına kadar olan tüm yaşam döngüsü boyunca gerçekleştirilmelidir.

Faydalar

Tüketiciyle etkileşim sürecinin sağladığı başlıca faydalar şunlardır:

• Tüketicilerin, kendi iş hedeflerine ulaşabilmek için hizmetten ne beklediklerinin daha iyi anlaşılmasına katkıda bulunur.

• Tüketici deneyimi ve memnuniyetinin düzenli olarak değerlendirilmesini mümkün kılar; böylece hizmetin gerektiğinde iyileştirilmesine olanak tanır.

• Hizmetin performansına ilişkin düzenli raporlamalar yapılmasına imkân tanır; böylece tüketiciler, hizmetin beklentileri karşılayıp karşılamadığını takip edebilir.

• Hizmetin geliştirilmesine rehberlik sağlar; böylece hizmetin, gerçek tüketici ihtiyaçlarıyla daha uyumlu hale gelmesine destek olur.

Temel Kavramlar

Tüketiciler, çoğunlukla bir hizmetin kendisiyle değil, o hizmetin kendi hedeflerine ulaşma sürecinde sağladığı katkıyla ilgilenir. Bir başka ifadeyle, hizmeti doğrudan kullanmaktan ziyade, hizmet aracılığıyla elde edecekleri sonuçlar tüketicinin esas motivasyon kaynağıdır. Tüketici hizmeti kullanarak bir değer elde eder; ancak bu değer, hizmet sağlayıcısının elde ettiği değerle örtüşmek zorunda değildir. Hizmet sağlayıcısı için değer; gelir artışı, müşteri memnuniyeti, pazar payı kazanımı veya daha üst düzey kurumsal hedeflerin desteklenmesi şeklinde olabilir. Tüketici açısından ise hizmet; e-posta iletişimi kurmak, veri işlemek ya da finansal işlemleri yürütmek gibi kendi operasyonel ihtiyaçlarını karşılayan bir araç niteliğindedir.

Bir hizmetin mevcut ya da potansiyel tüketicileriyle etkileşime geçmenin ilk adımı, tüketicinin hizmetten hangi değeri beklediğini anlamaktır. Bu soru basit görünse de, hizmetin benimsenmesi ve etkin biçimde kullanılması açısından kritik bir rol oynar. Tüketici tarafından algılanan değer, hem hizmete yönelik gereksinimlerin belirlenmesini sağlar hem de kurulacak ilişkinin temelini oluşturur.

Süreç

Tüketici değerinin netleştirilmesinin ardından, sunulacak hizmete ilişkin gereksinimler bu değer doğrultusunda tanımlanmalıdır. Örneğin bir e-posta hizmeti kapsamında, kullanıcıların iş süreçlerini daha verimli yürütmeleri için ortak posta kutuları veya zamanlanmış gönderim gibi işlevler gerekli olacaktır. Finansal hizmetler bağlamında ise bordro yönetimi ya da muhasebe sistemleriyle entegrasyon gibi bileşenler, tüketicilerin operasyonel hedeflerine ulaşmasında kritik rol oynayacaktır.

Farklı tüketici gruplarının hizmetten beklentileri farklılaşabilir. Bu nedenle, hem mevcut hem de potansiyel gereksinimlerin sistematik biçimde toplanması; ardından bu gereksinimlerin, tüketicilerin çoğunluğu tarafından paylaşılan ve belirli bir zaman aralığında hayata geçirilebilecek nitelikte olanlara göre önceliklendirilmesi gerekmektedir.

Tüketicilerin büyük kısmı tarafından ifade edilen, yani ortak olan gereksinimler hizmetin temel işlevselliği kapsamında ele alınmalıdır. Bunun ötesindeki bazı talepler, hizmetin kapsamını genişleterek daha fazla kullanıcıya ek değer sunabilir; bu tür işlevler süreç başında “ileri seviye” ya da “premium” paket özellikleri olarak konumlandırılabilir veya yakın vadeli geliştirme planlarına dahil edilebilir.

Tamamen özelleştirme gerektiren talepler ise yalnızca tek bir tüketiciye ya da dar bir kullanıcı grubuna yönelik olabilir. Bu noktada, sınırlı sayıda kullanıcıya hizmet edecek bir işlevin geliştirilmesinin iş açısından anlamlı olup olmadığı değerlendirilmelidir. Organizasyonun, standartlaştırılmış hizmet sunumuna mı odaklanacağı yoksa kontrollü biçimde özelleştirme esnekliği mi sunacağı; stratejik öncelikler ve ölçeklenebilirlik hedefleri doğrultusunda belirlenmelidir.

Tüketicilerden gelen taleplerin yanı sıra, organizasyon içinden toplanan gereksinimler de hizmet geliştirme sürecine doğrudan katkı sağlar. Bu sürece, ilerleyen bölümlerde Oluşturma başlığı altında ayrıntılı olarak yer verilecektir.

Tüketici ilişkileri, yalnızca gereksinimlerin toplanması ya da hizmetin sunulması ile sınırlı değildir. Tüketicilerin, hizmet yaşam döngüsü boyunca sürece aktif şekilde katılımı sağlanmalıdır. Bu katılım, hizmet deneyimlerine ilişkin geri bildirim sunmalarını mümkün kılarak, sürekli iyileştirme için önemli bir veri kaynağı oluşturur.

Bu yaklaşım, Tüketici Deneyimi (CX) yönetimi olarak tanımlanır. Son kullanıcı düzeyinde ise, bu kavram Kullanıcı Deneyimi (UX) yönetimi olarak ele alınır. CX ve UX; kullanım kolaylığı, işlevsellik, hizmete erişim süreçleri, faturalama (varsa), destek hizmetleri, değişiklik talepleri, olay çözüm süreçleri ve kullanıcıya sağlanan iyileştirmeler dâhil olmak üzere, hizmete yönelik tüm algı ve etkileşimleri kapsar.

Tüketicinin hizmetle veya hizmet sağlayıcı organizasyonla kurduğu her temas noktası, belirli bir deneyim yaratır. Tüketici ilişkileri yönetiminin temel amacı, bu deneyimlerin ölçümlenmesi, analiz edilmesi ve gerektiğinde iyileştirilmesidir.

Tüketici ihtiyaçları merkeze alınırken, çalışan deneyimi de göz ardı edilmemelidir. Başarılı hizmet sunumunun temelinde, çalışanların motivasyonu ve memnuniyeti yer alır. Süreçleri yürüten, hizmeti sağlayan ve kullanıcıya destek sunan bireylerin görevlerini memnuniyetle yerine getirmesi, genel hizmet kalitesi açısından kritik bir faktördür. Çalışan deneyimi, tıpkı müşteri deneyiminde olduğu gibi; düzenli anketler, bireysel görüşmeler veya ekip bazlı geri bildirim oturumları aracılığıyla ölçülebilir. Elde edilen bulgular, Sürekli İyileştirme sürecine entegre edilmeli ve gerekli durumlarda hizmet üzerinde anlamlı değişiklikler yapılmasına temel oluşturmalıdır.

Tüketici etkileşiminin bir diğer temel gereksinimi, sunulan hizmete ilişkin düzenli raporlama yapılmasıdır. Bu raporlamalar farklı biçimlerde sunulabilse de, çoğu zaman tüketiciyle üzerinde anlaşmaya varılmış hizmet hedeflerine dayanır. Bu hedefler genellikle aşağıdaki alanları kapsar:

• Hizmet talepleri, olaylar ve değişiklik isteklerine verilen yanıt süreleri

• Hizmetin kullanılabilirliği

• Hizmet performansı

• Hizmetin güvenilirliği

• Tüketici deneyimi (kullanım kolaylığı, etkin destek, amaca uygunluk vb.)

• Hizmetin tutarlılığı ve benzeri metrikler
  
   

Bu hedefler, standart sözleşmelere entegre edilebileceği gibi, belirli tüketiciler için özelleştirilmiş biçimde de tanımlanabilir. Her iki durumda da bu hedefler, bir Hizmet Seviyesi Anlaşması (SLA) çerçevesinde tanımlanır. Eğer odak, kullanıcı deneyimi üzerinde ise, bu anlaşma bir Deneyim Seviyesi Anlaşması (XLA) ile desteklenebilir.

Sık Karşılaşılan Sorunlar

Tüketici etkileşimiyle ilgili dikkat edilmesi gereken temel noktalar şunlardır:

• Tek tip hizmet yaklaşımı. Tüm tüketicilerin, kendi özgül ihtiyaçlarından bağımsız olarak hizmetten eşit düzeyde memnuniyet duyacağı varsayılmaktadır. Oysa gerçekte, her tüketicinin hizmetten beklentisi farklıdır. Bu nedenle, hizmetin bireysel ihtiyaçlara uyum sağlayacak şekilde yapılandırılması gerekebilir.

• Tüketiciyle etkileşim sıklığının standart olması. Tüketiciyle kurulacak etkileşimin sıklığı, tüketici tipine göre değişkenlik göstermektedir. Bazı tüketiciler aylık raporlama tercih ederken, bazıları yıllık performans değerlendirmesini yeterli bulabilir. Etkileşim sıklığının, ilgili tüketici grubunun ihtiyaçlarına göre uyarlanması gereklidir.

• Etkileşim biçiminin tüm tüketiciler için standart olması. Tıpkı sıklıkta olduğu gibi, etkileşim biçimi de farklı tüketici profillerine göre farklılaşmalıdır. Tüketici etkileşiminin içeriği ve sunum şekli, belirli ihtiyaç ve beklentiler doğrultusunda özelleştirilmelidir.

• Organizasyon içinde tanımlanan hedeflerin, tüketicilere sunulan SLA’larla uyumlu olmaması. Bu, uygulamada oldukça sık karşılaşılan bir sorundur. Hizmeti destekleyen ekiplerin kullandığı temel performans göstergeleri (KPI'lar), tüketicilerle üzerinde mutabık kalınan hizmet seviyesi hedefleriyle örtüşmeyebilir. Örneğin, organizasyon içi süreçlerde tanımlanmış bir yanıt süresi hedefi, tüketiciye verilen SLA taahhütlerinin karşılanmasını engelleyebilir. Bu nedenle, iç ve dış hedeflerin birbirine uyumlu hâle getirilmesi; ayrıca hizmet ekiplerinin hem kendi KPI’ları hem de SLA yükümlülükleri konusunda yeterli farkındalığa sahip olması kritiktir.

Ek Kaynaklar

Tüketici etkileşimi, deneyim ölçümü ve raporlama süreçleri hakkında daha fazla bilgi için ITSM.express web sitesine göz atabilirsiniz.

Oluşturma

Hizmet yönetiminin bu aşaması, hizmetin oluşturulması, uygulanması ve test edilmesi süreçlerini kapsar. Bu aşamada; hizmet, son kullanıcılarla buluşmadan önce canlı ortamda sunulmaya hazır hâle getirilir ve bu süreç değişiklik yönetimi ile sürüm yönetimi gibi kontrol süreçleriyle yönetilir.

Bir hizmet, müşterilerin tanımlanmış ihtiyaçlarını karşılayarak onlara değer sunmanın bir yoludur. Bu nedenle, hizmet çoğu zaman somut olmayan (soyut) bir yapıya sahiptir. Ancak bazı durumlarda, somut bir ürünle birlikte de sunulabilir.

Hizmetin Hayata Geçirilmesi

Bir hizmetin sunulabilmesi için öncelikle hayata geçirilmesi gerekir. Bu süreç; hizmetin tüm bileşenlerinin geliştirilmesi ve bir araya getirilmesi, hizmeti destekleyecek organizasyonel yapının hazırlanması ve hizmetin daha önce yapılan hizmet tasarımına uygun biçimde inşa edilmesini kapsar. Bu süreç, ideal olarak hizmet sağlayıcı ile tüketici arasında iş birliği içinde gerçekleştirilmelidir. Böylece her iki taraf da hizmetten en yüksek değeri elde edebilir. Ancak hizmetin sağlayıcıya ve tüketiciye sağladığı değer birbirinden çok farklı olabilir; bu nedenle, hizmet oluşturulurken her iki tarafın beklentileri ve hedefleri de dikkate alınmalıdır. Tüketici açısından değer; örneğin bir iş sürecinin kolaylaştırılması ve iş hedeflerinden birinin gerçekleştirilmesi olabilir. Hizmet sağlayıcı açısından ise bu değer; pazar payının artırılması veya korunması, müşteri memnuniyetinin artırılması ya da gelir elde edilmesi gibi çıktılarla ölçülebilir. Bir hizmetin özellikleri, doğrudan karşılamayı amaçladığı müşteri ihtiyaçlarına göre şekillendirilmelidir. Ancak bu tek başına yeterli değildir; aşağıdaki unsurlar da dikkate alınmalıdır:

• Organizasyonun yönetişim modeli ve stratejisi (Bu hizmeti gerçekten sunmalı mıyız?)

• Organizasyonun ve iş ortaklarının yetkinlikleri (Bu hizmeti sunabilecek kapasiteye sahip miyiz?)

• Onaylanmış kurumsal mimari ve kullanılan teknik mimari (Bu hizmeti etkili şekilde hayata geçirip sürdürülebilirliğini sağlayabilir miyiz?)
  
   

Müşteri ihtiyaçları değerlendirilirken, yalnızca işlevselliğin değil; aynı zamanda hizmetin güvenilirliği, sürekliliği, kapasitesi gibi garanti unsurlarının da dikkate alınması önemlidir. Ayrıca bu hizmetin portföye nasıl ekleneceği, nasıl sunulacağı ve sürdürebileceği de en başından planlanmalıdır.

Hizmet Tasarımı

Kullanım Koşulları

Hizmet sağlayıcılar, bir hizmetin garanti tasarımını doğru şekilde oluşturabilmek için hizmetlerin nasıl ve nerede kullanılacağını net bir şekilde anlamalıdır. 

Asgari düzeyde göz önünde bulundurulması gereken unsurlar şunlardır:

• Hizmet Talebi: Hizmetin sunulmasında kullanılan kaynaklar üzerinde oluşan yükü belirler. Kaç lokasyon, kaç kullanıcı, kaç işlem gibi farklı değişkenler üzerinden değerlendirilir. Bu bilgiler, yalnızca müşterilerin ihtiyaç duyduğu özelliklerin değil, aynı zamanda hizmetin gelecekte de değer sunabilecek kapasitede tasarlanması için mimari planlamaya dahil edilmelidir.

• Hizmet Erişilebilirliği: Müşterinin hizmeti hangi koşullarda kullanacağı ve hangi erişilebilirlik düzeyini kabul edilebilir bulacağı dikkate alınmalıdır. Hizmet ne zaman erişilebilir olmalı, nerelerde erişilebilir olmalı ve hangi durum “erişilebilir” kabul edilmelidir? Örneğin, yanıt süresinin çok yavaş olması, bazı kullanıcılar açısından hizmetin erişilemez olduğu şeklinde algılanabilir. Bu bağlamda, bilgisayarlı sistemlerde erişilebilirlik; zamanda işlem yanıt süresi ve sistemin kaldırabileceği işlem hacmiyle gibi unsurlarla da ilişkilidir.

• Hizmet Kapasitesi: Yukarıda belirtilen talep ve erişilebilirlik unsurları, hizmetin teknik altyapısına somut gereksinimler olarak yansıtılmalıdır. Özellikle bilgisayarlı sistemlerde bu; ağ bant genişliği, veritabanı hacmi ve okuma/yazma hızı, depolama kapasitesi ile işlem gücü (örneğin CPU ve bellek kapasitesi) gibi temel teknik bileşenler üzerinden tanımlanır.

İhtiyaç Analizi

Müşteri ihtiyaçlarının derinlemesine analiz edilmesi gerekir. Bu analiz, yalnızca müşteri taleplerini değil, aynı zamanda hizmetin rekabetçi bir ortamda müşterilere gerçekten sunulabilir olup olmadığını değerlendirmek amacıyla yapılmalıdır.

İhtiyaç analizi yalnızca müşterilerin beklediği özellikleri (yani hizmetin sağlaması gereken fayda unsurlarını) değil, aynı zamanda hizmetin kullanım koşullarını da içermeli, böylece hizmetin garanti bileşenleri netleştirilebilir. 

İhtiyaç analizinin açıkça tanımlanmış bir analiz yöntemine dayanması en doğru yaklaşımdır. Bu yöntem yalnızca müşteri veya kullanıcı görüşmeleri ile sınırlı kalmamalı; aynı zamanda iş süreçlerinin doğrudan gözlemlenmesini, benzer organizasyonların ihtiyaçlarının anlaşılmasını ve pazarda mevcut diğer çözümlerin (rekabet ortamının) değerlendirilmesini içermelidir.

Özgün ya da farklılaştırıcı bir değer önerisi sunmayan bir hizmetin tasarlanması ve geliştirilmesi, işletme yönetimi bakış açısıyla temellendirilmesi zor bir girişimdir. Bu nedenle organizasyonlar, müşterilere daha fazla ya da daha iyi değer sunmayı hedeflemelidir.

Hizmetin kullanıcılar tarafından nasıl ve nerede kullanılacağının anlaşılması, analiz sürecinin kritik bir parçasıdır. Bu bilgiler çoğu zaman uzmanlar tarafından teknik gereksinimlere dönüştürülerek hizmet tasarımına aktarılmalıdır.

Geliştirme mi, Satın Alma mı? (Build or Buy)

Hizmet tasarımı tamamlandıktan sonra, organizasyonların hizmetin tüm yönleriyle hayata geçirilebilmesi konusundaki yetkinliklerini eleştirel bir bakışla değerlendirmesi gerekir. Bu aşamada, hizmetin belirli bileşenlerinin sunulması için stratejik iş ortaklıklar kurulması sıkça başvurulan bir yaklaşımdır.

Mimari açıdan bakıldığında, organizasyonlar hizmet bileşenlerini oluştururken genellikle aşağıdaki üç yaklaşımdan birini tercih eder:

1. Tüm bileşenlerin organizasyon içinde sıfırdan geliştirilmesi,
2. Bazı bileşenlerin organizasyon içinde geliştirilip, kalan kısımların mevcut hazır bileşenlerle tamamlanması,
3. Standart bileşenlerin satın alınarak yalnızca yapılandırma (konfigürasyon) yoluyla, özelleştirilmiş bir çözüm hâline getirilmesi.

Bu seçeneklerin maliyetleri ciddi farklılıklar gösterebilir. Bu nedenle organizasyonlar, yalnızca teknik kapasitelerini değil; aynı zamanda kısa ve uzun vadeli maliyet-etkinliği değerlendirecek bir finansal çerçeve oluşturmalıdır.

Birden Fazla Hizmet Sağlayıcının Dahil Olduğu Hizmetler

Bir organizasyon, kendi hizmetini sunabilmek için başka sağlayıcılardan da hizmet alıyorsa, bu hizmetlerin zamanında ve beklendiği şekilde sunulmasını güvence altına almak, tasarım sürecinde göz önünde bulundurulması gereken temel kriterlerden biridir.

Hizmet seviyelerini belirleyen anlaşmalar yapılmalı; bu anlaşmaların nasıl yönetileceği, nasıl ölçüleceği ve hizmet kalitesi tehdit altına girdiğinde ne tür aksiyonlar alınacağı önceden netleştirilmelidir. Genellikle akla ilk gelen şey yasal yaptırımlar olur; ancak bu tür reaktif önlemler, yaşanan kaybın etkisini telafi etmez. Hizmet kalitesindeki düşüşlerin müşteriye yansımasını en aza indirmek için, tüm tarafların nasıl ve ne zaman devreye gireceği önceden planlanmalıdır.

Hizmet Entegrasyonu ve Yönetimi (SIAM) gibi yaklaşımlar, çoklu hizmet sağlayıcılarla yürütülen hizmetlerin çıktısına dair kapsamlı bir bakış açısı sunar.

Hizmet İzleme

Mümkünse, hizmet sağlayıcının hizmet kalitesindeki düşüşleri proaktif olarak fark edip aksiyon almasını sağlayacak izleme sistemleri, hizmet tasarımının bir parçası olarak kurgulanmalıdır.

Bu süreç hizmet izleme bölümünde daha ayrıntılı olarak ele alınacaktır.

Service Aggregation

Bazı durumlarda hizmet sağlayıcılar, müşteriye başka tedarikçiler tarafından sunulan hizmetleri de kendi hizmetleriyle birlikte yönetmek durumunda kalır. Bu senaryo, önceki bölümde bahsedilen hizmet bağımlılıklarından farklıdır. Burada, müşteri tarafından doğrudan sözleşmeye bağlanmış ve birbirinden bağımsız çalışan birden fazla hizmet sağlayıcıdan söz edilmektedir. Ancak bu ayrı hizmetlerin, genel hizmet performansı üzerinde kritik etkileri olabilir.

Bu tür durumlarda hizmet kesintisi veya performans düşüşü yaşandığında, sağlayıcılar çoğunlukla sorumluluğu birbirlerine atma eğilimindedir. Müşteri faydasına birlikte hareket etmek yerine, “suçlu” aramaya odaklanılır. Bu gibi dağınık yapılarda, tüm sağlayıcıları uçtan uca izleyen ve aralarındaki koordinasyonu sağlayan bağımsız bir rol tanımlanması müşteri açısından faydalı olabilir.

Hizmet Entegrasyonu ve Yönetimi (SIAM) yaklaşımı, bu tür senaryolarda da işbirliği ve bütüncül hizmet içgörüleri sağlamak için kullanılabilir.

Değişiklik Yönetimi

Amaç

Değişiklik yönetiminin amacı, üretim ortsamında uygulanan değişiklikleri kontrol altında tutmaktır. "Kontrol" kelimesi ilk bakışta kısıtlayıcı gibi görünse de, uygulamada her zaman bu şekilde algılanması gerekmez. Çoğu zaman hizmet iyileştirmelerinin hızlı ve esnek biçimde hayata geçirilmesi ile hizmetlerin kararlılığının korunması arasında bir denge kurmak gerekir. Değişiklik yönetiminin temel amacı da işte bu dengeyi sağlamaktır.

Faydalar

Etkili bir değişiklik yönetiminin sağladığı başlıca faydalar şunlardır:

• Değişiklikler devreye alındığında hizmetlerin tutarlı şekilde devam etmesi,

• Değişikliklerin uygulanmasında gecikmeyi en aza indirmek,

• Planlanan değişikliklerle ilgili tüm paydaşları zamanında bilgilendirmek,

• Hizmete en az etki eden değişiklik türlerinin daha kolay önceliklendirilmesini sağlamak.

Temel Kavramlar

Değişiklik yönetimi süreci, Değişiklik Talebi (Request for Change - RFC) ile başlar. Bu talep, son kullanıcı, geliştirme ekibi veya diğer paydaşlar tarafından mevcut hizmetlerde değişiklik yapılması amacıyla iletilir. RFC'ler, örneğin bir ağ arayüzünün hızının değiştirilmesi gibi küçük çaplı değişikliklerden, bir sunucunun donanımının yükseltilmesi gibi büyük ölçekli değişikliklere kadar geniş bir yelpazeye sahip olabilir.

Bir değişiklik yönetimi politikası oluşturularak, farklı türdeki değişikliklerin nasıl ele alınacağı tanımlanmalıdır:

• Büyük ve hizmeti doğrudan etkileyen değişiklikler, birden fazla paydaşın yer aldığı bir proje kapsamında ele alınabilir. Bu projelerde de, değişiklik yönetimi sürecinin gerektirdiği adımların takip edilmesi gerekir.

• Küçük değişiklikler, önceden onaylanarak gecikme olmadan uygulanabilir. Bu tür değişiklikler genellikle Talep karşılama sürecine yönlendirilir. Bu süreç, aslında değişiklik yönetiminin daha kısa bir versiyonudur ve Yanıtla adımında detaylı olarak işlenmektedir.

• Diğer tüm değişiklikler, standart değişiklik yönetimi sürecine tabi olmalıdır.

Acil değişiklik (Emergency change), genellikle bir olayın çözümü kapsamında gerçekleştirilen özel bir değişiklik kategorisidir. Bu tür değişiklikler, örneğin dağıtılmış hizmet reddi saldırısı (Distributed Denial of Service – DDoS, “servis dışı bırakma saldırısı” olarak da geçer) ya da hızla yamalanması gereken bir yazılım zafiyeti gibi kritik durumlarda, gecikmeksizin uygulanmalıdır.

Acil değişikliklerin nasıl yönetileceğine dair ayrı bir prosedür tanımlanmış olabilir. Bu prosedür, aciliyet gerektiren durumlarda standart değişiklik yönetimi sürecini geçici olarak devre dışı bırakarak değişikliğin hemen uygulanmasını sağlar. Ancak uygulama tamamlandıktan sonra, gerçekleştirilen işlemlerin belgelenmesi ve standart sürecin kalan adımlarının geriye dönük olarak tamamlanması gerekir.

Yukarıda anlatıldığı gibi, standart bir değişiklik yönetimi süreci tüm değişiklik türlerini kapsayabilir.

Süreç

Hizmet sağlayıcı bir değişiklik talebi (Request for change - RFC) aldığında, kaydın oluşturulmasının ardından ilk adım detaylı ön değerlendirme (triyaj) sürecidir. Bu aşamada, değişikliğin niteliği değerlendirilir ve olası etkileri analiz edilir. Ön değerlendirme sonucuna göre RFC, standart değişiklik yönetimi sürecine, talep karşılama sürecine veya bir proje yönetimi sürecine yönlendirilebilir.

RFC standart değişiklik yönetimi sürecine alındıysa, ilgili ekip tarafından geçerliliği değerlendirilmeli ve uygulanabilirliği gözden geçirilmelidir. Gerekirse talebi oluşturan kişiyle iletişime geçilerek detaylar netleştirilmeli ve değişikliğin devreye alınabileceği zaman aralığı üzerinde uzlaşılmalıdır. Ayrıca, değişiklik başarısız olursa geri alınabilmesini sağlamak amacıyla bir geri alma planı (rollback/back-out plan) da hazırlanmalıdır.

Büyük ve karmaşık ortamlarda, gelen tüm RFC’lerin bir arada değerlendirildiği ve olası çakışmaların önceden tespit edilerek ayrı zamanlarda devreye alınmasının sağlandığı ayrı bir yapı bulunabilir. Bu yapı, adından da anlaşılacağı üzere Değişiklik Danışma Kurulu (Change Advisory Board – CAB) olarak adlandırılır ve RFC’lerin nasıl ele alınması gerektiği konusunda yönlendirme sağlar. Ancak CAB’ın sürece dahil olması, dağıtımın gereksiz yere gecikmesine yol açmamalı; yalnızca hizmetin istikrarını sağlamak ve değişiklik kaynaklı olayları önlemek amacıyla destekleyici bir rol üstlenmelidir.

Bir değişikliğin onaylanması, değişikliğin niteliği ve canlı hizmetler üzerindeki etkisi konusunda en fazla bilgiye sahip ekip tarafından yapılmalıdır. Bu nedenle, onay süreci organizasyon içinde değişiklik talebini onaylama yetkisine sahip en alt düzeydeki birim tarafından yürütülmelidir.

İlgili RFC, onaylandıktan ve zamanlaması belirlendikten sonra, bir sonraki bölümde detaylı şekilde ele alınan Sürüm ve Dağıtım Yönetimi sürecine aktarılır.

Tam otomasyona dayalı ortamlarda, örneğin DevOps tabanlı geliştirme süreçlerinde, değişiklik ön değerlendirmesi, değerlendirme ve onay adımları için doğru kriterler önceden tanımlanmışsa, yukarıda belirtilen tüm adımlar otomatikleştirilebilir. Bu sayede, değişikliklerin uygulanmasında yaşanabilecek gecikmeler minimuma indirgenmiş olur.

Sık Karşılaşılan Sorunlar

There has been a lot of criticism on change management processes as implemented by various organizations, usually quoting unacceptable delays in getting RFCs deployed. The following pitfalls are at the core if this:

Değişiklik yönetimi süreçleri, birçok organizasyon tarafından uygulandığı şekliyle yoğun eleştiriye maruz kalmıştır. Bu eleştirilerin çoğu, RFC’lerin devreye alınmasında yaşanan kabul edilemez gecikmeleri gerekçe göstermektedir. Aşağıdaki yaygın hatalar bu durumun temelinde yer alır:

• Tüm değişikliklerin CAB’den geçmesi gerektiği varsayımı. Bu yaklaşım, özellikle düşük etkili değişiklikler için gereksiz yere gecikmelere yol açar. CAB yalnızca, farklı RFC’ler arasında çakışma riski bulunan karmaşık ortamlarda kullanılmalı ve düzenli aralıklarla toplanmalıdır.

• Bir değişikliğin devreye alınabilmesi için çok sayıda onay alınması gerektiği varsayımı. İlgili paydaşlar bilgilendirildiği sürece, bir değişiklik için esasen yalnızca tek bir onay yeterlidir: değişikliği uygulayacak ekipten alınacak onay. Gereksiz onay ihtiyacını azaltmak için, basit değişikliklerin ayrı bir onay sürecine ihtiyaç duyulmadan uygulanıp uygulanamayacağı da değerlendirilmelidir. Bu yaklaşıma, ilave onay gerektirmeden uygulanabilen “standart değişiklikler” denir.

• Çevik (Agile) ve DevOps ortamlarında, kullanıcılar tarafından beklenen yüksek dağıtım hızı nedeniyle değişiklik yönetimi uygulamaları zaman zaman göz ardı edilmektedir. Oysa Çevik yöntemlerde kullanıcı hikâyelerinin ele alınma biçimi, doğru uygulandığında; talep edilen işlevselliğin değerlendirilmesi, mevcut hizmetler üzerindeki etkilerin analiz edilmesi ve diğer hikâyelerle olası çakışmaların azaltılması adımlarını içerdiğinden, değişiklik yönetimi işlevi görecektir. DevOps ortamlarında ise mümkün olan her şeyin otomatikleştirildiği dikkate alındığında, bu adımlar da hizmetin doğasına bağlı olarak otomasyon yoluyla gerçekleştirilebilir. DevOps'taki otomasyonun büyük bir kısmı özellikle sürüm ve dağıtım yönetimi alanında yoğunlaşmaktadır.

Sürüm ve Dağıtım Yönetimi

Hizmet Yönetimi kapsamında sürüm yönetimi ve dağıtım süreçleri birbirine yakın ancak farklı kavramlardır. 

Basitçe ifade etmek gerekirse, sürüm yönetimi, bir hizmetin veya hizmet bileşeninin ne zaman ve hangi koşullarda yayınlanacağını belirleyen, büyük resmi gözeten ve iş hedefleriyle uyum sağlamayı amaçlayan bir süreçtir. Dağıtım yönetimi ise, bir hizmetin nasıl canlı ortama geçirileceğini ve operasyonel hale getirileceğini ele alan, teknik ayrıntılara odaklanan bir süreçtir.

Amaç

Sürüm ve dağıtım yönetiminin temel amaçları, test ve canlı ortamlar arasındaki geçişleri planlamak, zamanlamak ve kontrol altında tutmaktır. Bu sürecin öncelikli hedefi, canlı ortamın bütünlüğünü koruyarak doğru bileşenlerin yayınlanmasını sağlamaktır. 

İyi yapılandırılmış bir sürüm ve dağıtım yönetimi süreci, hizmet kalitesini artırırken kesintileri en aza indirmeye yardımcı olur ve değişikliklerin kontrollü bir şekilde devreye alınmasını güvence altına alır.

Faydalar

Etkili bir sürüm ve dağıtım yönetimi sürecinin sağladığı başlıca faydalar şunlardır:

• Geliştirilmiş hizmet kalitesi: Sürüm yönetiminin etkili bir şekilde yürütülmesi, değişikliklerin hizmet kalitesi üzerindeki olumsuz etkilerini azaltır.

• Daha güçlü risk yönetimi: Yayınlanan sürümlerle ilişkili risklerin önceden belirlenip yönetilmesi, canlı ortamda oluşabilecek kesinti riskini en aza indirir.

• Artan operasyonel verimlilik: Sürüm ve dağıtım süreçlerinin optimize edilmesi, kaynakların daha verimli kullanılmasını sağlar.

Temel Kavramlar

Sürüm yönetimi, sürümlerin test ve canlı (üretim) ortamlara taşınmasının planlanması, zamanlanması ve kontrol edilmesi süreçlerini kapsar. Temel amacı, canlı ortamın bütünlüğünü koruyarak doğru bileşenlerin eksiksiz bir şekilde yayınlandığından emin olmaktır. Bu süreç, birden fazla değişiklik ve özelliğin tek bir sürüm paketi içinde birleştirilmesini ve bunların entegrasyon ile test süreçlerinden geçirilmesini içerir. Yayına alınmadan önce, sürüm canlı öncesi ortamda (ön üretim, pre-prod) test edilerek olası sorunlar önceden tespit edilmeli ve dağıtıma hazır hale getirilmelidir. Genellikle sürüm planı adı verilen belgelenmiş bir prosedür kapsamında yürütülen bu yönetim süreci; farklı ekipler arasında koordinasyonu, sürüm zamanlamalarının belirlenmesini, sürüm dokümantasyonunun hazırlanmasını (örneğin sürüm notları) ve paydaşlarla iletişim ile eğitim faaliyetlerini içerir.

Dağıtım süreci ise, sürümün test, hazırlık veya canlı gibi farklı bir ortamına aktarılması ya da doğrudan kullanıcılara ulaştırılmasıdır. Daha teknik bir süreç olan dağıtım, yeni veya güncellenmiş hizmetin operasyonel hale getirilmesi için gerekli uygulama adımlarını içerir. Bu kapsamda; hedef ortamın hazırlanması, bileşenlerin yüklenmesi, canlı ortama uygun şekilde yapılandırılması ve gerekli testlerin gerçekleştirilmesi gibi işlemler yer alır. Amaç, dağıtımın belirlenen standartlara uygun şekilde gerçekleşmesini sağlamaktır.

Bu süreçlerle ilgili diğer önemli kavramlar şunlardır:

• Sürüm Politikası: Organizasyonda sürümlerin nasıl yönetileceğini tanımlayan kurallar bütünüdür. Yayın zamanlamaları, eğitim gereksinimleri, dokümantasyon ihtiyacı ve iletişim süreçlerini kapsar.

• Sürüm Paketi: Birlikte yayınlanacak konfigürasyon öğeleri (CI'lar), donanım, yazılım ve dokümantasyon gibi bileşenlerin tümünü içeren pakettir.

• Dağıtım Planı: Sürümün canlı ortama nasıl aktarılacağını ayrıntılı biçimde tanımlayan belgedir.

• Ortam: Hizmetlerin geliştirildiği, test edildiği, dağıtıldığı ve işletildiği canlı, test ve geliştirme ortamlarını ifade eder.

Süreç

1. Sürümün planlanması: Sürümün kapsamı, zamanlaması ve gerekli kaynakların belirlenmesiyle süreç başlar.
2. Geliştirme ve test aşaması: Sürüm paketi oluşturularak kapsamlı testler gerçekleştirilir. İşlevsel ve işlevsel olmayan gereksinimlerin karşılandığından emin olmak için kullanıcı talepleri, güvenlik, kalite ve diğer gereksinimler göz önünde bulundurulmalıdır.
3. Sürüm hazırlık kontrolleri: Sürümün dağıtıma tamamen hazır olduğunun doğrulanması gerekir. Bu aşama, kullanıcı dokümantasyonunun güncellenmesini, destek ekiplerinin eğitilmesini ve sürümün hedef ortamda desteklenmeye hazır olmasını içerebilir.
4. Dağıtım süreci: Belirlenen dağıtım planına uygun şekilde sürüm paketi canlı ortama aktarılır.
5. Gözden geçirme ve kapanış: Dağıtımın ardından sürecin değerlendirilmesi ve çıkarılan derslerin belgelenmesi önemlidir. Sürümle ilgili açık problem kayıtları veya çözülmesi hedeflenen olaylar kapatılmalı, sürüm kapsamında yapılan değişiklikler de güncellenmelidir.

Sık Karşılaşılan Sorunlar

• Yetersiz iletişim: Ekipler arasındaki koordinasyon eksikliği, yanlış anlaşılmalara ve sürüm sürecinde hatalara neden olabilir.

• Eksik test süreçleri: Yetersiz testler, sürümün var olan sorunları çözmek yerine yeni problemler yaratmasına yol açabilir.

• Zayıf planlama: Planlama eksikliği, sürümlerin gecikmesine, kaynak sıkıntısına ve kapsam genişlemesine (scope creep) neden olabilir.

• Risk yönetiminin ihmal edilmesi: Olası risklerin belirlenmemesi ve yönetilmemesi, dağıtım sırasında beklenmedik sorunlarla karşılaşma olasılığını artırır.

• Eksik dokümantasyon: Sürüm ve bileşenlerinin yeterince belgelenmemesi, sorun giderme süreçlerinde belirsizliklere yol açabilir ve operasyonel verimliliği olumsuz etkileyebilir.

Sun

ITSM.express yaklaşımının üçüncü aşaması, BT hizmetlerini koruma, ölçme ve geliştirmeye yönelik bütüncül bir sunum sürecini kapsar. Bu aşamada, tasarlanıp oluşturulan ve son kullanıcıya sunulan hizmetlerin, operasyonel ortamda karşılaşabileceği tehditlere karşı korunması sağlanır. Bu tehditlerin büyük bir kısmı tanımlama aşamasında belirlenerek risk kaydına işlenmiş olsa da, sürecin her aşamasında ortaya çıkabilecek yeni tehditlerin tespiti ve yönetimi kritik öneme sahiptir. Ayrıca, sunum aşamasında, hizmet sağlayıcının önceki aşamalarda verdiği taahhütleri yerine getirip getirmediği; hizmet ve hizmet sağlayıcı performansının ölçülmesi yoluyla düzenli olarak doğrulanmalıdır. Aynı zamanda sunulan hizmetlerin sürekli olarak iyileştirilmesine de taahhüt verilmelidir. Bu iyileştirme alanları, hem hizmet performansının ölçülmesi ile hem de yenilikçi yaklaşımların benimsenmesiyle belirlenebilir.

Koruma - Bilgi Güvenliği

Amaç

Bilgi güvenliği söz konusu olduğunda, tanımlama aşamasında açıklanan risk yönetimi ilkeleri doğrultusunda risk temelli bir yaklaşım benimsenmelidir. Bu adımda da, ISO 31000 standardı genel çerçeve sağlamak amacıyla temel bir referans olarak kullanılmaktadır. Bilgi güvenliğinin sağlanması, tedarikçiler, iş ortakları ve tüketiciler de dahil olmak üzere tüm hizmet sağlayıcı paydaşlarının ve çalışanlarının ortak sorumluluğudur. Bilgi güvenliği tehditleri sürekli evrilmekte ve değişmektedir. Bu nedenle, risk değerlendirmelerinin düzenli olarak güncellenmesi ve risk azaltma stratejilerinin gözden geçirilmesi kritik önem taşır. Bu proaktif yaklaşım, güçlü bir bilgi güvenliği yapısının sürdürülebilmesine katkı sağlarken, aynı zamanda ilgili bilgi güvenliği ve gizlilik düzenlemelerine uyumu da güvence altına alır.

ISO/IEC 27001’in uluslararası bilgi güvenliği standardı olduğu unutulmamalıdır. Bu standart, ITSM.express rehberinde ele alınanlardan çok daha kapsamlı gereksinimler içermekte olup, bilgi güvenliği yönetim sisteminin işletilmesine dair detaylı yönergeler sunmaktadır.

Süreç

Bilgi güvenliği risklerini tespit edebilmek için öncelikle korunması gereken varlıkların ne olduğunun net bir şekilde anlaşılması gerekir. Bu varlıkların belirlenmesi ve kayıt altına alınması, onların hizmet sağlayıcı ve tüketiciler açısından ne kadar kritik veya değerli olduğunun anlaşılmasına yardımcı olur. Bu varlıklar fiziksel bilgileri (örneğin, kağıt üzerindeki kayıtlar) kapsayabileceği gibi, dijital ve kişisel bilgileri de içerebilir. Bu sürecin doğru bir şekilde yürütülmesi, hizmet sağlayıcının bilgi güvenliği varlıklarını uygun seviyede koruyabilmesine olanak tanır.

Korunması gereken bilgi güvenliği varlıkları belirlendikten sonra kapsamlı bir risk değerlendirmesi yapılmalıdır. Bu değerlendirme, ilgili varlıkların karşılaşabileceği tehditlerin tanımlanmasını içerir. Ancak tehditlerin her zaman kasti (kötü niyetli) olmayabileceği unutulmamalıdır; bilgi varlıkları, yangın, sel, nem gibi doğal afetlere veya kazara meydana gelen olaylara karşı da savunmasız olabilir. Tanımlanan risk yönetimi yaklaşımı doğrultusunda, bu varlıkları etkileyebilecek potansiyel tehditler ve zafiyetler değerlendirilmelidir. Farklı tehditlerin gerçekleşme olasılığı ve potansiyel etkisi anlaşıldığında, bilgi güvenliği risklerinin nasıl ele alınacağı önceliklendirilerek planlanabilir.

Risk yönetimi, bu tehditlere karşı güçlü güvenlik kontrolleri içeren stratejilerin geliştirilmesini gerektirir. Bu kapsamda; bilgi güvenliğini sağlamak için açık politika ve prosedürlerin oluşturulması, mantıksal ve fiziksel erişim kontrollerinin uygulanması, kötü amaçlı yazılımlara karşı koruma önlemlerinin alınması ve düzenli yedekleme süreçlerinin işletilmesi kritik öneme sahiptir.

Bilgi güvenliği kontrolleri yalnızca teknik önlemlerle sınırlı değildir. Çalışanların hem standart operasyonel prosedürler hem de güvenlik en iyi uygulamaları konusunda eğitilmesi de bu sürecin ayrılmaz bir parçasıdır. Bu eğitimler, güvenlik farkındalığını artırarak hataların önlenmesine katkı sağlar.

Bilgi güvenliği kapsamında önemli bir alt süreç de erişim kontrolüdür. Erişim kontrolü, hem fiziksel güvenliğin (örneğin bina erişimi, güvenli alanlar) hem de uygulama güvenliğinin (uygulama ve sunuculara erişim) temel bir bileşenidir. Bu nedenle, bilgi varlıklarına yalnızca yetkilendirilmiş kişilerin erişebilmesini sağlayacak güvenlik önlemleri uygulanmalıdır.

Erişim Kontrolü

Erişim kontrolü, ağ kaynaklarına, uygulamalara ve verilere erişimi yönetmek ve izlemek için kullanılan süreçleri ve teknolojileri ifade eder. Bu kontrol mekanizması, yalnızca yetkilendirilmiş kullanıcıların ve sistemlerin belirli bilgilere ve işlevlere erişebilmesini sağlamak amacıyla uygulanır. Erişim kontrolü, bilgi güvenliğinin temel prensipleri olan gizlilik, bütünlük ve erişilebilirliğin korunmasında kritik bir rol oynar. Kimin hangi verilere erişebileceğini belirleyerek, kurumlar hassas bilgileri yetkisiz erişimden koruyabilir, veri ihlallerini önleyebilir ve yasal düzenlemelere uyumu kolaylaştırabilir.

Erişim kontrolünün uygulanması, kullanıcıların hangi kaynaklara erişebileceğini ve hangi işlemleri gerçekleştirebileceğini belirleyen politika, rol ve izinlerin tanımlanmasını içerir. Bu süreç genellikle kullanıcı kimlik doğrulama (authentication), yetkilendirme (authorization) ve denetim (audit) mekanizmalarını kapsar. Çoğu durumda, bu işlevler kimlik ve erişim yönetimi (Identity and Access Management – IAM) sistemleri ya da benzer teknolojiler aracılığıyla desteklenir.

Ölçme

Amaç

BT hizmetlerinin ölçümü, performansı anlamak, hizmet sunumunu iyileştirmek ve tüketici ihtiyaçlarıyla iş hedeflerini uyumlu hale getirmek açısından kritik öneme sahiptir. 

Tanımlama aşamasında tüketici raporlamasının nasıl yapılacağı ele alınmıştı. Benzer şekilde, hizmet sağlayıcının da hizmetleri ve performanslarını ölçerek belirlenen hizmet seviyelerinin karşılanıp karşılanmadığını doğrulaması ve bunu raporlaması gerekir.

Faydalar

Veri analizinden elde edilen içgörüler, hizmet sağlayıcının bilinçli kararlar almasına yardımcı olur. Bu, performansın yetersiz olduğu alanlara odaklanmayı, kaynakların yeniden tahsisini veya hizmetlerde ve süreçlerde değişiklik yapılmasını içerebilir. Bu bağlamda ölçüm, sunum aşamasında ele alınan sürekli iyileştirme sürecine doğrudan katkı sağlar.

Temel Kavramlar

Hizmetlerin ölçümü; tüketici memnuniyetini artırmak, kesintileri azaltmak ya da kaynak kullanımını iyileştirmek gibi birçok farklı amaçla gerçekleştirilebilir. Tanımlama aşamasında, tüketici raporlamasının yanı sıra açık hedeflerin, ölçülebilir metriklerin ve bunlara ait hedef değerlerin belirlenmesinin gerekliliği de vurgulanmıştı. Ölçüm, raporlama süreçlerinin temel bir bileşenidir. Tüketiciye doğrudan etki etmeyen, , ancak sunulan hizmetlere altyapı sağlayan iç servislerin de ölçülmesi gerekir. Bu ölçümler, performansa ilişkin içgörüler sunar ve hizmet seviyesinin yeniden sağlanmasını gerektiren önemli olayların tespitine yardımcı olur.

Süreç

Bu süreç kapsamında, hangi verilerin, hangi araçlar ve hangi süreçlerle toplanacağı; bu verilerin performans metriklerinin takibi için nasıl kullanılacağı ve nasıl yorumlanacağı netleştirilmelidir. Örneğin, sistem performansını izlemek için otomatik izleme araçları; tüketici memnuniyetini ölçmek için ise anketler kullanılabilir. Ölçüm için otomasyonun kullanıldığı durumlarda, işlenebileceğinden daha yüksek hacimde verilerle karşılaşılabilir. Bu nedenle, hangi verilerin toplandığı ve bu verilerin organizasyonun hedefleriyle nasıl ilişkili olduğunun açıkça bilinmesi, ölçüm sürecinin başarısı açısından kritiktir.

Kullanılacak araçlar devreye alındıktan sonra, hizmet sağlayıcının bu araçların diğer sistemlerle entegre şekilde çalıştığından ve verilerin tutarlı ve doğru bir biçimde toplandığından emin olması gerekir.

Toplanan veriler düzenli olarak analiz edilmeli; verideki eğilimler, örüntüler ve dikkat gerektiren alanlar belirlenmelidir. Bu analiz sürecinde, büyük veri kümelerini işleyebilen ve görselleştirme yetenekleri sunan veri analitiği araçları yaygın şekilde kullanılır. Elde edilen içgörüler, olay yönetimi süreçlerine katkı sağlayabilir; hatta bu süreçlerin temelini oluşturabilir.

Analiz sonucunda tespit edilen sorunlar, istisnalar ve eğilimler, açık ve anlaşılır şekilde raporlanmalıdır. Bu raporlar, hedef kitlenin bilgi ihtiyaçlarına uygun şekilde hazırlanmalıdır. Örneğin, teknik ekipler ayrıntılı performans verilerine ihtiyaç duyarken; üst yönetim, hizmet yöneticileri ve tüketiciler daha genel ve özet bilgileri tercih edebilir.

Sık Karşılaşılan Sorunlar

Gözden Geçir ve Uyumla: BT ortamları ve iş ihtiyaçları sürekli değiştiğinden, kullanılan metriklerin, veri toplama yöntemlerinin ve analiz tekniklerinin düzenli olarak gözden geçirilmesi ve gerektiğinde uyarlanması önemlidir. Bu sayede yapılan ölçümler, iş hedefleriyle uyumlu ve güncel kalmaya devam eder.

İyileştirme

Amaç

Risk yönetimi ve bilgi güvenliğinde olduğu gibi, hizmet sağlayıcı organizasyonundaki herkes; tedarikçiler, iş ortakları ve tüketiciler dahil olmak üzere, sürekli iyileştirme sürecine katkı sağlayabilir. Organizasyon, müşteri geri bildirimlerinden ve ölçüm aşamasında toplanan, analiz edilen ve raporlanan verilerden öğrenerek; hizmet sunumunu geliştirmek, hizmet hedeflerini ve iş ihtiyaçlarını daha iyi karşılamak ya da doğrudan hizmet hedeflerinin kendisini iyileştirmek amacıyla yinelemeli değişiklikler yapmalıdır.

Süreç

Sürekli iyileştirme yaklaşımları genellikle aşağıdaki adımları içerir:

1. İyileştirme fırsatını belirleyin: Hizmetin beklentileri karşılamadığı, süreçlerin veya işleyişin verimsiz olduğu ya da iyileştirme potansiyeli taşıyan alanlar tespit edilmelidir. Bu fırsatlar; müşteri geri bildirimleri, performans metrikleri, risk yönetimi, bilgi güvenliği yönetimi veya düzenli hizmet değerlendirmesi yoluyla ortaya çıkabilir.

2. Mevcut durumu anlayın: İyileştirilecek hizmeti, süreci veya diğer hedefleri detaylı bir şekilde inceleyerek mevcut durumun net bir resmini oluşturun. İyileştirme öncesinde bir referans noktası belirlemek, yapılacak değişikliklerin etkisini anlamak açısından kritiktir. Bu aşamada olay raporları, iş akışları ve kaynak tahsisleri gözden geçirilebilir.

3. Net ve ulaşılabilir hedefler belirleyin: İyileştirilmesi gereken alanlar belirlendikten sonra, açık, ölçülebilir ve gerçekçi hedefler tanımlanmalıdır. Küçük ve sık yapılan yinelemeli iyileştirmeler, kesintileri ve değişime direnci minimuma indirerek başarılı sonuçların elde edilme ihtimalini artırır. Yapılacak iyileştirmelerin amacı net olmalıdır; örneğin, daha hızlı yanıt süreleri, daha az hata ya da daha yüksek müşteri memnuniyeti gibi. Bu aşamada, iyileştirmenin başarısının nasıl ölçüleceği belirlenmeli ve buna uygun hedefler tanımlanmalıdır. İyileştirme ihtiyacını ortaya çıkaran metriklerin veya geri bildirim yöntemlerinin burada da kullanılması anlamlı ve karşılaştırılabilir sonuçlar sağlayacaktır.

4. İyileştirme planını oluşturun: Yapılan analiz doğrultusunda, iyileştirmenin nasıl gerçekleştirileceğine dair bir plan hazırlanmalıdır. Bu plan; atılacak somut adımları, ihtiyaç duyulan kaynakları ve zaman çizelgesini içermelidir. Gerçekçi olmak ve karşılaşılabilecek olası zorlukları da göz önünde bulundurmak önemlidir.

5. İyileştirmeyi hayata geçirin: Hazırlanan plan uygulamaya alınmalıdır. Bu süreç, personelin yeni prosedürler konusunda eğitilmesini, donanım veya yazılım güncellemelerini, süreç adımlarının yeniden düzenlenmesini ya da kaldırılmasını, kontrol mekanizmalarının eklenmesini veya müşteriyle iletişim yöntemlerinin değiştirilmesini içerebilir.

6. İyileştirmeyi izleyin ve değerlendirin: Yapılan değişikliklerin ardından hizmet dikkatle izlenmeli ve iyileştirmenin etkili olup olmadığı değerlendirilmelidir. Hedef belirleme aşamasında tanımlanan metrikler ve performans hedefleri doğrultusunda iyileşme ölçülmelidir. İzleme sonuçlarına göre, uygulanan iyileştirmelere ek düzenlemeler yapılması gerekebilir.

Hizmet iyileştirmesi tek seferlik bir uygulama değildir; süreklilik gerektiren, döngüsel bir süreçtir. Bu nedenle her iyileştirme tamamlandığında, süreç başa döndürülmeli ve bir sonraki iyileştirme hedefi belirlenerek yeniden başlanmalıdır.

Yanıtla

Hizmet sağlayıcılar, hizmet sunumunun bir parçası olarak sıklıkla tüketicilerle – özellikle de hizmetlerin son kullanıcılarıyla – iletişim kurarlar. Bu iletişim, bazen kullanıcının hizmet sağlayıcıya ulaşmasıyla, bazen de hizmet sağlayıcının kullanıcıyla temasa geçmesi ile başlar.

Bu etkileşimin, gerçekleştirilen işlemleri geriye dönük olarak izlenebilir kılacak şekilde, iyi yapılandırılmış iletişim kanalları üzerinden yürütülmesi önemlidir. Bunu sağlamanın en etkili yollarından biri, hizmet masası gibi merkezi bir temas noktası sunmaktır; ancak bu, iletişimin yalnızca tek bir kanal üzerinden yürütülebileceği anlamına gelmemelidir.

İlgili süreçler, bu merkezi temas noktası üzerinden yürütülür. Bu süreci destekleyen sistemler; eskalasyon, aktivite ve durum takibi ile günlük ölçüm ve yönetim fonksiyonlarına sahip olmalıdır.

Geleneksel olarak, YANITLA aşamasında yer alan süreçler şunlardır:

• Talep Yönetimi

• Olay Yönetimi

• Problem Yönetimi

• Hizmet Raporlama

• Bildirim Yönetimi
  
   

Bu rehberde; olay yönetimi, talep yönetimi ve problem yönetimi, bütünleşik bir yaklaşımla ele alınmaktadır. Bu birleşik yapıya “Yanıt Süreci” adı verilmektedir. Süreç boyunca yürütülen tüm iletişimin gerçekleştiği merkezi temas noktası ise Hizmet Masası’dır.

Hizmet Masası

Amaç

Hizmet masasının temel amaçları şunlardır:

• Hizmet tüketicileri (öncelikli olarak hizmet kullanıcıları) için merkezi bir iletişim noktası sağlamak,

• Hizmet kurtarma ve yeniden sağlama (restorasyon) süreçlerini kolaylaştırmak,

• Kullanıcı taleplerini yönlendirmek ve sonuçlandırılmasını sağlamak,

• Mümkün olan durumlarda olayları ve talepleri birinci seviye destek (L1) kapsamında çözümlemek,

• İletişimi kayıt altına almak, takip etmek ve süreç faaliyetlerinin belirlenen kalite standartlarını (genellikle SLA kapsamında tanımlanır) karşılamadığı durumlarda sürece müdahale etmek,

• Hizmet sağlayıcının üçüncü taraf desteğine bağlı olduğu durumlarda (örneğin eskalasyon yönetimi), sorunların çözümü için etkin bir aracılık sağlamak.

Faydalar

Hizmet masasının sağladığı başlıca faydalar şunlardır:

• Kullanıcılara, hizmet sağlayıcıyla hangi kanal üzerinden ve nasıl iletişime geçebilecekleri konusunda netlik sağlar;

• Sorunlar (özellikle olaylar) ve hizmet talepleri  kayıt altına alınarak, hizmet standartlarına uygun şekilde yönetilebilir hâle gelir;

• Kayıt altına alınan veriler şu amaçlarla kullanılabilir:

  • Hizmetlerin ve hizmet bileşenlerinin iyileştirilmesi,

  • Hizmet sağlayıcının performansının raporlanması,

  • Hizmetin mevcut durumunun daha iyi anlaşılması ve sağlayacağı değerin artırılması.

Süreç

Bir hizmet masası genellikle aşağıdaki görevleri yerine getirir:

• Kullanıcılardan gelen olay ve hizmet taleplerini kayıt altına alır,

• Kullanıcı taleplerine birinci seviye (L1) destek sağlar,

• Hizmetle ilişkili üçüncü taraflarla iletişim kurar,

• Kullanıcılara geri bildirim sunar,

• İlgili paydaşlara durum bildirimleri yapar (örneğin: hizmet kesintileri),

• Toplanan verilerle ilgili olarak paydaşlara raporlama yapar.
  
   

Bu görevler arasında özellikle ikinci maddede belirtilen birinci seviye destek kritik öneme sahiptir. hizmet masası uzmanlarının, kayıt altına alınan olayların ve taleplerin önemli bir bölümünü çözüme kavuşturabilecek teknik yetkinliğe ve gerekli araçlara sahip olması beklenir.

Ayrıca, özellikle küçük ölçekli organizasyonlarda Hizmet Masası, izleme, yedekleme ve operasyonel destek gibi ek sorumluluklar da üstlenebilir.

Sık Karşılaşılan Sorunlar

Hizmet masası yönetiminde sık karşılaşılan bazı sorunlar ve bunların nasıl düzeltilebileceği aşağıda anlatılmıştır:

1. İş (kullanıcı bağlamı) anlayışının eksikliği

Hizmet masası uzmanları, hizmet tüketicilerinin iş bağlamları hakkında bilgi sahibi olmalı ve bir kullanıcı talebinin, kullanıcının iş sürekliliği açısından kritik olup olmadığını hızla belirleyebilmelidir.

Bu taleplerin bağlamını doğru kavrayabilmeleri için hizmet masası uzmanlarına temel bir eğitim verilmesi gereklidir.

2. Teknik anlayış eksikliği

Hizmet masası uzmanları; destek verdikleri hizmetlerin yapısını, hizmet bileşenlerini ve ilgili teknik gereksinimleri kavramış olmalıdır. Bu anlayış, taleplerin büyük çoğunluğunun ilk temasta çözülebilmesi için kritik önemdedir.

Ayrıca, hizmetlerin genel mimarisi hakkında da temel bir farkındalığa sahip olmaları gerekir. Böylece, kendi başlarına çözemeyecekleri bir taleple karşılaştıklarında, talebi yönlendirmeleri gereken eskalasyon noktasını (yani bir sonraki temas noktasını) hızlıca belirleyebilirler.

Hizmet masası uzmanlarının kullanıcı taleplerini ilk temas noktasında etkili şekilde karşılayabilmesi için yeterli teknik bilgiye sahip olmaları, destek verdikleri teknik ortam hakkında gerekli eğitimi almış olmaları ve çözüm için ihtiyaç duyulan araçlara erişimlerinin bulunması gerekir.

3. Doğru bilgi/veri ve entegre araçların eksikliği

Bir hizmet masası, uygun teknik altyapı olmadan işlevini yerine getiremez. Hizmet masası araçları genellikle destek ve teknik yönetim işlevleri için kullanıldığından, bu araçların seçimi, değerlendirilmesi ve yatırım süreci titizlikle yürütülmelidir. Bu sürecin verimli bir şekilde yürütülebilmesi için entegre bir hizmet yönetim sistemine ihtiyaç vardır.

Kullanıcı talepleriyle ilgili veriler, hizmet sağlayıcının tüm altyapısı genelinde etkili bir şekilde yönetilemezse, hizmet masası desteği hiçbir zaman tam olgunluğa ulaşamayacaktır. Bu kapsamda aşağıdaki üç temel unsura dikkat edilmelidir:

• Hizmet kalitesi hedeflerinin gerçekleştirilebilmesi için doğru veriler kayıt altına alınmalıdır.

• İş akışları, ele alınan talep türüyle uyumlu, sade ve yapılandırılabilir olmalıdır.

• Kayıtlı talepler ile çözüm sürecine katkı sağlayabilecek diğer verilere serbest ve kolay erişim sağlanmalıdır. Kayıtlı talepler ve talep çözüm sürecine katkı sağlayabilecek diğer verilere serbestçe ve kolayca erişilebilmelidir.

   

4. İletişim Becerileri ve Empati Eksikliği

Hizmet sağlayıcılar, hizmet masası uzmanlarının kullanıcılarla daha iyi iletişim ve empati kurmalarını sağlayacak eğitimlere yatırım yapmalıdır. Hizmet destek süreçlerinde istenilen sonuçların elde edilmesi yalnızca uzmanların teknik yetkinliği ile değil, kullanıcıların hizmet masasıyla olan etkileşimlerindeki memnuniyetleriyle de doğrudan ilişkilidir.

Performansın Ölçülmesi

Hizmet masası performansı birden fazla yöntemle ölçülebilir ve bu ölçüm süreci, “Sunum” aşamasındaki sürekli iyileştirme çalışmalarıyla yakından ilişkilidir.

Hizmet masasının performansını kullanıcı perspektifinden değerlendirmek için kullanılabilecek bazı kriterler:

• Hizmet masasına ulaşım kolaylığı

• Talep çözüm kalitesi

• Talep çözüm hızı

• Hizmet masası ile etkileşim deneyimi

Hizmet masasının performansını hizmet sağlayıcı perspektifinden değerlendirmek için kullanılabilecek bazı kriterler:

• Bir talebe yanıt verme süresi

• Çözüm süresi

• İlk temasta çözüm sağlama oranı

• Belirli bir zaman aralığında, hizmet masası uzmanı başına alınan talep sayısı

• Belirli bir zaman aralığında, hizmet masası uzmanı başına çözümlenen talep sayısı

• Tekrar açılan talep yüzdesi (Çözüldü olarak işaretlenmesine rağmen, talebin devam ettiğine dair geri dönüş alınan durumlar. Bazı kaynaklar kapanan taleplerin yeniden açılmasını doğru bir uygulama olarak görmese de, bir talep kapandıktan sonra sorunun gerçekten çözüldüğünü ve tekrar etme olasılığının minimize edildiğini doğrulamak için bu metrik önemli bir göstergedir.)

Kullanıcı Taleplerinin Çözümü

Bu bölümde, geleneksel hizmet yönetimi kapsamında olay, hizmet talebi veya sorun/problem olarak ayrı değerlendirilebilecek tüm kullanıcı taleplerini ele almak için temel bir süreç sunulmuştur. 

Bu yaklaşım, organizasyonun ihtiyaçları değiştikçe geliştirilebilecek bir temel rehber sağlar; ancak sürecin karmaşık hale getirilmesi birçok ek zorluğu da beraberinde getirir. 

Kullanıcı talepleri genellikle, sorunun kök nedeni tam olarak ele alınmamış olsa bile, hizmetin hızla çalışır hale getirilmesi amacıyla geçici çözümler veya yamalar uygulanarak kapatılır. Bu bölümde sunulan bilgiler, çoğu organizasyonun taleplerin kök nedenlerini talep kapandıktan sonra ele alma yaklaşımlarının sadece kağıt üzerinde kaldığına dair yaşanan tecrübelerden yola çıkarak, 'tek süreçli' bir yaklaşım sunmaktadır.

Yanıt Süreci

Amaç

Bu sürecin amacı, kullanıcı iletişimi ve talep yönetimini iyileştirerek, hizmet kesintilerini gidererek ve hizmet kesintilerinin tekrarlanmasını önleyerek hizmetlerin sürekliliğinin sağlanmasıdır.

 

Faydalar

Yanıt Süreci’nin sağladığı başlıca faydalar şunlardır:

• Hizmetin son kullanıcıları açısından verimliliğin artması

• Hizmet sağlayıcı personelin daha verimli çalışması

• Son kullanıcı memnuniyetinin yükselmesi

• Hizmet performans sorunları veya kesintilerine ilişkin doğru verilerin elde edilmesi sayesinde hizmet tasarımı ve planlamasının kolaylaşması

• Hizmet kesintilerinin gerçek maliyetinin daha iyi anlaşılmasına katkı sağlanması

Temel Kavramlar

This process deals with three key concepts and lines of work, and providers who think that they want to separate this into three distinct processes should feel free to do so. However, we believe that there are so few differences between how incidents and requests are dealt with that in many organizations, the distinction is academic. 

Over decades, we observed that when incident (e.g. service unavailability or degradation) handling becomes the primary focus, dealing with the root cause after service restoration (generally referred to as problem management) is neglected. Therefore, we believe that an integrated approach is justified and, where it has been implemented, is prudent.

Yanıt süreci, üç temel kavramı kapsamaktadır. Hizmet sağlayıcılar isterlerse bu kavramlar için üç ayrı süreç olarak yapılandırabilir; ancak olay ve talep çözümünün uygulamada çoğunlukla benzer şekilde yürütüldüğünü ve bu ayrımın birçok organizasyonda daha çok teorik bir çerçevede kaldığını gözlemliyoruz. 

Yıllar içinde, olay yönetimi (örneğin hizmet kesintisi veya bozulması gibi durumlar) öncelik kazanırken, hizmet yeniden sağlandıktan sonra kök nedenlerin ele alındığı süreçlerin (genellikle problem yönetimi olarak adlandırılır) ihmal edildiğine sıkça tanık olduk. Bu nedenle, bütüncül bir yaklaşımın sürecin yönetimi açısından daha doğru ve uygulandığında diğer yöntemlere kıyasla daha etkili olduğuna inanıyoruz. 

Bu kapsamda ele alınan üç kavramı aşağıdaki şekilde tanımlayabiliriz:

Olaylar, hizmetin kesintiye uğraması veya kalitesinin düşmesi nedeniyle kullanıcının beklediği faydayı tam olarak elde edemediği durumlardır. 

Bu tür kesintiler veya performans sorunları, çoğunlukla hizmetin tasarımı ya da işleyişindeki yapısal problemlerden kaynaklanır ve bu problemler her zaman kolayca fark edilemeyebilir. Ancak, bu sorunlar doğru bir şekilde ele alınmadıkça, olayların kök nedenleri devam ettiği için tekrarlanacaktır. Olayların altında yatan bu nedenlerle ilgilenmek, genellikle problem yönetimi olarak adlandırılır.

Kullanıcının hizmet kullanımıyla ilgili diğer tüm sorular talep olarak değerlendirilir. Bu, hizmetin nasıl kullanılacağı, belirli özelliklere ya da hizmete nasıl erişileceği veya kullanıcıların hizmetten en iyi şekilde yararlanabilmesi için hizmet sağlayıcının gerçekleştirmesi gereken eylemlerle ilgili olabilir. Ayrıca, özel çıktı talepleri (örneğin özelleştirilmiş hizmet raporları veya sarf malzemeleri) de bu kapsama girer.

Ancak, yeni veya değiştirilmiş hizmet özelliklerine yönelik talepler hizmet talebi olarak değil, değişiklik talebi olarak ele alınır ve değişiklik yönetimi süreci kapsamında yürütülür. Bu süreç, söz konusu taleplerin kaydedilmesini ve ardından hizmet değişikliği ya da özelleştirmesiyle ilgilenen ilgili sürece aktarılmasını sağlar.

Kurumların kullanıcılarından gelen değişiklik taleplerinin çoğu genellikle iyi anlaşılmış ve taşıdığı riskler önceden belirlenmiştir. Bu tür talepler belirlenen sınırlar içinde yönetilebilir ve destek personeline bu standart değişikliklerin nasıl uygulanacağı öğretilebilir.

Organizasyonlar, taleplerin etkisine, aciliyetine ve potansiyel olumsuz etkilerin gerçekleşme süresine göre öncelik seviyeleri belirler.

Hizmetler çoğunlukla geçici bir çözüm ya da alternatif bir yöntemle yeniden işler hâle getirilir ve kullanıcı günlük işlerine dönebildiği anda olay kavramsal olarak kapatılmış sayılır.

Ancak unutulmamalıdır ki, olay her ne kadar kapatılmış gibi görünse de, kök neden giderilmemiş olabilir. Bu durum, hizmette daha fazla performans sorununa, tutarsızlığa ve tekrarlayan kesintilere yol açarak kısa süre içinde kısır bir döngüye dönüşebilir.

Geleneksel hizmet yönetimi yaklaşımında, kök nedenleri belirlemek ve kalıcı çözümler üretmek amacıyla ayrı bir süreç (problem yönetimi) kullanılır. Ancak asıl sorun, bu sürecin çok az sayıda organizasyonda etkili ya da olması gerektiği şekilde uygulanabilmesidir.

Bu nedenle, entegre bir olay/problem yönetimi yaklaşımını öneriyoruz. Gözlemlerimiz ve mevcut veriler, bu yaklaşımın olayların kök nedenlerinin ele alınma olasılığını belirgin şekilde artırdığını göstermektedir.

Bir veya birden fazla olayın kök nedenini bulmaya ve ortadan kaldırmaya yönelik yaygın yaklaşımların ortak bazı aşamaları şunlardır:

1. Sorunun ne olduğunu net bir şekilde tanımlamak
2. Kök nedeni belirlemek – burada önemli bir ayrım yapılmalıdır: Olayın yüzeyde görünen nedenine odaklanmak genellikle yeterli değildir, çünkü her nedenin altında başka bir neden olabilir. Gerçek sorunu kalıcı olarak çözmek için derine inilerek asıl kök nedenin ortaya çıkarılması gerekir.
3. Kök nedeni ortadan kaldırmaya yönelik yöntemleri uygulamak

Burada özellikle vurgulanması gereken bir diğer konu, çoğu durumda birden fazla kök neden bulunduğundan, yalnızca tek bir neden olduğunu varsaymanın yanıltıcı olabileceğidir.

Her kullanıcı talebi için kök neden değerlendirmesi yapmak gerekmeyebilir; ancak önceliği yüksek olan taleplerde bu tür bir değerlendirme mutlaka yapılmalıdır.

Süreç

Hizmet taleplerinin kapsamlı ve doğru şekilde ele alınabilmesi için genel süreç aşağıdaki bileşenleri içerir.

1. Talebin kayıt altına alınması, sınıflandırılması ve önceliklendirilmesi
2. Hizmet Masası 
3. Bilgi Sağlama
4. Hizmet Hakları
5. Hizmetin Yeniden Sağlanması
6. Kök Nedenlerin Ele Alınması
7. Kapanış ve Raporlama

Kullanıcı talepleri geldiğinde, hizmet masası çalışanlarının yalnızca bu talepleri kayıt altına alması yeterli olmayacaktır, aynı zamanda hizmeti ve işleyişle ilgili farkındalıklarının da yüksek olması gereklidir. Böylece, gelen taleplerin doğru şekilde kaydedilmesi, doğru kategoride sınıflandırılması ve işletmeye etkisine uygun bir öncelik seviyesinin belirlenmesi sağlanabilir. 

Kayıt aşamasında genellikle kullanıcı bilgileri, konum, etkilenen hizmet ve yaşanan sorunun belirtileri veya etkileri gibi temel veriler toplanır. 

Sınıflandırma, talebin türünün belirlenmesidir. Örneğin; talebin bir bilgi talebi mi, bir hizmet hakkının kullanımıyla ilgili bir istek mi, yoksa bir hizmetin kesintiye uğraması veya performans kaybı ile ilgili bir bildirim mi olduğu değerlendirilir. Bu ayrım, ilgili iş akışının doğru şekilde tetiklenmesini sağlar. Buna ek olarak, talebin iş üzerindeki etkisi değerlendirilerek öncelik seviyesi belirlenir. 

Talebin niteliğine bağlı olarak, çözüm sürecini hızlandırmak amacıyla önceden tanımlanmış iş akışları veya prosedürler devreye alınabilir.

Hizmet masasının tek irtibat noktası olması, yalnızca telefonla erişilebileceği anlamına gelmez. Hizmet masası, kullanıcı hangi iletişim kanalını kullanırsa kullansın, talepleri etkin şekilde karşılayabilmelidir. Kullanıcılar e-posta, web portalları, sohbet botları veya doğrudan entegrasyonlar gibi farklı kanallar üzerinden hizmet masasına ulaşabilmeli ve her birinde aynı düzeyde destek alabilmelidir.

Organizasyonlar, sıkça sorulan sorulara (SSS) yönelik standart yanıtlar hazırlayarak bu bilgileri çevrimiçi erişilebilir hâle getirir. Bu yanıtlar hem kullanıcılar hem de hizmet masası çalışanları tarafından kolaylıkla erişilebilmelidir.

Ancak, kullanıcının ihtiyacı standart bir yanıtla karşılanamıyorsa, hizmet masası konuyla ilgili en uygun kurumsal kaynağa yönlendirme yapmalıdır. Bu aşamada, kurumsal bilgi yapısına ve iş süreçlerine dair güçlü bir anlayış, doğru yönlendirme yapılabilmesi açısından kritik önem taşır.

Hizmet hakları, son kullanıcıların belirli kaynaklara erişim yetkilerini ifade eder. Uygulamalara erişim, dokümanlara ulaşım veya sistem izinleri gibi talepler bu kapsama girer. Bu tür talepler, gerekli yetkilendirme yapıldıktan sonra hizmet masası tarafından kolayca karşılanabilir.

Ancak bazı durumlarda, bu taleplerin belirli yetkinliklere, erişim izinleri veya karar verme yetkisine sahip bir kişiye yönlendirilmesi gerekebilir. Özellikle daha kritik seviyeli erişim gerektiren ya da güvenlik politikalarıyla ilişkili talepler için uygun kişilere eskalasyon yapılması gerekebilir.

Hizmet kesintilerini ya da beklenen hizmet seviyesinin altında kalan durumları gidermek genellikle teknik uzmanlık gerektirir. Ancak, daha önce uygulanmış çözümler doğru şekilde kaydedilmiş ve bir referans veri tabanı hâline getirilmişse, her durumda ileri seviye teknik yetkinliğe ihtiyaç duyulmayabilir.

Hizmet masasının sık karşılaşılan sorunlar için olası çözüm yollarını önceden tanımlaması, ilk çağrıda çözüm oranını artırmak açısından etkili bir yaklaşımdır. 

Eğer hizmet masası çalışanı bir olayı kendi başına çözemiyorsa, çözüm olasılığı en yüksek teknik uzmana yönlendirme yapabilecek düzeyde teknik bilgiye sahip olmalıdır. 

Eskalasyon yapıldığı durumda, hizmet masası olayın takibini üstlenmeli ve hem teknik ekipten hem de kullanıcıdan konunun başarıyla kapatıldığına dair onay almalıdır.

Bu aşamada, genellikle problem yönetimi olarak tanımlanan ayrı bir süreç devreye girer.

Bir olay kapatılmadan önce, hizmet masası olayın kritik bir etki yaratıp yaratmadığını ve iş sürekliliği üzerinde kayda değer bir risk oluşturup oluşturmadığını değerlendirmelidir. Eğer olay bu tür bir etkiye sahipse, doğrudan kapatılmamalı; kök neden analizi yapılmak üzere daha yetkin bir teknik uzmana yönlendirilmelidir. Bu gibi durumlarda, olay ancak temel neden belirlenip gerekli iyileştirme adımları atıldığında kapatılabilir.

Tüketicinin iş süreçleri üzerinde kayda değer bir etkiye sahip olan tüm hizmet kesintileri ve performans sorunları, hizmet yeniden sağlandıktan sonra mutlaka detaylı biçimde incelenmelidir. Bu tür sorunlar iş sürekliliğini etkilediğinden, hizmet sağlayıcılar benzer bir kesinti veya performans sorununun tekrar yaşanmaması için gerekli önlemleri almakla yükümlüdür.

Bu sürecin nasıl yürütüleceği, hizmet sağlayıcının tercihine bağlıdır. 

Ancak burada dikkat edilmesi gereken kritik bir nokta, bu görevin yalnızca tek bir kişiye atanmasının çoğu zaman yeterli olmayacağıdır. Tek bir kişinin, sorunu farklı yönleriyle ele alacak tüm yetkinliklere sahip olması beklenemez. Bu nedenle, kök nedenin doğru şekilde belirlenmesi ve kalıcı çözümler üretilmesi için teknik ve iş alanlarından uzmanların yer aldığı çok disiplinli bir ekibin çalışması gereklidir.

Kök neden ya da nedenler belirlendikten sonra, benzer bir sorunun yeniden ortaya çıkmasını önlemek amacıyla gerekli düzeltici önlemler alınmalıdır. Bu önlemler çoğu zaman sistematik değişiklikleri beraberinde getirir ve bu nedenle değişiklik yönetimi süreci kapsamında değerlendirilmelidir.

Tüm talepler, prosedürlere uygun şekilde gözden geçirilmeli ve ardından kapatılmalıdır. Çoğu durumda bu, talebi oluşturan kullanıcıya sağlanan çözümden memnun olup olmadığının sorulması kadar basit bir adımı içerebilir.

Ancak işletme üzerinde önemli etkileri olan hizmet kesintileri ve performans sorunlarında, yalnızca kullanıcının onayı yeterli değildir. Bu tür olaylar, tanımlanmış politikalara göre ayrıca değerlendirilmelidir. Gözden geçirme süreci; kök nedenlerin ele alınmasını ve gerekiyorsa değişiklik yönetimi süreci kapsamında düzeltici aksiyonların uygulanmasını içerir.

Ele alınan taleplerin hizmet kalitesinde somut bir iyileşme sağlayıp sağlamadığını doğrulamak adına, talep eğilimlerinin analiz edilmesi oldukça faydalıdır. Aynı şekilde, hizmetin kullanılabilirliği ve kapasitesindeki gelişmeleri izlemek için trend analizi (eğilim yüzdesi) önemli bir araçtır.

Hizmet masasındaki erişim kayıtları ve çözüm sürecine ilişkin veriler, ilgili paydaş ve departmanlarla paylaşılmadan önce anonimleştirilmeli ve gizlilik gerekliliklerine uygun şekilde işlenmelidir.

Bu sürece dair detaylı yönergeler, hizmet raporlama süreci kapsamında ele alınacaktır.

Sık Karşılaşılan Sorunlar

• Yanıt süreci, ancak organizasyon içinde disiplinli bir kayıt, takip, müdahale ve çözüm yönetimi sürdürüldüğünde etkili olabilir. Bu da çoğu zaman hem müşterilerin hem de hizmet sağlayıcıların sürece dair doğru şekilde bilgilendirilmesini gerektirir. İlgili tarafların, sürecin nasıl işlediğini, hangi aşamalardan geçtiğini ve hangi sonuçların beklendiğini net biçimde kavramış olması gerekir.

• Hizmet masası uzmanları, kullanıcı taleplerinin çoğunu ilk temas noktasında çözemiyorsa, hizmet masası etkin şekilde çalışmıyor demektir. Birçok organizasyonda uygulanan “topla ve yönlendir” modeli, yalnızca talepleri başka bir birime aktarmaktan ibarettir ve gerçek bir hizmet deneyimi sunmaz. Oysa hizmet masası, sadece bir yönlendirme noktası değil, doğrudan değer üreten bir çözüm merkezi olmalıdır. Bu nedenle, hizmet masası uzmanlarının doğru yetkinliklere, bilgiye ve araçlara sahip olması; talepleri mümkün olan en kısa sürede ve en etkili şekilde ele alabilmesi gerekir.

• İletişim yöntemleri, kullanıldıkları bağlama uygun olmalıdır. Kullanıcıların teknik bilgi düzeyi ve hizmet bağlamına dair farkındalıkları sınırlıysa, olay kaydının doğrudan kullanıcı tarafından oluşturulması, beklenenin aksine fazladan iş yükü yaratabilir. Özellikle, hizmet masasına e-posta gönderen bir kullanıcının sonradan aranarak aynı talebin tekrar kaydedilmesi gerekiyor ise, bu durum müdahale sürecini geciktirir ve genel süreci verimsizleştirir.

• Organizasyon üzerinde önemli etkiye sahip tüm hizmet kesintileri ve performans sorunlarının kök nedenleri mutlaka analiz edilmelidir. Geçici çözümler yerine, hizmetin tekrar kesintiye uğramasını önleyecek sürdürülebilir ve etkili yöntemler geliştirilmelidir.