Arama:

Hangi Süreç Yönetim Sistemi seçemeliyim?

Bu soruyu bana çokça sorulan bir soru olmasından dolayı bunu kaleme almanın zamanı geldiğini düşünüyorum. Ama önce Süreç Yönetim Sistemlerinin genel kabiliyetlerine bir bakalım. İngilizcesi “BPMS” yani “Business Process Management Suite” olarak geçer. Kısaltmanın sonunda ki “S” harfi karşılığı “System” değil de “Suite” kullanmayı uygun görmüşler. 10 sene öncesini hatırlıyorum, o zaman süreç tasarımlarımızı “Eclipse IDE” de yapıyorduk, çalışma sonrası tasarımları export ettip BPMS’de aktif hale getiriyorduk. Yani biraz zahmetliydi, dahası Formlarda ki alanları sürece entegre etmek için bir çok eşleşme yapılması gerekiyordu bunun için Java dan anlamanız ve bazı yerlerde Kod yazmanız gerekiyordu. Bugün artık bunlara pek konuşmuyoruz sadece bir deneyim olarak aklımızda kaldı. Her şey ihtiyaca göre hızlı gelişti, artık Uygulamalar aynı ortamda sürelerinizi tasarlayabiliyor, süreçlerinizi iyileştirebiliyor ve kısa sürede devreye alabiliyorsunuz. Genel bakışta, bu Uygulamalar artı/eksisi aşağıda ki özelliklerine sahiplerdir :

Süreç tasarımı, Uluslararası kabul görmüş Tasarım standartlarında (BPMN) süreçlerinizi tasarlamanıza izin verir. Tasarımlarınızı standartlara uygun olup olmadığını aynı ortamda test edebilir ve hataları baştan önleyebilirsiniz.

Simülasyon, mevcut veya yeni Süreçlerinizin süre, maliyet ve sürecinin tekrarlanması gibi farklı senaryolar göre taklit etmenize izin verir. Böylece uygulamaya almadan önce sürecinizi ölcebilir, süreci iyileştirmek için fırsatınız olabilir.

Otomasyon, tekrarlanan iş süreçleri belli bir disiplin, maliyet ve kalitede gerçekleştirmek için bazı iş süreçlerinizi otomasyona alabilirsiniz. Başta talep Yönetimi olmak üzere her bir iş süreci için bir Form tasarlayabilmeniz sağlar. Daha sonra bu formlar iş akışında belirlediğiniz yetki ve kriterlere göre işlenmesini ve onaylanmasını sağlar.

Kural Yönetimi, iş süreçleriniz için koşullar belirlemenize yarıyor. İş ve Yönetmeliklere göre akışları yönetebilir, belirlediğiniz koşulları izleyebilir ve performans kriterlerinizi (KPI) burada belirleyebilirsiniz.
Kaynak Yönetimi, Süreçlerinizde yer alacak Organizasyon, Departmanları, grupları ve bunlara bağlı Personel ve yetkilerin belirlendiği bir yönetim modülü. LDAP ve Microsoft Active directory ile entegrasunu oldukca önemlidir.

Süreç izleme, Süreçlerinizin hangi aşamada olduğunu ve ilgili sürecin performansını süreçte yer alan Aktörlere göre raporlayabilirsiniz. Örneğin Talep kime ne zaman geldi ve na zaman onaylandı gibi süreleri kolaylıkla görüntüleyebilirsiniz.

Entegrasyon, belki de en çok merak edilen bu Suite’lerin başka sistemlerle entegre çalışmasını nasıl sağlayabiliriz. entegrasyunu zor mudur kolay mıdır? Örneğin Sistemin dışında olan bir Web sayfanıza gelen bir siparişin önce Müşteri Hizmetleri tarafından görüntülenmesini, daha sonra onaylanması ve Deponuza yönlendirebilirmiyiz acaba?. Yada, bir satın alma talebinin onaylanması durumunda Muhasebe Programınızda göndererek otomatik olarak yeni sipariş gerçekleştirebilirmiyiz? Evet, hepsi mümkün.
Yönetim kontrol paneli, en üst seviye yetkileri kullanarak Sisteme ve Modül bazında parametrik ayarlarının yapabilirsiniz.

Raporlama, tüm süreçlere ait performans verilerini yetkiler dahilinde görselleştirmeye ve mevcut verileri farklı dosya türlerinde dışarı aktarılmasına yarar. (CSV, PDF, XLS gibi)
Açık kaynaklı kod, yani “Opensource”, “Community” sürümleri bazen kısıtlı özelliklere sahip olsanızda ücretsiz yararlanabilir veya “Enterprise” olarak ilgili Ürün ve Modüllerine ait desteğini satın alabilirsiniz. (Subscription)

Sorunun cevabına gelince;

