Audit Sistem Informasi Bab.

9 Operasi Sistem Informasi

Disusun Oleh : Nova Widyantoro A12.2009.03446 Deny Sandi T A12.2009.03443 Erwin W A12.2001.00808

UNIVERSITAS DIAN NUSWANTORO SEMARANG

2011/2012

BAB 9 : Operasi Sistem Informasi Bab ini membahas tentang bagaimana mengaudit operasi system informasi dari sudut pandang yang lebih luas. Termasuk juga didalamnya berbagai contoh nyata dari ketidak-efisien dan kelemahan control internal yang berkaitan dengan Operasi Sistem Informasi. Beberapa dari kontrol operasi komputer yang dibahas dalam bab ini berkaitan erat dengan kontrol keamanan fisik, yang dibahas lebih rinci dalam bab 7. Operasi sistem informasi meliputi kontrol internal pada fasilitas pengolahan data agar sebaik dan setepat yang diharapkan oleh pengguna akhir.yang didesain untuk membantu proses operasi organisasi agar berfungsi se-efisien dan se-efektif mungkin dalam batasan yang dikenakan dari segi ekonomi, keuangan, politik, hukum, dan peraturan lingkungan.karena seluruh opersai dalam sebuah organisasi saling bergantung, Audit seharusnya tidak melihat operasi sistem informasi sebagai suatu fungsi yang benarbenar terpisah dari operasi lainnya dalam suatu organisasi. Itu semua sebenarnya merupakan bagian yang sama dari Sistem Informasi yang besar. Itu semua membentuk suatu input, pengolahan dan output yang komprehensif, yang bekerja untuk mencapai tujuan strategis jangka panjang perusahaan.karena itu ketika memeriksa operasi sistem informasi, auditor harus mempertimbangkan keseluruhan dampak dari in-efisiensi dan prosedur tidak efektif pada kemampuan perusahaan untuk mencapai tujuan jangka panjang. Dengan proliferasi sistem pemrosesan data terdistribusi dalam beberapa tahun terakhir, operasi sistem informasi dari berbagai skala telah terwujud di beberapa lokasi dalam kebanyakan organisasi. Komputer dan perngkat keras perifer yang terkait dapat eksis secara terpusat, seperti di sebuah pusat data yang besar, serta disetiap lokasi fisik di perusahaan, seperti pada kasus wide area network (WAN) yang memungkinkan semua proses pertukaran data dapat terjadi secara elektonik. Dalam operasi sistem informasi ini, masing-masing area fungsional bertanggung jawab melakukan proses dalam kontrol yang dapat dipertanggungjawabkan. Karena seberapa luas pun operasi sistem informasi. Semua auditor harus dapat akrab dengan pendekatan yang diperlukan untuk menilai kecukupan mereka. Untuk memberikan pendekatan tingkat tinggi, operasi sistem informasi dalam suatu organisasi dapat dibagi menjadi 2 komponen yang saling berhubungan : operasi komputer dan operasi bisnis. Komputer operasi Operasi komputer terdiri dari proses sistem informasi yang menjamin bahwa data input diproses dengan cara yang efektif dan efisien untuk mendukung tujuan strategis dan operasional usaha suatu organisasi. Audit operasi komputer harus mencakup penilaian pengendalian internal yang memastikan bahwa :

Pekerjaan produksi harus diselesaikan secara tepat waktu dan kapasitas produksi cukup untuk memenuhi kebutuhan operasi jangka pendek dan panjang. Media output didistribusikan secara tepat waktu, akurat dan aman Backup dan prosedur pemulihan cukup melindungi data dan program terhadap kecelakaan atau disengaja kehilangan atau kerusakan. Prosedur pemeliharaan perangkat keras komputer cukup melindungi terhadap kegagalan Perangkat keras, perangkat lunak dan data yang tertanggung dalambiaya pergantian Prosedur manajemen masalah memastikan bahwa masalah sistem didokumentasikan dan diselesaikan secara efektif dan tepat waktu.

Pengawasan dan penjadwalan kerja produksi Penjadwalan kerja secara otomatis dan inisiasi perangkat lunak secara signifikan dapat meningkatkan efisiensi operasional dengan secara otomatis memulai program produksi berikutnya yang dijadwalkan segera setelah program yang sebelumnya telah selesai. Setiap pekerjaan harus diberikan sebuah nomor prioritas (misalnya, 1 sampai 9, dengan 1 memiliki prioritas tertinggi), yang memungkinkan software penjadwalan kerja untuk memulai program dengan prioritas tertinggi pertama kali. Sementara operator komputer masih perlu untuk memantau antrian program jika ada kegagalan program yang abnormal dan kadang-kadang mungkin perlu untuk mengubah urutan inisiasi program. Perangkat lunak semaacm ini secara signifikan mengurangi kebutuhan bagi operator komputer untuk menginisiasi secara manual. Dengan demikian membebaskan mereka untuk melakukan tugas lain. Program penjadwalan kerja secara otomatis juga mengurangi resiko bahwa mungkin operator komputer menjalankan program keluar dari urutan atau lupa menjalankan satu program samasekali. Ketika program dijalankan keluar dari urutan atau tidak berjalan sama sekali, output data berikutnya tidak dapat benar karena tergantung pada data terbaru dari program yang seharusnya selesai sebelumnya. Untuk memantau efektifitas program penjadwalan kerja otomatis, manajemen dibagian operasi komputer harus menerima laporan produksi harian termasuk waktu mulai dan selesainya dari masing-masing pekerjaan.dan sebaiknya dibandingkan dengan jadwal produksi yang direncanakan, dan pekerjaan apapun yang dinilai abnormal dapat dihentikan. Informasi ini memberikan suatu alat dimana managemen dapat menilai apakah pekerjaan yang telah diselesaikan secara tepat waktu dan sesuai dengan jadwal yang disepakati.masalah mungkin dapat diidentifikasikan sebagai kebutuhan untuk mengubah urutan dari pekerjaan yang telah dijadwalkan agar lebih mengefisiensi kemampuan dalam pemanfaatan sistem pengolahan. Manajemen juga dapat mengamati bilamana ada banyak pekerjaan yang abnormal yang harusnya dihentikan. Kegiatan tersebut dapat menunjukan masalah dari sistem pemrograman atau kebutuhanuntuk mempeluas kapasitas produksi dari perangkat keras sistem. Kontrol pemantauan lainnya yang harus ada mencakup pemerikasan jumlah ketersediaan disk penyimpanan dan pemanfaatan kapasitas sistem dinamik secara

berkala. Meneliti jumlah disc yang tersedia dalam ruang penyimpanan itu mirip dengan memeriksa jumlah ruang disk yang tersedia pada hard drive dari sebuah komputer pribadi. Pemanfaatan kapasistas sistem dinamis lebih sulit untuk ditentukan. Konrol pemantauan ini melibatkan pelacakan persantase total kapasitas sistem pengolahan yang digunakan selama periode waktu tertentu, sepert satu hari, satu minggu, satu bulan, atau satu tahun. Akan lebih baik untuk sistem jika dapat mecatat informasi ini secara otomastis dan menghasilkan laporan manajemen untuk periodde yang diinginkan. Informasi ini dapat membantu manajemen dalam pemeliharaan sistem penjadwalan, perencanaan jadwal produksi dan mengidentifikasi bila mana sistem telah mencapai tingkat pemanfaatan kapasitas yang memerlukan peningkatan sistem untuk mengakomodasikan volume pengolahan data yang lebih tinggi. Beberapa sistem yang lebih canggih dapat diprogram ke halaman atau email administrator sistem jika kapasitas pengolahan telah ditentukan atau ambang penyimpanan data telah terlampaui. Studi kasus 9.1 Menggambarkan beberapa kelemahan dalam pengendalian internal terkait dengan penjadwalan pekerjaan dan monitoring di area operasi komputer suatu organisasi. Ini mencakup SK9.1 yang merupakan sebuah gambaran 10 jam dari jenis laporan yang manajemen dapat gunakan untuk memantau penyimpanan data dan kapasitas pengolahan dinamis pada jaringan tertentu di CPU. Diketahui bahwa kapasitas CPU mulai meningkat secara dramatis setelah jam 8 pagi, ketika para pekerja mulai log on ke jaringan dan melakukan berbagai fungsi. Puncak pemrosesan terjadi antara jam 10 dan tengah hari, ketika produktivitas kerja mencapai puncaknya. Pada tengah hari dapat dipastiikan ada penurunan yang terjadi ketia para pekerja pergi makan siang, dan akan meningkat ketika para pekerja kembali dari makan siang, setelah jam 2 pemrosesan CPU akan menurun secara signifikan ketika para pekerja mulai menyelesaikan pekerjaan mereka. Studi Kasus 9.1 : kurangnya program penjadwalan kerja otomatis dan pemantauan kontrol pemanfaatan kapasitas. Selama audit dari departemen operasi komputer suatu organisasi, tercatat bahwa program sedang dieksekusi secara manual oleh operator komputer. Setelah menyelesaikan pekerjaan, sistem akan tetap menganggur sampai seorang operator komputer memasukan nama pekerjaan berikutnya. Kenyataan bahwa pekerjaan yang tidak secara otomatis dieksekusi menciptakan resiko bahwa operator bisa memulai pekerjaan keluar dari urutan atau bisa lupa untuk memulai pekerjaan seluruhnya. Begitu juga, jika operator menjadi sibuk dengan masalah yang lain, dia tidak mungkin meliat ketika pekerjaan yang tidak nomal dihentikan. Situasi ini dapat menyebabkan penundaan serius dalam jadwal operasi produksi jika sebuah pekerjaan besar yang membutuhkan waktu untuk menjalankannya ternyata berhenti. Dan operator tidak menyadari ini dalam beberapa waktu. Akibatnya ada peluang yang signifikan untuk meningkatkan efisiensi dan efektivitas penjadwalan pekerjaan dan inisialisasi. Sistem aplikasi perangkat lunak yang berlisensi dari vendor, dan vendor dilaporkan menawarkan modul yangakan memungkinkan penjadwalan pekerjaan secara otomatis dan inisiasi dengan aplikasi yang sudah ada. Oleh karena itu, direkomendasikan

