capacity-planner

Kuyruklu işleri yöneten ops ekipleri için boyutlandırma aracı — Support, CX, Customer Success, BizOps, IT ops, Finance ops. Erlang-C kuyruk teorisi, Little's Law ve operational-leadership kanonuna (Fournier, Larson, Cleveland, Reinertsen) dayalı. Deterministik, stdlib-only, LLM çağrısı yok.

Amaç

15 → 35 kişi arasında bir ops liderisiniz ve 35 kişilik organizasyonun pik yükte gerçekten nasıl davranacağını hiç bilmiyorsunuz. Ya da %88 utilization'dadasınız ve SLA kaymaya başlamıştır. Ya da dört çeyrek içinde işe alım bütçesi onaylanmış ve mevcut ekibi tüketmeden bunu sıralamanız gerekiyor. Bu beceri bu soruları hissiyat değil, aritmetikle cevaplayır.

Üç artefakt üretir:

1. Kapasite boyutlandırması %70/%80/%90 utilization'da P50/P90/P99 talebine karşı, her noktada P(SLA breach) ve SAFE/WATCH/AT_RISK/CRITICAL risk band'i ile.
2. Utilization sağlığı kişi başına traffic-light seviyesi ve ekip kararı (HEALTHY/SQUEEZED/OVERLOADED/UNBALANCED) ile.
3. 12 aylık çeyreklik işe alım planı ramp eğrileri, ayrılma, QoQ talep büyümesi ve span-of-control manager tetikleyicilerini hesaba katarak.

Ne zaman kullanılacağı

• Yıllık ops kapasite planlaması (Ekim-Kasım, takip eden mali yıl için).
• Çeyreklik yeniden boyutlandırma talep >%15 değiştiyse ya da ayrılma ani artışsa.
• Bütçe savunması — CFO'ya headcount talebini haklı kılan matematik.
• Teşhis ops ekibi SLA'yı kaçırdığında ve bunun bir boyutlandırma sorunu, bir proses sorunu mu yoksa bir병목sorunu mu olduğunu bilmeniz gerektiğinde.
• M&A / yeni segment lansmanı modelleme — yeni ekip ya da birleştirilmiş org boyutlandırması.

İş akışı

1. Talebi al. P50/P90/P99 günlük ticket/case hacmini çalışma sisteminizden çek (Zendesk, Intercom, JSM, ServiceNow, Salesforce). Yalnızca ortalamaları varsa dur ve dağılımı çek. Tek nokta talep tahminleri ops'taki en pahalı anti-pattern'dir.
2. Throughput'u modelle. capacity_modeler.py'yi talep, AHT, SLA hedefi, mevcut FTE ve shrinkage ile çalıştır. --profile'ı işleviniz için kullan (support / cx / bizops / finance-ops / it-ops). %80-utilization satırını oku — bu sizin boyutlandırma noktanızır.
3. Utilization riskini işaretle. utilization_analyzer.py'yi mevcut ekibinizin gerçek utilization verilerine karşı çalıştır.

   %85 sürekli olan herkes Reinertsen'e göre throughput-collapse riski'dir. Ekip genelinde >30 yüzde puan fark UNBALANCED demektir — işe almadan önce bunu düzelt.

4. İşe alımı sırala. hiring_sequencer.py'yi mevcut FTE, hedef EOY, ramp zamanı, ayrılma ve büyüme ile çalıştır. Q1'de işe alımları ön yükle (%35), Q4'te (%15), ramp eğrileri uygula ve span of control 7 IC/manager'ı geçtiğinde manager işe alımını tetikle.
5. Forcing-question kütüphanesinde yürü (aşağıya bak). Birer soru. Ileri atlamayın. Planı teslim etmeden önce cevaplar yazılı olmalıdır.

Scriptler

• scripts/capacity_modeler.py — shrinkage ayarlaması ve P50/P90/P99 breach olasılıkları ile Erlang-C boyutlandırması. Endüstri varsayılanları için --profile.
• scripts/utilization_analyzer.py — kişi başına traffic-light + varyans algılama ile ekip seviyesi sağlık kararı.
• scripts/hiring_sequencer.py — ramp, ayrılma, büyüme, quarter başına max-hires kısıtlaması ve manager-trigger lojik ile 12 aylık çeyreklik plan.

Üçü de --input <path> (JSON), --output {markdown,json}, --sample (yerleşik örnek) ve --help'i kabul eder. Stdlib only.

Referanslar

