AKTIVITAS PENGEMBANGAN DAN PEMELIHARAAN

SISTEM
AUDIT SISTEM INFOMASI

KELOMPOK 6

DEWI INDRIYANI 161210176

ENI RAHMAWATI 161210234

NOVIATI 161210074

VENI MUTIA SARI 161210096

IHSAN HAORI 191210262

INSTITUT BISNIS DAN INFORMATIKA KESATUAN

BOGOR
 AKTIVITAS PENGEMBANGAN DAN PEMELIHARAAN SISTEM

Salah satu aset perusahaan modern yang berharga adalah sistem informasi yang
responsif dan berorientasi pada pengguna. Sistem yang didesain dengan baik dapat
meningkatkan produktivitas, mengurangi persediaan, meniadakan aktivitas tidak bernilai
tambah, memperbaiki layanan pelanggan dan keputusan manajemen, serta mengoordinasikan
berbagai aktivitas di seluruh perusahaan.
Bab ini dimulai dengan penjelasan mengenai berbagai peran para partisipan yang
terlibat pengembangan sistem informasi perusahaan, termasuk profesional sistem, pengguna,
dan pemegang kepentingan. Kemudian akan diberikan garis besar berbagai aktivitas utama
yang membentuk siklus hidup pengembangan sistem (system development life cycle-SDLC).
Aktivitas-aktivitas ini meliputi perencanaan sistem, analisis sistem, desain konseptual,
pemilihan sistem, desain terperinci, implementasi sistem, dan pemeliharaan sistem. Prosedur
multi tahap ini digunakan sebagai petunjuk dalam pengembangan sistem di banyak
perusahaan. Terakhir, akan dibahas mengenai berbagai risiko, pengendalian, dan isu audit
SDLC.

PARTISIPAN DALAM PENGEMBANGAN SISTEM

Partisipan dalam pengembangan sistem dapat diklasifikan dalam empat kelompok umum :
1. Profesional Sistem (system professional) adalah analis, teknisi sistem, dan
programmer. Orang-orang inilah yang akan membangun sistem. Mereka
mengumpulkan berbagai fakta mengenai masalah dalam sistem yang telah ada,
menganalisis fakta tersebut, dan merumuskan solusi untuk mengatasi masalah tersebut.
Hasil dari usaha mereka adalah sistem baru.
2. Pengguna Akhir (end user) adalah pihak untuk siapa sistem dibangun. Terdapat
banyak pengguna akhir engan berbagai tingakatan dalam sebuah perusahaan. Para
pengguna tersebut meliputi para manajer, personel operasional, akuntan, dan auditor
internal. Dalam beberapa perusahaan, sulit untuk menemukan pihak yang bukan
pengguna. Dalam proses pengembangan sistem, profesional sistem bekerja bersama
para pengguna utama untuk mendapatkan pemahaman mengenai masalah pengguna dan
mendapatkan pernyataan yang jelas mengenai kebutuhan mereka.
3. Pemegang Kepentingan (stakeholder) adalah orang-orang di dalam atau di luar
perusahaan yang memiliki kepentingan atas sistem terkait akan tetapi bukan merupakan
pengguna akir sistem tersebut. Orang-orang ini meliputi akuntan, auditor internal dan
eksternal, serta komite pengarah internalyang mengawasi pengembangan sistem.
4. Akuntan/Auditor (accountant/auditor) adalah profesional yang menangani berbagai
isu pengendalian, akuntansi, dan audit untuk pengembangan auditor SI. Akan tetapi,
standar dan etika profesional membatasi tingkat keterlibatan-keterlibatan mereka dalam
beberapa hal, dan melarang keterlibatan langsung auditor eksternal. Keterlibatan
mereka akan lebih kepada memberikan petunjuk dan inout secara umum. Pembatasan
ini digerakkan oleh adanya kebutuhan akan independensi di pihak semua auditor.

Mengapa Akuntan dan Auditor Dilibatkan Dalam SDLC?

 Proses SDLC penting bagi akuntan dan auditor karena dua alasan. Pertama, pembuatan
sistem informasi berkaitan dengan transaksi keuangan yang signifikan, secara konseptual
pengembangan sistem sama seperti proses produksi lainnya yang menghasilkan sebuah
produk yang rumit melalui serangkaian tahapan. Transaksi semacam ini harus direncanakan,
diotorisasi, dijadwalkan, diperhitungkan, dan dikendalikan. Para akuntan akan harus juga
memerhatikan integritas proses ini seperti mereka memerhatikan prosesproduksi yang
memiliki berbagai implikasi sumber daya keuangan. Karena latar belakang, pengalaman, dan
pelatihannya, akuntan dan auditor adalah akhir dalam transaksi keuangan sehingga dapat
mmberikan input yang sangat penting pada sistem berkaitan dengan pengendalian, integritas,
ketepatan waktu, dan sejumlah aspek penting lainnya dalam transaksi keuangan.
Alasan kedua dan yang lebih banyak mendapat perhatian dari akuntan dan auditor
adalah sifat dari produk yang dihasilkan dari SDLC. Kualitas informasi akuntansi tergantung
secara langsung pada aktivitas SDLC yang menghasilkan sistem informasi akuntansi (SIA).
Sistem ini digunakan untuk memberikan informasi akuntansi kepada para pengguna internal
dan eksternal. Tanggung jawab akuntan adalah untuk memastikan bahwa sistem terkait
menggunakan konvensi dan aturan akuntansi yang tepat, serta memiliki pengendalian yang
memadai. Oleh karenanya, akuntan harus sangat peduli dengan kualitas proses yang
menghasilkan SIA. Contohnya, sebuah sistem pesanan penjualan yang dihasilkan oleh SDLC
yang tidak baik akan memiliki sejumlah kelemahan pengendalian yang serius yang dapat
membuat kesalahan dalam catatan akuntansi keuangan, atau memberikan peluang bagi pelaku
penipuan untuk mencuri dari perusahaan.

Bagaimana Cara Akuntan Dilibatkan Dalam SLDC?

Para akuntan dilibatkan dalam pengembangan sistem melalui tiga cara. Pertama,
akuntan adalah pengguna. Semua sistem yang memproses transaksi keuangan akan
berdampak pada fungsi akuntansi dalam hal tertentu. Seperti juga semua pengguna lainnya,
akuntan harus memberikan gambaran yang jelas mengenai berbagai masalah dan
kebutuhannya kepada para profesional sistem. Contohnya, akuntan harus menentukan teknik
akuntansi yang akan digunakan, kebutuhan pengendalian internal (seperti jejak audit), dan
algoritme khusus (seperti model depresiasi).
Kedua, akuntan berpartisipasi dalam pengembangan sistem sebagai anggota tim
pengembangan. Keterlibatan mereka sering kali jauh meluas di luar dari pengembangan
aplikasi SIA. Sistem yang tidak memproses transaksi keuangan secara langsung dapat saja
dibentuk dari data akuntansi. Akuntan dapat dijadikan rujukan untuk memberikan saran atau
menentukan apakah sistem yang diusulkan memiliki risiko pengendalian internal. Dalam
kondisi apa pun, tingkat partisipasi auditor dibatasi oleh isu independensi dalam standar dan
etika profesinya.
Ketiga, akuntan dilibatkan dalam pengembangan sistem sebagai auditor. Sistem
informasi akuntansi harus dapat diaudit. Beberapa teknik audit komputer membutuhkan fitur-
fitur khusus yang harus di desain dalam sistem terkait. Contohnya, semakin elektronik suatu
sistem, maka akan makin banyak daftar (log) dan informasi dalam daftar yang penting,
sehingga auditor akan makin membutuhkan data daftar. Auditor/akuntan memiliki
kepentingan terhadap semua sistem, sehingga mereka harus dilibatkan dari awal dalam tahap
desain, terutama yang berkaitan dengan dapat tidaknya sistem diaudit (audibility), keamanan,
dan pengendalian.

PENGADAAN SISTEM INFORMASI

Perusahaan biasanya mengadakan sistem informasi melalui dua cara: (1)
mengembangkan sistem khusus secara internal melalui aktivitas pengembangan sistem
formal, dan (2) membeli sistem komersial dari vendor peranti lunak. Bagian ini akan
membahas dua alternatif tersebut.
1. Pengembangan Secara Internal
Banyak perusahaan membutuhkan sistem informasi yang dapat disesuaikan dengan
operasi bisnis khususnya. Perusahaan-perusahaan ini mendesain sendiri sistem informasi
melalui aktivitas pengembangan sistem secara internal. Pengembangan secara internal
membutuhkan keberadaan staf sistem tetap sebagai analis serta programer yang akan
mengidentifikasi kebutuhan informasi para pengguna dan memuaskan kebutuhan mereka
melalui sistem yang disesuaikan.
2. Sistem Komersial
Makin banyak sistem yang dibeli dari vendor peranti lunak. Dihadapkan dengan
banyaknya paket peranti lunak yang saling bersaing, masing-masing dengan berbagai fitur
dan atribut uniknya, pihak manajemen harus memilih sistem dan vendor yang dapat dengan
sangat baik melayani kebutuhan perusahaan. Membuat pilihan yang optimal mensyaratkan
bahwa keputusan diambil berdasarkan informasi yang memadai.

Tren dalam Peranti Lunak Komersial

