SUKSES DAN KEGAGALAN SISTEM : SEBUAH

IMPLEMENTASI Tantangan manajemen

Gagal proyek seperti Ferndale tidak terbatas pada inisiatif di World

Wide Web dan
Internet. Ada tingkat kegagalan yang sangat tinggi di antara proyek-proyek
informasi sistem konvensional juga. Dalam hampir setiap organisasi, sistem
informasi proyek membutuhkan lebih banyak waktu dan uang untuk
melaksanakan daripada yang diantisipasi, atau sistem selesai tidak bekerja
dengan benar. Sebagian dari masalah ini disebabkan oleh teknologi sistem
informasi, tapi banyak dapat dikaitkan dengan faktor manajerial dan
organisasional. Menerapkan sistem informasi adalah suatu proses perubahan
organisasi, dan Anda harus menyadari tantangan manajemen berikut:

1. Organisasi
inersia.
Dengan tidak adanya krisis organisasi, sulit untuk memusatkan perhatian
organisasi dan sumber daya pada pengembangan sistem baru karena
organisasi sangat resisten terhadap perubahan. Banyak pengembangan
sistem skala besar dimulai pada masa krisis organisasi, dan tidak
direncanakan. Periode ini tidak cocok untuk perencanaan rasional
dan implementasi.

2. Berurusan dengan kompleksitas sistem proyek

berskala besar.
Sistem yang besar-besaran yang mempengaruhi sejumlah besar unit
organisasi dan anggota staf dan yang memiliki persyaratan informasi yang
luas sulit untuk mengawasi, mengkoordinasikan, dan merencanakan.
Melaksanakan sistem seperti ini, yang memiliki periode pembangunan
multi-tahun, khususnya masalah-berkuda karena sistem
sangat kompleks.

3. Memperkirakan waktu dan biaya untuk menerapkan sistem informasi

yang sukses besar.
Ada beberapa teknik yang dapat diandalkan untuk memperkirakan waktu dan
biaya untuk mengembangkan menengah-untuk sistem informasi berskala
besar. Beberapa proyek memperhitungkan biaya pemeliharaan jangka
panjang dari sistem. Pedoman disajikan dalam bab ini adalah membantu
tetapi tidak dapat menjamin bahwa informasi proyek sistem yang besar
dapat tepat direncanakan dan diberi anggaran yang
diproyeksikan.

Ketika sistem informasi gagal bekerja dengan baik atau terlalu banyak
biaya untuk mengembangkan, perusahaan mungkin tidak menyadari manfaat
dari investasi sistem mereka informasi dan sistem tidak mungkin dapat
memecahkan masalah bagi yang dimaksudkan. Karena sistem informasi begitu
banyak masalah-dikuasai, desainer, kontraktor, dan pengguna sistem informasi
harus memahami bagaimana dan mengapa mereka berhasil atau gagal. Bab ini
mengeksplorasi faktor-faktor manajerial, organisasi dan teknologi bertanggung
jawab atas keberhasilan dan kegagalan sistem informasi dan memeriksa proses
implementasi sistem.

Sebanyak 75 persen dari semua sistem yang besar dapat dianggap

sebagai operasi kegagalan. Walaupun sistem ini dalam produksi, mereka
mengambil begitu banyak waktu ekstra dan uang untuk melaksanakan atau
begitu fungsional kekurangan bahwa bisnis cant menuai keuntungan
yang diharapkan. Sebuah studi 1994 oleh Standish Group International Inc
menemukan bahwa 31 persen dari semua proyek pengembangan perangkat
lunak perusahaan dibatalkan sebelum selesai. Lima puluh satu persen biaya dua
atau tiga kali jumlah yang dianggarkan dan mengambil tiga waktu yang lebih
lama dari yang diharapkan untuk menyelesaikan (Bulkeley,
1996).

Banyak sistem informasi "kegagalan" tidak selalu gagal terpisah, tapi

entah mereka jelas tidak digunakan dalam cara mereka dimaksudkan atau
mereka tidak digunakan sama sekali. Pengguna harus mengembangkan
prosedur manual paralel untuk membuat sistem ini bekerja dengan baik.
Sebagai contoh, imbalan kerja departemen dari perhatian manufaktur multi unit
terus mempertahankan semua data keuntungan bagi 20.000 karyawan
perusahaan secara manual, meskipun kehadiran sistem, otomatis online untuk
manfaat asuransi pensiun dan kehidupan. Pengguna mengeluh bahwa data
dalam sistem tidak dapat diandalkan karena mereka tidak menangkap manfaat
rencana sebelum data untuk karyawan dari akuisisi dan karena gaji angka
penghasilan yang ketinggalan zaman. perhitungan pensiun Semua, perkiraan
preretirement, dan analisis manfaat harus
ditangani secara manual.

Dalam beberapa sistem, hampir semua mengeluarkan laporan untuk

manajemen tidak pernah dibaca. Mereka dianggap tidak berharga dan penuh
tokoh tidak ada konsekuensi untuk membuat keputusan atau analisis (Lucas,
1981). Sebagai contoh, manajer di sebuah bank komersial terkemuka dengan
kantor cabang di seluruh Amerika Serikat dan Eropa menemukan batch pinjaman
sistem rekening hampir tidak berguna. Halaman laporan diisi dengan nol,
sehingga hampir mustahil untuk menilai status pinjaman klien. Jumlah pinjaman,
saldo, dan jadwal pembayaran harus dilacak secara manual. Bank juga sangat
tidak puas dengan klien online sistem pelaporan. Meskipun, bank dipelihara fle
pada semua area untuk account klien (kredit, tabungan, rekening pensiun
individu, memeriksa), hanya memeriksa dan data rekening tabungan yang
tersedia secara online. Oleh karena itu, manajer dan analis tidak bisa
mendapatkan klien profl lengkap saat mereka membutuhkan mereka.

Sistem otomatis lain pergi tak tersentuh karena mereka terlalu sulit untuk
menggunakan atau karena data mereka tidak bisa dipercaya. Pengguna
terus mempertahankan data secara manual. Sebagai contoh, suatu bentuk
merekrut dikenal secara nasional eksekutif menemukan bahwa laporan
penting tentang aktivitas pencarian secara rutin tiga bulan dari tanggal.
Perusahaan telah mengembangkan statistik secara manual pada jumlah
pencarian eksekutif dimulai pada bulan tertentu. Perekrut tidak memiliki cara
untuk melacak dan koordinasi pencarian di antara kantor cabang perusahaan
di New York, Chicago, Houston dan Los Angeles.

Masih sistem lainnya menggelepar karena keterlambatan pemrosesan,

biaya operasional yang berlebihan, atau masalah produksi kronis. Sebagai
contoh, sistem batch akun piutang dari produsen produk konsumen menengah
selalu melanggar bawah. berjalan Produksi telah membatalkan beberapa kali
sebulan, dan besar akhir bulan berjalan yang hampir tiga minggu di belakang
jadwal. Karena tayangan ulang yang berlebihan, keterlambatan jadwal, dan
waktu yang dihabiskan untuk memperbaiki program kuno, sistem informasi
staf tidak punya waktu untuk bekerja mencari solusi jangka
panjang atau dikonversi ke sistem online. Dalam semua kasus ini,
sistem informasi yang bersangkutan harus dinilai kegagalan. Mengapa terjadi
kegagalan sistem?
Area Permasalahan Sistem Informasi

Masalah yang menyebabkan kegagalan sistem informasi jatuh ke dalam

beberapa kategori, seperti yang digambarkan oleh Gambar 14.1. Area Masalah
utama adalah desain, data, biaya dan operasi. Masalah ini dapat dikaitkan
tidak hanya untuk ftur-ftur teknis sistem informasi tetapi
sumber nonteknis juga. Pada kenyataannya, sebagian besar masalah berasal
dari faktor organisasi.

Dat
a

Siste Desain
Opera
m
si
Informa
si

Biay
a

Gambar
14.1

Desain

Rancangan sebenarnya sistem gagal untuk menangkap persyaratan

bisnis yang penting atau meningkatkan kinerja organisasi. Informasi tidak
dapat diberikan cukup cepat untuk membantu, mungkin dalam format yang
tidak mungkin untuk dicerna dan digunakan, atau mungkin mewakili potongan-
potongan yang salah data.

Cara di mana pengguna bisnis non-teknis harus berinteraksi dengan

sistem mungkin terlalu rumit dan mengecilkan hati. Suatu sistem dapat
dirancang dengan user interface yang miskin. Antarmuka pengguna adalah
bagian dari sistem dengan mana pengguna akhir berinteraksi. Sebagai contoh,
bentuk masukan atau layar online dapat menjadi begitu buruk diatur bahwa tidak
ada yang mau mengirimkan data. Prosedur untuk meminta pengambilan
informasi online mungkin sangat
dimengerti bahwa pengguna terlalu frustrasi untuk membuat permintaan.
Sebuah antarmuka pengguna grafis yang seharusnya intuitif mudah untuk
belajar mungkin enggan untuk menggunakan karena tampilan layar yang
berantakan dan buruk diatur atau karena pengguna tidak memahami makna dan
fungsi dari ikon. Sebagai contoh, sebagian besar pengguna dari Microsoft
Publisher tidak memahami sebuah ikon dengan panah menunjuk keempat arah
yang dimaksudkan untuk menandakan bahwa mereka bisa bergerak kotak ke
segala arah di sekitar layar. Masalah ini terpecahkan ketika programmer
tertanam sebuah truk bergerak dengan kata bergerak di atasnya di dalam tanda
panah empat (Bulkeley, 1992). Persentase yang tinggi dari perangkat lunak
bisnis mengembangkan atau dibeli oleh perusahaan berjalan tidak terpakai atau
kurang dimanfaatkan karena tidak memiliki user interface yang sesuai.

