1. Katalog Ekranı Yönlendirmesi

Dış ve iç kullanıcılara katalog oluşturma ekranlarında tavsiye ve yönlendirmelerde bulunulması.

2. Kayıt Karşılama & Rapor Desteği

İç kullanıcılara kayıt karşılama ve rapor ekranlarında tavsiye ve yönlendirmelerde bulunulması.

3. Ekran Yönlendirmesi

İlgili ekranlara yönlendirme yapılması. Örnek: "Oluşturduğum kaydın durumu nedir?" gibi sorulara yanıt olarak doğru ekrana yönlendirme.

Çok dilli destek (Türkçe/İngilizce otomatik dil algılama)

SBM'nin dış kullanıcıları arasında farklı dillerde iletişim kuranlar olabilir. Chat bot, kullanıcının yazdığı dilin Türkçe mi İngilizce mi olduğunu otomatik algılayarak o dilde yanıt vermeli. Bu sayede yabancı uyruklu çalışanlar veya uluslararası paydaşlar da sistemi rahatça kullanabilir.

Chat bot konuşma geçmişi ve öğrenme döngüsü

Bot, aynı kullanıcıyla daha önce yaptığı konuşmaları hatırlayabilmeli. Kullanıcı "dün sorduğum konu ne oldu?" dediğinde bağlamı kaybetmemeli. Ayrıca sık sorulan ama cevaplayamadığı sorular loglanarak, bilgi tabanına eklenmesi gereken konular raporlanmalı.

Fallback senaryosu — bot çözemezse canlı agent'a aktarım

Bot her soruyu çözemeyecek. Belirli bir güven eşiğinin altında kaldığında veya kullanıcı açıkça "gerçek bir kişiyle konuşmak istiyorum" dediğinde, konuşma geçmişiyle birlikte canlı bir agent'a sorunsuz aktarım yapılmalı. Agent, kullanıcının bot ile ne konuştuğunu sıfırdan sormak zorunda kalmamalı.

Proaktif bildirimler (planlı kesinti uyarısı, bakım penceresi duyurusu)

Chat bot sadece soru-cevap değil, proaktif olarak da çalışmalı. Planlı bir bakım varsa, kullanıcı Pusula'ya girdiğinde bot "Yarın 02:00-04:00 arası VPN bakımı yapılacaktır" gibi bir bilgilendirme yapabilmeli. Bu, gereksiz kayıt açılmasını önler.

1. Kayıt Bazlı Duygu Analizi

Yorum sayısı, kullanıcı üslubu ve kaydın yeniden açılma sayısı gibi parametreleri göz önünde bulundurarak kayıt bazlı kullanıcı duygu analizi yapılması.

2. Duygu Değişimi Uyarısı

Kullanıcı duygu değişimine göre agent veya yönetici uyarı bilgilendirmesinin yapılması.

3. Genel Duygu Profili

Genel kullanıcı duygu profilinin oluşturulması.

Duygu skorunun SLA önceliklendirmeye etkisi (Modül 15 ile entegrasyon)

Bir kullanıcının frustration skoru yüksekse, aynı öncelik seviyesindeki diğer kayıtların önüne alınabilir. Bu, Modül 15 Etki-Aciliyet Tavsiyesi ile birlikte çalışarak "teknik öncelik aynı ama müşteri deneyimi kritik" durumlarını yönetmeye yarar.

Departman bazlı duygu karşılaştırması

Finans departmanı mı yoksa IT departmanı mı daha memnuniyetsiz? Hangi iş birimi sürekli negatif duygu üretiyor? Bu veri, SBM yönetiminin hizmet kalitesi iyileştirmelerini hangi departmana öncelikli yönlendireceğini belirlemesine yardımcı olur.

Zaman serisi analizi — belirli dönemlerde duygu trendleri

Ay sonu kapanış dönemlerinde, sistem göçü sonrasında veya yeni bir uygulama deploy edildiğinde duygu skorları nasıl değişiyor? Zaman bazlı trend analizi, tekrarlayan sorunların kök nedenini anlamaya yardımcı olur.

CSAT anket sonuçları ile duygu skorunun korelasyon raporu

SBM zaten müşteri memnuniyet anketleri (CSAT) yapıyor olabilir. AI'ın ürettiği duygu skoru ile gerçek anket sonuçlarını karşılaştırmak, modelin doğruluğunu ölçmenin en somut yoludur. Sapma varsa model kalibre edilir.

1. Knowledge Base Sorgu Yanıtlama

Knowledge base içerisinde yer alan bilgiler kapsamında kullanıcı sorularına yanıt verme.