bahwa manajemen dari departemen operasi komputer menghubungi vendor untuk menentukan apakah akan ada biaya efektif untuk memperoleh penjadwalan kerja otomatis dan inisisasi perangkat lunak Ada pula ketika tidak ada laporan atau kontrol lain untuk memungkinkan departemen operasi komputer untuk memantau secara dinamis dari pemanfaatan kapasitas sistem selama periode tertentu. Dalam kasus ini, managemen melaporkan bahwa vendor, yang juga reseller hardware berlisensi yang digunakan oleh organisasi, bisa memasok laporan pemanfaatan kapasitas sistem dinamis, menunjukan poin tinggi dan rendah output komputasi yang diinginkan. Sayangnya, manajemen melaporkan bahwa vendor dapat menyediakan laporan hanya secara permintaan individual, tidak secara berkelanjutan. Selain itu, manajemen di departemen operasi komputer tidak mempertimbangkan kurangnya laporan untuk menjadi perhatian yang signifikan. Mereka merasa bahwa mereka menyadari kinerja sistem dan tahu kapan mereka akan perlu mengupgrade. Meskipun kita tahu bahwa manajemen tidak setuju dengan rekomendasi kami, kita masih merekomendasikan manajemen yang mempertimbangkan bekerja sama dengan vendor untuk menghasilkan laporan periodik menunjukan utilisasi kapasitas sistem dari waktu ke waktu. Dengan cara ini, kami mendokumentasikan fakta bahwa kita telah mengidentifikasi masalah ini dan disajikan rekomendasi yang layak untuk manajemen, bahkan jika mereka memilih untuk tidak menerapkan perubahan. Sebuah alternatif yang primitif tapi kadang-kadang efektif untuk pemantauan kinerja sistem pada dasar pengecualian adalah untuk memeriksa jumlah dan jenis panggilan dalam sistem bantuan. Jika sistem lambat untuk merespon atau jika itu benarbenar dimatikan karena kelebihan kapasitas atau masalah lain, pengguna mau tak mau memanggil bagian pembantu untuk mananyakan ketika sistem akan hidup atau berjalan kembali atau untuk sekedar mengeluh. Jika panggilan secara akurat dicatat sebagai waktu dan klasifikasi dari jenis masalah, sebuah grafik yang mewakili ketika degradasi kinerja sistem dapat diciptakan. Namun grafik tidak akan mengidentifikasi periode dari pemanfaatan kapasitas sistem yang rendah. Informasi tersebut membantu manajer sistem informasi mengidentifikasi ketika aktivitas sistem tertentu(misalnya, program batch) dapat dijalankan dengan lebih megoptimalkan pemanfaatan kapasitas sistem. Fluktuasi total penyimpanan data kapasitas secara umum jauh lebih datar dari fluktuasi pemrosesan CPU. Kapasitas memuncak pada pukul 10 pagi, mungkin sebagi puncak produktivitas pekerja diperlukan penyimpanan sementara untuk beberapa file data baru. Dan pada jam 4 sore total pemanfaatan penyimpanan data menurun kembali ke aslinya hampir sama saat awal pada jam 6 pagi. Karena pengguna jaringan akan membersihkan data yang berlebihan atau tidak perlu sebelum berakhirnya hari kerja mereka. Sayangnya, banyak sistem yang tidak memberikan kemepuan untuk memantau pemanfaatan kapasitas sistem secar dinamis. Study kasus 9.1 menunjukan : Pemanfaatan kapasitas penyimpanan data dan CPU harian.

Output dari media distribusi Banyak pekerjaan produksi yang menghasilkan data keluaran elektronik. File-file output ini di simpan dalam antrian sementara yang kadang-kadang disebut SPOOL , yang merupakan singkatan dari Simultaneous Peripheral Operation Online (perangkat simultan operasi online). File output pada SPOOL dapat diicetak, disalin ke direktori lain, atau keduanya, tergantung pada persyaratan dari pemilik data. Kegiatan ini harus dilakukan oleh area pendistribusian output secara tepat waktu sehingga pemilik data dapat memanfaatkan informasi secara efektif. File output juga harus dibersihkan dari SPOOL secara teratur, biasanya dalam satu atau dua hari, dalam rangka untuk membebaskan ruang disk penyimpanan. Media output fisik ( kertas catakan, microfis dan mikro film) harus di kontrol dengan ketat untuk mamastikan bahwa personil yang tidak sah tidak dapat melihat atau mendapatkan informasi sensitif. Demikian pula, akses logis untuk file SPOOL harus diberikan hanya untuk staf operasi komputer dan administrator keamanan sistem yang memerlukan. Ini adalah kontrol penting karena pengguna tidak sah dengan akses ke SPOOL bisa dengan cepat melihat, menyalin, dan mungkin mengubah berbagai file data yang mengandung informasi sensitif. Studi Kasus 9.2 menggambarkan bagaimana informasi sensitif yang dikompromi, banyak menggung malu dari departemen audit internal.

Studi Kasus 9.2: SPOOL file yang tidak terlindungi

Depatemen audit internal dari institut lembaga keuangan yang besar melakukan kejutan dengan mengaudit cabang dimuali pada hari senin. Bebrapa laporan aktivitas keuangan yang dihasilkan oleh departemen audit internal selama pertengahan minggu sebelumnya dicetak pada hari jumat sebelum audit di mulai. Seorang pengguna di pusat data memiliki sistem kemampuan akses yang memungkinkan dia untuk melihat SPOOL berisi program-program produksi yang baru saja selesai, termasuk departemen audit internal. Dari pengalamannya, pengguna tahu bahwa laporan standar tertentu dimulai setiap minggu oleh departemen audit internal yang dilakukan pada awal sebagai audit kejutan untuk cabang.karena pengguna memiliki seorang teman yang adalah seorang auditor internal cabang. Dia pikir dia akan memamerkan pengetahuannya dengan melihat SPOOL di laporan audit internal untuk mengetahui cabang mana yang akan diaudit berikutnya. Kemudian pada hari seni pagi, sebelum para auditor tiba untuk melakukan audit kejutan. Wanita tersebut terlebih dahulu menghubungi cabang dan meninggalkan pesan untuk auditor cabang. Hal ini tentu saja menghapus semua elemen kejutan dalam audit.auditor menerima pesannya sesaat setelah audit dimulai. Banyak yang mencemaskan tentang auditor yang bertanggung jawab.

Pengguna di pusat data ditegur atas tindakannya, dan kontrol ditempatkan di tempat dimana file hasil audit internal yang secara otomatis dipindahkan ke sebuah direktori terlindungi setelah selesainya program untuk mencegah kejadian serupa. Prosedur-prosedur cadangan (backup) dan Pemulihan. Seperti dibahas dalam Bab 7, setiap organisasi harus memiliki rencana kelangsungan bisnis. Sebagai bagian dari rencana, prosedur harus ada untuk cukup melindungi data dan program terhadap kecelakaan atau kehilangan atau kerusakan yang disengaja. Kontrol utama untuk memberikan perlindungan ini adalah untuk melakukan backup secara periodik (harian, mingguan, bulanan) dari perangkat lunak sistem, program aplikasi, dan data termasuk penyimpanan dan rotasi media backup seperti kaset magnetik, disk, dan compact disk (CD) ke lokasi off-situs aman. Backup harian biasanya diperlukan hanya untuk data sejak program aplikasi dan perangkat lunak sistem tidak berubah secara signifikan Backup penuh dari seluruh sistem, termasuk perangkat lunak sistem, program aplikasi, dan data, harus dilakukan mingguan atau bulanan, tergantung pada jumlah dan jenis perubahan yang telah dibuat. Kendali sistem backup juga harus dilakukan pada penyelesaian upgrade besar atau perubahan yang signifikan terhadap operasional dan keamanan parameter sistem. Selain itu, manajemen harus memastikan bahwa tes dilakukan untuk memastikan bahwa sistem operasi pada kenyataannya dapat sepenuhnya dikembalikan dengan menggunakan media backup. Ini adalah salah satu tes yang sering diabaikan Lihat Bab 7 untuk informasi tambahan dan contoh-contoh topik backup berkala dan program kelangsungan bisnis.

Prosedur-prosedur pemeliharaan. Semua perangkat keras komputer harus diservice sesuai dengan rekomendasi produsen sesuai dengan yang ditentukan dalam kontrak dengan vendor perangkat keras. Prosedur perawatan yang memadai harus dapat melindungi perangkat keras komputer terhadap kegagalan/kerusakan selama masa pemanfaatan yang diharapkan dari peralatan tersebut. Pada sebagian besar contoh, pemeliharaan yang tepat juga merupakan prasyarat agar jaminan produsen pada kinerja peralatan untuk tetap berlaku. Untuk alasan ini, penting bahwa setiap organisasi memelihara catatan akurat dari semua perawatan yang dilakukan. Tergantung pada jenis peralatan yang ditempatkan dalam sebuah organisasi, vendor teknisi atau subkontraktor mungkin perlu untuk melakukan pemeliharaan yang diperlukan. Jika demikian, biaya dan ketersediaan dari prosedur pemeliharaan yang sifatnya rutin dan tidak rutin harus didokumentasikan dalam kontrak dengan vendor atau subkontraktor. Sebelum memungkinkan pemeliharaan harus dilakukan oleh teknisi inhouse, manajemen harus meninjau isi kontrak untuk memastikan bahwa setiap jaminan tidak akan batal kalau teknisi nonvendor melakukan pemeliharaan. Kontrak dapat memungkinkan teknisi nonvendor untuk melakukan perawatan, tetapi mengharuskan