“İhtiyacınız neyse ona göre bir Sistem seçmelisiniz” derim! Bundan dolayı önce ihtiyaçlarınızı belirlemeniz gerekiyor ve ihtiyaçlarınızı da doğru belirlemelisiniz. Başta cevaplamanız gereken temel bir kaç soru olacaktır, şöyle;

  1. Bu Uygulamayla Kurumunuzun hangi sorunlarını çözmeye hedefliyorsunuz?
  2. Bu uygulama ile nasıl bir fayda sağlamasını hedefliyorsunuz (parasal, kalite, performans gibi)?
  3. Kurumsal gereksinimleriniz nelerdir?
  4. Fonksiyonel gereksinimleriniz nelerdir?
  5. Kaynak gereksinimleriniz nelerdir?
  6. Farklı sistemlerle entegrasyonu söz konusu mu?

Bu soruların cevaplarını bulabildiyseniz, süreç bazından incelemeler için aşağıdaki adımları takip edebilirsiniz.

  1. Mevcut iş süreçleri inceleyin ve hangi süreçleri değiştirmek veya iyileştirmek istiyorsanız onlara odaklanın.
  2. Öncesinde, Simülasyon kabiliyeti olan bir Modelleme aracı temin edin **
  3. Her bir iş süreci için  iş akış şemaları hazırlayın. (BPMN 2.0)
  4. Sürecin maliyetini, işlem sürelerini tespit etmeye çalışın.
  5. Her süreç için kalite ve performans kriterlerini belirleyin.

TIP: ** Bizagi Modeller ücretsiz modelleme ve simülasyon yapabiliyor. başka güzel bir araç ise Cloud (SaaS) tabanlı  Signavio Process Manager , 30 günlük deneme sürümü mevcut olup,  profesyonel bir Modelleme aracıdır. Her iki araç BPMN 2.0 modelemeyi %80-%95 kadar destekliyor. Bir iş analisti olarak bu tür araçlara sürekli ihtiyacımız olur.

Yeni iş süreçleri tasarlayın 

  1. Yeni iş süreçleriniz için iş akış modelleri hazırlayın (BPMN 2.0 standartları kullanın)
  2. İş ve Süreç sahipleri ile birlikte yeni iş sürecine ait tasarımı değerlendirin, risk analize yapın.
  3. Yeni süreç başka süreçlerle olan ilişkileri ve etkileşimi değerlendirin.
  4. Yeni süreçlere ait maliyet, işlem süresi, performans kriterleri ve kaliteyi göz önünde bulundurarak sürecinizi simule edin.

Fonksiyonel gereksinimlerinizi belirleyin

  1. İş akışlarınızda kullanılacak Formları kağıt üstünde veya elektronik ortamda tasarlayın
  2. Gereksiz alanları dikkate almayın, sadece lüzumlu olanları Formlara dahil ediniz.
  3. Onaylama mekanizmasında yer alacak önemli alanları belirleyin, “onayla”, “gözden geçir” veya “reddet” gibi seçenekleri kullanın. Açıklama kısımları mutlaka ekleyin.
  4. Eklenti kullanacaksa izin verilen ebat ve Dosya türleri belirleyin.
  5. İş akışında geriye dönük bir Formun ve ilişkin Belgeleri tekrar görüntüleme gibi beklentiniz varsa onu gereksinimler arasına yer almasına dikkat ediniz.
  6. Raporlama ihityaçlarınızı belirleyiniz, ne kadar detay sizin için yeterli olur. Süreç bazında, Personel/Görev bazında  neyi görmek istiyorsanız onu ihityaçlarınız arasında bulundurmayı unutmayin.

Kaynak gereksinimlerinizi belirleyin

  1. Person gereksinimlerinizi planlayın. Örneğin, Ek yazılım geliştirme yapılacak mı, ona göre Kaynak gerekli olacak.
  2. Sistemin Yönetimi, desteğini ve bakımını planlayın.
  3. Eğitim ihtiyaçlarınızı belirleyin.
  4. Test ortamını kurun
  5. Tedarikciye ödenecek yıllık Sistem destek ve/ya Lisans maliyetleri hesaplayınız.
  6. Operasyonel maliyetleriniz hesaplayın.

Sistem gereksinimleriniz belirleyin (aynı zamanda kapasite planlaması)

  1. Süreç ve alt süreç sayısı = (toplam süreç sayısı)
  2. Sürecin günlük/haftalık/aylık tekrarlama döngüsü
  3. Kullanıcı sayısı
  4. Veri gereksinimleri ( ERP, CRM, İnternet, IoT, vs)
  5. Veri depolama gereksinimleri
  6. Yedekleme ve Veri geri dönme prosedürlerine dahil ediniz.
  7. Sunucu (Donanım) gereksinimleri
  8. Tercih edilen İşletim Sistemi ve Veri tabanları (*Lisans ve mevcut IT altyapı dikkate alarak) 
  9. Mobil erişimi
  10. Erişim yetkileri  –> LDAP/AD
  11. Haberleşme gereksinimleri –> MAIL/SMTP
  12. Güvenlik gereksinimleri, –> IP PORT, Firewall, HTTPS
  13. Entegrasyon ve sorgulama gereksinimleri –> REST/API/3th party Connectors