Sebuah sistem informasi akan dinilai gagal jika desainnya tidak

kompatibel dengan budaya, struktur dan tujuan organisasi secara keseluruhan.
Seperti yang ditunjukkan dalam Bab 3, teori organisasi manajemen dan
teknologi informasi telah dilihat sistem sebagai erat terkait dengan semua
komponen lain dari organisasi-tugas, struktur, orang dan budaya. Karena
semua komponen ini saling terkait, perubahan dalam satu akan mempengaruhi
semua yang lain. Oleh karena itu, tugas organisasi peserta, struktur, dan budaya
pasti akan terpengaruh ketika suatu sistem informasi berubah. Merancang sistem
pendesainan ulang organisasi.

Secara historis, desain sistem informasi telah sibuk dengan masalah

teknis dengan mengorbankan keprihatinan organisasi. Hasilnya telah sering
sistem informasi yang secara teknis sangat baik tetapi tidak sesuai dengan
struktur organisasi kebudayaan mereka, dan tujuan. Tanpa cocok organisasi
dekat, sistem tersebut telah menciptakan ketegangan, ketidakstabilan dan
konfik.

Dat
a

Data dalam sistem tersebut memiliki tingkat tinggi ketidaktepatan atau

inkonsistensi. Informasi dalam bidang-bidang tertentu mungkin saja salah atau
ambigu, atau mereka mungkin tidak pecah baik untuk tujuan bisnis. Informasi
yang diperlukan untuk fungsi bisnis tertentu mungkin tidak dapat diakses karena
data tidak lengkap.

Biay
a

Beberapa sistem seperti opera sabun Ferndale multimedia online

beroperasi cukup lancar, tetapi biaya untuk melaksanakan dan menjalankan
secara produksi adalah cara di atas anggaran. Sistem lain mungkin mahal untuk
bersaing. Dalam kedua kasus, pengeluaran yang berlebihan tidak dapat
dibenarkan oleh nilai bisnis menunjukkan dari informasi yang mereka sediakan.

Opera
si
 Sistem ini tidak berjalan dengan baik. Informasi tidak diberikan secara
tepat waktu dan efsien karena operasi komputer yang menangani pengolahan
informasi rusak. Pekerjaan yang membatalkan terlalu sering menyebabkan
reruns berlebihan dan jadwal tertunda atau terlewatkan untuk pengiriman
informasi. Sebuah sistem online mungkin operasional tidak memadai karena
waktu respon terlalu panjang.
Mengukur Kesuksesan Sistem

Bagaimana kita mengatakan bahwa sebuah sistem disebut sukses? Ini

bukanlah sebuah pertanyaan yang bisa dijawab dengan mudah. Tidak semua
orang setuju tentang nilai keefektifan sistem informasi tertentu. Setiap individu
dengan cara pengambilan keputusan yang berbeda atau cara pendekatan
masalah yang berbeda mungkin saja memiliki pendapat yang jauh berbeda
tentang sebuah sistem yang sama. Sebuah sistem sangat dinilai dengan sebuah
analisis, user yang beroriatasi pada jumlah mungkin dihilangkan dengan
pemikiran intuitif yang lebih banyak berkonsentrasi dengan perasaan dan
anggapan. Demikian juga, seorang manajer penjualan junior dengan gelar
MBA yang baru saja didapatkannya dalam bidang penjualan mungkin akan lebih
menghargai laporan sistem informasi dalam bidang karakter demografis dari
wilayahnya daripada seseorang yang telah berpengalaman yang telah bekerja
pada wilayah yang sama selama 15 tahun dan mengetahui hal itu dengan
hatinya. Persepsi dan penggunaan dari sistem informasi bisa dikondisikan
dengan variabel pribadi dan situasi(Lucas, 1981). Apa yang dikatakan pengguna
apakah yang mereka sukai atau inginkan di dalam sistem informasi mungkin
tidak membutuhkan sebuah peningkatan berharga di dalam kinerja organisasi
(markus and Keil, 1994).

Meskipun demikian, peneliti MIS telah melihat seperangkat ukuran formal

untuk menilai sistem. Berbagai macam kriteria telah dikembangkan, akan tetapi
ukuran kesuksesan sistem seperti yang diperlihatkan pada Gambar 2 dianggap
paling penting.

1. Penggunaan sistem level tinggi, sebagaimana diukur dengan polling

pengguna, memberikan kuesioner, atau memantau parameter-parameter
seperti volume transaksi.
2. Kepuasan pengguna pada sistem, sebagaimana diukur oleh kuesioner
atau wawancara. Hal ini mungkin termasuk pendapat pengguna pada
akurasi, aktualitas, dan kerelevanan informasi, kualitas servis, dan
mungkin pada jadwal operasinya. Yang paling penting adalah perilaku
manajer pada sejauh mana tingkat kepuasannya terhadap informasi yang
dibutuhkannya (Ives et al., 1983; Westcott, 1985) dan pendapat
pengguna tentang bagaimana sistem meningkatkan kinerja mereka
(Davis, 1989).
3. Perilaku menguntungkan dari pengguna sistem informasi dan staf sistem
informasi.
4. Tercapainya tujuan sistem, tingkat di mana sistem dapat mencapai tujuan
tertentu, sebagaimana ditunjukkan dengan peningkatan kinerja
organisasi dan pengambilan keputusan yang dihasilkan oleh sistem.
5. Pembayaran fnansial kepada organisasi, baik dengan mengurangi biaya
atau meningkatkan
penjualan atau keuntungan.

Ukuran
kesuksesan
sistem informasi
Penggunaan Kepuasan Perilaku Tercapainya Pembayaran
sistem level pengguna menguntungkan tujuan finansial
tinggi pada sistem dari fungsi sistem
sistem
 Gambar 14.2. Ukuran kesuksesan sistem

Kelima ukuran dianggap menjadi nilai batas walaupun analisis keuntungan

biaya mungkin digambarkan dengan berat di dalam keputusan untuk
membangun sebuah sistem tertentu. Keuntungan dari sebuah sistem
informasi mungkin tidak secara keseluruhan dapat diperhitungkan. Terlebih
lagi keuntungan nyata tidak dapat dengan mudah ditunjukkan untuk aplikasi
sistem pendukung keputusan tingkat lanjut. Dan meskipun metodologi
keuntungan telah diikuti secara akurat , sejarah banyak proyek
pengembangan sistem telah menunjukkan perkiraan nyata ini selalu sulit
untuk diformulasikan. Peneliti MIS telah lebih suka berkonsentrasi pada
ukuran manusia dan organisasi pada kesuksesan sistem seperti kualitas
informasi, kualitas sistem, dan pengaruh sistem pada kinerja organisasi
(Lucas, 1981; DeLone and McLean, 1992).

Penyebab Kesuksesan dan Kegagalan Sistem Informasi

Sistem dikembangkan di tempat pertama, karena kekuatan lingkungan

eksternal dan kekuatan internal atau konstitusional yang sama. Banyak
sistem gagal karena penganturan lingkungan dan internal yang berlawanan.

Sebagaimana ditunjukkan oleh banyak peneliti MIS, pengenalan atau

pengubahan sebuah sistem informasi memiliki pengaruh organisasi dan
perilaku yang tinggi. Dia mengubah cara bagi beragam kelompok dan invidu
untuk bertidak dan berinteraksi. Mengganti cara pendefnisian informasi, dan
digunakan untuk mengatur sumber daya-sumber daya organisasi seringkali
mengarah kepada distribusi baru dari autoritas dan kekuatan (Lucas, 1975).
Organisasi internal ini mengganti keturunan resisten dan berlawanan dan
dapat pula mengarahkan kepada kematian dari sebuah sistem yang baik.
Karakterisitik yang penting dari kebanyakan sistem informasi adalah
bahwa permintaan individu atau kebutuhan untuk mengganti perilakunya
untuk membuat fungsi sistem.

Akan tetapi ada banyak alasan lain kegagalan sistem. Beberapa penelitian
telah menemukan bahwa di dalam organisasi dengan ftur lingkungan dan
institusi yang sama, maka inovasi yang sama akan sukses untuk beberapa
organisasi namun gagal pada yang lainnya (Robey and Sahay,
1996). Salah satu penjelasannya yaitu pada pola implementasi yang berbeda.

Konsep Implementasi

Implementasi merujuk kepada semua kegiatan organisasi meliputi adopsi,

manajemen, dan rutinitas inovasi. Gambar 14.3 mengilustrasikan tahapan
implementasi yang dijelaskan pada
literatur riset dan pendekatan utama pada subjek.