Terdapat empat faktor yang mendorong pertumbuhan pasar peranri lunak komersial,
yaitu : (1) biaya yang relatif rendah peranti lunak komersial pada umumnya jika
dibandingkan dengan peranti lunak yang disesuaikan; (2) perkembangan para vendor yang
mengkhususkan diri pada industri tertentu yang mengarahkan peranti lunak mereka untuk
memenuhi kebutuhan jenis bisnis tertentu: (3) pertumbuhan permintaan dari bisnis yang
terlalu kecil untuk mampu memiliki staf pengembangan sistem internal, dan (4) tren menuju
perampingan unit organisasi serta perpindahan menuju lingkungan pemrosesan datayang
terdistribusi telah membuat pilihan peranti lunak komersial lebih menarik bagi perusahaan
yang lebih besar ukurannya. Bahkan, banyak perusahaan yang memiliki staf pengembangan
sistem internal akan membeli peranti lunak komersial jika kebutuhan perusahaan menuntut
hal tersebut. Peranti lunak komersial dapat dikategorikan ke dalam tiga kelompok: sistem
siap pakai, sistem backbone, dan sistem dengan dukungan vendor.

JENIS SISTEM KOMERSIAL

a). Sistem Siap Pakai
Sistem siap pakai (turnkey system) adalah sistem yang sepenuhnya lengkap dan teruji
serta yang siap untuk diimplementasikan. Sistem ini sering kali berupa sistem bertujuan
umum (general-purpose system) atau sistem yang disesuaikan untuk jenis industri tertentu.
Sistem siap pakai biasanya hanya dijual dalam bentuk gabungan beberapa modul program,
dan pengguna memiliki kemampuan terbatas untuk menyesuaikannya dengan kebutuhannya.
Beberapa sistem siap pakai memiliki pilihan peranti lunak yang memungkinkan pengguna
untuk menyesuaikan input, output, dan beberapa pemrosesan melalui pilihan-pilihan menu.
Vendor sistem siap pakai lainnya akan mengirim kode sumber ke pelanggan jika perubahan
program diinginkan. Dengan biaya tertentu, pengguna atau vendor kemudian dapat
menyesuaikan sistem terkait melalui pemrograman ulang kode sumber aslinya. Beberapa
contoh dari sistem siap pakai dijelaskan berikut ini.
b). Sistem Akuntansi Umum
Sistem akuntansi umum (general accounting system) didesain untuk melayani berbagai
jenis kebutuhan pengguna. Melalui produksi missal sebuah sistem standar, vendor dapat
mengurangi biaya perunit sistem ini hingga menjadi sangat kecil daripada biaya
pengembangan sistem secara internal. Sistem canggih sejenis ini bisa didapat dengan biaya
dibawah $2.000.
Untuk memberikan fleksibilitas sebanyak mungkin, sistem akuntansi umum didesain
dalam bentuk modul-modul. Hal ini memungkinkan para pengguna untuk membeli modul-
modul yang memenuhi kebutuhan tertentu mereka. Modul-modul umum meliputi modul
utang usaha, piutang usaha, pemrosesan penggajian, pengendalian persediaan, buku besar,
laporan keuangan, dan aktiva tetap.
c). Sistem Bertujuan Khusus
Beberapa vendor peranti lunak membuat sistem bertujuan khusus (special-purpose
system) yang diarahkan bagi beberapa segmen tertentu dalam ekonomi. Contohnya, bidang
medis, industri perbankan, dan lembaga pemerintahan memiliki berbagai prosedur, aturan,
konvensi akuntansi yang unik, yang tidak selalu diakomodasi dalam prinsip akuntansi yang
berterima umum. Para vendor peranti lunak karenanya mengembangkan sistem standar untuk
menangani berbagai prosedur yang khusus untuk industri tertentu tersebut.
d). Sistem Otomatisasi Kantor
Sistem otomatisasi kantor (office automation system) adalah sistem computer yang
meningkatkan produktivitas para pekerja kantor. Contoh dari sistem otomatisasi kantor
meliputi pengolahan kata, sistem manajemen basis data, program spreadsheet, serta sistem
desktop publishing.
e). Sistem Backbone
Sistem backbone (backbone system) menyediakan struktur sistem dasar yang dapat
dikembangkan. Sistem backbonedilengkapi dengan semua modul pemrosesan utama yang
telah deprogram. Vendor akan mendesain dan memprogram antarmuka pengguna untuk
menyesuaikan dengan kebutuhan pengguna. Beberapa sistem seperti perencanaan sumber
daya perusahaan (Enterprise Resource Planning- ERP) menawarkan banyak sekali modul
untuk menangani hampir semua proses bisnis, dan semuanya dapat dihubungkan tanpa
terlihat ke dalam satu sistem tanggal. Dengan memilih modul yang sesuai, pelanggan dapat
membuat sebuah sistem yang disesuaikan. Akan tetapi, menyesuaikan sebuah sistem
komersial biayanya mahal dan memakan banyak waktu. Sistem ERP fungsional penuh
biasanya akan membutuhkan waktu 18 hingga 24 bulan instalasinya dan biaya berkisar dari
$10 juta hingga $100 juta.
f). Sistem dengan Dukungan Vendor
Sistem dengan dukungan vendor (vendor-supported system) adalah gabungan dari
sistem yang disesuaikan dengan peranti lunak komersial. Dalam pendekatan ini, vendor
mengembangkan (dan memelihara) sistem yang disesuaikan bagi para kliennya. Sistem itu
sendiri merupakan produk yang disesuaikan secara komersial. Pilihan ini banyak digunakan
dalam industri perawatan kesehatan dan jasa hukum, karena vendor berfungsi sebagai staf
pengembangan sistem internal perusahaan, perusahaan klien harus bergantung pada vendor
dalam hal penyediaan pemrograman yang disesuaikan san pemeliharaan di lokasi kantor atas
sistem terkait. Kebanyakan dari sistem klien dapat dikembangkan dari nol, tetapi dengan
menggunakan pendekatan yang berorientasi pada objek, vendor dapat digunakan lagi untuk
sistem kklien lainnya. Pendekatan ini membantu mengurangi biaya pengembangan sistem
yang dibebankan pada perusahaan yang menjadi klien.

Keungulan Peranti Lunak Komersial

 Waktu Implementasi. Sistem yang disesuaikan sering kali membutuhkan waktu lama
untuk pengembangannya. Berbulan-bulan atau bahkan beberapa tahun harus dilewati
sebelum sebuah sistem yang disesuaikan dapat dikembangkan memalui prosedur
pengembangan internal. Kecuali jika perusahaan berhasil mengantisipasi kebutuhan
informasi di masa mendatang dan menjadwalkan pengembangan aplikasi sesuai
kebutuhan tesebut, maka perusahaan dapat mengalami waktu tunggu yang sangat lama
sebelum kebutuhannya terpenuhi. Akan tetapi, peranti lunak komersial dapat
diimplementasikan hampir secara langsung pada saat timbul kebutuhan.
Penggunaannya tidak harus menunggu.
 Biaya. Seorang pengguna akan secara penuh menanggung biaya pengembangan
internal. Akan tetapi, karena biaya peranti lunak komersial disebarkan ke banyak
pengguna, biaya perunit berkurang hingga menjadi sebagian kecil saja dari biaya sistem
yang dikembangkan secara internal.
 Keandalan. Kebanyakan peranti lunak komersial telah diuji secara menyeluruh
sebelum dilepaskan ke pasar. Segala kesalahan sistem yang tidak ditemukan dalam
pengujian akan dapat ditemukan oleh perusahaan pengguna sistem ketika peranti lunak
dirilis dan dapat segera diperbaiki. Walaupun tidak ada sistem yang dijamin bebas dari
kesalahan, peranti lunak komersial memiliki lebih sedikit kesalahan daripada sistem
yang dikembangkan secara internal.

Kelemahan Peranti Lunak Komersial

 Independensi. Memiliki sistem yang didukung oleh vendor membuat perusahaan
tergantung pada vendor untuk pemeliharaan. Pengguna akan menghadapi risiko vendor
tidak lagi mendukung sistem tersebut atau bahkan bangkrut. Hal ini mungkin
merupakan kelemahan paling besar dari sistem yang didukung oleh vendor.
 Kebutuhan akan sistem yang disesuaikan. Keunggulan utama dari pengembangan
secara internal adalah kemampuan untuk menghasilkan berbagai aplikasi yang memiliki
spesifikasi tepat seperti yang dibutuhkan. Keunggulan ini juga menggambarkan
kelemahan dari peranti lunak komersial. Kadang kebutuhan pengguna bersifat unit dan
kompleks, padahal peranti lunak komersial yang tersedia terlalu umm atau terlalu tidak
fleksibel.
 Pemeliharaan. Sistem informasi bisnis sering mengalami perubahan. Jika kebutuhan
pengguna berubah, maka akan sulit atau bahkan tidak mungkin untuk memodifikasi
 peranti lunak komersial. Akan tetapi, pengembangan secara internal memberikan para
pengguna aplikasi berhak cipta yang dapat secara ekonomis dipelihara.

Siklus Hidup Pengembangan Sistem

