MAKALAH

MENGAUDIT SISTEM INFORMASI BERBASIS

KOMPUTER DAN PERANCANGAN BASIS
DATA MENGGUNAKAN MODEL DATA (REA)

Makalah ini disusun untuk memenuhi tugas Sistem

Informasi Akutansi

Disusun Oleh :
Kelompok 6 :

ADE ARIF FIRNANDA (161041120042)

ARIS DARMAWAN (161041120035)
RISKA SAPUTRA (161041120008)
LISDA WATI (161041120046)
MUNA KARTIKA (161041120051)
T MAULIDUL UMAM (161041120053)

PROGRAM STUDI SISTEM INFORMASI

FAKULTAS ILMU KOMPUTER
UNIVERSITAS UBUDIYAH INDONESIA
Jl. Alue Naga, Tibang, Kec. Syiah Kuala-Banda Aceh
2017
 1 KATA PENGANTAR

Puji dan sukur kami panjatkan kepada Tuhan Yang Maha Esa atas waktu
dan kesempatan yang telah diberikan sehingga kami bisa menyelesaikan
makalah ini tepat pada waktu yang diberikan. Tidak lupa pula saya
sampaikan terima kasih banyak kepada orang yang terlibat baik secara
langsung maupun yang tidak langsung dalam penyusunan makalah ini yang
membahas Mengaudit Sistem Informasi Berbasis Komputer dan
Perancangan Basis Data Menggunakan Model Data (REA)

Kami menyadari dalam penyusunan dan pembuatan makalah ini masih

bisa dikatakan sangat jauh dari kata sempurna dan oleh karena itu kami
bersedia menunggu kritik dan saran yang membangun dari bapak dan para
pembaca agar kedepannya kami bisa lebih baik lagi.

Banda Aceh, 19 September 2017

Kelompok 6

i
 2 DAFTAR ISI
KATA PENGANTAR ............................................................................................... i
DAFTAR ISI............................................................................................................. ii
1 BAB I PENDAHULUAN ................................................................................. 1
1.1 Latar Belakang........................................................................................... 1
1.2 Tujuan ....................................................................................................... 1
2 BAB II PEMBAHASAN .................................................................................. 2
2.1 GAMBARAN UMUM PROSES AUDIT ......................................................... 2
2.2 Pendekatan Audit berbasis Risiko ............................................................. 5
2.3 Audit Sistem Informasi .............................................................................. 6
2.3.1 Keamanan Keselurahan .................................................................... 6
2.3.2 Pengembangan Program dan Akuisi ................................................. 8
2.3.3 Modifikasi Program ......................................................................... 10
2.3.4 Oengolahan Komputer .................................................................... 13
2.3.5 Sumber Data ................................................................................... 17
2.3.6 Data File .......................................................................................... 19
2.4 Software Audit ........................................................................................ 22
2.5 Audit Operasional Dari AIS ...................................................................... 23
2.5.1 Interrupts ........................................... Error! Bookmark not defined.
2.5.2 Direct Memorry Acces ....................... Error! Bookmark not defined.
2.5.3 Hardware summary ........................... Error! Bookmark not defined.
2.6 Antarmuka I/O Aplikasi .............................. Error! Bookmark not defined.
2.6.1 Perangkat Block Dan Karakte ............. Error! Bookmark not defined.
2.6.2 Perangkat Jaringan ............................. Error! Bookmark not defined.
2.6.3 Jam dan Waktu................................... Error! Bookmark not defined.
2.6.4 Pemblikiran dan NonBlock I/O ........... Error! Bookmark not defined.
2.7 Kernel I/O Subsystem................................. Error! Bookmark not defined.
2.7.1 Penjadwalan I/O................................. Error! Bookmark not defined.
2.7.2 Penyangga .......................................... Error! Bookmark not defined.
2.7.3 Caching ............................................... Error! Bookmark not defined.
2.7.4 Spoling and Device reservation.......... Error! Bookmark not defined.
2.7.5 Eror Handling ..................................... Error! Bookmark not defined.
2.7.6 I/O Protection .................................... Error! Bookmark not defined.

ii
 2.7.7 Karnel data Struktures ....................... Error! Bookmark not defined.
2.7.8 Karnel I/O Subsystem summery ......... Error! Bookmark not defined.
2.8 Mengubah Permintaan I/O Ke Operasi Perangkat Keras Error! Bookmark
not defined.
2.9 Streams ...................................................... Error! Bookmark not defined.
2.10 Peforma...................................................... Error! Bookmark not defined.
DAFTAR PUSTAKA ............................................................................................. 43

iii
 3 BAB I PENDAHULUAN

3.1 Latar Belakang

Sistem operasi merupakan bagian penting dari setiap sistem komputer.
Demikian pula, kursus tentang sistem operasi merupakan bagian penting dari setiap
pendidikan sains komputer. Bidang ini mengalami perubahan yang cepat, karena
komputer sekarang lazim di hampir semua aplikasi, mulai dari game hingga anak-
anak melalui alat perencanaan paling canggih untuk pemerintah dan perusahaan
multinasional.

3.2 Tujuan

1. Dapat jelaskan cakupan dan tujuan pekerjaan audit, dan identifikasi langkah-
langkah utama dalam proses audit.
2. Mengidentifikasi tujuan audit sistem informasi, dan menjelaskan pendekatan
empat langkah yang diperlukan untuk memenuhi tujuan ini.
3. Rancang sebuah rencana untuk studi dan evaluasi pengendalian internal dalam
AIS.
4. Jelaskan perangkat lunak audit komputer. dan jelaskan bagaimana hal itu
digunakan dalam audit AIS.
5. Jelaskan sifat dan ruang lingkup audit Operasional.
6. Diskusikan langkah-langkah untuk merancang dan mengimplementasikan
sistem basis data
7. Gunakan model data REA untuk merancang database AIS
8. Diambil sebuah diagram REA database AIS
9. Baca diagram REA dan jelaskan apa yang diungkapkannya tentang aktivitas
bisnis dan kebijakan organisasi yang dimodelkan

1
 4 BAB II PEMBAHASAN

4.1 GAMBARAN UMUM PROSES AUDIT

Semua audit mengikuti urutan aktivitas yang sama. Audit dapat
dibagi menjadi empat tahap: perencanaan. mengumpulkan bukti,
mengevaluasi bukti, dan mengkomunikasikan hasil audit. Gambar 11-1
adalah ikhtisar proses audit dan mencantumkan banyak prosedur yang
dilakukan dalam masing-masing tahap ini.
PERENCANAAN AUDIT Perencanaan audit menentukan mengapa,
bagaimana, kapan, dan oleh siapa audit akan dilakukan. Langkah pertama
adalah menetapkan ruang lingkup dan tujuan audit. Misalnya, audit terhadap
perusahaan publik mempertimbangkan apakah laporan keuangannya
disajikan secara wajar. Sebaliknya, audit internal dapat memeriksa
departemen tertentu atau aplikasi komputer. Ini mungkin berfokus pada
pengendalian internal, informasi keuangan, kinerja operasi, atau kombinasi
dari ketiganya.
Tim audit dengan pengalaman dan keahlian yang diperlukan
terbentuk. Mereka menjadi akrab dengan auditee dengan berunding dengan
personil pengawas dan operasi, meninjau dokumentasi sistem, dan meninjau
kembali temuan audit sebelumnya.
Audit direncanakan sehingga jumlah pekerjaan audit terbesar berfokus
pada area dengan faktor risiko tertinggi. Ada tiga jenis risiko audit:

1. Risiko yang melekat adalah kerentanan terhadap risiko material

tanpa adanya kontrol. Misalnya, sistem yang menggunakan
pemrosesan online, netw0rks, database, telekomunikasi. dan 'bentuk
teknologi maju lainnya memiliki risiko yang lebih inheren daripada
sistem pemrosesan batch.
2. Risiko pengendalian adalah risiko bahwa salah saji material akan
melalui struktur pengendalian internal dan ke dalam laporan
keuangan. Perusahaan dengan kontrol internal yang lemah memiliki
risiko pengendalian yang lebih tinggi daripada yang memiliki
kontrol kuat. Risiko pengendalian dapat ditentukan dengan meninjau
lingkungan pengendalian, menguji pengendalian internal, dan
mempertimbangkan pengendalian yang lemahnesses diidentifikasi
dalam audit sebelumnya dan mengevaluasi bagaimana mereka telah
diperbaiki.

2
 Perencanaan audit menetapkan ruang lingkup dan tujuan
mengatur tim audit untuk mengembangkan pengetahuan tentang
tinjauan operasional bysiness sebelum hasil audit
mengidentifikasi faktor risiko mempersiapkan program audit.

Pengumpulan pengamatan bukti audit atas tinjauan kegiatan

operasional pembahasan dokumentasi dengan qustionaries
karyawan pemeriksaan fisik konfirmasi aset melalui pihak ketiga
reperformance prosedur vouching dokumen sumber review
analitis sampling audit.

Evaluasi Bukti Audit Menilai kualitas pengendalian internal

Menilai keandalan informasi Menilai kinerja operasi
Pertimbangkan perlu bukti ganjil Bukti Pertimbangkan faktor
risiko Temuan audit dokumen

Komunikasi Hasil Audit Merumuskan kesimpulan audit

Mengembangkan rekomendasi untuk manajemen Menyiapkan
laporan audit Menyampaikan hasil audit kepada manajemen

3. Risiko pendeteksian adalah risiko bahwa auditor dan prosedur

auditnya akan gagal mendeteksi kesalahan material atau salah saji.
Untuk menyimpulkan tahap perencanaan, sebuah program audit
disiapkan untuk menunjukkan sifat, luas, dan waktu prosedur yang
diperlukan untuk mencapai tujuan audit dan meminimalkan risiko
audit. Anggaran waktu disiapkan, dan anggota staf ditugaskan untuk
melakukan langkah Audit tertentu.
KOLEKSI BUKTI AUDIT Sebagian besar usaha audit dihabiskan
untuk mengumpulkan bukti. Karena banyak tes audit tidak dapat dilakukan
pada semua item yang sedang dikaji, namun sering dilakukan berdasarkan
basis sampel. Berikut ini adalah cara yang paling umum untuk
mengumpulkan bukti audit:

3
  Pengamatan terhadap kegiatan yang diaudit (misalnya, mengamati
bagaimana data kontrol personil memproses data pengolahan seperti
yang diterima)
 Review dokumentasi untuk memahami bagaimana suatu sistem atau
sistem pengendalian internal seharusnya berfungsi
 Diskusi dengan karyawan tentang pekerjaan mereka dan bagaimana
mereka melaksanakan prosedur tertentu
 Kuesioner yang mengumpulkan data
 Pemeriksaan fisik terhadap kuantitas dan / atau kondisi aset
berwujud. seperti peralatan dan inventaris
 Konfirmasi keakuratan informasi, seperti saldo rekening
nasabah. melalui komunikasi dengan pihak ketiga yang independen
 Reperformance perhitungan untuk memverifikasi informasi
kuantitatif (misalnya menghitung ulang biaya penyusutan tahunan)
 Vouching untuk validitas transaksi dengan memeriksa dokumen
pendukung, seperti pesanan pembelian, laporan penerimaan, dan
faktur vendor yang mendukung transaksi hutang dagang.
 Tinjauan analitis tentang hubungan dan kecenderungan di antara
informasi untuk mendeteksi barang yang harus diselidiki lebih
lanjut. Sebagai contoh, auditor untuk toko rantai menemukan bahwa
rasio satu toko terhadap piutang dagang terhadap penjualan terlalu
tinggi. Sebuah penyelidikan mengungkapkan bahwa manajer
mengalihkan dana yang dikumpulkan untuk penggunaan pribadinya.
Audit atipikal memiliki gabungan antara prosedur audit. Misalnya, audit
pengendalian internal membuat penggunaan observasi, tinjauan
dokumentasi, wawancara karyawan, dan kinerja prosedur kontrol yang lebih
baik.Audit keuangan berfokus pada pemeriksaan fisik, kelanjutan, vouching,
review analitis, dan reperformance perhitungan saldo akun.
EVALUASI BUKTI AUDIT Auditor mengevaluasi bukti yang
dikumpulkan dan memutuskan apakah mendukung kesimpulan yang
menguntungkan atau tidak menguntungkan. Jika tidak meyakinkan, auditor
melakukan prosedur tambahan yang cukup untuk mencapai kesimpulan
definitif.
Karena kesalahan ada di kebanyakan sistem, auditor fokus untuk
mendeteksi dan melaporkan hal-hal yang secara signifikan mempengaruhi
interpretasi manajemen terhadap audit fmdin gs. Menentukan materialitas,
apa dan tidak penting dalam audit, adalah masalah penilaian
profesional. Materialitas lebih penting untuk audit eksternal, di mana
penekanannya adalah keadilan laporan keuangan, daripada audit internal, di
mana fokusnya adalah pada kepatuhan terhadap kebijakan manajemen.
Auditor mencari kepastian yang memadai bahwa tidak ada kesalahan
material dalam informasi atau proses yang diaudit. Karena sangat mahal
untuk mendapatkan kepastian yang lengkap, auditor memiliki beberapa
risiko bahwa kesimpulan audit salah. Bila risiko inheren atau pengendalian

4
tinggi, auditor harus mendapatkan kepastian yang lebih besar untuk
mengimbangi ketidakpastian dan risiko yang lebih besar.
Pada semua tahap audit, temuan dan kesimpulan didokumentasikan di
dalam kertas kerja audit. Dokumentasi sangat penting pada tahap evaluasi,
bila kesimpulan harus dicapai dan didukung.
HASIL AUDIT KOMUNIKASI 0F Auditor menyampaikan laporan
tertulis yang merangkum temuan audit dan rekomendasi kepada manajemen,
komite audit, dewan direksi, dan pihak terkait lainnya. Setelah itu, auditor
sering melakukan studi lanjutan untuk memastikan apakah rekomendasi
telah dilaksanakan.

4.2 Pendekatan Audit berbasis Risiko

