30 saniyelik özet

Process Mapping, yani süreç haritalama, bir işin başlangıçtan sonuca nasıl ilerlediğini; faaliyetler, kararlar, roller ve bilgi akışlarıyla görünür kılar. BPMN ise bu işleyişi ortak sembollerle anlatmaya yarayan bir standarttır. İyi bir süreç modeli, güzel görünen bir diyagramdan fazlasını sunar: sorumluluğu, beklemeleri, istisnaları ve karar koşullarını tartışılabilir hâle getirir. Modelin ayrıntısı, cevaplanacak soruya göre seçilmelidir. Süreci çizmek, doğrulandığı veya otomasyona hazır olduğu anlamına gelmez.

Neden önemli?

Bir abonelik yükseltme talebinde satışın işi müşterinin teklifi kabul etmesiyle bitebilir. Finans için iş faturalama tamamlanınca, ürün ekibi için kullanım hakkı açılınca tamamlanır. Bu sınırlar konuşulmadığında her ekip kendi görevini bitirmiş görünürken müşteri yeni hizmete erişemeyebilir.

Süreç haritası, ekiplerin tamamlanmış saydığı adımları birbirine bağlar. Bir faaliyet sonraki adıma hangi bilgiyle geçiyor? Karar çıkmazsa iş nerede bekliyor? Başarısız işlemden sonra kim müdahale ediyor? Bu sorular, arayüz gereksinimlerinin veya görev listelerinin tek başına göstermediği boşlukları ortaya çıkarır.

Junior bir iş analisti için haritalama, farklı anlatımları ortak bir modelde birleştirme becerisidir. Yönetici için ise sorumluluk ve yatırım seçeneklerini değerlendirme aracıdır. Süreç anlaşılmadan alınan otomasyon kararı, belirsizliği hızlandırabilir: Yanlış koşul daha hızlı uygulanır, eksik bilgi daha fazla sisteme yayılır.

Endüstri mühendisliği açısından harita, sistemin parçaları arasındaki bağı görmeyi sağlar. Bununla birlikte diyagram tek başına darboğazı kanıtlamaz. Darboğaz, akışı sınırlayan noktadır; belirlemek için işlem hacmi, kapasite ve süre bilgisi gerekir. Model bu ölçülerin hangi faaliyet ve geçişlerle ilişkilendirileceğini gösterir.

Terim nedir?

Süreç haritalama bir yöntemdir; BPMN bu yöntemde kullanılabilecek bir anlatım standardıdır. BPMN, Business Process Model and Notation ifadesinin kısaltmasıdır ve Object Management Group tarafından yayımlanır. Her süreç haritası BPMN kullanmak zorunda değildir. Ancak ekipler ortak sembollerle ayrıntılı işleyişi tartışacaksa standart bir dil yanlış yorumları azaltabilir.

BPMN’de olaylar, süreçte gerçekleşen ve akışı etkileyen durumları temsil eder. Görevler yapılacak işi gösterir. Geçitler akışın hangi koşullarda ayrılacağını veya birleşeceğini anlatır. Katılımcılar havuzlarla, süreç içindeki sorumluluk veya sınıflandırmalar kulvarlarla gösterilebilir. Sembollerin anlamı gelişigüzel değiştirildiğinde ortak dilin faydası kaybolur.

Sıra akışı, süreç içindeki faaliyetlerin ilerleme ilişkisini gösterir. Mesaj akışı ise farklı katılımcılar arasındaki iletişimi anlatır. Bu ayrım önemlidir: Bir müşterinin talep göndermesiyle şirketin bu talebi işlemesi aynı katılımcının faaliyetleri değildir. Buna karşılık aynı şirket içindeki her departmanı ayrı katılımcı gibi göstermek de her durumda doğru modelleme tercihi olmayabilir.

Faaliyet adları somut olmalıdır. “Finans” bir rolü, “finans işlemleri” belirsiz bir iş grubunu anlatır. “Müşterinin kredi durumunu kontrol et” daha açık bir görevdir. Karar noktalarında da “uygun mu?” yerine hangi uygunluğun değerlendirildiği ve her yolun hangi koşulda seçildiği yazılmalıdır.

Bütün ayrıntılar aynı seviyede gösterilmez. Genel model, önemli aşamaları ve sorumlulukları anlatabilir. Karmaşık bir aşama alt süreç olarak ayrıca açılabilir. Böylece yönetici bütün akışı değerlendirirken uygulama ekibi ilgili bölümün ayrıntısını inceleyebilir. Ayrıntı düzeyi ile modelin amacı arasındaki bağ korunmalıdır.

Bir diyagramın standart semboller içermesi, çalıştırılabilir otomasyon modeli olduğu anlamına gelmez. Süreç motorunda yürütülecek modelde görevlerin uygulanması, veri, hata davranışı ve teknik bağlantılar ayrıca tanımlanır. İş analizi için hazırlanan model ile uygulama modeli arasındaki ilişki açıkça yönetilmelidir.

Gerçek vaka: Goldman Sachs’ta ortak süreç dili

Camunda’nın Goldman Sachs vaka sayfası, şirketin merkezi bir iş akışı otomasyonu platformu oluşturduğunu anlatıyor. Platformun ödeme işleme, müşteri faturalama ve karar hizmetleri gibi farklı kullanım alanlarını desteklediği belirtiliyor. BPMN ve DMN’nin hem geliştiricilerin hem de iş kullanıcılarının çalışmasına hizmet ettiği aktarılıyor.

DMN, Decision Model and Notation ifadesinin kısaltmasıdır; karar mantığını modellemek için kullanılan ayrı bir standarttır. Vaka sayfasında DMN tabanlı karar hizmetlerinin iş kurallarını tutarlı biçimde modellemek ve yürütmek için kullanıldığı açıklanıyor.

