İş organizasyonu diyagramı örneği. İş süreçlerinin görsel modellenmesi

Talimatlar

Birincisi, açıklanan sürecin adının anlaşılır olması ve süreci oluşturan eylemler dizisinin genel özünü yansıtması gereken doğru bir şekilde formüle edilmesidir. Örneğin, "Bir başvuruyu üretim için göndermek ve yürütülmesini izlemek" yerine, süreci "Ürün Kontrolü" olarak adlandırmak yeterlidir. İkinci şey, açıklanan sürecin tamamını daha küçük ("atomik") görevlere veya doğru bir şekilde bölmektir. alt süreç fonksiyonları ve bunların yürütülme sırasını belirler. Böyle bir bölünme ile anlatılan süreç üst düzey bir süreç olacaktır. Üst düzey süreçteki ayrıntı düzeyi farklılık gösterebilir ancak açıklamanızı kullanacak hedef kitlenin anlayabileceği düzeyde olmalıdır.

Bir iş sürecini tanımlamanın birkaç yolu vardır. Bunlardan en popüler olanı, çeşitli gösterimlerle yapılan grafiktir (gösterim, bir şeyi belirtmek için bir dizi semboldür).
İş süreçlerini açıklamaya yönelik en yaygın gösterim türleri IDEF0, BPMN, EPC (ARIS) vb.'dir.
Örnek olarak, CASE aracı PowerDesigner kullanılarak BPMN'de (İş Süreci Modelleme Gösterimi) yapılan bir diyagrama bakalım (Şekil 1). Diyagramdaki ana unsurlar şunlardır:
1. “Süreç” (işlev) - köşeleri yuvarlatılmış bir dikdörtgen;
2. “Geçiş” - süreçleri birbirine bağlayan bir ok;
3. “Karar” - yalnızca “Evet” veya “Hayır” olarak yanıtlanabilecek bir soruyu içeren bir elmas;
4. Koşullar - bir işlevden diğerine geçişin gerçekleştiği metin ifadeleri. Koşullar her zaman köşeli parantez içine alınır. Bazen kendinizi "Parçalara" (kurumun bölümlerini veya belirli bir işlevi yerine getirmekten sorumlu çalışanları gösteren dikey veya yatay bölümlere) bölmek yararlı olabilir. Bu durumda bu fonksiyonun kendi bölümü içerisinde bulunması gerekir. Listelenen öğelere ek olarak, süreç için girdi veya çıktı olan verilerin bir listesinin yanı sıra belirli bir işlevin yerine getirilmesine ilişkin kural veya düzenlemelere bağlantılar da içerebilir. “Ürün üretim kontrolü” iş sürecinin açıklamasına bir örnek Şekil 1'de gösterilmektedir. Bu diyagramın, problemin çözümüne yönelik algoritmanın akış şemasına çok benzediğini görmek kolaydır.

Bir sürecin grafiksel açıklaması, aşağıdaki sütunları içeren bir tablo biçimindeki fonksiyonlarının-alt süreçlerinin bir metin açıklamasıyla da desteklenebilir: süreç adı, departman (süreç sahibi), süreç açıklaması, süreç yürütme sonucu. Böyle bir açıklamanın bir örneği Şekil 2'de gösterilmektedir. Tanımlanan iş sürecinin daha fazla optimizasyonu bekleniyorsa, yürütülen süreçlerin zorluklarını veya eksikliklerini açıklayan tabloya başka bir sütun ekleyebilirsiniz. şu anda işlevler-alt süreçler.

Yararlı tavsiye

İş süreçlerini açıklamak için her zaman seçilen grafik gösteriminin kurallarına uyun.

Kaynaklar:

• M. Rybakov. İş süreçlerinin optimizasyonu.
• iş süreci nasıl oluşturulur

Bir fenomen olarak süreç, gözlem nesnesinde belirli bir süre boyunca meydana gelen niteliksel bir değişimdir. Bu nedenle, açıklamaya başlamadan önce bile gözlem nesnesini ve zaman dilimini belirtmelisiniz.

Talimatlar

Öncelikle sürecin özünü yani gözlemlediğiniz niteliksel değişimi tanımlamanız gerekiyor. Mesela alev aldı, yandı, söndü (olayın özü yanma sürecidir). Değişiklik dışarıdan görülebilir (tüm bir kibrit bir çubuğa dönüştü), tam olarak neyi izlediğinize bağlı olarak nesnenin yapısı, bağlantı sistemi değişebilir. Her durumda, değişikliği açıklarken, ayrıca süreyi ve hızı da belirtmeniz gerekecektir (örneğin, kibrit 20 saniye boyunca yandı, kömürleşme hızı saniyede 2 milimetreydi). Bazen buna “döngüsellik” gibi bir süreç özelliği de eklenir (gözlemlediğiniz değişim bir kez veya periyodik olarak gerçekleşir).

Değişimin özünü gösterdikten sonra genellikle süreci bir dizi "durum" olarak tanımlamaya devam ederler. Bu amaçla genellikle her zaman gözlem yapılır.

Kişisel bilgiler:

70'den fazla şirketin düzenli yönetimi alanında danışmanlık yapıldı: 10 ila 9.000 kişi (bunlar arasında: holding şirketleri, zincir mağazalar, fabrikalar, hizmet şirketleri, inşaatçılar, devlet yetkilileri, web ajansları, çevrimiçi mağazalar yer alıyor). Alexander Friedman'ın öğrencisi.

"Tallinn Yöneticiler Okulu'nun sosyal teknolojileri. İş, yönetim ve özel hayatta başarılı kullanım deneyimi" kitabının ortak yazarlarından biri: http://www.ozon.ru/context/detail/id/140084653/

"Üç yol bilgiye götürür: Düşünme yolu en asil yoldur, taklit yolu en kolay yoldur ve tecrübe yolu en acı yoldur."

Konfüçyüs

kime: sahipleri, üst düzey yöneticiler, idareciler

Süreçleri düzenlemeler yoluyla yönetmek, "elden ayak" yönetimine yol açar

İşletme sahipleri ve yöneticiler için bu kadar önemli sorunları çözen düzenlemelerin faydalarından defalarca bahsettim:

• çalışanların hatalarını en aza indirmek;
• iş kalitesinin standardizasyonu;
• kişisel bağımlılığın ortadan kaldırılması;
• Her çalışana işini en verimli şekilde yapma fırsatı.

Ve düzenlemeleri yararlı bulmayan bir liderle nadiren tanıştım. Görünüşe göre düzenlemeler tüm hastalıklara karşı her derde deva! Ama... “Yalnızca düzenlemelere göre yönetme” girişimleri çoğu zaman başarısız oluyor.