• references/queueing_theory_canon.md — Erlang, Little, Hopp & Spearman, Reinertsen, Kingman, Cleveland, ITIL, Armony vd. (8 kaynak). Matematik.
• references/ops_workforce_planning_canon.md — Fournier, Larson, Google SRE Workbook, Frei, Lawler, Bersin, Gartner, Grove (8 kaynak). İnsan faktörleri.
• references/capacity_anti_patterns.md — 11 adlandırılmış anti-pattern alıntılı kaynaklar, tool guards ve Lencioni + Goldratt + Christensen'in uyguladığı meta-disiplin ile. (8+ adlandırılmış kaynak.)

Varlıklar

• assets/capacity_brief_template.md — 20 dakikalık doldurma şablonu tüm üç tool için JSON iskeletleri ve output checklist ile.

Varsayımlar

Bu beceri şunları varsayar:

• İş kuyruklu (tickets, cases, work items) — proje tarzı değil. Ekibinizin işi kuyruklu değilse, bu yanlış beceridir.
• Talep bir çeyrek içinde stationary-enough dağılıma sahiptir. Adım-değişimler (yeni ürün lansmanı, M&A, düzenleyici değişim) quarter ortasında yeniden çalıştırmayı gerektirir.
• P50/P90/P99'u hesaplamak için en az 90 günlük tarihsel talep verisi var. Yoksa, dağılımı önce sales/user-base tahmininizden oluşturun.
• Hizmet bir kuyruk içinde tek-sınıftır. Sınıf-spesifik SLA'larla sabit öncelik katmanlarınız varsa (P1/P2/P3), her birini ayrı kuyruk olarak modelleyin ve toplayın.
• Kanallar uyumlu olarak modellenmiştir. Multi-channel ekipler yerleşik shrinkage premium ile uygun --profile kullanır.

Anti-patternler

Kaynakları ile tam taksonomi için references/capacity_anti_patterns.md'ye bakın. Top sekiz:

1. Plan-to-100%-utilization (Reinertsen Principle 12)
2. Treat-ramp-as-instant (Larson)
3. Ignore-attrition-in-12-month-plan (Bersin)
4. Hire-ICs-forever-with-no-manager-trigger (Fournier)
5. Size-to-P50-demand-only (Cleveland)
6. No-shrinkage-adjustment (Cleveland, SRE Workbook)
7. Single-channel-model-for-multi-channel-work (Gartner, Kingman)
8. No-surge-plan-for-P99-events (Hopp & Spearman, Reinertsen)

Farklı olan

