Ubuntu Debian için oynatıcıları indirin. Linux için video oynatıcılar. Müzik çalar Rhythmbox

IDEF0, bir sistemin yapısını ve işlevlerini, ayrıca bu işlevleri birbirine bağlayan bilgi akışlarını ve fiziksel nesneleri gösteren işlevsel bir model oluşturmak için kullanılan bir grafik modelleme gösterimidir. IDEF0 (Fonksiyon Modellemesi için Entegrasyon Tanımı) standardı, 1993 yılında ABD'de Federal Bilgi İşleme Standardı olarak onaylanmıştır. Rusya'da 2000 yılından bu yana yol gösterici belge statüsündedir ve şu anda standart olarak onaylanmamıştır. Bununla birlikte IDEF0 metodolojisi iş süreçlerini tanımlamak için kullanılan popüler yaklaşımlardan biridir. Özellikleri şunları içerir:

bir bağlam diyagramı kullanma;

ayrışma desteği;

hakimiyet;

4 tür ok tanımlama.

Bağlam diyagramı. Modelleme nesnesinin sınır okları olan tek bir blokla temsil edildiği en üstteki diyagram. Bu diyagrama A-0 (A eksi sıfır) denir. Bu diyagramdaki oklar, modellenen nesne ile çevresi arasındaki ilişkileri temsil eder. Diyagram A-0 modelleme alanını ve sınırını oluşturur. A-0 diyagramının bir örneği Şekil 2'de gösterilmektedir. 1.

Şekil 1. IDEF0 gösterimindeki A-0 Diyagramı

Ayrıştırma desteği. IDEF0 gösterimi, gerekli ayrıntı düzeyine kadar sıralı süreç ayrıştırmayı destekler. Ayrıştırmayla oluşturulan alt diyagram ana süreçle aynı alanı kapsar ancak onu daha ayrıntılı olarak açıklar. IDEF0 metodolojisine göre ayrıştırma sırasında ana sürecin okları sınır okları şeklinde alt diyagrama aktarılır.

Hakimiyet. Bağlamsal olmayan bir diyagramdaki IDEF0 model blokları, atanan sayılar sırasına göre diyagramın sol üst köşesinden sağ alt köşesine kadar çapraz olarak yerleştirilmelidir. Diyagramda sol üstte bulunan bloklar, sağ altta bulunan bloklara "hakimdir". "Hakimiyet", bir bloğun diyagramdaki diğer bloklar üzerindeki etkisi olarak anlaşılmaktadır. Diyagram sayfasındaki blokların düzeni, yazarın hakimiyet anlayışını yansıtır. Böylece diyagramın topolojisi hangi özelliklerin diğerleri üzerinde daha büyük etkiye sahip olduğunu gösterir.

4 tür okun tanımlanması. Aşağıdaki ok türleri ayırt edilir: “Giriş”, “Çıkış”, “Mekanizma”, “Kontrol”. Girdiler, çıktı olarak görünen şeyi yaratmak için bir süreç tarafından dönüştürülür veya tüketilir. Yönetim koşulları belirliyor süreç için gerekli Doğru çıktıyı üretmek için. Çıktılar, bir süreç tarafından üretilen veriler veya maddi nesnelerdir. Mekanizmalar, bir sürecin yürütülmesini destekleyen araçları tanımlar. Böylece IDEF0 bloğu, kontrol eylemlerini dikkate alan mekanizmalar kullanılarak girişin çıkışa dönüşümünü gösterir.

IDEF0 gösteriminde kullanılan grafik sembollerinin amacına ilişkin açıklama Tablo 1'de verilmiştir.

İsim	Grafik sembolü	Tanım
		Süreç dikdörtgen bir blokla gösterilir. Her bloğun içinde adı ve numarası bulunur. Ad, etkin bir fiil, fiil cümlesi veya sözlü isim olmalıdır. Blok numarası sağ alt köşede bulunur. Blok numaraları diyagramda ve ilgili metinde tanımlama için kullanılır.
		Oklar sürece giren ve çıkan nesneleri (verileri) temsil eder. Her tarafı fonksiyon bloğu Blok atıcı iletişimi açısından standart bir anlama sahiptir. Buna karşılık, bloğun okun bağlandığı tarafı, onun rolünü benzersiz bir şekilde belirler. Oklar dahil Sol Taraf blok - girişler. Bloğa yukarıdan giren oklar kontrollerdir. İşlemi sağda bırakan oklar çıkışlardır, yani. Bir süreç tarafından üretilen veri veya maddi nesneler. Bloğun alt kısmına bağlanan oklar mekanizmaları temsil etmektedir.
Tünelli ok		Tünelli oklar, bu okların aktardığı verilerin ana grafikte ve/veya alt grafikte dikkate alınmadığı anlamına gelir. Tünelin bir bloğa katıldığı yere yerleştirilen ok, o okla ifade edilen verinin bir sonraki ayrıştırma seviyesinde gerekli olmadığı anlamına gelir. Serbest uçtaki bir tünele yerleştirilen ok, temsil ettiği verilerin ana grafikte bulunmadığı anlamına gelir. IDEF0, Proses, Prosedür gösterimlerindeki proses diyagramlarında tünelli oklar kullanılabilir.
		Bir öğe, modellenen sistemin sınırları dışındaki bir yeri, varlığı veya varlığı belirtir. Modelin dışındaki bir okun kaynağını veya hedefini belirtmek için dış referanslar kullanılır. Grafiklerde Dış referans yanında Harici bağlantının adının gösterildiği bir kare olarak gösterilir. Dış bağlantılar herhangi bir gösterimdeki süreç diyagramlarında kullanılabilir.
		Başka bir diyagramı temsil eden bir öğe. Diyagramlar arası bağlantı, bir okun, üstteki diyagramda görüntülenmeden (hiyerarşik modeller kullanıldığında) başka bir süreç diyagramına hareket ettiğini belirtmek için kullanılır. EPC ve BPMN gösterimlerindeki bir süreç diyagramı, diyagramlar arası bağlantı görevi göremez. Diagramlar arası referanslar IDEF0, Proses, Prosedür notasyonlarındaki proses diyagramlarında kullanılabilir.
		Öğe, genel bir süreç modeline bağlantıyı belirtir. İş süreci modeli içerisinde en sık tekrarlanan süreçler, ayrı bir klasörde tipik olarak vurgulanabilir. Gezgin. Diyagram standart süreç bir yerde bir kez oluştu Gezgin. Ayrıca herhangi bir diyagramda tipik bir prosese proses bağlantısı kullanılabilir. Tipik bir prosesin parametreleri doğrudan doldurulur. Özellikler penceresi standart süreç. Standart sürecin uygulanmasına katılan konuların kalıcı bir listesi de oluşturulur. Özellikler penceresi standart süreç. Üstteki süreç çerçevesinde standart bir sürecin yürütülmesine katılan konuların bir listesi oluşturulur. Özellikler penceresi standart bir sürece süreç bağlantısı. Referans süreçleri, süreç diyagramlarında herhangi bir gösterimde kullanılabilir.
		Yorum yapmak için tasarlanmış uzak bir öğe. Öğe, süreç diyagramlarında herhangi bir gösterimde kullanılabilir.

Bir IS oluşturmanın ilk aşamalarında, otomatikleştirilecek organizasyonun nasıl çalıştığını anlamak gerekir. Kuruluştaki hiç kimse IP'yi oluşturmak için gereken ayrıntıda nasıl çalıştığını bilmiyor. Yönetici işi bir bütün olarak iyi biliyor, ancak her sıradan çalışanın işinin ayrıntılarını derinlemesine inceleyemiyor. Sıradan bir çalışan, işyerinde neler olup bittiğini çok iyi biliyor ancak meslektaşlarının nasıl çalıştığını bilmiyor. Bu nedenle bir işletmenin işleyişini anlatmak için bir model oluşturmak gerekir. Böyle bir modelin konu alanına uygun olması, dolayısıyla kurumun iş süreçlerindeki tüm katılımcıların bilgilerini içermesi gerekir.

İş süreçlerini modellemek için en uygun dil, 20 yılı aşkın bir süre önce Douglas Ross (SoftTech, Inc.) tarafından önerilen ve başlangıçta SADT - Yapılandırılmış Analiz ve Tasarım Tekniği olarak adlandırılan IDEF0'dır. (1970'lerin başında ABD ordusu, Entegre Bilgisayar Destekli Üretim (ICAM) programı kapsamındaki projeleri uygulamak için SADT'nin süreç modelleme alt kümesini kullandı. SADT'nin bu alt kümesi daha sonra IDEF0 adı altında bir ABD federal standardı olarak kabul edildi. Ayrıntılı Spesifikasyonlar IDEF standartlarına http://www.idef.com adresinden ulaşılabilir.

IDEF0'da bir sistem, etkileşimli etkinliklerin veya işlevlerin bir koleksiyonu olarak temsil edilir. Bu tamamen işlevsel yönelim esastır; sistemin işlevleri, birlikte çalıştıkları nesnelerden bağımsız olarak analiz edilir. Bu, kuruluş süreçlerinin mantığını ve etkileşimini daha net bir şekilde modellemenize olanak tanır.

IDEF0'daki bir model, önceden belirlenmiş bazı soruları yanıtlaması gereken bir sistemin (metinsel ve grafiksel) açıklaması olarak anlaşılmaktadır.

Simüle edilen sistem, Evrenin keyfi bir alt kümesi olarak kabul edilir. Keyfidir çünkü ilk olarak, belirli bir nesnenin sistemin bir parçası olup olmayacağını spekülatif olarak kendimiz belirleriz, yoksa onu dış bir etki olarak mı değerlendireceğiz ve ikincisi, sistemin bakış açısına bağlıdır. Sistemin kendisini Evrenin geri kalanından ayıran bir sınırı vardır. Bir sistemin dış dünya ile etkileşimi, girdi (sistem tarafından işlenen bir şey), çıktı (sistem faaliyetlerinin sonucu), kontrol (işin yürütüldüğü stratejiler ve prosedürler) ve mekanizma olarak tanımlanır. işi yürütmek için gerekli kaynaklar). Sistem kontrol altındayken mekanizmalar kullanarak girdileri çıktılara dönüştürür.

IDEF0'da bir sistemi modelleme süreci, bağlamın, yani sistemin bir bütün olarak tanımlanmasının en soyut düzeyinin tanımlanmasıyla başlar. Bağlamda modelleme konusunun tanımı, modelin amacı ve bakış açısı yer almaktadır.

Konu sistemin kendisi olarak anlaşılmaktadır ve tam olarak neyin sisteme dahil olduğunu ve neyin dışında olduğunu belirlemek gerekir, başka bir deyişle, daha sonra neyi sistemin bileşenleri olarak ele alacağımızı ve neyin bir sistem olarak ele alınacağını belirlememiz gerekir. dış etki. Sistemin konusunun tanımı, sisteme bakılan konumdan ve modellemenin amacından - oluşturulan modelin cevaplaması gereken sorulardan - önemli ölçüde etkilenecektir. Yani öncelikle modellemenin kapsamının belirlenmesi gerekmektedir. Hem bir bütün olarak sistemin hem de bileşenlerinin alanının açıklaması, bir model oluşturmanın temelidir. Kapsamın simülasyon boyunca ayarlanabileceği varsayılsa da, simülasyonun yönünü ve modelin ne zaman tamamlanması gerektiğini belirleyen kapsam olduğundan esas olarak başlangıçta formüle edilmesi gerekir. Kapsamı formüle ederken dikkate alınması gereken iki bileşen vardır: genişlik ve derinlik. Genişlik, modelin sınırlarını tanımlamayı içerir; neyin sistemin içinde, neyin dışında dikkate alınacağını biz belirleriz. Derinlik, modelin hangi ayrıntı düzeyinde tamamlanacağını belirler. Sistemin derinliğini belirlerken zaman sınırlamalarını unutmamak gerekir - bir model oluşturmanın karmaşıklığı, ayrışmanın derinliğiyle birlikte katlanarak artar. Modelin sınırları tanımlandıktan sonra, modellenen sisteme hiçbir yeni nesnenin dahil edilmemesi gerektiği varsayılır; Tüm model nesneler birbirine bağlı olduğundan, yeni bir nesnenin eklenmesi yalnızca aritmetik bir toplama değil aynı zamanda mevcut ilişkileri de değiştirebilir. Bu tür değişikliklerin yapılması bitmiş model kural olarak çok emek yoğun bir süreçtir (“değişken alan” sorunu olarak da bilinir).

Modelleme Amacı. Açıkça tanımlanmış bir amaç olmadan bir model oluşturulamaz. Hedef aşağıdaki sorulara cevap vermelidir:

Bu süreç neden modellenmeli?

Model neyi göstermeli?

Okuyucu ne alabilir?

Bir hedef belirlemek, analiz ekibinin çabalarını doğru yöne odaklamasına olanak tanır. Hedef beyanlarına örnek olarak aşağıdaki ifadeler verilebilir: “Belirleyin ve tanımlayın güncel konular, potansiyel iyileştirmelerin analiz edilmesini mümkün kılmak”, “Çalışanların iş tanımlarının yazılmasındaki rol ve sorumluluklarının belirlenmesi”, “Bilgi sistemi spesifikasyonlarının yazılması amacıyla işletmenin işlevselliğinin tanımlanması” vb.

Bakış açısı. Model oluşturulurken farklı kişilerin görüşleri dikkate alınsa da modelin tek bir bakış açısıyla oluşturulması gerekmektedir. Bakış açısı, sistemi modelleme için gerekli olan açıdan gören kişinin bakış açısı olarak temsil edilebilir. Bakış açısı modellemenin amacına uygun olmalıdır. Açıkçası, işletmenin çalışmasının bir finansçı ve bir teknoloji uzmanı açısından tanımı tamamen farklı görünecektir, bu nedenle modelleme sırasında seçilen bakış açısına bağlı kalmak önemlidir. Kural olarak, simüle edilen işten bir bütün olarak sorumlu olan kişinin bakış açısı seçilir. Çoğu zaman bir model üzerinde bir perspektif seçerken ek alternatif perspektifleri belgelemek önemlidir. FEO (Yalnızca Pozlama İçin) çizelgeleri bu amaç için yaygın olarak kullanılır.

IDEF0 modeli, açıkça formüle edilmiş bir hedefin, tek bir modelleme konusunun ve tek bir bakış açısının varlığını varsayar. BPwin'de IDEF0 modellerine kapsam, amaç ve bakış açısı eklemek için menü öğesini seçin Özellikleri Düzenle/Modelle, Model Özellikleri iletişim kutusunu açar (Şek. 4). Favorilere eklendi Amaç bir hedef, bakış açısı ve yer işareti eklemelisiniz Tanım- modelin tanımı ve alanın açıklaması.

