Servis Masası Biletleme Yazılımı: Nedir, Neden İhtiyacınız Var ve Hatasız Bir Şekilde Nasıl Uygulanır?

Pazartesi, saat 09.00. Teknik destek müdürü gelen kutusunu açar ve 23 yeni e-posta görür. Üçüncü kattaki yazıcı bozulmuş, bir çalışan CRM şifresini unutmuş ve yeni işe alınan bir çalışanın kurumsal portala erişim izni gerekiyor. Mesajlaşma uygulamasında da benzer sorunlarla ilgili 15 mesaj daha var. Bazı talepler farklı kanallarda tekrar ediyor, bazıları ise gidip gelme sürecinde kaybolmuş durumda. Birisi "Bu ne zaman düzeltilecek?" diye sorduğunda, verilen cevap sadece bir tahmin oluyor.

Bu tür durumların norm haline gelmesini önlemek için hizmet masası vardır: kaotik bir talep akışını yönetilebilir ve şeffaf bir sürece dönüştüren biletleme yazılımı.

Servis masası nedir ve neden biletleme yazılımına ihtiyacınız var?

Servis masası, talepleri merkezi olarak almak, işlemek, yönlendirmek ve takip etmek için kullanılan bir yazılımdır. "Yazıcı bozuk"tan "ERP'ye yeni bir tedarikçi eklememiz gerekiyor"a kadar, çalışanlar ve müşterilerden gelen tüm talepler için tek bir iletişim noktasıdır.

Servis masası kavramı, 1980'lerin sonlarında şirketlerin özel teknik destek ekipleri kurmaya başladığı dönemde BT alanında şekillenmiştir. ITIL (BT Altyapı Kütüphanesi) çerçevesinin ortaya çıkmasıyla birlikte bu yaklaşım, bir "yardım hattı" olmaktan çıkıp tam teşekküllü bir BT hizmet yönetim sistemine dönüşmüştür.

Günümüzde hizmet masası, çoktan BT departmanının sınırlarını aşmıştır. İK, çalışan taleplerini yönetmek için; muhasebe, şirket içi finans taleplerini karşılamak için; tesis yönetimi ise işyeri ve ofis sorunlarını çözmek için hizmet masasından yararlanmaktadır. Bir talep yönetim sistemi arayan şirketler, neredeyse her zaman bilet yönetimini olmazsa olmaz bir özellik olarak belirtir ve çoğu, kullanıma hazır SLA yönetimi ile bir self servis portalı da bekler.

Günümüzde bir hizmet masası, bağımsız bir yardım masası değil, bir ESM (Kurumsal Hizmet Yönetimi) ekosisteminin parçasıdır. BT hizmet yönetimi (ITSM), İK hizmetleri, tesis yönetimi ve diğer departmanları tek bir talep yönetim sistemi altında bir araya getirir.

Talep türleri: bir hizmet masasının ele aldığı konular

Bir talep yönetim sistemi, çeşitli talep kategorileriyle çalışır. Uygulamaya geçmeden önce bu farklılıkları anlamak önemlidir; çünkü bu sayede yönlendirme ve SLA’ları doğru bir şekilde ayarlayabilirsiniz.

Talep türlerini ayırmak, birçok sorunu aynı anda çözer. Olaylar ve değişiklikler farklı prosedürlere tabidir: ilki acil müdahale gerektirirken, ikincisi önceden onay alınmasını gerektirir. Net bir sınıflandırma olmadan, uzmanlar yapılması gerekeni yapmak yerine ne yapılması gerektiğini bulmaya zaman harcarlar.

Türlerinin yanı sıra, talepler öncelik ve kaynağa göre de sınıflandırılır. Kaynak açısından talepler BT, İK, tesisler, muhasebe ve hukuk departmanlarından gelir. Öncelik açısından ise kritik (çözüm süresi 1–2 saat) ile düşük (5–7 gün) arasında değişir. Düzgün yapılandırılmış bir bilet sistemi, kurallara ve anahtar kelimelere göre önceliği otomatik olarak atar.

Manuel talep yönetiminde sık karşılaşılan sorunlar

