Mengelola Sistem: Siklus Hidup Pengembangan

13
Diterjemahkan dari bahasa Inggris ke bahasa Indonesia - www.onlinedoctranslator.com
bab
Mengelola Sistem
Siklus Hidup Pengembangan*
A
responsif, sistem informasi yang berorientasi pada pengguna
adalah aset berharga dari organisasi bisnis modern. Sistem
yang dirancang dengan baik dapat meningkatkan bisnis
kinerja dengan mengurangi inventaris, menghilangkan aktivitas yang
tidak bernilai tambah, meningkatkan layanan pelanggan, dan
mengoordinasikan aktivitas rantai pasokan.
Bab ini mengkaji beberapa topik yang berkaitan dengan
proses dimana organisasi memperoleh sistem informasi. Ini
-
dimulai dengan ikhtisar tentangsiklus hidup pengembangan - Tujuan pembelajaran
sistem (SDLC). Proses multitahap ini memandu manajemen
organisasi melalui pengembangan dan/atau pembelian sistem Setelah mempelajari bab ini, Anda harus:
informasi. Selanjutnya, bab ini menyajikan isu-isu utama yang - Mampu mengidentifikasi tahapan kunci
berkaitan dengan pengembangan strategi sistem, termasuk dalam SDLC.
hubungannya dengan rencana bisnis strategis, situasi warisan
- Kenali bagaimana strategi bisnis
saat ini, dan umpan balik dari komunitas pengguna. Bab ini
perusahaan akan membentuk sistem
memberikan metodologi untuk menilai kelayakan proyek yang
informasinya.
diusulkan dan untuk memilih masing-masing proyek untuk
maju dalam konstruksi dan pengiriman ke penggunanya. Bab - Memahami hubungan antara
ini diakhiri dengan meninjau peran akuntan dalam mengelola perencanaan sistem strategis dan
SDLC. sistem warisan.
- Memahami apa yang terjadi selama
analisis sistem.
- Memahami model TELOS untuk
menilai kelayakan proyek.
- Akrab dengan masalah analisis biaya-
manfaat yang terkait dengan proyek
sistem informasi.
- Memahami peran akuntan

dalam SDLC.
* Bab ini ditulis bersama oleh Jiri Polak, PhD, Deloitte & Touche, dan
Vojtech Merunka, PhD, Deloitte & Touche.
574 PARTIV Kegiatan Pengembangan Sistem
Siklus Hidup Pengembangan Sistem

Perusahaan sedang dan besar dengan kebutuhan informasi yang unik sering kali mengembangkan sistem
informasi sendiri. Artinya, para profesional teknologi informasi (TI) dalam desain perusahaan dan memprogram
sistem. Sejumlah besar perusahaan kecil dan perusahaan besar dengan kebutuhan informasi yang relatif
standar memilih untuk membeli sistem informasi dari vendor perangkat lunak. Kedua pendekatan tersebut
mewakili risiko keuangan dan operasional yang signifikan. SDLC yang ditunjukkan pada Gambar 13-1 adalah
model untuk mengurangi risiko ini melalui perencanaan, pelaksanaan, pengendalian, dan dokumentasi
kegiatan utama yang cermat. Lima fase model ini diuraikan dalam paragraf berikut. Strategi sistem dan inisiasi
proyek dibahas dalam bab ini. Fase yang tersisa adalah topik Bab 14.
ANGKA
13-1 SYSTEMSDPERKEMBANGANLJIKACYCLE
Kebutuhan Bisnis
dan Strategi
Bisnis
Persyaratan
Warisan
Situasi
1. Strategi Sistem
– Menilai Strategis
Kebutuhan Informasi
– Mengembangkan Rencana Masukan:
Antarmuka Sistem, Sistem Strategis Permintaan Pengguna
Arsitektur dan – Buat Rencana Aksi untuk Sistem Baru
Persyaratan Pengguna
Proposal Prioritas Tinggi
Menjalani Studi dan
Pengembangan Tambahan
2. Inisiasi Proyek
– Analisis Sistem
– Konseptualisasi dari
Desain Alternatif Masukan:
– Evaluasi Sistem Permintaan Pengguna untuk
dan Seleksi Perbaikan Sistem
dan dukungan
Sistem yang Dipilih
Proposal Maju
untuk Desain Detail
3. Sistem In-House 4. Paket Komersial

Perkembangan – Tren Paket Komersial
– Membangun Sistem
– Menyampaikan Sistem – Memilih Paket
Baru dan Revisi

Sistem Masuk ke
Produksi
5. Pemeliharaan dan Dukungan

BAB 1 3 Mengelola Siklus Hidup Pengembangan Sistem 575
STRATEGI SISTEM.Langkah pertama dalam SDLC adalah mengembangkan strategi sistem, yang memerlukan
pemahaman kebutuhan bisnis strategis organisasi. Ini mungkin berasal dari pernyataan misi organisasi, analisis
tekanan kompetitif pada perusahaan, dan sifat kondisi pasar saat ini dan yang diantisipasi. Kebutuhan ini
mencerminkan posisi organisasi saat ini relatif terhadap kebutuhan jangka panjang untuk mempertahankan
keunggulan strategis. Selain itu, manajemen proyek harus mempertimbangkan implikasi sistem informasi yang
berkaitan dengan sistem lama dan masalah yang didaftarkan melalui umpan balik pengguna. Sebuah rencana
strategis untuk memenuhi kebutuhan yang beragam dan kompleks ini, bersama dengan jadwal pelaksanaan
sistem terpilih, dihasilkan.
INISIASI PROYEK.Inisiasi proyek adalah proses di mana proposal sistem dinilai konsistensinya
dengan rencana sistem strategis dan dievaluasi dalam hal kelayakan dan karakteristik biaya-
manfaatnya. Desain konseptual alternatif dipertimbangkan, dan yang terpilih memasuki fase
konstruksi SDLC. Bergantung pada sifat proyek dan kebutuhan organisasi, proposal akan
memerlukan pengembangan internal, paket komersial, atau keduanya.
PENGEMBANGAN DALAM RUMAH.Seperti disebutkan sebelumnya, beberapa organisasi memiliki kebutuhan informasi unik
yang hanya dapat dipenuhi secara memadai melalui pengembangan internal. Langkah pengembangan in-house termasuk
menganalisis kebutuhan pengguna, merancang proses dan basis data, membuat tampilan pengguna, memprogram aplikasi,
dan menguji serta mengimplementasikan sistem yang telah selesai.
PAKET KOMERSIAL.Ketika sifat proyek dan kebutuhan pengguna mengizinkan, sebagian besar organisasi akan mencari paket
perangkat lunak komersial yang telah dikodekan sebelumnya daripada mengembangkan sistem baru dari awal. Organisasi
yang dapat menerapkan perangkat lunak komersial memperoleh sejumlah keuntungan. Ini termasuk biaya awal yang lebih
rendah, waktu implementasi yang lebih singkat, kontrol yang lebih baik, dan pengujian vendor yang ketat. Semua manfaat ini
diterjemahkan menjadi penghematan biaya bagi pengguna. Namun, proses ini bukan tanpa risiko. Prosedur formal perlu diikuti
untuk memastikan bahwa pengguna mendapatkan paket yang memenuhi kebutuhannya secara memadai dan kompatibel
dengan sistem yang ada.
PEMELIHARAAN DAN DUKUNGAN.Pemeliharaan melibatkan perolehan dan penerapan versi perangkat lunak
terbaru dari paket komersial dan membuat modifikasi internal pada sistem yang ada untuk mengakomodasi
perubahan kebutuhan pengguna. Pemeliharaan mungkin relatif sepele, seperti memodifikasi aplikasi untuk
menghasilkan laporan baru, atau lebih ekstensif, seperti memprogram fungsionalitas baru ke dalam sistem.
Putaran umpan balik dari pemeliharaan ke inisiasi proyek dan langkah-langkah strategi sistem, terlepas dari
hubungan ini.
Secara tradisional, pemeliharaan sistem dipandang sebagai tahap SDLC yang terpisah dan berbeda yang dapat berlangsung
selama 5 hingga 10 tahun. Bisnis modern dalam industri yang sangat kompetitif, bagaimanapun, sering melihat perubahan
dalam teknologi dan masa hidup sistem yang jauh lebih pendek. Memang, ini menjadi norma bagi banyak organisasi. Banyak
sistem kompleks saat ini dikembangkan dan diimplementasikan menggunakan pendekatan inkremental yang
mengintegrasikan pemeliharaan dan pengembangan baru. Pemeliharaan sistem sering dipandang sebagai fase pertama dari
siklus pengembangan baru. Aplikasi yang ada (dipelihara) adalah prototipe untuk versi barunya. Jadi, alih-alih
mengimplementasikan aplikasi dalam satu rilis besar, sistem modern dikirimkan dalam beberapa bagian secara terus-menerus
dan cepat sebagai rilis yang lebih kecil yang dapat mencerminkan perubahan kebutuhan bisnis secara lebih akurat. Aspek lain
dari pemeliharaan modern termasuk membangun infrastruktur pendukung pengguna. Ini dapat mencakup layanan helpdesk,
memberikan pelatihan pengguna dan kelas pendidikan, dan mendokumentasikan umpan balik pengguna yang berkaitan
dengan masalah dan kesalahan sistem.
PESERTA DALAM PENGEMBANGAN SISTEM

Peserta dalam pengembangan sistem dapat diklasifikasikan menjadi tiga kelompok besar: profesional sistem, pengguna akhir,
dan pemangku kepentingan.
Profesional sistemadalah analis sistem, perancang sistem, dan pemrogram. Orang-orang ini benar-benar membangun
sistem. Mereka mengumpulkan fakta tentang masalah dengan sistem saat ini, menganalisis fakta tersebut, dan merumuskan
solusi untuk memecahkan masalah tersebut. Produk dari upaya mereka adalah sistem baru.
Pengguna akhiradalah mereka untuk siapa sistem dibangun. Banyak pengguna ada di semua tingkatan dalam suatu
organisasi. Ini termasuk manajer, personel operasi, akuntan, dan auditor internal. Di beberapa organisasi, sulit menemukan
seseorang yang bukan pengguna. Selama pengembangan sistem, profesional sistem bekerja dengan pengguna utama untuk
mendapatkan pemahaman tentang masalah pengguna dan pernyataan yang jelas tentang kebutuhan mereka.
Sebagaimana didefinisikan dalam Bab 1,pemangku kepentinganadalah individu baik di dalam maupun di luar organisasi
yang memiliki kepentingan dalam sistem tetapi bukan pengguna akhir. Ini termasuk akuntan, auditor internal, auditor
eksternal, dan komite pengarah internal yang mengawasi pengembangan sistem.1
Strategi Sistem
Tujuan daristrategi sistemadalah untuk menghubungkan proyek sistem individu dengan tujuan strategis
perusahaan. Perusahaan yang menganggap serius strategi sistem membentuk komite pengarah untuk
memberikan panduan dan pengawasan untuk proyek sistem. Komposisi daripanitia acaramungkin termasuk
chief executive officer (CEO), chief financial officer, chief information officer, manajemen senior dari area
pengguna, auditor internal, dan manajemen senior dari layanan komputer. Pihak eksternal, seperti konsultan
manajemen dan auditor eksternal perusahaan, juga dapat melengkapi komite tersebut. Komite ini terlibat tidak
hanya dalam mengembangkan strategi sistem tetapi juga dalam setiap fase utama SDLC.
Tahap strategi dalam SDLC terdiri dari tiga tugas mendasar: menilai kebutuhan informasi strategis organisasi,
mengembangkan rencana sistem strategis, dan membuat rencana tindakan. Masukan untuk fase strategi sistem
adalah rencana bisnis, situasi sistem lama, dan umpan balik dari komunitas pengguna. Pada bagian ini kita melihat
bagaimana potongan-potongan ini bersatu untuk membentuk rencana strategis yang komprehensif yang akan
menghasilkan rencana tindakan untuk memilih dan mengembangkan proyek sistem individual.
Menilai Kebutuhan Informasi Strategis

Perencanaan sistem strategis melibatkan alokasi sumber daya sistem pada tingkat makro, yang biasanya berhubungan
dengan kerangka waktu 3 sampai 5 tahun. Proses ini sangat mirip dengan penganggaran sumber daya untuk kegiatan
strategis lainnya, seperti pengembangan produk, perluasan pabrik, riset pasar, dan teknologi manufaktur. Bagi
sebagian besar perusahaan, masukan utama dalam mengembangkan strategi sistem yang baik mencakup kebutuhan
bisnis strategis organisasi, situasi sistem lama, dan umpan balik pengguna.
KEBUTUHAN BISNIS STRATEGIS