2. Kayıt Öncesi Yönlendirme

Kullanıcılar Pusula üzerinde kayıt oluşturmadan önce, kayıt oluşturma ekranı üzerinde kullanıcılara sorun ile ilgili yönlendirmelerde bulunulması.

KB makale kalitesi skorlaması

Her knowledge base makalesi eşit kalitede değil. Bir makale kaç kez görüntülendi, kaç kullanıcının sorununu gerçekten çözdü, kaç kez "işe yaramadı" geri bildirimi aldı? Bu metriklerle her makaleye bir kalite skoru atanır ve düşük puanlı makaleler güncelleme kuyruğuna alınır.

Kullanıcı geri bildirimi ile KB içeriğinin sürekli iyileştirilmesi

Kullanıcıya sunulan KB yanıtının altına basit bir "Bu yanıt işinize yaradı mı?" sorusu eklenmeli. Olumsuz geri bildirimler, ilgili makalenin içerik sahibine otomatik bildirim olarak gider ve iyileştirme döngüsü başlar.

KB boşluk analizi — hangi konularda makale eksik

Kullanıcılar soru soruyor ama KB'de eşleşen içerik bulunamıyorsa, bu bir "bilgi boşluğu" demektir. Sistem bu boşlukları raporlayarak "Son 30 günde 47 kullanıcı SAP yetkilendirme konusunda soru sordu ama KB'de bu konuda makale yok" gibi aksiyon alınabilir içgörüler üretmeli.

Çok kaynaklı arama (Confluence + SharePoint + Jira KB birleşik index)

SBM'nin bilgi kaynakları sadece Jira KB ile sınırlı olmayabilir. Confluence wiki'leri, SharePoint dokümanları, hatta ağ paylaşımındaki PDF'ler de bilgi kaynağı olabilir. Tüm kaynakların tek bir semantic index altında birleştirilmesi, kullanıcının doğru bilgiye ulaşma olasılığını katlayarak artırır.

1. Süreç Akışı Öğrenme & Bilgilendirme

Pusula üzerinden yer alan süreç akışlarını öğrenme ve herhangi bir olağan dışı durumda bilgilendirme yapma.

2. Mesai Dışı Aksiyon

Mesai saatleri dışında yaşanan olağan dışı durumlar ile ilgili aksiyon alma.

Anomaly baseline oluşturma süreci

Sistem "normal nedir" bilmeden anomali saptayamaz. Başlangıçta minimum 30-90 günlük veri ile bir baseline oluşturulmalı. Bu süre zarfında sistem gözlem modunda çalışır, uyarı vermez ama örüntüleri öğrenir. Hangi saatlerde kaç kayıt açılıyor, hangi kategorilerde ne sıklıkta talep geliyor — bunlar normalin tanımını oluşturur.

Yanlış pozitif oranı takibi ve geri bildirim mekanizması

Her yanlış alarm, ekibin sisteme olan güvenini azaltır. Anomaly uyarısı geldiğinde operatör "Bu gerçek bir anomali miydi?" sorusuna yanıt verebilmeli. Bu geri bildirimler modele döner ve zaman içinde yanlış pozitif oranı düşer. Hedef: yanlış pozitif oranı %5 altında tutmak.

Anomaly severity sınıflandırması

Her anomali aynı aciliyette değildir. Şifre taleplerinde %20 artış ile tüm e-posta sunucusunun çökmesi aynı ağırlıkta ele alınamaz. Anomalilere severity seviyesi atanmalı: Bilgilendirme (informational), Uyarı (warning), Kritik (critical). Her seviye farklı bildirim kanalını tetikler.

CMDB bağımlılık haritası ile kaskad etki analizi

Bir sunucuda anomali saptandığında, o sunucuya bağımlı tüm servislerin otomatik olarak listelenmesi gerekir. CMDB'deki CI bağımlılık haritası kullanılarak "Bu sunucu çökerse hangi servisler etkilenir, kaç kullanıcı impact alır?" sorusuna yanıt verilebilir.

1. Açıklama & Yorum Özetleme

Pusula üzerinde oluşturulmuş kayıtlar içerisinde yer alan uzun açıklama ve yorumların özetinin çıkartılması.

2. Yazım Kontrolü

Özet çıkarma sırasında yazım yanlışlarının kontrolü ve düzeltilmesi.

Özetin dil seviyesi ayarı (yönetici özeti vs teknik özet)

Aynı kaydın özeti farklı kitleler için farklı olmalı. Yönetici "ne oldu, ne zaman çözülecek" bilmek ister — 2-3 cümle yeter. Teknik ekip ise "hangi komponent, hangi log, hangi workaround" detayını ister. Sistem her iki formatta da özet üretebilmeli.