TAHAP
PENDEKATAN
Adops IMPLEMENTASI
Manajemen Rutinitas
Peranan Pelaku i
XXX XXX
Strate X X
XXX
Faktorgi X
XXX XXX
Organisasi X
Gambar 14.3. Tahap Pendekatan X
dan Implementasi
 Beberapa riset implementasi berfokus pada pelaku dan peranan.
Kepercayaan tersebut adalah bahwa organisasi harus memilih pelaku
dengan karakteristik sosial tepat dan peranan
pengembangan oraganisasi secara sistematis, seperti product champion
untuk membawa inovasi dengan sukses, seperti ditunjukkan oleh Gambar
14.4. Secara umum, literatur ini fokus pada adopsi terdahulu dan manajemen
inovasi.

Karakteristik pelaku
dan demografi
- Status sosial
- Pendidikan
- Canggih

Perilaku inovatif

Peranan Pelaku
- Product champion
- Wiraswasta
birokratis
- Penjaga gate

Gambar 14.4. Proses Pelaku

dan Inovasi

Sekolah kedua dari gagasan dalam literatur implementasi fokus pada

strategi inovasi. Dua yang paling ekstrim adalah inovasi top-down dan
grassroot. Banyak perusahaan yang mengabaikan dukungan manajemen
untuk inovasi proyek dari permulaan. Pada waktu yang sama, tanpa
grassroot yang kuat, partisipasi penggunaan akhir dan proyek sistem
informasi bisa juga gagal.

Pendekatan ketiga untuk mengimplementasikan fokus pada faktor

pergantian organisasi umum yang menentukan rutin inovasi jangka panjang.
Tabel 1 mengilustrasikan beberapa kunci aksi organisasi yang dibutuhkan
untuk jangka panjang, kesuksesan implementasi, dan indikator kesuksesan
(Yin, 1981). Aksi untuk meningkatkan pembelajaran organisasi dan
menangani
kendala untuk memperoleh pengetahuan baru dan praktik juga sangat
berguna (Attewall, 1992).

Aksi dan Indikator untuk Implementasi Kesuksesan Sistem

Didukung oleh dana lokal
Penyusunan organisasi yang baru
Persediaan yang stabil dan pemeliharaan
Klasifikasi personal baru
Perubahan dalam otoritas organisasi
Internalisasi dalam program training
Perbaruan sistem yang berkelanjutan
Promosi personal kunci
Bertahannya sistem setelah pergantian
Pencapaian penggunaan yang meluas
Sumber : Yin(1981)
Tabel 1. Pelaku dan Indikator untuk Kesuksesan
Implementasi Sistem

Di dalam konteks implementasi, sistem analis merupakan agen

perubahan. Analis tidak hanya mengembangkan solusi teknis, akan tetapi
juga mendefnisi ulang konfgurasi, interaksi, aktiftas, dan relasi kekuatan
dari kelompok organisasi yang bervariasi. Analis merupakan katalis untuk
proses perubahan secara keseluruhan dan bertanggung jawab untuk
memastikan bahwa perubahan yang dibuat oleh sebuah sistem baru diterima
oleh semua pihak yang terlibat. Agen
 perubahan berkomunikasi dengan pengguna, perantara antara kelompok
yang tertarik, dan memastikan bahwa peraturan organisasi untuk pergantian
ini sudah lengkap.

Satu model dari proses implementasi adalah model Kolb/Frohman

dari pergantian organisasi. Model ini membagi proses prubahan organisasi
menjadi 7 tahap relasi antara seorang konsultan organisasi dan klient-nya.
Kesuksesan usaha perubahan ditunjukkan oleh seberapa baik kesepakatan
konsultan dan klient pada persoalan pokok untuk setiap tahap (Kolb and
Frohman, 1970). Model lain dari implementasi menggambarkan
menggambarkan relasi sebagai kesatuan antara designer, klien, dan pembuat
keputusan, yang bertanggung jawab untuk mengatur usaha implementasi
untuk menjembatani jurang pemisah antara design dan manfaat (Swanson,
1988). Pekerjaan terbaru pada implementasi menekankan pada
kebutuhan feksibelitas dan peningkatan dengan pelaku organisasi tidak
dibatasi untuk peranan tetap yang kaku (Markus and Benjamin, 1997;
Orlikowski and Hofman, 1997).

Pembelajaran proses implementasi mempelajari relasi antara designer

sistem informasi dan pengguna pada tahap yang berbeda dari
pengembangan sistem. Pembelajaran telah berfokus pada beberapa isu
berikut :

Konfik antara orientasi teknis atau mesin dari spesialis sistem

informasi dan organisasi atau orientasi bisnis pengguna.
Pengaruh sistem informasi pada struktur organisasi, kelompok kerja, dan
perilaku
Perencanaan dan manajemen aktifitas pengembangan sistem
Derajat partisipasi pengguna di dalam proses design dan
pengembangan.

Penyebab Kesuksesan dan Kegagalan

Pengembangan

Riset implementasi hingga saat ini menemukan tidak ada sebuah

penjelasan untuk kesuksesan dan kegagalan sistem. Juga tidak menyarankan
formula untuk kesuksesan sistem. Bagaimanapun mereka menemukan bahwa
penghasilan implementasi dapat digambarkan dengan faktor-faktor berikut :

Peranan pengguna dalam proses implementasi

Derajat dukungan manajemen untuk usaha implementasi
Level kompleksitas dan resiko proyek implementasi
Kualitas manajemen proses implementasi
 Hal ini ditunjukkan pada Gambar 14.5
Keterlibatan dan PENGHASILAN
pengaruh IMPLEMENTASI
pengguna

Dukungan
manajemen
Design Biaya
Data Operasi

Level
kekomplekan/
resiko

Manajemen
proses
implementasi

Gambar 14.5. Faktor Keberhasilan dan Kegagalan Sistem

Informasi

Keterlibatan dan Pengaruh Pengguna

Keterlibatan pengguna dalam design dan operasi sistem informasi

memiliki beberapa hasil positif. Pertama, apabila pengguna terlibat
banyak dalam design sistem, mereka memiliki kesempatan untuk
membentuk sistem sesuai dengan prioritas dan kebutuhan bisnis mereka dan
banyak kesempatan untuk mengontrol penghasilan. Kedua, mereka lebih
bereaksi secara positif kepada sistem karena mereka telah menjadi participan
aktif di dalam proses perubahannya (Lucas,
1974).

Penggabungan antara pengetahuan pengguna dan ahli akan membawa

kepada solusi yang lebih baik. Bagaimanapun juga pengguna seringkali memiliki
pandangan yang sangat sempit dan terbatas pada permasalahan yang akan
dipecahkan dan mungkin tidak memperhatikan kesempatan penting untuk
meningkatkan proses bisnis atau cara inovatif untuk mengaplikasikan teknologi
informasi. Keterampilan dan visi designer sistem profesional masih sangat
dibutuhkan sama halnya seperti pelayanan seorang arsitek sangat dibutuhkan
ketika membangun rumah baru. Hasilnya sepertinya lebih buruk apabila
seseorang mencoba mendesign rumahnya dengan caranya (Markus and Keil,
1994).

Gap Komunikasi Designer dengan Pengguna

Relasi antara konsultan dan klien secara tradisional menjadi bidang

masalah untuk usaha implementasi sistem informasi. Pengguna dan spesialis
sistem informasi cenderung memiliki latar belakang, ketertarikan dan prioritas
yang berbeda. Hal inilah yang disebut gap komunikasi designer dengan
pengguna. Perbedaan ini mengarahkan divergensi loyalti organisasi, pendekatan
untuk pemecahan masalah dan kosakata. Spesialis sistem informasi ,sebagai
contoh seringkali memiliki memiliki orientasi teknis atau mesin untuk pemecahan
masalah. Mereka terlihat seperti solusi teknis yang elegan dan berpengalaman
yang mana efsiensi hardware dan software dioptimasi pada biaya kemudahan
penggunaan atau efektitifitas organisasi. Sementara di sisi lain, pengguna
lebih
menyukai sistem yang diorientasikan untuk memecahkan permasalahan bisnis
atau memfasilitasi tugas organisasi. Seringkali orientasi dari kedua kelompok ini
sangat tidak tetap seperti mereka berbicara dengan lidah yang berbeda.
Perbedaan ini diilustrasikan pada Tabel 2, yang mana menggambarkan
konsentrasi yang biasanya dilakukan oleh pengguna akhir dan spesialis (designer
sistem informasi) terhadap pengembangan sistem informasi yang baru.
Permasalahan komunikasi antara pengguna dan designer merupakan alasan
utama mengapa kebutuhan pengguna tidak tepat
digabungkan ke dalam sistem informasi dan mengapa pengguna keluar dari
proses implementasi.

Gap Komunikasi Pengguna dengan Designer