Bir talep yönetim sistemi arayan şirketler, en sık olarak otomasyon eksikliğini, zayıf raporlama ve analitik özellikleri ile çok kanallı desteğin bulunmamasını başlıca sorunları olarak belirtir. Aşağıda, bu şikayetlerin ardındaki spesifik senaryolar yer almaktadır.

1. Talepler yazışmalar arasında kaybolur

Bir talep, tatilde olan bir uzmanın kişisel sohbetine düşer. Ya da genel e-posta akışının içinde kaybolur. Kullanıcı yanıt bekler, uzman talepten haberdar değildir ve sorun daha da büyüyene kadar yönetici sorunu fark etmez.

2. Önceliklendirme yapılmaması

Tüm talepler geldikleri sırayla veya “en yüksek sesle bağıran” esasına göre ele alınır. Gerçekten acil görevler en son çözülür. Uzmanlar acil olmayan taleplere zaman harcar ve en önemli noktalarda SLA taahhütlerini ihlal eder.

3. İşin tekrarlanması

Kullanıcı, talebinin ulaşıp ulaşmadığını bilmediği için talebi tekrar gönderir: e-posta, mesajlaşma uygulaması veya telefon yoluyla. Birkaç uzman, birbirlerinden habersiz olarak aynı sorun üzerinde paralel olarak çalışır. Çalışma süresi, sorunun çözümü yerine koordinasyona harcanır.

4. Yönetici genel durumu göremez

Kaç talep işleniyor? Hangileri son teslim tarihini kaçırmak üzere? Kim aşırı yük altında? Bu soruların yanıtı ancak veriler manuel olarak toplanarak bulunabilir ve rakamlar hazır olduğunda çoktan güncelliğini yitirmiştir.

5. Geçmiş kaybolur

Geçmiş taleplerle ilgili bilgiler kişisel yazışmalarda saklanıyor ya da hiç saklanmıyor. Aynı sorunlar defalarca çözülüyor ve tekrarlayan olayların temel nedenleri hiçbir zaman tespit edilemiyor.

6. Ölçeklendirme imkansızdır

Bir şirket 100–300 çalışana ulaştığında, manuel talep işleme sistemi artık yetersiz kalır. Yanıt süreleri uzar, personel memnuniyetsizliği artar, süreçler üzerindeki kontrol kaybedilir ve bir uzman daha işe almak artık bir çözüm olmaz.

Servis masası ile otomasyonun faydaları

Düzgün bir şekilde yapılandırılmış bir bilet sisteminin, yukarıdaki sorunlu senaryoların her birinde talep işlemeyi nasıl değiştirdiğine bir göz atalım.

1. Hiçbir şey kaybolmaz

Tüm talepler, geldikleri kanal ne olursa olsun (e-posta, portal, mesajlaşma uygulaması veya telefon) otomatik olarak sisteme kaydedilir. Her talebe benzersiz bir numara atanır. Yazışmaların ve işlemlerin tüm geçmişi tek bir yerde saklanır. Kayıp talepler, kural değil istisna haline gelir.

2. Otomatik yönlendirme ve önceliklendirme

Sistem, kurallara ve anahtar kelimelere göre talebin türünü, kategorisini ve önceliğini otomatik olarak belirler ve becerilere ve mevcut iş yüküne göre sorumlu bir uzman atar. Gelişmiş çözümler, binlerce otomatik atama kuralı oluşturmanıza, bunları içe aktarmanıza veya JavaScript ile yapılandırmanıza olanak tanır. Aynı zamanda, yerleşik SLA izleme özelliği, son tarihleri otomatik olarak takip eder, son tarihlerine yaklaşan talepleri vurgular ve eskalasyonu tetikler. Sonuç olarak, SLA uyumluluğu genellikle belirgin bir şekilde artar.

3. Self servis portalı

Kullanıcılar, hizmet kataloğu, bilgi bankası ve SSS aracılığıyla sık sorulan soruların yanıtlarını kendileri bulur. Standart sorulara ilişkin talep sayısı azalır. Portaldaki bir yapay zeka asistanı da talebi sınıflandırır ve gerekirse doğru kategoride otomatik olarak bir bilet oluşturur. Bu, uzman gerektirmeden çalışan sıfır destek hattıdır.