Pilihan pengembangan secara internal dan peranti lunak komersial memiliki berbagai
kelemahan dan keunggulan. Sebuah perusahaan dapat memenuhi beberapa kebutuhan
informasinya dengan membeli peranti lunak komersial dan mengembangkan sistem lainnya
secara internal. Kedua pendekatan tersebut dikuatkan melalui prosedur formal yang
membentuk struktur ke proses pengambilan keputusan. Siklus hidup pengembangan sistem
yang akan dibahas berikut ini biasanya berhubungan dengan pengembangan secara internal,
akan tetapi, banyak dari tahapannya, terutama tahapan yang melibatkan analisis kebutuhan
dan spesifikasi sistem, dapat secara efektif digunakan bahkan perusahaan membeli sistem jadi
dari vendor luar.
Tujuan dan urutan aktivitas siklus hidup pengembangan sistem (system development
life cycle-SDLC) bersifat logis dan secara umum diterima oleh para ahli dalam komunitas
sistem, serta umumnya dianggap sebagai “praktik terbaik” untuk pengembangan sistem. Akan
tetapi, jumlah dan nama dan tahapan tertentu dalam proses ini masih menjadi perdebatan.
Beberapa pihak berwenang yang berbeda mengajukan berbagai model SDLC dengan 4
hingga 14 aktivitas khusus. Dari susut pandang audit, jumlah tahapan yang sesunggunya
tidaklah penting. Substansi dan aplikasi yang konsisten dari proses ini akan lebih penting,
apapun definisinya. SDLC dalam figure 4-1 adalah proses delapan tahap yang terdiri atas dua
tahapan utama pengembangan dan pemeliharaan sistem baru.
Tujuh tahapan pertama dalam SDLC menggambarkan berbagai aktivitas yang harus
dilalui oleh semua sistem baru. Pengembangan sistem baru (new system development)
melibatkan berbagai tahapan konseptual yang dapat digunakan untuk segala proses
pemecahan masalah : mengidentifikasi masalah, memahami hal yang harus dilakukan,
mempertimbangkan berbagai alternatif solusi, memilih solusi yang terbaik, dan terakhir,
mengimplementasikan solusi tersebut. Tiap tahap dalam SDLC menghasilkan serangkaian
dokumentasi yang harus dibuat dan secara bersama-sama membentuk suatu rangkaian bukti
audit mengenai kualitas SDLC secara keseluruhan.
1. Perencanaan sistem
2. Analisis sistem
3. Desain konseptual sistem
4. Evaluasi dan pemilihan sistem
5. Desain terperinci
6. Pemrograman dan pengujian sistem
7. Implementasi sistem
Tahap kedelapan, yaitu pemeliharaan sistem (system maintenance), melintasi sebagian
besar dari siklus hidup sistem. Tahap ini dimulai ketika ketujuh tahap pengembangan sistem
selesai dan sistem telah diimplementasikan penuh. Masing-masing dari berbagai tahap
tersebut dijelaskan secara singkat di bawah ini.
PERENCANAAN SISTEM – TAHAP 1
Tujuan dari perencanaan sistem (system planning) adalah menghubungkan berbagai
proyek sistem atau aplikasi dengan tujuan strategis perusahaan. Bahkan, dasar untuk
perencanaan sistem adalah rencana bisnis perusahaan, yang menspesifikasikan ke mana
perusahaan rencananya akan menuju dan bagaimana cara perusahaan untuk mencapai ke
tujuan tersebut. Secara khusus, berbagai proyek sistem dianalisis dengan menggunakan
rencana strategis TI, yang dikembangkan dari dan sesuai dengan rencana bisnis perusahaan.
Figure 4-2 menyajikan hubungan antara berbagai tahapan ini beserta tujuan strategis
perusahaan. Harus ada kesesuaian antara tiap proyek dengan rencana bisnis, atau perusahaan
akan gagal memenuhi tujuannya. Perencanaan sistem yang efektif memberikan kesesuaian
dengan tujuan ini.
Siapa yang Seharusnya Melakukan Perencanaan Sistem?
Kebanyakan perusahaan yang menganggap serius perencanaan sistem akan membentuk
komite pengarah untuk memberikan petunjuk dan mengkaji status dari berbagai proyek
sistem. Komposisi dari komite pengarah (steering committee) dapat meliputi CEO, direktur
keuangan, direktur informasi, pihak manajemen senior dari berbagai area pengguna, auditor
internal, dan pihak manajemen senior dari layanan komputer. Pihak-pihak eksternal, seperti
konsultan manajemen dan auditor eksternal perusahaan, juga dapat melengkapi komite ini.
Tanggung jawab umum untuk komite pengarah meliputi hal-hal berikut ini:
 Mengatasi berbagai konflik yang timbul dari sistem baru
 Mengkaji berbagai proyek dan menetapkan prioritas
 Menganggarkan dana untuk pengembangan sistem
 Mengkaji status tiap proyek yang sedang berjalan
 Menentukan melalui berbagai titik pemeriksaan di seluruh SDLC apakah akan
melanjutkan proyek atau menghentikannya.
Perencanaan sistem terjadi dalam dua tingkat: perencanaan sistem strategis dan
perencanaan proyek.

Perencanaan Sistem Strategis

Perencanaan sistem strategis (strategic system planning) melibatkan alokasi berbagai
sumber daya sistem ditingkat makro. Biasanya perencanan ini berhubungan dengan kerangka
waktu hingga lima tahun. Proses ini hampir sama dengan penganggaran sumber daya untuk
aktivitas strategis lainnya, seperti pengembangan produk, ekspansi pabrik, riset pasar,
teknologi produksi.
Secara teknis, perencanaan sistem strategis bukanlah bagian dari SDLC karena SDLC
berhubungan dengan aplikasi tertentu. Rencana sistem strategis berkaitan dengan alokasi
berbagai sumber daya sistem seperti karyawan (jumlah profesional sistem yang harus
dikontrak), peranti keras (jumlah terminal kerja, minikomputer, dan mainframe yang harus
dibeli), peranti lunak (dana yang dialokasikan untuk proyek sistem baru dan untuk
pemeliharaan sistem), serta telekomunikasi (dana yang dialokasikan untuk jaringan dan EDI).
Penting untuk diperhatikan bahwa rencana strategis menghindari terlalu banyak perincian.
Rencana tersebut harus memunginkan para spesialis sistem untuk membuat keputusan
berdasarkan informasi yang memadai dengan mempertimbangkan berbagai faktor yang
relevan, seperti harga, ukuran kinerja, ukuran, keamanan dan pengendalian.

Mengapa Melakukan Perencanaan Sistem Strategis?

Mungkin tidak ada aspek dalam aktivitas bisnis perusahaan yang sangat labil dan tidak
dapat diprediksi seperti perencanaan sistem informasi. Siapa yang dapat memprediksikan
lima tahun mendatang dan secara akurat dapat memprediksi kondisi teknologi sistem? Karena
kelabilan inilah rencana jangka panjang apapun yang dibuat perusahaan tampaknya akan
harus berubah. Oleh karenanya, bagaimana cara perusahaan untuk melakukan perencanaan
sistem strategis? Mengapa harus dilakukan?
Terdapat empat justifikasi untuk perencanaan sistem strategis:
1. Rencana yang berubah secara konstan lebih baik dari pada tidak ada rencana sama
sekali. Perencanaan strategis menggambarkan jalur yang harus diikuti perusahaan untuk
mencapai tujuan sistem informasinya. Bahkan jika itu artinya akan ada banyak
penyesuaian ditengah jalan, perncanaan jauh lebih baik daripad berjalan-jalan tanpa
arah ditengah hutan rimba.
2. Perencanaan strategis mengurangi komponen krisis dalam pengembangan sistem.
Rencana yang formal adalah model untuk mengidentifikasi dan membuat prioritas
kebutuhan pengguna. Rencana ini memungkinkan pihak manajemen untuk
mempertimbangkan berbagai kebutuhan dimasa mendatang, mengenali masalah secara
dini, dan bahkan mengantisipasi berbagai kebutuhan sebelum timbul gejala masalah.
Jika tidak ada rencana pemicu yang akan menstimulasi pengembangan sistem adalah
pengenalan masalah.
3. Perencanaan strategis sistem memberikan pengendalian otorisasi untuk SDLC.
Rencana sistem strategis menata aturan otorisasi untuk memastikan bahwa keputusan
untuk mengembangkan sistem tertentu sesuai dengan berinvestasi dalam pabrik dan
perlengkapan yang salah.
4. Perencanaan sistem strategis memang selalu berhasil baik! Secara historis,
perencanaan sistem telah terbukti merupakan alat yang efektif dari segi biaya untuk
mengelola berbagai proyek sistem dan pengembangan aplikasi.

Perencanaan Proyek
Tujuan dari perencanaan proyek (project planning) adalah untuk mengalokasikan
sumber daya ke tiap aplikasi dalam kerangka kerja rencana strategis. Hal ini dapat melibatkan
identifikasi berbagai area kebutuhan pengguna, membuat proposal mengevaluasi kelayakan
tiap proposal dan kontribusinya pada rencana bisnis, membuat prioritas untuk tiap proyek,
dan menjadwalkan berbagai pekerjaan yang akan dilakukan. Tujuan dasar dari perencanaan
proyek adalah untuk mengalokasikan berbagai sumber daya yang sulit didapatkan ke proyek-
proyek tertentu. Hasil dari tahap ini terdiri atas dua dokumen formal, yaitu proposal proyek
dan jadwal proyek.
1) Proposal Proyek (project proposal) memberikan pihak manajemen dasar untuk
memutuskan apakah akan melanjutkan proyek atau tidak. Proposal formal melayani dua
tujuan. Pertama, proposal tersebut meringkas berbagai temuan dari penelitian yang
dilakukan pada tahap ini menjadi rekomendasi umum untuk sistem baru untuk
modifikasi sistem. Hal ini memungkinkan pihak manajemen mengevaluasi masalah
yang dianggap ada bersama dengan sistem yang diusulkan sebagai solusi yang layak
dijalankan. Kedua, proposal tersebut menggambarkan secara garis besar hubungan
antara tujuan dari sistem yang diusulkan dengan tujuan bisnis perusahaan, terutama
dengan yang digambarkan secara umum dalam rencana strategis TI. Proposal ini
menunjukkan bahwa sistem baru yang diusulkan sesuai dengan arah strategis
perusahaan.
2) Jadwal proyek (projects schedule) mewakili komitmen pihak manajemen atas proyek
terkait. Jadwal proyek adalah anggaran waktu dan biaya untuk semua tahapan dalam
SDLC . Sebuah tim proyek yang akan dipilih dari berbagai profesional sistem,
pengguna akhir , dan ahli lainnya, seperti akuntan, dan auditor internal, akan
 melengkapi tahapan ini. Komposisi dari tim tersebut beserta dengan kompetensi dan
