Arıza ve talebin mesajlaşma uygulamasından, koridordan ve telefondan değil tek kayıttan geldiği bir düzen kuruyoruz. Her talep önceliklenir, sahibi bellidir, süresi ölçülür. Aynı yapıyı yalnızca bilgi işlemde değil; insan kaynakları, idari işler ve bakım taleplerinde de çalıştırırız. Kurumsal hizmet yönetimi (ESM) budur.
Bir fabrikada bilgi işlemin günü genelde şöyle geçer: sabah birinin yazıcısı çalışmaz, öğlene doğru üretimdeki bir terminal takılır, ikindi vakti muhasebeden e-posta gelir, akşamüstü müdür koridorda yakalayıp bir şey rica eder. Talepler dört ayrı kanaldan gelir ve hiçbiri kayda geçmez. Gün bittiğinde ne yapıldığı, hangi işin yarım kaldığı ve kimin hâlâ beklediği kimsenin elinde yoktur. Ertesi sabah unutulan talep bu kez şikâyet olarak geri döner. Ekip çok çalışır ama çalıştığını gösteremez. Yıl sonunda bir kişi daha veya yeni bir sunucu istendiğinde, talebi destekleyecek tek bir sayı bulunamaz ve bütçe genellikle bu yüzden reddedilir.
İkinci sorun, önceliğin sesi en yüksek çıkan kişiye göre belirlenmesidir. Üretim hattını durduran bir arıza ile bir ekran kartı isteği aynı sıraya girer; hangisinin önce yapılacağına o an odada kim varsa ona göre karar verilir. Üçüncüsü, çözümün kişide kalmasıdır: aynı hata altıncı kez yaşandığında bile nasıl çözüldüğü yazılı bir yerde durmaz, o işi bilen kişi izinliyse iş bekler. Dördüncüsü, değişikliklerin habersiz yapılmasıdır. Bir sunucu güncellenir, bir yazılım sürümü çıkılır, ardından üretimde beklenmedik bir sorun başlar ve neyin değiştiğini kimse hatırlamaz. Bu dört sorunun ortak noktası aynıdır: kayıt yokluğu. Kayıt olmadığı için ne öncelik verilebilir, ne bilgi paylaşılabilir, ne de geriye dönüp neyin ne zaman değiştiği görülebilir.
BT hizmet yönetimi (ITSM), bilgi işlemin yaptığı işi dağınık işler olarak değil hizmetler olarak ele alan yaklaşımdır. Her talep ve arıza bir kayda dönüşür; sınıflandırılır, önceliklendirilir, bir sahibe atanır ve çözüm süresi ölçülür. Tekrar eden arızalar problem kaydına bağlanarak kök nedeni araştırılır; sistemlerde yapılacak değişiklikler önceden planlanır ve kaydedilir; sık sorulanlar bilgi bankasına yazılır. Türkçede de sıkça kullanılan Help Desk, yani destek masası, bu yapının ilk kademesidir: talebin karşılandığı ve basit çözümlerin verildiği yer. ITSM ise destek masasının etrafındaki bütün süreci kapsar. Kurumsal hizmet yönetimi (ESM) ise aynı motorun bilgi işlem dışına taşınmasıdır: insan kaynakları, idari işler, bakım ve kalite birimlerine gelen iç talepler de aynı kayıt, öncelik ve süre mantığıyla yürür.
Sınırı baştan çizelim. Saha servis yönetimi (FSM) ile bu sistem sık karıştırılır ama farklıdırlar: FSM müşteriye giden teknisyenin rotasını, mobil iş emrini, kullandığı parçayı ve garanti kapsamını yönetir; buradaki sistem ise ağırlıklı olarak kurum içi hizmet masasıdır. İkisi birbirine bağlanabilir, ancak aynı şey değildir. İkinci dürüstlük noktası şudur: piyasada olgun hazır ITSM ürünleri vardır ve ihtiyacınız standartsa doğru karar çoğu zaman onlardan birini kullanmaktır; bunu açıkça söyleriz. Özel geliştirme, talep akışınız üretim süreçlerinize gömülüyse, ESM tarafında kendinize özgü akışlarınız varsa veya verinin kurum dışına çıkmaması gerekiyorsa anlamlı olur. Bu değerlendirmeyi keşifte birlikte yapar, sonucu ne olursa olsun açıkça paylaşırız.
Birkaç kişiyle geniş bir kullanıcı kitlesine ve üretim sistemlerine bakan ekipler. Buradaki asıl kazanç, talebin kaybolmaması ve neyin önce yapılacağının tartışmasız belli olmasıdır. İkinci kazanç ise iş yükünün ölçülebilir hale gelmesidir; yatırım ve kadro talepleri ilk kez sayıya dayandırılabilir, tahmine değil kayda bakılarak konuşulur.
Şube, depo veya farklı tesisleri olan, gece vardiyasında da destek gereken şirketler. Talebin hangi lokasyondan geldiği, o saatte kimin nöbetçi olduğu ve devrin nasıl yapılacağı sistemde tanımlıdır. Vardiya devrinde sözlü aktarıma kalan bilgi, bu yapıda açık kayıtlarla birlikte teslim edilir; gece başlayan bir işin sabah nerede kaldığı aranmak zorunda kalınmaz.
İzin, zimmet, araç, yemek, servis, satın alma talebi gibi iç isteklerin e-posta ve mesajla yürüdüğü yapılar. Kurumsal hizmet yönetimi (ESM) yaklaşımıyla bu talepler de aynı motorda, kendi formları ve onay kademeleriyle çalışır. Çalışan tek bir yerden talep açar, hangi birime gittiğini bilmesi gerekmez.
Yazılım, otomasyon veya teknik servis işi yapan, dışarıya destek sözleşmesiyle hizmet veren firmalar. Burada hizmet seviyesi taahhüdü sözleşmeye bağlıdır; yanıt ve çözüm sürelerinin ölçülüp raporlanabilmesi gerekir. Müşteri portalı, talebin durumunu telefonla sormayı büyük ölçüde ortadan kaldırır ve sözleşme yenilemelerinde elinizde tartışmasız bir performans kaydı bulunmasını sağlar.
| Yetenek | Ne sağlar |
|---|---|
| Tek kayıt noktası ve çok kanallı talep toplama | Talep; web portalı, e-posta, makine üzerindeki karekod veya telefonla arayan kullanıcı adına ekip tarafından açılabilir. Kanal ne olursa olsun sonuç aynıdır: numaralı bir kayıt. Kullanıcı kendi taleplerinin durumunu görür ve tekrar sormak zorunda kalmaz. Kayıt dışı iş kabul etmemek, sistemin işlemesinin tek şartıdır ve bunu baştan konuşuruz. |
| Sınıflandırma, öncelik ve otomatik atama | Her talep türüne göre sınıflandırılır; öncelik, etkinin genişliği ile aciliyetin birlikte değerlendirilmesiyle belirlenir. Üretim hattını durduran bir arıza ile tek kullanıcıyı etkileyen bir istek aynı sıraya girmez. Tanımlı kurallar sayesinde talep, konusuna ve lokasyonuna göre doğrudan ilgili ekibe veya kişiye düşer; kayıtları gün boyu elle dağıtan bir kişiye ihtiyaç kalmaz. |
| SLA, süre ölçümü ve eskalasyon | Talep türü ve önceliğe göre yanıt ve çözüm süresi hedefleri (SLA) tanımlanır. Süre işlemeye başlar, hedefe yaklaşan kayıtlar uyarı üretir, aşılan kayıtlar bir üst kademeye taşınır. Ölçümde çalışma saatleri, vardiya düzeni ve resmî tatiller hesaba katılır; kullanıcıdan bilgi beklenen süre ayrı tutulur. Dış müşteriye hizmet veriliyorsa aynı ölçüm sözleşme raporlamasının temeli olur. |
| Bilgi bankası ve tekrar eden sorunlar | Çözülen kayıtlardan bilgi bankası maddeleri üretilir; benzer bir talep açıldığında ilgili çözüm önerilir ve kullanıcı bazı sorunları kendi çözebilir. Sürekli tekrar eden arızalar tek tek kapatılmak yerine bir problem kaydı altında toplanır ve kök nedeni araştırılır. Böylece aynı işi altıncı kez yapmak yerine sebebi ortadan kaldırma imkânı doğar. |
| Değişiklik yönetimi ve bakım penceresi | Sunucu güncellemesi, sürüm geçişi, ağ değişikliği gibi işler önceden kaydedilir, etkilenen sistemler ve geri dönüş planı yazılır, onaya sunulur ve bakım penceresine yerleştirilir. Değişiklik takvimi herkese açıktır. Bir sorun çıktığında o dönemde ne değiştiğinin listesi elde bulunur; bu, arıza aramanın en çok zaman kazandıran adımıdır. |
| ESM: bilgi işlem dışındaki talepler | Aynı motor üzerinde insan kaynakları, idari işler, bakım ve kalite birimleri için ayrı hizmet katalogları ve formlar tanımlanır. Zimmet talebi, araç isteği, tesis arızası veya doküman talebi de numaralanır, önceliklenir ve süresi ölçülür. Her birim yalnızca kendi kayıtlarını görür; çalışan ise tek bir yerden talep açar. |
| Varlık bağlantısı ve raporlama | Talepler cihaz, kullanıcı, lokasyon ve sistemle ilişkilendirilir; böylece hangi cihazın sürekli sorun çıkardığı ve hangi sistemin en çok talep ürettiği görülür. Yönetim raporları açılan ve kapatılan kayıt sayısını, ortalama çözüm süresini, kategori dağılımını ve SLA uyumunu gösterir. Bu raporlar kadro ve yatırım kararlarının dayanağı olur. |
Hangi taleplerin geldiğini, kimden geldiğini, hangi kanaldan ulaştığını ve bugün nasıl çözüldüğünü birlikte çıkarırız. Bu çalışmadan bir hizmet kataloğu doğar: bilgi işlemin gerçekte hangi hizmetleri verdiği ilk kez yazılı hale gelir. Keşif genellikle bir ila iki hafta sürer ve projenin kapsamını da bu adım belirler.
Etki ve aciliyet matrisi, öncelik seviyeleri, hedef süreler, çalışma takvimi ve eskalasyon kademeleri yönetimle birlikte kararlaştırılır. Bu adım teknik değil yönetsel bir adımdır ve sonradan değiştirilmesi en zor olan kısımdır, çünkü ekiplerin beklentisini doğrudan belirler. Kurallar yazılı olarak onaylanmadan geliştirmeye geçmeyiz.
Talep portalı, e-posta alımı, bildirimler, kimlik doğrulama ve varlık bağlantıları kurulur; kısa aralıklarla çalışan sürüm gösterilir. İlk kullanılabilir sürüm, kapsama göre genellikle altı ila on hafta arasında ortaya çıkar. Bu sürümde hedef, tüm süreçleri birden kurmak değil talep akışını uçtan uca düzgün çalıştırmaktır; problem ve değişiklik yönetimi sonraya bırakılır.
Tek bir lokasyon veya tek bir birimle başlanır. Bu dönemde en sık gelen taleplerin çözümleri bilgi bankasına yazılır, formlar sadeleştirilir ve öncelik kuralları gerçek kayıtlarla test edilir. Pilotun amacı hem ekibin hem kullanıcıların sisteme güvenmesini sağlamaktır; kapsam ancak bu sağlandıktan sonra diğer birimlere genişletilir.
Tüm lokasyonlar devreye alınır, raporlar açılır ve istenirse insan kaynakları, idari işler ve bakım talepleri aynı sisteme taşınır. Değişiklik yönetimi bu aşamada eklenir. Sonrasında bakım kapsamında yeni hizmet türleri, kurallar ve entegrasyonlar sisteme işlenir. Kaynak kod, veri tabanı ve biriken talep geçmişi sizde kalır.
Çoğu şirket için hazır ürün doğru karardır ve bunu size açıkça söyleriz; standart bir destek masası ihtiyacını karşılamak için sıfırdan yazılım geliştirmek gereksiz maliyettir. Özel geliştirme şu durumlarda anlamlıdır: talep akışınız üretim veya kalite süreçlerinize gömülüyse, kurum dışına veri çıkmaması gerekiyorsa, kullanıcı sayısına bağlı lisans maliyeti sürdürülemez hale geldiyse ya da ESM tarafındaki akışlarınız hazır ürünlerin kalıplarına sığmıyorsa. Keşifte bu değerlendirmeyi birlikte yaparız.
Değil. Saha servis yönetimi müşteriye giden teknisyenin işidir: randevu ve rota planı, mobil iş emri, kullanılan yedek parça, garanti ve sözleşme kapsamı, müşteri imzası. Buradaki sistem ise kurum içi hizmet masasıdır: çalışanlardan gelen talep ve arızaların kaydı, önceliği, süresi ve çözümü. İki sistemi birbirine bağlamak mümkündür ve bazı firmalarda gerekir, ancak birini kurup diğerinin yerine saymak çalışmaz.
Bu, hizmet masası projelerinin en sık takıldığı yerdir. İki şey birlikte yapılmalıdır. Birincisi, talep açmak mesaj atmaktan daha kolay olmalıdır: kısa form, karekodla açılan kayıt, e-postanın doğrudan talebe dönüşmesi. İkincisi, yönetimin kayıtsız işi kabul etmeme konusunda net durması gerekir. Yalnızca yazılım kurup alışkanlığın kendiliğinden değişmesini beklemek, tecrübemize göre sonuç vermiyor.
ITIL bir ürün değil, iyi uygulama çerçevesidir; bir yazılımın ona uygun olduğunu iddia etmek yerine hangi süreçlerin kurulduğunu söylemeyi tercih ederiz. Uygulamada olay, talep, problem, değişiklik ve bilgi yönetimi başlıklarını ihtiyacınız kadar kurarız. Bir orta ölçekli üretim şirketinin çerçevenin tamamını uygulamasına gerek yoktur; gereğinden ağır bir süreç kurulumu, ekibin sistemi terk etmesinin en yaygın nedenlerinden biridir.
Bu endişe haklıdır ve kurulumun nasıl yapıldığına bağlıdır. Süre hedefleri ilk dönemde ölçüm amacıyla, aksiyon zorunluluğu olmadan çalıştırılır; gerçek verimiz oluştuktan sonra hedefler birlikte belirlenir. Hedefler tepeden değil mevcut performansa bakılarak konur. Ayrıca ölçüm çift yönlü çalışır: aşırı yük, eksik kadro veya sürekli tekrar eden bir arıza da aynı raporlarda görünür hale gelir.
Yazılı bir hizmet kataloğu; çok kanallı talep toplama ve tek numaralı kayıt düzeni; etki ve aciliyete dayalı öncelik ile otomatik atama kuralları; SLA ölçümü ve eskalasyon; bilgi bankası ve problem kayıtları; değişiklik yönetimi ve bakım takvimi; istenirse insan kaynakları ve idari işler taleplerinin aynı sistemde yürümesi; yönetim raporları. Kaynak kod ve veri size aittir.
30 dakikalık keşif görüşmesinde ihtiyacınızı dinler, özele mi yoksa hazır çözüme mi ihtiyacınız olduğunu dürüstçe söyleriz.
Bilgisayar, telefon, sunucu ve ağ cihazlarını kim kullanıyor, hangi lisans ne zaman bitiyor, hangi abonelik sessizce yenileniyor; hepsini tek kayıt düzeninde toplarız. Zimmet, garanti, yenileme takvimi ve kullanım dışı bırakma aynı sistemde yürür; envanter kişisel hafızadan çıkıp kurumun kaydına geçer.
Detay →Riskleri sahibine bağlar, her riskin karşısına bir kontrol ve o kontrolün kanıtını koyarız. Politikalar sürümlü yürür, denetim bulguları terminli takip edilir, mevzuat değişikliği ilgili kişiye düşer. Kişisel veri, iş güvenliği ve çevre tarafındaki çalışmalar aynı çatı altında tek panodan okunur.
Detay →Projeleri iş kırılımına ayırır, kaynakları ve kapasiteyi görünür kılar, bütçe ile gerçekleşeni yan yana koyarız. Kilometre taşları, riskler ve kararlar aynı kayıtta durur; yönetim tüm portföyü tek panodan okur ve hangi işin öncelikli olduğunu veriye bakarak konuşur.
Detay →Tarayıcıda çalışan, kullanıcı girişiyle korunan, rol ve yetkiye göre içerik gösteren dahili sistemler ve abonelik tabanlı SaaS ürünleri tasarlıyor ve geliştiriyoruz. İşinizin gerçek akışına göre kurguluyor, kaynak kodu sizinle paylaşıyoruz.
Detay →Sahada, satışta ve müşteriyle temasta işinizi tek bir uygulamaya taşıyoruz. İhtiyacınıza göre tasarlanmış iOS ve Android uygulamalarını, çevrimdışı çalışma ve push bildirim altyapısıyla geliştirip App Store ve Google Play'de yayına alıyoruz.
Detay →İnternet kesilse bile duraksamayan, barkoda ve yerel donanıma doğrudan bağlanan, üretim sahasında ve ofiste hızlı çalışan masaüstü uygulamalar. Windows ve macOS için, kaynak kodu size ait.
Detay →
