BPMN 2.0

BPMN nedir

Serbest çizimle notasyon arasındaki fark ilk bakışta biçimsel görünse de sonucu belirleyicidir. Serbest bir çizimde bir dikdörtgenin ne anlama geldiğini yalnızca onu çizen kişi bilir; altı ay sonra aynı şemaya bakan başka biri, o kutunun bir iş adımı mı yoksa bir karar mı olduğunu tahmin etmek zorunda kalır. BPMN'de ise dikdörtgen bir faaliyet, elmas bir kapı, çember bir olaydır ve bu karşılıklar tartışmaya açık değildir. Bir süreç dokümanının kurumda kişiden bağımsız olarak yaşaması isteniyorsa notasyon bir tercih değil zorunluluktur.

Notasyonun ikinci faydası teknik tarafta ortaya çıkıyor. BPMN diyagramları arka planda XML olarak saklanır, dolayısıyla Camunda, Bizagi veya Signavio gibi araçlarda çizilen bir model doğrudan bir iş akışı motoruna verilebilir. Serbest çizim yalnızca bir resimdir ve veriyle konuşamaz; BPMN modeli hem insanın hem yazılımın okuyabildiği tek bir kaynaktır.

Çekirdek semboller

Tam BPMN 2.0 spesifikasyonu yüzün üzerinde sembol tanımlar, ancak bunların büyük çoğunluğu günlük süreç geliştirme işinde hiç kullanılmaz. Sahada karşılaşılan süreçlerin neredeyse tamamı aşağıdaki yedi sembolle modellenebilir; geri kalanı ise ancak özel durumlarda ve genellikle yazılım tarafında ihtiyaç haline gelir.

Havuz ve kulvar

Bu iki kavram sürekli birbirinin yerine kullanılıyor, oysa aralarındaki fark diyagramın teknik olarak doğru olup olmadığını belirliyor.

Pratikte ayrım şöyle kuruluyor: kendi kuruluşun bir havuzdur ve içindeki operasyon, müşteri hizmetleri, muhasebe gibi birimler onun kulvarlarıdır. Müşteri ile anlaşmalı acente ise ayrı birer havuzdur, çünkü onların iç işleyişini sen yönetmiyorsun; onlarla ilişkin yalnızca karşılıklı mesaj alışverişinden ibarettir ve diyagram da bunu kesikli okla göstermek zorundadır.

Kulvar sayısının kendisi de bir teşhis aracı olarak kullanılabiliyor. Bir süreç beş kulvara yayılıyorsa o süreçte en az dört el değiştirme var demektir ve her el değiştirme, bekleme süresinin, bilgi kaybının ve sorumluluk boşluğunun oluşabileceği bir aday noktadır. Kulvarsız çizilen bir akış şemasında bu noktalar hiç görünmez.

Kapılar

Kapıların en çok yanlış anlaşılan yanı, karar verdiklerinin sanılmasıdır. Kapı karar vermez, yalnızca daha önce alınmış bir kararın sonucuna göre akışı dallandırır. "Hasar var mı?" bir kapı etiketidir; hasarın fiilen kontrol edildiği iş ise ondan önce gelen bir görevdir ve diyagramda ayrıca gösterilmelidir.

İkinci kural, açılan her kapının kapanmak zorunda olmasıdır. Üç yola ayrılan bir XOR kapısı ya üç ayrı bitiş olayında sonlanır ya da bir birleştirme kapısında yeniden toplanır. Havada kalan bir dal, modelin en yaygın hatasıdır ve genellikle o senaryonun hiç düşünülmediğini gösterir.

Çözümlü örnek

Sık karşılaşılan hatalar

Kulvar yerine havuz kullanmak. Kendi departmanları ayrı havuzlara yerleştirildiğinde aralarında sıra akışı çizmek mümkün olmaz ve model teknik olarak hatalı hale gelir. Aynı kuruluşun birimleri her zaman tek bir havuzun kulvarlarıdır.

Kapıyı karar yerine koymak. Kapının içine "Yönetici onaylar mı?" yazmak yaygın bir hatadır; onaylama bir görevdir ve ayrı bir kutuda gösterilmesi gerekir, kapı yalnızca sonucuna göre dallanır.

Bitiş olayını unutmak. Her dalın bir bitişte sonlanması gerekir. Havada kalan bir ok genellikle o senaryonun sonuna kadar düşünülmediğine işaret eder.

Olması gerekeni çizmek. Model önce mevcut durumu anlatmalıdır. İdeal durum çizildiğinde iyileştirmenin ölçüleceği fark ortadan kalkar; mevcut durum ve hedef durum iki ayrı diyagram olarak tutulur.

Detay seviyesini karıştırmak. Aynı diyagramda hem "Gönderiyi teslim eder" hem "Barkodu okutur" adımlarının bulunması, okuyucunun sürecin ölçeğini kaybetmesine yol açar. Tek bir seviyede kalınır, daha fazla ayrıntı gerekiyorsa alt süreç açılır.