mereka untuk menjadi ahli bersertifikat di bidang teknologi pemeliharaan sebagai garansi untuk tetap berlaku

Asuransi Seperti dibahas dalam Bab 7, setiap organisasi harus membeli asuransi dalam jumlah yang cukup memadai untuk mencakup semua perangkat keras komputer dan perangkat lunak di biaya penggantian, biaya untuk menciptakan kembali setiap data yang hilang, dan mungkin nilai pendapatan yang hilang yang merupakan akibat langsung dari kegagalan perangkat keras atau perangkat lunak komputer. Kebijakan asuransi mungkin mengharuskan prosedur pemeliharaan rutin yang ditentukan oleh produsen komputer dilakukan agar cakupan untuk tetap berlaku. Kebijakan mungkin juga menentukan bahwa perangkat lunak dan data backup dibuat dan disimpan di mengamankan lokasi off-situs yang aman dengan jadwal harian, mingguan atau bulanan. Penurunan harus ditetapkan pada tingkat yang memberikan keseimbangan yang wajar antara premi tahunan dan jumlah cakupan keseluruhan. Lihat Bab 7 untuk informasi tambahan dan contoh-contoh pada cakupan asuransi Masalah Manajemen Jumlah dan jenis masalah sistem yang timbul harus dilog secara hati-hati untuk membantu memastikan bahwa masalah sistem didokumentasikan dan diselesaikan secara tepat waktu dan efektif. Beberapa organisasi mempertahankan pusat Departemen Bantuan yang bidang pertanyaan melalui telepon berbagai pengguna, termasuk yang berkaitan dengan masalah sistem. Organisasi-organisasi lain mungkin memerlukan pemilik proses dari setiap sistem ke lapangan dan menyelesaikan masalah mereka sendiri sistem.Dalam kedua kasus, semua masalah sistem harus login, lebih disukai dalam format elektronik yang memfasilitasi meninjau manajemen dan yang dapat diberikan kepada sistem vendor untuk digunakan dalam mengatasi masalah penyebab masalah. Jenis informasi yang harus login mencakup tanggal dan waktu masalah itu dilaporkan, sebuah deskripsi masalah; nama, judul, departemen, alamat e-mail, dan nomor telepon dari individu yang melaporkan masalah, dan langkah-langkah tindakan yang diambil oleh orang tangkas laporan. Tindakan mungkin termasuk menyelesaikan masalah melalui telepon, merujuk masalah untuk teknisi, atau meningkat masalah ke manajer Tindak lanjut prosedur harus ada di mana orang yang ditunjuk dalam penyelesaian masalah area atau help desk trek setiap langkah tindakan yang diambil setelah laporan awal dan catatan dalam log sampai masalah telah diselesaikan Bahkan masalah sistem kecil harus dicatat dalam log sejak tinggi kejadian masalah kecil bisa menjadi pelopor untuk masalah yang lebih serius. Jika masalah tertentu tidak dapat diselesaikan, alasannya harus dicatat dalam log Secara periodik, (misalnya, mingguan), laporan manajemen mengenai masalah sistem harus disiapkan. Laporan harus mengklasifikasikan masalah untuk jenis dan keparahan agar manajemen memungkinkan untuk menentukan frekuensi dan urgensi dari

masalah yang terjadi selama periode dikaji. Masalah yang tidak terpecahkan harus disorot, terutama yang belum dikoreksi untuk jangka waktu yang panjang. Laporan tersebut harus ditinjau oleh manajemen di daerah yang terkena. Tren masalah yang signifikan dan isu-isu lain yang terkait sistem kinerja harus dikomunikasikan kepada vendor, teknisi, dan lainnya yang sesuai pihak

Operasi Bisnis
Operasi bisnis terdiri dari semua fungsi lain dalam organisasi selain orang-orang di area operasi komputer. Daerah operasi bisnis biasanya memberikan input data ke daerah operasi komputer dan memanfaatkan output yang dihasilkan dalam proses seharihari. Audit operasi bisnis harus mencakup penilaian kecukupan pengendalian internal yang berkaitan dengan semua aspek yang signifikan dari proses tertentu dalam pertimbangan. Jelas, jumlah dan jenis kontrol internal di operasi bisnis akan sangat bervariasi tergantung pada jenis bisnis atau proses yang diaudit. Dalam lingkungan operasi hampir setiap organisasi, ada banyak pengguna akhir kontrol SI. Kontrol ini harus berfungsi secara erat dengan kontrol operasi komputer yang terpusat secara tradisional untuk cukup melindungi organisasi terhadap sistem akses tidak sah dan untuk membantu memastikan bahwa operasi bisnis sedang dilaksanakan secara efisien dan efektif. Dengan kata lain, operating kontrol internal di daerah operasi komputer terpusat melengkapi orang-orang dalam operasi bisnis unit, dan sebaliknya. Tidak dapat berfungsi secara efektif tanpa yang lain Seperti yang disebutkan di awal bab ini operasi, operasi komputer dan bisnis bersama-sama terdiri operasi SI dari suatu organisasi. Memang benar bahwa lingkungan pengendalian internal suatu organisasi hanya sekuat komponennya yang paling lemah. Sistem informasi kontrol yang ada di lingkungan operasi bisnis dapat berhubungan dengan masing-masing tiga dasar pengolahan data elektronik kategori: input, proses, dan output. Tapi ada yang lain berdampak kontrol sistem informasi yang sangat penting untuk fungsi efektif dari bisnis operasi. Beberapa contoh dari kontrol operasi bisnis yang mungkin ditemui disajikan berikutnya. Edit dan Cek Kewajaran Untuk membantu mencegah data yang tidak valid dari yang dimasukkan ke dalam sistem, banyak sistem yang diprogram dengan edit dan pemeriksaan kewajaran secara otomatis. Sebagai contoh,. Cek pengeditan dapat mencegah surat dari yang memasuki field yang hanya memiliki nomor, atau sebaliknya Cek pengeditan juga dapat mencegah kode yang tidak valid dari yang masuk ke field tertentu dan dapat mencegah tanggal atau jumlah diluar dari kisaran masuk yang telah ditentukan. Beberapa sistem memerlukan seorang entri data kedua untuk mengunci ulang beberapa atau semua data yang dimasukkan oleh kunci-orang entri data asli dan akan menerima data hanya jika kedua set data yang persis sama. Atau, Cek pengeditan dapat dideteksi secara alami. Dengan kata lain, kontrol dapat mengedit manual atau setelah fakta. Sebagai contoh, sistem mungkin menghasilkan laporan entri data yang harus dibandingkan dengan dokumen input asli untuk

mengidentifikasi kesalahan, atau sistem dapat menerima dan mencoba memproses semua. Data awalnya masuk dan menghasilkan laporan pengecualian di mana kuncimemasukkan data tidak memenuhi ketentuan standar atau filter. Penerima laporan pengecualian kemudian harus memasukkan koreksi yang diperlukan data asli. Detektif IS kontrol biasanya kurang efisien dan efektif dibandingkan preventif kontrol karena mereka membutuhkan tindakan tambahan dan dengan demikian memperlambat proses keseluruhan Cek Integritas / Kelengkapan Ketika volume data yang besar secara elektronik diimpor dari atau diekspor ke sistem lain, kontrol kelengkapan dan integritas data dapat memberikan jaminan yang wajar bahwa penerima telah menerima semua data yang utuh, tanpa perubahan atau informasi yang hilang. total Kontrol adalah bentuk yang paling umum dari cek integritas / kelengkapan . Pengirim menyediakan penerima dengan total kontrol, seperti jumlah total catatan dalam file data dan jumlah total dolar dari catatan. Ketika penerima proses data, jumlah dan jumlah item yang diterima dolar dapat dibandingkan dengan yang disediakan oleh pengirim untuk menentukan apakah ada kemungkinan catatan hilang atau diubah. Namun, total kontrol tidak mungkin mengidentifikasi kasus-kasus di mana catatan telah diubah dalam selain jumlah lapangan. Sebagai contoh, rekening nomor tujuan atau nama pelanggan mungkin berubah dengan account yang tidak sah. Dalam kasus ini, jumlah total dan jumlah dolar catatan asli tidak akan berubah dan dengan demikian tidak akan diidentifikasi oleh total kontrol dasar Hash Total Total hash adalah bentuk umum dari integritas / kelengkapan kontrol yang dapat mengurangi paparan dari catatan telah diubah. Hash total hanyalah sebuah nomor yang dihitung berdasarkan bidang kunci yang biasanya tidak memiliki perhitungan numerik dilakukan padanya Sebagai contoh, sebuah formula sederhana hash Total dapat menambahkan nomor rekening atau nomor faktur dari setiap record dalam file data. Sebuah perubahan bahkan satu dari nomor rekening atau faktur akan menyebabkan total hash berubah. Ketika penerima meng-hash ulang data yang diterima, total tidak akan setuju dengan total hash yang diberikan oleh pengirim, sehingga mengingatkan penerima untuk perubahan tidak sah yang mungkin atau tidak disengaja mengacak data selama proses transmisi. Lebih kompleks hash total yang memanfaatkan algoritma aritmatika untuk menghitung variasi dan kombinasi dari beberapa bidang dapat dirancang. Hasilnya bahkan dapat dienkripsi sebelum transmisi atau transportasi. Tujuan dasar adalah sama dengan total hash sederhana Pemisahan Tugas Ketika memeriksa sebuah operasi bisnis atau proses SI yang terpusat secara sederhana seperti komputer operasi, pengembangan sistem, dan program pengendalian perubahan, salah satu yang paling penting dari tujuan pengendalian internal adalah pemisahan tugas. Tugas harus benar dipisahkan untuk cukup melindungi sebuah

