PERSPEKTIF PROSES BISNIS INTERNAL

Metrik berdasarkan perspektif ini memungkinkan manajer mengetahui seberapa baik bisnis
mereka berjalan dan apakah produk dan layanannya sesuai dengan kebutuhan pelanggan.
Mereka yang mengetahui proses ini sangat perlu secara hati-hati merancang metrik ini.

PERSPEKTIF PELANGGAN
Filosofi manajemen baru-baru ini telah menunjukkan peningkatan realisasi kepentingan 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
buruk dari perspektif ini memprediksi penurunan di masa depan, meskipun gambaran keuangan
saat ini mungkin terlihat bagus. Perspektif pelanggan mencakup pengukuran yang obyektif
seperti tingkat retensi pelanggan, serta kriteria yang lebih subjektif seperti survei 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 keempat perspektif pengukuran inti ini.
Pertimbangkan, misalnya, bisnis yang mengalami kinerja buruk dari perspektif keuangan,
seperti yang diperkirakan oleh pertumbuhan penjualan rendah, dan dari perspektif pelanggan,
yang diukur dengan retensi pelanggan dan kepuasan rendah. Dengan menggunakan pendekatan
BSC, manajemen dapat memeriksa langkah-langkah dari perspektif pembelajaran dan inovasi
dan dari perspektif proses internal untuk mengidentifikasi akar permasalahan serta solusi
potensial terhadap masalah tersebut. Dengan mengidentifikasi ketidakseimbangan yang ada di
area pengukuran ini, scorecard dapat digunakan untuk melakukan tindakan korektif.

BALANCED SCORECARD BERLAKU UNTUK PROYEK IT

Gambar 13-4 mengilustrasikan sebuah BSC yang mengukur keuntungan bisnis sebuah pro
perbankan online hipotetis. Pelanggan ritel bank menghasilkan margin keuntungan yang rendah
karena overhead yang tinggi dan biaya layanan pengelolaan akun mereka.
 FIGURE

13-4 BALANCED SCORECARD FOR ONLINE BANKING SYSTEM

Customer
Customer satisfaction with
convenient service
Complaints per 1,000 transactions

Internal Strategy: Learning

Time to process new account
application
Time spent processing retail
transaction
Time to solve customer problems
To lower operating costs
and improve profitability
of retail bank accounts by
moving customers to
electronic banking
Implementing new technology
Training for online customer
support

Financial
Accounts handled per full-time
employee
Profitability per account
Perbankan elektronik dilihat sebagai cara untuk mengatasi masalah ini. Jika tujuan strategis
adalah meningkatkan profitabilitas akun, indikator kinerja seperti jumlah akun yang dikelola
per karyawan tetap dan biaya per transaksi adalah tindakan 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 pada pro-posal
yang bersaing berdasarkan dampak strategisnya seperti yang dilihat dari berbagai perspektif.
Panitia akan menggunakan metrik ini untuk mengidentifikasi proposal yang diajukan ke fase
inisiasi proyek SDLC. Ini adalah keputusan utama pertama dalam siklus hidup sebuah proyek.
Jika panitia menyetujui proposal, maka proposal tersebut akan menjalani studi dan
pengembangan lebih lanjut. Jika proposal ditolak, maka tidak akan dipertimbangkan lagi dalam
periode anggaran saat ini.
Inisiasi Proyek

Inisiasi proyek melibatkan pemahaman rinci tentang masalah pengguna dan mengusulkan
beberapa solusi alternatif. Masing-masing proposal ini dinilai berdasarkan karakteristik
kelayakan dan biaya-manfaatnya. Pilihan yang dipilih pada langkah ini kemudian dilanjutkan
ke tahap pembuatan SDLC. Bergantung pada sifat proyek dan kebutuhan organisasi, sebuah
sistem memerlukan pengembangan in-house, paket komersial, atau keduanya. Pendekatan ini
diperiksa pada Bab 14.

Analisis Sistem

Analis sistem harus benar-benar memahami masalah bisnis sebelum dia dapat merumuskan
sebuah solusi. Analisis yang tidak lengkap atau cacat akan menyebabkan solusi yang tidak
lengkap atau rusak. Oleh karena itu, analisis sistem adalah fondasi untuk sisa SDLC. Analisis
sistem sebenarnya adalah proses dua langkah yang melibatkan survei awal sistem saat ini dan
kemudian analisis kebutuhan pengguna.