Semua area fungsional harus mendukung strategi bisnis organisasi. Karena ini benar untuk fungsi sistem
informasi, kita mulai dengan ikhtisar strategi bisnis. Kami akan meninjau secara singkat beberapa aspek umum
dari strategi bisnis yang berhubungan langsung dengan pengembangan strategi sistem yang baik.
Visi dan Misi

Mengembangkan strategi sistem memerlukan pemahaman tentang visi manajemen puncak, yang telah membentuk strategi
bisnis organisasi. Banyak CEO mengkomunikasikan visi strategis mereka melalui pernyataan misi formal. Namun, dalam
beberapa kasus, pandangan strategis manajemen puncak untuk perusahaan tidak sepenuhnya diartikulasikan atau
dirumuskan. Organisasi tanpa pernyataan misi yang dipertimbangkan dengan baik mungkin memiliki individu yang tidak
memiliki visi yang jelas untuk masa depan yang mengelola dan mengarahkan mereka. Tidak mengherankan, perusahaan dalam
situasi ini sering kekurangan strategi sistem yang layak. Konsekuensinya, manajemen mereka cenderung membuat respons
spontan terhadap kebutuhan sistem informasi yang muncul dari krisis daripada perencanaan.
Analisis Industri dan Kompetensi

Selain membutuhkan komponen visi yang tahan lama, proses perencanaan strategis memiliki banyak faktor bisnis dinamis yang
mendorongnya, antara lain konsolidasi, persaingan, teknologi yang berkembang pesat, perubahan lanskap regulasi, dan
tuntutan yang meningkat dari pemangku kepentingan. Analisis industri dan analisis kompetensi adalah dua metodologi
perencanaan strategis yang digunakan untuk menangkap informasi tentang faktor-faktor ini.
1 Akuntan dan auditor adalah pengguna akhir dari beberapa sistem, tetapi merupakan pemangku kepentingan di semua sistem informasi akuntansi.
Analisis industrimenyediakan manajemen dengan analisis kekuatan pendorong yang mempengaruhi

industri dan kinerja organisasinya. Analisis tersebut menawarkan perspektif berbasis fakta tentang tren penting
industri, risiko signifikan, dan peluang potensial yang dapat memengaruhi kinerja bisnis.
Analisis Kompetensimemberikan gambaran lengkap tentang efektivitas organisasi seperti yang terlihat melalui
empat filter strategis: sumber daya, infrastruktur, produk/layanan, dan pelanggan. Dengan menilai faktor-faktor ini,
sebuah organisasi dapat mengembangkan pandangan yang akurat tentang kekuatan, kelemahan, dan kompetensi inti
relatifnya. Analisis membantu dalam mengembangkan pilihan strategis, yang didasarkan pada pemahaman tentang
lingkungan masa depan dan kompetensi inti perusahaan. Peluang strategis dapat mencakup opsi memasuki pasar
atau opsi pengembangan produk baru.
Dalam mengembangkan strategi bisnis banyak organisasi melakukan analisis kompetensi pada pesaing
utama mereka serta mitra bisnis potensial. Dengan mengetahui kekuatan dan kelemahan pesaing, manajemen
dapat mengidentifikasi ancaman yang akan terjadi dan melihat peluang bisnis baru untuk pertumbuhan.
Demikian pula, dengan memeriksa kompetensi calon mitra dagang, kesenjangan strategis dan/atau sinergi dari
kemitraan dapat terwujud.
SISTEM WARISAN
Aplikasi, database, dan proses bisnis yang saat ini beroperasi penuh merupakan warisan sistem perusahaan.
Seringkali, ini adalah sistem yang rumit untuk dipelihara dan ditingkatkan. Bahkan di perusahaan modern,
sistem informasi biasanya merupakan campuran dari teknologi lama dan modern, yang sangat penting bagi
kesuksesan bisnis organisasi.
Komponen warisan perlu dipetakan ke proses bisnis saat ini untuk menentukan sejauh mana mereka mendukung
misi perusahaan. Evaluasi ini, bersama dengan penilaian kebutuhan bisnis strategis di masa mendatang, akan
memungkinkan manajemen untuk mengembangkan strategi migrasi yang diperlukan untuk beralih dari sistem lama
ke sistem masa depan dengan gangguan minimum terhadap operasi bisnis.
Mengembangkan Deskripsi Arsitektur

Arsitektur sistem adalah struktur komponen, keterkaitannya, dan prinsip serta pedoman yang mengatur desain
dan evolusinya dari waktu ke waktu. Sebuahdeskripsi arsitekturadalah deskripsi formal dari sistem informasi,
diorganisasikan sedemikian rupa sehingga mengidentifikasi sifat struktural dari sistem dan mendefinisikan
komponen atau blok bangunan yang membentuk sistem informasi secara keseluruhan. Uraian ini menyediakan
unsur-unsur rencana dari mana sistem baru dapat dikembangkan dan paket komersial yang diperoleh akan
bekerja sama sebagai komponen yang harmonis dari keseluruhan sistem. Ini juga memberikan landasan teknis
untuk strategi migrasi lama. Akhirnya, keuntungan teknis yang dihasilkan dari deskripsi arsitektur
diterjemahkan menjadi manfaat bisnis yang penting, yang disajikan pada Tabel 13-1.
UMPAN BALIK PENGGUNA

Menilai umpan balik pengguna melibatkan identifikasi bidang kebutuhan pengguna, menyiapkan proposal tertulis,
mengevaluasi kelayakan dan kontribusi setiap proposal terhadap rencana bisnis, dan memprioritaskan proyek individu. Umpan
balik pengguna pada titik ini berkaitan dengan masalah substansial yang dirasakan daripada modifikasi sistem kecil, yang
ditangani pada titik selanjutnya di SDLC. Selanjutnya, kami memeriksa fase kunci berikut dari kegiatan ini.
1. Mengenali masalah.
2. Mendefinisikan masalah.
3. Menentukan tujuan sistem.
4. Menentukan kelayakan proyek.
5. Mempersiapkan proposal proyek formal.
Mengenali Masalah
Kebutuhan akan sistem informasi baru yang lebih baik dapat diwujudkan melalui berbagai gejala. Pada tahap awal
suatu masalah, gejala-gejala ini mungkin tampak samar dan tidak berbahaya atau mungkin tidak dikenali.
MEJA
13-1 BKEGUNAANBKEUNTUNGAN DARIARsitekturDESKRIPSI
Operasi TI yang efisien
- Biaya pengembangan, dukungan, dan pemeliharaan perangkat lunak yang lebih rendah.
- Peningkatan portabilitas aplikasi.
- Peningkatan interoperabilitas dan manajemen sistem dan jaringan yang lebih mudah.
Kemampuan untuk mengatasi masalah kritis di seluruh perusahaan
- Peningkatan dan pertukaran komponen sistem yang lebih mudah.
- Pengembalian yang lebih baik atas investasi yang ada dan pengurangan risiko untuk investasi masa depan.
- Mengurangi kompleksitas dalam infrastruktur TI.
- Pengembalian investasi maksimum dalam infrastruktur TI yang ada.
- Fleksibilitas untuk membuat, membeli, atau mengalihdayakan solusi TI.
- Mengurangi risiko secara keseluruhan dalam investasi baru dan biaya kepemilikan TI.
Pengadaan yang lebih baik
- Keputusan pembelian lebih sederhana karena informasi yang mengatur pengadaan sudah tersedia dalam rencana yang koheren.
- Proses pengadaan lebih cepat, memaksimalkan kecepatan dan fleksibilitas pengadaan tanpa mengorbankan koherensi
arsitektural.
Namun, karena sumber yang mendasari masalah semakin parah, begitu pula gejalanya, sampai
gejalanya terlihat mengkhawatirkan. Pada titik ini, operasi mungkin telah mencapai keadaan krisis. Oleh
karena itu, titik di mana masalah dikenali adalah penting. Ini seringkali merupakan fungsi dari filosofi
manajemen perusahaan. Filosofi manajemen reaktif mencirikan posisi ekstrim; berbeda dengan ini
adalah filosofi manajemen proaktif.
Manajemen reaktifmenanggapi masalah hanya ketika mereka mencapai keadaan krisis dan tidak dapat lagi diabaikan.
Pendekatan ini menciptakan banyak tekanan untuk menyelesaikan masalah dengan cepat setelah diketahui. Terlalu sering, ini
menghasilkan analisis yang tergesa-gesa, identifikasi masalah yang tidak lengkap, jalan pintas dalam desain, partisipasi
pengguna yang buruk, dan produk akhir dari solusi yang umumnya kurang optimal.
Manajemen proaktiftetap waspada terhadap tanda-tanda halus dari masalah dan secara agresif mencari cara untuk
meningkatkan sistem organisasi. Gaya manajemen ini lebih cenderung mengenali gejala lebih awal dan, oleh karena
itu, menerapkan solusi yang lebih baik. Deteksi masalah dini menghindari tahap krisis dan menyediakan waktu yang
diperlukan untuk studi yang lengkap dan menyeluruh.
Siapa yang melaporkan gejala masalah? Biasanya, manajer tingkat bawah dan personel operasi pertama kali
melaporkan gejala. Berada dalam kontak terus menerus dengan operasi sehari-hari, orang-orang ini dengan cepat
menyadari kesulitan operasional dengan pelanggan, pemasok, dan komunitas keuangan. Akibatnya, sebagian besar
permintaan sistem berasal dari manajemen tingkat rendah.
Mendefinisikan Masalah
Manajer harus menghindari godaan untuk melakukan lompatan logika dari pengenalan gejala ke definisi
masalah. Seseorang harus tetap berpikiran terbuka dan menghindari menarik kesimpulan tentang sifat
masalah yang dapat mengarahkan perhatian dan sumber daya ke arah yang salah. Misalnya, peningkatan
pengembalian produk, penundaan pengiriman produk yang berlebihan ke pelanggan, lembur yang berlebihan
untuk personel operasi, dan tingkat perputaran persediaan yang lambat adalah semua gejala masalah. Ini
adalah bukti dari masalah yang mendasarinya, tetapi mereka tidak dengan sendirinya mendefinisikan masalah.
Manajer harus cukup belajar tentang masalah untuk mencari solusi secara cerdas. Namun, manajer tidak dapat
mengumpulkan semua informasi yang diperlukan untuk mendefinisikan masalah secara akurat dan
menentukan solusi. Ini akan membutuhkan evaluasi sistem yang terperinci.
Manajer melaporkan definisi masalah ini kepada profesional sistem komputer di dalam perusahaan.
Ini memulai proses interaktif antara profesional sistem dan pengguna, yang menghasilkan a
proposal proyek formal yang akan diajukan ke komite pengarah untuk persetujuan. Tiga tahap berikut
dalam fase perencanaan — menentukan tujuan sistem, menentukan kelayakan proyek, dan menyiapkan
proposal proyek formal — mewakili upaya kerja sama dari manajer dan profesional sistem.
Menentukan Tujuan Sistem

Persyaratan informasi pengguna perlu ditentukan dalam hal tujuan operasional untuk sistem informasi baru. Misalnya,
pengguna mungkin memerlukan sistem entri pesanan yang dapat menangani 5.000 transaksi per jam,
mempertahankan status inventaris terkini, dan memungkinkan semua pesanan yang diterima pada pukul 2 siang
dikirim ke pelanggan pada akhir hari. . Pada titik ini, kita hanya perlu mendefinisikan tujuan secara umum. Persyaratan
sistem yang lebih tepat akan dikembangkan nanti di SDLC.
Kelayakan Proyek Pendahuluan

