> tpl_svc_005
Hizmet Talebi Kataloğu ve Karşılama Tasarımı
Standartlaştırılmış self-servis talep kataloglarını, yapılandırılmış giriş formlarını, otomatik onay hiyerarşilerini, kimlik ve bulut sağlama iş akışlarını, karşılama SLA'lerini ve self-servis memnuniyet takibini tanımlayan kurumsal BT hizmet talebi yönetim mimarisi.
Self-servis iş akışlarını, onay zincirlerini ve otomatik sağlamayı standartlaştıran ITIL 4 uyumlu hizmet talep kataloğu çerçevesi.
Önemli Teknik Doküman Şablonu ve Hukuki Uyarı
TinyCTO.tv Teknik Doküman Şablon Bildirimi: Bu şablon genel eğitim ve operasyon amaçlı bir başlangıç materyalidir. Hukuki, vergisel, muhasebesel, yatırım, satın alma, mevzuat, güvenlik veya sertifikasyon danışmanlığı değildir. Gereklilikler ülkeye, kuruma, sözleşmeye ve riske göre değişir. Kullanmadan önce yetkin uzmanlarla gözden geçirip uyarlayın.
Çözülen Üretim Problemi
Erişim, bulut bilişim, yazılım lisansları ve ekipmanlar için e-posta ve sohbet üzerinden yapılan rastgele, yapılandırılmamış talepler ciddi operasyonel tıkanıklıklara, güvenlik denetimi uyumsuzluklarına ve kullanıcı memnuniyetsizliğine yol açar.
Ne Zaman Kullanılmalı?
- •ServiceNow veya Jira Service Management üzerinde kurumsal bir BT self-servis portalı tasarlayıp yayınlarken
- •Standart talep türlerini (donanım, SaaS lisansları, veritabanı erişimi, bulut korumalı alan sağlama) kurallara bağlarken
- •Çok katmanlı onay zincirlerini ve Okta veya Active Directory üzerinden sıfır temaslı kimlik sağlama hatlarını otomatikleştirirken
Ne Zaman Kullanılmamalı?
- •Beklenmedik sistem kesintileri, yazılım hataları veya performans bozulmalarında (Olay Yönetimi TPL-OPS-007 kullanın)
- •Canlı ortamı etkileyen karmaşık mimari değişiklikler veya yazılım dağıtımlarında (Değişiklik Kontrolü TPL-SVC-006 kullanın)
5 Şablon Bölümü ve Yapısal İskelet
Hizmet maddelerinin Kullanıcı Erişimi ve Kimlik, Donanım ve Çalışma Alanı, Bulut ve Geliştirici Araçları ve Ticari SaaS Lisansları olarak net tanımlarla sınıflandırılması.
İş gerekçesini, masraf merkezi tahsisini, talep edilen süreyi ve yönetici ön onayını toplayan yapılandırılmış dinamik formların tasarlanması.
Tek aşamalı ve çok aşamalı onaylar (Yönetici -> Kaynak Sahibi -> CISO) ile düşük riskli, bütçelenmiş kalemler için sıfır temaslı otomatik onay kuralları.
Onay sonrası sıfır temaslı sağlama yapmak için ITSM platformlarının Okta SCIM, Terraform Cloud, Active Directory ve SaaS API'leri ile entegrasyonu.
Talep karmaşıklığına göre SLA süreleri (ör. Standart Erişim: 2 saat; Donanım: 48 saat; Özel Bulut Ortamı: 24 saat) ve eskalasyon yolları.
Doldurma ve Uygulama Yönergeleri
Bağımsız İnceleme ve Onay Kontrol Listesi
- Tüm zorunlu bölümler dolduruldu
- Gizli anahtar veya parola içermiyor
- Yönetici sponsor onayı alındı
Hizmet Talebi Kataloğu ve Karşılama Tasarımı - Örnek Vaka Analizi
Örnek Organizasyon: Küresel Fintek Kurumsal Çalışma Alanı ve Bulut Platform Ekibi
Küresel Fintek Kurumsal Çalışma Alanı ve Bulut Platform Ekibi için eksiksiz operasyonel uygulamayı gösteren gerçek dünya vaka analizi.
- •ServiceNow üzerinde 64 farklı BT hizmet kalemi standartlaştırılarak yapılandırılmamış e-posta talepleri %94 azaltıldı
- •Onaylı 22 SaaS aracı için Okta SCIM otomatik karşılama kurularak erişim sağlama süresi 3 günden 4 dakikaya indirildi
- •12 ülkede yeni işe alım gecikmelerini önleyen otomatik 48 saatlik onay devir mekanizması kodlandı
Sıkça Sorulan Sorular
Hizmet Talebi (Service Request) ile Olay (Incident) arasındaki kesin operasyonel fark nedir?
Olay (Incident), acil müdahale gerektiren plansız bir kesinti veya hizmet kalitesinde bozulmadır (ör. veritabanının çökmesi, e-posta kesintisi). Hizmet Talebi (Service Request) ise standart prosedürler ve belirlenmiş SLA süreleri ile yönetilen rutin bir hizmet, varlık, erişim veya bilgi talebidir (ör. yeni dizüstü bilgisayar, GitHub depo erişimi, test ortamı açılması).
Otomatik sıfır temaslı sağlama boru hatları en az ayrıcalık (least-privilege) güvenliğini nasıl korur?
Sıfır temaslı sağlama, önceden tanımlanmış RBAC yetki matrislerine ve kimlik yönetişimine dayanır. Kullanıcı erişim istediğinde portal rol uygunluğunu doğrular. Yönetici SSO/MFA ile onayladığında, otomatik bir webhook Okta SCIM veya Terraform'u tetikleyerek süreli erişim tanır; bu işlem manuel sistem yöneticisi müdahalesi olmadan denetlenebilir bir kayıt oluşturur.
Düşük riskli hizmet talepleri neden manuel onay zincirlerini baypas etmelidir?
Düşük riskli ve düşük maliyetli talepler (ör. salt okunur Confluence erişimi, standart ofis ekipmanı, şifre sıfırlama) yöneticilerde onay yorgunluğu yaratır ve çalışanları bekletir. Bütçelenmiş standart işler için otomatik onay mekanizması kurmak hızı artırırken, insan gözetimini yüksek riskli veri ve bulut erişimlerine saklar.
Teknik Doküman Şablon Paketi
Giriş GerekliTüm boş şablonları, işlenmiş senaryoları ve doğrulama manifestolarını tek bir arşivde indirin.
Yetkili Standartlar ve Kaynaklar
- ITIL 4 Practice Guide: Service Request ManagementAXELOS • OFFICIAL REQUIREMENT
- ISO/IEC 20000-1:2018 Information technology — Service managementISO • OFFICIAL REQUIREMENT
- NIST SP 800-53 Rev. 5: Access Control (AC-2 Account Management)NIST • OFFICIAL REQUIREMENT