Özet güvenilirlik skoru (halüsinasyon riski uyarısı)

LLM tabanlı özetleme bazen kaynakta olmayan bilgiyi "uydurabiliyor" (halüsinasyon). Sistem her özetin yanına bir güvenilirlik skoru koymalı. Eğer kaynak veride belirsizlik veya çelişki varsa, özet "Dikkat: Bu özet eksik veya çelişkili verilerden üretilmiştir" uyarısı taşımalı.

Çok dilli özet desteği

Kayıt Türkçe açılmış ama yönetici İngilizce özet istiyor olabilir — özellikle global raporlamalarda. Sistem aynı özetin farklı dillerde versiyonunu üretebilmeli.

Özet geçmişi ve versiyonlama

Bir kayda yeni yorumlar eklendikçe özet değişir. Eski özetlerin silinmemesi, versiyonlanarak saklanması gerekir. Böylece "3 gün önce durum neydi" sorusuna yanıt verilebilir ve kronolojik izlenebilirlik sağlanır.

1. Değişiklik Risk Analizi

Benzer hizmetleri, CI'ları, sürümleri içeren eski kayıtlardan yararlanılması aracılığı ile değişiklik kayıtlarında risk analizinin yapılması ve tavsiye verilmesi.

2. Takvimsel Öneri

Değişiklik planlanması sürecinde takvimsel öneride bulunulması.

Risk skoru hesaplama formülünün şeffaflığı (Explainable AI)

Sistem "Risk: %85" dediğinde mühendis "neden?" diye soracaktır. Kara kutu bir skor güven oluşturmaz. Risk skoru; geçmiş kaç benzer değişiklikte sorun yaşandı, etkilenen CI'ların kritiklik seviyesi, değişikliği yapacak ekibin deneyimi gibi parametrelerin ağırlıklı ortalaması olarak açıklanabilir olmalı.

Değişiklik başarı/başarısızlık geçmişi ile model doğruluk metrikleri

Model "yüksek risk" dediği değişikliklerin gerçekten kaçı sorunlu oldu? "Düşük risk" dediğinin kaçı sürpriz kesintiye yol açtı? Bu metrikler aylık olarak raporlanmalı ve modelin kalibrasyonu sürekli iyileştirilmeli.

CAB (Change Advisory Board) entegrasyonu

Risk skoru yüksek olan değişiklikler otomatik olarak CAB gündemine eklenmeli. Toplantı öncesi CAB üyelerine risk raporu, etkilenen CI'lar ve önerilen bakım penceresi otomatik olarak dağıtılmalı.

Rollback planı önerisi

Her değişiklik için "eğer başarısız olursa ne yapılacak" planı kritiktir. Sistem, benzer geçmiş değişikliklerdeki rollback adımlarını analiz ederek otomatik bir rollback planı taslağı önerebilir.

1. JQL Rapor Oluşturma

Jira SM ürünü tarafından kullanılan JQL (Jira Query Language) veri sorgulama dili ile oluşturulabilecek basit ve orta seviye raporların oluşturulması.

2. Mevcut Rapor Yönlendirme

Pusula içerisinde halihazırda oluşturulmuş raporları analiz ederek, kullanıcıları (mevcut ise) ilgili rapora yönlendirme.

JQL düzenleme ve öğrenme döngüsü

Sistem JQL ürettiğinde kullanıcı bunu düzenleyebilmeli. Kullanıcının düzeltmesi modele geri bildirim olarak döner: "Kullanıcı 'Kritik' dediğinde Priority = Critical değil, Priority = Highest kastediyor" gibi SBM'ye özel dil kalıpları öğrenilir.

Rapor şablonları kütüphanesi

Sık kullanılan rapor tipleri (haftalık SLA özeti, aylık incident trendi, ekip bazlı workload) şablon olarak kaydedilmeli. Kullanıcı "geçen ayki gibi bir rapor oluştur" dediğinde sistem şablondan yola çıkmalı.

Zamanlı rapor oluşturma (scheduling)

Yönetici her Pazartesi sabahı aynı raporu istiyor olabilir. Raporlar zamanlanabilir olmalı ve otomatik olarak e-posta veya Teams kanalına gönderilebilmeli.

Rapor paylaşım ve export desteği (PDF/Excel)

Oluşturulan raporların sadece Jira içinde değil, PDF veya Excel formatında export edilebilmesi gerekir. Yönetim toplantılarında veya dış paydaş sunumlarında kullanılabilmesi için bu kritik bir ihtiyaçtır.

