ITIL v3 Yaklaşımı Hizmet Geçişi

Geldiğimiz aşamaya kadar BT LTD şirketinde Hizmet Stratejisi’nin planlanması ve çeşitli Hizmet Tasarımı işlemlerinin yapılması ile ilgili gereksinimler üzerine konuşmuş olduk. Bu yazıda inceleyeceğimiz konuda sahip olduğumuz hizmetlerde veya yeni oluşturduğumuz hizmetlerde geçiş aşamalarının neler olduğu üzerinde konuşacağız.

 

Öncelikle kısa bir özet geçmek istiyorum. BT LTD olarak sistem destek hizmeti, ağ hizmetleri ve kurumsal hizmetlerin yanı sıra yeni bir hizmet olarak dış kaynak hizmeti vermek istediğimizi varsayarak ilerledik. Hizmet Stratejisi’nde şirketin bu hizmeti neden vermesi gerektiği üzerinde konuştuk. Müşteriye ve hissedarlarımıza sağlayacağı faydaları, hizmetin değeri ve olası risklerini belirledik. Hizmet Tasarımında portföyümüzü ve hizmet kataloğumuzu ayrıntılanırdık, hizmetin süreçleri hakkında konuştuk, ölçümlemelerin öneminden bahsettik ve ne tür kaynak stratejileri olduğu hakkında bilgi verdik.

 

Bu aşamada konunun netleşmesi için bir müşterimizin taleplerini belirterek Hizmet Geçişi konusunda başlamak istiyorum.

 

Aşağıda müşterimizin genel bilgileri ve beklentileri bulunmaktadır:

 

 

 

image001

 

 

 

Müşteri BT LTD’den bir dış kaynak yardım masası desteği istemektedir. Mevcut durumda şirket bünyesinde çalıştırdığı tüm helpdesk personelini dış kaynak firmasının karşılamasını ve tüm problemlerin bu çalışanlar tarafından çözülmesini talep etmektedir. Ayrıca altı aylık gözden geçirmelerle durum analizi ve raporu da istemektedir.

 

BT LTD olarak bu tür hizmetlerin nasıl karşılanacağı hakkında bir katalog hazırlamıştık ve müşteri bu hizmeti almak için firmamızı tercih etmiştir. Proje üzerinde yaptığımız fizibiliteden sonra bu işin ayrıntılarını da müşteriyle yaptığımız görüşmelerde netleştirdik. Elimizde de ayrıca aşağıdaki gibi bir Hizmet Seviyesi Anlaşması bulunmaktadır ve artık bu hizmeti canlıya almak istiyoruz.

 

 

 

 

 

 

D-BİLGİ TEKNOLOJİLERİ ŞİRKETİNDE HİZMET GEÇİŞİ

 

 

Hizmet Geçişini şu şekilde tanımlayabiliriz:

 

 

1-      Hizmet Tasarımı ile Hizmet Operasyonu arasındaki bağlantıdır.

2-      Ayrıca diğer ITIL fazlarıyla da ilişkilidir.

3-      Hizmet Stratejisi ve Hizmet Tasarımından gelen bilgiler, kurallar ve talimatlara göre hareket edilir.

4-      Hizmet Tasarımından gelen girdi ile başlar(Hizmet Tasarım Paketi, Değişim Talebi, Yeni Hizmet Talebi)

5-      Organizasyonu yeni hizmete veya değişime hazırlamayı amaçlar.

6-      Hizmetin uygulanabilir olup olmadığının anlaşılması için bir geçiş sürecidir.

7-      Uygulamadaki oluşabilecek riskleri karşılamak için ilk adımdır.

8-      Müşterinin beklentilerine uyumluluğu kontrol etmek için değerlendirme noktasıdır.

 

 

Müşterinin sorunlarını çözecek olan ekibin hazırlanmasıyla başlıyoruz. Müşteri problemlerin ilk olarak telefonla karşılanması ve kayıt altına alınarak çözülmesini talep etmektedir. Gerekli altyapı ve iletişim teknolojilerinin kurulumları bu aşamada hazırlanır ve testler yapılır.

 

 