4. Şeffaflık ve analitik

Yöneticiler, her uzmanın iş yükünü, her talebin durumunu ve hangilerinin son tarihlerine yaklaştığını gerçek zamanlı olarak görebilir. Analitik veriler belirli kalıpları ortaya çıkarır: Bir hafta içinde on çalışan aynı sistem yavaşlığından şikayet ederse, bu durum BT ekibine her bileti ayrı ayrı yanıtlamak yerine sorunun nedenini araştırması gerektiğine dair bir sinyaldir.

5. Zaman tasarrufu

Kayıt, yönlendirme, bildirim ve raporlamanın otomatikleştirilmesi, uzmanların rutin işlere ayırdıkları zamanı önemli ölçüde azaltır ve karmaşık sorunları çözmeye daha fazla zaman ayırmalarını sağlar.

6. Çok kanallı destek

E-posta, portal, mesajlaşma uygulamaları ve telefondan gelen talepler tek bir sisteme aktarılır ve ortak kurallara göre işlenir. Kullanıcılar hangi kanalı kullanacaklarını düşünmek zorunda kalmaz; her halükarda bir yanıt alırlar.

SimpleOne ITSM: BT ve tüm işletme için bir bilet sistemi

SimpleOne ITSM, ITIL 4 ilkeleri üzerine kurulmuş, talep yönetimini otomatikleştiren bir platformdur.

Temelinde, kodsuz, az kodlu ve profesyonel kodlama araçlarına sahip esnek bir platform yer alır: standart süreçler geliştiricilere ihtiyaç duyulmadan yapılandırılır ve karmaşık senaryolar JavaScript ile genişletilir. Bu, süreçlerde değişiklik olduğunda şirketin tedarikçiye bağımlı kalmayacağı anlamına gelir.

BT departmanı için SimpleOne ITSM, taleplerin alınması ve işlenmesi, SLA yönetimi, CMDB, bilgi tabanı, self-servis portalı ve değişiklik yönetimi gibi tüm döngüyü kapsar. Olgun bir BT desteği için ihtiyacınız olan her şey, ayrı modüller satın almaya gerek kalmadan tek bir üründe mevcuttur.

Aynı zamanda, platform BT ile sınırlı değildir. BT süreçleri bir kez devreye girdiğinde, İK, tesis yönetimi, muhasebe ve hukuk departmanları da aynı sisteme bağlanır ve aynı ilkeler üzerinden çalışmaya başlar: tek bir hizmet kataloğu, SLA’lar, yönlendirme ve analitik. Şirket, birbirinden kopuk bir dizi araç yerine tüm iç hizmetler için tek bir platforma sahip olur.

Temel özellikler

1. Çok kanallı talep alımı

Kullanıcılar e-posta, self servis web portalı, mobil uygulama, mesajlaşma uygulamaları, telefon ve sohbet robotu aracılığıyla talepler oluşturur. Tüm talepler tek bir sisteme aktarılır ve ortak kurallara göre işlenir.

2. SLA yönetimi

Yerleşik hizmet seviyesi anlaşması izleme özelliği, LCAP platformu düzeyinde ayrı bir mikro hizmet olarak uygulanır: göstergeler yüksek hızda hesaplanır ve aynı anda ITSM, İK, tesis yönetimi ve diğer uygulamalar için çalışır. Öncelikler değiştiğinde geriye dönük yeniden hesaplama ve kalan çalışma süresinin görsel olarak gösterilmesi desteklenir.

3. Self servis portalı, ek ücret ödemeden lisansa dahildir

Bu, portalın ayrı olarak lisanslandığı piyasadaki birçok çözümden farklıdır. Portalda bir yapay zeka asistanı bulunur: bir sinir ağı, bilgi tabanında ve bilinen hatalarda bir cevap arar, talebi sınıflandırır ve gerekirse doğru kategoride otomatik olarak bir bilet oluşturur.