SURVEI LANGKAH

Sebagian besar sistem tidak dikembangkan dari awal. Biasanya, beberapa bentuk sistem
informasi dan prosedur terkait saat ini tersedia. Analis sering memulai analisis dengan
menentukan elemen apa, jika ada, dari sistem saat ini yang harus dipelihara sebagai bagian dari
sistem yang baru. Ini melibatkan survei sistem yang agak rinci. Fakta yang berkaitan dengan
pertanyaan awal tentang sistem dikumpulkan dan dianalisis. Sebagai analis memperoleh
pemahaman mendalam tentang masalah ini, dia mengembangkan pertanyaan yang lebih
spesifik sehingga lebih banyak fakta harus dikumpulkan. Proses ini bisa berlanjut melalui
beberapa iterasi. Ketika semua fakta yang relevan dikumpulkan dan dianalisis, analis datang
pada penilaian sistem saat ini. Survei sistem saat ini memiliki kelemahan dan keuntungan.

Kekurangan Survei Sistem Saat Ini

Mungkin argumen yang paling meyakinkan terhadap survei sistem saat ini berpusat pada
fenomena yang dikenal sebagai pit tar fisik saat ini.2 Ini adalah kecenderungan analis untuk
tersedot masuk dan kemudian terjebak oleh tugas untuk mensurvei sistem dinosaurus saat ini. .
Beberapa berpendapat bahwa survei sistem saat ini menghambat gagasan baru. Dengan
mempelajari dan memodelkan sistem lama, analis dapat mengembangkan gagasan terbatas
tentang bagaimana sistem baru seharusnya berfungsi. Hasilnya adalah sistem lama yang
diperbaiki daripada pendekatan yang baru secara radikal. Contohnya adalah implementasi
sistem ERP. Tugas untuk meninjau ulang prosedur organisasi saat ini tidak dapat dilakukan
karena penerapan ERP yang berhasil bergantung pada rekayasa ulang proses ini untuk
menerapkan praktik bisnis terbaik di industri ini.
Keuntungan dari Survei Sistem Saat Ini

Ada tiga keuntungan untuk mempelajari sistem saat ini. Pertama, ini adalah cara untuk
mengidentifikasi aspek sistem lama yang harus dijaga. Beberapa elemen sistem mungkin
berfungsi secara fungsional dan dapat memberikan fondasi bagi sistem yang baru. Dengan
sepenuhnya memahami sistem saat ini, analis dapat mengidentifikasi aspek-aspek yang layak
untuk diawetkan atau dimodifikasi untuk digunakan dalam sistem yang baru.

Kedua, ketika sistem baru diterapkan, pengguna harus melalui proses konversi dimana mereka
secara formal melepaskan diri dari sistem lama dan beralih ke yang baru. Analis harus
menentukan tugas, prosedur, dan data apa yang akan dihapus dengan sistem lama dan yang
akan terus berlanjut. Untuk menentukan prosedur konversi ini, analis harus tahu tidak hanya
apa yang harus dilakukan oleh sistem baru tapi juga apa yang dilakukan oleh yang lama. Hal ini
membutuhkan pemahaman menyeluruh tentang sistem yang ada.

Akhirnya, dengan mensurvei sistem saat ini, analis dapat menentukan secara meyakinkan
penyebab gejala masalah yang dilaporkan. Mungkin masalah akar bukanlah sistem informasi
sama sekali; Ini mungkin masalah manajemen atau karyawan yang bisa diselesaikan tanpa
mendesain ulang sistem informasi. Kita mungkin tidak dapat mengidentifikasi penyebab utama
masalah jika kita membuang sistem yang ada tanpa melakukan penyelidikan terhadap
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 umum berikut ini:

SUMBER DATA. Ini termasuk entitas eksternal, seperti pelanggan atau vendor, serta sumber
internal dari departemen lain.

PENGGUNA Ini termasuk manajer dan pengguna operasi.

DATA TOKO Toko 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.

ARUS DATA. Pergerakan dokumen dan laporan antara sumber data, penyimpanan data,
pemrosesan tugas, dan pengguna merupakan arus data.

KONTROL. Ini termasuk kontrol akuntansi dan operasional dan mungkin prosedur manual atau
kontrol komputer.