Favorilere eklendi Durum Aynı iletişim kutusunda modelin durumunu (taslak, çalışma, nihai vb.), oluşturulma zamanını ve son düzenlemeyi (daha sonra sistem tarihi tarafından otomatik olarak takip edilir) tanımlayabilirsiniz. Favorilere eklendi Kaynak Modelin oluşturulmasına yönelik bilgi kaynakları açıklanmaktadır (örneğin, “Uzmanlarla yapılan anket konu alanı ve belgelerin analizi"). Genel Projenin ve modelin adını, yazarın adını ve adının baş harflerini ve modelin zaman dilimini girmeye yarar - OLDUĞU GİBİ Ve TO-VE.

Pirinç. 4. Model özelliklerini ayarlama iletişim kutusu

Olduğu Gibi ve Olması Gereken Modeller. Genellikle ilk önce mevcut iş organizasyonunun bir modeli oluşturulur - OLDUĞU GİBİ (olduğu gibi). AS-IS modeline dayanarak, çeşitli iş birimleri arasında "kimin ne yaptığı" ve her iş biriminin sürece ne kattığı konusunda fikir birliğine varılır. AS-IS modeli, "yarın ne yapacağımıza" geçmeden önce "bugün ne yaptığımızı" anlamamıza olanak tanır. Fonksiyonel modelin analizi, en çok nerede olduğunu anlamamızı sağlar. Zayıf noktalar, yeni iş süreçlerinin avantajlarının neler olacağı ve iş organizasyonunun mevcut yapısının ne kadar derin değişikliklere uğrayacağı. İş süreçlerini detaylandırmak, işlevsellik ilk bakışta bariz görünse bile organizasyonun eksikliklerini tespit etmenize olanak sağlar. Etkin olmayan faaliyetin işaretleri işe yaramaz, yönetilmeyen ve mükerrer işler, etkisiz belge akışı (doğru belgenin doğru yerde olmaması) olabilir. doğru zaman), yönetim konusunda geri bildirim eksikliği (iş sonucundan etkilenmez), girdi (nesneler veya bilgiler mantıksız bir şekilde kullanılır) vb. AS-IS modelinde bulunan eksiklikler, TO-BE modeli oluşturulurken düzeltilebilir ( olacağı gibi) - iş süreçlerinin yeni organizasyon modelleri. TO-BE'nin iş yapmanın alternatif/daha iyi yollarını analiz etmek ve şirketin gelecekte nasıl iş yapacağını belgelemek için modele ihtiyacı var.

OLDUĞU GİBİ modeli oluştururken dikkat edilmesi gereken yaygın bir hata, idealleştirilmiş bir model oluşturmaktır. Bir örnek, belirli bir iş icracısına değil, yöneticinin bilgisine dayalı bir modelin oluşturulması olabilir. Yönetici, el kitaplarına ve iş tanımlarına göre işin nasıl yapılması gerektiği konusunda bilgi sahibidir ve çoğu zaman astlarının rutin işleri gerçekte nasıl yaptıklarını bilmez. Sonuç, yanlış bilgi taşıyan ve daha fazla analiz için kullanılamayan, süslenmiş, çarpık bir modeldir. Bu modele SHOULD_BE adı verilir (olması gerektiği gibi).

IS tasarım teknolojisi, önce bir AS-IS modeli oluşturmayı, onu analiz etmeyi ve iş süreçlerini iyileştirmeyi, yani bir TO-BE modeli oluşturmayı içerir ve yalnızca TO-BE modeli temelinde bir veri modeli, bir prototip ve ardından son sürüm bulunur. inşa edilen IS'den. AS-IS modeline dayalı bir sistem oluşturmak, işletmenin "bilgisayarları ayakta tutmak için her şeyi olduğu gibi bırakma" ilkesine göre otomasyonuna yol açar; yani IS, kusurlu iş süreçlerini otomatikleştirir ve mevcut belgeleri değiştirmek yerine kopyalar. akış. Sonuç olarak, böyle bir sistemin uygulanması ve işletilmesi yalnızca ekipmanın satın alınması, yazılımın oluşturulması ve her ikisinin bakımı için ek maliyetlere yol açar.

Bazen mevcut OLDUĞU GİBİ ve gelecekteki TO-BE modelleri çok farklıdır, dolayısıyla başlangıçtan son duruma geçiş açık değildir. Bu durumda sistemin başlangıç ​​durumundan son durumuna geçiş sürecini anlatacak üçüncü bir modele ihtiyaç duyulmaktadır çünkü böyle bir geçiş aynı zamanda bir iş sürecidir.

Model açıklamasının sonucu raporda elde edilebilir Model Raporu. Model raporu ayarları iletişim kutusu menü öğesinden çağrılır Rapor/Model Raporu. Ayarlar iletişim kutusunda gerekli alanları seçmelisiniz ve bilgilerin rapora gönderilme sırası otomatik olarak görüntülenir (Şekil 5).

Pirinç. 5. Model raporu

IDEF0 diyagramları. IDEF0 metodolojisinin temeli grafik dili iş süreçlerinin açıklamaları. IDEF0 gösterimindeki bir model, hiyerarşik olarak sıralanmış ve birbirine bağlı diyagramların bir koleksiyonudur. Her diyagram sistemin bir açıklama birimidir ve ayrı bir sayfada bulunur.

Model dört tür diyagram içerebilir:

bağlam diyagramı (her model yalnızca bir bağlam diyagramına sahip olabilir);

ayrışma diyagramları;

düğüm ağacı diyagramları;

yalnızca pozlama (FEO) çizelgeleri.

Bağlam diyagramı, diyagram ağaç yapısının en üstündedir ve en çok temsil eder. Genel açıklama Sistem ve dış çevre ile etkileşimi. Sistemi bir bütün olarak tanımladıktan sonra büyük parçalara ayrılır. Bu sürece fonksiyonel ayrıştırma adı verilir ve her bir parçayı ve parçaların etkileşimini açıklayan diyagramlara da ayrıştırma diyagramları denir. Bağlam diyagramını ayrıştırdıktan sonra her birinin ayrıştırılması büyük parça sistemleri daha küçük olanlara bölün ve istenen düzeyde açıklama ayrıntısı elde edilene kadar bu şekilde devam edin. Her ayrıştırma oturumundan sonra inceleme oturumları gerçekleştirilir; konunun uzmanları, gerçek iş süreçlerinin oluşturulan diyagramlara uygunluğunu belirtir. Bulunan tutarsızlıklar düzeltilir ve ancak incelemeyi herhangi bir yorum yapmadan geçtikten sonra bir sonraki ayrıştırma oturumu başlayabilir. Bu, modelin, modelin her düzeyinde gerçek iş süreçleriyle eşleşmesini sağlar. Sistemi bir bütün olarak ve onun parçalarının her birini tanımlamaya yönelik sözdizimi, model boyunca aynıdır.

Düğüm ağacı diyagramı, faaliyetlerin hiyerarşik bağımlılığını gösterir ancak faaliyetler arasındaki ilişkileri göstermez. Modelde istenildiği kadar çok sayıda düğüm ağacı diyagramı bulunabilir, çünkü ağaç kökten olmak zorunda değil, isteğe bağlı bir derinliğe kadar oluşturulabilir.

Pozlama diyagramları (FEO), bir modelin parçalarını göstermek, alternatif bir bakış açısını göstermek veya özel amaçlar için oluşturulur.

İşlevsel bir model oluşturma örneği.

Örnek olarak, kurgusal şirket “Computer Word”ün faaliyetleri ele alınmaktadır. Şirket öncelikle masaüstü bilgisayar ve dizüstü bilgisayarların montajını ve satışını yapıyor. Şirket, bileşenleri kendisi üretmiyor, yalnızca bilgisayarların montajını ve testlerini yapıyor.

Şirketteki ana çalışma türleri şunlardır:

satıcılar müşteri siparişlerini kabul eder;

operatörler siparişleri bilgisayar türüne göre gruplandırır;

operatörler bilgisayarları monte eder ve test eder;

operatörler bilgisayarları siparişlere göre paketliyor;

Mağaza sahibi siparişleri müşterilere gönderir.

Şirket, sipariş vermenize, fatura vermenize ve fatura ödemelerini takip etmenize olanak tanıyan lisanslı bir muhasebe bilgi sistemi kullanıyor.

İşin yapılma yöntemi

1. BPwin()'i çalıştırın.

2. Bir iletişim kutusu görüntülenirse ModelMart Bağlantı Yöneticisi, düğmeye tıklayın İptal etmek(İptal etmek).

3. Düğmeye tıklayın. Bir iletişim kutusu belirir Ben istiyorum(Şekil 6). Metin alanına yazın İsim model adı "Şirket Faaliyeti" ve Tür'ü seçin – İş Süreci (IDEF0). Düğmeye bas TAMAM.

Pirinç. 6. Modelin adlandırılması ve model tipinin seçilmesi

4. Bir iletişim kutusu açılacaktır Yeni Modellerin Özellikleri(Yeni modelin özellikleri) (Şek. 7). Metin alanına girin Yazar(Yazar) modelin yazarının adı ve metin alanı Yazarın baş harfleri onun baş harfleri. Tuşlara sırayla basın Uygula Ve TAMAM.

5. Otomatik olarak boş bir bağlam şeması oluşturulur (Şek. 8).

6. Araç çubuğundaki düğmeye dikkat edin. Bu düğme tarama ve gezinme aracını açar ve kapatır - Model Gezgini(Model tarayıcısı). Model Gezginiüç sekmesi var – Faaliyetler (), Diyagramlar() Ve Nesneler(). Sekmede Faaliyetler Model tarayıcısında bir nesneye sağ tıklamak, özelliklerini düzenleme seçeneklerini seçmenize olanak tanır (Şekil 9).

Pirinç. 8. Boş bağlam diyagramı

Pirinç. 9. Tıklayın sağ tık Etkinlikler sekmesindeki nesneye göre, özelliklerini düzenlemek için içerik menüsünü kullanmanıza olanak tanır

7. Menüye gidin Model/Model Özellikleri. Sekmede Genel iletişim kutusu Model Özellikleri metin alanına Model adı“Şirket Faaliyetleri” modelinin adını ve metin alanına girmelisiniz Proje"Şirketin faaliyet modeli" projesinin adı ve son olarak metinde Zaman aralığı(Zaman kapsamı) - OLDUĞU GİBİ(Olduğu gibi) (Şek. 10).

Pirinç. 10. Model özelliklerini ayarlama penceresi

8. Sekmede Amaç iletişim kutusu Model Özellikleri metin alanına Amaç(hedef) modeli geliştirme amacına ilişkin verileri girin - “Şirketin mevcut (OLDUĞU GİBİ) iş süreçlerini modellemek” ve metin alanına Bakış açısı(bakış açısı) - “Yönetmen” (Şek. 11).

Pirinç. 11.Modellemenin amacı ve bakış açısına ilişkin verilerin girilmesi

9. Sekmede Tanım iletişim kutusu Model Özellikleri metin alanına Tanım(Tanım) metin alanına "Bu bir şirketin faaliyetlerini açıklayan bir eğitim modelidir" ifadesini girin Kapsam(kapsam) - " Genel Müdürlükşirketin işi: pazar araştırması, bileşenlerin tedariki, ürünlerin montajı, test edilmesi ve satışı" (Şekil 12).

10. Bağlam diyagramına gidin ve gösterimde temsil eden dikdörtgene sağ tıklayın. IDEF0, işin geleneksel grafik gösterimi. İÇİNDE içerik menüsü seçeneği seç İsim(Şekil 13). Sekmede İsim“Şirket Faaliyetleri” adını girin (Şek. 14).

11. Sekmede Tanım iletişim kutusu Etkinlik Özellikleri metin alanına Tanım(Tanım) “Şirketin mevcut iş süreçlerine” girin (Şekil 15). Metin alanı Not(Notlar) boş bırakın.

Pirinç. 12. Modeli tanımlayan ek verilerin girilmesi

Pirinç. 13. Seçilen Ad seçeneğiyle çalışmak için bağlam menüsü

Pirinç. 14. Esere isim vermek

Pirinç. 15. İşle ilgili ek verilerin girilmesi

12. Oluşturun BEN COM-bağlam diyagramındaki oklar (Tablo 1).

Tablo 1 - Bağlam diyagramı okları

Ok adı (Okİsim)	Ok tanımı (OkTanım)	Ok türü (OkTip)
Müşteri aramaları	Bilgi talepleri, siparişler, teknik destek vb.
Kurallar ve prosedürler	Satış kuralları, montaj talimatları, test prosedürleri, performans kriterleri vb.
Satılan ürünler	Masaüstü bilgisayarlar ve dizüstü bilgisayarlar
Muhasebe Sistemi	Faturaların hazırlanması, faturaların ödenmesi, siparişlerle çalışma

13. Düğmeyi kullanarak diyagram alanına metni girin - bakış açısı ve hedef (Şek. 16).

Pirinç. 16. Metin Bloğu Düzenleyicisini kullanarak bir grafik alanına metin girme

14. Model hakkında bir rapor oluşturun. Menüde Araçlar/Raporlar/Model Raporu(Şekil 17) rapor oluşturma seçeneklerini ayarlayın (kutuları işaretleyin) ve düğmesine tıklayın Ön izleme(Ön izleme) (Şek. 18).

Pirinç. 17. Model Raporu oluşturmak için seçenekleri ayarlama

Pirinç. 18. Model Raporu Önizlemesi

Üretim süreçlerinin metodolojiye göre ayrıştırılmasıIDEF0

Çalışmalar (Etkinlik)

Faaliyetler, belirli bir süre içinde meydana gelen ve tanınabilir sonuçları olan adlandırılmış süreçlere, işlevlere veya görevlere atıfta bulunur. Eserler dikdörtgen şeklinde tasvir edilmiştir. Tüm eserler adlandırılmalı ve tanımlanmalıdır. Eserin adı, eylemi ifade eden sözel bir isim olarak ifade edilmelidir (örneğin, “Parça yapmak”, “Sipariş almak” vb.). "Bir parçanın üretimi" işi örneğin şu tanıma sahip olabilir: "İş, bir ürünün ham maddelerin kalite kontrolünden bitmiş paketlenmiş ürünün sevkiyatına kadar üretilmesinin tüm döngüsünü ifade eder." Yeni bir model oluştururken (menü Dosya/Yeni) sistemi bir bütün olarak tasvir eden tek bir çalışma ile otomatik olarak bir bağlam diyagramı oluşturulur (Şekil 1).

Bir iş adı girmek için işe sağ tıklayın ve menüden seçim yapın Ad Düzenleyici ve beliren iletişim kutusuna işin adını girin. Çalışmanın diğer özelliklerini tanımlamak için diyaloğu kullanın Etkinlik Özellikleri(İncir. 2).

Pirinç. 1. Bağlam diyagramı örneği

Pirinç. 2. İş özelliklerini ayarlamak için düzenleyici

Ayrıştırma diyagramları ilgili çalışmaları içerir; ortak bir ana işi olan alt işler. Bir ayrıştırma diyagramı oluşturmak için düğmeye tıklayın.

Bir diyalog ortaya çıkıyor Etkinlik Kutusu Sayısı(Şekil 3), burada yeni diyagramın gösterimini ve üzerindeki çalışma sayısını belirtmeniz gerekir. Bir notasyon seçelim IDEF0 ve tıklayın TAMAM. Bir ayrışma diyagramı belirir (Şekil 4). Kabul edilebilir iş sayısı aralığı 2-8'dir. İşi tek bir göreve ayırmanın hiçbir anlamı yok: sekizden fazla görevi olan diyagramların aşırı doygun olduğu ve okunması zor olduğu ortaya çıkıyor. Simüle edilen süreçlerin netliğini ve daha iyi anlaşılmasını sağlamak için, bir diyagramda üç ila altı bloğun kullanılması tavsiye edilir.

Pirinç. 3. DiyalogEtkinlik Kutusu Sayısı

Pirinç. 4. Ayrıştırma diyagramı örneği

İş sayısının yeterli olmadığı ortaya çıkarsa, önce araç paletindeki düğmeye, ardından diyagramdaki boş bir alana tıklanarak çalışma diyagrama eklenebilir.

Arıza diyagramlarındaki aktiviteler genellikle sol üstten sağ alta doğru çapraz olarak düzenlenir.