Sebuah pendahuluankelayakan proyekstudi dilakukan pada tahap awal ini untuk menentukan cara terbaik
untuk melanjutkan proyek. Dengan menilai kendala utama pada sistem yang diusulkan, manajemen dapat
mengevaluasi kelayakan proyek, atau kemungkinan untuk sukses, sebelum melakukan sejumlah besar sumber
daya keuangan dan manusia. AkronimTELOSmemberikan panduan untuk menilai kelayakan proyek. Istilah ini
berarti kelayakan teknis, ekonomi, hukum, operasional, dan jadwal.
Kelayakan teknisberkaitan dengan apakah sistem dapat dikembangkan di bawah teknologi yang ada atau jika teknologi
baru diperlukan. Sebagai proposisi umum, teknologi di pasar jauh di depan kemampuan sebagian besar perusahaan untuk
menerapkannya. Oleh karena itu, dari sudut pandang ketersediaan, kelayakan teknis biasanya tidak menjadi masalah. Bagi
sebagian besar perusahaan, masalah sebenarnya adalah keinginan dan kemampuan mereka untuk menerapkan teknologi yang
tersedia. Mengingat bahwa teknologi adalah dasar fisik untuk sebagian besar fitur desain sistem, aspek ini sangat bergantung
pada kelayakan keseluruhan dari sistem yang diusulkan.
Kelayakan ekonomiberkaitan dengan ketersediaan dana untuk menyelesaikan proyek. Pada titik ini, kami prihatin
dengan komitmen finansial manajemen untuk proyek ini mengingat proyek modal lain yang bersaing dalam
pertimbangan. Tingkat dukungan ekonomi yang tersedia berdampak langsung pada sifat operasional dan ruang
lingkup sistem yang diusulkan. Kemudian, pada langkah pembenaran dan pemilihan sistem, analisis biaya-manfaat
digunakan untuk mengidentifikasi desain sistem terbaik untuk biaya.
Kelayakan hukummelibatkan memastikan bahwa sistem yang diusulkan tidak bertentangan dengan kemampuan
perusahaan untuk melaksanakan tanggung jawab hukumnya. Dalam bab-bab sebelumnya, kita telah mempelajari kebutuhan
untuk mematuhi persyaratan kontrol yang ditetapkan dalam Undang-Undang Praktik Korupsi Asing tahun 1977, Pernyataan
tentang Standar Audit No. 78, dan undang-undang Sarbanes-Oxley. Selain itu, banyak peraturan dan undang-undang
berurusan dengan pelanggaran privasi dan kerahasiaan informasi yang disimpan. Kita harus yakin bahwa sistem yang
diusulkan tidak melanggar batasan hukum apa pun.
Kelayakan operasionalberkaitan dengan tingkat kesesuaian antara prosedur perusahaan yang ada dan
keterampilan personel dengan persyaratan operasional sistem baru. Menerapkan sistem baru mungkin memerlukan
penerapan prosedur baru dan pelatihan ulang personel operasi. Pertanyaan yang harus dijawab adalah: dapatkah
cukup dilakukan perubahan prosedural, pelatihan ulang personel, dan keterampilan baru yang diperoleh untuk
membuat sistem layak secara operasional?
Kelayakan jadwalberkaitan dengan kemampuan perusahaan untuk melaksanakan proyek dalam waktu yang dapat
diterima. Faktor kelayakan ini memengaruhi ruang lingkup proyek dan apakah akan dikembangkan sendiri atau dibeli
dari vendor perangkat lunak. Jika proyek, seperti yang dibayangkan semula, tidak dapat diproduksi secara internal
pada tanggal target, maka desainnya, metode perolehannya, atau tanggal targetnya harus diubah.
Mempersiapkan Proposal Proyek Formal

Ituproposal proyek sistemmenyediakan manajemen dengan dasar untuk memutuskan apakah akan
melanjutkan proyek. Proposal formal melayani dua tujuan. Pertama, merangkum temuan studi yang dilakukan
sampai saat ini menjadi rekomendasi umum untuk sistem baru atau yang dimodifikasi. Hal ini memungkinkan
manajemen untuk mengevaluasi masalah yang dirasakan bersama dengan sistem yang diusulkan sebagai
solusi yang layak. Kedua, proposal menguraikan hubungan antara tujuan sistem yang diusulkan dan tujuan
bisnis perusahaan. Ini menunjukkan bahwa sistem baru yang diusulkan melengkapi arah strategis perusahaan.
Gambar 13-2 menunjukkan contoh proposal proyek.
GAMBAR
13-
Proposal proyek
Diminta oleh: JJ Johnson Tanggal: 13/11/09
Sifat Sistem yang Diminta:Sistem Kontrol Inventaris
Alasan untuk Sistem Baru:Kelola inventaris dengan lebih baik, kurangi keusangan,
meningkatkan perputaran, dan mengurangi biaya penyimpanan persediaan
Persyaratan Sumber Daya Sistem Baru:

Tinggi Sedang Rendah
Personil
Perangkat keras
Perangkat lunak
Nilai faktor kelayakan proyek pada skala 1 sampai 10 di mana 10 adalah yang paling layak:
Kelayakan Teknis 9
Kelayakan Ekonomi 8
Kelayakan Hukum 10
Jadwal Kelayakan Operasi 10
Kelayakan Jadwal 8
Prioritas Proyek: Tinggi Sedang Rendah
Mengembangkan Rencana Sistem Strategis

Setelah mengumpulkan dan mendokumentasikan masukan dari rencana bisnis, masalah warisan, dan umpan balik
pengguna, anggota panitia pengarah dan profesional sistem mengevaluasi pro dan kontra dari setiap proposal. Ini
melibatkan penilaian setiap manfaat proyek potensial, biaya, dan implikasi strategis bagi organisasi. Pengembangan
akan dilanjutkan pada proposal yang menunjukkan potensi terbesar untuk mendukung tujuan bisnis organisasi
dengan biaya terendah. Gambar 13-3 menunjukkan bagaimana manfaat dari proyek-proyek yang bersaing dapat
disajikan untuk memberikan gambaran tentang skala relatif. Dimensi vertikal menunjukkan prioritas proyek dalam hal
kebutuhan organisasi. Bidang horizontal menunjukkan biaya yang diharapkan dari setiap proyek, dan ukuran lingkaran
mencerminkan dampak strategis proyek. Misalnya, sistem perencanaan sumber daya perusahaan (ERP) adalah proyek
prioritas tinggi yang sangat penting secara strategis. Namun, proyek semacam itu akan sangat mahal. Di sisi lain,
proyek sumber daya manusia juga memiliki kepentingan strategis, tetapi dengan biaya yang jauh lebih rendah.
Buat Rencana Tindakan

Keterampilan penting untuk manajemen puncak adalah kemampuan untuk menerjemahkan strategi menjadi tindakan. Meskipun
sebagian besar perusahaan AS mengambil tindakan untuk mengurangi jarak antara mereka yang merumuskan strategi dan mereka yang
melaksanakannya, menerjemahkan visi ke dalam pekerjaan itu sulit. Namun, jika organisasi ingin sukses, mereka harus belajar
menerapkan strategi dan mengalahkan tingkat kegagalan tinggi yang sering dialami oleh rekan-rekan mereka.
Itukartu skor berimbang (BSC)adalah sistem manajemen yang memungkinkan organisasi untuk mengklarifikasi visi dan
strategi mereka dan menerjemahkannya ke dalam tindakan. Ini memberikan umpan balik baik dari bisnis internal
ANGKA
RELASIBDUA BELASPRIORITAS, COST,DANSTRATEGISSAYAMPACT
13-3
Manfaat
Manusia
Sumber daya
APAKAH ITU
Prioritas utama
Organisasi
Paket ERP
Prioritas sedang
DIA
Infrastruktur
Kargo
Olahraga
Prioritas rendah
Penumpang Perumahan
Olahraga
Estimasi biaya
proses dan hasil eksternal untuk terus meningkatkan kinerja strategis. Ketika digunakan sepenuhnya, balanced
scorecard mengubah perencanaan strategis dari latihan akademik menjadi tugas operasional.
Saat ini, BSC menikmati perhatian yang meningkat dan kemungkinan besar akan ada di mana-mana di kalangan
manajemen senior. Sebagian besar daya tarik BSC berasal dari kemampuannya untuk mengintegrasikan ukuran keuangan dan
operasional ke dalam satu kerangka kerja komprehensif yang dapat menerjemahkan tujuan strategis perusahaan ke dalam
seperangkat ukuran kinerja yang koheren.
Pendekatan BSC sangat cocok untuk salah satu tantangan mendasar yang dihadapi CEO dan
eksekutif TI, yaitu, bagaimana mengukur, meningkatkan, dan memahami nilai yang diberikan TI
kepada bisnis. BSC dapat membantu manajer mengidentifikasi peluang peningkatan TI dan
melacak dampak inisiatif peningkatan melalui berbagai indikator kinerja.
BSC menyarankan agar kita melihat organisasi dari empat perspektif. Kami mengembangkan metrik, mengumpulkan data,
dan menganalisisnya relatif terhadap masing-masing perspektif berikut:
1. Perspektif pembelajaran dan pertumbuhan.
2. Perspektif proses bisnis internal.

3. Perspektif pelanggan.
4. Perspektif keuangan.
PERSPEKTIF PEMBELAJARAN DAN PERTUMBUHAN

Pembelajaran dan pertumbuhan merupakan fondasi penting untuk keberhasilan organisasi mana pun. Perspektif ini mencakup
pelatihan karyawan dan sikap budaya perusahaan yang terkait dengan peningkatan diri individu dan perusahaan. Dalam iklim
perubahan teknologi yang cepat saat ini, para pekerja perlu berada dalam mode pembelajaran berkelanjutan. Instansi
pemerintah seringkali mendapati diri mereka tidak mampu mempekerjakan pekerja teknis baru dan pada saat yang sama
menunjukkan penurunan dalam melatih karyawan yang ada. Metrik dapat dikembangkan untuk memandu manajer dalam
menyalurkan dana pelatihan di tempat yang dapat memberikan manfaat terbesar.
PERSPEKTIF PROSES BISNIS INTERNAL

Metrik berdasarkan perspektif ini memungkinkan manajer mengetahui seberapa baik bisnis mereka berjalan
dan apakah produk dan layanannya sesuai dengan persyaratan pelanggan. Mereka yang paling mengetahui
proses ini perlu merancang metrik ini dengan hati-hati.
PERSPEKTIF PELANGGAN
Filosofi manajemen baru-baru ini telah menunjukkan peningkatan kesadaran akan pentingnya fokus pelanggan dalam
bisnis apa pun. Ini adalah indikator utama: jika pelanggan tidak puas, mereka akhirnya akan menemukan pemasok lain
yang akan memenuhi kebutuhan mereka. Kinerja yang buruk dari perspektif ini memprediksi penurunan di masa
mendatang, meskipun gambaran keuangan saat ini mungkin terlihat bagus. Perspektif pelanggan mencakup
pengukuran objektif seperti tingkat retensi pelanggan, serta kriteria yang lebih subjektif seperti riset pasar dan survei
kepuasan pelanggan.
PERSPEKTIF KEUANGAN
Perspektif keuangan mencakup pengukuran tradisional seperti profitabilitas, pendapatan, dan penjualan. Namun, penekanan
berlebihan pada kinerja keuangan dapat merangsang keputusan jangka pendek yang menciptakan ketidakseimbangan dengan
perspektif lain.
Kekuatan model BSC terletak pada keterkaitan antara empat perspektif pengukuran inti ini. Pertimbangkan,
misalnya, bisnis mengalami kinerja buruk dari perspektif keuangan, yang diukur dengan pertumbuhan penjualan yang
rendah, dan dari perspektif pelanggan, yang diukur dengan retensi dan kepuasan pelanggan yang rendah.
Menggunakan pendekatan BSC, manajemen dapat memeriksa langkah-langkah dari perspektif pembelajaran dan
inovasi dan dari perspektif proses internal untuk mengidentifikasi akar penyebab serta potensi solusi untuk masalah
tersebut. Dengan mengidentifikasi ketidakseimbangan yang ada pada area pengukuran tersebut, scorecard dapat
digunakan untuk mengambil tindakan korektif.
BALANCED SCORECARD DITERAPKAN PADA PROYEK TI

Gambar 13-4 mengilustrasikan BSC yang mengukur manfaat bisnis dari proposal perbankan online hipotetis.
Pelanggan ritel bank menghasilkan margin keuntungan yang rendah karena biaya overhead yang tinggi dan
ANGKA
13-4 BALANCEDSCORECARD UNTUKHAINLINEBANKINGSYSTEM
Pelanggan
Kepuasan pelanggan dengan
layanan nyaman
Keluhan per 1.000 transaksi
Intern Strategi: Sedang belajar
Saatnya memproses akun baru Untuk menurunkan biaya operasional Menerapkan Pelatihan teknologi
aplikasi dan meningkatkan profitabilitas baru untuk pelanggan online
Waktu yang dihabiskan untuk memproses ritel rekening bank ritel dengan mendukung
transaksi memindahkan pelanggan ke