organisasi dari akses tidak sah ke informasi, hilangnya aset fisik atau keuangan, dan segudang risiko potensial lainnya. Pemisahan tugas sehingga bisa eksis di daerah entri data, data pengolahan daerah, dan di daerah operasi bisnis di mana output pengolahan dimanfaatkan. Pemisahan tugas bisa paling efektif ditegakkan melalui penyebaran yang tepat dan administrasi sistem kemampuan akses. (Lihat Bab 8 untuk pembahasan lengkap dari kontrol akses sistem.) Pelaksanaan kontrol prosedural yang kuat adalah sama pentingnya, tetapi lebih sulit untuk ditegakkan karena kemungkinan peningkatan kesalahan manusia atau gangguan. Sebagaimana akan terlihat dalam beberapa contoh kemudian dalam bab ini, pemisahan tugas adalah tempat operasi bisnis sering goyah Efisiensi / Efektivitas Kontrol Dalam operasi bisnis, hampir selalu ada peluang untuk meningkatkan efisiensi dan efektifitas dengan mengotomatisasi prosedur manual. Manajemen mungkin sering mengabaikan kesempatan yang karena mereka disibukkan dengan memenuhi tenggat waktu yang sedang berlangsung dan berurusan dengan masalah operasional sehari-hari. Ironisnya, jika manajemen adalah untuk mengotomatisasi sebagian dari proses yang paling sulit dan memakan waktu, mereka akan meningkatkan kemampuan mereka untuk memenuhi tenggat waktu dan mengurangi keparahan dari kesulitan operasional yang menyebabkan mereka menjadi bimbang. Pemantauan dan Penyeimbang Database internal Manajemen laporan dan informasi lainnya yang berasal dari database internal yang dihasilkan hanya sehandal data dari mana mereka berasal. Banyak organisasi membuat database ekstrak untuk digunakan dalam mempersiapkan berbagai jenis laporan khusus. Ekstrak database, yang pada dasarnya salinan database produksi asli, memungkinkan beberapa pengguna akhir daerah untuk mempersiapkan laporan khusus dan melakukan analisis berbagai basis data dan operasi lainnya tanpa mempengaruhi operasi produksi. Ekstrak database sehingga membuat informasi tersedia bagi sejumlah besar pengguna dalam sebuah organisasi yang, melalui analisis mereka, dapat membantu organisasi mereka lebih efektif mencapai nya tujuan Keamanan atas informasi yang jelas harus ketat untuk memastikan bahwa informasi tersebut tidak terganggu. Sebagai tambahan, mungkin yang lebih menjadi perhatian penting adalah bahwa program ekstrak menciptakan akurat database. Jika tidak, informasi dan analisis hasil yang diperoleh dari database ekstrak mungkin tidak lengkap atau tidak berarti, mungkin mengakibatkan kesalahan dalam penyajian material informasi atau keputusan strategis yang lemah. Dukungan yang tidak memadai untuk aplikasi End-User Program aplikasi komputer yang sedang dikembangkan pada tingkat yang mengkhawatirkan di area pengguna akhir. Banyak dari aplikasi ini dibuat oleh individu yang memiliki jumlah pelatihan teknis yang terbatas. Akibatnya, dokumentasi untuk logika dan desain dari aplikasi biasanya terbatas atau tidak ada. Kemudian, ketika pengembang pindah atau keluar, maka begitu juga semua pengetahuan tentang bagaimana mendukung aplikasi. Beberapa aplikasi pengguna akhir relatif sederhana dan

dengan mudah dapat diciptakan kembali dan bahkan ditingkatkan ketika pengembang pergi. Ada banyak juga aplikasi yang sangat kompleks di mana pengguna akhir organisasi telah menjadi sangat tergantung. Jika pengembang ditransfer atau keluar dan masalah muncul, manajemen bisa terlihat panik mencoba untuk menghubungi pengembang sebelumnya. Dampak yang dihasilkan pada operasi bisnis bisa saja telah dihindari ketika manajemen dibutuhkan pengembang untuk meluangkan waktu untuk menjelaskan dokumen aplikasi dari awal sehingga orang lain dengan pengetahuan yang cukup tentang pembangunan bahasa atau perangkat lunak tersebut, dapat mendukung jalannya aplikasi. Studi kasus 9.3 sampai 9,7 menggambarkan beberapa dari banyak jenis kelemahan pengendalian internal dan inefisiensi SI yang mungkin ditemui dalam operasi bisnis dari sebuah organisasi. Untuk auditor, penting untuk mencari jenis peluang untuk menunjukkan nilai mereka untuk manajemen sebagai konsultan bisnis yang dapat berkontribusi untuk pencapaian tujuan strategis Situasi yang sama dengan yang dijelaskan dalam studi kasus 9,3 dan 9,4 ada di lingkungan SI dari perusahaan di seluruh dunia, baik besar dan kecil, yang secara aktif mengakuisisi organisasi lain. Kerugian operasi bisnis seperti ini adalah jenis buah tergantung rendah bahwa auditor dapat mengidentifikasi dengan menggunakan teknik audit dibantu komputer. Sebagai contoh, database query dari semua rekening mantan karyawan bisa mengidentifikasi kasus-kasus seperti yang baru saja dijelaskan. Identifikasi dari beberapa kelemahan SI yang signifikan dapat menyebabkan ribuan karyawan bisa memulihkan dengan jumlah yang cukup besar bagi organisasi mereka dan menekankan kembali nilai audit internal untuk manajemen senior. Studi Kasus 9.3: Kesalahan pembersihan otomatis dari penuliasan pemasukan data yang efektif menggunakan informasi elektronik Selama proses pemeriksaan (ACH) dalam lembaga keuangan, tercatat bahwa beberapa transaksi ACH yang salah yang diposting ke rekening pelanggan sebagai dari dengan "entri tanggal efektif" yang diberikan oleh pedagang daripada "tanggal penyelesaian," yang merupakan tanggal yang mengirim dan menerima dana lembaga keuangan pertukaran untuk menyelesaikan total bersih dari semua debit dan kredit transaksi ACH. Setiap hari ACH transaksi yang diterima oleh keuangan institusi melalui men-download data elektronik dari sistem komputer Federal Reserve tuan (Fedwire). Pedagang yang berasal transaksi ACH (misalnya, Administrasi Keamanan Sosial, berbagai pensiun, utilitas, perusahaan asuransi, klub kesehatan) tanggal penerimaan pasokan yang efektif dalam elektronik ACH bets informasi header. Informasi lain termasuk dalam catatan elektronik ACH untuk setiap transaksi termasuk nama pelanggan, nomor rekening pelanggan, jumlah transaksi, pedagang nama, dan informasi terkait lainnya [1]. Tidak ada kekurangan dalam format atau isi dari ACH data yang diterima dari Federal Reserve diidentifikasi. Namun, di institusi penerima yang sedang diaudit, ditemukan bahwa ACH postingan Program aplikasi ini dirancang untuk mengirim salah transaksi ACH ke