Bu sıraya baskınlık sırası denir. Bu konum ilkesine göre soldaki üst köşe en çok yer alır önemli iş veya işin ilk önce zamanında yapılması. Daha sağda daha az önemli veya daha sonraki görevler vardır. Bu düzenleme diyagramların okunmasını kolaylaştırır ve iş ilişkileri kavramı buna dayanır.

Ayrıştırma diyagramındaki etkinliklerin her biri sırayla ayrıştırılabilir. Bir arıza diyagramında iş otomatik olarak soldan sağa doğru numaralandırılır. İş numarası sağ alt köşede gösterilir. Sol üst köşede bu eserin ayrıştırılmadığını gösteren küçük bir çapraz çizgi bulunmaktadır. Yani örneğin “Bir ürünün montajı” işi 3 numaradır ve henüz ayrıştırılmamıştır. "Kalite Kontrol" çalışması (4 numara) daha düşük bir ayrışma seviyesine sahiptir

Oklar

Eserlerin etkileşimi dış dünya ve kendi aralarında oklar şeklinde anlatılmıştır. Oklar bazı bilgileri temsil eder ve isim olarak adlandırılır (örneğin, “Ürün”, “Ürün”, “Sipariş”).

IDEF0'da beş tür ok vardır:

Giriş- bir sonuç (çıktı) üretmek için çalışma tarafından kullanılan veya dönüştürülen malzeme veya bilgi. Eserin tek bir giriş okuna sahip olmamasına izin verilir. Her ok türü, işi temsil eden dikdörtgenin belirli bir kenarına yaklaşır veya oradan ayrılır. Giriş oku eserin sol kenarına girecek şekilde çizilir. Teknolojik süreçleri tanımlarken (IDEF0'ın icat edilmesinin nedeni budur), girdileri tanımlamada hiçbir sorun yoktur. Aslında, Şekil 2'deki "Hammaddeler". 1. “Ürün Yapımı” sürecinde bir sonuç üretmek için işlenen bir şeydir. Bir IP'yi modellerken, oklar fiziksel nesneler değil veriler olduğunda, her şey o kadar açık değildir. Örneğin “Hasta Kabulü” sırasında hastanın kartı hem girişte hem de çıkışta olabiliyor, bu arada bu verinin kalitesi de değişiyor. Başka bir deyişle, bu örnekte amacını haklı çıkarmak için, giriş ve çıkış oklarının, verinin gerçekten işlendiğini gösterecek şekilde tam olarak tanımlanması gerekir (örneğin, çıktı "Tamamlanmış Hasta Kaydıdır"). Verinin girdi mi yoksa kontrol mü olduğunu belirlemek genellikle zordur. Bu durumda eserde verinin işlenip işlenmediği/değiştirilip değiştirilmediği konusunda bir ipucu ortaya çıkabilmektedir. Eğer değişirlerse, büyük olasılıkla bu bir girdidir; değilse, kontroldür.

Kontrol- Çalışmayı yönlendiren kurallar, politikalar, prosedürler veya standartlar. Her işte en az bir kontrol oku bulunmalıdır. Kontrol oku işin üst kenarına girecek şekilde çizilir. İncirde. 1 ok “Görev” ve “Çizim” - “Bir ürünün imalatı” çalışmasının kontrolü. Yönetim işi etkiler ama iş tarafından dönüştürülmez. Bir işin amacı bir prosedür veya stratejiyi değiştirmekse, o prosedür veya strateji işe girdi olacaktır. Bir okun durumunda (kontrol veya giriş) belirsizlik varsa, bir kontrol okunun çizilmesi önerilir.

Çıktı- çalışma tarafından üretilen malzeme veya bilgi. Her işin en az bir çıkış oku olması gerekir. Sonuçsuz çalışmanın hiçbir anlamı yoktur ve modellenmemelidir. Çıkış oku eserin sağ kenarından çıkacak şekilde çizilir. İncirde. 1 ok "Bitmiş ürün", "Ürün imalatı" çalışmasının çıktısıdır.

Mekanizma- işi gerçekleştiren kaynaklar örneğin işletme personeli, makineler, cihazlar vb. Mekanizma oku işin alt kenarına dahil edilecek şekilde çizilir. İncirde. 1 ok "Kurumsal personel", "Ürün imalatı" çalışmasına yönelik bir mekanizmadır. Analistin takdirine bağlı olarak mekanizmanın okları modelde gösterilmeyebilir.

Arama- farklı bir çalışma modelini gösteren özel bir ok. Çağrı oku eserin alt kenarından çıkacak şekilde çizilmiştir. İncirde. 1 ok "Diğer iş modeli", "Ürün imalatı" çalışmasına bir çağrıdır. Modellenen sistemin dışında bazı çalışmaların yapıldığını belirtmek için çağrı oku kullanılır. BPwin'de modelleri birleştirme ve bölme mekanizmasında çağrı okları kullanılmaktadır.

Kenar okları. Bağlam diyagramındaki oklar sistemin dış dünyayla etkileşimini tanımlamak için kullanılır. Diyagramın sınırında başlayıp işte bitebilirler veya tam tersi de olabilir. Bu tür oklara sınır okları denir.

Sınır girişi oku eklemek için:

Kontrol, çıkış, mekanizma ve çıkış okları benzer şekilde gösterilmektedir. Örneğin bir çıkış oku çizmek için, araç paletinde ok sembolünün bulunduğu düğmeye tıklayın, çıkış tarafındaki işin sağ tarafına (okun başladığı yere) tıklayın, imleci Sağ Tarafİlk çizgi çubuğu görünene kadar ekranda gezinin ve çizgi çubuğuna bir kez tıklayın.

Yeni eklenen okların adları sözlüğe otomatik olarak girilir ( Ok Sözlüğü).

ICOM kodları.Çalışmayı detaylandırmak için bir arıza şeması tasarlanmıştır. Bir organizasyonun yapısını gösteren modellerden farklı olarak IDEF0'da üst düzey diyagramdaki çalışma, altındaki çalışma üzerinde kontrol sağlamaz. Alt düzey çalışma, üst düzey çalışmayla aynıdır ancak daha ayrıntılıdır. Sonuç olarak, üst düzey bir çalışmanın sınırları, bir ayrıştırma diyagramının sınırlarıyla aynıdır. BEN COM(kısaltması Giriş, Kontrol, Çıkış ve Mekanizma) - sınır oklarını tanımlamayı amaçlayan kodlar. Kod BEN COM ok türüne karşılık gelen bir önek içerir ( BEN,İLE,HAKKINDA veya M), Ve seri numarası. BPwin, ICOM kodlarını otomatik olarak girer. ICOM kodlarını görüntülemek için sekmedeki ICOM kodlarını göster seçeneğini etkinleştirin Sunum diyalog Model Özellikleri.

Ok sözlüğü özel bir düzenleyici kullanılarak düzenlenir Ok Sözlük Düzenleyicisi Okun tanımlandığı ve onunla ilgili bir yorumun girildiği yer (Şekil 6). Ok sözlüğü çok önemli bir sorunu çözüyor. Diyagramlar, bir inceleme oturumunu yürütmek, yani diyagramı konunun uzmanıyla tartışmak amacıyla bir analist tarafından oluşturulur. Herhangi bir konu alanında profesyonel jargon oluşur ve sıklıkla jargon ifadeleri belirsiz bir anlama sahiptir ve farklı uzmanlar tarafından farklı şekilde algılanır. Aynı zamanda, diyagramların yazarı olan analist, uzmanlar için en anlaşılır ifadeleri kullanmalıdır. Resmi tanımların anlaşılması genellikle zor olduğundan, analist profesyonel jargon kullanmak zorunda kalır ve belirsiz yorumlardan kaçınmak için ok sözlüğünde her kavrama genişletilmiş ve gerekirse resmi bir tanım verilebilir.

Ok sözlüğünün içeriği bir rapor olarak yazdırılabilir (menü Rapor/Ok Raporu...) ve böylece modelde kullanılan alan terimlerinin açıklayıcı bir sözlüğünü elde edin.

Pirinç. 5. DiyalogOk Özellikleri

Pirinç. 6. Kelime okları

Bağlantısız kenarlık oku. Bir eseri ayrıştırırken, ona giren ve çıkan oklar (çağrı oku hariç) otomatik olarak ayrıştırma diyagramında (okların geçişi) görünür, ancak eserlere dokunmaz. Bu tür oklara bağlantısız denir ve BPwin'de sözdizimi hatası olarak değerlendirilir. Giriş, kontrol veya mekanizma oklarını bağlamak için ok düzenleme moduna geçmeli, ok ucuna ve ilgili çalışma bölümüne tıklamalısınız. Bir çıkış okunu bağlamak için ok düzenleme moduna geçmeniz, iş çıkışı segmentine ve ardından oka tıklamanız gerekir.

İç oklar. Eserleri birbirine bağlamak için iç oklar kullanılır, yani diyagramın kenarlarına değmeyen oklar bir eserde başlar ve diğerinde biter.

Dahili bir ok çizmek için, ok çizim modunda bir eserin bir bölümüne (örneğin, çıkış) ve ardından başka bir eserin bir bölümüne (örneğin, giriş) tıklamanız gerekir. IDEF0 beş tür iş ilişkisini birbirinden ayırıyor.

Çıkış-giriş iletişimi, yüksek seviyeli işin çıkış oku (bundan sonra sadece çıktı olarak anılacaktır) alt seviyenin girişine yönlendirildiğinde.

Kontrol iletişimi (çıkış-kontrol), daha yüksek seviyeli bir işlemin çıktısı alt seviyeyi kontrol etmek için gönderildiğinde. Yönetim iletişimi, üst düzey işlerin hakimiyetini gösterir. Üst düzey işin verileri veya çıktı nesneleri, alt düzey işte değiştirilmez.

Çıkış-giriş geri bildirimi, daha düşük seviyeli bir işin çıktısı daha yüksek seviyeli bir işin girişine gönderildiğinde. Böyle bir ilişki genellikle döngüleri tanımlamak için kullanılır.

Çıkış kontrolü geri bildirimi, daha düşük seviyeli bir işlemin çıktısı daha yüksek seviyeli bir işlemin kontrolüne gönderildiğinde. Yönetim geri bildirimi genellikle bir iş sürecinin etkinliğini gösterir.

Çıkış mekanizması bağlantısı, bir işin çıktısı diğerinin mekanizmasına gönderildiğinde. Bu ilişki diğerlerine göre daha az kullanılır ve bir faaliyetin başka bir faaliyeti gerçekleştirmek için gerekli kaynakları hazırladığını gösterir.

Açık oklar. Açık bir okun kaynağı olarak tek bir işi ve hedefi olarak tek bir işi vardır.

Dallanma ve birleştirme okları. Bir iş tarafından üretilen aynı veriler veya nesneler aynı anda birçok başka işte kullanılabilir. Öte yandan, farklı çalışmalarda oluşturulan oklar, aynı yerde kullanılan veya işlenen aynı veya homojen veri veya nesneleri temsil edebilir. IDEF0 bu gibi durumları modellemek için dallanma ve birleştirme oklarını kullanır. Bir oku dallandırmak için ok düzenleme modunda ok parçasına ve ilgili çalışma bölümüne tıklayın. İki çıkış okunu birleştirmek için, ok düzenleme modunda önce iş çıkış segmentine, ardından karşılık gelen ok parçasına tıklayın.

Dallanma ve birleştirme oklarının anlamı, okların her dalının adlandırılmasıyla aktarılır. Bu tür okları adlandırmanın belirli kuralları vardır. Örnek olarak dallanan okları kullanarak bunlara bakalım. Daldan önce bir ok adlandırılırsa ancak daldan sonra hiçbir dal adlandırılmazsa, her dalın, daldan önceki dalla aynı verileri veya nesneleri modellediği varsayılır.

Bir dalın önünde bir ok isimlendirilmişse ancak daldan sonra herhangi bir dal isimlendirilmemişse, bu dalların isme karşılık geldiği varsayılır. Daldan sonraki herhangi bir dal isimsiz kalırsa, daldan önceki dalla aynı verileri veya nesneleri modellediği varsayılır.

Okun daldan önce, daldan sonra da herhangi bir dalın adının verilmemesi kabul edilemez bir durumdur. BPwin böyle bir oku sözdizimi hatası olarak algılar.

Birleştirme oklarını adlandırma kuralları tamamen benzerdir - birleşmeden sonra adlandırılmayan ve dallarından herhangi biri birleşmeden önce adlandırılmayan bir ok hata olarak kabul edilecektir. Dallanma ve birleştirme oklarının ayrı bir dalını adlandırmak için diyagramda yalnızca bir dal seçin, ardından ad düzenleyiciyi çağırın ve oka bir ad atayın. Bu ad yalnızca seçilen dalla eşleşecektir.

Ok tüneli açma. Ayrıştırma diyagramına yeni eklenen sınır okları alt düzey köşeli parantez içinde gösterilir ve üst düzey diyagramda otomatik olarak görünmez.

Bunları en üste "sürüklemek" için önce araç paletindeki düğmeyi seçmeli ve kenarlık okunun köşeli parantezlerine tıklamalısınız. Bir diyalog belirir Kenar Oku Düzenleyicisi(Şekil 7).

Pirinç. 7. DiyalogKenar Oku Düzenleyicisi

Eğer düğmeye tıklarsanız çözmekSınırOk, ChangeToTunnel düğmesi kullanılırsa ok üst düzey diyagrama taşınır; ok tünellidir ve başka bir diyagramda sona ermez.

Tünel açma, önemsiz okları tasvir etmek için kullanılabilir. Herhangi bir alt düzey diyagramda, mevcut düzeyde işlenmeyen veya kullanılmayan önemsiz verileri veya nesneleri tasvir etmek gerekiyorsa, bunların daha yüksek bir düzeye (ana diyagrama) gönderilmesi gerekir. Bu veri ana grafikte kullanılmazsa daha da yükseğe gönderilmesi gerekir vs. Sonuç olarak her seviyede önemsiz bir ok çizilecek ve göründüğü tüm grafiklerin okunmasını zorlaştıracaktır. Çözüm, oku en alt seviyede tünellemektir. Bu tünellemeye "ana diyagramda olmayan" denir.

Ayrıştırma diyagramı oluşturma örneği

1. Araç paletinde ve iletişim kutusunda aşağı düğmesini seçin Etkinlik Kutusu Sayısı(Şekil 8) alt seviyedeki diyagramda - 3 - iş sayısını ayarlayın ve düğmeye tıklayın TAMAM.

Pirinç. 8. Etkinlik Kutusu Sayısı İletişim Kutusu

2. Otomatik olarak bir ayrıştırma diyagramı oluşturulacaktır (Şek. 9).

Pirinç. 9. Ayrışma diyagramı

Model düzenleme alanının sol üst köşesinde bulunan çalışmaya sağ tıklayın, içerik menüsündeki seçeneği seçin İsim ve işin adını girin. Kalan iki iş için işlemi tekrarlayın. Daha sonra Tablo 1'de gösterildiği gibi her çalışma için tanımı, durumu ve kaynağı girin.

Tablo 1. A0 ayrıştırma diyagramının çalışmaları

Ayrıştırma diyagramı Şekil 2'de gösterilen formu alacaktır. 10.

Şekil 10 Eserlere isim verildikten sonra ayrıştırma diyagramı

3. Diyagrama dahil edildikten sonra işlerin özelliklerini değiştirmek için işler sözlüğünü kullanabilirsiniz (Şek. 11). Sözlük ana menü öğesi kullanılarak çağrılır Sözlük/Etkinlik.

Pirinç. 11. SözlükEtkinlik Sözlüğü

Eğer eserin adını ve özelliklerini sözlükte açıklarsanız, daha sonra araç paletindeki bir düğmeyi kullanarak onu diyagrama ekleyebilirsiniz. Bir eserin herhangi bir diyagramda kullanılması halinde sözlükten çıkarılması mümkün değildir. Bir eser çizelgeden kaldırılırsa sözlükten de kaldırılmaz. Bu tür çalışmaların adı ve açıklaması daha sonra kullanılabilir. Sözlüğe eser eklemek için listenin sonuna gidin ve son satıra sağ tıklayın. İşin adını ve özelliklerini girmeniz gereken yeni bir satır belirir. Modelde kullanılmayan tüm iş adlarını silmek için ( Tasfiye(Temiz)).

4. Ok çizim moduna geçin ve Şekil 1'de gösterildiği gibi araç paletindeki düğmeyi kullanarak sınır oklarını bağlayın. 12.

Pirinç. 12. A0 diyagramındaki bağlı sınır okları

5. "Bilgisayarları oluşturma ve test etme" çalışmasının kontrol oku dalına sağ tıklayın ve onu "Oluşturma ve test etme kuralları" olarak yeniden adlandırın (Şekil 13). Yeni dal için bir tanım girin: "Derleme talimatları, test prosedürleri, performans kriterleri vb." “Satış ve Pazarlama” çalışma mekanizmasının ok dalına sağ tıklayın ve “Sipariş Sistemi” olarak yeniden adlandırın (Şekil 14).

Pirinç. 13. Ok "Kuralları oluştur ve test et"

Pirinç. 14. Ok "Sipariş sistemi"

6. Okların adlarını ve özelliklerini girmenin alternatif bir yöntemi, ok sözlüğünü kullanmaktır (sözlüğü çağırın - menü Sözlük/Ok). Okun adını ve özelliklerini sözlüğe girerseniz (Şekil 15), diyagrama daha sonra eklenebilir.

Pirinç. 15. Kelime okları

Ok herhangi bir diyagramda kullanılıyorsa sözlükten kaldırılamaz. Diyagramdan bir okun kaldırılması onu sözlükten kaldırmaz. Böyle bir okun adı ve açıklaması daha sonra kullanılabilir. Ok eklemek için listenin sonuna gidin ve son satıra sağ tıklayın. ortaya çıkar Yeni hat okun adını ve özelliklerini girmeniz gereken.

7. Şekil 2'de gösterildiği gibi yeni iç oklar oluşturun. 16.

Pirinç. 16. A0 diyagramının iç okları

8. Bir ok oluşturun geri bildirim(yönetim için) “Montaj ve test sonuçları”, “Bilgisayarların montajı ve test edilmesi” çalışmasından “Satış ve Pazarlama” çalışmasına geçiş. Gerekirse ok stilini (çizgi kalınlığı) değiştirin ve seçeneği ayarlayın Ekstra Ok Ucu(Ek Ok Ucu) (bağlam menüsünden). Yöntem sürükle bırak Okların adlarını daha kolay okunacak şekilde taşıyın. Gerekirse içerik menüsünden yükleyin Düzensiz çizgi(Zagogulin). Sonuç olası değişikliklerŞekil 2'de gösterilmiştir. 17.

Pirinç. 17. A0 diyagramındaki okların düzenlenmesinin sonucu

9. Satış ve Pazarlama işinden çıkan yeni bir Pazarlama Malzemeleri çıkış sınır oku oluşturun. Bu ok otomatik olarak üst düzey diyagramın içine girmez ve ucunda köşeli parantez bulunur (Şekil 18).

Pirinç. 18. Arrow Pazarlama materyalleri

10. Köşeli parantezlere sağ tıklayın ve menü öğesini seçin Ok Tüneli(Şekil 19).

İletişim kutusunda Kenar Oku Düzenleyicisi(Sınır Oku Düzenleyicisi) seçeneğini seçin Bunu Border Arrow'a çöz(Sınır Oku olarak izin verin) (Şek. 20).

Pirinç. 19. ParagrafMenüOk Tüneli

Pirinç. 20. DiyalogpencereKenar Oku Düzenleyicisi

Pazarlama Malzemeleri oku için seçeneği belirleyin Kırpma Bağlam menüsünden (Düzenle) öğesini seçin. Laboratuar çalışmasının sonucu Şekil 2'de gösterilmektedir. 21.

Pirinç. 21. Ayrışmanın sonucu

Bir resim bin kelime değerinde bir olup

Halk bilgeliği

Elbette teoride fonksiyonel modelşirketin işi yönetici tarafından yürütülmelidir ve bir deponun veya bir BT sisteminin (öncüden uygulamaya kadar) işini organize etmekten bahsettiğimizin bir önemi yoktur. Ancak gerçekte neredeyse hiçbir zaman öyle olmuyor ve bu nedenle, müşterinin sorununa çözüm bulma ve çalışma sürecinde, şirketin çalışmasının işlevsel bir modelini veya belirli bir süreci (işlev) kendi başıma da yaratıyorum.

Grafiklerin avantajları hakkında birkaç söz

Bildiğiniz gibi IDEF0 fonksiyonel modelleri her zaman grafik diyagramları. Kendine has özellikleri ve kompozisyon kuralları vardır. Bu konuyu biraz sonra konuşacağız. Şimdi grafiklerin etkinliğine dair birkaç örnek vermek istiyorum. Neden buna odaklanıyorum? Büyük olasılıkla, şirketin çalışmalarının işlevsel bir modeline duyulan ihtiyaç hakkındaki açıklamamdan sonra, birçok kişi tüm bunların gerekli olmadığını, şirkette şu veya bu işlevin nasıl çalıştığını kelimelerle açıklayabileceklerini düşündü. Bahsetmek istediğim şey bu.

Tarihe kısa bir geziyle başlayalım. Rus-Türk Savaşı sırasındaki uzak 1877 yılına geri dönelim. O zaman Sytin yazıcısı askeri operasyonları tanımlamak için grafikleri ilk kez kullandı. Artık tüm bunlar bize tanıdık geliyor, herhangi bir savaşı anlatırken gözümüzün önünde savaşın gidişatını açıkça gösteren oklu kartlar beliriyor. Ve o günlerde askeri eylemler kelimelerle anlatılırdı. Her savaş için çok ama çok kelime var. Ve sonunda ne olduğunu anlamak çok zordu.

Bu nedenle Sytin'in fikri gerçekten devrim niteliğindeydi; askeri birimlerin tahkimatlarını ve konumlarını gösteren haritaların litografik kopyalarını basmaya başladı. Bu kartlara “Gazete Okuyucuları İçin” adı verildi. Harçlık.” Fikir o kadar anlamlı çıktı ki "Avantajlar"ın ilk baskısı anında tükendi. Ve sonra bu tür uygulamalar büyük talep gördü. Sebebi açıktır. Grafikler, yalnızca kelimelerle anlaşılması neredeyse imkansız olan şeyleri anlamaya yardımcı oldu.

Sözlü betimlemelerin çaresizliğine benzer bir örneği kendi pratiğimden de verebilirim. Müşterilerimden biri benden, şirketi için bir ERM sisteminin uygulanmasını üstlenmemi istedi. Teknik özellikleri olup olmadığını sorduğumda ise şu cevabı aldım: “Evet var. Ama 400 sayfa.” Aynı zamanda müşteri, daha önce temasa geçtiği meslektaşlarımın ya projeyi tamamen reddetmelerinden ya da açıkça şişirilmiş fiyatlar teklif etmelerinden büyük şikayetçiydi. Bunu gördükten sonra başvuru şartları gerçekten 400 sayfa ve yalnızca şunlardan oluşuyor: metin açıklaması Geliştiricilerin davranışlarının nedenlerini anladım. Bu kadar hacimli bir metni okumak, derinlemesine incelemek, tüm nüansları anlamak, sadece görevi anlamak ve fiyatı adlandırmak gerçekten çok zor.

Bu müşteriye teklif ettim Alternatif seçenek- grafiksel olarak mümkün olan her şeyi notasyon şeklinde açıklayın. Ona modelleme örneklerini gösterdim. Sonuç olarak artık isteklerini ve teknik şartnamelerin tasarımını yeniden düşünüyorlar.

Ayrıca iş süreçlerinin grafiksel modellemesinin hem meslektaşlarıma, iş danışmanlarıma ve geliştiricilerime hem de iş adamlarına yardımcı olduğu birçok başka örnek de biliyorum.

Bu benim işim için neden önemli?

İşim her zaman mevcut sistemde değişiklik yapmayı içerir. Değişiklik yapmak ve istenen sonucu elde etmek için zaten var olanı incelemeniz gerekir. Ve tam olarak ne yaptığımız önemli değil; sıfırdan bir CRM sistemi kurmak veya kurmak, etkili bir ERP sistemi oluşturmak, entegrasyon yapmak çeşitli sistemler genel olarak işin otomasyonunu artırmak. Her durumda, önce bir fikir edinmeniz gerekir. mevcut şemaçalışın ve ancak bundan sonra bazı değişiklikler önerebilir ve sorunu çözmek için seçenekler üzerinde düşünebilirsiniz.

Ders çalıştıktan sonra Mevcut durum diğer üçüncü taraf uzmanlar gibi, mevcut duruma ilişkin vizyonumun yanı sıra görevi çözmek için yapılması gereken eylemleri mümkün olduğunca ayrıntılı olarak ortaya koyduğum ticari bir teklif oluşturuyorum ve elbette beklenen sonuç.

Bu tür iş anketi raporları hacimlidir ve birden fazla sayfa kaplar; bu bir yandan gerekli, diğer yandan algıyı karmaşıklaştırır. İlk başta, diğerleri gibi ben de hacimli raporların iyi olduğunu düşündüm, çünkü bir kişi iş için para ödüyor ve ona mümkün olduğunca ayrıntılı bilgi vermeniz gerekiyor.

Aslında hacim sağlamak değil, özü olabildiğince hızlı ve eksiksiz aktarmak önemlidir. Büyük hacimli metinler zaman gerektirir ve işadamları bu süreye genellikle çok az sahip olur. Grafikler de teklifimin hacmini azaltmamı ve çözümü net ve anlaşılır bir biçimde göstermemi sağlıyor. Sonuç olarak tekliflerim önemli ölçüde azaldı, içlerinde grafikler belirdi ve işbirliğini başlatma kararları daha hızlı alınmaya başlandı.

Bu yüzden görsel modeller kullanıyorum. Bildiğimiz gibi bir resim bin kelimeye bedeldir. İş süreçlerinin ve iş operasyonlarının modernleştirilmesine yönelik seçeneklerin açıklanması durumunda bu gerçekten doğrudur. Ve IDEF0 notasyonları buraya çok iyi uyuyor.

Ama önce temel kavramları anlayalım, notasyonlar nelerdir, neden ihtiyaç duyulur, IDEF0 nedir, bu yöntemin özellikleri ve avantajları nelerdir

İş süreci açıklama gösterimi nedir?

Gösterim, modellemede kullanılan bir dizi grafik nesnenin yanı sıra modelleme kuralları olan bir iş sürecini tanımlamak için kullanılan bir formattır.

Aslında gösterimler, bir şirketin çalışmalarını tanımlamanıza ve farklı departmanlar arasındaki etkileşimi net bir şekilde göstermenize olanak tanıyan özel bir grafik dilidir; iş süreçlerini tanımlar. Gösterimler süreç veya fonksiyonel modelleme için kullanılabilir.

Genel olarak notasyonlara iş analizi için bir programlama dili denilebilir.

IDEF0 nedir?

IDEF0, iş süreçlerini resmileştirmek ve tanımlamak için tasarlanmış işlevsel bir modelleme metodolojisi ve grafik gösterimidir. Ayırt edici özellik IDEF0, nesnelerin ikincilleştirilmesine vurgu yapıyor. IDEF0, işler arasındaki zamansal sıra (iş akışı) yerine mantıksal ilişkileri dikkate alır. Vikipedi

IDEF0 standardı 1981 yılında ABD'de Hava Kuvvetleri Bakanlığı tarafından otomasyon amacıyla geliştirilmiştir. endüstriyel Girişimcilik. Yazılım geliştirme sürecinde geliştiriciler iş süreçlerini analiz etmek için yeni yöntemler geliştirme ihtiyacıyla karşı karşıya kaldılar. Sonuç, analiz için özel IDEF0 gösterimlerini kullanan IDEF0 fonksiyonel modelleme metodolojisidir.

Şirketin fonksiyonel modeli

IDEF0 işlevsel modeli, her biri giriş ve çıkışları, kontrolleri ve ayrıntılı (ayrıştırılmış) mekanizmaları içeren bir “kara kutu” olan bir bloklar kümesidir. gereken seviye. En önemli işlev sol üst köşede bulunur. Fonksiyonlar, oklar ve fonksiyonel blokların açıklamaları kullanılarak birbirine bağlanır. Üstelik her ok veya aktivite türünün özdeğer. Bu model, hem idari hem de organizasyonel tüm ana süreç türlerini tanımlamanıza olanak tanır.

Oklar şunlar olabilir:

• Gelen – belirli bir görevi belirleyen giriş.
• Giden – faaliyet sonucunun çıktısı.
• Yöneticiler (yukarıdan aşağıya) – kontrol mekanizmaları (hükümler, talimatlar vb.).
• Mekanizmalar (aşağıdan yukarıya) - gerekli işi gerçekleştirmek için kullanılanlar.

İngilizce'de sırasıyla Giriş ve Çıkış olarak adlandırıldığı için gelen ve giden okları gelen ve giden oklar olarak adlandırmak daha doğru olacaktır. Ancak çevirinin özellikleri ve alışılmış isimler zaten olduğu gibi görünüyor. Ancak yine de terimlerin doğru anlaşılması için anlamlarını hatırlamak önemlidir. bu durumda. Bu aynı zamanda bu gösterimin öncelikle yazılım geliştirme için oluşturulmuş olması ve terimleri bu açıdan tercüme etmenin daha doğru olmasıyla da doğrulanmaktadır.

Oklar isimler (deneyim, plan, kurallar) kullanılarak imzalanır ve bloklar fiiller kullanılarak imzalanır; gerçekleştirilen eylemleri açıklarlar (bir ürün yaratmak, bir anlaşma yapmak, sevkiyat yapmak).

IDEF0, iş süreçlerini açıklamaya yönelik oldukça basit ve aynı zamanda görsel bir dildir. Bu standardı kullanarak geliştiriciler, danışmanlar ve kullanıcılar arasında bilgi aktarımı mümkündür. Standart çok dikkatli bir şekilde geliştirildi, tasarıma uygun ve evrenseldir. Bununla çalışmak için VISIO, BPWIN, ERWIN, Bussines studio vb. gibi birçok araç vardır.

Ayrıca iş modelleri oluşturmak için IDEF0'ı kullanmak hem kullanışlı hem de doğrudur. Bu araç, iş analitiği için tasarlanmış olup, kapsamlı ve ayrıntılı hata ayıklama ve iyileştirme işlemlerinden geçmiştir. Bu nedenle IDEF0 kullanarak hatasız işlevsel bir model oluşturmak, bu standardı kullanmadan çok daha kolaydır.

Bildiğiniz gibi çivileri çekiçle çakmak en iyisidir. Elbette bunun için başka aletler de kullanabilirsiniz, ancak çekiç en işlevsel ve çiviyi doğru ve doğru bir şekilde çakmanın en kolay yoludur. IDEF0 kullanımında da durum böyledir - bu araç fonksiyonel modelleme için oluşturulmuştur ve onun yardımıyla istenen sonucu çok daha hızlı ve daha doğru bir şekilde elde edebilirsiniz.

İşlevsel bir model IDEF0 oluşturma örneği

Fonksiyonel modelleme ile nasıl çalışılacağını anlamak için makale yazma sürecine bir örnek vereceğim.

Ana blok “Bir makale yaz”dır.

Gelen oklar – “Deneyim”, “Üçüncü taraf kaynaklardan gelen bilgiler”. Bunlar başlamak için ihtiyacınız olan giriş notlarıdır.

Makale yazma kuralları “Yayın Planı”, “Yayıncının Gereksinimleri”, “Rus Dili Kuralları” dır.

Ve “Mekanizmaların” rolü yazar, metin yazarı, redaktör ve yazılım. Bu durumda yazar, makaleye yansıtılması gereken tüm düşünce ve fikirleri topladığı sesli materyal oluşturur. Metin yazarı, yayıncının gereksinimlerine, yayın planına ve Rus dilinin kurallarına göre bu materyale dayanarak yaratan kişidir; hazır metin nesne. Düzeltici materyali hatalara karşı kontrol eder. Yazılım ise süreçteki tüm katılımcıların çalışmalarında kullandıkları araçlardır.

Böylece sürecin temel parametrelerini, girdisini, çıktısını ve sürecin başarılı bir şekilde uygulanması için gerekli olan her şeyi belirliyorum. Ancak bu sürecin yalnızca temel çerçevesidir. Bu, bir bütün olarak şirketin genel planını açıklar.

Aslında herhangi bir iş süreci gibi bir makale oluşturma süreci de ayrıntılı olabilir ve ayrıntılı olmalıdır. Bunu yapmak için genel "makale yaz" bloğunu ilgili öğelere ayırıyorum.

Bizim durumumuzda iş 4 ana aşamaya ayrılmıştır:

1. Sesi hazırlayın.
2. Metni hazırla
3. Metni yayına hazırlayın.
4. Bir yayına makale gönderin.

Diyagram, hangi aşamada hangi kontrol elemanlarının ve hangi mekanizmaların devreye girdiğini açıkça göstermektedir.

Böylece yazar, ses oluştururken bilgi ve deneyimini yayın planına ve yayıncının gereksinimlerine göre yönlendirerek kullanır. Metin yazarı, girdi olarak bir ses kaydı alır ve bu kayıttan, Rus dilinin kurallarına göre bir metin oluşturur. Düzeltici metni alır ve Rus dilinin kurallarına göre kontrol eder. Bir yayında makale yayınlamak için özel bir yazılıma ihtiyaç vardır.

İşlevsel bir model oluştururken temel parametreler amaç ve bakış açısıdır. Bunlara dayanarak aynı süreçlerin modellenmesi biraz farklı görünebilir. Mesela benim durumumda amaç “makale yazma süreci hakkında konuşmak”. Metin yazarının bakış açısı ise “süreç yöneticisinin bakış açısından makale yazıp yayınlamaktır.”

Yani aynı süreç bir metin yazarının bakış açısından anlatılsaydı, o zaman girdi deneyim ve yazarın ses dosyası olurdu. Üstelik bu durumda Deneyim, bir yöneticinin veya yazarın değil, bir metin yazarının deneyimi anlamına gelecektir. Bu nedenle iş süreci modeli oluştururken belirlenmesi gereken ilk şey, bir bakış açısı seçmek ve hedefi net bir şekilde formüle etmektir.

Bu tür bir modelleme sadece görsel değil, aynı zamanda etkili yönetim kararları almak için de çok uygundur. Örneğin, yukarıda açıklanan iş sürecinde iki ayrı uzman vardır - bir metin yazarı ve bir redaktör. Bir projenin finansmanını optimize etme görevini belirlersem, diyagram sayesinde bunun nerede yapılabileceğini ve nasıl yapılabileceğini hemen göreceğim. Yani, bir metin yazarı ve düzeltmen yaklaşık olarak aynı kuralları kullanır, ancak metin yazarı sesi alır ve sonucu metin biçiminde üretir; düzeltmen ise metni hem alır hem de iletir. Bu nedenle gerekirse, redaktörlük görevlerini bir metin yazarına yarı fiyatına teklif edebilirim. Bu şekilde farklı uzmanlar arasındaki etkileşimde paradan ve zamandan tasarruf edeceğim. Elbette düzeltmenlerin tüm erdemlerini ve bireysel uzmanlarla çalışmanın neden daha iyi olduğunu anlıyorum. Ancak size bir görevim olduğunu hatırlatırım: maliyet optimizasyonu.

Böyle bir görsel araç olmadan hangi blokların kaldırılabileceğini belirlemek ve dolayısıyla işi optimize etmek daha zor olacaktır.

IDEF0 Gösterimleri Nasıl Oluşturulur

Birçok farklı var yazılım ürünleri, notasyonlar oluştururken kullanılabilir. Bazıları özellikle işlevsel modelleme için yaratılmış, diğerleri ise grafik öğelerle yapılan herhangi bir çalışma için tasarlanmıştır. Bu modelleri nerede ve nasıl yapacağınız size kalmış.

Şahsen ben, ilk aşamada, hata durumunda düzeltmeler yapmak için düz kağıt, basit bir kalem ve silgiden daha iyi bir şeyin olmadığını düşünüyorum.

Mevcut iş süreçlerinin bir gösterimini oluşturmak için, ör. Şirketin şu anda nasıl çalıştığını açıklamak için çalışma prensiplerini incelemek gerekir. Üçüncü taraf bir uzman (danışman, geliştirici) bu amaçla bir görüşme gerçekleştirir. İlk aşamada şirket başkanı soruları yanıtlıyor, ardından notasyonun detaylandırılması sürecinde işin çeşitli aşamalarından sorumlu çalışanlarla görüşmeler yapılıyor.

Sonuç olarak 2 notasyonun gerekli olacağını anlamak önemlidir. İlki, iş süreçlerini "olduğu gibi" biçimde görüntüleyecektir. Bunu görüşmelere dayanarak oluşturuyorsunuz ve her detayı şirket çalışanları ve yöneticiyle koordine ediyorsunuz. Mevcut süreçlere ilişkin vizyonunuzun gerçeklikle örtüşmesi çok önemlidir; tam da bu nedenle her düzeyde onay gereklidir.

İkinci gösterim “olması gerektiği gibi”dir. Verilen görevi tamamlama çerçevesinde şirketin çalışmalarını optimize etmek ve otomatikleştirmek için iş yapısında yapmayı önerdiğiniz ilk ve değişiklikler temelinde oluşturulur.

IDEF0 standart gereksinimleri

Prensip olarak yukarıda IDEF0 standardının temel gereksinimlerini anlattım ve örnekle gösterdim.

1. Ana öğe her zaman sol üst köşededir.
2. Tüm öğelerin gelen ve giden okları olmalıdır, çünkü yürütme için girişte bir şey (bir sipariş, bir görev) almak gerekir ve çıktıda işlendikten sonra bitmiş ürünü aktarmak gerekir. Gelen oklar daima solda, giden oklar ise daima sağdadır.
3. Yukarıda kontrol elemanları, aşağıda ise süreci tamamlamak için gerekli mekanizmalar yer almaktadır.
4. Bir sayfada (ekranda) birkaç blok varsa, sonraki her blok bir öncekinin sağında ve altında bulunur.
5. Okların kesişimini gerekli minimum seviyeye indirecek şekilde diyagramlar oluşturmaya çalışmak gerekir.

Yaygın hatalar

Fonksiyonel modelleme, modelleme amaçlı olmayanlar da dahil olmak üzere çeşitli araçlar kullanılarak gerçekleştirilir. İkinci durumda, hata denetimi ve standart kısıtlama yoktur. Görünürlüğü artırma arzusu ve deneyim eksikliği çoğu zaman hatalarla sonuçlanır.

Farklı renkler kullanma

Diyagramdaki tüm öğeler eşit derecede önemlidir. Fonksiyonel modellemede daha fazla veya daha az yoktur. önemli unsurlar. Herhangi birinin ortadan kaybolması, sürecin aksamasına ve üretim hatalarına yol açacaktır.

Kullanıcılar genellikle kağıt üzerinde veya çeşitli programlarda modelleme yaparken farklı renkler kullanarak görünürlüğü artırmaya çalışırlar. Bu en yaygın hatalardan biridir. Aslında, çok renkli okların ve blokların kullanılması yalnızca daha fazla kafa karışıklığı yaratır ve aynı zamanda diyagramın algısını da bozar.

Modeliniz herhangi bir ek renk şeması olmadan siyah beyaz olarak okunabilir olmalıdır. Bu yaklaşım aynı zamanda yanlış anlaşılmaların önlenmesine yardımcı olur ve model yaratıcısını disipline eder, böylece modelin okunabilirliği ve okuryazarlığı artar.

Çok fazla blok

Bir model hazırlarken, genellikle şirketin çalışmalarının tüm nüanslarını tüm ayrıntılarıyla birlikte tek bir sayfada göstermeye çalışırlar. Sonuç çok fazla sayıda bloktur. büyük miktar okları kontrol edin. Bu durumda okunabilirlik kaybolur.

En iyi seçenek, sorunu anlamaya yetecek kadar ayrıntıdır, başka bir şey değil. Belirli bir sürecin ayrıntılı görünümü seçildiğinde, her departmanın ve hatta çalışanın çalışmalarının ayrıntılı ayrıntıları ortaya çıkarılabilir. Ve böyle bir yapı ancak iş veya karar verme için gerçekten gerekliyse yaratılır.

Ayarlamalar yapılırken yapının ihlali

Gelen, giden veya diğer önemli unsurlar olmadan herhangi bir karışıklık veya işlem olmadığından emin olun. Örneğin yukarıdaki örnekte bakış açısını metin yazarına kaydırmayı gerekli görürsem yazarı diyagramdan çıkaracağım. Ve sonra kontrol unsurları “yazarın deneyimi ve Üçüncü Taraf Kaynaklar” yanı sıra yayın planı da gereksiz hale geliyor. Sonuçta yazar bunları kullanıyor. Bir metin yazarı bir ses dosyasıyla çalışır. Ve eğer genel şemada kalırlarsa, detaylandırıldıklarında belirsiz bir yöne gidecekler ve kafa karışıklığına neden olacaklar.

Benzer şekilde, eğer bir blok eklemeye karar verirsem, onun da gerekli tüm özelliklere sahip olduğundan emin olmak önemlidir. Karmaşık iş süreçlerini modellerken modelin bir bölümündeki değişiklik diğerinde de değişikliğe yol açabileceğinden burada dikkatli olmak çok önemlidir. Kesinlikle dahil edilmeleri gerekiyor.

Kontrol elemanlarını ve blokları adlandırma kuralları

Basit bir kuralı hatırlamak önemlidir: kontrol oklarına isim, bloklara fiil denir. Bu, IDEF0 standardında kabul edilmektedir ve bu yaklaşım, kafa karışıklığının ve hataların önlenmesine yardımcı olmaktadır.

Çoğu zaman blokları adlandırırken hatalar yapılır. Örneğin, "Makale oluştur" yerine "Makale oluştur" yazıyorlar. Bu yaklaşımdaki bloklar eylemlerdir ve bu nedenle her zaman fiiller olmalıdırlar.

IDEF0 kullanmanın faydaları

• İlk fayda açıktır: görünürlük.Şu veya bu sistemin nasıl çalıştığını kendiniz anlamaya başlıyorsunuz ve ayrıca bu sistemdeki "ince noktaların" nerede olduğunu ve çözümlerinizin onlardan kurtulmaya nasıl yardımcı olacağını da açıkça açıklayabilirsiniz.
• Karşılıklı anlayış ve tutarsızlıkların olmaması. Fonksiyonel bir model kullanarak bir şirketin çalışmalarını tartışırken, kontrol unsurları içeren görsel ve sezgisel görev bloklarına sahipsiniz. Buna ek olarak, fonksiyonel modelleme, gerekirse, durumu ortaya koyan bir sözlük oluşturmayı da içerir. semboller ve şartlar. Sonuç olarak siz ve müşteriniz, yöneticiniz ve diğer çalışanlar bir sorunu tartışırken aynı dili konuşursunuz.
• Sadelik ve yüksek hız bir model oluşturmak. Modellemeyi öğrenmek elbette göründüğü kadar kolay değildir. Sonuçta, bir diyagram özünde bilginin süper yoğun bir sunumudur ve anlaşılması çok iyidir, ancak böyle bir sunumun uygulanması özel bir yaklaşım gerektirir. Bu durumda analistin beyni bir yandan çok güçlü bir baskı, diğer yandan da filtre görevi görür. Ancak deneyim kazandıkça bu süreç çok hızlı hale gelir. Sonuç olarak, belirli bir sistemde neler olup bittiğini kendi başınıza anlamanıza yardımcı olacak ve kısa sürede oluşturulan görsel bir yardımı kullanarak, önemli noktalar iş arkadaşları veya müşteriler.
• Disiplin ve hata yok. IDEF0 standardı katı çerçeveler ve kurallar sağlar. Bu yaklaşım disiplin yaratır ve standart dahilinde hareket etme alışkanlığı dikkatsizlikten kaynaklanan hataların önlenmesine yardımcı olur. Standardın herhangi bir ihlali anında fark edilir hale gelir.

IDEF0'ı kullanmanın zorluğu nedir?

Bunu yalnızca en çok anlamak önemlidir. basit vakalar iki iş analisti, şirketin çalışmalarını tanımlamak için tamamen aynı işlevsel modelleri oluşturacaktır. Herhangi bir model, analistin deneyiminin, tanımlamaya çalıştığı işe ilişkin anlayış derinliğinin ve ayrıca bir şekilde bu işe ilişkin kişisel bakış açısının bir yansımasıdır. Onlar. kişi, sanki yöneticiymiş gibi, yöneticinin bakış açısından bir iş modeli geliştirir.

Aynı zamanda iş analistinin tam olarak bir meslek olmadığına inanıyorum; işi analiz eden ve en iyiyi kurmaya çalışan her işletme yöneticisi veya bazı sistemlerin geliştiricisi. etkili sistem. IDEF0 aracı bu insanlar ve bu amaçlar için tasarlanmıştır.

Bu nedenle işlevsel bir "olduğu gibi" iş modeli hazırlarken, ayrıştırma aşamalarında otomatik olarak hatalara yol açacak hatalar yapmamak için şirket başkanına sürekli danışmak çok önemlidir. Ayrıca ilerleyen aşamalarda bölüm başkanları ve çalışanlardan ek onaylar da gerekebilecek. Yalnızca "olduğu gibi" işlevsel modeliniz gerçek durumu gerçekten yansıtıyorsa herhangi bir değişiklik ve öneride bulunabilirsiniz. Ve bu tür çalışmalarda yüksek kaliteli sonuçlar elde etmek için her şeyden önce gereklidir: pratik tecrübe ve belirli bir iş türünün özelliklerine ilişkin bilgi.

Rusya Federasyonu Eğitim ve Bilim Bakanlığı

Federal Eğitim Ajansı

Durum Eğitim kurumu yüksek mesleki eğitim

Ders çalışması

"Sistem Modelleme"

“IDEF0, DFD ve IDEF3 tasarım metodolojilerini kullanarak sera işletme modelinin geliştirilmesi”

1. İşin amacı

2. Teorik giriş

3. Konu alanının açıklaması

4. BPwin'in Açıklaması

4.1 IDEF0 modelini oluşturma ilkesi

4.2 DFD modeli oluşturma ilkesi

4.3 IDEF3 modelini oluşturma ilkesi

5. Simülasyon

5.1 Sera modeli

5.2 Matematiksel model

6. Karşılaştırmalı analiz

6.1 Metodolojiler

6.2 Araçların karşılaştırılması

Edebiyat

1. İşin amacı

Bu kurs çalışmasının amaçları şunlardı:

işletmenin proje öncesi araştırma yöntemlerinin uygulanması;

elde edilen malzemelerin sonraki modelleme için analizi;

IDEF0 standardında bir süreç modelinin geliştirilmesi;

DFD standardında belge akışı ve bilgi işlemenin açıklaması;

IDEF3 standardındaki süreçlerin açıklamaları;

IDEFO, DFD ve IDEF3 standartlarına dayalı karma süreç tanımlama modelinin geliştirilmesi.

kurumsal operasyon senaryolarının oluşturulması;

yapı blok şeması işletmeler;

Bu işletmenin matematiksel modelinin oluşturulması.

Karşılaştırmalı analiz

2. Teorik giriş

Geliştirme sırasında otomatik sistemler kodlama ve test aşamalarında yönetim, çok sayıda hata tespit edilir ve bunların düzeltilmesi, geliştirilmekte olan tüm sistemde temel bir değişiklik gerektirir. Oluşturulan projelerin modellenmesi ve derin, detaylı analizi sırasında bu tür hatalar dikkate alınır. Modelleme, projeyi geliştirme sürecinde "görmenize" ve başlangıç ​​koşullarına bağlı olarak sistemin davranışını analiz etmek için önkoşullar oluşturmanıza olanak tanır.

Simüle edilmiş kontrol sisteminde meydana gelen süreçleri uygun şekilde koordine etmek için bir yapı oluşturmak gerekir; süreçleri kolaylaştırın. İşin simülasyonu bilgi sistemiözellikle yaratılışının ilk aşamalarında önemlidir. Bu aşamada yapılan hataları düzeltmek en pahalısı olduğundan problem analizi ve geliştirme aşamasında da faydalıdır. mantıksal modelçözümü önemlidir.

Bu bakımdan seracılık işi gibi bir konu alanının çalışılması ve geliştirilmesi gerekmektedir. Bunu yapmak için, bu alanın terminolojisini anlamanız, gerekli düzenleyici ve yasal belgeleri toplamanız, bu işletmenin belge örneklerini incelemeniz ve bunların hem kuruluş içindeki hem de dışındaki hareketlerini takip etmeniz gerekir.

Geliştirmenin bir sonraki aşaması tasarım aşamasıdır. Tasarım ve uygulamaya başlamadan önce doğru ve detaylı anlayış için gereksinimler yüksek seviye. Ayrıca sistemi formüle etmek için girdi olarak kullanılabilecek bir gereksinim yapısına sahip olmak oldukça faydalıdır. Bütün bunlar analiz ve modelleme yoluyla elde edilir.

Modelleme ve tasarım aşamalarında yapılan çalışma sürecinde, uygulanması için yeterli bilgiyi içeren bir sistem tasarımının elde edilmesi gerekmektedir. Ayrıca seranın çalışmasını analiz etmek de gereklidir; bunun sonucunda her bölümün iş yükünün derecesi, ilk etapta neyin otomatikleştirilmesi gerektiği ve hangi yollarla değerlendirilebilir.

Proje geliştirirken modellemenin ana hedefleri şunlardır:

işletmenin faaliyetlerinin ve içinde benimsenen teknolojilerin, gösterimlerinin netliğini ve eksiksizliğini sağlayan bir diyagramlar hiyerarşisi biçiminde sunulması;

analize dayalı olarak organizasyonel ve yönetimsel yapının yeniden düzenlenmesine yönelik tekliflerin oluşturulması;

kuruluş içindeki bilgi akışlarını (belge akışı dahil) kolaylaştırmak;

kurumsal bilgi sistemleri için gereksinimlerin analizi ve spesifikasyonların tasarımı.

3. Konu alanının açıklaması

Bu ders çalışmasında dikkate alınmak üzere bir sera çiftliği çalışması esas alınmıştır. Bu kuruluş mahsul yetiştirme konusunda uzmanlaşmıştır. Müşterinin talebi doğrultusunda ürün satışı yapılmaktadır.

İşin organizasyonu aşağıdaki şemaya göre gerçekleştirilir:

Bu diyagram işletmenin departmanlarını, işlevlerini ve ilişkilerini gösterir. Bazı departmanlar otomatikleştirilebilir.

Tüm işletmenin başında, şef ve yardımcısı tarafından temsil edilen yönetim vardır. Ana işlevleri işletmenin faaliyetlerini kontrol etmektir.

Ana işlevi personel eğitimi olan İş Sağlığı ve Güvenliği Hizmeti;

Muhasebe departmanı belge akışıyla ilgilenir;

Üretim kontrol hizmeti, üretimin her aşamasında tam kontrol sağlar;

Sektör Bakım, onarım işiyle uğraşmaktadır.

Bu işletmenin departmanları, hizmetleri ve işyerleri 1 numaralı tabloda sunulmaktadır:

1 numaralı masa

Seramızın görev ve fonksiyonları tablo 2'de gösterilmektedir:

Tablo No.2

Dokümantasyon 3 numaralı tablolarda sunulmaktadır:

3 numaralı masa

Kuruluşların dizini 4 numaralı tabloda sunulmaktadır:

4 numaralı masa

Aşağıda, işletmenin senaryosunu her aşama için ilgili sonuçlarla birlikte açıklayan bir şema yer almaktadır: Müşteriden, belirli sera ürünlerinin satış müdürüne tedariki için bir talep alınır. Satış elemanı bu talebi işleme alır ve bir karar verir. Buna paralel olarak muhasebeci hizmet sağlamanın maliyetini hesaplar. Tüm bu adımlar tamamlandıktan sonra sözleşme süreci başlar. Satış müdürü sözleşmenin şartlarını müşteriyle tartışır ve sonuçlandırır. Bundan sonra müşteri ödeme yapar. Ödemenin kontrolü muhasebe departmanının sorumluluğundadır. Muhasebeci bir banka ekstresi alır ve emri uygulamaya başlamak için teknoloji uzmanına gönderilen bir emir oluşturur. Teknolog da bir plan hazırlar - gerçekleştirilecek bir çalışma programı ve gerekli fonların kayıtlarını tutar. Bir plan - bir çalışma programı hazırladıktan sonra, bahçıvana arazi işi yapması için bir emir verilir. Bahçıvan arazi işini yapar ve hasadı toplar. Hasat edilen ürün müşteriye gönderilir. Tüm üretim döngüsü boyunca işletmenin başkanı, satış müdürü, muhasebeci ve teknoloji uzmanının faaliyetleri hakkında raporlar alır. Patron, işletmenin tüm faaliyet sürecini kontrol eder ve gerekirse üretim sürecini ve tüm işletmenin çalışmasını bir bütün olarak iyileştirmek için personelinin çalışmaları hakkında yorumlarda bulunur.

Kurumsal operasyonun senaryo diyagramı

4. BPwin'in Açıklaması

BPwin, çeşitli model ve yöntemleri destekleyen küçük, entegre bir modelleme aracıdır.

Logic Works, iş süreçlerini analiz etmek ve yeniden düzenlemek için IDEF0 (işlevsel model), IDEF3 (İş Akışı Şeması) ve DFD (Veri Akışı Şeması) metodolojilerini destekleyen üst düzey bir CASE aracı olan BPwin'i sunar. Üç metodolojinin anası IDEF0'dır. BPwin oldukça basit ve sezgisel bir yapıya sahiptir net arayüz analistin oluşturmasına olanak tanıyan kullanıcı karmaşık modeller minimum çabayla.

BPwin, geliştirme modellerinin oluşturulmasıyla ilgili görevleri otomatikleştirerek sonuçların doğruluğunu ve tutarlılığını sağlamak için gereken anlamsal titizliği sağlar. Bu, BPwin'de şu metodolojiler kullanılarak elde edilir: IDEF0, DFD ve IDEF3.

Ancak bu daha karmaşık görevi ele almadan önce, işin tüm unsurlarını en azından "yeniden hesaplamak", yani şirketin organizasyon yapısını oluşturmak gerçekten gereklidir. Bir sonraki adım, arasındaki ilişkileri grafiksel olarak tasvir etmeye çalışmaktır. çeşitli unsurlar Daha önce tanımlanmış yapı.

BPwin'de karma modeller oluşturmak mümkündür; yani model aynı anda hem IDEFO hem de IDEF3 ve DFD diyagramlarını içerebilir. BPwin'de bir model, her biri belirli bir veri seti ile çalışan bir dizi eser olarak kabul edilir. Çalışma dikdörtgenlerle, veriler ise oklarla gösterilir.

Tüm model çalışmaları numaralandırılmıştır. Sayı bir önek ve bir sayıdan oluşur. Herhangi bir uzunlukta bir önek kullanılabilir, ancak genellikle A öneki kullanılır.Ağacın bağlam (kök) çalışması A0 olarak numaralandırılır. A0 ayrıştırma işinde Al, A2, A3 vb. sayılar bulunur. Alt düzey ayrıştırma işinde ana işin numarası ve bir sonraki seri numarası bulunur; örneğin ayrıştırma işi A3, A3.1 A3.2, AZ.Z, A3.4 vb. numaralara sahip olacaktır.

IDEFO diyagramlarının DFD ve IDEF3 diyagramları ile desteklenmesi sonucunda karma bir model oluşturulabilmektedir. en iyi yol işletmenin faaliyetlerinin tüm yönlerini açıklar. Karma model çalışmasının hiyerarşisi Model Gezgini penceresinde görülebilir. IDEFO notasyonunda eserler tasvir edilmiştir yeşil, DFD – mavi.

BPwin ve yerel entegre sistemler, küçük, orta ve büyük yönetim sistemleri oluşturmak için az çok gerekli olan kapsamlı bir sistem analizinin yapılmasına pratikte izin vermez. Onların yardımıyla, bireysel iş zincirlerini otomatikleştirmek için tasarlanmış, yani işletmenin kapsamlı bir analizine gerek olmadığında yerel IS veya küçük alt sistemler geliştirebilirsiniz. Küçük entegre araçların tipik bir kullanım alanı, bir işletmenin "parçalı" otomasyonu olarak adlandırılan sorunların çözülmesidir.

4.1 IDEFO modelini oluşturma ilkesi

IDEFO metodolojisinin temeli, iş süreçlerini açıklamaya yönelik bir grafik dilidir. IDEFO gösterimindeki bir model, hiyerarşik olarak sıralanmış ve birbirine bağlı diyagramların bir koleksiyonudur. Her diyagram sistemin bir açıklama birimidir ve ayrı bir sayfada bulunur.

IDEFO modeli, tek bir modelleme konusunun ve tek bir bakış açısının açıkça formüle edilmiş bir hedefinin varlığını varsayar.

Model dört tür diyagram içerebilir:

bağlam diyagramı (her model yalnızca bir bağlam diyagramına sahip olabilir);

ayrışma diyagramları;

düğüm ağacı diyagramları;

yalnızca pozlama (FEO) çizelgeleri.

Bağlam diyagramı en üsttedir ağaç yapısı Diyagramlar ve sistemin en genel tanımını ve dış çevre ile etkileşimini temsil eder.

Bu sürece fonksiyonel ayrıştırma adı verilir ve her bir parçayı ve parçaların etkileşimini açıklayan diyagramlara da ayrıştırma diyagramları denir.

IDEF0 notasyonu ve metodolojisi “blok” kavramına, yani belirli bir iş fonksiyonunu ifade eden dikdörtgene dayanmaktadır. Bildiğiniz gibi dikdörtgenin dört kenarı vardır. IDEF0'da tüm tarafların rolleri (işlevsel anlamları) farklıdır:

üst taraf "kontrol" anlamına gelir;

sol - “giriş”;

sağ - “çıkış”;

alttaki ise “mekanizmadır”.

Metodolojinin ve gösterimin ikinci öğesi "akış"tır (standartta "arayüz yayı" olarak adlandırılır) - verileri, resmi olmayan kontrolü veya blok tarafından gösterilen işlevi "etkileyen" herhangi bir şeyi tanımlayan öğe. Akışın bloğun hangi tarafına yönlendirildiğine bağlı olarak buna göre “giriş”, “çıkış”, “kontrol” denir.

"Akış"ı temsil eden figüratif unsur bir oktur.

Yönetim, büronun faaliyetlerini kontrol eden şeydir; geliştirilmekte olan bu modelde bunlar, bireysel ÜB'ye ilişkin yasalardır.

“Giriş” okları giriş verilerinin işlevlerini tanıtmaktadır; bağlam şemasında bunlar çalışanın kişisel verileridir.

"Çıkış" okları - çıktı verileri. Bağlam diyagramında bunlar, Rusya Federasyonu Emeklilik Fonuna sunulan çeşitli bilgilerdir.

“Mekanizma”nın oku süreçleri etkileyen verilerdir. Diyagramda bunlar personel ve PC'lerdir.

Bağlam diyagramının ayrıştırılmasından sonra, sistemin her büyük parçası daha küçük parçalara ayrıştırılır, her parçaya bir ad verilir ve bu şekilde, istenen düzeyde açıklama ayrıntısı elde edilene kadar devam edilir.

Her ayrıştırma oturumundan sonra inceleme oturumları gerçekleştirilir; konunun uzmanları, gerçek iş süreçlerinin oluşturulan diyagramlara uygunluğunu belirtir.

Bulunan tutarsızlıklar düzeltilir ve ancak incelemeyi herhangi bir yorum yapmadan geçtikten sonra bir sonraki ayrıştırma oturumu başlayabilir. Uyum bu şekilde sağlanır.

Diyagramdaki tüm kesişme noktaları numaralandırılmıştır, her numaranın bir J öneki vardır. Tanım Düzenleyici iletişim kutusunu kullanarak kesişimin özelliklerini düzenleyebilirsiniz.

4.2 DFD modeli oluşturma ilkesi

Veri akış diyagramları (DFD'ler), tasarlanmakta olan bir sistemin işlevsel gereksinimlerini modellemenin birincil yoludur. Onların yardımıyla bu gereksinimler işlevsel bileşenlere (süreçlere) bölünür ve veri akışlarıyla birbirine bağlanan bir ağ olarak sunulur. ana amaç Bu tür araçlar, her bir sürecin girdilerini çıktılara nasıl dönüştürdüğünü göstermenin yanı sıra bu süreçler arasındaki ilişkileri tanımlamaya yöneliktir.

DFD'leri temsil etmek için geleneksel olarak iki farklı gösterim kullanılır: Yourdon ve Gane-Sarson. Ayrıca örnekleri oluştururken Yodan notasyonu kullanılacak, tüm istisnalar önceden belirtilecektir.

Bu metodoloji (Gane/Sarson metodolojisi), analiz edilen - tasarlanmış veya fiilen mevcut olan - bir IS modelinin oluşturulmasına dayanmaktadır. Metodolojiye uygun olarak sistem modeli, bilginin sisteme girişinden kullanıcıya teslimine kadar dönüştürülmesinin eş zamanlı olmayan sürecini açıklayan bir veri akış diyagramları hiyerarşisi (DFD veya DFD) olarak tanımlanır. Diyagramlar üst seviyeler hiyerarşiler (bağlam diyagramları), bir IS'nin ana süreçlerini veya alt sistemlerini harici girdiler ve çıktılarla tanımlar. Daha düşük seviyeli diyagramlar kullanılarak detaylandırılmışlardır. Bu ayrıştırma, çok düzeyli bir diyagramlar hiyerarşisi yaratarak, sürecin temel hale geldiği ve bunları daha fazla detaylandırmanın imkansız olduğu bir ayrıştırma düzeyine ulaşılıncaya kadar devam eder.

Bilgi kaynakları (harici varlıklar) bilgi akışları Alt sistemlere veya süreçlere bilgi taşıyan (veri akışları). Bunlar da bilgiyi dönüştürür ve bilgiyi diğer süreçlere veya alt sistemlere, veri depolama aygıtlarına veya harici varlıklara, yani bilgi tüketicilerine aktaran yeni akışlar oluşturur. Dolayısıyla veri akış diyagramlarının ana bileşenleri şunlardır:

dış varlıklar;

sistemler/alt sistemler;

süreçler;

veri depolama cihazları;

veri akışları.

4.3 IDEF3 modelini oluşturma ilkesi

IDEF3 aynı zamanda süreç oluşturma yöntemi olarak da kullanılabilir. IDEF3, IDEFO'yu tamamlar ve daha sonra simülasyon analizi için kullanılabilecek modeller oluşturmak için gerekli her şeyi içerir.

IDEF3'teki her iş bir iş süreci senaryosunu tanımlar ve başka bir işin bileşeni olabilir. Senaryo, modelin amacını ve kapsamını tanımladığından, eserlerin eylem sürecini ifade eden bir fiil ismiyle veya bu ismi içeren bir cümleyle adlandırılması önemlidir.

Modelin bakış açısı belgelenmelidir. Bu genellikle işin tamamından sorumlu kişinin bakış açısıdır. Modelin amacını, yani modelin cevaplamayı amaçladığı soruları da belgelemek gerekir.

Kavşak noktası. Bir işin tamamlanması, birden fazla işin başlaması için bir sinyal görevi görebilir veya bir iş, başlamak için birden fazla işin tamamlanmasını bekleyebilir. Kavşaklar, birleştirme ve dallanma sırasında okların nasıl etkileşime girdiğinin mantığını veya başlamadan önce tamamlanması gereken veya tamamlanması gereken birden fazla olayı göstermek için kullanılır. sonraki iş. Kavşak türleri tabloda sunulmaktadır:

Kavşak türleri

Tanım	İsim	Okların birleştirilmesi durumunda anlamı (Fan-in Kavşağı)	Bu durumda anlam dallanma okları (Fan-out Kavşağı)
||&	Asenkron VE	Önceki tüm süreçlerin tamamlanması gerekiyor	Aşağıdaki işlemlerin tümü çalışıyor olmalıdır
||&||	Senkron VE	Önceki tüm işlemler aynı anda tamamlanır	Aşağıdaki işlemlerin tümü aynı anda çalışır
||O	Asenkron VEYA	Bir veya daha fazla önceki işlem sonlandırılmalıdır	Aşağıdaki işlemlerden bir veya daha fazlası çalışıyor olmalıdır
||O||	Senkron VEYA	Bir veya daha fazla önceki süreç aynı anda sonlandırıldı	Aşağıdaki işlemlerden bir veya daha fazlası aynı anda çalışıyor
||X		Yalnızca bir önceki süreç tamamlandı	Sadece bir sonraki süreç başlıyor

Diyagramdaki tüm kesişme noktaları numaralandırılmıştır, her numaranın bir J öneki vardır. Tanım Düzenleyici iletişim kutusunu kullanarak kesişimin özelliklerini düzenleyebilirsiniz. IDEFO ve DFD'den farklı olarak IDEF3'te oklar yalnızca kesişim noktalarında birleşebilir ve dallara ayrılabilir.

Bağlantı nesnesi. IDEF3'teki bir referans nesnesi, bir okla, kavşakla veya çalışmayla ilişkilendirilemeyen bazı fikirleri, kavramları veya verileri ifade eder. Bir bağlantı nesnesi girmek için |R| düğmesini kullanın. – (şemaya bir referans nesnesi ekleyin - Referans). Referans nesnesi, çalışma dikdörtgenine benzer şekilde bir dikdörtgen olarak çizilir. Referans nesnesinin adı Referans iletişim kutusunda (Ad Düzenleyici açılır menü öğesi) ayarlanır; ad olarak diğer diyagramlardaki bir okun adını veya veri modelindeki bir varlığın adını kullanabilirsiniz. Referans nesneleri iş birimlerine veya kesişimlere noktalı çizgilerle bağlanmalıdır. Resmi IDEF3 spesifikasyonu üç referans nesnesi stilini birbirinden ayırır: koşulsuz, eşzamanlı ve eşzamansız. BPwin yalnızca koşulsuz referans nesnelerini destekler. Nesne durumu geçiş diyagramlarında kullanılan eşzamanlı ve eşzamansız referans nesneleri desteklenmez.

5. Simülasyon

5.1 Sera modeli

Model Gezgini – Model Gezgini

Bağlam diyagramı:

A0 ayrışma diyagramı:

Ayrışma diyagramı A1:

IDEF3 A11.1 diyagramı:

Veri akış şeması A12:

Ayrışma diyagramı A2:

IDEF3 A21.1 diyagramı:

Ayrışma diyagramı A3:

Ayrıştırma diyagramı A4:

Ayrışma diyagramı A5:

Ayrıştırma diyagramı A6:

A63 veri akış şeması:

5.2 Matematiksel model

Daha fazlası için Detaylı Açıklama Bir seranın işletilmesi için işletmenin faaliyetlerinden elde edilen ürünün matematiksel modelinin oluşturulması gerekmektedir.

Bu matematiksel model Farklı koşullar altında birim fiyatların hesaplanmasını anlatacaktır.

e - üretici tarafından belirlenen bir mal biriminin maliyeti, bir birim malın üretimiyle ilgili tüm maliyetleri içerir, bu rakamın ana kısmı tohumların satın alma fiyatıdır;

v - tohum satın alma fiyatı, bu, işletmenin tedarikçiden tohum satın aldığı fiyattır ("tohum satın alma" bölümü);

a - işçilik maliyetleri (işletme içindeki maaşlar ve diğer giderler);

g – yakıtlar ve yağlayıcılar (yakıtlar ve yağlayıcılar);

n – vergiler (tüketici kısmı) devlet tarafından belirlenir ve sabit bir orana sahiptir;

k – KDV, katma değer vergisinin de sabit bir oranı vardır;

r - perakende fiyatı, bu, bir üreticinin ürününün bir birimini piyasada sattığı para miktarıdır; kural olarak, perakende fiyatı, belirli bir kâr yüzdesi ile maliyete göre belirlenir;

s işletmenin birim mal başına kâr marjıdır, kural olarak miktarı her girişimci tarafından ayrı ayrı belirlenir, bu durumda maliyetin %40'ıdır, yani (e*40)/100

Ö - Toptan satış fiyatı 100 adetten alımlarda birim mal başına teklif edilen para miktarıdır, bu durumda perakende satış fiyatı üzerinden %10 indirim yapılır;

os – toptan alımlarda indirim (os

Üretilen birim mal başına maliyeti hesaplamak için matematiksel model:

Üretilen mal birimi başına perakende fiyatını hesaplamak için matematiksel model:

Üretilen mal birimi başına toptan satış fiyatını hesaplamak için matematiksel model:

o= v+a+g+n+k+s - işletim sistemi

o=r - (r*10)/100

Sera İşletmesi işletmesinde ürünlerin maliyetinin hesaplanması, belge akışını kontrol eden, işletmenin gelir ve giderlerini dikkate alan, muhasebe defterlerini tutan, sertifika veren muhasebe departmanı tarafından yapılmaktadır. Muhasebeci, işletmenin matematiksel modelinde elde edilen bu formüllere dayanarak hem perakende hem de toptan malların fiyatını hesaplayabilir.

6. Karşılaştırmalı analiz

Kuruluşumuzu modellemek için 5 metodoloji kullandık: Dragon, UML, IDEF0, IDEF3, DFD. Bizim görüşümüze göre işletme modelimizi temsil etmek için en iyi seçenek UML metodolojisidir çünkü sera işletmeciliğinin ana yönlerini daha net ve doğru bir şekilde yansıtmaktadır.

UML diyagramlarının okunması nispeten kolaydır.

Örneğin Greenhouse uygulama sisteminin tasarımı sonucunda kullanılan “Kullanım Senaryosu” diyagramı müşteri, son kullanıcı ve geliştiricinin sistemin işlevselliğini ve davranışını ortaklaşa tartışmasına olanak tanır. Bir "sınıf diyagramı" sistemin yapısını tanımlamanıza olanak tanır; sistemin sınıflarını, bunların niteliklerini, yöntemlerini ve sınıflar arasındaki bağımlılıkları gösterir; bu da işletmenin senaryosunu ve organizasyonunu ayrıntılı olarak ortaya çıkarabilir.

Dragon metodolojisi de oldukça net bir yapıya sahip ancak çeşitli sistemleri modellemek için bu kadar geniş yeteneklere sahip değil.

Visio, en basit ve en erişilebilir süreç modelleme aracıdır. Bu ürün, MS Office tarzında standart, tanıdık kontrol panellerine sahiptir ve bu paketteki tüm uygulamalarla kolayca entegre olur, bu da deneyimsiz kullanıcıların onunla çalışmasını kolaylaştırır. Ancak zaman veya değer analizi rapor geliştirmeyi gerektirir ve bu da ürünün kullanımını çok daha zorlaştırır. Standart raporların iş süreçlerini analiz etmek için yeterli olmadığı açıktır. Buna rağmen Visio, hem Rusya'da hem de yurt dışında iş süreçlerini tanımlamak için kullanılan yaygın bir araçtır. Visio, iş süreçlerini tanımlamak için IDEF ve UML formatlarını destekler. Formatların bağımsız olarak geliştirilmesi de mümkündür.

BPWIN - yeterli basitlik ve mükemmel analiz yetenekleri ile karakterize edilen bir ara yer kaplar. BPWIN'in işlevselliği sadece diyagram çizmek değil aynı zamanda modelin bütünlüğünü ve tutarlılığını da kontrol etmektir. BPWIN, diyagram öğelerinin tanımlanması ve açıklanmasının yanı sıra diyagramlar arasındaki ilişkilerin bütünlüğünü kontrol etmede mantıksal netlik sağlar. Araç, modellemede en yaygın hataların düzeltilmesini sağlar. Ek olarak BPWIN, diyagram öğelerine, o öğenin doğasında bulunan belirli özellikleri tanımlamak için uygulanan özel özellikleri de destekler. Bu sistemin ana sınırlaması, model oluştururken katı kısıtlamalara sahip olan IDEF standardıdır. Bu, basit prosedürleri açıklarken görevi basitleştirir, ancak büyük süreçlerin tanımını karmaşıklaştırır. 1DEF diyagramları, karmaşık süreçleri anlatırken görünüş olarak birbirine çok benzeyen sayısız birbirine bağlı diyagramı temsil etmeye başlar ve bu da sürecin bir bütün olarak anlaşılmasını zorlaştırır.

7. Karar:

Bu kurs çalışması sırasında tüm hedeflerimize ulaşıldı.

Bu bağlamda geliştirilmekte olan konu olan seracılık çalışmalarını inceledik. Bunu yapmak için bu alanın terminolojisini anlamak, gerekli düzenleyici ve yasal belgeleri toplamak, kuruluşumuzdaki belge örneklerini incelemek ve bunların hem kuruluş içindeki hem de dışındaki hareketlerini takip etmek gerekiyordu.

Bu faaliyetler sonucunda, ilk analizin yapıldığı ve tasarlanan modelin çizimlerinin yapıldığı bilgiler elde edildi.

Geliştirmenin bir sonraki aşaması tasarım aşamasıdır. Tasarım ve uygulamaya başlamadan önce gereksinimleri yüksek düzeyde doğru ve ayrıntılı bir şekilde anlamanız gerekir. Ayrıca sistemi formüle etmek için girdi olarak kullanılabilecek bir gereksinim yapısına sahip olmak oldukça faydalıdır. Bütün bunlar analiz ve modelleme yoluyla elde edilir. Analiz ve modelleme yaparak, tasarım öncesi aşamada hazırladığımız ve daha sonraki tasarım ve uygulama faaliyetleri için basitleştirdiğimiz görev ayrımını sağladık. Çözülmesi gereken sorunlar ile bunlarla başa çıkmak için alınması gereken kararlar arasında ayrım yaparız.

Modelleme ve tasarım aşamalarındaki çalışmalar sonucunda uygulanması için yeterli bilgiyi içeren bir sistem tasarımı elde ettik.

Seranın çalışmasını analiz ettikten sonra, her bir departmanın iş yükünün derecesini, öncelikle neyin otomatikleştirilmesi gerektiğini ve hangi yolla otomatikleştirilmesi gerektiğini değerlendirebiliriz.

İşi kolaylaştırmak için çiftliğimizde çalışmayı kolaylaştıracak yeni teknolojileri tanıtabiliriz.

Edebiyat:

Rogozov Yu.I., Stukotiy L.N., Sviridov A.S. “Sistem Modellemesi” TRTU, 2004.

S.V. Maklakov “Bilgi sistemleri geliştirmek için CASE araçları. BPwin ve Erwin” – M.: DialogMifi, 2001.

Maklakov S. “Yeni nesil Computer Associates CASE araçlarında yapısal ve nesne tabanlı yaklaşımın birleştirilmesi” // Eğitim ve Danışmanlık Merkezi. 2002.

IDEF0: nedir ve nasıl kullanılır?

Çoğu zaman geliştiricilerden yalnızca şirketin işleyişindeki bir sorunu belirleyip çözmeleri değil, aynı zamanda sorunun şirket yapısında nasıl bir rol oynadığını da belirlemeleri istenir. Çünkü işlevsiz bir birimin diğerleriyle nasıl etkileşime girdiğini anlamak, onun neden düzgün çalışmadığını anlamaktan çok daha önemlidir. Bu nedenle herhangi bir sorunun belirlenmesi şirketin çalışmasının incelenmesi ve işlevsel modelinin oluşturulmasıyla başlar.

Nasıl bir şirketten bahsediyor olursak olalım, yöneticinin işlevsel bir şirket modeline sahip olması gerektiğini diyeceksiniz. Ancak uygulamanın gösterdiği gibi çoğu durumda bu model yoktur.

Grafik Avantajı

IDEF0 modelleri nelerdir? Kendi özelliklerine ve yapım kurallarına sahip grafik diyagramlar. Neden grafikler? Çünkü etkilidir. Bunu birkaç örnekte görmek mümkündür.

Ordunun savaş planını grafik sembollerin uygulandığı haritaların yardımıyla değil kelimelerle açıkladığını hayal edelim. Şimdi bu imkansız gibi görünüyor ama 19. yüzyılın ikinci yarısına kadar durum tam olarak böyleydi. Grafikler, açıklanması oldukça zor olanı anlamaya ve dolayısıyla anlamaya yardımcı olur.

İş süreçlerinde de durum aynıdır: Birçok teknik spesifikasyon, geliştiricilerin işini önemli ölçüde basitleştirecek ve müşteriler için tasarruf sağlayacak şekilde grafik gösterimler şeklinde sunulabilir.

IDEF0'ın faydalarıBT-uzmanlar

Geliştiricilerin faaliyetleri, örneğin bir CRM kurmak veya etkili bir ERP oluşturmak gibi, önceden kurulmuş bir sistemde değişiklik yapmakla ilişkilidir. Bunu doğru bir şekilde yapmak için öncelikle bu sistemin nasıl çalıştığını incelemeniz gerekir. Geliştirici bunu inceledikten sonra, duruma ilişkin vizyonunu, sorunu çözmek için gerekli eylemleri ve beklenen sonucu ortaya koyduğu ticari bir teklif yazar. Böyle bir belge bir düzineden fazla sayfa alabilir. Bu bir yandan iyidir çünkü müşteri kendisini ilgilendiren maksimum bilgiyi alır. Öte yandan, hacimli bir metni incelemek, başarılı bir iş adamının çoğu zaman sahip olmadığı bir zaman gerektirir.

Peki uzun metinlere başvurmadan özü net bir şekilde nasıl aktarabilirsiniz? Grafik Sanatları! Gerekli bilgileri açıkça göstererek yazılanları kısaltmanıza olanak tanıyan şey budur. Sonuçta bir görsel yüzlerce kelimenin yerini tutabilir. İş süreçlerini açıklarken grafik kullanımına gelince, bu %100 doğrudur.

Öncelikle IDEF0 ve notasyonun ne olduğunu ve ne için gerekli olduğunu anlayalım.

İş süreçlerini açıklamaya yönelik gösterim: nedir?

Gösterim, iş süreçlerinin modellemede kullanılan grafik nesneler ve modelleme kurallarının kendisi şeklinde sunulduğu bir formattır. Gösterim, bir şirketin işleyişini hayal etmenize olanak tanıyan, departmanlar ve bölümler arasındaki bağlantıyı gösteren bir tür grafik dilidir. Yani notasyon, iş analitiğinde bir tür programlama dili olarak düşünülebilir.

IDEF0...

IDEF0, işlevsel bir modelleme yönteminin yanı sıra iş süreçlerini tanımlamak ve resmileştirmek için kullanılan grafiksel bir gösterimdir. IDEF0'ın özelliği, bu metodolojinin nesnelerin ikincilleştirilmesine odaklanmasıdır. IDEF0, 1981 yılında ABD'de kurumsal otomasyon için geliştirildi.

Şirketin fonksiyonel modeli

IDEF0 işlevsel modeli, her biri birden fazla giriş ve çıkışa sahip olan bloklardan oluşur. Her blokta gerekli seviyeye kadar detaylandırılmış kontroller ve mekanizmalar bulunur. En önemli işlev sol üst köşede bulunur. Geri kalan oklara ve fonksiyon bloğu açıklamalarına bağlanır. Her okun veya aktivitenin kendi anlamı vardır. Bu nedenle, herhangi bir idari ve organizasyonel süreci tanımlamak için böyle bir model kullanılır.

Ok türleri

Gelen kutusu görevler belirlendi.

Dışa dönük etkinliğin sonucunu çıktı olarak verir.

Yöneticiler(yukarıdan aşağıya oklar) kontrol mekanizmalarıdır.

Mekanizmalar(aşağıdan yukarıya doğru oklar) gerekli çalışmayı gerçekleştirmek için kullanılır.

Fonksiyonel bir modelle çalışırken aşağıdaki kurallar kabul edilir. Örneğin, oklar isimlerle (kurallar, plan vb.), Bloklar ise fiillerle (kayıt tutmak, bir anlaşma yapmak) adlandırılır.

IDEF0 bilgi alışverişinde bulunmanıza olanak tanır ve çok yönlülüğü ve anlaşılırlığı sayesinde değişim katılımcıları birbirlerini kolaylıkla anlayabilir. IDEF0 dikkatlice geliştirildi ve iyileştirildi; IDEF0 ile ERWIN, VISIO, Bussines studio gibi çeşitli araçları kullanarak çalışabilirsiniz.

IDEF0'ın yadsınamaz bir avantajı da var. Bu teknik nispeten uzun zaman önce geliştirildi ve otuz yıldan fazla bir süredir kapsamlı bir cilalama ve ayarlama sürecinden geçti. Bu nedenle hızlı ve minimum hata olasılığıyla bir şirketin işlevsel modelini oluşturabilirsiniz.

Elbette başka metodolojiler de var, peki neden IDEF0'ı öneriyoruz? Bir demir testeresi ile bir metal boru parçasını kesebilirsiniz, ancak görüyorsunuz, bunu bir öğütücü ile yapmak çok daha kolay. IDEF0 için de durum aynı: Artık işlevsel bir modelleme aracı yok, onunla ihtiyacınız olan sonucu kolayca ve hızlı bir şekilde alabilirsiniz.

İşlevsel bir model nasıl oluşturulur?

Makale yazma örneğini kullanarak fonksiyonel bir modelin oluşturulmasına bakalım.

Ana ünite“Makale Yazmak” olarak adlandırılacaktır.

Bir makale yazmak için gerekenler şu şekilde yansıtılmıştır: gelen oklar– “Deneyim”, “Ek literatür”.

Kontrol okları bir makale yazmak için - “Makalenin Özeti”, “Biçimlendirme gereksinimleri”, “Rus dilinin kuralları”.

Mekanizmalar yazarın kendisi, metin yazarı, editör ve yazılımdır. Bu mekanizmalar nasıl organize ediliyor? Yazar metni ses versiyonunu kaydederek oluşturur. Metin yazarı, yayın planına odaklanarak, yayıncının gerekliliklerine ve Rus dilinin kurallarına uyarak metni metin formatına aktarır. Daha sonra makaleyi kontrol eden, konuşma, yazım ve noktalama hatalarını düzelten bir editör çalışmaya dahil olur. Yazılım, süreçteki katılımcıların makaleyi oluşturmak için kullandıkları programlar ve araçlardır.

Yukarıdakilerin tümü sadece genel bir çalışma planıdır, bu nedenle ayrıntılı olması gerekir.

Modelimize dönelim ve genel bloğu birbirine bağlı birkaç öğeye ayıralım.

Yani, bir makale yazma sürecinin tamamı 4 aşamaya ayrılabilir:

1. Sesli versiyonunu hazırlayın.
2. Metni basılı biçimde hazırlayın.
3. Metnin basım için düzenlenmesi ve hazırlanması.
4. Makalenin yayınlanması.

Diyagram, hangi kontrol elemanlarının ve mekanizmalarının hangi aşamada devreye girdiğine dair bilgiyi yansıtmaktadır. Örneğin, yüksek kalitede bir metin oluşturmak için yazar, yayıncının belirlediği yayın planını ve gereklilikleri bir rehber olarak kullanarak kendi deneyim ve bilgisini kullanır. Metin yazarı, metnin basılı bir versiyonunu oluştururken ve editör onu düzeltirken Rus dilinin kurallarını kullanır. Örneğin bir çevrimiçi yayında bir makale yayınlamak için özel bir yazılım gerekir.

İşlevsel bir model hazırlarken icracı, yaratılışın amacına ve kendi bakış açısına odaklanır.

Çeşitli yönetim kararları alınırken fonksiyonel modelleme etkili bir şekilde kullanılır. Makale yazma sürecine ilişkin verdiğimiz örnekte, biri metin yazarı, diğeri editör olmak üzere iki uzman bulunmaktadır. Ve proje finansmanının şemaya göre gerekli optimizasyonu ile bunun nasıl yapılacağını belirlemek zor değildir. Metin yazarı ve düzeltmen benzer çalışma yöntemlerine sahiptir, dolayısıyla editörün yapamayacağı şekilde doğrudan sesli metinle çalıştığı için metin yazarından tüm işi yapmasını isteyebilirsiniz. Bu durumda, metin yazarına bu işi editör için tasarlanan tutarın yarısı karşılığında yapması teklif edilebilir. Evet, bu durum metin kalitesinde kayıpla sonuçlanabilir ancak optimizasyon görevi başarıyla tamamlandı. Ancak bunu görsel bir diyagram olmadan yapmak daha zor olacaktır.

Gösterim oluşturma süreciIDEF0

Gösterim oluşturmak için birçok program vardır. Bazıları işlevsel modeller oluşturmak için tasarlanmıştır, diğerleri ise herhangi bir grafik nesneyle çalışmanıza olanak tanır. Bazıları için ise ilk aşamada bir kağıt, bir kalem ve bir silgi yeterlidir.

Şirketin çalışmalarını tanımlamaya, yani doğrudan iş süreçlerinin notasyonunu oluşturmaya başlamadan önce, şirketin işleyiş ilkelerini incelemelisiniz. Bunu yapmak için üçüncü taraf bir uzman tarafından bir röportaj yapılır. Soru öncelikle şirket başkanı tarafından, ardından işin diğer aşamalarını denetleyen uzmanlar tarafından yanıtlanır.

Çalışmanın ilk aşamasının sonucu iki gösterimdir. Biri iş süreçlerini orijinal haliyle yansıtacaktır. Bu notasyon, görüşmenin sonuçlarına göre oluşturulacak ve her ayrıntı üzerinde şirket başkanı ve çalışanları ile anlaşmaya varılmalıdır. Şirkette var olan iş süreçlerine ilişkin anlayışınızın gerçeklikle örtüşmesi son derece önemlidir; bu, her düzeyde onay gerektirir.

İkinci gösterim “Olması gerektiği gibi” olarak adlandırılabilir. Göreve uygun olarak yapılan değişikliklerle ilki esas alınarak oluşturulur.

IDEF0 standardı ve gereksinimleri

IDEF0'ın temel gereksinimlerinden biraz daha yukarıda bahsetmiştik.

1. Ana eleman sol üst köşededir.
2. Her öğenin gelen ve giden okları olmalıdır. Ayrıca gelen oklar solda, giden oklar ise sağdadır.
3. Kontrol elemanları üstte, mekanizmalar altta bulunur.
4. Bir kağıda veya ekrana birkaç blok yerleştirirken, sonraki bloklar bir öncekinin sağ altına yerleştirilir.
5. Şemalar, oklar minimum sayıda kesişecek şekilde oluşturulmalıdır.

Doğal olarak IDEF0 standardı genel kabul görmüş normları, gereksinimleri ve tanımları içerir. Bunlar üzerinde ayrıntılı olarak durmayacağız, dilerseniz bu bilgiyi bulmak kolaydır.

IDEF0 ile çalışırken hatalar

Her aktivitede olduğu gibi fonksiyonel modelleme yapılırken de hatalar meydana gelir. Bunlardan en tipik olanlarına bakalım.

Birden Çok Renk Kullanmak

Fonksiyonel modellemede tüm unsurların önemli olduğunu, daha önemli veya daha az önemli diye bir şeyin olmadığını unutmamak önemlidir. Kullanıcılar kağıt üzerinde veya bilgisayar programlarından birinde modelleme yaparken blokları ve okları farklı renklere boyayarak diyagramı daha görsel hale getirmeye çalışırlar. Ancak pratikte bu sadece diyagramı daha görsel hale getirmekle kalmaz, tam tersine kafa karışıklığına yol açar ve tasvir edilenin algısını bozar.

Bu nedenle ideal seçenek, ek renk seçenekleri kullanılmadan siyah beyaz bir şemadır. Bu sadece yanlış anlamaların ortadan kaldırılmasına yardımcı olmakla kalmayacak, aynı zamanda model oluşturucuyu doğrudan disipline edecek ve bu da modelin okunabilirliği ve görünürlüğü üzerinde faydalı bir etkiye sahip olacaktır.

Çok sayıda blok

Bir şirketin çalışmalarının işlevsel bir modelini hazırlarken, yazarları genellikle her şeyi, hatta en küçük ayrıntıları bile yansıtmaya çalışır. Sonuç, çok sayıda blok ve ok içeren bir diyagramdır. Sonuç olarak okunabilirliği ve netliği azalır.

Bu hatanın önüne geçmek için konuyu anlamaya yetecek detayı kullanın. Ayrıntılı ayrıntılar ancak önemli bir sorunun çözümü için gerçekten ihtiyaç duyulması durumunda hazırlanır.

Hataları düzeltirken yapıyı değiştirme

Diyagram oluştururken gelen, giden veya diğer önemli unsurlar olmadan hiçbir sürecin kalmaması önemlidir. Örneğin, bir yazarı bir diyagramdan kaldırmanız gerekiyorsa, onunla doğrudan ilgili tüm öğeleri ve okları kaldırmanız gerekir. Diyagramda kalırlarsa, yanlış anlaşılmalar ve kafa karışıklıkları ortaya çıkacaktır, çünkü detaylandırıldıklarında bilinmeyen bir hedefe varacaklardır.

Blok eklerken de aynı durum ortaya çıkar. Herhangi bir bilgi girmeniz gerekiyorsa, gerekli özellikleri sağlayıp sağlamadığınızı kontrol edin. Karmaşık iş süreçlerini modellerken, bir bölümdeki küçük bir değişiklik bile diğerinde değişiklik gerektireceğinden, bu durumun dikkatle izlenmesi gerekir.

Blokların ve kontrol elemanlarının adı

Model öğelerini adlandırma kuralları oldukça basittir, ancak bunları hatırlamak son derece önemlidir: kontrol oklarına isimler, bloklara fiiller denir. Bu kural IDEF0 standardında belirtilmiştir, karışıklık ve hataların önlenmesine yardımcı olur.

IDEF0 kullanmanın faydaları

Görünürlük.Şirketin çalışmalarını diyagram şeklinde tasvir ederek şirketin nasıl çalıştığı, sorunların nerede ortaya çıkabileceği ve bunların oluşmasının nasıl önlenebileceği netleşir.

Karşılıklı anlayış, diyagramın yanlış yorumlanma olasılığını ortadan kaldırır.Şirketin çalışmalarını bloklar ve kontrol unsurları şeklinde temsil eden işlevsel bir modelin görünürlüğü ve erişilebilirliği, şirketlerinin işleyişini yönetimle tartışırken size yardımcı olacaktır. Bu arada, gerekirse işlevsel model için tüm terimlerin ve kuralların toplandığı bir sözlük oluşturulur. Bu sayede yönetici ve şirket çalışanları ile aranızda yanlış anlaşılma olasılığı en aza indirilir.

Model oluştururken basitlik ve zaman tasarrufu. Elbette fonksiyonel modelleme tekniklerinde uzmanlaşmak için oldukça fazla zaman harcamanız gerekiyor. Her şeyden önce, büyük miktarda bilgiyi kısa bir diyagram biçiminde nasıl sunacağınızı öğrenmeniz gerekir; Kaynak verileri filtreleyebilir ve sıkıştırabilir. Ancak eğitime harcanan zaman ve çaba, daha sonra karşılığını fazlasıyla verir. Sonuçta işlevsel bir model oluşturmak ve bunu erişilebilir bir şekilde sunmak çok zaman almayacak.

Minimum hata olasılığı. IDEF0 standardına göre çalışmak, kurallarına sıkı sıkıya bağlı kalmayı gerektirir. Bu, icracıyı disipline eder ve hata olasılığını ortadan kaldırır. Ayrıca standarda uyulmaması anında fark edilir hale gelir.

Ve sonunda

İki iş analisti ancak şirket yapısının son derece basit olması durumunda aynı işlevsel modellere sahip olabilir. Diğer durumlarda modeller birbirinden farklı olacaktır. Bu doğaldır, çünkü her analistin kendine özgü deneyimi, şirketin işleyişine ilişkin kendi anlayışı ve kendisine verilen görevleri nasıl çözeceğine ilişkin kendi bakış açısı vardır. Bir iş analisti, yöneticinin bakış açısından işlevsel bir model geliştirir ve kendisine verilen görevleri nasıl çözeceğini hayal eder.

Bizce IDEF0 aracı sadece profesyonel iş analistleri için değil, işini doğrudan analiz eden ve etkili bir yönetim sistemi kurmaya çabalayanlar için de faydalı olacaktır.