Kaynaklar ve Kapasite Planlama
Kaynak Nedir?
Süreç simülasyonunda, kaynaklar kapasitesi sınırlı olan ve aktivitelerin erişmek için yarıştığı her şeyi temsil eder. Kaynaklar, simülasyonda gerçekçi darboğazların, kuyrukların ve bekleme sürelerinin oluşmasını sağlar.
Yaygın Kaynak Türleri
| Kategori | Örnekler |
|---|---|
| People | Müşteri temsilcileri, kredi uzmanları, yöneticiler, uzmanlar |
| Equipment | Makineler, iş istasyonları, test ekipmanları |
| Systems | Yazılım lisansları, sunucu kapasitesi, API rate limits |
| Facilities | Toplantı odaları, üretim hatları, kontrol istasyonları |
Neden Kaynak Modeli Kurmalı?
Kaynak kısıtı olmadan simülasyon, sınırsız kapasite var gibi tüm case’leri anında işler, bekleme olmaz. Bu, çoğu süreç için gerçekçi değildir.
Kaynak modelleme ile:
- Gerçekçi darboğazları bulabilirsiniz
- Daha doğru bekleme süresi analizleri yapabilirsiniz
- Kapasite planlaması ve senaryo analizleri oluşturabilirsiniz
- Kaynak kullanım düzenlerini görebilirsiniz
Kaynak Havuzları
ProcessMind’deki kaynaklar, birbirinin yerine kullanılabilen birimlerden oluşan havuzlar halinde düzenlenir.
Havuz Özellikleri
| Özellik | Açıklama |
|---|---|
| Name | Kaynak adı veya tanımı (örn. “Approval Staff”, “Loan Processor”) |
| Capacity | Havuzdaki toplam birim sayısı |
Kapasiteyi Anlamak
Kapasite, bir kaynağın aynı anda kaç aktiviteyi destekleyebileceğini gösterir:
- Kapasite = 1: Aynı anda sadece bir case bu kaynağı kullanabilir
- Kapasite = 5: Aynı anda en fazla 5 case bu kaynağı kullanabilir
Örnek: Onay departmanınızda 3 kişi varsa ve her biri tek seferde bir onay işlemi yapabiliyorsa, kapasiteyi 3 olarak ayarlayın.
Aktivitelere Kaynak Atama
Süreçteki her aktivite için gereken kaynakları belirleyebilirsiniz:
Atama Özellikleri
| Ayar | Açıklama |
|---|---|
| Resource Pool | Hangi kaynak havuzunun kullanılacağı |
| Quantity | Kaç birim kaynağın gerektiği |
Basit Atama
Çoğu aktivite için tek bir kaynaktan bir birim yeterlidir:
- Aktivite: “Review Application”
- Kaynak: “Loan Officers” (miktar: 1)
Çoklu Birim Atama
Bazı aktiviteler birden fazla birim gerektirir:
- Aktivite: “Major Decision Committee”
- Kaynak: “Senior Managers” (miktar: 3)
Kaynak Atama: Olgulara Kaynak Nasıl Atanır?
Bir case, kaynak gerektiren bir aktiviteye ulaştığında, simülasyon şu adımları izler:
Dağıtım Akışı
- Uygunluğu Kontrol Et: Gerekli kaynaklar mevcut mu?
- Gerekirse Kuyruğa Al: Kaynak yoksa, case bekleme kuyruğuna girer
- Bekle: Case, kaynaklar uygun hale gelene kadar bekler
- Ayır: Kaynaklar müsait olduğunda, bu case için rezerve edilir
- Çalıştır: Aktivite, belirlenen süresince çalışır
- Serbest Bırak: Tamamlanınca, kaynaklar tekrar havuza döner
Kuyruk Davranışı ve Stratejisi
ProcessMind birden fazla kuyruk stratejisi ile kaynak müsait olduğunda bekleyen case önceliğini belirlemenize imkan sağlar:
| Strateji | Açıklama |
|---|---|
| FIFO | First In, First Out—case’ler geliş sırasına göre işlenir (varsayılan) |
| LIFO | Last In, First Out—en son gelen case önce işlenir |
| Random | Bekleyen kuyruğundan rastgele seçim yapılır |
Bu stratejiyi her aktiviteye özel olarak element ayarlarından yapılandırabilirsiniz.
Kuyruk Stratejisi Seçimi
En yaygın ve adil yöntem FIFO’dur. LIFO, son gelenlerin daha öncelikli olduğu durumlarda kullanılır (ör. acil eskalasyonlar). Random, öngörülemeyen tipte hizmetleri simüle ederken faydalı olabilir.
Kaynaklar Meşgulse Ne Olur?
Gerekli kaynaklar meşgulse:
- Case, ilgili kaynak için bekleme kuyruğuna girer
- Case bekler (simülasyon zamanı geçer)
- Kaynaklar boşalınca, belirlenen kuyruk stratejisine göre bir case seçilir
- Aktivite başlar
Bu kuyruk yapısı, simülasyonunuzda gerçekçi bekleme sürelerini sağlar.
Dönemsellik ile Kaynak Erişilebilirliği
Kaynaklar her zaman aynı kapasitede olmayabilir. Değişen erişilebilirliği dönemsellik ile modelleyebilirsiniz.
Örnek: Mesai Saatleri
| Dönemsellik | Kapasite |
|---|---|
| Haftaiçi 09:00-17:00 | 5 agent |
| Haftaiçi 17:00-21:00 | 2 agent |
| Hafta Sonu 10:00-16:00 | 1 agent |
| Varsayılan | 0 agent |
Örnek: Vardiya Planı
| Dönemsellik | Kapasite |
|---|---|
| Her Gün 06:00-14:00 (Sabah) | 5 operatör |
| Her Gün 14:00-22:00 (Akşam) | 3 operatör |
| Her Gün 22:00-06:00 (Gece) | 1 operatör |
Örnek: Mevsimsel Değişim
| Dönemsellik | Kapasite |
|---|---|
| Her Yıl 15 Kasım - 31 Aralık (Yoğun) | 20 staff |
| Varsayılan | 12 staff |
Kaynak Kullanımını Anlamak
Utilization, kaynaklarınızın ne kadar meşgul olduğunu ölçer:
Utilization = (Meşgul Zaman ÷ Toplam Kullanılabilir Zaman) × 100%
Kullanımı Yorumlama
| Kullanım Seviyesi | Anlamı |
|---|---|
| %50’nin altında | Az kullanılmış—fazla kapasite olabilir |
| %50-70 | Dengeli kullanım—değişkenlik için iyi |
| %70-85 | Yoğun—piklerde boşluk az |
| %85-95 | Yüksek kullanım—gecikme ihtimali yüksek |
| %95 üzeri | Darboğaz—kuyruklar oluşur |
Kullanım Tuzağı
%100 Kullanımı Hedeflemeyin
Yüksek kullanım verimli görünebilir ama sorunlara yol açar. Talepte küçük değişiklikler bile yüzde 100’e yakın kullanımlarda kuyrukların çok hızlı büyümesine neden olur. Süreçlerinizi istikrarlı ve esnek tutmak için %70-80 arası kullanım hedefleyin.
Yüksek Kullanım Neden Uzun Kuyruklar Yaratır?
Basit bir örnek düşünelim:
- Kaynak kapasitesi: 1
- Ortalama işlem süresi: 10 dakika
- Saatte ortalama 5,5 işlem (kullanım %55): yönetilebilir kuyruklar
- Saatte 5,9 işlem (kullanım %98): çok hızlı kuyruk artışı
Kullanım %100’e yakın olduğunda, rastgele değişiklikler (fazladan birkaç işlem ya da biraz uzun süren görevler) kuyrukların hızla büyümesine sebep olur.
Paylaşılan Kaynaklar
Bir kaynak havuzu birden çok aktiviteye hizmet edebilir. Bu yaklaşım yaygın ve gerçekçidir:
Paylaşılan Kaynak Kurulumu
- Bir kaynak havuzu oluşturun (örn. “Customer Service Team”)
- Aynı havuzu birden fazla aktiviteye atayın
- Aktiviteler havuzdaki kapasite için yarışır
Örnek: Paylaşılan Ekip
“Customer Service Team” (kapasite: 5) şunları yönetir:
- “Answer Phone Inquiry”
- “Process Email Request”
- “Handle Chat Support”
Üç aktivite de aynı havuzu kullanır. 4 telefon çağrısı cevaplanıyorsa, e-posta veya chat için sadece 1 agent kalır.
Paylaşılan Kaynakların Avantajları
- Çok yetenekli ve esnek ekipleri modellendirir
- Farklı iş tipleri arasındaki rekabeti gösterir
- Hangi aktivitenin kaynak kullanımında öne çıktığını belirler
Çoklu Kaynak Gerektiren Aktiviteler
Bazı aktiviteler aynı anda birden fazla farklı kaynağa ihtiyaç duyar:
Örnek: Tasarım Değerlendirme Toplantısı
| Resource Pool | Gereken Miktar |
|---|---|
| Senior Designer | 2 |
| Meeting Room | 1 |
| Design Lead | 1 |
Önemli: Aktivite ancak tüm gerekli kaynaklar aynı anda müsaitse başlar. Tasarımcılar müsaitse bile toplantı odası yoksa case bekler.
Çoklu Kaynak Dikkat Noktaları
- Karmaşık bekleme desenleri oluşabilir
- Birden fazla kaynağı aynı anda bloke eden aktiviteleri izleyin
- Tüm kaynakların aynı anda gerekli olup olmadığını değerlendirin
Simülasyon ile Kapasite Planlama
Kaynak simülasyonunun en değerli kullanım alanlarından biri kapasite planlamasıdır.
Simülasyonun Yanıtladığı Temel Sorular
Kaç kaynağa ihtiyacım var?
Farklı kapasite seviyeleriyle simülasyon çalıştırın:
| Kapasite | Ortalama Bekleme Süresi | Kullanım | Çıktı |
|---|---|---|---|
| 2 staff | 45 dk | %95 | 150/hafta |
| 3 staff | 12 dk | %78 | 150/hafta |
| 4 staff | 3 dk | %58 | 150/hafta |
Yorum: 3. personel eklendiğinde bekleme süresi ciddi oranda azalır. 4. kişi ise az bir katkı sağlar.
Darboğazlar nerede?
Tüm kaynakların kullanım oranlarını karşılaştırın:
| Kaynak | Kullanım |
|---|---|
| Front Desk | %65 |
| Underwriters | %92 |
| Legal Review | %48 |
| Closing Team | %71 |
Yorum: Darboğaz Underwriters tarafında. Front Desk’e ek yapmak çözüm getirmez, iş yükü underwriting tarafında toplanmaya devam eder.
Talep artarsa ne olur?
Daha yüksek giriş hızlarıyla senaryoları deneyin:
| Talep | Mevcut Personel | Kuyruk Artışı |
|---|---|---|
| Mevcut | 5 | Stabil |
| +%20 | 5 | Yavaşça artıyor |
| +%50 | 5 | Sürdürülemez |
Yorum: Mevcut kapasite yaklaşık %20 büyümeyi kaldırır. Daha fazlası için yeni kaynak gerekir.
Kaynak Modelleme için En İyi Uygulamalar
Basit Başlayın
Gerçek kısıtları gösteren birkaç ana kaynakla başlayın:
- Her kişiyi ayrı kaynak olarak modellemeyin
- Benzer işleri yapanları havuzda toplayın
- Detay eklemeyi sadece önemli yerlere bırakın
Gerçek Data Kullanın
Kapasitenizi gerçek çalışma ekibinize göre belirleyin:
- Mevcut ekip sayısı
- Çalışma saatleri ve vardiya planları
- Geçmişteki müsaitlik (izin, hastalık gibi)
Boşluk (Slack) Ekleyin
Gerçek kaynaklar %100 erişilebilir değildir:
- İnsanlar mola verir
- Ekipman bakım gerektirir
- Beklenmedik devamsızlıklar olabilir
Teorik maksimum yerine gerçekçi bir kullanılabilir zamanı modelleyin.
Gerçekle Karşılaştırın
Simülasyondaki kullanım ile gerçek durumu karşılaştırın:
- Simüle edilen kuyruk uzunlukları, gerçek bekleme sürelerine uyuyor mu?
- Simüle edilen verim, gerçek verime yakın mı?
- Kaynak kullanımı gerçekçi mi?
Değilse, kaynak modelinizi güncelleyin.
İnsan Etkenini Unutmayın
Unutmayın, insanlar makine değildir:
- Verimlilik gün içinde değişir
- Sürekli yüksek kullanım tükenmeye ve hataya yol açar
- Çoklu yetenek sınırları vardır