Konsentrasi Pengguna Konsentrasi Designer
Akankah sistem memberikan informasi Seberapa banyak penyimpanan
yang saya yang akan
butuhkan untuk
Seberapa pekerjaan
cepat saya dapatsaya? digunakan oleh
mengakses Seberapa banyakfle master?
baris program
data itu? yang akan
Seberapa mudah saya mendapatkan digunakan untuk
Bagaimana kita melakukan fungsi ini?
bisa menurunkan
data? waktu CPU
Seberapa banyak dukungan saat kita cara
Apakah menjalankan sistem? untuk
paling efsien
administrasi(tulis menyimpan
menulis) yang saya potongan data ini?
butuhkan
Bagaimana untuk memasukkan
operasi data
sistem sesuai Sistem manajemen basis data apa yang
untuk jadwal akan kita
bisnis harian saya?Tabel 2. Gap Komunikasi
pergunakan?
Antar Pengguna dan Designer

Proyek pengembangan sistem memiliki resiko kegagalan yang amat tinggi

ketika ada gap antara pengguna dan teknisian dab ketika kelompok ini
melanjutkan untuk mengejar tujuan yang berbeda. Dalam kondisi seperti ini,
pengguna seringkali keluar dari proses implementasi. Partisipasi dalam usaha
implementasi sangat memakan waktu secara ekstrim dan membuatnya jauh dari
kegiatan harian dan tanggung jawab. Karena mereka tidak bisa memahami apa
yang dikatakan teknisian, pengguna menyimpulkan bahwa proyek ini sebaiknya
diberikan kepada spesialis saja. Dengan banyaknya usaha implementasi yang
dituntun oleh teknisian dengan sepenuh perhatian, maka tidak mengherankan
apabila banyak sistem yang gagal dalam memberikan pelayanan bagi kebutuhan
organisasi.

Dukungan Manajemen

Proyek sistem informasi memiliki manajemen menerima dan memberikan

pada level yang berbeda, itu lebih seperti persepsi positif antara pengguna dan
staf servis informasi teknis. Kedua kelompok akan mempercayai bahwa
partisipasinya akan dihargai untuk waktu dan usaha yang mereka berikan
untuk implementasi. Manajemen memberikan juga memastikan bahwa
proyek sistem akan menerima dana dan sumber daya yang cukup untuk sukses.
Lebih lagi semua pergantian dalam kebiasaan bekerja dan penyatuan kembali
organisasi yang diasosiasikan dengan sistem yang baru tergantung pada
manajemen pengembalian untuk dilaksanakan secara efektif. Jika seorang
manajer menganggap sebuah sistem baru sebagai prioritas, sistem akan lebih
diperhatikan sebagai bagiannya (Doll, 1985; Ein-Dor and Segev, 1978).
 Bagaimanapun juga dukungan manajemen kadang bisa memicu. Kadang-
kadang manajemen menjadi terlalu berkomitmen kepada sebuah proyek,
memberikan seluruh perhatian berlebihan ke
dalam usaha pengembangan sistem yang dapat menggagalkan sistem atau
yang tidak pernah disetujui di dalam tempat pertama (lihat Windows on
Technology) (Newman and Sabherwal, 1996).

Dukungan manajemen mungkin agak penting untuk bisnis kecil yang tidak
memiliki sumber daya atau birokrasi pengembangan organisasi besar. Ahli teknis
dan metodologi dari sumber luar seperti konsultan atau vendor teknologi
informasi mungkin memainkan aturan dalam mensukseskan implementasi,
karena bisnis kecil tidak memiliki staf sistem informasi internal (Thong, Yap, and
Raman, 1996).

Level Kompleksitas dan Resiko

Sistem berbeda secara jauh dalam ukuran, sekup, level kompleksitas dan
organisasi dan komponen teknis mereka. Beberapa proyek pengembangan
sistem, seperti proyek yang dijelaskan pada Windows on Techonology, lebih
terlihat seperti gagal karena mereka membawa level resiko yang lebih tinggi
dibandingkan dengan yang lainnya.

Para peneliti telah mengidentifkasi tiga dimensi kunci yang

mempengaruhi level resiko perlindungan (McFarlan, 1981).

Ukuran Project

Besarnya suatu proyek diidentifkasikan oleh uang yang

dihabiskan, jumlah staf implementasi, waktu yang dialokasikan untuk
implementasi dan jumlah unit organisasi yang dipengaruhinya. Makin besar
suatu proyek, maka makin besar resiko yang ditimbulkan. Misalnya suatu proyek
senilai $5 juta untuk 4 tahun dan mempengaruhi 5 departemen dalam 20 unit
operasi dan 120 pengguna, akan lebih beresiko daripada proyek $30.000
untuk 2 pengguna yang diselesaikan dalam 2 bulan. Faktor resiko yang lain
yaitu pengalaman perusahaan terhadap proyek yang diberikan. Apabila
perusahaan terbiasa mengimplementasikan proyek yang besar, resiko
mengimplementasikan proyek $5 juta akan lebih rendah. Resiko mungkin
lebih rendah daripada fakta dari mungkin lebih rendah daripada fakta dari
konsentrasi usaha sebuah proyek $200.000 ketika biaya produksi rata-rata
perusahaan sekitar $50.000.

Struktur Proyek

Beberapa proyek memiliki struktur yang lebih besar daripada yang

lainnya. Kebutuhannya jelas dan mudah dilakukan, sehingga output dan
prosesnya dapat didefnisikan dengan mudah. Pengguna mengetahui secara
tepat apa yang mereka inginkan dan apa yang dilakukan sistem. Dalam hal ini
hampir tidak ada kemungkinan bagi mereka untuk mengubah pikiran. Proyek
seperti ini memiliki resiko yang lebih rendah dibandingkan dengan proyek yang
kebutuhannya tidak didefnisikan, berubah-ubah dan berubah secara konstan, di
mana output tidak dapat ditetapkan dengan mudah karena mereka mengikuti
perubahan ide pengguna, atau karena pengguna tidak bisa setuju pada apa yang
mereka inginkan.

Pengalaman dengan Teknologi

 Resiko proyek akan meningkat apabila proyek dan staf sistem informasi
kekurangan ahli teknikal yang dibutuhkan. Apabila orang yang terlibat dalam
proyek asing dengan hardware atau
software sistem, software aplikasi atau Sistem Manajemen Basis Data yang
direncanakan untuk proyek, hal ini akan mengakibatkan terjadi hal-hal berikut :

Selip waktu tak terduga karena kebutuhan untuk menguasai keterampilan

baru.
Berbagai masalah teknis jika alat belum sepenuhnya dikuasai.
Pengeluaran berlebihan dan waktu tambahan karena kurangnya
pengalaman dengan keistimewaan yang tak tercatat dari setiap potongan
baru perangkat keras atau perangkat lunak.

Dimensi-dimensi risiko proyek akan hadir dalam kombinasi yang

berbeda untuk setiap upaya pelaksanaan. Tabel 14.3 menunjukkan bahwa
delapan tingkat risiko, yang paling besar kemungkinan bahwa upaya
pelaksanaan akan gagal.

Tabel 14.3 Dimensi Resiko Proyek

Project Technology
Project Structure Project Size Degree Of Risk
Level
High Low Large Low
High Low Small Very Low
High High Large Medium
High High Small Medium-Low
Low Low Large Low
Low Low Small Very Low
Low High Large Very High
Low High Small High

Manajemen Proses Pelaksanaan

Pengembangan sistem baru harus hati-hati dikelola dan diatur. Setiap proyek
melibatkan penelitian dan pengembangan. Persyaratan sulit untuk menentukan pada tingkat
rincian untuk otomatisasi. Bagian informasi yang sama dapat ditafsirkan dan didefinisikan
secara berbeda oleh individu yang berbeda. Beberapa pengguna berbeda saat kebutuhan dan
kebutuhan. Biaya, manfaat, dan jadwal proyek harus dinilai. Para Desaign terakhir mungkin
tidak mudah untuk memvisualisasikan. Karena sistem informasi yang kompleks melibatkan
kelompok kepentingan begitu banyak, aktor, dan rincian, kadang-kadang tidak pasti apakah
rencana awal untuk sistem yang benar-benar layak .

Sering elemen dasar keberhasilan dilupakan. Trainin GTO memastikan bahwa

pengguna akhir yang confortable dengan sistem baru dan memahami sepenuhnya
menggunakan potensi sering terlupakan dalam proyek pengembangan sistem. Sebagian
karena anggaran disaring menjelang akhir proyek, dan pada titik yang sangat startup ada dana
cukup untuk pelatihan (Bikson et al, 1985.).

Konflik dan ketidakpastian yang melekat dalam setiap upaya pelaksanaan akan
diperbesar ketika sebuah proyek implementasi kurang dikelola dan terorganisir. Seperti
diilustrasikan dalam gambar 14.6, sebuah pengembangan sistem proyek tanpa pengelolaan
yang baik kemungkinan besar akan menderita konsekuensi-konsekuensi ini :

Biaya overruns yang jauh melebihi anggaran

Biaya overruns yang jauh melebihi anggaran

terduga waktu selip

Teknis kekurangan yang mengakibatkan kinerja yang secara signifikan di bawah

perkiraan tingkat

Kegagalan untuk memperoleh manfaat yang diharapkan.

