Analisis Kebutuhan Sistem Informasi PDF

Sistem Informasi BAB III ANALISIS KEBUTUHAN SISTEM INFORMASI 3.1. Uraian Materi Kebutuhan untuk suatu sistem adalah deskripsi tentang apa yang harus dilakukan sistem, layanan yang disediakannya, dan batasan operasinya. Kebutuhan ini mencerminkan kebutuhan pelanggan untuk si...

Sistem Informasi BAB III ANALISIS KEBUTUHAN SISTEM INFORMASI 3.1. Uraian Materi Kebutuhan untuk suatu sistem adalah deskripsi tentang apa yang harus dilakukan sistem, layanan yang disediakannya, dan batasan operasinya. Kebutuhan ini mencerminkan kebutuhan pelanggan untuk sistem yang melayani tujuan tertentu seperti mengendalikan perangkat, menempatkan pesanan, atau mencari informasi. Proses menemukan, menganalisis, mendokumentasikan, dan memeriksa layanan dan kendala ini disebut analisis kebutuhan (Sommerville, 2011). Analisis kebutuhan sistem merupakan proses awal dalam tahapan pembangunan atau perbaikan sistem. Dan inti dari proses ini adalah bagaimana mengelola kebutuhan secara efektif akan pembangunan atau perbaikan sistem yang diharapkan (effective requirements management). Jika pengelolaan requirements ini tidak efektif maka risiko kegagalan pembangunan atau perbaikan sistem sangat tinggi. a. Analisis Permasalahan Ketika lingkungan pengembangan aplikasi atau sistem informasi semakin produktif, tentunya semakin lebih mudah untuk mengembangkan sistem yang dapat memenuhi kebutuhan bisnis user. Namun, dalam fakta yang telah disampaikan ternyata kita masih berhadapan dengan tantangan untuk dapat memahami dan memenuhi kebutuhan sistem sebenarnya. “Problem behind the problem” atau bisa juga disebut akar permasalahan adalah permasalahan kita yang sebenarnya. Kebanyakan pengembang hanya menyisihkan waktu sangat pendek untuk memahami masalah bisnis sebenarnya, kebutuhan user dan stakeholder, dan lingkungan dimana aplikasi dikembangkan. Sebaliknya, developers lebih cenderung fokus pada penyediaan solusi teknologi dengan pemahaman yang minim terhadap masalah yang akan dipecahkan. 22 Sistem Informasi Oleh karena itu, pemahaman terhadap akar permasalahan adalah kunci sukses seorang analis dalam menganalisis masalah, yakni memahami masalah bisnis sebenarnya, kebutuhan user dan stakeholder, dan mengusulkan solusi yang sesuai dengan kebutuhan tersebut. Setelah analis melakukan analisis masalah dengan baik, kemungkinan solusi sederhana dapat diterapkan misal dengan bypass masalah yang disebabkan oleh suatu proses tanpa harus memperbaiki proses tersebut atau dengan memperbaiki proses bisnis saja dan bukan membangun sistem yang baru. Ketika analis berhadapan dengan problem solving baik sederhana maupun kompleks, analis harus memahami tujuan terlebih dahulu. Tujuan dalam analisis masalah adalah memahami masalah yang akan diselesaikan sebelum memulai pengembangan. Salah satu cara sederhana untuk mendapatkan persetujuan adalah menulis masalah dan mendapatkan persetujuan masalah tersebut. Akan sangat membantu jika ada pemahaman terhadap manfaat dari solusi yang diusulkan bagi user. Melihat manfaat dari kacamata user akan sangat membantu memahami pandangan stakeholder terhadap masalah itu sendiri. Setelah memahami masalah besar sistem, maka analis harus memahami penyebab dari masalah itu dengan berbagai macam teknik. Salah satu teknik yang bisa dilakukan adalah analisis akar masalah (root cause analysis), yaitu cara sistematis dalam mengurai akar masalah dari masalah yang sudah teridentifikasi atau gejala masalah. Jika semua akar masalah berhasil diidentifikasi dan kita mendapatkan seberapa sering akar masalah tersebut muncul, maka cukup bagi analis untuk fokus pada akar masalah yang sering ditemukan tersebut. b. Identifikasi Kebutuhan Pengguna Memahami kebutuhan user dan stakeholder adalah kunci sukses pengembangan solusi yang efektif. Langkah awal sebelum melakukan identifikasi kebutuhan adalah melakukan identifikasi user dan stakeholder. 23 Sistem Informasi Identifikasi user maupun stakeholder ini akan sangat membantu analis dalam mendapatkan berbagai macam perspektif terhadap masalah dan kebutuhan akan solusinya. Jika ingin lebih maksimal lagi solusi yang diharapkan, diperlukan identifikasi non-user stakeholder, yaitu stakeholder yang hanya terpengaruh oleh outcome dari sistem. Hasil identifikasi pengguna berupa daftar profil masing-masing pengguna seperti pada Tabel 3.1. Tabel 3.1. Contoh Profil Pengguna Ada beberapa teknik yang bisa digunakan untuk mengidentifikasi kebutuhan pengguna, baik yang sederhana atau sulit, mahal dan sangat teknis, antara lain Direct Observation (DILO:day in the life of), wawancara, brainstorming/curah pendapat, Focus Group Discussion (FGD), kuesioner, dan sebagainya. Tidak ada satu teknik yang sempurna di setiap kasus. Oleh karena itu, penggunaan berbagai macam teknik akan dapat memperkaya pemahaman seorang analis terhadap masalah yang dihadapi. Beberapa sindrom yang sering ditemui pada penggalian kebutuhan dari stakeholder dapat dilihat pada Tabel 3.2. 24 Sistem Informasi Tabel 3.2. Sindrom Pengguna dan Pengembang Sistem Pemahaman yang lebih baik tentang sistem dapat dicapai jika dan hanya jika analis memahami dengan benar “needs” user atau stakeholder. Pemahaman ini akan menjadi rujukan untuk dapat mengambil keputusan yang lebih baik dalam definisi dan implementasi sistem. Meskipun, dalam kebanyakan hal “needs” dari user tidak jelas atau samar atau bahkan rancu, tetapi pernyataan tersebut menjadi sangat penting bagi langkah berikutnya. Sebagai contoh “Saya ingin cara mudah untuk mengetahui inventori saya”, “Saya ingin ada peningkatan produktivitas lebih pada layanan penjualan saya”, dll. Jadi, “needs” adalah refleksi bisnis, personal, atau masalah/peluang operasional yang ditujukan untuk pertimbangan, pembelian atau penggunaan sistem yang baru. Menariknya, ketika kita mau melangkah ke proses berikutnya untuk identifikasi fitur dari sistem yang dapat menjawab “needs” user, sering dijumpai bahwa kita sudah mendapat jawaban fitur sistem tersebut dari user. User atau stakeholder sudah menerjemahkan kebutuhannya (needs) ke perilaku sistem yang diyakini dapat memecahkan kebutuhan riil mereka (real needs). “Saya ingin... “ telah diterjemahkan menjadi “Yang saya pikirkan adalah sistem yang dapat menjawab... atau sistem yang bisa...” Hal ini tidak menjadi masalah, karena user selalu berbicara pengalaman praktisnya dalam bahasa 25 Sistem Informasi sehari-hari. Artinya bahwa hubungan antara kebutuhan dan fitur sangat erat sekali. Fitur adalah cara mudah dan praktis untuk menggambarkan fungsionalitas sistem tanpa harus menyampaikan secara rinci. Fitur adalah layanan yang sistem sediakan untuk memenuhi satu atau lebih kebutuhan stakeholder (stakeholder needs). Beberapa contoh lain fitur suatu sistem adalah, kontrol pintu manual ketika terjadi kebakaran pada sistem kontrol lift, penyediaan status yang up to date dari seluruh barang di inventori pada sistem kontrol inventori, dll. Hasil identifikasi kebutuhan pengguna berupa penjelasan lingkungan pengguna dan tabel penilaian terhadap masalah berdasarkan kriteria disertai bukti metode pengumpulannya seperti hasil observasi, wawancara, brainstorming, FGD, atau kuesioner. Beberapa pertanyaan dapat digunakan untuk membantu menjelaskan lingkungan pengguna seperti Siapa saja penggunanya? Apa latar belakang pendidikan dan bagaimana pemahaman tentang TI pengguna? Apakah pengguna berpengalaman dengan jenis aplikasi ini? Platform mana yang digunakan? Apa rencana untuk platform masa depan? Aplikasi tambahan apa yang digunakan yang perlu dihubungkan? Apa harapan untuk kegunaan sistem? Apa harapan untuk waktu pelatihan? Apa jenis dokumentasi online atau hardcopy yang dibutuhkan? Contoh tabel penilaian masalah dapat dilihat pada Tabel 3.3. Tabel 3.3. Contoh Tabel Penilaian Masalah Dampak Solusi Solusi yang Permasalahan Penyebab Mempengaruhi Prioritas Masalah Saat Ini Diusulkan Perkembangan Belum ada Proyek Project Manager Menanyaka Membangun Tinggi proyek sulit pemberitahuan terlambat n status Sistem dimonitor status setiap jika ada task secara Manajemen task dalam task yang manual Proyek yang proyek terlambat melalui disertai fitur WhatsApp notifikasi … … … … … … … 26 Sistem Informasi c. Pendefinisian Solusi Pemodelan solusi sistem ini merujuk pada requirement yang didapatkan dari hasil analisis menggunakan alat/tools yang dipakai, seluruh requirement kemudian dijelaskan dalam model yang lebih spesifik. Semakin banyaknya requirements yang harus didokumentasikan akan semakin susah untuk mengelolanya. Oleh karena itu, kemampuan dalam mengorganisasi requirements yang sudah diidentifikasi menjadi mutlak diperlukan. Salah satu cara yang dapat digunakan untuk organisasi sistem/software requirements adalah dengan visualisasi seperti diagram pohon pada Gambar 3.1. Gambar 3.1. Diagram Pohon System Requirement Setelah tahapan menetapkan strategi mengelola requirements yang telah diidentifikasi, maka tahapan terpenting selanjutnya adalah mengawal dokumen ini terhadap perubahan yang akan terjadi saat pengembangan. 1. Cakupan Sistem Ketika pernyataan masalah telah disetujui dan user/stakeholder sudah teridentifikasi, langkah selanjutnya adalah mendefinisikan sistem dimana 27 Sistem Informasi masalah itu berada. Dua hal penting yang tidak boleh dilupakan adalah setelah memahami masalah maka langkah berikutnya adalah mempertimbangkan solusi potensial terhadap masalah tersebut. Sekarang kita memasuki masa transisi di antara dua hal tersebut, yakni menentukan cakupan dari sistem solusi. Dalam kebanyakan kasus, cakupan sistem sangat jelas. Namun, jika sistem semakin kompleks (seperti misalnya banyak terkait dengan sistem yang lain) maka cakupan sistem menjadi tidak begitu jelas. Analis sistem harus menentukan apakah data dibagikan pada beberapa aplikasi, apakah aplikasi baru terdistribusi ke beberapa komputer klien yang lain, dan siapa pengguna. Pendekatan systemic thinking juga sangat membantu dalam menentukan cakupan sistem solusi. Bagaimana menentukan cakupan? Berikut pertanyaan yang dapat membantu untuk ini: Siapa yang akan memasok, menggunakan, atau menghapus informasi dari sistem? Siapa yang akan mengoperasikan sistem? Siapa yang akan melakukan pemeliharaan sistem? Di mana sistem akan digunakan? Dari mana sistem mendapatkan informasinya? Sistem eksternal apa lagi yang akan berinteraksi dengan sistem? 2. Batasan Sistem Sebelum masuk ke tahapan berikutnya dalam pengembangan sistem, analis perlu mempertimbangkan constraint atau batasan dari solusi yang akan dibangun. Segala macam sumber batasan harus dipertimbangkan. Diantaranya, jadwal, ROI, anggaran untuk peralatan dan SDM, isu lingkungan, OS, database, sistem komputer yang ada, isu teknis, isu politik, dan sebagainya. Beberapa contoh hal yang harus diperhatikan terkait batasan sistem adalah sebagai berikut. 28 Sistem Informasi Gambar 3.2. Pertimbangan Batasan Sistem Jika requirements yang nantinya harus dijawab sudah ditentukan, maka seberapa banyak sumber daya yang dikerahkan akan mempengaruhi seberapa pendek waktu yang diperlukan. Semakin banyak sumber daya yang dikerahkan untuk menjawab user needs/requirements maka semakin pendek waktu yang diperlukan untuk menyelesaikannya. Namun, yang perlu dicatat disini adalah bahwa ketika anda bertemu pada masalah keterlambatan proyek, penambahan sumber daya justru akan semakin memperlambat tercapainya tujuan proyek (Brooks’ law). 29 Sistem Informasi Langkah awal untuk menentukan ruang lingkup proyek adalah dengan menetapkan high-level requirements baseline. Salah satu strategi untuk menetapkan high-level requirements baseline adalah dengan menggunakan teknik penentuan prioritas requirements. Dengan menggunakan skala critical- important-useful, analis dapat menentukan prioritas requirements yang harus dipenuhi. Selain atribut untuk prioritas, analis juga bisa memberikan atribut yang terkait dengan effort dan risiko yang berhubungan dengan features/requirements sistem. Jika, analis mampu memberikan penilaian pada atribut effort dan risiko, maka untuk requirements yang critical diperlukan strategi yang sesuai dengan nilai atribut effort dan risiko. Setelah ruang lingkup berhasil didefinisikan, tantangan terberat berikutnya adalah bagaimana mengelolanya. Kemampuan seorang analis dalam merangkul user/stakeholder menjadi kunci di sini. Selain itu, kemampuan negosiasi, penerapan strategi komunikasi yang efektif, dan kecerdasan politis juga menjadi komoditas utama bagi seorang analis. d. Alat Bantu Analisis 1. Analisis Permasalahan Kegiatan identifikasi masalah adalah bagian dari proses pemecahan masalah yang idealnya harus jelas prosesnya mulai dari definisi masalah serta membedakan antara akar penyebab masalah, gejala dan efek. Definisi masalah adalah titik awal dari identifikasi masalah. Definisi masalah terdiri dari dua bagian, yaitu definisi awal masalah yang merupakan bagian awal dari kegiatan dengan menggunakan tool kerangka PIECES, kemudian masuk ke “pembedahan” masalah secara lebih rinci, membahas submasalah dan aspek-aspek yang relevan dengan masalah. Penggunaan Pohon Masalah, Pohon Hipotesis, dan Pohon Isu dapat digunakan untuk membantu proses kegiatan “pembedahan” masalah. Bahan utama 30 Sistem Informasi dalam mengidentifikasi masalah bisa berupa Business Process Diagram atau SOP (Standard Operating Procedure) di satuan organisasi. a) Kerangka PIECES Berikut adalah kerangka untuk identifikasi masalah, kesempatan atau peluang, dan perintah, yang dikenal dengan kerangka PIECES Wetherbe. P kebutuhan untuk mengoreksi atau memperbaiki performance I kebutuhan untuk mengoreksi atau memperbaiki information E kebutuhan untuk mengoreksi atau memperbaiki economics, mengendalikan biaya, atau meningkatkan keuntungan C kebutuhan untuk mengoreksi atau memperbaiki Control atau keamanan E kebutuhan untuk mengoreksi atau memperbaiki Efficiency orang, mesin (komputer) dan proses S kebutuhan untuk mengoreksi atau memperbaiki Services/layanan ke pelanggan, pemasok, rekan kerja, karyawan, dan lain-lain. Lebih lengkapnya dapat diuraikan sebagai berikut: 1) Performance (kinerja), peningkatan terhadap kinerja (hasil kerja) sistem yang baru sehingga menjadi lebih efektif. Kinerja dapat diukur dari throughput dan response time. Throughput adalah jumlah dari pekerjaan yang dapat dilakukan suatu saat tertentu. Response time adalah waktu yang dibutuhkan untuk menanggapi suatu perkerjaan. i. Produksi – jumlah kerja selama periode waktu tertentu ii. Waktu respons – penundaan rata-rata antara transaksi atau permintaan dengan respons ke transaksi atau permintaan tesebut. 2) Information (informasi), peningkatan terhadap kualitas informasi yang disajikan i. Output 31 Sistem Informasi Kurangnya informasi yang relevan Terlalu banyak informasi – “kelebihan informasi” Informasi yang tidak dalam format yang berguna Informasi yang tidak akurat Informasi yang tidak tepat waktunya untuk penggunaan selanjutnya ii. Input Data tidak ditangkap pada waktunya Data tidak ditangkap secara akurat – terdapat error Data sulit ditangkap Data ditangkap secara berlebihan – data yang sama ditangkap lebih dari sekali iii. Data Tersimpan Data disimpan secara berlebihan dalam banyak file dan/atau database Integrasi data yang jelek Data tersimpan tidak akurat Data tidak aman dari kecelakaan atau vandalisme Data tidak diorganisasikan dengan baik Data tidak fleksibel – tidak mudah untuk memenuhi kebutuhan informasi baru dari data tersimpan. Data tidak dapat diakses 3) Economy (ekonomis), peningkatan terhadap manfaat-manfaat atau keuntungan-keuntungan atau penurunan-penurunan biaya yang terjadi i. Biaya Biaya tidak diketahui Biaya tidak dapat dilacak ke sumber Biaya terlalu tinggi ii. Keuntungan 32 Sistem Informasi Profit yang didapat Pangsa pasar baru 4) Control (pengendalian), peningkatan terhadap pengendalian untuk mendeteksi dan memperbaiki kesalahan-kesalahan serta kecurangan-kecurangan yang dan akan terjadi i. Keamanan atau kontrol terlalu lemah Input data tidak diedit dengan cukup Kejahatan (misalnya, penggelapan atau pencurian) terhadap data Etika dilanggar pada data atau informasi – mengacu pada data atau informasi yang mencapai orang-orang yang tidak mempunyai wewenang Data tersimpan secara berlebihan tidak konsisten dalam file atau database yang berbeda Peraturan atau panduan privasi data dilanggar (atau dapat dilanggar) Error pemrosesan terjadi (oleh manusia, mesin atau perangkat lunak) Error pembuatan keputusan ii. Kontrol atau keamanan berlebihan Prosedur birokratis memperlambat sistem Pengendalian mengganggu para pelanggan atau karyawan Pengendalian berlebihan menyebabkan penundaan pemrosesan 5) Efficiency (efisiensi), peningkatan terhadap efisiensi operasi. Efisiensi berbeda dengan ekonomis. Bila ekonomis berhubungan dengan jumlah sumber daya yang digunakan, efisiensi berhubungan dengan bagaimana sumber daya tersebut digunakan dengan pemborosan yang paling minimum. Efisiensi dapat diukur dari output dibagi dengan input. 33 Sistem Informasi i. Orang, mesin atau komputer ii. Usaha yang dibutuhkan untuk tugas-tugas terlalu berlebihan iii. Material yang dibutuhkan untuk tugas-tugas terlalu berlebihan 6) Services (pelayanan), peningkatan terhadap pelayanan yang diberikan oleh sistem i. Sistem menghasilkan produk yang tidak akurat ii. Sistem menghasilkan produk yang tidak konsisten iii. Sistem menghasilkan produk yang tidak dapat dipercaya iv. Sistem tidak mudah dipelajari v. Sistem tidak mudah digunakan vi. Sistem tidak kompatibel Semua komponen dari PIECES harus teridentifikasi dengan jelas sehingga definisi permasalahan awal sudah clear dan telah disepakati bersama. Hasil dari analisis berupa pernyataan masalah yang narasinya merupakan pernyataan negatif, misalnya: kurangnya, lambatnya, mahalnya, belum optimalnya, dan lain-lain. b) Diagram Fishbone Diagram Fishbone atau Diagram Rantai Sebab-Akibat (disebut juga Ishikawa atau analisis akar penyebab) menyediakan peta visual dari faktor penyebab yang berkontribusi atau berdampak terhadap masalah tertentu. Bentuknya seperti pada Gambar 3.3 berikut ini. 34 Sistem Informasi Gambar 3.3. Diagram Fishbone Langkah-langkah dalam membuat Diagram Fishbone: 1. Masukkan pernyataan masalah hasil dari analisis menggunakan kerangka PIECES ke dalam kepala ikan (kotak ”problem”). Dalam hal ini pernyataan masalah disebut sebagai ”akibat”. 2. Cari akar permasalahan yang bersumber dari faktor-faktor manajemen (6M: Manpower/people, Money, Machine, Material, Method, dan Market), bisa juga menambahkan faktor lain seperti Information dan Environment. Dapat juga menggunakan faktor- faktor lain sesuai dengan referensi yang dipakai. 3. Masukkan narasi sebab (causes) yang muncul dari masing masing faktor. 4. Tuliskan narasi sebab yang lebih mendalam (subcauses) jika ada ke dalam causes. Contoh Diagram Fishbone dapat dilihat pada Gambar 3.4. Gambar 3.4. Contoh Diagram Fishbone 2. Analisis Stakeholders (RACI) Stakeholder proyek merupakan individu-individu dan organisasi yang terlibat secara aktif dalam proyek, atau kepentingannya dapat terpengaruh sebagai akibat dari proses eksekusi dan keberhasilan sebuah proyek. Tim 35 Sistem Informasi manajemen proyek harus mengidentifikasi para stakeholder, menentukan apa saja kebutuhan-kebutuhan dan ekspektasi mereka, kemudian mengelola dan mempengaruhi ekspektasi tersebut untuk memastikan keberhasilan sebuah proyek. Salah satu alat yang dapat digunakan dalam analisis stakeholders adalah Matriks RACI (Responsible, Accountable, Consulted, dan Informed). Matriks RACI digunakan untuk memperjelas peran stakeholder yang bertanggung jawab dalam masing-masing tugas (tasks), milestone dan keputusan yang diambil sepanjang berjalannya sebuah proyek. Gambar 3.5. Contoh Matriks RACI R, A, C, I adalah peran dari stakehoders yaitu: Responsible Responsible merujuk pada orang yang ditugaskan langsung untuk menyelesaikan sebuah tugas (tasks) atau membuat hasil dari tugas tersebut. Orang ini biasanya sebagai pengembang/pembuat (developers) program aplikasi. Orang yang sebagai responsible biasanya ada dalam tim proyek, bisa satu atau beberapa orang. Accountable 36 Sistem Informasi Accountable merujuk pada orang yang mendelegasikan tugas dan mereviu semua pekerjaan dalam proyek. Accountable memastikan tim (orang responsible) bekerja sesuai tujuan dan menyelesaikan pekerjaan tepat waktu. Setiap tugas (tasks) hanya memiliki satu orang sebagai accountable. Consulted Consulted merujuk pada orang yang memberikan input dan feedback pada pekerjaan yang sedang berjalan. Mereka punya kepentingan karena hasil dari proyek dapat berpengaruh pada pekerjaan mereka. Informed Informed merujuk pada orang yang perlu dimasukkan dalam lingkaran sebuah proyek tetapi bukan sebagai Consulted, bukan pula yang berkecimpung secara detail dalam tugas. Mereka perlu tau apa yang terjadi yang dapat berefek pada pekerjaan mereka. Orang-orang ini biasanya di luar tim bahkan berada pada departemen yang berbeda. Mereka biasanya pimpinan atau pejabat-pejabat dalam organisasi. Contoh sederhana dalam memahami RACI sebagai berikut: Andi sedang membuat program aplikasi A yang akan diintegrasikan dengan program aplikasi B yang telah dibuat oleh Indri. Deni adalah manajer proyek dan Susi adalah Manajer Pemasaran Produk. Dalam hal ini untuk pembuatan program aplikas A, Andi berstatus Responsible, Deni adalah Accountable, dan Indri dibutuhkan sebagai Consulted, karena program aplikasinya akan diintegrasikan oleh Andi. Terakhir Susi sebagai Informed pada saat program aplikasi sudah siap digunakan. 3. Solusi Sistem Untuk menggambarkan solusi sistem yang diajukan dengan ringkas dan jelas diperlukan beberapa alat pemodelan. Pemodelan yang bisa digunakan antara lain adalah Pemodelan dengan Flowchart dan BPMN. a) Flowchart 37 Sistem Informasi Flowchart atau bagan alur adalah diagram yang menampilkan langkah-langkah dan keputusan untuk melakukan sebuah proses dari suatu program. Flowchart ini menggambarkan secara rinci prosedur dari proses program. Flowchart program terdiri dari dua macam, antara lain: flowchart logika program (program logic flowchart) dan flowchart program komputer terinci (detailed computer program flowchart). Untuk menampilkan solusi sistem kita gunakan flowchart program komputer terinci. Simbol-simbol flowchart adalah sebagai berikut: Gambar 3.6. Simbol-simbol dalam Flowchart Berikut ini, pada Gambar 3.7, diberikan contoh pembuatan flowchart untuk program aplikasi entri data. 38 Sistem Informasi Gambar 3.7. Contoh Flowchart Entri Data b) Pemodelan dengan BPMN BPMN adalah singkatan dari Business Process Modeling Notation. Tujuan pemodelan BPMN adalah memberikan gambaran yang jelas tentang proses dari awal hingga akhir. pemodelan BPMN memuat jalur visual yang menunjukkan urutan aktivitas proyek yang diperlukan untuk berpindah dari akhir sebuah proses ke proses lainnya. Simbol-simbol BPMN adalah sebagai berikut: 39 Sistem Informasi Gambar 3.8. Simbol-simbol dalam BPMN BPMN dapat menjelaskan suatu sistem/proses secara utuh ataupun sebuah proses kolaborasi dengan beberapa entitas (user). Contoh BPMN untuk suatu proses secara utuh dapat dilihat pada Gambar 3.9. Gambar 3.9. Contoh BPMN Proses Contoh BPMN untuk suatu proses kolaborasi dengan beberapa entitas dapat dilihat pada Gambar 3.10. 40 Sistem Informasi Gambar 3.10. Contoh BPMN Proses Kolaborasi e. Studi Kelayakan Kelayakan adalah ukuran akan seberapa menguntungkan atau seberapa praktis pengembangan sistem informasi terhadap organisasi. Analisis kelayakan adalah proses pengukuran kelayakan dengan beberapa variabel. Kelayakan sebaiknya diukur sepanjang tahapan proses pengembangan sistem. Lingkup dan kompleksitas proyek yang tampaknya dapat dikerjakan dengan mudah, dapat berubah setelah persoalan dan kesempatan awal dianalisis secara lengkap atau setelah sistem didesain. Jadi, proyek yang layak dikerjakan di saat tahapan awal (studi kelayakan awal), dapat menjadi tidak layak pada tahapan selanjutnya. 1. Identifkasi solusi kandidat Untuk mendapatkan solusi sistem yang layak dan tepat, maka diperlukan beberapa kandidat sistem sebagai bahan untuk perbandingan dan mengukur kelayakan sistem. Alat yang digunakan adalah Matriks Solusi Kandidat. Matriks ini berisi minimal 3 (tiga) kandidat sistem dengan beberapa karakteristik yang telah ditetapkan. Bentuk Matriks Solusi Kandidat dapat dilihat pada Tabel 3.4. 41 Sistem Informasi Tabel 3.4. Matriks Solusi Kandidat 2. Analisis Solusi Kandidat Setiap solusi kandidat harus dianalisis kelayakannya. Sebagai kriteria penentu layak atau tidaknya suatu solusi, kita dapat menggunakan faktor kelayakan TELOS. a) Kelayakan Teknis Pertanyaan berikut dapat menjadi pertimbangan dalam menentukan kelayakan teknis: 1) Apakah teknologi atau solusi yang diajukan cukup praktis? 2) Apakah saat ini kita telah mempunyai teknologi yang memadai? 3) Apakah kita mempunyai pakar teknis yang memadai? b) Kelayakan Ekonomis Hal mendasar dalam banyak proyek adalah kelayakan ekonomis. Selama fase awal proyek (analisis kelayakan umum), analisis kelayakan ekonomis hanyalah menentukan apakah manfaat yang diperoleh dari menyelesaikan persoalan tersebut cukup berharga. Biaya secara praktis tidak mungkin diperkirakan pada tahap itu, karena pertimbangan persyaratan atau kebutuhan sistem belum dimasukkan. Akan tetapi, segera setelah persyaratan atau kebutuhan sistem didapat dan dimasukkan dalam 42 Sistem Informasi pertimbangan, analis dapat memperkirakan biaya dan keuntungan dari suatu solusi dengan menggunakan analisis cost-benefit. c) Kelayakan Legal Kelayakan legal menyangkut rentang yang luas dari kepentingan yang menyangkut kontrak, liabilitas, pelanggaran, dan banyak jebakan lain yang sering tidak diketahui oleh staf teknis. d) Kelayakan Operasional Kriteria kelayakan operasional mengukur tingkat kepentingan masalah atau tingkat penerimaan solusi. Ada dua aspek kelayakan operasional yang harus dipertimbangkan: 1) Apakah masalah itu cukup berharga untuk diselesaikan, atau akankah solusi itu bermanfaat untuk menyelesaikan suatu masalah? 2) Bagaimana pendapat pengguna akhir dan manajemen mengenai masalah atau solusi itu? e) Kelayakan Jadwal Tenggat waktu yang dibutuhkan dalam suatu proyek pengembangan sistem informasi, terkadang sangat menentukan sukses atau gagalnya suatu proyek. Banyak proyek pengembangan sistem informasi yang gagal karena masalah jadwal. Jadwal yang tidak tepat akhirnya dapat mempengaruhi penyelesaian proyek yang kurang baik. Lebih baik penyelesaian proyek dengan baik dan benar, meskipun dari sisi jadwal mengalami keterlambatan, daripada penyelesaian proyek yang tepat waktu tapi sistem tidak dapat berfungsi dengan baik dan benar. Melewati tenggat waktu merupakan hal yang problematis, namun sistem yang tidak berfungsi dengan baik dan benar dapat menjadi malapetaka. Ini merupakan pilihan mana yang lebih baik dari dua hal yang buruk. 3. Membandingkan solusi kandidat 43 Sistem Informasi Kita telah membahas kriteria kelayakan suatu alternatif solusi yang dapat digunakan untuk menentukan alternatif solusi mana yang paling layak untuk dipilih. Berikutnya adalah teknik untuk melakukan perbandingan secara cepat di antara solusi-solusi kandidat berdasarkan faktor kelayakan TELOS di atas dengan menggunakan matriks, yaitu Matriks Analisis Kelayakan (Feasibility Analysis Matrix). Matriks ini melengkapi matriks sistem kandidat dengan sebuah analisis dan peringkat sistem kandidat. Kolom matriks yang berhubungan dengan solusi kandidat sama dengan yang ditunjukkan dalam matriks sistem kandidat. Satu yang membedakan matriks ini dengan matriks sistem kandidat adalah adanya kolom weight, yang merupakan pembobotan nilai pada setiap kriteria kelayakan. Baris matriks berhubungan dengan kriteria kelayakan, ditambahkan satu baris dalam setiap kriteria berupa penilaian kelayakan untuk tiap kandidat. Setelah penetapan penilaian untuk tiap kriteria pada setiap kandidat, berikutnya adalah penetapan peringkat atau nilai akhir dicatat pada baris terakhir. Matriks Analisis Kelayakan dapat dilihat pada Tabel 3.5. 44 Sistem Informasi Tabel 3.5. Matriks Analisis Kelayakan Kita telah mendiskusikan fakta bahwa setiap alternatif solusi dapat dievaluasi menurut lima kriteria: kelayakan teknis, ekonomis, legal, operasional dan jadwal. Bagaimana seorang analis mengambil solusi terbaik? Tidak mudah. Masalah operasional dan ekonomis sangat sering bertentangan. Misalnya, solusi yang menyajikan hasil operasional terbaik bagi pengguna akhir bisa saja yang paling mahal, dan oleh karena itu, paling tidak layak secara ekonomis. 3.2. Rangkuman Memahami kebutuhan user dan stakeholder adalah kunci sukses pengembangan solusi sistem informasi yang efektif. Analisis kebutuhan sistem informasi dilakukan menggunakan beberapa alat yaitu Kerangka PIECES dan Diagram Fishbone untuk analisis permasalahan dan Matriks RACI untuk analisis stakeholder. Untuk menampilkan solusi sistem informasi yang akan dikembangkan menggunakan alat Flowchart atau BPMN. 45 Sistem Informasi Solusi sistem yang akan dikembangkan perlu diuji kelayakannya. Untuk itu perlu melakukan Feasibility Study yaitu memberikan 3 (tiga) alternatif kandidat solusi sebagai perbandingan untuk dipilih satu yang paling layak. Alat yang digunakan adalah Matriks Solusi Kandidat dan Matriks Analisis Kelayakan yang mempertimbangkan faktor TELOS. 3.3. Soal Latihan Buatlah Diagram Fishbone untuk menganalisis masalah “Belum optimalnya pelaksanaan SAKIP di unit kerja BPS Provinsi/Kabupaten/Kota” tempat Anda bekerja. 3.4. Contoh Kasus Rudi sedang membuat program aplikasi SAKIP BPS Kab. X yang akan diintegrasikan dengan program aplikasi SKP yang telah dibuat oleh Andri. Amir adalah Kepala BPS sebagai manajer proyek dibantu oleh para pejabat setingkat eselon IV. Untuk menyelesaikan program aplikasi ini diperlukan konsultasi kepada Sinta, pejabat di BPS Provinsi yang menangani SAKIP. Dari informasi di atas, Buatlah Matrik RACI dengan 4 (empat) tasks dan berikan keterangan untuk peran masing-masing orang dalam R, A, C, dan I. 46