Arama:

BPMN ile süreç modelleme dersi #2

Giriş

Bugünkü dersimizde basit bir Sipariş süreci ve Satınalma süreci inceleyeceğiz ve süreç tasarımında kullanılan araçlar hakkında biraz yorum yapacağız. Tasarımların karmaşık hale gelmemesi için süreç içerisinde Alt süreçlere tanışacağız (Subprocess). Ayrıca, ilerleyen bölümde “olaylara dayalı ayrıştırıcı” (intermediate event-based gateway) ve kısmen de olsa diğer objeleri nasıl kullanacağımızı öğreneceğiz.

Alt-süreçler (Subprocesses)

Alt-süreçler birden fazla olan görevleri birleştirmesinde kullanılır. Amaç Tasarımları karmaşık halden çıkarıp daha okunaklı hale getirmek. Dahası, tasarımda kullanılan alt-süreç(leri) ihtiyaca göre başka yerlerde tekrar kullanabilmemizi sağlar.

Şekilde görüldüğü gibi yemeğinin hazırlanması bir alt-süreç olarak tasarlanmış ve bu özellikten dolayı değerli bir tasarım alanı kazanıyoruz. Detayı görmek istiyorsak (+) işaretine basarak başka bir editör sayfasından açıp inceleyebiliriz.Alt-süreçleri aslında ikiye ayrılıyor bir kapalı (+) ve diğeri de açık olan (-). Açık olanına ileri ki bölümde gösteriyor olacağım.

Kaynak: bpmn.io Blog

Bu bölümde aynı sürece ait iki tasarım (Şekil-1 ve Şekil-2) inceleyeceğiz. Şekil-1 üzerinde bulunan bazı görevleri tespit ederek alt-süreçlere dönüştürebiliriz. Şekil-2’de ise sürecin iyileştirilmiş hali bulunuyor, aralarında ki farklılıkları daha iyi görebilmeniz için hazırladım.

Şekil -1 |  Sipariş süreci (karmaşık)

Kırmızı çerçeve içerisine aldığımı iş akışları inceleyiniz. Burada, siparişin geçerli olup olmadığını. Siparişin geçerli olması durumunda, siparişin tutarı 1,000€ üzerinde ise %3’lük bir indirim uygulanacaktır. Bu görevi standart bir işlem olarak algılayıp yeni bir alt-süreç olarak tanımlayabiliriz, adını da “sipariş değerlendirme” koyalım. Aynı şekilde sevkıyat sürecinde bazı standart adımları başka bir alt-süreç olarak tanımlayabiliriz. Not: “Fatura kes” hariç – çünkü Satınalma’nın bir görevidir.

Şekil -2 |  Sipariş süreci (daha okunaklı)

Şekilde görüldüğü gibi iki tane alt-süreç kullanarak Modelimizi hafif ve daha okunaklı hale getirmiş bulunuyoruz. Birincisi “Siparişi değerlendir“, ikincisi de “Sevk et“. Her ikisi standart bir prosedüre bağlı olduğunu varsayarak alt-süreç olarak tanımladım ve böylece her zaman karşılaştığımız gibi, ikisini başka tasarımlarda tekrar değerlendirebiliriz.

Şekil -3 |  Satınalma süreci (basitleştirilmiş)

Aşağıdaki Satınalma sürecine bakarsak, turuncu renkte 3 kapalı(+) ve 1 tane de açık (-) alt-süreç (turuncu çerçeve)  olarak tanımlanmıştır. Açık konumunda ki bu alt-süreç ise ihtiyaçtan dolay açık sergilenmiştir. Üzerinde yakından çalışıp bir değişiklik yapmak istiyorsunuz o yüzden görsel olarak açık olması daha uygundur. Unutmayalım, her şey ihtiyaca göre tasarlanır, bazen istemezsek de karmaşık olabilir.

Şekil -4 |  Koşullara bağlı bir süreç tasarımı (Pizzam nerede kaldı)

Bu çalışmanın sonunda ise olaylara bağlı görevlerin nasıl tetiklendiğini öğreneceğiz ve bununu için “Pizzam nerede kaldı” örneği üzerinden gitmeyi uygun buldum. Sürecinizi tasarlarken bazı aksiyonların istenilen koşullara erişince harekete geçmesini isteyebilirsiniz. Bunun için bir tetikleme mekanizmasına ihtiyacınız olacak. İşte tam burada bir “event-based “ objeler devreye giriyor örnek tasarıma bakarsak daha da iyi anlaşılır.