Bagaimana buruk adalah proyek dikelola? Rata-rata, proyek sectore swasta diremehkan
oleh satu setengah dalam hal anggaran dan waktu yang dibutuhkan untuk memberikan sistem
lengkap yang dijanjikan dalam rencana sistem. Jumlah yang sangat besar dari proyek yang
disampaikan dengan fungsi yang hilang (janji untuk pengiriman di versi). Proyek P
emerintah menderita dengan tingkat kegagalan yang sama, mungkin lebih buruk (Laudon,
1989; Helms dan Weiss, 1986).
Cost overruns
Poor Project Time slippage
Management Technical shortfalls impairing performance
Failure to obtain anticipated benefits

Gambar 14.6

Consequences of poor project management. Without proper management, a systems development project will take longer to
complete and most often will exceed the budgeted cost. The resulting information system will most likely be technically inferior
and may not be able to demonstrate any benefits to the organization.

Mengapa proyek yang dikelola begitu buruk dan apa yang bisa dilakukan tentang hal
itu? Di sini kita membahas beberapa kemungkinan.

KETIDAKTAHUAN DAN HARAPAN. Teknik untuk memperkirakan lamanya waktu

yang dibutuhkan untuk menganalisa dan desain sistem yang kurang berkembang. Tidak ada
standar, ada sedikit berbagi data dan pada organisasi, dan sebagian besar aplikasi adalah
pertama kali "(I, e., tidak ada pengalaman sebelumnya di daerah aplikasi). Akademisi
umumnya tidak mempelajari sistem komersial berskala besar melainkan fokus pada skala
kecil, mudah pemikiran manusia atau belajar proyek perangkat lunak. Skala yang lebih besar
dari sistem, pengumpulan dengan peran kebodohan dan optimisme. Untuk sistem berskala
besar (VLSI). Kadang-kadang disebut sistem grand design derita yang luar biasa untuk
tingkat kegagalan (Laudon, 1989; United States General Service Administrator, 1988). Hasil
murni dari faktor-faktor ini adalah bahwa perkiraan cenderung optimis, "kasus terbaik" dan
salah. Hal ini diasumsikan bahwa semua akan berjalan baik jika jarang sebenarnya.
MITOS MANUSIA - BULAN. Unit pengukuran secara tradisional yang digunakan oleh
desainer sistem untuk biaya proyek adalah manusia-bulan. Proyek adalah perkiraan dalam hal
bagaimana banyak manusia -bulan akan dibutuhkan. Namun, sedangkan biaya mungkin
bervariasi sebagai produk dan manusia-bulan, bukan kemajuan proyek , seperti yang
ditunjukkan oleh Frederick P. Brooks (Brooks, 1974). Ternyata, orang dan manusia-bulan
tidak dipertukarkan dalam jangka pendek pada proyek-proyek sistem. (Mereka mungkin
dipertukarkan dalam jangka panjang, namun kita hidup dalam jangka pendek). Dalam kata
lain, menambahkan lebih banyak pekerja untuk proyek-proyek tidak selalu mengurangi
waktu diperlukan untuk menyelesaikan sebuah proyek sistem.

Tidak seperti memetik kapas, ketika tugas dapat dipartisi secara tidak luwes,maka
komunikasi antara peserta tidak diperlukan, dan pelatihan tidak perlu. Sistem analisis dan
desain melibatkan tugas yang dihubungkan secara berurutan, tidak dapat dilakukan dalam
isolasi, dan membutuhkan komunikasi ekstensif dan pelatihan. Pengembangan perangkat
lunak secara inheren upaya kelompok, dan biaya komunikasi menjadi naik secara
eksponensial sebagai jumlah peserta yang meningkat. Apalagi bila omset pendekatan
personil 20 hingga 30 persen, banyak peserta dalam proyek perangkat lunak memerlukan
banyak belajar dan komunikasi.

Dengan karakteristik ini, menambah tenaga kerja untuk proyek-proyek sering dapat
memperlambat pengiriman, sebagai suatu komunikasi , belajar, dan biaya koordinasi naik
sangat cepat dan mengurangi untuk hasil akhir dari peserta. Untuk komparasi, bayangkan apa
yang akan terjadi jika lima penonton amatir yang ditambahkan untuk satu tim dalam
pertandingan kejuaraan basket profesional. Kemungkinan cukup baik bahwa tim terdiri dari
lima pemain basket profesional akan lebih baik dalam jangka pendek bahwa tim dengan lima
profesional dan lima amatir.

DIBALIK KEGAGALAN : BERITA BURUK YANG PERLAHAN MENANJAK. Selip

dalam proyek, kegagalan, dan keraguan seringkali tidak dilaporkan kepada manajemen senior
sampai itu menjadi terlambat. Sampai batas tertentu, sejauh ini adalah karakteristik proyek di
segala bidang. Konfirmasi Proyek, sistem informasi. Suatu sistem informasi untuk proyek
skala besar biasanya mengintegrasikan ke sebuah hotel, maskapai penerbangan, serta
pemesanan sewa mobil ini adalah contoh klasiknya. Hal ini disponsori oleh AMR
Information Service Inc., Suatu anak perusahaan dari American Airlines Corporation. Proyek
ini sangat ambisius dan teknis yang kompleks, mempekerjakan staf 500. Komfirmasi anggota
tim proyek manajemen yang tidak segera tampil ke depan dengan informasi yang akurat
ketika proyek ini mulai menghadapi masalah koordinasi kegiatan transaksi berbagai
pengolahan. Klien terus melakukan investasi dalam proyek yang tidak tetap karena mereka
tidak pernah diberitahu tentang masalah yang berkaitan dengan database, keputusan
dukungan, dan teknologi integrasi (Oz, 1994).
Contoh lain dari masalah ini adalah kecelakaan pesawat ulang-alik ruang angkasa pada
Januari 1986. Informasi yang segel O-ring pada pesawat ruang angkasa mungkin tidak
bekerja dengan baik dalam cuaca dingin pada Januari dan bahwa insinyur sangat keberatan
untuk meluncurkan pesawat dalam cuaca dingin sehingga tidak mencapai Nasional
Aeronaustics atas dan Space Administration (NASA) manajemen tim, yang akhirnya
memutuskan untuk meluncurkan. Alasannya, meskipun tidak sepenuhnya jelas, sebagian
melibatkan prinsip, baik mengerti bahwa pembawa berita buruk yang sering tidak dihargai
dan bahwa manajemen senior ingin jadwal yang harus dipenuhi.

Hirarki dari Organisasi memiliki sisi patologis dan mematikan: Apakah manajemen
senior sering disimpan dalam gelap (lihat Bab 3 dan 4). Untuk proyek sistem, ini tampaknya
menjadi sangat benar. Sistem pekerja tahu bahwa manajemen telah menjanjikan tanggal
pengiriman untuk grup pengguna penting, bahwa jutaan dolar telah dikeluarkan, dan bahwa
karir bergantung pada pengiriman tepat waktu dari keseluruhan sistem. Sebagai proyek ini
jatuh di belakang, satu hari pada satu waktu, tidak ada yang mau repot-repot manajemen
senior dengan rincian slip kecil. Evertually, hari menambahkan hingga bulan dan kemudian
ke tahun. Pada saat itu terlambat untuk menyelamatkan proyek, tidak peduli berapa banyak
orang yang ditambahkan ke tim.

Tantangan Bisnis Reengineering

Mengingat tantangan inovasi dan implementasi, tidak mengherankan untuk menemukan
tingkat kegagalan yang sangat tinggi antara proyek bisnis rekayasa ulang, yang biasanya
memerlukan perubahan organisasi yang luas. Serangkaian penelitian memperkuat Michael
Hammer, AOS pengamatan bahwa 70 persen dari semua proyek rekayasa ulang gagal untuk
memberikan manfaat yang dijanjikan. Banyak sistem informasi untuk mendukung bisnis
rekayasa ulang memakan waktu terlalu lama untuk mengembangkan dan don, AOT
menyampaikan apa yang diinginkan perusahaan. Perusahaan Cambridge, Massachusetts,
konsultasi dari Athur D. Little, Inc menemukan bahwa hanya 16 persen dari 350 eksekutif
bisnis yang disurvei, fully puas, dengan upaya rekayasa ulang bisnis mereka. Selain
itu, 68 persen dari eksekutif melaporkan bahwa proyek reengineering mereka telah unitended
efek samping, creatingnew masalah, bukan pemecahan yang lama (Caldwell, 1994).
Dalam beberapa kasus, masalah ini berasal dari manajemen, ketidakmampuan AOS
untuk mengidentifikasi masalah kritis yang harus diselesaikan dengan rekayasa ulang atau
untuk membedakan antara revamping radikal dari proses bisnis inti dan perubahan bertahap.
Dalam hal demikian, perusahaan akan Facebook hanya membuat tambahan perbaikan dalam
operasi yang sedang berlangsung bukan radikal ulang proses bisnis di sana. Namun dalam
banyak kasus, rintangan utama untuk rekayasa ulang disebabkan oleh buruknya implementasi
dan praktik perubahan pihak manajemen yang gagal mengatasi ketakutan luas perubahan.
Gambar 14.7 meringkas Deloitte & Touche, temuan AOS tentang hambatan terbesar untuk
reengineering bisnis yang sukses. Studi yang dilakukan oleh CSC Indeks Inc dan lainnya
melaporkan hasil yang sama. Berurusan dengan anxety takut anf seluruh organisasi,
mengatasi perlawanan oleh manajer kunci, mengubah fungsi pekerjaan, jenjang karir,
rekrutmen, dan pelatihan menimbulkan ancaman yang lebih besar untuk rekayasa ulang dari
kesulitan perusahaan dengan visualisasi dan merancang perubahan terobosan untuk proses
bisnis mereka (Maglitta, 1994) . masalah Reengineering adalah bagian dari masalah yang
lebih besar dari pelaksanaan organisasi dan manajemen perubahan.