dedikasi para anggotanya sangatlah penting bagi keberhasilan sistem baru tersebut.

Peran Auditor dalam Perencanaan Sistem

Auditor secara rutin memeriksa tahap perencanaan sistem dalam SDLC. Sejarah
menunjukkan bahwa perencanaan sistem yang hati-hati adalah teknik pengendalian yang
efektif dari segi biaya dalam proses pengembangan sistem. Perencanaan dapat banyak
mengurangi risiko menghasilkan sistem yang tidak dibutuhkan, tidak diinginkan, dan tidak
efektif. Auditor internal dan eksternal berkepentingan untuk memastikan bahwa terdapat
perencanaan sistem yang memadai.

ANALISIS SISTEM – TAHAP II

Kini pembahasan akan dilanjutkan ke tahap kedua dalam SDLC. Analisis sistem
(system analysis). Sesungguhnya adalah proses dua tahap yang pertama melibatkan survei
atas sistem yang ada dan kemudian analisis kebutuhan pengguna. Masalah bisnis harus
sepenuhnya dipahami oleh analis sistem sebelum dia merumuskan suatu solusi. Analisis yang
tidak lengkap atau cacat akan mengarah pada solusi yang tidak lengkap atau cacat. Oleh
karenanya, analisis sistem adalah dasar bagi keseluruhan tahapan SDLC lainnya. Hasil dari
tahap ini adalah laporan analisis sistem formal, yang menyajikan berbagai temuan dari
analisis dan berbagai rekomendasi untuk sistem yang baru.

Tahap Survei
Kebanyakan sistem tidak dikembangkan dari nol. Biasanya, beberapa bentuk sistem
informasi dan prosedur yang berhubungan telah ada. Analis sering kali memulai bisnis
dengan menentukan elemen apa saja, jika ada, dari sistem yang ada yang harus dipertahankan
sebagai bagian dari sistem baru. Hal ini melibatkan survei sistem (system survey) yang agak
terperinci. Berbagai fakta yang berhubungan dengan pertanyaan awal mengenai sistem
dikumpulkan dan dianalisis. Ketika analis mendapatkan pemahaman yang lebih baik
mengenai masalah yang ada, dia akan mengembangkan pertanyaan yang lebih spesifik yang
membuatnya harus mengumpulkan lebih banyak fakta. Proses ini dapat berjalan melalui
beberapa putaran. Ketika semua fakta yang relevan telah dikumpulkan dan dianalisis, analis
akan harus melakukan penilaian atas sistem yang ada menyurvei sistem yang ada memiliki
berbagai kelemahan dan keunggulan.

Kelemahaan Menyurvei Sistem yang Ada

 Lubang ter (tar pit) fisik yang ada. Istilah ini digunakan untuk menggambarkan tedensi
analis yang menjadi “terhisap di dalam” dan kemudian “terbenam” oleh pekerjaan
menyurvei sistem warisan yang ada.
 Berpikir di dalam kotak. Beberapa pihak berargumentasi bahwa survei sistem yang
telah ada akan menghambat ide baru. Dengan mempelajari dan membuat model sistem
yang lama, analis dapat mengembangkan sebuah ide pembatas atas bagaimana sistem
yang baru seharusnya berfungsi. Hasilnya adalah perbaikan sistem yang lama, bukan
merupakan pendekatan baru yang radikal.
Keunggulan Menyurvei Sistem yang Ada
 Mengidentifikasi aspek saja yang harus dipertahankan dari sistem yang lama. Beberapa
elemen sistem mungkin sudah berfungsi cukup baik dan dapat menjadi dasar bagi
sistem yang baru. Dengan memahami secara penuh sistem yang ada, analis dapat
mengidentifikasi berbagai aspek yang bernilai untuk dipertahankan atau yang harus
dimodifikasi untuk digunakan ke dalam sistem yang baru.
 Memaksa analis sistem untuk memahami sistem secara penuh. Ketika sistem harus
diimplementasikan, para pengguna harus melalui proses konversi dimana mereka akan
secara formal keluar dari sistem yang lama dan berpindah ke yang baru. Analis harys
menentukan pekerjaan, prosedur, dan data yang akan dikeluarkan sistem yang lama dan
mana yang akan dilanjutkan. Untuk menentukan prosedur konversi ini, analis harys
tidak saja mengetahui apa yang akan harus dilakukan oleh sistem yang baru, tetapi juga
apa yang akan dapat dilakukan oleh sistem yang lama. Hal ini membutuhkan
pemahaman menyeluruh terhadap sistem yang ada.
 Memisahkan akar permasalahan dari gejala. Dengan menyurvei sistem yang ada, analis
dapat menentukan secara konklusif penyebab dari berbagai gejala masalah yang
dilaporkan. Mungkin akar masalahnya sama sekali bukan berkaitan dengan sistem
informasi; mungkin akar masalah tersebut adalah masalah pihak manajemen atau
karyawan yang dapat diatasi tanpa mendesain ulang sistem informasi terkait. Mungkin
akan sulit untuk mengidentifikasi akar masalah jika membuat sistem yang ada tanpa
melakukan penyelidikan atas berbagai gejalanya.

Mengumpulkan Fakta
Survei sistem yang ada pada dasarnya adalah aktivitas mengumpulkan fakta. Berbagai
fakta yang dikumpulkan oleh analis adalah potongan-potongan data yang menjelaskan fitur
penting, situasi, dan hubungan dalam sistem. Fakta-fakta sistem dapat digolongkan ke dalam
beberapa kategori umum berikut ini.
 Sumber data (data source). Sumber data meliputi berbagai entitas eksternal, seperti
pelanggan atau vendor, serta sumber-sumber internal dari berbagai departemen lainnya.
 Pengguna (User). Pengguna meliputi para manajer dan pengguna operasi.
 Penyimpanan data (data store). Penyimpanan data berbentuk file, basis data, akun,
dan berbagai dokumen sumber yang digunakan dalam sistem.
 Proses (process). Pekerjaan pemrosesan adalah operasi manual atau komputer
yanmewakili keputusan atau tindakan yang dipicu oleh informasi.
 Aliran data (data flow). Aliran data diwakili oleh perpindahan berbagai dokumen dan
laporan antarsumber data, penyimpanan data, pekerjaan pemrosesan, dan pengguna.
Aliran data juga dapat diwakili dalam berbagai diagram UML.
 Pengendalian (control). Pengendalian meliputi pengendalian akuntansi dan operasional
dan dapat berupa berbagai prosedur manual atau pengendalian komputer.
 Volume transaksi (transaction Volume). Analis harus mendapatkan suatu ukuran atas
volume transaksi untuk periode waktu tertentu. Banyak sistem digantj karena sistem
tersebut telah mencapai kapasitas maksimalnya. Pemahaman terhadap berbagai
 karakteristik volume transaksi suatu sistem dan tingkat pertumbuhannya adalah elemen-
elemen penting untuk menilai kebutuhan kapasitas sistem yang baru.
 Tingkat kesalahan (error rate). Kesalahan transaksi sangat erat kaitannya dengan
volume transaksi. Ketika suatu sistem mencapai kapasitas maksimalnya, tingkat
kesalahan akan meningkat hingga mencapai tingkat yang tidak dapat lagi ditoleransi.
 Biaya Sumber Daya(resource cost). Berbagai sumber daya yang digunakan oleh
sistem yang ada meliputi biay tenaga kerja langsung. Biaya sumber daya apapun yang
tidak lagi timbul ketika sistem yang ada ditiadakan disebut sebagai biaya yang dapat
dihindari. Dibagian lain, ketika melakukan analisis biaya manfaat, biaya yang dapat
dihindari akan diperlakukan sebagai manfaat sistem yang baru.
 Kemacetan dan operasi yang redundan (bottleneck and redundant operation). Analis
harus mencatat berbagai titik dimana aliran data menjadi satu sehingga membentuk
penyempitan. Pada periode puncak, kondisi ini akan mengakibatkan penundaan dan
menyebabkan kesalahan pemrosesan.

Teknik Pengumpulan Fakta

