Analisis Bisnis: Memetakan Alur Kerja dengan Data Flow Diagram
Data Flow Diagram adalah diagram yang menggambarkan aliran data dalam suatu sistem, dari input hingga output. Data Flow Diagram menggambarkan alur kerja atau langkah-langkah dalam suatu proses bisnis dengan fokus pada aliran dan transformasi data bisnis.
Berikut adalah daftar simbol yang digunakan dalam Data Flow Diagram (DFD)
Lingkaran atau persegi panjang dengan sudut membulat mewakili suatu proses pada beberapa tingkat detail yang harus memiliki nama. Nama tersebut terdiri dari kata kerja aktif, apa yang dilakukan. Contoh: Proses “Verifikasi Pembayaran”, “Input Data”. Proses harus melakukan sesuatu yang pada akhirnya akan direpresentasikan dalam bentuk data. Suatu proses mengubah data yang masuk menjadi data yang keluar.
Panah mewakili data flow, yang berarti informasi yang bergerak, karena data bergerak dari suatu tempat ke tempat lainnya. Panah menunjuk ke arah pergerakan. Setiap aliran data harus memiliki nama karena data adalah suatu benda misalnya “Formulir Pendaftaran”, “Data Transaksi”.
Dua garis sejajar horizontal, atau persegi panjang terbuka di satu sisi mewakili data store. Data store hanyalah data yang diam, menunggu untuk dikonsumsi oleh suatu proses. Data store biasanya diletakkan di antara proses-proses yang membutuhkan atau menyimpan data. Contoh: Database pengguna, arsip transaksi.
Persegi panjang atau persegi dengan sudut membulat mewakili external entity, merepresentasikan orang, organisasi, atau aplikasi yang berada di luar cakupan dari perspektif DFD atau proyek. Contoh: Pelanggan, Pemasok, Sistem lain, Administrator.
Standar notasi DFD yang umum digunakan ada dua, yaitu notasi Yourdon dan notasi Gane-Sarson, dengan rincian perbedaan sebagai berikut
DFD memiliki berbagai tujuan, yaitu :
- Memodelkan sistem secara abstrak dan logis, tanpa memperhatikan implementasi teknis.
Kenapa DFD disebut abstrak? Karena DFD tidak menunjukkan bagaimana sistem diimplementasikan secara fisik atau teknis, tetapi hanya menjelaskan logika aliran data dan proses yang terjadi dalam sistem. DFD hanya menggambarkan apa yang dilakukan, bukan bagaimana dilakukan.
2. Membantu memahami dan menganalisis aliran data dalam sistem.
Setiap proses internal membuat dan mengonsumsi data tertentu. Jika Anda menggambar DFD, Anda mengungkap aliran data internal dan penyimpanan data.
3. Menjadi alat komunikasi antara analis sistem, pengembang, dan pemangku kepentingan.
Anda juga dapat membuat diagram untuk menyajikan dan mendiskusikan proses tersebut dengan orang lain. Kegunaan utamanya mungkin untuk mengidentifikasi, mendokumentasikan, dan mengomunikasikan persyaratan pemangku kepentingan pada sebuah proyek TI untuk menunjukkan suatu proses atau aliran alih-alih menggunakan kata-kata untuk menggambarkan apa yang mereka maksud.
DFD biasanya memiliki beberapa level untuk merepresentasikan tingkat detail yang berbeda:
- DFD Level 0 (Context Diagram)
Menampilkan seluruh sistem sebagai satu proses tunggal dan hubungan dengan entitas eksternal. - DFD Level 1
Memecah proses utama menjadi subproses dan menunjukkan data store. - DFD Level 2, 3, dst.
Masing-masing subproses dari level sebelumnya dapat dipecah lagi menjadi detail yang lebih kecil.
Secara umum, DFD memang biasanya hanya sampai Level 2, dan itu sudah cukup untuk sebagian besar sistem. Namun, DFD bisa saja memiliki Level 3, 4, atau lebih, tergantung pada:
- Kompleksitas Sistem
Sistem kecil/menengah: Biasanya cukup sampai Level 1 atau 2.
Sistem besar atau kritis (misalnya sistem perbankan, ERP, atau layanan pemerintah): Bisa sampai Level 3 atau lebih, karena setiap proses bisa dipecah menjadi subproses yang lebih rinci.
2. Kebutuhan Analisis
Jika analis sistem atau pengembang butuh pemahaman sangat detail tentang proses tertentu, maka mereka mungkin akan membuat DFD hingga Level 3 atau 4, tapi hanya untuk bagian spesifik, bukan keseluruhan sistem.
3. Dokumentasi dan standard organisasi
Beberapa organisasi memiliki standar dokumentasi yang menuntut detail tinggi, sehingga DFD-nya dibuat sangat terstruktur hingga level-level dalam.
Namun pada praktik umumnya, biasanya adalah sebagai berikut
Level 0 (Context Diagram): Selalu ada, memperlihatkan gambaran umum aliran data tanpa rincian teknis.
Level 1: Sangat umum
Level 2: Umum untuk sistem yang agak kompleks
Level 3+: Jarang, hanya jika benar-benar diperlukan
Tips menentukan sejauh mana level DFD yang perlu kita buat :
- Jangan membuat DFD terlalu dalam kalau tidak menambah pemahaman.
- Lebih baik buat dokumentasi lain (seperti flowchart, BPMN) jika detail logika proses sudah terlalu rumit untuk DFD.
Sebelum membuat DFD, kita harus benar-benar memahami apa yang dikerjakan sistem dan bagaimana alur informasinya bekerja. Kita akan gunakan contoh sistem pemesanan di salon dan menerapkan langkah-langkah sebelum membuat DFD.
- Analisis Kebutuhan Sistem (Gambaran Umum)
- Pelanggan memesan layanan salon (misal: potong rambut, creambath)
- Salon mengelola jadwal layanan
- Mencatat data pelanggan dan transaksi
- Admin menerima dan mengatur pemesanan
2. Identifikasi Proses Bisnis
- Pelanggan membuat pemesanan
- Salon memeriksa ketersediaan jadwal dan staf
- Sistem mengonfirmasi jadwal ke pelanggan
- Pelanggan datang dan mendapatkan layanan
- Pembayaran dilakukan dan dicatat
- Admin mengelola data layanan dan staf
3. Identifikasi Entitas Eksternal
- Pelanggan: memesan layanan, menerima konfirmasi
- Staf Salon: melayani pelanggan, mengikuti jadwal
- Admin : mengelola data layanan dan staf
4. Identifikasi Aliran Data
- Pelanggan → Sistem: data pemesanan (nama, layanan, waktu)
- Sistem → Pelanggan: konfirmasi jadwal
- Sistem → Data Store: simpan data pemesanan
- Admin → Sistem: input/update jadwal staf
- Sistem → Data Store : Menyimpan atau memperbarui jadwal layanan
5. Identifikasi Data Store (Penyimpanan)
- Data Pelanggan
- Data Pemesanan
- Data Jadwal Staf
- Data Layanan
- Data Pembayaran/Transaksi
6. Buat Narasi Singkat Sistem
- Pelanggan membuka aplikasi/website dan memilih layanan yang diinginkan.
- Sistem menampilkan waktu dan staf yang tersedia.
- Pelanggan memilih waktu dan mengirimkan pemesanan.
- Sistem menyimpan data pemesanan dan mengonfirmasi ke pelanggan.
- Ketika hari layanan tiba, pelanggan datang.
- Setelah layanan, pembayaran dilakukan dan sistem mencatat transaksi.
7. Membuat DFD
DFD Level 0 (Context Diagram)
- Proses Utama: “Sistem Pemesanan Salon”
- Entitas: Pelanggan, Admin
- Aliran Data:
Pelanggan → Sistem: Data Pemesanan
Sistem → Pelanggan: Konfirmasi Jadwal
Admin → Sistem: Data Jadwal & Layanan
Sistem → Admin: Laporan Transaksi, Jadwal
- Data Store (biasanya belum ditampilkan di level ini)
DFD Level 1
Proses (Sub-proses):
- 1.0 Pemesanan Layanan
- 2.0 Pengelolaan Jadwal
- 3.0 Pengelolaan Transaksi
Entitas Eksternal:
- Pelanggan
- Admin
Data Store:
- D1 — Data Pelanggan
- D2 — Data Pemesanan
- D3 — Data Jadwal
- D4 — Data Layanan
- D5 — Data Transaksi
- D6 — Laporan Transaksi
Aliran Data:
Dari dan ke Pelanggan:
- Pelanggan → 1.0 Pemesanan Layanan: Data Pemesanan
- 1.0 Pemesanan Layanan → Pelanggan: Status Jadwal
Dari dan ke Admin:
- Admin → 2.0 Pengelolaan Jadwal: Data Jadwal & Layanan
- 3.0 Pengelolaan Transaksi → Admin: Laporan Transaksi
- 2.0 Pengelolaan Jadwal → Admin: Jadwal
Antar Proses:
- 1.0 Pemesanan Layanan → 2.0 Pengelolaan Jadwal: Permintaan Jadwal
- 2.0 Pengelolaan Jadwal → 1.0 Pemesanan Layanan: Status Jadwal
- 1.0 Pemesanan Layanan → 3.0 Pengelolaan Transaksi: Data Pemesanan untuk Transaksi
- 3.0 Pengelolaan Transaksi → 1.0 Pemesanan Layanan: Status Pembayaran
DFD Level 2 — Proses 1.0: Pemesanan Layanan
Sub-Proses:
- 1.1 Mengisi Formulir Pemesanan
- 1.2 Validasi Data Pemesanan
- 1.3 Kirim Permintaan Jadwal
- 1.4 Kirim Data ke Transaksi
Entitas Eksternal:
- Pelanggan
Data Store
- Data Pemesanan
- Data Layanan
- Riwayat Pemesanan
Aliran Data:
Dari dan ke Pelanggan:
- Pelanggan → 1.1 Mengisi Formulir Pemesanan: Formulir Pemesanan
- 1.2 Validasi Data Pemesanan → Pelanggan: Notifikasi Kesalahan (jika ada)
Antar Sub-Proses:
- 1.1 → 1.2: Data Pemesanan
- 1.2 → 1.3: Data Valid
- 1.2 → Pelanggan: Notifikasi Kesalahan
- 1.3 → 2.0 Pengelolaan Jadwal: Permintaan Jadwal
- 2.0 → 1.3: Status Jadwal
- 1.3 → Pelanggan: Status Jadwal
- 1.3 → 1.4: Data Pemesanan & Jadwal
- 1.4 → 3.0 Pengelolaan Transaksi: Data Pemesanan untuk Transaksi
- 3.0 → 1.4: Status Pembayaran
- 1.4 → Pelanggan: Status Pembayaran
Proses paling dasar dalam DFD yang tidak akan dipecah lagi menjadi sub-proses lain disebut Functional primitive. Dengan kata lain Functional primitive adalah titik akhir dari dekomposisi proses dalam DFD.
Ciri-ciri Functional Primitives:
- Tidak memiliki DFD level lebih lanjut (tidak dipecah jadi DFD Level 2 atau seterusnya).
- Sudah cukup jelas dan spesifik untuk langsung diimplementasikan dalam kode atau sistem.
Contoh Dekomposisi Hingga Functional Primitive:
DFD Level 0:
- Proses 3: 3.0 Pengelolaan Transaksi
DFD Level 1 (pecahan dari proses 1):
- 3.1 Validasi Pembayaran
- 3.2 Simpan Data Transaksi (ini bisa jadi functional primitive)
- 3.3 Buat Laporan Transaksi (bisa juga primitive jika tidak terlalu kompleks)
Proses 3.2 dan 3.3 adalah functional primitive karena:
- Tidak dipecah lebih lanjut.
- Tugasnya spesifik dan implementatif: menyimpan data ke database.
Contoh Kasus
Kasus A — Proses: Buat Laporan Transaksi
- Proses hanya merangkum total transaksi dan menampilkannya ke admin
- Tidak ada banyak aturan bisnis atau variasi perhitungan
Maka ini cukup sederhana, bisa dianggap functional primitive.
Kasus B — Proses: Buat Laporan Transaksi
- Laporan punya beberapa jenis (harian, bulanan, berdasarkan layanan, status)
- Ada aturan pemfilteran, pengelompokan, eksport ke PDF, dll.
Maka proses perlu dipecah lagi ke subproses seperti:
- 3.3.1 Hitung Total Transaksi Harian
- 3.3.2 Filter Berdasarkan Layanan
- 3.3.3 Ekspor Laporan ke PDF
Dalam hal ini, belum bisa dianggap functional primitive karena masih ada logika yang kompleks.
Sering kali, masalah dalam suatu proses disebabkan oleh data yang hilang, tidak lengkap, tidak akurat, atau tidak tepat waktu. DFD berfokus pada alur data, jadi wajar jika masalah seringkali berasal dari data itu sendiri.
Mengapa Masalah Proses Sering Disebabkan oleh Data?
- Data adalah Input Utama Proses
Dalam DFD, proses tidak bisa berjalan tanpa data. Jika datanya tidak ada, salah, atau telat, maka proses tidak bisa menghasilkan output yang benar.
Contoh:
Proses “Pengelolaan Transaksi” butuh Data Pemesanan. Jika data ini hilang atau tidak lengkap, maka proses gagal menghasilkan laporan yang benar.
2. Proses Mengandalkan Akurasi dan Kelengkapan Data
Proses seperti verifikasi, perhitungan, atau pelaporan memerlukan data yang akurat dan lengkap. Jika ada satu field saja yang salah, seluruh output bisa kacau.
Contoh:
“Simpan Jadwal” tanpa tanggal yang benar akan menyebabkan bentrokan jadwal atau data tidak bisa digunakan
3. Ketepatan Waktu (Timeliness) Sangat Kritis
Banyak proses tergantung pada data yang datang tepat waktu. Data yang datang terlambat bisa menyebabkan proses lain tertunda atau salah ambil keputusan.
Contoh:
Jika “Status Pembayaran” datang setelah jadwal layanan, maka sistem bisa salah menyimpulkan bahwa pelanggan belum bayar.
4. Proses Output = Cerminan Kualitas Data Input
Kalau input-nya buruk, output-nya juga pasti salah. DFD tidak menyimpan logika internal yang mendalam, ia hanya menunjukkan alur dan transformasi data. Maka, data yang rusak, hilang, atau telat otomatis membuat proses terlihat gagal, padahal mungkin logika prosesnya benar.
dalam prinsip-prinsip penggambaran DFD yang benar, terdapat istilah berikut.
1. Penyeimbangan Horizontal (Horizontal Balancing)
Penyeimbangan horizontal adalah teknik untuk memastikan bahwa alur data yang masuk dan keluar dari suatu proses di DFD level tinggi (misalnya level 0) harus konsisten dengan proses yang diuraikan lebih detail di DFD level di bawahnya (misalnya level 1).
Artinya: Input dan output dari proses di level atas harus tetap ada dan tidak boleh berubah secara struktur atau makna ketika diuraikan lebih lanjut.
Contoh: Jika proses “1.0 — Pengelolaan Pemesanan” di DFD level 0 menerima data “Formulir Pemesanan” dan menghasilkan “Faktur Pemesanan”, maka saat dipecah menjadi DFD level 1:
- Harus tetap ada aliran “Formulir Pemesanan” yang masuk
- Harus tetap ada aliran “Faktur Pemesanan” yang keluar
2. Hukum Pelestarian Data (Law of Conservation of Data)
Ini adalah prinsip dasar bahwa tidak boleh ada data yang “hilang” atau “muncul tiba-tiba” saat membuat atau menguraikan DFD. Setiap data yang masuk ke proses harus diolah dan hasilnya keluar . Tidak boleh ada data keluar dari proses yang tidak berasal dari input atau data store yang valid
Horizontal Balancing adalah bentuk penerapan dari Law of Conservation of Data ketika DFD dipecah dari level yang lebih tinggi ke yang lebih rendah. Tujuannya agar alur data tetap logis, konsisten, dan tidak membingungkan ketika sistem dijabarkan lebih detail.
Suatu proses harus mengubah data, yang berarti data yang dihasilkannya harus berbeda dari data yang dikonsumsinya. Data tersebut dapat datang langsung melalui aliran data masuk atau proses membuatnya menggunakan data yang diterimanya. Aliran data dapat berasal dari penyimpanan data, proses lain, atau entitas eksternal. Proses memerlukan algoritme atau aturan bisnis untuk membuat data. Misalnya, proses menentukan usia. Agoritme usia sama dengan tahun berjalan dari tanggal hari ini dikurangi tahun lahir dari tanggal lahir karyawan. Algoritme dan aturan bisnis, memerlukan data untuk mendapatkan tahun kelahiran yang memerlukan ID karyawan. Pada akhirnya, Anda harus memperhitungkan setiap elemen data yang dibuat oleh proses dan setiap elemen data yang dibutuhkan untuk membuat output.
Problem Analysis, Timing Analysis, dan Exception Analysis adalah bagian dari tahapan evaluasi atau validasi dalam pengembangan sistem menggunakan Data Flow Diagram (DFD).
1. Problem Analysis
- Mengidentifikasi masalah dalam alur data, proses, atau struktur DFD.
- Melihat redundansi, duplikasi proses, kesalahan logika, atau ketidaksesuaian kebutuhan pengguna.
- Mengecek apakah ada data store atau proses yang tidak diperlukan, atau proses yang tidak memiliki input/output (dead process).
Contoh: Ada proses “Validasi Pembayaran” tapi tidak ada input dari entitas mana pun atau data store, ini mengindikasikan ada yang hilang atau rancangan belum lengkap.
Langkah-langkah:
- Identifikasi elemen DFD: Catat semua proses, data store, data flow, dan entitas eksternal.
2. Periksa keterhubungan antar elemen: Pastikan semua proses memiliki input dan output. Cek apakah data store digunakan minimal satu input & satu output. Jangan ada entitas langsung terhubung ke entitas atau data store tanpa melalui proses.
3. Cari duplikasi proses: Apakah ada proses yang berulang tanpa kebutuhan berbeda?
4. Bandingkan dengan kebutuhan sistem: Cek apakah semua fungsi sistem terwakili dalam DFD. Lihat apakah ada kebutuhan yang tidak tercermin dalam diagram.
5. Tinjau kelogisan aliran data: Apakah ada data flow yang tidak diperlukan? Apakah data mengalir ke tempat yang semestinya?
2. Timing Analysis
- Mengevaluasi apakah aliran data sesuai urutan logis dan waktu yang dibutuhkan.
- Berguna saat sistem melibatkan proses real-time atau deadline tertentu.
- Mendeteksi bottleneck atau proses yang terlalu lambat dalam urutan kerja.
Contoh: Proses “Kirim Notifikasi” dilakukan sebelum “Validasi Data Pengguna” selesai. Ini menandakan ada urutan yang salah.
Langkah-langkah:
- Tentukan proses yang bergantung waktu: Tandai proses yang berurutan atau bergantung pada hasil proses lain.
2. Susun alur proses berdasarkan urutan kerja: Buat urutan eksekusi secara logis/berbasis waktu, walau DFD tidak eksplisit menyatakan waktu.
3. Simulasikan alur kerja: Coba simulasikan skenario: “Jika proses A terjadi, berapa lama hingga proses B bisa mulai?” Apakah ada proses yang terjadi terlalu cepat/terlambat?
4. Identifikasi bottleneck: Lihat apakah ada proses lambat atau menumpuk, terutama yang membutuhkan input dari banyak proses.
5. Cek sinkronisasi data: Pastikan data yang digunakan di suatu proses sudah tersedia saat dibutuhkan.
3. Exception Analysis
- Fokus pada penanganan kasus tidak normal (exception)
- Apakah DFD mencakup skenario ketika data salah, proses gagal, atau entitas tidak memberikan respons?
- Apa yang terjadi jika input dari user salah format? Adakah proses validasi dan pengembalian error?
Langkah — langkah :
- Identifikasi titik rawan error: Bagaimana jika data kosong? Bagaimana jika proses gagal? Bagaimana jika koneksi ke data store gagal?
- Bandingkan dengan skenario nyata: Uji skenario ekstrem: input salah, proses tidak mendapat data, dll.
User Stories sering kali menjadi dasar awal untuk membangun DFD.
Dari sebuah user story seperti:
“Sebagai admin, saya ingin bisa mengganti status user agar data tetap akurat.”
Maka bisa dihasilkan elemen-elemen DFD seperti:
Proses: “Update Status User”
Data Flow: Data user dikirim ke sistem, status diubah, lalu disimpan
Data Store: Tabel/User Database
External Entity: Admin
DFD menggambarkan bagaimana kebutuhan (user stories) tersebut diwujudkan dalam alur data dan proses. Dalam pengembangan sistem, urutannya adalah sebagai berikut.
Banyak hal yang sering diabaikan saat membuat DFD (Data Flow Diagram) Berikut beberapa kesalahan umum dan hal yang sering terlewat, beserta dampaknya:
1. Tidak Jelas atau Salah Mengidentifikasi Entitas Eksternal
- Masalah: Entitas eksternal seperti user, sistem lain, atau organisasi sering tidak dimasukkan atau malah dimasukkan sebagai proses.
- Akibat: Sistem terlihat tidak interaktif, atau batasan sistem jadi kabur.
- Contoh salah: “Admin” digambarkan sebagai proses, padahal harusnya entitas eksternal.
2. Tidak Konsisten antara Level (Leveling Error)
- Masalah: Saat membuat DFD Level 0, Level 1, dst., isi prosesnya tidak sinkron.
- Akibat: Diagram menjadi tidak runtut, menyulitkan validasi atau pengembangan lebih lanjut.
- Tips: Pastikan setiap proses di Level 0 dijabarkan dengan benar di Level 1 (dekomposisi).
3. Tidak Menyediakan Data Store dengan Jelas
- Masalah: Tempat penyimpanan data (misalnya database, file, dsb.) tidak digambarkan, atau digambarkan sebagai proses.
- Akibat: Diagram terlihat tidak realistis , ke mana data disimpan?
- Solusi: Selalu tampilkan data store jika proses menyimpan/membaca data.
5. Penggunaan Simbol yang Tidak Konsisten
- Masalah: Simbol proses, data flow, entitas, dan data store dicampur-campur bentuknya.
- Akibat: Menimbulkan kebingungan dalam membaca diagram.
- Tips: Gunakan standar notasi DFD (misalnya Gane-Sarson atau Yourdon).
6. Kurangnya Validasi ke Stakeholder
- Masalah: DFD dibuat tanpa klarifikasi dengan user/stakeholder.
- Akibat: Banyak proses tidak relevan dengan kenyataan, menyebabkan revisi besar.
- Solusi: Validasi DFD ke pengguna teknis dan non-teknis sebelum lanjut ke desain sistem.
Kesimpulan
Dengan memahami dan menggunakan DFD secara tepat, kita tidak hanya memetakan aliran data, tetapi juga meningkatkan akurasi analisis kebutuhan sistem. DFD bukan sekadar diagram, melainkan alat berpikir visual yang efektif dalam menjembatani komunikasi antara tim teknis dan bisnis.