rekening pelanggan dengan menggunakan penjual entri efektif tanggal bukan tanggal penyelesaian lembaga keuangan. Metode posting merupakan pelanggaran Nasional Automated Clearing House (NACHA) operasi aturan dan peraturan. Dalam beberapa kasus, entri tanggal efektif adalah 30 sampai 45 hari sebelum tanggal penyelesaian. Jadi, ACH postingan aplikasi "dihitung sejak" transaksi ACH. Untuk debit untuk memeriksa bunga dan rekening tabungan, pelanggan sedang membayar bunga 30 sampai 45 hari 'kurang dari mereka berhak untuk menerima. Sebaliknya, untuk kredit dengan bungabantalan dan memeriksa rekening tabungan, pelanggan bunga dibayar terlalu banyak, meskipun situasi kedua adalah kurang umum karena pelanggan cenderung mengeluh ketika ACH deposito besar tidak segera diproses. Backdating ACH transaksi juga menyediakan informasi akurat kepada pelanggan dengan membuat muncul pada mereka pernyataan bahwa transaksi seharusnya sudah diposting sebelumnya padahal sebenarnya mereka sedang diposting di tanggal yang tepat (yaitu, penyelesaian tanggal). Analisis transaksi ACH dihitung sejak saat bulan audit mengungkapkan bahwa 8.718 debit sebesar lebih dari $ 2.800.000 yang dihitung sejak sebanyak 40 hari sementara 868 kredit sebesar lebih dari $ 723.000 yang dihitung sejak sampai 14 hari. Keuangan institusi telah salah backdating transaksi ACH selama bertahun-tahun. Direkomendasikan bahwa perubahan pemrograman dibuat untuk aplikasi ACH posting sehingga yang transaksi yang diposting menggunakan tanggal penyelesaian, bukan tanggal masuknya pedagang yang efektif. Sebuah postaudit tindak lanjut dengan manajemen dari Departemen ACH dilakukan untuk mengkonfirmasi bahwa Rekomendasi telah dilaksanakan. Manajemen menyatakan bahwa perubahan telah dilaksanakan, dan tidak ada pengujian lebih lanjut dilakukan. Selama audit berikutnya tiga tahun kemudian, diharapkan bahwa batch ACH header yang control kelemahan yang diidentifikasi dalam audit sebelumnya, pada kenyataannya, telah diperbaiki sehingga ACH transaksi yang yang diposting pada tanggal penyelesaian. Sayangnya, header yang asli kontrol batch kelemahan masih ada. Dengan kata lain, ada sudah benar-benar tidak ada perubahan dalam pemrograman atau ACH prosedur terkait dengan masalah sundulan batch. Manajer saat ini berspekulasi bahwa aslinya kelemahan telah diperbaiki lama setelah audit pertama, tetapi bahwa pengawasan berikutnya telah terjadi yang mengakibatkan kelemahan rematerializing kontrol asli. Namun, manajer tidak bisa menyediakan bukti kejadian seperti itu. Kelemahan kontrol asli sebenarnya sudah pernah diselesaikan-rupanya karena manajer selama audit pertama dipindahkan ke daerah lain. Para Manajer masuk telah keterbatasan pengetahuan dan pengalaman ACH pada waktu itu dan sibuk dengan pemahaman operasi. Manajer baru ini tidak dapat diandalkan menentukan apakah ACH bets sundulan lemahnya kontrol telah diselesaikan. Dalam situasi tertentu, Departemen Internal Audit keliru dengan mempertimbangkan secara verbal tindak lanjut rekomendasi asli untuk memadai. Karena metode resolusi yang jelas dan karena tidak ada hukuman keuangan untuk kegagalan untuk mematuhi aturan operasi ACH dan peraturan, risiko rekomendasi itu tidak dilaksanakan secara memadai dianggap rendah. Namun, menghabiskan waktu untuk visual mengkonfirmasi hanya satu hari transaksi ACH riwayat pemasangan bisa telah

mengidentifikasi kegagalan untuk menerapkan rekomendasi lebih dari dua tahun sebelumnya. Studi kasus ini menggambarkan butuhnya department audit internal untuk mengevaluasi cara mereka dalam memutuskan rekomendasi mana yang akan diimplementasikan, Untuk resiko yang rendah,rekomendasi yang kurang signifikan, konfirmasi verbal biasanya memadai. rekomendasi untuk memecahkan pengontrolan kelemahan tingkat tinggi dan menengah harus dikonfirmasikan melewati test terbatas. situasi ini merupakan situasi tingkat menengah, yang secara nyata telah mempunyai lebih dari sekedar konfirmasi verbal yang ditunjukan Studi Kasus 9.4: Penggabungan Menghasilkan kelalaian dalam Operasi Bisnis Selama banyak penggabungan dan penambahan yang terjadi pada tahun 1980-an dan 1990-an, kesempatan untuk IS operasi kelalaian itu banyak terjadi. Seringkali penggabungan diikuti oleh yang lain dan lainnya. Manajer sistem informasi mengalami kesulitan untuk mengikuti penambahan dan perubahan berikutnya, apalagi untuk melakukan perubahan yang memadai. Studi kasus ini adalah contoh bagaimana penggabungan yang negatif dapat mempengaruhi IS operasi dari berbagai organisasi. Perusahaan B di tengah menyerap operasi pengolahan data baru-baru ini diakuisisi anak perusahaan, Perusahaan A, ketika itu dirinya diakuisisi oleh organisasi lain, Perusahaan C. Merupakan hal yang lumrah, para anggota staf di Korporasi B yang bertanggung jawab untuk menyerap IS Sebuah operasi Perusahaan menjadi lebih peduli dengan dirinya sendiri dan menyelamatkan pekerjaan dan karir mereka sendiri daripada melakukan konversi menyeluruh sistem Perusahaan A. Mereka melakukan hanya terbatas pengujian sambil mencari pekerjaan baru di departemen lain dan perusahaan. Tak terhindarkan lagi, signifikansi IS pengujian dan masalah operasional terkait diabaikan. Kemudian SisFo perusahaan C harus menyerap operasi IS Corporation B, termasuk menyerap SisFO perusahaan A dengan setengah2. Situasi ini semakin rumit ketika sebuah organisasi keempat, perusahaan D, mulai proses untuk mengakuisisi Perusahaan C. Meskipun tampaknya terlalu mengada-ada, ini adalah situasi saya amati pada tahun 1980. Banyak rekan-rekan saya bekerja untuk sebuah bank yang sekarang sudah bangkrut yang disebut Bancorporation Rainier. Rainier adalah Bank daerah yang menghasilkan keuntungan tinggi, memiliki kantor pusat yang berada di Washington dengan asset lebih dari $ 9 miliar . Rainier telah aktif mengakuisisi bank-bank kecil di daerah dan mengaplikasikan sistem perbankan mereka pada bank-bank tersebut. Pada tahun 1987, Rainier dibeli oleh Keamanan Bancorporation Pasifik dari Los Angeles. Security Pacific, yang memiliki aset lebih dari $ 60 miliar sebelum untuk akuisisi, mulai tugas yang sulit menelan sistem informasi dari Rainier Bancorporation. Kemudian, pada awal 1990-an, Security Pacific Bancorporation, dengan aset lebih dari $ 90 miliar pada waktu itu, itu sendiri diakuisisi oleh Bank of America. Bank of America kini salah satu terbesar dan paling sukses memegang perusahaan bank di Amerika Serikat. [2]

Di permukaan, hasil akhir muncul menjadi bank yang sangat menguntungkan perusahaan holding yang mampu berhasil menyerap IS operasi dari semua perusahaan yang sebelumnya bergabung. Karena ketidakstabilan nilai dolar pada saat pengakuisisian ini, pernyataan sebelumnya adalah benar. Namun, jutaan dolar dalam kerugian immaterial operasional menyelinap melalui celah-celah hampir tanpa disadari. Eksekutif perusahaan mungkin menduga "kerugian merger" besar terjadi dan mungkin menganggap mereka sebagai biaya yang dapat diterima dalam melakukan bisnis, asalkan dampaknya tidak material terhadap keuangan. Namun, apa yang merupakan beberapa juta dolar untuk manajemen akhir perusahaan raksasa sebagai dividen kehilangan potensi dan nilai saham dikurangi menjadi pemegang saham. Ada juga yang cukup peluang untuk tindakan tidak jujur untuk tidak terdeteksi. Di sisi positif, beberapa kerugian ini akhirnya menguntungkan konsumen kecil yang pelanggan dari bank yang diperoleh. Banyak kerugian mungkin tidak telah dicegah selama akuisisi sebagai manajemen dan staf bergegas untuk menjaga sistem berjalan saat membuat setiap kesulitan sebagai transparan kepada pelanggan mungkin. Namun, banyak dari kerugian bisa saja mudah terdeteksi setelah fakta menggunakan relatif sederhana dengan bantuan komputer Audit tes, termasuk berbagai query database. Prosedur pemulihan kemudian bisa telah dilaksanakan. Dua contoh kerugian operasional yang terjadi sebagai akibat langsung dari kelalaian selama merger dan proses akuisisi tersebut disajikan: 1. Mantan karyawan dengan tingkat suku bunganya pada kartu kredit. Banyak orang diberhentikan selama merger pada 1980-an. Sementara bekerja di bank yang sudah ada, mereka diberikan pengurangan suku bunga dan biaya tahunan kartu kredit mereka. Banyak dari orang-orang ini masih menerima tingkat suku bunga dan biaya tahunan kartu kredit mereka, meskipun mereka telah tidak bekerja di bank selama lebih dari 10 tahun. Jumlah mantan karyawan yang ada dari pengawasan ini tidak diketahui. Namun, ada puluhan ribu mantan karyawan bank yang disebutkan, banyak dari mereka diberhentikan selama merger. 2. 401 (k) gagal merencanakan tabungan pensiun. Masing-masing dari perusahaan yang sebelumnya dibahas menyediakan rencana tabungan pensiun tambahan bernama 401 (k) untuk karyawan. Tiap rencana secara independen dikelola oleh organisasi yang terpisah dengan sistem informasi yang berbeda sebelum merger. Melalui masing-masing merger, aset 401 (k) dari perusahaan akuisisi harus menyerap pada aset 401(k) yang telah didapatkan dari organisasi atau didistribusikan kepada mantan karyawan. Kerumitan proses adalah keterlambatan yang terjadi selama penyelesaian kegiatan 401 (K) yang dimuali oleh karyawan (kadang-kadang sampai enam bulan), pengumpulan dana peminjaman 401 (k) dan kegiatan yang berhubungan , dan penyelesaian dan pengumpulan pendapatan investasi 401 (k) . Singkatnya, mengkonsolidasikan beberapa rencana 401 (k) bukanlah tugas yang sederhana. Dalam beberapa contoh, pendistribusian 401 (k) diberikan kepada karyawan yang diberhentikan oleh perusahaan yang melebihi jumlah karyawan mereka, dalam beberapa kasus oleh lebih dari 30 persen. Seperti situasi biaya karyawan yang dijelaskan di atas, tidak satupun dari perbedaan-perbedaan yang pernah terdeteksi dan jumlah total orang yang mendapatkan manfaat dari kelemahan ini tidak diketahui.