Analis sistem mengumpulkan beberapa teknik untuk mengumpulkan berbagai fakta
yang sebelumnya telah disebutkan. Teknik-teknik yang biasanya digunakan meliputi
observasi melibatkan diri dalam pekerjaan, wawancara personal, serta mengkaji berbagai
dokumen penting.
1) Observasi
Observasi melibatkan pengamatan secara pasif berbagai prosedur fisik dalam sistem.
Obesrvasi memungkinkan analis menentukan hal apa saja yang dilaksanakan, siapa yan
melaksanakan berbagai pekerjaan terkait, kapan dilakukannya, bagaimana cara
melakukannya, dan seberapa lama waktu yang dibutuhkan untuk melakukannya.
2) Keterlibatan dalam pekerjaan
Keterlibatan adalah perluasan dari observasi, dimata analis mengambil peran aktif
dalam melakukan pekerjaan pengguna. Hal ini memungkinkan analis mendapat pengalaman
langsung dari berbagai masalah yang dilibatkan dalam operasi sistem yang ada. Contohnya,
analis dapat bekerja dibagian penjualan untuk mencatat pesanan dari pelanggan dan membuat
pesanan penjualan. Analis dapat menentukan bahwa dokumen tidak didesain dengan baik,
terdapat kekurangan waktu untuk melakukan prosedur yang dibutuhkan, atau masalah beban
puncak menyebabkan penyempitan dan kesalahan pemrosesan. Dengan pengalaman
langsung, analis sering kali dapat membayangkan cara-cara yang lebih baik untuk melakukan
pekerjaan terkait.
3) Wawancara Personal
Wawancara adalah metode untuk mengekstraksi fakta mengenai sistem yang ada dan
persepsi pengguna mengenai berbagai kebutuhan akan sistem yang baru. Instrumen yang
digunakan untuk mengumpulkan berbagai fakta tersebut dapat berupa pertanyaan dengan
jawaban terbuka (open-ended question) kuesioner formal.
 Pertanyaan dengan jawaban terbuka memungkinkan para pengguna untuk meneliti
masalah ketika muncul dan memberikan saran serta rekomendasi. Berbagai jawaban
atas pertanyaan ini cenderung sulit dianalisis, akan tetapi jawaban-jawaban tersebut
memberikan analis pandangan atas lingkup masalah, Analis dalam wawancara jenis ini
 harus menjadi pendengar yang baik dan mampu memfokuskan diri pada fakta-fakta
yang penting.
 Kuesioner digunakan untuk menanyakan beberapa pertanyaan yang lebih spesifik dan
terperinci serta untuk membatasi berbagai respons dari para pengguna. Teknik ini
adalah teknik yang baik untuk mengumpulkan berbagai fakta objektif mengenai sifat
dari berbagai prosedur tertentu, volume transaksi yang diproses, sumber data, pengguna
laporan, dan berbagai isu pengendalian.
4) Mengkaji Dokumen Sumber
Dokumen-dokumen perusahaan adalah sumber lain fakta mengenai sistem yang sedang
disurvei. Beberapa contoh dari dokumen ini meliputi:
 Struktur organisasi
 Deskripsi pekerjaan
 Catatan akuntansi
 Daftar akun
 Pernyataan kebijakan
 Deskripsi prosedur
 Laporan keuangan
 Laporan kinerja
 Bagan alir sistem
 Dokumen sumber
 Daftar transaksi
 Anggaran
 Prediksi
 Pernyataan misi
Setelah tahap pengumpulan fakta, analis secara formal akan mendokumentasikan
berbagai hal yang ditangkapnya dan dipahaminya atas sistem terkait. Dokumentasi ini akan
berbentuk catatan, bagan alir sistem, dan diagram aliran data.

Tahap Analisis
Analisis sistem adalah proses intelektual yang berbaur dengan pengumpulan fakta. Analis
secara simultan akan menganalisis ketika dua melakukan pengumpulan fakta. Pengetahuan
akan suatu masalah saja menunjukkan adanya pemahaman mengenai norma atau kondisi
yang yang diinginkan. Oleh karenanya sulit untuk mengidentifikasi saat dimana survei
berakhir dan analisis dimulai.

Laporan Analisis Sistem

Peristiwa yang menandai selesainya tahapan analis sistem adalah pembuatab laporan
analisis sistem formal. Laporan ini menyajikan pihak manajemen atau komite pengarah
berbagai temuan survei, masalah yang diidentifikasi dalam sistem yang ada, kebutuhan
pengguna, dan kebutuhan sistem yang baru. Figur 4-3 berisi format yang mungkin digunakan
untuk laporan sejenis ini. Tujuan utama untuk melakukan analisis sistem adalah untuk
mengidentifikasi berbagai kebutuhan pengguna dan menspesifikasikan berbagai kebutuhan
untuk sistem yang baru. Laporan tersebut harus menyajikan secara terperinci apa yang akan
harus dilakukan oleh sistem, bukan bagaimana cara melakukannya. Pernyataan mengenai
kebutuhan dalam laporan akan membentuk pemahaman diantara profesional sistem, pihak
manajemen, pengguna, dan pemegang kepentingan lainnya. Dokumen ini membentuk
kontrak formal yang menentukan tujuan serta sasaran sistem. Laporan analisis sistem
seharusnya dibuat secara jelas khususnya dalam hal sumber data, pengguna, file data, proses
umum, aliran data, pengendalian dan kapasitas volume transaksi.
Laporan analisis sistem tidak menspesifikasikan desain terperinci dan sistem yang
diusulkan. Contohnya, laporan ini tidak menentukan metode pemrosesan, media
penyimpanan, struktur record, dan berbagai perincian lainnya yang dibutuhkan untuk
mendesain sistem fisiknya. Sebagai gantinya, laporan tersebut tetap berada pada tingkatan
tujuan untuk menghindari adanya pembatasan buatan dalam tahap desain konseptual.
Beberapa kemungkinan desain dapat saja memenuhi kebutuhan pengguna, dan proses
pengembangannya harus dibebaskan untuk mengeksplorasi semua kemungkinan ini.

Peran Auditor dalam Analisis Sistem

Auditor perusahaan (eksternal dan internal) adalah pemegang kepentingan dalam sistem
yang diusulkan. Di bab 8, akan dapat dilihat bagaimana CAATT tertentu (seperti modul audit
melekat dan fasilitas uji terintegrasi) harus didesain ke dalam sistem semasa SDLC. Sering
kali, berbagai fitur audit lanjutan tidak dapat dengan mudah ditambahkan ke sistem yang ada.
Oleh karenanya, akuntan/auditor harus dilibatkan dalam analisis kebutuhan sistem yang
diusulkan untuk menentukan apakah sistem tersebut merupakan kandidat yang baik untuk
fitur audit lanjutan dan, jika memang demikian, fitur mana saja yang paling sesuai untuk
sistem tersebut.

DESAIN KONSEPTUAL SISTEM - TAHAP III

Tujuan dari tahap desain konseptual sistem adalah untuk menghasilkan beberapa
alternatif konsep sistem yang memenuhi berbagai kebutuhan yang teridentifikasi dalam
analisis sistem. Dengan menyajikan sejumlah alternatif yang masuk akal ke pengguna,
profesional sistem menghindari munculnya persepsi mengenai batasan pada sistem yang
baru. Penggunalah yang akan mengevaluasi berbagai model konseptual ini dan memiliki
beberapa alternatif yang tampaknya paling masuk akal dan menarik. Berbagai alternatif
desain ini kemudian akan masuk ke tahap pemilihan sistem dari SDLC, di mana biaya serta
manfaat sistem-sistem tersebut akan diperbandingkan dan nantinya sebuah desain yang paling
optimal akan dipilih.
Dengan mempertahankan desain konseptual sistem dalam seluruh tahapan SDLC, maka
investasi sumber daya untuk berbagai alternatif desain yang nantinya akan ditolak akan
diminimalkan. Konsep sistem yang berkembang akan diteruskan ke tahap-tahap akhir SDLC,
di mana sistem akan didesain secara terperinci dan diimplementasikan.
Bagian ini menjelaskan dua pendekatan untuk desain konseptual sistem, yaitu:
pendekatan terstruktur dan pendekatan berorientasi objek. Pendekatan terstruktur
mengembangkan tiap sistem baru dari nol serta dari atas ke bawah. Desain berorientasi objek
(object-oriented design-OOD) mengembangkan sistem dari bawah ke atas melalui perakitan
berbagai modul yang dapat digunakan kembali, bukan membuat sistem dari nol. OOD sering
kali dikaitkan dengan pendekatan iteratif (iterative approach) dalam SDLC di mana beberapa
bagian kecil atau modul berputar melalui semua tahapan SDLC lebih cepat, dalam jangka
waktu yang pendek dari awal hingga akhir. Kemudian berbagai modul tambahan atau bagian
kecil lainnya akan ditambahkan dalam cara yang tepat sampai sistem telah dikembangkan
secara utuh. Pendekatan-pendekatan ini masih merupakan konsep yang berkembang dalam
SIA, tetapi akan menjadi beberapa malah mengatakan telah menjadi, pendorong dominan
dalam pengembangan sistem.

Pendekatan Desain Terstruktur

Pendekatan desain terstruktur (structured design) adalah cara yang disiplin untuk
mendesain sistem dari atas ke bawah. Pendekatan ini dimulai dengan "gambaran umum"
sistem yang diusulkan yang kemudian secara bertahap akan diuraikan menjadi makin
terperinci hingga sistem terkait dipahami secara penuh. Dalam pendekatan ini, proses bisnis
yang sedang didesain biasanya didokumentasikan melalui diagram aliran data dan diagram
struktur. Figur 4-4 menunjukkan penggunaan berbagai teknik ini untuk memperlihatkan
dekomposisi dari atas ke bawah suatu proses bisnis fiktif.
 Dapat dilihat dari diagram ini bagaimana desainer sistem mengikuti pendekatan dari