Saatnya menyelesaikan masalah pelanggan perbankan elektronik
Keuangan
Akun ditangani per waktu penuh
karyawan
Profitabilitas per akun
biaya layanan untuk mengelola akun mereka. Perbankan elektronik dipandang sebagai cara untuk mengatasi masalah
ini. Jika sasaran strategis adalah untuk meningkatkan profitabilitas akun, indikator kinerja seperti jumlah akun yang
dikelola per karyawan penuh waktu dan biaya per transaksi adalah ukuran yang relevan. Hubungan dapat ditarik
antara langkah-langkah ini. Misalnya, jam yang dihabiskan staf pendukung pelatihan dapat berdampak pada
pengurangan keluhan pelanggan.
Melalui analisis indikator BSC, panitia pengarah dapat menetapkan prioritas untuk bersaing proposal
berdasarkan dampak strategisnya dilihat dari berbagai perspektif. Panitia akan menggunakan metrik ini untuk
mengidentifikasi proposal yang maju ke fase inisiasi proyek SDLC. Ini adalah titik keputusan besar pertama
dalam siklus hidup proyek. Jika panitia menyetujui proposal, maka proposal akan menjalani studi dan
pengembangan lebih lanjut. Jika proposal ditolak, maka tidak akan dipertimbangkan lebih lanjut dalam periode
anggaran saat ini.
Inisiasi Proyek
Inisiasi proyek melibatkan memperoleh pemahaman rinci tentang masalah pengguna dan mengusulkan
beberapa solusi alternatif. Masing-masing proposal ini dinilai dari segi kelayakan dan karakteristik biaya-
manfaatnya. Opsi yang dipilih pada langkah ini kemudian dilanjutkan ke tahap konstruksi SDLC.
Bergantung pada sifat proyek dan kebutuhan organisasi, sistem akan memerlukan pengembangan
internal, paket komersial, atau keduanya. Pendekatan ini diperiksa dalam Bab 14.
Analisis Sistem
Analis sistem harus sepenuhnya memahami masalah bisnis sebelum dia dapat merumuskan solusi. Analisis
yang tidak lengkap atau cacat akan menghasilkan solusi yang tidak lengkap atau cacat. Oleh karena itu, analisis
sistem adalah dasar dari SDLC lainnya.Analisis sistemsebenarnya adalah proses dua langkah yang melibatkan
survei awal sistem saat ini dan kemudian analisis kebutuhan pengguna.
LANGKAH SURVEI
Sebagian besar sistem tidak dikembangkan dari awal. Biasanya, beberapa bentuk sistem informasi dan
prosedur terkait sudah ada. Analis sering memulai analisis dengan menentukan elemen apa, jika ada, dari
sistem saat ini yang harus dipertahankan sebagai bagian dari sistem baru. Ini melibatkan agak rinci survei
sistem. Fakta yang berkaitan dengan pertanyaan awal tentang sistem dikumpulkan dan dianalisis. Ketika analis
mendapatkan pemahaman yang lebih mendalam tentang masalah, dia mengembangkan pertanyaan yang
lebih spesifik yang membutuhkan lebih banyak fakta untuk dikumpulkan. Proses ini dapat berlangsung melalui
beberapa iterasi. Ketika semua fakta yang relevan telah dikumpulkan dan dianalisis, analis sampai pada
penilaian sistem saat ini. Mensurvei sistem saat ini memiliki kekurangan dan kelebihan.
Kerugian Menyurvei Sistem Saat Ini

Mungkin argumen yang paling menarik terhadap survei sistem saat ini berpusat pada fenomena yang
dikenal sebagai lubang tar fisik saat ini.2Ini adalah kecenderungan analis untuk tersedot dan kemudian
terhambat oleh tugas mensurvei sistem dinosaurus saat ini.
Beberapa berpendapat bahwa survei sistem saat ini menghambat ide-ide baru. Dengan mempelajari dan
memodelkan sistem lama, analis dapat mengembangkan gagasan terbatas tentang bagaimana sistem baru
harus berfungsi. Hasilnya adalah sistem lama yang lebih baik daripada pendekatan baru yang radikal.
Contohnya adalah penerapan sistem ERP. Tugas meninjau prosedur organisasi saat ini mungkin tidak ada
gunanya karena keberhasilan penerapan ERP bergantung pada rekayasa ulang proses ini untuk menerapkan
praktik bisnis terbaik di industri.
2 W. Keuffel, ''Rumah Struktur,''Tinjauan Unix 9 (Februari 1991), 36.

Keuntungan Menyurvei Sistem Saat Ini

Ada tiga keuntungan untuk mempelajari sistem saat ini. Pertama, ini adalah cara untuk mengidentifikasi aspek apa dari sistem
lama yang harus dipertahankan. Beberapa elemen sistem mungkin berfungsi dengan baik dan dapat memberikan dasar untuk
sistem baru. Dengan sepenuhnya memahami sistem saat ini, analis dapat mengidentifikasi aspek-aspek yang layak
dipertahankan atau dimodifikasi untuk digunakan dalam sistem baru.
Kedua, ketika sistem baru diimplementasikan, pengguna harus melalui proses konversi dimana mereka
secara resmi melepaskan diri dari sistem lama dan pindah ke yang baru. Analis harus menentukan tugas,
prosedur, dan data apa yang akan dihapus dengan sistem lama dan mana yang akan dilanjutkan. Untuk
menentukan prosedur konversi ini, analis harus mengetahui tidak hanya apa yang harus dilakukan oleh sistem
baru tetapi juga apa yang dilakukan oleh sistem lama. Ini membutuhkan pemahaman menyeluruh tentang
sistem saat ini.
Akhirnya, dengan mensurvei sistem saat ini, analis dapat menentukan secara meyakinkan penyebab dari
gejala masalah yang dilaporkan. Mungkin akar masalahnya bukanlah sistem informasi sama sekali; itu mungkin
masalah manajemen atau karyawan yang dapat diselesaikan tanpa mendesain ulang sistem informasi. Kami
mungkin tidak dapat mengidentifikasi akar penyebab masalah jika kami membuang sistem yang ada tanpa
menyelidiki gejalanya.
Mengumpulkan Fakta
Survei sistem saat ini pada dasarnya adalah kegiatan pengumpulan fakta. Fakta yang dikumpulkan analis
adalah potongan data yang menggambarkan fitur utama, situasi, dan hubungan sistem. Fakta sistem termasuk
dalam kelas luas berikut:
SUMBER DATA.Ini termasuk entitas eksternal, seperti pelanggan atau vendor, serta sumber internal
dari departemen lain.
PENGGUNA.Ini termasuk manajer dan pengguna operasi.
TOKO DATA.Penyimpanan data adalah file, database, akun, dan dokumen sumber yang digunakan dalam
sistem.
PROSES.Tugas pemrosesan adalah operasi manual atau komputer yang mewakili keputusan atau tindakan yang
memicu informasi.
ALIRAN DATA.Pergerakan dokumen dan laporan antara sumber data, penyimpanan data, tugas pemrosesan,
dan pengguna mewakili aliran data.
KONTROL.Ini termasuk kontrol akuntansi dan operasional dan mungkin prosedur manual atau
kontrol komputer.
VOLUME TRANSAKSI.Analis harus mendapatkan ukuran volume transaksi untuk jangka waktu
tertentu. Banyak sistem diganti karena sudah mencapai kapasitasnya. Memahami karakteristik
volume transaksi sistem dan laju pertumbuhannya merupakan elemen penting dalam menilai
kebutuhan kapasitas untuk sistem baru.
TINGKAT KESALAHAN.Kesalahan transaksi berkaitan erat dengan volume transaksi. Saat sistem mencapai kapasitas, tingkat
kesalahan meningkat ke tingkat yang tidak dapat ditolerir. Meskipun tidak ada sistem yang sempurna, analis harus
menentukan toleransi kesalahan yang dapat diterima untuk sistem yang baru.
BIAYA SUMBERDAYA.Sumber daya yang digunakan sistem saat ini meliputi biaya tenaga kerja, waktu komputer, bahan
(misalnya, faktur), dan overhead langsung. Setiap biaya sumber daya yang hilang ketika sistem saat ini dihilangkan
disebut biaya yang dapat dihindari. Nantinya, saat kami melakukan analisis biaya-manfaat, biaya yang dapat dihindari
akan diperlakukan sebagai manfaat dari sistem baru.
BOTTLENECK DAN OPERASI YANG BERLEBIHAN.Analis harus mencatat titik-titik di mana aliran data berkumpul untuk
membentuk hambatan. Pada periode beban puncak, ini dapat mengakibatkan penundaan dan meningkatkan
kesalahan pemrosesan. Demikian pula, penundaan dapat disebabkan oleh operasi yang berlebihan, seperti
persetujuan atau persetujuan yang tidak perlu. Dengan mengidentifikasi area masalah ini selama fase survei, analis
dapat menghindari kesalahan yang sama dalam mendesain sistem baru.
Teknik Pengumpulan Fakta

Analis sistem menggunakan beberapa teknik untuk mengumpulkan fakta yang dikutip sebelumnya. Ini termasuk
observasi, partisipasi tugas, wawancara pribadi, dan meninjau dokumen kunci.
PENGAMATAN.Pengamatan melibatkan secara pasif menonton prosedur fisik dari sistem. Hal ini memungkinkan analis untuk
menentukan apa yang dilakukan, siapa yang melakukan tugas, kapan mereka melakukannya, bagaimana mereka melakukannya,
mengapa mereka melakukannya, dan berapa lama.
PARTISIPASI TUGAS.Partisipasi merupakan perpanjangan dari pengamatan, dimana analis mengambil peran aktif dalam
melakukan pekerjaan pengguna. Hal ini memungkinkan analis untuk mengalami secara langsung masalah yang terlibat dalam
pengoperasian sistem saat ini. Misalnya, analis dapat bekerja di meja penjualan menerima pesanan dari pelanggan dan
menyiapkan pesanan penjualan. Analis dapat menentukan bahwa dokumen dirancang dengan tidak benar, bahwa waktu yang
ada tidak cukup untuk melakukan prosedur yang diperlukan, atau bahwa masalah beban puncak menyebabkan kemacetan dan
kesalahan pemrosesan. Dengan pengalaman langsung, analis seringkali dapat membayangkan cara yang lebih baik untuk
melakukan tugas tersebut.
WAWANCARA PRIBADI.Wawancara adalah metode penggalian fakta tentang sistem saat ini dan persepsi pengguna
tentang persyaratan untuk sistem baru. Instrumen yang digunakan untuk mengumpulkan fakta-fakta ini mungkin
berupa pertanyaan terbuka atau kuesioner formal.
Pertanyaan terbuka memungkinkan pengguna untuk menguraikan masalah seperti yang mereka lihat dan menawarkan
saran dan rekomendasi. Jawaban atas pertanyaan-pertanyaan ini cenderung sulit untuk dianalisis, tetapi memberi analis
gambaran tentang ruang lingkup masalahnya. Analis dalam jenis wawancara ini harus menjadi pendengar yang baik dan
mampu memusatkan perhatian pada fakta-fakta penting. Contoh pertanyaan terbuka adalah: "Menurut Anda, apa masalah
utama sistem pesanan penjualan kami?" dan "Bagaimana sistem dapat diperbaiki?"
Kuesioner digunakan untuk mengajukan pertanyaan yang lebih spesifik dan terperinci dan untuk membatasi tanggapan
pengguna. Ini adalah teknik yang baik untuk mengumpulkan fakta obyektif tentang sifat prosedur tertentu, volume transaksi
yang diproses, sumber data, pengguna laporan, dan masalah pengendalian.
MENINJAU DOKUMEN KUNCI.Dokumen organisasi adalah sumber fakta lain tentang sistem
yang disurvei. Contohnya termasuk:
- Bagan organisasi
- Deskripsi pekerjaan
- Catatan akuntansi
- Bagan akun
- Pernyataan kebijakan
- Deskripsi prosedur
- Laporan keuangan
- Laporan kinerja
- Bagan alur sistem
- Dokumen sumber
- Daftar transaksi
- Anggaran
- Prakiraan
- Pernyataan misi
Mengikuti fase pengumpulan fakta, analis secara formal mendokumentasikan kesan dan pemahamannya
tentang sistem. Ini akan mengambil bentuk catatan, diagram alur sistem, dan berbagai tingkat diagram
aliran data.
LANGKAH ANALISIS
Analisis sistem adalah proses intelektual yang bercampur dengan pengumpulan fakta. Analis secara bersamaan
menganalisis saat dia mengumpulkan fakta. Pengakuan masalah semata-mata mengandaikan beberapa pemahaman
tentang norma atau keadaan yang diinginkan. Oleh karena itu sulit untuk mengidentifikasi di mana survei berakhir dan
analisis dimulai.
Laporan Analisis Sistem