Proses Pelaksanaan: Apakah bisa Kesalahan itu Pergi

Masalah berikut ini dianggap khas untuk setiap tahap pengembangan sistem ketika
proses implementasi tidak dikelola dengan baik.
Analisis

Waktu, Uang, dan Sumber Daya belum dialokasikan untuk meneliti masalah.
Masalahnya masih ditetapkan. Tujuan dari pelaksanaan proyek akan kabur dan
ambigu; manfaat akan sulit untuk diukur.

Sedikit atau tidak ada waktu yang dihabiskan dalam perencanaan awal. Tidak ada
standar untuk digunakan dalam memperkirakan biaya awal atau durasi proyek.

Tim proyek tidak benar staf. Personil yang ditugaskan secara "tersedia" dan tidak bisa
mendedikasikan diri mereka untuk proyek. Kelompok pengguna yang akan dilayani
oleh sistem yang tidak terwakili dalam tim.

Staf jasa informasi menjanjikan hasil yang tidak mungkin untuk memberikan.
Persyaratan berasal dari dokumentasi yang tidak memadai dari sistem yang ada atau
menemukan tidak lengkap dari kegiatan belajar sistem.

Pengguna menolak untuk menghabiskan waktu membantu tim proyek mengumpulkan

informasi requsite.

Proyek analis tidak bisa wawancara pengguna dengan benar. Mereka tidak tahu
bagaimana mengajukan pertanyaan yang tepat. Mereka tidak dapat melanjutkan
percakapan diperpanjang dengan pengguna karena mereka tidak memiliki
kemampuan komunikasi yang baik.

Desain

Pengguna tidak bertanggung jawab atas atau masukan untuk merancang kegiatan.
Desain Oleh karena itu, mencerminkan bias atau staf teknis. Tidak mesh baik dengan
struktur, aktivitas, dan budaya organisasi th e atau prioritas manajemen.

Sistem ini dirancang hanya untuk melayani kebutuhan saat ini. Tidak ada fleksibilitas
telah dibangun untuk mengantisipasi kebutuhan masa depan organisasi.

perubahan drastis dalam prosedur administrasi atau staf yang direncanakan tanpa
analisis dampak organisasi.

spesifikasi fungsional adalah kurang didokumentasikan.

Pemrograman

Jumlah waktu dan dana yang diperlukan untuk pengembangan perangkat lunak
diremehkan.

Pemrogram diberikan dengan spesifikasi lengkap.

 Tidak cukup waktu dikhususkan untuk pengembangan logika program, terlalu banyak
waktu yang terbuang pada menulis kode.

Programmer tidak mengambil keuntungan penuh dari desain terstruktur atau teknik
berorientasi objek. Mereka menulis program yang sulit untuk memodifikasi dan
memelihara.

Program tidak cukup didokumentasikan.

Syarat sumber daya (seperti waktu komputer) tidak dijadwalkan.

Pengujian

Jumlah waktu dan uang yang dibutuhkan untuk pengujian yang tepat diremehkan.

Tim proyek tidak mengembangkan rencana tes terorganisir.

Pengguna tidak sufficienctly terlibat dalam pengujian. Mereka tidak membantu untuk
membuat data uji sampel atau hasil review tes. Mereka menolak untuk mencurahkan
banyak waktu untuk upaya pengujian.

Tim pelaksanaan proyek tidak mengembangkan tes penerimaan yang tepat untuk
tinjauan manajemen. Manajemen tidak meninjau dan menandatangani hasil tes.

Konversi

Kurangnya waktu dan uang yang dianggarkan untuk kegiatan percakapan, terutama
untuk konversi data.

Tidak semua individu yang akan menggunakan sistem yang terlibat sampai konversi
dimulai. Pelatihan dimulai hanya ketika sistem hendak diinstal.

Untuk mengimbangi overruns biaya dan penundaan, sistem dibuat operasional

sebelum sepenuhnya siap.

Sistem dan dokumentasi pengguna tidak memadai.

Kinerja evaluasi tidak dilakukan. Tidak ada standar kinerja ditetapkan, dan hasil dari
sistem tidak ditimbang dengan tujuan asli.

Kinerja evaluasi tidak dilakukan. Tidak ada standar kinerja ditetapkan, dan hasil dari
sistem tidak ditimbang dengan tujuan asli.

Ketentuan untuk pemeliharaan sistem tidak memadai. sistem informasi tidak cukup
personel traines untuk mendukung sistem dan melakukan perubahan pemeliharaan.
MENGELOLA IMPLEMENTASI

Tidak semua aspek dari proses implementasi dapat dengan mudah dikendalikan atau
direncanakan (Ginzberg, 1978). Namun, peluang untuk sukses sistem dapat ditingkatkan
dengan mengantisipasi potensi masalah pelaksanaan dan menerapkan strategi koreksi yang
tepat. Berbagai manajemen proyek, mengumpulkan persyaratan, dan metodologi perencanaan
telah dikembangkan untuk kategori tertentu dari masalah. Strategi juga telah dirancang untuk
memastikan bahwa pengguna memainkan peran yang tepat selama periode implementasi dan
untuk mengelola proses perubahan organisasi.

Mengontrol Faktor Risiko

Pelaksanaan cara dapat ditingkatkan adalah dengan adjusing strategi manajemen

proyek dengan tingkat risiko yang melekat pada masing-masing proyek. Jika sebuah proyek
pengembangan sistem diganti dalam kategori risiko yang tepat, tingkat risiko dapat diprediksi
sebelumnya dan strategi yang dikembangkan untuk melawan faktor risiko tinggi (McFarlan,
1981).
Pelaksana harus mengadopsi pendekatan darurat untuk manajemen proyek, penanganan
setiap proyek dengan alat-alat, metdhologies manajemen proyek, dan organisasi dalam
kaitannya untuk diarahkan untuk tingkat risiko. Ada empat teknik dasar manajemen proyek :

1. Alat integrasi eksternal menghubungkan pekerjaan dari tim implementasi ke user pada semua
level organisasi.
2. Alat integrasi internal meyakinkan bahwa tim imlementasi bekerja sebagai tim yang solid.
3. Alat perencanaan formal mengatur dan menyusun tugas,enyediakan estimasi waktu,uang dan
sumberdaya teknik yang dibutuhkan
4. Alat control formal membantu memonitor perkembangan pemenuhan tugas dan pemenuhan
tujuan.

Profil resiko dari tiap proyek akan memerlukan aplikasi teknik manajemen proyek yang sesuai.
Sebagaimana diilustrasikan di tabel berikut ini :

Strategi-strategi Untuk Mengatur Proyek Dengan Kontrol Resiko.

Struktur Level teknologi Ukuran Derajat resiko Alat manajemen proyek
proyek proyek proyek
1. Tinggi Rendah Besar Rendah Perencanaan formal-tinggi
Kontrol formal-tinggi
2. Tinggi Rendah Kecil Sangat rendah Kontrol formal-tinggi
Perencanaan formal-
menengah
3. Tinggi Tinggi Besar Menengah kontrol formal-menengah
Perencanaan formal-
menengah
4. Tinggi Tinggi Kecil Menengah-rendah Integrasi Internal -tinggi
5. Rendah rendah Besar Rendah Integrasi eksternal-tinggi
Perencanaan formal-tinggi
 Kontrol formal-tinggi
6. Rendah Rendah Kecil Sangat rendah Integrasi eksternal-tinggi
Kontrol formal-tinggi
7. Rendah Tinggi Besar Sangat tinggi Integrasi eksternal-tinggi
Integrasi internal tinggi
8. Rendah tinggi kecil tinggi Integrasi eksternal-tinggi
Integrasi internal tinggi

ALAT INTEGRASI EKSTERNAL

Proyek dengan struktur yang relatif kecil harus melibatkan user secara penuh setiap tahap
proyek. User harus digerakkan untuk mendukung salah satu dari berbagai pilihan design sistem dan
harus berkomitmen atas design yang menjadi pilihannya. Untuk itulah maka alat integrasi eksternal
harus diaplikasikan.
User harus dipilih sebagai pimpinan proyek atau sebagai pemberi komando kedua di tim proyek.
Steering komite dari user harus diciptakan untuk mengevaluasi design sistem.
User dapat menjadi anggota aktif dari team proyek.
Proyek dapat menggunakan review/ulasan dari user dan persetujuan spesifikasi.
Menit-menit dari pertemuan yang membahas kunci-kunci design harus didistribusikan secara
meluas pada para user.
User bisa menyiapkan laporan status untuk pihak manajemen yang lebih tinggi.
User dapat ditempatkan di bagian training & instalasi
User bertanggungjawab pada kontrol perubahan,mengerem perubaan yang tidak penting
terhadap sistem saat spesifikasi design sudah lengkap.