Neden? Şimdi açıklamaya çalışacağım. Düzenlemeler- bu, şirkette meydana gelen iş sürecinin herhangi bir bölümünün (eylemler dizisi) açıklamasıdır: sürecin tamamı, birkaç süreç veya sürecin bir kısmı.

İşlem("iş süreci" ile eşanlamlıdır) herhangi bir sorunu çözmeye yönelik bir dizi eylemdir. tipik görev(standart dışı görevler projelere atıfta bulunur).

Süreçleri doğrudan yönetmek ve bunları resmileştirmek, diyagramlar çizmek etkilidir.

Süreçler basit ve bileşik olarak ikiye ayrılır. Kompozit- birkaç tane içerir basit süreçler. Hala bazıları var uçtan uca süreçler. Süreçlere buna denir farklı aşamalar Bunlar şirketin çeşitli departmanlarından geçer. Genellikle zorlukların yattığı yer burasıdır.

Çalışanları regülasyonlar çerçevesinde yönetmek mümkünse, süreçleri regülasyonlar yoluyla yönetmek, bacağınızın içinden elinizi yönetmeye çalışmakla aynı şeydir. Oysa elinizi doğrudan kontrol etmek çok daha verimlidir.

Grafiksel ve şematik gösterimleri (örneğin BPMN gösteriminde) süreçlerin yönetilmesine doğrudan yardımcı olur. Donanımı incelemeye başlamadan önce süreçleri yönetmek için düzenlemelerin neden yeterli olmadığını anlamayı öneriyorum.

Düzenlemeler neden yeterli değil?

• Tüm süreçler doğrusal değildir. Birçoğunun birçok "eğer... o zaman..." koşulu vardır. Yönetmelik metninin “havlusunu” hızlı bir şekilde anlamak ve anlamak zordur. Sürecin aşamalarının birbiriyle nasıl ilişkili olduğu. Örneğin, çalışanların seçimine ilişkin düzenlemeler hemen hemen her aşamada benzer çatallarla doludur. Başvuranın pozisyonuna bağlı olarak görüşme, doğrudan amirinin katılımıyla veya katılımı olmadan uzaktan veya şahsen gerçekleştirilebilir.
• Bir süreç birkaç aşamadan geçerse “nihai sonuçtan kimin sorumlu olduğu” sorunu ortaya çıkar. Başarısızlık ve hata durumunda çalışanlar birbirlerini suçlar ve şartlara bağlı olarak karşılıklı sorumluluk doğar.
• Çalışanlar kendi aralarında anlaşamıyor kimin ne işe yaradığıyla ilgili.
• Görünürlüğün düşük olması nedeniyle (yönetmeliklerin metninin aynı devasa hacmi) son derece Bir süreci optimize etmek ve geliştirmek kolay değil.
• Çalışanların önemli ölçüde zaman kaybı Büyük resmi ve tüm ilişkileri okumak, incelemek ve anlamak. Düzenlemeler nadiren tüm süreci açıklar. Çoğu zaman birden fazla departmandan geçen bir süreç farklı düzenlemelere tabidir.

Süreç yönetimine giriş: Bir süreci tanımlamanın en iyi yolu nedir?

Süreç yönetimi- tam bir bilim. Ancak nasıl çalıştığının netleşmesi için birçok şeyi bilinçli olarak basitleştireceğim. Kısacası süreç yönetimi teorisinin özü, tüm şirket faaliyetlerinin süreçlere bölünebilmesidir (şaşırtıcı bir şekilde, değil mi?)

Sürecin nasıl işlediğini anlamak için aktörler (bölümler, çalışanlar, gerçekleştirilen roller) arasındaki tüm ilişkileri ve sürecin aşamalarını gösterecek bir diyagram çizmek gerekir. Sürecin hangi aşamasının hangi departman tarafından yapılması gerektiği, aşamayı tamamlamak için girdi verilerinin kimden alınması gerektiği ve sonucun kime aktarılacağı diyagramdan açıkça anlaşılmalıdır.

Tüm planlar eşit derecede yararlı değildir. Benim düşünceme göre, süreç diyagramı (ve dolayısıyla kullanılan notasyon sistemi, buna notasyon adı verilir) için önemli gereksinimler vardır:

• Süreçteki katılımcılar tarafından şemanın açık bir şekilde yorumlanması.
• Bu notasyon sisteminde (notasyon) yeterli miktarda eğitim video materyalinin bulunması.
• Gösterim beklentileri: hızlı bir şekilde gelişiyor mu, ne kadar kullanılıyor, gelecekte kullanılacak mı yoksa çoktan tükeniyor mu?

Bana göre BPMN notasyonu (versiyon 2.0) tüm bu kriterleri karşılıyor. Diyagramlar çizmek için şunu kullanmanızı öneririm: ücretsiz program Bizagi Modelleyici.

Ve bir kez daha basitleştirme hakkında. Diyagramları çizmeye başladığınızda standarda %100 uymanıza gerek yoktur; bu yalnızca uygulamayı zorlaştıracaktır. İlk aşamalarda asıl önemli olan, diyagramların katılımcılar tarafından anlaşılır olması ve onlar tarafından açıkça yorumlanmasıdır. Devreleri standartlara uygun hale getirmek için hâlâ zamanınız var.

Toplam Süreç diyagramları aşağıdaki sorunları çözer:

• Şeffaflık. Hem uygulayıcılar hem de yönetici, sürecin aşamaları arasındaki ilişkileri ve bu aşamaların hangi çalışanın/birimin sorumluluk alanında olduğunu anlar.
• En kritik ve/veya en az verimli şekilde gerçekleştirilen aşamaları belirleyerek süreci optimize etme yeteneği.

Optimizasyon hedeflerini belirlemeyi ve harcanan kaynakların ne kadar değişeceğini hesaplamayı unutmayın yeni versiyon işlem!

Süreç yönetiminin temel özelliği tüm süreçten sorumlu kişinin olmasıdır.

Herhangi bir şirket sahibi ve üst düzey yönetici için en önemli baş ağrılarından biri, olay için kimsenin suçlanmadığı, ancak çalışanların ve departmanların birbirini suçladığı karşılıklı sorumluluk durumudur. Karşılıklı sorumluluk ne kadar kapalı?

Bir çıkış yolu var. Uçtan uca bir süreciniz olduğunu gördüğünüzde (örneğin bir müşteri siparişini yerine getirmek), süreçten kimin sorumlu olabileceğini ve sürecin ayrı bir kopyasından kimin sorumlu olabileceğini düşünün.

Tüm süreçten sorumlu(bazen "süreç sahibi" olarak da adlandırılır) - bu, iş sürecinin iyileştirilmesinden ve geliştirilmesinden sorumlu olan yöneticidir (veya çalışandır); ortaya çıkan küresel çarpışmaları çözmek ve başarısızlıkları analiz etmek; Süreç kopyasından sorumlu olanların yardımı ve eğitimi.