Acara yang menandai kesimpulan dari tahap analisis sistem adalah persiapan formallaporan analisis
sistem. Laporan ini menyajikan manajemen atau panitia pengarah dengan temuan survei, masalah yang
diidentifikasi dengan sistem saat ini, kebutuhan pengguna, dan persyaratan sistem baru. Gambar 13-5
berisi kemungkinan format untuk laporan ini.
Tujuan utama melakukan analisis sistem adalah untuk mengidentifikasi kebutuhan pengguna dan menentukan persyaratan untuk
sistem baru. Laporan harus menetapkan secara rinci apa yang harus dilakukan sistem daripada bagaimana melakukannya.
ANGKA
13-5 HAIUTLINE DARIMAINTOPICS DALAM ASYSTEMSAANALISISREPORT
Laporan Analisis Sistem
I. Alasan Analisis Sistem

A. Alasan yang ditentukan dalam proposal proyek sistem
B. Perubahan alasan sejak analisis dimulai
C. Alasan tambahan
II. Lingkup Studi

A. Lingkup sebagaimana ditentukan oleh proposal proyek
B. Perubahan ruang lingkup
AKU AKU AKU. Masalah Diidentifikasi dengan Sistem Saat Ini

A. Teknik yang digunakan untuk mengumpulkan fakta
B. Masalah yang dihadapi dalam proses pengumpulan fakta
C. Analisis fakta
IV. Pernyataan Persyaratan Pengguna

A. Kebutuhan khusus pengguna di bidang-bidang utama, seperti:
1. Persyaratan keluaran
2. Volume transaksi
3. Waktu respons
B. Istilah nonteknis untuk khalayak luas, termasuk:
1. Pengguna akhir
2. Manajemen pengguna
3. Manajemen sistem
4. Panitia Pengarah
V. Implikasi Sumber Daya

A. Penilaian awal dampak ekonomi
B. Apakah kelayakan ekonomi yang tercantum dalam proposal masuk akal?
VI. Rekomendasi
A. Haruskah proyek dilanjutkan?
B. Apakah analisis mengubah kelayakan, dampak
strategis, atau prioritas proyek?
Pernyataan persyaratan dalam laporan menetapkan pemahaman antara profesional sistem, manajemen,
pengguna, dan pemangku kepentingan lainnya. Dokumen ini merupakan kontrak formal yang
menentukan tujuan dan sasaran sistem. Laporan analisis sistem harus menetapkan dengan jelas sumber
data, pengguna, file data, proses umum, aliran data, kontrol, dan kapasitas volume transaksi.
Laporan analisis sistem tidak menentukan desain rinci dari sistem yang diusulkan. Misalnya, tidak menentukan
metode pemrosesan, media penyimpanan, struktur rekaman, dan detail lain yang diperlukan untuk merancang sistem
fisik. Sebaliknya, laporan tersebut tetap pada tingkat tujuan untuk menghindari penempatan kendala buatan pada fase
desain konseptual. Beberapa kemungkinan desain dapat melayani kebutuhan pengguna, dan proses pengembangan
harus bebas untuk mengeksplorasi semua ini.
Konseptualisasi Desain Alternatif

Tujuan fase konseptualisasi adalah untuk menghasilkan beberapa solusi konseptual alternatif yang memenuhi
persyaratan sistem yang diidentifikasi selama analisis sistem. Dengan menghadirkan sejumlah alternatif yang masuk
akal kepada pengguna, tim proyek menghindari memaksakan kendala yang terbentuk sebelumnya ke sistem baru.
Desain alternatif ini kemudian masuk ke tahap pemilihan sistem, di mana biaya dan manfaat masing-masing
dibandingkan dan satu desain optimal dipilih untuk konstruksi.
BERAPA DETAIL DESAIN YANG DIBUTUHKAN?

Fase desain konseptual harus menyoroti perbedaan antara fitur-fitur penting dari sistem yang bersaing
daripada persamaannya. Oleh karena itu, desain sistem pada titik ini harus bersifat umum. Desain harus
mengidentifikasi semua input, output, proses, dan fitur khusus yang diperlukan untuk membedakan satu
alternatif dari yang lain. Dalam beberapa kasus, ini dapat dicapai pada tingkat diagram konteks. Dalam
situasi di mana perbedaan penting antara sistem tidak kentara, desain mungkin perlu diwakili oleh
diagram aliran data (DFD) tingkat rendah dan bahkan dengan diagram struktur. Namun, DFD terperinci
dan diagram struktur lebih umum digunakan pada fase desain rinci SDLC. Kami akan membahas transisi
dari DFD rinci ke diagram struktur di Bab 14.
Gambar 13-6 menyajikan dua desain konseptual alternatif untuk sistem pembelian. Desain ini tidak memiliki detail yang
diperlukan untuk mengimplementasikan sistem. Misalnya, mereka tidak menyertakan komponen yang diperlukan seperti:
- Struktur catatan basis data.

- Detail pemrosesan.
- Teknik kontrol khusus.
- Format untuk layar input dan dokumen sumber.
- Format laporan keluaran.
Desainnya, bagaimanapun, memiliki detail yang cukup untuk menunjukkan bagaimana kedua sistem secara konseptual
berbeda dalam fungsinya. Sebagai ilustrasi, mari kita periksa fitur umum dari setiap sistem.
Opsi A adalah sistem pembelian batch tradisional. Input awal untuk proses tersebut adalah permintaan pembelian
dari pengendalian persediaan. Ketika persediaan mencapai titik pemesanan ulang yang telah ditentukan sebelumnya,
persediaan baru dipesan sesuai dengan kuantitas pesanan ekonomisnya. Pengiriman pesanan pembelian ke pemasok
dilakukan sekali sehari melalui surat AS.
Sebaliknya, Opsi B menggunakan teknologi pertukaran data elektronik (EDI). Pemicu sistem ini adalah permintaan
pembelian dari perencanaan produksi. Sistem pembelian menentukan kuantitas dan vendor kemudian mengirimkan
pesanan secara online melalui perangkat lunak EDI ke vendor.
Kedua alternatif memiliki pro dan kontra. Keuntungan dari Opsi A adalah kesederhanaan desainnya, kemudahan
penerapannya, dan permintaan yang lebih rendah untuk sumber daya sistem daripada Opsi B. Aspek negatif dari Opsi A adalah
mengharuskan perusahaan untuk membawa persediaan. Di sisi lain, Opsi B memungkinkan perusahaan untuk mengurangi
atau bahkan menghilangkan persediaan. Manfaat ini datang dengan biaya sumber daya sistem yang lebih mahal dan canggih.
Terlalu dini, pada titik ini, untuk mencoba mengevaluasi manfaat relatif dari alternatif-alternatif ini. Hal ini dilakukan secara
formal pada fase berikutnya dari SDLC. Pada titik ini, perancang sistem hanya peduli dengan mengidentifikasi desain alternatif
yang masuk akal.
588
ANGKA
ALTERNATIFCSEKALIDLATIHAN UNTUK APURCHASINGSYSTEM
13-6
PARTIV
Opsi A, Sistem Batch
Inventaris Penjual
Catatan Data
Kegiatan Pengembangan Sistem

Batch dari Batch dari
Pembelian Pembelian Pengambilan Harian Dikirim oleh
Permintaan Pesanan oleh US Mail Surat AS
Inventaris Membeli Surat Surat AS Penjual
Kontrol Proses Ruang
Proses Proses
Opsi B, Sistem EDI

Tagihan dari Penjual
Bahan Data
Pelanggan Pembelian Elektronik Elektronik Elektronik

Pesanan Permintaan Pesanan Pembelian Transaksi Pesanan Penjualan
Produksi Membeli Sistem EDI Vendor Vendor

Pelanggan
Perencanaan Proses Sistem EDI Memesan
Pengolahan
Sistem
Evaluasi dan Seleksi Sistem

Fase dalam SDLC ini adalah mekanisme formal untuk memilih satu sistem dari rangkaian desain konseptual
alternatif yang akan digunakan untuk konstruksi. Ituevaluasi dan seleksi sistemfase adalah proses optimasi
yang berusaha untuk mengidentifikasi sistem terbaik. Keputusan ini merupakan titik kritis dalam SDLC. Pada
titik ini, ada banyak ketidakpastian tentang sistem, dan keputusan yang buruk bisa menjadi bencana. Tujuan
dari prosedur evaluasi dan seleksi formal adalah untuk menyusun proses pengambilan keputusan ini dan
dengan demikian mengurangi ketidakpastian dan risiko pengambilan keputusan yang buruk.
Tidak ada formula ajaib untuk memastikan keputusan yang baik. Pada akhirnya, keputusan jatuh ke penilaian
manajemen. Tujuannya adalah untuk menyediakan sarana dimana manajemen dapat membuat keputusan yang tepat.
Proses seleksi ini melibatkan dua langkah:
1. Lakukan studi kelayakan yang terperinci.

2. Lakukan analisis biaya-manfaat.
Hasil evaluasi ini kemudian dilaporkan secara formal kepada panitia pengarah untuk pemilihan sistem
akhir.
LAKUKAN STUDI KELAYAKAN DETAIL

Kami memulai proses pemilihan sistem dengan memeriksa kembali faktor kelayakan yang dievaluasi pada awal
sebagai bagian dari proposal sistem. Awalnya, skor yang diberikan untuk faktor-faktor ini sebagian besar didasarkan
pada penilaian dan intuisi profesional sistem. Sekarang fitur sistem spesifik telah dikonseptualisasikan, perancang
memiliki gambaran yang lebih jelas tentang faktor-faktor ini. Juga, pada tahap proposal, faktor-faktor ini dievaluasi
untuk keseluruhan proyek. Sekarang mereka dievaluasi untuk setiap desain konseptual alternatif.
Evaluator yang terinformasi harus melakukanstudi kelayakan rinci. Objektivitas sangat penting untuk penilaian yang
adil dari setiap desain. Grup ini harus terdiri dari manajer proyek, perwakilan pengguna, dan profesional sistem yang
memiliki keahlian di bidang tertentu yang dicakup oleh studi kelayakan. Juga, untuk alasan audit operasional, grup
tersebut harus terdiri dari seorang anggota staf audit internal. Faktor kelayakan yang diperkenalkan pada bagian
sebelumnya memberikan kerangka kerja untuk mengidentifikasi isu-isu kunci yang harus dipertimbangkan oleh
evaluator.
Kelayakan Teknis
Dalam mengevaluasi kelayakan teknis, teknologi yang mapan dan dipahami memiliki risiko yang lebih kecil daripada teknologi
yang tidak dikenal. Jika desain sistem membutuhkan teknologi yang mapan, skor kelayakan akan tinggi, katakanlah 9 atau 10.
Penggunaan teknologi yang baru (rilis pertama) dan asing bagi profesional sistem yang harus menginstal dan memeliharanya,
atau yang merupakan gabungan dari beberapa produk vendor, merupakan pilihan yang lebih berisiko. Bergantung pada
jumlah dan kombinasi faktor risiko, skor kelayakan teknologi tersebut akan lebih rendah.
Kelayakan Hukum
Dalam sistem pemrosesan transaksi keuangan, legalitas sistem selalu menjadi isu. Namun, legalitas juga menjadi
masalah bagi sistem nonkeuangan yang memproses data sensitif, seperti catatan pasien rumah sakit atau peringkat
kredit pribadi. Desain sistem yang berbeda dapat mewakili tingkat risiko yang berbeda ketika berhadapan dengan data
tersebut. Evaluator harus memperhatikan bahwa desain konseptual mengenali masalah kontrol kritis, keamanan, dan
jejak audit dan bahwa sistem tidak melanggar undang-undang yang berkaitan dengan hak privasi dan/atau
penggunaan dan distribusi informasi.
Kelayakan Operasional
Ketersediaan pengguna yang terlatih, termotivasi, dan berpengalaman adalah isu utama dalam mengevaluasi
kelayakan operasional sebuah desain. Jika pengguna tidak memiliki atribut ini, pindah ke lingkungan yang sangat
teknis mungkin berisiko dan akan membutuhkan pelatihan ulang yang ekstensif. Ini juga dapat mempengaruhi
kelayakan ekonomi sistem. Di sisi lain, komunitas pengguna yang nyaman dengan teknologi lebih cenderung
melakukan transisi yang lancar ke sistem teknologi canggih. Skor kelayakan operasional dari setiap desain alternatif
harus mencerminkan kemudahan yang diharapkan dari transisi ini.
Kelayakan Jadwal
Pada titik desain ini, evaluator sistem berada dalam posisi yang lebih baik untuk menilai kemungkinan bahwa
sistem akan selesai sesuai jadwal. Platform teknologi, desain sistem, dan kebutuhan pelatihan pengguna dapat
memengaruhi jadwal asli. Teknologi pengembangan sistem yang digunakan adalah pengaruh lain. Penggunaan
rekayasa perangkat lunak berbantuan komputer (CASE) dan alat prototyping (dibahas dalam Bab 14) dapat
secara signifikan mengurangi waktu pengembangan opsi desain sistem apa pun.
Kelayakan Ekonomi
Studi kelayakan ekonomi pendahuluan dibatasi untuk menilai komitmen keuangan manajemen terhadap
keseluruhan proyek. Ini masih menjadi masalah yang relevan. Apakah iklim ekonomi telah berubah sejak studi
pendahuluan atau apakah satu atau lebih desain yang bersaing tidak mendapat dukungan manajemen harus
ditentukan sekarang.
Studi kelayakan asli dapat menentukan biaya proyek hanya secara umum. Sekarang setiap desain
yang bersaing telah dikonseptualisasikan dan diekspresikan dalam fitur dan proses uniknya, desainer
dapat lebih tepat dalam memperkirakan biaya setiap alternatif. Studi kelayakan ekonomi sekarang dapat
diambil langkah lebih jauh dengan melakukan analisis biaya-manfaat.
LAKUKAN ANALISIS BIAYA-MANFAAT