atas ke bawah. Desainer akan mulai dengan penjelasan abstrak sistem, dan, melalui berbagai
tahapan berikutnya, meredefinisikan pandangan ini untuk menghasilkan penjelasan yang
lebih terperinci. Dalam contoh, Proses 2.0 di diagram konteks didekomposisikan ke dalam
tingkat menengah DFD. Dekomposisi ini dapat melibatkan beberapa tingkatan untuk
mendapatkan perincian yang memadai. Asumsikan bahwa tiga tingkat sudah cukup memadai
untuk contoh ini. Tahap terakhir adalah mentransformasikan Proses 2.3.3 kedalam sebuah
diagram struktur yang menjelaskan berbagai modul program yang akan membentuk proses
terkait.
Tahap desain konseptual harus menunjukkan perbedaan antara fitur-fitur yang sangat
penting sistem yang saling bersaing satu sama lain, bukan menunjukkan persamaan sistem-
sistem tersebut. Oleh karenanya, desain sistem pada titik ini seharusnya bersifat umum.
Desain tersebut juga seharusnya mengidentifikasi semua input, output, proses, dan fitur
khusus yang dibutuhkan untuk membedakan suatu alternatif dari alternatif lainnya. Figur 4-5
menyajikan dua alternatif desain konseptual sistem untuk sistem pembelian. Desain-desain
ini tidak memiliki perincian yang dibutuhkan untuk mengimplementasikan sistem. Sebagai
contoh, desain tersebut tidak memasukkan komponen penting berikut ini:
 Struktur record basis data
 Perincian pemrosesan
 Teknik pengendalian tertentu
 Format untuk tampilan input dan dokumen sumber
 Format laporan output.
Akan tetapi, desain tersebut memiliki perincian yang memadai untuk menunjukkan
bagaimana kedua sistem tersebut secara konseptual berbeda dari segi fungsinya. Sebagai
gambaran, pelajari fitur dari tiap sistem tersebut.
Pilihan A adalah sistem pembelian batch tradisional. Input awal untuk proses tersebut
adalah permintaan pembelian dari bagian pengendalian persediaan. Ketika persediaan
mencapai titik pemesanan ulang yang telah ditetapkan, persediaan baru akan dipesan sesuai
dengan jumlah pesanan ekonomis persediaan terkait. Pengiriman pesanan pembelian ke para
pemasok akan dilakukan sekali dalam sehari melalui kantor pos.
Sebaliknya, pilihan B menggunakan teknologi EDI. Pemicu sistem ini adalah
permintaan pembelian dari perencanaan produksi. Sistem pembelian akan menetapkan jumlah
dan pemasok, serta kemudian mentransmisikan pesanan tersebut melalui peranti lunak EDI
ke pemasok.
Kedua alternatif tersebut memiliki pro dan kontra. Keuntungan dari pilihan A adalah
kesederhanaan desainnya, kemudahan implementasinya, dan lebih sedikitnya kebutuhan
sumber daya daripada pilihan B. Di sisi lain, aspek negatif pilihan A adalah pilihan ini
membuat perusahaan harus menyimpan banyak persediaan. Di pihak lain, pilihan B
memungkinkan perusahaan mengurangi atau bahkan meniadakan persediaan. Keuntungan ini
didapat bersamaan dengan timbulnya biaya yang lebih mahal dan sumber daya sistem yang
canggih. Akan tetapi, pada titik ini, masih terlalu dini untuk mencoba mengevaluasi berbagai
keunggulan dari kedua alternatif tersebut. Evaluasi tersebut akan dilakukan secara formal di
tahap berikutnya dalam SDLC. Sementara ini, desainer sistem hanya memerhatikan
identifikasi berbagai desain sistem yang masuk akal.
Pendekatan Berorientasi Objek
Pendekatan berorientasi objek (object-oriented design-OOD) mengembangkan sistem
informasi dari berbagai komponen atau objek (object) standar yang dapat digunakan kembali.
Pendekatan ini dapat disetarakan dengan proses membuat mobil. Model-model baru
sebenarnya dibangun dari berbagai komponen standar yang juga ada di model lainnya.
Contohnya, setiap model mobil oleh produsen tertentu dapat menggunakan jenis mesin,
persneling, alternator, as roda, radio, dan sebagainya, dari tipe yang sama. Beberapa
komponen mobil tersebut bahkan merupakan produk standar industri yang digunakan oleh
produsen lainnya. Beberapa hal seperti setir, roda, busi, dan lampu besar masuk dalam
kategori ini. Bahkan, satu-satunya komponen yang benar-benar dibuat dari nol untuk suatu
mobil model baru adalah bagian badan mobil saja.
Industri mobil beroperasi dengan cara ini untuk tetap dapat bersaing. Dengan
menggunakan berbagai komponen standar, para produsen meminimalkan biaya produksi dan
pemeliharaan. Pada saat yang sama produsen mobil tersebut dapat tetap responsif terhadap
permintaan pelanggan atas produk baru dan menjaga fleksibilitas produksi dengan cara
membaurkan dan menyesuaikan berbagai komponen sesuai dengan spesifikasi pelanggan.
Konsep dari penggunaan ulang ini inti dari pendekatan berorientasi objek untuk desain
sistem. Setelah dibuat, berbagai modul standar dapat digunakan dalam sistem lainnya yang
memiliki kebutuhan hampir sama. Idealnya, profesional sistem perusahaan akan menciptakan
perpustakaan (persediaan) berbagai modul yang dapat digunakan oleh desainer sistem lainnya
dalam perusahaan. Manfaat dari pendekatan ini meliputi pengurangan waktu dan biaya
pengembangan, pemeliharaan, dan pengujian, serta peningkatan dukungan bagi pengguna dan
fleksibilitas dalam proses pengembangan.
Metode OOD sering kali juga dikaitkan dengan pendekatan iteratif dalam tahapan
desainnya, bukan berupa pendekatan yang seperti air terjun, atau proyek yang selesai.
Pendekatan air terjun melihat keseluruhan proyek dan membagi proses ke dalam berbagai
fungsi proyek, seperti yang digambarkan secara garis besar dalam bab ini (analisis, desain,
dan lain-lain). Pengembangan iteratif menggunakan serangkaian proyek (contohnya, modul)
yang berbeda serta menyelesaikan keseluruhan siklus SDLC untuk mengembangkan bagian
dari proyek yang lebih besar. Hasilnya adalah aplikasi yang berfungsi sebagai subrangkaian
dari keseluruhan proyek. Fungsi-fungsi tertentu seperti pelatihan dilakukanpadaakhir semua
subrangkaian dan iterasi. Komunitas OO harus secara eksklusif menggunakan pendekatan
iteratif. Contohnya, saat seorang ahli UML dan OO, Martin Fowler, berkata, Anda seharusnya
menggunakan pendekatan iteratif hanya untuk proyek yang Anda ingin pastikan
keberhasilannya.

Peran Auditor dalam Desain Konseptual Sistem

Auditor adalah pemegang kepentingan dalam semua sistem keuangan dan karenanya,
memiliki kepentingan dalam tahap desain konseptual sistem. Dapat tidaknya suatu sistem
diaudit tergantung sebagian pada karakteristik desainnya. Beberapa teknik audit komputer
mengharuskan sistem didesain dengan fitur audit khusus yang merupakan kesatuan dari
sistem tersebut. Fitur-fitur audit ini harus dispesifikasikan pada tahap desain konseptual.

EVALUASI DAN PEMILIHAN SISTEM - TAHAP IV

Tahap berikutnya dalam SDLC adalah prosedur untuk memilih salah satu sistem dari
serangkaian alternatif desain konseptual yang akan diteruskan ke tahap desain terperinci.
Tahap evaluasi dan pemilihan sistem (system evaluation and selection) adalah proses
optimalisasi yang bertujuan mengidentifikasi sistem yang terbaik. Keputusan ini mewakili
tahap yang sangat penting dalam SDLC.
Pada titik ini, terdapat banyak sekali ketidakpastian mengenai sistem, dan keputusan
yang kurang baik dalam tahap ini dapat sangat berbahaya. Tujuan dari prosedur formal
evaluasi dan pemilihan adalah untuk menstrukturisasi proses pengambilan keputusan ini dan
karenanya mengurangi ketidakpastian dan risiko adanya keputusan yang kurang baik. Proses
evaluasi dan pemilihan melibatkan dua tahapan:
1. Melakukan studi kelayakan yang terperinci
2. Melakukan analisis biaya-manfaat

Melakukan Studi Kelayakan yang Terperinci

Pembahasan berikut ini menggambarkan secara umum kelayakan proyek yang perlu
dipertimbangkan. Tiap alternatif proyek akan dinilai dengan cara yang sama. Proyek-proyek
yang dianggap layak kemudian akan diperbandingkan berdasarkan biaya-manfaatnya. Sistem
yang dipilih kemudian akan dilanjutkan ke tahap desain terperinci.

Kelayakan Teknis
Kelayakan teknis berhubungan dengan apakah sistem dapat dikembangkan dengan
teknologi yang ada atau apakah dibutuhkan teknologi baru. Sebagai proposisi umum,
teknologi di pasar jauh lebih maju daripada kemampuan sebagian besar perusahaan untuk
mengaplikasikannya. Oleh karenanya, dari sudut pandang ketersediaan, kelayakan teknis
biasanya bukan menjadi masalah. Bagi kebanyakan perusahaan, masalah sesungguhnya
adalahkeinginan dan kemampuan perusahaan untuk mengaplikasikan teknologi yang tersedia.
Karena teknologi adalah dasar fisik bagi kebanyakan fitur desain sistem, aspek ini sangat
diperhatikan dalam keseluruhan kelayakan berbagai alternatif sistem yang ada.