ALAT INTEGRASI INTERNAL

Proyek dengan manfaat teknologi tingkat tinggi dari alat integrasi internal. Kesuksesan dari
proyek tersebut tergantung pada sebaik apa kopleksitas teknik dapat diatur. Pimpinan proyek
membutuhkan teknik yang baik dan pengalaman administratif. Mereka harus dapat mengantisipasi
masalah dan membangun hubungan kerja yang baik diantara tim teknis.
Anggota tim harusmempunyai pengalaman yang baik
Tim harus berada di bawah kepemimpinan manajer yang mempunyai kemampuan teknis
yang kuat dan latar belakang manajemen proyek yang baik.
Pertemuan tim harus diadakan secara teratur, dengan distribusi rutin dari setiap menit
pertemuan untuk memutuskan kunci-kunci design.
Tim harus mengadakan ulasan status teknis secara teratur.
Anggota-anggota tim harus mempunyai riwayat hubungan yang baik dengan anggota tim
yang lain.
Anggota tim harus berpartisipasi pada penetapan tujuan dan penentuan tanggal target.
Keahlian teknis yang penting atau keahlian-keahlian lain yang tidak tersedia secara internal
harus diamankan dari luar organisasi.

PERENCANAAN FORMAL DAN ALAT-ALAT KONTROL

Proyek dengan struktur yang tinggi dan teknologi rendah mempunyai resiko yang terendah.
Design fix dan stabil, dan proyek tidak menimbulkan tantangan teknis. Jika proyeknya besar. Maka
bisa secara sukses diatur dengan perencanaan formal dan alat kontrol formal. Dengan teknik
manajemen seperti PERT (Program Evaluation & Review Technique) atau ganttchart, maka sebuah
rencana detail dapat dikembangkan.

PERT merupakan daftar aktifitas spesifik seputar proyek, durasinya dan aktifitas yang harus
dilengkapi sebelum sebuah aktifitas spesifik dimulai. Sebuah ganttchart secara visual mewakili urutan
dan jadwal dari berbagai tugas pada sebuah proyek pembangunan. Tugas-tugas dapat didefinisikan
dan sumberdaya dianggarkan. Teknik manajemen proyek tersebut dapat membantu menajer
mengidentifikasinadanya kejadian bottleneck dan menentukan akibat dari masalah yang akan terjadi
di waktu penyelesaian proyek.

Fase-fase target dapat dipilih

Spesifikasi-spesifikasi dapat di kembangkan dari studi kelayakan
Spesifikasi standar dapat dijalankan
Proses persetujuan proyek dapat dibangun.

Teknik kontrol standar dapat menggambarkan kemajuan proyek terhadap anggaran dan
tanggal target, dengan begitu maka tim implementasi dapat membuat penyesuaian untuk
mencocokkan jadwal asli mereka.

Disiplin untuk mengontrol atau membekukan design dapat dipertahankan.

Penyimpangan rencana dapat dilihat.
Laporan status formal periodik terhadap rencana akan memperlihatkan kemajuan proyek.

MENGATASI PENOLAKAN DARI USER

Selain untuk memastikan penerapat stategi manajemen proyek, resiko-resiko imlementasi

dapat dikurangi dengan mengamankan manajemen dan dukungan pengguna upaya implementasi.

Produk akhir lebih mungkin untuk mencerminkan kebutuhan pengguna. pengguna lebih
cenderung merasa bahwa mereka kontrol dan memiliki sistem . user juga akan merasa lebih puas
terhadap sistem informasi jika mereka sudah dilatih untuk menggunakannya. (Cronan &
Douglas,1990)

Bagaimanapun, para peneliti MIS juga menyatakan bahwa pembangunan sistem bukahlah
sebuah proses yang rasional. Aktivitas pengguna desain terkemuka telah memanfaatkan posisi mereka
untuk kepentingan pribadi lebih lanjut dan untuk mendapatkan kekuasaan penilai dari pada untuk
mempromosikan tujuan organisasi.(Franz & Robey,1984). User mungkin tidak selalu terlibat dalam
proyek sistem pada suatu cara yang produktif, sebagaimana dijelaskan di bagian jendela manajemen.

Partisipasi pada aktifitas implementasi mungkin tidak cukup untuk mengatasimasalah-

masalah dari penolakan user. Proses impelemtasi membutuhkan perubahan organisasi. Beberapa
perubahan kemungkinan akan ditolak oleh user karena user yang berbeda mungkin akan terpengaruh
oleh sistem dalam cara yang berbeda pula. Disamping itu beberapa user mungkin akan menerima
sistem yang baru karena dipercaya akan membawa perubahan yang bermanfaat bagi mereka,
sementara user yang lai menolak perubahan-perubahan tersebut karena meyakini bahwa pergeseran
akan merugikan kepentingan mereka (Joshi,1991)

Jika penggunaan sistem adalah secara sukarela, user mungkin akan memilih untuk
menghindarinya. Jika penggunaannya merupakan sebuah perintah, penolakan akan berbentuk
menjadi menigkatnya kesalahan, gangguan,dan bahkan sabotase. Maka strategi implementasi tidak
hanya harus melibatkan partisipasi user, tetapi juga harus memperhatikan isi-isu dari
counterimplementation. Counterimplementation adalah strategi yang sengaja dibuat untuk
mencegah implementasi dari sistem informasi atau suatu inovasi pada sebuah organisasi.

Para peneliti sudah menjelaskan tentang penolakan-penolakan user dengan satu dari 3 teori
(Markus,1983; Davis dan Okson 1985):

1. Teori orientasi manusia

Faktor internal dari user sebagai individual atau sebagai grup menghasilkan penolakan. Lebih
singkatnya, user mungkin menolak sebuah sistem baru atu perubahan lainnya karena takut
atau karena tidak ingin mempelajari cara-cara baru untuk melakukan sesuatu.

2. Teori orientasi sistem

Faktor-faktor yang melekat pada sistem membuat user menolak sistem tersebut. contohnya
user mungkin menolak sebuah sistem karena interfacenya membingungkan dan mereka
bermasalah dalam mempelajari kinerja sistem, menghasilkan penolakan user pada sistem.

3. Teori Interaksi.
Penolakan disebabkan faktor interaksi manusia dan sistem. Contohnya, sistem mungkin
didesign dengan sebaik-baiknya dan diterima sebagai user, tapi ditolak oleh user yang lain
karena takut bahwa sistem akan mengambil kekuatan atau peran mereka dan bahkan mereka
takut akan kehilangan pekerjaannya.

Strategi yang disarankan untuk mengatasi berbagai bentuk penolakan user:

Orientasi Manusia :
- pelatihan user (training)
- Pemaksaan (politik, hukum)
- Pendekatan
- Partisipasi user (untuk membangun komitmen)
Orientasi Sistem :
- Pelatihan user
- Peningkatan faktor kemanusiaan (interface)
- Partisipasi user (peningkatan design)
- Modifikasi paket untuk menyesuaikan sistem dengan organisasi bila perlu
Interaksi :
- Mengatasi masalah-masalah organisasi sebelum memperkenalkan sistem yang baru
- Restrukturisasi insentif bagi user
- Restruturisasi hubungan user dengan designer
- Promosi partisipasi user bila perlu

Straegi yang diperlukan untuk teori interaksi mengandung elemen-elemen orientasi manusia dan
strategi orientasi sistem. Ada orientasi yang mana partisipasi user tidak diperlukan. Contohnya
beberapa user bereaksi negatif terhadap design yang baru meskipun ini bermanfaat. Beberapa user
mungkin akan kehilangan kekuasaannya sebagai akibat dari keputusan design (Roby dan Markus,
1984). dalam hal ini partisipasi contoh dalam desain benar-benar dapat memperburuk kebencian dan
penolakan.
MERANCANG UNTUK PERUSAHAAN

Proses pengembangan secara keseluruhan dapat dilihat sebahai perubahan organisasi yang
terencana, karena tujuan dari sebuah sistem baru adalah untuk memperbaiki performa organisasi. Oleh
karena itu, proses pengembangan secara eksplisit harus menunjukkan cara-cara di mana organisasi
akan berubah ketika sistem yang baru diinstal, termask instalasi intranet. Sebagai tambahan, perbahan
prosedural,transformasi fungsi-fungsi pekerjaan, kekuatan hubungan dan perilaku yang semuanya
harus direncanakan dengan hati-hati. Saat perubahan teknologi yang ada membawa konsekuensi yang
tidak terduga, organisasi dapat mengambil manfaat dari kesempatan yang baru. Spesialis Sistem
Informasi, Manajer dan user harus perpikiran terbuka terhadap aturan-aturan yang ada pada proses
perubahan manajemen dan tidak mempertahankan persepsi sempit yang berbahaya. (Orlikowski &
Hofman,1997; Markus & Benjamin,1997).