Analisis biaya-manfaatmembantu manajemen menentukan apakah (dan berapa banyak) manfaat yang diterima dari
sistem yang diusulkan akan lebih besar daripada biayanya. Teknik ini sering digunakan untuk memperkirakan nilai
keuangan yang diharapkan dari investasi bisnis. Namun, dalam kasus ini, investasinya adalah sistem informasi, dan
biaya serta keuntungannya lebih sulit untuk diidentifikasi dan diukur dibandingkan jenis proyek modal lainnya.
Meskipun tidak sempurna dalam pengaturan ini, analisis biaya-manfaat digunakan karena kesederhanaannya dan
tidak adanya alternatif yang jelas lebih baik. Terlepas dari keterbatasannya, analisis biaya-manfaat, dikombinasikan
dengan faktor kelayakan, merupakan alat yang berguna untuk membandingkan desain sistem yang bersaing.
Ada tiga langkah dalam penerapan analisis biaya-manfaat: mengidentifikasi biaya, mengidentifikasi manfaat, dan
membandingkan biaya dan manfaat.
Identifikasi Biaya
Salah satu metode untuk mengidentifikasi biaya adalah membaginya menjadi dua kategori: biaya satu kali dan
biaya berulang. Biaya satu kali termasuk investasi awal untuk mengembangkan dan menerapkan sistem. Biaya
berulang termasuk biaya operasi dan pemeliharaan yang berulang selama umur sistem. Tabel 13-2
menunjukkan rincian biaya satu kali dan berulang.
Biaya Satu Kali

AKUISISI PERANGKAT KERAS.Ini termasuk biaya server mainframe, PC, dan peralatan periferal,
seperti jaringan dan paket disk. Angka biaya untuk item dapat diperoleh dari vendor.
PERSIAPAN LOKASI.Ini melibatkan biaya yang sering diabaikan seperti modifikasi bangunan, misalnya
menambahkan AC atau membuat perubahan struktural; pemasangan peralatan, yang dapat mencakup
penggunaan alat berat; dan ongkos angkut. Perkiraan biaya tersebut dapat diperoleh dari vendor dan
subkontraktor yang melakukan pemasangan.
AKUISISI PERANGKAT LUNAK.Biaya ini berlaku untuk semua perangkat lunak yang dibeli untuk sistem yang diusulkan,
termasuk perangkat lunak sistem operasi, jika tidak dipaketkan dengan perangkat keras; perangkat lunak kontrol
jaringan; dan aplikasi komersial, seperti paket akuntansi. Perkiraan biaya ini dapat diperoleh dari vendor.
DESAIN SISTEM.Ini adalah biaya yang dikeluarkan oleh para profesional sistem untuk melakukan fungsi perencanaan,
analisis, dan desain. Secara teknis, biaya yang dikeluarkan hingga saat ini hangus dan tidak relevan dengan keputusan.
Analis harus memperkirakan hanya biaya yang dibutuhkan untuk menyelesaikan desain rinci.
MEJA
13-2 HAINE-TIME DANRECURINGCOST
Biaya Satu Kali
Akuisisi perangkat keras
Persiapan situs
Akuisisi perangkat lunak
Desain sistem
Pemrograman dan pengujian
Konversi data dari sistem lama ke sistem baru
Pelatihan personil
Biaya Berulang
Pemeliharaan perangkat keras
Asuransi kontrak pemeliharaan
perangkat lunak
Persediaan
Personil
PEMROGRAMAN DAN PENGUJIAN.Biaya pemrograman didasarkan pada perkiraan jam personel yang diperlukan untuk
menulis program baru dan memodifikasi program yang ada untuk sistem yang diusulkan. Biaya pengujian sistem
melibatkan menyatukan semua modul program individual untuk pengujian sebagai keseluruhan sistem. Ini harus
menjadi latihan yang keras jika ingin bermakna. Perencanaan, pengujian, dan analisis hasil mungkin memerlukan
keterlibatan berhari-hari dari profesional sistem, pengguna, dan pemangku kepentingan sistem lainnya. Pengalaman
perusahaan di masa lalu adalah dasar terbaik untuk memperkirakan biaya ini.
KONVERSI DATA.Biaya ini timbul dalam transfer data dari satu media penyimpanan atau struktur yang lain.
Sebagai contoh, catatan akuntansi dari sistem manual harus diubah menjadi bentuk digital ketika sistem
menjadi berbasis komputer. Ini dapat mewakili tugas yang signifikan. Dasar untuk memperkirakan biaya
konversi adalah jumlah dan ukuran file yang akan dikonversi.
PELATIHAN.Biaya ini melibatkan mendidik pengguna untuk mengoperasikan sistem baru. Hal ini dapat dilakukan
dalam program pelatihan ekstensif yang disediakan organisasi luar di lokasi terpencil atau melalui pelatihan di tempat
kerja oleh personel internal. Biaya pelatihan formal dapat dengan mudah diperoleh. Biaya program pelatihan in-house
termasuk waktu pengajaran, fasilitas kelas, dan produktivitas yang hilang.
Biaya Berulang
PEMELIHARAAN PERANGKAT KERAS.Ini melibatkan biaya untuk memutakhirkan komputer (misalnya,
menambah memori), serta pemeliharaan preventif dan perbaikan komputer dan peralatan periferal.
Organisasi dapat masuk ke dalam kontrak pemeliharaan dengan vendor untuk meminimalkan dan
menganggarkan biaya ini. Perkiraan biaya ini dapat diperoleh dari vendor dan kontrak yang ada.
PEMELIHARAAN PERANGKAT LUNAK.Biaya ini termasuk upgrade dan debugging sistem operasi, aplikasi yang dibeli,
dan aplikasi yang dikembangkan sendiri. Kontrak pemeliharaan dengan vendor perangkat lunak dapat digunakan
untuk menentukan biaya ini dengan cukup akurat. Perkiraan pemeliharaan internal dapat diturunkan dari data historis.
PERTANGGUNGAN.Ini mencakup bahaya dan bencana seperti kebakaran, kegagalan perangkat keras, vandalisme, dan
perusakan oleh karyawan yang tidak puas.
MEJA
13-3 TANGIBLEBMANFAAT
Peningkatan Pendapatan
Peningkatan penjualan dalam pasar

yang ada Ekspansi ke pasar lain
Pengurangan biaya
Pengurangan tenaga kerja
Pengurangan biaya operasi (seperti persediaan dan overhead)
Mengurangi persediaan
Peralatan yang lebih murah
Mengurangi pemeliharaan peralatan
PERSEDIAAN.Biaya ini dikeluarkan melalui konsumsi rutin barang-barang seperti kartrid printer dan
kertas, disk magnetik, pita magnetik, dan perlengkapan kantor umum.
PERSONIL.Ini adalah gaji individu yang merupakan bagian dari sistem informasi. Beberapa biaya karyawan
bersifat langsung dan mudah diidentifikasi, seperti gaji personel operasi yang dipekerjakan secara eksklusif
sebagai bagian dari sistem yang dianalisis. Beberapa keterlibatan personel, misalnya, administrator basis data
dan personel ruang komputer, adalah hal yang umum bagi banyak sistem. Biaya personel tersebut harus
dialokasikan berdasarkan keterlibatan inkremental yang diharapkan dengan sistem.
Identifikasi Manfaat
Langkah selanjutnya dalam analisis biaya-manfaat adalah mengidentifikasi manfaat dari sistem. Ini mungkin berwujud
dan tidak berwujud.
MANFAAT NYATA.Manfaat berwujud adalah manfaat yang dapat diukur dan dinyatakan dalam istilah keuangan. Tabel
13-3 mencantumkan beberapa jenis manfaat nyata.
Manfaat nyata terbagi dalam dua kategori: manfaat yang meningkatkan pendapatan dan manfaat yang mengurangi biaya.
Misalnya, asumsikan sistem EDI yang diusulkan akan memungkinkan organisasi mengurangi persediaan dan pada saat yang
sama meningkatkan layanan pelanggan dengan mengurangi kehabisan stok. Pengurangan persediaan adalah manfaat
pengurangan biaya. Sistem yang diusulkan akan menggunakan lebih sedikit sumber daya (persediaan) daripada sistem saat ini.
Nilai manfaat ini adalah jumlah dolar dari biaya penyimpanan yang dihemat oleh pengurangan persediaan tahunan. Estimasi
peningkatan penjualan karena layanan pelanggan yang lebih baik adalah manfaat peningkatan pendapatan.
Saat mengukur penghematan biaya, hanya biaya yang dapat dihindari yang harus dimasukkan dalam analisis. Biaya yang
dapat dihindari berhubungan langsung dengan sistem dan tidak ada lagi ketika sistem tidak ada lagi. Beberapa biaya yang
tampaknya dapat dihindari oleh pengguna tidak benar-benar dapat dihindari dan, jika disertakan, dapat menyebabkan analisis
yang cacat. Misalnya, pusat pemrosesan data sering membebankan kembali biaya operasinya kepada konstituen penggunanya
melalui alokasi biaya. Tarif pengembalian yang mereka gunakan untuk ini mencakup biaya tetap (dialokasikan ke pengguna)
dan biaya langsung yang dibuat oleh aktivitas pengguna individual. Gambar 13-7 mengilustrasikan teknik ini.
Asumsikan manajemen di Area Pengguna B mengusulkan untuk mengakuisisi sistem komputer dan melakukan
pemrosesan datanya sendiri secara lokal. Salah satu manfaat dari proposal ini adalah penghematan biaya yang
diperoleh dengan menghindari tagihan balik dari pusat pemrosesan data saat ini. Meskipun pengguna mungkin
melihat ini sebagai biaya tahunan $400.000, organisasi secara keseluruhan hanya dapat menghindari porsi biaya
langsung ($50.000). Jika proposal disetujui, sisa tagihan sebesar $350.000 tidak akan hilang. Pengguna yang tersisa dari
sistem saat ini sekarang harus menanggung biaya ini.
MANFAAT TIDAK BERWUJUD.Tabel 13-4 mencantumkan beberapa kategori umum dari manfaat tak berwujud. Meskipun
manfaat tak berwujud sering kali menjadi kepentingan utama dalam keputusan sistem informasi, namun tidak demikian
ANGKA
13-7 DP CMEMASUKICOSTCBERHARGA-BAKUIASSERAREAS
Pengguna E
Pengguna A
li
M
ba
en
em
gi
-K
si-
isi
Ke
g
m
en
ba
M
li
Biaya Total-Kembali ke Pusat DP
Area Pengguna B = $400.000 Biaya operasional:
Biaya Tetap = $1.200.000