Süreç nasıl işliyor?

  1. Acıktınız ve bir Pizza beğeniyorsunuz.
  2. Siparişi veriyorsunuz.
  3. 30 dakika bekliyorsunuz.
  4. Siparişiniz gelirse afiyetle Pizza tüketiyorsunuz.
  5. Gelmediği taktirde, Pizzacıyı arayıp halen beklediğinizi söylersiniz.
  6. Telefon görüşmesinden 30 dak. içerisinde tekrar arıyorsunuz.
  7. Üçüncü arama sonunda beklemekten sıkılıp siparişi iptal edersiniz.

Dikkat ederseniz en alt kolda bir “conditional intermediate event  bulunuyor. Bu obje, Telefonla arama – bekleme döngüsünü 3 seferle ile sınırlandırıyor, aslında sizin belirleyeceğiniz şartla (condition) süreci sınırlandırıyor. Yoksa sürekli arar durursunuz. Kırmızı çerçevede gördüğünüz  “event-based Gatway” ise meydana gelen koşula göre süreci ayrıştırıyor. Pizzanız ulaşırsa tüketirsiniz, gecikirse de 30 dakikada bir Pizzacı arar durursunuz, fakat daha sonrası dayanamayıp sipariş iptal edersiniz:) 

Kendini geliştirmek isteyen arkadaşlar

Bu konuda farklı senaryolar üzerinde çalışmalarını tavsiye ederim, lakin süreç dünyasında çok yaygın kullanılan bir tekniktir. Örneğin bir gönderiniz var (Kargo) ve 3 Nakliye firmasından teklif bekliyorsunuz. Çağrıya ilk cevap veren Nakliye firmasına taşıma işi verilecektir.

Bu örneği ödev olarak kabul edenler bana admin@kolaybpm.com adresi üzerinden çözümlerini yollayabilirler. Unutmayın, bu konuda çok sayıda farklı tasarım yapılabilir, önemli olan Notation ile uyumlu olması, sade ve çalışır bir model olmasıdır. – Kolay gelsin

BPMN ile süreç modelleme dersi #1

Giriş

Uzun bir aradan sonra tekrar bir arada olmak güzel! BPMN 2.0 süreç modelleri merak eden veya oluşturmak isteyenlere önümüzde ki 3 hafta boyunca beni takip edebilir. Örnek süreçler üzerinden gideceğiz, mümkün mertebede doğru bir şekilde nasıl tasarım yapılır, yanlış tasarımlara da dikkat çekeceğim. Vakit kaybetmeden, ilk modelimiz olan “Hasar kayıt Raporlama” süreci inceliyor olacağız.

Senaryomuz şöyle; Eviniz yanıyor ve maddi hasar meydana geliyor. Sigorta şirketinize meydana gelmiş olan yangını bildiriyorsunuz. Diğer yandan bu olayda İtfaiye dahil olduysa, itfaiye merkezinden de bir Rapor alıyorsunuz. Sonunda talep ettiğimiz Raporlara ulaşınca birleşik bir Raporu hazırlıyoruz.

Aktörlerimiz:

Mülk sahibi (ilgili yerlerden Raporları talep eden ve sonunda hazar Raporu hazırlayandır), Sigorta Şirketi ( Hak sahibinin talep ettiği Raporunu oluşturan ve gönderen) ve İtfaiye Merkezi ( Yangını söndürmek için dahil olduysa, yangın Raporunu hazırlayandır).

Sürecin işleyişi (Açıklamalı):

  1. Yangın meydana geliyor (Başlat) simgesi olarak gösteriliyor. 
  2. Yol ikiye ayrılıyor ve her iki kolda ki görevler tamamlanıncaya kadar süreç devam ediyor.  Aynı zamanda  Bir yandan Sigorta şirketine Yangını bildiriyoruz, aynı zamanda İtfaiye yangına müdahale etmişse, “evet” veya “hayır” yönünde ilerliyoruz. veya demek ve birden fazla olabilir
  3. İtfaiye dahil olması durumunda Mesaj gönderip bir Rapor talep ediyoruz ve İtfaiye merkezinden Rapor bize  ulaşır. Bir olaya bağlı gönderilen bir mesajbir olaya bağlı gelen mesaj
  4. İtfaiye sürece dahil olmadıysa, yolumuza devam edip sadece Sigorta Şirketinden gelecek olan Raporu değerlendireceğiz.
  5. Diğer kolda ise, yangını Sigorta şirketine yangını bildiriyoruz. Sigorta Şirketi mesajımız alıyor, dönüşü ise talep edilen Raporu gönderilmesiyle son buluyor. mesajı aldı (başla)mesajı gönder (Bitir)
  6. Her iki yönden ulaşan Raporların gelmesiyle birlikte yolumuzu  tekrar birleştirerek son göreve, yani Raporu oluşturmaya yöneliyoruz.Görevi temsil eder
  7. Tüm görevi tamamlayınca süreci burada bitiriyoruz.Sürecin sonu simgeler

