TYS Dijital Performans Paketi'ne Geçmeden Önce: MPS Şirketleri İçin Hazırlık ve Ölçüm Çerçevesi

Yönetilen yazdırma alanında çalışan bir operasyon direktörü ya da IT müdürü için en pahalı hata, bir iyileştirme çalışmasına baseline almadan başlamaktır. TYS Dijital Performans paketi gibi bir katmanı devreye almadan önce cevaplamanız gereken soru şu değildir: 'Bu paket işleri ne kadar iyileştirir?' Doğru soru şudur: 'Bugün nerede durduğumu hangi sayılarla biliyorum, ve bu sayıları ay sonra aynı metodla tekrar ölçebilir miyim?' Bu yazı bir satış broşürü değildir. Amacı, geçiş öncesi hazırlık ve ölçüm çerçevesini somut biçimde kurmaktır: önce baseline, sonra uygulama, sonra tekrar ölçüm. ## Neden önce baseline İyileşme bir farktır. Farkı gösterebilmek için iki ölçüm noktasına ihtiyacınız var: değişiklikten önce ve sonra. Bir MPS operasyonunda 'işlerin daha iyi gittiği' hissi gerçek olabilir, ama yönetim kuruluna ya da müşteriye hissi sunamazsınız. Sunabileceğiniz şey, aynı tanımla, aynı kaynaktan, aynı zaman penceresinde alınmış iki sayıdır. Baseline almanın disiplini şudur: bir metriği tanımlarken o metriğin nasıl hesaplandığını, hangi olayların sayıma dahil olduğunu ve hangilerinin dışarıda bırakıldığını yazıya dökersiniz. Aksi halde sonradan 'iyileşti' dediğinizde, karşı taraf haklı olarak 'tanımı mı değiştirdiniz, yoksa süreç mi' diye sorar. ## Hangi metrikleri baseline alırsınız MPS servis operasyonunda anlamlı ve ölçülebilir birkaç çekirdek metrik vardır: - **İlk yanıt süresi:** Bir servis talebi açıldığı an ile ekibin talebe ilk dokunuşu arasındaki süre. - **Arıza çözüm süresi (MTTR):** Talebin açılışından kapanışına kadar geçen ortalama süre. - **SLA uyumu:** Taahhüt edilen süre pencerelerine ne oranda uyulduğu. - **Talep hacmi ve dağılımı:** Cihaz bazında, hata kodu bazında, öncelik bazında talep yoğunluğu. Bu metriklerin ortak koşulu şudur: hepsi ham zaman damgalarından ve yapılandırılmış talep alanlarından hesaplanır. Yani önce verinin tutarlı biçimde toplanması gerekir; metrik ondan sonra gelir. ## Veriyi nereden toplarsınız: Printage örneği Bu noktada üretim tarafından somut bir araca bakalım. TYS Dijital Performans'ın kendi MPS servis-masası ürünü Printage (v0.1.0), kurulu ve deploy-edilebilir bir platformdur. Çok-rollü (müşteri, teknisyen, admin, superadmin) ve çok-kiracılı çalışır. Bir servis talebi cihaz seri numarası, hata kodu ve öncelik ile açılır; talepler bir dashboard üzerinde Beklemede, Müdahale ve Tamamlandı durumlarıyla izlenir. Talep açıldığında otomatik e-posta bildirimi gider, talebe token ile erişilebilir, dosya yüklenebilir ve raporlama CSV (Excel uyumlu) olarak alınır. Baseline açısından önemli olan kısım şudur: her talebin açılış, durum geçişi ve kapanış anları ham zaman damgaları olarak kayıt altına alınır. Bu zaman damgaları, yukarıdaki KPI çerçevelerini (ilk yanıt, MTTR, SLA uyumu) hesaplamak için gereken temeli sağlar. CSV çıktısını Excel'de açıp bu hesapları yapabilirsiniz. Burada dürüstlük gerektiren bir not var: SLA ihlallerinin otomatik takibi ve eşik aşılınca uyarı gönderilmesi henüz kodlu değildir; yol haritasındadır. Yani SLA uyumunu bugün hesaplayabilirsiniz, ancak bunu ham veriden manuel olarak yaparsınız, sistem otomatik ihlal alarmı üretmez. Ayrıca online ödeme, muhasebe ve B2B/B2C satış akışları Printage'ın içinde değildir; bunlar TYS Dijital Performans paket katmanında ele alınır. Asistan tarafındaki yönlendirme ise rehber-temelli bir grounding ile (TroubleshootingGuide üzerinden) çalışır; bu bir vektör RAG mimarisi değildir. ## Uygulama: değişikliği tek seferde değil, kontrollü yapın Baseline'i aldıktan sonra dijital performans katmanını devreye alırsınız. Burada operasyonel disiplin şudur: değişikliği ölçülebilir biçimde devreye almak. Hangi tarihte neyin açıldığını, hangi sürecin değiştiğini ve hangi metriklerin etkilenmesini beklediğini önceden yazın. Böylece tekrar ölçüm yaptığınızda, değişen sayının sebebini süreç değişikliğine bağlayabilirsiniz, mevsimsel dalgalanmaya değil. Lead işleme tarafında, paket katmanındaki Dönüşüm Hızı (CVS, Conversion Speed) yaklaşımı gelen talebin işlenme hızını ele alır. Bu da yine bir ölçüm disiplinidir: talebin geldiği an ile ilk anlamlı yanıtın verildiği an arasındaki süreyi takip etmek. ## Tekrar ölçüm: aynı metodla, aynı pencerede Tekrar ölçümün tek kuralı vardır: baseline ile birebir aynı tanımı, aynı kaynağı ve karşılaştırılabilir bir zaman penceresini kullanmak. Eğer baseline'i bir aylık veriden aldıysanız, tekrar ölçümü de bir aylık veriden alın. Eğer MTTR'ı yalnızca kapanmış talepler üzerinden hesapladıysanız, tekrar ölçümde de aynı filtreyi uygulayın. Sayısal beklentiler konusunda dürüst olmak gerekir. Sektör verisine ve genel araştırmalara göre, servis taleplerinin yapılandırılmış biçimde toplanması ve dashboard takibi görünürlüğü artırır; ancak size belirli bir yüzde iyileşme vaat eden her ifadeye şüpheyle yaklaşın. Gerçek iyileşme sizin verinizde, sizin metodunuzla ölçülür. TYS Dijital Performans'ın yaklaşımı da budur: kanıtlanmış bir yüzde sözü değil, ölçülebilir bir çerçeve. ## AI görünürlüğü üzerine dengeli bir not Dijital performans paketinin bir parçası AI görünürlüğüdür. Burada açık olmak önemli: bir AI Authority Score gibi metrikler stokastiktir ve kullanılan metodolojiye bağlıdır. Aynı sorgu farklı zamanlarda farklı sonuç verebilir. Dolayısıyla 'şu sırada çıkıyorsunuz' türünden bir iddia teknik olarak savunulamaz. Savunulabilir olan, görünürlüğü ölçmek ve sistematik biçimde geliştirmektir. ## Sonuç Dijital performans katmanına geçişin değeri, paketin kendisinden önce sizin ölçüm disiplininizde başlar. Önce baseline alın, metrik tanımlarını yazıya dökün, veriyi Printage gibi yapılandırılmış bir kaynaktan tutarlı toplayın. Sonra değişikliği kontrollü devreye alın. En sonunda aynı metodla tekrar ölçün. Bu üç adımlı çerçeve, bir operasyon direktörünün ya da IT müdürünün yönetime sunabileceği tek savunulabilir iyileşme kanıtıdır: his değil, aynı tanımla alınmış iki sayı arasındaki ölçülmüş fark.