Kelayakan Hukum
Kelayakan hukum mengidentifikasi konflik antara konsep sistem dengan kemampuan
perusahaan untuk melaksanakan tanggung jawab hukumnya. Di bab-bab sebelumnya, telah
dipelajari perlunya untuk menaatipersyaratan pengendalian yang dinyatakan dalam undang-
undang praktik korupsi asing (Foreign Corrupt Practices Act) tahun 1977 dan SAS 78. Selain
itu, banyak peraturan dan hukum berkaitan dengan pelanggaran privasi serta kerahasiaan
informasi yang disimpan. Pembuat keputusan harus memastikan diri bahwa sistem yang
diusulkan tidak melanggar batasan hukum yang ada.

Kelayakan Operasional
Kelayakan operasional menunjukkan tingkat kesesuaian antara prosedur perusahaan
yang ada dengan berbagai keahlianserta kebutuhan operasional sistem yang baru.
Mengimplementasikan sistem yang baru dapat membutuhkan adopsi prosedur baru dan
pelatihan ulang personel operasional. Pertanyaan yang harus dijawab adalah, bisakah
perubahan prosedural yang memadai dilakukan, ada cukup banya personel yang dilatih ulang,
dan mendapat keahlian baru untuk membuat sistem tersebut secara operasional layak?

Kelayakan Jadwal
Kelayakan jadwal berhubungan dengan kemampuan perusahaan untuk
mengimplementasikan proyek tersebut dalam waktu yang dapat ditoleransi. Faktor kelayakan
ini berdampak pada lingkup proyek dan apakah proyek sistem tersebut akan dikembangkan
secara internal atau dibeli dari vendor peranti lunak. Jika proyek tersebut, seperti yang
digambarkan secara konseptual, tidak dapat dibuat secara internal tepat sesuai target
waktunya, maka desainnya, metodenya, atau tanggal targetnya yang harus diubah.

Melakukan Analisis Biaya-Manfaat

Analisis biaya-manfaat membantu pihak manajemen menentukan apakah (dan seberapa
banyak) manfaat yang diterima dari sistem yang diusulkan akan melebihi biayanya. Teknik
ini sering kali digunakan untuk memperkirakan nilai finansial yang diharapkan dari investasi
bisnis. Akan tetapi, dalam situasi ini, investasinya adalah sistem informasi, dan biaya serta
manfaatnya lebih sulit untuk diidentifikasi dan diukur daripada proyek permodalan biasa.
Walaupun tidak sempurna dalam situasi ini, analisis biaya-manfaat digunakan karena
kesederhanaannya dan karena tidak adanya alternatif lain yang lebih baik
Di luar berbagai keterbatasannya, analisis biaya-manfaat, jika digabungkan dengan
berbagai faktor kelayakan, merupakan alat yang berguna untuk membandingkan berbagai
alternatif desain sistem.
Terdapat tiga tahapan dalam aplikasi analisis biaya-manfaat, yaitu: mengidentifikasi
biaya, mengidentifikasi manfaat, dan membandingkan biaya dengan manfaat. Tiap tahapan
ini akan dibahas di bagian berikut ini.

Mengidentifikasi Biaya
Salah satu metode untuk mengidentifikasi biaya adalah dengan membaginya kedalam
dua kategori: biaya yang timbul sekali (one time cost) dan biaya yang berulang (recurring
cost). Biaya yang hanya timbul sekali meliputi investasi awal untuk mengembangkan dan
mengimplementasikan sistem. Biya yang berulang meliputi biaya operasional dan
pemeliharaan yang terus berulang selama masa hidup sistem terkait. Tabel 4-1 menunjukkan
perincian dari biaya yang hanya timbul sekali dan biaya yang berulang.
Biaya yang hanya timbul sekali meliputi hal-hal berikut ini :
 Pengadaan peranti keras. Biaya ini meliputi biaya mainframe, minikomputer,
mikrokomputer, dan perlengkapan periferal, seperti tape drive, dan disk pack. Angka-
angka biaya ini bisa didapat dari vendor.
 Persiapan lokasi. Biaya ini melibatkan berbagai biaya yang sering kali dilupakan dalam
proses modifikasi bangunan (contohnya, menambahkan AC atau melakukan perubahan
struktural bangunan), instalasi perlengkapan (yang dapat meliputi penggunaan peralatan
berat), dan biaya pengiriman. Perkiraan berbagai biaya ini bisa didapat dari vendor dan
subkontraktor yang melakukan instalasi.
 Pengadaan peranti lunak. Biaya ini berlaku untuk semua peranti lunak yang dibeli
untuk sistem yang diusulkan, termasuk peranti lunak sistem operasi (jika tidak jadi satu
dengan peranti kerasnya), peranti lunak pengendali jaringan, dan aplikasi komersial
(seperti peranti lunak akuntansi). Perkiraan biaya ini bisa didapat dari vendor.
 Desain sistem. Biaya ini adalah biaya yang ditimbulkan oleh para praktisi yang
melakukan fungsi perencanaan, analisis, dan desain. Secara teknis biaya ini terjadi
hingga pada tahap ini adalah biaya yang “tenggelam” dan tidak relevan untuk
pengambilan keputusan. Analis seharusnya hanya memperkirakan biaya yang
dibutuhkan untuk menyelesaikan desain terperinci.
 Pemrograman dan pengujian. Biaya pemrograman didasarkan pada perkiraan jam
tenaga kerja yang dibutuhkan untuk menulis program baru terkait dan memodifikasi
berbagai program yang ada untuk sistem yang diusulkan. Biaya pengujian sistem
melibatkan penyatuan semua modul program terpisah untuk diuji sebagai satu kesatuan
sistem. Aktivitas ini haruslah merupakan percobaan yang menyeluruh jika ingin ada
artinya. Perencanaan, pengujian, dan analisis hasil dapat membutuhkan waktu berhari-
hari para profesional sistem, pengguna, dan pemegang kepentingan sistem lainnya.
Pengalaman perusahaan di masa lalu adalah dasar yang terbaik untuk memperkirakan
biaya ini.
 Konversi data. Biaya ini timbul akibat transfer data dari suatu media penyimpanan ke
media lainnya. Contohnya, catatan akuntansi dalam sistem manual harus dikonversi ke
dalam bentuk magnetis ketika sistem menjadi berbasis komputer. Aktivitas ini dapat
mewakili pekerjaan dalam jumlah yang banyak. Dasar untuk memperkirakan biaya
konversi adalah jumlah dan ukuran file yang harus dikonversi.
 Pelatihan. Biaya ini melibatkan proses mendidik para pengguna dalam mengoperasikan
sistem baru terkait. Personel internal dapat melakukan hal ini dalam suatu program
pelatihan ekstensif yang disediakan oleh sebuah perusahaan luar dari jarak jauh atau
melalui pelatihan praktik (on the job training). Biaya pelatihan formal dapat dengan
mudah didapatkan. Biaya program pelatihan internal meliputi waktu pengajaran,
fasilitas ruang kelas, dan produktivitas yang hilang. Biaya ini sering kali merupakan
biaya pertama yang dipotong untuk memenuhi anggaran, padahal tindakan semacam itu
dapat berakibat fatal untuk pengembangan sistem (contohnya, bencana implementasi
ERP di Hershey dinyatakan karena adanya kesalahan dalam pengurangan secara drastis
pelatihan karyawan sebelum "operasional penuh sistem").2 Akuntan dan auditor harus
menyadari bahaya memotong bagian penting dari pengembangan sistem ini.
 Biaya yang berulang dapat meliputi hal-hal berikut ini:
 Pemeliharaan peranti keras. Biaya ini melibatkan pembaruan komputer (peningkatan
memori), serta pemeliharaan untuk pencegahan dan serta perbaikan atas komputer dan
perlengkapan periferal. Perusahaan dapat menandatangani kontrak pemeliharaan
dengan vendor untuk meminimalkan biaya dan anggaran biaya ini. Perkiraan biaya ini
bisa didapat dari vendor dan kontrak yang telah ada.
 Pemeliharaan peranti lunak. Biaya ini meliputi pembaruan dan debug sistem operasi,
pembelian aplikasi, dan aplikasi yang dikembangkan secara internal. Kontrak
pemeliharaan dengan vendor peranti lunak dapat digunakan untuk menspesifikasikan
biaya ini dengan cukup akurat. Perkiraan pemeliharaan secara internal bisa diambil dari
data historis.
 Asuransi. Biaya ini meliputi berbagai bahaya dan bencana seperti kebakaran, kegagalan
peranti keras, perusakan, dan penghancuran oleh karyawan yang kecewa.
 Pasokan. Biaya ini timbul melalui konsumsi rutin berbagai barang seperti kertas, disket
magnetis, CD, dan perlengkapan kantor umum lainnya.
 Biaya personel. Biaya ini meliputi gaji berbagai orang yang merupakan bagian dari
sistem informasi. Beberapa biaya karyawan bersifat langsung dan dapat dengan mudah
didentifikasi, seperti gaji personel operasional, yang secara khusus dipekerjakan
sebagai bagian dari sistem yang dianalisis. Beberapa keterlibatan personel (seperti
administrator basis data dan personel ruang komputer) bersifat umum untuk beberapa
sistem sekaligus. Biaya personel semacam ini harus dialokasikan berdasarkan perkiraan
keterlibatan seluruhnya dalam sistem terkait.

