Süreç Tasarımı
    • 11 Nov 2024
    • 9 Minutes to read
    • Dark
      Light

    Süreç Tasarımı

    • Dark
      Light

    Article summary

    Süreç Tasarımı Nasıl Yapılır ?

    Süreç Taslakları ilk seçildiğinde süreç projesi ile beraber açılır. Bu bölümden yeni tip tanımı ve gerekli elektronik formlar tasarlandıktan sonra artık akış tasarımı yapılabilir. Süreç projesi seçildikten sonra aşağıdaki menü oluşur.

    Yeni Süreç

    Burada Yeni Süreç tuşuna basılarak süreç sihirbazı ekranına geçilir.

    Akış Adı: Oluşturulacak olan sürecin adıdır. Tüm kullanıcıların önüne bu isim gelir. Bu nedenle bakıldığında ne olduğunun anlaşılması tavsiye edilir. Süreçler için örneğin "İzin Talep Süreci" demek çok uygun değildir. "İzin Talep" daha anlaşılır bir isim olacaktır.

    Tip Adı: Sürecin hangi tip ile tasarlanacağı bu bölümden seçilir.

    Form Adı: Seçilen tipe ait elektronik formlar listelenir. Sürecin başlangıç formu seçilmelidir.

    Organizasyon Şeması: Her akışın bir organizasyon şeması olmalıdır. Önceki kullanıcının yöneticisi, Akış sahibi yöneticisi gibi seçimler, departman yöneticilerinden seçimler yapabilmek için organizasyon şeması seçimi zorunludur.

    Organizasyon Şeması Değişikliği

    Taslak moduna alınan akışın organizasyon şeması değiştirildiğinde tarihçe ekranında tüm versiyonlar için organizasyon şeması seçimleri değişir.

    Takvim: Her akışın bir takvimi olmalı, kurumun en az 1 takvimi olmalıdır. Yapılan tüm KPI hesapları bu takvim üzerinden yapılır. Takvimin tüm tatil günlerinin düzenli girilmesi gerektiği unutulmamalıdır.

    Yetki Seti: Bu yetki setine göre akışı kimlerin başlatacağının belirlendiği bölümdür. Yetki setinde yazma yetkisi olan kullanıcılar bu akışı başlatabilirler.

    Tasarım Yetki Seti: Bu yetki setinde okuma yetkisinde olan kullanıcılar akışın tasarımını değiştirebilirler.

    Yönetim Yetki Seti: Bu yetki setinde okuma yetkisi olan kullanıcılar İş Akışı Yönetimi ekranında bu akış için işlem yapabilirler.

    Elektronik Posta ile Uyar: Eğer akış herhangi bir noktada hata alır ve hata kullanıcısına yönlenir ise aynı zamanda hata kullanıcısına elektronik posta göndererek bilgi verir.

    Hata Kullanıcısı: Süreç, herhangi bir aktivitede hata alır ise bu kullanıcıya yönlendirilir. Daha sonra her aktivite için bu kullanıcı değiştirilebilir.

    Açıklama: Sürecin son kullanıcının da önüne gelen açıklamasıdır.

    Tasarım

    Süreç tasarımı aşağıda görünen ekranda yapılır. Ekranın solunda süreç bileşenleri bulunur. Her bileşenin seçimi ile beraber sağ bölümde o bileşen ile ilgili tasarım ekranı açılır. Aynı zamanda ekranın üst bölümündeki işlem tuşları açılan ekrana göre değişiklik gösterir.

    Düzenle: Bu tuş aracılığı ile süreç üzerinde sadece aktivite özelliklerinde değişiklik yapılabilir. Akışın çiziminde herhangi bir değişiklik yapılamaz. Akışın versiyon numarası değişmez ve mevcutta çalışan akışlar kaldıkları yere göre yapılan değişiklikleri alarak devam ederler.

    Versiyonla: Bu seçenek ile akışın tasarımında da değişiklik yapılabilir, yeni aktiviteler eklenebilir, eskileri kaldırılabilir. Akış yayımlandığında versiyon numarası değişir. Daha önceki versiyonda başlatılan akışlar kendi versiyonunda çalışır, yeni başlatılan akışlar yeni versiyonda çalışırlar.

    Düzenleme ve Versiyonlama
    Bu 2 değişik yöntem ile akışlarda değişiklik yapılır ise platformlar arası taşıma esnasında gerekli kurallara uymak gerekir. Detay için taşıma ekranı yardımında Akışlarda Taşıma başlığı incelenmelidir.
    Dikkat !!!

    Akışlar iki yolla düzenlenir :

    1- Versiyonlama

    Bu durumda tüm kodlar ve parametreler yeni bir benzersiz akış numarası (Process ID) ve akış derleme numaraıs (Compile ID) ile kaydedilir.

    Bu andan itibaren yeni bir akış başlatıldığında, başlatılan akış yeni parameteler ve kodlar ile çalışır, önceki akışlar hiç bir şekilde yeni versiyondan etkilenmezler.

    2- Düzenleme

    Düzenleme işlemi yapıldığında benzersiz akış numarası (Process ID) değişmez, yeni bir akış derleme numarası (Compile ID) oluşur ve tüm parametreler ve kodlar bu akış derleme numarası (Compile ID) ile birlikte kaydedilir.

    Her iki durumda da arka tarafta Processs ID + Compile ID ile bir dll dosyası oluşur. Bu dll içerisinde yazılan kodlar bulunur.

    Bunlar,

    a- Makro içinde yazılmış kodlar, (Zamanlama makrosu dahil)

    b- SAP, Logo, gibi entegrasyon aktiviteleri, 

    c- Dosya kartı yaratma, belge yaratma kısmında yer alan eşletirme (Gelişmiş) kodları,

    d- Akışın global kodları,

    e- Akış bazında ortak kodlar.

    Bu durumda her yeni versiyonda bu kodlar yeniden bir dll dosyası oluşturmada kullanıldığından dolayı eski akışlar yeni yaratılan kodlardan oluşturulmuş dll dosyasını kullanmaz, daha önce oluşturulmuş olan dll dosyasını kullanır.

    Oysaki düzenleme durumunda, en son yapılan değişiklik ile birlikte eski akışlarda bu ortak kodları kullanır.

    Bunun dışında kalan tum parametreler:

    Zamanlayıcı değişkenleri, e-postanın kime gideceği, e-posta mesajı, başlığı, yerine getiren, link varsa gidecek link gibi tüm değişkenler (Yukarıda yazılanlar dışında kalan) akış derleme numarası (Compile ID) bazında veri tabanından çekilir ve ona göre çalışır. Zamanlayıcı süresi, ilk akış başladığı zaman göre çalışır.

    Aynı şekilde dosya kartı yarat kısmında eğer dosya kartı tipi değiştirilir ise bu bir parametre olarak tutulduğundan her akış derleme numarası (Compile ID) için farklı davranacaktır.

    Tüm bunların tek istisnası karar adımıdır.

    Karar adımlarında düzenleme modunda yeni bir bağlantı yaratılmasına izin vermez, fakat bağlantının gideceği adımlar değiştirilebilir. Bu durumda yine oluşturulan kod içindeki son kurallar geçerli olur. 

    Biz düzenleme veya versiyonlama yaptığımızda, çalışan akışların akış derleme numaralarını (Compile ID) değiştirmeyiz. 

    Eğer akış sunucusu kapalı ise ve akış henüz akış sunucusu tarafından hiç alınmamış ise zaten akış derleme numarası (Compile ID) yoktur ve ilk çalıştığı an oluşan son akış derleme numarası (Compile ID) ile set edilir. Bundan sonra akışın akış derleme numarası değişmez.

    Düzenle ve Versiyonla seçenekleri ile beraber buradaki tuşlar değişir ve aşağıdaki tuşlar aktif olur;

    Kaydet: Değişikliklerinize daha sonra devam etmek istiyorsanız kaydet tuşuna basarak ekranınızı kapatabilirsiniz.

    Kaydet ve Yayınla: Değişiklikleriniz bitti ise bu tuşa basarak yapılan değişikliklerin hayata geçmesini sağlayabilirsiniz.

    İptal Et: Bu tuşa basarak yapılan tüm değişiklikleri iptal edip diç değişiklik yapılmamış gibi akışın ekrana gelmesini sağlayabilirsiniz.

    Akış Numaraları
    Akışların tekilliği ile ilgili 3 adet 16 basamaklı numarası bulunur; MASTER_ID,PROCESS_ID,COMPILE_ID. Her akış ilk oluşturduğunda tüm akışlar bazında tekil olmasını sağlayan MASTER_ID değerini alır. Akış her versiyonlandığında PROCESS_ID ve COMPILE_ID değeri değişir, MASTER_ID değeri değişmez, Akışın versiyon numarası değişir. Akış her düzenlendiğinde MASTER_ID ve PROCESS_ID değeri değişmez, COMPILE_ID değeri değişir, versiyon numarası değişmez.
    Platformlar arası taşıma
    Her platformun (dev, test, prod, preprod gibi) kendine ait tekil bir numarası vardır. Sistemde üretilen nesne numaraların hepsi(MASTER_ID vs. dahil) 16 basamaklıdır ve platformun numarasını içerir. Örneğin 50044600000002CD numarası bir PROCESS_ID değerine aittir. Bu ilk 2 karakterinden anlaşılır. Bundan sonraki 4 basamak platform numarasıdır: 0446. Devamındaki numara da sıradan alınan tekil numaradır. Platformlar arası taşımada bu numaralar değiştirilmez ve bu numara ile eşleştirilir.

    Sil: Bu tuş ile tasarlanan akış silinebilir. Akışlar hiç bir zaman tamamen silinmezler. İlgili tablolarında silindi olarak işaretlenir ve listelere gelmemesi sağlanır.

    Tip Kullanımı
    Her tip nesnesi 1 akışa ait olabilir. Akışın silindiği durumda tip nesnesi de boşa çıkmaz. Bu nedenle aynı tip nesnesini kullanan yeni bir akış tasarlanamaz.

    Mutlak Sil: Bu tuşa basılması ile aşağıdaki diyalog aktif olur;

    Verileri Sil: Bu seçenek ile beraber o zamana kadar başlatılan tüm akışlar ve tip verileri silinirler.

    Akışı Sil: Bu seçenek ile beraber akış tasarımın kendisi, ve verileri silinir.

    Akış tipini Sil: Bu seçenek ile beraber akışın tipi ve bağlı elektronik formları, akışın kendisi ve verileri silinir.

    Silme işlemi aşağıdan yukarı doğru gerçekleşir. Yani akış siliniyor ise verisi de silinir gibi.
    Silme işleminin zamanı
    Silme işlemi komut seviyesinde ve uzun süre çalışan bir işlemdir. Bu nedenle silme emri verildiğinde silme işlemi hemen gerçekleşmez. Komutun verildiği 1 dakika içinde sunucu tarafında gerçekleşir. Silme işlemi sistem tarihçelerine yansır.
    Silme işlemi geri alınamaz.

    Akışların Durumları

    Akış tasarımı ana verisi PW_PROCESS tablosunda tutulur. Bu tabloda STATE isimli kolon bulunur. Bu kolonun alabileceği değerler şunlardır;

    1:Akışın yeni oluşturulduğunu ve şu anda değişiklik yapıldığını ifade eder. Aynı zamanda versiyonlamak için de açıldığında bu duruma geçer.

    2:Akışın silindiğini ifade eder. Silinen akış ara yüzlerde görünmez ve tablolarda bulunur. Yukarıda açıklanan Mutlak Sil fonksiyonunda akış tablodan da silinir.

    3:Yayınlanmış ve son kullanıcı tarafından kullanılabilecek akışları ifade eder.

    4:Akışın düzenleme modunda olduğunu ifade eder.

    Tavsiyeler

    1. İş Akışlarında tasarımın SwimLane yardımı ile yapılması tavsiye edilir. Bu notasyon İş birimi, İş Analisti ve Geliştirici tarafından kolaylıkla anlaşılabilmektedir. Swimlane grafikler, okunabilirliği yüksek, ilk bakıldığında neyin nereden geldiğinin rahat anlaşıldığı çizim şeklidir, görsellik hariç fonksiyonu yoktur. Özellikle sistem kulvarının tasarımlarda olması, kullanıcı aktiviteleri harici eğer görünüm çok kötü değil ise bu kulvar üzerinde olması tavsiye edilir. Genel yaklaşım olarak akışın soldan başlaması, ilerleme esnasında da sağa doğru büyümesi tavsiye edilir. Aktivitelerin birbirinden uzak, aktiviteleri birleştiren çizgilerin mümkün olduğunda kesişmediği bir tasarım tavsiye edilir. 
    2. Akış tasarımı yapılmadan önce Hata Takibi sayfasının okunması tavsiye edilir.
    3. Aktivitelere, SwimLane kulvarlarına, aktiviteleri bağlayan bağlaçlara değişik renkler vermek mümkündür. Bu akışın okunabilirliğini artırdığı için kullanılması tavsiye edilir. Ayrıca tasarlanan her akışta aynı renk paletini kullanmak okumayı kolaylaştırır. Ayrıca örneğin ret yolunun kırmızı renk olması gibi standartlar okumada büyük kolaylık sağlar.
    4. Tasarlanan iş akışında açıklama bölümünün doldurulması tavsiye edilir. Bu açıklama son kullanıcının iş akışı başlatması esnasında önüne gelir.
    5. Akış isimlendirmesi önemlidir. Sadece tanımlamalar yardımı ile akışa tip alanlarının da bulunduğu isim vermek mümkündür. Bu işlev iş akışının "İsimlendirme" sekmesi üzerinden yapılabilir.
    6. Akışta 3 adet yetki seti bulunur: 
      1. ‘Yetki Seti’: Bu yetki setinde okuma yetkisine sahip kullanıcılar iş akışını başlatabilirler. 
      2. ‘Tasarım Yetki Seti’: Bu yetki setinde okuma ve yazma yetkisine sahip kullanıcılar akışın tasarımını değiştirebilirler.
      3. ‘Yönetim Yetki Seti’: Bu yetki setindeki okuma ve yazma yetkisine sahip kullanıcılar İş Akışı Yönetimi ekranlarında bu akışları görerek yönetim fonksiyonlarını kullanabilirler.
    7. İş akışı tanımında ‘Bilgi alanları' mevcuttur. Son kullanıcı ekranında akışların hemen altında Outlook da olduğu gibi içerik 2 satıra kadar görüntülenebilir. Bu durumda bilgi alanları bu bölümde görüntülenerek kullanıcının daha ayırt ederek iş yapması sağlanabilir.
    8. Aktivitelerin hepsinde bir açıklama alanı bulunur. Bu açıklama alanları o adımda yapılan işlemleri açıklayacak nitelikte olmalıdır. Eğer bu bölümde bir tanım yapıldıysa son kullanıcı akışı açtığında yazılanlar önünde yardım olarak görünür.
    9. Aktivitelerde ARGUS kullanıcısı (akışta da) hata kullanıcısı olarak seçildiği gözlemlenmiştir. Bu kullanıcı sisteme ilk girişi sağlayabilmek adına oluşturulmuştur. İlk giriş sonrası kapatılmalıdır. 
    10. Her projede akışın/aktivitenin tipine göre hata kullanıcısının belirlenmesi tavsiye edilir. 
    11. Bazı durumlarda son kullanıcılar gelen elektronik postaların göndericisine göre işlem yapmak istemektedir. Yapıda birden fazla elektronik posta adresi tanımlamak ve her posta gönderimi yapılan bölümde hesap seçmek mümkündür.
    12. Bazı durumlarda benzer elektronik postalar değişik aktivitelerden gönderilmektedir. Bunu engellemek adına elektronik posta şablonlarının oluşturulması ve bu şablonların kullanılması tavsiye edilir. Şablon değiştirildiğinde tek bir bölümde değişiklik yapılarak tüm aktiviteler değiştirilebilir. 
    13. Manuel aktivitelerde gönderilen elektronik postalar için aksiyon belirlemek mümkündür. Aksiyonlar için tek bir alana değer atamak, atamanın sonucunda bir açıklama alanı doldurmak mümkündür. Ayrıca aksiyonlar tablo aksiyonu da olabilir. Bu son kullanıcı için işini çok kolaylaştıran bir yapıdır. 
    14. Akışların manuel aktivitelerinde bazı işlevler ‘Power User’ tipindeki kullanıcılara uygundur. Örneğin tarihçenin görünmesi, yönlendirme, başka kullanıcıya atama gibi. Bu özellikleri uyarlamalarda dikkatli incelemek ve son kullanıcıya mümkün ihtiyacına göre özellikler sunmak daha doğrudur.
    15. Akışların versiyonlanması esnasında açıklama girebileceğiniz bir kutu açılır. Yapılan değişikliklerin daha sonra takip edilebilmesi adına bu açıklamaların detaylı girilmesi tavsiye edilmektedir.
    16. Akış tasarımında eğer ihtiyaç var ise zamanlayıcı kullanılmalıdır. Her akışın zamanlayıcısı olabileceği gibi akışların manuel aktivitelerinin de zamanlayıcısı olabilir. «Süreç Süresi» isimli genel tanımlar bölümünden bir akışa süre verilebilir. Burada dikkat edilmesi gereken eğer bir akışa bitiş süresi(SLA) tanımlanmış ise akışta süreli başlangıç ve süreli bitiş adımları mutlaka kullanılmalıdır. Bu iki aktivite arasında normal akış tasarlar gibi akış tasarlanabilir. Tek fark paralel aktivite kullanılamaz. 
    17. Kullanıcı aktivitelerinde zamanlayıcı ile biten akış adımında mutlaka bir tip alanı güncellenmeli, hemen devamında zamanlayıcı ile bitmiş ise gerekli aksiyon planlanmalıdır. Zamanlayıcı adımlarında tip alanı güncelleme bölümünde süreç değişkenlerinin de kullanılabildiği unutulmamalıdır. Süreç değişkeni sadece akış tasarımında kullanılan, tip alanına benzeyen, akış bittikten sonra kullanılamayan veri taşıyıcılarıdır.
    18. Bekleme aktivitesinde makro yazılabilmektedir. Bu durumda aktivite belirtilen süre kadar bekler, makroyu çalıştırır, sonuçta 1 sonucunu alırsa işine devam eder, 0 sonucunu alırsa bekleme süresi kadar tekrar bekler ve döngüde devam eder. 
    19. Akışlar için bir süreç önceliği mimarisi kurmak mümkündür. Süreç önceliği kullanıcıların hangi işi hangi sıra ile yapacaklarını ayırt edebilmeleri için önemlidir. Bu nedenle tek akış için değil kurum içindeki tüm akışlar düşünülerek planlanmalıdır. Tanıma göre akış başlatırken öncelik değerini değiştirmek mümkündür. Akış boyunca zaman bazlı öncelik değeri değiştirilebilir. Ayrıca Öncelik aktivitesi yardımı ile akışın herhangi bir noktasında öncelik değiştirilebilir. Yine metodlarda ve formlarda geliştirme katmanı aracılığı ile öncelik değeri değiştirilebilir.
    20. Eklentili bir akış tasarımının veri eşleştirmelerinde kullanılan tarih, tarih-saat, saat nesneleri akış içerisinde boş geçilmemelidir.
    21. KPI kavramı aslında süreç kavramının vazgeçilmez bir parçasıdır. Genel olarak iş akışlarında KPI ölçümü yapılmadığı gözlemlenmiştir .Akışlarda 2 türlü KPI ölçebiliriz; a.KPI Başlangıç ve KPI Bitiş aktiviteleri yardımı ile. b.Manuel aktivite KPI ölçüm sekmesi ile. KPI, bir aktivitede işin tahmin edildiğinden erken veya geç bitirilmesine göre kurumun önlem almasını sağlar. Çalışanların işi beklenen sürede, beklenenden önce veya beklenenin altında yapıp yapmadıklarının denetlenmesini sağlar. KPI metriklerinin tek seferde belirlenip çıkarılabilmesi mümkün değildir. Yapılan iş hakkında zaman içinde ölçüm yaparak tecrübe kazanması gerekir. Bu nedenle akışın ilk tasarımında KPI metrikleri net olmasa da planlanmalı, zaman içinde raporlara göre düzeltmeler yapılmalıdır. PaperWork ürünü sloganı: Ölçemezsen Yönetemezsin.
    22. Süreç tasarımı esnasında yapılan genel hatalar için şu sayfa incelenebilir.