1. Sorun Analizi & İlişkilendirme

Sorun kayıtları analiz edildikten sonra içerik bazlı ilişkilendirilmesi. Tekrar eden veya çözülmesinde zorluk yaşanılan sorunların tespit edilmesi.

2. Problem Kaydı Oluşturma / Tavsiye

Problem kaydının otomatik oluşturulması veya problem kaydının oluşturulması konusunda tavsiyede bulunulması.

Cluster eşik değerinin konfigüre edilebilirliği

Kaç benzer incident bir araya gelince problem kaydı önerilmeli? Bu eşik sabit olmamalı. Bazı kategorilerde 5 incident yeterli olurken, bazılarında 20 gerekebilir. SBM yöneticileri bu eşikleri kategori bazında konfigüre edebilmeli.

Known Error Database (KEDB) entegrasyonu

Oluşturulan problem kaydı, bilinen hata veritabanında (KEDB) zaten kayıtlı bir hataya karşılık geliyor olabilir. Sistem, yeni problem kaydını açmadan önce KEDB'de eşleşme kontrolü yaparak mükerrer kayıt oluşturulmasını önlemeli.

Problem kaydı sonrası otomatik root cause template'i

Problem kaydı açıldığında, içine otomatik olarak bir kök neden analizi (RCA) şablonu yerleştirilmeli: "5 Neden Analizi", "Balık Kılçığı Diyagramı" gibi. Mühendis boş bir sayfaya değil, yapılandırılmış bir template'e yazmaya başlar.

İlişkilendirilen kayıtların kullanıcılarına toplu bilgilendirme

45 incident tek bir problem kaydına bağlandığında, bu 45 kaydın sahiplerine otomatik bilgilendirme yapılmalı: "Sorununuz tespit edilmiş bir altyapı problemiyle ilişkilendirildi, ekipler çalışıyor." Bu, kullanıcıların tek tek "ne oldu?" diye sormasını engeller.

1. Alan Tavsiyesi

Kayıt oluşturma ekrkullanıcılara doldurulması istenen alanlar hakkında tavsiye verilmesi.

2. Yazım Düzeltme

Kayıt oluşturma ekryazım yanlışlarının düzeltilmesi.

3. Etki & Aciliyet Tavsiyesi

Etki ve aciliyet alanları doldurulurken kullanıcıya tavsiyede bulunulması.

Tavsiye kabul/ret oranı takibi (model kalibrasyon metrikleri)

Sistem kategori tavsiyesi verdiğinde kullanıcı bunu kabul mü ediyor, reddedip başka bir şey mi seçiyor? Kabul oranı %70 altına düşerse model yeniden kalibre edilmeli. Bu metrik, sistemin gerçekten değer üretip üretmediğinin en net göstergesidir.

Kategori taksonomisi güncelleme mekanizması

Yeni bir uygulama devreye alındığında veya organizasyon yapısı değiştiğinde kategori ağacı da güncellenmeli. Sistem, mevcut kategorilere uymayan kayıtları tespit ederek "Son 30 günde 120 kayıt mevcut kategorilere sığmadı — yeni bir kategori öneriyorum" gibi içgörü üretmeli.

Zorunlu alan tamamlama oranı iyileştirme raporu

AI tavsiyesi devreye girdikten sonra, kullanıcıların zorunlu alanları doğru doldurma oranı ne kadar arttı? Bu metrik, modülün ROI'sini doğrudan ölçer ve yönetime sunulabilecek somut bir başarı göstergesidir.

1. Otomatik Knowledge Base Besleme

Pusula üzerinde oluşturulmuş ve kapatılmış kayıtlar üzerinde yer alan yorum, kapanış bilgisi vb. alanlar içerisindeki bilgiler analiz edilerek knowledge base'in beslenmesi.

Makale kalite skoru ve minimum kalite eşiği

Otomatik oluşturulan her makaleye bir kalite skoru atanmalı. Skor; içeriğin uzunluğu, yapısal bütünlüğü (sorun-çözüm-adımlar formatı), kaynak verinin zenginliği gibi faktörlerden hesaplanır. Eşik altı makaleler otomatik yayınlanmaz, insan onayına yönlendirilir.

Duplikasyon kontrolü — aynı konuda zaten makale var mı

Sistem yeni bir KB makalesi oluşturmadan önce, mevcut KB'de semantik olarak benzer bir makale olup olmadığını kontrol etmeli. Varsa, yeni makale oluşturmak yerine mevcut makaleyi güncellemeli veya birleştirme önerisi sunmalı.

Makale kategori/etiket önerisi