Firmanın destek verilmesini istediği bazı özel yazılımlar bulunabilir. Bunlar için ekibin kısa bir eğitimden geçirilmesi ve destek alacak olan kullanıcıların da prosedürle ilgili olarak bilgilendirilmesi gerekmektedir. Bu süreç organizasyonun ve hizmetin büyüklüğüne göre değişir. BT LTD ve GIDA LTD bu süreçle ilgili anlaşmayı da önceden belirler.

 

 

Destek verecek personelin kullanacağı yazılım ve donanımların kurulumları da tamamlanarak hizmet start alır. Tüm bu aşamalar ITIL v3 süreçlerinde belirlenmiştir. Şimdi bu süreçlerin neler olduğuna bakıp bunların üzerinden devam edelim.

 

 

Service Asset & Configuration Management

Change Management

Release & Deployment Management

Knowledge Management

 

 

 

E- HİZMET GEÇİŞİ SÜREÇLERİ

 

 

Service Asset & Configuration Management

 

 

 

Bu süreç Hizmet Yönetimi’ndeki tüm aşamalar için doğru karar almayı sağlayacak olan konfigürasyon bilgisini sağlar. Süreçle ilgili bazı tanımlamalar şu şekildedir:

 

 

Configuration Item (CI): Hizmetin verilmesi için kullanılan veya ihtiyaç duyulabilecek olan tüm alt parçaları temsil eder. Hizmetin büyüklüğüne göre Service Lifecycle, hizmetler, dahili ve harici parçalar ile ara yüz parçaları olarak ayrılabilir. Bunlara örnek olarak vaka analizi, hizmet yönetim planı, hizmet tasarım paketi, değişim ve test planları, süreçler, uygulamalar, çeşitli veriler ve ilgili bilgiler, altyapı ürünleri, sorumlu kişiler, talimatlar, kurumsal stratejiler ve kurallar, data Centerlar, yazılımlar ve anlaşmalar verilebilir.

Configuration Managemen System(CMS): Tüm Configuration Item(CI) bilgilerinin kontrol edilip yönetimini sağlar. Birbirinden farklı ama ilişkili olan tüm CI bilgilerine ulaşılır. Incident, Problem, Known Error ve Change & Release dokümanları burada yönetilir.

Configuration Management Database(CMDB): CMS’nin ihtiyaç duyduğu tüm bilgilerin saklandığı veri tabanıdır. Tüm CI ilişkileri burada tutulur.

Definitive Media Library (DML): Bir veya daha fazla lokasyonda bulundan ilgili tüm CI bilgilerinin güvenli bir şekilde saklandığı alandır. Burada lisans bilgileri ve CI ile ilgili dokümanlar tutulur. Bunlar yazılımsal bilgiler olabildiği gibi fiziksel de olabilir.

 

 

       

 

 

 

Service Asset & Configuration Management süreci ile kayıtlı olan tüm CI bilgileri ve bunlar arasındaki ilişkileri yönetebiliriz. Diğer süreçler için de bize aşağıdaki bilgileri sağlar:

 

 

Incident ve Problem nedenlerini ve etkilerini değerlendirmek

Talep edilen değişimlerin etkilerini değerlendirmek

Yeni bir hizmeti veya değişimi düşünülen hizmeti planlamak ve tasarlamak

Teknoloji yeniliklerini ve yazılım güncelleştirmelerini planlamak

Hizmetin diğer farklı lokasyonlara hızlı şekilde uygulanmasını planlamak

Altyapının ve maliyetlerin uygun seviyeye getirilmesini sağlamak

 

 

Bu bilgiler ışığında müşterimizin ihtiyaçlarına bakacak olursak şunları yapmamız gerektiği ortaya çıkacaktır:

 

 

Mevcut durumda kullanılan uygulamaların bir listesi oluşturulmalı

Uygulamaların hızlı şekilde güncelleştirilebileceği bir ortak alanın hazırlanması

Sahip olunan tüm donanım ve lisanların erişilebilir bir alanda olması

Güncelleştirilecek yazılımlar için uygulanacak talimat ve prosedürlerin paylaşılması