Men
bali gisi-
m Kem
gis i-Ke Dapat Dilacak Langsung bali
Men Biaya = $278.000
tap
a n Te
0
kasik 0.00
Pengguna B Dialo = $35 00 Pengguna D
a
Biay g = $50
.0
un
ngs
Mengisi-Kembali
a La
Biay
Pengguna C
mudah diukur dan dikuantifikasi. Misalnya, asumsikan bahwa sistem point-of-sale yang diusulkan untuk department store akan
mengurangi waktu rata-rata untuk memproses transaksi penjualan pelanggan dari 11 menit menjadi 3 menit. Waktu yang
dihemat dapat dihitung dan menghasilkan keuntungan nyata dalam bentuk penghematan biaya operasi. Manfaat tak berwujud
adalah peningkatan kepuasan pelanggan; tidak ada yang suka antre panjang untuk membayar pembelian. Tapi apa nilai
sebenarnya dari manfaat tak berwujud ini bagi organisasi? Kepuasan pelanggan yang meningkat dapat diterjemahkan ke dalam
peningkatan penjualan. Lebih banyak pelanggan akan membeli di toko—dan mungkin
MEJA
13-4 SAYATIDAK BERWUJUDBMANFAAT
Peningkatan kepuasan pelanggan
Peningkatan kepuasan karyawan
Informasi lebih terkini
Pengambilan keputusan yang lebih baik
Respons yang lebih cepat terhadap tindakan
pesaing Operasi yang lebih efisien
Komunikasi internal dan eksternal yang lebih baik
Perbaikan perencanaan
Fleksibilitas operasional
Peningkatan lingkungan kontrol

bersedia membayar sedikit lebih banyak untuk menghindari antrean pembayaran yang panjang. Tapi bagaimana kita mengukur
terjemahan ini? Menetapkan nilai seringkali sangat subyektif.
Profesional sistem memanfaatkan banyak sumber dalam upaya untuk mengukur manfaat tidak berwujud
dan memanipulasinya ke dalam istilah keuangan. Beberapa teknik umum termasuk survei pendapat pelanggan
(dan karyawan), analisis statistik, teknik nilai yang diharapkan, dan model simulasi. Meskipun profesional sistem
mungkin berhasil mengukur beberapa manfaat tak berwujud ini, lebih sering mereka harus puas hanya dengan
menyatakan manfaat setepat mungkin.
Karena menentang pengukuran yang tepat, manfaat tak berwujud terkadang dieksploitasi untuk alasan politik.
Dengan melebih-lebihkan atau mengecilkan manfaat ini, pendukung sistem dapat mendorongnya maju atau lawannya
dapat membunuhnya.
Bandingkan Biaya dan Manfaat

Langkah terakhir dalam analisis biaya-manfaat adalah membandingkan biaya dan manfaat yang diidentifikasi dalam dua
langkah pertama. Dua metode yang paling umum digunakan untuk mengevaluasi sistem informasi adalah net present value
dan payback.
METODE NILAI SEKARANG BERSIH.Di bawahmetode nilai sekarang bersih, nilai sekarang dari biaya dikurangkan
dari nilai sekarang dari manfaat selama umur sistem. Proyek dengan net present value positif layak secara
ekonomi. Saat membandingkan proyek yang bersaing, pilihan optimal adalah proyek dengan nilai sekarang
bersih terbesar. Gambar 13-8 mengilustrasikan metode net present value dengan membandingkan dua desain
yang bersaing.
Contoh tersebut didasarkan pada data berikut:
Desain A Desain B
Waktu penyelesaian proyek Umur 1 tahun 1 tahun
manfaat yang diharapkan dari 5 tahun 5 tahun
sistem Biaya satu kali (ribuan) $300 $140
Biaya berulang (ribuan) yang dikeluarkan pada awal Tahun 1 hingga 5 Manfaat $45 $55
berwujud tahunan (ribuan) yang dikeluarkan pada akhir Tahun 1 hingga 5 $170 $135
Jika hanya biaya dan manfaat nyata yang dipertimbangkan, maka Desain A akan dipilih daripada
Desain B. Namun, nilai manfaat tak berwujud, bersama dengan skor kelayakan desain, juga harus
diperhitungkan dalam analisis akhir.
ANGKA
13-8 NETPMEMBENCIVALUEMETOSCOST-BMANFAATAANALISIS
Awal Awal
Tahun Akhir tahun Tahun Akhir tahun
Waktu Arus keluar Arus masuk Waktu Arus keluar Arus masuk
0 $(300.000) 0 $(140.000)
1 (45.000) 170.000 1 (55.000) 135.000
2 (45.000) 170.000 2 (55.000) 135.000
3 (45.000) 170.000 3 (55.000) 135.000
4 (45.000) 170.000 4 (55.000) 135.000
5 (45.000) 170.000 5 (55.000) 135.000
PV Keluar $(479.672) PV Keluar $(359.599)

PV Di $628.482 PV Di $499.089
NPV $148.810 NPV $139.490
Minat
Kecepatan 8,00%
METODE PEMBAYARAN.Itumetode pengembalianadalah variasi analisis titik impas. Titik impas dicapai ketika
total biaya sama dengan total manfaat. Gambar 13-9(a) dan 13-9(b) mengilustrasikan pendekatan ini dengan
menggunakan data dari contoh sebelumnya.
Kurva biaya total terdiri dari biaya satu kali ditambah nilai sekarang dari biaya berulang selama umur
proyek. Kurva manfaat total adalah nilai sekarang dari manfaat nyata. Persimpangan garis-garis ini
menunjukkan jumlah tahun ke depan ketika proyek mencapai titik impas, atau terbayar dengan sendirinya.
Area yang diarsir antara kurva manfaat dan kurva biaya total mewakili nilai sekarang dari keuntungan masa
depan yang diperoleh sistem.
Dalam memilih sistem informasi, kecepatan pengembalian sering menjadi faktor penentu. Dengan siklus hidup produk yang
singkat dan kemajuan teknologi yang cepat, umur efektif sistem informasi cenderung pendek. Dengan menggunakan kriteria
ini, Desain B, dengan periode pengembalian 4 tahun, akan dipilih daripada Desain A, yang pengembaliannya akan memakan
waktu 4½ tahun. Lamanya periode pengembalian sering lebih diutamakan daripada pertimbangan lain yang diwakili oleh
manfaat tidak berwujud.
SIAPKAN LAPORAN SELEKSI SISTEM

Bagian yang dapat disampaikan dari proses pemilihan sistem adalahlaporan pemilihan sistem. Dokumen
formal ini terdiri dari studi kelayakan yang direvisi, analisis biaya-manfaat, dan daftar serta penjelasan
manfaat tak berwujud untuk setiap desain alternatif. Berdasarkan laporan ini, panitia pengarah akan
memilih satu sistem yang akan maju ke fase berikutnya dari fase konstruksi SDLC.
ANGKA
13-9(a) DDIPERHITUNGKANPKEMBALIMETOSCOST-BMANFAATAANALISIS
700
600 Desain A
500
400
iaya
otal B
Dolar (ribuan)
g dari T
karan
N ilai Se
300
al
ot
Poin Pengembalian
T
at
fa
200 an
riM
da
ng
ra
100 eka
iS
ila
N
0
1 2 3 4 5 6
Periode
ANGKA
DDIPERHITUNGKANPKEMBALIMETOSCOST-BMANFAATAANALISIS(lanjutan)
13-9(b)
600
500 Desain B
400
Dolar (ribuan)
300
iaya
Poin Pengembalian
al B
Tot al
dari t
200 ang To
kar at
i Se fa
Nila an
r iM
da
g
100 an
ar
S ek
l ai
Ni
0
1 2 3 4 5 6
Periode
Pengembangan In-House atau Beli Perangkat Lunak Komersial

Dua opsi umum terbuka untuk organisasi dalam fase konstruksi: mengembangkan sistem sendiri atau
membeli perangkat lunak komersial. Pada titik ini, manajemen harus memiliki pemahaman yang baik
tentang opsi mana yang akan diikuti. Sistem yang harus memenuhi kebutuhan bisnis yang unik dan
berpemilik lebih mungkin mengalami pengembangan internal. Sistem yang diharapkan mendukung
praktik industri terbaik mungkin lebih cocok untuk opsi perangkat lunak yang dibeli. Pendekatan ketiga,
yang melibatkan kedua opsi, adalah menyesuaikan sistem komersial untuk memenuhi kebutuhan
organisasi. Ini mungkin memerlukan modifikasi in-house ekstensif pada paket. Analisis sebelumnya
tentang arsitektur sistem, faktor TELOS, hasil survei sistem, dan masalah biaya-manfaat awal akan
mengungkapkan kepada pembuat keputusan tentang kesesuaian satu pendekatan dibandingkan
pendekatan lainnya.
MENGUMUMKAN PROYEK SISTEM BARU

Pengumuman formal manajemen tentang sistem baru ke seluruh organisasi adalah langkah terakhir dan
paling rumit dalam fase inisiasi proyek SDLC. Komunike yang sangat penting ini, jika berhasil, akan
membuka jalan bagi sistem baru dan membantu memastikan penerimaannya di antara komunitas
pengguna.
Suatu sistem baru terkadang dapat menimbulkan reaksi politik yang cukup besar yang dapat mengancam
keberhasilannya. Misalnya, tidak semua pengguna dapat memahami tujuan dari sistem baru. Faktanya, ketidakpastian
seputar sistem dapat menyebabkan beberapa pengguna merasa terancam. Seperti yang telah kita lihat, sistem baru
harus meningkatkan produktivitas dan efisiensi operasi. Tujuan ini kadang diterjemahkan ke dalam
restrukturisasi organisasi yang mengikis basis kekuatan pribadi beberapa pengguna. Karena sistem baru
membawa perubahan operasional, beberapa karyawan mungkin dipindahkan atau mungkin diharuskan
menjalani pelatihan ulang agar berfungsi di tempat kerja baru.
Ketakutan yang mengakar dan tumbuh dalam lingkungan ketidakpastian ini seringkali terungkap dalam tindakan oposisi,
baik secara terang-terangan maupun terselubung, terhadap sistem baru tersebut. Untuk meminimalkan oposisi, manajemen
puncak harus memadamkan ketakutan yang tidak perlu dan sepenuhnya menjelaskan alasan bisnis untuk sistem baru sebelum
konstruksi formal dimulai. Jika manajemen tingkat bawah dan staf operasional yakin bahwa sistem tersebut akan bermanfaat,
peluang keberhasilan proyek akan meningkat pesat.
UMPAN BALIK PENGGUNA

Pembahasan sebelumnya didasarkan pada asumsi bahwa proyek yang sedang dikembangkan melewati
tahap perencanaan strategis yang disajikan pada bagian sebelumnya. Tidak semua proyek sistem harus,
atau dapat, dimulai dengan cara ini. Pemeliharaan sistem merupakan komponen integral dari lingkungan
SDLC modern. Fungsi ini harus menerima umpan balik pengguna dan responsif terhadap kebutuhan sah
mereka. Oleh karena itu, permintaan pengguna juga diarahkan ke fase inisiasi proyek (lihat Gambar
13-1). Pada titik ini di SDLC, permintaan pengguna melibatkan peningkatan yang relatif kecil pada sistem
yang ada daripada retrofit besar atau sistem yang sama sekali baru. Oleh karena itu, anggaran TI harus
cukup fleksibel untuk mengakomodasi proyek cepat jangka pendek yang muncul setiap hari.
Peran Akuntan dalam Mengelola SDLC

Proses SDLC menarik bagi akuntan karena dua alasan. Pertama, pembuatan sistem informasi merupakan
transaksi keuangan yang signifikan yang menghabiskan sumber daya keuangan dan manusia. Pengembangan
sistem seperti proses manufaktur yang menghasilkan produk yang kompleks melalui serangkaian tahapan.
Transaksi tersebut harus direncanakan, disahkan, dijadwalkan, dipertanggungjawabkan, dan dikendalikan.
Akuntan sangat peduli dengan integritas proses ini seperti proses manufaktur yang memiliki implikasi sumber
daya keuangan.
Yang kedua, dan lebih mendesak, perhatian akuntan adalah dengan produk yang muncul dari SDLC. Kualitas sistem
informasi akuntansi terletak langsung pada kegiatan SDLC yang memproduksinya. Sistem ini digunakan untuk
menyampaikan informasi akuntansi kepada pengguna internal dan eksternal. Tanggung jawab akuntan adalah untuk
memastikan bahwa sistem menerapkan konvensi dan aturan akuntansi yang tepat dan memiliki kontrol yang
memadai. Oleh karena itu, akuntan sangat memperhatikan kualitas proses yang menghasilkan sistem informasi
akuntansi. Misalnya, sistem pesanan penjualan yang dihasilkan oleh SDLC yang rusak mungkin mengalami kelemahan
kontrol yang serius yang menimbulkan kesalahan ke dalam database dan, akhirnya, laporan keuangan.
BAGAIMANA AKUNTAN TERLIBAT DENGAN SDLC?

