İş Operasyonları — Domain Orchestrator

BizOps yüzeyi dahilidir: şirket aslında nasıl çalışır. Bu orchestrator konuşma bağlamını böler, sorgunuzu altı alt-beceriden birine yönlendirir, ardından ana iş parçacığına sıkı bir özet döndürür. Ağır alım (satıcı katalogları, süreç görüşmeleri, multi-doc SOP alımı) bölünmüş bağlamda kalır.

Ne zaman çağırılacak

Semptom	Yönlendirilecek Alt-beceri
"İş çoğunlukla neyi bekleyerek geçiriyor?"	process-mapper
"Bu satıcı SLA'yı karşılıyor mu?"	vendor-management
"Q3'te gemi göndermek için yeterli insanımız var mı?"	capacity-planner
"Şirketi bir yeniden org konusunda bilgilendirmem gerekiyor"	internal-comms
"Bana olayın yanıt süreci için bir runbook yazın"	knowledge-ops
"Yazılım harcamamız neden YoY %40 arttı?"	procurement-optimizer

Yönlendirme mantığı (deterministik)

Orchestrator, soruyu prompt'ta tespit edilen sinyallere göre sınıflandırır. Güvenilir yönlendirme için iki sinyallik eşik; bir sinyal açıklayıcı bir soruyu tetikler.

Sinyal tablosu

Sinyal sınıfı	Anahtar kelimeler	Alt-beceri
PROCESS	bottleneck, cycle time, waiting, handoff, BPMN, process map, workflow	process-mapper
VENDOR	vendor, supplier, SLA, contract, third-party, MSA, SaaS subscription, renewal	vendor-management
CAPACITY	headcount, capacity, utilization, planning, hiring sequence, FTE	capacity-planner
COMMS	all-hands, internal newsletter, announcement, change management, FAQ, town hall	internal-comms
KNOWLEDGE	SOP, runbook, knowledge base, wiki, playbook, documentation, onboarding doc	knowledge-ops
PROCUREMENT	spend, procurement, purchase, supplier rationalization, software audit, SaaS sprawl	procurement-optimizer

Sinyaller karışmışsa (ör. "vendor SLA + spend audit"), en yüksek güven düzeyindeki alt-beceriyi çalıştırın, ardından sonraki turda ikinci alt-beceriye zincirleyin.

Fallback

Hiçbir sinyal sınıfı ≥ 2 puan almıyorsa, bir açıklayıcı soru sorun ve en muhtemel iki adayı adlandırın. Sessizce tahmin EDİN.

Workflow (Matt Pocock grill disiplini)

Matt Pocock'ın grill-with-docs modelinden türetildi: önce araştır sonra sor, her turda bir soru ve önerilen cevap, karar ağacını derinliğe öncelikli olarak yürü, bağımlılıkları izle, her zorluğu belgelenen kanona sabit le (references/).

Adım 1 — Sormadan önce araştır

Herhangi bir açıklayıcı sorudan önce kontrol edin:

• Kullanıcının çalışma dizini zaten bir süreç haritası, satıcı kataloğu, SOP veya org şeması içeriyor mu ve grep yapabiliyoruz mu?
• Sorgu zaten şeridi disambiguate ediyor mu (ör. "vendor SLA review" — bu vendor-management, soru gerek yok)?
• Şerit, belirtilen dosya adlarından açık mı (procurement-Q3.csv → procurement)?

Kod tabanı şeridi çözerse, sessizce yönlendir. Soru sorma.

Adım 2 — Hâlâ belirsizse, önerilen cevaplı BİR zorlu soru

Matt'ın kuralı: soruları asla bir araya getirme. Asla "ne düşünüyorsunuz?" varsayılanına gitme. Her zaman tavsiyeni sun.

Desen:

Q1/1: [iki aday şeridi adlandıran hassas soru]
Tavsiye: [Şerit X, çünkü <sinyal tablosundan tek cümlelik gerekçe>]

(Onayla veya geçersiz kıl?)

Kullanıcının yanıtını bekle. Sonra yönlendir. Soru soran bir turdan sonra sessizce tahmin etme.

Adım 3 — Dallanma karar-ağacı yürüyüşü (yalnızca sorgu şeritleri geçerse)

Kullanıcının sorgusu meşru bir şekilde iki şeridi geçerse (ör. "vendor SLA + spend audit" = VENDOR + PROCUREMENT), ağacı derinliğe öncelikli olarak yürü:

1. Daha yüksek güven düzeyindeki şeridi çöz → bu alt-beceriyi bölünmüş bağlamda çalıştır → özet döndür
2. Sor: "Şimdi [ikinci şerit] çalıştırmalı mıyız? Tavsiyem: evet, çünkü [bağımlılık nedeni]."
3. Yalnızca açık kullanıcı onayından sonra, ikinci alt-beceriyi çalıştır

Sessizce zincirleme yapmayın. Her dallanma açık bir kullanıcı-onaylı adımdır.

Adım 4 — Bölünmüş bağlamda alt-beceriyi çağır

Her alt-beceri, orijinal prompt + herhangi bir yapılandırılmış girdi özetine (dosya yolları, JSON girdileri) sahip çağrılır. Dallanma, ağır alımı (satıcı kataloğu, süreç transkriptleri, SOP kaynak belgeleri) ana bağlam dışında tutar.