Oluşturulan makaleye otomatik olarak kategori, etiket ve ilgili CI ataması yapılmalı. Bu, ileride Knowledge Discovery modülünün (Modül 3) makaleyi doğru sorulara eşleştirmesini kolaylaştırır.

Makale kullanım metrikleri

Bir makale oluşturulduktan sonra kaç kez görüntülendi, kaç kayıtta referans verildi, kaç kullanıcının sorununu çözdü? Bu metrikler, KB'nin gerçek değerini ölçer ve düşük performanslı makalelerin iyileştirilmesini tetikler.

1. Katalog Değişikliği Önerisi

Kayıt oluşturma ekranı üzerinde, kullanıcının doldurduğu başlık ve açıklama alanlarının kontrol edilmesi ve katalog değişikliği önerisi verilmesi.

2. Dinamik Destek Grubu Ataması

Atanan destek gruplarının kayıt içeriğine göre değişebilir olması.

Atama doğruluk oranı KPI'ı ve dashboard'u

AI'ın önerdiği destek grubu atamasının kaçı doğruydu, kaçı sonradan transfer edildi? Bu oran aylık olarak dashboard'da izlenmeli. Hedef: ilk atamada doğru gruba yönlendirme oranını %90 üzerine çıkarmak.

Workload balancing algoritmasının detaylandırılması

AgentiX sadece doğru gruba değil, doğru kişiye atama yapacaksa, mühendislerin anlık iş yükünü bilmesi gerekir. Aktif kayıt sayısı, ortalama çözüm süresi, mühendişin müsaitlik durumu (izin, toplantı) gibi parametreler hesaplamaya dahil edilmeli.

Eskalasyon zinciri önerisi

Kayıt atandıktan sonra belirli sürede çözülmezse, bir sonraki eskalasyon adımı ne? Sistem, SLA kurallarına göre "Bu kayıt 4 saattir L2'de bekliyor, L3'e eskale edilmesi gerekiyor" uyarısını otomatik üretmeli.

SLA ihlali riski olan kayıtlarda otomatik re-routing

Bir kayıt SLA ihlal eşiğine yaklaşıyorsa ve atandığı grupta çözüm ilerlemiyorsa, sistem alternatif bir gruba veya daha müsait bir mühendise re-routing önerebilmeli.

1. Kapanış Özeti Oluşturma

Pusula sistemi üzerinde kapatılmış sorun kayıtlarının analiz edilerek, kapanış özeti oluşturulması.

2. Kümelendirme Analizi

Sorun kayıtlarının derinlemesine analiz noktasında varlıklar, kayıt tipleri, soru tipleri vb. kümelendirme analizlerinin yapılması.

PIR raporu ile KEDB arasında otomatik bağlantı

PIR raporu bir kök neden belirlediğinde, bu kök nedenin KEDB'de (Known Error Database) kayıtlı olup olmadığı kontrol edilmeli. Kayıtlıysa PIR otomatik bağlanır; değilse yeni bir KEDB kaydı oluşturma önerisi sunulur. Bu, problem management döngüsünü tamamlar.

MTTR/MTTA metriklerinin otomatik hesaplanması

PIR raporuna MTTR (Mean Time to Resolve) ve MTTA (Mean Time to Acknowledge) değerleri otomatik olarak dahil edilmeli. Mühendis bunları elle hesaplamak zorunda kalmamalı. Kayıt açılış-atanma-çözüm zaman damgalarından otomatik hesaplanır.

Benzer geçmiş incident'larla karşılaştırma

PIR raporu yazılırken, geçmişte benzer kök nedene sahip incident'lar otomatik listelenmeli. "Bu tarz arıza son 6 ayda 3 kez yaşandı, ortalama çözüm süresi 4.2 saat" gibi karşılaştırmalı veri, alınan derslerin kalitesini artırır.

PIR kalite skoru

Oluşturulan PIR raporunun kalitesi ölçülmeli: Kök neden belirlenmiş mi, aksiyon maddeleri yazılmış mı, sorumlu atanmış mı, takip tarihi var mı? Eksik bırakılan alanlar için uyarı verilmeli. Bu, PIR'ın bir formalite değil gerçek bir iyileştirme aracı olmasını sağlar.

1. Aktif Kayıt Kontrolü

Kullanıcının oluşturmak istediği sorun ve istek kaydı içeriği kontrol edilerek, Pusula üzerinden konu ile ilgili halihazırda aktif kayıt var mı kontrol edilmesi.

2. Participant Ekleme

İlgili kayıt bulunması durumunda kullanıcının izleyici olarak kayda eklenmesi.

Eşleşme güven skoru gösterimi