Akuntan terlibat dalam pengembangan sistem dalam tiga cara. Pertama, akuntan adalah pengguna. Semua sistem yang
memproses transaksi keuangan berdampak pada fungsi akuntansi dalam beberapa cara. Seperti semua pengguna, akuntan
harus memberikan gambaran yang jelas tentang masalah dan kebutuhan mereka kepada profesional sistem. Misalnya, akuntan
harus menentukan teknik akuntansi yang akan digunakan; persyaratan pengendalian internal, seperti jejak audit; dan algoritma
khusus, seperti model penyusutan.
Kedua, akuntan berpartisipasi dalam pengembangan sistem sebagai anggota tim pengembangan. Keterlibatan
mereka seringkali melampaui pengembangan aplikasi sistem informasi akuntansi yang ketat. Sistem yang tidak
memproses transaksi keuangan mungkin masih menggunakan data akuntansi. Akuntan dapat dikonsultasikan untuk
memberikan nasihat atau untuk menentukan apakah sistem yang diusulkan mengandung risiko pengendalian internal.
Ketiga, akuntan terlibat dalam pengembangan sistem sebagai auditor. Sistem informasi akuntansi harus
dapat diaudit. Beberapa teknik audit komputer memerlukan fitur khusus yang harus dirancang ke dalam
sistem. Auditor/akuntan memiliki andil dalam sistem tersebut dan harus terlibat sejak awal dalam
perancangannya.
PERAN AKUNTAN DALAM STRATEGI SISTEM

Auditor secara rutin meninjau strategi sistem organisasi. Sejarah telah menunjukkan bahwa perencanaan sistem yang
hati-hati adalah aktivitas hemat biaya dalam mengurangi risiko menciptakan sistem yang tidak dibutuhkan, tidak
diinginkan, tidak efisien, dan tidak efektif. Baik auditor internal maupun eksternal memiliki kepentingan dalam hasil ini.
PERAN AKUNTAN DALAM DESAIN KONSEPTUAL

Akuntan memainkan peran penting dalam desain konseptual sistem. Dia harus mengenali implikasi kontrol dari
setiap desain alternatif dan memastikan bahwa konvensi akuntansi dan persyaratan hukum dipahami. Isu-isu
ini tidak perlu ditentukan secara rinci pada saat ini, tetapi harus dikenali sebagai item yang harus ditangani
selama fase konstruksi sistem. Selain itu, kemampuan audit suatu sistem sebagian tergantung pada
karakteristik desainnya. Beberapa teknik audit komputer memerlukan sistem yang dirancang dengan fitur audit
bawaan. Fitur tersebut memerlukan sumber daya dan perlu dipertimbangkan pada desain konseptual.
PERAN AKUNTAN DALAM PEMILIHAN SISTEM

Kelayakan ekonomi dari sistem yang diusulkan menjadi perhatian utama para akuntan. Secara khusus, akuntan
harus memastikan bahwa:
- Hanya biaya yang dapat dihindari yang digunakan dalam perhitungan manfaat penghematan biaya.
- Suku bunga yang wajar digunakan dalam mengukur nilai sekarang dari arus kas.
- Biaya satu kali dan berulang dilaporkan secara lengkap dan akurat.
- Masa manfaat yang realistis digunakan dalam membandingkan proyek-proyek yang bersaing.
- Manfaat tak berwujud diberikan nilai keuangan yang wajar.
Kesalahan, kelalaian, dan kesalahan penyajian dalam akuntansi untuk hal-hal tersebut dapat mendistorsi analisis dan menghasilkan
keputusan yang kurang optimal.
Ringkasan
Bab ini berurusan dengan mengelola SDLC. Itu dimulai dengan mengenai berbagai alternatif sistem yang sedang dipertimbangkan.
review fase kunci dari SDLC modern. Yang pertama melibatkan Evaluasi sistem dan pemilihan akhir dilakukan melalui studi
perencanaan sistem strategis, yang memperoleh masukan dari kelayakan yang terperinci dan analisis biaya-manfaat yang cermat
rencana bisnis strategis, beragam kebutuhan dan perhatian dari solusi alternatif ini. Karena keberhasilan pada tahap ini
komunitas pengguna, dan sistem warisan organisasi yang ada. sebagian besar bergantung pada identifikasi yang akurat dari biaya
dan manfaat prospektif, kami memberikan perhatian khusus pada
Bab ini kemudian meninjau fase inisiasi proyek SDLC. Ini prinsip biaya satu kali dan berulang yang terkait dengan sistem dan
termasuk analisis sistem dan konseptualisasi desain alternatif. berbagai manfaat berwujud dan tidak berwujud yang dapat
Untuk memastikan solusi sistem yang benar, manajemen harus diharapkan. untuk menghasilkan. Bab ini diakhiri dengan review
mengumpulkan dan menimbang informasi yang relevan peran akuntan dalam mengelola SDLC.
Istilah Kunci
deskripsi arsitektur (577) kelayakan jadwal (579)
balanced scorecard (BSC) (580) pemangku kepentingan (576)

analisis kompetensi (577) komite pengarah (576)
analisis biaya-manfaat (590) survei sistem (583)
studi kelayakan terperinci (589) analisis sistem (583)
kelayakan ekonomi (579) laporan analisis sistem (586)
pengguna akhir (576) siklus hidup pengembangan sistem (SDLC)
analisis industri (577) (573) evaluasi dan pemilihan sistem (589)
kelayakan hukum (579) profesional sistem (575)
metode nilai sekarang bersih (594) proposal proyek sistem (579)
kelayakan operasional (579) metode laporan pemilihan sistem (595)
pengembalian (595) strategi sistem (576)
manajemen proaktif (578) kelayakan teknis (579)
kelayakan proyek (579) TELOS (579)
manajemen reaktif (578)
Tinjau Pertanyaan
1.Apa lima tahap siklus hidup pengembangan 13.Mengapa pengumuman formal dari teknik sistem baru
sistem? menjadi sangat penting?
2.Apa itu kartu skor berimbang? 14.Diskusikan berbagai langkah kelayakan yang harus
3.Apa peran akuntan dalam SDLC? Mengapa akuntan dipertimbangkan. Berikan contoh masing-masing.
diminta untuk memberikan masukan dalam 15.Apa kelas luas fakta yang perlu dikumpulkan
pengembangan sistem informasi nonakuntansi? dalam survei sistem?
16.Apa teknik pengumpulan fakta utama?
4.Apa perspektif pembelajaran dan pertumbuhan? 17.Apa manfaat dan kerugian relatif dari survei
5.Mengapa seringkali sulit untuk memperoleh keterlibatan sistem saat ini?
pengguna yang kompeten dan berarti dalam SDLC? 18.Apa tujuan utama dari desain
6.Apakah SDLC merupakan prosedur langkah demi langkah konseptual?
yang harus diikuti dengan tepat, atau lebih interaktif dan 19.Berapa detail desain yang dibutuhkan dalam fase
rekursif? Jelaskan jawabanmu. desain konseptual?
7.Jelaskan mengapa survei sistem saat ini mungkin 20.Apa peran utama akuntan dalam desain
tidak berguna ketika organisasi berencana untuk konseptual?
menerapkan ERP.
21.Siapa yang harus disertakan dalam kelompok evaluator
8.Mengapa penting bahwa tujuan strategis yang melakukan studi kelayakan terperinci?
perusahaan dipertimbangkan saat melakukan
22.Apa yang membuat analisis biaya-manfaat lebih sulit
fase perencanaan sistem?
untuk sistem informasi daripada kebanyakan investasi
9.Siapa yang harus duduk di komite pengarah lain yang mungkin dilakukan organisasi?
sistem? Apa tanggung jawab khas mereka?
23.Klasifikasikan masing-masing biaya berikut sebagai biaya satu
10.Jelaskan perspektif proses bisnis internal. kali atau berulang:
11.Bandingkan gaya manajemen proaktif dan reaktif. A. personel pelatihan
Gaya mana yang Anda pilih untuk organisasi Anda?
B. pemrograman awal dan pengujian
Mengapa?
C. desain sistem
12.Tujuan apa yang dilayani oleh tujuan sistem? Haruskah
D. biaya perangkat keras
mereka didefinisikan secara luas atau sempit?
Mengapa? e. biaya pemeliharaan perangkat lunak

Mengelola Sistem: Siklus Hidup Pengembangan

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Mengelola Sistem: Siklus Hidup Pengembangan

Diunggah oleh

Hak Cipta:

Format Tersedia

13

Diterjemahkan dari bahasa Inggris ke bahasa Indonesia - www.onlinedoctranslator.com

- Memahami peran akuntan

Siklus Hidup Pengembangan Sistem

3. Sistem In-House 4. Paket Komersial

Baru dan Revisi

5. Pemeliharaan dan Dukungan

PESERTA DALAM PENGEMBANGAN SISTEM

Menilai Kebutuhan Informasi Strategis

KEBUTUHAN BISNIS STRATEGIS

Visi dan Misi

Analisis Industri dan Kompetensi

Analisis industrimenyediakan manajemen dengan analisis kekuatan pendorong yang mempengaruhi

Mengembangkan Deskripsi Arsitektur

UMPAN BALIK PENGGUNA

13-1 BKEGUNAANBKEUNTUNGAN DARIARsitekturDESKRIPSI

Operasi TI yang efisien

Kemampuan untuk mengatasi masalah kritis di seluruh perusahaan

- Peningkatan dan pertukaran komponen sistem yang lebih mudah.

- Mengurangi kompleksitas dalam infrastruktur TI.

- Pengembalian investasi maksimum dalam infrastruktur TI yang ada.

- Fleksibilitas untuk membuat, membeli, atau mengalihdayakan solusi TI.

Pengadaan yang lebih baik

Menentukan Tujuan Sistem

Kelayakan Proyek Pendahuluan

Mempersiapkan Proposal Proyek Formal

Diminta oleh: JJ Johnson Tanggal: 13/11/09

Sifat Sistem yang Diminta:Sistem Kontrol Inventaris

Persyaratan Sumber Daya Sistem Baru:

Mengembangkan Rencana Sistem Strategis

Buat Rencana Tindakan

1. Perspektif pembelajaran dan pertumbuhan.

2. Perspektif proses bisnis internal.

PERSPEKTIF PEMBELAJARAN DAN PERTUMBUHAN

PERSPEKTIF PROSES BISNIS INTERNAL

BALANCED SCORECARD DITERAPKAN PADA PROYEK TI

13-4 BALANCEDSCORECARD UNTUKHAINLINEBANKINGSYSTEM

Intern Strategi: Sedang belajar

transaksi memindahkan pelanggan ke

Kerugian Menyurvei Sistem Saat Ini

2 W. Keuffel, ''Rumah Struktur,''Tinjauan Unix 9 (Februari 1991), 36.

Keuntungan Menyurvei Sistem Saat Ini

PENGGUNA.Ini termasuk manajer dan pengguna operasi.

Teknik Pengumpulan Fakta

Laporan Analisis Sistem

13-5 HAIUTLINE DARIMAINTOPICS DALAM ASYSTEMSAANALISISREPORT

Laporan Analisis Sistem

I. Alasan Analisis Sistem

II. Lingkup Studi

AKU AKU AKU. Masalah Diidentifikasi dengan Sistem Saat Ini

IV. Pernyataan Persyaratan Pengguna

V. Implikasi Sumber Daya

Konseptualisasi Desain Alternatif

BERAPA DETAIL DESAIN YANG DIBUTUHKAN?

- Struktur catatan basis data.

Kegiatan Pengembangan Sistem

Opsi B, Sistem EDI

Pelanggan Pembelian Elektronik Elektronik Elektronik

Produksi Membeli Sistem EDI Vendor Vendor

Evaluasi dan Seleksi Sistem

1. Lakukan studi kelayakan yang terperinci.

LAKUKAN STUDI KELAYAKAN DETAIL

LAKUKAN ANALISIS BIAYA-MANFAAT