BPMS  seçimine gelince, çok sayıda seçenekleriniz olduğunu bilmelisiniz.

Tbl.-1 de sıraladığım  ürünlerinin önerebilirim, kurdum ve bir çoğunu da denedim.

Kolay kurulum, kolay öğrenme ve kolay kullanım gibi kriterleri ön planda tutmadan değerlendirme yapmanız daha verimli olur. Tüm gereksinimlerinize dikkate alın ve karşılamaya çalışınız. Dikkate almanız gereken bir husus daha; Bilgi işlem altyapınız Microsoft ise Microsoft platformunda çalışan bir BPMS seçmeniz homojen altyapınızı korumak için daha doğru bir yaklaşım olur. Linux tabanlı ve Linux + Windows karmaşık bir altyapıya sahipseniz, muhtemelen JAVA veya PHP tabanlı bir BPMS değerlendirmeye alabilirsiniz.

Tbl.1 – Süreç tasarımı ve otomasyonu Ürünlerin listesi 

Ürün/Üretici Platform Açık kaynak kodlu
intalio BPMS JAVA evet
Comunda JAVA evet
Activity JAVA evet
ProcessMaker PHP evet
Bizagi Studio .NET hayır
Software AG .NET hayır
Adonis | BOC .NET hayır
ElmaBPM .NET kısmen
iGrafiX .NET hayır
Signavio CLOUD hayır
Kissflow CLOUD hayır
BPMOnline CLOUD hayır

Tedarkci seçimi, dikkat edilmesi gerekenler;

  1. Ürün İhtiyaçlarınızı ne kadarını karşılıyor (asgari %70 hedefleyin)
  2. Karşılanamayan ihtiyaçlar, üreticinin kısa vadede yol haritasında yer alıyor mu?
  3. Güncellemeleri ne sıklıkta yapılıyor ve güncelleme işlemi uzun ve zorlayıcı bir süreç mi?
  4. “Community” Forumları takip edin, sorulara bakınız, sorunlara tatmin edici cevaplar alınabiliyor mu?
  5. Üreticinin Satış sonra destek hizmet Sözleşmesinin detaylarına bakınız (kapsamı), zorlandığınız bir anda süratle destek alabilecekmisiniz. Farklı destek seviyeleri inceleyip kapsamlarına bakın.
  6. Deneme süresi kısıtlı olan Ürünleri (30 gün gibi)  ilk başta onları test sırasına alın, zaman çabuk akıyor, vakit kaybetmeden testleriniz verilmiş sürede tamamlayın.
  7. Anlamadığınız Fonksiyonları araştırmak üzere, Eğitim Video’ları izleyin, Dokümantasyonları okuyun.
  8. Ek geliştirme veya entegrasyon gereken konularda Üreticinin API Kütüphanesini inceleyin, Geliştirme yapan arkadaşlarınızı tatmin edecek yeterli bilgi var mı, kendilerine sorun?

BPMN ile süreç modelleme dersi #3

Tekrardan merhaba,

Geçen hafta ki dersimizde basit bir iki süreç inceledik ve tasarımlarda kullanılan bazı araçlar hakkında yorum yaptık. Tasarımların karmaşık hale gelmemesi için süreç içerisinde Alt süreçlerin kullanımı ile ilgili bilgi ve ip uçları vermiştik. Bu hafta kaldığımız yerden devam etmek istiyorum ve Olaylara bağlı bir süreç tasarımına daha göz atmak istiyorum.

Örnek Senaryo 

Bir Kargo gönderiniz var ve 3 Nakliye firmasından teklif bekliyorsunuz. Çağrıya ilk cevap veren Nakliye firmasına taşıma işi verilecektir.

Çözüm | Süreç Tasarımı

Açıklama

  1.  Yukarıdaki Tasarımda görüldüğü gibi, süreç bir ihtiyaçla  yani Nakliye talebi ile başlıyor.
  2. Aynı anda 3 Firmadan teklif talep ediliyor
  3. Teklif talepleri her üç Nakliye Şirketine ulaşıyor.
  4. Şirketler farklı zamanlarda Tekliflerini hazırlayıp gönderiliyorlar.
  5. Şirketlerden gelen ilk Teklif hemen değerlendiriliyor ve bu Sevkıyat teslim ediliyor.

Burada dikkate alınması gereken en önemli olay, Event based Gateway  sürecin devam edebilmesi için ilk gelen Teklifi bekliyor olmasıdır. Umarım bu örnek çalışma sizin için faydalı olmuştur !

KolayBPM

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