Kullanıcıya "Açık bir kayıt bulundu" dendiğinde, eşleşme ne kadar güvenilir? "%92 benzerlik" gibi bir skor gösterilmeli. Düşük benzerlik skorunda kullanıcıya eşleşmeyi kabul etme zorunluluğu olmamalı, kendi kararını verebilmeli. Bu şeffaflık, kullanıcı güvenini artırır.

Birden fazla aktif kayıt eşleştiğinde seçim ekranı

Kullanıcının sorunu birden fazla açık kayıtla eşleşebilir. Örneğin hem "VPN kesintisi" hem "ağ yavaşlığı" kaydıyla benzerlik çıkabilir. Bu durumda kullanıcıya bir seçim ekranı sunularak hangi kayda katılmak istediği sorulmalı.

"Benzer ama farklı" durumlarını ayırt etme hassasiyeti

Kullanıcının "Outlook açılmıyor" sorunu, mevcut "Exchange sunucu kesintisi" kaydıyla benzer görünür ama aslında kullanıcının yerel Outlook kurulumu bozuk olabilir. Semantik eşleştirme bağlamsal ipuçlarını (etkilenen kullanıcı sayısı, zaman, lokasyon) da değerlendirmeli.

1. Otomatik Yorum Yanıtlama

Pusula üzerinde oluşturulmuş aktif kayıtlarda kullanıcılara otomatik cevap verilmesi. Örnek: "Kaydımın son durumunu öğrenebilir miyim?" → "Kaydınız bugfix sürecindedir, en kısa sürede tarafınıza bilgi verilecektir."

2. Duyuru Şablonu Tavsiyesi

Major sorun, problem ve değişiklik kayıtlarını kontrol ederek duyuru tavsiyesi verilmesi.

Otomatik yanıtın şeffaflığı

Kullanıcı bir bot'tan mı yoksa gerçek bir mühendisten mi yanıt aldığını bilmeli. Otomatik yanıtların altına küçük bir "Bu yanıt AI asistanı tarafından oluşturulmuştur" notu eklenmelidir. Bu hem etik bir gereklilik hem de kullanıcının beklentisini doğru yönetir.

Yanıt kalite geri bildirimi

Otomatik yanıtın altına "Bu yanıt işinize yaradı mı?" butonu konulmalı. Olumsuz geri bildirimler, ilgili kaydın agent'ına bildirim olarak düşer ve insan müdahalesi tetiklenir. Ayrıca bu veriler modelin iyileştirilmesinde kullanılır.

Duyuru geçmişi ve analitik raporu

Hangi duyurular gönderildi, kaç kişiye ulaştı, duyuru sonrası kayıt açılma oranı düştü mü? Bu metrikler, duyuru mekanizmasının etkinliğini ölçer. Örneğin duyuru yapılmasına rağmen kullanıcılar hala kayıt açıyorsa, duyurunun formatı veya kanalı gözden geçirilmeli.

Duyuru hedef kitle segmentasyonu

Her duyurunun tüm şirkete gitmesi gerekmez. E-posta sunucusu sorunu sadece e-posta kullananları, SAP kesintisi sadece finans ve satın alma departmanını ilgilendirir. Duyurular, etkilenen CI'ların kullanıcı haritasına göre hedefli olarak segmente edilmeli.

1. Etki & Aciliyet Değerlendirmesi

Kayıt içeriğine, etkilenen servislere ve kullanıcı profiline göre etki ve aciliyet seviyesi tavsiyesi verilmesi.

Etki/aciliyet tavsiye kabul oranı takibi

Kullanıcılar AI'ın etki/aciliyet tavsiyesini ne oranda kabul ediyor? Eğer kullanıcılar sürekli tavsiyeyi reddedip kendi değerlerini seçiyorsa, ya model yanlış kalibre edilmiş ya da kullanıcı eğitimi eksik. Bu metrik her iki durumu da tespit etmeye yarar.

Tavsiye ile gerçek sonuç karşılaştırması (model doğruluğu)

AI "düşük etki" dediği bir kayıt gerçekten düşük etki ile mi çözüldü, yoksa sonradan major incident'a mı dönüştü? Geçmişe dönük bu karşılaştırma, modelin doğruluğunu ölçmenin en sağlıklı yoludur ve sürekli kalibrasyon için girdi sağlar.

CI kritiklik matrisinin CMDB'den otomatik beslenmesi

Etki hesaplamasının doğru olması için, hangi CI'ın ne kadar kritik olduğu bilgisi güncel olmalı. Bu veri CMDB'den otomatik çekilmeli ve "ERP sunucusu = Kritik, test sunucusu = Düşük" gibi ağırlıklar etki hesaplamasına girdi olarak kullanılmalı.

