Throughput, backlog ve SLA’yı yansıtan operasyon gösterge paneli metriklerini öğrenin. Ne ölçeceğinize, nasıl toplayacağınıza ve hangi grafiklerin eylem gerektirdiğine karar verin.
Bir operasyon gösterge paneli bir dizi güzel grafik değil. Ekiplerin aynı kararları daha hızlı ve kimin sayısının “doğru” olduğu konusunda tartışmadan almasını sağlayan ortak bir görünüm olmalı. Eğer birinin bir sonraki adımını değiştirmiyorsa, sadece süs olur.
İş, tekrarlanan küçük bir karar setini desteklemektir. Çoğu ekip her hafta aynı kararlara geri döner:
Farklı kişiler aynı gösterge panelini farklı şekilde kullanır. Bir ön hat lideri bunu günlük olarak kontrol edip bugünkü dikkat edilmesi gerekenleri belirleyebilir. Bir yönetici trendleri görmek, personeli savunmak ve sürprizleri önlemek için haftalık gözden geçirir. Tek bir görünüm nadiren ikisini iyi şekilde karşılar; genellikle bir lider görünümü ve bir yönetici görünümü gerekir.
“Güzel grafikler” basit bir şekilde başarısız olur: etkinliği gösterirler, kontrolü değil. Bir grafik etkileyici görünebilir ama işlerin biriktiği, yaşlandığı ve verilen sözlerin yerine getirilmediği gerçeğini saklayabilir. Gösterge paneli sorunları erken göstermeli, olayı sonra açıklamak için değil.
Görseller seçmeden önce “iyi”nin ne olduğuna karar verin. Çoğu operasyon ekibi için iyi sıkıcıdır:
Küçük bir örnek: bir destek ekibi "kapatılan biletler"in arttığını görüp kutlama yapar. Ama backlog yaşlanıyordur ve en eski öğeler SLA'yı aşmaya başlıyordur. Kullanışlı bir gösterge paneli bu gerilimi hemen gösterir, böylece lider yeni talepleri durdurabilir, bir uzmanı yeniden atayabilir veya engelleri yükseltebilir.
Çoğu operasyon gösterge paneli metriği üç kategoriye düşer: neyi bitiriyorsunuz, ne bekliyor ve sözlerinizi tutuyor musunuz.
Throughput belirli bir zaman diliminde “tamamlanan” iş miktarıdır. Kilit nokta “tamamlandı”nın gerçek olmasıdır, yarım olmaması. Bir destek ekibi için “tamamlandı” biletin çözülüp kapatılması olabilir. Bir operasyon ekibi için “tamamlandı” talebin teslim edilip doğrulanması ve devredilmesi olabilir. Hâlâ düzeltme gerektiren işleri sayarsanız kapasiteyi fazla tahmin eder ve sorunlar zarar verene kadar fark etmezsiniz.
Backlog başlanmayı veya tamamlanmayı bekleyen iştir. Yalnızca büyüklük yeterli değildir; çünkü bugün gelen 40 yeni iş ile haftalardır bekleyen 40 iş çok farklıdır. Backlog, öğelerin ne kadar süre beklediği veya X günden eski kaç tane olduğu gibi yaş bilgisini eklediğinizde faydalı olur. Bu, geçici bir zirve mi yoksa büyüyen bir tıkanma mı olduğunu söyler.
SLA zamanla ilgili verdiğiniz sözdür. İçsel (başka bir ekibe) veya dışsal (müşterilere) olabilir. SLA genellikle birkaç saate/saate eşlenir:
Bu üç metrik doğrudan bağlantılıdır. Throughput drenajdır. Backlog küvetteki su gibidir. SLA, küvet dolarken veya boşalırken bekleme sürelerine ne olduğudur. Eğer backlog throughput'tan daha hızlı büyüyorsa öğeler daha uzun oturur ve SLA ihlalleri artar. Eğer throughput artıp giriş sabit kalırsa backlog küçülür ve SLA iyileşir.
Basit örnek: ekibiniz günde yaklaşık 25 talep kapatıyor. Üç gün boyunca ürün güncellemesinin ardından yeni talepler günde 40'a fırlıyor. Backlog yaklaşık 45 öğe artıyor ve en eski öğeler 48 saatlik çözüm SLA'nızı aşmaya başlıyor. İyi bir gösterge paneli bu neden-sonuç ilişkisini açıkça gösterir, böylece erken hareket edebilirsiniz: önceliksiz işleri durdurmak, bir uzmanı yönlendirmek veya alımı geçici olarak ayarlamak gibi.
Yararlı bir gösterge paneli, veriyi çekmenin kolay olduğu şeyle değil, işler ters gittiğinde insanların sorduğu sorularla başlar. Gösterge panelinin desteklemesi gereken kararları yazmakla başlayın.
Çoğu ekip her hafta şu soruları yanıtlamak zorundadır:
Bundan sonra her alan için 1–2 temel ölçü ile kendinizi sınırlayın. Sayfayı okunabilir tutar ve “önemli olan”ı belirgin kılar.
Yanlış yorumları önlemek için bir öncü gösterge ekleyin. Throughput’un düşmesi daha yavaş çalışma anlamına gelebilir, ama aynı zamanda daha az girişin de işareti olabilir. Throughput ile birlikte arrivals (yeni oluşturulan işler) takip edin.
Son olarak, hangi kırılımları (slice) tutmanız gerektiğine karar verin. Kırılımlar tek bir ortalamayı eyleme geçirilebilir bir haritaya dönüştürür. Yaygın olanlar: ekip, kuyruk, müşteri seviyesi ve öncelik. Sadece sahiplik ve yükseltme yollarına uyan kırılımları tutun.
Somut örnek: genel SLA yeterli görünür ama önceliğe göre kırdığınızda P1 işlerin diğerlerinden iki kat daha sık ihlal ettiğini görebilirsiniz. Bu “daha hızlı çalış” demekten farklı bir düzeltmeye işaret eder: nöbet kapsamı eksiklikleri, P1 tanımlarının belirsizliği veya kuyruklar arası yavaş elden geçişler gibi.
Çoğu gösterge paneli tartışması sayılarla ilgili değil, kelimelerle ilgilidir. İki ekip “done” veya “breached” diye farklı şey anlıyorsa metrikler kesin görünür ama yanlış olur.
Ölçtüğünüz olayları tanımlayarak başlayın. Herkesin aynı şekilde uygulayabileceği basit kurallar olarak yazın, yoğun bir günde bile.
Küçük bir olay seti seçin ve her birini genellikle bir zaman damgası değişikliğine sabitleyin:
Ayrıca SLA raporlaması için neyin ihlal sayılacağına karar verin. SLA saati “created to first response” mu, “created to done” mu, yoksa “started to done” mu? Saat bloke olurken durur mu, durursa hangi bloke nedenleri buna dahil?
Rework metrikleri kolayca yanlış gösterir. Başta bir yaklaşım belirleyin ve buna sadık kalın.
Bir bilet yeniden açılırsa, onu aynı öğe (ek çevrim süresi ile) sayar mısınız yoksa yeni bir öğe olarak mı sayarsınız? Aynı öğe saymak genelde kaliteyi daha iyi görünür kılar ama throughput'u daha düşük gösterebilir. Yeni öğe saymak hataların gerçek maliyetini gizleyebilir.
Pratik bir uzlaşma: bir iş birimini tutun, ama ayrıca ayrı bir “yeniden açılma sayısı” ve “yeniden çalışma süresi” izleyin ki ana akış doğru kalsın.
Şimdi iş biriminizi ve durum kurallarınızı anlaşın. “Bilet”, “sipariş”, “talep” veya “görev” hepsi çalışabilir, ama herkes aynı anlamı kullanırsa. Örneğin: bir sipariş üç sevkiyata bölünürse, bu bir birim mi (sipariş) yoksa üç birim mi (sevkiyat)? Throughput ve backlog bu seçime göre değişir.
Sisteminizin yakalaması gereken minimum alanları belgelendirin, aksi takdirde gösterge panelli boşluklar ve tahminlerle dolu olur:
Toplulaştırma, faydalı gösterge panellerinin sıkça yanlış yaptığı yerdir. Dağınık gerçeği birkaç sayıya sıkıştırırsınız, sonra “iyi” trend çizgisi ekibin her gün hissettikleriyle uyuşmaz. Amaç daha güzel bir grafik değil; riski hâlâ gösteren dürüst bir özettir.
Kararlarınızla uyumlu zaman kovalarıyla başlayın. Günlük görünümler operatörlerin bugünkü birikmeleri fark etmesine yardım eder. Haftalık görünümler bir değişikliğin gerçekten yardımcı olup olmadığını gösterir. Aylık rolluplar planlama ve personel için iyidir ama SLA'yı bozan kısa zirveleri saklayabilir.
Zaman tabanlı ölçüler (çevrim süresi, ilk yanıt süresi, çözüm süresi) için ortalamalara güvenmeyin. Çok uzun birkaç vaka bunları çarpıtabilir, çok kısa birkaç vaka da işleri olduğundan iyi gösterir. Medyanlar ve yüzdelikler ekiplerin önem verdiği hikâyeyi anlatır: tipik olan (p50) ve acı veren uç (p90).
İşleyen basit bir desen:
Segmentasyon diğer kaldıraçtır. Liderlik için tek bir genel çizgi uygundur, ama tek görünüm bu olmamalı. İşin gerçekten nasıl aktığına uyan bir veya iki boyutta bölün; örneğin kuyruk, öncelik, bölge, ürün veya kanal (e-posta, sohbet, telefon). Sıkı tutun. Beş boyutta kırarsanız, küçük gruplar ve gürültülü grafikler elde edersiniz.
Kenarda kalan durumlar ekiplerin kendini kandırdığı yerlerdir. Duraklatılmış işleri, “müşteriyi bekliyor” durumunu, tatilleri ve mesai dışı zaman pencerelerini baştan nasıl ele alacağınıza karar verin. SLA saatiniz müşteri beklerken duruyorsa, gösterge paneliniz de aynı kuralı uygulamalı yoksa gerçek olmayan sorunların peşinden koşarsınız.
Pratik bir yaklaşım, yan yana iki saat yayınlamaktır: takvim süresi ve iş saati. Takvim süresi müşterinin deneyimiyle eşleşir. İş saati ekibin kontrol edebileceği süreyi gösterir.
Son olarak, her toplulaştırmayı gerçek birkaç bilet veya sipariş örneğiyle akılcı olarak test edin. p90 iyi görünüyorsa ama operatörler on adet takılı öğeyi sayabiliyorsa, gruplama veya saat kurallarınız acıyı saklıyordur.
İyi metriklerin yaptığı tek şey: bir sonraki ne yapılacağını işaret etmek. Bir grafik tanımlara takılıp tartışmaya sokuyorsa veya bir numarayla kutlama yapılıyorsa ve davranış değişmiyorsa, muhtemelen gösteriştir.
Throughput için bir çizgi grafiği (günlük veya haftalık tamamlanan iş sayısı) bağlamla daha faydalı olur. Grafiğe tek bir hedef çizgisi yerine hedef bandı koyun, böylece ne zaman anlamlı olarak sapma olduğunu görürsünüz.
Aynı zaman ekseninde arrivals (yeni oluşturulanlar) ekleyin. Throughput iyi görünür ama arrivals fırladıysa sistemin ne zaman geride kaldığını görebilirsiniz.
Okunabilir tutun:
Tek bir backlog sayısı gerçek problemi saklar: eski işler. Ekiplerin acı hissettiği yaş aralıklarına uygun yaşlanma kovaları kullanın. Yaygın bir set: 0-2 gün, 3-7, 8-14, 15+.
Haftalık olarak yığınlanmış bir çubuk grafiği iyi çalışır çünkü toplam hacim sabit olsa bile backlog'un olgunlaşıp olgunlaşmadığını gösterir. 15+ segmenti tırmanıyorsa önceliklendirme veya kapasite sorununuz var, “sadece yoğun bir hafta” değil.
Zaman içinde SLA uyumu (haftalık veya aylık) “sözü tutuyor muyuz?” sorusunu yanıtlar. Ama bugünkü ne yapılmalı sorusunu vermez.
Bunu açık bir ihlal kuyruğuyla eşleştirin: SLA penceresi içinde ama ihlale yakın olan açık öğelerin sayısı. Örneğin, trendin yanında “önümüzdeki 24 saatte süresi dolacak öğeler” ve “zaten ihlal olmuş” gibi iki küçük sayacı gösterin. Bu soyut yüzdeyi günlük eylem listesine dönüştürür.
Pratik bir senaryo: yeni bir ürün lansmanından sonra arrivals zirve yapar. Throughput sabit kalır ama backlog yaşlanma 8-14 ve 15+ kovalarında büyür. Aynı zamanda ihlal kuyruğu sıçrar. Hemen müdahale edersiniz: işi yeniden atamak, girişi daraltmak veya nöbet kapsamını ayarlamak gibi.
Bir gösterge paneli spesifikasyonu iki sayfaya sığmalıdır: bir sayfa kullanıcıların gördüğü, bir sayfa sayıların nasıl hesaplandığı. Uzunsa genellikle çok fazla problemi çözmeye çalışıyordur.
Önce kağıtta düzeni taslaklayın. Her panel için cevaplaması gereken bir günlük soru yazın. Soruyu cümleleyemiyorsanız, grafik “bakması güzel” bir metrik haline gelir.
Kullanışlı bir yapı:
Sonra her metriği bir cümleyle tanımlayın, ardından hesaplamak için gereken alanları listeleyin. Formülleri açık tutun, örneğin: “Çevrim süresi closed_at eksi started_at'tır, saat olarak ölçülür, Waiting durumundaki öğeler hariç.” Tam durum değerlerini, tarih alanlarını ve hangi tablonun/kaynağın otorite olduğunu yazın.
Yayınlamadan önce eşiklerini ve uyarıları ekleyin, sonra değil. Bir grafiğin eylemi yoksa sadece rapordur. Her eşik için belirtin:
İnsanların trendten nedene bir dakikadan kısa sürede gitmesini sağlayacak drill-down yolları planlayın. Pratik akış: trend çizgisi (hafta) -> kuyruk görünümü (bugün) -> öğe listesi (en büyük suçlular) -> öğe detayı (geçmiş ve sahibi). Bireysel öğelere inemiyorsanız, tartışmalar yerine düzeltmeler çıkmaz.
Göndermeden önce üç gerçek haftalık geçmiş verisiyle doğrulayın. Bir sakin hafta ve bir dağınık hafta seçin. Toplamların bilinen sonuçlarla eşleştiğini kontrol edin ve uçtan uca zaman damgalarını, durum geçişlerini ve hariç tutmaları on örnekle doğrulayın.
Bir destek ekibi Pazartesi büyük bir ürün güncellemesi yayınlar. Çarşamba itibarıyla müşteriler aynı “nasıl yaparım…” sorusunu sorup birkaç yeni hata raporu gönderir. Ekip daha meşgul hisseder ama bunun geçici bir zirve mi yoksa SLA felaketi mi olduğunu kimse söyleyemez.
Gösterge panelleri basittir: kuyruk başına bir görünüm (Faturalama, Hatalar, Nasıl yapılır). Gelenler (yeni biletler), throughput (çözülen biletler), backlog büyüklüğü, backlog yaşlanma ve SLA riski (yaşa ve kalan süreye göre ihlal olma olasılığı) izlenir.
Güncellemeden sonra metrikler şunu gösterir:
Bu genel bir performans sorunu gibi görünmez. Yönlendirme ve odak sorunu gibi görünür. Ekip için üç gerçek karar var ve gösterge paneli bunları netleştirir:
Karışık bir çözüm seçerler: zirve saatler için “Nasıl yapılır”a ekstra bir temsilci ve hazır cevap ile küçük bir yardım makalesi.
Ertesi gün tekrar kontrol ederler. Throughput dramatik şekilde artmamıştır, ama önemli sinyaller doğru yönde hareket eder. Backlog yaşlanması tırmanmayı durdurur ve aşağı doğru eğilmeye başlar. SLA risk grafiği önce düşer, sonra gerçek ihlaller azalır. “Nasıl yapılır” gelenleri azalmaya başlar; kök neden düzeltmesinin işe yaradığını doğrular.
Bir gösterge paneli bir sonraki ne yapılacağınıza yardım etmeli, dünün güzel görünmesini sağlamamalı. Birçok ekip riskleri gizleyen yoğun grafiklerle biter.
Klasik olan “bu hafta kapatılan biletler” tek başına gösterilmesidir. Bu artabilir ama işler kötüleşiyor olabilir; çünkü gelenler, yeniden açılmalar ve yaşlanma yok sayılır.
Aşağıdaki desenlere dikkat edin:
Basit bir düzeltme: her çıktı sayısını talep sayısı ve bir zaman sayısı ile eşleştirin. Örneğin, kapatılan vs oluşturulan ve medyan çevrim süresi.
Ortalama çözüm süresi müşteri acısını kaçırmanın hızlı bir yoludur. 20 gün süren bir takılı vaka, ortalamanın kısa vakalar tarafından bastırılmasıyla görünmez olabilir.
Medyan ve yüzdelikler (p75 veya p90 gibi) ile birlikte bir yaşlanma görünümü kullanın. Eğer yalnızca birini seçebiliyorsanız, medyanı seçin. Ardından uzun kuyruğun görünür kalması için “açık en yaşlı 10 öğe” tablosu ekleyin.
Ekip A “done”ı “ilk yanıt gönderildi” olarak sayıp Ekip B “done”ı “tamamen çözüldü” olarak sayarsa grafikler tartışma çıkarır. Başlatma saati, durdurma saati ve hangi durumların saati durdurduğunu açıkça yazın ve tutarlı kullanın.
Gerçekçi bir örnek: destek “Waiting on customer” durumunu “On hold” olarak değiştirir ama mühendislik o durumu hiç kullanmaz. Böylece bir grup için SLA saati dururken diğeri için durmaz; liderlik “SLA iyileşiyor” görürken müşteriler daha yavaş çözümler görür.
Filtreler yardımcıdır ama 12 filtre ve 20 grafikli bir gösterge paneli kendi kendine macera olur. Açık bir varsayılan görünüm seçin (son 6–8 hafta, tüm müşteriler, tüm kanallar) ve istisnaları kasten yapın.
Eksik zaman damgaları, geriye dönük doldurulan durum değişiklikleri ve tutarsız durum adları sonuçları gizlice zehirler. Daha fazla grafik oluşturmadan önce ana alanların mevcut ve doğru sırada olduğundan emin olun.
“Bitti” demeden önce gösterge panelinin yoğun bir pazartesi sabahında gerçek soruları yanıtlayıp yanıtlamadığını kontrol edin. İyi operasyon gösterge paneli metrikleri riski erken fark ettirir, neyin değiştiğini açıklar ve bir sonraki adımı belirler.
Tek ekrandaki hızlı kontrol:
Eğer herhangi bir cevap “hayır” ise önce küçük bir düzeltme yapın. Genellikle geçen haftaya karşılaştırma eklemek, bir görünümü önceliğe göre bölmek veya haftalık toplamın yanına 7 günlük hareketli ortalama göstermek kadar basittir. Tek bir iyileştirme seçmeniz gerekirse, sürprizleri önleyen bir şeyi seçin: önceliğe göre backlog yaşlanması veya bir SLA geri sayım görünümü.
Kontrol listesini uygulayan kısa bir şablon yazın, böylece biri yorulmadan uygulayabilir. Sıkı tutun ve tanımlar ile karar kurallarına odaklanın.
Eğer tam iş akışını (veri modeli, iş kuralları ve web gösterge paneli UI) hızlıca prototiplemek isterseniz, AppMaster (appmaster.io) kod yazmadan tam uygulamalar oluşturmak için uygundur ve arkada gerçek kaynak kod üretir. Önemli olan küçük başlamak, yayınlamak ve yalnızca kararları değiştiren metrikleri eklemektir.
What should an operations dashboard actually help me decide?Başlangıç noktası olarak ekibinizin tekrar eden kararlarını yazın (personel, önceliklendirme, yükseltme ve süreç düzeltmeleri) ve bu kararları doğrudan destekleyen birkaç ölçüyü seçin. Bir metrik birinin sonraki adımı değiştirmiyorsa, bırakın.
What are the three most important metric areas for an ops dashboard?Üç temel sinyali birlikte takip edin: throughput (gerçekten tamamlanan iş), backlog ile yaşlanma (bekleyen işler ve bekleme süreleri) ve SLA performansı (verilen sözler tutuluyor mu). Birçok “iyi” görünen gösterge paneli aktiviteyi gösterip riski gizler.
How do I define throughput so it doesn’t lie?“Done”ı, iş kabul kuralınızı karşıladığı an olarak tanımlayın; “incelemeye gönderildi” veya “başkasını bekliyor” gibi yarım durumlar olmasın. Eğer “done” tutarlı değilse, throughput gerçeği olduğundan iyi gösterir ve SLA’lar kaymaya başlayana dek sorunları kaçırırsınız.
Why isn’t backlog count enough?Backlog büyüklüğü tek başına yanıltıcıdır çünkü bugün gelen 40 yeni iş ile haftalardır bekleyen 40 iş aynı değildir. En az bir yaş sinyali ekleyin; örneğin “X günden eski kaç iş var?” Böylece geçici bir zirve mi yoksa büyüyen bir tıkanma mı olduğu anlaşılır.
What’s the simplest way to think about SLA on a dashboard?SLA, genellikle ilk yanıt, çözüm veya önemli durumlardaki süreye bağlı zaman sözüdür. Her söz için bir saat/başlangıç noktası seçin ve ne zaman başladığını, ne zaman durduğunu ve bloke veya bekleme durumlarında saatin durup durmayacağını belgeleyin.
What’s the one “context metric” people forget to add?Throughput’un yanında aynı zaman ekseninde arrivals (yeni oluşturulan işler) koyun. Throughput’un düşmesi daha yavaş çalışma anlamına gelebilir ama aynı zamanda daha az giriş olduğu anlamına da gelebilir; ikisini görmezseniz yanlış sonuca varırsınız.
Should I use averages for cycle time and resolution time?Zaman tabanlı metrikler için ortalamalar yerine medyan ve yüzdeler (p50, p90 gibi) kullanın; ortalamalar uç vakalar tarafından sapıtılır. Bu, tipik olanı (p50) ve acı veren uçları (p90) görünür kılar.
How should I handle reopened tickets in my metrics?Yeniden açılan bir öğe aynı iş birimi olarak mı kalacak yoksa yeni bir iş olarak mı sayılacak, baştan karar verin ve buna sadık kalın. Yaygın bir varsayılan, aynı öğeyi tutmak ve ayrıca “yeniden açılma sayısı” veya “rework zamanı” izlemektir, böylece kalite sorunları gizlenmez.
How do I aggregate data without hiding issues?Toplamlarken karar verdiğiniz zaman dilimleriyle eşleşmeyen kovalar veya çok fazla rollup, gerçek problemi gizler. Bugünün kontrolü için günlük görünüşler, değişikliğin işe yarayıp yaramadığını görmek için haftalık ve planlama için aylık rollup kullanın; sonuçları daima birkaç gerçek örnekle karşılaştırın.
How do I turn these ideas into a dashboard I can actually build?Kısa bir sayfa planı hazırlayın: kullanıcıların gördüğü sayfa ve metriklerin nasıl hesaplandığı. Her panel için bir günlük soru yazın ve her metriği bir cümlede tanımlayın. Prototip, uygulanabilir formül ve örnek veri ile doğrulayın.
How do I turn these ideas into a dashboard I can actually build?AppMaster (appmaster.io), el ile kod yazmadan veri modeli, iş kuralları ve web gösterge paneli UI’sını prototiplemek için kullanılabilir; arka planda gerçek kaynak kodu üretir. Küçük başla, yayınla ve yalnızca kararları değiştiren metrikleri ekleyin.
21 Oca 2026
8 dk
20 Oca 20268 dk
20 Oca 20268 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
