BPMN 2.0 Uygulaması: Bir İade Sürecini Adım Adım Modelleyin
Güncelleme tarihi: 21 saat önce
Bir süreç çizimini iki farklı ekip okuduğunda aynı işi mi anlıyor? BPMN 2.0, süreçleri ortak sembollerle ifade etmek için kullanılan bir standarttır. Eğitimde değerini, sembolleri sayabildiğinizde değil, bir işin nasıl ilerlediğini açıkça anlatabildiğinizde görürsünüz.
Bu uygulamada kurgusal bir ürün iadesini modelleyeceğiz. Amaç, ilk denemede bütün olasılıkları çizmek değil; başlangıcı, kararları, sorumluları ve sonuçları tutarlı bir akışta birleştirmek.
Çizmeden önce kapsamı yazın
Sürecin müşterinin iade talebiyle başladığını varsayalım. Hangi sonuçla bitecek: İadenin kabulü, reddi veya ödemenin tamamlanması mı? “İade süreci” başlığı bu ayrımı tek başına açıklamaz.
Örnekte kapsamı, talebin alınmasından kararın müşteriye bildirilmesine kadar sınırlayalım. Talep bilgileri incelenecek, uygunluk kararı verilecek, gerekli işlem yapılacak ve sonuç bildirilecek. Ödeme işlemini ayrı süreç olarak ele alırsanız bunu modelin notlarında belirtin.
En az öğeyle ilk modeli kurun
Başlangıç olayıyla tetikleyiciyi, görevlerle yapılacak işleri, uygun bir karar geçidiyle ayrılan yolları ve bitiş olaylarıyla sonuçları gösterin. Görev adlarını “Talebi incele” gibi eylemle yazın.
“İade koşulları sağlanıyor mu?” kararında çıkış koşullarını adlandırın. Birbirini dışlayan yollar mı, aynı anda ilerleyecek işler mi tasarladığınızı ayırt edin. Eksik bilgi durumunu doğrudan ret saymak yerine bilginin tamamlanacağı yolu ayrıca tartışın.
Sorumluluk ve iletişimi ayırın
Kulvarlar, aynı süreç içindeki sorumlulukları anlatmaya yardımcı olur. Ayrı katılımcılar arasındaki iletişimde ise mesaj akışının anlamını öğrenmek gerekir. Sıra akışı ile mesaj akışını birbirinin yerine kullanmayın.
İlk modelde temsilci ve değerlendirme ekibinin sorumluluklarını ayırın. Sonra müşteriyle hangi adımda iletişim kurulduğunu işaretleyin. Bu ayrım, modelin kurum içi işleri ve dış iletişimi aynı çizgiyle karıştırmasını önler.
Modeli üç örnekle yürütün
Her örneği çizim üzerinde baştan sona izleyin. Ulaşılamayan adım, koşulsuz bırakılmış yol veya bitmeyen döngü var mı? Modeli başka bir katılımcıya açıklatmak da iyi bir kontrol yöntemidir.
Bilgileri tam ve uygun bir talep.
Koşulları karşılamayan bir talep.
Eksik bilgiyle gelen ve tamamlanmayı bekleyen bir talep.
Diyagram henüz çalışan uygulama değildir
BPMN standardına uygun bir çizim, her yazılımda kendiliğinden çalışacak anlamına gelmez. Formlar, veriler, yetkiler, entegrasyonlar ve kullanılan motorun desteklediği öğeler ayrıca tasarlanır.
Çalışma sonunda kapsam notu, okunabilir model ve test senaryolarını birlikte hazırlayın. Teknik uyarlamaya geçerken bu üçü aynı işi tarif etmeli.
Diyagramı başka bir katılımcıya devredin
Modeli çizen kişi, çizimde bulunmayan ayrıntıları sözlü olarak tamamlamaya eğilimli olabilir. Bu nedenle ilk kontrolü modelin hazırlanmasına katılmamış bir kişi yapsın. Görevleri ve karar yollarını kendi cümleleriyle anlatsın.
“Burada aslında şöyle olacaktı” diye açıklama ihtiyacı duyduğunuz noktaları not edin. Koşul etiketi mi eksik, kapsam mı belirsiz, yoksa iş kuralında mı anlaşmazlık var? Çizimi büyütmeden önce eksikliğin türünü belirleyin.
İlgili eğitimler
Bu konuyu kendi rolünüz ve uygulama ihtiyacınız doğrultusunda çalışmak için aşağıdaki eğitimlerin içeriklerini inceleyebilirsiniz.
Okumaya devam edin
Kavram kaynakları
Kaynak kontrolü: 10 Kasım 2026. Kavram kaynağı, OMG’nin BPMN 2.0 standardıdır. İade süreci, standardı öğrenmek amacıyla hazırlanmış bir Academy uygulama örneğidir.
Yazının çıkış noktası
Bu Academy sürümü, Gürkan Platin’in aynı konudaki yazısından hareketle eğitim ve uygulama odağıyla yeniden hazırlanmıştır. Kavramsal anlatımın özgün sürümünü kişisel blogunda okuyabilirsiniz.
Yorumlar