TRANSAKSI VOLUMES. Analis harus memperoleh ukuran volume transaksi untuk jangka
waktu tertentu. Banyak sistem diganti karena sudah mencapai kapasitasnya. Dengan mendasari
karakteristik volume transaksi suatu sistem dan tingkat pertumbuhannya merupakan elemen
penting dalam menilai kebutuhan kapasitas untuk sistem yang baru.

ERROR TARIF. Kesalahan transaksi terkait erat dengan volume transaksi. Seiring 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 SUMBER DAYA. Sumber daya yang digunakan sistem saat ini meliputi biaya tenaga
kerja, waktu komputer, bahan (misalnya faktur), dan biaya overhead langsung. Setiap biaya
sumber daya yang hilang saat sistem yang sekarang dieliminasi disebut biaya yang bisa
diangkut. Kemudian, ketika kita melakukan analisis biaya-manfaat, biaya yang dapat
diupayakan akan dianggap sebagai keuntungan dari sistem baru ini.
OPERASI BOTTLENECKS DAN REDUNDANT. Analis harus mencatat poin dimana arus
data berkumpul untuk membentuk kemacetan. Pada periode beban puncak, ini dapat
mengakibatkan penundaan dan meningkatkan kesalahan pemrosesan. Demikian juga,
penundaan mungkin disebabkan oleh operasi berlebihan, seperti pendekatan atau tanda-tanda
yang tidak perlu. Dengan mengidentifikasi area masalah ini selama tahap survei, analis dapat
menghindari kesalahan yang sama dalam perancangan sistem baru.

Teknik Pengumpulan Fakta

Analis sistem menggunakan beberapa teknik untuk mengumpulkan fakta yang sebelumnya
dikutip. Ini termasuk observasi, partisipasi tugas, wawancara pribadi, dan review dokumen
kunci.

PENGAMATAN. Observasi melibatkan pasif mengamati prosedur fisik sistem. Hal ini
memungkinkan analis untuk menentukan apa yang akan dilakukan, siapa yang melakukan
tugas, saat mereka melakukannya, bagaimana mereka melakukannya, mengapa mereka
melakukannya, dan berapa lama waktu yang dibutuhkan.

PARTISIPASI TUGAS Partisipasi adalah perpanjangan observasi, 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 mengerjakan meja penjualan yang tidak menerima pesanan dari
pelanggan dan menyiapkan pesanan penjualan. Analis dapat menentukan bahwa dokumen
dirancang dengan tidak semestinya, bahwa waktu yang tidak mencukupi untuk melakukan
prosedur yang dipersyaratkan, atau masalah beban puncak menyebabkan kemacetan dan
kesalahan pemrosesan. Dengan pengalaman langsung, analis sering bisa memberi lebih banyak
cara untuk melakukan tugas tersebut.
WAWANCARA PRIBADI Wawancara adalah metode penggalian fakta tentang sistem dan
persepsi pengguna saat ini mengenai persyaratan sistem baru. Instrumen yang digunakan untuk
mengumpulkan fakta ini mungkin merupakan pertanyaan terbuka atau kuesioner formal.

Pertanyaan terbuka memungkinkan pengguna untuk menguraikan masalah saat mereka

melihatnya dan menawarkan saran dan rekomendasi. Jawaban atas pertanyaan-pertanyaan ini
cenderung sulit untuk dianalisis, namun analis merasa merasa berada dalam lingkup masalah.
Analis dalam jenis wawancara ini pastilah pendengar yang baik dan mampu memusatkan
perhatian pada fakta penting. Contoh pertanyaan terbuka adalah: '' Menurut Anda, apa
masalahnya dengan sistem pesanan penjualan kita? '' Dan 'Bagaimana sistem bisa diperbaiki?' '

Kuesioner digunakan untuk mengajukan pertanyaan spesifik dan terperinci dan untuk
membatasi tanggapan pengguna. Ini adalah teknik yang bagus untuk mengumpulkan fakta
obyektif tentang sifat prosedur spesifik, volume transaksi yang diproses, sumber data, pengguna
laporan, dan masalah kontrol.

TINJAUAN DOKUMEN UTAMA. Dokumen organisasi adalah sumber fakta lain tentang
sistem yang disurvei. Contohnya meliputi:

Bagan organisasi Uraian pekerjaan

Catatan Akuntansi Bagan akun Pernyataan kebijakan