Bir sürecin kopyası, bir iş sürecinin pratikteki uygulamalarından biridir. Mesela “müşteriye özel mutfak yapmak” gibi uçtan uca bir iş süreci var. İşlem kopyaları belirli siparişlerdir. İÇİNDE bu durumda yönetmen tüm süreçten sorumlu olabilir perakende satışlar ve belirli bir kopya için - belirli bir işlemi denetleyen salon yöneticisi.

Bir yönetici, sürecin (siparişin) kopyasında bir sorunla karşılaşırsa ve sorunu çözemezse, perakende satış müdürüyle iletişime geçer.

Sürecin geliştirilmesinden ve tüm kopyalarının yürütülmesinden bir kişi sorumlu olmalıdır.

Yani öyle bir kişi var ki tüm süreçten sorumludur(kopyalamadan sorumlu olanların çalışmaları dahil) ve kopya yapmaktan sorumlu kişiler vardır. Süreç yönetimi çerçevesinde sürecin kopyalarından sorumlu olanlar “süreç sahibine”, sorumlular ise süreçteki katılımcılara rapor verir.

“Süreç sahibinin” ve kopyalarından sorumlu olanların ortaya çıkan sorunları çözebilmesi için, kendilerine yetki verildiğinden emin olun (örneğin, ilgili departmanlardan siparişin durumu hakkında bilgi talep edin: teslimat hizmetleri, montajcılar; ne zaman karar verirler) sorunlar ortaya çıkar).

Diyagramları ve düzenlemeleri kullanarak bir iş sürecini tanımlamaya ve geliştirmeye yönelik algoritma

Uygulamaya geçmenin zamanı geldi. Anahtar süreçlerin diyagramlarını çizme fikri konusunda zaten heyecanlandığınızı düşünüyorum. Bunun nasıl yapılacağı aşağıda tartışılacaktır.

Aşama 1. Bir süreç şeması çizin ve üzerinde anlaşın

1. Süreci geliştirmekten sorumlu kişi ve sürecin belirli kopyalarını yürütmekten sorumlu uzmanlarla birlikte bir süreç şeması çizin. Sürecin en kritik noktalarını vurgulayın. Diyagramdaki her sürecin ve her aşamanın bir “girdisi” ve bir “çıktısı” vardır. Düzenlemeleri yazarken, girdinin ne olacağını ve çalışmanın sonucunun ne olacağını düşünün.
2. Süreçteki tüm katılımcılarla veya katılımcıların bölüm başkanlarıyla plan üzerinde mutabakata varın.

Örnek No.1. BPMN notasyonunda “Çalışan Alımı” sürecinin şeması

Örnek No.2. BPMN notasyonundaki "Çalışan İşe Alımı" diyagramının bir kısmı

Aşama 2. Sürecin aşamalarının gerçekleştirilmesine ilişkin düzenlemelerin yazılması

Diyagramda gösterilen sürecin her aşaması için ayrı bir düzenleme veya herhangi bir genel talimatın alt bölümünün oluşturulması gerekir. Düzenlemelerin tüm nüansları ayrıntılı olarak açıklaması gerekir: işin hangi sırayla gerçekleştirileceği; hangi küçük adımlardan oluşur; sonucun kalitesi için gereksinimler nelerdir; işi gerçekleştirmek için hangi teknolojinin kullanılacağı.

Süreç diyagramının aşamalarından birinin düzenlemelerindeki açıklamaya bir örnek

Aşama 3. Süreç kontrolünü başlatın

Sorular ortaya çıkıyor: sürecin şu anki aşamasını, ortaya çıkan sorunları ve sürecin başarıyla tamamlanıp tamamlanmadığını veya bir aşamada sonsuza kadar takılıp kalmadığını nasıl görebiliriz? Ya da belki tamamlandı ama aşamaların yarısı sapmalar ve hatalarla tamamlandı, bazıları ise tamamen atlandı.?

Kullanışlı (ve kullanışlı) büyük şirketler) yalnızca diyagram çizmekle kalmayıp aynı zamanda yürütmek üzere süreçleri başlatabileceğiniz yazılım çözümleri. Ama üzerinde başlangıç ​​aşaması Küresel uygulamalardan uzak durulmasını tavsiye ederim. Başlangıç ​​olarak çalışanlarınızı süreçlerle çalışacak şekilde eğitin. Google E-tablodaki kontrol listeleriyle başlayın.

Gelecekte Bitrix24 veya 1C'deki iş süreçlerine geçin. Şirketiniz için fazlasıyla yeterli olmaları oldukça olasıdır.

Aşama 4. Verimliliği ve kaliteyi artırmak için süreci geliştirin ve optimize edin

Daha önce de belirttiğim gibi sürecin gelişiminden “sahibi” sorumlu olmalıdır (lütfen bunun bir “istiyorum/istemiyorum” kategorisi değil, çalışanın onurlu bir görevi olduğunu unutmayın).

Sürecin mantığında (bağlantılarında) yapılacak herhangi bir ayarlama, aşamaların eklenmesi veya silinmesi, ilk önce diyagramda gerçekleştirilmelidir. Sürecin kilit katılımcılarıyla planlanan değişiklikler üzerinde mutabakata varıldıktan sonra düzenlemelerin, kontrol listelerinin nihai hale getirilmesi ve yapılandırılmış iş süreçlerinde değişiklik yapılması mümkün olacak.

Burada otomatik iş süreçlerinin yapılandırıldığı, kontrol listelerinin yapıldığı ve düzenlemelerin olduğu şemaların bir listesini tutmak önemlidir (belki ayrı bir tablo veya düzenlemelerin başında özel bir alan bunun için faydalı olacaktır). Bu “süreç sahibine” yardımcı olacaktır değişiklikleri her düzeyde senkronize et ve ayrıca bunları gereksiz eylemler olmadan gerçekleştirin.

Örneğin, otomatikleştirilmiş iş süreçlerinin yokluğunda, aşamalara ilişkin detaylara yapılan küçük eklemeler anında düzenlemelere dahil edilebilmektedir. Tabii bu eklemeler diyagramdaki bağlantıları ve aşamaları etkilemediği sürece.

Süreçteki tüm değişiklikler hakkında sadece doğrudan katılımcıların değil, ilgili tüm tarafların bilgilendirilmesi de önemlidir. Değişikliklerle ilgili iletişim, insanların yalnızca değişiklikleri görmesi ve eklemeler bulmak için düzenlemenin tamamını tekrar incelemesine gerek olmaması nedeniyle farklıdır.

Sonuç ya da Neden “her şey bir anda” projeler mezarlığına giden yoldur?