4. Programlama gerektirmeyen esnek süreç yapılandırması

Tiket yaşam döngüsü, eskalasyon ve bildirim kuralları, zorunlu alanlar, onaylar ve durum değişikliklerine ilişkin otomatik eylemlerin tümü, kodsuz/az kodlu araçlarla yapılandırılabilir. Gerektiğinde, JavaScript aracılığıyla kapsamlı özelleştirme yapılabilir.

5. Yapılandırma yönetimi (CMDB)

Donanım, yazılım, lisanslar, ağ cihazları, öğeler arasındaki ilişkiler ve değişiklik geçmişini içeren tek bir veritabanı.

6. Entegrasyonlar

Active Directory / LDAP, e-posta sistemleri (Exchange, Gmail), telefon sistemleri, mesajlaşma uygulamaları, izleme sistemleri (Zabbix, Nagios), ERP ve muhasebe sistemleri ile diğer tüm sistemlere bağlanmak için bir REST API.

Servis masası biletleme yazılımı nasıl seçilir

Bir bilet sistemi seçmek, şirketinizin önümüzdeki yıllarda nasıl çalışacağını etkileyecek bir karardır. Aşağıda, şirketlerin bir sistem seçerken fiilen kullandıkları kriterlere dayalı olarak, bir satıcıya sorulması gereken yedi sorudan oluşan bir kontrol listesi yer almaktadır.

Fiyat ve toplam sahip olma maliyeti (TCO) genellikle en önemli kriterdir; bunu kullanıma hazır işlevsellik ve yapılandırma esnekliği izler. Tek bir parametreye göre seçim yapmamak önemlidir: özelleştirme imkanı kısıtlı ucuz bir çözüm, pahalı yeniden çalışma gerektirirken, aşırı özellik yüklü bir sistem ise uzun bir uygulama süreci ve düşük benimseme oranı anlamına gelir.

Servis masası uygulama aşamaları: denetimden lansmana

Tam bir hizmet masası uygulamasının gerçekçi bir zaman çizelgesi 2–3 aydır ve çoğu şirket bu süreyi hedefler. Birçoğu resmi bir gereksinim belirtimi olmadan gelir ve bu sorun değildir: iyi bir uygulama, bir belirtimle değil, bir denetimle başlar.

1. Aşama. Denetim ve hazırlık (2–3 hafta)

Herhangi bir şeyi otomatikleştirmeden önce, süreçlerin şu anda nasıl işlediğini anlamanız gerekir: talepler nasıl geliyor, kimler ve nasıl işliyor, işleme ne kadar sürüyor ve darboğazlar nerede? Bu, kilit konumdaki çalışanlarla görüşmeler ve kullanıcı anketlerini içerir.

Aynı aşamada proje ekibi oluşturulur: bir yönetici sponsor, bir sistem yöneticisi ve hizmet ekipleri ile kullanıcıların temsilcileri. İş biriminin katılımı olmadan uygulama, daha sonra şirket içinde yeniden “satılması” gereken bir BT projesine dönüşür.

2. Aşama. Süreç tasarımı (2–4 hafta)

Ekip, hedef durumu tanımlar: her talep türü için yaşam döngüsü (durumlar), her aşamadaki sorumlular, durumlar arasında geçiş koşulları ve eskalasyon kuralları. Buna paralel olarak hizmet kataloğu geliştirilir: BT hizmetleri, İK hizmetleri, tesis hizmetleri; her tür için bir SLA (Hizmet Seviye Anlaşması) ile birlikte.

Temel bir ilke: ilk aşamada, otomasyonu az tutmak ancak bunu iyi yapmak daha iyidir. Başlangıçta değişiklik yönetimi ve bir CMDB gerekli değildir. Birçok şirket daha sonra ESM'ye geçmeyi planlar ve bu normal bir yoldur.

3. Aşama. Sistem yapılandırması (2–3 hafta)