Jenis kerugian operasional bisnis membawa pertanyaan kecukupan pengendalian internal atas rencana 401 (k) dan seberapa baik mereka dikelola. Kerugian lebih dari mungkin ditanggung oleh peserta 401 lain (k), bukan perusahaan itu sendiri.

Studi Kasus 9.5: Update Rekaman Biro Informasi Kredit Dibuat di Waktu yang Salah Selama proses audit dimana informasi laporan kredit telah diupdate oleh lembaga keuangan, itu mencatat bahwa Departemen Pengolah Data (DP) membuat biro kredit bulanan untuk memperbarui rekaman pada akhir pekan sebelum tanggal 15 setiap bulannya. Karena banyak pinjaman dibayar tanggal 15, prosedur ini disebabkan pembayaran pinjaman yang dibuat setelah tanggal pembuatan rekaman tetapi sebelum tanggal 16 dilaporkan ke kantor kredit sebagai tunggakan, walau mereka sudah membayar. Ini konsekuensi prosedut yang dihasilkan karena selisih paham antara biro peminjaman dengan customer dan lembaga keuangan Sebuah perubahan waktu sederhana direkomendasikan, dimana Departemen DP mulai menciptakan biro kredit pembaruan laporan pada hari Minggu pertama setelah tanggal 15 setiap bulan. Prosedur ini dilaksanakan selama audit dan tidak memiliki efek yang signifikan pada sumber daya di Departemen DP. Selain itu, biro kredit memecah wilayah lembaga keuangan dan banyak pelanggan yang lega dalam jumlah yang signifikan dari pada yang merasa sedih.

Studi Kasus 9.6: Kombinasi pinjaman / penipuan mesin teller otomatis hasil dari pemisahan tugas yang tidak memadai Dua pinjaman penipuan senilai lebih dari $ 30.000 dilakukan oleh mantan karyawan lembaga keuangan, sebut saja Susi. Susi bertanggung jawab untuk mencairkan dana pinjaman ke konsumen yang disetujui dan diberikan kemampuan berbagai sistem akses sepadan dengan tugas-tugasnya. Susie juga diberikan sistem kemampuan akses yang memungkinkan dia untuk mengubah alamat pelanggan dalam informasi database pelanggan lembaga keuangan itu. Kemampuan akses ini secara umum diberikan kepada karyawan sebagian besar lembaga keuangan. Bahkan, pada suatu saat, lebih dari 90 persen dari karyawan lembaga keuangan itu bisa mengubah alamat pelanggan. Selanjutnya, Susie memiliki sistem akses kemampuan untuk melihat informasi rahasia pelanggan yang dibutuhkan untuk penggantian kartu ATM dan nomor identifikasi pribadi (PIN) pelanggan serta kemampuan untuk melakukan setoran ke rekening yang tidak aktif. Dengan berbagai kemampuan mengakses sistem, itu hanya masalah waktu sebelum seseorang melakukan penipuan dalam laporan lembaga keuangan. Skema tertentu sangat cerdik.

Susie mencairkan dua transaksi pinjaman penipuan senilai lebih dari $ 30.000 untuk dua rekening tidak aktif yang berbeda. Rekening yang tidak aktif sebelumnya mempunyai saldo minimal kurang dari $ 10. Lembaga keuangan tidak memiliki kontrol yang baik untuk memantau aktivitas account tidak aktif. Susie mengatur pinjaman sehingga otomatis pembayaran akan datang dari rekening yang mana jumlah pokok telah dikreditkan. Dia menyiapkan arsip pinjaman yang berisi pembatasan sejumlah dokumen palsu untuk dua pinjaman penipuan, juga berhati-hati untuk membatasi jumlah tulisan tangan. Karena banyak pinjaman besar yang disalurkan dari pinjaman lembaga keuangan pusat, pengendalian internal klasik dimana pinjaman petugas meninjau pinjaman konsumen semua dicairkan dengan akurasi dan kepatutan yang kurang. Pada kenyataannya, rata-rata tidak mengalami dari pinjaman sedang dengan bebas meninjau terakhir. Dengan demikian, Susie dapat mencairkan dua pinjaman yang tidak sah ke rekening pelanggan aktif tanpa ketahuan. Susie kemudian mengubah alamat dua rekening yang tidak aktif pada database informasi pelanggan dengan kantor pos kotak yang dia sebelumnya dibuka di bawah nama-nama pemegang rekening aktif. Karena rekening pelanggan tidak aktif memiliki dana sedikit, mereka tidak menyadari bahwa mereka tidak lagi menerima laporan bulanan mereka. Langkah terakhir dalam skema Susie adalah menelepon Departemen Customer Service dan kartu ATM pengganti rangka dan PIN. Kartu dan PIN yang mudah dikirim ke kotak kantor pos penipuan. Seperti Anda mungkin bisa menduga, Susie menggunakan kartu dan PIN untuk memperoleh uang tunai dari ATM. Karena ia adalah seorang karyawan, Susie tahu mana ATM yang ada cctv-nya dan yang tidak. Oleh karena itu dia mendapat penarikan maksimum kas harian dari berbagai cameraless ATM, kembali hampir setiap hari selama beberapa minggu. Lembaga keuangan juga tidak memiliki kontrol pencegahan penipuan ATM klasik dari rekening pemantauan untuk harian maksimum penarikan aktivitas. Tapi Susie bukan pencuri terlalu serakah. Setelah menarik sedikit lebih dari separuh dari $ 30.000 pinjaman penipuan, ia dihentikan membuat penarikan ATM dan meninggalkan lembaga keuangan. Hal ini memungkinkan saldo yang tersisa di rekening yang sebelumnya tidak aktif untuk membayar pinjaman bulanan pembayaran, sehingga membuat pinjaman tampaknya saat ini dan aktif. Setelah sekitar dua tahun lagi, dana di rekening berlari keluar dan menjadi tunggakan pinjaman. Ketika Departemen Koleksi menghubungi pelanggan yang sebenarnya dari rekening yang tidak aktif, tak satu pun tahu untuk pinjaman apa kolektor yang merujuk. Para pelanggan menyatakan bahwa mereka tidak pernah diterapkan untuk setiap pinjaman di lembaga keuangan. Penipuan akhirnya telah ditemukan. Pada saat ini, banyak bukti yang memberatkan dingin. Sebagai contoh identifikasi visual oleh pos pegawai yang membuka kotak kantor pos atau orangorang menggunakan ATM sebelum atau setelah salah satu dari penarikan penipuan tidak mungkin. Dokumen-dokumen pinjaman itu tulisan tangan cukup untuk menarik kesimpulan. Tidak ada gambar kamera ATM. Semua yang dapat dibuktikan adalah bahwa Susie telah dikreditkan dua rekening yang tidak aktif dengan penyaluran kredit. Karena dana menyalurkan tugasnya, ia bisa membantah bahwa ia hanya melakukan apa yang dia diberitahu dan bahwa orang lain telah memalsukan dokumen. Susie tidak pernah dituntut dan keberadaannya kini tidak diketahui. Tak perlu dikatakan, pengendalian internal klasik disebutkan di atas sekarang kuat di tempat di korban lembaga keuangan.

Studi Kasus 9.7: Aplikasi pengguna yang tidak mendukung. Sebuah lembaga keuangan yang berbasis mainframe aplikasi pinjaman dirancang hanya untuk mengakomodasi aplikasi pinjaman akhir pembukaan, yang terdiri dari mayoritas pinjaman disetujui oleh lembaga. Sejak lembaga tersebut menyetujui jumlah akhir pinjaman, maka kontrak dengan vendor lokal kecil untuk mengembangkan aplikasi perangkat lunak berbasis mikrokomputer yang dihasilkan laporan pengungkapan tertutup pinjaman. Pengguna akan hanya perlu memasukkan informasi tertentu dan aplikasi akan mencetak informasi pengungkapan ke bentuk standar pengungkapan yang manual dimasukkan ke dalam printer. Sebagai lembaga keuangan tumbuh dan persyaratan hukum untuk pernyataan pengungkapan berubah, begitu pula kebutuhan untuk merevisi aplikasi karena perangkat lunak itu tidak fleksibel dan tidak efisien. Sebagai contoh, itu bukan berbasis Windows, satu-satunya cara untuk keluar dari program adalah untuk reboot microcomputer, tidak ada fungsi bantuan pengguna, dan perangkat lunak dapat diperbarui hanya dengan vendor. Selain itu, tidak ada pengguna atau instruksi manual. Sayangnya, vendor tidak lagi dalam bisnis dan tidak tersedia untuk membuat perubahan pada aplikasi. Keuangan institusi juga tidak memiliki kode sumber dan karena itu harus bergantung pada pengembang untuk mengubahnya. Ini direkomendasikan bahwa manajemen meminta untuk penggantian aplikasi perangkat lunak dari setidaknya tiga vendor terkemuka dan berkualitas dengan track record yang terbukti dalam industri. Kontrak dengan vendor harus menentukan bahwa kode sumber akan diselenggarakan di escrow sehingga, dalam kejadian vendor keluar dari kontrak atau melanggar kontrak, lembaga keuangan diberikan kode sumber asli. Atau, direkomendasikan bahwa manajemen menilai kelayakan dan ketepatan waktu memiliki perangkat lunak dalam program internal, tergantung pada ketersediaan sumber daya internal.

[1] Tata letak catatan yang tepat ditentukan oleh National Automated Clearing House Association (NACHA), yang menetapkan aturan operasi ACH dan peraturan. [2] Bank of America dan Nations Bank merger pada tahun 1998.

Efisiensi dan Efektivitas Sistem Informasi Operasi Bisnis

