- BPMN diyagramı neyi gösterir?
- Çizmeden önce: kapsamı ve katılımcıları belirleyin
- Temel öğeler ve simgeleri
- Adım adım çizim: örnek sipariş onay süreci
- Alt süreç ve olay kullanımı: diyagramı okunur tutmak
- Araçlar ve diyagramı kontrol etme
- Sık yapılan hatalar
- Mindset programlarında nerede çalışılır?
- Sık sorulan sorular
BPMN ile iş süreci diyagramı çizme: öğeler, adımlar, örnek
BPMN diyagramı çizmenin adımları: kapsam belirleme, olay, görev ve ağ geçidi kullanımı, örnek sipariş süreci, kontrol listesi ve sık yapılan hatalar.
BPMN diyagramı neyi gösterir?
BPMN, bir iş sürecinin kim tarafından, hangi sırayla, hangi koşullarda ve hangi sonuçla ilerlediğini ortak bir gösterimle çizmeyi sağlayan notasyondur. Standardı yayımlayan Object Management Group (OMG), BPMN'i süreç diyagramları için fiilî standart olarak tanımlar ve notasyonun hem süreci yöneten iş tarafının hem de onu yazılıma çeviren teknik tarafın doğrudan kullanabileceği biçimde tasarlandığını belirtir.
Akış şemasından farkı, katılımcıları (havuz ve kulvarlar), olayları, mesajlaşmayı ve paralel yolları anlamı sabit simgelerle ifade edebilmesidir. Farklı kişiler aynı diyagramı okuduğunda aynı süreci anlamalıdır; çizimin amacı budur.
Çizmeden önce: kapsamı ve katılımcıları belirleyin
En sık yapılan hata, yeni bir sayfaya doğrudan kutular çizmeye başlamaktır. Önce şu soruları yanıtlayın:
- Süreç hangi olayla başlıyor ve hangi sonuçla bitiyor? Örneğin "müşteri siparişi alındı" ile "sipariş teslim edildi".
- Sürece kimler (rol, bölüm, sistem) katılıyor?
- Hangi ayrıntı düzeyinde çizeceksiniz: üst düzey bir genel bakış mı, adım adım bir uygulama akışı mı?
- Çıkarım için kaynağınız ne: iş birimiyle atölye, mevcut prosedür, sistem kayıtları?
Süreç sahibinin ve en az bir gerçek uygulayıcının çizimi onaylaması şarttır. Prosedür kâğıdında yazan süreç ile fiilen yapılan süreç çoğu zaman farklıdır; BPMN çizimi bu farkı görünür kılar.
Temel öğeler ve simgeleri
BPMN 2.0 çok sayıda öğe tanımlar, ama günlük çizimlerin büyük kısmı şu temel öğelerle yapılır:
- Olaylar (yuvarlak): Başlangıç olayı ince çizgili, ara olay çift çizgili, bitiş olayı kalın çizgili daire ile gösterilir.
- Görevler (yuvarlatılmış dikdörtgen): Süreçte yapılan iş. Görev adı "fiil + nesne" biçiminde yazılır: "Siparişi onayla".
- Ağ geçitleri (eşkenar dörtgen): Akışın dallandığı veya birleştiği noktalar. Özel (exclusive) ağ geçidi yalnızca bir yolu seçtirir, paralel ağ geçidi tüm yolları aynı anda başlatır, kapsayıcı (inclusive) ağ geçidi koşulu sağlayan bir veya birden çok yolu açar.
- Sıra akışı (düz ok): Aynı katılımcının içindeki sırayı gösterir.
- Mesaj akışı (kesikli ok): Farklı havuzlar, yani farklı katılımcılar arasındaki iletişimi gösterir.
- Havuz ve kulvar: Havuz bir katılımcıyı, kulvar ise o katılımcı içindeki rol ya da bölümü gösterir.
- Veri nesnesi ve not: Sürece giren çıkan belgeleri ve açıklamaları ekler.
Adım adım çizim: örnek sipariş onay süreci
Örneğin bir firmada müşteri siparişinin onaylanması sürecini çizelim.
- Havuzları açın: "Müşteri" ve "Firma". Firma havuzunda satış ve depo kulvarları olsun.
- Müşteri havuzunda başlangıç olayı "İhtiyaç doğdu", ardından "Sipariş gönder" görevi gelir. Bu görevden firma havuzuna bir mesaj akışı çizin.
- Firma havuzunda başlangıç olayı mesajla tetiklenen "Sipariş alındı" olur. Satış kulvarında "Siparişi kontrol et" görevi gelir.
- Görevi bir özel ağ geçidi izler: "Stok yeterli mi?" Evet yolu depo kulvarındaki "Siparişi hazırla" görevine, hayır yolu "Müşteriyi bilgilendir" görevine gider.
- Evet yolunda hazırlık bittikten sonra "Sevk et" görevi ve bitiş olayı "Sipariş teslim edildi" gelir. Hayır yolu da kendi bitiş olayında sonlanır.
- Her çıkış yoluna koşulunu yazın: "Evet", "Hayır". Etiketsiz dallanma okuyanı yanıltır.
Bu akışta şu temel kurallar görülür: her süreç bir başlangıç ve en az bir bitiş olayıyla kapanır, her dallanan ağ geçidinin koşulları tutarlıdır, mesaj yalnızca havuzlar arasında gider, her görev tek bir sorumlu kulvarda durur.
Alt süreç ve olay kullanımı: diyagramı okunur tutmak
Diyagram tek sayfaya sığmayacak kadar büyüdüğünde ayrıntıyı alt sürece taşıyın. Alt süreç, bir görev kutusunun içinde saklanan ayrı bir süreç akışıdır; üst düzey diyagramda tek kutu olarak durur, gerektiğinde açılıp ayrıntısı gösterilir.
Zamanlayıcı ve mesaj gibi ara olaylar, süreçteki beklemeleri doğru göstermenin yoludur. Örneğin müşteri yanıtını bekleyen bir sürecin üzerinde "belirli süre dolarsa hatırlat" için zamanlayıcı sınır olayı çizebilirsiniz. Böylece bekleme ve zaman aşımı kurala dönüşür, kişinin hafızasına bırakılmaz.
Döngüler için ayrı bir "tekrar" simgesi kullanabilir ya da akışı geri bağlayan bir ağ geçidi çizebilirsiniz; ikisini aynı diyagramda karıştırmayın.
Araçlar ve diyagramı kontrol etme
BPMN 2.0 dosya biçimini destekleyen birçok araç vardır; Camunda ve Bonita gibi süreç platformlarının modelleme araçları, çizilen diyagramı doğrudan çalıştırılabilir sürece bağlayabilir. Yalnızca dokümantasyon amacıyla çiziyorsanız tarayıcıda çalışan herhangi bir BPMN düzenleyici de yeterlidir.
Çizim bittiğinde şu kontrol listesini uygulayın:
- Tüm akışlar başlangıç olayından başlayıp bitiş olayında sonlanıyor mu? Havada kalan ok var mı?
- Her ağ geçidi çıkışında koşul etiketi var mı? Paralel ayrılan yollar bir paralel ağ geçidinde birleşiyor mu?
- Görev adları fiil + nesne mi? Aynı iş farklı adlarla tekrarlanıyor mu?
- Kulvar ve havuz ayrımı gerçek sorumluluğu yansıtıyor mu?
- Süreç sahibi ve uygulayıcı diyagramı okuyup "evet, böyle yapıyoruz" dedi mi?
Sık yapılan hatalar
- Akış şeması gibi çizmek: mesaj akışını sıra akışı yerine kullanmak ya da kulvarlar arası iletişimi sıra oku ile bağlamak.
- Her ayrıntıyı tek sayfaya doldurmak: okunmayan diyagram kullanılmaz.
- Ağ geçidi türlerini karıştırmak: paralel yerine özel ağ geçidi kullanıldığında birlikte yürümesi gereken işler yarışmalı hale gelir.
- Bitiş olayı koymamak: süreç bittiğinde ne olduğunu belirsiz bırakır.
- "Olması gereken" süreci çizip fiili süreci atlamak: önce mevcut durumu, sonra iyileştirilmiş durumu ayrı diyagramlarda çizin.
- Görev adlarını isim biçiminde yazmak: "Sipariş onayı" yerine "Siparişi onayla".
Mindset programlarında nerede çalışılır?
Süreç Modelleme (BPMN) eğitimi, iş analistleri, süreç sahipleri ve kalite ekipleri için BPMN 2.0 temel kavramlarından olaylara, ağ geçitlerine, alt süreçlere ve uygulamalı bir atölyeye uzanır. BPM Araçları (Camunda, Bonita) Temelleri eğitimi, çizilen diyagramın bir platformda nasıl çalıştırıldığını; Süreç Yönetimi ve BPM Temelleri eğitimi ise sürecin yönetim çerçevesini ele alır.
Kurumsal ekiplerde çoğu zaman önce ortak bir modelleme standardı belirlenir, sonra bölümler kendi süreçlerini bu standartta çizer. Ekibinizin süreçlerine uygun bir atölye için kurumsal eğitim talebi üzerinden iletişime geçebilirsiniz.
İlgili Mindset programı
Süreç Modelleme (BPMN)
Sık sorulan sorular
BPMN diyagramı çizmek için hangi aracı kullanmalıyım?
BPMN 2.0 biçimini destekleyen herhangi bir modelleme aracı işinizi görür. Yalnızca belgelemek istiyorsanız tarayıcıda çalışan bir düzenleyici yeter; diyagramı çalıştırılabilir sürece bağlayacaksanız süreç platformunun kendi modelleyicisini kullanmak, uyumsuz dışa aktarma sorunlarını önler.
Akış şeması ile BPMN diyagramı arasındaki fark nedir?
Akış şeması adımları ve kararları gösterir; BPMN ise ek olarak katılımcıları, olayları, mesajlaşmayı ve paralel yürütmeyi anlamı sabit simgelerle ifade eder. BPMN'de farklı kişiler aynı diyagramı okuduğunda aynı süreci anlamalıdır. Akış şemasında bu garanti yoktur.
BPMN'de hangi öğeleri bilmek yeterlidir?
Başlangıç ve bitiş olayları, görev, özel ve paralel ağ geçidi, sıra akışı, mesaj akışı, havuz ve kulvar çoğu iş sürecini çizmeye yeter. Zamanlayıcı ve mesaj olayları ile alt süreç, gerçek süreçlerde en sık ihtiyaç duyulan sonraki öğelerdir.
Diyagramı iş birimleri nasıl doğrular?
Çizimi bir atölye yapısında, gerçek uygulayıcılarla birlikte adım adım gezin. Her göreve "bunu kim, hangi bilgiyle yapar" diye sorun, her ağ geçidinde "başka hangi durum olabilir" diye sorun. Uygulayıcının "bizde böyle olmaz" dediği her nokta, prosedür ile fiili süreç arasındaki farkı gösterir.
Diyagram ne kadar ayrıntılı olmalı?
Ayrıntı düzeyi amaca göre belirlenir. Yönetime sunulacak genel bakış birkaç kutudan oluşabilir; yazılıma çevrilecek akış ise istisnaları ve hata yollarını da gösterir. Her diyagram tek bir ayrıntı düzeyinde kalmalı, derin ayrıntılar alt süreçlere taşınmalıdır.