Deskripsi prosedur Laporan keuangan

Laporan kinerja Diagram alir sistem Dokumen sumber Kalender transaksi Anggaran

Perkiraan

Pernyataan misi

Setelah fase pengumpulan fakta, analis secara formal mendokumentasikan kesan dan
pemahamannya tentang sistem tersebut. Ini akan berupa wesel, diagram alir sistem, dan
berbagai tingkat aliran data diagram.

ANALISIS LANGKAH

Analisis sistem adalah proses intelektual yang digabungkan dengan pengumpulan fakta.
Analisnya simulta-menganalisa dengan saksama saat dia mengumpulkan fakta. Pengakuan atas
suatu masalah menganggap beberapa prinsip norma atau keadaan yang dikehendaki. Oleh
karena itu, sulit untuk mengidentifikasi di mana survei berakhir dan analisis dimulai.

Laporan Analisis Sistem

Acara yang menandai berakhirnya tahap analisis sistem adalah penyusunan laporan analisis
sistem formal. Laporan ini menyajikan manajemen atau komite pengarah dengan temuan
survei, masalah yang diidentifikasi dengan sistem saat ini, kebutuhan pengguna, dan
persyaratan sistem baru. Gambar 13-5 berisi format yang mungkin untuk laporan ini.

Tujuan utama untuk melakukan analisis sistem adalah untuk mengidentifikasi kebutuhan
pengguna dan menentukan persyaratan untuk sistem yang baru. Laporan tersebut harus
menjelaskan secara rinci apa yang harus dilakukan sistem daripada bagaimana melakukannya.

FIGURE

13-5 OUTLINE OF MAIN TOPICS IN A SYSTEMS ANALYSIS REPORT

Systems Analysis Report

Reasons for System Analysis

Reasons specified in the system project proposal
Changes in reasons since analysis began
Additional reasons

Scope of Study
Scope as specified by the project proposal
Changes in scope

Problems Identified with Current System

Techniques used for gathering facts
Problems encountered in the fact-gathering process
Analysis of facts

IV. Statement of User Requirements

Specific user needs in key areas, such as:
Output requirements
Transaction volumes
Response time
Nontechnical terms for a broad-based audience, including:
End users
User management
Systems management
Steering committee

V. Resource Implications
Preliminary assessment of economic effect
Is economic feasibility as stated in proposal reasonable?

VI. Recommendations
Should the project continue?
Has analysis changed feasibility, strategic impact, or
priority of the project?
Pernyataan persyaratan dalam laporan tersebut menetapkan pemahaman antara profesional sistem, manajemen, Struktur catatan
pengguna, dan pemangku kepentingan lainnya. Dokumen ini merupakan kontrak formal yang menentukan tujuan database Rincian
dan sasaran sistem. Laporan analisis sistem harus menetapkan secara jelas sumber data, pengguna, file data, proses pengolahan.
umum, arus data, kontrol, dan kapasitas volume transaksi.
Teknik
Laporan analisis sistem tidak menentukan perancangan rinci dari sistem yang diusulkan. Misalnya, tidak pengendalian
menentukan metode pengolahan, media penyimpanan, struktur rekam, dan rincian lainnya yang diperlukan untuk khusus.
merancang sistem fisik. Sebaliknya, laporan tetap pada tingkat tujuan untuk menghindari penempatan batasan
buatan pada fase desain konseptual. Beberapa kemungkinan desain dapat melayani kebutuhan pengguna, dan Format untuk layar
proses pengembangan harus bebas untuk mengeksplorasi semua ini. masukan dan
dokumen sumber.
Konseptualisasi Desain Alternatif Format laporan
output
Tujuan fase konseptualisasi adalah untuk menghasilkan beberapa alternatif solusi konseptual yang memenuhi
persyaratan sistem yang diidentifikasi selama analisis sistem. Dengan menghadirkan pengguna dengan sejumlah Namun desainnya
alternatif yang masuk akal, tim proyek menghindari penerapan kendala yang telah terbentuk sebelumnya ke sistem memiliki detail
yang baru. Desain alternatif ini kemudian masuk ke tahap pemilihan sistem, di mana biaya dan manfaat masing- yang cukup untuk
masing dibandingkan dan satu desain optimum dipilih untuk konstruksi. menunjukkan
bagaimana kedua
BAGAIMANA RANCANGAN DETAIL DAPAT DIPERLUKAN? sistem tersebut
secara konseptual
Fase desain konseptual harus menyoroti perbedaan antara fitur kritis dari sistim yang bersaing daripada berbeda dalam
persamaannya. Oleh karena itu, perancangan sistem pada saat ini harus bersifat umum. Desain harus fungsinya. Sebagai
mengidentifikasi semua input, output, proses, dan fitur khusus yang diperlukan untuk membedakan satu alternatif ilustrasi, mari kita
dari yang lain. Dalam beberapa kasus, ini dapat dicapai pada tingkat diagram konteks. Dalam situasi di mana periksa fitur umum
perbedaan penting antara sistem tidak kentara, desain mungkin perlu ditunjukkan oleh diagram alir data tingkat masing-masing
rendah (DFD) dan bahkan dengan diagram struktur. Namun, diagram DFD dan struktur rinci lebih umum sistem.
digunakan pada fase desain rinci SDLC. Kita akan membahas transisi dari DFD rinci ke diagram struktur pada
Bab 14. Opsi A adalah
sistem pembelian
Gambar 13-6 menyajikan dua desain konseptual alternatif untuk sistem pembelian. Desain ini kurang detail yang batch tradisional.
dibutuhkan untuk mengimplementasikan sistem. Misalnya, mereka tidak menyertakan komponen penting seperti: Masukan awal
untuk proses ini
adalah pembelian req-uisition dari inventory control. Ketika persediaan mencapai titik pemesanan ulang yang telah
ditentukan sebelumnya, inventaris baru dipesan sesuai dengan jumlah pesanan ekonomi mereka. Pengiriman
pesanan pembelian ke pemasok dilakukan sekali sehari melalui surat A.S.