Pendekatan evaluasi pengendalian internal berikut, yang disebut
pendekatan audit berbasis risiko, menyediakan kerangka kerja untuk
melakukan audit sistem informasi:

1. Tentukan ancaman (fraud dan error) yang dihadapi perusahaan. Ini

adalah daftar penyalahgunaan atau kerusakan yang disengaja atau
disengaja dimana sistem terkena.
2. Identifikasi prosedur pengendalian yang mencegah, mendeteksi, atau
memperbaiki ancaman. Ini semua adalah kontrol yang telah dilakukan
manajemen dan auditor harus meninjau dan menguji, untuk
meminimalkan ancaman.
3. Evaluasi prosedur pengendalian. Kontrol dievaluasi dua cara:
a. Tinjauan sistem menentukan apakah prosedur pengendalian
benar-benar ada.
b. Pengujian kontrol dilakukan untuk menentukan apakah
pengendalian yang ada bekerja sebagaimana mestinya
4. Mengevaluasi kelemahan pengendalian untuk menentukan pengaruhnya
terhadap sifat, waktu, atau tingkat prosedur audit. Jika auditor
menentukan bahwa risiko pengendalian terlalu tinggi karena sistem
kontrol tidak memadai, auditor mungkin harus mengumpulkan lebih
banyak bukti, bukti lebih baik, atau bukti yang lebih tepat
waktu. Kelemahan kontrol di satu area mungkin bisa diterima jika ada
kompensasi kontrol di area lain.
Pendekatan berbasis risiko memberi auditor pemahaman yang lebih
jelas tentang kecurangan dan kesalahan yang dapat terjadi dan risiko dan
eksposur terkait. Juga membantu mereka merencanakan bagaimana cara
menguji dan mengevaluasi pengendalian internal, serta bagaimana
merencanakan prosedur audit berikutnya. Hasilnya adalah dasar yang kuat
untuk mengembangkan rekomendasi kepada manajemen mengenai
bagaimana sistem kontrol AIS harus ditingkatkan.

5
4.3 Audit Sistem Informasi
Tujuan audit sistem informasi adalah untuk meninjau dan
mengevaluasi pengendalian internal yang melindungi sistem Saat
melakukan audit sistem informasi, auditor harus memastikan bahwa enam
tujuan berikut terpenuhi:
1. Ketentuan keamanan melindungi peralatan komputer, program,
komunikasi, dan data dari akses, modifikasi, atau penghancuran
yang tidak sah.
2. Pengembangan dan akuisisi program dilakukan sesuai dengan
kewenangan umum dan spesifik manajemen.
3. Modifikasi program memiliki otorisasi dan persetujuan manajemen
4. Pengolahan transaksi, lites, laporan, dan catatan komputer lainnya
yang akurat dan lengkap.
5. Data sumber yang tidak akurat atau tidak benar diotorisasi
diidentifikasi dan ditangani sesuai dengan kebijakan manajerial
yang ditentukan.
6. File data komputer yang akurat, lengkap, dan rahasia.
Gambar 11-2 menggambarkan hubungan antara enam komponen sistem
informasi dan tujuan ini. Masing-masing tujuan ini dibahas secara rinci pada
bagian berikut. Setiap deskripsi mencakup rencana audit untuk
menyelesaikan setiap tujuan, serta teknik dan prosedur untuk melaksanakan
rencana tersebu.

4.3.1 Keamanan Keselurahan

Tabel 11-] menggunakan pendekatan berbasis risiko untuk
menyajikan kerangka kerja untuk mengaudit keamanan komputer secara
keseluruhan. Ini menunjukkan bahwa keseluruhan ancaman keamanan
sistem mencakup kerusakan yang tidak disengaja atau disengaja terhadap
aset sistem; akses, pengungkapan, atau modifikasi data dan program yang
tidak sah; pencurian; dan gangguan kegiatan bisnis yang penting.

6
TABEL 11-1 Kerangka Audit Keseluruhan Keamanan Komputer
Jenis Kesalahan dan Penipuan

 Pencurian atau kerusakan disengaja atau disengaja terhadap perangkat

keras
 Rugi. pencurian. atau akses tidak sah ke program. data. dan sumber daya
sistem lainnya
 KERUGIAN. pencurian. atau pengungkapan data rahasia yang tidak sah
 Modifikasi atau penggunaan program dan file data yang tidak sah
 Gangguan aktivitas bisnis cntcial
Prosedur Pengendalian

 Informasi keamanan rencana perlindungan

 Membatasi akses fisik ke peralatan komputer
 Membatasi akses logis ke sysrem menggunakan kontrol otentikasi dan
otorisasi
 Kontrol penyimpanan dan transmisi data
 Prosedur perlindungan virus
 Prosedur backup dan recovery file
 Fault-tolerant system design
 Rencana pemulihan bencana
 Pemeliharaan preventif 0 Firewall
 Asuransi kecelakaan dan gangguan usaha
Prosedur Audit: Sistem Review

 Periksa situs komputer

 Tinjau rencana keamanan informasi / perlindungan dan pemulihan
bencana
 Wawancara sistem informasi personil tentang prosedur keamanan
 Meninjau kebijakan dan prosedur akses fisik dan logis
 Tinjau kembali kebijakan dan prosedur backup dan recovery file
 Meninjau kebijakan dan prosedur penyimpanan data dan transmisi
 Meninjau prosedur yang digunakan untuk meminimalkan downtime
sistem 0 Meninjau kontrak pemeliharaan vendor
 Periksa log akses sistem 'Periksa polis asuransi kecelakaan dan bisnis
gangguan
Prosedur Audit: Pengujian Kontrol

 Amati dan tat prosedur akses komputer-situs

 Amati persiapan dan penyimpanan off-site dari file cadangan
 Uji tugas dan prosedur modifikasi untuk ID pengguna: dan kata sandi
 Selidiki bagaimana upaya akses yang tidak sah ditangani
 Verifikasi luas dan efektifitas enkripsi data

7
 Verifikasi penggunaan kontrol transmisi data secara efektif
 Verifikasi penggunaan firewall dan prosedur proteksi virus yang efektif
 Verifikasi penggunaan perawatan pencegahan dan catu daya tak terputus
Verifikasi jumlah dan batasan cakupan asuransi
 Periksa hasil simulasi uji coba rencana pemulihan bencana
Kompensasi Kontrol

 Suara personil kebijakan. termasuk segregasi tugas yang tidak sesuai

 Kontrol pengguna yang efektif
Prosedur pengendalian untuk meminimalkan ancaman ini mencakup
pengembangan rencana keamanan / perlindungan informasi, membatasi
akses fisik dan logis, mengenkripsi data. melindungi terhadap virus,
menerapkan firewall, melembagakan kontrol transmisi data. dan mencegah
dan memulihkan dari kegagalan sistem atau bencana.
Prosedur tinjauan sistem mencakup pemeriksaan lokasi
komputer; mewawancarai personil: revieWing kebijakan dan prosedur; dan
memeriksa log akses. Polis asuransi. dan rencana pemulihan bencana,
Auditor menguji kontrol keamanan dengan mengamati prosedur,
memverifikasi bahwa kontrol ada pada tempatnya dan bekerja sebagaimana
mestinya, menyelidiki kesalahan atau masalah untuk memastikan
penanganannya benar, danmemeriksa tes yang pernah dilakukan
sebelumnya. Sebagai contoh. Salah satu cara untuk menguji kontrol akses
logis adalah dengan mencoba masuk ke sistem. Selama audit keamanan
pemerintah AS. auditor menggunakan terminal agen untuk mendapatkan
akses tidak sah ke sistem komputernya. nonaktifkan prosedur pemeriksaan
keamanannya. dan kontrol sistem dari terminal. Perincian keamanan
dimungkinkan karena kontrol administratif yang buruk dan perangkat lunak
keamanan yang tidak memadai.
Kebijakan personil yang baik dan pemisahan tugas-tugas yang tidak
kompatibel secara efektif dapat sebagian mengimbangi keamanan komputer
yang buruk. Kontrol pengguna yang baik juga akan membantu. asalkan
personil pengguna dapat mengenali output sistem yang tidak biasa. Karena
tidak mungkin kontrol ini bisa diimbangi tanpa batas waktu untuk keamanan
komputer yang buruk. auditor harus sangat menganjurkan agar keamanan
lemahnesses dikoreksi.
4.3.2 Pengembangan Program dan Akuisi
Peran auditor dalam pengembangan sistem harus dibatasi pada
tinjauan independen terhadap aktivitas pengembangan sistem. Untuk
menjaga objektivitas, auditor sebaiknya tidak membantu mengembangkan
sistem.
Dua hal bisa salah dalam pengembangan program: (l) kesalahan
pemrograman yang tidak disengaja karena kesalahpahaman tentang

8
spesifikasi sistem atau pemrograman ceroboh dan (2) instruksi yang tidak
sah sengaja dimasukkan ke dalam program.
Masalah ini dapat dikendalikan dengan meminta persetujuan dan
persetujuan manajemen, pengguna, dan pengujian menyeluruh. dan
dokumentasi yang tepat
Selama peninjauan sistem. auditor harus mendiskusikan prosedur
pengembangan dengan manajemen. pengguna sistem dan personil sistem
informasi. Mereka juga harus meninjau ulang kebijakannya. prosedur,
standar dan dokumentasi yang tercantum dalam Tabel I l-2.

TABEL 11-2 Kerangka Audit Pengembangan Program

Jenis Kesalahan dan Penipuan

 Kesalahan pemrograman yang tidak disengaja atau kode program yang

tidak sah
Prosedur Pengendalian

 Tinjauan perjanjian lisensi perangkat lunak

 Otorisasi manajemen untuk pengembangan program dan akuisisi
perangkat lunak
 Manajemen dan persetujuan pengguna untuk spesifikasi pemrograman
 Uji menyeluruh terhadap program baru. termasuk tes penerimaan
pengguna
 Dokumentasi sistem lengkap. termasuk persetujuan
Prosedur Audit: Sistem Review

 Kajian independen terhadap proses pengembangan sistem

 Tinjauan kebijakan dan prosedur pengembangan sistem / akuisisi
 Tinjauan kebijakan dan prosedur otorisasi sistem dan persetujuan
 Tinjauan standar evaluasi pemrograman
 Tinjauan standar dokumentasi program dan sistem
 Review specilications tes. uji data dan hasil tes
 Tinjauan kebijakan dan prosedur persetujuan uji
 Tinjauan akuisisi kebijakan dan prosedur perjanjian lisensi capyright
 Diskusi dengan manajemen. pengguna. dan personil sistem informasi
mengenai prosedur pengembangan
Prosedur Audit: Pengujian Kontrol

 Wawancara pengguna tentang akuisisi / pengembangan dan penerapan

sistem mereka
 Tinjau menit pertemuan tim pengembangan untuk bukti keterlibatan
 Verifikasi persetujuan manajemen dan persetujuan pengguna pada poin
tonggak perkembangan
 Tinjau spesifikasi tes. uji data dan hasil uji sistem

9
 Meninjau perjanjian lisensi perangkat lunak
Kompensasi Kontrol

 Kontrol pemrosesan yang kuat

 pengolahan data uji independen oleh auditor.
Untuk menguji kontrol develoPment sistem, auditor harus
mewawancarai manajer dan pengguna sistem. memeriksa persetujuan
pengembangan, dan meninjau pengembangan pertemuan tim
pengembang. Auditor harus meninjau semua dokumentasi yang berkaitan
dengan proses pengujian untuk memastikan semua perubahan program
diuji. Auditor harus memeriksa tes Spesifikasi dan data uji dan
mengevaluasi hasil pengujian. Auditor harus memastikan bagaimana hasil
uji tak terduga diselesaikan.
Kontrol pemrosesan yang kuat dapat mengimbangi kontrol
pembangunan yang tidak memadai jika auditor mendapatkan bukti persuasif
tentang kepatuhan terhadap kontrol pemrosesan. menggunakan teknik
pengolahan data seperti uji independen. Jika bukti ini tidak diperoleh,
auditor mungkin harus menyimpulkanbahwa kelemahan pengendalian
internal material ada dan bahwa risiko ancaman signifikan dalam program
aplikasi tidak dapat diterima tinggi.
4.3.3 Modifikasi Program
Tabel 11-3 menyajikan kerangka kerja untuk mengaudit perubahan
program aplikasi dan sistem yang lunak. Ancaman yang sama yang terjadi
selama pengembangan program terjadi selama modifikasi
program. Misalnya, seorang programmer yang ditugaskan untuk
memodifikasi sistem penggajian perusahaannya dimasukkan aperintah
untuk menghapus semua file perusahaan jika dia diakhiri. Saat
dipecat. sistem jatuh dan menghapus ubin kunci.

TABEL 11-3 Kerangka Audit Modifikasi Program

Jenis Kesalahan dan Penipuan

 kesalahan pemrograman yang tidak disengaja atau kode program yang

tidak sah
Prosedur Pengendalian

 Daftar komponen program yang akan dimodifikasi

 Otorisasi manajemen dan persetujuan modifikasi program
 Persetujuan pengguna terhadap spesifikasi perubahan program
 Uji menyeluruh terhadap perubahan program. termasuk tes penerimaan
pengguna
 Dokumentasi perubahan program lengkap, termasuk persetujuan
Pengembangan terpisah. uji. dan versi produksi dari program

10
 Perubahan yang dilakukan oleh personel independen pengguna dan
pemrogram Kontrol akses logis
Prosedur audit: System Review

 Meninjau kebijakan modifikasi program, standar. dan prosedur

 Meninjau standar dokumentasi untuk modifikasi program
 Meninjau dokumentasi akhir tentang modifikasi program
 Review program modifikasi modifikasi dan prosedur persetujuan uji
 Tinjau spesifikasi tes. uji data dan hasil tes
 Meninjau kebijakan dan prosedur persetujuan uji
 Meninjau standar evaluasi pemrograman
 Diskusikan kebijakan dan prosedur modifikasi dengan
manajemen. pengguna. dan personil sistem
 Meninjau kebijakan dan prosedur kontrol akses logis
Prosedur Audit: Pengujian Kontrol

 Verifikasi persetujuan pengguna dan manajemen signofl untuk perubahan