Meskipun aktifitas analisa dan design sistem seharusnya mencakup analisis dampak
organisasi, wilayah ini secara tradisional telah diabaikan. Sebuah analisis dampak organisasi
menjelaskan bagaimana sebuah sistem akan berdampak pada struktur organisasi, perilaku,
pengambilan keputusan dan operasi-operasi untuk menggabungkan sistem informasi dan organisasi
secara sukses, evaluasi mengenai dampak organisasi yang didokumentasikan secara penuh dan
menyeluruh harus mendapat perhatian yang lebih pada usaha pengembangan sistem.

Memungkinkan untuk faktor manusia

Kualitas sistem informasi harus dievaluasi dari segi kriteria pengguna

daripada berdasar kriteria staf sistem informasi. Selain tujuan seperti ukuran
memori, tingkat akses, dan waktu perhitungan, tujuan sistem juga harus
mencakup standar bagi kinerja pengguna. Sebagai contohnya, mungkin bisa
berupa waktu yang dibutuhkan oleh petugas data entry yang belajar produsen
dan kode untuk empat layar isian data baru secara on-line dalam sesi pelatihan
setengah hari.

Area dimana antarmuka pengguna dengan sistem harus hati-hati

dirancang, dengan kepekaan terhadap masalah ergonomis. Ergonomi mengacu
pada interaksi orang dan mesin di lingkungan kerja. Dalam mempertimbangkan
desain pekerjaan, masalah kesehatan, dan antarmuka pengguna akhir sistem
informasi. Dampak dari sistem aplikasi pada dimensi lingkungan kerja dan
pekerjaan harus dinilai dengan hati-hati. Pada studi layak-catat dari 620
administrasi Keamanan Sosial perwakilan klaim menunjukkan bahwa perwakilan
yang memiliki akses online untuk data klaim mengalami stres lebih besar
daripada mereka yang memiliki akses serial ke data melalui teletype. Meskipun
antarmuka online lebih cepat dan langsung daripada teletype, tetapi lebih
menciptakan frustrasi. Perwakilan dengan akses on-line bisa antarmuka dengan
jumlah yang lebih besar klien per hari. Hal ini mengubah dimensi pekerjaan
untuk perwakilan klaim. Restrukturisasi kerja - yang melibatkan tugas, kualitas
kehidupan kerja, dan kinerja - memiliki dampak yang lebih mendalam daripada
sifat dari teknologi itu sendiri (Turner, 1984).

Rancangan Sociotechnical
 Kebanyakan pendekatan sistem-bangunan kontemporer cenderung
memperlakukan pengguna akhir sebagai sesuatu yang penting dalam proses
membangun sistem tapi kebanyakan memainkan peran pasif yang relatif
terhadap kekuatan lain membentuk sistem seperti para desainer spesialis sistem
dan manajemen. Sebuah tradisi yang berbeda berakar pada gerakan buruh eropa
sosial demokratis pengguna memberikan peran yang lebih aktif, salah satu yang
memberdayakan mereka untuk codetermine peran sistem informasi di tempat
kerja mereka (Clement dan Van den Besselaar, 1993).

Tradisi desain partisipatif ini menekankan partisipasi oleh individu yang

paling terpengaruh oleh sistem yang baru. Ini sangat erat kaitannya dengan
konsep desain sociotechnical. Sebuah rencana desain sociotechnical menetapkan
tujuan manusia untuk sistem yang mengarah pada peningkatan kepuasan kerja.
Designer ditetapkan yang terpisah terhadap solusi desain teknis dan sosial.
Desain sosial rencana mengeksplorasi struktur workgroup yang berbeda, alokasi
tugas, dan desain pekerjaan individu. Solusi-solusi teknis yang diusulkan
dibandingkan dengan mengusulkan solusi sosial. Sosial dan solusi teknis yang
dapat dikombinasikan diusulkan sebagai solusi sociotechnical. Alternatif yang
paling baik memenuhi tujuan sosial dan teknis dipilih untuk desain akhir. Desain
sociotechnical dihasilkan diharapkan dapat menghasilkan sistem informasi yang
memadukan efsiensi teknis dengan kepekaan terhadap kebutuhan organisasi
dan manusia, yang mengarah ke kepuasan kerja tinggi (Mumford dan Weir,
1979). Sistem dengan unsur-unsur teknis dan organisasi yang kompatibel
diharapkan untuk meningkatkan produktivitas tanpa mengorbankan tujuan
manusia dan sosial.

Alasan-alasan utama bagi kegagalan sistem adalah tidak

memadainya dukungan manajemen dan lemahnya manajemen proses
implementasi. Manajer sepenuhnya harus memahami tingkat kompleksitas dan
risiko di proyek sistem baru dan memberikan tingkat yang realistis
terhadap dukungan dan sumber daya yang diperlukan.

Alasan mengapa sistem informasi gagal adalah bahwa sistem

pembangun mengabaikan masalah perilaku organisasi, khususnya inersia
organisasi dan penolakan terhadap perubahan. Menggalang dukungan dari
pengguna dan mempertahankan tingkat yang tepat dari keterlibatan pengguna
pada semua tahapan pengembangan sistem merupakan hal yang sangat
penting.

Sistem kadang-kadang gagal karena teknologi yang terlalu rumit

atau canggih untuk dengan mudah dilaksanakan atau karena pembangun
sistem tidak memiliki keterampilan yang diperlukan atau pengalaman yang
berkaitan dengan hal-hal tesebut. Manajer dan pembangun sistem harus
sepenuhnya menyadari resiko dan manfaat dari berbagai teknologi yang ada
karena mereka membuat pilihan teknologi mereka sendiri.

KESIMPULAN

1. Identifikasi daerah masalah utama dalam sistem informasi.

Persentase yang tinggi dari sistem dianggap gagal karena mereka tidak
digunakan dalam cara mereka dimaksudkan. Ada yang tidak digunakan
sama sekali. Kegagalan sistem ini dibuktikan dengan masalah desain,
data, biaya, atau penoperasian. Sumber keberhasilan atau kegagalan
sistem yang terutama adalah bersifat perilaku dan secara organisasi.
 2. Tentukan apakah suatu sistem sukses. Kriteria untuk mengevaluasi
keberhasilan sistem informasi meliputi (1) tingkat penggunaan sistem,
(2) kepuasan pengguna, (3) sikap pengguna yang menguntungkan
sistem informasi dan stafnya, (4) tujuan yang dicapai, dan (5)
keuntungan keuangan yang didapatkan oleh organisasi.

3. Jelaskan penyebab utama kegagalan sistem informasi. Penyebab

pokok kegagalan sistem informasi antara lain: (1) tidak memadai atau
tidak layaknya partisipasi pengguna dalam proses pengembangan sistem,
(2) kurangnya dukungan manajemen, (3) tingginya tingkat kompleksitas
dan risiko dalam proses pengembangan sistem, dan (4) miskinnya
pengelolaan proses implementasi. Terdapat tingkat kegagalan yang
sangat tinggi pada proyek bisnis rekayasa ulang karena mereka
memerlukan perubahan organisasi yang luas.

4. Jelaskan hubungan antara proses pelaksanaan dan hasil

sistem. Implementasi adalah seluruh proses perubahan organisasi yang
mencakup pengenalan sistem informasi baru. Seseorang dapat lebih baik
dapat memahami keberhasilan dan kegagalan sistem dengan memeriksa
pola penerapan yang berbeda. Yang terutama adalah hubungan antar
peserta dalam proses pelaksanaan, khususnya interaksi antara
perancang sistem dan pengguna. Konfik antara orientasi teknis dari
desainer sistem dan orientasi bisnis pengguna akhir harus diselesaikan.
Keberhasilan perubahan organisasi dapat ditentukan oleh bagaimana
karya spesialis informasi, pengguna akhir, dan pengambil keputusan
dalam menangani masalah- masalah di berbagai tahapan pelaksanaan.

5. Jelaskan strategi yang tepat untuk mengelola proses

implementasi. Dukungan manajemen pada proses implementasi sangat
penting, karena merupakan mekanisme untuk berurusan dengan tingkat
resiko dalam setiap proyek sistem baru. Beberapa pengalaman
perusahaan, organisasi menolak terhadap perubahan. Faktor risiko
proyek dapat dikendalikan dengan pendekatan darurat untuk manajemen
proyek. Tingkat risiko dalam proyek pengembangan sistem ditentukan
oleh tiga dimensi kunci: (1) ukuran proyek, (2) struktur proyek, dan (3)
pengalaman dengan teknologi. Tingkat risiko dari setiap proyek akan
menentukan campuran yang tepat alat integrasi eksternal, alat integrasi
internal, alat perencanaan formal, dan alat kontrol formal untuk
diterapkan.

Strategi yang tepat dapat diterapkan untuk memastikan tingkat yang

benar partisipasi pengguna dalam proses pengembangan sistem untuk
meminimalkan resistensi pengguna. Desain sistem informasi dan pelaksanaan
seluruh proses harus dikelola sebagai perubahan organisasi yang direncanakan.
Desain partisipatif menekankan partisipasi individu yang paling dipengaruhi
oleh sistem baru. Desain Sociotechnical bertujuan bagi paduan optimal dari
solusi desain yang bersifat sosial dan teknis.