İletişim ve network altyapısının kontrol edilmesi

Karşılaşılan sorun ve problemlerin kayıt altına alınıp listeleneceği bir veri tabanın oluşturulması

Dahili ve harici kontak bilgilerinin çalışanlara paylaştırılması

 

 

CMDB bizim hizmetimizi geliştirmemiz için ciddi derecede öneme sahiptir. Bu database karşılaştığımız tüm sorun ve problemleri içerisinde bulundurur. Gözden geçirme veya raporlama zamanlarında buradan yapılacak analizle hizmet işleyişi değiştirilebilir, sorunlara kesin çözüler bulunabilir, performans analizleri yapılabilir ve en önemlisi hizmetin ne durumda olduğu hakkında müşteriye ve hizmet sağlayıcısına kaynak sağlayabilir.

 

 

Change Management

 

 

Bu süreçle müşterinin ihtiyaç duyduğu tüm değişimler için kontrol mekanizması oluşturulur. Değişimleri önceliklendirme ve yönetmek, talepleri uygulamak, değişim sonrasında yaşanabilecek sorunlara hakim olmak, değişim kaynaklı riskleri yönetmek ve değerlendirmek için bu süreç kullanılır.

 

 

Change Management büyük organizasyonlarda Change Advisory Board (CAB) içerisindeki bir grup veya kurul tarafından yönetilir. Daha küçük organizasyonlar bunun için tek bir kişiyi sorumlu tutabilir veya çeşitli değişim talimatları ile de bunu yönetebilir. Bir tonerin değişimi de bu sürecin içerisine dahil edilebileceği gibi şirketin tüm notebooklarının değişimi de bu sürecin kapsamı içerisindedir.

 

 

Değişim, tüm organizasyonlar için değişmeyen tek süreçtir. Müşteri değişimin yönetilmesi için de sizden destek isteyebilir. Değişimin çeşitli tipleri vardır:

 

 

Hizmet veya hizmet tanımında yapılacak değişimler: Bunlar mevcut hizmette yapılacak olan değişimleri veya geliştirmeleri kapsar. Müşteri yalnızca genel müdürlük lokasyonu için istediği hizmeti sonradan diğer bölge lokasyonlarına veya kendisine bağlı olan

tüm bayilere verilecek şekilde değiştirilmesini isteyebilir. Veya önceden sadece telefondan verilmesini istediği desteğin web üzerinden verilecek şekilde genişletilmesini de isteyebilir.

Kullanıcı erişim talepleri: Yetkilendirme gibi değişikliklerin yapılmasını isteyebilir

Operasyonel değişimler: Günlük kullanımdaki donanımların değişimini isteyebileceği gibi tüm altyapının veya veri merkezinin değişimini de talep edebilir.

 

 

Değişimleri doğru şekilde yönetebilmek için uygun sınıflandırmasının da yapılması gerekmektedir. Bunlar standart, normal ve acil değişimler olarak sınıflandırılabilir. Sınıflandırma ile olağan durumlarda yapılacak olan değişimlerle olağanüstü durumlarda yapılacak olan değişimleri kontrol altında tutabilirsiniz. Böylece verdiğiniz hizmet önceden tanımlanmış bir standartta yürütülür ve olası problemlerde müşteriyle karşı karşıya gelme ihtimaliniz düşer.

 

 

ITIL ile Change Management sürecini yönetirken ihtiyaç duyabileceğiniz bazı temel adımlar vardır. Her biri R harfiyle başlayan ve 7Rs olarak isimlendirilen bu soruları yanıtlayarak değişimi kolayca yönetebilirsiniz. Bunları şöyle sıralayabiliriz:

 

 

RAISED: Değişim talebi açılmasına kimin yol açtığını sorgular

REASON: Değişim talebinin nedenini sorgular

RETURN: Değişim talebinin getirisini/geri dönüşünü sorgular

RISKS: Değişim talebinin yapılması veya yapılmaması durumundaki riskleri sorgular

RESOURCES: Değişim talebinin yerine getirmek için gerekli olan kaynakları sorgular

RESPONSIBLE: Değişim talebinin yerine getirilmesi için kimin sorumlu olduğunu sorgular