Dağıtım ve temel yapılandırma: organizasyon yapısı, AD/LDAP üzerinden kullanıcı içe aktarma, erişim hakları ve talep alma kanalları. Ardından süreç yapılandırması: talep türleri, yaşam döngüleri, yönlendirme, SLA’lar ve bildirimler. Hizmet kataloğu ve ilk bilgi bankası makaleleriyle self-servis portalının kurulması.

Bu aşamada, tedarikçiyi veya bir iş ortağını sürece dahil etmek mantıklıdır: profesyonel bir yapılandırma, haftalarca zaman kazandırır ve daha sonra düzeltilmesi zor olan teknik hataların riskini azaltır.

4. Aşama. Test ve pilot uygulama (1–2 hafta)

Proje ekibi tüm senaryoları kontrol eder: farklı kanallardan talep oluşturma, farklı talep türlerini işleme, bildirimler, SLA’lar ve raporlar. Ardından 1–2 departmanda (20–30 kişi) bir pilot uygulama başlatılır, geri bildirimler toplanır ve sorunlar giderilir. Paralel olarak, talimatlar hazırlanır ve destek ekibi eğitilir (2–4 saat).

5. Aşama. Başlatma ve istikrar sağlama (1–3 ay)

Hizmete sunumdan bir hafta önce bir farkındalık kampanyası düzenleyin: çalışanlara neyin neden değişeceğini açıklayan bir mesaj gönderin. "Yumuşak bir başlangıç" önerilir: ilk iki hafta boyunca talepler hem eski yöntemle hem de yeni sistem üzerinden kabul edilir. Bu, kullanıcıların stresini azaltır ve uyum sağlamaları için zaman tanır.

Hizmete sunumdan sonra düzenli olarak SLA uyum oranı, ortalama çözüm süresi, kullanıcı memnuniyeti ve bilgi bankası aracılığıyla çözülen taleplerin oranını izleyin. İlk ayda proje ekibi haftalık, daha sonra aylık olarak toplanır.

6. Aşama. ESM’ye Geçiş

BT süreçleri istikrar kazandıktan sonra, çoğu şirket diğer departmanları (İK, tesis yönetimi, muhasebe ve hukuk) sisteme dahil etmeye başlar. Bu, şirketin tüm iç hizmetlerini yönetmek için tek bir platform olan ESM’ye geçiş sürecidir.

Yaygın uygulama hataları

1. Süreçleri resmileştirmeden otomasyon yapmak. Süreçler belgelenmezse, sistem mevcut kaosu olduğu gibi sabitler. Öncelikle kimin neyden sorumlu olduğunu ve hangi SLA'ların gerçekçi olduğunu belirlemeniz gerekir; ancak bundan sonra bunu platforma aktarabilirsiniz.
2. Başlangıçta aşırı karmaşıklık. Her özelliği aynı anda yapılandırmaya çalışmak, ekibi aşırı yükler ve lansmanı yavaşlatır. Temel talep alımı, kayıt ve atama ile başlamak en iyi stratejidir.
3. Hizmete başlattıktan sonra eğitim veya destek sağlanmaması. Bir hizmet masası sürekli ilgi gerektirir: metriklerin düzenli analizi, geri bildirimlerin toplanması, bilgi tabanının güncellenmesi ve verilere dayalı olarak süreçlerin optimize edilmesi.

Özet

Hizmet masası, bir şirketteki tüm talepleri merkezi olarak yönetmek, kaydetmek ve takip etmek için kullanılan bir yazılımdır. Düzgün bir şekilde uygulanan bir sistem, otomatik talep kaydı ve yönlendirme, SLA izleme, kullanıcılar ve yönetim için şeffaflık ve süreç optimizasyonu için analitik sağlar.

Ekonomik etkisi ölçülebilir: uzmanlar zaman kazanır, SLA uyumu artar, tekrarlanan talep sayısı azalır ve uygulamanın maliyeti kendini amorti eder.

Uygulamanın başarısı üç şeye bağlıdır: yapılandırma başlamadan önce süreçleri anlamak ve resmileştirmek, ekibin katılımı ve bir tedarikçinin sunumundaki en uzun özellik listesi yerine işletmenin gerçek ihtiyaçlarına uygun bir sistem seçmek.