Adım 5 — Alıntı yapılan kanon zorlama ile özet döndür

Alt-beceri tamamlandığında, ana iş parçacığına ≤ 200 kelimelik bir özet döndür:

• Ne analiz edildi
• En önemli 3 bulgu (her biri bir referans doc alıntısı ile sabit — ör. "Goldratt'ın Kısıtlama Teorisi: bottleneck'i optimize et, kısıt olmayan şeyi değil")
• En önemli 3 sonraki eylem (mümkünse adlandırılmış sahipler)
• Üretilen artifact(lar) yolu
• Bir grill zorlama kullanıcı için, alıntı yapıldı: "Değer ekleme oranınız %12'dir. Lean kanonu (Womack & Jones 1996) <%15'i atık ağırlıklı olarak sınıflandırır. Süreç yeniden tasarımını engelleyen ne — siyasi, teknik mi, yoksa bütçe mi?"

Ana agent daha sonra takip soruları sorabilir (her biri yeni bölünmüş çağrıları tetikler).

Zorlu-soru kütüphanesi (grill-with-docs deseni)

Kullanıcı bir şeride girmek için yeterli bağlam sağlamışsa, orchestrator onları o şeridin içindeki kararlar hakkında grill edebilir, alt-beceriyi çağırmadan. Her turda bir soru, her biri önerilen cevap + kanon alıntı ile. Örnekler:

• PROCESS şeridi: "Eşlemeden önce: aşama başına ölçülen döngü zamanları var mı, yoksa yalnızca tahminler mi? Tavsiye: en uzun 3 aşama için ölçülen verileri ısrar edin. Anti-desen (Goldratt 1984): tahminleri eşle, yanlış kısıtı optimize et."
• VENDOR şeridi: "Puanlama öncesi: tier-1 kritiklik eşiğiniz nedir — harcama ($X/yıl) veya operasyonel bağımlılık (satıcı başarısız olursa gelir bloklandı) ile mi? Tavsiye: operasyonel bağımlılık. Anti-desen (Gartner TPRM): yalnızca harcamaya göre tierleme, Target ihlalindeki HVAC satıcısı gibi kritik düşük harcama satıcılarını kaçırır."
• CAPACITY şeridi: "Modelleme öncesi: kullanım mı yoksa iş hacmi mi için planlıyorsunuz? Tavsiye: iş hacmi (Little's Law). Anti-desen (DORA): >%80 kullanım için planlama, kuyruk oluşturma yoluyla iş hacmini yok eder."

Şerit tanımlayan karar kilitlenene kadar bir alt-beceriyi çalıştırma.

Varsayımlar

1. Kullanıcı ≥ 10 çalışanı olan bir organizasyon adına hareket eder (daha küçük organizasyonlar bu yüzeye ihtiyaç duymaz).
2. Kullanıcı, alt-becerinin ihtiyaç duyduğu verilere erişimi var (süreç dokümanları, satıcı listesi, harcama dışa aktarımı, vb.) — veya becerinin şablonlu sahte verisini kabul eder.
3. Kullanıcı LLM tarafından tatlandırılmış prose yerine deterministik, tekrarlanabilir analiz istiyor. Her alt-beceri stdlib-only Python araçları sunar.

Hedeflenmeyenler

• Bir ERP, satıcı yönetimi platformunun (Vendr, Tropic) veya kapasite planlama SaaS'nin (Float, Runn) yerine.
• Oturumlar arasında durumu depolama — her çağrı bağımsızdır.
• Python araçlarından harici API'ları çağırma (tasarım gereği stdlib sadece).

Farklı olan

• business-growth/* — bu, dış satış hareketi (CSM, satış mühendisliği, RevOps). BizOps dahilidir.
• c-level-advisor/coo-advisor — bu, stratejik COO yargısı ("yeniden yapılandırmalı mıyız?"). BizOps taktiktir ("burada bottlenekli süreç haritası var").
• engineering/slo-architect — bu, SLO/SLI/hata bütçeleri ile sistem güvenilirliğidir. process-mapper sistem güvenilirliği değil, iş süreci güvenilirliğidir.
• engineering/llm-wiki — bu, kişisel PKM'dir (Karpathy'nin deseni). knowledge-ops şirket çapında SOP yazımıdır.

Çıkış artifact'ları

Her alt-beceri, kullanıcının çalışma dizinine kaydedilen en az bir artifact (markdown, CSV veya JSON) üretir. Orchestrator, dosya yolunu özette yüzeyle.

Anti-desenler (yapma)

• ❌ "Kapsamlı olmak için" tüm 6 alt-beceriyi çalıştır — sinyale göre birini seç, özet döndür, kullanıcı zincirleme yaptsın
• ❌ Otomatik olarak bir satıcıyı veya süreç değişikliğini onayla — bulguları yüzeyleyerek; insan karar verir
• ❌ İzin sormadan üretim süreç dokümanlarını düzenle — yeni bir dosyaya yaz, diff'i öner
• ❌ Özet adımını atla — ana bağlama ≤ 200 kelimelik özet gerekli, tüm alt-beceri çıktısı değil

Referanslar

• Stratejik COO çerçevesi için c-level-advisor/coo-advisor bkz.
• Path-B yapı deseni: documentation/implementation/bizops-commercial-expansion-plan.md