RELATIONSHIP: Değişim talebinin diğer değişimlerle olan ilişkilerini sorgular

 

 

 

 

 

 

Release and Deployment Management

 

 

Hizmeti oluşturup, test ettiğimiz ve uygulamaya başladığımız süreçtir. Müşterinin gereksinimlerinin karşılanmasını ve talep edilen hizmetin uygulanmasını sağlar. Süreçle ilgili olarak bilinmesi gereken tanımları şöyle sıralayabiliriz:

 

 

Release: Değişimi yapılması istenen veya uygulanması istenen tüm donanım, yazılım ve ilgili diğer bileşenleri temsil eder.

Deployment: Mevcut sisteme uygulanacak olan bileşenin taşınması eylemini temsil eder.

Release Unit: Değişimin birlikte yapılacağı hizmet veya IT altyapısı bölümlerini temsil eder.

 

 

Sürecin amaçlarını da şu şekilde listeleyebiliriz:

 

 

Müşteri ile Release and Deployment planı üzerinde anlaşmak ve tanımlamak

Release paketinin birbiriyle uyumlu olan tüm hizmet bileşenlerini içermesini sağlamak

Geçiş prosedürleriyle oluşturulan ve CMS tarafından kaydedilen Release paketinin ve ilgili bileşenlerinin entegrasyonunun sağlanması

Tüm release paketlerinin uygun şekilde izlenebilmesini, yüklenebilmesini, test edilmesini, onlaylanmasını veya eğer gerekliyse kaldırılmasını ve yedeklenmesini sağlamak

Müşterinin değişim talebinin süreç boyunca yönetilmesini sağlamak

Yönetimsel sorunları, riskleri ve değişimle ilgili sorunları kayıt altına almak

Hizmetin kullanımıyla ilgili bilgi alışverişinin sağlanması

Hizmetin sağlıklı ve verimli şekilde yürütülebilmesi için destek verecek olan personelin bilgilendirilmesi ve gerekirse eğitimin sağlanması

 

 

Gıda LTD için vereceğimiz yardım masası dış kaynak desteği için bu sürece bakacak olursak öncelikle tüm iletişim altyapısının ve kontak noktalarının belirlendiğinden ve uygulanabilir olduğundan emin olmamız gerekmektedir. Müşteri tarafından tüm kullanıcıların destek personeline ulaşabileceği hizmet numaralarının paylaşılmış olması gerekmektedir. Eğer sadece belirli sorunlar için bu hizmet numarası aranacak ve destek istenecekse kullanıcıların bu konuda bilgilendirilmesi de gerekmektedir. Bazı durumlarda müşteri sadece basit sorunların ve basit değişimlerin yönetilmesi için sizden destek isteyebilir. Sorumluluğu yüksek olan yetkilendirme, pc-notebook değişimleri, standart olmayan ve lisanssız yazılımların yüklenmesi gibi taleplerin bu destek personeli tarafından yapılmasını istemeyebilir. Bu gibi durumlarda kullanıcının destek personeli üzerinde gereksiz iş yükü oluşturmaması için ne tür problemler ve talepler için destek isteyebileceği kullanıcılara bildirilmelidir. Aynı şekilde hizmet personeline de destek vereceği uygulamalarla ilgili sorunları hızlı şekilde çözebilmesi için bilgilendirme ve eğitim verilmelidir. Bu eğitim ilk olarak bu sorun ve taleplerin kaydını tutacağı uygulamanın eğitimi ile başlar.

 

 

Müşterinin tüm MS Office versiyonlarının güncelleştirilmesini istediğini düşünelim. Burada hizmet kapsamında yapılması gereken bu güncelleştirme Release and Deployment süreci tarafından kontrol edilir. Bunu tüm kullanıcılara bir seferde uygulayabileceğiniz gibi belirli bir zamana yayarak kademeli olarak da yapabilirsiniz. Aşağıda uygulayabileceğiniz diğer yöntemler listelenmiştir:

 

 

BigBang veya Phased: BigBang ile tüm işlem tek bir seferde tüm kullanıcılara yapılırken Phased yöntemi ile hazırlanan bir plana bağlı kalarak farklı bölgelerdeki kullanıcılara ayrı ayrı yapılır.