Mengidentifikasi Manfaat
Tahap berikutnya dalam analisis biaya-manfaat adalah untuk mengidentifikasi manfaat
sistem. Manfaat ini sifatnya dapat berwujud dan tidak berwujud. Tabel 4-2 mencantumkan
beberapa jenis manfaat yang berwujud.
Manfaat berwujud (tangible benefit) dapat dibagi ke dalam dua kategori: manfaat
yang meningkatkan pendapatan dan yang mengurangi pendapatan. Contohnya, asumsikan
bahwa sistem EDI yang diusulkan akan memungkinkan perusahaan mengurangi persediaan
dan pada waktu bersamaan meningkatkan layanan ke pelanggan melalui pengurangan
terjadinya kehabisan persediaan. Pengurangan persediaan adalah manfaat dari segi
pengurangan biaya. Sistem yang diusulkan tersebut akan menggunakan lebih sedikit sumber
daya (persediaan daripada sistem yang sekarang. Nilai dari manfaat ini adalah jumlah uang
biaya penggudangan yang dihemat dari pengurangan per tahun persediaan. Perkiraan
kenaikan penjualan akan disebabkan oleh adanya layanan pelanggan yang lebih baik dan
merupakan manfaat yang meningkatkan pendapatan.
 Ketika mengukur penghematan biaya, penting untuk hanya memasukkan biaya yang
dapat dihindari dalam analisis. Biaya yang dapat dihindari secara langsung berhubungan
dengan sistem, dan biaya ini tidak akan timbul lagi ketika sistem juga tidak lagi digunakan.
Beberapa biaya yang tampaknya dapat dihindari oleh pengguna bisa saja tidak benar-benar
dapat dihindari dan, jika dimasukkan, dapat mengarah pada kesalahan analisis. Contohnya,
pusat pemrosesan data sering kali "membebankan kembali" biaya operasionalnya ke para
penggunanya melalui alokasi biaya. Tarif pembebanan kembali yang digunakan untuk hal ini
meliputi biaya tetap (yang dialokasikan ke pengguna) dan biaya langsung yang ditimbulkan
dari aktivitas tiap pengguna. Figur 4-6 menggambarkan teknik ini.

Asumsikan bahwa pihak manajemen dalam Area Pengguna B mengusulkan untuk

mengadakan sistem komputer dan melakukan pemrosesan datanya sendirı secara lokal. Salah
satu manraat dar proposal ini adalah penghematanbiaya yang berasal dari penghindaran
adanya pembebanan kembalı dari pusataemrosesan data. Walaupun pengguna dapat
menganggap pembebanan tersebutadalah sebesar $400.000 per tahun, hanya bagian biaya
langsungnya sajaisebesar $50.000) yang dapat dihindari oleh perusahaan secara keseluruhan.
Walaupun proposal tersebut disetujui, sisa biaya yang dibebankan kembali, yaitu $350.000
tidak hilang. Para pengguna lainnya dalam sistem yang lamakini harus menanggung biaya ini.
Tabel 4-3 mencantumkan beberapa kategori umum manfaat yang tidak berwujud
(intangible benefit). Walaupun manfaat yang tidak berwujud sering kali lebih penting
daripada peran penting keputusan sistem informasi itu sendiri, manfaat ini tidak dapat dengan
mudah diukur dan dikuantifkasi.

Contohnya, asumsikan bahwa sebuah sistem point-of-sale yang diusulkan untuk sebuah
supermarket akan mengurangi rata-rata waktu proses transaksi penjualan pelanggan dari 11
menit menjadi 3 menit. Waktu yang dihemat dapat dikuantifikasikan dan menghasilkan
manfaat berwujud dalam bentuk penghematan biaya operasional. Manfaat yang tidak
berwujud adalah peningkatan kepuasan pelanggan; tidak ada yang suka mengantre lama
untuk membayar belanjaan. Akan tetapi, berapakah nilai sesungguhnya dari manfaat tidak
berwujud ini bagi perusahaan? Peningkatan kepuasan pelanggan dapat di artikan menjadi
peningkatan penjualan. Beberapa pelanggan akan membeli di toko tersebut-dan mungkin
akan bersedia untuk membayar sedikit lebih mahal untuk menghindari antrean pembayaran
yang panjang. Akan tetapi, bagaimana mengukur kondisi ini? Memberikan nilai sering kali
merupakan hal yang sangat subjektif.
Para profesional Sistem mempertimbangkan banyak sumber dalam usaha mereka untuk
mengukur manfaat tidak berwujud dan mengolahnya ke dalam bentuk finansial. Beberapa
teknik yang umum digunakan meliputi survei pendapat pelanggan (dan karyawan), analisis
statistik, perkiraan teknik penilaian, dan model simulasi. Walaupun profesional sistem
berhasil mengukur beberapa manfaat yang tidak berwujud, mereka sering kali harus puas
dengan hanya menyatakan manfaat sebatas penilaian terbaik yang dapat mereka lakukan saja.
Karena sulit untuk melakukan pengukuran yang pasti, manfaat tidak berwujud kadang
dieksploitasi untuk tujuan politis, Dengan melebih-lebihkan atau merendahkan manfaat
sejenis ini, Sistem dapat diusulkan secara paksa oleh pendukungnya atau dihentikan oleh
penentangnya.
Membandingkan Biaya dan Manfaat
Tahap terakhir dalam analisis biaya manfaat adalah membandingkan biaya dan manfaat
yang ditemukan pada dua tahap pertama. Dua metode yang paling banyak digunakan untuk
mengevaluasi sistem informasi adalah nilai sekarang bersih dan pembayaran kembali.
Dalam metode nilai sekarang bersih (net present value method), nilai sekarang biaya
dideduksi dari nilai sekarang manfaat selama masa hidup sistem terkait. Berbagai proyek
dengan nilai sekarang bersih yang positif secara ekonomi layak. Ketika membandingkan
berbagai alternatif proyek, pilihan yang optimal adalah proyek dengan nilai sekarang bersih
yang terbesar. Tabel 4-4 menggambarkan metode nilai sekarang bersih dengan
membandingkan dua alternatif desain.

Contoh yang disajikan didasarkan pada berikut ini :

Desain A Desain B
Waktu penyelesaian proyek 1 tahun 1 tahun
Perkiraan umur hidup sistem 5 tahun 5 tahun
Biaya yang timbul sekali (dalam ribuan) $300 $140
Biaya yang berulang (dalam ribuan)
Timbul di awal Tahun 1 hingga 5 $45 $55
Manfaat berwujud tahunan (dalam ribuan)
Timbul dari tahun 1 hingga 5 $170 $135

Jika hanya biaya dan mantaat berwujud yang dipertimbangkan, maka Desain A akan
lebih baik daripada Desain B. Akan tetapi, nilai manfaat tidak berwujud, bersama dengan
nilai kelayakan desain lainnya, juga harus dipertimbangkan ke dalam analisis akhir.
 Metode pembayaran kembali (payback method) adalah variasi analisis titik impas.
Titik impas (break-even point) dicapai ketika biaya total sama dengan manfaat total. Figur 4-
7 (A) dan (B) menggambarkan pendekatan ini menggunakan data dari contoh sebelumnya.
Kurva biaya total terdiri atas biaya yang timbul sekali ditambah nilai sekarang biaya
berulang selama masa hidup proyek. Perpotongan garis ini mewakili jumlah tahun di masa
mendatang untuk sampai ke titik impas, atau sampai sistem dapat membayar dirinya sendiri.
Area yang diberi bayang-bayang antara kurva manfaat dengan kurva biaya total mewakili
nilai sekarang laba di masa mendatang yang didapat oleh sistem terkait.
 Dalam memilih suatu sistem informasi, kecepatan pembayaran kembali sering kali
merupakan faktor yang mutlak. Dengan siklus hidup produk yang singkat dan perkembangan
teknologi yang sangat cepat, masa hidup sistem intormasi cenderung singkat. Dengan kriteria
ini, Desain B, dengan periode pembayaran kembali selama empat tahun, akan lebih baik
daripada Desain nya periode pembayaran kembali sering kali lebih penting daripada berbagai
pertimbangan lainnya yang disajikan oleh manfaat tidak berwujud.

Membuat Laporan Pemilihan Sistem

Hasil dari pemilihan sistem adalah laporan pemilihan sistem (system selection report).
Dokumen formal ini terdiri atas sebuah studi kelayakan yang direvisi, analisis biaya-manfaat,
dan daftar serta penjelasan berbagai manfaat tidak berwujud untuk setiap alternative desain.
Berdasarkan laporan ini, komite pengarah akan memilih sebuah sistem yang akan dilanjutkan
ke tahap SDLC berikutnya – desain terperinci.

Peran Auditor dalam Evaluasi dan Pemilihan

Perhatian utama auditor adalah kelayakan ekonommi yang diusulkan telah diukur
seakurat mungkin atau tidak. Secara khusus, auditor harus memastikan lima hal :
1. Hanya biaya yang dapat dihindari yang digunakan dalam perhitungan manfaat dan
penghematan biaya
2. Penggunaan tingkat bunga yang wajar dalam mengukur nilai sekarang arus kas
3. Biaya yang timbul sekali dan biaya berulang dilaporkan secara lengkap dan akurat
4. Adanya penggunaan umur hidup yang realistis dalam membandingkan berbagai
alternatif proyek
5. Manfaat tidak berwujud diberikan nilai financial yang wajar
Berbagai kesalahan, penghilangan, dan salah saji dalam akuntansi hal-hal semacam itu
dapat mendistorsi analisis dan dapat mengakibatkan keputusan yang salah secara material.