Süreçler hakkında bir kitaba yetecek kadar çok şey anlatabilirsiniz. Ancak... ölü projelerin mezarlıkları, "her şeyi aynı anda" ve en pahalı ve/veya zengin özellikli yazılımlarla uygulama girişimleriyle doludur. İÇİNDE en iyi senaryoçalışanlar uygulanan teknolojileri kullanmadı veya sistemler o kadar hantal hale geldi ki onlarla çalışmak imkansızdı. En kötüsü, uygulama sırasındaki zorluklar işin sonuna kadar tamamlanmasına izin vermedi.

Ve bir tane daha önemli nokta. Astlarınız anlaşmaları yerine getirmiyorsa ne düzenlemeler ne de süreç diyagramlarının çizilmesi size yardımcı olacaktır. Tek seçenek, anlaşmalara uyum şeklinde “sağlam” bir bölge oluşturmak ve bunu gelecekte genişletmektir. Bu yardımcı olacaktır.

Bu yazıyı okuyanlar şunu da okudu

Zaman "H": Şirketinizde düzenli yönetimin başlatılmasının kaçınılmaz olduğu ve başlangıcın ertelenmesinin yalnızca ek kayıplara yol açacağı zaman

Bir mal ve ekipman üreticisinin web sitesi: Yeni bayi ve toptancı arayışını engelleyen 10 yaygın hata

Vladimir Repin

Genel Müdür Vladimir Repin Yönetim LLC

ABPMP Rusya Üyesi

Yönetim Danışmanı

İş koçu

Teknik Bilimler Adayı

Makale, daha sonraki düzenleme amacıyla süreçleri tanımlamak için bir notasyon seçimi konularını tartışıyor. Sık kullanılan İş Akışı gösterimleri karşılaştırılır, örneğin: MS Visio'daki "Basit akış şeması", Business Studio'daki "Prosedür", ARIS eEPC gösterimi ve diğerleri. Gösterimleri karşılaştırırken asıl odak noktası, kuruluş çalışanları için basit ve anlaşılır süreç diyagramları oluşturmaktır.

Şirketlerin iş analistleri için makalede tartışılan tezler, organizasyonel süreçlerin grafik diyagramlarını geliştirmek için kullandıkları yaklaşımların ne kadar etkili olduğunu düşünmek için ciddi bir nedendir.

giriiş

Grafiksel süreç diyagramları oluşturmanın en önemli hedeflerinden biri, bunların kuruluşun düzenleyici belgelerinde daha sonra kullanılmasıdır. Bu şemalar, kural olarak, karmaşık gösterimler konusunda eğitim almamış, sistem analizi becerilerine sahip olmayan vb. çalışanlar tarafından kullanılır. Şemaların basitliği ve netliği onlar için çok önemlidir. Birçok farklı öğeyi içeren karmaşık, kafa karıştırıcı diyagramlar semboller insanlar tarafından yeterince algılanmıyor, bu da pratik kullanımlarını zorlaştırıyor. Bu nedenle, pratik amaçlar açısından, süreçleri tanımlamak için notasyonun (metodolojinin) doğru seçilmesi ve kullanılması önemlidir. Böyle bir notasyonu seçmek için hangi kriterler kullanılmalıdır? Farklı notasyonlar birbirleriyle nasıl karşılaştırılır? Popüler gösterimleri kullanarak bir iş sürecini tanımlamaya yönelik birkaç örneğe bakalım ve bu soruları yanıtlamaya çalışalım.

Gösterimlerin karşılaştırılması

Karşılaştırma için aşağıdaki süreç tanımlama notasyonları seçilmiştir:

1. “Basit akış şeması” (“Çözüm” bloğunu kullanarak belgelerin hareketini gösterir);
2. “Basit blok diyagramı” (“Çözüm” bloklarını kullanmadan, belgelerin hareketini göstermeden);
3. Business Studio sisteminin "Prosedürü" (biri) olası seçenekler temsiller);
4. ARIS eEPC.

Test örneği olarak basit ve sezgisel bir örnek seçildi süreci temizle. Bu süreci tanımlamanın sonuçları Şekil 2'de sunulmaktadır. 1-4.

Pirinç. 1. MS Visio'daki "Basit akış şeması" gösterimindeki süreç diyagramı ("Çözüm" bloğunu kullanarak belge hareketi ile)

Şekil 2'de sunulan şemada. Şekil 1'de, süreç işlemlerinin zaman içindeki sırası kalın oklarla, belgelerin hareketi ise ince noktalı oklarla gösterilmiştir. Çözüm blokları klasik bir şekilde kullanılır. Sürecin sonraki seyrinin "bağlı olduğu" bilgileri (soruları) görüntülerler. "Elmas" kullanımına yönelik bu yaklaşım çok yaygındır. Ama aslında karar vermenin ve belirli çıktıların (belgelerin) oluşturulmasının tüm mantığının sürecin işleyişi içinde yer alması gerekiyor. Düşünürseniz bu “elmasları” çizmenin değeri (anlamı) pek açık değildir. Bunlar ne tür nesnelerdir: süreç işlemleri, olaylar? Görünüşe göre ne biri ne de diğeri. Bunlar daha çok bazı koşullara bağlı olarak karar vermeye yönelik operatörlerdir. Ama biz insanlara özel bir süreç diyagramı geliştiriyoruz, özel bir dilde bilgisayar programı yazmıyoruz. İÇİNDE bilgisayar programı"elmas", koşulların karşılaştırılması vb. için tam teşekküllü bir işlem olacaktır. Ancak süreç diyagramının gerçek nesneleri (insanlar tarafından gerçekleştirilen süreçler, belgeler, bilgi sistemleri vb.) göstermesi gerekir. "Elmasları" ayrı ayrı göstermenin doğru olup olmadığını düşünün. şemadaki süreç operasyonundan mı? Bunun yerine şunları yapabilirsiniz:

• Karar verme mantığını, söz konusu sürecin diyagramında bir dizi işlem şeklinde açıklayın;
• Mantığı, bir sonraki seviyeye geçerek ilgili alt sürecin adımlarının bir diyagramı şeklinde açıklayın;
• Mantığı metinde açıklayın (işlemin metin niteliklerinde) ve ardından bunu süreç yürütme düzenlemelerinde görüntüleyin.

Yukarıda tartışılan "elmas" kullanma yönteminin "artılarını" ve "eksilerini" formüle edelim (Şekil 1).

MS Visio'da "Basit akış şeması" ("Çözüm" bloğunu kullanarak belge hareketi ile)

Şek. Şekil 2'de aynı sürecin yalnızca "Çözüm" blokları ve belgeleri kullanılmadan açıklanan bir örneği gösterilmektedir. Bu diyagramın, Şekil 2'deki diyagramdan 24 daha az grafik elemanına sahip olduğunu kontrol etmek kolaydır. 1. Şema Şek. 2 çok daha basit görünüyor. Grafik unsurları göz kamaştırmaz ve bilgi içeriği açısından bu diyagram son kullanıcı için oldukça anlaşılır ve erişilebilirdir. Her süreç operasyonu için uygulanmasına ilişkin gereklilikleri metin olarak açıklarsanız, tablo ve grafik sunum formlarını birleştirerek, şirket çalışanları için sürecin yürütülmesi prosedürünü oldukça yeterli bir şekilde tanımlayabilirsiniz.