Sebaliknya, Option B menggunakan teknologi electronic data interchange (EDI). Pemicu sistem ini adalah
permintaan pembelian dari perencanaan produksi. Sistem pembelian menentukan kuantitas dan vendor dan
kemudian mentransmisikan pesanan secara online melalui perangkat lunak EDI ke vendor.

Kedua alternatif tersebut memiliki pro dan kontra. Manfaat dari Opsi A adalah kesederhanaan disain, kemudahan
penerapan, dan rendahnya permintaan akan sumber daya sistem daripada Opsi B. Aspek negatif dari Opsi A adalah
bahwa perusahaan memerlukan persediaan. Di sisi lain, Opsi B memungkinkan perusahaan mengurangi atau
bahkan menghilangkan persediaan. Manfaat ini datang dengan biaya sumber ulang sistem yang lebih mahal dan
canggih. Ini adalah prematur, pada saat ini, untuk mencoba mengevaluasi manfaat relatif dari alternatif ini. Hal ini
dilakukan secara formal di fase berikutnya dari SDLC. Pada titik ini, perancang sistem hanya peduli dengan
identifikasi desain alternatif yang masuk akal.
 588
FIGURE
ALTERNATIVE CONCEPTUAL DESIGNS FOR A PURCHASING SYSTEM
13-6

PAR T I V
Option A, Batch System
Inventory Vendor
Records Data

Systems Development Activities

Batches of Batches of
Purchase Purchase Daily Pick-up Delivered by
Requisitions Orders by U.S. Mail U.S. Mail
Inventory Purchasing Mail U.S. Mail Vendor
Control Process Room
Process Process

Option B, EDI System

Bill of Vendor
Materials Data

Customer Purchase Electronic Electronic Electronic

Orders Requisitions Purchase Order Transaction Sales Orders
Vendor's
Customer Production Purchasing EDI System Vendor's
Order
Planning Process EDI System
Processing
System
Evaluasi dan Seleksi Sistem

Fase ini di SDLC adalah mekanisme formal untuk memilih satu sistem dari serangkaian desain
konseptual alternatif yang akan digunakan untuk konstruksi. Tahap evaluasi dan pemilihan
sistem merupakan proses optimasi yang bertujuan untuk mengidentifikasi sistem yang terbaik.
Keputusan ini merupakan titik kritis di SDLC. Pada titik ini, ada banyak ketidakpastian tentang
sistem ini, dan keputusan yang buruk bisa menjadi bencana. Tujuan dari prosedur evaluasi dan
seleksi formal adalah menyusun proses pengambilan keputusan ini dan dengan demikian
mengurangi ketidakpastian dan risiko membuat keputusan yang buruk.