SLA sapma raporu — tavsiye dinlenmeyen kayıtlarda SLA ihlali oranı

AI "bu kayıt düşük öncelikli" demiş ama kullanıcı Kritik seçmiş. Sonuç ne oldu? Bu kayıtlarda SLA ihlali yaşandı mı? Bu rapor, AI tavsiyesinin dinlenmesinin operasyonel faydasını somut rakamlarla kanıtlar ve yönetimi ikna etmek için güçlü bir araçtır.

İş Dünyasında "Bilişsel Evrim" Başladı

Dijital dönüşüm çağı sona erdi. Artık veriyi saklayan veya kuralları uygulayan pasif yazılımların devri kapandı. Bugünün rekabet dünyası; düşünen, gören, konuşan, inisiyatif alan ve kendi kendini denetleyen "Akıllı Organizmalar" talep ediyor.

Epoch Yaklaşımı

Epoch Teknoloji ve İnovasyon A.Ş. olarak kurumunuza parça parça yazılımlar sunmuyoruz. Gücünü APA (Autonomous Process & Agency) mimarisinden alan, birbiriyle konuşan ve yaşayan bütünleşik bir "Yapay Zeka Ekosistemi" kuruyoruz.

Mimari Yaklaşım

Rakiplerimiz size araç satar, biz size Mimari sunuyoruz. Parçalarla değil, bütünle ilgileniyoruz. Sizin işiniz teknolojiyi yönetmek değil; işinizi büyütmektir. Teknolojiyi yönetmek Epoch Intelligence Platform'un işidir.

Bir kurumun en büyük varlığı verisidir; ancak işlenmemiş veri sadece bir depolama maliyetidir. Epoch/CoreX, platformun kalbindeki bilişsel motordur ve kurumun "Merkezi Sinir Sistemi" olarak görev yapar. Bu sadece bir yazılım değil, kurumunuzun Özel Zeka Altyapısıdır (Private AI Infrastructure).

Bağlamsal Zeka (Contextual Intelligence)

Kurumunuzun tüm heterojen veri ekosistemini (ERP, CRM, IoT, Loglar) analiz eder. Veriler arasındaki gizli ilişkileri kurar ve ham veriyi işleyerek "Karar Destek Zekası"na dönüştürür.

Ekosistemin Kalbi

Platformun IQ kaynağıdır. Diğer tüm modüller (X, AgentiX, Cortex, Connex) ihtiyaç duydukları öğrenme kapasitesini ve analitik gücü buradan alır. O öğrenir, diğerleri uygular.

Altyapı Olarak

Tek başına kurumunuza entegre edilir; kendi iç uygulamalarınızı besleyen özel bir zeka motoru olarak çalışır.

Güç Kaynağı Olarak

Epoch ürün ailesinin (X, AgentiX vb.) içinde gömülü olarak gelir, süreçlerinizi akıllandıran görünmez güç olur.

Rutin, kurala dayalı ve yüksek hacimli işler en yetenekli insan kaynağınızı bile köreltir. Epoch/X, kurumunuzun Dijital Yakalı Çalışanlarıdır. Bu, basit bir otomasyon değildir; Görüntü İşleme (OCR), Yapay Zeka ve RPA teknolojilerinin hibrit gücüdür.

Bilişsel Algılama

Sadece dijital veriyi değil; fiziksel dünyayı da algılar. Faturaları okur, el yazısı formları tanır, sözleşmelerdeki maddeleri ayrıştırır.

Kırılmayan Adaptasyon (Adaptive UI)

Web siteleri değişse veya arayüzler güncellense bile, görsel zekası sayesinde butonları ve alanları bir insan gibi tanır; süreç kesintiye uğramadan devam eder.

CorteX, bir raporlama aracı, klasik bir BI ekranı veya metin üreten bir yapay zekâ değildir. O, küresel Büyük Dil Modellerinin (LLM) üretken gücünü, kurumunuza özgü bağlamsal bilgi ile harmanlayan özel bir bilişsel zeka katmanıdır. Tüm veritabanlarınızı, dokümanlarınızı, iş kurallarınızı ve kurumsal hafızanızı anlayarak sizinle stratejik bir çalışma arkadaşı gibi konuşur.

A. Bağlamsal Zeka (Contextual Intelligence)

Kurumunuzun tüm heterojen veri ekosistemini (ERP, CRM, IoT, loglar, dokümanlar) anlamlandırır; gizli ilişkileri ortaya çıkararak ham veriyi karar destek zekâsına dönüştürür.