Auditor harus selalu meninjau untuk merekomendasikan otomatisasi prosedur manual sebelumnya untuk meningkatkan efisiensi operasional. Manajemen seringkali terkait dengan operasi harian bahwa mereka mengabaikan peluang otomatisasi. Dalam beberapa kasus, manajemen mungkin tidak menyadari teknologi baru yang akan memungkinkan operasi akan otomatis bekerja dengan mudah. Dalam kasus lain, manajemen di unit perusahaan mungkin dilihat oleh Departemen Internal Audit untuk membantu manajemen dalam proses pengembangan SI. Auditor internal dapat memperkuat dasar kebenaran operasi bisnis dalam permintaan pemrograman untuk mengotomatisasi prosedur. Ini bukan untuk mengatakan bahwa operasi harus mengotomatisasi hanya demi mengotomatisasi. Harus ada bukti konkret bahwa manfaat dari otomatisasi akan lebih besar daripada biaya perancangan dan pemrograman sistem. Pernyataan yang sama dapat dibuat untuk kesempatan efektivitas. Kadang-kadang proses mungkin sudah otomatis atau sistem dapat memberikan informasi otomatis, namun kualitas layanan atau produk akhir dapat ditingkatkan melalui perubahan dalam proses otomasi. Sebagai contoh, pelanggan mungkin menerima laporan transaksi otomatis atau faktur, tetapi informasi mengenai dokumen tidak jelas atau membingungkan. Dalam hal ini, perubahan dalam jenis atau kejelasan informasi disediakan dalam membuat pernyataan dan faktur lebih efektif untuk pelanggan. Seringkali, peningkatan efisiensi secara bersamaan menyediakan perangkat tambahan untuk efektivitas suatu operasi. Studi kasus 9.8 melalui contoh 9.13 di mana kesempatan dalam meningkatkan efisiensi dan / atau efektivitas operasi bisnis dengan menerapkan solusi otomatis juga diidentifikasi selama audit internal.

9.8 Studi Kasus: Otomatisasi pada transfer kabel Selama audit dari operasi transfer kabel di lembaga keuangan, tercatat bahwa yang sedang masuk dalam kabel manual diposting ke account pelanggan. Informasi kabel yang masuk ditransmisikan secara elektronik dari Federal Reserve untuk komputer pribadi lembaga keuangan yang berbasis aplikasi transfer kabel. Sebuah analisis barubaru ini mengenai wire transfer megungkapkan bahwa Departemen Wire Transfer telah memposting rata-rata sekitar 200 kabel per hari. Ini banyak kemungkinan sekitar 1.000 kawat per minggu atau sekitar 50.000 kabel diposting setiap tahunnya. Sebagai lembaga keuangan yang terus berkembang, banyaknya wire transfer yang masuk juga diharapkan ikut berkembang. Ini direkomendasikan agar Departemen Wire Transfer bekerja dengan sistem pengolahan data untuk menciptakan aplikasi yang bisa mengambil data wire transfer download elektronik dari Federal Reserve dan otomatis memposting transaksi ke rekening pelanggan. Dengan cara ini, hanya memasukan kabel ke rekening yang tidak sah akan diproses secara manual.

Studi kasus ini menggambarkan bagaimana sebuah operasi di sebuah perusahaan yang berkembang bisa tumbuh pesat sehingga membuat biaya lebih efektif. Dalam hal ini, manajemen tidak mengakui bahwa sebagian besar pengguna bisa diselamatkan dengan mengotomatisasi posting wire transfer.

Studi Kasus 9.9: Informasi Membingungkan pada Aplikasi Perbankan Interaktif online Selama tinjauan aplikasi perbankan dilaksanakan secara interaktif, tercatat bahwa rincian transaksi Pinjaman salah satu pelanggan terdaftar sebagai pinjaman pokok sebagai judul kolom di atas transaksi jumlah kolom. Walaupun informasi ini tidak mempengaruhi sejarah mainframe, hal itu mengarah pada kebingungan pada bagian pelanggan pinjaman. Rekomendasi yang jelas adalah untuk hanya mengubah judul kolom, tetapi ini tidak membuktikan menjadi tugas yang mudah. Dua vendor perangkat lunak awalnya codeveloped beberapa tahun sebelumnya dan dipasarkan sebagai produk off-the-rak. Lembaga keuangan telah membeli perangkat lunak aplikasi sekitar satu tahun di muka dan instalasi selesai itu sekitar satu bulan sebelum kami tes. Sayangnya, perusahaan penjual telah bercerai setelah pembelian perangkat lunak, dan tidak salah satu memberikan dukungan pemrograman untuk perangkat lunak. Selanjutnya, kontrak lembaga keuangan yang gagal untuk menentukan bahwa kode sumber akan diadakan di escrow oleh pihak ketiga yang independen sehingga bisa dirilis ke lembaga keuangan dalam hal vendor tidak bisa atau tidak akan mendukung perangkat lunak, atau vendor lainnya melanggar panjang yang signifikan dari kontrak. Untungnya, lembaga keuangan mempekerjakan layanan dari salah satu dari dua vendor lainnya dalam aplikasi perangkat lunak. Akibatnya, lembaga keuangan mampu memanfaatkan vendor untuk memperbaiki program perangkat lunak dengan mengancam tidak akan melanjutkan kontrak jika tidak melaksanakannya. Kadang-kadang prakteknya lebih cerdas sehingga diperlukan untuk menyelesaikan tugas-tugas sederhana. Situasi ini bisa saja dihindari jika pengujian yang memadai telah dilakukan pada sistem awal dalam proyek dan memiliki kontrak yang jelas.

Studi Kasus 9.10: Otomatisasi Persiapan Periksa Manual dan Proses manual lainnya dalam Operasi Akun Individual Retirement Selama audit rekening pensiunan dan operasi keuangan yang terkait institusi, lima peluang yang diidentifikasi untuk meningkatkan efisiensi dan efektivitas secara otomatis dari prosedur manual sebelumnya atau meningkatkan prosedur otomatis yang ada. Kesempatan efisiensi pertama adalah Departemen Akuntansi secara manual menciptakan dan mengecek kiriman setiap dua kali dalam seminggu untuk penyetoran

pajak penghasilan yang dipotong untuk pemerintah pusat. Ini direkomendasikan bahwa dana dikirimkan secara elektronik memanfaatkan aplikasi yang sudah ada yang sudah digunakan untuk mengirimkan dana lain untuk pemerintah. Rekomendasi kami menghasilkan tiga manfaat: 1. Menghilangkan penggunaan cek kertas dan pemrosesan yang terkait dan biaya pengiriman. 2. Mengurangi jumlah waktu yang diperlukan untuk mempersiapkan dan mengirimkan pembayaran dibandingkan dengan jumlah waktu yang dibutuhkan untuk persiapannya dan surat cek kertas. 3. Perusahaan dapat lebih efektif mengelola kas. Sebelumnya, perusahaan harus memperkirakan jumlah hari yang diperlukan untuk pengiriman cek dan akan membuat jangka pendek investasi berdasarkan perkiraan ini. Namun, perusahaan harus setiap saat mengecek mail sehingga tidak merugikan pihak manapun, atas denda keterlambatannya. Akibatnya, pemerintah biasanya menerima cek dan menguangkannya sebelum tanggal jatuh tempo. Dengan pajak secara elektronik timbul koleksi pada tanggal jatuh tempo, perusahaan dapat menginvestasikan dana dalam jangka pendek sampai mungkin hari terakhir, sehingga memaksimalkan pendapatan investasi dari dana ini.

Efisiensi / efektifitas kesempatan kedua tergolong pada fakta bahwa aplikasi di lembaga keuangan tidak bisa menghitung distribusi informasi otomatis rekening pensiunan (IRA). Sebaliknya, Departemen IRA adalah vendor yang menggunakan aplikasi berbasis mikrokomputer untuk melakukan perhitungan ini, tetapi aplikasi IRA tidak berkomunikasi dengan aplikasi vendor. Dengan kata lain, informasi yang diperlukan untuk menghitung distribusi IRA secara manual disesuaikan kedalam vendor aplikasi oleh staf Departemen IRA. Ini direkomendasikan bahwa Departemen IRA mengajukan permintaan ke Departemen IS untuk mengembangkan sistem yang bisa secara elektronis dapat memindahkan informasi yang diperlukan dalam aplikasi utama IRA kepada aplikasi vendor (misalnya, dalam format ASCII [American Standard Code for Information Interchange]). Penghematan biaya tenaga kerja itu penting, terutama karena jumlah rekening IRA menginginkan perhitungan distribusi otomatis IRA yang terus meningkat setiap tahun, dan tingkat pertumbuhan diproyeksikan akan terus meningkat. Sebuah ketidakefisienan yang ketiga adalah fakta bahwa tidak ada aplikasi utama IRA maupun microcomputer aplikasi vendor dapat melakukan distribusi otomatis. Sebagai hasilnya, perhitungan harus dilakukan secara manual. Dalam hal ini, direkomendasikan bahwa pimpinan Departemen IRA mencari software perhitungan pembayaran yang lebih efektif agar memenuhi semua kebutuhan. Jika keputusan itu dibuat untuk membeli aplikasi pengganti, maka rekomendasi untuk program modul transfer data akan ditunda sampai aplikasi baru diinstal.