Tidak ada rumus ajaib untuk memastikan keputusan yang bagus. Akhirnya, keputusan tersebut
diturunkan ke penilaian pengelolaan. Tujuannya adalah untuk menyediakan sarana dimana
manajemen dapat membuat penilaian yang tepat. Proses seleksi ini melibatkan dua langkah:

Lakukan studi kelayakan terperinci.

Lakukan analisis biaya-manfaat.

Hasil evaluasi tersebut kemudian dilaporkan secara formal ke panitia kemudi untuk pemilihan
sistem akhir.

PERFORM A STUDI KELAYAKAN Rinci

Kami memulai proses pemilihan sistem dengan memeriksa kembali faktor kelayakan yang
dievaluasi secara pre-liminary sebagai bagian dari proposal sistem. Awalnya, nilai yang
diberikan pada faktor-faktor ini sebagian besar didasarkan pada penilaian dan intuisi
profesional sistem. Sekarang fitur sistem spesifik telah dikonseptualisasikan, perancang
memiliki gambaran yang lebih jelas mengenai faktor-faktor ini. Juga, pada tahap proposal,
faktor-faktor ini dievaluasi untuk keseluruhan proyek. Sekarang mereka dievaluasi untuk setiap
desain konseptual alternatif.

Evaluator Informasi harus melakukan studi kelayakan rinci. Objektivitas sangat penting untuk
penilaian yang adil terhadap setiap desain. Kelompok ini harus terdiri dari manajer proyek,
perwakilan pengguna, dan profesional sistem yang memiliki keahlian di bidang spesifik yang
studi kelayakannya mencakup. Selain itu, untuk alasan audit operasional, kelompok tersebut
harus memiliki anggota staf audit internal. Faktor kelayakan yang diperkenalkan pada bagian
sebelumnya memberikan kerangka kerja untuk mengidentifikasi masalah utama yang harus
dipertimbangkan evaluator.

Kelayakan teknis

Dalam mengevaluasi kelayakan teknis, teknologi yang mapan dan dipahami mewakili risiko
lebih kecil daripada yang tidak diketahui. Jika perancangan sistem memerlukan teknologi yang
mapan, nilai kelayakannya akan tinggi, katakanlah 9 atau 10. Penggunaan teknologi yang baru
(rilis pertama) dan yang tidak familiar dengan profesional sistem yang harus menginstal dan
merawatnya, atau itu adalah hibrida dari beberapa produk vendor, adalah pilihan yang lebih
berisiko. Bergantung pada jumlah dan kombinasi faktor risiko, nilai kelayakan untuk teknologi
tersebut akan lebih rendah.

Kelayakan Hukum

Dalam sistem pemrosesan transaksi keuangan, legalitas sistem selalu menjadi masalah. Namun,
legalitas juga menjadi masalah bagi sistem non finansial yang memproses data sensitif, seperti
catatan pasien rumah sakit atau peringkat kredit pribadi. Desain sistem yang berbeda mungkin
mewakili tingkat risiko yang berbeda saat berhadapan dengan data semacam itu. Penilai harus
memperhatikan bahwa desain konseptual mengenali masalah kontrol kritis, secu-rity, dan audit
trail dan bahwa sistem tersebut tidak melanggar undang-undang yang berkaitan dengan hak
privasi dan / atau penggunaan dan penyaluran informasi.

Kelayakan Operasional

Ketersediaan pengguna yang terlatih, termotivasi, dan berpengalaman merupakan isu utama
dalam mengevaluasi kelayakan operasinya sebuah desain. Jika pengguna tidak memiliki atribut
ini, pindah ke lingkungan yang sangat teknis mungkin berisiko dan akan memerlukan pelatihan
ulang yang ekstensif. Hal ini juga dapat mempengaruhi kelayakan ekonomi sistem. Di sisi lain,
komunitas pengguna yang merasa nyaman dengan teknologi lebih cenderung melakukan
transisi yang mulus ke sistem teknologi maju. Nilai kelayakan operasional masing-masing
desain alternatif harus mencerminkan kemudahan yang diharapkan dari transisi ini.
Jadwalkan Kelayakan