Bu örnek, süreç akışı ile ayrıntılı karar mantığının ortak bir çalışma düzeninde ele alınabileceğini gösteriyor. Ancak sayfa, belirli bir diyagramın tek başına hangi performans artışına neden olduğunu ölçmüyor. Dolayısıyla kaynakta anlatılan platform kullanımını, BPMN kullanan her kuruluşun aynı sonucu elde edeceğinin kanıtı olarak değerlendirmemek gerekir.

Kaynak: Camunda, “Goldman Sachs + Camunda”.

Standart başvurusu: Object Management Group, BPMN 2.0.2.

Varsayımsal örnek: Abonelik yükseltme süreci

İşletmelere abonelikle yazılım sunan bir şirkette müşterinin daha kapsamlı bir pakete geçmek istediğini düşünelim. İlk gereksinim “paketi değiştir” düğmesi olsun. Analist, düğmenin arkasındaki süreci satış, finans, operasyon ve teknik ekiple birlikte haritalar.

Başlangıç olayı müşterinin yükseltme talebidir. Ancak talep, kabul edilmiş teklif veya uygulanabilir sözleşme değişikliğiyle aynı şey olmayabilir. Modelde hangi olayın süreci başlattığı netleştirilir. Bitiş koşulu da yalnızca paket kaydının değişmesi yerine işletmenin üzerinde uzlaştığı tamamlanma durumuyla tanımlanır.

Akışta önce mevcut abonelik ve sözleşme koşulları kontrol edilebilir. Bazı müşterilerde ek onay gerekebilir; bazı durumlarda faturalama ile kullanım hakkının açılması arasında bağımlılık bulunabilir. Bunlar örneğe ait varsayımlardır. Gerçek uygulamada şirketin sözleşme ve operasyon kurallarından doğrulanmalıdır.

Model kararları görünür kılar: Talep uygun değilse müşteri nasıl bilgilendirilecek? Onay beklerken hangi ekip takip edecek? Kullanım hakkı açılmış, fakat ilgili kayıt güncellenememişse süreç hangi durumda kalacak? Başarısızlık yolları çizilmediğinde ekipler yalnızca sorunsuz ilerleyen işlem konusunda anlaşmış olabilir.

Çalıştay sırasında finansın “tamamlandı” dediği an ile müşterinin hizmete eriştiği anın farklı olduğu anlaşılabilir. Analist, bu farkı modelde ayrı olaylar olarak gösterir. Ardından hangi olayın müşteriye bildirim göndereceği ve hangi koşulun operasyonel takip gerektireceği kararlaştırılır.

Doğrulama için örnek bir talep model üzerinde baştan sona yürütülür. Ardından onay gecikmesi ve sistem hatası gibi farklı senaryolar denenir. Her geçişte gereken bilgi ve sorumlu rol kontrol edilir. Model, bu inceleme sonrasında geliştirme kapsamı ve kabul koşulları için dayanak hâline gelir.

Yaygın üç hata

  1. Her şeyi tek diyagrama sığdırmak. Çok ayrıntılı bir model, ilişkileri görünür kılmak yerine okumayı zorlaştırabilir. Genel akışı ve gerekli alt süreçleri ayrı seviyelerde gösterin. Bir ayrıntının modele girmesi, okuyucunun hangi kararı değerlendirmesine yardımcı olduğu üzerinden gerekçelendirilmelidir.
  2. Karar koşullarını belirsiz bırakmak. Farklı yollar çizmek yeterli değildir; hangi durumda hangi yolun seçildiği anlaşılmalıdır. Çelişen veya eksik koşullar uygulamada farklı yorumlara yol açabilir. Ayrıntılı kurallar ayrı tutulabilir, fakat süreç modelinden ilgili kuralın kaynağına ulaşılabilmelidir.
  3. Modeli kullanıcılarla sınamadan tamamlanmış saymak. Sembol kontrolü, iş davranışının doğruluğunu kanıtlamaz. İşi yapan kişilerle gerçek senaryoları yürütün. Özellikle beklemeleri, devir noktalarını ve hata sonrası davranışı kontrol edin. Modeldeki her ok, işletmede açıklanabilir bir geçişi temsil etmelidir.

Mini uygulama: Süreç modeli kontrol kartı

Bir model hazırlamadan önce amacını yazın. Ardından aşağıdaki sorularla değerlendirin.

Amaç
Model hangi kararı veya problemi açıklıyor?
Kapsam
Başlangıç ve bitiş koşulları belirli mi?
Roller
Her önemli faaliyetin sorumlusu anlaşılıyor mu?
Görevler
Faaliyet adları somut bir işi anlatıyor mu?
Kararlar
Alternatif yolların koşulları açık mı?
Bilgi
Geçiş için gereken veri ve belge biliniyor mu?
Bekleme
İşin durduğu noktalar görünür mü?
İstisna
Hata ve geri dönüş yolları ele alındı mı?
Doğrulama
Model hangi senaryolarla kontrol edildi?
Güncellik
Değişikliği kim izliyor, model ne zaman gözden geçirildi?

Kontrolün sonunda açık kalan soruları ayrı kaydedin. Bir diyagramı tamamlamak için bilinmeyen koşulları varsayımla kapatmayın. Modelin en yararlı çıktısı bazen yeni bir kutu değil, ekiplerin henüz karar vermediği bir ilişkinin görünür hâle gelmesidir.

İlgili terimler

As-Is Process, To-Be Process, Requirements Elicitation, Stakeholder Analysis, Business Rule, Functional Requirement, Non-Functional Requirement, Use Case, Acceptance Criteria, Dependency Management, Gap Analysis