Pirinç. 2. MS Visio'daki “Basit akış şeması” gösterimindeki süreç diyagramı (belge hareketi olmadan, “Çözüm” bloğunu kullanmadan)

Şekil 2'de sunulan formdaki sürecin grafiksel gösteriminin "artıları" ve "eksileri". 2'si aşağıda gösterilmektedir.

MS Visio'da "Basit akış şeması" (belge hareketi olmadan, "Çözüm" bloğunu kullanmadan)

Genel olarak, diyagramların Şekil 2'de sunulanlara benzer bir formatta kullanılması. 2, bu planlar üzerinde çalışan geliştiriciler ve çalışanlar için uygundur.

Şek. Şekil 3, Business Studio modelleme ortamının "Prosedür" gösteriminde oluşturulan bir süreç diyagramını göstermektedir. Şemanın çeşitli özellikleri vardır. İlk olarak, "Karar" blokları standart olmayan bir şekilde kullanılır - soruyu ve dallanmayı gösteren grafik bir öğe olarak değil, karar vermeyle ilgili tam teşekküllü bir süreç operasyonu olarak. Business Studio'da "elmas" tam teşekküllü bir sürecin hemen hemen tüm niteliklerine sahiptir, ancak ayrıştırılamaz (belki sistem geliştiricileri bunu zaman içinde mümkün kılacaktır). Bir “elmas” kullanmak (dörtgen yerine) diyagramı daha görsel hale getirir. Aynı zamanda, "elmas" niteliklerine herhangi bir metin bilgisini girebilirsiniz: açıklama, başlangıç, tamamlama, son tarih gereklilikleri vb.

Şekil 2'de sunulan süreç diyagramının ikinci özelliği. 3, okların uygulanmasıdır. Bir işlem dizisini görüntülemek için tek uçlu bir ok (öncelik oku) kullanabilirsiniz. Belge hareketini göstermek için çift başlı ok kullanabilirsiniz. Ancak Business Studio'da yalnızca tek bir ok türü olan "öncelik" oklarını kullanarak bunu yapabilirsiniz. Bu durumda adlandırılmış oklara bağlanabilirsiniz. gerekli miktar Etkinlik nesnelerinin dizininde tanımlanan belgeler.

Bu yaklaşım şunları mümkün kılar:

• Süreç diyagramındaki grafik öğelerin sayısını önemli ölçüde azaltın ve aynı zamanda;
• Süreç düzenlemelerinde gelen ve giden belgelerle ilgili gerekli bilgileri görüntüleyin.

Böylece, diyagramı gereksiz öğelerle doldurmadan, yine de süreci tam olarak tanımlayabiliyor ve gerekli tüm bilgileri düzenlemelere yükleyebiliyoruz.

Ok adının kendisine ekli belgelere bağlı olmaması, diyagramdaki okları çalışanlar için en anlaşılır ve kullanışlı şekilde adlandırmamızı sağlar. Örneğin, bir dizi spesifik belge "Bir dizi rapor hazırlandı" öncelik okuna bağlanabilir. Bu durumda okun adı, icracıya "Gün için tahsilat raporu oluştur" adı verilen önceki işlemi tamamlayan olayı gösterir. (STU şirketinin metodolojisinde süreç işleminden sonraki okun bir olay değil varlık olduğunu unutmayın. “Kararlar” bloğundan sonra kararın olası sonuçlarını gösterebilirsiniz).

Pirinç. 3. Business Studio sisteminin “Prosedürü” (isteğe bağlı) geleneksel olmayan kullanım"Çözüm" blokları)

Şekil 2'de sunulan formdaki sürecin grafiksel gösteriminin "artıları" ve "eksileri". 3'ü aşağıda gösterilmektedir.

Business Studio sisteminin “Prosedürü” (“Çözüm” bloklarının geleneksel olmayan kullanımıyla seçenek)

Business Studio'yu kullanırken Prosedür gösterimi biraz farklı şekillerde kullanılabilir. Makalenin yazarı, Şekil 2'de sunulan yaklaşıma eğilimlidir. 3.

Şek. Şekil 4, ARIS eEPC gösteriminde geliştirilen, söz konusu sürecin bir diyagramını göstermektedir. Bazı süreç işlemlerinin diyagrama uymadığını unutmayın. Basit bir sürecin ARIS eEPC notasyonuyla yazılmış bu kısmi diyagramı, dört mantık ifadesi ve sekiz olay içerir! Diyagramı okuyan kişinin bu mantıksal operatörlerin tamamını doğru yorumlayabilmesi gerekir. Özel eğitim ve bu tür diyagramları okuma konusunda bazı beceriler olmadan, sıradan bir çalışanın, ayrıntılı bir metin açıklaması veya nitelikli bir iş analistinin yardımı olmadan söz konusu sürecin mantığını anlaması pek mümkün değildir.

ARIS eEPC gösterimindeki süreç diyagramının, Şekil 1'de sunulan diyagramlardan çok daha fazla yer kapladığını unutmayın. 1-3. Böyle bir plan oluşturmanın karmaşıklığı da önemli ölçüde daha yüksektir.