Pada tahap ini, evaluator sistem berada pada posisi yang lebih baik untuk menilai kemungkinan
sistem akan selesai sesuai jadwal. Platform teknologi, perancangan sistem, dan kebutuhan akan
pelatihan pengguna dapat mempengaruhi jadwal semula. Teknologi pengembangan sistem yang
digunakan adalah pengaruh lain. Penggunaan perangkat lunak rekayasa perangkat lunak
komputer (CASE) dan alat prototip (dibahas di Bab 14) dapat secara signifikan mengurangi
waktu pengembangan dari setiap pilihan disain sistem.

Kelayakan ekonomi

Studi kelayakan ekonomi awal terbatas untuk menilai komitmen keuangan manajemen terhadap
keseluruhan proyek. Ini masih merupakan isu yang relevan. Apakah iklim ekonomi telah
berubah sejak studi pendahuluan atau apakah satu atau lebih dari desain bersaing tidak
memiliki suport manajemen sekarang harus ditentukan.

Studi kelayakan awal dapat menentukan biaya proyek hanya dalam istilah umum. Sekarang
setiap desain bersaing telah dikonseptualisasikan dan dinyatakan dalam bentuk fitur dan
prosesnya yang unik, perancang dapat lebih tepat dalam perkiraan biaya masing-masing
alternatif. Studi kelayakan ekonomi sekarang dapat dilakukan selangkah lebih maju dengan
melakukan analisis biaya-manfaat.

PERFORM BIAYA MANFAAT BIAYA

Analisis biaya-manfaat membantu manajemen menentukan apakah (dan seberapa banyak)

manfaat yang diterima dari sistem yang diusulkan akan lebih besar daripada biaya yang
dikeluarkannya. Teknik ini sering digunakan untuk memperkirakan nilai finansial investasi
bisnis yang diharapkan. Namun, dalam kasus ini, investasi adalah sistem informasi, dan biaya
dan tunjangan lebih sulit untuk diidentifikasi dan diukur daripada jenis proyek modal lainnya.
Meskipun tidak sempurna dalam pengaturan ini, analisis biaya-manfaat digunakan karena
simfisitasnya dan tidak adanya alternatif yang jelas lebih baik. Terlepas dari keterbatasannya,
analisis biaya-manfaat, digabungkan dengan faktor kelayakan, adalah alat yang berguna untuk
membandingkan rancangan sistem pesaing.

Ada tiga langkah dalam penerapan analisis biaya-manfaat: mengidentifikasi biaya,

mengidentifikasi manfaat, dan membandingkan biaya dan manfaat.

Mengidentifikasi Biaya

Salah satu metode untuk mengidentifikasi biaya adalah membaginya menjadi dua kategori:
biaya satu kali dan biaya berulang. Biaya satu kali mencakup investasi awal untuk
mengembangkan dan menerapkan sistem. Biaya berulang termasuk biaya operasi dan
pemeliharaan yang kambuh sepanjang umur sistem. Tabel 13-2 menunjukkan break-down biaya
satu kali dan berulang yang khas.

Satu kali biaya

AKUISISI HARDWARE Ini termasuk biaya server mainframe, PC, dan peralatan periferal,
seperti jaringan dan paket disk. Angka biaya barang bisa didapat dari vendor.

PERSIAPAN SITUS. Ini melibatkan biaya yang sering diabaikan seperti modifikasi bangunan,
misalnya menambahkan AC atau membuat perubahan struktural; instalasi peralatan, yang
mungkin termasuk penggunaan alat berat; dan biaya pengiriman Perkiraan biaya ini bisa
didapat dari vendor dan subkontraktor yang melakukan instalasi.

PERANGKAT LUNAK PERANGKAT LUNAK. Biaya ini berlaku untuk semua perangkat
lunak yang dibeli untuk sistem yang diusulkan, termasuk perangkat lunak sistem operasi, jika
tidak digabungkan dengan perangkat keras; perangkat lunak kontrol jaringan; dan aplikasi
komersial, seperti paket akuntansi. Perkiraan biaya ini bisa didapat dari vendor.

DESAIN SISTEM Ini adalah biaya yang dibutuhkan oleh profesional sistem dalam melakukan
perencanaan, analisis, dan fungsi perancangan. Secara teknis, biaya yang terjadi sampai saat ini
tenggelam dan tidak relevan dengan keputusan tersebut. Analis harus memperkirakan hanya
biaya yang dibutuhkan untuk menyelesaikan desain rinci.