B. Diyalogsal Veri Zekası (Conversational Analytics)

Veri ile aranızdaki tüm teknik bariyerleri kaldırır. "Geçen ay Marmara Bölgesi'nde en düşük kârlılığı gösteren ürünler hangileri?" gibi doğal dil sorularını alır, SQL'i kendi yazar, veriyi çeker, analiz eder ve anlamlı yanıtı sunar. Sesli komutlarla da çalışır — klavyeye dokunmanıza gerek yok.

C. Üretken Yaratıcılık (Generative Creation)

Sadece analiz etmez — üretilmesi gerekeni üretir. Yönetim Kurulu sunumları oluşturur, finansal raporları özetler, kurumsal tonda içerikler yazar, sözleşmeleri risk açısından değerlendirir ve karmaşık veriyi görselleştirir.

D. Simülasyon ve Stratejik Öngörü (Predictive + Generative Reasoning)

Geçmiş veriyi okuyup geleceği modelleyen bir strateji asistanıdır. "Enerji maliyetleri %20 artarsa bilançom nasıl etkilenir?", "3 farklı büyüme senaryosunu karşılaştır ve risk analizini çıkart" gibi sorulara hem matematiksel hesaplama hem de stratejik yorumla yanıt verir.

Modern bir kurumda iletişim dağınıktır. E-Postalar, WhatsApp mesajları, Çağrı Merkezi kayıtları ve Web formları farklı kanallardan akar. Bu dağınıklık, denetim zafiyeti ve veri kaybı yaratır. Epoch/Connex; kanal bağımsız (Channel Agnostic) olarak akan tüm bu trafiği tek bir "Ana Omurga" üzerinde toplayan, Programlanabilir Kurallar ve Yapay Zeka'nın hibrit gücüyle yöneten merkezi iletişim mimarisidir.

Omni-Channel Entegrasyon (Kanal Bağımsız Mimari)

Kurumun dış dünyayı duyan kulaklarıdır. Sadece e-postayı değil; WhatsApp, Çağrı Merkezi (Ses), Web Formları, Chatbotlar ve İç İletişim Platformlarını tek bir güvenli tünelde birleştirir. Müşteri veya tedarikçi nereden yazarsa yazsın, Connex o veriyi yakalar, standartlaştırır ve işleme alır.

Hibrit Motor: Kural + Yapay Zeka

İletişimi yönetmek için iki farklı gücü aynı anda kullanır. Programlanabilir (Deterministik) tarafta "Fatura tutarı X'in üzerindeyse doğrudan CFO'ya ilet" gibi kesin kurallar uygulanır. Yapay Zeka (Esnek) tarafında ise "Müşteri teknik bir sorun anlatıyor ama dili karmaşık ve öfkeli; bunu Teknik Destek ekibine özetleyerek ve 'Acil' koduyla aktar" gibi anlama gerektiren işler yönetilir.

Denetim ve Uyum Kalkanı (Compliance Firewall)

Kuruma giren ve çıkan her veriyi bir "Gümrük Kapısı" titizliğiyle tarar. Kimlik Doğrulama (Anti-Spoofing), İçerik Denetimi (KVKK ihlali kontrolü) ve Duygu/Niyet Analizi (metnin satır aralarını okuma, aciliyet ölçümü) katmanlarını içerir.

Satın Alma Yönetimi İçin

Tedarikçilerin termin sürelerini, fiyat istikrarını ve yanıt hızlarını ölçen bir "Tedarikçi Karnesi"dir.

Sigorta ve Finans İçin

Acentelerin veya brokerların satış kalitesini, evrak eksikliklerini ve risk skorunu izleyen bir "Acente Performans Denetçisi"dir.

Lojistik ve Operasyon İçin

Kargo veya nakliye firmalarının SLA (Hizmet Seviyesi) uyumunu takip eden bir "Operasyonel Müfettiş"tir.

Standart yazılımlar kural uygular, Epoch/AgentiX ise karar verir. Bu platform, karmaşık süreçleri yönetebilen, düşünen, planlayan ve işbirliği yapan "Otonom Ajanlar" oluşturur.

Hedef Odaklı Çalışma

Ona "Nasıl yapacağını" değil, "Ne başaracağını" söylersiniz. Sorunu tespit eder ve çözüm senaryoları üretir.

Çoklu Ajan Mimarisi (Multi-Agent)

Departmanlar arası siloları yıkar. Satış Ajanı Lojistik Ajanıyla konuşur, Finans Ajanı risk onayı verir ve süreç insan müdahalesi olmadan uçtan uca (End-to-End) tamamlanır.