Pirinç. 4. ARIS eEPC notasyonundaki süreç diyagramı (Business Studio'da yerleşiktir)

ARIS eEPC gösterimindeki süreç diyagramı (Business Studio'da yerleşik)

Genel olarak, SAP R/3 satın almayacaksanız, makalenin yazarının bakış açısına göre ARIS eEPC notasyonunu seçmek ve kullanmak, optimal çözüm. Sanatçılar için daha görsel ve sezgisel süreç tanımlama notasyonlarına dikkat etmekte fayda var. Ancak bazıları ARIS eEPC gösterimini daha görsel ve anlaşılır bulabilir. Bir dereceye kadar bu bir zevk meselesidir.

Daha sonraki otomasyon amaçları için prosesin tanımı

Yukarıdaki iş süreci açıklaması örneğinin BPMN 2.0 gösteriminde sunulması durumunda dikkate alınması ilginç olacaktır. Bu gösterim, "yürütülebilir" süreçleri, yani BPM sisteminin desteklediği süreçleri tanımlamayı amaçlamaktadır.

BPMN 2.0 kullanımına ilişkin fikriniz. Business Console şirketinin Genel Müdürü A. A. Belaichuk şunları paylaşıyor:

"Şek. Şekil 5 aynı süreci BPMN gösteriminde göstermektedir. Gördüğümüz gibi bu şekil Şekil 1'e benzer. Şekil 1: BPMN gösteriminde görevler dikdörtgenler, çatallar baklava desenleri ve veriler belgeye benzer bir simge olarak gösterilmektedir. Kontrol akışları düz çizgilerdir, veri akışları noktalıdır.

Bu diyagramın BPMN notasyonunun yalnızca küçük bir kısmını kullandığı dikkate alınmalıdır: paletteki 5 çataldan yalnızca biri, 8'den bir görev türü. Daha geniş bir palete ek olarak, bu notasyon Yalnızca yalıtılmış bir iş akışını değil, aynı zamanda mesajlar veya veriler aracılığıyla birbiriyle etkileşime giren çeşitli süreçleri de modelleme yeteneğiyle ayırt edilir. Ayrıca bu gösterim daha katıdır: yalnızca simgeleri değil aynı zamanda bunların birbirleriyle birleştirilebileceği kuralları da tanımlar. Bu tür kurallara duyulan ihtiyaç, BPMN notasyonunun yalnızca insanlar tarafından okunacağı gerçeğine değil, aynı zamanda BPM sisteminin "motoru" olan özel yazılım tarafından doğrudan yürütülmesine de odaklanmış olması gerçeğiyle belirlenir.

Aynı zamanda, bu örneğin gösterdiği gibi, paletin sınırlı bir alt kümesi kullanıldığında BPMN'nin geleneksel bir akış şemasından daha karmaşık olmadığı ortaya çıkıyor. BPMN'de profesyonel olarak uzmanlaşmak isteyenler için bpmntraining.ru uzman eğitimini öneriyoruz."

Pirinç. 5. BPMN 2.0 notasyonundaki süreç diyagramı

Yaşam pratiği

Şek. Şekil 6, çok spesifik bir şirketin iş analistleri tarafından kendi icat ettikleri notasyonda geliştirilen süreç diyagramının bir parçasını göstermektedir. Diyagram "Basit akış şeması" ilkeleri kullanılarak oluşturulmuştur - "Çözüm" bloğu klasik versiyon. Ek olarak diyagramda standart olmayan bir şekilde kullanılan diğer birçok sembol gösterilmektedir.

Pirinç. 6. Şirketlerden biri için süreç diyagramı örnekleri

Diyagramı oluştururken Şekil. 6'da, iş analistlerinin ortalama kullanıcı için netlik ve maksimum anlaşılırlık konusunda "mücadele ettiği" açıktır. Süreç diyagramları üzerindeki metinsel yorumları en aza indirmeye, hatta ortadan kaldırmaya çalıştılar. Sanatçılara basitçe A3 formatında bir şema basıldı ve okuduktan sonra her şey hemen netleşti: ne yapmalı, nasıl, hangi belgeleri kullanmalı vb.

Söz konusu şema elbette basitlik ve netliğin bir örneği değildir. Ancak sürece dahil olanlara maksimum yararlı bilgiyi aktarmak için oluşturulmuştur.

Sonuçlar

Dolayısıyla süreçleri anlatırken çalışanlar için basitlik ve netlik sağlamaya çalışmanız gerektiği açıktır.

Süreçleri tanımlarken karmaşık, resmileştirilmiş gösterimlerin kullanılması aşağıdakilere yol açar:

• Diyagramların sıradan çalışanlar tarafından kullanılmasında (yorumlanmasında) zorluklar;
• Geçmiş departman çalışanları tarafından süreçleri tanımlamak için iş organize etmenin imkansızlığı (zorluğu) özel eğitim;
• Planların oluşturulması için iş analistlerinin işgücü maliyetlerinde önemli bir artış;
• Devreleri belgelendirirken ek zorluklar (büyük hacim, vb.).

Bu nedenle süreç diyagramını çeşitli grafik öğelerle karıştırmamalısınız. Ama eğer onları kullanırsan, taşımaları daha iyi olur faydalı bilgilerçalışanlar için ve sadece modelleme notasyonlarının resmi uygulamasının bir sonucu değildi.

http://finexpert.ru/ - profesyoneller için iletişim ortamı http://bpm3.ru/ - süreçler, projeler, verimlilik

Kovalev Sergey Mihayloviç
Kovalev Valery Mihayloviç
(Yönetmen Danışmanı Dergisi, Sayı 12, Haziran 2004)

İş süreçlerini tanımlamak için yedi “altın” kural

İş süreçlerini tanımlamaya yönelik metodoloji oldukça basittir ancak pratikte etkili bir şekilde uygulanması basit bir iş değildir. Bir şirketin iş süreçlerini anlatırken ortaya çıkan tuzaklar, bu işin etkinliğini sıfıra indirebilir. Tuzakların ortaya çıkması insan faktörüyle ilişkilidir, çünkü şirket çalışanlarının çoğunluğu kendi organizasyonlarında bu tür işleri yapmakla ilgilenmemektedir.

İş süreçlerinin tanımlanması şirkette kimin ne yaptığı, kimin neyden sorumlu olduğu sorularına yanıt verir. Bu, şirketi şeffaf ve yönetime karşı hesap verebilir hale getirir. Şeffaflık öncelikle örgüt liderlerine fayda sağlarken, tüm çalışanları kişisel çıkarlarının zararına olacak şekilde örgütün hedefleri doğrultusunda çalışmaya zorlar. Üstelik iş süreçlerinin anlatılması ve şeffaflığın arttırılması, çalışanların acil durumlar için “biriktirdiği” fazla mali ve zaman kaynaklarının tespit edilmesini mümkün kılıyor. Dolayısıyla çalışanların çoğunluğu bu işle ilgilenmiyor ve şirketin faaliyetlerini anlatırken sürekli direnç ortaya çıkıyor, şirkette kimin ne yaptığı, kimin neyden sorumlu olduğu konusunda gerçek bilgiye ulaşmalarını engelliyor.

İlgisiz tarafların iş süreçlerinin tanımlanmasına karşı direncini azaltmak için, şu kaynaktan türetilen "altın" kuralları kullanmanız gerekir: pratik deneyim böyle bir çalışma yürütmek.

Kural 1. İş süreçlerinin “sahipleri”/“katılımcıları” ile birlikte diyagramları hazırlayın, açıklığa kavuşturun ve onaylayın.

İş süreçlerini anlatırken, bu sürece katılan ve bunların uygulanmasının etkinliğinden sorumlu olan uzmanların aktif olarak dahil edilmesi gerekir. Birincisi, bu, işi hızlandıracak ve sonuçların kalitesini artıracaktır, çünkü süreç katılımcılarının yanı sıra, iş sürecinin gerçekte nasıl gerçekleştiğini kimse daha iyi bilemez. İkinci olarak, geliştirilen açıklamalara dayanarak gelecekte iş süreçlerinde optimizasyon ve değişiklikler gerçekleştirilecektir. Ana kurallardan biri etkili uygulama Değişiklikler, sürece dahil olan ve faaliyetleri değişikliklerden etkilenecek çalışanların erken katılımıdır.

Kural 2. Gruptaki iş verimliliğini artırmaya yardımcı olan iş süreçlerini tanımlamak için görsel yaklaşımlar kullanın.

İş süreçlerini anlatırken alınan bilgileri hızlı bir şekilde kaydetmeniz ve görselleştirmeniz gerekir. Grup halinde çalışırken, bir sunum tahtası veya beyaz tahta kullanabilirsiniz. çalışma grubuİş sürecinin bir açıklaması geliştirilecek ve kaydedilecektir. Bir iş süreci diyagramının görüntüsünün özel bir yazılım kullanılarak geliştirildiği bir multimedya projektörünün kullanımına ilişkin yaklaşım. yazılım gerçek zamanlı olarak ekranda görüntülenir.

Kural 3. İş sürecinin "sahipleri"/"katılımcıları" için anlaşılır bir dil kullanın.

İş süreçlerini anlatırken organizasyonda kabul edilen dil ve terminolojiyi kullanmanız gerekir. Her şirketin kendine has özellikleri vardır; iş süreçleri, işlevler, belgeler ve departmanlar için kendi yerleşik isimleri vardır. Bu nedenle yerleşik terminolojinin kullanılması tavsiye edilir. Bu, iş süreci diyagramlarını süreçteki tüm katılımcılar için anlaşılır hale getirecek ve bunları koordine ederken, analiz ederken ve optimize ederken çok fazla zaman tasarrufu sağlayacaktır.

Kural 4. Organizasyon yapıları değil, faaliyet şemaları oluşturun.

İş süreçlerini açıklarken mevcut olanı “unutmanız” gerekir. organizasyon yapısı ve bunu iş süreçlerini ve faaliyetlerini öne çıkarma aracı olarak kullanmayın. İş süreçleri strateji temelinde inşa edilir ve organizasyon yapısı bunlara uyum sağlar, ancak bunun tersi mümkün değildir. Bu nedenle organizasyon yapısı son anda tanımlanır ve iş süreçlerine eklenir. Süreçlerle arayüz oluşturmayacak olması optimal olmadığını gösterir. Bu kuralı ihmal edersek ve mevcut organizasyon yapısını iş süreçlerini ve çalışmayı vurgulamanın bir aracı olarak kullanırsak, optimal olmayan bir organizasyon yapısı durumunda iş süreçlerine ilişkin geliştirilen tanımların çarpıtılma olasılığı oldukça yüksektir.

Çalışanların "Malların tedarikçiden teslimi" iş sürecini tanımladığı bir şirket örneğine bakalım. Bu çalışmayı gerçekleştirirken bu iş sürecinin sınırının ne olduğu sorusu ortaya çıktı. Bir grup uzman, teslim edilen malların ücretsiz satışta olduğu ve satış departmanlarının bunları satabileceği gerçeğini "Teslimat" iş sürecinin son sınırı olarak düşünmeyi önerdi. Satın alma departmanı uzmanları daha büyük ölçüde bu iş sürecine katılarak, bu iş sürecini kendi departmanlarının sorumluluk organizasyonel sınırları altına “çekmeye” çalıştılar ve “Teslimat” sürecinin sınırının, malların satın alınarak depo kapılarına teslim edilmesi olduğunu savundular. “Teslimat” iş sürecinin sınırını tanımlamaya yönelik ikinci seçenekte, mevcut organizasyon yapısı bir araç olarak kullanılmıştır ki bu yanlıştır, çünkü bu aşamada optimallik derecesi hakkında hiçbir şey bilinmemektedir.

Kural 5. Özellikle "olduğu gibi" diyagramında iş süreçlerinin aşırı ayrıntısından kaçının.

İş süreçlerini anlatırken ortaya çıkan sorunlardan biri de optimal detay seviyesinin ihlalidir ve bu da iş miktarının önemli ölçüde artmasına neden olur. Aynı zamanda aşırı detay, Pareto kanunu 20 ila 80'e göre ek etki sağlamamakla kalmaz, aynı zamanda proje katılımcılarının aşırı bilgi yüklemesiyle ilişkili olumsuz sonuçlara yol açar, iş sonuçlarının kalitesini düşürür ve çoğu zaman projenin başarısız olmasına yol açar. tüm olay.

Bu durumda, bir kuralı daha hatırlamanız gerekir - bir iş sürecini optimize ederken yapılması planlanan değişiklikler ne kadar büyük olursa, iş sürecinin "olduğu gibi" bir açıklaması o kadar az ayrıntılı olarak geliştirilmelidir.

Kural 6: Daha fazla analiz ve eylem gerektirmeyen diyagram oluşturma uğruna bir iş süreci diyagramı oluşturmaktan kaçının.

Tartışılan iş süreci tanımlama araçları, yalnızca iş süreçlerini optimize etme ve iyileştirme gibi daha yüksek hedeflere ulaşmaya yönelik bir araçtır. Bu çalışmayı gerçekleştirirken gerçek hedefleri sürekli hatırlamalı ve araçlara ve programların geliştirilmesine takılıp kalmamalısınız.

Aşağıdaki durum oldukça sık meydana gelir. Şirket iş süreçlerini anlatmaya başlıyor, herkes bu işi gerçekten seviyor, herkes iş süreçlerinin ve organizasyon yapısının diyagramlarını oluşturuyor ve kimse bu ilginç ve keyifli aktiviteyi durdurmak istemiyor. Bu durumda vurgu problem çözmekten devre geliştirmeye kayar. Bu nedenle, nihai hedefin optimizasyon olduğunu ve açıklamanın, hedefe ulaşmanın bir yolu olarak düşünülmesi gereken bir araç olduğunu sürekli hatırlamalısınız.

İşletmeyi entegre bir bilgi sisteminin uygulanmasına hazırlamak için bir şirketteki iş süreçlerini tanımlama örneğine bakalım. İş süreçlerini anlatırken IDEF0 metodolojisi kullanıldı. İş süreçlerinin tanımlanmasında yer alan uzmanlar, kendi aralarındaki ilişkiyi çözmek ve neyin ortaya çıktığına karar vermek için uzun zaman harcadılar. tartışmalı konu- “Mal Kabulü” iş sürecinin ortamını anlatırken tedarikçiden mallarla birlikte gelen faturanın neleri içermesi gerektiği. Bazıları faturanın bir iş sürecine girdi olduğuna inanıyordu, bazıları ise bunun yönetim olduğuna inanıyordu. Anlaşmazlık iki hafta sürdü, ancak herkes ikna olmadı.

Kural 7. "Olduğu gibi", "olması gerektiği gibi", "olacağı gibi" kavramlarını karıştırmayın.

İş süreçlerini anlatırken “olduğu gibi”, “olması gerektiği gibi” ve “olacağı gibi” kavramlarını karıştırmamak gerekir. İş süreci optimizasyon teknolojisine göre ilk adım, sürecin "olduğu gibi" tanımlanmasıdır. Bu nedenle, “eğriliklerine” bakılmaksızın, yalnızca bu işleri, yalnızca gerçekte var olan organizasyon yapısını tanımlamak gerekir. Çoğu zaman, görüşmeler sırasında faaliyetleri anlatılan çalışanlar hayal kurmaya ve gerçeklikten çok farklı şeyler anlatmaya başlar. Neden böyle davrandıklarını sorduğunuzda, kendilerine göre böyle olması gerektiği cevabını veriyorlar. Sonuç olarak, oluşturulan iş süreci diyagramları gerçeğe uygun değildir, bu da bilgiyi çarpıtır ve iş süreçlerinin etkin optimizasyon olasılığını azaltır.

Şirketlerin iş süreçlerine yeniden yönlendirilmesi - iş yeniden yapılanması- yeniden yapılandırmak anlamına gelir iç çalışma ve kontrol sistemleri. Bu, şirket çalışanlarının alışılagelmiş yollarından kopması, sorumluluklarının gözden geçirilmesi, işlerinin azalması/arttırılması gibi zorlu ve sancılı bir süreçtir. ücretler ve sıklıkla - işten çıkarmalar. Burada çok şey var çeşitli işler ve diğer şeylerin yanı sıra - yeni iş planları tasarlamak ve dolayısıyla yeni iş süreçleri.

Bir iş sürecinin iyi bir şekilde resmileştirilmesi neden önemlidir?

1. Düşüncelerimizi geniş bir tartışma konusu haline getirmemizi sağlar.
2. Yeni çalışma kurallarının bunlara uyacak çalışanlara aktarılmasını mümkün kılar.
3. Resmileştirilmiş iş süreçlerinin değiştirilmesi ve modernleştirilmesi daha kolaydır.
4. İş süreçlerinin resmileştirilmesi, şirketteki daha sonraki iş otomasyonu için iyi bir temel oluşturur: çeşitli süreçlerin oluşturulması/yapılandırılması bilgi sistemleri ve standart otomasyon paketleri.

Görsel modellerin biçimlendirme aracı olarak sunulduğunu tahmin etmek zor değil. Bu yöntemin sıradan metinlere göre avantajları gelenekseldir: İnsanların büyük metinleri okuması zordur, ancak diyagramları kolayca tartışabilirler. Aynı zamanda diyagramlar, eylem türlerini, katılımcıları ve sonuçları adım adım belirlemenize olanak tanıyan oldukça resmi açıklamalardır.

İş süreci örneği

Örnek olarak büyük bir mobilya perakende mağazasını ve onun “Müşterinin mal satın alması” iş sürecini ele aldım. Şek. Şekil 9.1, bu iş sürecinin BPMN notasyonundaki diyagramını, notasyonla ilgili yorumlarla birlikte göstermektedir.

Tüm iş süreci, köşeleri yuvarlatılmış dikdörtgenler olarak gösterilen eylemlere bölünmüştür. Etkinlikler arasındaki geçişler oklarla gösterilir ve bir etkinlik tarafından oluşturulan veya kullanılan belgeler sağ köşesi köşeli dikdörtgenler olarak gösterilir. Bu dikdörtgenler, onları oluşturan eyleme ve kullanıldıkları eylemlere kesikli çizgilerle bağlanır.

Aşağıdaki iş süreci eylemlerini vurgulayalım.

1. "Sipariş ver." İlk olarak müşteri siparişini verir. Bundan önce asıl şeye, neye ihtiyacı olduğuna karar verdiği varsayılıyor. Örneğin, mutfak seti. Daha sonra ticaret bölümünde mutfak mobilyaları bu departmanın yöneticilerinden biriyle birlikte, satın alması için (mutfağının büyüklüğüne ve isteklerine uygun olarak) bir tasarım projesi hazırlar, siparişinin parametrelerini netleştirir ve bileşenleri ve malzemeleri kesin olarak belirler.
2. "Malların alınması." Müşteri depoya gider ve siparişinin tüm bileşenlerini kendisi seçer, ihtiyaç duyduğu şeyin tam bir listesine sahip olur. Aynı zamanda depo çalışanları da ona yardım ediyor.
3. "Mallar için ödeme ve teslimat düzenlemeleri." Müşteri, seçtiği ürünlerle birlikte (onları bir araba üzerinde taşır) kasaya gider ve seçtiği ürünün parasını öder. Daha sonra, malların ücreti ödendikten sonra teslimat departmanına gider ve burada mobilyalarının teslimatını ve montajını (eğer ihtiyacı varsa) düzenler ve öder; daha sonra evden ayrılır.
4. "Teslimat". Ücreti ödenen ürünler üç gün içerisinde müşteriye teslim edilir.
5. "Toplantı". Bundan sonra eğer müşteri montaj emrini vermişse, usta bir montajcı kendisine gelerek teslim edilen mobilyaların montajını yapar.

Şek. 9.1 aynı belgeler birkaç kez mevcuttur. Bu kolaylık sağlamak amacıyla yapılır, böylece büyük miktarlar Diyagramdaki çizgiler. Bu, önceki derslerde tartışılan bir model öğesini bir diyagrama yükleme kavramını kullanır: aynı model öğesi bir diyagrama birçok kez yüklenebilir. Bu durumda, karşılık gelen birçok diyagramatik öğe vardır, ancak yalnızca bir model öğe vardır.

İş süreci ayrıştırması

Yukarıda sunulan iş sürecinin bütün detaylarıyla birlikte çok daha büyük olduğu açıktır. Ancak tüm bu ayrıntılar tek bir diyagrama yerleştirilirse, anlaşılması son derece zor olacak ve yalnızca otomatik işleme uygun olacaktır. Böyle bir diyagramın yardımıyla iş prosedürünü çalışanlara ve müşterilere açıklamak mümkün olmayacak; pratik rehber. Bununla birlikte, kendinizi yalnızca üst düzey ayrıntılarla sınırlandırırsanız, "prensipte" bir spesifikasyon elde edersiniz - bu, yönetim raporlarına eklenebilir ve yalnızca mobilyaların nasıl satıldığına dair ilk, "temel" bilgi için kullanılabilir. bir mağaza. Ancak iş süreci spesifikasyonunun insanlar için anlaşılır, erişilebilir olmasını ve aynı zamanda eksiksiz olmasını istiyorum. Daha sonra farklı uzmanlar, spesifikasyonlarımızı kullanarak mağazanın ilkeleriyle tanışmalarını basitleştirebilirler - ve sadece genel bir bilgi almak isteyenler