program
 Pastikan komponen program yang akan dimodifikasi diidentifikasi dan
terdaftar
 Verifikasi bahwa program mengubah prosedur dan dokumentasi uji
sesuai dengan standar
 Verifikasi bahwa kontrol akses logis berlaku untuk perubahan program
 Amati implementasi perubahan program
 Verity yang memisahkan pengembangan, uji. dan versi produksi
dipertahankan
 memverifikasi bahwa perubahan tidak dilakukan oleh pengguna atau
personil pemrograman
 Uji perubahan program yang tidak sah atau salah menggunakan program
perbandingan kode sumber. pemrosesan ulang dan simulasi paralel "
kompensasi kontrol

 tes audit independen untuk perubahan program yang tidak sah atau salah
 Kuat pengolahan cantrol
Ketika sebuah perubahan program diajukan {atau persetujuan, daftar
semua pembaruan yang diperlukan harus disusun dan disetujui oleh
pengguna manajemen dan program. Semua perubahan program harus diuji
dan didokumentasikan. Selama proses perubahan. program pengembangan
harus tetap terpisah dari versi produksi. Setelah program yang dimodifikasi
disetujui, versi produksi menggantikan versi develOpmental.
Selama peninjauan sistem. auditor harus mendiskusikan proses perubahan
dengan manajemen dan personil pengguna. Kebijakannya. Prosedur. dan
standar untuk menyetujui. memodifikasi. pengujian, dan dokumentasi
perubahan harus diperiksa. Semua materi dokumentasi akhir untuk

11
perubahan program. termasuk prosedur dan hasil uji, harus ditinjau
ulang. Prosedur yang digunakan untuk membatasi akses logis terhadap
program pembangunan harus ditinjau ulang.
Bagian penting dari tes kontrol adalah untuk mengetahui bahwa
perubahan program telah diidentifikasi, terdaftar, disetujui, diuji. dan
didokumentasikan. Auditor harus memverifikasi bahwa program
pengembangan dan produksi terpisah dipertahankan dan perubahan tersebut
diterapkan oleh seseorang yang tidak bergantung pada pengguna dan fungsi
pemrograman. Tabel kontrol akses program pengembangan ditinjau untuk
memverifikasi bahwa hanya pengguna yang berwenang yang memiliki akses
ke sistem.
Auditor harus menguji program secara mengejutkan untuk mencegah
seorang karyawan memasukkan perubahan program yang tidak sah setelah
audit selesai dan menghapusnya sebelum audit berikutnya. Ada tiga cara tes
auditor untuk perubahan program yang tidak sah:
1. Setelah menguji program baru. auditor menyimpan salinan kode
sumbernya. Auditor menggunakan program perbandingan kode
sumber untuk membandingkan versi program saat ini dengan kode
sumber. Jika tidak ada perubahan yang dilakukan. Kedua versi itu
harus identik; Perbedaan apapun harus diselidiki Jika perbedaannya
adalah perubahan yang diotorisasi. auditor memeriksa spesifikasi
perubahan program untuk memastikan bahwa perubahan tersebut
diotorisasi dan dimasukkan dengan benar.
2. Dalam teknik pemrosesan ulang. auditor memproses ulang data
menggunakan kode sumber dan membandingkan hasilnya dengan
output perusahaan. Perbedaan dalam output diselidiki.
3. dalam simulasi paralel. auditor menulis sebuah program alih-alih
menggunakan kode sumber. bandingkan hasilnya dan menyelidiki
perbedaan. Simulasi paralel dapat digunakan untuk menguji suatu
program selama proses implementasi. Sebagai contoh. Jason
menggunakan teknik ini untuk menguji sebagian sistem penggajian
departemen penjualan SPP yang baru.
Untuk setiap perubahan program utama. auditor mengamati
pengujian dan implementasi. meninjau otorisasi dan dokumen dan
melakukan tes independen. Jika langkah ini dilewati dan kontrol perubahan
program kemudian terbukti tidak memadai. mungkin juga tidak mungkin
bergantung pada keluaran program.
Jika kontrol perubahan program ckficient. sebuah kontrol
kompensasi adalah perbandingan kode sumber. pemrosesan ulang atau
simulasi paralel yang dilakukan oleh auditor. Kontrol pemrosesan
suara. diuji secara independen oleh auditor. sebagian dapat mengimbangi
kekurangan tersebut. Namun. jika kekurangan disebabkan oleh pembatasan
yang tidak adekuat terhadap akses lile program. auditor harus sangat
merekomendasikan tindakan untuk memperkuat kontrol akses logis
organisasi.

12
4.3.4 Oengolahan Komputer
Tabel 11.4 memberikan kerangka kerja untuk mengaudit
pemrosesan transaksi. file. dan catatan komputer terkait untuk memperbarui
file dan database dan untuk menghasilkan laporan.
Selama pemrosesan komputer. sistem mungkin gagal untuk
mendeteksi masukan yang keliru. Kesalahan masukan yang benar tidak
benar, isikan masukan yang salah. atau mendistribusikan atau
mengungkapkan output secara tidak benar. Tabel 11-4 menunjukkan
prosedur pengendalian untuk mendeteksi dan mencegah ancaman dan sistem
tinjauan dan tes kontrol yang digunakan untuk memahami
kontrol. mengevaluasi kecukupan mereka dan uji apakah mereka berfungsi
dengan baik.
Auditor mengevaluasi ulang kontrol pemrosesan secara berkala
untuk memastikan keandalannya terus berlanjut. jika mereka tidak
memuaskan kontrol data pengguna dan sumber mungkin cukup kuat untuk
dikompensasikan. jika tidak. ada kelemahan menar. dan langkah-langkah
harus diambil untuk menghilangkan kekurangan kontrol.
Beberapa teknik khusus digunakan untuk menguji kontrol
pemrosesan. masing memiliki kelebihan dan kekurangan tersendiri. Tidak
ada teknik yang efektif untuk segala situasi; semua lebih tepat dalam
beberapa situasi dan kurang begitu pada orang lain. Auditor tidak boleh
mengungkapkan teknologi mananique mereka gunakan karena hal itu dapat
mengurangi keefektifannya. EilCh dari prosedur ini sekarang dijelaskan.

TABEL 11-4 Kerangka Audit Kontrol Komputer

Jenis Kesalahan dan Penipuan

 Gagal mendeteksi salah, tidak lengkap. atau data masukan yang tidak sah
 Gagal untuk memperbaiki kesalahan yang ditandai oleh pengeditan data
 pengenalan kesalahan ke file atau database selama update
 Distribusi atau pengungkapan output komputer yang tidak tepat
 lntenuonal 'atau ketidakakuratan yang tidak disengaja dalam pelaporan
Prosedur Pengendalian

 Rutinisasi pengeditan data

 Penggunaan label file internal dan eksternal yang tepat
 Rekonsiliasi total batch 'Prosedur koreksi kesalahan yang efektif
 Dokumentasi operasi yang dapat dipahami dan manual berjalan
 Pengawasan yang kompeten atas operasi komputer
 Penanganan data input dan output yang efektif oleh personel kontrol data
 Persiapan daftar perubahan berkas dan ringkasan untuk tinjauan
departemen pengguna Pemeliharaan kondisi lingkungan yang tepat di
fasilitas komputer
Prosedur Audit: Sistem Review

13
 Meninjau dokumentasi administratif untuk standar pengendalian proses
 Tinjau dokumentasi sistem untuk pengeditan data dan kontrol
pemrosesan lainnya
 Tinjau dokumentasi pengoperasian untuk kelengkapan dan kejelasan
 Tinjau salinan daftar kesalahan. batch total laporan dan daftar perubahan
file
 Amati operasi komputer dan fungsi kontrol data
 Diskusikan pengolahan dan output kontrol dengan operator dan
supervisor sistem informasi
Prosedur Audit: Pengujian Kontrol

 Mengevaluasi kecukupan standar kontrol pengolahan dan prosedur

 Mengevaluasi kecukupan dan kelengkapan kontrol pengeditan data yang
 Verifikasi kepatuhan terhadap prosedur pengendalian pengolahan dengan
mengamati operasi komputer dan data kontrol
 Verify.that sistem aplikasi keluaran didistribusikan dengan baik
 Rekonsiliasi sampel total angkatan; menindaklanjuti perbedaan
 Melacak sampel kesalahan data mengedit rutinitas untuk memastikan
penanganan yang tepat
 Verifikasi pengolahan akurasi transaksi sensitif
 Verifikasi pengolahan akurasi transaksi yang dihasilkan komputer
 Cari kode yang salah atau tidak sah melalui analisis logika program
 Cheeck akurasi dan kelengkapan kontrol pengolahan menggunakan data
uji
 Memonitor sistem pengolahan online menggunakan teknik audit
bersamaan
 Menciptakan laporan yang dipilih untuk menguji akurasi dan
kelengkapan
kompensasi Kontrol

 kontrol pengguna yang kuat dan kontrol yang efektif dari sumber data
PENGOLAHAN TES DATA Salah satu cara untuk menguji sebuah
program adalah untuk memproses satu set hipotetis transaksi sah dan tidak
sah. Program ini harus memproses semua transaksi yang valid dengan benar
dan menolak semua yang tidak valid. Semua jalur logika harus diperiksa
oleh satu atau lebih transaksi tes. data yang tidak valid termasuk catatan
dengan data yang hilang, bidang mengandung sejumlah besar tidak wajar,
nomor rekening tidak valid atau kode pengolahan data nonnumeric di
bidang numerik. dan catatan dari urutan.
Sumber daya berikut membantu ketika mempersiapkan data uji:

 Daftar transaksi yang sebenarnya

 Transaksi tes perusahaan yang digunakan untuk menguji program
 Sebuah generator data uji, yang mempersiapkan data uji berdasarkan
spesifikasi Program

14
 Dalam sistem batch processing. program perusahaan dan salinan mes
yang relevan digunakan untuk memproses data uji. Hasilnya dibandingkan
dengan output yang benar telah ditentukan: perbedaan menunjukkan
kesalahan pengolahan atau kekurangan kontrol untuk diselidiki.
Dalam sistem online, auditor memasukkan data uji dan kemudian
mengamati dan log respon sistem. Jika sistem menerima transaksi tes yang
keliru, auditor membalikkan efek dari transaksi, menyelidiki masalah, dan
merekomendasikan bahwa kekurangan diperbaiki.
Pengolahan transaksi uji memiliki dua kelemahan. Pertama, auditor
harus menghabiskan waktu yang cukup memahami sistem dan
mempersiapkan transaksi uji. Kedua, auditor harus memastikan bahwa data
pengujian tidak mempengaruhi file perusahaan dan database. auditor dapat
membalikkan efek dari transaksi tes atau memproses transaksi dalam jangka
terpisah menggunakan c0py dari file atau database. Namun, lari terpisah
menghilangkan beberapa keaslian diperoleh dari data uji pengolahan dengan
transaksi biasa. Karena prosedur pembalikan dapat mengungkap keberadaan
dan sifat tes auditor untuk personil kunci, itu bisa kurang efektif daripada tes
tersembunyi.
TEKNIK AUDIT Bersamaan Karena transaksi dapat diproses dalam
sistem online tanpa meninggalkan jejak audit, bukti yang dikumpulkan
setelah data diproses tidak cukup untuk tujuan audit. Sebagai tambahan.
karena banyak sistem secara online memproses transaksi terus menerus,
sulit untuk menghentikan sistem untuk melakukan tes pemeriksaan. Dengan
demikian, auditor menggunakan teknik audit bersamaan untuk terus
memonitor sistem dan mengumpulkan bukti audit sedangkan data hidup
diproses selama jam operasi rutin. teknik audit bersamaan menggunakan
modul audit yang tertanam, yang segmen kode program yang melakukan
fungsi audit, hasil tes laporan, dan menyimpan bukti-bukti yang
dikumpulkan untuk diperiksa auditor. teknik audit bersamaan yang
memakan waktu dan sulit untuk digunakan, tetapi kurang jadi jika
digabungkan ketika program deveIOped.
Auditor biasanya menggunakan lima teknik audit bersamaan.
1. Sebuah fasilitas uji terintegrasi (ITF) menyisipkan catatan fiktif yang
mewakili divisi fiktif, departemen, pelanggan, atau pemasok di file
induk perusahaan. Pengolahan transaksi tes untuk memperbarui mereka
tidak akan mempengaruhi catatan sebenarnya. Karena catatan fiktif dan
yang sebenarnya diproses bersama-sama, karyawan perusahaan tidak
menyadari pengujian. Sistem ini membedakan catatan ITF dari catatan
yang sebenarnya, mengumpulkan informasi tentang transaksi tes, dan
melaporkan hasilnya. auditor membandingkan data yang diproses
dengan hasil yang diharapkan untuk memverifikasi bahwa sistem dan
kontrol yang beroperasi dengan benar. Dalam sistem batch processing,
IT F menghilangkan kebutuhan untuk membalikkan transaksi tes. ITF
efektif tes sistem pengolahan online, karena transaksi tes dapat
disampaikan sering, diproses dengan transaksi yang sebenarnya,dan

15
 ditelusuri melalui setiap tahap pengolahan tanpa mengganggu operasi
pengolahan biasa. Auditor harus berhati-hati tidak untuk
menggabungkan catatan dummy dan aktual selama proses pelaporan.

2. Dalam teknik snapshot, transaksi yang dipilih ditandai dengan kode

khusus. modul Audit mencatat transaksi tersebut dan catatan master file
mereka sebelum dan setelah pengolahan dan menyimpan data dalam file
khusus. auditor ulasan data untuk memverifikasi bahwa semua langkah
pengolahan yang benar dieksekusi.

3. Sistem kontrol berkas review audit (SCARF) menggunakan modul audit

yang tertanam untuk terus memantau aktivitas transaksi, mengumpulkan
data tentang transaksi dengan signifikansi audit khusus, dan
menyimpannya dalam sebuah file SYAL atau audit log. Transaksi yang
dicatat termasuk mereka melebihi batas dolar Ditentukan, yang
melibatkan rekening yang tidak aktif, yang menyimpang dari kebijakan
perusahaan. atau mengandung write-downs dari nilai aset. Secara
berkala, auditor memeriksa log audit untuk mengidentifikasi dan
menyelidiki transaksi dipertanyakan.

4. kait Audit rutinitas audit yang memberitahukan auditor transaksi

dipertanyakan, sesering mereka terjadi. penggunaan State Farm ini kait
audit, termasuk bagaimana perusahaan mendeteksi penipuan besar,
dijelaskan dalam Focus 11-1

5. Terus menerus dan intermiten simulasi (CIS) embeds modul audit

dalam sistem manajemen database (DBMS) yang meneliti semua
transaksi yang update database menggunakan kriteria mirip dengan
syal. Jika transaksi memiliki makna audit khusus, modul CIS
independen memproses data (dengan cara yang sama untuk paralel
simulasi), mencatat hasil, dan membandingkan mereka dengan yang
diperoleh oleh DBMS. Ketika perbedaan ada, mereka disimpan dalam
log audit untuk penyelidikan selanjutnya. Jika perbedaan serius, CIS
dapat mencegah DBMS dari melaksanakan pembaruan.
ANALISIS PROGRAM LOGIC Jika auditor su5pect bahwa program
berisi kode yang tidak sah atau kesalahan serius, analisis rinci dari logika
program mungkin diperlukan. Ini adalah memakan waktu dan memerlukan
kemahiran dalam bahasa pemrograman yang sesuai, sehingga harus
digunakan sebagai lalu
The State Farm Hidup asuransi Perusahaan sistem komputer memiliki
komputer host di Bloomington, lllinois, dan komputer kecil di kantor-kantor
regional. sistem proses lebih dari 30 juta transaksi per tahun selama lebih
dari 4 juta polis individu senilai lebih dari $ 7 miliar.
online ini, sistem real-time update file dan database sebagai transaksi
terjadi. audit kertas telah hampir lenyap, dan dokumen pendukung

16
perubahan catatan pemegang polis telah dihilangkan atau diadakan hanya
dalam waktu singkat sebelum disposisi.
Karena siapa pun dengan akses dan pengetahuan tentang sistem dapat
melakukan penipuan, staf audit internal diminta untuk mengidentifikasi
semua cara penipuan itu mungkin. Mereka brainstorming cara-cara untuk
menipu sistem dan mewawancarai pengguna sistem, yang memberikan
wawasan yang sangat berharga.
Auditor dilaksanakan 33 kait audit yang tertanam untuk memonitor 42
jenis transaksi. Satu hook Audit memonitor transaksi yang tidak biasa dalam
rekening transfer yang membersihkan rekening untuk memegang dana yang
areto dikreditkan ke beberapa account sementara.
Kait Audit telah sangat sukses. Satu karyawan curang diproses
pinjaman kebijakan asuransi jiwa kakaknya, memalsukan tanda kakaknya,
dan menguangkan cek. Untuk menyembunyikan penipuan, ia harus
membayar kembali pinjaman sebelum laporan status tahunan dikirim ke
kakaknya: Dia menggunakan serangkaian transaksi fiktif yang melibatkan
rekening transfer. penipuan itu terbongkar segera ketika akun transfer audit
yang kait diakui yang pertama ini transaksi fiktif dan diberitahu
auditor. Dalam waktu satu bulan pemberitahuan, kasus tersebut telah
diselidiki dan karyawan dihentikan.
resort. Auditor menganalisis pembangunan. operasi, dan dokumentasi
program serta hasil cetakan dari kode sumber. Mereka juga menggunakan
paket perangkat lunak berikut:

 program fiowcharting otomatis menafsirkan kode sumber dan

menghasilkan program flowchart.
 program tabel keputusan otomatis menafsirkan kode sumber dan
menghasilkan tabel keputusan.
 Pemindaian rutinitas mencari program untuk semua kejadian dari
item tertentu.
 program pemetaan mengidentifikasi kode program
unexecuted. Perangkat lunak ini bisa menemukan kode program
yang programmer yang tidak bermoral dimasukkan untuk
menghapus semua file komputer ketika ia dihentikan.
 Program menelusuri berurutan mencetak semua langkah Program
dijalankan ketika program berjalan, bercampur dengan output biasa
jadi urutan peristiwa eksekusi program dapat diamati. Program
tracing membantu mendeteksi instruksi program yang tidak
sah. jalur logika yang salah, dan kode program unexecuted.

4.3.5 Sumber Data

Matriks kontrol input digunakan untuk mendokumentasikan review
kontrol sumber data. Matriks pada Gambar 11-3 shows prosedur
pengendalian diterapkan untuk masing-masing bidang record input.

17
 Fungsi kontrol data harus independen dari fungsi lainnya,
mempertahankan log kontrol data, menangani error. dan menjamin efisiensi
keseluruhan operasi. Hal ini biasanya tidak layak secara ekonomis untuk
usaha kecil untuk memiliki fungsi kontrol data independen. Untuk
mengimbangi. kontrol departemen pengguna harus lebih kuat sehubungan
dengan persiapan data, total kontrol batch. mengedit program. pembatasan
akses fisik dan logis, dan prosedur error-handling. Prosedur ini harus
menjadi fokus dari sistem review dan pengujian pengendalian auditor ketika
tidak ada fungsi kontrol data independen.
Meskipun kontrol sumber data mungkin tidak berubah sering,
bagaimana ketat mereka diterapkan dapat berubah. dan auditor harus secara
teratur menguji mereka. auditor menguji sistem dengan mengevaluasi
sampel sumber data untuk otorisasi yang tepat. kontrol mendamaikan
batch. dan mengevaluasi apakah data mengedit kesalahan diselesaikan dan
dikirimkan kembali untuk diproses.
Jika kontrol sumber data tidak memadai, departemen pengguna dan
kontrol pengolahan data dapat mengkompensasi. jika tidak. auditor harus
merekomendasikan bahwa kekurangan kontrol sumber data yang dikoreksi.
Tabel l l-5 menunjukkan pengendalian internal yang mencegah,
mendeteksi. dan sumber data yang tidak akurat atau tidak sah yang
benar. itu juga menunjukkan review sistem dan tes prosedur pengendalian
auditor digunakan. dalam sistem online. entry dan pengolahan fungsi
sumber data yang satu operasi Oleh karena itu, kontrol sumber data yang
terintegrasi dengan kontrol processmg pada Tabel 11-4

18
4.3.6 Data File
Tujuan keenam menyangkut akurasi, integritas, dan keamanan data
yang tersimpan pada mesin-dibaca Liles. Tabel 1-06 Januari merangkum
kesalahan, kontrol, dan prosedur audit untuk tujuan ini. Jika kontrol berkas
yang serius deiicient, terutama berkenaan dengan akses fisik atau logis atau
untuk backup dan pemulihan prosedur, auditor harus merekomendasikan
mereka diperbaiki.
TABLE 115 Kerangka Audit Kontrol Sumber Data
Jenis Kesalahan dan Penipuan

 sumber data yang tidak akurat atau tidak sah

 Prosedur pengendalian
 penanganan yang efektif dari input data sumber oleh tenaga data kontrol
 otorisasi
 Pengguna input data sumber
 Persiapan dan rekonsiliasi total kontrol bets
 Logging tanda terima. gerakan, dan disposisi dari masukan sumber data
 cek digit verigication
 verifikasi kunci
 penggunaan dokumen turnaround
 rutinitas editing Data
 Pengguna departemen review daftar dan ringkasan perubahan genteng
 prosedur yang efektif untuk memperbaiki dan mengirimkan kembali data
yang salah
Prosedur Audit: Sistem Ulasan

 Ulasan dokumentasi tentang tanggung jawab fungsi kontrol Data

 Ulasan dokumentasi administrasi untuk standar kontrol sumber data
 metode Ulasan otorisasi dan memeriksa tanda tangan otorisasi
 Ulasan dokumentasi untuk langkah-langkah pengolahan identitas dan isi
data sumber dan kontrol
 Dokumen kontrol sumber data menggunakan matriks kontrol input
 Diskusikan sumber kontrol data dengan personil kontrol data. pengguna
sistem, dan manajer

TABEL 11-5 Lanjutan

Prosedur Audit: Pengujian Kontrol

 Mengamati dan mengevaluasi operasi departemen pengendalian data dan

prosedur pengendalian
 Verifikasi perawatan yang tepat dan penggunaan kontrol data log
 Mengevaluasi bagaimana item error log ditangani dengan
 Memeriksa data sumber untuk otorisasi yang tepat

19
 Rekonsiliasi total batch dan menindaklanjuti perbedaan
 Jejak disposisi dari kesalahan ditandai oleh edit data rutinitas
kompensasi Kontrol

 pengguna dan data kontrol pengolahan Kuat

TABLE 11-6 Kerangka Audit Kontrol Data File
Jenis Kesalahan dan Penipuan

 Penghancuran data yang disimpan karena kesalahan, perangkat keras atau

perangkat lunak malfungsi, dan tindakan yang disengaja sabotase atau
vandalisme
 Modifikasi yang tidak sah atau pengungkapan data yang tersimpan
Prosedur pengendalian

 Penyimpanan data di perpustakaan file aman dan pembatasan akses fisik

ke file data
 kontrol akses logis dan matriks kontrol akses
 penggunaan yang tepat dari label berkas dan mekanisme write-
perlindungan
 Pembaruan kontrol bersamaan
 Enkripsi data untuk data rahasia
 perangkat lunak antivirus
 Off-situs cadangan dari semua file data
 Checkpoint dan rollback prosedur untuk memfasilitasi pemulihan sistem

Prosedur Audit: Sistem Ulasan

 Ulasan dokumentasi untuk operasi file library

 Ulasan kebijakan dan prosedur akses logis
 standar Ulasan untuk perlindungan virus. off-situs penyimpanan
data. dan prosedur pemulihan sistem
 Ulasan kontrol untuk update bersamaan, enkripsi data. konversi file. dan
rekonsiliasi dari master file total dengan total kontrol independen
 Periksa rencana pemulihan bencana
 Diskusikan prosedur pengendalian file tersebut dengan manajer dan
operator
Prosedur Audit: Pengujian Kontrol

 Mengamati dan mengevaluasi operasi file library

 catatan Ulasan sandi tugas dan modifikasi
 Mengamati dan mengevaluasi berkas-prosedur penanganan oleh tenaga
operatious
 Mengamati persiapan dan off-situs penyimpanan file backup
 Verifikasi penggunaan yang efektif dari prosedur perlindungan virus
 Verifikasi penggunaan kontrol pembaruan bersamaan dan enkripsi data

20
 Verifikasi kelengkapan, mata uang. dan pengujian rencana pemulihan
bencana
 Reconcile file induk total secara terpisah dipertahankan total kontrol
 Amati prosedur yang digunakan untuk mengontrol konversi genteng
kompensasi Kontrol

 Kuat pengguna dan pengolahan data kontrol

 keamanan komputer contrp Efektif contr o ls
Audit oleh-tujuan pendekatan merupakan sarana yang komprehensif,
sistematis, dan efektif mengevaluasi pengendalian internal. Hal ini dapat
diimplementasikan dengan menggunakan prosedur audit checklist untuk
setiap ObjCCllVC. 'LHE checklist membantu auditor mencapai kesimpulan
yang terpisah untuk setiap tujuan dan menunjukkan kontrol kompensasi
yang sesuai. Masing-masing dari enam checklist harus diselesaikan untuk
'setiap aplikasi yang signifikan.

21
4.4 Software Audit
Teknik audit yang dibantu komputer (CAATs) mengacu pada
mengaudit software, sering disebut perangkat lunak audit umum (GAS).
yang menggunakan spesifikasi auditor yang disediakan untuk menghasilkan
program yang melakukan fungsi audit, sehingga mengotomatisasi atau
menyederhanakan proses audit. DUA dari paket perangkat lunak yang
paling populer adalah Audit Control Language (ACL) dan Interaktif
Ekstraksi Data dan Analisis (lDEA). CAATs idealnya cocok untuk
memeriksa file data yang besar untuk mengidentifikasi catatan
membutuhkan pengawasan audit lebih lanjut.
Amerika Serikat. Pemerintah menemukan bahwa teknik audit yang
dibantu komputer adalah alat yang berharga dalam mengurangi defisit
anggaran federal besar. Perangkat lunak ini digunakan untuk
mengidentifikasi klaim Medicare penipuan dan menentukan biaya yang
berlebihan oleh kontraktor pertahanan. General Accounting Office (GAO)
tokoh lintas diperiksa dengan IRS dan menemukan bahwa ribuan veteran
berbohong tentang pendapatan mereka untuk memenuhi syarat untuk
manfaat pensiun. Beberapa 1 16.000 veteran yang menerima pensiun
berdasarkan kebutuhan tidak mengungkapkan $ 338 juta dalam pendapatan
dari tabungan, dividen, atau sewa. Lebih dari l3,600 pendapatan tidak
dilaporkan; salah satu tidak melaporkan pendapatan lebih dari $ 300.000.
Ketika Veteran Administration (VA) diberitahu penerima pendapatan
mereka akan diverifikasi dengan IRS dan Administrasi Keamanan Sosial,
pensiun gulungan menurun lebih dari 13.000,di tabungan dari $ 9 juta per
bulan. VA berencana untuk menggunakan sistem yang sama untuk
memeriksa tingkat pendapatan mereka melamar careIf medis pendapatan
mereka ditemukan to_be di atas tingkat tertentu, pasien akan diminta untuk
membuat copayments
Dalam contoh lain, seorang penagih pajak baru di kota New England
kecil meminta .audit pajak. Menggunakan CAATs, auditor diakses catatan
pemungutan pajak selama empat tahun sebelumnya, mengurutkannya
berdasarkan tanggal, menyimpulkan koleksi dari bulan, dan menciptakan
laporan analisis collectionsThe pajak bulanan mengungkapkan bahwa
koleksi selama bulan Januari dan Juli, dua bulan tersibuk, telah menurun
58% dan 72%, masing-masing. Auditor kemudian digunakan CAATs untuk
membandingkan setiap record pengumpulan pajak dengan catatan properti.
Mereka mengidentifikasi beberapa perbedaan, termasuk salah satu yang
dilakukan oleh mantan pemungut cukai, yang digunakan pembayaran lain
wajib pajak untuk menutupi tunggakan pajak sendiri billsThe mantan
pemungut pajak ditangkap karena penggelapan.
Untuk menggunakan CAATs, auditor memutuskan tujuan audit,
mempelajari file dan database yang akan diaudit, merancang laporan audit,
dan menentukan bagaimana untuk menghasilkan mereka. Informasi ini
dicatat pada lembar spesifikasi dan dimasukkan ke dalam sistem. Program
CAATs menggunakan spesifikasi untuk menghasilkan program audit.
Program ini menggunakan salinan data hidup perusahaan (untuk

22
menghindari memperkenalkan kesalahan) untuk melakukan prosedur audit
dan menghasilkan laporan audit yang ditentukan. CAATs tidak dapat
menggantikan pertimbangan auditor atau membebaskan auditor dari fase
lain dari audit. Sebagai contoh, auditor masih harus menyelidiki item pada
laporan pengecualian. memverifikasi jumlah berkas terhadap sumber-
sumber informasi, dan memeriksa dan mengevaluasi sampel audit.
CAATs sangat berharga bagi perusahaan dengan proses yang
kompleks, operasi terdistribusi, volume transaksi yang tinggi, atau berbagai
macam aplikasi dan sistem.
Berikut ini adalah beberapa penggunaan yang lebih penting dari CAATs:

 Query file data untuk mengambil catatan pertemuan kriteria yang

ditentukan
 Membuat, memperbarui, membandingkan, download, dan penggabungan
file
 Meringkas, menyortir, dan data filtering
 Mengakses data dalam format yang berbeda dan mengkonversi data ke
format umum
 Memeriksa catatan untuk kualitas, kelengkapan, konsistensi. dan
kebenaran
 Stratifikasi catatan. memilih dan menganalisis sampel statistik
 Pengujian untuk risiko spesifik dan mengidentifikasi bagaimana untuk
mengendalikan risiko
 Melakukan perhitungan. analisis statistik, dan Operasi matematika
lainnya
 Melakukan tes analitis, seperti rasio dan analisis kecenderungan, mencari
pola-pola data yang tak terduga atau dijelaskan yang mungkin
mengindikasikan penipuan
 mengidentifikasi kebocoran keuangan. ketidakpatuhan kebijakan, dan
data kesalahan pengolahan
 Mendamaikan penghitungan fisik untuk jumlah yang dihitung, menguji
akurasi ulama ekstensi dan saldo, pengujian untuk duplikat item
 Format dan mencetak laporan dan dokumen
 Membuat kertas kerja elektronik

4.5 Audit Operasional Dari AIS

Teknik dan prosedur yang digunakan dalam audit operasional mirip
dengan audit sistem informasi dan laporan keuangan. Perbedaan mendasar
adalah ruang lingkup audit. Audit sistem informasi dibatasi pada
pengendalian internal dan audit keuangan untuk output sistem, sedangkan
audit operasional mencakup semua aspek manajemen sistem. di samping itu,
tujuan dari audit operasional termasuk mengevaluasi efektivitas, efisiensi,
dan pencapaian tujuan.
Langkah pertama dalam audit operasional adalah perencanaan audit,
di mana ruang lingkup dan tujuan audit ditetapkan, review sistem awal

23
dilakukan, dan program audit tentatif disiapkan. Langkah selanjutnya,
pengumpulan bukti, meliputi kegiatan sebagai berikut:

 Meninjau kebijakan operasi dan dokumentasi

 Mengkonfirmasikan prosedur dengan manajemen dan operasi personil
Mengamati fungsi dan kegiatan Operasi
 Memeriksa keuangan dan operasi rencana dan laporan
 Menguji keakuratan informasi operasi
 kontrol pengujian
Pada tahap evaluasi bukti, auditor mengukur sistem terhadap salah satu
yang mengikuti terbaik prinsip-prinsip manajemen sistem. Salah satu
pertimbangan penting adalah bahwa hasil dari kebijakan dan praktek
manajemen yang lebih signifikan daripada kebijakan dan praktek
sendiri. Artinya, jika hasil yang baik dicapai melalui kebijakan dan praktik
yang secara teoritis kekurangan, maka auditor harus hati-hati
mempertimbangkan apakah perbaikan yang direkomendasikan secara
substansial akan meningkatkan hasil. Auditor mendokumentasikan temuan
dan kesimpulan mereka dan berkomunikasi mereka untuk manajemen.
Auditor operasional ideal memiliki pelatihan audit dan pengalaman
serta beberapa tahun pengalaman dalam posisi manajerial. Auditor dengan
latar belakang audit yang kuat tapi pengalaman manajemen yang lemah
sering kekurangan perspektif yang diperlukan untuk memahami proses
manajemen.

4.6 Prosses Perancangan Basis Data

Gambar l7-l menunjukkan lima langkah dasar dalam perancangan
basis data. Tahap pertama (analisis sistem) terdiri dari perencanaan awal
untuk menentukan kebutuhan dan kelayakan pengembangan sistem
baru. Tahap ini mencakup penilaian awal tentang kelayakan teknologi dan
ekonomi prOposal. Ini juga melibatkan identifikasi kebutuhan informasi
pengguna. mendefinisikan ruang lingkup sistem baru yang diusulkan. dan
menggunakan informasi tentang jumlah pengguna dan volume transaksi
yang diharapkan untuk membuat keputusan awal mengenai persyaratan
perangkat keras dan perangkat lunak.
Tahap kedua (desain kerucut) mencakup pengembangan skema yang
berbeda untuk sistem baru pada tingkat konseptual, ekstemal, dan
internal. Tahapan ketiga (desain fisik) terdiri dari menerjemahkan skema
tingkat internal ke dalam struktur basis data aktual yang akan diterapkan di
sistem yang baru. Ini juga tahap ketika aplikasi baru devel0ped. Tahap
keempat (implementasi dan konversi) mencakup semua aktivitas yang
terkait dengan transfer data dari sistem yang ada ke database baru AIS.
Menguji sistem baru. dan melatih karyawan cara
menggunakannya. Tahap akhir adalah menggunakan dan memelihara
sysrem baru. Ini termasuk memantau secara hati-hati kinerja sistem dan
kepuasan pengguna untuk menentukan kebutuhan untuk membuat

24
penyempurnaan dan modifikasi sistem Akhirnya. perubahan strategi dan
praktik bisnis atau perkembangan baru yang signifikan dalam teknologi
informasi mendorong perusahaan untuk mulai menyelidiki kelayakannya
mengembangkan sistem baru, dan keseluruhan proses dimulai lagi
(perhatikan tanda panah yang kembali ke tahap analisis sistem).

Akuntan dapat dan harus berpartisipasi dalam setiap tahap proses

perancangan basis data. Meskipun tingkat keterlibatan mereka cenderung
bervariasi antar tahap. Selama tahap analisis sistem; akuntan membantu
mengevaluasi kelayakan proyek dan mengidentifikasi kebutuhan informasi
pengguna. Pada tahap desain konseptual, akuntan berpartisipasi dalam
mengembangkan skema logis, merancang kamus data, dan menentukan
kontrol penting. Akuntan dengan kemampuan database yang baik mungkin
Langsung berpartisipasi dalam menerapkan model data selama tahap
desain fisik. Selama tahap implementasi dan konversi, akuntan harus
dilibatkan dalam menguji keakuratan database baru dan program aplikasi
yang akan menggunakan data tersebut, serta menilai kecukupan
kontrol. Akhirnya. banyak akuntan adalah pengguna reguler database
organisasi dan kadang-kadang bahkan memiliki tanggung jawab untuk
pengelolaannya.
Akuntan dapat memberikan nilai terbesar bagi organisasi mereka
dengan mengambil tanggung jawab untuk pemodelan data. Pemodelan data
adalah proses pendefinisian database sehingga dengan setia
merepresentasikan semua aspek organisasi. termasuk interaksi dengan
lingkungan eksternal. Seperti ditunjukkan pada Gambar l7-l, pemodelan
data terjadi selama analisis sistem dan desain konseptual tahapan desain
database Selanjutnya, kita membahas dua alat penting yang dapat digunakan

25
akuntan untuk melakukan pemodelan data: diagram hubungan entitas dan
model data REA.

4.7 Diagram Entity-Relationship

Diagram entity-relationship (ER) adalah teknik grafis untuk
menggambarkan skema database. Ini disebut diagram ER karena ini
menunjukkan berbagai entitas yang dimodelkan dan hubungan penting di
antara mereka. Entitas adalah sesuatu yang diinginkan organisasi.
Mengumpulkan dan menyimpan informasi Misalnya, database Fred's
Train Shop mencakup entitas untuk karyawan, pelanggan, pemasok,
inventaris, dan untuk bisnis yang sesuai dengan pelanggan dan pengiriman
dari wppliers. Dalam database relasional, tabel terpisah akan dibuat untuk
menyimpan informasi tentang masing-masing entitas yang berbeda; Dalam
database berorientasi objek, kelas terpisah akan dibuat untuk setiap entitas
yang berbeda.
Dalam diagram ER, entitas digambarkan sebagai persegi panjang
Sayangnya. Namun, tidak ada standar industri untuk aspek lain dari diagram
ER Beberapa pemodel data dan pengarang menggunakan berlian untuk
menggambarkan hubungan (Gambar 17-2, panel A), sementara yang lainnya
melakukan (Gambar l7-2, panel B). Kadang-kadang atribut yang terkait
dengan masing-masing entitas digambarkan sebagai oval bernama yang
terhubung ke masing-masing persegi panjang (Gambar 17-2. panel C),
sedangkan di lain waktu atribut yang terkait dengan setiap entitas tercantum
dalam tabel terpisah (Gambar 17-2, panel D) . Dalam buku ini, kita akan
membuat diagram ER dengan sejumlah besar entitas dan hubungan. untuk
mengurangi kekacauan dan meningkatkan keterbacaan. kita menghilangkan
berlian untuk hubungan dan daftar atribut yang terkait dengan setiap entitas
dalam tabel terpisah. Dengan demikian, diagram kita terlihat seperti panel B
dan D pada Gambar 17-2.
Diagram ER dapat digunakan untuk mewakili isi dari setiap jenis
database. Sebagai contoh, diagram ER dari database olahraga intramural
mungkin termasuk siswa. tim, dan liga sebagai entitas, sedangkan diagram
ER untuk sebuah sekolah mungkin termasuk siswa. guru. dan kursus
sebagai entitas. dalam buku ini Fokus kami adalah pada database yang
dirancang untuk mendukung kegiatan bisnis sebuah organisasi. Karena
itu. kami akan menunjukkan bagaimana diagram ER dapat digunakan tidak
hanya untuk merancang database tetapi juga untuk mendokumentasikan dan
memahami database yang ada dan untuk mendesain ulang proses
bisnis. Manajemen proses bisnis tercakup dalam Bagian V; Dalam bab ini
kita fokus menggunakan diagram ER untuk perancangan basis data dan
untuk memahami isi database yang ada.
Seperti dicatat. Diagram ER dapat mencakup berbagai jenis entitas
dan hubungan di antara entitas tersebut. Langkah penting dalam desain

26
database. karena itu. memerlukan penentuan entitas mana yang perlu
dimodelkan. Model data REA berguna untuk malung keputusan itu.

4.8 Model Data REA2

Model data REA dikembangkan secara khusus untuk digunakan
dalam merancang A13. Model data REA berfokus pada semantik bisnis
yang mendasari aktivitas rantai nilai organisasi. Ini memberikan panduan
atau desain database dengan mengidentifikasi entitas apa saja yang harus
disertakan dalam database AIS dan dengan meresepkan cara menyusun
hubungan antara entitas di database tersebut. Model data REA biasanya
digambarkan dalam bentuk diagram ER. Akibatnya, dalam sisa bab ini dan
sepanjang buku ini, kita akan mengacu pada diagram ER yang
dikembangkan sesuai dengan model data REA sebagai diagram REA.
4.8.1 Tiga Jenis Dasar Entitas
Model data REA dinamai demikian karena mengklasifikasikan
entitas ke dalam tiga kategori yang berbeda: sumber daya yang diperoleh
dan digunakan oleh organisasi. peristiwa (kegiatan bisnis) di mana
organisasi terlibat, dan agen yang berpartisipasi dalam kejadian ini.3
Gambar 17-3 memberikan contoh dari ketiga jenis entitas ini.
Sumber daya adalah hal-hal yang memiliki nilai ekonomis bagi
organisasi. Gambar 11-3 mencakup dua entitas sumber: kas dan
inventaris. Acara adalah berbagai aktivitas bisnis yang manajemen ingin
mengumpulkan informasi untuk tujuan perencanaan atau pengendalian.
' Ada dua entitas acara pada Gambar 173: Penjualan dan Penerimaan
Tunai. Agen adalah orang-orang dan organisasi yang berpartisipasi dalam
acara dan tentang siapa informasi diinginkan untuk tujuan perencanaan,
pengendalian, dan evaluasi. Gambar 17-3 mencakup dua jenis entitas agen:
Karyawan dan Pelanggan.

27
4.8.2 Hubungan Penataan: Template REA Dasar
Model data REA menentukan pola dasar bagaimana tiga jenis entitas
(sumber daya, kejadian, dan agen) harus berhubungan satu sama
lain. Gambar 174 menyajikan pola dasar ini. Fitur penting dari pola ini
adalah sebagai berikut:
1. Eacheventinuntuk mengetahui paling sedikit apakah Anda benar-benar
tidak mampu.
2. Setiap kejadian terkait dengan satu sama lain.
3. Setiap acara terkait dengan setidaknya dua agen yang berpartisipasi.

ATURAN 1: SETIAP EVENT ENTITY HARUS TERKAIT SAMPAI

SATU SUMBER DAYA RESIKO Kejadian harus dikaitkan dengan
setidaknya satu sumber daya yang mereka temukan. Beberapa acara, seperti
yang diberi label "Get Resource A" pada Gambar 17-4, meningkatkan
jumlah sumber daya. Prestasi umum dari acara "Get" tersebut mencakup
penerimaan barang dari pemasok (yang meningkatkan kuantitas di tangan
persediaan) dan penerimaan pembayaran dari pelanggan (yang
meningkatkan jumlah uang tunai). Peristiwa lain, seperti yang diberi label
"Berikan Sumber Daya B" pada Gambar 17-4, secara langsung mengurangi
jumlah sumber daya. Contoh umum dari kejadian "Berikan" tersebut
meliputi pemasok dan penjualan barang dagangan yang mengurangi jumlah
uang dan kuantitas di tangan persediaan, masing-masing.
Hubungan yang mempengaruhi jumlah sumber daya terkadang
disebut sebagai saham / hubungan rendah karena keduanya mewakili aliran
masuk atau arus keluar sumber daya itu. Tidak setiap peristiwa secara
langsung mengubah jumlah sumber daya. namun. Sebagai contoh. pesanan
dari pelanggan mewakili komitmen yang pada akhirnya akan menghasilkan
penjualan barang dagangan masa depan, seperti pesanan ke pemasok
merupakan komitmen yang pada akhirnya akan menghasilkan pembelian
inventaris berikutnya. Untuk kesederhanaan. Gambar "-4 tidak termasuk
kejadian komitmen semacam itu yang dilakukan oleh organisasi. Namun,
perlu untuk melacak efits dari komitmen tersebut, baik untuk memberikan
layanan yang lebih baik dan untuk tujuan perencanaan. Sebagai
contoh. pesanan pelanggan mengurangi jumlah barang inventaris Tertentu
yang dipesan. Staf penjualan perlu mengetahui informasi ini agar dapat

28
melakukan pranata untuk menjawab pertanyaan dan pesanan cusromer
berikutnya. Perusahaan manufaktur dapat menggunakan informasi tentang
pesanan pelanggan untuk merencanakan produksi. Kemudian di bab ini kita
akan melihat bagaimana menambahkan peristiwa komitmen ke pola dasar
yang ditunjukkan pada Gambar l7-4.

ATURAN 2: SEGALA HAL-HAL YANG HARUS DILAKUKAN

SAMPAI PADA SATU ENTITAS LAINNYA Gambar 17-4 juga
menunjukkan bahwa acara Get Resource A terkait dengan acara Give
Resource B yang diberi label sebagai hubungan dualitas
ekonomi. Hubungan dualitas yang memberi-untuk-mendapatkan seperti itu
mencerminkan prinsip bisnis dasar bahwa organisasi biasanya terlibat dalam
kegiatan yang menggunakan sumber daya hanya dengan harapan
memperoleh beberapa sumber lain sebagai imbalan. Misalnya, acara
Penjualan. yang membutuhkan menyerah (menurun) persediaan. terkait
dengan acara Receive Cash. yang melibatkan mendapatkan (meningkatkan)
jumlah uang tunai. Gambar 17-5 menunjukkan bahwa setiap siklus
akuntansi dapat digambarkan dalam kaitannya dengan hubungan dualisme
ekonomi yang memberi-to-gt. Bagian bawah gambar juga menunjukkan
bahwa terkadang satu peristiwa dapat dihubungkan ke beberapa peristiwa
lainnya.

29
 Tidak semua hubungan antara dua peristiwa merupakan dualitas
ekonomi yang memberi-untuk-dapatkan. namun. Peristiwa komitmen terkait
dengan kejadian lain untuk mencerminkan hubungan sebab-akibat yang
diakibatkan. Sebagai contoh. acara Take Customer Order akan dikaitkan
dengan acara Penjualan untuk mencerminkan fakta bahwa pesanan tersebut
mendahului dan menghasilkan penjualan. Demikian pula, persediaan Order
(pembelian) acara akan dikaitkan dengan acara Receive Inventory untuk
mencerminkan hubungan sebab-akibat berurutan lainnya.
ATURAN 3: SETIAP EVENT ENTITY HARUS DILAKUKAN SAMPAI
SEKALI DUA BAGIAN YANG BERPENGALAMAN Untuk
pertanggungjawaban, organisasi harus dapat melacak tindakan
karyawan. Organisasi juga perlu memantau status komitmen dan pertukaran
dualitas ekonomi yang terlibat dengan pihak luar Dengan demikian, Gambar
17-4 menunjukkan setiap peristiwa yang terkait dengan dua entitas agen
yang berpartisipasi Untuk kejadian yang melibatkan transaksi dengan pihak
eksternal. agen internal adalah karyawan yang bertanggung jawab atas
sumber daya yang terkena dampak kejadian tersebut, dan agen eksternal
adalah pihak luar untuk transaksi tersebut. Untuk kejadian internal, seperti
pengalihan bahan baku dari kabin ke produksi, agen internal adalah
karyawan yang memberikan tanggung jawab untuk atau hak asuh atas
sumber daya, dan agen eksternal adalah karyawan yang menerima hak asuh
atau dengan asumsi tanggung jawab untuk sumber itu.

30
4.9 Pengembangan Diagram REA
Di bagian ini berfokus untuk mengembangkan diagram REA untuk
satu siklus bisnis. Pada bab berikutnya kita akan belajar bagaimana
mengintegrasikan diagram REA untuk siklus bisnis individu untuk
menciptakan satu diagram REA enterprise-wide.
Mengembangkan diagram REA untuk siklus bisnis tertentu terdiri dari
tiga Langkah berikut:
1. Mengidentifikasi kejadian tentang manajemen mana yang ingin
mengumpulkan informasi.
2. Mengidentifikasi sumber daya yang terpengaruh oleh setiap
peristiwa dan agen yang berpartisipasi dalam kejadian tersebut.
3. Tentukan kardinalitas masing-masing hubungan.
Mari kita ikuti tiga langkah ini untuk melihat bagaimana Paul
mengembangkan Gambar 17-6 untuk memodelkan siklus pendapatan Fred's
Train Shop.
4.9.1 Langkah 1 : Identifikasi Peristiwa yang Relavan
` Langkah pertama dalam mengembangkan model REA dari satu
siklus bisnis adalah mengidentifikasi kejadian yang menarik bagi
manajemen. Minimal, setiap model REA harus menyertakan dua kejadian
itu mewakili pertukaran bantuan ekonomi dasar yang dilakukan dalam
siklus bisnis tertentu (lihat Gambar 17-5) Biasanya ada acara lain yang
manajemen minati dalam perencanaan, pengendalian, dan
pemantauan; mereka juga perlu disertakan dalam model REA.

Pemahaman yang solid tentang acuvrtres yang dilakukan di setiap

siklus bisnis (lihat Bab l2-l6) diperlukan untuk mengidentifikasi kejadian
mana yang membentuk hubungan dualitas ekonomi memberi dasar. Sebagai

31
contoh.Bab l2 menjelaskan bahwa siklus pendapatan biasanya terdiri dari
empat aktivitas sekuensial:
1. Ambil pesanan pelanggan
2. Isi pesanan pelanggan
3. Bill pelanggan
4. Kumpulkan pembayaran dari pelanggan
Analisis aktivitas pertama, mengambil pesanan pelanggan. menunjukkan
bahwa itu tidak melibatkan keduanya perolehan sumber daya dari atau
penyediaan sumber daya ke pihak eksternal. Hanya komitmen untuk
melakukan tindakan semacam itu di masa depan. Aktivitas kedua. isi
pesanan pelanggan apakah mengurangi persediaan sumber daya organisasi
yang memiliki nilai ekonomis (inventarisasi) dengan mengantarkannya ke
pihak eksternal (pelanggan). Demikian. Ini merupakan contoh peristiwa
Give Resource prototipikal yang digambarkan pada Gambar l7-4. Aktivitas
ketiga. pelanggan penagihan melibatkan pertukaran informasi dengan
perusahaan eksternal namun tidak secara langsung meningkatkan atau
mengurangi jumlah sumber ekonomi apapun. Akhirnya.analisis aktivitas
keempat. mengumpulkan pembayaran dari pelanggan menunjukkan bahwa
hal itu menghasilkan peningkatan pasokan sumber daya ekonomi organisasi
(entitas yang diberi label "Kas" pada Gambar 17-6) sebagai hasil
penerimaan dari pihak eksternal (pelanggan). Demikian. Ini adalah contoh
acara TakeOtotypical Get Resource yang digambarkan pada Gambar l7-
4. Karena itu. Analisis aktivitas bisnis dasar yang dilakukan dalam siklus
pendapatan menunjukkan bahwa pertukaran ekonomi dasar memberikan-
untuk-dapatkan terdiri dari dua peristiwa: pesanan pelanggan (biasanya
disebut sebagai acara penjualan) dan mengumpulkan pembayaran dari
pelanggan (sering disebut Receive Cash peristiwa).
Dalam menggambar diagram REA untuk satu siklus bisnis. berguna
untuk membagi kertas menjadi tiga kolom, satu untuk setiap jenis
entitas. Gunakan kolom kiri untuk sumber daya, kolom tengah untuk
acara. dan kolom kanan untuk agen. Keterbacaan lebih ditingkatkan jika
entitas peristiwa ditarik dari atas ke bawah sesuai dengan urutan
kejadiannya. Jadi, Paul mulai menggambar Gambar 17-6 dengan
menempatkan entitas peristiwa Penjualan di atas entitas Aktivitas Menerima
Uang di kolom tengah kertas ".
Setelah peristiwa pertukaran ekonomi diidentifikasi. perlu untuk
menentukan aktivitas bisnis lain yang harus ditunjukkan sebagai kejadian
dalam model REA. Ini juga memerlukan pemahaman tentang masing-
masing kegiatan karena hanya aktivitas yang melibatkan perolehan
informasi baru yang perlu disertakan dalam model. Kembali ke contoh
kita. Paul mencatat bahwa dualitas ekonomi dari Sales and Receive Cash
secara akurat meningkatkan sebagian besar transaksi penjualan Store di
mana pelanggan memilih satu atau lebih barang dan
membayarnya. Terkadang, bagaimanapun juga. pelanggan menelepon toko
dan menanyakan apakah barang tertentu dapat disisihkan untuk pickup akhir

32
minggu itu. Untuk memastikan bahwa dia merujuk kembali item-item yang
populer secara tepat waktu, Fred hanya perlu untuk menyingkirkan barang-
barang itu selain juga untuk mencatat pesanan semacam itu di
sistem. Karena itu. Paul memutuskan untuk menambahkan acara komitmen
Ambil Customer Order ke diagram REA, menempatkannya di atas acara
Penjualan karena pesanan pelanggan mendahului acara Penjualan.
Paul kemudian mempertimbangkan kegiatan bisnis siklus
pendapatan lainnya. pelanggan penagihan Dia tahu bahwa di ~ penjualan
toko dibayar segera dan. karena itu. melakukan atau melibatkan langkah
"penagihan" terpisah Tapi Fred juga menjual kereta model ke pusat
perbelanjaan, hotel, dan institusi lain yang ingin membuat display musiman
untuk pelanggan mereka Penjualan seperti itu dilakukan secara kredit dan
Fred kemudian mempersiapkan dan mengirim surat faktur kepada pelanggan
tersebut Namun, faktur pencetakan dan pengiriman tidak secara langsung
meningkatkan atau mengurangi sumber daya ekonomi apapun. Aktivitas
penagihan juga tidak mewakili komitmen terhadap pertukaran ekonomi
masa depan: Kewajiban hukum pelanggan untuk membayar timbul dari
penyerahan barang dagangan. Dari pencetakan faktur, seperti yang dicatat
dalam Bab 12 dan 13, banyak organisasi mulai menyadari bahwa penagihan
adalah kegiatan tanpa nilai tambah yang dapat dihilangkan sepenuhnya.
Selain itu, percepatan mencetak faktur tidak menambahkan biaya baru.
informasi ke database.
Harga dan jumlah dari barang yang terjual dicatat pada saat
penjualan, dan pada saat itu syarat pembayaran juga disepakati. Dengan
demikian, aktivitas penagihan hanyalah sebuah kegiatan pemrosesan
informasi yang hanya dapat diambil: informasi dari database, mirip dengan
menulis Query atau mencetak laporan internal. Karena kejadian pencarian
informasi semacam itu tidak mengubah isi database, mereka tidak perlu
dimodelkan sebagai kejadian dalam diagram REA. Untuk semua alasan di
atas, Paul menyadari bahwa dia tidak perlu memasukkan acara penagihan
dalam diagram REA siklus pendapatan untuk Toko Kereta Fred.
Tapi bagaimana dengan piutang? Jika tidak ada acara penagihan,
bagaimana Toko Kereta Api Fred dapat memantau item neraca
ini? Solusinya terletak pada pemahaman bahwa piutang dagang hanyalah
perbedaan waktu antara dua komponen pertukaran ekonomi dasar dalam
siklus pendapatan: penjualan dan penerimaan pembayaran. Dengan kata
lain, piutang dagang sama dengan semua penjualan yang belum dibayar
pelanggan. Akibatnya, piutang dapat dihitung dan dipantau dengan hanya
mengumpulkan informasi tentang kejadian Penjualan dan Penerimaan
Tunai. Bab selanjutnya akan mengilustrasikan beberapa cara berbeda untuk
mengekstrak informasi tentang piutang dari database yang dibangun
menggunakan model data REA.
Akhirnya, perhatikan bahwa tidak ada kejadian yang berkaitan
dengan masuknya data. Alasan untuk ini adalah bahwa model data REA
digunakan untuk merancang database pemrosesan transaksi. Tujuannya

33
adalah untuk memodelkan aktivitas bisnis rantai nilai dasar sebuah
Organisasi: apa yang dilakukannya untuk menghasilkan revolsi dan
bagaimana Menghabiskan uang tunai dan menggunakan sumber dayanya
yang lain. Memasukkan data tentang kejadian tersebut dan tentang sumber
daya dan agen yang terkait dengannya biasanya tidak dianggap sebagai
aktivitas rantai nilai utama. Jadi, seperti menulis pertanyaan dan laporan
pencetakan, aktivitas entri data tidak dianggap sebagai peristiwa penting
tentang data terperinci yang perlu dikumpulkan. Apalagi seperti yang
dibahas di lima bab sebelumnya. Ada kecenderungan terus menerus
menggunakan teknologi untuk mengeliminasi kegiatan pengolahan
informasi klerik rutin, termasuk pemasukan data. Dengan demikian,
mungkin untuk memahami kejadian bisnis (seperti penjualan barang
dagangan) yang dilakukan tanpa memerlukan aktivitas entri data sepa ~
rate. Memang. banyak entri data sudah terjadi sebagai produk sampingan
untuk mewujudkan peristiwa bisnis yang termasuk dalam diagram
REA. Misalnya, kapan pun penjualan, pembelian, penerimaan uang tunai,
atau pembayaran terjadi, informasi tentang kejadian itu dimasukkan ke
dalam database. Demikian, Apa yang dimodelkan dalam diagram REA
adalah acara bisnis (misalnya, transaksi penjualan) dan fakta yang
manajemen ingin kumpulkan tentang kejadian itu, bukan masuknya data
tersebut.
4.9.2 Langkah 2 : Mengidentifikasi Sumber dan Agen
Setelah peristiwa yang relevan telah ditentukan, sumber daya yang
terpengaruh oleh peristiwa tersebut perlu diidentifikasi. Ini melibatkan
menjawab tiga pertanyaan:
1. Sumber daya ekonomi apa yang dikurangi dengan acara "Give"?
2. Sumber daya ekonomi apa yang diakuisisi oleh acara "Get"
3. Sumber daya ekonomi apa yang dipengaruhi oleh acara komitmen?
Sekali lagi, pemahaman yang solid tentang proses bisnis memudahkan
menjawab pertanyaan-pertanyaan ini. Untuk melanjutkan contoh kami, Paul
telah mengamati bahwa acara Penjualan melibatkan pemberian inventaris
kepada pelanggan dan bahwa acara Menerima Uang Tunai melibatkan
pembayaran (baik dalam bentuk uang, cek, kartu kredit, atau kartu debit)
dari pelanggan. Oleh karena itu, ia menambahkan entitas sumber Inventaris
ke diagram REA dan menghubungkannya ke entitas acara Penjualan. Entitas
persediaan menyimpan informasi tentang setiap produk yang dijual
Fred. Kemudian Paul menambahkan entitas sumber kas ke
diagram. Meskipun organisasi biasanya menggunakan banyak akun untuk
melacak kas dan setara kas (misalnya, akun cek operasi, kas kecil, dan
investasi jangka pendek), semua ini dilanjur dalam satu akun neraca yang
disebut Kas. Demikian pula, sumber daya Cash berisi informasi tentang
setiap akun tunai individu. Jadi, dalam database relasional, tabel "uang
tunai" akan berisi baris terpisah untuk setiap akun tertentu (misalnya, uang
kecil, rekening giro, dll.) Paul kemudian menghubungkan entitas sumber
"Kas" ke entitas acara Receive Cash. , acara Take Customer Order
melibatkan penyisihan barang dagangan untuk pelanggan tertentu Untuk

34
menjaga catatan inventaris yang akurat, dan untuk memudahkan penataan
ulang secara tepat waktu agar tidak stockout, masing-masing acara Take
Customer Order harus menghasilkan pengurangan jumlah barang inventaris
tersebut. Oleh karena itu, Paul menambahkan hubungan antara entitas
sumber Inventaris dan entitas aktivitas Take Customer Order di REA dia ~
gram yang dikembangkannya untuk siklus pendapatan Kereta Api Fred.
Selain menentukan sumber daya yang terpengaruh oleh setiap peristiwa,
juga perlu mengidentifikasi agen yang ParliCiPate dalam acara
tersebut. Akan selalu ada setidaknya satu agen internal (karyawan) dan,
dalam banyak kasus, agen eksternal (pelanggan atau vendor) yang
berpartisipasi dalam masing-masing
peristiwa. Dalam kasus siklus pendapatan Fred's Train Shop, pelanggan dan
penjual ikut serta dalam setiap acara Penjualan. Pelanggan dan kasir adalah
dua agen yang berpartisipasi dalam setiap Receive.
Aktivitas kas Baik wiraniaga maupun kasir adalah pegawai
Fred's. Dengan demikian, baik siklus pendapatan kegiatan pertukaran
ekonomi melibatkan dua jenis agen yang sama: karyawan (pihak internal)
dan pelanggan (pihak eksternal). Acara Take Customer Order juga
melibatkan pelanggan dan karyawan. Oleh karena itu, Paul menambahkan
kedua jenis agen ke diagram dan menarik hubungan untuk menunjukkan
agen mana yang berpartisipasi di mana acara Untuk mengurangi
kekacauan. kadang-kadang dia menghubungkan satu salinan entitas agen
tertentu ke dua entitas acara yang berdekatan ".
4.9.3 Langkah 3 : Tentukan Kardinalitas Hubungan
Langkah terakhir dalam menggambar diagram REA untuk satu
siklus transaksi adalah menambahkan informasi tentang kardinalitas
hubungan. Cardinalii'i menggambarkan sifat hubungan antara dua entitas
dengan menunjukkan berapa banyak contoh dari satu entitas yang dapat
dikaitkan dengan masing-masing instance spesifik dari entitas
lain. Pertimbangkan hubungan antara entitas agen pelanggan dan entitas
acara penjualan. Setiap entitas dalam diagram REA mewakili sebuah
himpunan. Misalnya, entitas Pelanggan mewakili set dari pelanggan
organisasi, dan entitas Penjualan mewakili serangkaian transaksi penjualan
individual yang terjadi selama periode fiskal berjalan. Setiap transaksi
pelanggan atau penjualan individual mewakili contoh spesifik dari entitas
tersebut. Jadi, dalam database relasional. setiap baris di tabel "Pelanggan"
akan menyimpan informasi tentang pelanggan tertentu, dan setiap baris di
tabel "Penjualan" akan menyimpan informasi tentang transaksi penjualan
tertentu. Kardinalitas menentukan berapa banyak transaksi penjualan
(instance dari entitas Penjualan) dapat dikaitkan dengan setiap pelanggan
(instance dari entitas Pelanggan) dan. Sebaliknya, berapa banyak pelanggan
yang bisa dikaitkan dengan setiap transaksi penjualan.
Tidak ada standar universal untuk mewakili informasi tentang
kardinalitas dalam diagram REA. Dalam teks ini, kita menggunakan gaya

35
notasi "crow's feet" grafis untuk mewakili informasi kardinalitas karena
semakin populer dan digunakan oleh banyak perancangan perangkat
lunak. Tabel l7-l menjelaskan arti dari simbol yang digunakan untuk
mewakili informasi kardinalitas, dan Focus l7-l membandingkan notasi yang
digunakan dalam buku ini dengan konvensi umum lainnya.

Sejumlah notasi berbeda ada untuk menggambarkan kardinalitas

minimum dan maksimum. Beberapa yang lebih umum alternatif kaki gagak
yang digunakan dalam teks ini ditunjukkan di sini.

Seperti ditunjukkan pada Tabel 17-], kardinalitas ditunjukkan oleh

sepasang simbol di samping entitas. Keempat baris pada Tabel 17-1
menggambarkan empat kemungkinan kombinasi minimum dan maksimum
kardinalitis.Kardinalitas minimum dapat berupa nol (0) atau satu
(1). tergantung pada apakah hubungan antara dua entitas adalah opsional
(kardinalitas minimum adalah nol; sec baris satu dan tiga) atau wajib
(kardinalitas minimum adalah salah satu seperti pada baris dua dan

36
empat.). Kardinalitas maksimum dapat berupa satu atau banyak (simbol kaki
gagak), tergantung pada apakah setiap contoh dari entitas A dapat
dihubungkan dengan paling banyak satu contoh (seperti di atas dua baris)
atau berpotensi banyak contoh dari entitas B (seperti dalam dua baris
bawah).
Mari sekarang kita menggunakan informasi pada Tabel 17-! untuk
menafsirkan beberapa cardinalitics pada Gambar 17-6. Lihatlah pertama di
hubungan Sale-pelanggan. Minimum dan maksimum cardinalitics sebelah
entitas Pelanggan keduanya satu. Pola ini sama dengan yang berturut-turut
dua pada Tabel, tutup. Demikian. kardinalitas minimum satu di sebelah
entitas Pelanggan pada Gambar l7-6 indi ~ isyarat bahwa setiap transaksi
penjualan (entitas A) harus dikaitkan dengan beberapa pelanggan tertentu
(entitas B). 171 :: kardinalitas maksimum satu berarti bahwa setiap
transacnon penjualan dapat dihubungkan dengan paling banyak hanya satu
pelanggan tertentu. Ini mencerminkan praktik bussines biasa: hanya satu
pelanggan diidentifikasi secara hukum (yang bisa menjadi seorang individu
atau bisnis) yang bertanggung jawab atas penjualan dan pembayaran
selanjutnya.
Sekarang lihat kardinalitas adalah nol, dan kardinalitas maksimum
adalah banyak. Nol kardinalitas maksimum berarti bahwa hubungan adalah
opsional: pelanggan tidak harus terkait dengan transaksi penjualan tertentu.
Hal ini memungkinkan Fred Kereta Shop untuk memasukkan informasi
tentang calon pelanggan kepada siapa dapat mengirim iklan sebelum mereka
pernah membeli apa-apa. Kardinalitas maksimum adalah banyak,
menunjukkan bahwa pelanggan specilic mungkin. dan Fred berharap akan,
dikaitkan dengan beberapa mactions penjualan (i.ew menjadi pelanggan
setia yang membuat pembelian berulang dari Fred Kereta Shop).Sekarang
perhatikan bahwa pasangan kardinalitas sebelah entitas persediaan pada
Gambar 116 memiliki minimal satu dan maksimal banyak untuk setiap
hubungan.
Ini adalah pola yang sama seperti berturut-turut empat pada Tabel “J.
Ini berarti bahwa everycustomer transaksi orderorsale harus melibatkan
setidaknya satu item persediaan (Anda tidak bisa menjual “apa-apa '? Tetapi
mungkin melibatkan beberapa item yang berbeda (misalnya. Pelanggan bisa
membeli kedua lokomotif dan mobil kereta api di TRANSAKSI sama ~
tion). Akhirnya . pemberitahuan bahwa pasangan kardinalitas sebelah entitas
Dijual di hubungannya dengan entitas Orde Ambil Pelanggan adalah seperti
pola berturut-turut salah satu Tabel 17-1. kardinalitas minimum dari nol
mencerminkan fakta bahwa perintah mungkin belum telah berubah menjadi
penjualan yang sebenarnya transactionThe kardinalitas maksimum satu
menunjukkan bahwa Fred's Kereta Shep tills semua pesanan pelanggan
secara penuh dan bukan dari pada membuat sejumlah 0' pengiriman parsial.
Anda harus dapat menafsirkan sisa Gambar 17-6 dengan mengikuti
proses yang sama hanya disajikan dengan membandingkan pasangan
kardinalitas sebelah setiap entitas ke {pola kami pada Tabel l7-l. Mari kita

37
memeriksa apa yang berbagai jenis hubungan berarti dan apa yang mereka
mengungkapkan tentang praktik bisnis organisasi.
4.9.4 Tiga Jenis Hubungan
Tiga tipe dasar dari hubungan antara entitas yang
possrble. tergantung pada kardinalitas maxmrum terkait dengan setiap
entitas (minimum,kardinalitas tidak masalah).
1. A (1 :1) hubungan satu-ke-satu ada saat kardinalitas maksimum untuk
setiap entitas dalam hubungan yang saya (lihat Gambar 17-7. Panel A).

2. Sebuah satu-ke-marty (1: N) hubungan terjadi ketika kardinalitas

maksimum satu entitas dalam hubungan adalah l dan kardinalitas
maksimum untuk entitas lain dalam hubungan yang banyak (lihat
Gambar 17-7, panel B dan C).
3. banyak ke banyak (M: N) hubungan terjadi ketika kardinalitas
maksimum untuk kedua entitas dalam hubungan adalah banyak
(Gambar 17-7, panel D).

Gambar 17-7 menunjukkan bahwa salah satu dari kemungkinan ini

mungkin menjelaskan hubungan antara Penjualan dan Menerima peristiwa Cash.
Pemodel data atau database desainer tidak bisa sembarangan memilih dari tiga
kemungkinan tersebut untuk digunakan saat menggambarkan berbagai hubungan.
Sebaliknya, cardi yang ~ nalities harus mencerminkan kebijakan bisnis organisasi.
Mari kita memeriksa apa yang masing-masing kemungkinan digambarkan dalam
Gambar 17-7 berarti. Gambar 17-7, panel A, menggambarkan satu-ke-satu (kl)
hubungan antara Penjualan dan Menerima peristiwa Cash. Kardinalitas maksimum
l terkait dengan Menerima entitas Cash berarti bahwa setiap peristiwa Sales
(transaksi) dapat dihubungkan dengan paling banyak satu Menerima acara Cash.
Ini akan sesuai untuk sebuah organisasi yang memiliki kebijakan bisnis tidak

38
memungkinkan pelanggan untuk melakukan pembayaran angsuran. Pada waktu
bersamaan,yang maximum'cardinality dari 1 terkait dengan setiap peristiwa Sale
berarti bahwa setiap pembayaran pelanggan menyampaikan terkait dengan paling
banyak satu acara penjualan. Ini akan sesuai untuk sebuah organisasi yang
memiliki kebijakan bisnis yang membutuhkan pelanggan untuk membayar setiap
transaksi penjualan secara terpisah. Dengan demikian, hubungan lzl digambarkan
dalam Gambar l7-7, panel A, mewakili hubungan siklus pendapatan khas untuk
bisnis-ke-konsumen penjualan ritel: Pelanggan harus membayar, secara penuh,
untuk setiap transaksi penjualan sebelum mereka diizinkan untuk meninggalkan
toko dengan barang dagangan mereka dibeli. Perhatikan bahwa tidak peduli
bagaimana pelanggan membayar untuk setiap transaksi penjualan (yaitu, dengan
uang tunai, cek, kartu kredit, atau kartu debit).

Terlepas dari metode yang digunakan, ada satu, dan hanya satu,
pembayaran terkait dengan setiap transaksi penjualan dan, sebaliknya, setiap
transaksi penjualan dikaitkan dengan satu,dan hanya satu, pembayaran dari
pelanggan (pembayaran dengan kartu debit dan kredit juga melibatkan penerbit
kartu, untuk kesederhanaan, agen thattransfer tidak termasuk dalam Gambar 17-6).
Jika manajemen tertarik pelacakan frekuensi bagaimana pelanggan memilih untuk
membayar, metode pembayaran mungkin disimpan sebagai atribut dari acara
Menerima Cash.

Panel B dan C dari Gambar l7-7 menggambarkan dua cara yang satu-ke-
banyak (l: N) hubungan dapat terjadi. Panel B menunjukkan bahwa setiap peristiwa
Penjualan dapat dikaitkan dengan banyak Menerima peristiwa Cash. Hal ini
menunjukkan bahwa organisasi memiliki kebijakan bisnis yang memungkinkan
pelanggan untuk melakukan pembayaran angsuran untuk organisasi penjualan. Jika
pelanggan menggunakan sumber pihak ketiga kredit, menjual ~ ing organisasi
menerima satu pembayaran penuh dari pihak ketiga untuk itu transaksi penjualan
tertentu; pelanggan mungkin melakukan pembayaran angsuran ke lembaga kredit,
tetapi mereka pembayaran tidak akan dimodelkan dalam diagram REA untuk
organisasi penjualan. (Pikirkan tentang hal ini: Organisasi jual tidak memiliki cara
pelacakan ketika salah satu pelanggan membayar sebagian dari tagihan kartu kredit
atau membuat pembayaran bulanan pada pinjaman bank). Situasi yang
digambarkan dalam Gambar l7-7, panel B.tidak, bagaimanapun, berarti bahwa
setiap transaksi penjualan dibayar di install' KASIH; Kardinalitas maksimum N
berarti bahwa beberapa transaksi penjualan dapat diangsur. Panel B dari Gambar
l7-7 juga menunjukkan bahwa setiap Menerima acara Kas terkait dengan paling
banyak satu acara Sale. Hal ini menunjukkan bahwa organisasi memiliki kebijakan
bisnis yang memerlukan pelanggan untuk membayar untuk setiap transaksi
penjualan secara terpisah dan tidak diizinkan untuk membangun sebuah saldo
rekening Selama periode waktu. Dengan demikian, Gambar 17-7, panel B,
merupakan siklus pendapatan dari suatu organisasi yang mungkin menjual barang-
barang besar-tiket. Harus kembali pelanggan dan melakukan pembelian lain, satu
set terpisah dari pembayaran angsuran akan dibuat untuk secara terpisah melacak
berapa banyak yang telah dibayar untuk setiap transaksi penjualan.berarti bahwa
setiap transaksi penjualan dibayar di install' KASIH; Kardinalitas maksimum N
berarti bahwa beberapa transaksi penjualan dapat diangsur. Panel B dari Gambar
l7-7 juga menunjukkan bahwa setiap Menerima acara Kas terkait dengan paling
banyak satu acara Sale. Hal ini menunjukkan bahwa organisasi memiliki kebijakan
bisnis yang memerlukan pelanggan untuk membayar untuk setiap transaksi
penjualan secara terpisah dan tidak diizinkan untuk membangun sebuah saldo
rekening Selama periode waktu. Dengan demikian, Gambar 17-7, panel B,

39
merupakan siklus pendapatan dari suatu organisasi yang mungkin menjual barang-
barang besar-tiket. Harus kembali pelanggan dan melakukan pembelian lain, satu
set terpisah dari pembayaran angsuran akan dibuat untuk secara terpisah melacak
berapa banyak yang telah dibayar untuk setiap transaksi penjualan.berarti bahwa
setiap transaksi penjualan dibayar di install' KASIH; Kardinalitas maksimum N
berarti bahwa beberapa transaksi penjualan dapat diangsur. Panel B dari Gambar
l7-7 juga menunjukkan bahwa setiap Menerima acara Kas terkait dengan paling
banyak satu acara Sale. Hal ini menunjukkan bahwa organisasi memiliki kebijakan
bisnis yang memerlukan pelanggan untuk membayar untuk setiap transaksi
penjualan secara terpisah dan tidak diizinkan untuk membangun sebuah saldo
rekening Selama periode waktu. Dengan demikian, Gambar 17-7, panel B,
merupakan siklus pendapatan dari suatu organisasi yang mungkin menjual barang-
barang besar-tiket. Harus kembali pelanggan dan melakukan pembelian lain, satu
set terpisah dari pembayaran angsuran akan dibuat untuk secara terpisah melacak
berapa banyak yang telah dibayar untuk setiap transaksi penjualan.Kardinalitas
maksimum N berarti bahwa beberapa transaksi penjualan dapat diangsur. Panel B
dari Gambar l7-7 juga menunjukkan bahwa setiap Menerima acara Kas terkait
dengan paling banyak satu acara Sale. Hal ini menunjukkan bahwa organisasi
memiliki kebijakan bisnis yang memerlukan pelanggan untuk membayar untuk
setiap transaksi penjualan secara terpisah dan tidak diizinkan untuk membangun
sebuah saldo rekening Selama periode waktu. Dengan demikian, Gambar 17-7,
panel B, merupakan siklus pendapatan dari suatu organisasi yang mungkin menjual
barang-barang besar-tiket. Harus kembali pelanggan dan melakukan pembelian
lain, satu set terpisah dari pembayaran angsuran akan dibuat untuk secara terpisah
melacak berapa banyak yang telah dibayar untuk setiap transaksi
penjualan.Kardinalitas maksimum N berarti bahwa beberapa transaksi penjualan
dapat diangsur. Panel B dari Gambar l7-7 juga menunjukkan bahwa setiap
Menerima acara Kas terkait dengan paling banyak satu acara Sale. Hal ini
menunjukkan bahwa organisasi memiliki kebijakan bisnis yang memerlukan
pelanggan untuk membayar untuk setiap transaksi penjualan secara terpisah dan
tidak diizinkan untuk membangun sebuah saldo rekening Selama periode waktu.
Dengan demikian, Gambar 17-7, panel B, merupakan siklus pendapatan dari suatu
organisasi yang mungkin menjual barang-barang besar-tiket. Harus kembali
pelanggan dan melakukan pembelian lain, satu set terpisah dari pembayaran
angsuran akan dibuat untuk secara terpisah melacak berapa banyak yang telah
dibayar untuk setiap transaksi penjualan.Hal ini menunjukkan bahwa organisasi
memiliki kebijakan bisnis yang memerlukan pelanggan untuk membayar untuk
setiap transaksi penjualan secara terpisah dan tidak diizinkan untuk membangun
sebuah saldo rekening Selama periode waktu. Dengan demikian, Gambar 17-7,
panel B, merupakan siklus pendapatan dari suatu organisasi yang mungkin menjual
barang-barang besar-tiket. Harus kembali pelanggan dan melakukan pembelian
lain, satu set terpisah dari pembayaran angsuran akan dibuat untuk secara terpisah
melacak berapa banyak yang telah dibayar untuk setiap transaksi penjualan.Hal ini
menunjukkan bahwa organisasi memiliki kebijakan bisnis yang memerlukan
pelanggan untuk membayar untuk setiap transaksi penjualan secara terpisah dan
tidak diizinkan untuk membangun sebuah saldo rekening Selama periode waktu.
Dengan demikian, Gambar 17-7, panel B, merupakan siklus pendapatan dari suatu
organisasi yang mungkin menjual barang-barang besar-tiket. Harus kembali
pelanggan dan melakukan pembelian lain, satu set terpisah dari pembayaran
angsuran akan dibuat untuk secara terpisah melacak berapa banyak yang telah
dibayar untuk setiap transaksi penjualan.satu set terpisah dari pembayaran angsuran
akan dibuat untuk secara terpisah melacak berapa banyak yang telah dibayar untuk
setiap transaksi penjualan.satu set terpisah dari pembayaran angsuran akan dibuat

40
untuk secara terpisah melacak berapa banyak yang telah dibayar untuk setiap
transaksi penjualan.

Gambar l7-7, panel C, menunjukkan jenis lain dari l: N hubungan antara

Penjualan dan Menerima peristiwa Cash. dalam hal ini, setiap peristiwa Sale dapat
dihubungkan dengan paling banyak satu Menerima acara Cash. Hal ini
menunjukkan bahwa organisasi memiliki kebijakan bisnis yang tidak mengizinkan
pelanggan untuk melakukan pembayaran angsuran. Gambar l7-7, panel C, juga
menunjukkan bahwa setiap Menerima acara Cash dapat dikaitkan dengan banyak
peristiwa Sale yang berbeda. Hal ini menunjukkan adanya kebijakan bisnis yang
memungkinkan pelanggan untuk membuat sejumlah pembelian selama periode
waktu (misalnya, satu bulan) dan kemudian membayar pembelian mereka dengan
satu kali pembayaran. Situasi yang digambarkan dalam Gambar l7-7, panel C,
adalah sangat umum, terutama untuk bisnis-ke-busmess penjualan barang tahan
lama.

Gambar “-7, panel D. menggambarkan banyak-banyak (MN) hubungan

antara Penjualan dan Menerima peristiwa Cash Hal ini menunjukkan bahwa setiap
peristiwa Penjualan mungkin terkait dengan satu atau lebih Menerima Cash acara
persediaan-penjualan akan 1. kardinalitas maksimum di sisi persediaan hubungan
masih akan banyak. Namun, karena sebagian besar organisasi akan dengan senang
hati menjual banyak item kasar-jenis yang berbeda sebagai pelanggan ingin dan
mampu untuk membeli.

Kardinalitas minimum di setiap sisi hubungan persediaan-acara

digambarkan pada Gambar 17-6 juga mencerminkan praktek bisnis yang khas.
Fred Kereta Toko, seperti banyak organisasi ritel, hanya menjual persediaan fisik.
Oleh karena itu, setiap order atau penjualan acara harus terkait dengan setidaknya
satu item persediaan; karenanya, kardinalitas minimum pada sisi persediaan dari
hubungan persediaan-event adalah l. Kardinalitas minimum pada sisi acara kapal-
kapal hubungan, bagaimanapun, adalah 0, untuk alasan yang sama bahwa itu
adalah 0 di agen ~ hubungan acara.

Sekarang mempertimbangkan hubungan antara sumber daya kas dan

Menerima Cash acara. Gambar 17-6 menggambarkan ini sebagai al: hubungan N,
yang mencerminkan praktik terbaik diikuti oleh sebagian besar organisasi dengan
kontrol internal yang baik. Setiap penerimaan kas dari pelanggan disimpan dalam
satu rekening kas, biasanya rekening umum organisasi. Bendahara subse »quently
transfer uang dari akun ke rekening kas lainnya (misalnya-, gaji, memeriksa,
investasi, dll) yang diperlukan. Kardinalitas minimum di setiap sisi hubungan ini
juga khas. Setiap pembayaran pelanggan harus disetorkan ke beberapa rekening;
maka kardinalitas minimum adalah l di sisi sumber daya hubungan.
Sebaliknya,kardinalitas minimum pada sisi acara hubungan adalah 0 untuk alasan
yang sama bahwa itu adalah O di agen-event dan persediaan-event hubungan
seperti yang dibahas sebelumnya.

Akhirnya, mari kita menguji hubungan event-event yang digambarkan

pada Gambar 17-6. Fred Kereta Toko kapal setiap pesanan pelanggan bisnis secara
individual dan menunggu sampai semua item dalam stok sebelum mengisi
perintah. Demikian. setiap pesanan terkait dengan hanya satu transaksi penjualan
dan setiap transaksi penjualan berhubungan dengan hanya satu urutan. Oleh karena
itu, Paul memiliki model hubungan antara Orde Ambil Pelanggan dan acara
Penjualan sebagai l: l. Kardinalitas minimum pada sisi penjualan hubungan adalah
0. arti bahwa Pesanan mungkin ada yang tidak terkait dengan penjualan. Hal ini

41
mencerminkan urutan temporal antara dua peristiwa: Pesanan sebelum penjualan,
sehingga pada setiap titik waktu tertentu. Fred Kereta Toko mungkin memiliki
perintah yang belum diisi. Fred Kereta Toko tidak, namun. mengharuskan setiap
penjualan didahului dengan perintah; memang, sementara banyak penjualan untuk
pelanggan korporat didahului oleh perintah, berjalan-dalam penjualan ke konsumen
tidak. Oleh karena itu, Paul Stone telah dimodelkan kardinalitas minimum pada sisi
urutan hubungan penjualan-order sebagai 0.

Paulus juga telah belajar bahwa Fred Kereta Toko meluas kredit kepada
pelanggan bisnis dan mail mereka pernyataan bulanan daftar semua pembelian
yang belum dibayar. Ia juga menemukan bahwa banyak pelanggan bisnis mengirim
Fred satu cek untuk menutupi semua pembelian mereka selama jangka waktu
tertentu. Dengan demikian, salah satu Menerima acara Cash dapat dikaitkan
dengan banyak peristiwa Sale yang berbeda. Namun. Fred Kereta Shop juga
memungkinkan pelanggan bisnis untuk melakukan pembayaran angsuran
pembelian besar; dengan demikian, acara Sale diberikan dapat terhubung ke lebih
dari satu Menerima acara Cash. Itulah sebabnya Paulus memiliki model hubungan
antara Sale dan Menerima peristiwa Kas sebagai banyak-ke-banyak.

42
 5 DAFTAR PUSTAKA

SilberschatzAbraham, GalvinPeterBaer, GagneGreg Operating System

Concepts Essentials．Jefferson City，John Wiley & Sons, Inc.，2011，

pp.457-491．

43