Bir BPMN süreç diyagramı, işleri etkinlikler, olaylar, kararlar ve iletişim için standart bir dil olan Business Process Model and Notation ile açıklar. Ekip incelemesindeki değeri kesinliktir. Paylaşılan model, katılımcıların “onaylar yavaş” gibi belirsiz ifadeler üzerinde tartışmak yerine belirli bir geçişi sorgulamasını sağlar.
Bu makale, tartışmaya yardımcı olacak küçük ve açıklayıcı örnekler kullanır. Bunlar çalıştırılabilir süreç modelleri değildir. Gerçek diyagramı oluşturup doğrulamak için BPMN destekli bir modelleme aracı kullanın. NextRetro retrospektif tartışmalarını ve takibi destekler; BPMN düzenleyicisi veya süreç motoru değildir.
Görseli yorumlamadan önce gösterimi anlayın
OMG BPMN 2.0.2 belirtimi yetkili kaynaktır. Aşağıdaki açıklama, örneğimizde kullanılan kavramlarla bilerek sınırlıdır; BPMN bu girişte ele alınandan daha fazla ayrıntıyı destekler.
| Öğe | Bu örnekteki anlamı |
|---|---|
| Havuz | İş birliğine katılan taraf |
| Kulvar | Süreç içindeki bir bölüm; burada sorumluluğu göstermek için kullanılır |
| Görev | Bir isteği kontrol etmek gibi bir etkinlik |
| Başlangıç veya bitiş olayı | Modellenen süreç yolunun başlangıcı veya sonu |
| Ağ geçidi | Yolları dallandıran veya birleştiren kontrol noktası |
| Sıra akışı | Bir süreç içindeki iş sırası; havuz sınırlarını geçmez |
| Mesaj akışı | Ayrı havuzlarla gösterilen bağımsız katılımcılar arasındaki iletişim |
Sıra akışı aynı havuzdaki kulvarları geçebilir. Farklı ekipler işi yapıyor diye aynı havuzun iki kulvarı arasında mesaj akışı kullanmayın. Kulvarlar, bağımsız katılımcılarla aynı şey değildir.
Ayrıntılı semboller ve davranışlar için normatif belirtime bakın. Otomasyonu yönlendirecek bir model, atölye taslağından daha sıkı doğrulama gerektirir.
Örnek 1: kurum içi erişim isteği
Personelin raporlama sistemine erişimi nasıl istediğini inceleyen varsayımsal bir kuruluş düşünün. Kuruluşu, hizmet masası ve erişim yönetimi kulvarlarının bulunduğu tek bir havuz olarak modelleyin. Seçilen iş birliği görünümü talep sahibini ayrı bir katılımcı sayıyorsa çalışanı ayrıca gösterebilirsiniz; sınırı tutarlı biçimde seçip belgeleyin.
Kuruluşun süreci için basit yol şöyledir:
- Bir istek gelir ve süreci başlatır.
- Hizmet masası gerekli bilgilerin bulunup bulunmadığını kontrol eder.
- Münhasır bir karar, eksiksiz ve eksik istekler için iki yol açar.
- Eksik istekler, tanımlanan talep sahibi etkileşimi kapsamında açıklama için geri gönderilir.
- Eksiksiz istekler yetkili erişim kontrolüne gider.
- Onaylanan isteklere erişim verilir; reddedilenlere açıklama iletilir.
- Süreç, uygun sonucun kaydedilmesiyle biter.
Karar yollarını “gerekli bilgi eksiksiz” ve “bilgi eksik” gibi koşullarla etiketleyin. Diyagram ilk sorusu olmadan paylaşıldığında “Evet” ve “Hayır”ı yorumlamak zorlaşır.
Bu, modellenmesi gereken bir açıklamadır; adımların belirli bir kuruluşun güvenlik politikasını karşıladığı iddiası değildir. Erişim yetkilendirme ve kanıt gereklilikleri o kuruluşun onaylı kontrollerinden gelmelidir.
Örnek 2: tedarikçinin sürece katkısı
Şimdi kuruluş yetkilendirdikten sonra ayrı bir tedarikçinin lisanslı hesabı etkinleştirmesi gerektiğini düşünün. Tedarikçiyi başka bir havuz olarak gösterin. Kuruluşun etkinleştirme isteği ve tedarikçinin onayı katılımcılar arası iletişimdir; bunları mesaj akışlarıyla modelleyin.
İç görevden tedarikçi görevine doğrudan sıra oku çizmeyin. Bu, bir katılımcının süreci içindeki iş sırasını sınır ötesi iletişimle karıştırır.
İnceleme kapsamı dışındaysa tedarikçinin iç sürecini gizli bırakabilirsiniz. Ekip, tedarikçinin iç işleyişini biliyormuş gibi davranmadan etkileşimi hangi mesajın başlattığını ve hangi yanıtın beklendiğini bilmek isteyebilir.
Artık yararlı bir inceleme sorusu görünür: Onay gelmezse ne olur? Resmî modele zamanlayıcı veya başka bir olay eklemeden önce amaçlanan istisna davranışını tanımlayın. Tek başına bir zaman aşımı etiketi, kimin takip edeceğini veya hangi kararı verebileceğini belirlemez.
Değişiklik yapmadan önce durumları modelde izleyin
Üç gerçek ve uygun şekilde kimliksizleştirilmiş durum seçin: olağan tamamlanma, açıklama gereken istek ve bir istisna. Kişisel ve gizli ayrıntıları onaylı vaka sisteminde tutun; atölyede referans veya özet kullanın.
Her durumda işi yapan kişilerden yolu izlemelerini isteyin. İş gerçekte nerede durdu? Hangi bilgi eksikti? Hangi katılımcı bir sonraki adımdan başkasının sorumlu olduğunu düşündü? Belgelenen süreçle gözlenen uygulama arasındaki farkları kaydedin.
Modeli sessizce ideal gelecek sürece dönüştürmeyin. Mevcut yolu ve önerilen değişikliği ayrı gösterin. Aksi hâlde ekip, araştırması gereken durumları artık açıklamayan, iyi görünümlü bir diyagramla ayrılabilir.
Süreç modeli, işin nasıl aktığına ilişkin bir varsayımdır. Zaman damgaları ve vaka geçmişleri bu varsayımı sınamaya yardımcı olur. Ne diyagram ne de katılımcının belleği tek başına eksiksiz kanıttır.
Ayrıntılı iyileştirme kararı örneği
Bu varsayımsal örnekte ekip on iki isteği inceler. Sayı açıklama içindir; kıyas ölçütü veya NextRetro müşteri sonucu değildir. Birkaç istek, devirde karar sahibinin belirtilmemesi nedeniyle bilgi kontrolü ile erişim yetkilendirmesi arasında beklemiştir.
İlk öneri her onayı otomatikleştirmektir. Model bunun neden erken olduğunu gösterir: ekip hangi isteklerin hangi yetkilendirmeleri gerektirdiği konusunda anlaşmamıştır. Tanımlanmamış bir kararı otomatikleştirmek, sorumluluğu çözmeden eksik işi hızlandırabilir.
Ekip daha küçük bir deney seçer. Ölçütlere uyan sonraki on istekte hizmet masası, devri göndermeden önce yetkilendirme sahibini belirleyecektir. Sorumluluğun açıklığa kavuşmasını bekleme süresi, yetkilendirme işleminin süresinden ayrı kaydedilecektir.
Güvenlik önlemi değişmez: erişim kontrolü korunur. Daha hızlı işlem, yetkilendirmeyi atlamayı haklı çıkarmaz. Bir sonraki incelemede ekip, sorumlu eksikliği kaynaklı gecikmelerin azalıp azalmadığını ve ek hazırlığın yeni bir darboğaz yaratıp yaratmadığını kontrol eder.
Böylece süreç diyagramı, diyagramı tamamlamayı iyileştirme saymak yerine gözlenebilir bir değişikliğe bağlanır.
Diyagramın yanında bir inceleme çalışma sayfası kullanın
Şüphelenilen her sorun için şu alanları kaydedin:
Konum: Hangi görev, karar veya devir etkileniyor?
Gözlenen durum: Hangi örnek zorluğu gösteriyor?
Beklenen tetikleyici: Sonraki adımı ne başlatmalı?
Gerçek engel: Bunu ne önledi?
Önerilen değişiklik: Uygun sonraki durumlarda ne farklı olacak?
Kısıt: Hangi kontrol veya kalite gerekliliği korunmalı?
İnceleme kanıtı: Ekip neyi ve ne zaman inceleyecek?
Değişiklikleri önceliklendirmeden önce katılımcılara modeli sorgulama zamanı tanıyan bir retrospektif biçimi seçin. Ardından, seçilen deneyin toplantıdan sonra da görünür kalması için eylem maddeleri kılavuzunu kullanın.
Sık sorulan sorular
BPMN'de havuzlar ve kulvarlar aynı şey midir?
Hayır. Havuz, iş birliğine katılan tarafı gösterir. Kulvar bir süreci böler. Sıra akışı bir havuz içindeki kulvarları geçebilir; ayrı katılımcı havuzları arasındaki iletişim mesaj akışıyla gösterilir.
Her süreç akış şeması BPMN diyagramı mıdır?
Hayır. Genel bir akış şeması resmî olmayan semboller ve kurallar kullanabilir. Bir modeli yalnızca ilgili gösterim kurallarına uyuyorsa BPMN olarak adlandırın; otomasyonda kullanılacaksa uygun biçimde doğrulayın.
NextRetro çalıştırılabilir BPMN modelleri oluşturabilir mi?
NextRetro bir BPMN modelleme aracı veya süreç motoru değildir. Yetkili modeli uygun bir düzenleyicide tutun; gözlenen sorunları, alternatif açıklamaları ve üzerinde anlaşılan iyileştirme deneylerini konuşmak için retrospektif panosu kullanın.