Süreç Haritası:

Tasarım önerileri:

  1. Şekilde gördüğünüz gibi süreci en az simge kullanarak tasarlamak makbul olandır. Önemli olan okunabilen ve tabii ki çalışan bir süreç olması.
  2. Üç paydaş (Havuz) arasında ki bilgi iletişimi bir mektup sarfı simgesi ile gösterilir. Giden ve gelen mesajlar sadece bir dosya alış-verişi olarak algılamak lazım, bu ihtiyaca göre bir ürün veya malzeme de olabileceğini unutmayalım.
  3. Modelinizde kullanacağınız görevleri (Task) doğru isimlendirmek gerekiyor, böylece süreç modeliniz daha daha iyi anlaşılır ve profesyonel görünür.
  4. Modeliniz oluşturmadan önce şu soruları sormalı; Ne/ne için? Örn.:Malzeme ihtiyacı, Kim? Örn.:Depo Sorumlusu, Nasıl/neyle? Örn.:Satınalma talep Formu doldurulması, Ne zaman? Örn.:Malzeme eksilince.
  5. Unutmayın, Modellemek istediğiniz süreçleri her tasarımcı farklı tasarlayabilir, aynı süreci anlatan çok sayıda çözüm kabul edilebilir. Anlatmak istediğiniz süreci ne kadar detaylı olması gerektiğini doğrusu siz belirleyeceksiniz. Bu tamamen oluşturacağınız çözüme bağlıdır. Örneğin Kalite iş süreçleri detay ister ve mümkünse tek bir Resimde her şey görünmesini istenir. Fakat bir yazılım entegrasyonu için hazırlayacağınız yeni iş süreçleriniz’de bu kadar detay gerekmeyecektir çünkü yeni sisteminin hangi iş süreçlerinde kullanılacaksa, fonksiyonel iletişim/etkileşimleri odaklanmanız yeterli olacaktır. Evet, karmaşık görülen hiç bir Uygulamayı kimse okumak istemez, bırakın yanından bile geçmek istemez.
  6. Tavsiyem, mümkün olduğu kadar asgari sayıda objeler kullanmaya bakın, bir ressam gibi fırçanızı hemen harcamayın sade olmaya çalışın, böylece daha çok esas işinize odaklanabilirsiniz. Elbette karmaşık ve iç-içe olan bir tasarımı daha sonra da basitleştirebilirsiniz ama değerli vaktinizi ve sabrınızı alacaktır. Bu tür karmaşıklığı nasıl önlenebileceğini bir sonra ki bölümünde sizlerle paylaşır olacağım.

Buradan yola çıkarak BPMN ile süreç modelleme dersi #2 geçebilirsiniz. Hazırlamış olduğum bu Modelde Satınalma süreci inceleyeceğiz ve size tasarımla ilgili yeni ipuçları vermeye çalışacağım.

 

ARIS Express ile Süreç Tasarımı

  • ARIS Express ücretsizdir, indirmek için buraya tıklayın
  • İş süreç Yönetimi alanında çalışan herkes için kullanışlı bir Süreç Tasarım araçıdır.
  • ARIS Express Tasarım yapan ekipler birlikte çalışabilir, kullanışlı ve üretken bir çalışma ortamı sunar.
  • Başta Organizasyon yapısı olmak üzere, süreçleri, uygulamaları (BT), Veri ve daha fazlasını tasarlamanız mümkün.
  • Ücretsiz eğitim, Video ve Doküman desteği (ARIS community)
  • Çalışmalarını saklayabilir, tekrar kullanabilir ve ARIS 7/9 (Software AG’nin Ticari BPM Ürünleri) kolayca aktarılabilir.

Tanıtım Videoları