Seringkali, pengembang diminta tidak hanya untuk mengidentifikasi dan memecahkan masalah dalam pekerjaan perusahaan, tetapi juga untuk menentukan peran apa yang dimainkannya dalam struktur perusahaan. Karena lebih penting untuk memahami bagaimana unit yang tidak berfungsi berinteraksi dengan yang lain daripada sekadar memahami mengapa itu tidak berfungsi. Oleh karena itu, mengidentifikasi masalah dimulai dengan mempelajari pekerjaan perusahaan dan menyusun model fungsionalnya.
Seringkali, pengembang diminta tidak hanya untuk mengidentifikasi dan memecahkan masalah dalam pekerjaan perusahaan, tetapi juga untuk menentukan peran apa yang dimainkannya dalam struktur perusahaan. Karena lebih penting untuk memahami bagaimana unit yang tidak berfungsi berinteraksi dengan yang lain daripada sekadar memahami mengapa itu tidak berfungsi. Oleh karena itu, mengidentifikasi masalah dimulai dengan mempelajari pekerjaan perusahaan dan menyusun model fungsionalnya.
Anda akan mengatakan bahwa manajer harus memiliki model fungsional perusahaan, terlepas dari jenis perusahaan apa yang dia bicarakan. Tetapi, seperti yang ditunjukkan oleh praktik, dalam banyak kasus model ini tidak ada.
Keuntungan grafis
Apa itu model IDEF0? Skema grafis dengan karakteristiknya sendiri dan aturan konstruksinya. Mengapa grafis? Karena itu efektif. Hal ini dapat dilihat dalam beberapa contoh.
Mari kita bayangkan bahwa rencana militer operasi militer dijelaskan dengan kata-kata, dan bukan dengan bantuan peta dengan simbol grafis yang diterapkan padanya. Sekarang tampaknya tidak mungkin, tetapi sampai paruh kedua abad ke-19, hal itu benar-benar terjadi. Grafik membantu untuk memahami apa yang harus dijelaskan dan, karenanya, untuk memahami apa yang cukup sulit.
Hal yang sama dengan proses bisnis: banyak tugas teknis dapat dibuat dalam bentuk notasi grafis, yang akan sangat menyederhanakan tugas untuk pengembang dan menghemat uang untuk klien.
Manfaat IDEF0 untukDIA-spesialis
Kegiatan pengembang, apakah itu, misalnya, menginstal CRM atau membuat ERP yang efektif, dikaitkan dengan membuat perubahan pada sistem yang sudah ada. Dan untuk melakukannya dengan benar, Anda harus terlebih dahulu mempelajari cara kerja sistem ini. Setelah mempelajarinya, pengembang menulis proposal komersial di mana ia menetapkan visinya tentang situasi, tindakan yang diperlukan untuk memecahkan masalah, serta hasil yang diharapkan. Dokumen semacam itu bisa memakan lebih dari selusin halaman. Ini, di satu sisi, bagus, karena klien mendapatkan informasi maksimal yang dia minati. Di sisi lain, dibutuhkan waktu untuk mempelajari teks yang panjang. pengusaha sukses sering tidak.
Jadi bagaimana mungkin menyampaikan esensi tanpa menggunakan teks yang banyak? Grafik! Dialah yang memungkinkan Anda untuk mempersingkat apa yang tertulis, dengan jelas menunjukkan informasi yang perlu... Lagi pula, satu gambar dapat menggantikan ratusan kata. Dan dalam kaitannya dengan penggunaan grafik dalam menggambarkan proses bisnis, ini 100% benar.
Mari kita pahami dulu apa itu notasi dan IDEF0 dan untuk apa mereka.
Notasi untuk menggambarkan proses bisnis: apa itu?
Notasi adalah format di mana proses bisnis direpresentasikan dalam bentuk objek grafis yang digunakan dalam pemodelan, dan aturan pemodelan langsung. Notasi adalah sejenis bahasa grafis yang memungkinkan Anda untuk mewakili fungsi perusahaan, menunjukkan hubungan antara departemen dan divisi. Artinya, notasi dapat dianggap semacam bahasa pemrograman dalam intelijen bisnis.
IDEF0 adalah ...
IDEF0 adalah metode pemodelan fungsional dan notasi grafis yang digunakan untuk menggambarkan dan memformalkan proses bisnis. Keunikan IDEF0 adalah bahwa metodologi ini berfokus pada subordinasi objek. IDEF0 dikembangkan untuk otomatisasi perusahaan pada tahun 1981 di Amerika Serikat.
Model fungsional perusahaan
Model fungsional IDEF0 adalah blok, masing-masing dengan beberapa input dan output. Setiap blok memiliki kontrol dan mekanisme yang merinci hingga tingkat yang diperlukan... Fungsi terpenting terletak di pojok kiri atas. Ini terhubung ke sisa panah dan deskripsi blok fungsi. Setiap panah atau aktivitas memiliki arti tersendiri. Karena itu, model seperti itu digunakan untuk menggambarkan proses administrasi dan organisasi apa pun.
Jenis panah
masuk tugas ditetapkan.
keluar menampilkan hasil kegiatan.
Manajer(panah dari atas ke bawah) adalah mekanisme kontrol.
Mekanisme(panah dari bawah ke atas) digunakan untuk melakukan pekerjaan yang diperlukan.
Saat bekerja dengan model fungsional, aturan berikut diadopsi. Misalnya, panah diberi nama dengan kata benda (aturan, rencana, dll.), Blok - dengan kata kerja (simpan catatan, buat kesepakatan).
IDEF0 memungkinkan Anda untuk bertukar informasi, sementara karena keserbagunaan dan visibilitasnya, para peserta pertukaran akan dengan mudah saling memahami. IDEF0 dikembangkan dan ditingkatkan dengan hati-hati, Anda dapat bekerja dengan IDEF0 menggunakan berbagai alat, misalnya, ERWIN, VISIO, studio Bussines.
IDEF0 juga memiliki keunggulan yang tak terbantahkan. Teknik ini dikembangkan relatif lama, dan lebih dari tiga dekade telah mengalami penggilingan dan penyesuaian menyeluruh. Oleh karena itu, dimungkinkan untuk membuat model fungsional perusahaan dengan cepat dan dengan kemungkinan kesalahan yang minimum.
Tentu saja, ada metodologi lain, jadi mengapa kami merekomendasikan IDEF0? Anda dapat memotong sepotong pipa logam dengan gergaji besi, tetapi, Anda tahu, jauh lebih mudah untuk melakukan ini dengan penggiling. Demikian pula dengan IDEF0: tidak ada lagi alat yang berfungsi untuk pemodelan, dengan itu Anda dapat dengan mudah dan cepat mendapatkan hasil yang Anda butuhkan.
Bagaimana model fungsional dibuat
Mari kita menganalisis pembuatan model fungsional menggunakan contoh penulisan artikel.
Unit utama akan disebut "Penulisan Artikel".
Apa yang dibutuhkan untuk menulis artikel tercermin dalam panah masuk- "Pengalaman", "Bacaan lebih lanjut".
Panah kontrol untuk menulis artikel - "Garis Besar artikel", "Persyaratan untuk pendaftaran", "Aturan bahasa Rusia".
Mekanismenya langsung penulis sendiri, copywriter, editor, software. Bagaimana mekanisme ini diatur? Penulis membuat teks dengan merekam versi audionya. Copywriter mentransfer teks ke format teks, dengan fokus pada rencana publikasi, mengamati persyaratan penerbit dan aturan bahasa Rusia. Kemudian editor terhubung ke pekerjaan, yang memeriksa artikel, mengoreksi kesalahan ucapan, ejaan dan tanda baca. Perangkat lunak adalah program dan alat yang digunakan peserta dalam proses untuk membuat artikel.
Semua hal di atas hanyalah skema kerja umum, sehingga perlu dirinci.
Mari kembali ke model kita dan menguraikan blok umum menjadi beberapa elemen terkait.
Jadi, keseluruhan proses penulisan artikel dapat dibagi menjadi 4 tahap:
- Siapkan versi audio.
- Siapkan teks tercetak.
- Mengedit dan menyiapkan teks untuk dicetak.
- Publikasi artikel.
Diagram mencerminkan informasi tentang kontrol dan mekanisme mana yang terlibat pada tahap mana. Misalnya, untuk membuat teks berkualitas tinggi, penulis menggunakan pengalaman sendiri dan pengetahuan, menggunakan rencana penerbitan dan persyaratan penerbit sebagai panduan. Copywriter, membuat versi cetak teks, dan editor, saat mengoreksinya, menggunakan aturan bahasa Rusia. Untuk mempublikasikan sebuah artikel, misalnya, dalam publikasi online, diperlukan perangkat lunak khusus.
Saat menyiapkan model fungsional, pelaku dipandu oleh tujuan penciptaannya dan sudut pandangnya.
Pemodelan fungsional secara efektif digunakan ketika membuat berbagai keputusan manajemen... Dalam contoh proses penulisan artikel kami, ada dua spesialis - copywriter dan editor. Dan dengan perlunya optimalisasi pembiayaan proyek sesuai skema, tidak sulit untuk menentukan cara melakukannya. Copywriter dan proofreader memiliki metode kerja yang serupa, sehingga semua pekerjaan dapat ditawarkan kepada copywriter, karena ia bekerja langsung dengan teks audio, yang tidak dapat dilakukan oleh editor. Dalam hal ini, copywriter dapat ditawari untuk melakukan pekerjaan ini dengan setengah dari jumlah yang dimaksudkan untuk editor. Ya, dari sini, kualitas teks mungkin hilang, tetapi tugas pengoptimalan berhasil diselesaikan. Dan akan lebih sulit untuk melakukan ini tanpa diagram visual.
Proses pembuatan notasiIDEF0
Ada banyak program untuk membuat notasi. Beberapa dirancang untuk membuat model fungsional, sementara yang lain memungkinkan Anda untuk bekerja dengan objek grafis apa pun. Dan bagi seseorang, pada tahap pertama, selembar kertas, pensil, dan penghapus sudah cukup.
Sebelum melanjutkan ke uraian pekerjaan perusahaan, yaitu langsung ke pembuatan notasi proses bisnis, seseorang harus mempelajari prinsip-prinsip fungsi perusahaan. Untuk ini, wawancara dilakukan oleh spesialis pihak ketiga. Pertama-tama, kepala perusahaan menjawab pertanyaan itu, kemudian spesialis yang mengawasi tahapan pekerjaan lainnya.
Pekerjaan tahap pertama menghasilkan dua notasi. Seseorang akan mencerminkan proses bisnis dalam bentuk aslinya. Notasi ini akan dibuat berdasarkan hasil wawancara, dengan setiap detail harus disepakati dengan pimpinan perusahaan dan karyawannya. Sangat penting bahwa pemahaman Anda tentang proses bisnis yang ada di perusahaan bertepatan dengan kenyataan, ini membutuhkan konfirmasi di semua tingkatan.
Notasi kedua bisa disebut "Sebagaimana mestinya". Itu dibuat atas dasar yang pertama dengan perubahan yang dibuat sesuai dengan tugas yang ada.
Standar IDEF0 dan persyaratannya
Kami berbicara tentang persyaratan dasar IDEF0 tepat di atas.
- Elemen utama ada di pojok kiri atas.
- Setiap elemen harus memiliki panah masuk dan panah keluar. Selain itu, panah yang masuk ada di sebelah kiri, di sebelah kanan - yang keluar.
- Elemen kontrol terletak di bagian atas, mekanisme di bagian bawah.
- Saat menempatkan beberapa blok pada satu lembar atau layar, yang berikutnya ditempatkan di kanan bawah yang sebelumnya.
- Skema harus dibuat sehingga panah berpotongan jumlah minimal sekali.
Kesalahan saat bekerja dengan IDEF0
Seperti halnya aktivitas apa pun, kesalahan terjadi saat melakukan pemodelan fungsional. Mari kita menganalisis yang paling khas.
Menggunakan banyak warna
Penting untuk diingat bahwa dalam pemodelan fungsional semua elemen penting, tidak ada yang lebih penting atau kurang penting. Saat membuat model di atas kertas atau di salah satu program komputer, pengguna mencoba membuat diagram lebih visual dengan mewarnai balok dan panah dengan warna berbeda. Namun, dalam praktiknya, ini tidak hanya tidak membuat diagram lebih visual, tetapi, sebaliknya, menyebabkan kebingungan dan fakta bahwa persepsi tentang apa yang digambarkan terdistorsi.
Oleh karena itu, opsi yang ideal adalah skema hitam putih tanpa menggunakan opsi warna tambahan. Ini tidak hanya akan membantu menghilangkan kesalahpahaman, tetapi juga mendisiplinkan pembuat model secara langsung, yang secara menguntungkan mempengaruhi keterbacaan dan kejelasan model.
Sejumlah besar blok
Saat menyusun model fungsional pekerjaan perusahaan, penulisnya sering mencoba untuk mencerminkan semuanya, bahkan detail terkecil. Ternyata diagram dengan sejumlah besar balok dan panah. Akibatnya, keterbacaan dan kejelasannya berkurang.
Untuk menghindari kesalahan ini, gunakan detail yang cukup untuk memahami masalahnya. Perincian terperinci disiapkan hanya jika benar-benar diperlukan untuk menyelesaikan masalah penting.
Mengubah struktur saat memperbaiki kesalahan
Saat membuat diagram, penting agar lebih dari satu proses tidak dibiarkan tanpa masuk, keluar, atau lainnya elemen penting... Misalnya, jika Anda ingin menghapus penulis dari skema, maka Anda harus menghapus semua elemen dan panah yang terkait langsung dengannya. Jika mereka tetap dalam skema, maka akan ada kesalahpahaman dan kebingungan, karena selama merinci mereka akan menyebabkan tidak ada yang tahu di mana.
Situasi yang sama muncul dengan penambahan blok. Jika Anda perlu mengisi informasi apa pun, periksa untuk melihat apakah Anda telah memberikan atribut yang diperlukan. Ini harus dipantau secara ketat, karena ketika memodelkan proses bisnis yang kompleks, bahkan sedikit perubahan di satu bagian akan memerlukan perubahan di bagian lain.
Nama blok dan kontrol
Aturan untuk penamaan elemen model cukup sederhana, tetapi sangat penting untuk mengingatnya: panah kontrol disebut kata benda, blok disebut kata kerja. Aturan ini ditulis dalam standar IDEF0 dan membantu menghindari kebingungan dan kesalahan.
Manfaat menggunakan IDEF0
Visibilitas. Dengan menggambarkan pekerjaan perusahaan dalam bentuk diagram, menjadi jelas bagaimana perusahaan bekerja, di mana masalah dapat muncul dan bagaimana mencegahnya.
Saling pengertian, mengesampingkan kemungkinan salah tafsir skema. Visibilitas dan aksesibilitas model fungsional, yang mewakili pekerjaan perusahaan dalam bentuk blok dan elemen kontrol, akan membantu Anda ketika berdiskusi dengan manajemen tentang fungsi perusahaan mereka. Omong-omong, jika perlu, glosarium dibuat untuk model fungsional, yang berisi semua persyaratan dan konvensi. Dengan demikian, kemungkinan kesalahpahaman antara Anda dan manajer, karyawan perusahaan, dapat diminimalkan.
Kesederhanaan dan penghematan waktu saat membuat model. Tentu saja, dibutuhkan banyak waktu untuk menjadi ahli dalam pemodelan fungsional. Pertama-tama, Anda perlu mempelajari cara menyajikan sejumlah besar informasi dalam bentuk skema singkat, mis. dapat memfilter dan mengompresi data asli. Tetapi waktu dan upaya yang dihabiskan untuk pelatihan lebih dari terbayar nanti. Lagi pula, tidak perlu banyak waktu untuk membuat model fungsional dan menyajikannya dengan cara yang mudah diakses.
Kemungkinan kesalahan minimum. Bekerja sesuai dengan standar IDEF0 membutuhkan kepatuhan yang ketat terhadap aturannya. Ini mendisiplinkan pemain dan menghilangkan kemungkinan kesalahan. Selain itu, setiap ketidakpatuhan terhadap standar menjadi segera terlihat.
Dan akhirnya
Untuk dua analis bisnis, model fungsional hanya bisa sama jika struktur perusahaan sangat sederhana. Dalam kasus lain, model akan berbeda satu sama lain. Ini wajar, karena setiap analis memiliki pengalamannya sendiri, pemahamannya sendiri tentang fungsi perusahaan, sudut pandangnya sendiri tentang bagaimana menyelesaikan tugas yang diberikan kepadanya. Seorang analis bisnis mengembangkan model fungsional dari sudut pandang seorang manajer, membayangkan bagaimana dia akan menyelesaikan tugas yang diberikan.
Menurut pendapat kami, alat IDEF0 akan berguna tidak hanya untuk analis bisnis profesional, tetapi juga bagi mereka yang secara langsung menganalisis bisnis mereka dan berusaha untuk membangun sistem yang efektif pengelolaan.
Deskripsi diagram proses bisnis "Akuntansi untuk peralatan komputer perusahaan"
Deskripsi diagram IDEF0
Untuk membangun proses bisnis, diagram IDEF0 digunakan. Metodologi IDEF0 mengatur konstruksi sistem diagram hierarkis - deskripsi tunggal dari fragmen sistem. Pertama, dilakukan deskripsi sistem secara keseluruhan dan interaksinya dengan dunia luar (diagram konteks). Tiga tingkat diagram dibangun:
1. Kontekstual
2. Dekomposisi fungsional
Gambar 1 - Diagram konteks "Akuntansi teknologi komputer perusahaan "
Gambar 1 menunjukkan diagram konteks dari proses bisnis "Akuntansi untuk peralatan komputer perusahaan". Ini menampilkan sistem secara keseluruhan dan interaksinya dengan arus informasi eksternal utama.
Panah ditunjukkan dalam diagram konteks.
Jenis panah:
Input (bahan input: komputer dan aksesoris)
Keluaran (keluaran berupa laporan)
Panah kontrol adalah dokumen dan manajer
Panah mekanisme adalah karyawan dan peralatan
Informasi masukan untuk diproses:
Komputer - PC (komputer pribadi) yang terletak di perusahaan
Komponen - bahan yang diperlukan untuk memutakhirkan komputer (kartu video, motherboard, prosesor, kasing, catu daya, modul memori)
Aliran keluaran:
Laporan - laporan siap pakai tentang akuntansi peralatan komputer perusahaan
Kontrol masukan:
Aturan - kondisi yang harus dipenuhi untuk mencapai tujuan.
Pesanan - tugas yang diberikan kepada perusahaan (untuk menyimpan catatan peralatan komputer di perusahaan menggunakan sistem informasi tertentu)
Manajer adalah direktur dan manajer umum perusahaan.
Sumber Daya Masukan:
PC - komputer dengan bantuan akuntansi yang dilakukan.
Karyawan adalah spesialis yang melaksanakan instruksi yang diberikan oleh manajemen. Setelah membangun model konseptual, dekomposisi fungsional dilakukan - sistem dibagi menjadi subsistem dan setiap subsistem dijelaskan secara terpisah (diagram dekomposisi).
Gambar 2 menunjukkan dekomposisi fungsional dari empat pekerjaan.
Gambar 2 - Dekomposisi fungsional "Akuntansi untuk peralatan komputer perusahaan"
Jenis pekerjaan berikut diidentifikasi:
1) Pendaftaran pengiriman - proses di mana id diberikan ke produk, dikirim ke penyimpanan, ke gudang dan informasi tentang produk dimasukkan ke dalam program.
Pekerjaan Pendaftaran persediaan termasuk tujuh panah batas (pintu masuk, kontrol, mekanisme) dan daun panah internal (sambungan di pintu masuk).
Komunikasi panah di pintu masuk antara pekerjaan Pendaftaran pengiriman dan Pemeliharaan komputer (komputer);
Panah untuk masuk, keluar, kontrol diulang dalam pekerjaan selanjutnya.
2) Pemeliharaan komputer - proses di mana perakitan, perbaikan dan modernisasi komputer berlangsung.
Pekerjaan pemeliharaan komputer mencakup empat panah batas (input, kontrol, mekanisme, output) dan beberapa panah internal (komunikasi input, Masukan di pintu masuk).
Kontrol panah - aturan, perintah, pemimpin;
Sambungan panah di pintu masuk antara pekerjaan Pemeliharaan dan Penempatan Komputer (memasukkan data ke dalam database), antara pekerjaan Pemeliharaan dan Pelaporan Komputer (memasukkan data ke dalam database);
3) Penempatan - proses di mana penempatan komputer di kantor (kantor) berlangsung.
Kontrol panah - aturan, perintah, pemimpin;
Mekanisme panah - karyawan;
Tautan panah pada input antara Spreading dan Reporting (menetapkan id);
4) Menyusun laporan - tahap akhir dari proses akuntansi, yang terdiri dari meringkas total yang diperoleh dengan melakukan data sebelumnya dari akuntansi saat ini.
Kemudian setiap subsistem dipecah menjadi dekomposisi yang lebih kecil, dan seterusnya, sampai tingkat detail yang diinginkan tercapai.
Gambar 3 adalah diagram yang menunjukkan pekerjaan Proses Pengadaan secara lebih rinci.
Sebagai hasil dari perincian, fungsi utama disorot. Bagian "Pendaftaran persediaan" mencakup tujuh panah utama (masuk, keluar, kontrol, mekanisme).
Entri panah - komputer dan aksesori;
Panah kontrol adalah aturan, perintah, dan pemimpin. Panah garpu;
Panah mekanisme, percabangan - PC, karyawan;
Panah masuk, kontrol, mekanisme diulang di semua karya.
1) Penetapan nomor - penetapan nomor individu ke komputer dan aksesori.
Panah masuk - komputer dan aksesori. Komputer panah diulang dalam pekerjaan selanjutnya, kecuali untuk kompilasi laporan;
Kontrol panah - aturan, perintah, dan pemimpin;
Mekanisme Panah - PC dan Karyawan;
Tautan panah di pintu masuk antara pekerjaan Menetapkan nomor dan Mengirim barang ke gudang (transfer), antara Menetapkan nomor dan Menempatkan keseimbangan (masuk ke pangkalan);
2) Mengirim barang ke gudang - mengirim barang dengan nomor yang ditetapkan ke gudang.
Keluar Panah - Komputer;
Kontrol panah - aturan, perintah, dan pemimpin.
Tautan panah di pintu masuk antara karya "Mengirim barang ke gudang" dan "Mengatur neraca" (jumlah);
3) Balancing - memasukkan informasi ke dalam komputer.
Kontrol panah - aturan, perintah, dan pemimpin;
Mekanisme Panah - PC dan Karyawan;
Gambar 4 adalah diagram yang merinci perawatan komputer secara lebih rinci.
Sebagai hasil perincian, fungsi utama yang dilakukan dalam proses servis komputer disorot.
Pekerjaan pemeliharaan komputer mencakup 4 panah batas (input, output, kontrol, mekanisme). Panah internal (masukan umpan balik, komunikasi masukan).
1) Perakitan komputer - konfigurasi komputer untuk pesanan individu manajer.
Entri panah - komputer;
Kontrol panah - aturan, perintah, dan pemimpin;
Mekanisme Panah - Karyawan;
Tautan panah di pintu masuk antara karya: "Merakit komputer" dan "Memperbaiki komputer" (komputer);
2) Perbaikan komputer - perakitan komputer disetujui untuk perbaikan.
Entri panah - komputer;
Panah keluar - masuk ke pangkalan;
Kontrol panah - aturan, perintah, dan pemimpin;
Mekanisme Panah - Karyawan;
Panah masuk, keluar, kontrol, mekanisme bercabang;
Tautan panah di pintu masuk antara karya: "Perbaikan komputer" dan "Tingkatkan" (aksesori);
3) Upgrade - peningkatan, peningkatan, peningkatan komputer.
Panah keluar - masuk ke pangkalan;
Kontrol panah - aturan, perintah, dan pemimpin;
Mekanisme Panah - Karyawan;
Panah kontrol, mekanisme bercabang;
Gambar 5 menunjukkan Reporting Chart secara lebih rinci. Dekomposisi kerja Pelaporan mencakup 4 panah batas (input, output, kontrol, mekanisme). Panah internal (masukan umpan balik, komunikasi masukan).
Sebagai hasil dari pekerjaan, fungsi-fungsi berikut diturunkan:
1) Pengumpulan data - pengumpulan informasi untuk analisis dan pengambilan keputusan.
Masukkan panah - menetapkan id;
Kontrol panah - aturan, perintah, dan pemimpin;
Panah masuk, kontrol, mekanisme bercabang;
Tautan panah di pintu masuk antara pekerjaan: Pengumpulan data dan Validasi data (catatan);
2) Verifikasi data - verifikasi informasi dan mengirimkannya ke persiapan laporan.
Panah masuk - menetapkan id, memasukkan data ke dalam database;
Panah keluar - Laporkan;
Kontrol panah - aturan, perintah, dan pemimpin;
Mekanisme Panah - Karyawan, PC;
Panah masuk (penugasan id), kontrol, mekanisme bercabang;
Masukan panah umpan balik dari “Pemeriksaan Data” ke “Akuisisi Data” (pemeriksaan berulang).
Deskripsi diagram DFD
Dalam dekomposisi pekerjaan "Perawatan komputer" Gambar 1, empat pekerjaan internal, dua entitas eksternal dan dua penyimpanan data.
Gambar 1 - Perawatan komputer
1) Perakitan komputer - proses merakit komputer dari komponen yang ada.
2) Menyusun laporan - proses yang terdiri dari meringkas indikator akhir yang diperoleh dengan melakukan pekerjaan akuntansi saat ini.
3) Diagnostik - pemeriksaan kinerja
4) Upgrade - peningkatan, peningkatan, peningkatan komputer.
Entitas eksternal: komputer dan komponen
Penyimpanan data:
1) Gudang - tempat penyimpanan komputer yang dirakit dan ditingkatkan.
2) DB - database yang menyimpan semua laporan dan semua informasi tentang pekerjaan yang dilakukan.
Kami mengumpulkan informasi tentang komputer dan memilih komponen untuk perakitannya. Kemudian kami merakit komputer dan mengirimkannya ke gudang untuk penyimpanan, tetapi selain itu, setelah merakitnya, kami dapat mengirimnya terlebih dahulu untuk diagnostik, memeriksa pengoperasian, dan kemudian hanya ke gudang. Setelah mendiagnosis komputer yang dirakit, kami mengirim data untuk menyusun laporan tentang pekerjaan yang dilakukan dan memasukkan informasi ke dalam Database.
Kami juga memiliki entitas eksternal lain, ini adalah komputer. Kami mengirimkannya untuk modernisasi, kemudian untuk diagnostik untuk memeriksa kinerjanya, lalu kami membuat laporan dan memasukkan informasi tentang pekerjaan yang dilakukan di Database. Atau, setelah modernisasi, kami mengirim barang ke gudang, dan kemudian kami melakukan diagnosa, membuat laporan dan memasukkan informasi ke dalam Database.
Dekomposisi kerja "Pelaporan" Gambar 2 mendefinisikan tiga aktivitas internal, tiga entitas eksternal, dan dua penyimpanan data.
1) Pengumpulan data - pengumpulan informasi tentang komputer dan komponennya.
2) Validasi - memeriksa keakuratan data.
3) Laporan - menulis laporan tentang pekerjaan yang dilakukan.
Entitas eksternal: komponen, komputer, manajer.
Gudang data - Data tentang komputer dan komponen, data laporan.
Mengumpulkan informasi tentang komputer dan aksesori, lalu mengirimkannya untuk disimpan. Setelah itu, kami memeriksa keakuratan data, membuat laporan dan mengirimkannya kembali untuk disimpan ke gudang data pertama (Gambar 2), atau mengirim data laporan ke gudang data kedua (Gambar 2) dan kemudian mengirimkannya ke manajer untuk verifikasi.
Manajer memeriksa, membuat catatan, koreksi dan mengirimkan untuk pemeriksaan ulang. Setelah itu, laporan dikirim untuk disimpan sampai manajer diperiksa ulang.
Deskripsi diagram IDEF3
Dalam dekomposisi pekerjaan Pemeliharaan komputer (Gbr. 1), beberapa persimpangan didefinisikan yang menghubungkan satu atau beberapa pekerjaan, beberapa pekerjaan internal.
1) Perbaikan - merakit komputer dengan komponen prefabrikasi
2) Perakitan - mengembalikan komputer ke normal
3) Tingkatkan - pemutakhiran komputer
4) Komputer - produk setelah perakitan dan modernisasi
5) Kirim ke gudang - kirim ke penyimpanan setelah perbaikan (perakitan)
6) Diagnostik - pemeriksaan kinerja.
7) Laporan - informasi tentang pekerjaan yang dilakukan.
Persimpangan - Konektor:
1) J2 - semua tindakan dimulai pada waktu yang sama.
2) J6 - Persimpangan Pertemuan. Sebuah node yang mengumpulkan banyak panah menjadi satu, menunjukkan perlunya kondisi menyelesaikan pekerjaan-sumber panah untuk melanjutkan proses.
3) J7 - ditunjukkan bahwa kondisi ini tidak dapat dipenuhi secara bersamaan.
4) J9 - tindakan ini berakhir pada saat yang sama setelah laporan pekerjaan yang dilakukan dibuat.
Diagram IDEF3 menunjukkan bahwa persimpangan J2 memiliki dua panah bercabang untuk bekerja (membangun dan meningkatkan) yang dimulai pada waktu yang sama. Hanya setelah pekerjaan ini selesai, produk jadi (komputer) keluar, menghubungkan persimpangan J6. Setelah itu, ada sambungan di simpang J7, yang menunjukkan bahwa dua pekerjaan (pengiriman barang ke gudang dan diagnostik) tidak dapat dilakukan secara bersamaan. Setelah menyelesaikan pekerjaan sebelumnya, proses penyusunan laporan pekerjaan sedang berlangsung, yang dihubungkan oleh persimpangan J9.
Objektif:
- mempelajari prinsip-prinsip dasar metodologi IDEF0,
- membuat proyek baru di BPWin,
- pembentukan diagram konteks,
- membuat koneksi.
Menggambarkan sistem menggunakan IDEF0 disebut model fungsional. Model fungsional dimaksudkan untuk menggambarkan proses bisnis yang ada di mana bahasa alami dan bahasa grafis digunakan. Untuk menyampaikan informasi tentang sistem tertentu, sumber bahasa grafis adalah metodologi IDEF0 itu sendiri.
Metodologi IDEF0 mengatur konstruksi sistem diagram hierarkis - deskripsi tunggal dari fragmen sistem. Pertama, sistem secara keseluruhan dan interaksinya dengan dunia luar dijelaskan (diagram konteks), setelah itu dekomposisi fungsional dilakukan - sistem dibagi menjadi subsistem dan setiap subsistem dijelaskan secara terpisah (diagram dekomposisi). Kemudian setiap subsistem dipecah menjadi yang lebih kecil, dan seterusnya sampai tingkat detail yang diinginkan tercapai.
Setiap Bagan IDEF0 a berisi blok dan busur. Blok mewakili fungsi dari sistem yang disimulasikan. Busur menghubungkan blok bersama dan mewakili interaksi dan hubungan di antara mereka.
Blok fungsional (aktivitas) dalam diagram diwakili oleh persegi panjang yang mewakili proses, fungsi, atau tugas bernama yang terjadi dari waktu ke waktu dan memiliki hasil yang dapat dikenali. Nama pekerjaan harus dinyatakan dengan kata benda verbal yang menunjukkan suatu tindakan.
IDEF0 membutuhkan diagram untuk memiliki setidaknya tiga dan tidak lebih dari enam blok. Kendala ini menjaga kompleksitas diagram dan model pada tingkat yang dapat dibaca, dimengerti, dan dapat digunakan.
Setiap sisi blok memiliki tujuan yang spesifik dan terdefinisi dengan baik. Sisi kiri blok untuk input, bagian atas untuk kontrol, kanan untuk output, dan bagian bawah untuk mekanisme. Penunjukan ini mencerminkan prinsip-prinsip sistem tertentu: input diubah menjadi output, batas kontrol atau menentukan kondisi untuk melakukan konversi, mekanisme menunjukkan apa dan bagaimana kinerja suatu fungsi.
Blok di IDEF0 diatur dalam urutan kepentingan, seperti yang dipahami oleh pembuat diagram. Urutan relatif ini disebut dominasi. Dominasi dipahami sebagai pengaruh yang dimiliki satu blok terhadap blok lain dalam diagram. Misalnya, blok diagram yang paling dominan dapat berupa urutan fungsi pertama yang diperlukan, atau fungsi perencanaan atau kontrol yang memengaruhi semua fungsi lainnya.
Blok paling dominan biasanya terletak di sudut kiri atas grafik, dan paling tidak dominan di sudut kanan.
Susunan blok pada halaman mencerminkan definisi penulis tentang dominasi. Dengan demikian, topologi diagram menunjukkan fitur mana yang memiliki dampak terbesar pada fitur lainnya. Untuk menekankan hal ini, analis dapat memberi nomor ulang blok sesuai dengan urutan dominasinya. Urutan dominasi dapat ditunjukkan dengan angka yang ditempatkan di sudut kanan bawah setiap persegi panjang: 1 akan menunjukkan dominasi yang paling banyak, 2 akan menunjukkan yang berikutnya, dll.
Interaksi karya dengan dunia luar dan antar sesama digambarkan dalam bentuk anak panah, digambarkan dengan garis tunggal dengan anak panah di ujungnya. Panah mewakili beberapa jenis informasi dan diberi nama dengan kata benda.
Jenis panah
IDEF0 membedakan antara lima jenis panah.
pintu masuk- benda yang digunakan dan diubah oleh usaha untuk memperoleh suatu hasil (output). Diasumsikan bahwa karya tersebut mungkin tidak memiliki panah masuk. Panah entri digambar saat memasuki sisi kiri pekerjaan.
Kontrol-.informasi yang mengatur kegiatan pekerjaan. Biasanya, panah kontrol membawa informasi yang menunjukkan bahwa pekerjaan harus dilakukan. Setiap pekerjaan harus memiliki setidaknya satu panah kontrol, yang digambarkan memasuki bagian atas pekerjaan.
keluar- objek yang inputnya dikonversi. Setiap pekerjaan harus memiliki setidaknya satu panah keluar, yang digambar berasal dari tepi kanan pekerjaan.
Mekanisme- sumber daya yang melakukan pekerjaan. Panah mekanisme digambar saat memasuki tepi bawah pekerjaan. Pada kebijaksanaan analis, panah mekanisme mungkin tidak muncul pada model.
Panggilan- panah khusus yang menunjuk ke model kerja yang berbeda. Panah panggilan digambar sebagai berasal dari bagian bawah pekerjaan dan digunakan untuk menunjukkan bahwa beberapa pekerjaan sedang dilakukan di luar sistem yang disimulasikan.
Beras. 2.1 Jenis panah
Dalam metodologi IDEF0, hanya lima jenis interaksi antar blok yang diperlukan untuk menggambarkan hubungan mereka: kontrol, masukan, umpan balik kontrol, umpan balik masukan, mekanisme keluaran. Tautan kontrol dan input adalah yang paling sederhana karena mencerminkan tindakan langsung yang intuitif dan sangat sederhana.
Beras. 2.2. Keluar dari komunikasi
Beras. 2.3. komunikasi manajemen
Hubungan kontrol terjadi ketika output dari satu blok secara langsung mempengaruhi blok yang kurang dominan.
Umpan balik kontrol dan umpan balik masukan lebih kompleks karena merupakan iterasi atau rekursi. Yaitu, output dari satu pekerjaan mempengaruhi kinerja pekerjaan lain di masa depan, yang selanjutnya akan mempengaruhi pekerjaan aslinya.
Umpan balik manajemen terjadi kemudian; ketika output dari beberapa blok mempengaruhi blok dengan dominasi besar.
Hubungan mekanisme keluar jarang terjadi. Mereka mencerminkan situasi di mana output dari satu fungsi menjadi sarana untuk mencapai tujuan yang lain.
Beras. 2.4. Masukan Umpan Balik
Beras. 2.5. Umpan balik manajemen
Hubungan mekanisme keluar umum terjadi dalam alokasi sumber daya (misalnya alat yang dibutuhkan, personel terlatih, ruang fisik, peralatan, pendanaan, bahan).
Dalam IDEF0, busur jarang menggambarkan satu objek. Biasanya melambangkan kumpulan benda. Karena busur mewakili kumpulan fitur, mereka dapat memiliki beberapa titik awal (sumber) dan titik akhir (tujuan). Oleh karena itu, busur dapat bercabang dan terhubung. cara yang berbeda... Seluruh busur atau bagiannya dapat muncul dari satu atau lebih balok dan berakhir di satu atau lebih balok.
Busur bercabang, ditampilkan sebagai garis divergen, berarti bahwa semua atau sebagian isi busur dapat muncul di setiap cabang. Busur selalu ditandai sebelum forking untuk memberi nama pada seluruh set. Selain itu, setiap cabang busur dapat ditandai atau tidak ditandai menurut aturan berikut:
- cabang yang tidak ditandai berisi berat objek yang ditentukan dalam label busur sebelum cabang;
- cabang yang ditandai setelah titik bifurkasi berisi semua atau sebagian dari objek yang ditentukan dalam label busur sebelum bifurkasi.
Penggabungan busur di IDEFO, digambarkan sebagai garis yang menyatu, menunjukkan bahwa isi setiap cabang membentuk label untuk busur yang dihasilkan dari penggabungan busur asli. Setelah penggabungan, busur yang dihasilkan selalu ditandai untuk menunjukkan serangkaian fitur baru setelah penggabungan. Selain itu, setiap cabang mungkin atau mungkin tidak ditandai sebelum digabungkan sesuai dengan aturan berikut:
Beras. 2.6. Komunikasi mekanisme keluaran
- cabang yang tidak ditandai berisi bobot objek yang ditentukan dalam label bersama setelah penggabungan;
- cabang yang ditandai sebelum penggabungan berisi semua atau beberapa objek yang tercantum dalam tanda umum setelah penggabungan,
Analisis kuantitatif grafik
Untuk melakukan analisis kuantitatif diagram, kami mencantumkan indikator model:
- jumlah balok dalam diagram - N;
- grafik tingkat dekomposisi - L;
- diagram keseimbangan - V;
- jumlah panah yang menghubungkan ke blok - SEBUAH
Kumpulan faktor ini berlaku untuk setiap diagram dalam model. Rekomendasi untuk nilai yang diinginkan dari faktor grafik akan dicantumkan di bawah ini.
Perlu diupayakan untuk memastikan bahwa jumlah blok pada diagram tingkat yang lebih rendah akan lebih rendah daripada jumlah blok pada diagram induk, yaitu, dengan peningkatan tingkat dekomposisi, koefisien akan berkurang. Dengan demikian, penurunan koefisien ini menunjukkan bahwa. bahwa ketika model didekomposisi, fungsinya harus disederhanakan, oleh karena itu, jumlah blok harus berkurang.
Grafik harus seimbang. Ini berarti bahwa dalam kerangka satu diagram, situasi yang digambarkan pada Gambar. 2.7: pekerjaan 1 memiliki panah masuk dan kontrol yang jauh lebih banyak daripada panah keluar. Perlu dicatat bahwa rekomendasi ini mungkin tidak diikuti dalam model yang menggambarkan proses produksi. Misalnya, ketika menjelaskan prosedur perakitan, sebuah blok dapat mencakup banyak panah yang menggambarkan komponen produk, dan satu panah mungkin keluar - produk jadi.
Beras. 2.7. Contoh grafik tidak seimbang
Mari kita perkenalkan faktor keseimbangan dari diagram
Perlu berusaha untuk Khu adalah minimal untuk grafik.
Selain analisis elemen grafis diagram perlu mempertimbangkan nama-nama blok. Untuk mengevaluasi nama, kamus fungsi dasar (sepele) dari sistem yang dimodelkan dikompilasi. Bahkan, fungsi yang lebih rendah, tingkat dekomposisi diagram harus masuk ke kamus ini. Misalnya, untuk model database, fungsi "menemukan catatan", "menambahkan catatan ke database" dapat menjadi dasar, sedangkan fungsi "pendaftaran pengguna" memerlukan deskripsi lebih lanjut.
Setelah membentuk kosakata dan menyusun paket diagram sistem, perlu untuk mempertimbangkan tingkat model yang lebih rendah. Jika ada kebetulan nama blok diagram dan kata-kata dari kamus di atasnya, maka ini menunjukkan bahwa tingkat dekomposisi yang memadai telah tercapai. Koefisien yang secara kuantitatif mencerminkan kriteria ini dapat ditulis sebagai L * C - produk tingkat model dengan jumlah kecocokan nama blok dengan kata-kata dari kamus. Semakin rendah tingkat model (lebih tinggi L), semakin berharga kebetulan.
Perangkat BPWin
Ketika BPWin diluncurkan, toolbar utama, palet alat dan Model Explorer muncul secara default.
Saat membuat model baru, sebuah dialog muncul di mana Anda harus menunjukkan apakah model akan dibuat baru, atau akan dibuka dari repositori ModelMart, masukkan nama model dan pilih metodologi di mana model akan dibangun ( Gambar 2.8).
Gambar 2.8 Dialog pembuatan model
BPWin mendukung tiga metodologi - IDEF0, IDEF3 dan DFD. Di BPWin, dimungkinkan untuk membangun model campuran, yaitu model dapat berisi diagram IDEF0 dan IDEF3 dan DFD secara bersamaan. Komposisi palet alat berubah secara otomatis saat beralih dari satu notasi ke notasi lainnya.
Model di BPWin dipandang sebagai kumpulan aktivitas, yang masing-masing beroperasi pada kumpulan data tertentu. Jika Anda mengklik objek model apa pun dengan tombol kiri mouse, menu konteks pop-up muncul, setiap item yang sesuai dengan editor properti objek.
Contoh
Membangun model sistem harus dimulai dengan mempelajari semua dokumen yang menjelaskannya. Kegunaan... Salah satu dokumen tersebut adalah kerangka acuan, yaitu bagian "Tujuan pengembangan", "Tujuan dan sasaran sistem" dan " Karakteristik fungsional sistem".
Setelah mempelajari dokumen sumber dan mewawancarai pelanggan dan pengguna sistem, maka perlu merumuskan tujuan pemodelan dan menentukan sudut pandang model. Mari kita pertimbangkan teknologi konstruksinya menggunakan contoh sistem "Layanan Ketenagakerjaan di Universitas", kemampuan utamanya dijelaskan dalam pekerjaan laboratorium No. 1.
Mari kita rumuskan tujuan pemodelan: untuk menggambarkan fungsi sistem, yang dapat dipahami oleh penggunanya, tanpa merinci implementasinya. Kami akan membangun model dari sudut pandang pengguna (siswa, guru, administrator, kantor dekan, perusahaan).
Mari kita mulai dengan membangun diagram IDEF0 kontekstual - Menurut deskripsi sistem, fungsi utamanya adalah melayani pelanggannya dengan memproses permintaan dari mereka. Jadi, mari kita definisikan satu-satunya pekerjaan diagram konteks sebagai "Layani klien sistem". Selanjutnya, kami mendefinisikan data input dan output, serta mekanisme dan kontrol.
Untuk melayani klien, perlu mendaftarkannya di sistem, membuka akses ke database, dan memproses permintaannya. Data input akan menjadi "nama klien", "kata sandi klien", "database sumber", "permintaan klien". Eksekusi kueri mengarah pada penerimaan informasi dari sistem, atau mengubah konten basis data (misalnya, saat menyusun penilaian ahli), oleh karena itu, data keluaran akan menjadi "laporan" dan "basis data yang dimodifikasi". Proses permintaan pemrosesan akan dilakukan oleh monitor sistem di bawah kendali administrator.
Diagram konteks
Jadi, kami mendefinisikan diagram konteks sistem (Gbr. 2.9).
Gambar 2.9. Diagram konteks sistem
Mari kita menguraikan diagram konteks, menggambarkan urutan layanan pelanggan:
- Menentukan tingkat akses ke sistem.
- Pemilihan subsistem.
- Akses subsistem.
- Mengubah database (jika perlu).
Kami mendapatkan diagram yang ditunjukkan pada Gambar. 2.10.
Setelah menyelesaikan dekomposisi diagram konteks, lanjutkan ke dekomposisi diagram level berikutnya. Biasanya, saat melihat level ketiga dan yang lebih rendah, model kembali ke diagram induk dan menyesuaikannya.
Beras. 2.10. Dekomposisi pekerjaan "Layanan, klien sistem"
Kami menguraikan semua blok diagram yang dihasilkan secara berurutan. Langkah pertama dalam menentukan tingkat akses ke sistem adalah menentukan kategori pengguna. Nama klien dicari di basis pengguna, menentukan kategorinya. Menurut kategori tertentu, otorisasi yang diberikan kepada pengguna sistem diklarifikasi. Selanjutnya dilakukan prosedur pengaksesan sistem, pengecekan nama akses dan password. Dengan menggabungkan informasi tentang otoritas dan tingkat akses ke sistem, serangkaian tindakan yang diizinkan dibentuk untuk pengguna. Dengan demikian, definisi tingkat akses ke sistem akan terlihat seperti yang ditunjukkan pada Gambar. 2.11.
Beras. 2.11. Dekomposisi pekerjaan "Menentukan tingkat akses ke sistem"
Setelah melalui prosedur untuk mengakses sistem, monitor menganalisis permintaan klien, memilih subsistem yang akan memproses permintaan tersebut. Penguraian karya "Mengatasi Subsistem" tidak sesuai dengan tujuan dan sudut pandang model. Pengguna sistem tidak tertarik dengan algoritma internal operasinya. Dalam hal ini, penting baginya bahwa pilihan subsistem akan dibuat secara otomatis, tanpa intervensinya, oleh karena itu penguraian panggilan ke subsistem hanya akan memperumit model.
Mari kita menguraikan pekerjaan "Pemrosesan permintaan klien" yang dilakukan oleh subsistem pemrosesan permintaan, menentukan kategori dan izin pengguna. Sebelum mencari jawaban atas permintaan, Anda harus membuka database (menghubungkannya). Secara umum, database dapat ditempatkan di server jauh, jadi mungkin perlu untuk membuat koneksi ke sana. Mari kita tentukan urutan pekerjaan:
- Membuka basis data.
- Melaksanakan permintaan.
- Pembuatan laporan.
Setelah membuka database, perlu untuk menginformasikan sistem tentang pembentukan koneksi dengan database, kemudian mengeksekusi permintaan dan menghasilkan laporan untuk pengguna (Gbr. 2.12).
Perlu dicatat bahwa "Eksekusi permintaan" mencakup pekerjaan berbagai subsistem. Misalnya, jika permintaan termasuk pengujian, maka itu akan dieksekusi oleh subsistem tes profesional dan psikologis. Pada tahap eksekusi kueri, mungkin perlu mengubah konten database, misalnya, saat menyusun penilaian ahli. Oleh karena itu, diagram harus menyediakan kemungkinan seperti itu.
Beras. 2.12.
Menyesuaikan grafik
Saat menganalisis diagram yang dihasilkan, muncul pertanyaan, apa aturan untuk menghasilkan laporan? Penting untuk memiliki templat yang telah dibentuk sebelumnya, yang dengannya pemilihan dari database akan dilakukan, dan templat ini harus sesuai dengan permintaan dan harus ditentukan sebelumnya. Selain itu, klien harus diberi kesempatan untuk memilih bentuk laporan.
Mari perbaiki diagram dengan menambahkan panah "Templat laporan" dan "Permintaan untuk mengubah database" dan panah terowongan "Klien sistem" ke dalamnya. Tunneling dari "System Client" diterapkan agar tidak menempatkan panah di diagram atas, karena fungsi memilih formulir laporan tidak cukup penting untuk ditampilkan pada diagram induk.
Mengubah diagram akan menyebabkan penyesuaian semua diagram induk (Gbr. 2.13 - 2.15).
Dianjurkan untuk menguraikan pekerjaan "Eksekusi kueri" menggunakan diagram DFD (pekerjaan laboratorium No. 3), karena metodologi IDEF0 menganggap sistem sebagai serangkaian pekerjaan yang saling terkait, yang dengan buruk mencerminkan proses pemrosesan informasi.
Beras. 2.13. Dekomposisi pekerjaan "Pemrosesan permintaan klien"
Beras. 2.14. Dekomposisi pekerjaan "Layanan klien sistem" (opsi 2)
Beras. 2.15. Diagram konteks sistem (opsi 2)
Mari kita beralih ke dekomposisi blok terakhir "Perubahan basis data". Dari sudut pandang klien, sistem ini terletak dalam satu database. Sebenarnya ada enam database dalam sistem:
- basis data pengguna,
- DB siswa, (pilihan 2)
- DB lowongan,
- Basis data kinerja,
- DB tes,
- DB penilaian ahli,
- ringkasan DB.
Menurut tujuan pemodelan, penting bagi klien untuk memahami bahwa data yang diterima tidak segera diperbarui dalam sistem, tetapi melalui tahap pemrosesan dan kontrol tambahan. Algoritma perubahan dapat dirumuskan sebagai berikut:
- Basis data di mana informasi akan berubah ditentukan.
- Operator membentuk kumpulan data sementara dan memberikannya kepada administrator.
- Administrator mengontrol data dan memasukkannya ke dalam database.
Model ini dapat diimplementasikan dengan cara yang berbeda, menyediakan kemampuan untuk memperbarui database secara langsung berdasarkan permintaan, melewati proses kontrol data. Dalam hal ini, perlu untuk memastikan kontrol integritas database untuk menghindari kerusakan padanya. Dalam hal ini, diagram akan terlihat seperti ini (Gbr. 2.17).
Beras. 2.16. Dekomposisi pekerjaan "Perubahan basis data"
Beras. 2.17. Dekomposisi pekerjaan "Perubahan basis data" (opsi 2) Untuk opsi pertama, ditunjukkan pada Gambar. 2.12
Melakukan dekomposisi lebih lanjut dari "Perubahan Basis Data" akan memperumit model, menjelaskan bagaimana perubahan fisik basis data dalam sistem dilakukan. Dalam hal ini, pengguna tidak akan menerima informasi tambahan pada sistem kerja pelayanan ketenagakerjaan. Disarankan untuk menguraikan pekerjaan ini dalam proses perancangan sistem basis data pada tahap pembuatan model basis data logis.
Penguraian pekerjaan Eksekusi Query akan dilakukan di lab berikutnya, menggambarkan penggunaan diagram DFD untuk menggambarkan proses pemrosesan informasi.
Kami akan melaksanakan Analisis kuantitatif model yang ditunjukkan pada gambar. 2.12 dan 2.13, menurut prosedur di atas. Mari kita perhatikan perilaku koefisien ^ untuk model-model ini. Diagram induk "Pemrosesan permintaan klien" memiliki koefisien 4/2 = 2, dan diagram dekomposisi adalah 3/3 = 1. Nilai koefisien menurun, yang menunjukkan penyederhanaan deskripsi fungsi dengan penurunan tingkat model.
Pertimbangkan perubahan koefisien K b dalam dua varian model.
untuk opsi kedua
Koefisien K b tidak mengubah nilainya, oleh karena itu, keseimbangan diagram tidak berubah.
Kami akan berasumsi bahwa tingkat dekomposisi diagram yang dipertimbangkan cukup untuk mencerminkan tujuan pemodelan, dan fungsi dasar (dari sudut pandang pengguna sistem) digunakan sebagai judul pekerjaan pada diagram Tingkat yang lebih rendah .
Menyimpulkan contoh yang dipertimbangkan, perlu dicatat pentingnya mempertimbangkan beberapa opsi untuk diagram saat memodelkan suatu sistem. Varian seperti itu mungkin muncul saat menyesuaikan diagram, seperti yang dilakukan dengan "Memproses permintaan klien" atau saat membuat implementasi alternatif dari fungsi sistem (penguraian pekerjaan "Memodifikasi database"). Pertimbangan opsi memungkinkan Anda untuk memilih yang terbaik dan memasukkannya ke dalam paket diagram untuk pertimbangan lebih lanjut.
Kontrol pertanyaan
Daftar pertanyaan tes:
- Apa yang dimaksud dengan model dalam notasi IDEF0?
- Apa yang dimaksud dengan pekerjaan IDEF0?
- Bagaimana urutan penamaan karya?
- Berapa banyak pekerjaan yang harus ada dalam satu diagram?
- Apa yang disebut ordo dominasi?
- Bagaimana karya-karya tersebut disusun menurut prinsip dominasi?
- Apa tujuan dari sisi-sisi persegi panjang yang bekerja dalam diagram?
- Sebutkan jenis-jenis anak panah!
- Apa saja jenis-jenis hubungan.
- Apa itu panah batas?
- Jelaskan konvensi penamaan untuk panah bercabang dan penggabungan.
- Metodologi apa yang didukung oleh BPWin?
- Daftar elemen utama dari jendela utama BPWin.
- Jelaskan proses pembuatan model baru di BPWin.
- Bagaimana cara membuat hubungan antar karya?
- Cara mengatur nama pekerjaan.
- Menjelaskan proses pemecahan pekerjaan.
- Bagaimana cara menambahkan pekerjaan ke diagram?
- Bagaimana cara mengatasi panah terowongan?
- Bisakah model BPWin berisi diagram berbagai metodologi?
Tahukah kamu,
apa itu eksperimen pikiran, eksperimen gedanken?
Ini adalah praktik yang tidak ada, pengalaman dunia lain, imajinasi tentang apa yang tidak ada dalam kenyataan. Eksperimen pikiran seperti mimpi yang terjaga. Mereka melahirkan monster. Tidak seperti eksperimen fisik, yang merupakan uji eksperimental hipotesis, "eksperimen pikiran" dengan licik menggantikan verifikasi eksperimental dengan kesimpulan praktik yang diinginkan dan belum diuji, memanipulasi konstruksi logis yang sebenarnya melanggar logika itu sendiri dengan menggunakan premis yang belum terbukti sebagai yang terbukti, yaitu dengan pengganti. Dengan demikian, tugas utama pelamar untuk "eksperimen pikiran" adalah menipu pendengar atau pembaca dengan mengganti eksperimen fisik nyata dengan "bonekanya" - penalaran fiktif tentang pembebasan bersyarat tanpa verifikasi fisik itu sendiri.
Mengisi fisika dengan imajiner, "eksperimen pikiran" menyebabkan munculnya gambaran dunia yang surealis, membingungkan, dan membingungkan. Seorang peneliti sejati harus membedakan "bungkus permen" seperti itu dari nilai sebenarnya.
Relativis dan positivis berpendapat bahwa "eksperimen pikiran" adalah alat yang sangat berguna untuk menguji teori (juga muncul dalam pikiran kita) untuk konsistensi. Dalam hal ini mereka menipu orang, karena verifikasi apa pun hanya dapat dilakukan oleh sumber yang tidak bergantung pada objek verifikasi. Pemohon hipotesis itu sendiri tidak dapat menguji pernyataannya sendiri, karena alasan pernyataan ini sendiri adalah tidak adanya kontradiksi dalam pernyataan yang terlihat oleh pemohon.
Hal ini kita lihat pada contoh SRT dan GRT yang telah berubah menjadi semacam agama yang mengatur ilmu pengetahuan dan opini publik... Tidak ada fakta yang bertentangan dengan mereka yang dapat mengatasi rumus Einstein: "Jika fakta tidak sesuai dengan teori, ubah fakta" (Dalam versi lain, "- Fakta tidak sesuai dengan teori? - Lebih buruk lagi untuk fakta").
Maksimum yang dapat diklaim oleh "eksperimen pikiran" hanyalah konsistensi internal hipotesis dalam kerangka logika pemohon sendiri, sering kali tidak benar. Ini tidak menguji kesesuaian latihan. Tes ini hanya dapat dilakukan dalam eksperimen fisik yang valid.
Eksperimen adalah eksperimen yang bukan merupakan penyempurnaan pemikiran, tetapi pengujian pemikiran. Pikiran yang konsisten dengan dirinya sendiri tidak dapat memverifikasi dirinya sendiri. Hal ini dibuktikan oleh Kurt Gödel.
Gennady Vernikov
Saat ini, di Rusia, minat pada standar manajemen yang diterima secara umum di Barat telah meningkat tajam, namun, dalam praktik manajemen nyata, ada satu momen yang sangat indikatif. Banyak pemimpin masih bingung dengan pertanyaan langsung tentang struktur organisasi perusahaan atau tentang skema proses bisnis yang ada. Manajer paling maju yang secara teratur membaca majalah ekonomi, sebagai suatu peraturan, mulai menggambar diagram hierarkis yang hanya dapat dipahami oleh mereka, tetapi bahkan dalam proses ini mereka biasanya dengan cepat menemui jalan buntu. Hal yang sama berlaku untuk karyawan dan manajer dari berbagai layanan dan unit fungsional. Dalam kebanyakan kasus, satu-satunya aturan yang ditetapkan sesuai dengan mana perusahaan harus beroperasi adalah seperangkat ketentuan individu dan Deskripsi pekerjaan... Paling sering, dokumen-dokumen ini dibuat lebih dari satu tahun yang lalu, tidak terstruktur dengan baik dan tidak saling berhubungan dan, sebagai akibatnya, hanya mengumpulkan debu di rak. Untuk saat ini, pendekatan seperti itu dibenarkan, karena selama pembentukan ekonomi pasar Rusia, konsep persaingan praktis tidak ada, dan tidak ada kebutuhan khusus untuk mempertimbangkan biaya - keuntungannya sangat besar. Sebagai hasilnya, kami telah melihat gambaran yang cukup dapat dimengerti selama dua tahun terakhir: perusahaan besar yang tumbuh di awal 90-an, secara bertahap kehilangan posisi mereka, hingga penarikan total dari pasar. Ini sebagian disebabkan oleh fakta bahwa perusahaan tidak menerapkan standar manajemen, konsep model fungsional kegiatan dan misi sama sekali tidak ada. Dengan bantuan pemodelan berbagai bidang kegiatan, adalah mungkin untuk secara efektif menganalisis "kemacetan" dalam manajemen dan mengoptimalkan skema bisnis secara keseluruhan. Tetapi, seperti yang Anda ketahui, di perusahaan mana pun, hanya proyek-proyek yang secara langsung mendatangkan keuntungan yang menjadi prioritas tertinggi, oleh karena itu, biasanya hanya selama krisis nyata dalam manajemen perusahaan yang kita bicarakan tentang survei kegiatan dan dampaknya. reorganisasi.
Pada akhir tahun 90-an, ketika pasar cukup kompetitif dan profitabilitas perusahaan mulai turun tajam, para manajer merasakan kesulitan besar dalam mencoba mengoptimalkan biaya sehingga produk tetap menguntungkan dan kompetitif. Tepat pada saat ini, kebutuhan untuk memiliki model aktivitas perusahaan di depan mata Anda, yang akan mencerminkan semua mekanisme dan prinsip interkoneksi berbagai subsistem dalam kerangka satu bisnis, dimanifestasikan dengan jelas.
Konsep "pemodelan proses bisnis" datang ke dalam kehidupan sehari-hari sebagian besar analis bersamaan dengan kemunculan di pasar produk perangkat lunak kompleks yang dirancang untuk otomatisasi terintegrasi manajemen perusahaan. Sistem seperti itu selalu menyiratkan survei pra-proyek yang mendalam terhadap kegiatan perusahaan. Hasil survei ini adalah pendapat ahli, di mana paragraf individu dibuat rekomendasi untuk menghilangkan "kemacetan" dalam pengelolaan kegiatan. Atas dasar kesimpulan ini, segera sebelum penerapan sistem otomasi, apa yang disebut reorganisasi proses bisnis dilakukan, terkadang cukup serius dan menyakitkan bagi perusahaan. Ini, dan tentu saja, tim yang telah berkembang selama bertahun-tahun selalu sulit untuk dipaksa "berpikir dengan cara baru". Survei perusahaan yang kompleks seperti itu selalu kompleks dan berbeda secara signifikan dari kasus ke tugas kasus. Ada metodologi dan standar yang dicoba dengan baik untuk memecahkan masalah seperti itu dalam pemodelan sistem yang kompleks. Standar ini mencakup metodologi keluarga IDEF. Dengan bantuan mereka, dimungkinkan untuk secara efektif menampilkan dan menganalisis model aktivitas berbagai sistem kompleks di berbagai bagian. Pada saat yang sama, luas dan kedalaman pemeriksaan proses dalam sistem ditentukan oleh pengembang itu sendiri, yang memungkinkan untuk tidak membebani model yang dibuat dengan data yang tidak perlu. Saat ini, standar berikut dapat dikaitkan dengan keluarga IDEF:
IDEF0 adalah metodologi pemodelan fungsional. Dengan bantuan bahasa grafis visual IDEF0, sistem yang sedang dipelajari muncul kepada pengembang dan analis dalam bentuk seperangkat fungsi yang saling terkait (blok fungsional - dalam hal IDEF0). Biasanya, pemodelan IDEF0 adalah langkah pertama dalam mempelajari sistem apa pun;
IDEF1 adalah metodologi untuk memodelkan arus informasi dalam sistem, yang memungkinkan Anda untuk menampilkan dan menganalisis struktur dan hubungan mereka;
IDEF1X (IDEF1 Extended) adalah metodologi untuk membangun struktur relasional. IDEF1X adalah jenis metodologi Entity-Relationship (ER) dan biasanya digunakan untuk memodelkan database relasional yang relevan dengan sistem yang bersangkutan;
IDEF2 adalah metodologi untuk pemodelan dinamis pengembangan sistem. Karena kesulitan yang sangat serius dalam menganalisis sistem dinamis, standar ini praktis ditinggalkan, dan pengembangannya dihentikan pada tahap paling awal. Namun, saat ini ada algoritma dan implementasi komputernya yang memungkinkan untuk mengubah satu set diagram IDEF0 statis menjadi model dinamis berdasarkan "jaring Petri berwarna" (CPN - Jaring Petri Warna);
IDEF3 adalah metodologi untuk mendokumentasikan proses yang terjadi dalam sistem, yang digunakan, misalnya, dalam penelitian proses teknologi di perusahaan. IDEF3 menjelaskan skenario dan alur kerja untuk setiap proses. IDEF3 memiliki hubungan langsung dengan metodologi IDEF0 - setiap fungsi (blok fungsional) dapat direpresentasikan sebagai proses terpisah melalui IDEF3;
IDEF4 adalah metodologi untuk membangun sistem berorientasi objek. Alat IDEF4 memungkinkan Anda untuk secara visual menampilkan struktur objek dan prinsip-prinsip yang mendasari interaksi mereka, sehingga memungkinkan Anda untuk menganalisis dan mengoptimalkan sistem berorientasi objek yang kompleks;
IDEF5 adalah metodologi untuk studi ontologis dari sistem yang kompleks. Menggunakan metodologi IDEF5, ontologi suatu sistem dapat dijelaskan menggunakan kosakata istilah dan aturan tertentu, atas dasar pernyataan yang dapat diandalkan tentang keadaan sistem yang sedang dipertimbangkan pada titik waktu tertentu dapat dibentuk. Atas dasar pernyataan-pernyataan ini, kesimpulan tentang pengembangan lebih lanjut dari sistem dibentuk dan dilakukan optimasi.
Pada artikel ini, kita akan melihat metodologi pemodelan fungsional yang paling umum digunakan IDEF0.
Sejarah standar IDEF0
Metodologi IDEF0 dapat dianggap sebagai tahap berikutnya dalam pengembangan bahasa grafis terkenal untuk menggambarkan sistem fungsional SADT (Teknik Analisis dan Desain Terstruktur). Beberapa tahun yang lalu, edisi kecil buku dengan nama yang sama diterbitkan di Rusia, yang dikhususkan untuk menjelaskan prinsip-prinsip dasar pembuatan diagram SADT. Secara historis, IDEF0 sebagai standar dikembangkan pada tahun 1981 sebagai bagian dari program otomasi industri ekstensif yang disebut ICAM (Integrated Computer Aided Manufacturing) dan diusulkan oleh Angkatan Udara AS. Keluarga standar IDEF sendiri mewarisi penunjukannya dari nama program ini (IDEF = ICAM DEFINition). Dalam proses implementasi praktis, peserta program ICAM dihadapkan pada kebutuhan untuk mengembangkan metode baru untuk menganalisis proses interaksi dalam sistem industri. Pada saat yang sama, selain serangkaian fungsi yang ditingkatkan untuk menggambarkan proses bisnis, salah satu persyaratan untuk standar baru adalah ketersediaan metodologi yang efektif untuk interaksi dalam kerangka "ahli analis". Dengan kata lain, metode baru seharusnya memberikan kerja kelompok dalam pembuatan model, dengan partisipasi langsung dari semua analis dan spesialis yang terlibat dalam proyek.
Sebagai hasil dari pencarian solusi yang tepat, metodologi pemodelan fungsional IDEF0 lahir. Sejak 1981, standar IDEF0 telah mengalami beberapa perubahan kecil, sebagian besar bersifat membatasi, dan revisi terakhirnya dirilis pada Desember 1993 oleh Institut Nasional untuk Standar dan Teknologi AS (NIST).
Elemen dasar dan konsep IDEF0
Bahasa grafis IDEF0 ternyata sangat sederhana dan harmonis. Metodologi ini didasarkan pada empat konsep utama.
Yang pertama adalah konsep Activity Box. Sebuah blok fungsional secara grafis digambarkan dalam bentuk persegi panjang (lihat Gambar 1) dan mempersonifikasikan beberapa fungsi tertentu dalam kerangka sistem yang sedang dipertimbangkan. Menurut persyaratan standar, nama setiap blok fungsional harus dirumuskan dalam suasana kata kerja (misalnya, "menghasilkan layanan", bukan "memproduksi layanan").
Masing-masing dari empat sisi blok fungsional memiliki arti (peran) spesifiknya sendiri, sedangkan:
Setiap blok fungsional dalam kerangka satu sistem yang dipertimbangkan harus memiliki nomor identifikasi uniknya sendiri.
Gambar 1. Blok fungsional.
"Paus" kedua dari metodologi IDEF0 adalah konsep busur antarmuka (Panah). Juga, busur antarmuka sering disebut aliran atau panah. Busur antarmuka menampilkan elemen sistem yang diproses oleh blok fungsi atau memengaruhi fungsi yang ditampilkan oleh blok fungsi ini.
Tampilan grafis dari busur antarmuka adalah panah searah. Setiap busur antarmuka harus memiliki nama uniknya sendiri (Label Panah). Seperti yang disyaratkan oleh standar, nama harus berupa pergantian kata benda.
Dengan bantuan busur antarmuka, berbagai objek ditampilkan yang, pada tingkat tertentu, menentukan proses yang terjadi dalam sistem. Objek tersebut dapat berupa elemen dunia nyata (suku cadang, mobil, karyawan, dll.) atau aliran data dan informasi (dokumen, data, instruksi, dll.).
Bergantung pada sisi mana busur antarmuka ini cocok, ini disebut "masuk", "keluar" atau "kontrol". Selain itu, hanya blok fungsional yang dapat menjadi "sumber" (awal) dan "sink" (akhir) dari setiap busur fungsional, sedangkan "sumber" hanya dapat menjadi sisi keluaran blok, dan "sink" dapat berupa apa saja. dari tiga yang tersisa.
Perlu dicatat bahwa setiap blok fungsional, sesuai dengan persyaratan standar, harus memiliki setidaknya satu busur antarmuka kontrol dan satu busur keluar. Ini dapat dimengerti - setiap proses harus mengikuti beberapa aturan (ditampilkan oleh busur kontrol) dan harus menghasilkan beberapa hasil (busur keluar), jika tidak, tidak masuk akal untuk mempertimbangkannya.
Saat membangun IDEF0 - diagram, penting untuk memisahkan dengan benar busur antarmuka yang masuk dari busur kontrol, yang seringkali tidak mudah. Misalnya, gambar 2 menunjukkan blok fungsi "Proses benda kerja".
Dalam proses nyata, pekerja yang melakukan pemrosesan diberikan benda kerja dan instruksi teknologi untuk pemrosesan (atau aturan keselamatan saat bekerja dengan mesin). Tampaknya keliru bahwa benda kerja dan dokumen dengan instruksi teknologi adalah objek yang masuk, tetapi sebenarnya tidak demikian. Sebenarnya, dalam proses ini, benda kerja diproses sesuai dengan aturan yang tercermin dalam instruksi teknologi, yang masing-masing harus ditampilkan oleh busur antarmuka kontrol.
Gambar 2.
Ini masalah lain ketika instruksi teknologi diproses oleh kepala teknolog dan perubahan dibuat untuk mereka (Gbr. 3). Dalam hal ini, mereka ditampilkan sebagai busur antarmuka yang sudah masuk, dan objek kontrol, misalnya, standar industri baru, berdasarkan mana perubahan ini dibuat.
Gambar 3.
Contoh di atas menekankan sifat yang tampaknya serupa dari busur antarmuka masuk dan keluar, tetapi selalu ada perbedaan tertentu untuk sistem dari kelas yang sama. Misalnya, dalam hal mempertimbangkan perusahaan dan organisasi, ada lima jenis objek utama: aliran material (suku cadang, barang, bahan mentah, dll.), Aliran keuangan (kas dan non tunai, investasi, dll.), Dokumen arus (dokumen komersial, keuangan dan organisasi), arus informasi (informasi, maksud, instruksi lisan, dll.) dan sumber daya (karyawan, mesin, mesin, dll.). Dalam hal ini, dalam berbagai kasus, semua jenis objek dapat ditampilkan oleh busur antarmuka masuk dan keluar, yang mengontrol hanya yang terkait dengan aliran dokumen dan informasi, dan hanya sumber daya yang dapat ditampilkan oleh mekanisme busur.
Kehadiran wajib busur antarmuka kontrol adalah salah satu perbedaan utama standar IDEF0 dari metodologi lain dari kelas DFD (Data Flow Diagram) dan WFD (Work Flow Diagram).
Konsep dasar ketiga dari standar IDEF0 adalah Decomposition. Prinsip dekomposisi digunakan ketika memecah proses kompleks menjadi fungsi-fungsi penyusunnya. Dalam hal ini, tingkat detail proses ditentukan langsung oleh pengembang model.
Dekomposisi memungkinkan Anda untuk secara bertahap dan terstruktur mewakili model sistem dalam bentuk struktur hierarkis diagram individu, yang membuatnya tidak terlalu padat dan mudah dicerna.
Model IDEF0 selalu dimulai dengan penyajian sistem secara keseluruhan - satu blok fungsional dengan busur antarmuka yang melampaui area yang dipertimbangkan. Diagram seperti itu dengan satu blok fungsional disebut diagram konteks, dan dilambangkan dengan pengidentifikasi "A-0".
Teks eksplanasi untuk diagram konteks harus menunjukkan Tujuan membangun diagram dalam bentuk Deskripsi singkat dan sudut pandang (Viewpoint) adalah tetap.
Mendefinisikan dan memformalkan tujuan pengembangan IDEF0 - modelnya sangat poin penting... Sebenarnya, tujuannya mengidentifikasi area yang relevan dalam sistem yang diteliti yang harus difokuskan terlebih dahulu. Misalnya, jika kita memodelkan aktivitas suatu perusahaan dengan tujuan membangun lebih lanjut berdasarkan model ini sistem Informasi, maka model ini akan berbeda secara signifikan dari model yang akan kami kembangkan untuk perusahaan yang sama, tetapi dengan tujuan untuk mengoptimalkan rantai pasokan.
Sudut pandang mendefinisikan arah utama pengembangan model dan tingkat detail yang diperlukan. Fiksasi sudut pandang yang jelas memungkinkan Anda untuk membongkar model, menolak untuk merinci dan mempelajari elemen individu yang tidak perlu, berdasarkan sudut pandang yang dipilih pada sistem. Misalnya, model fungsional dari perusahaan yang sama dari sudut pandang kepala teknologi dan direktur keuangan akan berbeda secara signifikan dalam arah perinciannya. Hal ini disebabkan fakta bahwa, pada akhirnya, CFO tidak tertarik pada aspek pemrosesan bahan baku pada mesin produksi, dan kepala teknolog tidak perlu menggambar skema arus keuangan. Pilihan sudut pandang yang benar secara signifikan mengurangi waktu yang dihabiskan untuk membangun model akhir.
Dalam proses dekomposisi, blok fungsional, yang dalam diagram konteks menampilkan sistem secara keseluruhan, dibor dalam diagram lain. Diagram tingkat kedua yang dihasilkan berisi blok fungsional yang menampilkan subfungsi utama dari blok fungsional diagram konteks dan disebut diagram Anak dalam kaitannya dengan itu (masing-masing blok fungsional milik diagram anak masing-masing disebut Kotak Anak) . Pada gilirannya, blok fungsi induk disebut blok induk dalam kaitannya dengan diagram anak (Kotak Induk), dan diagram tempatnya disebut diagram induk (Diagram Induk). Masing-masing sub-fungsi dari diagram anak dapat dirinci lebih lanjut dengan dekomposisi serupa dari blok fungsional yang sesuai. Penting untuk dicatat bahwa dalam setiap kasus dekomposisi blok fungsional, semua busur antarmuka yang termasuk dalam blok ini atau yang keluar darinya ditetapkan dalam diagram anak. Ini mencapai integritas struktural model IDEF0. Prinsip dekomposisi ditunjukkan dengan jelas pada Gambar 4. Perhatian harus diberikan pada hubungan antara penomoran blok fungsional dan diagram - setiap blok memiliki keunikannya sendiri. nomor seri pada diagram (angka di sudut kanan bawah persegi panjang), dan simbol di sudut kanan menunjukkan nomor diagram anak untuk blok ini. Tidak adanya penunjukan ini berarti tidak ada dekomposisi untuk blok ini.
Sering ada kasus ketika busur antarmuka individu tidak masuk akal untuk terus dipertimbangkan dalam diagram anak di bawah level tertentu dalam hierarki, atau sebaliknya - busur individu tidak memiliki arti praktis di atas level tertentu. Misalnya, busur antarmuka yang menggambarkan "detail" di pintu masuk ke "Proses aktif" mesin bubut"tidak masuk akal untuk merenungkan diagram di tingkat yang lebih tinggi - itu hanya akan membebani diagram dan membuatnya sulit untuk dipahami. Di sisi lain, menjadi perlu untuk menyingkirkan busur antarmuka "konseptual" yang terpisah dan tidak merincinya lebih dalam dari tingkat tertentu. Standar IDEF0 memberikan konsep tunneling. Penunjukan "terowongan" (Terowongan Panah) dalam bentuk dua tanda kurung di sekitar awal busur antarmuka berarti bahwa busur ini tidak diwarisi dari blok induk fungsional dan muncul (dari "terowongan") hanya dalam diagram ini. belok, penunjukan yang sama di sekitar ujung (panah) busur antarmuka di sekitar blok penerima berarti bahwa busur ini tidak akan ditampilkan dan dilihat pada anak diagram blok ini. busur antarmuka tidak dipertimbangkan pada beberapa tingkat hierarki menengah - termasuk Dalam hal ini, mereka pertama-tama "terjun ke dalam terowongan" dan kemudian, jika perlu, "kembali dari terowongan".
Konsep terakhir dalam IDEF0 adalah Glosarium. Untuk setiap elemen IDEF0: diagram, blok fungsional, busur antarmuka, standar yang ada menyiratkan pembuatan dan pemeliharaan serangkaian definisi, kata kunci, narasi, dll. yang relevan yang menjadi ciri objek yang ditampilkan oleh elemen ini. Himpunan ini disebut glosarium dan merupakan deskripsi esensi dari elemen ini. Misalnya, untuk busur antarmuka kontrol "pesanan pembayaran", glosarium dapat berisi daftar bidang dokumen yang sesuai dengan busur, set visa yang diperlukan, dll. Glosarium secara harmonis melengkapi bahasa grafis, memberikan diagram dengan informasi tambahan yang diperlukan.
Gambar 4. Dekomposisi blok fungsional.
Prinsip-prinsip membatasi kompleksitas diagram IDEF0
Biasanya, model IDEF0 membawa informasi yang kompleks dan terkonsentrasi, dan untuk membatasi kemacetannya dan membuatnya dapat dibaca, batas kompleksitas yang sesuai diadopsi dalam standar yang sesuai:
Membatasi jumlah blok fungsional pada diagram menjadi tiga hingga enam. Batas atas (enam) memaksa perancang untuk menggunakan hierarki saat menjelaskan item kompleks, dan batas bawah (tiga) memastikan bahwa ada cukup detail pada diagram yang sesuai untuk membenarkan pembuatannya;
Membatasi jumlah busur antarmuka yang cocok untuk satu blok fungsional (meninggalkan satu blok fungsional) menjadi empat.
Tentu saja, sama sekali tidak perlu untuk secara ketat mengikuti batasan ini, namun, seperti yang ditunjukkan oleh pengalaman, mereka sangat praktis dalam pekerjaan nyata.
Disiplin pekerjaan kelompok atas pengembangan model IDEF0
Standar IDEF0 berisi seperangkat prosedur yang memungkinkan sekelompok besar orang dari berbagai area sistem yang dimodelkan untuk mengembangkan dan menyepakati sebuah model. Biasanya, proses pengembangan bersifat iteratif dan terdiri dari tahapan kondisional berikut:
Pembuatan model oleh sekelompok spesialis yang terkait dengan berbagai bidang perusahaan. Grup ini disebut Penulis dalam istilah IDEF0. Membangun model awal adalah proses dinamis di mana penulis bertanya kepada orang yang kompeten tentang struktur berbagai proses. Berdasarkan ketentuan, dokumen dan hasil survey yang ada, maka dibuatlah Model Draft model tersebut.
Distribusi draf untuk ditinjau, disetujui, dan dikomentari. Pada tahap ini, draf model didiskusikan dengan berbagai orang yang kompeten (dalam hal pembaca IDEF0) di perusahaan. Dalam hal ini, setiap diagram dari draf model dikritik dan dikomentari secara tertulis, dan kemudian ditransfer ke penulis. Penulis, pada gilirannya, juga setuju secara tertulis dengan kritik atau menolaknya, menguraikan logika pengambilan keputusan dan mengembalikan draf yang direvisi untuk dipertimbangkan lebih lanjut. Siklus ini berlanjut sampai penulis dan pembaca mencapai konsensus.
Persetujuan model. Model yang disetujui disetujui oleh kepala kelompok kerja dalam hal penulis model dan pembaca tidak memiliki perbedaan pendapat tentang kecukupannya. Model terakhir adalah pandangan yang konsisten dari perusahaan (sistem) dari sudut pandang tertentu dan untuk tujuan tertentu.
Visibilitas bahasa grafis IDEF0 membuat model cukup mudah dibaca oleh orang-orang yang tidak mengambil bagian dalam proyek pembuatannya, serta efektif untuk mengadakan pertunjukan dan presentasi. Di masa depan, berdasarkan model yang dibangun, proyek-proyek baru dapat diatur yang bertujuan untuk membuat perubahan di perusahaan (dalam sistem).
Fitur praktik nasional menggunakan pemodelan fungsional melalui IDEF0
V tahun-tahun terakhir minat pada metodologi keluarga IDEF tumbuh dengan mantap di Rusia. Saya terus-menerus mengamati ini, melihat statistik panggilan ke halaman web pribadi saya (http://www.vernikov.ru), yang secara singkat menjelaskan prinsip-prinsip dasar standar ini. Pada saat yang sama, saya akan menyebut minat pada standar seperti IDEF3-5 teoretis, dan pada IDEF0 cukup praktis dibenarkan. Faktanya, Case-tools pertama yang memungkinkan untuk membuat diagram DFD dan IDEF0 muncul di pasar Rusia pada tahun 1996, bersamaan dengan rilis buku populer tentang prinsip-prinsip pemodelan dalam standar SADT.
Namun demikian, sebagian besar eksekutif masih menganggap penerapan praktis pemodelan dalam standar IDEF sebagai penghargaan terhadap mode, daripada cara yang efisien pengoptimalan sistem yang ada manajemen bisnis. Ini kemungkinan besar karena kurangnya informasi tentang aplikasi praktis metodologi ini dan dengan bias perangkat lunak yang sangat diperlukan dari sebagian besar publikasi.
Bukan rahasia lagi bahwa hampir semua proyek untuk survei dan analisis keuangan dan aktivitas ekonomi perusahaan sekarang di Rusia dalam satu atau lain cara terkait dengan konstruksi sistem otomatis pengelolaan. Karena itu, standar IDEF dalam pemahaman mayoritas secara kondisional menjadi tidak terpisahkan dari implementasi teknologi Informasi, meskipun dengan bantuan mereka kadang-kadang dimungkinkan untuk secara efektif menyelesaikan masalah lokal yang kecil sekalipun, secara harfiah dengan bantuan pensil dan kertas.
Saat melakukan proyek survei perusahaan yang kompleks, pengembangan model dalam standar IDEF0 memungkinkan Anda untuk secara visual dan efektif menampilkan seluruh mekanisme aktivitas perusahaan dalam konteks yang diinginkan. Namun, yang paling penting adalah kolaborasi yang disediakan IDEF0. di my kegiatan praktikum ada beberapa kasus ketika pembangunan model dilakukan dengan bantuan langsung dari karyawan dari berbagai departemen. Pada saat yang sama, konsultan menjelaskan kepada mereka prinsip-prinsip dasar IDEF0 dalam waktu yang cukup singkat dan mengajari mereka untuk bekerja dengan aplikasi yang sesuai. perangkat lunak... Akibatnya, karyawan dari berbagai departemen membuat diagram IDEF dari kegiatan unit fungsional mereka, yang menjawab pertanyaan-pertanyaan berikut:
Apa yang masuk ke unit "di pintu masuk"?
Fungsi apa, dan dalam urutan apa, yang dilakukan di dalam unit?
Siapa yang bertanggung jawab untuk masing-masing fungsi?
Apa yang dipandu oleh pelaksana ketika melakukan masing-masing fungsi?
Apa hasil kerja unit (output)?
Setelah menyetujui draf diagram dalam setiap departemen tertentu, mereka dikumpulkan oleh konsultan menjadi draf model perusahaan, di mana semua elemen input dan output dihubungkan. Pada tahap ini, semua perbedaan diagram individu dan tempat kontroversialnya dicatat. Selanjutnya, model ini kembali melewati departemen fungsional untuk persetujuan lebih lanjut dan membuat penyesuaian yang diperlukan. Alhasil, dalam waktu yang cukup singkat dan dengan daya tarik yang minim sumber daya manusia dari perusahaan konsultan (dan sumber daya ini, seperti yang Anda ketahui, sangat mahal), model IDEF0 dari suatu perusahaan diperoleh sesuai dengan prinsip "Apa adanya", dan, yang penting, itu mewakili perusahaan dari posisi karyawan yang bekerja di dalamnya dan benar-benar tahu semua nuansa, termasuk informal. Di masa depan, model ini akan ditransfer untuk analisis dan pemrosesan ke analis bisnis yang akan mencari hambatan dalam manajemen perusahaan dan mengoptimalkan proses utama, mengubah model "Apa Adanya" menjadi tampilan "Sebagaimana mestinya" yang sesuai. Berdasarkan perubahan tersebut, dibuat kesimpulan akhir, yang berisi rekomendasi untuk reorganisasi sistem manajemen.
Tentu saja, pendekatan semacam itu memerlukan sejumlah tindakan organisasi, terutama dari pihak manajemen perusahaan yang disurvei. Hal ini disebabkan oleh fakta bahwa teknik ini menyiratkan penugasan tanggung jawab tambahan kepada beberapa staf dalam penguasaan dan penerapan praktis metodologi baru. Namun, pada akhirnya, ini terbayar, karena tambahan satu atau dua jam kerja karyawan individu selama beberapa hari dapat secara signifikan menghemat uang untuk pembayaran layanan konsultasi ke perusahaan pihak ketiga (yang dalam hal apa pun akan terlepas dari pekerjaan karyawan yang sama dengan kuesioner dan pertanyaan). Adapun karyawan perusahaan itu sendiri, dalam satu atau lain cara, saya belum menemukan penentangan dari pihak mereka.
Kesimpulan dari semua ini dapat dilakukan sebagai berikut: sama sekali tidak perlu mencari solusi untuk masalah standar setiap saat. Setiap kali Anda dihadapkan dengan kebutuhan untuk menganalisis sistem fungsional tertentu (dari sistem desain pesawat ruang angkasa hingga proses menyiapkan makan malam yang kompleks), gunakan metode yang telah dicoba dan diuji selama bertahun-tahun. Salah satu metode ini adalah IDEF0, yang memungkinkan Anda untuk memecahkan masalah kehidupan yang kompleks dengan bantuan alatnya yang sederhana dan mudah dipahami.