Push veya Pull: Push ile merkezi bir noktadan kullanıcılara gönderim sağlanırken Pull yine merkezi bir noktadan yalnızca kullanıcının ihtiyaç duyduğu anda işlemin yapıldığı yöntemdir.

Automation veya Manual: Automation yönteminde bir yazılım kullanılarak istenen işlem yapılırken Manual yönteminde kullanıcının ihtiyaç duyduğu işlem için yerinde destek personeli gönderilir.

 

 

Release and Deployment süreci ile virüs güncelleştirmeleri, yazılım kurulumları, lisans güncelleştirmeleri gibi işlemleri de yönetebilirsiniz.

 

 

Knowledge Management

 

 

Karar alma sürecini geliştirmek için Service Lifecycle süresince erişilebilecek güvenilir ve korumalı olan bilgi desteğinin sağlamak için bu süreç kullanılır. Hizmet sağlayıcısına hizmetin kalitesini ve verimliliğini artırmayı sağlar. Ayrıca destek personeline de gerekli olan bilgileri sağlar. Tüm bu bilgiler Service Knowledge Management System (SKMS) içerisinde tutulur. SKMS bununla birlikte Hizmet Portfolyosu’nu ve Hizmet Kataloğu ’nu da içermektedir. Hizmet Stratejisi ve Hizmet Tasarımı fazlarında da belirttiğimiz gibi buradaki bilgilerden sadece Hizmet Kataloğu müşterilerle paylaşılabilir. Bunun dışındaki bilgiler şirketimize özel karar alma sürecinde kullanılmak üzere burada tutulmaktadır.

 

 

 

 

 

 

Knowledge Management sürecinde bilginin aşamaları ile ilgili olarak DIKW modeli kullanılır. Bunları şu şekilde sıralayabiliriz:

 

 

 

 

 

 

Data: Vakalarla ilgili olan bir takım farklı durumları temsil eder.

Information: Datadan daha anlamlı ve daha kapsamlı içerik sağlar. Kim, ne, ne zaman, nerede gibi basit soruların yanıtlarını içermektedir.

Knowledge: Yargılama, sorgulama, fikir verme ve açıkça belirtilmeyen deneyimlerin anlaşılmasını sağlar. Nasıl sorusunun yanıtını içerir.

Wisdom: Bilginin ulaşabileceği son noktadır. Neden sorusuna yanıt verir. Kayıt altına alınan bir bilgiden ziyade üst düzey bir düşünce denilebilir.

 

 

Konuyu özetlemek gerekirse;

 

 

1-      Hizmet Geçişi ile Hizmet Stratejisi ve Hizmet Tasarımından gelen bilgiler ışığında Hizmet Operasyonuna hazırlanmak amaçlanmaktadır.

2-      Hizmet Tasarımı ile Hizmet Operasyonu arasındaki bağlantıdır.

3-      Diğer Service Lifecycle süreçleriyle de ilişkilidir.

4-      Hizmetin canlıya alınmaya başlandığı, test edilerek müşteriye sunulduğu aşamadır.

5-      Organizasyonda bulunan tüm Configuration Item (CI) bilgileri Configuration Management Database (CMDB) içerisinde bulundurulur ve Configuration Management System (CMS) tarafından yönetilir.

6-      Müşterinin ihtiyaç duyduğu tüm değişimler bu fazdaki süreçlerle yönetilir.

7-      Yeni ve değiştirilmesi istenen hizmet bu fazdaki süreçlerle gerçek ortama aktarılır.

8-      Riskleri yönetmek ve yönetimsel sorunları gidermek için bu fazdaki bilgilerden faydalanılır.

9-      Service Knowledge Management System (SKMS) ile tüm hizmet bilgileri kayıt altında tutularak karar alma sürecinde kullanılmak üzere saklanır.

10-   Yapılan testler ve geri dönüşler eğer makul düzeyde ise artık hizmeti rutin şekilde uygulayacak operasyonel faza geçiş yapılabilir.

Exit mobile version