• c-level-advisor/vpe-advisor DORA 4 metrikler, story points, deployment sıklığı ve cycle time병목을 via engineering throughput'u ölçer. Bu, kod sevk eden engineering ekipleri içindir. Bu beceri ticket/case yöneten ops ekipleri içindir. Farklı çalışma birimi, farklı matematik (Erlang-C vs. DORA), farklı병목 (queueing-blind staffing vs. WIP + lead time).
• c-level-advisor/chro-advisor stratejik workforce planlaması yapar (1-5 yıl capability portfolyoları, talent supply, leadership succession). Bu beceri operasyonel 0-12 ay kapasite boyutlandırması talebe karşı yapar. Lawler'e göre: bunları karıştırmak sizi yanlış işlere işe alındırtır.
• project-management/* projeler üzerinde delivery throughput'u takip eder (Jira velocity, sprint capacity). Bu beceri steady-state kuyruklu iş etrafında boyutlandırır.
• **Kardeş process-mapper**병목ı bulur. Bu beceri bilinen bir병목 etrafında ekibi boyutlandırır. İş sırası: process-mapper önce → capacity-planner sonra. Yanlış kısıtlama etrafında işe almak hireları boşa harcar.
• business-growth/cs-coverage (varsa) Customer Success kapsamını ARR/CSM oranı ve segmente göre boyutlandırır. Bu beceri kuyruklu iş hacmini boyutlandırır (tickets, cases, escalations). CS ekibi hem relationship work hem de ticket queue yönetiyorsa, her ikisini çalıştırın.

Forcing-question kütüphanesi (Matt Pocock grill disiplini)

Disiplin: bunları birer birer yürü. Ileri atlamayın. Cevaplar yazılı olmalıdır. Birine cevap veremezseniz, bu sizin sonraki araştırmanızdır.

Q1 — "Sizin병목nedir ve bunu ampirik olarak doğruladınız mı?"

Önerilen cevap: kuyruk-zaman verilerini gösteren workflow'da adlandırılmış, ölçülmüş bir aşama iş nerede bekler. Hissiyat değil. "Escalations çok uzun sürüyor" değil. Gerçek ölçülmüş kuyruk.

Neden ilk soru: Goldratt (The Goal, 1984) — her sistemin tam bir kez bağlayıcı kısıtlama vardır. Yanlış kısıtlama etrafında boyutlandırma hireları tamamen boşa harcar. Eğer병목bilmiyorsanız, bu beceriden ÖNCE process-mapper'ı çalıştırın.

Kanon: Eli Goldratt, The Goal (1984); Reinertsen, Principles of Product Development Flow (2009).

Q2 — "Hangi hizmet trade-off'unu kabul ediyorsunuz?"

Önerilen cevap: yazılı, açık bir seçim — hızlı vs. empatik, geniş vs. derin, düşük maliyet vs. yüksek kalite. Frances Frei açık: dördünü de kazanamazsınız. Dördünü kazanmaya çalışan ekip sıfırı kazanır.

Neden önemli: AHT, SLA ve shrinkage input'ları bu trade-off'un operasyonel ifadesidir. Anlaşmazsa (ör., AHT'yi "empati" için ayarlayıp SLA'yı "hız" için), plan içsel olarak tutarsızdır.

Kanon: Frances Frei & Anne Morriss, Uncommon Service (HBR Press, 2012).

Q3 — "Talep P90'ınız nedir ve P99'a kadar boşluk nedir?"

Önerilen cevap: son 90 günün verilerinden iki spesifik numara, her birinin takvim bağlamı ile (ör., "P90 normal Salı günleri 480 ticket/gündü; P99 Kasım release'inden sonraki gün 720 idi"). P50'ye boyutlandırılan ekip SLA'yı zamanın yarısında kaçırır. P99'a boyutlandırılan ekip %30-50 overstaffing yapar. P90 Cleveland'e göre doğru operating boyutlandırma noktasıdır.

Kanon: Brad Cleveland, Call Center Management on Fast Forward (4. ed., 2019); A.K. Erlang, The Theory of Probabilities and Telephone Conversations (1909).

Q4 — "Planlanmış utilization'da, P90'da ve P99'da P(SLA breach) nedir?"

Önerilen cevap: iki olasılık, spesifik N, AHT ve SLA hedefin'iz ile Erlang-C'den hesaplanan (tahmin değil). P(breach at P90) > %10 ise boyutlandırma noktasında understaffing'desiniz. P(breach at P99) > %50 ise surge plan'ınız yoktur ve sonraki pik event CEO'ya görünür olacaktır.

Kanon: Erlang (1909); Hopp & Spearman, Factory Physics (3. ed., 2008), VUT denklemi.

Q5 — "Bu yıl göreceğiniz ayrılma için replacement hire'ları bütçelediniz mi?"

Önerilen cevap: evet, spesifik bir sayı ile. %30 yıllık ayrılmada (Bersin BPO midpoint), 20-FTE ekip bu yıl ~6 kişi kaybeder. Eğer "net 5 ekle" planınız gerçekte "11 işe al" planıysa, recruiting hacmi çarpıcı şekilde değişir. Anti-pattern #3.

Kanon: Bersin/Deloitte talent benchmarks (2015-2023); Edward Lawler, Strategic Workforce Planning (USC CEO, 2008).

Q6 — "Span of control ne zaman manager hire'ını tetikler ve aday kim?"

Önerilen cevap: spesifik quarter (hiring_sequencer.py'den) ve en az bir tanımlanan aday (iç lead ya da dış hire). 7 IC/manager'ın üzerinde, 1:1'ler düşer, feedback döngüleri kayar, ayrılma tırmanır. 10'un üzerinde coverage krizisiniz var. Manager hire'ını 10'u geçmeden ÖNCE, sonra değil.

Kanon: Camille Fournier, The Manager's Path (O'Reilly, 2017), ch. 5; Andy Grove, High Output Management (1983).

Q7 — "P99 günü için surge planınız nedir?"

Önerilen cevap: açık, belgelenmiş bir plan — overflow tier, BPO contracted capacity, on-call rotation, executive escalation tree, YA DA "P99 günlerde SLA'yı X dakikaya uzatıyoruz ve müşterileri proaktif olarak bildiriyoruz" diyen yazılı degradation contract'ı. Cevap "çözeriz" ise, P99 günü board'a görünür bir yangındır.

Kanon: Hopp & Spearman, Factory Physics (2008); Reinertsen (2009) capacity-margin disiplini hakkında.

---

Bu yedisi sırayla yürü. Birer birer. Cevapları yazı ile. Sunduğunuz plan bu yedi soruya verdiğiniz cevaplar kadar savunulabilir.