Ketidakefisienan keempat dihasilkan dari fakta bahwa Departemen IRA memasukkan kunci data ke dalam 11 databasenya secara manual, yang digunakan dalam pelacakan informasi historis tidak dinyatakan tersedia dalam aplikasi utama IRA. Pemeriksaan database ini terungkap karena banyak redundansi data dan, dalam dua kasus lain, database yang tidak seharusnya digunakan. Itu adalah direkomendasikan bahwa manajemen menghilangkan database yang tidak perlu dan menggabungannya sehingga hanya tujuh database saja yang digunakan. Hal ini mengakibatkan penurunan yang signifikan dalam jumlah waktu yang diperlukan untuk memasukkan informasi ke dalam database dan memungkinkan Departemen IRA untuk lebih efektif untuk menghasilkan laporan database. Permasalahan kelima tentang efektivitas pelaporan manajemen. Sebuah laporan yang dapat mengidentifikasi jumlah rekening-rekening aktif IRA tidak dapat dipersiapkan dari aplikasi utama IRA. Informasi aplikasi IRA dapat memberikan jumlah account baru yang dibuka dan jumlah account yang tertutup. Dari informasi ini, jumlah total IRA account aktif dihitung, menggunakan running total. Dengan kata lain, jumlah rekening baru dibuka ditambahkan secara manual ke total akhir dari bulan sebelumnya, dan kemudian jumlah rekening IRA tertutup dikurangi. Total yang dihasilkan diberikan kepada pimpinan dalam berbagai laporan IRA sebagai jumlah rekening aktif. Metode ini telah ada selama beberapa tahun, dan jumlah account yang aktif belum pernah dibandingkan dengan sistem total. Selama audit, laporan khusus dari database IRA diminta untuk mengkonfirmasi keakuratan dari running total yang dilaporkan kepada manajemen. Berdasarkan jumlah rekening yang diidentifikasi dari laporan khusus, jumlah rekening IRA dilaporkan kepada manajemen selama bulan terakhir adalah yang paling besar dengan 3,4 persen. Oleh karena itu direkomendasikan bahwa pempinan Departemen IRA mengajukan permohonan kepada pimpinan Departemen IS untuk menerima laporan dihasilkan dari aplikasi utama IRA, menunjukkan jumlah rekening IRA yang aktif, dan bahwa Departemen IRA menggunakan informasi dalam laporan manajemen.

Studi Kasus 9.11: Kegagalan untuk Mengotomatiskan Deaktivasi dari Penerbitan Besar Kartu Debet

Ini adalah kasus di mana Internal Audit tidak termasuk dalam tim pengembangan lembaga keuangan dalam merencanakan pengenalan produk kartu debit baru. Kartu debit baru yang disediakan dengan kemampuan untuk menggunakan kartu tunggal berbasis PIN ATM dan transaksi point-of-sale serta transaksi kartu debit berbasis tanda tangan. Oleh karena itu, kartu ATM yang lama harus diganti dengan kartu debit baru. Karena proyek ini tidak dianggap mempunyai risiko tinggi, Departemen Internal Audit memantau kemajuan proyek melalui pertanyaan dari pemimpin proyek dan sebatas ditulis korespondensi.

Setelah pengembangan produk selesai, kartu debit baru awalnya dikeluarkan untuk lebih dari 150.000 pemegang kartu. Pada penerimaan, setiap pemegang kartu untuk mengaktifkan kartu debit nya lain dengan melakukan transaksi berbasis PIN. Lembaga Kartu Debit kemudian menerima laporan harian untuk mengaktifkan kartu debit dan secara manual menonaktifkan kartu ATM yang sesuai untuk setiap pemilik kartu. Dengan jumlah besar kartu debit yang diterbitkan, penonaktifan kartu ATM yang lama. Bahkan, Departemen Kartu Debet harus menyewa tiga karyawan sementara untuk melakukan apa pun kecuali menonaktifkan kartu ATM lama. Kelemahan yang jelas dalam proyek kartu debit adalah bahwa selama perencanaan, prosedur otomatis tidak mengerti cara menonaktifkan kartu lama. Sebelum penerbitan kartu debit berikutnya, program penonaktifan otomatis harus dikembangkan.

Meskipun sudah terlambat untuk menerapkan rekomendasi ini untuk penerbitan pertama, ini pelajaran baik bagi auditor agar waspada dalam mengidentifikasi jenis-jenis peluang efisiensi awal proyek, bahkan jika anggota Departemen Internal Audit bukan merupakan bagian resmi dari tim proyek. Menginformasikan tim proyek tentang ketidakefisiensian berpotensi penting sebelum terlambat untuk memperbaiki agar bisa secara signifikan meningkatkan daya tarik termasuk auditor internal pada tim proyek berikutnya, terutama kata yang menyenangkan dalam berkomunikasi dengan organisasi. Studi Kasus 9.12: Kegagalan untuk Saldo Database Ekstrak Pemasaran

Selama audit aplikasi database pemasaran di sebuah lembaga keuangan, tercatat bahwa prosedur yang kurang untuk menyeimbangkan jumlah total akun rekening dan saldo dalam aplikasi database dengan sumber data secara teratur. Setiap bulan program menyalin deposito dan pinjaman rekening saldo, informasi demografis, dan data pemasaran lainnya yang dipilih dari database utama ke data salinan. Data pada salinan itu kemudian disalin ke dalam aplikasi database pemasaran. Data salinan yang berisi informasi pemasaran dari aplikasi lainnya juga disalin ke dalam database pemasaran. Setelah proses update selesai, Departemen Pemasaran akan melakukan berbagai pertanyaan dan analisis pelanggan lain untuk digunakan dalam perencanaan dan mengevaluasi keberhasilan promosi pemasaran dan upaya pengembangan produk.

Total dolar dan jumlah rekening yang seimbang setelah download pertama telah selesai dalam sistem ini dan hanya sekali pada setiap akhir tahun. Sejak unduhan yang dilakukan secara bulanan, jika data yang terdapat kesalahan karena masalah dalam program yang digunakan untuk menyadap data atau dalam proses update database, mereka tidak dapat dideteksi secara tepat waktu. Sebagai hasil pemasaran, bulanan dan laporan demografis yang disusun sepanjang tahun dapat berisi informasi yang tidak akurat, yang pada gilirannya dapat mempengaruhi keberhasilan promosi pemasaran

perusahaan dan kemampuannya secara akurat menilai keberhasilan promosi. Kegagalan untuk menyeimbangkan total database untuk mengekstrak sumber data merupakan keadaan yang biasa, tetapi seringkali signifikan dengan banyak pengguna akhir database.

Studi Kasus 9.13: Dokumentasi tidak memadai dan Pengujian Program Basis Data FOKUS Kritis

Sebuah lembaga keuangan besar FOKUS menggunakan database ekstensif untuk membuat berbagai jenis keuangan, kepatuhan peraturan perbankan, dan ad hoc laporan untuk semua tingkat manajemen. FOKUS database merupakan sumber data yang memungkinkan pengguna akhir untuk mendapatkan informasi relatif cepat tanpa harus memintanya melalui permintaan pengolahan data laporan terpusat. FOKUS database diciptakan melalui sebuah proses di mana catatan dari produksi file aplikasi yang diambil oleh sebuah program yang kemudian salinan mereka di FOKUS dibaca format alamat penyimpanan yang ditunjuk elektronik. Dalam lingkup audit pada lembaga keuangan tertentu, ada sekitar 820 pengguna FOKUS resmi, banyak di antaranya digunakan FOKUS setiap hari. Database FOKUS dalam ruang lingkup audit yang mencakup informasi mengenai rekening giro, rekening tabungan, sertifikat deposito, informasi sumber daya manusia , informasi pinjaman komersial dan konsumen, dan informasi buku besar keuangan. Untuk mengurangi risiko keputusan strategis oleh manajemen dan denda dan / atau tuntutan hukum akibat tidak akurat melaporkan hukum dan peraturan kegiatan, database FOKUS seimbang pada total produksi database pada setiap hari dengan Program otomatis. Setiap kondisi tidak seimbangan akan muncul pada laporan yang dikirim ke pemilik database FOKUS. Selama audit, ditemukan bahwa banyak departemen telah menulis program FOKUS canggih untuk mengekstrak informasi dari database FOKUS. Program tersebut dikembangkan secara independen dari Sistem sentralisasi Departemen Pengembangan, kadang-kadang oleh pengguna akhir dan staf teknis kadang-kadang oleh programmer kontrak. Banyak program FOKUS mengandung sedikit atau tidak ada dokumentasi sebagai tujuan mereka, logika, definisi lapangan, sumber data eksternal, dan jenis lainnya deskriptif informasi yang dapat membantu dalam operasi harian dan pemeliharaan program dan jika program perlu dikoreksi. Selain itu, pengujian program-program itu tidak didokumentasikan sebelum pelaksanaan produksi di departemen pengguna akhir. Dalam banyak kasus, programmer harus ditransfer ke departemen lain atau dihentikan sama sekali, sehingga menyebabkan kesulitan dalam memelihara dan pemecahan masalah yang dihadapi. Ini direkomendasikan untuk manajemen di departemen pengguna akhir supaya meminta FOKUS kompleks program yang akan dikembangkan bersama dengan Departemen Pembangunan Sistem terpusat agar membantu memastikan bahwa program yang dirancang baik, didokumentasikan, dan diuji sesuai dengan sebelumnya mendirikan

perusahaan pengembangan sistem dan standar pemrograman. Sebagai bagian dari rekomendasi, pengguna akhir manajemen harus bekerja dengan Sistem Pembangunan Manajemen untuk menentukan program yang kompleks. Hal itu juga merekomendasikan bahwa semua program FOKUS lainnya dikembangkan di departemen pengguna akhir yang didirikan mematuhi sistem dan pengembangan perusahaan pemrograman standar.