29
Bab IV Analisis Terhadap Data Empiris IV.1 Pendekatan Analisis yang Digunakan Analisis terhadap data empiris dalam penelitian ini menggunakan pendekatan Strauss. Alasan pemilihan pendekatan Strauss adalah bahwa pendekatan Strauss lebih cocok untuk konteks penelitian yang cenderung menggali seluruh aspek yang terdapat dalam data-data empiris dan berusaha menyediakan deskripsi lengkap atas aspek-aspek tersebut, sedangkan pendekatan Glaser lebih cenderung berusaha menyediakan konsep-konsep abstrak yang menjadi representasi dari data-data empiris [14]. Pendekatan Glaser membutuhkan konteks kasus yang cukup banyak sehingga dapat membuat abstraksi konsep yang berarti. Penelitian ini dilakukan dengan konteks kasus yang cukup sempit yaitu hanya di Perpustakaan Universitas Kristen Petra. Dengan demikian upaya pemberian deskripsi lengkap atas aspek-aspek yang ditemukan dalam kasus akan memberikan hasil yang lebih baik daripada penyediaan abstraksi konsep pada konteks yang cukup sempit tersebut. Berdasarkan pendekatan Strauss untuk menjamin bahwa teori yang dihasilkan tidak tercampuri oleh teori-teori lain, maka digunakan open coding untuk menghasilkan kategori-kategori yang berasal dari data-data empiris. Setelah seluruh kategori ditemukan, maka dilakukan axial coding untuk menemukan hubungan (relationship) antara kategori tersebut. Proses untuk menemukan hubungan-hubungan antar kategori ini dibantu dengan coding paradigm [23], teori-teori yang sudah ada yang berhubungan dengan konsep dan kategori yang ditemukan, dan pembentukan hipotesa untuk pengumpulan data berikutnya [14]. Proses open coding dan axial coding dilakukan berulang-ulang setiap didapatkan data empiris baru. Proses pengulangan perbandingan ini disebut sebagai constant comparison baik antara indikator, kode, konsep, dan kategori dengan data-data empiris yang baru [13].
30
IV.2 Konteks Adaptasi Sistem Informasi pada Penelitian Ini Karena definisi dari adaptasi sistem informasi adalah kemampuan sistem informasi untuk berubah, maka perlu diketahui pada daur hidup sistem informasi pada proses-proses manakah perubahan-perubahan sistem informasi terjadi. Dengan memperhatikan realita daur hidup pengembangan sistem informasi di Perpustakaan Universitas Kristen Petra, maka konteks adaptasi (proses-proses perubahan) pada sistem informasi Perpustakaan Universitas Kristen Petra adalah pada dua proses besar, yaitu: 1. Proses perubahan sistem informasi lama (SPEKTRA) ke sistem informasi yang baru (iSPEKTRA dan New SPEKTRA). Proses ini meliputi langkah 3, 4, 5, dan 6 pada Eight-Stage SDLC. 2. Proses perawatan pada sistem informasi yang baru (penambahan fungsi, atau perbaikan kesalahan) dalam rangka memenuhi perubahan kebutuhan perpustakaan terhadap sistem informasi yang baru. Proses ini meliputi langkah 8 pada Eight-Stage SDLC. Dengan memperhatikan dua proses besar tersebut, pertanyaan yang diajukan adalah faktor-faktor apa sajakah yang mempengaruhi kedua proses tersebut dalam menghasilkan sistem informasi organisasi yang adaptif. Iterasi-iterasi dalam tahap analisis ini digunakan untuk menemukan faktor-faktor yang mempengaruhi kedua proses tersebut. IV.3 Iterasi dalam Penelitian Penelitian dengan metode grounded theory adalah penelitian yang dilakukan melalui banyak iterasi. Setiap iterasi akan menyorot satu aspek dari keseluruhan obyek penelitian. Sebuah iterasi dapat mengusulkan topik baru yang perlu diteliti lebih lanjut pada iterasi berikutnya. Pada setiap iterasi dilakukan theoretical sampling yaitu upaya pemilihan sumber-sumber data empiris yang diharapkan dapat memberikan masukan data sesuai dengan hipotesa yang dibuat pada iterasi sebelumnya.
31 Iterasi pada penelitian ini (meliputi proses pengumpulan data empiris melalui wawancara, proses analisis (open coding, dan axial coding), dan pembuatan hipotesa yang menjadi dasar pengumpulan data iterasi berikutnya) adalah: 1. Fungsi dan perubahan fungsi perpustakaan, peranan sistem informasi untuk mendukung fungsi perpustakaan, efek perubahan fungsi perpustakaan terhadap sistem informasi, kualitas dukungan sistem informasi secara umum. Iterasi ke-1 melibatkan 7 partisipan. 2. Konfirmasi perubahan fungsi, dan memperluas cakupan waktu obyek penelitian. Iterasi ke-2 melibatkan 2 partisipan. 3. Apa yang terjadi selama proses pengembangan. Iterasi ke-3 melibatkan 4 partisipan. 4. Apa yang terjadi selama proses perawatan. Iterasi ke-4 melibatkan 3 partisipan. 5. Konfirmasi ketidakmampuan mengelola proyek pengembangan. Iterasi ke-5 melibatkan 3 partisipan. 6. Memperluas cakupan konteks penelitian dari hanya perubahan fungsi perpustakaan ke perubahan strategi bisnis perpustakaan: apa perubahan strategi bisnis perpustakaan, bagaimana perubahan itu mempengaruhi sistem informasi (tuntutan apa yang diberikan pada sistem informasi), apakah sistem informasi dapat memenuhi tuntutan perubahan yang berasal dari perubahan strategi bisnis. Iterasi ke-6 melibatkan 2 partisipan. Total responden wawancara 12 orang, total wawancara dilakukan sebanyak 20 kali dalam kurun waktu 2,5 bulan (Maret 2007 – Mei 2007). Selain pengumpulan data melalui wawancara juga dilakukan pemeriksaan dokumen-dokumen yang berhubungan dengan topik iterasi saat itu, yaitu: 1. Laporan bulanan perkembangan pengembangan dari setiap programmer mulai dari tahun 2000 – 2004 2. Laporan perawatan perangkat lunak tahun 2005. Karena konsep, kategori, dan hubungan antar konsep atau kategori selalu berkembang pada tiap iterasi sesuai dengan adanya penemuan data-data empiris
32 baru, maka tidak seluruh iterasi akan dituliskan pada laporan penelitian ini. Tidak seluruh tahap iterasi dituliskan pada laporan penelitian ini karena akan membutuhkan ruang yang cukup banyak untuk menampung seluruh kategori dan konsep yang dihasilkan di tiap iterasi, sedangkan kategori dan konsep tersebut bersifat tidak permanen (dapat dibuang, atau diubah pada iterasi berikutnya), dan juga sebagian besar kategori dan konsep masih akan menetap (akan disebutkan berulang-ulang)
pada
iterasi-iterasi
berikutnya
yang
mengakibatkan
ketidakefisienan dalam upaya pelaporan dari iterasi tahap pertama hingga keenam. Karena itu pada bab IV.4 akan ditunjukkan proses iterasi pada tahap ke-4. Sedangkan proses iterasi tahap ke-5 dijelaskan pada bab IV.5.
IV.4 Iterasi Tahap ke-4 Iterasi tahap ke-4 bertujuan untuk menggali (mengeksplorasi) fenomenafenomena apa saja yang terjadi selama tahap perawatan, dan menemukan faktorfaktor apa sajakah yang mempengaruhi kemampuan sistem informasi beradaptasi dari fenomena-fenomena tersebut. Langkah-langkah yang digunakan adalah langkah-langkah yang ditunjukkan pada gambar I.1. Hipotesa yang dibangun adalah bahwa kegagalan proses perawatan akan mempengaruhi kemampuan sistem informasi diubah sesuai dengan permintaan perbaikan (corrective), atau penambahan (enhancement) yang mengakibatkan sistem informasi tidak adaptif terhadap perubahan kebutuhan dari user. Untuk mendapatkan data empiris mengenai proses perawatan, dilakukan theoretical sampling dengan menentukan partisipan-partisipan manakah yang perlu dilibatkan dalam langkah pengumpulan data. Ditentukan bahwa partisipan yang dilibatkan dalam iterasi tahap ke-4 ini adalah orang-orang yang terlibat dalam proses perawatan, baik programmer yang menerima permintaan perubahan, maupun user yang menggunakan sistem informasi dan meminta dilakukannya perubahan-perubahan tertentu pada sistem informasi. Partisipan-partisipan
33 tersebut adalah koordinator divisi Software Development, para programmer yang terlibat dalam proses perawatan, dan koordinator divisi Pengolahan. Setelah hipotesa dibuat, dan partisipan-partisipan dalam iterasi tersebut telah ditentukan, dilakukan proses pengumpulan data. Proses pengumpulan data dilakukan menggunakan wawancara dengan menggunakan satu pertanyaan yang bersifat luas, dan dilanjutkan dengan pertanyaan-pertanyaan khusus yang bertujuan melakukan elaborasi dari jawaban partisipan dari pertanyaan pertama. Pertanyaan pertama selalu bersifat luas karena metode grounded theory tidak ingin jawaban dari partisipan dibatasi oleh apa yang seakan-akan menjadi realita di dalam pikiran peneliti mengenai apa yang terjadi. Pertanyaan pembuka adalah pertanyaan yang mengijinkan partisipan menjawab sesuai dengan apa yang ia inginkan tanpa dibatasi oleh variabel-variabel tertentu. Pertanyaan yang dibatasi oleh variabel tertentu misalnya adalah “Apakah menurut Anda proses perbaikan error berjalan lancar?” Pertanyaan ini mengandung dua variabel yaitu proses perbaikan error (terlalu sempit sebagai pertanyaan pembuka) dan berjalan lancar (menunjukkan arah atau direction tertentu yang dapat mengarahkan jawaban pada jawaban lancar atau tidak lancar saja). Pertanyaan pembuka seharusnya adalah “Apa yang Anda alami ketika menemukan sebuah kesalahan pada sistem informasi?” Pertanyaan ini dapat menghasilkan jawaban-jawaban yang berbeda, misalnya baik yang berorientasi pada teknologi (misalnya terdapat pesan kesalahan di layar monitor), atau bersifat pribadi (“Saya bingung apa yang harus saya lakukan”), atau berorientasi koordinasi (“Programmer tidak mau segera saya panggil waktu ada kesalahan padahal saat itu sangat penting”), atau jawabanjawaban lain yang tidak dibatasi pada aspek tertentu, atau diarahkan pada jenis jawaban tertentu saja. Setiap jawaban dapat dielaborasi lebih lanjut untuk menemukan fenomena-fenomena yang terjadi pada proses perawatan sistem informasi. Sebagai contoh, bila jawaban berorientasi pribadi seperti di atas, maka ada kemungkinan tidak ada upaya pelatihan sebelumnya terhadap user yang mengakibatkan terjadinya kebingungan ketika terjadi permasalahan.
34 Setelah proses pengumpulan data empiris dilakukan, maka langkah selanjutnya adalah proses analisis data empiris yang terbagi dalam dua langkah, yaitu open coding, dan axial coding. IV.4.1 Open Coding (Substantive Coding) IV.4.1.1 Pencarian Kode dari Data Empiris Open coding dimulai dengan melakukan proses analisis kata demi kata dari setiap data empiris yang ditemukan. Dari proses analisis tersebut akan didapatkan indikator-indikator, disebut juga poin kunci. Indikator adalah peristiwa tertentu (diantara seluruh peristiwa yang dikumpulkan dalam data empiris) yang dapat digunakan lebih lanjut untuk untuk menghasilkan konsep untuk membangun teori yang ingin dihasilkan. Dari setiap indikator kemudian dilakukan pengkodean (pemberian label) terhadap makna yang ditemukan dari kata, atau sekelompok kata tersebut. Yang perlu diperhatikan adalah peneliti yang terbiasa dengan metode kuantitatif (positivisme) akan cenderung berusaha menentukan kriteria-kriteria yang dapat digunakan untuk mengenali fakta-fakta (indikator-indikator) dari data empiris. Misalnya kriteria mengenai waktu, sumberdaya, kualitas, atau kriteria-kriteria lainnya. Contoh untuk kriteria waktu adalah bila dalam sebuah peristiwa terdapat keterlambatan waktu, maka peristiwa tersebut dimasukkan sebagai salah satu indikator. Metode grounded theory (penelitian kualitatif) memiliki pendekatan yang sangat berbeda. Baik pada iterasi ke-4 ini maupun pada iterasi sebelum dan sesudahnya tidak digunakan kriteria tertentu untuk menangkap indikator-indikator dari data empiris yang mempengaruhi proses perawatan, apakah itu yang berhubungan dengan masalah waktu, kualitas, sumber daya, atau kriteria-kriteria lainnya. Hal ini disebabkan metode grounded theory tidak ingin lebih dulu dibatasi di awal iterasi. Karena bila digunakan kriteria-kriteria tertentu untuk mengenali indikator,
35 maka hanya indikator-indikator itulah yang akan terlihat oleh peneliti, bukan keseluruhan indikator yang mungkin muncul. Untuk memastikan bahwa indikator-indikator yang muncul tidak dipengaruhi oleh kriteria tertentu, maka digunakan pertanyaan terbuka, yaitu “Apakah peristiwa (yang disebutkan dalam data empiris) ini mempengaruhi perubahan sistem informasi di perpustakaan untuk mencapai fungsi, tujuan, atau bentuk yang menjadi tujuan perubahannya?” Dengan demikian setiap peristiwa akan dinilai berdasarkan analisis apakah memiliki pengaruh tertentu atau tidak, walaupun tidak ditetapkan sejak awal apakah jenis-jenis pengaruh tersebut. Indikator yang ditemukan dari data empiris pada iterasi ke-4 yang digabungkan dengan indikator-indikator dari iterasi ke-1 hingga ke-3 ditunjukkan pada tabel IV.1. Tabel IV.1. Indikator dan kode No P1
P2
P3
Indikator (Poin kunci) Belum dihasilkan data yang akurat dan dapat diandalkan (reliable) pada proses pembuatan laporan akibat data yang tersimpan selalu berubah. Perubahan data yang tersimpan dalam database disebabkan adanya upaya perbaikan data–data lama. Programmer belum memahami keseluruhan teknologi, dan konsekuensi dari teknologi web ketika menentukan bahwa sistem informasi yang baru memanfaatkan teknologi berbasis web. Konsekuensi yang muncul adalah bahwa tidak tersedia komponen-komponen yang bisa digunakan berulang-ulang terutama yang berhubungan dengan antar muka dari perangkat lunk. Programmer juga dituntut untuk memahami daerah kemampuan yang lebih luas : html, protokol http, interface berbasis web yang baik, keamanan untuk internet, koneksi database, dan sekaligus web scripting seperti javascript. Adanya kebijakan “zero-growth” dari Yayasan sehingga terjadi penurunan jumlah staf perpustakaan secara keseluruhan termasuk jumlah programmer akibat tidak ada pengganti untuk staf-staf yang mengundurkan diri.
Kode / Label • Keandalan data sistem informasi baru rendah
•
Keterbatasan wawasan programmer dan system analyst. tentang teknologi yang diperlukan.
•
Penurunan jumlah staf perpustakaan, termasuk programmer. Tidak ada dukungan dari top management.
•
36
No P3a
P3b P4
P5
P6
P7
P8
P9
Indikator (Poin kunci) Kode / Label Jumlah programmer yang tersedia untuk setiap • Jumlah programmer sistem informasi (iSPEKTRA, dan New tidak memadai. SPEKTRA) sangat kecil bila dibandingkan jumlah modul di dalam setiap sistem informasi, dan kompleksitas dalam setiap modul tersebut. Sedikitnya jumlah staf yang dapat diberi tugas • Jumlah staf tidak melakukan pengujian sistem informasi baru akibat memadai. jumlah staf perpustakaan yang menurun. Tidak ada komponen yang bisa langsung • Keterbatasan dalam digunakan (setiap komponen harus dibuat sendiri), kakas yang digunakan dan digunakan secara berulang-ulang dalam dalam pengembangan. pengembangan perangkat lunak yang berbasis • {Karakteristik web. pengembangan untuk jumlah programmer yang kecil.} Desain database sistem lama tidak memperhatikan • Kesalahan desain constraints dan relation antar tabel. Hal ini database. mengakibatkan adanya kesalahan data yang • Kekurangan sistem semakin bertumpuk dari pengoperasian . informasi lama. Desain software sistem lama yang tidak • Kesalahan desain memperhatikan constraint. Seharusnya bila software database tidak dilengkapi dengan constraint, maka • Kekurangan sistem software harus dilengkapi dengan fasilitas informasi lama. pemeriksaan data ini (walaupun tidak seefisien pemeriksaan melalui constraint di database). Hal ini tidak dipenuhi sehingga data-data salah dapat masuk ke dalam database. Adanya kesalahan-kesalahan pengisian data, • Kesalahan manusia misalnya nama-nama penerbit, subyek yang dalam pengoperasian memiliki perbedaan antar record karena kesalahan sistem informasi lama. manusia (human error). Sistem informasi yang baru menuntut seluruh data • Pekerjaan ekstra dalam yang dipindahkan dari sistem lama sudah dalam masa transisi sistem kondisi benar. Hal ini menjadi tuntutan karena informasi sistem baru telah menerapkan constraints yang • {Standar kualitas sistem ketat sehingga tidak ada data salah yang diijinkan informasi.} masuk. Hal ini membuat kerja divisi Pengolahan bertambah berat karena harus memperbaiki ribuan record data yang mengalami kesalahan data tersebut sebelum dapat dimigrasi ke sistem baru. Sivitas pengguna sistem baru harus menyadari • Sistem informasi baru bahwa data yang tertampil pada Online Catalog tidak memiliki seluruh bukanlah data yang lengkap karena sebagian data data yang seharusnya. masih belum dapat ditambahkan pada database sistem yang baru.
37
No P10
P11
P12
P13
P14
P15
Indikator (Poin kunci) Dokumentasi atas kode-kode dalam setiap modul yang tidak memadai telah mempersulit programmer menangani modul yang dibuat oleh programmer lain akibat programmer tersebut keluar. Hal ini membuat proses pengembangan, dan perawatan modul lebih lambat karena programmer yang baru harus mempelajari struktur program langsung dengan membaca kode program yang jumlahnya puluhan ribu baris untuk memahami bagaimana modul tersebut bekerja. Pada saat sistem informasi masuk pada masa perawatan (maintenance), programmer yang tersedia hanya satu orang untuk menangani 6 modul yang telah diselesaikan, dan programmer tersebut bersifat part-time. Terjadi revisi berulang-ulang antar modul karena proses pemrograman yang bersamaan sehingga saling mempengaruhi. Yang dimaksud dengan revisi antar modul adalah adanya pengubahan bagian modul yang sudah jadi akibat pengembangan modul lainnya.
Kode / Label • Masalah dalam dokumentasi program. • Masalah dalam pengembangan sistem informasi baru. • Masalah dalam perawatan sistem informasi baru.
Programmer cenderung untuk bekerja mandiri, sehingga komunikasi dengan staf sering kurang terjadi kalau tidak didesak. Ada gap antara programmer dengan staf. Staf minder melakukan komunikasi dengan programmer bila terdapat kekurangan dalam sistem yang dibangun.
•
Terjadinya pembuatan berulang terhadap kodekode fungsi dan prosedur yang berfungsi sama, sehingga ada beberapa fungsi dan prosedur yang tumpang tindih.
•
Sejauh ini di perpustakaan semua permintaan data yang tidak dapat ditangani divisi Pengolahan diberikan pada sub divisi iSpektra. Dengan terpusatnya dan tidak adanya urutan prioritas yang jelas maka membuat programmer bingung harus mengerjakan tugas mengatasi bug di beberapa modul iSpektra, atau harus menyiapkan permintaan data dari divisi lain di perpustakaan untuk memenuhi permintaan dari jurusan.
•
• • • •
•
•
•
Masalah perawatan sistem informasi baru. Kurang sumber daya manusia. Masalah dalam pengembangan sistem informasi baru. {Masalah kebutuhan (requirement) yang belum bisa ditetapkan secara definitif pada saat desain sistem yang baru.} Komunikasi antara pengguna sistem dengan programmer tidak terjadi maksimal. Kecenderungan programmer untuk sulit berkomunikasi. Tidak ada dokumentasi terhadap seluruh fungsi dan prosedur Upaya pemrograman yang berulang (redundant) Interupsi terhadap proses pengembangan Prioritas kerja tidak jelas.
38
No P16
P17
P18
P19
P20
P21
Indikator (Poin kunci) Proses pengujian (bug hunting) tidak bekerja dengan baik, karena dirasakan oleh programmer cukup merepotkan bila harus menuliskan semua bug yang ada ke sebuah sistem pencatatan bug padahal lebih cepat bila langsung dikomunikasikan dengan programmer. Pada saat programmer mengalami kesulitan dalam proses coding biasanya programmer melakukan upaya untuk mencari jalan keluar melalui pencarian di internet, buku-buku pemrograman, dan programmer senior. Kecepatan koneksi internet masih dirasa cukup membantu dalam mencari jalan keluar. Sedangkan keterbatasan yang dialami adalah jumlah buku yang dapat digunakan sedikit karena harus berbagi dengan buku yang boleh dipinjam anggota perpustakaan. Demikian pula programmer senior yang bisa diajak berdiskusi berada dalam kondisi sulit dihubungi secara langsung (keluar, dan cuti studi). Programmer kebingungan menentukan urutan perbaikan kesalahan (bug fixing) karena semua bug diminta untuk diperlakukan segera dan penting (urgent). Karena bentuk software adalah terbagi menjadi beberapa modul independen yang mengakses kode-kode fungsi yang sama, dan database yang sama, maka perubahan desain sebuah modul dapat mempengaruhi kinerja modul lainnya. Dirasa perlu adanya semacam proses pemeriksaan silang (cross check) untuk mengetahui bagian modulmodul lain yang ikut terpengaruh akibat perubahan pada sebuah modul tertentu. Sering terjadi silang pendapat antara permintaan staf perpustakaan dengan perintah kerja yang didapatkan dari divisi System Development. Staf kadang menghubungi langsung programmernya sehingga terjadi kebingungan pada programmer mengenai apa yang seharusnya dikerjakan / diperbaiki.
Kode / Label • Kakas pengembangan tidak digunakan seperti seharusnya.
Sejak awal tidak ditetapkan adanya batas waktu penyelesaian sistem informasi baru. Tidak ada tekanan untuk menyelesaikan proses pengembangan pada waktu tertentu sehingga tidak terasa adanya masalah untuk mengundurkan jadwal penyelesaian sebuah modul.
•
•
Infrastruktur pengembangan (knowledge): o Internet : memadai o Buku : kurang memadai o Orang : kurang memadai
•
Tidak ada proses penentuan prioritas bug.
•
Pengaruh perubahan modul pada modul lainnya. Pemeriksaan silang antar modul dibutuhkan. {Alat yang terintegrasi untuk desain, pemrograman, dan pengujian modul.} Miskomunikasi antara pengguna dengan system analyst, dan programmer. Ketidakjelasan jalur komunikasi antara user, system analyst, dan programmer. Tidak ada batas waktu yang ditetapkan untuk penyelesaian seluruh sistem informasi baru.
• •
•
•
39
No P22
P23
P24
P25
P26
Indikator (Poin kunci) Sudah ada proses identifikasi apa saja yang harus dibuat (requirement list) untuk tiap modul di tiap sistem informasi, dan juga ada pembagian tugas untuk tiap bagian dari daftar tersebut, tetapi prediksi waktu untuk proses pengembangan setiap bagian seringkali salah karena selalu ada hal yang baru yang belum diketahui yang membuat pengembangan bagian itu menjadi lebih lama dari yang ditentukan. Hal baru tersebut misalnya adalah belum diketahui secara pasti seluruh kebutuhan komponen yang diperlukan, Beberapa kali terjadi pengembangan modul baru yang tidak direncanakan sebelumnya (biasanya baru dirasakan dibutuhkan karena adanya perubahan kebutuhan perpustakaan), tetapi harus pengadaannya harus diutamakan pada waktu itu. Pengembangan modul baru ini harus ditangani oleh programmer yang ada karena keterbatasan personil. Hal ini mengakibatkan pengembangan modul yang sudah ada tertunda. Proses evaluasi dilakukan tiap bulan melalui laporan dari tiap programmer, dan kemudian dicocokkan dengan daftar bagian-bagian modul yang harus dikerjakan. Dari hasil pencocokan tersebut kemudian ditentukan perkiraan persentase penyelesaian pekerjaan untuk modul tersebut. Masalahnya adalah tidak ada jadwal waktu detail untuk penyelesaian tiap bagian modul, yang ada hanyalah jadwal penyelesaian keseluruhan modul sehingga tetap tidak dapat diketahui kapan penyelesaian seluruhnya akan tercapai. Proses pengembangan sistem informasi baru memakan waktu cukup lama, yaitu empat tahun, dan tidak seluruh fungsi yang diinginkan dari sistem informasi baru dapat dipenuhi.
Kode / Label • Tidak ada detail prediksi waktu pengembangan yang memadai.
Tidak ada prediksi ulang terhadap jadwal waktu pengembangan bila terjadi interupsi pada proses pengembangan baik akibat adanya permintaan data, atau pengembangan modul baru. Proses prediksi hanya dilakukan sekali, yaitu pada saat membuat detail pekerjaan pengembangan di awal proses pengembangan.
•
• •
• •
•
Interupsi pada pengembangan modul. Keterbatasan jumlah programmer.
Proses evaluasi kinerja programmer yang tidak memadai. Tidak diketahui secara pasti kapan sebuah modul akan diselesaikan.
Proses pengembangan tidak efisien dan efektif untuk menghasilkan sistem informasi yang sesuai daftar kebutuhan awal. Tidak ada prediksi ulang atas proses pengembangan
40
No P27
Indikator (Poin kunci) Tidak ada perubahan besar pada fungsi perpustakaan. Yang terjadi adalah perubahan teknologi yang mempengaruhi lingkungan kerja pustakawan, dan lingkungan informasi dari pengguna perpustakaan. Perubahan teknologi yang dialami adalah: • Adanya perangkat keras yang lebih cepat yang memungkinkan diadopsinya operating system baru, dan teknologi seperti internet dibandingkan perangkat keras yang lama. •
Penggunaan internet (terutama http, dan email) yang lebih luas baik di lingkungan internal Universitas Kristen Petra, maupun dunia. Adanya search engine dan situs-situs penyedia informasi membuat sivitas tidak hanya menyandarkan diri pada perpustakaan sebagai sumber informasi. Sivitas lebih menyukai mengakses informasi di internet karena tidak harus datang ke perpustakaan, dan karena biasanya informasi tersebut sudah dalam bentuk ‘siap baca’, biasanya sudah berupa intisari dari informasi, tidak seperti buku yang cukup tebal dan harus dibaca lebih lama.
•
Dalam kondisi dimana hampir semua informasi bisa didapatkan di di internet, dan turunnya kecenderungan sivitas menggunakan perpustakaan sebagai sumber informasi, maka perpustakaan juga harus dapat membuat informasinya sendiri dalam bentuk institutional repository yang bisa diakses melalui internet. Dengan demikian perpustakaan tetap menyediakan sumber informasi berupa koleksi tercetak seperti biasanya, tetapi juga tetap relevan sebagai penyedia informasi yang bisa diakses di internet.
Kode / Label • Tidak terjadi perubahan besar pada fungsi perpustakaan. • Perubahan fungsi perpustakaan lebih mengarah pada pengadopsian teknologi baru.
IV.4.1.2 Pembentukan Konsep Pembentukan konsep dilakukan dengan membandingkan kode-kode yang telah ditemukan, dan mencari kemiripan (commonality), perbedaan, dan konsistensi dari kode-kode tersebut. Dari proses perbandingan tersebut dihasilkan konsep-konsep
41 baru yang kemudian dibandingkan lagi dengan indikator-indikator yang ada sehingga didapatkan konsep yang sesuai. Konsep-konsep yang ditemukan pada kasus Perpustakaan Universitas Kristen Petra ditunjukkan pada tabel IV.2. Tabel IV.2. Konsep yang ditemukan dari indikator No. Konsep 1 Tidak ada kejelasan batas waktu penyelesaian baik untuk tiap bagian modul, setiap modul, maupun seluruh sistem informasi.
2 3
Evaluasi kinerja proses pengembangan tidak memadai. Upaya prediksi yang tidak memadai untuk detail unit pekerjaan pengembangan.
4
Interupsi dari luar tim pengembangan yang mengganggu proses pengembangan.
5
Proses pengembangan yang tidak efisien (berulang). Proses transfer pekerjaan antar programmer menjadi lambat.
6
7
Tidak ada penentuan prioritas kerja.
8
Kurangnya jumlah programmer pada masa perawatan. Pengembangan sebuah modul dapat mengganggu pengembangan modul lainnya.
9
Kode / Label P21 Tidak ada batas waktu yang ditetapkan untuk penyelesaian seluruh sistem informasi baru. P22 Tidak ada detail prediksi waktu pengembangan yang memadai. P24 Tidak diketahui secara pasti kapan sebuah modul akan diselesaikan. P24 Evaluasi kinerja programmer yang tidak memadai. P22 Tidak ada prediksi yang memadai untuk detail waktu pengembangan. P26 Tidak ada prediksi ulang atas proses pengembangan. P23 Interupsi pada pengembangan modul. P15 Interupsi terhadap proses pengembangan P14 Upaya pemrograman yang berulang (redundant) P10 : • Masalah dalam dokumentasi program. • Masalah dalam pengembangan sistem informasi baru. • Masalah dalam perawatan sistem informasi baru. P14 Tidak ada dokumentasi terhadap seluruh fungsi dan prosedur P15 Prioritas kerja tidak jelas. P18 Tidak ada proses penentuan prioritas penanganan bug. P11 Kurang sumber daya manusia. P12 Masalah dalam pengembangan sistem informasi baru. P19 Pengaruh perubahan modul pada modul lainnya.
42
No. Konsep 10 Kakas pengembangan tidak digunakan seperti seharusnya. 11 Kakas yang digunakan dalam pengembangan memiliki keterbatasan. 12 Kekurangan sistem informasi lama.
13 14
Keterbatasan wawasan programmer dan system analyst tentang teknologi yang diperlukan. Kecenderungan programmer sulit berkomunikasi.
15
Ketidakjelasan jalur komunikasi pada masa pengembangan dan perawatan sistem.
16
Infrastruktur pengembangan untuk aspek pengetahuan kurang menunjang.
17
Pengoperasian sistem informasi baru tidak maksimal.
18
Tidak ada dukungan dari top management.
19
Kurangnya jumlah staf yang terlibat dalam proses pengembangan baik pustakawan, maupun programmer.
20
Proses pengembangan tidak efisien dan efektif untuk menghasilkan sistem informasi yang sesuai daftar kebutuhan awal.
Kode / Label P16 Kakas pengembangan tidak digunakan seperti seharusnya. P4 Keterbatasan dalam kakas yang digunakan dalam pengembangan. P5 Kesalahan desain database P6 Kesalahan desain software P7 Kesalahan manusia dalam pengoperasian sistem informasi lama. P2 Keterbatasan wawasan programmer dan system analyst. tentang teknologi yang diperlukan. P13 : • Komunikasi antara pengguna sistem dengan programmer tidak terjadi maksimal. • Kecenderungan programmer untuk sulit berkomunikasi. P20 : • Miskomunikasi antara pengguna dengan system analyst, dan programmer. • Ketidakjelasan jalur komunikasi antara user, system analyst, dan programmer. P17 Infrastruktur pengembangan (knowledge): o Internet : memadai o Buku : kurang memadai o Orang : kurang memadai P1 Keandalan data sistem informasi baru rendah P8 Pekerjaan ekstra pada masa transisi sistem informasi P9 Sistem informasi baru tidak memiliki seluruh data yang seharusnya P3 Tidak ada dukungan dari top management. P3a Jumlah programmer tidak memadai P3b Jumlah staf tidak memadai P23 Keterbatasan jumlah programmer. P25 Proses pengembangan tidak efisien dan efektif untuk menghasilkan sistem informasi yang sesuai daftar kebutuhan awal.
43
No. Konsep 21 Masalah-masalah yang timbul pada proses perubahan (pengembangan, dan perawatan) sistem informasi tidak berakar dari perubahan fungsi perpustakaan.
Kode / Label Seluruh indikator lain (P1 – P26). P27 Perubahan fungsi perpustakaan lebih mengarah pada pengadopsian teknologi baru.
IV.4.1.3 Pembentukan Kategori dari Konsep-konsep yang Ditemukan. Proses pembentukan kategori dilakukan dengan mencari kemiripan lebih lanjut dari setiap konsep yang ditemukan. Kategori adalah kata benda yang dapat dilengkapi dengan kata sifat yang dapat menunjukkan cakupan pemahaman yang lebih luas daripada konsep-konsep di dalamnya tetapi tidak menambah makna, kecuali bila diijinkan oleh adanya extant theory yang membahas pengetahuan tersebut. Kategori yang ditemukan dari konsep ditunjukkan pada tabel IV.3. Tabel IV.3. Kategori yang ditemukan dari konsep No. Kategori 1
2
3
Interupsi pada proses pengembangan.
Konsep
Interupsi dari luar tim pengembangan yang mengganggu proses pengembangan. Pengembangan sebuah modul dapat mengganggu pengembangan modul lainnya. Dokumentasi pengembangan Proses pengembangan yang tidak tidak lengkap. efisien (berulang). Proses transfer pekerjaan antar programmer menjadi lambat Masalah-masalah selama proses Tidak ada penentuan prioritas pengembangan, dan perawatan. kerja. Tidak ada kejelasan batas waktu penyelesaian baik untuk tiap bagian modul, setiap modul, maupun seluruh sistem informasi. Evaluasi kinerja proses pengembangan tidak memadai. Prediksi yang tidak memadai untuk detail unit pekerjaan pengembangan. Ketidakjelasan jalur komunikasi pada masa pengembangan dan perawatan sistem.
Kode / Label P23, P15 P12, P19 P14 P10, P14 P15, P18 P21, P22, P24 P24 P22, P26 P20
44
No. Kategori
Konsep
4
Kakas yang digunakan dalam pengembangan memiliki keterbatasan. Kakas pengembangan tidak digunakan secara maksimal. Infrastruktur pengembangan untuk aspek pengetahuan kurang menunjang. Tidak ada dukungan dari top management. Kurangnya jumlah programmer pada masa perawatan. Kurangnya jumlah staf yang terlibat dalam proses pengembangan baik pustakawan, maupun programmer. Keterbatasan wawasan programmer dan system analyst tentang teknologi yang diperlukan. Kecenderungan programmer sulit berkomunikasi. Kekurangan sistem informasi lama. Pengoperasian sistem informasi baru tidak maksimal. Proses pengembangan tidak efisien dan efektif untuk menghasilkan sistem informasi yang sesuai daftar kebutuhan awal. Masalah-masalah yang timbul pada proses perubahan (pengembangan, dan perawatan) sistem informasi tidak berakar dari perubahan fungsi perpustakaan.
5.
6
Keterbatasan infrastruktur pengembangan.
Keterbatasan jumlah staf.
Keterbatasan kemampuan staf teknologi informasi.
7
Efek ketidaksempurnaan sistem informasi lama.
8
Proses pengembangan tidak efisien dan efektif untuk menghasilkan sistem informasi yang sesuai daftar kebutuhan awal.
Kode / Label P4 P16 P17 P3 P11 P3a, P3b, P23 P2 P13 P5, P6, P7 P1, P8, P9 P25
P27
Visualisasi kumpulan kategori dan konsep di atas ke dalam bentuk diagram ditunjukkan pada gambar IV.1. IV.4.2 Axial Coding (Theoretical Coding) Proses axial coding adalah sebuah proses untuk menemukan relasi antar konsep, dan antar kategori. Dari proses penemuan relasi ini dapat dihasilkan kategori baru, konsep baru, perubahan nama kategori dan konsep, atau penggabungan konsep atau kategori.
45 Proses menemukan relasi dilakukan dengan menggunakan coding paradigm yang diusulkan
oleh
Strauss.
Coding
paradigm
meminta
peneliti
untuk
mengidentifikasi lebih lanjut setiap konsep dan kategori yang muncul dalam peranannya terhadap fenomena yang menjadi tujuan penelitian. Selain menggunakan coding paradigm juga digunakan teori-teori yang sudah ada (extant theory) yang berhubungan dengan konsep atau kategori tersebut yang membantu peneliti dalam membuat hipotesa mengenai adanya konsep, atau kategori baru. Hipotesa tersebut kemudian digunakan sebagai bahan dalam proses pengumpulan data, open coding, dan axial coding pada iterasi berikutnya. Extant theory juga digunakan untuk merevisi nama kategori dan konsep, atau membentuk kategori dan konsep baru. Extant theory memberi masukan pada peneliti mengenai daftar istilah, definisi istilah, dan tingkat konsep dalam keseluruhan pengetahuan dalam extant theory tersebut. Tiga hal inilah yang membantu peneliti merevisi lebih lanjut kumpulan konsep dan kategori yang ditemukan dalam open coding. Dengan menggunakan coding paradigm, konsep-konsep yang telah ditemukan dianalisis lebih lanjut untuk memetakan peran konsep di dalam fenomena pada kasus Perpustakaan Universitas Kristen Petra. Pemetaan konsep pada coding paradigm ditunjukkan pada tabel IV.4.
46
Gambar IV.1. Kategori dan konsep hasil dari open coding
47 Tabel IV.4. Pemetaan Konsep pada coding paradigm A. Fenomena A.1. Proses pengembangan tidak efisien dan efektif untuk menghasilkan sistem informasi yang sesuai daftar kebutuhan awal. A.2. Masalah-masalah yang timbul pada proses perubahan (pengembangan, dan perawatan) sistem informasi tidak berakar dari perubahan fungsi perpustakaan. B. Causal conditions B.1. Kakas yang digunakan dalam pengembangan memiliki keterbatasan. B.2. Keterbatasan wawasan programmer dan system analyst tentang teknologi yang diperlukan. B.3. Kurangnya jumlah staf yang terlibat dalam proses pengembangan baik pustakawan, maupun programmer. B.4. Kurangnya jumlah programmer pada masa perawatan. B.5. Tidak ada kejelasan batas waktu penyelesaian baik untuk tiap bagian modul, setiap modul, maupun seluruh sistem informasi. B.6. Upaya prediksi yang tidak memadai untuk detail unit pekerjaan pengembangan. B.7. Evaluasi kinerja proses pengembangan tidak memadai. C. Intervene conditions C.1. Interupsi dari luar tim pengembangan yang mengganggu proses pengembangan. C.2. Kecenderungan programmer sulit berkomunikasi. C.3. Kekurangan sistem informasi lama C.4. Kakas pengembangan tidak digunakan seperti seharusnya. C.5. Infrastruktur pengembangan untuk aspek pengetahuan kurang menunjang. C.6. Ketidakjelasan jalur komunikasi pada masa pengembangan dan perawatan sistem. C.7. Pengembangan sebuah modul dapat mengganggu pengembangan modul lainnya. C.8. Proses pengembangan tidak efisien (berulang). C.9. Hambatan pada proses pengembangan, dan perawatan karena kurangnya dokumen pengembangan. C.10. Tidak ada dukungan dari top management. C.11. Tidak ada penentuan prioritas kerja. D. Consequence D.1. Pengoperasian sistem informasi baru tidak maksimal.
Dengan menggunakan bantuan dari coding paradigm di atas, dilakukan analisa lebih lanjut untuk mengenali hubungan-hubungan antar konsep. Tentu saja setiap hubungan antar konsep tetap harus dapat ditarik pada data-data empiris yang menunjangnya. Tidak boleh ada hubungan konsep yang berupa asumsi peneliti belaka.
48 Dengan memperhatikan teori manajemen proyek [26] terlihat bahwa kondisi penyebab B5 dan B6 terkait erat dengan manajemen waktu. Manajemen waktu berupaya membuat estimasi berapa lama waktu yang dibutuhkan sebuah proyek, membuat jadwal proyek, dan memastikan penyelesaian yang tepat waktu dari proyek tersebut. Causal conditions B5, B6 dan B7 dipengaruhi oleh intervene conditions C1, C5, C7, dan C9. Pada kondisi B5 setiap programmer hanya diberi gambaran mengenai waktu penyelesaian untuk sebuah modul, tetapi tidak ada kejelasan waktu untuk pengerjaan bagian-bagian modul tersebut. Hal ini mengakibatkan setiap programmer tidak memiliki kejelasan kapan seharusnya sebuah bagian modul telah diselesaikan, dan kemudian berpindah pada bagian modul lainnya. Akibatnya pengembangan modul-modul tersebut cenderung mengalami keterlambatan dan tidak memenuhi gambaran waktu semula. Hal ini diperparah oleh adanya interupsi pada pekerjaan programmer (C1, dan C7) sehingga otomatis programmer tersebut harus terhenti dari proses pengerjaannya saat itu. Ketika programmer selesai mengerjakan pekerjaan tambahan akibat interupsi tersebut tidak dilakukan prediksi ulang kapan penyelesaian bagian modul tersebut, atau keseluruhan modul (B6). Selain upaya prediksi yang tidak memadai tersebut, pekerjaan pengembangan menjadi lebih lambat akibat adanya pengaruh dari infrastruktur pengetahuan kurang menunjang (C5), dan kurangnya dokumen pengembangan yang dibutuhkan (C9). Hal ini kurang disadari karena evaluasi bulanan tidak dapat menunjukkan posisi pengembangan saat itu yang dapat dibandingkan dengan posisi pengembangan seharusnya (B7). Dengan melihat hubungan-hubungan di atas dibentuk sebuah hipotesa baru bahwa staf kurang mampu mengelola proyek pengembangan perangkat lunak. Karena terdapat sebuah hipotesa baru, maka kondisi theoretical saturation belum tercapai sehingga perlu dilakukan iterasi ke-5 untuk menjawab hipotesa tersebut. IV.4.3 Selective Coding Selective coding adalah upaya untuk menentukan satu, atau dua kategori inti dan membatasi penelitian di seputar kategori inti tersebut. Kategori ini (core category) adalah poin esensial dan mendasar dari teori yang dibangun, dimana kebanyakan
49 kategori lain dihubungkan dengan kategori ini, dan kategori ini bertanggung jawab terhadap hampir seluruh variasi pola yang terjadi. Kategori inti memiliki fungsi utama (prime function) mengintegrasikan teori, dan membuat teori ‘padat’ dan saturasi [14]. Dengan memperhatikan konsep dan kategori yang berkembang pada open coding dan axial coding, tidak ditemukan adanya kategori inti yang mempengaruhi keseluruhan kategori lain, atau menjadi inti dari teori yang dibangun. Dengan pertimbangan tersebut, maka pada iterasi ini tidak digunakan selective coding. IV.5 Iterasi Tahap ke-5 Iterasi ke-5 dilakukan untuk menjawab hipotesa bahwa staf kurang mampu mengelola proyek pengembangan perangkat lunak. Untuk menguji hipotesa ini diajukan
pertanyaan-pertanyaan
yang
berusaha
menjawab
apakah
staf
berpengalaman dalam membuat perencanaan proyek pengembangan, atau pernah mempelajari manajemen proyek pengembangan perangkat lunak. Hasil pengumpulan data menghasilkan indikator P28 yang ditunjukkan pada tabel IV.5. Tabel IV.5. Indikator yang dihasilkan dari iterasi ke-5 No. P28
Indikator (Poin Kunci) Programmer dan system analyst tidak memahami project network, critical path, dan bagaimana membuat prediksi terhadap sumber daya yang dibutuhkan dalam tiap satuan kerja. Programmer dan system analyst juga tidak memahami bagaimana memprediksi, dan mengelola resiko yang muncul dari proyek pengembangan modul. Programmer dan system analyst memahami secara terbatas mengenai work breakdown structure (WBS), tapi tidak mampu mengubah WBS menjadi project network diagram dan mengukur critical path dari proyek.
Kode / Label • Manajemen proyek tidak memadai • Ketidakmampuan programmer dan system analyst untuk mengelola proyek
Dengan menggunakan indikator tersebut, maka dilakukan penambahan konsep seperti ditunjukkan pada tabel IV.6.
50 Tabel IV.6. Penambahan konsep baru pada iterasi ke-5 No. Konsep 22 Ketidakmampuan programmer dan system analyst mengelola proyek pengembangan.
Kode / Label P22 Tidak ada detail prediksi waktu pengembangan yang memadai. P28 : • Manajemen proyek tidak memadai • Ketidakmampuan programmer dan system analyst untuk mengelola proyek
Dengan adanya konsep baru, maka dilakukan evaluasi ulang atas kategorikategori yang sudah ada. Evaluasi kategori menghasilkan adanya perubahan pada kategori “Keterbatasan kemampuan staf teknologi informasi” seperti ditunjukkan pada tabel IV.7. Tabel IV.7. Perubahan kategori No.
Kategori
Konsep
6
Keterbatasan kemampuan staf teknologi informasi.
Keterbatasan wawasan programmer dan system analyst tentang teknologi yang diperlukan. Kecenderungan programmer sulit berkomunikasi. Ketidakmampuan programmer dan system analyst mengelola proyek pengembangan.
Kode / Label P2 P13 P28
Menurut teori manajemen proyek, kerangka kerja manajemen proyek meliputi sembilan knowledge area, yaitu: scope management, time management, cost management, quality management, human resource management, communication management,
risk
management,
procurement
management,
dan
project
integration management. Dengan memanfaatkan teori manajemen proyek tersebut, pada iterasi ke-5 dilakukan penggabungan konsep menjadi sub kategori baru. Konsep yang digabungkan adalah konsep nomor 1, 2, 3, dan 15 ke dalam sub kategori “Manajemen Proyek”. Penggabungan konsep ditunjukkan pada gambar IV.2.
51
Gambar IV.2. Penggabungan konsep ke dalam sub kategori “Manajemen Proyek” IV.6 Hasil Analisis (Pembentukan Substantive Theory) Setelah seluruh iterasi dilakukan pada tahap ke-1 hingga ke-6, maka dilakukan upaya pembuatan teori. Hasil dari tahap analisis adalah teori mengenai faktorfaktor penyebab, dan faktor-faktor yang mempengaruhi sistem informasi di Perpustakaan Universitas Kristen Petra mengalami kesulitan beradaptasi terhadap perubahan strategi perpustakaan. Teori ini dibangun dari data-data empiris yang dikumpulkan melalui proses wawancara, dan pemeriksaan dokumen selama enam iterasi. Teori divisualisasikan pada gambar IV.3. Pada gambar tersebut dilakukan visualisasi yang menunjukkan fenomena utama, yaitu proses pengembangan yang berjalan lambat (tidak efisien), dan belum mencapai seluruh fungsi yang diharapkan (tidak efektif). Di sekeliling fenomena utama, ditunjukkan kategori dan konsep yang menunjukkan konteks, menyebabkan, atau mempengaruhi fenomena utama yang dihasilkan dari proses axial coding dari setiap iterasi. Selain itu juga ditunjukkan kategori dan konsep yang berpengaruh terhadap proses pengembangan, proses perawatan, kedua proses tersebut sekaligus, dan juga yang tidak berhubungan secara langsung dengan proses pengembangan dan perawatan walaupun tetap berpengaruh pada fenomena utama. Data indikator, konsep, dan kategori yang diperoleh dari seluruh iterasi ditunjukkan pada lampiran D.
52 Melalui diagram tersebut terlihat adanya perubahan lingkungan bisnis perpustakaan yang mempengaruhi lingkungan informasi pengguna perpustakaan. Perubahan tersebut didorong oleh adanya teknologi baru, yaitu internet dalam bentuk layanan world wide web. Adanya search engine dan situs-situs penyedia informasi membuat sivitas tidak perlu hanya menyandarkan diri pada perpustakaan sebagai sumber informasi. Sivitas lebih menyukai mengakses informasi di internet karena tidak harus datang ke perpustakaan, dan karena informasi tersebut biasanya sudah dalam bentuk ‘siap baca’, yaitu sudah berupa intisari dari sebuah informasi, tidak seperti buku yang cukup tebal dan harus dibaca lebih lama. Demikian juga jurnal-jurnal yang selama ini dapat diperoleh secara fisik di perpustakaan, pada era internet pengguna perpustakaan dapat secara langsung mencarinya di search engine dan mendapatkan jurnal tersebut dalam bentuk elektronik pada situs-situs tertentu. Untuk menjawab perubahan lingkungan bisnis tersebut, maka perpustakaan memutuskan menjawab melalui tiga respon (strategi), yaitu: 1. Dalam kondisi dimana hampir semua informasi bisa didapatkan di internet, dan turunnya kecenderungan sivitas menggunakan perpustakaan sebagai sumber informasi, maka perpustakaan juga harus dapat membuat informasinya sendiri dalam bentuk institutional repository yang bisa diakses
melalui
internet.
Dengan
demikian
perpustakaan
tetap
menyediakan sumber informasi berupa koleksi tercetak seperti biasanya, tetapi juga tetap relevan dalam era informasi saat ini sebagai penyedia informasi yang bisa diakses di internet, tidak hanya sebagai pengguna saja. 2. Upaya diseminasi informasi melalui world wide web dengan membangun search engine yang bertujuan membantu pengguna perpustakaan mencari dan membaca koleksi perpustakaan melalui internet. Seluruh institutional repository yang dimiliki perpustakaan dapat diakses melalui pencarian pada search engine ini. 3. Kakas otomasi yang selama ini dibangun menggunakan teknologi berbasis telnet diubah menjadi sistem yang berbasis web. Ini dilakukan dengan tujuan untuk memudahkan proses perawatan sistem karena upaya
53 perbaikan hanya perlu dilakukan pada satu komputer saja tanpa perlu melakukan update aplikasi pada komputer-komputer client.
Gambar IV.3. Faktor-faktor yang mempengaruhi kemampuan sistem informasi beradaptasi pada strategi perpustakaan Strategi perpustakaan nomor 3, yaitu mengembangkan sistem otomasi baru berbasis web ternyata menimbulkan kesulitan pada masa pengembangan dan
54 perawatan sistem tersebut. Hal ini disebabkan para programmer dan system analyst yang terlibat dalam pertimbangan walaupun memahami bagaimana sebuah sistem berbasis web dibangun dari sisi teknologi, tetapi belum benar-benar memahami konsekuensi penggunaan teknologi tersebut untuk membangun sistem dalam skala besar. Sistem yang baru terdiri dari 9 modul. Setiap modul adalah aplikasi yang berdiri sendiri yang melayani fungsi-fungsi yang terpisah dengan modul lainnya. Setiap modul membutuhkan antar muka, dan memiliki logika bisnis yang berbeda dengan modul lainnya. Persamaan dari modul-modul tersebut adalah mengakses basis data yang sama yang diintegrasikan dari struktur data yang dimiliki setiap modul. Konsekuensi yang belum benar-benar disadari akibatnya adalah tidak tersedianya kakas pengembangan (komponen) siap pakai yang bisa langsung dimanfaatkan oleh programmer seperti komponen-komponen bahasa pemrograman yang sudah mendukung rapid application development (RAD). Hal ini mengakibatkan setiap komponen harus dibuat sendiri oleh programmer, misalnya untuk mengakses database, menampilkan tabel yang awas terhadap data (data aware component), atau elemen antar muka yang dapat merefresh data secara otomatis. Sebagian besar elemen antar muka harus dibangun dengan kerja sama antara html, javascript, dan web scripting. Selain itu tidak adanya komponen siap pakai tersebut berarti untuk setiap antar muka baru programmer harus membuat ulang komponen tersebut (tidak adanya komponen yang bisa digunakan berulang-ulang, dan hanya perlu sedikit disesuaikan) terutama yang berhubungan dengan pembangunan antar muka dari setiap modul. Dengan jumlah antar muka yang cukup banyak ketiadaan komponen-komponen RAD menjadi faktor utama lambatnya proses pengembangan. Programmer juga dituntut untuk memahami daerah kemampuan yang lebih luas sekaligus, yaitu hypertext markup languange (HTML) yang bersifat crossbrowser, struktur navigasi situs yang baik, protokol http, interface berbasis web
55 yang baik, keamanan untuk internet, koneksi database, javascript, dan sekaligus web scripting seperti PHP. Hal ini tentunya membutuhkan waktu agar setiap programmer dapat menguasai semuanya. Hal yang juga menyebabkan proses pengembangan berjalan lambat (memakan waktu empat tahun untuk mengeluarkan release pertama) adalah kurangnya jumlah
programmer
yang
tersedia
pada
masa
pengembangan.
Jumlah
programmer yang tersedia sangat kecil bila dibandingkan jumlah modul yang harus dikembangkan, dan kompleksitas dalam setiap modul tersebut. Hal ini diperparah dengan adanya kebijakan “zero-growth” dari yayasan sehingga terjadi penurunan jumlah staf perpustakaan secara keseluruhan termasuk jumlah programmer akibat tidak ada pengganti untuk staf-staf yang mengundurkan diri. Penurunan jumlah staf juga mengganggu proses pengujian dalam proses pengembangan. Staf setiap divisi sudah memiliki beban kerja yang tinggi sehingga kesulitan menentukan waktu luang untuk melakukan pengujian sistem informasi yang baru. Pada proses pengembangan terdapat beberapa kendala yang kemudian diidenfitikasi sebagai manajemen proyek pengembangan yang kurang baik. Indikator terhadap adanya manajemen yang kurang baik adalah tidak adanya penentuan batas waktu penyelesaian secara definitif di awal proses pengembangan baik untuk penyelesaian seluruh sistem baru, setiap modul, atau penyelesaian bagian-bagian modul. Indikator kedua adalah proses evaluasi perkembangan proyek pengembangan yang juga tidak memadai. Di setiap awal bulan setiap programmer diminta membuat laporan mengenai apa yang dikerjakan pada bulan sebelumnya, apa kesulitan yang mereka hadapi, pilihan-pilihan apa yang mereka pertimbangkan, jalan keluar apa yang dipilih, dan apa kegiatan pengembangan yang akan mereka lakukan pada bulan tersebut. Koordinator divisi software development kemudian menentukan bagian-bagian modul mana yang sudah diselesaikan dan berapa presentase penyelesaian untuk modul tersebut. Kekurangan yang dihadapi adalah bagaimana menentukan presentase secara tepat, dan kemudian menentukan lama pengembangan hingga penyelesaian modul, dan sumber daya yang diperlukan. Kesulitan ini dialami karena memang tidak ada
56 batas waktu definitif yang ditentukan sejak awal, dan kesulitan mengenai prediksi sumber daya yang diperlukan. Kesulitan memprediksi sumber daya yang diperlukan meliputi berapa lama waktu pengerjaan yang dibutuhkan untuk pengembangan tiap bagian modul, dan apa saja kesulitan-kesulitan yang muncul ketika melakukan pengembangan tersebut bagian modul tersebut. Kesulitan ini sebagian besar diakibatkan oleh minimnya pengalaman programmer terhadap teknologi yang digunakan sehingga kurang benar-benar memahami apa yang diperlukan untuk menyelesaikan bagian modul tersebut. Proses pengembangan juga terganggu oleh adanya interupsi-interupsi baik dari dalam, maupun dari luar tim programmer. Interupsi dari luar adalah adanya keinginan untuk membuat modul baru yang belum pernah direncanakan sebelumnya. Modul baru ini adalah hasil dari pemikiran baru yang dirasa perlu untuk segera direalisasikan. Dengan demikian programmer harus menghentikan pekerjaan pengembangan yang saat itu sedang ditangani, dan beralih mengerjakan modul tersebut. Interupsi dari dalam tim programmer terjadi ketika pengerjaan sebuah modul yang ditangani oleh programmer lain ternyata mengubah struktur data, atau logika dari sebuah prosedur yang mempengaruhi modul yang saat itu sedang ia kerjakan. Secara otomatis programmer harus beralih dari pekerjaannya, dan kemudian mengubah bagian lain dari modul yang terpengaruh tersebut. Selain itu juga ada permintaan-permintaan data dari jurusan-jurusan yang tidak bisa ditangani oleh divisi Pengolahan. Permintaan data ini kemudian dialihkan pada programmer. Programmer diminta membantu karena memang jumlah staf teknologi informasi sangat minim sehingga programmer juga bertindak sebagai database administrator, dan system administrator dari sistem yang sudah ada. Pada proses pengembangan dokumen pengembangan tidak dibangun dengan baik. Akibatnya dokumen mengenai struktur program, fungsi-fungsi dan prosedur yang terdapat di dalamnya, dan logika dari sebuah prosedur tidak dicatat dengan baik. Hal ini berakibat pada pengembangan sebuah modul yang dialihkan pada programmer lain karena programmer tersebut mengundurkan diri, programmer baru membutuhkan waktu cukup banyak untuk melanjutkan pengembangan
57 karena harus membaca puluhan ribu kode-kode program untuk memahami logika sebuah bagian dari modul. Demikian juga terjadi proses pembuatan ulang prosedur yang berfungsi sama (ada duplikasi prosedur) karena tidak adanya dokumen yang mencatat adanya prosedur tersebut. Proses pengembangan sebuah modul akan menghasilkan bug-bug yang perlu diperbaiki baik pada masa pengembangan itu sendiri, atau pada masa perawatan. Masalah yang dihadapi dalam upaya memperbaiki bug adalah ketidakjelasan jalur komunikasi antara pengguna sistem (staf perpustakaan) dengan programmer. Sering terjadi silang pendapat antara permintaan staf perpustakaan dengan perintah kerja yang didapatkan dari divisi System Development. Staf terkadang menghubungi langsung programmernya sehingga terjadi kebingungan pada programmer mengenai apa yang seharusnya dikerjakan / diperbaiki karena memiliki perbedaan dengan informasi yang didapatkan dari divisi System Development. Selain itu bila ada informasi mengenai sebuah bug tidak dilakukan upaya klasifikasi dan identifikasi awal, dan dokumentasi terhadap bug tersebut. Padahal tidak semua bug perlu diperlakukan sama prioritasnya, dan dokumentasi atas bug-bug yang ditemukan dapat dianalisa untuk proses pengembangan selanjutnya baik untuk membantu prediksi yang lebih baik, juga bila ditemukan bug yang sama maka akan diketahui jalan keluar yang paling baik. Kakas identifikasi dan dokumentasi bug sebenarnya sudah tersedia, tetapi programmer merasa lebih cepat bila langsung mengerjakan perbaikan bug daripada lebih dulu mencatat bug tersebut menggunakan kakas yang sudah disediakan. Masalah yang dihadapi pada masa perawatan juga sama, yaitu tidak adanya dokumentasi pengembangan yang mengakibatkan programmer yang menangani perawatan mengalami kesulitan memahami logika kode-kode modul tersebut dengan cepat. Hal yang juga perlu diperhatikan adalah dalam masa pengembangan dan perawatan
programmer
harus
memutuskan
cara
terbaik
untuk
mengimplementasikan sebuah prosedur, atau logika bisnis dari modul. Untuk itu programmer membutuhkan masukan-masukan yang dapat membantu programmer memutuskan cara tersebut. Pada kasus ini programmer merasa sangat terbantu
58 dengan adanya internet dimana ia dapat langsung memanfaatkan search engine yang ada di internet untuk memahami konsep teknologi tertentu, atau cara-cara terbaik (best practices) dalam menyelesaikan sebuah masalah. Kekurangan yang dialami programmer adalah jumlah buku yang berhubungan dengan teknologi yang dipakai masih terbatas, dan masih harus berbagi dengan pengguna perpustakaan. Selain itu karena adanya keterbatasan programmer senior, maka ada waktunya dimana programmer senior tidak tersedia untuk membantu programmer paruh waktu dalam menyelesaikan pekerjaannya. Pada masa implementasi dan pengoperasian sistem baru muncul masalah pada konversi sistem lama ke sistem yang baru. Masalah ini disebabkan adanya ketidaksempurnaan desain, dan kesalahan penggunaan sistem lama, yaitu: 1. Desain database lama yang tidak memperhatikan masalah constraint dan relation antar tabel. Tidak ada relation antar tabel membuat data-data yang seharusnya bisa dibatasi oleh isi tabel yang lain tidak dapat diawasi dan diperiksa oleh database engine. 2. Desain software yang tidak memperhatikan constraint. Seharusnya bila database tidak dilengkapi dengan constraint, maka software harus dilengkapi dengan fasilitas pemeriksaan data ini (walaupun tidak seefisien pemeriksaan melalui constraint di database). Hal ini tidak dipenuhi sehingga data-data salah dapat masuk ke dalam database. 3. Adanya kesalahan-kesalahan pengisian data, misalnya nama-nama penerbit, subyek yang memiliki perbedaan antar record karena kesalahan ketik. Kesalahan ini sesungguhnya bisa diatasi dengan adanya desain software yang memperhatikan masalah minimalisasi kesalahan manusia dalam pengisian data. Akibat kekurangan pada sistem lama membuat pengoperasian sistem baru harus memperhatikan masalah perbaikan data, dan struktur data. Sistem informasi yang baru menuntut seluruh data yang dipindahkan dari sistem lama sudah dalam kondisi benar. Hal ini menjadi tuntutan karena sistem baru telah menerapkan constraint yang ketat sehingga tidak ada data salah yang diijinkan masuk. Hal ini membuat kerja divisi Pengolahan bertambah berat karena harus memperbaiki
59 ribuan record data yang mengalami kesalahan data tersebut sebelum dapat dimigrasi ke sistem baru. Selain itu sivitas pengguna sistem baru harus menyadari bahwa data yang tertampil pada katalog sistem baru bukanlah data yang lengkap karena sebagian data masih belum dapat ditambahkan pada database sistem yang baru. IV.7 Pembentukan Pola atas Faktor-faktor yang Ditemukan Bila faktor-faktor yang mempengaruhi kemampuan sistem informasi diadaptasi yang ditunjukkan pada gambat IV.3 disederhanakan, maka hasilnya ditunjukkan pada gambar IV.4.
Gambar IV.4. Faktor-faktor yang mempengaruhi kemampuan adaptasi sistem informasi Pada gambar IV.4 ditunjukkan bahwa keterbatasan wawasan staf teknologi informasi adalah penyebab kesalahan pembentukan strategi bisnis, dimana di dalamnya terdapat kesalahan pembentukan strategi sistem informasi. Strategi bisnisnya sendiri pada dasarnya belum menunjukkan kesalahan, yaitu penggunaan web sebagai platform sistem informasi selanjutnya, tetapi strategi sistem informasi memiliki kekurangan, yaitu penentuan kakas pengembangan berbasis web yang memiliki keterbatasan-keterbatasan yang membuat pengembangan sistem informasi tidak efisien untuk tim programmer yang berjumlah kecil. Tetapi karena strategi sistem informasi adalah bagian dari strategi bisnis, maka secara keseluruhan strategi bisnis juga dapat dianggap memiliki kesalahan. Kesalahan
60 strategi bisnis ini dipacu oleh keterbatasan wawasan staf teknologi informasi mengenai konsekuensi dari teknologi yang digunakan. Keterbatasan kakas ini akhirnya mempengaruhi proses pengembangan dan perawatan sistem informasi. Faktor-faktor lain yang juga mempengaruhi adalah: 1. Kurangnya jumlah staf (baik perpustakaan, maupun teknologi informasi) dalam masa pengembangan, dan jumlah programmer pada masa perawatan sistem informasi. 2. Dokumen pengembangan yang tidak lengkap yang mengakibatkan terjadinya
pemrograman
berulang,
dan
transfer
pekerjaan
antar
programmer menjadi lambat. 3. Manajemen proyek pengembangan yang tidak memadai karena tidak adanya kejelasan batas waktu pengembangan, evaluasi kinerja dan upaya prediksi beban kerja yang tidak memadai. 4. Tidak memadainya manajemen proyek disebabkan tim programmer sendiri tidak memiliki kemampuan untuk hal tersebut. 5. Adanya interupsi pekerjaan baik yang berasal dari dalam maupun di luar tim programmer. 6. Masalah dalam penanganan bug-bug yang diidentifikasi meliputi tidak jelasnya jalur komunikasi penanganan bug, kakas identifikasi tidak digunakan maksimal, dan tidak ada penentuan klasifikasi dan prioritas penangan bug. IV.8 Validasi Hasil Analisis Dalam studi kualitatif istilah yang sering digunakan adalah verifikasi, walaupun di dalam istilah tersebut terkandung makna validasi. Demikian juga studi kuantitatif sering menggunakan istilah validasi, walaupun dalam istilah tersebut sebenarnya juga mengandung makna verifikasi. Studi kualitatif lebih suka menggunakan istilah verifikasi karena data-data yang diperoleh dalam operasionalisasi studi biasanya didapatkan dari orang, sedangkan studi kuantitatif memperoleh data-data studi dari eksperimen, penyebaran
61 kuesioner (dimana konteks yang berbeda dari setiap orang tidak terlalu diperhatikan dalam data-data tersebut). Validasi adalah tingkat pencapaian kebenaran (approximate of truth) dari sebuah kesimpulan (propositions, inferences, atau conclusions). Seperti halnya studi kualitatif, validasi dalam penelitian Grounded Theory diperhatikan dalam dua area, yaitu validasi internal, dan validasi eksternal [11] [29]. IV.8.1 Validasi Internal Validasi internal adalah upaya untuk memastikan keakuratan dari informasi yang didapatkan dalam studi, dan apakah informasi tersebut sesuai dengan realita sesungguhnya. Sesuai pengertian di atas, peneliti harus memastikan bahwa persepsinya tidak mengganggu interpretasi dari data-data yang dikumpulkan. Seluruh kategori-kategori yang diangkat dari data-data yang terkumpul harus sesuai dengan persepsi orang yang diwawancarai, bukan persepsi dari peneliti itu sendiri. Biasanya peneliti akan melakukan verifikasi pada setiap orang yang terlibat sebagai partisipan dengan mengkonfirmasi apakah kategori-kategori tersebut dapat diterima oleh partisipan, dan apakah makna (meaning) dari setiap kategori sesuai dengan persepsi partisipan. Pada penelitian ini telah dilakukan upaya verifikasi hasil wawancara kepada setiap partisipan yang dilibatkan dalam wawancara untuk melihat apakah hal-hal penting yang didapatkan melalui wawancara disimpulkan secara benar sesuai dengan persepsi partisipan sendiri. Tujuan kedua verifikasi adalah apakah tidak ada halhal yang terlewat yang mungkin dianggap kurang penting bagi peneliti, tetapi adalah hal yang penting bagi partisipan. Upaya verifikasi dilakukan dengan menulis ulang wawancara verbal dengan menggunakan kalimat peneliti sendiri, dan memberikan kategori yang dianggap sesuai dengan bagian wawancara tersebut. Dokumen tersebut kemudian dikirimkan kepada setiap partisipan untuk dinilai apakah tidak ada yang terlewat, dan apakah makna (kategori) yang diberikan peneliti pada bagian wawancara
62 tersebut telah tepat. Penggunaan kalimat sendiri dalam menulis wawancara verbal penting dilakukan karena pada penelitian ini setelah wawancara verbal dilakukan, rekaman suara wawancara tidak dimasukkan pada proses transcribing, yaitu mengubahnya menjadi skrip wawancara untuk kalimat per kalimat yang diucapkan baik partisipan maupun peneliti. Proses transcribing dapat memakan waktu sangat lama. Untuk itu peneliti memutar ulang rekaman setiap wawancara beberapa kali dan menuliskan hal-hal penting yang didapatkan dari wawancara tersebut. Hal-hal penting tersebut kemudian ditulis ulang menggunakan kalimat peneliti sendiri untuk menjamin bahwa peneliti benar-benar mengerti apa yang dimaksudkan oleh partisipan. IV.8.2 Validasi Eksternal Validasi eksternal berarti generalization. Validasi eksternal berarti upaya memastikan bahwa kesimpulan-kesimpulan tersebut tetap dapat memenuhi tingkat kebenaran bila diaplikasikan pada konteks di luar konteks penelitian (tempat, waktu, orang, atau situasi yang berbeda). Karena itu validasi eksternal berarti generalization [29]. Studi kualitatif terutama yang menggunakan metode case study, dan ethnography biasanya tidak memusingkan masalah generalization karena justru tujuan studistudi tersebut adalah mengungkap sebuah konteks tertentu, bukan untuk diaplikasikan secara umum atau luas. Grounded theory dan phenomenology biasanya menggunakan konteks penelitian yang lebih luas dibandingkan case study, dan ethnography. Karena itu grounded theory dan phenomenology pada tingkat tertentu harus memperhitungkan masalah validasi eksternal (generalisasi teori). Secara umum teori yang dihasilkan oleh grounded theory dan phenomenology dianggap dapat diaplikasikan pada konteks yang lebih luas dari konteks yang menjadi konteks penelitian. Tetapi bagaimanapun juga grounded theory dan phenomenology adalah studi kualitatif yang dilaksanakan pada konteks yang terbatas, sehingga perlu ada upaya yang membicarakan kondisi-kondisi apa saja
63 yang membuat hasil studi tidak dapat diaplikasikan pada konteks yang lebih luas. Karena itu peneliti harus membahas ancaman terhadap validasi eksternal (threat of external validity). Ancaman pada validasi eksternal pada peneltian ini adalah: 1. Organisasi yang menjadi konteks penelitian ini membangun sendiri seluruh sistem yang dibutuhkan. Tidak ada pembelian sistem lain, atau perlunya integrasi dengan sistem lain. Hasil penelitian ini mungkin tidak dapat diaplikasikan pada organisasi yang membeli seluruh sistem informasinya dari satu atau beberapa pihak ketiga, atau mengintegrasikan sistem yang dibangun sendiri dengan sistem dari pihak ketiga tersebut. 2. Konteks penelitian ini membahas perubahan strategi bisnis yang memberikan cukup waktu bagi organisasi mengembangkan sistem informasinya. Hasil penelitian ini mungkin tidak dapat diaplikasikan bila terjadi perubahan-perubahan strategi bisnis yang lebih cepat daripada waktu
pengembangan
sistem
informasi
(bila
dalam
satu
masa
pengembangan sistem organisasi harus mengubah strategi bisnisnya beberapa kali). 3. Organisasi yang menjadi konteks dalam penelitian ini memiliki staf teknologi informasi dalam jumlah kecil (empat orang staf tetap, ditambah 1 – 2 staf paruh waktu). Bila sebuah organisasi memiliki jumlah staf teknologi informasi yang besar atau mencukupi, kondisi yang dibutuhkan oleh sebagian besar kategori dan konsep untuk terjadi tidak terpenuhi.
